Práticas recomendadas para usar CMEKs

Esta página descreve as práticas recomendadas para configurar a criptografia em repouso com de criptografia gerenciadas pelo cliente (CMEKs) nos recursos do Google Cloud. Este guia é destinado a arquitetos de nuvem e equipes de segurança e descreve práticas recomendadas e decisões que você precisa tomar ao projetar a CMEK do Terraform.

Para acompanhar este guia, você precisa estar familiarizado com o Cloud Key Management Service (Cloud KMS) e ter lido o processo profundo do Cloud KMS mergulhar.

Decisões preliminares

As recomendações nesta página são destinadas aos clientes que usam CMEKs para criptografar os dados. Se você não souber ao certo se deve usar manualmente ou CMEKs criadas automaticamente como parte da estratégia de segurança. Nesta seção, fornece orientação para essas decisões preliminares.

Decidir se você quer usar o CMEK

Recomendamos usar a CMEK para criptografar dados em repouso no Google Cloud se precisar de algum 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 o material da chave no Cloud KMS ou importe o material da chave que está mantidos fora do Google Cloud.

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

  • Excluir seletivamente os dados protegidos por suas chaves em caso de desligamento ou remediação de ocorrências de segurança (trituração criptográfica).

  • Crie e use chaves exclusivas de um cliente, estabelecendo uma 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 com chaves gerenciadas pelo Google é apropriado para seu caso de uso. Se escolher usar apenas a criptografia padrão, você pode parar lendo este guia.

Escolher a criação manual ou automatizada de chaves

Este guia descreve as práticas recomendadas para decisões que você precisa tomar ao o provisionamento de CMEKs por conta própria. 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.

O 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 descriptografar permissões na chave.
    • As permissões de administrador do Cloud KMS se aplicam normalmente às chaves criado pelo Autokey. Os administradores do Cloud KMS podem exibir, atualizar, ativar ou desativar e destruir chaves criadas por Autokey. Os administradores do Cloud KMS não recebem permissões de criptografia e descriptografia.
    • Os desenvolvedores do Autokey só podem solicitar atribuição. Não é possível visualizar ou gerenciar chaves.
  • Especificidade de chave ou granularidade:chaves criadas pelo Autokey. têm granularidade que varia de acordo com o tipo de recurso. Para detalhes específicos de serviços 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 pela CMEK em locais O Cloud HSM não está disponível, você precisa criar sua CMEK manualmente.

  • Estado da versão da chave:chaves recém-criadas e solicitadas usando o Autokey. são criadas como a versão da chave primária no estado ativado.
  • Nomenclatura de keyrings: todas as chaves criadas pelo Autokey são criadas em uma chamado autokey no projeto Autokey no conjunto o local. Os keyrings no seu projeto do Autokey são criados O desenvolvedor do Autokey solicita a primeira chave em um determinado local.
  • Nomenclatura de chaves:as chaves criadas pelo Autokey seguem esta nomenclatura. convenção: PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX
  • Exportação de chaves: como todas as chaves do Cloud KMS, as chaves criadas pelo Não é possível exportar o Autokey.
  • Rastreamento de chaves:como todas as chaves do Cloud KMS usadas na CMEK integradas compatíveis com rastreamento de chaves, chaves criadas pelo Autokey são rastreadas no painel do Cloud KMS.

Se você tiver requisitos que não podem ser atendidos com chaves criadas pelo Autokey, como um nível de proteção diferente de HSM ou serviços que não forem compatíveis com Autokey, recomendamos o uso em CMEKs criadas manualmente em vez do Autokey.

Projetar sua arquitetura de CMEK

Ao projetar uma arquitetura de CMEK, você precisa considerar a configuração do chaves que você vai usar e como elas são gerenciadas. Essas decisões influenciam seu operacional, overhead operacional e facilidade de implementação de recursos como trituração de criptomoedas.

As seções a seguir discutem recomendações para cada escolha de design.

Usar um projeto centralizado de chaves CMEK para cada ambiente

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

O diagrama a seguir ilustra esses conceitos no design recomendado:

  • Cada pasta do 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 chave do Cloud KMS, e essas chaves são usadas para criptografar recursos nos projetos do aplicativo.
  • As políticas do Identity and Access Management (IAM) são aplicadas a projetos ou pastas de permitir a separação de tarefas. O principal que gerencia as chaves do Cloud KMS no projeto de chave do Cloud KMS não é o mesmo usa as chaves de criptografia em projetos de aplicativos.

Estrutura de projeto e pasta recomendada do Cloud KMS

Se você usa o Autokey do Cloud KMS, cada pasta na qual o Autokey está ativadas precisam ter um projeto de chave do Cloud KMS dedicado.

Criar keyrings do Cloud KMS para cada local

É preciso criar keyrings do Cloud KMS nos locais de implantação Recursos do Google Cloud criptografados com CMEK.

  • Os recursos regionais e zonais precisam usar um keyring e uma CMEK na mesma região como o recurso ou no local global. Única região e zonal os recursos não podem usar um keyring multirregional diferente de global.
  • Recursos multirregionais (como um conjunto de dados do BigQuery no us) multirregional) precisam usar um keyring e uma CMEK na mesma região multirregional ou birregional. Recursos multirregionais não podem usar um keyring regional.
  • Os recursos globais precisam usar um keyring e uma CMEK no local global.

Aplicar chaves regionais é uma parte de uma estratégia de regionalização de dados. De o uso de keyrings e chaves em uma região definida, também aplica os recursos precisam corresponder à região do keyring. Para orientações sobre dados residência, consulte Implementar requisitos de residência e soberania de dados.

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

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

Se você usa o Autokey do Cloud KMS, os keyrings são criados para você no mesmo local como 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. Para exemplo, uma chave que protege vários recursos é considerada 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 o seguinte vantagens e desvantagens de diferentes padrões:

Chaves de alta granularidade (por exemplo, uma chave para cada item) recurso

  • Mais controle para desativar com segurança as versões de chave: desativar ou destruir uma versão principal usada para um escopo restrito tem menor risco de afetar outros recursos que não 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, a escolha de uma granularidade maior resulta em custos mais altos.
  • Sobrecarga operacional:o uso de chaves altamente granulares pode exigir esforço administrativo ou ferramentas adicionais de automação para provisionar um de recursos do Cloud KMS e gerenciar controles de acesso para agentes de serviço, para que possam usar apenas as chaves apropriadas. Se você precisar chaves com alta granularidade, o 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.

  • Requer cuidado para desativar versões de chave com segurança: desativar ou destruir uma usada em um escopo amplo requer mais cuidado que a desativação ou destruir uma chave altamente granular. Você precisa garantir que todos os recursos criptografados por essa versão são recriptografados de forma segura com uma nova versão de chave antes de desativar a versão antiga da chave. Para muitos tipos de recursos, você pode visualizar uso de chaves para ajudar a identificar onde uma chave foi usada. Isso também significa que o uso de chaves de baixa granularidade pode aumentar o possível impacto de uma chave ser comprometida em comparação com o uso de alta granularidade chaves.
  • Custo:o uso de chaves menos granulares exige o uso de menos versões de chave. criado, e os preços do Cloud KMS são baseados o 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.

Escolha o nível de proteção para as chaves

Ao criar uma chave, é sua responsabilidade selecionar a proteção apropriado para cada chave com base no seus requisitos para dados e cargas de trabalho criptografados com CMEK. O seguinte perguntas podem ajudar na avaliação:

  1. Você precisa de algum dos recursos da CMEK? Analise os recursos listadas em Decidir se você quer usar a CMEK nesta página.

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

  3. Você exige que o material da 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 outras você precisa provisionar as chaves por conta própria.

Use material de chave gerado pelo Google quando possível.

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

Ao criar uma chave, é preciso permitir que o Cloud KMS gere a material da chave para você ou importe manualmente o material da chave gerado fora do Google Cloud. Quando possível, recomendamos que você escolha gerada. Essa opção não expõe o material bruto da chave fora Cloud KMS e cria automaticamente novas versões de chave com base na período de rotação que você escolher. Se você precisar da opção de importar suas próprias material importante, recomendamos que você avalie os seguintes aspectos considerações e riscos do uso da abordagem BYOK (traga sua própria chave):

  • 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. O que é o impacto caso a automação não crie uma nova versão da chave o horário previsto?
  • Como você pretende armazenar ou colocar em garantia o material original da chave?
  • Como reduzir o risco de vazamento de dados brutos durante o processo de importação de chaves? da chave de segurança?
  • Qual seria o impacto em importar novamente uma chave destruída anteriormente porque o a chave bruta foi retida fora do Google Cloud?
  • O benefício de importar o material da chave por conta própria justifica o aumento risco e sobrecarga operacional?

Escolha a finalidade de chave e o algoritmo certos para suas necessidades

Ao criar uma chave, é preciso selecionar a finalidade e o algoritmo subjacente para a chave. Para casos de uso de CMEK, apenas chaves com o propósito ENCRYPT_DECRYPT simétrico podem ser usadas. Essa finalidade principal sempre usa o Algoritmo GOOGLE_SYMMETRIC_ENCRYPTION, que usa criptografia avançada de 256 bits Chaves padrão (AES-256) no modo de contador Galois (GCM), 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 criptografia do lado do cliente, revise as chaves disponíveis finalidades e algoritmos para escolher a opção mais apropriada 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 confidencialidade 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ê faz a rotação de uma chave, os dados criptografados versões anteriores da chave não será recriptografada de forma automática.

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

Se você usar o Autokey, as chaves serão criadas usando uma rotação de chaves padrão. período 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 e outras funções importantes 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. Qa é altamente recomendável evitar o uso de papéis básicos. Em vez disso, conceder papéis predefinidos do Cloud KMS para mitigar e os riscos de incidentes de segurança relacionados ao acesso privilegiado.

Violações desse princípio e problemas relacionados podem ser detectadas automaticamente pelo Descobertas de vulnerabilidade do Security Command Center para IAM.

Planejar a separação de tarefas

Mantenha identidades e permissões separadas para aqueles que administram sua chaves de criptografia e de quem as usa. 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 associadas a qual cargo:

Papel do IAM Descrição Designação NIST SP 800-152
roles/cloudkms.admin Dá acesso aos recursos do Cloud KMS, com exceção do acesso tipos de recursos restritos e operações criptográficas. Oficial de criptografia
roles/cloudkms.cryptoKeyEncrypterDecrypter Permite usar os recursos do Cloud KMS para Apenas operações 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

Violações deste princípio e problemas relacionados podem ser detectadas automaticamente por descobertas de vulnerabilidade do Security Command Cloud KMS.

Aplicar a CMEK com consistência

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

Aplicar garantias do 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 de CMEK em todo o ambiente com restrições de políticas da organização.

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

Exigir que as chaves sejam desativadas antes da destruição

Recomendamos desativar as versões de chave antes de programá-las para destruição. Isso ajuda a validar se a chave não está em uso ativo e é uma etapa importante determinar se é seguro destruir uma versão de chave. Dados e os recursos protegidos por CMEKs não podem ser acessados após a chave correspondente versão foi desativada ou destruída. Uma versão de chave no estado desativado não pode ser usada, mas poderá ser reativada no futuro, se necessário.

Recomendamos que você use a restrição de política da organização constraints/cloudkms.disableBeforeDestroy exigir que uma chave seja desativada antes de ser programada para destruição.

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

Recomendamos que você defina uma duração mínima programada para destruição. Chave a destruição é uma operação irreversível que pode resultar em perda de dados. Por padrão, o Cloud KMS usa um período de 30 dias programado para destruição (às vezes chamado de período de exclusão reversível) antes que o material da chave seja irrecuperavelmente destruído. Dessa forma, você tem tempo para restaurar a chave em caso de destruição. 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 programada para destruição só pode ser definida durante criação de chaves.

Para garantir que todas as chaves criadas obedeçam a um valor mínimo programado para destruição padrão, recomendamos que você configure a restrição de política da organização constraints/cloudkms.minimumDestroyScheduledDurations com um período de espera 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 programada para destruição menor que o valor especificado na política.

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

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

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

Configurar controles de detetive para CMEKs

O Google Cloud oferece vários controles de detecção para CMEKs. O seguinte seções apresentam como ativar e usar esses controles relevantes para no Cloud KMS.

Ativar e agregar a geração de registros de auditoria

Recomendamos que você agregue Registros de auditoria de atividade do administrador do Cloud KMS (com o Administrador do os registros de atividades de todos os serviços) em um local centralizado para todos os recursos do em toda a organização. Isso permite que uma equipe ou auditor de segurança analise todas as atividades relacionadas à 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.

Também é possível 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 de chaves

É 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 usados para monitorar o estado, o uso e a disponibilidade das versões de chaves e os recursos que elas protegem. O painel também identifica dados inacessível devido a uma chave desativada ou destruída para que você possa tomar medidas como limpar os dados inacessíveis ou reativar a chave.

Você também pode usar o Cloud Monitoring com o Cloud KMS para definir alertas para eventos críticos, como programar a destruição de uma chave. Com o Cloud Monitoring, você tem a chance de fazer a triagem do motivo pelo qual uma operação foi realizada e acionará um processo downstream opcional para restaurar a chave se necessários.

Recomendamos que você estabeleça um plano operacional para detectar automaticamente eventos que você considera importantes e revisar periodicamente o uso da chave mais avançado.

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

O Security Command Center gera descobertas de vulnerabilidade que destacar configurações incorretas associadas ao Cloud KMS e outros do Google Cloud. Recomendamos que você ative o Security Command Center e integre esses descobertas em 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 os requisitos de compliance

Diferentes frameworks de compliance têm requisitos distintos de criptografia e gerenciamento de chaves. Uma estrutura de conformidade normalmente descreve as normas princípios e objetivos do gerenciamento de chaves de criptografia, mas isso não é obrigatório sobre o produto ou a configuração específica que atinge a conformidade. Está sua responsabilidade de entender os requisitos do 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 a CMEK Use a CMEK se você precisar de qualquer um dos recursos ativado pela CMEK.
Escolher a criação de chaves manual ou automatizada Use o Cloud KMS Autokey se o as características das chaves criadas pelo Autokey atendem às suas necessidades.
Projetos-chave do Cloud KMS Usar um projeto de chave centralizado para cada ambiente. Não criar recursos do Cloud KMS no mesmo projeto que o Google Cloud recursos protegidos pelas chaves.
Keyrings do Cloud KMS Crie keyrings do Cloud KMS para cada local em que você quer proteger os recursos do Google Cloud.
Granularidade de chave Escolha um padrão de granularidade de chave que atende às suas necessidades ou use o Autokey para provisionar chaves automaticamente com a granularidade recomendada para cada serviço.
Nível de proteção Escolha o Cloud EKM se o material da chave precisar ser armazenado fora de 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. Escolher chaves de software caso suas necessidades não exijam o Cloud HSM ou o Cloud EKM. Leia as orientações para selecionar um nível de proteção.
Material da chave Para materiais importantes hospedados no Google Cloud, use as chaves do Google material da chave sempre que possível. Se você usar material de chave importado, implementar automação e procedimentos para mitigar riscos.
Algoritmo e finalidade da chave Todas as chaves CMEK precisam usar a 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 suas chaves sejam giradas cronograma. Escolha e aplique um período de rotação que atenda às suas necessidades, idealmente pelo menos uma vez por ano. Use uma rotação de chaves mais frequente para para cargas de trabalho confidenciais.
Privilégio mínimo Conceder os papéis predefinidos mais limitados que permitem aos principais para concluir as tarefas. Não use papéis básicos.
Separação de tarefas Mantenha permissões separadas para administradores de chaves e principais que usam chaves.
Garantias do projeto Use as garantias do projeto para evitar a exclusão acidental da chave projetos.
Exigir CMEKs Usar a constraints/gcp.restrictNonCmekServices restrição.
Exigir que as chaves sejam desativadas antes da destruição Use a restrição constraints/cloudkms.disableBeforeDestroy.
Exigir um tempo mínimo programado para destruição Use o constraints/cloudkms.minimumDestroyScheduledDurations restrição.
Aplique os níveis de proteção permitidos para CMEKs Use a restrição constraints/cloudkms.allowedProtectionLevels.
Ativar e agregar a geração de registros de auditoria Agregar registros de auditoria de atividades administrativas para todos os recursos na sua organização. Considere se você quer ativar o registro de operações usando chaves.
Monitorar o uso de chaves Use a API de inventário do Cloud KMS ou o console do Google Cloud para entender o uso da chave. Se quiser, use o Cloud Monitoring para definir alertas operações sensíveis, como programar a destruição de uma chave.
Ativar o Security Command Center para Cloud KMS Analisar as descobertas de vulnerabilidades e integrar a análise de vulnerabilidades descobertas em 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