Cloud Key Management Service-Verschlüsselung

Der Inhalt dieses Dokuments wurde im Januar 2025 zum letzten Mal aktualisiert und stellt den Stand zum Zeitpunkt der Erstellung dar. Die Sicherheitsrichtlinien und -systeme von Google Cloud können sich aber in Zukunft ändern, da wir den Schutz unserer Kundinnen und Kunden kontinuierlich verbessern.

In diesem Dokument wird beschrieben, wie Cloud Key Management Service (Cloud KMS) Schlüsselverwaltungsdienste in Google Cloud für die Verschlüsselung inaktiver Daten bereitstellt. Google Cloud geht von der Überlegung aus, dass Google Cloud Kunden die Eigentümer ihrer Daten sind. Deswegen sollten Sie selbst kontrollieren können, wie ihre Daten genutzt werden.

Wenn Sie Daten mit Google Cloudspeichern, werden Ihre Daten standardmäßig bei Inaktivität automatisch verschlüsselt. Mit der Cloud KMS-Plattform haben Sie mehr Kontrolle darüber, wie Ihre inaktiven Daten verschlüsselt und Ihre Verschlüsselungsschlüssel verwaltet werden.

In diesem Dokument wird die interne Funktionsweise der Cloud KMS-Plattform behandelt. Mit den Optionen können Sie Schlüssel und andere vertrauliche Daten, die Sie in Google Cloudspeichern, besser schützen. Das Dokument richtet sich an technische Entscheidungsträger, die Details zu Architektur, Infrastruktur und Features von Cloud KMS benötigen. Dabei wird vorausgesetzt, dass Sie Grundwissen im Bereich Verschlüsselungskonzepte und Cloud-Architekturen haben.

Schlüssel in Google Cloud

In der folgenden Tabelle werden die verschiedenen Arten von Schlüsseln in Google Cloudbeschrieben.

Schlüsseltyp	Cloud KMS Autokey	Cloud KMS-Schlüssel, vom Kunden verwaltet (manuell)	Google-owned and Google-managed encryption key (standardmäßige Google-Verschlüsselung)
Kann wichtige Metadaten ansehen	Ja	Ja	Nein
Eigentum an Schlüsseln^1	Kunde	Kunde	Google
Kann ^2-Schlüssel verwalten und ^3-Schlüssel steuern	Die Schlüsselerstellung und ‑zuweisung erfolgt automatisch. Die manuelle Steuerung durch den Kunden wird vollständig unterstützt.	Kunde, nur manuelle Steuerung	Google
Unterstützt gesetzliche Anforderungen für vom Kunden verwaltete Schlüssel	Ja	Ja	Nein
Schlüsselfreigabe	Eindeutig für einen Kunden	Eindeutig für einen Kunden	Daten mehrerer Kunden werden in der Regel durch gemeinsame Schlüsselverschlüsselungsschlüssel (Key Encryption Keys, KEKs) geschützt.
Steuerung der Schlüsselrotation	Ja	Ja	Nein
CMEK-Organisationsrichtlinien	Ja	Ja	Nein
Administrativen und Datenzugriff auf Verschlüsselungsschlüssel protokollieren	Ja	Ja	Nein
Logische Datentrennung durch Verschlüsselung	Ja	Ja	Nein
Preise	Variabel	Variabel	Kostenlos

¹ Der Inhaber des Schlüssels gibt an, wer die Rechte an dem Schlüssel hat. Schlüssel, die Ihnen gehören, haben einen stark eingeschränkten oder keinen Zugriff durch Google.

² Die Verwaltung von Schlüsseln umfasst die folgenden Aufgaben:

• Schlüssel erstellen
• Wählen Sie das Schutzniveau der Schlüssel aus.
• Weisen Sie die Berechtigung zur Verwaltung der Schlüssel zu.
• Zugriff auf Schlüssel steuern
• Verwendung von Schlüsseln steuern.
• Rotationszeitraum von Schlüsseln festlegen und ändern oder eine Schlüsselrotation auslösen
• Schlüsselstatus ändern
• Schlüsselversionen löschen

³ Schlüssel kontrollieren: Das bedeutet, dass Sie festlegen, welche Art von Schlüsseln verwendet wird und wie sie eingesetzt werden. Außerdem müssen Sie Abweichungen erkennen und bei Bedarf Korrekturmaßnahmen planen. Sie können Ihre Schlüssel steuern, aber die Verwaltung der Schlüssel an einen Drittanbieter delegieren.

Cloud KMS-Grundsätze

Bei Cloud KMS liegt der Fokus von Google darauf, eine skalierbare, verlässliche und leistungsstarke Lösung mit umfassenden Optionen bereitzustellen, die Sie kontrollieren können. Cloud KMS basiert auf den folgenden Prinzipien:

• Kundensteuerung: Mit Cloud KMS können Sie Ihre eigenen Software- und Hardwareschlüssel für die Verschlüsselung und Signierung steuern. Diese Säule beinhaltet Unterstützung für BYOK (Bring Your Own Keys) und HYOK (Hold Your Own Keys).
• Zugriffssteuerung und Überwachung: Mit Cloud KMS können Sie Berechtigungen für einzelne Schlüssel verwalten und deren Verwendung überwachen.
• Regionalität: Cloud KMS bietet vorkonfigurierte Regionalisierung. Der Dienst ist so konfiguriert, dass Schlüssel nur an dem von Ihnen ausgewählten Google Cloud Standort erstellt, gespeichert und verarbeitet werden.
• Sicherungen: Damit Daten vor Korruption geschützt und erfolgreich entschlüsselt werden können, führt Cloud KMS regelmäßige Scans und Back-ups aller Schlüsselmaterialien und -metadaten durch.
• Sicherheit: Cloud KMS bietet starken Schutz vor nicht autorisiertem Zugriff auf Schlüssel und ist vollständig in die Steuerelemente der Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) und Cloud-Audit-Logs eingebunden.
• Logische Datentrennung:Die Cloud KMS-Verschlüsselung bietet durch die Verschlüsselung eine logische Datentrennung. Bei der logischen Datentrennung geben Dateninhaber keine Verschlüsselungsschlüssel (KEKs und DEKs) weiter.

Quellen und Verwaltungsoptionen für kryptografische Schlüssel

Mit der Cloud KMS-Plattform können Sie kryptografische Schlüssel in einem zentralen Cloud-Dienst entweder zur direkten Verwendung oder zur Verwendung durch andere Cloud-Ressourcen und -Anwendungen verwalten.

Das Google Cloud Portfolio für Schlüssel umfasst Folgendes:

• Standardverschlüsselung: Alle von Google gespeicherten Daten werden auf der Speicherebene mit dem AES-Algorithmus (Advanced Encryption Standard) AES-256 verschlüsselt. Wir generieren und verwalten die Schlüssel für die Standardverschlüsselung. Kunden haben keinen Zugriff auf die Schlüssel und können die Schlüsselrotation und -verwaltung nicht steuern. Standardverschlüsselungsschlüssel können von mehreren Kunden gemeinsam genutzt werden. Weitere Informationen finden Sie unter Standardverschlüsselung ruhender Daten.

• Cloud KMS mit softwaregeschützten Schlüsseln:Sie können die in Cloud KMS generierten Schlüssel verwalten. Mit dem Cloud KMS-Software-Back-End können Sie Ihre Daten wahlweise mit einem von Ihnen verwalteten symmetrischen oder asymmetrischen Schlüssel verschlüsseln oder signieren.

• Cloud KMS mit hardwaregeschützten Schlüsseln (Cloud HSM): Wenn Sie Cloud KMS mit dem Cloud HSM-Backend verwenden, können Sie eigene Schlüssel besitzen, die in Hardwaresicherheitsmodulen (HSMs) von Google generiert und gespeichert werden. Wenn Sie einen hardwaregeschützten Schlüssel benötigen, können Sie mithilfe des Cloud HSM-Back-Ends dafür sorgen, dass Ihre Schlüssel nur in FIPS 140-2 Level 3-validierten HSMs verwendet werden. Sie können hardwaregeschützte Schlüssel manuell mit einem Cloud KMS-Administrator oder automatisch mit Cloud KMS Autokey bereitstellen. Mit Autokey können Sie die Prozesse für die Schlüsselbereitstellung und ‑zuweisung für vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) automatisieren. Bei herkömmlichen HSM-Schlüsseln müssen die Schlüssel auf Anfrage von einem KMS-Administrator erstellt werden.

• Cloud KMS mit Schlüsselimport:Zur Erfüllung der BYOK-Anforderungen können Sie eigene kryptografische Schlüssel importieren, die Sie selbst generiert haben. Sie können diese Schlüssel außerhalb vonGoogle Cloudverwenden und verwalten und das Schlüsselmaterial in Cloud KMS verwenden, um Daten zu verschlüsseln oder zu signieren, die Sie in Google Cloudspeichern.

• Cloud KMS mit externem Schlüsselmanager (Cloud EKM): Zur Erfüllung der HYOK-Anforderungen können Sie Schlüssel erstellen und steuern, die in einem Key Manager außerhalb von Google Cloudgespeichert werden. Anschließend richten Sie die Cloud KMS-Plattform für die Verwendung der externen Schlüssel ein, um Ihre ruhenden Daten zu schützen. Sie können diese Verschlüsselungsschlüssel zusammen mit einem Cloud EKM-Schlüssel verwenden. Weitere Informationen zur externen Schlüsselverwaltung und zu Cloud EKM finden Sie unter Referenzarchitekturen für Cloud EKM.

Sie haben die Möglichkeit, von Cloud KMS generierte Schlüssel mit anderenGoogle Cloud -Diensten zu verwenden. Derartige Schlüssel sind als CMEKs bekannt. Mit dem CMEK-Feature können Sie Verschlüsselungsschlüssel generieren, verwenden, rotieren und löschen, wenn Sie Ihre Daten in anderen Google Cloud-Diensten schützen möchten. Wenn Sie CMEK mit Google Cloud -Diensten verwenden, werden der Schlüsselzugriff und die Nachverfolgung für Sie verwaltet.

Verschlüsselung und Schlüsselverwaltung bei Google

In diesem Abschnitt werden einige Begriffe für die Schlüsselverwaltung im Zusammenhang mit der mehrstufigen Infrastruktur für die Schlüsselverwaltung von Google erläutert.

Schlüsselbunde, Schlüssel und Schlüsselversionen

Das folgende Diagramm zeigt Schlüsselgruppierungen, Schlüsselbunde und Schlüssel mit einer einzelnen primären Version und mehreren vorherigen Versionen.

Die Konzepte, die im vorherigen Diagramm dargestellt werden, sind:

• Schlüssel: Ein benanntes Objekt, das einen kryptografischen Schlüssel darstellt, der für einen bestimmten Zweck verwendet wird. Das Schlüsselmaterial – die tatsächlichen für die kryptografischen Vorgänge verwendeten Bit – kann sich mit der Zeit ändern, wenn neue Schlüsselversionen erstellt werden. Sie können IAM-Zulassungsrichtlinien auf Schlüsselebene in der Ressourcenhierarchie zuweisen.

  Der Zweck und andere Attribute des Schlüssels werden mithilfe des Schlüssels verbunden und verwaltet. Daher ist der Schlüssel das wichtigste Objekt bei der Nutzung von KMS.

  Cloud KMS unterstützt sowohl asymmetrische als auch symmetrische Schlüssel. Ein symmetrischer Schlüssel wird zum Erstellen oder Validieren von MAC-Signaturen oder für die symmetrische Verschlüsselung verwendet, um einen Datenbestand zu schützen. Sie können beispielsweise AES-256 im GCM-Modus verwenden, um einen Klartextblock zu verschlüsseln. Ein asymmetrischer Schlüssel kann für die asymmetrische Verschlüsselung oder für die asymmetrische Signatur verwendet werden. Weitere Informationen finden Sie unter Unterstützte Zwecke und Algorithmen.

• Schlüsselbund: Eine Gruppierung von Schlüsseln für organisatorische Zwecke. Ein Schlüsselbund gehört zu einem Google Cloud -Projekt und befindet sich an einem bestimmten Standort. Schlüssel übernehmen Zulassungsrichtlinien von ihrem Schlüsselbund. Durch Gruppieren von Schlüsseln mit verwandten Berechtigungen in einem Schlüsselbund können Sie Berechtigungen für diese Schlüssel auf Schlüsselbundebene gewähren, aufheben oder bearbeiten, ohne dies für jeden Schlüssel einzeln vornehmen zu müssen. Schlüsselbunde sind praktisch und ermöglichen Kategorisierung. Wenn jedoch die Gruppierung von Schlüsselbunden für Sie nicht hilfreich ist, können Sie Berechtigungen auch direkt für Schlüssel verwalten. Mit Tags können Sie Richtlinien zulassen oder ablehnen, je nachdem, ob eine Ressource ein bestimmtes Tag hat oder nicht. Sie können Tags auf Schlüsselanhängerebene in der Ressourcenhierarchie anwenden.

  Um Konflikte bei Ressourcennamen zu vermeiden, können Sie einen Schlüsselbund oder Schlüssel nicht löschen. Für Schlüssel und Schlüsselbunde gibt es keine abrechenbaren Kosten oder Kontingentlimits. Daher hat ihr Fortbestand keine Auswirkungen auf Kosten oder Produktionslimits.

• Schlüsselmetadaten: Ressourcennamen, Attribute von KMS-Ressourcen wie Zulassungsrichtlinien, Schlüsseltyp, Schlüsselgröße, Schlüsselstatus und alle aus Schlüsseln und Schlüsselbunden abgeleiteten Daten.

• Eine Schlüsselversion steht für das Schlüsselmaterial, das zu einem bestimmten Zeitpunkt mit einem Schlüssel verbunden wird. Die Schlüsselversion ist die Ressource, die das eigentliche Schlüsselmaterial enthält. Die Versionen sind fortlaufend nummeriert und beginnen mit Version 1. Bei einer Schlüsselrotation wird eine neue Schlüsselversion mit neuem Schlüsselmaterial erstellt. Derselbe logische Schlüssel kann im Laufe der Zeit mehrere Versionen haben. Das bedeutet, dass Ihre Daten mit verschiedenen Schlüsselversionen verschlüsselt werden. Symmetrische Schlüssel haben eine primäre Version. Standardmäßig wird die primäre Version für die Verschlüsselung verwendet. Wenn Cloud KMS eine Entschlüsselung mit symmetrischen Schlüsseln vornimmt, wird automatisch erkannt, welche Schlüsselversion für die Entschlüsselung erforderlich ist.

Schlüsselhierarchie

Das folgende Diagramm zeigt die Schlüsselhierarchie und die Umschlagverschlüsselung für Cloud KMS und den internen Schlüsselspeicher von Google. Bei der Umschlagverschlüsselung wird ein Schlüssel mithilfe eines anderen Schlüssels verschlüsselt, um ihn sicher zu speichern oder über einen nicht vertrauenswürdigen Kanal zu übertragen. Alle Schlüssel in diesem Diagramm sind symmetrische Schlüssel.

In der Schlüsselhierarchie werden die Datenblöcke mit einem Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) verschlüsselt. Ein Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) wird verwendet, um den DEK zu verschlüsseln oder zu verpacken. Sie können alle Optionen der Cloud KMS-Plattform (Software, Hardware und externe Back-Ends) zum Steuern des KEK verwenden. KEKs werden in Cloud KMS gespeichert. Schlüsselmaterial verlässt niemals die Cloud KMS-Systemgrenze.

Bei softwaregeschützten Schlüsseln wird der KEK mit einem standortspezifischen KMS-Masterschlüssel verschlüsselt. Der KMS-Masterschlüssel wird im Keystore gespeichert. Für jeden Cloud KMS-Speicherort gibt es in Keystore einen separaten KMS-Masterschlüssel. Jeder Cloud KMS-Server ruft beim Start eine Kopie des KMS-Masterschlüssels als harte Abhängigkeit ab. Außerdem wird jeden Tag eine neue Kopie des KMS-Masterschlüssels abgerufen. Der KMS-Masterschlüssel wird regelmäßig mit dem Keystore-Masterschlüssel im Keystore neu verschlüsselt. Der Keystore-Masterschlüssel wird durch den Root Keystore-Masterschlüssel geschützt.

Bei hardwareschutzbasierten Schlüsseln wird der KEK mit einem standortspezifischen HSM-Verpackungsschlüssel verschlüsselt. Der HSM-Verpackungsschlüssel wird dann mit dem KMS-Masterschlüssel verschlüsselt. Weitere Informationen finden Sie unter Schlüssel erstellen. Bei externen Schlüsseln wird der verpackte DEK mit einem EKM-Verpackungsschlüssel verschlüsselt. Der EKM-Verpackungsschlüssel wird dann mit dem KMS-Masterschlüssel verschlüsselt.

Cloud KMS verwendet den internen Schlüsselverwaltungsdienst von Google, den Keystore, um mit Cloud KMS verschlüsselte Schlüssel zu verpacken. Cloud KMS verwendet dieselbe Root of Trust wie der Keystore. Weitere Informationen zu Keystore finden Sie im Abschnitt „Verschlüsselung ruhender Daten” unter Schlüsselverwaltung.

Betriebliche Einschränkungen

Für Cloud KMS gelten die folgenden Einschränkungen:

• Projekt:Cloud KMS-Ressourcen gehören zu einem Google Cloud-Projekt, ebenso wie alle anderen Google Cloud-Ressourcen. Ihre Cloud KMS-Schlüssel können sich in einem anderen Projekt als die Daten befinden, die durch die Schlüssel geschützt werden. Wenn Sie die Schlüssel im selben Projekt wie die Daten aufbewahren, die durch die Ressourcen geschützt werden, können Sie die Rolle „Inhaber“ aus dem Projekt entfernen, um die Best Practice der Aufgabentrennung zwischen Schlüssel- und Datenadministratoren zu unterstützen.
• Standorte: Innerhalb eines Projekts werden Cloud KMS-Ressourcen an einem Standort erstellt. Weitere Informationen zu Standorten finden Sie unter Geografie und Regionen.
• Konsistenz: Cloud KMS leitet Vorgänge für Schlüssel, Schlüsselbunde und Schlüsselversionen mit strikter Konsistenz oder Eventual Consistency weiter. Weitere Informationen finden Sie unter Konsistenz von Cloud KMS-Ressourcen.

Vom Kunden verwaltete Verschlüsselungsschlüssel

Standardmäßig verschlüsselt Google Cloud alle gespeicherten Kundendaten bei Inaktivität, wobei Google die für die Verschlüsselung verwendeten Schlüssel verwaltet. Für kompatible Google CloudProdukte, in denen Ihre Kundeninhalte dauerhaft gespeichert werden (z. B. Cloud Storage), können Sie stattdessen Cloud KMS verwenden, um vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEKs) zu verwalten. CMEKs sind Verschlüsselungsschlüssel, die Ihnen gehören und mit externen, softwaregeschützten und hardwaregeschützten Schlüsseln verwendet werden können.

Mit CMEKs haben Sie mehr Kontrolle über die Schlüssel, die zum Verschlüsseln inaktiver Daten in kompatiblen Google Cloud Diensten verwendet werden, und können eine kryptografische Grenze um Ihre Daten ziehen. Sie können CMEKs direkt in Cloud KMS verwalten oder die Bereitstellung und Zuweisung mit Autokey automatisieren. Wenn ein Dienst CMEK verwendet, können Ihre Arbeitslasten auf Ressourcen genauso zugreifen wie bei der Verwendung der Standardverschlüsselung.

Mit Cloud KMS können Sie viele Aspekte der Schlüssel kontrollieren (darunter Erstellen, Aktivieren/Deaktivieren, Rotieren und Löschen von Schlüsseln) und angemessene IAM-Berechtigungen für sie verwalten. Cloud KMS enthält mehrere vordefinierte IAM-Rollen, die bestimmte Berechtigungen und Einschränkungen haben und bestimmten Nutzern und Dienstkonten zugewiesen werden können, um eine empfohlene Aufgabentrennung zu erzwingen

Da Cloud KMS die Umschlagverschlüsselung verwendet, ist ein CMEK ein KEK, mit dem die DEKs verschlüsselt werden. Weitere Informationen finden Sie unter Schlüsselhierarchie.

Die CMEK-Rotation funktioniert je nach Ressourcentyp, den der Schlüssel schützt, unterschiedlich. Betrachten Sie hierzu folgende Beispiele:

• In Spanner wird der DEK mit einer neuen Schlüsselversion neu verschlüsselt.
• Bei anderen Ressourcentypen wie Cloud Storage-Buckets werden nur neu erstellte Ressourcen mit der neuen Schlüsselversion verschlüsselt. Das bedeutet, dass verschiedene Versionen eines Schlüssels unterschiedliche Teilmengen von Daten schützen.
• In einigen Szenarien muss die Cloud-Ressource mit der neuen Schlüsselversion neu erstellt werden. Standardmäßig wird beispielsweise in BigQuery ein Tabellenverschlüsselungsschlüssel nicht automatisch rotiert, wenn der mit der Tabelle verknüpfte Cloud KMS-Schlüssel rotiert wird. Vorhandene BigQuery-Tabellen verwenden weiterhin die Schlüsselversion, mit der sie erstellt wurden.

Weitere Informationen zur Schlüsselrotation finden Sie in der Dokumentation zum jeweiligen Produkt.

CMEK-Organisationsrichtlinien bieten mehr Kontrolle darüber, wie CMEK in Ihren Projekten verwendet wird. Mit diesen Richtlinien können Sie die Dienste und Projekte steuern, die Schlüssel enthalten, die für CMEK zulässig sind, sowie die Schutzstufe für die Schlüssel.

Google Cloud unterstützt CMEKs für viele Dienste, einschließlich Cloud Storage, BigQuery und Compute Engine. Eine vollständige Liste der CMEK-Einbindungen und CMEK-konformen Dienste finden Sie unter CMEK-Integrationen. Google arbeitet kontinuierlich an der CMEK-Einbindung für weitere Google Cloud -Produkte.

Cloud KMS Autokey

Mit Autokey können Sie den CMEK-Bereitstellungsprozess optimieren. Bei der manuellen CMEK-Bereitstellung muss ein Cloud KMS-Administrator die Arten von Schlüsselbunden, Schlüsseln und Dienstkonten planen, bevor sie benötigt werden, und sich mit Entwicklern abstimmen, um Schlüssel bereitzustellen. Mit Autokey delegiert der Cloud KMS-Administrator seine Berechtigungen an den Cloud KMS-Dienst-Agent im Projekt. Wenn Sie Autokey aktivieren, kann ein Entwickler einen Schlüssel von Cloud KMS anfordern und der Dienst-Agent stellt den richtigen Schlüssel für die Absicht des Entwicklers bereit. Mit Autokey sind Schlüssel bei Bedarf verfügbar, konsistent und entsprechen den Branchenstandards.

Mit Autokey werden Schlüsselringe, Schlüssel und Dienstkonten bei Bedarf bereitgestellt und zugewiesen, wenn Entwickler Cloud-Ressourcen erstellen. Dabei wird die Aufgabentrennung berücksichtigt. Die Schlüsselbereitstellung und ‑zuweisung erfolgt gemäß den Branchenstandards und Empfehlungen für Datensicherheit, einschließlich der folgenden:

• HSM-Schutzniveau:Mit Autokey erstellte Schlüssel sind immer HSM-Schlüssel und werden daher im Cloud HSM-Backend gespeichert. Es handelt sich um AES‑256‑GCM-Verschlüsselungsschlüssel.
• Aufgabentrennung:Um die Aufgabentrennung aufrechtzuerhalten, unterscheiden sich die Identitäten, die den Schlüssel zum Verschlüsseln und Entschlüsseln verwenden können, von den Identitäten, die den Schlüssel verwalten (einschließlich seiner Rotation, Vernichtung oder Statusänderung).
• Schlüsselrotation:Schlüssel werden jährlich rotiert.
• Schlüssel am selben Standort wie Ressourcen:Der Schlüssel befindet sich am selben Standort wie die Ressource, die er schützt.
• Schlüsselspezifität:Die Spezifität des Schlüssels ist für den Ressourcentyp, den der Schlüssel schützt, auf Ressourcentypbasis angemessen. Spezifität bedeutet, dass Sie die Ressourcentypen der einzelnen Dienste nicht manuell überprüfen und entscheiden müssen, wie viele Ressourcentypen ein einzelner Schlüssel schützen soll.

Mit Autokey angeforderte Schlüssel funktionieren identisch mit anderen Cloud HSM-Schlüsseln mit denselben Einstellungen. Autokey vereinfacht die Verwendung von Terraform, da keine Infrastruktur als Code mit erhöhten Berechtigungen zum Erstellen von Schlüsseln ausgeführt werden muss. Autokey ist an allenGoogle Cloud Standorten verfügbar, an denen Cloud HSM verfügbar ist.

Autokey ist nur für bestimmte Google Cloud Ressourcen verfügbar. Weitere Informationen finden Sie unter Übersicht: Autokey.

Architektur und Komponenten der Cloud KMS-Plattform

Die Cloud KMS-Plattform unterstützt mehrere kryptografische Algorithmen und bietet Methoden zum Verschlüsseln und digitalen Signieren mit externen, hardware- und softwaregeschützten Schlüsseln. Die Cloud KMS-Plattform ist in Identity and Access Management (IAM) und Cloud-Audit-Logs eingebunden. So können Sie Berechtigungen für einzelne Schlüssel verwalten und deren Verwendung prüfen.

Das vorstehende Diagramm zeigt die folgenden Hauptkomponenten der Cloud KMS-Plattform.

• Administratoren greifen über die Cloud Console oder die Google Cloud CLI auf Schlüsselverwaltungsdienste zu.

• Anwendungen greifen auf Schlüsselverwaltungsdienste zu, indem sie die REST API, gRPC oder Clientbibliotheken implementieren. Anwendungen können Google-Dienste verwenden, die für CMEK aktiviert sind. CMEK verwendet wiederum die Cloud Key Management Service API. Wenn Ihre Anwendung PKCS #11 verwendet, können Sie sie mit Cloud KMS über die Bibliothek für PKCS #11 integrieren.

• Mit der Cloud KMS API können Sie Software-, Hardware- oder externe Schlüssel verwenden. Sie können softwaregeschützte und hardwaregeschützte Schlüssel über den Cloud KMS-Dienstendpunkt generieren und verwalten. Sowohl software- als auch hardwaregeschützte Schlüssel verwenden als Schutzmaßnahme die redundanten Sicherungen von Google.

• Wenn Sie hardwaregeschützte Schlüssel verwenden, werden die Schlüssel in FIPS 140-2 Level 3-zertifizierten HSMs inGoogle Cloud gespeichert. Weitere Informationen zu unserer Zertifizierung finden Sie unter Zertifikat Nr. 4399.

• Cloud KMS verwendet den internen Datenspeicher von Google zum Speichern von verschlüsseltem Kundenschlüsselmaterial. Dieser Datenspeicher ist hochverfügbar und unterstützt viele der geschäftskritischen Systeme von Google. Weitere Informationen finden Sie unter Datenspeicherschutz.

• In regelmäßigen Abständen sichert das unabhängige Sicherungssystem den gesamten Datenspeicher sowohl im Onlinespeicher als auch im Archivspeicher. Mit diesem Backup kann Cloud KMS die Ziele für die Datenbeständigkeit erreichen. Weitere Informationen finden Sie unter Datenspeicherschutz.

FIPS 140-2-Validierung

Kryptografische Vorgänge für Cloud KMS werden von FIPS 140-2-validierten Modulen ausgeführt. Schlüssel mit der Schutzstufe SOFTWARE und die damit durchgeführten kryptografischen Vorgänge entsprechen FIPS 140-2 Level 1. Für diese kryptografischen Vorgänge wird BoringCrypto verwendet, eine von Google verwaltete Open-Source-Kryptografiebibliothek. Schlüssel mit der Schutzstufe HSM und die damit durchgeführten kryptografischen Vorgänge entsprechen FIPS 140-2 Level 3.

Sicherheit von Schlüsselmaterial

In Cloud KMS wird das Schlüsselmaterial sowohl bei Inaktivität als auch während der Übertragung immer verschlüsselt. Schlüsselmaterial wird nur in folgenden Fällen entschlüsselt:

• Wenn der Kunde es verwendet.
• Wenn der interne Schlüssel von Google zum Schutz des Kundenschlüsselmaterials rotiert oder auf Integrität geprüft wird.

Kundenanfragen an Cloud KMS werden während der Übermittlung mithilfe von TLS zwischen dem Kunden und dem Google Front End (GFE) verschlüsselt.

Sämtliche Cloud KMS-Jobs werden sowohl innerhalb als auch zwischen Google-Rechenzentren authentifiziert.

Mit den Richtlinien von Google wird sichergestellt, dass Jobs nur Quellcode verwenden, der auf verifizierbare Weise erstellt, getestet und überprüft wurde. Die Binärautorisierung für Borg (BAB) setzt diese Richtlinie auf operativer Ebene durch.

Cloud KMS API-Jobs können auf Schlüsselmetadaten (beispielsweise auf die Zulassungsrichtlinie oder den Rotationszeitraum) zugreifen. Google-Mitarbeiter mit einem gültigen dokumentierten geschäftlichen Grund (etwa ein Fehler oder ein Kundenproblem) können ebenfalls auf Schlüsselmetadaten zugreifen. Diese Zugriffsereignisse werden intern protokolliert. Logs zu Daten, die von Access Transparency abgedeckt werden, stehen berechtigten Kunden ebenfalls zur Verfügung.

Entschlüsseltes Schlüsselmaterial kann nicht über die API-Oberfläche oder eine andere Benutzeroberfläche exportiert oder angezeigt werden. Kein Google-Mitarbeiter hat Zugriff auf unverschlüsseltes Kundenschlüsselmaterial. Schlüsselmaterial wird zusätzlich mit einem Masterschlüssel in Keystore verschlüsselt, auf den keine Person direkt zugreifen kann. In einem HSM wird von Cloud KMS API-Jobs nie auf Schlüsselmaterial in einem entschlüsselten Zustand zugegriffen.

Datenspeicherschutz

Der Datenspeicher für Cloud KMS ist hochverfügbar, dauerhaft und geschützt.

Verfügbarkeit: Cloud KMS verwendet den internen Datenspeicher von Google, der hochverfügbar ist und eine Reihe von geschäftskritischen Systemen von Google unterstützt.

Langlebigkeit: Cloud KMS verwendet authentifizierte Verschlüsselung, um Kundenschlüsselmaterial im Datenspeicher zu speichern. Außerdem werden alle Metadaten mithilfe eines Hash-basierten Nachrichten-Authentifizierungscodes (HMAC) authentifiziert, um sicherzustellen, dass sie nicht bei Inaktivität geändert oder korrumpiert wurden. Jede Stunde scannt ein Batchjob alle Schlüsselmaterialien und Metadaten und verifiziert, dass die HMACs gültig sind und das Schlüsselmaterial erfolgreich entschlüsseln kann. Wenn Daten fehlerhaft sind, werden umgehend Cloud KMS-Entwickler informiert, damit sie geeignete Maßnahmen ergreifen können.

Cloud KMS verwendet verschiedene Arten von Back-ups für den Datenspeicher:

• Standardmäßig verwaltet der Datenspeicher den Änderungsverlauf für jede Zeile vier Tage lang. Im Notfall kann dieser Zeitraum verlängert werden, damit mehr Zeit zur Behebung von Problemen vorliegt.
• Jede Stunde zeichnet der Datenspeicher einen Snapshot auf. Dieser kann validiert und bei Bedarf zur Wiederherstellung verwendet werden. Die Snapshots werden vier Tage lang aufbewahrt.
• Täglich wird eine vollständige Sicherung auf ein Laufwerk und in den Archivierungsspeicher kopiert.

Das Cloud KMS-Team hat dokumentierte Verfahren zur Wiederherstellung von Back-ups, um Datenverlust bei einem Notfall auf Dienstseite zu minimieren.

Sicherungen Cloud KMS-Datenspeicher-Back-ups befinden sich in der zugehörigen Google Cloud Region. Diese Back-ups werden bei Inaktivität alle verschlüsselt. Der Zugriff auf Daten in Back-ups wird anhand von Zugriffsberechtigungen (z. B. eine Ticketnummer, die Sie beim Google-Support eingereicht haben) gesteuert und der menschliche Zugriff wird inAccess Transparency-Logs erfasst.

Schutz: Auf der Cloud KMS-Anwendungsebene wird Schlüsselmaterial vor dem Speichern verschlüsselt. Entwickler mit Zugriff auf den Datenspeicher haben keinen Zugriff auf Kundenschlüsselmaterial in Klartext. Außerdem werden alle vom Datastore verwalteten Daten verschlüsselt, bevor sie in den permanenten Speicher geschrieben werden. Daher ist der Zugriff auf zugrunde liegende Speicherebenen, einschließlich Festplatten oder Archivspeicher, nicht möglich, ohne Zugriff auf die Datenspeicherverschlüsselungsschlüssel, die im Keystore gespeichert sind.

Rotationsrichtlinie. Die Schlüsselrotation ist Teil der allgemeinen Best Practices für die Verwaltung von Schlüsselmaterial. Es gibt eine Rotationsrichtlinie für die Schlüssel, die zum Schutz von Cloud KMS-Datenspeichern verwendet werden. Es wird außerdem eine Schlüsselrotationsrichtlinie auf die Keystore-Masterschlüssel angewendet, welche die Cloud KMS-Masterschlüssel verpacken. Der Keystore-Masterschlüssel hat einen Geheimtext mit einem geplanten Höchstalter von 90 Tagen und einem Höchstalter von einem Tag für von Kunden gespeicherte Schlüssel. Cloud KMS aktualisiert die KMS-Masterschlüssel in KMS-Aufgaben alle 24 Stunden und verschlüsselt alle Kundenschlüssel jeden Monat neu.

Datenstandort. Die Daten, die einem Cloud KMS-Datenspeicher zugrunde liegen, verbleiben ausschließlich in der Google Cloud -Region, der diese Daten zugeordnet sind. Dies gilt auch für Standorte, die als Multi-Regionen definiert sind, beispielsweise die Multi-Region us.

Schlüsselverfügbarkeit nach dem Erstellen

In Cloud KMS kann ein Schlüssel sofort verwendet werden, nachdem der Cloud KMS-Datenspeicher die Transaktion übergeben hat, die den Schlüssel erstellt, und die Speicherebene die Erstellung quittiert hat.

Schlüssel-Backends und Schutzniveaus

Wenn Sie einen Schlüssel mit Cloud KMS erstellen, können Sie ein Schutzniveau auswählen, um zu bestimmen, welches Schlüssel-Backend den Schlüssel erstellt und alle zukünftigen kryptografischen Vorgänge für diesen Schlüssel ausführt. Die Backends werden in der Cloud KMS API als die folgenden Schutzstufen angezeigt:

• SOFTWARE: Gilt für Schlüssel, die von einem Softwaresicherheitsmodul zwecks Ausführung kryptografischer Vorgänge entpackt werden können.
• HSM: Gilt für Schlüssel, die nur von HSMs entpackt werden können, die alle kryptografischen Vorgänge mit den Schlüsseln ausführen.
• EXTERNAL oder EXTERNAL-VPC: Gelten für externe Schlüsselmanager (EKM). Mit EXTERNAL-VPC können Sie den EKM über ein VPC-Netzwerk mit Google Cloud verbinden.

Cloud KMS-Software-Backend: SOFTWARE-Schutzniveau

Das Schutzniveau SOFTWARE gilt für Schlüssel, deren kryptografische Vorgänge in Software ausgeführt werden. In diesem Abschnitt wird detailliert beschrieben, wie diese Stufe implementiert wird.

Algorithmus-Implementierungen

Für Softwareschlüssel verwendet Cloud KMS das BoringCrypto-Modul der BoringSSL von Google für alle kryptografischen Aufgaben, die in diesem Zusammenhang anfallen. Das BoringCrypto-Modul ist gemäß FIPS 140-2 validiert. Die Cloud KMS-Binärdatei basiert auf den kryptografischen Primitiven dieses Moduls, die gemäß FIP 140-2 Level 1 validiert sind. Die aktuellsten Algorithmen, die dieses Modul beinhaltet, sind unter Schlüsselzwecke und Algorithmen aufgeführt. Sie umfassen Verschlüsselungs-, Entschlüsselungs- und Signiervorgänge mit dem symmetrischen kryptografischen AES256-GCM-Schlüssel sowie den asymmetrischen kryptografischen RSA 2048-, RSA 3072-, RSA 4096-, EC P256- und EC P384-Schlüsseln.

Generierung von zufälligen Zahlen und Entropie

Beim Generieren von Verschlüsselungsschlüsseln verwendet Cloud KMS BoringSSL. FIPS 140-2 erfordert die Verwendung eigener PRNGs (auch als DRBGs bezeichnet). In BoringCrypto verwendet Cloud KMS ausschließlich CTR-DRBG mit AES-256. Dies liefert Ausgaben für RAND_bytes, die primäre Schnittstelle, über die das restliche System zufällige Daten erhält. Dieser PRNG wird aus dem RNG des Linux-Kernels geseedet, der wiederum aus mehreren unabhängigen Entropiequellen geseedet wird. Hierzu zählen entropische Ereignisse aus der Rechenzentrumsumgebung, beispielsweise engmaschige Messungen der Zugriffszeiten bei Festplatten und der Eingangszeiten zwischen Paketen sowie je nach Verfügbarkeit der RDRAND-Befehl von Intel. Weitere Informationen zum Verhalten des Zufallszahlengenerators für BoringSSL (FIPS-konformer Modus) finden Sie unter RNG-Design.

Cloud HSM-Back-End: HARDWARE-Schutzniveau

Cloud HSM stellt auf Hardware geschützte Schlüssel für Cloud KMS bereit. Sie können kryptografische Schlüssel verwenden, die durch vollständig verwaltete FIPS 140-2 Level 3-HSMs in Google-Rechenzentren geschützt sind. Cloud HSM ist hochverfügbar und bietet eine elastische Skalierung wie Cloud KMS. Sie können mit derselben API und denselben Clientbibliotheken wie Cloud KMS auf das Cloud HSM-Backend zugreifen. Weitere Informationen zum Cloud HSM-Backend finden Sie unter Cloud HSM-Architektur.

Cloud EKM: Schutzniveau „EXTERN”

Mit Cloud EKM können Sie Daten mit Verschlüsselungsschlüsseln verschlüsseln, die sich nicht in der Cloud befinden und unter Ihrer Kontrolle bleiben.

Schlüssel mit den Schutzstufen EXTERNAL und EXTERNAL_VPC werden in einem externen Schlüsselverwaltungssystem gespeichert und verwaltet. Weitere Informationen finden Sie unter Referenzarchitekturen für Cloud EKM.

Prozess der Schlüsselerstellung

Das folgende Diagramm veranschaulicht den Prozess der Schlüsselerstellung für die verschiedenen Schlüssel-Backends und Schutzstufen.

Der Schlüsselerstellungsprozess umfasst Folgendes:

1. Ein Nutzer fordert Cloud KMS über die Cloud KMS API auf, einen Schlüssel zu erstellen. Diese Anfrage enthält das Schutzniveau (ob der Schlüssel softwaregeschützt, hardwaregeschützt oder extern ist).
2. Cloud KMS prüft die Nutzeridentität und ob der Nutzer die Berechtigung zum Erstellen des Schlüssels hat.
3. Der Schlüssel wird so generiert:
   • Bei softwaregeschützten Schlüsseln generiert Cloud KMS den Kundenschlüssel.
   • Bei hardwareschutzbasierten Schlüsseln sendet Cloud KMS eine Anfrage an Cloud HSM. Cloud HSM sendet die Anfrage an das HSM, um einen neuen Schlüssel zu generieren. Das HSM generiert einen Kundenschlüssel und verschlüsselt (verpackt) diesen Schlüssel mit dem regionalen Verpackungsschlüssel des HSM. Cloud HSM sendet den verpackten Schlüssel an Cloud KMS zurück.
   • Bei externen Schlüsseln sendet Cloud KMS eine Anfrage an Cloud EKM. Cloud EKM sendet die Anfrage an den externen Schlüsselmanager, um einen neuen Schlüssel zu generieren. Das EKM generiert einen neuen Schlüssel und verschlüsselt ihn mit dem EKM-Umschlüssel. Cloud EKM sendet den umschlossenen Schlüssel zurück an Cloud KMS.
4. Cloud KMS verschlüsselt den verpackten Kundenschlüssel mit dem KMS-Masterschlüssel und sendet ihn zur Speicherung an den KMS-Datenspeicher.
5. Cloud KMS sendet eine Erfolgsantwort mit dem vollständigen URI für die Schlüsselversion an den Nutzer.

Schlüsselimport

Möglicherweise möchten Sie Ihre eigenen Schlüssel, die Sie lokal oder in einem EKM erstellt haben, in Ihre Cloud-Umgebung importieren. Dies könnte beispielsweise zutreffen, wenn gemäß Ihrer Richtlinien die zur Verwendung von Cloud-Daten verwendeten Schlüssel auf eine spezifische Weise oder in einer bestimmten Umgebung generiert werden müssen. Durch Schlüsselimport können Sie diese Schlüssel importieren und die geltenden Richtlinien einhalten. Sie können auch asymmetrische Schlüssel importieren, um Ihre Signierungsmöglichkeiten auf die Cloud auszuweiten.

Im Rahmen des Schlüsselimports generiert Cloud KMS mithilfe einer der unterstützten Importmethoden einen öffentlichen Verpackungsschlüssel, bei dem es sich um ein öffentliches/privates Schlüsselpaar handelt. Wenn Sie Ihr Schlüsselmaterial mit diesem Verpackungsschlüssel verschlüsseln, ist das Schlüsselmaterial bei der Übertragung geschützt.

Mit dem öffentlichen Verpackungsschlüssel verschlüsseln Sie den Schlüssel, der in den Client importiert werden soll. Der private Schlüssel, der dem öffentlichen Schlüssel entspricht, wird in Google Cloudgespeichert und zum Entpacken des öffentlichen Schlüssels verwendet, nachdem er dasGoogle Cloud -Projekt erreicht hat. Die von Ihnen gewählte Importmethode bestimmt den Algorithmus, mit dem der Verpackungsschlüssel erstellt wird. Nachdem Ihr Schlüsselmaterial verpackt wurde, können Sie es in einen neuen Schlüssel oder eine neue Schlüsselversion auf Cloud KMS importieren.

Sie können importierte Schlüssel mit der Schutzstufe HSM oder SOFTWARE verwenden. Für Cloud HSM ist der private Schlüssel des Verpackungsschlüssels nur innerhalb von Cloud HSM verfügbar. Durch die Beschränkung des privaten Teils des Schlüssels auf Cloud HSM wird verhindert, dass Google Ihr Schlüsselmaterial außerhalb von Cloud HSM entpackt.

Lebenszyklus einer Cloud KMS-Anfrage

In diesem Abschnitt wird der Lebenszyklus einer Cloud KMS-Anfrage beschrieben. Dabei wird auch auf das Löschen von Schlüsselmaterial eingegangen. Das folgende Diagramm zeigt, wie ein Client Zugriff auf Cloud KMS-Dienstinstanzen in us-east1 und us-west1 anfordert und wie die Anfragen über das Google Front End (GFE) weitergeleitet werden.

Dieser Lebenszyklus umfasst folgende Schritte:

1. Mitarbeiter in Ihrer Organisation oder ein Job, der im Namen Ihrer Organisation ausgeführt wird, stellen eine Anfrage an den Cloud KMS-Dienst, https://cloudkms.googleapis.com. DNS löst diese Adresse in eine Anycast-IP-Adresse des GFE auf.
2. Das GFE bietet öffentliches IP-Hosting des öffentlichen DNS-Namens, Schutz vor DoS-Angriffen (Denial of Service) und die Beendigung von TLS-Verbindungen. Wenn Sie eine Anfrage senden, wird diese in der Regel an ein GFE in Ihrer Nähe geroutet, egal für welchen Standort die Anfrage bestimmt ist. GFEs verwalten die TLS-Verhandlung und bestimmen mithilfe der Anfrage-URL und der Parameter, welcher Global Software Load Balancer (GSLB) die Anfrage routet.
3. Für jede Cloud KMS-Region existiert ein eigenes GSLB-Ziel. Wenn die Anfrage bei einem GFE in us-east1 eintrifft und für us-west1 bestimmt ist, wird die Anfrage zwischen den Rechenzentren für us-east1 und us-west1 geroutet. Sämtliche Kommunikation zwischen Rechenzentren wird während der Übertragung mithilfe von ALTS verschlüsselt, wodurch GFE- und Cloud KMS-Jobs sich gegenseitig authentifizieren.
4. Wenn die Anfrage den Cloud KMS-Job erreicht, wird sie zuerst von einem Framework verarbeitet, das einen großen Teil der Arbeitslast verwaltet, die alleGoogle Cloud -Dienste gemeinsam haben. Dieses Framework authentifiziert das Konto und führt eine Reihe von Tests durch, um Folgendes zu verifizieren:
   • Das Konto verfügt über gültige Anmeldedaten und kann authentifiziert werden.
   • Das Projekt hat die Cloud KMS API aktiviert und weist ein gültiges Abrechnungskonto auf.
   • Das Kontingent reicht aus, um die Anfrage auszuführen.
   • Das Konto ist auf der Zulassungsliste, um die relevanteGoogle Cloud -Region zu verwenden.
   • Die Anfrage wird von VPC Service Controls nicht abgelehnt.
5. Wenn diese Tests erfolgreich durchgeführt wurden, leitet das Framework die Anfrage und die Anmeldedaten an Cloud KMS weiter. Cloud KMS parst die Anfrage, um zu bestimmen, auf welche Ressourcen zugegriffen wird, und prüft dann bei IAM nach, ob der Nutzer autorisiert ist, diese Anfrage zu senden. IAM gibt auch an, ob die Anfrage in Audit-Logs protokolliert werden sollte. Wenn Key Access Justifications aktiviert ist, wird eine Begründungsbenachrichtigung gesendet, die Sie genehmigen müssen.
6. Nachdem die Anfrage authentifiziert und autorisiert wurde, ruft Cloud KMS seine regionalen Back-Ends auf, um die angeforderte Ressource abzurufen. Nachdem die Ressource abgerufen wurde, wird Ihr Schlüsselmaterial zur Verwendung entschlüsselt.
7. Mit dem Schlüsselmaterial führt Cloud KMS dann den kryptografischen Vorgang aus und leitet die verpackte Version des Schlüssels an das Cloud KMS-Software-Backend, das Cloud HSM-Backend oder das Cloud EKM-Backend je nach Schutzniveau des Schlüssels weiter.
8. Nach Abschluss des kryptografischen Vorgangs wird die Antwort an Sie über die gleiche Art von GFE-to-KMS-Kanal gesendet wie schon bei der Anfrage.
9. Wenn die Antwort zurückgegeben wird, löst Cloud KMS auch die folgenden Ereignisse asynchron aus:
   • Audit- und Anfragelogs werden gefüllt und in die Warteschlange geschrieben.
   • Zu Abrechnungs- und Verwaltungszwecken werden Berichte gesendet.
   • Wenn die Anfrage die Metadaten einer Ressource aktualisiert hat, wird die Änderung über Aktualisierungen des Batchjobs an Cloud Asset Inventory gesendet.

End-to-End-Datenintegrität

Mit Cloud KMS können Sie Prüfsummen für Schlüssel und Schlüsselmaterial berechnen, um sicherzustellen, dass sie nicht beschädigt sind. Diese Prüfsummen schützen Sie vor Datenverlust, der durch Hardware- oder Softwarefehler verursacht werden kann. Mit Helper-Bibliotheken können Sie die Schlüsselintegrität überprüfen. Sie können Helper-Bibliotheken verwenden, um die Schlüsselintegrität zu überprüfen, indem Sie Cloud KMS Prüfsummen zur Verfügung stellen, die vom Server überprüft werden. Außerdem können Sie mit diesen Bibliotheken Prüfsummen empfangen, um Antwortdaten auf dem Client zu überprüfen.

Die End-to-End-Datenintegrität schützt Ihre Umgebung vor Bedrohungen wie den folgenden:

• Beschädigung während der Übertragung; z. B. zwischen dem Senden von Daten und dem Schutz durch TLS.
• Probleme in Zwischen-Proxys zwischen Ihrem Endpunkt und KMS (z. B. für eingehende Anfragen)
• Fehlerhafte kryptografische Vorgänge, Beschädigung des Maschinenspeichers oder Beschädigung des HSM in der Cloud KMS-Architektur.
• Beschädigung bei der Kommunikation mit einem externen EKM

Weitere Informationen finden Sie unter End-to-End-Datenintegrität prüfen.

Löschen von Schlüsselmaterial

Da Schlüsselmaterial als Kundendaten zu betrachten ist, gilt der im Artikel Datenlöschung in Google Cloud beschriebene Ansatz auch für Cloud KMS. Schlüsselmaterial wird auf Anfrage gelöscht, wenn der Zeitraum Zum Löschen vorgemerkt abgelaufen ist und die Sicherungen abgelaufen sind. Das Schlüsselmaterial, das nach Ablauf des Zeitraums „Zum Löschen vorgemerkt“ noch in Sicherungen vorhanden ist, kann nur für die regionale Notfallwiederherstellung und nicht zum Wiederherstellen einzelner Schlüssel verwendet werden. Für Kopien importierter Schlüssel, die sich außerhalb der Kontrolle von Cloud KMS befinden, wird dieser Prozess nicht garantiert.

Schlüssel in Cloud KMS werden standardmäßig 30 Tage im Status Zum Löschen vorgemerkt (vorläufig gelöscht) angezeigt, bevor das Schlüsselmaterial logisch aus dem System gelöscht. Sie können diese Dauer ändern. Weitere Informationen finden Sie unter Variablendauer des Status Zum Löschen vorgemerkt.

Obwohl Schlüsselmaterial gelöscht wird, können Schlüssel und Schlüsselbunde nicht gelöscht werden. Obwohl Schlüsselversionen ebenfalls nicht gelöscht werden können, kann Schlüsselversionsmaterial gelöscht werden, damit die Ressourcen nicht mehr verwendet werden können. Für Schlüssel und Schlüsselbunde gibt es keine abrechenbaren Kosten oder Kontingentlimits. Daher hat ihr Fortbestand keine Auswirkungen auf Kosten oder Produktionslimits.

Sobald eine Schlüsselversion zum Löschen vorgesehen ist, steht sie nicht mehr für kryptografische Vorgänge zur Verfügung. Während des Zeitraums, in dem das Löschen aussteht, können Sie die Schlüsselversion wiederherstellen, damit sie nicht gelöscht wird.

Wenn Sie einen importierten Schlüssel versehentlich löschen, können Sie ihn neu importieren. Weitere Informationen finden Sie unter Einen gelöschten Schlüssel noch einmal importieren.

So vermeiden Sie das versehentliche Löschen eines Schlüssels:

• Legen Sie die Einschränkung Mindestwert für die geplante Dauer für das Löschen pro Schlüssel auf einen längeren Zeitraum fest. Mit dieser Einschränkung wird die Mindestdauer für den Zeitraum zum Löschen geplant für neue Schlüssel definiert.
• Erzwingen Sie die Einschränkung Löschen von Schlüsseln auf deaktivierte Schlüssel beschränken, damit nur deaktivierte Schlüssel gelöscht werden können. Weitere Informationen finden Sie unter Deaktivierung von Schlüsseln vor dem Löschen erzwingen.
• Erstellen Sie eine benutzerdefinierte KMS-Rolle, die nicht die Berechtigung cloudkms.cryptoKeyVersions.destroy enthält.
• Ändern Sie das Feld destroy_scheduled_duration in einen längeren Zeitraum.

• Benachrichtigungen für wichtige Löschereignisse überwachen und hinzufügen. Erstellen Sie beispielsweise den folgenden Cloud Logging-Filter:

    resource.type="cloudkms_cryptokeyversion"
    protoPayload.methodName="DestroyCryptoKeyVersion"
  

• Erstellen Sie Prozesse, die den Schlüssel einige Tage vor dem Löschen deaktivieren.

Abhängigkeiten von der Google-Infrastruktur

Elemente der Cloud KMS-Plattform werden als Borg-Produktionsjobs ausgeführt. Borg ist der umfangreiche Clustermanager von Google für die Verarbeitung von API-Bereitstellungsjobs und Batchjobs.

Informationen zur Sicherheit unserer physischen Infrastruktur und Produktionsinfrastruktur finden Sie in der Übersicht über das Sicherheitsdesign der Infrastruktur von Google.

API-Bereitstellungsjobs in Cloud KMS

API-Bereitstellungsjobs in Cloud KMS sind Borg-Produktionsjobs, die für Kundenanfragen zur Verwaltung und Verwendung ihrer Schlüssel eingesetzt werden. API-Bereitstellungsjobs in Cloud KMS verarbeiten auch zurückgestellte Aktionen von Kundenanfragen, z. B. Schlüssel nach Zeitplan rotieren, asymmetrische Schlüssel erstellen und Schlüssel importieren. Diese Bereitstellungsjobs werden in jederGoogle Cloud -Region ausgeführt, in der Cloud KMS verfügbar ist. Jeder Job ist einer einzigen Region zugewiesen und so konfiguriert, dass er nur auf Daten aus Systemen zugreift, die sich geografisch in der zugewiesenenGoogle Cloud -Region befinden.

Batchjobs in Cloud KMS

Die Cloud KMS-Plattform verwaltet auch eine Reihe von Batchjobs, die nach verschiedenen Zeitplänen als Borg-Produktionsjobs ausgeführt werden. Batchjobs sind regionsspezifisch und aggregieren nur Daten aus der zugehörigen Google Cloud-Region. Sie werden auch nur in dieser Region ausgeführt. Diese Jobs führen folgende Aufgaben aus:

• Aktive Schlüssel für die Kundenabrechnung zählen.
• Ressourcen aus der öffentlichen Protokollzwischenspeicher-API für Cloud KMS aggregieren und die Metadaten an Cloud Asset Inventory weiterleiten. Ressourcen sind in diesem Zusammenhang jegliche Ressourcen, die von Cloud KMS verwaltet werden, beispielsweise Schlüssel und Schlüsselbunde.
• Alle Ressourcen und Berichtsinformationen für Geschäftsanalysen aggregieren.
• Erstellen Sie einen Daten-Snapshot für Hochverfügbarkeit.
• Prüfen, ob alle im zugrunde liegenden Datenspeicher gespeicherten Daten unbeschädigt sind.
• Wiederholtes Verschlüsseln des Kundenschlüsselmaterials, wenn der KMS-Masterschlüssel rotiert wird.

Schlüssel-Snapshotter in Cloud KMS

Die Cloud KMS-Plattform verwaltet einen redundanten Datenspeicher in jeder Instanz eines gemeinsam genutzten Dienstes, in dem die Aufgaben des Cloud KMS API-Servers gehostet werden. So kann Hochverfügbarkeit aufrechterhalten werden. Jeder gemeinsam genutzter Dienst stellt seine eigene Instanz des Snapshotter-Dienstes bereit. Dank dieser Redundanz sind die Dienste in hohem Maße unabhängig, sodass ein Ausfall in einer Zone nur wenige Auswirkungen auf andere Zonen hat. Wenn der Cloud KMS API-Job einen kryptografischen Vorgang ausführen muss, fragt er den primären Datenspeicher sowie die lokalen Snapshotter-Jobs parallel ab. Wenn der primäre Datenspeicher langsam oder nicht verfügbar ist, kann die Antwort aus einem Snapshot bereitgestellt werden, sofern dieser nicht älter als zwei Stunden ist. Snapshots werden als Ausgabe eines Batchjobs erstellt, der für jede Region kontinuierlich ausgeführt wird. Snapshots befinden sich in der Cloud-Region, die dem Schlüsselmaterial zugeordnet ist.

Client-Server-Kommunikation

Google verwendet Application Layer Transport Security (ALTS), um Sicherheit bei Client-Server-Kommunikation zu ermöglichen, die den RPC-Mechanismus (Remote-Prozeduraufruf) von Google verwendet.

Weitere Informationen finden Sie unter Authentifizierung, Integrität und Verschlüsselung von Dienst zu Dienst.

Betriebsumgebung der Cloud KMS-Plattform

Die Betriebsumgebung für die Cloud KMS-Plattform umfasst Richtlinien für Datenspeicherung und -sicherheit, Zugriffsbeschränkungen und Strategien zur Risikominderung, die dazu dienen, Verlässlichkeit, Langlebigkeit und Verfügbarkeit zu optimieren und gleichzeitig Schlüsselmaterial zu schützen. In diesem Abschnitt werden die Betriebsstruktur des Dienstes, die Verantwortlichkeiten des Betriebsteams, die Authentifizierungsmechanismen und die Audit- und Logging-Protokolle beschrieben. Dieser Abschnitt gilt sowohl für Funktionen von auf Software als auch auf Hardware gesicherten Schlüsseln.

Softwareentwickler, Site Reliability Engineers und Systemoperatoren

Softwareentwickler sind für die Zusammenarbeit mit anderen Beteiligten wie Produktmanagern und Site Reliability Engineers (SREs) verantwortlich, damit sie das System entwickeln und einen Großteil des Codes und der Tests für den Cloud KMS-Dienst schreiben können. Der Code beinhaltet den Hauptjob für Kundenanfragen sowie einen sekundären Job für Aktivitäten wie Datenreplikation und Abrechnung. SREs können auch Code schreiben. Allerdings haben Softwareentwickler und SREs unterschiedliche Aufgaben. SREs sind primär dafür zuständig, die Produktionsumgebung für Cloud KMS-Jobs zu verwalten. SREs messen und erreichen Verlässlichkeit durch Engineering und operative Abläufe.

Systemoperatoren sind für den Build- und Release-Prozess sowie für Monitoring, Benachrichtigung und Kapazitätenplanung für Cloud KMS verantwortlich. Sie sind die Ersten, die auf Kundenprobleme und Ausfälle bei Cloud KMS reagieren. Beispielsweise nutzen Systemoperatoren Tools und Automatisierung, um manuelle Systemaufgaben zu minimieren, sodass sie sich auf Aufgaben mit langfristigem Wert konzentrieren können.

Die Aufgaben für Systemoperatoren sind in Standardbetriebsverfahren definiert. Systemoperatoren greifen bei der Ausführung von Aufgaben nicht auf Kundenschlüsselmaterial zu.

Regionalität von Cloud KMS-Ressourcen

Sie können Cloud KMS-Ressourcen an einem von vier Google Cloud -Standorten erstellen, um die wichtigsten Anforderungen an den Datenstandort zu erfüllen:

• Ein regionaler Standort besteht aus Zonen in einem bestimmten geografischen Bereich, z. B. Iowa.
• Ein Dual-Region-Standort besteht aus Zonen an zwei geografischen Orten, z. B. Iowa und South Carolina.
• Ein multiregionaler Standort besteht aus Zonen, die über einen allgemeinen geografischen Bereich verteilt sind, z. B. die Vereinigten Staaten.
• Der globale Standort besteht aus Zonen, die über die ganze Welt verteilt sind. Wenn Sie Ihre Cloud KMS-Ressourcen am globalen Standort erstellen, sind sie in Zonen weltweit verfügbar.

Standorte sind die geografischen Regionen, in denen Anfragen für eine bestimmte Ressource bei Cloud KMS verarbeitet werden und in denen die entsprechenden kryptografischen Schlüssel gespeichert sind.

Weitere Informationen zu verfügbaren Cloud KMS-Standorten finden Sie unter Cloud KMS-Standorte.

Cloud-Regionen und -Rechenzentren

Je nach Kennzeichnung einer Google Cloud -Region als einzelne Region, duale Region, Multi-Region oder globaler Standort enthält diese ein bestimmtes Rechenzentrum oder einen genau angegebenen Satz an Rechenzentren. Weitere Informationen zu Google Cloud -Regionen finden Sie unter Google Cloud Standorte.

Jedes Rechenzentrum enthält Racks von Maschinen für die Datenverarbeitung, das Netzwerk oder die Datenspeicherung. Diese Maschinen führen die Borg-Infrastruktur von Google aus.

Google-Rechenzentren haben strenge Anforderungen an die physische Sicherheit. Für jeden physischen Bereich, der Nutzerdaten enthalten kann, sind auf den Zugangswegen Kartenlesegeräte und Iris-Scanner zur Authentifizierung von Personen erforderlich. Türen dürfen nicht für mehrere Personen gleichzeitig geöffnet werden. Jede Person muss sich einzeln authentifizieren. Taschen dürfen nicht in diese Bereiche mitgebracht oder aus diesen Bereichen herausgetragen werden, es sei denn, es handelt sich dabei um geprüfte Taschen, die nach der Untersuchung durch Sicherheitspersonal ausdrücklich autorisiert wurden. Beim Betreten oder Verlassen der Bereiche ist für das Mitführen von elektronischen Geräten, mit denen Daten übertragen oder aufgezeichnet werden können, eine gesonderte Berechtigung erforderlich.

Speicherort der Schlüssel

In einigen Branchen müssen sich kryptografische Schlüssel an einem bestimmten Standort befinden. Cloud KMS hat Datenstandortbedingungen mit Zusicherungen zum Datenstandort. Wie unter Regionalität von Cloud KMS-Ressourcen beschrieben, bietet Cloud KMS vier Arten von regionalen Standorten, mit denen Sie diese Anforderungen erfüllen können.

Für einzelne, duale oder multiregionale Standorte erstellt, speichert und verarbeitet Cloud KMS Ihre software- und hardwaregeschützten Schlüssel und das Schlüsselmaterial nur an diesem Standort. Die von Cloud KMS verwendeten Speicher- und Datenverarbeitungssysteme werden so konfiguriert, dass sie nur Ressourcen innerhalb derGoogle Cloud -Region verwenden, die dem Schlüsselmaterial zugeordnet ist. Schlüsselmaterial, das in dualen oder multiregionalen Standorten erstellt wurde, verlässt die Grenzen der ausgewählten Standorte nicht.

Für die globale Region sind keine Regionalitätsgarantien angegeben.

Cloud KMS gewährleistet keinen Standort für Schlüsselmetadaten, Nutzungslogs oder für Schlüsselmaterial bei der Übertragung. Schlüsselmetadaten umfassen Ressourcennamen, Attribute von Cloud KMS-Ressourcen (z. B. Schlüsseltyp, Schlüsselgröße und Schlüsselstatus), IAM-Richtlinien und aus Daten abgeleitete Daten.

Wenn Sie CMEK verwenden, gelten die folgenden geografischen Cloud KMS-Einschränkungen für Ihre Schlüssel, unabhängig von den benutzerdefinierten, biregionalen oder multiregionalen Standorten, die Sie in anderen Google Cloud Produkten auswählen, die CMEK unterstützen:

• Für eine bestimmte Region:Da die Region eines vom Kunden verwalteten KMS-Schlüssels immer der Region der Ressource entsprechen muss, die dieser Schlüssel in einem angegebenen Google Cloud -Dienst schützt, wird gewährleistet, dass Standortbeschränkungen für Schlüssel und Ressourcen mit einzelner Region kompatibel sind und durchgesetzt werden.
• Für biregionale oder multiregionale Standorte:Nutzer können von Google definierte multiregionale Standorte für ihre Schlüssel und Google Cloud-Ressourcen auswählen, um die Standortcompliance zu gewährleisten. Sorgen Sie dafür, dass Ihre Regionen in anderen Produkten mit dem ausgewählten regionalen Standort von Cloud KMS übereinstimmen, damit dieser geografische Standort gewährleistet werden kann.

In der folgenden Tabelle ist der Standort von Schlüsselmaterial für Cloud KMS zusammengefasst.

Regiontyp	Ruhend, aktiv
Einzelne Region	Resident
Dual- oder Multiregion	Resident in den Regionen, die die Dual-/Multiregion bilden.

Monitoring der Regionalität

Mit den internen Dienste für das Datenmonitoring von Google wird der Schlüsselstandort aktiv überwacht. Cloud KMS sendet Benachrichtigungen an SRE-Teammitglieder, wenn versehentliche Fehlkonfigurationen entdeckt werden oder wenn Schlüsselmaterial die Grenzen seiner konfigurierten Region verlässt, in der falschen Region gespeichert wird oder wenn aus der falschen Region darauf zugegriffen wird.

Hochverfügbarkeit

Cloud KMS kann Ihnen helfen, Ihre Verfügbarkeitsanforderungen basierend auf den von Ihnen ausgewählten Regionen zu vereinfachen. Je genauer der Standort ist, desto mehr Redundanz müssen Sie einbauen. Verwenden Sie für Anwendungen mit höherer Verfügbarkeit multiregionale Standorte, anstatt ein eigenes Replikationssystem für Schlüssel zu erstellen. Sie müssen die integrierten Redundanzfunktionen mit Ihren Anforderungen an die Datenregionalisierung in Einklang bringen.

Authentifizierung und Autorisierung

Cloud KMS akzeptiert verschiedene Authentifizierungsmechanismen, darunter OAuth2, JWT und ALTS. Unabhängig vom Mechanismus ordnet Cloud KMS die angegebenen Anmeldedaten zu und identifiziert so das Hauptkonto (die authentifizierte Einheit, die auch die Anfrage autorisiert). Dann sendet es eine Anfrage an IAM, um zu ermitteln, ob das Hauptkonto autorisiert ist, die Anfrage durchzuführen, und ob ein Audit-Log erstellt wird.

Cloud KMS verwendet eine interne Version der öffentlichen Service Control API für viele Aspekte der Dienstverwaltung. Bevor ein Cloud KMS-Job eine Anfrage verarbeitet, sendet er zuerst eine Prüfungsanfrage an die Service Control API, die viele, allen Google Cloud Diensten gemeinsame Kontrollen erzwingt, beispielsweise folgende:

• Prüfen, ob Sie die Cloud KMS API aktiviert haben und ein aktives Abrechnungskonto haben
• Prüfen, ob Sie Ihr Kontingent nicht überschritten haben und Kontingentnutzung melden
• Erzwingen von VPC Service Controls
• Prüfen, ob Sie auf der Zulassungsliste für die entsprechenden privaten Cloud-Regionen stehen

Kontingentverwaltung

Für Cloud KMS gelten Nutzungslimits, sogenannte Kontingente, für Anfragen an den Dienst. Für Cloud KMS gelten die folgenden Kontingente:

• Kontingente für kryptografische Anfragen für Vorgänge wie „Verschlüsseln“, „Entschlüsseln“ oder „Signieren“.
• Kontingente für Leseanfragen für Vorgänge wie das Abrufen von Schlüsselmetadaten oder einer IAM-Richtlinie.
• Schreibanfragekontingente für Vorgänge wie das Erstellen eines Schlüssels oder das Festlegen einer IAM-Richtlinie.

Diese Kontingente werden dem Projekt in Rechnung gestellt, das dem Aufrufer zugeordnet ist. Diese Kontingente sind ebenfalls global, d. h. sie werden für die KMS-Nutzung des Aufrufers in allen Regionen und Multiregionen angewendet. Diese Kontingente werden für alle Schutzstufen ausgewertet.

Für Cloud HSM und Cloud EKM gelten zusätzliche Kontingente für kryptografische Vorgänge. Diese Kontingente müssen zusätzlich zum Kontingent für kryptografische Anfragen erfüllt werden. Die Kontingente für Cloud HSM und Cloud EKM werden dem Projekt in Rechnung gestellt, in dem sich der Schlüssel befindet. Die Kontingente werden für jeden Standort erzwungen.

Betrachten Sie hierzu folgende Beispiele:

• Entschlüsselung mit einem Softwareschlüssel in asia-northeast1 aufrufen erfordert eine Einheit des Kontingents (globale) kryptografische Anfragen.
• Zum Erstellen eines HSM-Schlüssels in us-central1 ist eine Einheit des Kontingents für Schreibanfragen und kein HSM-Kontingent erforderlich.
• Zum Aufrufen der Verschlüsselung mit einem EKM-Schlüssel in europe ist eine Einheit des Kontingents für (globale) kryptografische Anfragen und eine Einheit des Kontingents für externe KMS-Anfragen in europe erforderlich.

Weitere Informationen zu den verfügbaren Kontingenttypen finden Sie unter Kontingente für die Nutzung von Cloud KMS-Ressourcen. Sie können Ihr Kontingentlimit in der Cloud Console aufrufen. Die anfänglichen Kontingentlimits sind weiche Limits, die Sie basierend auf den Anforderungen Ihrer Arbeitslast anpassen lassen können.

Logging

Mit Cloud KMS sind drei Arten von Logs verknüpft: Cloud-Audit-Logs, Access Transparency-Logs und interne Anfrageprotokolle.

Cloud-Audit-Logs

Cloud KMS zeichnet Ihre Aktivitäten in Cloud-Audit-Logs auf. Sie können diese Logs in der Cloud Console aufrufen. Sämtliche Administratoraktivität (z. B. das Erstellen oder Löschen eines Schlüssels) wird in diesen Logs aufgezeichnet. Sie können auch für alle anderen Aktivitäten, die einen Schlüssel verwenden, das Logging aktivieren, etwa für Aktivitäten, die mithilfe eines Schlüssels Daten verschlüsseln oder entschlüsseln. Sie können festlegen, wie lange die Logs aufbewahrt werden sollen und wer sie einsehen darf.

Access Transparency-Logs

Berechtigte Kunden können Access Transparency-Logs aktivieren. Diese bieten Logs zu Aktionen, die Google-Mitarbeiter in IhrerGoogle Cloud -Organisation ausführen. Die Access Transparency-Logs können Ihnen zusammen mit den Logs aus Cloud-Audit-Logs dabei helfen, Fragen dazu zu beantworten, wer was, wo und wann getan hat.

Sie können Access Transparency-Logs in Ihre vorhandenen SIEM-Tools (Security Information and Event Management, Sicherheits- und Ereignisverwaltung) einbinden und so die Prüfung dieser Aktionen automatisieren. Diese Logs sind in der Cloud Console zusammen mit Cloud-Audit-Logs verfügbar.

Access Transparency-Logeinträge umfassen folgende Informationen:

• Die betroffene Ressource und Aktion
• Die Zeit der Aktion
• Die Gründe für die Aktion. Beispiele hierfür sind vom Kunden initiierter Support (mit einer Fallnummer), ein von Google initiierter Support, Anfragen von Drittanbietern und von Google initiierte Prüfungsanfragen.
• Daten über denjenigen, der auf die Daten Einfluss nimmt (z. B. den Standort des Google-Mitarbeiters)

Interne Anfragelogs

Anfragelogs speichern einen Eintrag für jede Anfrage, die an die Cloud KMS-Plattform gesendet wird. Dieser Eintrag enthält Details zum Anfragetyp (z. B. API-Methode oder -Protokoll) und zur Ressource, auf die zugegriffen wird (z. B. Ressourcenname, Schlüsselalgorithmus oder Schlüsselschutzniveau). Diese Logs speichern keinen Klartext, Geheimtext und kein Schlüsselmaterial. Bevor diesen Logs neue Datentypen hinzugefügt werden, muss ein auf Datenschutzprüfungen spezialisiertes Team Änderungen an den Daten, die geloggt werden, genehmigen.

Logeinträge werden dauerhaft gelöscht, wenn die konfigurierte Gültigkeitsdauer (TTL) verstrichen ist.

Cloud KMS-SREs und -Entwickler im rotierenden Bereitschaftsdienst können auf Anfragelogs zugreifen. Es ist ein gültiger dokumentierter geschäftlicher Grund erforderlich, damit Personen auf Logs und andere Kundendaten zugreifen können. Bis auf einige bestimmte Ausnahmen wird der Zugriff durch Personen protokolliert und ist für berechtigte Kunden über Access Transparency-Logs einsehbar.

Monitoring

Cloud KMS lässt sich in Cloud Monitoring einbinden. Mit dieser Integration können Sie viele Cloud KMS-Vorgänge überwachen, Dashboards erstellen und Benachrichtigungen erstellen. So können Sie beispielsweise überwachen, wann Schlüssel zum Löschen vorgemerkt sind, oder Cloud KMS-Kontingente überwachen und anpassen, wenn kryptografische Vorgänge einen von Ihnen festgelegten Grenzwert überschreiten. Weitere Informationen zu den verfügbaren Cloud KMS-Messwerten finden Sie unter Cloud Monitoring mit Cloud KMS verwenden.

Außerdem verfügt Security Command Center über integrierte KMS-Sicherheitslücken-Detektoren. Mit diesen Detektoren können Sie dafür sorgen, dass Ihre Projekte, die Schlüssel enthalten, unseren empfohlenen Best Practices entsprechen. Weitere Informationen zum KMS-Sicherheitslücken-Detektor finden Sie unter Sicherheitslücken-Ergebnisse für Cloud KMS.

Nächste Schritte

• Weitere Informationen zu Cloud KMS finden Sie in den folgenden Ressourcen:
  • Dokumentation zu Cloud KMS
  • Dokumentation zu Cloud HSM
• Informationen zur Verwendung eigener Verschlüsselungsschlüssel inGoogle Cloudfinden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK).
• Weitere Informationen zur Sicherheit der Google-Infrastruktur finden Sie unter Übersicht über das Sicherheitsdesign der Infrastruktur von Google.