Destek Alın
GÜVENLİK DUYURUSU — VERİTABANI

TDE saldırısı (sessiz fidye): yedekleriniz sessizce zehirleniyor olabilir

21 Ekim 2026 • SQL Server • Transparent Data Encryption (TDE) suistimali
Özet: Son dönemde görülen "sessiz fidye" saldırılarında saldırgan zararlı yazılım kullanmıyor; SQL Server'ın kendi güvenlik özelliği olan Transparent Data Encryption (TDE)'yi kendi sertifikasıyla devreye alıyor ve anahtarı alıp gidiyor. Sistem aylarca normal çalışıyor, yedekler "başarılı" görünüyor — ama sertifika olmadan o yedeklerin hiçbiri geri açılamıyor. Fark ettiğiniz gün, elinizde kullanılabilir tek bir yedek kalmamış olabilir.

TDE nedir?

TDE; SQL Server, Oracle ve MySQL/MariaDB gibi veritabanlarında veriyi disk üzerinde şifreli tutan meşru bir özelliktir. Veritabanı dosyaları çalınsa bile içerik okunamaz. Şifreleme bir anahtar zincirine dayanır: Service Master Key → Database Master Key → sertifika → Database Encryption Key (DEK). Kritik nokta şudur: TDE'li bir veritabanını başka bir sunucuya geri yüklemek için aynı sertifikanın özel anahtarıyla birlikte hedefte yüklü olması zorunludur; yoksa restore, "Cannot find server certificate with thumbprint..." hatasıyla başarısız olur. Saldırının tamamı bu zorunluluğun üzerine kurulu.

Saldırı nasıl çalışıyor?

  1. Erişim: Saldırgan zayıf/çalınmış bir parola, açık bir port veya yamalanmamış bir açıktan sunucuya ve SQL Server'a yönetici erişimi alır.
  2. Şifreleme: Kendi oluşturduğu bir sertifikayla veritabanlarında TDE'yi etkinleştirir. Ortada zararlı yazılım yoktur; sistemin kendi normal komutları çalışır, güvenlik araçları alarm vermez.
  3. Anahtarı alma: Sertifikayı ve özel anahtarı yedekleyip kendi tarafına kopyalar, sunucudaki izleri siler.
  4. Soğuk hazırlık: Hemen fidye istemez; 30–90 gün bekler. Bu sürede alınan tüm tam, fark ve log yedekleri saldırganın anahtarıyla şifrelenmiş veriyi yedekler; eski temiz yedekler saklama süresi doldukça silinir. Replikasyon/DR tarafları da senkronize oldukça zehir her yere yayılır.
  5. Fidye: Ortaya çıktığında sertifika karşılığında ödeme ister. Sertifika yoksa teknik olarak geri dönüş yoktur.

Klasik yedekleme neden yakalayamıyor?

  • Yedekleme yazılımı, yedeğin bütünlüğünü doğrular; içindeki verinin açılabilir olduğunu doğrulamaz. Şifreli veri de "başarılı yedek" sayılır.
  • Sistem çalışmaya devam eder: uygulamalar, bağlantılar, performans — her şey normal görünür.
  • Saldırgan meşru özellikleri kullandığı için antivirüs/EDR tarafında klasik bir "şifreleme saldırısı" imzası oluşmaz.

Hemen kontrol edin

SQL Server'ınızda şu iki sorguyu çalıştırın:

SELECT name, is_encrypted FROM sys.databases; — Beklemediğiniz bir veritabanında is_encrypted = 1 görürseniz araştırın.

SELECT name, subject, start_date, expiry_date FROM sys.certificates; — Tanımadığınız, özellikle yakın tarihte oluşturulmuş sertifikalar tehlike işaretidir.

Ayrıca en az bir yedeği farklı bir sunucuya test amaçlı geri yükleyin; aynı sunucuda restore etmek sertifika zaten yüklü olduğu için sorunu gizler.

⚠️ Önemli notlar

Sertifika yedeği her şeydir: TDE kullanıyorsanız sertifikanızı özel anahtarıyla birlikte (BACKUP CERTIFICATE ... WITH PRIVATE KEY) şifreli ve sunucu dışında, çevrimdışı/güvenli bir kasada saklayın. Bu yedek yoksa felaket anında teknik kurtarma ihtimali kalmaz.
SQL Server Express'te TDE yok: Express sürümü TDE desteklemez; bu sürümde benzer bir durum yaşıyorsanız saldırı dosya şifreleme gibi farklı bir yöntemle yapılmış demektir, ona göre araştırın.
Uzun saklama süresi hayat kurtarır: Saldırı 30–90 gün sessiz kaldığı için yalnızca son birkaç günün yedeğini tutmak yetmez. Aylık arşiv kopyalarını en az 3–6 ay, mümkünse değiştirilemez (immutable) ortamda saklayın.
Değişiklikleri izleyin: Sertifika oluşturma, TDE açma/kapama ve veritabanı güvenlik ayarlarındaki değişiklikler anlık alarm üretmeli. Bu olayları izlemiyorsanız saldırıyı ancak fidye gününde öğrenirsiniz.
Yönetici erişimini kilitleyin: sysadmin yetkisini minimuma indirin, yönetici hesaplarında MFA kullanın, SQL portunu (1433) internete asla doğrudan açmayın, yedek hesaplarıyla üretim hesaplarını ayırın.
Yedeği değil, geri dönüşü test edin: "Yedek başarılı" raporu tek başına hiçbir şey kanıtlamaz. Düzenli aralıklarla farklı sunucuya tam geri yükleme testi yapın ve sonucu raporlayın. Biz bakım müşterilerimizde bu testi periyodik uygularız.
Yedekleriniz de hedefte: Saldırgan önce yedek kataloğunu ve saklama ayarlarını inceler. Yedek altyapısının yönetimini ayrı kimlik bilgileriyle ve ayrı bir ağ segmentinde tutun.

Korunma kontrol listesi

  1. ☐ Yukarıdaki iki sorguyla TDE durumu ve sertifika listesi kontrol edildi
  2. ☐ TDE sertifikası + özel anahtarı sunucu dışında güvenli şekilde yedeklendi
  3. ☐ Farklı sunucuya restore testi başarıyla yapıldı
  4. ☐ Aylık arşiv yedekleri 3–6 ay ve immutable ortamda saklanıyor
  5. ☐ Sertifika/TDE değişikliklerinde alarm kuruldu
  6. ☐ sysadmin yetkileri gözden geçirildi, MFA aktif, 1433 internete kapalı
  7. ☐ Yedek yönetimi üretimden ayrı hesap ve ağda

İRCOM tarafında durum

Yönettiğimiz SQL Server kurulumlarında TDE durumu ve sertifika envanterini düzenli kontrol ediyor, sertifika yedeklerini müşterilerimiz için güvenli kasada tutuyor ve geri dönüş testlerini periyodik yapıyoruz. Kendi sunucunuzu yönetiyorsanız ve yukarıdaki sorguların çıktısından emin değilseniz bize gönderin, birlikte değerlendirelim — bu kontrol beş dakika sürer, geç kalmanın telafisi yoktur.

Kaynaklar

← Blog'a dön  •  Kontrol için destek isteyin →