Hızlı cevap

Yedekten dönüş tatbikatı bir yedeğin açılmasını değil bir iş hizmetinin kabul edilebilir süre ve veri kaybıyla yeniden çalışmasını sınar. Fidye yazılımı senaryosunda buna kurtarma ortamının temizliği ve yönetim kimliklerinin güvenliği de eklenir. Başarı ölçütü yedekleme konsolundaki yeşil işaret değil iş sahibinin doğruladığı uçtan uca işlemdir.

Bu rehber planlı ve kontrollü bir tatbikat içindir. Devam eden gerçek saldırıda olay müdahale ekibinin kararlarını değiştiren otomatik bir talimat listesi olarak kullanılmamalıdır. Temel planlama kavramları için RTO ve RPO yöntem seçimi rehberi tamamlayıcıdır.

Yedek mevcut ama hizmet neden dönmüyor?

Veritabanı geri yüklenebilirken uygulamanın şifreleme anahtarı bulunamayabilir. Uygulama açılırken kimlik sağlayıcısı erişilemez olabilir. Lisans sunucusu veya DNS kaydı eksik kalabilir. Kurtarılan sistem eski servis hesabıyla yeniden saldırganın erişim alanına bağlanabilir.

Bu nedenle tatbikatın nesnesi tek bir sanal makine yerine bir iş hizmeti olmalıdır. Örneğin deneme siparişinin oluşturulup faturaya dönüşmesi ve raporda görünmesi birlikte gözlenebilir. Altyapı ekibinin açıldı kararı ile iş sahibinin kullanabiliyorum kararı ayrı zamanlarda oluşabilir.

CISA'nın fidye yazılımı rehberi çevrim dışı şifreli yedekleri ve düzenli geri dönüş testlerini önerir. Kurtarmanın temiz ağda önceliklendirilmesini ve yeniden enfeksiyonun önlenmesini de ele alır. Bu rehberdeki ölçüm tablosu bu temel ilkelerden hareketle hazırlanmış özgün bir tatbikat önerisidir.

Tatbikattan önce kapsamı yazın

Hangi hizmetin kurtarılacağını belirtin. Hizmetin iş sahibini ve teknik sorumlusunu atayın. Kabul edilen kesinti süresini ve veri kaybı hedefini kararlaştırın. Başlangıç anının ne sayılacağını yazın. Sonuçların hangi koşulda kabul edileceğini tatbikat başlamadan belirleyin.

Sonra bağımlılık listesini hazırlayın. Kimlik servisi ve DNS çoğu uygulamanın görünmeyen temelidir. Şifreleme anahtarlarının erişim yöntemi ayrı kontrol edilmelidir. Yapılandırma dosyaları ve sertifikalar da geri dönüş kapsamına dahildir. Gereken anahtarın yalnızca kurtarılamayan sistemde tutulduğu bir plan çalışmayabilir.

Kullanılacak veri ve ağ bağlantılarını sınırlandırın. Sentetik veri tercih edin. Gerçek bir yedek kullanılacaksa erişim ve saklama kuralları belirlenmiş olmalıdır. Tatbikatın üretim verisini ezmesini veya deneme epostalarını müşterilere göndermesini engelleyen kontroller hazırlayın. Bu hazırlık testi geciktiren formalite değil testin güvenilir parçasıdır.

Sekiz kabul kapısı

Aşağıdaki kapılar DSET'in bu yazı için önerdiği çalışma şablonudur. Her kapı için geçti veya kaldı veya kanıt yetersiz sonucu kaydedilir. Hedef değerler kuruma göre doldurulur. Burada evrensel bir kurtarma süresi dayatılmamaktadır.

No Kontrol kapısı Kabul ölçütü Kanıt
1 Yedek ve anahtar erişimi Seçilen yedek yetkili kişi tarafından açılabilir Yedek kimliği ve erişim sonucu
2 Kurtarma noktası seçimi Seçim gerekçesi olay zaman çizelgesine bağlanır Zaman çizelgesi ve inceleme özeti
3 İzole kurtarma ortamı Üretime kontrolsüz bağlantı oluşmaz Ağ kuralı ve bağlantı kontrolü
4 Kimlik ve sırların güvenliği Riskli kimlikler temiz ortama aynen taşınmaz Yenileme ve erişim planı
5 Veri ve uygulama tutarlılığı Kritik kayıtlar uygulama seviyesinde doğrulanır Örnek kayıt karşılaştırmaları
6 İş süreci kabulü İş sahibi belirlenmiş işlemi tamamlar Uçtan uca işlem sonucu
7 Süre ve veri kaybı Ölçülen değerler önceden kabul edilmiş hedeflere uyar RTO ve RPO zamanları
8 Yeniden bağlantı kararı Güvenlik ve iş sorumluları kontrollü dönüşü onaylar Karar kaydı ve izleme planı

Yedekten dönüş kabul tablosunu indir. Dosyada her kapı için sorumlu ve gözlem alanları bulunur.

RTO ve RPO hesabı: kurgusal bir örnek

Bir deneme hizmeti saat 10.00'da kesilir. Kurum hedefi en fazla 120 dakika kesinti ve en fazla 10 dakika veri kaybıdır. Kurtarma işi 10.15'te başlar. Seçilen ve uygulama seviyesinde doğrulanan yedek 09.45'e kadar tutarlı kayıt içerir. İş sahibi hizmeti 12.10'da kabul eder.

Gözlenen hizmet kesintisi 130 dakikadır. Yalnızca geri yükleme işinin başlangıcından ölçülürse 115 dakika görünür. Bu ikinci süre hizmetin bütün kesintisini temsil etmez. Belirlenen 120 dakikalık hedef karşılanmamıştır.

Gözlenen veri kaybı aralığı 15 dakikadır. Kesinti öncesindeki son tutarlı geri dönüş noktası ile kesinti zamanı arasındaki fark alınmıştır. Bu da 10 dakikalık hedefi karşılamaz. Uygulama günlükleriyle daha ileri bir tutarlı noktaya dönülebiliyorsa sonuç yeni kanıtla hesaplanmalıdır.

Bu sayılar örnek hesap içindir. DSET müşterisinin sonucu veya hizmet taahhüdü değildir. RTO ve RPO hedeflerinin iş etki analizinden türetilmesi için NIST SP 800-34 Rev. 1 temel bir kaynaktır. Raporda hedef ile gözlenen sonucu aynı terim altında karıştırmamak gerekir.

Temiz yedek kararı yalnızca tarihe bakılarak verilemez

En yeni yedek saldırganın erişiminden sonra alınmış olabilir. Daha eski bir yedek ise önemli iş kayıtlarını eksik bırakabilir. Seçim olayın anlaşılmasıyla birlikte yapılmalıdır. Zararlı yazılım taramasından temiz sonuç alınması tek başına saldırgan erişiminin bulunmadığını kanıtlamaz.

Tatbikatta bu belirsizliği görünür kılan bir karar noktası ekleyin. Ekip hangi kayıtla yedeği kabul ediyor? Hangi inceleme tamamlanmadan yeniden bağlantıya izin vermiyor? Daha eski bir noktaya dönülürse iş sahibi hangi kayıtların tekrar oluşturulacağını biliyor mu? Bu soruların yanıtı kurtarma hızından ayrı bir çıktı olarak saklanmalıdır.

İş sahibinin yapacağı kabul işlemi

Kabul senaryosu mümkün olduğunca gerçek iş akışını temsil etmelidir. Bir ERP hizmetinde deneme siparişi oluşturulup stok hareketi ve muhasebe kaydı izlenebilir. Bir belge sisteminde izinli kullanıcı dosyayı açabilirken izinsiz kullanıcı erişememelidir. Yalnızca ana sayfanın açılması yeterli ölçüt değildir.

Uygulama açıldıktan sonra veri bütünlüğü ve erişim kontrolleri birlikte incelenir. Geri yükleme eski bir kullanıcı hesabını yeniden etkinleştirmiş olabilir. Dosyanın hash değerinin bekleneni vermesi içindeki ticari kayıtların güncel olduğunu göstermez. Teknik bütünlük ve iş doğruluğu farklı doğrulamalardır.

NIST SP 800-184 siber olay sonrası kurtarmayı planlama ve geliştirme çerçevesinde ele alır. Buradan çıkarılan pratik sonuç şudur: tatbikat bir raporla kapanmamalı; eksik kalan bağımlılıklar ve kararlar bir sonraki denemede yeniden sınanmalıdır.

Raporun sonunda hangi kararlar bulunmalı?

Ölçülen süreyi başlangıç ve bitiş tanımıyla birlikte yazın. Kabul edilen veri noktasını belirtin. Testte kullanılmayan bağımlılıkları açıkça listeleyin. Tam ölçekli veri kullanılmadıysa süreyi üretimin tamamına genellemeyin. İstisnaları onaylayan iş sahibini ve düzeltme sorumlusunu belirtin.

Bir sonraki tatbikat yalnızca takvimdeki tarih olmamalıdır. Yedek altyapısının veya kimlik sisteminin değişmesi tekrar test için tetikleyici olabilir. Başarısız kapılar kapatıldıktan sonra aynı kabul ölçütleriyle yeniden ölçüm yapılmalıdır.

Sık sorulan sorular

Değiştirilemez yedek geri dönüş garantisi midir?

Hayır. Değiştirilemezlik belirli koşullarda silinme veya değiştirilme riskini azaltır. Anahtar erişimi ve uygulama tutarlılığı ile kurtarma süresi ayrıca test edilir.

Her tatbikatta bütün üretimi durdurmalı mıyız?

Hayır. İzole ve kademeli testler yapılabilir. Ancak yalnızca dar bir örnek test edildiyse sonuç bütün kuruma genellenmemelidir.

Yedek dosyasının açılması yeterli midir?

Hayır. Uygulamanın ve iş sürecinin çalışması da doğrulanmalıdır. Açılan dosya eksik veya eski kayıtlar içerebilir.

Kurtarma başarısı yalnızca BT ekibinin kararı mı?

Hayır. Teknik ekip altyapıyı doğrular. İş sahibi hizmetin gerekli süreci karşılayıp karşılamadığını kabul eder. Güvenlik sorumlusu yeniden bağlantı koşullarını değerlendirir.

DSET ile hazırlık

Bir değerlendirme talebi için kritik hizmeti ve yedek yöntemini yazın. Kabul edilmiş RTO ve RPO hedefleri varsa ekleyin. DSET veri kurtarma hizmetleri ile siber güvenlik hizmetleri farklı uzmanlık gerektiren bu kapsamın görüşülmesi için başlangıç noktalarıdır. Bozuk yedek sorunu yaşıyorsanız kurumsal yedekten veri kurtarma rehberi ayrıca yararlıdır.

Editoryal not: Kabul kapıları ve hesap örneği bu rehber için hazırlanmıştır. Kaynaklar 11 Ekim 2026 tarihinde kontrol edilmiştir. Başarı oranı veya belirli sürede kurtarma garantisi verilmemektedir.