# Immutable Backup Nedir? Fidye Yazılımlarına Karşı Değiştirilemez Yedekler

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/backup-yedekleme-is-surekliligi/immutable-backup-nedir

![Immutable Backup Nedir? Fidye Yazılımlarına Karşı Değiştirilemez Yedekler](/images/bilgi-merkezi/covers/cover-backup-04.webp)

Fidye yazılımı saldırılarında kurumların en büyük umutlarından biri backup sistemleridir.

Üretim ortamı şifrelenmiş olabilir.

Dosya sunucuları erişilemez hale gelmiş olabilir.

Veritabanları bozulmuş olabilir.

Sanal makineler kapatılmış olabilir.

Ancak kurumun elinde temiz ve güvenli bir backup varsa saldırının etkisi önemli ölçüde azaltılabilir.

Tam da bu nedenle modern ransomware grupları artık yalnızca production sistemlerini hedeflememektedir.

Backup sunucuları da saldırı zincirinin kritik hedeflerinden biri haline gelmiştir.

Saldırgan açısından mantık oldukça basittir.

Eğer kurumun yedekleri sağlam kalırsa fidye ödeme ihtimali düşer.

Eğer yedekler silinir, bozulur veya şifrelenirse kurumun kurtarma seçenekleri azalır.

Bu nedenle gelişmiş saldırılarda saldırganlar;

backup server,

backup administrator hesapları,

snapshot sistemleri,

storage cihazları,

backup repository'leri,

cloud backup hesapları,

hypervisor yönetim katmanı

gibi sistemleri keşfetmeye çalışabilir.

Bu noktada modern yedekleme mimarisinin en kritik kavramlarından biri ortaya çıkar:

#### Immutable Backup

Yani:

**Değiştirilemez Yedekleme.**

Immutable backup yaklaşımının temel amacı, backup kopyalarının belirlenen bir süre boyunca silinememesi, değiştirilememesi veya üzerine yazılamamasıdır.

Bu sayede saldırgan yüksek yetki elde etse bile kurumun en azından belirli restore point'lerini koruması hedeflenir.

### Immutable Backup Nedir?

Immutable Backup, belirli bir retention süresi boyunca değiştirilemeyen ve normal operasyonel yollarla silinemeyen yedek kopyasıdır.

“Immutable” kelimesi İngilizcede:

**değiştirilemez**

anlamına gelir.

Örneğin bir backup kopyası 30 günlük immutable retention ile oluşturulduysa bu backup, yapılandırılan koruma süresi boyunca silinmeye veya değiştirilmeye karşı korunur.

Bu durum özellikle ransomware saldırılarında büyük avantaj sağlar.

Çünkü saldırgan;

backup konsoluna erişse,

yüksek yetkili bir hesap ele geçirse,

repository'yi keşfetse

bile immutable olarak kilitlenmiş backup kopyalarını doğrudan silemeyebilir.

### Immutable Backup Neden Ortaya Çıktı?

Klasik backup sistemleri esas olarak operasyonel veri kayıplarına karşı tasarlanmıştı.

Örneğin:

- yanlışlıkla dosya silinmesi,
- disk arızası,
- veritabanı bozulması,
- uygulama hatası,
- donanım problemi.

Bu senaryolarda saldırgan yoktur.

Backup sistemi teknik bir kurtarma mekanizmasıdır.

Ancak modern siber tehdit modeli tamamen farklıdır.

Artık sistemde bilinçli olarak hareket eden bir saldırgan vardır.

Bu saldırgan backup sisteminin ne işe yaradığını bilir.

Hangi ürünün kullanıldığını tespit edebilir.

Backup repository'nin nerede olduğunu keşfedebilir.

Administrator credential'larını ele geçirmeye çalışabilir.

Retention politikalarını değiştirebilir.

Snapshot'ları silebilir.

Restore point'lerini hedefleyebilir.

Dolayısıyla klasik backup mantığının üzerine yeni bir katman eklenmesi gerekmiştir:

**Backup'ın saldırgana karşı korunması.**

Immutable backup bu ihtiyacın sonucudur.

### Ransomware Saldırganı Neden Önce Backup'a Gider?

Gelişmiş ransomware saldırılarında şifreleme çoğu zaman saldırının ilk adımı değildir.

Saldırgan önce ortamı tanımaya çalışır.

Örnek bir saldırı zinciri şöyle olabilir:

İlk erişim sağlanır.

Kullanıcı hesabı ele geçirilir.

Yetkiler yükseltilir.

Domain yapısı keşfedilir.

Administrator credential'ları hedeflenir.

Backup sunucuları tespit edilir.

Storage altyapısı keşfedilir.

Backup administrator hesapları ele geçirilmeye çalışılır.

Snapshot'lar veya restore point'ler hedeflenir.

Kritik veriler dışarı çıkarılır.

En son üretim sistemleri şifrelenir.

Bu sıranın önemli bir nedeni vardır.

Saldırgan şifreleme işlemine çok erken başlarsa güvenlik ekipleri olayı fark edebilir.

Ancak önce backup sistemini sabote ederse saldırının etkisi çok daha büyük olur.

### Immutable Backup Nasıl Çalışır?

Immutable backup farklı teknolojilerle uygulanabilir.

Temel prensip her zaman aynıdır:

Backup verisi oluşturulduktan sonra belirlenen süre boyunca değiştirilemez hale getirilir.

Örneğin:

#### Backup oluşturuldu: 1 Ağustos

#### Retention süresi: 30 gün

Bu durumda backup dosyası 31 Ağustos'a kadar koruma altında tutulabilir.

Bu süre içerisinde normal kullanıcı veya administrator tarafından;

silme,

değiştirme,

üzerine yazma

işlemleri engellenebilir.

Bu yapı ürün ve storage teknolojisine göre farklı şekillerde uygulanabilir.

### WORM Storage Nedir?

Immutable backup dünyasında sık kullanılan kavramlardan biri:

#### WORM

yani:

#### Write Once, Read Many

yaklaşımıdır.

Türkçeye kabaca:

#### Bir kez yaz, birçok kez oku

olarak çevrilebilir.

WORM storage üzerinde veri yazıldıktan sonra belirli süre boyunca değiştirilemez.

Bu teknoloji finans, sağlık, arşivleme ve regülasyon gerektiren sektörlerde uzun süredir kullanılmaktadır.

Modern ransomware savunmasında da son derece değerlidir.

Backup bir kez WORM storage üzerine yazıldığında saldırganın o veriyi değiştirmesi veya silmesi ciddi şekilde zorlaştırılır.

### Object Lock Nedir?

Cloud ve object storage sistemlerinde kullanılan önemli immutable mekanizmalardan biri **Object Lock** teknolojisidir.

Object Lock belirli object'lerin belirli süre boyunca değiştirilememesini veya silinememesini sağlar.

Örneğin backup dosyaları object storage üzerinde tutuluyorsa bu dosyalara:

#### 30 gün Object Lock

uygulanabilir.

Bu süre boyunca backup object'i silme taleplerine karşı korunabilir.

Bu yöntem özellikle S3 uyumlu object storage mimarilerinde yaygın şekilde kullanılmaktadır.

### Retention Lock Nedir?

Retention Lock, backup verisinin saklama süresinin güvenli şekilde kilitlenmesini ifade eder.

Örneğin bir backup'a:

#### 90 günlük retention

uygulanmış olsun.

Normal bir backup sisteminde administrator retention süresini değiştirebilir.

Ancak güçlü bir retention lock yapılandırmasında bu sürenin sonradan kısaltılması engellenebilir.

Bu özellikle saldırganın administrator hesabını ele geçirmesi durumunda önemlidir.

Çünkü saldırganın amacı genellikle:

**Retention = 0**

veya çok kısa bir süre belirleyip backup'ların silinmesini sağlamaktır.

Retention lock bu riski azaltmayı hedefler.

### Governance Mode ve Compliance Mode

Bazı object lock sistemlerinde farklı immutable modları bulunabilir.

Genel olarak iki yaklaşım görülür:

#### Governance Mode

Belirli yüksek yetkili kullanıcılar gerektiğinde immutable korumayı kaldırabilir.

Bu operasyonel esneklik sağlar.

Ancak saldırgan bu özel yetkiye erişirse koruma aşılabilir.

#### Compliance Mode

Retention süresi boyunca korumanın kaldırılması çok daha sıkı şekilde sınırlandırılır.

Bu mod regülasyon ve yüksek güvenlik gerektiren ortamlarda daha güçlü koruma sağlayabilir.

Ancak yanlış retention ayarı yapılırsa verinin süre dolmadan silinememesi operasyonel sorun oluşturabilir.

Bu nedenle immutable tasarım dikkatli yapılmalıdır.

### Immutable Backup ile Air-Gap Aynı Şey midir?

Hayır.

Bu iki kavram birbirine yakın görünse de farklıdır.

#### Immutable Backup

Backup erişilebilir olabilir ancak değiştirilemez.

#### Air-Gap Backup

Backup üretim ortamından izole edilir.

Örneğin object storage üzerinde bulunan bir immutable backup network üzerinden erişilebilir olabilir.

Ancak retention süresi boyunca silinemez.

Tape üzerinde bulunan offline backup ise fiziksel air-gap sağlayabilir.

En güçlü mimarilerde iki yaklaşım birlikte kullanılabilir.

Yani backup:

**hem immutable**

hem de

**izole**

olabilir.

### Immutable Backup ile Offline Backup Arasındaki Fark

Offline backup network üzerinde sürekli erişilebilir değildir.

Immutable backup ise erişilebilir olsa bile değiştirilemez.

Bu iki yöntem farklı riskleri azaltır.

Offline backup saldırganın erişimini zorlaştırır.

Immutable backup ise erişim gerçekleşse bile verinin değiştirilmesini zorlaştırır.

Dolayısıyla:

#### Access Protection + Modification Protection

birlikte sağlanabilir.

### Hardened Repository Nedir?

Modern backup güvenliğinde sık kullanılan kavramlardan biri de:

#### Hardened Repository

yaklaşımıdır.

Hardened repository, saldırı yüzeyi azaltılmış ve özel güvenlik kontrolleriyle güçlendirilmiş backup depolama sistemidir.

Bu tür sistemlerde;

minimum servis,

sınırlı network erişimi,

ayrı administrator hesapları,

MFA,

SSH kısıtlaması,

root erişiminin sınırlandırılması,

immutable file system özellikleri,

ayrı credential yapısı

kullanılabilir.

Amaç backup repository'yi sıradan bir file server olmaktan çıkarmaktır.

### Backup Repository Domain'e Dahil Edilmeli mi?

Bu konu backup güvenliğinin en önemli tasarım kararlarından biridir.

Kritik ortamlarda backup repository'nin production Active Directory domain'ine dahil edilmesi risk oluşturabilir.

Neden?

Çünkü saldırgan Domain Admin yetkisini ele geçirirse domain'e bağlı birçok sisteme erişebilir.

Eğer backup repository de aynı domain içerisindeyse saldırganın kurtarma altyapısına erişmesi kolaylaşabilir.

Bu nedenle modern backup güvenliğinde:

#### Domain Separation

yaklaşımı değerlendirilebilir.

Backup sistemi;

ayrı credential,

ayrı local administrator,

ayrı authentication domain

veya izole kimlik yönetimi

kullanabilir.

Temel hedef şudur:

**Production domain'in compromise olması backup domain'in compromise olması anlamına gelmemeli.**

### Backup Administrator Hesapları Ayrılmalı mı?

Evet.

Backup administrator hesabının günlük kullanılan Domain Admin hesabıyla aynı olması ciddi risk oluşturabilir.

Örneğin bir yönetici:

user@company.com

hesabıyla hem e-posta kullanıyor hem de backup sistemini yönetiyor olsun.

Phishing saldırısıyla bu hesap ele geçirilirse saldırgan backup sistemine erişebilir.

Bunun yerine:

günlük kullanıcı hesabı,

server administrator hesabı,

backup administrator hesabı

ayrı tutulmalıdır.

Bu yaklaşım **Privileged Access Separation** prensibidir.

### MFA Backup Sistemlerinde Zorunlu mu?

Kritik backup sistemlerinde Multi-Factor Authentication güçlü şekilde önerilmelidir.

Çünkü backup administrator hesabı yüksek değerli bir hesaptır.

Parola ele geçirilse bile MFA ikinci güvenlik katmanı oluşturur.

Ancak MFA tek başına yeterli değildir.

Saldırgan session token çalabilir.

Administrator cihazını ele geçirebilir.

MFA fatigue saldırıları yapılabilir.

Bu nedenle MFA;

PAM,

network segmentation,

conditional access,

ayrı yönetim istasyonları

gibi kontrollerle desteklenmelidir.

### Privileged Access Management Backup Güvenliğinde Nasıl Kullanılır?

PAM sistemleri yüksek yetkili hesapların kontrollü şekilde kullanılmasını sağlar.

Backup administrator erişimleri PAM üzerinden yönetilebilir.

Örneğin:

kullanıcı doğrudan backup administrator parolasını bilmez.

PAM sistemi geçici erişim sağlar.

Session kaydedilebilir.

Komutlar loglanabilir.

Yetki belirli süreyle verilebilir.

Bu yaklaşım saldırganın kalıcı administrator credential'ı ele geçirmesini zorlaştırır.

### Backup Yönetimi İçin Ayrı Yönetim İstasyonu Kullanılmalı mı?

Yüksek güvenlik gereken ortamlarda evet.

Backup yönetim konsoluna sıradan kullanıcı bilgisayarlarından erişmek risklidir.

Örneğin administrator aynı bilgisayardan;

e-posta okuyorsa,

internet kullanıyorsa,

dosya indiriyorsa

phishing veya malware nedeniyle yönetim credential'ları risk altında olabilir.

Bu nedenle:

#### Privileged Access Workstation – PAW

veya

#### Secure Admin Workstation

kullanılabilir.

Backup yönetimi yalnızca bu güvenli sistemlerden yapılabilir.

### Backup Network Segmentasyonu Neden Önemlidir?

Backup altyapısı üretim network'üyle tamamen iç içe olmamalıdır.

Örneğin tüm kullanıcı VLAN'larından backup server'a erişim olması ciddi risktir.

Bunun yerine ayrı:

backup VLAN,

firewall zone,

management network

kullanılabilir.

Erişimler yalnızca gerekli portlarla sınırlandırılmalıdır.

Firewall üzerinde allow-list yaklaşımı uygulanabilir.

Bu yöntem saldırganın lateral movement ile backup sistemine ulaşmasını zorlaştırır.

### Backup Server İnternete Açık Olmalı mı?

Genellikle doğrudan internete açık olmamalıdır.

Backup yönetim arayüzlerinin internet üzerinden erişilebilir olması saldırı yüzeyini önemli ölçüde artırır.

Uzaktan erişim gerekiyorsa;

VPN,

Zero Trust Network Access,

MFA,

jump server,

privileged access gateway

gibi güvenli yöntemler kullanılmalıdır.

### Immutable Backup Şifrelenmeli mi?

Evet.

Immutable olmak gizlilik sağlamaz.

Bir backup değiştirilemez olabilir ancak saldırgan backup dosyasını okuyabiliyorsa veri ihlali yaşanabilir.

Bu nedenle backup verileri:

#### At Rest

ve

#### In Transit

şifrelenmelidir.

Özellikle backup repository içerisinde;

müşteri verileri,

kişisel veriler,

finansal kayıtlar,

e-posta,

ERP verileri,

ticari sırlar

bulunabilir.

Bu nedenle encryption backup güvenliğinin temel parçasıdır.

### Encryption Key Yönetimi Neden Kritik?

Backup şifreleme anahtarları korunmalıdır.

Eğer saldırgan encryption key'i ele geçirirse backup verilerini okuyabilir.

Eğer kurum encryption key'i kaybederse kendi backup'ını restore edemeyebilir.

Bu nedenle key yönetimi;

güvenli saklama,

yedekleme,

erişim kontrolü,

rotasyon,

ayrı yetkilendirme

süreçlerini içermelidir.

Kritik ortamlarda HSM veya merkezi key management sistemleri kullanılabilir.

### Immutable Backup Her Şeyi Çözer mi?

Hayır.

Immutable backup çok güçlü bir koruma katmanıdır ancak tek başına yeterli değildir.

Örneğin kurumun 7 günlük immutable backup retention'ı olsun.

Saldırgan sistemde 30 gündür bulunuyor olabilir.

Bu durumda son 7 günlük backup'ların tamamında saldırganın persistence mekanizması bulunabilir.

Backup dosyaları değiştirilemez olsa bile:

**temiz olmayabilir.**

Bu nedenle immutable backup ile birlikte threat detection ve incident response süreçleri de önemlidir.

### Clean Restore Point Nedir?

Clean Restore Point, saldırganın veya malware'in bulunmadığı doğrulanmış backup noktasıdır.

Ransomware sonrası recovery sürecinin en kritik sorularından biri:

**“Hangi backup temiz?”**

sorusudur.

En yeni backup her zaman en iyi backup değildir.

Örneğin saldırgan sisteme 1 Temmuz'da girdi.

Ransomware 20 Temmuz'da çalıştırıldı.

19 Temmuz backup'ı teknik olarak sağlam olabilir.

Ancak saldırganın backdoor'u backup içerisinde bulunabilir.

Bu nedenle incident response ekibi saldırganın ilk erişim zamanını belirlemeye çalışır.

Buna göre restore için güvenli bir nokta seçilir.

### Backup İçerisinde Malware Taraması Yapılmalı mı?

Mümkünse evet.

Modern recovery sistemlerinde backup verileri restore edilmeden önce malware veya IOC taramasından geçirilebilir.

Örneğin backup içerisindeki:

dosyalar,

registry,

startup entries,

script dosyaları,

scheduled tasks

analiz edilebilir.

Bu yaklaşım:

#### Secure Restore

veya

#### Clean Room Recovery

stratejilerinin parçası olabilir.

### Clean Room Recovery Nedir?

Clean Room Recovery, siber saldırı sonrası sistemlerin izole ve güvenilir bir ortamda restore edilmesi yaklaşımıdır.

Amaç compromised production ortamına doğrudan restore yapmamaktır.

Örneğin ayrı bir network oluşturulur.

Temiz kimlik altyapısı hazırlanır.

Backup restore edilir.

Malware taraması yapılır.

Sistem kontrolleri gerçekleştirilir.

Uygulamalar test edilir.

Daha sonra kontrollü şekilde production'a alınır.

Bu yöntem özellikle büyük ransomware olaylarında önemlidir.

### Cyber Recovery Vault Nedir?

Cyber Recovery Vault, kritik backup kopyalarının yüksek izolasyonlu özel bir kurtarma ortamında tutulması yaklaşımıdır.

Bu ortam production sistemlerinden mümkün olduğunca bağımsızdır.

Örneğin;

ayrı kimlik altyapısı,

network izolasyonu,

immutable storage,

sınırlı erişim,

MFA,

ayrı administrator hesapları

kullanılabilir.

Cyber Recovery Vault'un amacı yalnızca backup saklamak değildir.

**Siber saldırı sonrası güvenilir kurtarma noktası oluşturmak**tır.

### Immutable Backup Retention Süresi Ne Olmalı?

Tek bir doğru süre yoktur.

Retention süresi kurumun risk profilinə göre belirlenmelidir.

Örneğin;

14 gün,

30 gün,

60 gün,

90 gün

gibi süreler kullanılabilir.

Ancak doğru süre belirlenirken saldırganların ağ içerisinde fark edilmeden kalabileceği süre de değerlendirilmelidir.

Eğer kurum yalnızca 7 günlük immutable backup tutuyor fakat saldırıların ortalama fark edilme süresi daha uzunsa temiz restore point bulunamayabilir.

Bu nedenle retention stratejisi yalnızca storage maliyetine göre belirlenmemelidir.

### Immutable Backup ve RPO Arasındaki İlişki

Immutable backup retention süresi ile RPO aynı şey değildir.

RPO:

ne kadar veri kaybının kabul edilebilir olduğunu

ifade eder.

Immutable retention ise:

backup'ın ne kadar süre değiştirilemez şekilde korunacağını

ifade eder.

Örneğin:

RPO = 1 saat

Immutable Retention = 30 gün

olabilir.

Yani saatlik backup alınır ve bu backup'lar belirli politika kapsamında 30 gün boyunca korunabilir.

### Immutable Backup ve RTO Arasındaki İlişki

Immutable backup veriyi korur ancak restore hızını otomatik olarak garanti etmez.

Örneğin immutable backup çok yavaş bir archive storage üzerinde bulunuyorsa restore saatler sürebilir.

Bu nedenle RTO açısından;

storage performansı,

network bandwidth,

restore architecture,

instant recovery,

DR altyapısı

gibi faktörler değerlendirilmelidir.

### Immutable Backup Bulutta Kullanılabilir mi?

Evet.

Cloud object storage immutable backup için sık kullanılan seçeneklerden biridir.

Object Lock veya benzeri mekanizmalar sayesinde backup object'leri belirli süre silinmeye karşı korunabilir.

Ancak cloud backup'ta özellikle:

IAM,

MFA,

ayrı account,

API key güvenliği,

audit logging,

encryption,

retention lock

kontrolleri doğru yapılandırılmalıdır.

### Production ve Backup Aynı Cloud Account'ta Olmalı mı?

Kritik sistemlerde ayrı hesap yaklaşımı tercih edilebilir.

Örneğin:

#### Production Account

ve

#### Backup Account

ayrı tutulabilir.

Saldırgan production cloud administrator yetkisini ele geçirse bile backup account'a otomatik erişememelidir.

Bu yaklaşım:

#### Blast Radius Reduction

yani saldırının etki alanını küçültme prensibidir.

### Immutable Backup'ta En Sık Yapılan Hatalar

Kurumlarda sık karşılaşılan hatalar şunlardır:

- immutable özelliğini açıp mimariyi değiştirmemek,
- backup administrator hesabını production hesabıyla aynı tutmak,
- MFA kullanmamak,
- retention süresini çok kısa belirlemek,
- backup repository'yi production domain'e dahil etmek,
- internet erişimini gereksiz açık bırakmak,
- backup network'ünü segmentlere ayırmamak,
- encryption key'leri aynı sistemde tutmak,
- restore testi yapmamak,
- immutable backup'ı temiz backup zannetmek,
- ransomware sonrası doğrudan production'a restore yapmak.

Bu hatalar immutable teknolojinin sağladığı avantajı ciddi şekilde azaltabilir.

### Immutable Backup Nasıl Test Edilir?

Immutable backup yalnızca teorik olarak kontrol edilmemelidir.

Test yapılmalıdır.

Örneğin kontrollü ortamda;

backup silinmeye çalışılabilir,

retention değiştirilmeye çalışılabilir,

administrator hesabıyla silme testi yapılabilir,

repository erişimleri kontrol edilebilir,

restore işlemi yapılabilir.

Amaç sistemin gerçekten beklenen korumayı sağladığını doğrulamaktır.

### Backup Restore Testi Ne Kadar Sık Yapılmalı?

Test sıklığı sistemin kritikliğine göre belirlenmelidir.

Kritik Tier 1 sistemlerde daha sık restore testleri yapılabilir.

Örneğin;

aylık,

üç aylık,

altı aylık

tatbikatlar uygulanabilir.

Ancak yalnızca teknik restore yeterli değildir.

Belirli aralıklarla gerçek:

#### Disaster Recovery Exercise

yani felaket kurtarma tatbikatı yapılmalıdır.

### Zero Trust Backup Nedir?

Zero Trust Backup, backup altyapısına Zero Trust prensiplerinin uygulanmasıdır.

Temel yaklaşım şudur:

**Hiçbir kullanıcı veya cihaz otomatik olarak güvenilir kabul edilmez.**

Backup yönetim erişimleri sürekli doğrulanır.

Minimum yetki uygulanır.

Kimlikler ayrılır.

MFA kullanılır.

Network segmentasyonu uygulanır.

Kritik işlemler loglanır.

Administrator erişimleri kontrollü hale getirilir.

Bu sayede backup altyapısı kurumun en korunan sistemlerinden biri haline gelir.

### Backup Sistemleri SIEM ile İzlenmeli mi?

Evet.

Backup sistemlerinde gerçekleşen kritik işlemler SIEM veya merkezi log yönetim sistemine gönderilebilir.

Örneğin;

backup job silinmesi,

retention değişikliği,

repository silme işlemi,

administrator oluşturulması,

MFA devre dışı bırakılması,

login failure,

backup policy değişikliği

alarm üretebilir.

Bu sayede saldırgan backup sistemini sabote etmeye çalışırken erken tespit edilebilir.

### Backup Güvenliği EDR ile Desteklenebilir mi?

Backup sunucularında uygun şekilde yapılandırılmış EDR/XDR çözümleri kullanılabilir.

Ancak backup ürününün performans ve uyumluluk gereksinimleri dikkate alınmalıdır.

Amaç;

credential theft,

malware execution,

lateral movement,

suspicious PowerShell,

ransomware behavior

gibi aktiviteleri tespit etmektir.

Backup sunucusunun “güvenilir sistem” olduğu düşünülerek izleme dışı bırakılması ciddi risk oluşturabilir.

### Ransomware Sonrası Restore Sırası Nasıl Belirlenmeli?

Kurum tüm sistemleri aynı anda restore edemez.

Bu nedenle önceliklendirme yapılmalıdır.

Örneğin:

- Kimlik altyapısı
- DNS ve temel network servisleri
- Kritik database sistemleri
- ERP
- Finansal uygulamalar
- Dosya sistemleri
- Kullanıcı servisleri

şeklinde bir recovery priority oluşturulabilir.

Bu sıralama Business Impact Analysis sonucunda belirlenmelidir.

### Active Directory Backup Neden Özellikle Kritiktir?

Active Directory birçok kurumun merkezi kimlik altyapısıdır.

AD tamamen kaybedilirse;

kullanıcı login işlemleri,

server authentication,

group policy,

uygulama erişimleri,

service account'lar

etkilenebilir.

Bu nedenle AD backup ve recovery senaryoları ayrı test edilmelidir.

Sadece domain controller VM snapshot'ına güvenmek riskli olabilir.

AD için uygun backup ve forest recovery prosedürü oluşturulmalıdır.

### Immutable Backup Regülasyon Açısından Neden Önemlidir?

Birçok regülasyon ve güvenlik standardı doğrudan “immutable backup kullanın” demese bile veri bütünlüğü, iş sürekliliği, dayanıklılık ve kurtarma kontrolleri talep eder.

Örneğin;

ISO/IEC 27001,

ISO 22301,

DORA,

KVKK,

PCI DSS

gibi çerçeveler backup ve recovery süreçlerini farklı perspektiflerden ele alabilir.

Özellikle finans ve kritik altyapı sektörlerinde cyber resilience gereksinimleri immutable ve izole backup mimarilerinin önemini artırmaktadır.

### ISO 27001 Açısından Immutable Backup

ISO/IEC 27001 kapsamında backup yönetiminin kontrollü ve test edilmiş şekilde yürütülmesi önemlidir.

Kurumun;

backup politikası,

retention süresi,

erişim kontrolü,

restore prosedürü,

test sonuçları,

sorumlulukları

dokümante edilmelidir.

Immutable backup bu yapının teknik güvenlik katmanlarından biri olabilir.

### ISO 22301 Açısından Immutable Backup

ISO 22301 iş sürekliliği odaklıdır.

Bir felaket sonrasında kritik süreçlerin devam ettirilmesini hedefler.

Immutable backup;

kritik verinin kaybedilmesini önleyerek,

felaket kurtarma sürecini destekleyerek,

iş sürekliliğinin sağlanmasına katkıda bulunur.

Ancak ISO 22301 perspektifinde backup tek başına yeterli değildir.

Personel,

lokasyon,

tedarikçi,

iletişim,

operasyon süreçleri

de değerlendirilmelidir.

### DORA ve Siber Dayanıklılık Perspektifi

Finans sektöründe dijital operasyonel dayanıklılık kavramı giderek daha önemli hale gelmiştir.

Kurumların yalnızca siber saldırıyı engellemesi değil, saldırı gerçekleştiğinde operasyonlarını sürdürebilmesi beklenmektedir.

Bu nedenle;

backup,

DR,

restore testi,

resilience testing,

incident response

bir bütün olarak ele alınmalıdır.

Immutable backup da bu dayanıklılık modelinin önemli teknik bileşenlerinden biridir.

### En Kritik Soru: Saldırgan Backup'ı Silebilir mi?

Backup tasarımında sorulabilecek en değerli sorulardan biri budur:

**“Domain Admin hesabı saldırganın elindeyse backup'larımızı silebilir mi?”**

Eğer cevap:

**“Evet”**

ise backup mimarisinde önemli bir güvenlik açığı bulunabilir.

İkinci soru:

**“Backup administrator hesabı ele geçirilirse bütün restore point'ler silinebilir mi?”**

Üçüncü soru:

**“Production cloud account compromise olursa backup account da kaybedilir mi?”**

Bu sorular kurumun gerçek cyber recovery seviyesini ortaya çıkarır.

### Sonuç: Backup'ın Var Olması Yetmez, Saldırgandan Korunması Gerekir

Modern ransomware saldırıları backup dünyasını tamamen değiştirmiştir.

Artık saldırgan yalnızca production sistemlerini şifrelemiyor.

Kurtarma altyapısını da hedefliyor.

Bu nedenle kurumların yalnızca:

**“Backup alıyoruz.”**

demesi yeterli değildir.

Asıl soru şudur:

**“Saldırgan sistemlerimizi ele geçirdiğinde backup'larımızı da ele geçirebilir mi?”**

Immutable Backup bu soruya verilen en güçlü teknik cevaplardan biridir.

Ancak gerçek koruma yalnızca immutable özelliğini aktif etmekle sağlanmaz.

Etkili bir mimaride;

**Immutable Storage,**

**WORM,**

**Object Lock,**

**Retention Lock,**

**Hardened Repository,**

**MFA,**

**ayrı administrator hesapları,**

**network segmentation,**

**encryption,**

**offsite backup,**

**air-gap**

ve **restore testleri**

birlikte değerlendirilmelidir.

Modern backup güvenliğinin temel prensibi oldukça nettir:

**Production ortamı kaybedilebilir. Backup ortamı kaybedilmemelidir.**

Ve daha da önemlisi:

**Backup yalnızca var olmamalı; temiz, güvenli ve gerçekten geri yüklenebilir olmalıdır.**