İş Sürekliliği ve Felaket Kurtarma Planı Nasıl Oluşturulur? ISO 22301, ISO 27001 ve Regülasyonlar

Bir kurumun yedekleme altyapısının güçlü olması, tek başına iş sürekliliğini garanti etmez.

Immutable backup bulunabilir.

Air-gap mimarisi kurulmuş olabilir.

İkinci veri merkezi hazır olabilir.

Cloud backup ve DRaaS kullanılabilir.

Ancak kritik bir kesinti yaşandığında;

kim karar verecek,

hangi sistem önce ayağa kaldırılacak,

hangi backup kullanılacak,

hangi lokasyona geçilecek,

müşteriler nasıl bilgilendirilecek,

çalışanlar ne yapacak,

RPO ve RTO hedefleri nasıl doğrulanacak

sorularının cevapları önceden belirlenmemişse teknik altyapı tek başına yeterli olmayabilir.

Bu nedenle kurumların backup ve disaster recovery yatırımlarını daha geniş bir çerçeve içerisinde ele alması gerekir.

Bu çerçevenin adı:

Business Continuity Management – İş Sürekliliği Yönetimi

ve bunun teknik boyutlarından biri:

Disaster Recovery – Felaket Kurtarma

dır.

Güçlü bir iş sürekliliği yaklaşımı kurumun yalnızca teknolojik sistemlerini değil;

insan,

tesis,

tedarikçi,

iletişim,

operasyon,

veri

ve kritik iş süreçlerini

bir bütün olarak değerlendirir.

Amaç yalnızca sunucuları yeniden açmak değildir.

Amaç:

kurumun kritik hizmetlerini kabul edilebilir süre içerisinde devam ettirebilmesidir.

İş Sürekliliği Nedir?

İş sürekliliği, kurumun ciddi bir kesinti, kriz veya felaket sonrasında kritik faaliyetlerini kabul edilebilir seviyede devam ettirebilme yeteneğidir.

Bu kesinti;

siber saldırı,

ransomware,

veri merkezi kaybı,

doğal afet,

elektrik kesintisi,

cloud outage,

kritik tedarikçi problemi,

insan kaynağı kaybı

gibi çok farklı nedenlerle oluşabilir.

İş sürekliliğinin temel sorusu şudur:

“Bu hizmet durursa kurum nasıl çalışmaya devam edecek?”

Business Continuity Plan – BCP Nedir?

BCP:

Business Continuity Plan

yani:

İş Sürekliliği Planı

olarak ifade edilir.

BCP, kritik iş süreçlerinin kesinti sırasında nasıl devam ettirileceğini tanımlar.

Örneğin;

ERP çalışmıyorsa manuel sipariş süreci,

e-posta servisi yoksa alternatif iletişim yöntemi,

ofise erişilemiyorsa uzaktan çalışma süreci

BCP içerisinde tanımlanabilir.

Disaster Recovery Plan – DRP Nedir?

DRP:

Disaster Recovery Plan

yani:

Felaket Kurtarma Planı

BT sistemlerinin felaket sonrasında nasıl geri getirileceğini tanımlar.

Örneğin;

server recovery,

database restore,

DR site failover,

network recovery,

Active Directory recovery,

DNS değişikliği

DRP kapsamında değerlendirilebilir.

BCP ile DRP Arasındaki Fark Nedir?

BCP daha geniştir.

DRP ise çoğunlukla teknoloji odaklıdır.

Basit şekilde:

BCP = İş nasıl devam edecek?

DRP = Teknoloji nasıl geri gelecek?

Örneğin ödeme sistemi 4 saat kapalı olacaksa:

BCP geçici manuel ödeme sürecini tanımlayabilir.

DRP ise ödeme sisteminin DR lokasyonunda yeniden açılmasını sağlar.

Backup İş Sürekliliğinin Neresindedir?

Backup iş sürekliliğinin temel teknik bileşenlerinden biridir.

Ancak tek başına iş sürekliliği değildir.

Backup:

veriyi geri getirir.

DR:

sistemi geri getirir.

BCP:

işi devam ettirir.

Bu üç yapı birlikte çalışmalıdır.

İş Sürekliliği Planı Nereden Başlamalı?

İlk adım teknoloji seçmek değildir.

İlk adım kurumun kritik iş süreçlerini anlamaktır.

Bu nedenle iş sürekliliği planının temelinde:

Business Impact Analysis – BIA

bulunur.

Business Impact Analysis – BIA Nedir?

BIA, kritik iş süreçlerinin kesinti sonrasında kurum üzerinde oluşturacağı etkileri analiz eder.

Amaç:

hangi iş süreçlerinin kritik olduğunu

ve

ne kadar süre kesintiye dayanabileceğini

belirlemektir.

BIA Neden Yapılır?

BIA olmadan hangi sistemin önce kurtarılması gerektiğini doğru belirlemek zordur.

Örneğin BT ekibi mail sistemini en kritik sistem olarak görebilir.

Ancak iş birimi için üretim ERP sistemi çok daha kritik olabilir.

Bu nedenle teknoloji öncelikleri iş ihtiyaçlarına göre belirlenmelidir.

BIA Sürecinde Hangi Sorular Sorulur?

Her kritik süreç için şu sorular sorulabilir:

Bu süreç durursa ne olur?

1 saat sonra ne olur?

4 saat sonra?

24 saat sonra?

Finansal kayıp oluşur mu?

Müşteri etkilenir mi?

Yasal yükümlülük oluşur mu?

İtibar kaybı yaşanır mı?

Başka süreçler bu sisteme bağımlı mı?

Ne kadar veri kaybı kabul edilebilir?

Kritik İş Süreci Nasıl Belirlenir?

Kritik süreç;

kurumun gelirini,

müşteri hizmetini,

yasal yükümlülüklerini,

güvenliğini

veya temel operasyonlarını

önemli ölçüde etkileyen süreçtir.

Örneğin;

ödeme,

sipariş,

üretim,

müşteri destek,

kimlik doğrulama

kritik olabilir.

Business Service Mapping Nedir?

Business Service Mapping, iş hizmeti ile onu destekleyen teknoloji bileşenleri arasındaki ilişkinin haritalanmasıdır.

Örneğin:

Online Satış

↓

Web Uygulaması

↓

Application Server

↓

Database

↓

Active Directory

↓

DNS

↓

Network

Bu bağımlılık zinciri recovery planlamasında kritik öneme sahiptir.

Dependency Mapping Neden Gereklidir?

Sadece ana uygulamayı restore etmek yeterli olmayabilir.

Örneğin ERP açılmış olabilir.

Ancak;

DNS çalışmıyor,

AD çalışmıyor,

database kapalı,

storage erişilemiyor

ise hizmet verilemez.

Bu nedenle recovery sırası bağımlılık haritasına göre belirlenmelidir.

RPO İş Sürekliliği Planında Nasıl Kullanılır?

RPO:

Recovery Point Objective

kabul edilebilir veri kaybı süresini ifade eder.

Örneğin:

RPO = 15 dakika

ise sistemin en fazla yaklaşık 15 dakikalık veri kaybıyla geri getirilebilmesi hedeflenir.

Bu değer backup sıklığını ve replikasyon mimarisini etkiler.

RTO İş Sürekliliği Planında Nasıl Kullanılır?

RTO:

Recovery Time Objective

sistemin ne kadar sürede geri getirilmesi gerektiğini ifade eder.

Örneğin:

RTO = 2 saat

ise sistem kesintiden sonra yaklaşık iki saat içerisinde tekrar kullanılabilir hale getirilmelidir.

RPO ve RTO Kim Tarafından Belirlenmeli?

Sadece BT ekibi tarafından belirlenmemelidir.

Sürece;

iş birimleri,

BT,

siber güvenlik,

risk,

uyum,

iş sürekliliği,

üst yönetim

dahil edilmelidir.

Çünkü kabul edilebilir veri kaybı ve kesinti iş kararıdır.

Maximum Tolerable Downtime – MTD Nedir?

MTD, iş sürecinin kabul edilemez seviyede etkilenmeden önce dayanabileceği maksimum kesinti süresini ifade eder.

RTO genellikle bu sınırın içerisinde belirlenmelidir.

Örneğin:

MTD = 8 saat

ise RTO'nun 24 saat olması mantıklı değildir.

Recovery Priority Nedir?

Recovery Priority, sistemlerin hangi sırayla geri getirileceğini belirler.

Örneğin:

Priority 1

Network, DNS, Active Directory

Priority 2

Database

Priority 3

ERP ve kritik uygulamalar

Priority 4

Dosya sunucuları

gibi bir sıralama yapılabilir.

Gerçek sıralama BIA ve dependency mapping sonuçlarına göre oluşturulmalıdır.

Tüm Sistemler Aynı Öncelikte Olabilir mi?

Hayır.

Her sistemi “kritik” olarak sınıflandırmak planı işlevsiz hale getirir.

Kritiklik gerçekçi şekilde belirlenmelidir.

Tier Bazlı Recovery Yaklaşımı

Kurumlar örneğin şu sınıflandırmayı kullanabilir:

Tier 0

Kimlik, DNS, temel altyapı

Tier 1

İş kritik sistemler

Tier 2

Önemli ancak kısa süreli kesintiye dayanabilen sistemler

Tier 3

Düşük öncelikli sistemler

Bu sınıflandırma backup, DR ve yatırım maliyetlerini optimize eder.

İş Sürekliliği Risk Analizi Nasıl Yapılır?

BIA iş etkisini analiz eder.

Risk Assessment ise olayların olasılığı ve etkisini değerlendirir.

Örneğin;

ransomware,

deprem,

storage failure,

insan hatası,

cloud outage,

tedarikçi kesintisi

riskleri analiz edilebilir.

BIA ile Risk Assessment Arasındaki Fark Nedir?

BIA:

“Bu süreç durursa etkisi ne olur?”

Risk Assessment:

“Bu kesinti hangi tehditlerden kaynaklanabilir ve riski nedir?”

sorusuna cevap verir.

İki çalışma birbirini tamamlar.

İş Sürekliliği Senaryoları Nasıl Belirlenmeli?

Plan sadece tek bir felaket senaryosuna göre hazırlanmamalıdır.

Örneğin şu senaryolar ayrı ayrı değerlendirilmelidir:

• Veri merkezi tamamen kullanılamaz
• Ransomware saldırısı
• Active Directory tamamen compromise
• Cloud provider kesintisi
• Network bağlantısı yok
• Kritik tedarikçi çalışmıyor
• Ofise erişilemiyor

Her senaryo farklı recovery yöntemi gerektirebilir.

Doğal Afet ile Ransomware Recovery Aynı mıdır?

Hayır.

Doğal afet durumunda DR Site güvenilir olabilir.

Ransomware olayında ise DR Site da saldırgan tarafından etkilenmiş olabilir.

Bu nedenle Cyber Recovery ayrıca planlanmalıdır.

Cyber Recovery Nedir?

Cyber Recovery, siber saldırı sonrası sistemlerin güvenilir ve temiz şekilde geri getirilmesini hedefleyen recovery yaklaşımıdır.

Özellikle;

ransomware,

credential compromise,

Active Directory compromise,

supply chain attack

gibi olaylarda kullanılır.

Cyber Recovery Planı Normal DR Planından Nasıl Farklıdır?

Normal DR planında amaç hızlı failover olabilir.

Cyber Recovery'de ise önce güven gerekir.

Örneğin;

hangi backup temiz?

credential'lar güvenilir mi?

persistence var mı?

DR ortamı etkilenmiş mi?

soruları cevaplanmalıdır.

Bu nedenle cyber recovery süresi daha uzun olabilir.

Clean Recovery Point Nedir?

Clean Recovery Point, saldırgan faaliyetinin başlamasından önceki güvenilir backup noktasıdır.

En son backup her zaman clean olmayabilir.

Örneğin saldırgan iki hafta boyunca sistem içerisinde sessizce kalmış olabilir.

Bu durumda son clean restore point daha eski olabilir.

Cyber Recovery Vault Nedir?

Cyber Recovery Vault, kritik backup ve recovery bileşenlerinin yüksek izolasyon altında saklandığı güvenli ortamdır.

Bu ortam;

immutable,

air-gapped,

ayrı identity,

restricted network

ile korunabilir.

İş Sürekliliği Planında Immutable Backup Olmalı mı?

Kritik sistemlerde güçlü şekilde değerlendirilmelidir.

Immutable backup ransomware saldırganının recovery kapasitesini yok etmesini zorlaştırır.

Air-Gap İş Sürekliliğinde Neden Önemlidir?

Air-gap, production compromise sonrasında bağımsız recovery kopyasının korunmasını sağlar.

Bu özellikle siber dayanıklılık açısından önemlidir.

DR Site Planın Hangi Bölümünde Yer Alır?

DR Site kritik sistemlerin alternatif lokasyonda çalıştırılmasını sağlar.

Plan içerisinde;

hangi sistemler DR'a replike ediliyor,

hangi sırada açılacak,

hangi network değişiklikleri yapılacak,

kim failover başlatacak

tanımlanmalıdır.

Hot, Warm ve Cold Site Seçimi Nasıl Yapılır?

Seçim RTO ve maliyete göre yapılır.

Hot Site

düşük RTO, yüksek maliyet

Warm Site

orta RTO, orta maliyet

Cold Site

uzun RTO, düşük maliyet

sunabilir.

Active-Active ve Active-Passive Ne Zaman Kullanılır?

Çok düşük RTO hedefi bulunan sistemlerde Active-Active düşünülebilir.

Daha ekonomik yapılarda Active-Passive yaygındır.

Ancak uygulama mimarisi seçimde belirleyicidir.

Failover Planı Nedir?

Failover Plan, production sisteminden DR sistemine geçiş sürecini tanımlar.

Örneğin:

• Felaket ilanı
• Replication kontrolü
• DR sistemlerini başlatma
• Network yönlendirme
• DNS değişikliği
• Application validation
• Kullanıcı açılışı

Failback Planı Neden Gereklidir?

Felaket sona erdiğinde DR ortamında oluşan yeni verinin production'a geri taşınması gerekir.

Bu işlem yanlış yapılırsa veri kaybı yaşanabilir.

Bu nedenle failback ayrıca test edilmelidir.

Disaster Declaration Nedir?

Bir kesintinin resmi olarak felaket kabul edilmesi:

Disaster Declaration

olarak adlandırılır.

Bu karar DR planını devreye sokar.

Felaket Kim Tarafından İlan Edilmeli?

Önceden belirlenmiş roller bulunmalıdır.

Örneğin;

CIO,

BT Direktörü,

BCM Manager,

Crisis Committee

yetkili olabilir.

Crisis Management Team Nedir?

Büyük olaylarda teknik ekibin ötesinde kriz yönetim ekibi devreye girer.

Bu ekipte;

üst yönetim,

hukuk,

iletişim,

BT,

siber güvenlik,

İK

yer alabilir.

Incident Response ile Business Continuity Nasıl Çalışır?

Incident Response saldırıyı;

tespit eder,

analiz eder,

izole eder,

temizler.

Business Continuity ise işin devam etmesini sağlar.

Ransomware olayında bu iki süreç paralel yürüyebilir.

Kim Önce Karar Vermeli: IR mi DR mı?

Tek bir doğru cevap yoktur.

Örneğin saldırı devam ederken hızlı DR failover yapmak saldırganı yeni ortama taşıyabilir.

Bu nedenle Cyber Incident Response ve DR ekiplerinin koordinasyonu gerekir.

DR Runbook Nedir?

DR Runbook, recovery sırasında uygulanacak teknik adımların ayrıntılı listesidir.

Örneğin:

network recovery,

AD recovery,

database failover,

application startup,

DNS switch

adımları tanımlanabilir.

Runbook Neden Kritik?

Felaket anında ekip yoğun stres altında olabilir.

İnsan hafızasına güvenmek risklidir.

Runbook süreçleri standartlaştırır.

Runbook İçerisinde Neler Olmalı?

Örneğin:

sistem adı,

owner,

RPO,

RTO,

dependency,

backup lokasyonu,

restore procedure,

DR server,

DNS değişikliği,

validation steps,

rollback

bilgileri bulunabilir.

Runbook Kim Tarafından Güncellenmeli?

Sistem sahibi teknik ekip tarafından güncellenebilir.

Ancak değişiklik yönetimiyle kontrol edilmelidir.

İş Sürekliliği Dokümanları Nerede Saklanmalı?

Sadece production sistemlerinde tutulmamalıdır.

Örneğin plan yalnızca SharePoint üzerinde ise Microsoft 365 outage sırasında erişilemeyebilir.

Bu nedenle bağımsız veya offline kopya bulunabilir.

Emergency Contact List Nedir?

Felaket sırasında kimin aranacağı önceden belirlenmelidir.

Liste içerisinde;

yönetim,

BT,

SOC,

cloud provider,

internet servis sağlayıcı,

kritik tedarikçiler

bulunabilir.

İletişim Planı Neden Gereklidir?

Büyük kesintiler yalnızca teknik olay değildir.

Müşteriler ve çalışanlar bilgi bekler.

Yanlış veya gecikmiş iletişim krizi büyütebilir.

Crisis Communication Plan Neleri İçermeli?

Kim açıklama yapacak?

Hangi kanal kullanılacak?

Çalışanlara nasıl bilgi verilecek?

Müşteriler ne zaman bilgilendirilecek?

Regülatör bildirimi gerekecek mi?

Bu sorular önceden cevaplanmalıdır.

Alternatif İletişim Kanalı Olmalı mı?

Evet.

E-posta sisteminin kendisi çökmüş olabilir.

Bu nedenle;

telefon,

SMS,

alternatif mesajlaşma,

acil durum platformu

değerlendirilebilir.

Tedarikçi İş Sürekliliği Nedir?

Kurumun kritik hizmetleri üçüncü taraflara bağımlı olabilir.

Örneğin;

cloud provider,

internet servis sağlayıcı,

SaaS,

ödeme altyapısı

kesilebilir.

Bu nedenle supplier continuity değerlendirilmelidir.

Tedarikçiye Hangi Sorular Sorulmalı?

Tedarikçinin;

RPO,

RTO,

DR Site,

backup,

incident response,

BCP

süreçleri sorgulanabilir.

Sözleşmelerde İş Sürekliliği Maddesi Olmalı mı?

Kritik tedarikçiler için değerlendirilebilir.

Örneğin;

SLA,

recovery hedefleri,

incident notification,

backup retention

tanımlanabilir.

Cloud Provider Kullanmak BCP İhtiyacını Ortadan Kaldırır mı?

Hayır.

Cloud yüksek erişilebilirlik sağlar ancak;

region outage,

account compromise,

configuration error

gibi riskler devam eder.

SaaS Kullanmak BCP İhtiyacını Ortadan Kaldırır mı?

Hayır.

Örneğin Microsoft 365 tamamen erişilemezse şirket nasıl iletişim kuracak?

Bu senaryo BCP içerisinde değerlendirilmelidir.

İş Sürekliliği Tatbikatı Nedir?

BCP ve DR planlarının gerçek veya simüle edilmiş senaryolarla test edilmesidir.

Amaç dokümanın gerçek dünyada çalışıp çalışmadığını doğrulamaktır.

Tabletop Exercise Nedir?

Tabletop Exercise masa başı tatbikatıdır.

Bir senaryo ekiplere verilir.

Örneğin:

“Cuma günü saat 09:00'da ransomware nedeniyle tüm sistemler erişilemez.”

Ekipler ne yapacaklarını tartışır.

Tabletop Tatbikatının Avantajı Nedir?

Düşük riskle;

karar mekanizması,

iletişim,

rol dağılımı,

eksik prosedürler

görülebilir.

Teknik Restore Testi Nedir?

Gerçek backup'tan sistem restore edilir.

Örneğin;

VM,

database,

file server

geri getirilir.

Bu test backup'ın kullanılabilirliğini doğrular.

DR Failover Testi Nedir?

Kritik sistemlerin DR Site üzerinden çalıştırılması test edilir.

Bu sırada;

RPO,

RTO,

network,

DNS,

application

doğrulanır.

Full Business Continuity Exercise Nedir?

Teknik ve iş birimlerinin birlikte katıldığı geniş kapsamlı tatbikattır.

Örneğin;

ana ofis kapalı,

ERP çalışmıyor,

e-posta yok,

müşteri aramaları geliyor

gibi birleşik senaryo uygulanabilir.

Tatbikatlar Ne Sıklıkla Yapılmalı?

Tek bir evrensel süre yoktur.

Kritik sistemler ve risk seviyesi dikkate alınmalıdır.

Örneğin;

tabletop yılda birkaç kez,

teknik restore üç aylık,

full DR yıllık

gibi planlar kullanılabilir.

Ancak gerçek sıklık kurumun risk profiline göre belirlenmelidir.

Tatbikatta RPO Ölçülmeli mi?

Evet.

Restore edilen verinin son kullanılabilir zamanı ölçülmelidir.

Hedef RPO ile karşılaştırılmalıdır.

Tatbikatta RTO Ölçülmeli mi?

Evet.

Kesinti başlangıcından hizmetin kullanılabilir hale gelmesine kadar geçen süre ölçülmelidir.

Kağıt Üzerindeki RTO ile Gerçek RTO Farklı Olabilir mi?

Kesinlikle.

Örneğin:

Hedef RTO = 2 saat

Gerçek test = 5 saat

ise kurumun gerçek recovery yeteneği hedefi karşılamamaktadır.

Recovery Test Sonuçları Nasıl Yönetilmeli?

Test sonunda;

hangi adım gecikti,

hangi dependency unutuldu,

hangi credential çalışmadı,

hangi network kuralı eksikti

belirlenmelidir.

Sonrasında iyileştirme planı oluşturulmalıdır.

Lessons Learned Nedir?

Tatbikat veya gerçek olay sonrasında çıkarılan derslerin kayıt altına alınmasıdır.

Amaç aynı hatanın tekrar etmesini önlemektir.

Corrective Action Nedir?

Tespit edilen eksikliği gidermek için oluşturulan aksiyondur.

Örneğin:

“DR firewall policy eksik.”

Corrective Action:

“DR firewall kuralları oluşturulacak ve test edilecek.”

İş Sürekliliği KPI'ları Nelerdir?

Örnek KPI'lar:

RPO Compliance

RTO Compliance

Backup Success Rate

Restore Success Rate

DR Test Success Rate

Critical Service Coverage

BIA Completion Rate

BCP Exercise Completion

RTO Compliance Nedir?

Hedef RTO içerisinde recovery tamamlanan sistemlerin oranını gösterir.

RPO Compliance Nedir?

Recovery sonrasında hedef veri kaybı toleransına uyulup uyulmadığını gösterir.

Backup Success Rate Yeterli midir?

Hayır.

İş sürekliliği açısından önemli olan restore başarısıdır.

Bu nedenle:

Backup Success

ve

Restore Success

birlikte izlenmelidir.

İş Sürekliliği Dashboard'u Nasıl Olabilir?

Örneğin dashboard’da:

Son Backup

Son Immutable Copy

Son Restore Test

Target RPO

Actual RPO

Target RTO

Actual RTO

Son DR Test

gösterilebilir.

ISO 22301 Nedir?

ISO 22301:

Business Continuity Management Systems

yani İş Sürekliliği Yönetim Sistemi için uluslararası standarttır.

Kurumların kesinti ve krizlere sistematik şekilde hazırlanmasını hedefler.

ISO 22301 Ne Sağlar?

Standart;

iş sürekliliği politikası,

BIA,

risk değerlendirmesi,

strateji,

planlar,

tatbikatlar,

sürekli iyileştirme

gibi süreçleri sistematik hale getirir.

ISO 22301 Sadece BT Standardı mı?

Hayır.

Bu önemli bir ayrımdır.

ISO 22301 yalnızca backup ve disaster recovery ile ilgili değildir.

Ayrıca;

tesis,

personel,

tedarikçi,

iletişim,

operasyon

gibi alanları da kapsar.

ISO 27001 ile ISO 22301 Arasındaki Fark

ISO/IEC 27001:

Bilgi Güvenliği Yönetim Sistemi

üzerine odaklanır.

ISO 22301:

İş Sürekliliği Yönetim Sistemi

üzerine odaklanır.

Birbirlerini tamamlayabilirler.

ISO 27001 Backup Açısından Ne Bekler?

ISO/IEC 27001 yaklaşımında bilgi varlıklarının erişilebilirliği ve kurtarılabilirliği risk bazlı olarak ele alınır.

Backup'ların;

korunması,

test edilmesi,

erişim kontrollü olması

önemlidir.

ISO 27001 ICT Continuity Açısından Neden Önemlidir?

Kritik bilgi sistemlerinin kesinti sonrasında geri getirilebilmesi bilgi güvenliği açısından erişilebilirlik hedefini destekler.

Bu nedenle DR ve backup süreçleri ISMS içerisinde değerlendirilebilir.

ISO 27017 Cloud Backup İçin İlgili midir?

ISO/IEC 27017 cloud güvenlik kontrolleri açısından cloud ortamlarındaki roller ve sorumlulukların daha açık ele alınmasına yardımcı olabilir.

Cloud backup ve DR tasarımlarında shared responsibility konusu önemlidir.

KVKK Açısından Backup ve İş Sürekliliği

Backup içerisinde kişisel veri bulunabilir.

Bu nedenle backup verisi de;

yetkisiz erişim,

sızıntı,

değişiklik,

kayıp

risklerine karşı korunmalıdır.

KVKK Backup Saklama Süresini Belirler mi?

Her sistem için tek bir teknik backup süresi vermez.

Retention;

iş ihtiyacı,

hukuki saklama yükümlülükleri,

kişisel veri işleme amaçları

birlikte değerlendirilmelidir.

Backup Verilerinin Silinmesi Planlanmalı mı?

Evet.

Retention süresi dolan veriler için güvenli imha süreçleri oluşturulmalıdır.

Ancak immutable retention süresi teknik olarak buna uygun tasarlanmalıdır.

DORA Nedir?

DORA:

Digital Operational Resilience Act

Avrupa Birliği finans sektöründe dijital operasyonel dayanıklılık çerçevesidir.

Finansal kuruluşların ICT risklerine karşı dayanıklılığını güçlendirmeyi hedefler.

DORA Backup ve DR Açısından Neden Önemlidir?

Operasyonel dayanıklılık kapsamında;

backup,

recovery,

ICT continuity,

testing,

incident management

birlikte değerlendirilir.

Kritik finansal hizmetlerin büyük ICT olaylarından sonra geri getirilebilmesi önemlidir.

DORA Belirli Bir RPO veya RTO Söyler mi?

Tüm sistemler için tek bir evrensel sayıdan söz etmek doğru değildir.

Recovery hedefleri ilgili hizmetin kritikliği, risk profili ve düzenleyici beklentiler dikkate alınarak belirlenmelidir.

PCI DSS Backup İçin İlgili Olabilir mi?

Kart verisi işlenen ortamlarda backup içerisinde kart verisi bulunabilir.

Bu nedenle backup repository de ilgili güvenlik kontrollerinin kapsamına girebilir.

Regülasyonlara Uyum İçin Backup Almak Yeterli mi?

Hayır.

Backup'ın;

güvenli,

erişilebilir,

test edilmiş,

doğru retention ile saklanan,

yetkili erişime sahip

olması gerekir.

İş Sürekliliği Politikası Nedir?

Üst yönetimin iş sürekliliği yaklaşımını tanımlayan resmi dokümandır.

Örneğin;

amaç,

kapsam,

roller,

sorumluluklar

tanımlanabilir.

Üst Yönetimin Rolü Nedir?

İş sürekliliği sadece BT projesi değildir.

Üst yönetim;

risk kabulü,

bütçe,

öncelik,

kritik hizmet tanımı

konularında sorumluluk taşır.

BCP Owner Kim Olmalı?

Her iş sürecinin kendi business owner'ı bulunmalıdır.

BT yalnızca teknik sistemi yönetir.

İş sürecinin kritikliği iş birimi tarafından belirlenmelidir.

IT Disaster Recovery Owner Kim Olmalı?

BT altyapısı için;

IT Manager,

Infrastructure Manager,

DR Manager

gibi rol tanımlanabilir.

Cyber Recovery Owner Kim Olmalı?

Siber güvenlik ve BT ekipleri birlikte sorumluluk taşıyabilir.

Özellikle ransomware recovery sırasında SOC, Incident Response ve Infrastructure ekipleri koordineli çalışmalıdır.

RACI Matrisi Nedir?

RACI;

Responsible,

Accountable,

Consulted,

Informed

rollerini tanımlar.

İş sürekliliğinde sorumlulukların netleşmesi için kullanılabilir.

Örnek RACI

Örneğin DR Failover için:

Responsible → Infrastructure Team

Accountable → CIO

Consulted → Cyber Security

Informed → Business Units

gibi bir yapı oluşturulabilir.

İş Sürekliliği Planında Manuel Workaround Nedir?

Teknoloji geri gelene kadar işin manuel yöntemle devam ettirilmesini sağlar.

Örneğin ERP yokken siparişler Excel veya kağıt üzerinden geçici olarak kaydedilebilir.

Manuel Workaround Her Süreçte Mümkün mü?

Hayır.

Bu nedenle BIA sırasında değerlendirilmelidir.

Bazı dijital süreçlerde manuel alternatif bulunmayabilir.

Bu durumda RTO çok düşük tutulabilir.

Alternate Site Sadece Veri Merkezi midir?

Hayır.

Çalışanlar için alternatif ofis de gerekebilir.

Örneğin ana ofis kullanılamazsa çalışanlar;

başka lokasyon,

home office,

shared workspace

üzerinden çalışabilir.

Remote Working BCP'nin Parçası Olabilir mi?

Evet.

Ancak;

VPN kapasitesi,

MFA,

endpoint security,

internet bağlantısı

önceden test edilmelidir.

Çalışan Listeleri Güncel Olmalı mı?

Evet.

Kriz sırasında eski telefon numarası veya ayrılmış çalışan bilgilerinin bulunması ciddi sorun oluşturabilir.

Kritik Tedarikçi Listesi Güncel Olmalı mı?

Evet.

Acil durumda iletişim kurulacak teknik ve sözleşmesel kişiler kayıtlı olmalıdır.

Backup ve DR Lisansları Planlanmalı mı?

Evet.

DR ortamında uygulama çalıştırılacağı zaman lisans gereksinimi ortaya çıkabilir.

Felaket sırasında lisans sorunu yaşanmamalıdır.

Sertifikalar ve Secret'lar Recovery Kapsamına Alınmalı mı?

Kesinlikle.

Sistem restore olabilir ancak TLS certificate veya secret eksikse uygulama çalışmayabilir.

Bu nedenle;

certificate,

API key,

service account,

secret

recovery planına dahil edilmelidir.

DNS Recovery Planında Neden Kritik?

Sistem DR'da ayağa kalksa bile kullanıcılar doğru adrese yönlenemiyorsa hizmet verilemez.

DNS failover planı test edilmelidir.

Firewall Recovery Planında Neden Kritik?

DR ortamında uygulama çalışabilir.

Ancak firewall kuralları eksikse kullanıcı erişemez.

Bu nedenle network security configuration backup ve dokümantasyonu önemlidir.

Active Directory Recovery Neden Özel Plan Gerektirir?

AD birçok hizmetin kimlik altyapısıdır.

Domain tamamen kaybedilirse sıradan VM restore yeterli olmayabilir.

Forest Recovery planı gerekebilir.

Active Directory Forest Recovery Planı Nedir?

AD forest'ın güvenilir backup'tan kontrollü şekilde yeniden oluşturulmasını tanımlayan özel plandır.

Bu süreç ayrı tatbikat gerektirir.

SaaS İçin İş Sürekliliği Planı Nasıl Yapılır?

SaaS platformu erişilemezse;

alternatif iletişim,

offline export,

bağımsız backup,

manual workaround

seçenekleri değerlendirilmelidir.

Microsoft 365 Outage Senaryosu Örneği

Microsoft 365 birkaç saat kullanılamıyorsa:

E-posta nasıl gönderilecek?

Dosyalara nasıl erişilecek?

Teams yerine ne kullanılacak?

Bu sorular BCP içerisinde cevaplanmalıdır.

Ransomware İş Sürekliliği Senaryosu Örneği

Örneğin:

09:00 – Ransomware tespit edildi.

09:10 – Network segmentleri izole edildi.

09:30 – Incident Response başladı.

10:30 – DR'a otomatik geçişin güvenli olmadığı belirlendi.

12:00 – Son clean backup seçildi.

14:00 – Clean Room restore başladı.

18:00 – Kritik uygulama doğrulandı.

Bu senaryo normal DR'dan farklıdır.

Cyber RTO Nedir?

Siber saldırı sırasında gerçek recovery süresi;

forensic,

credential reset,

malware validation,

clean room

nedeniyle normal RTO'dan daha uzun olabilir.

Bu nedenle bazı kurumlar Cyber RTO'yu ayrıca değerlendirir.

Cyber RPO Nedir?

Son başarılı backup değil, son güvenilir clean backup dikkate alınır.

Örneğin normal RPO 15 dakika olsa bile son clean backup 3 gün eski olabilir.

Bu gerçek cyber recovery riskidir.

Backup Retention Dwell Time'a Göre Planlanmalı mı?

Ransomware saldırganları günler veya haftalar boyunca sistem içerisinde kalabilir.

Retention çok kısa ise clean restore point kaybolabilir.

Bu nedenle retention yalnızca storage maliyetine göre belirlenmemelidir.

Golden Image Nedir?

Golden Image, güvenilir ve hardened sistem imajıdır.

Cyber Recovery sırasında server'lar temiz image üzerinden yeniden kurulabilir.

Application Binary'leri Recovery Planında Olmalı mı?

Evet.

Sadece data backup yeterli değildir.

Uygulama installer'ları ve doğru versiyonlar gerekebilir.

Infrastructure as Code Recovery İçin Kullanılabilir mi?

Evet.

Terraform, Ansible veya benzeri IaC araçları altyapının hızlı şekilde yeniden oluşturulmasını sağlayabilir.

Bu RTO'yu düşürebilir.

IaC Repository de Backup Alınmalı mı?

Evet.

Infrastructure code'un kaybedilmesi recovery süresini ciddi şekilde uzatabilir.

Configuration Backup Neleri Kapsamalı?

Örneğin;

firewall,

switch,

load balancer,

hypervisor,

database configuration,

backup configuration

yedeklenebilir.

Recovery Dokümanı Ne Kadar Teknik Olmalı?

Bir kişinin adım adım uygulayabileceği kadar açık olmalıdır.

Sadece:

“ERP restore edilir.”

yazmak yeterli değildir.

Kritik Recovery Bilgileri Tek Kişide Olmalı mı?

Hayır.

Key-person dependency oluşturur.

Bir çalışanın erişilemez olması recovery sürecini durdurmamalıdır.

Cross-Training Nedir?

Birden fazla çalışanın kritik recovery işlemlerini yapabilecek şekilde eğitilmesidir.

İş sürekliliği açısından önemlidir.

Yedek Personel Belirlenmeli mi?

Evet.

Her kritik rolün alternatif kişisi bulunabilir.

BCP Planı Ne Sıklıkla Güncellenmeli?

En azından düzenli periyotlarda ve önemli değişikliklerden sonra gözden geçirilmelidir.

Örneğin;

yeni ERP geçişi,

yeni cloud sağlayıcısı,

network değişikliği,

şirket birleşmesi

sonrası güncellenmelidir.

Eski BCP Neden Risklidir?

Plan içerisindeki;

IP adresleri,

personeller,

telefon numaraları,

server isimleri,

tedarikçiler

değişmiş olabilir.

Gerçek kriz sırasında plan çalışmayabilir.

İş Sürekliliği Dokümanı Versiyonlanmalı mı?

Evet.

Kim ne zaman değiştirdi bilinmelidir.

Değişiklik geçmişi tutulmalıdır.

BCP Dokümanı Gizli midir?

Genellikle hassas bilgi içerir.

Örneğin;

kritik sistemler,

telefonlar,

DR lokasyonları,

credentials süreci

bulunabilir.

Bu nedenle erişim kontrollü olmalıdır.

BCP'nin Offline Kopyası Olmalı mı?

Kritik planlar için değerlendirilebilir.

Siber saldırgan kurumun doküman sistemine erişimi engelleyebilir.

İş Sürekliliği Olgunluğu Nasıl Ölçülür?

Kurum şu seviyelerde değerlendirilebilir:

Seviye 1 – Reaktif

Plan yok veya kişilere bağlı.

Seviye 2 – Dokümante

BCP/DRP mevcut.

Seviye 3 – Test Edilen

Düzenli tatbikat yapılıyor.

Seviye 4 – Ölçülen

RPO/RTO KPI'ları izleniyor.

Seviye 5 – Sürekli İyileştirilen

Gerçek olaylar ve testlerden sürekli geliştirme yapılıyor.

Backup Olgunluğu İş Sürekliliği Olgunluğunu Gösterir mi?

Tek başına hayır.

Çok iyi backup altyapısı olup BCP'si olmayan kurum olabilir.

İş sürekliliği daha geniş bir yönetim disiplinidir.

Kurumsal BCP Oluşturma Adımları

Pratik bir iş sürekliliği süreci şu şekilde ilerleyebilir:

• Kapsam belirlenir.
• Kritik iş süreçleri tanımlanır.
• BIA yapılır.
• Risk assessment yapılır.
• RPO ve RTO belirlenir.
• Dependency mapping yapılır.
• Recovery strategy belirlenir.
• Backup ve DR mimarisi tasarlanır.
• BCP ve DRP dokümante edilir.
• Rollerin sorumlulukları belirlenir.
• Communication plan oluşturulur.
• Tatbikat yapılır.
• Sonuçlar ölçülür.
• İyileştirmeler uygulanır.

Recovery Strategy Nasıl Seçilir?

Örneğin:

Tier 1 sistem → Hot DR + Immutable Backup

Tier 2 → Warm DR + Cloud Backup

Tier 3 → Backup and Restore

kullanılabilir.

Bu değerler örnektir.

Gerçek model BIA ve risk analizine göre belirlenmelidir.

İş Sürekliliği Bütçesi Nasıl Belirlenmeli?

Yalnızca altyapı maliyetine bakılmamalıdır.

Cost of Downtime ile karşılaştırılmalıdır.

Örneğin sistemin 1 saat kesintisi 5 milyon TL zarar oluşturuyorsa DR yatırımı ekonomik olarak anlamlı olabilir.

Yönetim İçin İş Sürekliliği Raporu Nasıl Olmalı?

Teknik ayrıntılardan ziyade risk bazlı olmalıdır.

Örneğin:

Kritik hizmet sayısı

RPO uyumu

RTO uyumu

Son DR testi

Restore success

Açık riskler

raporlanabilir.

Yönetimin Sorması Gereken Kritik Sorular

Üst yönetim şu sorulara cevap alabilmelidir:

Kritik hizmetlerimiz hangileri?

Her birinin RPO ve RTO'su nedir?

Hangi sistemlerin DR ortamı var?

Hangi sistemlerin immutable backup'ı var?

Son restore testi ne zaman yapıldı?

Son DR testinde hedefi tutturduk mu?

Ransomware sonrası hangi temiz backup'a döneceğiz?

Production ve DR aynı anda kaybolursa ne yapacağız?

Bu sorular gerçek operasyonel dayanıklılığı gösterir.

İş Sürekliliğinde En Sık Yapılan Hatalar

Kurumlarda sık görülen hatalar şunlardır:

• BCP'yi yalnızca BT projesi görmek,
• BIA yapmadan DR yatırımı yapmak,
• tüm sistemleri kritik ilan etmek,
• RPO/RTO'yu BT'nin tek başına belirlemesi,
• backup ile DR'yi aynı görmek,
• DR ile cyber recovery'yi aynı sanmak,
• dependency mapping yapmamak,
• iletişim planını unutmak,
• failback planlamamak,
• tedarikçileri kapsam dışı bırakmak,
• yalnızca kağıt üzerinde test yapmak,
• gerçek RPO/RTO'yu ölçmemek,
• yıllarca doküman güncellememek.

İş Sürekliliği ve Felaket Kurtarma Kontrol Listesi

Kurumlar şu başlıkları kontrol edebilir:

• Business Impact Analysis
• Risk Assessment
• Critical Service Inventory
• RPO
• RTO
• MTD
• Dependency Mapping
• Recovery Priority
• Backup Strategy
• Immutable Backup
• Air-Gap
• DR Site
• Cyber Recovery
• DR Runbook
• Failover
• Failback
• Crisis Management
• Communication Plan
• Supplier Continuity
• Restore Testing
• DR Testing
• Tabletop Exercise
• Lessons Learned
• Corrective Actions

ISO 22301, ISO 27001 ve İş Sürekliliğinin Ortak Noktası

Bu yapıların ortak amacı sadece doküman üretmek değildir.

Asıl hedef:

kurumun kritik hizmetlerini gerçek bir kesinti karşısında sürdürebildiğini gösterebilmektir.

Backup bulunması önemlidir.

Ancak backup restore edilmiyorsa eksiktir.

DR merkezi bulunması önemlidir.

Ancak failover test edilmediyse kapasitesi bilinmez.

BCP dokümanı bulunması önemlidir.

Ancak ekipler planı bilmiyorsa kriz sırasında işe yaramaz.

Bu nedenle gerçek dayanıklılık üç kavram üzerine kurulmalıdır:

Planla

Test Et

Ölç ve İyileştir

Sık Sorulan Sorular

İş Sürekliliği Planı nedir?

İş Sürekliliği Planı, ciddi kesintiler sırasında kurumun kritik faaliyetlerini nasıl devam ettireceğini tanımlayan plandır.

Disaster Recovery Plan nedir?

DRP, kritik BT sistemlerinin felaket sonrasında nasıl yeniden çalıştırılacağını tanımlar.

BCP ile DRP arasındaki fark nedir?

BCP tüm iş faaliyetlerini kapsar. DRP daha çok teknoloji ve BT recovery süreçlerine odaklanır.

BIA nedir?

Business Impact Analysis, kritik iş süreçlerinin kesinti etkilerini analiz eder ve recovery önceliklerinin belirlenmesine yardımcı olur.

RPO nedir?

RPO kabul edilebilir maksimum veri kaybı süresini ifade eder.

RTO nedir?

RTO sistemin veya iş hizmetinin hedeflenen maksimum recovery süresidir.

Backup varsa DR gerekli midir?

Kritik sistemlerde genellikle evet. Backup veriyi geri getirir, DR ise hizmetin alternatif altyapıda çalıştırılmasını sağlar.

ISO 22301 nedir?

ISO 22301 İş Sürekliliği Yönetim Sistemi için uluslararası standarttır.

ISO 27001 iş sürekliliği ile ilgili midir?

Evet. ISO/IEC 27001 bilgi güvenliği kapsamında erişilebilirlik, backup ve ICT continuity gibi konuları risk bazlı şekilde ele alır.

Ransomware sonrasında en son backup kullanılmalı mı?

Her zaman değil. Son backup saldırganın sisteme girmesinden sonra alınmış olabilir. Bu nedenle son güvenilir clean restore point belirlenmelidir.

Sonuç: Gerçek İş Sürekliliği, Backup'ın Ötesinde Bir Kurumsal Dayanıklılık Yeteneğidir

Bir kurumun felaketlere hazır olup olmadığını anlamak için:

“Backup alıyor musunuz?”

sorusunu sormak artık yeterli değildir.

Daha doğru sorular şunlardır:

Kritik hizmetleriniz hangileri?

Ne kadar veri kaybını kabul edebilirsiniz?

Ne kadar kesintiyi tolere edebilirsiniz?

Son clean backup'ınız hangisi?

DR Site gerçekten çalışıyor mu?

Ransomware durumunda hangi ortama döneceksiniz?

Bu planı en son ne zaman test ettiniz?

İş sürekliliği bu soruların teknik, operasyonel ve yönetsel olarak cevaplanmasını sağlar.

Güçlü bir yapı;

BIA

ile kritik süreçleri belirler.

RPO ve RTO

ile recovery hedeflerini ölçülebilir hale getirir.

Backup ve Immutable Backup

ile veriyi korur.

Disaster Recovery

ile sistemi geri getirir.

Cyber Recovery

ile saldırı sonrası güvenilir ortam oluşturur.

BCP

ile iş süreçlerini devam ettirir.

Tatbikatlar

ile bütün yapının gerçekten çalıştığını doğrular.

ISO 22301, ISO/IEC 27001 ve ilgili operasyonel dayanıklılık yaklaşımları da bu sürecin kurumsal ve sürekli şekilde yönetilmesini destekler.

Bu serinin başında sorduğumuz soru şuydu:

“Backup nedir ve kurumlar için neden kritiktir?”

Serinin sonunda cevap artık çok daha geniştir.

Backup yalnızca dosyanın ikinci kopyası değildir.

Backup;

siber güvenliğin,

iş sürekliliğinin,

disaster recovery'nin

ve kurumsal operasyonel dayanıklılığın

temel bileşenlerinden biridir.

Ve en kritik prensip değişmez:

Backup'ın gerçek değeri alındığı gün değil, ihtiyaç duyulduğunda başarıyla geri döndürülebildiği gün ortaya çıkar.

Kurumların hedefi yalnızca:

“Yedeğimiz var.”

diyebilmek olmamalıdır.

Gerçek hedef:

“Ana sistemimizi, veri merkezimizi veya cloud ortamımızı kaybetsek bile hangi veriden, hangi sırayla, kim tarafından ve ne kadar sürede geri döneceğimizi biliyoruz; bunu da düzenli olarak test ediyoruz.”

diyebilecek olgunluğa ulaşmaktır.

İşte gerçek İş Sürekliliği, Felaket Kurtarma ve Siber Dayanıklılık budur.