Práticas recomendadas para o Cloud HSM no Google Workspace

Este documento descreve as práticas recomendadas para configurar o Cloud HSM no Google Workspace e ajudar a proteger seu material de chaves contra destruição e exclusão acidental ou não autorizada, garantir alta disponibilidade e durabilidade para chaves criptográficas críticas e atender aos requisitos regulamentares e de compliance.

Este documento é destinado a arquitetos de nuvem, equipes de segurança e administradores do Google Workspace responsáveis pela segurança e resiliência operacional das chaves de criptografia usadas na criptografia do lado do cliente (CSE) para o Google Workspace. Ele pressupõe que você já conhece o Cloud HSM para Google Workspace e concluiu o processo de integração.

Mitigar a perda de material de chave

Os riscos de segurança podem surgir quando um principal tem um papel que concede permissão para concluir ações destrutivas, especialmente aquelas fora do escopo de trabalho usual do principal. Por exemplo, um usuário com um papel de proprietário do projeto (roles/owner) muito amplo pode destruir o material da chave usado para a CSE do Google Workspace, deixando os dados criptografados permanentemente inacessíveis.

As seções a seguir descrevem práticas que ajudam a reduzir o risco de destruição e exclusão acidental e maliciosa de chaves removendo as permissões para destruir ou excluir o material de chaves do Cloud KMS usado pela criptografia do lado do cliente (CSE, na sigla em inglês) do Google Workspace e restringindo a destruição de chaves.

Aplicar políticas de negação do IAM no nível da pasta

Com as políticas de negação do IAM, é possível negar permissões a principais, mesmo que a permissão seja concedida por uma função que o principal tenha. Por exemplo, mesmo que um usuário tenha o papel de proprietário do projeto (roles/owner), uma política de negação do IAM no nível da pasta pode impedir que ele destrua ou exclua chaves. Ao colocar o projeto do Cloud HSM em uma pasta e aplicar uma política de negação no nível da pasta, você cria uma proteção que impede a destruição e exclusão de chaves enquanto a política está em vigor. As políticas de negação aplicadas não podem ser canceladas sem uma função como Administrador de negação (roles/iam.denyAdmin) na pasta.

Verifique se os papéis de administração de pastas, como Administrador de pastas (roles/resourcemanager.folderAdmin) e Administrador de negações (roles/iam.denyAdmin), são concedidos apenas a principais que não têm o papel de Administrador do Cloud KMS (roles/cloudkms.admin) no projeto em que as chaves do Cloud HSM estão localizadas. Essa separação de funções garante que nenhum principal possa gerenciar e destruir chaves.

Defina uma política de negação com base no seguinte exemplo de configuração:

displayName: Deny KMS key destruction and deletion
rules:
- description: "Denies destroy and delete permissions on Cloud KMS keys for all principals."
  denyRule:
    deniedPrincipals:
    - "principalSet://goog/public:all"
    deniedPermissions:
    - "cloudkms.googleapis.com/cryptoKeyVersions.destroy"
    - "cloudkms.googleapis.com/cryptoKeys.delete"

Para mais informações sobre políticas de negação do IAM, consulte Visão geral das políticas de negação do IAM.

Aplicar restrições da política da organização para destruição de chaves

Além do IAM, é possível aplicar barreiras de proteção de segurança no nível da organização ou da pasta usando restrições da política da organização. Essas restrições atuam como requisitos rígidos que limitam os tipos de recursos que podem ser criados e como eles podem ser configurados. As restrições das políticas da organização aplicadas não podem ser ignoradas, nem mesmo por principais que têm as permissões necessárias para concluir a ação proibida. As restrições de política da organização aplicadas não podem ser canceladas sem uma função como Administrador da política da organização (roles/orgpolicy.policyAdmin) na organização.

  • Duração mínima da destruição (constraints/cloudkms.minimumDestroyScheduledDuration): exige uma duração mínima programada para destruição (por exemplo, 90 ou 120 dias) em todas as chaves da organização ou do recurso em que a política está ativada. Essa restrição impede que qualquer usuário reduza o período de recuperação abaixo do valor mínimo configurado.
  • Desativar antes de destruir (constraints/cloudkms.disableBeforeDestroy): exige que uma versão de chave esteja no estado DISABLED antes de ser programada para destruição. Essa restrição adiciona uma etapa obrigatória ao fluxo de trabalho de destruição, aumentando a visibilidade da ação nos registros de auditoria.

Para mais informações, consulte Destruição da versão da chave de controle.

Maximizar a janela de destruição de chaves

Quando uma versão de chave é programada para destruição, ela entra em um período de "exclusão reversível". Enquanto uma versão de chave está no estado programada para destruição, é possível restaurar a chave para cancelar a destruição dela. Definir esse período configurável como o tempo máximo de 120 dias ajuda a garantir que você tenha tempo suficiente para restaurar uma versão de chave que foi programada para destruição por acidente ou de forma maliciosa. Você só pode definir esse valor ao criar a chave.

Quando você restaura uma versão de chave programada para destruição, o estado da versão é definido como DISABLED. Em seguida, reative a versão da chave para restaurar o acesso aos seus dados criptografados do Google Workspace.

O comando da CLI gcloud a seguir cria uma chave com suporte de HSM com uma duração de destruição programada de 120 dias:

gcloud kms keys create KEY_NAME \
    --location LOCATION \
    --keyring KEY_RING \
    --purpose encryption \
    --protection-level hsm \
    --destroy-scheduled-duration 120d

Substitua:

  • KEY_NAME: o nome da chave;
  • LOCATION: o local do Cloud KMS do keyring.
  • KEY_RING: o nome do keyring que contém a chave.

Para aplicar essa duração a todas as chaves da sua organização em vez de definir em cada chave, defina e aplique uma restrição personalizada de política da organização. A restrição de exemplo a seguir só permite que os usuários criem uma chave se a duração programada para destruição for entre 90 e 120 dias:

name: organizations/ORGANIZATION_ID/customConstraints/custom.limitScheduledDestruction
resourceTypes:
- cloudkms.googleapis.com/CryptoKey
methodTypes:
- CREATE
condition: "resource.destroyScheduledDuration >= duration('7776000s') && resource.destroyScheduledDuration <= duration('10368000s')"
actionType: ALLOW
displayName: Require scheduled destruction duration between 90 and 120 days
description: Allows key creation only if the destroyScheduledDuration is between 90 and 120 days.

Substitua ORGANIZATION_ID pelo ID numérico da organização.

Para mais informações sobre como configurar a duração da destruição programada, consulte Destruir e restaurar versões de chave. Para mais informações sobre como usar restrições personalizadas da política da organização com o Cloud KMS, consulte Criar restrições personalizadas da política da organização para o Cloud KMS.

Proteja sua infraestrutura e seu projeto

As proteções discutidas anteriormente neste documento se concentram em evitar a destruição e exclusão de chaves. No entanto, você também precisa de proteções para evitar a exclusão do projeto principal. Use as seguintes diretrizes para proteger o ambiente do projeto que hospeda suas chaves do Google Workspace.

Aplicar garantias de projeto

Uma garantia impede que um projeto seja excluído. Mesmo um usuário com o papel de Proprietário do projeto (roles/owner) não pode encerrar o projeto enquanto uma restrição estiver ativa. Essa é a maneira mais eficaz de evitar a exclusão acidental ou não autorizada do projeto em que suas chaves do Google Workspace estão.

Para mais informações sobre garantias de projetos, consulte Proteger projetos com garantias.

Entender o período de recuperação do projeto

Se um projeto for excluído com sucesso, por exemplo, depois que uma garantia de projeto (prévia) for removida, ele entrará no período de recuperação de 30 dias. Durante esse período, um usuário com o papel de proprietário do projeto (roles/owner) ou administrador da organização (roles/resourcemanager.organizationAdmin) pode restaurar o projeto. Após 30 dias, o projeto e todas as chaves nele serão excluídos permanentemente.

Recomendamos que você mantenha os bloqueios de projeto e use a janela de recuperação apenas como último recurso.

Para mais informações sobre a recuperação de projetos, consulte Restaurar um projeto excluído.

Usar o VPC Service Controls

Com o VPC Service Controls, é possível definir um perímetro de segurança em torno do seu projeto do Cloud HSM. Isso ajuda a garantir que a API Cloud KMS só possa ser acessada de redes confiáveis ou identidades específicas, reduzindo o risco de ações administrativas não autorizadas fora do ambiente corporativo.

Garantir a soberania do material da chave com chaves importadas (BYOK)

Para a maioria das organizações, recomendamos que o Cloud HSM gere e gerencie o material de chave.

No entanto, se você precisar de recursos de "traga sua própria chave (BYOK)", gere o material da chave no local e importe-o para o Cloud HSM. Essa abordagem de BYOK permite atender a requisitos como manter uma cópia independente e local do material de chave, por exemplo, para atender a mandatos de soberania de dados ou se recuperar de uma perda catastrófica de material de chave. Essa abordagem oferece uma cópia independente do material da chave que pode ser reimportada se a versão da chave no Cloud KMS for destruída.

Importar novamente para a mesma versão

O Cloud KMS permite reimportar material de chave idêntico para a versão de chave destruída, para que o identificador de recurso e o URI sejam os mesmos da versão de chave importada original. Assim, você pode continuar usando as mesmas configurações do Google Workspace. Quando você importa novamente uma versão de chave usada em uma configuração do Google Workspace, o acesso aos dados é restaurado assim que a versão da chave termina de ser importada.

Para mais informações sobre como importar novamente uma versão de chave destruída, consulte Como importar novamente uma versão de chave destruída.

Proteção avançada com o Cloud HSM de locatário único

Para clientes que exigem o mais alto nível de isolamento, o Cloud HSM de locatário único oferece partições de HSM dedicadas. Sua instância do Cloud HSM de locatário único é criada e gerenciada usando a autenticação por quorum, que exige a aprovação de um número mínimo configurado de membros do quorum antes de operações críticas, como a exclusão da instância do Cloud HSM de locatário único. Isso ajuda a evitar que uma única conta comprometida destrua sua instância do Cloud HSM de locatário único. As práticas a seguir se aplicam quando você usa o Cloud HSM de locatário único. Para mais informações, consulte Autenticação baseada em quorum.

Separar a infraestrutura e as chaves entre projetos

Crie a instância do Cloud HSM de locatário único e as chaves do Google Workspace em projetos separados. A separação dos projetos de recursos ajuda a garantir que um usuário com papéis administrativos no projeto de chave não tenha autoridade sobre a instância do Cloud HSM de locatário único subjacente. Essa segregação de funções entre o gerenciamento de infraestrutura e de chaves reduz o risco de ações não autorizadas no nível da infraestrutura.

Para mais informações sobre o Cloud HSM de locatário único, consulte Visão geral do Cloud HSM de locatário único.

Resumo das práticas recomendadas

A tabela a seguir resume as práticas recomendadas neste documento:

Tópico Tarefa
Políticas de negação do IAM Aplique políticas de negação no nível da pasta para bloquear a destruição e exclusão de chaves, mesmo para usuários com alto acesso privilegiado.
Restrições das políticas da organização Impor restrições para exigir um período mínimo de recuperação e desativar as chaves antes que elas possam ser destruídas.
Período programado para destruição
  • Crie sua chave com o valor programado para destruição definido como o máximo de 120 dias. Como alternativa, você pode escolher uma duração menor, mas ela precisa ser longa o suficiente para garantir que as chaves possam ser recuperadas se forem programadas para destruição.
  • Use uma restrição personalizada da política da organização para garantir que todas as chaves sejam criadas com uma duração adequada às suas necessidades.
Restrições de projeto Aplique garantias de projeto para evitar a exclusão do projeto que contém suas chaves de criptografia.
Perímetro do VPC Service Controls Defina um perímetro do VPC Service Controls para restringir o acesso à API Cloud KMS a redes e identidades confiáveis.
Reimportação do BYOK Gere material de chave no local e use a reimportação para recuperar versões de chave destruídas sem mudar os nomes dos recursos.
Arquitetura entre projetos Se você usar o Cloud HSM de locatário único, separe a instância e as chaves do Cloud HSM de locatário único em projetos diferentes para aplicar a segregação de funções.

A seguir