Cloud Key Management Service im Detail

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

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 Cloud speichern, werden Ihre Daten standardmäßig bei Inaktivität automatisch verschlüsselt. Mit dem Cloud Key Management Service (Cloud KMS) können Sie besser steuern, wie Ihre inaktiven Daten verschlüsselt und Ihre Verschlüsselungsschlüssel verwaltet werden.

In der folgenden Tabelle werden die verschiedenen Arten von Google Cloud-Schlüsseln beschrieben.

Schlüsseltyp	Schlüsselverwaltung	Schlüsselfreigabe	Automatische Rotation	Preise
Standardverschlüsselungsschlüssel	Diese Schlüssel werden ausschließlich von Google verwaltet.	Für Daten mehrerer Kunden kann derselbe Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) verwendet werden.	Ja, siehe Standardverschlüsselung ruhender Daten.	Kostenlos.
Cloud KMS-Schüssel	Diese Schlüssel werden vom Kunden verwaltet.	Eindeutig für einen Kunden.	Ja für die symmetrische Verschlüsselung, nein für asymmetrische Schlüssel. Weitere Informationen finden Sie unter Schlüsselrotation.	Weitere Informationen finden Sie unter Cloud Key Management Service – Preise.

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 Cloud speichern, 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.

Designprinzipien von Cloud KMS

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. Das Design von Cloud KMS beruht auf diesen fünf Säulen:

• 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.

Quellen und Verwaltungsoptionen für Schlüsselmaterialien

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

Das folgende Diagramm zeigt das Google Cloud-Portfolio für Schlüssel, sortiert nach von Google verwaltetem Schlüsselmaterial und vom Kunden verwaltetem Schlüsselmaterial.

Im vorherigen Diagramm sind folgende Optionen zu sehen:

• 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 softwaregenerierten Schlüsseln: Mit Cloud KMS können Sie die von Google 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 hardwaregenerierten 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 symmetrischen und asymmetrischen Schlüssel nur in FIPS 140-2 Level 3-validierten HSMs verwendet 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 von Google Cloud verwenden und verwalten und das Schlüsselmaterial in Cloud KMS verwenden, um Daten zu verschlüsseln oder zu signieren, die Sie in Google Cloud speichern.

• 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 Cloud gespeichert 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 die zuverlässige Bereitstellung von Cloud EKM-Diensten.

Sie haben die Möglichkeit, von Cloud KMS generierte Schlüssel mit anderen Google Cloud-Diensten zu verwenden. Derartige Schlüssel sind als vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) bekannt. Mit dem CMEK-Feature können Sie Verschlüsselungsschlüssel generieren, verwenden, rotieren und löschen, wenn Sie Daten in anderen Google Cloud-Diensten schützen möchten.

Verschlüsselungskonzepte 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 wichtigsten 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.

Softwareschlüsselhierarchie

Das folgende Diagramm zeigt die Schlüsselhierarchie für Cloud KMS und den internen Schlüsselspeicher von Google. Cloud KMS verwendet den internen Schlüsselverwaltungsdienst von Google, den Keystore, um mit Cloud KMS verschlüsselte Schlüssel zu verpacken. Bei der Umschlagverschlüsselung wird ein Schlüssel mithilfe eines anderen Schlüssels codiert, um ihn sicher zu speichern oder über einen nicht vertrauenswürdigen Kanal zu übertragen. Cloud KMS verwendet dieselbe Root of Trust wie der Keystore.

Die im vorherigen Diagramm dargestellte Schlüsselhierarchie sieht so aus:

1. Die Datenblöcke werden mit einem Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) verschlüsselt.
2. 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.
3. Ein KMS-Masterschlüssel verschlüsselt den KEK. Der KMS-Masterschlüssel wird im Keystore gespeichert. Für jeden Cloud KMS-Speicherort gibt es in Keystore einen separaten KMS-Masterschlüssel. KEKs in Cloud KMS werden durch den KMS-Masterschlüssel des Speicherorts geschützt. 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 neu verschlüsselt.
4. Der KMS-Masterschlüssel wird durch den Keystore-Masterschlüssel im Keystore geschützt.
5. Der Keystore-Masterschlüssel wird durch den Root-Keystore-Masterschlüssel geschützt.

Weitere Informationen zu Keystore finden Sie im Abschnitt „Verschlüsselung ruhender Daten” unter Schlüsselverwaltung.

Betriebseinschränkungen für Schlüssel

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. Daten müssen nicht in demselben Projekt gehostet werden, in dem sich die Cloud KMS-Schlüssel befinden. Um die Best Practice der Aufgabentrennung zwischen Schlüssel- und Datenadministratoren zu unterstützen, können Sie die Rolle „Inhaber“ aus dem Schlüsselprojekt entfernen.
• 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.

Übersicht über die 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 softwaregestützten Schlüsseln. Die Cloud KMS-Plattform ist in die Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) und Cloud-Audit-Logs eingebunden, sodass Sie Berechtigungen für einzelne Schlüssel verwalten und deren Verwendung prüfen können.

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 über die Implementierung der REST API, gRPC oder Clientbibliotheken auf Schlüsselverwaltungsdienste zu. 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 mithilfe der Bibliothek für PKCS #11 in Cloud KMS einbinden.

• Mit der Cloud KMS API können Sie Software-, Hardware- oder externe Schlüssel verwenden. Sowohl software- als auch hardwarebasierte Schlüssel verwenden als Schutzmaßnahme die redundanten Sicherungen von Google.

• Wenn Sie Hardwareschlüssel verwenden, speichern FIPS 140-2 Level 3-zertifizierte HSMs in Google Cloud die Schlüssel. Weitere Informationen zu unserer Zertifizierung finden Sie unter Zertifikat Nr. 4399.

• Cloud KMS verwendet den internen Datenspeicher von Google, um verschlüsseltes Kundenschlüsselmaterial zu speichern. Dieser Datenspeicher ist hochverfügbar und unterstützt viele der kritischen Systeme von Google. Weitere Informationen finden Sie unter Datenspeicherschutz.

• In regelmäßigen Abständen sichert das unabhängige Sicherungssystem die gesamte Datendatenbank sowohl im Online- als auch im Archivspeicher. Durch diese Sicherung kann Cloud KMS seine Ausfallsicherheitsziele 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 gepflegte Open-Source-Kryptografiebibliothek. Schlüssel mit der Schutzstufe HSM und die damit durchgeführten kryptografischen Vorgänge entsprechen FIPS 140-2 Level 3.

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 jeder Google 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 zugewiesenen Google 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, wird die Antwort möglicherweise aus einem Snapshot zurückgegeben, 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 die Sicherheit der Client-Server-Kommunikation zu gewährleisten, die den RPC-Mechanismus (Remote Procedure Call) von Google verwendet.

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

Architektur der Cloud KMS-Plattform

In diesem Abschnitt werden architektonische Details zur Sicherheit von Schlüsselmaterial und zum Datenspeicherschutz beschrieben.

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 auf operativer Ebene um.

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 Archivspeicher kopiert.

Das Cloud KMS-Team hat Verfahren zur Wiederherstellung von Sicherungen dokumentiert, um Datenverluste bei einem Notfall auf Dienstebene zu vermeiden.

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 verschlüsselt der Datenspeicher alle verwalteten Daten, bevor sie in den dauerhaften Speicher geschrieben werden. Daher ist der Zugriff auf die zugrunde liegenden Speicherschichten, einschließlich Laufwerken oder Archivspeicher, ohne Zugriff auf die Verschlüsselungsschlüssel des Datenspeichers, die im Keystore gespeichert sind, nicht möglich.

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-Backend

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). EXTERNAL-VPC ermöglicht es, das EKM über ein VPC-Netzwerk mit Google Cloud zu 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 (BCM) der BoringSSL von Google für alle kryptografischen Aufgaben, die in diesem Zusammenhang anfallen. BCM 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 gesicherte 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. Für bestehende Cloud KMS-Kunden sind keine Anwendungsänderungen erforderlich, da sie mit derselben API und denselben Clientbibliotheken wie Cloud KMS auf das Cloud HSM-Backend zugreifen können. Weitere Informationen zum Cloud HSM-Backend finden Sie unter Cloud HSM-Architektur.

Cloud EKM: Schutzniveau „EXTERN”

Mit Cloud EKM können Sie Daten mit externen Verschlüsselungsschlüsseln verschlüsseln, die Sie selbst verwalten.

Schlüssel mit den Schutzniveaus EXTERNAL und EXTERNAL_VPC werden in einem externen Schlüsselverwaltungssystem gespeichert und verwaltet. Weitere Informationen finden Sie unter Referenzarchitekturen für die zuverlässige Bereitstellung von Cloud EKM-Diensten.

Schlüsselimport

Möglicherweise möchten Sie Ihre eigenen Schlüssel, die Sie lokal oder in einem externen Schlüsselverwaltungssystem 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 außerdem asymmetrische Schlüssel importieren, um Ihre Signaturfunktionen 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 Verschlüsselungsschlüssel verschlüsseln Sie den Schlüssel, der auf dem Client importiert werden soll. Der private Schlüssel, der dem öffentlichen Schlüssel entspricht, wird in Google Cloud gespeichert und zum Entpacken des öffentlichen Schlüssels verwendet, nachdem er das Google 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.

Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK)

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 einige Google Cloud-Produkte können Sie stattdessen Cloud KMS verwenden, um die für die Verschlüsselung verwendeten Schlüssel zu verwalten. CMEK kann für extern sowie auf Software und Hardware gesicherte Schlüssel verwendet werden. 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

Durch die Rotation des Cloud KMS-Schlüssels werden die Daten im zugehörigen CMEK-Dienst nicht neu verschlüsselt. Stattdessen werden neu erstellte Ressourcen mit der neuen Schlüsselversion verschlüsselt. Das bedeutet, dass verschiedene Versionen eines Schlüssels unterschiedliche Datenmengen schützen. In BigQuery wird beispielsweise 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. Neue BigQuery-Tabellen verwenden die aktuelle Schlüsselversion. Weitere Informationen finden Sie in der Dokumentation zum jeweiligen Produkt.

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

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.

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 einen Client, der 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. Ein Kunde oder ein Job, der für einen Kunden ausgeführt wird, stellt eine Anfrage an den Cloud KMS-Dienst, https://cloudkms.googleapis.com. DNS löst diese Adresse in eine Anycast-IP-Adresse des Google Front End (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 der Kunde eine Anfrage sendet, wird diese in der Regel an ein GFE in der Nähe des Kunden geroutet, egal für welchen Standort die Kundenanfrage 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 Google 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 alle Google Cloud-Dienste gemeinsam haben. Dieses Framework authentifiziert den Nutzer und führt eine Reihe von Tests durch, um Folgendes zu verifizieren:
   • Der Kunde verfügt über gültige Anmeldeinformationen 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.
   • Der Kunde ist auf der Zulassungsliste, um die relevante Google 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 teilt Cloud KMS auch mit, ob die Anfrage in Audit-Logs protokolliert werden sollte.
6. Nachdem die Anfrage authentifiziert und autorisiert wurde, ruft Cloud KMS seine regionalen Back-Ends auf, um die angeforderte Ressource abzurufen. Nachdem das Kundenschlüsselmaterial abgerufen wurde, wird es 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 den Kunden ü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 einige 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 Datenverlusten, die durch Hardware- oder Softwarebeschädigungen verursacht werden können. Mithilfe von 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 trägt dazu bei, Ihre Umgebung vor Bedrohungen wie den folgenden zu schützen:

• 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 Arbeitsspeichers oder 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 Löschen von Daten 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 geplanten Zeitraums noch in Sicherungen vorhanden ist, kann nur für die regionale Notfallwiederherstellung und nicht für die Wiederherstellung 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 Tagen 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 Schlüsselversionsmaterial planmäßig zum Löschen vorgesehen ist, steht die Schlüsselversion nicht mehr für kryptografische Vorgänge zur Verfügung. Innerhalb des Zeitraums, in dem das Löschen ausstehend ist, 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 noch einmal importieren. Weitere Informationen finden Sie unter Einen gelöschten Schlüssel noch einmal importieren.

Beachten Sie die folgenden Best Practices, um das versehentliche Löschen eines Schlüssels zu vermeiden:

• Erstellen Sie eine benutzerdefinierte KMS-Rolle, die die Berechtigung cloudkms.cryptoKeyVersions.destroy nicht 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.

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 ihrer 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. Für Cloud KMS gelten Bestimmungen zum Speicherort von Daten 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 Ihre auf Software und Hardware gesicherten 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 der Google Cloud-Region verwenden, die dem Schlüsselmaterial zugeordnet ist. Schlüsselmaterial, das in biregionalen oder multiregionalen Standorten erstellt wurde, verlässt die Grenzen der ausgewählten Standorte nicht.

Für die globale Region ist keine Regionalitätsgarantie 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

Mit Cloud KMS können Sie Ihre Verfügbarkeitsanforderungen basierend auf den von Ihnen ausgewählten Regionen vereinfachen. Je detaillierter der Standort, 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 wichtiger Metadaten oder einer IAM-Richtlinie.
• Kontingente für Schreibanfragen 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 Schutzniveaus 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.
• Für das 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 einsehen. Die anfänglichen Kontingentlimits sind Softlimits, die Sie an Ihre Arbeitslastanforderungen anpassen 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 Ihrer Google 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.

Darüber hinaus sind in Security Command Center integrierte KMS-Sicherheitslücken-Detektoren verfügbar. 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 in Google Cloud finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK).
• Vorbereitung von Google auf eine Post-Quanten-Welt
• Weitere Informationen zur Sicherheit der Google-Infrastruktur finden Sie unter Übersicht über das Sicherheitsdesign der Infrastruktur von Google.
• Allgemeine Informationen zur Sicherheit von Google Cloud finden Sie im Abschnitt „Sicherheit“ auf der Google Cloud-Website.