Arquitetura do Cloud HSM

Este conteúdo foi atualizado pela última vez em outubro 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, à medida 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.

O HSM na nuvem oferece dois níveis de proteção para chaves suportadas por hardware:

  • HSM na nuvem multi-inquilino: as chaves multi-inquilino estão alojadas em clusters de HSMs que servem vários Google Cloud clientes.
  • HSM na nuvem de inquilino único: as chaves de inquilino único estão alojadas em partições dedicadas em clusters de HSMs, onde cada partição serve apenas um cliente. Cria e gere as suas próprias instâncias do HSM na nuvem de inquilino único, que estão criptograficamente isoladas de outrosGoogle Cloud clientes. As instâncias do Cloud HSM de inquilino único incorrem em custos adicionais em comparação com as chaves do Cloud HSM de vários inquilinos. Para mais informações, consulte o artigo HSM na nuvem de inquilino único.

Ao longo deste guia, as referências ao Cloud HSM referem-se ao Cloud HSM multiinquilino e ao Cloud HSM de inquilino único.

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 HSM na nuvem multi-inquilino é totalmente gerido para que possa proteger as suas cargas de trabalho sem a sobrecarga operacional da gestão de um cluster de HSM. O HSM na nuvem de inquilino único é gerido em conjunto pelos administradores da sua instância e pela Google. O serviço Cloud HSM 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 multi-inquilino está disponível em muitas Google Cloud regiões em todo o mundo, incluindo várias regiões que abrangem geografias maiores. O HSM na nuvem de inquilino único está disponível num subconjunto destas regiões. Tem de usar o ponto final 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 noutros Google 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 de 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 chaves de encriptação geridas pelo cliente (CMEKs) protegidas por hardware, sempre que as CMEKs são suportadas pelos serviços Google Cloud . Por exemplo, pode encriptar dados em contentores do Cloud Storage ou tabelas do Cloud SQL com uma chave do Cloud HSM que gere. O HSM na nuvem multiinquilino também suporta a chave automática do KMS na nuvem para a criação e a gestão simplificadas de CMEKs.

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 ao encaminhar 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). A configuração da IAM tem menor probabilidade de sofrer de configurações incorretas e erros do que uma solução HSM personalizada. Além dos controlos da IAM, a gestão de uma instância do HSM na nuvem de inquilino único também requer a autenticação de dois fatores (2FA) de um quorum de, pelo menos, dois aprovadores designados. Quando cria uma instância, decide quantas aprovações são necessárias para cada alteração a uma instância do HSM na nuvem de inquilino único. As aprovações requerem desafios que são assinados com material de chave privada que cria fora do Google Cloud.

O diagrama seguinte mostra a arquitetura do Cloud HSM.

Diagrama da arquitetura do Cloud HSM.

Separação geográfica rigorosa, por design

No HSM na nuvem multiinquilino, pode optar por disponibilizar as chaves globalmente ou aplicar restrições geográficas rigorosas às chaves que exigem restrições. O HSM na nuvem de inquilino único só está disponível em regiões individuais.

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 partições do HSM na nuvem multiinquilino em três regiões.

Diagrama da geografia do Cloud HSM com partições do Cloud HSM multiinquilino.

Para isolar as chaves de cada região e 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 elevada 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 de clientes 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.

Quando cria chaves numa instância do Cloud HSM de inquilino único, as chaves de encapsulamento nas suas partições dedicadas garantem que as suas chaves não podem ser publicadas fora das suas partições ou da região.

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 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. Quando usa o Cloud HSM multiinquilino, não tem de fazer nada para manter os seus clusters de HSM. Quando usa o Cloud HSM de inquilino único, é responsável pelas operações de manutenção contínuas do cluster através da CLI gcloud.

Existem quatro principais perfis de utilizador para usar o Cloud HSM:

  • Utilizadores finais: normalmente, o HSM na nuvem é transparente para os utilizadores finais dos seus produtos e recursos. Por exemplo, se os seus Google Cloud recursos estiverem protegidos com uma CMEK, os dados são automaticamente encriptados e desencriptados conforme necessário para os seus utilizadores pelos agentes de serviço.
  • Programadores: os seus programadores usam as chaves do Cloud HSM. Se usar o Autokey, os seus programadores podem pedir novas chaves a pedido. Se não usar o Autokey, os administradores do Cloud KMS criam e gerem chaves para os seus programadores usarem.
  • Administradores do Cloud KMS: os administradores do Cloud KMS são responsáveis por criar e alternar as chaves do Cloud HSM. Também podem gerir as suas definições do Autokey ou políticas da organização, se estas responsabilidades não forem tratadas por administradores da organização dedicados.
  • Administradores do Cloud HSM de inquilino único: se usar o Cloud HSM de inquilino único, tem de ter uma equipa de administradores em quem confia para aprovar as operações de criação e manutenção nas suas instâncias do Cloud HSM de inquilino único. As funções de IAM separadas controlam quem está autorizado a propor, aprovar e executar alterações à sua instância. Não é possível aplicar alterações sem aprovação prévia, o que requer autenticação de quórum através de chaves de A2F.

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 nem a um subconjunto de HSMs numa região.
  • Cada cliente do Cloud HSM usufrui da escala total e da disponibilidade 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 dados e gestão 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 da chave desembrulhada. O Cloud HSM fornece uma declaração de atestação para a chave de envolvimento 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 tragam chaves de origens desconhecidas, as funções de 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 Cloud Key Management Service.

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 do HSM na nuvem multiinquilino também estão sujeitas a quotas para operações criptográficas. Estas quotas protegem a sua capacidade de executar as suas 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. Para o HSM na nuvem multiinquilino, cada partição num HSM contém uma chave de envolvimento que corresponde a uma localização do Cloud KMS. Para uma instância do Cloud HSM de inquilino único, a sua partição dedicada usa uma chave de encapsulamento dedicada à sua instância. A chave de união é partilhada entre todas as partições que suportam a localização do Cloud KMS ou a instância do Cloud HSM de inquilino único.

O diagrama seguinte mostra como as chaves protegidas por hardware são envolvidas no Cloud KMS.

Diagrama de criação de chaves HSM.

O processo de criação de chaves tem o seguinte aspeto:

  1. 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.
  2. 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 escrita suficiente. Se o autor da chamada estiver a pedir uma chave do Cloud HSM de inquilino único, a API também verifica se a instância do Cloud HSM de inquilino único selecionada está disponível.
  3. A API Cloud Key Management Service encaminha o pedido para o Cloud HSM.
  4. O Cloud HSM interage diretamente com o HSM. O HSM:
    1. Cria a chave e envolve-a com a chave de envolvimento específica da localização ou da instância.
    2. Cria a declaração de atestação para a chave e assina-a com a chave de assinatura da partição.
  5. 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 a chave não pode ser desembrulhada nem usada fora de um HSM, não pode ser extraída do HSM e 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:

  1. 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.
  2. 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.
  3. A API Cloud Key Management Service deteta que o nível de proteção é HSM ou HSM_SINGLE_TENANT e envia a chave parcialmente desembrulhada, juntamente 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 envolvida e os respetivos atributos não foram modificados.
    2. Desembrulha a chave e carrega-a no armazenamento do HSM.
    3. Executa a operação criptográfica e devolve o resultado.
  5. 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 HSM ou HSM_SINGLE_TENANT quando seguir 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 Rack de HSM de metal nu e HSM de metal nu.

O que se segue?

Para saber mais, explore os seguintes recursos: