Este conteúdo foi atualizado pela última vez em janeiro de 2025 e representa o status quo à data da sua redação. As políticas e os sistemas de segurança da Google podem mudar no futuro, uma vez que melhoramos continuamente a proteção dos nossos clientes.
O Cloud HSM faz parte da arquitetura do Cloud Key Management Service (Cloud KMS) e fornece o back-end para o aprovisionamento e a gestão de chaves protegidas por hardware. Para ajudar a cumprir os regulamentos corporativos e de conformidade, o Cloud HSM permite-lhe gerar as suas chaves de encriptação e realizar operações criptográficas em módulos de segurança de hardware (HSM) certificados de nível 3 da FIPS 140-2.
Este artigo descreve a arquitetura do Cloud HSM, incluindo a forma como o hardware é gerido e as chaves são atestadas e criadas. Para mais informações sobre o Cloud KMS, consulte o artigo Encriptação do Cloud Key Management Service.
Vista geral
As operações criptográficas incluem o seguinte:
- Encriptação de dados em repouso
- Proteger as chaves privadas do serviço de autoridade de certificação
- Proteger as chaves de encriptação de dados para que possam ser armazenadas juntamente com os dados encriptados
- Gerar e usar chaves assimétricas para operações criptográficas, como assinaturas digitais e autenticação
O Cloud HSM usa HSMs Marvell LiquidSecurity (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 acerca da nossa certificação, consulte o certificado n.º 4399. Para informações sobre os dispositivos HSM e as chaves protegidas por hardware, consulte a atestação de chaves.
O Cloud HSM é totalmente gerido para que possa proteger as suas cargas de trabalho sem as despesas gerais operacionais da gestão de um cluster de HSM. O serviço oferece as seguintes vantagens:
- Disponibilidade global
- Uma API consistente e unificada
- Escala automática com base na sua utilização
- Gestão centralizada e conformidade regulamentar
O HSM na nuvem está disponível em todas as Google Cloud regiões do mundo, incluindo várias regiões que abrangem áreas geográficas maiores. Tem de usar o endpoint do serviço Cloud KMS para criar e usar chaves protegidas por hardware no Cloud HSM para proteger os seus dados, incluindo os dados que armazena noutrosGoogle Cloud serviços, como o BigQuery, o Cloud Storage e o Persistent Disk.
Com o HSM na nuvem, pode usar chaves protegidas por hardware sem ter de gerir o hardware do HSM. A Google é proprietária e gere o hardware do HSM, incluindo a implementação, a configuração, a monitorização, a aplicação de patches e a manutenção. Quando usa o Cloud HSM, os seus dados estão estritamente isolados de outros inquilinos 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-lhe gerir chaves protegidas por hardware de forma programática.
O Cloud HSM suporta a chave automática do Cloud KMS protegida por hardware e as chaves de encriptação geridas pelo cliente (CMEK), sempre que as chaves CMEK forem suportadas pelos Google Cloud serviços. Por exemplo, pode encriptar dados em contentores do Cloud Storage ou tabelas do Cloud SQL com uma chave do Cloud HSM que gere.
Gestão do Cloud HSM
No Cloud HSM, os clusters de HSMs são mantidos por engenheiros de fiabilidade do site (SREs) e técnicos da Google que trabalham em cada Google Cloud localização do centro de dados. A Google trata da segurança física, da segurança lógica, da infraestrutura, do planeamento da capacidade, da expansão geográfica e do planeamento de recuperação de desastres do centro de dados.
Abstração do hardware HSM
Normalmente, as aplicações comunicam diretamente com os HSMs através do PKCS#11 e de uma API de gestão de clusters. Esta comunicação requer que mantenha um código especializado para cargas de trabalho que usam ou gerem chaves protegidas por hardware.
O HSM na nuvem abstrai a comunicação do HSM através do proxying de pedidos de chaves protegidas por hardware através da API Cloud Key Management Service. A abstração reduz a necessidade de código específico do HSM. O Cloud HSM herda a integração estreita com o Cloud KMS.
A integração estreita com o Cloud KMS oferece vantagens de segurança substanciais. A API Cloud Key Management Service reduz significativamente a amplitude da interface HSM disponível, o que reduz o risco em caso de violação de segurança do cliente. Por exemplo, um atacante não conseguiria limpar HSMs inteiros. Por predefinição, as tentativas de destruir chaves individuais são mitigadas através de um período de segurança de 30 dias predefinido. Pode definir a política da organização constraints/cloudkms.minimumDestroyScheduledDuration para aplicar uma duração mínima para a duração agendada para destruição para novas chaves e a política da organização constraints/cloudkms.disableBeforeDestroy para eliminar versões de chaves apenas quando estiverem desativadas. Para mais informações, consulte o artigo
Controle a destruição da versão da chave.
Pode controlar o acesso aos recursos do HSM através da gestão de identidade e de acesso (IAM). É menos provável que a configuração da IAM sofra de configurações incorretas e erros do que uma solução HSM personalizada.
O diagrama seguinte mostra a arquitetura do Cloud HSM.
Separação geográfica rigorosa, por design
No Cloud HSM, pode optar por disponibilizar as chaves globalmente ou aplicar restrições geográficas rigorosas às chaves que requerem restrições.
Muitas vezes, os HSMs são divididos em partições, para que um único dispositivo físico possa funcionar como vários dispositivos lógicos. Pode usar partições para reduzir os custos de implementação nos casos em que precisa de separar a administração e as chaves do HSM. O diagrama seguinte mostra as partições em três regiões.
Para isolar as chaves de cada região e de várias regiões, cada região do Cloud HSM está associada a uma chave de união regional do HSM separada (consulte o diagrama em Criar chaves). Para suportar a alta disponibilidade, a chave de encapsulamento é clonada em partições em cada HSM localizado fisicamente na região. As chaves regionais do HSM não saem do HSM nessa localização. A clonagem permite que os HSMs na mesma região sirvam o mesmo conjunto de chaves do cliente e garante que os HSMs fora da região não podem servir essas chaves.
O Cloud HSM também cria várias regiões através de chaves de encapsulamento. Todas as chaves de cliente para uma região múltipla são envolvidas através de uma chave de envolvimento presente numa partição em todas as localizações que constituem a região múltipla. O serviço usa o mesmo hardware para várias regiões, mas oferece o mesmo isolamento forte entre regiões e várias regiões que existe entre diferentes regiões.
O esquema de regionalização requer que as chaves de encapsulamento sejam replicadas apenas para as partições adequadas. Cada alteração de configuração tem de ser aprovada por vários membros da equipa do HSM na nuvem antes de ficar ativa. Os técnicos do centro de dados não podem aceder a uma configuração, um tempo de execução ou um armazenamento do HSM.
Gestão centralizada
Num centro de dados convencional que aloja HSMs, a gestão dos HSMs e dos respetivos recursos é totalmente separada da gestão de outras chaves protegidas por hardware. O Cloud HSM está estreitamente integrado no Google Cloud, o que lhe permite gerir facilmente os seus recursos do Cloud HSM. Por exemplo, pode gerir o seguinte:
- Pode gerir as suas chaves protegidas por hardware juntamente com as outras chaves no Cloud KMS e as chaves geridas externamente no Cloud External Key Manager (Cloud EKM).
- Pode gerir o acesso a chaves protegidas por hardware na IAM.
- Os relatórios de custos das operações criptográficas que usam chaves protegidas por hardware são comunicados no Cloud Billing.
- Pode usar chaves protegidas por hardware de forma transparente em todos os Google Cloud serviços que suportam a encriptação de recursos através de CMEK. As integrações da CMEK requerem que a chave CMEK e os dados que encripta estejam localizados em localizações geográficas compatíveis. Devido à restrição geográfica rigorosa das chaves do HSM na nuvem, toda a encriptação e desencriptação dos dados CMEK também estão geograficamente restritas.
- As operações administrativas em chaves protegidas por hardware são sempre registadas na camada da API nos registos de auditoria do Cloud. Também pode optar por ativar o registo de acesso aos dados. Para mais informações, consulte as informações de registo de auditoria do Cloud KMS.
- A Google trabalha diretamente com o fabricante do HSM para manter o hardware e o software em cada HSM atualizados, bem como para encontrar e corrigir problemas em tempo real. No caso de uma exploração de dia zero no HSM, a Google pode desativar seletivamente os caminhos de código afetados nos clusters de HSM afetados até que a exploração seja corrigida.
- Pode monitorizar as suas chaves, incluindo as chaves protegidas por hardware e os recursos que encriptam através de painéis de controlo de monitorização da utilização de chaves.
Experiência do utilizador e do programador
Uma vez que a Google é responsável pela gestão do HSM, o Cloud HSM oferece vantagens significativas aos programadores e aos utilizadores finais.
HSMs à escala da Google
Quando confia em hardware existente no local ou em centros de dados, o hardware pode criar um gargalo de desempenho ou tornar-se um único ponto de falha. O HSM na nuvem foi concebido para ser extremamente resiliente a cargas de trabalho imprevisíveis e falhas de hardware. O back-end do Cloud HSM usa um conjunto de HSMs em cada região para garantir a elevada disponibilidade e escalabilidade. Este conjunto de HSMs permite que o Cloud HSM também ofereça um elevado débito. Para mais informações, consulte o artigo Monitorize e ajuste as quotas do Cloud KMS.
Todas as chaves de cliente são armazenadas envolvidas com uma chave de envolvimento regional na base de dados do Cloud KMS e só podem ser desembrulhadas por um HSM na região como parte de uma operação criptográfica. Esta união tem as seguintes vantagens:
- A durabilidade de uma chave não está associada a um HSM específico ou a um subconjunto de HSMs numa região.
- Cada cliente do Cloud HSM usufrui da escala e da disponibilidade totais dos clusters do Cloud HSM que servem as respetivas chaves.
- O HSM na nuvem pode processar um conjunto muito maior de chaves que podem ser armazenadas num HSM.
- A adição ou a substituição de um HSM é rápida e segura.
Design de API unificado
O Cloud HSM e o Cloud KMS partilham uma API de plano de gestão e dados comum. Os detalhes internos da comunicação com um HSM são abstraídos do autor da chamada.
Consequentemente, não são necessárias alterações ao código para atualizar uma aplicação existente que use chaves de software no Cloud KMS para suportar chaves protegidas por hardware. Em alternativa, atualiza o nome do recurso da chave a usar.
Suporte de PKCS#11
Pode usar a API Cloud Key Management Service para associar as suas aplicações existentes ao Cloud HSM para gerir chaves criptográficas. A biblioteca PKCS#11 permite-lhe usar chaves protegidas por hardware para assinar os seus ficheiros binários e publicar sessões Web TLS.
Segurança e conformidade regulamentar
O Cloud HSM obteve a conformidade com vários regulamentos, incluindo FedRAMP High, C5:2020 e OSPAR. Além disso, o HSM na nuvem ajuda a aplicar a conformidade regulamentar às suas cargas de trabalho na nuvem.
Atestação de chaves criptográficas
Sempre que gera ou importa uma chave do HSM na nuvem, o HSM gera uma declaração de atestação assinada com uma chave de assinatura associada à partição. A declaração contém informações sobre os atributos da sua chave. A chave de assinatura é suportada por cadeias de certificados baseadas na Google e no fabricante do HSM. Pode transferir a declaração de atestação e os certificados para verificar a autenticidade da declaração e validar as propriedades da chave e do HSM que a gerou ou importou.
A cadeia de certificados permite-lhe verificar o seguinte:
- O hardware e o firmware do HSM são genuínos.
- A partição do HSM e o HSM são geridos pela Google.
- O HSM está no modo de funcionamento FIPS.
O conteúdo da declaração de atestação permite-lhe verificar o seguinte:
- A chave não é extraível.
- A chave foi gerada para a sua CryptoKeyVersion.
- A chave pública num par de chaves assimétricas corresponde a uma chave privada protegida por hardware.
- O material da chave de uma chave simétrica importada corresponde ao valor que encapsulou.
Importação segura de chaves diretamente para HSMs
Pode importar com segurança chaves existentes para o Cloud HSM para manter uma cópia de segurança do seu material de chaves fora do Google Cloudou para simplificar a migração de determinadas cargas de trabalho para o Google Cloud. O processo de importação de chaves não permite à Google qualquer acesso direto ao material de chaves não processado. O Cloud HSM fornece uma declaração de atestação para a chave de união gerada pelo HSM para validar que não ocorreu nenhum acesso.
Uma vez que a importação de chaves cria potencialmente riscos de segurança e conformidade ao permitir que os utilizadores obtenham chaves de origens desconhecidas, as funções do IAM separadas permitem um controlo detalhado sobre quem pode importar chaves para um projeto. As chaves importadas podem ser distinguidas pela declaração de atestação que o HSM gera na importação.
Para mais informações, consulte o artigo Importar uma chave para o Serviço de gestão de chaves na nuvem.
Os procedimentos de segurança rigorosos protegem o hardware do HSM
Conforme exigido pelo nível 3 da FIPS 140-2, os dispositivos HSM têm mecanismos incorporados para ajudar a proteger contra adulteração física e fornecer provas da mesma.
Além das garantias fornecidas pelo próprio hardware HSM, a infraestrutura do Cloud HSM é gerida de acordo com a vista geral do design de segurança da infraestrutura da Google.
Os seguintes procedimentos documentados e auditáveis protegem a integridade de cada HSM durante o aprovisionamento, a implementação e a produção:
- Todas as configurações de HSM têm de ser validadas por vários SREs do Cloud HSM antes de o HSM poder ser implementado num centro de dados.
- Após a colocação de um HSM em serviço, a alteração da configuração só pode ser iniciada e validada por vários SREs do Cloud HSM.
- Um HSM só pode receber firmware assinado pelo fabricante do HSM.
- O hardware do HSM não está diretamente exposto a nenhuma rede.
- Os servidores que alojam hardware HSM são impedidos de executar processos não autorizados.
As funções dos operadores de sistemas estão definidas em procedimentos operacionais padrão. Os operadores do sistema não podem aceder, usar nem extrair material de chaves do cliente enquanto desempenham as suas funções.
Isolamento de serviços e inquilinos
A arquitetura do HSM na nuvem garante que os HSMs estão protegidos contra interferências maliciosas ou inadvertidas de outros serviços ou inquilinos.
Um HSM que faz parte desta arquitetura aceita pedidos apenas do Cloud HSM, e o serviço Cloud HSM aceita pedidos apenas do serviço Cloud KMS. O serviço Cloud KMS garante que os autores das chamadas têm as autorizações do IAM adequadas nas chaves que tentam usar. Os pedidos não autorizados não chegam aos HSMs.
As chaves protegidas por hardware também estão sujeitas a quotas para operações criptográficas. Estas quotas protegem a sua capacidade de executar as cargas de trabalho, ajudando a evitar tentativas inadvertidas ou maliciosas de sobrecarregar o serviço. As quotas predefinidas baseiam-se nos padrões de utilização observados. As quotas estão significativamente abaixo da capacidade do serviço e podem ser aumentadas mediante pedido.
Fluxos de pedidos
Esta secção demonstra como a arquitetura do HSM na nuvem se aplica na prática, mostrando os passos para diferentes tipos de pedidos. Estes fluxos realçam as partes do Cloud HSM. Para mais informações sobre os passos comuns a todas as chaves, consulte a análise detalhada do Serviço de gestão de chaves na nuvem.
Criação de chaves
Quando cria uma chave protegida por hardware, a API Cloud Key Management Service não cria o material da chave, mas pede ao HSM que o crie.
Um HSM só pode criar chaves em localizações que suporta. Cada partição num HSM contém uma chave de encapsulamento correspondente a uma localização do Cloud KMS. A chave de união é partilhada entre todas as partições que suportam a localização do Cloud KMS.
O diagrama seguinte mostra como as chaves protegidas por hardware são envolvidas no Cloud KMS.
O processo de criação de chaves tem o seguinte aspeto:
- O serviço Google Front End (GFE) encaminha o pedido de criação de chaves para um servidor do Cloud KMS na localização que corresponde ao pedido.
- A API Cloud Key Management Service valida a identidade do autor da chamada, a autorização do autor da chamada para criar chaves no projeto e se o autor da chamada tem uma quota de pedidos de gravação suficiente.
- A Cloud Key Management Service API encaminha o pedido para o Cloud HSM.
- O Cloud HSM interage diretamente com o HSM. O HSM:
- Cria a chave e envolve-a com a chave de envolvimento específica da localização.
- Cria a declaração de atestação para a chave e assina-a com a chave de assinatura da partição.
- Depois de o Cloud HSM devolver a chave envolvida e a atestação ao Cloud KMS, a API Cloud Key Management Service envolve a chave envolvida pelo HSM de acordo com a hierarquia de chaves do Cloud KMS e, em seguida, escreve-a no projeto.
Este design garante que não é possível desembrulhar nem usar a chave fora de um HSM, que não é possível extraí-la do HSM e que existe no respetivo estado desembrulhado apenas em localizações especificadas.
Operações criptográficas
Quando realiza uma operação criptográfica no Cloud KMS, não precisa de saber se está a usar uma chave protegida por hardware ou por software. Quando a API Cloud Key Management Service deteta que uma operação envolve uma chave protegida por hardware, reencaminha o pedido para um HSM na mesma localização. Seguem-se os passos para uma operação criptográfica:
- O GFE encaminha o pedido para um servidor do Cloud KMS na localização adequada. A API Cloud Key Management Service valida a identidade do autor da chamada, a autorização do autor da chamada para aceder à chave e realizar a operação, e a quota do projeto para operações criptográficas.
- A API Cloud Key Management Service obtém a chave envolvida do repositório de dados e desencripta um nível de encriptação através da chave principal do Cloud KMS. A chave continua a ser envolvida com a chave de envolvimento do HSM para a localização do KMS.
- A API Cloud Key Management Service deteta que o nível de proteção é HSM e envia a chave parcialmente desembrulhada, juntamente 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:
- Verifica se a chave envolvida e os respetivos atributos não foram modificados.
- Desembrulha a chave e carrega-a no armazenamento do HSM.
- Executa a operação criptográfica e devolve o resultado.
- A Cloud Key Management Service API transmite o resultado de volta ao autor da chamada.
As operações criptográficas que usam chaves protegidas por hardware são realizadas inteiramente num HSM na localização configurada, e apenas 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 chaves protegidas por software no Cloud KMS.
Integrações de CMEK
Todas as chaves protegidas por hardware são CMEKs. Configurar um serviço com CMEK para usar chaves do Cloud HSM é tão simples como escolher uma chave com um nível de proteção do HSM quando segue as instruções específicas do serviço.
Quando um autor da chamada lê ou escreve dados num serviço ativado para CMEK, o autor da chamada não precisa de autorização direta para usar a chave e não precisa de saber se a chave está armazenada num HSM.
O mesmo fluxo de operações CMEK é usado com chaves protegidas por hardware e chaves protegidas por software, com as seguintes exceções quando usa chaves protegidas por hardware:
- O pedido do serviço ativado com CMEK é iniciado na rede da Google e não precisa de atravessar o GFE.
- A API Cloud Key Management Service verifica se a conta de serviço do serviço com a CMEK ativada tem as autorizações adequadas para usar a chave. A API Cloud Key Management Service não valida as autorizações do utilizador final do serviço ativado com CMEK.
O Cloud HSM é necessário se quiser usar o Autokey para aprovisionar chaves do Cloud KMS. A funcionalidade Autokey permite que o agente do serviço Cloud KMS forneça automaticamente chaves protegidas por hardware a pedido. Para mais informações, consulte o artigo Aprovisionamento automático para CMEK.
Use os seus próprios HSMs
Os HSMs usados pelo Cloud HSM são geridos pela Google. No entanto, em determinadas circunstâncias, a sua organização pode querer usar os seus próprios HSMs para armazenar as chaves protegidas por hardware para as suas cargas de trabalho. Por exemplo, a utilização dos seus próprios HSMs pode ajudar a migrar as cargas de trabalho para o Google Cloud.
Apenas em determinadas localizações, a Google oferece um HSM de infraestrutura como serviço que fornece operações de chaves criptográficas para transações criptográficas seguras em Google 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, compra e configura os seus próprios HSMs e, em seguida, envia-os para os centros de dados da Google, para que possam ser alojados pela Google. Mantém o acesso lógico total aos seus HSMs e tem de trabalhar diretamente com o fornecedor do HSM para gerir e resolver problemas dos seus dispositivos. A Google fornece segurança física e de rede, espaço em bastidor, energia e integração de rede mediante uma taxa. Para mais informações, consulte os artigos HSM de rack Bare Metal e HSM Bare Metal.
O que se segue?
Para saber mais, explore os seguintes recursos:
- Documentação do Cloud HSM
- Documentação do Cloud KMS
- Encriptação do Cloud Key Management Service
- Vista geral do design de segurança da infraestrutura da Google
- Encriptação de dados em repouso