La maggior parte delle guide sui Captive Portal parte dal punto sbagliato. Iniziano con il logo, i colori della splash page e il modulo e-mail, per poi trattare la sicurezza di rete come una semplice casella da spuntare. Una pagina curata non rende sicuro un SSID aperto, e un login riuscito non dimostra che il dispositivo di un ospite non possa raggiungere i sistemi interni.
Una configurazione di Captive Portal affidabile inizia dalla rete di accesso. Hai bisogno di un percorso ospiti separato, un traffico di pre-autenticazione rigorosamente controllato, un percorso di autenticazione adatto ai visitatori reali e controlli operativi che rimangano efficaci anche dopo il lancio. Il portale è parte dell'architettura di sicurezza, non solo una superficie di marketing.
Ridefinire il portale come perimetro di accesso
Il WiFi pubblico è diventato un servizio quotidiano con l'espansione dell'accesso in bar, hotel, stazioni e aeroporti, biblioteche e altri spazi pubblici. Nel 2014, il Regno Unito contava circa un hotspot WiFi ogni 11 persone, e la maggior parte degli hotspot richiedeva la registrazione prima dell'accesso a Internet, sebbene alcuni fossero gratuiti e altri fossero servizi commerciali. La stessa guida alla connettività digitale del governo locale del Regno Unito avvertiva che la sicurezza del WiFi pubblico poteva essere "blanda o inesistente".
Questa storia è importante perché rivela la reale funzione del portale. Si colloca tra l'associazione wireless e l'accesso illimitato, fornendo un punto di controllo per la registrazione, l'accettazione dei termini o il pagamento. Può autenticare un visitatore o registrare il consenso, ma non crittografa il traffico ordinario da solo e non impedisce a un dispositivo connesso di attaccarne un altro a meno che la rete non imponga l'isolamento.
Regola pratica: considerare il portale come un flusso di lavoro di autorizzazione inserito all'interno di una rete non attendibile, non come un perimetro di sicurezza che sostituisce la segmentazione.
La distinzione è facile da trascurare. Un ospite può completare un accesso personalizzato con il brand ed essere comunque esposto alle minacce associate a un accesso wireless aperto. Se la VLAN ospiti può instradare il traffico verso servizi aziendali, interfacce di gestione, stampanti o dispositivi smart, il portale ha solo reso più affidabile alla vista una rete non sicura.
Ecco perché l'identità e le policy di rete devono andare di pari passo. Una progettazione basata sull'identità può associare l'accesso a una persona, a una sessione o a una policy, ma il punto di applicazione deve comunque limitare ciò che quella sessione può raggiungere. Un riferimento utile per questo modello è l'identity-based networking, in particolare quando le strutture necessitano di trattamenti diversi per visitatori, personale, fornitori e dispositivi gestiti.
La popolazione connessa del Regno Unito si aspettava già un accesso mobile pratico nel 2015, quando il 78% degli adulti in Gran Bretagna, ovvero 39,3 milioni di persone, utilizzava Internet ogni giorno o quasi tutti i giorni, secondo il report sull'accesso a Internet dell'Office for National Statistics. Un buon portale deve quindi bilanciare due realtà: i visitatori si aspettano una connessione rapida, mentre l'operatore rimane responsabile di un percorso di accesso controllato e spiegabile.
Prerequisiti di rete e isolamento del traffico
Crea la rete ospiti prima di configurare la pagina. Inizia con un SSID ospiti dedicato associato a una VLAN separata. Non riutilizzare un SSID del personale con una splash screen diversa e non presupporre che un ruolo ospite da solo fornisca una separazione sufficiente senza aver prima testato il comportamento del firewall risultante.
Creare prima il percorso ospiti
La VLAN deve disporre del proprio scope DHCP e DNS. Applica regole firewall stateful che blocchino:
- Traffico da ospiti a rete aziendale: Impedisci l'accesso alle applicazioni aziendali, ai servizi di file, ai sistemi vocali e ad altre risorse private.
- Traffico da ospiti a rete di gestione: Nega l'accesso a controller wireless, switch, gateway, access point e interfacce amministrative.
- Traffico in entrata non autenticato: Blocca le connessioni non richieste verso i client ospiti e le reti interne.
- Traffico laterale tra ospiti: Abilita l'isolamento dei client a livello WLAN dove la piattaforma lo supporta, quindi verifica il risultato da dispositivi di test reali.
Prima dell'autenticazione, consenti solo le dipendenze necessarie per completare il percorso. Ciò include normalmente DHCP, DNS, il portale, gli endpoint API e tutti i controlli di connettività del sistema operativo esplicitamente richiesti. Mantieni ristretta la lista delle autorizzazioni pre-autenticazione. Una lista di autorizzazioni ampia facilita la risoluzione dei problemi per qualche minuto, ma crea una policy che nessuno potrà più revisionare con sicurezza.
Mantenere il walled garden deliberato
Reindirizza le richieste web a un portale HTTPS con un certificato valido. Consenti i contenuti e le dipendenze di autenticazione del portale prima del login, ma non permettere la navigazione non correlata come soluzione alternativa per una pagina che non si carica. Un walled garden generator può aiutare a comporre le voci necessarie, ma l'elenco finale richiede comunque una revisione rispetto ai servizi effettivi di identità, delivery dei contenuti e pagamento in uso.
La scelta della piattaforma influisce su quanto di questa policy si possa esprimere chiaramente. Se stai confrontando le opzioni di crittografia wireless e di accesso enterprise insieme a una progettazione per gli ospiti, questa guida aziendale WPA3 fornisce un contesto utile. WPA3 non elimina la necessità di un Captive Portal, ma può essere rilevante quando si scelgono percorsi più sicuri per il personale o per i dispositivi gestiti.
Il test di accettazione non consiste nel "caricamento della pagina". Consiste nel verificare che "un utente ospite non autenticato possa raggiungere solo le destinazioni previste e che un utente ospite autenticato continui a non poter accedere alle reti private".
Non inserire dispositivi amministrativi con privilegi su una rete con Captive Portal a meno che non vi siano controlli aggiuntivi per mitigare il rischio. La guida VPN del NCSC rileva che i Captive Portal richiedono la navigazione diretta all'esterno di una VPN durante l'autenticazione e possono esporre i dispositivi durante tale processo. Il personale e gli amministratori dovrebbero di norma utilizzare un WiFi enterprise basato su certificati o un altro percorso di accesso controllato.
Scelta del metodo di autenticazione corretto
L'autenticazione è una decisione di progettazione, non una scelta di campi da compilare. La acquisizione delle e-mail può essere adatta a un bar, l'SSO ai dipendenti, l'iPSK ad apparecchiature datate, e Passpoint può eliminare del tutto il portale per gli utenti ricorrenti. La scelta corretta dipende da chi si connette, da ciò che l'operatore deve dimostrare e da cosa succede quando il metodo preferito fallisce.
| Metodo | Frizione utente | Livello di sicurezza | Caso d'uso ideale |
|---|---|---|---|
| Click-through o acquisizione e-mail | Da bassa a moderata, a seconda dei campi richiesti | Identità di base o segnale di consenso | Accesso ospiti pubblico in cui la raccolta dei dati è proporzionata e accettabile |
| SSO | Moderata per i visitatori, bassa per il personale esistente | Accesso più sicuro e supportato da directory | Dipendenti e collaboratori con identità aziendali gestite |
| iPSK | Bassa dopo il provisioning, più alta durante la configurazione del dispositivo | Forte controllo dei dispositivi o dei segmenti | Dispositivi legacy, IoT e ambienti multi-tenant |
| Passpoint o OpenRoaming | Molto bassa dopo l'iscrizione | Onboarding crittografato più sicuro | Utenti abituali e offload della rete cellulare senza interruzioni |
Adatta il metodo all'utente
La raccolta di e-mail è facile da comprendere, ma diventa problematica quando gli operatori considerano il consenso al marketing come condizione per l'accesso a internet. Fornire, se possibile, un percorso separato e chiaramente etichettato che escluda il marketing, spiegare perché i dati vengono raccolti ed evitare di richiedere informazioni non necessarie al servizio.
L'SSO è appropriato per il personale perché l'organizzazione può collegare l'accesso a una directory esistente e revocarlo al variare dello stato lavorativo o contrattuale. Non è un metodo universale per gli ospiti. I visitatori potrebbero non disporre di un account compatibile, e forzare un utente finale attraverso un flusso di identità aziendale crea un attrito non necessario.
La tecnologia iPSK offre agli amministratori un controllo maggiore rispetto a una password condivisa, specialmente per i dispositivi che non possono gestire un'autenticazione interattiva moderna. Utilizza chiavi o policy separate dove i dispositivi richiedono un trattamento diverso e pianifica un processo di revoca prima di distribuire le credenziali.
Passpoint e OpenRoaming funzionano in modo eccellente quando la priorità è un accesso crittografato e senza attriti, anziché una splash page personalizzata. Richiedono un'infrastruttura di registrazione e identità compatibile, pertanto integrano anziché sostituire un portale in ciascuna sede.
Per l'autenticazione basata su directory, un servizio RADIUS gestito può ridurre l'onere di manutenzione di uno stack di autenticazione on-premise. RADIUS-as-a-Service è un'opzione da valutare insieme alle funzionalità già disponibili nella tua piattaforma wireless.
Progettare per la tolleranza ai guasti e l'accessibilità
Un percorso ben pianificato tiene conto dei visitatori privi di segnale mobile, delle persone che non acconsentono al marketing, degli utenti che utilizzano tecnologie assistive e degli ospiti che necessitano di un accesso immediato per motivi medici, lavorativi o di tutela. Offri un accesso assistito dal personale, voucher o un'altra alternativa proporzionata, e assicurati che la pagina funzioni con la navigazione da tastiera e con gli screen reader.
Il portale dovrebbe anche separare l'autorizzazione a Internet dal consenso promozionale. Il rapporto tecnologico su hotel e consumatori del 2025 descrive un'indagine nazionalmente rappresentativa sui consumatori britannici e ribadisce perché gli operatori dell'accoglienza dovrebbero testare le preferenze invece di presumere che ogni ospite desideri lo stesso percorso digitale.
Sfumature di configurazione specifiche del vendor
L'architettura rimane coerente tra i diversi vendor, ma i punti di vulnerabilità variano. In ogni caso, il controller deve sapere dove inviare il client non autenticato, quali destinazioni sono raggiungibili prima dell'autenticazione e in che modo un callback andato a buon fine modifica lo stato di accesso del client.
Meraki
Su Meraki, scegliere la modalità di splash page appropriata per lo SSID ospiti e configurare il Captive Portal esterno o il servizio di autenticazione. Verificare insieme il walled garden e i controlli del firewall associati. Un portale può caricarsi con successo mentre il callback viene bloccato, lasciando l'utente autenticato nel browser ma non autorizzato sul gateway.
Verifica attentamente i parametri di reindirizzamento. Il tuo portale necessita di contesto sufficiente per identificare la sede, l'SSID e la sessione client, ma non dovresti esporre informazioni non necessarie in un URL. Convalida il percorso di ritorno post-autenticazione e conferma che il cambio di policy avvenga sul dispositivo di rete previsto.
Aruba
Gli ambienti Aruba ricavano comunemente l'accesso dai ruoli utente. Confermare quale ruolo si applica prima dell'autenticazione, quale ruolo si applica dopo un callback andato a buon fine e se la policy del firewall del ruolo consente i servizi internet previsti. Un Captive Portal esterno configurato correttamente è inutile se il ruolo risultante blocca ancora il DNS o il traffico in uscita.
Mantenere il ruolo di pre-autenticazione deliberatamente restrittivo. Testare l'assegnazione del ruolo sia con un dispositivo pulito sia con un dispositivo precedentemente autorizzato, poiché lo stato in cache può nascondere una transizione errata.
Ruckus
I servizi hotspot Ruckus richiedono particolare attenzione alla relazione tra il profilo hotspot e la WLAN. Confermare che la pagina di login esterna, il walled garden e la policy post-autenticazione siano collegati allo stesso servizio ospiti. Verificare il comportamento di roaming quando un client si sposta tra i punti di accesso, in particolare dove il controller o il gateway mantengono lo stato della sessione a livello centrale.
Juniper Mist
Le implementazioni Juniper Mist dovrebbero essere testate a livello di policy e di integrazione cloud. Verificare che la policy WLAN, la VLAN ospiti e il flusso di lavoro di autenticazione esterna coincidano sullo stato del client. La visibilità gestita in cloud è utile, ma non sostituisce i controlli a livello di pacchetto quando un callback va a buon fine senza concedere l'accesso.
UniFi
Le impostazioni del server portal esterno di UniFi richiedono che l'URL del portale, la gestione del reindirizzamento e l'elenco di accesso pre-autorizzazione siano allineati. Evita di autorizzare l'intero dominio padre del portale quando è possibile definire un set di destinazioni più ristretto. Dopo il login, verifica se il client è uscito dalle restrizioni ospiti e se DNS, IPv4 e IPv6 seguono la stessa policy.
Una splash page visualizzata con successo dimostra solo che il browser ha raggiunto la pagina. Non dice nulla sul callback, sulla transizione di ruolo o sul risultato del firewall.
Per tutti i fornitori, registrare l'esatto stato della policy in ciascuna fase: associato, indirizzato, pre-autenticato, autenticato e scaduto. Questo rende la risoluzione dei problemi concreta. Se l'autenticazione va a buon fine ma l'accesso a internet fallisce, ispezionare il percorso di callback, lo stato di autorizzazione, la raggiungibilità del DNS e i log del gateway invece di riprogettare la pagina.
Procedure rigorose di test e validazione
Un singolo telefono che carica la splash page non costituisce un test di implementazione, ma solo un controllo visivo. La convalida in produzione deve accertare che la rete si comporti correttamente prima dell'autenticazione, dopo l'autenticazione, durante lo spostamento tra access point e in caso di guasto di una dipendenza.
Testare il perimetro di sicurezza
Utilizza un client pulito sull'SSID per gli ospiti e tenta di raggiungere i servizi interni, le interfacce di gestione e altri client ospiti. Esegui scansioni controllate della rete interna da un dispositivo di test autorizzato, conferma che il traffico tra client sia bloccato dove richiesto e ispeziona sia i log del firewall che i contatori delle policy WLAN.
Testa separatamente gli stati non autenticato e autenticato. Un client non autenticato deve ricevere solo il comportamento DHCP e DNS necessario per individuare il portale, oltre alle destinazioni pre-autenticazione approvate. Dopo l'autorizzazione, il client deve ottenere l'accesso a Internet senza guadagnare un instradamento verso le reti aziendali, di gestione o dei dispositivi con restrizioni.
Testare il comportamento reale dei dispositivi
Utilizzare dispositivi iOS, Android, Windows e macOS. I Captive Network Assistant possono comportarsi diversamente dai browser completi, specialmente quando il portale utilizza JavaScript complessi, reindirizza tra domini o dipende da una VPN. NCSC consiglia nello specifico di utilizzare l'assistente per Captive Portal della piattaforma, dove disponibile, e di considerare il WiFi pubblico come non attendibile.
Segui questo elenco di convalida:
- Controllo del certificato: verificare che il portale presenti un certificato valido per il proprio nome e che i client non ricevano avvisi relativi al certificato.
- Comportamento DNS: verificare che il DNS di pre-autenticazione funzioni come previsto e che le impostazioni del DNS privato o DNS-over-HTTPS non aggirino inaspettatamente la policy.
- IPv4 e IPv6: applicare controlli equivalenti a entrambi i protocolli. Un percorso IPv6 che aggira la policy del Captive Portal costituisce un errore di configurazione.
- Roaming: spostarsi tra i punti di accesso e verificare che la sessione rimanga coerente o scada secondo la policy.
- Avvio della VPN: completare il flusso del portale, quindi confermare che la VPN possa stabilirsi immediatamente. Non dare per scontato che una VPN sempre attiva possa autenticarsi attraverso lo stato del Captive Portal.
- Timeout: lasciare che le sessioni scadino e verificare che il client torni allo stato limitato previsto.
- Gestione dei guasti: scollegare il controller, il gateway o la dipendenza dal portale durante un test controllato e documentare se l'accesso fallisce bloccando il traffico (fail closed), permettendo l'accesso (fail open) o lasciando sessioni obsolete.
Testare l'identità senza presupposti sul MAC
Non utilizzare un indirizzo MAC come identità permanente. Gli indirizzi MAC casuali, il roaming e il ripristino dei dispositivi rendono inaffidabile il riconoscimento basato su MAC. Utilizza sessioni autenticate a breve durata e log centralizzati, quindi testa le connessioni ripetute con le funzioni di privacy degli indirizzi abilitate.
Se non hai testato il fallimento, non hai testato il portale.
Governance operativa e integrazione delle directory
Una rete ospiti diventa difficile da gestire quando il portale viene trattato come un progetto di lancio isolato. Definisci proprietà, policy, conservazione e escalation prima che il primo visitatore si connetta. L'operatore deve sapere chi esamina le attività sospette, chi può modificare il portale e con quale rapidità l'accesso può essere revocato.
L'integrazione con le directory è particolarmente preziosa per il personale e i collaboratori esterni. Collega il percorso del personale alla directory di identità scelta dall'organizzazione, come Microsoft Entra ID, Google Workspace o Okta, quindi mappa i gruppi della directory sui ruoli di rete. Il provisioning deve seguire lo stato occupazionale o contrattuale, mentre la revoca deve seguire le modifiche alla directory anziché un foglio di calcolo manuale.
Registrare i dati sufficienti per le indagini
Registra l'esito dell'autenticazione, l'identificatore del dispositivo o della sessione assegnato, il timestamp, il punto di accesso o la posizione e la versione della policy. Mantieni limitato l'accesso amministrativo, sincronizza gli orologi, proteggi l'archiviazione centrale dei log e definisci la conservazione prima del rilascio. Riduci al minimo i dati personali e indica chiaramente ai visitatori la finalità e il periodo di conservazione.
Le linee guida governative sulla sicurezza wireless richiedono che le autenticazioni riuscite sul Captive Portal degli ospiti vengano registrate o monitorate, che i ripetuti tentativi falliti vengano esaminati e che l'attività degli ospiti sia monitorata rispetto a una politica di uso accettabile. Questo approccio supporta anche un modello operativo pratico:
- Fallimenti ripetuti: Applica un rate limit ai tentativi e invia avvisi su pattern sospetti.
- Violazioni delle policy: Esamina l'attività rispetto alla policy di uso accettabile pubblicata.
- Modifiche al portale: Testa le modifiche in una sede controllata prima del rilascio su larga scala.
- Risposta agli incidenti: Mantieni un percorso chiaro per bloccare le sessioni, disabilitare le credenziali e conservare i registri pertinenti.
- Revisione della privacy: Rimuovi i campi e la conservazione dei dati non necessari per la finalità dichiarata.
Misurare la qualità del servizio e il controllo
Un portale può essere sicuro ma fallire a livello operativo se gli ospiti lo abbandonano o se il personale trascorre il tempo a risolvere problemi di accesso evitabili. Monitora il tasso di completamento del portale, il tempo medio di accesso a Internet, il tasso di errore di autenticazione, gli incidenti dell'help-desk e gli avvisi di violazione delle policy per sede e tipo di dispositivo.
Non ottimizzare il completamento indebolendo i controlli. Un modulo più corto può migliorare l'accesso aumentando al contempo i problemi di qualità dei dati, mentre un walled garden troppo ampio può ridurre i ticket ampliando però l'esposizione. Il giusto design consente di raggiungere Internet rapidamente, registra prove proporzionate, isola il traffico ospiti e fornisce agli operatori una risposta difendibile in caso di problemi.
Purple offre funzionalità di Captive Portal in cloud e di networking basato sull'identità che funzionano con gli ambienti esistenti come Meraki, Aruba, Ruckus, Mist e UniFi, tra cui autenticazione degli ospiti personalizzata con il proprio brand, accesso del personale collegato alla directory e analisi operative. Rivedi la tua attuale VLAN ospiti, i fallback di autenticazione e i controlli di registrazione, quindi visita Purple per valutare come la sua piattaforma possa adattarsi alla configurazione del tuo Captive Portal.
