Sessiz Fidye Tehdidi: TDE Suistimali ve EMSBulut ile Erken Tespit

Yedeğiniz Başarılı Görünebilir, Ancak Geri Yüklenemeyebilir

Klasik fidye yazılımlarında saldırganlar dosyaları şifreler, sistemleri erişilemez hâle getirir ve fidye talep eder. Güncel saldırı yöntemlerinde ise saldırganlar doğrudan dosyaları şifrelemek yerine, veritabanı sunucusunun kendi meşru şifreleme mekanizmasını kullanabilir.

TDE Suistimali olarak adlandırılan bu yöntemde saldırgan:

SQL Server üzerinde yüksek yetkili erişim elde eder.
Kendi kontrolündeki bir sertifika ve şifreleme anahtarı oluşturur.
Veritabanlarında TDE özelliğini etkinleştirir.
Sertifika ve özel anahtarları kendi sistemine aktarır.
Yedeklerin haftalarca veya aylarca şifreli şekilde alınmasını bekler.
Temiz yedekler silindikten sonra anahtar karşılığında fidye talep eder.

Bu süre boyunca yedekleme sistemi “yedekleme başarılı” raporu vermeye devam edebilir. Ancak gerekli TDE sertifikası bulunmadığında alınan yedekler farklı bir sunucuya geri yüklenemez.

TDE Nedir?

Transparent Data Encryption, veritabanı dosyalarının disk üzerinde şifreli tutulmasını sağlayan bir güvenlik özelliğidir.

Microsoft SQL Server tarafında şifreleme yapısı genel olarak şu bileşenlerden oluşur:

Service Master Key
Database Master Key
Sertifika veya asimetrik anahtar
Database Encryption Key
Şifrelenen veritabanı dosyaları

TDE doğru yapılandırıldığında önemli bir güvenlik katmanı sağlar. Ancak sertifika ve özel anahtarların kaybedilmesi durumunda, şifrelenmiş veritabanı yedeklerinin geri yüklenmesi mümkün olmayabilir.

Tipik geri yükleme hatası şöyledir:

Cannot find server certificate with thumbprint...

Bu hata, yedeğin bozuk olduğu anlamına gelmez. Yedek teknik olarak sağlam olabilir; ancak veriyi açabilecek sertifika hedef SQL Server üzerinde bulunmamaktadır.

Saldırı Neden Uzun Süre Fark Edilmeyebilir?

Saldırgan TDE’yi etkinleştirdikten sonra hemen fidye talep etmeyebilir. Bunun yerine yedek saklama süresini analiz ederek 30, 60 veya 90 gün bekleyebilir.

Bu bekleme süresinde:

Full yedekler şifreli veriyi içerir.
Differential yedekler aynı şifreleme zincirine bağlıdır.
Transaction log yedekleri etkilenir.
Replikasyon ve felaket kurtarma sunucuları şifreli veriyi devralır.
Eski ve temiz yedekler saklama süresi dolduğu için silinir.

Saldırgan daha sonra veritabanını silebilir, SQL Server’ı yeniden başlatabilir veya sertifikayı erişilemez hâle getirebilir.

Sonuç olarak kurumun elinde çok sayıda başarılı yedek bulunmasına rağmen, bu yedeklerin hiçbiri kullanılamayabilir.

Geleneksel Yedekleme Kontrolleri Neden Yeterli Değildir?

Yedek bütünlüğü, verinin okunabilir olduğu anlamına gelmez

RESTORE VERIFYONLY gibi kontroller, yedek dosyasının fiziksel ve mantıksal yapısını doğrular. Ancak yedek içindeki verinin gerekli sertifikalar olmadan açılıp açılamayacağını garanti etmez.

TDE yedekleme yazılımı için şeffaftır

SQL Server veriyi disk üzerinde şifreli tuttuğu için, yedekleme sistemi bu veriyi olduğu şekilde yedekler. İşlem başarısız olmaz ve standart kontroller alarm üretmeyebilir.

Kullanılan komutlar meşru SQL komutlarıdır

Saldırıda kullanılabilecek komutlar şunlardır:

CREATE CERTIFICATE
CREATE DATABASE ENCRYPTION KEY
ALTER DATABASE SET ENCRYPTION ON

Bu komutlar SQL Server’ın standart yönetim komutlarıdır. Kötü amaçlı yazılım imzası taşımadıkları için klasik antivirüs ve EDR çözümleri tarafından her zaman tehdit olarak algılanmayabilir.

EMSBulut Backup Now Nasıl Koruma Sağlar?

EMSBulut Backup Now, SQL yedekleme işlemi başlamadan önce veritabanlarının TDE şifreleme durumunu kontrol eder.

Beklenmeyen bir şifreleme durumu tespit edildiğinde sistem yöneticisi bilgilendirilir.

Örneğin:

Bu veritabanında TDE şifrelemesi etkinleştirilmiştir. Bu işlem kurumunuz tarafından planlı olarak mı gerçekleştirilmiştir?

Bu kontrol sayesinde saldırganın şifrelemeyi etkinleştirip haftalarca sessizce yedeklerin üzerine yazılmasını beklemesi zorlaşır.

EMSBulut Backup Now yaklaşımının temel amacı yalnızca yedek almak değil, alınan yedeğin şifreleme durumu hakkında sistem yöneticisine görünürlük sağlamaktır.

Böylece:

Yeni etkinleştirilen TDE durumu erken fark edilebilir.
Şifreli veritabanları takip edilebilir.
Sistem yöneticileri beklenmeyen değişiklikleri araştırabilir.
Temiz yedekler saklama süresi dolmadan koruma altına alınabilir.
Olası bir fidye saldırısının hazırlık aşaması kesintiye uğratılabilir.

SQL Server’da TDE Durumu Nasıl Kontrol Edilir?

Sistem yöneticileri aşağıdaki sorguyu SQL Server Management Studio üzerinden çalıştırabilir:

SELECT
    db.name AS [Veritabanı Adı],
    db.is_encrypted AS [TDE İşaretli mi? (1=Evet)],
    CASE dek.encryption_state
        WHEN 0 THEN 'Anahtar Yok / Şifreleme Yok'
        WHEN 1 THEN 'Şifrelenmemiş'
        WHEN 2 THEN 'Şifreleme Devam Ediyor'
        WHEN 3 THEN 'Şifrelenmiş (Aktif)'
        WHEN 4 THEN 'Anahtar Değişimi Devam Ediyor'
        WHEN 5 THEN 'Şifre Çözme Devam Ediyor'
        WHEN 6 THEN 'Koruma Değişikliği Yapılıyor'
        ELSE 'Bilinmiyor'
    END AS [Detaylı Durum],
    dek.percent_complete AS [İşlem Tamamlanma Yüzdesi]
FROM sys.databases db
LEFT JOIN sys.dm_database_encryption_keys dek
    ON db.database_id = dek.database_id;

Sonuçların yorumlanması

is_encrypted = 0

Veritabanında TDE etkin değildir. Kurumunuz TDE kullanmıyorsa beklenen durum budur.

is_encrypted = 1 ve encryption_state = 3

Veritabanı aktif olarak şifrelenmiştir. TDE kurumunuz tarafından planlı şekilde etkinleştirilmediyse acil inceleme yapılmalıdır.

encryption_state = 2

Şifreleme işlemi devam etmektedir. İşlem sistem yöneticileri tarafından başlatılmadıysa sunucuda aktif bir saldırı ihtimali değerlendirilmelidir.

encryption_state = 4 veya 6

Anahtar veya koruma yöntemi değiştirilmektedir. Planlı bir bakım işlemi bulunmuyorsa şüpheli durum olarak ele alınmalıdır.

Beklenmeyen Bir Şifreleme Tespit Edilirse

Sunucuyu hemen kapatmak doğru olmayabilir. SQL Server bazı şifreleme anahtarlarını bellekte tutuyor olabilir. Kontrolsüz bir yeniden başlatma, bellekte bulunan anahtarların kaybedilmesine neden olabilir.

Önerilen ilk adımlar:

Sunucunun dış ağ bağlantısını kesin veya ağı kontrollü şekilde izole edin.
SQL Server hizmetini plansız şekilde durdurmayın.
Olay müdahale ve adli bilişim ekibini devreye alın.
Erişilebiliyorsa master key ve TDE sertifikalarını yedekleyin.
SQL Server Audit, Extended Events ve Windows güvenlik kayıtlarını koruma altına alın.
TDE’nin hangi tarihte etkinleştirildiğini belirleyin.
Bu tarihten önce alınmış temiz yedekleri ayrı bir ortamda koruyun.
İzole bir SQL Server üzerinde gerçek geri yükleme testi gerçekleştirin.

Erişilebilir durumda olan master key ve sertifikalar aşağıdaki komutlarla yedeklenebilir:

BACKUP MASTER KEY
TO FILE = 'C:\SecureBackup\master_key.snk'
ENCRYPTION BY PASSWORD = 'Guclu-Bir-Parola-Kullanin';

BACKUP CERTIFICATE [SertifikaAdi]
TO FILE = 'C:\SecureBackup\certificate.cer'
WITH PRIVATE KEY
(
    FILE = 'C:\SecureBackup\certificate.pvk',
    ENCRYPTION BY PASSWORD = 'Guclu-Bir-Parola-Kullanin'
);

Anahtar ve sertifika dosyaları, SQL Server’ın bulunduğu sistemden ayrı ve erişimi sınırlandırılmış güvenli bir ortamda saklanmalıdır.

Kurumlar İçin Önerilen Önlemler

TDE işlemlerini izleyin

Aşağıdaki işlemler için SQL Server Audit veya Extended Events üzerinden alarm oluşturun:

Sertifika oluşturulması
Database Encryption Key oluşturulması
TDE’nin etkinleştirilmesi
Sertifika veya anahtar yedeklenmesi
Master key değişiklikleri
Sertifika silme işlemleri

SQL sysadmin hesaplarını sınırlandırın

Günlük kullanılan hesaplara kalıcı sysadmin yetkisi verilmemelidir.

Mümkünse:

Çok faktörlü kimlik doğrulama
Bastion sunucu
Just-in-time yetkilendirme
Ayrı yönetici hesapları
IP ve ağ segmenti kısıtlamaları

kullanılmalıdır.

Gerçek geri yükleme testi yapın

Yalnızca yedekleme işleminin başarılı olmasına veya VERIFYONLY sonucuna güvenilmemelidir.

Belirli aralıklarla:

Yedek izole bir SQL Server’a geri yüklenmeli,
TDE sertifikaları doğrulanmalı,
Kritik tablolar sorgulanmalı,
Uygulama seviyesinde veri erişimi test edilmelidir.

Anahtarları yedeklerden ayrı saklayın

TDE sertifikası ve özel anahtarı yalnızca SQL Server üzerinde tutulmamalıdır.

Kritik sistemlerde HSM, Azure Key Vault, AWS KMS veya kurumsal anahtar yönetim çözümleri değerlendirilmelidir.

İnternete açık SQL portlarını kapatın

SQL Server’ın 1433 portu doğrudan internete açılmamalıdır.

Uzak erişim gerektiğinde VPN, Zero Trust erişim, güvenli ağ geçidi veya IP beyaz listeleme kullanılmalıdır.

Sonuç

TDE Suistimali saldırısı, klasik fidye saldırılarından farklı olarak yedekleri silmeden veya yedekleme işini durdurmadan ilerleyebilir.

Bu nedenle “yedekleme başarılı” mesajı tek başına yeterli güvence değildir.

Modern bir yedekleme stratejisi şu üç soruya cevap verebilmelidir:

Yedek dosyası sağlam mı?
Veritabanı beklenmeyen şekilde şifrelenmiş mi?
Yedek, farklı bir sistem üzerinde gerçekten geri yüklenip okunabiliyor mu?

EMSBulut Backup Now, yedekleme öncesinde TDE durumunu kontrol ederek beklenmeyen şifreleme değişikliklerinin erken fark edilmesine yardımcı olur.

Amaç yalnızca veriyi yedeklemek değil, ihtiyaç anında geri yüklenebilecek ve kullanılabilecek bir veri kopyasını güvence altına almaktır.