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 Cloud de Confiance . 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 considera que você já conhece o Cloud Key Management Service (Cloud KMS) e as chaves de criptografia gerenciadas pelo cliente.Decidir se você quer usar o CMEK
Recomendamos que você use a CMEK para criptografar dados em repouso nos serviços do Cloud de Confiancese 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 Cloud de Confiance.
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.
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 seu custo, sobrecarga operacional e 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 aplicativos.
- 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.
Criar keyrings do Cloud KMS para cada local
Você precisa criar keyrings do Cloud KMS nos locais em que implanta recursos doCloud de Confiance criptografados com a CMEK.
- Os recursos regionais e zonais precisam usar um keyring e a CMEK na mesma região do recurso ou no local
global. - 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 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 a criptografia de um recurso com chaves global.
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 usadas 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 Cloud de Confiance projeto.
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.
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 restrito tem menos risco 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. Uma granularidade de chave maior exige um número maior de versões de chaves ativas, o que gera custos adicionais.
- 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.
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 recriptografados com segurança com uma nova versão antes de desativar a versão antiga. 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 chave, o que gera custos menores.
- 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:
Você precisa de algum dos recursos da CMEK? Revise os recursos listados em Decidir se é necessário usar a CMEK nesta página.
- Se sim, vá para a próxima pergunta.
- Caso contrário, recomendamos usar a criptografia padrão do S3NS .
Você precisa de uma certificação FIPS 140-2 de nível 2 ou 3 ou que o material de chave seja armazenado fora de Cloud de Confiance?
- Nesse caso, recomendamos a CMEK com o Cloud External Key Manager.
- Caso contrário, recomendamos usar a CMEK com chaves baseadas em software.
Use material de chave gerado por Cloud de Confiancesempre 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 Cloud de Confiance. 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 fazer a custódia do 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 Cloud de Confiance?
- 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, só é possível usar chaves com a finalidade simétrica ENCRYPT_DECRYPT. 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 de chaves frequente 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 ser comprometida.
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 executar 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.
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 funções entre o oficial de criptografia, que ativa e gerencia os serviços de um sistema de gerenciamento de chaves criptográficas, e um usuário, que usa essas chaves para criptografar ou descriptografar recursos.
Quando você usa a CMEK para gerenciar a criptografia em repouso com serviços do Cloud de Confiance ,
o papel do IAM para usar chaves de criptografia é atribuído ao agente
de serviço do serviço Cloud de Confiance , não ao usuário
individual. Por exemplo, para criar objetos em um bucket do Cloud Storage criptografado, 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.s3ns-system.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 |
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 (prévia) para evitar a exclusão acidental. 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
OCloud de Confiance oferece vários controles de detecção para CMEKs. As seções a seguir mostram 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 Agrupar e armazenar os registros da sua organização.
Se quiser, ative 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 aos 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.
Avaliar seus requisitos de compliance
Diferentes estruturas de conformidade têm 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 Cloud de Confiance podem ajudar a atender aos requisitos de diferentes estruturas de compliance, consulte o seguinte recurso:Resumo das práticas recomendadas
A tabela a seguir resume as práticas recomendadas neste documento:
| Tópico | Tarefa |
|---|---|
| Decidir se você quer usar o CMEK | Use a CMEK se precisar de qualquer uma das capacidades ativadas por ela. |
| 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 do 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 do 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. Confira 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 suas chaves 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 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. |