Intégration Oracle TDE avec Cockpit v2
Comment Oracle Transparent Data Encryption se connecte à Cockpit v2 via le fournisseur PKCS#11 de DuoKey.
Cette page décrit comment Oracle Transparent Data Encryption se connecte à Cockpit v2. Pour le chemin du Cockpit v1 historique, consultez la section Installation et configuration de ce guide.
Une courte vidéo de démonstration du flux Oracle TDE ↔ Cockpit v2 de bout en bout sera ajoutée ici.
La chaîne d'intégration
Oracle ne communique jamais directement avec Cockpit v2. Il charge le fournisseur PKCS#11 de DuoKey (une bibliothèque native), qui transforme chaque appel Cryptoki en une unique requête HTTPS vers un point de terminaison proxy de Cockpit v2. Le proxy effectue l'opération cryptographique réelle auprès du coffre du tenant / HSM.
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)
Deux propriétés sont importantes à comprendre :
Aucune cryptographie locale
La bibliothèque PKCS#11 ne détient aucune clé et n'effectue aucune opération cryptographique localement. Chaque opération est acheminée vers le proxy Cockpit v2. Le matériel de la clé maître TDE ne réside jamais sur l'hôte de la base de données.
Un seul symbole exporté
Oracle charge la bibliothèque via le point d'entrée standard C_GetFunctionList, qui retourne la table complète des fonctions Cryptoki.
La clé maître de chiffrement Oracle TDE est en AES256. Selon la documentation d'Oracle, « Les clés maîtres de chiffrement sont toujours en AES256 » (elles chiffrent les clés de table / tablespace en mode CBC). Oracle TDE n'utilise pas de clés RSA ou à courbe elliptique pour la clé maître. La bibliothèque PKCS#11 de DuoKey est un fournisseur Cryptoki généraliste qui annonce également des mécanismes RSA et EC pour d'autres intégrations DuoKey — mais Oracle TDE n'exerce que le chemin de génération de clé AES et de chiffrement/déchiffrement (encapsulation/désencapsulation).
Opérations PKCS#11 utilisées par Oracle TDE
Oracle ne pilote que le sous-ensemble ci-dessous. Pour la table complète des fonctions de la bibliothèque, les mécanismes et le modèle d'attributs, voir la section autonome Bibliothèque PKCS#11 — c'est là que le fournisseur est documenté intégralement.
| Opération Cryptoki | Rôle dans Oracle TDE |
|---|---|
C_Initialize / C_Finalize | Charge la configuration pkcs11.toml et initialise / arrête la bibliothèque. |
C_OpenSession / C_Login | Ouvre une session série et passe à l'état utilisateur — aucun PIN n'est envoyé ; le jeton porteur par requête assure l'authentification. |
C_FindObjectsInit / C_FindObjects | Localise la clé maître AES par CKA_LABEL / CKA_ID. |
C_GenerateKey | Crée la clé maître TDE AES256. |
C_Encrypt / C_Decrypt | Encapsule / désencapsule les clés de table & tablespace sous la clé maître. |
C_GetAttributeValue | Lit les attributs de clé ; CKA_VALUE est refusé (CKR_ATTRIBUTE_SENSITIVE) — les octets de la clé maître ne quittent jamais le backend. |
C_DestroyObject | Retire une clé maître. |
Modèle cryptographique
- Le proxy effectue un chiffrement d'enveloppe authentifié sous la clé maître (MEK). Comme le chiffrement et le déchiffrement utilisent la même primitive du coffre, le mécanisme Cryptoki est indicatif — l'intégrité aller-retour est garantie pour les blobs de clé opaques stockés par Oracle.
- Les octets de la clé maître sont sensibles :
C_GetAttributeValuerefuseCKA_VALUE. Avec un backend HSM réel, le matériel de clé n'existe jamais en dehors du HSM.
Cycle de vie de la clé maître de chiffrement (MEK)
Chaque clé maître est suivie par le Cockpit avec son label (CKA_LABEL), son identifiant (CKA_ID), son algorithme et sa taille de clé, une référence à la clé du coffre/HSM sous-jacente, et un état de cycle de vie.
Créer
Lorsqu'une app Oracle TDE est créée dans Cockpit v2, une clé maître active initiale est provisionnée automatiquement (label TDE-MASTER-<date>). D'autres clés peuvent être créées depuis le Cockpit ou depuis la bibliothèque via un appel de génération de clé. L'algorithme par défaut est AES-256.
Ouvrir / utiliser
Oracle ouvre le keystore avec ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY EXTERNAL STORE et localise la MEK via C_FindObjects. Les clés de tablespace (table) sont protégées par chiffrement / déchiffrement sous la MEK. En mode de déploiement software-keystore, le matériel de clé scellé est réimporté paresseusement dans le coffre après un redémarrage du Cockpit ; avec un backend HSM, la clé reste dans le HSM.
Faire pivoter
Faire pivoter une clé depuis le Cockpit désactive la clé actuelle, crée une nouvelle MEK active, et renvoie le SQL de rotation Oracle (ADMINISTER KEY MANAGEMENT SET KEY … WITH BACKUP). Les anciennes clés restent désactivées afin que les clés de tablespace précédemment encapsulées restent déchiffrables.
Machine à états
pre_active → active → deactivated → revoked / destroyed
Les transitions sont appliquées côté serveur (seule une clé pre_active peut être activée ; une clé doit être désactivée ou révoquée avant de pouvoir être détruite).
Authentification des opérations de gestion vs proxy
- Le point de terminaison proxy PKCS#11 est authentifié uniquement par le jeton porteur
access_guid. - Les opérations de gestion (créer / faire pivoter / activer / … ) nécessitent une session utilisateur Cockpit avec la permission basée sur les rôles appropriée, et sont en outre soumises à l'application des politiques d'accès.
Continuez avec Configuration du fournisseur PKCS#11 (pkcs11.toml) pour configurer le fournisseur.