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 documento describe come abbiamo progettato Google Cloud la crittografia dei dati in transito da internet e dei 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 dei dati 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 (un essere umano o un processo) in una connessione.
- L'integrità impedisce che i dati inviati vengano modificati durante il transito tra l'origine e la destinazione.
- La crittografia utilizza la crittografia per rendere i dati illeggibili durante il transito e mantenerli riservati.
La crittografia dei dati in transito contribuisce a proteggere i 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 dei dati 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 dati da potenziali aggressori ed elimina la necessità per Google, Google Cloud i clienti o gli utenti finali di considerare attendibili i livelli inferiori della rete.
Modalità di routing del traffico
Questa sezione descrive come le richieste provenienti da un utente finale vengono inviate al servizio o all'applicazione del cliente appropriati Google Cloud e come il traffico viene instradato tra i servizi.
Un Google Cloud servizio è 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, Cloud Storage è un Google Cloud servizio.
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 Google Cloud servizi. Le applicazioni del cliente o le soluzioni dei partner ospitate su Google Cloud non sono considerate Google Cloud servizi. 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 Google Cloud servizio (etichettato A nel diagramma)
- Dall'utente finale su internet a un'applicazione del cliente ospitata su Google Cloud (etichettata B nel diagramma)
- Da una macchina virtuale a un'altra macchina virtuale (etichettata C nel diagramma)
- Da una macchina virtuale a Google Front End (GFE) (etichettata D nel diagramma)
- Dal GFE alle API di Google e ai servizi (etichettati E nel diagramma)
- Google Cloud Da unservizio a un altro Google Cloud servizio (etichettato F nel diagramma)
Crittografia dei dati 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
Google Cloud servizi come Cloud Storage o Compute Engine sono servizi cloud che offriamo ai clienti e che vengono eseguiti nel nostro ambiente di produzione. Google Cloud servizi accettano richieste da tutto il mondo utilizzando un sistema distribuito a livello globale chiamato Google Front End (GFE). Il GFE termina il traffico per le connessioni HTTP(S), TCP e TLS in entrata, offre contromisure agli attacchi DDoS e può bilanciare il carico del traffico e instradare il traffico verso i Google Cloud servizi stessi. I punti di presenza dei GFE si trovano in tutto il mondo e le relative route sono annunciate mediante unicast o Anycast.
Il GFE instrada il traffico da un utente finale sulla rete di Google a un Google Cloud servizio e da un utente finale a un'applicazione del cliente che è ospitata su Google Cloud e utilizza Cloud Load Balancing.
Le richieste che i client inviano a un Google Cloud servizio 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 i parametri di crittografia standard del settore, inclusa la negoziazione delle chiavi forward-secure. Per i client meno recenti e meno capaci, il 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 del 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 all' 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). Il GFE termina le connessioni TLS degli utenti finali utilizzando certificati TLS autogestiti 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), consulta Panoramica di mutual TLS. Per i carichi di lavoro su GKE e Compute Engine, valuta la possibilità di utilizzare Cloud Service Mesh per poter utilizzare mTLS per l'autenticazione reciproca (client e server) e criptare le comunicazioni in transito utilizzando i certificati che gestisci.
Per i domini personalizzati di Firebase Hosting e Cloud Run, valuta la possibilità di utilizzare 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 di Google
Google Cloud cripta i dati dei clienti in transito all'interno delle reti di Google, salvo diversamente specificato in questa sezione.
Le interconnessioni specializzate a prestazioni ultra elevate 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 a prestazioni ultra elevate 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. È tua responsabilità configurare la tua crittografia per queste connessioni.
Google Cloud Autenticazione e crittografia della rete virtuale
Google CloudLa rete virtuale di cripta, 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 viene eseguita a livello di rete. Google Cloud
Ogni coppia di host comunicanti stabilisce una chiave di sessione utilizzando un canale di controllo protetto da ALTS per comunicazioni autenticate, con integrità protetta e criptate. La chiave di sessione viene utilizzata per criptare le comunicazioni da VM a VM tra questi host; inoltre, 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. Sono incluse le connessioni tra le VM dei clienti e le VM dei clienti e gestite da Google, ad esempio Cloud SQL. Il diagramma in Modalità di routing del traffico mostra questa interazione (connessione con etichetta C). Tieni presente che, poiché Google attiva la crittografia automatica in base all'utilizzo degli indirizzi IP interni, le connessioni tra le VM che utilizzano indirizzi IP esterni non vengono criptate automaticamente.
Google CloudLa rete virtuale di autentica 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 della posizione del Google Cloud servizio è ospitato.
La maggior parte dei servizi e delle API di Google è ospitata nei GFE. Il traffico dalla VM al GFE utilizza indirizzi IP esterni per raggiungere i Google Cloud servizi; tuttavia, puoi configurare l'accesso privato per evitare di utilizzare indirizzi IP esterni. La connessione dal GFE al servizio viene 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 Google Cloud Autenticazione e crittografia della rete virtuale.
Quando un utente invia una richiesta a un Google Cloud servizio, proteggiamo i dati in transito (fornendo autenticazione, integrità e 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 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 è in grado di 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 Google Cloud servizio e da un Google Cloud servizio a un altro Google Cloud servizio.
ALTS utilizza identità basate sui servizi per l'autenticazione. Ai servizi in esecuzione nell'ambiente di produzione di Google vengono rilasciate 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 rilasciate dalla CA 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 i dati dal GFE a un servizio e tra i 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 contribuisce 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 criptare i dati in transito.
Crittografia di rete con 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). Ogni volta che le SmartNIC sono disponibili, ALTS utilizza PSP per criptare i dati in transito sulla 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 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 i certificati firmati e calcolano una chiave di traffico condivisa. Tra gli algoritmi che sono supportati per la derivazione della chiave di traffico condivisa c'è l'algoritmo post-quantistico NIST ML-KEM (FIPS 203). Per saperne di più, 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 è 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 saperne di più sulla sicurezza dei nostri data center, consulta data center security.
- Per informazioni sulle opzioni di configurazione della sicurezza per le interconnessioni tra Google Cloud le reti dei data center e dei clienti, consulta Scegliere un prodotto di connettività di rete (IPSec) e Panoramica di MACsec per Cloud Interconnect.
- Per informazioni su Google Cloud conformità e conformità certificazioni, consulta il Centro risorse per la conformità, che include il nostro report di controllo SOC 3.
- Per le best practice su come proteggere i dati in transito, consulta il blueprint Fondazioni aziendali, Google Cloud framework di architettura: sicurezza, privacy e conformità e Decidere come soddisfare i requisiti normativi per la crittografia dei dati in transito.