Qu’est-ce que le chiffrement à double clé (DKE) ?

Description du service Microsoft Purview Audit

S’applique à : Microsoft Purview Double Key Encryption, Microsoft Purview, Protection des données Microsoft Purview

Description du service pour : Microsoft Purview

Le chiffrement à double clé (DKE) vous permet de protéger vos données hautement sensibles pour répondre à des exigences spécialisées. DKE vous permet de garder le contrôle de vos clés de chiffrement. Il utilise deux clés pour protéger les données ; une clé sous votre contrôle et une seconde clé que vous stockez en toute sécurité dans Microsoft Azure. Vous gardez le contrôle sur l’une de vos clés à l’aide du service Double Key Encryption. L’affichage des données protégées par Double Key Encryption nécessite l’accès aux deux clés.

DKE vous aide à répondre aux exigences réglementaires dans plusieurs réglementations et normes telles que le Règlement général sur la protection des données (RGPD), la loi sur la portabilité et la responsabilité en matière d’assurance maladie (HIPAA), la loi Gramm-Leach-Bliley (GLBA), la loi russe sur la localisation des données (loi fédérale n° 242-FZ), la loi fédérale australienne sur la protection de la vie privée de 1988 et la loi sur la confidentialité de la Nouvelle-Zélande de 1993.

Après avoir configuré le service DKE et vos clés, vous appliquez une protection à votre contenu hautement sensible à l’aide d’étiquettes de confidentialité.

Scénarios de déploiement pris en charge

DKE prend en charge plusieurs configurations différentes, y compris les déploiements dans le cloud et sur site. Ces déploiements permettent de garantir que les données chiffrées restent opaques où que vous les stockiez.

Vous pouvez héberger le service Double Key Encryption utilisé pour demander votre clé à l’emplacement de votre choix (serveur de gestion de clés local ou dans le cloud). Vous gérez le service comme vous le feriez pour toute autre application. Double Key Encryption vous permet de contrôler l’accès au service Double Key Encryption. Vous pouvez stocker vos données très sensibles localement ou les déplacer vers le cloud. Le double chiffrement vous permet de stocker vos données et votre clé dans le même emplacement géographique.

Pour plus d’informations sur les clés racine de client cloud par défaut, consultez Gestion de la clé racine pour votre service Azure Rights Management.

À quel moment votre organisation doit-elle adopter DKE ?

DKE ne s’adresse pas à toutes les organisations, ni à toutes vos données. Imaginons qu’un paysage de données organisationnel classique présente la structure suivante :

• Données non sensibles (environ 80 % des données) : la plupart des données d’une organization entrent dans cette catégorie. Le déplacement de ces données vers le cloud ne pose aucun problème ou préoccupation aujourd’hui. Le déplacement de ces données vers le cloud peut s’avérer bénéfique et permettre à l’organisation d’utiliser la sécurité intégrée au cloud.

• Sensibles (environ 15 % des données) : les données sensibles doivent être protégées. L’organisation attend du fournisseur de services cloud qu’il assure la sécurité tout en améliorant la productivité de cette catégorie de données afin qu’il puisse respecter les réglementations de conformité. Vous souhaitez vous assurer que ces données sont correctement étiquetées à l’aide de la Protection des données Microsoft Purview et qu’elles sont protégées par des stratégies de contrôle d’accès, de rétention et d’audit.

• Très sensible (environ 5 % des données) : cet ensemble est les joyaux de la couronne de l’organisation et doit être fortement protégé. L’organisation ne souhaite pas que quiconque ait accès à ces données. Cette catégorie de données peut également avoir des exigences réglementaires pour que les clés se trouvent dans la même région géographique que les données. Les clés peuvent également être sous la garde stricte de l’organisation. Ce contenu a la classification la plus élevée dans votre organisation (« Top Secret ») et l’accès est limité à quelques personnes uniquement. Les utilisateurs malveillants recherchent des données très sensibles. La perte de ces données peut nuire à la réputation de l’organisation et briser la confiance de ses clients.

Comme mentionné, Double Key Encryption est destiné à vos données les plus sensibles qui sont soumises aux exigences de protection les plus strictes. Vous devez faire preuve de diligence raisonnable pour identifier les bonnes données à couvrir avec cette solution avant de la déployer. Dans certains cas, vous devrez peut-être restreindre votre champ d’application et utiliser d’autres solutions. Par exemple, pour la plupart de vos données, envisagez la Protection des données Microsoft Purview avec des clés gérées par Microsoft ou apportez votre propre clé (BYOK). Ces solutions sont suffisantes pour les documents qui ne sont pas soumis à des protections renforcées et aux exigences réglementaires. De plus, ces solutions vous permettent d’utiliser les services Microsoft 365 les plus puissants ; services que vous ne pouvez pas utiliser avec le contenu chiffré DKE. Par exemple :

• Règles de flux de courrier, y compris les logiciels anti-programme malveillant et le courrier indésirable, qui nécessitent une visibilité sur la pièce jointe
• Microsoft Delve
• eDiscovery
• Recherche et indexation de contenu
• Office Web Apps, y compris la fonctionnalité de co-création
• Copilot

Les données chiffrées DKE ne sont pas accessibles au repos pour les services Microsoft 365, y compris Copilot. Lorsque vous utilisez vos données chiffrées DKE dans Office, les données ne sont toujours pas accessibles à Copilot et vous ne pouvez pas utiliser Copilot dans les applications pendant que vous utilisez des données chiffrées DKE.

Les applications ou services externes qui ne sont pas intégrés à DKE via le Kit de développement logiciel (SDK) Microsoft Information Protection ne peuvent pas effectuer d’actions sur les données chiffrées. Le SDK Microsoft Information Protection 1.7+ prend en charge le chiffrement à double clé. Les applications qui s’intègrent à notre SDK peuvent raisonner sur ces données avec suffisamment d’autorisations et d’intégrations en place.

Lorsque vos données chiffrées DKE sont utilisées dans une application Office, elles peuvent être accessibles à d’autres services Microsoft 365, selon votre version d’Office :

• Dans les dernières versions d’Office, les données chiffrées DKE en cours d’utilisation ne sont pas non plus accessibles aux services Microsoft 365. Cette modification ayant été déployée en même temps que le contrôle de confidentialité distinct pour les étiquettes de confidentialité, qui empêche l’envoi de contenu étiqueté aux expériences connectées à des fins d’analyse, vous pouvez identifier les versions minimales d’Office à l’aide du tableau des fonctionnalités et de la ligne Empêcher les expériences connectées qui analysent du contenu.

• Dans les versions précédentes d’Office, les données chiffrées DKE en cours d’utilisation sont accessibles aux services Microsoft 365, sauf si vous utilisez un paramètre de stratégie pour désactiver les expériences connectées qui analysent le contenu. Pour pls d’informations, consultez Utiliser les paramètres de stratégie pour gérer les contrôles de confidentialité des Applications Microsoft 365 Apps for enterprise.

Utilisez les fonctionnalités de Protection des données Microsoft Purview (classification et étiquetage) pour protéger la plupart de vos données sensibles et utilisez uniquement DKE pour vos données critiques. Le chiffrement à double clé est pertinent pour les données sensibles dans des secteurs hautement réglementés tels que les services financiers et la santé.

Fonctionnalités des étiquettes de confidentialité qui ne prennent pas en charge DKE

Étant donné que DKE n’utilise pas de clé cloud gérée par le service Azure Rights Management, plusieurs fonctionnalités d’étiquette de confidentialité ne peuvent pas fonctionner avec le contenu chiffré DKE :

• Co-auteur et AutoSave

  • La co-écriture et l’enregistrement automatique ne sont pas pris en charge pour les documents Office chiffrés avec DKE. Les étiquettes avec DKE continuent de s’afficher dans les applications Office, mais la co-création et l’enregistrement automatique sont désactivés lorsque l’étiquette est appliquée. Pour plus d’informations, voir Co-écriture pour les fichiers chiffrés avec des étiquettes de confidentialité.

• Files dans SharePoint et OneDrive

  • SharePoint et OneDrive ne peuvent pas traiter les fichiers chiffrés DKE. Ces fichiers ne peuvent pas être ouverts dans Office sur le Web et les fonctionnalités de collaboration telles que la co-création, l’eDiscovery, la protection contre la perte de données et la recherche ne fonctionnent pas pour les fichiers chiffrés DKE dans ces emplacements. Pour plus d’informations, voir Activer les étiquettes de confidentialité pour les fichiers dans SharePoint et OneDrive.

• Étiquette par défaut pour une bibliothèque de documents SharePoint

  • Une étiquette de confidentialité qui utilise DKE ne peut pas être définie comme étiquette de confidentialité par défaut pour une bibliothèque de documents SharePoint. Pour plus d’informations, consultez Configurer une étiquette de confidentialité par défaut pour une bibliothèque de documents SharePoint.

• Composants et pages de Loop

  • Les étiquettes de confidentialité configurées avec DKE ne sont pas prises en charge pour les composants et les pages de Loop. Pour plus d’informations, consultez Étiquettes de confidentialité pour les composants et les pages Loop.

• Conversations et réunions Teams

  • Les étiquettes DKE ne peuvent pas être utilisées pour protéger les éléments de calendrier, les réunions Teams et les conversations. Les réunions et les conversations nécessitent un chiffrement qui utilise le service Azure Rights Management. Pour plus d’informations, voir Utiliser des étiquettes de confidentialité pour protéger les éléments de calendrier, les réunions Teams et les conversations.

Si vos organisations ont l’une des exigences suivantes, vous pouvez utiliser DKE pour sécuriser votre contenu :

• Vous devez détenir des clés dans une limite géographique.
• Toutes les clés que vous détenez pour le chiffrement et le déchiffrement des données sont conservées dans votre centre de données.

Workflow de chiffrement DKE

Cette section divise le flux de travail en étapes distinctes pour illustrer comment deux clés sont utilisées pour protéger un document Office.

Étape 1 : Amorçage

Le client Microsoft Office effectue des tâches de configuration de démarrage et envoie des demandes et des informations au service de chiffrement Azure Rights Management. Ce processus est également appelé bootstrapping. Les tâches comprennent l’autorisation de l’utilisateur à l’aide de Microsoft Entra ID, le téléchargement de certificats et de modèles, etc. Les tâches de démarrage sont des tâches de première connexion et de démarrage qui donnent à l’utilisateur l’accès aux stratégies de chiffrement Azure Rights Management.

Étape 2 : Collecter et mettre en cache la clé publique pour le service Azure Rights Management

L’application Office récupère la clé publique du Azure Key Vault dans le service de chiffrement en fonction de l’utilisateur autorisé à l’aide de Microsoft Entra ID. Une fois collectée, le client met en cache la clé pendant 30 jours par défaut. Une fois mis en cache, le client n’a pas besoin d’amorcer à nouveau sur le service Azure Rights Management jusqu’à l’expiration de la clé. En tant qu’administrateur, vous pouvez configurer une période de mise en cache différente pour le service Azure Rights Management. Vous devez définir une période de cache pour cette clé ou accepter la valeur par défaut de 30 jours. Sans période de cache, la publication hors connexion ne fonctionne pas.

Étape 3 : Demander la clé publique DKE

Le client Office demande votre autre clé publique au service de chiffrement à double clé en fonction de l’utilisateur autorisé à l’aide de Microsoft Entra ID.

Étape 4 : collecter et mettre en cache la clé DKE

Le service Double Key Encryption envoie cette clé publique au client Office. Le client met en cache la clé dans l’appareil tant que vous l’avez configuré. Contrairement à la clé d’Azure,

• Vous ne devez pas configurer de période de cache pour la clé hébergée par le service Double Key Encryption.

• Si vous souhaitez configurer une période de cache, vous pouvez la configurer lorsque vous déployez le service Double Key Encryption ou après le déploiement.

Étape 5 : Protéger le document avec la clé DKE

Le client Microsoft Office chiffre la partie des métadonnées qui contrôle l’accès au contenu à l’aide de votre clé publique récupérée auprès du service de chiffrement à double clé.

Étape 6 : Protéger le document avec la clé Azure

Le client Microsoft Office chiffre la partie déjà chiffrée des métadonnées du document avec votre clé publique provenant d’Azure.

Les données sont désormais protégées avec les deux clés.

Exigences en matière de système et de licence pour DKE

Cette section détaille les exigences en matière de configuration et de système serveur et client que vous devez respecter avant de pouvoir déployer DKE dans votre environnement.

exigences en matière de licences pour DKE

Pour connaître les options de licence pour le chiffrement à double clé, voir Protection des données Microsoft Purview Chiffrement à double clé dans la description du service Microsoft Purview.

Le service Azure Rights Management est requis pour DKE

DKE fonctionne avec des étiquettes de confidentialité et nécessite le chiffrement avec la gestion des droits de la Protection des données Microsoft Purview.

Exigences d’étiquetage DKE pour les applications Office

Utilisez les étiquettes de confidentialité intégrées aux applications Office pour prendre en charge DKE dans Word, Excel, PowerPoint et Outlook. Pour connaître les versions prises en charge, consultez les tableaux de fonctionnalités et la ligne Chiffrement à double clé (DKE).

DKE sur les ordinateurs clients

Les utilisateurs appliquent des étiquettes de confidentialité DKE via ces interfaces.

• Étiquetage de sensibilité dans les applications Windows Office

• Étiqueteuse de fichiers Protection des données Microsoft Purview dans l’Explorateur de fichiers Windows

• Protection des données Microsoft Purview PowerShell

• Scanner de Protection des données Microsoft Purview

Installez les composants requis sur chaque ordinateur client sur lequel vous souhaitez protéger et consommer des documents protégés.

Environnements pris en charge pour le stockage et l’affichage du contenu protégé par DKE

Applications prises en charge. Applications Microsoft 365 pour les grandes entreprises clients sur Windows, notamment Word, Excel, PowerPoint et Outlook.

Prise en charge du contenu en ligne. Vous pouvez stocker des documents et des fichiers protégés par le chiffrement à double clé en ligne dans SharePoint et OneDrive. Vous devez étiqueter et protéger les documents et les fichiers avec DKE par les applications prises en charge avant de les télécharger vers ces emplacements. Vous pouvez partager du contenu chiffré par courrier électronique, mais vous ne pouvez pas afficher les documents et fichiers chiffrés en ligne. Au lieu de cela, vous devez afficher le contenu protégé à l’aide des applications de bureau et des clients pris en charge sur votre ordinateur local.

Scénarios d’étiquetage en dehors des applications Office. Appliquer des étiquettes DKE en dehors des applications Office à l’aide de l’étiqueteuse de fichiers de Protection des données Microsoft Purview dans l’Explorateur de fichiers options de clic droit, applets de commande d’étiquetage PowerShell de Protection des données Microsoft Purview, ou le scanner de Protection des données Microsoft Purview.

Affichage du contenu protégé par DKE en dehors des applications Office. Vous pouvez utiliser la visionneuse de la Protection des données Microsoft Purview pour utiliser les e-mails et les documents protégés par DKE, tels que les fichiers PDF.

Scénarios de chiffrement uniquement et Ne pas transférer. Les options Chiffrer uniquement et Ne pas transférer ne sont pas prises en charge avec DKE dans Outlook. Toutes les autres applications Office prennent en charge les étiquettes d’autorisation définies par l’utilisateur avec DKE.

Contenu connexe

• Configurer le cryptage à double clé

• FAQ sur le chiffrement à double clé