Değiştirilemeyen Yedek Neden Önemli?
Fidye yazılımı saldırısında yalnızca çalışan sistemler değil, yedekler de hedef olabilir. Bu nedenle başka bir yere kopya almakla yetinmeyip yedeklerin silinmeye ve değiştirilmeye karşı korunmasını, ardından geri yüklenebilmesini planlamak gerekir.
Bu rehber, Amazon S3 genel amaçlı bucket’larında Object Lock, Versioning ve sabit tarihli retention kullanarak yedek sürümlerini korumayı anlatır. Governance ile compliance farkını, MFA Delete’in sınırlarını, lifecycle ve replikasyon kararlarını, ardından dosya ve veritabanı geri dönüş testlerini ele alır. Bu kontroller saldırıya karşı dayanıklılığı artırır; yedeğin temiz, erişilebilir ve çalışır olduğunu tek başına kanıtlamaz.
Değiştirilemeyen Yedek Hangi Riski Azaltır?
Fidye yazılımı canlı dosyaları bozarken ele geçirilen yedekleme yetkileri eski kopyaları da hedef alabilir. Değiştirilemezlik, koruma kapsamındaki nesne sürümlerinin kalıcı silinmesini engelleyen bir katmandır. Etkisi seçilen retention moduna, legal hold durumuna ve yetkilere bağlıdır. Son yüklenen sürümün bozuk olması veya bir delete marker ile görünmez hale gelmesi, daha eski korunan sürümün de silindiği anlamına gelmez.
Kilitli kasa benzetmesi özellikle compliance retention için yararlıdır: korunan sürüm, saklama süresi devam ederken root dahil kullanıcılar tarafından silinemez. Governance modunda ise özel yetki ve açık bypass isteğiyle istisna uygulanabilir. Bu nedenle günlük otomasyon anahtarlarıyla acil durum yönetim yetkilerini aynı yerde tutmamak gerekir.
Retention süresini yanlış seçmek maliyeti artırabilir veya gerekli kurtarma geçmişini kısa bırakabilir. Süreyi veri sahibiyle birlikte belirleyin; test verisiyle kilit ve geri dönüş davranışını deneyin. Object Lock erişim kaybını, hesabın kapanmasını veya şifre çözme anahtarının silinmesini önlemez; saklama korumasını erişim ve anahtar yönetimiyle tamamlayın.
S3 Object Lock: Sürüm, Mod ve Saklama Süresi
S3 Object Lock, WORM yaklaşımıyla belirli bir nesne sürümünü korur. Hem yeni hem mevcut genel amaçlı bucket’larda etkinleştirilebilir; Versioning açık olmalıdır. Etkinleştirildikten sonra Object Lock kapatılamaz ve bucket’ın versioning durumu askıya alınamaz. Aynı nesne anahtarına yeni bir yükleme yapılması, korunan sürümü değiştirmek yerine ayrı bir sürüm oluşturur.
Governance korumasını aşmak için s3:BypassGovernanceRetention yetkisi ve istekte açık bypass seçimi gerekir; S3 konsolu bu başlığı yetkili kullanıcı adına ekleyebilir. Compliance modunda retention sürerken korunan sürüm silinemez, mod değiştirilemez ve süre kısaltılamaz; root kullanıcı da buna dahildir. Yetkili kullanıcı süreyi uzatabilir. Compliance seçimi tek başına her mevzuata uygunluk belgesi değildir.
Bu rehberdeki sabit retention örnekleri bir retain-until tarihi kullanır. Legal hold ise tarih sınırı olmadan yetkili kullanıcı kaldırana kadar sürer. İkisi bağımsızdır: retention bitse bile legal hold korumayı sürdürebilir; legal hold kaldırıldığında devam eden retention ortadan kalkmaz. Governance bypass yetkisi de legal hold’u aşmaz.
Ayrıntılar için AWS S3 Object Lock belgelerine başvurun. Bucket varsayılan retention ayarı, sonradan yazılan uygun yeni sürümlere uygulanır; mevcut sürümlere geriye dönük toplu kilit koymaz. Açıkça verilen nesne sürümü ayarları varsayılanın önüne geçebilir. Bu nedenle yalnızca bucket ayarını değil, saklamak istediğiniz sürümlerin gerçek modunu ve bitiş tarihini doğrulayın.
Versioning ve Delete Marker Ayrımı
Versioning açık bir bucket’ta aynı anahtara yapılan yeni yükleme ayrı bir version ID üretir. Sürüm belirtilmeyen normal DELETE, genellikle bir delete marker ekler; eski sürümleri kalıcı olarak silmez. Version ID belirtilerek yapılan DELETE ise o sürümü kalıcı silmeyi hedefler ve ilgili izinlerle Object Lock/MFA Delete kontrollerine tabidir. Etiket güncellemesi gibi her işlem yeni bir veri sürümü üretmez.
Örnek olarak bir raporun yeni yüklemesinin bozulduğunu düşünün. Olay zaman çizelgesi ve kayıtlarla temiz adayı belirleyin, tam version ID’sini kaydedin ve bu sürümü izole hedefe geri yükleyin. Dosyanın hash değerini ve uygulamanın veriyi okuyabildiğini kontrol edin. “En son sürüm” seçimi, saldırı öncesi temiz noktayı seçmekle aynı şey değildir.
Versioning geçmişi tutar, fakat yeterli silme yetkisine sahip bir kullanıcı korumasız eski sürümleri silebilir. Object Lock bu geçmişteki seçilmiş sürümlere ek koruma sağlar. Delete marker eklenmesi halen mümkün olduğundan, normal nesne adresinin bulunamaması halinde sürüm listesini ve kilit bilgisini incelemek kurtarma planının bir parçasıdır.
S3 Versioning rehberi bu davranışları açıklar. Her sürüm yalnızca değişiklik farkı değil, ayrı depolama maliyeti olan tam nesnedir; retention ve eski sürüm sayısını birlikte takip edin.
MFA Delete: Korunan İşlemler ve Lifecycle Sınırı
MFA Delete, nesne sürümünün kalıcı silinmesi ve bucket versioning durumunun değiştirilmesi için ek doğrulama ister. Normal DELETE ile delete marker oluşturulmasını genel olarak engelleyen bir mekanizma değildir. İstek, kimlik bilgileriyle birlikte kayıtlı ve desteklenen donanımsal veya sanal MFA cihazının seri numarasını/ARN’sini ve ürettiği altı haneli kodu içerir. Her güvenlik anahtarı bu kodu üreten cihaz türü değildir.
Varsayımsal bir temizlik işleminde yanlış yedek sürümlerinin seçildiğini düşünün. Ek doğrulama, kapsamına giren işlemlerde durup hedefi kontrol etme fırsatı sunabilir. Ancak MFA, ekip onayının yerine geçmez; silme yetkilerini ve onay sürecini ayrıca planlamak gerekir.
AWS MFA Delete dokümanına göre açma/kapatma işlemi bucket sahibi hesabın root yetkisini ve CLI/API yolunu gerektirir; konsolda sıradan bir aç/kapat seçeneği değildir. MFA Delete, lifecycle yapılandırmalarıyla kullanılamaz. Otomatik katman geçişi gerekiyorsa Object Lock + Versioning + dar IAM yetkileriyle lifecycle tasarımını; MFA Delete gerekiyorsa lifecycle içermeyen ayrı işleyişi değerlendirin. Kayıtlı cihazı ve hesap kurtarma yolunu doğrulayın; herhangi bir yedek cihazın otomatik çalışacağını varsaymayın, root anahtarlarını günlük yedek otomasyonuna koymayın.
İzole Geri Dönüş Testleri Nasıl Planlanır?
Önce tek bir yedeği üretimden ayrılmış bir ortama geri yükleyin. Backup/version ID, araç ve veritabanı sürümü, şifre çözme erişimi ve beklenen veri zamanı kaydedilsin. Dosya bütünlüğüne ek olarak uygulamanın açılması, izinler, bağımlılıklar ve gerekli iş akışları kontrol edilsin. Başarılı indirme, başarılı hizmet kurtarmasıyla aynı sonuç değildir.
Örnek başlangıç takvimi haftalık küçük kontrol ve aylık tam hizmet geri dönüşü olabilir; gerçek sıklığı kritik hizmetler, değişim hızı ve yükümlülükler belirler. E-ticaret örneğinde korunan asıl yedeği değiştirmeden kısıtlı, izole bir kopya oluşturun. Test kullanıcıları erişmeden gereken maskelemeyi yapın; ödeme, e-posta ve webhook çıkışlarını sandbox veya engellenmiş hedeflere yönlendirin. Giriş, sipariş ve arama işlevlerini beklenen sonuçlarla sınayın.
RTO/RPO ve felaket kurtarma planı rehberi, bu testleri sorumlular ve karar adımlarıyla birleştirmeye yardımcı olur. RTO, kesintiden kabul edilen hizmet seviyesine dönüş için hedef süre; RPO, kesinti anından geriye doğru kabul edilebilir veri kaybı penceresidir. Hedefleri testte ölçülen gerçek sonuçlardan ayrı kaydedin.
Yedek Aktarımı, Şifreleme ve Replikasyon
Önce uygulama veya veritabanına uygun yöntemle tutarlı bir yedek üretin, sonra tamamlanmış yedek setini S3’e taşıyın. Canlı veritabanı dizinini sıradan dosya kopyasıyla taşımak tutarlılık kanıtı değildir. Versioning ve Object Lock açıkken bucket varsayılan retention’ı kullanabilir veya aracın desteklediği doğrulanmış sürüm ayarlarını uygulayabilirsiniz. Yükleme sonrası version ID, boyut/bütünlük, şifreleme, mod ve retain-until tarihini kontrol edin; bu bilgiler için okuma yetkileri de gerekir.
rclone ile S3/Backblaze B2 yedek aktarımı rehberi, taşıma ve maliyet kararlarını tamamlar. Araç ve depolama sağlayıcısının gerçek özelliklerini doğrulayın; S3 uyumlu API her üründe aynı Object Lock davranışını garanti etmez. Aktarımda TLS, depoda uygun şifreleme kullanın. SSE-KMS seçiliyorsa anahtar yönetimiyle kullanma yetkilerini ayırın; eski yedeklerin şifresini açan anahtarın devre dışı kalması veya silinmesi kurtarmayı engelleyebilir.
Farklı hesap, üretim kimlik bilgilerinden bağımsız silme/yönetim sınırı kurmaya; farklı bölge, bölgesel kesintiye hazırlanmaya yardımcı olur. Bu ayrımlar otomatik oluşmaz. Kilitli nesnelerin S3 replikasyonunda hedef bucket’ta da Object Lock açık olmalı; rolün retention/legal hold okuma dahil gerekli izinleri bulunmalıdır. SSE-KMS replikasyonu ayrıca etkinleştirilip hedef bölge anahtarı ve politikaları hazırlanmalıdır. Asenkron kopyanın tamamlandığını, hedefteki sürüm kilidini ve şifre çözmeyi ayrı doğrulayın.
Lifecycle, Saklama Maliyeti ve Erişim Süresi
Bu bölüm MFA Delete kullanılmayan lifecycle tasarımı içindir. Kilitli sürümler depolama sınıfları arasında taşınabilir; lifecycle korunan sürümü retention veya legal hold devam ederken kalıcı silemez. Sürenin dolması da nesneyi kendiliğinden silmez: ayrıca uygulanabilir expiration kuralı veya yetkili silme gerekir. Hızlı geri dönüş gerektiren kopyaları erişimi uygun sınıfta tutun, arşivi ayrı değerlendirin.
AWS, 16 Temmuz 2026’da Standard-IA ve One Zone-IA geçişleri için eski 30 günlük bekleme şartını kaldırdı; bu sınıflara oluşturma gününden itibaren lifecycle geçişi planlanabilir. Bu değişiklik asgari depolama ücretini kaldırmaz. Standard-IA için 30, Glacier Instant/Flexible Retrieval için 90, Deep Archive için 180 günlük asgari ücretlendirme süreleri vardır. Glacier Instant Retrieval doğrudan erişim sağlar; Flexible Retrieval ve Deep Archive önce restore isteği gerektirir ve bekleme süresi seçilen erişim yöntemine göre değişir. Deep Archive dakikalık RTO beklentisiyle uyuşmayabilir.
Loglar, finansal kayıtlar ve medya için ihtiyaçlar farklı olabilir; retention kararlarını veri sahibinin gereksinimleriyle belgeleyin. Son 90 gündeki geri dönüş talepleri, toplam GB ve sürüm sayısı, erişim sıklığı, geçiş/istek/veri çekme ücretleri birlikte değerlendirilmelidir. Küçük nesnelerde geçiş maliyeti tasarrufu aşabilir; yeni lifecycle yapılandırmalarında 128 KB altındaki nesneler varsayılan olarak geçiş yapmaz. Örnek sınıf takvimini gerçek boyutlar ve test sonuçlarıyla doğrulayın.
Örnek Olay: Bozulmuş Veriden Temiz Sürüme Dönüş
Varsayımsal bir olayda dosya değişiklikleri ve sıra dışı erişim denemeleri görülüyor olsun. Önce olay kapsamını belirleyip ele geçirilen yetkileri sınırlandırın, inceleme kayıtlarını koruyun ve temiz olduğu düşünülen yedek sürümlerini seçin. Son yükleme saldırıdan etkilenmiş olabilir; Object Lock verinin temizliğini incelemez. Governance bypass, legal hold ve anahtar erişimi dahil koruma durumunu kontrol edin.
Runbook, seçilen version ID’yi, geri yükleme hedefini, doğrulama adımlarını ve sorumluları göstermelidir. İzole ortamda dosya ve veritabanını geri yükleyip kabul kontrollerini çalıştırın. Bu örneğe belirli bir başarı süresi atamak doğru değildir; veri boyutu, depolama sınıfı, erişim ve bağımlılıklar sonucu değiştirir. Karar, indirme, veritabanı kurtarma ve hizmet doğrulama sürelerini ayrı ölçün.
Bu senaryoda eksik bir konfigürasyon dosyası, uygulamanın ana sayfası açıldığı halde iç işlevlerin bozulmasına yol açabilir. Yedek kapsamına yapılandırmaları ve güvenli sır kurtarma yolunu ekleyin. Sonuçları yalnızca “sunucu açıldı” diye kapatmayın; hangi kullanıcı akışının hangi veriyle doğrulandığını yazın.
Veritabanı ve Dosya Kurtarma Noktalarını Eşleştirin
PITR, uygun bir temel yedek ve hedef noktaya kadar gereken kesintisiz WAL/log zinciriyle veritabanını seçilmiş bir zamana döndürür; tek bir dosya kopyası bunu sağlamaz. Araç, sürüm ve recovery hedefini birlikte doğrulayın. PostgreSQL ve pgBackRest PITR rehberi bu akışı ayrıntılandırır. Yedek ile gerekli logların tümünü kapsayan saklama süresi planlayın.
Web dosyaları bir sürüme, veritabanı beş dakika sonraki noktaya dönüyorsa medya kaydı veya uygulama şeması uyuşmayabilir. “Uygulama X: dosya sürümü A, veritabanı hedefi B, dağıtım/konfigürasyon sürümü C” şeklinde eşleştirme tutun. Bunların birebir aynı saat etiketi taşıması yetmez; seçilen noktaların uygulama açısından birlikte çalıştığını doğrulayın.
Veritabanını önce erişimi kısıtlı, üretimden ayrılmış bir ortamda kurtarın. Maskeleme gerekiyorsa türetilmiş test kopyasına uygulayın; tek kurtarma yedeğini değiştirmeyin. Üretim parolalarını ve dış servis bağlantılarını test ortamına uygun değerlerle değiştirin, veri erişimini sınırlandırın. Gerçek sorgularla ilişkileri ve iş sonuçlarını kontrol edin; yalnızca satır sayısı veya hash, tüm uygulama tutarlılığını kanıtlamaz.
IAM, CloudTrail ve Acil Durum Erişimi
Yedek yazma, geri okuma, retention yönetimi ve silme yetkilerini ayırın; public access’i engelleyin. Yükleme rolüne görev için gereken en dar izinleri verin: multipart aktarım, listeleme, doğrulama ve KMS işlemleri kullanılan araca göre ek izin gerektirebilir. Günlük role sürüm silme, governance bypass veya bucket kilit politikası yönetimi vermeyin. MFA koşullu IAM erişimi, bucket özelliği olan MFA Delete ile aynı mekanizma değildir.
CloudTrail nesne düzeyi data event kayıtları varsayılan olarak açık değildir. İlgili bucket/prefix ve okuma-yazma kapsamını açıkça seçin, maliyeti ve kayıt hedefini planlayın. Version ID içeren DeleteObject gibi silme istekleri için data event’leri; bucket versioning/politika değişiklikleri için management event’leri izleyin. Yetkili bir deneme ile kayıt ve alarmın gerçekten oluştuğunu doğrulayın. Break-glass erişimini günlük otomasyondan ayırın, kullanımını kaydedin ve normal kimlik sistemi yokken de erişim yolunu sınayın.
Terraform ile altyapı otomasyonu rehberi tekrarlanabilir yönetim için bir başlangıçtır. Politikaları kodda tutarken gerçek hesap, bucket ve anahtar hedeflerini plan üzerinden gözden geçirin. IaC uygulanması, retention altındaki sürümlerin kısaltılabileceği veya silinebileceği anlamına gelmez; değişiklik sonrası etkili ayarları yeniden okuyun.
Koruma ve Test Planını Birlikte Değerlendirin
Retention penceresi saldırının fark edilmesine kadar geçebilecek süreyi ve gereken kurtarma geçmişini kapsamalıdır. Yalnızca son başarılı yükleme saatine bakmak yeterli değildir. Eski temiz sürümlerin, ilgili veritabanı loglarının ve şifre çözme anahtarlarının aynı kurtarma planını desteklediğini kontrol edin.
Haftalık küçük kontrol ve aylık tam geri dönüş örnek takvimini ekip sorumluluklarına bağlayın. Sırayla farklı bucket ve depolama sınıflarını kapsayın; önemli uygulama, anahtar, yetki veya araç değişikliklerinden sonra ilgili testi tekrarlayın. Yeni ekip üyelerinin runbook’u izleyebilmesi, eksik örtük bilgileri ortaya çıkarır.
Ucuz depolama sınıfı toplam kurtarma maliyetini mutlaka düşürmez. Veri çekme, geçici ortam ve iş kesintisi maliyeti de önemlidir. Hem hızlı erişilen son kopyaların hem uzun süreli arşivin gerçek geri yükleme süresini ölçüp iş hedefiyle karşılaştırın.
WordPress ve Laravel Yedek Kapsamı
WordPress için veritabanı, medya yüklemeleri, kullanılan tema/eklenti sürümleri ve yapılandırmaları birlikte düşünün. Laravel için veritabanı, kalıcı storage verisi, dağıtım sürümü, yapılandırma ve gerekli sırların kurtarma yolu önemlidir. Object Lock canlı klasöre değil, S3’te oluşturduğunuz yedek nesne sürümlerine uygulanır. Statik/dinamik ayrımı yedek sıklığını etkileyebilir; retention’ı yalnızca dosya türüne göre belirlemeyin.
Gizli dosyalar veya environment değişkenleri eksikse giriş sayfası açıldığı halde ödeme ve arka plan işleri başarısız olabilir. Bu bağımlılıkları runbook’a ekleyin, sır değerlerini açık dokümana kopyalamayın. Ödeme kontrolünü sağlayıcının sandbox ortamında ve test hesabıyla yapın; üretimde gerçek tahsilat, e-posta veya webhook oluşturmadan beklenen uygulama sonucunu doğrulayın.
Uygulama Öncesi Kısa Kontrol Listesi
Bucket Aşaması
Yeni veya mevcut genel amaçlı bucket’ta Versioning ve Object Lock durumunu kontrol edin. İş gerekçesine uygun varsayılan retention seçip küçük test nesnelerinin gerçek kilidini okuyun; mevcut yedeklerin ayrıca korunup korunmadığını inceleyin. Farklı varsayılan süreler için ayrı bucket’lar gerekebilir. Prefix düzeni sınıflandırmaya yarar; tek başına prefix’e özel bucket varsayılan retention oluşturmaz.
Versioning ve Kurallar
MFA Delete kullanmayan tasarımda lifecycle kurallarını veri boyutu, sınıf kısıtları, retention ve hedef RTO ile birlikte doğrulayın. Mevcut compliance sürümünün süresini kısaltamazsınız; varsayılanı değiştirmek de önceki sürümlerin süresini değiştirmez. Testte yalnızca yeni yüklemeyi değil, geçmiş sürümü seçerek geri dönüşü de doğrulayın.
MFA ve Yetki
MFA Delete seçiyorsanız lifecycle olmadan çalışacak silme ve maliyet sürecini belgeleyin. Root hesabın desteklenen MFA cihazına erişimi ve kurtarma adımlarını kontrollü biçimde doğrulayın; sırları runbook’a yazmayın. Governance bypass veya legal hold kaldırma yetkisi ayrı ve dar kapsamlı olsun. MFA sahipliği, ekip onayı ve doğru hedef seçimi birbirinin yerine geçmez.
Geri Dönüş Süresini Aşamalarıyla Ölçün
Ölçümü yalnızca dosya indirme süresinde bitirmeyin. Arşiv bekleme, transfer, veritabanı recovery, uygulama başlatma, doğrulama ve kullanıcı trafiğinin yönlenmesi ayrı aşamalardır. Darboğaz yeniden kurulumsa otomasyonu; arşiv beklemesiyse depolama sınıfını değerlendirin. Değişikliği uyguladıktan sonra aynı kabul kontrolleriyle tekrar ölçün.
Varsayımsal olarak dosyaları 20 dakikada geri yükleyip istemci yönlenmesi için 40 dakika daha beklemek, ilk aşamanın RTO’yu tek başına belirlemediğini gösterir. DNS TTL’ini olay anında düşürmek önceden önbelleğe alınan cevapları hemen yenilemez. Geçici hostname ancak istemci yönlendirmesi, TLS sertifikası, cookie ve callback adresleri hazırlanıp test edilmişse işe yarar; otomatik bir çözüm değildir.
Kesinti, karar, geri yükleme ve hizmet kabul zamanlarıyla son tutarlı veri noktasını kaydedin. Örnekteki süreler performans vaadi değildir. Veri hacmi ve uygulama değiştikçe kayıtları karşılaştırın; hedef aşılırsa sorumlu, düzeltme ve yeniden test tarihi belirleyin.
Kontrollerin Sınırlarını Birlikte Okuyun
Versioning geçmiş sürümleri ayırır; Object Lock belirli sürümlerin korunmasını mod ve yetkilere göre uygular; MFA Delete ise kapsamındaki işlemlere ek doğrulama getirir. Lifecycle gerekiyorsa MFA Delete uyumsuzluğunu tasarımda çözün. Bu kontrollerin hiçbiri bozuk yüklemenin temiz olduğunu, anahtarın erişilebilir kaldığını veya uygulamanın geri döndüğünü tek başına doğrulamaz.
TLS aktarım korumasını, depolama şifrelemesini ve geri okuma yetkisini birlikte sınayın. SSE-KMS kullanılıyorsa key policy değişikliği, disable ve silme planlama işlemleri için ayrı yetki ve izleme gerekir. Anahtarın kendisi silinmişse Object Lock şifre çözmeyi geri getiremez. Kaynak ve replika için gerçek kurtarma rolüyle kontrollü okuma testi yapın.
Saklama Stratejisini Ne Zaman Güncellemelisiniz?
Örneğin altı ayda bir plan değerlendirmesi yapın; önemli veri, uygulama, ekip veya yükümlülük değişiminde bu tarihi beklemeyin. Bu değerlendirme haftalık/aylık geri dönüş testlerinin yerine geçmez. Yeni yüklemelerin varsayılan süreleriyle mevcut sürümlerin tarihlerini ayrı ele alın; uzatma kararı, devam eden korumayı kısaltabileceğiniz anlamına gelmez.
Bir politikayı değiştirmeden önce maliyet, erişim süresi ve gereken en eski kurtarma noktası üzerindeki etkisini inceleyin. Legal hold’un kaldırılması ayrı yetki ve gerekçe gerektirir; retention dolunca otomatik kalkmaz. Başarısız kopya veya şifre çözme testini çözmeden eski kurtarma kapsamını azaltmayın.
İlk Güvenilir Kurtarma Noktasını Doğrulayın
Başlangıç için bir yedek seti seçin: tutarlılığını üretim yöntemiyle doğrulayın, korunan S3 sürümünü ve anahtar erişimini kaydedin, izole ortamda geri yükleyin ve gerçek uygulama kontrollerini tamamlayın. Sonuçları bir runbook’a bağlayıp haftalık küçük ve aylık tam test için örnek takvimi iş ihtiyacına uyarlayın.
