Siber Kurtarma Tatbikatı: Fidye Senaryosunda Geri Dönüşü Sınamak

Rutin geri yükleme testi geçti diye fidye saldırısı sonrası kurtarma hazır sayılmaz. Gerçek olayda saldırgan genellikle etki alanı yöneticisi olmuştur, yedek konsoluna girmiştir ve hipervizörleri şifrelemiştir; kurtarma bu ortamın hiçbir parçasına güvenmeden yapılır. Bu rehber, saldırı varsayımlı bir teknik kurtarma tatbikatının senaryosunu, kapsamını, başarı kriterlerini ve ölçümünü nasıl kuracağınızı anlatır.

Geri yükleme testi ile siber kurtarma tatbikatı arasındaki fark

Klasik geri yükleme testi altyapının sağlam olduğunu varsayar. Yedek sunucusu açıktır, konsola etki alanı hesabıyla girilir, geri yüklenen makine üretim ağına bağlanır; DNS, DHCP ve kimlik doğrulama yerindedir. Bu test 3-2-1-1-0 kuralındaki “0 hata” hedefinin parçasıdır ve 3-2-1-1-0 yedekleme kuralı ve geri yükleme testi yazısında anlatılır. Gerekli ama yetersiz.

Siber kurtarma tatbikatı başka sorular sorar. Yedek sunucusu da şifrelendiyse konsolu nereden, kaç saatte yeniden kurarız? Yedek şifreleme parolası nerede, kim erişebiliyor? Active Directory ele geçirildiyse geri yüklenen sunuculara hangi kimlikle gireceğiz? Hangi kurtarma noktasının temiz olduğuna kim, neye bakarak karar verecek? Rutin testte bu soruların hiçbiri gündeme gelmez.

Boyut	Rutin geri yükleme testi	Siber kurtarma tatbikatı
Yedek konsolu	Çalışıyor kabul edilir	Kaybedilmiş ya da güvenilmez
Kimlik altyapısı	Üretim AD kullanılır	AD ele geçirilmiş varsayılır
Ağ	Üretim ağı	İzole kurtarma ağı
Kurtarma noktası	En son yedek	Temizliği doğrulanmış nokta
Ölçülen	Verinin okunabilirliği	İş hizmetinin geri dönüş süresi

Senaryo varsayımları

Tatbikatın kurumsal siber güvenlik açısından değeri, varsayımların ne kadar acımasız yazıldığına bağlıdır. Yumuşak varsayımla yapılan tatbikat yalnızca güven verir, bilgi vermez. Senaryo dokümanında en az şunlar açıkça yazılmalı:

• Kimlik: Tüm etki alanı yönetici hesapları ve KRBTGT anahtarı ele geçirilmiştir; mevcut AD hesaplarıyla hiçbir kurtarma sistemine oturum açılmaz.
• Yedek altyapısı: Yedek sunucusu ve yapılandırma veritabanı kullanılamaz; yalnız değiştirilemez depo, çevrimdışı kopya veya nesne depolamadaki kopya erişilebilirdir.
• Sanallaştırma: Üretim hipervizörleri ve paylaşımlı depolama şifrelenmiştir; kurtarma ayrı donanımda ya da ayrı bir kümede yapılır.
• Zaman çizelgesi: Saldırganın ilk erişimi şifrelemeden bir süre önce olmuştur; son birkaç günün yedekleri kalıcılık mekanizması içeriyor olabilir.
• Erişim: Kurumsal e-posta ve şirket içi parola kasası kullanılamaz; ekip iletişimi ve kritik bilgiler bant dışı kanaldan sağlanır.

İlk turda bütün varsayımları birden uygulamak şart değil. Ekibin olgunluğuna göre aşağıdaki varyasyonlardan biriyle başlayın:

Varyasyon	Ana varsayım	Sınanan yetenek
A: Konsol kaybı	Yedek sunucusu yok	Konsolu yeniden kurup depoyu içe aktarma
B: Kimlik kaybı	AD ele geçirilmiş	DC’yi izole ortamda kurtarma, hesapları sıfırlama
C: Kirli son yedek	Son yedeklerde zararlı var	Kurtarma noktası seçimi ve tarama
D: Tam senaryo	A + B + C ve hipervizör kaybı	Kritik iş hizmetinin uçtan uca dönüşü

Pratikte en verimli sıra A ile başlayıp her turda bir varyasyon eklemektir; böylece her darboğaz ayrı ayrı görünür. Sahada A varyasyonu bile çoğu ekibi ilk saatte durdurur: kurulum medyası, lisans dosyası ya da depo erişim bilgisi el altında değildir. Kirli son yedek varyasyonundaki tarama ve karar yöntemi için temiz kurtarma noktası seçimi rehberine bakın.

Kapsam ve başarı kriterleri

Kapsamı sunucu listesiyle değil, iş hizmetiyle tanımlayın. “ERP sistemi” yazmak yetmez; “ERP’ye kullanıcı giriş yapabilir, sipariş oluşturabilir ve fatura kesebilir” gibi doğrulanabilir bir cümle yazılır. Ardından bu hizmetin bağımlılık zinciri çıkarılır: etki alanı denetleyicisi, DNS, veritabanı sunucusu, uygulama sunucusu, lisans sunucusu, dosya paylaşımı, sertifika hizmetleri. Bağımlılık haritası olmadan başlayan tatbikat tipik olarak aynı yerde kilitlenir: uygulama sunucusu açılır, lisans sunucusunu bulamaz, servis kalkmaz. Bu, sahada en sık gördüğümüz duruş noktasıdır.

Her kapsam öğesi için şu kriterler tatbikattan önce yazılır:

• Hedef kurtarma süresi (RTO) ve kabul edilebilir veri kaybı (RPO), iş birimi onayıyla.
• Kurtarma noktasının temizliğini kanıtlamak için yapılacak kontroller.
• Hizmetin “çalışıyor” sayılması için uygulama sahibinin yapacağı fonksiyonel test.
• Tatbikatın durdurulma koşulları; örneğin izolasyon ihlali şüphesi.

Tatbikat adımları ve rol dağılımı

Teknik akış, gerçek bir olaydaki kurtarma akışıyla aynı olmalı. Orta ölçekli çoğu ortamda şu iskelet işler:

1. Başlatma ve iletişim: Tatbikat yöneticisi senaryoyu açıklar, saat damgasıyla kayıt başlar. Ekip bant dışı iletişim kanalına geçer.
2. İzole ortamın hazırlanması: Kurtarma ağı, geçici hipervizör ve yönetim iş istasyonu kurulur ya da önceden hazırlanmış ortam açılır. Tasarım ilkeleri için izole kurtarma ortamı tasarımı yazısına bakın.
3. Yedek konsolunun yeniden kurulması: Temiz kurulum medyasından yedek sunucusu kurulur, değiştirilemez depo ya da nesne depolama içe aktarılır. Şifreli yedekler için parola emanetten alınır.
4. Kurtarma noktası kararı: Zaman çizelgesine göre aday nokta seçilir, taranır ve karar kayda geçer.
5. Kimlik altyapısının kurtarılması: Etki alanı denetleyicisi izole ortamda geri yüklenir ve forest kurtarma adımları uygulanır. Ayrıntılar fidye sonrası AD forest kurtarma rehberinde.
6. Uygulama katmanının kurtarılması: Bağımlılık sırasına göre veritabanı, uygulama ve dosya sunucuları açılır.
7. Fonksiyonel doğrulama: Uygulama sahibi önceden yazılmış testi uygular.
8. Kapanış: Ortam temizlenir, kayıtlar toplanır, bulgu toplantısı planlanır.

Rol dağılımında en az şu kişiler olmalı: senaryoyu yöneten ve süreleri tutan tatbikat yöneticisi; yedekleme, sanallaştırma ve kimlik altyapısından sorumlu uygulayıcılar; uygulama sahipleri; kararları yazan bir kayıt sorumlusu. Gözlemci, uygulayıcıların atladığı adımları not eder ve müdahale etmez. Küçük ekiplerde bir kişi birden fazla rol üstlenir, bu kaçınılmaz. Ama uygulayıcı ile kayıt sorumlusunu aynı kişi yapmayın. Konsolda boğuşan kişi saat yazmaz.

Ölçülecek süreler ve gözlemler

Tek bir “toplam kurtarma süresi” rakamı neyin düzeltileceğini söylemez. Süreleri aşama aşama tutun ki darboğaz görünsün:

Ölçüm	Başlangıç	Bitiş
Ortam hazırlık süresi	Senaryonun başlaması	İzole ağın kullanılabilir olması
Konsol kurtarma süresi	Kurulumun başlaması	Yedek zincirlerinin görünür olması
Karar süresi	Aday noktaların listelenmesi	Kurtarma noktasının onaylanması
Kimlik kurtarma süresi	DC geri yüklemesinin başlaması	Hesaplarla oturum açılabilmesi
Hizmet dönüş süresi	Senaryonun başlaması	Fonksiyonel testin geçmesi

Sürelerin yanına nitel gözlemleri de yazın: hangi bilgi bulunamadı, hangi parola emanette yoktu, hangi doküman eskiydi, hangi adımda ekip ne yapacağını bilmedi. Tatbikatlarda tekrar tekrar çıkan bulgular bellidir: yedek şifreleme parolasının yalnız yedek sunucusunda kayıtlı olması; yedek yazılımı lisans dosyasına erişilememesi; geri yüklenen sunucuların yerel yönetici parolalarının bilinmemesi; veritabanı geri yüklemesinin depo performansı yüzünden beklenenden çok uzun sürmesi; uygulamanın sabit kodlanmış IP adreslerine bağlı olması.

Ölçümün güvenilir olması için kayıt sorumlusu her aşamanın başını ve sonunu aynı saat kaynağına göre yazmalı. Yedek yazılımının görev günlükleri ve hipervizör olay kayıtları, sözlü beyanı doğrulamak için ikinci kanıt kaynağıdır. Hafıza yanıltır, log yanıltmaz.

Bulguların iyileştirmeye dönüşmesi

Tatbikatın çıktısı bir bulgu kaydıdır. Her bulgu sahibi, tarihi ve doğrulama yöntemi olan bir aksiyona bağlanır. Kayıtları tutarlı tutmak için şu şablon kullanılabilir:

Bulgu No     : TB-2026-04
Aşama        : Konsol kurtarma
Gözlem       : Yedek şifreleme parolası yalnız eski yedek
               sunucusundaki yapılandırmada kayıtlı; emanette yok.
Etki         : Şifreli yedek zincirleri içe aktarılamadı,
               aşama 2 saat 40 dk gecikti.
Kök neden    : Parola emanet prosedürü tanımlı değil.
Aksiyon      : Parolalar mühürlü emanete ve ayrı kasaya alınacak.
Sorumlu      : Yedekleme yöneticisi
Hedef tarih  : 2026-12-15
Doğrulama    : Sonraki tatbikatta emanetten parola alınarak
               içe aktarma yapılacak.

Bulguları üç gruba ayırın: teknik (mimari değişiklik gerektiren), süreç (runbook ve emanet gibi dokümantasyon) ve yetkinlik (ekibin eğitim ihtiyacı). Teknik bulgular çoğu zaman bütçe ister; yönetime ölçülmüş sürelerle gidildiğinde karar çabuk çıkar. Örnek hesap: hedef RTO 8 saat, ölçülen hizmet dönüş süresi 19 saat. Farkın hangi aşamada oluştuğu tablodaki aşama süreleriyle gösterilir ve yatırım o aşamaya yönlendirilir.

Bir sonraki tatbikat, önceki bulguların gerçekten kapandığını doğrulayacak şekilde kurulur. Kapanmayan bulgu, bir sonraki olayda aynı saatleri yine yer. Tatbikat programını olay müdahale planıyla bütünleştirmek için siber olay müdahale hazırlığı ve tatbikat hizmetimize, yedek mimarisindeki açıkları kapatmak için yedekleme güvenliği ve fidye yazılımına hazırlık sayfasına bakabilirsiniz. Planlama ve değerlendirme yöntemi için NIST’in SP 800-84 test, eğitim ve tatbikat rehberi sağlam bir çerçevedir.

Sık sorulan sorular

Siber kurtarma tatbikatı üretim ortamını riske atar mı?

Doğru kurgulanırsa atmaz. Geri yüklenen makineler üretimle aynı adları, IP adreslerini ve etki alanını taşır; bu yüzden geri yüklemeler üretime hiçbir yönlendirme, VPN veya yönetim bağlantısı olmayan izole bir ağda yapılır. Yedek deposuna yalnız okuma amaçlı erişilir, tatbikat bitince test ortamındaki tüm makineler silinir. Asıl risk izolasyon kuralının unutulmasıdır; ağ ayrımını tatbikat öncesinde ayrıca doğrulayın.

Tatbikat ne sıklıkla yapılmalı?

Tam kapsamlı senaryo için yılda en az bir kez; yedek mimarisinde, kimlik altyapısında veya kritik uygulamalarda büyük değişiklik olduğunda ek olarak. Dar kapsamlı parçalar, örneğin yalnız etki alanı denetleyicisini izole ortamda ayağa kaldırmak, üç ayda bir tekrarlanabilir.

Rutin geri yükleme testleri başarılıysa siber tatbikata yine de gerek var mı?

Var. Rutin test, yedek konsolu, Active Directory ve ağ hizmetleri sağlamken tek bir sunucunun dönüp dönmediğini gösterir. Siber senaryoda bu bağımlılıkların kendisi yoktur; konsolun yeniden kurulması, şifreleme parolalarına erişim ve kimlik altyapısının sıfırdan ayağa kaldırılması ancak tatbikatta sınanır.

Tatbikatın başarılı sayılması için hangi ölçüt esas alınmalı?

Tek bir sunucunun açılması değil, önceden yazılmış iş hizmetinin uçtan uca çalışması. Örneğin “ERP’ye kullanıcı giriş yapabiliyor ve sipariş kaydı oluşturulabiliyor” gibi bir ölçüt, hedef süre ve veri kaybı sınırıyla birlikte tanımlanır; gerçekleşen değerler bu hedeflerle karşılaştırılır.