Bugünkü fidye saldırılarının temel amacı veriyi yalnızca görmek değildir. Saldırgan, kurumun dosya ve veritabanlarını şifreleyerek operasyonu durdurur; erişimi geri verme vaadi üzerinden ödeme baskısı kurar. Türkiye'de genel bir ad gibi kullanılan CryptoLocker, aslında belirli bir zararlı yazılım ailesinin adıdır. Güncel tehdit ailesinin doğru üst adı fidye yazılımı veya ransomware'dir.
Şifreleme tehdidin merkezinde olsa da veri hırsızlığı ortadan kalkmış değildir. Birçok saldırgan önce veriyi dışarı çıkarır, ardından sistemleri şifreler ve ödeme yapılmazsa veriyi yayımlamakla tehdit eder. CISA bu yöntemi çifte şantaj modeli olarak tanımlar. Bazı gruplar ise şifreleme yapmadan yalnız veri yayımlama tehdidiyle para ister. Kurum bu nedenle hizmet kesintisi, veri bütünlüğü şüphesi, gizlilik ihlali ve fidye baskısını aynı olayın parçaları olarak yönetmelidir.
Yedekleme veri sızıntısını önlemez; ancak saldırganın kurumun çalışma kapasitesini de rehin almasını engelleyen temel kurtarma kontrolüdür.
Ransomware ve kripto kilitleme saldırılarının güncel görünümü
2026 tarihli çalışmalar, kripto kilitleme tehdidinin münferit bir teknik sorun değil, yaygın bir iş sürekliliği riski olduğunu gösteriyor:
Bu araştırmalar farklı örneklem ve yöntemler kullanır; yüzdeleri tek bir küresel oran gibi toplamak doğru değildir. Birlikte gösterdikleri sonuç açıktır: saldırıyı şifreleme başlamadan durdurmak birinci hedeftir; saldırgan ağ içinde ilerlediğinde ise üretim ortamından bağımsız ve geri yüklemesi sınanmış yedek, ödeme baskısını azaltan temel savunmadır.
Yedeklemenin yapabildiği ve yapamadığı işler
Sızdırılan bir dosyanın yedeği, yetkisiz kişinin elindeki kopyayı ortadan kaldırmaz. Bildirim, hukuki değerlendirme, erişim anahtarlarının değiştirilmesi, etkilenen kişilerin korunması ve olayın kaynağının belirlenmesi ayrı süreçlerdir. Bu nedenle “yedek var, sorun yok” yaklaşımı yanlıştır.
Yedeklemenin değeri erişilebilirlik ve veri bütünlüğü tarafında ortaya çıkar. Etkilenen sistemler ağdan ayrıldığında kurum kritik veriyi güvenilir bir tarihe döndürebilir, bozulmuş kayıtları karşılaştırabilir ve temiz altyapıda hizmeti yeniden kurabilir. Bu kapasite, fidye ödemeden operasyonu sürdürme kararını güçlendirir. NIST de yedekleme ve geri yükleme stratejisinin planlanmasını, uygulanmasını ve düzenli olarak test edilmesini olay kurtarmanın temel unsurları arasında gösterir.
ForceBT yaklaşımı: Yedeği yalnız kopyalama işi olarak değil, olay sonrası doğrulanmış hizmete dönüş zinciri olarak tasarlıyoruz. Uygulama, veritabanı, dosya alanı, yapılandırma, şifreleme anahtarı, erişim yetkisi ve geri yükleme sırası aynı kurtarma planında ele alınıyor.
Güvenli yedekleme mimarisinin temel kontrolleri
1. Üretim ortamından bağımsız kopya
Üretim sistemiyle aynı hesap, aynı yönetim ağı ve aynı erişim anahtarını kullanan yedek saldırgana karşı bağımsız değildir. Saldırgan yönetici hesabını ele geçirdiğinde üretim verisiyle birlikte yedekleri de silebilir. En az bir kopya çevrimdışı veya üretim kimliğinden ayrı, doğrudan değiştirilemeyen bir depoda tutulmalıdır.
2. Değişmezlik ve silme koruması
Nesne kilidi, saklama politikası veya benzeri değişmezlik kontrolleri belirli süre boyunca yedeklerin silinmesini ve üzerine yazılmasını engeller. Bu kontrol yalnız fidye yazılımına karşı değil, yetkili hesabın kötüye kullanılması veya insan hatası sonucunda oluşan toplu silmelere karşı da önemlidir. Saklama süresi iş ihtiyacı, mevzuat ve kurtarma senaryosuyla birlikte belirlenmelidir.
3. Şifreleme ve ayrı anahtar yönetimi
Yedek ortamı kurumun en yoğun veri kümelerinden birini taşır; bu nedenle kendisi de önemli bir sızıntı hedefidir. Aktarım ve depolama sırasında şifreleme uygulanmalı, anahtar erişimi yedekleme işletiminden ayrılmalı ve yetkiler en az ayrıcalık ilkesiyle sınırlandırılmalıdır. Şifreleme anahtarı kaybedildiğinde yedek kullanılamaz; anahtar kurtarma yöntemi de tatbikat kapsamına alınmalıdır.
4. Sürüm ve zaman çeşitliliği
Saldırgan sistemde haftalarca fark edilmeden kalmış olabilir. Yalnız son kopyayı saklamak, zararlı veya değiştirilmiş verinin yedeğe taşınması halinde yeterli olmaz. Günlük, haftalık ve dönemsel kopyalar; olayın başlangıç zamanına göre güvenilir bir geri dönüş noktası seçilmesini sağlar. Kurtarma noktası seçilirken veri kaybı ile güvenilirlik arasındaki denge kayıt altına alınmalıdır.
5. Düzenli geri yükleme testi
Başarılı yedekleme kaydı, başarılı kurtarma anlamına gelmez. Dosyanın okunması, veritabanının açılması, uygulamanın doğru sürümle çalışması ve kullanıcı yetkilerinin beklenen biçimde uygulanması gerekir. Geri yükleme testi RTO ve RPO hedeflerini gerçek sürelerle karşılaştırmalı; eksik bağımlılıkları ve dokümantasyon hatalarını olay yaşanmadan göstermelidir.
Veri sızıntısından sonra yedek nasıl kullanılmalıdır?
Olay anında en yeni yedeği doğrudan üretime döndürmek doğru değildir. Önce saldırganın ilk erişim zamanı, kullanılan hesaplar, değiştirilen dosyalar ve etkilenen sistemler belirlenir. İlgili kayıtlar ve delil niteliğindeki kopyalar korunur. Kurtarma için seçilen yedek, üretimden ayrılmış bir alanda zararlı yazılım ve bütünlük kontrollerinden geçirilir.
Yeni ortam güvenli yapılandırmayla hazırlanır; yönetici parolaları, servis hesapları, API anahtarları ve sertifikalar gerektiğinde değiştirilir. Uygulama ile veritabanının sürüm uyumu doğrulanır. Kritik işlemler kullanıcı kabul senaryolarıyla test edildikten sonra erişim kontrollü biçimde açılır. Eski sistem yalnız kanıt koruma ve inceleme amacıyla, ağdan ayrılmış halde tutulur.
Yedekleme raporu yönetimin hangi sorularını cevaplamalıdır?
Yedekleme yüzdesi tek başına yeterli bir yönetim göstergesi değildir. Hangi sistemlerin korunduğu, son başarılı kopyanın tarihi, değişmez kopyanın konumu, son geri yükleme testinin sonucu, ölçülen kurtarma süresi ve sorumlu ekip birlikte raporlanmalıdır. Kritik bir sistem kapsam dışında kaldığında veya geri yükleme testi başarısız olduğunda bu durum normal operasyon uyarısı değil, iş sürekliliği riski olarak ele alınmalıdır.
Veri sınıflandırması saklama kararını da belirler. Gereğinden uzun saklanan kişisel veri, yedek ortamındaki ihlal etkisini büyütebilir. Silme ve saklama politikaları yedekleri de kapsamalı; ancak devam eden olay incelemesi ve hukuki saklama gereksinimleriyle çelişmeyecek biçimde yönetilmelidir. Güvenli yedekleme, mümkün olan en fazla veriyi süresiz saklamak değil; gerekli veriyi, gerekli süre boyunca, kontrollü ve geri yüklenebilir biçimde korumaktır.
ForceBT ile yedekleme ve kurtarma değerlendirmesi
ForceBT; datacenter altyapısı, ColdFusion/CFML uygulamaları, Workcube süreçleri, veritabanı, WAF ve sistem işletimini aynı teknik kapsamda değerlendirebilir. Bu sayede yedekleme planı yalnız sanal makine kopyasına indirgenmez; uygulamanın gerçekten çalışması için gereken bütün bağımlılıklar belirlenir.
Değerlendirme sonunda sistem ve veri envanteri, yedekleme kapsamı, saklama ve değişmezlik politikası, erişim matrisi, RTO/RPO hedefleri, geri yükleme test senaryoları ve öncelikli iyileştirme planı hazırlanır. Amaç yalnız “yedek alınıyor” demek değil, veri sızıntısı veya yıkıcı saldırı sonrasında hangi sistemin, hangi kopyadan, kim tarafından ve ne kadar sürede geri döndürüleceğini kanıtlamaktır.
Yedekleme ve kurtarma kapasitenizi gerçek bir olay senaryosuyla değerlendirelim.
Kritik sistemleri, değişmez kopyaları, erişim ayrımını, geri yükleme süresini ve veri sızıntısı sonrası temiz dönüş adımlarını birlikte inceleyelim.
Kaynaklar ve ileri okuma
- CISA — StopRansomware Guide
- Verizon — 2026 Data Breach Investigations Report, yönetici özeti
- Sophos — The State of Ransomware 2026
- Check Point Research — The State of Ransomware, 2026 birinci çeyrek
- NIST — Ransomware hazırlığı ve güvenli geri dönüş önerileri
- NIST NCCoE — Yedeklerin hazırlanması, korunması ve test edilmesi
- KVKK — Veri güvenliğine ilişkin yükümlülükler