Immutable Backup Nedir ve Neyi Çözmez?

Ransomware savunmasında son yıllarda en sık kullanılan terimlerden biri:

immutable backup.

Fikir güçlüdür:

Saldırgan backup sistemine ulaşsa bile yedek verisini değiştiremesin veya silemesin.

Fakat "immutable" kelimesi bazen backup mimarisinin bütün problemlerini çözüyormuş gibi kullanılmaktadır.

Çözmez.

Doğru tasarlanmış immutability çok önemli bir savunma katmanıdır fakat güvenilir recovery için tek başına yeterli değildir.

Immutable Ne Demek?

Genel anlamıyla belirlenen verinin belirli bir süre:

• değiştirilememesi,
• üzerine yazılamaması,
• silinememesi

amaçlanır.

Teknik uygulama platforma göre değişebilir.

Örneğin:

• object lock,
• WORM yaklaşımı,
• hardened repository,
• storage-level retention

gibi mekanizmalar kullanılabilir.

Önemli olan ürünün "immutable" etiketi değil, kontrolün saldırganın sahip olabileceği ayrıcalıklara karşı gerçekten enforce edilmesidir.

Ransomware Açısından Neden Değerli?

Ransomware operatörleri recovery mekanizmalarını hedefleyebilir.

MITRE ATT&CK bu davranışı T1490 — Inhibit System Recovery olarak sınıflandırır.

Saldırgan:

• snapshot silebilir,
• backup catalog'u bozabilir,
• recovery servislerini kapatabilir,
• network backup'larını silebilir,
• cloud backup politikalarını değiştirebilir.

Doğru immutability uygulaması bu davranışların etkisini sınırlandırabilir.

Ama Birinci Problem: Retention

Bir backup 7 gün immutable olabilir.

Saldırgan 20 gündür içerideyse ne olacak?

Eğer compromise uzun süredir devam ediyorsa retention süresi saldırı zaman çizelgesini kapsamayabilir.

Bu nedenle retention yalnızca storage maliyeti üzerinden tasarlanmamalıdır.

Risk senaryoları dikkate alınmalıdır.

İkinci Problem: Kirli Backup

Immutable backup değiştirilmemiş olabilir.

Ama backup alınırken sistem zaten compromise olmuş olabilir.

Örneğin:

• persistence mevcut,
• zararlı scheduled task var,
• webshell var,
• kötü amaçlı account var,
• konfigürasyon değiştirilmiş.

Backup teknik olarak bütünlüğünü koruyor olabilir fakat güvenilir baseline olmayabilir.

Bu nedenle recovery'de soru:

Backup mevcut mu?

değil:

Hangi backup versiyonunun güvenilir olduğunu biliyor muyuz?

olmalıdır.

NIST'in ransomware recovery çalışmalarında veri bütünlüğü ve doğru recovery versiyonunu belirleme bu nedenle önemlidir.

Üçüncü Problem: Yönetim Katmanı

Backup data immutable olsa bile:

• backup console,
• policy,
• credentials,
• encryption keys,
• retention configuration

hâlâ korunmalıdır.

Örneğin saldırgan gelecekteki backup job'larını kapatabiliyorsa bugün mevcut immutable kopyanın bulunması bütün problemi çözmez.

Bu yüzden management plane ayrı güvenlik katmanı olarak değerlendirilmelidir.

Dördüncü Problem: Kimlik

Backup admin hesabı ele geçirilirse saldırgan immutability dışındaki alanlarda önemli zarar verebilir.

Özellikle:

• policy değişikliği,
• repository ekleme/çıkarma,
• job disable,
• retention değişikliği,
• administrator oluşturma

gibi işlemler kritik olabilir.

Backup kimlikleri mümkün olduğunca production domain administrator kimliklerinden ayrılmalıdır.

Beşinci Problem: Recovery Kapasitesi

Immutable backup var.

Peki geri yükleyebilir misiniz?

Gerçek bir recovery şu kaynakları gerektirir:

• compute,
• storage,
• network,
• DNS,
• identity,
• uygulama bağımlılıkları,
• lisanslar,
• konfigürasyon,
• uzman personel.

Petabaytlarca immutable veri bulunması, bunun birkaç saat içinde production'a dönebileceği anlamına gelmez.

Altıncı Problem: Restore Testi

Backup sisteminin raporunda:

Successful

yazması restore testinin yerine geçmez.

Düzenli olarak örnek sistemlerin veya kritik servislerin restore edilmesi gerekir.

Test:

• veri bütünlüğünü,
• erişilebilirliği,
• recovery süresini,
• dependency problemlerini

ortaya çıkarır.

Immutable ve Offline Aynı Şey mi?

Hayır.

Immutable:

verinin değiştirilememesi

özelliğidir.

Offline/isolated:

normal production erişim yolundan ulaşılamaması

özelliğidir.

İki kontrol farklı riskleri azaltır.

Bir kurum ihtiyacına göre:

• immutable,
• offline,
• ayrı cloud/account,
• fiziksel medya,
• hardened repository

yaklaşımlarını birlikte kullanabilir.

Amaç bütün recovery seçeneklerinin aynı compromise domain'ine bağımlı olmamasıdır.

Immutable Backup İçin Sorulması Gereken Sorular

1. 01İmmutability teknik olarak nasıl enforce ediliyor?
2. 02Hangi privileged account bunu değiştirebilir?
3. 03Retention ne kadar?
4. 04Retention ransomware senaryosuna göre belirlendi mi?
5. 05Backup admin identity ayrı mı?
6. 06MFA kullanılıyor mu?
7. 07Repository production network'ten nasıl erişiliyor?
8. 08Backup policy değişiklikleri loglanıyor mu?
9. 09Silme girişimleri alarm üretiyor mu?
10. 10Restore düzenli test ediliyor mu?
11. 11Hangi restore point'in temiz olduğu nasıl belirlenecek?
12. 12Recovery için gerekli identity altyapısı mevcut mu?
13. 13Hypervisor da compromise olursa recovery mümkün mü?
14. 14Encryption key kaybında ne olacak?
15. 15Kritik sistemlerin recovery sırası belli mi?

İmmutability'nin Çözmediği Şeyler

Immutable backup şu problemlerin yerine geçmez:

• EDR
• network segmentation
• MFA
• privileged access management
• vulnerability management
• incident response
• logging
• clean recovery architecture
• Active Directory security.

Backup son savunma katmanlarından biridir.

İlk savunma katmanı değildir.

Sonuç

Immutable backup ransomware dayanıklılığı için son derece değerli olabilir.

Ancak şu ifade doğru değildir:

"Immutable backup aldık, ransomware problemi çözüldü."

Daha doğru ifade:

"Saldırganın recovery seçeneklerimizin tamamını yok etmesini zorlaştıran güçlü bir katman ekledik."

Ransomware dayanıklılığı ise bu katmanın diğer güvenlik ve recovery kontrolleriyle birlikte çalışmasına bağlıdır.