# Backup ve Disaster Recovery Güvenliği Nedir? Ransomware’e Karşı Yedekleme Stratejisi Nasıl Olmalıdır?

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/sistem-ve-bulut-guvenligi/backup-disaster-recovery-guvenligi-ransomware

![Backup ve Disaster Recovery Güvenliği Nedir? Ransomware’e Karşı Yedekleme Stratejisi Nasıl Olmalıdır?](/images/bilgi-merkezi/covers/cover-sistembulut-10.webp)

Bir kurumun yedeğinin olması, verisini geri getirebileceği anlamına gelmez.

Bu ayrım özellikle ransomware saldırılarından sonra çok daha önemli hale geldi.

Çünkü modern saldırganlar yalnızca production sunucularını şifrelemeye çalışmıyor.

Aynı zamanda;

backup sunucularını,

snapshot'ları,

yedekleme repository'lerini,

backup administrator hesaplarını,

hypervisor yönetim sistemlerini,

cloud backup servislerini

de hedefleyebiliyor.

Saldırgan açısından mantık basittir:

**Kurumun geri dönüş imkanını ortadan kaldırabilirsem fidye baskısını artırabilirim.**

Bu nedenle backup güvenliği artık sadece IT operasyon konusu değildir.

**Backup Security, Disaster Recovery, Ransomware Recovery ve Cyber Resilience** doğrudan siber güvenlik programının parçasıdır.

Modern bir kurum için asıl soru:

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

değildir.

Daha doğru sorular şunlardır:

#### Backup üretim ortamından gerçekten izole mi?

#### Saldırgan Domain Admin olduğunda backup'ları silebilir mi?

#### Immutable kopyamız var mı?

#### Offline veya ayrı güvenlik alanında yedeğimiz bulunuyor mu?

#### Backup restore edildiğinde gerçekten çalışıyor mu?

#### RTO ve RPO hedeflerimizi karşılayabiliyor muyuz?

Çünkü ransomware sonrası gerçek güvenlik seviyesi çoğu zaman saldırıyı tamamen önleyip önleyemediğinizden değil, **ne kadar hızlı ve güvenilir şekilde toparlanabildiğinizden** anlaşılır.

#### Backup Security Nedir?

**Backup Security – Yedekleme Güvenliği**, yedeklenen verilerin yetkisiz erişim, silme, değiştirme, şifreleme ve veri sızıntısı risklerine karşı korunmasıdır.

Bu kapsamda;

- backup repository güvenliği,
- privileged backup account yönetimi,
- immutable backup,
- offline backup,
- encryption,
- network segmentation,
- backup monitoring,
- restore testleri,
- ransomware recovery

gibi alanlar değerlendirilir.

Backup güvenliğinin amacı yalnızca verinin bir kopyasını oluşturmak değildir.

Asıl hedef:

**Production sistem tamamen kaybedilse bile kurumun güvenilir bir noktadan geri dönebilmesini sağlamaktır.**

### Disaster Recovery Nedir?

**Disaster Recovery – DR**, kritik sistem ve verilerin büyük bir kesinti, siber saldırı veya altyapı problemi sonrasında belirlenen süre içerisinde yeniden çalışır hale getirilmesi sürecidir.

Disaster Recovery;

backup,

replication,

secondary site,

cloud recovery,

network,

DNS,

identity,

application

gibi birçok bileşeni içerebilir.

Bu nedenle DR yalnızca “yedekten geri dönmek” değildir.

Uçtan uca iş hizmetinin yeniden ayağa kaldırılmasıdır.

### Backup ile Disaster Recovery Aynı Şey midir?

Hayır.

#### Backup

Verinin bir veya daha fazla kopyasının saklanmasını sağlar.

#### Disaster Recovery

Sistemin tamamının yeniden çalışır hale getirilmesini planlar.

Örneğin database backup'ınız olabilir.

Ama;

uygulama sunucusu,

DNS,

certificate,

IAM,

network,

configuration

geri yüklenemiyorsa hizmet yine çalışmayabilir.

Bu nedenle backup, Disaster Recovery'nin önemli bir bileşenidir ama tamamı değildir.

### Business Continuity ile Disaster Recovery Arasındaki Fark

**Business Continuity – İş Sürekliliği**, kritik iş süreçlerinin kesinti sırasında nasıl devam edeceğini ele alır.

**Disaster Recovery** ise ağırlıklı olarak IT sistemlerinin teknik geri dönüşüne odaklanır.

Örneğin:

Ödeme sistemi kapalı.

DR ekibi sistemi restore eder.

Bu sırada müşteri işlemlerinin alternatif kanaldan yürütülmesi ise Business Continuity kapsamına girebilir.

İki süreç birlikte çalışmalıdır.

### Ransomware Neden Backup Sistemlerini Hedefler?

Çünkü iyi bir backup saldırganın fidye gücünü azaltır.

Eğer kurum verisini güvenli şekilde geri yükleyebiliyorsa saldırganın:

**“Verilerinizi şifreledik, ödeme yapmazsanız açamayacaksınız.”**

baskısı zayıflar.

Bu nedenle gelişmiş ransomware operasyonlarında saldırganlar saldırının erken aşamalarında backup ortamını keşfetmeye çalışabilir.

Örneğin;

backup server,

hypervisor,

storage,

snapshot,

backup console

hedeflenebilir.

### Ransomware Saldırganı Backup'ı Nasıl Bulabilir?

Kurumsal network içerisinde backup altyapısı tamamen görünmez değildir.

Backup agent'ları.

Network bağlantıları.

Service account'lar.

DNS kayıtları.

Management console.

Installed software.

Bunların tamamı backup teknolojisi hakkında ipucu verebilir.

Bu nedenle backup sisteminin yalnızca “gizli” olması bir güvenlik kontrolü değildir.

Gerçek izolasyon gerekir.

### Backup Admin Hesabı Neden Kritik?

Backup administrator çoğu zaman;

backup oluşturabilir,

silme yapabilir,

retention değiştirebilir,

restore başlatabilir.

Bu nedenle yüksek yetkili hesaptır.

Backup admin credential'ı saldırganın eline geçerse production veriyi ele geçirmeden bile recovery kapasitesini yok etmeye çalışabilir.

Bu nedenle backup admin erişimi PAM ve MFA ile korunmalıdır.

### Backup Admin ile Domain Admin Aynı Kişi Olmalı mı?

Teknik personel aynı kişi olabilir.

Ancak aynı hesap ve aynı credential'ın iki ortamda da yüksek yetkili olması yüksek risk oluşturur.

Örneğin saldırgan Domain Admin elde ettiğinde otomatik olarak backup sistemini de yönetebiliyorsa recovery bağımsızlığı zayıftır.

Bu nedenle:

#### Identity Separation

önemlidir.

Backup güvenlik alanı mümkün olduğunca production identity plane'den ayrıştırılmalıdır.

### Backup Sisteminin Active Directory'ye Bağlı Olması Riskli mi?

İşletim açısından kolay olabilir.

Ancak ciddi bir domain compromise durumunda backup yönetimi de etkilenebilir.

Bu nedenle kritik yapılarda backup için;

ayrı authentication,

ayrı privileged account,

yerel emergency account,

MFA

gibi ek kontroller değerlendirilebilir.

Amaç AD tamamen ele geçirildiğinde bile backup'a güvenli erişim sağlayabilmektir.

### Immutable Backup Nedir?

**Immutable Backup**, belirlenen retention süresi boyunca backup verisinin değiştirilememesi veya silinememesini amaçlayan yedekleme modelidir.

Örneğin yedek:

30 gün immutable

olarak tutulabilir.

Bu süre boyunca administrator hesabı ele geçirilse bile belirli koruma mekanizmaları backup'ın silinmesini zorlaştırabilir.

Ransomware dayanıklılığı açısından en önemli modern backup kontrollerinden biridir.

### Immutable ile Read-Only Aynı Şey midir?

Tam olarak değil.

Read-only access policy administrator tarafından değiştirilebilir olabilir.

Gerçek immutability daha güçlü mekanizmalarla uygulanır.

Örneğin;

object lock,

WORM,

retention lock

gibi teknolojiler kullanılabilir.

Ama uygulamanın nasıl çalıştığı ürün ve mimariye göre doğrulanmalıdır.

### WORM Nedir?

**Write Once Read Many – WORM**, verinin bir kere yazıldıktan sonra belirli süre değiştirilememesini amaçlayan depolama yaklaşımıdır.

Backup dünyasında ransomware'e karşı güçlü koruma katmanı olarak kullanılabilir.

Ancak retention ayarları dikkatli yapılmalıdır.

Çünkü yanlış konfigürasyon depolama yönetimini zorlaştırabilir.

### Object Lock Nedir?

Object storage sistemlerinde nesnelerin belirli süre silinmesini veya değiştirilmesini engelleyen mekanizmalardan biridir.

Cloud backup stratejisinde kullanılabilir.

Özellikle backup bucket'ın compromise edilmesi durumunda ek koruma sağlayabilir.

### Compliance Mode ile Governance Mode Arasındaki Fark

Bazı object lock sistemlerinde farklı immutability seviyeleri bulunabilir.

Genel olarak;

#### Governance Mode

yetkili kullanıcıların belirli koşullarda retention'ı değiştirebilmesine izin verebilir.

#### Compliance Mode

daha katı olabilir ve retention süresi tamamlanmadan silmeyi çok daha fazla sınırlandırabilir.

Hangi modelin kullanılacağı iş ve regülasyon gereksinimlerine göre belirlenmelidir.

### Offline Backup Nedir?

**Offline Backup**, normal production network'üne sürekli bağlı olmayan yedek kopyasıdır.

Bu fiziksel medya veya bağlantısı kontrollü sistem olabilir.

Amaç saldırgan production network üzerinde yönetici yetkisi elde ettiğinde backup'a doğrudan ulaşamamasıdır.

### Air-Gapped Backup Nedir?

**Air Gap**, backup ile production ortamı arasında sürekli doğrudan bağlantı bulunmamasını ifade eder.

Fiziksel veya mantıksal air gap olabilir.

Bu yaklaşım ransomware karşısında güçlü bir izolasyon sağlar.

Ancak operasyonel yönetimi doğru yapılmalıdır.

### Logical Air Gap Nedir?

Backup ortamı fiziksel olarak aynı data center veya cloud içerisinde bulunabilir.

Ancak;

ayrı credential,

network isolation,

immutable storage,

restricted management

sayesinde production'dan ayrıştırılır.

Bu **Logical Air Gap** olarak düşünülebilir.

Fiziksel tape kadar ayrık olmayabilir ama doğru tasarlanırsa güçlü koruma sağlayabilir.

### 3-2-1 Backup Kuralı Nedir?

Yaygın kullanılan klasik backup yaklaşımıdır.

**3**

Verinin en az üç kopyası.

**2**

En az iki farklı medya veya depolama türü.

**1**

Kopyalardan en az biri farklı lokasyonda.

Ama modern ransomware riskleri nedeniyle daha gelişmiş modeller de kullanılır.

### 3-2-1-1-0 Backup Stratejisi Nedir?

Modern backup güvenliği için yaygın kullanılan geliştirilmiş modeldir.

**3** → En az üç veri kopyası.

**2** → İki farklı depolama türü.

**1** → Bir kopya off-site.

**1** → Bir kopya offline veya immutable.

**0** → Restore doğrulamasında sıfır hata hedefi.

Buradaki en önemli eklemeler;

**immutability**

ve

**restore verification**

konularıdır.

**“0” Gerçekten Sıfır Hata mı Demektir?**

Genel yaklaşım backup'ın doğrulanmış ve hatasız olduğunu ifade eder.

Bu otomatik integrity check ve periyodik restore testiyle desteklenebilir.

Ama “backup job succeeded” mesajı restore garantisi değildir.

Gerçek sistem açılmalıdır.

### Backup Job Başarılıysa Neden Restore Çalışmayabilir?

Birçok neden olabilir.

Backup file bozuk olabilir.

Application-consistent snapshot alınmamış olabilir.

Encryption key eksik olabilir.

Credential bulunamayabilir.

Database recovery hatalı olabilir.

Boot configuration eksik olabilir.

Bu nedenle sadece backup job status takip etmek yetersizdir.

### Restore Test Nedir?

**Restore Test**, backup'tan sistem veya verinin kontrollü şekilde geri yüklenerek gerçekten kullanılabilir olduğunun doğrulanmasıdır.

Örneğin;

VM restore edilir,

işletim sistemi açılır,

application başlatılır,

database kontrol edilir,

sample transaction gerçekleştirilir.

Bu backup güvenliğinin en kritik doğrulama adımlarından biridir.

### Restore Test Ne Sıklıkla Yapılmalıdır?

Tek bir evrensel süre yoktur.

Kritik sistemlerde daha sık uygulanabilir.

Örneğin;

kritik uygulamalar aylık/çeyreklik,

daha düşük kritik sistemler daha seyrek

test edilebilir.

Önemli olan risk bazlı plan ve düzenli tekrar olmasıdır.

### Automated Restore Validation Nedir?

Backup platformu yedeği izole ortamda otomatik olarak restore edip;

VM boot,

service status,

malware scan,

application test

gerçekleştirebilir.

Bu yöntem çok sayıda backup'ın düzenli doğrulanmasını kolaylaştırır.

Ancak kritik uygulamalarda yine işlevsel test gerekebilir.

### SureBackup Benzeri Doğrulama Yaklaşımları Neden Değerlidir?

Farklı üreticiler farklı isimlerle izole restore doğrulama mekanizmaları sunabilir.

Temel fikir aynıdır:

**Backup dosyasının varlığını değil, çalışabilirliğini test etmek.**

Bu ransomware recovery açısından kritik farktır.

### RPO Nedir?

**Recovery Point Objective – RPO**, kabul edilebilir maksimum veri kaybı miktarını ifade eder.

Örneğin:

RPO = 15 dakika.

Bu, büyük olay durumunda en fazla yaklaşık 15 dakikalık veri kaybının kabul edilebilir olduğu anlamına gelebilir.

RPO iş birimleriyle birlikte belirlenmelidir.

### RTO Nedir?

**Recovery Time Objective – RTO**, sistemin kesinti sonrasında ne kadar sürede tekrar çalışır hale gelmesi gerektiğini ifade eder.

Örneğin:

RTO = 2 saat.

Bu durumda teknik DR mimarisi sistemin 2 saat içerisinde geri dönmesini hedeflemelidir.

### RTO ile RPO Arasındaki Fark

Basitçe:

**RPO = Ne kadar veri kaybedebiliriz?**

**RTO = Ne kadar süre kapalı kalabiliriz?**

Bu iki değer backup ve DR mimarisinin temel tasarım girdileridir.

### RTO ve RPO IT Ekibi Tarafından mı Belirlenmeli?

Tek başına hayır.

Bunlar iş riski kararlarıdır.

Örneğin IT:

“Bu sistemi 24 saatte restore edebiliriz.”

diyebilir.

Ama finans birimi:

“30 dakika bile kapalı kalamaz.”

diyorsa teknik mimari yetersizdir.

Bu nedenle Business Impact Analysis gerekir.

### Business Impact Analysis – BIA Nedir?

**BIA**, kritik iş süreçlerinin kesinti durumundaki etkisini analiz eder.

Örneğin;

ödeme sistemi,

ERP,

e-ticaret,

mail,

CRM

farklı önceliklere sahip olabilir.

BIA sonucunda RTO/RPO hedefleri daha gerçekçi belirlenebilir.

### Mission Critical Sistem Nedir?

Kesintisi kurumun;

gelirini,

müşteri hizmetini,

regülasyon yükümlülüklerini,

operasyonunu

ciddi etkileyen sistemlerdir.

Bu sistemler daha düşük RTO/RPO ve daha güçlü backup/DR mimarisi gerektirebilir.

### Backup Retention Nedir?

**Retention**, backup'ın ne kadar süre saklanacağını belirler.

Örneğin;

günlük 30 gün,

aylık 12 ay,

yıllık 7 yıl

gibi politikalar olabilir.

Retention sadece storage kapasitesine göre belirlenmemelidir.

İş, hukuk ve regülasyon gereksinimleri dikkate alınmalıdır.

### Uzun Retention Her Zaman Daha Güvenli midir?

Hayır.

Gereksiz yere uzun saklama;

maliyet,

kişisel veri,

compliance

risklerini artırabilir.

Ayrıca eski backup içerisinde yıllardır unutulmuş hassas veri bulunabilir.

Bu nedenle retention data lifecycle ile uyumlu olmalıdır.

### Backup Encryption Neden Önemlidir?

Backup production verisinin tam kopyasını içerebilir.

Bu nedenle backup storage çalınır veya yanlışlıkla public olursa büyük veri sızıntısı gerçekleşebilir.

Backup;

#### Encryption at Rest

ve

#### Encryption in Transit

ile korunmalıdır.

### Backup Encryption Key Güvenliği

Yedeğin encryption key'i aynı backup repository üzerinde tutuluyorsa saldırgan ikisini birlikte elde edebilir.

Bu nedenle key management ayrıştırılmalıdır.

KMS veya HSM gibi mekanizmalar değerlendirilebilir.

### Backup Key Kaybolursa Ne Olur?

Encrypted backup erişilemez hale gelebilir.

Bu nedenle encryption key de yüksek availability ve recovery planına sahip olmalıdır.

Security ile recoverability arasında denge gerekir.

### Backup Network Segmentation Nedir?

Backup sunucuları production network ile tamamen aynı segmentte bulunmamalıdır.

Örneğin ayrı;

Backup VLAN,

Management Network,

Firewall Zone

kullanılabilir.

Yalnızca gerekli port ve kaynakların erişmesine izin verilir.

Bu lateral movement riskini azaltır.

### Backup Server İnternete Çıkmalı mı?

Gereksiz sınırsız internet erişimi verilmemelidir.

Gerekli;

update,

cloud backup,

vendor service

erişimleri allowlist veya proxy üzerinden kontrol edilebilir.

Egress filtering saldırganın C2 bağlantısını da zorlaştırabilir.

### Backup Management Console İnternete Açılmalı mı?

Genellikle hayır.

Backup console yüksek yetkili yönetim yüzeyidir.

VPN, Bastion veya PAM üzerinden erişim tercih edilebilir.

Doğrudan public access ciddi saldırı yüzeyi oluşturur.

### MFA Backup Sisteminde Kullanılmalı mı?

Özellikle administrator erişimlerinde güçlü şekilde değerlendirilmelidir.

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

PAM,

network restriction,

JIT access,

session logging

ile birlikte kullanılabilir.

### PAM Backup Ortamında Ne İşe Yarar?

Backup admin credential'larını kasalayabilir.

Parola rotation sağlayabilir.

Admin'in credential'ı doğrudan görmesini engelleyebilir.

Session recording yapabilir.

Onaylı ve süreli erişim sağlayabilir.

Bu özellikle kritik backup yönetim sistemlerinde değerlidir.

### Just-in-Time Backup Admin Access Nedir?

Kullanıcı sürekli Backup Administrator olmak yerine ihtiyaç olduğunda kısa süreli yüksek yetki alır.

Örneğin;

restore işlemi için 1 saat.

Süre sonunda privileged role kaldırılır.

Bu standing privilege riskini azaltır.

### Backup Service Account Neden Kritik?

Backup yazılımı çok sayıda sunucuya erişebilir.

Bu nedenle service account yüksek yetkili olabilir.

Eğer bu hesap ele geçirilirse saldırgan;

server,

hypervisor,

backup repository

gibi farklı sistemlere hareket edebilir.

Bu hesaplar minimum yetki ile yapılandırılmalıdır.

### Backup Service Account Domain Admin Olmalı mı?

Genellikle gereksiz geniş yetkiden kaçınılmalıdır.

Backup yazılımının belirli sistemlere erişmesi gerekebilir ama doğrudan Domain Admin kullanımı riskli olabilir.

Üretici önerileri ve least privilege modeli esas alınmalıdır.

### Hypervisor Backup Güvenliği Neden Kritik?

VMware, Hyper-V veya cloud virtualization platformu üzerinde snapshot ve backup işlemleri yapılabilir.

Hypervisor yönetim hesabı ele geçirilirse çok sayıda VM aynı anda etkilenebilir.

Bu nedenle virtualization management de Tier 0/critical infrastructure olarak ele alınabilir.

### VMware/Hypervisor Ransomware Neden Tehlikeli?

Saldırgan hypervisor erişimi elde ettiğinde tek tek endpoint'leri şifrelemek zorunda kalmadan çok sayıda virtual machine'i etkileyebilir.

Bu nedenle;

vCenter,

ESXi management,

Hyper-V admin

gibi sistemler sıkı şekilde korunmalıdır.

### Snapshot Backup Sayılır mı?

Tek başına genellikle hayır.

Snapshot kısa dönem operasyon ve rollback için faydalıdır.

Ancak aynı storage'a bağlıysa storage kaybında snapshot da kaybedilebilir.

Ayrıca ransomware veya admin compromise ile silinebilir.

Bu nedenle snapshot gerçek backup stratejisinin tamamı değildir.

### Replication Backup Sayılır mı?

Hayır.

Replication availability sağlar.

Ancak kötü değişiklik de replicate edilebilir.

Örneğin ransomware dosyaları şifreledi.

Şifrelenmiş veri replica'ya da kopyalanabilir.

Bu nedenle replication ve backup birlikte kullanılmalıdır.

### High Availability ile Disaster Recovery Arasındaki Fark

#### High Availability – HA

Bileşen arızasında hizmeti kesintisiz veya kısa kesintiyle sürdürmeye odaklanır.

#### Disaster Recovery

Büyük kayıp veya kompromizasyon sonrasında sistemi geri getirmeye odaklanır.

HA, backup'ın alternatifi değildir.

### Active-Active DR Nedir?

İki veya daha fazla site/region aynı anda aktif olabilir.

Trafik dağıtılır.

Bir ortam kaybolduğunda diğer ortam hizmet vermeye devam eder.

Bu düşük RTO sağlayabilir.

Ancak maliyet ve mimari karmaşıklığı yüksektir.

### Active-Passive DR Nedir?

Primary ortam aktif çalışır.

Secondary ortam standby olabilir.

Kriz durumunda failover yapılır.

Bu model daha ekonomik olabilir ancak RTO daha uzun olabilir.

### Hot Site, Warm Site ve Cold Site Nedir?

#### Hot Site

Sistemler hazır ve büyük ölçüde senkron çalışır.

Hızlı recovery sağlar.

#### Warm Site

Bazı altyapılar hazırdır ancak aktivasyon gerekir.

#### Cold Site

Temel fiziksel veya altyapısal hazırlık bulunur, sistemlerin kurulması gerekir.

Seçim RTO ve maliyet hedeflerine göre yapılır.

### Cloud Disaster Recovery Nedir?

DR ortamının cloud üzerinde tutulmasıdır.

Örneğin on-premise workload cloud'a replicate edilebilir.

Kriz anında cloud'da çalıştırılabilir.

Bu model fiziksel ikinci data center maliyetini azaltabilir.

Ancak network, identity ve cloud cost dikkate alınmalıdır.

### Cross-Region Backup Nedir?

Backup'ın farklı cloud region'da saklanmasıdır.

Tek region outage riskini azaltabilir.

Ancak aynı cloud account'ta bulunuyorsa account compromise hâlâ risk oluşturabilir.

Bu nedenle region ayrımı ile identity/account ayrımı birlikte düşünülmelidir.

### Cross-Account Backup Nedir?

Backup'ın production'dan farklı cloud account veya subscription'da tutulmasıdır.

Bu blast radius'u azaltabilir.

Production admin hesabı ele geçirilse bile backup account'a erişim sınırlı olabilir.

Cloud ransomware dayanıklılığında güçlü bir modeldir.

### Cross-Cloud Backup Gerekli mi?

Her kurum için değil.

Multi-cloud backup vendor/region bağımlılığını azaltabilir.

Ancak;

maliyet,

operasyon,

network transfer,

recovery karmaşıklığı

artabilir.

Risk bazlı değerlendirilmelidir.

### Backup Immutability Cloud'da Nasıl Sağlanır?

Cloud object storage;

retention lock,

object lock,

WORM

gibi mekanizmalar sağlayabilir.

Ancak en önemli konu bu özelliğin gerçekten saldırgan administrator tarafından kolayca devre dışı bırakılamamasıdır.

Architecture test edilmelidir.

### Ransomware Recovery Vault Nedir?

Bazı mimarilerde ransomware sonrası recovery için özel ve yüksek güvenlikli backup alanı oluşturulur.

Bu ortam;

ayrı credential,

immutable backup,

minimum network connectivity,

clean-room recovery

gibi özelliklere sahip olabilir.

Amaç son güvenilir geri dönüş noktası sağlamaktır.

### Cyber Recovery Nedir?

**Cyber Recovery**, klasik Disaster Recovery'den farklı olarak sistemin bir siber saldırı sonrası güvenli ve temiz şekilde geri döndürülmesine odaklanır.

Örneğin ransomware sonrası sadece sistemi çalıştırmak yetmez.

Şu soru da önemlidir:

#### Restore ettiğimiz backup zaten kompromize edilmiş miydi?

Bu nedenle clean recovery yaklaşımı gerekir.

### Clean Room Recovery Nedir?

**Clean Room / Clean Recovery Environment**, kompromize production ortamından izole yeni bir alanda sistemlerin doğrulanarak geri yüklenmesidir.

Bu alanda;

backup malware scan,

credential reset,

forensic validation,

application test

yapılabilir.

Amaç saldırgan persistence'ını tekrar production'a taşımamaktır.

### Restore Point Nasıl Seçilir?

En son backup her zaman güvenli olmayabilir.

Saldırgan ransomware çalıştırmadan günler önce sisteme girmiş olabilir.

Bu nedenle:

#### Last Known Good Backup

belirlenmelidir.

Threat Hunting ve Incident Timeline burada önemlidir.

### Last Known Good Nedir?

Kompromizasyon olmadığına dair makul güven bulunan en son veri veya sistem durumudur.

Örneğin saldırganın 10 Haziran'da sisteme girdiği belirlenirse 12 Haziran backup'ı teknik olarak çalışır olsa bile güvenilir olmayabilir.

9 Haziran veya öncesi değerlendirilebilir.

### Ransomware Dwell Time Neden Recovery'yi Etkiler?

Saldırgan sisteme girdikten sonra şifreleme yapmadan günler veya haftalar içeride kalabilir.

Bu sürede;

persistence,

backdoor,

new accounts

oluşturabilir.

Dolayısıyla en son backup içinde saldırganın değişiklikleri de bulunabilir.

Bu nedenle recovery ile DFIR birlikte yürütülmelidir.

### Backup Malware Scan Nedir?

Restore edilmeden önce backup içeriğinin malware veya IOC açısından kontrol edilmesidir.

Özellikle executable, script ve system backup'larda değerlidir.

Ancak malware scan temiz sonucu, sistemin kesin olarak compromise olmadığı anlamına gelmez.

Davranışsal ve forensic analiz de gerekebilir.

### DR Test Nedir?

**Disaster Recovery Test**, belirlenen kriz senaryosunda sistemlerin alternatif ortamdan veya backup'tan geri döndürülmesini doğrular.

Örneğin;

primary data center unavailable,

cloud region failure,

ransomware

senaryoları test edilebilir.

Amaç dokümanın teoride değil pratikte çalıştığını görmektir.

### DR Testi ile Restore Test Aynı Şey mi?

Hayır.

Restore Test:

Belirli backup'ın geri yüklenmesini doğrular.

DR Test:

Bütün hizmet zincirinin tekrar çalışmasını ölçer.

Örneğin;

application,

database,

DNS,

network,

authentication,

external integration

birlikte doğrulanır.

### DR Drill Nedir?

Planlı olarak gerçekleştirilen Disaster Recovery tatbikatıdır.

Ekiplerin;

rol,

iletişim,

teknik işlem,

failover

süreçlerini test eder.

Cybersecurity senaryolarıyla birleştirildiğinde **Cyber Resilience Exercise** haline gelebilir.

### Tabletop DR Exercise Nedir?

Gerçek sistemleri kapatmadan senaryo üzerinden ekiplerin karar süreçlerinin test edilmesidir.

Örneğin:

“Ransomware nedeniyle primary data center ve backup management sistemi erişilemiyor.”

senaryosu verilir.

Ekipler;

hangi backup'ın kullanılacağını,

kimlerin devreye gireceğini,

hangi sırayla restore yapılacağını

anlatır.

### DR Runbook Nedir?

Kriz sırasında teknik ekiplerin uygulayacağı detaylı adımları tanımlar.

Örneğin;

hangi DNS değişecek,

hangi VM önce açılacak,

database nasıl restore edilecek,

hangi credential kullanılacak,

validation nasıl yapılacak

gibi.

Runbook güncel tutulmalıdır.

### Recovery Order Neden Önemlidir?

Tüm sistemler aynı anda restore edilemez.

Bağımlılıklar vardır.

Örneğin:

Identity/DNS

↓

Database

↓

Application

↓

Web

gibi bir sıralama gerekebilir.

Yanlış recovery order zaman kaybettirebilir.

### Application Dependency Mapping Nedir?

Bir iş servisinin hangi;

database,

API,

DNS,

identity,

third-party

servislerine bağlı olduğunu gösterir.

DR sırasında sadece ana uygulamayı restore etmek yeterli olmayabilir.

Dependency map bu yüzden önemlidir.

### Configuration Backup Neden Unutulur?

Kurumlar veri backup'ına odaklanırken;

firewall config,

switch config,

Kubernetes manifest,

cloud IaC,

certificate,

DNS configuration

gibi bileşenleri unutabilir.

Oysa büyük recovery'de bunlara da ihtiyaç vardır.

### Infrastructure as Code DR İçin Nasıl Kullanılır?

Terraform, Ansible ve benzeri otomasyonla altyapı yeniden oluşturulabilir.

Bu özellikle cloud DR için güçlüdür.

Ancak;

IaC repository,

state file,

secret,

pipeline

de yedeklenmeli ve korunmalıdır.

### Terraform State Neden Kritik?

Terraform state içerisinde cloud resource bilgileri ve bazı durumlarda hassas metadata bulunabilir.

State kaybedilirse infrastructure recovery zorlaşabilir.

Yanlış erişim ise security riski oluşturur.

Bu nedenle state;

encrypted,

access-controlled,

versioned

olmalıdır.

### Certificate Backup Neden Gereklidir?

Bazı sistemlerin geri dönüşünde;

TLS certificate,

private key,

PKI configuration

gerekebilir.

Certificate kaybolursa uygulama çalışsa bile kullanıcı güvenli bağlantı kuramayabilir.

Bu nedenle cryptographic asset recovery planı bulunmalıdır.

### Active Directory Recovery Backup'tan Nasıl Farklıdır?

AD gibi identity sistemleri özel recovery prosedürü gerektirebilir.

Tek DC backup'ını restore etmek her senaryoda yeterli değildir.

Forest compromise durumunda;

clean recovery,

credential reset,

trust validation

gibi ek adımlar gerekir.

Bu nedenle identity recovery ayrı DR planına sahip olmalıdır.

### Backup Logları SOC'a Gönderilmeli mi?

Evet, özellikle kritik olaylar.

Örneğin;

backup deletion,

retention change,

admin login,

repository change,

job disable,

immutability policy change

SIEM'e gönderilebilir.

Backup platformu güvenlik telemetry kaynağı olarak değerlendirilmelidir.

### Backup Delete Olayı Neden Kritik Alarmdır?

Büyük miktarda backup'ın ani silinmesi son derece anormal davranış olabilir.

Özellikle privileged account tarafından gerçekleşiyorsa ransomware hazırlığı veya insider threat göstergesi olabilir.

Bu nedenle yüksek severity ile izlenebilir.

### Backup Job Disabled Alarmı Önemli mi?

Evet.

Saldırgan yedek alınmasını durdurup bir süre bekleyebilir.

Sonra ransomware çalıştırabilir.

Bu durumda temiz restore point'lerin yaşı artar.

Dolayısıyla backup job disable veya schedule değişikliği önemli security event'tir.

### Retention Değişikliği Neden İzlenmeli?

Retention süresinin 90 günden 2 güne düşürülmesi saldırganın temiz geçmiş backup'ları yok etmesine yardımcı olabilir.

Bu nedenle retention policy değişiklikleri nadir ve kontrollü olmalıdır.

### Immutability Disable Girişimi Neden Alarm Üretmeli?

Bu en kritik backup security olaylarından biri olabilir.

Administrator'ın normal operasyon sırasında immutability özelliğini sık değiştirmesi beklenmez.

Bu işlem change management ile doğrulanmalıdır.

### Backup Authentication Logları Neden Önemlidir?

Yeni IP'den admin login.

Gece privileged erişim.

Başarısız login artışı.

MFA reset.

Bunlar backup platform compromise göstergesi olabilir.

Identity monitoring backup sistemini de kapsamalıdır.

### Backup SOC Use Case Örnekleri

Örnek use case'ler:

#### Mass Backup Deletion

#### Backup Job Disabled

#### Retention Reduced

#### Immutability Disabled

#### New Backup Administrator

#### Backup Repository Added

#### Unusual Restore Activity

#### Admin Login from New Source

Bu alarm setleri saldırgan recovery altyapısını hedeflediğinde erken detection sağlayabilir.

### Unusual Restore Activity Neden Şüpheli Olabilir?

Saldırgan veri çalmak için backup'tan restore gerçekleştirebilir.

Örneğin production'a değil farklı bir lokasyona database backup restore edilmesi araştırılmalıdır.

Dolayısıyla restore işlemleri de audit edilmelidir.

### Backup Data Exfiltration Mümkün mü?

Evet.

Backup tam veri kopyası içerdiği için saldırgan production database'e dokunmadan backup dosyasını çalabilir.

Bu nedenle backup sadece availability değil confidentiality açısından da korunmalıdır.

### Backup DLP veya Data Classification Gerekli mi?

Hassas backup içerikleri veri sınıflandırması kapsamında değerlendirilebilir.

Ancak büyük encrypted backup dosyaları klasik DLP için zor olabilir.

En önemli kontroller;

access control,

encryption,

monitoring,

restricted export

olacaktır.

### Tape Backup Hâlâ Kullanılır mı?

Evet.

Tape özellikle offline/air-gapped backup için hâlâ bazı kurumlarda kullanılır.

Avantajı fiziksel ayrışmadır.

Ancak;

operasyon,

saklama,

restore süresi

daha zor olabilir.

Teknoloji seçimi RTO/RPO ve risk profiline bağlıdır.

### Tape Backup Ransomware'e Karşı Güvenli midir?

Offline ise güçlü koruma sağlayabilir.

Ancak tape library sürekli network'e bağlı ve software tarafından yönetiliyorsa yine saldırı yüzeyi bulunabilir.

Fiziksel medya yönetimi ve inventory de önemlidir.

### Cloud Backup ile Tape Birlikte Kullanılabilir mi?

Evet.

Hybrid backup stratejisi oluşturulabilir.

Örneğin:

Local fast backup.

Cloud immutable copy.

Offline tape archive.

Bu model farklı risklere karşı katmanlı dayanıklılık sağlar.

### Backup Vendor Lock-In Riski Nedir?

Backup yalnızca tek vendor proprietary formatında tutuluyorsa vendor veya platform problemi recovery'yi zorlaştırabilir.

Kritik kurumlar recovery alternatiflerini değerlendirebilir.

Ancak multi-vendor yapı da operasyonel karmaşıklığı artırır.

### SaaS Verileri Otomatik Yedekleniyor mu?

Her zaman kurumun beklediği şekilde değil.

Microsoft 365, CRM veya diğer SaaS servislerinde provider yüksek availability ve retention özellikleri sunabilir.

Ancak kurumun ihtiyaç duyduğu bağımsız point-in-time backup veya uzun süreli recovery farklı olabilir.

SaaS backup gereksinimi ayrıca analiz edilmelidir.

### Microsoft 365 Backup Neden Ayrı Değerlendirilmeli?

Exchange Online, SharePoint ve OneDrive için;

retention,

versioning,

recycle bin

mekanizmaları bulunabilir.

Ancak bunlar her senaryoda klasik bağımsız backup'ın yerini tutmaz.

Örneğin;

malicious deletion,

long-term retention,

cross-tenant recovery

gereksinimleri değerlendirilebilir.

### Cloud Native Snapshot Güvenilir Backup mıdır?

Tek başına olmayabilir.

Snapshot;

aynı account,

aynı region,

aynı credential plane

içerisindeyse saldırgan tarafından silinebilir.

Bu nedenle cross-account, immutability ve backup vault yaklaşımları önemlidir.

### Ransomware Recovery Planında Fidye Ödeme Senaryosu Olmalı mı?

Kriz yönetimi açısından organizasyonun hukuki ve yönetsel karar süreci önceden tanımlanabilir.

Ancak teknik recovery stratejisi fidye ödemesine bağımlı olmamalıdır.

Amaç kurumun kendi güvenilir yedeklerinden geri dönebilecek kapasiteye sahip olmasıdır.

### Double Extortion Backup ile Çözülür mü?

Tam olarak hayır.

**Double Extortion** modelinde saldırgan veriyi hem şifreler hem çalar.

Backup availability sorununu çözebilir.

Ancak çalınan verinin yayınlanması riskini ortadan kaldırmaz.

Bu nedenle backup security ile Data Loss Prevention ve Incident Response birlikte yürütülmelidir.

### Triple Extortion Nedir?

Bazı saldırılarda;

encryption,

data theft,

DDoS veya müşteri/partner baskısı

birlikte kullanılabilir.

Bu durum ransomware'in sadece backup konusu olmadığını gösterir.

Cyber resilience çok katmanlı olmalıdır.

### Backup'tan Geri Döndükten Sonra Her Şey Biter mi?

Hayır.

Recovery sonrası;

credential reset,

patching,

security validation,

EDR kontrolü,

attack path remediation

yapılmalıdır.

Aksi halde saldırgan aynı zafiyet üzerinden tekrar içeri girebilir.

### Post-Recovery Validation Nedir?

Restore edilen ortamın güvenlik ve işlev açısından doğrulanmasıdır.

Örneğin;

EDR aktif mi?

Logging çalışıyor mu?

Kritik patch uygulanmış mı?

Şüpheli account var mı?

Application transaction başarılı mı?

Bu kontrol production'a dönmeden önce yapılmalıdır.

### Recovery Sonrası Credential Reset Neden Önemlidir?

Backup içerisinde eski compromised credential'lar bulunabilir.

Sistem restore edildiğinde saldırgan aynı parola veya key ile tekrar erişebilir.

Bu nedenle high-risk credential'ların reset/rotation süreci recovery planına dahil edilmelidir.

### Backup Security Assessment Nedir?

**Backup Security Assessment**, kurumun yedekleme altyapısının ransomware ve yetkisiz erişim risklerine karşı değerlendirilmesidir.

Bu çalışma;

backup architecture,

identity,

network,

immutability,

encryption,

monitoring,

restore

alanlarını kapsayabilir.

### Backup Security Assessment Nasıl Yapılır?

Genel yaklaşım:

#### \1. Backup Inventory

Hangi sistemlerin yedeklendiği belirlenir.

#### \2. Architecture Review

Repository ve data flow incelenir.

#### \3. Identity Review

Backup admin ve service account'lar değerlendirilir.

#### \4. Network Segmentation

Production-backup erişimleri kontrol edilir.

#### \5. Immutability

Offline/immutable kopyalar doğrulanır.

#### \6. Encryption

Backup ve key güvenliği incelenir.

#### \7. Monitoring

SIEM ve alarm kapsamı kontrol edilir.

#### \8. Restore Testing

Backup'ın gerçekten çalıştığı doğrulanır.

#### \9. RTO/RPO Review

İş hedefleriyle karşılaştırılır.

#### \10. Ransomware Scenario

Saldırganın backup'ları ne ölçüde etkileyebileceği analiz edilir.

### Ransomware Resilience Assessment Nedir?

Sadece backup'a değil tüm ransomware dayanıklılığına odaklanır.

Örneğin;

AD,

EDR,

network segmentation,

backup,

incident response,

DR

birlikte değerlendirilir.

Ama backup altyapısı bu çalışmanın en kritik parçalarından biridir.

### Backup Penetration Test Yapılır mı?

Yetkilendirilmiş güvenlik değerlendirmelerinde backup management yüzeyi ve erişim kontrolleri test edilebilir.

Ama production backup'ları silme veya bozma gibi yüksek riskli aksiyonlar uygulanmamalıdır.

Amaç kontrollü şekilde;

privilege,

network exposure,

credential risk

doğrulamaktır.

### Recovery Tatbikatı ile Red Team Birleştirilebilir mi?

Evet.

Örneğin Red Team kontrollü ransomware senaryosu simüle eder.

Blue Team saldırıyı tespit eder.

Backup/DR ekibi clean recovery süreci başlatır.

Yönetim tabletop kararları alır.

Bu yaklaşım gerçek bir **Cyber Resilience Exercise** oluşturur.

### Backup Security KPI'ları Nelerdir?

Örnek metrikler:

#### Backup Coverage

#### Immutable Backup Coverage

#### Offline Copy Coverage

#### Restore Test Success Rate

#### RTO Achievement Rate

#### RPO Achievement Rate

#### Privileged Backup Account Count

#### MFA/PAM Coverage

#### Unencrypted Backup Count

#### Backup Monitoring Coverage

#### Last Successful Restore Test

Bu KPI'lar sadece backup job sayısından daha anlamlıdır.

### Backup Coverage Nedir?

Kritik sistemlerin ne kadarının politika kapsamında yedeklendiğini gösterir.

Örneğin kurumda 100 kritik sistem var.

95'i backup kapsamındaysa:

%95 coverage.

Ama kalan %5'in hangi sistemler olduğu önemlidir.

Tek kritik ödeme database'i backup dışında kalmışsa oran yanıltıcı olabilir.

### Immutable Backup Coverage Nedir?

Kritik backup'ların ne kadarının immutable veya offline korumaya sahip olduğunu gösterir.

Modern ransomware hazırlığında önemli KPI'dır.

### Restore Success Rate Neden Backup Success Rate'ten Daha Değerli?

Backup Success:

Yedek alındı.

Restore Success:

Yedek gerçekten kullanılabildi.

Ransomware sonrası önemli olan ikinci metriktir.

Bu nedenle yönetim raporlamasında restore performansı öne çıkarılmalıdır.

### RTO Achievement Rate Nedir?

DR testlerinde hedeflenen RTO sürelerinin ne kadarında başarıyla karşılandığını gösterir.

Örneğin 10 sistem test edildi.

8'i hedef RTO içerisinde geri döndü.

%80 RTO achievement.

Bu iş sürekliliği için doğrudan anlamlı bir metriktir.

### Backup Security Score Oluşturulabilir mi?

Evet.

Örneğin;

Immutability,

Identity,

Segmentation,

Encryption,

Monitoring,

Restore Readiness

alanları puanlanabilir.

Ancak tek skor kritik risklerin yerini almamalıdır.

Örneğin:

Genel skor %90.

Ama Domain Admin tüm immutable backup'ları silebiliyor.

Bu tek bulgu çok daha önemlidir.

### Backup ve DR Raporunda Neler Olmalıdır?

Profesyonel raporda şu alanlar bulunabilir:

#### Executive Resilience Summary

Yönetim için genel durum.

#### Critical System Inventory

Yedeklenen kritik varlıklar.

#### Backup Architecture

Local, off-site, cloud ve offline yapı.

#### Ransomware Exposure

Saldırganın backup'a ulaşabileceği yollar.

#### Privileged Access

Backup admin ve service account riskleri.

#### Immutability

Offline/WORM/Object Lock durumu.

#### Encryption

Backup ve key management.

#### Monitoring

SIEM ve security alert coverage.

#### Restore Validation

Test sonuçları.

#### RTO/RPO

Hedef ve gerçek değerler.

#### Recovery Dependencies

AD, DNS, network ve application bağımlılıkları.

#### Remediation Roadmap

Öncelikli aksiyonlar.

### Yönetim İçin Backup Raporu Nasıl Anlatılmalı?

Yönetim için:

**“Toplam 1.800 backup job'ın %98'i başarılı.”**

ifadesi iyi görünebilir.

Ama daha değerli bilgi şudur:

**“Kritik sistemlerin %100'ü yedeklenmektedir; ancak kritik ERP ve Active Directory yedekleri aynı identity domain'i üzerinden yönetildiği için Domain Admin kompromizasyonunda recovery riskimiz bulunmaktadır. Kritik sistemlerde immutable backup coverage %72, son restore test başarı oranı %94 ve finans uygulamasının gerçek RTO'su hedeflenen 2 saat yerine 4 saat 20 dakika olarak ölçülmüştür.”**

Bu doğrudan yönetim kararını destekler.

### Backup Güvenliğinde En Büyük Hata Nedir?

En yaygın hata:

**“Backup alıyoruz, ransomware'e hazırız.”**

düşüncesidir.

Gerçekte saldırgan;

backup console'a erişebilir,

yedekleri silebilir,

retention'ı değiştirebilir,

immutability'yi devre dışı bırakabilir,

backup credential'larını ele geçirebilir.

Veya backup dosyaları tamamen sağlamdır ama hiç restore edilmemiştir.

Bu nedenle backup'ın varlığı ile **recoverability** aynı şey değildir.

### Ransomware'e Karşı Güçlü Backup Stratejisi Nasıl Olmalıdır?

Kurumsal yaklaşım şu katmanları değerlendirebilir:

#### 3-2-1-1-0 Backup

Birden fazla güvenilir kopya.

#### Immutable / Offline Copy

Ransomware izolasyonu.

#### Separate Identity

Production admin'den ayrılmış backup yönetimi.

#### MFA & PAM

Privileged backup erişimi.

#### Network Segmentation

Backup network isolation.

#### Encryption

Data confidentiality.

#### Security Monitoring

Backup'a yönelik saldırıların tespiti.

#### Regular Restore Tests

Recoverability doğrulaması.

#### Clean Room Recovery

Güvenli geri dönüş.

#### RTO/RPO Validation

İş hedeflerinin doğrulanması.

Bu katmanlardan herhangi biri tek başına yeterli değildir.

### Cyber Resilience Backup ile Nasıl İlişkilidir?

Cyber resilience'ın temel amacı hiçbir zaman saldırıya uğramamak değildir.

Gerçekçi hedef:

**Saldırıyı önlemek, tespit etmek, etkisini sınırlamak ve hızla toparlanmak.**

Backup ve Disaster Recovery özellikle son iki aşamada kritik rol oynar.

Bir kurum güçlü firewall ve EDR kullanabilir.

Ama hiçbir savunma %100 değildir.

Bu nedenle güvenli geri dönüş kapasitesi son savunma hattıdır.

### Sonuç: Backup Güvenliği “Yedeğimiz Var” Demekten Çok Daha Fazlasıdır

Ransomware dünyasında yedek artık pasif bir operasyon kaynağı değildir.

**Doğrudan saldırı hedefidir.**

Bu nedenle güvenli backup stratejisi sadece:

“Her gece yedek alıyoruz.”

cümlesiyle açıklanamaz.

Gerçek sorular şunlardır:

#### Backup hangi credential ile yönetiliyor?

#### Domain compromise olduğunda backup güvende kalıyor mu?

#### Yedekler değiştirilemez mi?

#### Offline veya cross-account kopya var mı?

#### Backup şifreli mi?

#### Saldırgan silme işlemi yaptığında SOC bunu görüyor mu?

#### Son gerçek restore testi ne zaman yapıldı?

#### En son temiz recovery point hangisi?

#### RTO ve RPO hedefleri gerçekten karşılanıyor mu?

Güçlü bir ransomware recovery mimarisi;

**Backup + Immutability + Identity Isolation + Network Segmentation + Monitoring + Restore Testing + Clean Recovery**

birlikte uygulandığında oluşur.

Çünkü bir backup'ın gerçek değeri alındığı gün değil:

**ihtiyaç duyulduğu gün ortaya çıkar.**

Ve o gün tek soru vardır:

#### Bu sistemi gerçekten geri getirebiliyor muyuz?

Sistem ve bulut güvenliği açısından artık önemli bileşenleri ayrı ayrı inceledik.

Sunucular.

Active Directory.

Microsoft 365.

Cloud.

IAM.

Cloud Misconfiguration.

Kubernetes.

Database.

Backup ve Disaster Recovery.

Ancak büyük cloud ortamlarında bu risklerin her birini farklı dashboard ve farklı ürünlerle yönetmek kısa sürede zorlaşabilir.

Bu nedenle modern Cloud Security yaklaşımında bir sonraki büyük konu farklı güvenlik kabiliyetlerinin tek bir risk görünümünde birleştirilmesidir.