Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

CMEK-Compliance in Cloud Build

Cloud Build bietet vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK). Dabei wird der nichtflüchtige Speicher für die Build-Dauer mit einem sitzungsspezifischen Schlüssel verschlüsselt, der für jeden Build generiert wird. Es ist keine Konfiguration erforderlich. Für jeden Build wird ein eindeutiger Schlüssel generiert.

Sobald der Build abgeschlossen ist, wird der Schlüssel aus dem Speicher entfernt und gelöscht. Er wird nirgendwo gespeichert, ist weder für Google-Entwickler noch für Supportmitarbeiter zugänglich und kann nicht wiederhergestellt werden. Die mit einem solchen Schlüssel geschützten Daten sind dauerhaft unzugänglich.

Wie funktioniert die flüchtige Schlüsselverschlüsselung?

Cloud Build unterstützt CMEK durch Verwendung von flüchtigen Schlüsseln. Der Service ist dadurch vollständig mit einer CMEK-fähigen Einrichtung konsistent und kompatibel.

Cloud Build führt die folgenden Schritte aus, damit zum Erstellen verwendete nichtflüchtige Speicher mit einem flüchtigen Schlüssel verschlüsselt werden:

  1. Cloud Build erstellt im lokalen RAM einen zufälligen 256-Bit-Verschlüsselungsschlüssel, um jeden während der Erstellung nichtflüchtigen Speicher zu verschlüsseln.

  2. Cloud Build nutzt die Funktion des nichtflüchtigen Speichers für vom Kunden bereitgestellte Verschlüsselungsschlüssel (Customer-Supplied Encryption Key, CSEK), um den neuen Verschlüsselungsschlüssel als Verschlüsselungsschlüssel für den nichtflüchtigen Speicher zu verwenden.

  3. In Cloud Build wird der flüchtige Schlüssel, der aus dem lokalen RAM für den Build erstellt wurde, unmittelbar nach dem Start des Builds gelöscht. Der Schlüssel wird nie protokolliert oder in einen nichtflüchtigen Speicher geschrieben und kann nicht mehr wiederhergestellt werden.

  4. Nach Abschluss des Builds wird der nichtflüchtige Speicher gelöscht. Danach sind weder der Schlüssel noch die verschlüsselten Daten im nichtflüchtigen Speicher in der Google-Infrastruktur zu finden.

Wann erfolgt keine flüchtige Schlüsselverschlüsselung?

In den folgenden Szenarien erfolgt keine flüchtige Schlüsselverschlüsselung:

  • Wenn Sie einen Build durch Quellspiegelung (anstatt mit GitHub-App-Triggern) erstellen oder auslösen, wird der Quellcode in Cloud Storage oder Cloud Source Repositories gespeichert. Sie können den Speicherort für den Code frei wählen und seine Verschlüsselung uneingeschränkt steuern.

  • Wenn Sie einen eigenen Bucket für Cloud Build-Build-Logs angeben und einen verschlüsselten Log-Bucket bereitstellen, müssen Sie Stackdriver Logging deaktivieren. Deaktivieren Sie anschließend das Streaming von Cloud Build-Logs wie unter BuildOptions beschrieben.

  • Wenn Sie einen Build aus der Cloud Build GitHub-App auslösen, ruft Cloud Build den Quellcode aus GitHub ab. Anschließend wird ein Cloud Storage-Bucket mit einer eintägigen Objekt-TTL erstellt und der Code in diesem Bucket gespeichert. Sie haben weder Zugriff auf diesen Bucket, noch können Sie ihn steuern.

  • Wenn Sie sich in einer geografischen Region befinden, in der hinsichtlich der Verschlüsselung lokale Einschränkungen gelten, wie in Brasilien oder Indien, kann Cloud Build auf die nichtflüchtigen Speicher keine flüchtigen Schlüsselverschlüsselungen anwenden.