Yedekleme işiniz 2:47 AM'de başarıyla tamamlandı. Günlükleri kontrol edersiniz, yeşil onay işaretini görürsünüz ve sabahınıza devam edersiniz. Üç hafta sonra, fidye yazılımı üretim ortamınızı ve aynı ağa bağlı her yedek kopyayı şifreler. Yeşil onay işaretleri hiçbir şey ifade etmiyordu. Yedekler oradaydı, ama güvende değildi.
Bu senaryo, çoğu BT ekibinin kabul ettiğinden daha sık gerçekleşir. Klasik 3-2-1 yedekleme kuralı, on yıldan fazla bir süredir kuruluşlara iyi hizmet etti, ancak fidye yazılımı operatörleri aynı on yılı yedekleme sistemlerinin nasıl çalıştığını öğrenmek için harcadı. Onları kasıtlı olarak hedef alıyorlar. 2026'da, yalnızca 3-2-1 üzerine kurulu bir yedekleme stratejisi bir güvenlik ağı değildir. Yanıltıcı bir güvenlik hissidir.
Bu kılavuz, sizi 3-2-1-1 yedekleme mimarisi konusunda yönlendirir: ne anlama geldiği, bulut altyapısında nasıl uygulanacağı ve NIS2, DORA, GDPR ve SOC 2 gereksinimlerine nasıl uyum sağlayacağı, böylece bir sonraki denetiminizin sorunsuz geçmesi sağlanır.
Anahtar Çıkarımlar
- 3-2-1-1 yedekleme kuralı, klasik 3-2-1 çerçevesine bir değiştirilemez, hava boşluklu kopya ekler; bu, tam kimlik bilgisi ihlalinden sonra bile fidye yazılımının ulaşamayacağı tek kopyadır.
- WORM (Bir Kez Yaz, Çok Kez Oku) depolama, değiştirilemezliğin teknik temelidir. Uygulama katmanı "salt okunur" bayraklar nitelikli değildir.
- RPO ve RTO hedefleri, iş yükü katmanına göre belgelenmeli, otomatikleştirilmeli ve düzenli olarak test edilmelidir; böylece NIS2, DORA, GDPR Madde 32 ve SOC 2 Tip II gereksinimlerini karşılar.
- Modern fidye yazılımı operatörleri, yedekleme ajanlarını, bulut depolama kimlik bilgilerini ve anlık görüntü programlarını kasıtlı olarak hedef alır ve şifreleme başlamadan önce haftalarca sürebilen bir bekleme süresi boyunca bunları hedef alır.
- Kurtarma testleri, denetçi hazır kayıtlar üretmelidir: zaman damgaları, bütünlük doğrulama sonuçları, gerçek RTO ve mühendis onayı, en az üç yıl süreyle saklanmalıdır.
İçindekiler
- Neden Klasik 3-2-1 Yedekleme Kuralı 2026'da Artık Yeterli Değil
- 3-2-1-1 Yedekleme Kuralı Gerçekte Ne Anlama Geliyor (ve Her Bileşen Sizin İçin Ne Yapar)
- Fidye Yazılımı Anatomisi: Saldırganlar Yedekleme Ortamlarını Nasıl Hedef Alır
- Her Yedek Kopya İçin Doğru Depolama Katmanını Seçmek (NVMe, SSD, HDD)
- Açık RPO ve RTO Hedefleri ile Otomatik Yedekleme Nasıl Yapılandırılır
- Değiştirilemez Yedek Kopyalar: Hava Boşluklu ve WORM Depolama Fidye Yazılımı Şifrelemesini Nasıl Durdurur
- Kurtarma Testi ve Denetim Kanıtı: Planlı Tatbikatlardan Denetçi Hazır Raporlara
- Uyum Haritalama: Yedekleme Mimarinizin Karşılaması Gereken NIS2, DORA, GDPR ve SOC 2 Gereksinimleri
- 3-2-1-1 Bulut Yedekleme Yığını için Adım Adım Uygulama Kontrol Listesi
- Fidye Yazılımı Dayanıklılığı Oluşturmak Bir Mimari Karardır, Ürün Kararı Değil
Neden Klasik 3-2-1 Yedekleme Kuralı 2026'da Artık Yeterli Değil
Fotoğrafçı Peter Krogh tarafından popüler hale getirilen ve daha sonra CERT ve sayısız BT çerçevesi tarafından benimsenen orijinal 3-2-1 kuralı basittir: verilerinizin 3 kopyasını tutun, 2 farklı medya türünde, 1 kopya dışarıda. 2000'ler ve 2010'ların çoğu için bu sağlam bir tavsiyeydi.
Sorun şu ki, fidye yazılımı grupları endüstrileşti. Modern fidye yazılımı aileleri, yedekleme yazılımı ajanlarını, NAS paylaşımlarını ve bulut bağlantılı depolama bucket'larını şifrelemeyi tetiklemeden önce özellikle avlar. Ağda günler veya haftalar geçirirler, temiz geri yükleme noktalarını şifrelenmiş verilerle değiştirmek için yedekleme döngülerinin geçmesini beklerler. Saldırıyı fark ettiğinizde, "dışarıda" kopyanız da şifrelenmiş veya tüm üç kopya arasında sadakatle çoğaltılmış bozuk veriler içeriyor olabilir.
2026 önceliklerini izleyen yedekleme ve kurtarma araştırmasına göre, değiştirilemezlik ve hava boşluklu depolama, fidye yazılımı kurtarma konusunda ciddi olan herhangi bir kuruluş için temel gereksinimler haline gelmiştir. 3-2-1 kuralı, yedekleme kimlik bilgilerinizi zaten ihlal etmiş bir saldırganı hesaba katmamıştır.
Ayrıca düzenleyici boyut da var. 2024'ün sonlarında AB üye devletlerinde uygulanabilir hale gelen NIS2 ve Ocak 2025'ten itibaren finansal kuruluşlara uygulanan DORA, belgelenmiş Kurtarma Süresi Hedefleri (RTO) ve Kurtarma Noktası Hedefleri (RPO) ile gösterilebilir kurtarma yetenekleri gerektirir. Var olan ancak çalıştığı kanıtlanamayan bir yedekleme, bir denetçiyi tatmin etmez. Mimari değişmelidir.
3-2-1-1 Yedekleme Kuralı Gerçekte Ne Anlama Geliyor (ve Her Bileşen Sizin İçin Ne Yapar)
3-2-1-1 kuralı, klasik çerçeveyi kritik bir eklemeyle genişletir. İşte her bileşenin nasıl ayrıldığını gösteriyor:
- Verilerinizin 3 kopyası: üretim verileriniz artı iki yedek. Toplamda iki kopya değil. Üç.
- 2 farklı depolama medya türü: örneğin, birincil yedeklemeniz için NVMe blok depolama ve ikincil için nesne depolama veya bant. Medya çeşitliliği, tek bir satıcı arızası veya format-spesifik bir hatanın her şeyi silmesini önler.
- 1 dışarıda kopya: birincil altyapınızdan coğrafi olarak ayrı bir konumda saklanır. Farklı bir ülkedeki bir bulut bölgesi uygundur. Aynı veri merkezindeki ikinci bir raf uygun değildir.
- 1 değiştirilemez, hava boşluklu kopya: bu yeni eklemedir ve aslında fidye yazılımını durduran budur. Bu kopya, ortamınızı ihlal etmiş herhangi bir süreç, kullanıcı veya saldırgan tarafından değiştirilemez, silinemez veya şifrelenemez. Patlama yarıçapının dışında durur.
Son "1", modern bir yedekleme mimarisini, kağıt üzerinde iyi görünen ancak saldırı altında başarısız olan bir mimariden ayıran şeydir. Değiştirilemezlik, yazıldıktan sonra hiçbir API çağrısının, yönetici kimlik bilgisinin ve fidye yazılımı yükünün verileri değiştiremeyeceği veya silemeyeceği yaz-bir-kez, oku-çok (WORM) depolama anlamına gelir. Hava boşluğu, kopyanın birincil ortamınıza kalıcı bir ağ bağlantısının olmaması anlamına gelir.
Bu iki özellik birlikte, bir saldırgan bulut hesabınızı, üretim sunucularınızı, yedekleme ajanlarınızı ve dışarıda replikayı tamamen ihlal etse bile, dokunamayacakları bir kopya olduğunu garanti eder.
Fidye Yazılımı Anatomisi: Saldırganlar Yedekleme Ortamlarını Nasıl Hedef Alır
Savunma tasarlamadan önce saldırı modelini anlamak gerekir. İşletmeleri hedef alan fidye yazılımı operatörleri, ilk gün patlamazlar. Tipik bir kurumsal fidye yazılımı ihlali, öngörülebilir bir sırayı takip eder.
İlk olarak, başlangıç erişimi. Bu genellikle oltalama, açık RDP veya halka açık bir uygulamadaki bir güvenlik açığı yoluyla gelir. İçeri girdikten sonra, saldırgan sessizce ayrıcalıkları yükselterek yanlara doğru hareket eder. Bu bekleme süresi, şifreleme başlamadan önce haftalar ila aylar arasında değişir.
Bu bekleme süresi boyunca, saldırganlar özellikle yedekleme altyapısını ararlar. Sunucularda çalışan yedekleme ajanlarını tanımlarlar, bağlı depolama hacimlerini haritalarlar, ortam değişkenlerinde veya yapılandırma dosyalarında bulut depolama kimlik bilgilerini bulurlar ve anlık görüntü programlarını listelerler. Amaçları, yedekleri doğrudan silmek, üretim verileriyle birlikte şifrelemek veya hemen belli olmayan bir şekilde bozmak.
Bazı fidye yazılımı varyantları, özellikle yedekleme yazılımı API'lerini hedef alır. Diğerleri, tüm geri yükleme noktalarının şifrelenmiş veriler içerdiği yeterli yedekleme döngüsünün geçmesini bekler. 30 günlük bir saklama penceresi cömert gelebilir, ancak saldırganın içeride 45 gündür olduğunu fark ettiğinizde durum farklıdır.
Bu yüzden mimari önemlidir. Ağ erişimi olan yedekler, okuma-yazma kısıtlı olsa bile, kimlik bilgileri ihlal edilirse hala ulaşılabilir durumdadır. Yalnızca fiziksel veya mantıksal olarak ortamınızdan ayrılmış, uygulama katmanı yerine depolama katmanında değiştirilemez depolama özellikleri uygulanan bir kopya, bu saldırı modeline karşı güvenilir bir şekilde hayatta kalır.
Yedekleme ortamınızı sertleştirmek, yedekleme işleri yürüten sunucuları da sertleştirmek anlamına gelir. PlusClouds tarafından sağlanan Bulut Sunucularında iş yükleri çalıştırıyorsanız, tam kök erişimine sahipsiniz ve yedekleme ajanlarını özel örneklerde izole etme ve ağ erişimini sıkı bir şekilde sınırlama yeteneğine sahipsiniz, bu da yan hareket yüzeyini önemli ölçüde azaltır.
Her Yedek Kopya İçin Doğru Depolama Katmanını Seçmek (NVMe, SSD, HDD)
Her yedek kopyanın en hızlı depolama üzerinde olması gerekmez. Depolama katmanını kurtarma önceliğine göre eşleştirmek hem maliyet optimizasyonu hem de mimari bir karardır.
NVMe depolama, kurtarma senaryosunda ilk olarak başvuracağınız en yeni yedek kopyanız için uygundur. Hızlı geri yükleme süreleri, RTO'nuzu doğrudan azaltır. RTO hedefiniz dört saatin altındaysa, birincil yedeğinizi NVMe veya yüksek performanslı SSD üzerinde bulundurmanız gerekir. 150 MB/s hızında dönen diskten 2TB'ı geri yüklemek saatler alır. NVMe'den 3.000+ MB/s hızında geri yüklemek farklı bir konuşmadır.
SSD depolama, ikincil kopyanız için iyi çalışır, ayrı bir bulut bölgesinde veya dışarıda tutulan kopya. Birincil yedeklemenin kullanılamadığı senaryolar için makul kurtarma performansına karşı maliyeti dengeler.
HDD veya nesne depolama, değiştirilemez arşiv kopyanız için doğru katmandır. Bu kopya, son çarenizdir, ilk çağrınız değil. Ondan kurtarma daha uzun sürebilir, ancak bu kabul edilebilir çünkü her şey başarısız olduğunda ona başvurursunuz. Buradaki öncelik hız değil, dayanıklılık ve değiştirilemezliktir. WORM politikaları etkinleştirilmiş nesne depolama veya büyük bulut sağlayıcılarının sunduğu soğuk arşiv katmanları bu rol için uygundur.
PlusClouds tarafından sağlanan Bulut Depolama, tek bir kontrol düzleminden NVMe, SSD ve HDD dahil olmak üzere tüm üç katmanı kapsar. Bu pratik olarak önemlidir: 3-2-1-1 mimarinizi üç ayrı satıcı ilişkisini veya üç farklı API'yi yönetmeden yapılandırabilirsiniz.
Açık RPO ve RTO Hedefleri ile Otomatik Yedekleme Nasıl Yapılandırılır
RPO (Kurtarma Noktası Hedefi), ne kadar veri kaybına tolerans gösterebileceğinizi tanımlar, zamanla ölçülür. RPO'nuz dört saatse, en az dört saatte bir yedek alınması gerekir. RTO (Kurtarma Süresi Hedefi), bir arızadan sonra ne kadar hızlı çevrimiçi olmanız gerektiğini tanımlar. Bunlar, çoğu uyum çerçevesinde sözleşmeye dayalı taahhütlerdir.
RPO ve RTO hedeflerini belirlemek, iş etkisi hakkında dürüst bir konuşma gerektirir. Finansal işlemleri işleyen bir veritabanı, statik bir pazarlama web sitesinden çok farklı bir RPO'ya sahiptir. İş yüklerinizi sınıflandırarak başlayın:
- Tier 1 (kritik): RPO 1 saatten az, RTO 4 saatten az. Veritabanları, kimlik doğrulama hizmetleri, ödeme sistemleri.
- Tier 2 (önemli): RPO 4-8 saat, RTO 24 saatten az. Uygulama sunucuları, iç araçlar, CRM verileri.
- Tier 3 (standart): RPO 24 saat, RTO 48-72 saat. Geliştirme/test ortamları, arşivler, üretim dışı sistemler.
Katmanlarınızı belirledikten sonra, otomatik yedekleme programlarını buna göre yapılandırın. Bir Tier 1 iş yükü, en azından saatlik anlık görüntüler gerektirir ve veritabanınız destekliyorsa işlem günlüğü yedeklemeleri sürekli olarak çalışmalıdır. İşte bunu bir cron tabanlı yedekleme ajanı kullanarak nasıl programlayabileceğinize dair basit bir örnek:
# Tier 1: saatlik anlık görüntü, 72 saat saklanır
0 * * * * /usr/local/bin/backup-agent snapshot --target prod-db-01 --retention 72h
# 01:00'de günlük tam yedekleme, 30 gün saklanır
0 1 * * * /usr/local/bin/backup-agent full --target prod-db-01 --retention 30d
# Haftalık yedekleme değiştirilemez depolamaya, 1 yıl saklanır
0 2 * * 0 /usr/local/bin/backup-agent archive --target prod-db-01 --storage immutable --retention 365dBuradaki ana disiplin, RPO ve RTO hedeflerinin belgelenmesi, test edilmesi ve izlenmesidir. Otomasyon, programlamayı yönetir, ancak yedeklerin zamanında tamamlanıp tamamlanmadığını ve kurtarma testlerinin RTO'larını karşılayıp karşılamadığını gösteren SLA panolarına ihtiyacınız var. PlusClouds tarafından sağlanan Otomatik Yedekleme, açık RPO/RTO hedef yapılandırması ve SLA takibi içerir, böylece denetim izi sonradan eklenmek yerine baştan yerleşik olur.
Değiştirilemez Yedek Kopyalar: Hava Boşluklu ve WORM Depolama Fidye Yazılımı Şifrelemesini Nasıl Durdurur
Değiştirilemezlik, uygulama katmanında değil, depolama katmanında uygulanır. Bu ayrım kritiktir. Uygulama katmanı "salt okunur" bayrağı, yeterli izinlere sahip herhangi biri tarafından değiştirilebilir, bu da yönetici kimlik bilgilerini çalan bir saldırganı içerir. Depolama katmanında uygulanan değiştirilemezlik, WORM (Bir Kez Yaz, Çok Kez Oku) politikaları aracılığıyla, herhangi bir API çağrısı veya kimlik bilgisi tarafından değiştirilemez.
WORM depolama, nesneleri yazma anında tanımlı bir saklama süresi boyunca kilitleyerek çalışır. Bu süre zarfında, hiçbir işlem nesneyi değiştiremez veya silemez. Kilit, erişim kontrol politikaları tarafından değil, depolama sistemi tarafından uygulanır.
Hava boşluğu, bunu daha da ileri götürerek ağ yolunu tamamen kaldırır. Gerçek bir hava boşluğu, üretim ortamınız ile yedek kopya arasında kalıcı bir bağlantı olmadığı anlamına gelir. Bulut ortamlarında, bu genellikle şu yollarla uygulanır:
- Yönetim veya uyum modu ile nesne kilidi: AWS S3 Nesne Kilidi, Azure Değiştirilemez Blob Depolama ve eşdeğer hizmetler, WORM'u depolama API düzeyinde uygular.
- Periyodik çevrimdışı dışa aktarma: aktif bir montaj noktası olmadan soğuk depolamaya dışa aktarılan anlık görüntüler.
- Hiçbir çapraz hesap yazma izni olmayan ayrı bulut hesabı: yedek hesap, tek yönlü bir itme yoluyla veri alabilir, ancak üretim kimlik bilgileri yedek hesapta nesneleri silemez veya değiştiremez.
WORM politikası ve hesap izolasyonunun kombinasyonu, hava boşluğunun pratik bulut eşdeğeridir. Üretim bulut hesabınızı tamamen ihlal etmiş bir saldırgan, ayrı bir hesapta kimlik bilgilerine sahip olmadığı ve nesnelerin depolama katmanında kilitlendiği için yine de nesnelere ulaşamaz.
GDPR kapsamında hassas verileri işleyen ortamlar için, değiştirilemez depolama, silme hakkı etrafında dikkatli planlama gerektirir. Genellikle, değiştirilemez kopyalara karşı silme taleplerini ele almak için belgelenmiş bir sürece ihtiyacınız vardır; bu, genellikle yazıldıktan sonra silme yerine, içe alım sırasında takma ad kullanma yoluyla yapılır.
Kurtarma Testi ve Denetim Kanıtı: Planlı Tatbikatlardan Denetçi Hazır Raporlara
Hiç test edilmemiş bir yedekleme, bir yedekleme değildir. Bir hipotezdir. Kurtarma mimarinizin çalıştığını bilmenin tek yolu, ihtiyacınız olmadan önce, kasıtlı olarak kullanmaktır.
Kurtarma testi iki biçime sahiptir: geri yükleme testleri ve tam kurtarma tatbikatları. Geri yükleme testleri, bireysel dosyaların, veritabanlarının veya VM anlık görüntülerinin bilinen bir iyi duruma başarıyla geri yüklenip yüklenemeyeceğini doğrular. Tier 1 iş yükleri için en az ayda bir kez çalıştırılmalıdır. Tam kurtarma tatbikatları, bir ortamın tamamen başarısızlığını simüle eder ve gerçek RTO'yu hedefinize karşı ölçer. Bunlar üç ayda bir çalıştırılmalıdır.
Denetçi hazır kanıtlar için, her testin belgelenmiş bir kaydı olması gerekir:
- Testin tarihi ve saati
- Test edilen iş yükü ve kullanılan yedek kopya
- Kurtarma başlangıç ve bitiş zamanı (gerçek RTO)
- Veri bütünlüğü doğrulama yöntemi (checksum karşılaştırması, uygulama düzeyinde duman testi)
- Geçme/kalma sonucu ve alınan herhangi bir düzeltici eylem
- Sorumlu mühendisin imzası veya onayı
Otomatik kurtarma testi, planlanmış bir işin bir kurtarma ortamı oluşturduğu, bütünlük kontrolleri gerçekleştirdiği ve sonuçları insan müdahalesi olmadan kaydettiği altın standarttır. Bu, gerçek olaylarda kurtarma hatalarına neden olan "test etmeyi planladık ama sürekli öncelik kaybetti" sorununu ortadan kaldırır.
Bu kayıtları en az üç yıl saklayın. NIS2 ve DORA, kuruluşların yalnızca bir defalık mimari inceleme değil, sürekli kurtarma yeteneğini göstermesini gerektirir.
Uyum Haritalama: Yedekleme Mimarinizin Karşılaması Gereken NIS2, DORA, GDPR ve SOC 2 Gereksinimleri
Uyum çerçeveleri belirli yedekleme teknolojilerini öngörmez, ancak mimarinizin sağlaması gereken sonuçları zorunlu kılar. İşte 3-2-1-1 modelinin ana çerçevelere nasıl uyduğuna dair bir bakış:
NIS2 (AB Ağ ve Bilgi Güvenliği Direktifi 2): Temel ve önemli kuruluşların yedekleme yönetimi, iş sürekliliği önlemleri ve olay müdahale yetenekleri uygulamasını gerektirir. Madde 21, belgelenmiş kurtarma prosedürleri ile test edilmiş RTO/RPO hedeflerini özellikle çağırır. Değiştirilemez kopyanız ve otomatik kurtarma testiniz doğrudan bu gereksinimi karşılar.
DORA (Dijital Operasyonel Dayanıklılık Yasası): AB'deki finansal hizmetler kuruluşlarına uygulanır. Tanımlanmış kurtarma hedefleri, düzenli yedekleme ve kurtarma prosedürlerinin test edilmesi ve test sonuçlarının belgelenmesi ile BT iş sürekliliği politikaları gerektirir. DORA ayrıca üçüncü taraf BT sağlayıcılarının (bulut sağlayıcıları dahil) dayanıklılık standartlarını karşılamasını gerektirir, bu nedenle bulut yedekleme satıcınızın kendi uyum durumu önemlidir.
GDPR (Genel Veri Koruma Yönetmeliği): Veri kullanılabilirliği ve dayanıklılığını sağlamak için uygun teknik önlemler gerektirir. Madde 32, bir olaydan sonra kişisel verilerin kullanılabilirliğini zamanında geri yükleme yeteneğini zorunlu kılar. Tier 1 RTO hedefleriniz ve değiştirilemez kopyalarınız bunu doğrudan ele alır. Yukarıda belirtildiği gibi, karmaşıklık, Madde 17 kapsamındaki silme hakları ile değiştirilemezliği uzlaştırmaktır.
SOC 2 Tip II: Kullanılabilirlik güven hizmeti kriteri, belgelenmiş yedekleme prosedürleri, test kanıtları ve izleme gerektirir. Tip II sertifikasyonu, genellikle altı ila on iki ay arasında bir süre boyunca işletim etkinliğinin kanıtını gerektirir, bu nedenle otomatik test günlükleriniz ve SLA panolarınız isteğe bağlı ekstralar değildir. Onlar denetim eserleridir.
PlusClouds tarafından sağlanan Bulut Güvenliği teklifi, satıcı değerlendirme kısmını basitleştirir. Denetçinizin yalnızca yedekleme mimarinizi değil, aynı zamanda üzerinde çalıştığı altyapının uyum duruşunu da doğrulaması gerekir.
3-2-1-1 Bulut Yedekleme Yığını için Adım Adım Uygulama Kontrol Listesi
Bu kontrol listesini yedekleme mimarinizi oluşturmak veya denetlemek için kullanın. Her öğe, bu kılavuzda ele alınan bir bölüme karşılık gelir.
İş yüklerini sınıflandırın ve belgeleyin:
- Her üretim iş yükünü Tier 1, 2 veya 3'e atayın
- Her katman için yazılı olarak RPO ve RTO hedeflerini tanımlayın
- Bu hedefler üzerinde iş paydaşlarından onay alın
Üç kopyanızı yapılandırın:
- Üretimle birlikte hızlı geri yükleme için NVMe veya yüksek performanslı SSD üzerinde birincil yedekleme
- Ayrı bir bulut bölgesinde veya kullanılabilirlik bölgesinde SSD üzerinde ikincil yedekleme
- Ayrı bir bulut hesabında WORM etkin nesne depolama üzerinde değiştirilemez arşiv kopyası
Değiştirilemezliği uygulayın:
- Arşiv depolamanızda nesne kilidini (uyum modu, yönetim modu değil) etkinleştirin
- Üretim kimlik bilgilerinin arşiv hesabında silme veya değiştirme izinlerine sahip olmadığını doğrulayın
- Uyumluluk gereksinimlerinize uygun minimum saklama sürelerini ayarlayın (genellikle 1-7 yıl)
Yedekleme işlerini otomatikleştirin:
- Her katman için RPO hedeflerinize uygun frekanslarda yedeklemeleri planlayın
- Kaçırılan veya başarısız olan yedekleme işleri için uyarı yapılandırın
- Program karşısında yedekleme tamamlanmasını ölçmek için SLA takibini etkinleştirin
Yedekleme ortamını sertleştirin:
- Gereksiz gelen ağ erişimi olmayan izole edilmiş örneklerde yedekleme ajanlarını çalıştırın
- Yedekleme kimlik bilgilerini bir program dahilinde döndürün ve bir gizli yöneticiye saklayın
- Yedekleme altyapısına erişimi olan tüm hesaplarda çok faktörlü kimlik doğrulamasını etkinleştirin
Kurtarma test edin ve belgeleyin:
- Tier 1 iş yükleri için aylık geri yükleme testleri yapın
- Ölçülen RTO ile üç ayda bir tam kurtarma tatbikatları yapın
- Test kayıtlarını zaman damgaları, sonuçlar ve mühendis onayı ile en az üç yıl saklayın
Uyum gereksinimlerine haritalayın:
- Bilgi güvenliği politikanızda yedekleme mimarinizi belgeleyin
- Her yedekleme bileşenini ilgili NIS2, DORA, GDPR veya SOC 2 kontrolüne haritalayın
- Yıllık denetim paketinizde yedekleme testi kanıtlarını dahil edin
Bu kontrol listesinde açıklanan mimari teorik değildir. 2025 ve 2026'da fidye yazılımı saldırılarından başarıyla kurtulan kuruluşların ortak noktası olan modeldir, kurumsal yedekleme dayanıklılığı araştırması sürekli olarak doğrular.
Fidye Yazılımı Dayanıklılığı Oluşturmak Bir Mimari Karardır, Ürün Kararı Değil
3-2-1-1 kuralı bir çerçevedir, bir ürün değil. Tek bir araç, yedeklerinizi otomatik olarak fidye yazılımına karşı dayanıklı yapmaz. Onları dayanıklı kılan, kurtarma önceliğine göre eşleştirilmiş katmanlı depolama, depolama katmanında uygulanan değiştirilemezlik, yedekleme programından insan hatasını kaldıran otomasyon ve sistemi ihtiyacınız olmadan önce çalıştığını kanıtlayan düzenli testlerdir.
Uyum açısı, mimariyi güçlendirir. NIS2 ve DORA, kuruluşlara yedekleme testini düşük öncelikli bir görev olarak ele alma seçeneği vermez. Belgelenmiş, test edilmiş ve denetlenebilir kurtarma yetenekleri artık Avrupa işletmelerinin önemli bir kısmı için yasal bir gerekliliktir ve bu gereklilik uygulanmaktadır.
3-2-1 duruşundan gerçekten fidye yazılımına dayanıklı bir 3-2-1-1 mimarisine geçmeye hazırsanız, PlusClouds tarafından sağlanan Otomatik Yedekleme, RPO/RTO yapılandırması, SLA takibi ve uzaktan geri yükleme yetenekleri sunarak, araçları sıfırdan inşa etmeden oraya ulaşmanızı sağlar. Bunu PlusClouds tarafından sağlanan Bulut Depolama ile tek bir kontrol düzleminde katmanlı NVMe, SSD ve HDD depolama için eşleştirin ve 3-2-1-1 yığınızdaki altyapı katmanını kapsarsınız. Mimari kararlar size aittir. Onları destekleyecek altyapı, hazır olduğunuzda hazırdır.
