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 nella serie Purple Enterprise WiFi Intelligence. Oggi parleremo di un argomento che si colloca all'intersezione tra sicurezza, operazioni HR e architettura di rete: lo staff WiFi captive portal. Ora, so cosa potrebbero pensare alcuni di voi. Un captive portal per il personale? Non è quello che si usa per gli ospiti? Ed è proprio questo il malinteso che dobbiamo affrontare fin da subito. Uno staff WiFi captive portal non è una splash page per gli ospiti con un logo diverso. È 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 configurato correttamente, elimina la singola vulnerabilità più grande nella maggior parte delle implementazioni WiFi aziendali: la chiave precondivisa (PSK). Se configurato in modo errato, vi ritroverete con ex dipendenti, appaltatori e dispositivi personali che stazionano sulla rete del personale a tempo indeterminato. Entriamo nei dettagli dell'architettura. [APPROFONDIMENTO TECNICO - circa 5 minuti] Il problema fondamentale con la maggior parte delle installazioni WiFi per il personale è la password condivisa. Una singola chiave precondivisa WPA2, scritta su un post-it nel retroufficio, condivisa in un gruppo WhatsApp e mai cambiata quando qualcuno se ne va. In un hotel da 200 camere con 80 dipendenti, quella password è stata condivisa con circa 80 persone, i loro partner che hanno preso in prestito il telefono e almeno tre ex dipendenti. Questa non è una rete. È una porta aperta. Lo staff WiFi captive portal risolve questo problema sostituendo le credenziali condivise con un flusso di onboarding verificato dall'identità. Ecco come funziona in pratica. Quando un nuovo dipendente connette il proprio dispositivo alla rete del personale per la prima volta, si imbatte in un SSID di provisioning. Si tratta di una rete aperta, ma è un "walled garden" (un giardino recintato): instrada solo verso il portale di onboarding e il vostro provider di identità. 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 volta che il provider di identità conferma che il dipendente è attivo e nel gruppo corretto, il portale esegue una delle due operazioni seguenti, a seconda dell'architettura di autenticazione. In un'implementazione basata su credenziali che utilizza PEAP e MSCHAPv2, il portale convalida le credenziali e rilascia un token di accesso alla rete. In un'implementazione basata su certificati che utilizza EAP-TLS, il portale avvia la generazione del certificato. Un certificato X.509 specifico per il dispositivo viene rilasciato dalla vostra Autorità di Certificazione, confezionato 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 dal SSID di provisioning e si connette automaticamente al 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. Parliamo ora del perché lo standard EAP-TLS rappresenti l'obiettivo ideale per la maggior parte delle implementazioni aziendali. Lo standard IEEE 802.1X definisce il framework, ma l'EAP-TLS è il metodo che elimina completamente il furto di credenziali dal percorso di autenticazione. Non esiste alcuna password da sottoporre a phishing. Non esiste alcun hash da forzare con attacchi brute-force. Il certificato è associato al dispositivo. Se il dispositivo viene smarrito o rubato, è sufficiente revocare il certificato nella Certificate Authority 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 rilasciato a fronte di tale identità, l'integrazione SCIM propaga automaticamente il deprovisioning. L'accesso termina nel momento stesso in cui cessa il rapporto di lavoro. Questa è l'architettura di cui organizzazioni come Premier Inn e Whitbread hanno bisogno per gestire centinaia di strutture 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 BYOD, perché è qui che il Captive Portal diventa particolarmente prezioso. Nella maggior parte dei settori alberghiero, retail ed eventi, una percentuale significativa del personale utilizza dispositivi personali per svolgere attività operative. Gli addetti alle pulizie controllano le assegnazioni delle camere sui propri smartphone. Gli addetti alle vendite utilizzano tablet personali per la ricerca di inventario. I team che gestiscono le operazioni negli stadi utilizzano telefoni personali per le comunicazioni. Si tratta di dispositivi non gestiti. Non è possibile controllarne la versione del sistema operativo, lo stato dell'antivirus o quali altre applicazioni vi siano installate. Devono essere trattati, nel migliore dei casi, come parzialmente 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 dei dispositivi gestiti. Si tratta di una 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: la policy di utilizzo accettabile, o AUP. Il Captive Portal è il naturale punto di applicazione per l'accettazione dell'AUP. Prima che un dipendente possa accedere alla rete del personale, il portale presenta la policy – che copre l'uso accettabile, il monitoraggio, il trattamento dei dati e le conseguenze di un uso improprio – e richiede un'accettazione esplicita. Questo crea un record tracciabile e datato dell'accettazione della policy. Ai sensi del GDPR, questo è importante. Ai sensi dello standard PCI DSS, per qualsiasi rete che gestisce dati dei titolari di carta, questo è importante. E nel caso di un'indagine disciplinare per uso improprio della rete, questo è estremamente rilevante. Ora, la larghezza di banda. È qui che Purple Shield diventa direttamente rilevante. In ambienti ad alta densità di personale – un hotel durante un fine settimana di tutto esaurito, un punto vendita nel Black Friday, uno stadio nel giorno della partita – la congestione della larghezza di banda sulla rete del personale è un reale problema operativo. Purple Shield opera a livello di DNS, bloccando ad payload, script di tracciamento e domini di malware prima che raggiungano il dispositivo. L'effetto pratico è una riduzione fino al 40% del totale dei dati scaricati sulla rete, secondo i dati di Purple. Per i dispositivi del personale, questo si traduce in caricamenti delle pagine più rapidi, un minore consumo di batteria dei dispositivi e una 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 raggiungere la rete. Questo miglioramento si ottiene 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] Passiamo alla sequenza di implementazione e agli errori da evitare. Inizia con la tua architettura VLAN prima di configurare un singolo access point. Definisci almeno tre VLAN: personale, ospiti e IoT. Mappa le policy del tuo firewall. Ottieni l'approvazione dal tuo team di sicurezza. Gli errori più costosi nelle installazioni WiFi si verificano quando si costruisce prima la rete e si aggiunge l'architettura di sicurezza solo successivamente. In secondo luogo, distribuisci la tua infrastruttura RADIUS con ridondanza. Un singolo guasto al server RADIUS blocca contemporaneamente tutti i membri del personale fuori dalla rete. In un hotel, ciò significa che la reception non può gestire i check-in. In un negozio di vendita al dettaglio, significa che i sistemi POS non possono autenticarsi. Distribuisci almeno due server RADIUS in una configurazione active-passive e testa il failover prima di andare online. In terzo luogo, integra il tuo server RADIUS con il tuo 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 successivo tentativo di connessione. Nessun passaggio manuale, nessuna coda di ticket, nessun ritardo tra la partenza e la revoca 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. Per l'addetto di magazzino stagionale che non ha mai installato un profilo di configurazione. Istruzioni chiare, interfaccia brandizzata e un numero di telefono dell'assistenza visibile su ogni schermata. Ora le insidie. 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. Limitalo al portale, agli endpoint dell'identity provider e al server di download dei certificati. Nient'altro. La seconda insidia è 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 modo differente. Testa il tuo flusso di onboarding sui dispositivi Android specifici che il tuo personale utilizza effettivamente prima del roll-out. Passpoint, noto anche come Hotspot 2.0, migliora significativamente l'esperienza su Android abilitando il rilevamento automatico della rete e l'autenticazione dopo la configurazione iniziale. La terza insidia è la scadenza dei certificati. Rilascia certificati a breve termine: 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 forza la riautenticazione rispetto allo stato corrente dell'identity provider. Un dispositivo appartenente a un ex dipendente il cui account è stato disattivato sei mesi fa fallirà automaticamente il nuovo onboarding. [DOMANDE E RISPOSTE RAPIDE - circa 1 minuto] Alcune domande che sentiamo di frequente. "Possiamo usare iPSK invece dell'802.1X completo?" Sì, per gli ambienti in cui la distribuzione dei certificati non è fattibile. iPSK, o Identity Pre-Shared Key, assegna una password WiFi unica a ogni utente o dispositivo. È più sicuro di una PSK condivisa perché ogni credenziale è individuale e revocabile. È meno sicuro di EAP-TLS perché è comunque basato su password. Usalo come trampolino di lancio, non come destinazione. "Abbiamo bisogno di WPA3 se utilizziamo già WPA2-Enterprise?" Se il tuo hardware lo supporta, sì. WPA3-Enterprise introduce la Simultaneous Authentication of Equals, che elimina gli attacchi a dizionario offline contro l'handshake. Il costo di migrazione sull'hardware supportato si riduce a una modifica della configurazione. Il miglioramento della sicurezza è concreto. "Come gestiamo i collaboratori esterni che non hanno un'identità aziendale?" Utilizza l'iPSK o una credenziale ospite a tempo limitato emessa tramite il portale. Imposta una data di scadenza corrispondente alla data di fine contratto. La piattaforma di Purple supporta nativamente credenziali di accesso limitate nel tempo. [RIASSUNTO E PROSSIMI PASSI - circa 1 minuto] Riassumendo, un Captive Portal WiFi per il personale non è una semplice funzionalità di comodità. È 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 (PSK) comune 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 prossimi passi immediati: esegui un audit del metodo di autenticazione attuale della rete del personale. Se utilizzi una PSK condivisa, questa rappresenta la priorità assoluta di risoluzione. Se utilizzi lo standard 802.1X basato su credenziali, valuta il passaggio a EAP-TLS basato su certificati. E se non hai distribuito Purple Shield sulla rete del personale, la sola riduzione della larghezza di banda giustifica la scelta. Per guide all'implementazione, modelli di architettura e casi di studio tratti dalle installazioni di Purple in oltre 80.000 sedi attive, visita purple.ai. Grazie per l'attenzione.