Crittografia at-rest predefinita

Questi contenuti sono stati aggiornati per l'ultima volta a maggio 2024 e rappresentano lo status quo al momento della redazione. I criteri e i sistemi di sicurezza di Google potranno variare in futuro, in virtù del costante miglioramento della protezione per i nostri clienti.

In Google, la nostra strategia di sicurezza completa include la crittografia at-rest, che contribuisce a proteggere i dati dei clienti dagli autori degli attacchi. Utilizziamo uno o più meccanismi di crittografia per criptare tutti i contenuti archiviati dei clienti Google, senza che sia richiesta alcuna azione da parte tua. Questo documento descrive il nostro approccio alla crittografia at-rest predefinita per l'infrastruttura di Google e Google Cloud, e il modo in cui la utilizziamo per proteggere maggiormente i contenuti dei clienti.

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

La crittografia at-rest è quella 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 archiviati da Google vengono criptati a livello di archiviazione utilizzando l'algoritmo Advanced Encryption Standard (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 in Google Cloud.

Possediamo e gestiamo le chiavi usate 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 envelope ai tuoi dati. Con Cloud KMS puoi creare, ruotare, monitorare ed eliminare le chiavi. Per saperne di più, consulta Approfondimenti su Cloud Key Management Service.

Chiavi in Google Cloud

La tabella seguente descrive le diverse proprietà delle chiavi in Google Cloud.

Tipo di chiave	Cloud KMS Autokey	Cloud KMS gestito dal cliente (manuale)	Google-owned and Google-managed encryption key (crittografia predefinita di Google)
Può visualizzare i metadati chiave	Sì	Sì	No
Proprietà delle chiavi^1	Cliente	Cliente	Google
Può gestire^2 e controllare^3 le chiavi	La creazione e l'assegnazione delle chiavi sono automatizzate. Il controllo manuale del cliente è completamente supportato.	Cliente, solo controllo manuale	Google
Supporta i requisiti normativi per le chiavi gestite dal cliente	Sì	Sì	No
Condivisione della chiave	Unico per un cliente	Unico per un cliente	I dati di più clienti sono in genere protetti da chiavi di crittografia della chiave (KEK) condivise.
Controllo della rotazione della chiave	Sì	Sì	No
Policy dell'organizzazione per le chiavi CMEK	Sì	Sì	No
Registra l'accesso amministrativo e ai dati alle chiavi di crittografia	Sì	Sì	No
Separazione logica dei dati tramite crittografia	Sì	Sì	No
Prezzi	Varia	Varia	Nessun costo

¹ Il proprietario della chiave indica chi detiene i diritti sulla chiave. Le chiavi di tua proprietà hanno accesso strettamente limitato o nessun accesso da parte di Google.

² La gestione delle chiavi include le seguenti attività:

• Crea chiavi.
• Scegli il livello di protezione delle chiavi.
• Assegna l'autorità per la gestione delle chiavi.
• Controllare l'accesso alle chiavi.
• Controllare l'utilizzo delle chiavi.
• Imposta e modifica il periodo di rotazione delle chiavi o attiva una rotazione delle chiavi.
• Modifica lo stato della chiave.
• Elimina le versioni della chiave.
• Elimina versioni delle chiavi, chiavi e chiavi automatizzate.

³ Il controllo delle chiavi significa impostare i controlli sul tipo di chiavi e su come vengono utilizzate, rilevare le variazioni e pianificare azioni correttive, se necessario. Puoi controllare le tue chiavi, ma delegare la gestione a una terza parte.

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

La crittografia at-rest è uno dei tasselli di una più ampia strategia di sicurezza. La crittografia offre i seguenti vantaggi:

• Contribuisce a garantire che, se i dati finiscono nelle mani di un malintenzionato, quest'ultimo non possa leggerli senza avere accesso anche alle chiavi di crittografia. Anche se gli autori degli attacchi ottengono i dispositivi di archiviazione contenenti i dati dei clienti, non potranno comprenderli o decriptarli.
• Contribuisce a ridurre la superficie di attacco eliminando i livelli inferiori dello stack hardware e software.
• Funge da punto di controllo perché le chiavi di crittografia gestite centralmente creano un unico punto in cui l'accesso ai dati viene applicato e può essere controllato.
• Contribuisce a ridurre la superficie di attacco perché, anziché dover proteggere tutti i dati, le aziende possono concentrare le proprie strategie di protezione sulle chiavi di crittografia.
• Fornisce un importante meccanismo di tutela della privacy per i nostri clienti. Quando i dati vengono crittografati at-rest, l'accesso ai dati da parte di sistemi e ingegneri è limitato

Che cosa sono i dati dei clienti?

Come definito nei Google Cloud Termini di servizio, i dati dei clienti sono i dati che i clienti o gli utenti finali forniscono a Google tramite i servizi nell'ambito del loro account.

I contenuti dei clienti sono i dati che generi tu stesso o che ci fornisci, ad esempio i dati archiviati in bucket Cloud Storage, volumi 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 sui contenuti dei clienti e includono numeri di progetto generati automaticamente, timestamp, indirizzi IP, le dimensioni in byte di un oggetto in Cloud Storage o il tipo di macchina in Compute Engine. I metadati dei clienti sono protetti in modo ragionevole per garantire prestazioni costanti e continuità delle operazioni. Questo documento non si concentra sulle protezioni per i metadati.

I contenuti dei clienti e i metadati dei clienti costituiscono i dati dei clienti.

Crittografia predefinita dei dati a riposo

Google utilizza uno o più meccanismi di crittografia per criptare tutti i contenuti archiviati dei clienti, senza che sia richiesta alcuna azione da parte tua. 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 più 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 generalmente utilizzati per proteggere i dati degli utenti nei data center di produzione di Google. La crittografia del file system distribuito o la crittografia dell'archiviazione di database e file è attiva per tutti i dati utente e la crittografia del dispositivo di archiviazione è attiva per tutti i dati nei data center di produzione di Google.

Crittografia a livello di 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 logici per l'archiviazione e le dimensioni di ogni singolo blocco possono arrivare a diversi gigabyte. Ogni blocco viene criptato a livello di archiviazione con una chiave di crittografia dei dati (DEK) individuale: due blocchi non avranno la stessa DEK, anche se appartengono allo stesso cliente o sono archiviati sulla stessa macchina.

Se un blocco di dati viene aggiornato, viene criptato con una nuova chiave, non viene riutilizzata la chiave esistente. Questa partizione dei dati, ognuna delle quali utilizza una chiave diversa, limita il rischio di una potenziale compromissione della chiave di crittografia dei dati solo a quel blocco di dati.

Google cripta i dati prima che vengano scritti in un sistema di archiviazione del database o su un disco hardware. La crittografia è intrinseca a tutti i nostri sistemi di archiviazione, anziché aggiunta in un secondo momento.

Ogni blocco di dati logici ha un identificatore univoco. Gli elenchi di controllo dell'accesso (ACL) contribuiscono a garantire che ogni blocco possa essere decriptato solo dai servizi Google che operano con ruoli autorizzati, a cui viene concesso l'accesso solo in quel momento. Questa limitazione dell'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 in formato crittografato a fini di backup e ripristino di emergenza. Un malintenzionato che vuole accedere ai dati dei clienti deve conoscere e poter accedere a due cose: tutti i blocchi di archiviazione che corrispondono ai dati che vuole e tutte le chiavi di crittografia che corrispondono ai blocchi.

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

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

Un blocco di dati logico potrebbe contenere i dati di più clienti. Se vuoi ottenere la separazione logica dei dati tramite la crittografia, devi abilitare Cloud Key Management Service.

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 separata a livello di dispositivo (diversa dalla chiave utilizzata per criptare i dati a livello di archiviazione). Un numero ridotto di HDD legacy utilizza l'algoritmo AES-128. Gli SSD utilizzati da Google implementano AES-256 esclusivamente per i dati utente.

Crittografia dei backup

Il nostro sistema di backup garantisce che i dati rimangano criptati durante l'intero 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 con la propria DEK. La DEK deriva da una chiave archiviata in Keystore e da un seed per file generato in modo casuale al momento del backup. Un'altra DEK viene utilizzata per tutti i metadati nei backup, che vengono archiviati anche in Keystore.

Conformità FIPS per dati inattivi

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

Gestione delle chiavi

A causa dell'elevato volume di chiavi utilizzate da Google e della necessità di mantenere una bassa latenza e un'alta affidabilità, le DEK vengono archiviate vicino ai dati che devono criptare. Le DEK sono criptate (sottoposte a wrapping) con una chiave di crittografia della chiave (KEK), utilizzando una tecnica nota come crittografia envelope. Queste chiavi KEK non sono specifiche per i clienti. Esistono invece una o più chiavi KEK per ogni servizio.

Queste KEK sono archiviate centralmente in Keystore, un repository creato appositamente per l'archiviazione delle chiavi. Avere un numero inferiore di KEK rispetto alle DEK e utilizzare un keystore centrale rende gestibile l'archiviazione e la crittografia dei dati alla nostra scala e ci consente di monitorare e controllare l'accesso ai dati da un punto centrale.

Nota: Keystore era precedentemente noto come Key Management Service di Google. È diverso da Cloud KMS, che gestisce le chiavi di crittografia per Google Cloud i clienti e li aiuta a creare le chiavi tenant.

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 con una singola DEK. Le risorse non condivise vengono suddivise in blocchi di dati e criptate con chiavi separate da quelle utilizzate per altri clienti. Queste chiavi sono separate anche da quelle che proteggono altri elementi degli stessi dati di proprietà dello stesso cliente. Esistono eccezioni (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

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 criptate con la KEK del sistema di archiviazione e le DEK criptate vengono restituite 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 criptata e la invia a Keystore. Keystore verifica quindi che questo servizio sia autorizzato a utilizzare la KEK e, in caso affermativo, esegue il wrapping e restituisce la DEK non criptata al servizio. Il servizio utilizza quindi la DEK per decriptare il blocco di dati in testo non crittografato e verificarne l'integrità.

Tutti i sistemi di archiviazione Google Cloud aderiscono a 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. In questo modo, i sistemi possono fornire una bassa latenza utilizzando la KEK di livello più alto (memorizzata in Keystore) come radice di attendibilità.

Generazione di KEK

La maggior parte delle KEK per la crittografia dei blocchi di dati viene generata all'interno di Keystore, 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, tramite un generatore di numeri casuali (RNG) creato da Google. Questo RNG si basa su 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, il RNG viene inizializzato dall'istruzione RDRAND e dall'RNG del kernel Linux. A sua volta, l'RNG del kernel Linux viene inizializzato da più origini di entropia indipendenti, tra cui RDRAND ed eventi entropici dall'ambiente del data center (ad esempio, misurazioni granulari delle ricerche su disco e dei tempi di arrivo tra i pacchetti). Per i processori Arm, il RNG viene inizializzato dal RNG del kernel Linux.

Le DEK vengono criptate con le KEK utilizzando gli algoritmi AES-256 o AES-128, a seconda del servizioGoogle Cloud . Attualmente stiamo lavorando per eseguire l'upgrade di tutte le KEK per i serviziGoogle Cloud all'algoritmo AES-256.

Gestione KEK

Keystore è stato creato esclusivamente per la gestione delle KEK. Per progettazione, le KEK utilizzate dai sistemi di archiviazione non sono esportabili da Keystore; tutta la crittografia e la decrittografia con queste chiavi devono essere eseguite all'interno di Keystore. In questo modo si prevengono perdite e usi impropri e si consente a Keystore di creare una traccia di audit quando vengono utilizzate le chiavi.

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 facciamo riferimento a una singola chiave, in realtà intendiamo dire che i dati sono protetti tramite un set di chiavi: una chiave è attiva per la crittografia e un set di chiavi storiche è attivo per la decriptazione. Il numero di chiavi storiche è determinato dalla pianificazione rotazione della chiave. Le KEK vengono sottoposte a backup per scopi di ripristino di emergenza e sono recuperabili a tempo indeterminato.

L'utilizzo delle KEK è gestito tramite gli ACL in Keystore per ogni chiave, con un criterio diverso per ogni chiave. Solo i servizi e gli utenti 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 in un log. Tutti gli accessi ai dati da parte degli utenti sono verificabili nell'ambito delle norme generali sulla sicurezza e sulla privacy di Google.

Procedura per l'accesso ai 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 i dati di cui ha bisogno.
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 criptata memorizzata con quel blocco (in alcuni casi, questa operazione viene eseguita dal servizio) e la invia a Keystore per la decriptazione.
4. Il sistema di archiviazione verifica che il job identificato sia autorizzato ad accedere al blocco di dati in base a un identificatore del job e utilizzando l'ID blocco. Keystore verifica che il sistema di archiviazione sia autorizzato a utilizzare la KEK associata al servizio e a decriptare la DEK specifica.
5. Keystore esegue una delle seguenti operazioni:
   • Restituisce la DEK decriptata al sistema di archiviazione, che decripta il blocco di dati e lo invia al servizio.
   • In alcuni rari casi, trasmette la DEK non protetta al servizio. Il sistema di archiviazione passa il blocco di dati criptati al servizio, che lo decripta e lo utilizza.

Questa procedura è diversa nei 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, il servizio di archiviazione chiama Keystore per recuperare la DEK decriptata del blocco di dati.

Gerarchia delle chiavi di crittografia e radice di attendibilità

L'archivio chiavi è protetto da una chiave radice chiamata chiave master dell'archivio chiavi, che cripta tutte le KEK nell'archivio chiavi. Questa chiave master del keystore è AES-256 ed è a sua volta archiviata in un altro Key Management Service, chiamato Root Keystore. In passato, la chiave master del keystore era AES-128 e alcune di queste chiavi rimangono attive per decriptare i dati. Per ulteriore sicurezza, il keystore radice non viene eseguito su macchine di produzione generali, bensì solo su macchine dedicate in ogni data center di Google.

A sua volta, Root Keystore ha una propria chiave radice, chiamata chiave master di Root Keystore, che utilizza anch'essa l'algoritmo AES-256 ed è archiviata in un'infrastruttura peer-to-peer, chiamata distributore di chiavi master di Root Keystore, che replica queste chiavi a livello globale. In passato, la chiave master del keystore radice era AES-128 e alcune di queste chiavi rimangono attive per decriptare i dati. Il distributore di chiavi master del keystore radice contiene le chiavi solo nella RAM sulle stesse macchine dedicate del keystore radice e utilizza la registrazione per verificare l'uso corretto.

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

Per gestire lo scenario in cui tutte le istanze del distributore di chiavi master del keystore radice in una regione vengono riavviate simultaneamente, viene eseguito il backup della chiave master del keystore radice anche su dispositivi hardware protetti conservati in casseforti fisiche in aree a protezione elevata in più località distribuite geograficamente. Questo backup sarebbe necessario solo se tutte le istanze del distributore in una regione dovessero interrompersi contemporaneamente. Solo pochi dipendenti di 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 DEK, criptata con una KEK in Keystore, che a sua volta è protetta da Root Keystore e dal distributore di chiavi master di Root Keystore.

Riepilogo della gestione delle chiavi

Il seguente elenco riepiloga la gestione delle chiavi in Google:

• I dati vengono divisi in blocchi e criptati con DEK.
• Le DEK vengono criptate con KEK.
• Le chiavi KEK sono archiviate in Keystore.
• Keystore viene eseguito su più macchine nei data center a livello globale.
• Le chiavi dell'archivio chiavi sono criptate con la chiave master dell'archivio chiavi, archiviata nell'archivio chiavi radice.
• Root Keystore è molto più piccolo di Keystore e viene eseguito solo su macchine dedicate in ogni data center.
• Le chiavi del keystore radice sono criptate con la chiave master del keystore radice, archiviata nel distributore di chiavi master del keystore radice.
• Il distributore di chiavi master del keystore radice è un'infrastruttura peer-to-peer che viene eseguita simultaneamente nella RAM di macchine dedicate a livello globale. Ogni macchina riceve il materiale delle 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 affidabilità, la bassa latenza e l'accesso globale alle chiavi sono fattori essenziali. Queste caratteristiche sono necessarie per poter utilizzare i servizi di gestione delle chiavi in Google.

Per questo motivo, Keystore è altamente scalabile e viene replicato migliaia di volte nei nostri data center a livello globale. Viene eseguito su macchine normali nel nostro parco produzione e le istanze di Keystore vengono eseguite a livello globale per supportare le operazioni di Google. Di conseguenza, la latenza di qualsiasi operazione con una singola chiave è molto bassa.

Root Keystore viene eseguito su diverse macchine dedicate alle operazioni di sicurezza in ogni data center. Il distributore di chiavi master di Root Keystore viene eseguito sulle stesse macchine, one-to-one con Root Keystore. Il distributore di chiavi master del keystore radice fornisce un meccanismo di distribuzione utilizzando un protocollo gossip. A intervalli di tempo fissi, ogni istanza del distributore seleziona un'altra istanza casuale con cui confrontare le chiavi e riconcilia eventuali differenze nelle versioni delle chiavi. 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 delle chiavi con alta affidabilità.

Libreria crittografica comune di Google

La libreria crittografica comune di Google è Tink, che incorpora il modulo convalidato FIPS 140-2 denominato 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 rigidamente controllato e revisionato, rendendo superfluo che ogni team di Google sviluppi in modo indipendente la propria crittografia. Un team speciale di Google per la sicurezza è responsabile della manutenzione di questa libreria crittografica comune per tutti i prodotti.

La libreria di crittografia Tink supporta un'ampia gamma di tipi e modalità di chiavi di crittografia, che vengono esaminati regolarmente per garantire che siano aggiornati in base agli attacchi più recenti.

Nota: Google utilizza anche un'altra libreria chiamata Keymaster. Keymaster condivide con Tink codice di crittografia più recente, ma utilizza una diversa implementazione del controllo delle versioni delle chiavi e supporta una gamma più ampia di algoritmi meno recenti.

Attualmente, utilizziamo i seguenti algoritmi di crittografia at-rest per le DEK e le KEK. Gli algoritmi sono soggetti a modifiche in conformità con la nostra politica di continuo miglioramento delle funzionalità e della sicurezza.

Primitiva crittografica	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; tuttavia, questa tabella include i principali utilizzi in 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 livello mondiale incaricati 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. Pubblichiamo regolarmente le nostre ricerche nel campo della crittografia in modo che tutti, incluso il pubblico, possano beneficiare delle nostre conoscenze.

Ad esempio, nella ricerca sulla crittografia post-quantistica, stiamo lavorando nei seguenti ambiti:

• Standardizzazione: abbiamo progettato congiuntamente lo schema di firma digitale stateless basato su hash standardizzato come FIPS 205. Siamo editor dello standard dell'International Organization for Standardization (ISO) sulle firme basate su hash della crittografia post-quantistica e abbiamo contribuito alle linee guida sulla gestione dello stato per le firme basate su hash presso l'IETF.

• Attivazione: abbiamo implementato la crittografia post-quantistica nel nostro protocollo interno per la sicurezza del livello di trasporto. Abbiamo attivato il supporto per la crittografia post-quantistica in Chrome. Abbiamo aggiunto diversi algoritmi di crittografia post-quantistica alla nostra libreria crittografica Tink. Questo codice è sperimentale e ha lo scopo di informare la community su ciascun approccio.

• Pubblicazioni: abbiamo pubblicato Transitioning organizations to post-quantum cryptography su Nature. Questo documento fornisce una panoramica delle sfide di migrazione della crittografia post-quantistica. Abbiamo anche pubblicato un documento di ricerca sull'introduzione della crittografia post-quantistica nelle nostre chiavi di sicurezza.

Tieni presente che la crittografia simmetrica (che utilizza AES-128 o versioni successive) rimane resistente agli attacchi quantistici.

Passaggi successivi

• Per informazioni sulle risorse di crittografia post-quantistica di Google, vedi Crittografia post-quantistica.

• Per informazioni sull'utilizzo delle tue chiavi di crittografia in Google Cloud, vedi Chiavi di crittografia gestite dal cliente (CMEK).

• Per informazioni generali sulla sicurezza di Google Cloud , consulta la sezione Sicurezza del sito web Google Cloud .

• Per informazioni sulla Google Cloud conformità e sulle certificazioni di conformità, consulta la sezione sulla conformità del Google Cloud sito web, che include il report di controllo pubblico SOC3 di Google.

• Per informazioni sulla crittografia e sulla gestione delle chiavi di Google Workspace, consulta In che modo Google Workspace utilizza la crittografia per proteggere i tuoi dati, che tratta gran parte degli stessi contenuti inclusi qui, ma si concentra esclusivamente su Google Workspace.