Yedekleri Şifreleyerek Saklama: Uygulama ve Kontrol Rehberi

Yedek almak tek başına güvenlik sağlamaz; yedeğin şifrelenmemesi halinde dosyalar ele geçirildiğinde kimlik bilgileriniz, veritabanı dökümleri ve dosya listeleri doğrudan okunabilir hale gelir. Bu rehberde, sunucudan alınan yedeklerin yedek (backup) şifreleme ile güvenli biçimde saklanması için izlenebilir, ölçülebilir bir yol haritası veriyorum. Hedef; hangi şifreleme yaklaşımının seçileceği, anahtarların nasıl yönetileceği, şifreli yedeklerin nasıl test edileceği ve hangi hataların riski artırdığı konularında net karar almanız.

Aşağıdaki plan; VDS/VPS/dedicated sunucularda çalışan komut tabanlı yedekleme (rsync, tar, dump), bulut depolama (S3 uyumlu) ve kontrol paneli senaryolarında da uygulanabilir.

1) Şifreleme hedefini netleştirin: “At-rest” mi “in-transit” mi?

Şifreleme iki farklı katmanda ele alınır ve ikisini karıştırmak risk üretir.

• At-rest şifreleme: Yedek dosyası depoda (disk, bulut bucket, obje depolama) iken şifreli durur. En kritik katmandır.
• In-transit şifreleme: Yedek dosyası depoya taşınırken (SSH/HTTPS üzerinden) şifreli olur. Bu katman da gerekir; ancak depodaki dosya ele geçirilirse tek başına yeterli değildir.

Net hedef: Depoya yazdığınız yedek dosyası, depoda okunamaz durumda olmalıdır. Taşınma sırasında SSH/HTTPS kullanmak “ek güvenlik” sağlar; “tek başına çözüm” değildir.

2) Yaklaşım seçimi: Dosya bazlı şifreleme mi depolama bazlı şifreleme mi?

Piyasada iki yaygın yaklaşım var. En doğru seçim, yedeği kimin yönettiğine ve anahtar kontrolünü kimin elinde tuttuğuna bağlıdır.

Depolama bazlı şifreleme (provider-side encryption)

Bulut sağlayıcıların obje depolama katmanında yaptıkları şifreleme, diskte şifreli tutabilir. Ancak anahtar politikası her sağlayıcıda aynı şeffaflıkta sunulmaz.

Bu modelin avantajı: Yönetim kolaylığı. Bu modelin riski: Anahtar kontrolü sizde değilse, “yedek dosyası depoda ne kadar gerçekten okunamaz?” sorusunda belirsizlik artar.

Dosya bazlı şifreleme (client-side / end-to-end)

Yedeği almadan önce veya yedek dosyasını üretirken, şifreleme işlemini siz yaparsınız. Sonuçta depoya giden dosya şifreli blob olur.

Bu modelin avantajı: Depoya yazılan dosya okunamaz; anahtar sizdedir. Bu modelin riski: Anahtar kaybı doğrudan kurtarma kaybına dönüşür. Bu yüzden anahtar yönetimi şarttır.

Net karar kuralı: - Yedek “kimin erişebileceği belirsiz” bir ortamda saklanacaksa: Dosya bazlı şifreleme şarttır. - Anahtar yönetiminiz (rotation, erişim) kontrol altındaysa: dosya bazlı şifreleme tercih edin.

3) Şifreleme formatı ve araç seçimi: pratik ve geri dönüşü test edilebilir olsun

Şifreli yedeklerde amaç, hem güvenlik hem de restore edilebilirliktir. Araç seçerken aşağıdakileri birlikte düşünün.

Önerilen özellikler

• Şifreleme algoritması modern olmalı (ör. AES-256)
• Parola yerine tercihen anahtar/anahtar dosyası kullanılabilmeli
• Dosya bütünlüğü doğrulanabilmeli (hash doğrulama)
• Restore senaryosu kolay test edilebilir olmalı

“Güvenli gibi görünen” hatalar

• Şifreyi ortam değişkeninde (env) düz metin tutmak
• Şifreyi yedek dosyasıyla aynı klasörde saklamak
• Tek şifreyle tüm yedek setini kilitlemek ve anahtar rotasyonunu hiç yapmamak
• Şifreli arşivi oluşturduktan sonra açılıp doğrulanmayan yedek almak

4) Anahtar yönetimi (en kritik adım): Kimin elinde, ne zaman değişiyor?

Şifreli yedeklerin güvenliği anahtara bağlıdır. Anahtar yönetimini tek cümleyle özetlemek gerekirse: “Anahtar depodan ayrı, erişim kontrollü ve rotasyonlu olmalı.”

Anahtarların saklanacağı yer

• Sunucu dosya sistemi yerine, ayrı bir “anahtar deposu” (ör. KMS, vault benzeri sistem) kullanmak en temiz yaklaşımdır.
• KMS/vault yoksa bile anahtarı depodan ayırın: yedek dosyası S3 bucket’ta ise anahtar yerel disk veya şifreli bir LUKS bölümü üzerinde olmalıdır.

Erişim kontrolü

• Yedekleme çalışan hesabının yalnızca gerekli yetkileri olsun.
• Anahtara erişim kimin yetkisiyle mümkün olduğunu yazılı hale getirin.

Rotasyon (rotation) planı

• Yedekler için tek bir ömür boyu şifre/anahır kullanmayın.
• Uygulama: “Her 30/60 günde bir yeni anahtar setiyle yeni yedek alın” gibi net bir takvim belirleyin.

Anahtar kaybı kabul edilemez

Şifreyi kaybederseniz yedeği restore edemezsiniz. Bu nedenle geri yükleme testini “planlı operasyon” haline getirin.

5) Uygulama: Şifreli yedek arşivi oluşturma ve saklama (komut düzeyi)

Aşağıdaki örnekler, en az varsayımla çalışır: önce yedek içerik arşivi oluşturun, sonra şifreleyin, ardından depoya gönderin.

Örnek akış (dosya bazlı, client-side)

1) Yedek içeriğini toplayın (tar) 2) Şifreli arşiv üretin 3) Arşivin açılabildiğini doğrulayın (restore test) 4) Şifreli dosyayı depoya yükleyin (S3 uyumlu vb.) 5) İsteğe bağlı: bütünlük hash’i saklayın

Tar + şifreleme (örnek komut mantığı)

Aşağıdaki komutlar bir “şablon”dur; kullandığınız araca göre parametreler değişebilir.

• Arşiv alma:
• tar -czf backup_$(date +%F).tar.gz /var/www /etc
• Şifreleme:
• gpg --symmetric --cipher-algo AES256 --batch --yes -o backup_$(date +%F).tar.gz.gpg backup_$(date +%F).tar.gz
• Temizleme (düz arşivi sil):
• shred -u backup_$(date +%F).tar.gz || rm -f backup_$(date +%F).tar.gz

Bu akışta kritik nokta: Düz (şifrelenmemiş) arşiv, depoya gitmeden önce silinmelidir ve mümkünse oluşturulduğu anın kısa süreli olmasına dikkat edilmelidir.

Restore testini standartlaştırın

Şifreli yedek aldıktan sonra “en azından doğrulama” yapın: - gpg --decrypt --batch --yes backup_YYYY-MM-DD.tar.gz.gpg | tar -tzf - > /dev/null

Bu işlem, yedeğin açılabilir olduğunu ve arşiv bozulmadığını gösterir.

6) Yedekleri depolarken pratik kontrol listesi (S3/bucket veya NFS olabilir)

Aşağıdaki kontrol listesi; “şifre var ama risk var” senaryolarını azaltır.

Depolama tarafında kontrol edilecekler

• Depoya yüklenen dosya uzantısı: düz dosya değil, şifreli dosya (örn: .gpg, .enc)
• Bucket/NFS izinleri: dosyaları yalnızca yedekleme sistemi okumal/erişebilmelidir
• Sürümleme (versioning): yanlışlıkla silme/ezme riskini azaltır
• Yaşam döngüsü (lifecycle): ör. 30/90/180 gün politika net olsun

Taşıma sırasında kontrol edilecekler

• SSH üzerinden aktarımda: mümkünse sadece anahtar tabanlı erişim
• S3/HTTP aktarımında: TLS (HTTPS) zorunlu
• Aktarım logları: hata durumunda tekrar deneme mekanizması

Saklama stratejisi: 3-2-1 mantığını şifrelemeyle birleştirin

Şifreleme, “yedekleri okunamaz” yapar; çoğaltma ise “erişim kesintisine karşı süreklilik” sağlar. - 3 kopya (ör. yerel + uzak 1 + uzak 2) - 2 farklı ortam (ör. disk + bulut) - 1 kopya offline/ayrı erişim (ör. sadece kurtarma saatinde erişilen)

7) Hangi yedek türleri için şifreleme seviyesi farklı olmalı?

Her yedek aynı risk seviyesinde değildir. Şifreleme politikanızı yedek türüne göre netleştirin.

Veritabanı yedekleri

• MySQL/MariaDB/PostgreSQL dump’ları genellikle parolalar ve kullanıcı tablolarını içerir.
• Şifreleme zorunludur (at-rest).

Uygulama dosyaları ve web içerikleri

• Kaynak kod, konfig dosyaları ve API anahtarları risk yaratır.
• Özellikle .env, konfig dosyaları, private key dosyaları varsa şifreleme zorunludur.

Loglar

• Loglarda oturum bilgisi, token, IP gibi veriler bulunabilir.
• Her log seti için şifreleme gerekmez; ama kimlik doğrulama/log içeriğinde hassas veri varsa şifreleme yapın.

SSL sertifikaları ve anahtarlar

• Sertifika zinciri genelde hassas değildir, ama private key hassastır.
• Private key içeren yedekleri mutlaka şifreleyin.

8) Yedekleme yaptım ama güvenli mi? “Doğrulama” ile karar verin

Şifrelediğinizi varsaymak yerine doğrulayın. Net bir doğrulama düzeni kurun.

Minimum doğrulama seti

• Açılıp okunabiliyor mu? (restore test)
• Bütünlük bozulmuş mu? (hash doğrulama)
• Şifreli dosya gerçekten şifreli mi? (tespit: dosya boyutu ve formatla kontrol; örn. gpg header)
• Yetkiler doğru mu? (bucket/pastaizin)

Doğrulama sıklığı

• Her yedek seti için: en az 1 restore doğrulama
• Her gün/hafta: örneklemeli restore
• Anahtar rotasyonu sonrası: restore zorunlu doğrulama

9) “Şifrele ve sakla” için hızlı seçim tablosu

Aşağıdaki tablo, karar vermeyi hızlandırır.

10) Sonuç ve aksiyon planı

Bugün “şifreli yedek” hedefini netleştirmek için tek bir aksiyon alın: depoya giden yedeği oluşturma anında şifreleyin, düz (şifrelenmemiş) arşivi mümkünse anında temizleyin ve her yedek seti için en az bir restore/okunabilirlik testi çalıştırın. Ardından anahtar yönetimini yazılı hale getirin: anahtar depodan ayrı, erişim kontrollü ve rotasyonlu olacak şekilde plan yapın. Bu üç adım tamamlandığında, yedekler sadece saklanan dosya olmaktan çıkar; kurtarma anında kullanılabilir ve ele geçirilse dahi okunamaz hale gelir.

İsterseniz kullandığınız ortamı (VDS/VPS, kontrol paneli, bulut depolama ve yedek aracı) yazın; aynı yaklaşımı sizin senaryonuza uyarlayıp net bir komut/otomasyon taslağı çıkarabilirim.