Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Verwenden Sie die Informationen in diesem Artikel, wenn Sie sich entschieden haben, Ihren Mandanten so zu konfigurieren, dass er Ihren eigenen Stammschlüssel für den Azure Rights Management-Dienst anstelle eines von Microsoft generierten Standardschlüssels verwendet. Diese Konfiguration wird häufig als Bring Your Own Key (BYOK) bezeichnet.
Weitere Informationen zu den Optionen für Stammschlüssel finden Sie unter Schlüsseltypen für den Dienst.
BYOK und die Nutzungsprotokollierung funktionieren nahtlos mit Anwendungen, die in den von Microsoft Purview Information Protection verwendeten Azure Rights Management-Dienst integriert sind.
Folgende Anwendungen werden unterstützt:
Clouddienste wie Microsoft SharePoint oder Microsoft 365
Lokale Dienste, auf denen Exchange- und SharePoint-Anwendungen ausgeführt werden, die den Azure Rights Management-Dienst mithilfe des Rights Management-Connectors verwenden
Clientanwendungen wie Office 2024 und Office 2021.
Tipp
Wenden Sie bei Bedarf mithilfe eines zusätzlichen lokalen Schlüssels zusätzliche Sicherheit auf bestimmte Dokumente an. Weitere Informationen finden Sie unter Doppelschlüsselverschlüsselung (DKE).
Azure Key Vault Schlüsselspeicher
Kundengenerierte Schlüssel müssen im Azure Key Vault für BYOK gespeichert werden.
Hinweis
Die Verwendung von HSM-geschützten Schlüsseln im Azure Key Vault erfordert eine Azure Key Vault Premium-Dienststufe, für die eine zusätzliche monatliche Abonnementgebühr anfällt.
Freigeben von Schlüsseltresoren und Abonnements
Es wird empfohlen, einen dedizierten Schlüsseltresor für Ihren Azure Rights Management-Mandantenschlüssel zu verwenden. Dedizierte Schlüsseltresore tragen dazu bei, sicherzustellen, dass Aufrufe durch andere Dienste nicht zu Überschreitungen von Dienstlimits führen. Das Überschreiten der Dienstlimits für den Schlüsseltresor, in dem Ihr Mandantenschlüssel gespeichert ist, kann zu einer Drosselung der Antwortzeit für den Azure Rights Management-Dienst führen.
Da die verschiedenen Dienste unterschiedliche Anforderungen an die Schlüsselverwaltung stellen, empfiehlt Microsoft aus den folgenden Gründen auch die Verwendung eines dedizierten Azure-Abonnements für Ihren Schlüsseltresor:
Schutz vor Konfigurationsfehlern
Sicherer, wenn verschiedene Dienste unterschiedliche Administratoren haben
Um ein Azure Abonnement für andere Dienste freizugeben, die Azure Key Vault verwenden, stellen Sie sicher, dass das Abonnement eine gemeinsame Gruppe von Administratoren verwendet. Vergewissern Sie sich, dass alle Administratoren, die das Abonnement verwenden, über ein gründliches Verständnis aller Schlüssel verfügen, die sie verwalten können. Administratoren mit diesem Verständnis sind weniger anfällig dafür, dass Sie Ihre Schlüssel falsch konfigurieren.
Beispiel: Verwenden Sie ein freigegebenes Azure-Abonnement, wenn die Administratoren für Ihren Azure Rights Management-Mandantenschlüssel dieselben Personen sind, die Ihre Schlüssel für Microsoft Purview-Kundenschlüssel und Dynamics 365 Online verwalten. Wenn die wichtigsten Administratoren für diese Dienste unterschiedlich sind, empfehlen wir die Verwendung dedizierter Abonnements.
Vorteile der Verwendung von Azure Key Vault
Azure Key Vault bietet eine zentralisierte und konsistente Schlüsselverwaltungslösung für viele cloudbasierte und lokale Dienste, die Verschlüsselung verwenden.
Zusätzlich zur Schlüsselverwaltung bietet Azure Key Vault Ihren Sicherheitsadministratoren die gleiche Verwaltungsoberfläche zum Speichern, Zugreifen und Verwalten von Zertifikaten und Geheimnissen (z. B. Kennwörtern) für andere Dienste und Anwendungen, die Verschlüsselung verwenden.
Das Speichern Ihres Mandantenschlüssels im Azure Key Vault bietet die folgenden Vorteile:
| Vorteil | Beschreibung |
|---|---|
| Integrierte Schnittstellen | Azure Key Vault unterstützt eine Reihe integrierter Schnittstellen für die Schlüsselverwaltung, einschließlich PowerShell, CLI, REST-APIs und der Azure-Portal. Andere Dienste und Tools wurden in Azure Key Vault integriert, um optimierte Funktionen für bestimmte Aufgaben wie z. B. die Überwachung zu bieten. Analysieren Sie beispielsweise Ihre Schlüsselverwendungsprotokolle mit dem Azure Monitor-Agent, legen Sie Warnungen fest, wenn angegebene Kriterien erfüllt sind, usw. |
| Rollentrennung | Azure Key Vault bietet Rollentrennung als anerkannte bewährte Sicherheitsmethode. Durch die Rollentrennung wird sichergestellt, dass sich die Administratoren des Azure Rights Management-Diensts auf ihre höchsten Prioritäten konzentrieren können. Dazu gehören die Verwaltung der Datenklassifizierung und des Datenschutzes sowie Verschlüsselungsschlüssel und Richtlinien für bestimmte Sicherheits- oder Complianceanforderungen. |
| Position des Hauptschlüssels | Azure Key Vault ist an einer Vielzahl von Standorten verfügbar und unterstützt Organisationen mit Einschränkungen, wo master Schlüssel gespeichert werden können. Weitere Informationen finden Sie auf der Azure-Website auf der Seite "Verfügbare Produkte nach Region". |
| Getrennte Sicherheitsdomänen | Azure Key Vault verwendet separate Sicherheitsdomänen für seine Rechenzentren in Regionen wie Nordamerika, EMEA (Europa, Naher Osten und Afrika) und Asien. Azure Key Vault verwendet auch verschiedene Instanzen von Azure, z. B. Microsoft Azure Deutschland und Azure Government. |
| Einheitliche Oberfläche | Azure Key Vault ermöglicht Sicherheitsadministratoren auch das Speichern, Zugreifen und Verwalten von Zertifikaten und Geheimnissen wie Kennwörtern für andere Dienste, die Verschlüsselung verwenden. Die Verwendung von Azure Key Vault für Ihre Mandantenschlüssel bietet eine nahtlose Benutzererfahrung für Administratoren, die alle diese Elemente verwalten. |
Um die neuesten Updates zu erhalten und zu erfahren, wie andere Dienste Azure Key Vault verwenden, besuchen Sie den Azure Key Vault Teamblog.
Verwendungsprotokollierung für BYOK
Nutzungsprotokolle werden von jeder Anwendung generiert, die Anforderungen an den Azure Rights Management-Dienst sendet.
Obwohl die Nutzungsprotokollierung optional ist, empfehlen wir, die Nutzungsprotokolle nahezu in Echtzeit für den Azure Rights Management-Dienst zu verwenden, um genau zu sehen, wie und wann Ihr Azure Rights Management-Mandantenschlüssel verwendet wird.
Weitere Informationen zur Protokollierung des Schlüsselverbrauchs für BYOK finden Sie unter Verwendungsprotokollierung für den Azure Rights Management-Dienst.
Tipp
Zur zusätzlichen Sicherheit kann diese Verwendungsprotokollierung mit der Azure Key Vault Protokollierung abgeglichen werden. Azure Key Vault Protokolle bieten eine zuverlässige Methode, um unabhängig zu überwachen, ob Ihr Schlüssel nur vom Azure Rights Management-Dienst verwendet wird.
Widerrufen Sie bei Bedarf sofort den Zugriff auf Ihren Schlüssel, indem Sie die Berechtigungen für den Schlüsseltresor entfernen.
Optionen zum Erstellen und Speichern Ihres Schlüssels
Hinweis
Allgemeine Informationen zum Managed HSM-Angebot und zum Einrichten eines Tresors und eines Schlüssels finden Sie in der Azure Key Vault-Dokumentation.
Dieser Abschnitt enthält zusätzliche Anweisungen zum Erteilen der Schlüsselautorisierung für den Azure Rights Management-Dienst.
BYOK unterstützt Schlüssel, die entweder in Azure Key Vault oder lokal erstellt werden.
Wenn Sie Ihren Schlüssel lokal erstellen, müssen Sie ihn anschließend in Ihren Schlüsseltresor übertragen oder importieren und den Azure Rights Management-Dienst für die Verwendung des Schlüssels konfigurieren. Führen Sie zusätzliche Schlüsselverwaltungen in Azure Key Vault durch.
Optionen zum Erstellen und Speichern eines eigenen Schlüssels:
Lokal erstellt. Erstellen Sie Ihren Schlüssel lokal, und übertragen Sie ihn mithilfe einer der folgenden Optionen auf Azure Key Vault:
HSM-geschützter Schlüssel, als HSM-geschützter Schlüssel übertragen. Die typischste Methode.
Diese Methode hat zwar den größten Verwaltungsaufwand, kann jedoch für Ihre organization erforderlich sein, bestimmte Vorschriften zu befolgen. Die von Azure Key Vault verwendeten HSMs verfügen über FIPS 140-Validierung.
Softwaregeschützter Schlüssel, der konvertiert und als HSM-geschützter Schlüssel an Azure Key Vault übertragen wird. Diese Methode wird nur bei der Migration von Active Directory Rights Management Services (AD RMS) unterstützt.
Lokal als softwaregeschützter Schlüssel erstellt und als softwaregeschützter Schlüssel an Azure Key Vault übertragen. Für diese Methode ist ein . PFX-Zertifikatdatei.
Gehen Sie beispielsweise wie folgt vor, um einen lokal erstellten Schlüssel zu verwenden:
Generieren Sie Ihren Mandantenschlüssel lokal gemäß den IT- und Sicherheitsrichtlinien Ihrer organization. Dieser Schlüssel ist die Master-Kopie. Es verbleibt lokal und Sie sind für dessen Sicherung verantwortlich.
Erstellen Sie eine Kopie des master Schlüssels, und übertragen Sie sie sicher von Ihrem HSM auf Azure Key Vault. Während dieses Vorgangs verlässt die Master-Kopie des Schlüssels niemals die Hardwareschutzgrenze.
Nach der Übertragung ist die Kopie des Schlüssels durch Azure Key Vault geschützt.
Erstellt in Azure Key Vault. Erstellen und speichern Sie Ihren Schlüssel in Azure Key Vault als HSM-geschützten Schlüssel oder softwaregeschützten Schlüssel.
Warnung
Schlüssel, die direkt in Azure Key Vault generiert werden, können nicht zur Verwendung außerhalb Azure Key Vault exportiert werden. Die meisten Organisationen, die BYOK verwenden, haben Complianceanforderungen, die erfordern, dass sie ihre eigene Kopie des Schlüssels außerhalb von Azure Key Vault aufbewahren. Erstellen Sie den Schlüssel nicht direkt in Azure Key Vault, sondern erstellen Sie ihn lokal und übertragen Sie ihn auf Azure Key Vault.
Wenn Ihr organization erfordert, dass Schlüssel exportiert werden können und sich in Ihrem Besitz befinden, müssen Sie den Schlüssel lokal erstellen und importieren, um Ihre eigenen Sicherungen lokal zu Azure Key Vault und zu verwalten. Die Planung und Prüfung der Notfallwiederherstellung sollte Maßnahmen zum regelmäßigen Testen der Wiederherstellung dieser Schlüssel umfassen. Schlüssel können von Azure Key Vault gesichert, aber nur in das ursprüngliche Abonnement importiert werden.
Exportieren Ihrer vertrauenswürdigen Veröffentlichungsdomäne
Wenn Sie sich jemals dazu entschließen, den Azure Rights Management-Dienst nicht mehr zu verwenden, benötigen Sie eine vertrauenswürdige Veröffentlichungsdomäne (Trusted Publishing Domain, TPD), um Inhalte zu entschlüsseln, die vom Azure Rights Management-Dienst verschlüsselt wurden.
Das Exportieren Ihrer TPD wird jedoch nicht unterstützt, wenn Sie BYOK für Ihren Azure Rights Management-Mandantenschlüssel verwenden.
Um sich auf dieses Szenario vorzubereiten, stellen Sie sicher, dass Sie im Voraus eine geeignete TPD erstellen. Weitere Informationen finden Sie unter So bereiten Sie einen Azure Information Protection "Cloud Exit"-Plan vor.
Implementieren von BYOK für Ihren Azure Rights Management-Mandantenschlüssel
Führen Sie die folgenden Schritte aus, um BYOK zu implementieren:
- Überprüfen der BYOK-Voraussetzungen
- Auswählen eines Schlüsseltresorspeicherorts
- Erstellen und Konfigurieren Ihres Schlüssels
Voraussetzungen für BYOK
Die BYOK-Voraussetzungen variieren je nach Systemkonfiguration. Vergewissern Sie sich gegebenenfalls, dass Ihr System die folgenden Voraussetzungen erfüllt:
| Anforderung | Beschreibung |
|---|---|
| Azure-Abonnement | Für alle Konfigurationen erforderlich. Weitere Informationen finden Sie unter Überprüfen, ob Sie über ein BYOK-kompatibles Azure-Abonnement verfügen. |
| AIPService PowerShell-Modul für den Azure Rights Management-Dienst | Für alle Konfigurationen erforderlich. Weitere Informationen finden Sie unter Installieren des PowerShell-Moduls AIPService für den Azure Rights Management-Dienst. Hinweis: Das AIPService-Modul wird unter Windows PowerShell 5.1 und unter PowerShell 7.4 und höher mit Modulversion 3.1.0.0 oder höher ausgeführt. |
| Azure Key Vault Voraussetzungen für BYOK | Wenn Sie einen HSM-geschützten Schlüssel verwenden, der lokal erstellt wurde, stellen Sie sicher, dass Sie auch die in der Azure Key Vault Dokumentation aufgeführten Voraussetzungen für BYOK erfüllen. |
| Thales Firmware-Version 11.62 | Sie benötigen eine Thales-Firmwareversion 11.62, wenn Sie von AD RMS zum Azure Rights Management-Dienst migrieren, indem Sie Softwareschlüssel zu Hardwareschlüssel verwenden und Thales-Firmware für Ihr HSM verwenden. |
| Firewallumgehung für vertrauenswürdige Microsoft-Dienste | Wenn der Schlüsseltresor, der Ihren Mandantenschlüssel enthält, Virtual Network Dienstendpunkte für Azure Key Vault verwendet, müssen Sie vertrauenswürdigen Microsoft-Diensten erlauben, diese Firewall zu umgehen. Weitere Informationen finden Sie unter Virtual Network Dienstendpunkte für Azure Key Vault. |
Überprüfen, ob Sie über ein BYOK-kompatibles Azure-Abonnement verfügen
Ihr Azure Rights Management-Mandant muss über ein Azure-Abonnement verfügen. Wenn Sie noch keines haben, können Sie sich für ein kostenloses Konto registrieren. Um jedoch einen HSM-geschützten Schlüssel verwenden zu können, müssen Sie über die Azure Key Vault Premium-Dienststufe verfügen.
Das kostenlose Azure Abonnement, das Zugriff auf Microsoft Entra Konfiguration bietet, reicht für die Verwendung Azure Key Vault nicht aus.
Um zu überprüfen, ob Sie über ein mit BYOK kompatibles Azure-Abonnement verfügen, führen Sie zur Überprüfung mithilfe von Azure PowerShell-Cmdlets die folgenden Schritte durch:
Starten Sie eine Azure PowerShell-Sitzung als Administrator.
Führen Sie
Connect-AzAccounteine Rolle aus, die auf Ressourcen in Azure Key Vault zugreifen kann, und melden Sie sich an.Führen Sie diese Schritte aus
Get-AzSubscription, um zu überprüfen, ob die folgenden Werte angezeigt werden:- Name und ID Ihres Abonnements
- Ihre Mandanten-ID für den Azure Rights Management-Dienst
- Bestätigung, dass der Status aktiviert ist
Wenn keine Werte angezeigt werden und Sie zur Eingabeaufforderung zurückgeführt werden, verfügen Sie nicht über ein Azure-Abonnement, das für BYOK verwendet werden kann.
Stellen Sie sicher, dass Sie den Azure Key Vault Premium-Tarif verwenden können, der für HSM-geschützte Schlüssel erforderlich ist. Wenn Sie über einen Schlüsseltresor verfügen, führen Sie den folgenden Befehl aus, um dessen SKU zu überprüfen:
Get-AzKeyVault -VaultName "YourVaultName" | Select-Object VaultName, SkuDer SKU-Wert muss für HSM-geschützte Schlüssel Premium sein. Wenn Sie einen neuen Schlüsseltresor erstellen, stellen Sie sicher, dass Sie bei der Erstellung den Premium-Tarif auswählen. Preisinformationen finden Sie unter Azure Key Vault Preise.
Auswählen des Speicherorts für den Schlüsseltresor
Wenn Sie einen Schlüsseltresor mit dem Schlüssel erstellen, der als Mandantenschlüssel für den Azure Rights Management-Dienst verwendet werden soll, müssen Sie einen Speicherort angeben. Dieser Standort ist eine Azure Region oder Azure instance.
Treffen Sie Ihre Wahl zuerst aus Gründen der Konformität und dann zur Minimierung der Netzwerklatenz:
Wenn Sie die BYOK-Schlüsselmethode aus Compliancegründen gewählt haben, können diese Complianceanforderungen auch vorschreiben, welche Azure-Region oder -instance zum Speichern Ihres Azure Rights Management-Mandantenschlüssels verwendet werden kann.
Alle kryptografischen Aufrufe von Schutzketten zu Ihrem Azure Rights Management-Schlüssel. Daher sollten Sie die Netzwerklatenz, die für diese Aufrufe erforderlich ist, minimieren, indem Sie Ihren Schlüsseltresor in derselben Azure-Region oder -instance wie Ihr Azure Rights Management-Mandant erstellen.
Um den Standort Ihres Mandanten zu ermitteln, der den Azure Rights Management-Dienst verwendet, verwenden Sie das PowerShell-Cmdlet Get-AipServiceConfiguration und identifizieren Sie die Region anhand der URLs. Zum Beispiel:
LicensingIntranetDistributionPointUrl : https://5c6bb73b-1038-4eec-863d-49bded473437.rms.na.aadrm.com/_wmcs/licensing
Die Region ist von rms.na.aadrm.com aus identifizierbar, und in diesem Beispiel befindet sie sich in Nordamerika.
In der folgenden Tabelle sind empfohlene Azure-Regionen und -Instanzen zur Minimierung der Netzwerklatenz aufgeführt:
| Azure-Region oder -instance | Empfohlener Speicherort für Ihren Schlüsseltresor |
|---|---|
| rms.na.aadrm.com | USA, Norden-Mitte oder USA, Osten |
| rms.eu.aadrm.com | Europa, Norden oder Europa, Westen |
| rms.ap.aadrm.com | Asien, Osten oder Asien, Südosten |
| rms.sa.aadrm.com | USA, Westen oder USA, Osten |
| rms.govus.aadrm.com | USA, Mitte oder USA, Osten 2 |
| rms.aadrm.us | US Gov Virginia oder US Gov Arizona |
| rms.aadrm.cn | China, Osten 2 oder China, Norden 2 |
Erstellen und Konfigurieren Ihres Schlüssels
Wichtig
Informationen speziell für verwaltete HSMs finden Sie unter Aktivieren der Schlüsselautorisierung für verwaltete HSM-Schlüssel über die Azure CLI.
Erstellen Sie ein Azure Key Vault und den Schlüssel, den Sie für den Azure Rights Management-Dienst verwenden möchten. Weitere Informationen finden Sie in der Azure Key Vault-Dokumentation.
Wichtig
Aktivieren Sie nach dem Erstellen der Azure Key Vault sofort sowohl das vorläufige Löschen als auch den Löschschutz. Dadurch wird verhindert, dass Tresor und Schlüssel versehentlich gelöscht werden. Der Verlust der Schlüssel ohne ausreichende Backups führt zum vollständigen Datenverlust verschlüsselter Dateien und E-Mails. Weitere Details finden Sie unter Azure Key Vault: Übersicht über vorläufiges Löschen.
Beachten Sie Folgendes zum Konfigurieren Ihres Azure Key Vault und Schlüssels für BYOK:
- Anforderungen an die Schlüssellänge
- Erstellen eines HSM-geschützten Schlüssels lokal und Übertragen in Ihren Schlüsseltresor
- Konfigurieren des Azure Rights Management-Diensts für Ihre Schlüssel-ID
- Autorisieren des Azure Rights Management-Diensts zur Verwendung Ihres Schlüssels
Anforderungen an die Schlüssellänge
Stellen Sie beim Erstellen Ihres Schlüssels sicher, dass die Schlüssellänge 2048 Bit beträgt. Andere Schlüssellängen werden vom Azure Rights Management-Dienst nicht unterstützt.
Erstellen eines HSM-geschützten Schlüssels lokal und Übertragen in Ihren Schlüsseltresor
Um einen HSM-geschützten Schlüssel lokal zu erstellen und als HSM-geschützten Schlüssel in Ihren Schlüsseltresor zu übertragen, befolgen Sie die Verfahren in der Azure Key Vault-Dokumentation: So generieren und übertragen Sie HSM-geschützte Schlüssel für Azure Key Vault.
Damit der Azure Rights Management-Dienst den übertragenen Schlüssel verwenden kann, müssen die folgenden Key Vault-Vorgänge für den Schlüssel zulässig sein:
- Abrufen
- Entschlüsseln
- Zeichen
Führen Sie den folgenden PowerShell-Befehl aus, um die zulässigen Vorgänge für einen bestimmten Schlüssel zu überprüfen:
(Get-AzKeyVaultKey -VaultName <key vault name> -Name <key name>).Attributes.KeyOps
Konfigurieren des Azure Rights Management-Diensts für Ihre Schlüssel-ID
Im Azure Key Vault gespeicherte Schlüssel verfügen jeweils über eine Schlüssel-ID.
Die Schlüssel-ID ist eine URL, die den Namen des Schlüsseltresors, des Schlüsselcontainers, den Namen des Schlüssels und die Schlüsselversion enthält. Beispiel: https://contosorms-kv.vault.azure.net/keys/contosorms-byok/aaaabbbbcccc111122223333
Konfigurieren Sie den Azure Rights Management-Dienst für die Verwendung Ihres Schlüssels, indem Sie die Schlüsseltresor-URL angeben.
Autorisieren des Azure Rights Management-Diensts zur Verwendung Ihres Schlüssels
Der Azure Rights Management-Dienst muss über die Azure RBAC zur Verwendung Ihres Schlüssels autorisiert sein. Dazu müssen Sie eine benutzerdefinierte Rolle mit den erforderlichen Berechtigungen erstellen und sie dem Rights Management-Dienstprinzipal zuweisen.
Hinweis
Wenn Ihnen diese Rolle zugewiesen wird, kann der Azure Rights Management-Dienst kryptografische Vorgänge mit Ihrem Schlüssel ausführen. Mitglieder, die dieser Rolle zugewiesen sind, können alle Schlüssel im Tresor für diese Vorgänge verwenden. Nur einem Tresor zuweisen, der dem Azure Rights Management-Dienst gewidmet ist. Weisen Sie diese Rolle nicht anderen Tresoren zu, und verwenden Sie den Tresor nicht für andere Dienste.
Aktivieren der Schlüsselautorisierung mithilfe der Azure-CLI
Melden Sie sich bei der Azure CLI an, und rufen Sie die Abonnement-ID Ihres Schlüsseltresors ab:
az login az keyvault show --name <vault-name> --resource-group <resource-group-name> --query "id" -o tsvDie Ausgabe enthält die Abonnement-ID im folgenden Format:
/subscriptions/<subscription-id>/resourceGroups/...Erstellen Sie eine JSON-Datei mit dem Namen
PurviewRMSCustomAKVRole.json"JSON" mit folgendem Inhalt, und ersetzen Sie<subscription-id>diese durch die Abonnement-ID aus dem vorherigen Schritt:{ "Name": "Purview Rights Management key vault Encryption User", "IsCustom": true, "Description": "Grants access to use key vault keys for the Purview Rights Management service.", "Actions": [], "NotActions": [], "DataActions": [ "Microsoft.KeyVault/vaults/keys/read", "Microsoft.KeyVault/vaults/keys/sign/action", "Microsoft.KeyVault/vaults/keys/decrypt/action" ], "NotDataActions": [], "AssignableScopes": [ "/subscriptions/<subscription-id>" ] }Erstellen Sie die benutzerdefinierte Rollendefinition, und ändern Sie bei Bedarf den Pfad der Rollendefinitionsdatei:
az role definition create --role-definition "./PurviewRMSCustomAKVRole.json"Hinweis
Führen Sie diesen Befehl aus dem Verzeichnis aus, in dem Sie gespeichert haben
PurviewRMSCustomAKVRole.json, oder ersetzen./PurviewRMSCustomAKVRole.jsonSie ihn durch den vollständigen Pfad zu der Datei.Rufen Sie die Ressourcen-ID des Schlüsseltresors ab, und weisen Sie dem Rights Management-Dienstprinzipal die Rolle in einem einzigen Befehl zu:
az role assignment create --role "Purview Rights Management key vault Encryption User" --assignee "00000012-0000-0000-c000-000000000000" --scope $(az keyvault show --name <vault-name> --resource-group <resource-group-name> --query "id" -o tsv)
Aktivieren der Schlüsselautorisierung mit Azure PowerShell
Melden Sie sich bei Azure PowerShell an, und rufen Sie die Abonnement-ID Ihres Schlüsseltresors ab:
Connect-AzAccount # Define your key vault and resource group names $vaultName = "<vault-name>" $resourceGroupName = "<resource-group-name>" # Get the key vault resource ID and subscription ID $keyVault = Get-AzKeyVault -VaultName $vaultName -ResourceGroupName $resourceGroupName $resourceId = $keyVault.ResourceId $subscriptionId = ($resourceId -split "/")[2] # Create the custom role definition JSON file $jsonRoleDefinition = @" { "Name": "Purview Rights Management key vault Encryption User", "IsCustom": true, "Description": "Grants access to use key vault keys for the Purview Rights Management service.", "Actions": [], "NotActions": [], "DataActions": [ "Microsoft.KeyVault/vaults/keys/read", "Microsoft.KeyVault/vaults/keys/sign/action", "Microsoft.KeyVault/vaults/keys/decrypt/action" ], "NotDataActions": [], "AssignableScopes": [ "/subscriptions/$($subscriptionId)" ] } "@ $jsonRoleDefinition | Out-File -FilePath "./PurviewRMSCustomAKVRole.json" # Create the custom role definition New-AzRoleDefinition -InputFile "./PurviewRMSCustomAKVRole.json" # Assign the role to the Rights Management service principal New-AzRoleAssignment -RoleDefinitionName "Purview Rights Management key vault Encryption User" -ServicePrincipalName "00000012-0000-0000-c000-000000000000" -Scope $resourceId
Aktivieren der Schlüsselautorisierung für verwaltete HSM-Schlüssel über die Azure-Befehlszeilenschnittstelle
Führen Sie den folgenden Befehl aus, um dem Dienstprinzipal von Azure Rights Management Berechtigungen als Benutzer von Managed HSM Crypto zu erteilen:
az keyvault role assignment create --hsm-name "ContosoMHSM" --role "Managed HSM Crypto User" --assignee-principal-type ServicePrincipal --assignee https://aadrm.com/ --scope /keys/contosomhskey
Dabei gilt:
- "ContosoMHSM" ist ein Beispiel für einen HSM-Namen. Ersetzen Sie beim Ausführen dieses Befehls diesen Wert durch Ihren eigenen HSM-Namen.
Die Benutzerrolle "Krypto-Benutzer für verwaltete HSM" ermöglicht es dem Benutzer, den Schlüssel zu entschlüsseln, zu signieren und Berechtigungen für den Schlüssel zu erhalten, die alle für die verwaltete HSM-Funktionalität erforderlich sind.
Konfigurieren des Azure Rights Management-Diensts zur Verwendung Ihres Schlüssels
Nachdem Sie die vorherigen Schritte ausgeführt haben, können Sie den Azure Rights Management-Dienst so konfigurieren, dass er diesen Schlüssel als Mandantenschlüssel Ihrer organization verwendet.
Kopieren Sie zunächst die URL für Ihren Schlüssel aus Azure Key Vault, einschließlich der Schlüsselversion. Sie können dies mithilfe der Azure-Befehlszeilenschnittstelle oder PowerShell abrufen:
Azure CLI:
az keyvault key show --vault-name <vault-name> --name <key-name> --query "key.kid" -o tsv
Azure PowerShell:
(Get-AzKeyVaultKey -VaultName "<vault-name>" -Name "<key-name>").Id
Konfigurieren eines neuen BYOK-Schlüssels
Wenn dies ein neuer Schlüssel ist, führen Sie die folgenden Schritte aus, um den Azure Rights Management-Dienst zu konfigurieren:
Installieren und importieren Sie das AIPService PowerShell-Modul, sofern noch nicht geschehen:
Hinweis
Das AIPService-Modul wird unter Windows PowerShell 5.1 und unter PowerShell 7.4 und höher mit Modulversion 3.1.0.0 oder höher ausgeführt.
Install-Module -Name AIPService Import-Module -Name AIPServiceStellen Sie eine Verbindung mit dem Azure Rights Management-Dienst her:
Connect-AipServiceFühren Sie das Cmdlet Use-AipServiceKeyVaultKey aus, und geben Sie die Schlüssel-URL an:
Use-AipServiceKeyVaultKey -KeyVaultKeyUrl "https://contosorms-kv.vault.azure.net/keys/contosorms-byok/<key-version>"Wichtig
In diesem Beispiel ist die Version des Schlüssels,
<key-version>den Sie verwenden möchten. Sie müssen die Schlüsselversion angeben. Wenn Ihr Schlüssel später aktualisiert oder erneuert wird, funktioniert der Azure Rights Management-Dienst nicht mehr für Ihren Mandanten, es sei denn, Sie aktualisieren die Konfiguration mit der neuen Schlüsselversion.Listen Sie die für Ihren Mandanten konfigurierten Schlüssel auf, um die Schlüssel-ID des neuen Schlüssels abzurufen, indem Sie
Get-AipServiceKeysverwenden. Suchen Sie den Schlüssel mit der entsprechenden KeyVaultKeyUrl. Kopieren Sie den KeyIdentifier-Wert:Get-AipServiceKeys | Select-Object KeyIdentifier, KeyVaultKeyUrlLegen Sie den neuen Schlüssel als aktiven Mandantenschlüssel fest, indem Sie die neue Schlüssel-ID aus dem vorherigen Befehl verwenden:
Set-AipServiceKeyProperties -KeyIdentifier <key-id-from-previous-step> -Active $true
Der Azure Rights Management-Dienst ist nun so konfiguriert, dass Ihr Schlüssel anstelle des von Microsoft erstellten Standardschlüssels verwendet wird, der automatisch für Ihren Mandanten erstellt wurde.
Migration von Azure Key Vault hsmPlatform 1 zu hsmPlatform 2
Azure Key Vault hsmPlatform 1 wird eingestellt. Weitere Informationen zu dieser Außerbetriebnahme finden Sie in Azure Key Vault Ankündigung der Einstellung von hsmPlatform 1.
Wenn Ihr Azure Rights Management-Mandantenschlüssel in einem hsmPlatform 1-Schlüsseltresor gespeichert ist, müssen Sie zu hsmPlatform 2 migrieren, um BYOK weiterhin verwenden zu können.
Ermitteln, ob sich Ihr Schlüssel auf HSMPlattform 1 befindet
Ermitteln Sie zunächst, ob sich Ihr vorhandener Rights Management-Schlüssel auf hsmPlatform 1 befindet:
Verwenden der Azure-Befehlszeilenschnittstelle:
az keyvault key show --vault-name <vault-name> --name <key-name> --query "attributes.hsmPlatform" -o tsv
Verwenden von Azure PowerShell:
(Get-AzKeyVaultKey -VaultName "<vault-name>" -Name "<key-name>").Attributes.HsmPlatform
- Wenn der
hsmPlatformWert ist1, befindet sich Ihr Schlüssel auf hsmPlatform 1 und muss migriert werden. - Wenn der
hsmPlatformWert oder höher ist2, befindet sich Ihr Schlüssel bereits auf hsmPlatform 2 und es ist keine Aktion erforderlich.
Migrationsschritte für Schlüssel auf HSMPlatform 1
Wenn sich Ihr Schlüssel auf hsmPlatform 1 befindet, führen Sie die folgenden Schritte für die Migration aus:
Schritt 1: Suchen Ihres lokalen HSM
Sie müssen Zugriff auf das lokale HSM haben, das ursprünglich zum Generieren des Schlüsselmaterials verwendet wurde, oder auf eine Sicherung dieses Schlüssels, die innerhalb Ihrer Verwaltungsgrenze in ein kompatibles HSM importiert werden kann.
Wichtig
Wenn Sie keinen Zugriff mehr auf das ursprüngliche HSM oder das Schlüsselmaterial haben, lesen Sie Meine organization hat den Zugriff auf das ursprüngliche Schlüsselmaterial verloren.
Schritt 2: Erneutes Importieren des Schlüssels als neue Version in den vorhandenen Schlüsseltresor
Sie müssen für diese Migration keinen neuen Schlüsseltresor erstellen. Packen Sie dasselbe Schlüsselmaterial und importieren Sie es als neue Schlüsselversion aus Ihrem lokalen HSM in das vorhandene Azure Key Vault. Ausführliche Anweisungen finden Sie unter Generieren und Übertragen von HSM-geschützten Schlüsseln für Azure Key Vault.
Schritt 3: Überprüfen, ob sich die neue Schlüsselversion auf HSMPlattform 2 befindet
Vergewissern Sie sich nach Abschluss des Imports, dass die neue Schlüsselversion gemeldet wird hsmPlatform2 , bevor Sie den Rights Management-Dienst aktualisieren:
Verwenden der Azure-Befehlszeilenschnittstelle:
az keyvault key show --vault-name <vault-name> --name <key-name> --version <new-key-version> --query "attributes.hsmPlatform" -o tsv
Verwenden von Azure PowerShell:
(Get-AzKeyVaultKey -VaultName "<vault-name>" -Name "<key-name>" -Version "<new-key-version>").Attributes.HsmPlatform
Der zurückgegebene Wert muss 2sein. Ist dies nicht der Fall, beenden Sie den Import, und vergewissern Sie sich, dass Sie das richtige Schlüsselmaterial importiert haben und dass der Import erfolgreich abgeschlossen wurde.
Schritt 4: Überprüfen, ob die öffentlichen Schlüssel übereinstimmen
Stellen Sie vor dem Aktualisieren der Rights Management-Dienstkonfiguration sicher, dass die öffentlichen Schlüssel an allen Standorten übereinstimmen:
Rufen Sie den öffentlichen Schlüssel aus der neuen Schlüsselversion in Azure Key Vault ab:
Verwenden der Azure-Befehlszeilenschnittstelle:
az keyvault key show --vault-name <vault-name> --name <key-name> --version <new-key-version> --query "key.n" -o tsvVerwenden von Azure PowerShell:
Get-AzKeyVaultKey -VaultName "<vault-name>" -Name "<key-name>" -Version "<new-key-version>" | Format-List Key
Überprüfen Sie den n-Wert aus der Ausgabe, der den öffentlichen Schlüsselmodul darstellt.
Rufen Sie den öffentlichen Schlüssel vom Rights Management-Dienst ab:
Connect-AipService Get-AipServiceKeys | Select-Object KeyIdentifier, PublicKeyVergleichen Sie Ihre lokale HSM-Kopie mithilfe der Tools Ihres HSM-Anbieters, um den öffentlichen Schlüssel zu exportieren oder anzuzeigen. Wenden Sie sich an Ihren HSM-Anbieter, um Unterstützung zu erhalten, wenn Sie die Details des öffentlichen Schlüssels nicht finden können. Der Microsoft-Support kann Ihnen bei HSM-spezifischen Vorgängen nicht behilflich sein.
Alle drei öffentlichen Schlüssel müssen genau übereinstimmen. Wenn sie nicht übereinstimmen, überprüfen Sie, dass Sie den richtigen Schlüssel aus Ihrem HSM importieren.
Schritt 5: Aktualisieren des Azure Rights Management-Diensts zur Verwendung der neuen Schlüsselversion
Führen Sie Convert-AipServiceKeyToKeyVault aus, um die Schlüssel-URL auf die neue Schlüsselversion zu aktualisieren:
Connect-AipService
Convert-AipServiceKeyToKeyVault -KeyIdentifier <existing-key-id> -KeyVaultKeyUrl "https://<vault-name>.vault.azure.net/keys/<key-name>/<new-key-version>"
Hinweis
Dieser Befehl schlägt fehl, wenn die öffentlichen Schlüssel nicht genau zwischen dem vorhandenen BYOK-Schlüssel und dem Schlüssel im neuen Azure Key Vault übereinstimmen. Stellen Sie sicher, dass Sie die Überprüfung in Schritt 4 abgeschlossen haben, bevor Sie diesen Befehl ausführen.
Meine organization hat den Zugriff auf das ursprüngliche Schlüsselmaterial verloren
Wenn Sie keinen Zugriff mehr auf das ursprüngliche lokale HSM oder das Schlüsselmaterial haben, das zum Erstellen Ihres BYOK-Schlüssels verwendet wurde, müssen Sie einen neuen Schlüssel erstellen:
Erstellen Sie einen neuen Schlüssel , indem Sie die Schritte unter Erstellen und Konfigurieren Ihres Schlüssels ausführen.
Konfigurieren Sie die Zugriffssteuerung wie unter Autorisieren des Azure Rights Management-Diensts zur Verwendung Ihres Schlüssels beschrieben.
Legen Sie den neuen Schlüssel als aktiv fest:
Connect-AipService Use-AipServiceKeyVaultKey -KeyVaultKeyUrl "https://<vault-name>.vault.azure.net/keys/<key-name>/<key-version>" Set-AipServiceKeyProperties -KeyIdentifier <new-key-id> -Active $trueÖffnen Sie eine Supportanfrage beim Microsoft Purview-Support, um die nächsten Schritte für Inhalte zu besprechen, die mit dem vorherigen Schlüssel geschützt waren. Wechseln Sie zum Microsoft 365 Admin Center, und öffnen Sie eine Serviceanfrage, oder wenden Sie sich an Ihren Microsoft-Supportmitarbeiter. Weitere Informationen finden Sie unter Anfordern von Support für Microsoft 365 Business.
Warnung
Wenn Sie den ursprünglichen Schlüssel nicht migrieren können, entfernen Sie den vorhandenen hsmPlatform 1-Schlüssel nicht , nachdem Sie den neuen Schlüssel erstellt haben. Auf Inhalte, die mit dem vorherigen Schlüssel geschützt sind, kann nicht mehr zugegriffen werden, wenn der Schlüssel entfernt wird.
Nächste Schritte
Wenn Sie den Rights Management-Dienst noch nicht aktiviert haben, führen Sie diesen Schritt jetzt aus.
Wenn der Dienst aktiviert wurde, bevor Sie BYOK konfiguriert haben, werden die Benutzer im Laufe weniger Wochen schrittweise vom alten Schlüssel auf den neuen Schlüssel umgestellt. Während dieses Übergangs bleiben Dokumente und Dateien, die mit dem alten Mandantenschlüssel verschlüsselt wurden, für autorisierte Benutzer zugänglich.
Verwenden Sie die Verwendungsprotokollierung von Azure Rights Management, um jede Transaktion anzuzeigen, die der Azure Rights Management-Dienst und Ihr Schlüssel ausführen. Aus einer Protokolldatei, die in Excel angezeigt wird, zeigen die Anforderungstypen KeyVaultDecryptRequest und KeyVaultSignRequest, dass der Mandantenschlüssel verwendet wird.