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

Standardmäßig verschlüsselt Memorystore for Redis Cluster ruhende Kundeninhalte. Memorystore for Redis Cluster übernimmt die Verschlüsselung für Sie. Zusätzliche Maßnahmen Ihrerseits sind nicht erforderlich. Diese Option heißt Google-Standardverschlüsselung.

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 Memorystore for Redis Cluster verwenden. Mit Cloud KMS-Schlüsseln haben Sie die Kontrolle über Schutz level, 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 besitzen 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 Memorystore for Redis Cluster-Ressourcen der Verwendung der Google-Standardverschlüsselung. Weitere Informationen zu Ihren Verschlüsselung soptionen finden Sie unter Kundenverwaltete Verschlüsselungsschlüssel (CMEK).

Hinweis:Sie können CMEK nur für neue Memorystore for Redis Cluster-Bereitstellungen verwenden. Sie können CMEK nicht für vorhandene Cluster in Memorystore for Redis Cluster aktivieren. Informationen zum Erstellen von Clustern mit CMEK finden Sie unter Kundenverwaltete Verschlüsselungsschlüssel (CMEK) verwenden.

Für wen ist CMEK geeignet?

CMEK ist für Organisationen mit vertraulichen oder regulierten Daten gedacht, die verschlüsselt werden müssen. Weitere Informationen dazu, ob Sie CMEK zum Verschlüsseln dieser Daten verwenden sollten, finden Sie unter Entscheidung über die Verwendung von CMEK.

Von Google und kundenverwaltete Verschlüsselung im Vergleich

Mit dem CMEK-Feature für kundenverwaltete Verschlüsselungsschlüssel können Sie für inaktive Daten in Memorystore for Redis Cluster Ihre eigenen kryptografischen Schlüssel verwenden. Für CMEK-fähige Cluster in Memorystore for Redis Cluster verwendet Google Ihre Schlüssel, um auf alle inaktiven Daten zuzugreifen.

Memorystore verwendet von Google verwaltete Datenverschlüsselungsschlüssel (Data Encryption Keys, DEKs) und Schlüsselverschlüsselungsschlüssel (Key Encryption Keys, KEKs), um Daten in Memorystore for Redis Cluster zu verschlüsseln. Es gibt zwei Verschlüsselungsebenen:

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

Der Cluster in Memorystore for Redis Cluster speichert den verschlüsselten DEK zusammen mit den verschlüsselten Daten auf dem Laufwerk und Google verwaltet den Google-KEK. Der CMEK ist der KEK, der den DEK verpackt. Mit CMEK können Sie den KEK erstellen, deaktivieren oder löschen, rotieren und aktivieren oder wiederherstellen.

Die folgenden Diagramme zeigen, wie die Verschlüsselung inaktiver Daten in einem Cluster funktioniert, wenn entweder die standardmäßige von Google verwaltete Verschlüsselung oder CMEK verwendet wird.

Ohne CMEK

Mit CMEK

Beim Entschlüsseln von Daten, die mit CMEK verpackt sind, verwendet Memorystore den KEK aus Cloud Key Management Service, um den DEK zu entschlüsseln, und den unverschlüsselten DEK, um inaktive Daten zu entschlüsseln.

Preise

Memorystore for Redis Cluster berechnet CMEK-fähige Cluster wie alle 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 erstellen, der CMEK verwendet, 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.

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 von Persistenz:
  • RDB-Persistenz:Das Redis-Datenbankfeature (Redis Database, RDB) schützt Ihre Daten, indem es Snapshots Ihrer Daten im dauerhaften Speicher speichert.
  • AOF-Persistenz:Bei diesem Feature hat die Datenbeständigkeit 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.

Informationen zu Dienstkonten

Wenn Sie einen Cluster mit CMEK erstellen, müssen Sie dem Memorystore for Redis Cluster Dienstkonto mit dem folgenden Format die Rolle cloudkms.cryptoKeyEncrypterDecrypter zuweisen:

  [e-mail]
  

Durch das Erteilen dieser Berechtigung kann das Dienstkonto den Zugriff auf den Schlüssel von Cloud KMS anfordern.

Eine Anleitung zum Erteilen dieser Berechtigung für das Dienstkonto finden Sie unter Memorystore for Redis Cluster-Dienstkonto Zugriff auf den Schlüssel gewähren.

Informationen zu Schlüsseln

In Cloud KMS müssen Sie einen Schlüsselbund mit einem kryptografischen Schlüssel erstellen, der einen symmetrischen Verschlüsselungsalgorithmus verwendet. Wenn Sie einen Cluster in Memorystore for Redis Cluster erstellen, wählen Sie diesen Schlüssel aus, um den Cluster zu verschlüsseln. Sie können ein einziges Projekt für Ihre Schlüssel und Cluster erstellen oder für beide jeweils ein separates Projekt anlegen.

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

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

Externe Schlüssel

Sie können Cloud External Key Manager (Cloud EKM) verwenden, um Daten mit von Ihnen verwalteten externen Schlüsseln zu verschlüsseln. Google Cloud

Wenn Sie einen Cloud EKM-Schlüssel verwenden, hat Google keine Kontrolle über die Verfügbarkeit Ihres extern verwalteten Schlüssels. Wenn der Schlüssel beim Erstellen des Clusters nicht verfügbar ist, wird der Cluster nicht erstellt.

Weitere Überlegungen zur Verwendung externer Schlüssel finden Sie unter Cloud External Key Manager.

Wie kann ich CMEK-verschlüsselte Daten dauerhaft unzugänglich machen?

Warnung: Sie haben die Kontrolle über Schlüssel und Datenzugriff. Wenn Sie eine Schlüsselversion löschen, die mit einem Cluster in Memorystore for Redis Cluster verknüpft ist, kann Google die Daten nicht wiederherstellen.

Es kann vorkommen, dass Sie Daten, die mit CMEK verschlüsselt wurden, dauerhaft unzugänglich machen möchten. Löschen Sie dazu die Schlüsselversion. Weitere Informationen zum Löschen von Schlüsselversionen finden Sie unter Schlüsselversionen löschen und wiederherstellen.

Verhalten einer CMEK-Schlüsselversion

In diesem Abschnitt erfahren Sie, was passiert, wenn Sie eine Schlüsselversion deaktivieren, löschen, rotieren, aktivieren und wiederherstellen.

CMEK-Schlüsselversion deaktivieren oder löschen

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

Hinweis: Obwohl die Schlüsselversion deaktiviert oder gelöscht ist, werden im Cluster weiterhin Lese- und Schreibvorgänge ausgeführt.

Sicherungen

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

Persistenz

• Wenn Sie Ihren Cluster für die Verwendung von Persistenz, konfigurieren, deaktiviert Memorystore for Redis Cluster das Persistenzfeature, wenn die Schlüssel version nicht mehr verfügbar ist. Ihnen werden keine Kosten mehr für dieses Feature in Rechnung gestellt.
• Memorystore for Redis Cluster schreibt keine neuen Daten mit dem CMEK in den persistenten Speicher.
• Memorystore for Redis Cluster kann keine vorhandenen Daten lesen, die sich im persistenten Speicher befinden.
• Sie können die Persistenz erst aktualisieren oder wieder aktivieren, wenn Sie die primäre Schlüsselversion aktivieren oder wiederherstellen.

Wichtig: Wenn Sie die primäre Schlüsselversion deaktivieren oder löschen, gilt der Cluster als außerhalb der SLA.

Wenn Sie die primäre Schlüsselversion Ihres CMEK aktivieren, aber eine ältere Schlüsselversion deaktivieren oder löschen, gelten die folgenden Bedingungen für Sicherungen und Persistenz:

• 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 dieses Feature aktiviert. Wenn die ältere Schlüssel version, 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.

Primäre CMEK-Schlüsselversion rotieren

Wenn Sie die primäre Schlüsselversion Ihres CMEK rotieren und eine neue primäre Schlüsselversion erstellen, gelten die folgenden Bedingungen für Sicherungen und Persistenz:

• Die neueste primäre Schlüsselversion Ihres CMEK verschlüsselt neue Sicherungen.
• Für vorhandene Sicherungen erfolgt keine erneute Verschlüsselung.
• Für die Persistenz führen die Knoten keine Aktion aus. 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 kein bedarfsorientiertes erneutes Verpacken vorhandener inaktiver 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 die folgenden Bedingungen für Sicherungen und Persistenz:

Sicherungen

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

Achtung: Sie können vorhandene Sicherungen nicht neu verpacken. Wenn Sie also die KMS-Schlüsselversionen deaktivieren oder löschen, die Sie ursprünglich zum Verschlüsseln der vorhandenen Sicherungen verwendet haben, können Sie die Sicherungen nicht wiederherstellen.

Persistenz

Wenn Sie den Cluster zwingen möchten, einen neuen 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 KMS-Schlüssel ersetzen

Wenn Sie einen geschützten KMS-Schlüssel durch einen anderen KMS-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 KMS-Schlüssels wirkt sich auf folgende Weise auf Ihre Ressourcen aus:

• Sicherungen: Alle nachfolgenden Sicherungen werden mit dem neuen KMS-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 KMS-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 inaktive Daten betrachtet werden.

Wichtig: Wenn Sie den Zugriff auf einen aktiven 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 Cache. Reguläre In-Memory-Caching-Vorgänge verarbeiten weiterhin Traffic.

Sicherungen und Persistenz werden jedoch deaktiviert. Memorystore for Redis Cluster beendet sofort das Schreiben neuer Daten auf das Laufwerk und liest keine Daten vom vom Kunden verschlüsselten Laufwerk in den Arbeitsspeicher.

Primäre CMEK-Schlüsselversion aktivieren oder wiederherstellen

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

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

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.

Informationen zu Einschränkungen für CMEK-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 CMEK-Verschlüsselung verwenden, einen Schlüssel aus einem zulässigen Projekt, Ordner oder einer Organisation verwenden.

Hinweis: 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. Wenn Sie die Organisationsrichtlinie für das Projekt einrichten, geben Sie außerdem eine Projekt-ID anstelle einer Projekt nummer.