A ferramenta Split-Trust Encryption (STET) permite a transferência segura de dados de chaves para dentro e fora de Google Cloud de maneira comprovadamente e criptograficamente protegida contra pessoas com informações privilegiadas de Google Cloud .
Isso é feito usando dois sistemas de gerenciamento de chaves (KMS, na sigla em inglês), um interno ao Google Cloude outro externo. Mesmo que um KMS seja comprometido, o segundo estará em vigor para ajudar a manter a privacidade dos seus dados.
A seguir, há uma série de exemplos envolvendo dados transmitidos ao Cloud Storage e calculados usando VMs do Compute Engine. Os exemplos mostram níveis crescentes de segurança para ajudar a explicar como o STET se encaixa no seu 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 à carga de trabalho acesso 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 usadas para criar a criptografia. dados (texto criptografado). Dependendo do seu modelo de ameaças, é recomendável criptografar os dados antes de enviá-los ao Cloud Storage, para que o serviço 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 executada 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 VM confidencial são executadas com a memória criptografada, fornecendo 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 sensíveis.
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 está sendo 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 a VM confidencial, a STET também vai facilitar 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 a STET, consulte o repositório do GitHub e o guia de início rápido.
Confidential Space com STET
Se você usa o Confidential Space, o STET pode usar o token de comprovação do Confidential Space como evidência de comprovação 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 o atestado do fluxo de trabalho de criptografia, descriptografia ou ambos.
É possível criar uma configuração do STET que inclua informações como o nome do pool de identidades da carga de trabalho (WIP), URIs do Cloud KMS e informações de descriptografia. Em seguida, o STET usa essas informações para se integrar à configuração do seu Confidential Space.
Para mais informações, consulte o repositório do GitHub e o guia de integração do Confidential Space.