Questo documento fornisce dettagli sulla crittografia dei dati in transito con air gap di Google Distributed Cloud (GDC).
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 in entrata Cloud Service Mesh di GDC utilizzando TLS.
Introduzione
La sicurezza è spesso un fattore decisivo nella scelta di un provider di servizi cloud. Per Google la sicurezza è un tema di fondamentale importanza. Lavoriamo senza sosta per proteggere i tuoi dati durante i trasferimenti sulla 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 at-rest 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 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 è destinato ai CISO e ai team di operazioni di sicurezza che utilizzano o stanno valutando 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 a 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 a curva ellittica, per stabilire una chiave simmetrica condivisa utilizzata per la crittografia dei dati. Per ulteriori informazioni sulla crittografia, consulta il libro Introduction to Modern Cryptography.
La crittografia può essere utilizzata per proteggere i dati in più stati:
- La crittografia at-rest protegge i dati in caso di compromissione del sistema o di esfiltrazione di dati, crittografandoli durante l'archiviazione. Per la crittografia dei dati at-rest viene spesso utilizzato Advanced Encryption Standard (AES).
- La 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, all'arrivo, con la decriptazione e la verifica che i dati non siano stati modificati. Ad esempio, al fine di garantire la sicurezza del trasporto viene spesso utilizzato lo standard Transport Layer Security (TLS) per la crittografia dei dati in transito, mentre Secure/Multipurpose Internet Mail Extensions (S/MIME) è la scelta più frequente per assicurare 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 piccolo gruppo di personale approvato ha accesso all'hardware. I dati in transito all'interno di questi confini fisici sono generalmente autenticati e crittografati.
Per le comunicazioni che entrano o escono dal confine fisico di GDC, utilizziamo una crittografia e un'autenticazione efficaci 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 in che modo il traffico viene instradato 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 comprendono il computing, l'archiviazione e il 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 in GDC non sono considerate servizi gestiti da GDC. Ad esempio, un'applicazione creata con le 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 e al servizio gestito di GDC
Per i servizi gestiti ospitati sui gateway in entrata Cloud Service Mesh, questi accettano le richieste dalla rete del cliente utilizzando il gateway in entrata Cloud Service Mesh. Il gateway in entrata Cloud Service Mesh esegue il proxy del traffico HTTP(S) in entrata e può bilanciare il carico del traffico e instradare il traffico verso i servizi gestiti da GDC. Un altro livello di firewall fornisce contromisure agli attacchi DDoS con rilevamento e prevenzione delle intrusioni. Questa connessione viene autenticata e crittografata dal gateway in entrata 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 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 crittografare le connessioni a livello dell'applicazione utilizzando TLS. La Figura 1 mostra questa interazione come connessione B.
Dall'utente finale (rete del cliente) a un'applicazione del cliente ospitata in GDC
Il traffico dalla rete del cliente può essere instradato a un'applicazione del cliente ospitata in GDC in modi diversi. La modalità di routing del traffico dipende dalla configurazione in uso.
Esporre le applicazioni del cliente tramite il gateway API del cliente
GDC supporta l'esposizione delle applicazioni del cliente 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 workload containerizzati del cliente 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 le policy in entrata e in uscita per il personale corrispondente. La Figura 1 mostra questa interazione come connessione E.
Esporre i workload delle macchine virtuali
GDC supporta l'esposizione delle macchine virtuali create dal cliente 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 di interconnessione cross-site GDC
Il routing da un servizio gestito all'altro avviene in genere interamente all'interno del confine fisico di GDC. In alcuni casi, ad esempio per il backup cross-site, i dati vengono instradati al di fuori del confine fisico di GDC. In questo caso, i dati vengono crittografati 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 vengono crittografate a livello di rete. I clienti sono responsabili della crittografia dei dati utilizzando protocolli crittografati 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 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 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 l'autenticazione, l'integrità e la 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 crittografati in transito con Transport Layer Security (TLS). Il gateway in entrata Cloud Service Mesh negozia un particolare protocollo di crittografia con il client in base a ciò che il client è in grado di supportare. Il gateway in entrata Cloud Service Mesh di GDC applica solo gli algoritmi approvati da FIPS per fornire una maggiore sicurezza.
BoringSSL
BoringSSL è un'implementazione open source gestita da Google del protocollo TLS, ottenuta 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 Open Source Projects. BoringCrypto, il nucleo di BoringSSL, è stato convalidato ai sensi di FIPS 140-2 livello 1.
Il protocollo TLS nel gateway in entrata 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 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 dispositivo client potenziale. I browser e i dispositivi client sono configurati con un insieme di CA radice che considerano attendibili, 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.
Dal gateway in entrata Cloud Service Mesh ai frontend delle applicazioni
Due casi:
- Il gateway in entrata Cloud Service Mesh termina TLS, esegue la ricrittografia mTLS utilizzando i certificati Istio di Cloud Service Mesh
- mTLS dal gateway in entrata al frontend dell'applicazione Sidecar Istio
- Il gateway in entrata Cloud Service Mesh termina TLS, esegue la ricrittografia TLS su un altro server con la CA configurata.
Crittografia di rete del traffico di archiviazione
Nel sistema di archiviazione di file e archiviazione a blocchi GDC, il traffico viene instradato tra l'applicazione che utilizza l'archiviazione e il servizio di archiviazione. Questi dati vengono autenticati e crittografati 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 all'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 crittografati e decrittografati utilizzando la crittografia conforme a FIPS specificata nella SA IPSec.
Autenticazione, integrità e crittografia da un servizio all'altro
All'interno dell'infrastruttura GDC, a livello dell'applicazione (livello 7), utilizziamo mTLS o TLS per l'autenticazione, l'integrità e la crittografia delle chiamate RPC dal gateway in entrata 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 autenticarsi 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 autenticarsi ai servizi. I token dell'account di servizio Kubernetes vengono verificati utilizzando le chiavi pubbliche dell'emittente del token del server API Kubernetes.