Arquitetura do Cloud HSM

Este conteúdo foi atualizado pela última vez em janeiro de 2025 e representa o estado do momento em que foi escrito. Os sistemas e as políticas de segurança do Google podem mudar no futuro, à medida que a proteção dos clientes é aprimorada.

O Cloud HSM faz parte da arquitetura do Cloud Key Management Service (Cloud KMS) e fornece o back-end para provisionar e gerenciar chaves protegidas por hardware. Para ajudar você a atender a regulamentações corporativas e de conformidade, o Cloud HSM permite gerar chaves de criptografia e executar operações criptográficas em módulos de segurança de hardware (HSM) certificados pelo FIPS 140-2 nível 3.

Neste documento, descrevemos a arquitetura do Cloud HSM, incluindo como o hardware é gerenciado e as chaves são atestados e criadas. Para mais informações sobre o Cloud KMS, consulte Criptografia do Cloud Key Management Service.

Visão geral

As operações criptográficas incluem:

  • Como criptografar dados em repouso
  • Como proteger as chaves privadas do Certificate Authority Service
  • Proteção de chaves de criptografia de dados para que elas possam ser armazenadas com os dados criptografados
  • Gerar e usar chaves assimétricas para operações criptográficas, como assinaturas digitais e autenticação

O Cloud HSM usa os Marvell LiquidSecurity HSMs (modelos CNL3560-NFBE-2.0-G e CNL3560-NFBE-3.0-G) com as versões de firmware 3.4, build 09. Para mais informações sobre nossa certificação, consulte o certificado #4399. Para informações sobre os dispositivos HSM e as chaves protegidas por hardware, consulte confirmação de chaves.

O Cloud HSM é totalmente gerenciado para que você possa proteger suas cargas de trabalho sem a sobrecarga operacional de gerenciar um cluster do HSM. O serviço oferece as seguintes vantagens:

  • Disponibilidade global
  • Uma API consistente e unificada
  • Escalonamento automático com base no seu uso
  • Gerenciamento centralizado e conformidade regulatória

O Cloud HSM está disponível em todas as Google Cloud regiões do mundo, incluindo multirregiões que abrangem áreas geográficas maiores. Use o endpoint de serviço do Cloud KMS para criar e usar chaves protegidas por hardware no Cloud HSM e proteger seus dados, incluindo os armazenados em outros serviços doGoogle Cloud , como BigQuery, Cloud Storage e Persistent Disk.

Com o Cloud HSM, é possível usar chaves protegidas por hardware sem precisar gerenciar o hardware do HSM. O Google é proprietário e gerencia o hardware do HSM, incluindo implantação, configuração, monitoramento, aplicação de patches e manutenção. Quando você usa o Cloud HSM, os dados ficam estritamente isolados de outros locatários e serviços no Google Cloud. A API do plano de dados do Cloud HSM, que faz parte da API Cloud Key Management Service, permite gerenciar chaves protegidas por hardware de maneira programática.

O Cloud HSM oferece suporte à Autochave do Cloud KMS protegida por hardware e a chaves de criptografia gerenciadas pelo cliente (CMEK), em que as chaves CMEK são compatíveis com os serviços do Google Cloud . Por exemplo, é possível criptografar dados em buckets do Cloud Storage ou tabelas do Cloud SQL usando uma chave do Cloud HSM que você gerencia.

Gerenciamento do Cloud HSM

No Cloud HSM, os clusters de HSMs são mantidos por engenheiros e técnicos de confiabilidade do site (SREs) do Google que trabalham em cada local de data center do Google Cloud. Google CloudO Google lida com a segurança física, segurança lógica, infraestrutura, planejamento de capacidade, expansão geográfica e planejamento de recuperação de desastres do data center.

Abstração do hardware HSM

Normalmente, os aplicativos se comunicam diretamente com HSMs usando PKCS#11 e uma API de gerenciamento de cluster. Essa comunicação requer que você mantenha um código especializado para cargas de trabalho que usem ou gerenciem chaves protegidas por hardware.

O Cloud HSM abstrai a comunicação do HSM, fazendo proxy das solicitações para chaves protegidas por hardware por meio da API Cloud Key Management Service. A abstração reduz a necessidade de código específico do HSM. O Cloud HSM herda uma integração estreita com o Cloud KMS.

A integração perfeita com o Cloud KMS oferece benefícios de segurança substanciais. A API Cloud Key Management Service reduz significativamente a amplitude da interface HSM disponível, reduzindo o risco de caso de violação de segurança do cliente. Por exemplo, um invasor não conseguiria excluir HSMs inteiros. Por padrão, as tentativas de destruir chaves individuais são atenuadas por um período de segurança de 30 dias. É possível definir a política da organização constraints/cloudkms.minimumDestroyScheduledDuration para impor um tamanho mínimo para a duração programada para destruição de novas chaves e da política de organização constraints/cloudkms.disableBeforeDestroy para excluir versões de chave somente quando elas estiverem desativadas. Para saber mais, consulte Destruição da versão da chave de controle.

É possível controlar o acesso aos recursos do HSM usando o Identity and Access Management (IAM). É menos provável que a configuração do IAM sofra com configurações incorretas e bugs do que uma solução HSM personalizada.

O diagrama a seguir mostra a arquitetura do Cloud HSM.

Diagrama da arquitetura do Cloud HSM.

Separação geográfica estrita, por design

No Cloud HSM, é possível optar por disponibilizar as chaves globalmente ou aplicar restrições geográficas rigorosas às chaves que precisam delas.

Muitas vezes, os HSMs são divididos em partições, de modo que um único dispositivo físico pode operar como vários dispositivos lógicos. Use partições para reduzir os custos de implantação quando for necessário separar a administração e as chaves do HSM. O diagrama a seguir mostra as partições em três regiões.

Diagrama de geografia do Cloud HSM.

Para isolar as chaves de cada região e multirregião, cada região do Cloud HSM está associada a uma chave de encapsulamento regional do HSM separada. Consulte o diagrama em Criação de chaves. Para oferecer suporte à alta disponibilidade, a chave de união é clonada em partições em cada HSM localizado fisicamente na região. As chaves regionais do HSM não saem do HSM nesse local. Isso permite que HSMs na mesma região atendam ao mesmo conjunto de chaves do cliente e garante que os HSMs fora da região não possam veicular essas chaves.

O Cloud HSM também cria multirregiões usando chaves de encapsulamento. Todas as chaves do cliente de uma multirregião são encapsuladas por uma chave de união presente em uma partição em todos os locais que compõem a multirregião. O serviço usa o mesmo hardware para várias regiões, mas oferece o mesmo isolamento forte entre regiões e multirregiões que existem entre diferentes regiões.

O esquema de regionalização exige que as chaves de encapsulamento sejam replicadas apenas para partições apropriadas. Cada alteração de configuração precisa ser aprovada por vários membros da equipe do Cloud HSM antes de se tornar ativa. Os técnicos do data center não podem acessar uma configuração, um ambiente de execução ou um armazenamento do HSM.

Gerenciamento centralizado

Em um data center convencional que hospeda HSMs, o gerenciamento dos HSMs e recursos é totalmente separado do gerenciamento de outras chaves protegidas por hardware. O Cloud HSM está bastante integrado ao Google Cloud, permitindo gerenciar perfeitamente seus recursos do Cloud HSM. Por exemplo, é possível gerenciar o seguinte:

  • Gerencie as chaves protegidas por hardware com outras chaves no Cloud KMS e as chaves gerenciadas externamente no Gerenciador de chaves externas do Cloud (Cloud EKM).
  • Você gerencia o acesso às chaves protegidas por hardware no IAM.
  • Os relatórios de custos para operações criptográficas usando chaves protegidas por hardware são informados no Cloud Billing.
  • É possível usar chaves protegidas por hardware de forma transparente em todos os serviços do Google Cloud que aceitam criptografia de recursos usando CMEK. As integrações de CMEK requerem que a chave e os dados criptografados com CMEK estejam em locais geográficos compatíveis. Devido à rigorosa restrição geográfica das chaves do Cloud HSM, toda criptografia e descriptografia dos dados de CMEK também são restritas geograficamente.
  • As operações administrativas em chaves protegidas por hardware são sempre registradas na camada da API nos registros de auditoria do Cloud. Também é possível ativar a geração de registros de acesso a dados. Para mais informações, consulte Informações sobre registros de auditoria do Cloud KMS.
  • O Google trabalha diretamente com o fabricante do HSM para manter o hardware e o software atualizados em cada HSM e encontrar e corrigir problemas em tempo real. No caso de uma exploração de zero dia no HSM, o Google poderá desativar seletivamente os caminhos de código afetados nos clusters do HSM afetados até que a exploração seja corrigida.
  • É possível rastrear suas chaves, incluindo as protegidas por hardware e os recursos que elas criptografam usando os painéis de rastreamento de uso de chaves.

Experiência do desenvolvedor e do usuário

Como o Google é responsável pelo gerenciamento de HSM, o Cloud HSM oferece benefícios significativos para os desenvolvedores e usuários finais.

HSMs na escala do Google

Quando você depende de hardware que exista no local ou em data centers, o hardware pode criar um gargalo de desempenho ou se tornar um ponto único de falha. O Cloud HSM foi projetado para ser extremamente resiliente a cargas de trabalho previsíveis e falhas de hardware. O back-end do Cloud HSM usa um pool de HSMs em cada região para garantir alta disponibilidade e escalonabilidade. Esse pool de HSMs permite que o Cloud HSM também forneça alta capacidade. Para mais informações, consulte Monitorar e ajustar as cotas do Cloud KMS.

Todas as chaves do cliente são armazenadas encapsuladas por uma chave de encapsulamento regional no banco de dados do Cloud KMS e só podem ser desencapsuladas por um HSM na região como parte de uma operação criptográfica. Esse wrapper tem os seguintes benefícios:

  • A durabilidade de uma chave não está vinculada a um HSM ou subconjunto específico de HSMs em uma região.
  • Cada cliente do Cloud HSM tem a escala e a disponibilidade completas dos clusters do Cloud HSM que disponibilizam as chaves.
  • O Cloud HSM pode lidar com um conjunto muito maior de chaves que podem ser armazenadas em um HSM.
  • Adicionar ou substituir um HSM é rápido e seguro.

Design de API unificado

O Cloud HSM e o Cloud KMS compartilham uma API de plano de dados e gerenciamento comum. Os detalhes internos da comunicação com um HSM são abstraídos do autor da chamada.

Consequentemente, nenhuma mudança de código é necessária para atualizar um aplicativo atual que usa chaves de software no Cloud KMS para oferecer suporte a chaves protegidas por hardware. Em vez disso, atualize o nome do recurso da chave a ser usada.

Suporte para PKCS#11

Use a API Cloud Key Management Service para conectar seus aplicativos ao Cloud HSM e gerenciar chaves criptográficas. A biblioteca PKCS#11 permite usar chaves protegidas por hardware para assinar seus binários e disponibilizar sessões da Web TLS.

Segurança e conformidade regulatória

O Cloud HSM está em conformidade com várias regulamentações, incluindo FedRAMP High, C5:2020 e OSPAR. Além disso, o Cloud HSM ajuda a aplicar a conformidade regulatória para suas cargas de trabalho na nuvem.

Atestado de chave criptográfica

Sempre que você gera ou importa uma chave do Cloud HSM, o HSM gera uma declaração de atestado assinada com uma chave de assinatura associada à partição. A instrução contém informações sobre os atributos da chave. A chave de assinatura é usada por cadeias de certificados com acesso root no Google e no fabricante do HSM. É possível fazer o download da declaração e dos certificados de atestado para verificar a autenticidade da instrução e validar as propriedades da chave e do HSM que a gerou ou importou.

A cadeia de certificados permite verificar o seguinte:

  • O hardware e o firmware do HSM são originais.
  • A partição e o HSM são gerenciados pelo Google.
  • O HSM está no modo de operação do FIPS.

O conteúdo da declaração de atestado permite verificar o seguinte:

  • A chave não é extraível.
  • A chave foi gerada para a CryptoKeyVersion.
  • A chave pública em um par de chaves assimétricas corresponde a uma chave privada protegida por hardware.
  • O material da chave simétrica importada corresponde ao valor que você encapsula.

Importação segura de chaves diretamente para HSMs

É possível importar as chaves atuais com segurança para o Cloud HSM. Assim, é possível manter um backup do material das suas chaves fora do Google Cloudou simplificar a migração de determinadas cargas de trabalho para o Google Cloud. O processo de importação de chaves não permite que o Google tenha acesso direto ao material da chave desencapsulada. O Cloud HSM fornece uma instrução de atestado para a chave de encapsulamento gerada pelo HSM para validar se nenhum acesso ocorreu.

Como a importação de chaves pode criar riscos de segurança e conformidade, permitindo que os usuários tragam chaves de fontes desconhecidas, os papéis separados do IAM permitem um controle refinado sobre quem pode importar chaves para um projeto. As chaves importadas podem ser diferenciadas pela declaração de atestado que o HSM gera na importação.

Para mais informações, consulte Como importar uma chave para o Cloud Key Management Service.

Procedimentos de segurança rigorosos protegem o hardware do HSM

Conforme exigido pelo FIPS 140-2 de nível 3, os dispositivos HSM têm mecanismos integrados para ajudar a proteger contra erros e fornecer evidências de adulterações físicas.

Além das garantias fornecidas pelo próprio hardware do HSM, a infraestrutura do Cloud HSM é gerenciada de acordo com a Visão geral do design de segurança da infraestrutura do Google.

Os seguintes procedimentos documentados e auditáveis protegem a integridade de cada HSM durante o provisionamento, a implantação e a produção:

  • Todas as configurações do HSM precisam ser verificadas por vários SREs do Cloud HSM antes que o HSM possa ser implantado em um data center.
  • Depois que um HSM é colocado em serviço, a alteração da configuração só pode ser iniciada e verificada por vários SREs do Cloud HSM.
  • Um HSM só pode receber firmwares assinados pelo fabricante do HSM.
  • O hardware HSM não é diretamente exposto a nenhuma rede.
  • Os servidores que hospedam o hardware HSM são impedidos de executar processos não autorizados.

Os deveres dos operadores do sistema são definidos nos procedimentos operacionais padrão. Os operadores do sistema são impedidos de acessar, usar ou extrair o material da chave do cliente durante o desempenho das tarefas.

Isolamento de locatários e serviços

A arquitetura do Cloud HSM garante que os HSMs estejam protegidos contra interferências maliciosas ou acidentais de outros serviços ou locatários.

Um HSM que faz parte dessa arquitetura aceita solicitações apenas do Cloud HSM, e o serviço do Cloud HSM aceita solicitações somente do serviço do Cloud KMS. O serviço Cloud KMS impõe que os autores da chamada tenham as permissões do IAM adequadas nas chaves que tentam usar. Solicitações não autorizadas não alcançam HSMs.

Elas também estão sujeitas a cotas para operações criptográficas. Essas cotas protegem sua capacidade de executar suas cargas de trabalho ao ajudar a impedir tentativas mal-intencionadas ou maliciosas de sobrecarregar o serviço. As cotas padrão são baseadas em padrões de uso observados. As cotas estão significativamente abaixo da capacidade do serviço e podem ser aumentadas mediante solicitação.

Fluxos de solicitação

Nesta seção, demonstramos como a arquitetura do Cloud HSM se aplica na prática, mostrando as etapas para diferentes tipos de solicitações. Esses fluxos enfatizam as partes do Cloud HSM. Para mais informações sobre as etapas comuns a todas as chaves, consulte a análise detalhada do Cloud Key Management Service.

Como criar chaves

Quando você cria uma chave protegida por hardware, a API Cloud Key Management Service não cria o material da chave, mas solicita que o HSM o crie.

Um HSM só pode criar chaves em locais compatíveis. Cada partição em um HSM contém uma chave de encapsulamento correspondente a um local do Cloud KMS. A chave de encapsulamento é compartilhada entre todas as partições compatíveis com o local do Cloud KMS.

O diagrama a seguir mostra como as chaves protegidas por hardware são encapsuladas no Cloud KMS.

Diagrama de criação de chave HSM.

O processo de criação de chaves é semelhante ao seguinte:

  1. O Google Front End Service (GFE) encaminha a solicitação de criação de chave para um servidor do Cloud KMS no local correspondente à solicitação.
  2. A API Cloud Key Management Service verifica a identidade do autor da chamada, a permissão do autor da chamada para criar chaves no projeto e se o autor da chamada tem cota de solicitação de gravação suficiente.
  3. A API Cloud Key Management Service encaminha a solicitação para o Cloud HSM.
  4. O Cloud HSM interage diretamente com o HSM. HSM:
    1. Cria a chave e a encapsula com a chave de união específica do local.
    2. Cria a declaração de atestado para a chave e a assina com a chave de assinatura da partição.
  5. Depois que o Cloud HSM retorna a chave e o atestado encapsulados ao Cloud KMS, a API Cloud Key Management Service une a chave encapsulada com o HSM de acordo com a hierarquia de chaves do Cloud KMS e a grava no projeto.

Esse design garante que a chave não possa ser desencapsulada ou usada fora de um HSM, não possa ser extraída do HSM e exista no estado descompactado somente nos locais especificados.

Operações criptográficas

Ao executar uma operação criptográfica no Cloud KMS, você não precisa saber se está usando uma chave protegida por hardware ou software. Quando a API Cloud Key Management Service detecta que uma operação envolve uma chave protegida por hardware, ela encaminha a solicitação para um HSM no mesmo local. Siga estas etapas para uma operação criptográfica:

  1. O GFE encaminha a solicitação para um servidor do Cloud KMS no local adequado. A API Cloud Key Management Service verifica a identidade do autor da chamada, a permissão do autor da chamada para acessar a chave e executar a operação, além da cota do projeto para operações criptográficas.
  2. A API Cloud Key Management Service recupera a chave encapsulada do armazenamento de dados e descriptografa um nível de criptografia usando a chave mestra do Cloud KMS. A chave ainda estará encapsulada com a chave de encapsulamento do HSM para o local do KMS.
  3. A API Cloud Key Management Service detecta que o nível de proteção é HSM e envia a chave parcialmente desencapsulada com as entradas para a operação criptográfica para o Cloud HSM.
  4. O Cloud HSM interage diretamente com o HSM. O HSM conclui as seguintes operações:
    1. Verifica se a chave encapsulada e os atributos dela não foram modificados.
    2. Desencapsula a chave e a carrega no armazenamento do HSM.
    3. Executa a operação criptográfica e retorna o resultado.
  5. A API Cloud Key Management Service transmite o resultado de volta ao autor da chamada.

As operações criptográficas que usam chaves protegidas por hardware são realizadas inteiramente em um HSM no local configurado, e somente o resultado é visível para o autor da chamada.

Este diagrama mostra a diferença entre a criação de chaves protegidas por hardware e por software no Cloud KMS.

Integrações com CMEK

Todas as chaves protegidas por hardware são CMEKs. Configurar um serviço ativado para CMEK para usar chaves do Cloud HSM é tão simples quanto escolher uma chave com um nível de proteção HSM ao seguir as instruções específicas do serviço.

Quando o autor da chamada lê ou grava dados em um serviço ativado para CMEK, ele não precisa de permissão direta para usar a chave e não precisa saber se a chave está armazenada em um HSM.

O mesmo fluxo de operação da CMEK é usado com chaves protegidas por hardware e por software, com as seguintes exceções ao usar chaves protegidas por hardware:

  • A solicitação do serviço ativado para CMEK é iniciada na rede do Google e não precisa passar pelo GFE.
  • A API Cloud Key Management Service verifica se a conta de serviço do serviço ativado para CMEK tem permissões adequadas para usar a chave. A API Cloud Key Management Service não valida permissões do usuário final do serviço ativado para CMEK.

O Cloud HSM é necessário se você quiser usar o Autokey para provisionar chaves do Cloud KMS. Com o Autokey, o agente de serviço do Cloud KMS provisiona chaves protegidas por hardware automaticamente mediante solicitação. Para mais informações, consulte Provisionamento automático para CMEK.

Usar seus próprios HSMs

Os HSMs usados pelo Cloud HSM são gerenciados pelo Google. No entanto, em determinadas circunstâncias, sua organização pode querer usar os próprios HSMs para armazenar as chaves protegidas por hardware das cargas de trabalho. Por exemplo, usar seus próprios HSMs pode ajudar na migração das cargas de trabalho para o Google Cloud.

Em alguns locais, o Google oferece um HSM de infraestrutura como serviço que fornece operações de chaves criptográficas para transações criptográficas seguras emGoogle Cloud. Os produtos são conhecidos como Bare Metal Rack HSM e Bare Metal HSM. Com o HSM de rack bare metal ou o HSM bare metal, você compra e configura seus próprios HSMs e os envia para os data centers do Google, para que possam ser hospedados pelo Google. Você mantém o acesso lógico total aos HSMs e precisa trabalhar diretamente com o fornecedor para gerenciar e resolver problemas nos dispositivos. O Google oferece segurança física e de rede, espaço em rack, energia e integração de rede por uma taxa. Para mais informações, consulte HSM de rack Bare Metal e HSM Bare Metal.

A seguir

Acesse estes recursos para saber mais: