Vista geral da segurança do Confidential Space

Este documento descreve os controlos de segurança do Confidential Space e como o sistema foi concebido para mitigar uma vasta gama de ameaças. O espaço confidencial foi concebido para permitir que as partes partilhem dados confidenciais (por exemplo, dados regulamentados ou informações de identificação pessoal [IIP]) com uma carga de trabalho, mantendo a confidencialidade e a propriedade dos dados. O espaço confidencial ajuda a criar isolamento para que os dados só sejam visíveis para a carga de trabalho e os proprietários originais dos dados.

Pode usar o espaço confidencial para cenários em que não pode estabelecer confiança com o operador da carga de trabalho ou entre as partes originais que criaram os dados confidenciais. Por exemplo, as instituições financeiras podem usar o Confidential Space para colaborar entre si na identificação de fraude ou na análise de atividades de branqueamento de capitais. O espaço confidencial permite a análise em conjuntos de dados de clientes, mantendo as identidades dos clientes privadas.

Componentes de um sistema de espaço confidencial

O Confidential Space usa um ambiente de execução fiável (AEF) concebido para divulgar segredos apenas a cargas de trabalho autorizadas. Um processo de atestação e uma imagem do SO reforçada ajudam a proteger a carga de trabalho e os dados que a carga de trabalho processa de um operador não fidedigno.

Um sistema do espaço confidencial tem três componentes principais:

• Uma carga de trabalho: uma imagem contentorizada com um SO reforçado que é executada num AEE baseado na nuvem. Usa a computação confidencial como o AEF que oferece capacidades de isolamento de hardware e atestação remota.
• Atestado do Google Cloud: um fornecedor de tokens OpenID Connect (OIDC). Utiliza este serviço para validar as citações de atestação para o AAE e emitir tokens de autenticação. Os tokens contêm atributos de identificação para a carga de trabalho.
• Um recurso protegido: um recurso na nuvem gerido, como uma chave do Cloud Key Management Service ou um contentor do Cloud Storage. O recurso está protegido por uma política de permissão que concede acesso a tokens de identidade federada autorizados. Um passo intermédio, que usa Workload Identity Pools, transforma os tokens OIDC em tokens de identidade federada que o IAM pode consumir.

O sistema ajuda a garantir que o acesso aos recursos protegidos é concedido apenas a cargas de trabalho autorizadas. Além disso, o espaço confidencial ajuda a proteger a carga de trabalho contra inspeção e adulteração, antes e depois da atestação.

Num sistema de espaço confidencial, existem três partes:

• O autor da carga de trabalho, que cria uma imagem contentorizada que inclui uma aplicação com acesso aos recursos protegidos. O autor não tem acesso aos dados nem aos resultados. Além disso, o autor não controla o acesso aos dados nem aos resultados.
• O operador da carga de trabalho, que executa a carga de trabalho num Google Cloud projeto. Normalmente, o operador tem privilégios administrativos totais para o projeto. O operador pode gerir recursos, como instâncias, discos e regras de rede do Compute Engine, e pode interagir com qualquer API que atue sobre eles. Google Cloud Google Cloud O operador não tem acesso aos dados nem aos resultados e não pode influenciar nem modificar o código nem o ambiente de execução. Além disso, o operador não controla o acesso aos dados nem aos resultados.
• Os proprietários dos recursos (ou colaboradores de dados), que são proprietários do recurso protegido. Um proprietário de recursos pode aceder aos seus próprios dados, definir autorizações nos seus próprios dados e aceder aos resultados. Não podem aceder aos dados de outros proprietários de recursos nem modificar o código por si próprios.

O Confidential Space suporta um modelo de confiança em que o autor da carga de trabalho, o operador da carga de trabalho e os proprietários dos recursos são entidades separadas que não confiam umas nas outras.

O diagrama seguinte mostra os componentes e as partes do sistema. A carga de trabalho está localizada num projeto separado do recurso protegido.

Exemplos de tratamento de dados seguro

O espaço confidencial ajuda a preservar a privacidade de um utilizador enquanto partilha dados. A tabela seguinte descreve três exemplos de utilização.

Exemplo de utilização	Cenário de exemplo
Modelo de encriptação funcional	Num modelo de encriptação funcional, a Alice quer partilhar o resultado dos seus dados confidenciais com o Bob, sem revelar o conjunto de dados completo. A Alice encripta o respetivo conjunto de dados e protege a chave de encriptação de dados (DEK) no Cloud KMS no respetivo projeto. A Alice escreve um programa que implementa a carga de trabalho e partilha o ficheiro binário com o Bob. A Alice configura o KMS para dar ao programa acesso à DEK. A carga de trabalho é executada no espaço confidencial de Bob, desencripta e processa o conjunto de dados de Alice e escreve o resultado no Cloud Storage de Bob.
Computação multipartidária	Na computação multipartidária, a Alice e o Bob querem partilhar o resultado entre si, preservando a confidencialidade dos conjuntos de dados de entrada. Semelhante ao modelo de encriptação funcional, a Alice e o Bob encriptam os respetivos conjuntos de dados e protegem as DEKs nas instâncias do Cloud KMS nos respetivos projetos. Estes criam em conjunto um programa que determina os resultados e executam-no num espaço confidencial. A Alice e o Rui configuram o KMS para dar ao programa acesso às DEKs. O programa lê e processa ambos os conjuntos de dados e escreve o resultado num contentor do Cloud Storage partilhado.
Partilhas principais	Um esquema mais complexo usa a ideia de ações principais. Uma partilha de chave é uma chave privada dividida entre a Alice, o Bob e outros proprietários, de modo que o conhecimento das partilhas individuais não dá acesso ao conjunto de dados encriptado. Neste esquema, a confiança é dividida por vários proprietários. A chave privada é montada apenas num AEF restrito por uma carga de trabalho autorizada.

Nestes exemplos, apenas a carga de trabalho tem acesso ao conjunto de dados encriptado e pode processá-lo. O Confidential Space ajuda a garantir que ninguém pode realizar operações não auditadas em dados que não lhe pertencem. Os proprietários dos dados controlam a forma como os respetivos dados são usados e que cargas de trabalho estão autorizadas a agir sobre eles.

Proteger a integridade e a confidencialidade de uma carga de trabalho

Para ajudar a proteger a carga de trabalho de um operador de carga de trabalho não fidedigno, o espaço confidencial implementa os seguintes controlos de segurança:

• Um processo de atestação deteta modificações na imagem da carga de trabalho ou no respetivo AEF. Este controlo ajuda a proteger a integridade da carga de trabalho antes da atestação.
• Uma imagem base reforçada ajuda a reduzir a superfície de ataque e a impedir que o operador da carga de trabalho aceda ou comprometa a instância em tempo de execução. Este controlo ajuda a proteger a integridade e a confidencialidade de uma carga de trabalho após a atestação. Em conjunto, estes controlos de segurança ajudam a proteger a carga de trabalho, os respetivos segredos e os dados que processa.

Processo de atestação

O processo de atestação baseia-se no arranque medido e nas medições de tempo de execução alargadas da VM protegida. Este processo captura as medições da sequência de arranque num registo protegido e apenas de extensão no dispositivo do Módulo de plataforma fidedigna (TPM) virtual.

As medições abrangem os componentes de arranque antecipado, o kernel carregado e a imagem do contentor. Além disso, incluem propriedades do ambiente, como uma flag que indica que a instância é uma Confidential VM. O vTPM assina (ou cita) estas medições através de uma chave de atestação certificada que é fidedigna para a Atestação do Google Cloud.

O diagrama seguinte mostra os componentes de um sistema do Confidential Space e como cada componente participa no processo de atestação.

O processo de atestação depende dos seguintes componentes:

• Firmware do convidado: um componente imutável que é uma parte fidedigna do Google Cloud.
• Imagem do Confidential Space atestada: uma imagem reforçada baseada no SO otimizado para contentores que é lida a partir do disco de arranque anexado.
• Componentes de arranque antecipado: carregadores de arranque e kernels que interagem com o vTPM para medir os componentes de arranque num registo de configuração da plataforma (PCR).

• Launcher: um componente que transfere o binário da carga de trabalho do repositório de imagens e mede o contentor e a respetiva configuração num PCR. O Launcher lê a respetiva configuração a partir do servidor de metadados da instância.

• Código de processamento da atestação: código responsável por preparar uma cotação de PCR, e devolver a cotação, a chave de atestação e o registo de eventos completo do vTPM.

• Atestado do Google Cloud: um serviço que valida a cotação, repete o registo de eventos, emite o token OIDC e devolve o token com os atributos da política de acesso à carga de trabalho.

Imagem protegida

A imagem do espaço confidencial é um SO minimalista de finalidade única. A imagem executa o iniciador de contentores, que, por sua vez, inicia um único contentor. A imagem do espaço confidencial baseia-se nas melhorias de segurança existentes do SO otimizado para contentores e adiciona as seguintes vantagens:

• Partições de disco encriptadas com proteção de integridade: a imagem do espaço confidencial inclui as seguintes partições:
  • Uma partição root-fs e uma partição do OEM que inclui o ficheiro binário do launcher. Estas partições são imutáveis e estão protegidas por dm-verity.
  • Uma partição gravável temporária que armazena o binário da carga de trabalho transferida. dm-crypt encripta esta partição e protege a respetiva integridade.
  • Uma partição tmp-fs que é mapeada para a RAM. Num TEE de VM confidencial, a memória da VM é encriptada. Além disso, o sistema swap-fs está desativado, o que ajuda a impedir que um sistema operativo mal configurado armazene dados no disco.
• Ligações de rede autenticadas e encriptadas: o Launcher usa o TLS para autenticar a atestação do Google Cloud e proteger os respetivos links de comunicação.
• Várias medições de arranque: estas medições incluem argumentos da linha de comandos do kernel, configuração dm-verity para root-fs e o binário da carga de trabalho.

• Acesso remoto e ferramentas específicas da nuvem desativados: estas ferramentas incluem o sshd e o início de sessão do SO.

• Transições de estado reduzidas: por exemplo, o Launcher executa um único contentor e, em seguida, termina.

Modelo de ameaças e mitigações

Esta secção descreve os modelos de ameaças que o Confidential Space ajuda a mitigar e os novos riscos introduzidos pelo Confidential Space.

Os seguintes ataques estão fora do âmbito deste documento:

• Ataques à cadeia de fornecimento de software que se aplicam ao firmware da interface de firmware extensível unificada (UEFI) convidada, ao carregador de arranque e ao kernel da imagem do espaço confidencial, ao tempo de execução do contentor e às dependências de terceiros para a carga de trabalho. Os colaboradores de dados partem do princípio de que os proprietários dos recursos reviram e auditaram a imagem do contentor antes de partilharem o respetivo recurso com uma política de autorização.
• Ataques a Google Cloud, como fugas de VMs.

Possíveis ataques

O Confidential Space foi concebido para se defender contra três possíveis ataques:

• Um operador de carga de trabalho malicioso: um operador de carga de trabalho malicioso pode modificar o conteúdo do disco, intercetar ligações de rede e tentar comprometer o AAE em tempo de execução. Um operador malicioso pode expandir a superfície de ataque ou restringir o ambiente de tempo de execução. Por exemplo, um operador malicioso pode adicionar uma consola de série para introduzir novos vetores de ataque. Por exemplo, um operador malicioso pode restringir recursos, como limitar o tamanho da memória de um convidado, alterar o respetivo espaço em disco ou alterar as regras da firewall. Estas restrições podem acionar erros de E/S que podem levar a casos de erro mal testados.
• Um cliente de atestação malicioso: este atacante liga-se à atestação do Google Cloud e envia mensagens de registo de eventos com erros, mas assinadas.
• Um proprietário de recursos malicioso: um proprietário de recursos malicioso tem controlo total sobre o conjunto de dados encriptado que a carga de trabalho consome. Este atacante pode apresentar entradas com erros de formatação ou dados distorcidos e tentar acionar vulnerabilidades de análise na carga de trabalho ou tentar contornar os respetivos controlos de privacidade.

Vetores de ataque

A tabela seguinte descreve as superfícies de ataque disponíveis para os atacantes.

Atacante	Destino	Vetores de ataque	Riscos
Operador de cargas de trabalho	AEF, carga de trabalho	Leituras do disco	Tudo o que é lido a partir do disco está sob o controlo do atacante. Os serviços, como os discos persistentes de vários escritores e as anexações dinâmicas de discos, significam que um atacante pode modificar o conteúdo dos discos de forma dinâmica e à vontade.
Operador de cargas de trabalho	AEF, carga de trabalho	Escritas no disco	Tudo o que for escrito no disco é visível para um atacante. Consulte as capacidades de instantâneos de disco e de importação.
Operador de cargas de trabalho	AEF, carga de trabalho	Servidor de metadados	Os atributos da instância lidos a partir do servidor de metadados estão sob o controlo do atacante, incluindo o script de arranque e as variáveis de ambiente.
Operador de cargas de trabalho	AEF, carga de trabalho	Rede	As ligações de rede externas ao repositório de imagens ou à atestação do Google Cloud podem ser intercetadas. Este ataque é realizado através de uma VPC privada com uma instância do Cloud Router orientada para o público.
Cliente de atestação	Atestação do Google Cloud	Registo de eventos e mensagens de atestação	A atestação do Google Cloud tem uma lógica complexa e com muita criptografia que é difícil de escrever de forma defensiva.
Proprietário do recurso	Carga de trabalho	Conjunto de dados encriptado	Um atacante pode contaminar os conjuntos de dados de entrada da carga de trabalho, o que significa que os dados encriptados não são necessariamente dados fidedignos.

Google Cloud infraestrutura

Google Cloud Inclui o hipervisor do Compute Engine, o vTPM para a VM confidencial, o firmware UEFI convidado e uma instância de atestação do Google Cloud alojada. O material de chaves sensível, como as chaves de assinatura vTPM e OIDC, foi concebido para ser protegido em segurança.

A infraestrutura da Google foi concebida para isolar logicamente os dados de cada cliente dos dados de outros clientes e utilizadores, mesmo quando são armazenados no mesmo servidor físico. O acesso administrativo para o pessoal de apoio técnico e os engenheiros é limitado, auditado e transparente para os clientes. Além disso, a encriptação de memória inline nas VMs confidenciais ajuda a proteger a confidencialidade da memória da instância. A encriptação de memória inline torna a inspeção direta ou o registo acidental de memória (registo de falhas do kernel) ineficaz. Para mais informações sobre como protegemos a nossa plataforma, consulte a vista geral da segurança da Google.

Ameaças e mitigações

Um sistema de ficheiros encriptado com proteção da integridade foi concebido para mitigar os riscos de ataques ao disco. Além disso, depois de o código ser lido a partir do disco, é medido e esses dados nunca mais são lidos a partir do disco. Os segredos nunca são divulgados em formato de texto simples no disco nem em nenhum dispositivo externo, como uma consola serial.

Os riscos de ataques à rede são mitigados através de canais encriptados ponto a ponto autenticados. O acesso à rede externa, como SSH, está desativado na imagem. Um protocolo de atestação ajuda a proteger a sequência de arranque e qualquer configuração lida a partir do servidor de metadados. Por último, espera-se que as cargas de trabalho do espaço confidencial usem controlos de privacidade diferencial para mitigar os riscos de conjuntos de dados enviesados.

As tabelas seguintes descrevem as ameaças e as mitigações:

• Ataques ao processo de inicialização medida

• Ataques ao iniciador de contentores

• Ataques à atestação do Google Cloud

• Ataques a cargas de trabalho

Ataques ao processo de inicialização medida

Esta tabela descreve potenciais ameaças e estratégias de mitigação relacionadas com o processo de arranque medido.

Ameaça	Mitigação	Implementação da mitigação
Um atacante arranca uma VM protegida com firmware antigo que não suporta o arranque medido. Se tiver êxito, um atacante pode reproduzir medições arbitrárias e derrotar a atestação remota.	Esta ameaça é mitigada pelo plano de controlo Google Cloud . O espaço confidencial adiciona um dispositivo vTPM e firmware UEFI atualizado. Além disso, o espaço confidencial ativa o arranque medido, e não é possível desativar o arranque medido.	Dentro da Google Cloud infraestrutura
Um atacante substitui o firmware UEFI na memória física do convidado, reinicia o convidado, o que repõe os registos do vTPM, e executa firmware modificado. Se tiver êxito, um atacante pode reproduzir medições arbitrárias e derrotar a atestação remota.	Esta ameaça é mitigada pelo hipervisor. No reinício do convidado, o hipervisor carrega uma cópia limpa do firmware UEFI para a memória do convidado. As modificações anteriores na memória do convidado são rejeitadas. Além disso, o reinício do SO convidado é o único evento que repõe o vTPM.	Dentro do Google Cloud e através da ativação da computação confidencial
Um atacante modifica ficheiros de configuração não medidos, o que afeta negativamente a execução do programa.	Esta ameaça é mitigada pelo processo de atestação. Todos os binários executáveis e os respetivos ficheiros de configuração são totalmente medidos antes da execução. Em particular, são medidas as variáveis de arranque seguro, a configuração do GRUB e os argumentos da linha de comandos do kernel. A revisão de segurança determinou que não foram perdidas medições no processo de atestação.	Na imagem do espaço confidencial
Um atacante aciona vulnerabilidades de danos na memória nos componentes de arranque antecipado e obtém a execução de código.	Os componentes de arranque antecipado são escritos na linguagem C. Estes componentes processam dados de utilizadores não fidedignos e podem ser vulneráveis a problemas de corrupção de memória. Para ver um exemplo recente, consulte BootHole. Este risco é mitigado pelo processo de atestação: os componentes de arranque antecipado têm de medir todos os dados controlados pelo utilizador antes de os processarem. Um ataque BootHole usa um grub.cfg modificado para obter a execução de código e derrotar o arranque seguro. No entanto, num sistema de espaço confidencial, esse ataque não passa na atestação, uma vez que as medições grub.cfg não correspondem à configuração esperada. Um risco relacionado advém da lógica complexa do sistema de ficheiros. As vulnerabilidades anteriores, como a Sequoia, demonstram que os controladores do sistema de ficheiros processam estruturas de dados complexas e podem ser vulneráveis a problemas de corrupção de memória. Este risco é mitigado através da proteção da integridade ao nível do bloco dm-verity e dm-crypt, e desativando as montagens automáticas.	Na imagem do espaço confidencial
Um atacante modifica os binários de arranque antecipado no disco depois de serem lidos e medidos, antes de serem lidos e executados (TOCTOU do disco).	Os componentes de arranque inicial foram criados para máquinas sem sistema operativo e podem não esperar o ambiente dinâmico da nuvem. Os componentes de arranque podem assumir que o conteúdo do disco não pode ser alterado durante a execução, o que é uma suposição incorreta para ambientes de nuvem. Este risco é mitigado através da programação defensiva: o conteúdo do disco é apenas de leitura após a utilização do padrão de leitura, medição e execução. A revisão de segurança da imagem do espaço confidencial não identificou problemas de TOCTOU nos componentes de arranque iniciais como UEFI, Shim ou GNU GRUB.	Na imagem do espaço confidencial
Um atacante modifica os controladores do dispositivo e os serviços do modo de utilizador no disco após o carregamento do kernel.	Esta ameaça é mitigada por um sistema de ficheiros raiz com proteção de integridade. Root-fs na imagem do espaço confidencial está protegido pela integridade do dm-verity. A configuração (root-hash) é transmitida num argumento de comando do kernel e, em seguida, medida e atestada pela Atestação do Google Cloud.	Na imagem do espaço confidencial

Ataques ao iniciador de contentores

Esta tabela descreve potenciais ameaças e estratégias de mitigação relacionadas com o launcher.

Ameaça	Mitigação	Implementação da mitigação
Um atacante interceta a ligação de rede do launcher ou do repositório de imagens.	A ligação ao repositório de imagens está protegida por uma ligação TLS encriptada e autenticada. Um atacante pode alterar o URL da imagem e controlar o ficheiro binário da carga de trabalho. No entanto, estas ações são refletidas no registo de atestação. O repositório de imagens não é controlado através de uma lista de acesso e, por isso, considera-se que a imagem é visível para todos. Tem de garantir que a imagem do contentor da carga de trabalho não contém segredos.	Na imagem do espaço confidencial
Um atacante modifica a imagem da carga de trabalho no disco depois de ter sido transferida e medida.	Esta ameaça é mitigada por uma partição gravável que está encriptada e cuja integridade está protegida. A imagem da carga de trabalho e os respetivos dados temporários são protegidos por dm-crypt através de chaves efémeras por arranque. O processo de encriptação de disco dm-crypt permite ataques de reversão, em que um atacante substitui o conteúdo do disco por textos cifrados e etiquetas vistos anteriormente. Estes ataques são considerados altamente complexos nas definições do espaço confidencial.	Na imagem do espaço confidencial
Um atacante modifica a configuração do iniciador no servidor de metadados e controla o URL do repositório de imagens.	O processo de atestação deteta configurações não seguras que carregam imagens não autênticas.	No Google Cloud Attestation

Ataques à atestação do Google Cloud

Esta tabela descreve potenciais ameaças e estratégias de mitigação para a atestação do Google Cloud.

Ameaça	Mitigação	Implementação da mitigação
Um atacante interceta a ligação de rede do launcher ou da atestação do Google Cloud e lê o token secreto a partir do cabo.	Esta ameaça é mitigada através de uma ligação TLS autenticada e encriptada. Esta ligação ajuda a proteger o token contra escutas passivas. Um atacante não pode roubar a identidade do serviço porque não tem a chave TLS. Mesmo que seja bem-sucedido, o atacante não pode criar tokens OIDC válidos. Um atacante não pode roubar a identidade de um cliente válido porque a identidade do cliente é garantida pelo protocolo de atestação.	Na rede entre a sua carga de trabalho e o serviço de atestação.
Um atacante explora discrepâncias de análise, o que leva a alterações não detetadas no processo de atestação.	Esta ameaça pode ocorrer porque o registo de eventos de medições é serializado e enviado para a atestação do Google Cloud, onde é analisado e processado. Uma discrepância de análise ocorre quando o serviço e o SO de tempo de execução não concordam com a semântica do registo. Por exemplo, se o campo cmdline tiver uma lista de argumentos separados por uma vírgula, uma string como a=1, b=2 c='3,d=e' (tenha em atenção o ,d na substring do valor) pode ser analisada de forma diferente pelo kernel e pelo serviço. Este risco é mitigado através de um motor de análise que reflete corretamente o comportamento do SO. Em particular, o cmdline é processado como uma string completa e não é dividido em pares de chave-valor.	Na imagem do espaço confidencial
Um atacante usa todos os recursos do serviço, o que faz com que o serviço fique indisponível num ataque de negação de serviço (DoS). O serviço é interrompido para outros utilizadores do espaço confidencial.	Este risco de fiabilidade é mitigado através de um serviço distribuído e elástico que pode ser facilmente replicado e expandido conforme necessário. O código impede o esgotamento de recursos por parte de clientes maliciosos.	Dentro da carga de trabalho

Ataques a cargas de trabalho

Esta tabela descreve potenciais ameaças e estratégias de mitigação relacionadas com cargas de trabalho.

Ameaça	Mitigação	Implementação da mitigação
Um atacante lê segredos de tempo de execução da partição gravável.	Esta ameaça é mitigada com um sistema de ficheiros encriptado. O sistema de ficheiros gravável é montado através de dm-crypt. A troca está desativada e o conteúdo da memória não é paginado para o disco. Como técnica de defesa em profundidade, os tokens OIDC têm âmbito e curta duração.	Na imagem do espaço confidencial
Um atacante lê segredos de tempo de execução a partir da consola de série.	Esta ameaça é mitigada na imagem do espaço confidencial porque as credenciais e os tokens nunca são impressos na consola série. Além disso, o registo em nuvem está desativado.	Na imagem do espaço confidencial
Um atacante atualiza as chaves SSH autorizadas através do pacote OSLogin e, em seguida, liga-se à instância em execução.	Esta ameaça é mitigada na imagem do Confidential Space porque os serviços systemd predefinidos estão ocultos, incluindo o sshd.	Na imagem do espaço confidencial
Um atacante atualiza os scripts de arranque no servidor de metadados, que são carregados automaticamente pelo agente convidado.	Esta ameaça é mitigada na imagem do espaço confidencial porque o pacote do agente convidado está desativado.	Na imagem do espaço confidencial
Um atacante envia pacotes incorretos para a VM através do agente de configuração do SO.	Esta ameaça é mitigada na imagem do Confidential Space porque o agente de configuração do SO está desativado.	Na imagem do espaço confidencial
Um atacante transmite um conjunto de dados com formato incorreto e encriptado à carga de trabalho.	Esta ameaça é mitigada através da existência de código de análise defensiva na carga de trabalho.	Dentro da carga de trabalho
Um atacante transmite um conjunto de dados distorcido ou envenenado para a carga de trabalho e tenta aprender informações sobre os conjuntos de dados de outras partes.	Esta ameaça é mitigada através da implementação de controlos de privacidade diferencial na carga de trabalho.	Dentro da carga de trabalho

Testes de segurança

O Confidential Space passou por um processo de revisão de segurança abrangente na Google. Este processo de revisão de segurança incluiu os seguintes testes e auditorias:

• Testes de integração ponto a ponto de fluxo negativo

  Estes testes validaram que a atestação falha em medições incorretas, como quando o código é executado num ambiente de ETE inesperado ou inicia um contentor de carga de trabalho modificado.

• Auditoria manual do processo de inicialização medida

  Esta revisão focou-se na identificação de medições em falta e erros de leitura dupla. Os testes verificaram que o código foi escrito tendo em conta as práticas recomendadas de segurança e, quando ocorreu uma falha, o código foi fechado.

• Auditoria manual do processo de compilação da imagem do espaço confidencial e da lógica do iniciador:

  Esta revisão focou-se na remoção de pacotes e na redução da superfície de ataque.

• Auditoria manual da atestação do Google Cloud

  Esta revisão focou-se na implementação do protocolo de atestação correto e na prevenção de problemas de análise.

• Revisão da criptografia por especialistas em cibersegurança

  Esta revisão focou-se no protocolo de atestação, na encriptação do sistema de ficheiros e nas soluções de integridade.

• Revisão de privacidade por especialistas em privacidade

  Esta crítica focou-se nos controlos de privacidade diferencial em cargas de trabalho criadas pela Google.

• Testes de fuzzing contínuos

  Estes testes abrangeram componentes críticos de segurança, como o vTPM e a atestação do Google Cloud.

A NCC Group, uma organização externa de testes de intrusão, realizou testes de intrusão no sistema. A NCC reviu o Confidential Space como uma plataforma de computação segura.

O que se segue?

• Para começar a usar o Confidential Space, consulte o artigo Analise dados confidenciais com o Confidential Space.

• Para saber mais sobre a proteção de dados em utilização, consulte a secção Computação confidencial.

• Para saber mais sobre a segurança da infraestrutura da Google, consulte a vista geral do design de segurança da infraestrutura da Google.