Práticas recomendadas para usar CMEKs

Nesta página, descrevemos as práticas recomendadas para configurar a criptografia em repouso com chaves de criptografia gerenciadas pelo cliente (CMEKs) 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 as decisões que você precisa tomar ao projetar sua arquitetura de CMEK.

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

Decisões preliminares

As recomendações nesta 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 a CMEK

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

  • Ter suas próprias chaves de criptografia.

  • Controle e gerencie suas chaves de criptografia, incluindo 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 uma política sobre onde as chaves precisam ser usadas.

  • Exclua seletivamente os dados protegidos pelas suas chaves em caso de desvinculação ou para corrigir eventos de segurança (criptofragmentação).

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

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

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

Se você não precisar desses recursos, avalie se a criptografia padrão em repouso com Google-owned and managed keys é adequada para seu caso de uso. Se você optar por usar apenas a criptografia padrão, pare de ler 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 provisionar CMEKs por conta própria. O Cloud KMS Autokey toma algumas dessas decisões por você e automatiza muitas recomendações deste guia. Usar a Autokey é mais simples do que provisionar chaves por conta própria e é a opção recomendada se as chaves criadas pela Autokey atenderem a todos os seus 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 se aplicam normalmente às chaves criadas pelo Autokey. Os administradores do Cloud KMS podem visualizar, 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 atribuição de chaves. Não é possível ver ou gerenciar chaves.
  • Especificidade ou granularidade da chave:as chaves criadas pelo 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 onde o Cloud HSM não está disponível, crie a CMEK manualmente.

  • Estado da versão da chave:as chaves recém-criadas solicitadas usando o Autokey são criadas como a versão chave primária no estado ativado.
  • Nomeação do keyring:todas as chaves criadas pelo Autokey são criadas em um keyring chamado autokey no projeto do 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.
  • Nomenclatura de chaves:as chaves criadas pelo Autokey seguem esta convenção de nomenclatura: PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX
  • Exportação de chaves:assim como todas as chaves do Cloud KMS, as chaves criadas pelo Autokey não podem ser exportadas.
  • Rastreamento de chaves:assim como todas as chaves do Cloud KMS usadas em serviços integrados à CMEK 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 pelo Autokey, como um nível de proteção diferente de HSM ou serviços que não são compatíveis com o Autokey, recomendamos usar CMEKs criadas manualmente em vez do Autokey.

Projetar sua arquitetura de CMEK

Ao projetar uma arquitetura de CMEK, considere a configuração das chaves que você 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 a destruição criptografada.

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

Usar um projeto de chave CMEK centralizado para cada ambiente

Recomendamos usar um projeto de chave CMEK centralizado para cada pasta de ambiente. Não crie recursos criptografados com CMEK no mesmo projeto em que você gerencia as 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 chave do Cloud KMS, e essas chaves são usadas para criptografar recursos nos projetos de aplicativo.
  • 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 recomendada de pastas e projetos do Cloud KMS

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

Criar keyrings do Cloud KMS para cada local

Crie keyrings do Cloud KMS nos locais em que você implanta recursos doGoogle Cloud criptografados com CMEK.

  • Os recursos regionais e zonais precisam usar um keyring e a CMEK na mesma região do recurso ou no local global. Recursos zonais e de região única não podem usar um keyring multirregional que não seja global.
  • Recursos multirregionais (como um conjunto de dados do BigQuery na multirregião us) precisam usar um keyring e a CMEK na mesma multirregião ou birregião. Recursos multirregionais não podem usar um keyring regional.
  • 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 keyrings e chaves em uma região definida, você também força que os recursos correspondam à região do keyring. Para orientações sobre residência de dados, consulte Controlar a residência 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 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 criptografar 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 dos recursos que você protege.

Escolher uma estratégia de granularidade de chave

A granularidade se refere à escala e ao escopo do uso pretendido de cada chave. Por 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 da criação de 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 criar chaves menos granulares para reutilização entre recursos de forma mais ampla.

Em geral, recomendamos a seguinte estratégia de granularidade:

  • Cada chave protege recursos em um único local, por exemplo, us-central1.
  • Cada chave protege recursos em um único serviço ou produto, por exemplo, o BigQuery.
  • Cada chave protege recursos em um único projeto Google Cloud .

Essa recomendação pode não ser a estratégia de granularidade ideal para sua organização. Para a maioria das organizações, essa estratégia oferece um bom equilíbrio entre o trabalho de manter muitas chaves altamente granulares e os riscos potenciais de usar chaves menos granulares compartilhadas entre muitos projetos, serviços ou recursos.

As chaves criadas com a chave automática do Cloud KMS seguem essa recomendação.

Se você quiser seguir uma estratégia de granularidade diferente, considere as seguintes compensações de padrões diferentes:

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

  • Mais controle para desativar versões de chave com segurança:desativar ou destruir uma versão de chave usada para um escopo limitado 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:usar chaves granulares exige a manutenção de mais versões de chaves ativas em comparação com uma estratégia que usa chaves com menor granularidade. 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ço administrativo ou ferramentas adicionais para automação, a fim de 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, o Autokey pode ser uma boa opção para automatizar o provisionamento. Para mais informações sobre a granularidade da chave Autokey de cada serviço, consulte Serviços compatíveis.

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

  • Exige cuidado para desativar 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. É preciso garantir que todos os recursos criptografados por essa versão de chave sejam criptografados novamente com segurança usando uma nova versão antes de desativar a versão antiga. Para muitos tipos de recursos, é possível ver o uso da chave e identificar onde ela 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:usar chaves menos granulares exige a criação de menos versões de chaves, e os preços do Cloud KMS são baseados no número de versões de chaves ativas.
  • Sobrecarga operacional:é possível definir e pré-provisionar 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 para chaves

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

  1. Você precisa de algum dos recursos da CMEK? Revise os recursos listados em Decidir se é necessário usar a CMEK nesta página.

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

  3. Você precisa que o material da chave seja armazenado fora de Google Cloud?

O Autokey só aceita o nível de proteção HSM. Se você precisar de outros níveis de proteção, provisione as chaves por conta própria.

Use material de chave gerado por Google 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 da chave ou importar manualmente o material da 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 de 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 e riscos operacionais de usar a abordagem BYOK:

  • Você pode implementar a automação para importar novas versões de chave de forma consistente? Isso inclui as configurações do Cloud KMS para restringir as versões de chaves apenas à importação e a automação fora do Cloud KMS para gerar e importar material de chave de maneira consistente. Qual é o impacto se a automação não criar uma nova versão da chave no horário esperado?
  • Como você pretende armazenar ou colocar em custódia o material de chave original com segurança?
  • Como mitigar o risco de o processo de importação de chaves vazar o material de chave bruta?
  • Qual seria o impacto de reimportar uma chave destruída anteriormente porque o material da chave bruta foi retido fora de Google Cloud?
  • O benefício de importar o material da chave justifica o aumento do overhead operacional e do risco?

Escolher a finalidade e o algoritmo certos para suas necessidades

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

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

Escolher um período de rotação

Recomendamos que você avalie o período adequado de rotação de chaves para suas necessidades. A frequência da rotação de chaves depende dos requisitos das suas cargas de trabalho com base na sensibilidade ou na 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 alternar uma chave simétrica, a nova versão é marcada como a versão chave primária e usada em todas as novas solicitações para proteger informações. As versões antigas da chave permanecem disponíveis para descriptografar dados criptografados anteriormente protegidos com essa versão. Quando você faz a rotação de uma chave, os dados que foram 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.

Se você usa o Autokey, as chaves são criadas com um período padrão de rotação de chaves 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 responsabilidades ao planejar controles de acesso. As seções a seguir apresentam essas recomendações.

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

Ao atribuir permissão 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. Recomendamos que você evite usar papéis básicos. Em vez disso, conceda papéis predefinidos do Cloud KMS para reduzir os riscos de incidentes de segurança relacionados ao acesso com privilégios excessivos.

As violações desse princípio e os 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 as chaves de criptografia. O NIST SP 800-152 define uma separação de responsabilidades 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 , a função do IAM para usar chaves de criptografia é atribuída 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 os papéis do IAM normalmente associados a cada função de trabalho:

Papel do IAM Descrição Designação NIST SP 800-152
roles/cloudkms.admin Concede acesso aos recursos do Cloud KMS, exceto aos tipos de recursos restritos e às 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 os problemas relacionados podem ser detectados automaticamente pelas descobertas de vulnerabilidade do Security Command para o Cloud KMS.

Aplicar a CMEK de forma consistente

As seções a seguir descrevem controles adicionais 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 os projetos com garantias para evitar exclusões acidentais. Quando uma garantia de projeto é aplicada, o projeto da chave do Cloud KMS fica bloqueado para exclusão até que a garantia seja removida.

Exigir chaves CMEK

Recomendamos que você aplique o uso da 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 uma duração mínima programada para destruição

Recomendamos que você defina uma duração mínima programada para destruição. A destruição de chaves é uma operação irreversível que pode resultar em perda de dados. Por padrão, o Cloud KMS usa uma duração programada para destruição (às vezes chamada de período de exclusão reversível) de 30 dias antes que o material da chave seja destruído de forma irrecuperável. Isso dá 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 programada para destruição de apenas 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 a criação da chave.

Enquanto uma chave está programada para destruição, ela não pode ser usada para operações criptográficas, e todas as solicitações para usar a chave falham. 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, restaure antes do fim do período programado para destruição.

Para garantir que todas as chaves criadas sigam uma duração mínima programada para destruição, recomendamos que você configure a restrição da 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 programada para destruição menor que o valor especificado na política.

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

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

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

Configurar controles de detetive para CMEKs

OGoogle Cloud oferece vários controles de detetive para CMEKs. As seções a seguir explicam como ativar e usar esses controles relevantes para o Cloud KMS.

Ativar e agregar registros de auditoria

Recomendamos agregar 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 um auditor analise de uma só vez toda a atividade relacionada à criação ou modificação de recursos do Cloud KMS. Para orientações sobre como configurar coletores de registros agregados, consulte agregar e armazenar os registros da sua organização.

Se quiser, ative os registros de acesso a dados para registrar operações que usam as chaves, incluindo operações de criptografia e descriptografia. Ao usar CMEKs, isso pode gerar um volume substancial de registros 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 os custos de geração de registros vão aumentar.

Monitorar o uso da chave

É possível ver o uso de chaves com a API de inventário do Cloud KMS para ajudar a identificar recursos Google Cloud na sua organização que dependem de chaves do Cloud KMS e são protegidos por elas. Esse painel pode ser usado para monitorar o estado, o uso e a disponibilidade das versões de chave 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.

Você pode usar o Cloud Monitoring com o Cloud KMS para definir alertas de eventos críticos, como o agendamento de uma chave para destruição. O Cloud Monitoring permite triar o motivo de uma operação ter sido realizada e acionar um processo downstream opcional para restaurar a chave, se necessário.

Recomendamos que você estabeleça um plano operacional para detectar automaticamente eventos que 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 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 atuais. 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 funções.

Avaliar seus requisitos de compliance

Cada estrutura de conformidade tem requisitos diferentes para criptografia e gerenciamento de chaves. Uma estrutura de compliance geralmente descreve os princípios e objetivos de alto nível do gerenciamento de chaves de criptografia, mas não é prescritiva sobre o produto ou a configuração específica que atinge a conformidade. É sua responsabilidade entender os requisitos da sua estrutura de conformidade e como seus controles, incluindo o gerenciamento de chaves, podem atender a esses requisitos.

Para saber como os serviços do Google Cloud podem ajudar a atender aos requisitos de diferentes estruturas 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 precisar de alguma das capacidades ativadas por ela.
Escolher a criação manual ou automatizada de chaves Use a chave automática do Cloud KMS se as características das chaves criadas por ela 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 que os recursos do Google Cloudque as chaves protegem.
Keyrings do Cloud KMS Crie keyrings do Cloud KMS para cada local em que você quer proteger os recursos Google Cloud.
Granularidade da chave Escolha um padrão de granularidade de chave que atenda às suas necessidades ou use o Autokey para provisionar chaves automaticamente na 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) de propriedade do Google Cloud. Escolha chaves de software se suas necessidades não exigirem o Cloud HSM ou o Cloud EKM. Confira as orientações para selecionar um nível de proteção.
Material da chave Para material de chave hospedado em Google Cloud, use material de chave gerado por Google Cloudsempre 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 alternadas 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 uma rotação de chaves mais frequente para cargas de trabalho sensíveis.
Privilégio mínimo Conceda os papéis predefinidos mais limitados que permitam que seus principais concluam as tarefas. Não use papéis básicos.
Separação de tarefas Mantenha permissões separadas para administradores principais e principais que usam chaves.
Garantias do 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 uma duração mínima programada para destruição Use a restrição constraints/cloudkms.minimumDestroyScheduledDuration.
Aplicar níveis de proteção permitidos para CMEKs Use a restrição constraints/cloudkms.allowedProtectionLevels.
Ativar e agregar registros de auditoria Agregue registros de auditoria de atividade administrativa para todos os recursos da sua organização. Considere se você quer ativar o registro em log de operações usando chaves.
Monitorar o uso da chave Use a API Cloud KMS Inventory ou o console Google Cloud para entender o uso das chaves. Se quiser, use o Cloud Monitoring para definir alertas de operações sensíveis, como programar a destruição de uma chave.
Ativar o Security Command Center para o Cloud KMS Analise as descobertas de vulnerabilidade e integre essa análise à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

  • Saiba como o Cloud KMS Autokey reduz seu esforço para usar a CMEK de forma consistente.