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

In diesem Dokument wird beschrieben, wie Sie kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) in Cloud Key Management Service (Cloud KMS) für Ihre Cluster in Memorystore for Redis Cluster verwenden können. Außerdem wird erläutert, welche Daten im nichtflüchtigen Speicher verschlüsselt werden und wie sich Ihre Cluster bei Ereignissen 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 von Schlüsseln. So können Sie strenge Compliance- und gesetzliche Anforderungen erfüllen.

Die Implementierung von CMEK bietet eine zusätzliche Sicherheits- und Kontrollschicht für Ihre persistenten Daten wie Sicherungen und Persistenzdateien. Sie können CMEK nur für neue Cluster aktivieren. CMEK kann nicht auf vorhandene Cluster angewendet werden.

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 Entscheidung über die Verwendung von CMEK.

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 kundenverwaltete 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, die die DEKs in Ihrem Cluster verschlüsseln.

Das folgende Diagramm zeigt, 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 wurden. 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, mit dem der Cluster die gespeicherten Daten entschlüsselt.

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?

CMEK verschlüsselt die folgenden Arten von Kundendaten, die im persistenten Speicher gespeichert sind:

  • Sicherungen: Mit Sicherungen können Sie Ihre Daten zu einem bestimmten Zeitpunkt wiederherstellen sowie Daten exportieren und analysieren. Sicherungen sind auch nützlich für Notfallwiederherstellung, Datenmigration, Datenaustausch und Compliance-Szenarien.
  • 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 im dauerhaften Speicher gespeichert werden.
    • AOF-Persistenz:Bei dieser Funktion hat die Datendauerhaftigkeit Priorität. Daten werden dauerhaft gespeichert, indem jeder Schreibbefehl in einer Logdatei namens Append-Only File (AOF) aufgezeichnet wird. Bei einem Systemausfall oder Neustart spielt der Server die AOF-Dateibefehle sequenziell ab, um Ihre Daten wiederherzustellen.

CMEK-Komponenten

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

Dienstkonten

Um einen CMEK-fähigen Cluster zu erstellen, müssen Sie dem Memorystore for Redis Cluster-Dienstkonto die Rolle roles/cloudkms.cryptoKeyEncrypterDecrypter zuweisen. Das Dienstkonto hat das folgende Format:

service-PROJECT_NUMBER@cloud-redis.

Durch das Gewähren dieser Berechtigung kann das Dienstkonto den Zugriff auf Schlüssel 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 für beide Schlüssel und Cluster oder verschiedene Projekte für jeden von ihnen 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 multiregionalen Cluster 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 verwendet CMEK das folgende Format:

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

Weitere Informationen zum Ermitteln 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 ein Schlüssel beim Erstellen des Clusters nicht verfügbar ist, wird der Cluster von Memorystore for Redis Cluster nicht erstellt.

Schlüsselversionen

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

In den folgenden Abschnitten wird beschrieben, wie sich Ihre Cluster und ihre geschützten Daten bei Ereignissen im Lebenszyklus von Schlüsseln verhalten, z. B. beim Deaktivieren, Löschen, Rotieren, Aktivieren oder Wiederherstellen von Schlüsselversionen. Außerdem wird erläutert, welche Auswirkungen das Widerrufen des Zugriffs auf einen Cloud KMS-Schlüssel oder das Ersetzen eines Cloud KMS-Schlüssels hat. Außerdem finden Sie eine Anleitung zum manuellen Neuverschlü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 eine Datenpanne beheben. Um diese hochsichere Datenlöschung (auch als Crypto-Shredding 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äre Schlüsselversion löschen, 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äre Schlüsselversion aktivieren oder wiederherstellen. Weitere Informationen finden Sie unter Primäre CMEK-Schlüsselversion aktivieren oder wiederherstellen.
Persistenz

Wenn Sie Ihre primäre Schlüsselversion löschen, gelten für die Persistenz Ihres Clusters die folgenden Einschränkungen:

  • Wenn Sie Ihren Cluster für die Verwendung der Persistenz konfigurieren, deaktiviert Memorystore for Redis Cluster die Persistenz, wenn die Schlüsselversion nicht mehr verfügbar ist. Ihnen werden keine Kosten mehr für die Verwendung der Persistenz 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äre Schlüsselversion aktivieren oder wiederherstellen.

Wenn Sie Ihre primäre Schlüsselversion aktivieren, aber eine ältere Schlüsselversion deaktivieren oder löschen, gelten für Sicherungen 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, ist die Sicherung nicht zugänglich.
  • Wenn Sie die Persistenz aktivieren, bleibt sie aktiviert. Wenn die ältere Schlüsselversion, die in der 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 IAM-Berechtigungen für den Schlüssel entfernen, priorisiert Memorystore for Redis Cluster die Verfügbarkeit des primären Caches. Reguläre In-Memory-Caching-Vorgänge verarbeiten weiterhin Traffic.

Sicherungen und Persistenz werden jedoch deaktiviert. Memorystore for Redis Cluster schreibt sofort keine neuen Daten mehr auf das Laufwerk und liest keine Daten vom vom Kunden verschlüsselten Laufwerk 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 Sicherungen und Persistenz die folgenden Bedingungen:

  • Die neueste primäre Schlüsselversion Ihres CMEK verschlüsselt neue Sicherungen.
  • Für vorhandene Sicherungen wird keine Neuverschlüsselung durchgeführt.
  • Bei der Persistenz führen die Knoten keine Aktion aus. Die Knoten verwenden die ältere Schlüsselversion bis zum nächsten Wartungsereignis.

Mit 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 vorhandene Sicherungen oder aktive Persistenzdateien mit einer neuen Schlüsselversion neu zu verschlüsseln. 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 Sicherungen und Persistenz die folgenden Bedingungen:

Sicherungen

Sie können vorhandene Sicherungen nicht neu verschlüsseln. 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

Um den Cluster zu zwingen, einen neuen Cloud KMS-Schlüssel zu verwenden, 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 auf folgende Weise 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 Wartungs ereignis wird der neue Schlüssel verwendet.
  • Primärer Cache: Das Ersetzen dieses Schlüssels hat keine Auswirkungen. CMEK verschlüsselt keine In-Memory-Daten, 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 aktiviert die Persistenz wieder.

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 den CMEK-Schutz für Ihre Cluster erzwingen. Wenn sich die Memorystore for Redis Cluster API in der Deny Richtlinienliste der Dienste für diese Einschränkung befindet, können Sie keine nicht CMEK-geschützten Cluster 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 die Cluster, die die CMEK-Verschlüsselung verwenden, einen Schlüssel aus einem zulässigen Projekt, Ordner oder einer zulässigen Organisation verwenden.

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 Einschränkungen für Organisationsrichtlinien, 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 Memorystore for Redis Cluster – Preise.

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 für 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