Configurare la protezione web di Sophos Firewall con le politiche web

La protezione web di Sophos Firewall controlla quali siti web, categorie e contenuti web gli utenti possono raggiungere. In pratica, la protezione web non è semplicemente un singolo flag. Una politica web deve essere pianificata professionalmente, attivata in una regola firewall appropriata e successivamente testata con traffico reale.

Molti errori si verificano perché una politica web esiste, ma non viene applicata a una regola firewall attiva. Altri problemi sono legati a HTTPS, ispezione TLS, QUIC, riconoscimento utente, ordine delle regole o eccezioni troppo generiche. Il flusso logico è quindi: pianificare la politica, costruire la regola, attivarla, testarla e monitorarla in produzione.

Quale articolo sulla protezione web è adatto?

La protezione web si sovrappone a regole firewall, ispezione TLS, QUIC, reportistica ed eccezioni. A seconda del compito, un articolo più specifico potrebbe essere più adatto:

• Configurare fondamentalmente la protezione web e le politiche web: Questo articolo.
• Valutare categorie web, gruppi di URL e avvisi istantanei: Utilizzare le categorie web e gli avvisi istantanei di Sophos Firewall.
• Decrittare e verificare il traffico HTTPS: Implementare correttamente l’ispezione TLS di Sophos Firewall.
• Distribuire il certificato CA per i client gestiti: Distribuire il certificato CA di Sophos Firewall per l’ispezione TLS.
• Classificare QUIC e HTTP/3 in caso di problemi di filtraggio web: Bloccare correttamente QUIC e HTTP/3 su Sophos Firewall.
• Scoprire quale regola firewall e politica sono effettivamente applicate: Testare le regole di Sophos Firewall con Log Viewer, Policy tester e Packet Capture.
• Valutare eventi web e di sicurezza a lungo termine: Central Firewall Reporting o Inviare Syslog a SIEM.

In questo modo l’analisi rimane chiara: prima bisogna verificare se la regola firewall corrisponde. Successivamente, si controllano la politica web, la categoria, il contesto utente, QUIC, l’ispezione TLS e la registrazione.

Cosa controlla la protezione web

La protezione web è composta da diversi componenti. Non tutti i componenti devono essere utilizzati in ogni ambiente, ma le relazioni dovrebbero essere chiare.

• Politica web: Regole per accessi web consentiti, avvisati, bloccati o basati su quota.
• Categorie web: Categorie Sophos e categorie personalizzate per i siti web.
• Gruppi di URL: Liste di domini personalizzate per regole di consentito o bloccato mirate.
• Tipi di file: Controllo di determinati tipi di download o file.
• Filtri di contenuto: Termini o modelli per il controllo dei contenuti.
• Eccezioni: Eccezioni mirate per comportamento web, TLS o di scansione.
• Impostazioni generali: SafeSearch, restrizioni YouTube, Google Apps e restrizioni tenant Microsoft Entra ID.
• Registrazione e reportistica: Tracciabilità in Log Viewer, Reporting, Central o SIEM.

La protezione web non sostituisce una base di regole firewall pulita. La regola firewall decide prima quale traffico da quale zona a quale zona di destinazione è consentito. La politica web integra questa regola con il controllo web. Le basi per l’ordine delle regole, la sorgente, la destinazione, i servizi e i profili di sicurezza sono disponibili in Comprendere e costruire correttamente le regole di Sophos Firewall.

Prerequisiti

Prima del rollout, questi punti dovrebbero essere chiariti:

• La protezione web è concessa in licenza o inclusa nel pacchetto utilizzato.
• Le reti client interessate hanno regole firewall proprie.
• La registrazione è attiva nelle regole rilevanti.
• DNS e orario del firewall funzionano correttamente.
• Il riconoscimento utente è chiarito, se le politiche devono applicarsi per utente o gruppo.
• L’ispezione TLS è pianificata, se i contenuti HTTPS devono essere esaminati più da vicino.
• QUIC/HTTP/3 è consapevolmente consentito o bloccato.
• Esiste un gruppo pilota e un percorso di fallback per i siti critici per il business.

Particolarmente importante è la separazione per gruppi target. Una politica web per client normali, server, ospiti, utenti VPN e sistemi di gestione non dovrebbe essere la stessa. I server spesso necessitano di meno controllo di navigazione, ma liste di destinazione e aggiornamento più rigorose. Gli ospiti spesso necessitano di categorie e limitazioni di larghezza di banda, ma non di accesso alle risorse interne.

Se le politiche web devono reagire a utenti o gruppi, il riconoscimento utente deve funzionare. AD SSO, Captive Portal, STAS, SATC o altri metodi non dovrebbero essere scoperti solo durante il rollout della politica web. Nel Log Viewer deve essere visibile se una richiesta è stata valutata come utente noto, come gruppo oppure come Anybody o utente sconosciuto.

Pianificare la politica web

Una buona politica web non inizia nell’interfaccia, ma con alcune decisioni professionali.

Definire i gruppi target

Per prima cosa si stabilisce per chi è valida la politica:

• Client standard nella LAN
• Notebook gestiti tramite VPN
• WLAN ospiti
• Aule o ambienti scolastici
• Server con accesso HTTP/HTTPS in uscita
• Postazioni amministrative privilegiate

Se la stessa regola firewall contiene più gruppi molto diversi, la protezione web diventa difficile da comprendere. Meglio regole e politiche separate, ad esempio LAN_USERS_WEB, GUEST_WEB o SERVER_UPDATES_WEB.

Stabilire categorie e gruppi di URL

Le categorie web di Sophos sono utili per un controllo ampio: malware, phishing, contenuti per adulti, anonimizzatori, streaming, social media o giochi. I gruppi di URL sono migliori quando si desidera consentire o bloccare singoli domini in modo mirato.

Uso tipico:

• Bloccare categorie di rischio note: Categoria web.
• Consentire determinati domini SaaS: Gruppo di URL.
• Gestire un singolo dominio categorizzato erroneamente: Gruppo di URL o categoria personalizzata.
• Limitare temporalmente lo streaming: Politica web con pianificazione o quota.
• Pagina di avviso invece di blocco rigido: Politica web con azione di avviso.

I gruppi di URL non dovrebbero diventare una lista di raccolta non ordinata. Se vengono inseriti molti domini, la lista necessita di un proprietario, uno scopo e una data di revisione. Per liste molto grandi o dinamiche, Sophos Firewall Threat Feeds o altri componenti architetturali sono spesso più appropriati.

Per corrispondenze basate solo sul dominio, i gruppi di URL sono di solito migliori delle categorie web personalizzate. Sophos indica che i gruppi di URL sono più performanti e possono generare meno falsi positivi. Le categorie personalizzate sono utili quando un dominio deve comparire in una logica di policy propria oltre alla sua categoria standard Sophos.

Le keyword nelle categorie personalizzate vanno usate con molta cautela. Le keyword vengono confrontate con l’intero URL, inclusi percorso e query. Un allow basato su una keyword può quindi applicarsi involontariamente se la parola compare in un parametro di query su un altro dominio. Per decisioni di allow, domini concreti o gruppi di URL sono di solito più puliti; le regole keyword si adattano meglio a casi di blocco stretti.

Impostare con cautela le regole di consentito

Le regole di consentito nelle politiche web dovrebbero essere strette. Una regola di consentito in alto può rendere inefficaci le regole di blocco successive, poiché le regole delle politiche web di Sophos vengono valutate dall’alto verso il basso. Questo è particolarmente rilevante se un gruppo di URL, una regola di tipo di file o un’eccezione di categoria si trova sopra altre regole.

Praticamente si è dimostrato efficace:

1. Eccezioni aziendali specifiche consentite in alto.
2. Categorie di blocco critiche dopo.
3. Regole di avviso o quota per aree grigie.
4. Traffico web generalmente consentito solo alla fine.

Creare una politica web

La politica web viene creata nel seguente menu:

Web > Policies

Procedura di base:

1. Selezionare Add policy.
2. Assegnare un nome significativo, ad esempio LAN_USERS_STANDARD_WEB.
3. Aggiungere regole.
4. Verificare search engine enforcement, ad esempio SafeSearch o YouTube restrictions.
5. Impostare policy quota status se vengono usate azioni Quota.
6. Verificare Advanced settings, in particolare logging, reporting, download di grandi dimensioni, Google Apps e Microsoft Entra ID Tenant Restrictions.
7. Salvare la politica.

Una regola all’interno della politica web viene creata con Add rule. Il firewall crea prima una regola predefinita disattivata che blocca HTTP per Anybody. Poi i campi vengono adattati in modo mirato:

1. Aprire Users e impostare consapevolmente Anybody, utenti specifici o gruppi.
2. Aprire Activities e selezionare All web traffic, User activities, Categories, URL Groups, File types o Content filters.
3. Aggiungere Content filters se necessario. Per i Content filters, il firewall usa per HTTPS la stessa azione di HTTP.
4. Impostare Action per HTTP: Allow, Warn, Block o Quota.
5. Verificare l’azione HTTPS: Use action, Allow HTTPS, Warn HTTPS, Block HTTPS o Quota HTTPS.
6. Impostare Constraints se la regola deve valere solo per un programma.
7. Verificare la posizione della regola all’interno della policy.
8. Attivare lo stato della regola.
9. Salvare la policy.

Una politica web da sola non ha effetto. La politica deve essere utilizzata successivamente in una regola firewall. Questo è uno degli errori di configurazione più comuni.

Le regole in una politica web vengono valutate dall’alto verso il basso. Una regola Allow per All web traffic sopra una regola Block rende di fatto inefficace la regola di blocco. Dopo ogni modifica si dovrebbe quindi controllare non solo il contenuto della regola, ma anche l’ordine e l’interruttore di stato.

Attivare la politica web nella regola firewall

La regola firewall si trova sotto:

Rules and policies > Firewall rules

Per il traffico Internet normale dei client, di solito è responsabile una regola da LAN o una zona client a WAN. Lì, nell’area Web filtering, viene selezionata la politica web appropriata.

Punti di controllo nella regola firewall:

• La zona di origine e le reti di origine corrispondono alla rete client.
• La zona di destinazione è di solito WAN.
• I servizi includono HTTP/HTTPS o i servizi web desiderati.
• Log firewall traffic è attivo.
• Nell’area Web filtering è impostata la politica web corretta.
• Scan HTTP and decrypted HTTPS è attivato quando devono funzionare la scansione malware web o il controllo dei contenuti.
• Use Zero-day protection è utile solo se i file vengono scansionati tramite HTTP o HTTPS decrittato.
• Block QUIC protocol è impostato consapevolmente.
• Use web proxy instead of DPI engine è attivato o disattivato consapevolmente.
• L’ispezione TLS è pianificata separatamente e non confusa con la politica web.

Sophos Firewall imposta Block QUIC protocol per impostazione predefinita quando nella regola viene selezionata una politica web o viene attivato Scan HTTP and decrypted HTTPS. Spesso è sensato, perché QUIC non può essere scansionato come il traffico HTTPS classico. Tuttavia l’opzione va testata consapevolmente: browser, servizi Google, strumenti di collaborazione e singole applicazioni SaaS possono cambiare comportamento quando QUIC viene bloccato.

Se nella stessa regola firewall viene usato anche Application Control, c’è una sovrapposizione importante: alcune Micro Apps, ad esempio upload o download in Dropbox o Gmail, vengono riconosciute tramite dettagli URL. In ambienti DPI, questo riconoscimento richiede una regola SSL/TLS Inspection adatta con decrittazione. Application Control può quindi valutare queste Micro Apps anche se la politica web non è il principale punto decisionale.

Se una regola più generale sopra la regola web desiderata corrisponde, il traffico non raggiunge la politica web. In tali casi, aiuta Testare le regole di Sophos Firewall con Log Viewer e Packet Capture.

Classificare HTTPS, ispezione TLS e QUIC

Una grande parte del traffico web è HTTPS. Senza ispezione TLS, il firewall vede meno contenuti. Categorie, SNI, certificati, IP di destinazione, informazioni sul dominio e metadati aiutano, ma non sostituiscono una verifica completa dei contenuti.

DPI o Web Proxy?

Con la protezione web, bisogna decidere presto se la regola firewall interessata utilizza il DPI Engine o il Web Proxy. Questa decisione influenza quali funzioni si applicano e quali registri sono rilevanti in seguito.

• Modalità DPI: standard moderno per molte regole Internet client. L’ispezione TLS avviene tramite regole di ispezione SSL/TLS, la quota non è supportata.
• Modalità Web Proxy: ambienti con comportamento proxy esplicito o quota di politica. Verificare consapevolmente il comportamento del proxy, la compatibilità del browser/client e i registri del proxy.

In molte installazioni, la modalità DPI è il punto di partenza migliore. Tuttavia, se sono necessari tempi di quota tramite Quota, una regola puramente DPI non è sufficiente. In tal caso, la modalità Web Proxy deve essere pianificata e testata consapevolmente. Questa decisione dovrebbe essere presa prima del rollout, poiché un cambio successivo può generare altri modelli di errore, registri ed esperienze utente.

Il Web Proxy filtra nella regola firewall solo le porte classiche 80 e 443. Il DPI Engine può ispezionare traffico HTTP e SSL/TLS anche su altre porte, purché la regola e le regole SSL/TLS Inspection siano coerenti. Nei design con proxy diretto deve inoltre essere chiaro se i client usano esplicitamente il proxy o se il normale traffico client trasparente passa attraverso la regola. Altrimenti si rischia di testare il percorso sbagliato.

Ispezione TLS

Se si desidera verificare in modo affidabile download, scansione malware, determinate categorie web o controlli dei contenuti, è necessario pianificare l’ispezione TLS. Per questo è necessario un certificato CA attendibile sui client, regole TLS appropriate, eccezioni e un pilota pulito.

Il rollout è descritto in Distribuire gradualmente l’ispezione TLS su Sophos Firewall. Per distribuire e convalidare il certificato CA, è adatto Installare il certificato CA di Sophos Firewall per la scansione HTTPS.

QUIC e HTTP/3

I browser moderni utilizzano spesso QUIC o HTTP/3 su UDP 443. Questo può disturbare le aspettative di filtraggio web, ispezione TLS e scansione, se si desidera effettivamente esaminare il traffico HTTPS classico su TCP.

In molte aziende, è utile bloccare QUIC nelle regole Internet client, in modo che i browser tornino a HTTPS su TCP. I dettagli sono disponibili in Bloccare correttamente QUIC e HTTP/3 su Sophos Firewall.

SafeSearch, YouTube e restrizioni tenant

Sophos Firewall può impostare controlli di ricerca e cloud aggiuntivi nelle politiche web.

Opzioni tipiche:

• Enforce SafeSearch per Google, Yahoo e Bing.
• Enforce YouTube restrictions per contenuti YouTube limitati.
• Restrict login domains for Google Apps per domini Google consentiti.
• Apply Microsoft Entra ID tenant restrictions per il controllo dei tenant cloud Microsoft.

Queste funzioni sono utili, ma non magiche. Con HTTPS, l’efficacia dipende in parte dalla scansione HTTPS o dall’ispezione TLS. Inoltre, non sostituiscono la governance delle identità e delle app cloud in Microsoft 365 o Google Workspace. Per ambienti produttivi, si dovrebbe verificare l’effetto con utenti di test reali e i browser interessati.

Per Bing e Yahoo, SafeSearch può essere applicato su connessioni HTTPS solo se HTTPS scanning è attivo nella regola firewall interessata. Le restrizioni di accesso Google Apps valgono solo per domini ospitati da Google. Le Microsoft Entra ID Tenant Restrictions richiedono valori tenant puliti e dovrebbero essere testate con accessi reali al cloud Microsoft, non solo con un URL di esempio.

Quota e pagine di avviso

Le politiche web possono non solo bloccare o consentire. Con azioni di avviso o quota, è possibile informare consapevolmente gli utenti o consentire l’accesso limitato nel tempo.

Esempi significativi:

• Gli utenti possono confermare consapevolmente un avviso per determinate aree grigie.
• Lo streaming o lo shopping è consentito solo per un tempo limitato.
• Gli ambienti scolastici o di laboratorio consentono determinate categorie solo durante orari definiti.

Importante: la quota di politica non è supportata in modalità DPI. Se sono necessari tempi di quota, deve essere utilizzata la modalità Web Proxy. Questo dovrebbe essere deciso presto, poiché DPI e Web Proxy hanno caratteristiche e limiti diversi.

La allowed time quota viene impostata a livello di politica web e vale per tutte le regole di questa policy che usano un’azione Quota. Se due categorie richiedono quote temporali diverse, politiche web separate sono più pulite di una singola policy con aspettative di quota miste. Le quote vengono reimpostate localmente a mezzanotte e non possono essere impostate a zero.

I Policy Overrides sono uno strumento diverso dalle quote. Consentono a utenti autorizzati nel User Portal di creare accesso temporaneo a siti web normalmente bloccati. Può essere utile per scuole o scenari di supporto, ma richiede confini chiari: categorie non sovrascrivibili, persone autorizzate, finestre temporali e revisione degli override.

Web Exceptions ed eccezioni TLS

Le Web Exceptions sono potenti e quindi pericolose se usate come riparazione rapida. Un’eccezione in Web > Exceptions può saltare controlli di protezione per il traffico corrispondente, indipendentemente da quale politica web sia attiva. A seconda della selezione vengono saltati HTTPS decryption, HTTPS certificate validation, Malware and content scanning, Zero-day protection o Policy checks.

Per ambienti DPI vale una limitazione importante: le Web Exceptions si applicano solo se è impostata una politica web, Malware and content scanning è attivo o ATP è attivo. Le SSL/TLS Exclusion Rules sono invece il punto corretto quando si vuole solo evitare di decrittare determinate connessioni TLS. La differenza operativa è importante:

• SSL/TLS Exclusion Rule: esclude in modo mirato connessioni TLS dalla decrittazione, tipicamente per Certificate Pinning o incompatibilità.
• Web Exception: può saltare controlli di politica web, scansione malware, analisi Zero-Day o validazione dei certificati.
• URL Group in Web Policy: controlla Allow, Warn, Block o Quota nella logica normale della policy.

Per le eccezioni si dovrebbero evitare domini radice e pattern URL regex troppo ampi. Un pattern come example.com può comparire anche in percorsi o parametri di query di altri domini. Meglio usare hostname concreti, gruppi di URL adeguati e uno scope chiaro per sorgente, destinazione, categoria o gruppo utenti.

Le eccezioni combinano i diversi criteri con AND. All’interno dello stesso tipo di criterio, ad esempio più URL Patterns, vale invece OR. È pratico ma soggetto a errori: un’eccezione con URL Pattern e Source IP si applica solo se entrambi corrispondono. Un’eccezione con molti URL Patterns può invece avere un effetto molto più ampio del previsto.

Prestare particolare attenzione a Policy checks. Se una Web Exception salta i Policy checks, può indebolire indirettamente altre decisioni di regola. In combinazione con Synchronized Security Heartbeat, una tale eccezione può far sì che le richieste web non vengano bloccate come previsto, anche se nella regola firewall sono impostati controlli Heartbeat.

Testare la protezione web

Dopo il salvataggio, non si dovrebbe solo verificare se la politica esiste. È fondamentale verificare se si applica al traffico reale.

1. Utilizzare il Policy Tester

Sotto Web > Policies è disponibile il Policy tester. Con esso, è possibile verificare quale decisione politica è prevista per utente, URL e contesto.

Il Policy Tester è un buon pre-controllo, ma non sostituisce un flusso di pacchetti reale. Una regola firewall, NAT, ispezione TLS, QUIC o routing può comunque impedire che la politica prevista si applichi al traffico reale.

2. Test reale con client pilota

Con un client pilota, verificare:

• sito aziendale consentito
• categoria bloccata
• categoria di avviso
• gruppo di URL consentito
• gruppo di URL bloccato
• sito HTTPS con e senza ispezione TLS
• download di un tipo di file di test innocuo
• comportamento con QUIC attivo o bloccato

3. Verificare il Log Viewer

Nel Log Viewer dovrebbe essere visibile:

• quale regola firewall è stata colpita
• quale utente è stato riconosciuto, se rilevante
• quale categoria web o gruppo di URL è stato coinvolto
• se HTTPS, ispezione TLS o scansione malware sono stati coinvolti
• se l’azione ha consentito, avvisato o bloccato
• se si è applicata una Web Exception o TLS Exclusion
• se un download è stato trattato diversamente per dimensione, errore di scansione malware o analisi Zero-Day

Per Syslog o SIEM, URL e azione non bastano. Per un’analisi affidabile servono anche Firewall Rule ID, utente, categoria, politica web, metodo HTTP, stato, risultato della scansione, indicazione di eccezione e relazione SSL/TLS. Se questi campi mancano nel SIEM o sono normalizzati male, la protezione web appare rapidamente meno chiara nei report di quanto sia realmente sul firewall.

Per un troubleshooting più approfondito, sono rilevanti anche i file di log. L’assegnazione è disponibile in Sophos Firewall Troubleshooting: Servizi e Log.

Avvisi istantanei e reportistica

Se determinate categorie non solo devono essere bloccate, ma segnalate attivamente, gli avvisi istantanei possono essere utili. Questo è particolarmente utile nelle scuole, in ambienti strettamente regolamentati o in aree con una chiara politica di utilizzo di Internet.

I tre modi di valutazione rispondono a domande diverse:

• Email rapida per poche categorie web sensibili: Avvisi istantanei.
• Report ricorrenti, tendenze e valutazioni per utente o categoria: Central Firewall Reporting.
• Conservazione a lungo termine, correlazione con altri sistemi o processi SOC: Syslog o SIEM.

Prima degli avvisi istantanei, dovrebbe essere chiaro chi riceve la notifica, quali categorie richiedono davvero una reazione, come vengono gestiti i falsi positivi e quando viene verificata la selezione delle categorie. Una lista di avvisi ampia senza proprietario genera rapidamente rumore email, ma non una maggiore sicurezza.

Per l’attivazione tecnica e il triage, consultare Utilizzare le categorie web e gli avvisi istantanei di Sophos Firewall. Per valutazioni a lungo termine, dovrebbero essere esaminati Central Firewall Reporting o Inviare Syslog a SIEM.

Gestire modifiche ed eccezioni in produzione

La protezione web cambia continuamente in produzione. Nuovi servizi SaaS vengono aggiunti, singoli domini vengono categorizzati erroneamente, i dipartimenti necessitano di accesso temporaneo e il comportamento del browser cambia. Senza un flusso chiaro, si creano rapidamente eccezioni ampie che nessuno può più spiegare in seguito.

Per ogni modifica, si dovrebbe almeno annotare:

• Chi necessita dell’accesso? previene eccezioni globali per pochi utenti.
• Quale dominio, categoria o tipo di file è coinvolto? separa chiaramente gruppo di URL, categoria web e tipo di file.
• È un’eccezione temporanea o permanente? impone una revisione invece di autorizzazioni ombra permanenti.
• Quale regola firewall e politica web sono coinvolte? previene modifiche alla regola sbagliata.
• Come viene testato? rende il successo dimostrabile nel Log Viewer.

Si è dimostrato efficace un piccolo flusso di cambiamento:

1. Registrare la richiesta con utente, URL, orario, motivo aziendale e screenshot o messaggio di errore.
2. Verificare nel Log Viewer quale regola firewall, politica web, categoria e azione sono state applicate.
3. Decidere se la categoria è fondamentalmente errata, se solo un singolo dominio deve essere autorizzato o se la richiesta viene respinta.
4. Se è necessaria un’eccezione, lavorare il più strettamente possibile: singolo gruppo di URL invece di intera categoria, singolo gruppo di utenti invece di intera LAN.
5. Verificare la modifica in una regola di test o gruppo pilota.
6. Dopo il salvataggio, eseguire un test reale e documentare Log Viewer, categoria, ID regola e contesto utente.
7. Impostare una data di revisione, specialmente per eccezioni aziendali temporanee.

Le eccezioni temporanee dovrebbero essere chiaramente denominate, ad esempio TMP_ALLOW_vendor-portal_until_2026-07-31. Anche le eccezioni aziendali permanenti necessitano di un proprietario. Se nessuno è responsabile di un’eccezione, non dovrebbe rimanere permanentemente nella politica.

Se molti singoli domini per lo stesso servizio emergono, spesso non è la politica web il problema, ma l’architettura del servizio. In tal caso, si dovrebbe verificare se una regola firewall separata, una politica web separata, un gruppo di URL ben gestito o un altro punto di controllo sono più adatti. Per liste IOC o di blocco dinamiche, le eccezioni delle politiche web sono spesso il luogo sbagliato; in tal caso, sono più adatti Sophos Firewall Threat Feeds.

Rollback e autorizzazione di emergenza

Una modifica alla politica web può influenzare immediatamente il lavoro produttivo. Pertanto, prima di apportare modifiche significative, si dovrebbe stabilire come ripristinare lo stato precedente.

Opzioni pratiche di rollback:

• duplicare o documentare la politica web interessata prima della modifica
• testare la modifica prima in una regola pilota o in un piccolo gruppo di utenti
• non eliminare immediatamente la vecchia regola firewall o la vecchia politica web
• definire una finestra temporale, utenti di test e criterio di fallback
• dopo il salvataggio, verificare Log Viewer, ID regola e decisione di categoria

Per blocchi acuti, non si dovrebbe inserire automaticamente una regola di consentito ampia in alto. Meglio è un’eccezione stretta e temporanea con un chiaro gruppo di URL, gruppo di utenti e data di revisione. Se la pressione è alta, un’eccezione temporanea può stabilizzare l’operazione, ma deve essere rivalutata successivamente.

Errori tipici

La politica web non si applica

Spesso la politica non è attivata nella regola firewall corretta, la regola non viene colpita, una regola più in alto consente il traffico o il contesto utente non è corretto. Prima verificare Log Viewer e ID regola.

HTTPS non viene bloccato come previsto

Senza ispezione TLS, il firewall vede meno dettagli. A seconda della destinazione, una decisione di dominio o categoria può funzionare, mentre la verifica dei contenuti, i tipi di file o determinate funzioni di ricerca rimangono limitate.

Se la connessione non viene decrittata, il firewall può comunque usare informazioni SNI o di dominio per decisioni di policy. Pagine di blocco, pagine di avviso, tipi di file, Content Filters, scansione malware e analisi Zero-Day richiedono però maggiore visibilità. Nel Log Viewer si dovrebbe quindi controllare non solo l’azione della politica web, ma anche lo stato SSL/TLS Inspection.

QUIC aggira l’aspettativa

Se i browser utilizzano UDP 443, il traffico può essere elaborato diversamente rispetto all’HTTPS classico su TCP. Nelle regole client, si dovrebbe decidere consapevolmente se bloccare QUIC.

La regola di consentito è troppo in alto

Una regola di consentito ampia all’inizio della politica web può annullare le regole di blocco successive. L’ordine delle regole all’interno della politica web è importante quanto l’ordine delle regole nella lista delle regole firewall.

Troppe eccezioni

Le eccezioni risolvono rapidamente un problema singolo, ma possono ridurre l’efficacia della protezione. Ogni eccezione necessita di uno scopo, un proprietario e una data di revisione. Se emergono molte eccezioni, spesso la struttura della politica è errata o un’applicazione aziendale necessita di una regola propria.

Sono particolarmente rischiose le Web Exceptions che saltano Policy checks o Malware and content scanning. Se disturba solo HTTPS decryption, una SSL/TLS Exclusion è di solito più stretta e più comprensibile.

La reportistica non mostra nulla

In tal caso, si devono verificare registrazione, reportistica, regola firewall, selezione della politica o inoltro dei log. Una politica senza registrazione è difficile da valutare in produzione.

Lista di controllo operativa

• Stato della licenza di protezione web verificato.
• Traffico client, server, ospiti e VPN valutato separatamente.
• Politica web creata con nome significativo.
• Categorie critiche e gruppi di URL pianificati consapevolmente.
• Ordine delle regole all’interno della politica web verificato.
• Politica web attivata nella regola firewall appropriata.
• Log firewall traffic, logging della politica web e Reporting attivi.
• Regole della politica web attivate e nell’ordine corretto.
• Ispezione TLS e certificato CA verificati per il gruppo pilota.
• Strategia QUIC definita.
• Web Exceptions e TLS Exclusions documentate separatamente.
• Tester di politica e test reali eseguiti.
• Log Viewer e reportistica controllati.
• Processo di modifica per eccezioni di politica web definito.
• Eccezioni temporanee con data di scadenza impostata.
• Eccezioni documentate con proprietario e data di revisione.

FAQ