Backup Güvenliği: Şifreleme, MFA, Yetkilendirme ve Restore Testleri

Bir kurumun backup alıyor olması, bu backup’ın güvenli olduğu anlamına gelmez.

Asıl önemli olan backup’ın;

yetkisiz kişiler tarafından okunamaması,

saldırgan tarafından silinememesi,

değiştirilememesi,

bozulmaması

ve gerektiğinde gerçekten restore edilebilmesidir.

Bu nedenle modern backup mimarisi yalnızca veri kopyalama süreci olarak görülmemelidir.

Backup altyapısı aynı zamanda;

kimlik güvenliği,

erişim kontrolü,

şifreleme,

network segmentasyonu,

izleme,

loglama,

değişmezlik

ve recovery testleri

ile korunması gereken kritik bir güvenlik sistemidir.

Bugün gelişmiş ransomware saldırılarında backup altyapısı doğrudan hedef alınmaktadır.

Saldırganlar yalnızca production sistemlerini şifrelemekle yetinmeyebilir.

Ayrıca;

backup sunucularını,

repository’leri,

snapshot’ları,

backup administrator hesaplarını,

cloud backup hesaplarını,

encryption key’leri

ve restore point’leri

hedefleyebilir.

Bu nedenle şu soru modern backup güvenliğinin merkezindedir:

“Production ortamı tamamen ele geçirilirse backup ortamı yine de güvenli kalabilir mi?”

Backup Güvenliği Nedir?

Backup güvenliği, yedekleme verisinin ve yedekleme altyapısının gizlilik, bütünlük ve erişilebilirlik prensipleriyle korunmasını ifade eder.

Başka bir ifadeyle backup;

okunmamalı,

değiştirilmemeli,

silinmemeli

ve gerektiğinde erişilebilir olmalıdır.

Bu yaklaşım klasik CIA üçlüsüyle açıklanabilir:

Confidentiality – Gizlilik

Integrity – Bütünlük

Availability – Erişilebilirlik

Backup Verisi Neden Çok Kritik Bir Varlıktır?

Backup çoğu zaman kurumun üretim verisinin tam kopyasını içerir.

Örneğin tek bir backup repository içerisinde;

müşteri bilgileri,

çalışan verileri,

database’ler,

e-postalar,

kaynak kodlar,

finansal bilgiler,

sözleşmeler,

Active Directory

gibi birçok kritik veri bulunabilir.

Bu nedenle backup repository saldırgan açısından yüksek değerli bir hedeftir.

Bazı durumlarda production ortamından bile daha fazla veri tek noktada bulunabilir.

Backup Encryption Nedir?

Backup Encryption, yedeklenen verinin şifrelenerek saklanmasıdır.

Amaç backup dosyaları ele geçirilse bile içeriğin okunmasını engellemektir.

Şifreleme iki temel noktada uygulanır:

Encryption at Rest

ve

Encryption in Transit

Encryption at Rest Nedir?

Encryption at Rest, backup verisinin storage üzerinde şifreli tutulmasıdır.

Örneğin;

disk,

NAS,

object storage,

cloud storage,

tape

üzerindeki backup dosyaları şifrelenebilir.

Backup storage çalınsa veya yetkisiz kişi storage’a erişse bile veri şifreli kalır.

Encryption in Transit Nedir?

Encryption in Transit, backup verisi network üzerinden aktarılırken şifrelenmesidir.

Örneğin:

Production Server

↓

TLS

↓

Backup Server

şeklinde güvenli bağlantı kullanılabilir.

Bu sayede network üzerinde veri dinleyen saldırgan backup trafiğini okuyamaz.

Backup Trafiği Neden Şifrelenmeli?

Backup işlemleri sırasında büyük miktarda hassas veri network üzerinden geçebilir.

Örneğin:

database dump,

VM image,

mailbox,

dosya sistemi

aktarılabilir.

Bu trafik şifrelenmezse network üzerinde ciddi veri sızıntısı riski oluşabilir.

Backup Encryption Key Neden Kritiktir?

Backup dosyaları şifreliyse encryption key olmadan restore yapılamayabilir.

Bu nedenle key management backup güvenliğinin temel parçalarından biridir.

Key kaybolursa backup sağlam olsa bile veri kullanılamaz hale gelebilir.

Encryption Key Nerede Saklanmalı?

Encryption key backup dosyasıyla aynı yerde tutulmamalıdır.

Örneğin:

backup file + password.txt

aynı klasörde tutulursa şifreleme neredeyse anlamını kaybeder.

Key;

secure vault,

HSM,

password manager,

secret management sistemi

gibi güvenli ortamlarda saklanabilir.

HSM Nedir?

HSM:

Hardware Security Module

anlamına gelir.

Kriptografik anahtarların güvenli şekilde oluşturulması, saklanması ve kullanılması için kullanılan özel güvenlik cihazı veya servisidir.

Yüksek güvenlik gerektiren backup ortamlarında encryption key yönetimi için değerlendirilebilir.

Key Rotation Nedir?

Encryption key’lerin belirli aralıklarla değiştirilmesi:

Key Rotation

olarak adlandırılır.

Bu yaklaşım credential ve key compromise riskini azaltabilir.

Ancak eski backup’ların restore edilebilmesi için eski key’lerin güvenli şekilde korunması gerekebilir.

Backup Password Kaybolursa Ne Olur?

Bazı backup ürünlerinde encryption password kaybolduğunda vendor dahi backup’ı açamayabilir.

Bu nedenle backup password recovery süreci önceden planlanmalıdır.

MFA Backup Sistemlerinde Neden Önemlidir?

MFA:

Multi-Factor Authentication

anlamına gelir.

Bir kullanıcının yalnızca parola ile değil ikinci bir doğrulama faktörüyle giriş yapmasını sağlar.

Örneğin:

parola

mobil doğrulama

kullanılabilir.

Backup administrator hesaplarında MFA kritik öneme sahiptir.

Neden Backup Admin Hesabı Özellikle Korunmalı?

Backup administrator hesabı genellikle;

job silebilir,

restore point silebilir,

retention değiştirebilir,

repository yönetebilir,

backup export edebilir.

Bu nedenle saldırgan bu hesabı ele geçirirse recovery altyapısını sabote edebilir.

MFA Ransomware’e Karşı Tek Başına Yeterli mi?

Hayır.

MFA önemli bir katmandır.

Ancak ayrıca;

least privilege,

PAM,

network segmentation,

immutable backup,

ayrı administrator hesapları

gibi kontroller uygulanmalıdır.

Backup Admin Hesabı Günlük Kullanılmalı mı?

Hayır.

Backup admin hesabı ile;

e-posta okumak,

internette gezinmek,

doküman açmak

risk oluşturur.

Phishing veya endpoint malware bu hesabı ele geçirebilir.

Bu nedenle günlük kullanıcı hesabı ve backup administrator hesabı ayrılmalıdır.

Separate Backup Admin Nedir?

Separate Backup Admin yaklaşımı, backup yönetimi için bağımsız administrator hesaplarının kullanılmasıdır.

Örneğin:

[email protected]

günlük kullanıcı hesabı olabilir.

backup.ramazan

ise yalnızca backup yönetimi için kullanılabilir.

Bu yöntem credential compromise riskini azaltır.

Backup Admin Domain Admin Olmalı mı?

Mümkün olduğunca hayır.

Domain Admin çok geniş yetkiye sahiptir.

Backup yöneticisinin bütün Active Directory ortamında sınırsız yetkiye ihtiyacı olmayabilir.

Least Privilege yaklaşımı uygulanmalıdır.

Least Privilege Nedir?

Least Privilege:

Minimum Yetki Prensibi

olarak ifade edilir.

Bir kullanıcıya yalnızca görevini yerine getirecek kadar yetki verilir.

Örneğin backup operator yalnızca;

backup job yönetimi,

restore

yetkisine sahip olabilir.

Kullanıcı oluşturma veya domain yönetimi yetkisine sahip olmak zorunda değildir.

RBAC Nedir?

RBAC:

Role-Based Access Control

yani:

Rol Tabanlı Erişim Kontrolü

anlamına gelir.

Yetkiler kullanıcı bazında değil rol bazında tanımlanır.

Örneğin:

Backup Viewer

Backup Operator

Backup Administrator

Security Auditor

gibi roller oluşturulabilir.

Backup Viewer Rolü Ne İşe Yarar?

Backup Viewer yalnızca;

job durumunu,

raporları,

backup sonuçlarını

görebilir.

Silme veya restore yetkisi olmayabilir.

Bu özellikle SOC ve denetim ekipleri için faydalıdır.

Backup Operator ile Administrator Ayrılmalı mı?

Kritik ortamlarda ayrılabilir.

Backup Operator günlük operasyon yapar.

Backup Administrator ise;

policy,

repository,

retention,

security

ayarlarını yönetebilir.

Bu yöntem görevlerin ayrılığı prensibini destekler.

Segregation of Duties Nedir?

Segregation of Duties:

Görevlerin Ayrılığı

anlamına gelir.

Tek bir kişinin tüm kritik işlemleri yapamaması hedeflenir.

Örneğin;

bir kişi backup job oluşturur,

başka kişi retention policy onaylar.

Bu yaklaşım özellikle yüksek güvenlikli kurumlarda kullanılır.

PAM Backup Güvenliğinde Nasıl Kullanılır?

PAM:

Privileged Access Management

yani:

Ayrıcalıklı Erişim Yönetimi

sistemidir.

Backup administrator credential’ları PAM içerisinde saklanabilir.

Kullanıcılar gerçek password’ü görmeden kontrollü oturum açabilir.

PAM Ne Sağlar?

PAM şu avantajları sağlayabilir:

credential vault,

session recording,

password rotation,

approval workflow,

time-limited access,

audit logging.

Bu nedenle backup yönetimi için güçlü bir güvenlik katmanıdır.

JIT Access Nedir?

JIT:

Just-In-Time Access

anlamına gelir.

Administrator yetkisi sürekli verilmez.

İhtiyaç olduğunda kısa süreli olarak aktif edilir.

Örneğin backup administrator yetkisi:

2 saat

için verilebilir.

Bu süre sonunda otomatik kaldırılır.

JEA Nedir?

JEA:

Just Enough Administration

yaklaşımıdır.

Kullanıcıya yalnızca belirli yönetim işlemleri için yetki verir.

Bu şekilde full administrator erişimi gerekmeyebilir.

Privileged Access Workstation Nedir?

PAW:

Privileged Access Workstation

yüksek yetkili işlemler için ayrılmış güvenli yönetim bilgisayarıdır.

Bu cihaz üzerinde;

e-posta kullanılmaz,

normal internet gezintisi yapılmaz,

gereksiz uygulama kurulmaz.

Backup administration bu cihazlardan yapılabilir.

Network Segmentation Backup Güvenliğinde Neden Önemlidir?

Backup server production network ile aynı düz network üzerinde bulunursa saldırgan lateral movement ile backup sistemine ulaşabilir.

Bu nedenle backup network ayrı segmentte tutulabilir.

Örnek Backup Network Segmentasyonu

Kurumsal network şu şekilde ayrılabilir:

User VLAN

Server VLAN

Management VLAN

Backup VLAN

Cyber Recovery VLAN

Bu yaklaşım saldırganın network içerisinde hareketini sınırlar.

Backup VLAN Herkes Tarafından Erişilebilir Olmalı mı?

Hayır.

Backup VLAN’a yalnızca gerekli sistemlerin erişmesine izin verilmelidir.

Firewall üzerinden allow-list uygulanabilir.

Backup Firewall Kuralları Nasıl Olmalı?

Genel prensip:

Default Deny

olmalıdır.

Yani yalnızca gereken bağlantılar açılır.

Örneğin;

backup proxy → repository

backup server → production workload

management workstation → backup console

gibi akışlara izin verilir.

Any-Any Kuralı Neden Tehlikelidir?

Backup network için:

Any → Any → Allow

kuralı segmentasyonun anlamını ortadan kaldırır.

Bu durumda saldırgan network üzerinde kolayca hareket edebilir.

Backup Management Interface İnternete Açık Olmalı mı?

Genellikle hayır.

Backup yönetim konsolu doğrudan internet üzerinden erişilebilir olmamalıdır.

Gerekirse;

VPN,

ZTNA,

jump server,

private network

üzerinden erişim sağlanabilir.

Jump Server Nedir?

Jump Server veya Bastion Host, yönetim erişiminin geçtiği kontrollü ara sunucudur.

Administrator önce jump server’a bağlanır.

Daha sonra backup ortamına erişir.

Bu yöntem doğrudan network erişimini azaltır.

Backup Server Production Domain’e Dahil Olmalı mı?

Bu karar mimariye göre değerlendirilmelidir.

Production domain’e bağlı backup server operasyon kolaylığı sağlayabilir.

Ancak Domain Admin compromise durumunda backup ortamı da risk altına girebilir.

Yüksek güvenlikli yapılarda ayrı identity veya workgroup yaklaşımı değerlendirilebilir.

Backup Identity Separation Nedir?

Backup Identity Separation, backup sisteminin kimlik doğrulamasını production Active Directory’den ayırmayı hedefler.

Örneğin;

ayrı domain,

local hardened account,

ayrı cloud identity

kullanılabilir.

Production AD Tamamen Kaybolursa Backup’a Erişilebilir mi?

Bu kritik bir test sorusudur.

Eğer backup konsoluna login olmak için production AD gerekiyorsa AD kaybedildiğinde recovery süreci başlayamayabilir.

Bu nedenle break-glass hesapları planlanmalıdır.

Break-Glass Account Nedir?

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

Bu hesap;

offline korunabilir,

çok güçlü parola kullanabilir,

MFA veya ek kontrollerle korunabilir.

Break-Glass Account Sürekli Kullanılmalı mı?

Hayır.

Sadece acil durumlarda kullanılmalıdır.

Kullanımı alarm üretmelidir.

Backup Service Account Nedir?

Backup yazılımları production sistemlerine erişmek için service account kullanabilir.

Bu hesaplar;

VM,

database,

file server,

application

üzerinde backup işlemi yapabilir.

Service Account’lara Domain Admin Verilmeli mi?

Genellikle hayır.

Bu önemli bir güvenlik hatasıdır.

Service account yalnızca ihtiyacı olan kaynaklara erişmelidir.

Service Account Password Nasıl Korunmalı?

Password;

script,

Excel,

text dosyası

içerisinde tutulmamalıdır.

Secret vault veya PAM kullanılabilir.

Service Account Interactive Login Yapabilmeli mi?

Mümkün olduğunca engellenmelidir.

Backup service account yalnızca servis tarafından kullanılmalıdır.

Normal kullanıcı oturumu açmamalıdır.

Backup Repository Güvenliği Nedir?

Backup Repository, backup dosyalarının saklandığı storage alanıdır.

Bu alan ransomware saldırılarında en kritik hedeflerden biridir.

Repository;

güçlü erişim kontrolü,

immutable storage,

network izolasyonu,

şifreleme

ile korunmalıdır.

Hardened Repository Nedir?

Hardened Repository, saldırı yüzeyi azaltılmış ve backup verisini güçlü şekilde koruyacak şekilde yapılandırılmış repository’dir.

Örneğin;

minimum servis,

ayrı credential,

restricted network,

immutable filesystem,

MFA destekli yönetim

kullanılabilir.

Repository Normal SMB Share Olmalı mı?

Kritik backup ortamında herkese açık standart SMB share kullanımı risklidir.

Örneğin ransomware server üzerinde çalışırsa network share’e erişerek backup dosyalarını şifreleyebilir.

Immutable Backup Neden Backup Güvenliğinin Temelidir?

Immutable backup, belirli retention süresi içerisinde değiştirilemeyen veya silinemeyen backup kopyasıdır.

Saldırgan administrator hesabını ele geçirse bile immutable restore point’i silemeyebilir.

Bu ransomware dayanıklılığını ciddi şekilde artırır.

Immutable Backup Tek Başına Yeterli mi?

Hayır.

Immutable backup;

MFA,

network segmentation,

encryption,

identity separation,

restore testing

ile birlikte kullanılmalıdır.

Object Lock Nedir?

Object Lock, object storage içerisindeki backup dosyalarının belirli süre değiştirilmesini veya silinmesini engelleyebilir.

Cloud backup ortamlarında yaygın bir immutable backup yöntemidir.

Retention Lock Neden Kritik?

Retention Lock, backup retention süresinin saldırgan tarafından düşürülmesini engellemeye yardımcı olur.

Örneğin attacker retention süresini:

30 gün → 0 gün

yapamamalıdır.

Air-Gap Backup Güvenliğe Ne Katar?

Air-Gap backup, backup kopyasını production ortamından izole eder.

Bu;

physical

veya

logical

air-gap olabilir.

Amaç production compromise durumunda attacker’ın backup kopyasına erişememesidir.

Offline Backup Hâlâ Gerekli mi?

Bazı kritik sistemlerde evet.

Tape veya offline media, ransomware saldırganının network üzerinden erişemeyeceği bağımsız kopya sağlayabilir.

Backup Logları Neden Kritik?

Backup sisteminde yapılan her kritik işlem loglanmalıdır.

Örneğin;

login,

job creation,

job deletion,

retention change,

repository deletion,

restore,

export,

administrator creation

kayıt altına alınmalıdır.

Backup Logları Nerede Saklanmalı?

Yalnızca backup server üzerinde tutulmamalıdır.

Saldırgan backup server’ı ele geçirirse logları silebilir.

Bu nedenle loglar SIEM gibi merkezi platforma gönderilebilir.

SIEM Backup Sistemlerini İzlemeli mi?

Evet.

Backup sistemleri çoğu kurumda SIEM kapsamına alınmaz.

Bu ciddi bir eksiklik olabilir.

Backup event’leri security monitoring için değerlidir.

Backup İçin Örnek SIEM Use Case’leri

Örneğin:

Backup Administrator Login Outside Working Hours

Backup Job Disabled

Retention Reduced

Repository Deleted

Multiple Restore Points Deleted

MFA Disabled

Immutable Policy Changed

Backup Service Stopped

gibi use case’ler oluşturulabilir.

Restore İşlemleri Neden Loglanmalı?

Restore işlemi normalde faydalı bir işlemdir.

Ancak saldırgan backup içerisinden veri çıkarmak için restore kullanabilir.

Örneğin;

müşteri database’i,

mailbox,

source code

başka lokasyona restore edilebilir.

Bu nedenle restore işlemleri de audit edilmelidir.

Backup Export İşlemi Riskli midir?

Evet.

Backup export özelliği data exfiltration amacıyla kötüye kullanılabilir.

Bu nedenle export yetkisi sınırlı olmalıdır.

Restore Test Nedir?

Restore Test, backup’ın gerçekten geri yüklenebilir olup olmadığının doğrulanmasıdır.

Backup job’ın başarılı olması restore garantisi değildir.

Bu nedenle kurum düzenli restore testleri yapmalıdır.

Backup Success ile Restore Success Aynı Şey midir?

Hayır.

Backup yazılımı:

Success

gösterebilir.

Ancak restore sırasında;

corrupt data,

missing block,

encryption key hatası,

database consistency problemi

ortaya çıkabilir.

Bu nedenle tek gerçek doğrulama restore’dur.

“Backup Alındı” Mesajı Neden Yeterli Değil?

Backup job başarılı olabilir.

Ancak backup;

bozuk,

eksik,

şifre çözümü başarısız,

uygulama tutarsız

olabilir.

Bu nedenle backup operasyonunun başarı kriteri:

Restore edilebilirlik

olmalıdır.

Backup Integrity Verification Nedir?

Backup Integrity Verification, backup verisinin bütünlüğünü doğrulayan işlemdir.

Örneğin;

checksum,

hash,

block validation

kullanılabilir.

Amaç backup dosyasının bozulup bozulmadığını tespit etmektir.

Hash Backup Güvenliğinde Nasıl Kullanılır?

Backup dosyasının hash değeri alınabilir.

Dosya değişirse hash değeri de değişir.

Bu yöntem backup bütünlüğünü doğrulamak için kullanılabilir.

Checksum ile Malware Taraması Aynı Şey mi?

Hayır.

Checksum dosyanın değişip değişmediğini kontrol eder.

Malware scanning ise backup içeriğinde zararlı yazılım olup olmadığını analiz eder.

Clean Backup Nedir?

Clean Backup, saldırgan persistence veya malware içermediğine güvenilen restore point’tir.

Ransomware olaylarında en yeni backup her zaman clean olmayabilir.

Restore Öncesi Malware Taraması Yapılmalı mı?

Özellikle cyber recovery senaryosunda evet.

Restore edilen sistem;

EDR,

antivirus,

IOC scan,

YARA

gibi yöntemlerle kontrol edilebilir.

Clean Room Recovery Nedir?

Clean Room Recovery, sistemlerin production’a dönmeden önce izole güvenli ortamda restore edilip test edilmesidir.

Amaç infected backup’ın production’a yeniden taşınmasını önlemektir.

Restore Test Seviyeleri

Kurum farklı restore testleri uygulayabilir.

File-Level Restore

Tek dosya restore edilir.

VM Restore

Tüm sanal makine geri getirilir.

Database Restore

Database restore edilir ve tutarlılık kontrol edilir.

Application Restore

Uygulamanın tüm bileşenleri test edilir.

Full DR Restore

Bir iş hizmeti tamamen geri getirilir.

File Restore Tek Başına Yeterli mi?

Hayır.

Tek dosya restore etmek backup repository’nin çalıştığını gösterir.

Ancak tüm sistemin disaster recovery kapasitesini göstermez.

Database Restore Neden Ayrı Test Edilmeli?

Database yalnızca dosyalardan oluşmaz.

Transaction consistency önemlidir.

Backup dosyası restore olabilir ancak database açılmayabilir.

Bu nedenle application-consistent backup önemlidir.

Application-Consistent Backup Nedir?

Application-Consistent Backup, uygulama verilerinin tutarlı durumda alınmasını sağlar.

Örneğin database transaction’ları backup öncesinde düzgün şekilde commit veya flush edilebilir.

Crash-Consistent Backup Nedir?

Crash-Consistent Backup, sistemin anlık disk durumunu yakalar.

Elektrik kesintisi olmuş gibi düşünülebilir.

Bazı uygulamalar bu backup’tan açılabilir.

Ancak database gibi sistemlerde recovery gerekebilir.

Restore Test Ne Sıklıkla Yapılmalı?

Tek bir doğru süre yoktur.

Kritik sistemlerde daha sık test yapılmalıdır.

Örneğin;

Tier 1 → aylık veya üç aylık

Tier 2 → üç aylık veya altı aylık

Tier 3 → yıllık

gibi risk bazlı plan oluşturulabilir.

Bu değerler kurumun ihtiyacına göre belirlenmelidir.

Restore Test Otomatik Yapılabilir mi?

Evet.

Bazı backup platformları backup’tan VM başlatıp otomatik test yapabilir.

Örneğin;

VM boot ediyor mu?

Service çalışıyor mu?

Network erişimi var mı?

kontrol edilebilir.

Bu sürekli doğrulama sağlar.

Automated Restore Verification Yeterli mi?

Hayır.

Otomatik testler değerlidir.

Ancak gerçek DR tatbikatının yerini tamamen tutmaz.

İş biriminin uygulamayı doğrulaması gerekir.

Backup Restore Testinde RTO Ölçülmeli mi?

Evet.

Restore süresi gerçek RTO hedefiyle karşılaştırılmalıdır.

Örneğin:

RTO hedefi = 2 saat

Gerçek restore = 6 saat

ise mevcut mimari yetersizdir.

Restore Testinde RPO Ölçülmeli mi?

Evet.

Restore edilen verinin timestamp’i kontrol edilmelidir.

Bu sayede gerçek veri kaybı ölçülür.

Backup Capacity RTO’yu Nasıl Etkiler?

Backup repository performansı restore süresini doğrudan etkiler.

Örneğin;

network throughput,

storage IOPS,

CPU,

decompression,

decryption

restore hızını belirler.

Backup Hızlı Alınıp Yavaş Restore Edilebilir mi?

Evet.

Bu sık karşılaşılan bir problemdir.

Kurum backup penceresini optimize eder ancak restore performansını test etmez.

Felaket günü gerçek problem ortaya çıkar.

Restore Throughput Ölçülmeli mi?

Evet.

Örneğin backup repository gerçek restore sırasında:

500 MB/s

sağlıyorsa 50 TB verinin restore süresi tahmin edilebilir.

Ancak uygulama katmanları toplam süreyi daha da uzatabilir.

Backup Catalog Neden Korunmalı?

Backup Catalog hangi restore point’in nerede bulunduğunu gösterir.

Catalog bozulursa backup dosyaları mevcut olsa bile recovery zorlaşabilir.

Bu nedenle catalog database de backup alınmalı ve korunmalıdır.

Backup Configuration Backup Alınmalı mı?

Evet.

Backup sisteminin;

job,

policy,

repository,

credential mapping,

retention configuration

ayarları ayrı olarak korunmalıdır.

Backup Sunucusu Kaybolursa Ne Olur?

Kurum backup server’ın kendisinin recovery planına sahip olmalıdır.

Şu soru sorulmalıdır:

Backup server tamamen silinirse repository’den restore yapabiliyor muyuz?

Bare-Metal Recovery Nedir?

Bare-Metal Recovery, işletim sistemi ve uygulamanın boş donanım veya VM üzerine tamamen geri yüklenmesidir.

Backup server’ın tamamen kaybedildiği senaryolarda faydalı olabilir.

Backup Configuration Dokümante Edilmeli mi?

Evet.

Sadece backup sisteminin içinde bulunan konfigürasyona güvenilmemelidir.

Kritik;

IP,

hostname,

repository,

credential process,

encryption key,

restore procedure

bilgileri dokümante edilmelidir.

Dokumentasyon Nerede Saklanmalı?

Sadece production SharePoint içerisinde tutulursa felaket sırasında erişilemeyebilir.

Kritik recovery dokümanlarının offline veya bağımsız kopyaları bulunabilir.

Backup Güvenliği İçin Change Management

Retention veya repository gibi kritik ayarlar rastgele değiştirilmemelidir.

Değişiklikler;

ticket,

approval,

audit

süreçlerine tabi olabilir.

Backup Policy Değişikliği Neden Hassastır?

Yanlış bir policy değişikliği eski backup’ların otomatik silinmesine neden olabilir.

Bu nedenle kritik retention değişikliklerinde ikinci onay mekanizması değerlendirilebilir.

Four-Eyes Principle Nedir?

Four-Eyes Principle, kritik işlemin ikinci kişi tarafından onaylanmasıdır.

Örneğin:

immutable retention azaltılması

iki administrator onayı gerektirebilir.

Backup Monitoring'de Hangi KPI'lar Kullanılabilir?

Kurum backup güvenliği için şu metrikleri takip edebilir:

Backup Success Rate

Restore Success Rate

Average Restore Time

RPO Compliance

RTO Compliance

Immutable Backup Coverage

Offsite Backup Coverage

Failed Job Count

Restore Test Frequency

Privileged Access Events

Backup Success Rate Tek Başına Yeterli KPI mı?

Hayır.

%100 backup success olsa bile hiç restore test edilmemiş olabilir.

Bu nedenle Restore Success Rate daha güçlü bir göstergedir.

Restore Success Rate Nedir?

Belirli dönemde yapılan restore testlerinin ne kadarının başarılı olduğunu gösterir.

Örneğin:

20 restore testi

19 başarılı

Restore Success Rate:

%95

olabilir.

Immutable Coverage Nedir?

Kritik sistemlerin ne kadarının immutable backup’a sahip olduğunu gösterir.

Örneğin 100 kritik workload’dan 80’i immutable ise coverage %80’dir.

Backup Security Assessment Nedir?

Backup Security Assessment, backup mimarisinin siber güvenlik açısından değerlendirilmesidir.

Bu çalışma sırasında;

network,

identity,

repository,

encryption,

logging,

immutability,

restore testing

kontrol edilebilir.

Backup Penetration Test Yapılır mı?

Backup sistemleri doğrudan kritik güvenlik kapsamına alınabilir.

Ancak production backup altyapısında kontrollü ve risk bazlı test yapılmalıdır.

Amaç backup hizmetini bozmak değil zayıf noktaları tespit etmektir.

Backup Hardening Checklist

Backup server üzerinde;

gereksiz servisler kapatılmalı,

OS güncel tutulmalı,

firewall aktif edilmeli,

MFA kullanılmalı,

default hesaplar kontrol edilmeli,

RDP/SSH erişimi sınırlandırılmalı,

EDR/XDR değerlendirilmelidir.

Backup Server’a EDR Kurulmalı mı?

Ürün uyumluluğu dikkate alınarak değerlendirilebilir.

EDR;

credential theft,

malware,

ransomware,

lateral movement

gibi davranışları tespit edebilir.

Backup Server Antivirus Exclusion Riski

Backup ürünleri performans için bazı exclusion’lar isteyebilir.

Bu exclusion’ların çok geniş tanımlanması saldırganın kötüye kullanabileceği kör noktalar oluşturabilir.

Bu nedenle vendor önerileri kontrollü uygulanmalıdır.

Backup Patch Management

Backup ürünleri ve işletim sistemleri güncel tutulmalıdır.

Backup kritik diye yıllarca güncellememek ciddi zafiyet oluşturabilir.

Patch’ler;

test,

change management,

rollback plan

ile uygulanmalıdır.

Vulnerability Management Backup Sistemlerini Kapsamalı mı?

Evet.

Backup server,

management console,

storage,

repository

zafiyet taramalarına dahil edilmelidir.

Backup API Güvenliği

Modern backup platformları API sunabilir.

API token’ları yüksek yetkili olabilir.

Bu nedenle;

token rotation,

least privilege,

IP restriction,

audit logging

uygulanmalıdır.

Backup Security ve Zero Trust

Backup ortamında Zero Trust yaklaşımı uygulanabilir.

Temel prensipler:

Never Trust

Always Verify

Her erişim doğrulanmalıdır.

Her administrator sürekli güvenilir kabul edilmemelidir.

Zero Trust Backup Nasıl Uygulanır?

Örneğin;

ayrı identity,

MFA,

PAM,

JIT access,

network micro-segmentation,

immutable backup,

continuous monitoring

birlikte kullanılabilir.

Backup Güvenliği İçin 3-2-1-1-0

Modern backup stratejilerinde:

3 veri kopyası

2 farklı storage/media

1 offsite kopya

1 immutable veya offline kopya

0 doğrulama hatası

yaklaşımı kullanılabilir.

Buradaki:

0

restore doğrulamasının önemini vurgular.

“0 Errors” Ne Anlama Gelir?

Backup yalnızca oluşturulmaz.

Integrity ve restore testlerinden geçirilir.

Hedef:

doğrulanmış backup’larda sıfır hata

olmasıdır.

Backup Güvenlik Testi İçin Kritik Senaryo 1

Şu varsayım yapılabilir:

Domain Admin hesabı saldırganda.

Bu durumda:

Backup silinebiliyor mu?

Repository erişilebiliyor mu?

Retention değiştirilebiliyor mu?

Eğer evetse identity separation güçlendirilmelidir.

Kritik Senaryo 2

Backup Administrator hesabı ele geçirildi.

Saldırgan tüm restore point’leri silebiliyor mu?

Immutable backup bunu engelleyebilmelidir.

Kritik Senaryo 3

Production network tamamen kaybedildi.

Backup’a erişmek için production DNS veya AD gerekiyor mu?

Eğer gerekiyorsa recovery tasarımı risklidir.

Kritik Senaryo 4

Cloud Administrator hesabı ele geçirildi.

Cloud backup aynı account’ta mı?

Object Lock kaldırılabiliyor mu?

Backup farklı account’ta mı?

Bu test cloud recovery güvenliğini gösterir.

Kritik Senaryo 5

Backup server tamamen silindi.

Repository’den bağımsız restore yapılabiliyor mu?

Backup catalog yeniden oluşturulabiliyor mu?

Bu senaryo mutlaka test edilmelidir.

KVKK Açısından Backup Güvenliği

Backup içerisinde kişisel veri varsa bu veri de korunmalıdır.

Bu nedenle;

şifreleme,

erişim kontrolü,

loglama,

retention,

imha

politikaları backup ortamında da uygulanmalıdır.

Backup Silme ve İmha Süreci

Retention süresi dolduğunda backup verileri güvenli şekilde silinmelidir.

Ancak immutable backup retention süresi dolmadan silinemeyebilir.

Bu nedenle hukuki ve teknik retention birlikte planlanmalıdır.

ISO/IEC 27001 Açısından Backup Güvenliği

ISO/IEC 27001 bilgi güvenliği yönetiminde backup ve ICT continuity kontrolleri risk bazlı olarak ele alınır.

Backup süreçlerinin;

tanımlanmış,

korunan,

izlenen,

test edilen

bir yapı içerisinde olması önemlidir.

ISO 22301 Açısından Restore Testi

İş sürekliliği yaklaşımında planların yalnızca yazılması yeterli değildir.

Kurum kritik hizmetleri gerçekten geri getirebildiğini test etmelidir.

Bu nedenle restore ve DR tatbikatları iş sürekliliğinin önemli parçalarıdır.

DORA Perspektifinde Backup Güvenliği

Finansal kuruluşlar açısından dijital operasyonel dayanıklılık;

backup,

recovery,

testing,

incident management

gibi kabiliyetlerin birlikte değerlendirilmesini gerektirir.

Backup’ın gerçekten restore edilebilir olması operasyonel dayanıklılığın temel unsurlarındandır.

Yönetimin Sorması Gereken Backup Güvenliği Soruları

Üst yönetimin şu soruların cevaplarını bilmesi önemlidir:

Backup’larımız şifreli mi?

Immutable kopyamız var mı?

Backup admin hesaplarında MFA var mı?

Domain Admin backup’ları silebilir mi?

Son restore testi ne zaman yapıldı?

Kritik sistemleri gerçekten ne kadar sürede geri getiriyoruz?

Ransomware sonrası hangi temiz backup’a döneceğiz?

Bu sorular kurumun gerçek backup olgunluğunu ortaya çıkarır.

Backup Güvenliği İçin Örnek Katmanlı Mimari

Kurumsal bir yapı şu şekilde olabilir:

Production Systems

↓

Backup Proxy

↓

Hardened Backup Repository

↓

Immutable Backup

↓

Offsite / Cloud Copy

↓

Air-Gapped Cyber Recovery Vault

Bu yapının yönetimi ise;

MFA,

PAM,

Separate Admin,

SIEM,

Network Segmentation

ile korunabilir.

Backup Güvenliğinde En Sık Yapılan Hatalar

Kurumlarda sık görülen hatalar şunlardır:

• backup verisini şifrelememek,
• encryption key’i backup ile aynı yerde tutmak,
• backup admin’de MFA kullanmamak,
• Domain Admin’i backup admin olarak kullanmak,
• aynı kullanıcı hesabını günlük işlerde kullanmak,
• network segmentasyonu yapmamak,
• repository’yi açık SMB share olarak tutmak,
• immutable backup kullanmamak,
• logları SIEM’e göndermemek,
• restore testi yapmamak,
• backup success mesajını yeterli görmek,
• backup server’ın kendi recovery planını oluşturmamak.

Backup Güvenlik Kontrol Listesi

Kurumlar şu kontrolleri değerlendirebilir:

• Encryption at Rest
• Encryption in Transit
• Secure Key Management
• MFA
• PAM
• Least Privilege
• RBAC
• Separate Backup Administrator
• JIT Access
• PAW
• Network Segmentation
• Firewall Allow-List
• Hardened Repository
• Immutable Backup
• Air-Gap
• SIEM Monitoring
• Audit Logging
• Restore Testing
• Integrity Verification
• Clean Room Recovery
• DR Testing

Sonuç: Backup’ın Değeri Restore Edilebildiği Gün Ortaya Çıkar

Backup güvenliği yalnızca backup yazılımı kurmak değildir.

Gerçek güvenlik;

veriyi şifrelemek,

erişimi sınırlandırmak,

administrator hesaplarını ayırmak,

MFA kullanmak,

repository’yi izole etmek,

immutable kopya oluşturmak,

logları izlemek

ve en önemlisi:

restore işlemini düzenli olarak test etmek

ile sağlanır.

Bir backup sistemi her gece başarılı şekilde job çalıştırıyor olabilir.

Ancak hiçbir zaman restore edilmemişse kurumun elindeki şey yalnızca:

bir varsayımdır.

Backup’ın gerçekten çalıştığı ancak veri geri getirildiğinde kanıtlanabilir.

Bu nedenle modern backup güvenliğinde başarı metriği:

“Kaç backup aldık?”

değil;

“Kaç backup’ı başarıyla geri getirebildik?”

olmalıdır.

Kurum ayrıca en kötü senaryoyu varsaymalıdır:

Production ortamı kaybolabilir.

Domain Admin hesabı ele geçirilebilir.

Backup administrator hesabı hedef alınabilir.

Buna rağmen kurumun elinde saldırganın silemediği, değiştiremediği, okuyamadığı ve gerçekten restore edilebilen güvenilir bir kopya kalmalıdır.

Gerçek backup güvenliği budur.