Questo è il terzo white paper su come Google utilizza la crittografia per la protezione dei tuoi dati. In questo white paper, troverai maggiori dettagli sulla crittografia dei dati in transito per Google Cloud e Google Workspace.
In tutti i prodotti Google ci impegniamo a mantenere un'elevata protezione dei dati dei clienti e ad essere il più trasparenti possibile in merito alle modalità di protezione.
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, in virtù del costante miglioramento della protezione per i nostri clienti.
Riepilogo a livello di CIO
- Google si avvale di diverse misure di sicurezza volte a garantire l'autenticità, l'integrità e la privacy dei dati in transito.
- Per i casi d'uso illustrati nel presente white paper, Google crittografa e autentica i dati in transito su uno o più livelli di rete quando i dati si spostano all'esterno dei confini fisici non controllati da Google o per conto di Google. Tutto il traffico da VM a VM all'interno di una rete VPC e di reti VPC in peering viene criptato.
- A seconda della connessione effettuata, Google applica le misure di protezione predefinite ai dati in transito. Ad esempio, proteggiamo le comunicazioni tra l'utente e Google Front End (GFE) utilizzando TLS.
- I clienti di Google Cloud con requisiti aggiuntivi per la crittografia dei dati trasmessi su WAN possono scegliere di implementare ulteriori misure di protezione per i dati trasferiti da un utente a un'applicazione o da una macchina virtuale all'altra. Queste misure di protezione comprendono tunnel IPSec, S/MIME di Gmail, certificati SSL gestiti e Istio.
- Google collabora attivamente con il settore per contribuire a mettere la crittografia dei dati in transito a disposizione di tutti, ovunque. Abbiamo diversi progetti open source che incoraggiano l'uso della crittografia dei dati in transito e la sicurezza dei dati su Internet in generale, tra cui Certificate Transparency, le API di Chrome e SMTP sicuro.
- Google intende rimanere il leader nel settore della crittografia dei dati in transito. A tal fine, dedichiamo le nostre risorse allo sviluppo e al miglioramento della tecnologia di crittografia. Il nostro lavoro in questo campo include innovazioni nei settori della trasparenza delle chiavi e della crittografia post-quantica.
Introduzione
La sicurezza è spesso un fattore decisivo nella scelta di un provider di servizi per il cloud pubblico. Per Google la sicurezza è un tema di fondamentale importanza. Lavoriamo senza sosta per proteggere i tuoi dati durante i trasferimenti su Internet, negli spostamenti all'interno dell'infrastruttura di Google o semplicemente mentre sono archiviati sui nostri server.
Al centro della strategia di sicurezza di Google ci sono l'autenticazione, l'integrità e la crittografia, sia per i dati inattivi sia per quelli in transito. Questo documento descrive il nostro approccio alla crittografia dei dati in transito per Google Cloud.
Per i dati inattivi, consulta Crittografia dei dati inattivi su Google Cloud Platform. Per una panoramica complessiva della sicurezza di Google, consulta Panoramica sulla progettazione della sicurezza per l'infrastruttura Google.
Destinatari: questo documento è rivolto ai CISO e ai team per le operazioni di sicurezza che utilizzano o stanno prendendo in considerazione Google Cloud.
Prerequisiti: oltre a questa introduzione, è necessaria una conoscenza di base della crittografia e delle primitive crittografiche.
Autenticazione, integrità e crittografia
Google si avvale di diverse misure di sicurezza volte a garantire l'autenticità, l'integrità e la privacy dei dati in transito.
- Autenticazione: verifichiamo l'origine dei dati, che si tratti di un essere umano o di un processo, e la loro destinazione.
- Integrità: ci assicuriamo che i dati inviati arrivino a destinazione inalterati.
- Crittografia: rendiamo illeggibili i tuoi dati in transito per garantirne la riservatezza. La crittografia è il processo attraverso il quale i dati leggibili (testo non crittografato) sono resi illeggibili (testo crittografato) con l'obiettivo di garantire che il testo in chiaro sia accessibile solo alle parti autorizzate dal proprietario dei dati. Gli algoritmi utilizzati nel processo di crittografia sono pubblici, ma la chiave necessaria per decriptare il testo crittografato è privata. La crittografia dei dati in transito spesso utilizza lo scambio di chiavi asimmetriche, ad esempio l'algoritmo Diffie-Hellman basato su una curva ellittica, per stabilire una chiave simmetrica condivisa utilizzata per la crittografia dei dati. Per ulteriori informazioni sulla crittografia, consulta Introduction to Modern Cryptography.
La crittografia può essere utilizzata per proteggere i dati in tre stati:
- Crittografia dei dati inattivi: protegge i dati in caso di compromissione del sistema o di esfiltrazione dei dati, crittografandoli durante l'archiviazione. Per la crittografia dei dati inattivi viene spesso utilizzato l'algoritmo Advanced Encryption Standard (AES).
- Crittografia dei dati in transito: protegge i dati qualora le comunicazioni vengano intercettate durante il trasferimento dei dati tra la tua sede e il cloud provider o tra due servizi. Questa protezione viene ottenuta criptando i dati prima della trasmissione, autenticando gli endpoint e, all'arrivo, decriptando e verificando che i dati non siano stati modificati. Ad esempio, per garantire la sicurezza del trasporto viene spesso utilizzato Transport Layer Security (TLS) per criptare i dati in transito, mentre S/MIME (Secure/Multipurpose Internet Mail Extensions) viene utilizzato spesso per la crittografia dei messaggi email.
- Crittografia dei dati in uso: protegge i dati in memoria dalla compromissione o dall'esfiltrazione dei dati criptando i dati durante l'elaborazione. Per ulteriori informazioni, consulta Confidential Computing.
La crittografia è uno dei componenti di una strategia di sicurezza più ampia. Dopo la connessione e l'autenticazione, la crittografia dei dati in transito tutela i tuoi dati contro potenziali malintenzionati:
- Eliminando l'esigenza di affidarsi ai livelli inferiori della rete, comunemente forniti da terze parti
- Riducendo la potenziale superficie di attacco
- Impedendo agli utenti malintenzionati di accedere ai dati qualora le comunicazioni vengano intercettate
Con un'autenticazione, un'integrità e una crittografia adeguate, i dati trasferiti tra utenti, dispositivi o processi possono essere protetti in un ambiente ostile. La parte restante di questo documento spiega l'approccio di Google alla crittografia dei dati in transito e ne descrive i punti di applicazione.
Infrastruttura di rete di Google
Confini fisici
Un confine fisico è la barriera da superare per raggiungere uno spazio fisico controllato da Google o per conto di Google, nel quale possiamo garantire l'applicazione di rigorose misure di sicurezza. L'accesso fisico a queste località è limitato e fortemente monitorato. Solo un piccolo gruppo di dipendenti Google ha accesso all'hardware. I dati in transito all'interno di questi confini fisici sono generalmente autenticati, ma potrebbero non essere criptati per impostazione predefinita.
A causa della portata di internet globale, non possiamo mettere in atto gli stessi controlli di sicurezza fisici per i collegamenti in fibra ottica della nostra WAN o al di fuori dei confini fisici controllati da Google o per conto di Google. Per questo motivo, applichiamo automaticamente protezioni aggiuntive al di fuori del nostro confine di trust fisico. Queste misure di protezione includono la crittografia dei dati in transito per tutto il traffico al di fuori dei nostri confini fisici.
Modalità di routing del traffico
Per comprendere appieno come funziona la crittografia dei dati in transito su Google, dobbiamo spiegare anche in che modo il traffico viene instradato attraverso Internet. Questa sezione descrive come le richieste provenienti da un utente finale vengono inviate al servizio Google Cloud o all'applicazione del cliente appropriati e come il traffico viene instradato tra i servizi.
Un servizio Google Cloud è un servizio cloud modulare che offriamo ai nostri clienti. Questi servizi includono computing, archiviazione dati, analisi dei dati e machine learning. Ad esempio, Cloud Storage è un servizio di Google Cloud. Un'applicazione del cliente è un'applicazione ospitata su Google Cloud che tu, in qualità di cliente Google, puoi creare e implementare utilizzando i servizi Google Cloud. Le applicazioni del cliente o le soluzioni dei partner ospitate su Google Cloud non sono considerate servizi Google Cloud.1 Ad esempio, un'applicazione creata utilizzando Google App Engine, Google Kubernetes Engine o una VM in Google Compute Engine è un'applicazione del cliente.
I cinque tipi di richieste di routing presentati di seguito sono mostrati nella Figura 1. Questa figura mostra le interazioni tra i vari componenti della rete e la sicurezza in atto per ciascuna connessione.
Dall'utente finale (Internet) a un servizio Google Cloud
I servizi Google Cloud accettano richieste da tutto il mondo utilizzando un sistema distribuito a livello globale chiamato Google Front End (GFE). Il GFE termina il traffico proxy, TCP, HTTP(S) e TLS in entrata, offre contromisure agli attacchi DDoS e provvede a instradare e bilanciare il carico del traffico verso i servizi Google Cloud. I punti di presenza dei GFE si trovano in tutto il mondo e le relative route sono annunciate mediante unicast o Anycast.
I GFE indirizzano il traffico ai servizi Google Cloud. I GFE instradano la richiesta dell'utente sul nostro backbone di rete a un servizio Google Cloud. Questa connessione viene autenticata e crittografata dal GFE al front-end del servizio Google Cloud o dell'applicazione del cliente quando tali comunicazioni lasciano un confine fisico controllato da Google o per conto di Google. La Figura 1 mostra questa interazione (connessione con etichetta A).
Dall'utente finale (Internet) a un'applicazione del cliente ospitata in Google Cloud
Il traffico da Internet può essere instradato verso un'applicazione del cliente ospitata in Google Cloud con modalità diverse. La modalità di routing del traffico dipende dalla configurazione in uso, come spiegato di seguito. La Figura 1 mostra questa interazione (connessione con etichetta B).
Se utilizzi un bilanciatore del carico delle applicazioni esterno o un bilanciatore del carico di rete proxy esterno (con un proxy SSL), consulta Crittografia dal bilanciatore del carico ai backend.
Da una macchina virtuale a un'altra macchina virtuale
Le connessioni da VM a VM all'interno delle reti VPC e le reti VPC in peering all'interno della rete di produzione di Google vengono autenticate e criptate. Sono incluse le connessioni tra le VM dei clienti e le VM dei clienti e gestite da Google, ad esempio Cloud SQL. La Figura 1 mostra questa interazione (connessione con etichetta C). Tieni presente che le connessioni da VM a VM che utilizzano indirizzi IP esterni non sono criptate.
Connettività con i servizi e le API di Google
La gestione del traffico varia a seconda della posizione del servizio Google Cloud:
La maggior parte dei servizi e delle API di Google è ospitata nei Google Front End (GFE), tuttavia alcuni servizi sono ospitati nelle istanze gestite da Google. Ad esempio, l'accesso privato ai servizi e i master GKE per i cluster privati sono ospitati nelle istanze gestite da Google.
Con l'accesso privato Google, le VM che non hanno indirizzi IP esterni possono accedere a servizi e API di Google supportati, incluse le applicazioni dei clienti ospitate in App Engine. Per ulteriori informazioni sull'accesso ai servizi e alle API di Google, consulta Opzioni di accesso privato per i servizi.
Se un'istanza VM di Compute Engine si connette all'indirizzo IP esterno di un'altra istanza VM di Compute Engine, il traffico rimane nella rete di produzione di Google, ma non viene criptato a causa dell'utilizzo dell'indirizzo IP esterno. Per i sistemi al di fuori della rete di produzione di Google che si connettono a un indirizzo IP esterno di un'istanza VM di Compute Engine, il traffico viene instradato su Internet.
La Figura 1 mostra un percorso esterno (connessione con etichetta D). I casi tipici di questo genere di richiesta di routing sono:
- Da una VM di Compute Engine a Google Cloud Storage
- Da una VM di Compute Engine a un'API Machine Learning
Dalla VM al GFE, i servizi Google Cloud supportano la protezione di queste connessioni con TLS per impostazione predefinita.2 La connessione viene autenticata dal GFE al servizio e viene criptata quando la connessione lascia un confine fisico. Oltre a queste protezioni predefinite, puoi applicare la crittografia envelope. Per ulteriori informazioni, vedi Criptare i dati.
Da un servizio Google Cloud a un altro servizio Google Cloud
Il routing da un servizio di produzione all'altro avviene sul nostro backbone di rete e potrebbe richiedere il routing del traffico al di fuori dei confini fisici controllati da Google o per conto di Google. La Figura 1 mostra questa interazione (connessione con etichetta E). Un esempio di questo tipo di traffico è un evento Google Cloud Storage che attiva Google Cloud Functions. Le connessioni tra i servizi di produzione vengono criptate quando lasciano un confine fisico e vengono autenticate all'interno del confine fisico.
Figura 1: protezione per impostazione predefinita e opzioni sovrapposte su una rete VPC
Crittografia dei dati in transito per impostazione predefinita
Google utilizza vari metodi di crittografia, sia predefiniti sia configurabili dall'utente, per i dati in transito. Il tipo di crittografia utilizzato dipende dal livello OSI, dal tipo di servizio e dal componente fisico dell'infrastruttura. Le Figure 2 e 3 di seguito illustrano le protezioni facoltative e predefinite applicate da Google Cloud per i livelli 3, 4 e 7.
Figura 2: protezione per impostazione predefinita e opzioni nei livelli 3 e 4 in Google Cloud
Figura 3: protezione predefinita e opzioni per il livello 7 in Google Cloud3
Il resto di questa sezione descrive le protezioni predefinite utilizzate da Google per proteggere i dati in transito.
Crittografia dall'utente al Google Front End
Oggi molti sistemi utilizzano il protocollo HTTPS per comunicare su Internet. HTTPS fornisce la sicurezza tramite una connessione TLS, che garantisce l'autenticità, l'integrità e la riservatezza delle richieste e delle risposte. Per accettare le richieste HTTPS, il destinatario richiede una coppia di chiavi pubblica/privata e un certificato X.509 per l'autenticazione del server da parte di un'autorità di certificazione (CA). La coppia di chiavi e il certificato aiutano a proteggere le richieste di un utente a livello dell'applicazione (livello 7), dimostrando che il destinatario è il proprietario del nome di dominio a cui sono destinate le richieste. Le seguenti sottosezioni discutono i componenti della crittografia dall'utente al GFE, ovvero TLS, BoringSSL e Autorità di certificazione di Google. Ricorda che non tutti i percorsi dei clienti vengono instradati tramite il GFE; in particolare, il GFE è utilizzato per il traffico da un utente a un servizio Google Cloud e da un utente a un'applicazione del cliente ospitata in Google Cloud che utilizza Google Cloud Load Balancing.
Transport Layer Security (TLS)
Quando un utente invia una richiesta a un servizio Google Cloud, proteggiamo i dati in transito fornendo l'autenticazione, l'integrità e la crittografia tramite il protocollo HTTPS con un certificato di un'autorità di certificazione web (pubblica). Tutti i dati che l'utente invia al GFE vengono crittografati in transito con Transport Layer Security (TLS) o QUIC. Il GFE negozia un particolare protocollo di crittografia con il client in base a ciò che il client è in grado di supportare. Il GFE sceglie i protocolli di crittografia più moderni quando possibile.
La crittografia TLS in scala del GFE, oltre ad essere applicata alle interazioni dell'utente finale con Google, facilita anche le interazioni API con Google su TLS, incluso Google Cloud. Inoltre, la nostra crittografia TLS viene utilizzata in Gmail per lo scambio di email con server di posta esterni (maggiori dettagli sono disponibili in Richiesta di TLS in Gmail).
Google è leader del settore sia nell'adozione di TLS sia nel rafforzamento della sua implementazione. A tal fine, abbiamo abilitato per impostazione predefinita molte delle funzionalità di sicurezza di TLS. Ad esempio, dal 2011 utilizziamo la forward secrecy nella nostra implementazione di TLS. La forward secrecy assicura che la chiave che protegge una connessione non sia persistente: in questo modo, un utente malintenzionato che intercetta e legge un messaggio non può leggere i messaggi precedenti.
BoringSSL
BoringSSL è un'implementazione open source del protocollo TLS gestita da Google, creata mediante fork da OpenSSL e per la maggior parte compatibile a livello di interfaccia con OpenSSL. BoringSSL è un fork di OpenSSL creato da Google per semplificare OpenSSL, sia per uso interno sia per supportare meglio i progetti open source Chromium e Android. BoringCrypto, il nucleo di BoringSSL, è stato convalidato ai sensi di FIPS 140-2 livello 1.
TLS nel GFE viene implementato con BoringSSL. La Tabella 1 mostra i protocolli di crittografia supportati dal GFE durante la comunicazione con i client.
| Protocolli | Autenticazione | Scambio di chiavi | Crittografia | Funzioni hash |
|---|---|---|---|---|
| TLS 1.3 | RSA 2048 | Curve25519 | AES-128-GCM | SHA384 |
| TLS 1.2 | ECDSA P-256 | P-256 (NIST secp256r1) | AES-256-GCM | SHA256 |
| TLS 1.1 | AES-128-CBC | SHA17 | ||
| TLS 1.04 | AES-256-CBC | MD58 | ||
| QUIC5 | ChaCha20-Poly1305 | |||
| 3DES6 |
Tabella 1: crittografia implementata nel Google Front End per i servizi Google Cloud e implementata nella libreria crittografica BoringSSL
Autorità di certificazione di Google
Come parte di TLS, un server deve dimostrare la sua identità all'utente quando riceve una richiesta di connessione. Questa verifica dell'identità viene eseguita nel protocollo TLS chiedendo al server di presentare un certificato contenente l'identità che dichiara di avere. Il certificato contiene sia il nome host DNS del server sia la relativa chiave pubblica. Una volta presentato, il certificato viene firmato da un'autorità di certificazione (CA) emittente che viene considerata attendibile dall'utente che richiede la connessione.9 Di conseguenza, gli utenti che richiedono connessioni al server devono solo considerare attendibile la CA radice. Se il server desidera essere raggiungibile in maniera ubiqua, la CA radice deve essere nota ai dispositivi client in tutto il mondo. Oggi, la maggior parte dei browser e le altre implementazioni del client TLS hanno ciascuno il proprio set di CA radice configurate come attendibili nel loro "archivio radice".
Storicamente, Google gestiva la propria CA emittente, utilizzata per firmare i certificati per i domini di Google. Non gestiva invece una propria CA radice. Oggi i nostri certificati CA sono firmati da più CA radice distribuite in modo ubiqua, inclusi DigiCert e i certificati radice precedentemente gestiti da GlobalSign ("GS Root R2" e "GS Root R4").
Nel mese di giugno 2017 abbiamo annunciato il passaggio all'utilizzo di CA radice di proprietà di Google. I nostri piani nel corso del tempo prevedono la gestione di una CA radice distribuita in maniera ubiqua che emetterà certificati per i domini Google e per i nostri clienti.
Migrazione delle chiavi radice e rotazione delle chiavi
Le chiavi della CA radice non vengono modificate spesso, poiché il passaggio a una nuova CA radice richiede che tutti i browser e i dispositivi incorporino l'attendibilità di tale certificato, operazione che richiede molto tempo. Di conseguenza, anche se Google ora gestisce le proprie CA radice, nel periodo di transizione continueremo a fare affidamento su molteplici CA radice di terze parti, in modo da tenere conto dei dispositivi legacy mentre eseguiamo la migrazione alla nostra CA.
La creazione di una nuova chiave CA radice richiede una cerimonia delle chiavi. In Google, la cerimonia prevede che almeno 3 delle 6 possibili persone autorizzate raccolgano fisicamente le chiavi hardware conservate in una cassaforte. Questi individui si incontrano in una sala dedicata, protetta dalle interferenze elettromagnetiche, con un modulo di sicurezza hardware (HSM) ermetico per generare un set di chiavi e certificati. La sala dedicata si trova in una località sicura all'interno dei data center di Google. I controlli aggiuntivi, quali misure di sicurezza fisica, telecamere e altri osservatori umani, assicurano che il processo proceda come previsto. Se la cerimonia ha esito positivo, il certificato generato è identico a un certificato campione, fatta eccezione per il nome dell'emittente, la chiave pubblica e la firma. Il certificato CA radice risultante viene quindi inviato al browser e ai programmi radice del dispositivo per l'inclusione. Questo processo è studiato per garantire che la privacy e la sicurezza delle chiavi private associate siano ben chiare, in modo che le chiavi possano essere utilizzate per almeno un decennio.
Come descritto in precedenza, le CA utilizzano le loro chiavi private per firmare i certificati e questi certificati verificano le identità quando si avvia un handshake TLS come parte di una sessione utente. I certificati server sono firmati con CA intermedie, la cui creazione è simile alla creazione di una CA radice. I certificati delle CA intermedie vengono distribuiti come parte della sessione TLS: è pertanto più semplice eseguire la migrazione verso una nuova CA intermedia. Questo metodo di distribuzione consente inoltre all'operatore della CA di mantenere il materiale della chiave CA radice in uno stato offline.
La sicurezza di una sessione TLS dipende dal livello di protezione della chiave del server. Per ridurre ulteriormente il rischio di compromissione delle chiavi, la durata dei certificati TLS di Google è limitata a circa tre mesi e i certificati vengono ruotati ogni due settimane circa.
Un client precedentemente connesso a un server può utilizzare una chiave ticket privata10 per riprendere una sessione precedente con un handshake TLS abbreviato, rendendo questi ticket molto preziosi per un utente malintenzionato. Google ruota le chiavi ticket almeno una volta al giorno e ne imposta la scadenza in tutte le proprietà ogni 3 giorni. Per scoprire di più sulla rotazione delle chiavi ticket di sessione, vedi questo articolo sulla misurazione del problema di sicurezza delle scorciatoie crittografiche TLS.
Dal Google Front End ai front-end delle applicazioni
In alcuni casi, come spiegato nella sezione Modalità di routing del traffico, l'utente si connette a un GFE all'interno di un confine fisico diverso rispetto al servizio desiderato e al front-end dell'applicazione associato. In questo caso, la richiesta dell'utente e qualsiasi altro protocollo del livello 7, ad esempio HTTP, sono protetti da TLS o incapsulati in una RPC protetta mediante Application Layer Transport Security (ALTS), di cui si parla in Autenticazione, integrità e crittografia da un servizio all'altro. Queste RPC sono autenticate e crittografate.
Per i servizi Google Cloud, le RPC sono protette tramite ALTS. Per le applicazioni dei clienti ospitate in Google Cloud, se il traffico viene instradato tramite Google Front End, ad esempio se le applicazioni stanno utilizzando Google Cloud Load Balancer, il traffico verso la VM viene protetto utilizzando la crittografia della rete virtuale di Google Cloud, descritta nella sezione successiva.
Crittografia e autenticazione della rete virtuale di Google Cloud
La crittografia del traffico IP privato all'interno della stessa rete VPC o tra reti VPC in peering all'interno della rete virtuale di Google Cloud viene eseguita a livello di rete.
Utilizziamo Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) con una chiave a 128 bit (AES-128-GCM) per implementare la crittografia a livello della rete. Ogni coppia di host comunicanti stabilisce una chiave di sessione tramite un canale di controllo protetto da ALTS per comunicazioni autenticate e crittografate. La chiave di sessione viene utilizzata per crittografare tutte le comunicazioni da VM a VM tra questi host; inoltre, le chiavi di sessione vengono ruotate periodicamente.
Al livello della rete (livello 3), la rete virtuale di Google Cloud autentica tutto il traffico tra le VM. Questa autenticazione, ottenuta tramite token di sicurezza, protegge un host compromesso dallo spoofing dei pacchetti sulla rete.
Durante l'autenticazione, i token di sicurezza vengono incapsulati in un'intestazione del tunnel che contiene le informazioni di autenticazione relative al mittente e al destinatario. Il piano di controllo11 sul lato di invio imposta il token, mentre l'host ricevente lo convalida. I token di sicurezza vengono pre-generati per ogni flusso e consistono di una chiave token (contenente le informazioni del mittente) e del secret dell'host. Esiste un secret per ogni coppia mittente-destinatario di confini fisici controllati da Google o per conto di Google.
La Figura 4 mostra come creare le chiavi dei token, i secret degli host e i token di sicurezza.
Figura 4: token di sicurezza
Il secret del confine fisico è un numero pseudocasuale a 128 bit, da cui i secret dell'host vengono derivati con l'acquisizione di un HMAC-SHA1. Il secret del confine fisico è negoziato mediante un handshake tra i piani di controllo della rete di una coppia di confini fisici e viene rinegoziato a intervalli di qualche ora. I token di sicurezza utilizzati per l'autenticazione da VM a VM singola, derivati da questi e da altri dati in ingresso, sono HMAC negoziati per una determinata coppia di mittente e destinatario.
Crittografia dalla macchina virtuale al Google Front End
Il traffico dalla VM al GFE utilizza IP esterni per raggiungere i servizi Google, ma puoi configurare l'accesso privato per utilizzare gli indirizzi IP solo di Google per le richieste.
Per impostazione predefinita, supportiamo il traffico TLS da una VM al GFE. La connessione avviene come qualsiasi altra connessione esterna. Per ulteriori informazioni su TLS, consulta la pagina Transport Layer Security (TLS).
Autenticazione, integrità e crittografia da un servizio all'altro
Al livello dell'applicazione (livello 7) nell'infrastruttura di Google utilizziamo il nostro Application Layer Transport Security (ALTS) per l'autenticazione, l'integrità e la crittografia delle chiamate RPC di Google dal GFE a un servizio e da un servizio all'altro.
ALTS utilizza gli account di servizio per l'autenticazione. Ogni servizio eseguito nell'infrastruttura di Google viene eseguito con un'identità dell'account di servizio in possesso di credenziali crittografiche associate. Quando effettua o riceve RPC da altri servizi, un servizio utilizza le proprie credenziali per l'autenticazione. ALTS verifica queste credenziali utilizzando un'autorità di certificazione interna.
All'interno di un confine fisico controllato da Google o per conto di Google, ALTS fornisce sia l'autenticazione sia l'integrità per le RPC nella modalità "autenticazione e integrità". Per il traffico sulla WAN al di fuori dei confini fisici controllati da Google o per conto di Google, ALTS applica automaticamente la crittografia per il traffico RPC dell'infrastruttura nella modalità "autenticazione, integrità e privacy". Attualmente, tutto il traffico verso i servizi Google, inclusi i servizi Google Cloud, beneficia di queste stesse protezioni.
ALTS viene utilizzato anche per incapsulare altri protocolli del livello 7, ad esempio HTTP, nei meccanismi RPC dell'infrastruttura per il passaggio del traffico dal Google Front End al front-end dell'applicazione. Questa protezione isola il livello dell'applicazione e rimuove qualsiasi dipendenza dalla sicurezza del percorso di rete.
I servizi di infrastruttura di sicurezza accettano e inviano comunicazioni ALTS solo in modalità "autenticazione, integrità e privacy", anche all'interno dei confini fisici controllati da Google o per conto di Google. Un esempio è il Keystore, che archivia e gestisce le chiavi di crittografia utilizzate per proteggere i dati inattivi archiviati nell'infrastruttura di Google.
Crittografia di rete tramite PSP
Il PSP Security Protocol (PSP) è indipendente dal trasporto, consente la sicurezza per ogni connessione e supporta il trasferimento della crittografia su hardware Smart Network Interface Card (SmartNIC). Ogni volta che sono disponibili SmartNIC, utilizziamo PSP per criptare i dati in transito nella rete.
Il PSP è progettato per soddisfare i requisiti del traffico dei data center su larga scala. Utilizziamo i PSP per criptare il traffico all'interno e tra i nostri data center. PSP supporta i protocolli non TCP come UDP e utilizza una chiave di crittografia per ogni connessione di livello 4.
Per ulteriori informazioni su come utilizziamo i PSP, consulta l'articolo Annuncio che l'offload hardware crittografico su larga scala del PSP è ora open source.
Protocollo ALTS
ALTS dispone di un protocollo di handshake sicuro simile a TLS reciproco. Due servizi che desiderano comunicare utilizzando ALTS impiegano questo protocollo di handshake per autenticare e negoziare i parametri di comunicazione prima di inviare qualsiasi informazione sensibile. Il protocollo prevede un processo in due passaggi:
- Passaggio 1: handshake Il client avvia un handshake Diffie-Hellman a curva ellittica (ECDH) con il server utilizzando Curve25519. Il client e il server dispongono ciascuno di parametri pubblici ECDH certificati come parte del loro certificato, che viene utilizzato durante uno scambio di chiavi Diffie-Hellman. L'handshake genera una chiave di traffico comune, disponibile sul client e sul server. Le identità di peering dei certificati vengono riportate al livello dell'applicazione per essere utilizzate nelle decisioni di autorizzazione.
- Passaggio 2: registrazione della crittografia Utilizzando la chiave di traffico comune del passaggio 1, i dati vengono trasmessi dal client al server in modo sicuro. La crittografia in ALTS viene implementata utilizzando BoringSSL e altre librerie di crittografia. La crittografia scelta più comunemente è AES-128-GCM, mentre l'integrità è fornita dal GMAC di AES-GCM.
Il seguente diagramma mostra in dettaglio l'handshake ALTS. Nelle implementazioni più recenti è un helper di processo a occuparsi dell'handshake; ci sono però ancora alcuni casi in cui l'operazione viene eseguita direttamente dalle applicazioni.
Figura 5: handshake ALTS
Come descritto all'inizio della sezione Autenticazione, integrità e crittografia da un servizio all'altro, ALTS utilizza gli account di servizio per l'autenticazione: ogni servizio eseguito sull'infrastruttura di Google è in esecuzione come un'identità di servizio con le credenziali crittografiche associate. Durante l'handshake ALTS, l'helper di processo accede alle chiavi private e ai certificati corrispondenti che ciascuna coppia client-server utilizza nelle relative comunicazioni. Per l'identità dell'account di servizio del servizio è stato eseguito il provisioning della chiave privata e del certificato corrispondente (buffer di protocollo firmato). .
Certificati ALTS Esistono diversi tipi di certificati ALTS:
- Certificati macchina: forniscono un'identità ai servizi principali su una macchina specifica. Vengono ruotati approssimativamente ogni 6 ore.
- Certificati utente: forniscono l'identità di un utente finale per un ingegnere Google che si occupa dello sviluppo del codice. Vengono ruotati approssimativamente ogni 20 ore.
- Certificati per job Borg: forniscono un'identità per i job in esecuzione all'interno dell'infrastruttura di Google. Vengono ruotati approssimativamente ogni 48 ore.
La chiave di firma del certificato radice è archiviata nell'autorità di certificazione (CA) interna di Google, che non è correlata ed è indipendente dalla nostra CA esterna.
Crittografia in ALTS
La crittografia in ALTS può essere implementata utilizzando svariati algoritmi a seconda delle macchine utilizzate. Ad esempio, la maggior parte dei servizi utilizza AES-128-GCM12. Ulteriori informazioni sulla crittografia ALTS sono disponibili nella Tabella 2.
| Macchine | Crittografia dei messaggi utilizzata | |
|---|---|---|
| Più comuni | AES-128-GCM | |
| Sandy Bridge o precedenti | AES-128-VCM | Utilizza un VMAC invece di un GMAC ed è leggermente più efficiente su queste macchine meno recenti. |
Tabella 2: crittografia in ALTS
La maggior parte dei servizi Google utilizza ALTS o l'incapsulamento delle RPC che utilizza ALTS. Nei casi in cui non viene utilizzato ALTS, vengono utilizzati altri metodi di protezione, Ad esempio:
- Alcuni servizi di bootstrap e gestione delle macchine di basso livello utilizzano SSH
- Alcuni servizi di logging dell'infrastruttura di basso livello utilizzano TLS o Datagram TLS (DTLS)13
- Alcuni servizi che utilizzano servizi di trasporto diversi da TCP utilizzano altri protocolli crittografici o sistemi di protezione a livello della rete quando si trovano all'interno dei confini fisici controllati da Google o per conto di Google
Le comunicazioni tra le VM e i servizi Google Cloud Platform utilizzano TLS per comunicare con il Google Front End (GFE), non con ALTS. Queste comunicazioni vengono descritte nella crittografia dalla macchina virtuale a Google Front End (GFE) End.
Configurazione di altre opzioni di crittografia dei dati in transito
Puoi configurare le protezioni per i tuoi dati quando sono in transito tra Google Cloud e i tuoi data center o in transito tra le tue applicazioni ospitate su Google Cloud e i dispositivi degli utenti.
Se vuoi connettere il tuo data center a Google Cloud, considera quanto segue:
- Utilizza TLS con l'Application Load Balancer esterno o il bilanciatore del carico di rete proxy esterno per connetterti al servizio cloud. GFE termina le connessioni TLS provenienti dai tuoi utenti utilizzando i certificati SSL di cui esegui il provisioning e che controlli. Per ulteriori informazioni sulla personalizzazione del certificato, consulta la panoramica dei certificati SSL.
- Crea un tunnel IPSec utilizzando Cloud VPN o utilizza Cloud Interconnect per connettere in modo sicuro la tua rete on-premise alla rete Virtual Private Cloud. Per ulteriori informazioni, consulta la sezione Scegliere un prodotto per la connettività di rete.
Se vuoi connettere i dispositivi degli utenti alle applicazioni in esecuzione in Google Cloud, considera quanto segue:
- Utilizza il supporto di TLS da parte di GFE configurando il certificato SSL che utilizzi. Ad esempio, puoi terminare la sessione TLS nell'applicazione.
- Prendi in considerazione i nostri certificati SSL gratuiti e automatizzati, disponibili per i domini personalizzati di Firebase Hosting e App Engine. Con i domini personalizzati di App Engine, puoi anche fornire certificati SSL personali e utilizzare un'intestazione HSTS (HTTP Strict Transport Security).
- Per i carichi di lavoro su GKE e Compute Engine, prendi in considerazione il mesh di servizi GKE Enterprise in modo da poter utilizzare mTLS per l'autenticazione, che garantisce che tutte le comunicazioni TCP vengano criptate in transito.
Se utilizzi Google Workspace, configura Gmail per abilitare S/MIME per le email in uscita, imposta criteri per la conformità dei contenuti e degli allegati e crea regole di routing per le email in entrata e in uscita.
Ricerca e innovazione nella crittografia in transito
Nel corso degli anni, siamo stati coinvolti in diversi progetti open source e in altre iniziative che incoraggiano l'uso della crittografia in transito su internet.
Queste iniziative includono:
- Certificate Transparency (CT) è un'iniziativa che abbiamo introdotto per offrire agli operatori di siti e ai titolari di domini un modo per rilevare se una CA ha emesso certificati non autorizzati o errati.
- Il nostro Rapporto annuale sulla trasparenza di HTTPS monitora i nostri progressi verso il nostro obiettivo di una crittografia al 100% dei dati in transito per tutte le nostre proprietà, incluso Google Cloud.
- Lo sviluppo dell'algoritmo combinato a curva ellittica e post-quantistica (CECPQ2), che aiuta a proteggere le connessioni TLS dagli attacchi informatici quantistici.
Per ulteriori informazioni sui nostri recenti contributi, consulta la pagina Collaborazione con la community di ricerca sulla sicurezza.
Passaggi successivi
- Per informazioni generali sulla sicurezza di Google Cloud, incluse le best practice per la sicurezza, consulta la sezione 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 di controllo pubblico SOC3 di Google.
- Per le best practice su come proteggere i tuoi dati in transito, consulta il progetto delle basi aziendali, il framework dell'architettura Google Cloud: sicurezza, privacy e conformità e decidi come soddisfare i requisiti normativi per la crittografia dei dati in transito.