Nesne depolama ile değiştirilemez yedek: S3 Object Lock, compliance modu ve fidye yazılımına karşı saklama süresi

Fidye yazılımı bir sunucuya girdiğinde ilk işlerinden biri yedekleri bulmaktır. Yedek aynı ağdaki bir NAS'taysa ya da yedek sunucusunun elindeki anahtarla silinebiliyorsa, saldırgan onu da şifreler ya da siler. Nesne depolama üzerinde S3 Object Lock kullanarak yedeğinizi belirli bir süre boyunca kimsenin silemeyeceği ya da değiştiremeyeceği hale getirebilirsiniz. Bu rehber, yedekten sorumlu sistem yöneticileri ve KOBİ BT sorumluları için hazırlandı. Object Lock'un nasıl çalıştığını, governance ile compliance modunun farkını, saklama süresinin nasıl seçileceğini ve Veeam, restic, rclone ile nasıl bağlanacağını anlatıyor.

Fidye yazılımı yedekleri neden hedef alır

Saldırganın amacı fidyeyi ödetmektir. Temiz bir yedekten geri dönebiliyorsanız fidye ödemezsiniz, bu yüzden saldırgan şifreleme başlamadan önce yedekleri ortadan kaldırmaya çalışır. Tipik yollar şunlardır:

• Ağ paylaşımı olarak bağlı yedek klasörünü doğrudan şifrelemek.
• Yedek yazılımının konsoluna yönetici yetkisiyle girip yedek zincirlerini silmek.
• Yedek sunucusundaki S3 erişim anahtarını bulup bucket içeriğini silmek ya da üzerine yazmak.
• Windows gölge kopyalarını ve yerel snapshot'ları kaldırmak.

Bu yolların ortak noktası şudur: yedeği yazabilen kimlik onu silebiliyorsa, o kimliği ele geçiren de silebilir. Değiştirilemez yedek bu bağı koparır. Yedek yazılımı yeni veri yazabilir ama mevcut sürümleri saklama süresi bitmeden silemez.

Nesne depolamada Object Lock nedir

Object Lock, S3 API'sinin WORM (write once, read many: bir kez yaz, çok kez oku) özelliğidir. Nesne depolamada veri bucket içinde anahtar ve meta veriyle tutulan nesneler olarak saklanır; Object Lock bu nesnelerin sürümlerine kilit koyar. Anlamak için üç noktayı bilmek yeterli:

Sürümleme zorunludur. Object Lock açık bir bucket'ta sürümleme (versioning) her zaman açıktır ve askıya alınamaz. Aynı anahtara yeni dosya yazıldığında eskisi silinmez, yeni bir sürüm oluşur.

Kilit sürüme uygulanır, anahtara değil. Saklama süresi her nesne sürümü için ayrı tutulur. Sürüm kimliği belirtmeden yapılan bir silme isteği yalnız bir "delete marker" (silme işareti) ekler. Dosya listede görünmez olur ama kilitli sürüm yerinde durur ve geri getirilebilir. Kilitli sürümü sürüm kimliğiyle silme isteği ise süre bitene kadar reddedilir.

Kilit iki türlüdür. Retention (saklama süresi) bir bitiş tarihi taşır. Legal hold ise süresizdir ve yetkili biri kaldırana kadar sürer; hukuki bir inceleme sırasında belirli yedekleri dondurmak için kullanılır.

Önemli bir kısıt: birçok S3 uyumlu sistemde (örneğin MinIO) Object Lock yalnız bucket oluşturulurken etkinleştirilebilir ve bir kez açıldıktan sonra kapatılamaz. AWS S3 mevcut bucket'larda da açmaya izin verir ama siz kendi sağlayıcınızın belgesine bakın. Pratikte kural basit: yedek bucket'ını baştan Object Lock ile oluşturun. Davranışın ayrıntıları için AWS S3 Object Lock belgesi temel başvuru kaynağıdır; S3 uyumlu sağlayıcılar çoğunlukla bu API'yi izler.

Governance mı compliance mı: hangi modda kim silebilir

Saklama süresi iki modda uygulanır. Fark, süre dolmadan kilidi kimin aşabileceğidir.

Governance modunda silme için kullanıcının s3:BypassGovernanceRetention iznine sahip olması ve istekte atlatma başlığını göndermesi gerekir. Bu izin yedek sunucusundaki anahtarda yoksa governance da fidye yazılımına karşı iyi bir koruma sağlar. Zayıf nokta şudur: saldırgan bu izne sahip bir yönetici anahtarını ele geçirirse kilidi aşabilir.

Compliance modunda bu yol yoktur. Sağlayıcının panelinden bile süre dolmadan silemezsiniz. Bedeli de buradadır: 365 günlük compliance kilidiyle yanlışlıkla 5 TB veri yüklerseniz o veri bir yıl boyunca faturanızda kalır.

Karar ölçütü: İlk kurulumu ve geri dönüş testlerini governance ile yapın. Süreler, boyutlar ve yedek zinciri birkaç hafta sorunsuz çalıştıktan sonra üretim yedekleri için compliance'a geçin. Yönetici anahtarlarını çok sıkı koruyamıyorsanız compliance daha güvenli tercihtir.

Saklama süresi nasıl seçilir

Saklama süresini belirleyen soru şudur: "Saldırı fark edildiğinde, temiz bir yedeğe ulaşmak için ne kadar geriye gitmem gerekebilir?" Saldırganlar çoğu zaman sisteme girdikten hemen sonra şifrelemeye başlamaz; bir süre keşif yapar, yetki yükseltir, yedekleri araştırır. Kilit süreniz bu bekleme süresinden kısaysa, şifreleme günü geldiğinde en eski temiz yedeğin kilidi çoktan düşmüş olabilir.

Süreyi seçerken şu dört girdiyi bir araya getirin:

1. Tespit süresi: Bir sorunu fark etmeniz ne kadar sürer? İzleme ve log incelemeniz yoksa bu süre haftalarla ölçülür.
2. Geri dönüş noktası ihtiyacı: Muhasebe, ERP gibi sistemlerde ay sonu kapanışından önceki duruma dönmek gerekebilir.
3. Yasal ve sözleşmesel saklama yükümlülükleri: Bazı belgeleri belirli süre saklamak zorundaysanız bu süre alt sınır olur. Kişisel veride ise gereğinden uzun saklamak da sorundur.
4. Depolama maliyeti: Kilitli her sürüm süre boyunca yer kaplar. Toplam alan kabaca "tam yedek boyutu + günlük değişim × saklama günü" olarak hesaplanır.

Makul bir başlangıç, değiştirilemez katmanda 30 gün civarı kilit ve bunun üzerine yedek yazılımının kendi saklama politikasıdır. Kesin bir doğru sayı yoktur; kendi değişim oranınızı bir hafta ölçüp hesabı yapın. Maliyet tarafını ayrıca incelemek isterseniz yedek boyutu ve saklama süresinin faturaya etkisini ayrı ayrı hesaplayın, kilit süresi doğrudan bu hesabın çarpanıdır.

Adım adım: Object Lock'lu bucket oluşturma

Aşağıdaki betik AWS CLI v2 ile S3 uyumlu herhangi bir uç noktada kilitli bucket oluşturur, sürümlemeyi doğrular ve varsayılan saklama kuralını tanımlar. Ubuntu 24.04 ve Debian 12 üzerinde AWS CLI v2 için hazırlandı. Tekrar çalıştırılabilir: bucket varsa oluşturma adımını atlar.

Değiştirmeniz gereken değerler: ORNEK_BUCKET, ORNEK_PROFIL ve https://s3.example.com uç noktası. Geri alma: governance modunda varsayılan kural put-object-lock-configuration ile değiştirilebilir, bucket ise içi boşaltıldıktan sonra silinebilir. Object Lock'un kendisi kapatılamaz. Compliance ile yazılmış sürümler süre dolana kadar silinemez, bu yüzden betik varsayılan olarak GOVERNANCE kullanır.

#!/usr/bin/env bash
# Object Lock'lu yedek bucket'i olusturur ve varsayilan saklama kuralini ayarlar.
# AWS CLI v2 icin hazirlandi. Tekrar calistirilabilir.
set -euo pipefail

BUCKET="ORNEK_BUCKET"                 # bucket adi
PROFIL="ORNEK_PROFIL"                 # ~/.aws/credentials icindeki yonetici profili
ENDPOINT="https://s3.example.com"     # saglayicinizin S3 uc noktasi
MOD="GOVERNANCE"                      # ilk kurulumda GOVERNANCE, sonra COMPLIANCE
GUN=30                                # varsayilan saklama suresi (gun)

aws_s3() { aws --profile "$PROFIL" --endpoint-url "$ENDPOINT" s3api "$@"; }

# 1) Bucket yoksa Object Lock acik olarak olustur
if aws_s3 head-bucket --bucket "$BUCKET" 2>/dev/null; then
  echo "Bucket zaten var: $BUCKET"
else
  aws_s3 create-bucket --bucket "$BUCKET" --object-lock-enabled-for-bucket
  echo "Bucket olusturuldu: $BUCKET"
fi

# 2) Surumleme durumunu kontrol et (Object Lock ile otomatik Enabled olmali)
aws_s3 get-bucket-versioning --bucket "$BUCKET"

# 3) Varsayilan saklama kuralini yaz (ayni deger tekrar yazilirsa sorun olmaz)
aws_s3 put-object-lock-configuration --bucket "$BUCKET" \
  --object-lock-configuration "{\"ObjectLockEnabled\":\"Enabled\",\"Rule\":{\"DefaultRetention\":{\"Mode\":\"$MOD\",\"Days\":$GUN}}}"

# 4) Sonucu goster
aws_s3 get-object-lock-configuration --bucket "$BUCKET"

Bazı sağlayıcılar create-bucket sırasında bölge bilgisi ister. Hata alırsanız komuta --create-bucket-configuration LocationConstraint=BOLGE_ADI ekleyin. MinIO kullanıyorsanız aynı işi mc mb --with-lock ve mc retention set --default komutlarıyla da yapabilirsiniz.

Kilidin çalıştığını doğrulama

Kurulumdan sonra kilidi mutlaka deneyin. Aşağıdaki komutlar bir test dosyası yükler, saklama bilgisini okur ve sürüm kimliğiyle silmeyi dener.

# Test dosyasi yukle ve surum kimligini al
echo "kilit testi" > /tmp/kilit-testi.txt
aws --profile ORNEK_PROFIL --endpoint-url https://s3.example.com \
  s3api put-object --bucket ORNEK_BUCKET --key test/kilit-testi.txt --body /tmp/kilit-testi.txt

aws --profile ORNEK_PROFIL --endpoint-url https://s3.example.com \
  s3api list-object-versions --bucket ORNEK_BUCKET --prefix test/ \
  --query 'Versions[0].VersionId' --output text

# Saklama bilgisini oku (SURUM_KIMLIGI yerine yukaridaki ciktiyi yazin)
aws --profile ORNEK_PROFIL --endpoint-url https://s3.example.com \
  s3api get-object-retention --bucket ORNEK_BUCKET --key test/kilit-testi.txt --version-id SURUM_KIMLIGI

# Surumu silmeyi dene: AccessDenied ile reddedilmeli
aws --profile ORNEK_PROFIL --endpoint-url https://s3.example.com \
  s3api delete-object --bucket ORNEK_BUCKET --key test/kilit-testi.txt --version-id SURUM_KIMLIGI

Beklenen sonuç: get-object-retention çıktısında Mode ve RetainUntilDate alanları görünür, silme denemesi AccessDenied hatası döner. Silme başarılı olursa kilit çalışmıyor demektir, yedek göndermeye başlamadan önce yapılandırmayı düzeltin.

Eski sürümler için yaşam döngüsü kuralı

Kilidi süresi dolan eski sürümler kendiliğinden silinmez. Yaşam döngüsü kuralı tanımlamazsanız alan sürekli büyür. Aşağıdaki kural, güncel olmayan sürümleri 45 gün sonra ve artık sürümü kalmamış silme işaretlerini temizler. Bu süreyi kilit süresinden uzun tutun; kilitli sürümler zaten kural tarafından silinmez. Geri almak için delete-bucket-lifecycle kullanılır.

aws --profile ORNEK_PROFIL --endpoint-url https://s3.example.com \
  s3api put-bucket-lifecycle-configuration --bucket ORNEK_BUCKET \
  --lifecycle-configuration '{"Rules":[{"ID":"eski-surumleri-temizle","Status":"Enabled","Filter":{},"NoncurrentVersionExpiration":{"NoncurrentDays":45},"Expiration":{"ExpiredObjectDeleteMarker":true}}]}'

Veeam, restic ve rclone ile kilitli bucket'a yedek gönderme

Veeam

Veeam Backup & Replication, S3 uyumlu depoyu nesne deposu (object storage repository) olarak ekler ve "Make recent backups immutable" seçeneğiyle her nesnenin saklama süresini kendisi yönetir. Bunun için bucket'ta Object Lock ve sürümleme açık olmalıdır. Veeam belgeleri bucket'a varsayılan saklama kuralı tanımlanmamasını önerir, çünkü süreyi nesne bazında Veeam ayarlar. Bu yüzden Veeam için ayrı bir bucket açın ve yukarıdaki betikte 3. adımı atlayın. Veeam, blok üretim mantığı nedeniyle gerçek kilit süresini sizin girdiğiniz değerden biraz uzun tutabilir; alan hesabını buna göre yapın ve kullandığınız sürümün resmi yardım belgesindeki immutability bölümünü kontrol edin.

restic

restic nesnelere kendisi kilit koymaz; varsayılan saklama kuralı bu işi üstlenir. restic silme işlemlerini sürüm kimliği olmadan yaptığı için forget --prune ve kilit dosyası temizliği hata vermeden çalışır, ama gerçekte yalnız silme işareti oluşur. Eski veri, kilit süresi ve yaşam döngüsü kuralı dolana kadar yer kaplamaya devam eder. Saldırgan restic deposunu silse bile kilitli sürümler yerinde kalır. Kurulumun tamamı için restic ile S3 yedekleme yazısına, Object Lock'lu depoya özel ayarlar için S3 yedekleme rehberine bakabilirsiniz.

rclone ile eski bir ana dönme

Saldırı sonrası bucket'ın belirli bir tarihteki halini okumak için rclone'un --s3-version-at seçeneği kullanılabilir. Aşağıdaki komut, bucket'ı belirtilen andaki haliyle yerel bir dizine kopyalar; kaynağa yazmaz. kilitli adı, rclone yapılandırmanızdaki S3 remote adıdır.

# Bucket'in 1 Kasim 2026 00:00 itibariyle halini yerel dizine kopyalar
rclone copy kilitli:ORNEK_BUCKET /srv/geri-donus \
  --s3-version-at "2026-11-01 00:00:00" --progress

Erişim anahtarlarını ayırma

Object Lock tek başına yetmez; anahtar düzeni doğru değilse saldırgan kuralı değiştirebilir. En az üç kimlik kullanın:

• Yedek yazma anahtarı: Yedek sunucusunda durur. Yalnız ilgili bucket'ta okuma, yazma ve listeleme izni olsun. s3:BypassGovernanceRetention, s3:PutObjectLockConfiguration, s3:PutBucketPolicy ve s3:DeleteBucket izinleri olmasın.
• Geri yükleme anahtarı: Yalnız okuma izni olan, ayrı saklanan anahtar.
• Yönetici kimliği: Kilit kuralını ve yaşam döngüsünü yöneten kimlik. Yedek sunucusunda ya da etki alanına bağlı bir makinede durmamalı, çok faktörlü doğrulamayla korunmalı.

3-2-1-1-0 kuralı ve geri dönüş testi

3-2-1-1-0 kuralı: verinin 3 kopyası, 2 farklı ortam, 1 kopya farklı konumda, 1 kopya değiştirilemez ya da ağdan ayrık, 0 hatalı geri dönüş testi. Object Lock'lu nesne depolama, "farklı konum" ve "değiştirilemez" maddelerini aynı anda karşılar.

Son madde en çok atlanan maddedir. Ayda en az bir kez şu kontrolü yapın: rastgele bir yedeği kilitli bucket'tan ayrı bir test makinesine geri yükleyin, uygulamanın açıldığını ve verinin güncel olduğunu doğrulayın, süreyi not edin. Ölçülen geri dönüş süresi kabul edilebilir değilse yedek tasarımını değiştirmeniz gerekir.

KVKK açısından yedeğin Türkiye'de tutulması

Yedek, kaynak sistemdeki kişisel verinin tam bir kopyasıdır. Ana sunucunuz Türkiye'de olsa bile yedeği yurt dışındaki bir nesne depolama hizmetine gönderiyorsanız, KVKK 9. madde kapsamında yurt dışına aktarım yapıyor olabilirsiniz. Bu durumda aktarım mekanizmasını belgelemeniz gerekir. Konunun ayrıntıları Türkiye lokasyon veri depolama ve KVKK yazısında. Değiştirilemez yedeğin bir yan etkisini de unutmayın: kilit süresi boyunca bir kişinin verisini yedekten silemezsiniz. Saklama süresini ve bu durumu kişisel veri saklama ve imha politikanıza yazın.

Sık yapılan hatalar

• Kilidi sonradan açmaya çalışmak: Mevcut bucket'ta Object Lock açılamayan sistemlerde yeni bucket oluşturup veriyi taşımak gerekir. Baştan doğru kurun.
• Doğrudan compliance ile başlamak: Yanlış süre ya da yanlış veri, süre boyunca silinemez. Önce governance ile deneyin.
• Süre uyumsuzluğu: Yedek yazılımı 14 gün saklarken kilit 90 günse, yazılımın sildiğini düşündüğü veri alanı doldurmaya devam eder. Tersi durumda ise kilit, korunması gereken zinciri kapsamaz.
• Veeam bucket'ına varsayılan kural koymak: Veeam süreyi kendisi yönetir; çakışan varsayılan kural beklenmedik davranışa yol açabilir.
• Tek erişim anahtarı: Yedek sunucusundaki anahtar yönetici yetkisi taşıyorsa, saldırgan governance kilidini aşabilir ya da kuralları değiştirebilir.
• Yaşam döngüsü kuralı unutmak: Süresi dolan sürümler kendiliğinden silinmez, fatura büyür.
• Hiç test etmemek: Silme denemesi yapılmamış bir kilit, varsayımdır.

Sık sorulan sorular

Object Lock yedeği şifrelemeye karşı da korur mu?

Evet. Saldırgan aynı anahtara şifreli bir dosya yazarsa yeni bir sürüm oluşur, eski kilitli sürüm yerinde kalır. Önceki sürüme ya da bucket'ın belirli bir tarihteki haline dönerek temiz veriyi geri alırsınız.

Governance modunu sonradan compliance'a çevirebilir miyim?

Evet, governance kilidi compliance'a yükseltilebilir ve varsayılan kural da değiştirilebilir. Tersi mümkün değildir: compliance ile kilitlenmiş bir sürüm süresi dolana kadar o modda kalır.

Kilit süresi dolduğunda yedek otomatik silinir mi?

Hayır. Süre dolunca sürüm yalnız silinebilir hale gelir. Silme işini yedek yazılımı ya da bucket'a tanımladığınız yaşam döngüsü kuralı yapar.

Kilitli bucket'ta saklama ücreti neden beklenenden fazla?

Silindiğini sandığınız eski sürümler kilit süresi boyunca alan kaplamaya devam eder. Günlük değişim oranınızı kilit süresiyle çarparak ek alanı tahmin edin ve yaşam döngüsü kuralını kontrol edin.

Yerinde bir MinIO sunucusu yeterli olur mu?

Object Lock'u destekler ama aynı ağda ve aynı yöneticilerin elindeyse, sunucunun kendisi ele geçirildiğinde koruma zayıflar. Değiştirilemez kopyanın ayrı bir konumda ve ayrı yetkilerle tutulması daha güvenlidir.

Hazır kurulum seçeneği

Bu işi hazır yapmak isterseniz, verisi ve kopyaları İstanbul'da tutulan, S3 uyumlu Object Storage hizmetinde Object Lock'lu bir yedek bucket'ı açıp yukarıdaki adımları aynı şekilde uygulayabilirsiniz.

Sonuç

Değiştirilemez yedek, fidye yazılımına karşı son savunma hattıdır. Nesne depolama üzerinde Object Lock'u bucket oluştururken açın, ilk haftaları governance ile test edin, saklama süresini tespit süreniz ve maliyetinize göre seçin, yedek anahtarından kilit aşma yetkisini kaldırın. Ardından silme denemesi ve düzenli geri dönüş testiyle kilidin gerçekten işe yaradığını doğrulayın.