Freigeben über

Verschlüsselung mit kundenseitig verwalteten Schlüsseln in Microsoft Cloud for Sovereignty

  • Artikel

Kunden, die eine Microsoft Cloud for Sovereignty-Implementierung planen, müssen möglicherweise Datenverschlüsselungsfunktionen verwenden, um die Anforderungen an die Datensouveränität zu erfüllen. Kundschaft mit strengen Anforderungen an die Datensouveränität sollten Pläne zur Implementierung der Schlüsselverwaltung in der Cloud entwickeln. Dieser Artikel ist eine Anleitung für Cloud-Architektur-Fachkräfte, Besitzende kryptografischer Systeme und andere technische Entscheidende zur Entwicklung eines Plans für die Implementierung der Verschlüsselung auf Plattformebene in Azure. Die Planung der Verschlüsselung auf Plattformebene umfasst normalerweise die Ermittlung der Anforderungen an die Schlüsselverwaltung, die Auswahl der Technologie und die Auswahl von Designs und Konfigurationsoptionen für die zu verwendenden Azure-Dienste. Dieser Prozess umfasst technische Entscheidungen in drei Bereichen:

  • Anforderungen an die Schlüsselverwaltung festlegen: Was muss Ihre Organisation tun, um sensible Kundendaten und sensibles kryptografisches Material zu schützen?
  • Wählen Sie Datenverschlüsselungsfunktionen zum Schutz von Kundendaten aus: Wie, wo und wann sollten Sie Kundendaten in Azure verschlüsseln?
  • Schlüsselverwaltungslösungen zum Schutz von Kundenschlüsseln auswählen: Welchen Schlüsselspeicher sollten Sie zum Schutz von Datenschlüsseln verwenden, die zum Verschlüsseln von Kundendaten in Azure verwendet werden?

Anforderungen an die Schlüsselverwaltung festlegen

Die Anforderungen an die Schlüsselverwaltung können technische Anforderungen an die verwendeten kryptografischen Dienste sowie betriebliche Anforderungen in Bezug auf Leistung, Sicherheit und Souveränität umfassen. Als Ausgangspunkt für Entscheidungen darüber, wann und wie Daten in Azure-Workloads verschlüsselt werden sollen, empfehlen wir das Datenklassifizierungssystem der jeweiligen Organisation. Durch die Ausrichtung der Verschlüsselungsanforderungen an Datenklassifizierungen und nicht an bestimmten Systemen oder Lösungen sind Organisationen bei der Auswahl der optimalen Verschlüsselungsstufe während der Planung der Workload-Migration flexibler.

Wenn die Verschlüsselungsanforderungen auf der Datenklassifizierung basieren, kann außerdem ein mehrstufiger Ansatz genutzt werden, bei dem Workloads weniger kritische von einfacheren Lösungen profitieren können, während die komplexesten Konfigurationen Workloads mit einem höheren Grad an inhärentem Risiko vorbehalten bleiben. Ein Beispiel für diesen Ansatz wäre, die Verwendung von von Microsoft verwalteten Schlüsseln zum Verschlüsseln von Speicherkonten für Entwicklungsumgebungen zuzulassen und gleichzeitig zu verlangen, dass Produktionsspeicherkonten kundenseitig verwaltete Schlüssel verwenden.

Sobald eine Organisation genau weiß, wie sich ihre Verschlüsselungsanforderungen auf ihre Datenklassifizierungen auswirken, kann sie mit der Funktionsauswahl für die Azure-Dienste beginnen, die sie nutzen möchte. Einige dieser Features funktionieren möglicherweise anders als ähnliche lokale Systeme. Daher sollten Organisationen sich mit der Funktionsweise der Verschlüsselung in Azure vertraut machen und die Empfehlungen und Best Practices für die Entwicklung von Verschlüsselungslösungen zu lesen. Die folgenden Artikel bieten zusätzliche Perspektiven auf einige der technischen Entscheidungen, die getroffen werden müssen, und können ein nützlicher Ausgangspunkt für den Beginn eines Gesprächs über die Ziele einer Organisation im Hinblick auf die Schlüsselverwaltung in der Cloud sein.

Datenverschlüsselungsfeatures auswählen

Viele Azure-Dienste ermöglichen die Verschlüsselung mithilfe von Schlüsseln, die vollständig von Azure generiert, gespeichert und verwaltet werden, ohne dass eine Kundeninteraktion erforderlich ist. Diese plattformseitig verwalteten Schlüssel können Organisationen dabei helfen, Verschlüsselung mit geringem betrieblichen Mehraufwand zu implementieren. Allerdings muss Kundschaft mit strengen Anforderungen an die Datensouveränität möglicherweise bestimmte Plattformverschlüsselungsfeatures auswählen, um vertrauliche Daten im Ruhezustand in einem bestimmten Azure-Dienst zu schützen.

Für hochsensible Daten erlauben viele häufig verwendete Azure-Dienste Kundschaft die Implementierung einer Mehrfachverschlüsselung mithilfe von kundenseitig verwalteten Schlüsseln (CMK). Durch die Implementierung kundenseitig verwalteter Schlüssel in Azure-Diensten kann Kundschaft die in diesen Diensten gespeicherten Daten vor unbefugtem Zugriff schützen.

Die Implementierung kundenseitig verwalteter Schlüssel in Azure kann die Kosten und die Komplexität eines Workloads steigern. Daher wird Organisationen empfohlen, für jeden Workload und jede Datenklassifizierungsebene genau zu prüfen, ob dieses Feature notwendig ist. Kundenseitig verwaltete Schlüssel nur für die Workloads und Datentypen, die sie benötigen, zu implementieren, kann dazu beitragen, den betrieblichen Mehraufwand für Workloads zu reduzieren, die keine sensiblen Daten verarbeiten.

Wenn kundenseitig verwaltete Schlüssel erforderlich sind, müssen diese für den jeweiligen Azure-Dienst konfiguriert werden. Organisationen können dazu beitragen, die Bereitstellungs- oder Migrationsplanung zu rationalisieren, indem sie organisationsweite Standards und wiederholbare Entwurfsmuster für die Implementierung dieser Features festlegen. Die folgenden Artikel enthalten weitere Informationen zur Konfiguration der Verschlüsselung ruhender Daten in Azure:

Erfahren Sie, wie Sie häufig verwendete Azure-Dienste konfigurieren, um ruhende Daten mit kundenseitig verwalteten Schlüsseln zu verschlüsseln:

Schlüsselverwaltungslösungen auswählen

Während Features wie die Mehrfachverschlüsselung mit kundenseitig verwalteten Schlüsseln dazu beitragen können, Kundendaten zu schützen, die in Azure-Diensten verwaltet werden, tragen cloudbasierte Schlüsselverwaltungslösungen zum Schutz der Schlüssel und anderer kryptografischer Materialien bei, die zum Verschlüsseln sensibler Daten verwendet werden. Kundschaft mit strengen Anforderungen an die Datensouveränität sollten eine geeignete Schlüsselverwaltungslösung auswählen , die auf ihren Sicherheitsanforderungen und dem Risikoprofil ihrer Workloads basiert.

Workloads, die vertrauliche Daten verarbeiten, können von der zusätzlichen Sicherheit profitieren, die Lösungen wie verwaltete HSM von Azure bieten. Dazu gehören FIPS-140-2 Level-3-validierte Hardware-Sicherheitsmodule, die über zusätzliche Sicherheitskontrollen zum Schutz von gespeicherten kryptografischen Materials verfügen.

Die folgenden Artikel bieten Anleitungen, anhand derer Kundschaft einen geeigneten Schlüsselspeicher für ihre identifizierten Szenarios auswählen kann. Außerdem enthalten sie Informationen darüber, wie Microsoft kryptografische Dienste verwaltet, die Kundschaft im Rahmen ihrer Verschlüsselungslösung verwendet.

Betriebsmodelle für die Schlüsselverwaltung

Azure Key Vault implementiert die rollenbasierte Zugriffskontrolle auf unterschiedliche Weise, je nachdem, ob Sie die Standard-/Premium-Stufe von Azure Key Vault oder verwaltetes HSM von Azure Key Vault verwenden. Diese Unterschiede bei der Zugriffssteuerung können Auswirkungen auf die Art und Weise haben, wie eine Organisation diese Funktionen nutzt. In diesem Abschnitt werden diese Unterschiede beschrieben und es wird erläutert, wie sie sich auf die Gestaltung der Betriebsabläufe eines Unternehmens für die Cloud-Schlüsselverwaltung auswirken können.

Compliance-Einschränkungen für die FIPS-140 Level-3-Validierung

Die FIPS-140 Level-3-Validierung erfordert eine identitätsbasierte Bedieneridentifizierung. Diese Sicherheitsvorkehrungen werden in der zugrunde liegenden HSM-Hardware bereitgestellt und validiert, die die Key Vault-Dienste in Azure unterstützt. Daher sind die RBAC-Funktionen in Azure Key Vault von den RBAC-Funktionen der zugrunde liegenden Hardware abhängig.

Das verwaltete HSM von Azure Key Vault nutzt die lokalen RBAC-Zuweisungen, die auf Hardware-Ebene implementiert werden und Rollenzuweisungen im Rahmen der Sicherheitsdomäne (z. B. HSM-weit) oder auf Schlüsselbasis ermöglichen. Dies bedeutet, dass für die Schlüsselerstellung Administratorberechtigungen für die gesamte Sicherheitsdomäne erforderlich sind, da für einen Schlüssel, der noch nicht vorhanden ist, keine Berechtigungen zugewiesen werden können. Die Auswirkung dieses Entwurfs besteht darin, dass jeder, der einen Schlüssel in einer mHSM-Instanz speichern muss, entweder über vollständige Berechtigungen für alle in dieser Sicherheitsdomäne gespeicherten Schlüssel verfügen oder Schlüssel von einem zentralen Team anfordern muss, das über die erforderlichen Berechtigungen für die Sicherheitsdomäne verfügt. Dies stellt eine Abweichung von den Richtlinien für Azure Key Vault dar, die die Erstellung separater Schlüsseltresore für jede Anwendung empfehlen.

Schlüsselverwaltungsvorgänge im verwalteten HSM von Azure Key Vault

Um Betriebsprozesse für die Schlüsselverwaltung zu entwickeln, sollten Kunden feststellen, ob sie verwaltetes HSM von Azure Key Vault als Teil ihrer Lösungsarchitektur benötigen. Organisationen, die verwaltete HSM verwenden möchten, sollten sich zunächst mit den Modellen der Zugriffssteuerung vertraut machen, die für Verwaltungs- und kryptografische Vorgänge verwendet werden, und verstehen, wie die rollenbasierte Zugriffssteuerung zugewiesen wird.

Erfahren Sie mehr über die Zugriffssteuerung im verwalteten HSM:

Organisationen, die die Verwendung von Azure Key Vault HSM planen, sollten die Liste der integrierten RBAC-Rollen und zulässigen Vorgänge für verwaltetes HSM prüfen und insbesondere die folgenden Betriebsszenarien berücksichtigen:

  • Erstellen eines neuen Schlüssels im verwalteten HSM
  • Verwaltungsvorgänge für einen vorhandenen Schlüssel mithilfe der Steuerebene, z. B. Schlüsselaktualisierungen oder Schlüsselrotation
  • Datenebenennutzung eines vorhandenen Schlüssels durch eine Anwendung oder einen Dienst

Derzeit besteht die einzige Möglichkeit, Berechtigungen zum Erstellen eines neuen Schlüssels zuzuweisen, darin, eine Rolle wie Crypto User zuzuweisen, die auch andere Berechtigungen wie Schlüsselrotation und -löschung umfasst. Wenn einem Mitglied des Anwendungsteams die erforderlichen Berechtigungen zum Erstellen eigener Schlüssel im verwalteten HSM erteilt werden, kann dies daher wahrscheinlich einen Verstoß gegen das Prinzip der geringsten Berechtigungen darstellen, da dieser Benutzer auch über Administratorberechtigungen für alle Schlüssel im HSM verfügt. Dieses Problem lässt sich durch die Einführung eines zentralen Teams mit erweiterten Berechtigungen lösen, das Anforderungen zur Schlüsselerstellung erleichtern kann. Alternativ können Sie eine Automatisierung einführen, die Anforderungen zur Schlüsselerstellung durch IT-Service-Management-Prozesse erleichtert, die eine REST-API für verwaltetes HSM nutzen.

Zugehöriger Inhalt