Questi contenuti sono stati aggiornati per l'ultima volta ad aprile 2025 e rappresentano lo status quo al momento della loro 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, che si tratti di dati in transito su internet, in transito all'interno dell'infrastruttura di Google o 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 come abbiamo progettato la crittografia dei dati in transito da internet e all'interno delle reti di Google.Google Cloud Questo documento non si applica ai dati in transito tramite le 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 contribuire a proteggere i dati, tra cui la crittografia TLS (Transport Layer Security), BoringSSL, la crittografia ALTS (Application Layer Transport Security) 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.
- L'integrità impedisce che i dati inviati 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 aiuta a proteggere i dati nel caso in cui le comunicazioni vengano intercettate durante il trasferimento dei dati tra l'utente finale e Google Cloud o tra due servizi. La crittografia in transito autentica gli endpoint e cripta i dati prima della trasmissione. Al loro 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 tutela i tuoi dati contro potenziali malintenzionati e non richiede a Google, ai clienti o agli 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 servizio o all'applicazione del cliente appropriati e come il traffico viene instradato tra i servizi.Google Cloud
Un servizioGoogle Cloud è un servizio cloud modulare che offriamo ai nostri clienti. Questi servizi includono computing, archiviazione dei dati, analisi dei dati e 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 servizi Google Cloud. 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 di traffico:
- Utente finale su internet a un Google Cloud servizio (contrassegnato come A nel diagramma)
- Dall'utente finale su internet a un'applicazione del cliente ospitata su Google Cloud (contrassegnata come B nel diagramma)
- Da una macchina virtuale a un'altra macchina virtuale (contrassegnata con C nel diagramma)
- Macchina virtuale a Google Front End (GFE) (contrassegnata con D nel diagramma)
- GFE alle API e ai servizi Google (contrassegnata come E nel diagramma)
- Google Cloud da un servizio a un altro Google Cloud (contrassegnato con F nel diagramma)
Crittografia dei dati in transito tra l'utente finale e Google
Le sezioni seguenti forniscono ulteriori dettagli sulle richieste di routing dell'utente finale riportate nel diagramma precedente.
Utente finale a un Google Cloud servizio
IGoogle Cloud servizi come Cloud Storage o Compute Engine sono servizi cloud che offriamo ai clienti e che vengono eseguiti nel nostro ambiente di produzione. IGoogle 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 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 vengono pubblicizzati utilizzando 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 inviate dai client 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 parametri crittografici standard di settore, tra cui la negoziazione delle chiavi con sicurezza progressiva. Per i client meno recenti e meno capaci, la GFE sceglie le primitive di crittografia precedenti più efficaci offerte dal client.
Utente finale a un'applicazione del cliente ospitata su Google Cloud
Puoi instradare il traffico degli utenti finali da internet alle applicazioni dei tuoi clienti ospitate su Google Cloud utilizzando una connessione diretta o un bilanciatore del carico. Quando il traffico viene instradato direttamente, viene indirizzato all'indirizzo IP esterno del server VM che ospita l'applicazione.
Puoi utilizzare TLS con il bilanciatore del carico delle applicazioni esterno o con 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 dei tuoi utenti finali utilizzando certificati TLS con gestione indipendente o gestiti da Google. Per ulteriori informazioni sulla personalizzazione del certificato, consulta la 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 TLS reciproco (mTLS), consulta la Panoramica di TLS reciproco. Per i workload su GKE e Compute Engine, valuta la possibilità di utilizzare 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 domini personalizzati Cloud Run, valuta la possibilità di utilizzare i nostri certificati TLS gratuiti e automatici. Con i domini personalizzati di Cloud Run, puoi anche fornire i tuoi certificati SSL 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.
Le interconnessioni ad alte prestazioni specializzate che collegano TPU o GPU all'interno dei supercomputer di IA 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 l'architettura TPU e i 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 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 per l'integrità e criptate. Queste connessioni includono le connessioni tra le VM dei clienti e le VM dei clienti e gestite da Google, ad esempio Cloud SQL. Il diagramma in Come viene indirizzato 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 piano di controllo sull'host di invio imposta il token, mentre l'host di destinazione 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 Google Cloud servizio.
La maggior parte dei servizi e delle API di Google è ospitata su GFE. Il traffico dalla VM al GFE utilizza indirizzi IP esterni per raggiungere i servizi Google Cloud ; tuttavia, puoi configurare l'accesso privato per evitare di utilizzare indirizzi IP esterni. 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 ulteriori informazioni, 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) 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 Google Cloud servizio e da un Google Cloud Google Cloud servizio all'altro.
ALTS utilizza le identità basate su servizio per l'autenticazione. Ai servizi in esecuzione nell'ambiente di produzione di Google vengono assegnate credenziali che attestano le loro identità basate su servizi. Quando effettua o riceve RPC da altri servizi, un servizio utilizza le proprie credenziali per effettuare l'autenticazione. ALTS verifica che queste credenziali siano state emesse dall'autorità di certificazione interna di Google. L'autorità di certificazione interna di Google non è correlata ed è indipendente dal servizio Certificate Authority.
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 GFE e 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 lo sgravio della crittografia sull'hardware delle schede di interfaccia di rete intelligenti (SmartNIC). Quando sono disponibili SmartNIC, 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 di handshake: il client avvia uno scambio di chiavi combinato a curva ellittica e sicuro per i computer quantistici. Al termine dell'handshake, i servizi coinvolti si autenticano a vicenda scambiando e verificando i certificati firmati e calcolano una chiave di traffico condivisa. Tra gli algoritmi supportati per dedurre la chiave di traffico condivisa è incluso l'algoritmo post-quantistico NIST ML-KEM (FIPS 203). Per maggiori informazioni, consulta la pagina Crittografia post-quantistica.
Protocollo Record: i dati tra servizi 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 primo livello 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 nell'autorità di certificazione 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 traGoogle Cloud e le reti dei data center dei clienti, consulta Scegliere un prodotto di Network Connectivity (IPSec) e Panoramica di MACsec per Cloud Interconnect.
- Per informazioni sulla Google Cloud conformità e sulle certificazioni di conformità, consulta il Centro risorse per la conformità, che include il nostro report di controllo SOC3.
- Per le best practice su come proteggere i dati in transito, consulta il blueprint Fondamenti aziendali, il Google Cloud Framework di architettura: sicurezza, privacy e conformità e Decidere come soddisfare i requisiti normativi per la crittografia in transito.