Vom Kunden bereitgestellte Verschlüsselungsschlüssel (Customer-Supplied Encryption Keys, CSEKs) sind ein Feature in Google Cloud Storage und Google Compute Engine. Wenn Sie Ihre eigenen Verschlüsselungsschlüssel bereitstellen, verwendet Google Ihre Schlüssel zum Schutz der von Google generierten Schlüssel, die wiederum zum Verschlüsseln und Entschlüsseln Ihrer Daten verwendet werden.
In diesem Dokument verwendete Begriffe:
Datenverschlüsselungsschlüssel (Data Encryption Key, DEK): Ein Schlüssel zum Verschlüsseln von Daten.
Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK): Ein Schlüssel zum Verschlüsseln oder „Verpacken“ eines Datenverschlüsselungsschlüssels.
Clustermanager: Eine Sammlung von Prozessen, die unter einer Clustermanager-Identität in der Produktionsinfrastruktur von Google ausgeführt werden. Ein Clustermanager implementiert die Logik zum Verwalten von Compute Engine-Ressourcen wie Laufwerke und VM-Instanzen. Er speichert auch Metadaten zu diesen Ressourcen.
Instanzmanager: Eine Sammlung von Prozessen, die unter einer Instanzmanager-Identität in der Produktionsinfrastruktur von Google ausgeführt werden. Er führt Änderungen an VM-Instanzen (Prozesse) in der Gruppe durch, z. B. VM starten/anhalten oder Laufwerke anhängen/trennen. Der Clustermanager gibt an, welchen Status die VMs zu einem beliebigen Zeitpunkt haben sollen, der Instanzmanager regelt die entsprechende Ausführung.
Funktionsweise der vom Kunden bereitgestellten Verschlüsselungsschlüssel
Im Folgenden finden Sie Informationen zur Funktionsweise der vom Kunden bereitgestellten Verschlüsselungsschlüssel mit Google Cloud Storage und Google Compute Engine.
Cloud Storage
Wenn Sie die Funktion "Vom Kunden bereitgestellter Verschlüsselungsschlüssel" in Cloud Storage verwenden, geschieht Folgendes:
Sie stellen einen Standard-CSEK im Rahmen eines API-Aufrufs bereit. Dieser Schlüssel wird vom Google-Front-End zum Arbeitsspeicher des Speichersystems übertragen. Er wird in Google Cloud Storage als Schlüsselverschlüsselungsschlüssel für Ihre Daten verwendet.
Der Standard-CSEK wird zum Entpacken von verpackten Blockschlüsseln verwendet, um standardmäßige Blockschlüssel im Arbeitsspeicher zu erstellen. Mit diesen Schlüsseln werden in Speichersystemen gespeicherte Datenblöcke entschlüsselt. Sie werden in Google Cloud Storage als Datenverschlüsselungsschlüssel (DEK) für Ihre Daten verwendet.
| Schlüssel | Speicherort | Zweck | Zugänglich, bis |
|---|---|---|---|
| Standard-CSEK | Arbeitsspeicher des Speichersystems | Vom Kunden bereitgestellt. Schlüsselverschlüsselungsschlüssel (KEK) für Blockschlüssel. Verpackt die Blockschlüssel. |
der vom Kunden angeforderte Vorgang (z. B. insertObject oder getObject) abgeschlossen ist. |
| Verpackte Blockschlüssel | Speichergeräte | Schutz von inaktiven gespeicherten Blockschlüsseln. | das Speicherobjekt gelöscht ist. |
| Standardmäßige Blockschlüssel | Arbeitsspeicher der Speichergeräte | Datenverschlüsselungsschlüssel (DEK) für die Daten. Lesen/Schreiben von Daten auf dem Laufwerk. |
der vom Kunden angeforderte Vorgang abgeschlossen ist. |
Compute Engine
Bei Verwendung vom Kunden bereitgestellter Verschlüsselungsschlüssel in Compute Engine:
Sie stellen einen Standard-CSEK im Rahmen eines API-Aufrufs bereit.
- Optional können Sie einen mit öffentlichen Schlüsseln verpackten CSEK bereitstellen.
Dieser Schlüssel wird vom Google-Front-End an das Front-End des Clustermanagers übertragen:
- Wenn ein verpackter CSEK bereitgestellt wurde, wird er mithilfe eines asymmetrischen Google-Verpackungsschlüssels entpackt.
- Der Standard-CSEK wird mit einer kryptografischen Nonce pro nichtflüchtigem Speicher kombiniert, um einen CSEK-abgeleiteten Schlüssel zu generieren. Dieser Schlüssel wird in Google Compute Engine als KEK für Ihre Daten verwendet.
Im Cluster Manager-Front-End werden sowohl der CSEK als auch der CSEK-abgeleitete Schlüssel nur im Arbeitsspeicher des Clustermanagers vorgehalten. Der CSEK-abgeleitete Schlüssel wird im Arbeitsspeicher des Clustermanagers zum Entpacken der verpackten Laufwerksschlüssel verwendet, die in den Metadaten der Clustermanagerinstanz und des Instanzmanagers gespeichert sind, in denen der automatische Neustart aktiviert ist (diese Metadaten sind nicht mit den Instanzmetadaten identisch).
- Der vom CSEK abgeleitete Schlüssel wird zum Verpacken von Standard-Laufwerksschlüsseln beim Erstellen eines Laufwerks sowie zum Entpacken von Standard-Laufwerksschlüsseln beim Zugriff auf ein Laufwerk verwendet.
- Wenn der automatische Neustart aktiviert ist, werden die verpackten Laufwerksschlüssel vom Clustermanager für die Lebensdauer der VM beibehalten, sodass die VM bei einem Absturz neu gestartet werden kann. Die verpackten Laufwerksschlüssel werden mit einem symmetrischen Google-Verpackungsschlüssel verpackt. Aufgrund ihrer Berechtigungen können sie nur von Google Compute Engine verwendet werden.
- Wenn die Live-Migration aktiviert ist, wird der Standard-Laufwerksschlüssel vom Arbeitsspeicher der alten VM-Instanz an den Arbeitsspeicher der neuen VM-Instanz übergeben. Dabei sind weder der Instanzmanager noch der Clustermanager am Kopieren des Schlüssels beteiligt.
Die standardmäßigen Laufwerksschlüssel werden an den Arbeitsspeicher des Clustermanagers, des Instanzmanagers und der virtuellen Maschine übergeben. Diese Schlüssel werden in Google Compute Engine als Datenverschlüsselungsschlüssel für Ihre Daten verwendet.
| Schlüssel | Gehalten von | Zweck | Zugänglich, bis |
|---|---|---|---|
| Standard-CSEK | Clustermanager-Front-End | Vom Kunden bereitgestellt. Wird zur Ableitung des CSEK-abgeleiteten Schlüssels durch Hinzufügen einer kryptografischen Nonce verwendet. |
der vom Kunden angeforderte Vorgang (z. B. instances.insert, instances.attachDisk) abgeschlossen ist. |
| Mit öffentlichen Schlüsseln verpackter CSEK (optional – wenn die RSA-Schlüsselverpackung verwendet wird) |
Clustermanager-Front-End | Optional vom Kunden bereitgestellt. Wird zur Ableitung des CSEK-abgeleiteten Schlüssels verwendet. Dazu wird zuerst der asymmetrische Google-Schlüssel entpackt. |
der vom Kunden angeforderte Vorgang abgeschlossen ist. |
| Asymmetrischer Verpackungsschlüssel (wenn die RSA-Schlüsselverpackung verwendet wird) |
Interner Key Management Service von Google | Wird zum Entpacken eines vom Kunden bereitgestellten, mit RSA verpackten Schlüssels verwendet. | Unbefristet |
| CSEK-abgeleiteter Schlüssel | Clustermanager-Front-End | Schlüsselverschlüsselungsschlüssel (KEK) für Laufwerksschlüssel. Verpackt die Laufwerksschlüssel. |
die Schlüsselverpackung und -entpackung abgeschlossen ist. |
| Google-verpackte Laufwerksschlüssel (Optional – wenn der automatische Neustart verwendet wird) |
Clustermanager-Front-End | Schutz von inaktiven gespeicherten Laufwerksschlüsseln für Laufwerke, die an ausgeführte Instanzen angehängt sind. Neustart der Instanz, wenn der VM-Arbeitsspeicher gelöscht wurde (z. B. bei einem Absturz des Hosts). |
die VM angehalten oder gelöscht wird. |
| Standardmäßige Laufwerksschlüssel | VMM-Arbeitsspeicher (Virtual Machine Monitor) CM-Arbeitsspeicher (Clustermanager) |
Datenverschlüsselungsschlüssel (DEK) für die Daten. Lesen/Schreiben von Daten auf dem Laufwerk, Live-Migration der VM und direktes Upgrade. |
die VM angehalten oder gelöscht wird. |
| Von Google verpackter, CSEK-abgeleiteter Schlüssel | Clustermanager-Datenbank | Neustart des Vorgangs im Falle eines Fehlers. | der vom Kunden angeforderte Vorgang abgeschlossen ist. |
.
Schutz der vom Kunden bereitgestellten Verschlüsselungsschlüssel
Im Folgenden finden Sie Informationen zum Schutz der vom Kunden bereitgestellten Verschlüsselungsschlüssel a) auf dem Laufwerk, b) während sie in der Google Cloud Platform-Infrastruktur verschoben werden sowie c) im Arbeitsspeicher.
Auf dem Laufwerk
Standard-CSEKs, CSEK-abgeleitete Schlüssel und standardmäßige Block-/Laufwerksschlüssel werden niemals unverschlüsselt auf dem Laufwerk gespeichert. Standardmäßige Block-/Laufwerksschlüssel werden mit CSEK-abgeleiteten Schlüsseln verpackt gespeichert oder mit Google-Schlüsseln, wenn der automatische Neustart verwendet wird. Google speichert Ihre Schlüssel nicht dauerhaft auf seinen Servern.
Beim Verschieben in der Infrastruktur
Jeder Dienst bietet Funktionen zur Zugriffsverwaltung, die von der Infrastruktur für die genaue Festlegung, welche anderen Dienste mit ihm kommunizieren können, bereitgestellt werden. Der Dienst wird mithilfe der Zulassungsliste der erlaubten Dienstkontoidentitäten konfiguriert. Die so konfigurierte Zugriffsbeschränkung wird automatisch von der Infrastruktur durchgesetzt. Weitere Informationen finden Sie unter Dienstidentität, -integrität und -isolierung.
Zusätzlich zu den in den vorherigen Abschnitten dargestellten RPC-Authentifizierungs- und -Autorisierungsfunktionen bietet die Infrastruktur auch einen kryptographischen Datenschutz und Integrität für RPC-Daten im Netzwerk. Die Dienste können für jeden Infrastruktur-RPC den Grad des gewünschten kryptografischen Schutzes konfigurieren. Diese werden dann für vom Kunden bereitgestellte Verschlüsselungsschlüssel aktiviert. Weitere Informationen finden Sie unter Verschlüsselung der dienstübergreifenden Kommunikation.
Im Arbeitsspeicher
Wie beschrieben enthalten die Arbeitsspeicher verschiedener Systeme Schlüsselmaterial, unter anderem auch die Arbeitsspeicher des Clustermanagers und des VMM. Der Zugriff auf die Arbeitsspeicher dieser Systeme erfolgt nur in Ausnahmefällen (z. B. im Rahmen eines Vorfalls) und wird von Access Control Lists verwaltet. Für diese Systeme sind Speicherdumps entweder deaktiviert oder werden automatisch nach Schlüsselmaterial gescannt. Der Zugriff auf die Jobs selbst ist auf wenige Site Reliability Engineers beschränkt, die für die Aufrechterhaltung des Dienstes zuständig sind. Der Zugriff auf Logs ist wenigen Softwaretechnikern vorbehalten, deren Aufgabe das Debugging bei diesen Features ist.
Mehr erfahren
- Vom Kunden bereitgestellte Verschlüsselungsschlüssel in Google Cloud Storage
- Vom Kunden bereitgestellte Verschlüsselungsschlüssel in Google Compute Engine