Immutable Backup Nedir? Fidye Yazılımına Karşı Değiştirilemez Yedek

Fidye yazılımı saldırılarında üretim sunucularının şifrelenmesi çoğu zaman saldırının yalnızca ilk aşamasıdır. Saldırganlar yedekleri de silmeyi veya şifrelemeyi başarırsa kurumun elinde temiz bir kurtarma noktası kalmaz. Bu riske karşı geliştirilen yaklaşımın adı immutable backup, yani değiştirilemez yedektir: yazılan yedek belirlenen saklama süresi dolana kadar ne silinebilir ne de üzerine yazılabilir.

Bu rehber; immutable yedeklemenin nasıl çalıştığını, WORM depolama, S3 Object Lock ve hardened repository gibi teknik yöntemleri, klasik yedekleme ile farklarını ve kurulumda sık yapılan hataları ele alıyor. BT ekiplerinin kendi ortamlarına uygun modeli seçebilmesi için şirket içi ve bulut tabanlı seçenekler de karşılaştırılıyor.

Immutable Backup Nedir?

Teknik tanımıyla immutable backup, yedek verinin yazıldıktan sonra tanımlı bir süre boyunca değiştirilemediği, silinemediği ve şifrelenemediği yedekleme yöntemidir. Bu koruma, yedekleme yazılımının bir ayarından ibaret değildir; depolama katmanı tarafından uygulanır. Yedekleme sunucusunda yönetici yetkisi ele geçirilmiş olsa bile kilitli yedek bloklarına veya nesnelerine yapılan silme istekleri reddedilir.

Yöntemin temelinde WORM (Write Once, Read Many) prensibi vardır. Veri bir kez yazılır, istenildiği kadar okunabilir, ancak saklama süresi dolana kadar değiştirilemez. Saklama süresi sona erdiğinde yedek, normal yaşam döngüsü kurallarına göre temizlenebilir.

Değiştirilemez yedek, yani immutable backup kavramı sıklıkla şu terimlerle birlikte kullanılır:

• WORM depolama: Bir kez yazılıp çok kez okunan, değişikliğe kapalı depolama modeli.
• Object Lock: Nesne depolamada her nesne sürümüne saklama süresi veya yasal tutma (legal hold) uygulanması.
• Hardened repository: Veeam ortamında Linux tabanlı, değişmezlik bayrağıyla korunan yedek deposu.
• Air-gap: Yedeğin üretim ağından fiziksel veya mantıksal olarak yalıtılması.

Fidye Yazılımı Neden Önce Yedekleri Hedef Alır?

Saldırganın amacı fidyenin ödenmesidir ve bunun en güçlü yolu kurumun kendi başına kurtarma yapmasını engellemektir. ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı’nın #StopRansomware rehberi, birçok fidye yazılımı türünün erişilebilir yedekleri bulup silmeye veya şifrelemeye çalıştığını belirtir ve çevrim dışı, şifreli yedeklerin düzenli test edilmesini önerir.

Tipik bir saldırıda önce ağda yetki yükseltilir, ardından yedekleme sunucusu, hipervizör yönetimi ve depolama cihazları tespit edilir. Yedekler aynı Active Directory etki alanına bağlıysa ya da aynı yönetici hesabıyla erişilebiliyorsa, saldırgan şifrelemeyi başlatmadan önce yedek zincirini ortadan kaldırabilir. Bu senaryoda immutable backup, saldırganın elindeki yetki ne olursa olsun kilitli kopyalara dokunamamasını sağlar.

Immutable Backup Nasıl Çalışır? WORM, Object Lock ve Hardened Repository

Değişmezlik farklı katmanlarda uygulanabilir. Hangi yöntemin seçileceği, mevcut yedekleme yazılımına, depolama altyapısına ve saklama gereksinimlerine bağlıdır.

S3 Object Lock ile nesne düzeyinde kilit

S3 uyumlu nesne depolamada immutable backup kilidi, her nesne sürümüne ayrı ayrı uygulanır. AWS S3 Object Lock dokümantasyonuna göre iki mod bulunur: governance modunda özel izne sahip kullanıcılar kilidi değiştirebilir, compliance modunda ise saklama süresi boyunca hiçbir kullanıcı, kök hesap dahil, nesneyi silemez veya süreyi kısaltamaz. Object Lock yalnızca sürümleme (versioning) açık kovalarda çalışır.

Veeam hardened repository

Veeam ortamlarında yaygın yöntemlerden biri Linux tabanlı hardened repository kullanmaktır. Bu yapıda yedek dosyaları belirlenen gün sayısı boyunca değişmez olarak işaretlenir ve depo sunucusuna erişim tek kullanımlık kimlik bilgileriyle sınırlandırılır. Böylece yedekleme sunucusu ele geçirilse bile depodaki kilitli dosyalar silinemez.

Saklama süresi ve kurtarma penceresi

Bir immutable backup politikasında kilit süresi, kurumun bir saldırıyı ne kadar sürede fark edebileceğiyle ilişkilidir. Saldırganlar bazen haftalarca ağda fark edilmeden kalabilir; kilit süresi bu gizli kalma süresinden kısa tutulursa temiz kopyalar kilit kalktıktan sonra silinmiş olabilir. Saklama süresi hem bu riski hem de depolama maliyetini dengeleyecek şekilde belirlenmelidir.

Klasik Yedekleme ile Immutable Backup: Genel Uygulama ve Doğru Yaklaşım

Pek çok kurumda genel uygulama, yedekleri bir NAS cihazında veya ağ paylaşımında tutmaktır. Bu kopyalar donanım arızasına karşı koruma sağlar, ancak fidye yazılımına karşı aynı ölçüde dayanıklı değildir. Aşağıdaki tablo iki yaklaşımı temel başlıklarda karşılaştırır.

Bu karşılaştırmada immutable backup, klasik yedeğin yerini tamamen almak zorunda değildir. Hızlı geri yükleme için yerel kopya tutulurken, fidye yazılımına karşı son savunma hattı olarak kilitli bir kopya eklenmesi en dengeli modeldir.

Şirket İçi mi, Bulutta Immutable Backup mu?

Şirket içi hardened repository, yerel ağ hızında geri yükleme sağlar ve verinin kurum içinde kalmasını isteyen yapılar için uygundur. Ancak donanımın bakımı, işletim sisteminin sıkılaştırılması, fiziksel güvenlik ve aynı binada bulunmanın getirdiği yangın, su baskını veya deprem riski kurumun sorumluluğundadır.

Bulut tabanlı immutable backup ise kopyayı fiziksel olarak farklı bir veri merkezine taşır ve donanım yönetimini hizmet sağlayıcıya bırakır. İki model arasında seçim yapılırken şu kriterler değerlendirilmelidir:

• Kurtarma süresi hedefi (RTO): Büyük veri hacimlerinde yerel geri yükleme daha hızlıdır.
• Coğrafi ayrım: Bölgesel afet riskine karşı immutable backup kopyasının farklı bir lokasyonda olması gerekir.
• Yönetim yükü: Sıkılaştırılmış Linux depo sunucusunun güncel tutulması uzmanlık ister.
• Veri lokasyonu: Kişisel veri içeren yedeklerin hangi ülkede tutulduğu mevzuat açısından önemlidir.

Birçok kurum için en uygun yapı ikisinin birleşimidir: hızlı geri yükleme için yerel kopya, fidye yazılımına karşı yedek olarak da farklı lokasyonda kilitli bir bulut kopyası. S3 uyumlu altyapı arayan ekipler için S3 uyumlu object storage seçenekleri de bu mimaride hedef depo olarak değerlendirilebilir.

3-2-1-1-0 Kuralı ve Değiştirilemez Yedeğin Yeri

Klasik 3-2-1 kuralı; verinin üç kopyasının, iki farklı ortamda ve bunlardan birinin farklı lokasyonda tutulmasını öngörür. Fidye yazılımı tehdidiyle birlikte bu kural iki madde daha eklenerek genişletilmiştir:

1. 3 kopya: Üretim verisi ve en az iki yedek.
2. 2 farklı ortam: Örneğin disk tabanlı yerel depo ve nesne depolama.
3. 1 farklı lokasyon: Kopyalardan biri başka bir veri merkezinde.
4. 1 değiştirilemez veya çevrim dışı kopya: immutable backup ya da air-gap ile korunan yedek.
5. 0 hata: Geri yükleme testlerinde doğrulama hatası kalmaması.

Kuralın son maddesi en çok ihmal edilenidir. Kilitli bir immutable backup kopyası geri yüklenemiyorsa koruma sağlamaz; düzenli geri dönüş testi yapının ayrılmaz parçasıdır. Konunun daha geniş çerçevesi backup stratejileri yazısında ele alınmıştır.

Immutable Backup Kurulum Süreci: Adım Adım

Değiştirilemez yedek yapısı kurulurken teknik ayarlardan önce kapsam ve saklama politikası netleştirilmelidir. Tipik bir uygulama süreci şu aşamalardan oluşur:

1. Kapsam: Hangi sunucu, veritabanı ve uygulamaların kilitli kopyaya ihtiyaç duyduğu belirlenir.
2. Saklama politikası: Günlük, haftalık ve aylık kopyaların kaç gün kilitli kalacağı tanımlanır.
3. Hedef depo: immutable backup için hardened repository, Object Lock destekli nesne depolama veya hizmet sağlayıcı altyapısı seçilir.
4. Kimlik ayrımı: Yedek deposuna erişim üretim etki alanından ayrılır, çok faktörlü doğrulama zorunlu tutulur.
5. İlk tam yedek ve doğrulama: İlk kopya alınır, bütünlük kontrolü yapılır.
6. Geri dönüş testi: Seçilen sistemler izole ortamda geri yüklenir, süre ve bütünlük kaydedilir.
7. İzleme: Başarısız işler, kapasite ve kilit süreleri düzenli takip edilir.

Saklama süresi belirlenirken depolama kapasitesi de hesaba katılmalıdır. Kilitli veri süre dolmadan silinemediği için immutable backup kapasite planlaması klasik yedeklemeye göre daha dikkatli yapılır.

Sık Yapılan Hatalar ve Doğru Yöntem

Immutable backup teknolojisi doğru kurulmadığında sağladığı güvence beklenenin altında kalır. Sahada en sık karşılaşılan hatalar şunlardır:

• Yedeği aynı etki alanında tutmak: Depo sunucusu üretim Active Directory’sine bağlıysa saldırgan kimlik bilgileriyle erişim yolu bulabilir. Doğru yöntem, ayrı ve yalıtılmış kimlik yönetimidir.
• Governance modunu yeterli saymak: Atlama yetkisine sahip bir hesap ele geçirilirse kilit kaldırılabilir; kritik kopyalar için daha sıkı mod değerlendirilmelidir.
• Kilit süresini çok kısa tutmak: Saldırının geç fark edildiği durumlarda temiz kopyalar kilit kalktığı için kaybolabilir.
• Test etmemek: Geri dönüş testi yapılmayan immutable backup, gerçek bir olayda sürpriz çıkarabilir.
• Depo sunucusunu güncellememek: Sıkılaştırılmış bir Linux sunucusunun güvenlik güncellemeleri de takip edilmelidir.

Bu hataların çoğu tek seferlik kurulumla değil, süregelen yönetimle önlenir. İzleme, raporlama ve periyodik testlerin sorumlusu açıkça tanımlanmalıdır.

Türkiye’de Veri Lokasyonu ve KVKK Açısından Değiştirilemez Yedek

Yedekler, üretim verisindeki kişisel verilerin tamamını içerir. 6698 sayılı Kişisel Verilerin Korunması Kanunu kapsamında veri sorumlularının uygun teknik ve idari tedbirleri alması beklenir; yedeklerin nerede tutulduğu ve yurt dışına aktarılıp aktarılmadığı da bu değerlendirmenin parçasıdır. Türkiye lokasyonlu bir veri merkezinde saklanan kilitli yedekler, yurt dışı aktarım değerlendirmelerini sadeleştirir.

Değişmezlik ile saklama süresi politikası arasındaki ilişki de dikkate alınmalıdır. Kişisel verilerin silinmesi veya imhası gereken durumlarda, kilit süresinin kurumun veri saklama ve imha politikasıyla uyumlu olması gerekir. Bu bilgiler genel niteliktedir ve hukuki danışmanlık yerine geçmez.

MAV Cloud Immutable Backup: Altyapı, Standartlar ve SLA Hedefi

MAV Cloud, yedekleme ve felaket kurtarma hizmetlerini Türkiye lokasyonlu Equinix veri merkezinde, VMware altyapısı ve Veeam tabanlı yedekleme ile sunar. Bilgi güvenliği ve iş sürekliliği süreçleri ISO/IEC 27001, ISO/IEC 27701, ISO 22301, ISO 9001 ve ISO/IEC 20000 sertifikalarıyla belgelenmiştir.

• SLA hedefi: Yedekleme hizmeti için aylık %99,9 erişilebilirlik hedefi.
• İlk müdahale hedefleri: Kritik taleplerde 15 dakika, yüksek öncelikte 1 saat, orta öncelikte 4 saat.
• Destek: 7/24 uzman destek ve 7/24 sistem izleme.
• Kapsam: Bulut veri yedekleme ile birlikte kurgulanan immutable backup katmanı.

Hizmetin teknik kapsamı ve kurulum seçenekleri immutable backup hizmeti sayfasında yer alır.

Sıkça Sorulan Sorular

Immutable backup nedir?

Immutable backup, yazıldıktan sonra belirlenen saklama süresi boyunca silinemeyen, değiştirilemeyen ve şifrelenemeyen yedektir. Koruma depolama katmanında uygulandığı için yönetici yetkisi ele geçirilse bile kilitli kopyalar korunur.

Immutable backup fidye yazılımına karşı tam koruma sağlar mı?

Doğru kurulmuş bir immutable backup, yedeklerin saldırganlar tarafından silinmesini veya şifrelenmesini engelleyerek temiz bir kurtarma noktası sağlar. Saldırının kendisini önlemez; uç nokta güvenliği, erişim yönetimi ve izleme gibi önlemlerle birlikte kullanılmalıdır.

WORM depolama ile immutable yedekleme aynı şey mi?

WORM, bir kez yazılıp çok kez okunan depolama prensibidir. Immutable yedekleme ise bu prensibi yedekleme sürecine uygulayan yaklaşımdır ve Object Lock veya hardened repository gibi yöntemlerle hayata geçirilir.

Kilit süresi ne kadar olmalı?

Tek bir doğru değer yoktur. Süre, saldırının fark edilme süresi, kurtarma ihtiyacı, depolama kapasitesi ve veri saklama politikası birlikte değerlendirilerek belirlenir; çok kısa süreler gecikmeli fark edilen saldırılarda risk oluşturur.

S3 Object Lock governance ve compliance modu arasındaki fark nedir?

Governance modunda özel izne sahip kullanıcılar kilidi değiştirebilir veya nesneyi silebilir. Compliance modunda ise saklama süresi boyunca hiçbir kullanıcı nesneyi silemez ve süreyi kısaltamaz.

Immutable yedekten geri yükleme daha mı yavaştır?

Değişmezlik tek başına geri yükleme hızını belirlemez. Hız; deponun bulunduğu lokasyona, bağlantı kapasitesine ve veri hacmine bağlıdır. Bu yüzden hızlı kurtarma için yerel kopya ile bulutta kilitli kopyanın birlikte kullanılması yaygındır.

3-2-1-1-0 kuralında immutable yedeğin rolü nedir?

Kuraldaki ikinci “1”, en az bir kopyanın değiştirilemez veya çevrim dışı tutulmasını ifade eder. “0” ise geri yükleme testlerinde doğrulama hatası kalmaması gerektiğini anlatır.

Microsoft 365 verileri için de değiştirilemez yedek gerekir mi?

SaaS platformlarındaki veriler de hatalı silme, ele geçirilmiş hesaplar veya fidye yazılımı nedeniyle kaybolabilir. Bu verilerin bağımsız bir yedeğinin alınması ve bu yedeğin immutable backup ile korunması, genel yedekleme stratejisinin parçası olarak değerlendirilmelidir.

Konuyu yeni araştıran kurumlar için ilk adım, mevcut yedeklerin hangi hesaplarla silinebildiğini tespit etmektir. Şirket içi ve bulut modeli arasında kararsız kalan BT ekipleri, en kritik sistemlerden biri için bir immutable backup kopyası oluşturup geri dönüş testini ölçerek somut veriyle karar verebilir. Yapıyı kurmaya hazır işletmeler ise saklama politikası ve kurulum planını MAV Cloud ekibiyle birlikte netleştirebilir.