Architettura di Cloud HSM

Questi contenuti sono stati aggiornati per l'ultima volta a ottobre 2025 e rappresentano lo status quo al momento della redazione. I criteri e i sistemi di sicurezza di Google potranno variare in futuro, di pari passo con il nostro impegno al costante miglioramento della protezione dei clienti.

Cloud HSM fa parte dell'architettura di Cloud Key Management Service (Cloud KMS) e fornisce il backend per il provisioning e la gestione delle chiavi protette dall'hardware. Per aiutarti a rispettare le normative aziendali e di conformità, Cloud HSM ti consente di generare le chiavi di crittografia ed eseguire operazioni crittografiche in moduli di sicurezza hardware (HSM) certificati FIPS 140-2 di livello 3.

Cloud HSM fornisce due livelli di protezione per le chiavi supportate dall'hardware:

  • Cloud HSM multi-tenant: le chiavi multi-tenant sono ospitate su cluster di HSM che servono più Google Cloud clienti.
  • Cloud HSM a tenant singolo: le chiavi a tenant singolo sono ospitate in partizioni dedicate su cluster di HSM, dove ogni partizione serve un solo cliente. Crea e gestisci le tue istanze Cloud HSM a tenant singolo, che sono isolate crittograficamente da altri clientiGoogle Cloud . Le istanze Cloud HSM a tenant singolo comportano costi aggiuntivi rispetto alle chiavi Cloud HSM multitenant. Per ulteriori informazioni, consulta Cloud HSM single-tenant.

In questa guida, i riferimenti a Cloud HSM si riferiscono sia a Cloud HSM multitenant sia a Cloud HSM single-tenant.

Questo documento descrive l'architettura di Cloud HSM, incluso il modo in cui l'hardware viene gestito e le chiavi vengono attestate e create. Per saperne di più su Cloud KMS, consulta Crittografia di Cloud Key Management Service.

Panoramica

Le operazioni crittografiche includono quanto segue:

  • Crittografia dei dati inattivi
  • Protezione delle chiavi private per Certificate Authority Service
  • Proteggere le chiavi di crittografia dei dati in modo che possano essere archiviate insieme ai dati criptati
  • Generazione e utilizzo di chiavi asimmetriche per operazioni crittografiche come firme digitali e autenticazione

Cloud HSM utilizza moduli HSM Marvell LiquidSecurity (modelli CNL3560-NFBE-2.0-G e CNL3560-NFBE-3.0-G) con le versioni firmware 3.4 build 09. Per saperne di più sulla nostra certificazione, consulta Certificato n. 4399. Per informazioni sui dispositivi HSM e sulle chiavi protette dall'hardware, vedi attestazione della chiave.

Cloud HSM multitenant è completamente gestito, in modo da poter proteggere i tuoi carichi di lavoro senza il sovraccarico operativo connesso alla gestione di un cluster HSM. Cloud HSM a tenant singolo è gestito congiuntamente dagli amministratori della tua istanza e da Google. Il servizio Cloud HSM offre i seguenti vantaggi:

  • Disponibilità globale
  • Un'API coerente e unificata
  • Scalabilità automatica in base all'utilizzo
  • Gestione centralizzata e conformità normativa

Cloud HSM multitenant è disponibile in molte Google Cloud regioni in tutto il mondo, comprese le multiregioni che coprono aree geografiche più ampie. Cloud HSM a tenant singolo è disponibile in un sottoinsieme di queste regioni. Devi utilizzare l'endpoint del servizio Cloud KMS per creare e utilizzare chiavi protette dall'hardware in Cloud HSM per proteggere i tuoi dati, inclusi quelli archiviati in altri servizi Google Cloud , come BigQuery, Cloud Storage e Persistent Disk.

Con Cloud HSM, puoi utilizzare chiavi protette dall'hardware senza dover gestire tu stesso l'hardware HSM. Google possiede e gestisce l'hardware HSM, inclusi deployment, configurazione, monitoraggio, applicazione di patch e manutenzione. Quando utilizzi Cloud HSM, i tuoi dati sono rigorosamente isolati da altri tenant e servizi in Google Cloud. L'API Cloud HSM Data Plane, che fa parte dell'API Cloud Key Management Service, consente di gestire le chiavi protette dall'hardware in modo programmatico.

Cloud HSM supporta le chiavi di crittografia gestite dal cliente (CMEK) protette dall'hardware, ovunque le CMEK siano supportate dai Google Cloud servizi. Ad esempio, puoi criptare i dati nei bucket Cloud Storage o nelle tabelle Cloud SQL utilizzando una chiave Cloud HSM che gestisci. Cloud HSM multitenant supporta anche Autokey di Cloud KMS per la creazione e la gestione semplificate delle CMEK.

Gestione di Cloud HSM

All'interno di Cloud HSM, i cluster di HSM vengono gestiti dai tecnici e dagli ingegneri SRE (Site Reliability Engineering) di Google che lavorano in ogni Google Cloud data center. Google gestisce la sicurezza fisica, la sicurezza logica, l'infrastruttura, la pianificazione della capacità, l'espansione geografica e la pianificazione del ripristino di emergenza del data center.

Astrazione dell'hardware HSM

In genere, le applicazioni comunicano direttamente con gli HSM utilizzando sia PKCS#11 sia un'API di gestione dei cluster. Questa comunicazione richiede di mantenere codice specializzato per i workload che utilizzano o gestiscono chiavi protette dall'hardware.

Cloud HSM astrae la comunicazione dall'HSM eseguendo il proxy delle richieste di chiavi protette dall'hardware tramite l'API Cloud Key Management Service. L'astrazione riduce la necessità di codice specifico per HSM. Cloud HSM eredita l'integrazione con Cloud KMS.

La stretta integrazione con Cloud KMS offre notevoli vantaggi in termini di sicurezza. L'API Cloud Key Management Service riduce notevolmente l'ampiezza dell'interfaccia HSM disponibile, riducendo il rischio in caso di violazione della sicurezza del cliente. Ad esempio, un malintenzionato non sarebbe in grado di cancellare interi HSM. Per impostazione predefinita, i tentativi di eliminazione delle singole chiavi vengono mitigati tramite un periodo di sicurezza predefinito di 30 giorni. Puoi impostare il criterio dell'organizzazione constraints/cloudkms.minimumDestroyScheduledDuration per applicare una durata minima per l'eliminazione pianificata per le nuove chiavi e il criterio dell'organizzazione constraints/cloudkms.disableBeforeDestroy per eliminare le versioni della chiave solo quando sono disattivate. Per saperne di più, consulta Controllare l'eliminazione della versione della chiave.

Puoi controllare l'accesso alle risorse HSM utilizzando Identity and Access Management (IAM). È meno probabile che la configurazione IAM presenti errori di configurazione e bug rispetto a una soluzione HSM personalizzata. Oltre ai controlli IAM, la gestione di un'istanza Cloud HSM single-tenant richiede anche l'autenticazione a due fattori (2FA) da un quorum di almeno due approvatori designati. Quando crei un'istanza, decidi il numero di approvazioni richieste per ogni modifica a un'istanza Single-tenant Cloud HSM. Le approvazioni richiedono sfide firmate con materiale della chiave privata che crei al di fuori di Google Cloud.

Il seguente diagramma mostra l'architettura di Cloud HSM.

Diagramma dell'architettura di Cloud HSM.

Separazione geografica rigorosa, per progettazione

In Multi-tenant Cloud HSM, puoi scegliere di rendere le chiavi disponibili a livello globale o di applicare restrizioni geografiche rigorose alle chiavi che le richiedono. Cloud HSM a tenant singolo è disponibile solo in singole regioni.

Spesso, gli HSM sono suddivisi in partizioni, in modo che un singolo dispositivo fisico possa funzionare come più dispositivi logici. Puoi utilizzare le partizioni per ridurre i costi di deployment nei casi in cui devi separare l'amministrazione e le chiavi HSM. Il seguente diagramma mostra le partizioni Cloud HSM multitenant in tre regioni.

Diagramma della geografia di Cloud HSM che utilizza partizioni Cloud HSM multi-tenant.

Per isolare le chiavi per ogni regione e multiregione, ogni regione Cloud HSM è associata a una chiave di wrapping regionale HSM separata (vedi il diagramma in Creazione di chiavi). Per supportare l'alta disponibilità, la chiave di wrapping viene clonata sulle partizioni di ogni HSM fisicamente situato nella regione. Le chiavi regionali HSM non escono dall'HSM in quella località. La clonazione consente agli HSM nella stessa regione di gestire lo stesso insieme di chiavi del cliente e garantisce che gli HSM al di fuori della regione non possano gestire queste chiavi.

Cloud HSM crea anche più regioni utilizzando le chiavi di wrapping. Tutte le chiavi del cliente per una multi-regione vengono sottoposte a wrapping utilizzando una chiave di wrapping presente in una partizione in tutte le località che costituiscono la multi-regione. Il servizio utilizza lo stesso hardware per più regioni, ma fornisce lo stesso forte isolamento tra regioni e più regioni che esiste tra regioni diverse.

Lo schema di regionalizzazione richiede che le chiavi di wrapping vengano replicate solo nelle partizioni appropriate. Ogni modifica alla configurazione deve essere approvata da più membri del team Cloud HSM prima di diventare attiva. I tecnici del data center non possono accedere a una configurazione, un runtime o uno spazio di archiviazione HSM.

Quando crei chiavi in un'istanza Cloud HSM single-tenant, le chiavi di wrapping nelle partizioni dedicate assicurano che le chiavi non possano essere utilizzate al di fuori delle partizioni o della regione.

Gestione centralizzata

In un data center convenzionale che ospita HSM, la gestione degli HSM e delle relative risorse è completamente separata dalla gestione di altre chiavi protette dall'hardware. Cloud HSM è strettamente integrato in Google Cloud, il che ti consente di gestire facilmente le risorse Cloud HSM. Ad esempio, puoi gestire quanto segue:

  • Gestisci le chiavi protette dall'hardware insieme alle altre chiavi in Cloud KMS e le chiavi gestite esternamente in Cloud External Key Manager (Cloud EKM).
  • Gestisci l'accesso alle chiavi protette dall'hardware in IAM.
  • I costi per le operazioni di crittografia che utilizzano chiavi protette dall'hardware vengono riportati nella fatturazione Cloud.
  • Puoi utilizzare le chiavi protette dall'hardware in modo trasparente in tutti i servizi Google Cloud che supportano la crittografia delle risorse utilizzando CMEK. Le integrazioni CMEK richiedono che la chiave CMEK e i dati che cripta si trovino in posizioni geografiche compatibili. A causa della rigida limitazione geografica delle chiavi Cloud HSM, anche tutta la crittografia e la decrittografia dei dati CMEK sono geograficamente limitate.
  • Le operazioni amministrative sulle chiavi protette dall'hardware vengono sempre registrate a livello di API in Cloud Audit Logs. Puoi anche scegliere di attivare la registrazione dell'accesso ai dati. Per saperne di più, consulta Informazioni sui log di controllo di Cloud KMS.
  • Google collabora direttamente con il produttore dell'HSM per mantenere aggiornati l'hardware e il software di ogni HSM e per trovare e risolvere i problemi in tempo reale. In caso di exploit zero-day sull'HSM, Google può disattivare selettivamente i percorsi di codice interessati sui cluster HSM interessati fino alla correzione dell'exploit.
  • Puoi monitorare le tue chiavi, incluse quelle protette dall'hardware e le risorse che criptano utilizzando i dashboard di monitoraggio dell'utilizzo delle chiavi.

Esperienza di sviluppo e utente

Poiché Google è responsabile della gestione degli HSM, Cloud HSM offre vantaggi significativi a sviluppatori e utenti finali. Quando utilizzi Cloud HSM multitenant, non devi fare nulla per gestire i cluster HSM. Quando utilizzi Single-tenant Cloud HSM, sei responsabile delle operazioni di manutenzione continua del cluster utilizzando gcloud CLI.

Esistono quattro principali buyer persona per l'utilizzo di Cloud HSM:

  • Utenti finali: Cloud HSM è in genere trasparente per gli utenti finali dei tuoi prodotti e risorse. Ad esempio, se le tue Google Cloud risorse sono protette con una CMEK, i dati vengono criptati e decriptati automaticamente in base alle esigenze dei tuoi utenti dagli agenti di servizio.
  • Sviluppatori: i tuoi sviluppatori utilizzano le chiavi Cloud HSM. Se utilizzi Autokey, gli sviluppatori possono richiedere nuove chiavi on demand. Se non utilizzi Autokey, gli amministratori di Cloud KMS creano e gestiscono le chiavi che gli sviluppatori possono utilizzare.
  • Amministratori Cloud KMS: gli amministratori Cloud KMS sono responsabili della creazione e della rotazione delle chiavi Cloud HSM. Possono anche gestire le impostazioni di Autokey o le policy dell'organizzazione, se queste responsabilità non sono gestite da amministratori dell'organizzazione dedicati.
  • Amministratori di Cloud HSM single-tenant: se utilizzi Cloud HSM single-tenant, devi disporre di un team di amministratori di cui ti fidi per approvare le operazioni di creazione e manutenzione sulle tue istanze Cloud HSM single-tenant. Ruoli IAM separati controllano chi è autorizzato a proporre, approvare ed eseguire modifiche all'istanza. Le modifiche non possono essere applicate senza previa approvazione, che richiede l'autenticazione del quorum utilizzando le chiavi 2FA.

HSM su scala Google

Quando utilizzi hardware on-premise o in data center, l'hardware può creare un collo di bottiglia delle prestazioni o diventare un unico punto di errore. Cloud HSM è progettato per essere estremamente resiliente a carichi di lavoro imprevedibili e guasti hardware. Il backend di Cloud HSM utilizza un pool di HSM in ogni regione per garantire alta disponibilità e scalabilità. Questo pool di HSM consente a Cloud HSM di fornire anche un'elevata velocità effettiva. Per saperne di più, vedi Monitorare e modificare le quote di Cloud KMS.

Tutte le chiavi dei clienti vengono archiviate con wrapping con una chiave di wrapping regionale nel database Cloud KMS e possono essere sottoposte a unwrapping solo da un HSM nella regione nell'ambito di un'operazione di crittografia. Questo wrapping presenta i seguenti vantaggi:

  • La durabilità di una chiave non è legata a un HSM specifico o a un sottoinsieme di HSM in una regione.
  • Ogni cliente Cloud HSM sperimenta la scalabilità e la disponibilità complete dei cluster Cloud HSM che gestiscono le sue chiavi.
  • Cloud HSM può gestire un insieme molto più ampio di chiavi che possono essere archiviate su un HSM.
  • L'aggiunta o la sostituzione di un HSM è rapida e sicura.

Progettazione di API unificate

Cloud HSM e Cloud KMS condividono un'API di gestione e piano dati comune. I dettagli interni della comunicazione con un HSM vengono astratti dal chiamante.

Di conseguenza, non sono necessarie modifiche al codice per aggiornare un'applicazione esistente che utilizza chiavi software in Cloud KMS per supportare chiavi protette dall'hardware. Devi invece aggiornare il nome risorsa della chiave da utilizzare.

Supporto di PKCS#11

Puoi utilizzare l'API Cloud Key Management Service per connettere le tue applicazioni esistenti a Cloud HSM per gestire le chiavi di crittografia. La libreria PKCS#11 ti consente di utilizzare chiavi protette dall'hardware per firmare i tuoi file binari e gestire le sessioni web TLS.

Sicurezza e conformità normativa

Cloud HSM ha ottenuto la conformità a numerosi regolamenti, tra cui FedRAMP High, C5:2020 e OSPAR. Inoltre, Cloud HSM ti aiuta a garantire la conformità normativa per i tuoi carichi di lavoro nel cloud.

Attestazione della chiave di crittografia

Ogni volta che generi o importi una chiave Cloud HSM, l'HSM genera una dichiarazione di attestazione firmata con una chiave di firma associata alla partizione. La dichiarazione contiene informazioni sugli attributi della chiave. La chiave di firma è supportata da catene di certificati che hanno origine sia in Google che nel produttore dell'HSM. Puoi scaricare la dichiarazione di attestazione e i certificati per verificare l'autenticità della dichiarazione e convalidare le proprietà della chiave e dell'HSM che l'ha generata o importata.

La catena di certificati consente di verificare quanto segue:

  • L'hardware e il firmware HSM sono autentici.
  • La partizione HSM e l'HSM sono gestiti da Google.
  • L'HSM è in modalità di funzionamento FIPS.

Il contenuto della dichiarazione di attestazione ti consente di verificare quanto segue:

  • La chiave non è estraibile.
  • La chiave è stata generata per la tua CryptoKeyVersion.
  • La chiave pubblica in una coppia di chiavi asimmetriche corrisponde a una chiave privata protetta dall'hardware.
  • Il materiale della chiave di una chiave simmetrica importata corrisponde al valore di cui hai eseguito il wrapping.

Importazione sicura delle chiavi direttamente negli HSM

Puoi importare in modo sicuro le chiavi esistenti in Cloud HSM per mantenere un backup del materiale della chiave al di fuori di Google Cloudo per semplificare la migrazione di determinati carichi di lavoro a Google Cloud. La procedura di importazione delle chiavi non consente a Google alcun accesso diretto al materiale della chiave decriptato. Cloud HSM fornisce una dichiarazione di attestazione per la chiave di wrapping generata da HSM per convalidare che non si sia verificato alcun accesso.

Poiché l'importazione delle chiavi crea potenzialmente rischi per la sicurezza e la conformità consentendo agli utenti di importare chiavi da origini sconosciute, ruoli IAM separati consentono un controllo granulare su chi può importare chiavi in un progetto. Le chiavi importate possono essere distinte dalla dichiarazione di attestazione generata dall'HSM durante l'importazione.

Per saperne di più, consulta Importare una chiave in Cloud Key Management Service.

Procedure di sicurezza rigorose proteggono l'hardware HSM

Come previsto dallo standard FIPS 140-2 di livello 3, i dispositivi HSM dispongono di meccanismi integrati per contribuire a proteggere dalle manomissioni fisiche e a fornire prove di queste manomissioni.

Oltre alle garanzie fornite dall'hardware HSM stesso, l'infrastruttura per Cloud HSM è gestita in base alla panoramica sulla progettazione della sicurezza dell'infrastruttura di Google.

Le seguenti procedure documentate e verificabili proteggono l'integrità di ogni HSM durante il provisioning, il deployment e la produzione:

  • Tutte le configurazioni HSM devono essere verificate da più SRE Cloud HSM prima che l'HSM possa essere implementato in un data center.
  • Una volta messo in servizio un HSM, la modifica della configurazione può essere avviata e verificata solo da più SRE Cloud HSM.
  • Un HSM può ricevere solo firmware firmati dal produttore dell'HSM.
  • L'hardware HSM non è esposto direttamente a nessuna rete.
  • I server che ospitano hardware HSM non possono eseguire processi non autorizzati.

I compiti degli operatori di sistema sono definiti nelle procedure operative standard. Gli operatori di sistema non possono accedere, utilizzare o estrarre il materiale delle chiavi del cliente durante lo svolgimento delle loro mansioni.

Isolamento di servizi e tenant

L'architettura di Cloud HSM garantisce che gli HSM siano protetti da interferenze dannose o involontarie da parte di altri servizi o tenant.

Un HSM che fa parte di questa architettura accetta richieste solo da Cloud HSM e il servizio Cloud HSM accetta richieste solo dal servizio Cloud KMS. Il servizio Cloud KMS impone che i chiamanti dispongano delle autorizzazioni IAM appropriate per le chiavi che tentano di utilizzare. Le richieste non autorizzate non raggiungono gli HSM.

Le chiavi Cloud HSM multi-tenant sono soggette anche a quote per le operazioni crittografiche. Queste quote proteggono la tua capacità di eseguire i tuoi workload contribuendo a prevenire tentativi involontari o dannosi di sovraccaricare il servizio. Le quote predefinite si basano sui pattern di utilizzo osservati. Le quote sono significativamente inferiori alla capacità del servizio e possono essere aumentate su richiesta.

Flussi di richieste

Questa sezione mostra come viene applicata in pratica l'architettura Cloud HSM illustrando i passaggi per diversi tipi di richieste. Questi flussi mettono in evidenza le parti di Cloud HSM. Per ulteriori informazioni sui passaggi comuni a tutte le chiavi, consulta Approfondimento su Cloud Key Management Service.

Creazione di chiavi

Quando crei una chiave protetta dall'hardware, l'API Cloud Key Management Service non crea il materiale della chiave, ma richiede all'HSM di crearlo.

Un HSM può creare chiavi solo nelle posizioni che supporta. Per Cloud HSM multitenant, ogni partizione di un HSM contiene una chiave di wrapping che corrisponde a una località Cloud KMS. Per un'istanza Single-tenant Cloud HSM, la partizione dedicata utilizza una chiave di wrapping dedicata all'istanza. La chiave di wrapping è condivisa tra tutte le partizioni che supportano la posizione Cloud KMS o l'istanza Cloud HSM single-tenant.

Il seguente diagramma mostra come le chiavi protette dall'hardware vengono sottoposte a wrapping in Cloud KMS.

Diagramma di creazione della chiave HSM.

La procedura di creazione delle chiavi è la seguente:

  1. Il servizio Google Front End (GFE) instrada la richiesta di creazione della chiave a un server Cloud KMS nella località corrispondente alla richiesta.
  2. L'API Cloud Key Management Service verifica l'identità del chiamante, la sua autorizzazione a creare chiavi nel progetto e che disponga di una quota sufficiente di richieste di scrittura. Se il chiamante richiede una chiave Cloud HSM a tenant singolo, l'API verifica anche che l'istanza Cloud HSM a tenant singolo selezionata sia disponibile.
  3. L'API Cloud Key Management Service inoltra la richiesta a Cloud HSM.
  4. Cloud HSM interagisce direttamente con l'HSM. L'HSM:
    1. Crea la chiave e la esegue il wrapping con la chiave di wrapping specifica per la località o per l'istanza.
    2. Crea la dichiarazione di attestazione per la chiave e la firma con la chiave di firma della partizione.
  5. Dopo che Cloud HSM restituisce la chiave sottoposta a wrapping e l'attestazione a Cloud KMS, l'API Cloud Key Management Service esegue il wrapping della chiave sottoposta a wrapping HSM in base alla gerarchia delle chiavi Cloud KMS, quindi la scrive nel progetto.

Questo design garantisce che la chiave non possa essere decrittografata o utilizzata al di fuori di un HSM, non possa essere estratta dall'HSM ed esista nel suo stato decrittografato solo all'interno di posizioni specificate.

Operazioni crittografiche

Quando esegui un'operazione di crittografia in Cloud KMS, non devi sapere se stai utilizzando una chiave protetta dall'hardware o dal software. Quando l'API Cloud Key Management Service rileva che un'operazione coinvolge una chiave protetta dall'hardware, inoltra la richiesta a un HSM nella stessa località. Di seguito sono riportati i passaggi per un'operazione crittografica:

  1. Il GFE instrada la richiesta a un server Cloud KMS nella posizione appropriata. L'API Cloud Key Management Service verifica l'identità del chiamante, la sua autorizzazione ad accedere alla chiave ed eseguire l'operazione e la quota del progetto per le operazioni di crittografia.
  2. L'API Cloud Key Management Service recupera la chiave sottoposta a wrapping dal datastore e decripta un livello di crittografia utilizzando la chiave master Cloud KMS. La chiave è ancora sottoposta a wrapping con la chiave di wrapping HSM per la località KMS.
  3. L'API Cloud Key Management Service rileva che il livello di protezione è HSM o HSM_SINGLE_TENANT e invia la chiave parzialmente sottoposta a wrapping, insieme agli input dell'operazione di crittografia, a Cloud HSM.
  4. Cloud HSM interagisce direttamente con l'HSM. L'HSM completa le seguenti operazioni:
    1. Verifica che la chiave sottoposta a wrapping e i relativi attributi non siano stati modificati.
    2. Estrae la chiave e la carica nello spazio di archiviazione HSM.
    3. Esegue l'operazione crittografica e restituisce il risultato.
  5. L'API Cloud Key Management Service restituisce il risultato al chiamante.

Le operazioni di crittografia che utilizzano chiavi protette dall'hardware vengono eseguite interamente all'interno di un HSM nella posizione configurata e solo il risultato è visibile al chiamante.

Questo diagramma mostra la differenza tra la creazione di chiavi protette dall'hardware e di chiavi protette dal software in Cloud KMS.

Integrazioni CMEK

Tutte le chiavi protette dall'hardware sono CMEK. Configurare un servizio abilitato a CMEK per utilizzare le chiavi Cloud HSM è semplice come scegliere una chiave con un livello di protezione HSM o HSM_SINGLE_TENANT quando segui le istruzioni specifiche del servizio.

Quando un chiamante legge o scrive dati in un servizio abilitato a CMEK, non ha bisogno dell'autorizzazione diretta per utilizzare la chiave e non ha bisogno di sapere se la chiave è memorizzata in un HSM.

Lo stesso flusso di operazioni CMEK viene utilizzato con le chiavi protette dall'hardware e con le chiavi protette dal software, con le seguenti eccezioni quando si utilizzano le chiavi protette dall'hardware:

  • La richiesta dal servizio abilitato a CMEK viene avviata all'interno della rete di Google e non deve attraversare GFE.
  • L'API Cloud Key Management Service verifica che il account di servizio per il servizio abilitato a CMEK disponga delle autorizzazioni appropriate per utilizzare la chiave. L'API Cloud Key Management Service non convalida le autorizzazioni dell'utente finale del servizio abilitato a CMEK.

Cloud HSM è necessario se vuoi utilizzare Autokey per eseguire il provisioning delle chiavi Cloud KMS. Autokey consente all'agente di servizio Cloud KMS di eseguire il provisioning automatico delle chiavi protette dall'hardware su richiesta. Per saperne di più, consulta Provisioning automatico per CMEK.

Utilizzare i propri HSM

Gli HSM utilizzati da Cloud HSM sono gestiti da Google. Tuttavia, in determinate circostanze, la tua organizzazione potrebbe voler utilizzare i propri HSM per archiviare le chiavi protette dall'hardware per i tuoi carichi di lavoro. Ad esempio, l'utilizzo dei tuoi HSM può aiutarti a eseguire la migrazione dei carichi di lavoro a Google Cloud.

Solo in alcune località, Google offre un servizio HSM-as-a-service per l'infrastruttura che fornisce operazioni con chiavi crittografiche per transazioni crittografiche sicure in Google Cloud. I prodotti sono noti come Bare Metal Rack HSM e Bare Metal HSM. Con Bare Metal Rack HSM o Bare Metal HSM, acquisti e configuri i tuoi HSM e poi li spedisci ai data center Google, in modo che possano essere ospitati da Google. Mantieni l'accesso logico completo ai tuoi HSM e devi collaborare direttamente con il fornitore di HSM per gestire e risolvere i problemi dei tuoi dispositivi. Google fornisce sicurezza fisica e di rete, spazio rack, alimentazione e integrazione di rete a pagamento. Per maggiori informazioni, consulta Bare Metal Rack HSM e Bare Metal HSM.

Passaggi successivi

Per ulteriori informazioni, consulta le seguenti risorse: