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.
Jedes Modell zur serverseitigen Verschlüsselung impliziert eindeutige Merkmale für die Schlüsselverwaltung. Dazu zählt u.a., wo und wie Verschlüsselungsschlüssel erstellt und gespeichert werden, sowie die Zugriffsmodelle und die Schlüsselrotationsprozeduren.
Ziehen Sie für die clientseitige Verschlüsselung folgendes in Betracht:
- 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. Dies bedeutet, dass der Dienst Vollzugriff auf die Schlüssel hat, und dass er die Verwaltung der Lebensdauer der Anmeldeinformationen vollständig steuert.
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
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.
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 das es Zugriff 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
Unterstützende Dienste
Die Azure-Dienste, die die einzelnen Verschlüsselungsmodelle unterstützen:
| Produkt, Feature oder Dienst | Serverseitig mit vom Dienst verwaltetem Schlüssel | Serverseitig mit kundenseitig verwaltetem Schlüssel | Clientseitig mit vom Client verwaltetem Schlüssel |
|---|---|---|---|
| KI und Machine Learning | |||
| Azure KI Cognitive Search | Ja | Ja | - |
| Azure KI Services | Ja | Ja, einschließlich verwaltetem HSM | - |
| Azure Machine Learning | Ja | Ja | - |
| Content Moderator | Ja | Ja, einschließlich verwaltetem HSM | - |
| Gesicht | Ja | Ja, einschließlich verwaltetem HSM | - |
| Language Understanding | Ja | Ja, einschließlich verwaltetem HSM | - |
| Azure OpenAI | Ja | Ja, einschließlich verwaltetem HSM | - |
| Personalisierung | Ja | Ja, einschließlich verwaltetem HSM | - |
| QnA Maker | Ja | Ja, einschließlich verwaltetem HSM | - |
| Spracherkennungsdienste | Ja | Ja, einschließlich verwaltetem HSM | - |
| Textübersetzung | Ja | Ja, einschließlich verwaltetem HSM | - |
| Power BI | Ja | Ja, RSA 4.096 Bit | - |
| Analyse | |||
| Azure Stream Analytics | Ja | Ja**, einschließlich verwaltetem HSM | - |
| Event Hubs | Ja | Ja | - |
| Functions | Ja | Ja | - |
| Azure Analysis Services | Ja | - | - |
| Azure Data Catalog | Ja | - | - |
| Azure HDInsight | Ja | Ja | - |
| Azure Monitor Application Insights | Ja | Ja | - |
| Azure Monitor Log Analytics | Ja | Ja, einschließlich verwaltetem HSM | - |
| Azure-Daten-Explorer | Ja | Ja | - |
| Azure Data Factory | Ja | Ja, einschließlich verwaltetem HSM | - |
| Azure Data Lake Store | Ja | Ja, RSA 2048 Bit | - |
| Container | |||
| Azure Kubernetes Service | Ja | Ja, einschließlich verwaltetem HSM | - |
| Container Instances | Ja | Ja | - |
| Containerregistrierung | Ja | Ja | - |
| Compute | |||
| Virtual Machines | Ja | Ja, einschließlich verwaltetem HSM | - |
| VM-Skalierungsgruppe | Ja | Ja, einschließlich verwaltetem HSM | - |
| SAP HANA | Ja | Ja | - |
| App Service | Ja | Ja**, einschließlich verwaltetem HSM | - |
| Automation | Ja | Ja | - |
| Azure-Funktionen | Ja | Ja**, einschließlich verwaltetem HSM | - |
| Azure-Portal | Ja | Ja**, einschließlich verwaltetem HSM | - |
| Azure VMware Solution | Ja | Ja, einschließlich verwaltetem HSM | - |
| Logic Apps | Ja | Ja | - |
| Verwaltete Azure-Anwendungen | Ja | Ja**, einschließlich verwaltetem HSM | - |
| Service Bus | Ja | Ja | - |
| Site Recovery | Ja | Ja | - |
| Datenbanken | |||
| SQL Server auf virtuellen Computern | Ja | Ja | Ja |
| Azure SQL-Datenbank | Ja | Ja, RSA 3072 Bit, einschließlich verwaltetem HSM | Ja |
| Verwaltete Azure SQL-Instanz | Ja | Ja, RSA 3072 Bit, einschließlich verwaltetem HSM | Ja |
| Azure SQL-Datenbank for MariaDB | Ja | - | - |
| Azure SQL-Datenbank for MySQL | Ja | Ja | - |
| Azure SQL-Datenbank for PostgreSQL | Ja | Ja, einschließlich verwaltetem HSM | - |
| Azure Synapse Analytics (nur dedizierte SQL-Pool (–früher SQL DW) | Ja | Ja, RSA 3072 Bit, einschließlich verwaltetem HSM | - |
| SQL Server Stretch Database | Ja | Ja, RSA 3072 Bit | Ja |
| Table Storage | Ja | Ja | Ja |
| Azure Cosmos DB | Ja (weitere Informationen) | Ja, einschließlich verwaltetem HSM (Weitere Informationen finden Sie hier und hier.) | - |
| Azure Databricks | Ja | Ja, einschließlich verwaltetem HSM | - |
| Azure Database Migration Service | Ja | Nicht zutreffend* | - |
| Identität | |||
| Microsoft Entra-ID | Ja | - | - |
| Microsoft Entra Domain Services | Ja | Ja | - |
| Integration | |||
| Service Bus | Ja | Ja | - |
| Event Grid | Ja | - | - |
| API Management | Ja | - | - |
| IoT-Dienste | |||
| IoT Hub | Ja | Ja | Ja |
| IoT Hub Device Provisioning | Ja | Ja | - |
| Verwaltung und Governance | |||
| Von Azure verwaltetes Grafana | Ja | - | – |
| Azure Site Recovery | Ja | - | - |
| Azure Migrate | Ja | Ja | - |
| Medien | |||
| Media Services | Ja | Ja | Ja |
| Security | |||
| Microsoft Defender für IoT | Ja | Ja | - |
| Microsoft Sentinel | Ja | Ja, einschließlich verwaltetem HSM | - |
| Storage | |||
| Blob Storage | Ja | Ja, einschließlich verwaltetem HSM | Ja |
| Blob Storage Premium | Ja | Ja, einschließlich verwaltetem HSM | Ja |
| Disk Storage | Ja | Ja, einschließlich verwaltetem HSM | - |
| Disk Storage Ultra | Ja | Ja, einschließlich verwaltetem HSM | - |
| Speicher für verwaltete Datenträger | Ja | Ja, einschließlich verwaltetem HSM | - |
| File Storage | Ja | Ja, einschließlich verwaltetem HSM | - |
| Storage Premium für Dateien | Ja | Ja, einschließlich verwaltetem HSM | - |
| Dateisynchronisierung | Ja | Ja, einschließlich verwaltetem HSM | - |
| Queue Storage | Ja | Ja, einschließlich verwaltetem HSM | Ja |
| Data Lake Storage Gen2 | Ja | Ja, einschließlich verwaltetem HSM | Ja |
| Avere vFXT | Ja | - | - |
| Azure Cache for Redis | Ja | Nicht zutreffend* | - |
| Azure NetApp Files | Ja | Ja | Ja |
| Archivspeicher | Ja | Ja | - |
| StorSimple | Ja | Ja | Ja |
| Azure Backup | Ja | Ja, einschließlich verwaltetem HSM | Ja |
| Data Box | Ja | - | Ja |
| Data Box Edge | Ja | Ja | - |
| Andere | |||
| Azure Data Manager for Energy Preview | Ja | - | Ja |
* Dieser Dienst speichert keine Daten. Vorübergehende Caches werden ggf. mit einem Microsoft-Schlüssel verschlüsselt.
** Dieser Dienst unterstützt das Speichern von Daten in Ihrem eigenen Schlüsseltresor, Speicherkonto oder einem anderen Dienst zur persistenten Datenspeicherung, der bereits die serverseitige Verschlüsselung mit kundenseitig verwaltetem Schlüssel unterstützt.
Nächste Schritte
- Informieren Sie sich über die Verwendung der Verschlüsselung in Azure.
- Lesen Sie mehr dazu, wie mithilfe der doppelten Verschlüsselung Bedrohungen in Azure minimiert werden, die mit der Datenverschlüsselung einhergehen.