A ferramenta de encriptação de confiança dividida (STET) permite a transferência segura de dados de chaves para dentro e para fora do Google Cloud de uma forma verificável e criptograficamente protegida contra Google Cloud utilizadores internos.
Isto é conseguido através da utilização de dois sistemas de gestão de chaves (KMS), um interno aoGoogle Cloude outro externo. Mesmo que um KMS seja comprometido, o segundo está em vigor para ajudar a manter os seus dados privados.
Seguem-se uma série de exemplos que envolvem dados transmitidos para o Cloud Storage e calculados através de VMs do Compute Engine. Os exemplos explicam os níveis de segurança crescentes para ajudar a explicar como a STET se enquadra no seu fluxo de segurança.
Nível 1: Cloud Storage
Quando carrega dados para o Google Cloud, pode usar o Cloud Storage para disponibilizar os dados aos seus fluxos de trabalho na nuvem. Pode carregar os dados dos seus ambientes de computação no local para um contentor do Cloud Storage, conceder à sua carga de trabalho acesso a esse contentor e fazer com que a carga de trabalho (ou várias cargas de trabalho) consuma esses dados quando necessário. Esta estratégia evita a complexidade de criar uma ligação ativa diretamente à carga de trabalho para lhe enviar os dados de que precisa.
O Cloud Storage encripta sempre os seus dados em repouso. No entanto, se estiver a confiar no Cloud Storage para fazer essa encriptação por si, tem acesso aos dados não encriptados (texto simples) antes da encriptação, bem como às chaves de encriptação usadas para criar os dados encriptados (texto cifrado). Consoante o seu modelo de ameaças, pode ser desejável encriptar os dados antes de os enviar para o Cloud Storage, para que o Cloud Storage nunca tenha visibilidade do texto não cifrado.
Nível 2: encriptação por parte do cliente
Quando usa a encriptação por parte do cliente, encripta os dados antes de serem carregados para o Cloud Storage e só os desencripta depois de serem transferidos para a sua carga de trabalho. Como resultado, o Cloud Storage tem acesso ao texto cifrado, mas não ao texto simples. O Cloud Storage adiciona outra camada de encriptação antes de o armazenar, mas a proteção principal dos dados é a encriptação realizada antes do carregamento.
Com esta abordagem, agora tem de conceder à carga de trabalho acesso à chave de encriptação necessária para desencriptar os dados. Esta é, por si só, uma tarefa potencialmente difícil, uma vez que a chave de encriptação concede a capacidade de remover a sua camada original de encriptação e obter visibilidade dos dados.
Nível 3: gestão de chaves externas
Uma abordagem comum a este problema de gestão de chaves é usar um serviço de gestão de chaves (KMS) dedicado que contém as chaves e gere o acesso às mesmas. Em cada tentativa de encriptação ou desencriptação, tem de ser enviada uma solicitação para o KMS. O KMS tem a capacidade de conceder acesso com base em vários critérios para garantir que apenas as partes adequadas conseguem desencriptar os dados.
Os sistemas KMS têm a capacidade de exigir vários critérios diferentes antes de autorizar o acesso à chave de encriptação, mas normalmente exigem uma credencial que corresponda a uma política configurada no KMS. Por conseguinte, qualquer parte na posse dessa credencial vai poder aceder à chave de encriptação e desencriptar os dados.
Nível 4: computação confidencial
As instâncias de VM confidencial são executadas com a respetiva memória encriptada, o que oferece proteções adicionais contra o acesso não intencional aos dados durante a utilização. Para muitos modelos de ameaças, as instâncias de Confidential VM são mais fidedignas do que as instâncias padrão, o que permite a sua utilização para cargas de trabalho confidenciais.
Se o seu modelo de ameaças depender da computação confidencial, um problema é garantir que uma carga de trabalho está a ser executada numa instância de VM confidencial. A atestação remota é um meio através do qual a carga de trabalho pode provar a uma parte remota que está a ser executada numa instância de VM confidencial e pode confirmar muitas outras propriedades sobre a configuração e o ambiente da carga de trabalho. Uma vez que as atestações são geradas pela plataforma, a carga de trabalho não pode criar atestações falsas que não reflitam o respetivo ambiente real.
Um KMS pode exigir e avaliar estas atestações antes de permitir o acesso às chaves. Este requisito ajuda a garantir que apenas a carga de trabalho pretendida tem autorização para desencriptar os dados, mesmo que as credenciais normais sejam comprometidas.
Nível 5: confiança dividida
Quando usa um único KMS, esse KMS tem o controlo exclusivo sobre as chaves de encriptação. Se o operador do KMS adquirisse o texto cifrado dos seus dados encriptados, teria tudo o que é necessário para o desencriptar no seu texto simples. Embora este risco possa ser aceitável se o KMS for operado por uma entidade totalmente fidedigna, alguns modelos de ameaças criam a necessidade de remover o controlo unilateral do KMS.
Com a STET, tem a opção de dividir esta confiança entre dois sistemas KMS, sendo que nenhum dos KMS tem informações suficientes para desencriptar os seus dados. Exigiria a conivência entre os operadores do KMS (e o acesso ao texto cifrado) para descifrar os seus dados.
Se estiver a usar a VM confidencial, o STET também facilita a encriptação e a desencriptação de dados através de chaves armazenadas num KMS que requer atestações.
Em conjunto, a STET ajuda a garantir que as únicas entidades que têm acesso aos seus dados de texto simples são o originador dos dados (por exemplo, um sistema no local) e o consumidor dos dados (por exemplo, uma carga de trabalho em execução numa instância de VM confidencial).
Para mais informações sobre a utilização do STET, consulte o repositório do GitHub e o guia de início rápido.
Espaço confidencial com STET
Se usar o Confidential Space, o STET pode usar o token de atestação do Confidential Space como prova de atestação ao aceder à chave de encriptação de chaves (KEK) armazenada no Cloud KMS.
O STET processa o acesso às chaves do Cloud KMS para a sua carga de trabalho e suporta a utilização do espaço confidencial para realizar a atestação para o fluxo de trabalho de encriptação, o fluxo de trabalho de desencriptação ou ambos os fluxos de trabalho de encriptação e desencriptação.
Pode criar uma configuração STET que inclua informações como o nome do Workload Identity Pool (WIP), os URIs do Cloud KMS e as informações de desencriptação. Em seguida, o STET usa essas informações para integrar na sua configuração do Confidential Space.
Para mais informações, consulte o repositório do GitHub e o guia de integração do Confidential Space.