Ransomware’a dayanıklı bir hosting yedekleme stratejisinde 3‑2‑1 kuralı tek başına yeterli mi?

3-2-1; üretim dahil üç kopya, iki farklı depolama ortamı ve farklı fiziksel konumda bir kopya hedefler. Dosya biçimi veya ayrı dataset tek başına ortam ayrımı sağlamaz. Kural, hesapların ve saklama politikalarının bağımsızlığını kendiliğinden kurmaz. Üretimde ele geçirilebilecek yetkileri sınırlayın; korunan geçmiş, çevrimdışı veya bağımsız yönetilen kopyalar ve kullanılabilir anahtarlar planlayın. Seçilen tasarımın yeterliliğini gerçek geri yükleme ile sınayın; hiçbir tek katman temiz kopya garantisi değildir.

Immutable backup ile air‑gap arasında ne fark var, hangisine öncelik vermeliyim?

Değiştirilemezlik, belirli koşullarda korunan kopyayı değiştirme ve silmeyi sınırlar; yöneticiye karşı koruma ürün ve moda bağlıdır. Fiziksel air-gap, kopyanın ağ bağlantısını gerçekten keser. Mantıksal yalıtım bağlı sistemlerde yetki ve erişimi kısıtlar; fiziksel kopukluk değildir. Önceliği mevcut erişim yolları, RPO/RTO ve operasyon kapasitesine göre belirleyin. Kilitli uzak geçmiş ile daha seyrek çevrimdışı kuşak birlikte kullanılabilir; haftalık veya aylık aralıkların kabul edilen veri kaybını karşıladığını ayrıca kontrol edin.

DCHost üzerindeki web sitem için ransomware’a dayanıklı yedekleme mimarisini pratikte nasıl kurabilirim?

Önce hizmetinizin tamamlanmış dosya, veritabanı ve hesap ayarı dışa aktarımlarını ve geri yükleme yetkilerini doğrulayın. Bağımsız yedek işçisi tamamlanmış çıktıları toplasın; çalışan restic/Borg deposunu, bütün bağımlılıkları korunan kilitli arşiv katmanından ayırın. Versioning, Object Lock ve sabit varsayılan saklamayı yüklemeden önce hazırlayın; gerçek sürüm kimliği ve retention bilgisini denetleyin. İstemci tarafında şifrelenmiş kuşaklar ve ayrı anahtar kopyaları kullanın. Firewall ile ayrılmış çevrimiçi VPS mantıksal yalıtımdır; fiziksel air-gap için kopyayı gerçekten bağlantıdan ayırın. Tasarım, hizmetinizde doğrulanması gereken bir örnektir.

Yedeklerimi şifrelemeli miyim, şifreleme ransomware’e karşı ekstra koruma sağlar mı?

Şifreleme, anahtarlar korunduğu sürece yedek içeriğinin yetkisiz okunmasını sınırlayabilir; silinmeyi veya yeni bozuk yedek yazılmasını önlemez. rclone aktarımı kendiliğinden istemci şifrelemesi değildir; crypt veya önceden şifreli arşiv gerekir. Anahtarları, parolaları ve gerekli yapılandırmayı üretimden bağımsız kurtarma kopyalarında tutun. Object Lock anahtar kaybını engellemez; kaybolan ya da silinen anahtar kilitli veriyi okunamaz bırakabilir. Şifreleme ve kilit tek başına KVKK/GDPR uyumu kanıtlamaz.

Ransomware senaryosu için geri dönüş testini ne sıklıkla yapmalıyım ve nelere dikkat etmeliyim?

İlk kurulumda, önemli değişikliklerden sonra ve risk ile kurtarma hedeflerine göre düzenli test yapın. Aylık dar kapsamlı ve üç aylık tam test bir başlangıç örneğidir, evrensel güvenlik standardı değildir. Temiz ve izole ortamda uygun tarihli kuşağı; dosyaları, veritabanını, ayarları, rolleri ve anahtarlarıyla geri yükleyin. Gerçek ödeme, müşteri e-postası, webhook ve üretim işlerini engelleyin; kritik akışları sandbox ortamında iş birimleriyle doğrulayın. İndirme, şifre çözme, prepare ve uygulama kontrolü dahil toplam süreyi ölçüp runbook’a kaydedin.

Fidye Yazılımına Dayanıklı Yedekleme Stratejisi

Bir sunucunun yedekleme stratejisini değerlendirirken temel soru şu: “Ransomware senaryosunda, gerçekten geri dönebileceğiniz, dokunulmamış kaç kopyanız var?” Çoğu zaman alınan günlük yedekler, aynı sunucuda tutulan snapshot’lar veya tek bir uzak depolama alanı, ilk bakışta güven verici görünüyor. Ancak fidye yazılımı saldırılarında yedekler ve depolama kimlik bilgileri de hedef alınabilir; saldırganın değiştirme veya silme yetkisi kazandığı kopyalar risk altındadır.

Bu rehber, fidye yazılımına dayanıklı yedekleme stratejisini 3‑2‑1 kuralı, değiştirilemez kopyalar ve ağdan ayrılmış kurtarma kopyalarıyla ele alır. Paylaşımlı hosting, VPS ve dedicated sunucu için varsayımsal tasarımlar kullanıyoruz. Paylaşımlı hostingte panelin sunduğu dışa aktarma ve geri yükleme yetkileri, VPS’te ise işletim ve depolama sorumlulukları ayrıca doğrulanmalıdır. Amaç saldırganın denetimi dışında kullanılabilir bir kurtarma noktası tutmaktır; hiçbir tek özellik temiz ve başarılı geri dönüşü garanti etmez.

Ransomware Tehdidi Neden Yedek Stratejisini Baştan Yazdırdı?

Bir saldırgan yalnız üretim dosyalarını şifrelemeye çalışmayabilir; yönetici hesaplarını, yedekleme kimliklerini ve saklama politikalarını da hedefleyebilir. Yedeğin değeri, aynı olayda hangi hesapların onu okuyabildiğine, değiştirebildiğine veya silebildiğine bağlıdır. Yedekleme tasarımı bu erişim yollarını ve ortak arıza noktalarını birlikte incelemelidir.

Dikkate alınması gereken bazı saldırı ve arıza senaryoları:

cPanel veya panel dışı cron ile alınan yedeklerin, aynı sunucudaki başka bir dizinde tutulması ve ransomware tarafından beraberce şifrelenmesi.
VPS/dedicated sunucuların snapshot’larının, aynı hypervisor veya aynı depo havuzunda tutulup topluca erişilemez hale gelmesi.
Yedekler için kullanılan, sürümleri silme yetkisine sahip S3 uyumlu depolama erişim anahtarlarının (access key/secret) ele geçirilip, silmeye karşı korunmayan yedek versiyonlarının saldırgan tarafından silinmesi.

Bu tablo bize iki kritik dersi hatırlatıyor:

Tek bir yedek kopya yeterli dayanıklılık sağlamaz. Üretim verisi tek başına yedek değildir; yedek kopyalar da ortak arıza veya saldırı noktalarından ayrılmalıdır.
Erişim yetkisinin kapsamı belirleyicidir. Ağdan erişilebilirlik tek başına silme veya şifreleme yetkisi anlamına gelmez; yedekler, üretimde ele geçirilebilecek hesaplardan bağımsız koruma katmanlarına ihtiyaç duyar.

Yedek mimarisi, “disk arızası” kadar “yetkisi genişlemiş saldırgan” senaryosunu da kapsamalıdır. İşte burada 3‑2‑1 kuralı, immutable backup ve air‑gap yaklaşımı devreye giriyor.

3‑2‑1 Yedekleme Kuralı: Ransomware Direncinin Temeli

3‑2‑1, kopyaları ve depolama ayrımını planlamak için bir başlangıç kuralıdır:

3 kopya: Üretim verisi ve iki geri yüklenebilir yedek.
2 farklı ortam: Örneğin disk ve tape. Disk/bulut tasarımında gerçek depolama ortamlarını ve bağımsız fiziksel arıza sınırlarını ayrıca belgeleyin; başka dosya formatı veya dataset ikinci ortam değildir.
1 uzak kopya: Farklı fiziksel konum, örneğin başka veri merkezi. Yalnızca mantıksal veya hesap ayrımı yeterli değildir.

Bu yaklaşımı hosting dünyasına uyarladığımızda, pratik bir örnek şöyle görünebilir:

Üretim: Web sitesi, veritabanı ve yüklenen dosyaların çalışan kopyası.
Yakın yedek: Hızlı geri dönüş için ayrı fiziksel depolamada tamamlanmış panel veya uygulama yedeği. Aynı host ya da yönetim hesabı kullanılıyorsa ortak risk sürer.
Uzak yedek: Farklı fiziksel konum ve bağımsız yönetim kimlikleriyle saklanan, şifreli ve geri yüklenebilir kopya.

Aynı diskte başka bölüm, aynı havuzda başka dataset veya farklı dosya uzantısı ayrı bir fiziksel arıza alanı oluşturmaz. Object storage bir erişim modelidir; altında hangi ortamın ve arıza sınırlarının bulunduğunu ayrıca doğrulayın.

Panel ve VPS otomasyonu için 3‑2‑1 yedekleme stratejisi rehberimize bakabilirsiniz. Buradaki ek konu, kopyaları yetkisi genişlemiş saldırgana karşı korumak ve gerçekten geri yüklenebildiklerini sınamaktır.

3‑2‑1 Kuralını Ransomware’e Karşı Güçlendirmek

Temel 3‑2‑1 çoğu donanım arızası ve insan hatası senaryosunda işe yarar. Ancak ransomware için birkaç ek şart gerekiyor:

Kimlik ayrımı: Üretim hesabı, geçmiş kopyaları silen veya korumayı kaldıran yönetim yetkilerini taşımamalıdır. Aracın gerekli okuma, listeleme, yazma ve bakım işlemlerini belgeleyerek en az yetki verin.
Sürümleme: Eski nesne sürümleri üzerine yazma sonrası kurtarma sağlayabilir; sürümü silme yetkisi olan hesaba karşı tek başına koruma değildir.
Korunan geçmiş: Saklama kilidi, bağımsız hesap ve çevrimdışı kopya seçeneklerini birlikte değerlendirin. Saklama süresi, olayın geç fark edilme olasılığını da kapsamalıdır.

Bu gereksinimler bizi bir sonraki adıma, yani immutable backup kavramına götürüyor.

Immutable Backup Nedir, Ransomware’e Karşı Neden Kritik?

Değiştirilemez (immutable) yedek, korunan kopyanın belirlenen şartlarda değiştirilmesini veya silinmesini engelleyen saklama mekanizmasıdır. Yönetici yetkisine karşı koruma, ürüne ve kilit moduna bağlıdır. Kilitli bir kopya bozuk veya saldırıdan etkilenmiş veri içerebilir; değiştirilemezlik, yedeğin temiz olduğunu kanıtlamaz.

Bunu, belgenin okunabildiği ancak belirlenen süre boyunca değiştirilmesinin veya yok edilmesinin engellendiği bir arşiv gibi düşünün. Kilit, yedeği okumayı ya da geri yüklemeyi değil, korunan kopyayı değiştirmeyi ve silmeyi sınırlar.

S3 Object Lock ve WORM Mantığı

S3 Object Lock, nesne sürümleri için WORM koruması sağlayan bir örnektir. Aşağıdaki mod açıklamaları Amazon S3’ün sabit saklama süresi davranışına dayanır; “S3 uyumlu” etiketi başka sağlayıcıda aynı yetki, kilit ve kurtarma özelliklerini kanıtlamaz. Ayrıntı için S3 Object Lock ve sürümleme rehberimizi okuyabilirsiniz.

Amazon S3’te birbirinden ayrılması gereken üç koruma vardır:

Koruma	Sağladığı sınır	Yönetim koşulu
Governance	Özel aşma yetkisi olmayan kullanıcılar korunan sürümü silemez veya saklamayı kısaltamaz.	Aşma için `s3:BypassGovernanceRetention` ve açık bypass isteği gerekir. Bu yetki yedek yükleyen hesapta bulunmamalıdır.
Compliance	AWS hesabının root kullanıcısı dahil kullanıcılar kilit süresini kısaltamaz, modu değiştiremez veya sürümü silemez.	Gerçek veride uygulanmadan önce süre ve maliyet doğrulanmalıdır. Hesabın yaşam döngüsü ve şifreleme anahtarları ayrıca korunur.
Legal hold	Sabit bitiş tarihi olmadan sürümü korur; saklama süresinden bağımsızdır.	`s3:PutObjectLegalHold` yetkisi olan kullanıcı kaldırabilir; otomatik olarak aşılamaz süre kilidi değildir.

Önce hedefi hazırlayın: Ayrı hesap veya yönetim sınırındaki bucket için versioning ve Object Lock’u açın; seçilen sabit varsayılan saklama süresini yedek yüklemeden önce tanımlayın. AWS’de Object Lock açıldıktan sonra kapatılamaz ve versioning askıya alınamaz.
Yetkileri sınayın: Yükleyen hesap bucket kilit ayarını değiştiremesin, governance korumasını aşamasın ve legal hold kaldıramasın. Nesneye özel retention ayarı bucket varsayılanını geçersiz kılabildiğinden, izin verilen süreleri politika ile sınırlandırın.
Test verisi kullanın: Seçilen araç ve hesapla yükleyin; nesnenin gerçek version ID, mod ve retain-until-date bilgisini okuyun. Bucket ayarının açık görünmesi tek başına yeterli değildir.
Eski sürümleri ayrı inceleyin: Yeni varsayılan süreyi açmanın daha önce yazılmış her sürümü koruduğunu varsaymayın; gerekli eski version ID’lerine uygun retention uygulayın ve sonucu doğrulayın.
Koruma ve kurtarmayı birlikte deneyin: Günlük arşiv yükleyicisinin sınırlı kimliğiyle korunan test sürümünü silme ve süreyi kısaltma girişiminin reddedildiğini, yetkili kurtarma hesabıyla aynı sürümün okunabildiğini sınayın. Governance testi ile compliance davranışını birbirine karıştırmayın.

Kilit, korunan nesne sürümüne uygulanır. Aynı adla yeni bozuk bir sürüm yazılabilir; sürüm belirtilmeden yapılan silme isteği eski kilitli veriyi silmeden bir delete marker oluşturabilir. Geri yükleme prosedürü bu yüzden doğru version ID’yi bulmayı da kapsamalıdır. Yetkili saldırgan yeni yedekleri bozabilir, depolama tüketimini artırabilir veya erişebildiği şifreleme anahtarlarını çalabilir. Object Lock anahtar kaybını önlemez; örneğin KMS anahtarı silinirse kilitli veri okunamaz hale gelebilir.

Immutable Yedekleri Hosting İş Yüklerine Nasıl Uygularız?

VPS veya dedicated sunucuda çalışan varsayımsal bir iş yükünü ele alalım:

Web sitesi: WordPress, Laravel veya özel PHP uygulaması.
Veritabanı: MySQL/MariaDB veya PostgreSQL.
Sunucu tipi: Yönetilen veya yönetilmeyen VPS / dedicated.

Bu rehberin seçtiği akış, çalışan yedek deposu ile uzun süre kilitlenen arşiv katmanını ayırır. Böylece araçların günlük bakım gereksinimleri, arşivin saklama kilidiyle karıştırılmaz:

Tutarlı kaynak oluşturun: Veritabanına uygun tamamlanmış dışa aktarımı, aynı kurtarma noktasına ait uygulama dosyaları ve yapılandırmayla eşleştirin. MySQL’de transactional dump yalnız uygun InnoDB koşullarında tutarlıdır; eşzamanlı DDL ve transactional olmayan tablolar ayrıca ele alınır. PostgreSQL pg_dump tek veritabanı içindir; roller gibi küresel nesneler ayrıca korunur.
Snapshot kapsamını doğrulayın: LVM/ZFS snapshot veya fsfreeze tek başına uygulama işlemlerini koordine etmez. PostgreSQL dosya snapshot’ı bütün gerekli veri/WAL alanlarını ve eşzamanlı disk görüntülerini gerektirir. Ayrıntı için uygulama tutarlılığı ve snapshot rehberimizi kullanın.
Bağımsız yedek işçisi: Sınırlı erişimle tamamlanmış çıktıları toplasın. Restic veya Borg kullanılıyorsa kendi desteklenen deposuna yazsın; depo denetimleri ve temizleme işlemleri ayrı, güvenilir yönetim akışında çalışsın.
Tamamlanmış arşiv kuşağı: Kilitli katmana bağımsız geri yüklenebilir dosya seti veya tutarlı tam depo kopyası aktarın. Restic snapshot kaydını tek başına kopyalamak yetmez; ilgili index ve pack dosyaları, pack içindeki bütün tree/veri blobları, depo yapılandırması ve gerekli anahtar dosyaları da korunmalıdır. Aktif bir depoyu sıradan sync ile kopyalamak yerine yazmaları durduran veya aracın desteklediği tutarlı kopyalama yöntemini kullanın.
Şifreleme ve kabul: Her kuşağı benzersiz adla, önceden ayarlanmış kilitli hedefe gönderin. İstemci tarafı şifreleme ve anahtarların bağımsız kurtarma kopyası hazır olsun. Tamamlanma, veri bütünlüğü, retention metadatası ve izole geri yükleme kontrolü geçmeden kuşağı başarılı saymayın.

Restic ve Borg ile uzak yedekleme rehberimiz araç seçimini ayrıntılandırır. Bu araçlar aynı erişim ve saklama davranışına sahip değildir:

Araç	Depo veya aktarım	Kilitli arşivle ilişki
Restic	Yerel, SFTP/REST ve S3 gibi backend’lerde kendi şifreli depo yapısını kullanır.	Listeleme/okuma, depo kilitleri ve forget/prune bakımı gerekir. Etkin deponun tüm nesnelerine varsayılan Object Lock koymayı desteklenmiş bir kurulum saymayın; sürüm ve backend ile baştan sona test edin.
Borg 1.4.x	Yerel veya SSH üzerinden Borg deposu; burada doğrudan S3 backend’i olarak kullanılmaz.	Append-only erişim ayrı sunucudaki segmentleri korumaya yardım eder; root dosya erişimi ve güvenilir bakım işlemleri ayrı sınırdır. S3 arşivi gerekiyorsa tutarlı, eksiksiz kopya veya dışa aktarım ayrıca hazırlanır.
rclone	Dosyaları backend’ler arasında aktarır; tek başına veritabanı-tutarlı yedek üretmez.	Copy hedefte yalnız bulunan dosyaları silmez; aynı isimde değişiklik yine aktarılabilir. Sync hedefi kaynağa uydururken silme yapabilir. İstemci şifrelemesi için crypt veya önceden şifrelenmiş arşiv gerekir.

Fiziksel Air-Gap ve Mantıksal Yalıtım

Fiziksel air-gap, kurtarma kopyasının etkin ağ bağlantısını kaldırır. Mantıksal yalıtım ise bağlı sistemlerde kimlik, ağ ve yönetim kısıtları uygular. İkisi farklı erişim sınırlarıdır; “normal ağdan erişilemiyor” demek tek başına fiziksel kopukluk değildir.

Fiziksel air‑gap, ağ bağlantısı olmayan ortamlarla sağlanır (örneğin çevrimdışı tape kasetler veya bağlantısı kesilmiş harici diskler). Erişimin yalnızca belirli bakım aralıklarında kısıtlı bir ağ tüneliyle açılması ise mantıksal yalıtımdır; fiziksel kopuklukla eşdeğer değildir. Bağlantı penceresi açıkken erişim riski sürer; ağ kurallarını yöneten hesapların da üretim hesaplarından ayrılması gerekir.

Hosting İçin Mantıksal Yalıtım Tasarımları

Hosting tarafında değerlendirilebilecek mantıksal yalıtım tasarımlarından bazıları:

Ayrı yedek sunucusu: Üretimden farklı yönetim kimlikleri ve mümkünse farklı fiziksel konum kullanır. Depo yönetimi, üretimdeki panel veya SSH hesabının yetkisinde olmamalıdır.
Kontrollü çekme: Yedek işçisi üretimden tamamlanmış çıktıları çekebilir; üretim sunucusu yedek yönetim ağına yeni bağlantı başlatamaz. Bununla birlikte işçi, üretimden gelen dosya ve yanıtları güvenilmeyen girdi olarak işler.
Kısa erişim penceresi: Gereken kaynak erişimi yalnız planlı zamanda açılıp kapatılabilir. Bu fiziksel kopukluk değildir; açık pencere, kuralı değiştirebilen yönetici ve ortak kimlik sağlayıcısı riskleri sürer.
Ayrı yönetim: Yedek yöneticileri, MFA, ağ kuralları ve kurtarma anahtarları üretim otomasyonundan ayrılır. Kısıtları üretim hesabının gerçek yetkileriyle sınayın.

Fiziksel çevrimdışı katman için tamamlanmış ve şifrelenmiş arşivler çıkarılabilir diske veya tape’e kopyalanıp doğrulanabilir; ardından ortam gerçekten bağlantıdan ayrılır. Farklı fiziksel konumda saklama, aynı binadaki afet riskini de azaltır. Çevrimdışı olmak tek başına WORM değildir: yeniden bağlandığında yazılabilir bir ortam değiştirilebilir. Ortam, anahtar, saklama koşulu ve tekrar okuma testi birlikte yönetilir.

Air‑Gap ile Immutable Backup’ı Birleştirmek

Farklı kurtarma ihtiyaçları için bu katmanlar birlikte kullanılabilir:

Hızlı geri dönüş: Yakın snapshot veya ayrı depoda tamamlanmış yedek; aynı host ve yönetim hesabına bağımlılık açıkça kaydedilir.
Korunan uzak geçmiş: Farklı fiziksel konumda, bağımsız yönetimle, doğrulanmış Object Lock veya uygun WORM davranışı.
Çevrimdışı arşiv: İş ihtiyacına göre dönemsel tam kurtarma kopyası; ağ bağlantısı kesilir ve anahtarlarla birlikte kurtarılabilirliği sınanır.

Bu ayrım tüm kopyaların aynı olayda kaybedilme riskini azaltır. Son kopyanın gerçekten bağımsız olması; ortak yönetici hesabı, bulut hesap kurtarma yolu, şifreleme anahtarı ve erişim pencereleri üzerinden tekrar denetlenmelidir. Kilitli veya çevrimdışı olması, kopyanın saldırı öncesine ait ve temiz olduğunu tek başına göstermez.

Hosting İçin Üç Katmanlı Örnek Yedekleme Mimarisi

Aşağıdaki varsayımsal e‑ticaret veya SaaS tasarımını veri boyutu, panel yetkileri ve işletim sorumluluklarına göre uyarlayın. Kurulumdan önce üretim, yedek işçisi, arşiv hesabı ve kurtarma operatörü arasındaki veri ve yetki akışını çizin. Paylaşımlı hostingte sağlayıcıdan hangi dosyaların, veritabanlarının ve hesap ayarlarının dışa aktarılıp geri yüklenebildiğini doğrulayın.

1. Katman: Uygulama-Tutarlı Yedekler

Önce üretim sunucunuzda, uygulama açısından tutarlı yedek almayı hedefleyin:

Veritabanı: RPO’ya uygun sıklıkta mantıksal yedek veya desteklenen fiziksel yedek alın. MySQL 8.4 için uygun XtraBackup 8.4 akışı, MariaDB için sürümle uyumlu mariadb-backup, PostgreSQL için kendi desteklenen dump/base-backup akışı seçilir. Fiziksel yedeğin gerekli prepare/redo adımını atlamayın.
Uygulama: Kod, yüklenen dosyalar, yapılandırma, gerekli sürüm bilgileri ve bağımlılıkları aynı kurtarma noktasıyla eşleştirin. Veritabanı kaydı ile dosya yüklemesi arasındaki ilişki için uygulama düzeyinde koordinasyon gerekir.
Otomasyon: Cron veya systemd timer çıkış kodunu, eksik dosyaları ve son başarılı kuşağın yaşını izlesin. Kısmi başarının tam yedek olarak işaretlenmesini önleyin.

Yerel katmanı ayrı fiziksel depolamada tutmak disk arızası ayrımı sağlar; aynı diskte başka partition bu korumayı sağlamaz. Ayrı disk de host root erişimine veya ortak depolama yönetimine karşı yeterli sınır değildir. Bu katmanın amacı hızlı geri dönüş; bağımsız uzak ve çevrimdışı kopyalar ayrıca gerekir.

2. Katman: S3 Uyumlu Immutable Uzak Yedekler

İkinci katmanda, üretim sunucusundan bağımsız bir S3 uyumlu object storage kullanın:

Bağımsız yönetilen uzak hedefi, gerçek fiziksel konumunu ve S3 uygulamasının Object Lock davranışını doğrulayın.
Yukarıdaki sırayla versioning, kilit modu, sabit varsayılan süre ve yükleyen hesabın sınırlarını önceden hazırlayın.
Yedek işçisi tamamlanmış, şifreli ve bağımsız geri yüklenebilir arşiv kuşaklarını benzersiz adlarla aktarsın; çalışan restic/Borg deposunu körlemesine Object Lock bucket’ına eşitlemesin.
Şifreleme parolası/anahtarı, gerekli crypt yapılandırması ve kurtarma metadata’sı için üretimden bağımsız, erişimi denetlenen kopya tutun.
Her kabul edilen kuşak için dosya bütünlüğü, nesne sürümü ve retention bitişi kaydedilsin. Eski kuşakların dayandığı veri parçaları, o kuşakların kurtarma süresi bitmeden temizlenmesin.

“Yalnız put/list, hiçbir okuma veya silme yok” bütün araçlar için geçerli bir IAM tarifi değildir. Aktarım aracı hedefi okumak/listelemek isteyebilir; yedek deposu kilit ve bakım işlemleri yürütür. Gerçek sürüm ve backend’de gerekli işlemleri gözlemleyerek izinleri daraltın; arşiv silme, kilit aşma ve politika yönetimini günlük yükleyiciden ayırın. MFA ile korunan yönetici konsolu, çalınmış otomasyon anahtarını kendiliğinden etkisizleştirmez. Object storage’a otomatik yedekleme ve Restic/Borg uzak depo rehberleri bu ayrımların teknik devamıdır.

3. Katman: Air‑Gap Arşiv Yedekler

Çevrimdışı kuşağın sıklığını RPO, değişim hızı ve fiziksel operasyon kapasitesine göre belirleyin. Haftalık veya aylık arşivler birer örnektir; daha kısa kayıp hedefini tek başına karşılamaz:

Yedek işçisi, tamamlanmış ve doğrulanmış arşiv kuşağını planlı zamanda hazırlasın.
Ayrı çevrimdışı ortama kopyalayıp tekrar okuyun; şifre çözme ve dosya bütünlüğünü doğrulayın.
Ortamı güvenli biçimde ayırıp fiziksel bağlantıyı kesin; yalnız firewall kapatılmış sürekli bağlı VPS’i fiziksel air‑gap saymayın.
Konum, kuşak tarihi, saklama bitişi ve anahtar erişim sorumlusunu envanterde tutun. Eski temiz kuşağı, yeni kopyanın başarısı doğrulanmadan kaldırmayın.

Ayrı ve bağlantısız kopya, üretim üzerinden doğrudan erişim riskini azaltır. Ancak kopyalama anında bozuk veri taşınması, saklama ortamının zarar görmesi veya kurtarma anahtarının bulunamaması hâlâ mümkündür. Bu katman da düzenli okuma ve gerçek geri yükleme denemesinden geçmelidir.

RPO, RTO ve Geri Dönüş Testleri: Gerçekçi Hedefler Koymak

Hiçbir yedek stratejisi, geri dönüş (restore) test edilmeden tamamlanmış sayılmaz. Ransomware senaryosunda asıl önemli olan, yalnızca “yedek var mı?” sorusu değil; aynı zamanda şu iki sorunun cevabıdır:

RPO (Recovery Point Objective): En fazla ne kadar veri kaybını kabul edebilirim? 1 saat, 4 saat, 24 saat?
RTO (Recovery Time Objective): Sistemlerimi ne kadar sürede tekrar ayağa kaldırmam gerekiyor? 1 saat, 4 saat, 1 gün?

Bu iki hedefi netleştirmeden yedek stratejisi tasarlamak, mimari tasarım sürecinde boş bir kutu bırakmaktır. RPO/RTO kavramlarını detaylıca anlattığımız yedekleme stratejisi ve RPO/RTO rehberimiz bu noktada işin stratejik tarafını tamamlar.

Geri Dönüş Provaları ve Runbook

Yedeğin varlığı kadar, üretim sistemi kullanılamazken başka bir ortamda nasıl geri yükleneceği de bilinmelidir. Prova sıklığını kritik değişiklikler ve risk düzeyiyle belirleyin; örneğin aylık küçük kapsamlı ve üç aylık tam tatbikat bir başlangıç programı olabilir, evrensel yeterlilik kuralı değildir.

Temiz kurtarma ortamı: Yedeği üretimden ayrılmış sunucuya yükleyin; e‑posta, ödeme, webhook ve zamanlanmış işlerin gerçek müşterilere işlem göndermesini önleyin.
Doğru tarih ve sürüm: Son yedeği otomatik seçmeyin; şüpheli erişim başlangıcı, kayıtlar ve veri kontrolleriyle temiz aday belirleyin. S3’te gerektiğinde eski version ID’ye erişimi deneyin.
İçerik ve işlev: Arşivi açın, veritabanını gerçekten geri yükleyin; tabloları, kayıtları, izinleri ve dosya–veritabanı ilişkisini sınayın. Login, sepet, ödeme gibi akışları test/sandbox koşullarında doğrulayın.
Süre ve anahtarlar: İndirme, arşivden çıkarma, şifre çözme, veri yükleme ve doğrulama sürelerini ölçün. Soğuk depolama geri çağırma gecikmesini de RTO’ya katın.
Runbook: Gerekli araç sürümleri, bağımlılıklar, anahtarların güvenli erişim yolu ve görev sorumlularını kaydedin. Gerçek olayda saldırganın kalıcılık mekanizmalarını temizleyip giriş yolunu kapatın; ele geçirilen parolaları, API ve SSH anahtarlarını yenilemeden sistemi yeniden bağlamayın.

Felaket senaryolarını önceden prova etmek için hazırladığımız felaket kurtarma planı nasıl yazılır rehberi, bu runbook’u hazırlarken iyi bir tamamlayıcı olacaktır.

Sık Yapılan Hatalar ve Kendinize Soracağınız 10 Soru

Aşağıdaki hatalar kopya sayısı yeterli görünse de kurtarma kabiliyetini zayıflatabilir:

Yaygın Hatalar

Ortak arıza alanı: Tüm kopyaları aynı sunucu, disk havuzu veya yönetim hesabında tutmak.
Yedeği yanlış tanımlamak: RAID’i ayrı yedek, aynı havuzdaki snapshot’ı offsite kopya veya rclone sync’i saklama geçmişi saymak.
Yanlış yetki modeli: Yükleyiciye governance bypass, legal-hold kaldırma veya bucket politikasını değiştirme yetkisi vermek.
Eksik kurtarma zinciri: Snapshot metadata’sını saklayıp gerekli pack/WAL/veri dosyalarını, yapılandırmayı veya anahtarları kaybetmek.
Kontrolsüz temizleme: Ele geçirilmiş istemcinin ürettiği yeni kayıtlarla retention/prune kararını otomatik verip son temiz geçmişi kaldırmak.
Denemesiz güven: Başarılı upload veya listeleme sonucunu uygulamanın geri yüklenebildiğinin kanıtı saymak.

Kendinize Soracağınız 10 Soru

Üretim dahil üç kopyanın her biri hangi veriyi ve hangi kurtarma tarihini kapsıyor?
Depolama ortamları, fiziksel konumlar ve yönetim hesapları gerçekten hangi arızalarda birbirinden bağımsız?
Hangi nesne sürümleri hangi kilit moduyla, hangi tarihe kadar korunuyor?
Yükleyen hesap korumayı aşabilir, eski sürümü silebilir veya politikayı değiştirebilir mi?
Şifre çözme anahtarı, crypt/depo yapılandırması ve araç sürümleri üretim kaybolduğunda erişilebilir mi?
Son prova, veritabanı ve uygulama verisini gerçekten geri yükleyip doğruladı mı?
RPO ve RTO yazılı mı; ölçülen kurtarma süresi bu hedeflere uyuyor mu?
Çevrimdışı kopya gerçekten bağlantısız mı; mantıksal yalıtımın açık erişim pencereleri biliniyor mu?
Görev hatası, yedek yaşı, eksik veri, kapasite ve retention değişikliği alarm üretiyor mu?
Saklama, gerekli silme ve olay incelemesi ihtiyaçları uyumlu mu; kilit süresi seçilirken ilgili hukuki gereksinimler değerlendirildi mi?

Yedekleme Stratejisini Doğrulamak

Dayanıklı yedekleme, kopya sayısını bağımsız depolama ve yetki sınırlarıyla birleştirir. 3‑2‑1 kopyaların yerleşimini planlamaya, uygun saklama kilidi geçmişi korumaya, çevrimdışı kopya ise ağdan erişimi sınırlandırmaya yardımcı olur. Bunların işe yarayıp yaramadığı; tam veri, kullanılabilir anahtarlar ve temiz ortamda ölçülmüş geri yüklemeyle anlaşılır.

Paylaşımlı hosting, VPS, dedicated veya colocation için başlangıç aynı sorulardır: ne kadar veri kaybı kabul edilebilir, hangi sürede geri dönülmeli ve hangi hesap ele geçirilirse hangi kopyalar kaybedilir? Saklama süresini bütçe, olayın fark edilme süresi ve geçerli yükümlülüklerle birlikte belirleyin. Şifreleme veya Object Lock tek başına KVKK/GDPR uyumu oluşturmaz.

İlk somut adım, mevcut yedeklerden birini üretimden bağımsız ortamda geri yüklemek ve sonucu kaydetmektir. Ardından eksik kopyayı, yetki ayrımını ve saklama politikasını tamamlayın. Sağlayıcıyla görüşürken yedek kapsamını, fiziksel konumu, kilit modunu, sorumluları ve geri yükleme desteğini yazılı olarak netleştirin.

Teknik Kaynaklar