Cos'è un Supplicant 802.1X? Tipi di Client e Configurazione dei Dispositivi

Speak in British English with a confident, authoritative, conversational tone - like a senior network security consultant briefing a client. Measured pace, clear diction, professional but not stiff. Occasional natural pauses for emphasis: Benvenuti nella serie di briefing tecnici di Purple. Oggi parleremo di un elemento 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 rete aziendale senza richiedere una password, mentre altri generano errori di certificato e ticket di assistenza, questa è la puntata che fa per voi. [medium pause] Iniziamo con le basi. Il supplicant 802.1X è il componente software presente su un dispositivo client (un laptop, uno smartphone, un tablet) che gestisce l'handshake di autenticazione quando il 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, fammi 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 consentono il passaggio 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. [medium pause] 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 confrontandole con 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. [medium pause] Parliamo dei metodi EAP, perché è qui che viene presa la maggior parte delle decisioni di deployment. EAP-TLS, ovvero Extensible Authentication Protocol con Transport Layer Security, rappresenta il gold standard. Richiede che sia il client sia il server presentino dei certificati. Autenticazione reciproca. Nessuna password. Il certificato client dimostra l'identità del dispositivo; il certificato server dimostra la legittimità della rete, offrendo protezione contro gli attacchi evil twin, in cui un access point malevolo tenta di sottrarre credenziali. EAP-TLS si completa in dodici passaggi e utilizza la crittografia a chiave pubblica-privata durante l'intero processo. È 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, in genere MSCHAPv2, all'interno di un tunnel TLS. Il server presenta un certificato, mentre il client no. Di conseguenza, l'implementazione è più semplice (non è necessario distribuire certificati client), ma è meno sicura. MSCHAPv2 utilizza l'hashing MD4, considerato compromesso fin dal 1995. Se un utente si connette a un access point malevolo che presenta un certificato dall'aspetto attendibile, le sue credenziali possono essere intercettate. La validazione del certificato server sul lato client è quindi imprescindibile quando si utilizza PEAP. [medium pause] Passiamo ora 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 da XP, tramite i servizi Configurazione automatica reti cablate e Configurazione automatica WLAN. macOS e iOS gestiscono 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 è evidente: nessun software aggiuntivo da distribuire, nessun costo di licenza, aggiornamenti di sicurezza automatici del sistema operativo e stretta integrazione con l'archivio 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 silente tramite MDM, senza che gli utenti visualizzino alcuna richiesta. Il dispositivo si autentica automaticamente ogni volta che entra nel raggio di copertura. I supplicant 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, hai bisogno del software client di Cisco, storicamente il 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 supplicant in modo che gli utenti non possano configurarle erroneamente per errore, un client di terze parti ti offre tale controllo. Strumenti come la suite JoinNow di SecureW2 fungono anche da agenti di onboarding: configurano il supplicant nativo anziché sostituirlo, guidando gli utenti attraverso la registrazione dei certificati e l'installazione dei profili. [medium pause] Permettimi di illustrarti due scenari del mondo reale per rendere questo concetto concreto. Innanzitutto, un hotel da 400 camere. Oggi la struttura gestisce 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 macchine legacy Windows 7 nel back-of-house. L'approccio qui è graduale. Inizia con la flotta Windows gestita. Distribuisci un profilo di configurazione Intune che installi il certificato CA radice del server RADIUS, configuri il profilo WiFi per EAP-TLS e avvii la registrazione del certificato basata su SCEP dalla PKI interna. Tali dispositivi si autenticano automaticamente fin dal primo giorno. Per i dispositivi Android BYOD, distribuisci un portale di onboarding self-service: gli utenti visitano un URL, scaricano un profilo di configurazione e il supplicant viene configurato per loro. Le macchine legacy Windows 7 rimangono su PEAP con una rigorosa convalida del certificato del server applicata, isolate 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 POS, tablet del personale e una rete WiFi per gli ospiti. Il PCI DSS richiede che gli ambienti dei dati dei titolari di carta siano isolati da altri segmenti di rete. Il rivenditore utilizza l'802.1X sulle reti del personale e POS, con l'assegnazione della VLAN guidata dagli attributi del certificato. 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" - 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 supplicant sui terminali POS è bloccata tramite MDM. Nessuna interazione da parte dell'utente richiesta. I terminali si autenticano silenziosamente all'avvio. Il rinnovo del certificato è automatizzato tramite SCEP, quindi non vi è alcun intervento manuale alla scadenza dei certificati. [medium pause] Ora, le trappole dell'implementazione. Lascia che ti illustri le quattro più comuni. Numero uno: validazione del certificato del server mancante nelle distribuzioni PEAP. Se non si configura il supplicant per convalidare il certificato del server RADIUS e verificare il nome del server, gli utenti sono vulnerabili alla connessione a un access point fittizio. Specificare 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 si dispone di un rinnovo automatico tramite SCEP o NDES, si andrà incontro a un evento critico in cui centina extinction di dispositivi smetteranno di autenticarsi simultaneamente. Configurare 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 significativamente 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. Testare i profili del supplicant con le nuove versioni del sistema operativo prima di distribuirli in produzione. [medium pause] Ora passiamo alle domande rapide. I dispositivi IoT possono supportare l'802.1X? La maggior parte no. I dispositivi IoT in genere sono 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 contraffatti, quindi i dispositivi MAB dovrebbero sempre essere inseriti in una VLAN IoT isolata con regole firewall rigorose. Ho bisogno di una PKI per eseguire l'802.1X? Per PEAP, no: è necessario solo un certificato server sul server RADIUS. Per EAP-TLS, sì: è necessaria una PKI per emettere i certificati client. I servizi PKI basati su cloud riducono notevolmente i costi operativi dell'infrastruttura. In che modo l'802.1X interagisce con la piattaforma di accesso alla rete di Purple? Purple funziona 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 provider di identità (Microsoft Entra ID, Okta o Google Workspace) per applicare l'autenticazione 802.1X e le policy VLAN per singolo utente senza richiedere un'infrastruttura RADIUS on-premises. [medium pause] Per riassumere: 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 PKI e l'approccio alla configurazione del supplicant. I supplicant nativi del sistema operativo coprono la maggior parte degli scenari dei dispositivi gestiti se distribuiti tramite MDM. I client di terze parti offrono valore aggiunto in casi specifici: metodi EAP proprietari, parchi macchine con sistemi operativi misti che richiedono una configurazione coerente o onboarding BYOD self-service. I tre punti chiave da ricordare: convalida il certificato del server RADIUS su ogni profilo supplicant, automatizza il rinnovo del certificato prima di distribuire EAP-TLS su larga scala e isola i dispositivi che non supportano l'802.1X (dispositivi IoT e hardware legacy) su VLAN dedicate con il MAC Authentication Bypass come fallback. Per saperne di più su come Purple si integra con la tua architettura di accesso alla rete, visita purple punto ai. Grazie per l'ascolto.