Yük Devretme Sınaması: Masa Başı Çalışmaları ve DR Tatbikatları

Hiç sınanmamış bir felaket kurtarma planı yalnızca bir belgedir — gerçek güvence sağlamadan yanlış bir güven duygusu verir. Gerçek felaketler sırasında keşfedilen ancak sınanmamış planlarda ortaya çıkmayan yaygın sorunlar şunlardır: güncel olmayan iletişim listeleri (kilit personelin görevleri değişmiş veya kurumdan ayrılmıştır), yazılım sürümü uyuşmazlıkları nedeniyle başarısız olan backup Restore işlemleri, planın 30 dakika varsaydığı halde Restore edilmesi 4 saat süren sistemler ve hiç kimsenin felaket ilan etme yetkisine kimin sahip olduğunu bilmediği karar yetkisi boşlukları. Sınama, bu sorunları kriz sırasında değil, kontrollü bir ortamda ortaya çıkarır.

DR ve BCP sınaması, karmaşıklığın ve gerçekçiliğin giderek arttığı bir yelpazede gerçekleştirilir. Planların güncel ve eksiksiz olduğunu doğrulayan belge incelemesi, asgari temel düzeydir. Tabletop çalışmaları, herhangi bir sistemi etkinleştirmeden tartışma yürütmeyi içerir. Adım adım uygulama tatbikatlarında katılımcılar prosedürleri sözlü olarak izler. İşlevsel tatbikatlar, belirli bileşenleri etkinleştirir (çağrı zincirleri, kısmi sistem yük devretmeleri). Tam kapsamlı sınamalar, gerçekten DR altyapısına geçmeyi ve işi alternatif tesisten yürütmeyi içerir. Her kademe, daha yüksek maliyet ve kesinti karşılığında daha fazla güven sağlar.

Tabletop çalışması, gerçek sistemleri etkinleştirmeden, kilit paydaşları varsayımsal bir felaket senaryosunu sözlü olarak ele almak üzere bir araya getirir. Kolaylaştırıcı senaryoyu sunar: “Pazartesi sabahı bir uyarı alıyorsunuz: ransomware birincil veritabanı sunucusunu şifrelemiş ve Network üzerinden yayılıyor. Ne yaparsınız?” Katılımcılar gerçek zamanlı yanıt verir; böylece operasyonel bir kesintiye yol açmadan karar yetkisi, iletişim protokolleri ve kurtarma prosedürleri bilgisi konusundaki boşluklar ortaya çıkar.

İşlevsel tatbikatlar, DR planının belirli bileşenlerini tam etkinleştirme olmadan sınar. Örnekler: çağrı zinciri sınaması (numaraların doğru olduğunu ve personelin hedef süre içinde yanıt verdiğini doğrulamak için tüm acil durum kişilerini gece saat 2'de gerçekten arama), backup Restore sınaması (bir veritabanını backup'tan bir sınama ortamına geri yükleyip veri bütünlüğünü doğrulama), yük devretme sınaması (tek bir kritik olmayan uygulamayı DR tesisine geçirme) ve iletişim sistemi sınaması (örnek bir olayı koordine etmek için bant dışı iletişim kanalını kullanma). Her işlevsel tatbikat, planın belirli bir bileşenini doğrular.

Tam kapsamlı bir DR tatbikatı, Production operasyonlarını gerçekten DR tesisine geçirir ve tüm kurtarma zincirinin çalıştığını doğrular. Kuruluş alternatif tesisi etkinleştirir, sistemleri backup'lar üzerinden yükler, DNS'yi DR ortamına yönlendirir ve gerçek iş operasyonlarını yürütmeyi dener. Tam kapsamlı sınamalar şu kritik soruları yanıtlar: Eksiksiz kurtarma gerçekte ne kadar sürer? Tüm uygulamalar DR tesisinde çalışabilir mi? Tüm Network yapılandırmaları doğru mu? İzleme ve uyarı araçları DR ortamında çalışıyor mu? Bu sınamalar maliyetli ve kesintiye yol açıcıdır ancak en yüksek güven düzeyini sağlar.

DR tatbikatları, gerçek performansı RTO ve RPO hedeflerine göre ölçmelidir. Tatbikat sırasında şunları kaydedin: her sistemin DR sitesinde etkinleştirildiği zamanı, ilk kullanıcının başarıyla kimlik doğrulayıp her uygulamayı kullanabildiği zamanı, sistemler çevrimiçi olduğunda verilerin ne kadar eski olduğunu ve 'felaket ilan edildi' anından 'operasyonlar geri yüklendi' anına kadar geçen toplam süreyi. Bunları RTO ve RPO hedefleriyle karşılaştırın. Hedef performans ile gerçek performans arasındaki her fark, bir sonraki tatbikattan önce yapılması gereken belirli bir iyileştirmeyi gösterir.

Sonuç ne olursa olsun her DR tatbikatı bir After-Action Report (AAR) oluşturmalıdır. AAR şunları belgeler: hangi senaryoların test edildiğini, nelerin iyi çalıştığını, nelerin başarısız olduğunu veya planlanandan uzun sürdüğünü, belirlenen belirli eksiklikleri ve sorumluları ile hedef tamamlanma tarihleri atanmış önceliklendirilmiş iyileştirme listesini. AAR, programın olgunluğunu göstermek ve belirlenen eksiklikler için yatırım yapılmasını gerekçelendirmek amacıyla üst düzey yöneticilerle paylaşılır. AAR eylem maddeleri için belgelenmiş bir takip yapılmadığında tatbikatlar, hiçbir zaman giderilmeyen sorunları ortaya çıkarır.

Tam kapsamlı DR testleri iki yaklaşımdan birini kullanır. Geçiş testi, üretim trafiğini gerçekten DR sitesine yönlendirir; gerçekçidir ancak DR sitesi başarısız olursa uzun süreli kesintiye neden olabileceğinden yüksek risk taşır. Paralel test, DR ortamını üretim ortamının yanında çalıştırır ve üretim gerçek kullanıcılara hizmet vermeyi sürdürürken test trafiğini DR'ye yönlendirir; üretim çalışmaya devam ettiği için düşük riskle DR işlevselliğini doğrular. Çoğu kuruluş, kritik sistemlerde paralel testi; daha az kritik sistemlerde veya planlı bakım pencerelerinde geçiş testini kullanır.

Açık bir felaket ilan etme süreci gereklidir; DR'nin ne zaman etkinleştirileceği konusundaki belirsizlikler tehlikeli gecikmelere yol açar. Planlar, DR etkinleştirmesini otomatik olarak tetikleyen belirli ve ölçülebilir ölçütler tanımlamalıdır: 'Birincil veri merkezi 2 saatten uzun süre erişilemez durumdaysa' veya 'Üretim sunucularının %50'sinden fazlası kullanılamıyorsa.' Plan ayrıca felaket ilan etme yetkisinin kimde olduğunu (genellikle CIO veya CTO; bu kişiler erişilebilir değilse adı belirlenmiş bir yedek yetkiliyle birlikte), bu yetkiliye ulaşılabilecek 7/24 bir iletişim numarasını ve birincil yetkiliye ulaşılamadığında izlenecek açık bir üst makama bildirim yolunu tanımlamalıdır.

Test sıklığı, sistemlerin kritikliğine ve ortamın değişim hızına uygun olmalıdır. Sektördeki en iyi uygulamalar şunlardır: masa başı tatbikatları üç ayda bir (düşük maliyetli, yüksek değerli ve becerileri güncel tutar), işlevsel tatbikatlar altı ayda bir (belirli bileşenleri test eder), tam kapsamlı DR tatbikatları yılda bir (planın tamamını doğrular) ve önceden duyurulmayan testler yılda en az bir kez (ekibin önceden hazırlık yapmadan yanıt verip veremediğini test eder). Bulut geçişi, yeni uygulama dağıtımı veya veri merkezi taşınması gibi önemli tüm altyapı değişiklikleri güncellenmiş bir DR testini tetiklemelidir.

Birçok düzenleyici çerçeve, DR testlerini belirli sıklık ve belgelendirme gereksinimleriyle zorunlu kılar. HIPAA, kapsam dahilindeki kuruluşların acil durum planlarını düzenli aralıklarla test etmesini ve gözden geçirmesini gerektirir. PCI-DSS 12.10 Gereksinimi, olay müdahale planının en az yılda bir kez ve önemli değişikliklerin ardından test edilmesini gerektirir. Bankalara yönelik FDIC ve OCC kılavuzları, yönetim kuruluna raporlama ile birlikte yıllık BCP testi yapılmasını gerektirir. SOC 2 Type II denetçileri, BCP/DRP test sıklığına, sonuçlarına ve belirlenen eksikliklerin giderilmesine ilişkin kanıtları inceler. Tüm testlerin, sonuçların ve düzeltici eylemlerin belgelenmiş kanıtlarını denetçilerin incelemesi için saklayın.

Bu dersteki CompTIA Security+ (SY0-701) kavramlarını anlayıp anlamadığınızı test edin.

Bu derste şunları öğrendiniz: DR testi, gerçekçilik ve maliyetin artış sırasına göre masa başı görüşmelerinden işlevsel tatbikatlara ve tam kapsamlı tatbikatlara ilerler; belirli eksiklikleri belirlemek için her test gerçek performansı RTO ve RPO hedeflerine göre ölçmelidir ve atanmış eylem maddelerini içeren After-Action Report raporları, belirlenen zayıflıkların bir sonraki olaydan önce giderilmesini sağlar. İş Sürekliliği ve Felaket Kurtarma modülünü tamamladığınız için tebrikler — artık gelişmiş tehdit konularına geçmeye hazırsınız.