Che cos'è un supplicant 802.1X? Tipi di client e configurazione dei dispositivi

Parla in inglese britannico con un tono fiducioso, autorevole e colloquiale - come un consulente senior per la sicurezza di rete che fa un briefing a un cliente. Ritmo misurato, dizione chiara, professionale ma non rigido. Pause naturali occasionali per dare enfasi: Benvenuti nella serie di briefing tecnici Purple. Oggi parleremo di qualcosa che si trova proprio al centro della sicurezza WiFi aziendale - il supplicant 802.1X. Se vi siete mai chiesti perché alcuni dispositivi si connettono alla vostra rete aziendale senza richiedere una password, mentre altri mostrano errori di certificato e generano ticket di assistenza, questo è l'episodio che fa per voi. [pausa media] Iniziamo con le basi. Il supplicant 802.1X è il componente software su un dispositivo client - un laptop, uno smartphone, un tablet - che gestisce l'handshake di autenticazione quando quel dispositivo tenta di accedere a una rete protetta da IEEE 802.1X. Pensatelo come il presentatore della carta d'identità del dispositivo. La rete non fa entrare chiunque. Chiede le credenziali. Il supplicant è ciò che si fa avanti e dice: ecco chi sono, ecco il mio certificato, lasciami entrare. Lo standard stesso - IEEE 802.1X - definisce il controllo dell'accesso alla rete basato su porta. Prima che l'autenticazione vada a buon fine, l'access point o lo switch consente il passaggio solo di un tipo di traffico molto limitato: i frame EAPOL, che sta per Extensible Authentication Protocol over LAN. Tutto il resto viene bloccato. Una volta che il supplicant dimostra la propria identità al server RADIUS tramite l'autenticatore, la porta si apre e il traffico normale inizia a fluire. [pausa media] Ora, ci sono tre attori in questo scenario. Primo, il supplicant - il dispositivo client. Secondo, l'autenticatore - il vostro access point o switch, hardware come Cisco Meraki, HPE Aruba, Ruckus o Juniper Mist. Terzo, il server di autenticazione - quasi sempre un server RADIUS, che convalida le credenziali rispetto a una directory come Microsoft Entra ID o Okta. Il supplicant avvia il processo inviando un messaggio EAPOL-Start. L'autenticatore risponde con una richiesta EAP-Request di identità. Il supplicant risponde con la propria identità. Tale identità viene inoltrata al server RADIUS, che quindi sfida il supplicant con il metodo EAP concordato. Se tutto è in regola, il server RADIUS invia un Access-Accept, la porta si apre e il dispositivo viene inserito nella VLAN corretta. [pausa media] Parliamo dei metodi EAP, perché è qui che viene presa la maggior parte delle decisioni di implementazione. EAP-TLS - ovvero Extensible Authentication Protocol con Transport Layer Security - rappresenta lo standard di riferimento. Richiede che sia il client che il server presentino dei certificati. Autenticazione reciproca. Nessuna password. Il certificato del client dimostra l'identità del dispositivo; il certificato del server dimostra che la rete è legittima, proteggendo dagli attacchi evil twin in cui un access point non autorizzato tenta di sottrarre le credenziali. EAP-TLS si completa in dodici passaggi e utilizza costantemente la crittografia a chiave pubblica-privata. È il metodo richiesto per WPA3-Enterprise nella sua modalità di sicurezza più elevata e si allinea ai requisiti NIST SP 800-171 per la verifica dell'identità dei dispositivi. PEAP - Protected EAP - è il punto di partenza più comune per le organizzazioni che non dispongono ancora di una PKI completa. PEAP racchiude un metodo interno basato su password, tipicamente MSCHAPv2, all'interno di un tunnel TLS. Il server presenta un certificato; il client no. Ciò significa che l'implementazione è più semplice - non è necessario distribuire certificati client - ma è meno sicura. MSCHAPv2 utilizza l'hashing MD4, considerato compromesso dal 1995. Se un utente si connette a un access point non autorizzato che presenta un certificato apparentemente affidabile, le sue credenziali possono essere intercettate. La convalida del certificato del server sul lato client è quindi non negoziabile quando si esegue PEAP. [medium pause] Ora passiamo al supplicant vero e proprio - in particolare alla scelta tra i supplicant nativi del sistema operativo e i software client di terze parti. Ogni sistema operativo principale viene fornito con un supplicant 802.1X integrato. Windows lo supporta nativamente fin dai tempi di XP, tramite i servizi Configurazione automatica WLAN e Configurazione automatica reti cablate. macOS e iOS gestiscono lo standard 802.1X tramite i loro profili di configurazione di rete. Android lo supporta attraverso il pannello delle impostazioni WiFi. Questi supplicant nativi coprono EAP-TLS e PEAP-MSCHAPv2 su tutte le piattaforme attuali. Il vantaggio dei supplicant nativi è ovvio: nessun software aggiuntivo da distribuire, nessun costo di licenza, aggiornamenti di sicurezza automatici del sistema operativo e una stretta integrazione con l'archivio dei certificati del sistema operativo. Per i parchi dispositivi gestiti - macchine Windows registrate in Microsoft Intune, Mac gestiti tramite Jamf - è possibile inviare i profili di configurazione 802.1X in modo invisibile tramite MDM, senza che gli utenti visualizzino mai alcuna richiesta. Il dispositivo si autentica automaticamente ogni volta che entra nel raggio di copertura. I supplicanti di terze parti entrano in gioco in scenari specifici. Se utilizzi un'infrastruttura Cisco e desideri utilizzare EAP-FAST - il metodo EAP proprietario di Cisco - è necessario il software client di Cisco, storicamente Secure Services Client o AnyConnect Network Access Manager. Se hai bisogno di una gestione coerente della configurazione in un parco macchine con sistemi operativi misti e desideri bloccare le impostazioni del supplicante in modo che gli utenti non possano accidentalmente configurarle in modo errato, un client di terze parti ti offre tale controllo. Strumenti come la suite JoinNow di SecureW2 fungono anche da agenti di onboarding - configurano il supplicante nativo anziché sostituirlo, guidando gli utenti attraverso la registrazione dei certificati e l'installazione dei profili. [medium pause] Permettimi di illustrarti due scenari reali per rendere tutto questo concreto. Primo, un hotel da 400 camere. La struttura gestisce attualmente una rete per il personale su WPA2-Enterprise con PEAP-MSCHAPv2. Il team IT desidera migrare a EAP-TLS per eliminare l'autenticazione basata su password e ridurre il rischio di furto di credenziali. La sfida: i dispositivi del personale sono un mix di laptop Windows gestiti tramite Intune, telefoni personali Android utilizzati per il software di gestione della struttura e una manciata di vecchi computer Windows 7 nel back office. L'approccio qui è graduale. Inizia con la flotta Windows gestita. Distribuisci un profilo di configurazione Intune che installa il certificato CA radice del server RADIUS, configura il profilo WiFi per EAP-TLS e avvia la registrazione dei certificati basata su SCEP dalla PKI interna. Tali dispositivi si autenticano automaticamente fin dal primo giorno. Per i dispositivi BYOD Android, distribuisci un portale di onboarding self-service - gli utenti visitano un URL, scaricano un profilo di configurazione e il supplicante viene configurato per loro. I vecchi computer Windows 7 rimangono su PEAP con una rigorosa convalida del certificato del server applicata, isolati in una VLAN separata con accesso limitato, fino alla loro dismissione. [medium pause] Secondo scenario: una grande catena di vendita al dettaglio con 200 negozi. Ogni negozio ha un mix di terminali point-of-sale, tablet del personale e una rete WiFi per gli ospiti. Lo standard PCI-DSS richiede che gli ambienti con dati dei titolari di carta siano isolati dagli altri segmenti di rete. Il rivenditore utilizza 802.1X sulle reti del personale e POS, con l'assegnazione della VLAN guidata dagli attributi dei certificati. Un terminale POS presenta un certificato del dispositivo con un'unità organizzativa pari a "POS" - la policy RADIUS lo assegna alla VLAN PCI. Un tablet del personale presenta un certificato con "Staff" - e finisce sulla VLAN del personale. I dispositivi degli ospiti si connettono a un SSID completamente separato, gestito da una soluzione di Captive Portal. La configurazione del supplicante sui terminali POS è bloccata tramite MDM. Non è richiesta alcuna interazione da parte dell'utente. I terminali si autenticano in modo trasparente all'avvio. Il rinnovo dei certificati è automatizzato tramite SCEP, quindi non vi è alcun intervento manuale alla scadenza dei certificati. [medium pause] Ora, gli errori di implementazione più comuni. Permettimi di elencarti i quattro più frequenti. Numero uno: mancanza di validazione del certificato del server sulle implementazioni PEAP. Se non configuri il supplicant per validare il certificato del server RADIUS e verificare il nome del server, gli utenti sono vulnerabili alla connessione a un access point canaglia. Specifica sempre la CA radice attendibile e il nome del server nel profilo del supplicant. Numero due: la scadenza dei certificati che causa errori di autenticazione di massa. I certificati client hanno un periodo di validità. Se non disponi di un rinnovo automatizzato tramite SCEP o NDES, ti scontrerai con un evento critico in cui centinaia di dispositivi smetteranno di autenticarsi contemporaneamente. Configura l'automazione del rinnovo prima di andare online. Numero tre: dispositivi BYOD con comportamento del supplicant incoerente. Android in particolare presenta un supporto 802.1X frammentato tra i vari produttori. Alcune versioni richiedono che l'utente installi manualmente il certificato CA prima che il profilo WiFi lo accetti. Un portale di onboarding che gestisce questo passaggio riduce notevolmente il volume di richieste all'helpdesk. Numero quattro: gli aggiornamenti delle funzionalità di Windows 11 che interrompono la configurazione del supplicant. Microsoft ha modificato il comportamento di 802.1X in diversi aggiornamenti di Windows 11. Nello specifico, l'aggiornamento 24H2 ha introdotto modifiche al modo in cui il supplicant nativo gestisce il fallback EAP-TLS. Testa i profili del tuo supplicant con le nuove versioni del sistema operativo prima di distribuirli in produzione. [medium pause] Ora passiamo a domande a risposta rapida. I dispositivi IoT possono supportare 802.1X? La maggior parte no. I dispositivi IoT in genere sono del tutto privi di un supplicant. L'alternativa è il MAC Authentication Bypass - MAB - in cui il server RADIUS autentica il dispositivo in base al suo indirizzo MAC. Gli indirizzi MAC possono essere spoofati, quindi i dispositivi MAB dovrebbero sempre essere inseriti in una VLAN IoT isolata con regole di firewall restrittive. Ho bisogno di una PKI per eseguire 802.1X? Per PEAP no - hai solo bisogno di un certificato server sul server RADIUS. Per EAP-TLS sì - hai bisogno di una PKI per emettere certificati client. I servizi PKI basati su cloud riducono notevolmente i costi operativi dell'infrastruttura. In che modo 802.1X interagisce con la piattaforma di accesso alla rete di Purple? Purple opera come un overlay cloud sopra l'hardware esistente - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist e altri. Sulle reti WiFi del personale, l'add-on SecurePass di Purple si integra con il tuo provider di identità - Microsoft Entra ID, Okta o Google Workspace - per applicare l'autenticazione 802.1X e applicare criteri VLAN per utente senza richiedere un'infrastruttura RADIUS locale. [medium pause] Per concludere: il supplicant 802.1X è l'agente lato dispositivo che consente il funzionamento del controllo dell'accesso alla rete basato su porta. La scelta del metodo EAP - EAP-TLS per la massima sicurezza, PEAP come opzione di transizione - determina i requisiti della PKI e l'approccio alla configurazione del supplicant. I supplicant nativi del sistema operativo coprono la maggior parte degli scenari di dispositivi gestiti quando distribuiti tramite MDM. I client di terze parti aggiungono valore in casi specifici: metodi EAP proprietari, parchi macchine con sistemi operativi misti che richiedono una configurazione coerente o onboarding BYOD self-service. I tre aspetti principali da ricordare: convalidare il certificato del server RADIUS su ogni profilo di supplicant, automatizzare il rinnovo dei certificati prima di implementare EAP-TLS su larga scala e isolare i dispositivi che non possono supportare l'802.1X - IoT, hardware legacy - su VLAN dedicate con MAC Authentication Bypass come soluzione di riserva. Per saperne di più su come Purple si integra con la vostra architettura di controllo degli accessi alla rete, visitate purple.ai. Grazie per l'ascolto.