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 Cloud de Confiance 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.Decida se quer usar as CMEK
Recomendamos que use CMEK para encriptar dados em repouso nos serviços Cloud de Confiance 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 Cloud de Confiance.
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.
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.
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 Cloud de Confiance 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 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 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.
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 usadas 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. A granularidade das chaves mais elevada requer um maior número de versões de chaves ativas, o que acarreta custos adicionais.
- 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.
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. 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, o que implica custos mais baixos.
- 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:
Precisa de alguma das capacidades das CMEK? Pode rever as capacidades indicadas em Decida se deve usar as CMEK nesta página.
- Em caso afirmativo, avance para a próxima pergunta.
- Caso contrário, recomendamos que use a S3NS encriptação predefinida.
Precisa de uma certificação FIPS 140-2 de nível 2 ou nível 3, ou que o material da chave seja armazenado fora do Cloud de Confiance?
- Nesse caso, recomendamos o CMEK com o Cloud External Key Manager.
- Caso contrário, recomendamos que use a CMEK com chaves suportadas por software.
Use material de chaves gerado pela Cloud de Confiancesempre 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 Cloud de Confiance. 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 Cloud de Confiance?
- 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.
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.
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 Cloud de Confiance serviços, a função de IAM para usar chaves de encriptação é atribuída ao agente do serviço do serviço Cloud de Confiance , 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.s3ns-system.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 |
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
Cloud de Confiance 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.
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 Cloud de Confiance podem ajudar a cumprir os requisitos de diferentes estruturas de conformidade, consulte o seguinte recurso: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. |
| 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. Cloud de Confiance |
| Conjuntos de chaves do Cloud KMS | Crie conjuntos de chaves do Cloud KMS para cada localização onde quer proteger Cloud de Confiance recursos. |
| Nível de detalhe da chave | Escolha um padrão de nível de detalhe da chave que satisfaça as suas necessidades de tolerância ao risco, custo e sobrecarga operacional. |
| Nível de proteção | Escolha o EKM da nuvem se o seu material de chaves tiver de ser armazenado fora do Cloud de Confiance ou se precisar de uma certificação FIPS 140-2 de nível 2 ou nível 3. Caso contrário, escolha chaves de software. Reveja as orientações para selecionar um nível de proteção. |
| Material da chave | Para material de chaves alojado em Cloud de Confiance, use material de chaves gerado por Cloud de Confiancesempre 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. |
| 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. |