Backup Güvenliği Nedir? Tanım ve Veeam için Sekiz Kontrol

Backup güvenliği nedir?

Backup güvenliği, backup sistemlerini ve backup kopyalarını ransomware'e, silinmeye ve yetkisiz değişikliğe karşı korumak ve restore'un gerçekten çalıştığını kanıtlamaktır. Dört işi kapsar: backup health monitoring, backup altyapısının hardening'i, immutable bir kopya ve saldırı koşullarında restore testi. Threat model, admin credential'larını zaten ele geçirmiş bir saldırgandır: dışarıdan biri, kötü niyetli ya da baskı altındaki bir çalışan, ya da ele geçirilmiş bir MSP veya remote management hesabını kullanan biri.

Tanım, Microsoft 365 gibi SaaS backup'ları da dahil her backup sistemi için geçerli; aşağıdaki öneriler ise Veeam KB2680'de listelenen en yüksek sürüm olan Veeam Backup & Replication 13.1.1 (build 13.1.1.18, 2026-08-13) için yazıldı.

İlk hedef: backup'lar

Çalışan bir restore, saldırganın pazarlık gücünü elinden alır. CISA'nın #StopRansomware Guide belgesi: "Ransomware aktörleri çoğu zaman hedef ortamda saklanan credential'ları arayıp toplar ve bunlarla backup çözümlerine erişmeye çalışır; patch'lenmemiş backup çözümlerini hedeflemek için herkese açık exploit'leri de kullanır." Veeam'in 2025 anketinde saldırıya uğrayan kurumların (1.300 kurumun 900'ü) %89'unda backup repository'ler hedef alınmış; Sophos'un 2024 başındaki anketinde backup'ları ele geçirme girişimlerinin %57'si başarılı olmuş, medyan recovery maliyeti backup'lar ele geçirildiğinde 3 milyon dolar, geçirilmediğinde 375 bin dolar.

Backup yazılımının kendisi de hedef. CISA'nın KEV kataloğu (sürüm 2026.09.25), ransomware kampanyasında kullanımı "Known" olarak işaretlenmiş dört Veeam Backup & Replication zafiyeti listeliyor: CVE-2022-26500, CVE-2022-26501, backup ağı içindeki authenticate olmamış bir kullanıcının "configuration database'de saklanan encrypted credential'ları elde etmesine" izin veren CVE-2023-27532 ve authentication gerektirmeyen bir RCE zafiyeti olan CVE-2024-40711 (NVD CVSS 9,8), build 12.2.0.334'te kapatıldı (KB4649). Sophos X-Ops, ele geçirilmiş VPN cihazlarından girip bu zafiyetle "point" adında yeni bir local admin hesabı açan saldırganları belgeledi; bazı vakalar Akira, Fog ya da Frag ransomware'iyle sonuçlandı.

Sekiz kontrol

Kontroller dört gruba ayrılıyor: hardening (1 ile 3), immutable kopya (4 ve 5), monitoring (6), recovery testi (7 ve 8).

1. Identity ve access

Backup sunucusunda ya da bir proxy'de admin yetkisi alan saldırgan "production verisinin, backup'ların ve replica'ların çoğunu silebilir" (Veeam security guidance).

• Backup identity'sini production'dan ayırın. Veeam büyük ortamlar için "ayrı bir Active Directory forest'ında bir management domain'i" öneriyor; orta ve küçük ölçekli ortamlar ayrı bir workgroup kullanabilir. CVSS puanı 9,9 olan CVE-2025-23120 (KB4724), "authenticate olmuş bir domain kullanıcısının" RCE yapmasına izin veriyordu ve "yalnızca domain'e üye backup sunucularını etkiliyor".
• MFA'yı açın, önce service account'ları ayırın. MFA; REST API, Enterprise Manager'ın backup sunucusuna bağlantısı, Veeam ONE agent ve Veeam Backup Validator'ın non-interactive bağlantılarını kapsamıyor, PowerShell'i ise hiç kapsamıyor. MFA'yı açmadan önce bu araçların kullandığı hesapları service account olarak işaretleyin; bu, o hesaplarda MFA'yı kapatır. Yoksa bu bağlantılar kopar, configuration database restore'u da başarısız olur, çünkü Veeam bu restore'un MFA'sı kapalı bir service account ile çalıştırılmasını istiyor. MFA'dan muaf hesapları kısıtlayın ve izleyin.
• Four-eyes authorization'ı açın. v13'te ikinci bir Backup Administrator ya da Security Administrator onayı gerektiren işlemler arasında backup silme, repository kaldırma, user ve user group değişiklikleri, MFA ve automatic logoff değişiklikleri, Linux ya da hardened repository'de immutability'yi kapatma ya da süresini kısaltma ve four-eyes'ı kapatma var. Özellik açıkken PowerShell, REST API ve Enterprise Manager üzerinden delete işlemleri tamamen engellenir; MFA'dan muaf hesaplar da bu kapsama girer. v12'de immutability değişiklikleri bu listede yok.

Not: MFA yalnızca tek tek user hesaplarında açılabiliyor, user group'larda değil. Remote console ve web UI girişlerini koruyor, OS logon'larını korumuyor; onlar için ayrı bir kontrol gerekiyor. Enterprise Manager'ın kendi login'inde MFA için bir SAML identity provider gerekiyor. MFA'yı yalnızca Backup Administrator'lar yönetebildiği için en az iki kişiyi enroll edilmiş tutun. Four-eyes approver yetkisi bir user group üzerinden verilebiliyor; o grubu Active Directory'de düzenleyebilen herkes kendini approver yapabilir. KB4649, build 12.2.0.334'ten önce düşük yetkili bir Veeam kullanıcısının "MFA ayarlarını değiştirip MFA'yı bypass etmesine" izin veren CVE-2024-40713'ü listeliyor.

Checklist: Backup sunucusu production Active Directory domain'inin dışında (ayrı forest ya da workgroup); MFA, group üzerinden değil tek tek her Veeam user hesabında ve backup sunucusuyla repository'lere yapılan OS ve remote logon'larda zorunlu, MFA'dan muaf her service account biliniyor ve kısıtlı; four-eyes authorization açık, approver'lar farklı kişiler ve hiçbir production domain admin'inin kendini ekleyemeyeceği bireysel hesaplar.

2. Hardening ve patching

• Patch'leri yalnızca KEV'e göre değil, Veeam'in security bulletin'lerine göre geçin. CVE-2025-23120 yukarıdaki KEV kayıtları arasında yok.
• İnternetten gelen inbound bağlantıyı kapatın. Veeam'in hardening guidance'ı: "İnternetten backup sunucularına gelen inbound bağlantıya izin verilmemeli."
• Backup ağını içeriden de segment edin. CVE-2023-27532 için credential gerekmiyordu, backup ağının içinde bir foothold yetiyordu. İngiltere NCSC'nin on-prem ilkeleri "backup çözümünüzü izole edebilir hâle getirin" ilkesiyle başlıyor.
• Security & Compliance Analyzer'ı çalıştırın (12.x'te de mevcut); Veeam bunu düzenli olarak, "özellikle önemli değişikliklerden sonra" çalıştırmanızı öneriyor.
• Hardened repository eklerken single-use credential kullanın. Hardened repository bu durumda kayıtlı bir parola tutmaz: "Veeam Backup & Replication sunucusu ele geçirilse bile saldırgan credential'ları alıp hardened repository'ye bağlanamaz."
• DISA STIG ve FIPS compliance için Veeam appliance'larını kullanın. Veeam bu amaçla hazır yapılandırılmış Rocky Linux build'lerini, Veeam Software Appliance ve Veeam Infrastructure Appliance'ı öneriyor. Kurduysanız ilk configuration'da Security Officer hesabını oluşturun.

Not: Analyzer listesini tek seferde temizlemeye kalkmayın. Bazı maddeler remote erişimi kapatıyor: Windows'ta Remote Desktop Services ve WinRM'nin kapatılması, hardened repository'lerde SSH sunucusunun kapatılması. Önce console ya da out-of-band erişimi hazırlayın ve bu servislere hangi script ve araçların bağlı olduğunu kontrol edin.

Checklist: Backup sunucusu desteklenen bir build'de ve yalnızca KEV'dekiler değil, Veeam'in tüm security fix'leri uygulanmış; Analyzer son önemli değişiklikten sonra çalışmış, Passed olmayan her madde ya düzeltilmiş ya da bilinçli olarak exclude edilmiş, remote erişimi kapatan bir değişiklikten önce out-of-band erişim hazır.

3. Encryption ve key management

Encryption çalınan bir kopyayı korur ama bir kopyayı kaybetmenin yeni bir yolunu da açar: parola kaybolursa ya da KMS çökerse, encryption sürecinde Enterprise Manager key'lerini kullanmadıysanız "backup'lardan veya tape'lerden veri kurtaramazsınız" (Veeam encryption dokümanı).

• Password loss protection'ı açın ve Enterprise Manager'ı "key change saldırısı riskini azaltmak için" backup sunucusundan farklı bir makineye kurun (hardening guidance).
• Configuration backup'ları encrypt edin ve repository'lerini backup sunucusunun ağının dışında tutun. Configuration database, hypervisor'lar, host'lar ve diğer altyapı için credential'ları tutuyor; bunlar encrypted, "ancak backup sunucusunda admin yetkisi olan bir kullanıcı parolaları çözebilir ve bu potansiyel bir tehdittir" (hardening guidance). Encrypted olmayan bir configuration backup'ta secret'lar yer almıyor: "Credential'lar, encryption key'leri ve sertifikalar configuration backup'ta saklanmaz."
• Configuration backup'lar hardened, object storage, HPE StoreOnce ve Dell Data Domain repository'lerinde immutable yapılabiliyor.
• Configuration backup parolasını backup sunucusuna bağlı olmayan bir yerde saklayın. Kaybedilen bir backup sunucusunu credential'ları ve key'leriyle yeniden kurmanın yolu encrypted configuration backup.

Checklist: Encrypted bir configuration backup, asıl backup sunucusu olmadan temiz bir sunucuya restore edilmiş ve bir backup'ın encryption'ı çözülmüş.

4. Immutability ve izolasyon

Hardened repository'de immutability süresi içindeki dosyalar "taşınamaz, değiştirilemez ya da silinemez, ama kopyalanabilir". Object storage'daki karşılığı Object Lock. CISA "ransomware saldırılarında sık hedeflenen storage kaynaklarında delete protection'ı ya da object lock'u" öneriyor ve cloud sağlayıcılarının immutable storage teklifleri için bir uyarı ekliyor: "Immutable storage'ı dikkatli kullanın; bazı regülasyonların compliance kriterlerini karşılamaz ve yanlış configuration ciddi maliyet doğurabilir."

• Object Lock retention modunu kontrol edin. Amazon S3'te s3:BypassGovernanceRetention yetkisi olan herkes governance modunda lock'lanmış nesneleri silebilir, S3 console da bypass header'ını varsayılan olarak gönderir. Governance modu, ancak saldırganın ulaşabileceği hiçbir credential'da bu yetki yoksa koruma sağlar.
• Retention ayarlarını governance modunda test edin, compliance modunu önce kısa retention'lı, disposable bir bucket'ta deneyin. Compliance modu retention tarihi geçmeden geri alınamaz; AWS'ye göre böyle bir nesneyi erken silmenin tek yolu hesabı silmek.
• Storage'ın sahibi olan hesabı izole edin. Bu hesaba ulaşan saldırgan governance lock'larını bypass edebilir, erişimi engelleyebilir ya da hesabın kendisini silebilir. NCSC, bir backup sisteminin "saldırganın müşterinin tüm erişimini engelleyemeyeceği" şekilde yapılandırılmasını istiyor; hesabın tamamen silinmesi de buna dahil.

Checklist: En az bir kopya immutable, lock yalnızca console'da değil storage'ın kendisinde doğrulanmış ve retention modu biliniyor.

5. Kopyalar ve media

Veeam'in hardening guidance'ı 3-2-1 kuralına uymayı ve "backup dosyalarını sanal storage'ın yanında offline media'da da tutmayı" söylüyor; 3-2-1-1-0 kuralı buna immutable ya da air-gapped bir kopya ekliyor. Her kopya için onu kimin silebileceğini belirleyin ve en az birini backup admin'inin credential'ları ele geçirilse bile ayakta kalacak şekilde tutun.

Checklist: Offline bir kopya var ve backup admin'inin kendi credential'larının silemeyeceği bir kopya var.

6. Monitoring ve drift detection

Job sonuçları health'i gösterir; backup güvenliği bir de change signal ister: backup sunucusunun OS'inde açılan yeni admin hesapları, yeni Veeam user'ları ya da rolleri, kapatılan MFA ya da four-eyes, düzenlenen repository ayarları, kısaltılan immutability, silinen job'lar.

• Yalnızca Veeam'i değil, OS'i de izleyin. "point" hesabı local bir Windows hesabıydı ve Veeam'in kendi event'leri onu hiç görmez; Windows Security log'unda 4720 numaralı event ("A user account was created") olarak görünür.
• Alert'i severity'ye göre değil, event ID'ye göre kurun. "Warning ve üstü" diye kurulan bir kural Info seviyesindeki 42401, 40201, 31200 ve 28100'ü kaçırır.
• Event'leri backup sunucusunun dışına forward edin. Windows üzerindeki bir backup sunucusunda Veeam security event'lerini Windows Event Log'a yazar ve bir syslog sunucusuna forward edebilir.

Not: 42401 (Four-Eyes Authorization Disabled), 40201 (Multi-Factor Authentication Disabled, tüm kullanıcılar için), 31200 (User or Group Added) ve 28100 (Backup Repository Settings Updated) Severity: Info; 23090 (Job Deleted) ise Warning. Four-eyes'ı kapatmak ikinci bir onay gerektirdiği için daha erken sinyal, "Disable four-eyes authorization" işlemini taşıyan Info seviyesindeki 42402 (Four-Eyes Authorization Request Created) event'idir; aynı event ID diğer bütün onay isteklerinde de gönderilir.

Checklist: 42401, 40201, 31200 ve 28100 gibi Info seviyesindeki security event'leri backup sunucusunun dışında, birinin ilgilendiği bir alert üretiyor.

7. Restore testi

Başarılı bir job, restore point'in boot ettiğini ya da uygulamalarının çalıştığını göstermez. NIST CSF 2.0 aynı noktayı bir recovery outcome'ı olarak koyuyor: backup integrity'si "restore için kullanılmadan önce" doğrulanmalı (RC.RP-03). Restore'un ne kadar sürede bitmesi gerektiği ise bir RTO sorusu; bunu RTO ve RPO rehberimizde örnekle hesaplıyoruz.

• Recoverability'yi SureBackup ile doğrulayın. v13'te de 12.x'te de iki modu var. Full recoverability testing, makineleri izole bir virtual lab'da doğrudan backup'tan boot edip heartbeat, ping ve uygulama testleri koşuyor; "Backup verification and content scan only" ise lab gerektirmeden integrity'yi kontrol edebiliyor ve içeriği malware'e karşı tarayabiliyor.
• Şüpheli restore point'leri recovery'den önce değerlendirin. Malware detection buna Secure Restore ve scan backup seçeneklerini ekliyor. Ele geçirilmiş bir sistemin lock'lu kopyası, restore edildiğinde saldırıyı da geri getirir.

Checklist: İzole ortamda backup'tan en son ne zaman makine boot edildiği biliniyor.

8. Adversarial test

Restore testi saldırganın gittiğini varsayar. Veeam uygulama içi kontrollerin sınırını kendisi kabul ediyor: "Veeam Backup & Replication sunucusu ele geçirilirse four-eyes authorization backup altyapısını koruyamaz."

• Saldırganın konumundan test edin: toplanan bir credential'ın repository'ye ulaşıp ulaşmadığını, immutability'nin kısaltılıp kısaltılamadığını, four-eyes'ın devreye girip girmediğini ve birine alert gidip gitmediğini.
• Testi bir lab'da ya da kısa retention'lı, disposable bir test job'ı, test repository'si ya da test bucket'ı üzerinde, yazılı yetkiyle yapın.

Not: Tek immutable kopya üzerinde asla test yapmayın, production'daki bir backup sunucusuna karşı asla exploit kodu çalıştırmayın. Production kopyaları üzerinde test yapmak restore point'leri yok edebilir; uzun compliance retention'lı bir test bucket'ı da retention bitene kadar ücret yazmaya devam eder.

Checklist: Birinin saldırgan rolünü üstlendiği son testin tarihi biliniyor.

Standartlar

NIST CSF 2.0'da Protect fonksiyonunda doğrudan backup'lar için yazılmış tek outcome PR.DS-11: "Verinin backup'ları oluşturulur, korunur, sürdürülür ve test edilir." ISO/IEC 27001:2022 Annex A bunu A.8.13 Information backup kontrolünde ele alıyor. İngiltere NCSC, cloud ve on-prem backup'lar için ayrı ilkeler yayımlıyor; ikisi de key management'ı ve önemli bir değişiklik yapıldığında ya da privileged bir işlem denendiğinde alert üretmeyi ayrı birer ilke yapıyor. Sekiz kontrolün bu framework'lerle eşleşmesi bizim yorumumuz, resmî bir crosswalk değil.

Limitler

• Anket rakamları yön gösterir: vendor'ların yaptırdığı, beyana dayalı anketler. Veeam %89'un tabanını belirtmiyor, bu oran ancak saldırıya uğrayan 900 kuruma ait olabilir; Sophos'un %57'si girişimlerin oranı, 2024 başına ait ve Sophos bu soruyu o tarihten beri yeniden sormadı.
• Retention, dwell time'a karşı bir yarış. Lock, temiz bir restore point'i ancak o point compromise'dan önce yazıldıysa korur, o da lock'un süresi dolana kadar. Job'ları sessizce durduran ya da retention'ı kısaltıp bekleyen bir saldırgan her lock'u atlatabilir; bu açığı 6. kontroldeki change alert'leri kapatır.
• Backup uygulamasının içindeki kontroller backup sunucusuyla birlikte düşer. Sunucu kaybedildikten sonra ayakta kalan kontroller başka bir yerde uygulananlardır: repository, storage, ayrı bir identity. Immutability de availability'yi korur, confidentiality'yi değil: Sophos'un 2026 anketinde saldırıların %16'sında veri hem şifrelenmiş hem çalınmış.
• Kapsam. v12 (12.3.2) yalnızca four-eyes, Analyzer ve SureBackup için kontrol edildi, gerisini v12 dokümanıyla karşılaştırın; Linux tabanlı Veeam Software Appliance'ın aynı event ID'lerini syslog'a gönderip göndermediği doğrulanmadı. ISO/IEC 27001 kontrol numarası ve başlığı, ücretli olan standardın kendisiyle karşılaştırılmadı; bir zafiyetin KEV'de olmaması güvenli olduğu anlamına gelmez.

Daha geniş, puanlı bir soru seti için ücretsiz Backup Security Assessment yedi alanda 28 soru soruyor, ransomware maliyet hesaplayıcısı da başarısız bir restore'un maliyetini rakama döküyor. Ransomware'e özel tasarım için ransomware'e dayanıklı backup'lar yazımıza bakın.

BackupSec bu işe nasıl yaklaşıyor

ZeroMON, Veeam Backup & Replication'ı REST API üzerinden okuyan ve ona hiçbir şey yazmayan, on-prem çalışan bir client. Read-only bir Veeam hesabıyla çalışır; bu hesaba Backup Administrator rolü verilirse birkaç ek alan da görünür (configuration backup durumu, general options, lisans bilgileri). Her entegrasyon hesabı gibi MFA'dan muaf, bu yüzden onu da kısıtlayın ve izleyin. ZeroMON job health'ini, configuration değişikliklerini, Veeam'in raporladığı immutability durumunu ve backup sunucusunun build ve patch seviyesini takip eder; alert'ler e-posta ve uygulama içi bildirimle gelir. Storage'daki lock'ları doğrulamaz, restore testi çalıştırmaz. ZeroTAM, mimari ve hardening üzerine danışmanlık. ZeroPEN adversarial test: Veeam'e yönelik, MITRE ATT&CK'e eşlenmiş, kill-chain yaklaşımlı ve non-destructive bir pentest. ZeroVault, off-site kopya için Veeam'e yönelik Object Lock destekli, managed S3 uyumlu object storage. Stork365 ise Microsoft 365 backup ve restore'u bring-your-own-storage modeliyle karşılıyor.

Beş katmanın nasıl birlikte çalıştığını görün →