Filtro DNS per MSP e strutture multi-sito

Il filtraggio DNS per MSP e proprietà multi-site controlla le richieste di dominio rispetto alle policy di sicurezza nel cloud prima che i dispositivi si connettano. Gestito centralmente tramite Purple insieme a SSID, Captive Portal e analytics, non richiede alcun hardware in loco. Funzionando tramite integrazioni come Cisco Meraki e HPE Aruba, Purple protegge proprietà di rete che coprono oltre 80.000+ sedi attive senza bisogno di agenti.

Che cos'è il filtraggio DNS per MSP e proprietà multi-site?

Ogni connessione effettuata da un dispositivo inizia con una ricerca DNS (Domain Name System). Il dispositivo chiede a un resolver di trasformare un nome come esempio.com in un indirizzo IP. Il filtraggio DNS, chiamato anche DNS protettivo, verifica quel nome rispetto a una policy prima di rispondere. Se il dominio è malevolo o fuori policy, il resolver trattiene l'indirizzo reale. Il dispositivo non apre mai una connessione, quindi non scarica nulla e non carica alcuna pagina.

Per una singola sede, questo è un controllo utile. Per un managed service provider (MSP) o un team IT multi-site, i requisiti cambiano forma. Si filtrano dozzine o centinaia di reti, di proprietà di clienti diversi, con regole diverse, su hardware diverso. Ciò comporta tre requisiti che un filtro per singola sede raramente soddisfa:

• Policy per singolo tenant. Un tenant è un cliente o un'unità aziendale con le proprie regole. Un gruppo alberghiero familiare, una catena di pub e uno studio medico non dovrebbero mai condividere la stessa policy.
• Gestione centralizzata. È necessario visualizzare e modificare la policy di ciascun tenant da un unico punto, senza accedere a ciascun sito.
• Nessun hardware per sito. Spedire, installare e aggiornare un dispositivo in ogni sede non è scalabile su un'intera flotta.

Purple Shield è l'add-on di DNS protettivo di Purple, insieme a SecurePass e Verify. Il filtraggio viene eseguito nel cloud e si collega agli SSID (nomi di rete), ai Captive Portal e agli analytics che già gestisci per ciascun cliente. Un Captive Portal è la pagina di accesso che un visitatore vede prima di andare online.

In che modo il filtraggio per MSP differisce da un'implementazione su singola sede

Un filtro per singola sede ha una policy, un amministratore e una rete. Una proprietà MSP ha una gerarchia. Imposti le regole per l'intera proprietà, le sovrascrivi per cliente, quindi le vari per rete all'interno di una sede. La rete ospiti di un hotel richiede regole diverse rispetto alla rete del personale dietro la reception.

I filtri DNS autonomi in genere gestiscono questo aspetto con una sotto-organizzazione per tenant, configurata separatamente dal WiFi stesso. Si finisce per gestire due stack per ogni cliente: uno per la rete e il portale, uno per il resolver. Purple Shield elimina il secondo stack, perché la policy di filtraggio segue le reti che hai già definito in Purple.

Perché il filtraggio DNS è importante su una flotta di siti cliente?

Tre pressioni spingono il filtraggio in cima all'agenda di un MSP: dovere di diligenza, esposizione alle minacce e larghezza di banda limitata.

Dovere di diligenza sulle reti condivise

Il WiFi pubblico e per ospiti comporta obblighi reali. In Inghilterra, le scuole e gli istituti d'istruzione superiore seguono gli standard di filtraggio e monitoraggio del Department for Education, citati in Keeping children safe in education. Negli Stati Uniti, il Children's Internet Protection Act (CIPA) richiede alle scuole e alle biblioteche che ricevono fondi E-rate di applicare filtri. Hotel, bar e centri ricreativi che accolgono famiglie affrontano rischi reputazionali se un minore accede a contenuti per adulti. Lo schema Friendly WiFi nel Regno Unito esiste esattamente per questa ragione.

Quando si gestisce il WiFi per 40 clienti, si condivide parte di ciascun obbligo. Un singolo sito non filtrato equivale a una conversazione con il cliente che si preferirebbe evitare.

Minacce che raggiungono i dispositivi non gestiti

Non è possibile installare un agente sullo smartphone di un visitatore, né applicarvi patch. Link di phishing, download di malware e callback di comando e controllo iniziano tutti con una ricerca DNS. Questo rende la ricerca l'unico punto di controllo per qualsiasi dispositivo sulla rete.

Shield segnala le minacce durante la fase di ricerca DNS, bloccando le richieste malevole prima che le connessioni vengano stabilite. In tutta la rete di sedi, il blocco di una minaccia si applica contemporaneamente a ogni cliente. Per una panoramica più ampia del mercato, consultare la guida Software per la protezione dal phishing: 10 opzioni per il WiFi condiviso.

Banda connettività su sedi con risorse limitate

Molte strutture gestiscono il WiFi ospiti su connettività modeste: un router 4G in un'area di servizio, una linea condivisa in un pub, un circuito saturo in una stazione. Il traffico pubblicitario e i contenuti web indesiderati competono con tutto il resto. Filtrare annunci e domini malevoli a livello DNS riduce il consumo di dati di rete e migliora la velocità di caricamento. Su una sede satura, questo margine viene restituito al traffico principale richiesto dagli ospiti.

Ciò che sfugge a un firewall

Un firewall rimane fondamentale, ma opera in un punto diverso: ispeziona le connessioni solo dopo che il DNS ha già risposto. Questo lascia quattro vulnerabilità su una rete di edifici multi-sito per ospiti:

1. La crittografia nasconde la destinazione. TLS 1.3 (RFC 8446) crittografa il certificato del server. Encrypted Client Hello (ECH), un'estensione IETF per TLS, può nascondere anche il nome del server. Senza decrittografia, un firewall vede un indirizzo IP e poco altro, e non è possibile installare un certificato di decrittografia sul dispositivo di un visitatore.
2. Gli indirizzi IP condivisi rendono confuse le regole. Le reti per la consegna dei contenuti (CDN) ospitano molti domini sugli stessi indirizzi. Bloccando l'IP si rischia di compromettere siti legittimi; consentendolo, il dominio dannoso riesce a passare.
3. I set di regole per singola sede si frammentano. Una rete sviluppata negli anni sovrappone fornitori di firewall e versioni di firmware differenti. Mantenere allineati 60 set di regole è un lavoro a tempo pieno, ed una singola sede dimenticata rappresenta la vulnerabilità.
4. Il blocco interviene in ritardo. Nel momento in cui un firewall interviene, il dispositivo ha già risolto il nome e tentato una connessione. Il filtraggio DNS blocca la richiesta prima ancora che la connessione venga stabilita.

Il filtraggio DNS colma queste lacune senza decrittografia, agenti o regole specifiche per singola sede. Non sostituisce comunque il compito del firewall di segmentare le reti e controllare le porte.

Come funziona il filtraggio DNS su più tenant?

Cosa succede durante ogni ricerca

1. Un ospite si connette al WiFi del cliente, spesso tramite un Captive Portal.
2. Il dispositivo richiede un dominio, ad esempio da un link in un'email di phishing.
3. Purple Shield verifica il dominio rispetto alla policy assegnata a quella rete.
4. Se il dominio è consentito, il dispositivo riceve l'indirizzo e si connette normalmente.
5. Se viene bloccato, la ricerca non restituisce l'indirizzo reale, quindi non viene aperta alcuna connessione.

Come strutturare la policy per singolo tenant

Il filtraggio dei contenuti per tenant funziona al meglio se organizzato come un piccolo set di policy standard, anziché come un insieme di regole personalizzate per ogni sede. Questo modello si adatta bene a settori quali hospitality, retail e pubblica amministrazione:

• Baseline di sicurezza. Malware, phishing e altre categorie di minacce vengono bloccati su ogni rete, per ogni tenant. Nessuno può disattivarlo.
• Ospiti famiglie. La baseline più contenuti per adulti e inappropriati per l'età. Adatto a hotel per famiglie, biblioteche, centri ricreativi, scuole e sale d'attesa sanitarie.
• Ospiti adulti. La baseline con regole sui contenuti più flessibili. Adatto a bar, locali notturni e business hotel.
• Personale. La baseline più le regole che riflettono la policy di uso accettabile di ciascun cliente.

Assegna una policy per rete, quindi aggiungi eccezioni per il cliente solo dove l'azienda ne ha effettivamente bisogno. Il team di marketing di un hotel potrebbe aver bisogno delle piattaforme social che una scuola bloccherebbe. Quattro policy e una breve lista di eccezioni sono molto più facili da verificare rispetto a 60 set di regole creati manualmente.

Poiché Purple Shield associa la policy alle reti gestite in Purple, gli SSID per ospiti e personale di una sede possono avere policy diverse. Le reti del personale che utilizzano IEEE 802.1X, lo standard per il controllo dell'accesso alla rete basato su porte, mantengono i propri controlli di identità. Purple Shield aggiunge il livello DNS come ulteriore protezione.

Gestire un'intera flotta da un'unica dashboard

La gestione centralizzata delle policy DNS porta vantaggi concreti solo se si adatta al tuo modo di lavorare abituale. Purple Shield si trova all'interno della stessa piattaforma Purple che gestisce gli SSID, i Captive Portal e le analisi di ciascun cliente. Non occorre passare da una console all'altra per modificare un filtro e non serve mantenere un secondo inventario delle sedi.

Questo offre vantaggi pratici per un MSP:

• Onboarding. Una nuova sede cliente in Purple non richiede un account resolver separato.
• Gestione delle modifiche. Modifica una policy una sola volta e questa verrà applicata a ogni rete a cui è assegnata.
• Reporting. L'attività di filtraggio si affianca alle analisi di connessione che già condividi, così un solo report trimestrale copre sia il WiFi che la sicurezza.

Perché non c'è nulla da spedire

Purple Shield applica i filtri nel cloud, quindi non c'è alcun dispositivo fisico da acquistare, configurare, spedire o sostituire in ciascuna sede. Purple è indipendente dall'hardware e funziona come overlay cloud su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. La rete di un cliente che include vendor differenti a seguito di acquisizioni continua a eseguire un solo set di policy. La configurazione varia in base al vendor, pertanto ti invitiamo a seguire la documentazione di supporto di Purple relativa al tuo hardware.

Purple opera già su oltre 80.000 sedi attive e ha registrato 440 milioni di accessi nel 2024 (dati Purple).

Come si presenta il filtraggio DNS su una rete reale?

I tre scenari seguenti sono modelli compositi basati su configurazioni aziendali comuni. Il numero di sedi e l'hardware sono tipici; i risultati rappresentano il calcolo operativo di ciascun cambiamento.

Scenario 1: un MSP con 14 clienti nel settore hospitality

Situazione. Un MSP gestisce la rete WiFi per ospiti e personale per 14 clienti del settore hospitality in 60 sedi. Il mix comprende hotel indipendenti, un gruppo di 20 pub e un parco vacanze. Il WiFi e i Captive Portal funzionano già su Purple. Il filtraggio veniva eseguito su un servizio DNS separato, con un account e un elenco di sedi per ciascun cliente.

Azione eseguita. L'MSP ha trasferito il filtraggio in Shield e ha sostituito 14 set di regole personalizzati con le quattro policy standard. Gli hotel per famiglie e il parco vacanze hanno adottato la policy per ospiti famiglie; il gruppo di pub ha scelto quella per ospiti adulti. Due clienti hanno mantenuto brevi elenchi di eccezioni.

Risultato. Zero hardware spedito e nessuna visita in loco nelle 60 sedi. L'MSP ha dismesso 14 account di filtraggio separati e ora gestisce ogni cliente dalla dashboard Purple che già utilizzava. La modifica di una regola comporta l'aggiornamento di una delle quattro policy, anziché di un massimo di 60 voci di sede.

Scenario 2: biblioteche e centri ricreativi di un comune

Situazione. Un consiglio provinciale offre WiFi pubblico in 22 biblioteche e cinque centri ricreativi. I bambini utilizzano le reti delle biblioteche dopo la scuola. Due gare d'appalto hanno portato all'adozione di HPE Aruba nelle biblioteche e Ubiquiti UniFi nei centri ricreativi. Il team IT è composto da tre persone.

Azione eseguita. Il comune ha applicato la policy per ospiti famiglie a ogni SSID pubblico e la policy per il personale alle reti aziendali. L'autenticazione del personale rimane su 802.1X con WPA3 - Enterprise, l'attuale standard di crittografia WiFi enterprise. I visitatori continuano a connettersi tramite il Captive Portal del comune.

Risultato. Tutte le 27 sedi eseguono un'unica policy pubblica su due fornitori di hardware differenti, senza alcun dispositivo fisico aggiuntivo. Una singola modifica si applica a tutte le 27 sedi. Il comune mostra agli auditor un'unica policy e un'unica fonte di log, anziché 27 configurazioni locali.

Scenario 3: una catena retail di 120 negozi con connessione limitata

Situazione. Un retailer offre WiFi ospiti ai clienti in 120 negozi, un terzo dei quali è connesso tramite rete 4G. La navigazione dei clienti compete con i sistemi del punto vendita per la larghezza di banda. L'ambiente dei dati dei titolari di carta è già segmentato dal traffico ospiti per mantenerlo al di fuori dell'ambito PCI-DSS.

Azione eseguita. Il retailer ha abilitato la protezione dalle minacce e il blocco degli annunci di Shield solo sull'SSID ospiti. Ha iniziato con un progetto pilota di 10 negozi nelle sue sedi 4G più trafficate. Le reti del personale e dei sistemi di negozio sono rimaste sui propri segmenti dedicati.

Risultato. Il progetto pilota ha misurato il consumo prima e dopo l'intervento nell'arco di quattro settimane, dimostrando una riduzione del consumo complessivo di dati sulle connessioni con limiti di banda. Il retailer ha quindi esteso la policy a tutti i 120 negozi con un'unica modifica, senza alcuna visita in cassa o in negozio.

Come si posiziona il filtraggio DNS rispetto a ciò che gestisci già?

Il DNS protettivo è solo un livello della sicurezza. Funziona al meglio affiancato ai controlli già in tuo possesso.

• Segmentazione. Le VLAN (LAN virtuali che suddividono una rete fisica in reti logiche isolate) tengono separato il traffico degli ospiti da quello del personale e dai sistemi di pagamento. Consulta Come configurare la segmentazione di rete per ospiti e personale.
• Autenticazione. L'802.1X con RADIUS, il protocollo che verifica le credenziali rispetto a un server centrale, stabilisce chi può accedere alla rete aziendale. Lo stesso vale per SecurePass con Microsoft Entra ID, Okta o Google Workspace. Shield stabilisce dove possono navigare i dispositivi una volta connessi.
• Firewall. Il tuo firewall continua a controllare porte, protocolli e traffico tra i segmenti. Shield blocca le destinazioni malevole note al momento della risoluzione.
• Normativa sulla privacy. I log DNS possono contenere indirizzi IP e identificativi dei dispositivi, che il GDPR considera dati personali. Purple è conforme al GDPR e certificata ISO 27001.

Confronto tra Shield, DNSFilter e Cisco Umbrella

DNSFilter e WebTitan si rivolgono principalmente agli MSP, mentre Cisco Umbrella rappresenta lo standard predefinito in molte infrastrutture Cisco. Tutti effettuano il filtraggio a livello di DNS nel cloud. Le differenze risiedono in chi gestisce cosa e dove.

Criterio	Purple Shield	DNSFilter	Cisco Umbrella
Dove avviene il filtraggio	Risoluzione DNS, nel cloud di Purple	Risoluzione DNS, nel cloud di DNSFilter	Risoluzione DNS, nel cloud di Cisco
Hardware per sede	Nessuno	Nessuno per il filtraggio di rete	Nessuno per la protezione a livello DNS
Gestione tenant	All'interno della dashboard Purple che gestisce il WiFi dei clienti	Console MSP separata con sotto-organizzazioni	Console separata multi-organizzazione o MSP
Collegato a SSID, Captive Portal e analisi WiFi	Sì, nativo nella piattaforma WiFi	No, configurato come stack separato	Si integra con Cisco Meraki, gestito nella propria console
Dispositivi in roaming fuori sede	Progettato per i dispositivi sulla rete WiFi gestita	Agente roaming client	Modulo roaming Cisco Secure Client
Copertura hardware	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, Fortinet	Qualsiasi rete in grado di inoltrare le richieste DNS ai suoi resolver	Qualsiasi rete in grado di inoltrare le richieste DNS ai suoi resolver, integrazione massima con Cisco
Ideale per	MSP i cui clienti utilizzano il WiFi su Purple	MSP che proteggono endpoint gestiti in sede e fuori sede	Infrastrutture standardizzate sulla sicurezza Cisco

Le alternative sono valide nei contesti in cui Shield non compete. DNSFilter e Cisco Umbrella offrono entrambi agenti di roaming per laptop aziendali fuori sede. Umbrella si inserisce inoltre nel più ampio portafoglio di sicurezza Cisco. WebTitan, di TitanHQ, offre a sua volta un filtro cloud multi-tenant per MSP. Se i tuoi contratti coprono gli endpoint aziendali ovunque si trovino, una di queste opzioni potrebbe essere adatta.

L'argomentazione a favore di Shield è più mirata e, per gli MSP orientati al WiFi, più forte. Se gestisci gli SSID, i Captive Portal e le analisi di ciascun cliente in Purple, uno stack di resolver separato per tenant rappresenta un costo operativo aggiuntivo. Per maggiori dettagli, leggi Shield vs DNSFilter: un confronto di DNS protettivo per operatori WiFi e Shield vs Cisco Umbrella: scegliere il DNS protettivo per il guest WiFi.

Quali sono i limiti del filtraggio DNS che dovresti conoscere?

Il filtraggio DNS agisce in un singolo punto di una connessione, e questo definisce i suoi limiti.

• Il DNS crittografato può aggirarlo. Il DNS over HTTPS (DoH, RFC 8484) e il DNS over TLS (DoT, RFC 7858) consentono a un dispositivo di scegliere il proprio resolver. I controlli di rete possono ridurre questo fenomeno sui dispositivi non gestiti, ma non possono eliminarlo. Vedi DNS over HTTPS spiegato: privacy vs filtraggio WiFi pubblico.
• Le VPN creano un tunnel che lo supera. Un utente ospite su una VPN personale risolve i nomi all'interno del tunnel. Puoi bloccare i domini VPN noti, ma non tutti.
• Le connessioni IP dirette saltano il DNS. Il malware che chiama un indirizzo IP hardcoded non effettua mai una ricerca. Il tuo firewall copre questo caso.
• Vede i domini, non i contenuti. Il filtraggio DNS consente o blocca un intero dominio, non singole pagine o file.
• Le categorie richiedono una revisione. Qualsiasi elenco di categorie a volte bloccherà troppo o troppo poco. Fornisci a ciascun cliente un contatto dedicato e una procedura per richiedere modifiche.
• I log richiedono governance. Concorda la conservazione e l'accesso per ciascun cliente prima del rollout e registrali nel tuo accordo sul trattamento dei dati.

Cosa dovresti fare ora?

1. Mappa i tuoi tenant. Elenca ogni cliente, sede e rete, insieme al settore verticale e agli obblighi normativi, come scuole, biblioteche, strutture sanitarie e locali con licenza.
2. Bozza di criteri standard. Inizia con i quattro sopra indicati e mantieni obbligatoria la baseline di sicurezza.
3. Pilota su sedi rappresentative. Scegli una sede per settore verticale, inclusa una con backhaul limitato, e misura l'uso dei dati prima e dopo.
4. Rollout per criterio, non per sede. Assegna i criteri alle reti per ciascun cliente, quindi rivedi le eccezioni dopo 30 giorni.
5. Fornisci report. Aggiungi l'attività di filtraggio alle revisioni WiFi che già fornisci.

Se il WiFi dei tuoi clienti non funziona ancora su Purple, inizia con Guest WiFi, quindi aggiungi Shield. Per ulteriori informazioni sulla protezione delle reti in diverse proprietà, consulta Tutte le guide.

Domande frequenti

Devo installare hardware presso ogni sede cliente per utilizzare il filtraggio DNS?

No. Shield filtra a livello DNS nel cloud, quindi non c'è alcuna apparecchiatura da acquistare, configurare o spedire in qualsiasi sede. Purple funziona come overlay cloud sugli access point già posseduti dai tuoi clienti, tra cui Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. La configurazione varia in base al produttore, quindi segui la documentazione di supporto di Purple per ciascun tipo di hardware presente nella tua rete.

Posso impostare criteri di filtraggio diversi per ciascun cliente e per ciascuna rete?

Sì. Shield collega la politica di filtraggio alle reti già attive su Purple, così ogni cliente e ogni SSID all'interno di una sede può avere una propria regola. La rete ospiti di un hotel può bloccare i contenuti per adulti, mentre la rete del personale applica le regole di uso accettabile del cliente. Un piccolo insieme di politiche standard, unito a brevi elenchi di eccezioni, è più facile da verificare rispetto a regole personalizzate per singola sede.

Posso gestire il filtraggio dei contenuti per più sedi da un'unica dashboard?

Sì. Shield viene gestito all'interno della stessa piattaforma Purple che esegue gli SSID, i Captive Portal e le analisi dei tuoi clienti, consentendoti di modificare il filtraggio senza cambiare console. Una modifica a una politica si applica a ogni rete assegnata a quella politica, in tutte le sedi. L'attività di filtraggio si affianca ai report WiFi esistenti, permettendo di analizzare connettività e sicurezza in un'unica revisione con il cliente.

Come si confronta Shield con DNSFilter per un MSP?

Shield è ideale per gli MSP i cui clienti utilizzano già il WiFi su Purple, mentre DNSFilter si adatta agli MSP che proteggono laptop gestiti sia in sede che fuori sede. Entrambi effettuano il filtraggio a livello DNS nel cloud, senza hardware aggiuntivo per sede. DNSFilter funziona come una console multi-tenant separata con un agente roaming. Shield opera all'interno della piattaforma WiFi, collegato agli stessi SSID, Captive Portal e analisi che già gestisci.

Gli ospiti possono aggirare il filtraggio DNS utilizzando DNS over HTTPS o una VPN?

Sì, un utente esperto può farlo. DNS over HTTPS, DNS over TLS e le VPN personali inviano le richieste all'esterno del tuo resolver. I controlli di rete possono ridurre questo fenomeno, ad esempio bloccando le VPN note e gli endpoint DoH pubblici, ma nessun filtro DNS garantisce il controllo totale su un dispositivo non gestito. È consigliabile considerare il filtraggio DNS come la protezione predefinita per ogni dispositivo che utilizza il DNS della rete, affiancandolo alla segmentazione e al firewall.

Il filtraggio DNS aiuta le scuole e le biblioteche a soddisfare i requisiti di filtraggio?

Copre l'elemento relativo al filtraggio, ma il solo filtraggio non soddisfa l'intero requisito. In Inghilterra, gli standard di filtraggio e monitoraggio del Department for Education richiedono sia il filtraggio che il monitoraggio, con responsabilità definite e verifiche regolari. Negli Stati Uniti, la normativa CIPA richiede alle scuole e alle biblioteche finanziate da E-rate di utilizzare misure di protezione tecnologica all'interno di una politica di sicurezza su Internet. Associa un filtraggio coerente tra le sedi ai tuoi processi di monitoraggio e salvaguardia.

Come vengono gestiti i log delle query DNS ai sensi del GDPR?

Purple è conforme al GDPR e detiene la certificazione ISO 27001. I log DNS possono includere indirizzi IP e identificatori dei dispositivi, che il GDPR considera dati personali. Concorda conservazione, accesso e finalità con ciascun cliente prima del rilascio, e registra tali termini nel tuo accordo sul trattamento dei dati. In qualità di MSP, agirai spesso come responsabile del trattamento per i tuoi clienti, pertanto è importante documentare chi controlla i log di ciascun impianto.

Come viene calcolato il prezzo di Shield per un impianto multi-sede?

Shield è un add-on di sicurezza per la piattaforma Purple, insieme a SecurePass e Verify, che ti consente di aggiungerlo alle sedi già attive su Purple. Non richiede hardware dedicato per ciascun sito, eliminando così i costi di appliance, spedizione o sostituzione dal tuo modello economico. Richiedi a Purple un preventivo basato sul numero dei tuoi clienti e delle tue sedi, includendo anche i siti che prevedi di attivare quest'anno.