Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Cloud Key Management Service im Detail

Autoren: Sonal Shah, Il-Sung Lee, Walter Poupore, Hunter Freyer, Honna Segel, Dwight Worley

Danksagungen: Adrian Sears, John Randolph, Tim Dierks, Chris Rezek, Stanley McKenzie, Kevin Plybon, David Hale, Sergey Simakov, David U. Lee, Carrie McDaniel, Anton Chuvakin, Dave Tonisson

Letzte Aktualisierung: April 2020

1. Einführung

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.

Mit der Cloud KMS-Plattform können Google Cloud-Kunden kryptografische Schlüssel in einem zentralen Cloud-Dienst entweder zur direkten Verwendung oder zur Verwendung durch andere Cloud-Ressourcen und -Anwendungen verwalten. Cloud KMS bietet die folgenden Optionen als Quelle von Schlüsseln:

  • 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 (Cloud KMS).
  • Wenn Sie einen Hardwareschlüssel benötigen, können Sie Cloud HSM verwenden, damit Ihre symmetrischen und asymmetrischen Schlüssel nur in FIP 140-2 Level 3-validierten Hardware-Sicherheitsmodulen (HSMs) verwendet werden.
  • Mit Cloud KMS können Sie eigene kryptografische Schlüssel importieren für den Fall, dass Sie von Ihnen selbst generierte Schlüssel verwenden müssen.
  • 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.
  • Mit Cloud External Key Manager (Cloud EKM) können Sie Schlüssel in einem Schlüsselmanager außerhalb von Google Cloud erstellen und verwalten. Anschließend richten Sie die Cloud KMS-Plattform für die Verwendung von externen Schlüsseln ein, um Ihre inaktiven Daten zu schützen. Sie können vom Kunden verwaltete Verschlüsselungsschlüssel zusammen mit einem Cloud EKM-Schlüssel verwenden. Cloud EKM wird in diesem Whitepaper nicht behandelt.

Google unterstützt auch vom Kunden bereitgestellte Verschlüsselungsschlüssel (Customer-Supplied Encryption Keys, CSEK) für Compute Engine und Cloud Storage, wobei Daten mithilfe eines beim API-Aufruf bereitgestellten Schlüssels ver- und entschlüsselt werden. CSEK wird in diesem Whitepaper nicht behandelt. Weitere Informationen finden Sie in der Online-Dokumentation.

„Diagramm zum KMS-Portfolio“

Bei Cloud KMS liegt der Fokus von Google darauf, eine skalierbare, verlässliche und leistungsstarke Lösung mit umfassenden Optionen bereitzustellen, die Sie über eine leicht bedienbare Plattform verwenden können. Das Design von Cloud KMS beruht auf diesen fünf Säulen:

  • Kundenüberprüfung: Mit Cloud KMS können Sie Verschlüsselungsschlüssel für Software und Hardware verwalten oder eigene Schlüssel bereitstellen.
  • 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 Softwareschlüssel nur in der von Ihnen ausgewählten Google Cloud-Region erstellt, gespeichert und verarbeitet werden.
  • Langlebigkeit: Cloud KMS auf Google Cloud entspricht höchsten Langlebigkeitsstandards. 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.

In diesem Whitepaper wird die interne Funktionsweise der Cloud KMS-Plattform im GA-Release (General Availability) behandelt. Mit den Optionen können Sie Schlüssel und andere sensible Daten, die Sie in Google Cloud speichern, besser schützen. Das Whitepaper 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.

2. Verschlüsselungskonzepte und Schlüsselverwaltung bei Google

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

2.1. Schlüssel, Schlüsselversionen und Schlüsselbunde

In diesem Abschnitt werden Schlüssel, Schlüsselversionen und die Gruppierung von Schlüsseln in Schlüsselbunde beschrieben. Das folgende Diagramm zeigt Schlüsselgruppierungen. Verwandte Definitionen entsprechen dem Diagramm.

„Diagramm der Schlüsselgruppierungen“

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

    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 für die symmetrische Verschlüsselung verwendet, um einen Teil des Datenkorpus zu schützen (beispielsweise AES-256 im GCM-Modus zur Verschlüsselung eines Klartextblocks). Ein asymmetrischer Schlüssel kann für die asymmetrische Verschlüsselung oder für das Erstellen digitaler Signaturen verwendet werden. Unterstützte Zwecke und Algorithmen werden in der Cloud KMS-Dokumentation beschrieben.

  • 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 IAM-Berechtigungen vom Schlüsselbund, in dem sie enthalten sind. 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.

    Ein Schlüsselbund kann nicht gelöscht werden, um Konflikte bei Ressourcennamen zu vermeiden. Für Schlüssel und Schlüsselbunde gibt es keine abrechenbaren Kosten oder Kontingentlimits. Daher hat ihr Fortbestand keine Auswirkungen auf Kosten oder Produktionslimits. Weitere Informationen zum Löschen von Schlüsseln und Schlüsselmaterial finden Sie weiter unten in diesem Artikel im Abschnitt Löschen.

  • Schlüsselmetadaten: Ressourcennamen, Attribute von KMS-Ressourcen wie IAM-Richtlinien, Schlüsseltyp, Schlüsselgröße, Schlüsselstatus und alle aus dem obigen Beispiel abgeleiteten Daten. Schlüsselmetadaten können anders als das Schlüsselmaterial verwaltet werden.

  • 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, wodurch die Verwendung einer einzigen Version begrenzt wird. Symmetrische Schlüssel haben immer eine primäre Version. Diese Version wird standardmäßig 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.

2.2. Schlüsselhierarchie

Das folgende Diagramm zeigt die Schlüsselhierarchie des internen Key Management Service von Google. Cloud KMS nutzt diesen internen Schlüsselverwaltungsdienst von Google so, dass mit Cloud KMS verschlüsselte Schlüssel vom Google KMS verpackt werden. Cloud KMS verwendet dieselbe Root of Trust wie der Google KMS. Verwandte Definitionen entsprechen dem Diagramm.

„Diagramm der internen Schlüsselhierarchie“

  • Datenverschlüsselungsschlüssel (Data Encryption Key, DEK): Ein Schlüssel zum Verschlüsseln von Daten.
  • Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK): Ein Schlüssel, mit dem ein Datenverschlüsselungsschlüssel verschlüsselt oder verpackt wird. Sie können alle Optionen der Cloud KMS-Plattform (Software, Hardware und externe Back-Ends) zum Steuern des Schlüsselverschlüsselungsschlüssels verwenden.
  • KMS-Masterschlüssel: Der Schlüssel, mit dem die Schlüsselverschlüsselungsschlüssel (KEK) verschlüsselt werden. Dieser Schlüssel wird im Speicher bereitgestellt. Der KMS-Masterschlüssel wird auf Hardwaregeräten gesichert. Dieser Schlüssel ist für die Verschlüsselung Ihrer Schlüssel verantwortlich.
  • Root KMS: Der interne Schlüsselverwaltungsdienst von Google.

2.3. Betrieb

  • 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. Mit dieser Fähigkeit wird die Best Practice einer Aufgabentrennung zwischen Schlüssel- und Datenadministratoren unterstützt.
  • Standorte: Innerhalb eines Projekts werden Cloud KMS-Ressourcen an einem Standort erstellt. Weitere Informationen finden Sie unter Geografie und Regionen.

3. Übersicht über die Cloud KMS-Plattform

Die Cloud KMS-Plattform unterstützt mehrere kryptografische Algorithmen und bietet Methoden zum Verschlüsseln und digitalen Signieren sowohl mit hardware- als auch mit 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.

„Diagramm der Cloud KMS-Architektur“

Das vorstehende Diagramm zeigt die Hauptkomponenten der Cloud KMS-Plattform. Administratoren greifen über die Google Cloud Console oder das gcloud-Befehlszeilentool oder über Anwendungen, die REST- oder gRPC-APIs verwenden, auf Schlüsselverwaltungsdienste zu. Anwendungen greifen über eine REST API oder gRPC auf Schlüsselverwaltungsdienste zu. Anwendungen können Google-Dienste verwenden, die für durch Kunden verwaltete Verschlüsselungsschlüssel (CMEK) aktiviert sind. CMEK verwenden wiederum die Cloud KMS API. Mit der Cloud KMS API können Sie entweder Softwareschlüssel (Cloud KMS) oder Hardwareschlüssel (Cloud HSM) verwenden. Sowohl software- als auch hardwarebasierte Schlüssel verwenden als Schutzmaßnahme die redundanten Sicherungen von Google.

In der Cloud KMS-Plattform können Sie eine Schutzstufe auswählen, wenn Sie einen Schlüssel erstellen, um zu ermitteln, welches Schlüssel-Back-End den Schlüssel erstellt und alle künftigen kryptografischen Vorgänge für diesen Schlüssel ausführt. Die Cloud KMS-Plattform bietet zwei Back-Ends (ausgenommen Cloud EKM), die in der Cloud KMS API als Schutzstufen SOFTWARE und HSM angegeben sind. Die Schutzstufe SOFTWARE gilt für Schlüssel, die von einem Softwaresicherheitsmodul zwecks Ausführung kryptografischer Vorgänge entpackt werden können. Die Schutzstufe HSM gilt für Schlüssel, die nur von Hardwaresicherheitsmodulen entpackt werden können, die alle kryptografischen Vorgänge mit den Schlüsseln ausführen.

Google Cloud unterstützt CMEKs für mehrere Dienste, einschließlich Cloud Storage, BigQuery und Compute Engine. Mit CMEKs können Sie die Cloud KMS-Plattform verwenden, um die Verschlüsselungsschlüssel zu verwalten, die diese Dienste zum Schutz Ihrer Daten verwenden.

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. Schlüssel mit der Schutzstufe HSM und die damit durchgeführten kryptografischen Vorgänge entsprechen FIPS 140-2 Level 3.

3.1. Umgebung und Abhängigkeiten

Dieser Abschnitt enthält Informationen zur Google-Infrastruktur, auf der die Cloud KMS-Plattform ausgeführt wird, und zu den von der Infrastruktur verwendeten Kommunikationsprotokollen.

3.1.1. Borg-Jobs in Cloud KMS

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. Weitere Informationen zur Sicherheit unserer physischen Infrastruktur und Produktionsinfrastruktur finden Sie in der Übersicht über das Sicherheitsdesign der Infrastruktur von Google.

3.1.1.1. 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. 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. Weitere Informationen zum Speicherort von Schlüsseln finden Sie unter Regionalität weiter unten in diesem Dokument.

3.1.1.2. 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 aggregieren und die Metadaten an das 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.
  • Daten-Snapshots für Hochverfügbarkeit erstellen.
  • 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.
3.1.1.3. 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 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. Anschließend verwendet die Cloud KMS API den Job, der die Anfrage zuerst erfolgreich durchführt. Der API-Server verwendet keine Ergebnisse der Snapshotter-Jobs, wenn diese Daten mehr als zwei Stunden alt sind, um eine Verzögerung in der Snapshotting-Pipeline zu vermeiden. 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.

3.1.2. Client-Server-Kommunikation

Google verwendet Application Layer Transport Security (ALTS), um Sicherheit bei Client-Server-Kommunikation (Verschlüsselung bei der Übertragung) zu ermöglichen, die den RPC-Mechanismus (Remote-Prozeduraufruf) von Google verwendet. ALTS bietet Folgendes:

  • Ein Peer-to-Peer-Authentifizierungsprotokoll für Anwendungen
  • Ein Aufzeichnungsprotokoll der Verschlüsselung
  • Eine API, die den authentifizierten Nutzer zur Autorisierung freigibt

Die ALTS-Protokolle für Handshake- und -Datensatzverschlüsselung ähneln den Handshake- und Dataset-Protokollen von Transport Layer Security (TLS). ALTS ermöglicht durch verschiedene Kompromisse eine Optimierung der Google-Produktionsumgebung und ist vollständig in den gesamten Produktionshardware- und -softwarestack eingebunden. Weitere Informationen finden Sie unter Betriebsumgebung der Cloud KMS-Plattform weiter unten in diesem Dokument.

4. Architektur der Cloud KMS-Plattform

Dieser Abschnitt enthält nähere Informationen zur Architektur. Zuerst werden die Themen Sicherheit von Schlüsselmaterial und Datenspeicherschutz behandelt. Anschließend werden die Optionen für die Quelle von Schlüsselmaterial im Detail beschrieben:

In diesem Abschnitt werden auch die Optionen für vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) beschrieben.

Zur Veranschaulichung der bisher verwendeten Architekturstrukturen enthält dieser Artikel eine Beschreibung des Lebenszyklus einer Cloud KMS-Anfrage. Dabei wird auch auf das Löschen von Schlüsselmaterial eingegangen.

4.1. 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. Application Layer Transport Security (ALTS), ein bereits im Abschnitt zu Client-Server-Kommunikation beschriebenes System, wird zur Verschlüsselung zwischen Cloud KMS-Jobs und ihren Back-Ends in verschiedenen Rechenzentren verwendet. ALTS und die Verschlüsselung während der Übertragung werden unter Lebenszyklus einer Cloud KMS-Anfrage weiter unten in diesem Dokument noch ausführlicher beschrieben.

Sämtliche 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 und wird ausführlicher in dieser Sicherheitsdokumentation beschrieben.

Cloud KMS API-Jobs können auf Schlüsselmetadaten (beispielsweise auf die IAM-Richtlinie 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. Der Zugriff wird intern protokolliert und die Protokolle zu Daten, die von Access Transparency abgedeckt werden, stehen berechtigten Kunden ebenfalls zur Verfügung.

Das Schlüsselmaterial kann jedoch weder von Cloud KMS API-Jobs aufgerufen noch über die API-Schnittstelle 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 Root KMS verschlüsselt, auf den keine Person direkt zugreifen kann.

4.2. Datenspeicherschutz

In diesem Abschnitt wird beschrieben, wie Schlüsseldaten mit Google KMS geschützt werden.

4.2.1. Masterschlüssel

Cloud KMS verwendet einen Masterschlüssel, um alle inaktiven Kundenschlüssel zu verpacken. Jeder Cloud KMS-Server ruft beim Start eine Kopie des Masterschlüssels als harte Abhängigkeit ab. Außerdem wird jeden Tag eine neue Kopie des Masterschlüssels abgerufen. Der Masterschlüssel wird regelmäßig neu verschlüsselt.

4.2.2. 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 internen KMS-Masterschlüssel von Google angewendet, welche die Cloud KMS-Schlüssel verpacken. Der KMS-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 Masterschlüssel in KMS-Aufgaben alle 24 Stunden und verschlüsselt alle Kundenschlüssel jeden Monat neu.

4.2.3. 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. Weitere Informationen zum Datenstandort finden Sie unter Regionalität weiter unten in diesem Dokument.

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

4.4. Cloud KMS-Software-Back-End: 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.

4.4.1. 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 auf unserer Dokumentationsseite 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.

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

4.5. Cloud KMS-HSM-Back-End: HARDWARE-Schutzniveau

Der Cloud HSM-Dienst stellt auf Hardware gesicherte Schlüssel für Cloud KMS bereit. Er bietet Kunden die Möglichkeit, kryptografische Schlüssel zu verwalten und zu verwenden, die durch vollständig verwaltete Hardware Security Modules (HSMs) in Google-Rechenzentren geschützt sind. Der Dienst ist hochverfügbar und bietet horizontales Autoscaling. Schlüssel sind kryptografisch an die KMS-Region gebunden, in der der Schlüsselbund definiert wurde. Die mit dem Cloud HSM-Dienst erstellten und verwendeten Schlüssel können nur innerhalb eines HSM-Clusters materialisiert werden, das zu der bei der Schlüsselerstellung angegebenen Region gehört. Mithilfe von Cloud HSM können Sie auf verifizierbare Weise bestätigen, dass Ihre kryptografischen Schlüssel ausschließlich innerhalb eines Hardwaregeräts erstellt und verwendet werden. Es sind keine Anwendungsänderungen erforderlich, damit bestehende Cloud KMS-Kunden Cloud HSM verwenden können: Auf die Cloud HSM-Dienste wird über dieselbe API und dieselben Clientbibliotheken zugegriffen wie auf das Cloud KMS-Software-Back-End.

Cloud HSM verwendet HSMs, die gemäß FIP 140-2 Level 3 validiert sind und immer im FIPS-Modus ausgeführt werden. Der FIPS-Standard gibt die von den HSMs verwendeten kryptografischen Algorithmen und die Generierung von Zufallszahlen an.

4.5.1. Cavium-HSMs

Die Cavium-HSM-PCIe-Karte wurde vom Anbieter als FIPS 140-2 Level 3-konform validiert. Das aktuelle Zertifikat ist auf Anfrage verfügbar.

4.5.2. HSM-Schlüsselhierarchie

Das folgende Diagramm zeigt Cloud KMS in der oberen Diagrammhälfte. Cloud HSM fasst Kundenschlüssel zusammen. Anschließen fasst Cloud KMS die HSM-Schlüssel zusammen, die an den Datenspeicher von Google weitergeleitet werden.

„Diagramm der HSM-Schlüsselhierarchie“

Cloud HSM hat einen Schlüssel (nicht angezeigt), der die Migration des Materials innerhalb der Cloud HSM-Verwaltungsdomäne steuert. Eine Region kann mehrere HSM-Verwaltungsdomänen haben.

Der HSM-Root-Schlüssel hat zwei Eigenschaften:

  1. Er wird auf einem HSM generiert und verlässt während seiner gesamten Lebensdauer niemals die klar definierten Grenzen von HSMs. Er kann auf anderen HSMs oder auf Back-up-HSMs repliziert werden.
  2. Er kann als Schlüsselverschlüsselungsschlüssel verwendet werden, um Kundenschlüssel, die von HSMs verwendet werden, direkt oder indirekt zu verpacken.

Mit HSM-Root-Schlüsseln verpackte Kundenschlüssel können auf dem HSM verwendet werden. Das HSM gibt jedoch nie den Klartext des Kundenschlüssels zurück. Das HSM verwendet den Kundenschlüssel nur für Vorgänge.

4.5.3. Datenspeicherschutz

HSMs werden nicht als dauerhafter Speicher für Schlüssel verwendet. Sie speichern Schlüssel nur, während diese verwendet werden. Da HSM-Speicher begrenzt ist, werden die HSM-Schlüssel verschlüsselt und im Cloud KMS-Schlüsseldatenspeicher gespeichert. Dieses Thema wird unter Datenspeicher-Back-End weiter unten in diesem Dokument ausführlicher beschrieben.

4.5.4. Rotationsrichtlinie

An der Schlüsselschutzstrategie von Cloud HSM sind mehrere Schlüsselarten beteiligt. Kunden rotieren ihre eigenen Schlüssel und lassen die HSM-Schlüssel von Cloud KMS rotieren.

4.5.5. Prozess für Bereitstellung und Verwaltung

Die Bereitstellung von HSMs wird in einem Lab durchgeführt, das mit zahlreichen physischen und logischen Sicherheitsmaßnahmen ausgestattet ist, z. B. Autorisierungskontrollen durch mehrere Parteien, um einen Angriff durch einen einzelnen Akteur zu verhindern.

Im Folgenden sind die Cloud HSM-Invarianten auf Systemebene aufgeführt:

  1. Kundenschlüssel können nicht als Klartext extrahiert werden.
  2. Kundenschlüssel können nicht aus der Ursprungsregion verschoben werden.
  3. Alle Konfigurationsänderungen an bereitgestellten HSMs werden mithilfe von mehreren Absicherungen geschützt.
  4. Verwaltungsvorgänge werden unter Einhaltung der Aufgabentrennung zwischen Cloud HSM-Administratoren und Logging-Administratoren protokolliert.
  5. HSMs sind so konzipiert, dass sie während des gesamten Operations-Lebenszyklus vor Manipulationen (z. B. durch das Einfügen böswilliger Hardware oder Softwareänderungen oder der nicht autorisierten Extraktion von Secrets) geschützt sind.

4.5.6. Anbietergesteuerte Firmware

HSM-Firmware ist digital vom HSM-Anbieter signiert. Google kann die HSM-Firmware nicht erstellen oder aktualisieren. Sämtliche Firmware eines Anbieters ist signiert, einschließlich Entwicklungsfirmware, die zu Testzwecken verwendet wird.

4.5.7. Regionalität

Kundenschlüssel sind aufgrund ihrer Bindung an einen spezifischen HSM-Stammschlüssel bestimmten geografischen Regionen zugeordnet. So kann beispielsweise ein Schlüssel, der spezifisch in der Region us-west1 erstellt wurde, nicht in die Region us-east1 oder in eine Multi-Region us migriert werden. Ähnlich kann ein Schlüssel, der in der Multi-Region us erstellt wurde, nicht in die oder aus der Region us-west1 migriert werden.

4.6. Cloud-KMS: Schlüsselimport

Möglicherweises möchten Sie Ihre eigenen Schlüssel in Ihre Cloud-Umgebung migrieren. 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. Mit Cloud KMS können Sie Ihre eigenen kryptografischen Schlüssel importieren, die Sie lokal oder in einem externen Schlüsselverwaltungssystem erstellt haben. 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 Signierungsmöglichkeiten auf die Cloud auszuweiten.

Im Rahmen des Schlüsselimports generiert Cloud KMS mithilfe einer der unterstützten Importmethoden einen 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.

Dieser öffentliche Verpackungsschlüssel von Cloud KMS dient dazu, die zu importierenden Schlüssel auf dem Client zu verschlüsseln. Der private Schlüssel, der diesem öffentlichen Schlüssel entspricht, wird innerhalb von Google Cloud gespeichert und dazu verwendet, den 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.

Importierte Schlüssel können mit der Schutzstufe HSM oder SOFTWARE verwendet werden.

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.

4.7. 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 Kunden stattdessen Cloud KMS verwenden, um die für die Verschlüsselung verwendeten Schlüssel zu verwalten. CMEK kann sowohl für auf Software als auch für auf Hardware gesicherte Schlüssel verwendet werden. Mit Cloud KMS können Kunden 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 umfasst zahlreiche vordefinierte IAM-Rollen, die spezifische Berechtigungen und Einschränkungen haben und bestimmten Nutzern und Dienstkonten gewährt werden können, um eine empfohlene Berechtigungstrennung durchzusetzen.

Die folgenden Themen enthalten Informationen zu Produkten, die in die Cloud KMS-Plattform eingebunden sind und CMEK unterstützen:

Die Auswirkungen von Schlüsselrotation auf die verwendete Schlüsselversion hängt davon ab, wie ein Produkt CMEKs implementiert. Im Allgemeinen werden durch Rotation von Cloud KMS-Schlüsseln die Daten im zugehörigen CMEK-Dienst nicht neu verschlüsselt. Beispielsweise wird in BigQuery ein Tabellenverschlüsselungsschlüssel nicht automatisch rotiert, wenn der mit der Tabelle verknüpfte Cloud KMS-Schlüssel rotiert wird. Vorhandene BigQuery-Tabellen verwenden weiterhin die Schlüsselversion, mit der sie erstellt wurden. Neue BigQuery-Tabellen verwenden die aktuelle Schlüsselversion. Weitere Informationen finden Sie in der Dokumentation zum jeweiligen Produkt.

Eine vollständige Liste der CMEK-Einbindungen und CMEK-konformen Dienste finden Sie in dieser Dokumentation. Google arbeitet kontinuierlich an der CMEK-Einbindung für weitere Google Cloud-Produkte.

4.8. Lebenszyklus einer Cloud KMS-Anfrage

Zur Veranschaulichung der bisher verwendeten Architekturstrukturen enthält dieser Abschnitt eine Beschreibung des Lebenszyklus einer Cloud KMS-Anfrage. Dabei wird auch auf das Löschen von Schlüsselmaterial eingegangen.

„Diagramm des Lebenszyklus einer KMS-Anfrage“

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 Google Cloud-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-Back-End oder das Cloud HSM weiter, je nach Schutzniveau des Schlüssels.
  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.

4.9. Löschen von Schlüsselmaterial

In diesem Whitepaper wird das Löschen von Daten in Google Cloud beschrieben. Da Schlüsselmaterial als Kundendaten zu betrachten ist, gilt der im Whitepaper beschriebene Ansatz für Cloud KMS. Google gibt niemals Schlüsselmaterial außerhalb von Cloud KMS weiter. Somit wird das Schlüsselmaterial auch auf Anfrage gelöscht, wenn eine Frist von 24 Stunden bis zum Löschen verstrichen ist und Back-ups abgelaufen sind. Für Kopien importierter Schlüssel, die sich außerhalb der Kontrolle von Cloud KMS befinden, wird dieser Prozess nicht garantiert.

Während Schlüsselmaterial wie oben beschrieben 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 von 24 Stunden kann der Nutzer die Schlüsselversion wiederherstellen, damit sie nicht gelöscht wird.

5. 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. Die folgende Beschreibung gilt sowohl für Funktionen von auf Software als auch auf Hardware gesicherten Schlüsseln.

5.1. 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 letzten Endes 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.

5.2. Regionalität von Cloud KMS-Ressourcen

Sie können Cloud KMS-Ressourcen an einem von vier verschiedenartigen Google Cloud-Standorten erstellen:

  • Regionale Standorte: Ein regionaler Standort besteht aus Zonen in einem bestimmten geografischen Bereich, z. B. Iowa.
  • Dual-regionale Standorte: Ein dual-regionaler Standort besteht aus Zonen an zwei geografischen Orten, z. B. Finnland und Niederlande.
  • Multiregionale Standorte: Ein multiregionaler Standort besteht aus Zonen, die über einen allgemeinen geografischen Bereich verteilt sind, z. B. die Vereinigten Staaten.
  • Globaler Standort: 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 in der Dokumentation zu Cloud KMS.

5.2.1. 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/oder 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.

5.2.2. Regionalität

In einigen Branchen müssen sich kryptografische Schlüssel an einem bestimmten Standort befinden. Wie oben 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 Kundenschlü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 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, dualen oder multiregionalen Standorten, die Sie in anderen Google Cloud-Produkten auswählen, die Sie mit CMEK verwenden möchten:

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

Cloud KMS-Datenstandort Inaktiv, in Verwendung
(einzelne Region)
Inaktiv, in Verwendung
(Dual-/Multiregion)
Softwareschlüsselmaterial Resident Resident in den Regionen, die die Dual-/Multiregion bilden.
Hardwareschlüsselmaterial (HSM) Resident Resident in den Regionen, die die Dual-/Multiregion bilden.

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

5.3. 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 der Kunde die Cloud KMS API aktiviert hat und ein aktives Abrechnungskonto hat
  • Prüfen, ob der Kunde sein Kontingent nicht überschritten hat, und Kontingentnutzung melden
  • Erzwingen von VPC Service Controls
  • Prüfen, ob der Kunde auf der Liste der zulässigen privaten Cloud-Regionen steht

5.4. Logging

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

5.4.1. Cloud-Audit-Logs

Cloud KMS zeichnet Kundenaktivität in Cloud-Audit-Logs auf. Kunden 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. Kunden 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. Kunden kontrollieren, wie lange sie diese Logs aufbewahren möchten und wer sie ansehen darf.

5.4.2. Access Transparency-Logs

Berechtigte Kunden können optional 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)

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

5.5. Datastore-Back-End

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 mehrere Stunden 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 auf Band geschrieben.

Das Cloud KMS-Team hat dokumentierte Verfahren zur Wiederherstellung von Sicherungen in Notfallsituationen.

Datenstandort: Cloud KMS-Datenspeicher-Back-ups sind in der zugehörigen Google Cloud-Region resident. 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 Kundenschlüsselmaterial vor dem Speichern verschlüsselt. Datenspeicherentwickler 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. So ist der Zugriff auf zugrunde liegende Speicherebenen (einschließlich Laufwerke oder Band) ohne Zugriff auf die Datenspeicher-Verschlüsselungsschlüssel, die im internen KMS von Google gespeichert sind, nicht einmal für die verschlüsselten Cloud KMS-Daten erlaubt.

6. Weitere Informationen

Weitere Informationen finden Sie in den folgenden Ressourcen:

Whitepaper:

Sonstige Dokumentation: