Felaket Kurtarma Planı Nasıl Hazırlanır? Adım Adım Rehber

Bir sunucu odasında çıkan yangın, fidye yazılımının şifrelediği dosya sunucusu ya da tek bir hatalı güncelleme, işletmenin saatlerce hatta günlerce durmasına yol açabilir. Böyle bir anda neyin, hangi sırayla ve kim tarafından geri getirileceğini önceden yazıya döken belge felaket kurtarma planıdır. İyi hazırlanmış bir DR planı, BT ekiplerinin kriz anında doğaçlama yapmasını engeller ve kurtarma süresini ölçülebilir hedeflere bağlar.

Bu rehber; planın amacını, RTO ve RPO hedeflerinin nasıl belirlendiğini, adım adım hazırlık sürecini, örnek plan başlıklarını ve planın nasıl test edileceğini ele alıyor. Yalnızca yedek almakla gerçek bir kurtarma kabiliyetine sahip olmak arasındaki farkı ve kendi felaket kurtarma merkezini kurmak ile DRaaS hizmeti almak arasındaki seçimi de karşılaştırıyor.

Felaket Kurtarma Planı Nedir ve Neden Gereklidir?

Felaket kurtarma planı, BT altyapısının beklenmedik bir kesinti sonrasında önceden tanımlanmış süre ve veri kaybı sınırları içinde yeniden çalışır hale getirilmesini sağlayan yazılı prosedürler bütünüdür. Planın odağı teknoloji tarafıdır: sunucular, veritabanları, ağ bağlantıları, uygulamalar ve bunların geri getirilme sırası. İş sürekliliği planı ise daha geniş bir çerçevedir ve personel, tedarik zinciri, iletişim ve alternatif çalışma yerleri gibi konuları da kapsar.

ABD Ulusal Standartlar ve Teknoloji Enstitüsü’nün NIST SP 800-34 Rev. 1 Contingency Planning Guide dokümanı, bilgi sistemleri için acil durum planlamasını iş etki analiziyle başlayan, önleyici kontrollerle devam eden ve düzenli testlerle olgunlaşan bir süreç olarak tanımlar. Bu yaklaşım, planın bir kez yazılıp rafa kaldırılan bir belge olmadığını gösterir. Planın hazırlanmasını gerektiren başlıca kesinti türleri şunlardır:

• Siber saldırılar: Fidye yazılımı, veri silme saldırıları ve yetkisiz erişim.
• Donanım ve altyapı arızaları: Depolama ünitesi, sunucu, güç kaynağı veya soğutma sorunları.
• İnsan kaynaklı hatalar: Yanlış silinen veri, hatalı yapılandırma veya başarısız güncelleme.
• Fiziksel olaylar: Yangın, su baskını, deprem ve uzun süreli elektrik kesintisi.
• Hizmet sağlayıcı kesintileri: İnternet bağlantısı veya kritik bir SaaS hizmetinin erişilemez olması.

Türkiye gibi deprem riski yüksek bir coğrafyada, tek bir binada tutulan sunucu ve yedeklerin aynı olaydan etkilenme ihtimali plan hazırlığında ayrıca dikkate alınmalıdır.

RTO ve RPO: Planın Ölçülebilir Hedefleri

Her DR planı iki temel metriğe dayanır. RTO (Recovery Time Objective), bir sistemin kesintiden sonra en geç ne kadar sürede yeniden hizmet vermesi gerektiğini ifade eder. RPO (Recovery Point Objective) ise kabul edilebilir en fazla veri kaybını zaman cinsinden tanımlar; RPO dört saat ise son dört saatlik verinin kaybı tolere edilebilir demektir.

RTO ve RPO değerleri BT ekibinin tahminiyle değil, iş birimlerinin kesintinin maliyetini ve etkisini değerlendirmesiyle belirlenir. Tüm sistemlere aynı hedefi vermek ya gereksiz maliyet ya da kritik sistemlerde yetersiz koruma anlamına gelir. Aşağıdaki tablo, sistemlerin sınıflandırılmasında kullanılabilecek örnek bir yapıyı gösterir; değerler bağlayıcı değildir, her kurum kendi iş etki analizine göre uyarlamalıdır.

RTO ve RPO değeri küçüldükçe gereken altyapı yatırımı artar. Bu yüzden sınıflandırma, bütçe ile risk arasındaki dengeyi kurmanın en pratik aracıdır.

Felaket Kurtarma Planı Nasıl Hazırlanır? Adım Adım Süreç

Hazırlık süreci, kurumun büyüklüğünden bağımsız olarak benzer aşamalardan geçer. Küçük bir işletmede birkaç haftada tamamlanabilecek adımlar, çok lokasyonlu bir yapıda aylara yayılabilir.

1. Kapsam ve sorumluluk: Planın hangi sistemleri kapsadığı, planın sahibinin kim olduğu ve kriz anında karar yetkisinin kimde bulunduğu belirlenir.
2. Varlık envanteri: Sunucular, sanal makineler, veritabanları, uygulamalar, lisanslar ve bunlar arasındaki bağımlılıklar listelenir.
3. İş etki analizi (BIA): Her iş sürecinin kesintiden nasıl etkileneceği, finansal ve operasyonel etkileri değerlendirilir; RTO ve RPO değerleri bu analizden çıkar.
4. Risk değerlendirmesi: Olası tehditler ve bunların gerçekleşme ihtimali ortaya konur.
5. Kurtarma stratejisi: Yedekleme, replikasyon, yedek lokasyon veya DRaaS gibi teknik seçenekler sistem sınıflarına göre eşleştirilir.
6. Prosedürlerin yazılması: Her sistem için adım adım kurtarma talimatı, geri getirme sırası ve doğrulama kontrolleri yazılır.
7. İletişim planı: Çalışanlara, müşterilere, tedarikçilere ve gerekirse düzenleyici kurumlara kimin, hangi kanaldan bilgi vereceği tanımlanır.
8. Test ve güncelleme: Plan tatbikatlarla doğrulanır, her altyapı değişikliğinden sonra güncellenir.

Bu adımlardan en sık atlananı bağımlılık analizidir. Bir uygulama sunucusu geri gelse bile kimlik doğrulama servisi, DNS veya lisans sunucusu hazır değilse sistem kullanılamaz. Kurtarma sırası bu bağımlılıklara göre kurulmalıdır.

Felaket Kurtarma Planı Örneği: Belgede Hangi Başlıklar Olmalı?

Standart bir şablon her kuruma birebir uymaz, ancak iyi bir felaket kurtarma planı örneği incelendiğinde belirli bölümlerin tekrarlandığı görülür. Aşağıdaki başlıklar, planın okunabilir ve uygulanabilir olması için temel bir iskelet sunar:

• Amaç, kapsam ve varsayımlar: Planın hangi senaryolarda devreye gireceği ve hangi sistemleri kapsadığı.
• Roller ve iletişim listesi: Kurtarma ekibi, yedek kişiler, tedarikçi ve hizmet sağlayıcı irtibatları.
• Planın devreye alınma kriterleri: Hangi durumda felaket ilan edileceği ve bu kararı kimin vereceği.
• Sistem envanteri ve sınıfları: RTO ve RPO hedefleriyle birlikte öncelik sırası.
• Kurtarma prosedürleri: Her sistem için teknik adımlar, erişim bilgilerinin nerede tutulduğu ve doğrulama kontrolleri.
• Geri dönüş (failback) prosedürü: Ana lokasyon onarıldığında sistemlerin nasıl geri taşınacağı.
• Test takvimi ve revizyon geçmişi: Son tatbikatın tarihi, sonuçları ve yapılan düzeltmeler.

Planın basılı veya çevrim dışı erişilebilir bir kopyasının bulunması da önemlidir. Kurumsal dosya sunucusunda duran bir plan, o sunucu erişilemez olduğunda okunamaz.

Sadece Yedekleme mi, Gerçek DR Planı mı? Genel Uygulama ve Doğru Yaklaşım

Pek çok işletmede genel uygulama, gece alınan yedeklerin felaket kurtarma için yeterli olduğunu varsaymaktır. Yedekleme verinin bir kopyasını korur; felaket kurtarma ise o verinin hangi altyapıda, ne kadar sürede ve hangi sırayla tekrar çalışır hale geleceğini tanımlar. Birkaç terabaytlık bir yedeği yavaş bir bağlantı üzerinden geri yüklemek günler sürebilir ve bu süre çoğu zaman RTO hedefinin çok üzerindedir.

Doğru yaklaşım, yedeklemeyi planın bir bileşeni olarak konumlandırmaktır. İki model arasındaki temel farklar şöyle özetlenebilir:

• Genel uygulama: Yedekler aynı binada, aynı etki alanında tutulur; geri yükleme hiç denenmemiştir; hedef süre tanımlı değildir.
• Doğru yaklaşım: Bulut veri yedekleme ile yedekler farklı lokasyona taşınır, kritik sistemler replike edilir, geri yükleme düzenli test edilir ve süreler RTO ile karşılaştırılır.
• Fidye yazılımı dayanıklılığı: Doğru yaklaşımda en az bir yedek kopya değiştirilemez (immutable) veya ağdan yalıtılmış tutulur.

Fidye yazılımı saldırganlarının öncelikli hedeflerinden biri yedeklerdir. Modern bir plan, bu riske karşı immutable backup gibi silinemeyen ve değiştirilemeyen bir yedek katmanını da içermelidir.

Kendi Felaket Kurtarma Merkezi mi, DRaaS mı?

Kritik sistemler için dakikalar mertebesinde RTO hedefleniyorsa yedek bir lokasyonda çalışmaya hazır altyapı gerekir. Bunun iki yolu vardır: kurumun kendi felaket kurtarma merkezini kurması veya bu altyapıyı hizmet olarak (DRaaS) alması. Kendi merkezini kuran kurum ikinci bir veri merkezi alanı, donanım, lisans, bağlantı ve bu ortamı güncel tutacak personel yükünü üstlenir.

DRaaS modelinde ise replikasyon hedefi hizmet sağlayıcının veri merkezindeki bulut altyapısıdır. Veeam gibi platformlar, Veeam Backup & Replication kullanıcı kılavuzunda anlatıldığı şekilde sanal makinelerin kopyalarını hedef ortamda hazır tutar ve gerektiğinde bu kopyalara geçiş (failover) yapılmasını sağlar. Kurum yalnızca ihtiyaç duyduğu kapasite için ödeme yapar ve donanım yenileme yükünü taşımaz.

Seçimde belirleyici olan; hedef RTO, veri hacmi, mevzuat gereksinimleri ve kurum içinde bu ortamı yönetecek uzmanlığın bulunup bulunmadığıdır. Çok sayıda işletme için karma model de mantıklıdır: kritik sistemler bulut veri replikasyonu ile sürekli kopyalanırken daha az kritik sistemler yalnızca yedeklenir.

Felaket Kurtarma Senaryosu ve Tatbikat: Plan Nasıl Test Edilir?

Test edilmemiş bir plan, yalnızca bir varsayımdır. Tatbikatlar, prosedürlerdeki eksikleri, güncelliğini yitirmiş erişim bilgilerini ve gerçekçi olmayan RTO hedeflerini kriz yaşanmadan ortaya çıkarır. Her tatbikat belirli bir felaket kurtarma senaryosu üzerine kurulmalıdır; örneğin “ana veri merkezinde elektrik kesintisi” veya “dosya sunucusunun fidye yazılımıyla şifrelenmesi”.

Test yöntemleri kapsam ve risk açısından farklılık gösterir:

• Masa başı tatbikat: Ekip bir senaryo üzerinden plan adımlarını sözlü olarak yürütür; rol ve iletişim eksiklerini bulmak için uygundur.
• Kısmi geri yükleme testi: Seçilen sistemler izole bir ortamda yedekten geri getirilir ve süreler ölçülür.
• Failover testi: Replike sistemler yedek lokasyonda gerçekten çalıştırılır, uygulama bütünlüğü doğrulanır.
• Tam kapsamlı tatbikat: Üretim ortamının belirli bir bölümü planlı olarak yedek lokasyona taşınır ve geri döndürülür.

Her testin sonunda ölçülen süreler hedeflerle karşılaştırılmalı, sapmalar kayıt altına alınmalı ve plan revize edilmelidir. Yılda en az bir kapsamlı test ile altyapı değişikliklerinden sonra yapılan kısmi testler iyi bir başlangıç ritmidir.

Sık Yapılan Hatalar ve Doğru Yöntem

Plan hazırlığında karşılaşılan sorunların büyük kısmı teknik değil, süreçseldir. Aşağıdaki hatalar, kriz anında planın işlememesinin en yaygın nedenleri arasındadır:

• Yedeği aynı lokasyonda tutmak: Doğru yöntem, en az bir kopyanın coğrafi olarak ayrı bir veri merkezinde bulunmasıdır.
• Yönetim kimlik bilgilerini tek yerde toplamak: Saldırgan yedekleme konsoluna erişirse tüm kopyaları silebilir; ayrı kimlik bilgileri ve çok faktörlü doğrulama kullanılmalıdır.
• Geri yüklemeyi hiç denememek: CISA’nın #StopRansomware rehberi, çevrim dışı ve şifreli yedeklerin tutulmasını ve bunların kurtarma senaryosunda düzenli olarak test edilmesini önerir.
• Planı güncellememek: Yeni uygulamalar ve sunucular plana eklenmezse envanter kısa sürede eskir.
• Geri dönüşü unutmak: Yedek lokasyona geçiş planlanır ama ana lokasyona dönüş adımları yazılmaz.

Bu hataların ortak çözümü, planın sahibinin belli olması ve plan gözden geçirmelerinin takvime bağlanmasıdır.

Türkiye’de Veri Lokasyonu, KVKK ve İş Sürekliliği

Kişisel veri işleyen kurumlar için felaket kurtarma planı yalnızca teknik bir belge değildir. 6698 sayılı Kişisel Verilerin Korunması Kanunu, veri sorumlularının kişisel verilerin güvenliğini sağlamak için uygun teknik ve idari tedbirleri almasını bekler. Yedeklerin ve replikasyon hedefinin nerede bulunduğu, kimlerin erişebildiği ve verinin yurt dışına aktarılıp aktarılmadığı bu değerlendirmenin parçasıdır.

Türkiye lokasyonlu bir veri merkezinde tutulan yedek ve replika kopyalar, yurt dışı aktarım değerlendirmelerini sadeleştirir ve düşük gecikmeyle daha hızlı geri yükleme imkânı sunar. İstanbul merkezli kurumlar için ise farklı bir bölgede veya farklı bir veri merkezi binasında tutulan kopya, bölgesel afet riskine karşı ayrı bir güvence katmanı oluşturur. Bu bölümdeki bilgiler genel niteliktedir ve hukuki danışmanlık yerine geçmez.

MAV Cloud ile Felaket Kurtarma: Standartlar, SLA Hedefi ve Süreç

Bir hizmet sağlayıcıya kurtarma altyapısı emanet edilirken belgelenmiş süreçler ve bağımsız denetimden geçmiş standartlar belirleyicidir. MAV Cloud, iş sürekliliği yönetim sistemleri standardı olan ISO 22301 dahil olmak üzere ISO/IEC 27001, ISO/IEC 27701, ISO 9001 ve ISO/IEC 20000 sertifikalarına sahiptir. Hizmet yaklaşımının temel unsurları şunlardır:

• Altyapı: Türkiye lokasyonlu Equinix veri merkezi, VMware sanallaştırma ve Veeam tabanlı yedekleme ile replikasyon.
• SLA hedefi: Aylık %99,9 erişilebilirlik hedefi; kritik taleplerde 15 dakika, yüksek öncelikli taleplerde 1 saat ilk müdahale hedefi.
• Destek ve izleme: 7/24 uzman destek ve 7/24 sistem izleme.
• Süreç: Envanter ve iş etki analizi, RTO ve RPO hedeflerinin belirlenmesi, replikasyon ve yedekleme kurulumu, ardından planlı tatbikatlar.

Hizmetin kapsamı ve teknik ayrıntıları felaket kurtarma (DRaaS) hizmeti sayfasında yer alır.

Sıkça Sorulan Sorular

Felaket kurtarma planı ile iş sürekliliği planı arasındaki fark nedir?

Felaket kurtarma planı BT sistemlerinin ve verinin geri getirilmesine odaklanır. İş sürekliliği planı ise personel, tedarik zinciri, iletişim ve alternatif çalışma düzeni gibi konuları da kapsayan daha geniş bir çerçevedir; DR planı onun teknik bileşenidir.

RTO ve RPO değerleri nasıl belirlenir?

Değerler iş etki analiziyle belirlenir. Her iş sürecinin kesinti süresine ve veri kaybına ne kadar tolerans gösterebileceği, iş birimleriyle birlikte değerlendirilir ve sistemler bu toleranslara göre sınıflandırılır.

Felaket kurtarma planı ne sıklıkla test edilmeli?

Genel kabul gören yaklaşım yılda en az bir kapsamlı tatbikat yapılması ve önemli altyapı değişikliklerinden sonra kısmi testlerle doğrulama yapılmasıdır. Kritik sistemlerde test sıklığı artırılabilir.

Sadece yedekleme almak felaket kurtarma için yeterli mi?

Çoğu durumda yeterli değildir. Yedek verinin kopyasını korur ancak geri yükleme süresi, hedef altyapı ve kurtarma sırası tanımlanmadıkça RTO hedefine ulaşılamayabilir. Kritik sistemler için replikasyon ve yedek lokasyonda hazır altyapı gerekir.

DRaaS nedir, hangi işletmeler için uygundur?

DRaaS, felaket kurtarma altyapısının hizmet sağlayıcıdan hizmet olarak alınmasıdır. İkinci bir veri merkezi kurmak ve yönetmek istemeyen, ancak kritik sistemleri için kısa kurtarma süreleri hedefleyen işletmeler için uygundur.

Felaket kurtarma merkezi Türkiye’de mi olmalı?

Kişisel veri işleyen kurumlar için Türkiye lokasyonu, yurt dışı aktarım değerlendirmelerini sadeleştirir ve daha düşük gecikme sağlar. Kesin gereklilik sektöre ve veri türüne göre değişir; hukuki değerlendirme ayrıca yapılmalıdır.

ISO 22301 felaket kurtarma planı için zorunlu mu?

ISO 22301 yasal bir zorunluluk değil, iş sürekliliği yönetim sistemleri için uluslararası bir standarttır. Hizmet sağlayıcı seçerken bu sertifikanın bulunması, iş sürekliliği süreçlerinin bağımsız olarak denetlendiğini gösterir.

Fidye yazılımı senaryosu DR planında nasıl ele alınır?

Plan, temiz bir kurtarma noktasının nasıl belirleneceğini, değiştirilemez yedeklerin nerede tutulduğunu ve etkilenen sistemlerin izole edilme adımlarını içermelidir. Geri yükleme öncesinde yedeklerin zararlı yazılım açısından kontrol edilmesi de prosedüre eklenmelidir.

Konuyu araştırma aşamasında olan kurumlar için ilk adım, sistem envanterini çıkarıp her sistem için kabul edilebilir kesinti süresini sormaktır. Hangi modelin uygun olduğu konusunda kararsız kalan BT ekipleri, mevcut yedeklerden birini izole bir ortamda geri yükleyip süreyi ölçerek gerçekçi bir başlangıç noktası elde edebilir. Planı hayata geçirmeye hazır olan işletmeler ise MAV Cloud ekibiyle iş etki analizi ve DRaaS kurgusunu birlikte planlayabilir.