Vom Kunden verwaltete Verschlüsselungsschlüssel

Einrichtung

In Cloud Storage werden inaktive Kundendaten standardmäßig verschlüsselt. Die Verschlüsselung wird von Cloud Storage durchgeführt. Zusätzliche Maßnahmen Ihrerseits sind nicht erforderlich. 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 Storage 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 Storage-Ressourcen der Verwendung der Google-Standardverschlüsselung. Weitere Informationen zu CMEKs finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK). Informationen zum Schutz Ihrer Cloud Storage-Ressourcen mit manuell erstellten CMEKs finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel verwenden.

Weitere Informationen zu anderen Verschlüsselungsoptionen bei der Verwendung von Cloud Storage finden Sie unter Datenverschlüsselungsoptionen.

CMEK mit Cloud KMS Autokey

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

Autokey erstellt keine Schlüssel für Objekte. Standardmäßig verwenden Objekte in einem Bucket den Standardschlüssel des Buckets. Wenn Sie ein Objekt mit einem anderen Schlüssel als dem Standardschlüssel des Buckets verschlüsseln möchten, können Sie einen CMEK manuell erstellen und beim Erstellen des Objekts verwenden.

Informationen zum Verwenden von CMEKs, die mit Cloud KMS Autokey erstellt wurden, um Ihre Cloud Storage-Buckets und die darin enthaltenen Objekte zu schützen, finden Sie unter Autokey mit Cloud Storage-Ressourcen verwenden.

Wann wird der Schlüssel verwendet?

Wenn Sie einen CMEK auf ein Objekt anwenden, verwendet Cloud Storage den Schlüssel, um Folgendes zu verschlüsseln:

  • Die Daten des Objekts
  • Die CRC32C-Prüfsumme des Objekts
  • Den MD5-Hash des Objekts

Cloud Storage verwendet standardmäßige serverseitige Schlüssel zum Verschlüsseln der verbleibenden Metadaten für das Objekt, einschließlich des Objektnamens. Wenn Sie ausreichende Berechtigungen haben, können Sie also beispielsweise die meisten Metadaten lesen sowie Objekte auflisten und löschen, auch nachdem Sie den zugehörigen CMEK deaktiviert oder gelöscht haben.

Kundenservicemitarbeiter

Jedes Projekt verfügt über ein spezielles Cloud Storage-Dienstkonto, den sogenannten Dienst-Agent, der die Verschlüsselung und Entschlüsselung mit CMEKs durchführt. Nachdem Sie dem Dienst-Agent Zugriff auf einen Verschlüsselungsschlüssel gewährt haben, verschlüsselt dieser Dienst-Agent:

Wenn Sie sowohl einen Standardschlüssel für Ihren Bucket als auch einen spezifischen Schlüssel für die Anfrage festgelegt haben, verwendet Cloud Storage den spezifischen Schlüssel zum Verschlüsseln des Objekts, wenn ein Objekt in Cloud Storage hinzugefügt oder neu geschrieben wird.

Wenn ein Anfragesteller ein Objekt lesen möchte, das mit einem CMEK verschlüsselt ist, kann er wie gewohnt auf das Objekt zugreifen. Bei einer solchen Anfrage entschlüsselt der Dienst-Agent automatisch das angeforderte Objekt, wenn diese Bedingungen gegeben sind:

  • Der Dienst-Agent hat weiterhin die Berechtigung, mit dem Schlüssel zu entschlüsseln
  • Sie haben den Schlüssel nicht deaktiviert oder gelöscht

Wenn eine dieser Bedingungen nicht erfüllt ist, entschlüsselt der Dienst-Agent die Daten nicht und die Anfrage schlägt fehl.

Beschränkungen

Die Verwendung von CMEKs unterliegt den folgenden Einschränkungen:

  • Sie können ein Objekt nicht mit einem CMEK verschlüsseln, indem Sie seine Metadaten aktualisieren. Fügen Sie den Schlüssel stattdessen hinzu, während Sie das Objekt neu schreiben.

    • gcloud storage verwendet den Befehl objects update, um Verschlüsselungsschlüssel für Objekte festzulegen, aber der Befehl schreibt das Objekt als Teil der Anfrage neu.

  • Sie müssen den Cloud KMS-Schlüsselbund am selben Standort wie die Daten erstellen, die Sie verschlüsseln möchten. Wenn sich Ihr Bucket beispielsweise in US-EAST1 befindet, muss jeder Schlüsselbund, der zum Verschlüsseln von Objekten in diesem Bucket verwendet wird, in US-EAST1 erstellt werden.

    • Bei Dual-Regionen muss der Speicherort des Cloud KMS-Schlüsselbunds mit dem Standortcode der Dual-Region übereinstimmen. Wenn sich Ihr Bucket beispielsweise im konfigurierbaren Dual-Region-Paar US-EAST1, US-WEST1 befindet, muss jeder Schlüsselbund, der zum Verschlüsseln von Objekten in diesem Bucket verwendet wird, in der Multiregion US erstellt werden, die dem Standortcode dieses Buckets entspricht. Wenn sich Ihr Bucket in der vordefinierten Dual-Region NAM4 befindet, müssen Sie den Schlüsselbund in derselben vordefinierten Dual-Region NAM4 erstellen.

      Informationen zu verfügbaren Cloud KMS-Standorten finden Sie unter Cloud KMS-Standorte.

  • Verschlüsselungs- und Entschlüsselungsraten für Cloud KMS unterliegen einem Kontingent.

  • Die CRC32C-Prüfsumme und der MD5-Hash von Objekten, die mit CMEKs verschlüsselt sind, werden nicht zurückgegeben, wenn Objekte mit der JSON API aufgelistet werden

    • Gegebenenfalls führen einige Tools wie gcloud storage für jedes Objekt, das mit einem CMEK verschlüsselt ist, eine zusätzliche Metadatenanfrage GET durch, um CRC32C- und MD5-Informationen abzurufen. Diese zusätzliche Anfragen können die Auflistung wesentlich langsamer machen als die Auflistung von Objekten, die mit der standardmäßigen Cloud Storage-Verschlüsselung verschlüsselt sind.

  • Als CMEKs können nur symmetrische Verschlüsselungsschlüssel verwendet werden.

Bezug zu vom Kunden bereitgestellten Verschlüsselungsschlüsseln

Neben der Verschlüsselung, die vom Kunden verwaltet wird, bietet Cloud Storage zur Steuerung Ihrer Datenverschlüsselung auch vom Kunden bereitgestellte Verschlüsselungsschlüssel. Sie können verschiedene Objekte in einem einzelnen Bucket mit unterschiedlichen Verschlüsselungsmethoden verschlüsseln, beachten Sie aber Folgendes:

  • Ein einzelnes Objekt kann immer nur mit einer dieser Methoden verschlüsselt werden.

  • Wenn der Standardschlüssel für Ihren Bucket ein CMEK ist und Sie in einer Anfrage einen vom Kunden bereitgestellten Schlüssel angeben, verwendet Cloud Storage den vom Kunden bereitgestellten Schlüssel zum Verschlüsseln des Objekts.

Schlüsselverwaltung

In diesem Abschnitt werden Überlegungen zum Rotieren von Schlüsseln und Ersetzen von Schlüsseln sowie zum Deaktivieren oder Zerstören von Schlüsselversionen erläutert.

Schlüsselrotation

Cloud KMS unterstützt sowohl die automatische als auch die manuelle Schlüsselrotation auf eine neue Version. Nach dem Rotieren eines Schlüssels verwendet Cloud Storage die neue Version für alle Vorgänge, die mit dem Schlüssel verschlüsselt werden, z. B.:

  • Objektuploads, wenn der Ziel-Bucket den Schlüssel als Standardverschlüsselungsschlüssel verwendet.

  • Upload-, Kopier- oder Umschreibvorgänge für Objekte, die den Schlüssel im Vorgang verwenden.

Frühere Versionen des Schlüssels werden nicht deaktiviert oder zerstört, sodass Cloud Storage weiterhin vorhandene Objekte entschlüsseln kann, die zuvor mit diesen Versionen verschlüsselt wurden.

Schlüsselersatz

Beachten Sie die folgenden Richtlinien, wenn Sie den Schlüssel zum Verschlüsseln von Cloud Storage-Objekten durch einen neuen Schlüssel ersetzen:

  1. Prüfen Sie Ihre Buckets, um zu sehen, welche den Schlüssel als Standardverschlüsselungsschlüssel verwenden. Ersetzen Sie bei diesen Buckets den alten Schlüssel durch einen neuen.

    Dadurch wird sichergestellt, dass alle in den Bucket geschriebenen Objekte künftig den neuen Schlüssel verwenden.

  2. Prüfen Sie Ihren Quellcode, um nachzuvollziehen, welche Anfragen den Schlüssel im laufenden Betrieb verwenden, z. B. beim Festlegen von Bucket-Konfigurationen und beim Hochladen, Kopieren oder Umschreiben von Objekten. Aktualisieren Sie diese Instanzen so, dass sie den neuen Schlüssel verwenden.

  3. Suchen Sie in allen Buckets nach Objekten, die mit dem alten Schlüssel verschlüsselt sind. Verwenden Sie die Methode "Rewrite Object", um jedes Objekt mit dem neuen Schlüssel neu zu verschlüsseln.

  4. Deaktivieren Sie alle Versionen des alten Schlüssels. Achten Sie nach dem Deaktivieren alter Schlüsselversionen bei Client- und Dienstlogs auf Vorgänge, die fehlschlagen, weil eine Version nicht mehr verfügbar ist.

Schlüsselversion deaktivieren oder löschen

  • Wenn Sie eine bestimmte Schlüsselversion deaktivieren oder zerstören, können Sie kein Objekt entschlüsseln, das derzeit mit dieser Schlüsselversion verschlüsselt ist.

    Sie können das Objekt beispielsweise nicht herunterladen, kopieren oder umschreiben. Wenn Sie dies versuchen, wird ein Fehler angezeigt.

    • Wenn Sie eine Schlüsselversion deaktivieren, können Sie sie wieder aktivieren. Nach der erneuten Aktivierung können Sie auf Objekte zugreifen, die mit dieser Schlüsselversion verschlüsselt wurden.

    • Wenn Sie eine Schlüsselversion zerstören, sind Downloads von mit dieser Version verschlüsselten Objekten nie wieder möglich.

    Bevor Sie eine Schlüsselversion deaktivieren oder zerstören, sollten Sie alle Objekte in allen Buckets identifizieren, die mit der spezifischen Schlüsselversion verschlüsselt wurden. Verwenden Sie nach der Identifizierung die Methode "Rewrite Object", um jedes Objekt mit einer neuen Schlüsselversion, einem völlig neuen Schlüssel oder serverseitigen Schlüsseln neu zu verschlüsseln.

  • Wenn Sie die Primärversion eines Schlüssels deaktivieren oder zerstören, können Sie den Schlüssel erst zur Verschlüsselung verwenden, wenn Sie eine neue Primärversion haben. Ohne Primärversion gilt beispielsweise Folgendes:

    • Sie können den Schlüssel nicht als Teil eines Upload-, Kopier- oder Umschreibvorgangs für Objekte angeben.

    • Sie können Objekte nicht in einen Bucket hochladen, kopieren oder umschreiben, in dem der Schlüssel als Standardverschlüsselungsschlüssel festgelegt ist, es sei denn, Sie geben im Rahmen des Vorgangs einen anderen gültigen Schlüssel an.

    Sobald Sie eine Primärversion für Ihren Schlüssel haben, sind Vorgänge erfolgreich, bei denen der Schlüssel zum Verschlüsseln von Objekten verwendet wird.

    Bevor Sie eine Schlüsselversion deaktivieren oder zerstören, die die primäre Version des Schlüssels ist, sollten Sie erst die Verwendung als primäre Version beenden. Dies kann auf zwei Arten geschehen:

    • Sie können sie durch eine neue Primärversion ersetzen, normalerweise indem Sie eine Schlüsselrotation ausführen.
    • Sie können Instanzen entfernen, in denen Sie den Schlüssel zur Verschlüsselung verwenden. Wenn Sie dies tun, verwendet Cloud Storage stattdessen serverseitige Schlüssel für die Verschlüsselung.

Schlüsselversionen und gesperrte Objekte

Wenn eine Schlüsselversion ein gesperrtes Objekt verschlüsselt, entweder weil das Objekt in einem Bucket mit einer gesperrten Aufbewahrungsrichtlinie gespeichert ist oder weil es eine eigene Konfiguration für gesperrte Aufbewahrung hat, lässt sich die Schlüsselversion nur löschen, wenn die folgenden Bedingungen erfüllt sind:

  • Die Ablaufzeit der Aufbewahrung des verschlüsselten Objekts muss in der Vergangenheit liegen.
  • Das verschlüsselte Objekt darf keine festgelegten Objekt-Holds haben.

Sobald alle relevanten Objekte diese Bedingungen erfüllen, kann die Schlüsselversion gelöscht werden, auch ohne die Objekte zu löschen. In diesem Fall sind die betroffenen Objektdaten dauerhaft unzugänglich.

Nächste Schritte