Oracle-TDE-Integration mit Cockpit v2

Wie sich Oracle Transparent Data Encryption über den DuoKey-PKCS#11-Provider mit Cockpit v2 verbindet.

Gilt für:

DuoKey Cockpit v2Oracle TDEPKCS#11

Diese Seite beschreibt, wie sich Oracle Transparent Data Encryption mit Cockpit v2 verbindet. Für den bisherigen Cockpit-v1-Pfad siehe den Abschnitt Installation & Einrichtung dieser Anleitung.

Demo-Video

Ein kurzes Demo-Video des durchgängigen Ablaufs Oracle TDE ↔ Cockpit v2 wird hier ergänzt.

Die Integrationskette

Oracle spricht niemals direkt mit Cockpit v2. Es lädt den DuoKey-PKCS#11-Provider (eine native Bibliothek), der jeden Cryptoki-Aufruf in eine einzelne HTTPS-Anfrage an einen Cockpit-v2-Proxy-Endpunkt umwandelt. Der Proxy führt die eigentliche kryptografische Operation gegen das Mandanten-Vault / HSM aus.

Anfragekette Oracle TDE → Cockpit v2TEXT

Oracle Database (ADMINISTER KEY MANAGEMENT …)
 │ PKCS#11 (Cryptoki v2.40 C_* calls)
 ▼
libdke_pkcs11.so / dke_pkcs11.dll (DuoKey PKCS#11 provider)
 │ HTTPS — one request per Cryptoki operation
 ▼
Cockpit v2 proxy endpoint
 │ encrypt / decrypt / wrap / unwrap / generate
 ▼
Tenant vault / HSM backend
 (DuoKey software keystore in dev · Securosys / HSM in production)

Zwei Eigenschaften sind wichtig zu verstehen:

Keine lokale Kryptografie

Die PKCS#11-Bibliothek hält keine Schlüssel und führt keine Kryptografie lokal aus. Jede Operation wird an den Cockpit-v2-Proxy weitergeleitet. Das TDE-Masterschlüsselmaterial liegt nie auf dem Datenbank-Host.

Ein einziges exportiertes Symbol

Oracle lädt die Bibliothek über den standardmäßigen Einsprungpunkt C_GetFunctionList, der die vollständige Cryptoki-Funktionstabelle zurückgibt.

Oracle TDE verwendet ausschließlich AES — nicht RSA oder ECC

Der Oracle-TDE-Masterverschlüsselungsschlüssel ist AES256. Laut Oracle-Dokumentation gilt: „Master encryption keys always are AES256" (sie verschlüsseln die Tabellen- / Tablespace-Schlüssel im CBC-Modus). Oracle TDE verwendet für den Masterschlüssel keine RSA- oder Elliptic-Curve-Schlüssel. Die DuoKey-PKCS#11-Bibliothek ist ein universeller Cryptoki-Provider, der auch RSA- und EC-Mechanismen für andere DuoKey-Integrationen bereitstellt — Oracle TDE nutzt jedoch nur den Pfad der AES-Schlüsselgenerierung und Ver-/Entschlüsselung (Wrap/Unwrap).

Von Oracle TDE genutzte PKCS#11-Operationen

Oracle nutzt nur die folgende Teilmenge. Die vollständige Funktionstabelle, die Mechanismen und das Attributmodell der Bibliothek finden Sie im eigenständigen Abschnitt PKCS#11-Bibliothek — dort wird der Provider vollständig dokumentiert.

Cryptoki-Operation	Rolle in Oracle TDE
C_Initialize / C_Finalize	Lädt die pkcs11.toml-Konfiguration und initialisiert / beendet die Bibliothek.
C_OpenSession / C_Login	Öffnet eine serielle Sitzung und wechselt in den Benutzerzustand — es wird keine PIN gesendet; das Bearer-Token pro Anfrage authentifiziert.
C_FindObjectsInit / C_FindObjects	Sucht den AES-Masterschlüssel anhand von CKA_LABEL / CKA_ID.
C_GenerateKey	Erstellt den AES256-TDE-Masterschlüssel.
C_Encrypt / C_Decrypt	Wrap / Unwrap der Tabellen- & Tablespace-Schlüssel unter dem Masterschlüssel.
C_GetAttributeValue	Liest Schlüsselattribute; CKA_VALUE wird verweigert (CKR_ATTRIBUTE_SENSITIVE) — die Masterschlüssel-Bytes verlassen das Backend nie.
C_DestroyObject	Setzt einen Masterschlüssel außer Betrieb.

Kryptografisches Modell

• Für Oracle TDE führt der Proxy Wrap und Unwrap der Tablespace-(Tabellen-)Schlüssel unter dem Masterschlüssel mit einem längenerhaltenden AES-CBC- / AES-CBC-PAD-Mechanismus durch. Dies ist zwingend erforderlich: Oracles SET KEY erwartet, dass der entpackte Schlüssel exakt die Größe hat, mit der er gepackt wurde, sodass ein expandierender AES-GCM-Umschlag (der einen IV und ein Auth-Tag anhängt) das gespeicherte Schlüssel-Blob beschädigt und ORA-00600 [kcbtse_populate_tbskey_1] auslöst. Der authentifizierte AES-GCM-Umschlagmodus wird nur als Fallback für Nicht-TDE-Aufrufer angeboten, die opake Blobs speichern; er darf auf dem Oracle-TDE-Wrap-Pfad nicht ausgewählt werden.
• Die Masterschlüssel-Bytes sind sensibel: C_GetAttributeValue verweigert CKA_VALUE. Bei einem echten HSM-Backend existiert das Schlüsselmaterial nie außerhalb des HSM.

Lebenszyklus des Master Encryption Key (MEK)

Jeder Masterschlüssel wird vom Cockpit mit seinem Label (CKA_LABEL), seiner Kennung (CKA_ID), Algorithmus und Schlüsselgröße, einem Verweis auf den zugrunde liegenden Vault-/HSM-Schlüssel sowie einem Lebenszyklusstatus nachverfolgt.

1

Erstellen

Wenn eine Oracle-TDE-App in Cockpit v2 erstellt wird, wird automatisch ein anfänglicher aktiver Masterschlüssel provisioniert (Label TDE-MASTER-<date>). Weitere Schlüssel können vom Cockpit oder von der Bibliothek über einen Schlüsselgenerierungsaufruf erstellt werden. Der Standardalgorithmus ist AES-256.

2

Öffnen / verwenden

Oracle öffnet den Keystore mit ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY EXTERNAL STORE und findet den MEK über C_FindObjects. Tablespace-(Tabellen-)Schlüssel werden durch Ver-/Entschlüsselung unter dem MEK geschützt. Im Bereitstellungsmodus mit Software-Keystore wird versiegeltes Schlüsselmaterial nach einem Cockpit-Neustart bedarfsgerecht in den Vault reimportiert; bei einem HSM-Backend verbleibt der Schlüssel im HSM.

3

Rotieren

Das Rotieren eines Schlüssels vom Cockpit aus deaktiviert den aktuellen Schlüssel, erstellt einen neuen aktiven MEK und liefert das Oracle-Rotations-SQL (ADMINISTER KEY MANAGEMENT SET KEY … WITH BACKUP) zurück. Alte Schlüssel bleiben deaktiviert, sodass zuvor per Wrap geschützte Tablespace-Schlüssel weiterhin entschlüsselbar bleiben.

Zustandsautomat

Zustandsübergänge des MasterschlüsselsTEXT

pre_active → active → deactivated → revoked / destroyed

Übergänge werden serverseitig durchgesetzt (nur ein Schlüssel im Zustand pre_active kann aktiviert werden; ein Schlüssel muss deaktiviert oder widerrufen sein, bevor er zerstört werden kann).

Authentifizierung von Management- vs. Proxy-Operationen

• Der PKCS#11-Proxy-Endpunkt wird ausschließlich durch das access_guid-Bearer-Token authentifiziert.
• Die Management-Operationen (Erstellen / Rotieren / Aktivieren / … ) erfordern eine Cockpit-Benutzersitzung mit der passenden rollenbasierten Berechtigung und unterliegen zusätzlich der Durchsetzung von Zugriffsrichtlinien.

API-Referenz

Detaillierte API-Endpunkte sind separat in den Entwicklerdokumenten → DKE-API dokumentiert.

Nächster Schritt

Fahren Sie fort mit PKCS#11-Provider-Konfiguration (pkcs11.toml), um den Provider zu konfigurieren.