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

Auf dieser Seite wird beschrieben, wie vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) mit Memorystore for Redis Cluster funktionieren. Informationen zur Verwendung dieses Features finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) verwenden.

Standardmäßig verschlüsselt Memorystore for Redis-Cluster inaktive 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 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 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-Clusterressourcen der Verwendung der Google-Standardverschlüsselung. Weitere Informationen zu Ihren Verschlüsselungsoptionen finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK).

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 Entscheiden, ob CMEK verwendet werden soll.

Von Google und vom Kunden verwaltete Verschlüsselung im Vergleich

Mit dem CMEK-Feature können Sie für inaktive Daten in Memorystore for Redis Cluster Ihre eigenen kryptografischen Schlüssel verwenden. Bei CMEK-fähigen Memorystore for Redis-Clusterinstanzen 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 zum Verschlüsseln von Daten in Memorystore for Redis Cluster.
  • KEK-Verschlüsselung:Memorystore verwendet KEKs zum Verschlüsseln von DEKs.

Die Memorystore for Redis Cluster-Instanz speichert den verschlüsselten DEK zusammen mit den verschlüsselten Daten auf der Festplatte und Google verwaltet den Google-KEK. Der CMEK ist der KEK, der den DEK umschließt. 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 einer Memorystore for Redis Cluster-Instanz funktioniert, wenn entweder die standardmäßige von Google verwaltete Verschlüsselung oder CMEK verwendet werden.

Ohne CMEK

Die Daten werden auf Google hochgeladen, dann in Blöcke aufgeteilt und jeder Block wird mit einem eigenen Datenverschlüsselungsschlüssel verschlüsselt. Datenverschlüsselungsschlüssel werden mit einem Schlüsselverschlüsselungsschlüssel verpackt. Bei der standardmäßigen Google-Verschlüsselung wird der Schlüsselverschlüsselungsschlüssel aus dem internen Schlüsselspeicher von Google abgerufen. Verschlüsselte Blöcke und verpackte Verschlüsselungsschlüssel werden über die Speicherinfrastruktur von Google verteilt.

Mit CMEK

Die Daten werden auf Google hochgeladen, dann in Blöcke aufgeteilt und jeder Block wird mit einem eigenen Datenverschlüsselungsschlüssel verschlüsselt. Datenverschlüsselungsschlüssel werden mit einem Schlüsselverschlüsselungsschlüssel verpackt. Bei CMEK unter Verwendung von Cloud KMS wird der Schlüsselverschlüsselungsschlüssel vom Cloud KMS abgerufen. Verschlüsselte Blöcke und verpackte Verschlüsselungsschlüssel werden über die Speicherinfrastruktur von Google verteilt.

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.

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

Preise

Für einen CMEK-fähigen Cluster werden in Memorystore for Redis Cluster dieselben Kosten berechnet wie für 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 eine Memorystore for Redis Cluster-Instanz mit CMEK erstellen, verwendet Memorystore den Schlüssel regelmäßig, um Daten zu verschlüsseln.

Ihnen werden von Cloud KMS sowohl die Kosten für den Schlüssel als auch 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.

Welche Daten werden mit CMEK verschlüsselt?

Mit CMEK werden die folgenden Arten von Kundendaten verschlüsselt, 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 für Notfallwiederherstellung, Datenmigration, Datenaustausch und Compliance-Szenarien nützlich.
  • Persistenz: Memorystore for Redis-Cluster unterstützt zwei Arten von 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 Datenbeständigkeit 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.

Informationen zu Dienstkonten

Wenn Sie eine Instanz mit CMEK erstellen, müssen Sie dem Memorystore for Redis Cluster-Dienstkonto mit dem folgenden Format die Rolle 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.

Eine Anleitung zum Gewähren dieser Berechtigung für das Dienstkonto finden Sie unter Dem Dienstkonto des Memorystore for Redis-Clusters 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 eine neue Memorystore for Redis Cluster-Instanz erstellen, wählen Sie diesen Schlüssel aus, um die Instanz zu verschlüsseln. Sie können ein Projekt sowohl für Schlüssel als auch für Instanzen erstellen oder für beide jeweils ein separates Projekt erstellen.

CMEK ist an allen Memorystore for Redis Cluster-Instanzstandorten verfügbar. Sie müssen den Schlüsselbund und den Schlüssel in derselben Region erstellen, in der Sie die Instanz erstellen möchten. Bei einer Multi-Region-Instanz müssen Sie den Schlüsselbund und den Schlüssel auf denselben Standort wie die Instanz festlegen. Wenn die Regionen oder Standorte nicht übereinstimmen, schlägt eine Anfrage zum Erstellen der Instanz 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

Externe Schlüssel

Sie können Cloud External Key Manager (Cloud EKM) verwenden, um Daten inGoogle 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 Ihres extern verwalteten Schlüssels. Wenn der Schlüssel beim Erstellen der Instanz nicht verfügbar ist, wird die Instanz 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?

Es kann vorkommen, dass Sie mit CMEK verschlüsselte Daten dauerhaft löschen 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 für Sicherungen und Persistenz die folgenden Bedingungen.

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ärschlüsselversion aktivieren oder wiederherstellen.

Persistenz

  • Wenn Sie Ihre Instanz für die Verwendung von Persistenz konfigurieren, deaktiviert Memorystore for Redis Cluster das Persistenz-Feature, wenn die Schlüsselversion nicht mehr verfügbar ist. Ihnen werden keine Kosten mehr für diese Funktion in Rechnung gestellt.
  • Bei Memorystore for Redis Cluster werden neue Daten nicht mit dem CMEK in den persistenten Speicher geschrieben.
  • Memorystore for Redis Cluster kann keine vorhandenen Daten lesen, die im persistenten Speicher vorhanden sind.
  • Sie können die Persistenz erst aktualisieren oder wieder aktivieren, wenn Sie die Primärschlüsselversion aktivieren oder wiederherstellen.

Wenn Sie die primäre Schlüsselversion Ihres CMEK 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 wurde, die deaktiviert oder gelöscht wurde, bleibt die Sicherung unzugänglich.
  • Wenn Sie die Persistenz aktivieren, bleibt diese Funktion 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 in 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 für Sicherungen und Persistenz die folgenden Bedingungen:

  • Die neueste Primärschlü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.

Primäre CMEK-Schlüsselversion aktivieren oder wiederherstellen

Wenn Sie die primäre Schlüsselversion Ihres CMEK 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 in der Wartung verwendeten Update ähnelt, und reaktiviert die Persistenz.

Beschränkungen

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

  • Sie können CMEK nicht für eine vorhandene Memorystore for Redis-Clusterinstanz aktivieren.
  • Die Region für den Schlüssel, den Schlüsselbund und die Instanz muss identisch sein.
  • 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.