Captive Portal vs Splash Page

CAPTIVE PORTAL VS SPLASH PAGE - A PURPLE TECHNICAL BRIEFING Script per Podcast - Circa 10 Minuti Voce in Inglese Britannico --- SEGMENTO 1: INTRODUZIONE E CONTESTO (circa 1 minuto) Benvenuti alla serie Purple Technical Briefing. Sono il vostro presentatore 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 assistere a una riunione con un fornitore e sentire questi due termini usati come sinonimi, non siete i soli. Succede continuamente - nei documenti di gara, nelle presentazioni delle strategie IT, persino nelle conversazioni tra ingegneri di rete che dovrebbero decisamente conoscerne la differenza. E questa confusione ha importanza, perché quando si fondono i due concetti, si finisce per sovrastimare il componente sbagliato, sotto-investire in quello corretto o - peggio ancora - 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 ospiti con una schermata di accesso goffa e priva di branding. Quindi, oggi facciamo chiarezza. 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 punto vendita retail, di uno stadio o di un edificio del settore pubblico. --- SEGMENTO 2: APPROFONDIMENTO TECNICO (circa 5 minuti) Iniziamo 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é tale dispositivo non sia 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 qualsiasi traffico internet effettivo sia consentito, il captive portal lo intercetta. Ecco la sequenza tecnica. Il dispositivo dell'ospite invia una richiesta HTTP o HTTPS - potrebbe essere il tentativo di caricare un sito web, o potrebbe essere il 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 quella query DNS o richiesta HTTP e la reindirizza. Invece di raggiungere internet, il dispositivo riceve una risposta di reindirizzamento che punta a un URL specifico. Quell'URL è l'indirizzo in cui risiede la splash page.Ora, lo stesso meccanismo di reindirizzamento utilizza una delle due tecniche principali. La prima è il dirottamento DNS: 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 relativo al 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 impone 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, tranne il DNS e l'HTTP verso il server del portale, è bloccato. Una volta confermata l'autenticazione - che si tratti di un semplice clic, di un login social, 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 è importante: il Captive Portal è invisibile per l'ospite. Non lo vedono mai direttamente. Ciò che vedono è la splash page. La splash page è il livello applicativo - è l'HTML, il CSS e il JavaScript che vengono visualizzati nel browser dell'ospite o nella finestra pop-up del Captive Network Assistant. È l'interfaccia visiva: il vostro marchio, il vostro logo, il vostro messaggio di benvenuto, i vostri termini e condizioni, i pulsanti di login social, le caselle di controllo per il consenso 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 è il banco della reception - è il volto della vostra struttura, raccoglie informazioni e fa sentire l'ospite benvenuto. Avete bisogno di entrambi, ed essi devono collaborare in modo perfetto. Ora, perché questa distinzione è importante dal punto di vista commerciale? Perché quando valutate una soluzione WiFi per gli ospiti, dovete porre domande diverse su ciascun componente. Per il Captive Portal, vi chiederete: quali metodi di autenticazione supporta? È in grado di gestire l'802.1X per i dispositivi aziendali insieme al login social 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 agli obblighi di protezione dei dati previsti dal 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 gli A/B test? È in grado di mostrare contenuti diversi a segmenti di utenti differenti, ad esempio ai clienti fidelizzati rispetto ai visitatori alla prima esperienza? Supporta sfondi video, banner promozionali o pagine di reindirizzamento post connessione? Come si comporta sui dispositivi mobili? È accessibile? Si tratta di criteri di acquisto fondamentalmente diversi, e confondere le due cose 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 policy di sicurezza informatica. Abbiamo assistito anche al contrario - implementazioni di Captive Portal tecnicamente robuste con splash page progettate così male che i tassi di adozione da parte degli ospiti si attestavano intorno al trenta percento. Parliamo degli standard che sono alla base di tutto questo. Il meccanismo del Captive Portal non ha un unico standard di riferimento, ma opera all'interno di un quadro definito da diversi standard importanti. Lo standard IEEE 802.1X regola il controllo degli accessi alla rete basato su porte e definisce il modo in cui i dispositivi si autenticano a una rete utilizzando credenziali, certificati o token. È la base della sicurezza delle reti WiFi aziendali 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 WPA3, il più recente protocollo di sicurezza WiFi, introduce la tecnologia Opportunistic Wireless Encryption, che crittografa il traffico anche sulle reti aperte - un aspetto rilevante per le implementazioni di Captive Portal poiché modifica il funzionamento dell'handshake di connessione iniziale. Dal punto di vista della conformità, il GDPR ha implicazioni significative sul design della splash page. Se la tua splash page raccoglie dati personali - un indirizzo email, un nome, un login social - hai bisogno di un consenso esplicito e informato, di un'informativa sulla privacy chiara e di una base giuridica per il trattamento. La splash page è il luogo in cui viene acquisito tale consenso, ma il Captive Portal è lo strumento che garantisce il collegamento tra il consenso e l'accesso. Se un ospite rifiuta l'iscrizione al marketing, il Captive Portal deve comunque consentirgli l'accesso a Internet - l'accettazione del marketing non può essere una condizione vincolante per l'accesso alla rete ai sensi del GDPR. Lo standard PCI-DSS è rilevante se la rete WiFi per gli ospiti rientra nell'ambito degli ambienti di dati relativi alle carte di pagamento - in genere nel commercio al dettaglio o nel settore ricettivo. La segmentazione di rete applicata 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 E TRAPPOLE 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 con 200 camere. Hanno distribuito una soluzione WiFi per gli ospiti in cui la splash page presentava un branding curatissimo - il loro logo, un messaggio di benvenuto, un'offerta promozionale per la spa. Ma il captive portal sottostante era una semplice implementazione open-source che utilizzava il DNS hijacking senza alcuna gestione delle sessioni. Il 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 di timeout della sessione e nessuna integrazione con il sistema di gestione della struttura. La soluzione ha richiesto la sostituzione completa del controller del captive portal - la splash page andava bene così. In secondo luogo, una catena di vendita al dettaglio nazionale. Hanno distribuito 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 un design appropriato e personalizzato con il proprio brand, completa di 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 distinti richiedono investimenti 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 è obbligato a visitare. In secondo luogo, distribuire un captive portal senza supporto HTTPS per la splash page. Qualsiasi dato raccolto su una splash page non crittografata - indirizzi email, credenziali di accesso - viene trasmesso in testo non crittografato. Questo rappresenta un rischio per la sicurezza e per il GDPR. 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 attrito proprio nel momento in care saresti dovuti riuscire a creare un'impressione positiva del brand. - SEGMENTO 4: DOMANDE E RISPOSTE RAPIDE (circa 1 minuto) Passiamo in rassegna alcune domande che ci vengono poste regolarmente. Posso avere una splash page senza un captive portal? Tecnicamente sì - è possibile ospitare una pagina web e indirizzare gli utenti verso di essa - ma senza il captive portal che impone il reindirizzamento, gli ospiti non hanno alcun motivo per visitarla. Non avreste alcuna cattura 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 aziendali in cui l'autenticazione viene gestita silenziosamente tramite 802.1X. Ma per le distribuzioni rivolte agli ospiti, quasi sempre si desidera una splash page per gestire l'esperienza utente e l'acquisizione dei dati. La WPA3 rompe i Captive Portal? Non se implementata correttamente. La WPA3 con Opportunistic Wireless Encryption è compatibile con le distribuzioni di Captive Portal, ma richiede che il portale utilizzi HTTPS e che la rete pubblicizzi correttamente l'URL del portale. Alcuni dispositivi client più vecchi presentano problemi di compatibilità, motivo per cui molte sedi eseguono configurazioni a doppio SSID. Il login social tramite la splash page è sicuro? Dipende dall'implementazione. Il login 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 nel modo in cui tale token viene validato e nella 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. 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 che gestisca il controllo del Captive Portal di livello enterprise insieme a un design di splash page ricco e personalizzabile - con analisi complete, strumenti di conformità GDPR e integrazioni con la vostra infrastruttura esistente - questo è esattamente ciò per cui Purple è stato creato. Come prossimi passi, vi consiglio di consultare le guide all'implementazione di Purple sull'autenticazione 802.1X e sull'analisi del guest WiFi. I link sono nelle note dell'episodio. E se vi trovate nel bel mezzo di un processo di approvvigionamento, contattate il team 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