Merhaba
Bölüm 3’ten Bu Yana: Kopyalar Var, Peki Güvende mi?
Bölüm 3‘te 3-2-1-1-0 kuralını inceledik ve dördüncü rakamın, yani offline, air-gapped veya immutable kopyanın fidye yazılımı çağında kritik olduğunu gördük. Bu bölümde o rakamın arkasındaki mekanizmalara iniyoruz. Dört kavram sıkça birbirine karıştırılır: snapshot (anlık görüntü), CDP (Continuous Data Protection), immutability (değiştirilemezlik) ve air-gap (ağdan yalıtım). Her biri farklı bir soruyu cevaplar. Snapshot ve CDP ne kadar veri kaybedeceğimizi, immutability ve air-gap ise yedeğin saldırıdan sağ çıkıp çıkmayacağını belirler.
Ürün örneklerinde yine Gartner’ın Mayıs 2026 tarihli Backup and Data Protection Platforms Magic Quadrant raporunda Leaders (Liderler) çeyreğinde yer alan altı üreticiyi esas alıyoruz: Veeam, Commvault, Cohesity, Rubrik, Druva ve Dell Technologies.
Dört kavramın karşılaştırması
| Kavram | Cevapladığı soru | Ne sağlar | Ne sağlamaz |
|---|---|---|---|
| Snapshot (Anlık görüntü) | Hızlıca geri dönebilir miyim? | Kısa süreli geri alma noktası | Bağımsız kopya olmaz, kasıtlı silmeye karşı koruma sunmaz |
| CDP (Continuous Data Protection) | En fazla kaç saniyelik veri kaybederim? | Çok düşük veri kaybı penceresi | Silinmeye veya şifrelenmeye karşı tek başına koruma sunmaz |
| Immutability (Değiştirilemezlik) | Yedek silinebilir veya değiştirilebilir mi? | Saklama süresi boyunca silmeye ve değiştirmeye karşı direnç | Yanlış yapılandırılmış veya zaten bozuk veriyi düzeltmez |
| Air-gap (Ağdan yalıtım) | Saldırgan yedeğe ulaşabilir mi? | Erişim yolunun kesilmesi veya sınırlanması | Yedeğin geri yüklenebilirliğini garanti etmez |
Snapshot Yedek Değildir
Snapshot, bir sistemin belirli bir andaki durumunu hızla yakalayan ve çoğu zaman aynı depolama üzerinde tutulan bir geri alma noktasıdır. Yama öncesi hızlı geri dönüş için çok değerlidir. Ancak aynı depolama üzerinde durduğu için aynı hata alanını paylaşır: depolama dizisi arızalanırsa, silinirse veya şifrelenirse snapshot da onunla birlikte gider. Bu nedenle snapshot kendi başına yedek sayılmaz, yalnızca başka bir sisteme veya lokasyona kopyalandığında yedeğe yaklaşır.
Snapshot teknolojisi de kendi içinde farklılaşır. Klasik VMware sanal makine snapshot’ı değişiklikleri delta disk dosyalarına yazar ve bu dosyalar orijinal diske bağımlıdır. Snapshot ne kadar uzun yaşarsa zincir o kadar büyür, konsolidasyon o kadar uzar ve okuma işlemleri birden fazla delta dosyasına yayılır. Depolama dizilerinin kendi snapshot mekanizmaları ise iki ana yöntemle çalışır. Aşağıdaki tablo bu yöntemleri karşılaştırır.
Snapshot yöntemlerinin karşılaştırması
| Yöntem | Çalışma şekli | Performans etkisi | Dikkat edilecek nokta |
|---|---|---|---|
| VMware VM (Virtual Machine) snapshot, delta disk | Değişiklikler ayrı delta dosyalarına yazılır, orijinal disk dondurulur | Zincir uzadıkça okuma ve konsolidasyon yavaşlar | Kısa süreli kullanım için tasarlanmıştır, unutulan snapshot’lar tipik bir sorundur |
| Copy-on-Write (Yazarken kopyala) | Blok değişmeden önce eski blok snapshot alanına kopyalanır | İlk yazmada ek okuma ve yazma maliyeti | Yoğun yazma altında performans düşüşü görülebilir |
| Redirect-on-Write (Yazarken yönlendir) | Yeni yazmalar yeni konuma yönlendirilir, eski blok yerinde kalır | Yazma cezası düşüktür | Snapshot silindiğinde blok yönetimi depolama yazılımına bağlıdır |
| Application-consistent snapshot (Uygulama tutarlı) | Uygulama veya VSS (Volume Shadow Copy Service) ile bellekteki veri diske yazdırılarak snapshot alınır | Kısa bir dondurma anı oluşur | Bölüm 1’deki tutarlılık seviyeleriyle birlikte düşünülmelidir |
CDP: Saniyelere İnen Veri Kaybı Penceresi
Geleneksel snapshot tabanlı yedekleme belirli aralıklarla çalışır, dolayısıyla veri kaybı penceresi (RPO, Recovery Point Objective) aralığın uzunluğuna eşittir. Veeam’in 2021 tarihli v11 duyurusu, snapshot tabanlı yedeklemelerde bu pencereyi depolamaya bağlı olarak 5 ile 15 dakika arasında tarif eder. CDP ise yazma işlemlerini sürekli yakalayarak bu pencereyi saniyelere indirmeyi hedefler. Aşağıdaki şekil iki yaklaşımı karşılaştırmaktadır.
Veeam CDP Nasıl Çalışır?
Veeam CDP, VMware vSphere ortamı için VAIO (vSphere APIs for Input/Output Filtering) mekanizmasına dayanır. Bu mekanizma, hipervizörün I/O (Input/Output) işlemlerini oluştukları anda yakalamaya izin verir. Veeam bu amaçla cluster’daki host’lara bir CDP I/O filter yükler. Yakalanan yazmalar CDP Proxy üzerinden hedef sitedeki replikaya aktarılır ve replika sürekli güncel tutulur.
Kurtarma noktaları iki katmanda saklanır. Short-term retention (kısa süreli saklama) katmanında saniye aralıklarıyla bir zamana geri dönülebilir ve hedef kurtarma noktası en düşük iki saniyeden başlayarak ayarlanabilir. Long-term retention (uzun süreli saklama) katmanında ise saatlik kurtarma noktaları oluşturulur, bunlar application-aware (uygulama farkında) işlemeyi kullanabilir ve her zaman crash-consistent (çökme tutarlı) bir nokta içerir. Replikalar çalıştırılmaya hazır tutulduğu için RTO (Recovery Time Objective) de düşüktür.
Backup, Replication ve CDP karşılaştırması
| Yöntem | Tipik RPO (Recovery Point Objective) | Tipik RTO (Recovery Time Objective) | Kaynak yükü | Uygun iş yükü |
|---|---|---|---|---|
| Snapshot tabanlı backup | Dakikalar ile saatler | Geri yükleme süresine bağlı | Düşük, aralıklı | Çoğu iş yükü |
| Replication (Replikasyon) | Dakikalar | Düşük, replika hazır bekler | Orta, aralıklı | Önemli ama kritik olmayan sanal makineler |
| CDP (Continuous Data Protection) | Saniyeler | Düşük, replika hazır bekler | Sürekli, her yazma aktarılır | Kritik, kayıp toleransı çok düşük sistemler |
CDP Bant Genişliği Nasıl Boyutlandırılır?
CDP’nin maliyeti yazma yüküyle doğru orantılıdır, çünkü sürekli aktarım yapar. Kaba bir üst sınır hesabı için bir sanal makine (Virtual Machine) grubunun ortalama yazma hızını Mbit/s değerine çevirmek yeterlidir: Gereken hız (Mbit/s) = Ortalama yazma hızı (MB/s) x 8. Aşağıdaki tablo bu hesabı dört örnek yazma hızı için gösterir. Gerçek değerler sıkıştırma, aynı bloğa tekrarlı yazma ve ürün optimizasyonlarına göre değişir. Veeam’in CDP Infrastructure Assessment (CDP altyapı değerlendirmesi) aracı gerçek ortam için CPU (Central Processing Unit), RAM (bellek) ve ağ ihtiyacını değerlendirmek üzere tasarlanmıştır.
CDP için örnek bant genişliği ve günlük aktarım hesabı
| Ortalama yazma hızı | Gereken hat hızı (Mbit/s) | Günlük aktarılan veri (GB) | Günlük aktarılan veri (TB) |
|---|---|---|---|
| 5 MB/s | 40 | 432 | 0,43 |
| 20 MB/s | 160 | 1728 | 1,73 |
| 50 MB/s | 400 | 4320 | 4,32 |
| 100 MB/s | 800 | 8640 | 8,64 |
Immutability: Yedeği Değiştirilemez Kılmak
Immutability, bir yedek kopyanın belirli bir saklama süresi boyunca silinememesi ve değiştirilememesidir. Fidye yazılımı saldırganları yedekleri hedef aldığı için bu özellik 3-2-1-1-0 kuralındaki dördüncü rakamın pratik karşılığıdır. Ancak immutability tek bir şey değildir. Korumanın nerede uygulandığı, yani yazılımda mı, işletim sisteminde mi, depolama servisinde mi, fiziksel ortamda mı olduğu, direncini belirler. Aşağıdaki şekil bu seviyeleri sıralar.
Immutability seviyeleri
| Seviye | Koruma nerede uygulanır | Neye karşı koruyabilir | Zayıf nokta |
|---|---|---|---|
| Yazılım düzeyinde kilit | Yedekleme yazılımı kendi kuralını uygular | Yanlışlıkla silme | Yazılıma ve yönetici hesaplarına erişen saldırgan kuralı atlayabilir |
| Hardened Repository (Sertleştirilmiş depo) | Linux işletim sistemi dosya özelliği | Ele geçirilmiş yedekleme sunucusu hesabı | Host üzerinde root erişimi, out-of-band yönetim arayüzleri |
| S3 Object Lock, Governance Mode | Nesne depolama servisi | Sıradan yetkisiz silme | Özel bypass izni olan yetkili hesap kilidi atlayabilir |
| S3 Object Lock, Compliance Mode | Nesne depolama servisi | Yetkili hesap dahil silme girişimleri | Saklama süresi kısaltılamaz, yanlış süre maliyetli olur |
| Offline veya air-gapped kopya | Fiziksel veya mantıksal ayrım | Ağ üzerinden gelen her saldırı | Geri yükleme yavaştır, operasyonel çaba gerekir |
Hardened Repository Nasıl Çalışır?
Veeam Hardened Repository, immutability’yi yedekleme yazılımına değil işletim sistemine yaptırır. Aşağıdaki şekil mekanizmayı özetler. Linux host üzerindeki XFS dosya sisteminde her yedek dosyasına immutable (değiştirilemez) özniteliği verilir ve bitiş zamanı ayrı bir genişletilmiş öznitelikte tutulur. Yerel çalışan ve ağ erişimi olmayan bir immutability servisi bu özniteliği düzenli aralıklarla (yaklaşık 20 dakikada bir) ayarlar ve kaldırır. Yedek verisini alan Data Mover ise root olmayan bir kullanıcıyla çalışır.
İkinci temel unsur single-use credentials (tek kullanımlık kimlik bilgileri) yaklaşımıdır. Yönetilen kurulumlarda host’u devreye almak için kullanılan kimlik bilgisi yedekleme sunucusunda saklanmaz, SSH (Secure Shell) erişimi kapatılır ve root ile oturum açılamaz. Böylece yedekleme sunucusunu ele geçiren saldırgan, repository host’una kalıcı bir yönetici erişimi bulamaz. Immutability süresi repository üzerinde tanımlanır, en az 7 gündür ve saklama politikasından uzun olmaması önerilir. Bu modelde yalnızca forward incremental zincir tipi kullanılabilir, bu nedenle zincirin bütünlüğü için bazı kurtarma noktaları saklama süresinden daha uzun tutulabilir.
Immutability Kapasiteyi Nasıl Etkiler?
Immutable veri saklama süresi dolmadan silinemediği için kapasite planlaması da etkilenir. Süre uzadıkça tutulan veri doğrusal olarak artar. Aşağıdaki hesap basit bir modeli kullanır: 100 TB korunan veri, %2 günlük değişim ve 2:1 veri azaltma. Bu durumda tek bir full yedek yaklaşık 50 TB, günlük artımlı yedek ise yaklaşık 1 TB yer kaplar. GFS (Grandfather-Father-Son) saklama, synthetic full ve ek kopyalar bu rakamların üzerine eklenir.
Immutability süresine göre kapasite hesabı (basit model)
| Immutability süresi | Full yedek (TB) | Artımlı yedekler (TB) | Toplam kapasite (TB) |
|---|---|---|---|
| 14 gün | 50 | 14 | 64 |
| 30 gün | 50 | 30 | 80 |
| 90 gün | 50 | 90 | 140 |
Air-gap: Erişim Yolunu Kesmek
Air-gap, yedeğe ulaşan yolun fiziksel veya mantıksal olarak kesilmesi veya sınırlanmasıdır. Immutability yedeğin silinmesini zorlaştırırken air-gap saldırganın yedeğe ulaşmasını zorlaştırır. İkisi birbirini tamamlar. Terim pazarlamada geniş kullanıldığı için üç farklı türü birbirinden ayırmak önemlidir.
Air-gap türleri
| Tür | Nasıl sağlanır | Güçlü yön | Zayıf yön |
|---|---|---|---|
| Physical air-gap (Fiziksel) | Bant veya disk çıkarılıp ağdan bağımsız saklanır | Ağ saldırılarına karşı en güçlü ayrım | Yavaş geri yükleme, fiziksel operasyon, kasa güvenliği |
| Network air-gap (Ağ ayrımı) | Yedek ortamı yalnızca belirli pencerelerde bağlanır | Otomasyonla yönetilebilir | Bağlantı penceresinde açık kalır, yapılandırma hatasına duyarlıdır |
| Logical air-gap (Mantıksal) | Ayrı kimlik alanı, ayrı kiracı, değiştirilemez depo ve kontrollü erişim arayüzü | Operasyonu kolay, bulutta ölçeklenir | Koruma yazılım ve yapılandırmaya dayanır, tanımı üreticiden üreticiye değişir |
Hangi Saldırıya Karşı Hangi Koruma?
Aşağıdaki tablo, farklı tehditlere karşı her korumanın genel davranışını özetler. Tablo kaba bir çerçevedir, gerçek sonuç yapılandırmaya ve kimlik ayrımına bağlıdır.
Tablo 8: Tehdit ve koruma eşlemesi
| Tehdit | Local Snapshot | Hardened Repository | Object Lock Governance | Object Lock Compliance | Offline kopya |
|---|---|---|---|---|---|
| Yönetici hatası ile silme | Korur | Korur | Korur | Korur | Korur |
| Ele geçirilmiş yedekleme yöneticisi hesabı | Korumaz | Korur | Kısmen | Korur | Korur |
| Repository host’unda root erişimi | Korumaz | Korumaz | Uygulanmaz | Uygulanmaz | Korur |
| Ele geçirilmiş bulut hesabı | Uygulanmaz | Uygulanmaz | Korumaz | Korur | Korur |
| Depolama dizisi arızası | Korumaz | Korur | Korur | Korur | Korur |
| Fiziksel veya out-of-band erişim | Korumaz | Korumaz | Uygulanmaz | Uygulanmaz | Kısmen |
Leaders Üreticilerin Yaklaşımı
Her üretici immutability ve air-gap kavramlarını farklı isimlerle sunar. Aşağıdaki tablo yalnızca doğrulanabilen ifadeleri içerir. Üretici dokümanlarından doğrulayamadığım hücrelerde ‘üretici dokümanına bakınız’ yazılmıştır.
Leaders çeyreğindeki üreticilerin immutability ve air-gap yaklaşımı
| Vendor (Üretici) | Immutability yaklaşımı | Air-gap yaklaşımı | Not |
|---|---|---|---|
| Veeam | Hardened Repository, S3 Object Lock Compliance Mode | Çıkarılmış bant, yönetilen bulut seçenekleri (üretici dokümanına bakınız) | Mimariyi müşteri tasarlar, host sertleştirme müşteri sorumluluğundadır |
| Commvault | WORM (Write Once Read Many) koruması, S3 Object Lock gibi hedef kontrolleri | Air Gap Protect: yönetilen bulut depolama hedefi, air-gapped ve immutable güvenlik alanı, AES-256 şifreleme | Çapraz bölge ve çapraz bulut kopyaları için müşteri yönetimli MediaAgent gerekir |
| Cohesity | DataLock (kurtarma noktalarında WORM), ayrı Data Security rolü, quorum onayı | FortKnox: yönetilen izole bulut vault’u, mantıksal air-gap | Quorum veya MFA (Multi-Factor Authentication) yapılandırması üretici belgelerine bağlıdır |
| Rubrik | Append-only dosya sistemi, Retention Lock | Cloud Vault: yönetilen, air-gapped bulut yedek depolaması | Retention Lock yalnızca onu etkinleştiren SLA kapsamındaki iş yüklerini korur |
| Druva | Üretici dokümanına bakınız | Tamamen yönetilen SaaS (Software as a Service) mimarisi | Kopya yönetimi üretici bulutundadır |
| Dell Technologies | Üretici dokümanına bakınız | Üretici dokümanına bakınız | Cyber Recovery vault ayrıntıları Bölüm 5’te ele alınacaktır |
Immutability ve Air-gap Test Listesi
Bir kopyanın immutable veya air-gapped olduğunu ürün sayfasına bakarak değil, deneyerek doğrulayın. Aşağıdaki liste, bir yedek ortamında yapılabilecek temel testleri özetler. Testleri üretim verisinde değil, ayrı bir test işi ve test kopyası üzerinde çalıştırın.
Tablo 10: Immutability ve air-gap doğrulama testleri
| Test | Neden önemli | Beklenen sonuç |
|---|---|---|
| Yedekleme yöneticisi hesabıyla immutable kopyayı silmeyi dene | Ele geçirilmiş yönetici senaryosunu doğrular | Silme reddedilir |
| Bulut hesabının yönetici rolüyle Object Lock’lı sürümü silmeyi dene | Governance ve Compliance farkını görünür kılar | Compliance Mode’da silme reddedilir |
| Repository host’una SSH (Secure Shell) ile root olarak girmeyi dene | Single-use credentials uygulamasını doğrular | Erişim yoktur veya kapalıdır |
| Out-of-band yönetim arayüzünün ağ erişimini kontrol et | Fiziksel düzeydeki ihmali yakalar | Arayüz ayrı ağdadır ve MFA (Multi-Factor Authentication) ile korunur |
| Zaman senkronizasyonu (NTP, Network Time Protocol) kaynağının güvenliğini gözden geçir | Bitiş zamanının manipüle edilmesini önler | Güvenilir ve izlenen zaman kaynağı kullanılır |
| Immutable kopyadan örnek geri yükleme yap | 3-2-1-1-0 kuralındaki sıfır hata şartını doğrular | Geri yükleme başarılı ve tutarlıdır |
| Yedekleme yönetim hesaplarının ayrı kimlik alanında olduğunu doğrula | Bölüm 1’deki güven sınırı ilkesini sınar | Production kimlik bilgileriyle erişim yoktur |
Sonuç ve Sonraki Bölüm
Snapshot hızlı geri dönüş sağlar ama bağımsız bir kopya değildir. CDP veri kaybı penceresini saniyelere indirir ama bozulmuş veriyi de hızla taşıyabilir. Immutability silmeyi zorlaştırır, ancak direnci uygulandığı katmana bağlıdır: yazılım, işletim sistemi, depolama servisi veya fiziksel ortam. Air-gap saldırganın yedeğe ulaşmasını zorlaştırır, ancak terimin ne anlama geldiği üreticiden üreticiye değişir. Aradığınız cevap bu kavramların hiçbirinin adında değil, saldırgan yetkili bir hesabı ele geçirdiğinde yedeğin hala geri yüklenebilir olup olmadığındadır.
Serinin 5. bölümünde bu kopyaların nerede ve nasıl saklandığını, yani Cyber Recovery Vault ve DR (Disaster Recovery, Felaket Kurtarma) modellerini ele alıyoruz. İzole bir kurtarma ortamının nasıl tasarlandığını, temiz geri yüklemenin nasıl doğrulandığını ve olağan yedeklemeden farkını inceleyeceğiz.