Değiştirilemez Yedek Seçenekleri: Object Lock, WORM ve Hardened Repo

“Yedeklerimiz immutable” cümlesini toplantılarda sık duyarız. Arkasından gelmesi gereken soru ise neredeyse hiç sorulmaz: kime karşı? Fidye yazılımı operatörü şifrelemeye geçmeden önce yedek konsoluna, depolama yönetimine ya da bulut hesabına ulaşmaya çalışır ve değiştirilemezlik teknolojilerinin her biri bu yolların yalnızca bir kısmını kapatır. Aşağıda S3 Object Lock, WORM ve dizi snapshot’ları, sertleştirilmiş Linux deposu ve teyp seçeneklerini, hangi yetkiye kadar dayandıklarına ve sahada nasıl delindiklerine göre karşılaştırıyoruz.

Değiştirilemezlik neye karşı korur

Immutable yedekleme, yazılmış bir yedek dosyasının veya nesnesinin saklama süresi bitene kadar silinememesi, üzerine yazılamaması ve süresinin kısaltılamaması demektir. Asıl mesele “kim tarafından?” sorusudur. Bir kontrolün gücü, onu kapatabilen en düşük yetkiyle ölçülür. Değerlendirmeye başlamadan önce şu saldırgan profillerini tek tek masaya koyun:

• Domain admin: Active Directory ele geçirilmiş, domain’e üye her sunucuda yönetici yetkisi var.
• Yedek konsolu yöneticisi: Yedek yazılımının arayüzünde iş silme, saklama süresini kısaltma, depo kaldırma yetkisi var.
• Depolama veya işletim sistemi root’u: Depo sunucusunda root, dizide yönetici ya da sunucunun uzaktan yönetim kartına (iLO, iDRAC, IPMI) erişim var.
• Bulut hesabı sahibi: Nesne depolamanın bulunduğu hesapta en yüksek yetki ele geçirilmiş.
• Fiziksel erişim veya içeriden kişi: Diskleri, kartuşları veya cihazı fiziksel olarak alıp götürebilen biri.

Bir şeyi baştan netleştirelim: değiştirilemezlik okumayı engellemez. Saldırganın yedekleri dışarı çıkarıp şantaj malzemesi yapması kurumsal siber güvenlik tarafında ayrı bir risktir; şifreleme ve ağ kontrolleri ister. Burada konuştuğumuz tek şey, geri dönebilme yeteneğinin ayakta kalması.

S3 Object Lock: yönetim ve uyum modu

Amazon S3 Object Lock, nesne sürümlerine WORM (write once, read many) koruması uygular. Kovada sürümleme (versioning) açık olmak zorundadır; kilit nesnenin kendisine değil, belirli bir nesne sürümüne bağlanır. Sürüm kimliği verilmeden gönderilen bir silme isteği yalnızca silme işaretçisi (delete marker) ekler; kilitli sürüm yerinde durur. AWS iki saklama modu tanımlar:

• Yönetim modu (Governance): Çoğu kullanıcı kilitli sürümü silemez. Ancak s3:BypassGovernanceRetention iznine sahip bir kimlik, isteğe atlatma başlığını ekleyerek sürümü silebilir veya saklama ayarını değiştirebilir. Hesabın en yetkili kimliğini ele geçiren saldırgan bu izni kendine verir.
• Uyum modu (Compliance): Saklama süresi boyunca kök hesap dahil kimse korumalı sürümü silemez, süreyi kısaltamaz; süre yalnızca uzatılabilir.

Bunların yanında süreye bağlı olmayan legal hold vardır: kaldırılana kadar silmeyi engeller, ilgili izne sahip kullanıcı tarafından kaldırılabilir. Fidye senaryosunda anlam taşıyan koruma uyum modudur. Yönetim modu, test ve yanlışlıkla silmeye karşı bir emniyet kemeridir; saldırgana karşı değil.

Uyum modunun da kör noktaları var. Saldırgan yeni yazılan nesnelere çok uzun saklama süresi koyup maliyet saldırısı yapabilir. Hesabın kapatılması veya ödeme sorunu yüzünden askıya alınması verinin erişilebilirliğini etkiler. Şirket içindeki S3 uyumlu nesne depolama cihazlarında durum daha da farklıdır: API’nin uyum modu sunması yetmez, cihazın işletim sistemine, disklerine veya yönetim arayüzüne erişen biri API’yi tamamen bypass eder. Bu ürünlerde üreticiye iki soruyu yazılı sorun: uyum modu cihaz yöneticisine karşı nasıl uygulanıyor, saat kaynağı nasıl korunuyor?

Yedek yazılımının Object Lock’u hangi modda ve ne kadar ek süreyle kullandığı ürüne göre değişir. Sahada sık rastlanan durum, kovada kilit ayarlı ama yazılan nesnelerde saklama bilgisinin hiç olmamasıdır. Kova ayarını ve tek tek nesneleri kontrol edin:

aws s3api get-object-lock-configuration --bucket yedek-kovasi
aws s3api get-object-retention --bucket yedek-kovasi --key "ornek/nesne/yolu" --version-id SURUM_ID

WORM depolama ve depolama dizisi snapshot’ları

Kurumsal NAS ve dizilerde iki ayrı yaklaşım var. Birincisi dosya düzeyinde WORM: NetApp ONTAP SnapLock ve Dell PowerScale SmartLock bu sınıftadır, ikisi de “compliance” ve “enterprise” olmak üzere iki mod sunar. Enterprise modunda yetkili bir yönetici bazı koşullarda kilitli veriyi silebilir; compliance modu dizinin kendi yöneticisine karşı da koruma hedefler. İkincisi dizi snapshot’larının silinmeye karşı kilitlenmesidir: Pure Storage SafeMode ve NetApp ONTAP’ın tamperproof snapshot kilidi gibi özellikler, snapshot’ın tek bir yönetici hesabıyla silinmesini engeller. Korumanın nasıl kaldırıldığı (üretici destek süreci, ikinci onay, sürenin dolması) ürüne ve sürüme göre değişir; üreticinin güncel dokümantasyonundan doğrulayın.

Snapshot hızlı geri dönüş verir, yedeğin yerini tutmaz. Snapshot aynı dizide durur; dizi arızalanırsa ya da yönetim düzlemi ele geçirilip dizi yeniden yapılandırılırsa snapshot da gider. Aynı kutu, aynı kader. Değerlendirirken şu soruların cevabını alın: Koruma kaldırılırken kimin onayı gerekiyor? Dizinin saat kaynağı değiştirilirse süre erken biter mi? Fabrika ayarına dönüş veya disk grubunu yeniden oluşturma bu korumayı aşar mı?

Sertleştirilmiş Linux deposu

Bu modelde yedekler, tek amaçlı bir Linux sunucusunda dosya sisteminin değiştirilemezlik özniteliğiyle korunur. Yaygın örnek Veeam Hardened Repository’dir: depo, yedek sunucusunda kalıcı olarak saklanmayan tek kullanımlık kimlik bilgisiyle eklenir, yedek dosyalarına Linux’un immutable özniteliği konur ve bu özniteliği depo sunucusunda root yetkisiyle çalışan yerel bir servis koyup kaldırır. Yedek konsolu ele geçirilse bile konsol, süre dolmadan dosyaları silemez.

Zayıf nokta depo sunucusunun root hesabıdır. Root’a ulaşan biri özniteliği kaldırır veya diski biçimlendirir. Root’a giden yollar bellidir: SSH, yönetim kartının sanal konsolu, fiziksel erişim ve zaman kaynağı. Süre saate göre hesaplandığı için sunucunun saatini ileri alabilen saldırgan süreyi erken bitirmeye çalışır. Sahada en sık gördüğümüz açık ise SSH’ın kurulumdan sonra açık unutulmasıdır. Kurulum ve sıkılaştırma adımları Veeam hardened repository kurulum rehberinde sırasıyla anlatılıyor.

Teyp ve çevrimdışı medya

Kütüphaneden çıkarılıp başka bir yerde saklanan teyp, ağ üzerinden hiçbir yetkiyle erişilemeyen tek seçenektir; gerçek hava boşluğu (air gap) budur. LTO-WORM kartuşlar ayrıca medya düzeyinde üzerine yazmayı engeller. Ama kütüphanede takılı duran kartuş çevrimdışı değildir: yedek sunucusunu ele geçiren saldırgan onu silebilir veya üzerine yazabilir. Teypte korumayı teknoloji değil, kartuşu fiziksel olarak çıkarıp dışarıda saklama disiplini sağlar.

Teypin bedeli geri dönüş süresi ve operasyon yüküdür. Çok sayıda sunucuyu teypten geri yüklemek, diskteki bir kopyaya göre çok daha uzun sürer. Kartuş rotasyonu, envanter ve geri yükleme testi kişi disiplinine dayanır. Disiplin gevşerse teyp kütüphanede kalır. Uzun saklama ekonomisi açısından teyp ile nesne depolamanın karşılaştırmasını sistem tarafındaki teyp ve nesne depolama rehberinde bulabilirsiniz.

Saldırgan yetkisine göre karşılaştırma tablosu

Tablo, her seçeneğin doğru yapılandırıldığı varsayımıyla hangi yetki seviyesine kadar dayandığını gösteriyor. “Kısmen”, korumanın ek bir kontrole (ayrı kimlik, ayrı ağ, ikinci onay) bağlı olduğu anlamına gelir.

Saldırgan yetkisi	S3 uyum modu (bulut)	WORM / korumalı snapshot	Hardened Linux repo	Çevrimdışı teyp
Domain admin	Korur	Korur (dizi domain’den ayrıysa)	Korur (depo domain’e üye değilse)	Korur
Yedek konsolu yöneticisi	Korur	Korur	Korur	Korur
Depo/dizi yöneticisi veya root	Uygulanmaz	Kısmen (moda bağlı)	Korumaz	Korur
Bulut hesabı kök yetkisi	Silme engellenir; hesap kapatma riski	Uygulanmaz	Uygulanmaz	Uygulanmaz
Saat kaynağı manipülasyonu	Sağlayıcı saati	Kısmen	Risk var	Uygulanmaz
Fiziksel erişim	Sağlayıcı sorumluluğu	Korumaz	Korumaz	Saklama yerine bağlı

Tablonun söylediği şu: tek bir değiştirilemez kopya, tek bir yetki katmanına bağımlıdır. Çoğu kurum için makul tasarım iki kopyalıdır. Hızlı geri dönüş için şirket içinde bir değiştirilemez kopya (hardened repo veya korumalı dizi), farklı bir yönetim düzleminde de ikinci kopya (uyum modunda nesne depolama veya dışarıda saklanan teyp). Bu kopyaların kimlik bilgilerinin birbirinden ve domain’den ayrılması, seçilen teknoloji kadar belirleyicidir; konuyu yedek altyapısında kimlik izolasyonu yazısında ayrıca ele alıyoruz.

Seçim için kısa karar ağacı

1. Kurtarma süresi hedefiniz saatler mertebesindeyse ilk kopya şirket içinde ve diskte olmalı: hardened repo veya korumalı snapshot.
2. Depo sunucusunu ve dizileri domain’den ve ortak yönetim ağından ayıramıyorsanız, ikinci kopyayı farklı bir yönetim düzlemine taşıyın: ayrı hesapta uyum modlu nesne depolama veya dışarıda saklanan teyp.
3. Bulut hesabı BT ekibinin günlük kimlikleriyle yönetiliyorsa önce hesabı ayırın; aksi halde bulut kopyası kök hesap riskini paylaşır.
4. Mevzuat veya sözleşme uzun saklama istiyorsa, uzun dönem (GFS) kopyalar için teyp veya düşük maliyetli nesne depolama sınıfını değerlendirin.

Saklama süresi ve kapasite etkisi

Değiştirilemezlik süresi, saklama politikasının üstüne binen bir kapasite yüküdür. Süre dolmadan veri silinemediği için iki etki doğar. Birincisi, artımlı yedekler bağlı oldukları tam yedeğe muhtaçtır; yazılımlar korunan zincirin tamamını süre boyunca tutar, bazıları blok yeniden kullanımını yönetmek için süreyi kendiliğinden birkaç gün uzatır. İkincisi, saklama politikasını kısaltsanız bile alan hemen boşalmaz. Disk dolunca bu ikinci etki sürpriz olarak karşınıza çıkar.

Örnek hesap: 10 TB kaynak veri, günlük artımlı yedeklerin ortalama 0,5 TB yer kapladığı ve haftalık sentetik tam yedeğin fast clone ile alındığı bir ortamda 14 günlük değiştirilemezlik düşünün. Fast clone desteklenmiyorsa her haftalık tam yedek yaklaşık 10 TB ekler ve iki haftalık pencerede en az iki tam yedek ile 14 artımlı yedek (yaklaşık 27 TB) kilitli durur. Fast clone (XFS reflink veya ReFS block clone) ile sentetik tam yedekler değişmeyen blokları paylaşır ve fiziksel tüketim belirgin şekilde düşer. Dosya sistemi seçimi, kapasite kararının parçasıdır.

Nesne depolamada ek maliyet kalemleri çıkar: sürümleme yüzünden saklanan eski sürümler, bazı depolama sınıflarındaki asgari saklama süresi ve erken silme ücretleri, API istek sayısı. Uyum modunda yanlışlıkla çok uzun verilmiş bir politika, süre dolana kadar geri alınamaz. Geri dönüşü yoktur. Politikayı canlıya almadan önce kısa süreli bir test kovasında deneyin.

Uygulama öncesi kontrol listesi

• Her değiştirilemez kopya için “bu korumayı kim, hangi kimlikle kaldırabilir?” sorusunun yazılı cevabı var.
• Depo, dizi ve bulut hesabının kimlik bilgileri domain’den ve yedek konsolundan bağımsız.
• Zaman kaynağı (NTP) korunuyor, saat sapması izleniyor.
• Değiştirilemezlik süresi, saldırının fark edilmesine kadar geçebilecek süre hesaba katılarak belirlendi; birkaç günlük süre çoğu senaryoda yetmez.
• Koruma fiilen denendi: konsoldan ve işletim sisteminden yapılan silme girişimi reddedildi.
• En az bir kopya farklı bir yönetim düzleminde veya çevrimdışı.

Değiştirilemez kopya tek başına kurtarma planı değildir; temiz kurtarma noktasının seçimi ve geri yükleme sırası da önceden hazırlanmalıdır. Genel çerçeve için fidye yazılımına karşı kurtarma hazırlığı yazısına bakın. Mevcut yedek mimarinizi bu tablo üzerinden birlikte değerlendirmek, yedekleme güvenliği ve fidye yazılımına hazırlık çalışmamızın ilk adımıdır. Object Lock davranışının ayrıntıları için birincil kaynak AWS S3 Object Lock dokümantasyonu.

Sık sorulan sorular

S3 Object Lock’ta yönetim modu fidye yazılımına karşı yeterli mi?

Hayır. Yönetim modunda atlatma iznine sahip bir kimlik kilitli sürümleri silebilir; hesabın en yetkili kimliğini ele geçiren saldırgan da bu izni kendine verebilir. Fidye senaryosunda uyum modunu kullanın, yönetim modunu test ve yanlışlıkla silmeye karşı bırakın.

Hardened repository ile S3 uyum modu arasında hangisini seçmeliyim?

İkisi farklı riskleri kapatır. Hardened repository şirket içinde hızlı geri dönüş verir ama depo sunucusunun root hesabına ve yönetim kartına bağımlıdır. Uyum modundaki nesne depolama ayrı bir yönetim düzleminde durur, geri yükleme süresi ise bağlantınıza bağlıdır. Mümkünse ikisini birlikte, farklı kimliklerle kullanın.

Değiştirilemezlik süresi kaç gün olmalı?

Herkese uyan bir değer yok. Süre, saldırının fark edilmesine kadar geçebilecek zamanı ve temiz kurtarma noktasını geriye doğru arama ihtiyacını kapsamalı. Birkaç günlük süreler çoğu senaryoda kısa kalır; kapasite etkisini örnek hesapla doğrulayıp karar verin.

Kütüphanede duran teyp kartuşları çevrimdışı sayılır mı?

Hayır. Kütüphanede takılı kartuşlara yedek sunucusu üzerinden erişilir; saldırgan bunları silebilir veya üzerine yazabilir. Çevrimdışı koruma için kartuşun kütüphaneden çıkarılıp ayrı bir yerde saklanması gerekir.