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.
• Comprendere Single o Dual Engine, gli errori di scansione, i limiti di dimensione e un vero test malware: Configurare e testare la scansione malware di Sophos Firewall.
• 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.
• Search engine enforcement: SafeSearch e restrizioni YouTube.
• Advanced settings: restrizioni dei domini di accesso Google Apps e Microsoft Entra ID Tenant Restrictions.
• 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.

I criteri utente della regola firewall corrispondente hanno precedenza su Users nella politica web: la politica può restringere tale ambito, ma non includere utenti esclusi dalla regola.

Percorso minimo per una politica web efficace

Creare la politica in Web > Policies con almeno una decisione Allow/Block mirata. Modificare poi una regola reale in Rules and policies > Firewall rules con Action: Accept e valori corretti per Source Zone, Source Network, Destination Zone, Destination Network e Services; attivare Log firewall traffic e assegnare la politica in Web filtering. Verificare il NAT esistente senza crearne uno nuovo solo per la politica.

Prima della modifica, registrare la Rule ID e i risultati di un URL volutamente consentito e di uno volutamente bloccato; dopo la modifica, ripetere le stesse richieste da un client con il contesto reale di origine e utente. La modifica va accettata solo se Log Viewer mostra la Rule ID attesa, la nuova politica e le decisioni Allow e Block previste.

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

La categoria highly objectionable criminal activity è sempre bloccata. Né le regole della politica web né le esclusioni possono consentirla; inoltre, SFOS nasconde il dominio interessato nei log e nei report.

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.

Creare e usare in sicurezza gli URL Groups spiega come interagiscono valori di dominio validi, logica OR, uso nella Web Policy ed esclusioni TLS.

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:

Un’autorizzazione aziendale collocata sopra regole di blocco critiche vale solo per il suo ambito strettamente definito. Se una categoria di rischio deve restare bloccata senza eccezioni, la relativa regola di blocco deve trovarsi sopra tutte le regole Allow corrispondenti. Verificare l’ordine con una destinazione aziendale consentita e una destinazione bloccata all’interno dell’ambito dell’eccezione; l’autorizzazione di un dominio non deve consentire involontariamente qualsiasi tipo di file o contenuto di quella destinazione.

• Regole di avviso o quota per aree grigie.
• 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 o File types.
3. Per i contenuti scegliere la scheda separata Content filters, selezionare il filtro, attivare and with content e lasciare HTTPS su Use action.
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 applicarsi solo negli orari definiti da una pianificazione (Schedule).
7. Verificare la posizione della regola all’interno della policy.
8. Attivare lo stato della regola.
9. Salvare la policy.

In Users > Add new item, deselezionare Anybody se la regola deve riguardare solo utenti o gruppi specifici. In Activities > Add new item, deselezionare All web traffic prima di selezionare le singole Activities. Confermare ogni selezione con Apply selected items. Altrimenti, la regola resta inutilmente ampia nonostante l’aggiunta di singoli oggetti. Le azioni HTTP si chiamano Allow HTTP, Warn HTTP, Block HTTP e Quota HTTP; Use action applica la stessa decisione a HTTPS. Per i Content filters, questo collegamento è fisso e non può essere sostituito con un’azione HTTPS diversa.

Importare correttamente gli elenchi dei filtri di contenuto

I Content filters vengono gestiti in Web > Content filters e poi selezionati in Activities nella regola della politica web. Per elenchi di termini più lunghi, Sophos supporta un semplice file .txt. Il file può contenere al massimo 2,000 righe e ogni voce può avere una lunghezza massima di 80 caratteri, inclusi spazi e segni di punteggiatura.

Il file deve contenere un solo termine per riga e ogni riga viene valutata come exact match. Non deve includere intestazioni, commenti, metadati o colonne aggiuntive e, in presenza di caratteri non ASCII, dovrebbe essere salvato in UTF-8.

Procedura sicura:

1. Ripulire i termini in un editor di testo e inserire esattamente una voce per riga.
2. Salvare il file come .txt con codifica UTF-8.
3. Importare l’elenco in Web > Content filters e assegnargli un nome descrittivo.
4. In Activities, aprire Content filters, scegliere il filtro, attivare and with content e mantenere Use action per HTTPS.
5. Con un client pilota, testare un termine consentito e uno che corrisponda volutamente, quindi verificare l’azione in Log Viewer.

Se l’importazione viene rifiutata o singoli termini non vengono applicati, controllare prima il numero di righe, la lunghezza dei caratteri, la codifica e gli eventuali caratteri aggiuntivi invisibili. Una regola Allow ampia sopra la regola Content filter non deve aggirare l’elenco.

Per l’importazione, selezionare Add content filter, inserire il nome, scegliere un file come blocked.txt tramite Choose file e fare clic su Apply. Nella regola della politica web, controllare poi esplicitamente Block HTTP e Use action per HTTPS, confermare il filtro con Apply selected items, attivare Status e salvare la politica. La sola importazione non attiva alcun blocco. Per il pilota è preferibile una politica dedicata e assegnata rispetto a una modifica non controllata della Default Policy condivisa.

Creare tipi di file web personalizzati

Sophos Firewall identifica i File types in base all’estensione del file o all’header MIME. I tipi integrati non sono modificabili. Un tipo personalizzato viene creato in Web > File types > Add partendo da un modello adatto e aggiungendo le estensioni necessarie senza punto iniziale oppure gli header MIME. Lo stesso oggetto può poi essere utilizzato nelle policy di protezione web ed email.

Nella finestra Add occorre specificare un nome. Template è facoltativo e inserisce le estensioni e gli header MIME più comuni di una categoria; per il tipo personalizzato è possibile aggiungere altri valori. Salvare quindi con Save. Le estensioni non devono iniziare con un punto: pdf è corretto, .pdf no. I tipi integrati fungono da modelli e non sono modificabili; per apportare variazioni occorre creare un tipo personalizzato.

SFOS include le categorie predefinite All executable files, Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files e Web files. La vista dettagliata in Web > File types è il riferimento operativo per le estensioni e gli header MIME attualmente configurati. Ad esempio, Compressed files comprende voci quali 7z, gz, rar, tar.gz e zip, mentre Document files comprende voci quali docx, xlsx, pptx, odt, rtf e pdf. Prima di consentire una categoria, aprire quindi il tipo integrato specifico nella propria versione di SFOS e confrontarlo con il caso d’uso reale, senza basarsi solo sul nome.

Il nuovo tipo di file non produce alcun effetto da solo. Deve essere selezionato in Activities > File types nella regola della politica web pertinente. Si controllano quindi l’azione, lo stato e l’ordine della regola, oltre all’assegnazione della politica web alla regola firewall che gestisce realmente il traffico.

La verifica usa un download rappresentativo e un file volutamente simile che non deve corrispondere. Nel Log Viewer si controllano la politica web e l’azione. Una corrispondenza basata sull’estensione o sull’header MIME è una classificazione di policy, non una prova di malware né di un’analisi Zero-Day completata. Per HTTPS, la visibilità necessaria dipende anche dal percorso TLS Inspection. Se il tipo non viene riconosciuto, confrontare innanzitutto lo stato e l’ordine della regola, il File Type effettivamente selezionato, la risposta Content-Type del server, l’estensione visibile e lo stato di TLS Inspection. Un tipo MIME errato o generico fornito dal server può produrre un risultato diverso da quello suggerito dal nome del file.

Riferimento dei tipi di file integrati

Il riferimento seguente associa le estensioni e gli header MIME documentati alle categorie integrate. Descrive una classificazione, non un file consentito o sicuro. Prima di apportare modifiche, confrontare i valori con quelli della propria installazione. All executable files comprende anche file eseguibili per Mac/Linux tramite header MIME aggiuntivi; Executable files è orientato a Windows. Dynamic files generano contenuti web dinamici, mentre Encoded files comprendono, tra l’altro, contenuti crittografati o codificati in formato binario. Le categorie possono sovrapporsi: ad esempio, mdf compare nei database e nelle Disk Images, tar nei documenti e tar.gz nei file compressi. In particolare, application/octet-stream in Backup files è un valore MIME generico, non una prova certa che si tratti di un file di backup.

All executable files

• Estensioni: exe, cmd, bat, com.
• Header MIME: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/x-dosexec, application/x-mach-binary, application/x-executable.

Audio files

• Estensioni: gsm, sd2, qcp, kar, smf, midi, mid, ulw, snd, aifc, aif, aiff, m3url, m3u, wav, rm, ram, mp3, wmv.
• Header MIME: audio/x-gsm, audio/vnd.qcelp, audio/x-midi, application/x-midi, audio/midi, audio/x-mid, x-music/x-midi, audio/basic, audio/x-adpcm, audio/aiff, audio/x-aiff, audio/x-mpequrl, audio/wav, audio/x-wav, application/vnd.rn-realmedia, audio/x-au, audio/x-pn-realaudio, audio/mpeg3, audio/x-mpeg-3, audio/x-ms-wmv, audio/ac3, audio/x-ape, audio/flac, audio/mpeg, audio/mp4, audio/ogg.

Backup files

• Estensioni: asd, bak, bkp, bup, dba, dbk, fbw, gho, nba, old, ori, sqb, tlg, tmp.
• Header MIME: application/octet-stream.

Compressed files

• Estensioni: 7z, alz, deb, gz, pkg, pup, rar, rpm, sea, sfx, sit, sitx, tar.gz, tgz, war, zip, zipx.
• Header MIME: application/x-7z-compressed, application/x-alz, application/x-deb, application/x-gzip, application/x-newton-compatible-pkg, application/x-rar-compressed, application/sea, application/x-sea, application/x-sit, application/x-stuffit, application/gnutar, application/x-compressed, application/x-zip-compressed, application/zip, multipart/x-zip.

Configuration files

• Estensioni: cfg, clg, dbb, ini, keychain, prf, prx, psf, rdf, reg, thmx, vmx, wfc.
• Header MIME: application/pics-rules, application/vnd.ms-officetheme.

Database files

• Estensioni: accdb, db, mdsn, mdb, mdf, pdb, sql, sqlite.
• Header MIME: application/msaccess, application/x-msaccess, application/vnd.msaccess, application/vnd.ms-access, application/mdb, application/x-mdb, chemical/x-pdb.

Developer files

• Estensioni: rb, src, tcl, trx, v, vbproj, vcproj, vtm, xcodeproj, asc, cbl, cp, cpp, csproj, dev, fs, fsproj, fsx, ftl, gem, hpp, ise, ism, java, ocx, pas, pod, r.
• Header MIME: text/pascal, application/x-bsh, application/x-sh, text/x-script.sh, application/x-wais-source, application/x-tcl, text/x-script.tcl, application/x-shar.

Disk image files

• Estensioni: dmg, iso, mdf, nrg, nri, pvm, toast, vcd, vmdk.
• Header MIME: application/x-cdlink.

Document files

• Estensioni: doc, docx, wbk, xls, xlsx, ppt, pptx, oft, pub, msg, one, xsf, xsn, grv, mpp, mpt, acl, pip, bld, blg, bvp, cdd, cdf, contact, csv, dif, dmsp, efx, epub, epw, exif, exp, fdb, fxp, gbr, gpi, hdf, id2, lib, mat, mcd, menc, ndx, not, notebook, out, ovf, pdx, pfc, pps, ppsx, pptm, prj, qbw, sdf, svf, tar, tsv, vdb, odt, opml, pages, rtf, sig, tex, wpd, wps, pdf.
• Header MIME: application/msword, application/vnd.openxmlformats-officedocument.wordprocessingml.document, application/excel, application/vnd.ms-excel, application/x-excel, application/x-msexcel, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/mspowerpoint, application/powerpoint, application/vnd.ms-powerpoint, application/x-mspowerpoint, application/vnd.openxmlformats-officedocument.presentationml.presentation, application/x-mspublisher, application/onenote, application/vnd.ms-project, application/x-project, application/cdf, application/x-cdf, application/x-netcdf, video/x-dv, application/x-hdf, application/mcad, application/x-mathcad, application/vnd.openxmlformats-officedocument.presentationml.slideshow, application/vnd.ms-powerpoint.presentation.macroEnabled.12, image/vnd.dwg, image/x-dwg, application/x-tar, text/x-vcard, application/rtf, application/x-rtf, text/richtext, application/x-tex, application/wordperfect, application/x-wpwin, application/vnd.ms-works, application/pdf, application/vnd.oasis.opendocument.graphics, application/vnd.oasis.opendocument.presentation, application/vnd.oasis.opendocument.formula, application/vnd.oasis.opendocument.text, application/vnd.oasis.opendocument.spreadsheet, application/vnd.ms-excel.addin.macroEnabled.12, application/vnd.ms-excel.sheet.binary.macroEnabled.12, application/vnd.ms-excel.sheet.macroEnabled.12, application/vnd.ms-excel.template.macroEnabled.12, application/vnd.ms-powerpoint.addin.macroEnabled.12, application/vnd.ms-powerpoint.slideshow.macroEnabled.12, application/vnd.ms-powerpoint.template.macroEnabled.12, application/vnd.ms-word.document.macroEnabled.12, application/vnd.ms-word.template.macroEnabled.12, application/vnd.openxmlformats-officedocument.presentationml.template, application/vnd.openxmlformats-officedocument.spreadsheetml.template, application/vnd.openxmlformats-officedocument.wordprocessingml.template.

Dynamic files

• Estensioni: jsp, asp, php, cgi, shtml.
• Header MIME: text/x-script.perl, text/asp.

Encoded files

• Estensioni: bin, enc, hex, hqx, mim, mime, uue.
• Header MIME: application/mac-binary, application/macbinary, application/x-binary, application/x-macbinary, application/binhex, application/binhex4, application/mac-binhex, application/mac-binhex40, application/x-binhex40, application/x-mac-binhex40, message/rfc822, www/mime, text/x-uuencode.

Executable files

• Estensioni: exe, cmd, bat, com.
• Header MIME: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/x-dosexec.

Image files

• Estensioni: bmp, gif, jpeg, jpg, pcx, png.
• Header MIME: image/bmp, image/x-windows-bmp, image/gif, image/pjpeg, image/jpeg, image/x-pcx, image/png, image/jp2, image/vnd.adobe.photoshop, image/tiff.

Page layout files

• Estensioni: idml, indd, inx, isd, mdi, pmd, ptx, pub, qxb, qxd, qxp, rels, xps.
• Header MIME: application/x-mspublisher, application/vnd.ms-xpsdocument.

Plugin files

• Estensioni: 8bi, arx, plugin, vst, xll.
• Header MIME: application/x-visio.

System files

• Estensioni: bashrc, cab, cpl, cur, dll, dmp, drv, hlp, key, lnk, msp, prf, profile, scf, scr, sys.
• Header MIME: application/vnd.ms-cab-compressed, application/x-msdownload, application/hlp, application/x-helpfile, application/x-winhelp.

Video files

• Estensioni: dat, mov, avi, qt, smi, sml, smil, flc, fli, vfw, mpeg, mpg, m15, m1u, m1a, m75, mls, mp2, mpm, rm, wmv, flv, swf.
• Header MIME: application/x-troff-msvideo, video/avi, video/msvideo, video/x-msvideo, video/quicktime, application/smil, application/x-simile, Video/flc, video/fli, video/x-fli, video/mpeg, video/x-mpeg, video/x-mpeq2a, application/vnd.rn-realmedia, video/flv, application/x-shockwave-flash, video/x-flv, video/x-ms-asf, video/3gpp, video/mp4, video/mj2.

Web files

• Estensioni: alx, asax, asmx, aspx, atom, att, axd, chm, dwt.
• Header MIME: application/atom+xml.

Raggruppare correttamente le User Activities

In Web > User activities > Add, una User activity raggruppa Web Categories, File types e URL Groups in un’attività riutilizzabile. Questi elementi vengono valutati con OR; è sufficiente una sola corrispondenza. Il nome non indica quindi un utente connesso, ma una raccolta di criteri web.

La User Activity viene poi selezionata in Activities nella regola della politica web. È utile quando la stessa combinazione viene impiegata in più policy. Per la verifica si testa almeno una corrispondenza per ogni tipo di oggetto incluso e un caso simile che non deve corrispondere.

Nella finestra di dialogo, impostare un nome significativo come RISK_WEB_CONTENT, selezionare le categorie, i tipi di file o gli URL Groups necessari tramite Add new item e salvare con Save. Show: All consente, se necessario, di limitare i tipi di oggetto visualizzati. Ad esempio, un’attività può raggruppare la categoria Spyware/Malware e un elenco personalizzato di domini di test bloccati: basta che uno di questi criteri corrisponda per attivare l’azione di blocco della regola della politica. Per i test, usare destinazioni innocue sotto il proprio controllo, senza aprire un vero sito malware.

Controllare l’ordine delle regole e le policy migrate

Le regole della politica web vengono valutate dall’alto verso il basso. Se, per esempio, una regola Allow per il tipo di file .mdb si trova sopra una regola di blocco di una categoria, i download .mdb da quella categoria restano consentiti. In modalità DPI, la connessione iniziale alla categoria può essere consentita finché non viene identificato il tipo di file; se il file non corrisponde, il firewall interrompe poi la connessione senza mostrare una pagina di blocco. Se la categoria deve essere sempre bloccata, la relativa regola va collocata sopra la regola Allow del tipo di file.

Le vecchie policy migrate sono inoltre soggette a un limite rigido di 128 regole per policy. Se l’origine ne contiene di più, SFOS usa solo le prime 128. Le regole adiacenti per User Activities, Categories, URL Groups, File types e Dynamic Categories vanno quindi consolidate consapevolmente in Activities combinate prima o dopo la migrazione. Il conteggio, l’ordine e test reali di Allow e Block fanno parte della verifica della migrazione.

Le finestre ricorrenti vengono create come pianificazione separata. La procedura e la differenza rispetto a una regola firewall controllata nel tempo sono descritte in Configurare pianificazioni per regole e policy in Sophos Firewall.

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.

Unire solo regole adiacenti con la stessa assegnazione di utenti, le stesse azioni HTTP/HTTPS e le stesse condizioni temporali. Le differenze relative a Content filters, Constraints o all’ordine non devono andare perse. Prima di unire le regole, salvare o documentare la vecchia politica e registrare casi rappresentativi di corrispondenza e mancata corrispondenza per ogni Activity. Dopo l’unione, verificare nuovamente queste decisioni; un numero inferiore di regole, da solo, non dimostra un’efficacia di protezione equivalente.

Configurare in modo mirato le Advanced settings

Enable logging and reporting include la politica nei log e nei report; resta inoltre necessario attivare Log firewall traffic nella regola firewall corrispondente. Prevent downloading of large files blocca i download che superano la dimensione impostata. Scegliere la soglia in base ai download aziendali effettivamente necessari e verificarla con file innocui di dimensioni inferiori e superiori al valore; questo blocco dei download non equivale a un limite di dimensione per la scansione malware.

Add X-Forwarded-For header to outgoing HTTP requests inoltra alla destinazione l’indirizzo IP della richiesta HTTP originale. Questa opzione non è necessaria per il filtraggio web. Attivarla solo in presenza di un’esigenza motivata, perché il server di destinazione riceve così informazioni aggiuntive sul client; valutare prima la trasmissione di indirizzi interni e i requisiti di protezione dei dati. Per il pilota, documentare i valori precedenti e, in caso di effetti indesiderati, annullare esattamente queste modifiche.

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.
• Sul percorso trasparente della regola firewall, Use web proxy instead of DPI engine è attivo per SafeSearch, YouTube Restrictions e restrizioni di accesso Google Apps; negli altri casi e con Direct Proxy, la modalità viene scelta in base alle funzioni necessarie.
• 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.

In una regola firewall trasparente, Transparent Web Proxy elabora soltanto le porte 80 e 443; sulle altre porte il DPI Engine può ispezionare il traffico HTTP e SSL/TLS se la regola firewall e le regole SSL/TLS Inspection sono adeguate. Direct Proxy è invece un percorso esplicito separato, scelto dal client, e non richiede necessariamente Use web proxy instead of DPI engine. Durante ogni test va quindi annotato se il client usa il percorso trasparente o la propria configurazione proxy esplicita.

La scelta completa delle funzioni, la migrazione pilota e i test specifici per modalità sono descritti in Confrontare correttamente DPI Engine e Web Proxy.

Configurare Direct Web Proxy con un file PAC spiega come integrare listener, file PAC, Device Access e una regola proxy funzionante.

I client solo IPv6 che accedono a destinazioni web solo IPv4 utilizzano un percorso distinto con due regole. NAT64 con Direct Web Proxy separa la Web Policy nella regola IPv6 da Application Control e IPS nell’egress IPv4.

Se Sophos Firewall deve inoltrare le proprie Web Requests a un parent proxy, configurare un upstream proxy in WAN o LAN/DMZ illustra il percorso corretto di regole e NAT per ogni topologia.

Quando più utenti RDS condividono lo stesso IP del server, Per-Connection AD SSO per host multiutente può distinguere le singole connessioni proxy HTTP e HTTPS. Il metodo non si applica al traffico non proxy e deve quindi essere consapevolmente distinto da SATC.

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

SafeSearch e YouTube si trovano in Search engine enforcement; Google Apps ed Entra in Advanced settings.

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.

Il riferimento dell’API XML di SFOS 22/23 descrive EnforceSafeSearch come applicabile solo quando le categorie Adult Content, Nudity e Porn vengono negate nella Web Policy. Verificare queste decisioni nella policy effettivamente assegnata al traffico; attivare l’opzione e soddisfare i prerequisiti di proxy e HTTPS scanning non basta a confermare questa condizione documentata. Questo requisito riguarda l’API; verificare separatamente il comportamento dell’interfaccia e della build installata. Se la guida della build installata differisce, chiarire la differenza prima di affidarsi a SafeSearch.

Sul percorso trasparente della regola firewall, SafeSearch, YouTube Restrictions e le restrizioni Google Apps richiedono Use web proxy instead of DPI engine; un Direct Proxy esplicito può offrire queste funzioni proxy senza tale opzione della regola firewall. Per Bing e Yahoo su HTTPS, SafeSearch richiede inoltre HTTPS scanning, mentre le restrizioni di accesso Google Apps valgono solo per i domini ospitati da Google. Le Microsoft Entra ID Tenant Restrictions sono separate, richiedono valori tenant corretti e devono essere provate con accessi reali al cloud Microsoft, non soltanto con un URL di esempio. Questi controlli non sostituiscono la governance delle identità e delle applicazioni cloud in Microsoft 365 o Google Workspace.

In Apply Microsoft Entra ID tenant restrictions, Restrict-Access-To-Tenants contiene i tenant consentiti come elenco di nomi di dominio o ID di dominio separati da virgole, per un massimo complessivo di 256 caratteri. Restrict-Access-Context contiene l’ID di dominio del tenant che definisce la restrizione, per un massimo di 50 caratteri. Ricavare questi valori dalla gestione del proprio tenant, non da una configurazione di esempio di terzi. Salvare prima i valori esistenti; successivamente, verificare nel pilota un accesso a un tenant consentito e uno a un tenant non consentito e, in caso di errori, ripristinare allo stato precedente solo i valori modificati.

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.

Policy Quota non vale per Content filters o Dynamic Categories. Le modifiche non hanno effetto se la policy non è valida, non resta tempo o una sessione Quota è già attiva. DPI non supporta Policy Quota.

Questa Policy Quota si applica alle categorie web e non è la Surfing Quota basata sull’utente. La creazione, l’assegnazione e il controllo del consumo di Surfing Quota e Network Traffic Quota seguono una procedura separata.

Quando si accede a una destinazione con un’azione Quota, viene prima visualizzata la pagina della quota. L’utente sceglie una durata entro il contingente disponibile e seleziona Proceed, oppure rinuncia all’accesso con Return to previous page. Al termine del periodo scelto, la pagina ricompare; quando il contingente è esaurito, non viene più offerto alcun tempo residuo. Un Policy Override può invece consentire un accesso temporaneo; in questo caso, la quota non si applica. L’autorizzazione all’override non deve quindi essere attivata come alternativa indiscriminata per tutti gli utenti.

Una regola SSL/TLS Inspection corrispondente con Action > Deny continua a bloccare l’accesso; aumentare la quota o eseguire un reset non risolve questo conflitto. Verificare prima se il blocco TLS è intenzionale dal punto di vista dei requisiti aziendali. Pianificare una Web Exception per saltare la decrittazione HTTPS solo per un caso esplicitamente approvato e strettamente limitato. Questa eccezione elimina anche i controlli che dipendono dalla decrittazione e può consentire certificati server non validi; non usarla come soluzione standard. Verificare separatamente l’accesso pilota consentito, il mantenimento del blocco al di fuori dell’ambito dell’eccezione e il ripristino mediante disattivazione dell’eccezione pilota. L’ambito effettivo della Web Exception deve essere definito dai suoi criteri supportati, ad esempio l’IP di origine del pilota insieme al pattern hostname confermato, non dal gruppo dell’utente soggetto alla quota.

Verificare la Policy Quota durante l’esercizio

In Web > Policy quota status, SFOS mostra per i singoli utenti il tempo restante nelle Web Policy interessate entro un periodo di 24 ore. L’utente selezionato può essere reimpostato tramite Reset. Si tratta di una modifica deliberata dello stato e non di un pulsante diagnostico: prima si documentano utente, policy, tempo residuo, motivo e ora.

Questo reset riguarda la Policy Quota temporale di una categoria web. Non equivale a Reset user accounting per Surfing Quota o Network Traffic Quota. Un reset non corregge né un ordine errato delle regole né la mancata identificazione dell’utente.

Personalizzare le pagine di avviso e blocco

In Web > User notifications si possono configurare immagini personalizzate e messaggi di blocco, override, quota e avviso. I segnaposto {category}, {user} e {url} inseriscono categoria web, nome utente e URL bloccato. La preview verifica presentazione e testo, ma non dimostra che la Web Policy e la regola firewall corrette corrispondano alla richiesta di produzione.

Il messaggio deve spiegare brevemente perché l’accesso è stato bloccato o ha generato un avviso e dove segnalare un legittimo caso aziendale. Nomi utente e URL possono contenere informazioni sensibili; la pagina non deve quindi includere segreti interni, password o dati di contatto non necessari.

Per le immagini, attivare Use custom images e selezionare le immagini desiderate. Per i testi, attivare rispettivamente Use custom block message, Use custom override message, Use custom quota message o Use custom warn message e inserire il testo. Aprire il relativo link di anteprima e poi verificare il tipo di messaggio corrispondente con una richiesta pilota reale. Non usare dati reali dei clienti nelle immagini di test.

Limitare in sicurezza i Policy Overrides

Un utente già autorizzato dall’amministratore crea la propria sessione nello User Portal come segue:

1. Aprire My policy overrides > Add e assegnare un nome significativo alla sessione.
2. Mantenere il codice di accesso preimpostato oppure generarne uno nuovo tramite Generate access code. Un codice personalizzato creato manualmente è consentito solo se è stata concessa un’autorizzazione esplicita.
3. Selezionare i siti web e le categorie web consentiti necessari; le destinazioni escluse dagli override dall’amministratore non possono essere autorizzate.
4. In Restricted to time periods, selezionare una pianificazione esistente dall’elenco. Qui si sceglie una pianificazione, non si inserisce un intervallo arbitrario come testo libero.
5. Salvare con Apply. Successivamente, quando si accede a una destinazione bloccata corrispondente, inserire il codice di accesso nel campo del codice sulla pagina di blocco.

Con Status, l’utente attiva o disattiva questa sessione di override. Questa funzione non coincide con la gestione amministrativa tramite View overrides: l’amministratore può attivare, disattivare o eliminare la sessione creata dall’utente indipendentemente dal suo stato. Senza autorizzazione, questa procedura utente non è disponibile; resta valida la limitazione al gruppo principale AD e ai singoli utenti.

I Policy Overrides sono uno strumento diverso dalle quote. Con Enable policy override, gli utenti autorizzati possono creare nel User Portal un accesso temporaneo a siti web normalmente bloccati. Authorized users and groups limita chi può farlo, mentre Blocked websites and categories definisce le destinazioni che non possono mai essere ignorate. Allow manual access code entry viene attivato solo se i codici creati dagli utenti sono compatibili con il processo di approvazione.

In Web > General settings > Policy overrides, documentare prima lo stato precedente e gli utenti autorizzati. Nel User Portal, l’utente autorizzato specifica siti o categorie, un intervallo di tempo limitato e un codice di accesso per l’override. Quando si richiede una destinazione bloccata corrispondente, la pagina di blocco contiene un campo aggiuntivo per quel codice. Se Allow manual access code entry è attivo, gli utenti specificati possono creare i propri codici; se è disattivato, devono utilizzare codici generati. Questa scelta non va confusa con l’inserimento di un codice già valido nella pagina di blocco.

View overrides permette di visualizzare, attivare, disattivare ed eliminare gli override esistenti. Per la verifica, usare un utente di test autorizzato per accedere a una destinazione corrispondente entro l’intervallo di tempo con un codice valido; senza codice, fuori dall’intervallo e per una destinazione che non può mai essere autorizzata tramite override, deve restare il normale blocco. Correlare utente, Rule ID, web policy, azione e orario in Log Viewer. Per HTTPS, la pagina di blocco deve poter essere visualizzata; una semplice interruzione della connessione non offre un campo di inserimento.

Per il rollback, disattivare l’override pilota tramite View overrides e verificare il blocco originale con una nuova richiesta. Solo dopo eliminare un override non più necessario e ripristinare esclusivamente i valori globali modificati nel pilota allo stato precedente documentato. Non rimuovere indiscriminatamente gli override esistenti degli altri utenti.

Per gli utenti AD, My policy overrides si applica solo al gruppo principale e ai singoli utenti, non alle altre appartenenze a gruppi. Una regola di ispezione SSL/TLS corrispondente con Action > Deny continua ad avere la precedenza. Se in questa situazione deve funzionare un override approvato, si pianifica una Web Exception strettamente limitata per saltare la decrittazione HTTPS e la si testa separatamente con un caso negativo; la regola TLS non viene indebolita in modo generalizzato. L’autorizzazione all’override non limita la Web Exception; definirne l’ambito specifico basato su IP di origine e hostname/categoria e verificarlo con test negativi, come descritto di seguito.

Web Exceptions ed eccezioni TLS

Le Web Exceptions sono potenti e quindi pericolose quando vengono usate come soluzione rapida: un’eccezione in Web > Exceptions può saltare i controlli sul traffico corrispondente indipendentemente dalla politica web applicata. Se si salta HTTPS decryption, vengono eliminati i controlli che ne dipendono e sono consentiti certificati server non validi; se si salta Malware and content scanning, viene saltata automaticamente anche Zero-day protection.

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; non è un criterio di Web Exception.

Per le Web Exceptions, evitare domini radice e pattern regex URL troppo ampi: un semplice pattern come example.com può corrispondere anche a testo nel percorso o nella query di un altro dominio. I pattern specifici per hostname possono corrispondere nel contesto TLS; i percorsi presenti solo nell’URL sono visibili soltanto in HTTP o in HTTPS già decrittato. I criteri supportati per le Web Exceptions sono pattern regex URL, categorie web, indirizzi IP di origine e indirizzi IP di destinazione, non utenti, gruppi di utenti o URL Groups.

Per un’autorizzazione aziendale limitata a un gruppo di utenti, utilizzare la regola firewall corrispondente e Users nella Web Policy; per un’esclusione dalla decrittazione limitata in base all’identità in modalità DPI, utilizzare la regola di ispezione SSL/TLS appropriata con Don’t decrypt e criteri espliciti per utenti o gruppi. Questi criteri di identità non diventano criteri di una Web Exception applicata separatamente e non ne limitano da soli il bypass.

Per un progetto pilota con una Web Exception, combinare gli specifici Source IP addresses dei client con un pattern hostname confermato o una categoria web giustificata. Testare sia un’origine non approvata sia una destinazione al di fuori dell’effettivo ambito di corrispondenza; un indirizzo IP non è un’identità utente. Non dedurre dalla logica generica AND che le eccezioni basate su IP di origine e IP di destinazione possano essere combinate per l’esclusione TLS: le indicazioni mantenute sull’esclusione TLS affermano che non possono essere combinate, e il loro ambito esatto non è chiaro. Se sono necessarie entrambe le restrizioni IP, fermarsi senza attivare né ampliare l’eccezione e ottenere chiarimenti specifici per la build. La procedura e i limiti di corrispondenza sono descritti in Creare e testare in sicurezza le Web Exceptions.

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.

Automatizzare in modo mirato Web Protection tramite XML API

La XML API è utile quando occorre gestire gli stessi oggetti web verificati su più firewall. Non sostituisce né l’assegnazione della Web Policy alla regola firewall effettivamente appropriata né la verifica del traffico. Prima di scrivere, salvare l’inventario attuale degli oggetti, i relativi riferimenti e la vecchia policy. L’accesso, la costruzione delle richieste, la versione dell’API, lo stato XML e l’Audit Trail sono spiegati in Configurare in modo sicuro l’accesso alla XML API e valutare le risposte. Le relazioni tra oggetti riportate di seguito non costituiscono un modello di richiesta completo ed eseguibile. In presenza delle contraddizioni tra fonti esplicitamente indicate, consultare prima API help della build installata e non eseguire scritture senza un chiarimento univoco.

Prima gli oggetti, poi la policy e l’assegnazione

Un caso di automazione circoscritto consiste in un URL Group dedicato alle destinazioni aziendali, un File Type dedicato ai download e una User Activity che raggruppa questi criteri. Leggere o creare prima questi oggetti con i loro nomi effettivi, quindi fare in modo che le regole della policy facciano riferimento a tali oggetti e, infine, assegnare in modo controllato la Web Policy alla regola firewall esistente ed effettivamente appropriata. Un nuovo oggetto, da solo, non consente né blocca ancora alcun traffico.

• URL Group: WebFilterURLGroup contiene Name e voci URL ripetute sotto URLlist. La grafia URLlist non è la stessa di URLList di una Web Category esterna. IsDefault identifica un URL Group integrato; secondo la documentazione di riferimento, il campo è di sola lettura e le modifiche apportate vengono ignorate durante l’aggiornamento. Non trasforma un oggetto personalizzato in un oggetto predefinito modificabile. Per i valori di dominio appropriati e la gestione tramite UI, resta determinante la procedura per gli URL Group.
• File Type: FileType raggruppa FileExtensionList con valori FileExtension ripetuti e MIMEHeaderList con valori MIMEHeader ripetuti. Il commento nell’esempio XML descrive Template indicando che vengono riprese le estensioni e le intestazioni MIME del modello e che le voci indicate separatamente vengono aggiunte. Dopo la scrittura, verificare quindi la lista complessiva effettiva, non soltanto i valori aggiunti. L’esempio mostra Blank, ma la tabella dei parametri non spiega Template; non dedurne una lista universale dei template consentiti. Le estensioni restano prive del punto iniziale, ad esempio pdf.
• User Activity: UserActivity usa Name per il nome esistente e NewName per una rinomina prevista. Sotto CategoryList si trovano oggetti Category con Type e ID. Nell’esempio, le denominazioni dei tipi web category, file type e url group sono distinte da ID, che rappresenta il nome dell’oggetto. Non usare una denominazione di tipo come ID dell’oggetto e non inventare un ID numerico. L’esempio indica il tag di descrizione Desc, mentre la tabella indica Description; confermare il tag valido per la specifica build. La combinazione OR dei criteri dell’Activity resta separata dalla successiva azione HTTP/HTTPS.

In caso di errore relativo a File Type, queste risposte XML sono particolarmente rilevanti: Edit File Type 202 / Message.FileTypeUpdateWithRename, Add File Type o Edit File Type 503 / Message.FileTypeSameDetailRecordExists e 505 / Message.FileTypeInvalidExtensionOrMIMEHeader. Si tratta di simboli di riferimento invariati, non di testi di messaggio risolti né di codici HTTP. Con 202, leggere il vecchio e il nuovo nome e i riferimenti nelle policy; con 503, confrontare i valori di dettaglio già presenti e, con 505, verificare le estensioni e le intestazioni MIME. Non limitarsi a creare un secondo oggetto con un nome diverso.

Categorie personalizzate: separare contenuto, classificazione e larghezza di banda

WebFilterCategory distingue due modalità di immissione tramite ConfigureCategory: Local usa DomainList/Domain e KeywordList/Keyword; External usa URLList/URL per la lista di categorie esterna. L’URL di una lista esterna non è automaticamente un valore di dominio aziendale da autorizzare. L’origine, l’aggiornamento e il contenuto della lista esterna devono essere verificabili. Non combinare entrambe le modalità in una richiesta senza averle verificate.

Classification classifica la categoria, ma non determina Allow o Block. La descrizione riporta in parte denominazioni diverse da quelle della tabella degli enum; quest’ultima indica Productive, Unproductive, Acceptable e Objectionable. Anche ConfigureCategory non è del tutto coerente: l’esempio mostra Local/External, mentre la tabella include anche 0. Non trasmettere né nomi di classificazione tradotti né 0 come sostituto non verificato. QoSPolicy fa riferimento a una policy di larghezza di banda, non a un’azione della Web Policy; la selezione e l’effetto vengono verificati nella procedura di Traffic Shaping. Solo una regola Web Policy appropriata trasforma la categoria in una decisione di accesso.

La tabella delle categorie richiede un’attenta verifica successiva dei dettagli:

• Add Category 201 / Message.WFCCategoryDetailCannotAdded e Update Category 201 / Message.WFCCategoryDetailCannotUpdated: non considerare tutte le risposte XML 2xx come indicazione che i valori di dominio, parole chiave e liste siano stati salvati integralmente. Rileggere separatamente l’intestazione dell’oggetto e ogni insieme di dettagli necessario. Add Category 202 rimanda, come 200, a Message.WFCAddSuccess; il nome del simbolo condiviso non spiega la differenza tra i codici.
• Add Category 522 / Message.WFCMaxFiveURL e 523 / Message.WFCMaxFiveKeyword, ma Update Category 503 / Message.WFCMaxFiveURL e 504 / Message.WFCMaxFiveKeyword: valutare insieme operazione e codice. I soli nomi dei simboli non attestano un limite attuale universale di cinque voci; chiarire la quantità effettivamente consentita consultando la guida della build.
• Delete WebFilter Category 201 / Message.WFCRelationExists e 203 / Message.WFCSomeCategoryCannotDeleted: verificare i riferimenti e le categorie rimanenti prima di eliminare o riprovare. Non presumere un successo di eliminazione complessivo per una selezione di più categorie.

Tutti i simboli Message.* restano qui intenzionalmente non risolti. Prima di un nuovo tentativo, salvare lo stato effettivamente memorizzato e la risposta; in particolare, non ripetere alla cieca una modifica alle categorie applicata solo parzialmente.

Content Condition Lists: Key non è Name

Un oggetto ContentConditionList contiene il Name visibile, l’identità separata Key e ContentList con valori ContentString ripetuti. La documentazione di riferimento richiede Name e Key; per Delete Content Condition List, Key è esplicitamente il selettore. Durante la lettura e la documentazione, conservare quindi entrambi i valori e non usare mai il nome visualizzato come chiave di eliminazione senza averlo verificato.

La tabella API descrive ContentString come valori regex grezzi e afferma che i duplicati non vengono ignorati. L’importazione tramite UI descritta sopra è invece una lista di testo con un Exact Match per riga. Non è quindi dimostrato che un’importazione tramite UI e una lista regex API abbiano un formato di immissione identico. Prima di una conversione, chiarire la semantica con la guida della build e testare corrispondenze e non corrispondenze innocue; non trasmettere una lista di testo esistente come payload regex senza averla verificata.

Particolarmente evidenti sono le associazioni contraddittorie tra operazioni e messaggi nella documentazione di riferimento:

Queste righe attestano una contraddizione nella documentazione, non che un Update elimini o che un Delete aggiorni. Verificare l’operazione, Key, la risposta e i contenuti effettivamente presenti. Senza un chiarimento univoco per la build, non dedurne un’operazione distruttiva e non avviare un nuovo tentativo automatico sulla base del nome di un simbolo.

WebFilterPolicy: preservare ordine e selettori

WebFilterPolicy contiene le regole sotto RuleList/Rule. Ogni regola fa riferimento, sotto CategoryList/Category, a un nome di oggetto ID e a un selettore type. L’esempio della policy usa WebCategory, URLGroup, UserActivity, DynamicCategory e FileType; questi token differiscono dalle denominazioni dei tipi nell’esempio User Activity e il tag type è scritto in minuscolo in questo contesto. Riprendere la grafia, il tipo di oggetto e il nome esistente dall’oggetto letto o dalla guida della build, anziché serializzare etichette UI o ID inventati.

HTTPAction e HTTPSAction sono decisioni separate; FollowHTTPAction descrive il loro collegamento. L’esempio API indica Deny, Allow, Warn, Log e Quota. Questi valori di esempio non confermano che siano tutti selezionabili su ogni build e Deny non va semplicemente sostituito con la parola Block della UI. PolicyRuleEnabled controlla l’attivazione della regola, Schedule la pianificazione a cui si fa riferimento e UserList/User l’ambito degli utenti. CCLRuleEnabled e CCLList/CCL collegano i filtri dei contenuti alla regola; in questo punto l’esempio fa riferimento a un nome CCL, mentre l’eliminazione della CCL richiede il suo Key. Il comportamento HTTPS di un Content Filter deve continuare a corrispondere al collegamento nella UI spiegato sopra. Durante l’aggiornamento, preservare l’ordine, l’ambito degli utenti, la pianificazione, i filtri dei contenuti e la Default Action, e confrontare l’intera policy salvata. L’assenza di un campo non consente di presumere con certezza né il mantenimento né l’eliminazione.

Per i seguenti input, la documentazione di riferimento non fornisce un modello eseguibile privo di contraddizioni:

• DefaultAction: la tabella indica un massimo di un carattere, ma consente al contempo Allow e Deny. Non abbreviare a un carattere e non inventare una codifica numerica sostitutiva. EnableReporting mostra nell’esempio Enable/Disable, mentre la tabella consente soltanto Enable; la disattivazione non è quindi confermata senza una verifica della build.
• DownloadFileSizeRestriction: il commento XML indica da 1 a 1536 MB, mentre la tabella dei parametri indica da 0 a 1536. Il significato di 0 resta quindi non chiarito; non considerarlo né come illimitato né come un limite attivo valido. Definire insieme l’interruttore DownloadFileSizeRestrictionEnabled e il limite in base alla guida della build, e verificarli con file innocui di dimensioni inferiori e superiori al limite confermato. La tabella API indica per QuotaLimit un intervallo da 1 a 1440; verificare il limite nella API help della build installata prima di una modifica. DPI continua a non supportare la Quota della policy.
• Tenant Controls: Office365Enabled, Office365TenantsList e Office365DirectoryId riguardano la restrizione dei tenant Microsoft. Per la lista, la tabella API indica 4096 caratteri, mentre la guida UI per Restrict-Access-To-Tenants indica 256; non equiparare questi limiti e non dedurre dal dato API che sia possibile usare in produzione un valore più lungo. Il valore di esempio per Office365DirectoryId, 456ff232-35l2-5h23-b3b3-3236w0826f3d, contiene caratteri non esadecimali e non è un valore GUID di esempio valido. Non correggerlo implicitamente: usare invece l’effettivo Directory ID della propria gestione dei tenant e testare gli accessi ai tenant sia consentiti sia non consentiti. Confermare l’associazione dei campi UI, le lunghezze e la semantica nella build installata.

Add Policy 522 / Message.WebPoliciesLimit riguarda il limite delle policy; non dedurne un limite per regole o categorie. Update Policy 503 / Message.WFPQuotaLimitInvalid richiede la verifica dell’input Quota. La documentazione di riferimento riporta inoltre Update Policy from API come denominazione di operazione distinta; le relative righe di risposta non contengono questa voce 503. Ciò non dimostra che questo percorso accetti qualsiasi Quota. Verificare lo stato, la policy salvata e l’effetto reale prima di una nuova scrittura.

Non confondere opzioni di protezione globali e notifiche

WebFilterSettings è l’area delle impostazioni globali del filtro web, non una singola WebFilterPolicy. Contiene, tra l’altro, PharmingProtection, Scanning, BlockUnscannableContent e PUAWhitelist con nomi PUA ripetuti. Una voce PUA è un’eccezione approvata consapevolmente, non un passaggio necessario per una nuova Web Policy. La selezione dello scanner e il suo effetto restano trattati nella procedura di scansione malware collegata; modificare un messaggio non è un motivo per cambiare anche le opzioni di protezione globali o la lista PUA.

WebFilterProtectionSettings è un ulteriore contratto distinto per la scansione/protezione, con campi come ScanMode e FileSizeThreshold. La presenza di campi di protezione con nomi simili non lo rende sinonimo di WebFilterSettings o WebFilterNotificationSettings; non scambiare i payload tra questi oggetti. Per un semplice testo informativo, non includere opzioni di scansione, dimensione o certificato. Anche per questo oggetto di protezione, il contratto valido deve provenire dalla guida della build, non da valori di esempio ripresi senza verifica.

Anche qui l’esempio contraddice la tabella: BlockUnscannableContent mostra Enable/Disable, mentre la tabella consente Allow e Block (Best Protection). Non uniformare questi enum e non dedurli dal nome del campo. Prima di ogni modifica, salvare il comportamento precedente e chiarire il contratto esatto della build.

WebFilterNotificationSettings riguarda invece le notifiche agli utenti. OverrideDefaultDeniedMessage è associato a DefaultDeniedMessage, OverrideDefaultWarnedMessage a DefaultWarnedMessage; i testi personalizzati vengono selezionati consapevolmente solo con l’Override appropriato. Ulteriori campi Override/Quota sono presenti nella tabella, ma mancano in parte nell’esempio: OverrideDefaultOverrideMessage/DefaultOverrideMessage e OverrideDefaultQuotaMessage/DefaultQuotaMessage. Gli interruttori Override/Quota indicano come valori consentiti 0/1, ma al contempo indicano Enable come valore predefinito. Si tratta di un’ulteriore contraddizione tra fonti, non di un motivo per codificare tutti i flag allo stesso modo. Per una semplice modifica del testo, modificare soltanto i campi di testo/Override previsti secondo il contratto della build confermato e verificare la pagina corrispondente nel test pilota.

DeniedMessageImage seleziona Default o Custom. L’esempio collega TopImageFile e BottomImageFile a un nome di file della richiesta multipart; la tabella descrive jpg/jpeg. Per le User Notifications, tuttavia, la tabella chiama il parametro superiore Top Image, mentre l’esempio usa TopImageFile. Queste informazioni non sono sufficienti per costruire con certezza i nomi delle parti, Content-Disposition, l’endpoint di upload o l’associazione dei file. Chiarire prima il trasferimento dei file tramite la guida della build o una collection ufficiale confermata per tale scopo. Non eseguire modifiche automatizzate delle immagini senza un contratto di upload confermato. I campi di messaggio e immagine simili in WebFilterSettings non rendono i due oggetti intercambiabili.

DefaultWebFilterNotificationSettings è ulteriormente separato: offre testi di messaggio predefiniti con un nome, ad esempio WebsiteBlocked. Un caso d’uso utile e circoscritto è un avviso approvato con il contatto di supporto corretto. A tale scopo, salvare esattamente il testo originale interessato, modificare soltanto la chiave del messaggio confermata, verificare l’anteprima appropriata e la pagina pilota reale e, se necessario, ripristinare esattamente quel testo. Il testo di un messaggio non costituisce né un’autorizzazione di accesso né una prova di un rilevamento malware o zero-day.

Rileggere e convalidare ogni modifica automatizzata

Dopo ogni operazione di scrittura, rileggere tramite API o in WebAdmin l’oggetto esatto interessato: confrontare nomi/chiavi, liste effettive, riferimenti, ordine della policy, attivazione e assegnazione effettiva al firewall. Eseguire quindi le stesse richieste pilota consentite e bloccate usate prima della modifica e correlare Rule ID, utente, Web Policy e azione nel Log Viewer. Un successo HTTP, un codice XML 2xx o un simbolo Message.* non risolto, da soli, non bastano. In caso di modifica parziale o risposta poco chiara, salvare prima lo stato effettivo e l’Audit Trail, poi correggere in modo mirato; nessun nuovo tentativo Add/Delete alla cieca. Ripristinare soltanto le proprie modifiche documentate, non altre policy, Override o valori di protezione globali esistenti.

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

Il percorso esatto è Diagnostics > Tools > Pop-out tools > Policy tester. Firewall, SSL/TLS, and web verifica il percorso trasparente combinato, mentre Web policy only isola la decisione della politica web. Il test web rappresenta soltanto gli accessi trasparenti, non considera le route SD-WAN e non accetta Source Networks con indirizzi MAC. Se non si specifica un protocollo usa HTTP; se non si specifica una porta usa quella standard del protocollo scelto.

Prima della modifica, eseguire entrambi i modi pertinenti come riferimento e registrare il risultato e la Rule ID attesa; dopo la modifica, ripetere gli stessi test. Il Policy Tester resta una verifica preliminare e deve essere completato con veri test Allow e Block da un client pilota, perché NAT, ispezione TLS, QUIC, routing o un percorso Direct Proxy esplicito possono gestire diversamente il 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 ha gestito il traffico
• 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’autorizzazione aziendale, mantenerne ristretto l’ambito nella regola firewall corrispondente e nella Web Policy: un URL Group specifico invece di un’intera categoria e Users espliciti invece dell’intera LAN. Se invece è necessaria una Web Exception, utilizzare i suoi criteri supportati relativi a URL, categorie e IP; un gruppo di utenti o un URL Group non è un criterio di Web Exception.
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

In caso di blocchi urgenti, non inserire automaticamente una regola Allow ampia in cima all’elenco. Preferire un’autorizzazione aziendale circoscritta e limitata nel tempo nella regola firewall corrispondente e nella Web Policy, con un URL Group specifico, Users espliciti e una data di revisione. Non si tratta di una Web Exception limitata a un gruppo di utenti. Qualsiasi bypass dell’ispezione necessario richiede criteri di corrispondenza propri, approvati e supportati, oltre a test positivi e negativi separati. Rivalutare successivamente l’autorizzazione temporanea.

Errori tipici

La politica web non si applica

Spesso la politica non è attivata nella regola firewall corretta, il traffico non corrisponde alla regola, 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