Secure Web Gateway vs Protezione DNS: Quale Usare
Confronta i secure web gateway con le protezioni a livello DNS per il WiFi ospiti e pubblico. Scopri le funzionalità, i compromessi sulle prestazioni e dove posizionare ciascuna soluzione nel tuo stack.
Published 19 ottobre 2026
Se un ospite accede al vostro WiFi con un laptop compromesso, cosa impedisce il callback al suo server di comando e controllo, e cosa potete dimostrare in seguito? È questa domanda, e non un elenco di funzionalità, a dover stabilire se avete bisogno di un secure web gateway, di una protezione a livello DNS o di entrambi.
Sommario
- Perché è importante il giusto livello di protezione web
- Cosa fa effettivamente un Secure Web Gateway
- Come funziona la protezione a livello DNS
- Confronto tra funzionalità e prestazioni
- Dove si inserisce ciascun approccio nel tuo stack
- Come scegliere l'approccio giusto
- Testare e verificare la protezione
Perché è importante scegliere il giusto livello di protezione web
Un ospite effettua il check-in in un hotel, apre un laptop e si connette all'SSID. Il dispositivo sembra comune. Si autentica, ottiene un indirizzo IP e inizia a risolvere domini, uno dei quali appartiene a un servizio di comando e controllo che il malware presente sul dispositivo tenta di raggiungere da giorni.
In quel momento non hai il controllo sull'endpoint. Non puoi verificare se il suo antivirus sia aggiornato, installare un agente o configurare un certificato per l'ispezione TLS. Devi operare attraverso il percorso di rete, e il livello in cui applichi le policy determina ciò che puoi bloccare e le evidenze di cui disporrai in seguito.
La domanda fondamentale prima dell'acquisto
Gli operatori chiedono spesso quale sia il prodotto migliore. È l'impostazione sbagliata. Un secure web gateway e un servizio a livello DNS applicano le policy in punti diversi, vedono elementi diversi e si interrompono in modi diversi; pertanto la domanda utile è quale punto di applicazione si adatti al tuo mix di dispositivi, ai tuoi siti e al tuo dovere di protezione.
Considera tre situazioni comuni all'interno della stessa struttura. Il tablet di uno studente necessita di filtraggio per categorie e Safe Search. Il telefono di un fornitore esterno richiede protezione da phishing senza che nessuno debba toccare il dispositivo. Un laptop aziendale gestito potrebbe richiedere l'ispezione completa dei caricamenti verso archivi non autorizzati. Un singolo livello raramente gestisce tutti e tre i casi con la stessa efficacia.
Regola pratica: Partire dalla proprietà del dispositivo. Meno si controlla l'endpoint, più l'applicazione delle policy deve essere tempestiva e nativa di rete.
Sbagliare questo aspetto ha conseguenze visibili. Implementate un'ispezione profonda dove non potete gestire i certificati e interromperete il funzionamento delle applicazioni o eviterete il traffico che intendevate ispezionare. Affidatevi solo ai controlli delle tabelle di lookup dove vi serve visibilità sul payload e vi sfuggiranno le minacce veicolate all'interno di sessioni altrimenti consentite. Entrambi gli errori lasciano una falla che scoprirete durante un incidente, non durante la fase di acquisto.
L'esperienza utente è ugualmente fondamentale. Gli ospiti valutano la tua rete in pochi secondi. I controlli che aggiungono ritardi visibili, impongono escamotage per il Captive Portal o bloccano servizi legittimi senza una chiara spiegazione generano chiamate di supporto e pressioni per indebolire le policy. I controlli che operano durante l'impostazione della connessione tendono a resistere all'impatto con le sedi reali.
La scelta non è neanche binaria. Molte infrastrutture necessitano di una baseline ampia che copra ogni dispositivo, oltre a un'ispezione più profonda per la percentuale minore di endpoint gestiti in cui tale ispezione è tecnicamente e legalmente fattibile. La difesa in profondità in questo contesto non è uno slogan. È l'ammissione che ogni livello dimostra qualcosa di diverso, e dovreste sapere esattamente cosa sia quel qualcosa prima di firmare.
Cosa fa effettivamente un Secure Web Gateway
Un secure web gateway deve essere inteso principalmente come un punto di ispezione e applicazione delle policy per il traffico web in uscita, non come una blacklist più grande. Il NIST descrive questa funzione come la protezione del traffico utente in uscita tramite l'ispezione HTTP e HTTPS, centralizzando al contempo il controllo, la visibilità e il reporting tra sede centrale, filiali, uffici domestici e sedi remote, come è possibile approfondire nella guida del NIST sulle funzioni dei secure web gateway.
In pratica, il traffico viene reindirizzato al gateway in modo esplicito tramite le impostazioni proxy, attraverso un tunnel da una filiale o mediante un agente su un dispositivo gestito. Il gateway valuta la richiesta rispetto alla policy, ispeziona il contenuto restituito e registra la decisione. Se questo modello proxy non risulta familiare, è utile comprendere prima i concetti di inoltro correlati, tra cui come funzionano i reverse proxy, prima di confrontare le architetture dei vari fornitori.
Funzionalità chiave da valutare
- Filtraggio di URL e categorie: blocca o consente le destinazioni in base alla reputazione e alla classe di contenuto, anziché solo in base al dominio.
- Rilevamento di malware e phishing: scansiona download e pagine, inclusi i contenuti all'interno di sessioni consentite in cui l'ispezione è abilitata.
- Controlli delle applicazioni: distingue tra servizi autorizzati e non autorizzati che condividono la stessa infrastruttura sottostante.
- Ispezione TLS: decrittografa e crittografa nuovamente il traffico nei punti in cui è possibile distribuire chiavi di attendibilità, operazione semplice sui dispositivi gestiti ma complessa sui dispositivi degli ospiti.
- Registro di controllo e ambito delle regole: registra chi o cosa ha richiesto una risorsa, quale regola è stata applicata e quale azione è seguita.
Quest'ultimo punto distingue un gateway da una semplice blocklist. Si acquistano policy ed evidenze coerenti, applicate allo stesso modo in diverse sedi, e non un semplice feed di domini dannosi.
Contesto di mercato e di distribuzione
La categoria rappresenta ora un'area principale di investimento nella sicurezza. Il mercato dei secure web gateway è stato stimato a 14,75 miliardi di USD nel 2024, con previsioni fino a 75,54 miliardi di USD entro il 2033 con un CAGR del 20,6%, e l'America del Nord ha detenuto il 37,4% del fatturato globale nel 2024, secondo le stime di mercato di Grand View Research per i secure web gateway. Considerate queste cifre come stime degli analisti e non come totali sottoposti a revisione contabile, poiché i fornitori e i ricercatori definiscono i confini dei prodotti in modo differente.
L'erogazione si è spostata in modo decisivo verso il cloud. L'implementazione basata su cloud ha rappresentato il 76,32% dei ricavi SWG nel 2025, con una crescita prevista delle distribuzioni cloud a un CAGR del 22,05% fino al 2031, secondo l'analisi di Mordor Intelligence sui modelli di distribuzione SWG. Questo è fondamentale a livello operativo. Un gateway cloud può applicare regole senza richiedere un dispositivo fisico in ogni sede, un approccio ideale per le infrastrutture distribuite, sebbene introduca una dipendenza dall'instradamento e dalla prossimità ai punti di ispezione.
Il compromesso è costante. Si guadagna in profondità, visibilità del payload e controllo granulare delle applicazioni. Il prezzo da pagare è la complessità di distribuzione, la gestione dei certificati e il lavoro continuo di instradamento del traffico affinché l'ispezione avvenga.
Come funziona la protezione a livello DNS
Ogni connessione inizia con una richiesta. Prima che un browser, un'app o un malware possano raggiungere un servizio, di solito risolvono un nome, e il DNS protettivo risponde a quella ricerca in base alle policy prima ancora che la connessione abbia inizio.
Se il dominio è noto per phishing, distribuzione di malware o comando e controllo, il resolver rifiuta o reindirizza la ricerca. Il dispositivo non ottiene mai una destinazione utilizzabile, quindi la chiamata di ritorno fallisce nel momento stesso in cui viene avviata. Si tratta di un intervento più mirato rispetto all'ispezione del payload, ma ha il vantaggio di funzionare senza dover intervenire sull'endpoint.
Cosa succede al momento della risoluzione DNS
I criteri di categoria funzionano allo stesso modo. Una richiesta per un dominio per adulti o di gioco d'azzardo su un SSID per famiglie può essere bloccata, mentre la stessa ricerca su una rete del personale segue una regola diversa. L'applicazione di Safe Search su Google, Bing e YouTube può essere implementata tramite il comportamento di risoluzione, e i domini di annunci e tracciamento possono essere trattenuti in modo che le pagine abbiano un impatto minore in termini di terze parti.
La granularità delle policy è ciò che rende questo sistema utile in un'intera rete. È possibile variare le regole per SSID, VLAN, sede e orario, in modo che una scuola applichi un filtraggio più severo durante le ore di lezione, un hotel separi il traffico degli ospiti da quello gestionale e un gruppo di pub mantenga una linea di base comune consentendo al contempo eccezioni a livello di singola sede. La reportistica mostra quindi quale dominio è stato richiesto, quale policy è stata applicata e su quale segmento di rete.
Un blocco DNS dimostra che una ricerca è stata interrotta in base a una policy specifica in un determinato momento registrato. Non dimostra che il contenuto dietro quel dominio sia stato ispezionato, e un report onesto non dovrebbe far finta del contrario.
Perché è ideale per i dispositivi non gestiti
L'implementazione è il vantaggio decisivo. Non c'è alcun acquisto di hardware, alcuna modifica al firewall e nulla da installare sui dispositivi client, quindi la copertura si estende a telefoni, dispositivi da gioco, smart TV e a tutta quella serie di dispositivi mai raggiunti dagli agent. Un ospite che si connette per venti minuti ottiene la stessa protezione di base di un residente che soggiorna per un intero trimestre.
Questa semplicità presenta dei limiti che vanno chiariti in modo trasparente. Il DNS vede il nome che viene risolto, non il percorso URL completo o il payload restituito attraverso una connessione consentita. Un file malevolo ospitato su un servizio autorizzato e reputato affidabile non verrà bloccato dalla sola ricerca DNS. Inoltre, i client che aggirano il resolver tramite DNS crittografato, risoluzione hardcoded o una VPN possono ridurre la visibilità, a meno che la rete non gestisca attivamente tali percorsi.
La protezione a livello DNS offre un controllo ampio, tempestivo e basato su evidenze con il minimo attrito. Non fornisce un'ispezione approfondita. Sapere di quale di queste due soluzioni si ha realmente bisogno costituisce l'intera decisione.
Confronto tra funzionalità e prestazioni
Il modo più lineare per confrontare questi livelli è basarsi su ciò che ciascuno di essi può osservare. Un gateway posizionato nel percorso del traffico può ispezionare richieste e risposte, inclusi i payload HTTPS completi laddove l'ispezione TLS sia distribuibile in modo legittimo. La protezione DNS osserva la ricerca che precede la connessione. Tutto il resto deriva da questa differenza.
Ciò significa che le minacce nascoste all'interno di sessioni HTTPS consentite, i caricamenti dannosi e la perdita di dati attraverso servizi apparentemente autorizzati richiedono controlli a livello di gateway o endpoint. Significa anche che un gateway che non può essere posizionato nel percorso di rete per un dispositivo ospite non ispeziona assolutamente nulla, per quanto sia potente il suo motore. Una copertura che puoi effettivamente applicare supera qualsiasi funzionalità che non sei in grado di gestire.
Confronto rapido: SWG vs Protezione a livello DNS
| Criterio | Secure Web Gateway | Protezione a livello DNS |
|---|---|---|
| Profondità di ispezione | Richiesta e risposta complete nel percorso di connessione | Risoluzione del dominio prima della connessione |
| Copertura dei dispositivi | Massima sui dispositivi gestiti | Tutti i dispositivi che utilizzano il resolver |
| Impatto sulle prestazioni | Dipende dall'ispezione e dalla distanza dal punto di presenza | Minimo, limitato alla risoluzione |
| Complessità di implementazione | Instradamento, tunnel, agenti o certificati | Configurazione del resolver per rete |
| Qualità dei dati di evidenza | Verdetti su URL, utente, azione e contenuto | Dominio, policy, segmento, timestamp, azione |
| Punto cieco principale | Traffico che aggira il percorso proxy | Payload all'interno di sessioni consentite |
La qualità dei dati alimenta entrambe le righe di quella tabella. L'accuratezza della categoria, l'aggiornamento e la velocità di ricategorizzazione determinano se l'uno o l'altro controllo blocchi gli elementi corretti, quindi vale la pena comprendere come i feed di threat intelligence influenzano le decisioni di filtraggio prima di confrontare le offerte dei fornitori.
Prestazioni misurabili
Non confrontare la velocità effettiva indicata in una scheda tecnica con il caricamento della pagina di un utente ospite. Le linee guida SWG indipendenti riportano circa 40–80 ms di latenza aggiuntiva quando gli utenti sono vicini a un punto di presenza cloud e circa 150–400 ms quando sono lontani, mentre la scheda tecnica di un dispositivo fisico pubblicata riporta fino a 110 Gbps di throughput firewall e più di 25 Gbps di throughput IPS in condizioni di laboratorio; cifre dettagliate nella scheda tecnica del dispositivo Check Point e nelle linee guida sulle prestazioni SWG. Tali numeri descrivono aspetti diversi. Il throughput di laboratorio dice ben poco sul tempo di handshake TLS in una sede rurale congestionata durante i picchi di accesso.
Misura invece la percezione degli ospiti. Confronta la sicurezza attivata rispetto a quella disattivata presso siti rappresentativi, durante i periodi di picco, e riporta la mediana insieme alla latenza p95 e p99 per la risoluzione DNS, la configurazione TLS e il tempo di caricamento dei contenuti rilevanti. Le medie nascondono le sedi con le prestazioni peggiori, che sono esattamente quelle da cui hanno origine i reclami.
Il limite di QUIC e del DNS crittografato
QUIC funziona su UDP, impone la crittografia TLS 1.3 e supporta la migrazione della connessione tra WiFi e reti cellulari, il che crea un divario di applicazione per i gateway convenzionali, come descritto nella ricerca sul proxying consapevole di QUIC e sull'inoltro del traffico. Il blocco di UDP sulla porta 443 può forzare il fallback a TCP ispezionabile, ma potrebbe ridurre le prestazioni o interrompere le applicazioni moderne. Consentire QUIC preserva l'esperienza dell'utente riducendo al contempo la visibilità di un gateway tradizionale.
I criteri DNS si applicano comunque al momento della risoluzione se il client utilizza il vostro resolver, motivo per cui i due controlli rispondono a domande diverse. Chiedete ai fornitori di definire con precisione il concetto di bloccato. È stata interrotta una risoluzione, è stata impedita una connessione o il contenuto è stato effettivamente ispezionato? Si tratta di tre affermazioni ben distinte.
Dove si inserisce ciascun approccio nel tuo stack
Il tipo di struttura prevede la risposta meglio delle dimensioni dell'organizzazione. Un utile punto di partenza consiste nel verificare la proprietà dei dispositivi su ciascun SSID, per poi mappare le esigenze di ispezione a tale realtà, un approccio riflesso anche nei consigli di sicurezza di Nerds 2 You Edmonton per le reti più piccole che valutano controlli multilivello.
Settore dell'accoglienza, aeroporti, biblioteche e attrazioni per famiglie gestiscono reti in cui quasi tutti i dispositivi sono non gestiti e temporanei. La protezione a livello DNS si adatta perfettamente perché copre gli ospiti immediatamente, supporta livelli gratuiti o a pagamento tramite criteri per SSID e produce prove del filtraggio senza ispezionare i contenuti personali. Un gateway aggiunge poco in quel contesto se non potete instradare o decifrare il traffico degli ospiti in modo responsabile.
Scuole, campus e alloggi per studenti si trovano nel mezzo. Gli obblighi di protezione dei minori e salvaguardia richiedono un filtro di categoria coerente e Safe Search su ogni dispositivo, compresi telefoni personali e console. I dispositivi didattici gestiti, tuttavia, possono giustificare l'ispezione del gateway per il controllo delle applicazioni e la scansione dei download, motivo per cui molte strutture integrano entrambi i livelli applicandoli a segmenti diversi.
Vale la pena analizzare nella pratica il modello operativo che sta alla base di questa suddivisione.
Gli ospedali e le strutture sanitarie affrontano una suddivisione simile. Il WiFi per pazienti e visitatori richiede un filtraggio ampio e senza ostacoli. I sistemi clinici e amministrativi si trovano dietro controlli più rigidi e gestiti separatamente, e unire questi gruppi sotto un unico modello di ispezione di solito non porta benefici a nessuno dei due.
Quando un gateway giustifica il suo costo
Gli uffici aziendali e le imprese multi-sede con flotte gestite sono l'ambiente ideale per il gateway. È possibile distribuire agenti o tunnel, gestire certificati, associare le policy all'identità e ispezionare i caricamenti verso servizi non autorizzati. I segmenti BYOD (Bring-Your-Own-Device) in quegli stessi uffici richiedono comunque una riflessione separata, poiché i dispositivi personali oppongono resistenza proprio a quei controlli che rendono efficace un gateway - una tensione approfondita nella guida sulla sicurezza BYOD per ambienti con dispositivi misti.
- SSID ospiti e pubblici: livello base DNS, pagine di blocco trasparenti, reportistica per singola sede.
- Reti per studenti e residenti: filtraggio DNS ovunque, controlli gateway sui dispositivi gestiti.
- Segmenti aziendali e del personale: ispezione del gateway legata all'identità, con il DNS come blocco preventivo.
- Tecnologia operativa e display: policy DNS per dispositivi che non possono eseguire agenti, allowlist con ambito restrittivo.
Il modello ibrido non è sintomo di indecisione. Significa assegnare ciascun livello all'utenza in cui la relativa applicazione risulta efficace.
Come scegliere l'approccio giusto
Tre domande risolvono la maggior parte delle valutazioni. Chi possiede i dispositivi, quale livello di ispezione richiede la vostra posizione di rischio o conformità e quale capacità operativa avete per gestire correttamente il controllo? Rispondete a queste domande per ciascun segmento di rete, non per l'organizzazione nel suo complesso.
Se i dispositivi non gestiti sono la maggioranza, iniziate con la protezione a livello DNS come impostazione predefinita. Copre ogni tentativo di connessione che utilizza il vostro resolver, si distribuisce senza interventi sugli endpoint e fornisce prove verificabili di cosa è stato bloccato, dove e quando. Per hotel, pub, aeroporti e WiFi pubblico, questo è il controllo che continuerà a funzionare anche in un sabato di massimo affollamento, quando nessuno è disponibile per risolvere un'eccezione del proxy.
Se i dispositivi gestiti sono la maggioranza e necessitate di ispezione del payload, controllo delle applicazioni o prevenzione della perdita di dati, scegliete un secure web gateway e finanziate il lavoro operativo richiesto. Questo include l'instradamento del traffico, il ciclo di vita dei certificati, la gestione delle eccezioni per le applicazioni con certificate pinning e la pianificazione della capacità per i punti di ispezione. Acquistare la licenza senza svolgere questo lavoro significa ottenere una copertura solo parziale.
L'affidabilità prima dell'elenco delle funzionalità
Siate scettici di fronte alle dichiarazioni di rilevamento non verificabili. Una ricerca indipendente che ha valutato gli strumenti di filtro famiglia ha rilevato una protezione non uniforme tra i diversi fornitori, senza che un singolo strumento fornisse una copertura completa, mentre il filtraggio dei resolver DNS ha mostrato prestazioni più coerenti rispetto a diverse alternative, e Cloudflare ha segnalato che i link ingannevoli rappresentavano il 52% delle e-mail malevole analizzate nel 2025, in aumento rispetto al 43% del 2024, secondo la ricerca indipendente sulla copertura degli strumenti di filtraggio e sulle tendenze dei link ingannevoli.
Test di selezione: Chiedete a ciascun fornitore con quale rapidità viene classificato un dominio registrato di recente, come funzionano i ricorsi di riclassificazione e quali prove produce un singolo blocco. Risposte vaghe presagiscono problemi operativi.
Per la maggior parte delle infrastrutture miste, la raccomandazione più onesta è adottare entrambi, sequenziati in modo sensato. Implementate prima la baseline DNS perché è rapida, copre i dispositivi che niente altro riesce a toccare e crea immediatamente evidenze sull'intera infrastruttura. Aggiungete l'ispezione gateway dove la proprietà del dispositivo e il livello di rischio lo giustificano. Questo ordine colma prima la falla più grande invece di perfezionare la protezione per i dispositivi più semplici da gestire.
Testare e verificare la protezione
Non accettate uno screenshot della dashboard come prova. Eseguite un test di accettazione sui vostri SSID, con il vostro mix di dispositivi, prima di impegnarvi, e strutturatelo in base al comportamento effettivo del traffico piuttosto che a come il diagramma di vendita sostiene debba funzionare. Per una progettazione dei test più ampia, consultate le raccomandazioni di ThreatExploit AI sulla creazione di routine di test di sicurezza ripetibili.
Un test di accettazione davvero significativo
Misura l'applicazione delle policy separatamente per DNS, HTTP, HTTPS, QUIC, DNS crittografato e IPv6, quindi verifica che i risultati rimangano coerenti tra SSID, VLAN, sedi e orari. Un blocco che funziona sulla rete del personale ma non sulla VLAN ospiti, o durante il giorno ma non con una policy serale, è un problema concreto, non una nota a margine.
- Ricerche su domini notoriamente malevoli: confermare che i domini di test per phishing, malware e command-and-control vengano bloccati e registrati con la relativa regola e segmento.
- Controlli delle categorie: verificare le categorie per adulti, gioco d'azzardo e altre categorie limitate su ciascun SSID, oltre al comportamento di Safe Search sui principali servizi di ricerca e video.
- Tentativi di aggiramento: provare a utilizzare DNS crittografati, una VPN consumer, l'accesso diretto tramite IP e browser abilitati per QUIC, quindi registrare ciò che ciascun controllo continua a rilevare.
- Domini recenti: testare domini registrati di recente e non categorizzati, prendendo nota se la regola predefinita li autorizza, li blocca o invia un avviso.
- Servizi legittimi: confermare che i pagamenti, le videoconferenze e le applicazioni critiche per la struttura continuino a funzionare senza un accumulo di eccezioni manuali.
Comportamento in caso di errore e prestazioni
Testate la modalità fail-open rispetto a fail-closed in modo deliberato interrompendo il servizio o il tunnel. È necessario sapere se un'interruzione causa la navigazione bloccata o una rete non filtrata, e quale di queste opzioni sia tollerabile per il vostro dovere di diligenza. Documentate questo comportamento nel vostro registro dei rischi, poiché gli auditor lo richiederanno. La stessa disciplina di evidenza supporta un lavoro di garanzia più ampio, inclusi i controlli descritti nella guida sui requisiti di certificazione Cyber Essentials.
Esegui un benchmark presso siti rappresentativi durante i periodi di picco. Registra il caricamento della pagina fino ai contenuti rilevanti, il tempo di risoluzione DNS, il tempo di handshake TLS e il throughput in presenza di utenti simultanei, confrontando la sicurezza attivata rispetto a quella disattivata e riportando la mediana insieme a p95 e p99. Includi la perdita del tunnel o del point-of-presence in modo da osservare il comportamento di riconnessione prima che lo facciano gli ospiti.
Infine, ispeziona la prova stessa. Ogni blocco dovrebbe conservare timestamp, criteri, segmento di rete, dominio richiesto, azione e motivo. Un contatore aggregato non soddisferà un responsabile della sicurezza, un'assicurazione o la tua stessa revisione degli incidenti. Se la reportistica non è in grado di ricostruire una singola decisione, il controllo non è completo, a prescindere da ciò che ha bloccato.
Purple Shield offre protezione DNS e filtraggio dei contenuti progettati per WiFi di ospiti, sedi e spazi pubblici, verificando ogni ricerca prima che la connessione abbia inizio e applicando le policy per SSID, VLAN, sede e orari senza installare agenti sui dispositivi degli utenti. Se desiderate questa visibilità di base nella vostra rete mentre valutate dove applicare un'ispezione gateway più approfondita, visitate Purple Shield per scoprire come distribuirlo sulla vostra infrastruttura esistente.