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 in corso, GDC applica protezioni predefinite ai dati in transito per i componenti GDC. Ad esempio, proteggiamo le comunicazioni tra l'utente e il gateway in entrata di Cloud Service Mesh di GDC Cloud 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 instancabilmente per proteggere i tuoi dati, sia che vengano trasferiti sulla tua rete, che si spostino all'interno dell'infrastruttura di Google o che vengano archiviati sui nostri server.
La strategia di sicurezza di Google si basa su autenticazione, integrità e crittografia, sia per i dati at-rest che 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 at-rest, consulta Crittografia at-rest. Per una panoramica complessiva della sicurezza di Google, consulta Panoramica sulla progettazione della sicurezza per l'infrastruttura Google.
Pubblico: questo documento è rivolto ai CISO e ai team di operazioni di sicurezza che utilizzano o stanno valutando l'utilizzo di 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 che invii arrivino a destinazione inalterati, ovvero protetti da modifiche non autorizzate.
- Crittografia: rendiamo i tuoi dati illeggibili durante il transito per mantenerli riservati. La crittografia è il processo attraverso il quale i dati leggibili (testo non crittografato) vengono 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 decrittografare il testo crittografato è privata. La crittografia in transito utilizza spesso lo scambio di chiavi asimmetriche, come Diffie-Hellman basato su curve ellittiche, per stabilire una chiave simmetrica condivisa utilizzata per la crittografia dei dati. Per saperne di più sulla crittografia, consulta Introduzione alla crittografia moderna.
La crittografia può essere utilizzata per proteggere i dati in più stati:
- La crittografia at-rest protegge i tuoi dati da una compromissione del sistema o dall'esfiltrazione di dati dati criptandoli mentre sono archiviati. L'Advanced Encryption Standard (AES) viene spesso utilizzato per criptare i dati at-rest.
- Crittografia dei dati in transito: protegge i tuoi dati durante il trasferimento tra il sito e il cloud provider, o tra un servizio e l'altro, nel caso in cui le comunicazioni vengano intercettate. Questa protezione viene ottenuta criptando i dati prima della trasmissione, con l'autenticazione degli endpoint e con la decriptazione 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. La crittografia in transito protegge i tuoi dati, dopo che una connessione è stata stabilita e autenticata, da potenziali aggressori:
- Eliminazione della necessità di fidarsi dei livelli inferiori della rete, che sono 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'adeguata autenticazione, integrità e crittografia, i dati che viaggiano tra utenti, dispositivi o processi possono essere protetti in un ambiente ostile. Il resto di questo documento spiega l'approccio di GDC alla crittografia dei dati in transito e dove viene applicata.
Infrastruttura di rete GDC
Confini fisici
Un confine fisico è la barriera di uno spazio fisico controllato da Google o in coordinamento con Google, dove possiamo garantire l'applicazione di misure di sicurezza rigorose. L'accesso fisico a queste sedi è limitato, monitorato e controllato attentamente. Solo un numero limitato di membri del 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 entrano o escono dal confine fisico di GDC, utilizziamo un'autenticazione e una crittografia efficaci per proteggere i dati in transito.
Modalità di routing del traffico
Per capire come funziona la crittografia in transito in GDC, è necessario spiegare come il traffico viene instradato verso e attraverso GDC. Questa sezione descrive in che modo le richieste arrivano da un utente finale al servizio GDC o all'applicazione del cliente appropriati e in che modo il traffico viene instradato tra i servizi cross-site.
Un servizio gestito da GDC è un servizio cloud privato modulare. Questi servizi includono computing, 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 tu, in qualità di cliente GDC, puoi creare ed eseguire il deployment utilizzando i servizi GDC. Le applicazioni dei clienti o le soluzioni dei partner ospitate su GDC non sono considerate servizi gestiti da GDC. Ad esempio, un'applicazione creata utilizzando le VM GDC, il servizio Database 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 di rete e la sicurezza in atto per ogni connessione.
Figura 1: infrastruttura di connettività tra siti
Utente finale (rete del cliente) all'API GDC e al servizio gestito
I servizi gestiti ospitati su gateway in entrata di Cloud Service Mesh accettano le richieste dalla rete del cliente utilizzando il gateway in entrata di Cloud Service Mesh. Il gateway in entrata di Cloud Service Mesh funge da proxy per il traffico HTTP(S) in entrata, lo instrada e lo bilancia verso i servizi gestiti da GDC. Un altro livello di firewall fornisce contromisure per gli attacchi DDoS con rilevamento e prevenzione delle intrusioni. Questa connessione è autenticata e criptata dal gateway in entrata di Cloud Service Mesh al frontend del servizio gestito da GDC. La Figura 1 mostra questa interazione come connessione A.
La maggior parte delle API e dei servizi gestiti di GDC è ospitata sui gateway in entrata di 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.
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. Il modo in cui il traffico viene instradato dipende dalla configurazione.
Esponi le applicazioni del cliente tramite l'API Gateway del cliente
GDC supporta l'esposizione delle applicazioni dei clienti tramite l'API Gateway 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.
Esponi i workload containerizzati dei clienti tramite il bilanciatore del carico esterno del cliente
GDC supporta l'esposizione dei workload containerizzati gestiti dal cliente tramite un bilanciatore del carico esterno. GDC offre la possibilità di configurare policy in entrata e in uscita per il personale corrispondente. La Figura 1 mostra questa interazione come connessione E.
Esponi i workload delle macchine virtuali
GDC supporta l'esposizione delle macchine virtuali create dai clienti agli utenti finali. GDC offre la possibilità di configurare le policy in entrata e in uscita per il personale corrispondente. La Figura 1 mostra questa interazione come connessione F.
Servizio Cross-Site Interconnect di GDC
Il routing da un servizio gestito a un altro avviene in genere interamente all'interno del confine fisico di GDC. In alcuni casi, come il backup tra siti, i dati vengono instradati al di fuori del confine fisico di GDC. In questo caso, i dati vengono criptati sia a livello di applicazione, ad esempio TLS, sia a livello di rete. La Figura 1 mostra questa interazione come connessione G.
Da macchina virtuale a 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 che 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 che Google utilizza per proteggere i dati in transito.
Il resto di questa sezione descrive le protezioni predefinite che Google utilizza per proteggere i dati in transito.
Crittografia tra l'utente e il gateway in entrata di Cloud Service Mesh
Oggi molti sistemi utilizzano il protocollo HTTPS per comunicare su Internet. HTTPS fornisce sicurezza utilizzando una connessione TLS, che garantisce l'autenticità, l'integrità e la riservatezza delle richieste e delle risposte. Per accettare le richieste HTTPS, il ricevitore richiede una coppia di chiavi pubbliche/private e un certificato X.509 per l'autenticazione del server da un'autorità di certificazione (CA). La coppia di chiavi e il certificato aiutano ad autenticare le richieste di un utente a livello di applicazione (livello 7) dimostrando che il destinatario possiede il nome di dominio a cui sono destinate le richieste. Le sezioni seguenti illustrano i componenti della crittografia da utente a 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, utilizzando HTTPS con un certificato di un'autorità di certificazione attendibile. Tutti i dati inviati dall'utente al gateway in entrata di Cloud Service Mesh per il servizio gestito da GDC vengono criptati in transito con Transport Layer Security (TLS). Il gateway in entrata di Cloud Service Mesh negozia un protocollo di crittografia specifico con il client in base a ciò che il client può supportare. Il gateway in entrata di GDC Cloud Service Mesh applica solo algoritmi approvati da FIPS per fornire una sicurezza più elevata.
BoringSSL
BoringSSL è un'implementazione open source del protocollo TLS gestita da Google, derivata da OpenSSL, che è per lo più compatibile con l'interfaccia di OpenSSL. Google ha creato 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 secondo lo standard 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 in entrata di Cloud Service Mesh per i servizi GDC e implementata nella libreria crittografica BoringSSL
Autorità di certificazione configurabile di GDC
Nell'ambito del protocollo TLS, un server deve dimostrare la propria identità all'utente quando riceve una richiesta di connessione. Questa verifica dell'identità viene eseguita nel protocollo TLS facendo in modo che il server presenti un certificato contenente l'identità dichiarata. Il certificato contiene sia il nome host DNS del server sia la sua chiave pubblica. Una volta presentato, il certificato viene firmato da un'autorità di certificazione (CA) emittente considerata attendibile dall'utente che richiede la connessione. Di conseguenza, gli utenti che richiedono connessioni al server devono considerare attendibile solo la CA radice. Se il server vuole essere accessibile ovunque, la CA radice deve essere nota a tutti i potenziali dispositivi client. I browser e i dispositivi client sono configurati con un insieme di CA radice di cui si fidano, in base all'ambiente in cui opera il client.
La CA radice per GDC dipende dall'ambiente in cui viene eseguito il deployment e dai requisiti dei clienti in quell'ambiente.
Gateway in entrata di Cloud Service Mesh ai frontend delle applicazioni
Due casi:
- Il gateway in entrata di Cloud Service Mesh termina TLS, cripta nuovamente mTLS utilizzando i certificati Istio di Cloud Service Mesh
- mTLS dal gateway in entrata al frontend dell'applicazione sidecar Istio
- Il gateway in entrata di Cloud Service Mesh termina TLS, cripta nuovamente TLS su un altro server, con la CA configurata.
Crittografia di rete del traffico di archiviazione
Nel sistema di archiviazione di file e a blocchi di GDC, il traffico viene instradato tra l'applicazione che utilizza lo spazio di 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 verso l'host che deve accedere allo spazio di archiviazione. L'autenticazione viene eseguita tramite una chiave precondivisa generata in tempo reale 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 nell'IPSec SA.
Autenticazione, integrità e crittografia da un servizio all'altro
All'interno dell'infrastruttura GDC, a livello di applicazione (livello 7), utilizziamo mTLS o TLS per l'autenticazione, l'integrità e la crittografia delle chiamate RPC dal gateway in entrata di Cloud Service Mesh a un servizio e da un servizio GDC a un altro servizio GDC. Ogni servizio eseguito in GDC viene eseguito come identità di un account di servizio con credenziali crittografiche associate. Quando comunicano tramite mTLS tramite Cloud Service Mesh, i servizi GDC utilizzano i certificati client per autenticarsi con 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 dei account di servizio Kubernetes per autenticarsi ai servizi. I token dei account di servizio Kubernetes vengono verificati utilizzando le chiavi pubbliche dell'emittente dei token del server API Kubernetes.