Come revocare l'accesso WiFi quando un dipendente lascia l'azienda

Benvenuto in questo briefing tecnico sulla revoca dell'accesso WiFi quando un dipendente lascia l'azienda. Il problema spesso appare più piccolo di quello che è in realtà. Qualcuno se ne va il venerdì. Il suo manager disabilita l'e-mail e ritira il laptop. Eppure, il suo telefono o dispositivo personale può ancora connettersi al WiFi del personale il lunedì. In un hotel, questo potrebbe posizionare un ex dipendente vicino ai sistemi operativi. In una rete di vendita al dettaglio, potrebbe consentire l'accesso a una rete del personale in molti negozi. In uno stadio o in un centro congressi, potrebbe rendere più difficile la gestione di una giornata di eventi affollata. La domanda immediata non è se chi se ne va conosce una password. È se il tuo WiFi è in grado di identificare quella persona come un'identità distinta e negare l'accesso a quell'identità senza disturbare tutti gli altri. Una singola passphrase WPA2 condivisa non può farlo. Ogni persona ha la stessa credenziale. Una volta che quella passphrase è stata condivisa con chi se ne va, la rete non ha un modo pulito per distinguere quell'ex dipendente da ogni dipendente autorizzato che la conosce. La risposta pratica è una rotazione della passphrase a livello aziendale, seguita da un aggiornamento su ogni dispositivo approvato. Questo è operativamente costoso, genera ticket di supporto e spesso viene ritardato. Non è un controllo di offboarding credibile in giornata per una proprietà immobiliare di sedi distribuite. Esistono tre modelli credibili. Il primo è l'802.1X per persona con EAP-TLS. Il secondo è iPSK, a volte chiamato chiave precondivisa individuale. Il terzo è il deprovisioning guidato dall'identity provider tramite SCIM. È possibile combinare questi modelli. La scelta progettuale centrale rimane la stessa: rendere le credenziali di accesso attribuibili a una persona o a un dispositivo gestito, quindi rendere la rimozione un evento controllato e registrato. Iniziamo con 802.1X ed EAP-TLS. L'IEEE 802.1X è il framework di controllo dell'accesso alla rete. Separa il dispositivo che chiede di connettersi, l'autenticatore sul perimetro della rete e il servizio di autenticazione back-end. EAP-TLS è un metodo Extensible Authentication Protocol che utilizza certificati per l'autenticazione reciproca e la derivazione delle chiavi. In parole povere, il dispositivo dimostra il possesso di un certificato e la rete dimostra la propria identità nello stesso scambio di autenticazione. Questo modello si adatta ai dispositivi del personale gestiti e alle reti ad alta sicurezza. L'azione per chi se ne va non consiste nel cambiare una password condivisa. Consiste nel disabilitare l'identità e revocare, negare o altrimenti rimuovere il diritto del certificato di autenticarsi. Il tuo progetto di convalida dei certificati e RADIUS deve essere in grado di riconoscere tale modifica quando un dispositivo si autentica. Non confondere la scadenza del certificato con la revoca del certificato. La scadenza è pianificata. La revoca è l'azione di offboarding che si intraprende prima della data di fine pianificata. La tempistica è fondamentale. L'accesso WiFi basato su certificati viene verificato al momento dell'autenticazione. Pertanto, il vostro obiettivo pratico è chiaro: impedire che il certificato abbia successo al successivo tentativo di autenticazione e testare tale risultato. Se il dipendente ha già una sessione attiva, decidete separatamente se la vostra policy richiede la disconnessione della sessione. Si tratta di una scelta di network-operations, non di un sostituto della revoca dell'identità. Considerate inoltre il comportamento di riconnessione rapida e le sessioni memorizzate nella cache durante il processo di progettazione e test. Un design che appare corretto in laboratorio può creare un punto cieco se il percorso di autenticazione in produzione non convalida la modifica come previsto. La checklist operativa per EAP-TLS è semplice. Primo, confermare il record d'identità della persona e l'ultimo orario di lavoro. Secondo, disabilitare l'identità di origine. Terzo, revocare o negare il certificato pertinente in base alla propria autorità di certificazione e al processo RADIUS. Quarto, rimuovere o terminare una sessione attiva se la policy lo richiede. Quinto, tentare una nuova connessione con il dispositivo gestito dell'ex dipendente o un equivalente controllato. Infine, conservare la richiesta, la modifica, il risultato, l'ora e il proprietario responsabile. Il secondo modello è iPSK. Invece di un'unica passphrase condivisa da tutta la forza lavoro, ogni persona o dispositivo ha una chiave distinta sulla stessa rete Staff WiFi. Questo rende la rimozione mirata. Eliminate la chiave associata alla persona che lascia l'azienda, verificate che un nuovo tentativo di associazione fallisca e lasciate invariate tutte le altre chiavi. iPSK può funzionare bene dove ci sono dispositivi che non possono utilizzare i certificati, dove un programma di dispositivi gestiti è ancora in fase di sviluppo o dove è necessario un passaggio pratico per abbandonare un'unica passphrase condivisa. iPSK non equivale a una password generica del personale con un nome diverso. La chiave deve essere legata a un'identità o a un record di dispositivo. Mantenete un inventario del proprietario della chiave, della data di rilascio, dell'associazione al dispositivo o alla persona, del ruolo di rete e dello stato di rimozione. Rendete la chiave sufficientemente distinta in modo che un evento di eliminazione possa essere ricondotto a chi lascia l'azienda. Se lo stesso iPSK viene riutilizzato da un team, da un gruppo di appaltatori o da un turno, avete ricreato il problema del segreto condiviso in un contenitore più piccolo. Il terzo modello è il deprovisioning guidato da SCIM. SCIM è un protocollo standard basato su HTTP per il provisioning e la gestione dei dati di identità tra i sistemi. In un buon processo di joiner-mover-leaver, le risorse umane o l'IT disabilitano l'account nel provider di identità, lo stato disabilitato passa al servizio di accesso WiFi e una successiva autenticazione WiFi viene negata. Purple collega l'accesso WiFi al provider di identità tramite SCIM. I provider di identità pertinenti sono Microsoft Entra ID, Okta e Google Workspace. Il vantaggio operativo non è una magia. Si tratta di un'unica fonte di verità: l'evento che pone fine al rapporto di lavoro avvia anche la rimozione del WiFi. Considerate lo SCIM come un percorso di controllo, non come uno slogan. Avete bisogno di un identificatore unico che mappi l'account dell'identity provider sul record di accesso WiFi. Avete bisogno di un evento di disattivazione concordato. Dovete sapere quale errore produce il servizio ricevente quando una richiesta di disattivazione fallisce. E avete bisogno di un'identità di test che dimostri che il vostro monitoraggio intercetta quel fallimento. Ora passate dal design all'implementazione. Iniziate con un inventario degli accessi. Elencate ogni rete WiFi del personale, la sua modalità di sicurezza, la sorgente di identità, il percorso RADIUS se presente, l'autorità di certificazione se presente, il record del proprietario iPSK se presente, la capacità di disconnessione della sessione e la destinazione dei log. Fatelo per gruppo di sedi, non come un'unica lista aziendale piatta. Un hotel, un negozio in centro e uno stadio possono condividere la policy pur utilizzando team operativi e hardware diversi. Successivamente, scegliete il controllo che elimina la maggior parte del lavoro manuale dal processo di offboarding. Per i dispositivi aziendali gestiti, utilizzate 802.1X con EAP-TLS laddove l'autorità di certificazione, la progettazione RADIUS e la gestione dei dispositivi possano supportarlo. Per parchi dispositivi misti e dispositivi che non possono utilizzare i certificati, utilizzate iPSK solo quando ogni chiave è di proprietà esclusiva ed è eliminabile. Per un parco dispositivi che utilizza già Microsoft Entra ID, Okta o Google Workspace, utilizzate il deprovisioning guidato da SCIM per fare in modo che la disattivazione dell'account sia il trigger per la rimozione del WiFi. Purple può collegare quell'evento di identità allo stato di accesso WiFi. Non aggiungete un secondo ticket manuale a meno che non si tratti di un percorso di eccezione. Costruite un runbook di offboarding in giornata. Le Risorse Umane confermano l'orario di fine rapporto. Il proprietario dell'identità disabilita l'account. Il proprietario della rete conferma che il relativo certificato, iPSK o record di accesso WiFi non è più valido. Le Operations decidono se una sessione attiva deve essere disconnessa. Un tester designato esegue un nuovo tentativo di autenticazione. Il caso si chiude solo quando il risultato viene registrato. Questo è deliberatamente poco affascinante. È anche la parte che un valutatore può ricostruire. Per le prove ISO 27001 o SOC 2, conservate una catena piccola ma completa: la richiesta di offboarding autorizzata, la modifica dell'identity provider, la modifica del WiFi, il risultato della verifica, i timestamp e il proprietario di ogni passaggio. Evitate di raccogliere più dati personali di quanti ne richieda il controllo. I record di accesso possono essere dati personali, quindi includeteli nelle vostre decisioni sulla conservazione e sul controllo degli accessi. Se il WiFi del personale può avere un impatto sui sistemi di pagamento, discutete l'ambito e la segmentazione con il team responsabile della PCI DSS invece di trattare la revoca del WiFi come una richiesta di conformità a sé stante. Prestate attenzione a quattro modalità di errore. Primo, una password condivisa è ancora in uso su un SSID trascurato. Secondo, il record WiFi è associato a un indirizzo email modificabile invece che a un'identità permanente. Terzo, un evento di disattivazione raggiunge l'identity provider ma non il servizio di accesso WiFi. Quarto, testate solo lo stato della dashboard e non un reale tentativo di nuovo accesso. Ciascuna modalità di errore è prevenibile se inventariate, monitorate e testate il controllo. Domande a raffica. È possibile revocare una password WPA2 condivisa per un solo dipendente che lascia l'azienda? No. È necessario reimpostarla per tutti o sostituirla con un controllo basato sulla singola identità. Con quale rapidità si può revocare un accesso EAP-TLS? Al successivo tentativo di autenticazione, a condizione che il certificato e il design di convalida RADIUS riconoscano la revoca. Il protocollo SCIM rimuove una sessione attiva? Non da solo. Il controllo della sessione va gestito come una decisione operativa a sé stante. La tecnologia iPSK è adatta a qualsiasi dispositivo? No. Si tratta di un modello pratico basato su chiavi associate all'identità, ideale quando l'autenticazione tramite certificato non è opportuna. Il passo successivo consiste in una rapida revisione del design. Scegliete una rete WiFi per lo staff. Seguite la procedura di uscita di un dipendente, dalla notifica delle Risorse Umane fino al rifiuto dell'autenticazione. Individuate il passaggio manuale. Quindi, eliminatelo. Una credenziale WiFi deve decadere nel momento stesso in cui il dipendente lascia l'azienda, non in occasione del successivo progetto di rotazione delle password.