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.	Daten von mehreren Kunden können denselben Schlüsselverschlüsselungsschlüssel (KEK) verwenden.	Ja, siehe Standardverschlüsselung ruhender Daten.	Kostenlos.
Cloud KMS-Schüssel	Diese Schlüssel werden vom Kunden gesteuert.	Exklusiv für einen Kunden.	Ja für die symmetrische Verschlüsselung, nein für asymmetrische Schlüssel. Siehe Schlüsselrotation.	Weitere Informationen finden Sie unter Cloud Key Management Service – Preise.

In diesem Dokument geht es um die interne Funktionsweise der Cloud KMS-Plattform. 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.

Säulen für Cloud KMS-Design

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 Monitoring: 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üsselmaterial

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

Das folgende Diagramm zeigt das Google Cloud-Portfolio für Schlüssel, das von Google-gesteuertem Schlüsselmaterial bis zum vom Kunden kontrollierten Schlüsselmaterial angeordnet ist.

Die im vorherigen Diagramm angezeigten Optionen sind:

• 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 und Kunden haben keinen Zugriff auf die Schlüssel oder die Steuerung der Schlüsselrotation und -verwaltung. Standardverschlüsselungsschlüssel können von Kunden gemeinsam verwendet 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 steuern. Mit dem Cloud KMS-Software-Backend 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 Schlüssel besitzen, die 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: Damit Sie die BYOK-Anforderungen erfüllen können, können Sie eigene kryptografische Schlüssel importieren, die Sie selbst generieren. Sie können diese Schlüssel außerhalb von Google Cloud verwenden und verwalten und das Schlüsselmaterial in Cloud KMS zum Verschlüsseln oder Signieren von Daten verwenden, 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 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 veranschaulicht Schlüsselgruppierungen und Schlüsselbunde sowie Schlüssel mit einer einzigen primären Version und mehreren vorherigen Versionen.

Folgende Schlüsselkonzepte werden im vorherigen Diagramm gezeigt:

• 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 der Schlüsselebene 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 Prüfen von MAC-Signaturen oder zur symmetrischen Verschlüsselung verwendet, um einen Teil des Datenkorpus 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 asymmetrische Signaturen 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 abhängig davon zulassen, ob eine Ressource ein bestimmtes Tag hat. Sie können Tags auf der Schlüsselbundebene 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 Keystore, den internen Schlüsselverwaltungsdienst von Google, zum Verpacken von Cloud KMS-verschlüsselten Schlüsseln. Beim Key-Wrapping 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 ist:

1. Ein Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) verschlüsselt die Datenblöcke.
2. Ein Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) wird zum Verschlüsseln oder Verpacken des DEK verwendet. Sie können alle Cloud KMS-Plattformoptionen (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. In Keystore gibt es für jeden Cloud KMS-Standort einen separaten KMS-Masterschlüssel. KEKs in Cloud KMS sind durch den KMS-Masterschlüssel des Standorts 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 in 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 folgende 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 einer Aufgabentrennung zwischen Schlüssel- und Datenadministratoren zu unterstützen, können Sie die Inhaberrolle 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 auf die 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 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 kritische Systeme von Google. Siehe Datastore-Schutz.

• Das unabhängige Sicherungssystem sichert in regelmäßigen Abständen den gesamten Datenspeicher sowohl für den Online- als auch für den Archivspeicher. Mit dieser Sicherung kann Cloud KMS seine Langlebigkeitsziele erreichen. Siehe Datastore-Schutz.

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. Diese Kryptografievorgänge verwenden BoringCrypto, 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.

Abhängigkeiten 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.
• Snapshot-Daten 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 von einem Snapshot bereitgestellt werden, wenn der Snapshot nicht mehr als zwei Stunden alt 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 für Client-Server-Kommunikation mit dem RPC-Mechanismus (Remote-Prozeduraufruf) von Google zu gewährleisten.

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

Architektur der Cloud KMS-Plattform

In diesem Abschnitt werden Architekturdetails 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) erzwingt diese Richtlinie auf operativer Ebene.

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 und die Protokolle 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. Auf 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 speichert 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 dokumentierte Verfahren zur Wiederherstellung von Sicherungen, um Datenverluste bei einem dienstseitigen Notfall 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 verschlüsselt der Datenspeicher alle Daten, die er verwaltet, bevor er sie in den dauerhaften Speicher schreibt. Daher bietet der Zugriff auf zugrunde liegende Speicherebenen, einschließlich Laufwerken oder Archivspeichern, keinen Zugriff auf die verschlüsselten Cloud KMS-Daten ohne Zugriff auf die Datenspeicherverschlüsselungsschlüssel, die in 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 ebenfalls eine Schlüsselrotationsrichtlinie auf die Keystore-Masterschlüssel angewendet, die 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 Back-Ends werden in der Cloud KMS API als Schutzniveaus bereitgestellt:

• 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 das 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 (BCM) der BoringSSL-Implementierung 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-Backend: HARDWARE-Schutzniveau

Cloud HSM stellt hardwaregestü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. 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 Cloud-Verschlüsselungsschlüsseln verschlüsseln, die Sie selbst kontrollieren.

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

Schlüsselimport

Möglicherweises 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 auf den Client importiert werden soll. Der private Schlüssel, der mit dem öffentlichen Schlüssel übereinstimmt, wird in Google Cloud gespeichert und dazu verwendet, den öffentlichen Schlüssel zu entpacken, sobald er das Google Cloud-Projekt erreicht. 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 dem Schutzniveau 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. Dies bedeutet, dass verschiedene Versionen eines Schlüssels unterschiedliche Teilmengen von Daten 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 können Sie besser steuern, 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.
   • Für das Projekt ist die Cloud KMS API aktiviert und es gibt ein gültiges Rechnungskonto.
   • 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 diese nicht beschädigt sind. Diese Prüfsummen schützen Sie vor Datenverlust, der durch Hardware- oder Softwarebeschädigung verursacht werden kann. Mit Hilfsbibliotheken können Sie die Schlüsselintegrität prüfen. Sie können Hilfsbibliotheken verwenden, um die Schlüsselintegrität zu prüfen, indem Sie Cloud KMS Prüfsummen zur Verfügung stellen, die vom Server überprüft werden. Mit diesen Bibliotheken erhalten Sie auch Prüfsummen, um Antwortdaten auf dem Client zu prüfen.

End-to-End-Datenintegrität trägt zum Schutz Ihrer Umgebung vor Bedrohungen wie den folgenden bei:

• 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 Kryptovorgänge, Maschinenspeicherbeschädigungen oder HSM-Beschädigungen in der Cloud KMS-Architektur.
• Beschädigung während 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 unter Datenlöschung auf der Google Cloud beschriebene Ansatz auch für Cloud KMS. Schlüsselmaterial wird auf Anfrage gelöscht, wenn der Zeitraum Zum Löschen vorgemerkt abgeschlossen ist und die Sicherungen ablaufen. Das Schlüsselmaterial, das noch in den Sicherungen vorhanden ist (nach Ablauf des zum Löschen vorgemerkten Zeitraums), 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 24 Stunden 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.

Nachdem eine Schlüsselversion zum Löschen geplant ist, ist die Schlüsselversion nicht mehr für kryptografische Vorgänge verfügbar. Innerhalb des ausstehenden Löschzeitraums 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 Gelöschten Schlüssel noch einmal importieren.

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

• 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 lang deaktivieren, bevor der Schlüssel gelöscht wird.

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 werden in Standardbetriebsverfahren definiert. Systemoperatoren greifen beim Ausführen ihrer Aufgaben nicht auf Kundenschlüsselmaterial zu.

Regionalität von Cloud KMS-Ressourcen

Sie können Cloud KMS-Ressourcen an einem von vier verschiedenen Google Cloud-Standorten erstellen, um alle Anforderungen an den Schlüsselstandort 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.

Schlüsselstandort

In einigen Branchen müssen sich kryptografische Schlüssel an einem bestimmten Standort befinden. Cloud KMS hat Begriffe für Datenstandorte und bietet Sicherheit für den 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 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 garantiert 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, dual- 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 dual- 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 Multi-Region	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 Ihre Verfügbarkeitsanforderungen basierend auf den ausgewählten Regionen vereinfachen. Je detaillierter der Standort ist, desto mehr Redundanz muss erstellt werden. Verwenden Sie für Anwendungen mit höherer Verfügbarkeit Instanzen multiregionale Standorte, anstatt zu versuchen, 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 Liste der zulässigen privaten Cloud-Regionen stehen

Kontingentverwaltung

Für Cloud KMS gelten Nutzungslimits, die als Kontingente für Anfragen an den Dienst bezeichnet werden. Cloud KMS enthält die folgenden Kontingente:

• Kontingente für kryptografische Anfragen für Vorgänge wie Verschlüsseln, Entschlüsseln oder Signieren.
• Leseanfragekontingente für Vorgänge wie das Abrufen wichtiger Schlüsselmetadaten oder das Abrufen 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 mit dem Aufrufer verknüpft 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.

Cloud HSM und Cloud EKM haben zusätzliche Kontingente für kryptografische Vorgänge. Diese Kontingente müssen zusätzlich zum Kontingent für kryptografische Anfragen erfüllt sein. 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 von 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 ansehen. Die anfänglichen Kontingentlimits sind weiche Limits, die Sie an Ihre Anforderungen 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ät 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 die Logs aufrufen 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 kann in Cloud Monitoring eingebunden werden. Durch diese Einbindung können Sie Dashboards überwachen und Benachrichtigungen für viele Cloud KMS-Vorgänge erstellen. Sie können beispielsweise überwachen, wann Schlüssel zum Löschen geplant sind, oder Cloud KMS-Kontingente überwachen und anpassen, wenn kryptografische Vorgänge einen von Ihnen definierten Schwellenwert überschreiten. Weitere Informationen zu den verfügbaren Cloud KMS-Messwerten finden Sie unter Cloud Monitoring mit Cloud KMS verwenden.

Darüber hinaus verfügt Security Command Center über integrierte Sicherheitslücken-Detektoren von KMS. Diese Detektoren sorgen dafür, dass Ihre Projekte, die Schlüssel enthalten, unseren empfohlenen Best Practices folgen. Weitere Informationen zum KMS-Detektor für Sicherheitslücken finden Sie unter Ergebnisse zu Sicherheitslücken 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.