Configuration DKE dans Cockpit v2
Les fonctions de configuration du Double Key Encryption (DKE 365) exposées par DuoKey Cockpit v2.
Cette page documente les fonctions de configuration DKE 365 exposées par DuoKey Cockpit v2. Pour le flux de travail du Cockpit v1 historique, consultez les sections Configuration et Opérations de ce guide.
Deux familles de points de terminaison
DKE 365 expose deux types de points de terminaison :
- Une surface de gestion utilisée par les administrateurs du Cockpit pour déployer, configurer et gérer les services DKE. Elle est protégée par une session utilisateur Cockpit et le contrôle d'accès basé sur les rôles de la plateforme.
- Le protocole DKE public que Microsoft 365 / Office appellent directement :
GetKeyest public, tandis queDecryptvalide un jeton porteur Azure AD lorsqu'il est configuré et applique la politique d'accès liée.
Cycle de vie du service
Provisioned → Running → Disabled → Stopped (+ Failed)
Seul un service à l'état Running sert les requêtes de déchiffrement.
Gérer un service
Depuis le Cockpit, vous pouvez déployer un nouveau service DKE, valider qu'une clé est compatible DKE, l'activer (ce qui provisionne automatiquement l'app Azure AD), le désactiver ou l'arrêter, faire pivoter sa clé (voir Rotation des clés et historique des clés), et surveiller son état de santé ainsi que les indications d'intégration (DNS / CNAME). Microsoft 365 / Office appellent ensuite directement les points de terminaison du protocole public du service (version, GetKey et Decrypt).
Champs de configuration du service
Un service DKE se configure avec :
Identité et routage
name, description, slug (un GUID utilisé pour construire l'URL du service), key_id (la clé RSA-2048/4096 liée), key_name (exposé dans l'URL kid publiée), status.
Algorithme
algorithm : RSA-OAEP-256 (par défaut) ou RS256.
Historique des clés
Une clé retirée de la rotation reste en déchiffrement seul dans l'historique des clés du service jusqu'à ce qu'un administrateur la retire — voir Rotation des clés et historique des clés. cache_duration_hours (24 par défaut) reste accepté sur le service.
Azure AD / Entra
azure_tenant_id, azure_client_id, azure_audience, allowed_domains (domaines partenaires B2B, chacun étant associé aux émetteurs valides de son propre tenant), identity_provider_id (identifiants Graph utilisés pour provisionner automatiquement l'app).
mTLS optionnel
mtls_enabled, mtls_client_ca_pem, mtls_allowed_subjects, mtls_header_name (par défaut X-ARR-ClientCert).
Déchiffrement permissif
allow_anonymous (honoré uniquement hors production, lorsque l'hôte active également le mode permissif ; ne doit jamais être utilisé en production).
Contrôle d'accès
access_policy_id lie une politique d'accès évaluée à chaque déchiffrement.
Exemple de configuration de service
{
"name": "Contoso DKE",
"slug": "89c3b193-af16-4887-8031-43f88d475d9d",
"key_id": "<rsa-key-uuid>",
"key_name": "dke_key",
"azure_tenant_id": "<azure-tenant-guid>",
"azure_client_id": "<app-guid>",
"azure_audience": "https://89c3b193-af16-4887-8031-43f88d475d9d.duokey365.com",
"allowed_domains": ["partner.com"],
"algorithm": "RSA-OAEP-256",
"cache_duration_hours": 24,
"mtls_enabled": false,
"allow_anonymous": false,
"access_policy_id": "<policy-uuid>",
"identity_provider_id": "<idp-uuid>"
}
Flux GetKey / Decrypt
GetKey
Office récupère la JWK publique du service depuis l'URL d'étiquette (https://{slug}.{base-domain}/dke/{slug}) afin de chiffrer le contenu sous la clé publique de l'organisation. La clé publiée est une JWK RSA standard dont le kid désigne la version courante de la clé (https://{slug}.{base-domain}/dke/{slug}/{key_id}).
Decrypt
Office renvoie la clé encapsulée au kid enregistré dans le document. Cockpit v2 résout le service, exige le statut Running, sélectionne la clé que désigne le kid (la clé courante, ou une clé en déchiffrement seul de l'historique), effectue une validation mTLS optionnelle, valide le JWT Azure AD, applique la politique d'accès liée, puis déchiffre en RSA-OAEP dans le coffre. La clé privée ne quitte jamais le coffre.
Chaque déchiffrement est limité en débit par tenant (100 requêtes/seconde par défaut, configurable).
La clé publiée et les payloads de requête/réponse suivent le format du protocole DKE de Microsoft, de sorte qu'Office et Purview interopèrent avec le service sans configuration particulière.
Rotation des clés et historique des clés
Depuis Cockpit 2.0.8, une rotation ne modifie pas l'URL de l'étiquette de confidentialité. Pour faire pivoter la clé manuellement ou selon un calendrier (tous les 30, 180 ou 365 jours, ou un intervalle personnalisé), voir Rotation des clés.
| Élément | Comportement |
|---|---|
| URL d’étiquette | L'URL à saisir dans l'étiquette Purview est https://{slug}.{base-domain}/dke/{slug}. Elle désigne le service, et non une clé, et elle est affichée sur la page de détail du service. |
| Rotation | Les nouveaux documents sont chiffrés avec la nouvelle clé. Le kid change ; l'URL d'étiquette ne change pas. |
| Clés retirées de la rotation | Conservées dans l’historique des clés du service en déchiffrement seul, afin que les documents chiffrés avec elles restent lisibles. Une clé retirée de la rotation n’expire plus d’elle-même. |
| Retrait / restauration | Un administrateur retire une clé de l’historique lorsqu’aucun document n’en a plus besoin ; une clé retirée répond 404. Une clé retirée peut être restaurée. |
| Renommage de clé | Les URL contiennent le slug du service et l’identifiant de la clé, jamais le nom de la clé : renommer une clé ne change donc rien pour Office. Le service affiche le nouveau nom. |
Une étiquette dont l'URL désigne une clé (https://{slug}.{base-domain}/dke/{key_id}) continue de fonctionner. Depuis la 2.0.9, elle suit aussi les rotations : elle chiffre les nouveaux documents avec la clé courante du service, sans modification de l'étiquette.
Provisionnement Azure AD (« enregistrer » le service)
Il n'existe pas d'étape « enregistrement » distincte. L'enregistrement = déployer → activer. Lors de l'enable, si le service possède un identity_provider_id et n'a pas encore d'app Azure, Cockpit v2 appelle Microsoft Graph pour créer et configurer l'enregistrement de l'app Azure AD (URI d'identifiant / audience, URL de redirection), puis stocke les valeurs résultantes azure_client_id, azure_audience et azure_app_object_id. Les identifiants Graph proviennent soit du fournisseur d'identité du service, soit du repli hôte DKE_DEFAULT_GRAPH_* (qui nécessite Application.ReadWrite.All).
Paramètres DKE au niveau de l'hôte (environnement Cockpit v2)
Ces variables d'environnement sont définies sur le serveur Cockpit v2 :
| Variable | Rôle |
|---|---|
DKE_BASE_DOMAIN | Base DNS pour les URL de connexion des services — chaque service est https://{slug}.{DKE_BASE_DOMAIN} (nécessite un DNS générique + TLS) |
DKE_AUDIENCE_DOMAIN | Audience JWT / apex de l'URI d'identifiant Azure AD (se replie sur DKE_BASE_DOMAIN) |
DKE_DEFAULT_GRAPH_TENANT_ID / DKE_DEFAULT_GRAPH_CLIENT_ID / DKE_DEFAULT_GRAPH_CLIENT_SECRET | App Microsoft Graph de repli utilisée pour provisionner automatiquement les enregistrements Azure AD |
DKE_ALLOW_PERMISSIVE_MODE | Active le déchiffrement permissif — dev/test uniquement — doit être désactivé (non défini) en production |
DKE_TENANT_DECRYPT_RPS_MAX | Plafond de débit de déchiffrement par tenant (100 par défaut) |
DKE_JWKS_CACHE_TTL_SECS | Durée de vie du cache JWKS Azure AD pour la validation du jeton de déchiffrement |
Microsoft Purview
DKE constitue le magasin de clés DKE pour Purview / MIP : les étiquettes de confidentialité de type Double Key Encryption pointent vers ces points de terminaison GetKey / Decrypt (les étiquettes sont configurées côté Microsoft — voir Étiquettes de confidentialité et Microsoft Purview). Cockpit v2 propose en outre un type d'app Purview DLP distinct pour l'intégration de la prévention de la perte de données.
Continuez avec Politiques d'accès pour contrôler qui, depuis où, et quand peut utiliser une clé DKE.