Gérée par le client : opérations de cycle de vie de la clé client

Remarque

Recherchez-vous Microsoft Purview Information Protection, anciennement Microsoft Information Protection (MIP) ?

Le complément Azure Protection des données est supprimé et remplacé par des étiquettes intégrées à vos applications et services Microsoft 365. En savoir plus sur l’état de la prise en charge d’autres composants Azure Information Protection des données.

Le client Protection des données Microsoft Purview (sans complément) est généralement disponible.

Si vous gérez votre clé client pour Azure Information Protection (scénario Bring Your Own Key, ou BYOK), utilisez les sections suivantes pour plus d’informations sur les opérations de cycle de vie pertinentes pour cette topologie.

Révoquer votre clé client

Il existe très peu de scénarios lorsque vous devrez peut-être révoquer votre clé au lieu de retaper. Lorsque vous révoquez votre clé, tout le contenu protégé par votre client à l’aide de cette clé devient inaccessible à tout le monde (y compris Microsoft, vos administrateurs généraux et les super utilisateurs), sauf si vous avez une sauvegarde de la clé que vous pouvez restaurer. Après avoir révoqué votre clé, vous ne pourrez pas protéger le nouveau contenu tant que vous n’avez pas créé et configuré une clé client pour Azure Information Protection.

Pour révoquer votre clé client gérée par le client, dans Azure Key Vault, modifiez les autorisations sur le coffre de clés qui contient votre clé client Azure Information Protection afin que le service Azure Rights Management ne puisse plus accéder à la clé. Cette action révoque efficacement la clé client pour Azure Information Protection.

Lorsque vous annulez votre abonnement pour Azure Information Protection, Azure Information Protection cesse d’utiliser votre clé client et aucune action n’est nécessaire pour vous.

Retaper votre clé client

La retapage est également connue sous le nom de déploiement de votre clé. Lorsque vous effectuez cette opération, Azure Information Protection cesse d’utiliser la clé client existante pour protéger les documents et les emails, et commence à utiliser une autre clé. Les stratégies et les modèles sont immédiatement résignés, mais cette modification est progressive pour les clients et services existants à l’aide d’Azure Information Protection. Par conséquent, pendant un certain temps, certains nouveaux contenus continuent d’être protégés avec l’ancienne clé client.

Pour retaper, vous devez configurer l’objet de clé client et spécifier l’autre clé à utiliser. Ensuite, la clé précédemment utilisée est automatiquement marquée comme archivée pour Azure Information Protection. Cette configuration garantit que le contenu protégé à l’aide de cette clé reste accessible.

Exemples de cas où vous devrez peut-être retaper pour Azure Information Protection :

• Votre entreprise s’est divisée en deux entreprises ou plus. Lorsque vous retapez votre clé client, la nouvelle entreprise n’aura pas accès au nouveau contenu que vos employés publient. Ils peuvent accéder à l’ancien contenu s’ils ont une copie de l’ancienne clé client.

• Vous souhaitez passer d’une topologie de gestion de clés à une autre.

• Vous pensez que la copie principale de votre clé client (la copie en votre possession) est compromise.

Pour retaper une autre clé que vous gérez, vous pouvez créer une clé dans Azure Key Vault ou utiliser une autre clé déjà dans Azure Key Vault. Suivez ensuite les mêmes procédures que celles que vous avez effectuées pour implémenter BYOK pour Azure Information Protection.

1. Uniquement si la nouvelle clé se trouve dans un coffre de clés différent de celui que vous utilisez déjà pour Azure Information Protection : autoriser Azure Information Protection à utiliser le coffre de clés à l’aide de l’applet de commande Set-AzKeyVaultAccessPolicy.

2. Si Azure Information Protection ne connaît pas déjà la clé que vous souhaitez utiliser, exécutez l’applet de commande Use-AipServiceKeyVaultKey.

3. Configurez l’objet de clé client à l’aide de l’applet de commande Set-AipServiceKeyProperties .

Pour plus d'informations sur chacune de ces étapes :

• Pour revenir à une autre clé que vous gérez, consultez Planification et implémentation de votre clé client Azure Information Protection.

  Si vous retapez une clé protégée par HSM que vous créez localement et transférez vers Key Vault, vous pouvez utiliser le même monde sécurisé et accéder aux carte que vous avez utilisés pour votre clé actuelle.

• Pour retaper une clé, en passant à une clé que Microsoft gère pour toi, voir la section Retaper une clé client pour les opérations gérées par Microsoft.

Sauvegarder et récupérer votre clé client

Étant donné que vous gérez votre clé client, vous êtes responsable de la sauvegarde de la clé utilisée par Azure Information Protection.

Si vous avez généré votre clé client localement, dans un HSM de chiffrement nCipher : pour sauvegarder la clé, sauvegarder le fichier de clé tokenisé, le fichier world et l’administrateur carte s. Lorsque vous transférez votre clé vers Azure Key Vault, le service enregistre le fichier de clé tokenisé pour vous protéger contre l’échec de tous les nœuds de service. Ce fichier est lié au monde sécurisé pour la région ou l’instance Azure spécifique. Toutefois, ne considérez pas ce fichier de clé tokenisé comme une sauvegarde complète. Par exemple, si vous avez besoin d’une copie en texte brut de votre clé pour utiliser en dehors d’un HSM de chiffrement nCipher, Azure Key Vault ne peut pas la récupérer pour vous, car elle ne contient qu’une copie non récupérable.

Azure Key Vault dispose d’une applet de commande de sauvegarde que vous pouvez utiliser pour sauvegarder une clé en la téléchargeant et en la stockant dans un fichier. Étant donné que le contenu téléchargeable est chiffré, il ne peut pas être utilisé en dehors d’Azure Key Vault.

Exporter votre clé client

Si vous utilisez BYOK, vous ne pouvez pas exporter votre clé client à partir d’Azure Key Vault ou d’Azure Information Protection. La copie dans Azure Key Vault n’est pas récupérable.

Répondre à une violation

Aucun système de sécurité, quel que soit le niveau de force, est terminé sans processus de réponse aux violations. Votre clé client peut être compromise ou volée. Même s’il est protégé correctement, des vulnérabilités peuvent être trouvées dans la technologie de clé de génération actuelle ou dans les longueurs et algorithmes de clé actuels.

Microsoft dispose d’une équipe dédiée pour répondre aux incidents de sécurité dans ses produits et services. Dès qu’il existe un rapport crédible d’un incident, cette équipe s’engage à examiner l’étendue, la cause racine et les atténuations. Si cet incident affecte vos ressources, Microsoft avertit vos administrateurs généraux clients par email.

Si vous avez une violation, la meilleure action que vous ou Microsoft pouvez entreprendre dépend de l’étendue de la violation ; Microsoft vous accompagne tout au long de ce processus. Le tableau suivant présente certaines situations courantes et la réponse probable, bien que la réponse exacte dépend de toutes les informations qui sont révélées pendant l’enquête.

Description de l'incident	Réponse probable
Votre clé client est divulguée.	Retaper votre clé client. Consultez retaper votre clé client.
Une personne ou un programme malveillant non autorisé a obtenu des droits pour utiliser votre clé client, mais la clé elle-même n’a pas fui.	Le retapage de votre clé client n’aide pas ici et nécessite une analyse de la cause racine. Si un processus ou un bogue logiciel était responsable de l’accès non autorisé, cette situation doit être résolue.
Vulnérabilité découverte dans la technologie HSM de génération actuelle.	Microsoft doit mettre à jour les modules HSM. S’il existe une raison de croire que la vulnérabilité exposée aux clés, Microsoft demande à tous les clients de retaper leurs clés de client.
Les vulnérabilités découvertes dans l’algorithme RSA, ou la longueur de clé, ou les attaques par force brute deviennent réalisables en calcul.	Microsoft doit mettre à jour Azure Key Vault ou Azure Information Protection pour prendre en charge de nouveaux algorithmes et des longueurs de clés plus longues qui sont résilientes, et demander à tous les clients de retaper leur clé client.