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 loro 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 devono controllare l'utilizzo.

Quando archivi 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 at-rest e su come vengono gestite le chiavi di crittografia.

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

Chiavi in Google Cloud

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

Tipo di chiave	Cloud KMS Autokey	Gestita dal cliente (manuale) Cloud KMS	Google-owned and Google-managed encryption key (crittografia predefinita di Google)
Può visualizzare i metadati chiave	Sì	Sì	No
Proprietà delle chiavi^1	Cliente	Cliente	Google
Può gestire^2 e controllare^3 chiavi	La creazione e l'assegnazione delle chiavi sono automatizzate. Il controllo manuale da parte 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 con chiave condivisa (KEK).
Controllo della rotazione delle chiavi	Sì	Sì	No
Criteri dell'organizzazione CMEK	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	Variabile	Variabile	Gratis

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

² La gestione delle chiavi include le seguenti attività:

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

³ Per controllo delle chiavi si intende l'impostazione di controlli sul tipo di chiavi e sul loro utilizzo, il rilevamento della varianza e la pianificazione di un'azione correttiva, se necessario. Puoi controllare le tue chiavi, ma delegare la gestione delle chiavi 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 si basa sui 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 le chiavi BYOK (Bring Your Own Key) e HYOK (Hold Your Own Key).
• Controllo dell'accesso e monitoraggio:con Cloud KMS puoi gestire le autorizzazioni per le singole chiavi e monitorarne l'utilizzo.
• Regionalità:Cloud KMS offre la regionalizzazione out of the box. Il servizio è configurato per creare, archiviare ed elaborare le chiavi solo nella Google Cloud località selezionata.
• Backup:per evitare il danneggiamento dei dati e garantirne 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 degli audit log di Cloud.
• Separazione logica dei dati:la crittografia Cloud KMS offre 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 ti 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 portafoglio di chiavi include quanto segue:

• Crittografia predefinita:tutti i dati archiviati da Google vengono criptati nel 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 ulteriori informazioni, consulta Crittografia at-rest predefinita.

• Cloud KMS con chiavi protette da software:puoi controllare le chiavi generate in Cloud KMS. Il backend software di Cloud KMS offre la flessibilità necessaria per 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 da hardware, puoi utilizzare il backend Cloud HSM per garantire che le chiavi vengano utilizzate solo in moduli 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 Autokey di Cloud KMS. Autokey consente di automatizzare le procedure di provisioning e assegnazione delle chiavi per le chiavi di crittografia gestite dal cliente (CMEK). Le chiavi HSM convenzionali richiedono che un amministratore KMS le crei su richiesta.

• Cloud KMS con importazione delle chiavi: per soddisfare i requisiti BYOK, puoi importare le chiavi di crittografia che hai generato 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 archiviati in Google Cloud.

• Cloud KMS con gestore delle chiavi esterno (Cloud EKM): per soddisfare i requisiti HYOK, puoi creare e controllare le chiavi memorizzate in un gestore delle chiavi esterno a Google Cloud. Poi, configura la piattaforma Cloud KMS in modo da utilizzare le chiavi esterne per contribuire a proteggere i dati at-rest. 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 chiavi sono note come CMEK. La funzionalità CMEK consente di generare, utilizzare, ruotare ed eliminare le chiavi di crittografia che contribuiscono a proteggere i tuoi dati in altri Google Cloud servizi. Quando 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.

Portachiavi, chiavi e versioni delle chiavi

Il diagramma seguente illustra i raggruppamenti di chiavi, 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 gli elementi utilizzati effettivamente 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 le 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, consulta 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 queste 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, 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 dati vengono criptati utilizzando versioni di chiavi diverse. Le chiavi simmetriche hanno una versione principale. Per impostazione predefinita, la versione principale 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 dell'involucro per Cloud KMS e il Keystore interno di Google. La crittografia envelope è il processo di crittografia di una chiave con un'altra chiave, al fine di archiviarla o trasmetterla in modo sicuro 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 KEK. Le KEK sono archiviate in Cloud KMS. Il materiale della chiave non esce mai dal confine del sistema Cloud KMS.

Per le chiavi protette da software, una chiave master KMS specifica per la località cripta la KEK. La chiave master del KMS è archiviata nell'archivio chiavi. Esiste una chiave master KMS distinta nel 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 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 dall'hardware, una chiave di wrapping HSM specifica per la località cripta la KEK, che a sua volta viene criptata con la chiave master KMS. Per maggiori informazioni, consulta Creare le chiavi. Per le chiavi esterne, una chiave di wrapping EKM cripta la DEK con wrapping e la chiave di wrapping EKM viene poi criptata con la chiave master KMS.

Cloud KMS utilizza Keystore, il servizio di gestione delle chiavi interno di Google, per eseguire il wrapping delle chiavi criptate da Cloud KMS. Cloud KMS utilizza la stessa radice di attendibilità del Keystore. Per ulteriori informazioni su Keystore, consulta la sezione Gestione delle chiavi nel documento Crittografia at-rest.

Vincoli operativi

Cloud KMS opera nei seguenti limiti:

• Progetto: le risorse Cloud KMS appartengono a un Google Cloud progetto, proprio come tutte le altre Google Cloud risorse. Le chiavi Cloud KMS possono trovarsi in un progetto diverso rispetto ai 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 di 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 Geografia e regioni.
• Coerenza: Cloud KMS propaga le operazioni su chiavi, keyring e versioni delle chiavi utilizzando la coerenza forte o la coerenza finale. Per ulteriori informazioni, consulta la pagina relativa alla 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, con Google che gestisce le chiavi utilizzate per la crittografia. Per i prodotti Google Cloud compatibili che archiviano in modo permanente i contenuti dei clienti (ad esempio Cloud Storage), puoi 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 CMEK ti consentono di avere un maggiore controllo sulle chiavi utilizzate per criptare i dati at-rest all'interno di servizi Google Cloud compatibili e di fornire un confine crittografico attorno ai tuoi dati. Puoi gestire i 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 allo stesso modo in cui accade quando utilizzi solo la crittografia predefinita.

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

Poiché Cloud KMS utilizza la crittografia dell'involucro, una CMEK è una KEK che cripta le DEK. Per ulteriori informazioni, consulta la sezione Gerarchia delle chiavi.

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

• 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 la chiave di crittografia di una 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 ulteriori informazioni sulla rotazione delle chiavi, consulta la documentazione di ciascun prodotto.

Le policy dell'organizzazione CMEK offrono un maggiore controllo sull'utilizzo della chiave CMEK all'interno dei progetti. Questi criteri ti consentono di controllare i servizi e i progetti che contengono le chiavi consentite per CMEK, nonché il livello di protezione delle chiavi.

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

Cloud KMS Autokey

Autokey ti consente di semplificare la procedura di provisioning di CMEK. Durante una procedura di provisioning manuale di CMEK, un amministratore Cloud KMS deve pianificare i tipi di portachiavi, chiavi e account di servizio 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 attivi Autokey, uno sviluppatore può richiedere una chiave da Cloud KMS e l'agente di servizio esegue il provisioning della chiave giusta per le sue intenzioni. Con Autokey, le chiavi sono disponibili on demand, sono coerenti e rispettano le pratiche standard di settore.

Autokey esegue il provisioning e assegna chiavi, chiavi automatizzate e account di servizio su richiesta quando 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 pertanto vengono archiviate nel backend di Cloud HSM. Si tratta di chiavi di crittografia GCM AES-256.
• 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 (inclusa la rotazione, la distruzione o la modifica dello stato).
• Rotazione delle chiavi: le chiavi vengono ruotate ogni anno.
• Co-locazione delle chiavi 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 protetta dalla chiave, in base al tipo di risorsa. La specificità significa che non devi esaminare manualmente i tipi di risorse di ogni servizio e decidere quante risorse di ogni tipo 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é rimuove la necessità di eseguire l'infrastruttura come codice con privilegi elevati per la creazione di chiavi. Autokey è disponibile in tutte le Google Cloud località 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 da hardware e chiavi protette da software. La piattaforma Cloud KMS è integrata con Identity and Access Management (IAM) e 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 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 da software e 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 inGoogle Cloud memorizzano le chiavi. Per ulteriori informazioni sulla nostra certificazione, consulta il 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 degli sistemi critici di Google. Consulta Protezione del datastore.

• A intervalli regolari, il sistema di backup indipendente esegue il backup dell'intero datastore sia in archiviazione online sia in archiviazione. Questo backup consente a Cloud KMS di raggiungere i suoi obiettivi di durabilità. Consulta la sezione 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 girata 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. Inoltre, i clienti qualificati possono visualizzare i log relativi ai dati coperti da Access Transparency.

Il materiale della chiave 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 nel 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 al fine di mitigare la perdita di dati in caso di emergenza lato servizio.

Backup. I backup del datastore Cloud KMS si trovano all'interno della Google Cloud regione associata. Questi backup vengono tutti criptati quando sono inattivi. L'accesso ai dati nei backup è controllato in base alle motivazioni del caso, 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 hanno accesso al materiale delle chiavi dei clienti in testo non criptato. Inoltre, il datastore cripta tutti i dati che gestisce prima di scrivere nello spazio di archiviazione permanente. Pertanto, l'accesso ai livelli di archiviazione sottostanti, inclusi i dischi o l'archiviazione, non consente di accedere nemmeno ai dati criptati di Cloud KMS senza 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 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 Google Cloud regione 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 potrebbe venire annullato solo da moduli HSM che eseguono tutte le operazioni di crittografia con le chiavi.
• EXTERNAL o EXTERNAL-VPC: da applicare al gestore di chiavi esterno (EKM). EXTERNAL-VPC ti consente di connettere l'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 di BoringSSL di Google per tutte le operazioni di crittografia correlate. Il modulo BoringCrypto è convalidato FIPS 140-2. Il codice binario di Cloud KMS è creato in base alle primitive crittografiche di questo modulo convalidate secondo lo standard FIPS 140-2 livello 1. Gli algoritmi più recenti coperti da questo modulo sono elencati nella pagina 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 e 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. Ti 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 ti 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 ulteriori informazioni, consulta Architetture di riferimento per Cloud EKM.

Procedura di creazione della chiave

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

La procedura di creazione della chiave 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, hardware o è esterna).
2. Cloud KMS verifica l'identità dell'utente e se l'utente ha l'autorizzazione per creare la chiave.
3. La chiave viene generata nel seguente modo:
   • Per le chiavi protette da 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 del cliente e cripta (avvolge) questa chiave con la chiave di wrapping regionale dell'HSM. Cloud HSM restituisce la chiave con 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. L'EKM genera una nuova chiave e la cripta con la chiave di wrapping EKM. Cloud EKM restituisce la chiave con 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 successo con l'URI completo della versione della chiave.

Importazione di una chiave

Potresti voler importare le tue chiavi create on-premise o in un EKM nell'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 chiavi pubbliche/private, utilizzando uno dei metodi di importazione supportati. Grazie a questa chiave di wrapping, il materiale delle chiavi viene crittografato e protetto in transito.

La chiave di wrapping pubblica viene utilizzata per criptare la chiave da importare sul client. La chiave privata che corrisponde alla chiave pubblica viene archiviata in Google Cloud e 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 cliente che richiede l'accesso alle istanze di 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 del GFE.
2. GFE fornisce l'hosting degli IP pubblici per il nome DNS pubblico, la protezione 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 gesticono la negoziazione TLS e, utilizzando i parametri e l'URL della richiesta, determinano quale bilanciatore del carico software globale 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 la regioneGoogle 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 a cui viene eseguito l'accesso, quindi utilizza IAM per verificare se il chiamante è autorizzato a effettuare la richiesta. Inoltre, IAM indica se la richiesta deve essere scritta negli audit log. Se la funzionalità Giustifichiazioni per l'accesso alle chiavi è attivata, 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 Cloud HSM o al backend Cloud EKM, a seconda del livello di protezione della chiave.
8. Una volta completata l'operazione di crittografia, la risposta viene inviata nuovamente allo 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 ti consente di calcolare i checksum per le chiavi e i materiali delle chiavi per contribuire a garantire che non siano danneggiati. Questi checksum ti aiutano a proteggerti dalla perdita di dati che potrebbe essere causata da danneggiamenti hardware o software. Le librerie di supporto ti consentono di verificare l'integrità delle chiavi. Puoi utilizzare le librerie di supporto per verificare l'integrità delle chiavi fornendo i checksum a Cloud KMS, che vengono verificati dal server. Inoltre, queste librerie ti consentono di ricevere i 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:

• Corruzione durante il transito, ad esempio nello stack tra il momento in cui i dati vengono inviati e il momento in cui vengono protetti da TLS.
• Problemi in eventuali proxy intermedi tra l'endpoint e KMS (ad esempio per le richieste in arrivo).
• 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 Verificare l'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 riguarda anche Cloud KMS. Il materiale delle chiavi viene distrutto su richiesta al termine del periodo Pianificata per l'eliminazione e quando scadono i backup. Il materiale delle chiavi ancora presente nei backup (al termine del periodo di pianificazione dell'eliminazione) può essere utilizzato solo per il disaster recovery a livello di regione 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 rimangono nello stato Pianificata per eliminazione (eliminata temporaneamente) per 30 giorni prima che il materiale della chiave venga eliminato logicamente dal sistema. Puoi modificare questa durata. Per ulteriori informazioni, consulta Durata variabile dello stato Programmato 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.

Se la versione di una chiave è pianificata per essere eliminata, non può essere utilizzata per 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 reimportarla. Per ulteriori informazioni, consulta la sezione Reimportare una chiave distrutta.

Per evitare di eliminare accidentalmente una chiave, segui queste 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 Pianificata 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 ulteriori informazioni, consulta Richiedi la disattivazione delle chiavi prima della distruzione.
• Crea un ruolo KMS personalizzato che non includa l'autorizzazionecloudkms.cryptoKeyVersions.destroy.
• Modifica il campo destroy_scheduled_duration in modo da impostare 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 delle richieste dei clienti, come la rotazione delle chiavi in base alla pianificazione, la creazione di chiavi asimmetriche e l'importazione delle chiavi. Questi job di pubblicazione vengono eseguiti in ogni Google Cloud regione 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 nell'area geografica della 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 vengono eseguiti all'interno di una specifica area geografica e aggregano solo i dati provenienti dall'area geografica Google Cloud associata. Le attività eseguite da questi job includono quanto segue.

• Conta le chiavi attive per la fatturazione dei clienti.
• Aggregare le risorse dall'API pubblica per il buffer di protocollo per Cloud KMS e inoltrare i metadati a Cloud Asset Inventory. Le risorse in questo contesto sono quelle gestite da Cloud KMS, ad esempio chiavi e keyring.
• Aggregare tutte le risorse e le informazioni dei report per le analisi aziendali.
• Generazione di snapshot dei dati per l'alta disponibilità.
• Verificare l'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 generata da uno snapshot se non sono trascorse più 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 garantire la sicurezza delle comunicazioni client-server che utilizzano il meccanismo di chiamata di procedura remota (RPC) di Google.

Per ulteriori informazioni, consulta 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 sia le funzionalità delle chiavi protette da software che quelle protette 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 il 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 doveri degli operatori di sistema sono definiti nelle procedure operative standard. Gli operatori di sistema non accedono al materiale delle chiavi dei clienti durante l'esercizio delle loro funzioni.

Aree geografiche delle risorse Cloud KMS

Per aiutarti a soddisfare eventuali requisiti di residenza delle chiavi, puoi creare risorse Cloud KMS in uno dei quattro tipi di Google Cloud località:

• Una località a livello di regione è composta da zone in un luogo geografico specifico, 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à a più regioni è 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

Un' Google Cloud area geografica contiene un data center specifico o un insieme specificato di data center, determinato dalla rispettiva designazione come località con una sola area geografica, due aree geografiche o più aree geografiche oppure come località globale. Per ulteriori informazioni sulle Google Cloud regioni, consulta Google Cloud le località.

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 devono essere 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.

Localizzazione delle chiavi

Alcuni settori richiedono che le chiavi crittografiche si trovino in una località specifica. Cloud KMS ha termini relativi alla posizione 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 e il materiale delle chiavi protette da software e hardware 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 localizzazione per metadati delle chiavi, log di utilizzo o materiale delle chiavi in transito. I metadati delle chiavi comprendono 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 alle tue chiavi, indipendentemente dalle località personalizzate con due o più regioni che scegli in altri Google Cloud prodotti che supportano CMEK:

• Per una regione specifica: poiché la regione di una chiave KMS gestita dal cliente deve sempre essere correlata alla regione della risorsa che protegge in un determinato servizio Google Cloud , le limitazioni relative alla residenza per le chiavi e le risorse di una singola regione sono garantite come compatibili e applicate.
• Per località con due o più regioni: gli utenti possono scegliere località con 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à geografica 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
A due regioni 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ò aiutarti a semplificare i requisiti di disponibilità in base alle regioni selezionate. Più granulare è la località, maggiore è la ridondanza da creare. Per le applicazioni con livelli di disponibilità più elevati, utilizza località in più regioni anziché provare a creare il tuo 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 incluso nella lista consentita per le regioni Cloud private pertinenti.

Gestione delle quote

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

• Quote per le richieste crittografiche per operazioni come crittografia, decrittografia o firma.
• Quote per le richieste di lettura per operazioni come l'ottenimento 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 all'utente chiamante. Queste quote sono inoltre globali, il che significa che vengono applicate all'utilizzo di KMS da parte dell'utente chiamante in tutte le regioni e nelle 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 alla quota di richieste di crittografia. Le quote Cloud HSM e Cloud EKM vengono addebitate al progetto in cui si trova la chiave e vengono applicate per ogni località.

Considera gli esempi seguenti:

• La chiamata a decripta 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 una unità di quota di richieste di scrittura e nessuna quota HSM.
• La chiamata a crittografia con una chiave EKM in europe richiede una unità di quota per le richieste crittografiche (globali) e una unità di quota per le richieste KMS esterne in europe.

Per ulteriori informazioni sul tipo di quote disponibili, consulta Quote per l'utilizzo delle risorse Cloud KMS. Puoi visualizzare il limite di quota nella console Cloud. I limiti iniziali delle quote sono limiti flessibili che puoi richiedere di modificare in base alle esigenze del tuo carico di lavoro.

Logging

A Cloud KMS sono associati tre tipi di log: audit log di Cloud, 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 attivare il logging per tutte le altre azioni che prevedono l'impiego di 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 attivare i log di Access Transparency, che contengono le azioni che i dipendenti Google eseguono nella tuaGoogle Cloud organizzazione. I log di Access Transparency, insieme agli audit log di Cloud, 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 nella console Cloud insieme agli audit log di Cloud.

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 dedicato alla revisione 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 consente di monitorare, creare dashboard e generare avvisi su molte operazioni di Cloud KMS. Ad esempio, puoi monitorare quando è pianificata la distruzione delle chiavi o monitorare e modificare le quote di Cloud KMS quando le operazioni di crittografia superano una soglia che hai definito. Per ulteriori informazioni sulle metriche Cloud KMS disponibili, consulta Utilizzare Cloud Monitoring con Cloud KMS.

Inoltre, Security Command Center dispone di rilevatori di vulnerabilità KMS integrati. Questi detector contribuiscono 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 scoprire 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 scoprire di più sulla sicurezza dell'infrastruttura Google, consulta la Panoramica sulla progettazione della sicurezza per l'infrastruttura Google.