Yedekleriniz Gerçekten Ransomware'e Dayanıklı mı?

"Backup'ımız var."

Bu cümle ransomware hazırlığı açısından başlangıçtır; cevap değildir.

Backup sistemi normal operasyonel hatalara karşı mükemmel çalışıyor olabilir fakat bilinçli olarak backup'ı yok etmeye çalışan bir saldırgana karşı aynı ölçüde dayanıklı olmayabilir.

Ransomware perspektifinde soru şudur:

Saldırgan production ortamını ele geçirdiğinde backup sistemini de etkisiz hale getirebilir mi?

Ransomware Operatörü Neden Backup'ı Hedefler?

Backup sağlam kalırsa kurumun fidye ödeme baskısı azalabilir.

Bu nedenle saldırganlar recovery seçeneklerini ortadan kaldırmaya çalışabilir.

MITRE ATT&CK bunu T1490 — Inhibit System Recovery altında tanımlar.

Hedefler arasında:

• volume shadow copy,
• snapshot,
• backup catalog,
• network backup,
• hypervisor snapshot,
• cloud backup,
• recovery configuration

bulunabilir.

Online Backup'ın Riski

Production ortamından erişilebilen backup saldırgan açısından da erişilebilir olabilir.

Örneğin aynı:

• domain,
• administrator hesabı,
• service account,
• network segmenti,
• management workstation

kullanılıyorsa üretim ortamındaki compromise backup'a sıçrayabilir.

Bu nedenle yalnızca verinin nerede tutulduğu değil, backup'ın yönetim düzleminin nasıl korunduğu da değerlendirilmelidir.

Kimlik Ayrımı

Backup yöneticisinin Domain Admin olması pratik görünebilir.

Ancak bu yaklaşım iki güvenlik alanını birbirine bağlar.

Domain ele geçirilirse backup da risk altına girebilir.

İdeal yaklaşım, backup yönetim kimliklerini mümkün olduğunca:

• günlük kullanıcı hesaplarından,
• normal server admin hesaplarından,
• Domain Admin'den

ayırmaktır.

Ayrıcalık minimum seviyede tutulmalıdır.

MFA

Backup yönetim konsolunda MFA önemli bir kontrol olmalıdır.

Özellikle:

• politika değişikliği,
• backup deletion,
• repository yönetimi,
• administrator değişikliği

gibi kritik işlemler yüksek güvence gerektirir.

Ancak MFA tek başına yeterli değildir. Ele geçirilmiş yönetim sistemi veya kötü yapılandırılmış service account gibi başka saldırı yolları bulunabilir.

Immutable Backup

Immutable backup, belirlenen retention süresi boyunca backup verisinin değiştirilmesini veya silinmesini teknik olarak sınırlandırmayı amaçlar.

Bu ransomware açısından güçlü bir kontrol olabilir.

Fakat "immutable" etiketi otomatik olarak güvenli recovery anlamına gelmez.

Şunlar ayrıca değerlendirilmelidir:

• immutability gerçekten enforce ediliyor mu?
• retention yeterli mi?
• ayrıcalıklı kullanıcı bunu değiştirebilir mi?
• backup alınırken veri zaten bozulmuş muydu?
• repository konfigürasyonu korunuyor mu?
• restore süreci test edildi mi?

Immutable fakat aylarca test edilmemiş backup operasyonel olarak yine ciddi risk taşıyabilir.

Offline veya Ayrıştırılmış Kopya

CISA ransomware rehberliği kritik verilerin offline ve şifreli backup'larının tutulmasını ve düzenli restore testlerini özellikle vurgular.

Buradaki temel amaç saldırganın production erişimi üzerinden bütün backup kopyalarını aynı anda yok edememesidir.

"Offline" organizasyona göre farklı biçimde uygulanabilir.

Önemli olan saldırganın normal production erişim yoluyla backup'ın bütün kopyalarına ulaşamamasıdır.

Backup Başarılı Mesajı Yeterli Değildir

Backup job:

SUCCESS

diyebilir.

Ama bu, recovery'nin başarılı olacağını garanti etmez.

Restore testleri şu soruları cevaplamalıdır:

• veri gerçekten okunabiliyor mu?
• uygulama çalışıyor mu?
• bağımlı sistemler mevcut mu?
• gerekli anahtarlar ve credential'lar var mı?
• yeterli altyapı kapasitesi bulunuyor mu?
• ne kadar sürede restore edilebiliyor?
• hangi backup versiyonu güvenilir?

NIST'in veri bütünlüğü rehberliği recovery sırasında doğru ve güvenilir backup versiyonunun belirlenmesini önemli bir konu olarak ele alır.

Recovery Point ile Recovery Time Farkı

Bir kurumun çok fazla backup'ı olabilir ama restore kapasitesi yetersiz olabilir.

Örneğin yüzlerce sanal makinenin tamamını tekrar ayağa kaldırmak:

• storage,
• compute,
• network,
• uzman insan kaynağı,
• bağımlılık sırası

gerektirir.

Bu yüzden backup stratejisi iş sürekliliği ile birlikte tasarlanmalıdır.

Clean Recovery

Recovery'nin aynı compromise olmuş yönetim yapısı üzerinden gerçekleştirilmesi risklidir.

Kurumlar gerektiğinde:

• temiz yönetim hesapları,
• clean workstation,
• izole recovery VLAN,
• doğrulanmış image'lar,
• güvenilir DNS/AD servisleri

kullanabilecekleri modeli önceden düşünmelidir.

Backup Logları

Backup sistemi yalnızca recovery aracı değildir.

Aynı zamanda önemli bir güvenlik telemetry kaynağıdır.

İzlenebilecek davranışlar:

• toplu backup deletion,
• retention değişikliği,
• yeni administrator,
• MFA değişikliği,
• repository erişimi,
• backup job'larının devre dışı bırakılması,
• sıra dışı login.

Bu logların saldırganın kolaylıkla silemeyeceği merkezi bir platforma gönderilmesi faydalıdır.

Kendinize Sorun

1. 01Backup yöneticileri Domain Admin mi?
2. 02Backup sistemi production domain'e bağımlı mı?
3. 03MFA var mı?
4. 04Immutable backup var mı?
5. 05Offline veya güçlü biçimde ayrıştırılmış kopya var mı?
6. 06Repository production network'ten doğrudan erişilebilir mi?
7. 07Silme işlemleri alarm üretiyor mu?
8. 08Restore ne zaman test edildi?
9. 09Restore süresi ölçüldü mü?
10. 10Kritik sistemlerin recovery sırası belli mi?
11. 11Backup logları merkezi tutuluyor mu?
12. 12Saldırgan domain'i ele geçirirse backup'ı silebilir mi?

Son soruya net cevap veremiyorsanız backup mimarisinin ransomware açısından ayrıca değerlendirilmesi gerekir.