Fidye yazılımı olayında en rahatlatıcı cümle genellikle “yedeklerimiz var” olur. Fakat bir yedek dosyasının listede görünmesi; temiz, eksiksiz, erişilebilir ve kabul edilen sürede geri yüklenebilir olduğu anlamına gelmez. Saldırgan kimlik altyapısında kalıcılık sağladıysa, yedek yönetim hesabını ele geçirdiyse veya uygulama bağımlılıkları bilinmiyorsa aceleyle yapılan geri yükleme temiz sistemleri yeniden riske atabilir.
Gerçek kurtarma, veriyi kopyalamaktan fazlasıdır. Olayı sınırlamak, kanıtı korumak, güvenilir bir başlangıç noktası seçmek, hizmetleri doğru sırayla ayağa kaldırmak ve üretime dönmeden önce bütünlüğü doğrulamak gerekir. Kurtarma planının başarı ölçütü “sunucu açıldı” değil; iş süreci güvenli ve ölçülebilir biçimde yeniden çalışıyor olmalıdır.
Kurtarma, Yedekten Daha Büyük Bir Sistemdir
Yedekleme bir veri koruma yeteneğidir; kurtarma ise insan, süreç, kimlik, ağ, uygulama ve iletişimi bir araya getiren operasyonel bir yetenektir. CISA, kritik verilerin çevrimdışı ve şifreli yedeklerinin tutulmasını, kullanılabilirlik ile bütünlüğün felaket kurtarma senaryosunda düzenli test edilmesini önerir. Aynı rehber, kritik sistemlerin güncel “golden image”larını; yani güvenilir işletim sistemi ve uygulama şablonlarını da hazırlık kapsamında değerlendirir.
Yaygın kullanılan 3-2-1-1 kuralı — üç veri kopyası, iki farklı ortam, bir tesis dışı kopya ve bir çevrimdışı ya da değiştirilemez kopya — dayanıklı bir temel sağlar. Immutable (değiştirilemez) yedek, belirlenen saklama süresince silinemeyen veya değiştirilemeyen kopyadır. Yine de kuralın uygulanmış olması tek başına kurtarma kanıtı değildir; yetkiler, anahtarlar, kataloglar ve geri yükleme prosedürü de saldırı anında çalışmalıdır.
RTO, RPO ve Bağımlılıklar Kurtarma Sırasını Belirler
RTO (Recovery Time Objective / kurtarma süresi hedefi), bir sistem kaynağının kabul edilemez iş etkisi oluşmadan önce ne kadar süre kullanılamaz kalabileceğini tanımlar. RPO (Recovery Point Objective / kurtarma noktası hedefi), kesinti sonrasında verinin hangi zaman noktasına kadar geri getirileceğini ve bununla bağlantılı tolere edilebilir veri kaybını tanımlar. Bu iki değer iş birimi tarafından onaylanmalı; yalnızca altyapı ekibinin tahmini olmamalıdır.
Hizmetleri tek tek değil, bağımlılık zinciriyle önceliklendirin. Bir ERP sunucusunu kimlik doğrulama, DNS, veritabanı, sertifika hizmetleri veya ağ segmentleri hazır olmadan açmak işlevsel bir kurtarma üretmez. Her kritik hizmet için sahibi, RTO/RPO değeri, veri kaynağı, teknik bağımlılıkları, geri yükleme yöntemi ve doğrulama sorumlusu kayıtlı olmalıdır.
Temel
· Örnek bileşen: Kimlik, DNS, zaman, sertifika ve güvenli yönetim
· Başarı kanıtı: Yetkili erişim ve kayıt üretimi
Veri
· Örnek bileşen: Veritabanı, dosya ve yapılandırma depoları
· Başarı kanıtı: Tutarlılık ve kötü amaçlı yazılım kontrolü
Uygulama
· Örnek bileşen: Kritik iş servisleri ve entegrasyonlar
· Başarı kanıtı: Uçtan uca işlem testi
Kullanıcı
· Örnek bileşen: İstemciler, raporlama ve ikincil servisler
· Başarı kanıtı: Kontrollü erişim ve izleme
İlk Saatte İzole Edin, Triyaj Yapın ve Kanıtı Koruyun
CISA’nın yanıt kontrol listesi, etkilenen sistemlerin belirlenmesini ve derhal izole edilmesini ilk adımlar arasında sayar. Mümkünse cihazı kapatmak yerine ağ bağlantısını kesin; kapatma, bellekteki uçucu adli kanıtı yok edebilir. Yayılım birden çok alt ağı etkiliyorsa izolasyon ağ anahtarı veya segment düzeyinde yapılabilir. Bulut kaynaklarında olay anı görüntüsü almak, daha sonraki incelemeye yardımcı olabilir.
Triyaj, sistemleri etki ve kurtarma önceliğine göre hızlıca sınıflandırmaktır. Etkilenen, şüpheli ve temiz olduğu henüz doğrulanmamış varlıkları ayrı tutun. Bellek, güvenlik olayları, güvenlik duvarı tamponları ve kısa saklama süreli bulut kayıtları gibi uçucu kanıtları koruyun. Fidye yazılımı, daha önce başlayan ve çözülmemiş bir sızmanın son aşaması olabilir; yalnızca şifreleme yazılımını kaldırmak kök nedeni ortadan kaldırmaz.
Temiz Kurtarma Ortamını Kimlikten Başlatın
Geri yükleme, saldırıya uğramış üretim ağına doğrudan yapılmamalıdır. Ayrı yönetim hesapları ve sıkı ağ kuralları olan segmentli bir temiz kurtarma ortamı, sistemlerin üretime dönmeden önce incelenmesini sağlar. CISA da kurtarma için oluşturulan yeni VLAN’a (sanal yerel ağ) yalnızca temiz sistemlerin eklenmesini ve yeniden bulaşmaya karşı dikkatli olunmasını önerir.
Önce güven köklerini ele alın: ayrıcalıklı hesaplar, dizin hizmeti, çok faktörlü kimlik doğrulama, yedek kasası erişimi, anahtarlar ve sertifikalar. Ele geçirilmiş kimlik bilgilerini temiz sisteme taşımayın; parolaları ve ayrıcalıklı anahtarları kontrollü biçimde yenileyin. Ardından temel ağ servisleri, yönetim araçları ve merkezi kayıt altyapısını kurun. İzleme çalışmadan uygulamaları açmak, yeniden bulaşmayı veya saldırganın kalıcılığını görünmez bırakır.
Yedeği Kullanmadan Önce ve Sistemi Açtıktan Sonra Doğrulayın
NIST Cybersecurity Framework 2.0’ın RC.RP-03 sonucu, yedeklerin ve diğer geri yükleme varlıklarının bütünlüğünün kullanılmadan önce doğrulanmasını ister. Bu; seçilen kurtarma noktasının saldırı öncesine ait olduğunun, şifreleme ve kötü amaçlı yazılım izleri taşımadığının, katalog ile anahtarların çalıştığının kontrol edilmesi demektir. Daha yeni kopya her zaman daha güvenli kopya değildir; saldırganın içeride bulunduğu süre hesaba katılmalıdır.
Geri yükleme sonrasında yalnızca dosya sayısını karşılaştırmayın. Veritabanı tutarlılığı, uygulamanın uçtan uca işleyişi, entegrasyon mesajı, yetki kontrolü ve iş birimi kabul testi birlikte değerlendirilmelidir. NIST CSF 2.0 RC.RP-05, geri dönen varlıkların bütünlüğünün doğrulanmasını ve normal işletim durumunun teyidini açıkça ayırır. Bağlantıyı dalgalar halinde açın; her dalgada telemetriyi izleyin ve geri dönüş kriteri belirleyin.
Sık Yapılan Hatalar
İlk hata, geri yükleme testini “iş tamamlandı” raporuyla karıştırmaktır; süre, veri bütünlüğü ve iş işlemi ölçülmediyse test eksiktir. İkinci hata, yedek yönetim düzlemini üretimle aynı kimlik ve ağ sınırında bırakmaktır. Üçüncü hata, en görünür uygulamayı bağımlılıklarını kurmadan önce açmaktır. Dördüncü hata, saldırganın ilk erişim ve kalıcılık yöntemini kapatmadan eski yapılandırmayı geri getirmektir. Son olarak, kriz iletişimini teknik ekibin anlık mesajlarına bırakmak çalışanlar, hizmet kullanıcıları, yönetim ve dış paydaşlar arasında çelişkili bilgi üretir.
Sektörel Kurtarma Senaryoları
Üretimde öncelik güvenlik sistemleri, OT/IT sınırı ve üretim reçetelerinin bütünlüğüdür; hat yalnızca sunucular açıldığı için başlatılmamalıdır. Sağlıkta klinik hizmet sürekliliği ile hasta verisinin doğruluğu birlikte korunmalı, geçici manuel süreçlerin sisteme nasıl işleneceği planlanmalıdır. Finansta kimlik, işlem kayıtları ve mutabakat zinciri kritik olur; her geri yükleme dalgası denetlenebilir kanıt üretmelidir. Perakendede mağaza, ödeme, stok ve e-ticaret bağımlılıkları farklı RTO’lara sahip olabilir; merkezi sistem dönene kadar sınırlı çalışma modu önceden tasarlanmalıdır.
Aşamalı Kurtarma Yol Haritası
Birinci aşamada iş etki analizini tamamlayın; kritik hizmetleri, sahiplerini ve bağımlılıklarını çıkarın. İkinci aşamada yedekleri çevrimdışı veya değiştirilemez katmanla güçlendirin; golden image, altyapı kodu, lisans ve yapılandırma kopyalarını koruyun. Üçüncü aşamada kimlikten uygulamaya kadar temiz kurtarma ortamını ve ayrık yönetim erişimini kurun. Dördüncü aşamada masa başı tatbikatı değil, gerçek geri yükleme yaparak RTO/RPO sonuçlarını ölçün. Beşinci aşamada üretim, güvenlik, hukuk, iletişim ve iş birimlerinin katıldığı tam senaryolu tatbikat gerçekleştirin. Her olay ve tatbikattan sonra planı, irtibat listesini ve otomasyonu güncelleyin.
Nereden Başlamalı? Kısa Kontrol Listesi
· Kritik hizmetler iş etkisine göre sıralı ve bağımlılıkları belgeli mi?
· RTO ve RPO değerleri iş sahipleri tarafından onaylandı mı?
· En az bir yedek kopyası üretim kimliğinden ve ağından ayrılmış mı?
· Yedek bütünlüğü ve gerçek geri yükleme süresi düzenli ölçülüyor mu?
· Temiz kurtarma ağı ile ayrı yönetim hesapları hazır mı?
· Kimlik, DNS, sertifika, anahtar ve kayıt servislerinin sırası belli mi?
· Adli kanıtı kim, nerede ve hangi saklama zinciriyle koruyacak?
· Üretime dönüş için teknik ve iş kabul kriterleri tanımlı mı?
· İç ve dış iletişim mesajları ile karar yetkileri önceden belirlendi mi?
Kaynaklar
· CISA — #StopRansomware Guide (https://www.cisa.gov/stopransomware/ransomware-guide)
· NIST — Cybersecurity Framework 2.0 (https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=957258)
· NIST SP 800-184 — Guide for Cybersecurity Event Recovery (https://csrc.nist.gov/pubs/sp/800/184/final)
· NIST SP 1800-11 — Data Integrity: Recovering from Ransomware and Other Destructive Events (https://csrc.nist.gov/pubs/sp/1800/11/final)
