Teilen über

Zugriffssteuerung für verwaltetes HSM

  • Artikel

Verwaltetes HSM von Azure Key Vault ist ein Clouddienst zum Schutz von Verschlüsselungsschlüsseln. Da es sich hierbei um vertrauliche und geschäftskritische Daten handelt, müssen Sie Ihre verwalteten Hardwaresicherheitsmodule (HSMs) schützen, sodass nur autorisierte Anwendungen und Benutzer*innen auf die Daten zugreifen können.

Dieser Artikel enthält eine Übersicht über das Zugriffssteuerungsmodell für verwaltete HSMs. Er erläutert die Authentifizierung und Autorisierung und beschreibt, wie Sie den Zugriff auf Ihre verwalteten HSMs schützen.

Hinweis

Der Azure Key Vault-Ressourcenanbieter unterstützt zwei Ressourcentypen: Tresore und verwaltete HSMs. Die in diesem Artikel beschriebene Zugriffssteuerung gilt nur für verwaltete HSMs. Weitere Informationen zur Zugriffssteuerung für verwaltetes HSM finden Sie unter Gewähren des Zugriffs auf Key Vault-Schlüssel, -Zertifikate und -Geheimnisse mit der rollenbasierten Zugriffssteuerung in Azure.

Zugriffssteuerungsmodell

Der Zugriff auf ein verwaltetes HSM wird über zwei Schnittstellen gesteuert:

  • Verwaltungsebene
  • Datenebene

Die Verwaltungsebene dient zum Verwalten des HSM selbst. Zu den Vorgängen auf dieser Ebene gehören das Erstellen und Löschen von verwalteten HSMs und das Abrufen von verwalteten HSM-Eigenschaften.

Auf der Datenebene arbeiten Sie mit den Daten, die in einem verwalteten HSM gespeichert sind. Das heißt, Sie arbeiten mit im HSM gesicherten Verschlüsselungsschlüsseln. Sie können Schlüssel hinzufügen, löschen, ändern und mithilfe von Schlüsseln kryptografische Vorgänge durchführen, Rollenzuweisungen zur Zugriffssteuerung für die Schlüssel verwalten, eine vollständige HSM-Sicherung erstellen, eine vollständige Sicherung wiederherstellen und die Sicherheitsdomäne über die Datenebenenschnittstelle verwalten.

Um auf ein verwaltetes HSM in einer der beiden Ebenen zugreifen zu können, müssen alle Aufrufer über eine ordnungsgemäße Authentifizierung und Autorisierung verfügen. Die Authentifizierung stellt die Identität des Aufrufers fest. Die Autorisierung bestimmt, welche Vorgänge der Aufrufer ausführen darf. Ein Aufrufer kann ein beliebiger der Sicherheitsprinzipale sein, die in der Microsoft Entra-ID definiert sind: Benutzer, Gruppe, Dienstprinzipal oder verwaltete Identität.

Beide Ebenen verwenden Microsoft Entra ID für die Authentifizierung. Für die Autorisierung verwenden sie verschiedene Systeme:

  • Die Verwaltungsebene verwendet die rollenbasierte Zugriffssteuerung in Azure (Azure RBAC), ein Autorisierungssystem, das auf Azure Resource Manager basiert.
  • Die Datenebene verwendet ein RBAC auf Ebene des verwalteten HSM (lokale RBAC für verwaltetes HSM), ein Autorisierungssystem, das auf der Ebene verwalteter HSMs implementiert und erzwungen wird.

Wenn ein verwaltetes HSM erstellt wird, stellt der Anforderer eine Liste von Datenebenenadministrator*innen bereit (es werden alle Sicherheitsprinzipale unterstützt). Nur diese Administrator*innen können auf die Datenebene des verwalteten HSMs zuzugreifen, um wichtige Vorgänge durchzuführen und die Rollenzuweisungen der Datenebene zu verwalten (lokale RBAC für verwaltetes HSM).

Das Berechtigungsmodell für beide Ebenen verwendet dieselbe Syntax, aber sie werden auf verschiedenen Ebenen erzwungen, und die Rollenzuweisungen verwenden unterschiedliche Bereiche. Auf Verwaltungsebene wird Azure RBAC von Azure Resource Manager erzwungen, und auf der Datenebene wird vom verwalteten HSM selbst die lokale RBAC des verwalteten HSM durchgesetzt.

Wichtig

Das Gewähren des Zugriffs auf einen Sicherheitsprinzipal auf Verwaltungsebene gewährt dem Sicherheitsprinzipal nicht Zugriff auf Datenebene. Beispielsweise verfügt ein Sicherheitsprinzipal mit Zugriff auf Verwaltungsebene nicht automatisch über Zugriff auf Schlüssel oder Rollenzuweisungen auf Datenebene. Diese Isolation ist so konzipiert, dass eine unbeabsichtigte Erweiterung von Berechtigungen, die den Zugriff auf in verwaltetem HSM gespeicherte Schlüssel beeinträchtigen, verhindert wird.

Es gibt jedoch eine Ausnahme: Mitglieder der Rolle „Globaler Microsoft Entra Administrator“ können immer Benutzer*innen zur Rolle „Administrator für verwaltetes HSM“ für Wiederherstellungszwecke hinzufügen, wenn z. B. keine gültigen Administratorkonten für verwaltetes HSM mehr vorhanden sind. Weitere Informationen finden Sie unter bewährten Methoden für die Sicherung der Rolle "Globaler Adminstrator"von Microsoft Entra ID.

Beispielsweise können Abonnementadministrator*innen (da sie über Berechtigungen vom Typ „Mitwirkender“ für alle Ressourcen im Abonnement verfügen) ein verwaltetes HSM im Abonnement löschen. Wenn jedoch kein Zugriff auf Datenebene speziell über die lokale RBAC für verwaltetes HSM gewährt wird, können sie keinen Zugriff auf Schlüssel erhalten oder Rollenzuweisungen im verwalteten HSM verwalten, um sich selbst oder anderen Zugriff auf die Datenebene zu gewähren.

Microsoft Entra-Authentifizierung

Wenn Sie ein verwaltetes HSM in einem Azure-Abonnement erstellen, wird das verwaltete HSM automatisch dem Microsoft Entra-Mandanten des Abonnements zugeordnet. Alle Aufrufer in beiden Ebenen müssen bei diesem Mandanten registriert sein und sich authentifizieren, um auf das verwaltete HSM zugreifen zu können.

Die Anwendung authentifiziert sich vor dem Aufrufen einer Ebene mit Microsoft Entra-ID. Die Anwendung kann eine beliebige unterstützte Authentifizierungsmethode verwenden, die vom Anwendungstyp abhängt. Die Anwendung erwirbt ein Token für eine Ressource in der Ebene, um Zugriff zu erhalten. Die Ressource ist ein Endpunkt in der Verwaltungs- oder Datenebene, abhängig von der Azure-Umgebung. Anschließend sendet die Anwendung unter Verwendung des Tokens eine REST-API-Anforderung an den Endpunkt des verwalteten HSM. Weitere Informationen finden Sie in der Gesamtdarstellung des Authentifizierungsablaufs.

Die Verwendung eines einzigen Authentifizierungsmechanismus für beide Ebenen hat mehrere Vorteile:

  • Organisationen können den Zugriff auf alle verwalteten HSMs in ihrer Organisation zentral steuern.
  • Wenn ein*e Benutzer*in aus der Organisation ausscheidet, verliert er bzw. sie umgehend den Zugriff auf alle verwalteten HSMs in der Organisation.
  • Organisationen können die Authentifizierung mithilfe von Optionen in der Microsoft Entra-ID anpassen, z. B. um die mehrstufige Authentifizierung für zusätzliche Sicherheit zu ermöglichen.

Ressourcenendpunkte

Sicherheitsprinzipale greifen über Endpunkte auf die Ebenen zu. Die Zugriffssteuerung für die beiden Ebenen arbeiten voneinander unabhängig. Um einer Anwendung Zugriff auf die Verwendung von Schlüsseln in einem verwalteten HSM zu gewähren, gestatten Sie den Zugriff auf die Datenebene mithilfe der lokalen RBAC für verwaltetes HSM. Um Benutzer*innen Zugriff auf Ressourcen des verwalteten HSM zu gewähren, damit sie die verwalteten HSMs erstellen, lesen, löschen, verschieben und andere Eigenschaften und Tags bearbeiten können, verwenden Sie Azure RBAC.

Die folgende Tabelle zeigt die Endpunkte für die Verwaltungs- und Datenebene:

Zugriffsebene Zugriffsendpunkte Operationen (Operations) Zugriffssteuerungsmechanismus
Verwaltungsebene Global:
management.azure.com:443
 Erstellen, Lesen, Aktualisieren, Löschen und Verschieben von verwalteten HSMs

Festlegen von verwalteten HSM-Tags		 Azure RBAC
Datenebene Global:
<hsm-name>.managedhsm.azure.net:443
 Schlüssel: Entschlüsseln, verschlüsseln,
Umbruch aufheben, umbrechen, überprüfen, signieren, abrufen, auflisten, aktualisieren, erstellen, importieren, löschen, sichern, wiederherstellen, bereinigen

Rollenverwaltung auf Datenebene (lokale RBAC für verwaltetes HSM): Rollendefinitionen auflisten, Rollen zuweisen, Rollenzuweisungen löschen, benutzerdefinierte Rollen definieren

Sichern und Wiederherstellen: Sichern, Wiederherstellen, Status von Sicherungs- und Wiederherstellungsvorgängen überprüfen

Sicherheitsdomäne: Sicherheitsdomäne herunterladen und hochladen		 Lokale RBAC für verwaltetes HSM

Verwaltungsebene und Azure RBAC

Auf der Verwaltungsebene autorisieren Sie mit Azure RBAC die Vorgänge, die ein Aufrufer ausführen darf. Im Azure RBAC-Modell verfügt jedes Azure-Abonnement über eine Instanz von Microsoft Entra-ID. Über dieses Verzeichnis gewähren Sie Benutzern, Gruppen und Anwendungen Zugriff. Der Zugriff wird gewährt, um Abonnementressourcen zu verwalten, die das Bereitstellungsmodell von Azure Resource Manager verwenden. Um den Zugriff zu gewähren, können Sie das Azure-Portal, die Azure CLI, Azure PowerShell oder Azure Resource Manager-REST-APIs verwenden.

Sie erstellen einen Schlüsseltresor in einer Ressourcengruppe und verwalten den Zugriff mithilfe der Microsoft Entra-ID. So können Sie Benutzern oder einer Gruppe die Verwaltung von Schlüsseltresoren in einer Ressourcengruppe ermöglichen. Sie gewähren den Zugriff auf eine bestimmte Bereichsebene, indem Sie entsprechende Azure-Rollen zuordnen. Um einem Benutzer Zugriff für die Verwaltung von Schlüsseltresoren zu gewähren, weisen Sie ihm für einen bestimmten Bereich die vordefinierte Rolle key vault Contributor zu. Die folgenden Bereichsebenen können einer Azure-Rolle zugeordnet werden:

  • Verwaltungsgruppe: Eine auf Abonnementebene zugewiesene Azure-Rolle gilt für alle Abonnements in dieser Verwaltungsgruppe.
  • Abonnement: Eine auf Abonnementebene zugewiesene Azure-Rolle gilt für alle Ressourcengruppen und Ressourcen innerhalb des Abonnements.
  • Ressourcengruppe: Eine auf Ressourcengruppenebene zugewiesene Azure-Rolle gilt für alle Ressourcen in der Ressourcengruppe.
  • Bestimmte Ressourcen: Eine für eine bestimmte Ressource zugewiesene Azure-Rolle gilt für diese Ressource. In diesem Fall ist die Ressource ein bestimmter Schlüsseltresor.

Mehrere Rollen sind vordefiniert. Wenn eine vordefinierte Rolle nicht Ihren Anforderungen entspricht, können Sie Ihre eigene Rolle definieren. Weitere Informationen finden Sie unter Azure RBAC: Integrierte Rollen.

Datenebene und lokale RBAC für verwaltetes HSM

Sie gewähren einem Sicherheitsprinzipal Zugriff zur Ausführung bestimmter Schlüsselvorgänge, indem Sie ihm eine Rolle zuweisen. Für jede Rollenzuweisung müssen Sie eine Rolle und einen Bereich angeben, für den diese Zuweisung gilt. Für lokale RBAC für verwaltetes HSM stehen zwei Bereiche zur Verfügung.

  • / oder /keys: HSM-Ebenenbereich. Sicherheitsprinzipale, denen eine Rolle in diesem Bereich zugewiesen wurde, können die in der Rolle definierten Vorgänge für alle Objekte (Schlüssel) im verwalteten HSM ausführen.
  • /keys/<key-name>: Schlüsselebenenbereich. Sicherheitsprinzipale, denen eine Rolle in diesem Bereich zugewiesen wurde, können die in dieser Rolle definierten Vorgänge nur für alle Versionen des angegebenen Schlüssels ausführen.

Nächste Schritte