Captive Portal vs Splash Page

CAPTIVE PORTAL VS SPLASH PAGE - UN DOCUMENTO TECNICO PURPLE Script del podcast - Circa 10 minuti Voce inglese del Regno Unito --- SEGMENTO 1: INTRODUZIONE E CONTESTO (circa 1 minuto) Benvenuti alla serie Purple Technical Briefing. 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 un fornitore e di sentire usare questi due termini in modo intercambiabile, non siete i soli. Succede continuamente - nei documenti di RFP, nelle presentazioni delle strategie IT, persino nelle conversazioni tra ingegneri di rete che dovrebbero saperne di più. E questa confusione è importante, perché quando si confondono le due cose, si finisce per sovradimensionare il componente sbagliato, per sotto-investire in quello giusto o, peggio, per implementare una soluzione WiFi per gli ospiti che ha un bell'aspetto ma non ha un adeguato controllo di rete alla base, oppure una soluzione tecnicamente solida che però allontana gli ospiti con una schermata di login goffa e priva di brand. 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 sede, che si tratti di un hotel, di un punto vendita, di uno stadio o di un edificio della pubblica amministrazione. --- SEGMENTO 2: APPROFONDIMENTO TECNICO (circa 5 minuti) Iniziamo con il captive portal, perché è la base su cui si 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 fino a quando tale 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 effettivo traffico internet, 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 o 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 su cloud - intercetta la query DNS o la richiesta HTTP e la reindirizza. Invece di raggiungere internet, il dispositivo riceve una risposta di reindirizzamento che punta a un URL specifico. Quell'URL è il luogo in cui risiede la splash page. Ora, il meccanismo di reindirizzamento stesso 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 e invia una risposta di reindirizzamento 302. Per il traffico HTTPS, questo processo è più complesso, perché 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 di quello DNS e HTTP verso il server del portale, è 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 è importante: il captive portal è invisibile per l'ospite. Non lo vede mai direttamente. Ciò che vede è la splash page. La splash page è il livello applicativo - è l'HTML, il CSS e il JavaScript che viene visualizzato nel browser dell'ospite o nella finestra pop-up del Captive Network Assistant. È l'interfaccia visiva: il tuo brand, il tuo logo, il tuo messaggio di benvenuto, i tuoi termini e condizioni, i tuoi pulsanti di social login, le tue 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 tuo brand. Pensala 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 tua struttura, raccoglie informazioni e fa sentire l'ospite il benvenuto. Hai bisogno di entrambi, ed entrambi devono funzionare insieme in modo ottimale. Ora, perché questa distinzione è importante dal punto di vista commerciale? Perché quando valuti una soluzione WiFi per gli ospiti, devi porre domande diverse per ciascun componente. Per il captive portal, ti chiederai: Quali metodi di autenticazione supporta? Può gestire l'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 tuoi obblighi di protezione dei dati ai sensi del GDPR? Si integra con la tua 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, ti chiederai: quanto è personalizzabile? Il tuo team di marketing può modificarla senza toccare la configurazione di rete? Supporta gli A/B test? Può mostrare contenuti diversi a segmenti di utenti differenti — ad esempio, membri del programma fedeltà rispetto ai visitatori che accedono per la prima volta? Supporta sfondi video, banner promozionali o pagine di reindirizzamento successive alla 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 bellissima 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 adozione da parte degli ospiti si aggiravano intorno al trenta percento. Parliamo degli standard alla base di tutto questo. Il meccanismo del captive portal non ha un unico standard di riferimento, ma opera all'interno di un quadro di riferimento composto da diversi standard importanti. IEEE 802.1X è lo standard di controllo dell'accesso alla rete basato su porta che regola il modo in cui i dispositivi si autenticano a una rete utilizzando credenziali, certificati o token. È la base della sicurezza WiFi aziendale ed è sempre più rilevante anche nei contesti di WiFi per gli ospiti, dove si desidera offrire un accesso continuo e basato su credenziali ai visitatori che ritornano. WPA3, l'ultimo protocollo di sicurezza WiFi, introduce la Opportunistic Wireless Encryption, che crittografa il traffico anche sulle reti aperte — un aspetto rilevante per le implementazioni 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 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 applica il collegamento tra consenso e accesso. Se un ospite rifiuta l'adesione al marketing, il captive portal deve comunque concedergli l'accesso a internet — il consenso al marketing non può essere una condizione per accedere alla rete ai sensi del GDPR. Il PCI-DSS è rilevante se la tua rete WiFi per gli ospiti rientra nell'ambito degli ambienti di dati delle carte di pagamento — tipicamente nel retail o nell'hospitality. 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 E TRAPPOLE DA EVITARE (circa 2 minuti) Lascia che ti presenti due scenari reali che illustrano come questo si traduce in pratica. In primo luogo, un gruppo alberghiero da 200 camere. Hanno distribuito una soluzione WiFi per gli ospiti in cui la pagina di benvenuto era splendidamente personalizzata con il loro brand - il loro logo, un messaggio di benvenuto, un'offerta promozionale per la spa. Ma il Captive Portal sottostante era un'implementazione open-source di base che utilizzava il dirottamento DNS 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 pagina di benvenuto 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 - la pagina di benvenuto andava bene. In secondo luogo, una catena di vendita al dettaglio nazionale. Hanno implementato un Captive Portal di livello aziendale con supporto completo 802.1X, integrazione RADIUS e una sofisticata segmentazione del traffico. Ma la loro pagina di benvenuto era un modello predefinito - bianco e semplice, senza branding, con un messaggio generico "Connettiti al WiFi". L'adozione da parte degli ospiti era del 34%. Dopo aver investito in una pagina di benvenuto con un brand ben progettata e con un'opzione di accesso social 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 lasciare che il tuo team di rete gestisca il design della pagina di benvenuto e non lasciare che il tuo team di marketing prenda decisioni sull'architettura del Captive Portal. Errori comuni da evitare: in primo luogo, presumere che una pagina di benvenuto sia un Captive Portal. Non lo è. Una pagina di benvenuto senza un Captive Portal è solo una pagina web che nessuno è costretto a visitare. In secondo luogo, distribuire un Captive Portal senza supporto HTTPS per la pagina di benvenuto. Qualsiasi dato raccolto su una pagina di benvenuto non crittografata - indirizzi email, credenziali di accesso - viene trasmesso in chiaro. Questo è 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 tua pagina di benvenuto non è ottimizzata per i dispositivi mobili, stai creando attrito proprio nel momento in cui dovresti creare un'impressione positiva del brand. --- SEGMENTO 4: DOMANDE E RISPOSTE RAPIDE (circa 1 minuto) Vediamo rapidamente alcune domande che sentiamo regolarmente. Posso avere una pagina di benvenuto senza un Captive Portal? Tecnicamente sì - puoi ospitare una pagina web e indirizzare le persone ad essa - ma senza il Captive Portal che impone il reindirizzamento, gli ospiti non hanno motivo di visitarla. Non avresti acquisizione di dati, nessuna gestione del consenso e nessun controllo dell'accesso alla rete. Posso avere un Captive Portal senza una pagina di benvenuto? Sì, e questo è comune negli ambienti aziendali in cui 802.1X gestisce l'autenticazione in modo invisibile. Ma per le distribuzioni rivolte agli ospiti, quasi sempre desideri una pagina di benvenuto per gestire l'esperienza utente e l'acquisizione dei dati. WPA3 blocca i Captive Portal? No, se implementato correttamente. 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 social login tramite la splash page è sicuro? Dipende dall'implementazione. Il social login 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'autenticazione. Il rischio principale risiede nel modo in cui tale token viene convalidato e in cui viene gestita la 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 sulla 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 preventivate i costi per entrambi in modo indipendente. Quattro: la conformità risiede nella loro 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 mezzo di un processo di acquisto, contattate il team di Purple per una valutazione tecnica - vale la pena definire correttamente l'architettura prima di procedere con la distribuzione. Grazie per l'ascolto. Alla prossima. - - - FINE DELLO SCRIPT