Empfohlene Vorgehensweisen für die Verwendung von CMEKs

Auf dieser Seite finden Sie empfohlene Vorgehensweisen zum Konfigurieren der Verschlüsselung ruhender Daten mit vom Kunden verwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEKs) für Ihre Cloud de Confiance -Ressourcen. Dieser Leitfaden richtet sich an Cloud-Architekten und Sicherheitsteams. Er enthält Empfehlungen und Entscheidungen, die Sie beim Entwerfen Ihrer CMEK-Architektur treffen müssen.

In dieser Anleitung wird davon ausgegangen, dass Sie bereits mit dem Cloud Key Management Service (Cloud KMS) und kundenverwalteten Verschlüsselungsschlüsseln vertraut sind.

Auswählen, wo CMEK verwendet werden soll

Google empfiehlt die Verwendung von kundenverwalteten Verschlüsselungsschlüsseln, wenn Sie eine kryptografische Grenze um Ihre Daten oder die Daten Ihrer Kunden in der Cloud ziehen möchten. Weitere Informationen finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK).

Sie können CMEKs in kompatiblen Diensten verwenden, um die folgenden Ziele zu erreichen:

• Sie sind Eigentümer Ihrer Verschlüsselungsschlüssel.

• Sie haben die Kontrolle über Ihre Verschlüsselungsschlüssel und können sie verwalten, einschließlich der Auswahl des Speicherorts, des Schutzlevels, der Erstellung, der Zugriffssteuerung, der Rotation, der Verwendung und der Vernichtung.

• Schlüsselmaterial in Cloud KMS generieren oder Schlüsselmaterial importieren, das außerhalb von Cloud de Confianceverwaltet wird.

• Legen Sie eine Richtlinie fest, wo Ihre Schlüssel verwendet werden müssen.

• Sie können Daten, die durch Ihre Schlüssel geschützt sind, im Falle eines Offboardings oder zur Behebung von Sicherheitsereignissen selektiv löschen (kryptografisches Löschen).

• Erstellen und verwenden Sie Schlüssel, die für einen Kunden eindeutig sind, um eine kryptografische Grenze um Ihre Daten zu ziehen.

• Administrator- und Datenzugriff auf Verschlüsselungsschlüssel protokollieren

• Sie müssen aktuelle oder zukünftige Vorschriften einhalten, die eines dieser Zielvorhaben erfordern.

Google empfiehlt außerdem, Compliance-Frameworks zu berücksichtigen, die für Ihre geschäftlichen Anforderungen gelten. Für verschiedene Compliance-Frameworks gelten unterschiedliche Anforderungen an die Verschlüsselung und das Schlüsselmanagement. Ein Compliance-Framework beschreibt in der Regel die allgemeinen Grundsätze und Ziele der Verwaltung von Verschlüsselungsschlüsseln, schreibt aber nicht vor, welches bestimmte Produkt oder welche Konfiguration die Compliance erreicht. Es liegt in Ihrer Verantwortung, die Anforderungen Ihres Compliance-Frameworks zu verstehen und zu wissen, wie Ihre Kontrollen, einschließlich der Schlüsselverwaltung, Ihnen helfen können, diese Anforderungen zu erfüllen.

Informationen dazu, wie Cloud de Confiance Dienste helfen können, die Anforderungen verschiedener Compliance-Frameworks zu erfüllen, finden Sie in den folgenden Ressourcen:

• Schutz von Gesundheitsdaten auf Cloud de Confiance
• Center für Compliance-Ressourcen

Quelle des Schlüsselmaterials auswählen

Wenn Sie einen Schlüssel erstellen, müssen Sie entweder Cloud KMS das Schlüsselmaterial für Sie generieren lassen oder manuell Schlüsselmaterial importieren, das außerhalb von Cloud de Confiancegeneriert wurde. Wenn möglich, empfehlen wir, Schlüsselmaterial in Cloud KMS zu generieren. Bei dieser Option besteht kein Risiko, dass das Rohschlüsselmaterial außerhalb von Cloud KMS offengelegt wird. Außerdem werden automatisch neue Schlüsselversionen basierend auf dem von Ihnen ausgewählten Schlüsselrotationszeitraum erstellt. Wenn Sie Ihr eigenes Schlüsselmaterial importieren müssen, empfehlen wir, die folgenden betrieblichen Aspekte und Risiken der Verwendung des BYOK-Ansatzes (Bring Your Own Key) zu berücksichtigen:

• Können Sie die automatische Importierung neuer Schlüsselversionen implementieren? Dazu gehören sowohl Cloud KMS-Einstellungen zum Einschränken von Schlüsselversionen auf den Import als auch die Automatisierung außerhalb von Cloud KMS zum konsistenten Generieren und Importieren von Schlüsselmaterial. Welche Auswirkungen hat es, wenn durch Ihre Automatisierung nicht zum erwarteten Zeitpunkt eine neue Schlüsselversion erstellt wird?

• Wie beabsichtigen Sie, das ursprüngliche Schlüsselmaterial sicher zu speichern oder zu hinterlegen?

• Wie können Sie das Risiko minimieren, dass beim Importieren Ihres Schlüssels das Rohschlüsselmaterial offengelegt wird?

• Welche Auswirkungen hat es, wenn ich einen zuvor gelöschten Schlüssel noch einmal importiere, weil das Rohschlüsselmaterial außerhalb von Cloud de Confianceaufbewahrt wurde?

• Rechtfertigt der Vorteil des selbstständigen Importierens von Schlüsselmaterial den erhöhten operativen Aufwand und das erhöhte Risiko?

Schlüsselverwaltungs- und Schlüsselspeichermodelle auswählen

Beim Entwerfen Ihrer CMEK-Architektur müssen Sie entscheiden, wo und wie Ihre Schlüssel verwaltet werden. Im Idealfall wählen Sie ein Schlüsselverwaltungsmodell und ein Schlüsselspeichermodell aus, die aufeinander abgestimmt sind. Das von Ihnen ausgewählte Governance- und Speichermodell wirkt sich auf wichtige Konfigurationen aus, z. B. auf die Durchsetzung der Funktionstrennung.

Schlüssel-Governance

Die Schlüsselverwaltung beschreibt, wer in einer Organisation für die Verwaltung des Lebenszyklus Ihrer Cloud KMS-Ressourcen und die Aufrechterhaltung von Schutzmaßnahmen zur Steuerung der Verwendung von Cloud KMS verantwortlich ist. Es gibt verschiedene Ansätze für die Schlüsselverwaltung, die sich auf einem Spektrum von zentralisierter Verwaltung bis hin zu delegierter Verwaltung bewegen:

• Zentrale Governance: Ein dediziertes Sicherheits- oder Plattformteam ist für die Verwaltung des Lebenszyklus aller kryptografischen Schlüssel in der gesamten Organisation verantwortlich. Dieses Modell wird häufig von stark regulierten Unternehmen mit strengen Compliance-Anforderungen gewählt.
• Delegierte Governance: Ein zentrales Sicherheitsteam verwendet Guardrails, um Verschlüsselungsstandards vorzuschreiben, delegiert aber die Verantwortung für wichtige Lebenszyklusvorgänge an Anwendungsbesitzer in ihren Projekten. Diese Schutzmaßnahmen können Organisationsrichtlinien mit verwalteten Beschränkungen und benutzerdefinierten Einschränkungen sowie IAM-Zuweisungen und ‑Verweigerungsrichtlinien umfassen. Dadurch werden zentrale betriebliche Engpässe beseitigt.

Google empfiehlt eine zentrale Schlüsselverwaltung für Organisationen mit strengen behördlichen Anforderungen oder für Organisationen, die auf externe Schlüsselsysteme angewiesen sind, um den Schlüssel-Lebenszyklus zu verwalten.

Schlüsselspeicherung

Der Schlüsselspeicherort beschreibt, wo Cloud KMS-Ressourcen in einer Organisation erstellt werden. Es gibt zwei Hauptansätze für die Schlüsselspeicherung: Schlüsselspeicherung im dedizierten Projekt und Schlüsselspeicherung im selben Projekt.

• Schlüsselspeicher im dedizierten Projekt: Ein dediziertes Schlüsselprojekt enthält Schlüssel, die für mehrere Anwendungen verwendet werden. Normalerweise hat jeder Umgebungsordner ein eigenes Schlüsselprojekt. Sie können Autokey mit Schlüsselspeicher im dedizierten Projekt verwenden. Weitere Informationen zum Schlüsselspeichermodell für dedizierte Projekte finden Sie unter Schlüsselspeicher im dedizierten Projekt.

• Schlüsselspeicher im selben Projekt: Schlüssel werden im selbenCloud de Confiance -Projekt wie die Ressourcen gespeichert, die sie schützen. Das wird manchmal als „der Schlüssel folgt den Daten“ bezeichnet. Sie können Autokey mit dem Schlüsselspeicher im selben Projekt verwenden. Weitere Informationen zum Schlüsselspeichermodell im selben Projekt finden Sie unter Schlüsselspeicher im selben Projekt.

Google empfiehlt eine verteilte Schlüsselverwaltung, wenn die Priorität auf Entwicklergeschwindigkeit, Agilität und klarer Verantwortlichkeit liegt.

Governance und Speicher abstimmen

Die folgende Tabelle enthält Beispiele dafür, wie diese Governance- und Speichermodelle kombiniert werden können, um unterschiedliche Organisationsanforderungen zu erfüllen:

Governance-Modell	Schlüsselspeicher im dedizierten Projekt	Schlüsselspeicher im selben Projekt
Zentrale Governance	Vollständig zentralisierter Ansatz Empfohlene Verwendung: Organisationen mit strengen behördlichen Anforderungen, die eine Isolation der Projektgrenzen vorschreiben. Operative Auswirkungen: Hohe Komplexität bei der Einrichtung. Erfordert eine robuste Automatisierung (z. B. eine „Projektfabrik“), um Betriebsverzögerungen für Entwicklungsteams zu vermeiden.	Kontrollierte Inhaberschaft Empfohlene Verwendung: Organisationen, die eine zentrale Sicherheitskontrolle benötigen, aber die Entwicklungsgeschwindigkeit maximieren möchten. Operative Auswirkungen: Geringe Komplexität bei der Einrichtung. Bei der zentralen Sicherheit wird die Richtlinie mithilfe von Guardrails durchgesetzt, während sich die Schlüssel zur einfachen Verwaltung am selben Ort wie die Ressourcen befinden, die sie schützen.
Delegierte Governance	Nicht empfohlen Die Einführung von projektübergreifender IAM-Komplexität macht die Delegation der Schlüsselverwaltung an Anwendungsteams zunichte.	Autonomous DevOps Empfohlene Verwendung: Schnelle, dezentrale Organisationen mit einer starken DevOps-Kultur. Operative Auswirkungen: Minimale Komplexität bei der Einrichtung. Anwendungsteams haben die volle Autonomie über Ressourcen und Schlüssel innerhalb ihrer Projektgrenzen.

Konsistente Architektur in allen Umgebungen verwenden

Wir empfehlen, für jede Anwendung dasselbe Schlüsselspeichermuster in Entwicklungs-, Test- und Produktionsumgebungen zu verwenden. Diese architektonische Konsistenz trägt dazu bei, dass Ihre IAM-Berechtigungen, Bereitstellungspipelines und Sicherheitskontrollen in niedrigeren Umgebungen gründlich getestet werden, bevor Sie sie in der Produktion bereitstellen. Wenn Sie unterschiedliche Architekturen für Ihre Umgebungen auswählen, besteht das Risiko von Konfigurationsabweichungen, die zu Bereitstellungsfehlern führen können.

Schlüsselspeicher im dedizierten Projekt

Bei einem Schlüsselspeichermodell mit dediziertem Projekt werden alle Schlüssel für einen bestimmten Umgebungsordner (z.B. „Production“) in einem zentralen, freigegebenen Schlüsselprojekt gespeichert. Berechtigungen für die Schlüsselverwaltung werden einem gemeinsamen Sicherheitsteam erteilt, das in der Regel auch den Lebenszyklus von Schlüsseln und Schutzmaßnahmen wie CMEK-Organisationsrichtlinien sowie IAM-Richtlinien und Rollenzuweisungen verwaltet.

Anwendungsfall

Wir empfehlen die Verwendung des Schlüsselmodells mit dediziertem Projekt, wenn Ihre Organisation strenge, zentrale Kontrolle über Verschlüsselungsschlüssel priorisiert, was häufig durch behördliche Anforderungen bedingt ist, oder wenn Schlüssel auf einem externen HSM gehostet werden.

Wenn Ihre Organisation einem Compliance-Framework unterliegt, das einen Cryptographic Officer oder Key Custodian erfordert, z. B. PCI DSS oder BSI C5, ist dieses Modell eine gute Wahl. Wenn Sie alle Schlüssel für eine Anwendung in einem einzelnen, dedizierten Schlüsselprojekt isolieren, können Sie die Rolle „Cloud KMS-Administrator“ nur einer kleinen, geprüften Gruppe von Sicherheitsadministratoren zuweisen. Dies kann Compliance-Prüfungen vereinfachen, da die Anzahl der Projekte, in denen Richtlinien für den Schlüsseladministrationszugriff überprüft werden müssen, begrenzt wird.

Hinweise

Dieser Ansatz kann zu projektübergreifenden IAM-Komplexitäten und potenziellen Engpässen für Entwicklungsteams führen. Um dieses Risiko zu minimieren, können Sie die automatische Projektbereitstellung implementieren, die manchmal auch als „Project Factory“ bezeichnet wird. Damit lassen sich die Erstellung von Schlüsseln und die Zuweisung von Berechtigungen automatisieren.

Beispiel

Das folgende Diagramm zeigt ein Beispiel für eine Ressourcenhierarchie für eine Produktionsumgebung mit dem Schlüsselmodell für dedizierte Projekte:

• Der Ordner „Prod“ enthält einzelne Ordner und Projekte für verschiedene Anwendungen sowie einen freigegebenen Ordner.
• Die Anwendungsprojekte enthalten eine Vielzahl verschiedener Ressourcen wie Compute Engine-Instanzen und Cloud Storage-Buckets, aber keine Cloud KMS-Schlüssel.
• Der Ordner „Shared“ enthält Ressourcen, die von den verschiedenen Anwendungen gemeinsam genutzt werden.
• Im freigegebenen Ordner befindet sich ein dediziertes Schlüsselprojekt, in dem die Cloud KMS API aktiviert ist. Dieses Projekt enthält alle Schlüssel, die zum Schutz von Ressourcen im Ordner „Prod“ verwendet werden.
• Guardrails auf Organisations- und Ordnerebene wie Einschränkungen für Organisationsrichtlinien und IAM-Richtlinien erzwingen die Trennung von Aufgaben und andere Praktiken.
• Entwickler können erweiterte Berechtigungen wie die Rolle „Projektinhaber“ in einem einzelnen Anwendungsordner oder Projekt haben, ohne dass ihnen Berechtigungen für das Schlüsselprojekt gewährt werden müssen.

Schlüsselspeicher im selben Projekt

In diesem Modell werden Schlüssel im selben Projekt wie die Ressourcen gespeichert, die sie schützen. Schutzmaßnahmen für die Schlüsselverwaltung werden in der Regel von einem zentralen Sicherheitsteam implementiert, auch wenn Entwickler den Schlüssel-Lebenszyklus für ihre eigenen Anwendungen verwalten.

Anwendungsfall

Wir empfehlen die Verwendung des Schlüsselmodells für dasselbe Projekt, wenn die Entwicklergeschwindigkeit, Agilität und klare Verantwortlichkeit für Sie Priorität haben. Wenn Schlüssel und die Ressourcen, die sie schützen, am selben Ort gespeichert werden, stimmt die Schlüsselverantwortung mit der Datenverantwortung überein: Der Schlüssel folgt den Daten. Dieses Modell erleichtert die Übertragung der Verantwortlichkeiten für die Schlüsselverwaltung an die Inhaber von Arbeitslasten, die die Verantwortung für die Einhaltung der CMEK-Organisationsrichtlinien und die Verwaltung von Schlüssel-Lebenszyklusvorgängen in ihren Projekten übernehmen können.

Hinweise

Dieses Modell gibt Anwendungsteams mehr Autonomie, erfordert aber eine sorgfältige Überprüfung der IAM-Rollen in jedem Projekt, um das Prinzip der geringsten Berechtigung durchzusetzen. Dieses Modell kann die betriebliche Komplexität für Organisationen erhöhen, die BYOK (Bring Your Own Key) implementieren oder Cloud EKM-Schlüssel verwenden, da der Aufwand für die Koordination zwischen den Systemen hoch ist.

Beispiel

Das folgende Diagramm zeigt ein Beispiel für eine Ressourcenhierarchie für eine Produktionsumgebung mit dem Schlüsselverwaltungmodell für dasselbe Projekt:

• Der Ordner „Prod“ enthält einzelne Ordner und Projekte für verschiedene Anwendungen.
• Die Anwendungsprojekte enthalten eine Vielzahl verschiedener Ressourcen wie Compute Engine-Instanzen und Cloud Storage-Buckets, einschließlich aller Cloud KMS-Schlüssel, die diese Ressourcen schützen.
• Schutzmaßnahmen auf Organisations- und Ordnerebene wie Einschränkungen für Organisationsrichtlinien und IAM-Richtlinien erzwingen die Aufgabentrennung und andere Praktiken. Das Erzwingen der Aufgabentrennung erfordert jedoch möglicherweise eine sorgfältigere Konfiguration.
• Entwickler benötigen erweiterte Cloud KMS-Berechtigungen für das Ressourcenprojekt, um Schlüssel erstellen und verwalten zu können.

Aufgabentrennung erzwingen

Unabhängig von Ihrem Speichermodell müssen Sie separate Identitäten und Berechtigungen für diejenigen verwalten, die Ihre Verschlüsselungsschlüssel verwalten, und diejenigen, die sie verwenden. Um das Prinzip der geringsten Berechtigung und die strikte Aufgabentrennung zu erzwingen, weisen Sie IAM-Rollen basierend auf bestimmten betrieblichen Verantwortlichkeiten zu.

In der folgenden Tabelle ist die empfohlene Rollentrennung für Cloud KMS zusammengefasst:

Zuständigkeit	Empfohlene Rolle	Zusammenfassung der Berechtigungen
Schlüsselverwaltung, z.B. Schlüssellebenszyklen und Governance Dazu können menschliche Administratoren und IaC-Principals gehören, die erhöhte Berechtigungen benötigen.	Cloud KMS-Administrator (roles/cloudkms.admin)	Schlüssel und zugehörige Ressourcen erstellen, rotieren, aktivieren, deaktivieren und löschen. IAM-Richtlinien verwalten.
Bereitstellung von Ressourcen, z.B. Erstellung von CMEK-geschützten Ressourcen Dazu können menschliche Entwickler und IaC-Principals ohne erhöhte Berechtigungen gehören.	Dienstspezifische Administrator- oder Bearbeiterrollen wie die folgenden: BigQuery-Nutzer (roles/bigquery.user) Compute-Administrator (roles/compute.admin)	Wählen Sie Schlüssel beim Erstellen von Ressourcen aus.
Schlüsselverwendung, z.B. Verschlüsselung und Entschlüsselung Weisen Sie diese Rolle nur Dienst-Agents zu. Für Schlüssel, die in CMEK-Integrationen verwendet werden, benötigen menschliche Identitäten diese Berechtigungen nicht.	Cloud KMS CryptoKey-Verschlüsseler/Entschlüsseler (roles/cloudkms.cryptoKeyEncrypterDecrypter)	Daten mit dem Schlüssel verschlüsseln und entschlüsseln

Rechteausweitung mit geringsten Berechtigungen für IaC-Pipelines anwenden

Viele Organisationen automatisieren die Ressourcenbereitstellung mithilfe von IaC-Pipelines (Infrastruktur als Code) wie Terraform-Runnern. Die Art und Weise, wie Sie Ihren Schlüsselspeicher gestalten, wirkt sich direkt auf den Sicherheitsstatus dieser Pipelines aus.

Um die Bereitstellung von Cloud KMS-Schlüsseln zu automatisieren, müssen Ihren IaC-Pipelines administrative Rollen mit hohen Berechtigungen zugewiesen werden, damit sie Schlüssel generieren und IAM-Richtlinien ändern können. Wenn ein Angreifer die IaC-Pipeline manipuliert, kann er die vollständige administrative Kontrolle über Ihre Schlüsselverwaltungsebene erlangen.

• Wenn Sie die Schlüssel in einem dedizierten Projekt speichern, benötigt die Pipeline Administratorzugriff auf das zentrale Cloud KMS-Projekt. Wenn die Pipeline manipuliert wird, kann dies die Schlüsselverwaltungsebene für Ihre gesamte Organisation offenlegen.
• Wenn Sie den Schlüsselspeicher im selben Projekt verwenden, benötigt die Pipeline nur Administratorzugriff auf das Ressourcenprojekt. Dadurch wird das potenzielle Risiko auf die jeweilige Anwendung beschränkt, es müssen aber weiterhin erhöhte Berechtigungen innerhalb des Projekts verwaltet werden.

Cloud KMS Autokey begegnet diesem Risiko, indem die Schlüsselbereitstellung an einen sicheren, von Google verwalteten Dienst-Agenten delegiert wird. So können Sie eine Pipeline mit den geringsten Berechtigungen für die laufende Schlüsselbereitstellung implementieren:

• Pipelines mit geringen Berechtigungen: Für die IaC-Pipeline ist nur die Rolle „Cloud KMS Autokey User“ (roles/cloudkms.autokeyUser) mit geringen Berechtigungen erforderlich, um einen Schlüssel anzufordern, indem eine KeyHandle-Ressource erstellt wird.
• Automatisierte Bereitstellung: Das Erstellen von Schlüsseln und das Aktualisieren von IAM-Richtlinien werden im Hintergrund vom von Google verwalteten Cloud KMS-Dienst-Agenten übernommen.
• Begrenztes Risiko: Durch die Minimierung der Berechtigungen, die Ihrer Pipeline gewährt werden, wird vermieden, dass Ihren Bereitstellungspipelines erweiterte Berechtigungen zum Erstellen von Schlüsseln oder Sicherheitsadministratorberechtigungen oder die Möglichkeit zum Zuweisen von Helferrollen gewährt werden. Dadurch wird das Risiko einer Pipeline-Gefährdung erheblich reduziert.

Für eine IaC-Pipeline, die Autokey ermöglicht, ist eine permissive Rolle wie „Cloud KMS Autokey Admin“ (roles/cloudkms.autokeyAdmin) erforderlich. Wenn Sie also IaC-Pipelines verwenden, um die Autokey-Aktivierung zu verwalten, müssen Sie auch die Aufgabentrennung auf einzelne IaC-Hauptkonten anwenden.

Empfohlene Praktiken für die Schlüsselverwaltung einhalten

Google empfiehlt Praktiken für Schlüsselspeicherort, Schutzlevel, Rotationszeitplan, Granularität und Berechtigungen. Im Dashboard für Verschlüsselungsmesswerte können Sie sehen, wie gut Ihre Schlüssel diesen Praktiken entsprechen. Mit Security Command Center-Ergebnissen zu Sicherheitslücken können Sie Verstöße gegen die Funktionstrennung erkennen.

Speicherort des Schlüssels

Sie müssen Cloud KMS-Schlüsselbunde an den Standorten erstellen, an denen Sie Cloud de Confiance Ressourcen bereitstellen möchten, die mit CMEK verschlüsselt sind. Sie müssen dies tun, bevor Sie die Schlüssel erstellen können.

• Für regionale und zonale Ressourcen muss ein Schlüsselbund und ein Schlüssel in derselben Region wie die Ressource oder am Standort global verwendet werden.
• Für globale Ressourcen muss ein Schlüsselbund und ein Schlüssel am Standort global verwendet werden.

In den meisten Fällen werden diese Einschränkungen vom Cloud de Confiance-Dienst durchgesetzt.

Die Durchsetzung der Verwendung regionaler Schlüssel ist ein wichtiger Bestandteil einer erfolgreichen Strategie zur Regionalisierung von Daten. Wenn Sie die Verwendung von Schlüsselbunden und Schlüsseln in einer bestimmten Region erzwingen, erzwingen Sie auch, dass Ressourcen der Region des Schlüsselbunds entsprechen müssen.

Strategie für die Schlüsselgranularität auswählen

Granularität bezieht sich auf den Umfang und die Reichweite der beabsichtigten Verwendung der einzelnen Schlüssel. Ein Schlüssel, der mehrere Ressourcen schützt, ist beispielsweise weniger detailliert als ein Schlüssel, der nur eine Ressource schützt. Wenn Sie eine geeignete Strategie für die Schlüsselgranularität auswählen, können Sie die NIST-Empfehlung einhalten, dass jeder Schlüssel einen bestimmten Zweck hat.

Im Allgemeinen empfehlen wir, jeden Schlüssel so zu verwenden:

• Wird für ein einzelnes Cloud de Confiance Projekt verwendet.
• Wird an einem einzelnen Ort verwendet, z. B. us-central1.
• Wird in einem einzelnen Dienst oder Produkt verwendet, z. B. BigQuery.
• Wenn möglich, für eine einzelne Ressource verwendet, z. B. einen einzelnen Cloud Storage-Bucket.

Für die meisten Organisationen bietet diese Strategie ein gutes Gleichgewicht zwischen dem Aufwand für die Verwaltung vieler hochgranularer Schlüssel und den potenziellen Risiken der Verwendung weniger granularer Schlüssel, die von vielen Projekten, Diensten oder Ressourcen gemeinsam genutzt werden.

Wenn Sie diese Granularitätsrichtlinien befolgen, können Sie Schlüsselversionen leichter sicher deaktivieren oder löschen und das Risiko einer versehentlichen oder böswilligen Schlüsselzerstörung wird begrenzt.

Schutzstufe für Schlüssel auswählen

Beim Erstellen eines Schlüssels liegt es in Ihrer Verantwortung, die Schutzstufe auszuwählen, die für jeden Schlüssel basierend auf Ihren Anforderungen an die mit CMEK verschlüsselten Daten und Arbeitslasten geeignet ist. * Wenn Sie möchten, dass Ihr Schlüsselmaterial außerhalb von Cloud de Confiancegespeichert wird, verwenden Sie Cloud EKM-Schlüssel. Wir empfehlen das Schutzlevel EXTERNAL_VPC, um eine bessere Verfügbarkeit zu erzielen. * Wenn Sie Ihr Schlüsselmaterial nicht außerhalb von Cloud de Confiancespeichern müssen, empfehlen wir die Verwendung von softwarebasierten Schlüsseln.

Rotationszeitraum auswählen

Cloud KMS unterstützt die automatische Schlüsselrotation von softwaregestützten und hardwaregestützten symmetrischen Schlüsseln, wie sie für CMEK verwendet werden. Für softwarebasierte Schlüssel empfehlen wir den branchenüblichen Rotationszeitraum von 90 Tagen. Für Cloud HSM-Schlüssel empfehlen wir den branchenüblichen Rotationszeitraum von 365 Tagen. Externe Schlüssel müssen gemäß dem von Ihnen ausgewählten Zeitplan manuell rotiert werden.

Wir empfehlen, den geeigneten Zeitraum für die Schlüsselrotation für Ihre Anforderungen zu ermitteln. Die Häufigkeit der Schlüsselrotation hängt von den Anforderungen Ihrer Arbeitslasten in Bezug auf Vertraulichkeit oder Compliance ab. Beispielsweise kann eine Schlüsselrotation mindestens einmal jährlich erforderlich sein, um bestimmte Compliance-Standards zu erfüllen. Für hochsensible Arbeitslasten können Sie auch einen kürzeren Rotationszeitraum wählen.

Durch die häufige Schlüsselrotation wird die Anzahl der Nachrichten begrenzt, die mit derselben Schlüsselversion verschlüsselt werden. Dies trägt dazu bei, das Risiko und die Folgen eines Schlüsselmissbrauchs zu verringern.

Prinzip der geringsten Berechtigung anwenden

Halten Sie sich beim Zuweisen von IAM-Rollen an das Prinzip der geringsten Berechtigung. Wir empfehlen dringend, einfache Rollen wie „Inhaber“, „Bearbeiter“ und „Betrachter“ zu vermeiden. Gewähren Sie stattdessen vordefinierte Cloud KMS-Rollen, um das Risiko von Sicherheitsvorfällen im Zusammenhang mit überprivilegiertem Zugriff zu verringern. Wenn ein Hauptkonto beispielsweise nur Schlüsselmaterial importieren muss, weisen Sie ihm die Rolle „Cloud KMS-Importer“ (roles/cloudkms.importer) anstelle der freizügigeren Rolle „Cloud KMS-Administrator“ (roles/cloudkms.admin) zu.

Operative Vorkehrungen treffen

In den folgenden Abschnitten werden Kontrollen beschrieben, die Sie implementieren können, um Risiken wie eine inkonsistente Schlüsselnutzung oder versehentliches Löschen oder Vernichten zu minimieren.

Projektsperren erzwingen

Wir empfehlen, Projekte mit Sperren zu schützen (Vorabversion), um ein versehentliches Löschen Ihrer Cloud KMS-Projekte und der darin enthaltenen Schlüssel zu verhindern. Solange eine Projektsperre aktiv ist, kann das Projekt erst gelöscht werden, wenn die Sperre entfernt wird. Bei Projekten, die Cloud KMS-Schlüssel enthalten, wird so eine mögliche Ursache für das versehentliche Löschen von Schlüsseln verhindert.

CMEK-Schlüssel erforderlich machen

Wir empfehlen, die Verwendung von CMEK in Ihrer Umgebung mit Einschränkungen für Organisationsrichtlinien zu erzwingen.

Verwenden Sie constraints/gcp.restrictNonCmekServices, um Anfragen zum Erstellen bestimmter Ressourcentypen ohne Angabe eines CMEK-Schlüssels zu blockieren.

Mindestdauer für die geplante Löschung erforderlich

Wir empfehlen, eine Mindestdauer für zum Löschen geplant festzulegen. Das Löschen eines Schlüssels ist ein unwiderruflicher Vorgang, der zu einem dauerhaften Datenverlust führen kann. Standardmäßig verwendet Cloud KMS einen Zeitraum von 30 Tagen für den Status Zum Löschen vorgemerkt (manchmal auch Zeitraum für das vorläufige Löschen genannt), bevor das Schlüsselmaterial unwiederbringlich gelöscht wird. So haben Sie etwas Zeit, einen Schlüssel wiederherzustellen, falls er versehentlich gelöscht wurde. Es ist jedoch möglich, dass jemand mit der Rolle „Cloud KMS Admin“ einen Schlüssel mit einer Dauer von nur 24 Stunden für das geplante Löschen erstellt. Das ist möglicherweise nicht ausreichend Zeit, um ein Problem zu erkennen und den Schlüssel wiederherzustellen. Die Dauer des Status Löschen geplant kann nur beim Erstellen des Schlüssels festgelegt werden.

Wenn ein Schlüssel zum Löschen vorgemerkt ist, kann er nicht für kryptografische Vorgänge verwendet werden. Alle Anfragen zur Verwendung des Schlüssels schlagen fehl. Prüfen Sie in dieser Zeit die Audit-Logs, um sicherzugehen, dass der Schlüssel nicht verwendet wird. Wenn Sie den Schlüssel wieder verwenden möchten, müssen Sie ihn vor Ablauf des Zeitraums zum Löschen vorgemerkt wiederherstellen.

Damit alle erstellten Schlüssel eine Mindestdauer für die geplante Vernichtung haben, empfehlen wir, die Organisationsrichtlinien-Einschränkung constraints/cloudkms.minimumDestroyScheduledDuration mit mindestens 30 Tagen oder der gewünschten Dauer zu konfigurieren. Diese Organisationsrichtlinie verhindert, dass Nutzer Schlüssel mit einer Dauer für den Status Zum Löschen vorgemerkt erstellen, die kürzer ist als der in der Richtlinie angegebene Wert.

Zulässige Schutzstufen für CMEKs erzwingen

Wir empfehlen, Ihre Anforderungen an die Schlüsselschutzstufen in Ihrer Umgebung mithilfe von Einschränkungen für Organisationsrichtlinien einheitlich durchzusetzen.

Mit constraints/cloudkms.allowedProtectionLevels können Sie erzwingen, dass für neue Schlüssel, Schlüsselversionen und Importjobs die von Ihnen zugelassenen Schutzstufen verwendet werden müssen.

Aufdeckungskontrollen für CMEKs konfigurieren

Cloud de Confiance bietet verschiedene Erkennungsmechanismen für CMEKs. In den folgenden Abschnitten wird beschrieben, wie Sie die für Cloud KMS relevanten Steuerelemente aktivieren und verwenden.

Audit-Logging aktivieren und zusammenfassen

Wir empfehlen, Cloud KMS-Audit-Logs zur Administratoraktivität für alle Ressourcen in Ihrer Organisation an einem zentralen Ort zusammenzufassen. So kann ein Sicherheitsteam oder ein Prüfer alle Aktivitäten im Zusammenhang mit dem Erstellen oder Ändern von Cloud KMS-Ressourcen gleichzeitig prüfen. Eine Anleitung zum Konfigurieren aggregierter Logsenken finden Sie unter Logs Ihrer Organisation zusammenfassen und speichern.

Optional können Sie Datenzugriffsprotokolle aktivieren, um Vorgänge zu protokollieren, bei denen die Schlüssel verwendet werden, einschließlich Verschlüsselungs- und Entschlüsselungsvorgängen. Bei der Verwendung von CMEKs kann dies zu einem erheblichen Logvolumen führen und sich auf Ihre Kosten auswirken, da für jeden Vorgang von jedem Dienst, der CMEKs verwendet, Datenzugriffsprotokolle erstellt werden. Bevor Sie Datenzugriffsprotokolle aktivieren, sollten Sie einen klaren Anwendungsfall für die zusätzlichen Protokolle definieren und prüfen, wie sich Ihre Protokollierungskosten erhöhen.

Zusammenfassung der Best Practices

In der folgenden Tabelle sind die Best Practices zusammengefasst, die in diesem Dokument empfohlen werden:

Thema	Aufgabe
Cloud KMS-Schlüsselprojekte	Verwenden Sie für jede Umgebung ein zentrales Schlüsselprojekt. Erstellen Sie keine Cloud KMS-Ressourcen im selben Projekt wie die Cloud de Confiance-Ressourcen, die von den Schlüsseln geschützt werden.
Cloud KMS-Schlüsselbunde	Erstellen Sie Cloud KMS-Schlüsselbunde für jeden Standort, an dem Sie Cloud de Confiance-Ressourcen schützen möchten.
Detaillierungsgrad des Schlüssels	Wählen Sie ein Muster für die Schlüsselgranularität aus, das Ihren Anforderungen in Bezug auf Risikotoleranz, Kosten und Betriebsaufwand entspricht.
Schutzniveau	Wählen Sie Cloud EKM aus, wenn Ihr Schlüsselmaterial außerhalb von Cloud de Confiance gespeichert werden muss oder wenn Sie eine FIPS 140-2-Zertifizierung der Stufe 2 oder 3 benötigen. Wählen Sie andernfalls Softwareschlüssel aus. Hinweise zur Auswahl eines Schutzniveaus
Schlüsselmaterial	Verwenden Sie für Schlüsselmaterial, das auf Cloud de Confiancegehostet wird, nach Möglichkeit von Cloud de Confiancegeneriertes Schlüsselmaterial. Wenn Sie importiertes Schlüsselmaterial verwenden, implementieren Sie Automatisierung und Verfahren, um Risiken zu minimieren.
Schlüsselzweck und Algorithmus	Alle CMEK-Schlüssel müssen den symmetrischen Schlüsselzweck ENCRYPT_DECRYPT und den Algorithmus GOOGLE_SYMMETRIC_ENCRYPTION verwenden.
Rotationszeitraum	Verwenden Sie die automatische Schlüsselrotation, um sicherzustellen, dass Ihre Schlüssel planmäßig rotiert werden. Wählen Sie einen Rotationszeitraum aus, der Ihren Anforderungen entspricht, idealerweise mindestens einmal pro Jahr. Verwenden Sie eine häufigere Schlüsselrotation für sensible Arbeitslasten.
Geringste Berechtigung	Weisen Sie die am stärksten beschränkten vordefinierten Rollen zu, die Ihre Hauptkonten zum Ausführen ihrer Aufgaben benötigen. Verwenden Sie keine einfachen Rollen.
Aufgabentrennung	Separate Berechtigungen für Schlüsseladministratoren und Identitäten, die Schlüssel verwenden, beibehalten.
Projektsperren	Verwenden Sie Projektsperren, um ein versehentliches Löschen Ihrer wichtigsten Projekte zu verhindern.
CMEKs erzwingen	Verwenden Sie die Einschränkung constraints/gcp.restrictNonCmekServices.
Mindestdauer für die geplante Löschung erforderlich	Verwenden Sie die Einschränkung constraints/cloudkms.minimumDestroyScheduledDuration.
Zulässige Schutzstufen für CMEKs erzwingen	Verwenden Sie die Einschränkung constraints/cloudkms.allowedProtectionLevels.
Audit-Logging aktivieren und zusammenfassen	Audit-Logs zu Administratoraktivitäten für alle Ressourcen in Ihrer Organisation zusammenfassen. Überlegen Sie, ob Sie die Protokollierung von Vorgängen mit Schlüsseln aktivieren möchten.
Compliance-Anforderungen prüfen	Überprüfen Sie Ihre Cloud KMS-Architektur und vergleichen Sie sie mit allen Compliance-Anforderungen, die Sie einhalten müssen.