Crittografia at-rest predefinita

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questi contenuti sono stati aggiornati l'ultima volta a settembre 2022 e rappresentano lo status quo al momento in cui sono stati scritti. D'ora in poi, i criteri e i sistemi di sicurezza di Google potranno cambiare, in quanto continueremo a migliorare la protezione dei nostri clienti.

In Google, la nostra strategia di sicurezza completa include la crittografia dei dati inattivi, che aiuta a proteggere i contenuti dei clienti da utenti malintenzionati. Criptiamo tutti i contenuti inattivi dei clienti Google, senza che tu debba fare nulla, utilizzando uno o più meccanismi di crittografia. Questo documento descrive il nostro approccio alla crittografia at-rest predefinita per l'infrastruttura di Google e Google Cloud e il modo in cui li utilizziamo per mantenere più sicure le informazioni dei clienti.

Questo documento è rivolto agli architetti della sicurezza e ai team per la sicurezza che attualmente utilizzano o stanno prendendo in considerazione Google. Questo documento presuppone una conoscenza di base di crittografia e primitive crittografiche. Per ulteriori informazioni sulla crittografia, consulta Introduzione alla crittografia moderna.

La crittografia at-rest è la crittografia utilizzata per proteggere i dati archiviati su un disco (incluse le unità a stato solido) o i supporti di backup. Tutti i dati archiviati da Google vengono criptati a livello di archiviazione con l'algoritmo Advanced Encryption Standard (AES-AES, AES-256). Utilizziamo una libreria crittografica comune, Tink, che include il nostro modulo convalidato FIPS 140-2 (denominato BoringCrypto) per implementare la crittografia in modo coerente su Google Cloud.

Gestiamo le chiavi utilizzate nella crittografia at-rest predefinita. Se utilizzi Google Cloud, Cloud Key Management Service ti consente di creare le tue chiavi di crittografia che puoi utilizzare per aggiungere la crittografia della busta ai dati. Con Cloud KMS, puoi creare, ruotare, tenere traccia ed eliminare le chiavi. Per ulteriori informazioni, consulta l'approfondimento su Cloud Key Management Service.

In che modo la crittografia at-rest aiuta a proteggere i dati

La crittografia dei dati inattivi è un elemento di una strategia di sicurezza più ampia. La crittografia offre i seguenti vantaggi:

  • Contribuisce a garantire che se i dati rientrano nelle mani di un utente malintenzionato, l'attacco non può leggere i dati senza anche accedere alle chiavi di crittografia. Anche se gli utenti malintenzionati ottengono i dispositivi di archiviazione che contengono i dati dei clienti, non saranno in grado di comprenderli o decriptarli.
  • Contribuisce a ridurre la superficie di attacco tagliando i livelli inferiori dello stack hardware e software.
  • Funziona come un punto di passaggio singolo perché le chiavi di crittografia gestite centralmente creano un'unica posizione in cui viene applicato l'accesso ai dati e possono essere controllati.
  • Contribuisce a ridurre la superficie di attacco perché anziché dover proteggere tutti i dati, le aziende possono concentrare le loro strategie di protezione sulle chiavi di crittografia.
  • Fornisce un meccanismo di privacy importante ai nostri clienti. Quando i dati at-rest sono criptati, limitano l'accesso ai dati da parte di sistemi e tecnici

Che cosa sono i dati dei clienti?

Come definiti nei Termini di servizio di Google Cloud, i dati dei clienti sono dati che i clienti o gli utenti finali forniscono a Google tramite i servizi collegati all'account. I dati dei clienti includono i contenuti e i metadati dei clienti.

I contenuti dei clienti sono dati generati da te o che ci fornisci, come i dati archiviati in Cloud Storage, gli snapshot dei dischi utilizzati da Compute Engine e i criteri IAM. Questo documento è incentrato sulla crittografia at-rest predefinita per i contenuti dei clienti.

I metadati dei clienti costituiscono il resto dei dati. I metadati dei clienti potrebbero includere numeri di progetto generati automaticamente, timestamp, indirizzi IP, dimensioni dei byte di un oggetto in Cloud Storage o tipo di macchina in Compute Engine. I metadati sono protetti in misura ragionevole per le prestazioni e le operazioni in corso.

Crittografia predefinita dei dati at-rest

Google cripta tutti i contenuti inattivi inattivi dei clienti archiviati, senza che tu debba fare nulla, utilizzando uno o più meccanismi di crittografia. Le seguenti sezioni descrivono i meccanismi che utilizziamo per criptare i contenuti dei clienti.

Livelli di crittografia

Google utilizza diversi livelli di crittografia per proteggere i dati. L'utilizzo di più livelli di crittografia aggiunge una protezione dei dati ridondante e ci consente di selezionare l'approccio ottimale in base ai requisiti delle applicazioni.

Il seguente diagramma mostra i diversi livelli di crittografia generalmente utilizzati per proteggere i dati utente nei data center di produzione di Google. Viene applicata la crittografia distribuita del file system o la crittografia del database e dell'archiviazione di file per tutti i dati utente, mentre per tutti i dati nei data center di produzione di Google è attiva la crittografia dei dispositivi di archiviazione.

Diversi livelli di crittografia.

Crittografia a livello di hardware e infrastruttura

Tutti i sistemi di archiviazione di Google utilizzano un'architettura di crittografia simile, anche se i dettagli di implementazione variano da sistema a sistema. I dati sono suddivisi in blocchi di sottofile per l'archiviazione; ogni blocco può avere dimensioni massime di diversi gigabyte. Ogni blocco viene criptato a livello di archiviazione con una chiave di crittografia dei dati individuale (DEK): due blocchi non avranno la stessa chiave DEK, anche se sono di proprietà dello stesso cliente o archiviati sulla stessa macchina. Un blocco di dati in Datastore, App Engine e Pub/Sub può contenere i dati di più clienti.

Un blocco di dati aggiornato viene criptato con una nuova chiave, anziché riutilizzarla. Questa partizione dei dati, ciascuna utilizzando una chiave diversa, limita il rischio di una potenziale compromissione della chiave di crittografia dei dati solo a tale blocco di dati.

Google cripta i dati prima che siano scritti su un sistema di archiviazione di database o su un disco hardware. La crittografia è integrata in tutti i nostri sistemi di archiviazione e non viene aggiunta in seguito.

Ogni blocco di dati ha un identificatore univoco. Gli elenchi di controllo di accesso (ACL) contribuiscono ad assicurare che ogni blocco possa essere decriptato solo dai servizi Google che operano con ruoli autorizzati, ai quali viene concesso l'accesso solo in quel momento. Questa limitazione di accesso contribuisce a impedire l'accesso ai dati senza autorizzazione, rafforzando la sicurezza e la privacy dei dati.

Ogni blocco viene distribuito sui nostri sistemi di archiviazione e viene replicato in forma criptata per il backup e il ripristino di emergenza. Un utente malintenzionato che vuole accedere ai dati dei clienti deve conoscere ed essere in grado di accedere a due cose: tutti i blocchi di archiviazione che corrispondono ai dati che vogliono e tutte le chiavi di crittografia che corrispondono ai blocchi.

Il diagramma seguente mostra come i dati vengono caricati nella nostra infrastruttura e quindi suddivisi in blocchi criptati per l'archiviazione.

Come vengono caricati i dati.

Utilizziamo l'algoritmo AES per criptare i dati at-rest. Tutti i dati a livello di archiviazione vengono criptati dalle DEK, che utilizzano AES-256 per impostazione predefinita, ad eccezione di un numero limitato di dischi permanenti creati prima del 2015 che utilizzano AES-128. AES è ampiamente utilizzato perché sia AES-256 che AES-128 sono consigliati dal National Institute of Standards and Technology (NIST) per l'utilizzo dello spazio di archiviazione a lungo termine e AES è spesso incluso nei requisiti di conformità dei clienti.

Crittografia a livello di dispositivo di archiviazione

Oltre alla crittografia a livello di sistema di archiviazione, i dati vengono criptati anche a livello di dispositivo di archiviazione con AES-256 per unità disco rigido (HDD) e unità a stato solido (SSD), utilizzando una chiave separata a livello di dispositivo (diversa dalla chiave utilizzata per criptare i dati a livello di archiviazione). Un numero limitato di HDD legacy utilizza AES-128. Le unità SSD utilizzate da Google implementano l'algoritmo AES-256 esclusivamente per i dati utente.

Crittografia dei backup

Il nostro sistema di backup assicura che i dati rimangano criptati durante il processo di backup. Questo approccio evita esposizioni non necessarie dei dati del testo non crittografato.

Inoltre, il sistema di backup cripta ulteriormente la maggior parte dei file di backup in modo indipendente utilizzando la propria DEK. La chiave DEK deriva da una chiave archiviata nell'archivio chiavi e un seed per file generato casualmente al momento del backup. Nei backup viene utilizzata un'altra DEK per tutti i metadati, che sono anche memorizzati in Keystore.

Conformità FIPS per dati inattivi

Google utilizza un modulo di crittografia convalidato FIPS 140-2 (certificato 3318) nel nostro ambiente di produzione.

Gestione delle chiavi

A causa dell'elevato volume di chiavi utilizzate da Google e della necessità di mantenere una bassa latenza e un'alta disponibilità, le DEK sono archiviate vicino ai dati che devono criptare. Le DEK sono a loro volta criptate con una chiave di crittografia delle chiavi (KKK), utilizzando una tecnica nota come crittografia delle buste. Queste KEK non sono specifiche per i clienti, ma ne esistono una o più per ogni servizio.

Queste KEK sono archiviate a livello centrale in Keystore, un repository creato appositamente per l'archiviazione delle chiavi. La presenza di un numero inferiore di KEK rispetto alle DEK e l'uso di un Keystore centrale rendono l'archiviazione e la crittografia dei dati su larga scala gestibili e ci consentono di monitorare e controllare l'accesso ai dati da un punto centrale.

In Google Cloud, ogni cliente può avere risorse condivise e non condivise. Un esempio di risorsa condivisa è un'immagine di base condivisa in Compute Engine. Per le risorse condivise, più clienti fanno riferimento a una singola copia, criptata da una singola DEK. Le risorse non condivise sono suddivise in blocchi di dati e criptate con chiavi separate da quelle utilizzate per gli altri clienti. Queste chiavi sono addirittura separate da quelle che proteggono altri elementi degli stessi dati di proprietà dello stesso cliente. Le eccezioni sono dati archiviati in Datastore, App Engine o Pub/Sub, dove più dati di un cliente potrebbero essere criptati con la stessa DEK.

Generazione di DEK

Il sistema di archiviazione genera le DEK utilizzando la libreria crittografica comune di Google. In generale, le DEK vengono quindi inviate a Keystore per essere aggregate con la KEK del sistema di archiviazione e vengono nuovamente trasferite al sistema di archiviazione per essere conservate insieme ai blocchi di dati. Quando un sistema di archiviazione ha bisogno di recuperare i dati criptati, recupera la DEK aggregata e la passa a Keystore. Keystore verifica quindi che questo servizio sia autorizzato a utilizzare la KEK e, in caso affermativo, ne annulla il wrapping e restituisce al servizio la DEK in testo non crittografato. Il servizio utilizza quindi la DEK per decriptare il blocco di dati in testo normale e verificarne l'integrità.

Tutti i sistemi di archiviazione di Google Cloud rispettano questo modello di gestione delle chiavi, ma la maggior parte dei sistemi implementa anche livelli aggiuntivi di KEK lato archiviazione per creare una gerarchia di chiavi. Ciò consente ai sistemi di fornire bassa latenza utilizzando la chiave KEK di livello più alto (memorizzata in Keystore) come radice di attendibilità.

Generazione di KEK in corso...

La maggior parte delle KEK per la crittografia dei blocchi di dati viene generata all'interno dell'archivio chiavi, mentre le altre vengono generate all'interno dei servizi di archiviazione. Per coerenza, tutte le KEK vengono generate utilizzando la libreria crittografica comune di Google, utilizzando un generatore di numeri casuali (RNG) creato da Google. Questo RNG si basa su NIST 800-90Ar1 CTR-DRBG e genera un AES-256 KEK. In passato il codice era AES-128 e alcune di queste chiavi rimangono attive per la decriptazione dei dati.

Il RNG è derivato dalle istruzioni RDRAND di Intel e dall'RNG del kernel Linux. A sua volta, l'RNG del kernel Linux è derivato da più origini entropiche indipendenti, tra cui eventi RDRAND ed entropici dell'ambiente del data center (ad esempio, misurazioni granulari delle ricerche di dischi e dei tempi di arrivo tra pacchetti).

Le DEK sono aggregate con KEK utilizzando AES-256 o AES-128, a seconda del servizio Google Cloud. Attualmente stiamo lavorando all'upgrade di tutte le KEK per i servizi Google Cloud ad AES-256.

Gestione KEK

Keystore è stato creato esclusivamente per la gestione delle KEK. Per impostazione predefinita, le KEK utilizzate dai sistemi di archiviazione non possono essere esportate da Keystore; tutta la crittografia e la decriptazione con queste chiavi devono essere eseguite all'interno di Keystore. Ciò consente di evitare perdite e usi impropri e consente a Keystore di creare un audit trail quando le chiavi vengono utilizzate.

L'archivio chiavi può ruotare automaticamente le KEK a intervalli di tempo regolari, utilizzando la libreria crittografica comune di Google per generare nuove chiavi. Anche se spesso facciamo riferimento a una singola chiave, in realtà intendiamo dire che i dati sono protetti usando un set di chiavi: una chiave è attiva per la crittografia, mentre un set di chiavi storiche è attivo per la decriptazione. Il numero di chiavi storiche è determinato dalla pianificazione di rotazione delle chiavi. Le KEK sono supportate a scopo di ripristino di emergenza e sono definitivamente recuperabili.

L'utilizzo di KEK è gestito dagli ACL in Keystore per ogni chiave, con un criterio per chiave. Solo gli utenti e i servizi Google autorizzati possono accedere a una chiave. L'utilizzo di ogni chiave viene monitorato a livello della singola operazione che richiede la chiave, quindi ogni volta che un utente utilizza una chiave viene autenticato e registrato. L'accesso ai dati da parte degli utenti è verificabile nell'ambito delle norme generali sulla sicurezza e sulla privacy di Google.

Procedura per l'accesso a blocchi di dati criptati

Quando un servizio Google accede a un blocco di dati criptato, si verifica quanto segue:

  1. Il servizio effettua una chiamata al sistema di archiviazione per ottenere i dati necessari.
  2. Il sistema di archiviazione identifica i blocchi in cui sono archiviati i dati (gli ID blocco) e la posizione in cui sono archiviati.
  3. Per ogni blocco, il sistema di archiviazione estrae la DEK aggregata che è archiviata con quel blocco (in alcuni casi, questa operazione viene eseguita dal servizio) e la invia al keystore per l'annullamento del wrapping.
  4. Il sistema di archiviazione verifica che il job identificato sia autorizzato ad accedere al blocco di dati in base a un identificatore job e utilizzando l'ID blocco. Keystore verifica che il sistema di archiviazione sia autorizzato a utilizzare la KEK associata al servizio e ad annullare il wrapping di quella specifica DEK.
  5. Keystore svolge una delle seguenti operazioni:
    • Ritrasferisce la DEK decriptata al sistema di archiviazione, che decripta il blocco di dati e lo passa al servizio.
    • In alcuni rari casi, passa la DEK senza wrapping al servizio. Il sistema di archiviazione passa il blocco di dati criptato al servizio, che lo decripta e lo utilizza.

Questo processo è diverso in alcuni dispositivi di archiviazione dedicati, ad esempio i dischi SSD locali, in cui il dispositivo gestisce e protegge la DEK a livello di dispositivo.

Il processo seguente mostra la procedura. Per decriptare un blocco di dati, il servizio di archiviazione chiama Keystore per recuperare la chiave DEK senza wrapping per il blocco di dati in questione.

Processo per la crittografia di blocchi di dati.

Gerarchia delle chiavi di crittografia e radice di attendibilità

L'archivio chiavi è protetto da una chiave root denominata chiave master archivio chiavi, che esegue il wrapping di tutte le KEK in Keystore. Questa chiave master dell'archivio chiavi è AES-256 ed è archiviata a sua volta in un altro servizio di gestione delle chiavi, denominato Root Keystore. In passato la chiave master dell'archivio chiavi era AES-128 e alcune di queste chiavi rimangono attive per la decriptazione dei dati. L'archivio chiavi radice archivia un numero di chiavi molto più ridotto, circa una dozzina per regione. Per maggiore sicurezza, l'archivio chiavi radice non viene eseguito su macchine di produzione generali, ma viene eseguito solo su macchine dedicate in ogni data center di Google.

A sua volta, il keystore radice ha una propria chiave radice, denominata chiave master radice keystore, anch'essa AES-256, archiviata in un'infrastruttura peer-to-peer, denominata distributore di chiavi master del keystore radice, che replica queste chiavi a livello globale. In passato, la chiave master dell'archivio chiavi radice era AES-128 e alcune di queste chiavi rimangono attive per la decriptazione dei dati. Il distributore di chiavi master dell'archivio chiavi radice conserva solo le chiavi nella RAM delle stesse macchine dedicate di Cloud KeyStore e utilizza il logging per verificare l'utilizzo corretto. Viene eseguita un'istanza del distributore di chiavi master dell'archivio chiavi radice per ogni istanza di archivio chiavi radice.

Quando viene avviata una nuova istanza del distributore di chiavi master dell'archivio chiavi radice, viene configurata con un elenco di nomi host di istanze di distributori già in esecuzione. Le istanze del distributore possono quindi ottenere la chiave master dell'archivio chiavi radice da altre istanze in esecuzione. Ad eccezione dei meccanismi di ripristino di emergenza descritti in Disponibilità e replica globali, la chiave master dell'archivio chiavi radice esiste solo nella RAM su un numero limitato di macchine appositamente protette.

Per risolvere lo scenario in cui tutte le istanze del distributore di chiavi master dell'archivio chiavi radice in un'area geografica vengono riavviate contemporaneamente, viene eseguita anche il backup della chiave master dell'archivio chiavi radice sui dispositivi hardware protetti che sono memorizzati in casseforti fisiche in aree altamente protette in più località geograficamente distribuite. Questo backup sarebbe necessario solo se tutte le istanze del distributore in un'area geografica venissero disattivate contemporaneamente. Meno di 100 dipendenti Google possono accedere a queste casseforti.

Il seguente diagramma mostra la gerarchia delle chiavi di crittografia. La gerarchia delle chiavi di crittografia protegge un blocco di dati con una chiave DEK, aggregata con una KEK in Keystore, che a sua volta è protetta dal keystore radice e dal distributore di chiavi master del keystore radice.

La gerarchia delle chiavi di crittografia.

Riepilogo della gestione delle chiavi

Il seguente elenco riassume la gestione delle chiavi in Google:

  • I dati vengono divisi in blocchi e criptati con DEK.
  • Le DEK vengono criptate con KEK.
  • Le KEK sono archiviate in Keystore.
  • Keystore viene eseguito su più computer nei data center a livello globale.
  • Le chiavi dell'archivio chiavi vengono criptate con la chiave master dell'archivio chiavi, che è archiviata in Root Keystore.
  • L'archivio chiavi radice è molto più piccolo di Keystore e viene eseguito solo su macchine dedicate in ciascun data center.
  • Le chiavi dell'archivio chiavi radice sono aggregate con la chiave master dell'archivio chiavi radice, che è archiviata nel distributore di chiavi master dell'archivio chiavi principale.
  • Il distributore di chiavi master dell'archivio radice è un'infrastruttura peer-to-peer che viene eseguita contemporaneamente nella RAM su macchine dedicate a livello globale. Ogni macchina recupera il materiale chiave da altre istanze in esecuzione nella regione.
  • Nel caso in cui tutte le istanze del distributore in un'area geografica dovessero funzionare, una chiave master è archiviata in hardware diverso in casseforti fisiche in località Google limitate.

Replica e disponibilità a livello globale

A ogni livello, sono fondamentali l'alta disponibilità, la bassa latenza e l'accesso globale alle chiavi. Queste caratteristiche sono necessarie per poter utilizzare i servizi di gestione delle chiavi in Google.

Per questo motivo, l'archivio chiavi è a scalabilità elevata e viene replicato migliaia di volte nei nostri data center a livello globale. Viene eseguito su macchine normali nel nostro parco risorse di produzione e le istanze di Keystore vengono eseguite a livello globale per supportare le operazioni di Google. Di conseguenza, la latenza di ogni singola operazione relativa ai tasti è molto bassa.

L'archivio chiavi radice viene eseguito su diverse macchine dedicate alle operazioni di sicurezza, in ogni data center. Il distributore di chiavi master dell'archivio radice viene eseguito su queste stesse macchine, uno a uno con archivio chiavi radice. Il distributore di chiavi master dell'archivio radice fornisce un meccanismo di distribuzione che utilizza un protocollo di gossip. A intervalli di tempo fissi, ogni istanza del distributore sceglie un'altra istanza casuale con cui confrontare le chiavi e riconcilia eventuali differenze nelle versioni della chiave. Con questo modello, non esiste un nodo centrale da cui dipende tutta la nostra infrastruttura. Questo metodo di distribuzione ci consente di gestire e proteggere il materiale chiave con disponibilità elevata.

Libreria crittografica comune di Google

La libreria crittografica comune di Google è Tink, che incorpora il nostro modulo convalidato FIPS 140-2, BoringCrypto. Tink è disponibile per tutti gli sviluppatori di Google. L'uso coerente di una libreria comune significa che solo un piccolo team di crittografi deve implementare questo codice strettamente controllato e revisionato, il che rende impossibile per ogni team di Google sviluppare in modo indipendente la propria crittografia. Un team di sicurezza speciale di Google è responsabile della manutenzione di questa libreria crittografica comune per tutti i prodotti.

La libreria di crittografia Tink supporta una vasta gamma di modalità e tipi di chiavi di crittografia, che vengono rivisti regolarmente per garantire che siano aggiornati con gli attacchi più recenti.

Attualmente, utilizziamo i seguenti algoritmi di crittografia per la crittografia dei dati inattivi per DEK e KEK. sono soggetti a modifiche man mano che continuiamo a migliorare le nostre capacità e la nostra sicurezza.

Primitiva di crittografia Protocolli preferiti Altri protocolli supportati
Crittografia simmetrica AES-GCM (256 bit)
  • AES-CBC e AES-CTR (128 e 256 bit)
  • AES-EAX (128 e 256 bit)
Firme simmetriche (se utilizzate con AES-CBC e AES-CTR sopra per l'autenticazione) HMAC-SHA256
  • HMAC-SHA512
  • HMAC-SHA1

Nella libreria sono presenti altri protocolli di crittografia supportati in passato, ma questa tabella illustra gli utilizzi principali di Google.

Ricerca e innovazione nel campo della crittografia

Per stare al passo con l'evoluzione della crittografia, abbiamo un team di ingegneri della sicurezza di altissimo livello con il compito di seguire, sviluppare e migliorare la tecnologia di crittografia. I nostri ingegneri partecipano ai processi di standardizzazione e alla gestione del software di crittografia di uso comune. Pubblicamo regolarmente le nostre ricerche nel campo della crittografia in modo che tutti, compreso il pubblico, possano trarre vantaggio dalle nostre conoscenze.

Ad esempio, nella ricerca di crittografia post-quantistica, stiamo lavorando nelle seguenti aree:

Passaggi successivi