Yedekleri Şifreleyerek Saklama: Güvenli ve Doğrulanabilir Yöntemler

Yedek (backup) almak, felaket senaryosunda veriyi geri çağırmayı sağlar; ancak yedek dosyası ele geçirildiğinde şifrelenmemiş içeriğin tamamı risk altına girer. Bu yazıda, yedekleri şifreleyerek saklama yöntemlerini; hangi seviyede şifreleme yapılacağını, anahtar yönetimini, saklama katmanlarını ve yedeklerin gerçekten çalıştığını nasıl doğrulayacağınızı netleştiriyoruz. Amaç: Kurulumdan sonra “dosya var ama geri alınamıyor” sürprizini azaltmak ve yedek güvenliğini ölçülebilir hale getirmek.

Şifreleme seviyeleri: Ne zaman, neyi şifrelemelisiniz?

Şifreleme tasarımında ilk karar, verinin hangi noktada şifreleneceğidir. Uygulamada üç yaygın seviye vardır.

1) Uygulama seviyesinde şifreleme

Örnek: Veri tabanı dökümü (dump) veya dosya arşivi oluşturulurken doğrudan şifreli format üretilmesi. - Artı: Şifreli içerik, üretim anından itibaren korunur. - Eksi: Aracın formatı/komutları, geri dönüş (restore) sürecini etkileyebilir.

2) Yedek dosyası (paket) seviyesinde şifreleme

Örnek: rsync ile alınan dosyalar önce arşivlenir, sonra tek bir şifreli arşive dönüştürülür. - Artı: Çok sayıda dosyayı tek bir kurtarılabilir paket haline getirirsiniz. - Eksi: Çok büyük arşivlerde yönetim (parçalama) gerekebilir.

3) Aktarım ve saklama seviyesinde şifreleme

Aktarımda TLS (HTTPS/SSH) kullanılır, saklamada ise disk/nesne seviyesinde şifreleme yapılır. - Artı: “Geçişte” güvenlik sağlanır; depolama sağlayıcısı tarafında ek koruma olur. - Eksi: Bu katmanlar tek başına “yedek dosyası ele geçirildi” riskini tamamen kapatmaz. Asıl güvenlik, yedek dosyasının kendi içeriğinin şifrelenmesidir.

Net hedef: Yedek kopyanız depolama hesabına erişen bir üçüncü taraf tarafından okunamamalıdır. Bu nedenle “şifreleme anahtarı sizdeyken, yedek içerik okunamaz” yaklaşımı en doğru modeldir.

Anahtar yönetimi: En önemli güvenlik düğümü

Şifreleme yapıp anahtarları aynı yerde tutmak, güvenliği büyük ölçüde boşa çıkarır. Güvenli anahtar yönetimi için net kurallar:

• Anahtar ayrı tutulmalı: Şifreleme anahtarı yedeklerin saklandığı depoda olmamalıdır. Aynı sistemde bile olsa, farklı disk/erişim mekanizması hedeflenmelidir.
• Anahtar rotasyonu tanımlayın: Her ay/üç ay gibi periyotlarla anahtar yenileme planı yapın. Yeni anahtar ile sonraki yedekler şifrelensin.
• Erişim yetkisi sınırlayın: Anahtarlara sadece restore işlemini yapacak personele/işlem hattına erişim verin.
• Anahtar kaybını önleyin: Anahtarı kaybederseniz şifreli yedekler kurtarılamaz. Anahtar escrow/korumalı saklama modeli oluşturun.

Pratikte en güçlü yaklaşım: Şifreleme için kullanılan anahtarın, yedek dosyalarının bulunduğu sunucudan bağımsız bir yerde tutulmasıdır. Bu, depolama hesabının veya sanal makinenin ele geçirilmesi durumunda bile yedek içeriğini okunamaz kılar.

Şifreleme araçları ve doğru parametre seçimi

Yedek şifrelemede amaç: Geri dönüşte açılabilirlik + güçlü kriptografi + tutarlı format. Linux odaklı yaygın seçenekler üzerinden net bir karşılaştırma yapalım.

Hangi aracı ne zaman seçmelisiniz?

Aşağıdaki tablo, kullanım senaryolarına göre seçim yapmayı kolaylaştırır.

Net parametre hedefleri

Araç seçmek kadar parametre de kritiktir. - “Parola” ile şifreleme yapıyorsanız: Parolayı kısa ve tahmin edilebilir seçmeyin. Tercihen anahtar tabanlı yöntem kullanın. - Sık güncellenen yedeklerde: Aynı anahtarla sınırsız üretim yerine rotasyon planı uygulayın. - Bütünlük doğrulaması için: Şifreleme dışında hash (örn. SHA-256) ile doğrulama adımı ekleyin.

Saklama stratejisi: Şifreli yedek tek başına yetmez

Şifrelemek sadece “okunamama” sağlar; kurtarma senaryosunda erişilebilirlik ve sürüm (version) yönetimi de gerekir.

1) Katmanlı saklama (offline + online)

Net bir düzen kurun: - Online (yakın erişim): Hızlı restore için, şifreli yedek bulut depoda veya uzak bir sunucuda. - Offline/ayrık ortam: Ransomware senaryosuna karşı yedeklerin değiştirilemeyeceği bir katman. Örn. izole bir depolama hedefi veya periyotla taşınan offline kopya.

Ransomware, hem uygulamayı hem de yedek depolama hesabını hedefleyebilir. Bu nedenle “yedek var” cümlesi tek başına yeterli değildir: Yedeklerin zaman içinde değişmeden kalması gerekir.

2) Sürümleme (retention) ve sınırlı tutma

Aşağıdaki net prensibi kullanın: - Günlük yedek: 7-14 gün - Haftalık yedek: 4-8 hafta - Aylık yedek: 6-12 ay

Bu değerler, uygulamanın değişim sıklığına göre netçe güncellenmelidir. E-ticaret gibi sık güncellenen sistemlerde günlük sürüm süresi uzatılır.

3) Aynı şifreli formatı koruyun

Restore testini kolaylaştırmak için, şifreli paket formatını ve anahtar yöntemini mümkün olduğunca standardize edin. Aynı aracı/formatı farklı seçeneklerle karıştırmak, geri dönüşte hataya yol açar.

Yedekleri doğrulama: “Şifreliyse çalışır” yanılgısı

Şifreleme doğru olsa bile yedek dosyası bozulabilir, yanlış anahtarla şifrelenmiş olabilir ya da restore adımı farklı ortamda başarısız olabilir. Bu nedenle doğrulama rutinini yazılı hale getirin.

Net doğrulama checklist’i

• Arşivin açılabilirliği: Şifreli paketi başka bir ortamda (tercihen farklı bir sunucuda) açın.
• Geri dönüş testi (restore test): Veri tabanı veya dosya sisteminin küçük bir parçasını geri yükleyin.
• Bütünlük kontrolü: Şifrelemeden önce/sonra hash üretin ve geri yükleme sonrası doğrulayın.
• Restore süresi ölçümü: RTO (Recovery Time Objective) için süreyi kaydedin.

Uygulama örneği: Parçalı doğrulama yaklaşımı

Tüm arşivi her gün restore etmek maliyetli olabilir. Net alternatif: - Günlük yedeklerde küçük örnek restore edin. - Haftalık tam restore/rehydration yapın.

Bu yöntem, hem güvenliği hem operasyonel maliyeti dengeler.

Otomasyon: Şifreleme ve yedekleme akışını tek pipeline yapın

Yedeklerin şifrelenmesini otomasyonun içine gömmezseniz insan hatası riski artar. Net bir akış önerisi:

1. Dosyaları/DB’yi topla
2. Arşiv/parçalama yap
3. Şifrele (anahtar dışarıda)
4. Hash üret
5. Şifreli paketi depoya yükle
6. Depodan indirip açılabilirlik testi çalıştır
7. Logları sakla (anahtar/loglarda veri sızıntısı olmadan)

Hata senaryoları için net davranış

• Yükleme başarısız olursa: Eski başarılı yedek bozulmayacak şekilde “son iyi kopya” korunmalı.
• Şifreleme başarısız olursa: Şifrelenmemiş dosya asla depoya gitmemeli. Bu kuralı otomasyon script’inde kontrol edin.
• Anahtar bulunamazsa: Restore akışını tetikleyin; yedek üretimi durmalı.

Kurulum için karar noktaları (NetKıyas bakış açısıyla)

VDS/VPS/dedicated sunucu kullanıcılarının sık yaptığı hatalar genelde “hangi bileşen nerede şifrelenmeli?” sorusunda düğümleniyor.

Aşağıdaki karar listesi, sisteminizi doğru konumlandırmanıza yardım eder:

• Yedek hedefiniz (uzak depolama) bulut mu, başka bir sunucu mu?
• Şifreleme anahtarını nereye koyabilirsiniz? Yedekle aynı erişim mantığını paylaşmıyor mu?
• Yedek boyutu artıyor mu? Artıyorsa parçalama ve sürümleme planı var mı?
• Restore için RTO ve RPO hedefiniz nedir? (Örn. “veri en fazla 1 gün kaybolabilir” gibi)
• Doğrulama rutini var mı? En az haftada bir restore testi yapıyor musunuz?

Bu soruların yanıtı, doğru yöntemi belirler. Şifrelemeyi sadece “dosyayı .zip yapmak” gibi düşünmek, güvenlik hedefini karşılamaz.

Sonuç: Hemen uygulanacak aksiyon planı

Yedekleri şifreleyerek saklama sürecinde en hızlı ilerleme; (1) şifreli paket üretmeyi, (2) anahtarı yedeklerden bağımsız tutmayı, (3) bütünlük + restore testini rutin haline getirmeyi planlamaktır. Bugün başlayın: Mevcut yedek alım aracınız varsa şifreleme katmanını arşiv paketine ekleyin; anahtar saklama düzenini ayırın; ardından 1 yedek dosyası üzerinde açılabilirlik testi yapın. Eğer restore testinde hata görürseniz, güvenlik sağlayan şifreleme doğru olsa bile kurtarma planınız tamamlanmamış demektir—önce test, sonra otomasyon standardizasyonu yapın.