Felaket Kurtarma ve İş Sürekliliği Mühendisliği (DRaaS)

Var. Yedek veriyi geri getiriyor; felaket kurtarma hizmeti geri getiriyor. Aradaki fark, sunucuların, ağın, kimlik altyapısının ve bağımlılık sırasının nerede ve nasıl ayağa kalkacağı.

Bunu somutlaştıran soru şudur: elinizdeki yedekle, sıfırdan bir ortamda, uygulamanızı kaç saatte kullanıcıya açabilirsiniz? Yalnızca yedeği olan kurumlarda bu süre çoğunlukla gün mertebesindedir, çünkü yedekten dönerken sunucu sağlama, IP planı, DNS kayıtları, sertifikalar, lisans anahtarları ve kimlik doğrulama sırayla çözülmek zorundadır ve hiçbiri yedeğin içinde yazılı değildir.

Felaket kurtarma planı tam olarak bu adımları önceden yazıya döker: hangi sistem hangi sırayla kalkar, ağ nereye yönlenir, DNS ne zaman devreder, kim hangi kararı verir. Yedek bu planın malzemesidir, kendisi değil.

İş birimi belirliyor, biz maliyetini ve teknik karşılığını gösteriyoruz.

RPO kaybetmeyi göze aldığınız veri süresidir: RPO 15 dakikaysa, bir felakette son 15 dakikanın verisi kaybolabilir demektir. RTO ise ayakta olmanız gereken süredir. İkisi de teknik değil ticari karardır, çünkü ikisi de doğrudan maliyet demektir.

Yaklaşık ölçek şudur: dakikalık RPO senkron ya da sürekli replikasyon ister ve iki tarafta da hazır kapasite gerektirir. Saatlik RPO periyodik replikasyonla karşılanır ve belirgin biçimde ucuzdur. Günlük RPO çoğu durumda mevcut yedekleme düzeninin üstüne kurulabilir.

Pratikte doğru yöntem tek bir sayı belirlemek değil, sistemleri katmanlara ayırmaktır: ödeme alan sistem ile içerideki raporlama aracı aynı hedefi taşımak zorunda değildir, ve taşımaya çalışmak bütçenin çoğunu yanlış yere harcamak olur. Karar verildiğinde yazılı hâle getirilir; sözlü kalan bir RPO olay anında tartışma konusu olur.

Doğru kurguda etkilemiyor: kurtarma izole bir ağda yapılıyor ve üretimle bağlantı kurulmuyor.

Teknik olarak yapılan şey, replika kopyaların üretimden yalıtılmış bir ağ segmentinde ayağa kaldırılmasıdır. Uygulama gerçekten açılır, kullanıcı girişi denenir, veri bütünlüğü kontrol edilir, ama bu ortam üretim DNS'ine, üretim veritabanına ve dış entegrasyonlara bağlanmaz. Bağlansaydı iki sistemin aynı anda yazması gibi gerçek bir risk doğardı.

Tatbikatın asıl maliyeti sistemde değil takvimdedir: hazırlık, yürütme ve raporlama için ekipten zaman ister. Bu maliyeti kabul etmemenin karşılığı, planın gerçek bir felakette ilk kez denenmesidir; ve o an, denemek için yılın en kötü anıdır.

Kritik sistemler için yılda en az iki kez, ayrıca mimaride önemli bir değişiklik sonrasında.

İkinci koşul çoğu kurumda atlanır ve asıl riski o yaratır. Yeni bir uygulama devreye alındığında, kimlik altyapısı değiştiğinde, veritabanı sürümü yükseltildiğinde ya da ağ topolojisi değiştiğinde plan bir önceki dünyayı anlatıyor olabilir. Altı ay önce çalışan bir devir sırası, araya giren tek bir bağımlılıkla çalışmaz hâle gelir.

Her tatbikatta ölçülen kurtarma süresi kaydedilir. Asıl değerli veri tek bir tatbikatın sonucu değil, bu sürenin zaman içindeki eğilimidir: süre uzuyorsa, ortam plandan uzaklaşıyor demektir ve bunu ancak ölçerek görebilirsiniz.

ISO 22301 kapsamında denetime giriyorsanız tatbikat kaydı zaten isteniyor; aynı çalışma iki işi birden görür.

Şart değil. Bulut tabanlı kurtarma sahası, boşta bekleyen ikinci bir veri merkezinin maliyetini ortadan kaldırıyor; kaynaklar yalnızca tatbikat ve gerçek olay sırasında çalışıyor.

Karşılaştırma şöyle kurulur. Kendi ikincil sahanız, donanımı, alan kirasını, enerjiyi ve bakımı sürekli ödemeniz demektir; buna karşılık kontrol tamamen sizdedir ve veri hiçbir zaman kurum dışına çıkmaz. Bulut tabanlı sahada ise depolama ve replikasyon sürekli, işlem kapasitesi ise yalnızca ihtiyaç anında ücretlendirilir.

Seçimi belirleyen genellikle maliyet değil mevzuattır: verinin hangi ülkede ve hangi tesiste duracağı kısıtlanmışsa, saha seçimi o kısıtla başlar. Bu kısıt yoksa, karar RTO ile bütçe arasındaki dengeye kalır.

Değil, ve karıştırılması pahalı bir hataya yol açıyor.

Yüksek erişilebilirlik (HA) tek bir bileşenin arızasını kurum içinde, çoğunlukla saniyeler içinde karşılar: bir sunucu düşer, cluster devralır. Aynı veri merkezinde, aynı depolama üzerinde çalışır.

Felaket kurtarma ise o veri merkezinin tamamının kaybını karşılar: yangın, sel, uzun süreli enerji kesintisi, ya da tüm ortamı şifreleyen bir fidye yazılımı. HA cluster'ı bu senaryoların hiçbirinde işe yaramaz, çünkü cluster'ın her iki node'u da aynı olaydan etkilenir.

İkisi birbirinin alternatifi değil, farklı katmanlarıdır: HA günlük arızayı görünmez kılar, felaket kurtarma kurumu ayakta tutar.

Bu senaryo, klasik yedeklemenin en zayıf noktasıdır ve tasarımın başında düşünülmesi gerekir.

Fidye yazılımı bugün ortama girdiği anda şifrelemiyor; genellikle haftalarca sessiz kalıp yedekleme altyapısını arıyor. Ağdan erişilebilir bir yedek deposu, saldırganın öncelikli hedefidir, çünkü yedeği kullanılamaz hâle getirdiğinde pazarlık gücü tamamlanır.

Karşı önlem iki katmanlıdır. Birincisi değiştirilemez (immutable) yedek: yazıldıktan sonra belirlenen süre boyunca hiçbir hesabın (yönetici hesabı dahil) silemediği ya da değiştiremediği kopya. İkincisi mantıksal ayrıştırma: yedekleme altyapısının kimlik doğrulamasının üretim dizin hizmetinden bağımsız olması, böylece üretimdeki bir yetki ele geçirme yedeğe geçmez.

Kurtarma noktası da farklı seçilir: saldırının tespit edildiği ana göre değil, bulaşmanın başladığı ana göre. Aradaki fark genellikle günlerdir ve bu, temiz bir noktaya dönmek için yeterli geçmişin saklanması gerektiği anlamına gelir.

Bu, planın en çok atlanan ve olay anında en çok vakit kaybettiren maddesidir.

Teknik hazırlık tamam olsa bile, ikincil sahaya geçme kararı ticari bir karardır: geri dönüş de bir maliyet taşır ve erken verilen bir devir kararı, geçici bir kesintiyi kalıcı bir veri tutarsızlığına çevirebilir.

Plan bu yüzden üç şeyi yazılı olarak belirler: kararı verecek rolün adı (kişinin değil, rolün; o kişi izinde olabilir), o kişiye ulaşılamazsa yetkinin kime geçtiği, ve kararın hangi eşikte otomatik sayılacağı. Örneğin "iki saati aşan ve nedeni belirlenememiş tam kesinti" gibi bir eşik, kimsenin tereddüt etmemesi için önceden tanımlanır.

Bu maddeler bir tatbikatta da sınanır: karar zinciri, teknik adımlar kadar prova edilmesi gereken bir parçadır.

Kurtarma planlarının çoğu ikincil sahaya geçişi ayrıntılı anlatır ve geri dönüşü tek cümleyle geçer. Oysa asıl karmaşık olan kısım budur.

İkincil sahada geçirilen süre boyunca orada yeni veri üretilmiştir. Geri dönüşte bu verinin birincil sahaya, veri kaybı olmadan ve çakışma yaratmadan taşınması gerekir; yani replikasyon yönü ters çevrilir, iki taraf senkronlanır, ve ancak eşitlik doğrulandıktan sonra kısa bir planlı kesintiyle geri dönülür.

Bu yüzden geri dönüş, felaketin aksine planlı bir işlemdir ve acele edilmez. Birincil saha gerçekten hazır olana kadar ikincil sahada çalışmaya devam etmek çoğu zaman doğru karardır.

Plan, geri dönüş adımlarını ve doğrulama ölçütlerini de içerir; içermiyorsa plan yarımdır.

Evet, ve çoğu çalışma zaten böyle başlıyor: sıfırdan bir plan yazmak değil, var olanı gerçeğe karşı sınamak.

Gözden geçirme dört soruya bakar. Plandaki RPO ve RTO hedefleri hâlâ iş birimlerinin beklentisiyle örtüşüyor mu? Bağımlılık haritası son mimariyi mi anlatıyor, yoksa iki yıl öncesini mi? En son ne zaman tatbikat yapıldı ve o tatbikatta ölçülen süre hedefin neresindeydi? Yedekler, üretimi ele geçiren bir saldırgandan mantıksal olarak ayrıştırılmış mı?

Çıktı, bulguların önem sırasına dizildiği bir rapordur. Bulguların bir kısmı çoğu zaman kendi ekibinizle kapatılabilir; hepsinin bir hizmete dönüşmesi gerekmez ve biz de öyle sunmuyoruz.