Ransomware’a Dayanıklı Hosting Yedekleme Stratejisi: 3‑2‑1 Kuralı, Immutable Backup ve Air‑Gap

Bugün bir sunucu güvenlik denetimi yaparken ilk sorduğumuz sorulardan biri ş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ımlarının artık doğrudan yedeklere saldırdığını, yedek depolama kimlik bilgilerini hedeflediğini ve ağdaki her erişilebilir kopyayı tek tek şifrelediğini gördüğünüzde resim tamamen değişiyor.

Bu yazıda, hosting ortamında gerçekten ransomware’a dayanıklı bir yedekleme mimarisi kurmak için üç temel taşı birlikte ele alacağız: 3‑2‑1 yedekleme kuralı, immutable (değiştirilemez) yedekler ve air‑gap (fiziksel/mantıksal yalıtılmış) yedekleme. Odak noktamız, paylaşımlı hosting, VPS ve dedicated sunucularınızı DCHost altyapısında çalıştırırken uygulayabileceğiniz pratik, test edilebilir ve sürdürülebilir bir strateji kurmak olacak. Teknik terimleri mümkün olduğunca sadeleştirerek, gerçek dünya senaryolarından örneklerle ilerleyeceğiz.

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

Ransomware saldırıları artık yalnızca dosyalarınızı şifreleyip fidye isteyen “klasik” zararlı yazılımlardan ibaret değil. Modern saldırı senaryolarında, saldırganlar önce erişim haklarını genişletiyor, yönetici hesaplarını ele geçiriyor, ardından da yedek altyapısını sistematik biçimde devre dışı bırakmaya çalışıyor.

Son yıllarda gördüğümüz bazı ortak desenler:

• 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 S3 uyumlu depolama erişim anahtarlarının (access key/secret) ele geçirilip, saldırgan tarafından mevcut tüm yedek versiyonlarının da silinmesi.

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

• Tek noktaya güvenen yedek yoktur. Bir kopya asla yedek sayılmaz.
• Erişilebilen her şey şifrelenebilir veya silinebilir. Yani yedekleriniz saldırganın yetki seviyesinden bağımsız, ek güvenlik katmanlarıyla korunmalıdır.

DCHost’ta altyapı tasarlarken, yedek mimarisini artık “disk arızası” senaryosundan çok, “yetkisi genişlemiş saldırgan” senaryosuna göre kurguluyoruz. İş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 kuralı, modern yedekleme dünyasında hâlâ en sağlam iskeletlerden biri:

• 3 kopya veri (1 üretim + 2 yedek)
• 2 farklı ortam (farklı disk türü, farklı depolama sistemi, farklı dosya formatı vb.)
• 1 kopya mutlaka offsite (farklı veri merkezinde veya en azından farklı fiziksel/lojik altyapıda)

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

• 1. Kopya (Üretim): Web siteniz ve veritabanınızın çalıştığı DCHost sunucusu.
• 2. Kopya (Yerel Yedek): Aynı veri merkezinde ama farklı disk havuzunda tutulan günlük snapshot veya panel yedekleri.
• 3. Kopya (Uzak Yedek): Farklı veri merkezinde barındırılan S3 uyumlu object storage üzerinde şifrelenmiş ve versiyonlu yedekler.

3‑2‑1 kuralını hosting tarafında nasıl uygulayabileceğinizi, 3‑2‑1 yedekleme stratejisi neden işe yarıyor ve cPanel/plesk/VPS’te otomatik yedekleri nasıl kurarsınız yazımızda detaylı anlattık. Bu yazıda ise aynı prensibi ransomware’e özel sertleştirme katmanlarıyla birleştireceğiz.

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 bilgisi ayrımı: Üretim sunucusunun sahip olduğu erişim anahtarları, tüm yedeklere tam yetkili olmamalı. En kötü ihtimalde yalnızca “yeni yedek yazma” yetkisi olmalı.
• Sürümleme (versioning): Uzak depoda silinen veya üzerine yazılan yedeklerin önceki versiyonlarına geriye dönük erişim sağlanmalı.
• Silme işlemlerine ek fren: “Tüm klasörü boşalt” komutu tek adımda geri dönülemez sonuç üretmemeli; immutable/retention politikaları ile frenlenmeli.

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

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

Immutable backup, belirli bir süre boyunca değiştirilemeyen, silinemeyen yedek kopyaları ifade eder. Bir kez yazıldıktan sonra, tanımlı “tutma süresi” dolana kadar kimse (hatta tam yetkili bir yönetici bile) bu veriyi değiştiremez veya silemez.

Bunu günlük hayattan bir metaforla düşünün: Bir kasaya belge koyuyorsunuz ve kasayı 30 günlüğüne zaman kilidine alıyorsunuz. Anahtar sizde olsa bile, süre dolmadan kasayı açamıyorsunuz. Immutable backup tam olarak bunu dijitalde yapıyor.

S3 Object Lock ve WORM Mantığı

Immutable yedekleri pratiğe dökmek için en sık kullanılan yöntemlerden biri, S3 uyumlu depolarda Object Lock veya WORM (Write Once, Read Many) özelliklerini kullanmaktır. DCHost altyapısında da yaygın olarak kullandığımız bu yaklaşımı, S3 Object Lock ile fidye yazılıma karşı kale gibi yedek rehberimizde ayrıntılı anlattık.

Temel mantık şu adımlarla kuruluyor:

1. Yedekler, S3 uyumlu bir bucket içine yazılıyor.
2. Bucket’ta versioning (sürümleme) etkinleştiriliyor.
3. Object Lock devreye alınarak, her yedek nesnesine “şu tarihe kadar silinemez/değiştirilemez” bilgisi ekleniyor.
4. Silme veya süreyi kısaltma denemeleri, politika tarafından reddediliyor.

Bu sayede, üretim sunucusuna tam erişim sağlanmış ve yedekleme access key’i ele geçirilmiş olsa bile, saldırgan yalnızca yeni kötü yedekler yazabilir; geçmişteki immutable kopyaları fiziksel olarak silemez.

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

DCHost üzerinde tipik bir senaryoyu 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 senaryoda immutable yedekleme için aşağıdaki akış oldukça sağlamdır:

1. Uygulama ve veritabanı için uygulama‑tutarlı yedek alın (örneğin LVM snapshot + mysqldump ya da XtraBackup). Bu konuda uygulama‑tutarlı yedekler ve LVM snapshot kullanımı rehberimize de göz atabilirsiniz.
2. Bu yedek çıktısını (örneğin restic veya borg ile) sıkıştırıp şifreleyerek S3 uyumlu immutable bucket’a gönderin.
3. Bucket üzerinde Object Lock ve retention politikası ile, örneğin 30 gün boyunca “silinemez/değiştirilemez” kuralını uygulayın.
4. Yedekleme kimlik bilgilerinin yalnızca “yazma” ve “listeleme” hakkına sahip olduğundan, silme hakkı olmadığından emin olun.

restic ve borg gibi modern araçlarla S3 uyumlu uzak yedekleme kurulumunu, restic ve Borg ile S3 uyumlu uzak yedekleme başlıklı yazımızda adım adım anlattık. Immutable katmanını buradaki akışa eklediğinizde, ransomware senaryolarına karşı çok daha sağlam bir yapı elde edersiniz.

Air‑Gap Yedekleme: Ağdan Kopuk Son Kale

Air‑gap, kelime anlamıyla “hava boşluğu” demek. Yedek dünyasında ise şu anlama geliyor: Belirli bir yedek kopyası, normal ağ erişimiyle ulaşılamayacak kadar izole bir yerde tutuluyor.

Bu fiziksel olabilir (örneğin offline tape kasetler, harici diskler) veya mantıksal olabilir (erişim yalnızca belirli bir bakım zaman aralığında, kısıtlı bir ağ tüneli ile açılır). Önemli olan, saldırı anında ransomware’in yayılabildiği ağ segmentlerinden tamamen kopuk olmasıdır.

Hosting Ortamında Pratik Air‑Gap Senaryoları

Hosting tarafında en sık kullandığımız mantıksal air‑gap senaryolarından bazıları:

• Ayrı yedek VPS’i: Üretim altyapısından farklı bir DCHost veri merkezinde, yalnızca yedekleri toplamak için kullanılan, SSH anahtarları ve firewall kurallarıyla sıkı biçimde izole edilmiş bir VPS.
• Zamanlanmış kısa bağlantı pencereleri: Yedek sunucusu normalde tüm üretim sunucularına kapalıdır; yalnızca belirli cron zamanlarında (örneğin gece 02:00–02:30 arası) firewall kuralı geçici olarak açılır, rsync/restic ile yedekler çekilir, ardından bağlantı penceresi kapanır.
• Ayrı yönetim kimlik bilgileri: Yedek sunucusuna erişen kullanıcı hesapları, üretim ortamına erişen hesaplardan tamamen farklı tutulur; böylece tek bir kimlik bilgisinin ele geçirilmesi tüm yapıyı çökertmez.

Buna ek olarak, bazı kurumlar hâlâ belirli aralıklarla fiziksel air‑gap de kullanıyor: Kritik aylık yedekler, şifrelenmiş arşiv olarak harici disk veya tape’e alınarak veri merkezinden fiziksel olarak çıkarılıyor. Bu yaklaşım maliyetli ve operasyonel zahmetli olsa da, bazı regülasyonlu sektörlerde hâlâ altın standart kabul ediliyor.

Air‑Gap ile Immutable Backup’ı Birleştirmek

En güçlü mimarilerde immutable ve air‑gap genellikle birlikte kullanılır:

• 1. katman: Yerel snapshot’lar (hızlı geri dönüş için, ransomware’e karşı tek başına yeterli değil).
• 2. katman: Uzak S3 uyumlu depoda immutable backup (Object Lock + versioning).
• 3. katman: Mantıksal veya fiziksel air‑gap ile dönemsel (haftalık/aylık) tam arşiv kopyaları.

Böylece, en kötü senaryoda bile (örneğin S3 erişim anahtarlarının tümü sızdırıldı, üretim ortamı tamamen şifrelendi), ayrı air‑gap katmanındaki kopyalarınız, son savunma hattı olarak elinizde kalıyor.

DCHost Üzerinde Ransomware’a Dayanıklı Örnek Mimari

Şimdi tüm parçaları bir araya getirip, DCHost üzerinde çalışan tipik bir e‑ticaret sitesi veya SaaS uygulaması için somut bir örnek mimari kuralım. Buradaki tasarım, kolayca ölçeklenebilir ve az sayıda bileşenle uygulanabilir olmayı hedefliyor.

1. Katman: Uygulama‑Tutarlı Günlük Yedekler

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

• Veritabanı (MySQL/MariaDB/PostgreSQL) için günlük veya daha sık aralıklarla tam veya artımlı yedek alın.
• Dosya sistemi için LVM snapshot veya rsync tabanlı bir çözümle kod, yüklenen dosyalar ve yapılandırma kopyalanın.
• Bu işlemleri cron/systemd timer ile otomatikleştirin; manuel adım bırakmamaya çalışın.

Bu aşamada dikkat edilmesi gereken nokta, yedeklerin aynı diskte değil, ayrı bir disk havuzunda veya en azından ayrı partition’da tutulmasıdır. Ancak bu katman ransomware’e karşı tek savunmanız olmamalı; burası daha çok “hızlı geri dönüş” katmanı.

2. Katman: S3 Uyumlu Immutable Uzak Yedekler

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

• DCHost altyapınızdan erişebileceğiniz S3 uyumlu bir bucket oluşturun.
• Bucket’ta versioning ve Object Lock’u etkinleştirin.
• restic, borg veya benzeri bir araçla uygulama + veritabanı yedeklerinizi bu bucketa gönderin.
• Yedekleri üretimden bağımsız bir şifreleme anahtarı ile şifreleyin (örneğin restic repository password).

Yedek yükleyen kullanıcı hesabına yalnızca put/list yetkisi verip delete yetkisini kapatarak, saldırganın erişse bile geçmiş immutable kopyaları silmesini neredeyse imkansız hale getirebilirsiniz. Bu modelin detaylarını, hem object storage’a otomatik yedek alma (rclone, restic ve cron ile cPanel/VPS yedekleri) hem de restic ve Borg ile S3 uyumlu uzak yedekleme rehberlerimizde ayrıntılı bulabilirsiniz.

3. Katman: Air‑Gap Arşiv Yedekler

Üçüncü katmanda, haftalık veya aylık periyotlarla, tüm sistemi kapsayan air‑gap bir arşiv üretin:

• Belirli bir gün/saat seçin (örneğin her pazar 03:00).
• Yalnızca bu zaman aralığında aktif olan bir bağlantı penceresiyle, ayrı bir DCHost VPS’ine rsync/restic ile tam arşiv yedeği çekin.
• Bu VPS’i üretim ağından firewall ile sert biçimde yalıtın; normal zamanda inbound bağlantıları tamamen kapalı tutun.
• Dilerseniz bu arşiv yedeklerini periyodik olarak şifreli tar arşivi olarak indirip, kurum içi NAS veya offline depolama üzerinde ek bir katman daha oluşturun.

Böylece, üretim ortamınız tamamen ele geçirilmiş ve S3 erişim anahtarlarınız çalınmış olsa bile, saldırganın erişemeyeceği ekstra bir yedek katmanınız olur.

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

DCHost üzerinde pek çok müşterimizle birlikte şunu gördük: Yedek var ama 1 yıl boyunca hiç restore denenmemiş. Böyle bir ortamda, gerçek bir fidye saldırısında risk almak istemezsiniz. Bu yüzden:

• Her 1–3 ayda bir, rastgele seçilen bir yedeği ayrı bir test sunucusuna geri yükleyin.
• Veritabanı bütünlüğünü, uygulamanın ayağa kalkmasını ve kritik işlevleri (sepet, ödeme, login vb.) test edin.
• Bu süreci adım adım anlatan bir runbook (yazılı prosedür) oluşturun.

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

Ransomware’a dayanıklı yedek mimarisi kurarken en çok gördüğümüz hataları ve kendinize sorabileceğiniz kontrol sorularını özetleyelim.

Yaygın Hatalar

• Tüm yedeklerin aynı sunucuda tutulması: Disk arızası ve ransomware için tek seferde kayıp anlamına gelir.
• Tek yedek hedefi kullanmak: Sadece RAID, sadece snapshot veya sadece tek bir object storage yetersizdir.
• Silme yetkisi olan access key’ler: Üretim sunucusundan kullanılan anahtarların, immutable katmanı bile devre dışı bırakabilecek kadar geniş yetkili olması.
• Şifrelenmemiş uzak yedekler: Object storage sızıntısında müşterilerinizin ham verisinin açığa çıkması.
• Hiç restore testi yapmamak: Yedeklerin yalnızca “var” olduğunu bilmek, geri dönüş süresini ve başarısını garanti etmez.

Kendinize Soracağınız 10 Soru

1. Şu an üretimde çalışan verilerimin en güncel 3 bağımsız kopyası gerçekten var mı?
2. Bu kopyalardan en az 1 tanesi, farklı bir DCHost veri merkezinde veya tamamen farklı bir altyapıda mı?
3. S3 uyumlu yedeklerimde versioning ve Object Lock etkin mi, yoksa tek sürüm mü tutuyorum?
4. Üretim sunucusundan erişilen access key, yedekleri silme yetkisine sahip mi?
5. Yedeklerim şifreli mi? Şifreleme anahtarları nerede, nasıl yedeklenmiş durumda?
6. Son 6 ay içinde en az 1 kez, rastgele bir tarihteki yedeği açıp test restore yaptım mı?
7. RPO ve RTO hedeflerim yazılı olarak tanımlı mı, yoksa herkes kafasına göre bir tahmin mi yapıyor?
8. Air‑gap bir katmanım var mı, yoksa tüm kopyalar sürekli aynı ağdan erişilebilir durumda mı?
9. Yedekleme görevleri başarısız olduğunda bana e‑posta veya alarm gönderen bir izleme sistemim var mı?
10. Yedekleme politikam KVKK/GDPR gibi regülasyonlarla çelişmeyecek şekilde saklama süreleri ve silme prosedürleri içeriyor mu?

Sonuç: Ransomware’a Dayanıklı Yedek, Sadece Bir Ayar Değil Bir Mimari Kararı

Ransomware çağında, “yedek alıyoruz, sorun yok” demek maalesef yeterli değil. Artık yedekler de doğrudan hedefte ve saldırganlar, yedek altyapısını devre dışı bırakmadan fidye talep etmeyecek kadar tecrübeli. Bu yüzden 3‑2‑1 kuralı, immutable backup ve air‑gap katmanları bir araya geldiğinde gerçek anlamda dayanıklı bir mimari elde ediyorsunuz.

DCHost ekibi olarak, ister paylaşımlı hosting, ister VPS, ister dedicated veya colocation kullanın; yedek mimarinizi gerçekçi RPO/RTO hedefleriyle, KVKK/GDPR yükümlülükleriyle ve bütçe kısıtlarıyla birlikte ele almayı öneriyoruz. İlk adım olarak, mevcut ortamınızda yukarıdaki 10 soruya dürüstçe cevap vermeniz bile nereden başlamanız gerektiğini netleştirecektir.

Eğer yedek stratejinizi yeniden tasarlamak, S3 uyumlu immutable yedekler kurmak veya air‑gap arşiv mimarisini DCHost altyapınızda hayata geçirmek istiyorsanız, ekibimizle birlikte proje planlama toplantısı yaparak ayrıntılı bir yol haritası çıkarabiliriz. Böylece olası bir ransomware saldırısı geldiğinde, panikle değil, daha önce prova edilmiş felaket kurtarma planınızla ve sağlam yedeklerinizle hareket edersiniz.