SQL Server veritabanı yönetiminde, güvenlik amacıyla TDE (Transparent Data Encryption) yani Şeffaf Veri Şifreleme sıklıkla tercih edilen bir yöntemdir. Ancak TDE ile şifrelenmiş bir veritabanını farklı bir sunucuya (instance) taşımak, yedekten dönmek (restore) veya işletim sistemi formatı sonrasında yeniden ayağa kaldırmak istediğinizde en çok karşılaşılan ve can sıkan hatalardan biri şudur:
Hata Mesajı:
Msg 33111, Level 16, State 4
Cannot find server asymmetric key with thumbprint '0x7b8626f7e9b646cb8702530018600bf3'.
RESTORE DATABASE is terminating abnormally.
Bu makalede, bu kritik hatanın ne anlama geldiğini, veritabanını kurtarmak için hangi adımları izlemeniz gerektiğini ve TDE mimarisindeki bazı gizli riskleri detaylarıyla ele alıyoruz.
🔍 Bu Hata Ne Anlama Geliyor?
Geri yüklemeye çalıştığınız TDE şifreli veritabanı, yedek alındığı eski SQL Server üzerinde kurulu olan bir Certificate (Sertifika) veya Asymmetric Key (Asimetrik Anahtar) yapısına bağımlıdır.
Yeni sunucunuzda veya yeni SQL Server instance'ı üzerinde bu güvenlik nesnesi (ve onun benzersiz parmak izi olan thumbprint) bulunmadığı için, SQL Server verilerini deşifre edemez ve güvenliği korumak adına veritabanını açmayı reddeder.
🛠️ Adım Adım Kurtarma Çözümü
Sorunu çözmek için eski sunucudaki sertifika ve anahtar bileşenlerini yedekleyip, yeni sunucuya güvenli bir şekilde aktarmamız (restore etmemiz) gerekir.
1. Adım: Veritabanında TDE Durumunu Kontrol Edin
Öncelikle eski sunucu üzerinde (eğer erişiminiz varsa) aşağıdaki sorgularla TDE durumunu ve aranan thumbprint değerini genel olarak teyit edin:
👍İlgili parmak izine sahip sertifikayı kontrol edin
SELECT name, thumbprint
FROM sys.certificates
WHERE thumbprint = 0x7b8626f7e9b646cb8702530018600bf3;
👍Genel TDE şifreleme durumlarını listeleme
SELECT db.name AS DatabaseName,
dek.encryption_state,
dek.percent_complete,
dek.key_algorithm,
dek.key_length
FROM sys.databases db
LEFT JOIN sys.dm_database_encryption_keys dek
ON db.database_id = dek.database_id;
encryption_state değeri listeleniyorsa TDE aktiftir.
2. Adım: Eski Sunucuda Sertifikayı Yedekleyin (Backup)
Eski sunucudan Database Master Key (DMK) tarafından korunan anahtar bileşenlerini dışarı aktarmamız şarttır. Aşağıdaki script ile sertifikayı ve onun özel anahtarını (PRIVATE KEY) şifreli bir dosya olarak diske kaydedin:
👍Master veritabanında çalıştırın
USE master;
GO
BACKUP CERTIFICATE MyTDECert
TO FILE = 'D:\Backup\MyTDECert.cer'
WITH PRIVATE KEY (
FILE = 'D:\Backup\MyTDECert.pvk',
ENCRYPTION BY PASSWORD = 'GucluBirSifre123!'
);
GO
3. Adım: Yeni Sunucuda Sertifikayı Yeniden Oluşturun (Restore)
Oluşturduğunuz .cer ve .pvk dosyalarını yeni sunucunun diskine taşıyın. Ardından yeni SQL Server'ın master veritabanında bu nesneleri içeri aktarın. Eğer yeni sunucuda henüz bir Master Key yoksa, önce onu oluşturmalısınız:
👍Yeni sunucunun Master veritabanında çalıştırın
USE master;
GO
👍1. Eğer daha önce oluşturulmadıysa Database Master Key oluşturun
IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE name = '##MS_DatabaseMasterKey##')
BEGIN
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'YeniMasterKeySifresi123!';
END
GO
👍2. Eski sunucudan gelen dosyaları kullanarak Sertifikayı içeri aktarın
CREATE CERTIFICATE MyTDECert
FROM FILE = 'D:\Backup\MyTDECert.cer'
WITH PRIVATE KEY (
FILE = 'D:\Backup\MyTDECert.pvk',
DECRYPTION BY PASSWORD = 'GucluBirSifre123!'
);
GO
Bu adımları tamamladıktan sonra, veritabanı yedeğinizi (.bak) yeni sunucuya sorunsuz bir şekilde RESTORE edebilir veya dosyaları ATTACH edebilirsiniz. SQL Server aradığı thumbprint değerini bulacağı için şifreyi çözecektir.
🚨 Önemli Güvenlik Uyarısı (Sysadmin Riski)
TDE (Transparent Data Encryption), verilerinizin disk seviyesinde (at-rest) çalınmasını veya .mdf/.ldf dosyalarının kopyalanarak başka sunucularda açılmasını kesin olarak engeller.
Ancak unutulmamalıdır ki, SQL Server üzerinde Sysadmin (SA) yetkisine sahip bir kullanıcı veya sunucu yöneticisi, doğrudan canlı veritabanı üzerinde sorgu çekebildiği gibi master veritabanındaki sertifika yapılarına da tam erişim sağlayabilir.
TDE, harici disk hırsızlıklarına karşı mükemmel bir kalkan sunarken, içerideki en üst düzey yetkili kullanıcıların veriyi okumasını kısıtlamaz. Bu nedenle tam bir veri güvenliği için yetki hiyerarşisi ve sunucu erişim rolleri de sıkı denetlenmelidir.
Araç indirme linki için tıklayınız.
🍁
Sorularınız, karşılaştığınız teknik sorunlar ve destek talepleriniz için aşağıya yorum bırakabilirsiniz
Yorumlar
Yorum Gönder
Fikirlerin benim için değerli, paylaşmaktan çekinme!