Come implementare l'autenticazione 802.1X con Cloud RADIUS

Come implementare l'autenticazione 802.1X con Cloud RADIUS Un briefing informativo di Purple WiFi --- INTRODUZIONE E CONTESTO (circa 1 minuto) --- Benvenuti al briefing informativo di Purple WiFi. Sono il vostro ospite e oggi entreremo nei dettagli dell'autenticazione 802.1X con Cloud RADIUS: cos'è, perché è importante in questo momento e come implementarla concretamente in un'infrastruttura multi-sito. Se gestite l'infrastruttura WiFi per un gruppo alberghiero, una catena di negozi, uno stadio o un'organizzazione del settore pubblico, questo è uno di quegli argomenti che continuano a presentarsi, e per una buona ragione. Lo scenario delle minacce è cambiato. Le reti PSK condivise sono sempre più viste come una responsabilità di conformità, non solo come un inconveniente per la sicurezza. Autorità di regolamentazione, auditor e assicuratori informatici pongono domande sempre più difficili sul controllo degli accessi alla rete. E la buona notizia è che il RADIUS fornito via cloud ha reso l'802.1X realmente implementabile su scala, senza i costi dell'infrastruttura on-premises che in passato lo rendevano impraticabile per le sedi distribuite. Quindi, entriamo nel vivo dell'argomento. --- APPROFONDIMENTO TECNICO (circa 5 minuti) --- Innanzitutto, assicuriamoci di partire tutti dalla stessa definizione. Lo standard IEEE 802.1X è uno standard di controllo degli accessi alla rete basato su porta. Definisce un framework di autenticazione che si colloca al livello 2 del modello OSI, quindi opera prima che a un dispositivo venga concessa qualsiasi connettività IP. Questa è la distinzione fondamentale rispetto all'autenticazione a livello applicativo. Con l'802.1X, un dispositivo non può accedere alla rete finché non è stato autenticato positivamente. Il protocollo è composto da tre elementi. Il supplicant: il dispositivo finale, che si tratti di un laptop, di uno smartphone o di un terminale POS. L'authenticator: in genere l'access point WiFi o lo switch gestito. E il server di autenticazione: che nelle implementazioni moderne è il servizio Cloud RADIUS. Il flusso funziona in questo modo. Un dispositivo tenta di associarsi a un access point. L'access point non concede immediatamente l'accesso completo alla rete. Al contrario, apre una porta controllata e avvia uno scambio EAP (Extensible Authentication Protocol) con il dispositivo. Il dispositivo presenta le proprie credenziali, che potrebbero essere un nome utente e una password, un certificato digitale o un'identità basata su SIM. L'access point trasmette lo scambio al server RADIUS utilizzando il protocollo RADIUS su UDP, in genere sulla porta 1812 per l'autenticazione e 1813 per l'accounting. Il server RADIUS convalida le credenziali rispetto a un archivio di identità (Active Directory, Azure AD o una directory LDAP) e restituisce un messaggio di Access-Accept o Access-Reject. Se accettato, l'access point apre la porta e il dispositivo ottiene l'accesso alla rete. Se rifiutato, rimane bloccato. Semplice in linea di principio, ma i dettagli di implementazione contano enormemente. La selezione del metodo EAP è il punto in cui molte implementazioni falliscono. Esistono diversi metodi EAP comunemente utilizzati, con profili di sicurezza e requisiti operativi molto diversi. EAP-TLS rappresenta lo standard di riferimento. Richiede l'autenticazione reciproca dei certificati: sia il server che il client presentano un certificato. Ciò elimina completamente il rischio di furto di credenziali, perché non ci sono password da rubare. Richiede tuttavia un'infrastruttura PKI e un meccanismo per distribuire i certificati client ai dispositivi, il che in genere comporta una soluzione MDM. Per gli ambienti BYOD aziendali e le implementazioni ad alta sicurezza, questa è la risposta corretta. PEAP con MSCHAPv2 è il metodo più diffuso negli ambienti aziendali. Richiede solo un certificato lato server e incapsula lo scambio di credenziali all'interno di un tunnel TLS. È compatibile nativamente con Active Directory, il che lo rende semplice dal punto di vista operativo. Il rischio è che sia vulnerabile alla raccolta di credenziali se gli utenti si connettono a un access point non autorizzato con un certificato autofirmato; pertanto, la convalida del certificato sul lato client non è negoziabile. EAP-TTLS è simile a PEAP ma più flessibile nel metodo di autenticazione interno. È particolarmente utile in ambienti con dispositivi misti in cui si ha una combinazione di dispositivi Windows, macOS, iOS e Android con diverse funzionalità di supplicant. Per il supporto dei dispositivi legacy, come i vecchi hardware POS o i sensori IoT, EAP-FAST può essere una scelta pragmatica, in quanto non richiede certificati e utilizza invece una Protected Access Credential. Ora, passiamo alla parte relativa a Cloud RADIUS. Tradizionalmente, RADIUS era un servizio on-premises: FreeRADIUS su un server Linux o Microsoft NPS su Windows Server. Questo modello funziona, ma comporta costi operativi reali: manutenzione dell'hardware, configurazione dell'alta affidabilità, patch e necessità di un'infrastruttura locale in ogni sede che richieda un'autenticazione a bassa latenza. Cloud RADIUS cambia notevolmente questo calcolo. Un servizio Cloud RADIUS è ospitato e gestito dal provider. I vostri access point inviano richieste RADIUS su Internet al servizio cloud, che gestisce l'autenticazione rispetto al vostro identity provider. Il problema della latenza è reale ma gestibile: i moderni servizi Cloud RADIUS sono distribuiti a livello globale e i cicli di autenticazione si completano in genere in meno di 100 millisecondi, un tempo impercettibile per gli utenti finali. L'integrazione con gli identity provider è la dipendenza critica. La maggior parte delle piattaforme Cloud RADIUS supporta LDAP, LDAPS, SAML 2.0 e l'integrazione diretta con Azure AD o Okta. For organizations already running Microsoft 365, l'integrazione con Azure AD è il percorso naturale: si ottengono single sign-on, criteri di accesso condizionale e applicazione dell'MFA, tutti elementi che alimentano il livello di controllo degli accessi alla rete. Per le strutture che implementano il WiFi per gli ospiti insieme alle reti del personale, l'architettura in genere separa queste ultime in SSID distinti con criteri di autenticazione diversi. Le reti del personale utilizzano 802.1X con credenziali aziendali. Le reti degli ospiti utilizzano un Captive Portal o un flusso di accesso social. La piattaforma di Purple supporta entrambi i modelli e il livello di analisi WiFi si colloca su entrambi, offrendo visibilità sul comportamento dei dispositivi, sul tempo di permanenza e sull'utilizzo della rete senza compromettere la segmentazione della sicurezza. --- RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE (circa 2 minuti) --- Permettetemi di fornirvi la sequenza pratica di implementazione e di segnalare gli errori che vedo più spesso. Iniziate con l'integrazione del vostro identity provider. Prima di toccare un singolo access point, verificate che il servizio Cloud RADIUS sia in grado di autenticarsi rispetto alla vostra directory. Eseguite un test con un account di servizio, convalidate il bind LDAP e verificate che gli attributi di appartenenza al gruppo vengano restituiti correttamente, poiché ne avrete bisogno per i criteri di assegnazione delle VLAN. In secondo luogo, pianificate la strategia dei certificati. Se scegliete EAP-TLS, avete bisogno di una CA, dovete decidere se utilizzare una CA pubblica o interna e avete bisogno di un piano di implementazione MDM per i certificati client. Se scegliete PEAP, avete bisogno di un certificato server emesso da una CA attendibile (non autofirmato) e dovete distribuire il certificato della CA a tutti i dispositivi client in modo che la convalida del certificato funzioni correttamente. Questo è il passaggio che spesso viene saltato e che causa incidenti di sicurezza. In terzo luogo, configurate i client RADIUS (ovvero gli access point e i controller) con il segreto condiviso corretto e l'IP o l'hostname del server. Utilizzate un segreto condiviso forte, generato in modo casuale, non una parola del dizionario. E se il vostro provider Cloud RADIUS supporta RADIUS su TLS (RadSec), utilizzatelo. Crittografa il traffico RADIUS in transito, il che è particolarmente importante quando tale traffico attraversa la rete internet pubblica. In quarto luogo, eseguite un test con un gruppo pilota prima dell'implementazione completa. I fallimenti di autenticazione su larga scala sono dirompenti e difficili da diagnosticare sotto pressione. Eseguite un progetto pilota con un numero compreso tra dieci e venti dispositivi, convalidate i log di autenticazione, verificate che l'assegnazione delle VLAN funzioni e controllate che i record di accounting vengano scritti correttamente. Gli errori che vedo più spesso: convalida del certificato disabilitata sui client, con conseguente vulnerabilità man-in-the-middle. Segreti condivisi troppo brevi o riutilizzati in più sedi. Consent-list degli IP del server RADIUS non configurata, per cui le richieste di autenticazione provenienti da nuove sedi vengono scartate silenziosamente. E profili MDM non aggiornati alla scadenza dei certificati, con conseguenti errori di autenticazione di massa il giorno del rinnovo. --- DOMANDE E RISPOSTE RAPIDE (circa 1 minuto) --- Alcune domande che mi vengono poste regolarmente. Posso eseguire l'802.1X su una rete che presenta anche dispositivi IoT che non supportano l'EAP? Sì, utilizzate il MAC Authentication Bypass come fallback per i dispositivi che non possono eseguire un supplicant, ma inserite tali dispositivi su una VLAN limitata con regole di firewall rigide. L'802.1X sostituisce la crittografia WPA2 o WPA3? No, l'802.1X gestisce l'autenticazione. WPA2-Enterprise o WPA3-Enterprise gestisce la crittografia. Sono necessari entrambi. WPA3-Enterprise con 802.1X rappresenta l'attuale best practice per le nuove implementazioni. Qual è l'impatto della latenza sull'autenticazione? Con un servizio Cloud RADIUS ben configurato, prevedete da 50 a 150 millisecondi per autenticazione. Per gli scenari di roaming, la transizione BSS rapida 802.11r può ridurre significativamente i tempi di riautenticazione. Questo sistema è conforme allo standard PCI DSS? L'802.1X con EAP-TLS o PEAP su una rete correttamente segmentata soddisfa i requisiti 1 e 8 del PCI DSS per il controllo degli accessi alla rete. Coinvolgete presto il vostro QSA. --- SINTESI E PROSSIMI PASSI (circa 1 minuto) --- Per riassumere: l'802.1X con Cloud RADIUS è la risposta corretta per qualsiasi organizzazione che debba dimostrare il controllo degli accessi alla rete agli auditor, ridurre l'area di impatto di una compromissione delle credenziali o gestire l'autenticazione in modo centralizzato in un'infrastruttura distribuita. L'implementazione non è banale, ma è assolutamente gestibile con la giusta preparazione. Ottenete prima di tutto l'integrazione corretta del vostro identity provider. Scegliete il metodo EAP in base al parco dispositivi e alla vostra capacità operativa di gestire i certificati. Utilizzate RadSec se la vostra infrastruttura lo supporta. E fate dei test prima di procedere all'implementazione su larga scala. Se gestite una rete mista per ospiti e personale, come fa la maggior parte degli operatori del settore alberghiero e retail, piattaforme come Purple vi offrono la possibilità di gestire entrambi i modelli di autenticazione da un'unica interfaccia, con il livello di analisi esteso a tutta l'infrastruttura. Per i prossimi passi: verificate lo stato attuale del controllo degli accessi alla rete, identificate quali sedi utilizzano ancora PSK condivise e create un piano di migrazione graduale. Iniziate con i siti a più alto rischio, quelli che rientrano nell'ambito del PCI DSS o che gestiscono dati sensibili, e procedete verso l'esterno. Grazie per l'ascolto. Ulteriori briefing tecnici sono disponibili su purple.ai.