Gateway web sicuri: cloud vs. on-premises
- I gateway web sicuri basati su cloud e quelli on-premises si differenziano principalmente per il luogo in cui il traffico viene decrittografato e ispezionato.
- Gli SWG basati su cloud sono adatti agli utenti remoti e alle soluzioni SaaS; gli SWG on-premise sono adatti al traffico regolamentato, interno e OT.
- La latenza, la sovranità, la resilienza e i costi su larga scala rivestono maggiore importanza rispetto a elenchi di funzionalità sempre più simili tra loro.
- Un sistema ibrido di controllo degli accessi ( secure web gateway ) esamina ogni utente e ogni sito nel punto più opportuno, in base a un’unica politica.
- L'esecuzione di entrambi i modelli senza un motore di criteri condiviso determina una discrepanza tra gli utenti in sede e quelli remoti.
Un “ secure web gateway ” on-premises è un dispositivo proxy, fisico o virtuale, che opera nel proprio data center o nella propria filiale e ispeziona il traffico web a livello locale. Un “ secure web gateway ” basato su cloud svolge la stessa funzione dai punti di presenza del fornitore. Molte organizzazioni necessitano ormai di entrambe le soluzioni; per questo motivo l’architettura SWG ibrida è diventata una soluzione comune per le imprese soggette a regolamentazione.
Il presente articolo fa parte della guida alla sicurezza del cloud ibrido.
Di cosa si occupa un “ secure web gateway ”?
Un dispositivo di controllo di rete ( secure web gateway ) si interpone tra gli utenti e Internet per bloccare le minacce, garantire un utilizzo corretto e prevenire la perdita di dati, indipendentemente dal luogo in cui viene utilizzato.
In genere prevede:
- Filtraggio per URL e categoria
- Decrittografia e ispezione TLS
- Analisi dei malware, sandboxing e " remote browser isolation " per i siti a rischio
- Data loss prevention per i caricamenti e l'invio dei moduli
- Visibilità e controllo delle applicazioni cloud
- Registrazione ai fini delle indagini e della conformità
Il documento NIST SP 800-215 include gli SWG tra le soluzioni di sicurezza puntuali che le moderne reti aziendali combinano con ZTNA, CASB e altri controlli, man mano che il perimetro tradizionale viene meno.
SWG su cloud vs. SWG on-premises: confronto diretto
La differenza principale tra gli SWG basati su cloud e quelli on-premises risiede nel luogo in cui avviene l’ispezione e in chi ne è responsabile.
| Fattore | SWG Cloud | SWG on-premises |
|---|---|---|
| Luogo dell'ispezione | Punti di presenza dei fornitori | I vostri data center e le vostre filiali |
| Ideale per | Utenti remoti e mobili, traffico diretto verso il SaaS | Utenti degli uffici, degli stabilimenti e dei centri dati; traffico interno |
| Latenza | Dipende dalla distanza dal punto di presenza più vicino | Quantità minima di luppolo aggiunta per gli utenti in loco |
| Laddove siano presenti dati decriptati | Infrastruttura del fornitore | La vostra infrastruttura |
| Posizione del registro | Regioni selezionate dal fornitore o configurabili | Ovunque lo conservi |
| Dipendenza dalla connettività esterna | Obbligatorio | Non richiesto per l’ispezione locale supportata; i servizi forniti tramite cloud richiedono una connessione a Internet |
| Pianificazione della capacità | Responsabilità del fornitore | La vostra responsabilità |
| Impegno operativo | Minore impegno a livello hardware; le politiche e le eccezioni rimangono di vostra competenza | Il ciclo di vita dell’hardware, l’applicazione delle patch e il ridimensionamento sono di vostra competenza |
| Modello dei costi | Per utente o in base al consumo; si adatta al numero di utenti | Hardware e licenze, scalabilità in base alla produttività |
| Reti isolate fisicamente | Non adatto | Solo nei casi in cui sia esplicitamente supportato e siano state risolte tutte le dipendenze |
Luogo dell'ispezione
È il luogo in cui avviene l'ispezione a determinare chi gestisce i contenuti decriptati.
Per molte classi di traffico, un SWG basato su cloud dotato di controlli e certificazioni adeguati può soddisfare i requisiti. Per i carichi utili soggetti a regolamentazione, l’ispezione locale può ridurre l’elaborazione esterna; tuttavia, prima di scegliere la sede dell’ispezione, è necessario valutare i servizi inoltrati, la registrazione dei dati, le prove, l’accesso e i requisiti applicabili.
Le linee guida della NSA sulla gestione dei rischi derivanti dall’ispezione TLS raccomandano di eseguire tale ispezione una sola volta, all’interno della rete aziendale, ed evitare catene di proxy che decrittografino ciascuna lo stesso traffico. Le architetture ibride dovrebbero garantire che un determinato flusso venga decrittografato dal gateway locale o dal gateway cloud, ma non da entrambi. Si veda “Ispezione TLS locale vs. cloud: compromessi di implementazione”.
Latenza ed esperienza utente
La latenza dipende dal percorso effettivo, dalla distanza dal punto di presenza, dalla capacità del gateway e dal carico di ispezione.
Per gli utenti remoti, uno SWG basato su cloud può migliorare l’esperienza eliminando il backhaul VPN verso la sede centrale. Per gli utenti in sede, l’ispezione locale consente di evitare un percorso di transito su cloud, mentre l’ispezione su cloud può comunque risultare adeguata in base alla destinazione e alla configurazione della rete. Valutate la differenza per:
- Applicazioni in tempo reale quali piattaforme vocali, video e di trading
- Trasferimenti di file di grandi dimensioni e aggiornamenti software
- Siti situati lontano dal punto di presenza più vicino del fornitore
- Sistemi OT e industriali con requisiti temporali rigorosi
Controllo delle politiche
Entrambi i modelli applicano una politica granulare; la vera domanda è se i gateway cloud e quelli on-premises condividano un’unica politica.
Le organizzazioni che gestiscono un parco di dispositivi legacy parallelamente a un servizio cloud separato spesso mantengono due insiemi di regole, due insiemi di eccezioni e due configurazioni DLP. Con il passare del tempo, un utente in ufficio e lo stesso utente a casa vengono trattati in modo diverso, e nessuno se ne accorge fino a quando non si verifica un audit o un incidente.
Un SWG ibrido dotato di gestione unificata delle politiche consente ai team di definire una regola una sola volta e di applicarla su ogni gateway. Skyhigh SWG for Hybrid, ad esempio, supporta la gestione unificata delle politiche su tutti i punti di applicazione, sia on-premise che nel cloud, con le politiche definite una sola volta nella console cloud.
Impegno operativo
Gli SWG basati su cloud riducono il carico di lavoro relativo all’hardware, ma la gestione delle politiche, delle eccezioni e dei certificati rimane di competenza del Suo team in entrambi i modelli.
Gli SWG basati su cloud eliminano la necessità di procurarsi l’hardware, pianificare la capacità e applicare le patch alle appliance. Non eliminano invece la definizione delle politiche, la gestione delle eccezioni, la gestione dei certificati né la classificazione degli incidenti. Questi compiti rimangono di competenza del Suo team in entrambi i modelli.
Gli SWG on-premise richiedono una gestione del ciclo di vita: aggiornamenti hardware, aggiornamenti del sistema operativo e scalabilità per far fronte alla crescita del traffico. Le appliance virtuali e containerizzate riducono in parte tale carico di lavoro. Il passaggio a una piattaforma di un altro fornitore può comportare costi operativi non previsti. I clienti di Symantec Edge SWG (precedentemente noto come Blue Coat ProxySG), ad esempio, devono affrontare la fine del supporto per SGOS 7.3 e la rimozione della console di gestione basata su Java in SGOS 7.4. Si veda Blue Coat e «ProxySG End of Life: Migration Planning».
Resilienza
Gli SWG on-premise continuano a eseguire l’ispezione anche in caso di interruzione della connettività esterna, mentre gli SWG cloud dipendono dal fornitore e dal percorso di rete che conduce ad esso.
Uno SWG basato su cloud dipende dalla connettività con il fornitore e dalla disponibilità di quest’ultimo. La maggior parte delle organizzazioni accetta questa situazione per gli utenti remoti. Per uno stabilimento, un ospedale, una sala di negoziazione o una struttura governativa, la perdita dell’ispezione web o il passaggio in modalità “failing open” durante un’interruzione di servizio potrebbero risultare inaccettabili. I gateway on-premise continuano a ispezionare il traffico web a livello locale quando i collegamenti esterni non funzionano. I servizi che dipendono dal cloud del fornitore, quali la protezione dei dati e l’ remote browser isolation, non sono disponibili fino al ripristino del percorso. Si veda «Resilienza SSE ibrida: failover e ripristino».
Requisiti di migrazione
Ogni migrazione SWG, sia tra modelli diversi che tra fornitori diversi, prevede le stesse sei fasi:
- Politica attuale in materia di inventario, eccezioni, ambiti di autenticazione e integrazioni quali ICAP e DLP.
- Decidete quali utenti e siti trasferire a quale punto di applicazione.
- Ripristinare la gestione del traffico: proxy espliciti o file PAC, agenti, tunnel o controlli del browser.
- Riemettere e distribuire l'autorità di certificazione per l'ispezione TLS.
- Eseguire in parallelo con un gruppo pilota prima del passaggio definitivo.
- Effettuare il passaggio in più fasi, con un piano di ripristino collaudato.
Si veda “Secure Web Gateway : lista di controllo per il passaggio e il ripristino”.
Qual è il modello più adatto a Lei?
Scegliete in base alla posizione dei vostri utenti, delle vostre applicazioni e dei vostri dati soggetti a normative, non in base all’elenco delle funzionalità.
Si raccomanda di optare prevalentemente per il cloud qualora la maggior parte degli utenti operi in remoto, la maggior parte delle applicazioni sia di tipo SaaS e non sussistano normative o contratti che impongano l’elaborazione locale del traffico decriptato.
Si raccomanda di optare prevalentemente per soluzioni in loco qualora sia richiesta l’elaborazione locale o la continuità operativa per un traffico specifico. Per gli ambienti isolati fisicamente, classificati o OT, si raccomanda di verificare il supporto esplicito del prodotto e ogni dipendenza relativa alla gestione, all’identità, agli aggiornamenti, alle licenze e alle ispezioni.
Scegliete la soluzione ibrida se disponete di un mix di utenti in ufficio e in remoto, di dati soggetti a normative specifiche insieme al traffico generico, oppure se disponete di un parco gateway on-premise esistente che desiderate modernizzare senza dover passare obbligatoriamente al cloud. Ciò descrive la maggior parte delle grandi imprese operanti in settori soggetti a normative specifiche.
L'ibrido secure web gateway
Un SWG ibrido integra appliance on-premise e punti di presenza nel cloud sotto un unico motore di policy, un’unica console e un unico set di log.
Il traffico interno all’azienda viene controllato in loco, quello remoto nel cloud e il traffico regolamentato ovunque lo richiedano le politiche aziendali.
Skyhigh Hybrid SSE Mesh amplia le funzionalità di questo modello oltre i gateway web, aggiungendo ZTNA locale, controlli di sicurezza per il browser e soluzioni CASB, DSPM, DLP e RBI basate sul cloud, il tutto nell’ambito della stessa politica.
Fonti
- NIST. SP 800-215: Guida alla sicurezza dell’infrastruttura di rete aziendale (novembre 2022). https://csrc.nist.gov/pubs/sp/800/215/final
- 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
- Skyhigh Security. Secure Web Gateway per Hybrid. https://www.skyhighsecurity.com/products/secure-web-gateway-for-hybrid.html
- Skyhigh Security. “Skyhigh Security , al primo posto nella categoria ‘Casi d’uso avanzati di SSE’ nel rapporto Gartner del 2026 ‘ Critical Capabilities ’ relativo a ‘ Security Service Edge’ ” (5 agosto 2026). https://www.globenewswire.com/news-release/2026/08/05/3339504/0/en/skyhigh-security-ranked-1-in-advanced-sse-use-case-in-2026-gartner-critical-capabilities-for-security-service-edge.html
- Broadcom. Fine del ciclo di vita e ciclo di vita del prodotto per Edge SWG (ProxySG) e Advanced Secure Gateway (KB 151102). https://knowledge.broadcom.com/external/article/151102/end-of-life-and-product-lifecycle-for-pr.html