Approfondimenti su Cloud Key Management Service

Questi contenuti sono stati aggiornati l'ultima volta a luglio 2023 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.

Google Cloud si basa sul presupposto che i clienti di Google Cloud possiedono i propri dati e ne devono controllare l'utilizzo.

Una volta archiviati con Google Cloud, i dati vengono criptati quando sono inattivi per impostazione predefinita. Quando utilizzi la piattaforma Cloud Key Management Service (Cloud KMS), puoi ottenere un maggiore controllo su come vengono criptati i dati inattivi e su come vengono gestite le chiavi di crittografia.

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

Tipo di chiave	Gestione delle chiavi	Condivisione della chiave	Rotazione automatica	Prezzi
Chiave di crittografia predefinita	Queste chiavi sono gestite esclusivamente da Google.	I dati di più clienti potrebbero utilizzare la stessa chiave di crittografia della chiave (KEK).	Sì, consulta la sezione Crittografia at-rest predefinita.	Gratuito.
Chiavi Cloud KMS	Queste chiavi sono controllate dal cliente.	Unico per un cliente.	Sì per la crittografia simmetrica, no per le chiavi asimmetriche. Consulta Rotazione delle chiavi.	Consulta la pagina Prezzi di Cloud Key Management Service.

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.

Elementi di progettazione fondamentali 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 cinque elementi di progettazione fondamentali:

• 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 località di Google Cloud 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 di Cloud Audit Logs.

Origini e opzioni di gestione dei materiali delle chiavi

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 seguente diagramma mostra il portafoglio di Google Cloud per le chiavi, organizzato dal materiale delle chiavi controllato da Google a quello controllato dal cliente.

Le opzioni mostrate nel diagramma precedente sono le seguenti:

• 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 generate dal software:con Cloud KMS puoi controllare le chiavi generate da Google. 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 generate 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 di Cloud HSM per garantire che le chiavi simmetriche e asimmetriche vengano utilizzate solo in moduli di sicurezza hardware (HSM) convalidati di tipo FIPS 140-2 livello 3.

• 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 Cloud e utilizzare il materiale della chiave in Cloud KMS per criptare o firmare i dati archiviati in Google Cloud.

• Cloud KMS con un key manager esterno (Cloud EKM): per soddisfare i requisiti HYOK, puoi creare e controllare le chiavi memorizzate in un key manager esterno a Google Cloud. Poi, configura la piattaforma Cloud KMS in modo da utilizzare le chiavi esterne per contribuire a difendere i tuoi dati a riposo. 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 il deployment affidabile dei servizi Cloud EKM.

Puoi scegliere di utilizzare le chiavi generate da Cloud KMS con altri servizi Google Cloud. Queste sono chiamate chiavi di crittografia gestite dal cliente (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 Cloud.

Concetti di 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 diagramma seguente illustra i raggruppamenti di chiavi, i keyring e le chiavi con una singola versione principale e più versioni precedenti.

I concetti chiave 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 software

Il seguente diagramma illustra la gerarchia delle chiavi per Cloud KMS e per il Keystore interno di Google. Cloud KMS utilizza Keystore, il Key Management Service interno di Google, per eseguire il wrapping delle chiavi criptate da Cloud KMS. La crittografia dell'involucro è il processo di crittografia di una chiave mediante un'altra chiave, al fine di memorizzarla o trasmetterla in modo sicuro tramite un canale non attendibile. Cloud KMS utilizza la stessa radice di attendibilità del Keystore.

La gerarchia delle chiavi mostrata nel diagramma precedente è la seguente:

1. Una chiave di crittografia dei dati (DEK) cripta i blocchi di dati.
2. Per criptare o sottoporre a wrapping la DEK viene utilizzata una chiave di crittografia della chiave (KEK). Tutte le opzioni della piattaforma Cloud KMS (software, hardware e backend esterni) consentono di controllare la KEK. Le KEK sono archiviate in Cloud KMS.
3. Una chiave master KMS cripta la KEK. La chiave master del KMS è archiviata nel Keystore. In Keystore è presente una chiave master KMS separata per ogni località Cloud KMS. Le chiavi KEK in Cloud KMS sono protette dalla chiave master del KMS della località. Ogni 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.
4. La chiave master del KMS è protetta dalla chiave master dell'archivio chiavi nell'archivio chiavi.
5. La chiave master del keystore è protetta dalla chiave master del keystore principale.

Per ulteriori informazioni sul Keystore, consulta la sezione Gestione delle chiavi nel documento Crittografia at-rest.

Principali vincoli operativi

Cloud KMS opera nei seguenti limiti:

• Progetto: le risorse di Cloud KMS appartengono a un progetto Google Cloud, proprio come tutte le altre risorse Google Cloud. Puoi ospitare i dati in un progetto diverso da quello in cui si trovano le chiavi Cloud KMS. 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 principale.
• 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 elevata coerenza o la coerenza finale. Per ulteriori informazioni, consulta la pagina relativa alla coerenza delle risorse Cloud KMS.

Panoramica 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, hardware e basate su 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 Cloud o Google Cloud CLI.

• Le applicazioni accedono ai servizi di gestione delle chiavi implementando l'API REST, gRPC o le librerie client.gRPC 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. Sia le chiavi basate su software che quelle basate su hardware utilizzano le funzionalità di protezione offerte dal backup ridondante di Google.

• Se utilizzi chiavi hardware, gli HSM certificati FIPS 140-2 di livello 3 in Google 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 dei 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 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.

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 a una pianificazione, la creazione di chiavi asimmetriche e l'importazione delle chiavi. Questi job di pubblicazione vengono eseguiti in ogni regione di Google 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 nell'area geografica di Google 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 di 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.

Architettura della piattaforma Cloud KMS

Questa sezione descrive i dettagli dell'architettura relativi alla sicurezza dei materiali delle chiavi e alla protezione del datastore.

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 dell'area geografica di Google Cloud 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 dell'area geografica di 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

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 (BCM) all'interno dell'implementazione di BoringSSL di Google per tutte le operazioni di crittografia correlate. Il BCM è convalidato secondo lo standard 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 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. I clienti Cloud KMS esistenti non devono apportare alcuna modifica alle applicazioni al fine di utilizzare Cloud HSM. Possono accedere al backend di Cloud HSM utilizzando la medesima 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 il deployment affidabile dei servizi EKM di Cloud.

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

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 progetto Google 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.

Chiavi di crittografia gestite dal cliente (CMEK)

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 alcuni prodotti Google Cloud, puoi invece utilizzare Cloud KMS per gestire le chiavi impiegate per la crittografia. La funzionalità CMEK può essere utilizzata per chiavi esterne, software e hardware. 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.

La rotazione della chiave Cloud KMS non cripta nuovamente i dati nel servizio CMEK associato. Le risorse appena create vengono invece criptate utilizzando la nuova versione della chiave, il che significa che versioni diverse di una chiave proteggono sottoinsiemi diversi di dati. Ad esempio, 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. Le nuove tabelle BigQuery utilizzano la versione della chiave corrente. Per ulteriori informazioni, consulta la documentazione di ogni prodotto.

Le policy dell'organizzazione CMEK offrono un maggiore controllo sull'utilizzo del CMEK all'interno dei progetti. Queste norme ti consentono di controllare sia i servizi sia i progetti che contengono le chiavi consentite per CMEK.

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 prodotti Google Cloud.

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. Un cliente, o un job in esecuzione per conto di un cliente, 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 DoS e la terminazione TLS. Quando il cliente invia la richiesta, questa di solito viene indirizzata a un servizio GFE vicino al cliente, 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 Google 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 servizi Google Cloud. Questo framework autentica l'utente ed esegue una serie di controlli per verificare quanto segue:
   • Il cliente 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.
   • Il cliente si trova nella lista consentita di utenti che possono utilizzare l'area geografica di 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 a cui viene eseguito l'accesso, quindi utilizza IAM per verificare se il chiamante è autorizzato a effettuare la richiesta. Inoltre, IAM indica a Cloud KMS se la richiesta deve essere scritta negli audit log.
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 del cliente 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 al cliente sullo stesso tipo di canale GFE-KMS della richiesta.
9. Quando la risposta viene inviata, Cloud KMS attiva anche alcuni 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 in Google Cloud si applica anche a 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 ripristino di emergenza 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:

• Crea un ruolo KMS personalizzato che non includa l'autorizzazionecloudkms.cryptoKeyVersions.destroy.
• Modifica il campo destroy_scheduled_duration in 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.

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 sia software che 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 località Google Cloud:

• 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'area geografica di Google Cloud contiene un data center specifico o un insieme specifico 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 regioni Google Cloud, consulta Località Google 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 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 software e hardware del cliente, 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 dell'area geografica di Google 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 scelte in altri prodotti Google Cloud che supportano le chiavi 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 per le risorse Google Cloud 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 costituiscono la 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à, più devi creare ridondanza. 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. Ecco alcuni esempi:

• 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 privato 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 anche 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 a quella relativa alle 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 una 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.
• L'utilizzo di 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: Cloud Audit Logs, log di Access Transparency e log interni delle richieste.

Cloud Audit Logs

Cloud KMS registra la tua attività negli audit log di Cloud. 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 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 nell'organizzazione Google 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 nella console Cloud 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 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 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).
• Scopri come Google si prepara per un mondo post-quantistico.
• Per scoprire di più sulla sicurezza dell'infrastruttura Google, consulta la Panoramica sulla progettazione della sicurezza per l'infrastruttura Google.
• Per informazioni generali sulla sicurezza di Google Cloud, consulta la sezione sulla sicurezza del sito web di Google Cloud.