Çok faktörlü kimlik doğrulama neden Fransız veri sızıntıları dalgasını engelleyemedi

2025 yazından itibaren Fransız kuruluşlarını vuran bir dizi veri sızıntısı rahatsız edici bir ortak özellik taşıyordu: Teknik bir güvenlik açığı tespit edilmemişti; geçerli bir hesap sadece giriş yapıp on binlerce, hatta yüz binlerce kaydı okumuştu. Bu gözlem, dev.to'da yazan Jules Robineau'dan geliyor ve Robineau bu olayları, çok faktörlü kimlik doğrulamanın (MFA) bu tür ihlaller için yanlış soruya cevap verdiği argümanını desteklemek için kullanıyor. MFA kapıdaki kişinin kim olduğunu doğrular ama ne kadar veri dışarı çıkardığı konusunda hiçbir şey söylemez.

Aktarılan olaylar

Gönderiye göre örnek teşkil eden vakalar arasında, Temmuz 2025 sonrasında etkilenen araçta iki faktörlü kimlik doğrulamayı hızlandırma taahhüdünde bulunan France Travail, SFR ve Fransız vergi idaresindeki bir sızıntı var; vergi idaresi 2026 sonuna kadar tüm personel için daha güçlü kimlik doğrulama planlayarak yanıt verdi. Robineau, 31 Ekim 2026 itibarıyla aldığı anlık görüntüyü kuruluşların açıklamaları ile üçüncü taraf anlatıları birbirinden ayırıyor ve vakaların hepsinin aynı saldırı yolunu kanıtlamadığı konusunda uyarıyor.

Aralık 2025'teki bir vaka öne çıkıyor: Saldırganın gerçek bir hesabın haklarını taşıyan iki yeni hesap oluşturduğu bildirildi. Gönderide belirtildiği gibi, MFA giriş yapan kişiyi kontrol eder, bir hesabın zaten var olup olmaması gerektiğini değil.

MFA sızıntıyı neden durdurmuyor

Robineau, bir hesabın kimlik doğrulamayı geçtiği veya atlatığı ama yine de anormal hacimlerde veri çıkardığı üç durum tespit ediyor:

• Kimlik bilgisi çalan kötü amaçlı yazılım, MFA'dan zaten geçmiş tarayıcı oturum cookie'lerini ele geçirerek saldırgana tamamen doğrulanmış bir oturum sunabilir.
• Hesap oluşturma iznine sahip bir hesap, Aralık 2025 vakasında olduğu gibi, ek ayrıcalıklı erişim yaratabilir.
• Tamamen meşru bir hesap, kötü ayarlanmış bir script veya hatalı bir export işlemiyle normal etkinliğinin gerektirdiğinden çok daha fazlasını okuyabilir.

Üç senaryoda da her bir isteğin tek başına bakıldığında sıradan görünmesi sorunu var: Hesap giriş yapmış, gerekli izne sahip ve uygulama cevap veriyor. Kimsenin sormadığı soru şu: Kaç kayıt dışarı çıktı?

İsteğe göre yetkilendirmenin hafızası yoktur

İki baskın yetkilendirme modeli olan rol tabanlı erişim kontrolü (RBAC) ve öznitelik tabanlı erişim kontrolü (ABAC), aynı anda tek bir isteği değerlendirir. Her iki tür sistemi de kurduğunu söyleyen Robineau, klasik bir izin kuralının önceki cevapların kaydını tutmadığına dikkat çekiyor. Bir hesabın tüm bir dizini okumasına izin veriliyorsa, kural gönderideki örnekte 62.848 kez evet diyecektir ve her bir cevap teknik olarak doğrudur.

Önerilen çözüm: önce dar kapsam, sonra okuma bütçesi

Gönderi, herhangi bir şey saymaya çalışmadan önce bir hesabın neleri görebileceğini daraltmayı öneriyor. Her şeyi okuyabilen bir hesap, her kimlik bilgisi hırsızlığını tam bir sızıntıya dönüştürür. Somut olarak:

• Her hesabı kendi veri dilimle sınırlandırın; böylece bir satış temsilcisi tüm şirketinkini değil, kendi müşterilerini görür.

• Hesap oluşturma hakkını ayrı ayrı izlenen bir izin olarak ele alın.

• API sayfa boyutunu sınırlayın; çünkü 100.000 kayıt limitini kabul eden bir endpoint fiilen bir export aracıdır.

• Toplu export'u olağan ekran okumalarından farklı, ayrı bir izin yapın.

• Dahili araçlara, birkaç görümle sınırlı salt-okunur veritabanı hesapları verin.

Bunların üzerine Robineau bir okuma bütçesi öneriyor: Bir hesabın saat başına okuyabileceği kayıt sayısı için bir üst sınır; bu sınıra ulaşılınca uygulama daha fazla okumayı reddeder ve birini uyarır. Bütçenin istekleri değil kayıtları sayması gerektiğini vurguluyor; çünkü dakika başına çağrı sayan geleneksel bir rate limiter, 10.000 kayıt döndüren tek bir çağrıya memnuniyetle izin verecektir. Ayrıca vergi sızıntısından sonra Fransız hükümetinin de her yerde uygulanan erişim kotaları fikrini gündeme getirdiğini belirtiyor.

Gönderideki kısa bir Go middleware örneği mekanizmayı taslaklıyor: hesap kimliği kimlik doğrulama katmanından gelir ve asla bir istek parametresinden gelmez, her istek bütçeden en fazla 100 kayıt rezerve eder ve bütçeyi aşan istek HTTP 429 cevabı ve loglanmış bir uyarı alır. Doğrulanan limit daha sonra ham sorgu dizisinden yeniden okunmak yerine doğrudan SQL sorgusuna aktarılır.

Neden önemli

Güvenlik harcamalarının çoğu ön kapıya gidiyor; oysa bu sızıntılar ön kapı doğru şekilde açıldıktan sonra gerçekleşti. MFA çalınmış parolalara karşı en iyi savunma olmaya devam ediyor ve etkilenen kuruluşların onu kullanmaya karar vermeleri doğruydu; ama yıkım yarıçapını ancak kapsam sınırları ve hacim kontrolleriyle eşleştiğinde daraltıyor. Müşteri kayıtları tutan herhangi bir web servisi, back office veya API için pratik ders şudur: Bir oturumun er geç çalınacağını varsayın ve zararın sınırlı kalacağı şekilde tasarlayın. İstek başına rate limiting yaygın bir mühendislik pratiğidir; fiilen döndürülen kayıtları saymak ise nadirdir ve sızan şey tam olarak kayıtlardır.