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.
La strategia di sicurezza completa di Google include la crittografia at-rest, che aiuta a proteggere i dati dei clienti da utenti malintenzionati. Criptiamo tutti i dati i contenuti inattivi dei clienti, senza che sia richiesta alcuna azione da parte tua, utilizzando uno o più 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 un tipo di crittografia comune libreria, Tink, che include il nostro modulo convalidato FIPS 140-2 (denominato 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 consente di creare le tue chiavi di crittografia che puoi utilizzare per aggiungere la crittografia envelope 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 pezzo di una strategia di sicurezza più ampia. La crittografia ha i seguenti vantaggi:
- Contribuisce a garantire che se i dati finiscano 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 gli strati inferiori lo stack hardware e 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 con crittografia at-rest, limita l'accesso richiesto a sistemi e ingegneri 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 è incentrato 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 generati automaticamente, timestamp, indirizzi IP, la dimensione in byte in Cloud Storage, oppure il tipo di macchina in Compute Engine. I metadati dei clienti sono protetti in una misura tale in modo ragionevole per garantire le prestazioni e le operazioni costanti. Questo documento non è incentrato su sulle protezioni dei metadati.
Insieme, i contenuti dei clienti e i metadati dei clienti costituiscono i dati dei clienti.
Crittografia predefinita dei dati at-rest
Google cripta tutti i contenuti archiviati inattivi dei clienti senza che sia necessaria alcuna azione da parte dei mediante 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'uso di più fornisce una protezione dei dati ridondante e ci consente di selezionare un approccio ottimale in base ai requisiti dell'applicazione.
Il seguente diagramma mostra i vari livelli di crittografia generalmente utilizzate per proteggere i dati degli utenti nei data center di produzione 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 un file secondario chunk per l'archiviazione; e ciascun blocco può avere una dimensione massima di 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 possono 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 siano scritti in un sistema di archiviazione di database disco hardware. La crittografia è intrinseca in tutti i nostri sistemi di archiviazione, anziché aggiunti in seguito.
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 utente malintenzionato che vuole accedere che i dati dei clienti dovrebbero conoscere ed essere in grado di accedere a due cose: di archiviazione dati che corrispondono ai dati desiderati e a tutte di crittografia che corrispondono ai blocchi.
Il seguente diagramma mostra come i dati vengono caricati nella nostra infrastruttura e quindi suddivisi in blocchi criptati per l'archiviazione.
Per criptare i dati at-rest, utilizziamo l'algoritmo AES. Tutti i dati a livello di archiviazione è criptato dalle chiavi DEK, che per impostazione predefinita utilizzano AES-256, ad eccezione di un un numero ridotto di Dischi permanenti creati prima del 2015 con 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 a crittografia a livello di sistema di archiviazione, i dati vengono inoltre crittografati a livello di dispositivo di archiviazione con l’algoritmo AES-256 per l’hard disk (HDD) e a stato solido (SSD), utilizzando una chiave separata a livello di dispositivo (che è 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 una propria DEK. La DEK deriva da una chiave archiviata nell'archivio chiavi un seed generato casualmente per file al momento del backup. Viene utilizzata un'altra DEK per tutte nei backup, archiviati anche nell'archivio chiavi.
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 avere una bassa latenza e l'alta disponibilità, le DEK sono archiviate vicino ai dati che devono criptare. Le DEK sono Essere criptato con una chiave di crittografia della chiave (KEK), utilizzando una tecnica nota come crittografia busta. 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 sono suddivise in blocchi di dati e criptati con chiavi separate 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 ad esempio Datastore, App Engine o Pub/Sub). in cui i dati di più clienti potrebbero essere criptati con la stessa DEK.
Generazione delle DEK in corso...
Il sistema di archiviazione genera le DEK utilizzando la libreria crittografica comune di Google. In generale, le chiavi DEKS vengono inviate all'archivio chiavi per eseguirne il wrapping con Le KEK e le DEK criptate vengono restituite al sistema di archiviazione per essere conservate dei 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 nella gerarchia delle 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 delle KEK in corso...
La maggior parte delle KEK per la crittografia dei blocchi di dati viene generata all'interno dell'archivio chiavi e le altre vengono generate all'interno dei servizi di archiviazione. Per coerenza, tutte le KEK generati mediante la libreria crittografica comune di Google, utilizzando un numero casuale generatore (RNG) creato da Google. Questo RNG si basa su NIST 800-90Ar1 CTR-DRBG e genera una KEK AES-256. (In passato, era AES-128 e alcuni di questi 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 viene generato da più origini entropiche indipendenti, tra cui RDRAND ed eventi entropici provenienti dai dati dell'ambiente centrale, ad esempio misurazioni granulari del numero di ricerche le ore di arrivo tra pacchetti). Per i processori ARM, l'RNG viene derivato con l'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 KEK
L'archivio chiavi è stato creato esclusivamente per gestire le KEK. Per progettazione, le KEK usati dai sistemi di archiviazione non sono esportabili dall'archivio chiavi. tutte le operazioni di crittografia la decrittografia con queste chiavi deve essere eseguita 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.
L'archivio chiavi può ruotare automaticamente le KEK a intervalli di tempo regolari, utilizzando 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. Le KEK vengono sottoposte a backup a scopo di ripristino di emergenza e recuperabili in modo permanente.
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 possono essere controllati come parte 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:
- Il servizio effettua una chiamata al sistema di archiviazione per i 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 per verificare che il sistema di archiviazione sia autorizzato a utilizzare la KEK, associati al servizio e per annullare il wrapping di quella specifica DEK.
- L'archivio chiavi esegue una delle seguenti operazioni:
- Ritrasmette la DEK senza wrapping al sistema di archiviazione, decripta il blocco di dati e lo passa al servizio.
- In alcuni rari casi, passa la DEK senza wrapper 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. (Nel in passato, la chiave master dell'archivio chiavi era AES-128 e alcune di queste chiavi rimangono attive per decriptare i dati.) Per maggiore sicurezza, Root Keystore non viene eseguito su macchine di produzione generali, ma viene eseguito solo 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 master dell'archivio chiavi principale il distributore di chiavi conserva le chiavi nella RAM solo sulle stesse macchine dedicate Root Keystore, che usa il logging per verificarne 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 dell'archivio chiavi principale 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 di macchine protette.
per risolvere lo scenario in cui tutte le istanze della chiave master dell'archivio chiavi principale automaticamente il distributore in una regione, la chiave master dell'archivio chiavi radice ed è inoltre eseguito il backup su dispositivi hardware protetti conservati in casseforti fisiche in aree altamente protette in diverse località geograficamente distribuite. Questo il backup sarebbe necessario solo nel caso in cui tutte le istanze del distributore in una regione vengano contemporaneamente. Solo pochi 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 sottoposte a wrapping con la chiave master dell'archivio chiavi, che viene archiviata nell'archivio chiavi radice.
- L'archivio chiavi radice è molto più piccolo dell'archivio chiavi e viene eseguito solo su in ogni 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 dell'archivio chiavi radice è un distributore peer-to-peer infrastruttura che viene eseguita contemporaneamente nella RAM su macchine dedicate a livello globale. Ogni macchina riceve il materiale della chiave da altre istanze in esecuzione della regione.
- Nel caso in cui tutte le istanze del distributore in una regione smettano di funzionare, sia archiviata in diversi hardware protetti all'interno di casseforti fisiche di località Google limitate.
Replica e disponibilità a livello globale
A ogni livello, alta disponibilità, bassa latenza e accesso globale alle chiavi sono in modo critico. Queste caratteristiche sono necessarie affinché i servizi di gestione utilizzati su Google.
Per questo motivo, l'archivio chiavi è altamente scalabile e viene replicato 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 operations. Di conseguenza, la latenza di ogni singola operazione relativa alle chiavi è molto bassa.
L'archivio chiavi root viene eseguito su diverse macchine dedicate alle operazioni di sicurezza in ciascun data center. Il distributore di chiavi master dell'archivio chiavi radice viene eseguito su questi stessi macchine virtuali, 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 versions. 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 nostro modulo convalidato FIPS 140-2, BoringCrypto. Tink è disponibile per tutti gli sviluppatori di Google. Utilizzo coerente di una libreria comune solo un piccolo team di crittografi deve implementare questa controllato e revisionato, rendendo inutile per ogni team di Google sviluppare in modo indipendente la propria crittografia. Un team speciale di Google per la sicurezza responsabile della manutenzione 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, per la crittografia at-rest vengono utilizzati i seguenti algoritmi di crittografia. per le DEK e le KEK. Queste modifiche sono soggette a variazioni nell'ambito del miglioramento continuo dei nostri funzionalità e sicurezza.
| Primitiva crittografica | Protocolli preferiti | Altri protocolli supportati |
|---|---|---|
| Crittografia simmetrica | AES-GCM (256 bit) |
|
| Firme simmetriche (quando utilizzate con i protocolli AES-CBC e AES-CTR precedenti per autenticazione) | HMAC-SHA256 |
|
Nella libreria sono presenti altri protocolli crittografici che storicamente erano supportati, ma questa tabella illustra gli utilizzi principali in 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 del Organizzazione internazionale per la standardizzazione (ISO) su crittografia post-quantistica basata su hash firme e ha contribuito a indicazioni sullo stato per le firme basate su hash presso la IETF.
Enablement: abbiamo implementato la tecnologia post-quantistica crittografia al nostro protocollo interno per il protocollo Transport Layer Security. 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 post-quantistica crittografia in Natura. Questo documento fornisce una panoramica della crittografia post-quantistica sfide legate alla migrazione. Abbiamo anche pubblicato una ricerca su come della 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 per 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 su conformità e conformità di Google Cloud le certificazioni, consulta Sezione sulla conformità del sito web di Google Cloud. che include le funzionalità report pubblico di audit SOC3.
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.