S3 Object Lock ile Fidye Yazılıma Karşı Kale Gibi Yedek: Versioning, MFA Delete ve Geri Dönüş Testlerini Samimi Samimi Konuşalım

Ofiste “Silinmeyen Yedek” Muhabbeti ve Neden Önemli Olduğunu Anladığım O Gün

Hiç başınıza geldi mi? Sessiz sakin bir sabah, kahve daha bitmemiş, Slack’te bir mesaj: “Yedekler de şifrelenmiş olabilir mi?” İşte o an, kalp bir anlığına duruyor. Bir müşteride yaşamıştık; sunuculara fidye yazılımı bulaşmış, dosyalar şifrelenmiş, bazı paylaşımlı alanlar boşalmış. Neyse ki yedeklerimiz farklı bir yere akıyordu ama o gün bir şey kafama kazındı: Yedek dediğin, sadece başka bir kopya değil; gerektiğinde bir şalter indirip geri dönmeni sağlayan, dokunulamaz bir sigorta poliçesi olmalı.

Bu yazıda tam da bunu konuşacağız. S3 Object Lock ile immutability (değiştirilemezlik) ne demek, neden fidye yazılımlara karşı çok güçlü bir kalkan? Versioning ile yan yana nasıl çalışır, MFA Delete devreye girdiğinde silmeler nasıl iki kere düşünülür hale gelir? Ve en önemlisi, bütün bunlar kağıt üstünde kalmasın diye geri dönüş testlerini nasıl planlayıp canlandırırız? Hadi birlikte adım adım gidelim; teknik terimlere boğulmadan, gerçek hayatta işimize yarayacak bir çerçeve kuralım.

Bu arada, aklınızda pratik bir akış canlansın diye zaman zaman “Mesela şöyle düşünün…” diye ufak senaryolarla ilerleyeceğim. Böylece sadece kavramları değil, uygulamayı da birlikte kurgularız.

Ransomware Korkusunu Kıran Fikir: Değiştirilemeyen Yedek

Fidye yazılımlarının en can sıkıcı tarafı, sadece dosyaları şifrelemekle kalmayıp “geriye dönüş kapılarını” da kapatmaya çalışmaları. Yani saldırgan yedekleri de hedef alıyor; bazen siliyor, bazen üzerine yazıyor, bazen erişimi kilitliyor. İşte immutability burada devreye giriyor: Belli bir süre boyunca yedeklere dokunulamıyor. Ne yanlışlıkla, ne de kötü niyetle. Ne bir kullanıcı, ne de bir süreç o dosyayı silemiyor veya üzerinde oynama yapamıyor.

Mesela şöyle düşünün: Bir kasanız var ve içine kritik kasetleri koyuyorsunuz. Kasayı kapattığınızda, belirlediğiniz tarih gelene kadar anahtarı sizde bile olsa kilit açılmıyor. S3 Object Lock tam olarak bu hissi veriyor. Fark, bunun bir veri nesnesi üzerinde, bulutta ve fena halde pratik oluşu.

Bazı ekipler, bunun “fazla sert” bir yaklaşım olduğundan korkuyor; “Ya yanlış retention süresi koyarsak?” diye soruyor. Haklılar, çünkü yanlış süre hem maliyeti, hem de esnekliği etkiler. Ama kural doğru kurulunca, bu “sertlik” aslında panik anında aradığınız dinginlik oluyor. Silinmezlik, yanlış bir komutu bile etkisiz kılıyor.

S3 Object Lock Nedir, Nasıl Çalışır? (Ve O Küçük Ama Kritik İlk Adım)

Önce en temelinden: S3 Object Lock, nesnelerin belirli bir süre boyunca WORM (Write Once, Read Many) mantığıyla saklanmasını sağlıyor. Yani bir kere yazıyorsunuz, sonra sadece okuyorsunuz. Bu kilidi koyduktan sonra, süre dolana kadar değiştirme yok, silme yok. Hatta kaçamak bir kısayol da yok. Bu özelliği kullanabilmek için, bucket oluştururken Object Lock’ı aktif etmiş olmanız gerekiyor; sonradan “bir tıkla açayım” yok. Bu küçük detay, her projede ilk checklist maddelerimden biri haline geldi.

İkinci nokta, mode seçimi. Basitçe anlatayım: “Governance” modunda, belli yetkilerle yine de bazı yönetsel istisnalar yapılabiliyor. “Compliance” modunda ise “bıçak gibi” kesin; süre bitmeden kimse dokunamıyor. Finansal kayıt gibi mutlak korunması gereken veriler için compliance, günlük operasyonlar için governance daha rahat hissettiriyor. Ama hangi modu seçerseniz seçin, temel fikir aynı: Süre bitene kadar o yedek orada güvende.

Üçüncü parça, retention süreleri ve legal hold. Retention, süre bazlı kural koyuyor; legal hold ise “süre bağımsız bir durdurma düğmesi” gibi, kaldırana kadar nesne kilitli kalıyor. Mesela bir olay araştırması yapıyorsanız ve o sırada bazı yedeklerin hiç kıpırdamamasını istiyorsanız, legal hold “dur, burada kal” diyor.

Detaylı okumak isterseniz AWS S3 Object Lock belgeleri sade bir referans sunuyor; ama şunu bilin: Günlük hayatta en kritik karar, bucket’ı baştan doğru hazırlayıp doğru retention stratejisini belirlemek oluyor.

Versioning Neden Hayat Kurtarır? En Basit Haliyle Geri Alma Bileti

Versioning’i, bir dosyanın zaman makinesi gibi düşünün. Her yeni yükleme, yeni bir versiyon. Bir şeyi yanlışlıkla güncellediniz veya fidye yazılımı dosyayı bozdu; dert etmiyorsunuz, çünkü eski versiyon orada, sessiz sakin bekliyor. S3’te silme bile aslında bir tür versiyon; yani delete marker atılıyor ve geride gerçek nesne versiyonları kalıyor.

Mesela şöyle düşünün: Bir rapor dosyası var; akşam saatlerinde beklenmedik bir akış, dosyayı bozuyor. Ertesi sabah, versioning sayesinde önceki temiz versiyona dönüyorsunuz. Sizin tek yapmanız gereken, hangi versiyonun “temiz” olduğuna karar vermek. Bu karar için de izleme ve loglar çok işe yarıyor.

Versioning, tek başına da işe yarıyor ama Object Lock ile yan yana çok daha güçlü bir kalkan oluyor. Çünkü saldırgan sadece overwrite ve delete ile oynasa bile, en kritik versiyonlar belirli süreyle dokunulmaz. Buna “yedeklerin yedeği” gibi bakabilirsiniz; üst üste kesişen güvenlik halkaları.

Versioning’in mantığını daha iyi anlamak isterseniz, bir göz atmak faydalı olur: S3 Versioning rehberi. Ama işin özü şu: Bir günümü kurtaran özelliklerden biri oldu; basit, görünmez, ama kritik.

MFA Delete: Silmeye “Bir Düşün Daha” Freni

MFA Delete, silme ve bazı versiyon işlemlerine ikinci bir doğrulama koyuyor. Yani birisi yanlışlıkla, aceleyle veya kötü niyetle bir nesneyi silmek istediğinde, karşısına bir duvar çıkıyor: ikinci adım. Telefonunuzda ya da donanım anahtarınızda üretilen tek seferlik kod olmadan, o silme olmuyor. Güzel tarafı şu: Insani hatayı da, kritik bir anda oluşabilecek panik hamleleri de frenliyor.

Ben bir projede, admin arayüzden hızlıca yapılan bir temizlik sırasında yanlış klasörün hedef alındığını görmüştüm. “Neyse ki MFA açık” dediğimiz andaki ferahlığı unutamam. Üstelik bu sadece bireysel koruma değil; değişiklikleri planlamayı da öğretiyor. Çünkü silme, artık bir ekip kararı haline geliyor.

Teknik ayrıntıya çok girmeden şunu da not edeyim: MFA Delete’i etkinleştirme ve kullanma tarafında bazı işlem adımları var; ayrıntılar için MFA Delete dokümanı yol gösteriyor. Benim tavsiyem, MFA cihazlarını yedekli tutmak ve “kimde, nerede” bilgisini bir erişim kasasında saklamak. Panik anında ikinci cihazı bulamamak, gereksiz stres yaratıyor.

Geri Dönüş Testleri: Kağıt Üstünde Kalmayan Plan

İşin kalbi burada. Birçok ekip “Yedek alıyoruz ya” rahatlığıyla yıllar geçiriyor, geri dönüş günü geldiğinde ise beklenmedik küçük taşlar koca kamyonu durduruyor. O yüzden ben geri dönüş testlerini bir proje gibi ele alıyorum. Küçük başlayıp genişletmek güzel bir taktik. Önce tek bir uygulamanın tek bir yedeğini, bağımsız bir ortamda ayağa kaldırın. Sonra veri tutarlılığına, performansa ve erişim izinlerine bakın. Sürüm uyuşmazlığı var mı, uygulama gizli bir dosyayı arıyor mu? Küçük notlar alın, runbook’a ekleyin.

Mesela şöyle düşünün: Bir e-ticaret veritabanınız var. Haftalık bir ritim tutturup, prod verisini değil ama maskelemiş bir kopyayı, izole bir test ortamına döndürüyorsunuz. Uygulamanın login’i açılıyor mu, sipariş sayfaları normal mi, arama çalışıyor mu? Bu mini tatbikatlar, gerçek günü kolaylaştırıyor. Hem de ekibi dağıtmıyor; akıcı bir ritim.

Runbook tarafını seviyorsanız, RTO/RPO’yu netleştirip yedek testlerini gerçekten çalışır hale getirmek üzerine derli toplu bir yol haritası işinizi hızlandırabilir. En sevdiğim detay, karar anlarında kimin ne yapacağını netleştirmek. Böylece telefon trafiği azalıyor, herkes neyi nereden kontrol edeceğini biliyor.

Uçtan Uca Akış: Yedekleri Nasıl Taşıyıp Kilitleriz?

Tüm bu özellikler güzel ama günlük akışınız nasıl olacak? Benim sevdiğim yaklaşım şu: Uygulamalar kendi yedeklerini yerelde üretsin, sonra bir senkronizasyon aracıyla S3’e aktarılsın. Versioning mutlaka açık, Object Lock kuralları net. İlk saatlerde sıcak erişim, sonra lifecycle ile daha soğuk katmanlara taşıma. Mesela 7 gün kolay erişim, 30 gün soğuk, 180 gün arşiv; tabii bu tamamen veri tipine göre değişir. Ama prensip şu: Her verinin bir ömrü var; akış bunu kabul etmeli.

Aktarım tarafında pratik bir örnek arıyorsanız, rclone ile S3/Backblaze B2 yedek senkronizasyonu ve lifecycle ile maliyeti düşürme yazısındaki akışlar işinize yarayabilir. Özellikle şifreleme ve saklama politikalarını akıllıca kurunca, hem güven hem bütçe tarafı dengeleniyor.

Bir ipucu daha: Yedekler yalnızca bir hesaba bağlı olmasın. Cross-account mantığı, “tek anahtarın sahibi” riskini azaltıyor. Ayrıca bazı ekipler, farklı bölgeye replikasyonla “bölgesel felaket” ihtimalini de kapsıyor. Burada da Object Lock kurallarının replikasyon tarafında nasıl taşındığına dikkat etmek önemli; testlerde bunu da doğrulayın.

Maliyet, Yaşam Döngüsü ve Akıl Sağlığı

Konuşmadığımız bir şey kaldı: Maliyet. İtiraf edeyim, ilk başta “kilitli yedekler pahalıya patlar mı?” diye ben de çok düşündüm. Ama akış doğru oturunca, lifecycle ve arşiv katmanları devreye girdiğinde gayet yönetilebilir oluyor. Şöyle bir ritim iyi işliyor: İlk günler daha hızlı erişim; kısa süre sonra daha ucuz sınıfa geçiş; daha sonra arşiv. Bu sayede “Kritik dönemde hızlıyım, uzun vadede ekonomik” dengesini tutturuyorsunuz.

Saklama süresi, her veri için aynı olmak zorunda değil. Loglar daha kısa, finansal kayıtlar daha uzun; medya yedekleri kullanım senaryosuna bağlı. Bu kararları tek liste gibi düşünmeyin; veri profillerine göre ayrı kurallar koymak, bütçeyi de, riski de yönetiyor. Mesela web içeriği anlık restore isteyebilir, arşiv raporları daha sabırlı olabilir.

Ve evet, yanlış bir retention ya da gereksiz bir kural maliyeti şişirebilir. O yüzden ben üç şeyi bir arada takip ediyorum: Son 90 gün geri dönüş istekleri, aylık GB dağılımı ve erişim desenleri. Bu üçlü, “nerede şiştik, nerede zayıfız” sorusuna hızlı cevap veriyor.

Gerçek Dünya Senaryosu: Saldırı, Panik ve 38 Dakikada Ayağa Kalkmak

Bir akşam, bildirimler art arda düşmeye başladı. Disk kullanımı havaya fırlamış, bazı dosyalar beklenmedik şekilde değişmiş. İlk refleks, yedeği kontrol etmek oldu. İyi ki Object Lock ve Versioning kuralları yerli yerindeydi; geçmişte alınan dosyalar tertemiz duruyordu. Önce olayın kapsamını anladık, sonra izole bir ortamda hızlıca geri dönüş yaptık. Saldırganın “silme” hamleleri, MFA Delete duvarına takılmıştı.

En güzel tarafı, bu anın daha önce provası yapılmıştı. Dokümanda “önce X yedeğini dön, audit loglara bak, uygulama için Y adımını çalıştır” diye net bir akış vardı. Ekip içinde roller belliydi; kim kiminle konuşacak, kim hangi ekranı kontrol edecek… Sonuç? Yayını etkileyen kısım, 38 dakika içinde temiz veriye döndü. Bu süre, ekip şemasına ve veri büyüklüğüne göre değişir elbette ama hissi şu: Panik yok; adımlar belli.

Bu senaryoda en çok şaşırdığım şey, küçük bir veri parçasının atladığımızda nasıl büyük gecikmelere yol açabildiği. Bir konfig dosyası, yanlış yerde olunca uygulama açılmış görünüp iç sayfada takıldı. Sonraki testlerde “konfiglerin özel yedeği” diye ayrı bir satır ekledik. Ufak bir not, büyük bir fark.

Veritabanı Geri Dönüşleri: Yalnız Dosyalar Değil, Zaman Çizgisi de Önemli

Dosyalar bir yana, veritabanları ayrı bir dünya. Burada sadece “dosya geri dönmek” değil, zaman çizgisini doğru yakalamak kritik. Örneğin PITR (Point-In-Time Recovery), olaydan hemen önceki dakikayı yakalamak için harika. Ben veritabanı tarafında pratik çalışmaları anlatan şu rehbere çok başvurdum: PostgreSQL yedekleme ve noktaya dönüş (PITR) pratik adımları. Buradaki disiplin, dosya yedekleriyle birleşince tam bir zırh oluyor.

Mesela şöyle düşünün: Web dosyalarını bir versiyona döndünüz, ama veritabanınız 5 dakika ileride. O zaman veri uyumsuzluğu yaşayabiliyorsunuz. Bu yüzden “Uygulama X için dosya versiyonu A, veritabanı zamanı B” diye çift taraflı bir not tutmak çok iş görüyor. Bir çeşit senkron dansı gibi; ikisi aynı ritme girmeli.

Veritabanı geri dönüşlerinde test verisi maskeleme ve izole ortam şart. Canlı veriyi test ortamına getirmeyin; maskeleyin, sınırlandırın, şifreleri değiştirin. Bu hem güven, hem de yasal taraf için iyi bir alışkanlık.

Kimlik, Yetki ve Küçük Polisler: IAM Kuralının Gücü

İşin bir de erişim tarafı var. Ben S3 için “silmeyi özel şartlara bağlayan” politikaları seviyorum. Mesela şöyle bir kural, düşünce olarak hoşuma gidiyor: “Silme işlemi için MFA zorunlu.” Bu, MFA Delete ile ruhen aynı fikir; bir adım daha güvenlik. Yine “public access” tarafını sıkı tutmak, yazma yetkilerini az kullanıcıya vermek ve CloudTrail ile “kim, ne zaman ne yaptı”yı rahatça okuyabilmek, bir saldırı anında zaman kazandırıyor.

Bir başka pratik, break-glass hesabı. Yani kapalı bir zarfta, yetkisi güçlü ama çok nadiren kullanılan bir kullanıcı. Sadece gerçekten gerekli anlarda açılıyor, sonra tekrar kapatılıyor. Bu hesabın kimde olduğu, MFA cihazının nerede durduğu, erişim günlüğünün nasıl yazıldığı gibi detayları runbook’ta net yazmak, gelecekteki siz’e teşekkür sebebi.

Eğer otomasyon seviyorsanız, bu kuralları altyapı kodu olarak yazmak çok ferahlatıcı. Ben çoğu ortamda, Terraform ile altyapı otomasyonu ve tekrarlanabilir dağıtımlar yazısını referans alarak bir temel kuruyorum. Böylece ortamlar arasında tutarlılık geliyor; elle yapılan hatalar azalıyor.

Küçük Taşlar, Büyük Dersler: Deneyimden Notlar

İlk ders: Object Lock olmadan versioning bile zaman zaman yetersiz kalabiliyor. Çünkü saldırgan bazen “silme” ile yetinmiyor, “üstüne yazma” ve “kilitleme” gibi hileler deniyor. Nesne düzeyinde değiştirilemezlik, bu oyunları boşa çıkarıyor. Burada retention süresinin kararını iş birimleriyle birlikte almak güzel; “kaç gün, hangi veri için?” sorusuna ortak bir cevap vermek, sonradan çıkan sürprizleri azaltıyor.

İkinci ders: Geri dönüş testlerini “sıkıcı bir zorunluluk” değil, ekip ritminin parçası yapmak gerekiyor. Ayda bir küçük tatbikat, üç ayda bir büyük tatbikat; hem bilgi tazelenir, hem de yeni katılanlar ritmi yakalar. Bir tatbikatta bir modülün hiç beklemediğiniz bir özelliğiyle zorlanabilirsiniz; ertesi ayın konusu çıkar.

Üçüncü ders: Maliyet konuşmasını ertelemeyin ama geri dönüşü de ucuzlatmayın. Bir iki saniye kazanalım diye her şeyi sıcak tutmak şart değil; ama “iki gün uğraşalım ucuz olsun” da hiç gereksiz. Veri profillerine özel süre ve katman kombinasyonu, hem cüzdanı, hem sabrınızı koruyor.

WordPress, Laravel, Dosyalar ve “Şurada Bir Küçük Yedek Daha” Hissi

Web uygulamalarında dosya ve veritabanı ikilisi meşhur. WordPress’te medya yüklemeleri, tema dosyaları, eklentiler derken birbiriyle iç içe bir yapı oluyor. Laravel’de storage klasörü, config, env dosyaları, public içerikler… Ben bu tür ortamlarda, dosya yedeklerini sürümlemek ve en kritik klasörlere Object Lock uygulamakla birlikte, “statik-ezilen-dinamik” ayrımı yapmayı seviyorum. Yani statik dosyalar için daha uzun retention, dinamikler için daha kısa ve sık yedek gibi bir denge.

Birçok ekibin gözden kaçırdığı nokta, gizli dosyalar ve environment değişkenleri. Uygulama ayağa kalkıyor ama kritik bir env değeri eksikse, iç sayfalarda bocalayabiliyor. Geri dönüş testlerinde “Uygulama açıldı mı?” sorusunun yanına “Ekrandan ödeme yapılıyor mu?” gibi gerçek akış sorularını da ekleyin. Küçük ama etkili.

S3’te Küçük Bir “Nasıl Yapılır” Krokisi: Yol Kaybetmeyin

Bucket Aşaması

Yeni bir bucket açarken Object Lock seçeneğini aktif etmeyi unutmayın. Bu, sonradan açılmadığı için en kritik adım. Varsayılan retention süresini çok agresif yapmayın; önce küçük başlayıp, gözlemlerle iyileştirmek iyi bir pratik. Büyük projelerde, farklı veri tipleri için ayrı bucket ya da en azından ayrı önekler (prefix) kullanmak düzeni artırıyor.

Versioning ve Kurallar

Versioning her zaman açık olsun. Bu, günlük hatalardan karmakarışık senaryolara kadar geniş bir güven alanı sunuyor. Lifecycle kurallarıyla “şu klasörleri şu sürede şu katmana taşı” gibi basit ama etkili politikalar kurun. İlk günler, erişim ve geri dönüş testlerinden öğrendiklerinizle bu kuralları yumuşatıp sertleştirebilirsiniz.

MFA ve Yetki

MFA Delete ve silme için MFA zorunluluğu, birden fazla hatayı tek hamlede engelliyor. Silme yetkisini sadece birkaç kişide tutmak, acil durumlar için yedek MFA cihazları planlamak ve “kimde, nerede” bilgisini netleştirmek gerek. Bu bilgiyi bir kasada saklamak, güncelliğini takip etmek de ayrıca önemli.

Süreçleri Ölçmek: “Oldu mu?” Değil, “Ne Kadar Sürdü?”

Geri dönüş testlerinde en sevdiğim soru “ne kadar sürdü?” oluyor. Çünkü bu soru, sizi doğrudan darboğaza götürüyor. Eğer dosya geri dönüşü kolay ama uygulama yeniden kurulum adımı yorucuysa, onu otomatikleştirme şansı yakalıyorsunuz. Eğer veritabanı geri dönüşü hızlı ama indeksleme sonradan uzuyorsa, o indeksleri farklı bir teknikle ele alma fırsatı doğuyor.

Mesela şöyle düşünün: 20 dakikada yedeği döndünüz ama 40 dakika DNS yayılımı beklediniz. O zaman strateji, geçici bir hostname üstünden servis vermek olabilir. Altyapı kodu bu noktada elinizi güçlendiriyor. İhtiyaç duyarsanız, Terraform ile altyapı otomasyonu ve tekrarlanabilir dağıtımlar yazısındaki pratikler güzel bir temel olabilir.

Bu ölçümleri yazmak, sadece bugün değil yarın da işinizi kolaylaştırıyor. Ekip büyüyor, uygulama büyüyor, veri büyüyor; süreler değişiyor. Yazılı bir kayıt, “dün nasıldı, bugün nasıl?” sorusuna hızlı yanıt verdiriyor.

S3 Object Lock + Versioning + MFA Delete: Üçlü Savunmanın Akıcı Hali

Bu üçlü birlikte çalıştığında ortaya güven veren bir resim çıkıyor. Versioning, yanlış güncellemeyi geriye aldırıyor. Object Lock, belli süre boyunca hiçbir gücün yedeklere dokunamamasını sağlıyor. MFA Delete ise “silme” hallerinde ikinci bir kapı bekçisi gibi duruyor. İsimleri teknik gelebilir; ama hissettirdikleri gayet insani: “Sakin ol, bir çıkış kapısı var.”

Bu arada bir not: Yedek taşırken şifreleme tarafını da unutmayın. Sunucudan çıkar çıkmaz şifreli taşımak, varışta da sunucu tarafında şifrelemek rahatlatıcı. Hangi yöntemi seçeceğiniz, ekibin alışkanlıklarına ve araç setine bağlı. Ama prensip basit: Yedek, yolculukta da güvende kalsın.

Ne Zaman Güncelleme, Ne Zaman Dondurma?

Yedek stratejisi bir kere yazılıp bırakılacak bir şey değil. Uygulama güncelleniyor, veri profili değişiyor, ekip büyüyor. Ben her altı ayda bir, “yedek ve geri dönüş stratejisi” oturumları yapmayı seviyorum. Bu oturumlarda, yaşanan küçük aksaklıklar ve yeni gereksinimler konuşuluyor. Gerekiyorsa retention süresi uzatılıyor, gerekiyorsa lifecycle kuralları yeniden dengeleniyor.

Bu dinamik yaklaşım, Object Lock’ın katılığını yumuşatmıyor; sadece doğru zemine koyuyor. “Değiştirilemezlik” bir kalkan; ama o kalkanı nerede, ne kadar süre kaldıracağınıza siz karar veriyorsunuz. Bu karar, pratikte maliyet, hız ve risk üçlüsünü dengeleyen bir sanat.

Kapanış: “Hadi Gerçekten Koruyalım” Demenin Pratik Yolu

Toparlayalım. Fidye yazılımları, sadece bir dosyayı değil, moralinizi de kilitleyebiliyor. Ama S3 Object Lock ile değiştirilemeyen yedekler, Versioning ile geri alma özgürlüğü ve MFA Delete ile “iki kere düşün” duvarı birleşince, tablo değişiyor. Üstüne düzenli geri dönüş testleri eklenince, “olur mu?” sorusu “nasıl, ne kadar sürede olur?”a dönüşüyor. İşte o gün, ekipteki herkes daha rahat uyuyor.

Başlamak için küçük bir liste bırakayım: Yeni bucket açarken Object Lock’ı işaretleyin, versioning’i kalıcı açık bırakın, silmelerde MFA’yı zorunlu kılın. İlk ay bir mini geri dönüş tatbikatı yapın. Sonra veriyi profillere bölüp lifecycle ile katmanlandırın. Ara ara ölçüp runbook’u güncelleyin. İsterseniz, Object Lock, Versioning ve MFA Delete dökümanlarını göz atmalık bir kenara pinleyin; unuttuğunuz bir ayrıntı olursa elinizin altında kalsın.

Son bir not: Bu yazıda bahsettiklerimiz, tek başına bir mucize değil. Ama birlikte uygulandıklarında, gerçekten güçlü bir savunma örüyorlar. Umarım bu satırlar, sizde de bir aksiyon planına dönüşür. Takıldığınız yerde yazın, beraber düşünelim. Bir dahaki yazıda görüşmek üzere.