Immutable Yedeklerinizin Gerçekten Immutable Olduğunu Nasıl Kanıtlarsınız?

Immutable yedeklerin gerçekten immutable olduğu nasıl kanıtlanır

Immutability'yi depolama attribute'ları, kimlik ve policy incelemesi, izole bir koruma testi ve restore sonucunu birlikte değerlendirerek doğrulayın. Silmenin reddedilmesi tek başına yeterli değil; sıradan izin eksikleri aynı hatayı üretebilir. Üretimde metadata'yı salt okunur inceleyin; silme testini yalnızca izole lab ortamındaki atılabilir veride yapın ve kanıtın sınırlarını kaydedin.

Bu runbook, Veeam ortamlarının çoğunun gerçekten kullandığı iki hedefi kapsıyor: Linux hardened repository ve S3 Object Lock. VBR 13'ün desteklediği her immutable hedefin turu değil. Kapanış bölümü nelerin dışarıda kaldığını, birinde (NFS ve SMB WORM) bu kontrollerin neden sessizce boşa düştüğünü anlatıyor.

Aşağıdaki çalıştırılabilir örnekler salt okunur. Yıkıcı kabul testi için hedefi kesin olarak doğrulayan, kuruluma özel ayrı bir runbook ve üretimden izole atılabilir veri gerekir. Bir test prefix'i ya da job adı tek başına izolasyon sağlamaz; Veeam nesneleri birden fazla restore point'in paylaştığı blokları taşıyabilir.

Yapılandırılmış olmak, doğrulanmış olmak değildir

Veeam konsolu immutability'yi repository'nin bir özelliği olarak gösterir. Bu özellik, Veeam'e ne yapmasının söylendiğini ve Veeam'in ne yaptığına inandığını kaydeder. Depolamanın şu anda neyi zorunlu kıldığının canlı okuması değildir. Baştan beri Object Lock açılmamış bir bucket düşünün. Amazon S3'te sonradan kapatamazsınız, "Bir bucket'ta Object Lock'u etkinleştirdikten sonra Object Lock'u devre dışı bırakamaz ya da o bucket için versioning'i askıya alamazsınız", ama bir repository'nin düz bir bucket'a ya da satıcısı daha gevşek davranan bir S3 uyumlu endpoint'e yöneltilmesini engelleyen hiçbir şey yok. Bir de immutability servisi durmuş bir hardened repository var, bir de son oturumu flag uygulanmadan önce başarısız olmuş bir job. Hepsi arayüzdeki yeşil durumla mutlu mesut bir arada yaşar.

Bu son durum belgelidir. Veeam'in hardened repository immutability kılavuzu (v13, build 13.1.1.18), immutability flag'inin bir dosyaya yalnızca backup oturumu tamamlandığında konduğunu, oturum ortamsal bir sorun nedeniyle başarısız olursa flag'in konmadığını belirtiyor. Veeam bir sonraki çalışmada yeniden dener, ama sonraki çalışma yeni bir full backup üretirse başarısız çalışmanın dosyaları hiçbir zaman otomatik olarak immutable yapılmaz. Flag'i sonradan elle koymak için bir cmdlet var: Set-VBRImmutabilityLockExpirationDate. Ona güvenmeden önce sınırlarını bilin. Süreyi kısaltamaz: "Immutability'yi PowerShell komutlarıyla azaltmak mümkün değildir". Yalnızca VMware ve Hyper-V için çalışır ve unstructured data source job'larından, application backup policy'lerinden ya da transaction log'lardan gelen restore point'leri desteklemez. Bu iş yüklerinde, flag uygulanmadan başarısız olmuş bir oturumun belgelenmiş elle çözümü yok. Bu senaryo ortamınızda bir kez bile yaşandıysa, immutable bir repository'nin içinde duran mutable restore point'leriniz var demektir ve hiçbir konsol alanı bunu size söylemez.

Sorun ayrıca backup formatına bağlı, ki bu onu yukarıdaki paragrafın ima ettiğinden daha zor fark edilir kılıyor. Veeam'in notu: per-machine backup formatlarında ve eksik bir restore point'te "immutability flag'i yalnızca başarıyla oluşturulan backup dosyalarına konur"; single-file backup formatında ise "backup dosyasına hiç konmaz". Yani per-machine formatlar karışık bir zincir bırakır (bazı dosyalar kilitli, bazıları değil) ve bunu tek bir konsol alanı temsil etmez.

Başlamadan önce temel kurallar

1. Üretim incelemesini lab testinden ayırın. Üretim metadata'sını yetkili, salt okunur bir kimlikle okuyun. Koruma testi için ayrı bir lab repository veya bucket'ı ve üretimle veri paylaşmayan atılabilir iş yüklerini kullanın. İlgili build, depolama ayarları ve policy koşullarını eşleştirin; farkları kaydedin. Backup oturumunun tamamlanmasını ve hardened repository'de en az bir 20 dakikalık veeamimmureposvc döngüsünü bekleyin. Lab sonucu yalnızca bu kurulumu ve test edilen kimliği kapsar; tüm üretim restore point'lerini onaylamaz.

   "Gözden çıkarılabilir"in ne demek olduğu ve ne demek olmadığı konusunda net olun. Test verisi, kaybı size hiçbir şeye mal olmadığı için gözden çıkarılabilir; istediğiniz anda silinebilir değil. Veeam, VeeamZIP ve export edilmiş backup'lara repository'nin immutability süresini uygular ve onların retention'ını dikkate almaz. Dokümantasyon açık: "GFS flag'i taşıyan backup'lar, VeeamZIP backup'ları ve export edilmiş backup dosyaları için Veeam Backup & Replication object storage repository'sinin immutability süresini uygular. Bu backup dosyalarının retention'ı hesaba katılmaz". Yani birazdan üreteceğiniz artefakt, repository'nin tüm süresi boyunca, object storage'da üstüne Block Generation da binerek silinemez olacak. Test ettiğiniz özelliğin size uygulanmış hâli bu. Boyutu ona göre seçin, VeeamZIP'in her zaman full bir VBK yazdığını hesaba katın ve çok yıllık bir süreyle yapılandırılmış bir repository'de bunu, test verisini o kadar süre ödemeye razı değilseniz çalıştırmayın.

2. Test edilen kimliği tanımlayın. Lab ortamında repository servis hesabının veya Veeam depolama kimliğinin ilgili izinlerini üretim sırlarını kopyalamadan modelleyin. Etkin rolleri, oturum bağlamını ve yetki düzeyini kaydedin. Yerel Windows administrator hesabının saklanan Veeam kimlik bilgilerine erişimi bir tehdit senaryosudur (Veeam KB4349); repository'de root erişimi başka bir senaryodur. Temel izin eksikliğinden kaynaklanan bir reddi immutability kanıtı saymayın.

3. Version silme ile delete marker'ı ayırın. Versiyonlu S3'te version ID olmadan silme, korunan version yerinde kalırken delete marker oluşturabilir (S3 Object Lock dokümantasyonu). Başarılı silmeyi bozuk kilit diye yorumlamadan önce version'ları ve audit kayıtlarını inceleyin. İzole koruma testi tam bir object version'ı tanımlamalı. Yanlışlıkla oluşan marker üretim backup'ını etkiliyorsa kanıtı saklayın ve incelenmiş bir kurtarma prosedürü izleyin; doğaçlama ikinci bir silme yapmayın.

4. Her şeyi tarihlendirin ve kime ait olduğunu yazın. Zaman damgasız ekran görüntüsü kanıt değildir. Her komutu sistem saati transkriptte görünecek şekilde çalıştırın.

Katman 1: Veeam hardened repository (Linux)

Önce v13'ün hardened repository dediği üç şeyden hangisini test ettiğinize karar verin, çünkü bu neyin mümkün olduğunu değiştiriyor:

• Elle kurulmuş bir Linux host. Aşağıdaki runbook yazıldığı gibi çalışır; backup dizininin sahibi olan hesapla koşturun.
• Veeam Infrastructure Appliance'tan kurulmuş bir Veeam Hardened Repository. SSH yok; Host Management TUI, Security Officer onayından sonra süreli bir root shell sağlar. Host incelemesini salt okunur tutun (Kontrol 1.1 ve 1.3). Root ile dosyanın sahibi olmayan bir hesabın sonuçları farklı yetkileri test eder; ikisi de hedef kimliğin kontrollü testinin yerini tutmaz. Kontrol 1.2b için ayrı lab kullanın; S3 testi yalnızca kurulum ayrıca object storage kullanıyorsa geçerlidir.
• Veeam Software Appliance'tan gelen bir Linux backup sunucusu, ki ek bir hazırlık olmadan immutable repository gibi davranır. Bunun aşağıdaki argümana ne yaptığına dikkat edin: backup sunucusu ile repository aynı makine, yani "backup sunucusunun ele geçirilmesi repository'de root vermez" artık geçerli değil.

Aşağıdaki yollar ve bucket adları (/mnt/veeam-repo/, veeam-immutable-repo, Veeam/<test-job>/) örnektir. Kendi yapınızla değiştirin; kontrollerin hiçbiri dizin düzenine bağlı değil.

Veeam'in hardened repository'si, "immutable dosyaları ve chattr ile setxattr komutlarıyla değiştirilen extended attribute'ları desteklemesi gereken" bir dosya sistemi ister (gereksinimler ve kısıtlar, v13). Yani diskte okunacak iki şey var: immutable flag'i ve son kullanma tarihini taşıyan extended attribute.

Kontrol 1.1: Attribute'lar gerçekten konmuş mu

# Read-only: set BACKUP_FILE to an existing absolute backup file path.
: "${BACKUP_FILE:?Set BACKUP_FILE to an absolute file path}"
case "$BACKUP_FILE" in
  /*) ;;
  *) echo "REFUSING: absolute path required" >&2; exit 1 ;;
esac
[ -f "$BACKUP_FILE" ] || { echo "REFUSING: file not found" >&2; exit 1; }
lsattr "$BACKUP_FILE"
getfattr -d -m - "$BACKUP_FILE"

lsattr, immutability penceresi içindeki .vbk ve .vib dosyalarında i (immutable) attribute'unu göstermelidir. .vbm metadata dosyalarında göstermeyecektir: Veeam, "bir backup zincirinin metadata dosyaları (.VBM) her job geçişinde güncellendikleri için immutable olamaz" diyor. Bunu bulgu saymayın; penceresi içindeki bir .vbk dosyasında i yoksa onu bulgu sayın.

Ayrıca Veeam'in her backup dosyasının yanına immutability zaman aralığını taşımak için oluşturduğu .veeam.N.lock eşlik dosyasını da doğrulayın.

Doğru dosyaları örnekleyin, yoksa kendi elinizle yanlış negatif üretirsiniz. Belgelenmiş üç durumda eksik ya da kısa bir i flag'i doğru davranıştır, bulgu değil: inactive bir zincirdeki dosyaların süresi uzatılmaz ("Veeam Backup & Replication inactive zincirler için immutability'yi uzatmaz"); eksik bir restore point, per-machine formatlarda dosyaların bir kısmını flag'li bırakır, single-file formatta ise hiç flag koymaz; ve bir backup copy job, üzerinde GFS açık değilse immutability almaz.

Kontrol 1.2: İzole dosya sistemi testini yorumlayın

Üretim incelemesi yukarıdaki salt okunur attribute kontrolleriyle sınırlı. Repository shell'ine art arda chattr -i / rm yapıştırmayın. Yanlış yazılmış bir yol üretim verisine ulaşabilir; yeterince yetkili bir süreç de dosyayı silmeden önce flag'i kaldırabilir.

Ayrı bir lab ortamında, operatörün incelediği runbook testi tam host, canonical dosya yolu, repository ve etkin kimliğe bağlamalı; eksik veya beklenmeyen değerleri reddetmeli. Flag kaldırmayı ve dosya silmeyi ayrı senaryolar olarak test edin; aralarında flag'i yeniden okuyun. Korunan atılabilir dosyayı, aynı ilgili dizin izinleri ve kimlik altında korumasız atılabilir kontrol dosyasıyla karşılaştırın. Kontrol dosyası da silinemiyorsa korunan dosyadaki ret kesin sonuç vermez. Önceki/sonraki attribute'ları, exit status ve stderr'i saklayın; tek başına Operation not permitted sebebi açıklamaz. Sessiz bir komut sonucundan koruma çıkarımı yapmayın.

Kontrol 1.2b: Backup sunucusu üzerinden erişimi ayrıca test edin

Host kontrolü, ele geçirilmiş bir backup sunucusunun neler yapabileceğini göstermez. Ayrı lab testini tasarlamadan önce aday backup'ın envanterini çıkarın:

# Read-only inventory; set an exact backup name in the connected lab VBR session.
$backupName = Read-Host 'Exact lab backup name'
if ([string]::IsNullOrWhiteSpace($backupName)) { throw 'Backup name required' }
$backup = @(Get-VBRBackup | Where-Object { $_.Name -eq $backupName })
if ($backup.Count -ne 1) { throw 'Expected exactly one backup' }
Get-VBRRestorePoint -Backup $backup[0]

VBR 13 build 13.1.1.18'de Remove-VBRRestorePoint, verilen restore point'lerden VM'leri bulur ve seçilen VM veya replica'ların tüm restore point'lerini siler. Tek restore point seçmek silmeyi o noktayla sınırlamaz. -WhatIf yalnızca bulunduğu çağrıyı önizler; sonraki parametresiz çağrıyı korumaz. Four-eyes authorization açıkken cmdlet çalışmaz; bu ret de depolama korumasını kanıtlamaz.

Yıkıcı test için izole lab iş yükleri, doğrulanmış VM/backup/repository kimlikleri ve etkilenecek veri listesi gerekir. Konsol kendiliğinden kapsam güvencesi sağlamaz. Karşılaştırılabilir korumasız kontrol dahil VBR oturum log'larını ve depolama kanıtlarını kaydedin. İşlem depolamaya ulaşmadan engelleniyorsa o kontrolü ayrı raporlayın; depolama korumasını doğrulanmış saymayın.

Kontrol 1.3: Immutability servisi çalışıyor mu ve saate güveniliyor mu

Immutability attribute'ları yalnızca dosya sistemi tarafından değil, bir servis tarafından sürdürülür. Veeam bu ayrımı belgeliyor: Veeam Data Mover Service (veeamtransport, port 6162, root olmayan bir kullanıcıyla çalışır) immutability süresini Veeam Immutability Service'e (veeamimmureposvc) iletir; bu servis "root yetkileriyle Veeam Data Mover Service'in alt süreci olarak çalışır", dosya immutability attribute'larını her 20 dakikada bir kontrol eder ve immutable attribute'unu koyar ya da kaldırır. İkinci bir systemd unit aramak yerine süreç ağacını doğrulayın.

systemctl status veeamtransport
ps -eo user,pid,ppid,comm | grep -E 'veeamtransport|veeamimmureposvc'
# expect veeamimmureposvc running as root with PPID = the veeamtransport PID

ls -la /etc/veeam/immureposvc/      # a retainLock file here means immutability is BLOCKED
cat  /etc/veeam/immureposvc/config  # may raise the threshold or switch the check off
cat  /etc/veeam/immureposvc/timeLog
timedatectl

timeLog dosyası Veeam'in saat kaydırma tespitidir, her 10 dakikada bir yazılır. İçinde systemTime, moveTime, hwTime ve accelerationTime tutulur; moveTime ya da accelerationTime 86.400 saniyeyi (yani 24 saatlik bir sıçramayı) aşarsa Veeam retention işlemlerini bloklar ve backup job oturumunda uyarır. Bu mekanizma, saati ileri almanın bir immutability penceresini erkenden doldurmanın en bariz yolu olması nedeniyle var; varsaymak yerine çalıştığını doğrulamaya değer.

O eşikle ilgili, bir denetimin varsaymak yerine okuması gereken iki şey var. Birincisi, 86.400 bir varsayılan, sabit değil: KB4482, maxDeltaValueInSec değerinin 60 ile 604.800 saniye arasını kabul ettiği ve disableCheck="1" ile saat kaydırma tespitinin tamamen kapatılabildiği /etc/veeam/immureposvc/config dosyasını belgeliyor. O dosya aksini söylerken 24 saatlik eşiği onaylayan bir rapor, zayıflatılmış ya da kapatılmış bir kontrolü onaylamış olur.

İkincisi, gözlenebilir durum log değil. Eşik aşıldığında Veeam retainLock adında immutable bir dosya oluşturur ve "retainLock dosyasının varlığı, immutable servisinin hem mevcut hem yeni backup dosyalarının immutability durumunu değiştirmesini bloklar". Aranacak şey bu, yanında da job oturumundaki repository time shift detected, immutability flag cannot be set uyarısı. Aynı şey hiçbir saldırı olmadan da olur: repository'yi 24 saatten uzun kapalı tutun, retention işlemleri bloklanır. Kurtarma build'e göre değişiyor: v13 Veeam Hardened Repository ya da Software Appliance'ta Host Management konsol TUI'sindeki Reset time shift protection seçeneği; elle kurulmuş bir host'ta ise root, chattr -i ve retainLock'a karşı rm.

Kontrol 1.4: Erişim yolu, yani sizi asıl koruyan kısım

İnsanların atladığı, asıl önemli olan kontrol bu. Linux immutable flag'i sihirli değil: root ya da CAP_LINUX_IMMUTABLE taşıyan herhangi bir süreç onu chattr -i ile kaldırır. Hardened repository'nin modeli root'un çaresiz olması değil, o makinede kimsenin root olamaması. O yüzden erişim yolunu doğrulayın:

• Single-use credentials. Veeam'in hardened repository dokümantasyonu, kimlik bilgilerinin "Linux sunucusu backup altyapısına eklenirken Veeam Data Mover'ı kurmak için yalnızca bir kez kullanıldığını. Bu kimlik bilgileri backup altyapısında saklanmaz" diye tanımlıyor. Kimlik bilgisinin Veeam credential manager'da görünmediğini doğrulayın.
• SSH yok, domain yok. Veeam Infrastructure Appliance'tan kurulan bir Veeam Hardened Repository'de v13 sertifika tabanlı kimlik doğrulama zorunlu kılıyor, SSH'ın kullanılamayacağını ve appliance'ın domain'e alınamayacağını söylüyor. Elle kurduğunuz bir Rocky ya da Ubuntu host'ta ise siz kaldırmadıkça SSH de root da yerinde kalır. Veeam'in kendi hardening tavsiyesi ikisini de kaldırmanız yönünde: kurulum "SSH üzerinden yapılır ama ... ilk kurulum bittikten sonra SSH'ın kapatılması şiddetle tavsiye edilir" ve root hesabı "DISA STIG Profile'ın gerektirdiği gibi kurulum sırasında kilitlenmelidir". Yani elle kurulmuş bir yapıda denetlenecek maddeler şunlar: sshd kapalı, servis hesabının geçici sudo hakları geri alınmış, root kilitli. Bunun bu runbook için anlamına da dikkat edin: doğru kurulmuş bir repository'de SSH olmadığı için yukarıdaki kontroller fiziksel ya da out-of-band konsoldan çalışır; o konsolun kendisi de denetlediğiniz erişim yolunun bir parçası.
• Out-of-band yönetim. Veeam'in WORM storage best practice dokümanı DRAC, iLO ve IMM'i açıkça sayıyor: out-of-band erişimi olan bir saldırgan "mevcut sistemin üzerine yazabilir." BMC'ye kullanıcı VLAN'ından erişilip erişilmediğini test edin. Cevap veriyorsa immutability'nizin bir yan kapısı var demektir.

Katman 2: S3 Object Lock

Object Lock'ta doğrulanacak birbirinden bağımsız iki şey var: bucket bunun için yapılandırılmış mı, ve Veeam'in yazdığı tekil nesneler gerçekten retention taşıyor mu.

Aşağıdaki her şey Amazon S3'ü varsayıyor. S3 uyumlu bir endpoint'te --endpoint-url ekleyin ve retention modunun, azami sürenin ve bypass izin modelinin farklı olmasını bekleyin. Veeam Compliance modu garantisini yalnızca Amazon S3 için veriyor, Backblaze B2 Object Lock'u 3.000 günle sınırlıyor ve bypass'ı IAM yerine application key capability'lerine bağlıyor, Cloudflare R2 ise ne GetObjectLockConfiguration ne de GetObjectRetention uyguluyor; yani bir Veeam immutable repository'sini hiç taşıyamaz.

Kontrol 2.1: Bucket seviyesi

aws s3api get-object-lock-configuration --bucket veeam-immutable-repo
aws s3api get-bucket-versioning --bucket veeam-immutable-repo

get-object-lock-configuration bucket'ın varsayılan kuralını döner ve AWS bu kuralın "belirtilen bucket'a konan her yeni nesneye varsayılan olarak uygulanacağını" belirtir. Veeam'e özgü iki uyarı: Object Lock yalnızca versioning açık bucket'larda çalışır (get-bucket-versioning ile doğrulayın) ve Veeam'in kendi object storage değerlendirmeleri bucket varsayılan retention'ı koymamanız gerektiğini söylüyor, çünkü "varsayılan retention öngörülemeyen sistem davranışına ve veri kaybına yol açabilir." Yani doğru kurulmuş bir Veeam bucket'ında Object Lock açık ama varsayılan kural yok olmalı. Buradaki boş kural seti doğru cevaptır, eksik değil. Asıl eksik olan bir hata: "S3 Object Lock etkin olmayan bir bucket için Object Lock yapılandırması isteği yaparsanız Amazon S3 bir hata döndürür." Hangisini not edeceğinize karar vermeden önce ikisini birbirinden ayırın.

Kontrol 2.2: Nesne seviyesi, gerçeğin yaşadığı yer

aws s3api list-object-versions --bucket veeam-immutable-repo \
  --prefix "Veeam/<test-job>/" --max-items 5

aws s3api get-object-retention --bucket veeam-immutable-repo \
  --key "Veeam/<test-job>/<object>" --version-id "<VersionId>"

get-object-retention nesnenin Mode ve RetainUntilDate değerlerini döner. Legal hold durumunu döndürmez. Onun için get-object-legal-hold gerekir, ya da retention modunu, retain-until tarihini ve legal hold'u tek çağrıda veren head-object. Yalnızca legal hold ile korunan bir nesne burada hiçbir şey döndürmez ve bunu "koruma yok" diye okumak yanlış bir bulgudur. Amazon S3 için Veeam'in hem v12 hem v13 dokümantasyonu "Veeam Backup & Replication yüklediği her nesne için Compliance object lock modunu kullanır" diyor. Amazon S3 bucket'ındaki Veeam'in yazdığı bir nesnede GOVERNANCE görüyorsanız bir sorun var ve destek kaydı açmaya değer.

Aday listesini list-object-versions ile oluşturun. Retention okumak için geniş örnekleyebilirsiniz: en yeni nesne, retention penceresinin ortasından bir nesne, bir GFS full'ünden bir nesne. Block Generation nedeniyle (aşağıda) meşru olarak farklılık gösterirler.

Örnekler salt okunur kalır. Üretim örneklerini yıkıcı lab prosedürüne taşımayın; yeni bir shell veya test izlenimi veren prefix, nesnenin gözden çıkarılabilir olduğunu kanıtlamaz.

Kontrol 2.3: Pozitif kontrollü, izole koruma testi

Ayrı bir lab bucket'ı ve Veeam'in referans vermediği sentetik nesneler kullanın. Prefix eşleşmesi tek başına yeterli değil: boş PREFIX, shell desenini her key ile eşleşir hâle getirir. Veeam zincirini test etmek için ayrı lab repository ve atılabilir iş yükleri gerekir; sentetik S3 nesneleri depolama davranışını test eder, Veeam zincirinin kurtarılabilirliğini değil.

Ayrı test runbook'u her değişiklikten önce endpoint'i, çağıran hesabı ve rolü, bucket sahibini, lab bucket'ını, tam key'i ve boş olmayan version ID'yi kayıtlı bir izin listesine karşı doğrulamalı. Placeholder, None/null, beklenmeyen hedef ve sorgu hataları reddedilmeli. İşlem öncesinde retention, legal hold ve UTC zamanını kaydedin. Silinecek hedefi üretim listesinin ilk sonucundan çıkarmayın.

Yetkilendirilmiş bir delete-object testinde tam atılabilir version'ı hedefleyin. Aktif Compliance retention, kalıcı silmeyi AccessDenied / HTTP 403 ile reddetmeli. Bu hata tek başına kesin sonuç vermez: eksik s3:DeleteObjectVersion izni, policy deny veya başka bir erişim kontrolü de aynı sonucu üretebilir. Aynı ilgili kimlik, resource-policy koşulları ve istek bağlamında korumasız sentetik bir version ile karşılaştırın. Kontrolde aktif retention veya legal hold olmamalı. Kontrol de başarısızsa immutability testini geçti diye raporlamak yerine izinleri araştırın. Testten sonra version'ın varlığını kontrol edin; tam sonucu, request ID ve zaman damgasını saklayın.

Testten önce, test kaynakları için S3 CloudTrail data-event kaydını yapılandırın. Object data event'leri varsayılan olarak kaydedilmez ve CloudTrail Event history içinde görünmez. DeleteObject olayını bulun; request ID, kimlik, bucket, key ve version ID ile ilişkilendirin. s3:DeleteObjectVersion, CloudTrail olay adı değil IAM action'dır. Yapılandırılan trail veya event data store'u sorgulayın. Eksik kayıt, hiç istek yapılmadığının kanıtı değil kayıt kapsamındaki bir boşluktur. S3 uyumlu sağlayıcılarda sağlayıcının belgelenmiş audit mekanizması gerekir.

Governance bypass testi isteğe bağlıdır ve yalnızca lab ortamında yapılır. İlgili silme izni, s3:BypassGovernanceRetention ve açık bypass istek başlığı gerekir; legal hold bağımsız kalır. Bypass izni olmayan bir principal'ın reddedilmesi, yetkili principal'ın bypass yapıp yapamayacağını test etmez. Atılabilir version'da başarı, beklenen Governance davranışıdır; bozuk Compliance kanıtı değildir. Veeam veri bloklarına bypass silmesi uygulamayın: paylaşılan bir blok silinirse birden fazla restore point bozulabilir. Kontrol 2.4'teki etkin yetkilendirme yollarını da inceleyin.

Kontrol 2.4: Kimlerin bypass yapabileceğini inceleyin

Governance bypass için temel işlem iznine ek olarak s3:BypassGovernanceRetention ve açık bypass başlığı gerekir. Silme, s3:PutObjectRetention ve s3:PutObjectLegalHold yetkilerini ayrı inceleyin; legal hold'u kaldırmak aktif Compliance retention'ı kaldırmaz.

get-account-authorization-details, çağıranın AWS hesabındaki kullanıcı, grup, rol ve policy'leri sayfalar hâlinde dönen bir envanterdir. Başlangıç noktasıdır; etkin bypass principal'larının eksiksiz listesi değildir. Action metni aramak; wildcard, NotAction, effect, resource ve condition gibi policy anlamlarını kaçırır. Bucket/access-point policy'lerini, cross-account principal'ları ve role-assumption yollarını, session policy'lerini, permissions boundary'leri ve geçerli organization veya endpoint kontrollerini de inceleyin.

IAM policy simulator ile belirli action/resource/context birleşimlerini araştırın. Güncel doküman SCP değerlendirmesini, condition ve resource kapsamı dahil destekliyor; bu, ilgili SCP'leri ve simülasyon girdilerini inceleme gereğini ortadan kaldırmaz. Konsol dışında resource policy'yi siz sağlamalısınız. Resource control policy'ler desteklenmez; endpoint policy'leri, role chaining veya birden fazla resource policy canlı yetkilendirmeden farklı sonuç doğurabilir. Girdileri ve modellenmeyen kontrolleri kaydedin; simülasyon sonucu canlı kanıt değildir.

Aday principal'ları, erişim yollarını, sahiplerini ve kapsam boşluklarını raporlayın. Açık deny, etkili olduğu kapsamda bypass'ı sınırlayabilir; fakat kapsamı ve onu kimin değiştirebildiği de önemlidir. Tek policy dışa aktarımının veya deny ifadesinin bütün bypass yollarının kapalı olduğunu kanıtladığını söylemeyin. Policy değişikliğini uygulamadan önce ayrıca doğrulayın ve temsilî davranışı izole lab ortamında kontrol edin.

Governance ile Compliance karşılaştırması

Legal hold bu tablonun dışında kalıyor ve tam da bu yüzden bilmeye değer: iki moddan da bağımsız, son kullanma tarihi yok ve bir bypass'tan sağ çıkıyor. Kural net: "Governance modunu bypass etmek, bir object version'ın legal hold durumunu etkilemez."

AWS compliance durumunu açıkça yazıyor: compliance modunda "korunan bir object version, AWS hesabınızdaki root kullanıcı dahil hiçbir kullanıcı tarafından üzerine yazılamaz veya silinemez" ve "compliance modundaki bir nesneyi retention tarihinden önce silmenin tek yolu ilişkili AWS hesabını silmektir."

Governance modu gerçekten kullanışlıdır; AWS bunu, compliance'a geçmeden önce retention ayarlarını test etmek için öneriyor. Ama Governance çalıştırırken sigortacınıza yedeklerinizin immutable olduğunu söylemek, doğru IAM rolüne sahip bir saldırganın kapatabileceği bir kontrolü tarif etmektir. Hangisini çalıştırdığınızı söyleyin.

Veeam arayüzünün bildirdiği ile depolamanın zorunlu kıldığı

Her şey doğru yapılandırılmış olsa bile sayılar tutmayacak ve bu bir arıza değil.

• Block Generation. Veeam, object store'a yapılan API çağrılarını azaltmak için yapılandırılan immutability süresinin üzerine bir Block Generation süresi ekler. v13'te varsayılan, Amazon S3, IBM Cloud, Google Cloud ve 11:11 Cloud object storage için 30 gün, diğer tüm türler için 10 gündür. v12'de aynı sayfa 30 günü yalnızca Amazon S3 ve IBM Cloud için, 10 günü geri kalan her şey için listeliyor. Yani Amazon S3'te 30 günlük bir minimum immutability süresi RetainUntilDate olarak 30 + 30 = 60 gün verir, ama bunu yalnızca bir block generation'ın başında verir. Bu sayıyı üç şey oynatır ve üçü de örnekleminizde karşınıza çıkar. Veeam generation penceresini ilerledikçe kısaltıyor ("Block Generation süresi her hafta 7 gün azalır"), yani belirli bir nesne 30 ile 60 gün arasında bir yerde durur; garanti edilen tek şey taban, yani bir generation'daki hiçbir bloğun yapılandırılan süreden kısa immutable olmaması. 13.0.1.1071 build'inden itibaren repository varsayılanı minimum süre modu değil job retention modu; bu da gerçek retention'ı max(job retention, minimum süre) + Block Generation yapıyor. 45 günlük job retention'a karşı 30 günlük bir ayar 60 değil 75 verir. Aylık ve yıllık GFS full'leri ise varsayılanları değiştirmedikçe hiç Block Generation almaz, yani bu runbook'un örneklemenizi söylediği GFS nesnesi çıplak süreyi gösterir. Üçü de arıza değil. Depolama haklı; konsoldaki alan bir ayardır, bir tahmin değil.
• Retention alt ve üst sınırları katmana göre değişir. Hardened repository minimum 7, maksimum 9999 gün alır; object storage repository minimum 1, v13'te maksimum 999 gün. v12'de arayüz bunu 90 günle sınırlıyordu. 3 günlük bir politika bir katmanda geçerli, diğerinde imkânsızdır.
• Immutability, job retention'ı ezer. Veeam'in retention senaryoları, job retention süresi immutability süresinden kısaysa backup dosyalarının job retention dolduğunda değil ancak immutability dolduğunda silineceğini belirtir. Object storage'da aynı fikir, yapılandırılan süre artı Block Generation demek olan actual retention olarak karşımıza çıkar. Yalnızca job retention üzerine kurulmuş kapasite tahminleri yanlış çıkacaktır.

Kanıt paketi

Kanıtınızı okuyacak kişinin ortamınıza erişimi olmadığını ve hiçbir iddiayı olduğu gibi kabul etmeyeceğini varsayın. Tarihli ve tekrarlanabilir bir paket bu okumaya dayanır; bir özet dayanmaz. Şunları toplayın:

1. Tarihli bir komut transkripti: yukarıdaki her kontrol, operatörün kimliği ve komutun çalıştığı host ile birlikte. Ekran görüntüsü değil düz metin olsun ki bir sonraki çeyreğin çalışmasıyla diff'lenebilsin.
2. İzole test sonuçları: korunan ve korumasız kontroller, önceki/sonraki attribute'lar, tam hedefler, kimlikler, hata kodları, request ID'ler ve ilişkili audit olayları. Kesin sonuç vermeyen durumları ve üretimden farkları kaydedin; tek başına başarısız silme log'u yeterli değildir.
3. Yapılandırma dışa aktarımları: get-object-lock-configuration ve get-bucket-versioning çıktıları JSON olarak; Veeam repository özellikleri; bucket'a dokunan her principal'ın IAM politikaları.
4. Aday bypass yolları (Kontrol 2.4), sahipleri, incelenen policy kapsamı ve açık kapsam boşluklarıyla birlikte.
5. Konsol ekran görüntüleri: repository immutability ayarları ve restore point özellikleri. Bunlar en zayıf artefakt ve çoğunlukla tek başına sunulan artefakt; pakete koyun ama asla paketin tamamı olmasın.
6. Immutability penceresi içinden bir restore testi sonucu: kilitli verinin aynı zamanda kullanılabilir veri olduğunu gösteren.
7. Testten bu yana yapılandırmanın değişmediğini gösteren bir değişiklik kaydı. Bu olmadan birinci madde, dosyaladığınız an geçerliliğini yitirir.

Bu runbook'un kanıtlamadıkları

• Bir anı kanıtlar, bir dönemi değil. Yukarıdaki her kontrol noktasal bir örnektir. Bucket policy'sini değiştirme ya da veeamimmureposvc'yi durdurma yetkisi olan biri, siz raporu dosyaladıktan bir saat sonra bunu yapabilir. Sürekli güvence, çeyreklik bir test değil yapılandırma değişikliğinin izlenmesini gerektirir.
• Governance modu tasarım gereği bypass edilebilir kalır. Hiçbir test sonucu bunu değiştirmez. Çözüm Compliance modu ya da bypass iznini kimin taşıdığına dair sert bir sınırdır, daha iyi bir test değil.
• Elle kurulmuş bir hardened repository'de root, immutable flag'ini kaldırabilir. Yeterince yetkili bir yerel süreç için chattr -i çalışır. Hardened repository'nin size kazandırdığı şey, o yetkiyi elde etmenin zor olması ve backup sunucusunun ele geçirilmesinin o yetkiyi devretmemesidir. Bu gerçek ve değerli bir özelliktir; "matematiksel olarak silinemez" ile aynı özellik değildir.
• Veeam extended attribute anahtarını yayınlamıyor. Dokümantasyon chattr ve setxattr kullanıldığını ve bir xattr'ın immutability süresini taşıdığını doğruluyor ama anahtar adı vermiyor. Varsaydığınız bir adı grep'lemek yerine attribute'ları getfattr -d -m - ile dökün ve orada ne varsa onu okuyun.
• Compliance modu bedava değil. Silinemez olan aynı zamanda küçültülemezdir: hardened repository'de yanlış konmuş 9999 günlük bir retention, iptal edemeyeceğiniz bir depolama faturasıdır; Amazon S3'te Compliance modunda ise belgelenmiş tek çıkış hesabı kapatmaktır.
• Pek çok hedeften ikisini kapsıyor. VBR 13 immutability'yi ayrıca Azure version-level WORM'a, Veeam Data Cloud Vault'a, archive tier'a, WORM destekli depolama üzerindeki NFS ve SMB repository'lerine, Dell Data Domain'e, HPE StoreOnce'a, configuration backup'lara, Agent backup'larına ve WORM tape'e de yazıyor. Bunlardan biri ayrıca anılmayı hak ediyor, çünkü bu runbook altında sessizce yanılıyor: NFS ve SMB'de Veeam atime ile read-only attribute'unu koyuyor ve bunlara uyulmasını depolamaya bırakıyor, yani lsattr ile getfattr hiçbir şey raporlamıyor ve hiçbir şey kanıtlamıyor.
• SOBR retention, extent türüne bağlıdır. Veeam'in performance-tier immutability algoritması, performance extent olarak eklenen direct-backup object storage repository'leri için move policy'ye bağlı süre azaltımını ve archive-tier senaryosunda operational restore window'a bağlı GFS sınırını içerir. Bunlar Linux hardened repository için genel kurallar değildir. Yapılandırılan süreyi gözlenen retention ile karşılaştırmadan önce extent türünü ve geçerli senaryoyu belirleyin.
• Zincir, dosyalardan ibaret değil. Buradaki her kontrol backup dosyalarıyla ilgili. .vbm metadata tasarım gereği mutable ve aktif bir zincirdeki log backup dosyaları kendi süreleri dolduğunda mutable hâle geliyor. Yani bir zincir yukarıdaki her kontrolü geçip yine de bir application restore'unda çuvallayabilir.
• Geçen bir immutability testi, içerik hakkında hiçbir şey söylemez. Zaten şifrelenmiş veri içeren bir restore point kusursuz biçimde immutable ve kusursuz biçimde işe yaramazdır. Immutability, kendisine verileni korur.

BackupSec bu konuya nasıl yaklaşıyor

Yukarıdaki sorunların ikisi prosedürel değil yapısal. Bypass principal listesi, production kimlik düzleminiz ile backup storage'ınız arasındaki ayrım kadar işe yarar. ZeroVault, immutable Veeam backup'ları için yönetilen S3 uyumlu storage hizmetimiz: governance ve compliance modlu S3 Object Lock ve legal hold. Veeam varsayılan olarak compliance modunda kilit yazar ve bu kilidi süresi dolmadan kimse, bizim ekibimiz dahil, kısaltamaz ya da kaldıramaz. Active Directory domain'inizin dışında, ayrı credential'lar ve ayrı IAM ile kendi hesabında çalışır; böylece ağınızdaki domain admin, son kopyanız üzerinde silme yetkisi anlamına gelmez. ZeroVault izoledir ama air-gapped değildir: internet üzerinden erişilebilir kalır. Gerçek bir air gap gerekiyorsa offline medyayla birlikte kullanın.

Bu runbook'ta olmayan ve adının konması gereken bir kontrol daha var. Veeam'in kendi Security & Compliance Analyzer'ı tam bu alanı kapsayan kurallar taşıyor: immutable repository'lerde Compliance modu, immutable ya da air-gapped medya kullanımı, hardened repository'de SSH'ın kapalı olması. Buradaki hiçbir komutu çalıştırmadan önce onu çalıştırın; ücretsiz, zaten kurulu ve yukarıdaki komutların bir öğleden sonrada teyit ettiğini bir dakikada buluyor.

Diğer sorun ise testin bir andan ibaret olması. ZeroMON on-premise, read-only bir istemci olarak çalışır ve immutability ile hardening durumunu, configuration drift'i ve değişiklik tespitini sürekli izler; böylece "mart ayında immutable'dı" ile "bugün immutable" arasındaki boşluk bir varsayım değil bir uyarı olur.

ZeroMON, repository immutability yapılandırmasını Veeam'den okur ve değişiklikleri izler. Bu, yapılandırma izlemesidir; storage seviyesindeki metadata kontrolünün veya kontrollü koruma ve restore testlerinin yerini tutmaz. Yetkili read-only incelemeyi periyodik çalıştırın, yıkıcı kabul testini ayrı lab runbook'unda tutun ve incelemeler arasındaki yapılandırma değişikliklerini izlemeyle yakalayın.