S3 Object Lock ile WORM Yedek Katmanı Runbook’u

Yedekleme konuşulurken “snapshot aldık” cümlesi hızla rahatlatır. Fakat ransomware ve içeriden yanlışlıkla silme gibi senaryolarda kritik soru şudur: Yedeği kim silebiliyor? Eğer üretimdeki bir kimlik (veya ele geçirilmiş bir pipeline) yedeği de silebiliyorsa, yedek “sigorta” değil “kopya”dır.

S3 uyumlu depolarda Object Lock bu noktada devreye girer ve WORM (Write Once Read Many) davranışı sağlar. Bu runbook, Object Lock’u operasyonel olarak doğru kurmak ve doğrulamak için pratik bir akış sunar.

Ön koşullar ve tasarım kararı

• Object Lock bucket oluşturulurken etkinleştirilmelidir (sonradan açmak her sağlayıcıda mümkün değildir).
• Bucket’ta genellikle versioning gerekir.
• Retention modeli seçilmelidir:
  • Governance mode: yetkili roller bypass edebilir (daha esnek)
  • Compliance mode: bypass edilemez (daha sert, daha riskli)

1) Bucket oluşturma (Object Lock + versioning)

AWS örneği (sağlayıcıya göre komutlar değişebilir):

aws s3api create-bucket --bucket corp-backup-worm --region eu-central-1
aws s3api put-bucket-versioning --bucket corp-backup-worm --versioning-configuration Status=Enabled
aws s3api put-object-lock-configuration --bucket corp-backup-worm --object-lock-configuration "ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=GOVERNANCE,Days=30}}"

Bu noktada hedef: en azından varsayılan retention ile “silinemez kopya” üretmek.

2) IAM / erişim modeli (en kritik bölüm)

WORM’un değeri, erişim modeliyle gelir. Pratik yaklaşım:

• Üretim workload kimlikleri sadece PUT yapabilsin (okuma bile şart değilse kapat).
• Silme yetkisi normal rollerden kaldır.
• “Break-glass” rolü ayrı hesapta/ayrı kimlikte ve denetimli olsun.

Minimum hedef: saldırgan üretim kimliğini ele geçirse bile retention altındaki objeyi silememeli.

3) Yedek yazma ve retention doğrulama

Bir obje yükle ve retention’ı kontrol et:

echo "probe" > probe.txt
aws s3 cp probe.txt s3://corp-backup-worm/probes/probe.txt
aws s3api head-object --bucket corp-backup-worm --key probes/probe.txt

Silme testi (beklenen: engellenme):

aws s3 rm s3://corp-backup-worm/probes/probe.txt

Eğer silme başarılı oluyorsa, Object Lock aktif değildir ya da IAM bypass ediyordur.

4) Retention süresi: operasyonel gerçeklik + regülasyon dengesi

Retention gün sayısını şu iki eksen belirler:

• İyileşme penceresi: “En kötü gün” kaç gün geriden döndürülebilmeli?
• Maliyet ve veri hacmi: retention uzadıkça maliyet büyür.

Ben pratikte şunu severim:

• Operasyonel WORM: 14–30 gün
• Arşiv/uyum: daha uzun ama farklı katmanda (ayrı bucket/hesap)

5) Alarm ve denetim

WORM katmanı “sessiz” kalmamalı:

• Object Lock config değişiklikleri için audit alarmı
• Silme denemeleri (AccessDenied) için alarm
• Retention bypass girişimleri için alarm
• Bucket policy / IAM policy değişiklikleri için change-control

6) Incident runbook: ransomware şüphesinde

1. Üretim kimliklerini ve CI/CD token’larını kilitle
2. WORM bucket’ta silme denemesi var mı kontrol et
3. Geri dönüş hedefi seç: “son temiz snapshot” → “son temiz obje versiyonu”
4. Restore işlemini ayrı izole ortamda doğrula
5. Üretime geri dönüşten önce IAM modelini yeniden doğrula (aynı zayıflıkla geri dönme)

Kapanış

Object Lock, yedekleme stratejisinin tek başına çözümü değildir; ama “yedek de silindi” senaryosunu dramatik biçimde zorlaştırır. WORM’un gerçek değeri; doğru IAM modeli, denetim alarmları ve prova edilmiş bir incident akışıyla birlikte ortaya çıkar.