Crittografia dei dati inattivi su Google Cloud Platform

I contenuti del presente documento sono aggiornati ad aprile 2017 e rappresentano lo status quo del momento in cui sono stati redatti. Criteri e sistemi di sicurezza di Google Cloud Platform possono variare in futuro, grazie al costante miglioramento della protezione per i nostri clienti.

Pulsante di riproduzione

Crittografia dei dati inattivi su Google Cloud

Riepilogo a livello di CIO

  • Google utilizza diversi livelli di crittografia per proteggere i dati inattivi dei clienti nei prodotti Google Cloud Platform.
  • Google Cloud Platform utilizza uno o più meccanismi di crittografia per criptare i contenuti archiviati inattivi dei clienti, senza che sia richiesta alcuna azione da parte loro. Esistono alcune piccole eccezioni, indicate più avanti in questo documento.
  • I dati da archiviare sono suddivisi in blocchi, ognuno dei quali viene criptato con una chiave di crittografia dei dati univoca. Le chiavi di crittografia dei dati vengono archiviate insieme ai dati e vengono criptate (vengono sottoposte a wrapping) da chiavi di crittografia della chiave archiviate e utilizzate esclusivamente nel Key Management Service centrale di Google. Il Key Management Service di Google è un servizio ridondante e distribuito a livello globale.
  • I dati archiviati in Google Cloud Platform vengono criptati a livello di archiviazione con gli algoritmi AES256 o AES128.
  • Per implementare in modo coerente la crittografia in quasi tutti i prodotti Google Cloud Platform, Google utilizza Tink, una libreria crittografica comune. Dato che la libreria comune è ampiamente accessibile, è necessario solo un team ridotto di crittografi per implementare e gestire adeguatamente questo codice rigidamente controllato e revisionato.

Introduzione

Per molti utenti e aziende, la sicurezza è un fattore decisivo nella scelta di un fornitore di servizi per il cloud pubblico. Per Google la sicurezza è un tema di fondamentale importanza. Trattiamo la sicurezza e la privacy con la massima serietà e lavoriamo instancabilmente per proteggere i tuoi dati, che siano in viaggio su Internet, in movimento tra i nostri data center o archiviati nei nostri server.

Un elemento centrale della nostra strategia di sicurezza completa è la crittografia dei dati in transito e inattivi, che garantisce che solo i ruoli e i servizi autorizzati con accesso controllato alle chiavi di crittografia possano accedere ai dati. Il presente articolo descrive l'approccio di Google alla crittografia dei dati inattivi per Google Cloud Platform e il modo in cui viene utilizzata da Google per proteggere maggiormente i tuoi dati.

Questo documento è rivolto ai CISO e ai team per le operazioni di sicurezza che attualmente utilizzano o stanno pensando di utilizzare Google Cloud Platform. Ad eccezione dell'introduzione, il presente documento presume una conoscenza di base delle primitive crittografiche e della crittografia.

Che cos'è la crittografia

La crittografia è un processo che prende come input i dati leggibili (spesso chiamati testo non crittografato) e li trasforma in un output (detto spesso testo crittografato) che rivela poche o nessuna informazione sul testo non crittografato. L'algoritmo di crittografia utilizzato è pubblico, ad esempio l'Advanced Encryption Standard (AES), ma l'esecuzione dipende da una chiave, che viene mantenuta segreta. Per decriptare il testo crittografato e riportarlo alla forma originale, è necessario utilizzare la chiave. In Google, l'utilizzo della crittografia per garantire la riservatezza dei dati è generalmente combinato con la protezione dell'integrità; chi accede al testo crittografato non può comprenderlo e nemmeno modificarlo senza conoscere la chiave. Per ulteriori informazioni sulla crittografia, una valida risorsa è il libro Introduction to Modern Cryptography.

Il presente white paper si concentra sulla crittografia dei dati inattivi. Con l'espressione crittografia dei dati inattivi si intende la crittografia utilizzata per proteggere i dati archiviati su un disco (incluse le unità a stato solido o SSD) o su supporti di backup.

Perché la crittografia aiuta a proteggere i dati dei clienti

La crittografia è un tassello di una strategia di protezione più ampia, che aggiunge un livello di difesa in profondità per la protezione dei dati. Nel caso in cui i dati finiscano accidentalmente nelle mani di un utente malintenzionato, la crittografia garantisce che tale utente non vi possa accedere senza avere accesso anche alle chiavi di crittografia. Anche se un utente malintenzionato ottiene i dispositivi di archiviazione contenenti i tuoi dati, non potrà comprenderli o decriptarli.

La crittografia dei dati inattivi riduce la superficie di attacco escludendo efficacemente i livelli più bassi degli stack hardware e software. Anche se i livelli più bassi vengono compromessi (ad esempio, tramite accesso fisico ai dispositivi), i dati nei dispositivi non vengono messi a rischio se viene implementata una crittografia adeguata. La crittografia agisce anche da "collo di bottiglia": le chiavi di crittografia gestite centralmente creano un'unica posizione in cui si impone l'obbligo di accesso ai dati e da cui è possibile controllare tutti gli accessi.

La crittografia fornisce un meccanismo importante per quanto riguarda le modalità con cui Google assicura la privacy dei dati dei clienti. Consente ai sistemi di manipolare i dati, ad esempio per il backup, e agli ingegneri di supportare la nostra infrastruttura, senza concedere accesso ai contenuti.

La nostra definizione di dati dei clienti

Secondo la definizione presente nei Termini di servizio di Google Cloud Platform, il termine dati dei clienti si riferisce ai contenuti forniti a Google da un cliente di Google Cloud Platform (o sotto la sua direzione), direttamente o indirettamente, tramite i servizi Google Cloud Platform utilizzati dall'account del cliente. I dati dei clienti includono i contenuti dei clienti e i metadati dei clienti.

I contenuti dei clienti sono i dati generati dai clienti di Google Cloud Platform o forniti dai clienti a Google, ad esempio i dati archiviati in Google Cloud Storage, snapshot di dischi utilizzati da Google Compute Engine e criteri Cloud IAM. La crittografia dei contenuti inattivi dei clienti è l'aspetto su cui si concentra il presente white paper.

I metadati dei clienti costituiscono la parte restante dei dati dei clienti e si riferiscono a tutti i dati che non possono essere classificati come contenuti dei clienti. Possono essere inclusi numeri di progetto generati automaticamente, timestamp e indirizzi IP, così come le dimensioni in byte di un oggetto in Google Cloud Storage o il tipo di macchina in Google Compute Engine. Ai metadati viene fornito un grado di protezione ragionevole per garantire prestazioni costanti e continuità delle operazioni.

La crittografia predefinita di Google

Crittografia dei dati inattivi

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.

Grafico dei livelli di crittografia

Figura 1: per proteggere i dati archiviati in Google Cloud Platform vengono utilizzati diversi livelli di crittografia. La crittografia dei file system distribuiti o a livello di archiviazione di file e database, così come la crittografia dei dispositivi di archiviazione, è applicata a quasi tutti i file.

Crittografia a livello di sistema di archiviazione

Per capire il funzionamento specifico della crittografia di Google Cloud Storage, è importante comprendere in che modo Google archivia i dati dei clienti. I dati sono suddivisi in blocchi di sottofile per l'archiviazione e le dimensioni di ogni singolo blocco possono arrivare a diversi GB. Ogni blocco viene criptato a livello di archiviazione con una chiave di crittografia individuale: due blocchi non avranno la stessa chiave di crittografia, anche se fanno parte dello stesso oggetto di Google Cloud Storage, appartengono allo stesso cliente o sono archiviati sulla stessa macchina1. Se un blocco di dati viene aggiornato, viene criptato con una nuova chiave, non viene riutilizzata la chiave esistente. Il partizionamento dei dati, con l'utilizzo di una chiave diversa per ogni partizione, implica che il "raggio di esplosione" della potenziale compromissione di una chiave di crittografia dei dati è limitato soltanto a un blocco di dati.

Google cripta i dati prima che vengano scritti su disco. La crittografia è integrata in tutti i sistemi di archiviazione di Google, non viene aggiunta in un secondo momento.

Ogni blocco di dati ha un identificatore univoco. Gli elenchi di controllo di accesso (ACL) assicurano che ogni blocco possa essere decriptato solo dai servizi Google operanti nei ruoli autorizzati, a cui viene concesso l'accesso in quel momento. In questo modo viene impedito l'accesso ai dati senza autorizzazione, potenziando la privacy e la sicurezza dei dati.

Ogni blocco viene distribuito nei sistemi di archiviazione di Google e viene replicato in formato criptato a fini di backup e ripristino di emergenza. Un utente malintenzionato che volesse accedere ai dati dei clienti dovrebbe conoscere ed essere in grado di accedere a (1) tutti i blocchi di archiviazione corrispondenti ai dati desiderati e (2) alle chiavi di crittografia corrispondenti ai blocchi.

Diagramma dei dati memorizzati in blocchi criptati

Figura 2: in Google i dati vengono suddivisi in blocchi criptati per l'archiviazione.

Google utilizza l'algoritmo Advanced Encryption Standard (AES) per criptare i dati inattivi. L'algoritmo AES è di uso comune perché (1) gli algoritmi AES256 e AES128 sono consigliati dal National Institute of Standards and Technology (NIST) per l'archiviazione a lungo termine (ad oggi, marzo 2019) e (2) l'algoritmo AES è spesso incluso nei requisiti di conformità dei clienti.

I dati archiviati in Google Cloud Storage vengono criptati a livello di archiviazione tramite l'algoritmo AES, nella maggior parte dei casi in modalità GCM (Galois/Counter Mode). L'algoritmo viene implementato nella libreria BoringSSL gestita da Google. Questa libreria è stata divisa da OpenSSL per uso interno, in seguito all'esposizione di numerosi difetti in OpenSSL. In alcuni casi selezionati, l'algoritmo AES viene utilizzato in modalità CBC (Cipher Block Chaining) con un codice HMAC (Hashed Message Authentication Code) per l'autenticazione. Per alcuni file replicati l'algoritmo AES viene utilizzato in modalità Counter (CTR) con un codice HMAC. Ulteriori dettagli sugli algoritmi vengono forniti successivamente nel presente documento. L'algoritmo AES viene utilizzato in diversi modi in altri prodotti Google Cloud Platform.

Crittografia a livello di dispositivo di archiviazione

Oltre alla crittografia a livello di sistema di archiviazione descritta nel paragrafo precedente, nella maggior parte dei casi i dati vengono criptati anche a livello di dispositivo di archiviazione, con almeno l'algoritmo AES128 per i dischi rigidi (HDD) e l'algoritmo AES256 per le nuove 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). Quando i dispositivi meno recenti vengono sostituiti, per la crittografia a livello di dispositivo sarà utilizzato esclusivamente l'algoritmo AES256.

Crittografia dei backup

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

Il sistema di backup inoltre cripta ulteriormente ogni file di backup in modo indipendente, ognuno con una chiave di crittografia dei dati (DEK) derivante da una chiave archiviata nel Key Management Service (KMS) di Google e un seed generato in modo casuale al momento del backup diverso per ogni file. Durante i backup, per tutti i metadati viene utilizzata un'altra DEK, archiviata anch'essa nel KMS di Google. Ulteriori informazioni sulla gestione delle chiavi vengono fornite in una sezione successiva.

Esistono casi in cui i dati inattivi non vengono criptati?

Google Cloud Platform utilizza uno o più meccanismi di crittografia per criptare i contenuti archiviati inattivi dei clienti, senza che sia richiesta alcuna azione da parte loro, ad eccezione dei seguenti casi.

  • Log di console seriali provenienti da macchine virtuali in Google Compute Engine. Questo caso è in via di risoluzione.
  • Core dump scritti in unità locali, se si verifica un errore imprevisto nel processo. Questo caso è in via di risoluzione.
  • Log di debug scritti in un disco locale. Questo caso è in via di risoluzione.
  • File temporanei utilizzati dai sistemi di archiviazione. Questo caso è in via di risoluzione.
  • Alcuni log che potrebbero includere contenuti dei clienti, così come metadati dei clienti. La risoluzione di questo caso è stata pianificata.

Questi dati sono comunque ampiamente protetti dal resto dell'infrastruttura di sicurezza di Google e nella maggior parte dei casi sono comunque protetti dalla crittografia a livello di archiviazione.

Gestione delle chiavi

Chiavi di crittografia dei dati, chiavi di crittografia della chiave e Key Management Service di Google

La chiave utilizzata per criptare i dati in un blocco è chiamata chiave di crittografia dei dati (DEK). A causa dell'elevato volume di chiavi utilizzate da Google e della necessità di mantenere una bassa latenza e un'alta disponibilità, queste chiavi vengono archiviate vicino ai dati che devono criptare. Le DEK sono a loro volta criptate (sottoposte a wrapping) con una chiave di crittografia della chiave (KEK). Per ogni servizio di Google Cloud Platform è previsto l'utilizzo di una o più chiavi KEK. Le KEK sono archiviate a livello centrale nel Key Management Service (KMS) di Google, un repository creato appositamente per l'archiviazione delle chiavi. La presenza di un numero inferiore di KEK rispetto alle DEK e l'utilizzo di un servizio di gestione delle chiavi centralizzato rendono l'archiviazione e la crittografia dei dati gestibili su scala Google, oltre a consentire di monitorare e controllare l'accesso ai dati da una posizione centrale.

Per ogni cliente di Google Cloud Platform, tutte le risorse non condivise2 vengono ripartite in blocchi di dati e criptate con chiavi distinte da quelle utilizzate per altri clienti3. Le DEK sono distinte anche da quelle che proteggono altre porzioni degli stessi dati appartenenti allo stesso cliente.

Le DEK sono generate dal sistema di archiviazione tramite la libreria crittografica comune di Google. Dopo essere state inviate al KMS per essere criptate con la KEK del sistema di archiviazione, 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 al KMS. Il KMS verifica che il servizio sia autorizzato a utilizzare la KEK e, in caso positivo, la decripta e restituisce al servizio la DEK in testo non crittografato. In seguito il servizio utilizza la DEK per decriptare il blocco di dati, trasformarlo in testo non crittografato e verificarne l'integrità.

La maggior parte delle KEK per la crittografia dei blocchi di dati viene generata all'interno del KMS, 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 con algoritmo AES2564. L'RNG ha origine dall'RNG del kernel Linux, che a sua volta deriva da varie origini entropiche indipendenti. Sono inclusi eventi entropici provenienti dall'ambiente del data center, tra cui misurazioni granulari del numero di operazioni di ricerca su disco e dei tempi di arrivo tra pacchetti, così come l'istruzione RDRAND di Intel, se disponibile (su Ivy Bridge e CPU più recenti).

I dati archiviati in Google Cloud Platform vengono criptati con le DEK utilizzando gli algoritmi AES256 o AES128, come descritto precedentemente. Per la crittografia di tutti i nuovi dati criptati su dischi permanenti in Google Compute Engine viene utilizzato l'algoritmo AES256. Le DEK vengono criptate con le KEK utilizzando gli algoritmi AES256 o AES128, a seconda del servizio Google Cloud Platform. Attualmente stiamo lavorando per eseguire l'upgrade di tutte le KEK per i servizi Cloud all'algoritmo AES256.

Il KMS di Google gestisce le KEK ed è stato creato esclusivamente per questo scopo, con particolare attenzione alla sicurezza. Le KEK sono state progettate per non poter essere esportate dal KMS di Google; tutte le operazioni di crittografia e decriptazione con queste chiavi devono essere svolte nel KMS. Tale misura contribuisce a evitare fughe di dati e usi impropri e consente al KMS di emettere un audit trail quando le chiavi vengono utilizzate.

Il KMS 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 per la decriptazione, il cui numero è determinato dalla pianificazione di rotazione delle chiavi. L'attuale pianificazione di rotazione delle KEK varia in base al servizio, tuttavia il periodo di rotazione standard è di 90 giorni. Google Cloud Storage in particolare ruota le KEK ogni 90 giorni e può archiviare fino a 20 versioni, richiedendo una nuova crittografia dei dati almeno una volta ogni 5 anni, anche se, nella pratica, le nuove crittografie dei dati vengono effettuate molto più spesso. Le chiavi conservate nel KMS vengono sottoposte a backup a scopo di ripristino di emergenza e possono essere recuperate in modo illimitato.

Per ogni chiave, l'utilizzo delle KEK è gestito tramite gli elenchi di controllo di accesso (ACL) nel KMS, con un criterio diverso per ogni 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 in un log. Tutti gli accessi ai dati da parte di utenti umani sono controllabili nell'ambito delle norme sulla privacy e dei criteri di sicurezza globali di Google.

Ecco cosa accade quando un servizio di Google Cloud Platform accede a un blocco di dati criptato:

  1. Il servizio effettua una chiamata al sistema di archiviazione dei 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 archiviata con il blocco (in alcuni casi, questa operazione viene eseguita dal servizio) e la invia al KMS per farla decriptare.
  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 tramite l'ID blocco; il KMS inoltre verifica che il sistema di archiviazione sia autorizzato a utilizzare la KEK associata al servizio e a decriptare quella specifica DEK.
  5. Il KMS svolge una delle seguenti azioni:
    • Restituisce la DEK decriptata al sistema di archiviazione, che decripta il blocco di dati e lo passa al servizio. In alternativa, in alcuni rari casi:
    • Passa la DEK decriptata 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.

Diagramma della decriptazione del blocco di dati

Figura 3: per decriptare un blocco di dati, il servizio di archiviazione effettua una chiamata al Key Management Service (KMS) di Google per recuperare la chiave di crittografia dei dati (DEK) decriptata del blocco di dati.

Gerarchia delle chiavi di crittografia e radice di attendibilità

Il KMS di Google è protetto da una chiave radice, chiamata chiave master del KMS, che esegue il wrapping di tutte le KEK nel KMS. La chiave master del KMS utilizza l'algoritmo AES2564 ed è archiviata a sua volta in un altro Key Management Service chiamato KMS radice. Nel KMS radice è archiviato un numero di chiavi molto più ridotto, circa una dozzina. Per ulteriore sicurezza, il KMS radice non viene eseguito su macchine di produzione generali, bensì solo su macchine dedicate in ogni data center di Google.

Il KMS radice ha a sua volta una propria chiave radice, chiamata chiave master del KMS radice, che utilizza anch'essa l'algoritmo AES2564 ed è archiviata in un'infrastruttura peer-to-peer, il distributore di chiavi master del KMS radice, che replica queste chiavi a livello globale. Il distributore di chiavi master del KMS radice conserva le chiavi solo sulla RAM delle stesse macchine dedicate del KMS radice e utilizza il logging per verificare l'utilizzo corretto. Viene eseguita un'istanza del distributore di chiavi master del KMS radice per ogni istanza del KMS radice. Il distributore di chiavi master del KMS radice è ancora in fase di inserimento graduale, in sostituzione di un sistema che operava in modo simile ma che non era peer-to-peer.

Quando viene avviata una nuova istanza del distributore di chiavi master del KMS radice, tale istanza viene configurata con un elenco di nomi host su cui sono già in esecuzione istanze del distributore. Le istanze del distributore possono quindi ottenere la chiave master del KMS radice dalle altre istanze in esecuzione. Diversamente dai meccanismi di ripristino di emergenza descritti successivamente, la chiave master del KMS 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 KMS radice vengono riavviate simultaneamente, il backup della chiave master del KMS radice viene effettuato anche su dispositivi hardware protetti conservati in casseforti fisiche in aree a protezione elevata in due sedi Google globali separate fisicamente. Il backup sarebbe necessario solo se tutte le istanze del distributore si spegnessero contemporaneamente, ad esempio nel caso di un riavvio globale. Meno di 20 dipendenti di Google sono autorizzati ad accedere alle casseforti.

Diagramma della gerarchia di crittografia di Google

Figura 4: la gerarchia delle chiavi di crittografia protegge un blocco di dati con una DEK, criptata con una KEK nel KMS, che a sua volta è protetta dal KMS radice e dal distributore di chiavi master del KMS radice.

In sintesi:

  • I dati vengono divisi in blocchi e criptati con DEK
  • Le DEK vengono criptate con KEK
  • Le KEK sono archiviate nel KMS
  • Il KMS viene eseguito su più macchine nei data center a livello globale
    • Le chiavi del KMS sono criptate con la chiave master del KMS, archiviata nel KMS radice
  • Il KMS radice ha dimensioni ridotte rispetto al KMS e viene eseguito solo su macchine dedicate in ciascun data center
    • Le chiavi del KMS radice sono criptate con la chiave master del KMS radice, archiviata nel distributore di chiavi master del KMS radice
  • Il distributore di chiavi master del KMS radice è un'infrastruttura peer-to-peer che viene eseguita simultaneamente sulla RAM di macchine dedicate a livello globale; ognuna riceve il materiale relativo alle chiavi da altre istanze in esecuzione
    • Nel caso in cui tutte le istanze del distributore si spengano (arresto globale), una chiave master è archiviata in (diversi) hardware protetti in casseforti (fisiche) in alcune sedi di Google
    • Il distributore di chiavi master del KMS radice attualmente è in fase di inserimento graduale, in sostituzione di un sistema che operava in modo simile ma che non era peer-to-peer

Replica e disponibilità a livello globale

L'alta disponibilità, la bassa latenza e l'accesso globale alle chiavi sono fattori essenziali a ogni livello; queste caratteristiche sono necessarie per poter utilizzare i servizi di gestione delle chiavi in Google.

Per questo motivo, il KMS è a scalabilità elevata e viene replicato migliaia di volte nei data center di Google di tutto il mondo. Viene eseguito su macchine normali nel parco produzione di Google e le istanze del KMS vengono eseguite a livello globale per supportare le operazioni di Google Cloud Platform. Di conseguenza, la latenza di ogni singola operazione relativa alle chiavi è estremamente ridotta.

Il KMS radice viene eseguito su varie macchine dedicate alle operazioni di sicurezza in ciascun data center. Il distributore di chiavi master del KMS radice viene eseguito sulle stesse macchine, one-to-one con il KMS radice. Il distributore di chiavi master del KMS radice fornisce un meccanismo di distribuzione tramite 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 della chiave. Con questo modello, non esiste un nodo centrale da cui dipende l'intera infrastruttura di Google. Ciò consente a Google di gestire e proteggere il materiale relativo alle chiavi con alta disponibilità.

Libreria crittografica comune di Google

La libreria crittografica comune di Google è Tink5, che implementa gli algoritmi crittografici utilizzando BoringSSL6. Tink è disponibile per tutti gli sviluppatori di Google. Dato che la libreria comune è ampiamente accessibile, è necessario solo un team ridotto di crittografi per implementare adeguatamente questo codice rigidamente controllato e revisionato. Non è necessario che ogni team di Google crei il proprio sistema di crittografia. Un team speciale di Google per la sicurezza ha la responsabilità di gestire la 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 revisionati regolarmente per garantire che siano aggiornati sugli attacchi più recenti.

Al momento della pubblicazione del presente documento, Google utilizza i seguenti algoritmi crittografici basati sulle chiavi DEK e KEK per la crittografia dei dati inattivi. 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 supportati7
Crittografia simmetrica
  • AES-GCM (256 bit)
  • AES-CBC e AES-CTR (128 e 256 bit)
  • AES-EAX (128 e 256 bit)
Firme simmetriche (quando utilizzate con i protocolli AES-CBC e AES-CTR riportati sopra per l'autenticazione)
  • HMAC-SHA256
  • HMAC-SHA512
  • HMAC-SHA1

Granularità della crittografia in ogni prodotto Google Cloud Platform

Ogni servizio Google Cloud Platform divide i dati a un diverso livello di granularità per la crittografia.

  Servizio Google Cloud Platform Granularità della crittografia dei dati dei clienti8 (dimensioni dei dati criptati con una singola DEK)
Archiviazione Cloud Bigtable Per blocco di dati (diversi per tabella)
Cloud Datastore Per blocco di dati9
Cloud Firestore Per blocco di dati9
Cloud Spanner Per blocco di dati (diversi per tabella)
Cloud SQL
  • Seconda generazione: per istanza, come in Google Compute Engine (ogni istanza può contenere più database)
  • Prima generazione: per istanza
Cloud Storage Per blocco di dati (in genere da 256 kB a 8 MB)
Computing App Engine10 Per blocco di dati9
Cloud Functions11 Per blocco di dati9
Compute Engine
  • Vari per disco
  • Per gruppo di snapshot; i singoli intervalli di snapshot derivano dalla chiave master del gruppo di snapshot
  • Per immagine
Kubernetes Engine Diversi per disco, per i dischi permanenti
Container Registry Archiviazione in Google Cloud Storage, per blocco di dati
Big data BigQuery Diversi per set di dati
Cloud Dataflow Archiviazione in Google Cloud Storage, per blocco di dati
Cloud Datalab Archiviazione in Cloud Bigtable, per file blocco note
Cloud Dataproc Archiviazione in Google Cloud Storage, per blocco di dati
Cloud Pub/Sub Rotazione ogni 30 giorni9

Ulteriori opzioni di crittografia per i clienti di Cloud

In Google Cloud Platform, oltre a fornire la crittografia per impostazione predefinita, stiamo lavorando per offrire ai clienti ulteriori opzioni di crittografia e gestione delle chiavi per un maggiore controllo.

Vogliamo consentire ai clienti di Google Cloud Platform di:

  • Rimanere i custodi ultimi dei propri dati ed essere in grado di controllare l'accesso e l'utilizzo dei dati al massimo livello di granularità, per garantire la privacy e la sicurezza dei dati
  • Gestire la crittografia dei dati ospitati sul cloud nello stesso modo utilizzato al momento on-premise, o persino meglio
  • Stabilire una radice di attendibilità dimostrabile e controllabile per le proprie risorse
  • Essere in grado di separare e isolare ulteriormente i dati, anche senza utilizzare gli ACL

I clienti possono utilizzare le chiavi di crittografia esistenti che gestiscono con Google Cloud Platform tramite la funzionalità Chiavi di crittografia fornite dal cliente. Questa funzionalità è disponibile per Google Cloud Storage e per Google Compute Engine per la crittografia a livello di archiviazione.

Su Google Cloud Platform i clienti possono gestire le proprie chiavi di crittografia anche utilizzando il Google Cloud Key Management Service (Cloud KMS). Questo prodotto consente ai clienti di gestire la crittografia a livello di applicazione.

Ricerca e innovazione nel campo della crittografia

Per stare al passo con l'evoluzione della crittografia, Google dispone di 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. Pubblichiamo regolarmente le nostre ricerche nel campo della crittografia in modo che tutto il settore, incluso il pubblico generale, possa beneficiare delle nostre conoscenze. Ad esempio, nel 2014 abbiamo rivelato una significativa vulnerabilità nella crittografia SSL 3.0 (nota come POODLE) e nel 2015 abbiamo individuato una vulnerabilità ad alto rischio in OpenSSL.

Google intende rimanere leader del settore della crittografia per i servizi cloud. In termini di sviluppo, implementazione e ricerca di nuove tecniche crittografiche, disponiamo di team che lavorano sui seguenti tipi di crittografia:

  • Crittografia parzialmente omomorfica, che consente lo svolgimento di alcune operazioni sui dati criptati, in modo che il cloud non visualizzi mai i dati in testo non crittografato, anche in memoria. Questa tecnologia attualmente è utilizzata nella versione sperimentale criptata del client BigQuery, disponibile pubblicamente.
  • Crittografia con protezione del formato e dell'ordine, che consente lo svolgimento di alcune operazioni di ranking e confronto sui dati criptati.
  • Crittografia post-quantistica, che ci consente di sostituire le primitive di crittografia esistenti vulnerabili agli efficienti attacchi quantistici con candidati post-quantistici, considerati più solidi contro questo genere di attacchi. L'obiettivo principale è effettuare ricerche e creare prototipi di crittografia a chiave pubblica basata su reticoli, includendo i consigli del NIST sugli algoritmi post-quantistici. Attualmente la crittografia basata su reticoli è considerata una delle tecniche di crittografia più idonee in un contesto post-quantistico, anche se siamo ancora agli inizi in termini di individuazione degli algoritmi, dei parametri concreti e dei metodi di crittoanalisi più efficaci per l'applicazione della crittografia basata su reticoli. Anche se la crittografia a chiave simmetrica e i MAC sono indeboliti dagli algoritmi quantistici noti, in un contesto post-quantistico è sempre possibile un upgrade a bit di sicurezza simili raddoppiando le dimensioni delle chiavi.

Ulteriori riferimenti

Sicurezza di Google Cloud Platform

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

Conformità di Google Cloud Platform

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

Sicurezza di G Suite

Per informazioni sulla gestione delle chiavi e della crittografia in G Suite, consulta il white paper sulla crittografia di G Suite. Il white paper copre molti contenuti inclusi nel presente documento, ma si concentra esclusivamente su G Suite. Per tutte le soluzioni G Suite, ci impegniamo per mantenere protetti i dati dei clienti e per essere il più trasparenti possibile riguardo al modo in cui li proteggiamo. Ulteriori informazioni sulla sicurezza generale di G Suite sono disponibili nel white paper sulla sicurezza e la conformità di G Suite.

Note a piè di pagina

1 Un blocco di dati in Cloud Datastore, App Engine e Cloud Pub/Sub può contenere dati di vari clienti. Consulta la sezione sulla granularità della crittografia dei dati per servizio.
2 Un esempio di risorsa condivisa (per cui l'isolamento non si applica) potrebbe essere un'immagine di base condivisa in Google Compute Engine. Naturalmente, più clienti fanno riferimento a una singola copia, criptata con una singola DEK.
3 Fanno eccezione i dati archiviati in Cloud Datastore, App Engine e Cloud Pub/Sub, dove i dati di più clienti potrebbero essere criptati con la stessa DEK. Consulta la sezione sulla granularità della crittografia dei dati per servizio.
4 Tieni presente che in passato l'algoritmo era AES128 e alcune di queste chiavi rimangono attive per decriptare i dati.
5 Google utilizza anche due librerie: Keymaster e CrunchyCrypt. 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. CrunchyCrypt è stato unito a Tink.
6 In alcuni punti di Google Cloud Storage viene utilizzata anche la libreria OpenSSL.
7 Nella libreria sono presenti altri protocolli di crittografia supportati in passato; tuttavia, questo elenco include i principali utilizzi in Google Cloud Platform.
8 Si riferisce alla granularità della crittografia per i contenuti dei clienti. Non sono inclusi i metadati dei clienti, ad esempio i nomi delle risorse. In alcuni servizi, tutti i metadati sono criptati con una singola DEK.
9 Non univoca per singolo cliente.
10 Sono inclusi il codice e le impostazioni dell'applicazione. I dati utilizzati in App Engine vengono archiviati in Cloud Datastore, Cloud SQL o Cloud Storage, a seconda delle configurazioni del cliente.
11 Sono inclusi i dati degli eventi, le impostazioni e il codice delle funzioni. I dati degli eventi vengono archiviati in Cloud Pub/Sub.
Hai trovato utile questa pagina? Facci sapere cosa ne pensi:

Invia feedback per...