Ispezione TLS locale vs. ispezione TLS su cloud: compromessi di implementazione
- L'ispezione TLS decrittografa, ispeziona e ricrittografa il traffico; pertanto, ovunque ciò avvenga, il testo in chiaro rimane visibile per un breve istante.
- L’ispezione locale consente di mantenere il controllo sui dati in chiaro e sulle chiavi a livello locale; si valutino separatamente i servizi basati sul cloud e le relative operazioni di elaborazione.
- Le linee guida della NSA raccomandano di ispezionare ogni sessione una sola volta, all’interno della rete aziendale, senza l’utilizzo di proxy in catena.
- Si mantenga un elenco aggiornato delle eccezioni relative alle app aggiunte ai preferiti, alle categorie sensibili dal punto di vista della privacy e al traffico che non supera i controlli.
- Il protocollo "Client Hello" crittografato, pubblicato come RFC 9849, limita la visibilità passiva e richiede una gestione mirata.
L’ispezione TLS (spesso ancora denominata ispezione SSL) è il processo che consiste nell’intercettare una sessione TLS, decrittografarla tramite un certificato considerato attendibile dall’azienda, ispezionarne il contenuto e ricrittografarla prima di inoltrarla alla destinazione. In assenza di tale processo, i gateway web sicuri, i motori DLP e le sandbox vedono solo i metadati di destinazione. Grazie ad esso, invece, sono in grado di rilevare malware, bloccare l’esfiltrazione di dati e applicare le politiche di utilizzo accettabile all’interno delle sessioni crittografate.
La decisione non riguarda l’opportunità di effettuare l’ispezione, bensì il luogo in cui effettuarla. La presente guida mette a confronto l’ispezione TLS locale e quella su cloud in termini di percorsi di decrittografia, responsabilità relative ai certificati, eccezioni, registrazione dei dati e operazioni.
Il presente articolo fa parte della guida alla sicurezza del cloud ibrido.
Come funziona l'ispezione TLS
L'ispezione TLS funziona in modo tale che un proxy affidabile interrompa la sessione crittografata del client, ne ispezioni il contenuto e apra una nuova sessione crittografata verso la destinazione.
Il proxy funge da server per il client e da client per la destinazione:
- Il cliente avvia una sessione TLS verso un sito web o un'applicazione.
- Il proxy intercetta la connessione e presenta un certificato per la destinazione, firmato da un’autorità di certificazione (CA) aziendale di cui i dispositivi client si fidano.
- Il proxy avvia una propria sessione TLS verso la destinazione effettiva e verifica la validità del certificato di quel server.
- Il traffico viene decrittografato tra le due sessioni, ispezionato e nuovamente crittografato.
Ciò significa che il proxy detiene una chiave estremamente potente e gestisce il testo in chiaro per ogni sessione ispezionata. L’avviso della NSA intitol ato “Managing Risk from Transport Layer Security Inspection” raccomanda di ridurre al minimo tali situazioni: eseguire l’ispezione una sola volta, all’interno della rete aziendale, ed evitare ispezioni ridondanti da parte di più proxy di inoltro. Il precedente avviso della CISA sull’intercettazione HTTPS metteva in guardia sul fatto che prodotti di ispezione implementati in modo inadeguato possono indebolire la sicurezza TLS, ad esempio non convalidando correttamente i certificati a monte.
Panoramica sul confronto tra l’ispezione TLS locale e quella su cloud
L'ispezione locale mantiene il testo in chiaro e le chiavi all'interno della vostra infrastruttura, mentre l'ispezione su cloud li trasferisce ai punti di presenza del fornitore.
| Fattore | Ispezione TLS locale (in sede) | Ispezione TLS nel cloud |
|---|---|---|
| Laddove sia presente del testo in chiaro | I dispositivi del Suo data center o delle Sue filiali | Punti di presenza dei fornitori |
| Chi detiene la chiave privata CA di ispezione? | Voi, eventualmente nel vostro HSM | Il fornitore, oppure Lei tramite le opzioni relative alle chiavi supportate dal fornitore |
| Ideale per | Dati regolamentati, traffico interno, utenti in loco, OT | Utenti remoti, traffico diretto verso il SaaS |
| Latenza per gli utenti in loco | Dipende dalla capacità locale e dal percorso del traffico | Dipende dalla distanza del punto di presenza e dall'instradamento |
| Pianificazione della capacità | Cordiali saluti; la decrittografia richiede un'elevata potenza di calcolo | Del fornitore |
| Dipendenza dalla connettività esterna | Non è necessario per l'applicazione delle politiche web locali; è invece richiesto per i servizi basati sul cloud, quali la protezione dei dati | Obbligatorio |
| Registri e ubicazione delle prove | I registri locali sono configurabili; i dati relativi ai servizi cloud seguono la politica di archiviazione di ciascun servizio | Regioni dei provider, soggette a configurazione |
| Impegno operativo | Dimensionamento dell’hardware, applicazione delle patch, ciclo di vita dei certificati | Distribuzione dei certificati, eccezioni, configurazione dei provider |
La maggior parte delle organizzazioni ibride ricorre a entrambe le soluzioni: l’ispezione locale per il traffico selezionato in loco e quello soggetto a regolamentazione, e l’ispezione nel cloud per gli utenti remoti. Si raccomanda di mappare la terminazione TLS su ciascun percorso ed evitare la decrittografia ridondante, anche quando un gateway locale inoltra il traffico destinato ai servizi gestiti nel cloud.
Percorsi di decrittografia
Ogni progetto ibrido dovrebbe mappare ogni punto di terminazione e di ricrittografia TLS ed evitare ispezioni ridondanti.
Tra i percorsi più comuni figurano:
- Utente in ufficio connesso a Internet: gateway locale oppure tramite tunnel verso un punto di presenza nel cloud
- Utente remoto connesso a Internet: punto di presenza nel cloud oppure collegamento tramite backhaul a un gateway locale
- Da utente ad app privata: verificare se e dove il percorso ZTNA selezionato supporti l'ispezione TLS
- Sessione del browser: controlli a livello di browser che consentono di visualizzare i contenuti senza decrittografia di rete
- Obiettivo: ispezione basata su agenti sul dispositivo
Un rischio negli ambienti ibridi è rappresentato dalla decrittografia duplicata non pianificata. Una filiale potrebbe inviare il traffico attraverso un proxy locale e successivamente attraverso un servizio cloud che interrompe nuovamente la connessione TLS. Si raccomanda di documentare ogni fase di ispezione necessaria, proteggere ogni punto di passaggio in chiaro ed eliminare le fasi ridondanti che aumentano l’esposizione o la complessità della risoluzione dei problemi.
Responsabilità relative al certificato
L'affidabilità del controllo TLS dipende interamente dall'affidabilità dei certificati su cui si basa; pertanto, attribuite chiaramente la responsabilità per ciascuna fase del ciclo di vita del certificato:
- Creazione e protezione delle certificati di autenticazione (CA). Documentare dove è conservata la chiave privata, chi può accedervi e se è necessario un HSM. Verificare le integrazioni HSM supportate per ciascun gateway locale o servizio cloud e la relativa versione del prodotto; non dare per scontato il supporto.
- Distribuzione. Modalità di installazione della CA negli archivi di fiducia del sistema operativo e del browser sui dispositivi gestiti, nonché il comportamento sui dispositivi non gestiti.
- Rotazione. Il programma e la procedura per la sostituzione del CA addetto alle ispezioni senza interruzione del servizio.
- Convalida a monte. Verificare che il proxy respinga i certificati di destinazione non validi, scaduti o revocati, anziché nasconderli agli utenti.
- Supporto dei protocolli. Il protocollo TLS 1.3 (RFC 8446) dovrebbe essere gestito in modo nativo, senza ricorrere al downgrade.
Eccezioni relative al traffico
Nessuna organizzazione dovrebbe decriptare ogni dato; pertanto, si raccomanda di mantenere un elenco delle eccezioni ben documentato e sottoposto a revisione periodica:
| Tipo di eccezione | Motivo | Gestione tipica |
|---|---|---|
| Applicazioni con certificato associato | L'ispezione interrompe la connessione | Esclusione in base alla destinazione; applicazione dei controlli relativi alla reputazione e alla categoria |
| Categorie relative alla salute, alle questioni finanziarie e alla sfera personale | Privacy dei dipendenti, requisiti legali e del comitato aziendale | Ignorare la decrittografia; applicare comunque la politica relativa alle categorie |
| Autenticazione TLS reciproca e tramite certificato client | Il proxy non è in grado di presentare il certificato del cliente | Disattivare o utilizzare un pass-through supportato |
| Servizi di aggiornamento e alcuni protocolli OT | Stabilità e assistenza da parte dei fornitori | Bypass in base alla destinazione con accesso limitato |
| QUIC e HTTP/3 (RFC 9000) | Molti proxy non sono in grado di ispezionare il protocollo QUIC | Blocchi QUIC in modo che i browser ricorrano a TLS su TCP, oppure confermi il supporto nativo |
Esaminare le eccezioni su base trimestrale. I bypass obsoleti rappresentano un punto cieco comune.
Client Hello crittografato e quali sono le novità
Il "Client Hello" crittografato nasconde il nome host di destinazione agli osservatori passivi; pertanto, è necessario riconsiderare la visibilità basata su SNI e alcune decisioni relative al bypass.
Il protocollo "Encrypted Client Hello" è stato pubblicato come RFC 9849 nel 2026. L’ECH crittografa la parte dell’handshake TLS che in precedenza rivelava il nome host di destinazione (la Server Name Indication) e altri campi. Gli strumenti passivi che classificano il traffico leggendo l’SNI perdono tale visibilità per i siti che utilizzano l’ECH.
I proxy espliciti che interrompono la connessione TLS si trovano in una situazione diversa, poiché stabiliscono sessioni proprie con le destinazioni. Ciononostante, l’ECH comporta alcune implicazioni operative:
- I browser potrebbero inviare estensioni simili a ECH anche quando ECH non è in uso; pertanto, i prodotti di analisi devono gestirle correttamente.
- L'RFC sottolinea che, in contesti aziendali gestiti, un approccio consiste nel disabilitare l'ECH tramite i criteri di gruppo e fare affidamento sul fatto che i client rispettino tale impostazione.
- Le decisioni relative alla categoria e alla reputazione che dipendevano dallo SNI per il traffico deviato necessitano di un’alternativa, come ad esempio controlli a livello di DNS o una configurazione esplicita del proxy.
Verifichi la roadmap ECH del Suo fornitore di servizi di ispezione e ne verifichi il comportamento con le versioni attuali dei browser.
Registrazione
I registri di ispezione possono contenere URL, identità e prove relative al DLP; pertanto, il loro contenuto, la loro ubicazione e l’accesso agli stessi richiedono decisioni esplicite:
- Quali campi vengono registrati per il traffico decriptato rispetto a quello bypassato?
- Dove vengono conservati i registri e se questi possano uscire dal territorio di una giurisdizione
- Periodi di conservazione e soggetti autorizzati ad accedere alle prove relative all’intero contenuto
- Quali eventi vengono inoltrati al SIEM
L’ispezione in loco semplifica la conservazione dei registri e delle prove all’interno del Paese. L’ispezione nel cloud richiede la verifica delle regioni di archiviazione dei registri del fornitore e dei controlli di accesso. Si veda la sezione “Sovranità dei dati” nel capitolo “Sicurezza del cloud ibrido”.
Compromessi operativi
L'ispezione locale privilegia l'impegno operativo a scapito del controllo, l'ispezione cloud privilegia la semplicità a scapito del controllo, mentre l'ispezione ibrida richiede un unico motore di policy per funzionare.
L’ispezione locale richiede il dimensionamento delle apparecchiature per la decrittografia nei momenti di picco, l’aggiornamento costante dei motori di ispezione e la pianificazione della crescita della capacità hardware o virtuale. In cambio, offre il pieno controllo sul testo in chiaro, sulle chiavi e sui registri relativi al traffico ispezionato localmente; inoltre, l’applicazione locale delle politiche relative al web e alle applicazioni private prosegue anche in caso di interruzione della WAN o del cloud, mentre i servizi applicati nel cloud del fornitore vengono sospesi fino al ripristino della connettività.
L'ispezione nel cloud trasferisce la pianificazione della capacità e gli aggiornamenti dei motori al fornitore. Richiede comunque la distribuzione dei certificati, la gestione delle eccezioni e la messa a punto delle politiche, e introduce una dipendenza dalla disponibilità e dalla connettività del fornitore.
L'ispezione ibrida combina entrambe le modalità, ma funziona correttamente solo con un unico motore di policy. Se i gateway locali e quelli nel cloud dispongono di elenchi di eccezioni e regole DLP distinti, gli utenti saranno trattati in modo diverso a seconda della loro ubicazione.
L'approccio di Skyhigh alle ispezioni in loco e nel cloud
Skyhigh esegue l’ispezione TLS in locale, laddove la conformità lo richieda, e nel cloud per gli utenti remoti, il tutto nell’ambito di un’unica politica.
Skyhigh Hybrid SSE Mesh esegue la decrittografia e l’ispezione SSL/TLS a livello locale sugli apparecchi dell’organizzazione stessa, laddove la conformità lo richieda, e nei punti di presenza nel cloud di Skyhigh per gli utenti remoti, con un unico motore di policy comune a entrambi. Le funzionalità “ Secure Web Gateway ” e “Zero Trust Access” vengono applicate in modo nativo sul gateway, mentre la policy di protezione dei dati viene applicata nel cloud di Skyhigh sul traffico inoltrato dal gateway. Il traffico Web decrittografato sul gateway on-premise viene ispezionato e ricrittografato in loco per l’applicazione delle politiche Web locali. Laddove una politica utilizzi un servizio applicato nel cloud, come la protezione dei dati, il gateway inoltra il traffico pertinente al cloud Skyhigh, dove viene applicata la stessa politica. I controlli Secure Browser senza agente aggiungono un’ispezione compatibile con WebSocket del traffico relativo all’intelligenza artificiale e alla messaggistica nella sessione del browser.
Fonti
- NSA. Gestione dei rischi derivanti dall’ispezione del protocollo TLS (novembre 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
- CISA. “L’intercettazione HTTPS compromette la sicurezza TLS” (Avviso TA17-075A, marzo 2017). https://www.cisa.gov/news-events/alerts/2017/03/16/https-interception-weakens-tls-security
- IETF. RFC 8446: Protocollo Transport Layer Security (TLS), versione 1.3. https://www.rfc-editor.org/rfc/rfc8446.html
- IETF. RFC 9849: Client Hello crittografato con TLS. https://www.rfc-editor.org/rfc/rfc9849.html
- IETF. RFC 9000: QUIC: un protocollo di trasporto multiplexato e sicuro basato su UDP. https://www.rfc-editor.org/rfc/rfc9000.html
- Skyhigh Security. “L’adozione dell’ibrido è diventata più semplice grazie alla piattaforma Skyhigh SSE” (3 ottobre 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html
- Skyhigh Security. “Modernizzazione dell’ Secure Web Gateway Symantec Edge con Skyhigh Hybrid SSE Mesh” (15 luglio 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html