Staff WiFi Captive Portal: Onboarding e autenticazione dei dipendenti

Staff WiFi Captive Portal: Onboarding and Authenticating Employees Un briefing di Purple Enterprise WiFi Intelligence [INTRODUZIONE - circa 1 minuto] Benvenuti alla serie Purple Enterprise WiFi Intelligence. Oggi tratteremo un argomento che si colloca all'intersezione tra sicurezza, operazioni HR e architettura di rete: il captive portal per il WiFi dello staff. Ora, so cosa potrebbero pensare alcuni di voi. Un captive portal per lo staff? Non è quello che si usa per gli ospiti? Ed è proprio questo il malinteso che dobbiamo affrontare fin da subito. Un captive portal per il WiFi dello staff non è una pagina di benvenuto per gli ospiti con un logo diverso. Si tratta di un gateway di onboarding strutturato che autentica i singoli dipendenti, applica l'accettazione delle policy e registra i dispositivi prima di concedere l'accesso alla rete aziendale. Se implementato correttamente, elimina la più grande vulnerabilità nella maggior parte delle distribuzioni WiFi aziendali: la chiave pre-condivisa. Se implementato in modo errato, vi ritroverete con ex dipendenti, collaboratori esterni e dispositivi personali che stazionano sulla rete dello staff a tempo indeterminato. Entriamo nei dettagli dell'architettura. [APPROFONDIMENTO TECNICO - circa 5 minuti] Il problema fondamentale della maggior parte delle distribuzioni WiFi per lo staff è la password condivisa. Una singola chiave pre-condivisa WPA2, scritta su un post-it nel retroufficio, condivisa in un gruppo WhatsApp e mai cambiata quando qualcuno se ne va. In un hotel di 200 camere con 80 membri dello staff, quella password è stata condivisa con circa 80 persone, i loro partner che hanno preso in prestito il telefono e almeno tre ex dipendenti. Quella non è una rete. È una porta aperta. Il captive portal per il WiFi dello staff risolve questo problema sostituendo la credenziale condivisa con un flusso di onboarding con identità verificata. Ecco come funziona in pratica. Quando un nuovo dipendente connette il proprio dispositivo alla rete dello staff per la prima volta, accede a un SSID di provisioning. Si tratta di una rete aperta, ma è un ambiente protetto - instrada solo al portale di onboarding e al vostro identity provider. Nient'altro. Il dipendente viene reindirizzato al captive portal, dove si autentica utilizzando la propria identità aziendale. Nella maggior parte degli ambienti aziendali odierni, ciò significa Single Sign-On tramite Microsoft Entra ID, Okta o Google Workspace. Una cyvolta che l'identity provider conferma che il dipendente è attivo e nel gruppo corretto, il portale esegue una delle due opzioni a seconda dell'architettura di autenticazione. In una distribuzione basata su credenziali che utilizza PEAP e MSCHAPv2, il portale convalida le credenziali ed emette un token di accesso alla rete. In una distribuzione basata su certificati che utilizza EAP-TLS, il portale avvia la generazione del certificato. Un certificato X.509 specifico per il dispositivo viene emesso dalla Certificate Authority, inserito in un profilo di configurazione - un file .mobileconfig su iOS o un profilo Passpoint su Android - e inviato al dispositivo. Il dispositivo installa il profilo, si disconnette dall'SSID di provisioning e si connette automaticamente all'SSID protetto dello staff utilizzando il certificato per l'autenticazione EAP-TLS. Da quel momento in poi, ogni volta che il dispositivo si connette alla rete del personale, il server RADIUS convalida il certificato. Nessuna richiesta di password. Nessun login manuale. Il dispositivo si connette semplicemente, in modo silenzioso e sicuro. Ora parliamo del perché EAP-TLS rappresenta lo stato obiettivo per la maggior parte delle installazioni enterprise. Lo standard IEEE 802.1X definisce il framework, ma EAP-TLS è il metodo che elimina completamente il furto di credenziali dal percorso di autenticazione. Non c'è alcuna password da sottrarre tramite phishing. Non c'è alcun hash da forzare con attacchi brute force. Il certificato è legato al dispositivo. Se il dispositivo viene smarrito o rubato, si revoca il certificato nella propria Autorità di Certificazione e il server RADIUS negherà l'accesso al tentativo di connessione successivo. Se il dipendente lascia l'azienda, si disabilita il suo account nell'identity provider e, poiché il certificato è stato emesso per quell'identità, l'integrazione SCIM propaga automaticamente il de-provisioning. L'accesso termina quando termina il rapporto di lavoro. Questa è l'architettura di cui organizzazioni come Premier Inn e Whitbread hanno bisogno per gestire centinaia di proprietà con migliaia di dispositivi del personale in un patrimonio distribuito. Non è possibile gestire tutto questo su larga scala con password condivise e revoche manuali. Affrontiamo anche la dimensione del BYOD, perché è qui che il captive portal diventa particolarmente prezioso. Nella maggior parte dei settori dell'ospitalità, del retail e degli eventi, una percentuale significativa del personale utilizza dispositivi personali per compiti operativi. Il personale delle pulizie controlla le assegnazioni delle camere sul proprio smartphone. Gli addetti alla vendita al dettaglio utilizzano tablet personali per la ricerca dell'inventario. I team operativi degli stadi utilizzano telefoni personali per le comunicazioni. Si tratta di dispositivi non gestiti. Non si controlla la versione del loro sistema operativo, lo stato del loro antivirus o quali altre applicazioni vi siano installate. Devono essere trattati, nel migliore dei casi, come semi-attendibili. Il captive portal per il WiFi del personale gestisce il BYOD inserendo questi dispositivi in una VLAN dedicata dopo l'autenticazione. La VLAN fornisce loro l'accesso alle specifiche applicazioni interne di cui hanno bisogno - il sistema di gestione della proprietà, l'interfaccia del punto vendita, l'app di pianificazione - e a nient'altro. Non possono raggiungere i server aziendali, i sistemi finanziari o la rete di dispositivi gestiti. Questa è la segmentazione VLAN applicata a livello RADIUS, ed è l'implementazione pratica del principio zero-trust: verificare l'identità, quindi concedere l'accesso minimo richiesto. Un altro elemento architetturale che vale la pena trattare: l'Acceptable Use Policy, o AUP. Il Captive Portal è il punto di applicazione naturale per l'accettazione dell'AUP. Prima che un dipendente ottenga l'accesso alla rete del personale, il portale presenta la policy - che copre l'uso accettabile, il monitoraggio, la gestione dei dati e le conseguenze di un uso improprio - e richiede una conferma esplicita. Questo crea un registro dell'accettazione della policy con timestamp e verificabile. Ai fini del GDPR, questo è importante. Ai fini PCI-DSS, per qualsiasi rete che tocca i dati dei titolari di carta, questo è importante. E nel caso di un'indagine disciplinare che comporti un uso improprio della rete, questo è estremamente importante. Ora, la larghezza di banda. È qui che Purple Shield diventa direttamente rilevante. In ambienti di personale ad alta densità - un hotel durante un fine settimana di tutto esaurito, un'area commerciale il Black Friday, uno stadio il giorno della partita - la congestione della larghezza di banda sulla rete del personale è un reale problema operativo. Purple Shield opera a livello DNS, bloccando i payload pubblicitari, gli script di tracciamento e i domini malware prima che raggiungano il dispositivo. L'effetto pratico è una riduzione fino al 40% dei dati totali scaricati sulla rete, secondo i dati di Purple. Per i dispositivi del personale, ciò significa caricamenti di pagina più rapidi, un minore consumo di batteria dei dispositivi e maggiore larghezza di banda disponibile per il traffico operativo. Le pagine si caricano fino a 3.5 volte più velocemente quando le oltre 120 query DNS tipiche di una pagina ricca di annunci vengono rimosse prima di colpire la rete. Si ottiene questo miglioramento senza toccare l'hardware, senza riconfigurare gli access point e senza alcuna configurazione per singolo dispositivo. [RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE DA EVITARE - circa 2 minuti] Permettetemi di fornirvi la sequenza di implementazione e le modalità di guasto da tenere d'occhio. Iniziate con la vostra architettura VLAN prima di configurare un singolo access point. Definite un minimo di tre VLAN: personale, ospiti e IoT. Mappate le policy del firewall. Ottenete l'approvazione del vostro team di sicurezza. Gli errori più costosi nelle implementazioni WiFi si verificano quando la rete viene creata prima e l'architettura di sicurezza viene aggiunta in un secondo momento. In secondo luogo, distribuite la vostra infrastruttura RADIUS con ridondanza. Un singolo guasto del server RADIUS blocca contemporaneamente ogni membro del personale fuori dalla rete. In un hotel, ciò significa che la reception non può elaborare i check-in. In un negozio al dettaglio, significa che i sistemi POS non possono autenticarsi. Distribuite almeno due server RADIUS in configurazione attivo-passivo e testate il failover prima di andare online. In terzo luogo, integrate il vostro server RADIUS con il vostro identity provider tramite LDAP o SAML. Questo è ciò che consente il deprovisioning automatico. Quando un dipendente viene disabilitato in Microsoft Entra ID o Okta, il server RADIUS smette di accettare le sue credenziali o il suo certificato al tentativo di connessione successivo. Nessun passaggio manuale, nessuna coda di ticket, nessun divario temporale tra la partenza e la rimozione dell'accesso. In quarto luogo, progetta il flusso di onboarding del tuo captive portal per l'utente meno tecnico del tuo team. Non per l'IT manager. Pensa all'operatore di magazzino stagionale che non ha mai installato un profilo di configurazione. Istruzioni chiare, interfaccia personalizzata con il brand e un numero di telefono dell'assistenza visibile su ogni schermata. Ora parliamo dei potenziali problemi. L'errore più comune è un walled garden troppo permissivo. Se l'SSID di provisioning consente l'accesso generale a Internet, il personale rimarrà semplicemente su di esso invece di completare il flusso di onboarding. Bloccale l'accesso limitandolo al portale, agli endpoint dell'identity provider e al server di download dei certificati. Nient'altro. Il secondo problema è la frammentazione di Android. iOS gestisce i profili dot-mobileconfig in modo coerente. Android no. Produttori e versioni del sistema operativo diversi gestiscono l'installazione dei certificati in modi differenti. Testa il tuo flusso di onboarding sui dispositivi Android specifici che il tuo personale utilizza effettivamente prima del lancio. Passpoint, noto anche come Hotspot 2.0, migliora notevolmente l'esperienza Android consentendo il rilevamento automatico della rete e l'autenticazione dopo la configurazione iniziale. Il terzo problema è la scadenza dei certificati. Rilascia certificati a breve durata - 90 giorni è un valore predefinito ragionevole per i dispositivi BYOD. Alla scadenza del certificato, il dispositivo deve eseguire nuovamente l'onboarding tramite il portale. Questo rimuove naturalmente i dispositivi obsoleti dalla rete e impone una nuova autenticazione in base allo stato corrente dell'identity provider. Un dispositivo appartenente a un ex dipendente il cui account è stato disabilitato sei mesi fa non supererà automaticamente il nuovo onboarding. [D&R RAPIDE - circa 1 minuto] Alcune domande che sentiamo di frequente. "Possiamo usare iPSK invece del protocollo completo 802.1X?" Sì, per gli ambienti in cui la distribuzione dei certificati non è fattibile. iPSK, o Identity Pre-Shared Key, assegna una password WiFi unica a ciascun utente o dispositivo. È più sicuro di una PSK condivisa perché ogni credenziale è individuale e revocabile. È meno sicuro di EAP-TLS perché è ancora basato su password. Utilizzalo come una soluzione di passaggio, non come destinazione finale. "Abbiamo bisogno di WPA3 se utilizziamo già WPA2-Enterprise?" Se il tuo hardware lo supporta, sì. WPA3-Enterprise introduce il protocollo Simultaneous Authentication of Equals, che elimina gli attacchi a dizionario offline contro l'handshake. Il costo della migrazione sull'hardware supportato si limita a una modifica della configurazione. Il miglioramento della sicurezza è concreto. "Come gestiamo i collaboratori esterni che non hanno un'identità aziendale?" Utilizza iPSK o credenziali ospite con scadenza temporale emesse tramite il portale. Imposta una data di scadenza corrispondente alla data di fine contratto. La piattaforma di Purple supporta nativamente le credenziali di accesso limitate nel tempo. [RIASSUNTO E PROSSIMI PASSI - circa 1 minuto] In sintesi. Un Captive Portal WiFi per il personale non è una funzionalità di comodo. È il punto di applicazione per la verifica dell'identità, l'accettazione delle policy, la registrazione dei dispositivi e il controllo degli accessi sulla rete operativa. La chiave pre-condivisa condivisa rappresenta un rischio di conformità e una vulnerabilità di sicurezza. Sostituiscila con un flusso di onboarding con verifica dell'identità, segmentazione VLAN e autenticazione basata su RADIUS. I tuoi prossimi passi immediati: verifica il metodo di autenticazione attuale della rete del personale. Se utilizzi una PSK condivisa, questo è l'intervento correttivo con massima priorità. Se utilizzi lo standard 802.1X basato su credenziali, valuta il passaggio a EAP-TLS basato su certificati. E se non hai Purple Shield distribuito sulla rete del personale, la sola riduzione della larghezza di banda giustifica l'investimento. Per guide all'implementazione, modelli di architettura e casi di studio delle installazioni di Purple in oltre 80.000 sedi attive, visita purple.ai. Grazie per l'attenzione.