Questi contenuti sono stati aggiornati a maggio 2024 e rappresentano lo status quo al momento della loro redazione. I criteri e i sistemi di sicurezza di Google potranno essere soggetti a modifiche in futuro, come parte del nostro impegno per il miglioramento continuo della protezione dei nostri clienti.
In Google, la nostra strategia di sicurezza completa include crittografia at-rest, che aiuta a proteggere i dati dei clienti dagli aggressori. Criptiamo tutti i contenuti archiviati dei clienti di Google, senza che sia richiesta alcuna azione da parte tua, utilizzando uno o più meccanismi di crittografia. Questo documento descrive il nostro approccio alla crittografia dei dati inattivi 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 è rivolto agli architetti 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 Introduction to Modern Cryptography.
La crittografia dei dati inattivi è 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 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 (chiamato BoringCrypto) per implementare la crittografia in modo coerente in Google Cloud.
Possediamo e gestiamo le chiavi utilizzate nella crittografia at-rest predefinita. Se utilizzi Google Cloud, Cloud Key Management Service ti consente di creare le tue chiavi di crittografia da utilizzare per aggiungere la crittografia dell'involucro ai tuoi dati. Con Cloud KMS, puoi creare, ruotare, monitorare ed eliminare le chiavi. Per saperne di più, consulta Approfondimenti su Cloud Key Management Service.
In che modo crittografia at-rest contribuisce a proteggere i dati
La crittografia at-rest è un tassello di una strategia di sicurezza più ampia. La crittografia offre i seguenti vantaggi:
- Contribuisce ad assicurare che, se i dati finiscono nelle mani di un malintenzionato, questo non possa leggerli senza avere accesso anche alle chiavi di crittografia. Anche se gli utenti malintenzionati 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 più bassi dell'hardware e dello stack software.
- Agisce da collo di bottiglia perché le chiavi di crittografia gestite centralmente creano un unico punto in cui viene applicato l'accesso ai dati e da cui è possibile eseguire controlli.
- 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 privacy per i nostri clienti. Quando i dati sono sottoposti a crittografia a riposo, l'accesso dei sistemi e degli ingegneri ai dati è limitato
Che cosa sono i dati dei clienti?
Come definito nei Termini di servizio di Google Cloud, dati dei clienti sono i dati forniti a Google da clienti o utenti finali tramite i servizi associati al loro account.
I contenuti dei clienti sono i dati che generi o ci fornisci, ad esempio i dati archiviati in bucket Cloud Storage, volumi di Persistent Disk e snapshot dei dischi utilizzati da Compute Engine. Questo documento si concentra sulla crittografia at-rest predefinita per questo tipo di dati dei clienti.
I metadati dei clienti sono dati relativi ai contenuti dei clienti e includono numeri di progetto, timestamp, indirizzi IP, dimensioni in byte di un oggetto in Cloud Storage o il tipo di macchina in Compute Engine generati automaticamente. I metadati dei clienti sono protetti in misura ragionevole per garantire prestazioni e operazioni continue. Questo documento non si concentra sulle protezioni per i metadati.
I contenuti e i metadati dei clienti costituiscono i dati dei clienti.
Crittografia predefinita dei dati at-rest
Google utilizza uno o più meccanismi di crittografia per criptare tutti i contenuti archiviati inattivi dei clienti, senza che sia richiesta alcuna azione da parte loro. Le sezioni seguenti descrivono i meccanismi che utilizziamo per criptare i contenuti dei clienti.
Livelli di crittografia
Google utilizza diversi livelli di crittografia per contribuire a proteggere i dati. L'utilizzo di molteplici livelli di crittografia aggiunge una protezione dei dati ridondante e ci consente di scegliere l'approccio ottimale in base ai requisiti dell'applicazione.
Il seguente diagramma mostra i diversi livelli di crittografia che vengono generalmente utilizzati per proteggere i dati utente nei data center di produzione di Google. La crittografia dei file system distribuiti o a livello di archiviazione di file e database è applicata a tutti i dati degli utenti e la crittografia dei dispositivi di archiviazione è applicata a 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 un sistema all'altro. I dati sono suddivisi in blocchi di sottofile per l'archiviazione e le dimensioni di ogni singolo blocco possono arrivare a diversi gigabyte. 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 sono di proprietà dello stesso cliente o archiviati sulla stessa macchina. Un blocco di dati in Datastore, App Engine e Pub/Sub può contenere i dati di più clienti.
Se un blocco di dati viene aggiornato, viene criptato con una nuova chiave, non viene riutilizzata la chiave esistente. Il partizionamento dei dati, con l'utilizzo di una chiave diversa per ogni partizione, 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 è integrata in tutti i nostri sistemi di archiviazione, non viene aggiunta in un secondo momento.
Ogni blocco di dati ha un identificatore univoco. Gli elenchi di controllo di 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 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 malintenzionato che vuole accedere ai dati dei clienti deve conoscere ed essere in grado di accedere a due elementi: tutti i blocchi di archiviazione corrispondenti ai dati che vuole e tutte le chiavi di crittografia corrispondenti ai blocchi.
Il seguente diagramma mostra come i dati vengono caricati nella nostra infrastruttura e poi suddivisi in blocchi criptati per l'archiviazione.
Utilizziamo l'algoritmo AES per criptare i dati inattivi. Tutti i dati a livello di archiviazione vengono criptati dalle DEK, che utilizzano AES-256 per impostazione predefinita, ad eccezione di un numero ridotto di dischi permanenti creati prima del 2015 che utilizzano AES-128. L'algoritmo AES è di uso comune perché sia AES-256 che AES-128 sono consigliati dal National Institute of Standards and Technology (NIST) per l'archiviazione a lungo termine e l'algoritmo AES è 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 AES-256 per i dischi rigidi (HDD) e le unità a stato solido (SSD), utilizzando una chiave a livello di dispositivo distinta (diversa dalla chiave utilizzata per criptare i dati a livello di archiviazione). Un numero ridotto di HDD legacy utilizza l'algoritmo AES-128. Le unità SSD utilizzate da Google implementano l'algoritmo AES-256 esclusivamente per i dati degli utenti.
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 è ricavata da una chiave archiviata nell'archivio chiavi e da un seme generato in modo casuale per ogni file al momento del backup. Per tutti i metadati dei backup viene utilizzata un'altra DEK, archiviata anch'essa nel Keystore.
Conformità FIPS per dati inattivi
Google utilizza un modulo di crittografia convalidato FIPS 140-2 (certificato 4407) nel nostro ambiente di produzione.
Gestione delle chiavi
A causa dell'elevato volume di chiavi utilizzate da Google e della necessità di mantenere una bassa latenza e un'alta disponibilità, le chiavi DEK vengono archiviate vicino ai dati che devono criptare. Le DEK sono criptate con una chiave di crittografia della chiave (KEK) (sottoposte a wrapping) utilizzando una tecnica nota come crittografia con incapsulamento. Queste chiavi KEK non sono specifiche per i clienti, ma esistono una o più chiavi KEK per ogni servizio.
Queste KEK sono archiviate a livello centrale in Keystore, 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 Keystore centralizzato rendono gestibili l'archiviazione e la crittografia dei dati su larga scala, oltre a consentire di monitorare e controllare l'accesso ai dati da una posizione centrale.
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 diverse da quelle utilizzate per altri clienti. Queste chiavi sono distinte anche da quelle che proteggono altre porzioni degli stessi dati appartenenti allo 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 di DEK
Il sistema di archiviazione genera le DEK utilizzando la libreria crittografica comune di Google. In genere, le DEK vengono inviate al Keystore per essere sottoposte a wrapping con la KEK del sistema di archiviazione e le DEK con wrapping vengono restituite al sistema di archiviazione per essere conservate insieme ai blocchi di dati. Quando un sistema di archiviazione ha bisogno di recuperare i dati criptati, recupera la DEK con wrapping e la invia al Keystore. Il keystore verifica quindi che il servizio sia autorizzato a utilizzare la KEK e, in caso affermativo, ne annulla il wrapping e restituisce al servizio la DEK in testo non criptato. In seguito il servizio utilizza la DEK per decriptare il blocco di dati, trasformarlo 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. In questo modo, i sistemi possono fornire una bassa latenza utilizzando il KEK di primo livello (memorizzato nel Keystore) come radice di attendibilità.
Generazione di KEK
La maggior parte delle KEK per la crittografia dei blocchi di dati viene generata all'interno del Keystore, mentre le altre vengono generate all'interno dei servizi di archiviazione. Per coerenza, tutte le KEK vengono generate tramite la libreria crittografica comune di Google, utilizzando un generatore di numeri casuali (RNG) creato da Google. L'RNG si basa sulla pubblicazione NIST 800-90Ar1 CTR-DRBG e genera una KEK AES-256. In passato, l'algoritmo era AES-128 e alcune di queste chiavi rimangono attive per decriptare i dati.
Per i processori Intel e AMD, l'RNG viene generato dall'istruzione RDRAND e dall'RNG del kernel Linux. A sua volta, l'RNG del kernel Linux ha origine da più origini entropiche indipendenti, tra cui RDRAND ed eventi entropici provenienti dall'ambiente del data center (ad esempio misurazioni granulari del numero di operazioni di ricerca su disco e tempi di arrivo tra pacchetti). Per i processori ARM, l'RNG ha origine dall'RNG del kernel Linux.
Le DEK vengono sottoposte a wrapping con le KEK utilizzando gli algoritmi 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 delle KEK
Il keystore è stato creato esclusivamente per la gestione delle 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. In questo modo si contribuisce a evitare fughe di dati e usi impropri e si consente a Keystore di creare un audit trail quando le chiavi vengono utilizzate.
Il keystore può ruotare automaticamente le KEK a intervalli di tempo regolari, utilizzando la libreria crittografica comune di Google per generare nuove chiavi. Anche se spesso 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. Il backup delle KEK viene eseguito a scopo di ripristino di emergenza e possono essere recuperate in modo illimitato.
Per ogni chiave, l'utilizzo delle KEK è gestito tramite gli ACL nel Keystore, 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 degli utenti sono controllabili nell'ambito delle norme sulla privacy e dei criteri di sicurezza globali di Google.
Procedura per accedere a blocchi di dati criptati
Quando un servizio Google accede a un blocco di dati criptato, avviene quanto segue:
- Il servizio effettua una chiamata al sistema di archiviazione dei dati di cui ha bisogno.
- Il sistema di archiviazione identifica i blocchi in cui sono archiviati i dati (gli ID blocco) e la posizione in cui sono archiviati.
- Per ogni blocco, il sistema di archiviazione estrae la DEK con wrapping archiviata con il blocco (in alcuni casi, questa operazione viene eseguita dal servizio) e la invia al Keystore per farne annullare il wrapping.
- 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 keystore verifica che il sistema di archiviazione sia autorizzato a utilizzare la KEK associata al servizio e ad annullare il wrapping di quella specifica DEK.
- Il keystore esegue una delle seguenti operazioni:
- Restituisce la DEK decriptata al sistema di archiviazione, che decripta il blocco di dati e lo passa al servizio.
- In alcuni rari casi, passa la DEK decriptata al servizio. 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, in cui il dispositivo gestisce e protegge la DEK a livello di dispositivo.
Questa procedura è illustrata nel seguente diagramma. 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 esegue il wrapping di tutte le KEK nell'archivio chiavi. Questa chiave master del keystore è AES-256 ed è archiviata a sua volta in un altro Key Management Service, chiamato Root Keystore. In passato, la chiave principale del keystore era AES-128 e alcune di queste chiavi rimangono attive per decriptare i dati. Per ulteriore sicurezza, il Root Keystore non viene eseguito su macchine di produzione generali, bensì solo su macchine dedicate in ogni data center di Google.
Il keystore principale ha a sua volta una propria chiave radice, chiamata chiave master del keystore principale, che utilizza anch'essa l'algoritmo AES-256 ed è archiviata in un'infrastruttura peer-to-peer, chiamata distributore di chiavi master del keystore principale, che replica queste chiavi a livello globale. In passato, la chiave master del keystore principale era AES-128 e alcune di queste chiavi rimangono attive per decriptare i dati. Il distributore di chiavi master del keystore radice conserva le chiavi solo nella RAM delle stesse macchine dedicate del keystore radice e utilizza il logging per verificare l'utilizzo corretto.
Quando viene avviata una nuova istanza del distributore di chiavi master del keystore radice, 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 del keystore radice dalle altre istanze in esecuzione. Diversamente dai meccanismi di ripristino di emergenza descritti in Disponibilità e replica a livello globale, la chiave master del keystore radice esiste solo in 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 contemporaneamente, il backup della chiave master del keystore radice viene effettuato anche su dispositivi hardware protetti conservati in casseforti fisiche in aree a protezione elevata in più località geograficamente distribuite. Questo backup sarebbe necessario solo se tutte le istanze del distributore in una regione si spegnessero contemporaneamente. Solo alcuni 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 nel Keystore, che a sua volta è protetta dal Keystore principale e dal distributore di chiavi master del Keystore principale.
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.
- Il 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 in Root Keystore.
- Il Keystore principale è molto più piccolo del Keystore e viene eseguito solo su macchine dedicate in ciascun data center.
- Le chiavi dell'archivio chiavi principale sono sottoposte a wrapping con la chiave master dell'archivio chiavi principale, che è archiviata nel distributore di chiavi master dell'archivio chiavi principale.
- Il distributore di chiavi master del Keystore principale è un'infrastruttura peer-to-peer che viene eseguita contemporaneamente nella RAM di macchine dedicate a livello globale. Ogni macchina riceve il materiale relativo alle chiavi da altre istanze in esecuzione nella regione.
- Nel caso in cui tutte le istanze del distributore in una regione si spengano, una chiave master è archiviata in hardware protetti diversi in casseforti fisiche in alcune sedi di Google.
Replica e disponibilità a livello globale
A ogni livello, l'alta disponibilità, la bassa latenza e l'accesso globale alle chiavi sono fattori essenziali. Queste caratteristiche sono necessarie 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 di tutto il mondo. 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 ogni singola operazione relativa alle chiavi è estremamente ridotta.
Il Keystore principale viene eseguito su varie macchine dedicate alle operazioni di sicurezza in ciascun data center. Il distributore di chiavi master del Keystore radice viene eseguito sulle stesse macchine, one-to-one con il Keystore radice. Il distributore di chiavi master del Keystore radice fornisce un meccanismo di distribuzione che utilizza 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 l'intera infrastruttura. Questo metodo di distribuzione ci consente di gestire e proteggere il materiale chiave con alta disponibilità.
Libreria crittografica comune di Google
La libreria crittografica comune di Google è Tink, che incorpora il modulo convalidato FIPS 140-2 BoringCrypto. Tink è disponibile per tutti gli sviluppatori di Google. Grazie all'uso coerente di una libreria comune, è sufficiente un team ridotto di crittografi per implementare questo codice rigidamente controllato e revisionato. Non è necessario che ogni team di Google sviluppi in modo indipendente la propria crittografia. Un team per la sicurezza speciale di Google 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.
Attualmente, utilizziamo i seguenti algoritmi crittografici per crittografia at-rest per le chiavi DEK e KEK. Gli algoritmi sono soggetti a modifiche in conformità con la nostra politica di continuo miglioramento delle funzionalità e della sicurezza.
| Primitiva di crittografia | Protocolli preferiti | Altri protocolli supportati |
|---|---|---|
| Crittografia simmetrica | AES-GCM (256 bit) |
|
| Firme simmetriche (se utilizzate con i protocolli AES-CBC e AES-CTR riportati sopra per l'autenticazione) | HMAC-SHA256 |
|
Nella libreria sono presenti altri protocolli di crittografia supportati in passato, ma questa tabella illustra i principali utilizzi di Google.
Ricerca e innovazione nel campo della crittografia
Per stare al passo con l'evoluzione della crittografia, abbiamo 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 tutti, incluso il pubblico generale, possano beneficiare delle nostre conoscenze.
Ad esempio, nella ricerca sulla crittografia post-quantistica, ci occupiamo delle seguenti aree:
Standardizzazione: abbiamo co-progettato lo schema di firma digitale basato su hash senza stato, standardizzato come FIPS 205. Siamo editor dello standard dell'International Organization for Standardization (ISO) sulle firme basate su hash di crittografia post-quantistica e abbiamo contribuito alle linee guida sulla gestione dello stato per le firme basate su hash all'IETF.
Attivazione: abbiamo implementato la crittografia post-quantistica nel nostro protocollo interno per la sicurezza del livello di trasporto. Abbiamo attivato il supporto per la crittografia post-quantistica in Chrome. Abbiamo aggiunto diversi algoritmi di crittografia post-quantistica alla nostra libreria di crittografia Tink. Questo codice è sperimentale e ha lo scopo di aiutare la community a conoscere meglio ogni approccio.
Pubblicazioni: abbiamo pubblicato Transizione delle organizzazioni alla crittografia post-quantistica su Nature. Questo documento fornisce una panoramica delle sfide di migrazione alla crittografia post-quantistica. Abbiamo anche pubblicato un articolo di ricerca sull'implementazione 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 sull'utilizzo delle tue chiavi di crittografia in Google Cloud, consulta Chiavi di crittografia gestite dal cliente (CMEK).
Per informazioni generali sulla sicurezza di Google Cloud, consulta la sezione sulla sicurezza del sito web di Google Cloud.
Per informazioni sulla conformità di Google Cloud e sulle certificazioni di conformità, consulta la sezione sulla conformità del sito web di Google Cloud, che include il report di controllo pubblico SOC3 di Google.
Per informazioni sulla gestione delle chiavi e della crittografia in Google Workspace, consulta Come Google Workspace utilizza la crittografia per proteggere i tuoi dati, che tratta molti degli stessi contenuti inclusi qui, ma si concentra esclusivamente su Google Workspace.