Le chiffrement à double clé (Double Key Encryption, DKE) est un mode de protection de Microsoft Purview qui chiffre les contenus les plus sensibles de Microsoft 365 avec deux clés : l'une détenue par Microsoft dans Azure, l'autre détenue par vous, hors de Microsoft. Ouvrir un document ou un e-mail protégé exige les deux clés. Microsoft ne peut donc pas lire ces contenus seul. (Microsoft Learn : Double Key Encryption)
Cette page est la définition. Pour le déploiement pas à pas avec DuoKey, voir le guide de configuration DKE. Pour choisir un fournisseur, voir le comparatif des fournisseurs DKE.
Sommaire
- Pourquoi une double clé ?
- Comment fonctionne le chiffrement à double clé
- Ce que DKE couvre, et ce qu'il ne couvre pas
- Prérequis
- DKE, Customer Key et chiffrement par défaut
- Quand déployer DKE
- Comment DuoKey détient la clé externe
- Questions fréquentes
Pourquoi une double clé ?
Par défaut, Microsoft 365 chiffre les données au repos et en transit avec des clés que Microsoft gère. Le chiffrement est solide, mais celui qui détient la clé peut déchiffrer. Une clé compromise chez le fournisseur, une erreur d'administration ou une demande légale adressée au fournisseur suffisent alors à exposer les données.
Le CLOUD Act américain illustre ce dernier point : le Département de la Justice des États-Unis indique qu'il vise les données en la « possession, garde ou contrôle » du fournisseur, quel que soit le lieu de stockage, et qu'il est « neutre vis-à-vis du chiffrement ». (DOJ : The Purpose and Impact of the CLOUD Act) Ce que le fournisseur peut produire dépend donc de la clé qu'il détient. Avec DKE, la clé décisive reste chez vous.
DKE s'active par une étiquette de sensibilité Microsoft Purview. Quand un utilisateur applique cette étiquette dans Word, Excel, PowerPoint ou Outlook, le client Office protège le contenu deux fois :
- avec votre clé, obtenue auprès du service DKE que vous exploitez ou confiez à un prestataire ;
- avec la clé Azure Rights Management de Microsoft.
Pour ouvrir le contenu, il faut les deux. Azure RMS vérifie les droits de l'utilisateur ; votre service DKE vérifie son identité avant de déverrouiller votre clé. Microsoft ne détient jamais cette seconde clé.

Les deux clés sont nécessaires. Microsoft détient l'une dans Azure RMS ; l'autre reste dans le service de clés du client.
Ce que DKE couvre, et ce qu'il ne couvre pas
Microsoft destine DKE à une petite part des contenus, environ 5 % dans sa propre illustration. Comme Microsoft ne peut pas lire les éléments protégés, plusieurs fonctions s'arrêtent sur ces éléments :
- eDiscovery, recherche et indexation ;
- règles de flux de messagerie qui inspectent les pièces jointes, y compris l'analyse antimalware et antispam ;
- Office sur le web et la coédition ;
- Microsoft 365 Copilot ;
- les réunions, conversations et éléments de calendrier Teams ne peuvent pas être protégés par une étiquette DKE.
Les fichiers protégés peuvent être stockés dans SharePoint et OneDrive et envoyés par e-mail, mais ils s'ouvrent dans les applications de bureau, pas en ligne. (Microsoft Learn : Double Key Encryption)
Prérequis
| Prérequis | Détail |
|---|
| Licences | Microsoft 365 E5, A5 ou G5, EMS E5, Microsoft Purview Suite et les modules E5 Information Protection and Governance, entre autres (description du service Microsoft Purview) |
| Service de chiffrement | Azure Rights Management de Microsoft Purview Information Protection |
| Applications | Microsoft 365 Apps for enterprise sous Windows ; hors Office, l'étiqueteur de fichiers Purview, PowerShell et le scanner |
| Service de clés | Un service DKE accessible en HTTPS et enregistré dans Microsoft Entra ID, hébergé par vous ou par un fournisseur |
| Connectivité | DKE a besoin d'Azure : pas d'environnement totalement isolé (air-gapped) |
DKE, Customer Key et chiffrement par défaut
| Chiffrement par défaut | Customer Key | Chiffrement à double clé (DKE) |
|---|
| Qui détient les clés | Microsoft | Vos clés racines dans Azure Key Vault, plus une clé de disponibilité protégée par Microsoft | Votre clé hors de Microsoft, et la clé de Microsoft : les deux sont requises |
| Microsoft 365 peut-il déchiffrer en fonctionnement normal ? | Oui | Oui, pour les services que vous autorisez | Non |
| Portée | Tout le service | Exchange, SharePoint, OneDrive, Teams, Windows 365 | Éléments étiquetés |
| Fonctions conservées | Toutes | Toutes | Pas de recherche, de coédition web ni de Copilot sur les éléments protégés |
Customer Key relève du modèle BYOK (qu'est-ce que BYOK). DKE relève du modèle HYOK (BYOK vs HYOK). De nombreux programmes combinent les deux : Customer Key sur le tenant, DKE sur les quelques étiquettes que Microsoft ne doit pas pouvoir lire seul.
Quand déployer DKE
DKE convient quand une autorité de surveillance, une règle du secteur public ou le conseil d'administration exige que le fournisseur ne puisse pas déchiffrer seul une catégorie de contenus nommée :
- dossiers de fusion-acquisition, documents du conseil, secrets d'affaires ;
- documents couverts par le secret professionnel ou le secret bancaire ;
- données personnelles sensibles ou données clients soumises à des règles de confidentialité ;
- informations des administrations publiques, par exemple en Suisse (Microsoft 365 pour l'administration publique suisse).
DKE n'est pas le bon outil si l'exigence est « chiffrer tout le tenant et garder la recherche, l'eDiscovery et Copilot ». Dans ce cas, c'est Customer Key ou le chiffrement par défaut.
DuoKey fournit la seconde clé de DKE :
| Élément | Où il se trouve |
|---|
| Clé de Microsoft | Azure Rights Management |
| Votre clé DKE | Coffre DuoKey : la clé est répartie sur plusieurs nœuds MPC et n'est jamais entière sur une seule machine |
| Point de terminaison DKE | Déployé depuis un assistant dans DuoKey Cockpit, sans serveur IIS à construire |
| Qui peut déverrouiller | Une politique Zero Trust dans Cockpit : utilisateur, groupe, localisation, adresse IP, horaire |
| Audit | Événements GetKey et Decrypt journalisés par service |
| Où il s'exécute | DuoKey opéré en Suisse, ou Cockpit sur site ou sur OpenShift |
L'étiquette stocke l'URL de votre clé. Une rotation de clé dans Cockpit conserve cette URL : les étiquettes publiées n'ont pas à être refaites. Les étapes sont détaillées dans le guide de configuration DKE ; les critères de choix d'un fournisseur dans comment évaluer un fournisseur DKE. Fiche produit : DuoKey pour Microsoft 365.
Questions fréquentes
Qu'est-ce que le chiffrement à double clé de Microsoft 365 ?
C'est la fonction Double Key Encryption de Microsoft Purview : les contenus étiquetés sont protégés par deux clés, l'une chez Microsoft, l'autre chez vous. Les deux sont nécessaires pour les ouvrir, donc Microsoft ne peut pas les lire seul.
Quelle différence entre DKE et Customer Key ?
Customer Key chiffre les charges de travail Microsoft 365 au repos sous des clés racines que vous contrôlez, mais les services Microsoft 365 déchiffrent toujours les données pour fonctionner. DKE protège des éléments choisis avec une clé qui reste hors de Microsoft.
DKE fonctionne-t-il dans Outlook, SharePoint et OneDrive ?
Outlook, Word, Excel et PowerPoint de bureau sous Windows appliquent et ouvrent les étiquettes DKE. Les fichiers protégés peuvent être stockés dans SharePoint et OneDrive, mais Office sur le web, la coédition, la recherche et Copilot ne fonctionnent pas sur ces éléments.
Peut-on partager un document DKE avec une autre organisation ?
Oui, si les utilisateurs externes ont l'autorisation d'utiliser votre clé dans votre service DKE et la clé correspondante dans Azure. (FAQ Microsoft sur DKE)
Quelles licences incluent DKE ?
Microsoft cite notamment Microsoft 365 E5, A5 et G5, EMS E5, Microsoft Purview Suite et les modules E5 Information Protection and Governance. Vérifiez votre plan dans la description du service Microsoft Purview.
Faut-il un HSM pour DKE ?
Non. Microsoft fournit une implémentation de référence avec des clés logicielles, et plusieurs fournisseurs proposent des HSM. DuoKey répartit la clé sur des nœuds MPC, sans qu'elle soit jamais reconstituée sur une seule machine.