İşletmenizdeki kritik bir sistem çöktüğünde en zor kısımlar, önce neyin geri yükleneceğini, bunu yapacak erişime kimin sahip olduğunu, hangi yedeğe güvenilebileceğini ve işletmenizin bu sistem olmadan ne kadar süre çalışmaya devam edebileceğini bilmektir.
İşte bu noktada birçok küçük ve orta ölçekli işletme (KOBİ), yedeklere sahip olmakla gerçek bir kurtarma tarifesine sahip olmak arasındaki boşluğu keşfeder. Bir yedek ihtiyacınız olan verileri içerebilir ancak kurtarma sırasına karar vermez, sorumlulukları atamaz, geri yüklemenin çalışıp çalışmadığını doğrulamaz veya bir kesinti sırasında eksik yönetici kimlik doğrulama bilgileri sorununu çözmez.
Bir BT felaket kurtarma tarifesi, bir kesinti meydana gelmeden önce bu sürece bir yapı kazandırır. Hangi sistemlerin en önemli olduğunu, ne kadar hızlı geri yüklenmeleri gerektiğini, işletmenin ne kadar veri kaybını tolere edebileceğini, hangi veri kaybını önleme stratejilerinin uygulanacağını, her bir kurtarma adımının sahibinin kim olduğunu ve kritik kimlik doğrulama bilgilerinin nasıl korunacağını tanımlar. Bu netlik, bir BT olayının uzun süreli kapalı kalma süresine, gelir kaybına veya daha geniş bir operasyonel krize dönüşmesini engelleyebilir.
BT felaket kurtarma tarifesi nedir?
İş sürekliliği ve BT felaket kurtarma karşılaştırması
BT felaket kurtarma tarifenizin kapsaması gerekenler
BT felaket kurtarma tarifenizin tanımlaması gerekenler
Kimlik doğrulama bilgisi kurtarma: gözden kaçan felaket kurtarma senaryosu
Felaket kurtarma tarifesi şablonu
BT felaket kurtarma tarifeniz nasıl test edilir
Kurtarmayı sistemler, veriler ve erişim etrafında yapılandırın
BT felaket kurtarma tarifesi nedir?
BT felaket kurtarma tarifesi, bir kesintinin ardından teknoloji sistemlerinin geri yüklenmesi için belgelenmiş bir süreçtir. İşletmenin BT katmanına odaklanır: veriler, uygulamalar, aygıtlar, altyapı, bulut hizmetleri, yönetici erişimi, yedekler ve kurtarmadan sorumlu kişiler.
Pratik bir BT kurtarma tarifesi şu tür soruları yanıtlamalıdır:
- Öncelikle hangi sistemler geri gelmelidir?
- İşletme ne kadar kapalı kalma süresini tolere edebilir?
- Ne kadar veri kaybı kabul edilebilirdir?
- Yedekler nerede depolanıyor?
- Sistemleri kim geri yükleyebilir?
- Hangi yönetici kimlik doğrulama bilgileri gereklidir?
- Ekip, geri yüklenen sistemlerin güvenli ve kullanılabilir olduğunu nasıl onaylayacak?
- Birincil kanallar kapalıysa işletme personelle ve müşterilerle nasıl iletişim kuracak?
Bir felaket kurtarma tarifesi siber saldırılarla başa çıkmanın ötesine geçmelidir: donanım arızası, kayıp kimlik doğrulama bilgileri ve yanlışlıkla silme gibi günlük sorunları kapsaması gerekir. Ayrıca bulut platformu veya SaaS aracı kesintileri, yanlış yapılandırmalar ve kritik çalışanların kritik erişimleri devretmeden ayrılması gibi harici hizmet kesintilerini de kapsamalıdır.
Kurtarma, kesinti sırasında tasarlanacak bir şey değildir. İşletmenizin buna güvenmek zorunda kalmasından önce planlanmalı, sahiplenilmeli, iletilmeli ve test edilmelidir.
İş sürekliliği ve BT felaket kurtarma karşılaştırması
İş sürekliliği ve BT felaket kurtarma genellikle aynı şey olarak görülür ancak farklı sorunları çözerler.
İş sürekliliği, kesinti sırasında şirketin çalışmaya devam etmesini sağlamakla ilgilidir. Müşteri iletişimini, geçici iş akışlarını, personel sorumluluklarını, tedarikçi koordinasyonunu ve normal sistemler kullanılabilir olmasa bile hangi hizmetlerin devam etmesi gerektiğine ilişkin kararları kapsar.
BT felaket kurtarma, bu çalışmanın arkasındaki teknolojiye odaklanır. İşletmenin normal operasyonlarına güvenli bir şekilde dönebilmesi için sistemlerin, verilerin, uygulamaların, yedeklerin ve yönetici erişiminin nasıl geri yükleneceğini tanımlar.
Örnek olarak, bir CRM kesintisini ele alalım. Bir iş sürekliliği tarifesi, CRM kapalıyken satış veya destek ekiplerinin müşterilere hizmet vermeye nasıl devam edeceğini açıklayabilir. BT kurtarma tarifesi ise satıcıyla kimin iletişime geçeceğini, hangi verilerin geri yüklenmesi gerektiğini, hangi yedeğin veya dışa aktarımın mevcut olduğunu, hangi kimlik doğrulama bilgilerinin gerekli olduğunu ve ekibin sistemin tekrar güvenle kullanılabileceğini nasıl onayladığını açıklar.
Birçok KOBİ için boşluk yalnızca bir olay sırasında ortaya çıkar. İnsanlar müşterilerle kimin iletişime geçeceğini bilir ancak faturalandırma sistemini kimin geri yükleyebileceğini bilmez. Yedeklerin var olduğunu bilirler ancak geri yüklemenin daha önce test edilip edilmediğini bilmezler. Genellikle bir çalışanın BT işlerini yürüttüğünü bilirler ancak bu kişinin ulaşılamaz olması durumunda ne olacağını veya bu kişiyle iletişim kurulamadığında yönetici parolalarının nerede depolandığını bilmezler.
BT felaket kurtarma tarifenizin kapsaması gerekenler
Güçlü bir BT felaket kurtarma tarifesinin aşırı uzun olması gerekmez ancak stresli bir durum sırasında uygulanabilecek kadar spesifik olması gerekir.
Kurtarma süresi hedefi
Kurtarma süresi hedefi veya RTO, bir sistemin ne kadar hızlı geri yüklenmesi gerektiğini tanımlar. Bir ödeme sisteminin saatler içinde geri gelmesi gerekebilirken, dahili bir raporlama panosu daha uzun bir kesintiyi tolere edebilir.
RTO’ları teknik tercihlere göre değil, iş üzerindeki etkisine göre belirleyin; çünkü kapalı kalma süresinin maliyeti hem iş hem de teknik bir sorundur. Hangi sistemlerin geliri, müşteri taahhütlerini, yasal yükümlülükleri, güvenliği ve çalışan üretkenliğini etkilediğini sorun.
Kurtarma noktası hedefi
Kurtarma noktası hedefi veya RPO, ne kadar veri kaybının kabul edilebilir olduğunu tanımlar ve bu da doğru veri kaybını önleme (DLP) stratejilerinin belirlenmesine yardımcı olur. Bir sistemin RPO’su bir saat ise, yedeklemelerin veya replikasyonun yaklaşık olarak bu noktaya kadar kurtarmayı desteklemesi gerekir.
RPO bir gün ise işletme daha büyük bir boşluğu kabul ediyor demektir. RPO ayrıca yedekleme sıklığının belirlenmesine de yardımcı olur; çünkü RPO’nuz ne kadar kısa olursa yedeklerinizin o kadar sık alınması gerekir. Bu nedenle kritik sistemler, düşük öncelikli sistemlere göre daha sık yedeklemeye ihtiyaç duyar.
Sistem öncelik katmanları
Her sistem aynı anda geri yüklenmemelidir. Küçük bir işletme felaket kurtarma tarifesi, sistemleri öncelik katmanlarına ayırmalıdır.
- 1. Katman: Temel operasyonlar, güvenlik, iletişim veya gelir için gerekli sistemler.
- 2. Katman: Kısa süreli kapalı kalma sürelerini tolere edebilecek önemli sistemler.
- 3. Katman: İşletme istikrarlı hale geldikten sonra geri yüklenebilecek daha düşük öncelikli sistemler.
Tipik 1. katman sistemleri arasında e-posta, kimlik sağlayıcı, parola yöneticisi, finans sistemleri, müşteri veri tabanı, bulut depolama alanı ve iletişim platformları yer alabilir.
Yedekleme stratejisi
Yedekleme stratejiniz şunları tanımlamalıdır:
- Nelerin ve ne sıklıkla yedeklendiğini
- Yedeklerin nerede depolandığını
- Bunlara kimlerin erişebileceğini
- Geri yüklemenin nasıl test edildiğini
NCSC ayrıca(yeni pencere) bulut ve şirket içi yedekleme çözümleri için fidye yazılımına dayanıklı yedekleme ilkeleri yayınlayarak yedeklenen verilerin varsayılan olarak fidye yazılımına karşı dayanıklı olmadığını ve fidye yazılımı tehdidine karşı değerlendirilmesi gerektiğini belirtmiştir.
Güçlü bir yedekleme stratejisi genellikle kritik veriler için çevrim dışı veya değiştirilemez yedekler, düzenli testler, belgelenmiş geri yükleme adımları ve yedek yönetimi için ayrı kimlik doğrulama bilgileri içerir.
Roller ve sorumluluklar
Bir felaket kurtarma tarifesi yalnızca görevleri değil, sahipleri de belirtmelidir. Tüm kurtarma bilgisi tek bir kişideyse işletme, BT riskinin yanı sıra insan riskiyle de karşı karşıya kalır. Şunları kimin yapacağını tanımlayın:
- Kurtarmayı yönetir
- Sistemleri geri yükler
- Satıcılarla iletişime geçer
- Acil durum erişimini onaylar
- Dahili olarak iletişim kurar
- Kararları belgeler
BT felaket kurtarma tarifenizin tanımlaması gerekenler
| Bileşen | Yanıtladığı soru |
| RTO | Her bir sistemin ne kadar hızlı geri yüklenmesi gerekiyor? |
| RPO | İşletme ne kadar veri kaybetmeyi göze alabilir? |
| Öncelik katmanları | Öncelikle hangi sistemler geri gelir ve hangileri bekleyebilir? |
| Yedekleme stratejisi | Neler yedekleniyor, nerede depolanıyor ve geri yükleme test edildi mi? |
| Roller ve sorumluluklar | Kurtarmayı kim yönetir, sistemleri geri yükler, satıcılarla iletişime geçer ve acil durum değişikliklerini onaylar? |
Kimlik doğrulama bilgisi kurtarma: gözden kaçan felaket kurtarma senaryosu
Felaket kurtarma genellikle verilere, sunuculara ve yedeklere odaklanır. Ancak pratikte kurtarma işlemi, ekibin operasyonları geri yüklemek için gereken sistemlere erişememesi nedeniyle başarısız olabilir.
Kimlik doğrulama bilgisi kurtarma şu soruları sorar:
- Yönetici hesaplarına kimlerin erişimi var?
- Yedekleme kimlik doğrulama bilgileri nerede depolanıyor?
- Hangi hesaplar kritik sistemleri geri yükleyebilir?
- Bir parola kaybolursa, ödün verilirse veya ulaşılamayan biri tarafından tutulursa ne olur?
- Acil durum kimlik doğrulama bilgileri korunuyor ve inceleniyor mu?
- Erişim hızlı bir şekilde geçersiz kılınıp yeniden atanabilir mi?
Yedekleme kimlik doğrulama bilgileri tek bir çalışanın tarayıcısında depolanıyorsa, kurtarma kodları güvenli bir notta tutuluyorsa veya paylaşılan yönetici parolaları sohbet üzerinden dolaşıyorsa, işletme bir olay sırasında sorunsuz bir şekilde kurtarma gerçekleştiremeyebilir.
Bir kurumsal parola yöneticisi, kritik kimlik doğrulama bilgilerini şifrelenmiş kasalarda merkezileştirerek, erişimi role göre atayarak ve birisi ayrıldığında veya sorumluluklar değiştiğinde erişimi geçersiz kılmayı veya yeniden atamayı kolaylaştırarak bu riski azaltmaya yardımcı olur. Proton Pass for Business, ekiplerin güçlü parolalar oluşturmasına, kimlik doğrulama bilgilerini güvenli bir şekilde depolamasına, güvenli paylaşım kullanmasına ve hassas erişimleri sohbetlerden ve hesap tablolarından uzak tutmasına yardımcı olur.
BT ekipleri için bir parola yöneticisi olan Proton Pass; merkezi kimlik doğrulama bilgisi yönetimini, parola ilkelerini, güvenli paylaşımı, raporlama ve günlükleri, SCIM hazırlamayı ve SSO entegrasyonlarını destekler. Bu durum, kritik sistemlere erişimin tek bir kişiye, tek bir tarayıcı profiline veya belgelenmemiş tek bir parolaya bağımlı olmaması nedeniyle kimlik doğrulama bilgisi kurtarmayı daha yönetilebilir hale getirir.
Felaket kurtarma tarifesi şablonu
Bir felaket kurtarma tarifesi, bir kesinti sırasında eyleme rehberlik edecek kadar spesifik ancak ekibin baskı altında kullanabileceği kadar basit olduğunda en iyi şekilde çalışır. KOBİ’ler için şablon temel konulara odaklanmalıdır: neyin, ne kadar hızlı, hangi yedekten, kimin tarafından ve hangi kimlik doğrulama bilgileriyle geri yüklenmesi gerektiği.
1. Kapsam
Tarifenin hangi sistemleri, hizmetleri, konumları, aygıtları ve verileri kapsadığını tanımlayın.
Şablon metni: Bu BT felaket kurtarma tarifesi, bir teknoloji kesintisinden sonra [Company Name] şirketinin kritik operasyonlarını geri yüklemek için gereken sistemleri, verileri, hizmetleri, kimlik doğrulama bilgilerini ve satıcıları kapsar.
2. Kritik sistemler envanteri
İşletmenizdeki kritik sistemleri listeleyin ve öncelik katmanları atayın.
Şablon metni: Kritik sistemler; iş üzerindeki etki, kurtarma süresi hedefi, kurtarma noktası hedefi ve diğer sistemlere olan bağımlılığa göre 1. Katman, 2. Katman ve 3. Katman olarak gruplandırılacaktır.
3. Kurtarma hedefleri
Her bir öncelikli sistem için RTO ve RPO’yu tanımlayın.
Şablon metni: Her sistemin belgelenmiş bir kurtarma süresi hedefi ve kurtarma noktası hedefi olmalıdır. Bu hedefler en az yılda bir kez ve büyük sistem değişikliklerinden sonra gözden geçirilmelidir.
4. Yedekleme ve geri yükleme süreci
Yedeklerin nerede depolandığını, ne sıklıkla çalıştırıldığını, bunlara kimlerin erişebileceğini ve geri yükleme testinin nasıl çalıştığını belgeleyin.
Şablon metni: Yedekler yetkisiz erişimden korunmalı, uygun durumlarda birincil sistemlerden ayrı depolanmalı ve düzenli bir programa göre test edilmelidir. 1. Katman sistemleri için geri yükleme prosedürleri belgelenmelidir.
5. Kimlik doğrulama bilgisi ve erişim kurtarma
Kritik kimlik doğrulama bilgilerinin nerede depolandığını ve kurtarma sırasında bunlara kimlerin erişebileceğini tanımlayın.
Şablon metni: Felaket kurtarma için gereken yönetici kimlik doğrulama bilgileri, yedekleme kimlik doğrulama bilgileri, kurtarma kodları ve satıcı erişimi onaylanmış şifrelenmiş bir kasada depolanmalıdır. Erişim, yetkili rollerle sınırlandırılmalı ve rol değişikliklerinden, işten ayrılma süreçlerinden ve kurtarma tatbikatlarından sonra gözden geçirilmelidir.
6. Roller ve üst seviyeye iletim
Kurtarma sahiplerini, yedeklerini ve üst seviyeye iletim yollarını tanımlayın.
Şablon metni: Her kurtarma rolünün bir birincil sahibi ve bir yedek sahibi olmalıdır. Tarife; kurtarmayı kimin yöneteceğini, sistemleri kimin geri yükleyeceğini, satıcılarla kimin iletişime geçeceğini, güncellemeleri kimin ileteceğini ve acil durum değişikliklerini kimin onaylayacağını belirlemelidir.
7. İletişim tarifesi
Bir BT kesintisi sırasında işletmenin dahili ve harici olarak nasıl iletişim kuracağını tanımlayın.
Şablon metni: Bir kurtarma etkinliği sırasında dahili güncellemeler [onaylanmış kanal] aracılığıyla paylaşılacaktır. Müşterilere, satıcılara, sigortacılara veya düzenleyici kurumlara yapılacak harici iletişimler [rol/ekip] tarafından onaylanmalıdır.
8. Test ve gözden geçirme sıklığı
Tarifenin ne sıklıkla test edildiğini ve güncellendiğini tanımlayın.
Şablon metni: Bu felaket kurtarma tarifesi en az [yılda bir/yılda iki kez] test edilecek ve büyük olaylardan, sistem değişikliklerinden, satıcı değişikliklerinden veya başarısız kurtarma tatbikatlarından sonra gözden geçirilecektir.
BT felaket kurtarma tarifeniz nasıl test edilir
Bir felaket kurtarma tarifesi, yalnızca gerçek bir kesintiye benzeyen koşullar altında test edildiğinde kullanışlı hale gelir. Mevcut olan ancak hiçbir zaman geri yüklenmemiş bir yedek hala bir varsayımdır. Yalnızca bir kişinin anladığı bir kurtarma rolü hala bir bağımlılıktır. Kesinti sırasında kimsenin bulamadığı bir yönetici kimlik doğrulama bilgisi hala bir engelleyicidir.
Test etmenin başlangıçta karmaşık olması gerekmez. Çoğu KOBİ için amaç; işletmenin doğru sistemleri, doğru kişilerle, doğru kimlik doğrulama bilgilerini kullanarak, gerçekçi bir zaman dilimi içinde geri yükleyebileceğini kanıtlamaktır.
1. Masa başı tatbikatı
Fidye yazılımının paylaşılan dosyaları etkilemesi, bulut depolama alanı kesintisi, müşteri verilerinin yanlışlıkla silinmesi veya bir yönetici hesabına erişimin aniden kaybedilmesi gibi olası bir senaryo seçin. İlk saatte ekibin ne yapacağını, kimin liderlik edeceğini, hangi satıcılarla iletişime geçileceğini, hangi sistemlere öncelik verileceğini ve hangi bilgilerin eksik olacağını gözden geçirin.
2. Geri yüklemeyi test edin
Kritik bir dosya, veri tabanı, e-posta kutusu veya sistem dışa aktarımı seçin ve bunun kullanılabilir bir duruma geri yüklenebileceğini onaylayın. Geri yüklenen verilerin yeterince güncel olup olmadığını, izinlerin hala çalışıp çalışmadığını ve ekibin yedeğin nerede olduğunu bilip bilmediğini kontrol edin.
3. Düzenli olarak test edin
Pratik bir temel olarak KOBİ’ler, Özel Yayın 800-34 Revizyon 1(yeni pencere)’deki NIST kılavuzu doğrultusunda tarifeyi en az yılda bir kez ve büyük sistem veya satıcı değişikliklerinden sonra daha sık test etmelidir.
4. Kimlik doğrulama bilgisi kurtarmayı test edin
Yetkili kişilerin; tek bir çalışanın tarayıcısına, güvenli notlarına veya hafızasına güvenmeden yedek yönetici hesaplarına, bulut yönetici hesaplarına, satıcı portallarına, kurtarma kodlarına ve acil durum kimlik doğrulama bilgilerine erişebildiğini onaylayın. Amaç, hassas parolaları gereksiz yere açığa çıkarmak değildir. Amaç, işletme baskı altındayken erişim modelinin hala çalıştığını onaylamaktır.
Her testten sonra neyin başarısız olduğunu, neyin çok uzun sürdüğünü belgeleyin ve her bir düzeltme için belirli bir kişi ve son tarih atayın. İyi bir test, her şeyin mükemmel gittiği bir test değildir. İşletmenin bunları düzeltmek için hala zamanı varken boşlukları ortaya çıkaran testtir.
Kurtarmayı sistemler, veriler ve erişim etrafında yapılandırın
Kullanışlı bir BT felaket kurtarma tarifesi; işletmeye bir kurtarma sırası, bir dizi sahip, kabul edilebilir kapalı kalma süresine ilişkin gerçekçi bir görünüm ve iş sürekliliğini sürdürme ile işin devam etmesini sağlayan sistemlere yeniden erişim sağlama yolu sunar.
KOBİ’ler için bu durum, kısa bir kesinti ile uzun süreli bir kesinti arasındaki farkı yaratabilir. E-posta, finans yazılımı, bulut depolama alanı, müşteri sistemleri veya yönetici hesapları kullanılamıyorsa ekibin neyin önce geleceğini, kimlerin harekete geçebileceğini ve erişimi güvenli bir şekilde geri yüklemek için hangi kimlik doğrulama bilgilerinin gerekli olduğunu bilmesi gerekir.
Bu nedenle kurtarma planlaması; sistemleri, verileri ve erişimi birlikte kapsamalıdır. Yedekler dosyaları geri yükleyebilir ancak ekibin kurtarma için gereken sistemlerin kontrolünü yeniden ele geçirmesini sağlayan şey kimlik doğrulama bilgileridir. Bir şeyler ters gittiğinde yönetici girişleri, satıcı portalları, yedekleme hesapları, kurtarma kodları ve paylaşılan operasyonel kimlik doğrulama bilgilerinin tümünün korunması, düzenlenmesi ve doğru kişilerin kullanımına sunulması gerekir.
Bir kurumsal parola yöneticisi, tarifenin bu kısmının güçlendirilmesine yardımcı olur. Kritik kimlik doğrulama bilgilerinin şifrelenmiş parola kasalarında depolanması ve yalnızca yetkili kişilerle paylaşılmasıyla işletme, bir kurtarma etkinliği sırasında tek bir çalışanın tarayıcısına, güvenli notlarına veya hafızasına daha az bağımlı olur.
