Crittografia dei dati in transito in Google Cloud

Questo è il terzo white paper sull'utilizzo della crittografia da parte di Google per la protezione dei tuoi dati. Abbiamo rilasciato anche i white paper Crittografia dei dati inattivi in Google Cloud Platform e Crittografia in G Suite. Potresti trovare utile leggere anche questi documenti per conoscere l'uso della crittografia in Google. In questo white paper, troverai maggiori dettagli sulla crittografia dei dati in transito per Google Cloud, compresi Google Cloud Platform e G Suite.

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.

I contenuti del presente documento sono aggiornati a dicembre 2017. Questo white paper rappresenta lo status quo al momento in cui sono stati redatti. I criteri e i sistemi di sicurezza di Google Cloud potrebbero variare in futuro, in virtù del costante miglioramento della protezione per i nostri clienti.

Crittografia dei dati in transito in Google Cloud

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.
  • Google crittografa e autentica tutti 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. I dati in transito all'interno di un confine fisico controllato da Google o per conto di Google sono generalmente autenticati, ma non necessariamente crittografati.
  • 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 e in qualunque luogo. 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.

Presentazione

La sicurezza è spesso un fattore decisivo nella scelta di un fornitore di servizi per la cloud pubblica. 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 vi 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 in 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 i tuoi dati inintelligibili durante il transito per garantirne la riservatezza. La crittografia è il processo attraverso il quale i dati leggibili (testo in chiaro) sono resi illeggibili (testo cifrato) 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 cifrato è 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 Introduzione alla crittografia moderna.

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 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 fornitore del servizio cloud o tra due servizi. Questa protezione viene ottenuta crittografando i dati prima della trasmissione, con l'autenticazione degli endpoint e con la decriptazione e la verifica dei dati all'arrivo. Ad esempio, al fine di garantire la sicurezza del trasporto viene spesso utilizzato Transport Layer Security (TLS) per la crittografia dei dati in transito, mentre Secure/Multipurpose Internet Mail Extensions (S/MIME) è la scelta più frequente per la sicurezza dei messaggi email.
  • Crittografia dei dati in uso: protegge i dati mentre vengono utilizzati dai server per eseguire calcoli; un esempio è la crittografia omomorfica.

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 della rete di Google

Google applica diversi metodi di protezione ai dati in transito quando vengono trasmessi al di fuori di un confine fisico controllato da Google o per conto di Google. 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 una piccola percentuale di dipendenti di Google ha accesso all'hardware. I dati in transito all'interno di questi confini fisici sono generalmente autenticati, ma potrebbero non essere crittografati per impostazione predefinita: puoi scegliere quali misure di sicurezza aggiuntive applicare in base al modello di minaccia.

A causa della portata globale di Internet, non possiamo mettere in atto questi stessi controlli di sicurezza fisici 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 altre tutele al di fuori del nostro confine di trust fisico. Questi sistemi di protezione includono la crittografia dei dati in transito.

Modalità di routing del traffico

Nella sezione precedente è stato spiegato il confine fisico della rete di Google e le modalità con cui applichiamo sistemi di protezione diversi ai dati inviati al di fuori di questo confine. 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 comprendono il computing, l'archiviazione dei dati, l'analisi dei dati e il machine learning. Ad esempio, Google Cloud Storage e Gmail sono entrambi servizi Google Cloud. Un'applicazione del cliente è un'applicazione ospitata su Google Cloud che tu, in qualità di cliente Google, puoi creare e distribuire utilizzando i servizi Google Cloud. Le applicazioni del cliente o le soluzioni dei partner ospitate in Google Cloud non sono considerate servizi Google Cloud1. Ad esempio, un'applicazione creata con 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 TLS, TCP e HTTP(S) in arrivo, offre contromisure agli attacchi DDoS e può 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 sulla nostra dorsale 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 a un'applicazione del cliente ospitata su Google Cloud in modi diversi. 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).

  • Utilizzo di un bilanciatore del carico esterno Google Cloud Load Balancer per l'indirizzamento proxy TCP/SSL o HTTP(S): un'applicazione del cliente ospitata sulle VM Google Compute Engine può utilizzare un servizio Google Cloud Load Balancer (GCLB) per terminare le connessioni HTTP(S), TLS o TCP e per indirizzare, instradare e distribuire questo traffico alle relative VM. Questi servizi di bilanciamento del carico sono implementati dai GFE, proprio come i GFE terminano e instradano il traffico per i servizi Google Cloud. Le connessioni vengono autenticate quando GCLB instrada il traffico tra i GFE e crittografate quando il traffico lascia un confine fisico controllato da Google o per conto di Google. Quando GCLB instrada il traffico tra un GFE e una macchina fisica che ospita una VM del cliente, questo traffico viene autenticato e crittografato quando lascia un confine fisico controllato da Google o per conto di Google. Per i bilanciatori del carico HTTPS, le connessioni tra gli utenti finali e i GFE vengono crittografate e autenticate con TLS o QUIC utilizzando i certificati forniti dai clienti per il bilanciamento del carico. Per i bilanciatori del carico HTTP, le connessioni tra gli utenti finali e i GFE non sono né crittografate né autenticate. Per i bilanciatori del carico SSL, le connessioni tra gli utenti finali e i GFE vengono crittografate con TLS, in modo simile all'utilizzo dei certificati forniti dal cliente. Per i bilanciatori del carico TCP, non esiste alcuna crittografia tra l'utente finale e i GFE. L'applicazione del cliente può tuttavia utilizzare la propria crittografia tra l'utente finale e le VM.
  • Utilizzo di una connessione diretta a una VM utilizzando un IP esterno o l'IP di un bilanciatore del carico di rete: se effettui la connessione tramite l'IP esterno della VM o tramite un IP con bilanciamento del carico di rete, la connessione non passa attraverso un GFE. Per impostazione predefinita questa connessione non viene crittografata e la sua sicurezza è fornita a discrezione dell'utente.
  • Utilizzo di Cloud VPN: se effettui la connessione da un host on-premise a una VM Google Cloud tramite una VPN, la connessione attraversa in sequenza l'host on-premise, la VPN on-premise, la VPN Google e la VM Google Cloud; la connessione non passa attraverso un GFE. La connessione dalla VPN on-premise alla VPN Google è protetta da IPsec. La connessione dalla VPN Google alla VM Google Cloud viene autenticata e crittografata quando tali comunicazioni lasciano un confine fisico controllato da Google o per conto di Google.
  • Utilizzo di Cloud Dedicated Interconnect: se effettui la connessione tramite Dedicated Interconnect, la connessione inizia e termina direttamente nell'host on-premise e non passa attraverso un GFE. Per impostazione predefinita questa connessione non è crittografata e la sua sicurezza è fornita a discrezione dell'utente.

Da una macchina virtuale a un'altra macchina virtuale

Il routing da VM a VM che avviene sulla nostra dorsale di rete, utilizzando gli indirizzi IP privati RFC 1918, potrebbe richiedere il routing del traffico al di fuori dei confini fisici controllati da Google o per conto di Google. Gli esempi di routing da VM a VM comprendono:

  • VM Compute Engine che inviano richieste l'una all'altra
  • VM del cliente che si connette a una VM gestita da Google come Cloud SQL

Le connessioni da VM a VM vengono crittografate quando lasciano un confine fisico e vengono autenticate all'interno del confine fisico. Il traffico da VM a VM, che utilizza indirizzi IP pubblici, non viene crittografato per impostazione predefinita e la sua sicurezza è fornita a discrezione dell'utente. La Figura 1 mostra questa interazione (connessione con etichetta C).

Da una macchina virtuale a un servizio Google Cloud

Se una VM instrada una richiesta a un servizio Google Cloud, la richiesta viene instradata a un GFE (tranne nei casi in cui il servizio Google Cloud è in esecuzione su una VM gestita da Google, come discusso sopra). Il GFE riceve la richiesta, quindi instrada la richiesta con le stesse modalità con cui instrada le richieste provenienti da Internet: il traffico da una VM a un servizio Google Cloud viene instradato attraverso percorsi Google privati agli stessi IP pubblici dei GFE. L'accesso privato a Google consente alle VM prive di IP pubblici di accedere ad alcuni servizi Google Cloud e alle applicazioni del cliente ospitate in Google App Engine. Tieni presente che, se una VM si connette a un'applicazione del cliente ospitata in Google Compute Engine o Google Kubernetes Engine, il relativo traffico viene instradato allo stesso modo delle richieste provenienti da Internet, ossia su percorsi esterni. La Figura 1 mostra questa interazione (connessione con etichetta D). Un esempio di questo tipo di richiesta di routing è tra una VM Compute Engine e Google Cloud Storage o un'API Machine Learning. Per impostazione predefinita, i servizi Google Cloud supportano la protezione di queste connessioni con TLS2. Questa protezione è attiva dalla VM al GFE. La connessione viene autenticata dal GFE al servizio e viene crittografata quando la connessione lascia un confine fisico.

Da un servizio Google Cloud a un altro servizio Google Cloud

Il routing da un servizio di produzione all'altro avviene sulla nostra dorsale 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 crittografate quando lasciano un confine fisico e vengono autenticate all'interno del confine fisico.

Figura 1: protezione predefinita e opzioni sovrapposte sulla rete di Google

Crittografia predefinita dei dati in transito

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 opzionali e predefinite applicate da Google Cloud per i livelli 3, 4 e 7.

Figura 2: protezione 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 indirizzando il protocollo su una connessione TLS, garantendo 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 possiede il 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 mantenuta da Google del protocollo TLS, ottenuta mediante fork da OpenSSL e per la maggior parte compatibile a livello di interfaccia con OpenSSL. Google ha effettuato il fork di BoringSSL da OpenSSL 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 dal GFE durante la comunicazione con i client.

Protocolli Autenticazione Scambio di chiavi Crittografia Funzioni hash
TLS 1.34 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 SHA18
TLS 1.05     AES-256-CBC MD59
QUIC6     ChaCha20-Poly1305  
      3DES7  

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. Dopo la presentazione, il certificato viene firmato da un'autorità di certificazione (CA) emittente che è considerata attendibile dall'utente che richiede la connessione10. 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 maniera ubiqua, comprendenti Symantec ("GeoTrust") e le CA radice precedentemente gestite 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 della chiave 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 CA radice richiede una cerimonia delle chiavi. In Google, la cerimonia richiede che almeno 3 dei 6 possibili individui autorizzati si radunino fisicamente per utilizzare 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 di 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 durate 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 privata11 per riprendere una sessione precedente con un handshake TLS abbreviato: questi ticket sono pertanto 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 ulteriori informazioni sulla rotazione delle chiavi ticket di sessione, vedi 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 impostazione predefinita. 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 delle reti virtuali di Google Cloud

L'infrastruttura di rete virtuale di Google Cloud consente la crittografia quando il traffico supera i nostri confini fisici. La crittografia viene eseguita a livello di rete e si applica al traffico IP privato all'interno della stessa Virtual Private Cloud (VPC) o su reti VPC in peering.

Partiamo dal presupposto che qualsiasi rete che attraversa un confine fisico non controllato da Google o per conto di Google può essere compromessa da un utente malintenzionato attivo, che può spiare, iniettare o alterare il traffico in transito. Garantiamo l'integrità e la privacy delle comunicazioni utilizzando la crittografia durante il trasferimento dei dati al di fuori dei confini fisici che non controlliamo.

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 controllo12 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 segreto dell'host. Esiste un segreto per ogni coppia mittente-destinatario di confini fisici controllati da Google o per conto di Google. La Figura 4 mostra come vengono create le chiavi token, i segreti degli host e i token di sicurezza.

Figura 4: token di sicurezza

Il segreto del confine fisico è un numero pseudocasuale a 128 bit, da cui i segreti dell'host vengono derivati con l'acquisizione di un HMAC-SHA1. Il segreto del confine fisico è negoziato mediante un handshake tra i piani di controllo della rete di una coppia di confini fisici e viene rinegoziato ogni poche ore. 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.

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 possono essere configurati per accettare e inviare comunicazioni ALTS solo nella modalità "autenticazione, integrità e privacy", anche all'interno dei confini fisici controllati da Google o per conto di Google. Un esempio è il servizio di gestione delle chiavi interno di Google, che archivia e gestisce le chiavi di crittografia utilizzate per proteggere i dati inattivi archiviati nell'infrastruttura di Google.

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.

La Figura 5 mostra l'handshake ALTS nel dettaglio. Nelle implementazioni più recenti è un helper di processo a occuparsi dell'handshake; vi 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. La chiave privata e il certificato corrispondente (buffer di protocollo firmato) sono stati predisposti per l'identità dell'account di servizio.

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 interna (CA) 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-GCM13. 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)14
  • 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 ALTS, per comunicare con il Google Front End. Queste comunicazioni sono descritte in Crittografia dalla macchina virtuale al Google Front End.

Crittografia dalla macchina virtuale al Google Front End

Il traffico dalla VM al GFE utilizza indirizzi IP esterni per raggiungere i servizi Google; tuttavia, puoi configurare la funzione Accesso privato Google per utilizzare gli indirizzi IP solo di Google per le richieste.

Come nel caso delle richieste a Google provenienti da un utente esterno, supportiamo per impostazione predefinita il traffico TLS da una VM al GFE. La connessione avviene allo stesso modo di qualsiasi altra connessione esterna. Per ulteriori informazioni su TLS, vedi Transport Layer Security (TLS).

Opzioni configurabili dall'utente per la crittografia dei dati in transito

La crittografia dei dati in transito descrive i sistemi di protezione predefiniti applicati da Google ai dati in transito. Questa sezione descrive le configurazioni che i nostri utenti possono eseguire con questi sistemi di protezione predefiniti.

Dal data center on-premise a Google Cloud

TLS con bilanciatori del carico esterni GCLB

Se il servizio cloud utilizza un bilanciatore di carico esterno Google HTTPS o SSL Proxy, GFE termina le connessioni TLS provenienti dai tuoi utenti utilizzando i certificati SSL di cui esegui il provisioning e che controlli. Ulteriori informazioni sulla personalizzazione del certificato sono disponibili nella nostra documentazione sui certificati SSL.

Tunnel IPsec con VPN Google Cloud

In qualità di cliente Google Cloud, puoi utilizzare la VPN Google Cloud per connettere in modo sicuro la tua rete on-premise alla rete VPC (Virtual Private Cloud) di Google Cloud Platform tramite una connessione VPN IPsec (livello 3). Il traffico tra le due reti viene crittografato da un gateway VPN e decriptato dall'altro gateway VPN. Questa scelta protegge i tuoi dati su Internet. Inoltre, puoi impostare più tunnel con bilanciamento del carico attraverso molteplici gateway VPN. La VPN Google Cloud protegge i tuoi dati nei seguenti modi:

  • I pacchetti dalle tue VM alla VPN Cloud rimangono nella rete di Google. Questi pacchetti vengono crittografati dalla rete virtuale di Google Cloud se si spostano al di fuori dei confini fisici controllati da Google o per conto di Google.
  • I pacchetti dalla VPN Cloud alla VPN on-premise vengono crittografati e autenticati utilizzando un tunnel IPsec.
  • I pacchetti dalla VPN on-premise agli host on-premise vengono protetti da qualsiasi controllo in atto sulla rete.

Per configurare una VPN, crea un gateway Cloud VPN e un tunnel sulla rete VPC del servizio ospitato, quindi consenti il traffico tra le reti. Hai anche la possibilità di configurare una VPN tra due VPC.

Puoi personalizzare ulteriormente la rete specificando la versione IKE (Internet Key Exchange)15 per il tunnel VPN. Puoi scegliere tra due versioni di IKE, IKEv1 e IKEv2, ognuna delle quali supporta crittografie diverse. Se specifichi IKEv1, Google crittografa i pacchetti utilizzando AES-128-CBC e fornisce l'integrità tramite l'HMAC SHA-116. Per IKEv2 sono disponibili e supportate svariate crittografie. In tutti i casi, la VPN Google Cloud negozierà il protocollo comune più sicuro supportato dai dispositivi peer. Le istruzioni complete sulla configurazione di una VPN sono disponibili nella nostra documentazione Scelta di un'opzione di routing VPN.

Un'alternativa al tunnel IPsec è Google Cloud Dedicated Interconnect. Dedicated Interconnect fornisce connessioni fisiche dirette e comunicazioni RFC 1918 tra la rete on-premise e la rete di Google. I dati in transito su questa connessione NON sono crittografati per impostazione predefinita e devono quindi essere protetti al livello dell'applicazione, ad esempio utilizzando TLS. La VPN Google Cloud e Google Cloud Interconnect utilizzano lo stesso punto di collegamento in modo da poter utilizzare la crittografia VPN IPsec con Dedicated Interconnect; tuttavia per ottenere questo risultato, è necessario utilizzare una soluzione di terze parti. MACsec (protezione di livello 2) non è attualmente supportato.

Dall'utente al Google Front End

Certificati SSL gestiti: certificati gratuiti e automatizzati

Quando crei un'applicazione in Google Cloud, puoi sfruttare il supporto di TLS da parte del GFE configurando il certificato SSL utilizzato. Ad esempio, puoi terminare la sessione TLS nell'applicazione. Questa terminazione è diversa dalla terminazione di TLS descritta in TLS con bilanciatori del carico esterni GCLB.

Google fornisce inoltre certificati SSL gratuiti e automatizzati sia in Firebase Hosting che nei domini personalizzati di Google App Engine. Questi certificati sono disponibili solo per le proprietà ospitate da Google. Con i domini personalizzati di Google App Engine, puoi anche fornire certificati SSL personali e utilizzare un'intestazione HSTS (HTTPS Strict Transport Protocol).

Quando il tuo dominio è indirizzato all'infrastruttura di Google, chiediamo e otteniamo un certificato per quel dominio per consentire comunicazioni sicure. Gestiamo le chiavi private del server TLS, che sono RSA a 2048 bit o ECC secp256r1, e rinnoviamo i certificati per conto dei nostri clienti.

Richiesta di TLS in Gmail

Come spiegato in Transport Layer Security, Gmail utilizza TLS per impostazione predefinita. Gmail registra e indica se l'ultimo trasferimento di un messaggio email è avvenuto su una sessione TLS17. Quando un utente Gmail scambia un messaggio email con un altro utente Gmail, le email sono protette da TLS o, in alcuni casi, inviate direttamente all'interno dell'applicazione. In questi casi, le RPC utilizzate dall'applicazione Gmail sono protette con ALTS come descritto in Autenticazione, integrità e crittografia da un servizio all'altro. Per i messaggi in arrivo da altri provider email, Gmail non applica TLS. Gli amministratori di Gmail possono configurare Gmail per richiedere una connessione TLS sicura per tutte le email in entrata e in uscita.

S/MIME di Gmail

S/MIME (Secure/Multipurpose Internet Mail Extensions) è uno standard di sicurezza email che fornisce autenticazione, integrità e crittografia. L'implementazione dello standard S/MIME impone che i certificati associati agli utenti che inviano email siano ospitati in una CA pubblica.

In qualità di amministratore, puoi configurare Gmail per abilitare S/MIME per le email in uscita, impostare i criteri per la conformità dei contenuti e degli allegati e creare regole di routing per le email in entrata e in uscita. Dopo la configurazione, devi caricare i certificati pubblici degli utenti in Gmail utilizzando l'API Gmail. Per gli utenti esterni a Gmail, è necessario scambiare un messaggio iniziale firmato con S/MIME per impostare S/MIME come scelta predefinita.

Crittografia da servizio a servizio e da VM a VM

Istio è una mesh di servizi open source sviluppata da Google, IBM, Lyft e altri per semplificare l'individuazione e la connettività dei servizi. L'autenticazione Istio fornisce la crittografia automatica dei dati in transito tra i servizi e la gestione delle chiavi e dei certificati associati. Istio può essere utilizzato in Google Kubernetes Engine e Google Compute Engine.

Se vuoi implementare l'autenticazione reciproca e la crittografia per i carichi di lavoro, puoi utilizzare l'autenticazione Istio. In particolare, per un carico di lavoro in Kubernetes, l'autenticazione Istio consente a una CA a livello di cluster di generare e distribuire certificati successivamente utilizzati per mTLS (mutual Transport Layer Security) da pod a pod.

Contributo di Google alla crittografia dei dati in transito su Internet

Le sezioni Crittografia predefinita dei dati in transito e Opzioni configurabili dall'utente per la crittografia dei dati in transito hanno descritto le misure di protezione predefinite e personalizzabili applicate da Google Cloud per i dati in transito dei clienti. Google prevede inoltre vari progetti open source e altre attività che incoraggiano l'uso della crittografia dei dati in transito e la sicurezza dei dati su Internet su vasta scala.

Certificate Transparency

Come descritto nella sezione Crittografia dall'utente al Google Front End, per offrire HTTPS un sito deve prima richiedere un certificato a un'autorità di certificazione (CA) sul Web (pubblica) considerata attendibile. L'autorità di certificazione ha la responsabilità di verificare che il richiedente sia autorizzato dal titolare del dominio, nonché di garantire che tutte le altre informazioni incluse nel certificato siano accurate.Il certificato viene poi presentato al browser per l'autenticazione del sito a cui l'utente sta tentando di accedere. Per garantire la corretta autenticazione di HTTPS, è importante assicurare che le CA emettano solo i certificati autorizzati dal titolare del dominio.

Certificate Transparency (CT) è un progetto lanciato da Google nel mese di marzo 2013 per offrire agli operatori di siti e ai titolari di domini un mezzo per scoprire se una CA ha emesso certificati non autorizzati o non corretti. CT fornisce a titolari di dominio, autorità di certificazione e pubblico generico un meccanismo per registrare i certificati attendibili che incontrano o, nel caso delle CA, che rilasciano, all'interno di log verificabili pubblicamente, di sola aggiunta e a prova di manomissione. I certificati in questi log possono essere esaminati da chiunque per garantire che le informazioni siano corrette, accurate e autorizzate.

La prima versione di Certificate Transparency è stata specificata in una RFC sperimentale di IETF, RFC 6962. Durante lo sviluppo di Certificate Transparency, Google ha definito numerosi strumenti open source, tra cui un server di log open source in grado di registrare certificati, nonché gli strumenti per creare i log di Certificate Transparency. Inoltre, Google Chrome richiede che alcuni certificati siano divulgati pubblicamente, ad esempio i certificati EV (Extended Validation) o i certificati emessi da CA che in passato hanno rilasciato certificati in maniera impropria. Dal 2018, Chrome richiederà la divulgazione di tutti i nuovi certificati pubblicamente attendibili.

Come operatore del sito, puoi utilizzare Certificate Transparency per rilevare se sono stati emessi certificati non autorizzati per il tuo sito web. Sono disponibili numerosi strumenti gratuiti per semplificare questa operazione, come il rapporto su Certificate Transparency di Google, Certificate Search o gli strumenti di Facebook. Anche se non utilizzi Certificate Transparency, alcuni browser esaminano regolarmente Certificate Transparency per garantire che le CA considerate attendibili dagli utenti per l'accesso al tuo sito web rispettino i requisiti e le best practice del settore, riducendo il rischio di emissione di certificati fraudolenti.

Aumento dell'utilizzo di HTTPS

Come descritto nella sezione Crittografia dall'utente al Google Front End, lavoriamo duramente per assicurarci che i nostri siti e servizi forniscano per impostazione predefinita il moderno protocollo HTTPS. Il nostro obiettivo è raggiungere un livello di crittografia pari al 100% tra i nostri prodotti e servizi. A tal fine, pubblichiamo un rapporto annuale sulla trasparenza di HTTPS che rileva i nostri progressi verso l'obiettivo per tutte le proprietà, compreso Google Cloud. Continuiamo a lavorare per superare le barriere tecniche che rendono difficile il supporto della crittografia in alcuni dei nostri prodotti, ad esempio con soluzioni per browser o altri client che non supportano il protocollo HSTS (HTTPS Strict Transport Protocol18. Utilizziamo HSTS per alcuni dei nostri siti, compresa la home page di google.com, per consentire agli utenti di connettersi a un server solo tramite HTTPS.

Sappiamo che il resto di Internet sta lavorando al passaggio ad HTTPS. Cerchiamo di facilitare questo passaggio nei seguenti modi:

Nel 2016 abbiamo iniziato a pubblicare le metriche "Utilizzo di HTTPS su Internet" per i primi 100 siti non Google su Internet. L'obiettivo di queste metriche è aumentare la conoscenza e contribuire a rendere Internet un luogo più sicuro per tutti gli utenti. Nel mese di ottobre 2017, Chrome ha formalmente rinnovato il suo sostegno finanziario a Let's Encrypt in qualità di sponsor Platinum.

Aumento dell'utilizzo di SMTP sicuro: indicatori Gmail

La maggior parte delle email viene scambiata utilizzando il protocollo SMTP (Simple Mail Transfer Protocol) che, per impostazione predefinita, invia email senza utilizzare la crittografia. Per crittografare un messaggio email, il provider deve implementare controlli di sicurezza come TLS.

Come spiegato nella sezione Crittografia dall'utente al Google Front End, Gmail utilizza TLS per impostazione predefinita. Inoltre, la sezione Richiesta di TLS in Gmail descrive come gli amministratori di Gmail possono imporre l'uso della protezione TLS per le email in arrivo e in uscita. Analogamente all'impegno di Google per la trasparenza HTTPS, Gmail fornisce dati sull'utilizzo di TLS per le email in arrivo su Gmail. Questi dati sono presentati nel nostro rapporto sulla trasparenza per email più sicure.

Google, in collaborazione con IETF e altri importanti membri del settore, sta guidando lo sviluppo di SMTP STS, simile ad HSTS per HTTPS, che impone l'uso di SMTP solo su canali crittografati.

API di Chrome

A febbraio 2015, Chrome ha annunciato la disponibilità di nuove e potenti funzionalità per le sole origini sicure19. Tali funzionalità includono la gestione delle informazioni private e l'accesso ai sensori sul dispositivo dell'utente. A partire dalla geolocalizzazione in Chrome 50, abbiamo iniziato a ritirare queste funzionalità per le origini non sicure.

Innovazione continua nella crittografia dei dati in transito

Esperienza utente relativa alla sicurezza in Chrome

Google Chrome è leader del settore grazie all'intuitività della sua interfaccia utente che permette agli utenti di avere una visibilità completa delle informazioni sulla sicurezza e verificare rapidamente se la loro connessione a un sito è sicura. Con queste informazioni, gli utenti possono prendere decisioni informate in merito a quando e come condividere i loro dati. Chrome svolge estese ricerche sugli utenti, condividendo i risultati in articoli sottoposti a revisione paritaria.

Per contribuire a proteggere ulteriormente i suoi utenti, Chrome ha annunciato che entro la fine del 2017 contrassegnerà tutte le connessioni HTTP come non sicure. A partire da Chrome 56, gli utenti vedranno per impostazione predefinita un avviso se una pagina HTTP contiene un modulo con campi relativi a password o carte di credito. In Chrome 62, sarà visualizzato un avviso quando un utente inserisce dati in una pagina HTTP e per tutte le pagine HTTP visitate nella modalità di navigazione in incognito. Alla fine, Chrome mostrerà un avviso per tutte le pagine gestite tramite HTTP.

Per comprendere la modalità di visualizzazione di particolari configurazioni per gli utenti in Chrome, puoi utilizzare lo strumento BadSSL.

Trasparenza delle chiavi

Un importante deterrente all'adozione diffusa della crittografia dei messaggi è la difficoltà nello scambio di chiavi pubbliche: come posso trovare in modo affidabile la chiave pubblica di un nuovo utente con cui sto comunicando? Per contribuire a risolvere questo problema, nel gennaio 2017 Google ha annunciato Key Transparency. Si tratta di un framework aperto che fornisce un mezzo generico, sicuro e controllabile per distribuire le chiavi pubbliche. Il framework elimina la necessità di eseguire la verifica manuale delle chiavi da parte degli utenti. Key Transparency è destinato principalmente alla distribuzione delle chiavi pubbliche degli utenti nelle comunicazioni, ad esempio per la crittografia dei messaggi email E2E e OpenPGP. Il design di Key Transparency rappresenta un nuovo approccio al recupero e alla distribuzione delle chiavi e si basa sulle conoscenze acquisite con Certificate Transparency e CONIKS.

Lo sviluppo di Key Transparency è open source e viene implementato utilizzando una struttura ad albero Merkle su larga scala. Key Transparency Verification consente ai proprietari degli account di vedere quali chiavi sono state associate ai loro account e per quanto tempo un account è rimasto attivo e stabile. L'obiettivo a lungo termine del progetto Key Transparency di Google è consentire a chiunque di gestire un server Key Transparency e di integrarlo facilmente in un numero illimitato di applicazioni.

Crittografia post-quantistica

Google intende rimanere il leader nel settore della crittografia dei dati in transito. A tal fine, abbiamo iniziato a lavorare nell'area della crittografia post-quantistica. Questo tipo di crittografia consente di sostituire le primitive di crittografia esistenti, vulnerabili agli efficienti attacchi quantistici, con candidati post-quantistici che sono considerati più solidi contro questo genere di attacchi. A luglio 2016 abbiamo annunciato lo svolgimento di un esperimento sulla fattibilità della distribuzione di tale algoritmo utilizzando l'algoritmo di crittografia post-quantistica New Hope nella versione per sviluppatori di Chrome. Oltre a questo lavoro, i ricercatori di Google hanno pubblicato documenti su altri protocolli pratici per lo scambio di chiavi post-quantistico.

Appendice

Scopri di più sulla sicurezza di Google Cloud, anche con la nostra Panoramica sulla progettazione della sicurezza dell'infrastruttura, e sulla conformità di Google Cloud, anche con il rapporto di controllo SOC 3.

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 nel livello 7 sono comunque protette nei livelli 3 e 4.
4 TLS 1.3 non è ancora finalizzato. La versione bozza è implementata per scopi di test solo in determinati domini di Google, come ad esempio Gmail.
5 Google supporta TLS 1.0 per i browser che ancora utilizzano 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.
6 Per i dettagli su QUIC, visita https://www.chromium.org/quic.
7, 8, 9 Per la compatibilità con alcuni sistemi operativi precedenti, supportiamo 3DES, SHA1 e MD5.
10 Per i certificati concatenati, la CA è considerata attendibile in modalità transitiva.
11 Potrebbe essere un ticket di sessione (RFC 5077) o un ID di sessione (RFC 5246).
12 Il piano di controllo è la parte della rete che trasporta il traffico di segnalazione ed è responsabile del routing.
13 In precedenza erano utilizzati altri protocolli che successivamente sono stati ritirati. Meno dell'1% dei job utilizza questi protocolli precedenti.
14 DTLS (Datagram TLS) fornisce la sicurezza per le applicazioni basate su datagrammi, consentendo loro di comunicare in modo da impedire intercettazioni e manomissioni.
15 IKE (Internet Key Exchange) è il protocollo utilizzato per configurare un'associazione di sicurezza nella suite di protocolli IPsec.
16 HMAC-SHA-1 non viene interrotto da una collisione SHA-1, come la collisione SHAttered individuata dai ricercatori di Google.
17 Per G Suite Enterprise, questa informazione non è mostrata nell'interfaccia utente. Gli amministratori di dominio possono esaminare i dati del loro dominio utilizzando Ricerca log email.
18 HTTPS Strict Transport Protocol è un meccanismo che consente ai siti web di dichiararsi accessibili solo tramite connessioni sicure e/o che permette agli utenti di indirizzare i loro agenti utente per interagire con determinati siti solo su connessioni sicure.
19 Le origini sicure sono connessioni che rispettano determinati pattern di schemi, host o porte.

Hai trovato utile questa pagina? Facci sapere cosa ne pensi:

Invia feedback per...