TDE – sinnvoll, aber nicht ohne Nebenwirkungen

Du willst ruhende Daten verschlüsseln.
Du willst keine Compliance-Diskussion mit der IT-Leitung.
Also schaltest Du Transparent Data Encryption (TDE) ein.

Soweit gut.
Aber irgendwann fragst Du Dich: Warum ist das Backup so langsam geworden?
Warum schreibt die Datenbank weniger MB/s als vorher?

Die Antwort: TDE war früher ein Flaschenhals.
Seit SQL Server 2019 hat Microsoft nachgebessert.

Was hat sich verbessert?

Die entscheidenden Verbesserungen:

• Lesepuffer für entschlüsselte Seiten
• parallele Entschlüsselung über mehrere CPUs
• Nutzung von AES-NI durch Crypto API: Next Generation (CNG)

Wie Du erkennst, ob TDE bremst

SELECT * 
FROM sys.dm_io_virtual_file_stats(NULL, NULL);

Achte auf hohe io_stall-Werte trotz SSD.
Vergleiche Datenbank mit/ohne TDE bei identischer Last.

Oder prüfe CPU-Auslastung durch Krypto-Threads:

SELECT 
    scheduler_id, 
    current_tasks_count, 
    runnable_tasks_count, 
    pending_disk_io_count
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255;

Performance-Tipp 1: Backup Compression + TDE

Seit SQL 2016 kannst Du komprimierte Backups mit TDE kombinieren.
Aber: Backup-Kompression greift nach der Verschlüsselung.
Kompression ist also oft ineffizient.

Abhilfe: Komprimieren per Tool (z. B. 7-Zip) nach dem Backup.
Oder: Backup ohne TDE, wenn möglich – auf sekundärer Kopie.

Performance-Tipp 2: TDE Scan Buffer aktivieren

SQL Server nutzt ab 2019 CU8 einen Lesepuffer für entschlüsselte Seiten.
Das reduziert die CPU-Spitzen bei großen Scans.

Aktivierung: automatisch.
Du kannst es nur über die Traceflag 1806 abschalten (nicht empfohlen).

Performance-Tipp 3: Verschlüsselungsalgorithmus prüfen

Standard ist AES_256.
Wenn Dein Prozessor AES-NI kann, dann ist das auch performant.

Prüfen kannst Du das so:

SELECT * 
FROM sys.dm_os_loaded_modules 
WHERE description LIKE '%AES%';

Oder im BIOS nach AES-Befehlssatz schauen.
Viele VMs haben ihn nicht standardmäßig aktiv.

Beispiel: TDE aktivieren (Reminder)

-- Zertifikat anlegen
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'StarkesPasswort123!';
CREATE CERTIFICATE MyServerCert
WITH SUBJECT = 'TDE Zertifikat';

-- Schlüssel im Kontext der DB
USE MeineDB;
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;

ALTER DATABASE MeineDB
SET ENCRYPTION ON;

Monitoring: Was ist verschlüsselt?

SELECT 
    name, is_encrypted
FROM sys.databases;

Und:

SELECT 
    db.name, dek.encryption_state, dek.percent_complete, dek.encryptor_type
FROM sys.dm_database_encryption_keys dek
JOIN sys.databases db ON db.database_id = dek.database_id;

Mein Fazit

TDE war lange ein Performanceproblem.
Jetzt nicht mehr – wenn Du SQL Server 2019+ nutzt
und auf aktuelle Hardware achtest.

Wenn Du trotzdem IO-Spitzen hast:
Lass uns den Server gemeinsam prüfen.
Oft liegt’s nicht an TDE, sondern an RAID, VMs oder falscher Konfiguration.

Und wenn Du willst, automatisier ich Dir die TDE-Prüfung per Job. Norddeutsch pragmatisch.