# Ransomware Saldırılarında Backup: Saldırganlar Yedekleri Nasıl Hedef Alıyor?

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/backup-yedekleme-is-surekliligi/ransomware-saldirilarinda-backup-hedefleme

![Ransomware Saldırılarında Backup: Saldırganlar Yedekleri Nasıl Hedef Alıyor?](/images/bilgi-merkezi/covers/cover-backup-06.webp)

Ransomware saldırıları uzun süre yalnızca dosyaların şifrelenmesi üzerinden değerlendirildi.

Bir kullanıcının bilgisayarı enfekte olur.

Dosyalar şifrelenir.

Ekranda fidye notu çıkar.

Backup varsa geri dönülür.

Bu klasik senaryo bugün hâlâ mümkündür ancak gelişmiş ransomware operasyonları artık çok daha farklı çalışmaktadır.

Modern saldırganın hedefi yalnızca veriyi şifrelemek değildir.

Asıl amaç kurumun **kurtarma kapasitesini yok etmektir.**

Çünkü kurumun sağlam, temiz ve güvenli bir backup'ı varsa saldırganın pazarlık gücü azalır.

Kurum sistemlerini birkaç saat veya birkaç gün içerisinde geri getirebiliyorsa fidye ödeme ihtimali de düşebilir.

Bu nedenle gelişmiş ransomware operasyonlarında saldırganlar artık özellikle şu sistemleri hedeflemektedir:

- backup sunucuları,
- backup administrator hesapları,
- storage sistemleri,
- hypervisor altyapısı,
- snapshot'lar,
- backup repository'leri,
- cloud backup hesapları,
- Active Directory,
- credential kasaları,
- DR altyapısı.

Bu değişim backup güvenliğini klasik veri koruma yaklaşımından çıkarıp doğrudan **siber güvenliğin bir parçası** haline getirmiştir.

Bugün bir backup çözümünün başarısı yalnızca şu soruyla ölçülmemelidir:

**“Backup alıyor muyuz?”**

Asıl soru şudur:

**“Saldırgan içeri girdiğinde bu backup'ları silebilir mi?”**

### Ransomware Saldırısı Gerçekte Nasıl İlerler?

Birçok kurum ransomware saldırısını tek aşamalı düşünür.

Gerçekte saldırı haftalar sürebilir.

Saldırgan içeri girdikten sonra hemen şifreleme yapmayabilir.

Örnek bir saldırı süreci şu şekilde ilerleyebilir:

#### \1. İlk Erişim

Saldırgan kuruma ilk erişimi sağlar.

Bu erişim;

phishing,

zayıf parola,

ele geçirilmiş VPN hesabı,

internete açık sistem zafiyeti,

credential stuffing,

RDP,

supply chain

gibi yöntemlerle gerçekleşebilir.

Bu aşamada saldırgan genellikle düşük yetkilidir.

Henüz backup sistemine erişimi olmayabilir.

### \2. Persistence Oluşturma

Saldırgan ilk erişimi kaybetmemek için persistence mekanizmaları oluşturmaya çalışabilir.

Örneğin;

yeni kullanıcı hesabı,

scheduled task,

service,

registry değişikliği,

web shell,

remote management tool

kullanılabilir.

Amaç kurum saldırganın ilk giriş noktasını kapatsa bile içeride kalabilmektir.

### \3. Credential Discovery

Ransomware saldırılarının en kritik aşamalarından biri credential erişimidir.

Saldırgan;

kullanıcı parolaları,

administrator credential'ları,

service account'lar,

stored password'ler,

browser credential'ları,

cached credential'lar

gibi bilgileri toplamaya çalışabilir.

Çünkü backup altyapısına erişmek için çoğu zaman yüksek yetkili hesap gerekir.

### Credential Dumping Nedir?

Credential Dumping, işletim sistemi veya uygulamalardan parola, hash veya authentication materyali çıkarılması yöntemidir.

Windows ortamlarda saldırganlar LSASS gibi süreçleri hedefleyebilir.

Ayrıca;

SAM,

NTDS.dit,

browser password store,

registry,

memory

gibi kaynaklardan credential toplamaya çalışabilir.

Saldırganın amacı çoğu zaman doğrudan parola değildir.

Bir NTLM hash veya session token da saldırıyı devam ettirmek için yeterli olabilir.

Bu nedenle backup administrator hesabının credential güvenliği son derece kritiktir.

### \4. Privilege Escalation

Saldırgan düşük yetkili bir kullanıcıdan:

Local Administrator

ve ardından:

Domain Administrator

seviyesine ulaşmaya çalışabilir.

Bu aşama özellikle backup güvenliği açısından kritiktir.

Çünkü birçok kurumda backup altyapısı Active Directory ile doğrudan entegredir.

Eğer Domain Admin backup sistemini de yönetebiliyorsa saldırgan tek hesapla tüm kurtarma altyapısına erişebilir.

### \5. Active Directory Discovery

Saldırgan Active Directory yapısını analiz edebilir.

Örneğin;

domain controller'lar,

administrator grupları,

service account'lar,

backup operator grupları,

GPO'lar,

sunucu isimleri,

network share'leri

tespit edilebilir.

Bu keşif saldırganın hangi hesapların backup altyapısında yetkili olduğunu anlamasına yardımcı olur.

### Backup Operators Grubu Neden Kritik?

Windows ortamlarında backup işlemleri için özel yetkiler bulunabilir.

Saldırgan bu grupları inceleyerek hangi hesapların backup sistemlerinde kullanıldığını öğrenebilir.

Bazı kurumlarda backup service account'larına gereğinden fazla yetki verilmesi saldırı yüzeyini artırabilir.

Bu nedenle service account'larda:

#### Least Privilege

yaklaşımı uygulanmalıdır.

### \6. Network Discovery

Saldırgan kurum ağını tarayabilir.

Amaç;

sunucular,

storage sistemleri,

backup appliance'lar,

NAS,

hypervisor,

management interface'leri

tespit etmektir.

Backup sistemleri çoğu zaman isimlerinden bile anlaşılabilir.

Örneğin:

backup01

veeam01

repository01

nas-backup

dr-backup

gibi isimler saldırgana doğrudan ipucu verebilir.

Bu nedenle yalnızca isim gizlemek çözüm değildir.

Asıl çözüm erişimi sınırlandırmaktır.

### \7. Backup Discovery

Bu aşama modern ransomware operasyonlarında kritik öneme sahiptir.

Saldırgan sistem içerisinde hangi backup teknolojisinin kullanıldığını tespit etmeye çalışabilir.

Örneğin;

çalışan servisler,

installed software,

Windows services,

process list,

network connections,

DNS kayıtları,

registry,

file system

incelenebilir.

Amaç backup ürününü ve yönetim sunucusunu belirlemektir.

### Backup Ürününün Bilinmesi Neden Tehlikelidir?

Bir saldırgan hangi backup yazılımının kullanıldığını öğrendiğinde o ürünün mimarisini araştırabilir.

Backup;

hangi portları kullanıyor,

hangi servis hesaplarıyla çalışıyor,

repository nerede,

config dosyaları nerede,

credential'lar nasıl tutuluyor

gibi bilgileri analiz edebilir.

Bu nedenle backup sunucuları kritik güvenlik sistemi olarak değerlendirilmelidir.

### \8. Backup Administrator Account Hedefleme

Saldırganın en değerli hedeflerinden biri backup administrator hesabıdır.

Çünkü bu hesap genellikle;

backup job oluşturabilir,

repository silebilir,

retention değiştirebilir,

restore point silebilir,

backup policy değiştirebilir.

Eğer bu hesap günlük kullanıcı hesabıyla aynıysa risk daha da büyür.

Bu nedenle backup admin hesaplarının kesinlikle ayrılması gerekir.

### Aynı Hesapla E-Posta ve Backup Yönetimi Neden Tehlikelidir?

Örneğin bir IT yöneticisi:

admin@firma.com

hesabıyla hem Outlook kullanıyor hem backup konsoluna giriyor olsun.

Phishing saldırısı bu hesabı ele geçirirse saldırgan doğrudan backup sistemine erişebilir.

Bu nedenle:

normal kullanıcı hesabı,

server admin hesabı,

backup admin hesabı

ayrı olmalıdır.

### \9. Hypervisor Hedefleme

Birçok kurum sanal altyapı kullanır.

Dolayısıyla saldırgan yalnızca backup sistemini değil hypervisor yönetimini de hedefleyebilir.

Örneğin;

VMware,

Hyper-V,

KVM

gibi ortamların yönetim katmanı ele geçirilirse saldırgan çok sayıda sanal makineyi aynı anda etkileyebilir.

Hypervisor yetkisi ayrıca snapshot'lara erişim sağlayabilir.

Bu nedenle backup ve virtualization yönetimi farklı güvenlik katmanlarında tutulmalıdır.

### Snapshot Deletion Neden Yaygındır?

Snapshot hızlı restore için çok değerlidir.

Ancak saldırgan storage veya hypervisor administrator yetkisi elde ederse snapshot'ları silebilir.

Bu nedenle ransomware saldırılarında sık karşılaşılan hedeflerden biri:

**restore noktalarını ortadan kaldırmaktır.**

Snapshot hızlı kurtarma sağlar ancak tek başına ransomware dayanıklılığı sağlamaz.

### \10. Shadow Copy Silme

Windows sistemlerde Volume Shadow Copy Service üzerinden oluşturulan shadow copy'ler hızlı restore için kullanılabilir.

Ancak saldırganlar bunları silebilir.

Amaç kullanıcının veya yöneticinin sistem üzerindeki geçmiş kopyalardan hızlı geri dönmesini engellemektir.

Bu nedenle yalnızca local shadow copy'lere güvenmek doğru değildir.

### \11. Backup Job'ların Durdurulması

Saldırgan şifreleme öncesinde backup job'ları durdurabilir.

Örneğin;

backup service durdurulur,

scheduler kapatılır,

job disabled yapılır.

Bu işlem saldırıdan önce günlerce fark edilmeyebilir.

Bu nedenle backup job başarısızlıkları SIEM veya monitoring sistemi tarafından izlenmelidir.

### Backup Job Failure Neden Güvenlik Olayı Olabilir?

Backup job failure her zaman saldırı değildir.

Disk dolabilir.

Network kesilebilir.

Credential expire olabilir.

Ancak kritik backup job'ın beklenmedik şekilde durması güvenlik açısından da değerlendirilmelidir.

Özellikle aynı anda;

administrator login,

retention değişikliği,

backup service stop

gibi olaylar varsa alarm üretilmelidir.

### \12. Retention Politikalarının Değiştirilmesi

Saldırgan backup silmek yerine retention süresini değiştirebilir.

Örneğin:

30 gün → 1 gün

gibi bir değişiklik yapılabilir.

Backup sistemi eski restore point'leri otomatik olarak silebilir.

Bu nedenle retention değişikliği kritik bir güvenlik olayıdır.

### Retention Değişikliği Alarm Üretmeli mi?

Evet.

Kritik backup ortamında:

retention azaltılması,

immutable süresinin değiştirilmesi,

repository silinmesi,

backup job silinmesi

gibi değişiklikler anında alarm üretmelidir.

### \13. Backup Repository Silme

Backup repository saldırgan açısından en değerli hedeflerden biridir.

Eğer repository sıradan bir SMB share veya network storage olarak açıksa ransomware doğrudan backup dosyalarını şifreleyebilir.

Bu nedenle repository;

normal kullanıcı network'ünden erişilebilir olmamalıdır.

### SMB Backup Repository Neden Risklidir?

Backup repository:

\backup\repository

şeklinde herkesin erişebildiği network share ise saldırgan lateral movement sonrası bu alana ulaşabilir.

Bu nedenle;

minimum erişim,

firewall segmentasyonu,

ayrı credential,

hardened repository

kullanılması önemlidir.

### \14. Backup Dosyalarının Şifrelenmesi

Saldırgan backup dosyalarını doğrudan şifreleyebilir.

Örneğin backup repository Windows server üzerinde bulunuyor ve ransomware bu sunucuda çalıştırılabiliyorsa backup dosyaları da şifrelenebilir.

Bu nedenle backup dosyalarının production ortamıyla aynı trust zone içerisinde bulunmaması önemlidir.

### \15. Backup Kataloglarının Silinmesi

Backup sistemlerinde yalnızca backup dosyaları değil metadata ve katalog bilgileri de önemlidir.

Backup catalog hangi restore point'in nerede olduğunu gösterir.

Saldırgan catalog database'i silerse backup dosyaları fiziksel olarak duruyor olsa bile restore süreci ciddi şekilde zorlaşabilir.

Bu nedenle backup config ve catalog backup'ları da ayrıca korunmalıdır.

### \16. Encryption Key Hedefleme

Backup dosyaları şifreliyse encryption key'ler kritik öneme sahiptir.

Saldırgan key'leri ele geçirirse backup içerisindeki veriyi okuyabilir.

Key'leri silerse kurum kendi backup'ını restore edemeyebilir.

Bu nedenle encryption key management ayrı güvenlik katmanı olarak tasarlanmalıdır.

### \17. Cloud Backup Hesaplarının Ele Geçirilmesi

Bulut backup kullanılması saldırgan riskini otomatik olarak ortadan kaldırmaz.

Eğer saldırgan;

cloud administrator,

access key,

API token,

service principal

ele geçirirse backup object'lerine erişebilir.

Özellikle production ve backup aynı cloud account içerisinde bulunuyorsa risk artabilir.

### Cloud Backup'ta En Kritik Hata Nedir?

En kritik hatalardan biri production ve backup ortamlarının aynı IAM yetkileriyle yönetilmesidir.

Örneğin tek bir Global Administrator hem production workload hem backup storage üzerinde tam yetkiliyse saldırganın işi kolaylaşır.

Ayrı:

account,

subscription,

credential,

MFA

kullanılması blast radius'u azaltabilir.

### \18. Object Storage Silme

Cloud backup object storage üzerinde tutuluyorsa saldırgan object'leri silebilir.

Bu riske karşı;

Object Lock,

WORM,

retention lock,

immutable storage

kullanılabilir.

Bu nedenle cloud backup tasarımında yalnızca storage kullanmak yeterli değildir.

### \19. DR Ortamının Hedeflenmesi

Disaster Recovery ortamları da ransomware saldırılarında hedef olabilir.

Özellikle production ile sürekli replike edilen DR ortamında şifrelenmiş veri de replike olabilir.

Bu nedenle DR tek başına backup değildir.

### DR Replikasyonu Neden Ransomware'e Karşı Yeterli Değildir?

Production sisteminde dosya şifrelenirse replication bunu DR sistemine de taşıyabilir.

Bu durumda iki ortam da aynı anda etkilenebilir.

Bu nedenle ransomware dayanıklılığı için:

**Point-in-Time Backup + Immutable Copy + Air-Gap**

gibi ek katmanlara ihtiyaç vardır.

### \20. Logların Silinmesi

Saldırgan yalnızca backup sistemini değil logları da silmeye çalışabilir.

Amaç incident response ekibinin ne olduğunu anlamasını zorlaştırmaktır.

Backup administrator login logları,

repository erişimleri,

policy değişiklikleri

merkezi SIEM sistemine gönderilmelidir.

### Backup Logları Neden Merkezi Sistemde Tutulmalı?

Eğer loglar yalnızca backup server üzerinde tutuluyorsa saldırgan server'ı ele geçirdiğinde logları silebilir.

SIEM'e gönderilen merkezi loglar ayrı bir güvenlik katmanı oluşturur.

### Ransomware Öncesi Backup Ortamında Görülebilecek IOC'ler

Saldırı başlamadan önce bazı davranışlar erken uyarı olabilir.

Örneğin:

- beklenmeyen backup admin login,
- gece saatlerinde yönetim erişimi,
- yeni administrator oluşturulması,
- repository silme denemeleri,
- backup service stop,
- retention policy değişikliği,
- immutable ayar değişikliği,
- MFA kapatma,
- çok sayıda failed login,
- yeni API key oluşturulması,
- snapshot silme,
- backup job disable.

Bu davranışlar güvenlik ekipleri tarafından izlenmelidir.

### Backup Sistemlerinde SIEM Use Case Oluşturulmalı mı?

Evet.

Backup sistemleri SIEM için özel use case'lere sahip olmalıdır.

Örneğin:

#### Use Case 1: Backup Administrator Login Outside Business Hours

Normal çalışma saatleri dışında backup yönetim login'i alarm üretebilir.

#### Use Case 2: Backup Retention Reduced

Retention süresi düşürülürse alarm oluşturulur.

#### Use Case 3: Multiple Restore Points Deleted

Kısa sürede çok sayıda restore point silinirse kritik alarm oluşturulur.

#### Use Case 4: Backup Service Stopped

Backup servisi beklenmedik şekilde durursa alarm üretilir.

### EDR Backup Sunucularında Ne İzlemeli?

EDR/XDR çözümü backup server üzerinde;

PowerShell,

credential dumping,

suspicious process,

remote execution,

lateral movement,

malware execution,

ransomware behavior

gibi davranışları izleyebilir.

Ancak performans ve ürün uyumluluğu dikkate alınmalıdır.

### Ransomware Encryption'dan Önce Neden Sessiz Kalır?

Saldırgan ne kadar uzun süre gizli kalırsa o kadar fazla sistemi keşfedebilir.

Bu dönemde;

backup sistemini,

DR ortamını,

administrator hesaplarını,

kritik verileri

tespit eder.

Encryption genellikle saldırının en görünür aşamasıdır.

Ancak olay çok daha önce başlamıştır.

### Dwell Time Nedir?

Dwell Time, saldırganın sistem içerisinde fark edilmeden bulunduğu süreyi ifade eder.

Bu süre ransomware recovery açısından çok önemlidir.

Çünkü saldırgan haftalarca sistemde kaldıysa en yeni backup'ların tamamı compromised olabilir.

Bu nedenle temiz restore point belirlemek için saldırganın ilk erişim tarihi önemlidir.

### En Yeni Backup Her Zaman En İyi Backup Değildir

Örneğin saldırgan:

1 Haziran'da sisteme girdi.

15 Haziran'da persistence oluşturdu.

25 Haziran'da ransomware çalıştırdı.

24 Haziran backup'ı teknik olarak sağlam olabilir.

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

Bu nedenle restore noktası incident timeline'a göre seçilmelidir.

### Ransomware Sonrası İlk Yapılmaması Gereken Şey: Acele Restore

Saldırı sonrası sistemleri hızlıca ayağa kaldırmak isteği doğaldır.

Ancak compromised ortama doğrudan restore yapmak tekrar enfeksiyona neden olabilir.

Önce saldırının kök nedeni anlaşılmalıdır.

### Ransomware Sonrası Recovery Süreci

Güvenli bir recovery süreci genel olarak şu aşamaları içerebilir:

#### \1. İzolasyon

Compromised sistemler network'ten ayrılır.

#### \2. Incident Investigation

İlk erişim ve saldırı timeline'ı belirlenir.

#### \3. Credential Reset

Kritik hesaplar değiştirilir.

#### \4. Clean Restore Point Seçimi

Saldırıdan önceki güvenilir backup belirlenir.

#### \5. Clean Room Recovery

Sistem izole ortamda restore edilir.

#### \6. Malware ve IOC Kontrolü

Backup taranır.

#### \7. Production'a Geçiş

Kontrollü şekilde sistem tekrar devreye alınır.

### Active Directory Önce mi Restore Edilmeli?

Birçok ortamda Active Directory en kritik recovery bileşenlerinden biridir.

Çünkü diğer sistemler;

authentication,

DNS,

service account,

Group Policy

için AD'ye bağımlı olabilir.

Bu nedenle AD forest recovery planı önceden hazırlanmalıdır.

### Ransomware Sonrası Tüm Parolalar Değiştirilmeli mi?

Olayın kapsamına göre kritik credential'ların reset edilmesi gerekebilir.

Özellikle;

Domain Admin,

backup admin,

cloud admin,

service account,

VPN account,

API key,

secret

gibi kimlik bilgileri değerlendirilmelidir.

Çünkü backup temiz olsa bile saldırgan credential'lara sahip olabilir.

### Backup Administrator Credential'ları İlk Değiştirilecek Hesaplardan Olmalı mı?

Çoğu senaryoda evet.

Backup ortamına erişimin güvenli hale getirilmesi recovery'nin temel aşamalarından biridir.

Aksi halde saldırgan restore süreci sırasında backup ortamına tekrar erişebilir.

### Clean Room Network'ü Nasıl Olmalı?

Clean Room mümkün olduğunca production ortamından izole olmalıdır.

Örneğin:

ayrı VLAN,

ayrı firewall zone,

ayrı DNS,

ayrı admin account

kullanılabilir.

Restore edilen sistemlerin internete erişimi ilk aşamada sınırlandırılabilir.

### Backup Önce Malware Taramasından Geçmeli mi?

Evet, özellikle ransomware olaylarında faydalıdır.

Backup dosyaları;

EDR,

antivirus,

YARA,

IOC scan

gibi yöntemlerle analiz edilebilir.

Amaç compromised dosyaların tekrar production'a taşınmasını önlemektir.

### Backup İçerisindeki Persistence Nasıl Tespit Edilir?

Restore edilen sistem üzerinde;

scheduled task,

service,

registry startup,

user account,

web shell,

remote management tool

gibi persistence mekanizmaları kontrol edilmelidir.

Bu işlem incident response ekibiyle birlikte yürütülebilir.

### Ransomware Recovery'de RPO Nasıl Değişir?

Normal operasyon sırasında RPO 15 dakika olabilir.

Ancak saldırı 10 gündür sistemdeyse en son temiz backup 11 gün önce olabilir.

Bu durumda teorik RPO ile gerçek cyber recovery RPO farklılaşır.

Bu önemli bir farktır.

### Cyber Recovery RPO Nedir?

Cyber Recovery RPO, siber saldırı sonrası geri dönülebilecek temiz ve güvenilir veri noktasını ifade eder.

Klasik RPO yalnızca backup sıklığını dikkate alırken cyber recovery:

**temizlik ve güvenilirlik**

faktörünü de dikkate alır.

### Ransomware Recovery'de RTO Neden Uzayabilir?

Normal bir server arızasında restore birkaç saat sürebilir.

Ancak ransomware olayında önce;

forensic analiz,

credential reset,

network cleanup,

clean room,

malware taraması

yapılması gerekebilir.

Bu nedenle cyber incident RTO normal DR RTO'dan daha uzun olabilir.

### Backup Restore Testine Ransomware Senaryosu Dahil Edilmeli mi?

Kesinlikle.

Sadece:

“Server silindi, backup'tan geri yükledik.”

testi yeterli değildir.

Ayrıca şu senaryo test edilmelidir:

**“Domain Admin saldırganda, production tamamen compromised ve backup sistemine saldırı girişimi var.”**

Bu daha gerçekçi bir cyber recovery tatbikatıdır.

### Tabletop Exercise Nedir?

Tabletop Exercise, ekiplerin gerçek sistemleri kapatmadan masa başında kriz senaryosunu çalışmasıdır.

Örneğin:

Saat 09:00 ransomware tespit edildi.

Backup sistemi erişilemiyor.

Domain Admin hesabı ele geçirilmiş.

CEO müşteri açıklaması istiyor.

Bu durumda hangi ekip ne yapacak?

Bu tür tatbikatlar Business Continuity ve Incident Response olgunluğunu artırır.

### Teknik Tatbikat da Yapılmalı mı?

Evet.

Tabletop tek başına yeterli değildir.

Gerçek teknik recovery tatbikatında;

backup bulunur,

restore edilir,

DNS çalıştırılır,

database açılır,

uygulama test edilir,

RTO ölçülür.

Bu sayede planın gerçekten çalışıp çalışmadığı görülür.

### Ransomware'e Karşı Backup Güvenlik Kontrol Listesi

Kritik backup ortamında şu kontroller değerlendirilmelidir:

- immutable backup,
- air-gap,
- offsite backup,
- MFA,
- ayrı backup administrator hesapları,
- production domain'den izolasyon,
- network segmentation,
- hardened repository,
- encryption,
- SIEM monitoring,
- EDR/XDR,
- retention lock,
- Object Lock,
- secure credential management,
- düzenli restore testleri,
- clean room recovery,
- cyber recovery tatbikatları.

### Backup'ın Kendisi Kritik Varlık Olarak Sınıflandırılmalı

Birçok kurum CMDB veya asset inventory içerisinde backup sistemlerini sıradan infrastructure olarak değerlendirir.

Oysa backup sistemi kurumun en kritik varlıklarından biridir.

Çünkü saldırı sonrası tüm kurumun geri dönüş kapasitesi bu sisteme bağlı olabilir.

Bu nedenle backup sunucuları;

Critical Asset

olarak sınıflandırılmalıdır.

### Backup Sistemlerine Vulnerability Management Uygulanmalı mı?

Evet.

Backup sunucuları da düzenli olarak;

zafiyet taraması,

patch management,

hardening,

configuration review

süreçlerine dahil edilmelidir.

“Backup sistemi olduğu için dokunmayalım” yaklaşımı güvenlik açığı oluşturabilir.

### Patch Management Neden Hassastır?

Backup sistemi kritik olduğu için patch işlemleri dikkatli yapılmalıdır.

Ancak güncellenmemiş backup yazılımı da saldırgan için hedef olabilir.

Bu nedenle;

test,

change management,

backup config backup,

rollback plan

ile kontrollü patch yapılmalıdır.

### Default Credential'lar Kontrol Edilmeli mi?

Kesinlikle.

Backup appliance veya storage cihazlarında default account'lar kapatılmalı veya güvenli hale getirilmelidir.

Default credential saldırgan için kolay giriş noktası olabilir.

### Backup API Güvenliği

Modern backup ürünlerinde REST API kullanılabilir.

Bu API'ler otomasyon için değerlidir.

Ancak API token ele geçirilirse saldırgan kritik işlemler yapabilir.

Bu nedenle;

API authentication,

token expiration,

IP restriction,

least privilege,

audit logging

uygulanmalıdır.

### Backup Sisteminde Break Glass Account Nedir?

Break Glass Account, normal kimlik altyapısı kullanılamadığında acil erişim için kullanılan özel hesaptır.

Örneğin production AD tamamen kaybedildiğinde backup sistemine erişebilmek için bağımsız acil durum hesabı gerekebilir.

Bu hesap;

offline korunmalı,

çok sınırlı kullanılmalı,

güçlü authentication ile korunmalı

ve düzenli test edilmelidir.

### En Kritik Senaryo: Domain Tamamen Ele Geçirildi

Kurum backup güvenliğini şu varsayımla test etmelidir:

**“Saldırgan Domain Admin.”**

Bu durumda;

backup silinebilir mi?

repository erişilebilir mi?

cloud backup silinebilir mi?

Object Lock kaldırılabilir mi?

vault'a erişilebilir mi?

Eğer cevap evetse mimari yeterince izole değildir.

### İkinci Kritik Senaryo: Backup Admin Ele Geçirildi

Daha ileri senaryo:

**“Saldırgan backup administrator hesabına da sahip.”**

Bu durumda immutable backup'ın önemi ortaya çıkar.

Backup admin hesabı olsa bile tüm restore point'lerin silinememesi gerekir.

### Üçüncü Kritik Senaryo: Production Tamamen Yok

En uç test:

**Production DC tamamen kullanılamıyor.**

Bu durumda kurum;

offline backup,

recovery key,

network config,

AD backup,

uygulama kurulum dosyaları

ile sistemi yeniden kurabiliyor mu?

Gerçek cyber resilience bu seviyede ölçülür.

### Sonuç: Ransomware'in Hedefi Veriden Önce Kurtarma Yeteneğinizdir

Modern ransomware saldırılarında backup artık saldırıdan sonra kullanılacak pasif bir araç değildir.

Doğrudan saldırı zincirinin hedefidir.

Saldırganın amacı yalnızca:

**“Veriyi şifrelemek”**

değildir.

Asıl amaç:

**“Kurumun kendi verisine geri dönmesini engellemektir.”**

Bu nedenle saldırganlar;

Active Directory,

Domain Admin,

backup administrator,

repository,

snapshot,

DR,

cloud backup,

encryption key

gibi katmanları hedefleyebilir.

Modern backup stratejisinde temel varsayım şu olmalıdır:

**Saldırgan production ortamına girebilir.**

Daha güçlü varsayım:

**Saldırgan Domain Admin olabilir.**

En güçlü varsayım ise:

**Saldırgan backup sistemini de hedefleyecektir.**

İşte bu nedenle ransomware dayanıklı bir backup mimarisinde;

**Immutable Backup,**

**Air-Gap,**

**Hardened Repository,**

**Identity Separation,**

**MFA,**

**Network Segmentation,**

**SIEM Monitoring,**

#### Clean Room Recovery

ve **Restore Testing**

birlikte ele alınmalıdır.

Çünkü saldırı günü önemli olan kaç backup aldığınız değildir.

Önemli olan:

**Saldırganın ulaşamadığı kaç temiz backup'ınız kaldığıdır.**