Yedek Şifreleme ve Anahtar Yönetimi: Kayıp ve Saldırı Riskleri

Yedek şifreleme, depodan veya taşınan medyadan veri sızmasını engeller; anahtar kaybolduğunda ise yedeğin kendisini çöpe çevirir. Fidye senaryosunda iş daha da sertleşir: saldırgan yalnız yedekleri silmeye değil, şifreleme ayarını kendi lehine değiştirmeye de uğraşır. Bu rehber; şifreleme noktalarını, anahtar yönetim modellerini, anahtar saklama ve emanet kurallarını ve anahtar kurtarma testini yedek altyapısını işleten ekiplerin gözünden anlatır.

Yedek şifrelemenin amacı ve riskleri

Yedek dosyası, kurumdaki neredeyse her verinin tek bir yerde toplanmış kopyasıdır. Bir sanal makine yedeğinden etki alanı denetleyicisinin ntds.dit dosyası, bir dosya sunucusu yedeğinden kişisel veriler, bir SQL yedeğinden müşteri kayıtları çıkarılabilir. Saldırgan için yedek hem sızdırılacak hem silinecek hedeftir. Değiştirilemez depolama silmeye karşı korur, okunmaya karşı korumaz. Bu boşluğu şifreleme kapatır.

Şifrelemenin getirdiği riskler üç başlıkta toplanır:

• Anahtar kaybı: Parola yalnız yedek sunucusunda veya etki alanına bağlı bir parola kasasında tutuluyorsa, saldırı sonrası bu kaynaklar kullanılamaz ve yedekler açılamaz.
• Anahtarın yedekle birlikte ele geçirilmesi: Anahtar yedek konsolunun veritabanında, aynı sunucuda veya aynı yönetici hesabının erişebildiği yerde duruyorsa şifreleme sızıntıya karşı anlamlı koruma sağlamaz.
• Saldırganın şifrelemeyi silaha çevirmesi: Konsolu ele geçiren saldırgan, işlerin şifreleme parolasını kendi belirlediği bir parolayla değiştirebilir. Bu konu aşağıda ayrıca ele alınıyor.

Şifreleme noktaları: kaynak, aktarım, depo

Yedek verisi üç noktada şifrelenebilir, her biri farklı bir tehdide cevap verir. Hangi katmanın neyi koruduğunu bilmeden “yedeklerimiz şifreli” demek yanıltıcıdır. Denetimde en sık duyduğumuz cümle budur.

Nokta	Nasıl uygulanır	Neye karşı korur	Neye karşı korumaz
Kaynakta (iş düzeyi)	Yedek yazılımı veriyi depoya yazmadan önce şifreler	Depo, teyp ve bulut kopyasının okunması	Konsolu ele geçiren yöneticinin geri yüklemesi
Aktarımda	Bileşenler arası TLS veya ağ trafiği şifrelemesi	Ağ üzerinde dinleme	Depoda duran veriye erişim
Depoda (bekleyen veri)	Disk/dizi şifrelemesi, nesne depolamada sunucu tarafı şifreleme	Fiziksel disk veya cihaz kaybı	Depoya yetkili erişimle okunan veri

Depo düzeyinde şifreleme (örneğin S3 uyumlu depolamada sunucu tarafı şifreleme) çoğunlukla şeffaftır: depoya yetkili erişimi olan her süreç veriyi düz metin olarak okur. Bu yüzden bulut veya üçüncü taraf depoya giden kopyalarda iş düzeyi şifreleme, depo şifrelemesinin yerine değil üstüne eklenir. Teyp kullanıyorsanız LTO sürücü şifrelemesi mi yazılım şifrelemesi mi kullanıldığını ve anahtarı kimin yönettiğini açıkça yazın. Yoksa yıllar sonra okunması gereken bir kartuşun anahtarı bulunamaz. Teyp rafta durur, anahtar kaybolur.

Parola tabanlı ve KMS tabanlı anahtar yönetimi

Yedek ürünlerinin çoğu iki model sunar. Parola tabanlı modelde yönetici her iş veya depo için bir parola belirler; yazılım anahtarı bu paroladan türetir. KMS tabanlı modelde anahtarlar harici bir anahtar yönetim sisteminde (şirket içi KMIP sunucusu, HSM ya da bulut KMS) üretilir ve yedek yazılımı anahtarı oradan ister. Veeam Backup & Replication gibi ürünlerde iki model de var; KMS desteğinin kapsamı sürüme göre değiştiği için kendi sürümünüzün dokümantasyonundan doğrulayın.

Ölçüt	Parola tabanlı	KMS tabanlı
Kurulum	Basit, ek altyapı yok	KMS, sertifika ve erişim politikası gerekir
İnsan hatası	Zayıf parola, paylaşım, kayıt unutma	Daha az; anahtar insan eline geçmez
Saldırı sonrası bağımlılık	Parolanın bant dışı kaydına	KMS’nin ayakta ve erişilebilir olmasına
Saldırganın etkisi	Konsoldan parolayı değiştirebilir	KMS yetkisi varsa anahtarı devre dışı bırakabilir
Uygun olduğu yer	Küçük ve orta ölçekli, az sayıda iş	Çok sayıda iş, uyum gereksinimi, merkezi denetim

KMS seçildiyse asıl soru KMS’nin kendisinin nasıl kurtarılacağıdır. KMS sanal makinesi aynı hipervizör kümesinde, aynı etki alanına bağlı ve aynı yedek işiyle yedekleniyorsa döngüsel bağımlılık oluşur: yedekleri açmak için KMS gerekir, KMS’yi geri yüklemek için de yedek. Kilit kendi kutusunun içinde kalır. KMS’nin anahtar materyalini yedek altyapısından bağımsız, çevrimdışı bir kopya olarak da saklayın.

Parola tabanlı modelde parola uzun ve rastgele olmalı; anahtar türetme işlemi zayıf bir parolayı güçlendirmez. Parola kasasında üretilmiş, en az 20 karakterlik rastgele parolalar kullanmak ve her parolaya kimin erişebildiğini kayda geçirmek pratik bir başlangıçtır. Sahada sık rastladığımız hata, tüm işlerde aynı, ezbere bilinen tek parolanın yıllarca kullanılmasıdır.

Anahtarların ayrı saklanması ve emanet

Kurumsal siber güvenlik açısından anahtar yönetiminin temel kuralı şudur: anahtar, koruduğu veriyle aynı güven alanında durmaz. NIST SP 800-57, anahtarın tüm yaşam döngüsü (üretim, dağıtım, saklama, arşiv, imha) için ayrı kontroller tanımlar. Yedek senaryosunda en çok ihmal edilen aşama arşivdir. Planlı bir değişimden sonra eski parola silinirse, saklama süresi içindeki eski geri yükleme noktaları açılamaz.

İşleyen bir emanet düzeni şu unsurları içerir:

• İki ayrı kopya: Biri günlük işletim için kurumsal parola kasasında, diğeri etki alanından ve kurumsal ağdan bağımsız bir ortamda (mühürlü zarf içinde kasa, ayrı kimlikle yönetilen çevrimdışı parola kasası veya donanım anahtarıyla korunan şifreli dosya).
• Bölünmüş bilgi: Kritik anahtarlarda iki kişi kuralı uygulanabilir; örneğin parolanın iki yarısı iki farklı yöneticide durur veya kasayı açmak için iki onay gerekir.
• Sürüm kaydı: Her parola veya anahtar için geçerlilik başlangıcı, hangi işlerde kullanıldığı ve hangi tarihe kadar saklanması gerektiği yazılır.
• Merkezi kurtarma özelliği: Bazı ürünler parola kaybı koruması sunar (Veeam’de Enterprise Manager üzerinden). Bu özellik kullanılıyorsa, ilgili sunucunun anahtar materyali de aynı ayrım kurallarına tabidir.

Anahtar kaydı için basit ama eksiksiz bir şablon:

Anahtar kimliği     : YDK-2026-03
Kapsam              : Bulut kopya işleri (BCJ-*), teyp havuzu TP-AYLIK
Geçerlilik başlangıcı: 2026-03-01
Yerine geçtiği      : YDK-2025-09
Saklama bitişi      : Bu anahtarla yazılmış son noktanın saklama süresi + 30 gün
Birincil konum      : Kurumsal parola kasası / Yedek-Anahtarlar klasörü
İkincil konum       : Çevrimdışı kasa, zarf no 14
Erişim              : Yedek sorumlusu + bilgi güvenliği sorumlusu (iki onay)
Son kurtarma testi  : 2026-06-12, başarılı

Saldırganın şifreleme ayarını değiştirmesi riski

Yedek konsoluna yönetici yetkisiyle giren saldırgan her zaman yedekleri silmeye kalkmaz. Değiştirilemez depoda silme başarısız olur ve alarm üretebilir. Daha sessiz yol, iş ayarlarında şifrelemeyi açmak ya da parolayı saldırganın bildiği bir parolayla değiştirmektir. O andan sonra alınan her yedek saldırganın anahtarıyla yazılır; eski geri yükleme noktaları saklama süresi dolup silindikçe, kurumun elinde açabileceği yedek kalmaz. Değiştirilemezlik bunu engellemez, çünkü yedek silinmiyor, okunamaz biçimde yazılıyor. Yedek var, ama sizin değil.

Bulut KMS kullanılan mimarilerde benzer yol, anahtarın devre dışı bırakılması veya silinmeye zamanlanmasıdır. AWS KMS’de anahtar silme 7 ile 30 gün arasında bir bekleme süresiyle zamanlanır; bu süre içinde iptal edilebilir, fark edilmezse anahtarla şifrelenmiş tüm veri kalıcı olarak okunamaz hale gelir. Aşağıda, anahtar silme ve devre dışı bırakma yetkisini kurtarma amaçlı ayrı bir rol dışında herkesten kaldıran bir kuruluş politikası (SCP) örneği var. SCP’ler AWS Organizations yönetim hesabına uygulanmaz; bu yüzden anahtarları üye hesaplarda tutun:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyBackupKeyDestruction",
      "Effect": "Deny",
      "Action": ["kms:ScheduleKeyDeletion", "kms:DisableKey"],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/BreakGlass-KeyAdmin"
        }
      }
    }
  ]
}

Bu riske karşı kontroller:

• Yedek konsolunda şifreleme ayarlarını değiştirme yetkisini yalnız ayrı bir role verin; günlük operatör rolü bu ayarı görmesin. Kimlik ayrımının bütününü yedek altyapısında kimlik izolasyonu rehberi ele alır.
• Ürün destekliyorsa kritik ayar değişikliklerinde dört göz onayını açın.
• İş şifreleme ayarlarının ve parola değişikliklerinin olay kaydını SIEM’e aktarın; beklenmeyen değişiklikte yüksek öncelikli alarm üretin. İzlenecek diğer olaylar yedek altyapısına yönelik saldırı belirtileri yazısında listelenir.
• Bulut KMS için ScheduleKeyDeletion ve DisableKey çağrılarını CloudTrail üzerinden izleyin.

Şifreleme ayarlarının güncel durumunu periyodik olarak bir referansla karşılaştırmak da işe yarar. Veeam Backup & Replication PowerShell modülüyle iş bazında şifreleme durumunu listeleyen örnek (özellik adları sürüme göre farklılık gösterebilir, kendi ortamınızda doğrulayın):

Get-VBRJob | Select-Object Name,
  @{n='Sifreleme';e={$_.GetOptions().BackupStorageOptions.StorageEncryptionEnabled}} |
  Sort-Object Name | Export-Csv C:\Raporlar\yedek-sifreleme.csv -NoTypeInformation -Encoding UTF8

Bu çıktıyı her hafta bir önceki haftayla karşılaştırın; şifrelemesi beklenmedik biçimde açılan veya kapanan iş hemen göze çarpar. Basit bir fark (diff) yeter.

Anahtar kurtarma testi

Rutin geri yükleme testleri çoğunlukla yedek sunucusu çalışırken yapılır; yazılım anahtarı zaten bildiği için parola hiç sorulmaz. Bu test, anahtarın gerçekten kurtarılabilir olduğunu kanıtlamaz. Anahtar kurtarma testinde yedek sunucusu ve kurumsal kimlik altyapısı yokmuş gibi davranılır; yalnız yedek dosyaları ve emanetteki anahtarla veri açılmaya çalışılır.

1. İzole bir ağda, etki alanına bağlı olmayan temiz bir sunucuya yedek yazılımını kurun.
2. Değiştirilemez depodan veya çevrimdışı kopyadan bir yedek zincirini içe aktarın.
3. Parolayı veya anahtarı yalnız çevrimdışı emanet kopyasından alın; kurumsal parola kasasına bağlanmayın.
4. Bir sanal makineyi veya dosya kümesini geri yükleyin ve içeriğin okunabildiğini doğrulayın.
5. KMS kullanılıyorsa aynı testi KMS’nin yedekten veya ikincil kopyadan ayağa kaldırılmasıyla birlikte yapın.
6. Kullanılan anahtar kimliğini, süreyi ve karşılaşılan engelleri anahtar kaydına işleyin.

Bu testte en sık çıkan sorunlar: emanetteki parolanın güncel olmaması, eski anahtarların arşivlenmemiş olması, çevrimdışı kasaya kimin erişebildiğinin belirsizliği ve KMS’yi geri yüklemek için gereken sertifikaların yalnız üretim ortamında bulunması. Test, kapsamlı siber kurtarma tatbikatı senaryosunun parçası olarak da yürütülebilir; tatbikatın kimlik kaybı varyasyonu anahtar erişimini zaten sınar.

Uygulama kontrol listesi

• Kurum dışına veya ayrı bir ortama giden her yedek kopyası iş düzeyinde şifreli mi?
• Her anahtarın en az bir kopyası etki alanı, kurumsal e-posta ve yedek sunucusundan bağımsız bir yerde mi?
• Değiştirilen eski anahtarlar, ilgili saklama süresi bitene kadar arşivde mi?
• Şifreleme ayarlarını değiştirebilen hesaplar sınırlı ve kayıt altında mı?
• Şifreleme ayarı ve KMS anahtar durumu değişiklikleri alarm üretiyor mu?
• Son anahtar kurtarma testi ne zaman yapıldı ve sonucu kaydedildi mi?

Şifreleme, değiştirilemezlik ve çevrimdışı kopya birlikte tasarlandığında yedek hem sızıntıya hem silmeye karşı korunur; genel hazırlık çerçevesi için fidye yazılımına karşı kurtarma hazırlığı yazısına bakın. Mevcut mimarinizin anahtar yönetimini bağımsız bir gözle değerlendirmek isterseniz yedekleme güvenliği ve fidye yazılımına hazırlık hizmetimizin kapsamını inceleyebilirsiniz.

Anahtar yaşam döngüsüne ilişkin birincil kaynak: NIST SP 800-57 Part 1 Rev. 5.

Sık sorulan sorular

Yedek şifreleme parolası unutulursa yedekler kurtarılabilir mi?

Şifreleme doğru uygulanmışsa yazılım üreticisi dahil kimse parolasız veriyi açamaz. Bazı ürünler merkezi yönetim sunucusu üzerinden parola kaybı koruması sunar; bu özellik etkin değilse ve parola kayıtlı değilse, o parolayla şifrelenmiş tüm geri yükleme noktaları kaybedilmiş sayılır.

Değiştirilemez depoya yazılan yedeği ayrıca şifrelemek gerekir mi?

Gerekir. Değiştirilemezlik silme ve değiştirmeye karşı korur, okumaya karşı korumaz. Depoya veya kopya ortamına erişen biri, şifrelenmemiş yedekten veritabanlarını, e-posta kutularını ve parola hash’lerini çıkarabilir. İki kontrol farklı tehditlere cevap verir; birlikte kullanın.

Yedek şifreleme anahtarı ne sıklıkla değiştirilmeli?

Sabit takvimden çok olaya bağlı değişim belirleyicidir: anahtara erişimi olan kişinin ayrılması, sızıntı şüphesi veya yedek altyapısında güvenlik olayı. Planlı değişimde eski anahtarları, onlarla şifrelenmiş son geri yükleme noktası saklama süresinden çıkana kadar arşivde tutun.

KMS kullanmak parola tabanlı yönetimden her zaman daha mı güvenlidir?

Hayır. KMS insan hatasını ve parola paylaşımını azaltır, ama yedeğin açılmasını KMS’nin erişilebilir olmasına bağlar. KMS etki alanına veya üretim bulut hesabına bağlıysa saldırgan anahtarı devre dışı bırakarak yedekleri kullanılmaz hale getirebilir. Doğru seçim, KMS’nin yedek altyapısından ayrı kimlikle yönetilmesine bağlıdır.