A ferramenta de criptografia de confiança dividida (STET, na sigla em inglês) oferece um mecanismo de distribuição que permite a transferência segura de dados de chaves para dentro e fora do Google Cloud de uma maneira verificável e criptograficamente protegida contra pessoas com informações privilegiadas do Google Cloud .
Isso é feito usando dois sistemas de gerenciamento de chaves (KMS), um interno ao Google Cloude outro externo. Mesmo que um KMS seja comprometido, o segundo está em vigor para ajudar a manter seus dados particulares.
A seguir, confira uma série de exemplos que envolvem dados transmitidos para o Cloud Storage e calculados usando VMs do Compute Engine. Os exemplos mostram como aumentar os níveis de segurança para explicar como a STET se encaixa no fluxo de segurança.
Nível 1: Cloud Storage
Ao ingerir dados no Google Cloud, é possível usar o Cloud Storage para disponibilizar os dados para suas cargas de trabalho na nuvem. É possível fazer upload dos dados dos seus ambientes de computação locais para um bucket do Cloud Storage, conceder acesso à carga de trabalho a esse bucket e fazer com que a carga de trabalho (ou várias cargas de trabalho) consuma esses dados quando necessário. Essa estratégia evita a complexidade de criar uma conexão ativa diretamente na carga de trabalho para enviar os dados necessários.
O Cloud Storage sempre criptografa os dados em repouso. No entanto, se você estiver confiando ao Cloud Storage essa criptografia, ele terá acesso aos dados não criptografados (texto simples) antes da criptografia, bem como às chaves de criptografia usadas para criar os dados criptografados (texto criptografado). Dependendo do seu modelo de ameaças, pode ser recomendável criptografar os dados antes de enviá-los ao Cloud Storage, para que o Cloud Storage nunca tenha visibilidade do texto simples.
Nível 2: criptografia do lado do cliente
Ao usar a criptografia do cliente, você criptografa os dados antes de enviá-los ao Cloud Storage e só os descriptografa após o download na carga de trabalho. Como resultado, o Cloud Storage tem acesso ao texto criptografado, mas não ao texto simples. O Cloud Storage adiciona outra camada de criptografia antes de armazená-la, mas a proteção principal dos dados é a criptografia realizada antes do upload.
Com essa abordagem, agora você precisa conceder à carga de trabalho acesso à chave de criptografia necessária para descriptografar os dados. Essa tarefa é potencialmente difícil, já que a chave de criptografia permite remover a camada original da criptografia e ganhar visibilidade aos dados.
Nível 3: gerenciamento de chaves externas
Uma abordagem comum para esse problema de gerenciamento de chaves é usar um serviço de gerenciamento de chaves (KMS) dedicado que mantém as chaves e gerencie o acesso a elas. Em cada tentativa de criptografia ou descriptografia, é preciso enviar uma solicitação ao KMS. O KMS pode conceder acesso com base em vários critérios para garantir que apenas as partes apropriadas possam descriptografar os dados.
Os sistemas KMS podem exigir vários critérios diferentes antes de autorizar o acesso à chave de criptografia, mas normalmente exigem uma credencial correspondente a uma política configurada no KMS. Portanto, qualquer parte que tenha essa credencial poderá acessar a chave de criptografia e descriptografar os dados.
Nível 4: computação confidencial
As instâncias de VMs confidenciais são executadas com a memória criptografada, oferecendo proteções adicionais contra acesso não intencional aos dados em uso. Para muitos modelos de ameaça, as instâncias de VM confidenciais são mais confiáveis do que as instâncias padrão, o que permite que elas sejam usadas para cargas de trabalho confidenciais.
Se o modelo de ameaças depende da Computação confidencial, um problema é garantir que uma carga de trabalho esteja sendo executada em uma instância de VM confidencial. O atestado remoto é um meio usado para a carga de trabalho provar a uma parte remota que ela é executada em uma instância de VM confidencial e confirmar muitas outras propriedades sobre a configuração e o ambiente da carga de trabalho. Como os atestados são gerados pela plataforma, a carga de trabalho não pode criar atestados falsos que não reflitam o ambiente real.
Um KMS pode exigir e avaliar esses atestados antes de permitir o acesso às chaves. Esse requisito ajuda a garantir que apenas a carga de trabalho pretendida possa descriptografar os dados, mesmo que as credenciais normais sejam comprometidas.
Nível 5: confiança dividida
Ao usar um único KMS, ele tem controle único sobre as chaves de criptografia. Se o operador KMS adquire o texto criptografado dos dados criptografados, ele tem tudo o que é necessário para descriptografá-lo no texto simples. Embora esse risco possa ser aceitável se o KMS for operado por uma entidade completamente confiável, alguns modelos de ameaça criam uma necessidade de remover o controle unilateral do KMS.
Com o STET, você tem a opção de dividir essa confiança entre dois sistemas KMS, sem que o KMS tenha informações suficientes para descriptografar os dados. Para descriptografar os dados, é necessário um conflito entre os operadores KMS e o acesso ao texto criptografado.
Se você estiver usando uma VM confidencial, a STET também facilita a criptografia e a descriptografia de dados usando chaves armazenadas em um KMS que exige atestados.
Juntos, o STET ajuda a garantir que as únicas entidades que têm acesso aos dados de texto simples sejam a origem dos dados (por exemplo, um sistema local) e o consumidor dos dados (por exemplo, uma carga de trabalho em execução em uma instância de VM confidencial).
Para mais informações sobre como usar o STET, consulte o repositório do GitHub e o guia de início rápido.
Confidential Space com STET
Se você usar o Confidential Space, o STET poderá usar o token de atestado do Confidential Space como evidência de atestado ao acessar a chave de criptografia de chaves (KEK) armazenada no Cloud KMS.
O STET processa o acesso às chaves do Cloud KMS para sua carga de trabalho e oferece suporte ao uso do Confidential Space para realizar atestados para o fluxo de trabalho de criptografia, o fluxo de trabalho de descriptografia ou ambos.
É possível criar uma configuração de STET que inclua informações como o nome do pool de identidade de carga de trabalho (WIP, na sigla em inglês), URIs do Cloud KMS e informações de descriptografia. Em seguida, o STET usa essas informações para integrar à configuração do Confidential Space.
Para mais informações, consulte o repositório do GitHub e o guia de integração do Espaço confidencial.