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 fondamentale per la 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 presentano errori di certificato e generano ticket di assistenza, questa è la puntata che fa per voi. [medium pause] Iniziamo con le basi. Il supplicant 802.1X è il componente software presente sul 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 del documento d'identità del dispositivo. La rete non fa entrare chiunque. Richiede delle 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, ovvero Extensible Authentication Protocol over LAN. Tutto il resto viene bloccato. Una volta che il supplicant dimostra la propria identità al server RADIUS tramite l'authenticator, la porta si apre e il traffico normale inizia a fluire. [medium pause] Ci sono tre attori in questo scenario. Primo, il supplicant - il dispositivo client. Secondo, l'authenticator - il vostro access point o switch, hardware come Cisco Meraki, HPE Aruba, Ruckus o Juniper Mist. Terzo, l'authentication server - 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'authenticator risponde con una richiesta EAP-Request per l'identità. Il supplicant risponde con la propria identità. Tale identità viene inoltrata al server RADIUS, che sfida il supplicant con il metodo EAP concordato. Se tutto va a buon fine, il server RADIUS invia un messaggio di Access-Accept, la porta si apre e il dispositivo viene inserito nella VLAN corretta. [medium pause] Parliamo ora dei metodi EAP, perché è qui che viene presa la maggior parte delle decisioni di implementazione. L'EAP-TLS - ovvero Extensible Authentication Protocol con Transport Layer Security - è lo standard di riferimento assoluto. Richiede che sia il client sia il server presentino dei certificati. Autenticazione reciproca. Niente password. Il certificato client dimostra l'identità del dispositivo; il certificato server dimostra che la rete è legittima, offrendo protezione contro gli attacchi evil twin in cui un access point non autorizzato tenta di sottrarre le credenziali. L'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. Il PEAP - Protected EAP - è il punto di partenza più comune per le organizzazioni che non dispongono ancora di una PKI completa. Il PEAP racchiude un metodo interno basato su password, in genere 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 contraffatto che presenta un certificato dall'aspetto attendibile, le sue credenziali possono essere intercettate. La validazione del certificato server lato client è quindi imprescindibile quando si utilizza il PEAP. [medium pause] Passiamo ora al supplicant vero e proprio - in particolare alla scelta tra supplicant nativi del sistema operativo e software client di terze parti. Ogni principale sistema operativo viene fornito con un supplicant 802.1X integrato. Windows lo supporta nativamente da XP, tramite i servizi Configurazione automatica reti cablate e Configurazione automatica WLAN. macOS e iOS gestiscono l'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 una stretta integrazione con l'archivio dei certificati del sistema operativo. Per i parchi dispositivi gestiti - macchine Windows registrate in Microsoft Entra ID tramite Microsoft Intune, Mac gestiti tramite Jamf - è possibile distribuire i profili di configurazione 802.1X in modo invisibile tramite MDM, senza che gli utenti visualizzino alcuna richiesta. Il dispositivo si autentica automaticamente ogni volta che entra nel raggio d'azione. 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 il Secure Services Client o AnyConnect Network Access Manager. Se hai bisogno di una gestione coerente della configurazione su 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 concreto questo concetto. In primo luogo, 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 Android personali utilizzati per il software di gestione della struttura e una manciata di macchine legacy Windows 7 nel back office. L'approccio in questo caso è graduale. Inizia con la flotta di dispositivi Windows gestiti. 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 autenticheranno 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 supplicante 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 per punti vendita, tablet per il 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 lo standard 802.1X sulle reti del personale e dei terminali di vendita, con l'assegnazione delle VLAN guidata dagli attributi dei certificati. Un terminale di vendita presenta un certificato 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 di vendita è bloccata tramite MDM. Non è richiesta alcuna interazione da parte dell'utente. I terminali si autenticano silenziosamente all'avvio. Il rinnovo dei certificati è automatizzato tramite SCEP, eliminando qualsiasi intervento manuale alla scadenza dei certificati. [medium pause] Ora, i problemi comuni di implementazione. Ti illustrerò i quattro più frequenti. Numero uno: la mancata 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 automatico tramite SCEP o NDES, ti scontrerai con una situazione critica in cui centinaia di dispositivi smetteranno di autenticarsi contemporaneamente. Configura l'automazione del rinnovo prima di andare online. Numero tre: dispositivi BYOD con comportamenti del supplicant incoerenti. Android in particolare presenta un supporto 802.1X frammentato tra i vari produttori. Alcune versioni richiedono che l'utente installi manualmente il certificato della 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 supplicant con le nuove versioni del sistema operativo prima di implementarli in produzione. [pausa media] Ora passiamo alle domande rapide. I dispositivi IoT possono supportare lo standard 802.1X? La maggior parte non può farlo. I dispositivi IoT in genere sono privi di un supplicant. L'alternativa di ripiego è 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 connettersi a una VLAN IoT isolata con regole di firewall rigide. Ho bisogno di una PKI per eseguire 802.1X? Per PEAP, no - ti serve solo 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 il tuo 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 identity provider - Microsoft Entra ID, Okta o Google Workspace - per applicare l'autenticazione 802.1X e applicare policy VLAN per utente senza richiedere un'infrastruttura RADIUS on-premises. [pausa media] Per concludere: il supplicant 802.1X è l'agente lato dispositivo che fa funzionare il controllo dell'accesso alla rete basato su porta. La tua scelta del metodo EAP - EAP-TLS per la massima sicurezza, PEAP come opzione di transizione - determina i requisiti della tua PKI e l'approccio alla configurazione del supplicant. I supplicant nativi del sistema operativo coprono la maggior parte degli scenari dei dispositivi gestiti quando vengono 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: convalidate il certificato del server RADIUS su ogni profilo supplicant, automatizzate il rinnovo dei certificati prima di distribuire EAP-TLS su vasta scala e isolate i dispositivi che non supportano l'802.1X - IoT, hardware legacy - su VLAN dedicate con MAC Authentication Bypass come soluzione di backup. Per maggiori informazioni su come Purple si integra con la vostra architettura di accesso alla rete, visitate purple dot ai. Grazie per l'ascolto.