Schritt 2: Migration HSM-geschützter Schlüssel zu HSM-geschützten Schlüsseln

Gilt für: Active Directory Rights Management Services, Azure Information Protection

Relevant für: AIP-Client für einheitliche Bezeichnungen und den klassischen Client

Hinweis

Der klassische Azure Information Protection-Client und die Bezeichnungsverwaltung im Azure-Portal werden am 31. März 2021 als veraltet markiert, um eine einheitliche und optimierte Kundenumgebung zu gewährleisten. Der klassische Client funktioniert zwar weiterhin wie konfiguriert, es wird aber kein weiterer Support bereitgestellt, und es werden keine Wartungsversionen für den klassischen Client mehr veröffentlicht.

Wir empfehlen, zu einheitlichen Bezeichnungen zu migrieren und ein Upgrade auf den Client für einheitliche Bezeichnungen durchzuführen. Weitere Informationen finden Sie in unserem jüngsten Blog zu veralteten Versionen.

Diese Anweisungen sind Teil des Migrationspfads von AD RMS zu Azure Information Protection und gelten nur, wenn Ihr AD RMS-Schlüssel HSM-geschützt ist und Sie die Migration zu Azure Information Protection mit einem HSM-geschützten Mandantenschlüssel in Azure Key Vault durchführen möchten.

Wenn dies nicht Ihr ausgewähltes Konfigurationsszenario ist, fahren Sie mit Schritt 4 fort. Exportieren Sie Konfigurationsdaten aus AD RMS importieren Sie sie in Azure RMS und wählen Sie eine andere Konfiguration aus.

Hinweis

Für diese Anweisungen wird angenommen, dass Ihr AD RMS-Schlüssel modulgeschützt ist. Dies ist der am häufigsten vorkommende Fall.

Das Verfahren zum Importieren des HSM-Schlüssels und der AD RMS-Konfiguration in Azure Information Protection, um den von Ihnen verwalteten Azure Information Protection-Mandantenschlüssel (BYOK) zu erhalten, gliedert sich in zwei Phasen.

Da Ihr Azure Information Protection-Mandantenschlüssel von Azure Key Vault gespeichert und verwaltet wird, muss dieser Teil der Migration nicht nur in Azure Key Vault, sondern auch in Azure Information Protection verwaltet werden. Wenn Azure Key Vault für Ihre Organisation nicht von Ihnen, sondern von einem anderen Administrator verwaltet wird, müssen Sie sich mit diesem Administrator abstimmen und mit ihm zusammenarbeiten, um diese Prozeduren abzuschließen.

Stellen Sie zu Beginn sicher, dass Ihre Organisation über einen Schlüsseltresor verfügt, der in Azure Key Vault erstellt wurde, und dass er HSM-geschützte Schlüssel unterstützt. Auch wenn dies nicht erforderlich ist, empfehlen wir, einen dedizierten Schlüsseltresor für Azure Information Protection zu verwenden. Dieser Schlüsseltresor wird so konfiguriert, dass der Azure Rights Management-Dienst darauf zugreifen kann, sodass dieser Schlüsseltresor nur Azure Information Protection-Schlüssel enthält.

Tipp

Wenn Sie die Konfigurationsschritte für Azure Key Vault ausführen möchten und noch nicht mit diesem Azure-Dienst vertraut sind, finden Sie nützliche Informationen im Artikel Erste Schritte mit Azure Key Vault.

Teil 1: Übertragen Ihres HSM-Schlüssels in Azure Key Vault

Diese Verfahren werden vom Administrator für Azure Key Vault durchgeführt.

  1. Führen Sie für jeden exportierten SLC-Schlüssel, den Sie in Azure Key Vault speichern möchten, die Schritte im Abschnitt Implementieren von „Bring Your Own Key“ (BYOK) für Azure Key Vault der Azure Key Vault-Dokumentation durch – mit folgender Ausnahme:

    • Führen Sie nicht die Schritte zum Generieren Ihres Mandantenschlüssels aus, da Sie bereits über das Äquivalent aus Ihrer AD RMS-Bereitstellung verfügen. Identifizieren Sie stattdessen die Schlüssel, die von Ihrem AD RMS-Server von der nCipher-Installation verwendet werden, bereiten Sie diese Schlüssel für die Übertragung vor, und übertragen Sie sie dann Azure Key Vault.

      Verschlüsselte Schlüsseldateien für nCipher werden key_<keyAppName>_<keyIdentifier > lokal auf dem Server benannt. Beispiel: C:\Users\All Users\nCipher\Key Management Data\local\key_mscapi_f829e3d888f6908521fe3d91de51c25d27116a54. Sie benötigen den mscapi-Wert als keyAppName und Ihren eigenen Wert für den Schlüsselbezeichner, wenn Sie den KeyTransferRemote-Befehl ausführen, um eine Kopie des Schlüssels mit reduzierten Berechtigungen zu erstellen.

      Wenn der Schlüssel in Azure Key Vault hochgeladen wird, werden Ihnen die Schlüsseleigenschaften, einschließlich der Schlüssel-ID, angezeigt. Dies sieht in etwa wie https : ://contosorms-kv.vault.azure.net/keys/contosorms-byok/aaaabbbbcccc111122223333. Notieren Sie sich diese URL, da der Azure Information Protection-Administrator sie benötigt, um dem Azure Rights Management-Dienst mitzuteilen, dass dieser Schlüssel als Mandantenschlüssel verwendet werden soll.

  2. Verwenden Sie auf der Arbeitsstation mit Internetverbindung in einer PowerShell-Sitzung das Cmdlet Set-AzKeyVaultAccessPolicy, um den Azure Rights Management-Dienstprinzipal für den Zugriff auf den Schlüsseltresor zu autorisieren, in dem der Azure Information Protection-Mandantenschlüssel gespeichert wird. Die erforderlichen Berechtigungen sind „decrypt“, „encrypt“, „unwrapkey“, „wrapkey“, „verify“ und „sign“.

    Wenn beispielsweise der Schlüsseltresor, den Sie für Azure Information Protection erstellt haben, „contoso-byok-ky“ heißt und die Ressourcengruppe „contoso-byok-rg“, führen Sie den folgenden Befehl aus:

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

Jetzt haben Sie Ihren HSM-Schlüssel in Azure Key Vault für den Azure Rights Management-Dienst von Azure Information Protection vorbereitet und können die AD RMS-Konfigurationsdaten importieren.

Teil 2: Importieren der Konfigurationsdaten in Azure Information Protection

Diese Verfahren werden vom Administrator für Azure Information Protection durchgeführt.

  1. Stellen Sie auf der Arbeitsstation mit Internetverbindung und in der PowerShell-Sitzung mithilfe des Cmdlets Verbinden-AipService eine Verbindung mit dem Azure Rights Management-Dienst her.

    Laden Sie dann jede vertrauenswürdige Veröffentlichungsdomänendatei (.xml) mithilfe des Cmdlets Import-AipServiceTpd hoch. Sie müssen beispielsweise mindestens eine weitere Datei importieren, wenn Sie Ihren AD RMS-Cluster auf den Kryptografiemodus 2 aktualisiert haben.

    Um dieses Cmdlet auszuführen, benötigen Sie die Kennwörter, die Sie zuvor für die jeweiligen Konfigurationsdatendateien angegeben haben, sowie die URL für den Schlüssel, der im vorherigen Schritt identifiziert wurde.

    Führen Sie den folgenden Befehl aus, um das Kennwort zu speichern. Als Beispiel dienen hier die Konfigurationsdatendatei „C:\contoso-tpd1.xml“ und der Wert für die Schlüssel-URL aus dem vorherigen Schritt:

    $TPD_Password = Read-Host -AsSecureString
    

    Geben Sie das Kennwort ein, das Sie für den Export der Konfigurationsdatendatei angegeben haben. Führen Sie dann den folgenden Befehl aus, und bestätigen Sie, dass Sie diese Aktion ausführen möchten:

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

    Im Rahmen dieses Importvorgangs wird der SLC-Schlüssel importiert und automatisch als archiviert festgelegt.

  2. Wenn Sie jede Datei hochgeladen haben, führen Sie Set-AipServiceKeyProperties aus, um anzugeben, welcher importierte Schlüssel dem derzeit aktiven SLC-Schlüssel in Ihrem AD RMS entspricht. Dieser Schlüssel wird zum aktiven Mandantenschlüssel für Ihren Azure Rights Management-Dienst.

  3. Verwenden Sie das Cmdlet Disconnect-AipServiceService, um die Verbindung mit dem Azure Rights Management trennen:

    Disconnect-AipServiceService
    

Wenn Sie später bestätigen müssen, welcher Schlüssel ihr Azure Information Protection-Mandantenschlüssel in Azure Key Vault verwendet, verwenden Sie das Cmdlet Get-AipServiceKeys Azure RMS Cmdlet.

Sie können nun mit Schritt 5 fortgehen. Aktivieren Sie den Azure Rights Management-Dienst.