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

Benvenuti al Purple Technical Briefing. Sono il vostro ospite e oggi affronteremo una delle lacune più comuni nell'offboarding aziendale: cosa succede effettivamente all'accesso WiFi quando un dipendente lascia l'azienda? Sembra semplice. Qualcuno consegna il badge, le risorse umane chiudono il suo account e si va avanti. Ma se la vostra rete funziona ancora con una password WPA2 condivisa, quella persona è uscita dalla porta conoscendo ancora la password. E a meno che non la cambiate per tutti, può riconnettersi dal parcheggio. Questo è il problema che risolveremo oggi. Esamineremo i tre modelli credibili per la revoca del WiFi per singolo utente, analizzeremo una checklist di revoca in giornata e spiegheremo esattamente cosa si aspetta di vedere nei vostri log un auditor ISO 27001 o SOC 2. Cominciamo. Sezione uno: perché le password condivise sono lo strumento sbagliato per questo lavoro. WPA2-Personal, la configurazione standard dei router domestici, utilizza una singola chiave precondivisa. Tutti sulla rete conoscono la stessa password. Quando una persona se ne va, quella password è ancora valida sul suo telefono, sul suo laptop, su qualsiasi dispositivo abbia mai connesso. L'unico modo per revocare il suo accesso è cambiare la password per l'intera rete e ridistribuirla a tutti gli utenti e dispositivi rimanenti. In un hotel con 200 dipendenti, ciò significa aggiornare ogni terminale POS, ogni PC del back-office, ogni telefono dei manager. In una catena di negozi con 50 punti vendita, significa un rollout coordinato in ogni sede. Il costo operativo è elevato, l'interruzione è reale e la finestra temporale tra l'ultimo giorno del dipendente uscente e il completamento della rotazione è una vera e propria falla di sicurezza. Il PCI DSS, lo standard del settore delle carte di pagamento, richiede di modificare le credenziali condivise ogni volta che il personale che le conosce lascia l'azienda. Quindi, se le vostre casse si trovano sulla stessa rete del WiFi dello staff, un dipendente uscente fa scattare un obbligo di conformità, non solo una raccomandazione sulle best practice. La causa principale è semplice: a una password condivisa non è associata alcuna identità. La rete non può distinguere tra un dipendente attuale e uno precedente. Per risolvere questo problema, sono necessarie credenziali per singolo utente. Sezione due: i tre modelli che funzionano davvero. Il primo modello è l'autenticazione basata su certificati 802.1X con EAP-TLS. Questo è il gold standard per la sicurezza WiFi aziendale. In questo modello, ogni utente o dispositivo possiede un certificato digitale univoco emesso dalla vostra Certificate Authority, o CA. Quando si connettono al WiFi, il server RADIUS convalida tale certificato crittograficamente. Il certificato è legato a un'identità, non a una password. Per revocare l'accesso, si revoca il certificato a livello di CA. Il server RADIUS verifica lo stato di revoca in tempo reale utilizzando l'OCSP, l'Online Certificate Status Protocol. Quando si contrassegna un certificato come revocato, la volta successiva che il dispositivo tenta di autenticarsi, il server RADIUS interroga il risponditore OCSP, riceve una risposta di revoca e invia un Access-Reject all'access point. Il dispositivo viene escluso dalla rete entro pochi secondi dal successivo tentativo di autenticazione. Per le sessioni attive, si utilizza il RADIUS Change of Authorisation, o CoA, per terminare immediatamente la sessione esistente. Insieme, OCSP e CoA consentono di revocare l'accesso WiFi a un dipendente uscente in meno di un minuto, con un audit trail completo nei log RADIUS. La sfida con EAP-TLS è il sovraccarico della PKI. È necessaria una Certificate Authority, un meccanismo per emettere certificati sui dispositivi, in genere tramite un MDM come Microsoft Intune, e un processo per revocarli. Per le organizzazioni con un'infrastruttura di identità e MDM matura, questa è la risposta giusta. Per i team più piccoli o gli ambienti con dispositivi IoT che non possono supportare l'autenticazione tramite certificato, è necessario un approccio diverso. Il secondo modello è iPSK, Identity Pre-Shared Key. Cisco lo chiama iPSK, Ruckus lo chiama DPSK, Aruba lo chiama MPSK, ma il concetto è lo stesso: ogni utente o dispositivo riceve una password univoca, anche se si connettono tutti allo stesso SSID. Il server RADIUS mappa ogni chiave univoca a un'identità specifica e, facoltativamente, a una VLAN specifica. Quando si elimina quella chiave dal database RADIUS, il dispositivo non può più autenticarsi. Il raggio d'impatto di un dipendente uscente è esattamente di una persona. Le chiavi di tutti gli altri rimangono valide. iPSK è particolarmente adatto ad ambienti con tipi di dispositivi misti. I dispositivi IoT, i terminali POS e l'hardware legacy che non supportano i certificati 802.1X possono tutti utilizzare iPSK. È anche più semplice da gestire rispetto a un'implementazione PKI completa, il che lo rende la scelta giusta per le organizzazioni del mid-market che necessitano di revoca per singolo utente senza il sovraccarico dell'infrastruttura. Il tempo di revoca per iPSK è in genere di pochi minuti, non secondi. L'eliminazione della chiave si propaga al server RADIUS, ma le sessioni attive possono persistere fino a quando il dispositivo non si autentica nuovamente o fino a quando non si invia un pacchetto CoA per forzare la disconnessione. Il terzo modello è il deprovisioning guidato da SCIM. SCIM sta per System for Cross-domain Identity Management. Si tratta di uno standard aperto, definito nelle RFC 7643 e RFC 7644, che consente al vostro identity provider di inviare eventi del ciclo di vita dell'utente ai sistemi a valle in tempo reale. Ecco come funziona in pratica. Il vostro identity provider, che si tratti di Microsoft Entra ID, Okta o Google Workspace, è la fonte autorevole di verità per gli account utente. Quando le risorse umane disabilitano l'account di un dipendente uscente nell'identity provider, SCIM invia una richiesta a ogni sistema connesso, inclusa la vostra piattaforma di gestione WiFi. Purple si connette al vostro identity provider tramite SCIM. Nel momento in cui disabilitate un utente in Entra ID, Okta o Google Workspace, Purple riceve l'evento SCIM e revoca le sue credenziali WiFi alla successiva autenticazione. L'evento viene registrato con un timestamp, l'identità dell'utente e l'azione intrapresa. Quella voce di log è esattamente ciò che un auditor ISO 27001 deve vedere. SCIM non sostituisce 802.1X o iPSK. Si posiziona al di sopra di essi. SCIM gestisce il ciclo di vita dell'identità; il protocollo di autenticazione gestisce l'applicazione di rete. La combinazione di SCIM più 802.1X offre una revoca automatica in tempo reale con un audit trail completo e zero passaggi manuali. Sezione tre: la checklist di revoca in giornata. Quando arriva l'ultimo giorno di un dipendente uscente, ecco la sequenza che il vostro team IT dovrebbe seguire. Fase uno: disabilitare l'account nell'identity provider. Questo è l'input per tutto il resto. In Microsoft Entra ID, impostare l'account su disabilitato. In Okta, disattivare l'utente. In Google Workspace, sospendere l'account. Fase due: se si utilizza SCIM, verificare che l'evento di deprovisioning sia stato attivato. Controllare i log SCIM o la piattaforma di gestione WiFi per l'evento corrispondente. Se SCIM non è attivo, revocare manualmente il certificato nella CA o eliminare la chiave iPSK dal database RADIUS. Fase tre: inviare un RADIUS CoA per terminare qualsiasi sessione WiFi attiva. La maggior parte dei server RADIUS aziendali e delle piattaforme come Purple può farlo automaticamente in caso di evento di deprovisioning. Se lo si fa manualmente, utilizzare l'interfaccia CoA del server RADIUS per disconnettere il dispositivo dell'utente tramite indirizzo MAC o ID sessione. Fase quattro: confermare che non rimangano sessioni attive. Controllare la dashboard del controller WiFi. Su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet, dovrebbe essere possibile cercare per nome utente o dispositivo e confermare l'assenza di associazioni attive. Fase cinque: archiviare la voce del log di audit. Esportare o contrassegnare il log di autenticazione RADIUS, il log degli eventi SCIM e il log CoA per l'utente e la data pertinenti. Memorizzarli nella piattaforma ITSM o SIEM (security information and event management). Il controllo A.9.2.6 dell'Appendice A di ISO 27001 richiede di rimuovere o modificare i diritti di accesso di tutti i dipendenti e collaboratori al momento della cessazione del rapporto. Il log è la prova. Fase sei: se si utilizza WPA2 PSK condiviso e nessuna delle opzioni precedenti è applicabile, ruotare la password. Coordinare il rollout su tutte le sedi e i dispositivi prima dell'ultimo giorno del dipendente uscente, se possibile, o subito dopo. Sezione quattro: cosa si aspetta l'auditor. Sia ISO 27001 sia SOC 2 richiedono di dimostrare che l'accesso venga rimosso tempestivamente al termine del rapporto di lavoro. Per il WiFi in particolare, gli auditor cercano quattro elementi. Primo, una procedura di offboarding documentata che includa esplicitamente l'accesso alla rete. Secondo, la prova che la procedura sia stata seguita per un campione di dipendenti uscenti, in genere da dieci a venticinque persone selezionate negli ultimi dodici mesi. Terzo, un log che mostri il timestamp di disabilitazione dell'account e il timestamp di revoca dell'accesso WiFi, con l'intervallo tra i due chiaramente visibile. Quarto, la conferma che nessun account di ex dipendenti mostri sessioni WiFi attive. Se si utilizza WPA2 PSK condiviso, non è possibile produrre prove per i punti tre e quattro. Non esiste un log per singolo utente. Il meglio che si possa fare è mostrare la data di rotazione della password e sostenere che sia stata completata prima o durante l'ultimo giorno del dipendente uscente. Gli auditor rifiutano sempre più spesso questa argomentazione. Se si utilizza 802.1X con SCIM, il log è automatic. Purple registra ogni evento di deprovisioning SCIM con un timestamp UTC, la sorgente dell'identity provider, l'identificatore univoco dell'utente e l'azione risultante. Questo è un record pulito e verificabile. Sezione cinque: errori di implementazione e come evitarli. L'errore più comune è presumere che disabilitare un account nell'identity provider sia sufficiente. Non lo è, a meno che la vostra piattaforma WiFi non sia connessa a quell'identity provider tramite SCIM o un'integrazione simile in tempo reale. Senza tale connessione, il sistema WiFi non ha modo di sapere che l'account è stato disabilitato. Il secondo errore è la memorizzazione in cache dei certificati. Anche con OCSP, i server RADIUS memorizzano in cache le risposte positive per un periodo configurabile, in genere da 15 a 60 minuti. Se si revoca un certificato e il server RADIUS ha una risposta positiva in cache, il dispositivo potrebbe continuare ad autenticarsi fino alla scadenza della cache. Impostare il TTL della cache OCSP a 15 minuti o meno per ambienti ad alta sicurezza. Il terzo errore è dimenticare le sessioni attive. La revoca delle credenziali impedisce nuove autenticazioni ma non termina una sessione WiFi esistente. Inviare sempre un RADIUS CoA dopo aver revocato le credenziali per disconnettere immediatamente il dispositivo. Il quarto errore riguarda i dispositivi IoT e condivisi. Un dispositivo registrato con l'identità di un dipendente uscente potrebbe essere una workstation condivisa o un componente hardware operativo. Prima di procedere alla revoca, verificare che il dispositivo sia personale e non condiviso. Se è condiviso, registrarlo nuovamente con un account di servizio prima di revocare le credenziali del dipendente uscente. Sezione sei: domande rapide. Domanda: quanto velocemente si può revocare l'accesso WiFi basato su certificati? Con OCSP e RADIUS CoA, in meno di 60 secondi dal momento in cui si revoca il certificato presso la CA. Il controllo OCSP avviene al successivo tentativo di autenticazione. Il CoA termina immediatamente la sessione attiva. Domanda: SCIM funziona con tutto l'hardware WiFi? SCIM opera a livello di gestione delle identità, non a livello hardware. Purple è indipendente dall'hardware e funziona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. L'integrazione SCIM avviene con Purple, non direttamente con gli access points. Domanda: cosa succede se non abbiamo un MDM e non possiamo distribuire certificati? iPSK è la risposta. Offre la revoca per singolo utente senza richiedere un'infrastruttura di certificati. Purple può gestire le chiavi iPSK e connettersi al vostro identity provider per automatizzare il ciclo di vita. Riepilogo e passaggi successivi. Il messaggio fondamentale è questo: se non potete revocare l'accesso WiFi a una persona senza influire su tutti gli altri, avete un problema di credenziali condivise. La soluzione consiste in credenziali per singolo utente, ovvero certificati tramite 802.1X EAP-TLS o chiavi univoche tramite iPSK, combinati con il deprovisioning guidato da SCIM per automatizzare la revoca nel momento stesso in cui intervengono le risorse umane. Purple si connette a Microsoft Entra ID, Okta e Google Workspace tramite SCIM, opera in oltre 80.000 sedi attive e registra ogni evento di deprovisioning per scopi di audit. Se vi state preparando per ISO 27001 o SOC 2, o semplicemente volete colmare la lacuna dei dipendenti uscenti prima che si trasformi in un incidente, questo è il punto di partenza. Per l'analisi tecnica completa della revoca dei certificati e di OCSP, consultate la nostra guida su OCSP e revoca dei certificati per l'autenticazione WiFi. Per una panoramica più ampia sull'automazione joiner-mover-leaver, consultate la nostra guida sulla sicurezza WiFi aziendale. Grazie per aver ascoltato il Purple Technical Briefing.