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) in Cloud Key Management Service (Cloud KMS) für Ihre Memorystore for Redis-Instanzen verwenden können. Das Dokument beschreibt auch, welche Daten im persistenten Speicher verschlüsselt werden und wie sich Ihre Instanzen bei wichtigen Ereignissen im Lebenszyklus 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 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 Instanzen aktivieren. Sie können CMEK nicht auf vorhandene Instanzen 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 Auswählen, wo CMEK verwendet werden soll.

Kundenverwaltete Verschlüsselung

Mit CMEK können Sie Ihre kryptografischen Schlüssel verwenden, um gespeicherte Daten in Instanzen zu schützen. Zum Verschlüsseln dieser Daten verwendet Memorystore for Redis 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.
  • KEK-Verschlüsselung: KEKs verschlüsseln DEKs.

Memorystore for Redis 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 Ihrer Instanz verschlüsselt werden.

Das folgende Diagramm zeigt, wie eine Instanz CMEK zum Verschlüsseln von Daten verwendet. Daten, die in die Speicherinfrastruktur von Google hochgeladen werden, werden in Blöcke unterteilt 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 Daten entschlüsselt, die mit CMEK verschlüsselt sind. Um auf diese verschlüsselten Daten zuzugreifen, sendet Memorystore for Redis 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 die Instanz zum Entschlüsseln der gespeicherten Daten verwendet.

Datenblock, der mit einem DEK verschlüsselt und mit dem verschlüsselten DEK gespeichert wird. Eine Anfrage zum Entschlüsseln des DEK wird an Cloud KMS gesendet, wo der KEK gespeichert ist. 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 unterstützt die Redis-Datenbankpersistenz (RDB), mit der Sie Snapshots Ihrer Daten in einem langlebigen Speicher speichern können.
  • Metadaten zu Sicherheitsfunktionen wie AUTH und Verschlüsselung während der Übertragung. Weitere Informationen finden Sie unter Redis AUTH 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 Ihre CMEK-Architektur besteht.

Dienstkonten

Wenn Sie eine CMEK-fähige Instanz erstellen möchten, müssen Sie dem Memorystore for Redis-Dienstkonto mit dem folgenden Format die Rolle roles/cloudkms.cryptoKeyEncrypterDecrypter zuweisen:

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

Wenn Sie diese Berechtigung erteilen, 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 eine Memorystore for Redis-Instanz erstellen, wählen Sie diesen Schlüssel aus, um die Instanz zu verschlüsseln. Sie können ein Projekt für Ihre Schlüssel und Instanzen oder verschiedene Projekte für die einzelnen Elemente erstellen.

CMEK ist an allen Standorten von Memorystore for Redis-Instanzen verfügbar. Sie müssen den Schlüsselbund und den Schlüssel in derselben Region erstellen, in der Sie die Instanz erstellen möchten. Ein Schlüssel für mehrere Regionen oder für eine globale Region funktioniert nicht. 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

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

In der Google Cloud Console wird für eine gesperrte Instanz auf der Seite Instanzen ein rotes Ausrufezeichen als Kurzinfo angezeigt. Wenn Sie den Mauszeiger auf die Kurzinfo bewegen, wird der Status No state angezeigt. Sobald der Schlüssel wieder zugänglich ist, setzt Memorystore for Redis die Instanz automatisch fort.

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 der Instanz nicht verfügbar ist, wird die Memorystore for Redis-Instanz nicht erstellt. Wenn der externe Schlüssel zu einem beliebigen Zeitpunkt nach dem Erstellen der Instanz nicht mehr verfügbar ist, wird die Instanz von Memorystore for Redis angehalten, bis der Zugriff wiederhergestellt ist.

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

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. Bei jeder Schlüsselrotation wird eine Schlüsselversion erstellt.

In den folgenden Abschnitten wird beschrieben, wie sich Ihre Instanzen und die darin geschützten Daten bei wichtigen Lebenszyklusereignissen wie dem Deaktivieren, Löschen, Aktivieren oder Wiederherstellen von Schlüsselversionen verhalten. In den Abschnitten wird auch die Auswirkung des Ersetzens eines Cloud KMS-Schlüssels erläutert. Außerdem finden Sie dort eine Anleitung zum manuellen Verschlüsseln von Daten und Informationen zum Importieren oder Exportieren von Daten für eine CMEK-aktivierte Instanz.

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 Crypto-Shredding bezeichnet) zu erreichen, vernichten Sie die Schlüsselversion. Weitere Informationen zum Löschen von Schlüsselversionen finden Sie unter Schlüsselversionen löschen und wiederherstellen.

Wenn Sie sicherstellen möchten, dass kein Datenzugriff auf Ihre Instanz erfolgt, deaktivieren Sie die primäre Schlüsselversion. Dadurch wird Ihre Instanz gesperrt. Wenn ein verwendeter CMEK deaktiviert oder zerstört wird, wird die Instanz in Memorystore for Redis angehalten. Das gilt auch für ältere Schlüsselversionen, die von der Instanz verwendet werden.

So prüfen Sie, ob Ihre Instanz von Memorystore for Redis gesperrt wurde:

  • Google Cloud Console: Auf der Seite Instanzen wird neben Ihrer Instanz ein rotes Ausrufezeichen mit einem entsprechenden Hinweis angezeigt. Wenn Sie den Mauszeiger auf die Kurzinfo bewegen, wird der Status Kein Status angezeigt.
  • gcloud CLI: Verwenden Sie den Befehl gcloud redis instances describe. Prüfen Sie das Feld state. Für eine gesperrte Instanz wird kein Status READY oder REPAIRING angezeigt.

Ersetzen eines geschützten Cloud KMS-Schlüssels

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 diese Änderung nur auf zukünftige Vorgänge an.

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

  • Sicherungen: Memorystore for Redis exportiert Sicherungen nach Cloud Storage. Daher wird die Verschlüsselung der exportierten Daten durch die Verschlüsselungseinstellungen des Ziel-Buckets (nicht durch den CMEK der Instanz) gesteuert.
  • Persistenz: Beim nächsten Neustart der Instanz 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 Daten im Ruhezustand gelten.

CMEK-geschützte Daten manuell neu verschlüsseln

Memorystore for Redis unterstützt kein On-Demand-Neuverschlüsseln vorhandener ruhender 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 zum Verschlüsseln neu geschriebener Daten verwenden.

Daten für eine CMEK-fähige Instanz importieren oder exportieren

Wenn Ihre exportierten Daten weiterhin durch einen CMEK geschützt sein sollen, müssen Sie CMEK für den Cloud Storage-Ziel-Bucket konfigurieren, bevor Sie Daten dorthin exportieren. Wenn Ihre Daten bereits auf einer CMEK-fähigen Instanz gespeichert sind, gelten für den Import dieser Daten in eine neue Instanz keine besonderen Anforderungen oder Einschränkungen. Weitere Informationen finden Sie unter Daten importieren und exportieren.

Primäre CMEK-Schlüsselversion aktivieren oder wiederherstellen

Wenn Sie Ihre primäre Schlüsselversion aktivieren oder wiederherstellen, wird Ihre Instanz in Memorystore for Redis automatisch fortgesetzt.

Einschränkungen für Organisationsrichtlinien

Memorystore for Redis unterstützt Einschränkungen für Organisationsrichtlinien für CMEK. Mit diesen Einschränkungen können Sie den CMEK-Schutz für Ihre Instanzen 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 CMEK-Schutz für Ihre Instanzen erzwingen. Wenn sich die Memorystore for Redis API in der Richtlinienliste Deny für diese Einschränkung befindet, können Sie keine Instanzen 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 Instanzen, die CMEK-Verschlüsselung verwenden, Schlüssel aus einem zulässigen Projekt, Ordner oder einer Organisation verwendet werden.

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

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

Preise

Die Abrechnung für eine CMEK-fähige Memorystore for Redis-Instanz erfolgt wie für jede andere Instanz. Es fallen keine zusätzlichen Kosten an. Weitere Informationen finden Sie unter Memorystore for Redis-Preise.

Sie verwenden die Cloud KMS API, um CMEK zu verwalten. Wenn Sie eine Instanz mit CMEK erstellen, verwendet Memorystore den Schlüssel regelmäßig zum Verschlüsseln von Daten.

Cloud KMS berechnet Ihnen die Kosten für den Schlüssel sowie für Verschlüsselungs- und Entschlüsselungsvorgänge, wenn Memorystore for Redis den Schlüssel verwendet. Weitere Informationen finden Sie unter Cloud KMS-Preise.

Beschränkungen

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

  • Sie können CMEK nicht für eine vorhandene Instanz aktivieren.
  • Der Schlüssel, der Schlüsselbund und die Instanz 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