Table des matières
- Fonctionnement de DuoKey DKE
- Pourquoi ne pas héberger vous-même le service de clés
- Avant de commencer
- Étape 1 : Se connecter à DuoKey Cockpit
- Étape 2 : Créer une clé DKE
- Étape 3 : Déployer le service DKE
- Étape 4 : Accorder le consentement administrateur
- Étape 5 : Créer l'étiquette de sensibilité dans Purview
- Étape 6 : Publier la stratégie d'étiquette
- Étape 7 : Appliquer l'étiquette dans Microsoft 365
- Ajouter le contrôle d'accès Zero Trust
- Faire tourner les clés sans toucher à vos étiquettes
- Mener un pilote avant le déploiement
- Dépannage
- Références
Double Key Encryption (DKE) est le seul mode de protection de Microsoft 365 dans lequel Microsoft ne peut pas déchiffrer votre contenu, car l'une des deux clés n'entre jamais dans le cloud de Microsoft. La difficulté a toujours été d'exploiter cette seconde clé. La réponse de Microsoft est un projet .NET d'exemple que vous devez compiler, héberger sur IIS ou App Service, relier à un magasin de clés et maintenir en fonctionnement vous-même.
DuoKey remplace tout cela. La seconde clé réside dans le coffre MPC de DuoKey, le point de terminaison DKE est déployé depuis un assistant dans DuoKey Cockpit, et chaque demande de déchiffrement passe par une politique Zero Trust que vous contrôlez. Ce guide suit les mêmes sept étapes que la documentation DuoKey DKE : d'un tenant Cockpit vide à un document Word protégé.
Fonctionnement de DuoKey DKE

Les deux clés sont nécessaires pour ouvrir un document DKE. Microsoft détient l'une dans Azure RMS ; vous détenez l'autre dans le coffre MPC de DuoKey.
Lorsqu'un utilisateur applique une étiquette de sensibilité DKE dans Word, Excel, PowerPoint, Outlook ou Adobe Acrobat :
- Le client Office chiffre le contenu avec une clé protégée par votre clé DuoKey (clé 2), récupérée depuis votre point de terminaison DuoKey DKE.
- Le résultat est ensuite protégé une seconde fois avec la clé Azure RMS de Microsoft (clé 1).
- Pour ouvrir le document, le client a besoin des deux. Azure RMS vérifie les droits de l'utilisateur ; DuoKey vérifie le jeton d'identité de l'utilisateur et votre politique d'accès avant de déballer la clé 2.
La clé DuoKey n'est jamais détenue en entier sur une seule machine. Elle est répartie entre des nœuds MPC indépendants, et le déballage est calculé conjointement, de sorte que ni Microsoft, ni le personnel de DuoKey, ni un attaquant qui compromettrait un nœud ne peut la reconstituer. Vous pouvez visualiser le flux complet, en temps réel, sur la page de détail de chaque service dans Cockpit :

Un service DKE en fonctionnement dans DuoKey Cockpit : contrôles de santé, compteurs GetKey et Decrypt, durée de cache et flux de bout en bout Microsoft 365 → Azure RMS → Zero Trust → Cockpit → coffre.
Pourquoi ne pas héberger vous-même le service de clés
Microsoft documente DKE avec un magasin de clés de référence que vous construisez vous-même. Cela fonctionne pour un laboratoire. En production, chacun de ses éléments devient votre problème.
| Exemple Microsoft (auto-hébergé) | DuoKey DKE |
|---|
| Service de clés | Compiler l'exemple .NET, l'héberger sur IIS ou App Service | Déployé depuis un assistant Cockpit, sans code |
| Stockage des clés | Magasin de fichiers ou Key Vault à raccorder vous-même | Coffre MPC, la clé n'existe jamais en un seul endroit |
| TLS, DNS, disponibilité | À construire et surveiller vous-même | Opérés par DuoKey, contrôles de santé dans Cockpit |
| Inscription d'application Entra ID | Manuelle, plus modifications de appsettings.json | Provisionnée automatiquement à l'activation du service |
| Contrôle d'accès | Liste d'autorisation par e-mail ou rôle dans des fichiers de configuration | Politiques ABAC : utilisateur, groupe, localisation, IP, horaire |
| Rotation des clés | Republier les clés, mettre à jour les étiquettes | Un clic, URL de l'étiquette inchangée |
| Audit | Journalisation à construire vous-même | Chaque GetKey et Decrypt journalisé par service |
| Souveraineté | Dépend de l'endroit où vous l'hébergez | Opéré en Suisse, ou sur site / dans votre cloud |
Si vous devez conserver le service de clés à l'intérieur de votre propre périmètre, DuoKey Cockpit peut également fonctionner sur site ou sur OpenShift : les étapes de configuration ci-dessous restent les mêmes.
Avant de commencer
Côté Microsoft
- Des licences incluant Microsoft Purview Information Protection avec DKE, comme Microsoft 365 E5 ou E5 Compliance, pour chaque utilisateur qui protège ou ouvre du contenu DKE.
- Microsoft 365 Apps for enterprise (bureau) sur les postes clients. Office pour le web et les applications mobiles ne peuvent pas ouvrir les fichiers protégés par DKE.
- Un Global Administrator (administrateur général, ou équivalent) pour le consentement administrateur unique de l'étape 4.
- Un Compliance Administrator (administrateur de conformité) pour créer et publier les étiquettes de sensibilité dans Purview.
- Votre ID de tenant Entra ID (centre d'administration Entra → Overview).
Côté DuoKey
- Un accès à votre tenant DuoKey Cockpit sur cockpit.duokey.cloud (ou à l'URL de votre Cockpit sur site).
- Au moins un coffre dans Cockpit pour héberger la clé DKE.
Réseau
- HTTPS sortant (443) depuis les postes clients vers votre point de terminaison DuoKey DKE,
login.microsoftonline.com et les points de terminaison Azure RMS (*.aadrm.com, *.protection.outlook.com). La liste complète figure sur la page de liste blanche des URL.
- Excluez ces hôtes de l'inspection SSL. Un proxy qui intercepte TLS casse l'échange DKE.
Étape 1 : Se connecter à DuoKey Cockpit
Connectez-vous à cockpit.duokey.cloud. Si vous gérez plusieurs tenants, sélectionnez celui qui détiendra les clés Microsoft 365. Tout ce qui suit (clés, services et politiques d'accès) est rattaché à ce tenant.
Étape 2 : Créer une clé DKE
- Ouvrez l'onglet Keys (Clés) et cliquez sur New Key (Nouvelle clé).
- Sélectionnez le coffre qui hébergera la clé.
- Choisissez RSA-2048. Le client Microsoft DKE exige RSA-2048 et n'accepte pas RSA-4096.
- Donnez à la clé un nom descriptif qui indique sa finalité et son niveau de sensibilité, par exemple
key-confidential-finance ou key-topsecret-hr.
- Vérifiez puis cliquez sur Generate the Key (Générer la clé).
Cockpit génère la paire de clés à l'intérieur du coffre, lui attribue un External ID unique et l'active. La clé privée n'est jamais exportée.
Étape 3 : Déployer le service DKE
Le service DKE est le point de terminaison HTTPS qu'Office appelle pour récupérer la clé publique et demander des déchiffrements. Dans Cockpit, ouvrez DKE 365 et cliquez sur Deploy new service (Déployer un nouveau service). L'assistant comporte cinq écrans :
- Key. Sélectionnez le coffre et la clé RSA-2048 de l'étape 2. Cockpit exécute une vérification préalable (validité de la clé, accessibilité du backend et aller-retour wrap/unwrap) avant de vous laisser continuer.
- Service. Saisissez un nom et une description, conservez l'algorithme RSA-OAEP-256, et définissez la cache duration (durée de cache) : le nombre d'heures pendant lesquelles la clé précédente continue de servir les requêtes après une rotation (24 par défaut).
- Identity. Sélectionnez votre fournisseur d'identité et saisissez votre Azure tenant ID, votre client ID et votre audience. Cockpit les utilise pour provisionner automatiquement l'inscription d'application Entra ID. Ne laissez pas l'ID de tenant vide en production : sans lui, le service fonctionne dans un mode de test permissif.
- Access control. Associez éventuellement une politique d'accès dès maintenant (vous pourrez en ajouter une plus tard, voir Zero Trust), et activez éventuellement mTLS pour un contrôle supplémentaire au niveau du transport sur les appels de déchiffrement.
- Review. Vérifiez le récapitulatif et cliquez sur Deploy.
Le service démarre à l'état Provisioned. Activez-le : il passe à l'état Running et, si aucune application Entra ID n'existe encore, Cockpit en crée une pour vous.
Ouvrez ensuite la page de détail du service et copiez son DKE Access URL. Elle se présente ainsi :
https://<service-id>.duokey365.com/dke/<key-id>
Vous n'avez pas besoin de la construire à la main. C'est cette URL que vous collerez dans l'étiquette Purview à l'étape 5.
Étape 4 : Accorder le consentement administrateur
Le service DKE est une application Entra ID située en dehors de votre tenant ; un Global Administrator doit donc y consentir une fois. Cela permet à Office de demander des jetons pour le point de terminaison DuoKey au nom de vos utilisateurs.
- Dans Cockpit, ouvrez votre service DKE, cliquez sur Edit (Modifier) et avancez jusqu'à la section Service API. Copiez l'Azure DKE Client Id.
- Construisez l'URL de consentement avec votre ID de tenant et ce client ID :
https://login.microsoftonline.com/<tenant-id>/adminconsent?client_id=<azure-dke-client-id>
- Ouvrez-la dans un navigateur en étant connecté en tant que Global Administrator et cliquez sur Accept. En cas de succès, vous êtes redirigé vers la page de connexion de Cockpit.
- Vérification facultative : le service apparaît désormais dans le centre d'administration Entra sous Enterprise applications, avec le nom que vous lui avez donné.
Étape 5 : Créer l'étiquette de sensibilité dans Purview
Dans le portail Microsoft Purview, allez dans Information Protection → Sensitivity labels → Create a label.
- Nom et description. Par exemple
Highly Confidential - DuoKey DKE, avec une description destinée aux utilisateurs qui explique quand l'utiliser.
- Portée. Sélectionnez Files et Emails. DKE ne s'applique pas aux réunions, groupes ou sites.
- Paramètres de protection. Sélectionnez uniquement Control access (Contrôler l'accès).
- Contrôle d'accès.
- Attribuez des autorisations aux utilisateurs ou groupes autorisés à ouvrir ce contenu, avec le niveau approprié (Viewer, Reviewer, Co-Author, Co-Owner).
- Définissez l'accès hors connexion. Choisissez Never pour le contenu le plus sensible (dossiers RH, code source, résultats financiers) : un utilisateur révoqué ne peut alors plus rouvrir une copie en cache. Choisissez Always uniquement pour du contenu moins sensible ; les utilisateurs conservent l'accès jusqu'à 30 jours après le retrait de leurs droits.
- Cochez Use Double Key Encryption (Utiliser Double Key Encryption) et collez la DKE Access URL de l'étape 3, exactement telle qu'elle apparaît dans Cockpit.
- Marquage du contenu (facultatif). Ajoutez un en-tête, un pied de page ou un filigrane afin que les utilisateurs voient que le document est protégé par DKE.
- Vérifiez et cliquez sur Create label.
Étape 6 : Publier la stratégie d'étiquette
Une étiquette reste invisible pour les utilisateurs tant qu'une stratégie ne la publie pas.
- Sur la page Sensitivity labels, sélectionnez votre nouvelle étiquette et cliquez sur Publish label (Publier l'étiquette). Vous pouvez publier plusieurs étiquettes dans une même stratégie.
- Ciblez d'abord un groupe pilote, pas l'ensemble des utilisateurs.
- Activez Users must provide a justification to remove a label or lower its classification (les utilisateurs doivent justifier la suppression d'une étiquette ou l'abaissement de sa classification).
- Nommez la stratégie et validez.
La publication prend de quelques minutes à plusieurs heures selon la taille de votre tenant. Les utilisateurs doivent redémarrer leurs applications Office pour voir la nouvelle étiquette ; il faut parfois une déconnexion complète ou un redémarrage du poste.
Étape 7 : Appliquer l'étiquette dans Microsoft 365
- Ouvrez un document dans Word (ou Excel, PowerPoint, Outlook).
- Cliquez sur Sensitivity (Sensibilité) dans le ruban Accueil et sélectionnez votre étiquette DuoKey DKE.
- Le document est immédiatement chiffré, marqué avec l'étiquette, et ne peut être ouvert que par les utilisateurs à la fois autorisés par l'étiquette et admis par votre politique d'accès DuoKey.
De retour dans Cockpit, le compteur GetKey du service augmente lorsque l'étiquette est appliquée, et le compteur Decrypt chaque fois qu'un utilisateur autorisé ouvre le fichier. Adobe Acrobat, avec la prise en charge de Microsoft Purview Information Protection, peut appliquer la même étiquette aux PDF, en utilisant le même service DuoKey.
Ajouter le contrôle d'accès Zero Trust

Chaque demande de déchiffrement est évaluée par le moteur de politiques de DuoKey avant que la clé 2 ne soit libérée.
Purview décide qui a des droits sur un document. DuoKey ajoute une seconde décision, indépendante, à chaque déchiffrement, sous votre contrôle et non sous celui de Microsoft. Une politique d'accès Cockpit combine plusieurs dimensions :
- Qui : des utilisateurs précis ou des groupes du fournisseur d'identité.
- Où : pays autorisés et bloqués, plages d'adresses IP.
- Quand : heures ouvrées ou plages de dates.
Une politique de déchiffrement DKE typique n'autorise que les membres du groupe destinataire de l'étiquette, depuis les pays de votre entreprise, pendant les heures ouvrées, et bloque purement et simplement les pays sous sanctions. Créez-la sous Access policies dans Cockpit, puis associez-la au service (DKE 365 → Actions → Edit → Access control). Elle s'applique dès la demande de déchiffrement suivante ; aucune modification de l'étiquette n'est nécessaire. Si vous devez couper entièrement l'accès, la désactivation ou l'arrêt du service bloque toute nouvelle demande de déchiffrement pour les documents protégés par sa clé (hors licences hors connexion en cache, voir l'étape 5). Consultez Contrôle d'accès Zero Trust pour Microsoft 365 pour des exemples détaillés.
Faire tourner les clés sans toucher à vos étiquettes
Depuis Cockpit 2.0.8, l'URL de l'étiquette identifie le service, et non une clé spécifique. La rotation se résume à un seul clic sur Rotate key (Faire tourner la clé) dans la page du service :
- Les nouveaux documents sont chiffrés avec la nouvelle clé. L'étiquette Purview ne change pas.
- La clé précédente passe dans l'historique des clés du service en mode decrypt-only (déchiffrement uniquement), de sorte que les documents existants restent lisibles.
- Lorsqu'aucun document n'a plus besoin d'une ancienne clé, un administrateur peut la retirer. Une clé retirée peut être restaurée.
- Renommer une clé ne change rien pour Office, car les URL contiennent des identifiants, pas des noms.
Mener un pilote avant le déploiement
DKE modifie le comportement des fichiers protégés : ils ne sont pas indexés par la recherche Microsoft, eDiscovery ne peut pas les lire, et Office pour le web et les applications mobiles ne peuvent pas les ouvrir. Menez un pilote avec de vrais utilisateurs avant de publier largement l'étiquette. Le programme pilote DuoKey DKE couvre :
- la création, la modification et le partage sur postes fixes et portables ;
- le comportement sur mobiles et tablettes, afin que les utilisateurs sachent à quoi s'attendre ;
- le partage externe et la collaboration B2B ;
- la révocation : retirer un utilisateur, désactiver une politique et confirmer que l'accès est bien coupé ;
- l'audit : rapprocher les journaux Cockpit des actions effectuées par les utilisateurs.
Réservez l'étiquette DKE au contenu qui en a réellement besoin (dossiers de fusions-acquisitions, documents couverts par le secret professionnel de l'avocat, données personnelles réglementées, secrets d'affaires) et conservez les étiquettes Purview standard pour la collaboration courante.
Dépannage
| Symptôme | Cause la plus probable | Solution |
|---|
| « Word ne peut pas enregistrer ou créer ce fichier » | Le client ne peut pas joindre le point de terminaison DKE | Office utilise le proxy WinHTTP, pas celui du navigateur. Vérifiez le proxy système et autorisez le trafic sortant 443 vers l'URL DKE et la connexion Entra. |
| Le navigateur ouvre l'URL DKE mais Office échoue | Inspection SSL ou proxy | Ajoutez les hôtes DKE, Entra et RMS à la liste d'exclusion de l'inspection SSL. |
| L'étiquette n'apparaît pas dans Office | Stratégie pas encore propagée | Attendez la fin de la publication, redémarrez les applications Office, puis le poste si nécessaire. |
| « Azure Information Protection ne peut pas appliquer cette étiquette » | Étiquette non publiée ou absente de la stratégie de l'utilisateur | Vérifiez l'état de l'étiquette et les utilisateurs ciblés par la stratégie. |
| Erreur d'autorisation après application de l'étiquette | Utilisateur non autorisé par l'étiquette, ou bloqué par la politique DuoKey | Vérifiez les autorisations de l'étiquette, puis la politique d'accès Cockpit et les journaux du service. |
| Demande de clé rejetée | Key ID incorrect ou consentement manquant | Recopiez l'Access URL depuis Cockpit (les identifiants sont sensibles à la casse) et confirmez le consentement administrateur dans Enterprise applications. |
Pour obtenir le détail côté client, activez la journalisation MSIP (%LOCALAPPDATA%\Microsoft\MSIP\Logs) et reproduisez le problème. Le guide de dépannage DKE complet traite chaque cas pas à pas.
Prochaines étapes
Vous disposez désormais d'une clé détenue par le client qui protège le contenu Microsoft 365, servie par DuoKey, régie par votre propre politique d'accès, et que vous pouvez faire tourner sans toucher à Purview. Pour cadrer un pilote pour votre tenant, contactez notre équipe ou découvrez DuoKey pour Microsoft 365.
Références