Nesta página, descrevemos as práticas recomendadas para configurar a criptografia em repouso com chaves de criptografia gerenciadas pelo cliente (CMEK) nos seus recursos do Cloud de Confiance . Este guia é destinado a arquitetos de nuvem e equipes de segurança e descreve práticas e decisões recomendadas que você precisa tomar ao projetar sua arquitetura de CMEK.
Este guia considera que você já conhece o Cloud Key Management Service (Cloud KMS) e as chaves de criptografia gerenciadas pelo cliente.Escolher onde usar a CMEK
O Google recomenda o uso de chaves de criptografia gerenciadas pelo cliente quando você quer um limite criptográfico em torno dos seus dados ou dos dados dos seus clientes na nuvem. Para mais informações, consulte Chaves de criptografia gerenciadas pelo cliente (CMEK).
É possível usar CMEKs em serviços compatíveis para ajudar a implementar as seguintes metas:Tenha 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 Cloud de Confiance.
Defina uma política sobre onde suas chaves precisam ser usadas.
Excluir seletivamente os dados protegidos pelas chaves em caso de desativação ou para corrigir eventos de segurança (destruição criptográfica).
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.
O Google também recomenda que você considere as estruturas de compliance aplicáveis às necessidades da sua empresa. Diferentes estruturas de compliance têm requisitos diferentes para criptografia e gerenciamento de chaves. Normalmente, uma estrutura de compliance 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 ajudar você a atender a esses requisitos.
Para orientação sobre como os serviços do Cloud de Confiance podem ajudar a atender aos requisitos de diferentes estruturas de compliance, consulte os seguintes recursos:
Escolher a origem do material de chave
Ao criar uma chave, você precisa permitir que o Cloud KMS gere o material de chave ou importar manualmente o material de chave gerado fora de Cloud de Confiance. Sempre que possível, recomendamos que você gere material de chaves no Cloud KMS. Essa opção não corre o risco de expor o material da chave bruta fora do Cloud KMS e cria automaticamente novas versões de chave com base no período de rotação de chaves que você escolher. Se você precisar importar seu próprio material de chaves, 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 chave de forma consistente? Isso inclui as configurações do Cloud KMS para restringir versões de chaves apenas para importação e a automação fora do Cloud KMS para gerar e importar material de chaves de maneira consistente. Qual é o impacto se a automação não criar uma nova versão de chave no momento esperado?
Como você pretende armazenar ou fazer a custódia do material de chave original com segurança?
Como mitigar o risco de o processo de importação da chave vazar o material da chave bruta?
Qual seria o impacto de reimportar uma chave destruída anteriormente porque o material da chave bruta foi retido fora de Cloud de Confiance?
O benefício de importar o material da chave justifica o aumento do overhead operacional e do risco?
Escolher os modelos de governança e armazenamento de chaves
Ao projetar sua arquitetura de CMEK, você precisa decidir onde e como as chaves serão gerenciadas. O ideal é escolher um modelo de governança e um modelo de armazenamento de chaves que se alinhem. O modelo de governança e o modelo de armazenamento escolhidos influenciam configurações importantes, como a aplicação da separação de funções.
Governança de chaves
A governança de chaves descreve quem em uma organização é responsável por gerenciar o ciclo de vida dos recursos do Cloud KMS e manter mecanismos de proteção para controlar como o Cloud KMS é usado. As principais abordagens de governança existem em um espectro que vai da governança centralizada à governança delegada:
- Governança centralizada: uma equipe dedicada de segurança ou plataforma é responsável por gerenciar o ciclo de vida de todas as chaves criptográficas na organização. Esse modelo geralmente é escolhido por empresas altamente regulamentadas com requisitos de compliance rigorosos.
- Governança delegada: uma equipe central de segurança usa mecanismos de proteção para exigir padrões de criptografia, mas delega a responsabilidade pelas operações do ciclo de vida das chaves aos proprietários de aplicativos nos projetos. Esses mecanismos podem incluir políticas da organização usando restrições gerenciadas e personalizadas, além de concessões e políticas de negação do IAM. Isso elimina gargalos operacionais centrais.
Armazenamento de chaves
O armazenamento de chaves descreve onde os recursos do Cloud KMS são criados em uma organização. Há duas abordagens principais para o armazenamento de chaves: armazenamento de chaves em projeto dedicado e armazenamento de chaves no mesmo projeto.
Armazenamento de chaves em projeto dedicado: um projeto de chaves dedicado contém chaves usadas para vários aplicativos. Normalmente, cada pasta de ambiente tem um projeto de chave próprio. É possível usar o Autokey com o armazenamento de chaves em projeto dedicado. Para mais informações sobre o modelo de armazenamento de chaves de projeto dedicado, consulte Armazenamento de chaves de projeto dedicado.
Armazenamento de chaves no mesmo projeto: as chaves são armazenadas no mesmo projetoCloud de Confiance que os recursos protegidos. Às vezes, isso é descrito como "a chave segue os dados". É possível usar o Autokey com armazenamento de chaves no mesmo projeto. Para mais informações sobre o modelo de armazenamento de chaves no mesmo projeto, consulte Armazenamento de chaves no mesmo projeto.
Alinhar governança e armazenamento
A matriz a seguir mostra exemplos de como esses modelos de governança e armazenamento podem ser combinados para atender a diferentes necessidades da organização:
| Modelo de governança | Armazenamento de chaves em projeto dedicado | Armazenamento de chaves no mesmo projeto |
|---|---|---|
| Governança centralizada | Abordagem totalmente centralizada Uso recomendado: organizações com requisitos regulamentares rígidos que exigem isolamento de limites de projetos. Impacto operacional: alta complexidade de configuração. Exige automação robusta (como uma "fábrica de projetos") para evitar atrasos operacionais para equipes de desenvolvimento. |
Propriedade gerenciada Uso recomendado: organizações que precisam de supervisão central de segurança, mas querem maximizar a velocidade dos desenvolvedores. Impacto operacional: baixa complexidade de configuração. A segurança centralizada aplica a política usando proteções, enquanto as chaves são colocadas junto aos recursos que protegem para facilitar o gerenciamento. |
| Governança delegada | Não recomendado A introdução da complexidade do IAM entre projetos prejudica o objetivo de delegar o gerenciamento de chaves às equipes de aplicativos. |
DevOps autônomo Uso recomendado: organizações descentralizadas de alta velocidade com uma cultura de DevOps forte. Impacto operacional: complexidade mínima de configuração. As equipes de aplicativos têm autonomia total sobre recursos e chaves dentro dos limites do projeto. |
Use uma arquitetura consistente em todos os ambientes
Recomendamos que você use o mesmo padrão de armazenamento de chaves em todos os ambientes de desenvolvimento, teste e produção de um determinado aplicativo. Essa consistência arquitetônica ajuda a garantir que suas permissões do IAM, pipelines de implantação e controles de segurança sejam testados minuciosamente em ambientes inferiores antes de serem implantados na produção. Se você escolher arquiteturas diferentes para seus ambientes, vai introduzir o risco de desvio de configuração que pode causar falhas de implantação.
Armazenamento de chaves em projeto dedicado
Em um modelo de armazenamento de chaves em projeto dedicado, todas as chaves de uma pasta de ambiente específica (por exemplo, "Production") são armazenadas em um projeto de chave centralizado e compartilhado. As permissões de gerenciamento de chaves são concedidas a uma equipe de segurança compartilhada, que geralmente também gerencia operações e controles de ciclo de vida de chaves, como políticas da organização da CMEK e concessões de papéis e políticas do IAM.
Caso de uso
Recomendamos usar o modelo de armazenamento de chaves de projeto dedicado se sua organização priorizar o controle estrito e centralizado sobre as chaves de criptografia, geralmente motivado por requisitos regulamentares, ou quando as chaves são hospedadas em um HSM externo.
Se sua organização estiver sujeita a uma estrutura de compliance que exija um oficial de criptografia ou um custodiante de chaves, como PCI DSS ou BSI C5, esse modelo será uma boa opção. Ao isolar todas as chaves de um aplicativo em um único projeto de chaves dedicado, é possível conceder o papel de administrador do Cloud KMS apenas a um pequeno grupo auditado de administradores de segurança. Isso pode simplificar as auditorias de compliance, limitando o número de projetos em que as principais políticas de acesso de administração precisam ser revisadas.
Considerações
Essa abordagem pode introduzir complexidades de IAM entre projetos e possíveis gargalos para as equipes de desenvolvimento. Para ajudar a reduzir esse problema, implemente o provisionamento automático de projetos, às vezes chamado de "fábrica de projetos", para automatizar a criação de chaves e a atribuição de permissões.
Exemplo
O diagrama a seguir mostra um exemplo de hierarquia de recursos para um ambiente de produção usando o modelo de armazenamento de chaves dedicado ao projeto:
- A pasta "Prod" contém pastas e projetos individuais para diferentes aplicativos, além de uma pasta "Shared".
- Os projetos de aplicativos contêm vários recursos diferentes, como instâncias do Compute Engine e buckets do Cloud Storage, mas não contêm chaves do Cloud KMS.
- A pasta "Shared" contém recursos compartilhados entre os diferentes aplicativos.
- Na pasta compartilhada, há um projeto de chave dedicado em que a API Cloud KMS está ativada. Esse projeto contém todas as chaves usadas para proteger recursos na pasta "Prod".
- Os mecanismos de proteção no nível da organização e da pasta, como restrições de política da organização e políticas do IAM, aplicam a segregação de funções e outras práticas.
- Os desenvolvedores podem ter privilégios elevados, como o papel de proprietário do projeto, em uma pasta ou projeto de aplicativo individual sem conceder privilégios no projeto principal.
Armazenamento de chaves no mesmo projeto
Nesse modelo, as chaves são armazenadas no mesmo projeto que os recursos que elas protegem. Os guardrails de gerenciamento de chaves geralmente são implementados por uma equipe principal de segurança, mesmo que os desenvolvedores gerenciem o ciclo de vida das chaves dos próprios aplicativos.
Caso de uso
Recomendamos usar o mesmo modelo de armazenamento de chaves do projeto se sua prioridade for velocidade, agilidade e responsabilidade clara do desenvolvedor. A colocalização de chaves com os recursos que elas protegem alinha a propriedade da chave com a propriedade dos dados: a chave segue os dados. Esse modelo facilita a delegação de responsabilidades importantes de gerenciamento aos proprietários de cargas de trabalho, que podem assumir a responsabilidade de se alinhar às políticas da organização da CMEK e gerenciar operações do ciclo de vida de chaves nos projetos.
Considerações
Embora esse modelo capacite as equipes de aplicativos, ele exige uma auditoria diligente dos papéis do IAM em cada projeto para aplicar o privilégio mínimo. Esse modelo pode aumentar a complexidade operacional para organizações que implementam o BYOK ou usam chaves do Cloud EKM devido ao overhead de coordenação entre sistemas.
Exemplo
O diagrama a seguir mostra um exemplo de hierarquia de recursos para um ambiente de produção usando o modelo de armazenamento de chaves do mesmo projeto:
- A pasta "Prod" contém pastas e projetos individuais para diferentes aplicativos.
- Os projetos de aplicativos contêm vários recursos diferentes, como instâncias do Compute Engine e buckets do Cloud Storage, incluindo chaves do Cloud KMS que protegem esses recursos.
- Os mecanismos de proteção no nível da organização e da pasta, como restrições de política da organização e políticas do IAM, aplicam a separação de funções e outras práticas, mas isso pode exigir uma configuração mais cuidadosa.
- Os desenvolvedores precisam de privilégios elevados do Cloud KMS no projeto de recurso para criar e gerenciar chaves.
Aplicar a segregação de funções
Independente do seu modelo de armazenamento, você precisa manter principais e permissões separados para quem administra e quem usa as chaves de criptografia. Para aplicar o princípio de privilégio mínimo e a separação estrita de funções, conceda papéis do IAM com base em responsabilidades operacionais específicas.
A tabela a seguir resume a separação de papéis recomendada para o Cloud KMS:
| Responsabilidade | Função recomendada | Resumo de permissões |
|---|---|---|
Administração de chaves, por exemplo, ciclos de vida e governança de chaves Isso pode incluir administradores humanos e principais da IaC que precisam de privilégios elevados. |
Administrador do Cloud KMS (roles/cloudkms.admin) |
|
Provisionamento de recursos, por exemplo, criação de recursos protegidos pela CMEK Isso pode incluir desenvolvedores humanos e principais da IaC sem privilégios elevados. |
Papéis de administrador ou editor específicos do serviço, como os seguintes:
|
Selecione as chaves durante a criação do recurso. |
Uso da chave, por exemplo, criptografia e descriptografia Conceda esse papel apenas aos agentes de serviço. Para chaves usadas em integrações de CMEK, os principais humanos não precisam dessas permissões. |
Criptografador/Descriptografador do Cloud KMS CryptoKey
(roles/cloudkms.cryptoKeyEncrypterDecrypter) |
Criptografe e descriptografe dados usando a chave. |
Aplicar escalonamento privilégio mínimo para pipelines de IaC
Muitas organizações automatizam o provisionamento de recursos usando pipelines de infraestrutura como código (IaC), como os executores do Terraform. A maneira como você arquiteta o armazenamento de chaves afeta diretamente a postura de segurança desses pipelines.
Para automatizar o provisionamento de chaves do Cloud KMS, seus pipelines de IaC precisam receber papéis administrativos altamente privilegiados para gerar chaves e modificar políticas do IAM. Se um invasor comprometer o pipeline de IaC, ele poderá ganhar controle administrativo total sobre seu plano de gerenciamento de chaves.
- Se você usa o armazenamento de chaves em um projeto dedicado, o pipeline exige acesso administrativo ao projeto central do Cloud KMS. Uma violação do pipeline pode expor o plano de gerenciamento de chaves de toda a organização.
- Se você usa o armazenamento de chaves no mesmo projeto, o pipeline só exige acesso administrativo ao projeto de recursos. Isso limita o escopo do risco potencial ao aplicativo específico, mas ainda exige o gerenciamento de privilégios elevados no projeto.
O Autokey do Cloud KMS resolve esse risco delegando o provisionamento de chaves a um agente de serviço seguro e gerenciado pelo Google. Assim, é possível implementar um pipeline de menor privilégio para o provisionamento contínuo de chaves:
- Pipelines de baixo privilégio: o pipeline de IaC só exige a função de
usuário do Autokey do Cloud KMS de baixo privilégio (
roles/cloudkms.autokeyUser) para solicitar uma chave criando um recursoKeyHandle. - Provisionamento automatizado: a criação de chaves e as atualizações de políticas do IAM são processadas nos bastidores pelo agente de serviço do Cloud KMS gerenciado pelo Google.
- Escopo limitado de risco: ao minimizar as permissões concedidas ao seu pipeline, esse design evita conceder aos pipelines de implantação privilégios elevados de criação de chaves ou de administrador de segurança, ou a capacidade de atribuir funções de assistente, o que reduz significativamente o risco de comprometimento de um pipeline.
Um pipeline de IaC que ativa o Autokey exige uma função mais permissiva, como administrador do Autokey do Cloud KMS (roles/cloudkms.autokeyAdmin). Portanto, se você usa pipelines de IaC para gerenciar a ativação do Autokey, também precisa aplicar a separação de funções aos principais individuais da IaC.
Alinhar com as práticas recomendadas de gerenciamento de chaves
O Google recomenda práticas para localização, nível de proteção, programação de rotação, granularidade e permissões de chaves. Para saber se as chaves estão alinhadas com essas práticas, use o painel de métricas de criptografia. É possível detectar violações de separação de funções usando descobertas de vulnerabilidade do Security Command Center.
Local da chave
Crie keyrings do Cloud KMS nos locais em que você planeja implantar recursos Cloud de Confiance criptografados com CMEK. Faça isso antes de criar as chaves.- Os recursos regionais e zonais precisam usar um keyring e uma chave na mesma região
que o recurso ou no local
global. - Os recursos globais precisam usar um keyring e uma chave no local
global.
Na maioria dos casos, essas restrições são aplicadas pelo serviço Cloud de Confiance.
Impor o uso de chaves regionais é uma parte de uma estratégia de regionalização de dados bem-sucedida. Ao exigir o uso de keyrings e chaves em uma região definida, você também exige que os recursos correspondam à região do keyring.
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. Escolher uma estratégia adequada de granularidade de chave ajuda você a se alinhar à recomendação do NIST de que cada chave tenha uma finalidade específica.
Em geral, recomendamos que cada chave seja usada da seguinte maneira:
- Usado para um único projeto Cloud de Confiance .
- Usado em um único local, por exemplo,
us-central1. - Usado em um único serviço ou produto, por exemplo, o BigQuery.
- Sempre que possível, usado para um único recurso, por exemplo, um único bucket do Cloud Storage.
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.
Seguir essas diretrizes de granularidade facilita a desativação ou destruição segura de versões de chaves e limita os riscos de destruição acidental ou maliciosa.
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 seus requisitos para os dados e
cargas de trabalho criptografadas com CMEK.
* Se você precisar armazenar o material de chave fora do
Cloud de Confiance, use chaves do Cloud EKM. Recomendamos o nível de proteção
EXTERNAL_VPC para melhorar a disponibilidade.
* Se você não precisar armazenar seu material de chaves fora do
Cloud de Confiance, recomendamos usar chaves baseadas em software.
Escolher um período de rotação
O Cloud KMS é compatível com a rotação de chaves automática de chaves simétricas com suporte de software e com suporte de hardware, como as usadas para CMEK. Para chaves baseadas em software, recomendamos usar o período de rotação padrão do setor de 90 dias. Para chaves do Cloud HSM, recomendamos o período de rotação padrão do setor de 365 dias. As chaves externas precisam ser trocadas manualmente de acordo com o cronograma escolhido.
Recomendamos que você 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 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.
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.
Aplique o princípio de privilégio mínimo
Ao conceder papéis do IAM, siga o princípio de privilégio mínimo.
É altamente recomendável evitar o uso de papéis básicos, como
Proprietário, Editor e Leitor. 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. Por exemplo, se um principal só precisar importar material de chave, conceda o papel de importador do Cloud KMS (roles/cloudkms.importer) em vez do papel mais permissivo de administrador do Cloud KMS (roles/cloudkms.admin).
Definir medidas de segurança operacionais
As seções a seguir descrevem os controles que podem ser implementados para ajudar a reduzir riscos como uso inconsistente de chaves ou exclusão ou destruição acidental.
Aplicar garantias do projeto
Recomendamos que você proteja projetos com garantias (prévia) para evitar a exclusão acidental dos seus projetos do Cloud KMS e das chaves que eles contêm. Enquanto uma garantia de projeto estiver em vigor, o projeto ficará bloqueado para exclusão até que a garantia seja removida. Para projetos que contêm chaves do Cloud KMS, isso evita uma possível causa de exclusão acidental de chaves.
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 permanente 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 você detectar um problema e restaurar a chave. A duração do estado programado 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 a chave 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 configurar 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 para 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
OCloud de Confiance oferece vários controles de detecção para CMEKs. As seções a seguir explicam como ativar e usar os controles relevantes para o Cloud KMS.
Ativar e agregar registros de auditoria
Recomendamos agregar os registros de auditoria de atividade do administrador do Cloud KMS 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 Agrupar e armazenar os registros da sua organização.
Opcionalmente, você pode ativar os registros de acesso aos 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 aos 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.
Resumo das práticas recomendadas
A tabela a seguir resume as práticas recomendadas neste documento:
| Tópico | Tarefa |
|---|---|
| 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 Cloud de Confianceque as chaves protegem. |
| Keyrings do Cloud KMS | Crie keyrings do Cloud KMS para cada local em que você quer proteger recursos Cloud de Confiance. |
| Granularidade da chave | Escolha um padrão de granularidade de chave que atenda às suas necessidades de tolerância a riscos, custo e sobrecarga operacional. |
| Nível de proteção | Escolha o Cloud EKM se o material da chave precisar ser armazenado fora de Cloud de Confiance ou se você precisar de uma certificação FIPS 140-2 de nível 2 ou 3. Caso contrário, escolha chaves de software. Consulte as orientações para selecionar um nível de proteção. |
| Material da chave | Para material de chave hospedado em Cloud de Confiance, use material de chave gerado por Cloud de Confiancesempre 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 aos principais concluir as tarefas. Não use papéis básicos. |
| Segregação de funções | Mantenha permissões separadas para administradores de chaves 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. |
| Avaliar os requisitos de compliance | Revise sua arquitetura do Cloud KMS e compare com os requisitos de conformidade que você precisa seguir. |