Il traffico criptato con Transport Layer Security (TLS) rappresenta la stragrande maggioranza del traffico web. Poiché gli attori delle minacce utilizzano spesso 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 il tuo ambiente dalle minacce nascoste nei 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 del certificato: Secure Web Proxy genera un certificato temporaneo per
www.example.comin tempo reale. A seconda della modalità di emissione dei certificati configurata, il proxy richiede i certificati foglia direttamente dal servizio CA per ogni dominio o li firma localmente utilizzando un certificato CA intermedio memorizzato nella cache del pool di CA.Convalida dell'attendibilità: il client riceve il certificato temporaneo.
Punto di ispezione: il traffico viene decriptato all'interno dell'istanza di Secure Web Proxy. In questa fase, le policy di sicurezza vengono applicate 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 criptato nuovamente 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 Certificate Authority Service fornisce un repository ad alta affidabilità gestito da Google 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 in Certificate Authority Service. Puoi quindi generare e gestire un certificato radice completamente nuovo direttamente all'interno di CA Service.
Decrittografia specifica: utilizza
SessionMatcherper definire con precisione quale traffico decrittografare. Puoi attivare l'ispezione TLS in base ai seguenti parametri:- Nomi di dominio dei siti web: trova siti web specifici utilizzando espressioni regolari ed elenchi di domini.
- Criteri di rete: scegli come target intervalli di indirizzi IP di origine specifici o blocchi CIDR (Classless Inter-Domain Routing), ad esempio
10.0.0.0/24, per definire i confini della rete. - Logica booleana: combina più condizioni, ad esempio un IP di origine e un URL di destinazione, per creare regole di sicurezza altamente specifiche.
Architettura delle policy scalabile:
Policy dedicate: assegna una policy di ispezione TLS e un pool di CA univoci a ogni policy di Secure Web Proxy per un isolamento rigoroso.
Policy condivise: semplifica la gestione delle policy condividendo una singola configurazione di ispezione TLS tra più policy proxy.
Visibilità completa dell'URI (Uniform Resource Identifier): ispeziona l'intero URI (inclusi dominio, percorso e stringhe di query, ad esempio
www.example.com/downloads/malware.exe) anziché solo il nome di dominio.Controllo degli accessi preciso: utilizza l'ispezione TLS per applicare le policy per percorsi specifici di un sito web. Ad esempio, puoi consentire l'accesso a
www.example.com/documentation, ma bloccarewww.example.com/uploads.Supporto delle CA intermedie: riduci le tariffe di utilizzo di Certificate Authority Service memorizzando nella cache locale una singola CA intermedia per firmare i certificati foglia, anziché inviare richieste per dominio direttamente a Certificate Authority Service. Per saperne di più, consulta Modalità di emissione dei certificati.
Ruolo delle autorità di certificazione nell'ispezione TLS
Per ispezionare il traffico crittografato, Secure Web Proxy agisce come intermediario attendibile. Ciò comporta un processo coordinato tra il proxy, il servizio CA e il dispositivo client.
Requisiti di attendibilità del client
L'ispezione TLS è progettata per gli ambienti in cui un'organizzazione ha il controllo amministrativo sui dispositivi client, come laptop, server o macchine virtuali (VM) gestiti.
Attendibilità del container dell'agente: quando esegui il routing del traffico web in uscita dagli agenti AI containerizzati, ad esempio in Cloud Run o Google Kubernetes Engine (GKE), devi esportare il certificato CA principale dal pool CA o dall'infrastruttura a chiave pubblica (PKI) privata e inserirlo nell'archivio di attendibilità dei certificati del container. Ad esempio, puoi configurare il runtime del container o impostare la variabile di ambiente
AGENT_GATEWAY_ROOT_CERTIFICATESoSSL_CERT_FILE. Per maggiori informazioni su come configurare la CA principale, consulta Configura l'ispezione TLS in "Esegui il deployment di Secure Web Proxy come Agent Gateway".Trust anchor privato: 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 di
Insecure connectionperché questi dispositivi non dispongono del trust anchor specifico della tua organizzazione.
Gestisci 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 è impostata come hardcoded per accettare solo una chiave pubblica specifica o una catena di CA pubbliche specifica.
- Esempi di certificate pinning: 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 impostate come hardcoded 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 bypassare l'ispezione. Puoi limitare o saltare 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.
Modalità di emissione dei certificati
Secure Web Proxy supporta due modalità per eseguire il provisioning dei certificati che utilizza per decriptare il traffico durante il processo di ispezione TLS. La scelta dipende dai requisiti di costo, prestazioni e audit logging.
Per saperne di più, consulta Configura la firma di una CA intermedia locale.
Firma della CA intermedia locale
Se imposti certificateIssuanceMode su LOCAL_INTERMEDIATE_CA_SIGNING, Secure Web Proxy richiede un singolo certificato CA intermedio dal pool di CA. Il proxy memorizza nella cache questa CA intermedia e firma localmente i singoli certificati foglia per i domini richiesti.
Le funzionalità della modalità di emissione dei certificati di firma della CA intermedia locale sono le seguenti:
Costi di CA Service inferiori: le richieste a CA Service sono limitate al ciclo di aggiornamento della CA intermedia (in genere una volta al giorno) anziché essere eseguite per ogni dominio, il che comporta costi di transazione inferiori.
Osservabilità ridotta: i singoli certificati foglia firmati localmente dal proxy non vengono registrati negli audit log di CA Service.
Provisioning diretto dei nodi foglia
Se imposti certificateIssuanceMode su DIRECT_LEAF_PROVISIONING, Secure Web Proxy comunica direttamente con il pool di CA Service per ogni dominio univoco per richiedere un certificato foglia.
Le funzionalità della modalità di emissione dei certificati di provisioning diretto delle foglie sono le seguenti:
Maggiore osservabilità: ogni richiesta di certificato generata viene registrata negli audit log di Certificate Authority Service, consentendoti di monitorare e controllare tutte le attività di generazione dei certificati.
Costi di CA Service più elevati: poiché le richieste vengono inviate a CA Service per ogni dominio, questo processo può comportare commissioni di transazione più elevate in ambienti con diversi domini o attività proxy univoci.
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 in CA Service: 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 di Certificate Authority Service per firmare le CA subordinate.
Per saperne di più su questi metodi, consulta Crea un pool CA subordinato.