Fidye Yazılımı Sonrası Veri Kurtarma: Kanıt, Sıra ve Geri Dönüş Rehberi

Fidye yazılımı vakaları genellikle tek bir soruya indirgeniyor: ödesek mi? Oysa ödeme sorusu, işin en sonunda ve çoğu zaman en önemsiz kısmında duruyor. Kurulun yayımladığı dosyalarda gördüğümüz tablo şu: verilerini geri alabilen kurumlar, ödeme kararını vermeden önce kurtarma problemini çözmüş olanlar; geri alamayanlar ise üç hafta boyunca aynı soruyu farklı kişilere soranlar. Bu metin, kurtarmayı bir hukuk ve itibar tartışması olarak değil, bir mühendislik ve kanıt problemi olarak ele alıyor.

Üç şeyi birbirinden ayırmak gerekiyor, çünkü pratikte sürekli karışıyorlar. Şifre çözme bir anahtar sorusudur ve çoğu zaman sizin elinizde değildir. Geri dönüş bir yedek sorusudur ve tamamen sizin elinizdedir, yeter ki daha önce test edilmiş olsun. Kanıt ise bir sıra sorusudur: kurtarma işlemi, ihlalin kapsamını gösteren kayıtların üzerine yazar. Bu yüzden doğru sıra, önce kanıt, sonra temizlik, en son veri dönüşü.

Türkçe kaynaklarda bu konunun tipik hâli ya bir veri kurtarma firmasının "diskten veri kurtarma" sayfası ya da bir hukuk bürosunun 12. madde özeti. İkisi de konunun yalnızca bir kenarını tutuyor: birincisi arızalı diskle fidye yazılımını aynı kutuya koyuyor, ikincisi bildirim yükümlülüğünü yazıp hangi kaydın nerede durduğunu yazmıyor. Aradaki boşluk, kurtarma kararının verildiği yer: hangi kopya temiz, hangi sırayla dönülür, ne zaman yeniden bağlanılır ve o ana kadar hangi kanıt toplanmış olmalı.

Kayıt ne söylüyor: Kurul'un yayımladığı dosyalar tek bir hatayı tekrar ediyor

Kişisel Verileri Koruma Kurulu, fidye yazılımı kaynaklı ihlalleri kamuoyu duyurusu ve karar özeti olarak yayımlıyor. Bu dosyalar, sektörde dolaşan anlatılardan farklı olarak tarih, kişi sayısı ve eksik tedbir açısından somut. Aşağıdaki tablo 2026 yılında yayımlanan bildirimlerden ve iki inceleme kararından derlendi; hepsi Kurumun kendi sitesinde yayımlanmış kayıtlar.

Kayıt	Tarih	Kayıtta geçen kapsam	Dikkat çeken nokta
2024/413 kararı	Karar 06.03.2024	56 çalışan; kimlik, iletişim, özlük, kaza raporu ve sağlık verileri; veriler dışarıya sızdırıldı	Çok faktörlü doğrulama ve yamalar ihlalden sonra devreye alınmış; ortak sunucu kullanımı ihlali birden çok veri sorumlusuna yaymış
2024/2196 kararı	Karar 26.12.2024	Veri sorumlusu dahil 9 şirket etkilenmiş; bildirimde çalışan ve müşteri verisi, sonraki yazılarda "hiç kimse etkilenmedi" beyanı	Şifrelenen log kayıtları yüzünden güvenlik açığı hiç tespit edilememiş; ihlal öncesi yaptırılan sızma testi "temiz" çıkmış
Doro Dizayn bildirimi	İhlal 12.06.2026, aynı gün tespit	Kategoriler işlem güvenliği, risk yönetimi, finans, pazarlama; kişi sayısı 1-10.000 aralığında	Bildirimde "hangi verilerin şifrelendiği henüz bilinmiyor" ifadesi var
Mefa Endüstri bildirimi	Başlangıç 22.08.2026, tespit 23.08.2026	2.200 kişi; çalışan, kullanıcı ve müşteri; sağlık ve ceza mahkumiyeti dahil on beş kategori	Olağandışı faaliyeti dışarıdan danışmanlık firması fark etmiş
Ada Mert Sağlık bildirimi	02.09.2026, aynı gün tespit, 03.09.2026 bitiş	Etkilenen kişi grubu ve kategori "henüz bilinmiyor"	İki gün süren olayda kapsam hiç belirlenememiş
Procatcx, PCX ve PCT bildirimleri	Üçünde de 30.09.2026, aynı gün tespit	Özlük dosyaları, CV'ler, çağrı detay kayıtları ve çağrı ses kayıtları; kişi sayısı belirsiz	Aynı gün, aynı kategori listesi, üç ayrı karar (2026/2204, 2026/2205, 2026/2207)

Bu tablodaki ortak nokta, tespitin geç olması değil. Neredeyse hepsinde tespit aynı gün yapılmış. Ortak nokta, kapsamın bilinmemesi: hangi veri gitti, kaç kişi etkilendi, veri dışarı çıktı mı. Bu üç sorunun cevabı, kurtarma çalışmasının yan ürünü olarak kendiliğinden çıkmıyor; aksine kurtarma çalışması bu soruların cevabını üreten kayıtların üzerine yazıyor.

İki karar özeti ise idari para cezasının neden kurtarma başarısızlığına değil, kanıt ve tedbir eksikliğine bağlandığını gösteriyor. 2024/2196'da veri sorumlusu yedekten başarıyla dönmüş ve sunucuları çalışır hâle getirmiş; yine de 250.000 TL idari para cezası uygulanmış, çünkü ihlale sebep olan güvenlik açığı hiç tespit edilememiş ve bunun nedeni olarak şifrelenmiş log kayıtlarına ulaşılamaması gösterilmiş. Yani kurtarma tamamlanmış, açıklama tamamlanmamış. 2024/413'te ise 150.000 TL ceza, alınmayan tedbirlerin listesiyle birlikte yazılmış.

"Yedekten geri döndük" cümlesi neden bir kapanış değil

Bir olay müdahalesinde en çok duyulan cümle bu ve teknik olarak doğru olabiliyor. Yedekten dönmek veriyi geri getiriyor, ama dört şeyi getirmiyor: açığın ne olduğunu, saldırganın ne kadar süre içeride kaldığını, hangi hesapların kullanıldığını ve hangi verinin çıktığını. Bu dördü, kurtarma sırasında silinen kayıtlarda duruyordu.

Somut olarak ne kayboluyor: etki alanı denetleyicisinin güvenlik günlüğü, uç nokta aracısının yerel olay önbelleği, güvenlik duvarının oturum kayıtları, posta sunucusunun bağlantı izleri, sanallaştırma platformunun görev geçmişi ve dosya sunucusunun erişim denetimi kayıtları. Bir makine yeniden kurulduğunda bu kayıtlar da yeniden kurulur ve boş başlar. Kurulum sırasında "temiz bir sayfa" hissi veren şey, aslında delilin imhası.

Bu yüzden ilk iki saatte yapılan iş, kurtarmanın değil kanıtın işi. Aşağıdaki tablo, sahada en sık atlanan ve sonradan aranan altı kalemi listeliyor.

Kanıt	Nerede duruyor	Neden sonradan bulunamıyor	Kim almalı
Etki alanı denetleyicisi güvenlik günlüğü ve dizin veritabanı	Sunucunun kendi diskinde, olay günlüğü döngüsel	Yeniden kurulumda silinir; günlük 20.480 olayla sınırlıysa saatler içinde üzerine yazılır	Olay müdahale lideri, yazma korumalı kopya
Uç nokta aracısının olay geçmişi	Bulut konsolunda, varsayılan saklama 30-90 gün	Aracı kaldırılıp yeniden yüklenince cihaz kimliği değişir, geçmiş eski cihaza bağlı kalır	Güvenlik operasyonu
Dosya sunucusu erişim denetimi kayıtları	Denetim ilkesi açıksa sunucuda	Denetim ilkesi kapalıysa hiç yoktur; sonradan açmak geçmişi üretmez	Sistem yöneticisi
Fidye notu ve uzantı örnekleri	Etkilenen dizinlerde, bazen yalnızca birkaç dosyada	Kurtarma sırasında silinir; aile tespiti ve çözücü araması buna bağlı	Adli inceleme
Şifrelenmiş dosyalardan örneklem	Her bölümden en az üç dosya, boyutlarıyla	Geri dönüş sonrası üzerine yazılır	Adli inceleme
Yedek kataloğu ve iş kayıtları	Yedek sunucusunda	Yedek altyapısı da etkilendiyse katalog kaybolur; hangi noktaya dönülebileceği bilinmez	Yedek yöneticisi

Bu listedeki üçüncü satır, denetimde en pahalıya patlayan kalem. Dosya erişim denetimi kapalıysa "hangi çalışan verisi okundu" sorusunun cevabı hiçbir zaman bulunamıyor ve bildirim, tahmin aralığıyla yazılıyor. Mefa Endüstri bildiriminde 2.200 gibi net bir sayı varken Ada Mert bildiriminde "henüz bilinmiyor" yazması, kanıtın olay sırasında toplanıp toplanmamasıyla ilgili bir fark.

Dört ayrı problem: veri, sistem, kimlik, güven

"Şifrelendik" cümlesi dört farklı problemi aynı anda anlatıyor ve bu dördünün sahibi, saati ve kanıtı farklı. Hepsini tek bir iş gibi ele almak, kurtarmaların üçüncü haftada tıkanmasının en yaygın nedeni.

Problem	Asıl soru	Bittiğini gösteren kanıt	Tipik süre
Veri	Kullanılabilir bir kopya var mı ve saldırıdan önce mi?	Geri dönüş testi kaydı, dosya sayısı ve sağlama toplamı karşılaştırması	1-3 gün
Sistem	Veriyi anlamlı kılan uygulama ve yapılandırma ayakta mı?	İşlem kabul testi, yetki matrisi, servis hesaplarının yeniden eşlenmesi	3-10 gün
Kimlik	Saldırganın elinde kalan anahtar var mı?	KRBTGT çift sıfırlama kaydı, parola ve sertifika yenileme listesi	1-2 gün, ama tam kapsam şart
Güven	Müşteri, sigortacı ve denetçi ortamın temiz olduğuna neden inansın?	Temizlik kanıt paketi: kapsam, zaman çizelgesi, kapatılan erişim yolları	Kurtarmayla paralel, 2-4 hafta

Dördüncüsü bütçelenmeyen kısım ve genellikle en pahalı olan. Bir kurum her baytı geri getirip yine de müşteri kaybediyor, çünkü sorulan soru "veriniz geri geldi mi" değil, "aynı şey yarın tekrar olur mu". Bu sorunun cevabı bir belgeyle veriliyor, bir sunumla değil.

Hangi geri dönüş noktası: RPO ile saldırganın kalma süresi arasındaki aritmetik

Kurtarma planlarının çoğu RPO'yu bir hedef olarak yazıyor: "en fazla 4 saatlik veri kaybı". Ama fidye yazılımında belirleyici olan RPO değil, saldırganın içeride kaldığı süre ile yedeğin saklama süresi arasındaki fark. Aşağıdaki tablo, 40 TB verisi olan ve günde yüzde 4 değişim yaşayan bir kurum için bu farkı gösteriyor.

Senaryo	Saldırganın kalma süresi	14 günlük saklama	30 günlük saklama	Sonuç
Hızlı, fırsatçı saldırı	9 gün	Temiz kopya var	Temiz kopya var	14 gün yeterli
Ortalama	14 gün	Temiz kopya yok	Temiz kopya var	Saklama süresi kritik eşikte
Hedefli, bekleyen saldırı	21 gün	Temiz kopya yok	Temiz kopya var	14 gün yetersiz
Uzun süreli yerleşim	45 gün	Temiz kopya yok	Temiz kopya yok	Değiştirilemez arşiv şart

Bu tablonun pratik anlamı şu: 14 günlük bir saklama politikası, saldırganın iki haftadan uzun süre sessiz kaldığı her senaryoda sıfır temiz kopya demek. Ve şifreleme anı, saldırganın içeri girdiği an değil, işini bitirdiği andır; yedeklerin çoğu saldırgan hâlâ içerideyken alınmış oluyor. Bu yüzden "en son yedek" çoğu zaman "en kirli yedek" anlamına geliyor.

Buradan çıkan üç kural: saklama süresi, tahmini kalma süresinin en az iki katı olmalı; en az bir kopya yazma sonrası değiştirilemez olmalı; geri dönüş noktası seçilirken "en yeni" değil "saldırı öncesi olduğu kanıtlanmış en yeni" tercih edilmeli. Üçüncüsü, dosya sunucusunda bir değişiklik izleme kaydı varsa kanıtlanabilir; yoksa tarih tahminine dayanır ve tahmin, altı ay sonra sorulduğunda savunulamaz.

Dört kopya sınıfı ve her birinin gerçekten atlattığı olay

3-2-1 kuralı artık yetersiz, çünkü kopyaların çoğu aynı kimlik bilgileriyle erişilebilir durumda. 3-2-1-1-0 biçiminde yazılan genişletilmiş kural, her kopyanın hangi olayı atlattığını ayırıyor.

Sınıf	Örnek	Atlattığı olay	Atlatamadığı olay
Çevrimiçi kopya	Yedek sunucusundaki gecelik iş	Disk arızası, yanlış silme (ilk 24 saat)	Aynı etki alanına bağlıysa fidye yazılımı; saldırgan yedek kataloğunu da şifreler
Çevrimdışı kopya	Çıkarılmış teyp, ayrı ünitede saklanan disk	Kimlik bilgisiyle silme, yedek sunucusunun ele geçirilmesi	Fiziksel olay, kayıp teyp, katalog kaybı
Değiştirilemez kopya	Nesne depolamada kilitli saklama (WORM)	Silme ve şifreleme girişimleri, içeriden müdahale	Yanlış yapılandırılmış saklama ilkesi; kilit süresi dolduktan sonra silme
Ayrık kopya	Farklı kimlik sağlayıcısı, farklı yönetici, farklı bölge	Etki alanı genelinde kimlik ele geçirme	Yedekleme kapsamına alınmamış sistemler

Tablodaki en çok yanlış anlaşılan satır ikincisi. Fiziksel olarak ayrı duran bir teyp, saldırganın erişemediği tek kopya olabilir; ama kataloğu yedek sunucusunda kaldıysa, teyp elinizdeyken hangi dosyayı nereden alacağınızı bilemeyebilirsiniz. Bu yüzden katalog, yedek sunucusundan bağımsız olarak da tutulmalı: en azından bant etiketi, iş kimliği ve tarih eşlemesi kâğıt veya ayrı bir depoda.

Geri dönüş sırası: kimlik, platform, ağ, veri, uygulama

Sıra, kurtarmanın en çok yanlış yapılan kısmı. Veri önce dönmek istiyor çünkü iş birimi veriyi istiyor; oysa veri sunucusu, kimlik altyapısı temiz olmadan ağa bağlanırsa ikinci bir şifreleme turuna davetiye çıkarıyor. Aşağıdaki sıra, bir olay müdahalesinde savunulabilir olan sıra.

Adım	Ne yapılır	Neden bu sırada	Geçiş koşulu
1	Kimlik: yeni orman veya temiz etki alanı denetleyicisi, KRBTGT çift sıfırlama, tüm parolalar	Eski kimlikle dönen her sistem, saldırganın elindeki biletle yeniden ele geçirilebilir	Eski biletlerin geçersizliği test edildi
2	Sanallaştırma ve depolama platformu	Diğer her şeyin üzerinde durduğu katman; yönetim arayüzü de saldırı yüzeyi	Yönetim arayüzü yalnızca yönetim ağından erişilebilir
3	Ağ ve segmentasyon, güvenlik duvarı kuralları en az yetkiyle	Saldırgan yatay hareket ediyorsa ilk kapatılan yol bu olmalı	Doğu-batı trafiği varsayılan olarak reddediyor
4	Veri: dosya, veritabanı, posta	Kimlik ve ağ temizken dönen veri, tekrar şifrelenme riski taşımıyor	Geri dönüş testi ve sağlama toplamı geçti
5	Uygulama ve entegrasyonlar	Servis hesapları ve bağlantı dizeleri bu adımda yeniden üretilir	İşlem kabul testi geçti
6	Dış erişim: VPN, uzak masaüstü, ortak erişimler	En son açılır, çünkü giriş yolu saldırganın ilk kullandığı yol	Çok faktörlü doğrulama zorunlu ve kayıtlı

Bu sırayı bozmanın maliyeti ölçülebilir: 2024/413 kararında çok faktörlü doğrulamanın ihlalden sonra devreye alındığı, yamaların ihlalden sonra yapıldığı ve ortak sunucu kullanımının ihlali birden çok veri sorumlusuna yaydığı tespit edilmiş. Üçü de sıra hatası: kimlik ve segmentasyon, veriden önce gelir.

Etki alanı denetleyicisi problemi: KRBTGT ve iki sıfırlama

Fidye yazılımı olaylarında en sık atlanan adım, etki alanı denetleyicisinin olduğu gibi geri getirilmesi. Bir saldırgan etki alanında yeterli süre kaldıysa, kimlik bileti imzalayan hesabın parolasını alabilir ve bu parola değişmedikçe ürettiği biletler saatlerce geçerli kalır. Bu yüzden kurtarma sonrası ilk iş parola değiştirmek değil, bilet imzalama anahtarını iki kez yenilemek.

İki kez yenilemenin nedeni aritmetik: kerberos biletlerinin ömrü varsayılan olarak 10 saat, yenileme süresi 7 gün olabiliyor. Tek bir sıfırlama, eski anahtarla imzalanmış ama hâlâ geçerli olan biletleri iptal etmiyor, çünkü doğrulama sırasında önceki anahtar da kabul ediliyor. İkinci sıfırlama, ilk sıfırlamadan en az bir bilet ömrü sonra yapıldığında eski anahtarla üretilmiş tüm biletler geçersiz hâle geliyor: 10 saatlik ömür için en az 10 saat, uygulamada 12 saat ara bırakılıyor. Bunu tek seferde yapmak isteyen ekipler, iki sıfırlamayı arka arkaya çalıştırıp aradaki süreyi atlıyor ve eski biletler çalışmaya devam ediyor.

Aynı mantık diğer gizli anahtarlar için de geçerli: hizmet hesapları, sertifika otoritesi anahtarları, sanallaştırma platformunun yönetici sertifikaları, yedekleme aracısının kayıt anahtarları ve parola kasasındaki tüm paylaşılan kimlik bilgileri. Kurtarma listesine "parola değiştir" yazmak yetmiyor; liste kalem kalem olmalı ve her kalemin sahibi, tarihi ve doğrulaması yazılmalı.

Sanallaştırmada arıza birimi sunucu değil, veri deposu

Fiziksel dünyada düşünme alışkanlığı "hangi sunucu bozuldu" sorusuyla başlıyor. Sanallaştırmada aynı yaklaşım, kurtarmayı yanlış ölçekte planlamaya götürüyor: bir veri deposu bozulduğunda üzerindeki onlarca sanal makine aynı anda duruyor ve tek tek geri dönmek, tek tek doğrulamak anlamına geliyor.

Bu yüzden kurtarma planı veri deposu bazında yazılmalı: her veri deposunda hangi sanal makineler var, hangisi önce gelmeli, hangisi bir başkasına bağımlı. Anlık görüntü zincirleri burada en büyük tuzak; aylardır birikmiş zincirler geri dönüş süresini saatlerden günlere çıkarıyor ve şifreleme anında zincirin kırılması, tek bir anlık görüntüye dönüşü imkânsız hâle getiriyor. Zincir uzunluğunu üç-dört adımla sınırlamak, kurtarma hızını doğrudan etkiliyor.

Veritabanı geri döndü ama açılmıyor: karşılaşılan dört neden

Yedekten dönen bir veritabanının açılmaması, kurtarmanın en sinir bozucu kısmı, çünkü "yedek var" bilgisi doğru ama işe yaramıyor. Sahada dört neden tekrar ediyor.

Birincisi, kurtarma modeli ile yedekleme planı uyumsuzluğu. Basit kurtarma modelinde çalışan bir veritabanının işlem günlüğü yedeği yoktur; tam yedekten sonraki tüm işlemler kayıptır. Tam kurtarma modelinde ise günlük zinciri koparıldığında veritabanı "kurtarma bekliyor" durumunda kalır ve açılmaz. Zincirin koptuğu noktayı bilmek için günlük yedeklerinin sıra numarası ile son tam yedeğin sıra numarasının karşılaştırılması gerekiyor.

İkincisi, sürüm ve yama farkı. Yedek, farklı bir yapı numarasındaki sunucuya geri yüklenemez; bu durumda hata mesajı açık olsa da çoğu zaman "bozuk yedek" olarak yorumlanır. Kurtarma ortamının yapı numarası, yedeğin alındığı sunucuyla aynı olmalı.

Üçüncüsü, dosya yolu ve disk harfleri. Veritabanı dosyalarının mantıksal adları, yeni sunucuda farklı yollara işaret ediyor olabilir; geri yükleme komutunda hedef yolların açıkça yazılması gerekiyor. Bu, en sık yapılan ve en kolay düzeltilen hata.

Dördüncüsü, şifreleme. Saydam veri şifrelemesi kullanılan bir veritabanının yedeği, sertifika olmadan açılmaz. Sertifika yedeklenmemişse veritabanı dosyası elinizde olsa da okunamaz. Sertifika ve onu koruyan anahtar, yedek planının parçası olmalı; ayrı bir kasada, ayrı bir erişim listesiyle.

Bu dört maddenin ortak yanı şu: hiçbiri gerçek bir geri dönüş testinde görünmüyor, çünkü testler genellikle aynı sunucuda, aynı yapı numarasıyla, aynı sertifikayla yapılıyor. Testin değeri, farklı bir ortamda yapıldığında ortaya çıkıyor.

Kısmi şifreleme: anahtar olmadan ne kurtulur

Bazı fidye yazılımı aileleri hız için dosyanın tamamını değil, başını ve sonunu ya da belirli bloklarını şifreler. Bu, saldırganın işini hızlandırırken kurban için ilginç bir durum yaratıyor: dosyanın büyük kısmı diskte duruyor ama dosya açılmıyor. Kurtarma açısından bu, dosya türüne göre çok farklı sonuç veriyor.

Dosya sınıfı	Yapı nerede	1 MB baş şifrelemede durum	Pratik sonuç
Ofis belgeleri (sıkıştırılmış paket biçimi)	Dizin yapısı dosyanın sonunda	Baş ve son şifreliyse dosya tanınmaz	Tek tek onarım çoğu zaman mümkün değil; içerik akışı kurtarılabilir
PDF	Çapraz başvuru tablosu sonda	Baş kısmı şifreliyse okuyucu açmaz	Nesne akışları ayrıştırılarak kısmi metin çıkarılabilir
Veritabanı dosyaları	Sayfa başlıkları dağınık	Sayfaların bir kısmı bozulur	Tutarlılık kaybı; onarımdan sonra bile bütünlük garantisi yok
Büyük medya dosyaları	Başlık önde, veri gövdesi arkada	Yalnızca küçük bir bölüm şifreli	Başlık onarımı veya yeniden paketleme ile çoğu kurtulabilir
Küçük dosyalar (ortalama 34 KB)	Tamamı baş bölgede	Dosyanın tamamı şifreli	Sıfır kurtarma; yedek dışında yol yok

Bu tablodaki son satır, ofis ortamlarında gerçek hayatın çoğunu açıklıyor. Bir dosya sunucusunda 1,2 milyon dosya ve ortalama 34 KB boyut varsa toplam veri 41,8 GB eder; 1 MB başlık şifrelemesi bu dosyaların tamamını kapsar. Aynı saldırı, 12.000 dosyalık ve ortalama 3,4 GB boyutlu bir medya arşivinde ise toplam baytların yalnızca yüzde 0,03'ünü etkiler. Yani "kısmi şifreleme" ifadesi, veri setinin dosya boyutu dağılımına bakmadan hiçbir şey ifade etmiyor.

Kamuya açık çözücüler: kapsam ve sınır

No More Ransom girişimi, kolluk birimleri ve güvenlik şirketlerinin ortak yürüttüğü bir çözücü arşivi. Arşivde belirli aileler için çalışan araçlar var ve bunları kullanmak ücretsiz. Ancak kapsamı doğru okumak gerekiyor: arşiv, o güne kadar çözülmüş aileleri içeriyor; yeni bir aile veya yeni bir sürüm genellikle kapsam dışında kalıyor.

Doğru sıra şu: önce fidye notu ve dosya uzantısından aile tespiti, sonra çözücü arşivinde arama, sonra şifrelenmiş dosyaların kopyaları üzerinde deneme. Orijinaller üzerinde deneme yapmak, çalışmayan bir çözücünün dosyayı daha da bozmasına yol açabiliyor. Ve kritik nokta: bir dosya çözüldüğünde bu, veritabanının çözüldüğü anlamına gelmiyor. Dosya düzeyinde çözme, uygulama düzeyinde bütünlük sağlamıyor.

Çözücü bulunamadığında kalan yol, dosya kurtarma araçlarıyla silinmiş veya üzerine yazılmamış veriyi aramak. Ancak şifreleme işlemi dosyayı yerinde değiştirdiği için, aynı dosyanın şifrelenmemiş hâli diskte nadiren kalıyor; bu umut, ancak dosya sistemi günlüğü veya anlık görüntü varsa gerçekçi.

Ödeme: hukuken ne söylenebilir, pratikte ne değişir

Türkiye'de fidye ödemesini doğrudan yasaklayan özel bir hüküm bulunmuyor; ödeme bir suç olarak tanımlanmış değil. Buna karşılık ödemenin hukuki sonuçları ve pratik sonuçları ayrı ayrı değerlendirilmeli. Bu metin bir hukuki görüş değil, karar verirken sorulması gereken soruların listesi.

Birinci soru: ödeme neyi satın alıyor? Genellikle bir anahtar ve bir söz. Anahtarın işe yaradığına dair bir garanti yok; çoğu vakada ödeme sonrası verilen araç, verilerin bir kısmını çözüyor. Bu yüzden ödeme, kurtarma planının yerine geçmiyor; en iyi durumda plana bir şans ekliyor.

İkinci soru: ödeme yapıldığında çalınan veri ne oluyor? Şifreleme ile veri hırsızlığı aynı olayda birleştiğinde, ödeme sadece şifreyi çözüyor. Sızdırılmış verinin yayımlanmaması taahhüdü, hiçbir tarafın uygulayamadığı bir taahhüt. İkinci bir gasp talebi sık karşılaşılan bir durum ve ödeme, sonraki taleplerin varlığını ortadan kaldırmıyor.

Üçüncü soru: ödeme, bildirim yükümlülüğünü etkiliyor mu? Etkilemiyor. Kişisel veri ihlalinin bildirimi, ödeme yapılıp yapılmadığından bağımsız. Ödeme yapılmış olması, ihlalin gerçekleşmediği anlamına gelmiyor ve bildirim süresini durdurmuyor.

Dördüncü soru: kim karar veriyor? Teknik ekip değil. Karar, yönetim kurulu düzeyinde, hukuk ve sigorta danışmanıyla birlikte, kurtarma seçenekleri tükendikten sonra verilir. Ödeme kararını olay gününde veren ekipler genellikle yedek testinin olmadığını o gün öğreniyor; bu yüzden kararın gerçek konusu, ödeme değil, hazırlık eksikliği.

Bir de yaptırım boyutu var: ödeme, kolluk birimine başvuruyu dışlamıyor ve birçok ülkede ödeme yapan kurumlar yaptırım listeleriyle karşılaşma riski taşıyor. Bu nedenle ödeme seçeneği değerlendirilirken uyum biriminin de sürece girmesi gerekiyor.

Çalınan veri ve ikinci gasp: iddiayı doğrulama

Fidye yazılımı gruplarının sızıntı sitelerinde yayımladığı iddialar, kurumun kendi kanıtıyla karşılaştırılmadan doğru kabul edilmemeli; ama tamamen yok sayılması da mümkün değil, çünkü iddia bir gün müşterinin karşısına çıkıyor. Aşağıdaki tablo, iddiayı doğrulamak için kullanılan kalemleri gösteriyor.

İddia	Doğrulama yolu	Yetersizse ne olur
"X GB veri kopyaladık"	Çıkış trafiği kayıtları, vekil sunucu günlükleri, bulut depolama erişim kayıtları	Bildirimde aralık yazılır, sonradan revize edilir
"Şu tabloları aldık"	Veritabanı erişim denetimi, sorgu günlükleri, yedek dosyası erişimleri	Hangi kişilerin etkilendiği belirlenemez
Ekran görüntüsü veya dosya örneği	Örnekteki verinin gerçekten sizde olup olmadığı, tarih ve biçim karşılaştırması	Sahte iddia ile gerçek ihlal ayırt edilemez
"Ödeme yapılmazsa yayımlarız"	Grup geçmişi, daha önce yayımladığı kurumlar, talebin tutarlılığı	Gereksiz panik veya gereksiz sessizlik

Bu tablodaki ilk satır, olay sonrası en sık eksik kalan kalem. Çıkış trafiği kayıtları genellikle 30-90 gün tutuluyor ve olay anında saklanmazsa sonradan üretilemiyor. Veri hacmi iddiası doğrulanamadığında, bildirim "en kötü durum" varsayımıyla yazılıyor; bu da kişi sayısını ve dolayısıyla yükümlülükleri büyütüyor.

Kurtarma bitmeden başlayan saatler: bildirim yükümlülüğü

Kişisel veri ihlalinin bildirimi, kurtarma çalışmasının sonunda yapılan bir iş değil. 6698 sayılı Kanunun 12. maddesinin beşinci fıkrası, veri sorumlusuna ihlali "en kısa sürede" bildirme yükümlülüğü getiriyor; sürenin nasıl hesaplanacağına dair ölçütü Kurulun 24.01.2019 tarihli ve 2019/10 sayılı kararı belirliyor ve bu karar, bildirimin ihlali öğrendikten sonra 72 saat içinde yapılmasını bekliyor. Yani saat, fidye yazılımını fark ettiğiniz anda başlıyor, verilerin geri döndüğü anda değil.

Adım	Ne zaman	Kim	Çıktı
İç bildirim ve olay kaydı açılışı	0-4 saat	Bilgi işlem ve veri koruma sorumlusu	Olay kimliği, ilk kapsam tahmini
Kanıt toplama ve etki alanı sınırlama	0-24 saat	Olay müdahale ekibi	Zaman çizelgesi ilk sürümü, izole edilen sistemler
Kurula bildirim	72 saat içinde	Veri sorumlusu temsilcisi	Bildirim formu, etkilenen kategori ve kişi tahmini
İlgili kişilere bildirim	Makul en kısa sürede	Veri sorumlusu	Bildirim metni, iletişim kanalı, soru hattı
Kurul karar özetinin yayımlanması	İnceleme sonrası	Kurum	Kamuya açık kayıt

2026 bildirimlerinin tarihleri bu takvimin nasıl işlediğini gösteriyor: Mefa Endüstri olayı 22.08.2026'da başlamış, 23.08.2026'da tespit edilmiş, karar 02.09.2026 tarihli. Procatcx, PCX ve PCT bildirimlerinde olay 30.09.2026, kararlar 07.10.2026. Yani tespitten yayıma kadar geçen süre bir hafta ile iki hafta arasında; bu süre içinde yapılan iş, kurtarma değil kapsam belirleme.

Pratik sonuç: 72 saatlik pencere, kurtarma çalışmasıyla çakışıyor. Bu çakışmayı yönetmenin tek yolu, bildirim metnini olay anında sıfırdan yazmamak; kapsam bilinmediğinde nasıl yazılacağını önceden belirlemek. "Etkilenen kişi sayısı henüz belirlenemedi" ifadesi, kayıtlarda görüldüğü gibi kabul edilebilir bir beyan; ama bunu yazabilmek için hangi kategoriyi hangi gerekçeyle bildirdiğinizi gösterebilmeniz gerekiyor.

Kanıt dosyası: sigortacının ve avukatın isteyeceği liste

Olay bittikten sonra üç taraf aynı soruyu farklı biçimde soruyor: sigortacı "kayıp ne kadar", avukat "yükümlülüğünü yerine getirdin mi", müşteri "verim güvende mi". Üçünün de kabul ettiği tek şey, tarih damgalı belge. Aşağıdaki liste, bir dosyanın kapanabilmesi için gereken asgari set.

Belge	Neyi kanıtlar	Yoksa
Zaman çizelgesi (ilk belirti, tespit, ilk müdahale, bildirim)	Sürelerin uygunluğunu	Sigorta tazminatı tartışmalı hâle gelir
Geri dönüş testi kaydı (tarih, süre, sonuç)	Yedeğin çalıştığını	Kesinti süresi "ihmal" olarak değerlendirilir
Etkilenen sistem ve veri envanteri	Kapsamın sınırını	Kapsam tahmini büyür, bildirim genişler
Kimlik bilgisi yenileme kaydı	Erişimin kapatıldığını	Tekrar ihlal riski kabul edilmez
Temizlik doğrulama raporu	Kalıcı erişim kalmadığını	Denetimde "kontrol edilmedi" bulgusu
İşlem kabul testi sonuçları	Hizmetin geri döndüğünü	Müşteri iadesi ve ceza şartları devreye girer

2024/2196 kararı bu listenin neden gerekli olduğunu gösteriyor: kurtarma tamamlanmış olmasına rağmen açığın ne olduğu tespit edilememiş, çünkü log kayıtları şifrelenmişti. İdari para cezasının gerekçesinde bu eksiklik açıkça yer alıyor. Yani "veriyi geri aldık" savunması, "açığı açıklayamıyoruz" itirafıyla birlikte sunulduğunda işe yaramıyor.

Yeniden bağlamadan önce kabul testleri

Sistemlerin ayağa kalkması ile hizmete açılması arasındaki fark, bu testler. Her biri bir dakika sürüyor, ama atlandığında ikinci bir olay riski doğuyor.

Test	Ne aranır	Başarısızsa
Kimlik bileti testi	Eski anahtarla imzalanmış bilet reddediliyor mu	İki sıfırlama arası süre yetersiz, tekrar et
Yerel yönetici hesapları	Bilinmeyen hesaplar, yeni oluşturulmuş servis hesapları	Kalıcı erişim devam ediyor
Zamanlanmış görevler ve başlangıç öğeleri	Olay penceresinde oluşturulmuş her görev	Yeniden şifreleme tetiklenebilir
Uç nokta koruması	Engelleme modu açık, imza güncel, politika merkezden geliyor	İlk savunma hattı devre dışı
Yedek işleri	Yeni taban çizgisi alınmış, katalog güncel, kilitli saklama aktif	Sonraki olayda aynı çıkmaz
Dış erişim yolları	Çok faktörlü doğrulama zorunlu, eski hesaplar kapalı	Giriş kapısı açık kalır
Posta akışı ve alan adı doğrulaması	Gönderim politikası, kimlik doğrulama kayıtları	Sahte gönderim ve itibar kaybı

Bu testlerin sonucu bir tutanak hâline getirilmediğinde, altı ay sonra "kontrol ettik" demek kanıtsız kalıyor. Tutanak, kurtarmanın son adımı değil; müşteriye ve sigortacıya verilen cevabın dayanağı.

Maliyet ve süre modeli: 40 TB için gerçek sayılar

Aşağıdaki model, tek bir varsayım setiyle kuruldu ve tüm sayılar bu varsayımlardan hesaplandı: 40 TB korunan veri, günlük yüzde 4 değişim (günde 1,6 TB), 3,5 kat sıkıştırma ve tekilleştirme oranı, dört haftalık tam yedek ve 26 günlük artımlı yedek saklama. Amaç kesin bir fatura üretmek değil, hangi değişkenin sonucu belirlediğini göstermek.

Kalem	Hesap	Sonuç
Haftalık tam yedek boyutu	40 TB / 3,5	11,4 TB
Günlük artımlı yedek boyutu	1,6 TB / 3,5	0,46 TB
30 günlük toplam depolama	4 x 11,4 TB + 26 x 0,46 TB	57,6 TB
Haftalık tam yedek penceresi	40 TB, 600 MB/s	18,5 saat
Geri dönüş süresi (hızlı depolama)	40 TB, 900 MB/s	12,3 saat
Geri dönüş süresi (paylaşılan depolama)	40 TB, 250 MB/s	44,4 saat
Geri dönüş süresi (şeritli teyp, tek akış)	40 TB, 120 MB/s	92,6 saat
Şifreleme süresi (6 sunucu, sunucu başına 150 MB/s)	40 TB, 900 MB/s	12,3 saat

Tablodaki son iki satır birlikte okunmalı. Saldırganın şifreleme hızı, sizin geri dönüş hızınıza eşit veya daha yüksek olabiliyor; yani olay anında kaybettiğiniz zaman, geri dönüş sırasında kazandığınız zamandan fazla. Bu asimetri, "hızlı kurtarma" hedefinin neden tek başına yeterli olmadığını açıklıyor: kurtarma hızı, şifreleme hızını geçmediği sürece kesinti kaçınılmaz.

Kesintinin parasal karşılığı için basit bir model: yıllık cirosu 480 milyon TL olan bir kurumda saatlik ciro yaklaşık 54.800 TL; operasyon durduğunda cironun yüzde 35'i risk altındaysa saatlik kayıp yaklaşık 19.200 TL. Sekiz saatlik kesinti 153.000 TL, 24 saat 460.000 TL, 72 saat 1,38 milyon TL, beş iş günü 2,3 milyon TL. Bu sayıların yanına idari para cezasını koyduğunuzda, ölçülen iki kalemin (150.000 TL ve 250.000 TL) kesinti maliyetinin yanında küçük kaldığı görülüyor. Yani asıl risk, ceza değil durma süresi.

Otuz kişilik bir şirket: kurtarmanın gerçekçi sırası

Yukarıdaki model büyük ölçekli görünüyor ama ölçek değişince problem değişmiyor, yalnızca çözümün aracı değişiyor. Otuz kişilik, tek sunucu ve bir yedek cihazıyla çalışan bir şirket için ilk 24 saat genellikle şöyle geçiyor.

Saat 0-1. Ağdan çıkarma. Yedek cihazının da bağlı olduğu ağı kapatmak, işi durduruyor ama şifrelemenin yedeklere ulaşmasını engelliyor. Bu kararı hızlı vermek gerekiyor, çünkü yedek cihazı aynı ağda ve aynı kimlik bilgileriyle erişilebilir durumdaysa şifrelenmesi dakikalar alıyor.

Saat 1-4. Kanıt toplama. Sunucunun disk imajı alınıyor, fidye notu ve uzantı örnekleniyor, dosya erişim kayıtları kopyalanıyor. Bu aşamada sistem kapatılmıyor; kapatmak, bellekteki ve günlükteki izleri kaybettiriyor.

Saat 4-12. Aile tespiti ve çözücü araması, paralel olarak yedek kataloğunun doğrulanması: dönüş noktası hangi tarih, o tarihte hangi dosyalar vardı, sağlama toplamları tutuyor mu. Otuz kişilik bir şirkette bu adım çoğu zaman yedek cihazının arayüzünde yapılan on dakikalık bir kontrol; ama yapılmadığında ertesi gün öğrenilen şey, yedeğin de yarısının boş olduğu.

Gün 1-2. Kimlik yenileme ve temiz kurulum, sonra veri dönüşü. Otuz kişilik bir şirkette etki alanı denetleyicisini sıfırdan kurmak yarım gün; hesapları yeniden oluşturmak ve parolaları dağıtmak yarım gün daha.

Gün 2-4. Uygulamaların yeniden yapılandırılması. Buradaki gizli maliyet, yapılandırmaların kimsenin aklında olmaması: yazıcı kuyrukları, paylaşım izinleri, muhasebe yazılımının veritabanı bağlantısı, e-fatura entegrasyonu, yedekleme ajanının yeniden kaydı.

Gün 4-7. Kabul testleri ve bildirim dosyasının tamamlanması. Bu aşama, işin teknik olarak bittiği ama hukuken bitmediği aşama.

Bu takvim, otuz kişilik bir şirkette yedek testi düzenli yapılıyorsa 4 güne, yapılmıyorsa iki haftaya çıkıyor. Fark, teknolojiden değil, önceden yapılmış üç saatlik bir testten geliyor.

Bir dahaki seferi ucuzlatan yedi madde

Bu liste, olay sonrası incelemelerde en sık çıkan ve en hızlı uygulanabilen maddelerden oluşuyor. Hepsi bu çeyrekte başlatılabilir; hiçbiri yeni bir platform satın almayı gerektirmiyor.

1. Geri dönüş testini takvime bağla. Ayda bir, rastgele seçilen bir klasör ve bir veritabanı, farklı bir ortama geri yüklenip açılıyor. Sonuç tarih, süre ve dosya sayısıyla kaydediliyor. Kayıt yoksa test yapılmamış sayılıyor.

2. Değiştirilemez kopya ekle. En az bir kopya, yazma sonrası değiştirilemez saklamada ve farklı kimlik bilgileriyle erişilebilir olsun. Aynı yönetici hesabıyla erişilen dört kopya, tek kopya sayılır.

3. Saklama süresini kalma süresine göre ayarla. 14 gün, çoğu gerçek olay için yetersiz. En az 30 gün, hedefli saldırılar için değiştirilemez arşivle 90 gün.

4. Katalogu ayrı tut. Hangi bandın hangi güne ait olduğunu gösteren liste, yedek sunucusundan bağımsız bir yerde dursun. Yedek sunucusu ele geçirildiğinde elinizde kalan tek şey bu liste olacak.

5. Yönetim düzlemini ayır. Sanallaştırma yönetim arayüzü, yedek konsolu ve güvenlik duvarı yönetimi, kullanıcı ağından erişilemez olsun. Saldırganların ilk hedefi bu üçü.

6. Olay anı için hazır metin tut. Bildirim formunun kapsam bilinmediğinde nasıl doldurulacağı, kimin imzalayacağı ve kime gönderileceği önceden yazılı olsun. 72 saatlik pencerede metin yazmak, en çok vakit kaybettiren iş.

7. Envanteri gerçek tut. Hangi sistem hangi kişisel veriyi tutuyor, hangi yedekleme kapsamında, kim erişiyor. Kapsam sorusuna cevap veremeyen kurumlar, kurtarma tamamlandıktan sonra bile bildirimi revize etmek zorunda kalıyor.

Dışarıdan yardım alırken kapsam ve yetki

Kurtarma sırasında dışarıdan destek almak normal, ama yetkinin yazılı olması şart. Adli inceleme, yedek altyapısına erişim ve kimlik sisteminde değişiklik yapma yetkisi birbirinden farklı yetkiler; hepsini tek bir sözlü anlaşmayla vermek, sonradan "kim ne yaptı" sorusunu cevapsız bırakıyor.

Yazılı kapsamda bulunması gerekenler: hangi sistemlere erişilecek, hangi işlemler yapılacak, kanıtların nereye kopyalanacağı ve ne kadar süre saklanacağı, iş bitiminde erişimlerin nasıl kaldırılacağı, raporun hangi formatta teslim edileceği. Bu maddeler, hem denetimde hem sigorta sürecinde işe yarıyor.

Bir de sıralama meselesi var: dış ekip kurtarmayı yönetirken bildirim yükümlülüğü veri sorumlusunda kalıyor. Hizmet sağlayıcının raporu, bildirimin yerine geçmiyor; yalnızca dayanağı oluyor.

Nerede bitiyor

Fidye yazılımı sonrası kurtarma, üç soruya verilen cevapların toplamı: hangi kopya temiz, hangi sırayla dönülecek, neyi kanıtlayabileceğim. Üçü de olay gününden önce belirlenebilir ve üçü de ölçülebilir. Ödeme sorusu ise bu üçü cevaplanmadığında soruluyor; cevaplandığında çoğu zaman sorulmuyor bile.

Bu metindeki sayılar bir modelden, kayıtlar ise Kurumun yayımladığı dosyalardan. Kendi ortamınız için yapılacak ilk iş, modelin girdilerini kendi verinizle değiştirmek: kaç TB, günlük ne kadar değişim, hangi saklama süresi, hangi geri dönüş hızı. Bu dört sayıyı bilmeden kurtarma planı yazmak, tatbikatsız bir plan yazmakla aynı şey.

Kurumsal olay müdahalesi ve adli inceleme kapsamınızı yazılı yetkilendirmeyle netleştirmek istiyorsanız, dijital adli inceleme ve güvenlik sertleştirme hizmetlerimizin kapsamı bu metindeki sırayı takip ediyor. Olay öncesi hazırlık için olay müdahale planı rehberine, kayıt ve kanıt tarafı için teknik tedbirler ve kanıt rehberine, olayın giriş yolu çoğu zaman e-posta olduğu için e-posta güvenliği denetimi yazısına bakabilirsiniz.