İş Sürekliliği ve Siber Dayanıklılık

Siber güvenlik yalnızca saldırıları önlemekten ibaret değildir. Gerçek dayanıklılık, bir saldırı veya sistem kesintisi gerçekleştiğinde kurumun kritik hizmetlerini ne kadar hızlı ve kontrollü şekilde yeniden çalıştırabildiği ile ölçülür.

Eclipta İş Sürekliliği ve Siber Dayanıklılık yaklaşımı; kritik sistemlerin belirlenmesi, yedekleme stratejisinin değerlendirilmesi, felaket kurtarma mimarisinin oluşturulması ve siber olay sonrası operasyonların yeniden başlatılmasına odaklanır.

Amaç sıfır kesinti vaat etmek değil, beklenmeyen olayların kurum üzerindeki etkisini azaltacak hazırlığı oluşturmaktır.

İş Sürekliliği Neden Siber Güvenliğin Bir Parçasıdır?

Geleneksel iş sürekliliği çalışmaları uzun yıllar boyunca donanım arızası, veri merkezi kesintisi veya doğal afet gibi senaryolara odaklandı. Günümüzde bu risklere siber saldırılar da eklendi.

Özellikle ransomware saldırılarında yalnızca üretim sistemleri değil; sunucular, Active Directory, dosya sistemleri, yedekleme sunucuları, sanallaştırma ortamları ve yönetim sistemleri aynı anda etkilenebilir.

Bu nedenle modern iş sürekliliği yaklaşımı siber saldırı senaryolarını da kapsamalıdır.

Siber Olay Sonrası Toparlanma

Bir siber olay gerçekleştiğinde en önemli sorulardan biri şudur: Hangi sistem önce ayağa kaldırılmalı? Bu karar olay sırasında verilmemelidir. Kritik sistemlerin ve servis bağımlılıklarının önceden belirlenmesi gerekir.

Siber olay sonrası toparlanma çalışmalarında:

Kritik servislerin önceliklendirilmesi
Sistem bağımlılıklarının belirlenmesi
Kurtarma sırasının oluşturulması
Alternatif çalışma yöntemlerinin belirlenmesi
Kimlik altyapısının kurtarılması
Yedeklerin doğrulanması
Güvenli geri dönüş sürecinin planlanması

gibi konular değerlendirilir.

Yedekleme Stratejisi

Bir kurumun en önemli dayanıklılık katmanlarından biri yedekleme altyapısıdır. Ancak modern saldırılar doğrudan yedekleme sistemlerini de hedefleyebilir. Bu nedenle etkili bir yedekleme stratejisi yalnızca veri kopyası oluşturmak anlamına gelmez.

Aşağıdaki konular birlikte değerlendirilmelidir:

Kritik sistemlerin yedek kapsamı
Yedekleme sıklığı
Saklama süreleri
Yedek erişim yetkileri
Offline yedekleme
Immutable yedekleme
Coğrafi olarak ayrı kopyalar
Geri yükleme testleri
Yedekleme loglarının izlenmesi
Yetkisiz silme veya değiştirmeye karşı koruma

En önemli soru şudur: Yedek var mı? değil, Yedek gerçekten geri yüklenebiliyor mu?

Felaket Kurtarma Mimarisi

Felaket kurtarma mimarisi, kritik sistemlerin ana ortam kullanılamaz hale geldiğinde alternatif bir ortamdan çalıştırılabilmesini hedefler. Her kurum için aynı mimari doğru değildir.

İhtiyaca göre ikinci veri merkezi, felaket kurtarma merkezi, bulut tabanlı kurtarma, hibrit yapı, replikasyon, yedek üzerinden kurtarma veya kritik servisler için aktif/pasif mimari gibi modeller değerlendirilebilir.

Burada temel amaç teknolojiyi çoğaltmak değil, iş gereksinimine uygun bir kurtarma modeli oluşturmaktır.

RTO ve RPO Nedir?

İş sürekliliği projelerinde iki temel metrik vardır.

RTO — Recovery Time Objective: Bir sistemin kesinti sonrasında ne kadar süre içerisinde tekrar çalışır hale gelmesi gerektiğini ifade eder. Örneğin bir ERP sisteminin maksimum 4 saat içerisinde tekrar çalışması gerekiyorsa RTO 4 saat olabilir.

RPO — Recovery Point Objective: Kurumun kabul edebileceği maksimum veri kaybı süresini ifade eder. Örneğin RPO 1 saat ise, en kötü senaryoda son 1 saatlik verinin kaybedilebilmesi kabul ediliyor demektir.

RTO ve RPO değerleri teknoloji ekipleri tarafından tek başına belirlenmemelidir. İş birimleri, BT ekipleri ve yönetim birlikte değerlendirme yapmalıdır.

Kritik Servislerin Sürekliliği

Bir kurum içerisinde tüm sistemlerin aynı seviyede korunması ekonomik ve operasyonel olarak doğru değildir. Bu nedenle önce kritik servisler belirlenmelidir.

Örneğin Active Directory, ERP, finans sistemleri, üretim sistemleri, dosya sunucuları, e-posta, VPN, internet erişimi, veri tabanları ve yedekleme altyapısı kritiklik seviyelerine göre sınıflandırılabilir.

Daha sonra her sistem için maksimum kabul edilebilir kesinti, veri kaybı toleransı, teknik bağımlılıklar, kurtarma yöntemi ve sorumlu ekip belirlenebilir.

Ransomware Sonrası İş Sürekliliği

Ransomware vakaları klasik felaket senaryolarından farklıdır. Bir donanım arızasında yedek sistem doğrudan devreye alınabilir. Ancak ransomware vakasında saldırganın alternatif sistemlere veya yedeklere de erişmiş olma ihtimali vardır. Bu nedenle kurtarma süreci kontrollü yürütülmelidir.

Kurtarma öncesinde:

Olay kapsamı belirlenmeli
Etkilenen sistemler ayrıştırılmalı
Saldırgan erişiminin kesildiği doğrulanmalı
Kimlik bilgileri değerlendirilmelidir
Yedeklerin güvenilirliği kontrol edilmelidir

Daha sonra temiz ortam üzerinden sistemlerin yeniden devreye alınması planlanmalıdır.

Olay Müdahale Sonrası Güvenli Geri Dönüş

Bir sistemin yeniden çalışması olayın tamamen sona erdiği anlamına gelmez. Siber olay sonrası geri dönüş kontrollü yapılmalıdır.

Etkilenen kullanıcı hesaplarının kontrolü
Parola ve anahtar değişiklikleri
Ayrıcalıklı hesapların gözden geçirilmesi
Güvenlik yamalarının uygulanması
EDR ve log sistemlerinin doğrulanması
Ağ segmentasyonunun kontrolü
Açık servislerin sınırlandırılması
Olay göstergelerinin izlenmesi

Amaç saldırganın sisteme tekrar erişebileceği açık bir kapı bırakmamaktır.

İş Etki Analizi

İş sürekliliğinin temel adımlarından biri İş Etki Analizi'dir (Business Impact Analysis — BIA). Bu sayede hangi servislerin kurum için kritik olduğu belirlenir.

Analiz sırasında hangi süreçler kritik, hangi sistemler bu süreçleri destekliyor, sistem durduğunda finansal, operasyonel ve müşteri etkisi nedir, yasal veya sözleşmesel etkiler nelerdir ve maksimum kabul edilebilir kesinti süresi nedir gibi sorular değerlendirilir.

Bu çalışma teknik ekip ile iş birimleri arasında ortak bir önceliklendirme oluşturur.

Felaket Kurtarma Testleri

Bir plan test edilmediyse, kriz anında çalışacağı varsayılamaz. Bu nedenle felaket kurtarma planları düzenli olarak test edilmelidir.

Test yöntemleri:

Masa başı senaryo çalışmaları
Belirli sistemlerin geri yükleme testleri
Yedek doğrulama testleri
Kritik uygulamaların kurtarma testleri
Felaket merkezi geçiş testleri

Amaç hataları kriz yaşanmadan önce ortaya çıkarmaktır.

Kimler İçin Uygundur?

İş Sürekliliği ve Siber Dayanıklılık hizmeti özellikle kritik BT sistemlerine bağımlı şirketler, KOBİ'ler, orta ölçekli işletmeler, ransomware riskine karşı hazırlık yapmak isteyen kurumlar, felaket kurtarma planı olmayan kuruluşlar, mevcut planını güncellemek isteyen şirketler, yedekleme altyapısının güvenilirliğinden emin olmayan kurumlar ve ikinci veri merkezi veya DR mimarisi planlayan işletmeler için uygundur.

Eclipta Yaklaşımı

Eclipta iş sürekliliğini yalnızca dokümantasyon çalışması olarak değerlendirmez. Yaklaşım dört temel adımdan oluşur.

1. Kritik Sistemleri Belirleme — Hangi servislerin kurum operasyonları için kritik olduğu belirlenir.

2. Bağımlılıkları Görünür Hale Getirme — Uygulamalar, veri tabanları, Active Directory, ağ ve diğer sistemler arasındaki bağımlılıklar analiz edilir.

3. Kurtarma Modeli Oluşturma — RTO, RPO ve iş gereksinimlerine uygun kurtarma stratejisi oluşturulur.

4. Test ve İyileştirme — Planlar test edilir ve elde edilen sonuçlara göre geliştirilir.

Kritik Sistemleriniz Bugün Kullanılamaz Hale Gelse?

Modern kurumlar yalnızca saldırıları önlemeye değil, saldırı gerçekleştiğinde operasyonlarını sürdürebilmeye de hazırlanmalıdır. İş sürekliliği, yedekleme, kimlik güvenliği ve felaket kurtarma süreçlerinin birlikte ele alınması kurumun siber dayanıklılığını artırır.

Hangi sistemi ne kadar sürede geri getirebileceğinizi biliyor musunuz?

Sık Sorulan Sorular

İş sürekliliği ile felaket kurtarma arasındaki fark nedir?

İş sürekliliği kurumun operasyonlarını sürdürmesine odaklanırken, felaket kurtarma daha çok BT sistemlerinin ve verilerin tekrar çalışır hale getirilmesine odaklanır.

Felaket kurtarma merkezi şart mı?

Hayır. Kurumun ihtiyaçlarına göre ikinci veri merkezi, bulut, hibrit yapı veya yedek üzerinden kurtarma gibi farklı modeller kullanılabilir.

RTO ve RPO nasıl belirlenir?

RTO ve RPO değerleri sistemlerin iş üzerindeki etkisine göre belirlenir. BT ekipleri ve iş birimleri birlikte değerlendirme yapmalıdır.

Yedekleme olması ransomware için yeterli midir?

Hayır. Ransomware saldırılarında yedekleme sistemleri de hedef alınabilir. Yedeklerin saldırıdan ayrıştırılması, korunması ve düzenli olarak test edilmesi gerekir.

Felaket kurtarma planları ne sıklıkla test edilmelidir?

Kritik sistemlere ve kurumun risk seviyesine göre düzenli testler yapılmalıdır. Önemli altyapı değişikliklerinden sonra planların tekrar doğrulanması da önemlidir.