Práticas recomendadas para usar CMEKs

Esta página descreve as práticas recomendadas para configurar a encriptação em repouso com chaves de encriptação geridas pelo cliente (CMEKs) nos seus Google Cloud recursos. Este guia destina-se a arquitetos da nuvem e equipas de segurança, e descreve as práticas recomendadas e as decisões que tem de tomar enquanto cria a sua arquitetura de CMEK.

Este guia pressupõe que já conhece o Cloud Key Management Service (Cloud KMS) e as chaves de encriptação geridas pelo cliente e que leu a análise detalhada do Cloud KMS.

Decisões preliminares

As recomendações nesta página destinam-se a clientes que usam CMEKs para encriptar os respetivos dados. Se não tiver a certeza se deve usar CMEKs criadas manual ou automaticamente como parte da sua estratégia de segurança, esta secção fornece orientações para estas decisões preliminares.

Decida se quer usar as CMEK

Recomendamos que use CMEK para encriptar dados em repouso nos serviços Google Cloud se precisar de alguma das seguintes capacidades:

  • Seja proprietário das suas chaves de encriptação.

  • Controlar e gerir as suas chaves de encriptação, incluindo a escolha da localização, o nível de proteção, a criação, o controlo de acesso, a rotação, a utilização e a destruição.

  • Gerar material de chaves no Cloud KMS ou importar material de chaves que é mantido fora do Google Cloud.

  • Defina a política relativamente ao local onde as chaves têm de ser usadas.

  • Eliminar seletivamente dados protegidos pelas suas chaves em caso de desvinculação ou para corrigir eventos de segurança (destruição criptográfica).

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

  • Registe o acesso administrativo e aos dados às chaves de encriptação.

  • Cumprir os regulamentos atuais ou futuros que exijam qualquer um destes objetivos.

Se não precisar destas capacidades, avalie se a encriptação predefinida em repouso com Google-owned and managed keys é adequada para o seu exemplo de utilização. Se optar por usar apenas a encriptação predefinida, pode parar de ler este guia.

Escolha a criação de chaves manual ou automática

Este guia descreve as práticas recomendadas para as decisões que tem de tomar quando aprovisiona as CMEKs por si próprio. A chave automática do Cloud KMS toma algumas destas decisões por si e automatiza muitas recomendações deste guia. A utilização da Autokey é mais simples do que o aprovisionamento manual de chaves e é a opção recomendada se as chaves criadas pela Autokey cumprirem todos os seus requisitos.

O Autokey aprovisiona CMEKs por si. As CMEKs aprovisionadas pela Autokey têm as seguintes caraterísticas:

  • Nível de proteção: HSM.
  • Algoritmo: AES-256 GCM.
  • Período de rotação: um ano.

    Depois de uma chave ser criada pelo Autokey, um administrador do Cloud KMS pode editar o período de rotação a partir do predefinido.

  • Separação de funções:
    • A conta de serviço do serviço recebe automaticamente autorizações de encriptação e desencriptação na chave.
    • As autorizações de administrador do Cloud KMS aplicam-se como habitualmente às chaves criadas pela Autokey. Os administradores do Cloud KMS podem ver, atualizar, ativar ou desativar e destruir chaves criadas pela chave automática. Os administradores do Cloud KMS não têm autorizações de encriptação e desencriptação.
    • Os programadores da chave automática só podem pedir a criação e a atribuição de chaves. Não pode ver nem gerir chaves.
  • Especificidade ou granularidade das chaves: as chaves criadas pelo Autokey têm uma granularidade que varia consoante o tipo de recurso. Para ver detalhes específicos do serviço acerca da granularidade das chaves, consulte o artigo Serviços compatíveis.
  • Localização: o Autokey cria chaves na mesma localização que o recurso a proteger.

    Se precisar de criar recursos protegidos por CMEK em localizações onde o Cloud HSM não está disponível, tem de criar a CMEK manualmente.

  • Estado da versão da chave: as chaves criadas recentemente pedidas através da chave automática são criadas como a versão da chave principal no estado ativado.
  • Nomenclatura do conjunto de chaves: todas as chaves criadas pelo Autokey são criadas num conjunto de chaves denominado autokey no projeto do Autokey na localização selecionada. Os porta-chaves no seu projeto do Autokey são criados quando um programador do Autokey pede a primeira chave numa determinada localização.
  • Nomenclatura das chaves: as chaves criadas pela Autokey seguem esta convenção de nomenclatura: PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX
  • Exportação de chaves: tal como todas as chaves do Cloud KMS, não é possível exportar as chaves criadas pelo Autokey.
  • Monitorização de chaves: tal como todas as chaves do Cloud KMS usadas em serviços integrados de CMEK compatíveis com a monitorização de chaves, as chaves criadas pela Autokey são monitorizadas no painel de controlo do Cloud KMS.

Se tiver requisitos que não podem ser cumpridos 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 que use CMEKs criadas manualmente em vez da chave automática.

Crie a sua arquitetura de CMEK

Ao criar uma arquitetura de CMEK, tem de considerar a configuração das chaves que vai usar e como estas chaves são geridas. Estas decisões influenciam o seu custo, custos gerais operacionais e facilidade de implementação de capacidades como a eliminação de dados criptografados.

As secções seguintes abordam as recomendações para cada escolha de design.

Use um projeto de chave CMEK centralizado para cada ambiente

Recomendamos que use um projeto de chave CMEK centralizado para cada pasta de ambiente. Não crie recursos encriptados com CMEK no mesmo projeto onde gere as chaves do Cloud KMS. Esta abordagem ajuda a evitar a partilha de chaves de encriptação entre ambientes e ajuda a ativar a separação de funções.

O diagrama seguinte ilustra estes conceitos no design recomendado:

  • Cada pasta de ambiente tem um projeto de chave do Cloud KMS administrado separadamente dos projetos de aplicação.
  • Os conjuntos de chaves e as chaves do Cloud KMS são aprovisionados no projeto de chaves do Cloud KMS, e estas chaves são usadas para encriptar recursos nos projetos de aplicações.
  • As políticas de gestão de identidade e de acesso (IAM) são aplicadas a projetos ou pastas para permitir a separação de funções. O principal que gere as chaves do Cloud KMS no projeto de chaves do Cloud KMS não é o mesmo principal que usa as chaves de encriptação nos projetos de aplicações.

Estrutura de projeto e pasta do Cloud KMS recomendada

Se usar a chave automática do Cloud KMS, cada pasta para a qual a chave automática está ativada tem de ter um projeto de chave do Cloud KMS dedicado.

Crie conjuntos de chaves do Cloud KMS para cada localização

Tem de criar conjuntos de chaves do Cloud KMS nas localizações onde implementa Google Cloud recursos encriptados com CMEK.

  • Os recursos regionais e zonais têm de usar um anel de chaves e uma CMEK na mesma região que o recurso ou na localização global. Os recursos zonais e de região única não podem usar um anel de chaves multirregional que não seja global.
  • Os recursos multirregionais (como um conjunto de dados do BigQuery na região multirregional) têm de usar um anel de chaves e a CMEK na mesma região multirregional ou região dupla.us Os recursos multirregionais não podem usar um conjunto de chaves regionais.
  • Os recursos globais têm de usar um conjunto de chaves e CMEK na localização global.

A aplicação de chaves regionais é um elemento de uma estratégia de regionalização de dados. Ao aplicar a utilização de conjuntos de chaves e chaves numa região definida, também aplica que os recursos têm de corresponder à região do conjunto de chaves. Para orientações sobre a residência dos dados, consulte o artigo Controle a residência dos dados.

Para cargas de trabalho que requerem capacidades de alta disponibilidade ou recuperação de desastres em várias localizações, é da sua responsabilidade avaliar se a sua carga de trabalho é resiliente no caso de o Cloud KMS ficar indisponível numa determinada região. Por exemplo, não é possível recriar um disco persistente do Compute Engine encriptado com uma chave do Cloud KMS da região A na região B num cenário de recuperação de desastres em que a região A esteja indisponível. Para mitigar o risco deste cenário, pode planear a encriptação de um recurso com chaves global.

Para mais informações, consulte o artigo Escolher o melhor tipo de localização.

Se usar a chave automática do Cloud KMS, os conjuntos de chaves são criados para si na mesma localização que os recursos que protege.

Escolha uma estratégia de nível de detalhe das chaves

A granularidade refere-se à escala e ao âmbito da utilização pretendida de cada chave. Por exemplo, diz-se que uma chave que protege vários recursos é menos detalhada do que uma chave que protege apenas um recurso.

As chaves do Cloud KMS aprovisionadas manualmente para a CMEK têm de ser aprovisionadas antecipadamente antes de criar um recurso que vai ser encriptado com a chave, como um disco persistente do Compute Engine. Pode optar por criar chaves muito detalhadas para recursos individuais ou criar chaves menos detalhadas para reutilização entre recursos de forma mais abrangente.

Embora não exista um padrão universalmente correto, considere as seguintes compromissos de diferentes padrões:

Chaves de elevada granularidade, por exemplo, uma chave para cada recurso individual

  • Maior controlo para desativar versões de chaves em segurança: desativar ou destruir uma versão de chave usada para um âmbito restrito tem um risco menor de afetar outros recursos do que desativar ou destruir uma chave partilhada. Isto também significa que a utilização de chaves altamente detalhadas ajuda a reduzir o potencial impacto da violação de uma chave em comparação com a utilização de chaves pouco detalhadas.
  • Custo: a utilização de chaves detalhadas requer a manutenção de mais versões de chaves ativas em comparação com uma estratégia que usa chaves com menor detalhe. Uma vez que os preços do Cloud KMS se baseiam no número de versões de chaves ativas, a escolha de uma granularidade de chaves mais elevada resulta em custos mais elevados.
  • Sobrecarga operacional: a utilização de chaves altamente detalhadas pode exigir esforços administrativos ou ferramentas adicionais para a automatização de forma a aprovisionar um grande número de recursos do Cloud KMS e gerir os controlos de acesso para os agentes de serviço, para que só possam usar as chaves adequadas. Se precisar de chaves com elevada granularidade, a Autokey pode ser uma boa escolha para automatizar o aprovisionamento. Para mais informações sobre a granularidade das chaves do Autokey para cada serviço, consulte Serviços compatíveis.

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

  • Requer cuidado para desativar versões de chaves em segurança: a desativação ou a destruição de uma versão de chave usada para um âmbito alargado requer mais cuidado do que a desativação ou a destruição de uma chave altamente detalhada. Tem de garantir que todos os recursos encriptados por essa versão da chave são novamente encriptados em segurança com uma nova versão da chave antes de desativar a versão antiga da chave. Para muitos tipos de recursos, pode ver a utilização de chaves para ajudar a identificar onde uma chave foi usada. Isto também significa que a utilização de chaves de baixa granularidade pode aumentar o potencial impacto da comprometimento de uma chave em comparação com a utilização de chaves de alta granularidade.
  • Custo: a utilização de chaves menos detalhadas requer a criação de menos versões de chaves, e o preço do Cloud KMS baseia-se no número de versões de chaves ativas.
  • Custos operacionais: pode definir e aprovisionar previamente um número conhecido de chaves, com menos esforço necessário para garantir os controlos de acesso adequados.

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

Quando cria uma chave, é da 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 encriptados com a CMEK. As seguintes perguntas podem ajudar na sua avaliação:

  1. Precisa de alguma das capacidades das CMEK? Pode rever as capacidades indicadas em Decida se deve usar as CMEK nesta página.

  2. Precisa que o seu material de chaves permaneça dentro do limite físico de um módulo de segurança de hardware (HSM)?

  3. Exige que o material da chave seja armazenado fora do Google Cloud?

O Autokey suporta apenas o nível de proteção HSM. Se precisar de outros níveis de proteção, tem de aprovisionar as chaves por si mesmo.

Use material de chaves gerado pela Google Cloudsempre que possível

Esta secção não se aplica a chaves do Cloud EKM.

Quando cria uma chave, tem de permitir que o Cloud KMS gere o material da chave por si ou importar manualmente o material da chave gerado fora do Google Cloud. Sempre que possível, recomendamos que escolha a opção gerada. Esta opção não expõe o material da chave não processado fora do Cloud KMS e cria automaticamente novas versões da chave com base no período de alternância de chaves que escolher. Se precisar da opção para importar o seu próprio material de chaves, recomendamos que avalie as seguintes considerações operacionais e riscos de usar a abordagem de trazer a sua própria chave (BYOK):

  • Consegue implementar a automatização para importar consistentemente novas versões de chaves? Isto inclui as definições do Cloud KMS para restringir as versões das chaves apenas para importação e a automatização fora do Cloud KMS para gerar e importar consistentemente material de chaves. Qual é o impacto se a automatização não criar uma nova versão da chave no momento esperado?
  • Como tenciona armazenar ou manter em depósito o material de chaves original de forma segura?
  • Como pode mitigar o risco de o seu processo de importação de chaves divulgar o material da chave não processado?
  • Qual seria o impacto de reimportar uma chave destruída anteriormente porque o material da chave não processado foi retido fora do Google Cloud?
  • A vantagem de importar o material essencial justifica o aumento dos custos operacionais e do risco?

Escolha o objetivo principal e o algoritmo certos para as suas necessidades

Quando cria uma chave, tem de selecionar a finalidade e o algoritmo subjacente da chave. Para exemplos de utilização de CMEK, só é possível usar chaves com o objetivo simétrico ENCRYPT_DECRYPT. Esta finalidade da chave usa sempre o algoritmo GOOGLE_SYMMETRIC_ENCRYPTION, que usa chaves do Advanced Encryption Standard (AES-256) de 256 bits no modo de contador de Galois (GCM), com preenchimento de metadados internos do Cloud KMS. Quando usa a chave automática, estas definições são aplicadas automaticamente.

Para outros exemplos de utilização, como a encriptação por parte do cliente, reveja os objetivos e algoritmos disponíveis para escolher a opção mais adequada ao seu exemplo de utilização.

Escolha um período de rotação

Recomendamos que avalie o período de rotação de chaves adequado às 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 cumprir determinadas normas de conformidade ou pode optar por um período de rotação mais frequente para cargas de trabalho altamente confidenciais.

Após a rotação de uma chave simétrica, a nova versão é marcada como a versão da chave principal e é usada para todos os novos pedidos de proteção de informações. As versões antigas das chaves permanecem disponíveis para utilização na desencriptação de dados encriptados anteriormente protegidos com essa versão. Quando alterna uma chave, os dados que foram encriptados com versões anteriores da chave não são automaticamente reencriptados.

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

Se usar a chave automática, as chaves são criadas com um período de rotação predefinido de um ano. Pode alterar o período de rotação das chaves depois de as criar.

Aplique controlos de acesso adequados

Recomendamos que tenha em consideração os princípios do menor privilégio e da separação de funções ao planear os controlos de acesso. As secções seguintes apresentam estas recomendações.

Aplique o princípio do menor privilégio

Ao atribuir autorização para gerir CMEKs, considere o princípio do menor privilégio e conceda as autorizações mínimas necessárias para realizar uma tarefa. Recomendamos vivamente que evite usar funções básicas. Em alternativa, conceda funções predefinidas do Cloud KMS para mitigar os riscos de incidentes de segurança relacionados com o acesso com privilégios excessivos.

As violações deste princípio e os problemas relacionados podem ser detetados automaticamente pelas conclusões de vulnerabilidades do Security Command Center para o IAM.

Planeie a separação de funções

Manter identidades e autorizações separadas para quem administra as suas chaves de encriptação e quem as usa. A norma NIST SP 800-152 define uma separação de funções entre o responsável pela criptografia que ativa e gere os serviços de um sistema de gestão de chaves criptográficas e um utilizador que usa essas chaves para encriptar ou desencriptar recursos.

Quando usa a CMEK para gerir a encriptação em repouso com os Google Cloud serviços, a função de IAM para usar chaves de encriptação é atribuída ao agente do serviço do serviço Google Cloud , e não ao utilizador individual. Por exemplo, para criar objetos num contentor do Cloud Storage encriptado, um utilizador só precisa da função de 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 da função de IAM roles/cloudkms.cryptoKeyEncrypterDecrypter.

A tabela seguinte indica as funções do IAM normalmente associadas a cada função profissional:

Função de IAM Descrição Designação NIST SP 800-152
roles/cloudkms.admin Fornece acesso aos recursos do Cloud KMS, exceto acesso a tipos de recursos restritos e operações criptográficas. Responsável pela criptografia
roles/cloudkms.cryptoKeyEncrypterDecrypter Oferece a capacidade de usar recursos do Cloud KMS apenas para operações de encrypt e decrypt. Utilizador do sistema de gestão de chaves criptográficas
roles/cloudkms.viewer Ativa as operações get e list. Administrador de auditorias
As violações deste princípio e os problemas relacionados podem ser detetados automaticamente pelas conclusões de vulnerabilidades do Security Command Center para o Cloud KMS.

Aplique as CMEK de forma consistente

As secções seguintes descrevem controlos adicionais para ajudar a mitigar riscos, como a utilização inconsistente de chaves ou a eliminação ou a destruição acidental.

Aplique hipotecas sobre projetos

Recomendamos que proteja os projetos com bloqueios para evitar a eliminação acidental. Quando é aplicada uma restrição de projeto, o projeto da chave do Cloud KMS fica bloqueado para eliminação até que a restrição seja removida.

Exija chaves CMEK

Recomendamos que aplique a utilização da CMEK em todo o seu ambiente através de restrições da política da organização.

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

Exigir uma duração mínima agendada para destruição

Recomendamos que defina uma duração mínima agendada para destruição. A destruição de chaves é uma operação irreversível que pode resultar na perda de dados. Por predefinição, o Cloud KMS usa uma duração agendada para destruição (por vezes, denominada período de eliminação temporária) de 30 dias antes de o material da chave ser destruído de forma irrecuperável. Isto 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 agendada para destruição de apenas 24 horas, o que pode não ser tempo suficiente para detetar um problema e restaurar a chave. A duração agendada para destruição só pode ser definida durante a criação da chave.

Enquanto uma chave estiver agendada para destruição, não pode ser usada para operações criptográficas e todos os pedidos para usar a chave falham. Durante este período, monitorize os registos de auditoria para verificar se a chave não está em utilização. Se quiser usar a chave novamente, tem de a restaurar antes do fim do período agendado para destruição.

Para garantir que todas as chaves criadas cumprem uma duração mínima agendada para destruição, recomendamos que configure a restrição da política da organização constraints/cloudkms.minimumDestroyScheduledDuration com um mínimo de 30 dias ou a duração que preferir. Esta política da organização impede que os utilizadores criem chaves com uma duração agendada para destruição inferior ao valor especificado na política.

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

Recomendamos que aplique os seus requisitos para níveis de proteção de chaves de forma consistente no seu ambiente através de restrições da política da organização.

Use constraints/cloudkms.allowedProtectionLevels para aplicar que as novas chaves, versões de chaves e tarefas de importação têm de usar os níveis de proteção que permite.

Configure controlos de deteção para CMEKs

Google Cloud oferece vários controlos de deteção para CMEKs. As secções seguintes apresentam como ativar e usar estes controlos relevantes para o Cloud KMS.

Ative e agregue o registo de auditoria

Recomendamos que agregue os registos de auditoria da atividade do administrador do Cloud KMS (juntamente com os registos de atividade do administrador para todos os serviços) numa localização centralizada para todos os recursos na sua organização. Isto permite que uma equipa de segurança ou um auditor reveja toda a atividade relacionada com a criação ou a modificação de recursos do Cloud KMS de uma só vez. Para orientações sobre a configuração de sinks de registo agregados, consulte o artigo Agregue e armazene os registos da sua organização.

Opcionalmente, pode ativar os registos de acesso aos dados para registar operações que usam as chaves, incluindo operações de encriptação e desencriptação. Quando usa CMEKs, isto pode gerar um volume de registos substancial e afetar os seus custos, porque cada operação de cada serviço que usa CMEKs cria registos de acesso aos dados. Antes de ativar os registos de acesso aos dados, recomendamos que defina um exemplo de utilização claro para os registos adicionais e avalie como os custos de registo vão aumentar.

Monitorize a utilização de chaves

Pode ver a utilização de chaves com a API Cloud KMS Inventory para ajudar a identificar os recursos na sua organização que dependem das chaves do Cloud KMS e estão protegidos por estas. Google Cloud Este painel de controlo pode ser usado para monitorizar o estado, a utilização e a disponibilidade das suas versões de chaves e dos recursos correspondentes que protegem. O painel de controlo também identifica dados inacessíveis devido a uma chave desativada ou destruída, para que possa tomar medidas, como limpar os dados inacessíveis ou reativar a chave.

Pode usar o Cloud Monitoring com o Cloud KMS para definir alertas para eventos críticos, como agendar uma chave para destruição. O Cloud Monitoring dá-lhe a oportunidade de avaliar o motivo pelo qual essa operação foi realizada e acionar um processo a jusante opcional para restaurar a chave, se necessário.

Recomendamos que estabeleça um plano operacional para detetar automaticamente eventos que considere importantes e reveja periodicamente o painel de controlo de utilização principal.

Ative o Security Command Center para resultados de vulnerabilidades do Cloud KMS

O Security Command Center gera resultados de vulnerabilidades que realçam erros de configuração associados ao Cloud KMS e a outros recursos. Recomendamos que ative o Security Command Center e integre estas descobertas nas suas operações de segurança existentes. Estas conclusões incluem problemas como chaves do Cloud KMS acessíveis publicamente, projetos do Cloud KMS com a função owner demasiado permissiva ou funções da IAM que violam a separação de funções.

Avalie os seus requisitos de conformidade

Diferentes estruturas de conformidade têm diferentes requisitos para a encriptação e a gestão de chaves. Normalmente, uma estrutura de conformidade descreve os princípios e os objetivos de alto nível da gestão de chaves de encriptação, mas não é prescritiva sobre o produto ou a configuração específicos que alcançam a conformidade. É da sua responsabilidade compreender os requisitos da sua estrutura de conformidade e como os seus controlos, incluindo a gestão de chaves, podem cumprir esses requisitos.

Para orientações sobre como os serviços Google Cloud podem ajudar a cumprir os requisitos de diferentes estruturas de conformidade, consulte os seguintes recursos:

Resumo das práticas recomendadas

A tabela seguinte resume as práticas recomendadas neste documento:

Tópico Tarefa
Decida se quer usar as CMEK Use as CMEK se precisar de alguma das capacidades ativadas pelas CMEK.
Escolha a criação de chaves manual ou automática Use a chave automática do Cloud KMS se as características das chaves criadas pela chave automática satisfizerem as 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 que as chaves protegem. Google Cloud
Conjuntos de chaves do Cloud KMS Crie conjuntos de chaves do Cloud KMS para cada localização onde quer proteger Google Cloud recursos.
Nível de detalhe da chave Escolha um padrão de granularidade das chaves que satisfaça as suas necessidades ou use a chave automática para aprovisionar automaticamente chaves na granularidade recomendada para cada serviço.
Nível de proteção Escolha o Cloud EKM se o seu material de chaves tiver de ser armazenado fora do Google Cloud. Escolha o Cloud HSM se o seu material de chaves puder ser alojado em módulos de segurança de hardware (HSMs) pertencentes à Google. Google CloudEscolha chaves de software se as suas necessidades não exigirem o Cloud HSM nem o Cloud EKM. Reveja as orientações para selecionar um nível de proteção.
Material da chave Para material de chaves alojado em Google Cloud, use material de chaves gerado por Google Cloudsempre que possível. Se usar material de chaves importado, implemente a automatização e os procedimentos para mitigar os riscos.
Objetivo e algoritmo principais Todas as chaves CMEK têm de usar o objetivo da chave ENCRYPT_DECRYPT simétrica e o algoritmo GOOGLE_SYMMETRIC_ENCRYPTION.
Período de rotação Use a rotação automática de chaves para garantir que as chaves são rodadas de acordo com um horário. Escolha e aplique um período de rotação que satisfaça as suas necessidades, idealmente, pelo menos, uma vez por ano. Use uma rotação de chaves mais frequente para cargas de trabalho sensíveis.
Menor privilégio Conceda as funções predefinidas mais limitadas que permitam aos seus principais concluir as respetivas tarefas. Não use funções básicas.
Separação de funções Manter autorizações separadas para os administradores principais e os responsáveis que usam chaves.
Hipoteca de projetos Use restrições de projetos para evitar a eliminação acidental dos seus projetos de chaves.
Exija CMEKs Use a restrição constraints/gcp.restrictNonCmekServices.
Exigir uma duração mínima agendada para destruição Use a restrição constraints/cloudkms.minimumDestroyScheduledDuration.
Aplique níveis de proteção permitidos para CMEKs Use a restrição constraints/cloudkms.allowedProtectionLevels.
Ative e agregue o registo de auditoria Agregue registos de auditoria de atividade administrativa para todos os recursos na sua organização. Considere se quer ativar o registo de operações com chaves.
Monitorize a utilização de chaves Use a API Cloud KMS Inventory ou a Google Cloud consola para compreender a utilização das chaves. Opcionalmente, use o Cloud Monitoring para definir alertas para operações confidenciais, como agendar a destruição de uma chave.
Ative o Security Command Center para o Cloud KMS Reveja as conclusões de vulnerabilidades e integre a revisão das conclusões de vulnerabilidades nas suas operações de segurança.
Avalie os requisitos de conformidade Reveja a sua arquitetura do Cloud KMS e compare-a com os requisitos de conformidade aos quais tem de aderir.

O que se segue?