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 recursos do Google Cloud. 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 leu o Guia de introdução ao Cloud KMS.

Decisões preliminares

As recomendações desta página são destinadas a clientes que usam CMEKs para criptografar dados. Se você não tiver certeza se deve usar CMEKs criadas manualmente ou automaticamente como parte da sua estratégia de segurança, esta seção oferece orientações para essas decisões preliminares.

Decidir se você quer usar o CMEK

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

  • Ter suas próprias chaves de criptografia.

  • Controle e gerencie suas chaves de criptografia, incluindo a escolha de 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 do Google 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 chaves gerenciadas pelo Google é adequada para seu caso de uso. Se você optar por usar apenas a criptografia padrão, pare de ler este guia.

Escolha a criação manual ou automatizada de chaves

Este guia descreve as práticas recomendadas para decisões que você precisa tomar ao provisionar CMEKs. O Cloud KMS Autokey toma algumas dessas decisões para você e automatiza muitas recomendações deste guia. Usar a Autokey é mais simples do que provisionar chaves manualmente e é a escolha recomendada se as chaves criadas pela Autokey atenderem a todos os requisitos.

A Autokey provisiona CMEKs para você. As CMEKs provisionadas pelo Autokey têm as seguintes características:

  • Nível de proteção:HSM.
  • Algoritmo:AES-256 GCM.

  • Período de rotação:um ano.

    Depois que uma chave é criada pelo Autokey, um administrador do Cloud KMS pode editar o período de rotação do padrão.

  • Separação de tarefas:
    • A conta de serviço do serviço recebe automaticamente permissões de criptografia e descriptografia na chave.
    • As permissões de administrador do Cloud KMS são aplicadas normalmente às chaves criadas pelo Autokey. Os administradores do Cloud KMS podem conferir, atualizar, ativar ou desativar e destruir chaves criadas pelo Autokey. Os administradores do Cloud KMS não recebem permissões de criptografia e descriptografia.
    • Os desenvolvedores da Autokey só podem solicitar a criação e a atribuição de chaves. Não é possível acessar ou gerenciar chaves.
  • Especificidade ou granularidade da chave:as chaves criadas pela Autokey têm uma granularidade que varia de acordo com o tipo de recurso. Para detalhes específicos do serviço sobre a granularidade da chave, consulte Serviços compatíveis.

  • Local:o Autokey cria chaves no mesmo local que o recurso a ser protegido.

    Se você precisar criar recursos protegidos por CMEK em locais em que o Cloud HSM não estiver disponível, crie o CMEK manualmente.

  • Estado da versão da chave:as chaves recém-criadas solicitadas usando a chave automática são criadas como a versão da chave primária no estado ativado.
  • Nomeação de keyring:todas as chaves criadas pelo Autokey são criadas em um keyring chamado autokey no projeto Autokey no local selecionado. Os keyrings no seu projeto do Autokey são criados quando um desenvolvedor do Autokey solicita a primeira chave em um determinado local.
  • Nome da chave:as chaves criadas pelo Autokey seguem esta convenção de nomenclatura: PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX
  • Exportação de chaves:como todas as chaves do Cloud KMS, as chaves criadas pelo Autokey não podem ser exportadas.
  • Rastreamento de chaves:como todas as chaves do Cloud KMS usadas em serviços integrados da CMEK que são compatíveis com o rastreamento de chaves, as chaves criadas pela chave automática são rastreadas no painel do Cloud KMS.

Se você tiver requisitos que não podem ser atendidos com chaves criadas pela chave automática, como um nível de proteção diferente de HSM ou serviços que não são compatíveis com a chave automática, recomendamos o uso de CMEKs criadas manualmente em vez da chave automática.

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 do Identity and Access Management (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

Se você usa o Cloud KMS Autokey, cada pasta em que o Autokey está ativado precisa ter um projeto de chave do Cloud KMS dedicado.

Criar keyrings do Cloud KMS para cada local

É necessário criar keyrings do Cloud KMS nos locais em que você implanta recursos do Google Cloud 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 de região única e zonal não podem usar um keyring multirregional diferente de global.
  • Os recursos multirregionais (como um conjunto de dados do BigQuery na multirregião us) precisam usar um keyring e um CMEK na mesma multirregião ou dupla região. Os recursos multirregionais não podem usar um keyring regional.
  • Os recursos globais precisam usar um keyring e a 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 keyring. Para orientações sobre a residência de dados, consulte Implementar requisitos de residência e soberania de dados.

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 de us-central1 não pode ser recriado em us-central2 em um cenário de recuperação de desastres em que us-central1 não está disponível. Para reduzir o risco desse cenário, planeje a criptografia de um recurso com chaves global.

Para mais informações, consulte Como escolher o melhor tipo de local.

Se você usar a autokey do Cloud KMS, os keyrings serão criados para você no mesmo local que os recursos que você protege.

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 provisionadas manualmente 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. Como os preços do Cloud KMS são baseados no número de versões de chaves ativas, escolher uma granularidade maior resulta em custos mais altos.
  • 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. Se você precisar de chaves com alta granularidade, a Autokey pode ser uma boa opção para automatizar o provisionamento. Para mais informações sobre a granularidade da chave Autokey para cada serviço, consulte Serviços compatíveis.

Chaves de baixa granularidade: por exemplo, uma chave para cada aplicativo, região e 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 exige 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. Para muitos tipos de recursos, é possível acessar o uso de chaves para identificar onde uma chave foi usada. Isso também significa que o uso de chaves de baixa granularidade pode aumentar o impacto potencial de uma chave comprometida 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, e o preço do Cloud KMS é baseado no número de versões de chaves ativas.
  • Sobrecarga 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.

  2. Você exige que o material da chave permaneça dentro do limite físico de um módulo de segurança de hardware (HSM)?

  3. Você exige que o material de chave seja armazenado fora do Google Cloud?

A chave automática só oferece suporte ao nível de proteção do HSM. Se você precisar de outros níveis de proteção, será necessário provisionar as chaves.

Use materiais de chave gerados pelo Google sempre 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 do Google Cloud. Quando 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 bruto?
  • Qual seria o impacto de reimportar uma chave destruída anteriormente porque o material da chave bruta foi retido fora do Google 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, é necessário 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 ser comprometida.

Se você usar o Autokey, as chaves serão criadas usando um período de rotação de chaves padrão de um ano. É possível mudar o período de rotação das chaves depois que elas são criadas.

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.

As violações desse princípio e problemas relacionados podem ser detectados automaticamente pelas descobertas de vulnerabilidade do Security Command Center para IAM.

Planejar a separação de tarefas

Mantenha identidades e permissões separadas para quem administra e quem usa suas chaves de criptografia. A 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 os serviços do Google Cloud, o papel do IAM para usar chaves de criptografia é atribuído ao agente de serviço do serviço do Google Cloud, não ao usuário individual. Por exemplo, para criar objetos em um bucket criptografado do Cloud Storage, 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.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

As violações desse princípio e problemas relacionados podem ser detectados automaticamente pelo Security Command com as descobertas de vulnerabilidade do Cloud KMS.

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 restore 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

O Google 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.

Monitorar o uso da chave

É possível ver o uso da chave com a API de inventário do Cloud KMS para identificar os recursos do Google Cloud na sua organização que dependem e são protegidos por chaves do Cloud KMS. Esse painel pode ser usado para monitorar o estado, o uso e a disponibilidade das versões de chaves e dos recursos correspondentes que elas protegem. O painel também identifica dados inacessíveis devido a uma chave desativada ou destruída para que você possa realizar ações como limpar os dados inacessíveis ou reativar a chave.

Também é possível usar o Cloud Monitoring com o Cloud KMS para definir alertas para eventos críticos, como a programação de uma chave para destruição. O Cloud Monitoring permite que você trieie por que essa operação foi realizada e acione um processo downstream opcional para restaurar a chave, se necessário.

Recomendamos que você estabeleça um plano operacional para detectar automaticamente eventos que você considera importantes e revise periodicamente o painel de uso principal.

Ativar o Security Command Center para descobertas de vulnerabilidade do Cloud KMS

O Security Command Center gera descobertas de vulnerabilidade que destacam as configurações incorretas associadas ao Cloud KMS e a outros recursos. Recomendamos que você ative o Security Command Center e integre essas descobertas às suas operações de segurança. Essas descobertas incluem problemas como chaves do Cloud KMS acessíveis publicamente, projetos do Cloud KMS com o papel owner excessivamente permissivo ou papéis do IAM que violam a separação de tarefas.

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 do Google Cloud podem ajudar a atender aos requisitos de diferentes frameworks de compliance, consulte os seguintes recursos:

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.
Escolher a criação manual ou automatizada de chaves Use o Cloud KMS Autokey se as características das chaves criadas pelo Autokey atenderem às suas necessidades.
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 dos recursos do Google Cloud que as chaves protegem.
Keyrings do Cloud KMS Crie keyrings do Cloud KMS para cada local em que você quer proteger os recursos do Google Cloud.
Granularidade da chave Escolha um padrão de granularidade de chave que atenda às suas necessidades ou use a chave automática para provisionar chaves automaticamente com a granularidade recomendada para cada serviço.
Nível de proteção Escolha o Cloud EKM se o material de chave precisar ser armazenado fora do Google Cloud. Escolha o Cloud HSM se o material da chave puder ser hospedado em módulos de segurança de hardware (HSMs) pertencentes ao Google. Escolha chaves de software se suas necessidades não exigirem o Cloud HSM ou o Cloud EKM. Leia as orientações para selecionar um nível de proteção.
Material da chave Para materiais de chave hospedados no Google Cloud, use materiais de chave gerados pelo Google sempre que possível. Se você usar material de chave importado, implemente automação e 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 de chaves e principais que usam chaves.
Garantias de projeto Use garantias do projeto para evitar a exclusão acidental de 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 Registros de auditoria de atividade administrativa agregados para todos os recursos da sua organização. Considere ativar o registro de operações usando chaves.
Monitorar o uso da chave Use a API de inventário do Cloud KMS ou o console do Google Cloud para entender o uso da chave. Como opção, use o Cloud Monitoring para definir alertas para operações sensíveis, como programar a destruição de uma chave.
Ativar o Security Command Center para o Cloud KMS Analise os resultados de vulnerabilidade e integre a análise de vulnerabilidades às suas operações de segurança.
Avaliar os requisitos de compliance Revise sua arquitetura do Cloud KMS e compare com os requisitos de conformidade que você precisa seguir.

A seguir