Verschlüsselungsschlüssel verwenden

Übersicht

Standardmäßig verschlüsselt Cloud Storage alle Objektdaten mit von Google verwalteten Verschlüsselungsschlüsseln und dem AES256-Verschlüsselungsalgorithmus. Sie können jedoch alternativ einen von zwei Verschlüsselungsschlüsseltypen verwenden: vom Kunden (Ihnen) bereitgestellte Verschlüsselungsschlüssel (Customer Supplied Encryption Keys, CSEK) oder vom Kunden (Ihnen) über Google Cloud KMS verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK). Cloud Storage speichert CSEKs nicht dauerhaft auf den Google-Servern und verwaltet sie auch nicht anderweitig. Weitere Informationen zu diesen Verschlüsselungsoptionen finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel und Vom Kunden bereitgestellte Verschlüsselungsschlüssel.

gsutil akzeptiert CSEKs für die Interaktion mit Cloud Storage-Objekten mithilfe der JSON API. Die Schlüssel werden so über die .boto-Konfigurationsdatei bereitgestellt:

[GSUtil]
encryption_key = ...
decryption_key1 = ...
decryption_key2 = ...

Jeder Schlüssel ist ein Base64-codierter RFC 4648-String mit 256 Bit für die Verwendung mit dem AES256-Verschlüsselungsalgorithmus.

gsutil akzeptiert auch CMEKs zum Verschlüsseln von Objekten mithilfe der JSON API. Wenn Sie alle neu geschriebenen Objekte in einem Bucket mit einem CMEK verschlüsseln möchten, sollten Sie den Standard-KMS-Schlüssel dieses Buckets festlegen (siehe gsutil help kms). Alternativ können Sie den gewünschten CMEK in der .boto-Konfigurationsdatei angeben. Dazu müssen Sie aber nur das Attribut "encryption_key" angeben:

[GSUtil]
encryption_key = projects/PROJECT_ID/locations/LOCATION/keyRings/KEYRING/cryptoKeys/KEYNAME

Während für die Entschlüsselung eines CSEK-verschlüsselten Objekts der CSEK in einem der decryption_key-Attribute angegeben werden muss, ist dies zum Entschlüsseln von CMEK-verschlüsselten Objekten nicht erforderlich. Bei diesen Objekten ist nämlich der Name des CMEK, der zum Verschlüsseln des Objekts verwendet wird, in den Metadaten des Objekts gespeichert.

Wenn Sie CMEKs auf Befehlsbasis angeben möchten, ohne die boto-Datei bearbeiten zu müssen, können Sie den Schlüsselnamen als übergeordnete boto-Option angeben:

gsutil -o 'GSUtil:encryption_key=projects/PROJECT_ID/locations/LOCATION/keyRings/KEYRING/cryptoKeys/KEYNAME' \
       cp /some/local/file gs://my-bucket/

Verschlüsselungsverhalten

In der .boto-Konfigurationsdatei können ein einzelner Verschlüsselungsschlüssel (encryption_key) und mehrere Entschlüsselungsschlüssel (decryption_keys) angegeben werden.

Wenn in der .boto-Konfigurationsdatei ein Verschlüsselungsschlüssel vorhanden ist, sorgt gsutil dafür, dass die in Cloud Storage geschriebenen oder kopierten Daten mit diesem Schlüssel verschlüsselt werden. Wenn kein Verschlüsselungsschlüssel angegeben ist, sorgt gsutil wiederum dafür, dass für alle geschriebenen oder kopierten Daten stattdessen der Standardverschlüsselungstyp des Ziel-Buckets verwendet wird. Wenn für den Bucket ein Standard-KMS-Schlüssel festgelegt ist, wird dieser CMEK zur Verschlüsselung verwendet. Andernfalls wird die von Google verwaltete Verschlüsselung eingesetzt.

Bei jedem Herunterladen oder Kopieren von mit CSEKs verschlüsselten Objekten (mit den Befehlen "gsutil cat", "gsutil cp", "gsutil mv" oder "gsutil rsync") ist der übereinstimmende Entschlüsselungsschlüssel erforderlich. Der übereinstimmende Entschlüsselungsschlüssel ist darüber hinaus zum Abrufen der CRC32C- oder MD5-Hashes solcher Objekte erforderlich (über die Befehle "ls -L" oder "stat").

Wenn in der .boto-Konfiguration ein übereinstimmender Schlüssel vorhanden ist, stellt gsutil ihn nach Bedarf in Anfragen an Cloud Storage bereit und arbeitet mit den entschlüsselten Ergebnissen. gsutil speichert verschlüsselte Daten nie auf einem lokalen Laufwerk.

gsutil ermittelt den korrekten CSEK für ein Cloudobjekt automatisch, da der SHA256-Hash des Schlüssels mit dem Hash des CSEK verglichen wird. gsutil berücksichtigt bei der Suche nach einer Übereinstimmung den konfigurierten Verschlüsselungsschlüssel und bis zu 100 Entschlüsselungsschlüssel. Entschlüsselungsschlüssel müssen in der boto-Konfigurationsdatei in aufsteigender numerischer Reihenfolge aufgeführt werden, beginnend mit 1, zum Beispiel in der folgenden Konfiguration:

decryption_key1 = ...
decryption_key9 = ...
decryption_key10 = ...
decryption_key11 = ...

Die Entschlüsselungsschlüssel 9, 10 und 11 werden ignoriert, da keine Werte für die Entschlüsselungsschlüssel 2 bis 8 angegeben werden.

Fortsetzbare Vorgänge und Verschlüsselungsschlüssel

Wenn sich der Verschlüsselungsschlüssel in Ihrer boto-Konfigurationsdatei während eines teilweise abgeschlossenen Schreib- oder Kopiervorgangs ändert, startet gsutil den teilweise abgeschlossenen Vorgang neu, um zu gewährleisten, dass das Zielobjekt mit dem neuen Schlüssel geschrieben wird. Ein Beispiel für einen solchen Vorgang ist, wenn Sie den Upload eines Objekts mit gsutil cp noch einmal ausführen, nachdem Sie ihn über "^C" abgebrochen haben oder eine Netzwerkzeitüberschreitung eingetreten ist.

Vom Kunden bereitgestellte Verschlüsselungsschlüssel erzeugen

Das Erzeugen eines Base64-codierten RFC 4648-Strings mit 256 Bit zur Verwendung als Verschlüsselungsschlüssel kann einfach mit Python durchgeführt werden:

python -c 'import base64; import os;\
           print(base64.encodestring(os.urandom(32)))'

Vom Kunden bereitgestellte Verschlüsselungsschlüssel verwalten

Da Google keine CSEKs speichert, verlieren Sie bei Verlust Ihres CSEK dauerhaft den Zugriff auf alle mit diesem Schlüssel verschlüsselten Daten. Daher wird empfohlen, jeden Verschlüsselungsschlüssel an einem sicheren Ort aufzubewahren. Die .boto-Konfigurationsdatei sollte niemals der einzige Speicherort für Ihren Schlüssel sein.

Wenn Sie einen CSEK erstellen, kann jeder, der den Schlüssel und Zugriff auf Ihre Objekte hat, die Daten dieser Objekte lesen. Achten Sie darauf, Ihre Verschlüsselungsschlüssel nicht mit nicht vertrauenswürdigen Parteien zu teilen.

Schlüssel rotieren

Zum Rotieren von CSEKs können Sie den Konfigurationswert des Verschlüsselungsschlüssels in einen Konfigurationswert für Entschlüsselungsschlüssel ändern und dann einen neuen Wert für den Verschlüsselungschlüssel verwenden. Anschließend können Sie mit dem Befehl "rewrite" Schlüssel in der Cloud rotieren, ohne die Daten herunterladen und noch einmal hochladen zu müssen. Angenommen, Ihre Anfangskonfiguration lautet so:

# Old encryption key
encryption_key = keyA...

Sie können die Konfiguration so ändern:

# New encryption key
encryption_key = keyB...
# Encryption key prior to rotation
decryption_key1 = keyA...

Anschließend können Sie den Verschlüsselungsschlüssel für ein Objekt rotieren. Dafür führes Sie folgenden Befehl aus:

gsutil rewrite -k gs://bucket/object temp-file

Hiermit können Sie auch verschiedene CMEKs anwenden. Es ist jedoch nicht nötig, CMEKs zu den Konfigurationswerten für Entschlüsselungsschlüssel hinzuzufügen. Ebenso können Sie zwischen CSEK- und CMEK-Verschlüsselung wechseln, wobei dies vom Schlüsseltyp abhängig ist, der im Konfigurationswert für Verschlüsselungsschlüssel angegeben ist.

Auswirkungen auf die Leistung von Verschlüsselungsschlüsseln

Beim Durchführen einer Objektauflistung enthalten Metadaten für Objekte, die mit einem CSEK oder CMEK verschlüsselt wurden, nicht die CRC32C- oder MD5-Hashes der Objekte. Bei gsutil-Befehlen, für die diese Felder erforderlich sind, z. B. gsutil ls -L, führt gsutil eine zusätzliche GET-Metadatenanfrage für jedes mit einem CSEK oder CMEK verschlüsselte Objekt aus. Daher ist für das Auflisten solcher Objekte mit dem Flag "-L" ein zusätzlicher Vorgang pro Objekt erforderlich, der wesentlich langsamer ist als das Auflisten von Objekten, die mit Google-Schlüsseln verschlüsselt sind.

Auswirkungen auf die Sicherheit für vom Kunden bereitgestellte Verschlüsselungsschlüssel

gsutil sendet Verschlüsselungsschlüssel immer über HTTPS, sodass Ihre CSEKs nie im Netzwerk sichtbar sind. Die Schlüssel sind jedoch sowohl in der .boto-Konfigurationsdatei als auch im Arbeitsspeicher der Maschine enthalten, auf der gsutil ausgeführt wird. Wenn diese Datei oder die Maschine manipuliert wurde, sollten daher auch Ihre Verschlüsselungsschlüssel als manipuliert gelten und Sie sollten sofort eine Schlüsselrotation für alle Objekte ausführen, die mit den manipulierten Schlüsseln verschlüsselt sind.

XML API wird nicht unterstützt

gsutil unterstützt die Interaktion mit verschlüsselten Objekten nicht über die XML API. Stattdessen wird die JSON API verwendet, wenn in der Konfiguration Verschlüsselungs- oder Entschlüsselungsschlüssel angegeben sind.