Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Confidential Space bietet eine isolierte Umgebung für den Umgang mit sensiblen Daten von mehreren Parteien, sodass die Inhaber dieser Daten sie vertraulich behandeln können.
Vertrauliche Daten können personenidentifizierbare Informationen (PII), geschützte Gesundheitsdaten (Protected Health Information, PHI), geistiges Eigentum, kryptografische Secrets, Modelle für maschinelles Lernen (ML) oder anderes umfassen.
Sie können Confidential Space verwenden, um vertrauliche Daten zu verarbeiten, die nur für die ursprünglichen Inhaber und eine gemeinsam vereinbarte Arbeitslast sichtbar sind. Alternativ können Sie damit Endkunden einen besseren Datenschutz bieten, da der Betreiber oder Inhaber einer Confidential Space-Umgebung nicht auf die verarbeiteten Daten zugreifen kann.
Confidential Space verwendet eine vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE), mit der Ihre Secrets nur für autorisierte Arbeitslasten freigegeben werden können. Ein Attestierungsprozess und ein gehärtetes Betriebssystem-Image schützen die Arbeitslast und die Daten, die die Arbeitslast verarbeitet, vor einem Operator.
Ein Confidential Space-System verfügt über drei Kernkomponenten:
Arbeitslast: Ein containerisiertes Image mit Code, der die geschützten Ressourcen verarbeitet. Es wird auf einem Confidential Space-Image ausgeführt, einem gehärteten Betriebssystem, das auf Container-Optimized OS basiert.
Dies wird wiederum auf einer Confidential VM ausgeführt, einer cloudbasierten TEE, die Hardwareisolation und Remote-Attestierungsfunktionen bietet. Die Arbeitslast befindet sich in der Regel in einem anderen Projekt als die geschützten Ressourcen.
Der Attestierungsdienst: Ein Remote-Attestierungsprüfer, der Attestierungsnachweise in Form von OpenID Connect-Tokens (OIDC) zurückgibt. Die Tokens enthalten Identifizierungsattribute für die Arbeitslast.
Der Attestierungsdienst wird in derselben Region ausgeführt wie die Arbeitslast.
Geschützte Ressourcen: Verwaltete Ressourcen, die durch ein Authentifizierungs- und Autorisierungssystem geschützt sind. Wenn sich die Ressourcen in Google Cloudbefinden, können sie verwaltete Cloud-Ressourcen wie Cloud KMS-Schlüssel (Cloud Key Management Service) oder Cloud Storage-Buckets sein. Wenn sich die Ressourcen nicht in Google Cloud befinden(z. B. in einer lokalen Umgebung oder in einer anderen Cloud), kann es sich um eine beliebige Ressource handeln.
Confidential Space-Rollen
Die Komponenten in einem Confidential Space-System werden von Personen mit drei verschiedenen Rollen verwaltet:
Datenmitbearbeiter: Die Personen oder Organisationen, denen die geschützten Ressourcen gehören, die von der Arbeitslast verarbeitet werden. Datenmitbearbeiter können auf ihre eigenen Daten zugreifen, Berechtigungen für diese Daten festlegen und je nach Ausgabe des Arbeitslastprozesses auf Ergebnisse zugreifen, die auf diesen Daten basieren.
Data Collaborators können nicht auf die Daten der anderen zugreifen oder den Arbeitslastcode ändern.
Arbeitslastautor: Die Person, die die Anwendung erstellt, mit der auf die vertraulichen Daten zugegriffen und diese verarbeitet werden. Sie fügen die Anwendung einem containerisierten Image hinzu, z. B. mit Docker, und laden das Image in ein Repository wie Artifact Registry hoch.
Der Autor der Arbeitslast hat keinen Zugriff auf die Daten oder die Ergebnisse und kann den Zugriff darauf auch nicht steuern.
Arbeitslastoperator: Die Person, die die Arbeitslast ausführt. Der Arbeitslastoperator hat in der Regel uneingeschränkte Administratorberechtigungen für das Projekt, in dem er die Arbeitslast ausführt. Sie können beispielsweise Ressourcen in ihrem Projekt verwalten, z. B. Compute Engine-Instanzen, Laufwerke und Netzwerkregeln, und mit jederGoogle Cloud API interagieren, die darauf reagiert.
Der Arbeitslastoperator hat keinen Zugriff auf die Daten und kann den Zugriff darauf auch nicht steuern. Sie können den Arbeitslastcode oder die Ausführungsumgebung nicht beeinflussen oder ändern.
Eine Person kann eine oder mehrere dieser Rollen übernehmen. Für maximale Sicherheit unterstützt Confidential Space ein Vertrauensmodell, bei dem Datenmitarbeiter, Arbeitslastautoren und Arbeitslastoperatoren voneinander getrennte, sich gegenseitig nicht vertrauende Parteien sind. Alle Rollen müssen zusammenarbeiten, um die gewünschten Ergebnisse zu erzielen.
Beispiel für einen Confidential Space-Ablauf
Confidential Space nutzt mehrere Google Cloud Dienste, um vertrauliche Informationen vertraulich zu verarbeiten. Das Einrichten eines Confidential Space könnte in etwa so aussehen:
Mehrere Datenmitbearbeiter speichern verschlüsselte vertrauliche Daten in ihren eigenen isolierten Google Cloud Projekten, oft in verschiedenen Organisationen. Sie möchten diese Daten vergleichen und verarbeiten, ohne sie einander oder externen Parteien offenzulegen. Die verschlüsselten Daten können sich in Cloud Storage, BigQuery oder einem anderen Dienst befinden.
Die Datenbearbeiter erstellen simulierte, nicht vertrauliche Daten, die von einer Testarbeitslast verarbeitet werden können. Diese Daten können sich in verschiedenen Dateien oder an einem anderen Ort wie einem separaten Cloud Storage-Bucket befinden.
Die Datenmitbearbeiter erstellen einen Workload Identity-Pool (WIP).
Später kann eine Arbeitslast, die im separaten, isolierten Projekt eines Arbeitslastoperators ausgeführt wird, diesen WIP verwenden, um auf die vertraulichen Daten der Mitbearbeiter zuzugreifen.
Der Autor der Arbeitslast schreibt Code zum Verarbeiten der vertraulichen Daten. In einem Projekt, das von den Datenmitarbeitern und dem Arbeitslastoperator getrennt ist, erstellen sie mit Docker ein Container-Image und laden es in Artifact Registry hoch.
Der Arbeitslastoperator erstellt ein Dienstkonto in einem isolierten Projekt, das Lesezugriff auf den Speicherort der verschlüsselten vertraulichen Daten der Datenmitarbeiter und Schreibzugriff auf einen Speicherort (z. B. einen Cloud Storage-Bucket) hat, um das Ergebnis der Verarbeitung der entschlüsselten Daten auszugeben. Später wird dieses Dienstkonto an eine Confidential VM angehängt, auf der die Arbeitslast ausgeführt wird.
Die Datenmitarbeiter fügen ihren Workload Identity-Pools einen Anbieter hinzu. Sie fügen dem Anbieter Details hinzu, z. B. den zu verwendenden Attestierungsservice, Attributzuordnungen zum Erstellen eines Prüfpfads in Protokollen und Attributbedingungen.
Diese Details bestätigen die Assertionen des Confidential Space-Images, des Arbeitslastcontainers und der Arbeitslast-VM-Instanz. Wenn die Arbeitslast diese Überprüfung besteht, darf sie auf die vertraulichen Daten zugreifen und sie entschlüsseln.
Die Arbeitslast wird mit den nicht vertraulichen Daten getestet, indem eine Confidential VM-Instanz im Projekt des Arbeitslastoperators gestartet wird. Die VM basiert auf einer Debug-Version des Confidential Space-Image, in der die containerisierte Arbeitslast geladen wird.
Nachdem die Attestierungen der VM überprüft wurden und die Arbeitslast die Bedingungen der Datenmitwirkenden erfüllt, darf das an die VM angehängte Dienstkonto auf die vertraulichen Daten zugreifen, sie verarbeiten und ein Ergebnis ausgeben.
Nachdem Monitoring und Debugging abgeschlossen sind, wird die Arbeitslast für die Produktionsumgebung aktualisiert. Die Datenbearbeiter aktualisieren und sichern ihre Anbieter von Arbeitslastidentitäten bei Bedarf weiter und testen die Produktionsarbeitslast möglicherweise zuerst mit nicht vertraulichen Daten.
Alle Parteien stimmen der Produktionsarbeitslast zu und die Arbeit an vertraulichen Daten kann beginnen.
Voraussetzungen
Confidential Space erfordert Confidential VM, um zu funktionieren. Für Confidential VM-Instanzen muss AMD SEV, Intel TDX oder Intel TDX mit NVIDIA Confidential Computing (Vorschau) als Confidential Computing-Technologie verwendet werden. Unter Unterstützte Konfigurationen finden Sie Informationen zu Hardwarekonfigurationsoptionen und dazu, an welchen Standorten Confidential VM-Instanzen erstellt werden können.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-18 (UTC)."],[[["\u003cp\u003eConfidential Space offers a secure environment for processing sensitive data, ensuring that data owners retain confidentiality and control over who can access their information.\u003c/p\u003e\n"],["\u003cp\u003eThe system utilizes a trusted execution environment (TEE) with attestation processes and a hardened OS to safeguard workloads and data from unauthorized access, even from the operator.\u003c/p\u003e\n"],["\u003cp\u003eConfidential Space is built around three core components: a containerized workload, an attestation service for verifying workload identity, and protected resources managed by authentication and authorization systems.\u003c/p\u003e\n"],["\u003cp\u003eThree distinct roles—data collaborators, workload authors, and workload operators—manage the system, enabling a trust model where these parties can be separate and mutually distrusting for enhanced security.\u003c/p\u003e\n"],["\u003cp\u003eSetting up Confidential Space involves a detailed process that includes encrypted data storage, test workload creation, service account setup, code development, attestation verification, and rigorous testing before production use on confidential data.\u003c/p\u003e\n"]]],[],null,["# Confidential Space overview\n\n*** ** * ** ***\n\nConfidential Space provides an isolated environment to operate on sensitive data\nfrom multiple parties, so the owners of that data can keep it confidential.\nSensitive data might include personally identifiable information (PII),\nprotected health information (PHI), intellectual property, cryptographic\nsecrets, machine learning (ML) models, or otherwise.\n\nYou might use Confidential Space to operate on sensitive data that's only visible\nto its original owners and a mutually agreed-upon workload. Alternatively, you\ncould use it to offer end customers stronger data privacy, as the operator or\nowner of a Confidential Space environment can't access the data that is being\nprocessed.\n\nConfidential Space uses a trusted execution environment (TEE) that can be used to\nrelease your secrets only to authorized workloads. An attestation process and\nhardened OS image help protect the workload and the data that the workload\nprocesses from an operator.\n\nFor more detail about Confidential Space's use cases and security model, see\n[Confidential Space security overview](/docs/security/confidential-space).\n\nConfidential Space components\n-----------------------------\n\nA Confidential Space system has three core components:\n\n- **A workload** : A containerized image containing code that processes the\n protected resources. This is run on top of a\n [Confidential Space image](/confidential-computing/confidential-space/docs/confidential-space-images), a\n hardened OS based on\n [Container-Optimized OS](/container-optimized-os/docs/concepts/features-and-benefits).\n This in turn runs on a [Confidential VM](/confidential-computing/confidential-vm/docs), a cloud-based TEE\n that offers hardware isolation and remote attestation capabilities. The\n workload is typically located in a separate project from the protected\n resources.\n\n- **The attestation service** : A remote attestation verifier that returns\n attestation evidence in the form of\n [OpenID Connect](https://developers.google.com/identity/protocols/oauth2/openid-connect)\n (OIDC) tokens. The tokens contain identification attributes for the workload.\n The attestation service runs in the same region that the workload is running\n in.\n\n- **Protected resources**: Managed resources that are protected by an\n authentication and authorization system. If the resources are in Google Cloud,\n they can be managed cloud resources such as Cloud Key Management Service (Cloud KMS)\n keys or Cloud Storage buckets. If the resources aren't in Google Cloud (for\n example, in an on-premises environment or in another cloud), then they can be\n any resource.\n\nConfidential Space roles\n------------------------\n\nThe components in a Confidential Space system are managed by people with three\ndistinct roles:\n\n- **Data collaborators**: The people or organizations who own the protected\n resources being operated on by the workload. Data collaborators can access\n their own data, set permissions on that data, and depending on the workload's\n output might access results based on that data.\n\n Data collaborators can't access each other's data or modify the workload code.\n\n See\n [Create and grant access to confidential resources](/confidential-computing/confidential-space/docs/create-grant-access-confidential-resources)\n to learn more about the role of data collaborators.\n- **Workload author** : The person who creates the application that accesses and\n processes the confidential data. They add the application to a containerized\n image, for example, using [Docker](https://www.docker.com/), and upload the\n image to a repository such as [Artifact Registry](/artifact-registry/docs).\n\n The workload author has no access to the data or the results, and can't\n control access to them either.\n\n See\n [Create and customize workloads](/confidential-computing/confidential-space/docs/create-customize-workloads)\n to learn more about the workload author's role.\n- **Workload operator**: The person who runs the workload. The workload operator\n typically has full administrative privileges on the project they run the\n workload in. For example, they can manage resources in their project (such as\n Compute Engine instances, disks, and networking rules) and can interact with any\n Google Cloud API that acts on them.\n\n The workload operator has no access to the data, and can't control access to\n it either. They can't influence or modify the workload code or execution\n environment.\n\n See [Deploy workloads](/confidential-computing/confidential-space/docs/deploy-workloads) to learn more\n about the workload operator's role.\n\nA person can assume one or more of these roles. For the highest security,\nConfidential Space supports a trust model where data collaborators, workload\nauthors, and workload operators are separate, mutually distrusting parties. All\nroles must collaborate with each other to get the results they need.\n\nAn example Confidential Space flow\n----------------------------------\n\nConfidential Space makes use of multiple Google Cloud services to help private\ninformation be operated on confidentially. In general, setting up a\nConfidential Space might look similar to the following process:\n\n1. Multiple data collaborators store encrypted confidential data in their own\n isolated Google Cloud projects, often in different organizations. They want\n to compare and process that data without revealing it to each other or\n external parties. The encrypted data might live in\n [Cloud Storage](/storage/docs),\n [BigQuery](/bigquery/docs), or another service.\n\n2. The data collaborators create mock, non-confidential data for a test\n workload to operate on. This data might be different files, or live in a\n different place like a separate Cloud Storage bucket.\n\n3. The data collaborators create a\n [workload identity pool](/iam/docs/workload-identity-federation) (WIP).\n Later, a workload running in a workload operator's separate, isolated\n project can use that WIP to access the collaborators' confidential data.\n\n4. The workload author writes code to process the confidential data. In a\n project separate from the data collaborators and workload operator, they\n build a containerized image with Docker and upload it to\n [Artifact Registry](/artifact-registry).\n\n5. The workload operator creates a service account in an isolated project that\n has read access to where the data collaborators' encrypted confidential data\n is stored, and write access to somewhere (for example, a\n Cloud Storage bucket) to output the result of operating on the\n decrypted data. Later, this service account is attached to a Confidential VM\n which runs the workload.\n\n6. The data collaborators add a\n [provider](/iam/docs/workload-identity-federation#providers) to their\n workload identity pools. They add details to the provider like the\n attestation service that must be used,\n [attribute mappings](/iam/docs/workforce-identity-federation#attribute-mappings)\n to create an audit trail in logs, and\n [attribute conditions](/iam/docs/workload-identity-federation#conditions).\n These details verify the\n [assertions](/confidential-computing/confidential-space/docs/reference/attestation-assertions) made by\n the Confidential Space image, the workload container, and the workload VM\n instance. If the workload passes this verification, it's allowed to access\n and decrypt the confidential data.\n\n7. The workload is tested on the non-confidential data by starting a\n Confidential VM instance in the workload operator's project. The VM is based on\n a debug version of the Confidential Space image which loads the containerized\n workload.\n\n After the VM's attestations are verified and the workload passes the data\n collaborators' conditions, the service account attached to the VM is allowed\n to access the confidential data, process it, and output a result.\n8. After [monitoring and debugging](/confidential-computing/confidential-space/docs/monitor-debug) is\n complete, the workload is updated for production use. The data collaborators\n update and lock down their workload identity providers further if required,\n and they might choose to test the production workload on non-confidential\n data first.\n\n9. All parties sign off on the production workload, and it's ready to begin\n working on confidential data.\n\nRequirements\n------------\n\nConfidential Space requires Confidential VM to work. Confidential VM instances must use\nAMD SEV, Intel TDX, or Intel TDX with NVIDIA Confidential Computing ([Preview](/products#product-launch-stages)) as the\nConfidential Computing technology. See\n[Supported configurations](/confidential-computing/confidential-vm/docs/supported-configurations) to learn\nabout hardware configuration options, and what locations Confidential VM instances\ncan be created in.\n\nWhat's next\n-----------\n\n- Learn more about\n [Confidential Space images](/confidential-computing/confidential-space/docs/confidential-space-images).\n\n- [Create your first Confidential Space environment](/confidential-computing/confidential-space/docs/create-your-first-confidential-space-environment)."]]
