Datenverschlüsselungsmodelle
Damit Sie verstehen, wie die verschiedenen Ressourcenanbieter in Azure die ruhende Verschlüsselung implementieren, ist es wichtig, dass Sie die unterschiedlichen Verschlüsselungsmodelle und deren Vor- und Nachteile kennen. Diese Definitionen sind in allen Ressourcenanbietern in Azure gleich, um die gleiche Sprache und Taxonomie zu gewährleisten.
Es gibt drei Szenarios für die serverseitige Verschlüsselung:
Serverseitige Verschlüsselung mit dienstseitig verwalteten Schlüsseln
- Azure-Ressourcenanbieter führen die Verschlüsselungs- und Entschlüsselungsvorgänge durch
- Microsoft verwaltet die Schlüssel
- Vollständige Cloud-Funktionen
Serverseitige Verschlüsselung mit vom Kunden verwalteten Schlüsseln in Azure Key Vault
- Azure-Ressourcenanbieter führen die Verschlüsselungs- und Entschlüsselungsvorgänge durch
- Der Kunde steuert Schlüssel per Azure Key Vault
- Vollständige Cloud-Funktionen
Serverseitige Verschlüsselung mit vom Kunden verwalteten Schlüsseln auf kundengesteuerter Hardware
- Azure-Ressourcenanbieter führen die Verschlüsselungs- und Entschlüsselungsvorgänge durch
- Der Kunde steuert die Schlüssel auf kundengesteuerter Hardware
- Vollständige Cloud-Funktionen
Als Modelle für die serverseitige Verschlüsselung werden Verschlüsselungen bezeichnet, die vom Azure-Dienst durchgeführt werden. In diesem Modell führt der Ressourcenanbieter den Ver- und Entschlüsselungsvorgang durch. Azure Storage erhält z.B. Daten in Nur-Text-Vorgängen und führt die Ver- und Entschlüsselung intern durch. Der Ressourcenanbieter verwendet möglicherweise Verschlüsselungsschlüssel, die je nach Konfiguration von Microsoft oder dem Kunden verwaltet werden.
Jede serverseitige Verschlüsselung in ruhenden Modellen impliziert unterschiedliche Merkmale der Schlüsselverwaltung, einschließlich des Speicherorts und der Speicherung von Verschlüsselungsschlüsseln sowie der Zugriffsmodelle und der Schlüsselrotationsverfahren.
Berücksichtigen Sie bei der clientseitigen Verschlüsselung Folgendes:
- Azure-Dienste können entschlüsselte Daten nicht erkennen
- Die Kunden bewahren die Schlüssel lokal auf (oder in anderen sicheren Speichern). Schlüssel sind für Azure-Dienste nicht verfügbar
- Reduzierte Cloud-Funktionen
Die unterstützten Verschlüsselungsmodelle in Azure können in zwei Hauptgruppen unterteilt werden: „Clientverschlüsselung“ und „serverseitige Verschlüsselung“ (wie bereits erwähnt). Unabhängig vom Verschlüsselungsmodell für ruhende Daten wird für Azure-Dienste immer der Einsatz eines sicheren Datentransports wie TLS oder HTTPS empfohlen. Deshalb sollte das Datentransportprotokoll die Verschlüsselung während des Datentransport behandeln und sollte kein ausschlaggebender Faktor bei der Entscheidung für oder gegen ein Verschlüsselungsmodell für ruhende Daten sein.
Clientverschlüsselungsmodell
Als Clientverschlüsselungsmodell wird eine Verschlüsselung bezeichnet, die außerhalb des Ressourcenanbieters oder außerhalb von Azure von der Dienst- oder der aufrufenden Anwendung durchgeführt wird. Die Verschlüsselung kann von der Dienstanwendung in Azure durchgeführt werden oder von einer Anwendung, die im Rechenzentrum des Kunden ausgeführt wird. In beiden Fällen erhält der Azure-Ressourcenanbieter einen verschlüsselten Datenblob, ohne die Daten entschlüsseln oder auf die Verschlüsselungsschlüssel zugreifen zu können, wenn Sie dieses Verschlüsselungsmodell einsetzen. In diesem Modell erfolgt die Schlüsselverwaltung über den aufrufenden Dienst bzw. die aufrufende Anwendung und ist für den Azure-Dienst nicht transparent.
Serverseitige Verschlüsselung mit vom Dienst verwalteten Schlüsseln
Für viele Kunden ist die wichtigste Anforderung, sicherzustellen, dass die Daten immer dann verschlüsselt sind, wenn sie ruhen. Dieses Modell ist durch die serverseitige Verschlüsselung mit vom Dienst verwalteten Schlüsseln möglich, da diese es Kunden ermöglicht, die spezifische Ressource (Storage-Konto, SQL-Datenbank usw.) für die Verschlüsselung zu kennzeichnen und alle Schlüsselverwaltungsaspekte wie die Schlüsselausstellung, -rotation und -sicherung Microsoft zu überlassen. Die meisten Azure-Dienste, die die Verschlüsselung ruhender Daten unterstützen, unterstützen üblicherweise auch dieses Modell, bei dem die Verwaltung der Verschlüsselungsschlüssel an Azure übergeben wird. Der Azure-Ressourcenanbieter erstellt die Schlüssel, speichert sie an einem sicheren Speicherort und ruft sie bei Bedarf ab. Dieser Dienst hat Vollzugriff auf die Schlüssel und steuert die Verwaltung der Lebensdauer der Anmeldeinformationen vollständig.
Durch die serverseitige Verschlüsselung mit vom Dienst verwalteten Schlüsseln wurde deshalb schnell auf die Anforderung reagiert, eine Verschlüsselung ruhender Daten mit geringem Mehraufwand für den Kunden bereitzustellen. Wenn sie zur Verfügung steht, kann der Kunde das Azure-Portal für das Zielabonnement und den Zielressourcenanbieter öffnen und ein Kontrollkästchen aktivieren, das angibt, dass die Daten verschlüsselt werden sollen. Bei einigen Ressourcen-Managern ist die serverseitige Verschlüsselungen mit vom Dienst verwalteten Schlüssel standardmäßig aktiviert.
Die serverseitige Verschlüsselung mit von Microsoft verwalteten Schlüsseln impliziert nicht, dass der Dienst über Vollzugriff zum Speichern und Verwalten der Schlüssel verfügt. Während einige Kunden möglicherweise die Schlüssel verwalten möchten, weil sie das Gefühl haben, dass sie so eine höhere Sicherheit erreichen können, sollten die Kosten und das Risiko, die mit einer kundenspezifischen Schlüsselspeicherlösung verbunden sind, bei der Bewertung eines Modells berücksichtigt werden. In vielen Fällen kann eine Organisation zu dem Schluss kommen, dass Ressourceneinschränkungen oder die Risiken einer lokalen Lösung höher sind als das Risiko der Cloudverwaltung der Schlüssel für die Verschlüsselung ruhender Daten. 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 die serverseitige Verschlüsselung mit vom Dienst verwalteten Schlüsseln verwendet wird, werden die Erstellung und Speicherung von Schlüsseln sowie der Dienstzugriff vollständig vom Dienst verwaltet. Üblicherweise speichert der grundlegende Azure-Ressourcenanbieter die DEKs in einem Speicher, der sich in der Nähe der Daten befindet und schnell verfügbar und zugreifbar ist, während die KEKs in einem sicheren internen Speicher gespeichert werden.
Vorteile
- Einfache Einrichtung
- Microsoft verwaltet die Rotation, Sicherung und Redundanz der Schlüssel.
- Der Kunde muss die Kosten nicht tragen, die mit einer Implementierung oder dem Risiko eines kundenspezifischen Schlüsselverwaltungsschema in Verbindung stehen.
Nachteile
- Keine Kundensteuerung der Verschlüsselungsschlüssel (Schlüsselspezifizierung, Lebensdauern, Widerruf usw.)
- Die Schlüsselverwaltung kann nicht vom allgemeinen Verwaltungsmodell für den Dienst getrennt werden
Serverseitige Verschlüsselung mit vom Kunden verwalteten Schlüsseln in Azure Key Vault und Azure Managed HSM
In Szenarien, in denen es erforderlich ist, die ruhenden Daten zu verschlüsseln und die Verschlüsselungsschlüssel zu steuern, können Kunden die serverseitige Verschlüsselung mit vom Kunden verwalteten Schlüsseln in Key Vault verwenden. Einige Diensten speichern möglicherweise nur den Stamm-KEK in Azure Key Vault und speichern den verschlüsselten DEK in einem internen Speicherort, der sich näher an den Daten befindet. In diesem Szenario können Kunden Ihre eigenen Schlüssel in Key Vault mitbringen (BYOK: Bring Your Own Key) oder neue Schlüssel generieren und diese verwenden, um die gewünschten Ressourcen zu verschlüsseln. Während der Ressourcenanbieter die Ver- und Entschlüsselungsvorgänge durchführt, verwendet er den konfigurierten KEK als Stammschlüssel für alle Verschlüsselungsvorgänge.
Der Verlust von KEKs bedeutet, dass Daten verloren gehen. Aus diesem Grund sollten Schlüssel nicht gelöscht werden. Schlüssel sollten immer dann gesichert werden, wenn sie erstellt oder gedreht werden. Der Schutz vor vorläufigem und endgültigem Löschen muss für jeden Tresor aktiviert sein, der Schlüsselverschlüsselungsschlüssel enthält, um Schutz vor versehentlichem oder böswilligem Löschen von Kryptografien zu bieten. Anstatt einen Schlüssel zu löschen, wird empfohlen, die Einstellungen des Schlüsselverschlüsselungsschlüssel von „enabled“ (aktiviert) auf „false“ festzulegen. Verwenden Sie Zugriffssteuerungen, um den Zugriff auf einzelne Benutzer oder Dienste in Azure Key Vault oder verwaltetem HSM zu widerrufen.
Hinweis
Eine Liste der Dienste, die vom Kunden verwaltete Schlüssel in Azure Key Vault und Azure Managed HSM unterstützen, finden Sie unter Dienste, die CMKs in Azure Key Vault und Azure Managed HSM unterstützen.
Schlüsselzugriff
Beim Modell der serverseitigen Verschlüsselung mit vom Kunden verwalteten Schlüsseln in Azure Key Vault greift der Dienst auf die Schlüssel zu, um nach Bedarf Ver- und Entschlüsselungen durchzuführen. Schlüssel für die Verschlüsselung ruhender Daten werden einem Dienst über eine Richtlinie zur Zugriffssteuerung verfügbar gemacht. Diese Richtlinie gewährt dem Dienst Identitätszugriff, um Schlüssel zu erhalten. Ein Azure-Dienst, der für ein verknüpftes Abonnement ausgeführt wird, kann mit einer Identität in diesem Abonnement konfiguriert werden. 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. Dieses Token kann dann Key Vault gezeigt werden, um einen Schlüssel zu erhalten, auf den es Zugriff erhalten hat.
Für Vorgänge mit Verschlüsselungsschlüsseln kann einer Dienstidentität Zugriff auf jeden der folgenden Vorgänge gewährt werden: decrypt, encrypt, unwrapKey, wrapKey, verify, sign, get, list, update, create, import, delete, backup, and restore.
Um einen Schlüssel zum Ver- oder Entschlüsseln von ruhenden Daten abzurufen, muss die Dienstidentität, als die die Dienstinstanz des Ressourcen-Managers ausgeführt wird, „UnwrapKey“ (zum Abrufen den Schlüssels für die Entschlüsselung) und „WrapKey“ (um einen Schlüssel beim Erstellen eines neuen Schlüssels in den Schlüsseltresor einzufügen) aufweisen.
Hinweis
Weitere Informationen zur Authentifizierung bei Key Vault finden Sie auf der Seite „Sichern Ihres Schlüsseltresors“ in der Dokumentation zu Azure Key Vault.
Vorteile
- Vollständige Steuerung der verwendeten Schlüssel: Verschlüsselungsschlüssel werden im Key Vault des Kunden unter dessen Kontrolle verwaltet.
- Die Fähigkeit, mehrere Dienste für einen Master zu verschlüsseln
- Die Schlüsselverwaltung kann vom allgemeinen Verwaltungsmodell für den Dienst getrennt werden.
- Der Dienst- und Schlüsselspeicherort kann regionsübergreifend definiert werden.
Nachteile
- Der Kunde trägt die volle Verantwortung für die Schlüsselzugriffsverwaltung
- Der Kunde trägt die volle Verantwortung für die Lebensdauerverwaltung des Schlüssels
- Zusätzlicher Aufwand für die Einrichtung und die Konfiguration
Serverseitige Verschlüsselung mit vom Kunden verwalteten Schlüsseln auf kundengesteuerter Hardware
Einige Azure-Dienste ermöglichen das Schlüsselverwaltungsmodell HYOK (Host Your Own Key, Eigenen Schlüssel hosten). Dieser Verwaltungsmodus ist in Szenarios nützlich, in denen es erforderlich ist, die ruhenden Daten zu verschlüsseln und die Schlüssel in einem geschützten Repository außerhalb der Kontrolle von Microsoft zu verwalten. In diesem Modell muss der Dienst den Schlüssel von einer externen Site verwenden, um den Datenverschlüsselungsschlüssel (DEK) zu entschlüsseln. Leistungs- und Verfügbarkeitsgarantien werden beeinträchtigt, und die Konfiguration ist komplexer. Zusätzlich ähneln die allgemeinen Sicherheitsgarantien für dieses Modell denen für eine Umgebung, in der die Schlüssel vom Kunden in Azure Key Vault verwaltet werden, weil der Dienst bei Verschlüsselungs- und Entschlüsselungsvorgängen Zugriff auf den DEK hat. Daraus folgt, dass das Modell für die meisten Organisationen ungeeignet ist, es sei denn, sie haben besondere Schlüsselverwaltungsanforderungen. Aufgrund dieser Einschränkungen unterstützen die meisten Azure-Dienste keine serverseitige Verschlüsselung mit kundenseitig verwalteten Schlüsseln auf kundengesteuerter Hardware. Einer von zwei Schlüsseln in der Verschlüsselung mit doppeltem Schlüssel (DKE) folgt diesem Modell.
Schlüsselzugriff
Wenn serverseitige Verschlüsselung mit kundenseitig verwalteten Schlüsseln in kundengesteuerter Hardware verwendet wird, werden die Schlüsselverschlüsselungsschlüssel auf einem vom Kunden konfigurierten System verwaltet. Azure-Dienste, die dieses Modell unterstützen, bieten eine Möglichkeit, eine sichere Verbindung mit einem von Kunden bereitgestellten Schlüsselspeicher herzustellen.
Vorteile
- Volle Steuerung des verwendeten Stammschlüssels: Verschlüsselungsschlüssel werden von einem vom Kunden bereitgestellten Speicher verwaltet.
- Die Fähigkeit, mehrere Dienste für einen Master zu verschlüsseln
- Die Schlüsselverwaltung kann vom allgemeinen Verwaltungsmodell für den Dienst getrennt werden.
- Der Dienst- und Schlüsselspeicherort kann regionsübergreifend definiert werden.
Nachteile
- Volle Verantwortung für den Speicher, die Sicherheit, Leistung und Verfügbarkeit der Schlüssel
- Volle Verantwortung für die Schlüsselzugriffsverwaltung
- Volle Verantwortung für die Lebensdauerverwaltung des Schlüssels
- Erhebliche Kosten für die Einrichtung, Konfiguration und fortlaufende Wartung
- Verstärkte Abhängigkeit von der Netzwerkverfügbarkeit zwischen den Rechenzentrum des Kunden und den Azure-Rechenzentren