Crittografia di Cloud Key Management Service

Questi contenuti sono stati aggiornati per l'ultima volta a gennaio 2025 e rappresentano lo status quo al momento della redazione. I criteri e i sistemi di sicurezza di Google potranno variare in futuro, in virtù del costante miglioramento della protezione per i nostri clienti.

Questo documento descrive in che modo Cloud Key Management Service (Cloud KMS) fornisce servizi di gestione delle chiavi in Google Cloud per la crittografia dei dati at-rest. Google Cloud si basa sul presupposto fondamentale che Google Cloud i clienti possiedono i propri dati e ne devono controllare l'utilizzo.

Quando memorizzi i dati con Google Cloud, questi vengono criptati quando sono inattivi per impostazione predefinita. Quando utilizzi la piattaforma Cloud KMS, puoi ottenere un maggiore controllo su come vengono criptati i dati inattivi e su come vengono gestite le chiavi di crittografia.

Questo documento si concentra sui meccanismi interni della piattaforma Cloud KMS. Queste opzioni consentono di proteggere le chiavi e altri dati riservati archiviati in Google Cloud. Questo documento è destinato ai responsabili delle decisioni tecniche che hanno bisogno informazioni dettagliate su architettura, infrastruttura e funzionalità di Cloud KMS. Questo documento presuppone che tu abbia una conoscenza di base dei concetti di crittografia e delle architetture cloud.

Chiavi in Google Cloud

La tabella seguente descrive i diversi tipi di chiavi in Google Cloud.

Tipo di chiave	Autokey di Cloud KMS	Cloud KMS gestito dal cliente (manuale)	Google-owned and Google-managed encryption key (crittografia predefinita di Google)
Può visualizzare i metadati chiave	Sì	Sì	No
Proprietà delle chiavi1	Cliente	Cliente	Google
Può gestire le chiavi2 e controllare le chiavi3	La creazione e l'assegnazione delle chiavi sono automatizzate. Il controllo manuale del cliente è completamente supportato.	Cliente, solo controllo manuale	Google
Supporta i requisiti normativi per le chiavi gestite dal cliente	Sì	Sì	No
Condivisione della chiave	Unico per un cliente	Unico per un cliente	I dati di più clienti sono in genere protetti da chiavi di crittografia condivise (KEK).
Controllo della rotazione della chiave	Sì	Sì	No
Policy CMEK dell'organizzazione	Sì	Sì	No
Registra l'accesso amministrativo e ai dati alle chiavi di crittografia	Sì	Sì	No
Separazione logica dei dati tramite crittografia	Sì	Sì	No
Prezzi	Varia	Varia	Gratis

¹ Il proprietario della chiave indica chi detiene i diritti sulla chiave. Le chiavi di tua proprietà hanno accesso strettamente limitato o nessun accesso da parte di Google.

² La gestione delle chiavi include le seguenti attività:

• Crea chiavi.
• Scegli il livello di protezione delle chiavi.
• Assegna l'autorità per la gestione delle chiavi.
• Controlla l'accesso alle chiavi.
• Controllare l'utilizzo delle chiavi.
• Imposta e modifica il periodo di rotazione delle chiavi o attiva una rotazione delle chiavi.
• Modifica lo stato della chiave.
• Elimina le versioni della chiave.

³ Il controllo delle chiavi significa impostare controlli sul tipo di chiavi e su come vengono utilizzate, rilevare le variazioni e pianificare un'azione correttiva, se necessario. Puoi controllare le chiavi, ma delegare la gestione a una terza parte.

Principi di Cloud KMS

Con Cloud KMS, l'obiettivo di Google è fornire una soluzione scalabile e affidabile, con prestazioni elevate e una vasta gamma di opzioni che puoi controllare. Cloud KMS è supportato dai seguenti principi:

• Controllo del cliente:Cloud KMS ti consente di controllare le tue chiavi software e hardware per la crittografia e la firma. Questo pilastro include il supporto per Bring Your Own Keys (BYOK) e Hold Your Own Keys (HYOK).
• Controllo e monitoraggio dell'accesso:con Cloud KMS puoi gestire le autorizzazioni per le singole chiavi e monitorarne l'utilizzo.
• Regionalità:Cloud KMS offre la regionalizzazione predefinita. Il servizio è configurato per creare, archiviare ed elaborare le chiavi solo nella Google Cloud località che selezioni.
• Backup:per evitare il danneggiamento dei dati e verificarne la corretta decriptazione, Cloud KMS analizza periodicamente tutti i metadati e i materiali delle chiavi e ne esegue il backup.
• Sicurezza:Cloud KMS offre una protezione efficace contro l'accesso non autorizzato alle chiavi ed è completamente integrato con i controlli di Identity and Access Management (IAM) e di Cloud Audit Logs.
• Separazione logica dei dati:la crittografia Cloud KMS fornisce la separazione logica dei dati tramite la crittografia. La separazione logica dei dati significa che i proprietari dei dati non condividono le chiavi di crittografia (KEK e DEK).

Origini e opzioni di gestione per le chiavi crittografiche

La piattaforma Cloud KMS consente di gestire le chiavi di crittografia in un servizio cloud centrale per utilizzarle direttamente o con altre risorse e applicazioni cloud.

Il Google Cloud portfolio per le chiavi include:

• Crittografia predefinita:tutti i dati archiviati da Google vengono criptati a livello di archiviazione utilizzando l'algoritmo Advanced Encryption Standard (AES), AES-256. Generiamo e gestiamo le chiavi per la crittografia predefinita e i clienti non hanno accesso alle chiavi né controllano la rotazione e la gestione delle chiavi. Le chiavi di crittografia predefinite potrebbero essere condivise tra i clienti. Per maggiori informazioni, consulta Crittografia at-rest predefinita.

• Cloud KMS con chiavi protette dal software:puoi controllare le chiavi generate in Cloud KMS. Il backend software di Cloud KMS ti offre la flessibilità di criptare o firmare i dati con una chiave simmetrica o asimmetrica che controlli personalmente.

• Cloud KMS con chiavi protette dall'hardware (Cloud HSM): utilizzando Cloud KMS con il backend Cloud HSM, puoi possedere chiavi generate e archiviate in moduli di sicurezza hardware (HSM) di proprietà e gestiti da Google. Se hai bisogno di una chiave protetta dall'hardware, puoi utilizzare il backend Cloud HSM per garantire che le chiavi vengano utilizzate solo in HSM convalidati di tipo FIPS 140-2 livello 3. Puoi eseguire il provisioning delle chiavi protette dall'hardware utilizzando un metodo manuale che richiede un amministratore Cloud KMS o automaticamente utilizzando Cloud KMS Autokey. Autokey ti consente di automatizzare i processi di provisioning e assegnazione delle chiavi per le chiavi di crittografia gestite dal cliente (CMEK). Le chiavi HSM convenzionali richiedono che un amministratore KMS crei le chiavi su richiesta.

• Cloud KMS con importazione delle chiavi:per soddisfare i requisiti BYOK, puoi importare le tue chiavi di crittografia che generi personalmente. Puoi utilizzare e gestire queste chiavi al di fuori di Google Cloude utilizzare il materiale della chiave in Cloud KMS per criptare o firmare i dati che memorizzi in Google Cloud.

• Cloud KMS con gestione delle chiavi esterna (Cloud EKM): Per soddisfare i requisiti HYOK, puoi creare e controllare le chiavi archiviate in un gestore delle chiavi esterno a Google Cloud. Successivamente, configuri la piattaforma Cloud KMS per utilizzare le chiavi esterne per proteggere i dati inattivi. Puoi utilizzare queste chiavi di crittografia con una chiave Cloud EKM. Per saperne di più sulla gestione delle chiavi esterne e su Cloud EKM, consulta Architetture di riferimento per Cloud EKM.

Puoi scegliere di utilizzare le chiavi generate da Cloud KMS con altri serviziGoogle Cloud . Queste sono chiamate CMEK. La funzionalità CMEK consente di generare, utilizzare, ruotare ed eliminare le chiavi di crittografia che contribuiscono a proteggere i dati in altri servizi. Google CloudQuando utilizzi CMEK con i servizi Google Cloud , l'accesso alle chiavi e il monitoraggio vengono gestiti per te.

Crittografia e gestione delle chiavi in Google

Questa sezione definisce alcuni termini per la gestione delle chiavi nel contesto dell'infrastruttura di gestione delle chiavi multilivello di Google.

Keyring, chiavi e versioni delle chiavi

Il seguente diagramma illustra i raggruppamenti di chiavi e mostra i keyring e le chiavi con una singola versione principale e più versioni precedenti.

I concetti mostrati nel diagramma precedente sono i seguenti:

• Chiave: un oggetto denominato che rappresenta una chiave di crittografia utilizzata per uno scopo specifico. Il materiale della chiave, ovvero i bit effettivi utilizzati per le operazioni di crittografia, può cambiare nel tempo man mano che vengono create nuove versioni delle chiavi. Puoi assegnare criteri di autorizzazione IAM a livello di chiave nella gerarchia delle risorse.

  Lo scopo e altri attributi della chiave vengono connessi e gestiti utilizzando la chiave. Di conseguenza, la chiave è l'oggetto più importante per comprendere l'utilizzo di KMS.

  Cloud KMS supporta le chiavi sia simmetriche che asimmetriche. Una chiave simmetrica viene utilizzata per creare o convalidare firme MAC o per la crittografia simmetrica al fine di proteggere un corpus di dati. Ad esempio, puoi utilizzare AES-256 in modalità GCM per criptare un blocco di testo non crittografato. Una chiave asimmetrica può essere utilizzata per la crittografia asimmetrica o la firma asimmetrica. Per ulteriori informazioni, vedi Scopi e algoritmi supportati.

• Keyring: si tratta di un raggruppamento di chiavi a fini organizzativi. Un keyring appartiene a un progetto Google Cloud e si trova in una località specifica. Le chiavi ereditano i criteri di autorizzazione dal keyring. Il raggruppamento di chiavi con autorizzazioni correlate in un keyring consente di concedere, revocare o modificare le autorizzazioni per tali chiavi a livello di keyring senza dover agire singolarmente su ogni chiave. I keyring offrono convenienza e categorizzazione, ma se il loro raggruppamento non è utile per i tuoi scopi, puoi gestire le autorizzazioni direttamente nelle chiavi. I tag ti consentono di consentire o negare in modo condizionale i criteri a seconda che una risorsa abbia un tag specifico. Puoi applicare i tag a livello di portachiavi nella gerarchia delle risorse.

  Per evitare conflitti per i nomi delle risorse, non puoi eliminare un keyring o una chiave. I keyring e le chiavi non hanno costi fatturabili o limitazioni di quota, perciò il fatto che continuino a esistere non influisce sui costi o sui limiti di produzione.

• Metadati delle chiavi: includono nomi di risorse, proprietà delle risorse KMS (ad esempio criteri di autorizzazione, oltre a tipo, dimensione e stato della chiave) e qualsiasi dato derivato da chiavi e keyring.

• Versione della chiave:il materiale della chiave associato a una chiave in un determinato momento. La versione della chiave è la risorsa che contiene il materiale della chiave vera e propria. Le versioni sono numerate in sequenza a partire da 1. Quando una chiave viene ruotata, ne viene creata una nuova versione con del nuovo materiale. La stessa chiave logica può avere più versioni nel corso del tempo, il che significa che i tuoi dati vengono criptati utilizzando versioni diverse della chiave. Le chiavi simmetriche hanno una versione primaria. Per impostazione predefinita, la versione primaria viene utilizzata per la crittografia. Quando Cloud KMS esegue la decriptazione mediante chiavi simmetriche, identifica automaticamente la versione della chiave necessaria per l'operazione.

Gerarchia delle chiavi

Il seguente diagramma illustra la gerarchia delle chiavi e la crittografia envelope per Cloud KMS e il keystore interno di Google. La crittografia envelope è il processo di crittografia di una chiave utilizzando un'altra chiave, per archiviarla in modo sicuro o trasmetterla su un canale non attendibile. Tutte le chiavi in questo diagramma sono chiavi simmetriche.

All'interno della gerarchia delle chiavi, una chiave di crittografia dei dati (DEK) cripta i blocchi di dati. Una chiave di crittografia della chiave (KEK) viene utilizzata per criptare o sottoporre a wrapping la DEK. Tutte le opzioni della piattaforma Cloud KMS (software, hardware e backend esterni) consentono di controllare la chiave di crittografia della chiave. Le KEK sono archiviate in Cloud KMS. Il materiale della chiave non esce mai dal perimetro del sistema Cloud KMS.

Per le chiavi protette dal software, una chiave master del KMS specifica per la località cripta la KEK. La chiave master del KMS è archiviata in Keystore. Esiste una chiave master KMS separata in Keystore per ogni località Cloud KMS. Ciascun server Cloud KMS recupera una copia della chiave master KMS in fase di avvio come dipendenza rigida e recupera ogni giorno una nuova copia della chiave master KMS, La chiave master del KMS viene criptata di nuovo periodicamente utilizzando la chiave master del keystore in Keystore. La chiave master del keystore è protetta dalla chiave master del keystore radice.

Per le chiavi protette a livello hardware, una chiave di wrapping HSM specifica per la località cripta la KEK, che a sua volta viene criptata con la chiave master del KMS. Per maggiori informazioni, consulta Creazione di chiavi. Per le chiavi esterne, una chiave di wrapping EKM cripta la DEK sottoposta a wrapping, che a sua volta viene criptata con la chiave master del KMS.

Cloud KMS utilizza Keystore, il Key Management Service interno di Google, per eseguire il wrapping delle chiavi criptate da Cloud KMS. Cloud KMS utilizza la stessa radice di attendibilità di Keystore. Per saperne di più su Keystore, consulta la sezione Gestione delle chiavi nel white paper sulla crittografia at-rest.

Vincoli operativi

Cloud KMS opera nei seguenti limiti:

• Progetto: le risorse di Cloud KMS appartengono a un progettoGoogle Cloud, proprio come tutte le altre risorse Google Cloud. Le chiavi Cloud KMS possono risiedere in un progetto diverso dai dati che proteggono. Se mantieni le chiavi nello stesso progetto dei dati protetti dalle risorse, per supportare la best practice della separazione dei compiti tra gli amministratori delle chiavi e quelli dei dati, puoi rimuovere il ruolo Proprietario dal progetto.
• Località: all'interno di un progetto, le risorse di Cloud KMS vengono create in una località. Per saperne di più sulle località, consulta Area geografica e regioni.
• Coerenza: Cloud KMS propaga le operazioni su chiavi, keyring e versioni delle chiavi utilizzando una elevata coerenza o una coerenza finale. Per ulteriori informazioni, consulta Coerenza delle risorse Cloud KMS.

Chiavi di crittografia gestite dal cliente

Per impostazione predefinita, Google Cloud cripta tutti i dati dei clienti archiviati in stato inattivo ed è Google a gestire le chiavi utilizzate per la crittografia. Per i prodotti Google Cloudcompatibili che archiviano in modo permanente i contenuti dei clienti (ad esempio Cloud Storage), puoi invece utilizzare Cloud KMS per gestire le chiavi di crittografia gestite dal cliente (CMEK). Le chiavi CMEK sono chiavi di crittografia di tua proprietà e possono essere utilizzate con chiavi esterne, chiavi protette da software e chiavi protette da hardware.

Le chiavi CMEK ti consentono di avere un maggiore controllo sulle chiavi utilizzate per criptare i dati inattivi all'interno di servizi compatibili Google Cloud e forniscono un limite crittografico intorno ai tuoi dati. Puoi gestire le chiavi CMEK direttamente in Cloud KMS o automatizzare il provisioning e l'assegnazione utilizzando Autokey. Quando un servizio utilizza CMEK, i tuoi carichi di lavoro possono accedere alle risorse nello stesso modo in cui lo fanno quando utilizzi solo la crittografia predefinita.

Cloud KMS consente di controllare molti aspetti delle chiavi (ad esempio creazione, abilitazione, disabilitazione, rotazione ed eliminazione delle chiavi) nonché di gestire le autorizzazioni IAM appropriate. Per applicare la separazione dei compiti consigliata, Cloud KMS include diversi ruoli IAM predefiniti con privilegi e limitazioni specifici e che possono essere concessi a utenti e service account specifici.

Poiché Cloud KMS utilizza la crittografia envelope, una CMEK è una KEK che cripta le DEK. Per ulteriori informazioni, vedi Gerarchia delle chiavi.

La rotazione delle chiavi CMEK funziona in modo diverso a seconda del tipo di risorsa protetta dalla chiave. Considera i seguenti esempi:

• In Spanner, una nuova versione della chiave cripta nuovamente la DEK.
• Per altri tipi di risorse, come i bucket Cloud Storage, solo le risorse appena create vengono criptate utilizzando la nuova versione della chiave, il che significa che versioni diverse di una chiave proteggono sottoinsiemi diversi di dati.
• In alcuni scenari, la risorsa cloud deve essere ricreata con la nuova versione della chiave. Ad esempio, per impostazione predefinita, BigQuery non ruota automaticamente una chiave di crittografia della tabella quando viene ruotata la chiave Cloud KMS associata alla tabella. Le tabelle BigQuery esistenti continuano a utilizzare la versione della chiave con cui sono state create.

Per saperne di più sulla rotazione della chiave, consulta la documentazione di ogni prodotto.

Le policy dell'organizzazione CMEK offrono un maggiore controllo su come viene utilizzata CMEK all'interno dei tuoi progetti. Questi criteri consentono di controllare i servizi e i progetti che contengono le chiavi consentite per CMEK e il livello di protezione delle chiavi.

Google Cloud supporta CMEK per molti servizi, tra cui Cloud Storage, BigQuery e Compute Engine. Consulta la sezione Integrazioni CMEK per l'elenco completo delle integrazioni CMEK e dei servizi conformi alla funzionalità CMEK. Google continua a investire nell'integrazione CMEK per altri prodotti. Google Cloud

Autokey di Cloud KMS

Autokey ti consente di semplificare il processo di provisioning CMEK. Durante una procedura di provisioning CMEK manuale, un amministratore Cloud KMS deve pianificare i tipi di portachiavi, chiavi e service account prima che siano necessari e coordinarsi con gli sviluppatori per eseguire il provisioning delle chiavi. Con Autokey, l'amministratore di Cloud KMS delega la propria autorità all'agente di servizio Cloud KMS nel progetto. Quando abiliti Autokey, uno sviluppatore può richiedere una chiave da Cloud KMS e l'agente di servizio esegue il provisioning della chiave giusta per l'intento dello sviluppatore. Con Autokey, le chiavi sono disponibili on demand, sono coerenti e seguono le pratiche standard del settore.

Autokey esegue il provisioning e assegna portachiavi, chiavi e service account su richiesta man mano che gli sviluppatori creano le risorse cloud, rispettando la separazione dei compiti. Il provisioning e l'assegnazione delle chiavi seguono le pratiche e i consigli standard di settore per la sicurezza dei dati, tra cui:

• Livello di protezione HSM:le chiavi create utilizzando Autokey sono sempre chiavi HSM e vengono quindi archiviate nel backend di Cloud HSM. Sono chiavi di crittografia AES-256 GCM.
• Separazione dei compiti:per mantenere la separazione dei compiti, le identità che possono utilizzare la chiave per criptare e decriptare sono diverse da quelle che gestiscono la chiave (inclusi la rotazione, la distruzione o la modifica dello stato).
• Rotazione delle chiavi: le chiavi vengono ruotate ogni anno.
• Collocazione della chiave con le risorse: la chiave si trova nella stessa posizione della risorsa che protegge.
• Specificità della chiave: la specificità della chiave è appropriata per il tipo di risorsa che protegge, in base al tipo di risorsa. La specificità significa che non devi esaminare manualmente i tipi di risorse di ogni servizio e decidere quanti tipi di risorse deve proteggere una singola chiave.

Le chiavi richieste utilizzando Autokey funzionano in modo identico alle altre chiavi Cloud HSM con le stesse impostazioni. Autokey semplifica l'utilizzo di Terraform perché elimina la necessità di eseguire Infrastructure as Code con privilegi elevati di creazione delle chiavi. Autokey è disponibile in tutte le Google Cloud posizioni in cui è disponibile Cloud HSM.

Autokey è disponibile solo per risorse Google Cloud specifiche. Per ulteriori informazioni, consulta la panoramica di Autokey.

Architettura e componenti della piattaforma Cloud KMS

La piattaforma Cloud KMS supporta vari algoritmi di crittografia e offre metodi per criptare e firmare digitalmente i dati mediante chiavi esterne, chiavi protette dall'hardware e chiavi protette dal software. La piattaforma Cloud KMS è integrata con Identity and Access Management (IAM) e gli audit log di Cloud in modo da gestire le autorizzazioni per le singole chiavi e verificarne l'utilizzo.

Il diagramma precedente mostra i seguenti componenti principali della piattaforma Cloud KMS:

• Gli amministratori accedono ai servizi di gestione delle chiavi utilizzando la console Google Cloud o Google Cloud CLI.

• Le applicazioni accedono ai servizi di gestione delle chiavi implementando l'API REST, gRPC o le librerie client. Le applicazioni possono utilizzare i servizi Google abilitati per l'utilizzo di CMEK. A loro volta, le chiavi CMEK utilizzano l'API Cloud Key Management Service. Se la tua applicazione utilizza PKCS #11, puoi integrarla con Cloud KMS utilizzando la libreria per PKCS #11.

• L'API Cloud KMS consente di utilizzare chiavi software, hardware o esterne. Puoi generare e gestire chiavi protette dal software e dall'hardware utilizzando l'endpoint del servizio Cloud KMS. Sia le chiavi protette da software che quelle protette da hardware utilizzano le funzionalità di protezione offerte dal backup ridondante di Google.

• Se utilizzi chiavi protette dall'hardware, gli HSM certificati FIPS 140-2 di livello 3 in Google Cloud memorizzano le chiavi. Per ulteriori informazioni sulla nostra certificazione, consulta Certificato n. 4399.

• Cloud KMS utilizza il datastore interno di Google per archiviare il materiale delle chiavi dei clienti criptato. Questo datastore è ad alta disponibilità e supporta molti sistemi critici di Google. Consulta Protezione Datastore.

• A intervalli regolari, il sistema di backup indipendente esegue il backup dell'intero datastore sia nell'archivio online sia in quello di archiviazione. Questo backup consente a Cloud KMS di raggiungere i suoi obiettivi di durabilità. Consulta Protezione del datastore.

Convalida FIPS 140-2

Le operazioni di crittografia di Cloud KMS vengono eseguite dai nostri moduli convalidati secondo lo standard FIPS 140-2. Le chiavi con livello di protezione SOFTWARE e le operazioni di crittografia che eseguono sono conformi allo standard FIPS 140-2 livello 1. Queste operazioni di crittografia utilizzano BoringCrypto, una libreria di crittografia open source gestita da Google. Le chiavi con livello di protezione HSM e le operazioni di crittografia che eseguono sono conformi allo standard FIPS 140-2 livello 3.

Sicurezza dei materiali delle chiavi

In Cloud KMS, il materiale delle chiavi è sempre criptato, sia in stato inattivo che in transito. Il materiale delle chiavi viene decriptato solo nei seguenti casi:

• Quando il cliente utilizza la chiave.
• Quando la chiave interna di Google utilizzata per proteggere il materiale della chiave del cliente viene ruotata o quando ne viene verificata l'integrità.

Le richieste dei clienti a Cloud KMS vengono criptate in transito mediante TLS tra il cliente e Google Front End (GFE).

L'autenticazione avviene tra tutti i job Cloud KMS, sia all'interno che tra i data center Google.

Le norme di Google garantiscono che i job utilizzino solo il codice sorgente creato, testato e rivisto in modo verificabile. L'autorizzazione binaria per Borg (BAB) applica questo criterio a livello operativo.

I job dell'API Cloud KMS possono accedere ai metadati delle chiavi, ad esempio il criterio di autorizzazione o il periodo di rotazione. Anche un dipendente Google con una motivazione lavorativa valida e documentata (ad esempio un bug o un problema del cliente) può accedere ai metadati delle chiavi. Questi eventi di accesso vengono registrati internamente e i log relativi ai dati coperti da Access Transparency sono disponibili anche per i clienti qualificati.

Il materiale delle chiavi decriptato non può essere esportato o visualizzato tramite l'interfaccia dell'API o un'altra interfaccia utente. Nessun dipendente Google ha accesso al materiale non criptato della chiave del cliente. Inoltre, il materiale delle chiavi viene criptato con una chiave master in Keystore, a cui nessuno può accedere direttamente. Su un HSM, i job dell'API Cloud KMS non accedono mai al materiale delle chiavi in uno stato decriptato.

Protezione del datastore

Il datastore per Cloud KMS è ad alta disponibilità, durevole e protetto.

Disponibilità. Cloud KMS utilizza il datastore interno ad alta disponibilità di Google, che supporta una serie di sistemi critici di Google.

Durabilità. Cloud KMS utilizza la crittografia autenticata per archiviare il materiale delle chiavi dei clienti nel datastore. Inoltre, tutti i metadati vengono autenticati mediante un codice HMAC (Hash-based Message Authentication Code) per garantire che non siano stati modificati o danneggiati mentre erano inattivi. Ogni ora, un job batch scansiona tutti i materiali e i metadati delle chiavi per verificare che i codici HMAC siano validi e che il materiale delle chiavi possa essere decriptato. Se i dati sono danneggiati, i tecnici di Cloud KMS vengono immediatamente avvisati in modo che possano intervenire.

Cloud KMS utilizza diversi tipi di backup per il datastore:

• Per impostazione predefinita, il datastore memorizza per quattro giorni una cronologia delle modifiche di ogni riga. In caso di emergenza, questa durata può essere estesa in modo da avere più tempo per risolvere i problemi.
• Il datastore memorizza ogni ora uno snapshot che può essere convalidato e utilizzato per il ripristino, se necessario. Questi snapshot vengono conservati per quattro giorni.
• Un backup completo viene copiato ogni giorno sia su disco che nell&#archiviazione dei dati ad accesso sporadico.

Il team di Cloud KMS si avvale di procedure documentate per ripristinare i backup e mitigare la perdita di dati in caso di emergenza lato servizio.

Backup. I backup del datastore Cloud KMS si trovano nella regione associata. Google Cloud Questi backup vengono tutti criptati quando sono inattivi. L'accesso ai dati nei backup è controllato in base alle motivazioni dell'accesso, ad esempio un numero di richiesta inviato all'assistenza Google, e l'accesso da parte delle persone viene registrato nei log di Access Transparency.

Protezione. A livello di applicazione Cloud KMS, il materiale delle chiavi viene criptato prima di essere archiviato. I tecnici con accesso al datastore non possono accedere al materiale delle chiavi dei clienti in testo non crittografato. Inoltre, il datastore cripta tutti i dati che gestisce prima di scriverli nell'archiviazione permanente. Pertanto, l'accesso ai livelli di archiviazione sottostanti, inclusi dischi oarchiviazione dei dati ad accesso sporadicoe, non consente l'accesso nemmeno ai dati Cloud KMS criptati senza l'accesso alle chiavi di crittografia del datastore, che sono archiviate in Keystore.

Criterio di rotazione. La rotazione delle chiavi fa parte delle best practice accettate generalmente per la gestione del materiale delle chiavi. Esiste un criterio di rotazione per le chiavi utilizzate per proteggere i datastore di Cloud KMS. Un criterio di rotazione viene applicato anche alle chiavi master del keystore che eseguono il wrapping delle chiavi master di Cloud KMS. La chiave master del Keystore ha una durata massima programmata per il testo crittografato di 90 giorni, mentre quella massima per una chiave memorizzata nella cache del cliente è di un giorno. Cloud KMS aggiorna le chiavi master del KMS nelle attività KMS ogni 24 ore e cripta di nuovo tutte le chiavi del cliente su base mensile.

Residenza dei dati. I dati sottostanti di ogni datastore Cloud KMS rimangono esclusivamente all'interno della regione Google Cloud a cui sono associati i dati. Ciò è valido anche per le località con più aree geografiche, ad esempio us.

Disponibilità delle chiavi dopo la creazione

Cloud KMS consente di utilizzare una chiave subito dopo che il datastore Cloud KMS esegue il commit della transazione che crea la chiave e dopo che il livello di archiviazione ne conferma la creazione.

Backend delle chiavi e livelli di protezione

Quando crei una chiave con Cloud KMS, puoi scegliere un livello di protezione per determinare quale backend di chiavi crea la chiave ed esegue tutte le future operazioni di crittografia sulla chiave in questione. I backend sono esposti nell'API Cloud KMS come i seguenti livelli di protezione:

• SOFTWARE: si applica alle chiavi il cui wrapping potrebbe venire annullato da un modulo di sicurezza software per eseguire operazioni di crittografia.
• HSM: si applica alle chiavi il cui wrapping può essere annullato solo da HSM che eseguono tutte le operazioni di crittografia con le chiavi.
• EXTERNAL o EXTERNAL-VPC: si applica al gestore di chiavi esterno (EKM). EXTERNAL-VPC ti consente di connettere EKM a Google Cloud tramite una rete VPC.

Backend software di Cloud KMS: livello di protezione SOFTWARE

Il livello di protezione SOFTWARE si applica alle chiavi le cui operazioni di crittografia vengono eseguite nel software. Questa sezione descrive i dettagli relativi all'implementazione di questo livello.

Implementazioni algoritmiche

Per le chiavi software, Cloud KMS utilizza il modulo BoringCrypto all'interno dell'implementazione BoringSSL di Google per tutte le operazioni di crittografia correlate. Il modulo BoringCrypto è convalidato FIPS 140-2. Il dati binari di Cloud KMS sono creati sulla base delle primitive crittografiche di questo modulo, convalidate secondo lo standard FIPS 140-2 livello 1. Gli algoritmi più recenti coperti da questo modulo sono elencati in Scopi e algoritmi delle chiavi e includono le operazioni di crittografia, decriptazione e firma con chiavi di crittografia sia simmetriche AES256-GCM sia asimmetriche RSA 2048, RSA 3072, RSA 4096, EC P256 ed EC P384.

Generazione di numeri casuali ed entropia

Cloud KMS utilizza BoringSSL per generare le chiavi di crittografia. FIPS 140-2 richiede l'utilizzo di generatori interni di numeri pseudocasuali (PRNG), chiamati anche generatori interni di numeri casuali deterministici (DRBG). In BoringCrypto, Cloud KMS utilizza esclusivamente CTR-DRBG con AES-256. Ciò fornisce l'output per RAND_bytes, l'interfaccia principale tramite la quale il resto del sistema ottiene dati casuali. Questo PRNG ha origine dall'RNG del kernel Linux, che a sua volta deriva da più origini entropiche indipendenti. Questa derivazione include eventi entropici provenienti dall'ambiente del data center, tra cui misurazioni granulari del numero di operazioni di ricerca su disco e dei tempi di arrivo tra pacchetti, così come l'istruzione RDRAND di Intel, se disponibile. Per ulteriori informazioni sul funzionamento del generatore di numeri casuali per BoringSSL (modalità conforme allo standard FIPS), consulta le informazioni sulla progettazione RNG.

Backend Cloud HSM: livello di protezione HARDWARE

Cloud HSM fornisce chiavi protette dall'hardware a Cloud KMS. Consente di utilizzare chiavi di crittografia protette da HSM completamente gestiti e certificati FIPS 140-2 di livello 3 nei data center Google. Cloud HSM è ad alta disponibilità e offre scalabilità elastica, proprio come Cloud KMS. Puoi accedere al backend di Cloud HSM utilizzando la stessa API e le stesse librerie client di Cloud KMS. Per maggiori informazioni sul backend di Cloud HSM, consulta Architettura di Cloud HSM.

Cloud EKM: livello di protezione ESTERNO

Cloud EKM consente di criptare i dati utilizzando chiavi di crittografia off-cloud che rimangono sotto il tuo controllo.

Le chiavi con i livelli di protezione EXTERNAL e EXTERNAL_VPC vengono archiviate e gestite in un sistema di gestione delle chiavi esterno. Per maggiori informazioni, consulta Architetture di riferimento per Cloud EKM.

Procedura di creazione della chiave

Il seguente diagramma illustra la procedura di creazione delle chiavi per i diversi backend delle chiavi e livelli di protezione.

Il processo di creazione delle chiavi include quanto segue:

1. Utilizzando l'API Cloud KMS, un utente chiede a Cloud KMS di creare una chiave. Questa richiesta include il livello di protezione (se la chiave è protetta da software, protetta da hardware o esterna).
2. Cloud KMS verifica l'identità dell'utente e se dispone dell'autorizzazione per creare la chiave.
3. La chiave viene generata nel seguente modo:
   • Per le chiavi protette dal software, Cloud KMS genera la chiave del cliente.
   • Per le chiavi protette dall'hardware, Cloud KMS invia una richiesta a Cloud HSM. Cloud HSM invia la richiesta all'HSM per generare una nuova chiave. L'HSM genera una chiave cliente e la cripta (wrapping) con la chiave di wrapping regionale dell'HSM. Cloud HSM invia la chiave sottoposta a wrapping a Cloud KMS.
   • Per le chiavi esterne, Cloud KMS invia una richiesta a Cloud EKM. Cloud EKM invia la richiesta al gestore di chiavi esterno per generare una nuova chiave. EKM genera una nuova chiave e la cripta con la chiave di wrapping EKM. Cloud EKM invia la chiave sottoposta a wrapping a Cloud KMS.
4. Cloud KMS cripta la chiave del cliente sottoposta a wrapping con la chiave master del KMS e la invia al datastore KMS per l'archiviazione.
5. Cloud KMS invia all'utente una risposta di esito positivo con l'URI completo della versione della chiave.

Importazione di una chiave

Potresti voler importare le chiavi create personalmente on-premise o in un EKM nel tuo ambiente cloud. Ad esempio, potrebbe esistere un requisito normativo che stabilisce che le chiavi utilizzate per criptare i dati cloud vengano generate in un modo o in un ambiente specifico. L'importazione delle chiavi consente di importarle e di rispettare gli obblighi normativi. Per estendere le funzionalità di firma al cloud, puoi anche importare chiavi asimmetriche.

Nell'ambito dell'importazione delle chiavi, Cloud KMS genera una chiave di wrapping pubblica, composta da una coppia di chiave pubblica/privata, utilizzando uno dei metodi di importazione supportati. Grazie a questa chiave di wrapping, il materiale delle chiavi viene crittografato e protetto in transito.

Utilizzi la chiave di wrapping pubblica per criptare la chiave da importare sul client. La chiave privata che corrisponde alla chiave pubblica viene archiviata in Google Cloud e viene utilizzata per annullare il wrapping della chiave pubblica dopo che raggiunge il progettoGoogle Cloud . Il metodo di importazione che scegli determina l'algoritmo utilizzato per creare la chiave di wrapping. Dopo che il materiale della chiave viene sottoposto a wrapping, puoi importarlo in una nuova chiave o versione della chiave in Cloud KMS.

Puoi utilizzare le chiavi importate con il livello di protezione HSM o SOFTWARE. Per Cloud HSM, la parte della chiave privata della chiave di wrapping è disponibile solo in Cloud HSM. La limitazione della parte della chiave privata a Cloud HSM impedisce a Google di annullare il wrapping del materiale della chiave al di fuori di Cloud HSM.

Ciclo di vita di una richiesta Cloud KMS

Questa sezione descrive il ciclo di vita di una richiesta Cloud KMS, compresa un'analisi dell'eliminazione del materiale delle chiavi. Il seguente diagramma mostra un client che richiede l'accesso alle istanze del servizio Cloud KMS in us-east1 e us-west1 e come le richieste vengono instradate utilizzando Google Front End (GFE).

I passaggi di questo ciclo di vita sono i seguenti:

1. Il personale della tua organizzazione o un job in esecuzione per conto della tua organizzazione scrive una richiesta al servizio Cloud KMS, https://cloudkms.googleapis.com. Il DNS risolve questo indirizzo in un indirizzo IP anycast di GFE.
2. GFE fornisce l'hosting degli IP pubblici per il nome DNS pubblico, la protezione denial of service (DoS) e la terminazione TLS. Quando invii la richiesta, questa di solito viene indirizzata a un servizio GFE vicino a te, a prescindere dalla località a cui è destinata la richiesta. I servizi GFE gestiscono la negoziazione TLS e, utilizzando i parametri e l'URL della richiesta, determinano quale bilanciatore del carico software globale (GSLB) inoltra la richiesta.
3. Esiste un bilanciatore del carico software globale di destinazione separato per ogni area geografica Cloud KMS. Se la richiesta arriva a un GFE in us-east1 ed è destinata a us-west1, viene instradata tra i data center in us-east1 e us-west1. Tutte le comunicazioni tra i data center sono criptate in transito mediante ALTS, che esegue l'autenticazione reciproca di GFE e dei job Cloud KMS.
4. Quando la richiesta raggiunge il job Cloud KMS, viene prima elaborata da un framework che gestisce gran parte del lavoro comune a tutti i serviziGoogle Cloud . Questo framework autentica l'account ed esegue una serie di controlli per verificare quanto segue:
   • L'account dispone di una credenziale valida e può essere autenticato.
   • Nel progetto è abilitata l'API Cloud KMS ed esiste un account di fatturazione valido.
   • La quota è sufficiente per eseguire la richiesta.
   • L'account si trova nella lista consentita di utenti che possono utilizzare l'area geografica Google Cloud pertinente.
   • La richiesta non viene rifiutata dai Controlli di servizio VPC.
5. Dopo aver superato questi controlli, il framework inoltra la richiesta e la credenziale a Cloud KMS. Cloud KMS analizza la richiesta per determinare le risorse alle quali viene eseguito l'accesso, quindi utilizza IAM per verificare se il chiamante è autorizzato a effettuare la richiesta. IAM indica anche se la richiesta deve essere scritta negli audit log. Se Key Access Justifications è abilitato, viene inviata una notifica di giustificazione che devi approvare.
6. Dopo che la richiesta è stata autenticata e autorizzata, Cloud KMS chiama i backend del datastore dell'area geografica per recuperare la risorsa richiesta. Una volta recuperata la risorsa, il materiale della chiave viene decriptato per essere utilizzato.
7. Con questo materiale della chiave, Cloud KMS esegue l'operazione di crittografia, inoltrando la versione sottoposta a wrapping della chiave al backend software di Cloud KMS, al backend di Cloud HSM o al backend di Cloud EKM, a seconda del livello di protezione della chiave.
8. Una volta completata l'operazione di crittografia, la risposta viene inviata di nuovo sullo stesso tipo di canale GFE-KMS della richiesta.
9. Quando la risposta viene inviata, Cloud KMS attiva anche i seguenti eventi in modo asincrono:
   • Gli audit log e i log della richiesta vengono compilati e inseriti in una coda di scrittura.
   • I rapporti vengono inviati per la fatturazione e la gestione delle quote.
   • Se la richiesta ha aggiornato i metadati di una risorsa, la modifica viene inviata a Cloud Asset Inventory tramite aggiornamenti di job batch.

Integrità dei dati end-to-end

Cloud KMS consente di calcolare i checksum per chiavi e materiali delle chiavi per assicurarsi che non siano danneggiati. Questi checksum ti aiutano a proteggerti dalla perdita di dati che potrebbe essere causata da danneggiamento dell'hardware o del software. Le librerie di assistenza ti consentono di verificare l'integrità delle chiavi. Puoi utilizzare le librerie helper per verificare l'integrità delle chiavi fornendo checksum a Cloud KMS, che vengono verificati dal server. Inoltre, queste librerie ti consentono di ricevere checksum per verificare i dati di risposta sul client.

L'integrità dei dati end-to-end contribuisce a proteggere il tuo ambiente da minacce come le seguenti:

• Corruzione durante il transito, ad esempio nello stack tra l'invio dei dati e la loro protezione tramite TLS.
• Problemi in eventuali proxy intermedi tra l'endpoint e KMS (ad esempio per le richieste in entrata).
• Operazioni di crittografia errate, danneggiamento della memoria della macchina o danneggiamento dell'HSM nell'architettura di Cloud KMS.
• Corruzione durante la comunicazione con un EKM esterno.

Per ulteriori informazioni, consulta la sezione Verifica dell'integrità dei dati end-to-end.

Eliminazione del materiale delle chiavi

Il materiale delle chiavi fa parte dei dati del cliente, pertanto l'approccio descritto in Eliminazione dei dati su Google Cloud si applica anche a Cloud KMS. Il materiale delle chiavi viene eliminato su richiesta al termine del periodo Pianificato per l'eliminazione e quando scadono i backup. Il materiale della chiave ancora presente nei backup (dopo la fine del periodo di eliminazione pianificata) può essere utilizzato solo per il ripristino di emergenza regionale e non per il ripristino di singole chiavi. Questo processo non è garantito per le copie di chiavi importate esistenti al di fuori del controllo di Cloud KMS.

Per impostazione predefinita, le chiavi in Cloud KMS trascorrono 30 giorni nello stato Pianificata per l'eliminazione (eliminazione temporanea) prima che il materiale della chiave venga eliminato logicamente dal sistema. Puoi modificare questa durata. Per ulteriori informazioni, vedi Durata variabile dello stato Pianificato per l'eliminazione.

Sebbene il materiale delle chiavi venga eliminato, non è possibile eliminare le chiavi e i keyring. Non possono essere eliminate neppure le versioni delle chiavi, ma è possibile eliminarne il materiale in modo che le risorse non vengano più utilizzate. I keyring e le chiavi non hanno costi fatturabili o limitazioni di quota, perciò il fatto che continuino a esistere non influisce sui costi o sui limiti di produzione.

Una volta pianificata l'eliminazione di una versione della chiave, questa non è disponibile per le operazioni di crittografia. Durante il periodo di eliminazione in attesa, puoi ripristinare la versione della chiave in modo che non venga eliminata.

Se elimini una chiave importata per errore, puoi importarla di nuovo. Per maggiori informazioni, consulta la sezione Reimportare una chiave distrutta.

Per evitare di eliminare accidentalmente una chiave, tieni a mente le seguenti best practice:

• Imposta il vincolo Durata pianificata minima dell'eliminazione per chiave su una durata più lunga. Questo vincolo definisce il periodo di tempo minimo per il periodo pianificato per l'eliminazione per le nuove chiavi.
• Applica il vincolo Limita l'eliminazione delle chiavi alle chiavi disattivate in modo che solo le chiavi disattivate possano essere eliminate. Per maggiori informazioni, vedi Richiedere la disattivazione delle chiavi prima della distruzione.
• Crea un ruolo KMS personalizzato che non includa l'autorizzazione cloudkms.cryptoKeyVersions.destroy.
• Modifica il campo destroy_scheduled_duration impostando un periodo di tempo più lungo.

• Monitora e aggiungi avvisi per gli eventi di eliminazione delle chiavi. Ad esempio, crea il seguente filtro Cloud Logging:

    resource.type="cloudkms_cryptokeyversion"
    protoPayload.methodName="DestroyCryptoKeyVersion"
  

• Crea processi che disattivino la chiave per un paio di giorni prima che venga eliminata.

Dipendenze dell'infrastruttura Google

Gli elementi della piattaforma Cloud KMS vengono eseguiti come job Borg di produzione. Borg è il sistema di gestione dei cluster su larga scala di Google per i job di servizio dell'API e i job batch.

Per informazioni sulla sicurezza della nostra infrastruttura fisica e di produzione, consulta la panoramica sulla progettazione della sicurezza dell'infrastruttura Google.

Job di servizio dell'API Cloud KMS

I job di servizio dell'API Cloud KMS sono job Borg di produzione che si occupano delle richieste dei clienti per gestire e utilizzare le loro chiavi. I job di servizio dell'API Cloud KMS elaborano anche le azioni differite dalle richieste dei clienti, come la rotazione delle chiavi in base a una pianificazione, la creazione di chiavi asimmetriche e l'importazione di chiavi. Questi job di servizio vengono eseguiti in ogni regioneGoogle Cloud in cui è disponibile Cloud KMS. Ogni job è associato a una singola regione ed è configurato in modo da accedere ai dati solo da sistemi che si trovano nella regioneGoogle Cloud associata.

Job batch di Cloud KMS

La piattaforma Cloud KMS offre anche una serie di job batch che vengono eseguiti come job Borg di produzione in varie pianificazioni. I job batch sono specifici per regione e aggregano solo i dati provenienti dalla regione Google Cloud associata e vengono eseguiti al suo interno. Le attività eseguite da questi job includono quanto segue.

• Conteggio delle chiavi attive per la fatturazione dei clienti.
• Aggrega le risorse dall'API pubblica per il buffer di protocollo per Cloud KMS e inoltra i metadati a Cloud Asset Inventory. Le risorse in questo contesto sono quelle gestite da Cloud KMS, ad esempio chiavi e keyring.
• Aggrega tutte le risorse e genera report con informazioni per le analisi aziendali.
• Genera snapshot dei dati per l'alta disponibilità.
• Convalida dell'integrità di tutti i dati archiviati nel datastore sottostante.
• Nuova crittografia del materiale della chiave del cliente quando è in corso la rotazione della chiave master del KMS.

Servizio di snapshot delle chiavi Cloud KMS

Per mantenere l'alta disponibilità, la piattaforma Cloud KMS gestisce un datastore ridondante in ogni istanza del servizio condiviso che ospita le attività server dell'API Cloud KMS. Ogni servizio condiviso esegue il deployment della propria istanza del servizio di snapshot. Questa ridondanza rende i servizi estremamente indipendenti, in modo che un eventuale errore in una zona abbia un effetto limitato su altre zone. Quando il job dell'API Cloud KMS deve eseguire un'operazione di crittografia, esegue in parallelo una query sul datastore principale e sui job del servizio di snapshot locale. Se il datastore principale è lento o non disponibile, la risposta potrebbe essere fornita da uno snapshot, se lo snapshot non è più vecchio di due ore. Gli snapshot vengono creati come output di un job batch eseguito continuamente per ogni area geografica. Gli snapshot si trovano nell'area geografica Cloud associata al materiale della chiave.

Comunicazioni client-server

Google utilizza Application Layer Transport Security (ALTS) per contribuire a proteggere le comunicazioni client-server che utilizzano il meccanismo di chiamata di procedura remota (RPC, Remote Procedure Call) di Google.

Per ulteriori informazioni, vedi Autenticazione, integrità e crittografia da un servizio all'altro.

Ambiente operativo della piattaforma Cloud KMS

L'ambiente operativo per la piattaforma Cloud KMS include criteri di archiviazione e sicurezza dei dati, limitazioni degli accessi e strategie di riduzione dei rischi che permettono di ottimizzare l'affidabilità, la durabilità e la disponibilità, proteggendo al contempo il materiale delle chiavi. Questa sezione descrive la struttura operativa del servizio, le responsabilità dei membri del team operativo, i meccanismi di autenticazione e i protocolli di controllo e logging. Questa sezione riguarda le funzionalità delle chiavi protette sia da software che da hardware.

Tecnici software, SRE e operatori di sistema

I tecnici software sono responsabili della collaborazione con altre parti interessate, ad esempio gestori di prodotto e SRE (Site Reliability Engineer), per progettare il sistema e scrivere gran parte del codice e dei test per il servizio Cloud KMS. Il codice include il job principale che gestisce le richieste dei clienti, nonché job secondari per attività come la replica e la fatturazione dei dati. Anche gli SRE possono scrivere codice. Tuttavia, i loro compiti sono diversi da quelli dei tecnici software. Gli SRE sono responsabili principalmente della manutenzione dell'ambiente di produzione per i job Cloud KMS. Gli SRE misurano e garantiscono l'affidabilità tramite attività di progettazione e operative.

Gli operatori di sistema sono responsabili del processo di build e rilascio, monitoraggio, gestione degli avvisi e pianificazione delle capacità per Cloud KMS. Sono i primi a rispondere ai problemi dei clienti e in caso di interruzioni di Cloud KMS. Ad esempio, gli operatori di sistema sfruttano vari strumenti e meccanismi di automazione per ridurre al minimo l'intervento manuale sui sistemi, in modo da concentrarsi su attività che generano valore a lungo termine.

I compiti degli operatori di sistema sono definiti nelle procedure operative standard. Gli operatori di sistema non accedono al materiale delle chiavi dei clienti durante lo svolgimento delle loro mansioni.

Aree geografiche delle risorse Cloud KMS

Per rispettare i requisiti di residenza delle chiavi, puoi creare risorse Cloud KMS in uno dei seguenti quattro tipi di Google Cloud località:

• Una località a singola regione è composta da zone in un'area geografica specifica, ad esempio l'Iowa.
• Una località a due regioni è composta da zone in due aree geografiche specifiche, ad esempio Iowa e Carolina del Sud.
• Una località multiregionale è composta da zone distribuite in un territorio più ampio, ad esempio gli Stati Uniti.
• La località globale è composta da zone distribuite in tutto il mondo. Se crei risorse Cloud KMS nella località globale, queste sono disponibili nelle zone di tutto il mondo.

Le località rappresentano le aree geografiche in cui vengono gestite le richieste a Cloud KMS per una determinata risorsa e dove vengono archiviate le chiavi di crittografia corrispondenti.

Per ulteriori informazioni sulle località Cloud KMS disponibili, consulta la sezione Località di Cloud KMS.

Aree geografiche e data center Cloud

Una Google Cloud regione contiene un data center specifico o un insieme specifico di data center, determinato dalla rispettiva designazione come località con una sola regione, due regioni o più regioni oppure come località globale. Per saperne di più sulle regioni Google Cloud , consulta PosizioniGoogle Cloud .

Ogni data center contiene rack di macchine per computing, networking o archiviazione dei dati. Queste macchine utilizzano l'infrastruttura Borg di Google.

I requisiti di sicurezza fisica dei data center Google sono molto rigorosi. All'ingresso di qualsiasi spazio fisico che potrebbe contenere dati degli utenti sono previsti lettori di badge e scanner dell'iride per autenticare chi entra. Le porte non vengono lasciate aperte per più persone; ognuna deve autenticarsi singolarmente. Non è consentito portare borse all'interno o all'esterno di queste aree, a meno che non siano trasparenti ed esplicitamente autorizzate dopo l'ispezione da parte del personale di sicurezza. È necessaria un'autorizzazione speciale per portare all'interno o all'esterno di queste aree qualsiasi dispositivo elettronico che possa trasmettere o registrare dati.

Residenza delle chiavi

Alcuni settori richiedono che le chiavi crittografiche si trovino in una località specifica. Cloud KMS ha termini di localizzazione dei dati con garanzie sulla residenza dei dati. Come spiegato nella sezione Aree geografiche delle risorse Cloud KMS, Cloud KMS offre quattro tipi di località con aree geografiche al fine di rispettare questo requisito.

Per le località con una sola area geografica, due aree geografiche o più aree geografiche, Cloud KMS crea, archivia ed elabora le chiavi protette da software e hardware, nonché il rispettivo materiale, solo nella località pertinente. I sistemi di archiviazione ed elaborazione dei dati utilizzati da Cloud KMS sono configurati in modo da utilizzare solo le risorse all'interno della regioneGoogle Cloud associata al materiale delle chiavi. Il materiale delle chiavi creato in località con due o più regioni non lascia i confini delle località selezionate.

Per la regione globale, non sono specificate garanzie di regionalità.

Cloud KMS non garantisce la residenza per metadati delle chiavi, log di utilizzo o per il materiale delle chiavi in transito. I metadati delle chiavi includono i nomi delle risorse e le proprietà delle risorse Cloud KMS come tipo, dimensioni e stato delle chiavi, nonché i criteri IAM e qualsiasi dato derivato dai metadati.

Se utilizzi le chiavi CMEK, vengono applicate le seguenti limitazioni geografiche di Cloud KMS a prescindere dalle località personalizzate, a due regioni o multiregionali scelte in altri prodotti Google Cloud che supportano le chiavi CMEK:

• Per un'area geografica specifica: poiché l'area geografica di una chiave KMS gestita dal cliente deve sempre essere correlata all'area geografica della risorsa che protegge in un determinato servizio Google Cloud , le limitazioni relative alla localizzazione per le chiavi e le risorse di una singola regione sono garantite come compatibili e vengono applicate.
• Per località con due o più regioni: gli utenti possono selezionare più regioni definite da Google per le proprie chiavi e Google Cloud risorse al fine di garantire la conformità in termini di localizzazione. Per garantire questa localizzazione geografica, assicurati che le regioni in altri prodotti siano in linea con la località regionale di Cloud KMS che hai scelto.

La seguente tabella riassume la localizzazione del materiale delle chiavi per Cloud KMS.

Tipo di regione	Inattivi, in uso
Regione singola	Residente
Due o più regioni	Residente nelle regioni che fanno parte della località con due o più regioni

Monitoraggio delle aree geografiche

I servizi interni di monitoraggio dei dati di Google controllano attivamente la localizzazione delle chiavi. Cloud KMS invia avvisi ai membri del team SRE se rileva errori di configurazione accidentali o se il materiale delle chiavi esce dai confini dell'area geografica configurata oppure se viene archiviato o utilizzato nell'area geografica errata.

Alta disponibilità

Cloud KMS può contribuire a semplificare i requisiti di disponibilità in base alle regioni selezionate. Più è granulare la posizione, più ridondanza devi creare. Per le applicazioni con livelli di disponibilità più elevati, utilizza posizioni multiregionali anziché tentare di creare un sistema di replica delle chiavi. Devi bilanciare le funzionalità di ridondanza integrate con le tue esigenze di regionalizzazione dei dati.

Autenticazione e autorizzazione

Cloud KMS accetta vari meccanismi di autenticazione, ad esempio OAuth2, JWT e ALTS. A prescindere dal meccanismo, Cloud KMS risolve le credenziali fornite per identificare l'entità autenticata e che sta autorizzando la richiesta. Inoltre, effettua una chiamata a IAM per verificare se l'entità è autorizzata a effettuare la richiesta e se viene compilato un audit log.

Cloud KMS utilizza una versione interna dell'API Service Control pubblica per molti aspetti della gestione dei servizi. Prima di gestire una richiesta, un job Cloud KMS ne invia una di controllo all'API Service Control, che applica molti controlli comuni a tutti i servizi Google Cloud , ad esempio:

• Controllo per verificare se hai attivato l'API Cloud KMS e disponi di un account di fatturazione attivo.
• Controllo per verificare che non hai superato la quota e generazione di report sull'utilizzo della quota.
• Applicazione dei Controlli di servizio VPC.
• Controllo per verificare se sei compreso nella lista consentita per le regioni cloud privato pertinenti.

Gestione delle quote

Cloud KMS ha limiti di utilizzo, chiamati quote, per le richieste effettuate al servizio. Cloud KMS contiene le seguenti quote:

• Quote per le richieste crittografiche per operazioni come crittografia, decrittografia o firma.
• Quote per le richieste di lettura per operazioni come il recupero di metadati chiave o di un criterio IAM.
• Quote per le richieste di scrittura per operazioni come la creazione di una chiave o l'impostazione di un criterio IAM.

Queste quote vengono addebitate al progetto associato al chiamante. Queste quote sono anche globali, il che significa che vengono applicate all'utilizzo di KMS del chiamante in tutte le regioni e in tutte le regioni multiple. Queste quote vengono valutate per tutti i livelli di protezione.

Cloud HSM e Cloud EKM hanno quote aggiuntive per le operazioni di crittografia. Queste quote devono essere soddisfatte oltre a quella per le richieste crittografiche. Le quote Cloud HSM e Cloud EKM vengono addebitate al progetto in cui si trova la chiave e vengono applicate per ogni località.

Considera i seguenti esempi:

• La chiamata di decrittografia con una chiave software in asia-northeast1 richiede un'unità di quota per le richieste crittografiche (globali).
• La creazione di una chiave HSM in us-central1 richiede un'unità di quota di richieste di scrittura e nessuna quota HSM.
• La chiamata di crittografia con una chiave EKM in europe richiede un'unità di quota per le richieste crittografiche (globali) e un'unità di quota per le richieste KMS esterno in europe.

Per saperne di più sul tipo di quote disponibili, consulta Quote sull'utilizzo delle risorse Cloud KMS. Puoi visualizzare il limite di quota nella console Cloud. I limiti iniziali delle quote sono limiti temporanei che puoi richiedere di modificare in base alle esigenze del tuo workload.

Logging

A Cloud KMS sono associati tre tipi di log: Cloud Audit Logs, log di Access Transparency e log interni delle richieste.

Cloud Audit Logs

Cloud KMS registra la tua attività in Cloud Audit Logs. Puoi visualizzare questi log nella console Cloud. Tutte le attività di amministrazione, ad esempio la creazione o l'eliminazione di una chiave, vengono registrate nei log. Puoi anche scegliere di abilitare la registrazione per tutte le altre azioni che utilizzano una chiave, ad esempio l'utilizzo di una chiave per criptare o decriptare i dati. Sei tu a decidere per quanto tempo conservare i log e chi può visualizzarli.

Log di trasparenza degli accessi

I clienti idonei possono scegliere di abilitare i log di Access Transparency, che contengono le azioni che i dipendenti Google eseguono nella tua organizzazioneGoogle Cloud . I log di Access Transparency, insieme a Cloud Audit Logs, sono utili per capire chi ha effettuato un'operazione, di cosa si trattava, dove e quando è stata eseguita.

Puoi integrare i log di Access Transparency con gli strumenti esistenti per la gestione degli eventi e delle informazioni di sicurezza (SIEM) al fine di automatizzare i controlli relativi a queste azioni. Questi log sono disponibili in Cloud Console insieme a Cloud Audit Logs.

Le voci dei log di Access Transparency includono i seguenti tipi di dettagli:

• La risorsa e l'azione interessate.
• L'ora dell'azione.
• I motivi dell'azione. Questi includono, ad esempio, assistenza richiesta dal cliente (con un numero di richiesta), assistenza offerta da Google, richieste di dati di terze parti e richieste di revisione avviate da Google.
• Dati su chi esegue azioni sui dati, ad esempio la località del membro del personale Google.

Log interni delle richieste

I log delle richieste archiviano un record per ogni richiesta inviata alla piattaforma Cloud KMS. Questo record contiene dettagli sul tipo di richiesta (ad esempio metodo o protocollo API) e sulla risorsa a cui si accede (ad esempio nome della risorsa, algoritmo della chiave o livello di protezione della chiave). Questi log non memorizzano il testo non crittografato, il testo crittografato o il materiale delle chiavi dei clienti. Prima di aggiungere nuovi tipi di dati a questi log, un team specializzato in revisioni della privacy deve approvare le modifiche ai dati registrati.

Le voci dei log vengono eliminate definitivamente quando scade la durata (TTL) configurata.

I tecnici e gli SRE di Cloud KMS che si occupano delle richieste di assistenza possono accedere ai log delle richieste. L'accesso ai log da parte di una persona e qualsiasi accesso che restituisce i dati dei clienti richiedono una giustificazione lavorativa valida e documentata. Con alcune eccezioni specifiche, l'accesso da parte di una persona viene registrato e i clienti idonei possono consultare le informazioni al riguardo nei log di Access Transparency.

Monitoraggio

Cloud KMS si integra con Cloud Monitoring. Questa integrazione ti consente di monitorare, creare dashboard e avvisi su molte operazioni Cloud KMS. Ad esempio, puoi monitorare quando le chiavi sono pianificate per la distruzione o monitorare e modificare le quote di Cloud KMS quando le operazioni di crittografia superano una soglia che definisci. Per ulteriori informazioni sulle metriche Cloud KMS disponibili, consulta Utilizzo di Cloud Monitoring con Cloud KMS.

Inoltre, Security Command Center dispone di rilevatori di vulnerabilità KMS integrati. Questi detector aiutano a garantire che i progetti che includono chiavi seguano le nostre best practice consigliate. Per ulteriori informazioni sul rilevatore di vulnerabilità KMS, consulta Risultati delle vulnerabilità per Cloud KMS.

Passaggi successivi

• Per saperne di più su Cloud KMS, consulta le seguenti risorse:
  • Documentazione di Cloud KMS
  • Documentazione di Cloud HSM
• Per informazioni sull'utilizzo delle tue chiavi di crittografia in Google Cloud, consulta Chiavi di crittografia gestite dal cliente (CMEK).
• Per saperne di più sulla sicurezza dell'infrastruttura Google, consulta la Panoramica sulla progettazione della sicurezza dell'infrastruttura Google.