Microsoft Purview Information Protection
Microsoft Purview Information Protection
Comprendre les fondements du chiffrement et du déchiffrement DKE
Fondement : MPIP / Azure RMS
Comprendre le flux de travail standard MPIP/Azure RMS est essentiel avant d'aborder les spécificités de DKE, car DKE s'appuie sur ce fondement.
Fonctionnalité principale
MPIP est fondamentalement une technologie de chiffrement côté client qui automatise la gestion des clés pour les utilisateurs finaux, simplifiant la protection par rapport à une PKI traditionnelle. Elle s'appuie fortement sur Microsoft Entra ID pour l'identité des utilisateurs (à l'aide d'adresses e-mail ou de noms d'utilisateur principaux) afin de contrôler l'autorisation.
Au-delà du chiffrement, elle applique des restrictions d'usage (droits) – comme empêcher l'impression, restreindre la modification ou définir des dates d'expiration – définies par l'auteur ou par des politiques centrales (par exemple, les étiquettes de confidentialité).
Concept clé : Ces droits accompagnent le fichier chiffré.
Concepts et composants clés
| Composant | Description |
|---|---|
| Microsoft Entra ID | Fournit des services d'identité et l'isolation des tenants. Les identités d'utilisateurs/de groupes contrôlent l'autorisation. |
| Purview Information Protection Service | Service cloud de gestion des étiquettes de confidentialité et des paramètres de protection |
| Azure Rights Management (Azure RMS) | Service cloud principal qui détient les clés cryptographiques du tenant et traite les requêtes |
| Clients | Applications sur les appareils des utilisateurs ou instances de services cloud autorisées qui interagissent avec le contenu protégé |
| DKE Web Service | Composant contrôlé par le client pour le Double Key Encryption (traité séparément) |
Processus de chiffrement standard (MPIP/Azure RMS)
Ceci décrit comment le contenu est protégé sans DKE, en utilisant uniquement la clé gérée par Microsoft :
Application de l'étiquette
Un utilisateur applique une étiquette de confidentialité configurée pour le chiffrement dans une application compatible RMS (par exemple, Word).
Génération de la clé de contenu
L'application génère en mémoire une clé symétrique AES unique (Content Key) pour ce document spécifique (liée à son documentID).
Chiffrement du fichier
L'application chiffre le flux de contenu du document à l'aide de cette clé de contenu unique.
Création de la licence de publication (PL)
L'application crée une licence de publication (Publishing License, PL). Cette structure XML contient la clé de contenu, les droits/permissions d'usage définis par l'étiquette ou l'auteur, ainsi que d'autres métadonnées.
Chiffrement et intégration de la PL
L'application chiffre les parties sensibles de la PL (surtout la clé de contenu) à l'aide de la clé publique du tenant Azure RMS (récupérée et mise en cache depuis le service Azure RMS). La PL chiffrée est ensuite intégrée dans la structure du fichier du document.
Les étapes 2 à 4 se déroulent localement, dans la mémoire de l'application.
Certaines métadonnées de la PL, comme l'URL du service Azure RMS du tenant, restent non chiffrées afin de permettre aux clients de trouver le bon service.
Processus de déchiffrement standard (MPIP/Azure RMS)
Ceci décrit comment les utilisateurs ou services autorisés accèdent au contenu protégé sans DKE :
Tentative d'ouverture et découverte du service
Un utilisateur ouvre le document protégé dans une application compatible RMS. L'application lit l'URL du service Azure RMS depuis la partie non chiffrée de la PL.
Authentification et GIC
L'utilisateur s'authentifie auprès du service Azure RMS via Microsoft Entra ID. S'il s'agit de la première interaction de l'utilisateur avec RMS, le service provisionne une paire de clés RSA propre à l'utilisateur (Global Identity Certificate (GIC)). La clé privée du GIC est stockée de manière sécurisée dans le profil local de l'utilisateur ; la clé publique est connue de RMS.
Demande de licence
L'application envoie la PL chiffrée (et non le fichier complet) ainsi que la preuve de l'identité de l'utilisateur (y compris sa clé publique GIC) au service Azure RMS identifié à l'étape 1.
Vérification de l'autorisation
Azure RMS valide l'identité de l'utilisateur par rapport aux permissions définies dans la PL, en vérifiant éventuellement les appartenances aux groupes Microsoft Entra ID ou d'autres attributs. Il détermine les droits effectifs de l'utilisateur pour ce document spécifique (les permissions sont cumulatives si elles sont accordées via plusieurs groupes).
Émission de la licence d'utilisation (UL/EUL)
S'il est autorisé, Azure RMS utilise la clé privée de son tenant pour déchiffrer la clé de contenu depuis la PL. Il crée ensuite une licence d'utilisateur final (End User License, EUL), également appelée licence d'utilisation (Use License). L'EUL contient la clé de contenu déchiffrée et les permissions effectives spécifiques de l'utilisateur. Cette EUL est ensuite chiffrée à l'aide de la clé publique GIC de l'utilisateur.
Déchiffrement du contenu et application des droits
L'application reçoit l'EUL chiffrée. Elle utilise la clé privée GIC de l'utilisateur (stockée localement) pour déchiffrer l'EUL, récupérant ainsi la clé de contenu. L'application utilise alors la clé de contenu pour déchiffrer le contenu réel du document et applique simultanément les permissions spécifiées dans l'EUL (par exemple, autoriser la consultation mais désactiver l'impression ou la copie).
Remarque sur l'accès des services
Services cloud autorisés
Ce flux RMS ne se limite pas aux applications des utilisateurs finaux. Des services cloud autorisés peuvent également agir en tant que clients RMS :
Exchange Online
Règles de transport
Services DLP
Prévention des pertes de données
eDiscovery
Microsoft Purview
Microsoft Copilot
Services d'IA
Ils s'authentifient auprès d'Azure RMS, obtiennent une licence d'utilisation s'ils y sont autorisés, et déchiffrent le contenu pour exécuter leurs fonctions sur les données en clair.