Merhaba

Veri sızıntılarının ve regülasyon baskısının arttığı bir dönemde, veritabanının diskteki fiziksel dosyalarını korumak artık tercih değil zorunluluk haline geldi. SQL Server’ın bu ihtiyaca verdiği yanıt TDE (Transparent Data Encryption / Saydam Veri Şifreleme).

Bu yazıda TDE’nin ne olduğunu, anahtar hiyerarşisini ve tek bir veritabanına sıfırdan nasıl uygulandığını adım adım ele alacağız. TDE’nin Always On Availability Group üzerinde yapılandırılması ise ayrı bir yazının konusu olacak; önce temeli sağlam kuralım.

Başlamadan önce ortamınızı belirleyin: Bu yazıdaki adımlar tek (standalone) bir SQL Server üzerinde çalışan bir veritabanı içindir; bu durumda Primary/Secondary gibi bir kavram yoktur, doğrudan aşağıdaki adımlarla devam edebilirsiniz. Ancak veritabanınız bir Always On Availability Group içindeyse, işlemlere başlamadan önce hangi sunucunun PRIMARY hangisinin SECONDARY olduğunu doğrulamanız gerekir; çünkü Always On senaryosunda bazı komutlar yalnızca Primary’de, bazıları yalnızca Secondary’de çalışır.

Rolleri şu sorguyla kontrol edebilirsiniz:

Always On ortamında, her iki node’da da çalışır:

SELECT 
    ag.name AS AG_Name,
    ar.replica_server_name,
    ars.role_desc
FROM sys.availability_groups ag
JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id
JOIN sys.dm_hadr_availability_replica_states ars 
     ON ar.replica_id = ars.replica_id;
GO

Bu sorgu boş dönerse (veya sys.availability_groups boşsa) sunucunuz Always On yapılandırmasında değildir; standalone olarak bu yazıdaki adımları uygulayın. Always On ortamında TDE yapılandırmasının tüm ayrıntıları için serinin ikinci yazısına bakın.

TDE Nedir?

TDE, veritabanının veri (.mdf), ikincil veri (.ndf) ve log (.ldf) dosyalarını disk üzerinde şifreleyen, bekleyen veriyi (data at rest) koruyan bir güvenlik özelliğidir. İlk kez SQL Server 2008 ile Enterprise Edition özelliği olarak tanıtıldı; SQL Server 2019 ve sonrasında Standard Edition dahil çoğu sürümde kullanılabilir hale geldi.

“Saydam” (transparent) kelimesi buradaki en kritik noktadır: şifreleme ve şifre çözme işlemi tamamen veritabanı motoru tarafından yürütülür. Uygulama tarafında hiçbir kod değişikliği gerekmez. Uygulamalar veriyi her zamanki gibi okur ve yazar; SQL Server sayfa (page) seviyesinde şifrelemeyi ve çözmeyi arka planda otomatik yapar.

TDE Ne İşe Yarar, Neyi Korumaz?

TDE’nin koruma alanı net biçimde tanımlıdır:

• Fiziksel hırsızlığa karşı korur. Disk, SAN LUN’u veya yedek dosyası (.bak) çalınsa dahi, doğru sertifika olmadan veri okunamaz.
• Yedekleri de şifreler. TDE etkin bir veritabanının yedeği de otomatik olarak şifrelidir; sertifikası olmayan bir sunucuya restore edilemez.
• Regülasyon uyumuna katkı sağlar. PCI-DSS, GDPR/KVKK, HIPAA gibi standartların “bekleyen verinin şifrelenmesi” gerekliliklerini karşılamaya yardımcı olur.

Ancak TDE bir “her derde deva” değildir. Bellekteki veriyi, ağ üzerinde hareket eden veriyi (data in transit) veya yetkili bir kullanıcının çalıştırdığı SELECT sorgusunun sonucunu şifrelemez. Yetkiye sahip bir hesap veriyi düz metin olarak görür. Ağ trafiğinin şifrelenmesi için TLS, sütun bazlı koruma için Always Encrypted gibi tamamlayıcı mekanizmalar gerekir.

TDE’nin Anahtar Hiyerarşisi

TDE’yi doğru yapılandırmak için anahtar zincirini anlamak şart. Şifreleme, birbirini koruyan katmanlı bir yapıya dayanır:

1. Service Master Key (SMK): SQL Server instance kurulumunda otomatik oluşur, tüm hiyerarşinin kökündedir.
2. Database Master Key (DMK): master veritabanında oluşturulur ve bir parola ile korunur.
3. Sertifika (Certificate): DMK tarafından korunur ve asıl şifreleme anahtarını (DEK) korumak için kullanılır.
4. Database Encryption Key (DEK): Kullanıcı veritabanının içinde bulunan simetrik anahtardır. Asıl veriyi şifreleyen anahtar budur; AES-128, AES-192 veya AES-256 algoritmalarından biriyle üretilir.

Zincir şu şekilde işler: DEK veriyi şifreler → sertifika DEK’i korur → DMK sertifikayı korur → SMK DMK’yi korur. Bu yüzden sertifika kaybedilirse veritabanı bir daha asla açılamaz. Sertifikanın ve özel anahtarının yedeği, TDE’nin en kritik operasyonel maddesidir.

Tek Bir Veritabanına TDE Uygulama

Temel mantık şudur: anahtar zinciri yukarıdan aşağı kurulur (master key → sertifika → DEK), sonra en altta şifreleme açılır.

Bu örnekte, kendi ortamımdaki BAKICUBUK_DB1 veritabanını şifreleyeceğiz. Siz kendi veritabanı adınızla uyarlayabilirsiniz.

İpucu: TDE’yi devreye almadan önce veritabanının hatasız olduğundan emin olmak için DBCC CHECKDB çalıştırın ve güncel bir tam yedek (full backup) alın.

Bütünlük kontrolünü şu şekilde yapabilirsiniz:

DBCC CHECKDB('BAKICUBUK_DB1') WITH NO_INFOMSGS, ALL_ERRORMSGS;
GO

NO_INFOMSGS bilgilendirme satırlarını gizler, yalnızca varsa hataları gösterir; ALL_ERRORMSGS tüm hata mesajlarını eksiksiz listeler. Sonuçta “0 allocation errors and 0 consistency errors” ifadesini görüyorsanız veritabanı sağlıklıdır ve TDE’ye devam edebilirsiniz. Herhangi bir hata çıkarsa, TDE uygulamadan önce bu hatayı çözmeniz gerekir. Büyük veritabanlarında CHECKDB yoğun I/O ve tempdb kullandığından, yoğun olmayan saatlerde çalıştırmanız önerilir.

Adım 1: Master Key Oluşturma

İlk kez şifreleme yapıyorsanız, mevcut bir master key olmamalıdır. Aşağıdaki sorgu boş sonuç dönerse temizsiniz demektir:

SELECT * FROM sys.symmetric_keys 
WHERE name = '##MS_DatabaseMasterKey##';

master veritabanında güçlü bir parola ile master key oluşturun:

USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Str0ng!#MasterKey#TDE2026';
GO

Adım 2: Sertifika Oluşturma

DEK’i koruyacak sertifikayı oluşturun. Sertifikanın varsayılan geçerlilik süresi 1 yıldır.

İpucu: Sertifikanın bir yıl içinde dolması operasyonel yük getirir. Geçerlilik süresini 5 yıl olarak ayarlamak iyi bir pratiktir.

 

Not: Buradaki BAKICUBUK_TDE_Cert sertifikanın adıdır ve tamamen sizin seçtiğiniz bir etikettir; SQL Server açısından özel bir anlamı yoktur. İstediğiniz ismi verebilirsiniz (TDE_Cert , SQL25HAG_TDE_Cert vb.). Aynı şekilde SUBJECT alanı da yalnızca açıklama amaçlı serbest metindir. Önemli olan tek kural: sonraki tüm adımlarda aynı sertifika adını birebir kullanmanızdır.

USE master;
GO
CREATE CERTIFICATE BAKICUBUK_TDE_Cert
    WITH SUBJECT = 'TDE Certificate',
    EXPIRY_DATE = '2031-12-31';
GO

Sertifikanın oluştuğunu doğrulayın:

SELECT name, subject, expiry_date 
FROM sys.certificates 
WHERE name = 'BAKICUBUK_TDE_Cert';
GO

Adım 3: Sertifikayı Yedekleme (KRİTİK)

Sertifikayı ve özel anahtarını, şifrelemeyi açmadan önce mutlaka yedekleyin. Bu yedek olmadan veritabanını başka bir instance’a taşıyamaz, restore edemez ve sertifika kaybı durumunda veriye bir daha erişemezsiniz. Yedeği veritabanı sunucusundan ayrı, güvenli bir konumda saklayın.

Not: Yedekleme komutlarını çalıştırmadan önce, hedef klasörün diskte var olduğundan emin olun. C:\ dizini altında TDE_Backup isimli bir klasör yoksa oluşturun; aksi halde BACKUP CERTIFICATE komutu şuna benzer bir hata verir: Msg 3013 – BACKUP CERTIFICATE is terminating abnormally.
SQL Server var olmayan bir dizine yazamaz ve klasörü kendisi oluşturmaz. Ayrıca SQL Server hizmet hesabının (service account) bu klasöre yazma iznine sahip olması gerekir.

USE master;
GO
BACKUP CERTIFICATE BAKICUBUK_TDE_Cert
    TO FILE = 'C:\TDE_Backup\BAKICUBUK_TDE_Cert.cer'
    WITH PRIVATE KEY (
        FILE = 'C:\TDE_Backup\BAKICUBUK_TDE_Cert.pvk',
        ENCRYPTION BY PASSWORD = 'Cert!PrivKey#Str0ngTDE2026'
    );
GO

Parola notu: Buradaki ENCRYPTION BY PASSWORD = '...' satırındaki parola örnektir; kendi güçlü parolanızla değiştirin. Ancak bu parolayı bir yere not edin ve unutmayın: sertifikayı ileride başka bir sunucuda veya Always On ikincil replikasında geri yüklerken (CREATE CERTIFICATE ... DECRYPTION BY PASSWORD) tam olarak aynı parolayı girmeniz gerekir. Parola tutmazsa .pvk dosyası açılamaz ve sertifika taşınamaz. Aynı şey master key yedeğindeki (BACKUP MASTER KEY) parola için de geçerlidir; her parolayı ayrı ayrı güvenli bir yerde saklayın.

Not: Yedekleme komutları çalıştırıldıktan sonra, C:\TDE_Backup klasöründe iki dosya oluşacaktır

• BAKICUBUK_TDE_Cert.cer – sertifikanın kendisi (public kısım)
• BAKICUBUK_TDE_Cert.pvk – sertifikanın özel anahtarı (private key)

Bu iki dosya, sertifikayı ikincil replikaya taşırken (Always On senaryosu) veya başka bir sunucuda geri yüklerken kullanılacaktır. Her ikisini de güvenli bir konumda saklayın; .pvk dosyası olmadan sertifika bir işe yaramaz.

Bu arada master key’i de güvenli bir konuma yedeklemek iyi bir pratiktir (Yedek parolası, master key parolasından farklı olabilir):

BACKUP MASTER KEY TO FILE = 'C:\TDE_Backup\MasterKey.key'
    ENCRYPTION BY PASSWORD = 'Backup!MK#Str0ngTDE2026';
GO

Not: Yedekleme komutlarını çalıştırmadan önce C:\TDE_Backup klasörünün diskte var olduğundan emin olun. SQL Server var olmayan bir dizine yazamaz ve klasörü kendisi oluşturmaz; ayrıca SQL Server hizmet hesabının (service account) bu klasöre yazma izni olmalıdır. Klasör yoksa BACKUP komutu hata verir.

Bu adımların sonunda C:\TDE_Backup klasöründe üç dosya oluşur. Karıştırmamak için ne olduklarını özetleyelim:

Dosya	Hangi Komuttan	Ne işe yarar
MasterKey.key	BACKUP MASTER KEY	Database Master Key (DMK) yedeği – sunucu taşıma / felaket kurtarma için
BAKICUBUK_TDE_Cert.cer	BACKUP CERTIFICATE	Sertifikanın kendisi (public kısım)
BAKICUBUK_TDE_Cert.pvk	BACKUP CERTIFICATE	Sertifikanın özel anahtarı (private key)

Üçünü de güvenli, veritabanı sunucusundan ayrı bir konumda saklayın. Özellikle.cer ve .pvk ikilisi, sertifikayı başka bir sunucuda (örneğin Always On ikincil replikasında) yeniden oluşturmak için gereklidir; .pvk dosyası olmadan sertifika işe yaramaz.

Not: Master key yedekleme komutu çalıştırıldıktan sonra, klasöründe dosyası oluşturulacaktır. Bu dosya, Database Master Key’in (DMK) yedeğidir ve sunucu taşıma / felaket kurtarma senaryolarında master key’i geri yüklemek için kullanılır. Güvenli bir konumda saklayın.

Adım 4: Database Encryption Key (DEK) Oluşturma

Asıl veriyi şifreleyecek simetrik anahtarı, master‘da değil, şifreleyeceğiniz kullanıcı veritabanının içinde oluşturun:

USE BAKICUBUK_DB1;
GO
CREATE DATABASE ENCRYPTION KEY
    WITH ALGORITHM = AES_256
    ENCRYPTION BY SERVER CERTIFICATE BAKICUBUK_TDE_Cert;
GO

Adım 5: TDE Şifrelemesini Etkinleştirme

USE master;
GO
ALTER DATABASE BAKICUBUK_DB1 SET ENCRYPTION ON;
GO

Adım 6: Şifreleme Durumunu İzleme

Şifreleme ilerlemesini izleyin. encryption_state değeri 3 olduğunda şifreleme tamamlanmış demektir:

SELECT 
    DB_NAME(database_id) AS DatabaseName,
    encryption_state,
    percent_complete,
    key_algorithm,
    key_length
FROM sys.dm_database_encryption_keys;
GO

encryption_state değerlerinin anlamı: 0 = anahtar yok, 1 = şifresiz, 2 = şifreleme devam ediyor, 3 = şifreleme tamamlandı, 4 = anahtar değişikliği sürüyor, 5 = şifre çözme devam ediyor.

Not: İlk şifreleme, veritabanının tüm sayfalarının yeniden yazılmasını gerektirdiğinden veritabanı boyutuna bağlı olarak zaman alır, birkaç GB’lık bir veritabanında dakikalar, çok büyük veritabanlarında saatler sürebilir. İlerlemeyi percent_complete sütunundan takip edebilirsiniz (bu sütun yalnızca encryption_state = 2 iken anlamlı değer gösterir, işlem bitince 0’a döner). Bu süre boyunca veritabanı çevrimiçi ve kullanılabilir durumda kalır; yalnızca ek I/O yükü oluşur, bu nedenle işlemi yoğun olmayan saatlerde başlatmanız önerilir. FULL recovery modelinde ilk şifreleme transaction log’unu büyütebilir; log yedeklerinizin bu sırada düzenli alındığından emin olun.

 

Not: Herhangi bir kullanıcı veritabanı TDE ile şifrelendiğinde, tempdb de otomatik olarak şifrelenir.

Bu altı adımla tek bir veritabanı başarıyla şifrelenmiş olur. Şimdi bu yapıyı Always On mimarisine taşıyalım.

Süresi Dolan Sertifikayı Yenileme (Certificate Rotation)

TDE sertifikasının süresi dolmak üzereyse, sertifikayı döndürmek (rotate etmek) iyi bir pratiktir. Süresi dolmuş bir sertifika veritabanının normal operasyonlarını engellemez, ancak yeni yedekler için güncel bir sertifika bulundurmak güvenlik açısından önemlidir.

Önce sertifikaların bitiş tarihini kontrol edin:

SELECT name, subject, expiry_date 
FROM sys.certificates
WHERE pvt_key_encryption_type = 'MK';
GO

Yeni bir sertifika oluşturun:

USE master;
GO
CREATE CERTIFICATE BAKICUBUK_TDE_Cert_New
    WITH SUBJECT = 'TDE Certificate Rotation 2025',
    EXPIRY_DATE = '2031-12-31';
GO

Yeni sertifikayı yedekleyin:

BACKUP CERTIFICATE BAKICUBUK_TDE_Cert_New
    TO FILE = 'C:\TDE_Backup\BAKICUBUK_TDE_Cert_New.cer'
    WITH PRIVATE KEY (
        FILE = 'C:\TDE_Backup\BAKICUBUK_TDE_Cert_New.pvk',
        ENCRYPTION BY PASSWORD = 'NewCert!PrivKey#2025'
    );
GO

DEK’i yeni sertifikaya döndürün:

USE BAKICUBUK_DB1;
GO
ALTER DATABASE ENCRYPTION KEY
    ENCRYPTION BY SERVER CERTIFICATE BAKICUBUK_TDE_Cert_New;
GO

Bitiş tarihini doğrulayın:

SELECT 
    DB_NAME(database_id) AS DatabaseName,
    c.name AS CertificateName,
    c.expiry_date
FROM sys.dm_database_encryption_keys dek
JOIN sys.certificates c ON dek.encryptor_thumbprint = c.thumbprint;
GO

Önemli: Eski sertifikayı hemen silmeyin. Rotasyondan önce alınmış yedekleri restore edebilmek için eski sertifikanın bir süre daha saklanması gerekir. Yeni sertifika yalnızca rotasyon sonrası alınan yedekler için kullanılır.

Not: Sertifikanın Always On Availability Group üzerinde döndürülmesinde ek adımlar vardır (yeni sertifikanın ikincil replikalara da taşınması gibi). Bu konuyu Always On yazısında ele alacağız.

Operasyonel En İyi Uygulamalar

• Sertifikayı ve özel anahtarını mutlaka yedekleyin. TDE’de veri kaybının bir numaralı sebebi kaybolan sertifikadır. Yedekleri veritabanı sunucusundan ayrı, güvenli bir konumda saklayın.
• Sertifikanın geçerlilik süresini uzun tutun (5 yıl önerilir) ve dolma tarihini izlemeye alın.
• TDE, şifreleme/çözme işlemi nedeniyle küçük bir CPU maliyeti getirir. Yoğun I/O yapan sistemlerde bunu performans testleriyle ölçün.
• Kurumsal ortamlarda anahtarları veritabanı içinde tutmak yerine harici bir anahtar yöneticisiyle (Extensible Key Management, EKM) yönetmeyi değerlendirin; bu, görev ayrımı (separation of duties) ve merkezi anahtar yönetimi sağlar. Seçenekler arasında yerinde (on-premise) HSM cihazları ve Azure Key Vault gibi bulut tabanlı çözümler bulunur. Ancak seçim yaparken regülasyon ve veri konumu (data residency) kısıtlarını göz önünde bulundurun: özellikle finans, ödeme sistemleri ve kamu gibi sektörlerde, ilgili mevzuat (örneğin KVKK kapsamında yurt dışına veri aktarımı hükümleri veya sektörel düzenlemeler) şifreleme anahtarlarının yurt içinde ya da doğrudan kurum kontrolündeki bir HSM’de tutulmasını gerektirebilir. Böyle durumlarda bulut tabanlı bir anahtar kasası uygun olmayabilir; yerinde HSM daha doğru bir tercih olabilir. Nihai kararı, kurumunuzun uyum (compliance) ve hukuk birimleriyle birlikte verin.
• TDE’yi TLS (hareket halindeki veri) ve gerekiyorsa Always Encrypted (sütun bazlı koruma) ile birlikte katmanlı bir güvenlik stratejisinin parçası olarak konumlandırın.

TDE, SQL Server’ın bekleyen veriyi korumak için sunduğu güçlü ve uygulamaya saydam bir çözümdür. Bu yazıda TDE’nin anahtar hiyerarşisini, tek bir veritabanına sıfırdan nasıl uygulandığını ve sertifika rotasyonunu adım adım ele aldık. Bir sonraki yazıda bu yapıyı Always On Availability Group mimarisine taşıyacak; şifreli bir veritabanının replikalar arasında nasıl senkronize edileceğini ve failover senaryolarını inceleyeceğiz.