Approfondimenti su Cloud Key Management Service

Autori: Sonal Shah, Il-Sung Lee, Walter Poupore, Hunter Freyer, Honna Segel, Dwight Worley

Ringraziamenti: Adrian Sears, John Randolph, Tim Dierks, Chris Rezek, Stanley McKenzie, Kevin Plybon, David Hale, Sergey Simakov, David U. Lee, Carrie McDaniel, Anton Chuvakin, Dave Tonisson

Ultimo aggiornamento: aprile 2020

1. Introduzione

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. Grazie alla nostra 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 piattaforma Cloud KMS consente ai clienti di Google Cloud di gestire le chiavi di crittografia in un servizio cloud centrale per utilizzarle direttamente o con altre risorse e applicazioni cloud. Per l'origine delle chiavi, Cloud KMS offre le seguenti opzioni:

  • Il backend software di Cloud KMS offre la flessibilità necessaria per criptare i dati con una chiave simmetrica o asimmetrica che controlli personalmente (Cloud KMS).
  • Se hai bisogno di una chiave hardware, puoi utilizzare Cloud HSM per garantire che le chiavi simmetriche e asimmetriche siano utilizzate solo in moduli di sicurezza hardware (HSM, Hardware Security Module) convalidati di tipo FIPS 140-2 livello 3.
  • Cloud KMS consente di importare le chiavi di crittografia nel caso in cui tu debba utilizzare quelle che hai generato personalmente.
  • 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 utilizzate per proteggere i dati in altri servizi Google Cloud.
  • Con Cloud External Key Manager (Cloud EKM) puoi creare e gestire le chiavi in uno strumento esterno a Google Cloud, per poi configurare la piattaforma Cloud KMS in modo che utilizzi le chiavi esterne per proteggere i dati inattivi. Puoi utilizzare chiavi di crittografia gestite dal cliente con una chiave Cloud EKM. Al momento, Cloud EKM non rientra nell'ambito di questo white paper.

Google supporta anche le chiavi di crittografia fornite dal cliente (CSEK) per Compute Engine e Cloud Storage, che permettono di decriptare e criptare i dati mediante una chiave fornita nella chiamata API. Le chiavi CSEK non rientrano nell'ambito di questo white paper. Per ulteriori informazioni, consulta la documentazione online.

"Diagramma del portafoglio 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 su una piattaforma di semplice utilizzo. Cloud KMS si basa su cinque elementi di progettazione fondamentali:

  • Controllo da parte dei clienti. Cloud KMS consente di gestire le chiavi di crittografia software e hardware o di fornire chiavi personalizzate.
  • Controllo e monitoraggio dell'accesso. Con Cloud KMS puoi gestire le autorizzazioni per le singole chiavi e monitorarne l'utilizzo.
  • Aree geografiche. Cloud KMS incorpora la regionalizzazione. Il servizio è configurato per creare, archiviare ed elaborare le chiavi software solo nell'area geografica di Google Cloud che selezioni.
  • Durabilità. Cloud KMS soddisfa gli standard di durabilità più elevati su Google Cloud. 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 misure di protezione efficaci per evitare l'accesso non autorizzato alle chiavi ed è completamente integrato con i controlli di Identity and Access Management (IAM) e degli audit log di Cloud.

Questo documento descrive i meccanismi di base della piattaforma Cloud KMS all'interno della release disponibile pubblicamente (GA, General Availability). Queste opzioni consentono di proteggere le chiavi e altri dati sensibili archiviati in Google Cloud. Questo white paper è destinato ai responsabili delle decisioni tecniche che hanno bisogno 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.

2. Concetti di crittografia e gestione delle chiavi in Google

Questa sezione specifica alcuni dei termini e definizioni per la gestione delle chiavi nel contesto dell'infrastruttura di gestione delle chiavi multilivello di Google.

2.1. Chiavi, versioni delle chiavi e keyring

Questa sezione descrive le chiavi, le versioni delle chiavi e il raggruppamento delle chiavi in keyring. Il diagramma seguente descrive i raggruppamenti di chiavi. Le definizioni correlate seguono il diagramma.

"Diagramma dei raggruppamenti di chiavi".

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

    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 la crittografia simmetrica al fine di proteggere un corpus di dati, ad esempio mediante una chiave AES-256 in modalità GCM per criptare un blocco di testo non crittografato. Una chiave asimmetrica può essere utilizzata per la crittografia asimmetrica o per creare firme digitali. Gli scopi e gli algoritmi supportati sono descritti nella documentazione di Cloud KMS.

  • 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 IAM dal keyring che le contiene. Il raggruppamento di chiavi con autorizzazioni correlate in un keyring consente di concedere, revocare o modificare le autorizzazioni per tali chiavi a livello di keyring senza dover agire singolarmente su ogni chiave. I keyring offrono convenienza e categorizzazione, ma se il loro raggruppamento non è utile per i tuoi scopi, puoi gestire le autorizzazioni direttamente nelle chiavi.

    Per evitare conflitti per i nomi delle risorse, non è possibile eliminare un keyring. 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. Per ulteriori dettagli su come eliminare le chiavi e i rispettivi materiali, consulta la sezione sull'eliminazione più avanti in questo documento.

  • Metadati delle chiavi: includono nomi di risorse, proprietà delle risorse KMS (ad esempio criteri IAM, oltre a tipo, dimensione e stato della chiave) e qualsiasi dato derivato da questi elementi. I metadati della chiave possono essere gestiti in modo diverso rispetto al materiale della chiave.

  • Versione della chiave: rappresenta 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, così da limitare l'utilizzo di ogni singola versione. Le chiavi simmetriche avranno sempre una versione principale che viene utilizzata per la crittografia per impostazione predefinita. Quando Cloud KMS esegue la decriptazione mediante chiavi simmetriche, identifica automaticamente la versione della chiave necessaria per l'operazione.

2.2. Gerarchia delle chiavi

Il seguente diagramma illustra la gerarchia delle chiavi del sistema Key Management Service interno di Google. Cloud KMS utilizza il KMS interno di Google per le chiavi criptate da Cloud KMS, che vengono sottoposte a wrapping da Google KMS. Cloud KMS utilizza la stessa radice di attendibilità di Google KMS. Le definizioni correlate seguono il diagramma.

"Diagramma della gerarchia delle chiavi del KMS interno"

  • Chiave di crittografia dei dati (DEK): una chiave utilizzata per criptare i dati.
  • Chiave di crittografia della chiave (KEK): una chiave utilizzata per criptare o sottoporre a wrapping una chiave di crittografia dei dati. Tutte le opzioni della piattaforma Cloud KMS (software, hardware e backend esterni) consentono di controllare la chiave di crittografia della chiave.
  • Chiave master KMS: la chiave utilizzata per criptare le chiavi di crittografia della chiave (KEK). Questa chiave viene distribuita in memoria. La chiave master del KMS viene sottoposta a backup sui dispositivi hardware. Questa chiave è responsabile della crittografia delle chiavi.
  • KMS radice: è il KMS interno di Google.

2.3. Suite operativa

  • Progetto: le risorse di Cloud KMS appartengono a un progetto Google Cloud, proprio come tutte le altre risorse di Google Cloud. Puoi ospitare dati in un progetto diverso da quello in cui si trovano le chiavi Cloud KMS. Questa funzionalità supporta la best practice di separazione dei compiti tra gli amministratori delle chiavi e quelli dei dati.
  • Località: all'interno di un progetto, le risorse di Cloud KMS vengono create in una località. Per ulteriori informazioni, consulta Geografia e aree geografiche.

3. 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 sia hardware che 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.

"Diagramma dell'architettura di Cloud KMS".

Il diagramma precedente mostra i componenti principali della piattaforma Cloud KMS. Gli amministratori accedono ai servizi di gestione delle chiavi utilizzando Google Cloud Console o lo strumento a riga di comando gcloud oppure tramite applicazioni che implementano le API REST o gRPC. Le applicazioni accedono ai servizi di gestione delle chiavi utilizzando un'API REST o gRPC. Le applicazioni possono utilizzare i servizi Google abilitati per l'utilizzo delle chiavi di crittografia gestite dal cliente (CMEK). A loro volta, le chiavi CMEK utilizzano l'API Cloud KMS. L'API Cloud KMS consente di utilizzare chiavi software (Cloud KMS) o hardware (Cloud HSM). Sia le chiavi basate su software che quelle basate su hardware sfruttano le funzionalità di protezione offerte dal backup ridondante di Google.

Con la piattaforma Cloud KMS, puoi scegliere un livello di protezione durante la creazione di una chiave per determinare quale backend di chiavi crea la chiave ed esegue tutte le future operazioni di crittografia sulla chiave in questione. La piattaforma Cloud KMS fornisce due backend (tranne Cloud EKM), esposti nell'API Cloud KMS come livelli di protezione SOFTWARE e HSM. Il livello di protezione SOFTWARE si applica alle chiavi il cui wrapping potrebbe venire annullato da un modulo di sicurezza software per eseguire operazioni di crittografia. Il livello di protezione HSM si applica alle chiavi il cui wrapping potrebbe venire annullato solo da moduli di sicurezza hardware che eseguono tutte le operazioni di crittografia con le chiavi.

Google Cloud supporta CMEK per numerosi servizi, tra cui Cloud Storage, BigQuery e Compute Engine. La funzionalità CMEK consente di utilizzare la piattaforma Cloud KMS per gestire le chiavi di crittografia utilizzate da questi servizi per proteggere i dati.

Le operazioni di crittografia di Cloud KMS vengono eseguite dai 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. Le chiavi con livello di protezione HSM e le operazioni di crittografia che eseguono sono conformi allo standard FIPS 140-2 livello 3.

3.1. Ambiente e dipendenze

Questa sezione fornisce dettagli sull'infrastruttura di Google in cui viene eseguita la piattaforma Cloud KMS, nonché sui protocolli di comunicazione utilizzati dall'infrastruttura.

3.1.1. Job Borg di Cloud KMS

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 i dettagli sulla sicurezza della nostra infrastruttura fisica e di produzione, consulta la panoramica sulla progettazione della sicurezza dell'infrastruttura Google.

3.1.1.1. 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. Questi job di servizio vengono eseguiti in tutte le aree geografiche di Google Cloud in cui è disponibile Cloud KMS. Ogni job è associato a una singola area geografica ed è configurato in modo da accedere ai dati solo da sistemi che si trovano nell'area geografica di Google Cloud associata. Per ulteriori informazioni sulla localizzazione delle chiavi, consulta la sezione Aree geografiche più avanti in questo documento.

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

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

Per mantenere l'alta disponibilità, la piattaforma Cloud KMS gestisce un datastore ridondante in ogni istanza di un servizio condiviso che ospita le attività server dell'API Cloud KMS. Ogni servizio 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. L'API Cloud KMS utilizzerà quindi il job che completa per primo la richiesta. Per evitare un ritardo nella pipeline di snapshot, con il conseguente recupero di dati troppo obsoleti, il server API non utilizza i risultati dei job del servizio di snapshot se sono passate 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.

3.1.2. Comunicazioni client-server

Google utilizza Application Layer Transport Security (ALTS) per proteggere le comunicazioni client-server (crittografia in transito) che utilizzano il meccanismo di chiamata di procedura remota (RPC, Remote Procedure Call) di Google. ALTS fornisce quanto segue:

  • Un protocollo di autenticazione peer-to-peer per le applicazioni
  • Un protocollo di registrazione della crittografia
  • Un'API che espone l'utente autenticato per l'autorizzazione

I protocolli di handshake e registrazione della crittografia di ALTS sono simili a quelli per handshake e registrazione di TLS (Transport Layer Security). ALTS applica varianti diverse per ottimizzare l'ambiente di produzione di Google ed è completamente integrato nell'intero stack hardware e software di produzione. Per ulteriori dettagli, consulta la sezione Ambiente operativo della piattaforma Cloud KMS più avanti in questo documento.

4. Dettagli dell'architettura della piattaforma Cloud KMS

Questa sezione approfondisce i dettagli dell'architettura a partire dalla sicurezza del materiale delle chiavi e dalla protezione del datastore, per poi descrivere in dettaglio le opzioni per l'origine del materiale delle chiavi.

Questa sezione descrive anche le opzioni per le chiavi di crittografia gestite dal cliente (CMEK).

Per offrire una panoramica dinamica dell'utilizzo delle strutture architettoniche introdotte finora, questo white paper descrive il ciclo di vita di una richiesta Cloud KMS, compresa un'analisi dell'eliminazione del materiale delle chiavi.

4.1. Sicurezza dei materiali delle chiavi

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

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

Le richieste dei clienti a Cloud KMS vengono criptate in transito mediante TLS tra il cliente e Google Front End (GFE). Application Layer Transport Security (ALTS), descritto in precedenza nella sezione sulle comunicazioni client-server, viene utilizzato per la crittografia tra i job di Cloud KMS e i relativi backend in diversi data center. ALTS e la crittografia dei dati in transito sono descritti più in dettaglio nella sezione Ciclo di vita di una richiesta Cloud KMS più avanti in questo documento.

L'autenticazione avviene tra tutti i job 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 e viene descritta in dettaglio in questo documento sulla sicurezza.

I job dell'API Cloud KMS possono accedere ai metadati delle chiavi, ad esempio il criterio IAM 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. Gli accessi vengono registrati internamente. Inoltre, i clienti qualificati possono visualizzare i log relativi ai dati coperti da Access Transparency.

Tuttavia, i job dell'API Cloud KMS non possono accedere al materiale delle chiavi, che a sua volta 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. Il materiale delle chiavi viene inoltre criptato con una chiave master nel KMS radice, a cui nessuno può accedere direttamente.

4.2. Protezione del datastore

Questa sezione descrive in che modo Google KMS protegge i dati delle chiavi.

4.2.1. Chiavi master

Cloud KMS utilizza una chiave master per eseguire il wrapping di tutte le chiavi inattive dei clienti. Ciascun server Cloud KMS recupera una copia della chiave master in fase di avvio come dipendenza rigida e recupera ogni giorno una nuova copia della chiave master, che viene criptata di nuovo periodicamente.

4.2.2. 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 KMS interno di Google che esegue il wrapping delle chiavi di Cloud KMS. La chiave master del KMS 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 nelle attività KMS ogni 24 ore e cripta di nuovo tutte le chiavi del cliente su base mensile.

4.2.3. Localizzazione 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. Per ulteriori dettagli sulla localizzazione dei dati, consulta la sezione Aree geografiche più avanti in questo documento.

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

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

4.4.1. Implementazioni algoritmiche

Per le chiavi software, Cloud KMS utilizza il modulo BoringCrypto (BCM) all'interno dell'implementazione BoringSSL di Google per tutte le operazioni di crittografia correlate. Il BCM è convalidato secondo lo standard FIPS 140-2. Il dati binari di Cloud KMS sono creati sulla base delle primitive crittografiche di questo modulo, convalidate secondo lo standard FIPS 140-2 livello 1. Gli algoritmi più recenti coperti da questo modulo sono elencati nella nostra pagina della documentazione 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.

4.4.2. 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_byte, 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.

4.5. Backend HSM di Cloud KMS: livello di protezione HARDWARE

Il servizio Cloud HSM fornisce chiavi hardware a Cloud KMS. Offre ai clienti la possibilità di gestire e utilizzare chiavi di crittografia protette da moduli di sicurezza hardware (HSM, Hardware Security Module) completamente gestiti nei data center Google. Il servizio è a disponibilità elevata e viene scalato automaticamente in orizzontale. Le chiavi sono associate in modo crittografico all'area geografica del KMS in cui è stato definito il keyring. Con Cloud HSM, il materiale delle chiavi che crei e utilizzi non può essere generato al di fuori del cluster di moduli HSM appartenenti all'area geografica specificata al momento della creazione della chiave. L'uso di Cloud HSM ti consente di attestare in modo verificabile che le chiavi di crittografia siano state create e vengano utilizzate solo all'interno di un dispositivo hardware. I clienti Cloud KMS esistenti non devono apportare alcuna modifica alle applicazioni al fine di utilizzare Cloud HSM. L'accesso ai servizi Cloud HSM viene eseguito utilizzando la medesima API e le stesse librerie client del backend software di Cloud KMS.

Cloud HSM utilizza moduli HSM convalidati secondo lo standard FIPS 140-2 livello 3 e che vengono eseguiti sempre in modalità FIPS. Lo standard FIPS specifica gli algoritmi crittografici e la modalità di generazione di numeri casuali utilizzati dai moduli HSM.

4.5.1. HSM Cavium

Il fornitore garantisce che la scheda PCIe per i moduli HSM Cavium è compatibile con FIPS 140-2 di livello 3. Il certificato corrente è disponibile su richiesta.

4.5.2. Gerarchia delle chiavi HSM

Nel seguente diagramma, Cloud KMS si trova nella metà superiore. Cloud HSM esegue il wrapping delle chiavi dei clienti, quindi Cloud KMS esegue il wrapping delle chiavi HSM trasmesse al datastore di Google.

"Diagramma della gerarchia delle chiavi HSM"

Cloud HSM dispone di una chiave (non mostrata) che controlla la migrazione del materiale all'interno del dominio amministrativo di Cloud HSM. Un'area geografica potrebbe avere più domini amministrativi HSM.

La chiave radice HSM ha due caratteristiche:

  1. È generata in un modulo HSM e durante il suo ciclo di vita non lascia mai i limiti ben definiti dei moduli HSM. Potrebbe essere replicata su altri moduli HSM o sui moduli HSM di backup.
  2. Può essere utilizzata come chiave di crittografia della chiave per eseguire direttamente o indirettamente il wrapping delle chiavi dei clienti utilizzate dai moduli HSM.

Le chiavi dei clienti sottoposte a wrapping dalle chiavi radice HSM possono essere utilizzate nel modulo HSM, ma questo non restituisce mai il testo non crittografato della chiave del cliente. Il modulo HSM utilizza la chiave del cliente solo per le operazioni.

4.5.3. Protezione del datastore

I moduli HSM non vengono utilizzati come archiviazione permanente per le chiavi, ma le archiviano solo mentre vengono utilizzate. Poiché l'archiviazione HSM è vincolata, le chiavi HSM sono criptate e archiviate nel datastore delle chiavi di Cloud KMS. Questo argomento è descritto in dettaglio nella sezione Backend del datastore più avanti in questo documento.

4.5.4. Criterio di rotazione

La strategia di protezione delle chiavi di Cloud HSM prevede l'uso di diversi tipi di chiavi. I clienti ruotano le proprie chiavi e lasciano che sia Cloud KMS a ruotare le chiavi HSM.

4.5.5. Processo di provisioning e gestione

Il provisioning dei moduli HSM viene eseguito in un laboratorio dotato di numerose misure di sicurezza sia fisica che logica, tra cui controlli delle autorizzazioni multi-parte al fine di evitare violazioni da parte di un singolo utente.

Di seguito sono riportati gli aspetti invariabili a livello di sistema per Cloud HSM:

  1. Le chiavi dei clienti non possono essere estratte come testo non crittografato.
  2. Le chiavi dei clienti non possono essere spostate al di fuori dell'area geografica di origine.
  3. Tutte le modifiche alla configurazione dei moduli HSM di cui è stato eseguito il provisioning sono protette da varie misure di sicurezza.
  4. Le operazioni amministrative vengono registrate secondo il criterio di separazione dei compiti tra gli amministratori di Cloud HSM e quelli del logging.
  5. I moduli HSM sono progettati per essere protetti da eventuali manomissioni (ad esempio tramite l'inserimento di modifiche dannose del software o hardware oppure l'estrazione non autorizzata di secret) durante il ciclo di vita operativo.

4.5.6. Firmware controllato dal fornitore

Il firmware dei moduli HSM è firmato digitalmente dal rispettivo fornitore. Google non è in grado di creare o aggiornare il firmware dei moduli HSM. Ogni tipo di firmware viene firmato dal fornitore, incluso quello di sviluppo utilizzato per i test.

4.5.7. Aree geografiche

Le chiavi dei clienti vengono assegnate a specifiche aree geografiche dopo essere state associate a una specifica chiave radice HSM. Ad esempio, una chiave creata in modo specifico nell'area geografica us-west1 non può essere trasferita nell'area geografica us-east1 o in una zona us con più aree geografiche. Allo stesso modo, una chiave creata nella zona us con più aree geografiche non può essere trasferita all'interno o all'esterno dell'area geografica us-west1.

4.6. Cloud KMS: importazione delle chiavi

Potrebbe essere necessario importare le chiavi create personalmente 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. Cloud KMS consente di importare le chiavi di crittografia create personalmente on-premise o in un sistema di gestione delle chiavi esterno. L'importazione delle chiavi consente di importarle e di rispettare gli obblighi normativi. Puoi anche importare chiavi asimmetriche per estendere le funzionalità di firma al cloud.

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

Questa chiave di wrapping pubblica di Cloud KMS viene utilizzata per criptare sul client la chiave da importare. La chiave privata che corrisponde a questa chiave pubblica viene archiviata in Google Cloud e utilizzata per annullare il wrapping della chiave 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.

Le chiavi importate possono essere utilizzate 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.

4.7. 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, i clienti possono invece utilizzare Cloud KMS per gestire le chiavi impiegate per la crittografia. La funzionalità CMEK può essere utilizzata per chiavi sia software che hardware. Cloud KMS consente ai clienti di controllare molti aspetti delle chiavi (ad esempio creazione, abilitazione/disabilitazione, rotazione ed eliminazione delle chiavi) nonché di gestire le autorizzazioni IAM appropriate. Cloud KMS include numerosi ruoli IAM predefiniti con limitazioni e privilegi specifici e che possono essere concessi a utenti e account di servizio specifici al fine di applicare il criterio consigliato di separazione dei compiti.

Gli argomenti seguenti forniscono dettagli sui prodotti integrati con la piattaforma Cloud KMS che supportano CMEK:

L'impatto della rotazione delle chiavi sulla versione della chiave utilizzata dipende dal modo in cui un prodotto implementa le chiavi CMEK. In generale, la rotazione della chiave Cloud KMS non cripta nuovamente i dati nel servizio CMEK associato. 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.

Consulta questa documentazione per l'elenco completo dei servizi che offrono l'integrazione CMEK e che sono conformi alla funzionalità CMEK. Google continua a investire nell'integrazione CMEK per altri prodotti Google Cloud.

4.8. Ciclo di vita di una richiesta Cloud KMS

Per offrire una panoramica dinamica dell'utilizzo delle strutture architettoniche introdotte finora, questa sezione descrive il ciclo di vita di una richiesta Cloud KMS, compresa un'analisi dell'eliminazione del materiale delle chiavi.

"Diagramma del ciclo di vita di una richiesta KMS"

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 Google Front End (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 gestiscono la negoziazione TLS e utilizzano i parametri e l'URL della richiesta per determinare quale bilanciatore del carico software globale la inoltra.
  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 Google Cloud è 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 verrà rifiutata dai Controlli di servizio VPC.
  5. Dopo aver superato questi controlli, il framework inoltra la richiesta e la credenziale a Cloud KMS. Cloud KMS analizza la richiesta per determinare le risorse alle quali viene eseguito l'accesso, quindi utilizza IAM per verificare se il chiamante è autorizzato a effettuare la richiesta. 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 esegue una chiamata ai backend del datastore dell'area geografica per recuperare la risorsa richiesta. Una volta recuperata, 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 o a Cloud HSM, 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.

4.9. Eliminazione del materiale delle chiavi

L'eliminazione dei dati su Google Cloud è descritta in questo white paper. Il materiale delle chiavi fa parte dei dati del cliente, pertanto l'approccio descritto nel white paper riguarda Cloud KMS. Inoltre, poiché Google non lo condivide mai al di fuori di Cloud KMS, il materiale delle chiavi viene eliminato su richiesta al termine del periodo di eliminazione in attesa di 24 ore e quando scadono i backup. Questo processo non è garantito per le copie di chiavi importate esistenti al di fuori del controllo di Cloud KMS.

Sebbene il materiale delle chiavi venga eliminato come descritto in precedenza, 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. L'utente ha a disposizione un periodo di 24 ore per ripristinare la versione della chiave in modo che non venga eliminata.

5. 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. Quanto riportato di seguito riguarda le funzionalità delle chiavi sia software che hardware.

5.1. 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, in ultima analisi, 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.

5.2. Aree geografiche delle risorse Cloud KMS

Puoi creare risorse di Cloud KMS in uno dei seguenti quattro tipi di località Google Cloud:

  • Località a singola area geografica. Una località a singola area geografica è composta da zone in un'area geografica specifica, ad esempio l'Iowa.
  • Località a due aree geografiche. Una località a due aree geografiche è composta da zone in due aree geografiche specifiche, ad esempio Iowa e Carolina del Sud.
  • Località a più aree geografiche. Una località a più aree geografiche è composta da zone distribuite in un territorio più ampio, ad esempio gli Stati Uniti.
  • Località globale. 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 documentazione di Cloud KMS.

5.2.1. 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 al riguardo, consulta l'articolo sulle località di 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/o 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.

5.2.2. Aree geografiche

Alcuni settori richiedono che le chiavi crittografiche si trovino in una località specifica. Come spiegato in precedenza 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ù aree geografiche non lascia i confini delle località selezionate.

Per l'area geografica globale, non è specificata alcuna garanzia geografica.

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 a prescindere dalle località personalizzate con due o più aree geografiche scelte in altri prodotti Google Cloud che vuoi utilizzare con le chiavi CMEK:

  • Per un'area geografica specifica: poiché l'area geografica di una chiave KMS gestita dal cliente deve sempre essere correlata all'area geografica della risorsa che protegge in un determinato servizio di Google Cloud, vengono applicate e garantite come compatibili alcune limitazioni relative alla localizzazione per le chiavi e le risorse di una singola area geografica.
  • Per località con due o più aree geografiche: gli utenti possono scegliere località con più aree geografiche 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 aree geografiche 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.

Localizzazione dei dati Cloud KMS Inattivi, in uso
(singola area geografica)
Inattivi, in uso
(due o più aree geografiche)
Materiale delle chiavi software Residente Residente nelle aree geografiche che fanno parte della località con due o più aree geografiche.
Materiale della chiavi hardware (HSM) Residente Residente nelle aree geografiche che fanno parte della località con due o più aree geografiche.

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

5.3. 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 il cliente ha attivato l'API Cloud KMS e dispone di un account di fatturazione attivo.
  • Controllo per verificare che il cliente non abbia superato la quota e generazione di rapporti sull'utilizzo della quota.
  • Applicazione dei Controlli di servizio VPC.
  • Controllo per verificare se il cliente è compreso nella lista consentita per le aree geografiche Cloud private pertinenti.

5.4. Logging

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

5.4.1. Audit log di Cloud

Cloud KMS registra l'attività dei clienti negli audit log di Cloud. I clienti possono visualizzare questi log in Cloud Console. Tutte le attività di amministrazione, ad esempio la creazione o l'eliminazione di una chiave, vengono registrate nei log. I clienti possono 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. I clienti stabiliscono per quanto tempo conservare i log e chi può visualizzarli.

5.4.2. Log di trasparenza degli accessi

I clienti idonei possono scegliere facoltativamente di abilitare i log di Access Transparency, che contengono le azioni che i dipendenti Google eseguono nell'organizzazione Google Cloud. I log di Access Transparency, insieme agli audit log di Cloud, sono utili per capire chi ha effettuato un'operazione, di cosa si trattava, dove e quando è stata eseguita.

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

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

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

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

5.5. Backend 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 parecchie ore 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 su nastro.

Il team di Cloud KMS si avvale di procedure documentate per ripristinare i backup in caso di emergenza.

Localizzazione. 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 dei clienti viene criptato prima di essere archiviato. I tecnici del datastore non possono accedere al materiale delle chiavi dei clienti in testo non crittografato. Inoltre, il datastore cripta tutti i dati che gestisce prima di scriverli nell'archiviazione permanente. Di conseguenza, l'accesso ai livelli di archiviazione sottostanti, inclusi dischi o supporti a nastro, non consentirà di accedere neppure ai dati criptati di Cloud KMS senza accedere alle chiavi di crittografia del datastore, che sono archiviate nel KMS interno di Google.

6. Per approfondire

Per ulteriori informazioni, consulta le seguenti risorse:

White paper:

Altra documentazione: