Questo documento fornisce dettagli sulla crittografia in transito di Google Distributed Cloud (GDC) con air gap.
Riepilogo a livello di CIO
- GDC si avvale di diverse misure di sicurezza volte a garantire l'autenticità, l'integrità e la riservatezza dei dati in transito.
- A seconda della connessione effettuata, GDC applica le misure di protezione predefinite ai dati in transito per i componenti GDC. Ad esempio, proteggiamo le comunicazioni tra l'utente e il gateway di ingresso GDC Cloud Service Mesh utilizzando TLS.
Introduzione
La sicurezza è spesso un fattore decisivo nella scelta di un cloud provider. Per Google la sicurezza è un tema di fondamentale importanza. Lavoriamo senza sosta per proteggere i tuoi dati durante i trasferimenti sulla tua rete, negli spostamenti all'interno dell'infrastruttura di Google o semplicemente mentre sono archiviati sui nostri server.
Al centro della strategia di sicurezza di Google ci sono l'autenticazione, l'integrità e la crittografia, sia per i dati inattivi sia per quelli in transito. Questo documento descrive il nostro approccio alla crittografia dei dati in transito per Google Distributed Cloud con air gap (GDC).
Per i dati inattivi, consulta Crittografia dei dati inattivi. 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 GDC.
Prerequisiti: oltre a questa introduzione, è necessaria una conoscenza di base della crittografia e delle primitive crittografiche.
Autenticazione, integrità e crittografia
GDC si avvale di diverse misure di sicurezza volte a garantire l'autenticità, l'integrità e la riservatezza dei dati in transito.
- Autenticazione: autentichiamo la destinazione dei dati sul livello di rete. L'origine viene autenticata da AIS gestito da GDC.
- Integrità: ci assicuriamo che i dati inviati arrivino a destinazione inalterati, ovvero protetti da modifiche non autorizzate.
- Crittografia: rendiamo i tuoi dati illeggibili durante il transito per garantirne la riservatezza. La crittografia è il processo attraverso il quale i dati leggibili (testo non crittografato) sono resi illeggibili (testo crittografato) con l'obiettivo di garantire che il testo non crittografato sia accessibile solo alle parti autorizzate dal proprietario dei dati. Gli algoritmi utilizzati nel processo di crittografia sono pubblici, ma la chiave necessaria per decriptare il testo crittografato è privata. La crittografia dei dati in transito spesso utilizza lo scambio di chiavi asimmetriche, ad esempio l'algoritmo Diffie-Hellman basato su una curva ellittica, per stabilire una chiave simmetrica condivisa utilizzata per la crittografia dei dati. Per ulteriori informazioni sulla crittografia, consulta Introduction to Modern Cryptography.
La crittografia può essere utilizzata per proteggere i dati in più stati:
- La crittografia dei dati inattivi protegge i dati in caso di compromissione del sistema o di esfiltrazione di 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 cloud provider o tra due servizi. Questa protezione viene ottenuta crittografando i dati prima della trasmissione, con l'autenticazione degli endpoint e con la decrittografia e la verifica dei dati all'arrivo. Ad esempio, Transport Layer Security (TLS) viene spesso utilizzato per criptare i dati in transito per la sicurezza del trasporto, mentre Secure/Multipurpose Internet Mail Extensions (S/MIME) viene spesso utilizzato per la crittografia dei messaggi email.
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 GDC alla crittografia dei dati in transito e ne descrive i punti di applicazione.
Infrastruttura di rete GDC
Confini fisici
Un confine fisico è la barriera da superare per raggiungere uno spazio fisico controllato da Google o in coordinamento con Google, nel quale possiamo garantire l'applicazione di rigorose misure di sicurezza. L'accesso fisico a queste località è limitato, fortemente monitorato e sottoposto ad audit. Solo un numero limitato di personale approvato ha accesso all'hardware. I dati in transito all'interno di questi confini fisici sono generalmente autenticati e criptati.
Per le comunicazioni che attraversano il confine fisico del GDC, utilizziamo una crittografia e un'autenticazione avanzate per proteggere i dati in transito.
Modalità di routing del traffico
Per comprendere come funziona la crittografia dei dati in transito in GDC, è necessario spiegare come viene instradato il traffico verso e attraverso GDC. Questa sezione descrive come le richieste provenienti da un utente finale vengono inviate al servizio GDC o all'applicazione del cliente appropriati e come il traffico viene instradato tra i servizi cross-site.
Un servizio gestito da GDC è un servizio cloud privato modulare. Questi servizi includono calcolo, archiviazione e machine learning. Ad esempio, l'archiviazione di oggetti GDC è un servizio gestito da GDC. Un'applicazione del cliente è un'applicazione ospitata su GDC che, in quanto cliente GDC, puoi creare e di cui puoi eseguire il deployment utilizzando i servizi GDC. Le applicazioni del cliente o le soluzioni dei partner ospitate su GDC non sono considerate servizi gestiti da GDC. Ad esempio, un'applicazione creata utilizzando VM GDC, Database Service e Vertex AI è un'applicazione del cliente.
La Figura 1 mostra diversi tipi di richieste di routing. La Figura 1 mostra le interazioni tra i vari componenti della rete e la sicurezza in atto per ciascuna connessione.
Figura 1: infrastruttura di connettività tra siti
Dall'utente finale (rete del cliente) all'API GDC e al servizio gestito
Per i servizi gestiti ospitati sui gateway in entrata di Cloud Service Mesh, accettano richieste dalla rete del cliente utilizzando il gateway in entrata di Cloud Service Mesh. Cloud Service Mesh Ingress Gateway indirizza il traffico per HTTP(S) in entrata e instrada e bilancia il carico del traffico verso i servizi gestiti da GDC. Un altro livello di firewall fornisce contromisure contro gli attacchi DDoS con rilevamento e prevenzione delle intrusioni. Questa connessione viene autenticata e criptata da Cloud Service Mesh Ingress Gateway al frontend del servizio gestito da GDC. La Figura 1 mostra questa interazione come connessione A.
La maggior parte delle API GDC e dei servizi gestiti sono ospitati sui gateway di ingresso Cloud Service Mesh. Tuttavia, alcuni servizi sono ospitati direttamente sul bilanciatore del carico di livello 4 gestito da GDC. Ad esempio, i database DBS sono ospitati su un bilanciatore del carico esterno GDC. Questi servizi sono configurati per autenticare e criptare le connessioni a livello di applicazione utilizzando TLS. La Figura 1 mostra questa interazione come connessione B.
Dall'utente finale (rete del cliente) a un'applicazione del cliente ospitata su GDC
Esistono diversi modi per instradare il traffico dalla rete del cliente a un'applicazione del cliente ospitata su GDC. La modalità di routing del traffico dipende dalla configurazione.
Esporre le applicazioni dei clienti tramite il gateway API del cliente
GDC supporta l'esposizione delle applicazioni dei clienti tramite il gateway API del cliente. Il servizio API Gateway del cliente consente agli utenti di sviluppare, eseguire il deployment, proteggere, gestire e scalare l'API in base alle esigenze. La Figura 1 mostra questa interazione come connessione C.
Esporre i carichi di lavoro containerizzati dei clienti tramite il bilanciatore del carico esterno del cliente
GDC supporta l'esposizione di carichi di lavoro containerizzati gestiti dal cliente tramite un bilanciatore del carico esterno. GDC offre la possibilità di configurare i criteri per il traffico in entrata e in uscita per il personale corrispondente. La Figura 1 mostra questa interazione come connessione E.
Esporre i carichi di lavoro delle macchine virtuali
GDC supporta l'esposizione delle macchine virtuali create dai clienti agli utenti finali. GDC offre la possibilità di configurare i criteri per il traffico in entrata e in uscita per il personale corrispondente. La Figura 1 mostra questa interazione come connessione F.
Servizio di interconnessione tra siti GDC
Il routing da un servizio gestito all'altro di solito avviene interamente all'interno del confine fisico di GDC. In alcuni casi, come il backup cross-site, i dati vengono indirizzati al di fuori del confine fisico del GDC. In questo caso, i dati vengono criptati sia a livello dell'applicazione, ad esempio TLS, sia a livello di rete. La Figura 1 mostra questa interazione come connessione G.
Da una macchina virtuale a un'altra macchina virtuale
Le connessioni da VM a VM all'interno di GDC non sono criptate a livello di rete. I clienti sono responsabili della crittografia dei dati utilizzando protocolli criptati appropriati o tecnologie specifiche come i tunnel IPSec.
Crittografia dei dati in transito per impostazione predefinita
GDC 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. Questa sezione descrive le protezioni predefinite utilizzate da Google per proteggere i dati in transito.
Il resto di questa sezione descrive le protezioni predefinite utilizzate da Google per proteggere i dati in transito.
Crittografia dall'utente al gateway in entrata di Cloud Service Mesh
Oggi molti sistemi utilizzano il protocollo HTTPS per comunicare su Internet. HTTPS fornisce la sicurezza tramite una connessione TLS, che garantisce l'autenticità, l'integrità e la riservatezza delle richieste e delle risposte. Per accettare le richieste HTTPS, il destinatario richiede una coppia di chiavi pubblica/privata e un certificato X.509 per l'autenticazione del server da parte di un'autorità di certificazione (CA). La coppia di chiavi e il certificato aiutano ad autenticare le richieste di un utente a livello dell'applicazione (livello 7), dimostrando che il destinatario è il proprietario del nome di dominio a cui sono destinate le richieste. Le seguenti sottosezioni discutono i componenti della crittografia dall'utente al gateway in entrata di Cloud Service Mesh, ovvero TLS, BoringSSL e l'autorità di certificazione configurabile di GDC.
Transport Layer Security (TLS)
Quando invii una richiesta a un servizio GDC, proteggiamo i dati in transito fornendo autenticazione, integrità e crittografia tramite il protocollo HTTPS con un certificato di un'autorità di certificazione attendibile. Tutti i dati che l'utente invia al gateway in entrata Cloud Service Mesh per il servizio gestito da GDC vengono criptati in transito con Transport Layer Security (TLS). Cloud Service Mesh Ingress Gateway negozia un particolare protocollo di crittografia con il client in base a ciò che il client può supportare. GDC Cloud Service Mesh Ingress Gateway applica solo algoritmi approvati da FIPS per fornire una maggiore sicurezza.
BoringSSL
BoringSSL è un'implementazione open source del protocollo TLS gestita da Google, creata mediante fork da OpenSSL e per la maggior parte compatibile a livello di interfaccia con OpenSSL. 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.
TLS nel gateway in entrata di Cloud Service Mesh è implementato con BoringSSL. La Tabella 1 mostra i protocolli di crittografia supportati da GDC durante la comunicazione con i client.
| Protocolli | Autenticazione | Scambio di chiavi | Crittografia | Funzioni hash |
|---|---|---|---|---|
| TLS 1.3 | RSA 2048 | Curve25519 | AES-128-GCM | SHA384 |
| TLS 1.2 | ECDSA P-256 | P-256 (NIST secp256r1) | AES-256-GCM | SHA256 |
Tabella 1: crittografia implementata nel gateway di ingresso Cloud Service Mesh per i servizi GDC e implementata nella libreria crittografica BoringSSL
Autorità di certificazione configurabile di GDC
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 connessione. 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 a qualsiasi potenziale dispositivo client. I browser e i dispositivi client sono configurati con un insieme di CA radice attendibili, in base all'ambiente in cui opera il client.
L'autorità di certificazione radice per GDC dipende dall'ambiente in cui viene implementata e dai requisiti dei clienti in quell'ambiente.
Gateway in entrata Cloud Service Mesh per i front-end delle applicazioni
Due casi:
- Cloud Service Mesh Ingress Gateway termina TLS, esegue nuovamente la crittografia mTLS utilizzando i certificati Istio di Cloud Service Mesh
- mTLS dal gateway in entrata al frontend dell'applicazione sidecar Istio
- Cloud Service Mesh Ingress Gateway termina TLS, lo ricrittografa in un altro server con la CA configurata.
Crittografia di rete del traffico di archiviazione
Nel sistema di archiviazione di file e blocchi GDC, il traffico viene instradato tra l'applicazione che utilizza l'archiviazione e il servizio di archiviazione. Questi dati vengono autenticati e criptati in transito utilizzando IPSec. La crittografia lato client per il traffico di archiviazione sarà disponibile a breve. La modalità di trasporto IPsec viene utilizzata tra il traffico di file e blocchi e l'host che deve accedere allo spazio di archiviazione. L'autenticazione viene eseguita tramite una chiave precondivisa generata al volo e archiviata in modo sicuro in GDC. Una volta stabilite le SA IPSec, le informazioni vengono scambiate utilizzando il tunnel IPSec. I pacchetti vengono criptati e decriptati utilizzando la crittografia conforme a FIPS specificata in IPSec SA.
Autenticazione, integrità e crittografia da un servizio all'altro
Al livello dell'applicazione (livello 7) nell'infrastruttura di GDC utilizziamo mTLS o TLS per l'autenticazione, l'integrità e la crittografia delle chiamate RPC dal gateway di ingresso di Cloud Service Mesh a un servizio e da un servizio GDC a un altro servizio GDC. Ogni servizio eseguito in GDC viene eseguito con un'identità dell'account di servizio in possesso di credenziali crittografiche associate. Quando comunicano tramite mTLS tramite Cloud Service Mesh, i servizi GDC utilizzano i certificati client per l'autenticazione ad altri servizi. Cloud Service Mesh verifica questi certificati utilizzando un'autorità di certificazione interna. Quando comunicano tramite TLS, ad esempio con un server API Kubernetes GDC, i servizi GDC utilizzano i token dell'account di servizio Kubernetes per l'autenticazione ai servizi. I token del account di servizio Kubernetes vengono verificati utilizzando le chiavi pubbliche dell'emittente di token del server dell'API Kubernetes.