Questi contenuti sono stati aggiornati a maggio 2024 e rappresentano lo status quo. al momento in cui è stata scritta. Le norme e i sistemi di sicurezza di Google potrebbero cambiare in futuro, grazie al costante miglioramento della protezione per i nostri clienti.
In Google, la nostra strategia di sicurezza completa include la crittografia dei dati inattivi, che aiuta a proteggere i dati dei clienti dagli aggressori. Criptiamo tutti i contenuti archiviati dei clienti di Google, senza che sia richiesta alcuna azione da parte tua, utilizzando uno o più meccanismi di crittografia. Questo documento descrive il nostro approccio al modello predefinito crittografia at-rest per l'infrastruttura Google e Google Cloud, e come la usiamo per proteggere meglio i contenuti dei clienti.
Questo documento è rivolto agli architetti della sicurezza e ai team di sicurezza che attualmente che utilizzano o prendono in considerazione Google. Questo documento presuppone una conoscenza di base 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 SSD) o su supporti di backup. Tutti i dati che vengono archiviati da Google e vengono criptati a livello di archiviazione utilizzando Algoritmo di crittografia Standard (AES), AES-256. Utilizziamo una libreria crittografica comune, Tink, che include il nostro modulo convalidato FIPS 140-2 (chiamato BoringCrypto) per implementare la crittografia in modo coerente in Google Cloud.
Possediamo e 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 da utilizzare per aggiungere la crittografia dell'involucro ai tuoi dati. Con Cloud KMS, puoi creare, ruotare, monitorare ed eliminare le chiavi. Per ulteriori informazioni, vedi Approfondimento su Cloud Key Management Service.
In che modo la crittografia at-rest contribuisce alla protezione dei dati
La crittografia at-rest è un tassello di una strategia di sicurezza più ampia. La crittografia offre i seguenti vantaggi:
- Contribuisce a garantire che se i dati finiscono nelle mani di un aggressore, l’autore dell’attacco non può leggere i dati senza avere anche accesso alla crittografia chiave. Anche se gli aggressori ottengono i dispositivi di archiviazione che contengono non saranno in grado di comprenderli o decriptarli.
- Contribuisce a ridurre la superficie di attacco eliminando i livelli più bassi dell'hardware e dello stack software.
- Agisce da "chokepoint" perché le chiavi di crittografia gestite centralmente creano una un unico luogo in cui l'accesso ai dati viene applicato in modo forzato e controllato.
- Aiuta a ridurre la superficie di attacco perché invece di dover proteggere tutti i dati, le aziende possono concentrare le loro strategie di protezione chiavi di crittografia.
- Fornisce un importante meccanismo di privacy per i nostri clienti. Quando i dati vengono criptato at-rest, limita l'accesso di cui i sistemi e gli ingegneri hanno bisogno i dati
Che cosa sono i dati dei clienti?
Come definito nella sezione Termini di servizio di Google Cloud, I dati dei clienti sono i dati che i clienti o gli utenti finali forniscono a Google tramite i servizi nel proprio account.
I contenuti dei clienti sono dati generati da te o da te forniti, come i dati archiviati in bucket Cloud Storage, volumi di Persistent Disk e snapshot di dischi utilizzati da Compute Engine. Questo documento si concentra sulla crittografia at-rest predefinita per questo tipo di dati dei clienti.
I metadati dei clienti sono dati relativi ai contenuti dei clienti e includono numeri di progetto, timestamp, indirizzi IP, dimensioni in byte di un oggetto in Cloud Storage o il tipo di macchina in Compute Engine generati automaticamente. I metadati dei clienti sono protetti in misura ragionevole per garantire prestazioni e operazioni costanti. Questo documento non si concentra sulle protezioni per i metadati.
Insieme, i contenuti dei clienti e i metadati dei clienti costituiscono i dati dei clienti.
Crittografia predefinita dei dati at-rest
Google utilizza uno o più meccanismi di crittografia per criptare tutti i contenuti archiviati inattivi dei clienti, senza che sia richiesta alcuna azione da parte loro. Le sezioni seguenti 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 molteplici livelli di crittografia aggiunge una protezione dei dati ridondante e ci consente di scegliere l'approccio ottimale in base ai requisiti dell'applicazione.
Il seguente diagramma mostra i diversi livelli di crittografia che vengono generalmente utilizzati per proteggere i dati utente nei data center di produzione di Google. Sia distribuito la crittografia del file system o la crittografia di database e archiviazione di file e la crittografia del dispositivo di archiviazione è applicata a tutti i dati data center di produzione Google.
Crittografia a livello di hardware e infrastruttura
Tutti i sistemi di archiviazione di Google utilizzano un'architettura di crittografia simile, e i dettagli dell'implementazione variano da un sistema all'altro. I dati sono suddivisi in blocchi di sottofile per l'archiviazione e le dimensioni di ogni singolo blocco possono arrivare a diversi gigabyte. Ciascuna è criptato a livello di archiviazione con una chiave di crittografia dei dati individuale (DEK): due blocchi non avranno la stessa DEK, anche se sono di proprietà della stessa o archiviati sulla stessa macchina. Un blocco di dati in Datastore, App Engine e Pub/Sub può contenere i dati di più clienti.
Se un blocco di dati viene aggiornato, viene criptato con una nuova chiave, anziché tramite a riutilizzare la chiave esistente. Questo partizionamento dei dati, ognuno con una chiave diversa, limita il rischio di compromissione della chiave di crittografia dei dati solo a quei dati un blocco note.
Google cripta i dati prima che vengano scritti in un sistema di archiviazione del database o su un disco hardware. La crittografia è integrata in tutti i nostri sistemi di archiviazione, non viene aggiunta in un secondo momento.
Ogni blocco di dati ha un identificatore univoco. Guida per gli elenchi di controllo dell'accesso (ACL) per garantire che ogni blocco possa essere decriptato solo dai servizi Google con ruoli autorizzati, a cui viene concesso l'accesso solo in quel momento. Questo la limitazione di accesso contribuisce a impedire l'accesso ai dati senza autorizzazione, rafforzando la sicurezza e la privacy dei dati.
Ogni blocco viene distribuito nei nostri sistemi di archiviazione e viene replicato per il backup e il ripristino di emergenza. Un malintenzionato che vuole accedere ai dati dei clienti deve conoscere ed essere in grado di accedere a due elementi: tutti i blocchi di archiviazione corrispondenti ai dati che vuole e tutte le chiavi di crittografia corrispondenti ai blocchi.
Il seguente diagramma mostra come i dati vengono caricati nella nostra infrastruttura e poi suddivisi in blocchi criptati per l'archiviazione.
Per criptare i dati at-rest, utilizziamo l'algoritmo AES. Tutti i dati a livello di archiviazione vengono criptati dalle DEK, che utilizzano AES-256 per impostazione predefinita, ad eccezione di un numero ridotto di dischi permanenti creati prima del 2015 che utilizzano AES-128. L'algoritmo AES è ampiamente usato perché Gli standard AES-256 e AES-128 sono consigliati National Institute of Standards and Technology (NIST) per l'archiviazione a lungo termine e l'algoritmo AES è spesso incluso di conformità.
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 i dischi rigidi (HDD) e le unità a stato solido (SSD), utilizzando una chiave a livello di dispositivo distinta (diversa dalla chiave utilizzata per criptare i dati a livello di archiviazione). Un numero ridotto di HDD legacy utilizza AES-128. Le unità SSD utilizzate da Google implementano l'algoritmo AES-256 solo per i dati utente.
Crittografia dei backup
Il nostro sistema di backup garantisce che i dati rimangano criptati durante il backup e il processo di sviluppo. 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 con la propria DEK. La DEK è ricavata da una chiave archiviata nell'archivio chiavi e da un seme generato in modo casuale per ogni file al momento del backup. Per tutti i metadati dei backup viene utilizzata un'altra DEK, archiviata anch'essa nel Keystore.
Conformità FIPS per dati inattivi
Google utilizza una Certificazione FIPS 140-2 modulo crittografia (certificato 4407) 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 vengono archiviate vicino ai dati che devono criptare. Le DEK sono criptate con una chiave di crittografia della chiave (KEK) (sottoposte a wrapping), utilizzando una tecnica nota come crittografia con incapsulamento. Queste KEK non sono specifiche per i clienti; esistono invece una o più KEK ogni servizio.
Queste KEK sono archiviate a livello centrale nell'archivio chiavi, un repository creato appositamente per per archiviare le chiavi. Avere un numero inferiore di KEK rispetto alle DEK e utilizzare una L'archivio chiavi rende gestibili l'archiviazione e la crittografia dei dati sulla nostra scala e ci consente 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 in Compute Engine. Per le risorse condivise, più clienti utilizzano una singola copia, criptata da una singola DEK. Le risorse non condivise vengono suddivise in blocchi di dati e criptate con chiavi diverse da quelle utilizzate per altri clienti. Questi token sono separati da quelli che proteggono altre degli stessi dati di proprietà dello stesso cliente. Ci sono delle eccezioni (ad esempio, Datastore, App Engine o Pub/Sub) in cui i dati di più clienti 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 genere, le DEK vengono inviate al Keystore per essere sottoposte a wrapping con la KEK del sistema di archiviazione e le DEK con wrapping vengono restituite al sistema di archiviazione per essere conservate insieme ai blocchi di dati. Quando un sistema di archiviazione deve recuperare i dati criptati, recupera la DEK sottoposta a wrapping e la passa all'archivio chiavi. L'archivio chiavi verifica quindi questo servizio è autorizzato a utilizzare la KEK e, in questo caso, annulla il wrapping e restituisce il token DEK in testo non crittografato al servizio. Il servizio utilizza quindi la chiave DEK per decriptare i dati in testo non crittografato 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 durante l'utilizzo la KEK di livello più elevato (archiviata nell'archivio chiavi) come radice di attendibilità.
Generazione di KEK
La maggior parte delle KEK per la crittografia dei blocchi di dati viene generata all'interno del Keystore, mentre le altre vengono generate all'interno dei servizi di archiviazione. Per coerenza, tutte le KEK vengono generate tramite la libreria crittografica comune di Google, utilizzando un generatore di numeri casuali (RNG) creato da Google. L'RNG si basa sulla pubblicazione NIST 800-90Ar1 CTR-DRBG e genera una KEK AES-256. In passato, l'algoritmo era AES-128 e alcune di queste chiavi rimangono attive per decriptare i dati.
Per i processori Intel e AMD, l'RNG proviene da RDRAND istruzione e Linux con l'RNG del kernel. A sua volta, l'RNG del kernel Linux ha origine da più origini entropiche indipendenti, tra cui RDRAND ed eventi entropici provenienti dall'ambiente del data center (ad esempio misurazioni granulari del numero di operazioni di ricerca su disco e tempi di arrivo tra pacchetti). Per i processori ARM, l'RNG ha origine dall'RNG del kernel Linux.
Le DEK vengono sottoposte a wrapping con le KEK utilizzando gli AES-256 o AES-128, a seconda dal servizio Google Cloud. Al momento stiamo lavorando per eseguire l'upgrade di tutte le KEK per i servizi Google Cloud in formato AES-256.
Gestione delle KEK
L'archivio chiavi è stato creato esclusivamente per gestire le KEK. Per impostazione predefinita, le KEK utilizzate dai sistemi di archiviazione non sono esportabili dall'archivio chiavi; tutte le operazioni di crittografia e decriptazione con queste chiavi devono essere eseguite all'interno dell'archivio chiavi. Ciò aiuta a prevenire perdite e usi impropri e consente all'archivio chiavi di creare un audit trail quando le chiavi in uso.
Il keystore può ruotare automaticamente le KEK a intervalli di tempo regolari, utilizzando la libreria crittografica comune di Google per generare nuove chiavi. Anche se spesso si riferisce a una singola chiave, intendiamo dire che i dati sono protetti tramite set: una chiave è attiva per la crittografia e un set di chiavi storiche è attivo per la decrittografia. Il numero di chiavi storiche è determinato dalla rotazione della chiave programmazione. Il backup delle KEK viene eseguito a scopo di ripristino di emergenza e possono essere recuperate in modo illimitato.
L'uso delle KEK è gestito da ACL nell'archivio chiavi per ogni chiave, con un . 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 richiede quella chiave, perciò, ogni volta che un utente utilizza una chiave, autenticati e registrati. Tutti gli accessi ai dati da parte degli utenti sono controllabili nell'ambito delle norme sulla privacy e dei criteri di sicurezza globali di Google.
Procedura per accedere a blocchi di dati criptati
Quando un servizio Google accede a un blocco di dati criptato, si verifica:
- Il servizio effettua una chiamata al sistema di archiviazione dei dati di cui ha bisogno.
- Il sistema di archiviazione identifica i blocchi in cui sono archiviati i dati (gli ID blocco) e la posizione in cui sono archiviati.
- Per ogni blocco, il sistema di archiviazione estrae la DEK con wrapping che è archiviata con quel blocco (in alcuni casi, questa operazione viene eseguita dal servizio) e lo invia all'archivio chiavi per l'unwrapping.
- Il sistema di archiviazione verifica che il job identificato sia autorizzato ad accedere il blocco di dati in base a un identificatore del job e tramite l'ID blocco. Keystore verifica che il sistema di archiviazione sia autorizzato a utilizzare la KEK, associati al servizio e per annullare il wrapping di quella DEK specifica.
- L'archivio chiavi esegue una delle seguenti operazioni:
- Restituisce 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 decriptata al servizio. La sistema di archiviazione passa il blocco di dati criptato al servizio, decripta il blocco di dati e lo utilizza.
Questa procedura è diversa per i dispositivi di archiviazione dedicati, in cui il dispositivo gestisce e protegge la DEK a livello di dispositivo.
Il seguente diagramma mostra questo processo. Per decriptare un blocco di dati, lo spazio di archiviazione il servizio chiama l'archivio chiavi per recuperare la DEK senza wrapping per quel blocco di dati.
Gerarchia delle chiavi di crittografia e radice di attendibilità
L'archivio chiavi è protetto da una chiave radice denominata chiave master dell'archivio chiavi, che aggrega tutte le KEK nell'archivio chiavi. Questa chiave master dell'archivio chiavi è AES-256 in un altro Key Management Service, chiamato Root Keystore. In passato, la chiave principale del keystore era AES-128 e alcune di queste chiavi rimangono attive per decriptare i dati. Per ulteriore sicurezza, il Root Keystore non viene eseguito su macchine di produzione generali, bensì solo su macchine dedicate in ogni data center di Google.
L'archivio chiavi radice a sua volta ha una propria chiave radice, denominata master dell'archivio chiavi root , anch'esso AES-256 e archiviata in un'infrastruttura peer-to-peer, chiamato distributore di chiavi master dell'archivio chiavi principale e che replica queste chiavi a livello globale. (In passato, la chiave master dell'archivio chiavi principale era AES-128 e alcune di queste chiavi rimangono attive per decriptare i dati.) Il distributore di chiavi master del keystore radice conserva le chiavi solo nella RAM delle stesse macchine dedicate del keystore radice e utilizza il logging per verificare l'utilizzo corretto.
Quando viene avviata una nuova istanza del distributore di chiavi master dell'archivio chiavi radice, è configurato con un elenco di nomi host di un distributore già in esecuzione di Compute Engine. Le istanze del distributore possono quindi ottenere la chiave master del keystore radice dalle 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 di macchine protette.
Per gestire lo scenario in cui tutte le istanze del distributore di chiavi master del keystore radice in una regione vengono riavviate contemporaneamente, il backup della chiave master del keystore radice viene effettuato anche su dispositivi hardware protetti conservati in casseforti fisiche in aree a protezione elevata in più località geograficamente distribuite. Questo il backup sarebbe necessario solo nel caso in cui tutte le istanze del distributore in una regione vengano contemporaneamente. Solo alcuni dipendenti di Google possono accedere a queste casseforti.
Il seguente diagramma mostra la gerarchia delle chiavi di crittografia. La chiave di crittografia la gerarchia protegge un blocco di dati con una DEK, sottoposta a wrapping con una KEK nell'archivio chiavi che è a sua volta protetta dall'archivio chiavi radice e dalla chiave master dell'archivio chiavi radice. distributore.
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 nell'archivio chiavi.
- L'archivio chiavi viene eseguito su più computer nei data center a livello globale.
- Le chiavi dell'archivio chiavi sono criptate con la chiave master dell'archivio chiavi, archiviata in Root Keystore.
- Il Keystore principale è molto più piccolo del Keystore e viene eseguito solo su macchine dedicate in ciascun data center.
- Le chiavi dell'archivio chiavi radice sono sottoposte a wrapping con la chiave master dell'archivio chiavi radice, che nel distributore di chiavi master dell'archivio chiavi.
- Il distributore di chiavi master del Keystore principale è un'infrastruttura peer-to-peer che viene eseguita contemporaneamente nella RAM di macchine dedicate a livello globale. Ogni macchina riceve il materiale relativo alle chiavi da altre istanze in esecuzione nella regione.
- Nel caso in cui tutte le istanze del distributore in una regione si spengano, una chiave master è archiviata in hardware protetti diversi in casseforti fisiche in alcune sedi di Google.
Replica e disponibilità a livello globale
A ogni livello, l'alta disponibilità, la bassa latenza e l'accesso globale alle chiavi sono fattori essenziali. Queste caratteristiche sono necessarie affinché i servizi di gestione utilizzati su Google.
Per questo motivo, Keystore è altamente scalabile e viene replicato migliaia di volte nei nostri data center di tutto il mondo. Viene eseguito su macchine normali nel nostro parco risorse di produzione e le istanze dell'archivio chiavi vengono eseguite a livello globale per supportare operazioni aziendali. Di conseguenza, la latenza di ogni singola operazione relativa alle chiavi è molto bassa.
Il Keystore principale viene eseguito su varie macchine dedicate alle operazioni di sicurezza in ciascun data center. Il distributore di chiavi master dell'archivio chiavi radice viene eseguito su questi stessi machine learning one-to-one con l'archivio chiavi radice. La chiave master dell'archivio chiavi radice distributore fornisce un meccanismo di distribuzione utilizzando protocollo di gossiping. In un intervallo di tempo fisso, ogni istanza del distributore seleziona un'altra istanza dell'istanza per confrontare le proprie chiavi e riconciliare eventuali differenze e versioni successive. Con questo modello, non esiste un nodo centrale che tutte le nostre dell'infrastruttura. Questo metodo di distribuzione ci consente di e il materiale chiave con disponibilità elevata.
Libreria crittografica comune di Google
La libreria crittografica comune di Google è Tink, che incorpora il modulo convalidato FIPS 140-2 BoringCrypto. Tink è disponibile per tutti gli sviluppatori di Google. Grazie all'uso coerente di una libreria comune, è sufficiente un team ridotto di crittografi per implementare questo codice rigidamente controllato e revisionato. Non è necessario che ogni team di Google sviluppi in modo indipendente la propria crittografia. Un team speciale di Google per la sicurezza responsabile della gestione di questa libreria crittografica comune prodotti di big data e machine learning.
La libreria di crittografia Tink supporta un'ampia varietà di tipi di chiavi di crittografia e e questi vengono esaminati regolarmente per verificarne la conformità alle più recenti.
Al momento, utilizziamo i seguenti algoritmi crittografici per la crittografia dei dati inattivi per le chiavi DEK e KEK. Gli algoritmi sono soggetti a modifiche in conformità con la nostra politica di continuo miglioramento delle funzionalità e della sicurezza.
| Primitiva di crittografia | Protocolli preferiti | Altri protocolli supportati |
|---|---|---|
| Crittografia simmetrica | AES-GCM (256 bit) |
|
| Firme simmetriche (quando utilizzate con i protocolli AES-CBC e AES-CTR riportati sopra per l'autenticazione) | HMAC-SHA256 |
|
Nella libreria sono presenti altri protocolli di crittografia supportati in passato, ma questa tabella illustra i principali utilizzi di Google.
Ricerca e innovazione nel campo della crittografia
Per stare al passo con l'evoluzione della crittografia, disponiamo di un team di esperti tecnici della sicurezza incaricati di seguire, sviluppare e migliorare la crittografia tecnologia. I nostri ingegneri partecipano ai processi di standardizzazione e alla gestione del software di crittografia di uso comune. Pubblichiamo regolarmente la nostra ricerca nel campo della crittografia in modo che tutti, incluso il pubblico, possano traggano vantaggio dalle nostre conoscenze.
Ad esempio, nell'ambito della ricerca sulla crittografia post-quantistica, stiamo lavorando le seguenti aree:
Standardizzazione: abbiamo co-progettato il modello digitale stateless basato su hash schema di firma standardizzato come FIPS 205. Siamo editor dello standard dell'International Organization for Standardization (ISO) sulle firme basate su hash di crittografia post-quantistica e abbiamo contribuito alle linee guida sulla gestione dello stato per le firme basate su hash all'IETF.
Attivazione: abbiamo implementato la crittografia post-quantistica nel nostro protocollo interno per la sicurezza del livello di trasporto. Abbiamo attivato l'assistenza per la crittografia post-quantistica Chrome Abbiamo aggiunto diversi algoritmi di crittografia post-quantistica nel nostro Tink. crittografico libreria di Google. Questo codice è sperimentale ed è pensato per informare la community di ciascun approccio.
Pubblicazioni: abbiamo pubblicato Transizione delle organizzazioni alla crittografia post-quantistica su Nature. Questo documento fornisce una panoramica della crittografia post-quantistica sfide legate alla migrazione. Abbiamo anche pubblicato una ricerca su come crittografia post-quantistica nella nostra chiave.
Tieni presente che la crittografia simmetrica (con AES-128 o versioni successive) rimane resistente agli attacchi quantistici.
Passaggi successivi
Per informazioni sull'utilizzo delle tue chiavi di crittografia in Google Cloud, consulta Chiavi di crittografia gestite dal cliente (CMEK).
Per informazioni generali sulla sicurezza di Google Cloud, consulta la sezione sulla sicurezza del sito web di Google Cloud.
Per informazioni sulla conformità di Google Cloud e sulle certificazioni di conformità, consulta la sezione sulla conformità del sito web di Google Cloud, che include il report di controllo pubblico SOC3 di Google.
Per informazioni sulla gestione delle chiavi e della crittografia in Google Workspace, consulta In che modo Google Workspace utilizza la crittografia per proteggere i tuoi dati che copre gran parte degli stessi contenuti inclusi qui, ma si concentra esclusivamente su Google Workspace.