Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O Confidential Space oferece um ambiente isolado para operar dados sensíveis
de várias partes, para que os proprietários possam manter a confidencialidade.
Esses dados podem incluir informações de identificação pessoal (PII),
informações protegidas de saúde (PHI), propriedade intelectual, secrets
criptográficos, modelos de aprendizado de máquina (ML) ou outros.
Você pode usar o Confidential Space para operar dados sensíveis que só ficam visíveis
para os proprietários originais e uma carga de trabalho mutuamente acordada. Outra opção é usar o Confidential Space para oferecer aos clientes finais uma privacidade de dados mais forte, já que o operador ou proprietário de um ambiente do Confidential Space não pode acessar os dados que estão sendo tratados.
O Confidential Space usa um ambiente de execução confiável (TEE) que pode ser usado para
liberar seus secrets somente para cargas de trabalho autorizadas. Um processo de atestado e uma imagem do SO reforçada ajudam a proteger a carga de trabalho e os dados que ela processa vindos de um operador.
Um sistema de Confidential Space tem três componentes principais:
Uma carga de trabalho: uma imagem conteinerizada que contém código para processar os
recursos protegidos. Ele é executado sobre uma
imagem do Confidential Space, um
SO reforçado baseado no
Container-Optimized OS.
Isso, por sua vez, é executado em uma VM confidencial, um TEE baseado na nuvem
que oferece isolamento de hardware e recursos de atestado remoto. A carga de trabalho geralmente está localizada em um projeto separado dos recursos protegidos.
O serviço de atestado: um verificador de atestado remoto que retorna evidências de atestado na forma de tokens do OpenID Connect (OIDC). Os tokens contêm atributos de identificação para a carga de trabalho.
O serviço de atestado é executado na mesma região em que a carga de trabalho está sendo executada.
Recursos protegidos: recursos gerenciados protegidos por um sistema de autenticação e autorização. Se os recursos estiverem em Google Cloud,
eles poderão ser recursos de nuvem gerenciados, como chaves do Cloud Key Management Service (Cloud KMS)
ou buckets do Cloud Storage. Se os recursos não estiverem em Google Cloud (por exemplo, em um ambiente local ou em outra nuvem), eles poderão ser qualquer recurso.
Funções do Confidential Space
Os componentes de um sistema do Confidential Space são gerenciados por pessoas com três funções distintas:
Colaboradores de dados: as pessoas ou organizações proprietárias dos recursos
protegidos que estão sendo operados pela carga de trabalho. Os colaboradores de dados podem acessar os próprios dados, definir permissões neles e, dependendo da saída da carga de trabalho, acessar resultados com base nesses dados.
Os colaboradores de dados não podem acessar os dados uns dos outros nem modificar o código da carga de trabalho.
Autor da carga de trabalho: a pessoa que cria o aplicativo que acessa e
processa os dados confidenciais. Eles adicionam o aplicativo a uma imagem
em contêineres, por exemplo, usando o Docker, e fazem upload da
imagem para um repositório como o Artifact Registry.
O autor da carga de trabalho não tem acesso aos dados ou aos resultados e não pode controlar o acesso a eles.
Operador de carga de trabalho: a pessoa que executa a carga de trabalho. O operador de carga de trabalho normalmente tem privilégios administrativos totais no projeto em que executa a carga de trabalho. Por exemplo, eles podem gerenciar recursos no projeto (como instâncias do Compute Engine, discos e regras de rede) e interagir com qualquer APIGoogle Cloud que funcione neles.
O operador de carga de trabalho não tem acesso aos dados e não pode controlar o acesso a eles. Ele não pode influenciar ou modificar o código da carga de trabalho ou o ambiente
de execução.
Uma pessoa pode assumir uma ou mais dessas funções. Para a máxima segurança, o Confidential Space é compatível com um modelo de confiança em que os colaboradores de dados, os autores de carga de trabalho e os operadores de carga de trabalho são partes separadas e mutuamente não confiáveis. Todas as funções precisam colaborar entre si para conseguir os resultados necessários.
Exemplo de fluxo do Confidential Space
O Confidential Space usa vários serviços do Google Cloud para ajudar a operar informações particulares de maneira confidencial. Em geral, a configuração de um
Confidential Space pode ser semelhante ao processo a seguir:
Vários colaboradores de dados armazenam dados confidenciais criptografados em projetos isolados Google Cloud próprios, geralmente em organizações diferentes. Eles querem comparar e processar esses dados sem revelá-los uns aos outros ou a terceiros. Os dados criptografados podem estar no Cloud Storage, no BigQuery ou em outro serviço.
Os colaboradores de dados criam dados simulados e não confidenciais para uma carga de trabalho de teste operar. Esses dados podem ser arquivos diferentes ou estar em um lugar diferente, como um bucket separado do Cloud Storage.
Os colaboradores de dados criam um
pool de identidade da carga de trabalho (WIP).
Mais tarde, uma carga de trabalho em execução em um projeto separado e isolado do operador de carga de trabalho poderá usar esse WIP para acessar os dados confidenciais dos colaboradores.
O autor da carga de trabalho escreve o código para processar os dados confidenciais. Em um projeto separado dos colaboradores de dados e do operador de carga de trabalho, eles criam uma imagem em contêineres com o Docker e fazem upload dela para o Artifact Registry.
O operador de carga de trabalho cria uma conta de serviço em um projeto isolado que
tem acesso de leitura ao local onde os dados confidenciais criptografados dos colaboradores de dados
são armazenados e acesso de gravação a algum lugar (por exemplo, um
bucket do Cloud Storage) para gerar o resultado da operação nos
dados descriptografados. Mais tarde, essa conta de serviço será anexada a uma VM confidencial
que executa a carga de trabalho.
Os colaboradores de dados adicionam um provedor aos pools de identidades de carga de trabalho. Eles adicionam detalhes ao provedor, como o serviço de
atestado que precisa ser usado, mapeamentos de atributos
para criar um rastreamento de auditoria em registros e
condições de atributos.
Esses detalhes verificam as
asserções feitas pela
imagem do Confidential Space, o contêiner de carga de trabalho e a instância de VM de carga de trabalho. Se a carga de trabalho passar nessa verificação, ela poderá acessar
e descriptografar os dados confidenciais.
A carga de trabalho é testada nos dados não confidenciais iniciando uma instância de VM confidencial no projeto do operador da carga de trabalho. A VM é baseada em
uma versão de depuração da imagem do Confidential Space que carrega a carga de trabalho
em contêineres.
Depois que os atestados da VM são verificados e a carga de trabalho atende às condições dos colaboradores de dados, a conta de serviço anexada à VM pode acessar e processar os dados confidenciais e gerar um resultado.
Depois que o monitoramento e a depuração forem
concluídos, a carga de trabalho será atualizada para uso em produção. Os colaboradores de dados atualizam e bloqueiam ainda mais os provedores de identidade da carga de trabalho, se necessário, e podem optar por testar a carga de trabalho de produção primeiro em dados não confidenciais.
Todas as partes assinam a carga de trabalho de produção, e ela está pronta para começar
a trabalhar com dados confidenciais.
Requisitos
O Confidential Space exige o uso da VM confidencial para funcionar. As instâncias de VM confidenciais precisam usar AMD SEV, Intel TDX ou Intel TDX com NVIDIA Confidential Computing (Prévia) como tecnologia de Computação confidencial. Consulte
Configurações compatíveis para saber
mais sobre as opções de configuração de hardware e em quais locais as instâncias de VM confidencial
podem ser criadas.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)."]]
