Arquitetura do Cloud HSM

Este conteúdo foi atualizado pela última vez em novembro de 2023 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.

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, na sigla em inglês) 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.

Visão geral

As operações criptográficas incluem a criptografia de dados em repouso, a proteção de chaves privadas para o Certificate Authority Service e a proteção de chaves de criptografia de dados para que elas possam ser armazenadas com os dados criptografados. 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.

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 regiões do Google Cloud do mundo, incluindo multirregiões que abrangem áreas geográficas maiores. Depois de ativar o Cloud HSM, é possível criar e usar chaves compatíveis com HSM para proteger seus dados, incluindo os dados armazenados em outros serviços do Google Cloud, como BigQuery, Cloud Storage e Persistent Disk.

Como o Cloud HSM e o hardware do HSM são gerenciados pelo Google, não é necessário gerenciar as chaves compatíveis com o HSM na produçã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 do Cloud Key Management Service, permite gerenciar chaves protegidas por HSM de maneira programática.

O Cloud HSM oferece suporte a chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês) com suporte do HSM, em que as chaves CMEK são compatíveis com o 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. O 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 com suporte de HSM.

O Cloud HSM abstrai a comunicação do HSM, fazendo proxy das solicitações para chaves com suporte do HSM 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 24 horas. É 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.

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.

Cada local regional do Cloud HSM está associado a uma chave de união separada. A chave de união é clonada em uma partição em cada HSM no local, mas nunca deixa o HSM no 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.

Diagrama de geografia do Cloud HSM.

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 no campo.

Gerenciamento centralizado

Em um data center tradicional que hospeda HSMs, o gerenciamento dos HSMs e recursos é totalmente separado do gerenciamento de outros recursos criptográficos. 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 os recursos apoiados pelo HSM com outras chaves no Cloud KMS e as chaves gerenciadas externamente no Gerenciador de chaves externas do Cloud (Cloud EKM).
Você gerencia o acesso aos recursos compatíveis com HSM no IAM.
Os relatórios de custos para operações criptográficas usando chaves compatíveis com HSM são informados no Cloud Billing.
É possível usar chaves compatíveis com HSM de maneira transparente em todos os serviços do Google Cloud compatíveis com recursos de criptografia usando CMEK. As integrações de CMEK requerem a chave e os dados criptografados com CMEK 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 recursos compatíveis com HSM 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 faz uma parceria direta 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.

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 alteração de código é necessária para atualizar um aplicativo atual que usa chaves de software no Cloud KMS para ser compatível com chaves protegidas por HSM. 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 HSM 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 que é 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 com suporte do HSM.
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 Cloud ou 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.

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 Cloud KMS. O Cloud KMS impõe que os autores de chamada tenham as permissões do IAM apropriadas nas chaves que tentam usar. Solicitações não autorizadas não alcançam HSMs.

Elas também estão sujeitas a quotas 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, 3.000 QPM para operações criptográficas assimétricas e 30.000 QPM para operações criptográficas simétricas, 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 os destaques arquitetônicos acima se aplicam 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 com suporte de HSM, 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 processo de criação de chaves é semelhante ao seguinte:

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.
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.
A API Cloud Key Management Service encaminha a solicitação para o Cloud HSM.
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.
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.

O diagrama a seguir mostra as diferenças na criação de chaves do Cloud HSM e de software no Cloud KMS.

Diagrama de criação de chave HSM.

Operações criptográficas

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

O GFE encaminha a solicitação para um servidor do Cloud KMS no local apropriado. 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.
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.
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.
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.
A API Cloud Key Management Service transmite o resultado de volta ao autor da chamada.

Operações criptográficas usando chaves compatíveis com HSM 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 do Cloud HSM e de software no Cloud KMS.

Diagrama de operações de criptografia do HSM.

Integrações com CMEK

A CMEK e o Cloud HSM juntas permitem que você proteja seus dados em serviços selecionados do Google Cloud com chaves HSM. 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 fluxo para uma operação CMEK é muito semelhante ao de uma operação criptográfica normal, com as seguintes exceções:

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 é o serviço de gerenciamento de chaves de hardware do Google Cloud. Ele oferece várias vantagens distintas para os usuários que querem proteger os dados em repouso com as chaves HSM. O serviço foi projetado com os princípios do acesso bloqueado à API para os HSMs, escala sem esforço e regionalização rigorosa das chaves.

O Cloud HSM oferece suporte a CMEK-para os serviços mais importantes e a presença do Cloud HSM em todas as regiões do Google Cloud (incluindo multirregiões e global). O serviço foi projetado para facilitar a proteção dos dados confidenciais, onde quer que eles estejam, com uma chave protegida por dispositivos de nível 3 do FIPS 140-2.

A seguir

Acesse estes recursos para saber mais: