Étape 2 : Migration de clé protégée par HSM à clé protégée par HSM

s’applique à: services AD RMS (Active Directory Rights Management Services), Azure Information Protection

Concerne : Client d’étiquetage unifié AIP et client classique

Notes

Pour fournir une expérience client unifiée et homogène, le client classique Azure Information Protection et la gestion des étiquettes dans le portail Azure sont dépréciés depuis le 31 mars 2021. Le client classique continue de fonctionner selon la configuration, mais aucun support n’est fourni, et les versions de maintenance ne sont plus publiées pour le client classique.

Nous vous recommandons de passer à l’étiquetage unifié et d’effectuer la mise à niveau vers le client d’étiquetage unifié. En savoir plus sur notre récent blog de dépréciation.

Ces instructions font partie du chemin de migration d’AD RMS vers Azure Information Protection. Elles s’appliquent uniquement si votre clé AD RMS est protégée par HSM et que vous souhaitez procéder à la migration vers Azure Information Protection avec une clé de locataire protégée par HSM dans Azure Key Vault.

S’il ne s’agit pas du scénario de configuration que vous avez choisi, revenez à l' étape 4. Exportez les données de configuration de AD RMS, puis importez-les dans Azure RMS et choisissez une autre configuration.

Notes

Ces instructions supposent que votre clé AD RMS est protégée par module. Il s’agit du cas le plus classique.

Cette procédure en deux parties permet d’importer votre clé HSM et votre configuration AD RMS dans Azure Information Protection pour que votre clé de locataire Azure Information Protection soit gérée par l’utilisateur (BYOK).

Comme votre clé de locataire Azure Information Protection est stockée et gérée par Azure Key Vault, cette partie de la migration nécessite une administration dans Azure Key Vault, en plus d’Azure Information Protection. Si Azure Key Vault est géré par un autre administrateur que celui de votre organisation, vous devez coordonner et travailler avec cet administrateur pour effectuer ces procédures.

Avant de commencer, vérifiez que votre organisation dispose d’un coffre de clés qui a été créé dans Azure Key Vault et qu’il prend en charge les clés protégées par HSM. Bien que ce ne soit pas obligatoire, nous vous recommandons d’avoir un coffre de clés dédié pour Azure Information Protection. Ce coffre de clés doit être configuré de façon à autoriser le service Azure Rights Management à y accéder : les clés stockées dans ce coffre de clés doivent donc être limitées aux clés Azure Information Protection.

Conseil

Si vous effectuez les étapes de configuration pour Azure Key Vault et que vous n’êtes pas familiarisé avec ce service Azure, il peut être utile de consulter d’abord Prise en main d’Azure Key Vault.

Partie 1 : Transfert de votre clé HSM vers Azure Key Vault

Ces procédures sont effectuées par l’administrateur d’Azure Key Vault.

  1. Pour chaque clé SLC exportée que vous voulez stocker dans Azure Key Vault, suivez les instructions de la documentation d’Azure Key Vault, notamment Implémentation de BYOK pour Azure Key Vault avec l’exception suivante :

    • N’effectuez pas les étapes pour Générer votre clé de locataire car vous avez déjà l’équivalent dans votre déploiement AD RMS. Au lieu de cela, identifiez les clés utilisées par votre serveur AD RMS à partir de l’installation nCipher et préparez ces clés pour le transfert, puis transférez-les vers Azure Key Vault.

      Les fichiers de clé chiffrés pour nCipher sont nommés key_<keyAppName>_<KeyIdentifier > localement sur le serveur. Par exemple : C:\Users\All Users\nCipher\Key Management Data\local\key_mscapi_f829e3d888f6908521fe3d91de51c25d27116a54. Vous aurez besoin de la valeur mscapi comme keyAppName, ainsi que de votre propre valeur pour l’identificateur de clé lorsque vous exécutez la commande KeyTransferRemote pour créer une copie de la clé avec des autorisations réduites.

      Quand la clé se charge dans Azure Key Vault, vous voyez s’afficher les propriétés de la clé, notamment l’ID de clé. Elle doit ressembler à https : //ContosoRMS-kV.vault.Azure.net/Keys/ContosoRMS-Byok/aaaabbbbcccc111122223333. Prenez note de cette URL, car l’administrateur Azure Information Protection en a besoin pour indiquer au service Azure Rights Management d’utiliser cette clé pour sa clé de locataire.

  2. sur la station de travail connectée à internet, dans une session PowerShell, utilisez l’applet de commande Set-AzKeyVaultAccessPolicy pour autoriser le principal du service Azure Rights Management à accéder au coffre de clés qui stocke la clé de locataire Azure Information Protection. Les autorisations nécessaires sont déchiffrer, chiffrer, désencapsuler la clé (unwrapkey), encapsuler la clé (wrapkey), vérifier et signer.

    Par exemple, si le coffre de clés que vous avez créé pour Azure Information Protection est nommé contoso-byok-ky et que votre groupe de ressources est nommé contoso-byok-rg, exécutez la commande suivante :

    Set-AzKeyVaultAccessPolicy -VaultName "contoso-byok-kv" -ResourceGroupName "contoso-byok-rg" -ServicePrincipalName 00000012-0000-0000-c000-000000000000 -PermissionsToKeys decrypt,sign,get
    

Maintenant que vous avez préparé votre clé HSM dans Azure Key Vault pour le service Azure Rights Management d’Azure Information Protection, vous êtes prêt à importer vos données de configuration AD RMS.

Partie 2 : Importer les données de configuration dans Azure Information Protection

Ces procédures sont effectuées par l’administrateur d’Azure Information Protection.

  1. sur la station de travail connectée à internet et dans la session PowerShell, connectez-vous au service Azure Rights Management à l’aide de l’applet de commande Connecter-AipService .

    Téléchargez ensuite chaque fichier trusted publishing domain (.xml) à l’aide de l’applet de commande Import-AipServiceTpd . Par exemple, vous devez disposer d’au moins un fichier supplémentaire à importer si vous avez mis à niveau votre cluster AD RMS pour le Mode de chiffrement 2.

    Pour exécuter cette applet de commande, vous avez besoin du mot de passe que vous avez spécifié précédemment pour chaque fichier de données de configuration et de l’URL de la clé qui a été identifiée à l’étape précédente.

    Par exemple, à l’aide d’un fichier de données de configuration de C:\contoso_tpd1.xml et de l’URL de notre clé issue de l’étape précédente, exécutez d’abord la commande suivante pour stocker le mot de passe :

    $TPD_Password = Read-Host -AsSecureString
    

    Entrez le mot de passe que vous avez spécifié pour exporter le fichier de données de configuration. Ensuite, exécutez la commande suivante et confirmez que vous souhaitez effectuer cette action :

    Import-AipServiceTpd -TpdFile "C:\contoso-tpd1.xml" -ProtectionPassword $TPD_Password –KeyVaultKeyUrl https://contoso-byok-kv.vault.azure.net/keys/contosorms-byok/aaaabbbbcccc111122223333 -Verbose
    

    Dans le cadre de cette importation, la clé SLC est importée et définie automatiquement comme archivée.

  2. Une fois que vous avez chargé chaque fichier, exécutez Set-AipServiceKeyProperties pour spécifier la clé importée qui correspond à la clé de licence en tant que actuellement active dans votre cluster AD RMS. Cette clé devient la clé de locataire active pour votre service Azure Rights Management.

  3. utilisez l’applet de commande disconnect-AipServiceService pour vous déconnecter du service Azure Rights Management :

    Disconnect-AipServiceService
    

Si vous devez ensuite confirmer la clé que votre clé de locataire Azure Information Protection utilise dans Azure Key Vault, utilisez l’applet de commande AipServiceKeys Azure RMS.

Vous êtes maintenant prêt à passer à l' étape 5. activez le service Azure Rights Management.