Fidye yazılımı yedekleri neden güvenlik ağı değil, doğrudan hedef haline getiriyor
Yıllar boyunca yedekleme, fidye yazılımını atlatılabilir kılan istisnaydı: üretim ortamı şifrelenir, yedekten restore edilir, yola devam edilirdi. Saldırganlar bu açığı kapattı. Veeam'in 2025 Ransomware Trends raporu 1.300 kuruluşla yapıldı; bunların 900'ü son 12 ayda en az bir fidye yazılımı saldırısı yaşamıştı. Veeam'in aktardığına göre kuruluşların %89'unda backup repository'leri saldırganın hedefi oldu ve repository'lerin ortalama %34'ü değiştirildi ya da silindi. Kurbanın geri dönüş yolunu yok etmek veya bozmak, fidye notu gelmeden önce elindeki pazarlık gücünü ortadan kaldırıyor.
Bunun sonucu kurtarma rakamlarında görülüyor. Sophos'un State of Ransomware 2025 raporu, son bir yılda fidye yazılımından etkilenen kuruluşlardaki 3.400 BT ve güvenlik yöneticisiyle yapıldı. Verisi şifrelenen kuruluşlar arasında veriyi yedekten restore edenlerin oranı yalnızca %54 oldu; bu, Sophos'un altı yıldır yürüttüğü anketteki en düşük oran. Sonunda saldırganın ilk talebinden fazlasını ödeyen 151 kuruluşun %38'i yedeklerinin başarısız olduğunu ya da düzgün çalışmadığını söyledi (katılımcılar genellikle iki neden gösterdi). Kâğıt üzerinde var olan bir yedek, baskı altında sorunsuz restore edilen bir yedekle aynı şey değil.
"Yedeklerimiz var" ile "fidye yazılımına dayanıklı yedeklerimiz var" arasındaki fark üç temel unsura dayanıyor: immutability, izolasyon ve test edilmiş kurtarma. Bunlar istediğiniz gibi seçip birleştirebileceğiniz bağımsız kontroller değil. Birini atlarsanız diğer ikisi eksiği kapatmaz. Saldırganın erişemediği immutable bir yedek, ancak gerçekten restore edilebiliyorsa işe yarar; iyi test edilmiş bir kurtarma planı da dayandığı yedek tatbikattan önce silinmişse hiçbir değer taşımaz. Bu üç unsur, identity'den monitoring'e uzanan daha geniş bir kontrol setinin parçası; bunu Backup güvenliği nedir? yazımızda anlatıyoruz.
Üç temel unsur, ayrıntılarıyla
1. Immutability: Saldırganın dokunamayacağı yedekler
Immutability, bir yedeğin retention süresi boyunca değiştirilememesi ve silinememesi demek: ne yanlış yapılandırılmış bir retention betiği, ne ele geçirilmiş bir yönetici hesabı, ne de domain admin kimlik bilgilerini zaten ele geçirmiş bir saldırgan bunu yapabilmeli. Uygulamada bu; object storage üzerinde Object Lock, Write Once Read Many (WORM) donanımı ya da retention'ın yedekleme uygulamasının kendi erişim kontrollerinden bağımsız olarak depolama katmanında uygulandığı bir hardened Linux repository ile sağlanıyor.
Bu ayrım önemli, çünkü fidye yazılımı operatörleri çaldıkları kimlik bilgileriyle erişebilecekleri yedekleri özellikle arıyor. CISA'nın #StopRansomware Guide belgesi bunu açıkça söylüyor: "Ransomware actors often hunt for and collect credentials stored in the targeted environment and use those credentials to attempt to access backup solutions." Yedekleme yazılımınızı yöneten hesap geçen ayın restore point'lerini de silebiliyorsa, immutability aslında yerinde değil. Yeterli yetkiye sahip bir saldırganın dakikalar içinde kapatabileceği bir ayardan ibaret.
CISA'nın yedekleme tavsiyesi, kritik verilerin çevrimdışı ve şifreli yedeklerini tutmak ve bu yedeklerin erişilebilirliğini ve bütünlüğünü bir felaket kurtarma senaryosunda düzenli olarak test etmek. Aynı rehber, tek başına immutable bulut depolamaya karşı temkinli: "Use immutable storage with caution as it does not meet compliance criteria for certain regulations and misconfiguration can impose significant cost." Immutability güçlü bir kontrol, ama çevrimdışı bir kopyanın ya da test edilmiş bir restore'un yerini tutmuyor.
2. İzolasyon: Ayrı bir kimlik düzlemi ve saldırganın hiç ulaşamayacağı bir kopya
Immutability bir yedeği değiştirilmekten korur. İzolasyon ise ona hiç ulaşılamamasını sağlar. İkisi birbirinin yerine geçmez, birbirini tamamlar; yalnızca birini uygulayan kurumlar bu açığı genellikle bir tasarım incelemesinde değil, gerçek bir olay sırasında fark ediyor.
İzolasyonun iki bileşeni var. Birincisi ayrı bir kimlik düzlemi: yedekleme altyapısı üretimle aynı Active Directory domain'ine, aynı yönetici kimlik bilgilerine ya da aynı düz (flat) ağ segmentine güvenmemeli. Ele geçirilmiş bir domain controller otomatik olarak ele geçirilmiş bir yedekleme ortamı anlamına gelmemeli; geliyorsa saldırganın iki şeyi değil, tek bir şeyi ele geçirmesi yetmiş demektir. İkincisi gerçek anlamda çevrimdışı veya air-gapped bir kopya: kritik verinin, üretimden hiçbir kalıcı ağ yolu olmayan en az bir kopyası. Bu; çevrimdışı tape rotasyonu, yalnızca veri almak için kısa süreliğine çevrimiçi olan bağlantısız bir replikasyon hedefi ya da üretim ortamından erişilebilecek hiçbir yerde kalıcı kimlik bilgisi saklanmayan bir bulut katmanı olabilir.
Veeam'in 2025 raporuna göre veri dayanıklılığına öncelik veren kuruluşlar saldırılardan yedi kata kadar daha hızlı kurtulabiliyor ve belirgin biçimde daha az veri kaybediyor. Veeam bunu yalnızca izolasyona değil, bir bütün olarak veri dayanıklılığına (yedekleme ve kurtarma, proaktif güvenlik, olay müdahalesi) bağlıyor. Yine de izolasyon bu tablonun büyük bir parçası: kurtarma noktanıza ulaşmak için gerçekten ek çaba harcaması gereken bir saldırgan ile az önce ele geçirdiği sistemlerle aynı kimlik düzlemini paylaştığı için o noktaya zaten açık bir oturumu olan bir saldırgan arasındaki farkı izolasyon belirliyor.
3. Test edilmiş kurtarma: İhtiyaç duymadan önce restore edilebilirliği kanıtlamak
Üç unsurun en az göz alıcı olanı, yarım bırakılması da en kolay olanı. Veeam'in 2025 raporunda katılımcıların %98'inin bir fidye yazılımı playbook'u vardı, ama yalnızca %44'ü bu playbook'a yedek doğrulamalarını ve sıklıklarını dahil etmişti. Veeam'in 2023'te en az bir saldırıya uğrayan 1.200 kuruluşa dayanan 2024 Ransomware Trends raporu ise kuruluşların %63'ünün kurtarma sırasında enfeksiyonu yeniden içeri alma riski taşıdığını buldu: hızlı restore baskısı altındaki ekipler, verinin karantinada yeniden taranması gibi adımları atlıyor.
Test edilmemiş restore'lar, en çok önem taşıdıkları ana kadar görünmeyen şekillerde başarısız olur: bozuk backup zincirleri, eksik application-consistency bağımlılıkları, aylar önce süresi dolmuş servis hesabı kimlik bilgileri ya da artık var olmayan bir altyapı topolojisi için yazılmış runbook'lar. Bütünlük ve zararlı yazılım taramasını atlamanın riski kesintiden daha ağır: kesintiye yol açan zararlı yükün (payload) kendisini geri yüklemek.
Gerçek bir test edilmiş kurtarma programı, yalnızca "backup job başarılı" bildirimleri değil, izole bir kurtarma ortamına planlı ve tam kapsamlı restore tatbikatları demek. Bu tatbikatları, sunumda güven verici görünen rakamlara göre değil, işin gerçekten ihtiyaç duyduğu RTO'lara göre ölçün. Bu hedefleri BIA'dan nasıl belirleyeceğinizi ve gerçek bir restore ile nasıl test edeceğinizi RTO ve RPO rehberimizde anlatıyoruz.
Kurtarma rakamları aslında ne söylüyor
Sophos'un 2025 verileri ilk bakışta içinizi rahatlatan bir manşet sunuyor: verisi şifrelenen kuruluşların %97'si veriyi geri alabildi. Dağılım ise o kadar rahatlatıcı değil. Yalnızca yarıdan biraz fazlası (%54) yedekten restore etti, %49'u fidyeyi ödeyip verisini geri aldı, %29'u başka yollara başvurdu; birçoğu birden fazla yol kullandı. Veriyi geri almak ile onu kendi yedeklerinizden geri almak farklı sonuçlar. Zayıf unsurlar tam bu aradaki mesafede ortaya çıkıyor: yanlış bir rolün geçersiz kılabileceği bir retention kilidi, hâlâ aynı domain'e güvenen "ayrı" bir yedekleme ağı ya da hiç uçtan uca prova edilmemiş bir restore.
Bunu yanlış yapmanın bedeli
Bu üç unsur soyut bir en iyi uygulamalar listesi değil; bir fidye yazılımı olayının ne kadara mal olduğuna ve ne kadar sürdüğüne doğrudan yansıyor. Sophos'un 2025 raporuna göre ödenen fidye hariç, bir fidye yazılımı saldırısından kurtulmanın ortalama maliyeti 1,53 milyon dolar; 2024'te bu rakam 2,73 milyon dolardı. Kurbanların %53'ü bir hafta içinde tamamen toparlandı, bir önceki yıl bu oran %35'ti. Geri kalanı yedi günden uzun süre bir tür aksaklık içinde kaldı; kesinti, üretkenlik kaybı ve olay müdahalesi (incident response) iş gücü her gün birikti.
Yedekleme duruşu (backup posture), bu denklemde bir kuruluşun tamamen kontrol edebildiği az sayıdaki değişkenden biri. Bir saldırganın backup repository'nize yönelik ilk hamlesinin başarılı olup olmayacağı, olay sırasında değil, büyük ölçüde aylar önce verilen kararlarla belirleniyor. Bir tehdit aktörü domain admin kimlik bilgilerini ele geçirip yedekleme platformunuzu yoklamaya başladığında immutability, izolasyon ve test edilmiş kurtarma ya zaten yerindedir ya da değildir; bunları baskı altında sonradan eklemenin yolu yok.
Üçünü de sessizce baltalayan yaygın hatalar
Olay sonrası incelemelerde birkaç kalıp tekrar tekrar karşımıza çıkıyor:
- Snapshot'ları yedek sanmak. Bir VMware snapshot'ı, orijinal sanal diskin değişiklik kaydıdır; bağımsız bir kopya değildir. Broadcom'un snapshot en iyi uygulamalar makalesi bunu açıkça söylüyor: "Do not use VMware snapshots as backups." Snapshot dosyası tutulduğu sürece büyümeye devam eder, datastore'u doldurabilir ve performansı düşürür; base disk'ler kaybolursa da Broadcom'un ifadesiyle "the snapshot files alone are not sufficient to restore a virtual machine." Snapshot'lar kısa ömürlü geri alma (rollback) için kullanışlı bir özellik (Broadcom tek bir snapshot'ı 72 saatten uzun tutmamayı öneriyor), bir kurtarma stratejisi değil.
- "Immutable" ifadesini doğrulanmış bir özellik yerine işaretlenecek bir kutu olarak görmek. Object Lock ve retention politikaları yalnızca bir yapılandırma kılavuzunda belgelenmekle kalmamalı, yedekleme platformunu yöneten rolün tam olarak kendisine karşı test edilmeli.
- Aynı kimlik alanındaki (identity domain) ikinci bir kopyayı "izole" saymak. Üretimde ele geçirilen kimlik bilgileri backup repository'sinde de oturum açabiliyorsa, coğrafi veya platform ayrımı gerçek bir izolasyon sağlamaz.
- Başarıyı restore doğrulamasıyla değil, backup job'un tamamlanmasıyla ölçmek. Dün geceki job'un yanındaki yeşil onay işareti, verinin bir yere yazıldığını söyler. Bu verinin geri alınabilir, uygulama açısından tutarlı ve restore'u gerektiren zararlı yazılımdan arınmış olduğunu göstermez.
BackupSec Devreye Girdiğinde
BackupSec yedekleme platformunuzun yerini almıyor. Üç hizmetimiz yukarıdaki unsurlarla doğrudan örtüşüyor:
- ZeroMON, Veeam Backup & Replication için bir izleme platformu. Şirket içinde (on-premises) OVA olarak çalışır, read-only bir hesapla bağlanır ve BackupSec'e ya da herhangi bir üçüncü tarafa hiçbir veri göndermez. Job sağlığını izler, yapılandırma değişikliklerini Forensic & Audit modülünde kaydeder (kim, neyi, ne zaman değiştirdi), Security Analyzer kontrol listesini çalıştırır, rapor üretir ve e-posta ile uygulama içi bildirim üzerinden uyarır. Her repository'nin immutability durumunu Veeam'in kendi repository ayarlarının bildirdiği şekilde gösterir ve bu ayar değiştiğinde işaretler. Veeam'in yapılandırmasını okur; depolama tarafında nesne düzeyindeki kilitleri doğrulamaz.
- ZeroTAM yazılım değil, size atanmış bir backup güvenliği danışmanı: mimari ve izolasyon tasarımı, kapasite planlaması, fidye yazılımı kurtarma planlaması ve kriz anında öncelikli destek.
- ZeroPEN, Veeam Backup & Replication, Veeam ONE ve Enterprise Manager için tehdit odaklı bir sızma testi. MITRE ATT&CK ile eşlenmiş bir fidye yazılımı kill chain'ini sekiz aşamada simüle eder: initial access, keşif ve envanter, credential kötüye kullanımı, Veeam sunucusunun ele geçirilmesi, repository erişimi, backup neutralization, veri sızdırma simülasyonu ve şifreleme kabiliyetinin kanıtı. Gerçek yedekleri asla silmez, gerçek şifreleme yapmaz, üretim ya da yedekleme servislerini durdurmaz. Denetime hazır kanıt alırsınız, kritik bulgular yeniden test edilir. Çalışma, restore bütünlüğü ve immutability doğrulamasını da içerir. Yine de belirli bir andaki durumu ölçen bir testtir; 3. unsurdaki düzenli restore tatbikatlarının yapılması gerekmeye devam eder.
Yedekleme güvenliği duruşunuz hakkında BackupSec ile görüşün →
Kendi yedeklerinizin baskı altında nasıl dayanacağını görmek ister misiniz? Ücretsiz Backup Security Assessment, backup stratejisinden erişim kontrolüne ve restore testine kadar yedi alanda 28 soru soruyor.