Questi contenuti sono stati aggiornati l'ultima volta a settembre 2022 e rappresentano lo status quo del momento in cui sono stati redatti. Criteri e sistemi di sicurezza di Google possono variare in futuro, grazie al 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 contenuti dei clienti da utenti malintenzionati. Criptiamo tutti i contenuti at-rest dei clienti Google, senza che sia richiesta alcuna azione da parte tua, utilizzando uno o più meccanismi di crittografia. Questo documento descrive il nostro approccio alla crittografia at-rest per impostazione predefinita per l'infrastruttura di Google e Google Cloud e il modo in cui la utilizziamo per proteggere maggiormente i dati dei clienti.
Questo documento è rivolto 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 è la crittografia utilizzata per proteggere i dati archiviati su un disco (incluse le unità a stato solido) o su un supporto di backup. Tutti i dati archiviati da Google vengono criptati a livello di archiviazione utilizzando l'algoritmo AES (Advanced Encryption Standard), AES-256. Utilizziamo Tink, una libreria crittografica comune, che include il nostro modulo convalidato FIPS 140-2 (denominato BoringCrypto) per implementare la crittografia in modo coerente su Google Cloud.
Gestiamo le chiavi utilizzate nella crittografia at-rest predefinita. Se utilizzi Google Cloud, Cloud Key Management Service ti consente di creare chiavi di crittografia personalizzate da utilizzare per aggiungere la crittografia envelope ai tuoi dati. Con Cloud KMS, puoi creare, ruotare, monitorare ed eliminare chiavi. Per ulteriori informazioni, consulta l'approfondimento su Cloud Key Management Service.
In che modo la crittografia at-rest contribuisce a proteggere i dati
La crittografia at-rest è un pezzo 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 utente malintenzionato, quest'ultimo non possa leggerli senza avere accesso anche alle chiavi di crittografia. Anche se i malintenzionati acquisiscono i dispositivi di archiviazione che contengono i dati dei clienti, non saranno in grado di comprenderli o decriptarli.
- Contribuisce a ridurre la superficie di attacco tagliando i livelli inferiori dello stack hardware e software.
- Funziona come un punto di passaggio, perché le chiavi di crittografia gestite centralmente creano un'unica posizione in cui è applicato in modo forzato l'accesso ai dati e in cui è possibile controllare l'accesso.
- 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 sono crittografati at-rest, limita l'accesso ai dati che i sistemi e gli ingegneri hanno
Cosa sono i dati dei clienti?
Secondo la definizione dei Termini di servizio di Google Cloud, i dati dei clienti sono i dati che clienti o utenti finali forniscono a Google tramite i servizi nel proprio account. I dati dei clienti includono i loro contenuti e i metadati.
I contenuti dei clienti sono dati generati da te o da te forniti, come i dati archiviati in Cloud Storage, gli snapshot dei dischi utilizzati da Compute Engine e i criteri IAM. Questo documento è incentrato sulla crittografia at-rest predefinita per i contenuti dei clienti.
I metadati dei clienti costituiscono il resto dei dati. I metadati dei clienti potrebbero includere numeri di progetto generati automaticamente, timestamp, indirizzi IP, le dimensioni in byte di un oggetto in Cloud Storage o il tipo di macchina in Compute Engine. I metadati sono protetti in una misura ragionevole per garantire prestazioni e operazioni continue.
Crittografia predefinita dei dati at-rest
Google utilizza uno o più meccanismi di crittografia per criptare tutti i contenuti dei clienti archiviati at-rest, senza che sia necessario alcun intervento da parte tua. Le seguenti sezioni descrivono i meccanismi che utilizziamo per criptare i contenuti dei clienti.
Livelli di crittografia
Google utilizza diversi livelli di crittografia per proteggere i dati. L'utilizzo di più livelli di crittografia aggiunge una protezione dei dati ridondante e ci consente di selezionare l'approccio ottimale in base ai requisiti dell'applicazione.
Il seguente diagramma mostra i diversi livelli di crittografia generalmente utilizzati per proteggere i dati utente nei data center di produzione di Google. La crittografia dei file system distribuiti o l'archiviazione di database e file viene applicata per tutti i dati utente e la crittografia dei dispositivi di archiviazione viene applicata per tutti i dati nei data center di produzione di Google.
Crittografia a livello di hardware e infrastruttura
Tutti i sistemi di archiviazione di Google utilizzano un'architettura di crittografia simile, anche se i dettagli di implementazione variano da sistema a sistema. I dati sono suddivisi in blocchi di sottofile per l'archiviazione; ogni blocco può avere una dimensione massima di diversi gigabyte. Ogni blocco viene criptato a livello di archiviazione con una singola chiave di crittografia dei dati (DEK): due blocchi non avranno la stessa DEK, anche se sono di proprietà dello stesso cliente o archiviati sulla stessa macchina. Un blocco di dati in Datastore, App Engine e Pub/Sub potrebbe contenere i dati di più clienti.
Se un blocco di dati viene aggiornato, viene criptato con una nuova chiave anziché riutilizzare la chiave esistente. Questo partizionamento dei dati, utilizzando ognuno una chiave diversa, limita il rischio di compromissione della chiave di crittografia dei dati solo per 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 in tutti i nostri sistemi di archiviazione, anziché essere aggiunta in un secondo momento.
Ogni blocco di dati ha un identificatore univoco. Gli elenchi di controllo dell'accesso (ACL) aiutano ad assicurare 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 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 in formato criptato a fini di backup e ripristino di emergenza. Un utente malintenzionato che vuole accedere ai dati dei clienti dovrebbe sapere ed essere in grado di 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.
Per criptare i dati at-rest, utilizziamo l'algoritmo AES. Tutti i dati a livello di archiviazione sono criptati dalle DEK, che utilizzano l'algoritmo AES-256 per impostazione predefinita, ad eccezione di un piccolo numero di dischi permanenti creati prima del 2015 con 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 dell'archiviazione a lungo termine e spesso è incluso nei requisiti di conformità dei clienti.
Crittografia a livello di dispositivo di archiviazione
Oltre alla crittografia a livello di sistema di archiviazione, i dati vengono criptati anche a livello di dispositivo di archiviazione con l'algoritmo AES-256 per le unità disco rigido (HDD) e le unità a stato solido (SSD), mediante 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 l'algoritmo AES-128. Le unità SSD utilizzate da Google implementano l'algoritmo AES-256 esclusivamente per i dati utente.
Crittografia dei backup
Il nostro sistema di backup garantisce che i dati rimangano criptati durante il processo di backup. Questo approccio evita esposizioni non necessarie dei dati del testo non crittografato.
Inoltre, il sistema di backup cripta ulteriormente la maggior parte dei file di backup in modo indipendente con la propria DEK. La DEK deriva da una chiave archiviata nell'archivio chiavi e da un seed per file generato casualmente al momento del backup. Nei backup viene utilizzata un'altra DEK, archiviata nell'archivio chiavi, per tutti i metadati.
Conformità FIPS per dati inattivi
Google utilizza un modulo di crittografia convalidato FIPS 140-2 (certificato 4407) nel proprio 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 una disponibilità elevata, le DEK vengono archiviate vicino ai dati che criptano. Le DEK vengono criptate (sottoposte a wrapping) con una chiave di crittografia della chiave (KEK) mediante una tecnica nota come crittografia envelope. Queste KEK non sono specifiche per i clienti; esistono invece una o più KEK per ogni servizio.
Le 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 usare un archivio chiavi centrale rende gestibili l'archiviazione e la crittografia dei dati sulla nostra scala e ci permette di monitorare e controllare l'accesso ai dati da un punto centrale.
In Google Cloud, ogni cliente può disporre di risorse condivise e non condivise. Un esempio di risorsa condivisa è un'immagine di base condivisa in Compute Engine. Per le risorse condivise, più clienti fanno riferimento a una singola copia, criptata da una singola DEK. Le risorse non condivise vengono suddivise in blocchi di dati e criptate con chiavi separate da quelle utilizzate per altri clienti. Queste chiavi sono separate da quelle che proteggono altri dati degli stessi dati di proprietà dello stesso cliente. Le eccezioni sono i dati archiviati in Datastore, App Engine o Pub/Sub, dove i dati di più di un cliente possono essere criptati con la stessa DEK.
Generazione di DEK
Il sistema di archiviazione genera DEK utilizzando la libreria crittografica comune di Google. In generale, le DEK vengono inviate all'archivio chiavi per essere aggregate con la KEK del sistema di archiviazione, mentre 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 con wrapping e la passa all'archivio chiavi. L'archivio chiavi verifica quindi che il servizio sia autorizzato a utilizzare la KEK e, in questo caso, ne annulla il wrapping e restituisce al servizio la DEK in testo non crittografato. Il servizio utilizza quindi la DEK per decriptare il blocco di dati in testo 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 una bassa latenza utilizzando al contempo la KEK di livello più alto (archiviata nell'archivio chiavi) come radice di attendibilità.
Generazione di KEK in corso...
La maggior parte delle KEK per la crittografia dei blocchi di dati viene generata all'interno dell'archivio chiavi, mentre le altre vengono generate all'interno dei servizi di archiviazione. Per coerenza, tutte le KEK vengono generate utilizzando la libreria crittografica comune di Google, utilizzando un generatore di numeri casuali (RNG) creato da Google. L'RNG si basa sulla tecnologia 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.
L'RNG ha origine dall'istruzione RDRAND di Intel e dall'RNG del kernel Linux. A sua volta, l'RNG del kernel Linux ha origine da diverse origini entropiche indipendenti, tra cui RDRAND ed eventi entropici provenienti dall'ambiente del data center (ad esempio misurazioni granulari delle ricerche di dischi e dei tempi di arrivo tra pacchetti).
Le DEK vengono sottoposte a wrapping con le KEK utilizzando AES-256 o AES-128, a seconda del servizio Google Cloud. Attualmente stiamo lavorando per eseguire l'upgrade di tutte le KEK per i servizi Google Cloud all'algoritmo AES-256.
Gestione 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ò contribuisce a prevenire fughe di dati e usi impropri e consente all'archivio chiavi di creare un audit trail quando le chiavi vengono utilizzate.
L'archivio chiavi può ruotare automaticamente le KEK a intervalli di tempo regolari utilizzando la libreria crittografica comune di Google per generare nuove chiavi. Anche se spesso facciamo riferimento a una singola chiave, in realtà intendiamo dire che i dati sono protetti tramite un set di chiavi: una chiave è attiva per la crittografia e un set di chiavi storiche è attivo per la decrittografia. Il numero di chiavi storiche è determinato dalla pianificazione di rotazione della chiave. Le KEK vengono sottoposte a backup a scopo di ripristino di emergenza e possono essere ripristinate in modo continuo.
L'utilizzo delle KEK è gestito dagli ACL nell'archivio chiavi per ogni chiave, con un criterio per singola 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, l'utente viene autenticato e registrato. L'accesso ai dati da parte degli utenti è controllabile nell'ambito delle norme generali di Google sulla sicurezza e sulla privacy.
Processo per l'accesso a blocchi di dati criptati
Quando un servizio Google accede a un blocco di dati criptato, si verifica quanto segue:
- 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 archiviata con quel blocco (in alcuni casi, questa operazione viene eseguita dal servizio) e la invia all'archivio chiavi per l'unwrapping.
- Il sistema di archiviazione verifica che il job identificato sia autorizzato ad accedere al blocco di dati in base a un identificatore job e utilizzando l'ID blocco. L'archivio chiavi verifica che il sistema di archiviazione sia autorizzato a utilizzare la KEK associata al servizio e a annullare il wrapping di quella specifica DEK.
- L'archivio chiavi esegue una delle seguenti operazioni:
- Restituisce la DEK di cui è stato annullato il wrapping al sistema di archiviazione, che decripta il blocco di dati e lo passa al servizio.
- In alcuni rari casi, passa la DEK senza wrapping al servizio. Il sistema di archiviazione passa il blocco di dati criptato al servizio, che lo decripta e lo utilizza.
Questo processo è diverso nei dispositivi di archiviazione dedicati, in cui il dispositivo gestisce e protegge la DEK a livello di dispositivo.
Il seguente diagramma illustra questa procedura. Per decriptare un blocco di dati, il servizio di archiviazione chiama Keystore per recuperare la DEK senza wrapping relativa a 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 esegue il wrapping di tutte le KEK nell'archivio chiavi. La chiave master dell'archivio chiavi è AES-256 ed è archiviata a sua volta in un altro Key Management Service, chiamato archivio chiavi radice. In passato, la chiave master dell'archivio chiavi era AES-128 e alcune di queste chiavi rimangono attive per decriptare i dati. L'archivio chiavi radice archivia un numero molto ridotto di chiavi, circa una dozzina per area geografica. Per maggiore sicurezza, l'archivio chiavi radice non viene eseguito su macchine di produzione generali, ma solo su macchine dedicate in ogni data center di Google.
L'archivio chiavi radice a sua volta ha una propria chiave radice, denominata chiave master dell'archivio chiavi principale, anch'essa AES-256 e archiviata in un'infrastruttura peer-to-peer, chiamata distributore di chiavi master dell'archivio chiavi radice, 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 dell'archivio chiavi radice contiene le chiavi nella RAM solo sulle stesse macchine dedicate dell'archivio chiavi radice e utilizza il logging per verificare l'utilizzo corretto. Viene eseguita un'istanza del distributore di chiavi master dell'archivio chiavi principale per ogni istanza dell'archivio chiavi radice.
Quando viene avviata una nuova istanza del distributore di chiavi master dell'archivio chiavi principale, questa viene configurata con un elenco di nomi host di istanze del distributore già in esecuzione. Le istanze del distributore possono quindi ottenere la chiave master dell'archivio chiavi principale dalle altre istanze in esecuzione. A parte i meccanismi di ripristino di emergenza descritti in Disponibilità e replica globali, la chiave master dell'archivio chiavi radice esiste solo nella RAM su un numero limitato di macchine appositamente protette.
Per risolvere lo scenario in cui tutte le istanze del distributore di chiavi master dell'archivio chiavi radice in una regione si riavviano simultaneamente, viene eseguito il backup anche della chiave master dell'archivio chiavi radice su dispositivi hardware sicuri archiviati in casseforti fisiche in aree ad alta sicurezza in più località con distribuzione geografica. Questo backup è necessario solo se tutte le istanze del distributore in una regione si disattivano contemporaneamente. Meno di 100 dipendenti Google possono accedere a queste casseforti.
Il seguente diagramma mostra la gerarchia delle chiavi di crittografia. La gerarchia delle chiavi di crittografia protegge un blocco di dati con una DEK, sottoposta a wrapping con una KEK nell'archivio chiavi, che a sua volta è protetta dall'archivio chiavi radice e dal distributore di chiavi master dell'archivio chiavi radice.
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ù macchine nei data center di tutto il mondo.
- Le chiavi dell'archivio chiavi vengono sottoposte a wrapping con la chiave master dell'archivio chiavi, archiviata nell'archivio chiavi radice.
- L'archivio chiavi radice è molto più piccolo dell'archivio chiavi e viene eseguito solo su macchine dedicate in ciascun data center.
- Le chiavi dell'archivio chiavi radice vengono sottoposte a wrapping con la chiave master dell'archivio chiavi radice, che è archiviata nel distributore di chiavi master dell'archivio chiavi principale.
- Il distributore di chiavi master dell'archivio chiavi radice è un'infrastruttura peer-to-peer che viene eseguita contemporaneamente su RAM su macchine dedicate a livello globale. Ogni macchina riceve il materiale della chiave da altre istanze in esecuzione nella regione.
- Nel caso in cui tutte le istanze del distributore in una regione vadano in arresto, una chiave master viene archiviata in un hardware protetto diverso in casseforti fisiche in alcune località di Google.
Replica e disponibilità a livello globale
A ogni livello, disponibilità elevata, bassa latenza e accesso globale alle chiavi sono aspetti fondamentali. Queste caratteristiche sono necessarie affinché i servizi di gestione delle chiavi vengano utilizzati 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 di produzione e le istanze dell'archivio chiavi vengono eseguite a livello globale per supportare le operazioni di Google. Di conseguenza, la latenza di ogni singola operazione relativa alle chiavi è molto bassa.
L'archivio chiavi radice 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 queste stesse macchine, one-to-one con l'archivio chiavi radice. Il distributore di chiavi master dell'archivio chiavi radice fornisce un meccanismo di distribuzione che utilizza un protocollo gossip. A un intervallo di tempo fisso, ogni istanza del distributore seleziona un'altra istanza casuale con cui confrontare le chiavi e riconcilia eventuali differenze nelle versioni principali. Con questo modello, non esiste un nodo centrale da cui dipende l'intera infrastruttura. Questo metodo di distribuzione ci consente di mantenere e proteggere il materiale delle chiavi 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. Un uso coerente di una libreria comune significa che solo un piccolo team di crittografi ha bisogno di implementare questo codice rigorosamente controllato e rivisto. In questo modo, ogni team di Google non ha bisogno di sviluppare in modo indipendente la propria crittografia. Un team per la sicurezza speciale di Google è responsabile della gestione di questa libreria crittografica comune per tutti i prodotti.
La libreria di crittografia Tink supporta un'ampia gamma di modalità e tipi di chiavi di crittografia che vengono revisionati regolarmente per garantire che siano aggiornati agli attacchi più recenti.
Attualmente utilizziamo i seguenti algoritmi di crittografia per la crittografia at-rest per le DEK e le KEK. Questi sono soggetti a modifiche man mano che continuiamo a migliorare le nostre funzionalità e la nostra 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 riportati sopra per l'autenticazione) | HMAC-SHA256 |
|
Nella libreria sono presenti altri protocolli crittografici supportati che in passato erano supportati, ma questa tabella illustra i principali utilizzi in Google.
Ricerca e innovazione nel campo della crittografia
Per stare al passo con l'evoluzione della crittografia, disponiamo 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 chiunque, incluso il pubblico, possa trarre vantaggio dalle nostre conoscenze.
Ad esempio, nella ricerca sulla crittografia post-quantistica, lavoriamo nelle seguenti aree:
Standardizzazione: stiamo contribuendo alle continue iniziative di standardizzazione per la crittografia post-quantistica. Abbiamo co-autore di tre proposte di sistemi di crittografia affinché vengano prese in considerazione dal NIST nell'ambito del concorso di standardizzazione della crittografia post-quantistica. Siamo editor dello standard ISO (International Organization for Standardization) per le firme basate su hash di crittografia post-quantistica. Siamo co-editor della bozza dell'Internet Engineering Task Force (IETF) per la codifica JSON per le firme di crittografia post-quantistica.
Abilitazione: di recente abbiamo abilitato diversi algoritmi di crittografia post-quantistica nella nostra libreria crittografica Tink. Si tratta di un codice sperimentale progettato per fornire alla community informazioni sui pro e sui contro di ciascun approccio.
Pubblicazioni: di recente, abbiamo pubblicato il titolo Transizione delle organizzazioni alla crittografia post-quantistica in Nature. Questo documento fornisce una panoramica delle sfide della migrazione della crittografia post-quantistica.
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 Conformità del sito web di Google Cloud, che include il report pubblico di controllo SOC3 di Google.
Per informazioni sulla crittografia e sulla gestione delle chiavi di Google Workspace, consulta l'articolo In che modo Google Workspace utilizza la crittografia per proteggere i tuoi dati, che copre gran parte degli stessi contenuti inclusi qui, ma è incentrato esclusivamente su Google Workspace. Per tutte le soluzioni Google Workspace, ci impegniamo per mantenere protetti i dati dei clienti e per essere il più trasparenti possibile in merito al modo in cui li proteggiamo.
Per informazioni su sicurezza e conformità generali, consulta il Centro risorse per la conformità.