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é avec une fenêtre de chevauchement, 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.
Chevauchement de rotation de clé
cache_duration_hours (24 par défaut). Pendant la rotation, la clé précédente continue de servir GetKey + Decrypt pendant cette fenêtre (previous_key_id / previous_key_retires_at).
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 afin de chiffrer le contenu sous la clé publique de l'organisation. La clé publiée est une JWK RSA standard dont le kid correspond à l'URL du service (https://{slug}.{base-domain}/dke/{slug}/{key_name}/{key_id}).
Decrypt
Office renvoie la clé encapsulée. Cockpit v2 résout le service, exige le statut Running, sélectionne la clé effective (actuelle, ou la clé précédente pendant la fenêtre de rotation), 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.
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.