Felaket Kurtarma (DR) Planı: Hazırlama ve Test Adımları

Sunucu odasında çıkan bir yangın, ele geçirilmiş bir yönetici hesabıyla başlayan fidye yazılımı saldırısı ya da binaya günlerce girilemeyen bir su baskını... Bu olaylar yaşandığında ilk saatlerde verilen kararlar, işletmenin günler mi yoksa haftalar mı kapalı kalacağını belirler. Felaket kurtarma (Disaster Recovery, DR) planı, o saatlerde doğaçlama yapmak yerine önceden düşünülmüş ve test edilmiş adımları uygulamanızı sağlar. Bu rehberde, farklı ölçeklerdeki işletmelerde uyguladığımız DR planlama yaklaşımını adım adım aktarıyoruz.

Felaket Kurtarma Nedir? İş Sürekliliğinden Farkı

Felaket kurtarma, ciddi bir kesinti sonrasında BT sistemlerini, verileri ve altyapıyı belirlenmiş süreler içinde yeniden çalışır hale getirmeye yönelik plan, teknoloji ve prosedürlerin bütünüdür. İş sürekliliği planı (BCP) ise daha geniş bir çerçevedir: insanlar, tesisler, tedarikçiler, müşteri iletişimi ve geçici manuel çalışma yöntemleri dahil işletmenin tüm kritik faaliyetlerini kapsar.

Kısaca iş sürekliliği ‘işimizi nasıl sürdürürüz?’ sorusunu, felaket kurtarma ise ‘sistemlerimizi nasıl geri getiririz?’ sorusunu yanıtlar. DR planı, iş sürekliliği planının teknik ayağıdır ve ondan bağımsız hazırlanmamalıdır. Çerçevenin tamamı için iş sürekliliği planı rehberimize göz atabilirsiniz.

Risk ve Etki Analizi: Kritik Sistemleri Belirleme

İyi bir DR planı, her sistemi aynı önemde görmeyen bir analizle başlar. İlk adımda karşılaşabileceğiniz tehditleri listeleyin:

• Teknik arızalar: Depolama ünitesi arızası, sunucu donanım hatası, bozulan veritabanı, sorunlu bir güncelleme.
• Siber saldırılar: Fidye yazılımı, hesap ele geçirme, içeriden kötü niyetli silme.
• Fiziksel olaylar: Yangın, su baskını, uzun süreli elektrik kesintisi, deprem.
• Tedarikçi kaynaklı kesintiler: İnternet servis sağlayıcısı, veri merkezi veya SaaS sağlayıcısında yaşanan sorunlar.
• İnsan hatası: Yanlışlıkla silinen klasörler, hatalı yapılandırma değişiklikleri.

İstanbul gibi deprem riski yüksek bir bölgede, binaya uzun süre erişilemeyeceği senaryosu mutlaka planın parçası olmalıdır.

Ardından sistemleri iş etkisine göre sınıflandırın. Her uygulama için şu soruları sorun: Bu sistem çalışmazsa hangi süreç durur? Kaç saat sonra müşteriye yansır? Yasal veya sözleşmesel bir yükümlülük ihlal edilir mi? Hangi diğer sistemlere bağımlıdır? Sonuçta sistemleri üç kademede toplamak çoğu zaman yeterlidir: birkaç saat içinde dönmesi gereken kritik sistemler, bir iş günü içinde dönmesi gerekenler ve birkaç gün bekleyebilecek olanlar.

Bağımlılıklar gözden kaçırılmamalıdır: Active Directory, DNS, lisans sunucusu ve veritabanı sunucusu çalışmıyorsa ERP uygulamasını geri getirmek tek başına bir anlam ifade etmez.

RTO ve RPO Hedeflerini Belirleme

Her kademe için iki hedef tanımlanır:

• RTO (Recovery Time Objective): Sistemin kesintiden sonra en geç ne kadar sürede yeniden kullanılabilir olması gerektiği.
• RPO (Recovery Point Objective): Kabul edilebilir en fazla veri kaybı, yani en son hangi ana kadar geri dönülebilmesi gerektiği.

Bu hedefleri BT tek başına belirlememelidir. İş birimi yöneticileri çoğu zaman her şeyin anında geri gelmesini ister; burada yapılması gereken, her hedefin bir maliyeti olduğunu açıkça göstermektir. Dakikalar mertebesinde bir RTO, ikinci bir lokasyonda sürekli güncel tutulan kopya sistemler gerektirir; bir günlük RTO ise yedekten geri yükleme ile karşılanabilir. Hedefler yedekleme ve replikasyon tasarımını doğrudan belirler; bu bağlantıyı 3-2-1 yedekleme rehberimizde ayrıntılı anlattık.

Bir de gerçekçilik testi yapın: mevcut yedeklerinizden kritik bir sunucuyu geri yüklemek fiilen kaç saat sürüyor? Hedef ile ölçülen süre arasındaki fark, DR yatırımlarınızın öncelik listesini verir. Unutmayın ki kurtarma süresi yalnızca verinin kopyalanma süresi değildir; sorunun fark edilmesi, karar verilmesi, doğru yedeğin bulunması, uygulamanın doğrulanması ve kullanıcıların yeniden bağlanması da bu süreye dahildir.

DR Senaryoları: Yerel, İkincil Lokasyon ve Bulut (DRaaS)

Kurtarma altyapısı için üç temel yaklaşım vardır ve çoğu işletme bunları birlikte kullanır:

• Yerel kurtarma: Aynı binadaki yedek sunucudan veya yedekleme cihazından geri dönüş. Donanım arızası ve yanlışlıkla silme gibi olaylarda en hızlı yöntemdir; binayı etkileyen felaketlerde ise işe yaramaz.
• İkincil lokasyon: Başka bir şubede veya bir veri merkezinde kiralanan kabinde tutulan kopya sistemler, replikasyonla güncel tutulur. Kontrol sizdedir; donanım, bağlantı ve bakım maliyeti de sizdedir.
• Bulut ve DRaaS (Disaster Recovery as a Service): Sunucular buluttaki bir hedefe çoğaltılır ve felaket anında sanal makineler bulutta başlatılır. Normal zamanda ağırlıklı olarak depolama ve replikasyon için ödeme yapılır; hesaplama kaynakları test ve gerçek kurtarma sırasında devreye girer.

Senaryo seçerken ağ tarafını unutmayın: sistemler başka bir yerde açıldığında kullanıcılar oraya nasıl bağlanacak? DNS kayıtları, VPN erişimi, genel IP adresleri, e-posta akışı ve güvenlik duvarı kuralları planın parçası olmalıdır. Sunucuları ayağa kaldırıp erişimi unutan planlar ilk testte çöker.

Microsoft 365 gibi SaaS hizmetlerini de senaryoya dahil edin. Bu hizmetlerin altyapısı sağlayıcı tarafından korunur; ancak yanlışlıkla silinen posta kutuları, ele geçirilmiş bir hesapla toplu silinen dosyalar veya saklama süresini aşan kayıplar sizin kurtarma planınızın konusudur.

Adım Adım DR Planı Hazırlama

1. Kapsam ve sorumluluk: Planın hangi sistemleri kapsadığını ve sahibini belirleyin; bir DR koordinatörü ve onun yedeğini atayın. Planda görevi olan herkesin rolünü bildiğinden ve tatbikatlara katıldığından emin olun.
2. Envanter: Sunucuları, uygulamaları, veritabanlarını, ağ cihazlarını, lisansları, tedarikçi sözleşmelerini ve destek iletişim bilgilerini güncel bir listede toplayın.
3. Felaket ilanı kriterleri: Hangi durumda felaket ilan edileceğini ve bu kararı kimin vereceğini tanımlayın. Belirsizlik, en değerli ilk saatlerin tartışmayla geçmesine yol açar.
4. Kurtarma sırası: Bağımlılıklara göre sıralama yapın: önce kimlik ve ağ altyapısı, sonra veritabanları, ardından uygulamalar ve en son kullanıcı erişimi.
5. Adım adım prosedürler: Her kritik sistem için, o sistemi daha önce hiç görmemiş yetkin bir teknisyenin uygulayabileceği ayrıntıda talimat yazın.
6. İletişim planı: Çalışanlara, yönetime, müşterilere ve tedarikçilere kimin, hangi kanaldan, ne söyleyeceğini belirleyin. Kurumsal e-posta çalışmıyor olabilir; alternatif kanalları önceden tanımlayın.
7. Acil erişim bilgileri: Acil durum yönetici hesapları, şifreleme anahtarları ve yedek konsolu erişimleri, ana sistemler çöktüğünde de ulaşılabilecek güvenli bir yerde saklanmalıdır.
8. Geri dönüş (failback): Sorun giderildiğinde ana ortama nasıl ve veri kaybı yaşamadan dönüleceğini planlayın.

Planın basılı bir kopyası ve şifreli bir çevrimdışı kopyası bulunmalıdır; yalnızca çöken dosya sunucusunda duran bir DR planı, ihtiyaç anında kimsenin işine yaramaz.

Veri Kurtarma Sürecinde Dikkat Edilecekler

Kriz anında yapılan hatalar çoğu zaman olayın kendisinden daha fazla zarar verir. Veri kurtarma sırasında şu kurallara uyun:

• Önce yayılmayı durdurun: Fidye yazılımı şüphesinde etkilenen sistemleri ağdan ayırın; kapatmadan önce adli inceleme gerekip gerekmediğini değerlendirin. Saldırgan hâlâ ağdaysa geri yüklenen sistemler de yeniden şifrelenebilir.
• Temiz geri yükleme noktası seçin: Saldırının başlangıç anı tespit edilmeden en son yedeği geri yüklemek zararlı yazılımı da geri getirebilir.
• Fiziksel arızalı diske müdahale etmeyin: Arızalı diskte tekrar tekrar çalıştırma ve onarım denemeleri kurtarma şansını azaltır; bu durumda profesyonel veri kurtarma desteği alınmalıdır.
• Önce izole ortamda doğrulayın: Geri yüklenen veriyi canlıya almadan önce bütünlüğünü ve uygulamanın çalıştığını kontrol edin.
• Açığı kapatmadan canlıya dönmeyin: Saldırganın giriş noktası bulunup kapatılmadan, ele geçirilmiş parolalar değiştirilmeden ve sistemler güncellenmeden yapılan bir geri dönüş, aynı saldırının kısa sürede tekrarlanmasına zemin hazırlar.
• Her adımı kaydedin: Ne zaman, kim, ne yaptı? Bu kayıtlar hem olay sonrası analiz için hem de kişisel veri ihlali söz konusuysa KVKK kapsamındaki bildirim süreci için gereklidir.

Planı Test Etme ve Güncel Tutma

Test edilmemiş bir DR planı, iyi niyetli bir varsayımdan ibarettir. Testleri kademeli olarak planlayın:

1. Masa başı tatbikat: Ekip bir senaryo üzerinden planı adım adım konuşur; eksik bilgiler ve belirsiz sorumluluklar ortaya çıkar.
2. Bileşen testi: Tek bir sunucu veya uygulama izole ortamda geri yüklenir ve geçen süre ölçülür.
3. Paralel test: Kritik sistemler, canlı ortam çalışmaya devam ederken DR ortamında ayağa kaldırılır; iş birimleri erişip doğrular.
4. Tam geçiş testi: Belirlenmiş bir bakım penceresinde üretim gerçekten DR ortamına aktarılır ve geri dönülür. En gerçekçi ama en dikkatli planlanması gereken testtir.

Her testte en azından şu bilgileri kayda geçirin:

• Kurtarma işleminin başladığı ve sistemin kullanıcılara açıldığı an, yani fiilen gerçekleşen kurtarma süresi.
• Geri dönülen yedeğin veya replikasyon noktasının zamanı, yani gerçekleşen veri kaybı.
• Prosedürde eksik, hatalı veya güncelliğini yitirmiş adımlar.
• Test sırasında ihtiyaç duyulan ama plana yazılmamış bilgi, erişim veya kişiler.
• İş biriminin uygulamayı doğrulama sonucu ve varsa gözlemleri.

Ölçülen süreleri RTO ve RPO hedefleriyle karşılaştırın, bulguları kayda geçirin ve planı güncelleyin. Yeni bir uygulama devreye girdiğinde, sunucular taşındığında, kilit personel veya tedarikçi değiştiğinde plan gözden geçirilmeli; bunların dışında en az yılda bir kez kapsamlı bir revizyon yapılmalıdır.

Maliyet Faktörleri ve Hizmet Sağlayıcı Seçimi

DR maliyetini belirleyen başlıca faktörler şunlardır:

• RTO ve RPO hedefleri: Hedef kısaldıkça sürekli çalışan altyapı ve daha sık replikasyon gerekir.
• Korunan sunucu ve veri miktarı: Kapsama alınan her iş yükü depolama ve lisans maliyetine eklenir.
• Hedef ortam: Kendi ikincil lokasyonunuz, kiralanan kabin veya bulut tabanlı DRaaS.
• Bağlantı: Replikasyon için yeterli bant genişliği ve yedekli internet hatları.
• Test sıklığı ve işletme emeği: Düzenli testler için ayrılan zaman ve varsa test başına hizmet bedelleri.

Bir DR hizmet sağlayıcısı seçerken şunları sorun: Veri hangi ülkede ve hangi veri merkezinde tutulacak? Kurtarma süreleri sözleşmede taahhüt ediliyor mu? Yılda kaç test hakkınız var ve testler ücretli mi? Felaket anında sizinle kim, hangi kanaldan çalışacak? Hizmetten ayrılmak istediğinizde veriniz hangi formatta teslim edilecek? Bankacılık ve sigorta gibi düzenlemeye tabi sektörlerde bu soruların yanıtları denetim dosyasının da parçası olur; bu sektörlere yönelik yaklaşımımızı bankacılık ve sigorta sayfamızda bulabilirsiniz.

Sonuç

Felaket kurtarma planı, yaşanması istenmeyen bir günün sigortasıdır ve değeri ancak test edildiğinde ortaya çıkar. Sunucu kurulum ve altyapı hizmetlerimiz kapsamında risk analizinden DR ortamının kurulmasına ve düzenli testlere kadar süreci uçtan uca yürütebiliriz. Mevcut hazırlık düzeyinizi birlikte görmek için bizimle ücretsiz bir ön görüşme yapın.