Veri ihlalleri neden tekrarlıyor: kimlik katmanı ve toplanan veri

2026, ihlallerin tekrarladığı yıl

Yılın başından bu yana tek bir gruba, ShinyHunters adıyla anılan bir oluşuma, üç yüzü aşkın kurumun ihlali atfedildi. Eğitim teknolojisinden telekomünikasyona, oyun sektöründen kamu kurumlarına kadar uzanan bir liste. Bunların içinde belki de en çarpıcı örnek, milyonlarca öğrenci ve eğitmenin kullandığı Canvas öğrenme platformunu işleten Instructure oldu: şirket sekiz ay içinde ikinci kez hedef alındı.

Mayıs 2026'daki ikinci olayda saldırganlar 275 milyona yakın kişiye ait kaydı ele geçirdiklerini öne sürdü; yaklaşık 330 kurumun giriş ekranı, "öde ya da sızdırırız" mesajlarıyla tahrif edildi. Senaryo tanıdık: bir son tarih konur, tarih yaklaşınca uzatılır ve baskı, kurum masaya oturana kadar artar. Bu tek bir kurumun talihsizliği değil; 2026 boyunca tekrar eden bir kalıp.

Asıl kapı kimlik katmanında açılıyor

Bu olaylara "hack" demek çoğu zaman yanıltıcı. Saldırganların kullandığı yöntemlerin büyük kısmı, yazılımdaki bir açıktan çok, kimliğe duyulan güveni hedefliyor. 2026 dalgasında öne çıkan birkaç tekrarlayan teknik var:

Vishing ve sahte onay ekranları

Saldırgan, BT destek ekibinden arıyormuş gibi bir çalışanı telefonla arıyor — buna vishing denir — ve onu sahte bir oturum açma ya da uygulama izni ekranına yönlendiriyor. Çalışan iyi niyetle onayı verdiğinde, saldırgan parolayı hiç görmeden geçerli bir oturuma sahip oluyor. Çoğu durumda iş bununla da bitmiyor: ele geçirilen hesaba kendi MFA cihazını kaydederek kalıcı bir erişim kuruyor.

Yanlış yapılandırılmış SaaS izinleri

İkinci kalıp ise hiç insan kandırmayı gerektirmiyor. Saldırganlar, herkese açık bulut uygulamalarını otomatik olarak tarayıp aşırı geniş yetki verilmiş "misafir" kullanıcı profilleri arıyor. Yanlış yapılandırılmış tek bir izin, kimlik doğrulaması bile gerektirmeden bütün bir veri tabanının kapısını aralayabiliyor.

Çalınan token'lar ve domino etkisi

En sinsi nokta burası. Modern kurumlar onlarca bulut uygulamasını birbirine OAuth ile bağlıyor; bir uygulamanın diğerine erişmesini sağlayan bu izinler birer token ile taşınıyor. Saldırgan üçüncü taraf bir entegrasyondan tek bir token çaldığında, o token'ın eriştiği her sisteme aynı anda uzanabiliyor. Tek bir zayıf halka, tüm zincire yayılan bir domino etkisine dönüşüyor. Bu yüzden artık çevreyi koruyan duvar değil, kimlik katmanının kendisi asıl sınır.

[ çalınan token ]
     │
     ├─▶ CRM            # müşteri kayıtları
     ├─▶ veri ambarı    # geçmiş tüm veri
     ├─▶ e-posta        # yazışmalar
     └─▶ dosya deposu   # yedekler dâhil

Fidye ödemek hikâyeyi bitirmiyor

Bu olayların çoğu bir "öde ya da sızdır" pazarlığına dönüşüyor ve baskı altındaki kurumlar kimi zaman ödüyor. Ne yazık ki ödemek, çoğu zaman sonun değil yeni bir başlangıcın işareti. Daha önceki örneklerde, kurum fidyeyi ödedikten sonra bile bireysel kullanıcılar ayrı ayrı şantajla tehdit edildi. Verisi bir kez kopyalanmış birinin elindeki kopyayı "geri almak" mümkün değil; ödeme, yalnızca o veriyi elinde tutan kişinin sözüne güvenmek demek.

Aynı kurumun kısa sürede yeniden vurulması da tesadüf değil. İlk ihlalde toplanan bilgi — kim kimdir, hangi sistem nasıl çalışır — ikinci saldırı için hazır bir harita oluşturuyor. Bir kez içeri girilen kapı, kapatılmazsa ikinci kez davet ediyor.

Asıl ders: az veri, dar yetki

Bütün bu olayları yan yana koyunca öne çıkan sonuç şaşırtıcı derecede sade: güvenlik, satın alınıp bir köşeye konan bir ürün değil, sürekli bakım isteyen bir alışkanlık. Ve en güçlü savunma çoğu zaman en az konuşulan yerde duruyor — hiç toplanmamış veri. Sızdırılamayacak tek kayıt, baştan tutulmamış kayıttır.

Bir kurumun yıllardır "belki lazım olur" diye sakladığı veriler, bir ihlal anında en büyük yükümlülüğe dönüşür. Güvenlik dünyasında son yıllarda giderek daha yüksek sesle dile getirilen ilke de tam olarak bu: veri minimizasyonu. Bir veriyi toplamadan önce "bunu gerçekten saklamak zorunda mıyız?" diye sormak, kısıtlayıcı bir kural değil; gürültüyü azaltan, hem güvenliği hem de bakımı kolaylaştıran bir tasarım tercihi.

İkinci nokta, kimliği ciddiye almak. Parolaların ötesinde, hangi uygulamanın hangi uygulamaya neden eriştiğini bilmek; bağlı entegrasyonları, OAuth izinlerini ve "geçici" diye verilip unutulan yetkileri düzenli olarak gözden geçirmek. Bir token'ın eriştiği alanı dar tutmak, çalındığında yaratacağı zararı da dar tutar. Dalga boyunca tekrar tekrar görülen şey bunu doğruluyor: kapıyı açan, kırılan bir kilit değil, fazla geniş verilmiş bir anahtardı.

Kurumunuz için sade bir başlangıç

• Tuttuğunuz veriyi sadeleştirin — gerçekten ihtiyaç duymadığınız kayıtları silin, yeni veriyi toplamadan önce gerekliliğini sorun.
• Bağlı uygulamaları gözden geçirin — OAuth izinlerini ve üçüncü taraf entegrasyonları düzenli denetleyin, kullanılmayanları kaldırın.
• Kimlik doğrulamayı dirençli kılın — oltalamaya dayanıklı MFA kullanın ve yeni cihaz kaydı gibi değişiklikleri izleyin.
• En az yetki ilkesini uygulayın — her hesap ve token yalnızca işini yapacak kadar erişime sahip olsun, "her ihtimale karşı" geniş yetkiden kaçının.

Özetle

2026'nın ihlal dalgası bize yeni bir tehdit değil, eski bir gerçeği hatırlatıyor: saldırganlar en zoru değil, en kolayı seçer — ve en kolayı genellikle açık bırakılmış bir kimlik ya da gereksiz yere saklanmış bir yığın veridir. Mükemmel bir kale kurmak yerine, korunması gereken yüzeyi küçültmek çoğu zaman daha sağlam bir yoldur.

Bu konuların teknik temeline daha yakından bakmak isterseniz — kimlik ve erişim yönetimi, oturum güvenliği, en az yetki ilkesi — Bilgi Merkezi · Kimlik ve Erişim ile Web Uygulama Güvenliği rehberlerine göz atabilirsiniz.