Crittografia dei dati in transito

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo è il terzo white paper su come Google utilizza la crittografia per la protezione dei tuoi dati. In questo white paper troverai ulteriori 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 al momento in cui sono stati scritti. Le politiche e i sistemi di sicurezza di Google possono cambiare in futuro, in quanto miglioriamo costantemente la 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 mentre sono in transito per mantenerli privati. 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. Lo standard di crittografia avanzata (AES) viene spesso utilizzato per criptare i dati at-rest.
  • 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 si ottiene criptando i dati prima della trasmissione, autenticando gli endpoint e, all'arrivo, decriptando e verificando che i dati non siano stati modificati. Ad esempio, spesso TLS (Transport Layer Security) viene utilizzato per criptare i dati in transito per la sicurezza dei trasporti e le estensioni S/MIME (Secure/Multipurpose Internet Mail Extensions) vengono utilizzate spesso per la crittografia dei messaggi email.
  • Crittografia dei dati in uso: protegge i dati in memoria dalla compromissione o dall'esfiltrazione dei dati tramite la crittografia dei dati durante l'elaborazione. Per ulteriori informazioni, consulta la pagina relativa a 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 globale di Internet, non possiamo implementare gli stessi controlli di sicurezza fisica per i collegamenti in fibra nella 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 protezioni 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 calcolo, archiviazione dei dati, analisi dei dati e machine learning. Ad esempio, Cloud Storage è un servizio Google Cloud. Un'applicazione del cliente è un'applicazione ospitata su Google Cloud che puoi, in qualità di cliente Google, creare ed eseguire il deployment utilizzando i servizi Google Cloud. Le applicazioni dei clienti o le soluzioni dei partner ospitate su Google Cloud non sono considerate servizi Google Cloud1. Ad esempio, un'applicazione che crei 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 bilanciamento del carico HTTP(S) o un proxy proxy SSL esterno, 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).

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. 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 alle protezioni predefinite, puoi applicare la crittografia della busta. Per maggiori informazioni, consulta la pagina 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.

L'utente viene instradato ai servizi Google Cloud in confini fisici mediante la crittografia ALTS.

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.

Le opzioni di crittografia per i livelli 3 e 4 includono il traffico di dati verso la VM e nei confini.

Figura 2: protezione per impostazione predefinita e opzioni nei livelli 3 e 4 in Google Cloud

Le opzioni di crittografia per il livello 7 includono quelle per i dati in transito tra le VM e verso il Google Front End (GFE).

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.

Il protocollo TLS nel GFE è implementato con BoringSSL. La Tabella 1 mostra i protocolli di crittografia supportati da 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 è considerata attendibile dall'utente che richiede la connessione9. 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. Attualmente i nostri certificati CA sono firmati da più CA radice distribuite in maniera ubiqua, incluse DigiCert e root gestite in precedenza 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 della chiave. In Google, la cerimonia richiede che almeno 3 dei 6 possibili individui autorizzati fisicamente possano utilizzare le chiavi hardware conservate in una cassaforte. Questi individui si trovano in una sala dedicata, protetta dalle interferenze elettromagnetiche, con un modulo di sicurezza hardware (HSM) con air gap 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 privata di ticket10 per riprendere una sessione precedente con un handshake TLS abbreviato, rendendo i ticket molto importanti 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 HSM. 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.

A livello di 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.

I componenti di un token di sicurezza possono includere una chiave del token, un secret dell'host e le relative dipendenze.

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, vedi 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 dell'infrastruttura di sicurezza accettano e inviano le comunicazioni HSM solo in modalità "autenticazione, integrità e privacy", anche all'interno dei confini fisici controllati da Google o per conto di Google. Un esempio è Keystore, che archivia e gestisce le chiavi di crittografia utilizzate per proteggere i dati at-rest archiviati nell'infrastruttura di Google.

Crittografia della rete tramite PSP

PSP Security Protocol (PSP) è indipendente dal trasporto, consente la sicurezza per connessione e supporta l'offload della crittografia per l'hardware SmartNIC (Smart Network Interface Card). Ogni volta che sono disponibili smartNIC, utilizziamo i PSP per criptare i dati in transito sulla nostra rete.

Il provider PSP è progettato per soddisfare i requisiti del traffico di data center su larga scala. Utilizziamo PSP per criptare il traffico all'interno e tra i nostri data center. PSP supporta protocolli non TCP, come UDP, e utilizza una chiave di crittografia per ogni connessione di livello 4.

Per ulteriori informazioni su come utilizziamo PSP, consulta la pagina relativa all'annuncio dell'offload dell'hardware crittografico di PSP su larga scala.

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.

L'app client interagisce con un servizio di handshake mediante un helper di processo e con l'app server attraverso uno scambio di chiavi.

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, e non Dialogflow, per comunicare con il Google Front End. Queste comunicazioni sono descritte nella crittografia della macchina virtuale a Google Front End.

Configurazione di altre crittografie nelle opzioni di trasporto pubblico

Puoi configurare le protezioni dei tuoi dati quando sono in transito tra Google Cloud e i tuoi data center oppure quando sono in transito tra le tue applicazioni ospitate su Google Cloud e i dispositivi degli utenti.

Se stai connettendo il tuo data center a Google Cloud, considera quanto segue:

Se stai connettendo i tuoi dispositivi utente ad applicazioni in esecuzione in Google Cloud, considera quanto segue:

  • Utilizza il supporto di TLS da parte del GFE configurando il certificato SSL che utilizzi. Ad esempio, puoi terminare la sessione TLS nell'applicazione.
  • Valuta i nostri certificati SSL automatici e gratuiti, disponibili per entrambi i domini personalizzati di Firebase Hosting e App Engine. Con i domini personalizzati di App Engine, puoi anche fornire i tuoi certificati SSL e utilizzare un'intestazione HTTP Strict Transport Security (HSTS).
  • Per i carichi di lavoro su GKE e Compute Engine, valuta la soluzione Anthos service mesh in modo da poter utilizzare mTLS per l'autenticazione, in modo da garantire che tutte le comunicazioni TCP siano criptate in transito.

Se utilizzi Google Workspace, configura Gmail per attivare S/MIME per le email in uscita, imposta i 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 dei dati in transito

Nel corso degli anni, abbiamo coinvolto diversi progetti open source e altre iniziative che incoraggiano l'utilizzo della crittografia in transito su Internet.

Tali sforzi includono:

Per ulteriori informazioni sui nostri contributi recenti, vedi Collaborazione con la community di ricerca sulla sicurezza.

Passaggi successivi

Note a piè di pagina

1 Le soluzioni per i partner includono entrambe le soluzioni offerte in Cloud Launcher, nonché i prodotti realizzati in collaborazione con i partner come Cloud Dataprep.
2 Puoi comunque disattivare questa crittografia, ad esempio per l'accesso HTTP ai bucket Google Cloud Storage.
3 Le comunicazioni da VM a servizio non protette al livello 7 sono comunque protette ai livelli 3 e 4.
4 Google supporta TLS 1.0 per i browser che utilizzano ancora questa versione del protocollo. Tieni presente che qualsiasi sito Google che elabora informazioni relative alle carte di credito non supporterà più TLS 1.0 entro luglio 2018, quando la conformità PCI (Payment Card Industry) ne richiederà il ritiro.
5 Per maggiori dettagli su QUIC, visita https://www.chromium.org/quic.
6, 7, 8 Per la compatibilità con alcune versioni precedenti di alcuni sistemi operativi, supportiamo 3DES, SHA1 e MD5.
9 Per i certificati concatenati, la CA è considerata attendibile in modo transitivo.
10 Potrebbe essere un ticket di sessione RFC 5077 o un ID sessione RFC 5246.
11 Il piano di controllo è la parte della rete che trasporta il traffico di segnalazione ed è responsabile del routing.
12 In precedenza erano stati utilizzati altri protocolli, ma ora sono deprecati. Meno dell'1% dei job utilizza questi protocolli precedenti.
13 DTLS (Datagram TLS) fornisce la sicurezza per le applicazioni basate su datagrammi, permettendo loro di comunicare in modo da evitare intercettazioni e manomissioni.