Práticas recomendadas para usar CMEKs

Esta página descreve as práticas recomendadas para configurar a criptografia em repouso com chaves de criptografia gerenciadas pelo cliente (CMEKs, na sigla em inglês) nos seus Trusted Cloud recursos. Este guia é destinado a arquitetos de nuvem e equipes de segurança e descreve as práticas recomendadas e decisões que você precisa tomar ao projetar sua arquitetura CMEK.

Este guia pressupõe que você já conhece o Cloud Key Management Service (Cloud KMS) e as chaves de criptografia gerenciadas pelo cliente.

Decidir se você quer usar o CMEK

Recomendamos que você use o CMEK para criptografar dados em repouso nos serviços Trusted Cloud se precisar de qualquer um dos seguintes recursos:

  • Ter suas próprias chaves de criptografia.

  • Controle e gerencie suas chaves de criptografia, incluindo a escolha do local, nível de proteção, criação, controle de acesso, rotação, uso e destruição.

  • Gere material de chave no Cloud KMS ou importe material de chave mantido fora de Trusted Cloud.

  • Defina a política sobre onde as chaves precisam ser usadas.

  • Exclua seletivamente os dados protegidos pelas suas chaves no caso de desativação ou para remediar eventos de segurança (fragmentação criptográfica).

  • Crie e use chaves exclusivas para um cliente, estabelecendo um limite criptográfico em torno dos dados.

  • Registre o acesso administrativo e de dados às chaves de criptografia.

  • Atender a regulamentações atuais ou futuras que exijam qualquer uma dessas metas.

Se você não precisar desses recursos, avalie se a criptografia padrão em repouso com Google Cloud-powered keys é adequada para seu caso de uso. Se você optar por usar apenas a criptografia padrão, pare de ler este guia.

Projetar sua arquitetura de CMEK

Ao projetar uma arquitetura CMEK, você precisa considerar a configuração das chaves que vai usar e como elas são gerenciadas. Essas decisões influenciam o custo, a sobrecarga operacional e a facilidade de implementação de recursos, como o criptorompimento.

As seções a seguir discutem as recomendações para cada opção de design.

Usar um projeto de chave CMEK centralizado para cada ambiente

Recomendamos o uso de um projeto de chave CMEK centralizado para cada pasta de ambiente. Não crie recursos criptografados com a CMEK no mesmo projeto em que você gerencia chaves do Cloud KMS. Essa abordagem ajuda a evitar o compartilhamento de chaves de criptografia entre ambientes e permite a separação de funções.

O diagrama a seguir ilustra esses conceitos no design recomendado:

  • Cada pasta de ambiente tem um projeto de chave do Cloud KMS administrado separadamente dos projetos de aplicativos.
  • Os keyrings e as chaves do Cloud KMS são provisionados no projeto de chaves do Cloud KMS e são usados para criptografar recursos nos projetos de aplicativos.
  • As políticas de gerenciamento de identidade e acesso (IAM) são aplicadas a projetos ou pastas para permitir a separação de tarefas. O principal que gerencia as chaves do Cloud KMS no projeto de chaves do Cloud KMS não é o mesmo que usa as chaves de criptografia em projetos de aplicativos.

Estrutura de projeto e pasta recomendada do Cloud KMS

Criar keyrings do Cloud KMS para cada local

Você precisa criar keyrings do Cloud KMS nos locais em que implanta Trusted Cloud recursos criptografados com CMEK.

  • Os recursos regionais e zonais precisam usar um keyring e uma CMEK na mesma região do recurso ou no local global.
  • Os recursos globais precisam usar um keyring e uma CMEK no local global.

A aplicação de chaves regionais é uma parte de uma estratégia de regionalização de dados. Ao forçar o uso de chaveiros e chaves em uma região definida, você também exige que os recursos correspondam à região do chaveiro.

Para cargas de trabalho que exigem recursos de alta disponibilidade ou recuperação de desastres em vários locais, é sua responsabilidade avaliar se a carga de trabalho é resiliente caso o Cloud KMS fique indisponível em uma determinada região. Por exemplo, um disco permanente do Compute Engine criptografado com uma chave do Cloud KMS da região A não pode ser recriado na região B em um cenário de recuperação de desastres em que a região A está indisponível. Para reduzir o risco desse cenário, planeje a criptografia de um recurso com chaves global.

Escolher uma estratégia de granularidade de chave

Granularidade se refere à escala e ao escopo do uso pretendido de cada chave. Por exemplo, uma chave que protege vários recursos é menos granular do que uma chave que protege apenas um recurso.

As chaves do Cloud KMS usadas para CMEK precisam ser provisionadas com antecedência antes de criar um recurso que será criptografado com a chave, como um disco permanente do Compute Engine. Você pode criar chaves muito granulares para recursos individuais ou chaves menos granulares para reutilização entre recursos de forma mais ampla.

Embora não haja um padrão universalmente correto, considere as seguintes compensações de padrões diferentes:

Chaves de alta granularidade: por exemplo, uma chave para cada recurso

  • Mais controle para desativar versões de chave com segurança:desativar ou destruir uma versão de chave usada para um escopo estreito tem um risco menor de afetar outros recursos do que desativar ou destruir uma chave compartilhada. Isso também significa que o uso de chaves altamente granulares ajuda a reduzir o possível impacto de uma chave comprometida em comparação com o uso de chaves de baixa granularidade.
  • Custo:o uso de chaves granulares exige a manutenção de versões de chaves mais ativas em comparação com uma estratégia que usa chaves com granularidade menor. Uma granularidade maior exige um número maior de versões de chaves ativas, o que gera custos adicionais.
  • Sobrecarga operacional:o uso de chaves altamente granulares pode exigir esforços administrativos ou ferramentas adicionais para a automação provisionar um grande número de recursos do Cloud KMS e gerenciar controles de acesso para agentes de serviço, para que eles só possam usar as chaves adequadas.

Chaves de baixa granularidade: por exemplo, uma chave para cada aplicativo, para cada região e para cada ambiente.

  • É preciso cuidado para desativar as versões de chave com segurança:desativar ou destruir uma versão de chave usada para um escopo amplo requer mais cuidado do que desativar ou destruir uma chave altamente granular. É necessário garantir que todos os recursos criptografados por essa versão da chave sejam recriptografados com segurança com uma nova versão da chave antes de desativar a versão antiga. Isso também significa que o uso de chaves de baixa granularidade pode aumentar o potencial de comprometimento de uma chave em comparação com o uso de chaves de alta granularidade.
  • Custo:o uso de chaves menos granulares exige a criação de menos versões de chaves, o que resulta em custos mais baixos.
  • Overhead operacional:é possível definir e provisionar previamente um número conhecido de chaves, com menos esforço necessário para garantir controles de acesso adequados.

Escolher o nível de proteção das chaves

Ao criar uma chave, é sua responsabilidade selecionar o nível de proteção adequado para cada chave com base nos seus requisitos para os dados e as cargas de trabalho criptografados com CMEK. As perguntas a seguir podem ajudar na sua avaliação:

  1. Você precisa de algum dos recursos do CMEK? Confira os recursos listados em Decidir se vai usar a CMEK nesta página.

    • Se sim, vá para a próxima pergunta.
    • Caso contrário, recomendamos usar a criptografia padrão. S3NS

  2. Você precisa de uma certificação FIPS 140-2 de nível 2 ou 3 ou que o material da chave seja armazenado fora de Trusted Cloud?

Use o material da chave gerado pelo Trusted Cloudsempre que possível

Esta seção não se aplica às chaves do Cloud EKM.

Ao criar uma chave, você precisa permitir que o Cloud KMS gere o material de chave para você ou importar manualmente o material de chave gerado fora de Trusted Cloud. Sempre que possível, recomendamos que você escolha a opção gerada. Essa opção não expõe o material de chave bruto fora do Cloud KMS e cria automaticamente novas versões da chave com base no período de rotação escolhido. Se você precisar importar seu próprio material de chave, recomendamos avaliar as seguintes considerações operacionais e riscos de usar a abordagem BYOK:

  • Você pode implementar a automação para importar novas versões de chaves de forma consistente? Isso inclui as configurações do Cloud KMS para restringir as versões das chaves apenas à importação e a automação fora do Cloud KMS para gerar e importar o material de chave de forma consistente. Qual é o impacto se a automação não conseguir criar uma nova versão de chave no momento esperado?
  • Como você pretende armazenar ou depositar com segurança o material de chave original?
  • Como você pode reduzir o risco de seu processo de importação de chaves vazar o material de chave bruta?
  • Qual seria o impacto de importar novamente uma chave destruída anteriormente porque o material da chave bruta foi retido fora de Trusted Cloud?
  • O benefício de importar o material-chave por conta própria justifica o aumento do overhead operacional e do risco?

Escolha o propósito e o algoritmo de chave certos para suas necessidades

Ao criar uma chave, você precisa selecionar a finalidade e o algoritmo dela. Para casos de uso da CMEK, apenas chaves com o propósito ENCRYPT_DECRYPT simétrico podem ser usadas. Esse propósito de chave sempre usa o algoritmo GOOGLE_SYMMETRIC_ENCRYPTION, que usa chaves no Padrão de criptografia avançada de 256 bits (AES-256, na sigla em inglês) no modo de contador Galois (GCM, na sigla em inglês), preenchidas com metadados internos do Cloud KMS. Quando você usa a chave automática, essas configurações são aplicadas automaticamente.

Para outros casos de uso, como a criptografia do lado do cliente, consulte os usos e algoritmos de chave disponíveis para escolher a opção mais adequada para seu caso de uso.

Escolha um período de rotação

Recomendamos que você avalie o período de rotação de chaves adequado para suas necessidades. A frequência da rotação de chaves depende dos requisitos das cargas de trabalho com base na sensibilidade ou conformidade. Por exemplo, a rotação de chaves pode ser necessária pelo menos uma vez por ano para atender a determinados padrões de compliance, ou você pode escolher um período de rotação mais frequente para cargas de trabalho altamente sensíveis.

Depois de fazer a rotação de uma chave simétrica, a nova versão é marcada como a versão da chave primária e usada para todas as novas solicitações para proteger informações. As versões de chave antiga continuam disponíveis para descriptografar dados criptografados anteriormente protegidos com essa versão. Quando você alterna uma chave, os dados criptografados com versões anteriores não são recriptografados automaticamente.

A rotação frequente de chaves ajuda a limitar o número de mensagens criptografadas com a mesma versão de chave, o que ajuda a reduzir o risco e as consequências de uma chave comprometida.

Aplicar controles de acesso adequados

Recomendamos que você considere os princípios de privilégio mínimo e separação de funções ao planejar os controles de acesso. As seções a seguir apresentam essas recomendações.

Aplicar o princípio de privilégio mínimo

Ao atribuir permissões para gerenciar CMEKs, considere o princípio de privilégio mínimo e conceda as permissões mínimas necessárias para realizar uma tarefa. É recomendável evitar o uso de papéis básicos. Em vez disso, conceda papéis predefinidos do Cloud KMS para reduzir os riscos de incidentes de segurança relacionados a acesso com privilégios excessivos.

Planejar a separação de tarefas

Mantenha identidades e permissões separadas para quem administra e quem usa suas chaves de criptografia. O NIST SP 800-152 define uma separação de funções entre o oficial de criptografia que ativa e gerencia os serviços de um sistema de gerenciamento de chaves criptográficas e um usuário que usa essas chaves para criptografar ou descriptografar recursos.

Quando você usa a CMEK para gerenciar a criptografia em repouso com serviços Trusted Cloud , o papel do IAM para usar chaves de criptografia é atribuído ao agente de serviço do serviço Trusted Cloud , não ao usuário individual. Por exemplo, para criar objetos em um bucket do Cloud Storage criptografado, um usuário precisa apenas do papel do IAM roles/storage.objectCreator, e o agente de serviço do Cloud Storage no mesmo projeto (como service-PROJECT_NUMBER@gs-project-accounts.s3ns-system.iam.gserviceaccount.com) precisa do papel do IAM roles/cloudkms.cryptoKeyEncrypterDecrypter.

A tabela a seguir lista quais papéis do IAM são normalmente associados a qual função:

Papel do IAM Descrição Designação do NIST SP 800-152
roles/cloudkms.admin Concede acesso aos recursos do Cloud KMS, com exceção do acesso a tipos de recursos restritos e operações criptográficas. Oficial de criptografia
roles/cloudkms.cryptoKeyEncrypterDecrypter Permite usar os recursos do Cloud KMS apenas para operações de encrypt e decrypt. Usuário do sistema de gerenciamento de chaves criptográficas
roles/cloudkms.viewer Ativa as operações get e list. Administrador de auditoria

Aplicar a CMEK de forma consistente

As seções a seguir descrevem outros controles para ajudar a reduzir riscos, como uso inconsistente de chaves ou exclusão ou destruição acidental.

Aplicar garantias de projeto

Recomendamos que você proteja projetos com garantias para evitar exclusões acidentais. Quando uma garantia de projeto é aplicada, o projeto de chave do Cloud KMS é bloqueado para exclusão até que a garantia seja removida.

Exigir chaves CMEK

Recomendamos que você aplique o uso do CMEK em todo o ambiente usando restrições de política da organização.

Use constraints/gcp.restrictNonCmekServices para bloquear solicitações de criação de determinados tipos de recursos sem especificar uma chave CMEK.

Exigir um tempo mínimo programado para destruição

Recomendamos que você defina uma duração mínima para destruição programada. A destruição de chaves é uma operação irreversível que pode resultar na perda de dados. Por padrão, o Cloud KMS usa um período de programado para destruição (às vezes chamado de período de exclusão reversível) de 30 dias antes que o material da chave seja destruído de forma irreversível. Isso oferece algum tempo para restaurar uma chave em caso de destruição acidental. No entanto, é possível que alguém com a função de administrador do Cloud KMS crie uma chave com uma duração de programação para destruição de até 24 horas, o que pode não ser tempo suficiente para detectar um problema e restaurar a chave. A duração scheduled for destruction só pode ser definida durante a criação da chave.

Enquanto uma chave estiver programada para destruição, ela não poderá ser usada para operações criptográficas, e todas as solicitações para usar a chave falharão. Durante esse período, monitore os registros de auditoria para verificar se a chave não está em uso. Se você quiser usar a chave novamente, será necessário restaurar a chave antes do fim do período programado para destruição.

Para garantir que todas as chaves criadas sigam um período mínimo de destruição programada, recomendamos que você configure a restrição de política da organização constraints/cloudkms.minimumDestroyScheduledDuration com um mínimo de 30 dias ou a duração de sua preferência. Essa política da organização impede que os usuários criem chaves com uma duração de programado para destruição menor do que o valor especificado na política.

Aplicar os níveis de proteção permitidos para CMEKs

Recomendamos que você aplique seus requisitos para níveis de proteção de chaves de forma consistente em todo o ambiente usando restrições de política da organização.

Use constraints/cloudkms.allowedProtectionLevels para aplicar que novas chaves, versões de chaves e jobs de importação precisam usar os níveis de proteção permitidos.

Configurar controles de detetive para CMEKs

OTrusted Cloud oferece vários controles de detecção para CMEKs. As seções a seguir apresentam como ativar e usar esses controles relevantes para o Cloud KMS.

Ativar e agregar registros de auditoria

Recomendamos que você agregue os registros de auditoria de atividades do administrador do Cloud KMS (junto com os registros de atividades do administrador de todos os serviços) em um local centralizado para todos os recursos da sua organização. Isso permite que uma equipe de segurança ou auditor analise toda a atividade relacionada à criação ou modificação de recursos do Cloud KMS de uma só vez. Para orientações sobre como configurar coletores de registros agregados, consulte Agrupar e armazenar os registros da sua organização.

Opcionalmente, você pode ativar os registros de acesso a dados para registrar operações que usam as chaves, incluindo operações de criptografia e descriptografia. O uso de CMEKs pode gerar um volume de registro considerável e afetar seus custos, porque cada operação de cada serviço que usa CMEKs cria registros de acesso a dados. Antes de ativar os registros de acesso a dados, recomendamos que você defina um caso de uso claro para os registros adicionais e avalie como seus custos de geração de registros vão aumentar.

Avaliar seus requisitos de compliance

Diferentes frameworks de compliance têm requisitos diferentes para criptografia e gerenciamento de chaves. Um framework de compliance normalmente descreve os princípios e objetivos de alto nível do gerenciamento de chaves de criptografia, mas não é prescritivo sobre o produto ou a configuração específica que alcança a conformidade. É sua responsabilidade entender os requisitos do seu framework de compliance e como seus controles, incluindo o gerenciamento de chaves, podem atender a esses requisitos.

Para orientações sobre como os serviços Trusted Cloud podem ajudar a atender aos requisitos de diferentes frameworks de compliance, consulte o seguinte recurso:

Resumo das práticas recomendadas

A tabela a seguir resume as práticas recomendadas neste documento:

Tópico Tarefa
Decidir se você quer usar o CMEK Use a CMEK se precisar de algum dos recursos ativados pela CMEK.
Projetos de chaves do Cloud KMS Use um projeto de chave centralizado para cada ambiente. Não crie recursos do Cloud KMS no mesmo projeto que os recursos Trusted Cloudque as chaves protegem.
Keyrings do Cloud KMS Crie keyrings do Cloud KMS para cada local em que você quer proteger Trusted Cloud os recursos.
Granularidade da chave Escolha um padrão de granularidade de chave que atenda às suas necessidades de tolerância a riscos, custo e sobrecarga operacional.
Nível de proteção Escolha o Cloud EKM se o material de chave precisar ser armazenado fora Trusted Cloud ou se você precisar de uma certificação FIPS 140-2 de nível 2 ou 3. Caso contrário, escolha "Chaves de software". Leia as orientações para selecionar um nível de proteção.
Material da chave Para material de chave hospedado em Trusted Cloud, use material de chave gerado por Trusted Cloudsempre que possível. Se você usar material de chave importado, implemente a automação e os procedimentos para reduzir os riscos.
Finalidade e algoritmo da chave Todas as chaves CMEK precisam usar a finalidade de chave simétrica ENCRYPT_DECRYPT e o algoritmo GOOGLE_SYMMETRIC_ENCRYPTION.
Período de rotação Use a rotação automática de chaves para garantir que elas sejam giradas de acordo com a programação. Escolha e aplique um período de rotação que atenda às suas necessidades, de preferência, pelo menos uma vez por ano. Use a rotação de chaves mais frequente para cargas de trabalho sensíveis.
Privilégio mínimo Conceda os papéis predefinidos mais limitados que permitem que os principais concluam as tarefas. Não use funções básicas.
Separação de tarefas Mantenha permissões separadas para administradores e principais que usam chaves.
Garantias de projeto Use garantias do projeto para evitar a exclusão acidental dos seus projetos principais.
Exigir CMEKs Use a restrição constraints/gcp.restrictNonCmekServices.
Exigir um tempo mínimo programado para destruição Use a restrição constraints/cloudkms.minimumDestroyScheduledDuration.
Aplicar os níveis de proteção permitidos para CMEKs Use a restrição constraints/cloudkms.allowedProtectionLevels.
Ativar e agregar registros de auditoria Agrupar registros de auditoria de atividade administrativa para todos os recursos da sua organização. Considere ativar o registro de operações usando chaves.
Avaliar os requisitos de compliance Revise sua arquitetura do Cloud KMS e compare com os requisitos de conformidade que você precisa seguir.