Fidye Yazılımına Dayanıklı Yedekleme Rehberi: restic ve rest-server Append-Only Kipiyle Silinemeyen Yedekler, Saklama Politikası ve Geri Yükleme Testi

Fidye yazılımı operatörleri artık yalnızca dosyaları şifrelemekle yetinmiyor; ağa girdikten sonra ilk hedefledikleri şeylerden biri yedeklerdir. Yedek sunucusu, sunucuların yönetici hesaplarıyla erişilebilen bir paylaşım veya silme yetkisi olan bir bulut anahtarı ele geçirildiğinde, saldırgan önce yedekleri siler, ardından şifrelemeyi başlatır. Bu noktada "yedeğimiz var" cümlesi bir anlam taşımaz.

Bu rehberde açık kaynak yedekleme aracı restic ile yedek alan sunucunun, yedekleri silemeyeceği ve değiştiremeyeceği bir mimari kuruyoruz. Temel yapı taşı, restic'in resmî sunucu bileşeni olan rest-server'ın --append-only kipidir. Komutlar restic ve rest-server resmî belgelerine dayanmaktadır.

1. Tehdit modeli: yedek neden ilk hedef?

Klasik bir kurulumda yedeklenen sunucu, yedek deposuna tam yetkiyle bağlanır: yazar, okur ve eski yedekleri temizlemek için siler. Saldırgan bu sunucuyu ele geçirdiğinde aynı yetkiyi devralır. Dolayısıyla korunması gereken asıl ilke şudur:

Yedeği üreten sistem, yedeği yok edebilecek yetkiye sahip olmamalıdır.

Bunu sağlamak için görevler ikiye ayrılır:

Rol	Nerede çalışır	Yetkisi
Yedek alma (backup)	Korunan sunucu	Yalnızca yeni veri ekleme
Temizlik (forget/prune) ve doğrulama	Yedek sunucusunun kendisi veya ayrı yönetim makinesi	Silme ve bakım
Geri yükleme testi	İzole test makinesi	Okuma

2. restic ve rest-server kısaca

restic, yedekleri istemci tarafında şifreleyen ve tekrar eden veriyi ayıklayan (deduplication) bir komut satırı aracıdır. Depo; yerel dizin, SFTP, S3 uyumlu nesne depolama veya REST sunucusu olabilir. rest-server ise restic'in REST arka ucunu uygulayan hafif bir HTTP sunucusudur.

rest-server belgelerine göre --append-only kipi yeni yedeklerin oluşturulmasına izin verirken mevcut yedeklerin silinmesini ve değiştirilmesini engeller. Bu, yedeklenen sistemin ele geçirilme riskine karşı tam da ihtiyaç duyulan davranıştır.

3. rest-server kurulumu: TLS, kimlik doğrulama ve append-only

Yedek sunucusunda önce her istemci için ayrı bir kullanıcı oluşturun. rest-server, kimlik bilgilerini htpasswd dosyasında tutar; bcrypt için -B seçeneği kullanılır:



Ardından sunucuyu TLS, özel depolar ve append-only kipiyle başlatın:



Seçeneklerin anlamı:

Seçenek	Görevi
--tls, --tls-cert, --tls-key	Trafiği şifreler; parola ve veri ağda açık gitmez
--htpasswd-file	Kullanıcı ve parola dosyasının yeri
--private-repos	Her kullanıcı yalnızca kendi adındaki alt dizine erişir
--append-only	Yeni yedek eklenebilir, var olan yedek silinemez ve değiştirilemez

--private-repos önemli bir yan korumadır. Belgelere göre "foo" kullanıcısı rest:https://foo:pass@host:8000/foo adresine erişebilir; ancak aynı kullanıcı kök dizine veya /foobar/ gibi başka bir dizine erişemez. Böylece ele geçirilen bir web sunucusu, veritabanı sunucusunun yedeklerini okuyamaz.

Test ortamında görülebilecek --no-auth seçeneğini üretimde kullanmayın; kimlik doğrulamasız bir yedek sunucusu ağdaki herkese açık demektir.

4. İstemci tarafı: depo oluşturma ve parola yönetimi

Korunan sunucuda depo adresini ve parolayı ortam değişkeniyle vermek, parolanın komut geçmişine ve süreç listesine düşmesini önler. restic, parolayı RESTIC_PASSWORD_FILE (veya --password-file) ile bir dosyadan ya da --password-command ile bir programdan okuyabilir:



Kritik not: Depo şifreleme parolası kaybolursa yedekler geri açılamaz. Parolayı korunan sunucudan bağımsız bir yerde, örneğin çevrimdışı bir parola kasasında saklayın. Saldırgan sunucudaki parola dosyasını okuyabilir; ancak append-only kipi sayesinde bu parola ile yedekleri silemez.

Yedeği zamanlamak için basit bir cron satırı yeterlidir:



5. Temizlik politikası: forget ve prune nerede çalışmalı?

Append-only depoda korunan sunucu eski yedekleri silemez; bu yüzden saklama politikası, depoya doğrudan erişimi olan yedek sunucusunun kendisinde veya ayrı bir yönetim makinesinde uygulanır. restic belgelerinde örnek politika şöyledir:



--dry-run hiçbir şey silmeden neyin silineceğini gösterir; politikayı ilk kez uygularken mutlaka bu seçenekle başlayın. forget yalnızca anlık görüntü (snapshot) kayıtlarını kaldırır, alanı geri kazanmak için prune gerekir; --prune ikisini sırayla çalıştırır.

Burada gözden kaçan önemli bir saldırı yolu var: Ele geçirilen sunucu, silme yetkisi olmasa bile depoya çok sayıda sahte anlık görüntü ekleyebilir. Yöneticinin çalıştırdığı "son 7 günlük yedeği tut" türündeki bir politika, bu sahte kayıtları "en yeni" sayıp meşru yedekleri silebilir. restic belgeleri bu nedenle append-only depolarda --keep-within kullanılmasını önerir; bu seçenek saldırganın eklediği kayıtlarla birlikte meşru olanları da belirtilen süre boyunca tutar:



6. Yedeğin sağlamlığını doğrulama

Hiç geri yüklenmemiş bir yedek, var olduğu varsayılan bir yedektir. restic'in check komutu depo yapısını denetler; varsayılan olarak veri paketlerinin içeriğini okumaz. İçeriği de doğrulamak için --read-data veya depoyu parça parça okuyan --read-data-subset kullanılır:



1/5 biçimi paket dosyalarını beş gruba ayırıp birini okur; bunu haftalık döngüyle 1/5'ten 5/5'e ilerletirseniz tüm depo beş haftada bir baştan sona okunmuş olur.

Düzenli bir geri yükleme testi de takvime eklenmelidir:



restic belgeleri, --path seçeneğinin yalnızca hangi anlık görüntünün seçileceğini belirlediğini, geri yüklenecek dosyaları daraltmak için --include veya --exclude kullanılması gerektiğini vurgular.

7. İkinci kopya: copy ile farklı ortama aktarma

Tek bir yedek sunucusu da yangın, donanım arızası veya o sunucunun ele geçirilmesi riski taşır. restic'in copy komutu anlık görüntüleri bir depodan diğerine aktarır. Yedek sunucusunda çalışan bir görevle ikinci konuma, örneğin farklı bir sağlayıcıdaki S3 uyumlu depoya kopya alınabilir:



İkinci konumun erişim anahtarını korunan sunuculara hiçbir zaman koymayın; bu anahtar yalnızca yedek sunucusunda bulunmalıdır.

8. Kontrol listesi

• Yedek alan sunucu, depoya yalnızca append-only kipindeki rest-server üzerinden erişiyor mu?
  
• rest-server TLS ile mi çalışıyor, --no-auth kapalı mı, --private-repos açık mı?
  
• Her sunucunun ayrı kullanıcısı ve ayrı depo dizini var mı?
  
• forget/prune yalnızca yedek sunucusunda veya yönetim makinesinde mi çalışıyor, --keep-within kullanılıyor mu?
  
• Depo şifreleme parolası korunan sunucudan bağımsız, çevrimdışı bir yerde saklanıyor mu?
  
• check --read-data-subset düzenli çalışıyor mu, geri yükleme testi takvimde mi?
  
• Farklı ortamda ikinci bir kopya var mı ve o ortamın anahtarı korunan sunucularda bulunmuyor mu?

Sonuç

Fidye yazılımına karşı yedeklemede asıl soru "yedek alıyor muyuz?" değil, "sunucularımızdan biri ele geçirildiğinde yedeklerimiz ayakta kalır mı?" sorusudur. restic ve rest-server'ın append-only kipi, yedek üreten sistemle yedeği silebilen sistemi birbirinden ayırarak bu soruya olumlu yanıt vermeyi sağlar. Ancak bu mimari de düzenli doğrulama ve geri yükleme testleriyle tamamlanmadıkça eksik kalır.

Kaynaklar

• restic belgeleri, yeni depo hazırlama: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html
  
• restic belgeleri, anlık görüntü silme ve saklama politikası: https://restic.readthedocs.io/en/stable/060_forget.html
  
• restic belgeleri, depo işlemleri (check, snapshots, copy): https://restic.readthedocs.io/en/stable/045_working_with_repos.html
  
• restic belgeleri, geri yükleme: https://restic.readthedocs.io/en/stable/050_restore.html
  
• rest-server GitHub deposu: https://github.com/restic/rest-server

← Ana sayfaya dön