Kısaca
Felaket kurtarma planı (DR), kritik sistemlerin büyük bir arıza, afet veya siber saldırı sonrasında belirli bir sürede ve kabul edilebilir veri kaybıyla yeniden çalıştırılması için hazırlanan teknik plan ve altyapıdır. Sunucuları ve verisi kendi bünyesinde olan şirketler içindir. CybUp; RPO/RTO hedeflerini belirler, replikasyon ve değiştirilemez yedek kurar, adım adım kurtarma dokümanı yazar ve düzenli test yapar.
Felaket kurtarma planı nedir, yedeklemeden farkı ne?
Yedekleme verinin bir kopyasının alınmasıdır; felaket kurtarma ise o kopyadan işin ne kadar sürede, hangi sırayla ve nerede yeniden ayağa kaldırılacağının planıdır. Yedeği olan ama hangi sunucunun önce açılacağını, DNS’in nasıl değişeceğini, kullanıcıların hangi adrese bağlanacağını bilmeyen bir şirket, felaket anında saatlerini bu soruların cevabını aramakla geçirir.
Plan iki şeyi bir araya getirir: altyapı (ikinci lokasyon, replikasyon, değiştirilemez yedek) ve prosedür (kim neyi hangi sırayla yapacak). İkisinden biri eksikse plan çalışmaz. Altyapı tarafının temeli için Veeam Backup kurulumu sayfamıza bakabilirsiniz.
RPO ve RTO nedir, nasıl belirlenir?
RPO (Recovery Point Objective), kabul edebileceğiniz en fazla veri kaybıdır ve zaman cinsinden ifade edilir. RPO dört saat ise felaket anında en fazla son dört saatin verisini kaybetmeyi göze almışsınız demektir. RTO (Recovery Time Objective) ise sistemin yeniden kullanılabilir hale gelmesi için kabul ettiğiniz en uzun süredir.
Her sistem için ayrı belirlenir ve hedefin sıkılaştıkça maliyeti artar. ERP veritabanı için 15 dakikalık RPO ve iki saatlik RTO gerekirken, arşiv dosya sunucusu için bir günlük RPO ve iki günlük RTO yeterli olabilir. Bu rakamları biz uydurmuyoruz; departman yöneticileriyle “bu sistem yarım gün kapalı kalırsa ne olur?” sorusunu konuşarak sizinle birlikte çıkarıyoruz.
Hedef belirlendikten sonra teknik karşılığı seçilir. Gece alınan yedek 24 saatlik RPO verir. Hyper-V Replica 30 saniye, 5 dakika veya 15 dakikalık aralıklarla kopya gönderir. Veritabanı düzeyinde replikasyon daha da düşük RPO sağlayabilir.
DR lokasyonu mu, bulut mu?
İkinci lokasyon şirketin başka bir binası, bir şube ya da bir veri merkezinde kiralanmış kabinet olabilir. Avantajı, verinin sizin kontrolünüzde ve yüksek hızlı yerel ağda olmasıdır; dezavantajı ikinci bir donanım setinin satın alınıp bakımının yapılmasıdır. İstanbul’daki merkez ile aynı fay hattında, aynı elektrik dağıtım bölgesinde bir yedek lokasyon da her senaryoyu karşılamaz; bunu planlamada açıkça konuşuyoruz.
Bulut tarafında Azure Site Recovery, şirket içindeki VMware ve Hyper-V sanal makinelerini ve fiziksel sunucuları Azure’a sürekli replike edebiliyor, üretimi etkilemeden tatbikat yapılmasına izin veriyor. Felaket anında makineler Azure’da açılıyor. Bu durumda Azure aboneliği sizin adınıza sizin hesabınızda açılır; detaylar için Azure ve AWS kurulumu sayfamıza bakabilirsiniz. Verinin yurt dışındaki bir bölgede tutulması KVKK açısından ayrıca değerlendirilmelidir.
Fidye yazılımına karşı yedek nasıl korunur?
Fidye yazılımı saldırılarında saldırganlar dosyaları şifrelemeden önce yedekleri bulup silmeye çalışır. ABD siber güvenlik ajansı CISA’nın fidye yazılımı rehberi bu yüzden kritik verinin çevrimdışı, şifreli yedeklerinin tutulmasını ve bu yedeklerin bir felaket senaryosunda düzenli olarak test edilmesini öneriyor. Rehber ayrıca kritik sistemler için hazır “altın imajlar” tutulmasını tavsiye ediyor.
Bizim uyguladığımız katmanlar şunlar: yedek sunucusunun etki alanından ayrılması, değiştirilemez (immutable) depo, en az bir kopyanın ağdan erişilemeyen ya da nesne kilitli bir hedefte durması, yedek yönetimi için çok faktörlü kimlik doğrulama ve yedek işlerinde beklenmedik silme ya da değişiklik olduğunda uyarı. Microsoft’un fidye yazılımına hazırlık rehberi de kritik sistem yedeklerinin saldırganın kasıtlı silme ve şifreleme girişimlerine karşı korunmasını, en güçlü seçenek olarak değiştirilemez ya da tamamen çevrimdışı depolamayı öneriyor; kurtarma prosedürü dokümanlarının ve ağ şemalarının da saldırıdan sağ çıkacak bir yerde tutulmasını istiyor.
- Etki alanından ayrı yedek sunucusu ve ayrı yönetici hesabı
- Değiştirilemez depo veya nesne kilitli bulut kopyası
- Çevrimdışı ya da ağdan yalıtılmış en az bir kopya
- Yedek yönetimine çok faktörlü kimlik doğrulama
- Düzenli geri yükleme tatbikatı ve sonuç raporu
“It is important that backups are maintained offline, as many ransomware variants attempt to find and subsequently delete or encrypt accessible backups to make restoration impossible unless the ransom is paid.”
Yedeklerin çevrimdışı tutulması önemlidir; çünkü birçok fidye yazılımı türü, fidye ödenmedikçe geri yüklemeyi imkânsız kılmak için erişilebilir yedekleri bulup silmeye veya şifrelemeye çalışır.
Saldırı sonrası teknik kurtarma nasıl yürür?
Bir fidye yazılımı olayından sonra ilk iş, etkilenen sistemleri ağdan ayırmak ve temiz olduğundan emin olunan bir ortam hazırlamaktır. Yedekten geri dönüşü, saldırganın hâlâ içeride olduğu bir ağa yapmak aynı saldırıyı ikinci kez yaşamak demektir. Bu yüzden kurtarmayı yalıtılmış bir ağda, temiz imajlardan kurulan sunucularla ve parolaları değiştirilmiş hesaplarla yapıyoruz; etki alanı denetleyicisi ve kimlik sistemi her zaman ilk sıradadır.
Burada sınırımızı net çizelim: şifrelenmiş dosyaların çözülmesini vaat etmiyoruz, fidye pazarlığına girmiyoruz, adli bilişim (forensic) incelemesi yapmıyoruz. Bu işler için siber olay müdahale konusunda uzmanlaşmış firmalar ve hukuk danışmanınızla çalışmanızı öneririz; KVKK kapsamındaki bildirim yükümlülükleri de bu sürecin parçasıdır. Bizim rolümüz, temiz yedeklerden altyapıyı sırasıyla ayağa kaldırmak ve bir sonraki olaya karşı yapıyı sağlamlaştırmaktır.
“Reconnect systems and restore data from offline, encrypted backups based on a prioritization of critical services.”
Sistemleri kritik hizmetlerin önceliklendirmesine göre yeniden bağlayın ve verileri çevrimdışı, şifreli yedeklerden geri yükleyin.
Runbook nedir, felaket kurtarma testi ne sıklıkla yapılmalı?
Runbook, felaket anında izlenecek adımların sırasıyla yazıldığı belgedir: hangi sistem önce açılır, hangi IP ve DNS değişiklikleri yapılır, kim hangi kararı verir, kullanıcılara ne duyurulur. Yazıldığı gün mükemmel olan runbook, altı ay sonra yeni bir sunucu eklendiğinde eskir. Bu yüzden runbook’u değişiklik yönetiminize bağlıyoruz.
Test sıklığı sistemin önemine göre değişir. Önerimiz, otomatik yedek testlerinin her hafta, seçili sistemlerin tatbikatlı geri dönüşünün üç ayda bir, tüm planın yılda en az bir kez masa başı ve teknik tatbikatla denenmesidir. Örneğin 150 çalışanlı bir üretim firmasında yılda bir cumartesi günü ERP, etki alanı ve dosya sunucusu DR ortamında açılır, birkaç kullanıcı oradan sipariş girer ve ölçülen süre RTO hedefiyle karşılaştırılır. Sapma varsa plan güncellenir.
Teslim ettiklerimiz
- Sistem envanteri, iş etkisi değerlendirmesi ve RPO/RTO tablosu
- İkinci lokasyon veya bulut replikasyon altyapısı
- Fidye yazılımına dayanıklı yedek mimarisi (değiştirilemez ve çevrimdışı kopya)
- Adım adım kurtarma runbook’u ve iletişim planı
- İlk tatbikat ve ölçülen RTO/RPO raporu
- Yıllık test takvimi ve güncelleme süreci
Nasıl çalışıyoruz
- 1
Ücretsiz inceleme
Sistemlerinizi, mevcut yedekleri ve bağımlılıkları çıkarıp en büyük riskleri öncelik sırasıyla raporluyoruz.
- 2
Hedef belirleme
Departman yöneticileriyle her sistem için RPO ve RTO hedeflerini birlikte belirliyoruz.
- 3
Altyapı
Replikasyon, DR lokasyonu veya bulut hedefi, değiştirilemez yedek ve izleme kuruluyor.
- 4
Runbook
Kurtarma adımları, roller ve iletişim planı yazılıyor, sizin ekibinizle gözden geçiriliyor.
- 5
Tatbikat
Plan gerçek bir geri dönüşle test ediliyor, sonuçlar raporlanıyor ve plan güncelleniyor.
Sıkça sorulan sorular
Küçük bir şirketin de felaket kurtarma planına ihtiyacı var mı?
Evet, ama ölçeği farklıdır. Beş sunuculu bir ofis için plan; değiştirilemez bir yedek, bulutta bir kopya ve iki sayfalık bir runbook olabilir. Önemli olan felaket gününde ne yapılacağının önceden yazılmış ve denenmiş olmasıdır.
Fidye yazılımı bulaşırsa dosyalarımızı kurtarabilir misiniz?
Sağlam ve temiz bir yedeğiniz varsa sistemleri o yedekten geri kurarız. Şifrelenmiş dosyaların çözülmesini vaat etmiyoruz ve adli inceleme yapmıyoruz; bu konularda olay müdahale firmalarıyla çalışmanızı öneriyoruz.
RPO sıfır olabilir mi?
Senkron replikasyonla teorik olarak sıfıra yaklaşılabilir ama bu, düşük gecikmeli hat ve özel depolama gerektirir. Çoğu şirket için dakikalar düzeyindeki RPO, maliyet ve karmaşıklık açısından daha dengelidir.
Felaket kurtarma testi üretimi etkiler mi?
Doğru kurgulanmış bir testte etkilemez. Hyper-V Replica, Azure Site Recovery ve Veeam SureBackup gibi araçlar test kopyasını üretim ağından yalıtılmış bir ağda açar.
DR lokasyonu olarak buluta geçmek KVKK’ya aykırı mı?
Kendiliğinden aykırı değildir ama verinin Türkiye dışında bir bölgede tutulması yurt dışına aktarım hükümlerine göre değerlendirilmelidir. Bu hukuki değerlendirmeyi hukuk danışmanınızın yapmasını öneriyoruz; biz bölge seçimi, şifreleme ve erişim kayıtları gibi teknik tedbirleri uyguluyoruz.
Plan ne kadar sürede hazır olur?
Kapsama bağlı olarak birkaç haftadan birkaç aya kadar sürebilir. Değiştirilemez yedek gibi acil kalemleri ilk haftalarda devreye alıp planın geri kalanını aşamalı tamamlıyoruz.
Felaket kurtarma planı ne kadar tutar?
Kapsamı inceledikten sonra yazılı teklif veriyoruz; inceleme ücretsiz. Sistem sayısı, RPO/RTO hedefleri ve DR hedefinin bina mı bulut mu olduğu teklifi belirliyor.