Grundlegende Konzepte von Azure Key Vault
Azure Key Vault ist ein Clouddienst zum sicheren Speichern und Zugreifen auf Geheimnisse. Als Geheimnis wird alles bezeichnet, für das Sie den Zugriff streng kontrollieren möchten, z. B. API-Schlüssel, Kennwörter, Zertifikate oder kryptografische Schlüssel. Der Key Vault-Dienst unterstützt zwei Arten von Containern: Tresore und verwaltete HSM-Pools (Hardware Security Module). Tresore unterstützen die Speicherung von Software und HSM-gestützten Schlüsseln, Geheimnissen und Zertifikaten. Verwaltete HSM-Pools unterstützen nur HSM-gestützte Schlüssel. Ausführliche Informationen finden Sie unter Übersicht über die Azure Key Vault-REST-API.
Hier sind weitere wichtige Begriffe:
Tenant: Ein Mandant ist die Organisation, die eine bestimmte Instanz von Microsoft-Clouddiensten besitzt und verwaltet. Der am häufigsten verwendete Begriff, um auf die Azure- und Microsoft 365-Dienste für eine Organisation zu verweisen.
Tresorbesitzer: Ein Tresorbesitzer kann einen Schlüsseltresor erstellen und über Vollzugriff sowie über uneingeschränkte Kontrolle verfügen. Außerdem kann der Tresorbesitzer auch eine Überprüfung einrichten, um zu protokollieren, wer auf Geheimnisse und Schlüssel zugreift. Administratoren können den Lebenszyklus des Schlüssels steuern. Sie können zu einer neuen Version des Schlüssels wechseln, den Schlüssel sichern und ähnliche Aufgaben ausführen.
Tresorconsumer: Ein Tresorconsumer kann Aktionen für die Objekte im Schlüsseltresor ausführen, wenn der Tresorbesitzer dem Consumer Zugriff gewährt. Welche Aktionen verfügbar sind, hängt von den gewährten Berechtigungen ab.
Administratoren für verwaltete HSMs: Benutzer, denen die Rolle „Administrator“ zugewiesen ist, haben die vollständige Kontrolle über einen verwalteten HSM-Pool. Sie können weitere Rollenzuweisungen erstellen, um den kontrollierten Zugriff an andere Benutzer zu delegieren.
Kryptoverantwortlicher/Kryptografiebenutzer für verwaltete HSMs: Integrierte Rollen, die normalerweise Benutzern oder Dienstprinzipalen zugewiesen werden, die kryptografische Vorgänge mithilfe von Schlüsseln in verwaltetem HSM durchführen. Kryptografiebenutzer*innen können neue Schlüssel erstellen, aber keine Schlüssel löschen.
Managed HSM Crypto Service Encryption User (Benutzer der Kryptografiedienstverschlüsselung für verwaltete HSMs): integrierte Rolle, die in der Regel für die Verschlüsselung von ruhenden Daten mit kundenseitig verwaltetem Schlüssel einem Dienstkonto mit verwalteter Dienstidentität (z. B. Speicherkonto) zugewiesen wird.
Ressource: Eine Ressource ist ein verwaltbares Element, das über Azure verfügbar ist. Allgemeine Beispiele sind virtuelle Computer, Speicherkonten, Web-Apps, Datenbanken und virtuelle Netzwerke. Es gibt noch viele weitere.
Ressourcengruppe: Eine Ressourcengruppe ist ein Container, der verwandte Ressourcen für eine Azure-Lösung enthält. Die Ressourcengruppe kann alle Ressourcen für die Lösung oder nur die Ressourcen enthalten, die Sie als Gruppe verwalten möchten. Sie entscheiden in Abhängigkeit davon, was für Ihre Organisation am sinnvollsten ist, wie Sie die Ressourcen den Ressourcengruppen zuordnen möchten.
Sicherheitsprinzipal: Ein Azure-Sicherheitsprinzipal ist eine Sicherheitsidentität, die durch von Benutzern erstellte Apps, Dienste und Automatisierungstools verwendet wird, um auf bestimmte Azure-Ressourcen zuzugreifen. Das Konzept lässt sich als „Benutzeridentität“ (Benutzername und Kennwort oder Zertifikat) mit einer bestimmten Rolle und streng kontrollierten Berechtigungen beschreiben. Ein Sicherheitsprinzipal sollte – im Gegensatz zu einer allgemeinen Benutzeridentität – nur für bestimmte Dinge zuständig sein. Wenn Sie ihm nur die Berechtigungen gewähren, die er zum Ausführen seiner Verwaltungsaufgaben benötigt, verbessert das die Sicherheit. Ein Sicherheitsprinzipal, der mit einer Anwendung oder einem Dienst verwendet wird, wird als Dienstprinzipal bezeichnet.
Microsoft Entra ID: Microsoft Entra ID ist der Active Directory-Dienst für einen Mandanten. Jedes Verzeichnis verfügt über mindestens eine Domäne. Einem Verzeichnis können viele Abonnements zugeordnet sein, aber nur ein Mandant.
Azure-Mandanten-ID: Eine Mandanten-ID ist eine eindeutige Möglichkeit, eine Microsoft Entra-Instanz innerhalb eines Azure-Abonnements zu identifizieren.
Verwaltete Identitäten: Azure Key Vault bietet eine Möglichkeit zum sicheren Speichern von Anmeldeinformationen und anderen Schlüsseln und Geheimnissen. Um diese abrufen zu können, muss sich Ihr Code jedoch bei Key Vault authentifizieren. Die Verwendung einer verwalteten Identität vereinfacht die Lösung dieses Problems, indem für Azure-Dienste eine automatisch verwaltete Identität in Microsoft Entra ID bereitgestellt wird. Sie können diese Identität verwenden, um sich bei Key Vault oder einem beliebigen Dienst zu authentifizieren, der die Microsoft Entra-Authentifizierung unterstützt, ohne dass Anmeldeinformationen in Ihrem Code vorhanden sind. Weitere Informationen finden Sie in der nachfolgenden Abbildung und unter Verwaltete Identitäten für Azure-Ressourcen – Übersicht.
Authentifizierung
Sie müssen sich zuerst authentifizieren, um Vorgänge mit Key Vault durchführen zu können. Es gibt drei Möglichkeiten für die Authentifizierung bei Key Vault:
- Verwaltete Identitäten für Azure-Ressourcen: Wenn Sie eine App auf einer VM in Azure bereitstellen, können Sie Ihrer VM eine Identität zuweisen, die Zugriff auf den Key Vault hat. Sie können Identitäten auch anderen Azure-Ressourcen zuweisen. Der Vorteil bei dieser Vorgehensweise ist, dass die App bzw. der Dienst die Drehung des ersten Geheimnisses nicht verwaltet. Die Identität wird von Azure automatisch gedreht. Als bewährte Methode wird diese Vorgehensweise empfohlen.
- Dienstprinzipal und Zertifikat: Sie können einen Dienstprinzipal und ein zugehöriges Zertifikat verwenden, das Zugriff auf Key Vault hat. Diese Vorgehensweise wird nicht empfohlen, da der Besitzer oder Entwickler der Anwendung das Zertifikat drehen muss.
- Dienstprinzipal und Geheimnis: Obwohl Sie einen Dienstprinzipal und ein Geheimnis zur Authentifizierung bei Key Vault verwenden können, wird diese Vorgehensweise nicht empfohlen. Es ist schwierig, das Bootstrapgeheimnis, das zur Authentifizierung bei Key Vault verwendet wird, automatisch zu drehen.
Verschlüsselung von Daten während der Übertragung
Azure Key Vault erzwingt das Transport Layer Security-Protokoll (TLS), um Daten zu schützen, wenn sie zwischen Azure Key Vault und Clients übertragen werden. Clients handeln eine TLS-Verbindung mit Azure Key Vault aus. TLS bietet strenge Authentifizierung, Datenschutz von Nachrichten und Integrität (ermöglicht die Erkennung von Manipulation, Abfangen und Fälschung von Nachrichten), Interoperabilität, Algorithmusflexibilität sowie einfache Bereitstellung und Verwendung.
Perfect Forward Secrecy (PFS) schützt Verbindungen zwischen den Clientsystemen von Kunden und den Clouddiensten von Microsoft durch eindeutige Schlüssel. Die Verbindungen verwenden zudem RSA-basierte Verschlüsselungsschlüssellängen von 2.048 Bit. Diese Kombination erschwert das Abfangen von Daten während der Übertragung und den Zugriff darauf.
Key Vault-Rollen
Die folgende Tabelle enthält Informationen dazu, wie Sie mithilfe des Schlüsseltresors die Anforderungen von Entwicklern und Sicherheitsadministratoren erfüllen können.
| Role | Problembeschreibung | Lösung durch den Azure Key Vault |
|---|---|---|
| Entwickler einer Azure-Anwendung | „Ich möchte eine Anwendung für Azure schreiben, die Schlüssel für die Signierung und Verschlüsselung verwendet. Diese Schlüssel sollen sich jedoch außerhalb meiner Anwendung befinden, damit die Lösung auch für eine geografisch verteilte Anwendung geeignet ist. Ich möchte Schlüssel und Geheimnisse schützen, ohne den Code dafür selbst zu schreiben. Außerdem sollen die Schlüssel auf einfache Weise und mit optimaler Leistung in meinen Anwendungen verwendbar sein.“ |
√ Schlüssel werden in einem Tresor gespeichert und bei Bedarf über einen URI aufgerufen. √ Schlüssel werden mit branchenüblichen Algorithmen, Schlüssellängen und Hardwaresicherheitsmodulen von Azure geschützt. √ Schlüssel werden in HSMs verarbeitet, die sich in den gleichen Azure-Datencentern befinden wie die Anwendungen. Durch diese Methode werden im Gegensatz zu einer Lösung, bei der die Schlüssel an einem anderen Ort (beispielsweise lokal) vorliegen, eine höhere Zuverlässigkeit und eine geringere Latenz erreicht. |
| Entwickler von SaaS-Lösungen (Software-as-a-Service) | „Ich möchte weder die Verantwortung noch die Haftung für Schlüssel und geheime Schlüssel für Kundenmandanten übernehmen. Ich möchte, dass Kunden sowohl die Verantwortung als auch die Verwaltung für ihre Schlüssel übernehmen, sodass ich mich auf meine eigentlichen Aufgaben konzentrieren kann – die Bereitstellung der Softwarefunktionen.“ |
√ Kunden können eigene Schlüssel in Azure importieren und diese verwalten. Wenn eine SaaS-Anwendung kryptografische Vorgänge unter Verwendung von Kundenschlüsseln ausführen muss, führt der Schlüsseltresor diese Vorgänge im Auftrag der Anwendung aus. Die Anwendung hat keine Informationen über die Kundenschlüssel. |
| Sicherheitsbeauftragter (Chief Security Officer, CSO) | „Ich möchte sicherstellen, dass unsere Anwendungen den Anforderungen für FIPS 140 Level 3 HSMs für die sichere Schlüsselverwaltung entsprechen. Ich möchte sicherstellen, dass meine Organisation die Kontrolle über den gesamten Lebenszyklus der Schlüssel behält und die Schlüsselverwendung überwachen kann. Auch wenn wir verschiedene Azure-Dienste und -Ressourcen nutzen, möchte ich die Schlüssel über einen einzigen Speicherort in Azure verwalten.“ |
√ Wählen Sie Tresore oder verwaltete HSMs für FIPS 140 validierte HSMs. √ Wählen Sie Verwaltete HSM-Pools für HSMs aus, die gemäß FIPS 140-2 Level 3 überprüft wurden. √ Mit Key Vault sind Ihre Schlüssel für Microsoft nicht sichtbar und können auch nicht extrahiert werden. √ Die Schlüsselverwendung wird nahezu in Echtzeit protokolliert. √ Der Tresor stellt eine einzige Benutzeroberfläche bereit – unabhängig davon, über wie viele Tresore Sie in Azure verfügen, welche Regionen diese unterstützen und von welchen Anwendungen die Tresore verwendet werden. |
Jeder Benutzer mit einem Azure-Abonnement kann Schlüsseltresore erstellen und verwenden. Wenngleich der Schlüsseltresor insbesondere Entwicklern und Sicherheitsadministratoren Vorteile bietet, kann er durch einen Organisationsadministrator implementiert und verwaltet werden, der andere Azure-Dienste verwaltet. So kann sich dieser Administrator beispielsweise mit einem Azure-Abonnement anmelden, einen Tresor für die Schlüsselspeicherung der Organisation erstellen und dann operative Vorgänge wie die folgenden übernehmen:
- Erstellen oder Importieren eines Schlüssels oder geheimer Informationen
- Widerrufen oder Löschen eines Schlüssels oder geheimer Informationen
- Autorisieren von Benutzern oder Anwendungen für den Zugriff auf den Schlüsseltresor, sodass sie die Schlüssel und geheimen Schlüssel verwalten oder verwenden können
- Konfigurieren der Schlüsselverwendung (z. B. Anmelden oder Verschlüsseln)
- Übersachen der Schlüsselverwendung
Dieser Administrator stellt dann Entwicklern URIs bereit, die sie aus ihren Anwendungen aufrufen können. Dieser Administrator stellt auch Protokollierungsinformationen zur Schlüsselverwendung für den Sicherheitsadministrator bereit.
Entwickler können die Schlüssel außerdem durch Verwendung von APIs direkt verwalten. Weitere Informationen finden Sie im Entwicklerhandbuch für den Schlüsseltresor.
Nächste Schritte
- Hier finden Sie Informationen zu Azure Key Vault-Sicherheitsfunktionen.
- Erfahren Sie, wie Sie Ihre verwalteten HSM-Pools sichern können.
Azure-Tresorschlüssel ist in den meisten Regionen verfügbar. Weitere Informationen finden Sie auf der Seite Preisübersicht für Schlüsseltresor.