Visão geral do Cloud HSM de locatário único

Este documento oferece uma visão geral dos conceitos e recursos do Cloud HSM de locatário único.

O Cloud HSM de locatário único permite criar e gerenciar uma instância de locatário único do Cloud HSM. Uma instância do Cloud HSM de locatário único é um cluster dedicado de partições em módulos de segurança de hardware (HSMs) para uso exclusivo. Cada instância oferece a mesma redundância e alta disponibilidade do Cloud HSM multilocatário. Cada cluster do Cloud HSM de locatário único é distribuído em vários HSMs em várias zonas na região selecionada. Cada partição é isolada criptograficamente de outras partições no HSM.

É possível conceder ou negar o acesso do Google ao cluster, e os administradores da instância gerenciam o cluster. Os administradores da instância controlam a instância usando um modelo de aprovação de quórum que depende de chaves de controle assimétricas para autenticação de dois fatores (2FA). Você cria as chaves de controle fora do Google Cloudpara que o Google nunca tenha acesso às suas chaves de controle privadas.

Depois que a instância do Cloud HSM de locatário único for configurada, os administradores do Cloud KMS poderão criar chaves de locatário único, e os desenvolvedores poderão usá-las como qualquer outra chave do Cloud HSM, sem alterações no código.

O uso do Cloud HSM de locatário único gera custos. Para informações sobre preços, consulte Preços do Cloud KMS.

Autenticação baseada em quórum

O Cloud HSM de locatário único usa a autenticação baseada em quórum para garantir que as operações críticas sejam aprovadas por vários administradores de instâncias. Antes de criar uma instância de locatário único, é necessário criar um conjunto de chaves de controle assimétricas fora do Cloud KMS e definir quantas aprovações são necessárias para operações na instância. Por exemplo, se a instância for gerenciada por cinco administradores, você poderá exigir que três administradores aprovem cada operação de manutenção na instância.

As operações que exigem autenticação de quórum têm três estágios:

  1. Proposta: um administrador de instância propõe uma operação, por exemplo, registrar uma nova chave de controle. A proposta cria um snapshot imutável do estado atual do sistema. As propostas expiram após 24 horas e podem ser canceladas a qualquer momento até que a operação aprovada seja iniciada.

  2. Aprovação: o número necessário de administradores precisa assinar desafios usando a chave de controle exclusiva. Cada desafio assinado indica um administrador que aprova a operação. Quando desafios assinados suficientes estiverem prontos, um administrador de instância fará o upload deles para aprovar a proposta. Se os desafios forem válidos e a proposta não tiver expirado, ela será aprovada.

  3. Execução: depois que uma proposta é aprovada, mas antes de expirar, é possível executar a operação proposta.

Recursos do Cloud HSM de locatário único

Esta seção descreve os principais recursos do Cloud HSM de locatário único.

Gerenciamento de instâncias

Os administradores gerenciam o ciclo de vida das instâncias do Cloud HSM de locatário único.

  • Criar uma instância: provisione uma nova instância em uma única região. O processo de criação exige que você configure a autenticação de quórum.
  • Receber informações da instância: é possível consultar uma instância para receber os metadados e a configuração dela. Essa operação não exige autenticação de quórum.
  • Desativar e ativar uma instância: é possível desativar temporariamente uma instância, o que revoga o acesso do Google às partições. Você pode ativar a instância mais tarde. Ambas as operações exigem autenticação de quórum. A ativação da instância redefine a disableDate para 730 dias a partir do momento da operação de ativação. Enquanto uma instância está desativada, todas as chaves criadas nela ficam indisponíveis, e todas as operações que tentam usar essas chaves falham.
  • Atualizar uma instância: é necessário atualizar a instância regularmente para mantê-la disponível. As instâncias precisam ser atualizadas a cada 730 dias ou menos. Cada instância tem uma disableDate que indica quando a instância estará atrasada para uma atualização. A atualização da instância redefine a disableDate para 730 dias a partir do momento da atualização. Essa operação exige autenticação de quórum. As instâncias que não são atualizadas antes do horário disableDate são desativadas automaticamente.
  • Excluir uma instância: é possível excluir uma instância. A exclusão de uma instância destrói permanentemente todas as chaves criadas nela. Essa é uma operação destrutiva e irreversível. Não exclua uma instância, a menos que você queira triturar criptograficamente todos os dados criptografados usando chaves criadas na instância. Essa operação exige autenticação de quórum.

Gerenciamento de chaves

Os administradores são proprietários das chaves de controle usadas para autenticação de quórum. Os desenvolvedores e outros proprietários de recursos criam e usam chaves criptográficas na instância.

  • Girar chaves de controle de administrador: os administradores podem girar a chave de controle 2FA para um membro do quórum administrativo. Essa operação exige autenticação de quórum.
  • Gerar chaves criptográficas: os desenvolvedores e proprietários de recursos podem criar uma CryptoKey com um nível de proteção de HSM de locatário único. Essa operação não exige autenticação de quórum.
  • Realizar operações criptográficas: depois de criadas, as chaves armazenadas em uma instância de locatário único podem ser usadas para operações criptográficas, assim como qualquer outra chave do Cloud Key Management Service.
  • Portabilidade de chaves: é possível gerenciar suas próprias chaves de encapsulamento confiáveis em instâncias de locatário único para exportar outras chaves ou importar chaves pré-encapsuladas. Isso permite a interoperabilidade entre diferentes provedores de nuvem e Google Cloud regiões.

Práticas recomendadas para o Cloud HSM de locatário único

Siga estas práticas recomendadas ao usar o Cloud HSM de locatário único:

  • Garantias do projeto: use garantias do projeto para proteger projetos que contenham instâncias ativas do Cloud HSM de locatário único. Se você excluir um projeto que contém uma instância do Cloud HSM de locatário único, as chaves criadas nessa instância não poderão ser recuperadas.
  • Tokens físicos: use tokens físicos para armazenar as chaves 2FA privadas dos administradores da instância. Armazene esses tokens físicos com segurança. Se você perder um quórum de chaves, o Google não poderá ajudar a recuperar o acesso à instância. Como as instâncias precisam ser atualizadas regularmente, a perda de um quórum de chaves acaba desativando a instância.
  • Chaves de backup: registre pelo menos uma chave 2FA reserva além das chaves mantidas pelos membros do quórum. Mantenha as chaves de backup em um local seguro onde você possa acessá-las se a chave de um membro do quórum for perdida ou roubada.
  • Segregação de funções: mantenha a segregação de funções para os administradores da instância. A proposta, a aprovação e a execução exigem papéis separados do IAM, que precisam ser distribuídos entre pelo menos duas pessoas para que nenhuma pessoa tenha as permissões de todos os três papéis. Se uma pessoa tiver todas as permissões subjacentes, haverá um risco maior de perda de dados acidental ou intencional.
  • Distribuição de chaves: verifique se as chaves 2FA privadas estão distribuídas com segurança entre pessoas confiáveis. Nenhuma pessoa deve manter a posse de chaves privadas suficientes para atingir um quórum. Se uma pessoa tiver acesso a chaves privadas suficientes para atender ao tamanho do quórum necessário, haverá um risco maior de perda de dados acidental ou intencional.
  • Programação de atualização: incorpore a atualização das instâncias do Cloud HSM de locatário único aos procedimentos de manutenção contínuos. É necessário monitorar a disableDate de cada instância e concluir uma operação de atualização antes desse horário. A atualização da instância exige a aprovação do quórum. Portanto, proponha a operação de atualização com antecedência suficiente para que a proposta possa ser aprovada e executada antes da disableDate.

A seguir