Fonctionnement du service Azure Rights Management : détails techniques

Utilisez les informations suivantes si vous souhaitez comprendre en détail le fonctionnement du service Azure Rights Management. Vous n’avez pas besoin de connaître ce niveau d’informations pour configurer ou appliquer les paramètres de chiffrement afin de protéger vos données.

Un concept important à comprendre sur le service Azure Rights Management est que ce service ne voit pas ou ne stocke pas vos données dans le cadre du processus de chiffrement. Les informations que vous chiffrez ne sont jamais envoyées ou stockées dans Azure, sauf si vous les stockez explicitement dans Azure ou si vous utilisez un autre service cloud qui les stocke dans Azure. Le service Azure Rights Management rend simplement les données d’un élément illisibles pour toute personne autre que les utilisateurs et services autorisés :

• Les données sont chiffrées au niveau de l’application et incluent une stratégie qui définit l’utilisation autorisée pour cet élément.

• Lorsqu’un élément chiffré est utilisé par un utilisateur légitime ou qu’il est traité par un service autorisé, les données de l’élément sont déchiffrées et les droits définis dans la stratégie sont appliqués.

À un niveau général, vous pouvez voir comment fonctionne ce processus dans l’image suivante. Un document contenant la formule secrète est chiffré, puis ouvert avec succès par un utilisateur ou un service autorisé. Le document est chiffré par une clé de contenu (la clé verte dans cette image). La clé de contenu est unique pour chaque document et est placée dans l’en-tête de fichier où elle est chiffrée par votre Azure Rights Management clé racine de locataire (la clé rouge dans cette image). Votre clé de locataire peut être générée et gérée par Microsoft, ou vous pouvez générer et gérer votre propre clé de locataire.

Tout au long du processus chiffré lorsque le service Azure Rights Management chiffre et déchiffre, autorise et applique des restrictions, la formule secrète n’est jamais envoyée à Azure.

Pour obtenir une description détaillée de ce qui se passe, consultez la section Procédure pas à pas du fonctionnement du service : Première utilisation, chiffrement du contenu, consommation de contenu dans cet article.

Pour plus d’informations sur les algorithmes et les longueurs de clé que le service utilise, consultez la section suivante.

Contrôles de chiffrement : Algorithmes et longueurs de clé

Même si vous n’avez pas besoin de savoir en détail comment cette technologie fonctionne, vous pouvez être interrogé sur les contrôles de chiffrement qu’elle utilise. Par exemple, pour confirmer que le chiffrement est standard.

Note de bas de page 1

256 bits sont utilisés par le client Protection des données Microsoft Purview dans les scénarios suivants :

• Chiffrement générique (.pfile).

• Chiffrement natif pour les documents PDF lorsque le document a été chiffré avec la norme ISO pour le chiffrement PDF, ou lorsque le document chiffré résultant a une extension de nom de fichier .ppdf.

• Chiffrement natif pour les fichiers texte ou image (tels que .ptxt ou .pjpg).

Note de bas de page 2

2 048 bits est la longueur de clé lorsque le service Azure Rights Management est activé. 1 024 bits est pris en charge pour les scénarios facultatifs suivants :

• Pendant une migration à partir d’un emplacement local, si le cluster AD RMS s’exécute en mode de chiffrement 1.

• Pour les clés archivées créées localement avant la migration, afin que le contenu précédemment chiffré par AD RMS puisse continuer à être ouvert par le service Azure Rights Management après la migration.

Comment les clés de chiffrement sont stockées et sécurisées

Pour chaque document ou e-mail protégé par le service Azure Rights Management, le service crée une clé AES unique (la « clé de contenu ») et cette clé est incorporée dans le document et est conservée dans les éditions du document.

La clé de contenu est chiffrée avec la clé RSA du organization (la « clé de locataire Azure Rights Management ») dans le cadre de la stratégie dans le document, et la stratégie est également signée par l’auteur du document. Cette clé de locataire est commune à tous les documents et e-mails protégés par le service Azure Rights Management pour le organization et cette clé ne peut être modifiée par un administrateur pour le service que si le organization utilise une clé de locataire gérée par le client (appelée « bring your own key » ou BYOK).

Cette clé de locataire est protégée dans la services en ligne de Microsoft, dans un environnement hautement contrôlé et sous surveillance étroite. Lorsque vous utilisez une clé de locataire gérée par le client (BYOK), cette sécurité est renforcée par l’utilisation d’un ensemble de modules de sécurité matériels (HSM) haut de gamme dans chaque région Azure, sans que les clés puissent être extraites, exportées ou partagées en aucune circonstance. Pour plus d’informations sur la clé de locataire et BYOK, consultez Gestion de la clé racine de votre service Azure Rights Management.

Les licences et les certificats envoyés à un appareil Windows sont chiffrés avec la clé privée de l’appareil du client. Cette clé privée est créée la première fois qu’un utilisateur sur l’appareil utilise le service Azure Rights Management. Cette clé privée, à son tour, est chiffrée avec DPAPI sur le client, qui protège ces secrets à l’aide d’une clé dérivée du mot de passe de l’utilisateur. Sur les appareils mobiles, les clés ne sont utilisées qu’une seule fois. Par conséquent, comme elles ne sont pas stockées sur les clients, ces clés n’ont pas besoin d’être chiffrées sur l’appareil.

Procédure pas à pas du fonctionnement du service : première utilisation, chiffrement du contenu, consommation de contenu

Pour comprendre plus en détail le fonctionnement du service Azure Rights Management, passons en revue un flux classique après l’activation du service Azure Rights Management et lorsqu’un utilisateur utilise pour la première fois le service Rights Management à partir de son ordinateur Windows (processus parfois appelé initialisation de l’environnement utilisateur ou démarrage), chiffre le contenu (un document ou un e-mail), puis consomme (ouvre et utilise) du contenu qui a été chiffré par quelqu’un d’autre.

Une fois l’environnement utilisateur initialisé, cet utilisateur peut chiffrer des documents ou consommer des documents chiffrés sur cet ordinateur.

Initialisation de l’environnement utilisateur

Avant qu’un utilisateur puisse chiffrer du contenu ou consommer du contenu chiffré sur un ordinateur Windows, l’environnement utilisateur doit être préparé sur l’appareil. Il s’agit d’un processus unique qui se produit automatiquement sans intervention de l’utilisateur lorsqu’un utilisateur tente de chiffrer ou de consommer du contenu chiffré :

Ce qui se passe à l’étape 1 : le client du service Azure Rights Management qui s’exécute d’abord sur l’ordinateur se connecte au service et le service authentifie l’utilisateur à l’aide de son compte Microsoft Entra.

Lorsque le compte de l’utilisateur est fédéré avec Microsoft Entra ID, cette authentification est automatique et l’utilisateur n’est pas invité à fournir des informations d’identification.

Ce qui se passe à l’étape 2 : une fois l’utilisateur authentifié, la connexion est automatiquement redirigée vers le locataire de l’organization, qui émet des certificats qui permettent à l’utilisateur de s’authentifier auprès du service Azure Rights Management afin de consommer du contenu chiffré et de chiffrer le contenu hors connexion.

L’un de ces certificats est le certificat de compte de droits, souvent abrégé en RAC. Ce certificat authentifie l’utilisateur auprès de Microsoft Entra’ID et est valide pendant 31 jours. Le certificat est automatiquement renouvelé par le client, à condition que le compte d’utilisateur se trouve toujours dans Microsoft Entra ID et que le compte soit activé. Ce certificat n’est pas configurable par un administrateur.

Une copie de ce certificat est stockée dans Azure de sorte que si l’utilisateur se déplace vers un autre appareil, les certificats sont créés à l’aide des mêmes clés.

Chiffrement de contenu

Lorsqu’un utilisateur chiffre un document, le client pour le service Azure Rights Management effectue les actions suivantes sur un document non chiffré :

Ce qui se passe à l’étape 1 : le client crée une clé aléatoire (la clé de contenu) et chiffre le document à l’aide de cette clé avec l’algorithme de chiffrement symétrique AES.

Ce qui se passe à l’étape 2 : le client crée ensuite un certificat qui inclut une stratégie pour le document qui inclut les droits d’utilisation des utilisateurs ou des groupes, ainsi que d’autres restrictions, telles qu’une date d’expiration. Ces paramètres peuvent être définis avec des paramètres de chiffrement d’étiquette de confidentialité qu’un administrateur a précédemment configurés ou spécifiés au moment du chiffrement du contenu (parfois appelés « autorisations définies par l’utilisateur » ou « stratégie ad hoc »).

L’attribut principal Microsoft Entra utilisé pour identifier les utilisateurs et les groupes sélectionnés est l’attribut proxyAddresses Microsoft Entra, qui stocke toutes les adresses e-mail d’un utilisateur ou d’un groupe. Toutefois, si un compte d’utilisateur n’a pas de valeurs dans l’attribut AD ProxyAddresses, la valeur UserPrincipalName de l’utilisateur est utilisée à la place.

Le client utilise ensuite la clé de l’organization obtenue lors de l’initialisation de l’environnement utilisateur et utilise cette clé pour chiffrer la stratégie et la clé de contenu symétrique. Le client signe également la stratégie avec le certificat de l’utilisateur obtenu lors de l’initialisation de l’environnement utilisateur.

Ce qui se passe à l’étape 3 : Enfin, le client incorpore la stratégie dans un fichier avec le corps du document chiffré précédemment, qui constituent ensemble un document chiffré.

Ce document peut être stocké n’importe où ou partagé à l’aide de n’importe quelle méthode, et la stratégie reste toujours avec le document chiffré.

Consommation de contenu

Lorsqu’un utilisateur souhaite consommer un document chiffré, le client commence par demander l’accès au service Azure Rights Management :

Ce qui se passe à l’étape 1 : l’utilisateur authentifié envoie la stratégie de document et les certificats de l’utilisateur au service Azure Rights Management. Le service déchiffre et évalue la stratégie et génère une liste de droits (le cas échéant) dont dispose l’utilisateur pour le document. Pour identifier l’utilisateur, l’attribut ProxyAddresses Microsoft Entra est utilisé pour le compte et les groupes de l’utilisateur dont il est membre. Pour des raisons de performances, l’appartenance au groupe est mise en cache. Si le compte d’utilisateur n’a pas de valeurs pour l’attribut Microsoft Entra ProxyAddresses, la valeur dans le Microsoft Entra UserPrincipalName est utilisée à la place.

Ce qui se passe à l’étape 2 : le service extrait ensuite la clé de contenu AES de la stratégie déchiffrée. Cette clé est ensuite chiffrée avec la clé RSA publique de l’utilisateur qui a été obtenue avec la requête.

La clé de contenu rechiffrée est ensuite incorporée dans une licence d’utilisation chiffrée avec la liste des droits utilisateur, qui est ensuite retournée au client.

Ce qui se passe à l’étape 3 : Enfin, le client prend la licence d’utilisation chiffrée et la déchiffre avec sa propre clé privée utilisateur. Cela permet au client de déchiffrer le corps du document tel qu’il est nécessaire et de le restituer à l’écran.

Le client déchiffre également la liste des droits et les transmet à l’application, qui applique ces droits dans l’interface utilisateur de l’application.

Variantes

Les procédures pas à pas précédentes couvrent les scénarios standard, mais il existe quelques variantes :

• chiffrement Email : lorsque Exchange Online et Chiffrement de messages Microsoft Purview est utilisé pour chiffrer les messages électroniques, l’authentification pour la consommation peut également utiliser la fédération avec un fournisseur d’identité sociale ou à l’aide d’un code secret à usage unique. Ensuite, les flux de processus sont très similaires, sauf que la consommation de contenu se produit côté service dans une session de navigateur web sur une copie temporairement mise en cache de l’e-mail sortant.

• Appareils mobiles : lorsque des appareils mobiles chiffrent ou consomment des fichiers avec le service Azure Rights Management, les flux de processus sont plus simples. Les appareils mobiles ne passent pas d’abord par le processus d’initialisation de l’utilisateur, car au lieu de cela, chaque transaction (pour chiffrer ou consommer du contenu) est indépendante. Comme avec les ordinateurs Windows, les appareils mobiles se connectent au service Azure Rights Management et s’authentifient. Pour chiffrer le contenu, les appareils mobiles envoient une stratégie et le service Azure Rights Management leur envoie une licence de publication et une clé symétrique pour chiffrer le document. Pour consommer du contenu chiffré, lorsque des appareils mobiles se connectent au service Azure Rights Management et s’authentifient, ils envoient la stratégie de document au service Azure Rights Management et demandent une licence d’utilisation pour utiliser le document. En réponse, le service Azure Rights Management envoie les clés et restrictions nécessaires aux appareils mobiles. Les deux processus utilisent TLS pour protéger l’échange de clés et d’autres communications.

• Connecteur Rights Management : lorsque le service Azure Rights Management est utilisé avec le connecteur Rights Management, les flux de processus restent les mêmes. La seule différence est que le connecteur agit comme un relais entre les services locaux (tels que Exchange Server et SharePoint Server) et le service Azure Rights Management. Le connecteur lui-même n’effectue pas d’opérations, telles que l’initialisation de l’environnement utilisateur, le chiffrement ou le déchiffrement. Il relaie simplement la communication qui serait généralement transmise à un serveur AD RMS, en gérant la traduction entre les protocoles utilisés de chaque côté. Ce scénario vous permet d’utiliser le service Azure Rights Management avec des services locaux.

• Chiffrement générique (.pfile) : lorsque le service Azure Rights Management chiffre génériquement un fichier, le flux est essentiellement le même pour le chiffrement de contenu, sauf que le client crée une stratégie qui accorde tous les droits. Lorsque le fichier est consommé, il est déchiffré avant d’être transmis à l’application cible. Ce scénario vous permet de chiffrer tous les fichiers, même s’ils ne prennent pas en charge le service Azure Rights Management en mode natif.

• Comptes Microsoft : le service Azure Rights Management peut autoriser la consommation d’adresses e-mail lorsqu’elles sont authentifiées avec un compte Microsoft. Toutefois, toutes les applications ne peuvent pas ouvrir du contenu chiffré lorsqu’un compte Microsoft est utilisé pour l’authentification. Plus d’informations.

Étapes suivantes

Pour une vue d’ensemble moins technique du service Azure Rights Management, consultez En savoir plus sur le service Azure Rights Management.

Si vous êtes prêt pour les étapes recommandées de déploiement qui incluent le chiffrement pour protéger vos données, consultez Déployer une solution de protection des informations avec Microsoft Purview.