Vertrauliche Ressourcen erstellen und Zugriff darauf gewähren

Datenmitbearbeiter müssen die folgenden Ressourcen einrichten, damit ihre vertraulichen Daten für eine Arbeitslast zugänglich sind:

Außerdem müssen die Datenbearbeiter festlegen, wo die Ergebnisse der Arbeitslast des Confidential Space gespeichert werden und ob die angezeigten Daten eindeutig oder freigegeben sind. Sie können beispielsweise dasselbe Ergebnis in mehrere Cloud Storage-Buckets ausgeben, die den einzelnen Datenbearbeitern gehören.

Daten speichern

Sie können jeden Google Cloud -Dienst verwenden, der Daten speichert, um Ihre vertraulichen Daten zu hosten. Beispielsweise können Sie einen der folgenden Dienste verwenden:

Sie sollten dafür sorgen, dass diese Daten im Ruhezustand verschlüsselt sind, sei es mithilfe von integrierten Funktionen oder mithilfe von Diensten wie dem Cloud Key Management Service (Cloud KMS).

Dienstkonto zum Entschlüsseln vertraulicher Daten erstellen

Sie stellen Ihre vertraulichen Daten über Dienstkonten für Arbeitslasten in Confidential Space zur Verfügung und verringern so die Zugriffsrechte von Personen auf diese Daten.

Sie können beispielsweise vertrauliche Dateien in Cloud Storage mit Cloud KMS verschlüsseln und dann ein Dienstkonto erstellen, das zum Zugriff auf diese Daten und zum Entschlüsseln den entsprechenden Schlüssel hat.

Verbinden Sie dieses Dienstkonto dann mit einem WIP. Eine autorisierte Arbeitslast für einen Confidential Space in einem anderen Projekt kann dann dieses WIP verwenden, um die Identität des Dienstkontos zu übernehmen, das die Daten entschlüsselt, die entschlüsselten Daten abzurufen und zu verarbeiten.

Da Dienstkonten sowohl zum Entschlüsseln als auch zum Verarbeiten dieser vertraulichen Daten verwendet werden, ist die Sichtbarkeit der Daten auf ihre Inhaber beschränkt. Da die Arbeitslast in einer Confidential VM ausgeführt wird, sorgt die hardwarebasierte Speicherverschlüsselung dafür, dass Ihre Daten während der Nutzung privat bleiben. SSH wird auch auf Arbeitslast-VMs deaktiviert, die das Produktions-Image für Confidential Space verwenden. Das bedeutet, dass niemand auf die VM zugreifen kann, während sie ausgeführt wird.

Ein Beispiel dafür finden Sie unter Erste Confidential Space-Umgebung erstellen.

WIP und Anbieter für die Attestierungsvalidierung erstellen

Zum Schutz von Daten vor einem nicht vertrauenswürdigen Arbeitslastoperator implementiert Confidential Space einen Attestierungsprozess, der Änderungen an einem Arbeitslast-Image oder seiner TEE erkennt. Der Prozess beruht auf Shielded VM-Messungen von Measured Boot und erweiterten Laufzeiten und erfasst Messungen der Startsequenz in einem geschützten "extend-only"-Register im vTPM-Gerät (virtual Trusted Platform Module).

Der Attestierungsdienst von Confidential Space generiert OpenID Connect-Tokens (OIDC), die diese vTPM-Attestierungen in einer Form enthalten, die von einem WIP validiert werden kann. Dabei werden sie anhand von Richtlinien geprüft, die als Attributbedingungen zu einem Anbieter hinzugefügt werden. Diese Tokens werden von Google signiert, sind eine Stunde gültig und werden automatisch aktualisiert.

Wenn der WIP die Arbeitslast autorisiert, kann die Arbeitslast die Identität von Dienstkonten im Projekt übernehmen, um vertrauliche Daten zu entschlüsseln und abzurufen.

So richten Sie einen WIP und einen Anbieter ein:

  1. Erstellen Sie das WIP.

  2. Verbinden Sie das Dienstkonto für die Entschlüsselung mit der Rolle iam.workloadIdentityUser mit dem WIP.

  3. Erstellen Sie einen OIDC-Anbieter mit den folgenden Details:

    • Einen Aussteller-URI von https://confidentialcomputing.googleapis.com/.

    • Eine zulässige Zielgruppe von https://sts.googleapis.com.

    • Eine Attributzuordnung des Anbieters für google.subject mit dem Wert assertion.sub.

    • Attributbedingungen, mit denen die Attestierungen der Arbeitslast validiert werden. Informationen zu den verfügbaren Optionen finden Sie unter Attestierungsrichtlinie erstellen.

Attestierungsrichtlinie erstellen

Beim Erstellen eines WIP fügen Sie Attributbedingungen hinzu, die eine Arbeitslast erfüllen muss, um auf Ihre Daten zugreifen zu können. Für einen vertraulichen Gruppenbereich bilden diese Attributbedingungen Ihre Attestierungsrichtlinie.

Richtlinien werden in der Common Expression Language (CEL) geschrieben und bestehen aus einer Reihe von Behauptungen, die mit dem Operator && miteinander verknüpft werden können.

Im Folgenden finden Sie ein Beispiel für das Hinzufügen eines Anbieters zu einem Workload Identity-Pool mithilfe der gcloud CLI zusammen mit der Option attribute-condition, die die Richtlinien definiert:

gcloud iam workload-identity-pools providers create-oidc attestation-verifier \
    --location=global \
    --workload-identity-pool=user-pool-name \
    --issuer-uri="https://confidentialcomputing.googleapis.com/" \
    --allowed-audiences="https://sts.googleapis.com" \
    --attribute-mapping="google.subject=assertion.sub" \
    --attribute-condition="assertion.submods.container.image_digest =='sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b' \
&& 'service-account@my-project.iam.gserviceaccount.com' in assertion.google_service_accounts \
&& assertion.swname == 'CONFIDENTIAL_SPACE' \
&& 'STABLE' in assertion.submods.confidential_space.support_attributes"

In diesem Beispiel muss eine externe Identität, die versucht, die Identität eines Dienstkontos zu übernehmen, das mit dem Workload Identity-Pool verbunden ist, die folgenden Details attestieren und deren Werte müssen mit den Richtlinienwerten übereinstimmen, damit die Authentifizierung erfolgreich ist:

  • Den Image-Digest des Arbeitslastcontainers

  • Die Adresse des Dienstkontos, das mit der VM der Arbeitslast verbunden ist

  • Diese CONFIDENTIAL_SPACE ist die Software, die auf der VM ausgeführt wird, mit allen integrierten Sicherheitsgarantien.

  • Das Attribut „support“ für das Confidential Space-Produktions-Image

Attestierungs-Assertions

Die verfügbaren Behauptungen zum Erstellen einer Attestierungsrichtlinie sind in der folgenden Tabelle aufgeführt. Sie können Behauptungen validieren, die vom Confidential Space-Image, dem Arbeitslastcontainer und der VM gemacht wurden.

Bildbeschreibungen

Behauptung Typ Beschreibung

assertion.dbgstat

Interagiert mit:

 Definierter String

Prüft, ob das Confidential Space-Image die Debugging- oder Produktionsversion ist.

Gültige Werte:

  • enable: Prüfen, ob das Debug-Image verwendet wird.
  • disabled-since-boot: Prüfen, ob das Produktions-Image verwendet wird.
Beispiele

Mit dem folgenden Code wird überprüft, ob die Debugging-Version des Confidential Space-Images verwendet wird:

assertion.dbgstat == "enable"

Mit dem folgenden Code wird überprüft, ob die Produktionsversion des Confidential Space-Images verwendet wird:

assertion.dbgstat == "disabled-since-boot"
assertion.submods.confidential_space.support_attributes String-Array

Prüft, ob die Sicherheitsversion der TEE ein Confidential Space-Produktions-Image ist. Für Debug-Images im Confidential Space ist kein Attribut „support“ festgelegt.

Es gibt drei Supportattribute:

  • LATEST: Dies ist die neueste Version des Bilds und wird unterstützt. Das Bild LATEST ist auch STABLE und USABLE.
  • STABLE: Diese Version des Images wird unterstützt und auf Sicherheitslücken überwacht. Ein STABLE-Bild ist auch USABLE.
  • USABLE: Ein Image mit nur diesem Attribut wird nicht mehr unterstützt und nicht mehr auf Sicherheitslücken überwacht. Sie gehen dabei auf eigenes Risiko vor.
Beispiel

Mit dem folgenden Code wird überprüft, ob eine stabile Version des Confidential Space-Images verwendet wird:

"STABLE" in assertion.submods.confidential_space.support_attributes
assertion.swname Definierter String

Prüft die Software, die auf der attestierenden Entität ausgeführt wird. Der Wert ist immer CONFIDENTIAL_SPACE.

Beispiel
assertion.swname == "CONFIDENTIAL_SPACE"
assertion.swversion String-Array

Verifiziert die Softwareversion des Confidential Space-Images. Wir empfehlen stattdessen die Verwendung von assertion.submods.confidential_space.support_attributes, um die Ausrichtung auf die neueste Version eines Bildes vorzunehmen.

Beispiel
int(assertion.swversion[0]) == 230103

Container-Assertions

Behauptung Typ Beschreibung

assertion.submods.container.cmd_override

Interagiert mit:

 String-Array

Verifiziert die CMD-Befehle und ‑Parameter, die im Arbeitslast-Image verwendet werden.

Beispiele

Mit dem folgenden Code wird überprüft, ob der CMD des Arbeitslast-Images nicht überschrieben wurde:

size(assertion.submods.container.cmd_override) == 0

Mit dem folgenden Code wird überprüft, ob program der einzige Inhalt in den CMD-Überschreibungen ist:

assertion.submods.container.cmd_override == ['program']

assertion.submods.container.env

Interagiert mit:

 JSON-Objekt

Prüft, ob Umgebungsvariablen und ihre Werte explizit an den Container übergeben wurden.

Beispiel

Im folgenden Code wird überprüft, ob die Umgebungsvariable example-env-1 auf value-1 und example-env-2 auf value-2 festgelegt ist.

assertion.submods.container.env == {"example-env-1": "value-1", "example-env-2": "value-2"}

assertion.submods.container.env_override

Interagiert mit:

 String

Prüft, ob der Arbeitslast-Operator Umgebungsvariablen im Container überschrieben hat.

Beispiele

Mit dem folgenden Code wird überprüft, ob der Arbeitslastbearbeiter die Umgebungsvariable example nicht überschrieben hat:

!has(assertion.submods.container.env_override.example)

Mit dem folgenden Code wird überprüft, ob der Arbeitslastoperator keine Umgebungsvariablen überschrieben hat:

size(assertion.submods.container.env_override) == 0
assertion.submods.container.image_digest String

Verifiziert den Image-Digest des Arbeitslastcontainers. Durch die Angabe dieser Bedingung können mehrere Parteien einer autorisierten Arbeitslast zustimmen, die auf ihre Daten zugreifen darf.

Beispiel
assertion.submods.container.image_digest == "sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b"
assertion.submods.container.image_id String

Verifiziert die Image-ID des Arbeitslastcontainers.

Beispiel
assertion.submods.container.image_id == "sha256:652a44b0e911271ba07cf2915cd700fdfa50abd62a98f87a57fdebc59843d93f"

assertion.submods.container.image_reference

Interagiert mit:

 String

Verifiziert den Speicherort des Arbeitslastcontainers, der über dem Confidential Space-Image ausgeführt wird.

Beispiel
assertion.submods.container.image_reference == "us-docker.pkg.dev/PROJECT_ID/WORKLOAD_CONTAINER:latest"

assertion.submods.container.image_signatures

Interagiert mit:

 JSON-Objekt

Prüft, ob das Bild eine bestimmte Signatur hat oder mit einem öffentlichen Schlüssel und Signaturalgorithmus signiert ist. Durch die Angabe dieser Bedingung können mehrere Parteien einer autorisierten Arbeitslast zustimmen, die auf ihre Daten zugreifen darf.

Die Behauptung kann die folgenden Elemente enthalten:

  • key_id: Der Hexadezimal-Fingerabdruck des öffentlichen Schlüssels. Führen Sie den folgenden Befehl aus, um den Fingerabdruck abzurufen:

    openssl pkey -pubin -in public_key.pem -outform DER | openssl sha256

    Dabei ist public_key.pem Ihr öffentlicher Schlüssel im PEM-Format.

  • signature: Die Signatur über einer Nutzlast, die dem signierten Container zugeordnet ist und dem Format für die einfache Signatur entspricht.

  • signature_algorithm: Der Algorithmus, mit dem der Schlüssel signiert wird. Eines der folgenden Betriebssysteme:

    • RSASSA_PSS_SHA256 (RSASSA-PSS mit einem SHA-256-Digest)
    • RSASSA_PKCS1V15_SHA256 (RSASSA-PKCS1 v1_5 mit SHA-256-Digest)
    • ECDSA_P256_SHA256 (ECDSA auf der P-256-Kurve mit einem SHA-256-Digest)
Beispiel
assertion.swname == 'CONFIDENTIAL_SPACE' && ['ECDSA_P256_SHA256:PUBLIC_KEY_FINGERPRINT'].exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig, sig.signature_algorithm+':'+sig.key_id)) && 'serviceaccount.iam.gserviceaccount.com' in assertion.google_service_accounts"

assertion.submods.container.restart_policy

Interagiert mit:

 Definierter String

Prüft die Neustart-Richtlinie des Container-Launchers für den Fall, dass die Arbeitslast beendet wird.

Gültige Werte:

  • Never (Standard)
  • Always
  • OnFailure
Beispiel
assertion.submods.container.restart_policy == "Never"

VM-Behauptungen

Behauptung Typ Beschreibung

assertion.google_service_accounts

Interagiert mit:

 String-Array

Prüft, ob ein bestimmtes Dienstkonto mit der VM verbunden ist, auf der die Arbeitslast ausgeführt wird, oder mit tee-impersonate-service-accounts in den VM-Metadaten aufgelistet wurde.

Beispiel
workload-service-account@my-project.iam.gserviceaccount.com in assertion.google_service_accounts
assertion.hwmodel String

Verifizierung der zugrunde liegenden Confidential Computing-Technologie. Folgende Plattformen werden unterstützt:

Beispiel
assertion.hwmodel == "GCP_AMD_SEV"

assertion.submods.confidential_space.monitoring_enabled

Interagiert mit:

 Boolesch

Prüft den Überwachungsstatus der attestierenden Entität.

Beispiel
assertion.submods.confidential_space.monitoring_enabled.memory == true
assertion.submods.gce.instance_id String

Die VM-Instanz-ID wird überprüft.

Beispiel
assertion.submods.gce.instance_id == "0000000000000000000"
assertion.submods.gce.instance_name String

Verifies the name of the VM instance.

Beispiel
assertion.submods.gce.instance_name == "workload-vm"
assertion.submods.gce.project_id String

Prüft, ob auf der VM ein Google Cloud -Projekt mit der angegebenen Projekt-ID ausgeführt wird.

Beispiel
assertion.submods.gce.project_id == "project-id"
assertion.submods.gce.project_number String

Prüft, ob die VM in einem Google Cloud -Projekt mit der angegebenen Projektnummer ausgeführt wird.

Beispiel
assertion.submods.gce.project_number == "00000000000"

assertion.submods.gce.zone

Interagiert mit:

  • Arbeitslastoperator: Der Wert für --zone .
 String

Prüft, ob die VM in der angegebenen Zone ausgeführt wird.

Beispiel
assertion.submods.gce.zone == "us-central1-a"