Panoramica dell'ispezione TLS

Il traffico criptato con Transport Layer Security (TLS) rappresenta la stragrande maggioranza del traffico web. Poiché gli autori delle minacce spesso utilizzano questi canali criptati per nascondere attività dannose, è fondamentale ispezionare questo traffico prima che raggiunga la sua destinazione.

Secure Web Proxy fornisce un servizio di ispezione TLS integrato che consente di intercettare e decriptare il traffico HTTPS. Ottenendo visibilità sulla richiesta criptata, Secure Web Proxy può applicare policy di sicurezza avanzate, come il filtro degli URL sul percorso completo della richiesta e l'ispezione dell'intestazione HTTP, per proteggere l'ambiente dalle minacce nascoste all'interno dei tunnel criptati.

Come funziona

L'ispezione TLS funziona stabilendo due connessioni criptate separate, con Secure Web Proxy che funge da intermediario sicuro.

Handshake del client: quando un client tenta di connettersi a un sito esterno, ad esempio www.example.com, Secure Web Proxy intercetta la richiesta.
Generazione di certificati: Secure Web Proxy comunica con il servizio CA (Certificate Authority Service) privato. Il proxy genera un certificato temporaneo per www.example.com in tempo reale, firmato dalla CA subordinata privata della tua organizzazione.
Convalida dell'attendibilità: il client riceve quindi il certificato temporaneo.
Punto di ispezione: il traffico viene decrittografato all'interno dell'istanza Secure Web Proxy. In questa fase, i criteri di sicurezza vengono applicati ai dati HTTP in testo normale.
Handshake del server: Secure Web Proxy avvia quindi una seconda connessione TLS al server di destinazione effettivo. Il traffico viene nuovamente criptato e inviato all'indirizzo di destinazione.

Funzionalità principali

Il servizio di ispezione TLS di Secure Web Proxy offre un framework flessibile e scalabile per la gestione del traffico criptato tramite le seguenti funzionalità:

Trust privato integrato: l'integrazione integrata con CA Service fornisce un repository gestito da Google e ad alta disponibilità per le tue CA private.
Radice di attendibilità flessibile: utilizza un'autorità di certificazione (CA) radice on-premise esistente per firmare le CA subordinate ospitate nel servizio CA. A questo punto puoi generare e gestire un certificato radice completamente nuovo direttamente all'interno di CA Service.
Decrittografia specifica: utilizza SessionMatcher per definire con precisione il traffico da decrittografare. Puoi attivare l'ispezione TLS in base ai seguenti parametri:
- Nomi di dominio dei siti web: abbina siti web specifici utilizzando espressioni regolari ed elenchi di domini.
- Criteri di rete: scegli come target intervalli di indirizzi IP di origine o blocchi CIDR (Classless Inter-Domain Routing) specifici, ad esempio 10.0.0.0/24, per definire i limiti di rete.
- Logica booleana: combina più condizioni, ad esempio un IP di origine e un URL di destinazione, per creare regole di sicurezza molto specifiche.
Architettura delle norme scalabile:
- Policy dedicate: assegna un pool di CA e una policy di ispezione TLS unici a ogni policy Secure Web Proxy per un isolamento rigoroso.
- Policy condivise: semplifica la gestione delle policy condividendo una singola configurazione di ispezione TLS in più policy proxy.
Visibilità completa dell'Uniform Resource Identifier (URI): esamina l'intero URI (inclusi il dominio, il percorso e le stringhe di query, ad esempio www.example.com/downloads/malware.exe) anziché solo il nome di dominio.
Controllo dell'accesso preciso: utilizza l'ispezione TLS per applicare le policy a percorsi specifici di un sito web. Ad esempio, puoi consentire l'accesso a www.example.com/documentation, ma bloccare www.example.com/uploads.

Ruolo delle autorità di certificazione nell'ispezione TLS

Per ispezionare il traffico criptato, Secure Web Proxy funge da intermediario attendibile. Si tratta di un processo coordinato tra il proxy, il servizio CA e il dispositivo client.

Requisiti di affidabilità del client

L'ispezione TLS è progettata per gli ambienti in cui un'organizzazione ha il controllo amministrativo sui dispositivi client, come laptop gestiti, server o macchine virtuali (VM).

Ancora di attendibilità privata: poiché Secure Web Proxy presenta certificati firmati dalla tua CA interna anziché da una CA pubblica, i client considerano attendibile la connessione solo se la tua CA radice privata è preinstallata.
Ambito amministrativo: le connessioni da hardware non gestito in genere attivano avvisi Insecure connection perché questi dispositivi non dispongono dell'ancora di attendibilità specifica della tua organizzazione.

Gestire gli errori di intercettazione

Anche sui dispositivi gestiti, alcune connessioni non possono essere intercettate a causa del certificate pinning. Il pinning dei certificati si verifica quando un'applicazione è codificata in modo permanente per accettare solo una chiave pubblica specifica o una catena di CA pubblica specifica.

Esempi di pinning dei certificati: i servizi comuni che utilizzano il pinning includono gli aggiornamenti di sistema di Windows e macOS, gli aggiornamenti di Google Chrome e alcune applicazioni mobile ad alta sicurezza.
Risultato del pinning dei certificati: quando Secure Web Proxy presenta il certificato firmato, l'applicazione rileva che il certificato non corrisponde alle aspettative codificate e termina la connessione.

Mitigazione e controllo preciso

Per evitare interruzioni del servizio per le applicazioni bloccate o per mantenere la privacy per i siti web sensibili, puoi utilizzare l'attributo SessionMatcher per ignorare l'ispezione. Puoi limitare o ignorare l'ispezione in base ai seguenti parametri:

Attributi di destinazione: nomi di dominio completi (FQDN) specifici.
Attributi di origine: tag sicuri, service account o indirizzi IP.
Logica personalizzata: utilizza espressioni booleane per escludere traffico specifico durante l'ispezione del resto dell'ambiente.

Metodi di configurazione dell'autorità di certificazione

Per attivare l'ispezione TLS, configura l'autorità di certificazione (CA) utilizzando uno dei seguenti metodi:

CA subordinata nel servizio CA: utilizza una CA radice esterna esistente per firmare una CA subordinata archiviata in Google Cloud.
CA radice esterna: utilizza una CA radice esterna per firmare i certificati generati in fase di runtime tramite CA subordinate.
CA radice gestita da Google: genera un nuovo certificato radice direttamente all'interno del servizio CA per firmare le CA subordinate.

Per saperne di più su questi metodi, vedi Crea un pool di CA subordinate.