Devredilmiş Yetki Sorunu: BES Pipeline Erişim Kontrolleri Neden Patlamaya Hazır Bir Denetim Bulgusu?

Son on yılda kurduğum ya da devraldığım her BES (Bireysel Emeklilik Sistemi) pipeline'ının aynı mimari günahı var: erişim kontrol katmanı bir kez, kuruluş anındaki organizasyon şemasına göre tasarlandı ve ardından sonraki beş yıl boyunca sessizce gerçeklikten uzaklaştı. Bu sapmayı kimse loglamıyor. Kimse yeniden onaylamıyor. Ve pipeline aynı anda üç düzenleyici akışı — EGM, FATCA ve CRS — beslediğinde, bu sapma artık bir BT hijyen meselesi olmaktan çıkıp imzalı bildirim sorununa dönüşüyor.

Bu, devredilmiş yetki sorunudur. Ve istisnasız, patlamaya hazır bir denetim bulgusudur.

Kuruluş Anı Fotoğrafı Yanılgısı

Bir BES pipeline'ı üretime alındığında, birisi bir erişim matrisi yazar. İlk gün genellikle makul görünür:

• Pipeline sahibi: kıdemli data engineer, tam prod erişimi
• Batch operatörü: ops takım lideri, planlı DAG üzerinde çalıştırma yetkisi
• Mutabakat inceleyicisi: finans kontrolörü, staging + gold üzerinde okuma yetkisi
• Düzenleyici imza yetkilisi: uyum yetkilisi, bildirim ekstresi üzerinde okuma yetkisi

Sonra 400'üncü gün gelir. Kıdemli data engineer fraud ekibine geçmiş ama AD grubunu korumuştur. Ops takım liderinin rolü ikiye ayrılmıştır, ikisi de çalıştırma yetkisini resmi olarak devralmamıştır — ama grup üyeliği hiç temizlenmediği için her iki kişide de hâlâ vardır. Finans kontrolörü emekli olmuş; yerine gelen kişi, aynı erişime ek olarak üç farklı sistemde yazma yetkisi içeren daha geniş bir "finance-all" grubuna eklenmiştir. Uyum bölümü yeniden yapılanmış, FATCA sign-off yetkisi bir yetkiliden diğerine geçmiş, ancak eski yetkilinin hesabı hâlâ CRS ile ilgilendiği için aktiftir.

Bunların hiçbiri kötü niyetli değildir. Hiçbiri bir uyarı tetiklemez. Ve hiçbiri, hâlâ ilk günü yansıtan pipeline dokümantasyonunda görünmez.

EGM, FATCA ve CRS Neden İşi Daha da Zorlaştırıyor?

Yalnızca EGM'yi besleyen bir pipeline'ın bile bu sorunu olurdu. BES vakasını gerçekten tehlikeli kılan şey, aynı katılımcı ve katkı tablolarının üç farklı düzenleyiciyi üç farklı kapsamda beslemesidir:

• EGM, yurt içi katılımcı görünümünü, katkı geçmişini ve devlet katkısı hesaplamalarını önemser.
• FATCA, US person indicia'sını, özellikle de indicia flag'lerini kimin değiştirebildiğini önemser.
• CRS, vergi mukimliği tespiti ve yargı yetki alanları arası raporlanabilir hesap statüsünü önemser.

Tek veri seti. Üç imza yetkilisi. "Bu kaydı değiştirmeye yetkili" ifadesinin üç farklı tanımı. Ve pratikte, katılımcı tablosuna yazma yetkisini, BES ops rotasyonunda bir kez bile bulunmuş herkese veren tek bir AD grubu.

FATCA bildirimi gönderildikten sonra denetçi, belirli bir hesaptaki US indicia flag'inin Mart ayında bir Salı günü çalışan batch tarafından güncellendiğini tespit ettiğinde, soru "pipeline doğru muydu" değildir. Soru şudur: O batch'i kim çalıştırdı, hangi yetki altında çalıştırdı ve bu yetki o tarihte FATCA ile ilgili alanları değiştirmeyi meşru olarak kapsıyor muydu?

Bu soruyu bir hafta süren adli inceleme çalışması yapmadan net bir şekilde cevaplayabilen bir BES pipeline'ı hiç görmedim.

Hiç Gerçekleşmemiş Görevler Ayrılığı

BES pipeline'larında görevler ayrılığı (SoD) genellikle roller arası bir matris olarak kağıt üzerinde vardır. Ama uygulama katmanı roller değildir — grup üyelikleridir. Ve grup üyelikleri, SoD matrisiyle hiç ilgisi olmayan sebeplerle verilir:

• Birinin gece 2'de bir üretim vakasını debug etmesi gerekmiştir ve "geçici olarak" eklenmiştir.
• Bir junior gölgeleme yapıyordu, onboarding'i hızlandırmak için okuma yetkisi verildi.
• Bir dış danışman, on sekiz ay önce sona eren bir migrasyon projesi için erişime ihtiyaç duymuştu.
• BI ekibi mutabakat ekstrelerini çekmek için bir servis hesabına ihtiyaç duydu ve kimse daha dar bir rol tasarlamak istemediğinden, servis hesabına insan operatörle aynı yetkiler verildi.

Bunların her biri tek başına savunulabilir kararlardır. Birlikte ise şu anlama gelirler: tutarsızlığın yaşandığı gün, on iki kişi ve dört servis hesabı o batch'i çalıştırmış olabilir; pipeline logları hangi hesabın çalıştırdığını söyleyecek ama o hesabın arkasındaki insanın kim olduğunu söylemeyecektir.

Denetçi Aslında Ne Sorar?

Bulgu düştüğünde denetçi size CI/CD pipeline'ınızı veya dbt testlerinizi sormaz. Şunları sorar:

1. 15 Mart FATCA bildirimini besleyen veriyi değiştirmeye kim yetkiliydi?
2. Bu listeyi 15 Mart'ta veya öncesinde teyit eden erişim incelemesini gösterin.
3. Bir önceki bildirim ile 15 Mart arasında ilgili tablolara yalnızca bu kişilerin (veya yetkili servis hesaplarının) dokunduğunu kanıtlayan log kayıtlarını gösterin.
4. Bu pencerede verilen erişim yetkileri için değişiklik kontrolünü gösterin.

Eğer (2)'ye cevabınız altı ay önce, o zamandan beri değişmiş bir organizasyon şemasına karşı yapılan yıllık erişim yeniden sertifikasyonu ise, bulgunuz var demektir. (3)'e cevabınız, AD loglarını pipeline yürütme loglarıyla ve talep sistemi onaylarıyla birleştirmeyi gerektiren ad-hoc bir Excel dosyası ise, bulgunuz var demektir. (4)'e cevabınız "hiç vermedik" ama AD denetim logu üç grup üyeliği değişikliği gösteriyorsa, bulgunuz var demektir.

Gerçekten İşe Yarayan Nedir?

Yeterince bu döngüden geçtikten sonra birkaç şey emeğinin karşılığını verir:

• Erişimi pipeline'a değil, bildirime bağlayın. Her düzenleyici ekstrenin kendi erişim soy ağacı olmalı ve her bildirim döngüsünden önce — yılda bir değil — yeniden onaylanmalıdır. FATCA ekstresinin yetkili değiştiriciler listesi bir uyum belgesidir, BT belgesi değil.
• Servis hesaplarının, son kullanma tarihleri olan atanmış insan sahipleri olmalıdır. Süresiz servis hesabı olmaz. Sahip rol değiştirdiğinde, hesap yeniden sahiplenilene kadar dondurulur.
• Sadece hesabı değil, insanı loglayın. Bir batch servis hesabı altında çalışıyorsa, tetikleyici (planlı, manuel veya API) insan kimliğini pipeline log'una taşımalıdır. Aksi takdirde adli cevabınız her zaman "servis hesabı yaptı" olur.
• Düzenleyici açıdan kritik gruplardaki grup üyeliği değişikliklerini değişiklik kontrolü olaylarıyla eş tutun. Talep oluşturmalı, onay gerektirmeli ve kod dağıtımlarıyla aynı değişiklik logunda görünür olmalıdır.
• SoD matrisini gerçek grup üyeliğiyle aylık olarak mutabık kılın. Yıllık değil. Birinci ay ile on ikinci ay arasındaki sapma, tüm bulguların yaşadığı yerdir.

Bunların hiçbiri teknik olarak zor değildir. Organizasyonel olarak zordur, çünkü uyum, BT ve veri ekibinin erişimin bir altyapı meselesi değil, bildirim-kapsamlı bir mesele olduğunda anlaşmasını gerektirir.

Rahatsız Edici Kısım

Bu sorunun sürmesinin sebebi, denetçi gelene kadar kimsenin sahiplenmemesidir. Pipeline'ın sahibi veri ekibidir. AD'nin sahibi BT'dir. Bildirimin sahibi uyumdur. Erişim ise üçünün arasındaki dikişte oturur ve denetim bulguları dikişlerde ürer.

Bugün bir BES pipeline'ının sahibiyseniz ve son on iki ay içindeki herhangi bir tarihte FATCA ile ilgili alanları değiştirmeye kimin yetkili olduğunun imzalı listesini otuz dakika içinde çıkaramıyorsanız, bulgu çoktan yazılmıştır. Denetçi sadece henüz ziyaret etmemiştir.