Questi contenuti sono stati aggiornati per l'ultima volta ad aprile 2025 e rappresentano lo status quo al momento della redazione. I criteri e i sistemi di sicurezza di Google potranno variare in futuro, in virtù del costante miglioramento della protezione per i nostri clienti.
In Google, i nostri controlli di sicurezza contribuiscono a 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 at-rest sia per quelli in transito. Questo articolo descrive come abbiamo progettato Google Cloud per criptare i dati in transito da internet e i dati in transito all'interno delle reti di Google. Questo documento non si applica ai dati in transito tramite interconnessioni tra le reti dei data center dei clienti e le reti dei data center di Google.
La crittografia in transito utilizza varie tecnologie per proteggere i dati, tra cui Transport Layer Security (TLS), BoringSSL, Application Layer Transport Security (ALTS) e il protocollo di sicurezza PSP. Oltre alla protezione predefinita fornita da Google, puoi proteggere ulteriormente i dati aggiungendo opzioni di crittografia come IPsec, certificati TLS gestiti e Cloud Service Mesh.
Questo documento è rivolto ai CISO e ai team per le operazioni di sicurezza che utilizzano o stanno prendendo in considerazione Google Cloud. Questo documento presuppone una conoscenza di base della crittografia e delle primitive crittografiche.
Autenticazione, integrità e crittografia
Google si avvale delle seguenti misure di sicurezza volte a garantire l'autenticità, l'integrità e la privacy dei dati in transito:
- L'autenticazione verifica l'identità di un peer (una persona o un processo) in una connessione.
- Integrità impedisce che i dati che invii vengano alterati durante il transito tra l'origine e la destinazione.
- La crittografia utilizza la crittografia per rendere i tuoi dati illeggibili durante il transito e mantenerli riservati.
La crittografia dei dati in transito protegge i tuoi dati durante il trasferimento tra l'utente finale e Google Cloud o tra due servizi, nel caso in cui le comunicazioni vengano intercettate. La crittografia in transito autentica gli endpoint e cripta i dati prima della trasmissione. All'arrivo, il destinatario decripta i dati e verifica che non siano stati modificati durante il transito.
La crittografia è uno dei componenti di una strategia di sicurezza più ampia. La crittografia dei dati in transito protegge i tuoi dati da potenziali malintenzionati ed elimina la necessità per Google, i clienti o gli utenti finali di fidarsi dei livelli inferiori della rete. Google Cloud
Modalità di routing del traffico
Questa sezione descrive come le richieste provenienti da un utente finale vengono inviate al servizioGoogle Cloud o all'applicazione del cliente appropriati e come il traffico viene instradato tra i servizi.
Un servizioGoogle Cloud è un servizio cloud modulare che offriamo ai nostri clienti. Questi servizi comprendono il calcolo, l'archiviazione dei dati, l'analisi dei dati e il machine learning. Ad esempio, Cloud Storage è un servizio Google Cloud .
Un'applicazione del cliente è un'applicazione ospitata su Google Cloud che, in quanto cliente Google, puoi creare e di cui puoi eseguire il deployment utilizzando i servizi Google Cloud. Le applicazioni del cliente o le soluzioni dei partner ospitate su Google Cloud non sono considerate servizi Google Cloud . Ad esempio, un'applicazione creata con Cloud Run, Google Kubernetes Engine o una VM in Compute Engine è un'applicazione del cliente.
Il seguente diagramma mostra i percorsi del traffico dall'utente finale a Google, i percorsi all'interno della rete di Google e la sicurezza per ogni connessione. Vengono mostrati i seguenti percorsi del traffico:
- Dall'utente finale su internet a un servizio (etichettato A nel diagramma) Google Cloud
- Dall'utente finale su internet a un'applicazione del cliente ospitata su Google Cloud (etichettato B nel diagramma)
- Da una macchina virtuale a un'altra macchina virtuale (etichettata C nel diagramma)
- Dalla macchina virtuale a Google Front End (GFE) (etichettato D nel diagramma)
- GFE a API di Google e servizi (etichettato E nel diagramma)
- Google Cloud al servizio Google Cloud (etichettato F nel diagramma)
Crittografia in transito tra l'utente finale e Google
Le sezioni seguenti forniscono maggiori dettagli sulle richieste di routing degli utenti finali mostrate nel diagramma precedente.
Dall'utente finale a un Google Cloud servizio
I serviziGoogle Cloud come Cloud Storage o Compute Engine sono servizi cloud che offriamo ai clienti e che vengono eseguiti nel nostro ambiente di produzione. I serviziGoogle Cloud accettano richieste da tutto il mondo utilizzando un sistema distribuito a livello globale chiamato Google Front End (GFE). GFE termina il traffico per le connessioni HTTP(S), TCP e TLS in entrata, fornisce contromisure agli attacchi DDoS e instrada e bilancia il carico del traffico verso i serviziGoogle Cloud . I punti di presenza dei GFE si trovano in tutto il mondo e i relativi percorsi sono annunciati mediante unicast o Anycast.
Il GFE instrada il traffico da un utente finale sulla rete di Google a un servizioGoogle Cloud e da un utente finale a un'applicazione del cliente ospitata su Google Cloud e che utilizza Cloud Load Balancing.
Le richieste che i client inviano a un servizio Google Cloud tramite HTTPS, HTTP/2 o HTTP/3 sono protette con TLS. Il protocollo TLS nel GFE è implementato con BoringSSL, un'implementazione open source del protocollo TLS gestita da Google. BoringCrypto, il nucleo di BoringSSL, è convalidato ai sensi di FIPS 140-3 livello 1.
Il GFE negozia con il client parametri crittografici standard del settore, inclusa la negoziazione delle chiavi con segretezza perfetta. Per i client meno recenti e meno capaci, GFE sceglie le primitive crittografiche legacy più efficaci offerte dal client.
Dall'utente finale a un'applicazione del cliente ospitata su Google Cloud
Puoi instradare il traffico degli utenti finali da internet alle tue applicazioni cliente ospitate su Google Cloud utilizzando una connessione diretta o tramite un bilanciatore del carico. Quando il traffico viene instradato direttamente, viene instradato all'indirizzo IP esterno del server VM che ospita l'applicazione.
Puoi utilizzare TLS con il bilanciatore del carico delle applicazioni esterno o il bilanciatore del carico di rete proxy esterno per connetterti alla tua applicazione in esecuzione su Google Cloud. Quando utilizzi un bilanciatore del carico di livello 7, la connessione tra l'utente finale e il bilanciatore del carico viene criptata utilizzando TLS per impostazione predefinita (a condizione che l'applicazione client dell'utente finale supporti TLS). GFE termina le connessioni TLS provenienti dagli utenti finali utilizzando i certificati TLS con gestione indipendente o gestiti da Google. Per saperne di più sulla personalizzazione del certificato, consulta Panoramica dei certificati SSL. Per attivare la crittografia tra il bilanciatore del carico e la VM che ospita l'applicazione del cliente, consulta Crittografia dal bilanciatore del carico ai backend.
Per configurare mutual TLS (mTLS), vedi Panoramica di mutual TLS. Per i workload su GKE e Compute Engine, valuta Cloud Service Mesh in modo da poter utilizzare mTLS per l'autenticazione reciproca (client e server) e criptare le comunicazioni in transito utilizzando i certificati che gestisci.
Per Firebase Hosting e i domini personalizzati di Cloud Run, prendi in considerazione i nostri certificati TLS senza costi e automatizzati. Con i domini personalizzati di Cloud Run, puoi anche fornire certificati SSL personali e utilizzare un'intestazione HTTP (HSTS Strict Transport Security).
Crittografia dei dati in transito all'interno delle reti Google
Google Cloud cripta i dati dei clienti in transito all'interno delle reti di Google, se non diversamente descritto in questa sezione.
Gli interconnessioni specializzate ad altissime prestazioni che collegano le TPU o le GPU all'interno dei supercomputer AI di Google sono separate dalle reti descritte in questo documento. In Google Cloud, queste interconnessioni ad altissime prestazioni sono ICI per le TPU e NVLink per le GPU. Per saperne di più, consulta Architettura TPU e Tipi di macchine GPU.
Il traffico sulle connessioni alle VM che utilizzano indirizzi IP esterni esce dalle reti di Google. Sei responsabile della configurazione della tua crittografia per queste connessioni.
Google Cloud Autenticazione e crittografia della rete virtuale
La rete virtuale diGoogle Cloudcripta, protegge l'integrità e autentica il traffico tra le VM.
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 Cloudviene eseguita a livello di rete.
Ogni coppia di host comunicanti stabilisce una chiave di sessione utilizzando un canale di controllo protetto da ALTS per comunicazioni autenticate, protette dall'integrità e criptate. La chiave di sessione viene utilizzata per criptare le comunicazioni da VM a VM tra questi host e le chiavi di sessione vengono ruotate periodicamente.
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 sono protette dall'integrità e criptate. Queste connessioni includono le connessioni tra le VM dei clienti e tra le VM dei clienti e quelle gestite da Google, ad esempio Cloud SQL. Il diagramma in Come viene instradato il traffico mostra questa interazione (connessione con etichetta C). Tieni presente che poiché Google attiva la crittografia automatica in base all'utilizzo di indirizzi IP interni, le connessioni tra VM che utilizzano indirizzi IP esterni non vengono criptate automaticamente.
La rete virtuale diGoogle Cloudautentica tutto il traffico tra le VM. Questa autenticazione, ottenuta tramite token di sicurezza, impedisce a un host compromesso di eseguire lo spoofing dei pacchetti sulla rete.
I token di sicurezza vengono incapsulati in un'intestazione del tunnel che contiene le informazioni di autenticazione relative al mittente e al destinatario. Il control plane sull'host di invio imposta il token, mentre l'host ricevente lo convalida. I token di sicurezza vengono pre-generati per ogni flusso e consistono di un token (contenente le informazioni del mittente) e del secret dell'host.
Connettività con i servizi e le API di Google
La gestione del traffico varia a seconda di dove è ospitato il servizio Google Cloud .
La maggior parte dei servizi e delle API di Google è ospitata sui GFE. Il traffico dalla VM al GFE utilizza indirizzi IP esterni per raggiungere i servizi Google, ma puoi configurare l'accesso privato per evitare di utilizzare indirizzi IP esterni. Google Cloud La connessione dal GFE al servizio è autenticata e criptata.
Alcuni servizi, come Cloud SQL, sono ospitati su istanze VM gestite da Google. Se le VM dei clienti accedono ai servizi ospitati su istanze VM gestite da Google utilizzando indirizzi IP esterni, il traffico rimane nella rete di produzione di Google, ma non viene criptato automaticamente a causa dell'utilizzo degli indirizzi IP esterni. Per saperne di più, consulta autenticazione e crittografia della rete virtuale diGoogle Cloud .
Quando un utente invia una richiesta a un servizio Google Cloud , proteggiamo i dati in transito (fornendo autenticazione, integrità e crittografia) utilizzando HTTPS con un certificato di un'autorità di certificazione web (pubblica). Tutti i dati che l'utente invia al GFE vengono criptati in transito con TLS o QUIC. Il GFE negozia un particolare protocollo di crittografia con il client in base a ciò che il client può supportare. Il GFE sceglie i protocolli di crittografia più moderni quando possibile.
Autenticazione, integrità e crittografia da un servizio all'altro
L'infrastruttura di Google utilizza ALTS per l'autenticazione, l'integrità e la crittografia delle connessioni dal GFE a un servizio Google Cloud e da un servizio Google Cloud a un altro Google Cloud .
ALTS utilizza identità basate sul servizio per l'autenticazione. I servizi in esecuzione nell'ambiente di produzione di Google ricevono credenziali che attestano le loro identità basate sui servizi. Quando effettua o riceve RPC da altri servizi, un servizio utilizza le proprie credenziali per l'autenticazione. ALTS verifica che queste credenziali siano emesse dall'autorità di certificazione interna di Google. La CA interna di Google non è correlata ed è indipendente dal Certificate Authority Service.
ALTS utilizza la crittografia e la protezione dell'integrità crittografica per il traffico che trasporta Google Cloud dati dal GFE a un servizio e tra servizi in esecuzione nell'ambiente di produzione di Google.
ALTS viene utilizzato anche per incapsulare altri protocolli del livello 7, ad esempio HTTP, nei meccanismi RPC per il traffico tra i GFE e i servizi Google Cloud. Questa protezione aiuta a isolare il livello dell'applicazione e rimuove qualsiasi dipendenza dalla sicurezza del percorso di rete.
Metodi di crittografia dei dati in transito
Le sezioni seguenti descrivono alcune delle tecnologie utilizzate da Google per crittografare i dati in transito.
Crittografia di rete tramite PSP
PSP è un protocollo indipendente dal trasporto che consente la sicurezza per connessione e supporta l'offload della crittografia all'hardware della scheda di interfaccia di rete intelligente (SmartNIC). Quando sono disponibili, le ALTS utilizzano PSP per criptare i dati in transito nella nostra rete.
PSP è progettato per soddisfare i requisiti del traffico dei data center su larga scala. L'infrastruttura di Google utilizza PSP per criptare il traffico all'interno e tra i nostri data center. PSP supporta anche protocolli non TCP come UDP e utilizza una chiave di crittografia univoca per ogni connessione.
Application Layer Transport Security
ALTS è un sistema di autenticazione reciproca e crittografia sviluppato da Google. ALTS fornisce autenticazione, riservatezza e integrità per i dati in transito tra i servizi in esecuzione nell'ambiente di produzione di Google. ALTS è costituito dai seguenti protocolli:
Protocollo di handshake:il client avvia uno scambio di chiavi combinato a curva ellittica e quantum-safe. Al termine dell'handshake, i servizi coinvolti autenticano le identità reciproche scambiando e verificando certificati firmati e calcolano una chiave di traffico condivisa. Tra gli algoritmi supportati per derivare la chiave di traffico condivisa c'è l'algoritmo post-quantistico NIST ML-KEM (FIPS 203). Per maggiori informazioni, consulta Crittografia post-quantistica.
Protocollo Record: i dati da servizio a servizio vengono criptati in transito utilizzando la chiave di traffico condivisa. Per impostazione predefinita, ALTS utilizza la crittografia AES-128-GCM per tutto il traffico. I dati in transito all'interno del sistema di archiviazione di livello più basso di Google utilizzano la crittografia AES-256 e ALTS fornisce l'autenticazione dei messaggi AES. La crittografia in ALTS viene fornita da BoringSSL o PSP. Questa crittografia è convalidata ai sensi di FIPS 140-2 livello 1 o FIPS 140-3 livello 1.
Le chiavi di firma radice per i certificati ALTS sono archiviate nella CA interna di Google.
Passaggi successivi
- Per ulteriori informazioni sulla sicurezza dei nostri data center, vedi Sicurezza dei data center.
- Per informazioni sulle opzioni di configurazione della sicurezza per le interconnessioni tra Google Cloud e le reti dei data center dei clienti, consulta Scelta di un prodotto Connettività di rete (IPsec) e Panoramica di MACsec per Cloud Interconnect.
- Per informazioni sulla conformità e sulle certificazioni di conformità, consulta il Centro risorse per la conformità, che include il nostro report di controllo SOC 3. Google Cloud
- Per le best practice su come proteggere i dati in transito, consulta il blueprint Enterprise foundations, il Google Cloud framework di architettura: sicurezza, privacy e conformità e Decidi come soddisfare i requisiti normativi per la crittografia in transito.