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.