Dark Web'de Bilgilerim Satılıyor mu? Sızıntı Kontrolü ve İlk 72 Saat

Bilgilerinizin dark web'de satılıp satılmadığını merak eden çoğu kişi bir arama kutusuna e-posta adresini yazıyor, sonuç ya yeşil bir onay ya kırmızı bir uyarı oluyor ve iş orada bitiyor. Oysa o ekranın söylediği tek şey, adresinizin bir dökümde geçtiği. Geçmişte kalmış bir dökümde adresin bulunması ile bugün birinin elinde çalışan bir parolanızın olması arasında, o bilginin ucuz bir işlemle paraya çevrilmesine yetecek kadar mesafe var. Bu rehber o mesafeyi ölçüyor: hangi veri sınıfı hangi kapıyı açıyor, açılan kapının kapatılma süresi ne, ve kapatma işinin hangi adımı ilk sırada olmalı.

Kısa cevap şu: bir sızıntının size maliyeti, dökümün boyutuyla değil, içindeki hangi alanın hâlâ geçerli olduğuyla ölçülür. 4,5 milyon satırlık bir dökümün %64'ü okunabilir parola içeriyorsa ve o parolaların yalnızca dörtte biri bugün bir yerde çalışıyorsa, gerçek tehlike 4,5 milyon değil, yaklaşık 273 bin kayıttır. Geri kalanı gürültü. Bu yazı o ayrımı yapmayı, sonra da ayrımı 30 günlük kişisel ve 90 günlük kurumsal bir plana çevirmeyi anlatıyor. Hukuki taraf ayrı bir bölümde: 6698 sayılı Kanun'un 12. maddesi, Kişisel Verileri Koruma Kurulu'nun 2019/10 sayılı kararı, TCK 135 ve 136 ile 5651 sayılı Kanun'un 9. maddesi.

Sızıntı kontrolü neyi ölçer, neyi ölçmez

Bir sızıntı kontrol servisinin yaptığı iş teknik olarak basit: elindeki döküm arşivinde sizin adresinizi arıyor. Bu arşivler halka açılmış, forumlarda paylaşılmış veya satılmış veri setlerinden oluşuyor. Yani kontrolün kapsamı geçmişte kamuya düşmüş olanla sınırlı. Kimsenin yayınlamadığı bir ihlali hiçbir kontrol motoru gösteremez; satıcının elinde dolaşan ama henüz yayınlanmamış bir dökümü de gösteremez.

Bundan iki sonuç çıkıyor ve ikisi de pratik. Birincisi, temiz sonuç güvenli olduğunuz anlamına gelmiyor; "bu adres bilinen ihlallerde bulunamadı" cümlesi, "bu adresin parolası kimsenin elinde değil" cümlesi değil. İkincisi, aynı adres için iki farklı kontrol farklı sayı gösterebilir, çünkü arşivler farklı. Bu yüzden "12 ihlal bulundu" gibi bir sayı bir teşhis değil, bir envanter satırı. Teşhis için o ihlallerin hangi veri sınıfını içerdiğine bakmak gerekiyor.

Kontrolün gösterdiği	Gerçekte söylediği	Ne yapılabilir
Adresiniz bir dökümde geçiyor	Geçmişte bir yerde kayıt olmuşsunuz ve o yer sızdırmış	Dökümün tarihini ve içerdiği alanları öğrenin
Parola alanı düz metin	O parola bugün bir yerde hâlâ geçerli olabilir	Önce o parolayı kullandığınız her yerde değiştirin
Parola alanı hash	Parola kırılabilir ama hemen değil	Zayıf hash ise değişikliği ertelemeyin
Telefon veya kimlik numarası var	Kimlik avı ve SIM swap hedefi olursunuz	Operatör tarafında hat güvenliği ve SIM swap kilidi
Hiç sonuç yok	Bilinen kamuya açık dökümlerde yoksunuz	Yine de parola hijyeni ve iki adımlı doğrulama gerekli

Tablonun son satırı en çok yanlış anlaşılan satır. Kontrolün boş dönmesi bir başarı değil, bir bilgi eksikliği. Aynı mantık ters yönde de geçerli: on yıl önce kapatılmış bir forumdan gelen kayıt bugünkü riskinizi neredeyse hiç değiştirmez; aynı adresle hâlâ bir yere giriş yapıyorsanız değiştirir. Yani sorulacak soru "sızdı mı" değil, "sızan şey bugün hâlâ bir kapıyı açıyor mu".

Dört sızıntı, dört ayrı saat: veri sınıfına göre triyaj

Bir ihlal bildirimi geldiğinde ya da bir kontrol sonucu gördüğünüzde yapılacak ilk iş sızan veriyi sınıflandırmak olmalı; çünkü her sınıfın yarı ömrü farklı. Bir parola değiştirildiği anda ölür. Bir oturum çerezi, parola değiştirilse bile yaşamaya devam eder. Bir API anahtarı siz iptal edene kadar çalışır. Bir kimlik numarası veya doğum tarihi ise hiç ölmez, sadece kullanım biçimi değişir. Bu yüzden "önce şifreyi değiştir" tavsiyesi, sızıntının türüne göre bazen doğru, bazen tamamen boşa giden bir adım oluyor.

Veri sınıfı	Yarı ömrü	Doğru ilk adım	Süre
Düz metin parola	Siz değiştirene kadar	O parolayı kullandığınız tüm hesaplarda değiştir, aynı parolayı tekrar kullanma	Aynı gün
Zayıf hash (tuzsuz MD5, SHA1)	Günler, kırılma hızına bağlı	Parolayı değiştir, hash'in kırıldığını varsay	24 saat
Güçlü hash (Argon2, bcrypt, tuzlu)	Aylar, hedefli kırma gerekir	Değiştir ama panik yapma; asıl risk başka alandadır	7 gün
Oturum çerezi / erişim belirteci	Belirtecin süresi dolana kadar, parola değişse de	Tüm oturumları sunucu tarafında iptal et	Dakikalar
API anahtarı, servis hesabı	Siz iptal edene kadar, süresiz olabilir	Anahtarı döndür, kullanım kaydını incele	Dakikalar
Telefon, T.C. kimlik no, adres	Kalıcı	SIM swap kilidi, kimlik avı farkındalığı, kredi izleme	Günler
Kart bilgisi	Kart kapanana kadar	Kartı kapat, yeni kart çıkar, abonelik envanterini güncelle	Aynı gün
CV, sağlık, bordro	Kalıcı, özel nitelikli veri olabilir	Veri sorumlusu bildirimi, KVKK 12/5 değerlendirmesi	72 saat

Bu tabloyu bir kez okuyup akılda tutmak yetmiyor, çünkü acil durumda insan tabloyu değil refleksi uyguluyor. Refleks ise genellikle "her yerde şifre değiştir" oluyor. O refleksin nerede işe yarayıp nerede boşa gittiğini görmek için sıradaki iki bölüm gerekli: bir dökümün hangi kısmı gerçekten kullanılabilir hale geliyor, ve bir parola değişikliği hangi erişimi kesmiyor.

Dökümden hesap devralmaya: dönüşüm modeli

Döküm satın alan birinin yaptığı iş, bir listeyi baştan sona denemek değil. Önce listeyi kullanılabilir hale getiriyor. Bu adımın ne kadar iş çıkardığını görmek için 4,5 milyon satırlık tipik bir dökümü katmanlarına ayıralım. Varsayımlar açık: kayıtların %38'i düz metin, %33'ü tuzsuz zayıf hash, %29'u tuzlu ve yavaş hash. Zayıf hash'lerin %78'i kırılıyor, güçlü hash'lerin %2'si. Bu varsayımlarla okunabilir hale gelen satır sayısı 2.894.400, yani dökümün %64,3'ü.

Aşama	Kalan kayıt	Dökümün yüzdesi	Ne oldu
Ham döküm	4.500.000	%100	Satıcının elindeki liste
Okunabilir parola	2.894.400	%64,3	Düz metin + kırılmış zayıf hash
Hâlâ geçerli	1.186.704	%26,4	Hesap açık ve parola değiştirilmemiş
Başka kapıyı da açıyor	272.942	%6,1	Aynı parola iş hesabında veya başka serviste de kullanılıyor

Bu dört satır, sızıntı haberlerindeki sayıların neden sürekli abartılı göründüğünü de açıklıyor. "1 milyar parola sızdı" başlığı doğru olabilir, ama o milyarın içinde sizin işinize yarayan kısım yüzde altı. Öte yandan aynı tablo savunma tarafına da bir şey söylüyor: elinizdeki 4,5 milyon satırın %6'sı gerçek riskse, 380 kişilik bir kurumda bu riskin kaç kişiye denk geldiği hesaplanabilir. Kurumun çalışan sayısı çarpı yeniden kullanım oranı çarpı geçerlilik oranı: 380 × 0,23 × 0,41 ≈ 36 hesap. Yani bir kurumda her an, çalışan bir parolası kamuya açık bir dökümde duran yaklaşık otuz altı hesap var. Bu sayı bir ihtimal değil, bir envanter tahmini.

Aynı hesabı maliyete çevirelim. Bir hesabın devralınması destek tarafında yaklaşık dokuz dakika iş demek: parola sıfırlama, oturum temizliği, kullanıcıya doğrulama, kayıt tutma. Yüklü saat maliyeti 420 TL varsayımıyla hesap başına 63 TL, otuz altı hesap için 2.268 TL. Buna devralınan hesapların %12'sinde görülen zorla kurtarma ve ödeme itirazı kalemi eklenince (kalem başına 1.850 TL) toplam 10.260 TL'ye çıkıyor. Bu rakam bir felaket senaryosu değil, sıradan bir kötü haftanın faturası. Ve karşılaştırma için: aynı 380 hesabın tamamının parolasını zorunlu sıfırlamanın iş yükü 38 saat, yani 15.960 TL. Yani kaza çıktıktan sonra temizlemek, işi baştan yapmaktan ucuz görünüyor; görünüyor, çünkü henüz ölçmediğimiz kalem var. Devralınan hesabın içinden giden posta, o postadan çıkan fatura ve müşteriye giden bildirim o hesaba dahil değil. Ölçümün sınırını bilmek, ölçümün kendisi kadar önemli.

"Şifreni değiştir" neden yanlış ilk adım

Bir parola değişikliğinin ne yaptığı konusunda yaygın bir yanlış anlama var: sanılıyor ki parola değişince hesaba açılmış bütün kapılar kapanır. Kapanmıyor. Parola bir kapıdır, oturum başka bir kapıdır. Tarayıcıya bırakılmış bir oturum çerezi, sunucuda geçerli olduğu sürece paroladan bağımsız çalışır; çünkü sunucu her istekte parolayı değil çerezi doğrular. Aynı şey mobil uygulamaların yenileme belirteçleri, e-posta istemcilerinin OAuth belirteçleri ve entegrasyonların API anahtarları için geçerli.

Ele geçen şey	Parola değişikliği keser mi	Ne keser	Ölçülen pencere
Parola	Evet	Yeni giriş denemesini	Anında
Oturum çerezi	Hayır	Sunucu tarafında oturum iptali	Çerez ömrü boyunca (30 güne kadar)
Yenileme belirteci	Hayır	Belirteç ailesinin tamamının iptali	Belirteç ömrü boyunca (aylar olabilir)
Uygulama parolası	Hayır	Tek tek uygulama parolası iptali	Süresiz
API anahtarı	Hayır	Anahtar rotasyonu	Süresiz
Kurtarma e-postası	Hayır	Kurtarma adresinin değiştirilmesi	Süresiz

Bu tablonun pratik anlamı şu: bir hesabın ele geçirildiğini öğrendiğinizde sıra "oturumları kapat, sonra parola, sonra kurtarma bilgisi" olmalı. Ters sıra, kapıyı kilitleyip pencereden girmeye devam eden birine kapıyı göstermek gibi. Ölçüsü de var: bir çalışanın ortalama yedi açık oturumu varsa ve siz yalnızca parolayı değiştirdiyseniz, saldırganın elindeki çerez o yedi oturumdan biriyse hiçbir şey kesmediniz; oturumları da kapattıysanız yedi kapının yedisini de kapattınız. Aynı işlem, iki farklı sonuç, aradaki fark tek bir düğme.

Bu yüzden "şifreni değiştir" tavsiyesi sızıntı türüne göre değerlendirilmeli. Dökümde düz metin parola varsa ve saldırgan henüz giriş yapmadıysa parola değişikliği doğru ilk adım. Ama bir oturum çerezi veya API anahtarı sızdıysa, parola değişikliği yalnızca sizi rahatlatır, saldırganı durdurmaz. İkisini ayırt etmenin tek yolu, ihlalin hangi alanı içerdiğini öğrenmek. Bunu öğrenemediğinizde en güvenli varsayım, ikisinin de sızdığını kabul edip her iki kapıyı da kapatmak.

Hangi hash ne kadar dayanır

"Parola hash'lendi, güvende" cümlesi tek başına bir şey söylemiyor; çünkü hash'ler arasında kırılma süresi açısından yüz binlerce kat fark var. Farkı görmek için sekiz karakterlik, 62 karakterlik alfabeden rastgele üretilmiş bir parolayı alalım: olasılık uzayı 2,18 × 10^14. Aynı donanımda tuzsuz MD5 saniyede yaklaşık 10 milyar deneme yapabiliyor; bütün uzayı taramak 21.834 saniye, yani altı saat. SHA1 ile bu süre 31.191 saniye, yaklaşık dokuz saat. Tuzlu ve yavaş bir hash'te ise aynı iş 5.770 yıl ile 8.654 yıl arasına çıkıyor.

Hash türü	Yaklaşık hız	8 karakter rastgele parolayı kırma süresi	Sızıntı sonrası karar
Tuzsuz MD5	Saniyede ~10 milyar	~6 saat	Parolayı bugün değiştir; kırıldığını varsay
Tuzsuz SHA1	Saniyede ~7 milyar	~9 saat	Aynı gün değiştir
bcrypt, cost 12	Saniyede ~1.200	~5.770 yıl	Kırılma olasılığı düşük; asıl risk başka alanda
Argon2id, yüksek maliyet	Saniyede ~800	~8.654 yıl	Parola değil, oturum ve erişim hedeflenir

Bu tablonun asıl dersi, hash güçlüyse sızıntının önemsiz olduğu değil; riskin yer değiştirdiği. Bir saldırgan güçlü hash'lerle dolu bir dökümle uğraşmak yerine aynı kurumdaki daha zayıf bir kapıyı arıyor: süresi dolmayan bir oturum, ayrılmış çalışanın silinmemiş uygulama parolası, kapatılmamış bir servis hesabı. Yani hash güçlendirmek gerekli ama yeterli değil; parola tarafını sağlamlaştırıp erişim tarafını unutmak, kilidi değiştirip anahtarı kapının altında bırakmaya benziyor. Bu yüzden üçüncü bölümdeki tablo, sızıntının türüne göre ilk adımı belirliyor ve hash satırı ile oturum satırını ayrı ayrı ele alıyor.

Bir de parola uzunluğunun etkisi var; çünkü uzunluk, karmaşıklıktan daha çok iş yapıyor. Sekiz karakterden on ikiye çıkmak olasılık uzayını 2,18 × 10^14'ten 3,23 × 10^21'e taşıyor, yani yaklaşık on beş milyon kat. Aynı artışı büyük harf ve simge ekleyerek elde etmek mümkün değil. Kurumsal parola politikasını "en az bir büyük harf, bir simge" listesinden "en az 14 karakter, sızdırılmış listede olmayan" kuralına çevirmek, hem kullanıcı için daha az sinir bozucu hem de ölçülebilir biçimde daha etkili.

Ücretsiz kontrol motorlarının kör noktası

Ücretsiz kontroller işe yaramaz değil, sadece dar. Yaptıkları şey kamuya açılmış arşivlerde arama yapmak; yapmadıkları şey, henüz yayınlanmamış bir dökümün sizin kurumunuza ait satırlarını görmek. Bu ayrımı bir ürün karşılaştırmasına çevirmek yerine bir soru listesine çevirmek daha faydalı, çünkü her satıcının cevabı kendi ürününü anlatıyor. Aşağıdaki sorular bir sızıntı izleme hizmetini değerlendirirken sorulacak sorular; cevapları da bir ürünün ne yapıp ne yapamayacağını gösteriyor.

Soru	Zayıf cevap	Ölçülebilir cevap
Hangi kaynakları izliyorsunuz?	"Dark web'in tamamını"	İsimlendirilmiş kaynak listesi: forum, pazar yeri, paste sitesi, kod deposu, tedarikçi sızıntı beslemeleri
Uyarı ne kadar sürede geliyor?	"Anında"	Kaynağa göre ortalama gecikme; ölçüm tarihi ve örneklem
Ne bildiriyorsunuz?	"İhlal tespit edildi"	Hangi alan: parola, hash, çerez, kimlik no, kart; hangi tarihli döküm
Şüpheli kayıtları ayıklıyor musunuz?	"Hepsini bildiriyoruz"	Doğrulama oranı ve yanlış pozitif yüzdesi
Uyarı geldikten sonra ne oluyor?	"Panelde görürsünüz"	Rotasyon adımları, sahiplik ataması, kapanış kanıtı

Bu tablodaki en kritik satır ikincisi. Bir sızıntı izleme ürününün sattığı şey tespit değil, gecikme farkı. Aynı olayı 30 gün sonra öğrenmekle 1 gün sonra öğrenmek arasındaki fark 720 saat; o 720 saatte parolanın değişip değişmemesi, olayın bir uyarı mı yoksa bir ihlal mi olduğunu belirliyor. Yani satın aldığınız şey bir sigorta değil, bir zaman dilimi. Bunu bilerek satın almak ile "dark web izleme" başlığına para vermek arasındaki fark, sonradan hayal kırıklığı oluyor.

Ücretsiz araçların kurumsal tarafta ikinci bir kör noktası var: çalışanların kişisel adresleriyle kayıt olduğu servisler. Kurumsal izleme genellikle şirket alan adını izler; oysa bir çalışanın kişisel e-posta hesabıyla bir pazarlama aracına kaydolup şirket verisine eriştiği durumlarda sızıntı, şirket alan adında değil kişisel adreste görünür. Bu yüzden izleme kapsamını belirlerken "hangi adresler" sorusu "hangi alan adı" sorusundan daha önemli. Kapsamı daraltan kurumlar, panelde temiz bir ekran görüp gerçek sızıntıyı kaçırıyor.

Kurumsal taraf: tedarikçi sızıntısından kendi kiracınıza

Kurumsal sızıntıların çoğu kendi sisteminizden değil, sizin adınıza veri tutan bir tedarikçiden geliyor: İK platformu, muhasebe yazılımı, e-ticaret altyapısı, çağrı merkezi, kargo entegrasyonu. Bu durumda iki iş aynı anda yapılmalı: tedarikçiyle hukuki süreç, ve kendi kiracınızda kimlik bilgisi sayımı. İkincisi genellikle atlanıyor, oysa asıl operasyonel risk orada.

Kimlik bilgisi sayımı (credential census) şu soruyla başlıyor: kiracımızdaki kaç hesap, başka bir yerde kullanılan bir parolayla korunuyor? Bu soruyu doğrudan cevaplayamazsınız, çünkü parolaları okuyamazsınız; ama dolaylı cevaplayabilirsiniz. Parola politikası, sızdırılmış parola listesine karşı kontrol, MFA kapsamı ve son 12 ayda kaç hesabın sıfırlandığı verisi birleştiğinde bir oran çıkıyor. 380 hesaplı bir kiracıda MFA kapsamı %61 ise 148 hesap tek faktörle korunuyor demek. Bu 148 hesap, parola püskürtme saldırısının hedef kümesi.

Ölçüm	Değer	Nasıl okunur
Hesap sayısı	380	Kapsam
MFA kapsamı	%61	148 hesap tek faktör
Yeniden kullanım oranı	%23	87 hesapta başka yerde geçen parola olabilir
Dökümde geçerli olma oranı	%41	Yaklaşık 36 hesap gerçekten açık
Kilitleme eşiği	5 başarısız deneme	Saldırganın hesap başına deneme bütçesi

Bu tablodan çıkan saldırı hesabı şöyle: tek faktörlü 148 hesap, hesap başına günde dört deneme (kilitleme eşiğinin altında kalmak için) 592 deneme demek; 30 günde 17.760 deneme. Dökümden seçilen bir parolanın bu popülasyonda tutma olasılığı %2,1 ile %3,4 arasında varsayıldığında, tek bir parola denemesi turu başına 3 ile 5 hesap açılıyor. Yani saldırganın bir parolayı denemesi, onu yakalatmadan birkaç hesap kazandırıyor. Savunmanın yapabileceği en etkili şey bu aritmetiği bozmak: MFA kapsamını yükseltmek, sızdırılmış parola listesini giriş anında kontrol etmek, ve oturum sürelerini kısaltmak.

Rotasyon sırası da ölçülebilir bir karar. Bir sızıntı sonrası ilk 24 saatte sırayla şunlar dönmeli: oturum belirteçleri ve uygulama parolaları, MFA kayıtları, sonra parolalar, en son API anahtarları. Bu sıra keyfi değil; yarı ömrü en uzun olan ve iptal edilmediğinde süresiz çalışan şey önce kapatılmalı. API anahtarlarını sona bırakmanın tek gerekçesi, döndürmenin entegrasyon kırması olabilir; o zaman da döndürme tarihini takvime yazmak zorunlu, çünkü ertelenen anahtar pratikte hiç döndürülmüyor.

Bir de tedarikçi tarafında sorulacak soru var: ihlali bize kaç saatte bildiriyorsunuz? Sözleşmede "makul sürede" yazan bir madde, 72 saatlik yasal saatin karşısında işe yaramıyor; çünkü sizin saatiniz tedarikçinin bildirimiyle başlıyor. Bu yüzden sözleşmeye saat cinsinden bir taahhüt, bildirim kanalı ve teknik temas kişisi yazmak gerekiyor. Tedarikçi riskinin hukuki ve operasyonel ayrıntıları ayrı bir rehberin konusu: tedarikçi risk rehberi.

72 saat: KVKK 12/5 ve Kurul 2019/10

Türkiye'de bir veri ihlalinin hukuki saati, ihlali öğrendiğiniz an başlıyor. 6698 sayılı Kanun'un 12. maddesinin beşinci fıkrası, işlenen kişisel verilerin kanuni olmayan yollarla başkaları tarafından elde edilmesi halinde veri sorumlusunun bu durumu en kısa sürede ilgilisine ve Kurula bildirmesini şart koşuyor. "En kısa süre" ifadesi 24.01.2019 tarih ve 2019/10 sayılı Kurul kararıyla 72 saat olarak yorumlandı: ihlali öğrendiğiniz andan itibaren gecikmeksizin ve en geç 72 saat içinde Kuruma bildirim. Aynı karar, etkilenen kişilere yapılacak bildirimin de makul en kısa sürede, iletişim adresi varsa doğrudan, yoksa veri sorumlusunun web sitesinde yayımlanması gibi uygun yöntemlerle yapılmasını öngörüyor.

Bu kural kâğıt üzerinde basit, uygulamada zor; çünkü 72 saatlik saat bir bildirim süresi değil, bir tespit süresi. Kurula "42.000 kayıtta ihlal oldu" demek yetmiyor; hangi veri alanları, hangi kişiler, hangi tarih aralığı ve hangi tedbirin alındığı soruluyor. Bu bilgilerin üretilmesi ise veritabanı sorgusuyla yapılır, elle değil. Aradaki farkı ölçelim: 42.000 kaydın etkilenen kısmını elle çıkarmak, kayıt başına 6 dakikayla 4.200 saat, yani 525 iş günü. Aynı çıkarım indeksli bir sorguyla iki saat. 72 saatlik saatte 6 saatlik tespit gecikmesi yaşandığında geriye 66 saat kalıyor; 42.000 kişiye bildirim yapmak zorunda kalırsanız kayıt başına 5,66 saniye düşüyor. Bu bütçe ancak otomatik şablon, hazır alıcı listesi ve önceden yazılmış metinle tutturulabiliyor.

Saat	Yapılması gereken	Kanıt
0-6	Sızıntının doğrulanması, kapsamın kabaca belirlenmesi, erişimin kesilmesi	Olay kaydı, zaman damgaları, alınan ilk tedbir
6-24	Etkilenen kişi ve veri alanlarının sorguyla çıkarılması	Sorgu metni, sonuç sayısı, sürüm
24-48	Kurul bildirim formunun doldurulması, tedarikçiyle yazışma	Form kopyası, gönderim kaydı
48-72	İlgili kişilere bildirim, iç iletişim, destek hattı	Gönderim listesi, şablon, yanıt kayıtları
72 sonrası	Kök neden analizi, tedbir planı, tekrar önleme	Rapor, sorumlu ataması, kapanış tarihi

Kurul kararları bu saatin nasıl denetlendiğini de gösteriyor. 2020/357 sayılı kararda veri güvenliğine yönelik teknik tedbirleri almayan bir sigorta şirketine 12. maddenin birinci fıkrası uyarınca 90.000 TL idari para cezası verilmiş; aynı kararda ihlalin 72 saat içinde bildirildiği ve ilgililere bildirim yapıldığı için 12/5 kapsamında işlem yapılmamasına karar verilmiş. 2019/352 sayılı banka kararında ise geç bildirim ayrıca cezalandırılmış: 12/5'e uymamaktan 30.000 TL, toplam 100.000 TL. 2021/154 sayılı kararda teknik ve idari tedbir eksikliği 150.000 TL ile sonuçlanmış, bildirimin 72 saat içinde yapılması ayrı bir ihlal doğurmamış. Bu üç kararın ortak mesajı şu: bildirim süresine uymak cezayı sıfırlamıyor, ama uymamak cezayı büyütüyor; tedbir eksikliği ise bildirimden bağımsız bir kalem.

Ceza tarafı: TCK 135, 136 ve 5651 md. 9

Veriyi sızdıran, satan veya yayan taraf için ayrı bir ceza rejimi var ve bu rejim sızıntı mağduru için bir kaldıraç. TCK 135, hukuka aykırı olarak kişisel verileri kaydeden kişiye bir yıldan üç yıla kadar hapis cezası öngörüyor; verinin siyasi, felsefi, dini görüş, ırk, sağlık, cinsel yaşam gibi nitelikli kategorilerde olması halinde ceza yarı oranında artırılıyor. TCK 136 ise kişisel verileri hukuka aykırı olarak bir başkasına veren, yayan veya ele geçiren kişiye iki yıldan dört yıla kadar hapis cezası veriyor. Bir dökümü satın alıp kullanmak, bir listeyi forumda paylaşmak veya bir hesabı ele geçirip içindeki veriyi almak bu iki maddenin kapsamına girebiliyor.

Fiil	Dayanak	Sonuç	Kim harekete geçer
Kişisel veriyi hukuka aykırı kaydetme	TCK 135	1-3 yıl hapis; nitelikli veride yarı oranında artırım	Cumhuriyet savcılığı, şikâyet üzerine
Veriyi verme, yayma, ele geçirme	TCK 136	2-4 yıl hapis	Cumhuriyet savcılığı
Veri sorumlusunun bildirim yükümlülüğü	KVKK 12/5, Kurul 2019/10	72 saat içinde Kurula ve ilgililere bildirim	Veri sorumlusu
Kişilik haklarının ihlali, içeriğin kaldırılması	5651 md. 9	İçerik sağlayıcıya başvuru; 24 saatte cevap, yerine getirilmezse 15 gün içinde sulh ceza hâkimi	İlgili kişi
Teknik tedbir eksikliği	KVKK 12/1, md. 18/1-b	İdari para cezası (kararlarda 90.000-150.000 TL bandı)	Kurul

5651 sayılı Kanun'un 9. maddesi, internette yayımlanan bir içerik yüzünden kişilik hakları ihlal edilen kişiye iki yol veriyor: içerik sağlayıcısına, ulaşılamıyorsa yer sağlayıcısına başvurarak uyarı yöntemiyle içeriğin kaldırılmasını istemek, ya da doğrudan sulh ceza hâkimine başvurmak. Süreler net: talep 24 saat içinde cevaplanır, cevaplanmazsa reddedilmiş sayılır ve 15 gün içinde sulh ceza hâkimine gidilir, hâkim üç gün içinde duruşmasız karar verir. Sızıntı mağduru için bu madde, adının ve verisinin yayınlandığı bir sayfanın kaldırılmasında pratik bir araç; ama tek başına yeterli değil, çünkü içerik kaldırılsa da kopyası başka yerde duruyor.

Bu hukuki çerçevenin pratik sonucu şu: sızıntı yönetimi bir teknik iş olduğu kadar bir kayıt tutma işi. Hangi tarihte ne öğrendiniz, hangi saatte hangi tedbiri aldınız, etkilenen kişi sayısını hangi sorguyla çıkardınız, kime ne zaman bildirdiniz. Bu dört kayıt olmadan 72 saatlik saati savunmak mümkün değil. Teknik tedbirlerin kanıt tarafını ayrı bir rehberde ayrıntılandırdık: KVKK teknik tedbirler ve kanıt rehberi.

Kişisel 30 gün planı

Sızıntı öğrenen bir kişinin yapacağı iş, panikle her hesabın parolasını değiştirmek değil, sıralı ve biten bir iş listesi çıkarmak. Aşağıdaki plan 30 güne yayılıyor çünkü ilk günün işi farklı, üçüncü günün işi farklı. Planın en önemli özelliği, her satırın bir çıktısı olması: yapıldı ya da yapılmadı, belirsiz kalmıyor.

Gün	İş	Çıktı
1	Öncelikli üç hesapta (e-posta, banka, iş) oturumları kapat, parolayı değiştir, kurtarma adresini kontrol et	Üç hesapta yeni parola ve doğrulanmış kurtarma
1	Posta kutusunda kural, yönlendirme ve uygulama parolası var mı bak	Tanımadığınız her kural silinmiş
2	Aynı parolayı kullandığınız diğer hesapları listele	Hesap listesi, her biri için değişim tarihi
3	Parola yöneticisi kur, tarayıcıda kayıtlı parolaları içeri aktar	Tek kasada 40-150 kimlik bilgisi
5	İki adımlı doğrulamayı uygulama tabanlı yönteme taşı, SMS'ten çık	En az beş hesapta uygulama tabanlı kod
7	Telefon hattında SIM swap kilidi ve operatör şifresi	Operatör kaydı ve kilit durumu
10	Sızan adresle kayıtlı eski hesapları kapat veya sil	Kapatılan hesap listesi
14	Kart ve abonelik envanterini gözden geçir, tanımadığın tahsilatı iptal et	Güncel abonelik listesi
21	İzleme kapsamını gözden geçir: hangi adresler, hangi bildirim kanalı	İzlenen adres listesi ve bildirim tercihi
30	Kalan hesaplarda parola tekrarını sıfırla, listeyi arşivle	Sıfır tekrar, tarihli kayıt

Bu planda 1. günün ikinci satırı en çok atlanan satır. Bir posta kutusuna kurulmuş yönlendirme kuralı, parola değiştirildikten sonra da çalışmaya devam eder; çünkü kural parolayla değil hesapla ilişkili. Aynı şey "uygulama parolası" için geçerli: eski bir cihaz için üretilmiş uygulama parolası, ana parola değişse bile posta okumaya devam eder. Bu iki kalemi kontrol etmeden yapılan bir parola değişikliği, kapıyı kilitleyip arka kapıyı açık bırakmak. Açık bir oturumun nasıl kapatılacağı ve hesabın nasıl geri alınacağı ayrı bir rehberde: hacklenen hesap nasıl kurtarılır.

Kurumsal 90 gün planı

Kurum tarafında sızıntı yönetimi bir olay müdahalesi değil, bir envanter disiplini. 90 günlük planın amacı, bir sonraki sızıntıda "hangi hesaplar etkilendi" sorusunun cevabını dakikalar içinde üretebilmek. Bunun için önce bugünkü durumu ölçmek, sonra ölçümü tekrarlanabilir hale getirmek gerekiyor.

Dönem	İş	Ölçüt
0-15 gün	Kimlik bilgisi envanteri: hesap sayısı, MFA kapsamı, servis hesabı listesi, API anahtarı sahipliği	Yazılı envanter, sahipsiz kalem sayısı
15-30 gün	MFA kapsamını yükselt; yönetici hesaplarında koşulsuz zorunlu hale getir	Yönetici hesaplarında %100 MFA
30-45 gün	Sızdırılmış parola kontrolünü giriş akışına ekle	Giriş denemelerinde engellenen eşleşme sayısı
45-60 gün	Oturum ömrünü kısalt, uzun ömürlü belirteçleri envanterle	Ortalama oturum ömrü, belirteç sayısı
60-75 gün	KVKK 72 saat tatbikatı: etkilenen kişi sorgusunu gerçek veriyle çalıştır	Sorgu süresi ve çıktı sayısı
75-90 gün	Tedarikçi bildirim maddelerini saat cinsinden güncelle, temas listesini doğrula	Sözleşme eki, doğrulanmış temas kişisi

60-75 gün arasındaki tatbikat, planın en değerli maddesi ve en sık atlananı. Kâğıt üzerinde 72 saatlik bir süreç yazmak kolay; gerçek veriyle o sorguyu bir kez çalıştırmadan, o sürenin tutup tutmayacağını bilmiyorsunuz. Tatbikatta ölçülecek tek şey var: "şu anda sızmış olsa, etkilenen kişilerin listesini kaç saatte çıkarırız". Cevap 40 saatse, 72 saatlik süreçte bildirim için 32 saat kalıyor; cevap 4 saatse rahat bir nefes alanı var. Bu sayıyı bilmek, olay anında tartışmayı bitiriyor.

Kurumsal tarafta bir de olay sonrası ölçüm var: tekrar oranı. Aynı kurumda bir yıl içinde ikinci bir kimlik bilgisi kaynaklı olay yaşanıyorsa, ilk olayda alınan tedbirlerin kalıcı olmadığı anlaşılıyor. Tedbirlerin kalıcılığını ölçmenin basit bir yolu, oturum kapatma ve parola sıfırlama işlemlerinin ne kadarının otomatikleştiğine bakmak. Elle yapılan bir temizlik, olay kapandıktan üç ay sonra yeni hesaplarda tekrar açık kalıyor. Bu yüzden olay müdahale planınızın, sızıntı senaryosunu ayrı bir başlık olarak içermesi gerekiyor: siber olay müdahale planı rehberi.

Sık yapılan yedi hata

Bu hataların ortak noktası, hepsinin makul görünmesi. Her biri, bilgi eksikliğiyle alınmış bir karar; sonucu ise işin yarısının yapılmış sayılması.

Bir: parolayı değiştirip oturumları kapatmamak. En yaygın hata. Parola değişir, saldırganın çerezi çalışmaya devam eder, iki gün sonra hesap yine gider ve "parolamı değiştirmiştim" şaşkınlığı yaşanır.

İki: tek bir sızıntı kontrolüne güvenip temiz sonucu güvenlik saymak. Kontrol yalnızca kamuya açılmış dökümlere bakar. Sonuç boşsa bilgi eksiktir, risk sıfır değil.

Üç: bütün hesaplarda aynı yeni parolayı kullanmak. Sızıntı sonrası yapılan toplu değişikliklerde sık görülüyor: herkes tek bir güçlü parola seçip her yere yazıyor. Bu, tekrar kullanım sorununu çözmediği gibi tek bir noktadan bütün hesapların açılmasına yol açıyor.

Dört: kurtarma bilgisini atlamak. Parola değişip kurtarma e-postası eski bir adreste kaldığında, hesabın anahtarı hâlâ başkasının elinde oluyor. Kurtarma adresi ve telefonu parolayla aynı gün kontrol edilmeli.

Beş: bildirimi sonraya bırakmak. Kurumsal tarafta en pahalı hata. 72 saatlik süre "iş bitsin, sonra bildiririz" mantığını kaldırmıyor; 2019/352 kararında geç bildirim ayrı bir ceza kalemi olarak duruyor.

Altı: tedarikçiden gelen ihlal bildirimini teknik olay saymamak. Oysa sizin kiracınızda çalışan parolalar o dökümden gelmiş olabilir. Tedarikçi bildirimi geldiğinde yapılacak iş kendi kimlik bilgisi envanterinizi taramak.

Yedi: her şeyi elle yapmak. 42.000 kayıt için elle listeleme 525 iş günü; 72 saatlik saatte bu mümkün değil. Sorgu, şablon ve alıcı listesi olaydan önce hazır olmalı, olay anında yazılmamalı.

Hangi sayı neyi gösterir

Bu rehberde kullanılan bütün sayılar varsayımlara dayanıyor ve varsayımlar metinde açık. Yine de bir okuma anahtarı faydalı: hangi sayı gerçekten karar değiştirir, hangisi sadece süs.

Sayı	Neyi gösterir	Karar değiştirir mi
Dökümün ham boyutu	Satıcının pazarlama rakamı	Hayır
Okunabilir parola oranı (%64,3)	Dökümün ne kadarının kullanılabilir olduğu	Evet; hash türüne bakmayı gerektirir
Hâlâ geçerli oran (%26,4)	Rotasyon disiplininiz	Evet; parola politikasının çıktısı
Yeniden kullanım oranı (%23)	Tek bir dökümün kaç kapıyı açtığı	Evet; parola yöneticisi ve giriş kontrolü
MFA kapsamı (%61)	Saldırıcının hedef kümesinin büyüklüğü	Evet; en hızlı iyileştirme kalemi
Tespit gecikmesi (saat)	İzleme ürününün gerçek değeri	Evet; satın alma kararının merkezi
Etkilenen kişi listesini çıkarma süresi	72 saatlik saatte kalan pay	Evet; KVKK tarafının tek gerçek ölçüsü

Ne zaman dışarıdan destek gerekir

Bu rehberdeki işlerin çoğu kendi başınıza yapılabilir: oturum kapatma, parola değiştirme, MFA açma, parola yöneticisi kurma, kurumsal envanter çıkarma. Dışarıdan destek anlamlı hale geldiğinde ise genellikle üç durum var. Birincisi, ihlalin kaynağının belirsiz olduğu durumlar: kendi sisteminizde mi, tedarikçide mi, bir çalışanın cihazında mı sızdığını bilmiyorsunuz ve delil toplamak gerekiyor. İkincisi, hukuki süreçle teknik sürecin aynı anda yürümesi gereken durumlar: 72 saatlik bildirim, sulh ceza başvurusu ve adli bilişim incelemesinin birbirini bozmadan ilerlemesi. Üçüncüsü, düzenli doğrulama ihtiyacı: sızıntı sonrası kapatılan kapıların gerçekten kapalı olduğunun bağımsız bir gözle test edilmesi.

Yetkisiz erişim, izinsiz sızma veya bir başkasının hesabına girme teklif eden hiçbir hizmet yasal değil; bu tür talepler hem TCK 136 kapsamına girebilecek fiiller doğuruyor hem de elinizdeki delili kirletiyor. Yasal çerçevede çalışan bir ekip, her adımda yazılı yetki ister; sahiplik doğrulanmamış bir hesap için iş almaz. Kurumsal doğrulama ve yetki belgesi sürecinin nasıl işlediği ayrı bir sayfada: sızma testi kapsamı ve fiyatlandırma. Teknik doğrulama tarafında API ve uç nokta incelemesi için API güvenlik testi rehberi, kimlik avı kaynaklı sızıntılarda oltalama farkındalık programı, hat ele geçirme şüphesinde SIM swap rehberi ve kurumsal posta güvenliğinde SPF, DKIM ve DMARC denetimi devam niteliğinde okunabilir.

Kapanış: sızıntı bir olay değil, bir süreç

Sızıntı haberlerinin çoğu bir kere olup biten bir olay gibi sunuluyor: bir tarih, bir şirket, bir sayı. Oysa sızan bir parolanın ömrü, o haberi okuyan kişinin onu değiştirdiği güne kadar sürüyor. Bu yüzden doğru soru "sızdı mı" değil, "hangi parola hâlâ nerede çalışıyor ve onu kim ne zaman kapatacak". Bu sorunun cevabı bir envanterde, bir rotasyon takviminde ve bir oturum iptali düğmesinde duruyor; bir haber başlığında değil.

Ölçülebilir üç hedef yeterli: kamuya açık bir dökümde çalışan parolası kalan hesap sayısını sıfıra indirmek, tek faktörlü hesap sayısını sıfıra indirmek, ve etkilenen kişi listesini 72 saatlik saatin içinde üretmek. Bu üçü tutulduğunda geri kalan her şey — hangi döküm, hangi satıcı, hangi alarm — bir ayrıntı oluyor. Tutulmadığında ise en pahalı izleme aboneliği bile bir ekran koruyucudan fazlası olmuyor.