Yedekleri Şifreleyerek Saklama Yöntemleri: Net Rehber

Yedek (backup) almak tek başına yeterli değildir; yedeğin güvenliği, erişim yetkileri ve şifreleme yaklaşımı gerçek farkı yaratır. Çünkü bir sunucu hatası, veri sızıntısı ya da yanlışlıkla silme durumunda geri dönüşün “çalışır” ve “güvenli” olması gerekir. Bu rehberde yedekleri şifreleyerek saklamanın en net yöntemlerini; at-rest (saklama anında) ve in-transit (aktarırken) katmanlarıyla ele alacağız. Ayrıca anahtar yönetimi, test/geri yükleme doğrulaması ve pratik kontrol listesiyle kararınızı hızlandıracağız.

Şifrelemenin hedefi: hangi riskleri kapatıyoruz?

Yedek şifrelemesinin amacı iki temel riski azaltmaktır: - Depolama ortamında erişim: Yedek dosyası bir bulut depoya, NAS’a ya da harici diske kopyalandığında, depoya erişen biri veriyi doğrudan okuyamasın. - Aktarım sırasında ele geçirilme: Yedek dosyaları ağ üzerinden taşınırken (VDS → depolama, VPS → S3 uyumlu servis vb.) üçüncü kişiler içerikleri göremesin.

Bu nedenle şifrelemeyi tek bir ayar olarak değil, uçtan uca bir sistem gibi düşünün: - Yedek dosyası saklanırken şifreli olacak (at-rest) - Yedek dosyası aktarılırken şifreli olacak (in-transit) - Şifreyi çözecek anahtarlar ise erişimi kısıtlı ve denetlenebilir olacak (key management)

At-rest mi in-transit mi? Net ayrım

• At-rest şifreleme: Yedek dosyası depoya yazılırken şifreli olur. Depoya izinsiz erişim riskine karşı korur.
• In-transit şifreleme: Yedek ağ üzerinden taşınırken şifreli kanaldan gider (ör. TLS). Aynı depoya erişim olmasa bile taşıma sırasında veri okunamaz.

İyi uygulama: Her iki katmanı da uygulamaktır. Örneğin “sadece TLS var, depoda şifre yok” yaklaşımı, depoya yanlışlıkla erişim olursa veriyi korumaz.

Yedek şifreleme yöntemleri (pratikte 3 ana yol)

Aşağıdaki yöntemler, kullanıcıların en sık seçtiği ve yönetmesi net olan seçeneklerdir. “En iyi”yi tek bir cümleyle değil, senaryoya göre seçmek gerekir.

1) Depo seviyesinde şifreleme (ör. S3 sunucu tarafı şifreleme)

Bazı bulut depolarında server-side encryption (SSE) bulunur. Dosyalar depoya yazılırken sistem şifreler, okuma sırasında uygun yetkiyle otomatik çözer.

Artılar - Uygulama tarafında genellikle az ek kurulum - Trafik için ayrıca TLS kullanımı çoğu zaman zaten açık olur

Eksiler (net risk noktaları) - Şifreleme anahtarlarına dair kontrol sınırlı kalabilir - Uygulama (yedek alma aracı) tarafında “yedek dosyası gerçekten şifreli mi?” doğrulaması zorlaşır

Ne zaman seçilir? - Şifreleme yönetimi gereksiniminiz düşükse ve bulut sağlayıcı SSE detaylarını net okuyabiliyorsanız.

2) Dosya/ark seviyesinde şifreleme (yedek dosyasını siz şifreleyin)

Burada yedek alma aracınız ya da süreç, arşivi oluşturmadan önce/oluştururken şifreler. Sonuçta depoya giden veri “zaten şifreli dosya” olur.

Örnek senaryo: /home dizinini arşivleyip sonra şifreleyerek (ya da yedek aracı içinde şifreleme özelliğiyle) depoya aktarın.

Artılar - Depoya erişen kişi bile yedeği okuyamaz - Şifreleme standardı ve anahtar yönetimi yaklaşımı daha kontrol edilebilir

Eksiler - Geri yükleme adımlarında şifre çözme anahtarı/erişimi kritik olur - Anahtar kaybı geri yüklemeyi fiilen durdurur

Ne zaman seçilir? - “Depo sağlayıcının yetkisiyle değil, kendi anahtarım ile güvence” yaklaşımı istiyorsanız.

3) İstemci tarafı şifreleme + anahtar yönetimi (en güçlü kontrol)

Bu, 2. yöntemin anahtar yönetimi odaklı ilerletilmiş halidir. Şifreleme anahtarları tek bir sunucuya gömülmez; erişimi sınırlı bir süreçle yönetilir.

Bu yaklaşımda hedef şudur: - Anahtarlar depodan ayrı saklanır (ve erişimi dar tutulur) - Anahtar rotasyonu (rotation) planlanır - Yedek doğrulama testlerinde şifre çözme akışı denenir

Ne zaman seçilir? - Kurumsal gereksinimler (denetim, olay müdahalesi, erişim kontrolü) varsa

Şifreleme yaparken mutlaka çözmeniz gereken 4 konu

Yedek şifreleme “dosyayı şifrele” kadar basit değildir. Aşağıdaki 4 başlık, uygulamada karar verdirir.

1) Anahtarları nerede ve nasıl saklıyorsunuz?

En sık yapılan hata: şifreleme anahtarının aynı sunucuda, erişimi kısıtlanmamış bir dosyada tutulması.

Net hedef: - Anahtar, yedeğin saklandığı depoya aynı kimlik/aynı erişim paketinde bağlanmamalı - Anahtar erişimi; ayrı bir süreç, ayrı izin ve loglama ile yönetilmeli

Anahtar yönetimi için pratik seçenekler: - Bulut KMS (Key Management Service) kullanımı (mevcutsa) - Şifreyi sadece belirli ortam değişkenlerinde (environment variable) tutma + erişim kısıtı - Gizli bilgiyi (secret) bir secret manager ile yönetme

2) Şifreleme algoritması ve format seçimi

İki hedef var: güvenlik ve geri yükleme kolaylığı. - Şifreleme türü: doğrulanabilir ve standart bir yöntem (ör. modern AES tabanlı uygulamalar) - Arşiv formatı: şifre çözme süreci otomasyona uygun olmalı

Kritik pratik: Şifreli yedeği “bir kere” açıp doğrulayın; rutin işlemlerde bu adımı atlamayın.

3) Anahtar rotasyonu ve kurtarma senaryosu

Anahtar rotasyonu şu anlama gelir: Yeni yedekler yeni anahtarla şifrelenir; eski yedekler eski anahtarla çözülür.

Net kural: - En azından şu iki şeyi dokümante edin: 1) Hangi yedek hangi anahtarla şifrelenmiş? 2) Geri yükleme sırasında hangi adımda anahtar seçiliyor?

4) Yedek bütünlüğü ve doğrulama (restore test)

Şifreli yedek “dosya var” demek değildir. Şunları rutinleştirin: - Yedek oluşturma sonrası boyut/sha kontrolü - Şifreli arşivi bir test ortamında açma - Uygulama seviyesinde geri yükleme testi (ör. DB için bir dump restore kontrolü)

Yedekleri şifreleyerek saklama için net mimari örnekler

Aşağıdaki mimariler, gerçek hosting/VDS kullanımında sık görülen akışları temsil eder.

Örnek A: VDS → S3 uyumlu depoya şifreli arşiv

• Yedek aracı arşivi oluşturur
• Arşiv dosyası şifrelenir
• Şifrelenmiş dosya depoya TLS üzerinden aktarılır
• Depoda şifreleme ek katmanı varsa (SSE gibi) bu ikinci bir koruma olur
• Anahtarlar depoda değil, kısıtlı bir secret yönetiminde tutulur

Bu akışta en net kontrol noktaları: - Depoya yazılan dosyanın “okunabilir içerik” üretmemesi - Geri yükleme sırasında şifre çözme adımının otomasyonla çalışması

Örnek B: VPS’te veritabanı + şifreli yedek akışı

DB yedeklerinde (MySQL/MariaDB/PostgreSQL gibi) iki tür yedek yaklaşımı görülür: - Dump (SQL/Custom format) dosyaları - Volume snapshot gibi disk tabanlı yöntemler

Dump yaklaşımıyla şifrelemeyi uygulamanın avantajı: Yedek dosyasının kendisini şifreleyebilmeniz.

Net kontrol: - Şifreli dump dosyasının restore edilebilir olduğundan emin olmak - “Restore test”in şifre çözmeden bağımsız bozulmadığını görmek

Örnek C: Özel depolama/NAS ile şifreli yedek

Yerel depolamada da şifreleme at-rest mantıklıdır. - Yedek dosyası şifreli yazılır - Ağ erişimi mümkün olsa bile yedek içerik okunamaz - Yetkisiz kullanıcıların erişimini dosya izinleri ve ağ ACL’leriyle ayrıca kısıtlayın

Kontrol listesi: Güvenli yedekleme için 12 net madde

Aşağıdaki listeyi, mevcut kurulumunuzda tek tek işaretleyin.

1. Yedek dosyası at-rest şifreli mi?
2. Yedek aktarımı in-transit TLS ile mi yapılıyor?
3. Şifreleme anahtarı depodaki aynı erişimle ele geçirilebilir durumda mı değil mi?
4. Anahtarlar üretimde düz metin dosya olarak saklanmıyor mu?
5. Anahtar rotasyonu planlanmış mı (dokümante mi)?
6. Şifreli yedek geri yükleme (restore) prosedürü yazılı mı?
7. Restore testi belirli sıklıkta yapılıyor mu?
8. Yedek bütünlüğü (hash/size) kontrol ediliyor mu?
9. Yedekleme logları (başarılı/başarısız) saklanıyor mu?
10. Yedekleme kullanıcı yetkileri en düşük yetki (least privilege) ilkesine uygun mu?
11. Yedeklerin yaşam döngüsü net mi (retention süresi, otomatik silme)?
12. Şifreli yedeklerin boyutu ve performans etkisi izleniyor mu?

Yaygın hatalar ve net düzeltmeler

Hata 1: Sadece bulut depo “şifreler” diyerek yetinmek

Düzeltme: Depoya giden verinin gerçekten şifreli içerik ürettiğini doğrulayın (ör. şifreli dosyayı deneyerek açma/okuma testleri).

Hata 2: Şifreleme anahtarını aynı sunucuda herkesin erişebileceği yerde tutmak

Düzeltme: Anahtar erişimini kısıtlayın; secret manager/KMS gibi yöntemlerle erişimi daraltın.

Hata 3: Restore testini yalnızca “dosyayı indirdim” seviyesinde bırakmak

Düzeltme: Şifre çözme dahil tam restore akışını periyodik test edin.

Hata 4: Yedek şifreleme algoritması belirsiz/eskimiş yöntemler

Düzeltme: Standart ve modern şifreleme yaklaşımı kullanın; dokümante edin.

Doğru yöntemi seçmek için net karar tablosu

Aşağıdaki tablo, hangi yöntemin hangi koşullarda daha rasyonel olduğunu özetler.

Sonuç: Bugün uygulanabilecek aksiyon planı

İlk adım olarak mevcut yedek akışınızda at-rest ve in-transit şifrelemenin çalıştığını kontrol edin; ardından şifreleme anahtarının nerede ve kim tarafından erişilebilir olduğunu netleştirin. En hızlı kazanım için: şifreli yedek alın, bir kez şifre çözerek geri yükleyin ve bu restore testini takvimlendirin. İsterseniz bir sonraki adım olarak yedek retention (saklama süresi) ve anahtar rotasyon dokümantasyonunu oluşturun; böylece hem güvenlik hem de geri dönüş hızı aynı anda artar.