Fidye Yazılımı (Ransomware) Saldırılarına Karşı Modern Yedekleme ve Kurtarma Stratejileri

Fidye yazılımlarının ilk döneminde denklem basitti: dosyalar şifrelenir, yedeğiniz varsa geri yükler, fidyeyi ödemezdiniz. Saldırgan grupları bu denklemi hızla değiştirdi. Bugün tipik bir fidye yazılımı operasyonu şifrelemeden günler, hatta haftalar önce ağa sızar; önce yedekleri bulur ve yok eder, sonra veriyi dışarı çıkarır, en son şifreler.

Bu yüzden "yedeğimiz var" demek artık yeterli değil. Asıl soru şu: Yedeğiniz, ağınızda yönetici yetkisi ele geçirmiş bir saldırgana dayanabilir mi?

Şantaj modelleri nasıl değişti?

Bu tablo iki şeyi gösterir: yedekler hâlâ kurtarmanın temelidir, ama fidye yazılımına karşı savunmanın tamamı değildir. Veri sızıntısına karşı ayrıca önleme ve tespit katmanları gerekir.

Klasik yedekleme neden yetersiz kalıyor?

• Yedek sunucusu etki alanına (domain) üye: Saldırgan domain yöneticisi olduğunda yedek sunucusuna da yönetici olarak girer.
• Yedekler ağ paylaşımında: Fidye yazılımı erişebildiği her paylaşımı şifreler; bağlı bir NAS da buna dahildir.
• Yedek yazılımı konsolu ele geçirilebilir: Saldırgan yedekleme işlerini siler, saklama süresini kısaltır, yedek depolarını biçimlendirir.
• Anlık görüntüler (snapshot) silinebilir: Windows gölge kopyaları ve sanallaştırma snapshot'ları, yeterli yetkiyle tek komutla silinir.
• Geri yükleme hiç test edilmemiş: Yedek alınıyor ama hiç geri yüklenmemiş. Kriz anında bozuk ya da eksik olduğu ortaya çıkıyor.

3-2-1 kuralından 3-2-1-1-0 kuralına

Klasik 3-2-1 kuralı (3 kopya, 2 farklı ortam, 1 kopya dışarıda) hâlâ geçerli bir temel, ama fidye yazılımı çağında iki ek gerekiyor:

• 3 kopya veri (1 üretim + 2 yedek),
• 2 farklı depolama ortamı,
• 1 kopya fiziksel olarak farklı bir lokasyonda,
• 1 kopya değiştirilemez (immutable) veya çevrimdışı (air-gapped),
• 0 hata: geri yükleme testleri hatasız doğrulanmış.

Değiştirilemez (immutable) yedek mimarisi

Değiştirilemez yedek, belirlenen saklama süresi boyunca hiç kimse tarafından, yönetici hesabı dahil, silinemeyen veya üzerine yazılamayan yedektir. Saldırgan tüm ağı ele geçirse bile bu kopyaya dokunamaz.

Uygulama seçenekleri

• Nesne kilidi (Object Lock) destekli depolama: Amazon S3 Object Lock (compliance modu), Azure Blob değiştirilemez depolama politikaları veya S3 uyumlu yerel depolama çözümleri. Compliance modunda saklama süresi dolmadan hesap sahibi bile veriyi silemez.
• Sıkılaştırılmış Linux deposu: Birçok kurumsal yedekleme çözümünün sunduğu, tek kullanımlık kimlik bilgisiyle eklenen ve dosyalara değiştirilemezlik bayrağı uygulayan depolar.
• Çevrimdışı ortam: Dönüşümlü teypler veya ağdan fiziksel olarak ayrılan diskler. Eski ama saldırgan açısından hâlâ en zor hedef.

Mimari ilkeler

1. Kimlik ayrımı: Yedekleme altyapısı üretim etki alanından ayrı kimliklerle yönetilsin; domain üyesi olmasın.
2. Yönetim erişimi: Yedek konsoluna yalnızca ayrı bir yönetim ağından, MFA ile erişilebilsin.
3. Dört göz ilkesi: Yedek silme veya saklama süresini kısaltma gibi kritik işlemler iki kişinin onayını gerektirsin.
4. Yeterli saklama süresi: Saldırganlar şifrelemeden önce günlerce ağda kalabildiğinden, en az 30 günlük değiştirilemez geçmiş hedeflenmeli; böylece saldırı öncesindeki temiz bir noktaya dönülebilir.
5. Yedek bütünlüğü izleme: Yedek boyutunda ani artış veya veri değişim oranında sıçrama, toplu şifrelemenin erken işareti olabilir.

Kurtarma planı: yedek almak işin yarısı

RPO ve RTO'yu belirleyin

• RPO (kurtarma noktası hedefi): En fazla ne kadarlık veri kaybını kabul edebilirsiniz? (ör. 4 saat)
• RTO (kurtarma süresi hedefi): Sistem ne kadar sürede tekrar çalışmalı? (ör. 24 saat)

Bu hedefler her sistem için farklıdır ve iş birimleriyle birlikte belirlenmelidir. ERP sistemi için 4 saat kabul edilemezken, arşiv sunucusu için bir hafta sorun olmayabilir.

Temiz ortamda geri yükleme

Saldırgan hâlâ ağdaysa, geri yüklenen sistemler de tekrar ele geçirilir. Kurtarma, izole edilmiş temiz bir ortamda başlamalı; geri yüklenen imajlar zararlı yazılım taramasından geçirilmeli ve ele geçirilen tüm kimlik bilgileri değiştirilmeden ağa bağlanmamalıdır.

Düzenli tatbikat

• Her ay rastgele seçilen dosya ve sunucuların geri yükleme testi,
• Her çeyrek bir kritik sistemin tamamen geri yüklenip çalıştırılması ve sürenin ölçülmesi,
• Yılda en az bir kez, yönetimin de katıldığı fidye yazılımı masa başı tatbikatı.

Yedeğin ötesinde: çift şantaja karşı önlemler

• Veri sızıntısı tespiti: Olağan dışı büyük veri çıkışlarını izleyin; bulut depolama hizmetlerine toplu yüklemeler alarm üretsin.
• Veri minimizasyonu: Tutmanız gerekmeyen veriyi silin. Saklanmayan veri çalınamaz.
• Hassas verinin şifrelenmesi: Kişisel ve ticari sır niteliğindeki veriler, erişim kontrollü ve şifreli depolarda tutulsun.
• Olay müdahale planı: Hukuk, iletişim ve KVKK bildirim süreçleri önceden planlansın; 72 saatlik bildirim süresi kriz anında hazırlık yapılamayacak kadar kısadır.

Kontrol listesi

• En az bir yedek kopyası değiştirilemez veya çevrimdışı mı?
• Yedek altyapısı üretim etki alanından ayrı mı?
• Yedek konsolunda MFA var mı?
• Değiştirilemez saklama süresi en az 30 gün mü?
• Son geri yükleme testi ne zaman yapıldı, ne kadar sürdü?
• Kritik sistemler için RPO/RTO tanımlı mı?
• Fidye yazılımı senaryosu için yazılı bir müdahale planı var mı?

Sonuç

Fidye yazılımına karşı en güçlü koz, saldırganın dokunamayacağı ve gerçekten test edilmiş bir yedektir. Ama modern şantaj modelleri, yedeğin yanında sızıntı tespiti ve hazırlıklı bir müdahale planını da zorunlu kılıyor. Yedekleme mimarinizin fidye yazılımına dayanıklılığını test etmek veya bir olay sonrası destek almak için bizimle iletişime geçebilirsiniz.