Azure Key Vault – Sicherheit

Abgeschlossen

Azure Key Vault schützt kryptografische Schlüssel, Zertifikate (und die privaten Schlüssel, die den Zertifikaten zugeordnet sind) und Geheimnisse (z. B. Verbindungszeichenfolgen und Kennwörter) in der Cloud. Wenn Sie jedoch vertrauliche und unternehmenskritische Daten speichern, müssen Sie Maßnahmen ergreifen, um die Sicherheit Ihrer Tresore und der darin gespeicherten Daten zu maximieren.

Netzwerksicherheit

Sie können die Angriffsfläche Ihrer Tresore reduzieren, indem Sie angeben, welche IP-Adressen Zugriff darauf haben. Die VNET-Dienstendpunkte für Azure Key Vault ermöglichen Ihnen, den Zugriff auf angegebene virtuelle Netzwerke zu beschränken. Die Endpunkte ermöglichen Ihnen außerdem, den Zugriff auf eine Liste von IPv4-Adressbereichen (Internet Protocol, Version 4) zu beschränken. Allen Benutzern, die außerhalb dieser Quellen eine Verbindung mit Ihrem Schlüsseltresor herstellen, wird der Zugriff verweigert.

Wenn Firewallregeln in Kraft sind, können Benutzer nur Daten aus Key Vault lesen, wenn ihre Anforderungen aus zulässigen virtuellen Netzwerken oder IPv4-Adressbereichen stammen. Dies gilt auch für den Zugriff auf den Schlüsseltresor aus dem Azure-Portal. Obwohl Benutzer im Azure-Portal zu einem Schlüsseltresor navigieren können, können sie möglicherweise keine Schlüssel, Geheimnisse oder Zertifikate auflisten, wenn ihr Clientcomputer nicht in der Zulassungsliste enthalten ist.

Mit dem Azure Private Link-Dienst können Sie über einen privaten Endpunkt in Ihrem virtuellen Netzwerk auf Azure Key Vault sowie auf in Azure gehostete Kunden-/Partnerdienste zugreifen. Ein privater Endpunkt in Azure ist eine Netzwerkschnittstelle, die Sie privat und sicher mit einem von Azure Private Link betriebenen Dienst verbindet. Der private Endpunkt verwendet eine private IP-Adresse aus Ihrem VNET und bindet den Dienst dadurch in Ihr VNET ein. Der gesamte für den Dienst bestimmte Datenverkehr kann über den privaten Endpunkt geleitet werden. Es sind also keine Gateways, Netzwerkadressenübersetzungsgeräte (NAT), ExpressRoute- oder VPN-Verbindungen oder öffentlichen IP-Adressen erforderlich. Der Datenverkehr zwischen Ihrem virtuellen Netzwerk und dem Dienst wird über das Microsoft-Backbone-Netzwerk übertragen und dadurch vom öffentlichen Internet isoliert. Sie können eine Verbindung mit einer Instanz einer Azure-Ressource herstellen, was ein Höchstmaß an Granularität bei der Zugriffssteuerung ermöglicht.

Transport Layer Security (TLS) und Hypertext Transfer-Protokoll Secure (HTTPS)

Beim Key Vault-Front-End (Datenebene) handelt es sich um einen mehrmandantenfähigen Server. Dies bedeutet, dass die Schlüsseltresore verschiedener Kunden dieselbe öffentliche IP-Adresse gemeinsam nutzen können. Für die Gewährleistung von Isolation wird jede HTTP-Anforderung unabhängig von anderen Anforderungen authentifiziert und autorisiert.

Das HTTPS-Protokoll ermöglicht es dem Client, an der TLS-Aushandlung teilzunehmen. Clients können die TLS-Version erzwingen. Wenn dies der Fall ist, wird für die gesamte Verbindung der entsprechende Ebenenschutz verwendet. Key Vault unterstützt die Protokollversionen TLS 1.2 und 1.3.

Schlüsseltresor-Authentifizierungsoptionen

Wenn Sie einen Schlüsseltresor in einem Azure-Abonnement erstellen, wird dieser 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 den Schlüsseltresor zugreifen zu können. In beiden Fällen können Anwendungen auf drei Arten auf den Schlüsseltresor zugreifen:

• Nur Anwendungszugriff: Die Anwendung stellt einen Dienstprinzipal oder eine verwaltete Identität dar. Diese Identität ist das häufigste Szenario für Anwendungen, die in regelmäßigen Abständen auf Zertifikate, Schlüssel oder Geheimnisse aus dem Schlüsseltresor zugreifen müssen. Damit dieses Szenario funktioniert, muss die objectId der Anwendung in der Zugriffsrichtlinie angegeben werden. Die applicationId darf nicht angegeben werden oder muss NULL sein.
  
• Nur Benutzerzugriff: Die Benutzer*innen greifen von einer beliebigen auf dem Mandanten registrierten Anwendung auf den Schlüsseltresor zu. Beispiele für diese Art von Zugriff wären etwa Azure PowerShell und das Azure-Portal. Damit dieses Szenario funktioniert, muss die objectId der Benutzer*innen in der Zugriffsrichtlinie angegeben werden. Die applicationId darf nicht angegeben werden oder muss NULL sein.
• Anwendungs- und Benutzerzugriff (manchmal als Verbundidentität bezeichnet): Die Benutzer*innen müssen von einer bestimmten Anwendung aus auf den Schlüsseltresor zugreifen. Die Anwendung muss den On-Behalf-Of-Authentifizierungsflow (OBO) verwenden, um die Identität der Benutzer*innen anzunehmen. Damit dieses Szenario funktioniert, müssen sowohl die applicationId als auch die objectId in der Zugriffsrichtlinie angegeben werden. Die applicationId identifiziert die erforderliche Anwendung und die objectId die Benutzer*innen. Diese Option ist derzeit nicht verfügbar für die Azure RBAC-Datenebene.

Bei allen Arten des Zugriffs wird die Anwendung in Microsoft Entra ID authentifiziert. Die Anwendung verwendet eine beliebige unterstützte Authentifizierungsmethode, die auf dem Anwendungstyp basiert. Die Anwendung erwirbt ein Token für eine Ressource in der Ebene, um den Zugriff zu gewähren. Die Ressource ist ein Endpunkt in der Verwaltungs- oder Datenebene, basierend auf der Azure-Umgebung. Anschließend sendet die Anwendung unter Verwendung des Tokens eine REST-API-Anforderung an einen Schlüsseltresor.

Das Modell eines einzelnen Mechanismus für die Authentifizierung für beide Ebenen hat mehrere Vorteile:

• Organisationen können den Zugriff auf alle Schlüsseltresore zentral steuern.
  
• Wenn ein Benutzer aus der Organisation ausscheidet, verliert er umgehend den Zugriff auf sämtliche Schlüsseltresore in der Organisation.
• Organisationen können die Authentifizierung mithilfe der Optionen in Microsoft Entra ID anpassen und z. B. für zusätzliche Sicherheit die Multi-Faktor-Authentifizierung aktivieren.

Übersicht über das Zugriffsmodell

Der Zugriff auf einen Schlüsseltresor wird über zwei Schnittstellen gesteuert: die Verwaltungsebene und die Datenebene. Die Verwaltungsebene dient zum Verwalten des Schlüsseltresors selbst. Zu den Vorgängen in dieser Ebene gehören das Erstellen und Löschen von Schlüsseltresoren, das Abrufen von Schlüsseltresor-Eigenschaften und das Aktualisieren von Zugriffsrichtlinien. Auf der Datenebene arbeiten Sie mit den in einem Schlüsseltresor gespeicherten Daten. Sie können Schlüssel, Geheimnisse und Zertifikate hinzufügen, löschen und ändern.

Beide Ebenen verwenden Microsoft Entra ID für die Authentifizierung. Für die Autorisierung wird auf der Verwaltungsebene die rollenbasierte Zugriffssteuerung in Azure (Role-Based Access Control, Azure RBAC) verwendet, während auf der Datenebene eine Key Vault-Zugriffsrichtlinie und Azure RBAC für Key Vault-Vorgänge auf Datenebene zum Einsatz kommen.

Um auf einen Schlüsseltresor in beiden Ebenen zugreifen zu können, müssen alle Anrufe (Benutzer oder Anwendungen) über eine ordnungsgemäße Authentifizierung und Autorisierung verfügen. Die Authentifizierung stellt die Identität des Anrufers fest. Die Autorisierung bestimmt, welche Vorgänge der Aufrufer ausführen darf. Für die Authentifizierung bei Key Vault wird zusätzlich Microsoft Entra ID genutzt, um die Authentifizierung der Identität der vorhandenen Sicherheitsprinzipale zu ermöglichen.

Ein Sicherheitsprinzipal ist ein Objekt, das Benutzer, Gruppen, Dienste oder Anwendungen darstellt, die Zugriff auf Azure-Ressourcen anfordern. Azure weist jedem Sicherheitsprinzipal eine eindeutige Objekt-ID zu.

• Benutzer als Sicherheitsprinzipale identifizieren eine Person, die über ein Profil in Microsoft Entra ID verfügt.
  
• Eine Gruppe als Sicherheitsprinzipal identifiziert eine Gruppe von Benutzer, die in Microsoft Entra ID erstellt wurden. Alle Rollen oder Berechtigungen, die der Gruppe zugewiesen werden, werden allen Benutzern in der Gruppe erteilt.
• Ein Dienstprinzipal ist ein Typ von Sicherheitsprinzipal, der für eine Anwendung oder einen Dienst steht und sozusagen ein Codeausschnitt anstelle eines Benutzers oder einer Gruppe ist. Die Objekt-ID eines Dienstprinzipals wird als dessen Client-ID bezeichnet und verhält sich wie der Benutzername. Der geheime Clientschlüssel oder das Zertifikat des Dienstprinzipals verhält sich wie sein Kennwort. Viele Azure-Dienste unterstützen das Zuweisen von Verwaltete Identität mit automatisierter Verwaltung von Client-ID und Zertifikat. „Verwaltete Identität“ ist die sicherste und empfohlene Option zum Authentifizieren in Azure.

Bedingter Zugriff

Key Vault bietet Unterstützung für Richtlinien für den bedingten Microsoft Entra-Zugriff. Mithilfe von Richtlinien für bedingten Zugriff können Sie bei Bedarf die richtigen Zugriffssteuerungen auf Key Vault anwenden, um die Sicherheit Ihrer Organisation zu gewährleisten, und behindern die Benutzer*innen ansonsten nicht.

Privilegierter Zugriff

Die Autorisierung bestimmt, welche Vorgänge der Aufrufer ausführen darf. Die Autorisierung in Key Vault verwendet rollenbasierte Zugriffssteuerung in Azure (Azure RBAC) auf Verwaltungsebene und entweder Azure RBAC oder Azure Key Vault-Zugriffsrichtlinien auf Datenebene.

Der Zugriff auf Tresore erfolgt über zwei Schnittstellen oder Ebenen. Die Ebenen lauten Verwaltungsebene und Datenebene.

• Auf Verwaltungsebene verwalten Sie Key Vault selbst. Sie stellt die Schnittstelle zum Erstellen und Löschen von Tresoren dar. Sie können auch die Eigenschaften von Schlüsseltresoren lesen und Zugriffsrichtlinien verwalten.
  
• Auf der Datenebene arbeiten Sie mit den in einem Schlüsseltresor gespeicherten Daten. Sie können Schlüssel, Geheimnisse und Zertifikate hinzufügen, löschen und ändern.

Die Anwendungen 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 Schlüsseltresor zu gewähren, müssen Sie den Zugriff auf Datenebene unter Verwendung von Azure RBAC oder einer Key Vault-Zugriffsrichtlinie gewähren. Um einem Benutzer Lesezugriff auf die Eigenschaften und Tags des Schlüsseltresors zu gewähren, aber nicht auf Daten (Schlüssel, Geheimnisse oder Zertifikate), gewähren Sie mit Azure RBAC den Zugriff auf die Verwaltungsebene.

Zugriffsebene	Zugriffsendpunkte	Vorgänge	Zugriffssteuerungsmechanismus
Verwaltungsebene	Global: management.azure.com:443 Microsoft Azure, betrieben von 21Vianet: management.chinacloudapi.cn:443 Azure US Government: management.usgovcloudapi.net:443 Azure Deutschland: management.microsoftazure.de:443	Erstellen, Lesen, Aktualisieren und Löschen von Schlüsseltresoren Festlegen von Zugriffsrichtlinien für den Schlüsseltresor Festlegen der Schlüsseltresortags	Azure RBAC
Datenebene	Global: <Tresorname>.vault.azure.net:443 Microsoft Azure, betrieben von 21Vianet: <Tresorname>.vault.azure.cn:443 Azure US Government: <Tresorname>.vault.usgovcloudapi.net:443 Azure Deutschland: <Tresorname>.vault.microsoftazure.de:443	Schlüssel: encrypt, decrypt, wrapKey, unwrapKey, sign, verify, get, list, create, update, import, delete, recover, back up, restore, purge, rotate (Preview), getrotationpolicy (Preview), setrotationpolicy (Preview), release (Preview) Zertifikate: manage contacts, getissuers, list issuers, set issuers, delete issuers, manage issuers, get, list, create, import, update, delete, recover, back up, restore, purge Geheimnisse: get, list, set, delete, recover, back up, restore, purge	Key Vault-Zugriffsrichtlinie oder Azure RBAC

Verwalten des Administratorzugriffs auf Key Vault

Wenn Sie einen Schlüsseltresor in einer Ressourcengruppe erstellen, steuern Sie den Zugriff mithilfe von Microsoft Entra ID. So können Sie Benutzern oder einer Gruppe die Verwaltung von Schlüsseltresoren in einer Ressourcengruppe ermöglichen. Sie können den Zugriff auf eine bestimmte Bereichsebene gewähren, indem Sie entsprechende Azure-Rollen zuordnen. Wenn Sie also Benutzer*innen Zugriff zum Verwalten von Schlüsseltresoren gewähren möchten, weisen Sie ihnen für einen bestimmten Bereich die vordefinierte Rolle Key Vault-Mitwirkender zu. Die folgenden Bereichsebenen können einer Azure-Rolle zugeordnet werden:

• 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.

Falls bei Verwendung des Berechtigungsmodells für Zugriffsrichtlinien ein Benutzer für eine Schlüsseltresor-Verwaltungsebene über die Berechtigung Contributor verfügt, kann er sich durch Festlegen einer Key Vault-Zugriffsrichtlinie selbst Zugriff auf die Datenebene gewähren. Sie sollten mithilfe des Berechtigungsmodells für Zugriffsrichtlinien sehr genau steuern, wer über die Rolle Contributor Zugriff auf Ihre Sicherungstresore hat, um sicherzustellen, dass nur autorisierte Benutzer auf Ihre Sicherungstresore, Schlüssel, Geheimnisse und Zertifikate zugreifen und diese verwalten können. Es wird empfohlen, das neue RBAC-Berechtigungsmodell zu verwenden, um dieses Problem zu vermeiden. Mit dem RBAC-Berechtigungsmodell ist die Berechtigungsverwaltung auf die Rollen „Besitzer“ und „Benutzerzugriffsadministrator“ beschränkt. Dies ermöglicht die Aufgabentrennung zwischen Rollen für Sicherheitsvorgänge und allgemeine Verwaltungsvorgänge.

Steuern des Zugriffs auf Key Vault-Daten

Sie können den Zugriff auf Key Vault-Schlüssel, -Zertifikate und -Geheimnisse mithilfe von Azure RBAC oder Key Vault-Zugriffsrichtlinien steuern.

Protokollierung und Überwachung

Bei der Key Vault-Protokollierung werden Informationen zu den Aktivitäten gespeichert, die für Ihren Tresor ausgeführt werden.

Sie können Key Vault in Event Grid integrieren, um Benachrichtigungen zu erhalten, wenn sich der Status eines im Schlüsseltresor gespeicherten Schlüssels, Zertifikats oder Geheimnisses geändert hat.

Es ist auch wichtig, die Integrität Ihres Schlüsseltresors zu überwachen, um sicherzustellen, dass Ihr Dienst wie vorgesehen funktioniert.

Sicherung und Wiederherstellung

Mit den Azure Key Vault-Funktionen zum Schutz beim vorläufigen und endgültigen Löschen können Sie gelöschte Tresore und Tresorobjekte wiederherstellen.

Sie sollten beim Aktualisieren, Löschen und Erstellen von Objekten in einem Schlüsseltresor auch regelmäßig Sicherungskopien Ihres Schlüsseltresors erstellen.