Bulut Yedekleme: Cloud Backup, BaaS ve DRaaS Mimarileri

Bulut altyapılarının yaygınlaşmasıyla birlikte kurumların backup ve disaster recovery yaklaşımları da önemli ölçüde değişti.

Eskiden yedekleme denildiğinde çoğunlukla veri merkezindeki fiziksel sunucuların, storage sistemlerinin ve tape cihazlarının korunması düşünülüyordu.

Bugün ise kritik iş yüklerinin önemli bir bölümü;

public cloud,

private cloud,

hybrid cloud,

SaaS,

container,

virtual machine,

object storage

ve farklı bulut servisleri üzerinde çalışıyor.

Bu dönüşüm beraberinde yeni bir yanlış algı da oluşturdu:

“Veri cloud’da ise zaten yedeklidir.”

Bu düşünce her zaman doğru değildir.

Cloud sağlayıcıları altyapı dayanıklılığı, disk sürekliliği ve servis erişilebilirliği konusunda güçlü mekanizmalar sunabilir.

Ancak bu durum;

yanlışlıkla silinen verinin,

ransomware tarafından şifrelenen dosyanın,

ele geçirilmiş administrator hesabının,

yanlış yapılandırılmış retention politikasının,

silinen SaaS verisinin

otomatik olarak geri getirilebileceği anlamına gelmez.

Bu nedenle modern bulut mimarisinde de backup ayrı bir güvenlik ve iş sürekliliği katmanı olarak değerlendirilmelidir.

Cloud Backup yaklaşımının temel amacı, bulutta veya kurum içinde çalışan sistemlerin güvenli, bağımsız ve geri yüklenebilir kopyalarının oluşturulmasıdır.

Cloud Backup Nedir?

Cloud Backup, verilerin yedek kopyalarının cloud tabanlı storage veya backup platformlarında saklanmasıdır.

Bu veri;

on-premise sistemlerden,

başka bir cloud ortamından,

SaaS uygulamalarından,

virtual machine’lerden,

database sistemlerinden

gelebilir.

Cloud backup sayesinde kurum fiziksel backup storage kurmak zorunda kalmadan uzak lokasyonda veri kopyası oluşturabilir.

Ancak burada kritik nokta şudur:

Cloud üzerinde veri saklamak ile güvenli cloud backup yapmak aynı şey değildir.

Cloud Backup Nasıl Çalışır?

Genel bir cloud backup mimarisi şu şekilde olabilir:

Production sistemleri

↓

Backup Agent veya Backup Proxy

↓

İnternet veya özel bağlantı

↓

Cloud Backup Storage

↓

Retention / Immutable Storage

Veriler belirlenen zamanlarda bulut ortamına aktarılır.

Backup yazılımı;

full,

incremental,

synthetic full,

snapshot,

application-aware backup

gibi farklı yöntemler kullanabilir.

Cloud Storage Backup Sayılır mı?

Her zaman değil.

Örneğin bir şirket dosyalarını doğrudan cloud object storage üzerinde saklıyor olabilir.

Bu veri;

tek kopya,

tek account,

tek region

üzerinde bulunuyorsa bunu otomatik olarak backup kabul etmek doğru değildir.

Backup’ın üretim verisinden bağımsız bir restore point oluşturması gerekir.

Cloud’da Çalışan Sistem Zaten Yedekli Değil mi?

Bu en sık karşılaşılan sorulardan biridir.

Cloud sağlayıcısı altyapıyı yedekli çalıştırabilir.

Örneğin diskler birden fazla fiziksel cihaz üzerinde tutulabilir.

Ancak kullanıcı bir dosyayı silerse storage redundancy o silme işlemini de uygular.

Benzer şekilde ransomware dosyayı şifrelerse replicated storage şifrelenmiş dosyanın kopyalarını tutabilir.

Bu nedenle:

Redundancy ≠ Backup

Cloud Redundancy Nedir?

Redundancy, verinin veya servisin birden fazla altyapı bileşeni üzerinde tutulmasıdır.

Amaç hardware failure durumunda hizmeti devam ettirmektir.

Örneğin bir disk bozulursa başka disk üzerinden hizmet devam eder.

Backup ise geçmiş bir veri noktasına geri dönmeyi sağlar.

Bu iki teknoloji farklı sorunları çözer.

Cloud Snapshot Backup mıdır?

Snapshot çok değerli bir recovery mekanizmasıdır.

Ancak tek başına bağımsız backup olarak değerlendirilmemelidir.

Çünkü snapshot aynı cloud account veya storage sistemi içerisinde tutulabilir.

Administrator account ele geçirilirse snapshot’lar silinebilir.

Bu nedenle kritik snapshot’ların ayrıca;

başka account,

başka region,

immutable storage

üzerine kopyalanması değerlendirilebilir.

BaaS Nedir?

BaaS:

Backup as a Service

anlamına gelir.

Türkçede:

Hizmet Olarak Yedekleme

şeklinde ifade edilebilir.

Bu modelde kurum backup altyapısının önemli bir bölümünü servis sağlayıcı üzerinden kullanır.

Sağlayıcı;

storage,

backup platformu,

management console,

retention mekanizması,

monitoring

gibi bileşenleri hizmet olarak sunabilir.

BaaS Nasıl Çalışır?

Örneğin şirketin veri merkezinde 50 sanal makine bulunuyor olsun.

Bu VM’lere backup agent veya proxy kurulabilir.

Veriler güvenli bağlantı üzerinden BaaS sağlayıcısının storage ortamına gönderilir.

Kurum;

backup job,

retention,

restore,

reporting

işlemlerini portal üzerinden yönetebilir.

BaaS Avantajları Nelerdir?

BaaS’ın başlıca avantajları şunlardır:

• Başlangıç yatırımını azaltabilir.
• Ayrı backup storage yatırımı gereksinimini düşürebilir.
• Offsite backup sağlayabilir.
• Kapasite büyüdükçe ölçeklenebilir.
• Merkezi yönetim sunabilir.
• Operasyonel yükü azaltabilir.

Özellikle küçük ve orta ölçekli kuruluşlar için pratik olabilir.

BaaS Kullanmanın Riskleri Nelerdir?

BaaS kullanıldığında sorumluluk tamamen servis sağlayıcıya geçmez.

Kurum yine de şu konuları değerlendirmelidir:

Veri nerede tutuluyor?

Kim erişebiliyor?

Backup şifreleniyor mu?

Encryption key kimde?

Immutable backup var mı?

Retention nasıl uygulanıyor?

Restore ne kadar sürüyor?

Sağlayıcı saldırıya uğrarsa ne olacak?

Sağlayıcı hizmet veremez hale gelirse backup’a nasıl erişilecek?

Bu sorular sözleşme ve mimari aşamasında cevaplanmalıdır.

Cloud Backup ile BaaS Arasındaki Fark Nedir?

Cloud Backup daha genel bir kavramdır.

Kurum kendi backup yazılımını kullanarak cloud object storage’a yedek alabilir.

BaaS modelinde ise backup platformunun kendisi de hizmet olarak sağlanır.

Özetle:

Cloud Backup = Backup’ın cloud üzerinde saklanması

BaaS = Backup platformunun hizmet olarak sunulması

DRaaS Nedir?

DRaaS:

Disaster Recovery as a Service

anlamına gelir.

BaaS yalnızca backup ve restore sağlarken DRaaS kritik sistemleri başka bir ortamda çalıştırmayı hedefler.

Örneğin kurumun ana veri merkezi tamamen kullanılamaz hale geldiğinde DRaaS sağlayıcısındaki sistemler devreye alınabilir.

BaaS ve DRaaS Arasındaki Fark

Bu iki kavram sık karıştırılır.

BaaS

Verinin backup’ını sağlar.

Restore gerekir.

DRaaS

Sistemin alternatif ortamda çalıştırılmasını sağlar.

Failover kullanılabilir.

Basit ifadeyle:

BaaS = Veriyi korur.

DRaaS = Hizmeti ayağa kaldırır.

DRaaS Nasıl Çalışır?

Production sistemleri sürekli veya periyodik olarak DRaaS ortamına replike edilir.

Felaket meydana geldiğinde:

Primary Site devre dışı kalır.

DR süreci başlatılır.

Replica sistemler aktif edilir.

Network bağlantıları yönlendirilir.

DNS değiştirilir.

Kullanıcılar DR ortamına erişir.

Bu sayede tüm sistemi backup’tan yeniden restore etmek beklenmeyebilir.

DRaaS RTO’yu Düşürür mü?

Genellikle evet.

Özellikle kritik sanal makinelerin hazır replica’ları tutuluyorsa sistemler kısa sürede açılabilir.

Ancak gerçek RTO;

network,

DNS,

database,

authentication,

application dependencies

gibi faktörlere bağlıdır.

DRaaS RPO’yu Nasıl Etkiler?

Replikasyon sıklığı RPO’yu belirler.

Örneğin veri her:

5 dakikada

replike ediliyorsa teorik RPO yaklaşık birkaç dakika olabilir.

Ancak bu değer platform ve uygulamaya göre değişir.

DRaaS Backup Yerine Geçer mi?

Hayır.

Ransomware veya veri corruption hatası DRaaS ortamına replike olabilir.

Bu nedenle DRaaS yanında ayrıca;

immutable backup,

point-in-time backup,

air-gapped backup

gibi koruma katmanları bulunmalıdır.

Object Storage Nedir?

Object Storage, verileri dosya veya blok yapısından farklı olarak object şeklinde saklayan depolama modelidir.

Cloud backup dünyasında son derece yaygındır.

Object storage;

yüksek ölçeklenebilirlik,

düşük maliyet,

API tabanlı erişim,

immutable özellikleri

nedeniyle backup için tercih edilir.

S3 Uyumlu Storage Nedir?

S3, object storage erişim modelidir.

Birçok cloud ve on-prem storage platformu S3 uyumlu API sunar.

Backup yazılımları bu storage sistemlerine doğrudan backup yazabilir.

Bu sayede kurum tek bir vendor’a bağlı kalmadan farklı object storage sağlayıcılarını kullanabilir.

Object Lock Cloud Backup İçin Neden Önemlidir?

Object Lock, backup object’lerinin belirli süre boyunca silinmesini veya değiştirilmesini engelleyebilir.

Bu özellik ransomware dayanıklılığı için son derece değerlidir.

Örneğin:

30 günlük Object Lock

uygulanan backup kopyası administrator hesabı ele geçirilse bile retention süresi boyunca korunabilir.

Cloud Backup Immutable Olmalı mı?

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

Cloud backup internet üzerinden erişilebilir olduğu için saldırganın cloud credential ele geçirme riski vardır.

Immutable storage bu riske karşı önemli bir savunma katmanıdır.

Cloud Backup ve 3-2-1-1-0

Cloud Backup modern 3-2-1-1-0 stratejisinde önemli rol oynayabilir.

Örnek:

Production

↓

Local Backup

↓

Cloud Offsite Backup

↓

Immutable Object Storage

Bu yapı;

offsite,

farklı storage,

immutable copy

sağlayabilir.

Cross-Region Backup Nedir?

Cross-Region Backup, backup verisinin bir cloud region’dan başka region’a kopyalanmasıdır.

Örneğin:

Region A

↓

Region B

Bu sayede tek region failure riskine karşı ek dayanıklılık sağlanabilir.

Cross-Region Backup Neden Gerekir?

Cloud region’lar yüksek dayanıklılığa sahip olabilir.

Ancak sıfır risk yoktur.

Büyük;

network failure,

provider outage,

disaster,

configuration error

bir region’ı etkileyebilir.

Bu nedenle kritik sistemler için cross-region backup değerlendirilebilir.

Cross-Region Replication Backup mıdır?

Her zaman değil.

Eğer production object’leri gerçek zamanlı replike ediliyorsa yanlış silme veya ransomware etkisi ikinci region’a da taşınabilir.

Bu nedenle:

Cross-Region Replication

ile

Cross-Region Backup

aynı şey değildir.

Backup geçmiş restore point sağlamalıdır.

Cross-Account Backup Nedir?

Cross-Account Backup, production backup’larının başka cloud account içerisinde tutulmasıdır.

Örneğin:

Production Account

↓

Backup Account

Bu yöntem özellikle account compromise riskini azaltır.

Neden Ayrı Backup Account Kullanılmalı?

Saldırgan production administrator hesabını ele geçirirse aynı account içerisindeki;

VM,

storage,

snapshot,

backup

sistemlerine erişebilir.

Backup ayrı account’ta tutulursa saldırganın ikinci güvenlik sınırını da aşması gerekir.

Bu yöntem:

Blast Radius Reduction

sağlar.

Cloud Account Compromise Nedir?

Cloud Account Compromise, saldırganın cloud yönetim hesabını ele geçirmesidir.

Bu durumda saldırgan;

VM silebilir,

snapshot silebilir,

backup policy değiştirebilir,

storage erişebilir,

IAM yetkilerini değiştirebilir.

Bu nedenle cloud backup mimarisinde identity security kritik öneme sahiptir.

MFA Cloud Backup İçin Yeterli mi?

Hayır.

MFA önemli bir güvenlik katmanıdır.

Ancak ayrıca;

least privilege,

conditional access,

separate backup account,

PAM,

audit logging,

immutable storage

gibi kontroller uygulanmalıdır.

Cloud Backup IAM Nasıl Tasarlanmalı?

Backup service account yalnızca ihtiyaç duyduğu kaynaklara erişmelidir.

Örneğin sadece;

backup oluşturma,

backup okuma,

restore

yetkileri verilebilir.

Gereksiz administrator yetkileri verilmemelidir.

Least Privilege Cloud Backup İçin Neden Önemli?

Backup service account compromise olursa saldırgan hesabın sahip olduğu tüm yetkileri kullanabilir.

Bu nedenle yetkilerin sınırlı olması saldırının etkisini azaltır.

Cloud Backup API Key Güvenliği

Cloud platformlarında backup entegrasyonları API key kullanabilir.

API key;

source code,

script,

shared folder

içerisinde tutulmamalıdır.

Secret management veya vault sistemleri kullanılmalıdır.

Cloud Backup Encryption

Cloud backup verileri;

in transit

ve

at rest

şifrelenmelidir.

In Transit encryption network üzerindeki veriyi korur.

At Rest encryption storage üzerindeki veriyi korur.

Customer-Managed Encryption Key Nedir?

Bazı cloud platformlarında kurum kendi encryption key’ini yönetebilir.

Bu:

Customer-Managed Key

olarak adlandırılır.

Bu yöntem daha fazla kontrol sağlar.

Ancak key management sorumluluğunu da artırır.

Encryption Key Kaybedilirse Ne Olur?

Backup dosyaları sağlam olsa bile encryption key kaybedilirse restore yapılamayabilir.

Bu nedenle key backup ve key recovery süreçleri ayrıca planlanmalıdır.

Cloud Backup Egress Maliyeti Nedir?

Buluttan veri dışarı çıkarılırken oluşan network maliyetine çoğu zaman:

Egress Cost

denir.

Backup yüklemek ucuz olabilir.

Ancak büyük bir felaket sırasında 50 TB veriyi geri çekmek ciddi maliyet oluşturabilir.

Bu nedenle cloud backup maliyet hesabı yalnızca storage ücretine göre yapılmamalıdır.

Restore Maliyeti Önceden Hesaplanmalı mı?

Kesinlikle.

Örneğin kurum 100 TB backup saklıyor olabilir.

Felaket sırasında tüm verinin restore edilmesi gerekirse;

API request,

retrieval,

egress,

compute,

storage

maliyetleri oluşabilir.

Bu yüzden disaster recovery bütçesi önceden planlanmalıdır.

Archive Storage Nedir?

Cloud sağlayıcıları düşük maliyetli archive storage sınıfları sunabilir.

Bu storage genellikle uzun süreli backup için uygundur.

Ancak restore süresi daha uzun olabilir.

Archive Storage RTO’yu Nasıl Etkiler?

Archive katmanından veri restore edilmeden önce:

rehydration

işlemi gerekebilir.

Bu işlem saatler sürebilir.

Dolayısıyla RTO çok düşükse tüm backup’ın archive üzerinde tutulması uygun olmayabilir.

Hot, Cool ve Archive Storage Katmanları

Cloud storage genellikle farklı erişim katmanlarına ayrılır.

Hot Storage

Sık erişilen veri.

Hızlı restore.

Daha yüksek storage maliyeti.

Cool Storage

Daha az erişilen veri.

Orta maliyet.

Archive Storage

Çok az erişilen veri.

Düşük saklama maliyeti.

Daha uzun restore süresi.

Backup retention stratejisinde bu katmanlar birlikte kullanılabilir.

Lifecycle Policy Nedir?

Lifecycle Policy, backup object’lerinin zamanla farklı storage katmanlarına otomatik taşınmasını sağlar.

Örneğin:

0–30 gün → Hot

31–90 gün → Cool

90 günden sonra → Archive

Bu şekilde maliyet optimize edilebilir.

Lifecycle Policy Yanlış Yapılandırılırsa Ne Olur?

Backup çok erken archive katmanına taşınabilir.

Bu da acil restore sırasında gecikme yaratabilir.

Bu nedenle policy RTO hedefleriyle uyumlu olmalıdır.

Multi-Cloud Backup Nedir?

Multi-Cloud Backup, backup verilerinin birden fazla cloud sağlayıcı veya cloud platformu üzerinde tutulmasıdır.

Örneğin production bir cloud’da çalışırken backup başka cloud’da tutulabilir.

Multi-Cloud Backup Avantajları

• Provider bağımlılığını azaltabilir.
• Büyük provider outage riskine karşı koruma sağlar.
• Vendor lock-in’i azaltabilir.
• Coğrafi çeşitlilik sağlar.

Multi-Cloud Backup Dezavantajları

• Yönetim karmaşıklığı
• Farklı IAM yapıları
• Network maliyeti
• Egress maliyeti
• Encryption key yönetimi
• Operasyonel yük

artabilir.

Bu nedenle her kurum için gerekli değildir.

Cloud-to-Cloud Backup Nedir?

Cloud-to-Cloud Backup, bir cloud servisindeki verinin başka cloud ortamına veya bağımsız backup platformuna kopyalanmasıdır.

Örneğin:

Microsoft 365

↓

Cloud Backup Platform

Bu yaklaşım SaaS backup için çok yaygındır.

SaaS Verileri Neden Ayrıca Yedeklenmeli?

SaaS sağlayıcısı platformun çalışmasını sağlar.

Ancak kullanıcı;

yanlışlıkla dosya silebilir,

mail silebilir,

hesabı compromise olabilir,

ransomware ile OneDrive dosyaları şifrelenebilir.

Bu nedenle SaaS backup ayrıca değerlendirilmelidir.

Microsoft 365 Cloud Backup Örneği

Bir kurumun tüm e-posta ve dosyaları Microsoft 365 üzerinde olabilir.

Backup çözümü;

Exchange Online,

OneDrive,

SharePoint,

Teams

verilerini ayrı storage ortamına kopyalayabilir.

Bu sayede silinen veya bozulan veriler bağımsız backup’tan geri getirilebilir.

Cloud-Native Database Backup

Cloud database servisleri kendi backup özelliklerini sunabilir.

Örneğin otomatik snapshot veya point-in-time recovery bulunabilir.

Ancak kritik sistemlerde;

retention,

region,

account,

immutable copy

gibi konular ayrıca değerlendirilmelidir.

Point-in-Time Recovery Cloud Database İçin Neden Önemli?

Yanlış SQL komutu saat 14:30’da kritik tabloyu silmiş olabilir.

Günlük backup’a dönmek saatlerce veri kaybına yol açabilir.

Point-in-Time Recovery ile:

14:29

gibi bir zamana dönmek mümkün olabilir.

Container ve Kubernetes Backup

Modern cloud ortamlarında yalnızca VM backup yeterli değildir.

Kubernetes ortamlarında;

etcd,

persistent volume,

namespace,

secret,

configuration,

application manifest

gibi bileşenler backup planına dahil edilmelidir.

Kubernetes Disaster Recovery Neden Farklıdır?

Container’lar stateless olabilir.

Ancak application state;

database,

persistent volume,

object storage

üzerinde bulunabilir.

Bu nedenle Kubernetes backup yalnızca container image saklamak değildir.

Infrastructure as Code Backup Gerekir mi?

Cloud altyapısı kodla yönetiliyorsa;

Terraform,

Ansible,

CloudFormation

gibi configuration dosyaları kritik recovery varlığıdır.

Bu dosyalar version control içerisinde güvenli şekilde korunmalıdır.

Git Repository Backup Gerekir mi?

Evet.

Kod repository’leri SaaS üzerinde bulunabilir.

Ancak kritik source code’un ayrıca backup’ı alınabilir.

Çünkü account compromise veya yanlış silme riski vardır.

Cloud Backup Monitoring

Backup job’ların başarılı olup olmadığı merkezi olarak izlenmelidir.

Örneğin;

backup failed,

repository unavailable,

retention changed,

immutability disabled,

admin login,

restore point deleted

gibi olaylar alarm üretebilir.

Cloud Backup Logları SIEM’e Gönderilmeli mi?

Kritik ortamlarda evet.

Cloud audit log’ları;

administrator işlemleri,

API kullanımı,

IAM değişikliği,

Object Lock değişikliği

gibi olayları gösterebilir.

Bu loglar SIEM üzerinden analiz edilebilir.

Cloud Backup İçin Zero Trust Yaklaşımı

Modern cloud backup ortamlarında Zero Trust prensipleri uygulanabilir.

Örneğin;

her erişimi doğrula,

minimum yetki ver,

ayrı identity kullan,

MFA uygula,

network erişimini sınırlandır,

logları izle.

Backup storage sıradan cloud kaynaklarından daha kritik kabul edilmelidir.

Private Endpoint Nedir?

Cloud storage erişimi public internet yerine private network üzerinden gerçekleştirilebilir.

Bu yapı:

Private Endpoint

veya benzeri teknolojilerle sağlanabilir.

Bu sayede backup storage’ın public exposure riski azaltılabilir.

Cloud Backup Public Olmamalı

Object storage bucket veya backup repository yanlışlıkla public yapılmamalıdır.

Bu durum ciddi veri ihlaline neden olabilir.

Backup içerisinde kurumun tüm kritik verileri bulunabilir.

Bu nedenle storage access policy düzenli olarak kontrol edilmelidir.

Cloud Backup Misconfiguration Riski

Cloud güvenlik olaylarının önemli bir bölümü yanlış yapılandırmadan kaynaklanabilir.

Örneğin;

public bucket,

fazla IAM yetkisi,

MFA eksikliği,

exposed API key,

encryption kapalı olması

gibi hatalar backup güvenliğini etkileyebilir.

Backup Account’ta Break-Glass User Olmalı mı?

Kritik ortamlarda bağımsız acil durum hesabı değerlendirilebilir.

Production identity sistemi çalışmasa bile backup ortamına erişilebilmelidir.

Bu hesap;

offline korunmalı,

çok güçlü authentication kullanmalı,

sadece acil durumda kullanılmalıdır.

Cloud Provider Tamamen Erişilemezse Ne Olur?

Bu nadir ancak kritik senaryodur.

Kurum backup ve production sistemlerini aynı sağlayıcıda tutuyorsa provider-wide outage durumunda iki taraf da etkilenebilir.

Bu nedenle kritik kurumlarda;

offsite,

multi-region,

multi-cloud,

offline copy

gibi seçenekler değerlendirilebilir.

Cloud Exit Plan Nedir?

Cloud Exit Plan, kurumun mevcut cloud sağlayıcısından ayrılması veya verileri başka ortama taşıması gerektiğinde izleyeceği plandır.

Bu;

sağlayıcı değişimi,

maliyet artışı,

regülasyon,

teknik sorun,

provider failure

nedeniyle gerekebilir.

Backup Cloud Exit Plan’ın Parçası mıdır?

Evet.

Kurum backup verilerinin standart formatta dışarı çıkarılabilir olup olmadığını bilmelidir.

Vendor’a özel formatlar uzun vadeli bağımlılık oluşturabilir.

Vendor Lock-In Nedir?

Vendor Lock-In, kurumun teknik veya ekonomik olarak belirli bir sağlayıcıdan çıkmasının çok zor hale gelmesidir.

Backup stratejisinde;

standard format,

S3-compatible storage,

export capability

gibi özellikler vendor lock-in riskini azaltabilir.

Cloud Backup SLA Nasıl Değerlendirilmeli?

Yalnızca platform uptime’ına bakılmamalıdır.

Ayrıca;

restore time,

support response,

data durability,

service availability,

incident notification

gibi konular değerlendirilmelidir.

Restore SLA Neden Önemlidir?

Backup’ın bulunması yeterli değildir.

Kurum felaket anında veriyi ne kadar hızlı alabileceğini bilmelidir.

Özellikle managed BaaS kullanılıyorsa restore süreci servis sağlayıcıya bağlı olabilir.

BaaS Sağlayıcısına Sorulması Gereken Sorular

BaaS seçerken şu sorular sorulabilir:

Backup verisi hangi ülkede?

Data center sertifikaları neler?

Backup immutable mı?

Encryption nasıl uygulanıyor?

Encryption key kimde?

MFA var mı?

RPO/RTO nasıl sağlanıyor?

Restore testleri nasıl yapılıyor?

Data export mümkün mü?

Hizmet sona ererse backup nasıl teslim edilir?

Bu sorular teknik ve sözleşmesel açıdan önemlidir.

DRaaS Sağlayıcısına Sorulması Gereken Sorular

DRaaS için ayrıca;

Failover nasıl başlatılıyor?

Test failover mümkün mü?

RTO garanti ediliyor mu?

RPO nasıl ölçülüyor?

Network kapasitesi ne kadar?

Public IP ve DNS nasıl yönetiliyor?

Failback nasıl yapılıyor?

DR ortamı ransomware’den nasıl korunuyor?

soruları değerlendirilmelidir.

Shared Responsibility Model Nedir?

Cloud güvenliğinin temel kavramlarından biri:

Shared Responsibility Model

yani:

Paylaşılan Sorumluluk Modelidir.

Cloud sağlayıcısı belirli altyapı katmanlarından sorumludur.

Müşteri ise;

hesap güvenliği,

IAM,

veri sınıflandırma,

retention,

backup,

configuration

gibi alanlardan sorumlu olabilir.

Sorumluluk kullanılan hizmet modeline göre değişebilir.

Cloud Sağlayıcı Backup’tan Tamamen Sorumlu mudur?

Genellikle hayır.

Bu nedenle hizmet sözleşmesinin ve paylaşılan sorumluluk modelinin incelenmesi gerekir.

“Kullandığımız servis cloud’da, dolayısıyla sağlayıcı her şeyi yedekliyor.” varsayımı yapılmamalıdır.

Cloud Backup KVKK Açısından Nasıl Değerlendirilir?

Backup içerisinde kişisel veri varsa backup da kişisel veri içerir.

Dolayısıyla;

erişim kontrolü,

retention,

şifreleme,

veri aktarımı,

silme süreçleri

değerlendirilmelidir.

Cloud lokasyonunun yurtdışında olması halinde veri aktarımı gereksinimleri ayrıca incelenmelidir.

Backup Retention ile KVKK Silme Süreçleri Çelişebilir mi?

Yanlış tasarlanırsa evet.

Örneğin kişisel verinin silinmesi gereken tarihten çok daha uzun immutable retention uygulanırsa operasyonel ve hukuki değerlendirme gerekebilir.

Bu nedenle backup retention politikası yalnızca teknik ekip tarafından belirlenmemelidir.

ISO 27001 ve Cloud Backup

ISO/IEC 27001 açısından bilgi varlıklarının;

gizlilik,

bütünlük,

erişilebilirlik

gereksinimleri değerlendirilmelidir.

Cloud backup;

erişilebilirlik,

recovery,

veri bütünlüğü

hedeflerini destekleyebilir.

Ancak erişim kontrolü ve restore testleri de gereklidir.

ISO 22301 ve Cloud DR

ISO 22301 iş sürekliliği açısından kritik süreçlerin kabul edilebilir süre içerisinde devam ettirilmesini hedefler.

Cloud DR veya DRaaS bu hedefleri teknik olarak destekleyebilir.

Ancak gerçek recovery kapasitesi tatbikatla doğrulanmalıdır.

Cloud Backup İçin Örnek Mimari

Kurumsal bir yapı şu şekilde olabilir:

Production Cloud Account

↓

Daily / Hourly Backup

↓

Separate Backup Account

↓

Immutable Object Storage

↓

Cross-Region Copy

↓

Long-Term Archive

Bu mimari farklı failure domain’ler oluşturur.

Hybrid Cloud Backup Mimarisi

Hybrid yapıda;

On-Prem Production

↓

Local Backup

↓

Cloud Backup

↓

Immutable Object Storage

kullanılabilir.

Bu sayede hızlı local restore ile offsite güvenlik birlikte sağlanır.

Multi-Layer Backup Yaklaşımı

Modern backup tek storage üzerinde tutulmamalıdır.

Örnek:

Katman 1:

Local backup – hızlı restore

Katman 2:

Cloud immutable copy – ransomware koruması

Katman 3:

Archive/offline copy – uzun süreli koruma

Bu yaklaşım farklı risklere karşı farklı koruma katmanları oluşturur.

Cloud Backup RPO Nasıl Belirlenir?

RPO iş ihtiyacına göre belirlenmelidir.

Örneğin:

Tier 1 sistemi → 15 dakika

Tier 2 sistemi → 4 saat

Tier 3 sistemi → 24 saat

Cloud backup job sıklığı bu gereksinime göre ayarlanır.

Cloud Backup RTO Nasıl Belirlenir?

RTO restore süresiyle doğrudan ilişkilidir.

Örneğin 50 TB backup archive storage’da bulunuyorsa kısa RTO sağlamak zor olabilir.

Bu nedenle kritik sistemlerin son restore point’leri hot storage üzerinde tutulabilir.

Cloud Backup Restore Testi Nasıl Yapılmalı?

Belirli aralıklarla gerçek restore yapılmalıdır.

Örneğin;

VM restore,

file restore,

database restore,

application restore

test edilebilir.

Ayrıca farklı region veya account’tan recovery senaryoları da çalışılmalıdır.

Cloud Backup Tatbikatı Neden Önemlidir?

Cloud platformlarının birçok otomasyon özelliği olabilir.

Ancak yanlış IAM policy,

eksik network route,

expired secret,

DNS problemi

felaket sırasında recovery’yi durdurabilir.

Bu nedenle gerçek test yapılmalıdır.

Cloud Backup İçin En Sık Yapılan Hatalar

Kurumlarda sık karşılaşılan hatalar şunlardır:

• Cloud redundancy’yi backup sanmak,
• snapshot’ı bağımsız backup kabul etmek,
• production ve backup’ı aynı account’ta tutmak,
• MFA kullanmamak,
• Object Lock kullanmamak,
• public storage yapılandırmak,
• encryption key planlamamak,
• egress maliyetini hesaplamamak,
• archive storage nedeniyle RTO’yu kaçırmak,
• restore testi yapmamak,
• SaaS verilerini backup dışı bırakmak,
• cloud provider’ın her şeyi yedeklediğini varsaymak.

Cloud Backup Stratejisi İçin Kontrol Listesi

Kurum şu sorulara cevap verebilmelidir:

Hangi cloud verilerini yedekliyoruz?

Backup hangi account’ta?

Backup hangi region’da?

Immutable mı?

Cross-region copy var mı?

MFA kullanılıyor mu?

IAM minimum yetkili mi?

Encryption aktif mi?

Key’ler nerede?

Restore süresi nedir?

Egress maliyeti nedir?

Restore test edildi mi?

Bu sorular modern cloud backup olgunluğunu ortaya çıkarır.

Sonuç: Cloud Altyapısı Backup İhtiyacını Ortadan Kaldırmaz

Cloud teknolojileri;

yüksek ölçeklenebilirlik,

yüksek erişilebilirlik,

coğrafi çeşitlilik,

otomasyon

gibi büyük avantajlar sağlar.

Ancak cloud kullanmak verinin otomatik olarak her tehdide karşı güvende olduğu anlamına gelmez.

Yanlış silme,

ransomware,

administrator account compromise,

IAM hatası,

region failure,

SaaS veri kaybı

gibi riskler devam eder.

Bu nedenle modern bulut stratejisinde backup ayrıca tasarlanmalıdır.

Güçlü bir cloud backup mimarisinde;

BaaS,

DRaaS,

Immutable Object Storage,

Object Lock,

Cross-Region Backup,

Cross-Account Backup,

Encryption,

MFA,

Least Privilege

ve Restore Testing

birlikte değerlendirilebilir.

En kritik prensip ise şudur:

Production cloud hesabının ele geçirilmesi, backup verisinin de ele geçirilmesi anlamına gelmemelidir.

Bu nedenle backup için mümkün olduğunca ayrı;

identity,

account,

region

ve retention boundary

oluşturulmalıdır.

Cloud backup’ın gerçek değeri yalnızca verinin bulutta bulunması değildir.

Gerçek değer:

üretim ortamı tamamen kaybedildiğinde kurumun güvenli, temiz ve bağımsız bir restore point’e hâlâ sahip olmasıdır.