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 Memorystore for Redis-Instanzen verwenden können. Außerdem wird beschrieben, 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. 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 Entscheiden, ob 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 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 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, mit dem die Instanz 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?

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 dauerhaften Speicher speichern können.
  • Metadaten im Zusammenhang mit 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 sich Ihre CMEK-Architektur zusammensetzt.

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

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 Instanzen und ihre geschützten Daten bei wichtigen Lebenszyklusereignissen wie dem Deaktivieren, Vernichten, Aktivieren oder Wiederherstellen von Schlüsselversionen verhalten. In den Abschnitten wird auch erläutert, welche Auswirkungen das Ersetzen eines Cloud KMS-Schlüssels hat. Außerdem finden Sie dort Anleitungen zum manuellen Verschlüsseln von Daten und zum Importieren oder Exportieren von Daten für eine CMEK-fähige 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 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 sichergehen möchten, dass kein Datenzugriff auf Ihre Instanz erfolgt, deaktivieren Sie die primäre Schlüsselversion. Dadurch wird Ihre Instanz angehalten. Wenn ein verwendeter CMEK deaktiviert oder gelöscht wird, wird die Instanz von Memorystore for Redis angehalten. Dazu gehört auch jede ältere Schlüsselversion, die von der Instanz verwendet wird.

So prüfen Sie, ob Ihre Memorystore for Redis-Instanz 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. Bei einer gesperrten Instanz wird kein Status READY oder REPAIRING angezeigt.

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 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: 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 verwenden, um neu geschriebene Daten zu verschlüsseln.

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

Wenn Sie möchten, dass Ihre exportierten Daten durch einen CMEK geschützt bleiben, 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, gibt es keine besonderen Anforderungen oder Einschränkungen für den Import dieser Daten in eine neue Instanz. 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 von 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 die CMEK-Verschlüsselung 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 Einschränkungen für Organisationsrichtlinien, die Google für Memorystore for Redis verwaltet, finden Sie unter Einschränkungen für Organisationsrichtlinien.

Preise

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

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.

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