Approfondimenti su Cloud Key Management Service

Questi contenuti sono stati aggiornati l'ultima volta a luglio 2023 e rappresentano lo status quo alla data dall'ora in cui è stato scritto. Le norme e i sistemi di sicurezza di Google potrebbero cambiare nel miglioramento continuo della protezione dei 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 crittografia della chiave chiave (KEK).	Sì, consulta la sezione Crittografia at-rest predefinita.	Gratuito.
Chiavi Cloud KMS	Queste chiavi sono controllate dal cliente.	Univoco 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 si concentra sui meccanismi interni della piattaforma Cloud KMS. Queste opzioni consentono di proteggere le chiavi e altri dati riservati archiviati in Google Cloud. Questo documento è 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 comprende supporto per il modello BYOK (Bring Your Own Key) e per la modalità hold-your-own-key (HYOK).
• Controllo dell'accesso e monitoraggio: con Cloud KMS puoi gestire le autorizzazioni per le singole chiavi e monitorarne l'utilizzo.
• Area geografica: Cloud KMS offre la regionalizzazione . Il servizio è configurato per creare, archiviare ed elaborare le chiavi solo alla località Google Cloud che hai selezionato.
• Backup:per contribuire a evitare il danneggiamento dei dati e per verificare che i dati possono essere decriptati correttamente, Cloud KMS analizza periodicamente ed esegue il backup di tutto il materiale e dei metadati della chiave.
• 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.

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 sono criptati a livello di archiviazione usando l'algoritmo AES (Advanced Encryption Standard) algoritmo AES-256. Generiamo e gestiamo le chiavi per la crittografia predefinita, e i clienti non hanno accesso alle chiavi o controllo della rotazione della chiave gestione dei dispositivi. 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 puoi utilizzare il backend Cloud HSM per garantire che le tue proprietà simmetriche le chiavi asimmetriche vengono utilizzate solo FIPS 140-2 Livello 3: convalidato HSM.

• 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 Google Cloud e utilizzare il materiale delle chiavi in Cloud KMS crittografare o firmare i dati archiviati in Google Cloud.

• Cloud KMS con il gestore di chiavi esterno (Cloud EKM): Per soddisfare i requisiti di HYOK, puoi creare e controllare chiavi che in un gestore di chiavi 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 chiavi generate da Cloud KMS insieme ad altri servizi Google Cloud. Queste chiavi sono note come 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 seguente diagramma illustra i raggruppamenti di chiavi e mostra i keyring e le chiavi con un'unica 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: le bit effettivamente utilizzate per le operazioni crittografiche, possono cambiare nel tempo man mano che crei una nuova chiave. e versioni successive. Puoi assegnare criteri di autorizzazione IAM a livello di chiave nella 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 crittografare un blocco di testo non crittografato. Una chiave asimmetrica può essere utilizzata per la crittografia 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. Chiavi i criteri di autorizzazione dal proprio 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. Tag puoi consentire o negare in modo condizionale i criteri a seconda che una risorsa ha 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, quindi il loro proseguimento non influisce sui costi o sui limiti di produzione.

• Metadati delle chiavi: nomi delle risorse, proprietà delle risorse KMS come di autorizzazione, il tipo di chiave, le dimensioni e lo stato della chiave, oltre a tutti i dati derivanti e i keyring.

• Versione chiave: il materiale della chiave associato a una chiave in un determinato momento nel tempo. La versione chiave è la risorsa che contiene il materiale effettivo della chiave. 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. Di per impostazione predefinita, per la crittografia viene utilizzata la versione primaria. Quando Cloud KMS esegue la decriptazione mediante chiavi simmetriche, identifica automaticamente la versione della chiave necessaria per eseguire la decriptazione.

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 l'archivio chiavi, l'archivio delle chiavi per il wrapping delle chiavi criptate su Cloud KMS. Crittografia della busta è il processo di crittografia di una chiave con un'altra chiave, per garantire memorizzarli o trasmetterli su un canale non attendibile. Cloud KMS utilizza la stessa radice di attendibilità dell'archivio chiavi.

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

1. Una chiave di crittografia dei dati (DEK) cripta i blocchi di dati.
2. 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.
3. Una chiave master del KMS cripta la KEK. La chiave master KMS è archiviata in Archivio chiavi. Nell'archivio chiavi è presente una chiave master KMS separata per ogni Località Cloud KMS. Le KEK in Cloud KMS sono protette dalla chiave master 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 dell'archivio chiavi è protetta dalla chiave master dell'archivio chiavi principale.

Per ulteriori informazioni sull'archivio chiavi, consulta Gestione delle chiavi nel documento Crittografia at-rest.

Principali vincoli operativi

Cloud KMS opera all'interno dei seguenti vincoli:

• Progetto: le risorse 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 Cloud KMS vengono creato in un 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.

Panoramica della piattaforma Cloud KMS

La piattaforma Cloud KMS supporta più algoritmi crittografici e fornisce metodi per criptare e firmare in modo digitale utilizzando basate su software. La piattaforma Cloud KMS è integrata con Identity and Access Management (IAM) e Audit log di Cloud in modo da poter gestire le autorizzazioni per le singole chiavi e controllarne in uso.

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 API REST, gRPC, o librerie client. Le applicazioni possono utilizzare i servizi Google abilitati per l'utilizzo di CMEK. CMEK in utilizza l'API Cloud Key Management Service. Se la tua applicazione utilizza PKCS #11, puoi integrarlo con Cloud KMS utilizzando raccolta per PKCS #11.

• L'API Cloud KMS consente di utilizzare software, hardware o chiavi esterne. Sia le chiavi basate su software che quelle basate su hardware utilizzano il backup ridondante di Google le tue protezioni.

• Se si utilizzano chiavi hardware, gli HSM certificati FIPS 140-2 di livello 3 in e Google Cloud archivia le chiavi. Per ulteriori informazioni sulle nostre certificazione, consulta Certificato n. 4399.

• Cloud KMS utilizza il datastore interno di Google per archiviare contenuti crittografati materiale della chiave del cliente. 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 archiviazione sia online che in archiviazione dei dati ad accesso sporadico. Questo backup consente a Cloud KMS per raggiungere i suoi obiettivi di durabilità. Consulta: Protezione del datastore.

Convalida FIPS 140-2

Le operazioni crittografiche di Cloud KMS vengono eseguite dal nostro sistema FIPS 140-2 moduli convalidati. 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 crittografica open source gestita da Google. I tasti con il livello di protezione di HSM e le operazioni crittografiche eseguite con il livello 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 gestore di cluster su larga scala di Google per la gestione di job di gestione API e batch di lavoro.

Per informazioni sulla sicurezza dei nostri sistemi fisici e infrastruttura, consulta 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 regione di Google Cloud in cui è disponibile Cloud KMS. Ogni job è associato a una singola regione ed è configurato per accedere solo provenienti da sistemi che si trovano geograficamente all'interno regione Google Cloud.

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 chiavi attive per fatturazione del cliente.
• Aggrega le risorse API buffer protocollo pubblico per Cloud KMS e l'inoltro dei metadati Cloud Asset Inventory. Le risorse in questo contesto sono quelle gestite da Cloud KMS, ad esempio chiavi e keyring.
• Aggrega tutte le risorse e le informazioni dei report per le analisi aziendali.
• Dati di snapshot 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 datastore primario è lento o non disponibile, la risposta può essere fornita da un snapshot, se non è stato creato più di due ore prima. 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

In questa sezione vengono descritti i dettagli dell'architettura sicurezza dei materiali delle chiavi e 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.
• Se la chiave interna di Google utilizzata per proteggere il materiale della chiave del cliente viene ruotato o controllato per verificarne 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 sia tra i dati Google center.

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 periodo di rotazione). Un dipendente Google con un'attività valida e documentata alla giustificazione (come un bug o un problema del cliente) possono accedere anche ai metadati della chiave. Questi eventi di accesso vengono registrati internamente e i log relativi ai dati coperti Trasparenza degli accessi disponibili anche per clienti qualificati.

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 a un cliente non criptato materiale della chiave. Inoltre, il materiale della chiave è criptato con una chiave master in Archivio chiavi, non accessibile direttamente a nessuno. Su un HSM, la chiave non è mai possibile accedere al materiale in stato decriptato dai job dell'API Cloud KMS.

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 utilizzando un codice HMAC (Hash-based Message Authentication Code) per garantirne l'autenticazione. che non sia stato alterato o danneggiato quando è inattivo. 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 dispone di procedure documentate per ripristinare i backup a mitigare la perdita di dati in caso di emergenza lato servizio.

Backup. I backup del datastore Cloud KMS si trovano regione 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 della chiave viene criptato prima di essere archiviato. Gli ingegneri con accesso al datastore avere accesso a materiale in chiaro delle chiavi del cliente. Inoltre, il datastore cripta tutti i dati che gestisce prima di scriverli nello spazio di archiviazione permanente. Pertanto, accesso ai livelli di archiviazione sottostanti, tra cui dischi non consente l'accesso nemmeno ai dati criptati di Cloud KMS senza alle chiavi di crittografia del datastore, che sono archiviate nell'archivio chiavi.

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. Archivio chiavi la chiave master ha una durata massima di 90 giorni del testo crittografato con un client durata massima della chiave memorizzata nella cache 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. Questo si applica anche alle località che hanno più regioni, ad esempio l'us in più regioni.

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 della chiave

Quando crei una chiave con Cloud KMS, puoi scegliere una livello di protezione per determinare quale backend della chiave crea la chiave ed esegue tutte le operazioni future le operazioni crittografiche su quella chiave. I backend sono esposti nell'API Cloud KMS come i seguenti livelli di protezione:

• SOFTWARE: si applica alle chiavi che potrebbero essere sottoposte a unwrapping da un software modulo di sicurezza per eseguire operazioni crittografiche.
• HSM: si applica alle chiavi di cui l'unwrapping può essere annullato solo da HSM che eseguono tutte le operazioni crittografiche con le chiavi.
• EXTERNAL o EXTERNAL-VPC: applica al gestore di chiavi esterno (EKM). EXTERNAL-VPC ti consente di connettere l'EKM a Google Cloud tramite un VPC in ogni rete.

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 di Google BoringSSL per tutte le attività crittografiche correlate. Il BCM è convalidato secondo lo standard FIPS 140-2. Il file binario di Cloud KMS viene creato FIPS 140-2 Livello 1: primitive crittografiche convalidate di questo modulo. La più recente gli algoritmi trattati in questo modulo sono elencati Scopi e algoritmi chiave, e includono operazioni di crittografia, decriptazione e firma con le operazioni simmetriche AES256-GCM Crittografia asimmetrica RSA 2048, RSA 3072, RSA 4096, EC P256 ed EC P384 chiave.

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 comportamento del numero casuale, generatore per BoringSSL (modalità conforme allo standard FIPS), consulta 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 di 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 informazioni sul backend 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 memorizzate e gestite in un sistema di gestione delle chiavi esterno. Per ulteriori informazioni, vedi Architetture di riferimento per un deployment affidabile dei servizi Cloud EKM.

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. Importazione chiavi consente di importare queste chiavi e soddisfare 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. La crittografia del materiale della chiave con questa chiave di wrapping protegge il materiale della chiave trasporto pubblico.

Puoi utilizzare la chiave di wrapping pubblica per criptare la chiave da importare sul client. La chiave privata che corrisponde alla chiave pubblica viene archiviata in Google Cloud e utilizzata per annullare il wrapping della chiave pubblica dopo che raggiunge il progetto Google Cloud. Il metodo di importazione scelto determina 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 usare 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 all'interno di 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 inattivi dei clienti, con Google che gestisce le chiavi utilizzate per la crittografia. Per alcuni prodotti Google Cloud, puoi invece utilizzare Cloud KMS per gestire le chiavi impiegate per la crittografia. È possibile utilizzare CMEK per chiavi esterne, software e hardware. Cloud KMS consente di controllare molti aspetti delle chiavi (come la creazione, attivazione, disattivazione, rotazione ed eliminazione di chiavi) e gestire le opzioni IAM appropriate le relative autorizzazioni. Per applicare una separazione consigliata dei compiti, Cloud KMS include diversi ruoli IAM predefiniti con privilegi e limitazioni specifici e che possono essere concessi a specifici e account di servizio.

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

Criteri dell'organizzazione CMEK per avere un maggiore controllo sulle modalità di utilizzo di CMEK all'interno dei tuoi 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: Integrazioni CMEK per consultare l'elenco completo delle integrazioni 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 che richiede l'accesso alle istanze di servizio Cloud KMS in us-east1 e us-west1 e come vengono instradate le richieste tramite 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, compone una 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 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 per us-west1, la richiesta viene inoltrata tra us-east1 e us-west1 data center on-premise. 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 e 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 e dispone di 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. Una volta superati 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. IAM indica inoltre Cloud KMS indica se l'occorrenza della richiesta deve essere scritta in e gli 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 helper l'integrità della chiave fornendo checksum a Cloud KMS, che sono verificati dal server. Inoltre, queste librerie consentono di ricevere checksum verificare i dati di risposta sul client.

L'integrità dei dati end-to-end aiuta a proteggere l'ambiente da minacce come le seguenti:

• Danneggiamento durante il trasporto. ad esempio nello stack tra quando i dati quando viene inviato e quando viene protetto 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 dei moduli 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

I materiali chiave sono considerati dati dei clienti, perciò l'approccio descritto in Eliminazione di dati su 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. La chiave ancora presente nei backup (dopo l'eliminazione pianificata periodo è terminato) può essere utilizzato solo per il ripristino di emergenza a livello di regione e non per ripristinare singole chiavi. Questo processo non è garantito per le copie dei file esistenti al di fuori del controllo di Cloud KMS.

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

Sebbene il materiale delle chiavi venga eliminato, non è possibile eliminare le chiavi e i keyring. Legenda non possono essere eliminate, ma il materiale della versione della chiave può essere eliminato che le risorse non possono più essere usate. 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.

Dopo aver pianificato l'eliminazione della versione della chiave, quest'ultima non viene disponibili per le operazioni crittografiche. 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 maggiori informazioni le informazioni, vedi Reimportare una chiave eliminata.

Per evitare di eliminare accidentalmente una chiave, prendi in considerazione le seguenti best practice:

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

• Creare processi disabilita la chiave per un paio di giorni prima che la chiave 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 si applica alle funzionalità chiave sia software che hardware.

Tecnici software, SRE e operatori di sistema

Gli ingegneri informatici sono responsabili della collaborazione con altri stakeholder, come in qualità di product manager e tecnici della Site Reliability Engineering (SRE) per progettare il sistema e scrivere gran parte del codice e testare 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. Gli SRE potrebbero anche scrivere le API nel tuo codice. Tuttavia, i loro compiti sono diversi da quelli dei tecnici software. Gli SRE sono responsabili principalmente della manutenzione dell'ambiente di produzione per i job Cloud KMS. Gli SRE misurano e garantiscono l'affidabilità tramite attività di progettazione e operative.

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

I compiti degli operatori di sistema sono definiti nelle procedure operative standard. Gli operatori di sistema non accedono al materiale delle chiavi dei clienti durante 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à multiregionale è composta da dislocati in un'area geografica generale, come 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 saperne di più sulle località Cloud KMS disponibili, consulta 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 sono aperta per più persone; ogni persona 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 località a singola, doppia o più regioni, Cloud KMS crea, archivia ed elabora le chiavi sia software che hardware e il materiale delle chiavi solo in quella posizione. Sistemi di archiviazione ed elaborazione dati utilizzati da Cloud KMS sono configurate per utilizzare solo le risorse all'interno della regione Google Cloud che è associato al materiale della chiave. 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 un KMS gestito dal cliente la chiave deve sempre essere correlata alla regione della risorsa che protegge in base al servizio Google Cloud, le limitazioni di residenza per una singola regione le chiavi e le risorse sono garantite che siano 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	At-rest, 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ò aiutare a semplificare i requisiti di disponibilità in base a le regioni selezionate. Più granulare è la località, maggiore sarà la ridondanza da creare. Per applicazioni con livelli la disponibilità, usa località multiregionali anziché provare a creare di replicazione delle chiavi. Devi bilanciare la ridondanza integrata per soddisfare 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'ambiente pubblico API Service Control 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 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 di crittografia per operazioni come crittografia, decriptare o firmare.
• 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 un'impostazione 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 crittografiche. 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:

• Per chiamare la decrittografia con una chiave software in asia-northeast1 è necessaria una unità della quota di richieste crittografiche (globali).
• La creazione di una chiave HSM in us-central1 richiede una unità di quota per le 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 sull'utilizzo delle risorse Cloud KMS. Puoi visualizzare il limite di quota nella console Cloud. L'iniziale di quota sono limiti flessibili che puoi richiedere modificato in base alle esigenze del tuo carico di lavoro.

Logging

A Cloud KMS sono associati tre tipi di log: Cloud Audit Logs, Access Transparency log 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 li può visualizzare.

Log di trasparenza degli accessi

I clienti idonei possono scegliere di attivare Trasparenza degli accessi log delle azioni che i dipendenti Google eseguono nei tuoi dell'organizzazione Google Cloud. I log di Access Transparency, insieme ai log da Cloud Audit Logs, può aiutarti a rispondere a domande su chi ha fatto cosa, dove e quando.

Puoi integrare i log di Access Transparency con i dati di sicurezza esistenti strumenti di gestione delle informazioni e degli eventi (SIEM) per automatizzare il controllo di questi azioni. Questi log sono disponibili nella console Cloud insieme al tuo 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.
• La motivi per l'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 dei clienti, testo crittografato o materiale delle chiavi. Prima di aggiungere nuovi tipi di dati a questi log, è necessario un team specializzato in revisioni della privacy deve approvare le modifiche ai dati dei dati nel log.

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 Cloud KMS. Ad esempio, puoi monitorare quando è pianificata l'eliminazione delle chiavi o monitorare e regolare le quote di Cloud KMS quando le operazioni crittografiche superano una soglia da te definita. 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 saperne di più su Cloud KMS, esplora le risorse seguenti:
  • 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 in che modo Google si sta preparando a 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.