Informationen zu vom Kunden verwalteten Verschlüsselungsschlüsseln (Customer-managed Encryption Keys, CMEK)

In diesem Dokument wird beschrieben, wie Sie vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) im Cloud Key Management Service (Cloud KMS) für Ihre Cluster in Memorystore for Redis Cluster verwenden können. Außerdem wird beschrieben, welche Daten im nichtflüchtigen Speicher verschlüsselt werden und wie sich Ihre Cluster während wichtiger Ereignisse im Lebenszyklus von Schlüsseln verhalten.

Mit CMEK können Sie die kryptografischen Schlüssel steuern, die Ihre gespeicherten Daten schützen. Wenn Sie Ihre eigenen Schlüssel in Cloud KMS verwalten, haben Sie mehr Kontrolle über den Zugriff auf Schlüssel, die Rotation und die Verwendung. So können Sie strenge Compliance- und behördliche Anforderungen erfüllen.

Die Implementierung von CMEK bietet eine zusätzliche Sicherheits- und Kontrollebene für Ihre persistenten Daten wie Back-ups und Persistenzdateien. Sie können CMEK nur für neue Cluster aktivieren. Sie können CMEK nicht auf vorhandene Cluster anwenden.

Für wen ist CMEK geeignet?

CMEK ist für Organisationen mit vertraulichen oder regulierten Daten gedacht, die die Kontrolle über ihre eigenen Verschlüsselungsschlüssel benötigen. Weitere Informationen dazu, ob Sie CMEK zum Verschlüsseln dieser Daten verwenden sollten, finden Sie unter Entscheiden, ob CMEK verwendet werden soll.

Kundenverwaltete Verschlüsselung

Mit CMEK können Sie Ihre kryptografischen Schlüssel verwenden, um gespeicherte Daten in Clustern zu schützen. Zum Verschlüsseln dieser Daten verwendet Memorystore for Redis Cluster von Google verwaltete Datenverschlüsselungsschlüssel (Data Encryption Keys, DEKs) und vom Kunden verwaltete Schlüsselverschlüsselungsschlüssel (Key Encryption Keys, KEKs).

Sie können die folgenden Verschlüsselungsebenen verwenden:

  • DEK-Verschlüsselung: DEKs verschlüsseln Daten in Memorystore for Redis Cluster.
  • KEK-Verschlüsselung: KEKs verschlüsseln DEKs.

Memorystore for Redis Cluster verwendet KEKs zum Verschlüsseln von DEKs und DEKs zum Verschlüsseln der gespeicherten Daten. Wenn Sie CMEK verwenden, können Sie die KEKs verwalten, mit denen die DEKs in Ihrem Cluster verschlüsselt werden.

Im folgenden Diagramm wird gezeigt, wie ein Cluster CMEK zum Verschlüsseln von Daten verwendet. Daten, die in die Speicherinfrastruktur von Google hochgeladen werden, werden in Blöcke aufgeteilt und jeder Block wird mit einem eigenen DEK verschlüsselt. Cloud KMS stellt den KEK zum Verschlüsseln der DEKs bereit und die Speicherinfrastruktur von Google verteilt sowohl die verschlüsselten Datenblöcke als auch die verschlüsselten DEKs im System.

Die Daten werden in die Speicherinfrastruktur von Google hochgeladen und in Blöcke unterteilt. Jeder Block wird mit einem eigenen DEK verschlüsselt. Die DEKs werden dann mit einem KEK verschlüsselt, der aus Cloud KMS abgerufen wird. Die verschlüsselten Blöcke und verschlüsselten DEKs werden über die Speicherinfrastruktur verteilt.

Das folgende Diagramm zeigt, wie Memorystore for Redis Cluster Daten entschlüsselt, die mit CMEK verschlüsselt sind. Um auf diese verschlüsselten Daten zuzugreifen, sendet Memorystore for Redis Cluster eine Anfrage an Cloud KMS, das den KEK verwaltet, um den DEK zu entschlüsseln. Cloud KMS gibt dann den entschlüsselten DEK zurück, den der Cluster zum Entschlüsseln der gespeicherten Daten verwendet.

Mit DEK verschlüsselter und mit dem verschlüsselten DEK gespeicherter Datenblock. Eine Anfrage zum Entschlüsseln des DEK wird an Cloud KMS gesendet, in dem der KEK gespeichert wird. Cloud KMS gibt den entschlüsselten DEK zurück.

Welche Daten werden mit CMEK verschlüsselt?

Mit CMEK werden die folgenden Arten von Kundendaten verschlüsselt, die im permanenten Speicher gespeichert sind:

  • Sicherungen: Mit Sicherungen können Sie Ihre Daten zu einem bestimmten Zeitpunkt wiederherstellen sowie exportieren und analysieren. Sicherungen sind auch für die Notfallwiederherstellung, Datenmigration, Datenfreigabe und Compliance-Szenarien nützlich.
  • Persistenz: Memorystore for Redis-Cluster unterstützt zwei Arten der Persistenz:
    • RDB-Persistenz:Die Redis-Datenbankfunktion (RDB) schützt Ihre Daten, indem Snapshots Ihrer Daten in einem langlebigen Speicher gespeichert werden.
    • AOF-Persistenz:Bei dieser Funktion hat die Datenlanglebigkeit Priorität. Dabei werden Daten dauerhaft gespeichert, indem jeder Schreibbefehl in einer Logdatei namens „Append-Only File“ (AOF) aufgezeichnet wird. Bei einem Systemausfall oder Neustart spielt der Server die Befehle der AOF-Datei sequenziell ab, um Ihre Daten wiederherzustellen.
  • Metadaten zu Sicherheitsfunktionen wie der einfachen tokenbasierten Authentifizierung und der Verschlüsselung während der Übertragung. Weitere Informationen finden Sie unter Sicheren Zugriff auf Ihre Cluster mit einfacher tokenbasierter Authentifizierung und Verschlüsselung während der Übertragung.

CMEK-Komponenten

In den folgenden Abschnitten werden die Anforderungen und Verhaltensweisen der Dienstkonten, kryptografischen Schlüssel, Schlüsselversionen und Organisationsrichtlinien beschrieben, aus denen sich Ihre CMEK-Architektur zusammensetzt.

Dienstkonten

Wenn Sie einen CMEK-fähigen Cluster erstellen möchten, müssen Sie dem Memorystore for Redis-Cluster-Dienstkonto, das das folgende Format verwendet, die Rolle roles/cloudkms.cryptoKeyEncrypterDecrypter zuweisen:

service-PROJECT_NUMBER@cloud-redis.iam.gserviceaccount.com

Wenn Sie diese Berechtigung gewähren, kann das Dienstkonto den Schlüsselzugriff von Cloud KMS anfordern.

Schlüssel

In Cloud KMS müssen Sie einen Schlüsselbund und dann einen kryptografischen Schlüssel erstellen, der einen symmetrischen Verschlüsselungsalgorithmus verwendet. Wenn Sie einen Cluster erstellen, wählen Sie diesen Schlüssel aus, um den Cluster zu verschlüsseln. Sie können ein Projekt sowohl für Schlüssel als auch für Cluster erstellen oder für beide jeweils ein separates Projekt erstellen.

CMEK ist an allen Clusterstandorten verfügbar. Sie müssen den Schlüsselbund und den Schlüssel in derselben Region erstellen, in der Sie den Cluster erstellen möchten. Bei einem Cluster mit mehreren Regionen müssen Sie den Schlüsselbund und den Schlüssel auf denselben Standort wie den Cluster festlegen. Wenn die Regionen oder Standorte nicht übereinstimmen, schlägt eine Anfrage zum Erstellen des Clusters fehl.

Für die Ressourcen-ID des Schlüssels wird bei CMEK das folgende Format verwendet:

projects/CMEK_ENABLED_PROJECT/locations/REGION/keyRings/KEY_RING_NAME/cryptoKeys/KEY_NAME

Weitere Informationen zum Suchen der Ressourcen-IDs vorhandener Schlüssel finden Sie unter Cloud KMS-Ressourcen-ID abrufen.

Externe Schlüssel

Im Rahmen Ihrer CMEK-Strategie können Sie externe Schlüssel verwenden. Verwenden Sie dazu Cloud External Key Manager (Cloud EKM), um Daten in Google Cloud mit von Ihnen verwalteten externen Schlüsseln zu verschlüsseln.

Wenn Sie einen Cloud EKM-Schlüssel verwenden, hat Google keine Kontrolle über die Verfügbarkeit Ihrer extern verwalteten Schlüssel. Wenn beim Erstellen des Clusters kein Schlüssel verfügbar ist, wird der Cluster in Memorystore for Redis Cluster nicht erstellt. Wenn der externe Schlüssel nach dem Erstellen des Clusters zu einem beliebigen Zeitpunkt nicht mehr verfügbar ist, deaktiviert Memorystore for Redis Cluster Sicherungen und Persistenz. Reguläre In-Memory-Caching-Vorgänge werden jedoch weiterhin ausgeführt.

Weitere Überlegungen zur Verwendung externer Schlüssel finden Sie unter Überlegungen.

Schlüsselversionen

In Cloud KMS wird das kryptografische Schlüsselmaterial, das Sie zum Ver- und Entschlüsseln Ihrer Daten verwenden, in einer Schlüsselversion gespeichert. Ein einzelner Schlüssel kann mehrere Schlüsselversionen enthalten. Wenn Sie einen Schlüssel rotieren, erstellen Sie eine Schlüsselversion.

In den folgenden Abschnitten wird beschrieben, wie sich Ihre Cluster und die darin geschützten Daten bei wichtigen Lebenszyklusereignissen wie dem Deaktivieren, Löschen, Rotieren, Aktivieren oder Wiederherstellen von Schlüsselversionen verhalten. In den Abschnitten wird auch erläutert, welche Auswirkungen es hat, wenn Sie den Zugriff auf einen Cloud KMS-Schlüssel widerrufen oder ihn ersetzen. Außerdem finden Sie dort eine Anleitung zum manuellen Verschlüsseln von Daten.

CMEK-Schlüsselversion deaktivieren oder löschen

Es kann vorkommen, dass Sie mit CMEK verschlüsselte Daten dauerhaft unzugänglich machen möchten, z. B. wenn Sie einen Datenverlust beheben. Um diese sichere Datenvernichtung (auch als kryptografisches Löschen bezeichnet) zu erreichen, löschen Sie die Schlüsselversion. Weitere Informationen zum Löschen von Schlüsselversionen finden Sie unter Schlüsselversionen löschen und wiederherstellen.

Wenn Sie Ihre primäre Schlüsselversion deaktivieren oder löschen, gelten für Sicherungen und Persistenz die folgenden Bedingungen.

Sicherungen

Wenn Sie Ihre Primärschlüsselversion zerstören, gelten für die Sicherungen Ihres Clusters die folgenden Einschränkungen:

  • Sie können keine On-Demand- oder automatischen Sicherungen erstellen. Wenn Sie jedoch eine ältere Schlüsselversion aktivieren, können Sie auf alle Sicherungen zugreifen, die Sie mit dieser Schlüsselversion erstellt haben.
  • Sie können automatische Sicherungen erst aktualisieren oder wieder aktivieren, wenn Sie die Primärschlüsselversion aktivieren oder wiederherstellen. Weitere Informationen finden Sie unter Primäre CMEK-Schlüsselversion aktivieren oder wiederherstellen.
Persistenz

Wenn Sie die Hauptschlüsselversion löschen, gelten für die Persistenz für Ihren Cluster die folgenden Einschränkungen:

  • Wenn Sie Ihren Cluster für die Verwendung von Persistenz konfigurieren, wird die Persistenz in Memorystore for Redis Cluster deaktiviert, wenn die Schlüsselversion nicht mehr verfügbar ist. Die Nutzung von Persistenz wird Ihnen nicht mehr in Rechnung gestellt.
  • Memorystore for Redis Cluster schreibt keine neuen Daten mit dem CMEK in den nichtflüchtigen Speicher.
  • Memorystore for Redis Cluster kann keine vorhandenen Daten lesen, die sich im nichtflüchtigen Speicher befinden.
  • Sie können die Persistenz erst aktualisieren oder wieder aktivieren, wenn Sie die Primärschlüsselversion aktivieren oder wiederherstellen.

Wenn Sie Ihre primäre Schlüsselversion aktivieren, aber eine ältere Schlüsselversion deaktivieren oder löschen, gelten für Back-ups und Persistenz die folgenden Bedingungen:

  • Sie können Sicherungen erstellen. Wenn eine Sicherung jedoch mit einer älteren Schlüsselversion verschlüsselt ist, die deaktiviert oder gelöscht wurde, bleibt die Sicherung unzugänglich.
  • Wenn Sie die Persistenz aktivieren, bleibt sie aktiviert. Wenn die ältere Schlüsselversion, die für die Persistenz verwendet wird, deaktiviert oder gelöscht wird, führt Memorystore for Redis Cluster ein Update durch, das dem bei der Wartung verwendeten Update ähnelt, und verschlüsselt die Daten mit der primären Schlüsselversion neu.

Zugriff auf einen Cloud KMS-Schlüssel widerrufen

Wenn Sie den Zugriff auf einen aktiven Cloud KMS-Schlüssel widerrufen, indem Sie den Schlüssel deaktivieren oder die IAM-Berechtigungen für den Schlüssel entfernen, priorisiert Memorystore for Redis-Cluster die Verfügbarkeit des primären Cache. Regelmäßige In-Memory-Caching-Vorgänge werden weiterhin für die Bereitstellung von Traffic verwendet.

Sicherungen und Persistenz sind jedoch deaktiviert. Memorystore for Redis Cluster schreibt sofort keine neuen Daten mehr auf die Festplatte und liest keine Daten von der vom Kunden verschlüsselten Festplatte in den Arbeitsspeicher.

Primäre CMEK-Schlüsselversion rotieren

Wenn Sie Ihre primäre Schlüsselversion rotieren und eine neue primäre Schlüsselversion erstellen, gelten für Back-ups und Persistenz die folgenden Bedingungen:

  • Die neueste primäre Schlüsselversion Ihres CMEK verschlüsselt neue Sicherungen.
  • Vorhandene Sicherungen werden nicht neu verschlüsselt.
  • Für die Persistenz ergreifen die Knoten keine Maßnahmen. Die Knoten verwenden die ältere Schlüsselversion bis zum nächsten Wartungsereignis.

CMEK-geschützte Daten manuell neu verschlüsseln

Memorystore for Redis Cluster unterstützt keine On-Demand-Neuverschlüsselung gespeicherter Daten. Sie können keinen Prozess manuell auslösen, um eine neue Schlüsselversion zum erneuten Verschlüsseln vorhandener Sicherungen oder aktiver Persistenzdateien zu verwenden. Sie können die neue Schlüsselversion jedoch verwenden, um neu geschriebene Daten zu verschlüsseln.

Wenn Sie einen Schlüssel rotieren und einen Cluster zwingen müssen, die neue Schlüsselversion zu verwenden, gelten für Back-ups und Persistenz die folgenden Bedingungen:

Sicherungen

Vorhandene Sicherungen können nicht neu verschlüsselt werden. Wenn alle Daten aus Compliance-Gründen mit dem neuesten Schlüssel verschlüsselt werden müssen, erstellen Sie eine Sicherung mit diesem Schlüssel und löschen Sie dann vorhandene Sicherungen manuell. Sie können diese Sicherung auch in einen Cloud Storage-Bucket exportieren, damit der Cloud Storage-Verschlüsselungsschlüssel verwendet wird.

Persistenz

Wenn Sie erzwingen möchten, dass der Cluster einen neuen Cloud KMS-Schlüssel verwendet, können Sie eine simulierte Wartung für den Cluster ausführen. Nach Abschluss dieses Vorgangs kann Memorystore for Redis Cluster Persistenzdaten mit der aktualisierten primären Schlüsselversion schreiben.

Geschützten Cloud KMS-Schlüssel ersetzen

Wenn Sie einen geschützten Cloud KMS-Schlüssel durch einen anderen Schlüssel oder eine neue primäre Schlüsselversion ersetzen, wendet Memorystore for Redis Cluster diese Änderung nur auf zukünftige Vorgänge an.

Das Ersetzen eines geschützten Schlüssels wirkt sich folgendermaßen auf Ihre Ressourcen aus:

  • Sicherungen: Alle nachfolgenden Sicherungen werden mit dem neuen Schlüssel verschlüsselt. Vorhandene Sicherungen behalten ihre ursprünglichen Schlüssel.
  • Persistenz: Beim nächsten Neustart des Clusters oder bei einem Wartungsereignis wird der neue Schlüssel verwendet.
  • Primärer Cache: Das Ersetzen dieses Schlüssels hat keine Auswirkungen. Mit CMEK werden keine In-Memory-Daten verschlüsselt, da diese Daten nicht als gespeicherte Daten gelten.

Primäre CMEK-Schlüsselversion aktivieren oder wiederherstellen

Wenn Sie Ihre primäre Schlüsselversion aktivieren oder wiederherstellen, gelten für Sicherungen und Persistenz die folgenden Bedingungen:

  • Sie können wieder On-Demand- und automatische Sicherungen erstellen.
  • Memorystore for Redis Cluster führt ein Update durch, das dem bei der Wartung verwendeten Update ähnelt, und reaktiviert die Persistenz.

Einschränkungen für Organisationsrichtlinien

Memorystore for Redis Cluster unterstützt Einschränkungen für Organisationsrichtlinien für CMEK. Mit diesen Einschränkungen können Sie den CMEK-Schutz für Ihre Cluster erzwingen und einschränken, welche Cloud KMS-Schlüssel Sie für diesen Schutz verwenden können.

Sie können die folgenden Einschränkungen für Organisationsrichtlinien konfigurieren:

  • constraints/gcp.restrictNonCmekServices: Mit dieser Einschränkung können Sie die CMEK-Verschlüsselung für Ihre Cluster erzwingen. Wenn sich die Memorystore for Redis Cluster API in der Richtlinienliste Deny für diese Einschränkung befindet, können Sie keine Cluster ohne CMEK-Schutz erstellen.
  • constraints/gcp.restrictCmekCryptoKeyProjects: Mit dieser Einschränkung können Sie einschränken, welche Cloud KMS-Schlüssel Sie für den CMEK-Schutz verwenden können. Wenn Sie diese Einschränkung konfigurieren, müssen für die Cluster, die CMEK-Verschlüsselung verwenden, Schlüssel aus einem zulässigen Projekt, Ordner oder einer Organisation verwendet werden.

Da sowohl Memorystore for Redis Cluster als auch Memorystore for Redis denselben Endpunkt (redis.googleapis.com) verwenden, können Sie CMEK für Cluster nicht unabhängig von Memorystore for Redis-Instanzen erzwingen.

Weitere Informationen zu den CMEK-bezogenen Organisationsrichtlinieneinschränkungen, die Google für Memorystore for Redis Cluster verwaltet, finden Sie unter Einschränkungen für Organisationsrichtlinien.

Preise

Memorystore for Redis Cluster berechnet CMEK-fähige Cluster wie jeden anderen Cluster. Es fallen keine zusätzlichen Kosten an. Weitere Informationen finden Sie unter Preise für Memorystore for Redis Cluster.

Sie verwenden die Cloud KMS API, um CMEK zu verwalten. Wenn Sie einen Cluster mit CMEK erstellen, verwendet Memorystore den Schlüssel regelmäßig, um Daten zu verschlüsseln.

Ihnen werden von Cloud KMS die Kosten für den Schlüssel sowie die Ver- und Entschlüsselungsvorgänge in Rechnung gestellt, wenn Memorystore for Redis Cluster den Schlüssel verwendet. Weitere Informationen finden Sie unter Cloud KMS – Preise.

Beschränkungen

Bei der Verwendung von CMEK mit Memorystore for Redis Cluster gelten die folgenden Einschränkungen:

  • Sie können CMEK nicht für einen vorhandenen Cluster aktivieren.
  • Der Schlüssel, der Schlüsselbund und der Cluster müssen sich in derselben Region befinden.
  • Sie müssen den symmetrischen Verschlüsselungsalgorithmus für Ihren Schlüssel verwenden.
  • Verschlüsselungs- und Entschlüsselungsraten für Cloud KMS unterliegen einem Kontingent.

Nächste Schritte