Separação de deveres é o conceito de garantir que um principal não tenha todas as permissões necessárias para concluir uma ação mal-intencionada. No Cloud Key Management Service, essa pode ser uma ação, como usar uma chave para acessar e descriptografar dados aos quais esse usuário não tem um motivo válido para acessar.
A separação de deveres é um controle comercial tipicamente usado em organizações maiores, destinado a evitar incidentes e erros de segurança ou privacidade. É considerada uma prática recomendada.
No Cloud KMS, a separação de funções exige uma distinção estrita entre os seguintes papéis:
- Administradores de chaves: principais autorizados a gerenciar ciclos de vida de chaves, incluindo criação, exclusão, rotação e mudanças de estado. Por exemplo, usuários com a função Administrador do Cloud KMS.
- Usuário principal: principais autorizados a usar chaves, incluindo criptografia, descriptografia, assinatura ou verificação de assinatura. Por exemplo, usuários com o papel Criptografador/descriptografador de CryptoKey do Cloud KMS.
Ao usar chaves do Cloud KMS para chaves de criptografia gerenciadas pelo cliente, recomendamos que a conta de serviço seja o único principal autorizado a usar a chave para criptografia e descriptografia. Para mais informações sobre como as integrações da CMEK processam o acesso a recursos, consulte Como os serviços integrados à CMEK processam o acesso a recursos.
Para evitar uma violação da separação de funções, não conceda aos principais papéis básicos amplos, como Proprietário (roles/owner), que contém permissões administrativas e criptográficas. Use o painel Métricas de criptografia (Prévia) para identificar chaves que não seguem as recomendações de separação de responsabilidades. Para mais informações, consulte Conferir métricas de criptografia.
Para mais informações sobre como usar papéis do IAM com segurança, consulte Usar o IAM com segurança.
Modelos de gerenciamento de chaves
O Cloud KMS oferece dois modelos principais para aplicar a separação de funções: gerenciamento centralizado e delegado de chaves. Esses modelos de gerenciamento de chaves podem ser usados separadamente ou em combinação. Por exemplo, uma organização pode usar um modelo centralizado para ambientes de produção e um modelo dedicado para ambientes inferiores usados para desenvolvimento e teste.
A tabela a seguir compara os modelos de gerenciamento de chaves centralizado e delegado e ajuda você a decidir qual é o melhor para suas necessidades.
| Área | Centralizado (nível da pasta) | Delegada (nível do projeto) |
|---|---|---|
| Local da chave | Armazenadas em um projeto de chave dedicado, geralmente por pasta. | Armazenada no mesmo projeto que o recurso protegido pela chave. |
| Método de separação | Limites do projeto: as chaves e os recursos que elas protegem estão em projetos diferentes. | Separação de papéis: separação estrita de papéis do IAM para que nenhum principal possa gerenciar e usar uma chave. |
| Cultura empresarial | Ideal para organizações altamente regulamentadas com equipes dedicadas de segurança central ou criptografia. | Ideal para organizações que priorizam a agilidade dos desenvolvedores e a autoridade descentralizada. |
| Principais fatores | Alto isolamento e supervisão centralizada. | Gerenciamento simplificado de cotas e redução do trabalho operacional. |
Gerenciamento de chaves delegado
O modelo de gerenciamento de chaves delegado ou "mesmo projeto" é recomendado para organizações que priorizam a agilidade do desenvolvedor e visam reduzir o "loop" entre as equipes centrais de segurança e os desenvolvedores.
No modelo delegado, as CMEKs e outras chaves são armazenadas no mesmo projeto que os recursos protegidos. Para aplicar a separação de tarefas no gerenciamento de chaves delegado, é necessário manter os papéis do IAM estritamente separados.
É possível ativar a chave automática para projetos (pré-lançamento) em um projeto ou pasta para permitir a criação automatizada de chaves usando o modelo de gerenciamento de chaves delegado. Para mais informações, consulte Ativar a Autokey para gerenciamento de chaves delegado.
Gerenciamento de chaves centralizado
O modelo de gerenciamento de chaves centralizado ou de "projeto dedicado" é recomendado para organizações com equipes de segurança centralizadas ou que exigem isolamento estrito do material de chaves dos ambientes de aplicativos.
No modelo centralizado, as CMEKs e outras chaves são armazenadas em projetos de chaves dedicados, separados dos recursos que protegem. Normalmente, isso significa que cada pasta tem um projeto de chave dedicado para conter chaves que protegem recursos em toda a pasta. Esse projeto de chave dedicada é gerenciado por uma equipe de segurança central, que tem permissões de administração de chaves no projeto de chave, mas não pode acessar projetos que contêm os recursos protegidos por essas chaves.
É possível ativar o Autokey em uma pasta para permitir a criação automática de chaves usando o modelo de gerenciamento centralizado de chaves. Para mais informações, consulte Configurar o Autokey para gerenciamento centralizado de chaves.
Automação e monitoramento da conformidade
OGoogle Cloud oferece as seguintes ferramentas para automatizar e monitorar seus limites de segurança:
- Chave automática do Cloud KMS: a chave automática é compatível com modelos de gerenciamento de chaves centralizados e delegados (pré-lançamento). Para ambos, ele automatiza a separação de funções concedendo automaticamente o papel de uso da chave ao agente de serviço necessário, e não à pessoa que solicita a chave. O Autokey foi projetado para oferecer suporte a pipelines de infraestrutura como código que não precisam de privilégios elevados para a criação de chaves.
- Security Command Center: monitore as descobertas de Separação de papéis do KMS para detectar qualquer principal, incluindo um proprietário do projeto ou uma conta de serviço do Google, que tenha permissões administrativas e criptográficas em uma única chave.
Métricas de criptografia CMEK: use o painel para verificar o alinhamento com as práticas de separação de funções em toda a organização.