Azure Key Vault – Sicherheit

Artikel
01/30/2024

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.

Dieser Artikel bietet eine Übersicht über Sicherheitsfeatures und Best Practices für Azure Key Vault.

Hinweis

Eine umfassende Liste mit Sicherheitsempfehlungen für Azure Key Vault finden Sie in der Sicherheitsbaseline für Azure Key Vault.

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. Vollständige Informationen dazu finden Sie unter VNET-Dienstendpunkte für Azure Key Vault.

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. Die Implementierungsschritte finden Sie unter Konfigurieren von Azure Key Vault-Firewalls und virtuellen Netzwerken.

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, NAT-Geräte, ExpressRoute-/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. Die Implementierungsschritte finden Sie unter Integrieren von Key Vault in Azure Private Link.

TLS und HTTPS

Beim Key Vault-Front-End (Datenebene) handelt es sich um einen mehrinstanzenfä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.

Hinweis

Sie können die von Clients verwendete TLS-Version überwachen, indem Sie Key Vault-Protokolle mit dieser Kusto-Beispielabfrage überwachen.

Key Vault-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, und die applicationId darf nicht angegeben werden oder muss null sein.
Nur Benutzerzugriff: Der Benutzer greift auf den Schlüsseltresor aus allen Anwendungen zu, die im Mandanten registriert sind. Beispiele für diese Art von Zugriff wären etwa Azure PowerShell und das Azure-Portal. Damit dieses Szenario funktioniert, muss die objectId des Benutzers in der Zugriffsrichtlinie angegeben werden, und die applicationId darf nicht angegeben werden oder muss null sein.
Anwendungs- und Benutzerzuriff (manchmal als Verbundidentität bezeichnet): Der Benutzer muss aus einer bestimmten Anwendung auf den Schlüsseltresor zugreifen, und die Anwendung muss den On-Behalf-Of-Authentifizierungsdatenfluss verwenden, um die Identität des Benutzers anzunehmen. Damit dieses Szenario funktioniert, müssen sowohl applicationId als auch objectId in der Zugriffsrichtlinie angegeben werden. applicationId identifiziert die erforderliche Anwendung, und objectId identifiziert den Benutzer. 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. Weitere Informationen finden Sie in der Gesamtdarstellung des Authentifizierungsablaufs.

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 über die Optionen in Microsoft Entra ID anpassen und so beispielsweise die Multi-Faktor-Authentifizierung aktivieren, um die Sicherheit zu verbessern.

Weitere Informationen finden Sie unter Grundlagen der Key Vault-Authentifizierung.

Ü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. Die Authentifizierung mit Key Vault funktioniert in Verbindung mit Microsoft Entra ID, was für die Authentifizierung der Identität eines bestimmten Sicherheitsprinzipals zuständig ist.

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.

Weitere Informationen zur Authentifizierung bei Key Vault finden Sie unter Authentifizieren bei Azure Key Vault.

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.

Weitere Informationen finden Sie unter Übersicht über den bedingten Zugriff.

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.

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

Zugriffsebene	Zugriffsendpunkte	Operationen (Operations)	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, backup, restore, purge, rotate (Vorschau), getrotationpolicy (Vorschau), setrotationpolicy (Vorschau), release (Vorschau) Zertifikate: managecontacts, getissuers, listissuers, setissuers, deleteissuers, manageissuers, get, list, create, import, update, delete, recover, backup, restore, purge Geheimnisse: get, list, set, delete,recover, backup, 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. 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:

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.

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

Wichtig

Wenn ein Benutzer über Contributor, Key Vault Contributor oder eine andere Rolle mit Microsoft.KeyVault/vaults/write Berechtigungen für eine Schlüsseltresor-Verwaltungsebene verfügt, kann der Benutzer selbst Zugriff auf die Datenebene gewähren, indem er eine Zugriffsrichtlinie für den Key Vault festlegt. 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.

Weitere Informationen finden Sie unter

Protokollierung und Überwachung

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

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. Informationen dazu finden Sie unter Überwachen von Key Vault mit Azure Event Grid.

Es ist auch wichtig, die Integrität Ihres Schlüsseltresors zu überwachen, um sicherzustellen, dass Ihr Dienst wie vorgesehen funktioniert. Unter Überwachung und Warnungen für Azure Key Vault erfahren Sie, wie Sie dazu vorgehen.

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. Vollständige Informationen dazu finden Sie unter Übersicht über die Azure Key Vault-Funktion für vorläufiges Löschen.

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