Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK)

In Bigtable werden inaktive Kundeninhalte standardmäßig verschlüsselt. Die Verschlüsselung wird von Bigtable durchgeführt. Zusätzliche Maßnahmen Ihrerseits sind nicht erforderlich. Diese Option wird Google-Standardverschlüsselung genannt.

Wenn Sie Ihre Verschlüsselungsschlüssel selbst verwalten möchten, können Sie vom Kunden verwaltete Verschlüsselungsschlüssel (CMEKs, Customer-Managed Encryption Keys) in Cloud KMS mit CMEK-integrierten Diensten wie Bigtable verwenden. Mit Cloud KMS-Schlüsseln haben Sie die Kontrolle über Schutzlevel, Speicherort, Rotationszeitplan, Nutzungs- und Zugriffsberechtigungen sowie über kryptografische Grenzen. Mit Cloud KMS können Sie außerdem Audit-Logs aufrufen und den Lebenszyklus von Schlüsseln steuern. Statt es Google zu überlassen, die symmetrischen Schlüsselverschlüsselungsschlüssel (Key Encryption Keys, KEKs) zum Schutz Ihrer Daten zu steuern und zu verwalten, können Sie diese auch über Cloud KMS steuern und verwalten.

Nachdem Sie Ihre Ressourcen mit CMEKs eingerichtet haben, ähnelt der Zugriff auf Ihre Bigtable-Ressourcen der Verwendung der Google-Standardverschlüsselung. Weitere Informationen zu den Verschlüsselungsoptionen finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK).

Auf dieser Seite wird CMEK für Bigtable beschrieben. Eine Anleitung zum Ausführen von CMEK-Aufgaben mit Bigtable finden Sie unter CMEK verwenden.

Features

  • Sicherheit: CMEK bietet die gleiche Sicherheitsstufe wie die Standardverschlüsselung von Google, darüber hinaus jedoch mehr administrative Steuerung.

  • Datenzugriffssteuerung: Administratoren können den Schlüssel, der zum Schutz inaktiver Daten in Bigtable verwendet wird, rotieren, den Zugriff darauf verwalten und den zum Schutz inaktiver Daten in Bigtable verwenden Schlüssel deaktivieren oder löschen.

  • Prüfbarkeit: Alle Aktionen für Ihre CMEK-Schlüssel werden geloggt und in Cloud Logging angezeigt. Cloud EKM-Schlüssel unterstützen Key Access Justification, wodurch allen Schlüsselanfragen ein Begründungsfeld hinzugefügt wird. Mit ausgewählten Partnern für die externe Schlüsselverwaltung können Sie diese Anfragen basierend auf der Begründung automatisch genehmigen oder ablehnen.

  • Vergleichbare Leistung: CMEK-geschützte Instanzen bieten eine vergleichbare Leistung für Bigtable-Instanzen, die die Standardverschlüsselung von Google verwenden.

  • Flexibilität: Sie können denselben CMEK-Schlüssel in mehreren Projekten, Instanzen oder Clustern verwenden oder je nach Ihren Geschäftsanforderungen auch separate Schlüssel verwenden.

  • Regionenübergreifender Schutz: Sie können CMEK in Instanzen mit Clustern in jeder Region aktivieren, in der Bigtable verfügbar ist. Jeder Cluster ist durch einen CMEK-Schlüssel in der Region dieses Clusters geschützt.

Preise

Cloud KMS berechnet die Kosten für den Schlüssel und alle kryptografischen Vorgänge, die mit diesem Schlüssel ausgeführt werden. Weitere Informationen finden Sie unter Cloud KMS – Preise.

Die Betriebskosten werden Ihnen in Rechnung gestellt, wenn Bigtable den Cloud KMS-Schlüssel anweist, einen Verschlüsselungs- oder Entschlüsselungsvorgang durchzuführen. Verschlüsselungs- oder Entschlüsselungsanfragen werden aus jeder Tabelle in jedem Cluster der Instanz gesendet. Da Bigtable die Umschlagverschlüsselung verwendet, sind diese Kosten pro Tabelle in der Regel gering, da die Anzahl der erwarteten kryptografischen Vorgänge gering ist. Wenn Sie viele Tabellen in einer CMEK-geschützten Instanz speichern, sind Ihre Kosten höher.

Für die Verwendung von CMEK-fähigen Instanzen fallen keine zusätzlichen Bigtable-Kosten an.

Mit CMEK geschützte Inhalte

In einer CMEK-geschützten Instanz verwendet Bigtable Ihren CMEK-Schlüssel, um Ihre inaktiven Daten zu schützen. Dies schließt Daten in allen Tabellen im Cluster ein. Daten, die sowohl auf HDD- als auch auf SSD-Speicher gespeichert sind, sind geschützt.

Einige Daten werden durch die Google-Standardverschlüsselung von inaktiven Daten, aber nicht vom CMEK-Schlüssel geschützt:

  • Eine Teilmenge von Zeilenschlüsseln, die Bereichsgrenzen markieren und für das Routing verwendet werden
  • Debugging von Daten, einschließlich Kern-Dumps und Betriebslogs
  • Daten bei der Übertragung oder im Speicher
  • Eine Teilmenge von Zeitstempelwerten, die für die automatische Speicherbereinigung verwendet werden

Bigtable verwendet für die inaktiven Daten die Umschlagsverschlüsselung. Der CMEK-Schlüssel wird als Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) verwendet, um andere von Bigtable verwendete Schlüssel zu verschlüsseln. Wenn Sie den CMEK-Schlüssel rotieren, muss Bigtable nur die Zwischenschlüssel neu verschlüsseln.

CMEK aktivieren

Auf übergeordneter Ebene gehen Sie so vor, um CMEK mit Bigtable zu verwenden:

  1. Erstellen und konfigurieren Sie in jeder Region, in der sich die Cluster Ihrer Instanz befinden werden, einen CMEK-Schlüssel.
  2. Erstellen Sie eine neue Bigtable-Instanz und wählen Sie einen CMEK-Schlüssel für jeden Cluster in der Instanz aus. Der CMEK-Schlüssel eines Clusters muss sich in derselben Region wie der Cluster befinden.
  3. Planen Sie eine Schlüsselrotation für jeden Schlüssel.

Anwendungen, die Bigtable verwenden, müssen beim Lesen, Schreiben oder Löschen von Daten keine Schlüssel- oder Verschlüsselungskonfiguration angeben. Bigtable kann in Ihrem Namen auf den Schlüssel zugreifen, nachdem Sie dem Bigtable-Dienst-Agent die Rolle Cloud KMS-Verschlüsseler/Entschlüsseler zugewiesen haben.

Eine ausführliche Anleitung finden Sie unter CMEK verwenden.

Wenn Sie mit CMEK für Bigtable arbeiten, können Sie Folgendes verwenden:

Sie können auch direkt auf die Cloud Bigtable Admin API zugreifen. Dies wird aber nur empfohlen, wenn Sie keine Bigtable-Clientbibliothek verwenden können, die Sicherungsaufrufe an die API sendet.

Schlüsselverwaltung

Vorgänge zur Schlüsselverwaltung werden mit Cloud KMS ausgeführt. Bigtable kann Schlüsseländerungen erst erkennen oder darauf reagieren, wenn sie von Cloud KMS weitergegeben wurden. Bei einigen Vorgängen, z. B. beim Deaktivieren oder Löschen eines Schlüssels, kann es bis zu vier Stunden dauern, bis Änderungen wirksam werden. Änderungen an den Berechtigungen eines Schlüssels erfolgen normalerweise schneller.

Nachdem Sie mindestens eine Tabelle in einer CMEK-geschützten Instanz erstellt haben, validiert Bigtable alle 5 Minuten den Schlüssel für jede Tabelle in jedem Cluster.

Wenn Bigtable einen deaktivierten Schlüssel erkennt, wird er nacheinander kaskadierend deaktiviert, bis alle Cluster in der Instanz deaktiviert sind. Nachdem der erste Cluster meldet, dass ein Schlüssel deaktiviert oder gelöscht wurde, können bis zur Deaktivierung der Instanz einige Datenanfragen erfolgreich sein, während andere einen Fehler zurückgeben. Alle Datenvorgänge, die an einen deaktivierten Cluster gesendet werden, geben den Fehler FAILED_PRECONDITION oder NOT_FOUND zurück.

Da die Bigtable-Replikation letztendlich konsistent ist, besteht die Möglichkeit, dass ein Cluster eine Schreibanfrage bestätigt, aber noch nicht auf die anderen Cluster in der Instanz repliziert hat, bevor er deaktiviert wurde.

Die automatische Deaktivierung aller Cluster in einer Instanz in Bigtable nach dem Deaktivieren eines Schlüssels kann bis zu mehreren Stunden dauern. Zur Vermeidung dieses Zustands empfehlen wir, immer alle Schlüssel einer Instanz gleichzeitig zu deaktivieren.

Wenn ein Bigtable-Cluster deaktiviert ist, sind die folgenden Verwaltungsvorgänge für die gesamte Instanz eingeschränkt:

  • Cluster erstellen
  • Cluster löschen
  • Tabelle erstellen
  • Spaltenfamilie ändern
  • Tabelle wiederherstellen

Sie können die Instanz dennoch löschen, eine Tabelle löschen und eine Sicherung löschen.

Wenn Bigtable-Aufrufe an Cloud KMS erkennen, dass ein zuvor deaktivierter Schlüssel wieder aktiviert wurde, stellt Cloud KMS den Zugriff auf den Bigtable-Cluster automatisch wieder her.

Wenn ein Cloud KMS-Schlüssel gelöscht wurde, ist jede Bigtable-Instanz mit einem Cluster, der mit diesem Schlüssel verschlüsselt wurde, dauerhaft unzugänglich.

Umgang mit einem nicht verfügbaren Schlüsselstatus

In seltenen Fällen, z. B. wenn Cloud KMS nicht verfügbar ist, kann Bigtable den Status eines Schlüssels nicht aus Cloud KMS abrufen.

Wenn ein Bigtable-Cluster durch einen Schlüssel geschützt ist, der aktiviert wird, wenn Bigtable zum ersten Mal nicht mit Cloud KMS kommunizieren kann, unterstützt Bigtable weiterhin vollständige Instanzvorgänge auf Best-Effort-Basis. Dazu werden im Cache gespeicherte Schlüssel verwendet, die für einen Zeitraum von bis zu einer Stunde vom Cloud KMS-Schlüssel abgeleitet werden, um die Auswirkungen solcher Vorfälle auf Ihre Arbeitslast zu minimieren.

Wenn Bigtable nach einer Stunde immer noch keine Verbindung zu Cloud KMS herstellen kann, stellt Bigtable die Instanz als Schutzmaßnahme offline. Die Daten in der Bigtable-Instanz bleiben so lange unzugänglich, bis die Instanz wieder eine Verbindung zu Cloud KMS herstellen kann. Cloud KMS antwortet daraufhin, dass der Schlüssel aktiv ist.

Wenn ein Cluster in Ihrer Bigtable-Instanz dagegen durch einen Schlüssel geschützt ist, der deaktiviert wurde, bevor Bigtable zum ersten Mal nicht mit Cloud KMS kommunizieren kann, bleibt Ihre Instanz bis zu dem Zeitpunkt unzugänglich, zu dem sie wieder eine Verbindung zu Cloud KMS herstellen und Sie den Schlüssel wieder aktiviert haben.

Überlegungen zu externen Schlüsseln

Wenn Sie einen Cloud EKM verwenden, hat Google keine Kontrolle über die Verfügbarkeit Ihres extern verwalteten Schlüssels im Partnersystem für die externe Schlüsselverwaltung.

Wenn der extern verwaltete Schlüssel nicht verfügbar ist, unterstützt Bigtable Clustervorgänge mit einer im Cache gespeicherten Version des Schlüssels bis zu eine Stunde lang weiter.

Wenn Bigtable nach einer Stunde immer noch keine Verbindung zu Cloud KMS herstellen kann, stellt es die Instanz als Schutzmaßnahme offline. Die Daten in der Bigtable-Instanz bleiben so lange unzugänglich, bis die Instanz wieder eine Verbindung zu Cloud KMS herstellen kann. Cloud KMS antwortet daraufhin, dass der externe Schlüssel aktiv ist.

Wenn Sie einen externen Schlüssel für eine Bigtable-Instanz mit Clustern in mehr als einer Region verwenden möchten, stellen Sie sicher, dass Ihr Schlüssel in diesen Regionen unterstützt wird. Weitere Informationen finden Sie unter Externe Schlüsselmanager und Regionen. Darüber hinaus sollten Sie keine Kombination aus externen und nicht externen Schlüsseln in derselben Instanz verwenden.

Weitere Informationen zur Verwendung externer Schlüssel mit Cloud Key Management Service finden Sie unter Cloud External Key Manager (Cloud EKM).

Organisationsrichtlinien

Bigtable unterstützt Einschränkungen für Organisationsrichtlinien, damit die CMEK-Nutzung in einer Organisation gewährleistet werden kann. Weitere Informationen zur Verwendung von Organisationsrichtlinien finden Sie unter Organisationsrichtlinien für CMEK.

Sicherungen

Wie andere Daten wird eine Sicherung durch den CMEK-Schlüssel für den Cluster geschützt, in dem die Sicherung gespeichert wird. Neue Tabellen, die aus einer Sicherung wiederhergestellt werden, sind durch den CMEK-Schlüssel oder die Schlüssel für den Cluster geschützt, in dem sie wiederhergestellt werden. Weitere Informationen dazu, wie sich CMEK auf Sicherungen und Wiederherstellungsvorgänge auswirkt, finden Sie unter Sicherungen. Informationen zum Erstellen oder Wiederherstellen aus einer Sicherung finden Sie unter Sicherungen verwalten.

Logging

Sie können die Anfragen prüfen, die Bigtable in Cloud Logging in Ihrem Namen an Cloud KMS sendet, wenn Sie für das Cloud KMS API in Ihrem Projekt Cloud KMS-Audit-Logs aktiviert haben. In jedem Cluster gehen etwa alle fünf Minuten pro Tabelle einige Logeinträge ein.

Beschränkungen

  • CMEK können nur auf Clusterebene konfiguriert werden. Sie können CMEK nicht für Sicherungen, Tabellen oder Anwendungsprofile konfigurieren.

  • Der CMEK-Schlüssel eines Clusters muss sich in derselben Region wie der Cluster befinden. Achten Sie beim Erstellen eines Cloud KMS-Schlüsselbunds darauf, die Region auszuwählen, die Ihrer geplanten zonalen Konfiguration von Bigtable entspricht.

  • Die Verschlüsselungskonfiguration einer Bigtable-Ressource (eine Instanz, ein Cluster, eine Tabelle oder eine Sicherung) ist unveränderlich.

    • Nicht-CMEK-Instanzen können nicht auf die Verwendung von CMEK umgestellt werden.
    • CMEK-Instanzen können nicht auf die Verwendung der Standardverschlüsselung von Google umgestellt werden.
    • Mit einem CMEK-Schlüssel erstellte Cluster können nicht so neu konfiguriert werden, dass ein anderer Schlüssel verwendet wird.

  • Durch CMEK geschützte Bigtable-Ressourcen (Instanzen, Cluster, Tabellen oder Sicherungen), die an einen Schlüssel gebunden sind, der infolge einer durch einen Nutzer ausgelösten Aktion (z. B. das Deaktivieren oder Löschen eines Schlüssels oder durch Aufheben der Rolle "Verschlüsseler/Entschlüsseler") für mehr als 30 aufeinanderfolgende Tage nicht mehr zugänglich ist, werden automatisch gelöscht.

  • Wenn Sie einen deaktivierten CMEK-Schlüssel wieder aktivieren, um den Zugriff auf Bigtable-Instanzen wiederherzustellen, die durch diesen Schlüssel geschützt sind, kann bei einigen Data API-Anfragen eine Zeitüberschreitung auftreten, während Ihre Daten wieder online gehen.

  • Bis zu fünf Minuten, nachdem eine Tabelle in einer CMEK-geschützten Instanz erstellt wurde, können die Schlüsselversion und der Schlüsselstatus als unbekannt gemeldet werden. Alle Daten, die in der Tabelle geschrieben werden, sind während dieser Zeit jedoch weiterhin durch den CMEK-Schlüssel geschützt.

  • Das Deaktivieren oder Löschen von nur einer Version anstelle aller von Bigtable verwendeten Versionen eines Schlüssels kann zu unvorhersehbarem Verhalten führen. Deaktivieren oder löschen Sie immer alle Versionen eines CMEK-Schlüssels.

Nächste Schritte