Transparent Data Encryption schützt Tabellen- und Tablespace-Schlüssel mit einem TDE-Masterkey, der im Keystore liegt. Eine Rotation aktiviert einen neuen Masterkey. Damit ist die operative Änderung jedoch nicht abgeschlossen: Ältere Backups können weiterhin Schlüssel aus der bisherigen Key-Historie benötigen. Wer den Wallet- oder Key-Vault-Zugriff, die PDBs und den Restore-Ablauf nicht mitplant, riskiert im Notfall unlesbare Daten.
Vor der Rotation: Zustand und Abdeckung erfassen
Prüfen Sie zunächst Keystore-Status und Speicherort über V$ENCRYPTION_WALLET und erfassen Sie die aktiven sowie früheren Schlüssel in V$ENCRYPTION_KEYS. In einer CDB gehört dazu eine Liste der betroffenen PDBs samt Öffnungszustand. Bei CONTAINER = ALL müssen alle PDBs geöffnet sein; andernfalls schlägt der Befehl fehl. Planen Sie für einen kontrollierten Change daher ein passendes Wartungsfenster und klären Sie vorher, ob ein zentraler oder isolierter Keystore verwendet wird.
Rotation mit Keystore-Backup ausführen
Die Rotation erfolgt mit ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY. Die Klausel WITH BACKUP erstellt vor der Änderung eine Sicherung des Keystores; ein aussagekräftiger Backup-Identifier erleichtert die Zuordnung zum Change-Ticket:
ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY
IDENTIFIED BY "<Keystore-Passwort aus sicherer Eingabe>"
WITH BACKUP USING 'rotate_20261104'
CONTAINER = ALL;Das Passwort gehört in eine geschützte Eingabe oder einen freigegebenen External Store, nicht in ein dauerhaft gespeichertes Skript. Anschließend kontrollieren Sie CREATION_TIME und ACTIVATION_TIME in V$ENCRYPTION_KEYS und bestätigen den geöffneten Keystore. Falls automatische Login-Keystores an einem getrennten Speicherort liegen, muss deren Aktualisierung beziehungsweise Neuerstellung ausdrücklich in den Ablauf aufgenommen werden.
Restore-Fähigkeit nachweisen
Behalten Sie alte Masterkeys im Keystore, solange Backups oder Kopien existieren, die sie benötigen. Die Rotation allein ist kein Grund, historische Schlüssel zu entfernen. Verknüpfen Sie Backup-Zeitpunkt, Datenbank beziehungsweise PDB und benötigte Keystore-Sicherung in Ihrer Aufbewahrungsdokumentation. Testen Sie mindestens einen Restore aus der Backup-Generation vor der Rotation in einer isolierten Umgebung – inklusive Keystore-Zugriff und Recovery bis zu einem geöffneten Datenbankzustand.
Führen Sie Masterkey-Rotation außerdem nicht parallel zu einem laufenden Tablespace-Rekeying aus. Prüfen Sie V$ENCRYPTED_TABLESPACES auf den Status REKEYING, bevor Sie das Wartungsfenster starten. Ein Tablespace-Rekey ist ein eigener Vorgang mit eigener Laufzeit- und I/O-Planung.
Checkliste für den Change
- Keystore-Typ, Speicherort, Status und PDB-Abdeckung dokumentieren.
- Keystore-Sicherung mit Change-Kennung erstellen und ihren Ablageort testen.
- Rotation ausführen, aktive Schlüssel und Keystore-Status kontrollieren.
- Ältere Backups mit der benötigten Schlüsselhistorie verknüpfen.
- Restore aus einem Backup vor der Rotation regelmäßig praktisch testen.
Fazit
Eine TDE-Rotation ist erst dann betriebssicher, wenn neue Schlüssel aktiv sind und ältere Sicherungen weiterhin wiederhergestellt werden können. Ein versioniertes Keystore-Backup, geprüfte PDB-Abdeckung und ein echter Restore-Test machen aus dem einzelnen SQL-Befehl einen belastbaren Sicherheitsprozess.
Weiterführend: Oracles Anleitung zum Verwalten von Keystore und TDE-Masterkey und die Referenz zu ADMINISTER KEY MANAGEMENT.