YEDEKLEME REHBERİ

TDE nedir? SQL Server şifreleme, yedek ve suistimal rehberi

TDE (Transparent Data Encryption), veritabanı dosyalarını diskte şifreleyen bir güvenlik özelliğidir. SQL Server’da TDE ile şifrelenen bir veritabanının yedeğini başka sunucuya geri yüklemek için ilgili sertifika ve özel anahtar da gerekir. Yalnızca .bak dosyasını saklamak yeterli değildir. TDE suistimali ise bu meşru özelliğin izinsiz kullanılarak yedeklerin saldırganın kontrolündeki anahtara bağımlı hale getirilmesidir.

Acil durum: Sertifika hatası veya izinsiz şifreleme fark ettiyseniz

Çalışan sistemde aceleyle sertifika silmeyin, TDE’yi kapatmayın veya SQL Server servisini yeniden başlatmayın. Önce SQL yöneticiniz ve olay müdahale ekibinizle durumu değerlendirin. Anahtar erişimi bozulduğunda yeniden başlatma canlı veritabanına erişimi de etkileyebilir.

Geri yükleme sırasında sertifika bulunamadığına ilişkin hata, tek başına saldırı kanıtı değildir. Hedef sunucuda sertifika ve özel anahtarın eksik olması veya farklı sertifika kullanılması da neden olabilir.

  1. Hata metnini, etkilenen veritabanını ve yedek zamanını kaydedin; anahtar veya parola paylaşmayın.
  2. Planlı TDE açılışı ya da sertifika yenilemesi olup olmadığını yetkili kişiden doğrulayın.
  3. Sertifika ve özel anahtarın güvenli yedeklerini bulun; erişim parolasını ve ilgili yedekle eşleşmesini kontrol ettirin.
  4. Mevcut yedekleri ve olay kayıtlarını koruyun; kullanılabilir eski kopyaların otomatik silinmesini yetkili süreçle durdurun.
  5. Üretim verisinin üzerine yazmadan, ayrı bir hedefte geri yükleme yolunu doğrulayın.

TDE neyi korur, neyi korumaz?

TDE’nin açılımı Transparent Data Encryption, Türkçesi Saydam Veri Şifreleme’dir. Bu rehber Microsoft SQL Server’daki uygulamayı ele alır. Temel amacı, veri ve günlük dosyalarını diskte şifreli tutmaktır. “Saydam” ifadesi, yetkili uygulamanın normal kullanımında şifre çözmenin veritabanı motorunca yönetilmesini anlatır.

TDE, veritabanına yetkili bir oturumla ulaşan kişinin erişim haklarını ortadan kaldırmaz. Ağ bağlantısı güvenliği, kullanıcı yetkileri, uç nokta koruması ve yedek saklama ayrı önlemlerdir. TDE açık olması, sistemin saldırıya kapalı olduğu veya yedeklerin otomatik olarak doğrulandığı anlamına gelmez.

Veritabanı çalışıyor ama yedek neden geri yüklenemiyor?

Çalışan sunucu şifreleme için gereken anahtarlara erişebilirken, geri yüklemenin yapılacağı sunucuda aynı anahtar zinciri bulunmayabilir. Bu nedenle uygulamanın bugün sorunsuz çalışması, farklı bir ortamda geri dönüşün de mümkün olduğunu kanıtlamaz.

Sertifika tabanlı SQL Server TDE kullanımında veritabanı şifreleme anahtarını koruyan sertifika ve özel anahtar geri dönüş planının parçasıdır. Sertifika yedeği, özel anahtar ve bunlara erişim bilgisi birbirinden farklı gereksinimlerdir. EKM gibi harici anahtar yönetimi kullanılan yapılarda sağlayıcı ve anahtar erişimi ayrıca değerlendirilmelidir.

TDE suistimali ve sessiz fidye senaryosu nasıl işler?

Saldırganın önce sunucu üzerinde bu değişikliği yapabilecek yetki elde etmesi gerekir. Ardından kendi kontrolündeki sertifikayla TDE’yi etkinleştirebilir veya anahtar koruma düzenini değiştirebilir. Uygulamanın çalışmayı sürdürmesi ve yedekleme görevlerinin tamamlanması değişikliği gözden saklayabilir.

Yeni yedekler anahtar bağımlılığını taşırken, eski temiz kopyalar saklama politikasıyla zaman içinde azalabilir. Gerekli anahtar erişilemez hale geldiğinde saldırgan geri dönüş imkânı üzerinden baskı kurabilir. “Sessiz fidye” ifadesi bu senaryodaki gecikmiş farkındalığı anlatır; her TDE değişikliğinin saldırı olduğu anlamına gelmez.

Bu nedenle yalnız yedekleme işinin başarı durumunu izlemek yeterli değildir. Şifreleme durumunun, sertifika değişikliklerinin ve korunmuş eski yedeklerin de takip edilmesi gerekir.

TDE, yedek şifreleme ve buluta aktarım şifrelemesi aynı şey mi?

TDE, veritabanının diskteki dosyalarını korur. SQL Server yedek şifrelemesi ise yedek oluşturma işleminde ayrıca seçilebilen bir korumadır. Bulut yedekleme aracının arşivi şifrelemesi ve aktarım kanalının güvenliği de başka katmanlardır. Bir yedek birden fazla şifreleme katmanına sahip olabilir.

Yedekleme aracının dış arşiv şifresini çözebilmesi, içindeki SQL Server yedeğinin TDE sertifikası ihtiyacını kaldırmaz. Geri dönüş tatbikatı yalnız indirmeyi değil, SQL Server’da gerçekten geri yüklemeyi de kapsamalıdır.

Güvenli TDE kullanımı için kontrol listesi

TDE’yi kapatmak genel bir güvenlik çözümü değildir. Amaç, meşru şifrelemeyi yönetilebilir anahtarlar, izlenebilir değişiklikler ve denenmiş geri yükleme adımlarıyla birlikte kullanmaktır.

  1. TDE açma ve sertifika değiştirme yetkilerini ihtiyaca göre sınırlandırın; yetkili değişiklikleri kayıt altına alın.
  2. Sertifika ve özel anahtar yedeğini güvenli biçimde alın. Erişim bilgisini yedek dosyasıyla aynı korumasız konumda tutmayın.
  3. Anahtar yedeklerini yalnız üretim sunucusuna bağımlı bırakmayın; erişim yetkilerini ve kurtarma sorumlusunu belirleyin.
  4. Sertifika değişikliğinde eski yedeklerin ihtiyaç duyduğu eski anahtarları saklama planına dahil edin.
  5. Şifreleme durumu ve sertifika değişikliklerini izleyin; okunamayan durumu sağlıklı kabul etmeyin.
  6. Temiz eski kopyaları koruyan saklama politikası oluşturun ve farklı bir SQL Server ortamında geri yükleme testi yapın.
  7. Test edilen yedek tarihi, anahtar gereksinimi, test sonucu ve sorumlu kişiyi kaydedin.

Yedeğin kullanılabilirliğini nasıl sınarsınız?

Hedef SQL Server sürümü, boş alan, sertifika ve özel anahtar erişimi hazırlanmış ayrı bir test ortamı kullanın. İlgili yedeği geri yükleyin, veritabanı bütünlüğünü kontrol edin ve işinize özgü uygulama testini ayrıca planlayın. Canlı veritabanının üzerine yazmak bir test yöntemi olarak kullanılmamalıdır.

Dosyanın var olması, indirilebilmesi, veritabanının geri yüklenmesi ve uygulamanın çalışması farklı sonuçlardır. Bir kontrolün başarıyla bitmesini diğerlerinin de yapıldığı şeklinde yorumlamayın.

Kladim TDE Guard ve Restore Proof bu süreçte ne yapar?

Kladim TDE Guard, SQL Server şifreleme durumu ve sertifikayı her yedekten önce kontrol eder; yedek sonrasında dosyayı da inceler ve saatte bir bağımsız kontrol yapar. Şüphede temiz bulut yedeklerini kilitler, yeni yedekleri işaretler ve bildirim verir. Saldırıyı durduran veya kayıp anahtarı yeniden üreten bir araç değildir.

Restore Proof (Yedek Sağlığı Doğrulama), etkin kapsamda SQL Server yedeğini ayrı test ortamına geri yükler ve DBCC CHECKDB bütünlük kontrolü uygular. Klasör yedeklerinde dönüşümlü örnek dosyaları kontrol eder. Sonuç, test edilen yedek ve belirtilen kapsam içindir; işletmenin tüm uygulamalarını kapsayan bir felaket kurtarma garantisi değildir.

Sık sorulan sorular

TDE fidye yazılımı mıdır? Hayır. TDE meşru bir şifreleme özelliğidir; risk, yetkisiz kişilerce kötüye kullanılmasıdır.

Sertifika olmadan TDE yedeği geri yüklenebilir mi? Sertifika tabanlı senaryoda gereken sertifika ve özel anahtar ya da bunları güvenli biçimde geri getirecek anahtar zinciri olmadan normal geri yükleme tamamlanamaz. Önce güvenli anahtar yedeklerini araştırın.

Sertifika değiştiyse bütün eski yedekler işe yaramaz mı? Eski yedekler kendi oluşturuldukları anahtar düzenine ihtiyaç duyabilir. İlgili eski sertifika ve özel anahtarlar saklandıysa kullanılabilirlik test edilebilir; yeni sertifikayı saklamak tek başına yeterli olmayabilir.

TDE’yi kapatmak anahtar saklama ihtiyacını bitirir mi? Önceden alınmış şifreli yedekler için gereken anahtarları korumaya devam etmelisiniz.

Bulutta kopya olması yeterli mi? Hayır. Kopyanın korunması, gerekli anahtarlara erişim ve ayrı ortamda geri yükleme denemesi birlikte değerlendirilmelidir.

Teknik kaynaklar

Motorun geri yükleme ayrıntıları için kullandığınız sürümün resmî belgesini esas alın.

↑