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

MySQL | PostgreSQL | SQL Server

In Cloud SQL for MySQL werden inaktive Kundendaten standardmäßig verschlüsselt. Die Verschlüsselung wird von Cloud SQL for MySQL durchgeführt. Sie müssen nichts weiter tun. Diese Option wird Google-Standardverschlüsselung genannt.

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 Cloud SQL for MySQL 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 die Schlüsselnutzung im Blick behalten, Audit-Logs aufrufen und den Lebenszyklus von Schlüsseln steuern. Statt es Google zu überlassen und zu verwalten, das die symmetrischen Schlüsselverschlüsselungsschlüssel (Key Encryption Keys, KEKs) zum Schutz Ihrer Daten enthält, können Sie diese auch über Cloud KMS steuern und verwalten.

Nachdem Sie Ihre Ressourcen mit CMEKs eingerichtet haben, ähnelt der Zugriff auf Ihre Cloud SQL for MySQL-Ressourcen der Verwendung der Google-Standardverschlüsselung. Weitere Informationen zu den Verschlüsselungsoptionen finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK).

CMEK mit Cloud KMS Autokey

Sie können CMEKs manuell erstellen, um Ihre Cloud SQL for MySQL-Ressourcen zu schützen, oder dazu Cloud KMS Autokey verwenden. Mit Autokey werden Schlüsselringe und Schlüssel bei der Ressourcenerstellung in Cloud SQL for MySQL auf Anfrage generiert. Dienst-Agenten, die die Schlüssel für Verschlüsselungs- und Entschlüsselungsvorgänge verwenden, werden erstellt, falls sie noch nicht vorhanden sind. Sie erhalten dann die erforderlichen IAM-Rollen (Identity and Access Management). Weitere Informationen finden Sie unter Übersicht: Autokey.

Cloud SQL for MySQL ist nur dann mit Cloud KMS Autokey kompatibel, wenn Ressourcen mit Terraform oder der REST API erstellt werden.

Informationen zum Schutz Ihrer Cloud SQL for MySQL-Ressourcen mit manuell erstellten CMEKs finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) verwenden.

Wenn Sie von Cloud KMS Autokey erstellte CMEKs zum Schutz Ihrer Cloud SQL for MySQL-Ressourcen verwenden möchten, folgen Sie als Beispiel der Anleitung für Secret Manager unter Autokey mit Secret Manager-Ressourcen verwenden.

Von Google und vom Kunden verwaltete Verschlüsselung im Vergleich

Die folgenden Diagramme zeigen, wie die Verschlüsselung inaktiver Daten in einer Cloud SQL-Instanz funktioniert, wenn entweder die standardmäßige Google-Verschlüsselung oder vom Kunden verwaltete Verschlüsselungsschlüssel verwendet werden.

Ohne CMEK

Mit CMEK

Beim Entschlüsseln von Daten, die mit vom Kunden verwalteten Verschlüsselungsschlüsseln verpackt sind, verwendet Cloud SQL den KEK, 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 den KMS-Speicher gesendet, in dem der nicht exportierbare KEK gespeichert wird. Der KMS-Speicher gibt den entpackten DEK zurück.

Wann interagiert Cloud SQL mit CMEK-Schlüsseln?

Vorgang	Hinweise
Instanzerstellung	Während der Erstellung einer Instanz konfigurieren Sie die Instanz für die Verwendung von vom Kunden verwalteten Verschlüsselungsschlüsseln.
Sicherung erstellen	Bei Sicherungen einer CMEK-fähigen Instanz verschlüsseln vom Kunden verwaltete Verschlüsselungsschlüssel Nutzerdaten wie Nutzerabfragen und -antworten. Sicherungen einer CMEK-fähigen Instanz übernehmen die Verschlüsselung mit demselben Cloud KMS-Schlüssel wie die Quellinstanz.
Instanzwiederherstellung	Während der Wiederherstellung einer CMEK-fähigen Instanz greift Cloud SQL mit dem Schlüssel auf Daten in der wiederherzustellenden Sicherungsinstanz zu. Beim Wiederherstellen in einer anderen Instanz kann die Zielinstanz einen anderen Schlüssel für die Verschlüsselung verwenden.
Replikaterstellung	Wenn Sie ein Leser- oder Failover-Replikat einer Cloud SQL-Instanz in derselben Region erstellen, wird der CMEK von der übergeordneten Instanz übernommen. Wenn Sie ein Lese- oder Failover-Replikat in einer anderen Region erstellen, müssen Sie einen CMEK aus der anderen Region auswählen. Jede Region nutzt einen eigenen Schlüsselsatz.
Klonerstellung	Klone von einer CMEK-fähigen Instanz übernehmen die CMEK-Verschlüsselung mit demselben Cloud KMS-Schlüssel wie die Quellinstanz.
Instanzaktualisierung	Bei Aktualisierungen einer CMEK-fähigen Instanz prüft Cloud SQL den CMEK-Schlüssel.

An welchen Standorten werden CMEK-fähige Cloud SQL-Instanzen unterstützt?

CMEK sind an allen Cloud SQL-Instanzstandorten verfügbar.

Informationen zu Dienstkonten

Wenn für Ihre Cloud SQL-Instanzen CMEK aktiviert ist, müssen Sie den Schlüsselzugriff von Cloud KMS über ein Dienstkonto anfordern.

Wenn Sie einen vom Kunden verwalteten Verschlüsselungsschlüssel für ein Projekt verwenden möchten, müssen Sie ein Dienstkonto haben und dem vom Kunden verwalteten Verschlüsselungsschlüssel Zugriff auf das Dienstkonto gewähren. Das Dienstkonto muss im Projekt vorhanden sein. Das Dienstkonto ist in allen Regionen sichtbar.

Bei Erstellung der Instanz über die Console, erstellt Cloud SQL automatisch das Dienstkonto, wenn Sie zum ersten Mal die Option Vom Kunden verwalteter Schlüssel auswählen (wenn noch kein Dienstkonto vorhanden ist). Wenn Cloud SQL das Dienstkonto automatisch erstellt, benötigen Sie keine besonderen Berechtigungen für Ihr Nutzerkonto.

Informationen zu Schlüsseln

In Cloud KMS müssen Sie einen Schlüsselbund mit einem kryptografischen Schlüssel erstellen, der für einen Standort festgelegt ist. Wenn Sie eine neue Cloud SQL-Instanz erstellen, wählen Sie diesen Schlüssel aus, um die Instanz zu verschlüsseln.

Sie müssen die Schlüssel-ID und -region kennen, wenn Sie neue Cloud SQL-Instanzen erstellen, die vom Kunden verwaltete Verschlüsselungsschlüssel verwenden. Neue Cloud SQL-Instanzen müssen sich in derselben Region befinden wie der vom Kunden verwaltete Verschlüsselungsschlüssel, der der Instanz zugeordnet ist. Sie können ein Projekt sowohl für Schlüssel als auch für Cloud SQL-Instanzen erstellen oder für beide jeweils ein separates Projekt erstellen.

Vom Kunden verwaltete Verschlüsselungsschlüssel haben folgendes Format:

projects/[KMS_PROJECT_ID]/locations/[LOCATION]/keyRings/[KEY_RING]/cryptoKeys/[KEY_NAME]

Wenn Cloud SQL nicht auf den Schlüssel zugreifen kann (z. B. wenn Sie die Schlüsselversion deaktivieren), sperrt Cloud SQL die Instanz. Sobald der Schlüssel wieder zugänglich ist, setzt Cloud SQL die Instanz automatisch fort.

Wenn Sie Schlüssel rotieren, werden mit dem jeweiligen Schlüssel verschlüsselte Instanzen nicht automatisch mit der neuen Primärschlüsselversion neu verschlüsselt. Sie können alle vorhandenen primären CMEK-Instanzen oder -Replikate mit der neuen Primärschlüsselversion neu verschlüsseln. Weitere Informationen zum erneuten Verschlüsseln einer Cloud SQL-Instanz oder eines -Replikats nach einer Schlüsselrotation finden Sie unter Vorhandene CMEK-fähige Instanzen oder Replikate neu verschlüsseln.

Externe Schlüsselverwaltung

Sie können Schlüssel, die in externen Schlüsselverwaltungssystemen gespeichert sind, z. B. Fortinix, Futurex oder Thales, als vom Kunden verwaltete Verschlüsselungsschlüssel verwenden. Informationen zur Verwendung externer Schlüssel mit Cloud KMS finden Sie unter Cloud External Key Manager (Cloud EKM).

Key Access Justifications

Sie können Key Access Justifications (KAJ) als Teil von Cloud EKM verwenden. Mit Key Access Justifications können Sie den Grund für jede Cloud EKM-Anfrage aufrufen. Basierend auf der Begründung können Sie eine Anfrage außerdem automatisch genehmigen oder ablehnen. Weitere Informationen finden Sie in der Übersicht über Begründungen für den Schlüsselzugriff.

Damit bietet Key Access Justifications eine zusätzliche Kontrolle über Ihre Daten. Dazu stellt es für jeden Versuch zum Entschlüsseln der Daten eine Begründung bereit.

Weitere Informationen zur Verwendung von Schlüsseln mit Cloud SQL-Instanzen finden Sie unter Cloud SQL-Instanz mit CMEK erstellen.

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 Version des vom Kunden verwalteten Verschlüsselungsschlüssels. Sie können zwar den Schlüsselbund oder Schlüssel nicht löschen, aber Sie können Versionen des Schlüssels löschen.

Wie exportiere und importiere ich Daten aus einer und in eine CMEK-fähige Instanz?

Wenn Ihre Daten während eines Exports oder Imports mit einem vom Kunden verwalteten Schlüssel verschlüsselt bleiben sollen, müssen Sie vor dem Exportieren von Daten in den Cloud Storage-Bucket einen vom Kunden verwalteten Verschlüsselungsschlüssel festlegen. Es gibt keine besonderen Anforderungen oder Einschränkungen für den Import von Daten in eine neue Instanz, wenn die Daten zuvor in einer CMEK-fähigen Instanz gespeichert waren.

Beschränkungen

Vom Kunden verwaltete Verschlüsselungsschlüssel unterliegen diesen Beschränkungen:

Sie können keine vom Kunden verwalteten Verschlüsselungsschlüssel auf einer vorhandenen Instanz aktivieren.
Sie können einem Replikat in derselben Region wie die primäre Instanz keinen anderen Schlüssel zuweisen. Für regionenübergreifende Replikate müssen Sie einen neuen Schlüssel für die Replikatregion erstellen.
Sie können einem Klon keinen anderen Schlüssel zuweisen.
Sie können keine vom Kunden verwalteten Verschlüsselungsschlüssel verwenden, um Folgendes zu verschlüsseln:
- Externe Server (externe primäre Instanzen und externe Replikate)
- Instanzmetadaten wie Instanz-ID, Datenbankversion, Maschinentyp, Flags, Sicherungszeitplan usw.
Sie können keine vom Kunden verwalteten Verschlüsselungsschlüssel verwenden, um Nutzerdaten wie Anfragen und Antworten von Nutzern während der Übertragung zu verschlüsseln.