Microsoft 365 Double Key Encryption : Guide de configuration complet

Table des matières

1. Qu'est-ce que Double Key Encryption et pourquoi c'est important
2. DKE vs Customer Key : comprendre vos options
3. Prérequis et exigences d'infrastructure
4. Démarche de déploiement DKE étape par étape
5. Configuration des étiquettes de sensibilité pour DKE
6. Considérations sur l'expérience utilisateur et la productivité
7. Résolution des problèmes courants de mise en œuvre DKE
8. Maintien de la conformité avec DKE en production
9. Conclusion
10. Références et lectures complémentaires

Les entreprises migrant des charges de travail sensibles vers Microsoft 365 font face à un dilemme persistant : comment maintenir un véritable contrôle sur vos données lorsque les clés de chiffrement résident chez votre fournisseur cloud ? Double Key Encryption Microsoft 365 répond directement à ce défi en divisant le contrôle cryptographique entre Microsoft et votre organisation, en s'assurant qu'aucune partie — y compris Microsoft — ne peut accéder à votre contenu protégé. Pour les industries réglementées sous le RGPD, NIS2, DORA ou les exigences FINMA, cette architecture représente une voie pratique vers la souveraineté des données M365 sans abandonner les avantages de productivité de la collaboration cloud.

Ce guide fournit une démarche technique complète pour déployer DKE dans des environnements de production. Nous couvrons les exigences d'infrastructure, les procédures de déploiement étape par étape, la configuration du chiffrement des étiquettes de sensibilité, et les réalités opérationnelles du maintien de la conformité à grande échelle. Que vous soyez un RSSI évaluant les options de chiffrement ou un architecte de sécurité cloud chargé de la mise en œuvre, cette ressource fournit la profondeur technique nécessaire pour prendre des décisions éclairées et exécuter avec succès.

Qu'est-ce que Double Key Encryption et pourquoi c'est important

Double Key Encryption (DKE) est une capacité de Microsoft Purview Information Protection qui applique deux couches de chiffrement au contenu protégé. La première clé est gérée par Microsoft dans le service Azure Rights Management. La seconde clé est hébergée et contrôlée exclusivement par votre organisation — sur site ou via un fournisseur de gestion des clés tiers de confiance.

L'architecture technique

Architecture DuoKey DKE — le document est d'abord chiffré avec votre clé client conservée dans DuoKey KMS MPC, puis à nouveau avec la clé Azure gérée par Microsoft. Les deux sont nécessaires pour déchiffrer.

Lorsqu'un utilisateur protège un document avec DKE :

1. Le contenu est chiffré en utilisant la clé de votre organisation (récupérée depuis votre point de terminaison de service DKE)
2. Le contenu déjà chiffré est ensuite rechiffré en utilisant la clé Azure RMS de Microsoft
3. Les deux clés sont nécessaires pour déchiffrer et accéder au contenu

Ce modèle de double chiffrement crée une barrière cryptographique qui empêche toute entité unique d'accéder aux données protégées. Microsoft ne peut pas déchiffrer le contenu sans votre clé. Votre organisation ne peut pas déchiffrer le contenu sans la clé de Microsoft. Même si une clé est compromise, le contenu reste protégé.

Pourquoi la souveraineté des données exige cette approche

Le chiffrement Microsoft 365 standard — qu'il utilise des clés gérées par Microsoft ou Customer Key — permet toujours à Microsoft d'accéder techniquement à votre contenu pendant certaines opérations. Pour les organisations soumises à des cadres réglementaires stricts, cela crée une lacune de conformité.

Considérez le paysage réglementaire auquel font face les entreprises européennes :

Réglementation	Exigence de chiffrement	Pertinence DKE
RGPD Article 32	Mesures techniques appropriées incluant le chiffrement	DKE offre une défense contre l'accès du fournisseur cloud
NIS2 Article 21	Contrôles cryptographiques et gestion des clés	Exige le contrôle sur les mécanismes de chiffrement
DORA Article 28	Gestion des risques ICT tiers	Réduit la dépendance envers un seul fournisseur cloud
FINMA Circulaire 2018/3	Confidentialité des données dans l'externalisation	Les banques suisses exigent la preuve d'exclusion du fournisseur

DKE répond à la question fondamentale que les régulateurs posent de plus en plus : « Votre fournisseur cloud peut-il accéder à ces données ? » Avec DKE correctement déployé, la réponse est définitivement non.

L'argumentaire au-delà de la conformité

Au-delà des exigences réglementaires, DKE sert des objectifs stratégiques de sécurité :

• Atténuation des menaces internes : Même des comptes d'administrateur Microsoft compromis ne peuvent pas accéder au contenu protégé par DKE
• Contrôle juridictionnel : Votre clé reste dans la géographie que vous avez choisie, indépendamment de l'endroit où Microsoft traite les données
• Défendabilité d'audit : La séparation cryptographique claire démontre la diligence raisonnable aux auditeurs et aux clients
• Levier contractuel : Prouve aux clients et partenaires que vous maintenez un contrôle exclusif sur leurs données

DKE vs Customer Key : comprendre vos options

Microsoft propose plusieurs options de chiffrement dans Microsoft 365. Comprendre les distinctions est essentiel pour sélectionner la solution appropriée.

Clés gérées par Microsoft (par défaut)

Microsoft contrôle toutes les clés de chiffrement. Le contenu est chiffré au repos, mais Microsoft conserve une capacité d'accès technique. Convient aux données d'entreprise générales sans exigences réglementaires élevées.

Customer Key (Microsoft 365 BYOK)

Votre organisation fournit des clés racines que Microsoft utilise pour générer des clés de chiffrement. Ces clés sont stockées dans Azure Key Vault sous votre locataire. Microsoft conserve l'accès à une « clé de disponibilité » gérée par Microsoft pour les scénarios de récupération de données.

Limitation critique : Microsoft peut toujours techniquement déchiffrer les données en utilisant la clé de disponibilité, qu'il contrôle. Cela ne satisfait pas aux exigences demandant une exclusion complète du fournisseur.

Double Key Encryption

Votre organisation héberge et contrôle l'une des deux clés de déchiffrement requises entièrement en dehors de l'infrastructure Microsoft. Microsoft ne possède aucune capacité technique d'accéder au contenu protégé.

Matrice de comparaison des fonctionnalités

Capacité	Clés gérées Microsoft	Customer Key	DKE
Microsoft peut accéder au contenu	Oui	Oui (via clé de disponibilité)	Non
Contrôle de rotation des clés	Microsoft	Partagé	Contrôle client complet
Types de contenu pris en charge	Tout M365	Exchange, SharePoint, Teams	Fichiers dans les applications Office
Recherche et eDiscovery	Complet	Complet	Limité
Prise en charge de la co-création	Complet	Complet	Non
Prise en charge mobile	Complet	Complet	Limité
Complexité de mise en œuvre	Aucune	Moyenne	Élevée
Répond à l'« exclusion fournisseur » RGPD	Non	Partiel	Oui

Quand choisir DKE

DKE est approprié lorsque :

• Les règlements exigent explicitement de démontrer que les fournisseurs cloud ne peuvent pas accéder aux données
• Le contenu est hautement classé (secrets commerciaux, documents de fusion-acquisition, privilège juridique)
• Les clients ou partenaires exigent contractuellement des garanties d'exclusion du fournisseur
• Votre modèle de menace inclut des acteurs étatiques avec une potentielle contrainte légale sur Microsoft

DKE n'est pas approprié pour :

• Les documents d'entreprise quotidiens nécessitant des fonctionnalités de collaboration
• Le contenu qui doit être recherchable via les outils de conformité Microsoft
• Les organisations sans infrastructure pour héberger des services de clés de manière fiable

La plupart des entreprises déploient DKE aux côtés de Customer Key, en utilisant DKE pour les catégories de contenu les plus sensibles tandis que Customer Key protège des ensembles de données plus larges.

Prérequis et exigences d'infrastructure

Un déploiement DKE réussi nécessite des configurations spécifiques de licence, d'infrastructure et d'identité. Traiter ces exigences avant de commencer la mise en œuvre.

Exigences de licence

DKE nécessite une licence Microsoft 365 E5 ou l'un des modules complémentaires suivants :

• Microsoft 365 E5 Compliance
• Microsoft 365 E5 Information Protection and Governance
• Office 365 E5

Les utilisateurs qui protégeront le contenu avec DKE et les utilisateurs qui consommeront le contenu protégé par DKE nécessitent tous deux des licences appropriées.

Infrastructure Azure

Azure Active Directory (Entra ID) :

• Le locataire doit être configuré pour Azure RMS
• Les utilisateurs doivent être synchronisés en cas d'utilisation d'identité hybride

Enregistrement d'application :

• Le service DKE nécessite un enregistrement d'application Azure AD
• Configurer les permissions d'API appropriées pour Azure Rights Management Services

Infrastructure du service de clés DKE

Votre service de clés DKE peut être déployé dans plusieurs configurations :

Option 1 : Déploiement sur site

• Windows Server 2019 ou version ultérieure
• Runtime .NET Core 3.1 ou version ultérieure
• IIS avec certificat HTTPS
• Accessibilité réseau depuis les services cloud Microsoft

Option 2 : Déploiement hébergé sur Azure

• Azure App Service (recommandé pour la disponibilité)
• Azure Key Vault pour le stockage des clés
• Intégration de réseau virtuel pour la sécurité

Option 3 : Fournisseur de gestion des clés tiers

• Service DKE géré par des fournisseurs comme DuoKey
• Élimine les frais généraux d'infrastructure
• Fournit des garanties de résidence géographique des clés
• Inclut une protection des clés de niveau HSM et une journalisation d'audit

Exigences réseau

Le point de terminaison du service DKE doit être :

• Accessible via HTTPS (TLS 1.2 minimum)
• Accessible depuis les services cloud Microsoft pour la récupération des clés lors de l'accès au contenu
• Protégé par des contrôles de sécurité réseau appropriés

Règles de pare-feu requises :

Direction	Source	Destination	Port	Protocole
Entrant	Services Microsoft RMS	Point de terminaison DKE	443	HTTPS
Entrant	Applications client	Point de terminaison DKE	443	HTTPS

Exigences logicielles client

• Microsoft 365 Apps for Enterprise (version 2009 ou ultérieure)
• Windows 10 version 1809 ou ultérieure, ou Windows 11
• Client d'étiquetage unifié Azure Information Protection (optionnel, pour l'intégration de l'Explorateur de fichiers)

La prise en charge macOS nécessite Microsoft 365 Apps version 16.40 ou ultérieure. Les clients mobiles ont une prise en charge DKE limitée — évaluez la composition des appareils de votre effectif avant de procéder.

Prérequis d'identité et d'accès

• Les utilisateurs doivent s'authentifier via Azure AD pour accéder au contenu protégé par DKE
• Les politiques d'accès conditionnel ne doivent pas bloquer l'accès au point de terminaison du service DKE
• L'authentification multifacteur est recommandée mais doit être configurée pour éviter de perturber les flux de récupération des clés

Démarche de déploiement DKE étape par étape

DuoKey applique des contrôles d'accès Zero Trust (localisation, appareil, rôles, groupes, intégration Azure) avant de servir la clé client lors d'une requête de déchiffrement.

Cette section fournit une démarche technique pour déployer le service de clés DKE et l'intégrer avec Microsoft Purview.

Étape 3 : Enregistrer l'application DKE dans Azure AD

1. Naviguez vers Portail Azure > Azure Active Directory > Enregistrements d'applications

2. Sélectionnez « Nouvel enregistrement »

3. Configurez l'application :

   • Nom : DKE Key Service
   • Types de comptes pris en charge : Comptes dans ce répertoire organisationnel uniquement
   • URI de redirection : Laisser vide (non requis pour ce service)

4. Après la création, notez l'ID d'application (client) et l'ID de répertoire (locataire)

5. Configurez les permissions d'API :

   • Ajouter Azure Rights Management Services > Content.SuperUser
   • Accorder le consentement administrateur pour votre organisation

6. Créer un secret client ou configurer l'authentification par certificat (certificats recommandés pour la production)

Étape 5 : Déployer le service DKE

Pour le déploiement Azure App Service :

1. Créer un nouveau Azure App Service (Windows ou Linux)
2. Configurer HTTPS avec un certificat TLS valide
3. Configurer les paramètres de l'application depuis votre appsettings.json
4. Activer l'authentification via Azure AD

Pour le déploiement IIS sur site :

1. Installer le bundle d'hébergement .NET Core sur Windows Server
2. Créer un site web IIS avec liaison HTTPS
3. Déployer l'application DKE publiée
4. Vérifier que le site est accessible à l'URL prévue

Étape 7 : Enregistrer l'URL de clé DKE auprès de Microsoft Purview

1. Naviguez vers le portail de conformité Microsoft Purview
2. Allez dans Information Protection > Étiquettes
3. Vous référencerez l'URL de clé DKE lors de la création d'étiquettes de sensibilité dans la section suivante

À ce stade, votre infrastructure DKE est opérationnelle et prête pour l'intégration des étiquettes de sensibilité.

Configuration des étiquettes de sensibilité pour DKE

Le chiffrement des étiquettes de sensibilité avec DKE nécessite une configuration spécifique dans Microsoft Purview. Cette section couvre la création des étiquettes et le déploiement des politiques.

Création d'une étiquette de sensibilité activée pour DKE

1. Ouvrez le portail de conformité Microsoft Purview

2. Naviguez vers Information Protection > Étiquettes

3. Sélectionnez Créer une étiquette

4. Configurez les paramètres de base de l'étiquette :

   • Nom : Hautement confidentiel - Protégé DKE
   • Nom d'affichage : Protégé DKE
   • Description pour les utilisateurs : « Appliquer cette étiquette aux documents nécessitant une protection maximale. Le contenu ne peut pas être accédé par Microsoft. »

5. Définissez la portée de l'étiquette :

   • Sélectionnez Fichiers et emails
   • Les éléments peuvent également inclure des réunions si nécessaire

6. Configurez les paramètres de chiffrement :

   • Sélectionnez Appliquer le chiffrement
   • Choisissez Double Key Encryption
   • Entrez votre URL de clé DKE : https://dke.votreentreprise.com/keys/DKEKey1

7. Configurez les permissions d'accès :

   • Attribuez des permissions à des utilisateurs, groupes ou à toute votre organisation
   • Définissez les niveaux de permissions appropriés (Lecteur, Relecteur, Co-auteur, Co-propriétaire)

8. Configurez l'expiration du contenu et l'accès hors ligne :

   • Considérez les besoins métier pour l'accès aux documents hors ligne
   • Notez que DKE nécessite la connectivité au service de clés pour le déchiffrement

9. Configurez le marquage du contenu :

   • Ajoutez des en-têtes, pieds de page ou filigranes pour identifier le contenu protégé
   • Considérez d'inclure des indicateurs « Protégé DKE » pour la sensibilisation des utilisateurs

10. Réviser et créer l'étiquette

Publication de l'étiquette de sensibilité

Les étiquettes doivent être publiées via une politique d'étiquettes pour être disponibles aux utilisateurs :

1. Naviguez vers Information Protection > Politiques d'étiquettes
2. Sélectionnez Publier une étiquette
3. Choisissez vos étiquettes activées DKE
4. Sélectionnez les utilisateurs et groupes cibles (commencez avec un groupe pilote)
5. Configurez les paramètres de politique :
   • Exiger une justification pour la suppression d'étiquette
   • Exiger que les utilisateurs appliquent une étiquette (optionnel)
6. Nommer et créer la politique

Les politiques d'étiquettes peuvent prendre jusqu'à 24 heures pour se propager à tous les utilisateurs. Planifier les tests pilotes en conséquence.

Bonnes pratiques de configuration des étiquettes

Configuration	Recommandation	Justification
Visibilité des étiquettes	Limiter aux utilisateurs ayant un véritable besoin	Réduit la confusion et la charge de support
Sous-étiquettes	Utiliser la hiérarchie parent/enfant	« Hautement confidentiel » > « Protégé DKE »
Justification de suppression	Toujours requise pour DKE	Crée une piste d'audit des dégradations de protection
Contenu par défaut	Ne pas définir DKE comme étiquette par défaut	Impact trop large sur les flux de travail

Considérations sur l'expérience utilisateur et la productivité

DKE impose des restrictions fonctionnelles que les organisations doivent anticiper et communiquer aux utilisateurs.

Fonctionnalités non disponibles avec DKE

• Co-création en temps réel : DKE ne prend pas en charge l'édition simultanée de documents
• Recherche dans le contenu protégé : Le contenu DKE n'est pas indexé par la recherche Microsoft
• Accès mobile complet : Les applications mobiles ont un support DKE limité
• eDiscovery automatisé : Les outils de conformité Microsoft ne peuvent pas analyser le contenu DKE

Stratégies d'adoption

1. Programme pilote : Commencez avec des utilisateurs clés (équipe juridique, direction) avant un déploiement large
2. Formation dédiée : Expliquer clairement quand et pourquoi utiliser les étiquettes DKE
3. Flux de travail documentés : Créer des procédures claires pour les scénarios courants (partage externe, révision juridique)
4. Support utilisateur : Mettre en place un processus de support pour les problèmes d'accès aux documents protégés

Résolution des problèmes courants de mise en œuvre DKE

Erreur : « Le service de clés n'est pas accessible »

Cause : Le point de terminaison DKE n'est pas accessible depuis les services Microsoft RMS.

Résolution :

1. Vérifier les règles de pare-feu entrant sur le port 443
2. Confirmer que le certificat TLS est valide et approuvé
3. Tester la connectivité depuis un environnement externe

Erreur : « Permission refusée pour la clé DKE »

Cause : L'enregistrement d'application Azure AD n'a pas les permissions correctes.

Résolution :

1. Vérifier que Content.SuperUser est accordé pour Azure Rights Management Services
2. Confirmer que le consentement administrateur a été accordé
3. Vérifier que le secret ou certificat client n'a pas expiré

Échec de déchiffrement pour les utilisateurs existants

Cause : Rotation de clé sans rechiffrement adéquat du contenu existant.

Résolution :

1. Maintenir les anciennes versions de clés disponibles pendant la période de transition
2. Implémenter une politique de rotation de clés avec préservation des versions précédentes
3. Documenter les procédures d'accès d'urgence pour le contenu historique

Maintien de la conformité avec DKE en production

Surveillance continue

Configurez des alertes pour :

• Indisponibilité du service de clés DKE (impact immédiat sur l'accès aux documents)
• Erreurs d'authentification fréquentes (indicateur potentiel de compromission)
• Tentatives d'accès depuis des localisations inhabituelles

Revues d'accès périodiques

Effectuez trimestriellement :

• Revue des utilisateurs autorisés à appliquer des étiquettes DKE
• Vérification des permissions d'accès aux documents protégés
• Audit des journaux d'accès aux clés pour détecter des anomalies

Gestion du cycle de vie des clés

Événement	Action requise	Délai
Expiration de certificat	Renouveler avant expiration	30 jours avant
Rotation planifiée des clés	Nouvelle version de clé + rechiffrement	Trimestrielle
Compromission de clé suspectée	Rotation immédiate + investigation	Immédiate
Départ d'employé clé	Revue des accès + rotation si nécessaire	Sous 24 heures

Conclusion

Microsoft 365 Double Key Encryption représente la solution la plus solide disponible pour les organisations qui doivent garantir que Microsoft — ou toute autorité gouvernementale — ne peut pas accéder à leur contenu le plus sensible. Pour les entreprises européennes soumises au RGPD, DORA, NIS2 ou aux exigences FINMA, DKE offre une architecture de conformité qui répond aux questions les plus exigeantes des régulateurs sur la souveraineté des données cloud.

La complexité de déploiement est réelle, et les restrictions fonctionnelles signifient que DKE n'est pas adapté à tout le contenu. La clé du succès est une segmentation disciplinée : identifier les catégories de contenu qui justifient le compromis DKE, déployer avec rigueur pour ces cas d'utilisation spécifiques, et maintenir une infrastructure robuste du service de clés. DuoKey propose un service DKE géré qui simplifie considérablement ce déploiement tout en fournissant des garanties de niveau HSM pour vos clés les plus sensibles.

Références et lectures complémentaires

• Microsoft Purview Double Key Encryption — Documentation officielle
• Référence de l'API du service de clés DKE
• Azure Rights Management Service — Architecture technique
• RGPD Article 32 — Sécurité du traitement
• FINMA Circulaire 2018/3 — Externalisation
• NIS2 Directive (EU) 2022/2555 — Article 21
• ENISA — Bonnes pratiques pour la gestion des clés de chiffrement