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.
Um zu verstehen, wie Azure-Ressourcenanbieter ruhende Verschlüsselung implementieren, müssen Sie die verschiedenen Verschlüsselungsmodelle und deren Vor- und Nachteile verstehen. Um eine gemeinsame Sprache und Taxonomie sicherzustellen, verwenden Azure-Ressourcenanbieter diese Definitionen.
Azure verschlüsselt ruhende Daten standardmäßig mithilfe von plattformverwalteten Schlüsseln. Sie können optional andere Schlüsselverwaltungsansätze basierend auf Ihren Sicherheits- und Complianceanforderungen auswählen. Serverseitige Verschlüsselung umfasst drei Szenarien:
Serverseitige Verschlüsselung mittels plattformverwalteter Schlüssel (Standard).
- Azure-Ressourcenanbieter führen die Verschlüsselungs- und Entschlüsselungsvorgänge aus.
- Microsoft verwaltet die Schlüssel automatisch.
- Standardmäßig aktiviert, ohne dass eine Konfiguration erforderlich ist.
- Vollständige Cloudfunktionalität.
Serverseitige Verschlüsselung durch Nutzung von kundenverwalteten Schlüsseln in Azure Key Vault (optional).
- Azure-Ressourcenanbieter führen die Verschlüsselungs- und Entschlüsselungsvorgänge aus.
- Du steuerst die Schlüssel über Azure Key Vault.
- Erfordert Kundenkonfiguration und -verwaltung.
- Vollständige Cloudfunktionalität.
Serverseitige Verschlüsselung durch die Verwendung von kundenverwalteten Schlüsseln auf kundenkontrollierter Hardware (erweiterte Option).
- Azure-Ressourcenanbieter führen die Verschlüsselungs- und Entschlüsselungsvorgänge aus.
- Sie verwalten Schlüssel auf vom Kunden kontrollierter Hardware.
- Komplexe Konfiguration und eingeschränkte Azure-Dienstunterstützung.
- Vollständige Cloudfunktionalität.
Serverseitige Verschlüsselungsmodelle beziehen sich auf die Verschlüsselung, die der Azure-Dienst ausführt. In diesem Modell führt der Ressourcenanbieter die Verschlüsselungs- und Entschlüsselungsvorgänge aus. So kann Azure Storage beispielsweise Daten in Klartext-Operationen empfangen und die Ver- und Entschlüsselung intern durchführen. Der Ressourcenanbieter könnte Verschlüsselungsschlüssel verwenden, die Microsoft oder der Kunde verwaltet, je nach deiner Konfiguration.
Jede serverseitige Verschlüsselung in ruhenden Modellen weist charakteristische Merkmale der Schlüsselverwaltung auf. Diese Merkmale umfassen, wo und wie Sie Verschlüsselungsschlüssel erstellen und speichern, sowie die Zugriffsmodelle und die Schlüsseldrehungsverfahren.
Für die Verschlüsselung auf Client-Seite sollten Sie dies in Betracht ziehen:
- Azure-Dienste können entschlüsselte Daten nicht sehen.
- Die Kunden bewahren die Schlüssel lokal auf (oder in anderen sicheren Speichern). Azure-Dienste haben keinen Zugriff auf Schlüssel.
- Eingeschränkte Cloudfunktionalität.
Die unterstützten Verschlüsselungsmodelle in Azure gliedern sich in zwei Hauptgruppen: Client-Verschlüsselung und serverseitige Verschlüsselung. Unabhängig vom verwendeten Verschlüsselungsmodell empfehlen Azure-Dienste immer die Verwendung eines sicheren Transports wie TLS oder HTTPS. Daher wird die Adressverschlüsselung beim Transport über das Transportprotokoll verwendet. Es sollte kein wesentlicher Faktor bei der Entscheidung sein, welches Modell für die Verschlüsselung ruhender Daten verwendet wird.
Clientverschlüsselungsmodell
Das Client-Verschlüsselungsmodell bezieht sich auf die Verschlüsselung, die der Dienst oder die aufrufende Anwendung außerhalb des Ressourcenanbieters oder von Azure durchführt. Die Dienstanwendung in Azure oder eine Anwendung, die im Kundendatencenter ausgeführt wird, kann die Verschlüsselung ausführen. In beiden Fällen erhält der Azure-Ressourcenanbieter bei der Verwendung dieses Verschlüsselungsmodells einen verschlüsselten Datenblob, ohne die Daten in irgendeiner Weise entschlüsseln oder auf die Verschlüsselungsschlüssel zugreifen zu können. In diesem Modell behandelt der aufrufende Dienst oder die Anwendung die Schlüsselverwaltung und hält sie für den Azure-Dienst undurchsichtig.
Serverseitige Verschlüsselung mittels plattformverwalteter Schlüssel (Standard)
Für die meisten Kunden besteht die wesentliche Voraussetzung darin, sicherzustellen, dass die Daten verschlüsselt werden, wann immer sie ruhen. Serverseitige Verschlüsselung durch die Verwendung von plattformverwalteten Schlüsseln (früher Service-Managed Keys) erfüllt diese Anforderung, indem sie standardmäßig automatische Verschlüsselung bietet. Dieser Ansatz ermöglicht eine Verschlüsselung in Ruhe, ohne dass Kunden Verschlüsselungsschlüssel konfigurieren oder verwalten müssen. Microsoft übernimmt Aufgaben der Schlüsselverwaltung wie die Ausgabe, Rotation und Sicherung von Schlüsseln.
Die meisten Azure-Dienste implementieren dieses Modell als Standardverhalten, das automatische Verschlüsseln ruhender Daten mithilfe von plattformverwalteten Schlüsseln ohne erforderliche Kundenaktion. Der Azure-Ressourcenanbieter erstellt die Schlüssel, speichert sie an einem sicheren Speicherort und ruft sie bei Bedarf ab. Der Dienst hat vollen Zugriff auf die Schlüssel und behält die volle Kontrolle über das Management des Zugangslebenszyklus. Diese Kontrolle bietet robusten Verschlüsselungsschutz ohne jeglichen Verwaltungsaufwand für Kunden.
Die serverseitige Verschlüsselung mithilfe von plattformverwalteten Schlüsseln erfüllt das Bedürfnis nach Datenverschlüsselung im Ruhezustand ohne zusätzlichen Aufwand für den Kunden. Diese Verschlüsselung ist standardmäßig über Azure-Dienste hinweg aktiviert, sodass automatischer Datenschutz bereitgestellt wird, ohne dass eine Kundenkonfiguration oder -verwaltung erforderlich ist. Kunden profitieren sofort von einem robusten Verschlüsselungsschutz, sobald sie Daten in Azure-Diensten speichern, ohne zusätzliche Schritte, Kosten oder fortlaufende Verwaltung.
Serverseitige Verschlüsselung durch plattformverwaltete Schlüssel bedeutet, dass der Dienst vollen Zugriff auf die Speicherung und Verwaltung der Schlüssel hat. Während einige Kunden die Schlüssel verwalten möchten, weil sie das Gefühl haben, mehr Sicherheit zu erlangen, sollten Sie beim Auswerten dieses Modells die Kosten und Risiken berücksichtigen, die mit einer benutzerdefinierten Schlüsselspeicherlösung verbunden sind. In vielen Fällen kann eine Organisation feststellen, dass Ressourceneinschränkungen oder Risiken einer lokalen Lösung größer als das Risiko der Cloudverwaltung der Verschlüsselung bei ruhenden Schlüsseln sind. Dieses Modell ist jedoch möglicherweise nicht für Organisationen ausreichend, die die Erstellung oder die Lebensdauer der Verschlüsselungsschlüssel steuern müssen, oder in denen die Verschlüsselungsschlüssel eines Diensts nicht von denselben Mitarbeitern verwaltet werden, die den Dienst verwalten (d. h. in Fällen, in denen die Schlüsselverwaltung vom allgemeinen Verwaltungsmodell des Diensts getrennt erfolgt).
Schlüsselzugriff
Wenn Sie serverseitige Verschlüsselung mit plattformverwalteten Schlüsseln verwenden, übernimmt der Dienst die Schlüsselerstellung, Speicherung und den Zugriff auf den Dienst. Typischerweise speichern die grundlegenden Azure-Ressourcenanbieter Datenverschlüsselungsschlüssel in einem Speicher, der nahe an den Daten liegt und schnell zugänglich ist, während Schlüsselverschlüsselungsschlüssel in einem sicheren internen Speicher gespeichert sind.
Vorteile
- Einfache Einrichtung.
- Microsoft verwaltet die Schlüsselrotation, Sicherung und Redundanz.
- Sie tragen keine Kosten oder Risiken im Zusammenhang mit der Implementierung eines individuellen Schlüsselmanagement-Systems.
Betrachtungen
- Keine Kundenkontrolle über die Verschlüsselungsschlüssel (Schlüsselspezifikation, Lebenszyklus, Sperrung usw.). Diese Option eignet sich für die meisten Anwendungsfälle, erfüllt jedoch möglicherweise keine speziellen Complianceanforderungen.
- Keine Möglichkeit, die Schlüsselverwaltung vom allgemeinen Verwaltungsmodell für den Dienst zu trennen. Organisationen, die eine Trennung von Aufgaben erfordern, benötigen möglicherweise vom Kunden verwaltete Schlüssel.
Serverseitige Verschlüsselung durch Nutzung von kundenverwalteten Schlüsseln in Azure Key Vault und Azure Key Vault Managed HSM (optional)
In Szenarien, in denen Organisationen spezifische Anforderungen haben, ihre Verschlüsselungsschlüssel über die standardmäßige plattformverwaltete Verschlüsselung hinaus zu kontrollieren, können Kunden optional serverseitige Verschlüsselung wählen, indem sie kundenverwaltete Schlüssel in Key Vault oder Azure Key Vault Managed HSM verwenden. Dieser Ansatz baut auf der ruhenden Standardverschlüsselung auf, sodass Kunden ihre eigenen Schlüssel verwenden können, während Azure die Verschlüsselungs- und Entschlüsselungsvorgänge weiter verarbeitet.
Einige Dienste speichern möglicherweise nur den Root-Key-Verschlüsselungsschlüssel (KEK) im Azure Key Vault und speichern den verschlüsselten Datenverschlüsselungsschlüssel (DEK) an einem internen Ort, der näher an den Daten liegt. In diesem Szenario können Kunden das Bring Your Own Key (BYOK)-Modell nutzen, um Schlüssel in Key Vault zu importieren oder neue Schlüssel in Key Vault zu generieren und diese dann zur Verschlüsselung der gewünschten Ressourcen zu verwenden. Während der Ressourcenanbieter die Verschlüsselungs- und Entschlüsselungsoperationen durchführt, verwendet er das vom Kunden konfigurierte KEK als Root-Key für alle Verschlüsselungsoperationen.
Der Verlust von KEKs bedeutet, dass Daten verloren gehen. Aus diesem Grund sollten die Schlüssel nicht gelöscht werden. Erstellen oder rotieren Sie immer eine Sicherungskopie der Schlüssel, wenn Sie sie erstellen. Wenn ein KEK rotiert wird, umwickelt der Dienst die Datenverschlüsselungsschlüssel mit der neuen Schlüsselversion – die zugrunde liegenden Daten werden nicht neu verschlüsselt. Sowohl die alte als auch die neue Schlüsselversionen müssen aktiviert bleiben, bis alle Datenverschlüsselungsschlüssel mit der neuen Schlüsselversion gewickelt sind. Um sich vor versehentlicher oder böswilliger kryptografischer Erlöschung zu schützen, müssen Soft-Delete- und Purge-Protection auf jedem Tresor aktiviert werden, der Schlüsselverschlüsselungsschlüssel speichert. Statt einen Schlüssel zu löschen, setzen Sie die Einstellung 'enabled' des Schlüsselverschlüsselungsschlüssels auf 'false'. Verwenden Sie Zugriffssteuerungen, um den Zugriff auf einzelne Benutzer oder Dienste in Azure Key Vault oder verwaltetem HSM zu widerrufen.
Warning
Wenn du vermutest, dass ein Schlüssel kompromittiert ist, deaktivieren oder löschen Sie ihn nicht sofort. Das Deaktivieren oder Löschen eines Schlüssels schaltet alle abhängigen Dienste offline, aber es macht keine Kopien des Schlüssels, die gesichert und in einen anderen Tresor zurückgelegt wurden, ungültig. Diese Kopien bleiben voll funktionsfähig. Wechseln Sie stattdessen zu einem neuen Schlüssel und migrieren Sie alle abhängigen Dienste, bevor Sie den kompromittierten Schlüssel deaktivieren. Informationen zum vollständigen Verfahren zur Reaktion auf Vorfälle finden Sie unter Überlegungen zur Sicherung der Sicherheit und zur Reaktion auf wichtige Kompromittierungen.
Für kundenverwaltete Schlüsselszenarien verwenden Sie die Azure Key Vault Premium Tier (HSM-gestützt) als Mindestmaßnahme für Compliance-Anforderungen, die HSM-geschützte Schlüssel vorschreiben. Verwenden Sie Azure Key Vault Managed HSM für Arbeitslasten, die Key Sovereignty oder dedizierte HSM-Kapazität benötigen. Für Organisationen, die regulatorische oder vertragliche Anforderungen haben, die vorschreiben, dass Schlüsselmaterial physisch außerhalb der Microsoft-Infrastruktur liegen muss, unterstützt Azure Key Vault Managed HSM auch externe Schlüsselverwaltung (Vorschau), wodurch das KEK vollständig außerhalb von Azure in einem vom Kunden betriebenen HSM bleibt.
Hinweis
Eine Liste von Diensten, die kundenverwaltete Schlüssel in Azure Key Vault und Azure Key Vault Managed HSM unterstützen, finden Sie unter Services that support CMKs in Azure Key Vault und Azure Key Vault Managed HSM.
Schlüsselzugriff
Im serverseitigen Verschlüsselungsmodell, das kundenverwaltete Schlüssel in Azure Key Vault verwendet, greift der Dienst auf die Schlüssel zu, um bei Bedarf zu verschlüsseln und zu entschlüsseln. Sie machen verschlüsselung bei ruhenden Schlüsseln über eine Zugriffssteuerungsrichtlinie für einen Dienst zugänglich. Diese Richtlinie gewährt dem Dienst Identitätszugriff, um Schlüssel zu erhalten. Sie können einen Azure-Dienst konfigurieren, der im Auftrag eines zugeordneten Abonnements mit einer Identität in diesem Abonnement ausgeführt wird. Der Dienst kann die Microsoft Entra-Authentifizierung durchführen und ein Authentifizierungstoken erhalten, mit dem er sich als der Dienst identifiziert, der im Namen des Abonnements handelt. Der Dienst präsentiert das Token dann Key Vault, um einen Schlüssel zu erhalten, auf den er zugreifen kann.
Für Vorgänge, bei denen Verschlüsselungsschlüssel verwendet werden, können Sie einer Service-Identität Zugriff auf eine der folgenden Operationen gewähren: decrypt, encrypt, unwrapKey, wrapKey, verify, sign, get, list, update, create, import, delete, backup und restore.
Um einen Schlüssel zur Ver- oder Entschlüsselung gespeicherter Daten zu erhalten, muss die Dienstidentität, unter der die Resource Manager-Dienstinstanz ausgeführt wird, über UnwrapKey (um den Schlüssel zur Entschlüsselung abzurufen) und WrapKey (um beim Erstellen eines neuen Schlüssels einen Schlüssel in Key Vault einzufügen) verfügen.
Hinweis
Weitere Informationen zur Key Vault-Autorisierung finden Sie unter Secure your key vault.
Vorteile
- Volle Kontrolle über die verwendeten Tasten. Verschlüsselungsschlüssel werden in Ihrem Key Vault unter Ihrer Kontrolle verwaltet.
- Du kannst mehrere Dienste mit einem Root-Schlüssel verschlüsseln.
- Sie können das Schlüsselmanagement vom Gesamtmanagementmodell des Dienstes trennen.
- Sie können Service und Schlüsselstandort über verschiedene Regionen hinweg definieren.
Nachteile
- Sie haben volle Verantwortung für die Schlüsselzugriffsverwaltung.
- Sie haben volle Verantwortung für die Schlüssellebenszyklusverwaltung.
- Zusätzlicher Einrichtungs- und Konfigurationsaufwand.
Serverseitige Verschlüsselung durch die Verwendung von kundenverwalteten Schlüsseln in kundenkontrollierter Hardware (spezialisierte Option)
Einige Azure-Dienste ermöglichen das Managementmodell von HYOK-Schlüsseln (Host Your Own Key) für Organisationen mit speziellen Sicherheitsanforderungen. Dieser Verwaltungsmodus ist nützlich in stark regulierten Szenarien, die eine Verschlüsselung ruhender Daten und das Schlüsselmanagement in einem proprietären Repository erfordern, das völlig außerhalb der Kontrolle von Microsoft liegt. Es geht über die standardmäßige plattformverwaltete Verschlüsselung und optionale kundenverwaltete Schlüssel in Azure Key Vault hinaus.
In diesem Modell muss der Dienst den Schlüssel von einer externen Seite verwenden, um das DEK zu entschlüsseln. Leistungs- und Verfügbarkeitsgarantien sind betroffen, und die Konfiguration ist wesentlich komplexer. Zusätzlich sind die gesamten Sicherheitsgarantien dieses Modells, weil der Dienst bei den Verschlüsselungs- und Entschlüsselungsvorgängen keinen Zugriff auf das DEK hat, mit denen vergleichbar, die gelten, wenn die Schlüssel in Azure Key Vault vom Kunden verwaltet werden. Daher ist dieses Modell für die meisten Organisationen nicht geeignet, es sei denn, sie haben sehr spezifische regulatorische oder Sicherheitsanforderungen, die mit plattformverwalteten Schlüsseln oder kundenverwalteten Schlüsseln in Azure Key Vault nicht erfüllt werden können. Aufgrund dieser Einschränkungen unterstützen die meisten Azure-Dienste keine serverseitige Verschlüsselung durch Nutzung von kundenverwalteten Schlüsseln in kundenkontrollierter Hardware. Einer der beiden Schlüssel in der Doppelschlüsselverschlüsselung folgt diesem Modell.
Schlüsselzugriff
Wenn man serverseitige Verschlüsselung mit kundenverwalteten Schlüsseln in kundenkontrollierter Hardware verwendet, behält man die Schlüsselschlüssel auf einem System, das man konfiguriert. Azure-Dienste, die dieses Modell unterstützen, bieten eine Möglichkeit, eine sichere Verbindung mit einem vom Kunden bereitgestellten Schlüsselspeicher herzustellen.
Vorteile
- Du hast die volle Kontrolle über den Root-Key, weil ein vom Kunden bereitgestellter Shop die Verschlüsselungsschlüssel verwaltet.
- Du kannst mehrere Dienste mit einem Root-Schlüssel verschlüsseln.
- Sie können das Schlüsselmanagement vom Gesamtmanagementmodell des Dienstes trennen.
- Sie können Service und Schlüsselstandort über verschiedene Regionen hinweg definieren.
Nachteile
- Sie haben volle Verantwortung für Schlüsselspeicher, Sicherheit, Leistung und Verfügbarkeit.
- Sie haben volle Verantwortung für die Schlüsselzugriffsverwaltung.
- Sie haben volle Verantwortung für die Schlüssellebenszyklusverwaltung.
- Es entstehen erhebliche Einrichtungs-, Konfigurations- und fortlaufende Wartungskosten.
- Das Modell erhöht die Abhängigkeit von der Netzwerkverfügbarkeit zwischen dem Kundenrechenzentrum und den Azure-Rechenzentren.