Facilite a criptografia de dados ubíqua com a ferramenta de criptografia Split-Trust

Para o Google, a criptografia de ponta a ponta precisa ter uma visão simples: que os dados do cliente são protegidos de modo verificável contra qualquer acesso não autorizado ao cliente assim que ele sai do data center e chega ao Google Cloud. Nosso objetivo é fornecer um mecanismo seguro de distribuição de chaves que permita a entrada e a saída seguras de chaves do Google Cloud de maneira comprovável e . protegidos criptograficamente contra pessoas com informações privilegiadas do Google Cloud.

O escopo desse recurso são os dados transmitidos ao Cloud Storage e calculados usando VMs do Compute Engine. Nesta visão geral, abordamos as tecnologias de criptografia existentes para o Cloud Storage, o Compute Engine e os gerenciadores de chaves externos. Ele descreve as lacunas em relação à nossa visão e como esse recurso ajuda a preencher essas lacunas.

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á necessariamente 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 Cloud Storage nunca tenha visibilidade do texto simples.

Criptografia no 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.

Gerenciamento de chaves externo

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.

Computação confidencial

Com a oferta de máquina virtual confidencial (VM) do Google Cloud, as VMs do Compute Engine 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 VMs confidenciais são mais confiáveis do que as VMs 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 VM confidencial. O Atestado remoto é um meio usado para a carga de trabalho provar a uma parte remota que ela é realmente executada em uma VM confidencial e confirmar muitas outras propriedades sobre a configuração e 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 incluam 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.

A ferramenta Split-Trust Encryption (STET) facilita a criptografia e a descriptografia de dados usando chaves armazenadas em um KMS que exige atestados.

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.

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 VM confidencial.

Para mais informações sobre como usar a ferramenta de criptografia Split-Trust, consulte o repositório do GitHub e o guia de início rápido.