Captive Portal vs Splash Page

CAPTIVE PORTAL VS SPLASH PAGE - UN BRIEFING TECNICO PURPLE Script del Podcast - Circa 10 Minuti Voce in Inglese Britannico --- SEGMENTO 1: INTRODUZIONE E CONTESTO (circa 1 minuto) Benvenuti alla serie di briefing tecnici di Purple. Sono il vostro ospite e oggi faremo chiarezza su una delle fonti di confusione più persistenti nell'approvvigionamento e nell'implementazione del WiFi per gli ospiti: la differenza tra un captive portal e una splash page. Se vi è capitato di partecipare a una riunione con i fornitori e di sentire usare questi due termini in modo intercambiabile, non siete i soli. Accade continuamente - nei documenti di gara, nelle presentazioni delle strategie IT, persino nelle conversazioni tra ingegneri di rete che dovrebbero decisamente conoscerne la differenza. Questa confusione è importante, perché quando si confondono le due cose si rischia di definire in modo eccessivo il componente sbagliato, di investire troppo poco in quello giusto o, peggio, di implementare una soluzione WiFi per gli ospiti che ha un bell'aspetto ma è priva di un adeguato controllo di rete sottostante, oppure una soluzione tecnicamente solida che però allontana gli utenti con una schermata di accesso sgraziata e priva di branding. Quindi facciamo chiarezza oggi. Al termine di questo briefing, avrete un modello mentale chiaro di ciò che fa ciascun componente, di come interagiscono e di cosa cercare quando valutate le soluzioni per la vostra struttura - che si tratti di un hotel, di un parco retail, di uno stadio o di un edificio della pubblica amministrazione. --- SEGMENTO 2: APPROFONDIMENTO TECNICO (circa 5 minuti) Cominciamo con il captive portal, perché è la base su cui poggia tutto il resto. Un captive portal è un meccanismo a livello di rete. Il suo compito è intercettare tutto il traffico in uscita da un dispositivo appena connesso e trattenerlo in una sorta di sala d'attesa digitale finché quel dispositivo non è stato autenticato. Quando un ospite si connette al vostro SSID WiFi, il suo dispositivo riceve un indirizzo IP tramite DHCP - questa parte funziona normalmente. Ma prima che sia consentito il passaggio di qualsiasi traffico internet effettivo, il captive portal lo intercetta. Ecco la sequenza tecnica. Il dispositivo dell'ospite invia una richiesta HTTP o HTTPS - potrebbe cercare di caricare un sito web, oppure potrebbe trattarsi del controllo di connettività del sistema operativo stesso, che i dispositivi moderni come iPhone e telefoni Android eseguono automaticamente. Il controller del captive portal - che risiede sul controller wireless, sul router o su una piattaforma basata sul cloud - intercetta la query DNS o la richiesta HTTP e la reindirizza. Invece di raggiungere internet, il dispositivo riceve una risposta di reindirizzamento che lo rimanda a un URL specifico. Quell'URL è l'indirizzo in cui risiede la splash page. Ora, lo stesso meccanismo di reindirizzamento utilizza una di due tecniche principali. La prima è il DNS hijacking - il captive portal intercetta le query DNS e restituisce l'indirizzo IP del server del portale invece della destinazione reale. La seconda è il reindirizzamento HTTP - il portale intercetta la richiesta HTTP a livello di gateway ed emette una risposta di reindirizzamento 302. Per il traffico HTTPS, questo processo è più complesso, poiché non è possibile intercettare una sessione crittografata senza attivare un avviso di certificato. Ecco perché la maggior parte delle implementazioni di captive portal si affida al Captive Network Assistant integrato nel sistema operativo - la finestra pop-up che appare sul telefono quando ci si connette a una nuova rete - che utilizza un endpoint HTTP noto per rilevare i captive portal prima di tentare connessioni HTTPS. A livello di rete, il captive portal applica il controllo degli accessi utilizzando regole di firewall. I dispositivi non autenticati vengono inseriti in una VLAN o sottorete limitata in cui tutto il traffico, ad eccezione del DNS e dell'HTTP verso il server del portale, viene bloccato. Una volta confermata l'autenticazione - che si tratti di un semplice clic, di un social login, dell'acquisizione di un'e-mail o di uno scambio completo di credenziali 802.1X - il controller del portale aggiorna le regole del firewall per l'indirizzo MAC di quel dispositivo, spostandolo dalla zona limitata alla zona autorizzata con accesso completo a Internet. Questo è un punto importante: il captive portal è invisibile per l'ospite. Non lo vede mai direttamente. Ciò che vede è la splash page. La splash page è il livello applicazione - è l'HTML, il CSS e il JavaScript che vengono visualizzati nel browser dell'ospite o nel pop-up del Captive Network Assistant. È l'interfaccia visiva: il vostro brand, il vostro logo, il vostro messaggio di benvenuto, i vostri termini e condizioni, i pulsanti di social login, le caselle di controllo per l'adesione al marketing. È ciò che trasforma un freddo evento di autenticazione di rete in un'esperienza ospite personalizzata con il vostro brand. Pensatela in questo modo. Il captive portal è il buttafuori alla porta - decide chi entra e applica le regole. La splash page è la reception - è il volto della vostra struttura, raccoglie informazioni e fa sentire l'ospite benvenuto. Avete bisogno di entrambi e devono collaborare in modo ottimale. Ora, perché questa distinzione è importante dal punto di vista commerciale? Perché quando valutate una soluzione WiFi per ospiti, dovete porre domande diverse per ciascun componente. Per il captive portal, dovete chiedervi: quali metodi di autenticazione supporta? È in grado di gestire lo standard 802.1X per i dispositivi aziendali insieme al social login per gli ospiti? Supporta il bypass dell'indirizzo MAC per i dispositivi che non possono visualizzare un browser? Come gestisce i timeout di sessione e la riautenticazione? È conforme ai vostri obblighi di protezione dei dati ai sensi del GDPR? Si integra con la vostra infrastruttura RADIUS? Può segmentare il traffico per tipo di utente - separando il traffico degli ospiti da quello del personale a livello di rete?Per la splash page, le domande da porsi sono: quanto è personalizzabile? Il team di marketing può modificarla senza toccare la configurazione di rete? Supporta i test A/B? È in grado di mostrare contenuti diversi a segmenti di utenti differenti, ad esempio ai membri del programma fedeltà rispetto ai visitatori che effettuano il primo accesso? Supporta sfondi video, banner promozionali o reindirizzamenti post-connessione? Come si comporta sui dispositivi mobili? È accessibile? Si tratta di criteri di acquisto fondamentalmente diversi, e confonderli porta a decisioni errate. Abbiamo visto organizzazioni investire molto nel design di una splendida splash page, per poi scoprire che il Captive Portal sottostante non supportava i metodi di autenticazione richiesti dalla loro politica di sicurezza IT. Abbiamo visto anche il contrario: implementazioni di Captive Portal tecnicamente robuste con splash page progettate così male che i tassi di utilizzo da parte degli ospiti si attestavano intorno al trenta percento. Parliamo ora degli standard alla base di tutto questo. Il meccanismo del Captive Portal non ha un unico standard di riferimento, ma opera all'interno di diversi standard importanti. Lo standard IEEE 802.1X regola il controllo degli accessi alla rete basato su porta e definisce il modo in cui i dispositivi si autenticano a una rete utilizzando credenziali, certificati o token. Rappresenta la base della sicurezza WiFi aziendale ed è sempre più rilevante anche nei contesti di WiFi per gli ospiti in cui si desidera offrire un accesso continuo e basato su credenziali ai visitatori ricorrenti. Il protocollo WPA3, l'ultimo standard di sicurezza WiFi, introduce la crittografia OWE (Opportunistic Wireless Encryption), che crittografa il traffico anche sulle reti aperte; questo aspetto è rilevante per le installazioni di Captive Portal perché modifica il funzionamento dell'handshake di connessione iniziale. Dal punto di vista della conformità, il GDPR ha implicazioni significative per il design della splash page. Se la splash page raccoglie dati personali - un indirizzo email, un nome, un login social - sono necessari un consenso esplicito e informato, un'informativa sulla privacy chiara e una base giuridica per il trattamento. La splash page è il luogo in cui viene acquisito tale consenso, ma è il Captive Portal che impone il collegamento tra consenso e accesso. Se un ospite rifiuta l'iscrizione al marketing, il Captive Portal deve comunque concedergli l'accesso a internet - secondo il GDPR, il consenso al marketing non può essere una condizione per accedere alla rete. Lo standard PCI-DSS è rilevante se la rete WiFi per gli ospiti rientra nell'ambito degli ambienti di dati delle carte di pagamento - tipicamente nel settore retail o dell'ospitalità. La segmentazione della rete imposta dal Captive Portal è un controllo chiave in questo caso, poiché garantisce che il traffico degli ospiti sia isolato dai sistemi di pagamento. - SEGMENTO 3: RACCOMANDAZIONI DI IMPLEMENTAZIONE ED ERRORI DA EVITARE (circa 2 minuti) Permettetemi di presentarvi due scenari reali che illustrano come tutto questo si traduce in pratica. In primo luogo, un gruppo alberghiero di 200 camere. Avevano implementato una soluzione WiFi per gli ospiti in cui la splash page presentava un branding curato: il loro logo, un messaggio di benvenuto, un'offerta promozionale per la spa. Tuttavia, il captive portal sottostante era una semplice implementazione open source che utilizzava il DNS hijacking senza alcuna gestione delle sessioni. Risultato: agli ospiti che tornavano in hotel veniva richiesto di accedere nuovamente a ogni visita, anche all'interno dello stesso soggiorno. La splash page era fantastica, ma il captive portal non aveva persistenza dell'indirizzo MAC, nessuna configurazione del timeout di sessione e nessuna integrazione con il sistema di gestione della proprietà. La soluzione ha richiesto la sostituzione completa del controller del captive portal, mentre la splash page andava benissimo. In secondo luogo, una catena di vendita al dettaglio nazionale. Avevano implementato un captive portal di livello enterprise con supporto completo 802.1X, integrazione RADIUS e una sofisticata segmentazione del traffico. Ma la loro splash page era un modello predefinito: completamente bianca, senza branding, con un messaggio generico "Connettiti al WiFi". L'adozione da parte degli ospiti era del 34%. Dopo aver investito in una splash page con branding progettata correttamente, con un'opzione di social login con un solo clic, l'adozione è salita al 71% in tre mesi. Il captive portal non era cambiato affatto. La lezione di entrambi gli scenari: questi componenti separati richiedono investimenti separati e competenze separate. Non lasciate che il vostro team di rete gestisca il design della splash page e non lasciate che il vostro team di marketing prenda decisioni sull'architettura del captive portal. Errori comuni da evitare: in primo luogo, presumere che una splash page sia un captive portal. Non lo è. Una splash page senza un captive portal è solo una pagina web che nessuno è costretto a visitare. In secondo luogo, implementare un captive portal senza supporto HTTPS per la splash page. Qualsiasi dato raccolto su una splash page non crittografata - come indirizzi email o credenziali di accesso - viene trasmesso in chiaro. Questo rappresenta un rischio per il GDPR e per la sicurezza. In terzo luogo, ignorare l'esperienza mobile. Oltre l'80% delle connessioni WiFi degli ospiti proviene da dispositivi mobili. Se la vostra splash page non è ottimizzata per i dispositivi mobili, state creando attriti proprio nel momento in cui dovreste creare un'impressione positiva del brand. - SEGMENTO 4: DOMANDE E RISPOSTE RAPIDE (circa 1 minuto) Esaminiamo rapidamente alcune domande che sentiamo regolarmente. Posso avere una splash page senza un captive portal? Tecnicamente sì - potete ospitare una pagina web e indirizzarvi le persone - ma senza che il captive portal imponga il reindirizzamento, gli ospiti non hanno alcun motivo per visitarla. Non avreste acquisizione di dati, nessuna gestione del consenso e nessun controllo dell'accesso alla rete. Posso avere un captive portal senza una splash page? Sì, e questo è comune negli ambienti enterprise in cui l'autenticazione 802.1X avviene in modo silenzioso. Ma per le installazioni rivolte agli ospiti, quasi sempre desidererete una splash page per gestire l'esperienza utente e l'acquisizione dei dati. Il WPA3 blocca i Captive Portal? Non se implementato correttamente. Il WPA3 con Opportunistic Wireless Encryption è compatibile con le distribuzioni di Captive Portal, ma richiede che il portale utilizzi HTTPS e che la rete pubblichi l'URL del portale correttamente. Alcuni dispositivi client più vecchi presentano problemi di compatibilità, motivo per cui molti locali utilizzano configurazioni dual SSID. L'accesso tramite social network sulla splash page è sicuro? Dipende dall'implementazione. L'accesso tramite social basato su OAuth 2.0 - tramite Google, Facebook o Apple - è sicuro se implementato correttamente. La splash page gestisce il flusso OAuth e il Captive Portal riceve un token che conferma l'avvenuta autenticazione. Il rischio principale risiede nelle modalità di convalida di tale token e di gestione della sessione. - - - SEGMENTO 5: RIEPILOGO E PROSSIMI PASSI (circa 1 minuto) Concludiamo con i punti chiave da ricordare. Uno: un Captive Portal e una splash page non sono la stessa cosa. Il Captive Portal è il meccanismo di controllo della rete - intercetta il traffico e applica le regole di accesso. La splash page è l'interfaccia visiva - è ciò che l'ospite vede e con cui interagisce. Due: lavorano insieme. Il Captive Portal reindirizza l'ospite alla splash page. La splash page raccoglie l'autenticazione o il consenso. Il Captive Portal concede quindi l'accesso in base a tale risultato. Tre: valutateli separatamente. Ponete domande diverse, applicate competenze diverse e pianificate il budget per entrambi in modo indipendente. Quattro: la conformità vive nell'intersezione tra i due. Il consenso GDPR viene acquisito sulla splash page ma applicato dal Captive Portal. Assicuratevi che entrambi siano corretti. Cinque: Purple fornisce entrambi. Se cercate una piattaforma in grado di gestire il controllo del Captive Portal di livello enterprise insieme a un design di splash page ricco e personalizzabile - con funzionalità analitiche complete, strumenti di conformità GDPR e integrazioni con la vostra infrastruttura esistente - questo è esattamente ciò per cui Purple è stata creata. Come prossimi passi, vi consiglio di consultare le guide all'implementazione di Purple sull'autenticazione 802.1X e sull'analisi del WiFi per gli ospiti. I link si trovano nelle note dello show. E se vi trovate nel mezzo di un processo di acquisto, contattate il team di Purple per una valutazione tecnica - vale la pena definire correttamente l'architettura prima di impegnarsi in una distribuzione. Grazie per l'ascolto. Alla prossima. - - - FINE DELLO SCRIPT