EAP-TLS vs. PEAP: quale protocollo di autenticazione è adatto alla tua rete?

EAP-TLS vs PEAP: quale protocollo di autenticazione è quello giusto per la tua rete? Un briefing tecnico Purple [INTRODUZIONE — circa 1 minuto] Benvenuti al briefing tecnico Purple. Sono il vostro presentatore e oggi affronteremo una delle decisioni più importanti che vi troverete a prendere durante la progettazione o l'aggiornamento della vostra infrastruttura wireless aziendale: la scelta tra EAP-TLS e PEAP per il vostro framework di autenticazione 802.1X. Se siete un IT manager, un network architect o un CTO responsabile di un gruppo alberghiero, di una rete di punti vendita, di uno stadio o di un'organizzazione del settore pubblico, questa decisione influisce sulla vostra postura di sicurezza, sulla conformità al GDPR e sui costi operativi quotidiani che il vostro team deve sostenere. Quindi, andiamo dritti al punto. Sia EAP-TLS che PEAP sono metodi di autenticazione 802.1X. Entrambi si affidano a un server RADIUS per gestire le richieste di autenticazione ed entrambi offrono una sicurezza significativamente maggiore rispetto a una passphrase WPA2 condivisa. Ma il modo in cui verificano l'identità è fondamentalmente diverso, e questa differenza ha implicazioni importanti sul modo in cui distribuite, gestite e scalate la vostra rete. [APPROFONDIMENTO TECNICO — circa 5 minuti] Iniziamo con EAP-TLS — Extensible Authentication Protocol Transport Layer Security. EAP-TLS è il gold standard dell'autenticazione WiFi aziendale. La caratteristica distintiva è l'autenticazione reciproca tramite certificati. Ciò che significa in pratica è questo: quando un dispositivo tenta di connettersi alla rete, il server RADIUS presenta un certificato digitale al dispositivo. Il dispositivo verifica tale certificato confrontandolo con le proprie Autorità di Certificazione attendibili. Ma ecco la differenza fondamentale rispetto a PEAP: il dispositivo presenta a sua volta il proprio certificato al server. Il server convalida il certificato del client e, solo se entrambi i certificati sono validi e attendibili, la rete concede l'accesso. Non ci sono password coinvolte. Nessuna. L'autenticazione si basa interamente sui certificati. Questo rende EAP-TLS straordinariamente resistente al furto di credenziali, agli attacchi a dizionario e agli attacchi Man-in-the-Middle. Semplicemente non è possibile rubare una password che non esiste nel flusso di autenticazione. Il compromesso, tuttavia, è la complessità di implementazione. Per eseguire EAP-TLS su larga scala, è necessaria una Public Key Infrastructure (PKI) per emettere, gestire e revocare i certificati per ogni singolo dispositivo sulla rete. È inoltre necessaria una soluzione di Mobile Device Management per distribuire silenziosamente tali certificati agli endpoint. Se gestite un parco macchine aziendale con Microsoft Intune o Jamf, questo è del tutto gestibile. In caso contrario, EAP-TLS diventa un'impresa significativa. L'altra considerazione operativa riguarda la gestione del ciclo di vita dei certificati. I certificati scadono. Se il certificato del server RADIUS scade, l'autenticazione di ogni singolo dispositivo sulla rete fallirà contemporaneamente. Si tratta di un disservizio catastrofico. I processi di monitoraggio e rinnovo dei certificati non sono negoziabili. Ora diamo un'occhiata a PEAP — Protected Extensible Authentication Protocol. PEAP è stato progettato per risolvere la complessità di implementazione di EAP-TLS, offrendo al contempo una sicurezza robusta. L'intuizione chiave alla base di PEAP è questa: è necessario che solo il server disponga di un certificato. Il client non ne ha bisogno. Ecco come funziona. Il server RADIUS presenta il proprio certificato al dispositivo client. Il client convalida il server, proprio come in EAP-TLS. Questo stabilisce un tunnel TLS crittografato. All'interno di quel tunnel, il client esegue quindi l'autenticazione standard basata su password, in genere utilizzando MSCHAPv2, rispetto al tuo archivio di identità: Active Directory, LDAP, Google Workspace o qualsiasi altro strumento tu stia utilizzando. La password non viaggia mai in chiaro. È sempre protetta all'interno del tunnel crittografato. Quindi PEAP è autenticamente sicuro, a condizione che sia configurato correttamente. Ed è qui che dobbiamo parlare della configurazione errata più comune e pericolosa nelle implementazioni PEAP. Se un dispositivo client non è configurato per convalidare rigorosamente il certificato del server RADIUS, un utente malintenzionato può configurare un access point non autorizzato con lo stesso nome di rete, presentare un certificato fraudolento e il dispositivo si connetterà senza problemi. L'autore dell'attacco acquisisce quindi lo scambio di autenticazione MSCHAPv2, che può essere decifrato offline. Questo non è un attacco teorico: è una tecnica ampiamente documentata utilizzata nei penetration test del mondo reale. La soluzione è semplice: utilizza i Criteri di gruppo, i profili MDM o gli strumenti di onboarding per imporre una convalida rigorosa del certificato del server su ogni dispositivo client. Ma la realtà operativa è che negli ambienti BYOD, garantire che questa configurazione sia applicata in modo coerente su migliaia di dispositivi personali non gestiti è davvero difficile. Permettetemi di fare un confronto concreto. Consideriamo una catena di vendita al dettaglio con 500 sedi. Dispongono di tablet aziendali e scanner portatili, tutti gestiti tramite Microsoft Intune. EAP-TLS è la scelta giusta. Intune distribuisce i certificati automaticamente. Se uno scanner viene smarrito, l'IT revoca il suo certificato e questo viene rimosso dalla rete in pochi minuti: nessun ripristino della password, nessuna modifica della passphrase condivisa in 500 negozi. La sicurezza è assoluta. Consideriamo ora un grande centro congressi che gestisce il WiFi per 3.000 membri dello staff sui loro dispositivi personali. Nessun MDM. Lo staff utilizza Google Workspace. PEAP integrato con Google Secure LDAP è la scelta pragmatica. Lo staff si autentica con le proprie credenziali standard. Il team IT fornisce la documentazione di onboarding per configurare la convalida del certificato. È implementabile in pochi giorni, non in mesi. L'architettura alla base di entrambi i protocolli è lo stesso modello 802.1X a tre componenti: il supplicant (ovvero il dispositivo client), l'authenticator (che è l'access point o lo switch) e il server RADIUS. L'authenticator funge da gatekeeper, bloccando tutto il traffico finché il server RADIUS non segnala che l'autenticazione è andata a buon fine. [RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE DA EVITARE — circa 2 minuti] Quali sono quindi le raccomandazioni pratiche? Primo: se disponete di una soluzione MDM e di dispositivi aziendali, implementate EAP-TLS. L'investimento iniziale in PKI e nella gestione dei certificati ripaga ampiamente in termini di riduzione del rischio e semplificazione degli audit di conformità. Per gli ambienti regolamentati (sanità, finanza, settore pubblico) questa non è un'opzione. È l'architettura che i vostri auditor si aspettano di vedere. Secondo: se gestite un ambiente BYOD o non disponete di un'infrastruttura MDM, implementate PEAP. Ma non saltate la configurazione della validazione del certificato del server. Utilizzate strumenti di onboarding, portali di controllo degli accessi alla rete o profili MDM, laddove possibile, per imporla. Consideratelo come un passaggio di implementazione obbligatorio, non come una misura di hardening opzionale. Terzo: indipendentemente dal protocollo scelto, integrate la ridondanza RADIUS nella vostra architettura. L'autenticazione è un percorso critico. Un singolo guasto al server RADIUS significa che nessuno può accedere alla rete. Le soluzioni RADIUS ospitate in cloud possono offrire resilienza senza l'onere di gestire un'infrastruttura on-premises ridondante. Quarto: segmentate la rete dopo l'autenticazione. Un'autenticazione 802.1X riuscita non deve garantire un accesso illimitato all'intera rete aziendale. Utilizzate le policy di assegnazione delle VLAN per collocare gli utenti nei segmenti di rete appropriati con i relativi controlli di accesso. Le trappole comuni da evitare: la scadenza dei certificati che causa errori di autenticazione di massa nelle implementazioni EAP-TLS; i dispositivi client che non convalidano i certificati del server nelle implementazioni PEAP; e i problemi di timeout RADIUS causati da un'elevata latenza tra il controller wireless e il server di autenticazione, particolarmente rilevanti in proprietà distribuite geograficamente. [Q&A RAPIDO — circa 1 minuto] Permettetemi di passare in rassegna alcune domande che sento di frequente. Posso eseguire sia EAP-TLS che PEAP sulla stessa rete? Sì. Molte organizzazioni eseguono EAP-TLS per i dispositivi aziendali su un SSID e PEAP per il BYOD o l'accesso ospiti su un SSID separato, con un'adeguata segmentazione di rete tra di essi. WPA3 cambia questa decisione? WPA3 Enterprise impone la modalità di sicurezza a 192 bit per le implementazioni ad alta sicurezza, il che si allinea con EAP-TLS. WPA3 Personal utilizza SAE invece di PSK, ma per le implementazioni aziendali 802.1X, la selezione del metodo EAP rimane rilevante. PEAP è conforme allo standard PCI DSS? Sì, se configurato correttamente con la validazione del certificato del server attiva. Tuttavia, per gli ambienti che gestiscono dati dei titolari di carta, EAP-TLS è sempre più l'approccio raccomandato nelle valutazioni di sicurezza. E per quanto riguarda OpenRoaming? OpenRoaming utilizza l'autenticazione basata su certificati dietro le quinte, allineandosi ai principi di EAP-TLS. Piattaforme come Purple possono fungere da identity provider per OpenRoaming, consentendo un roaming sicuro e senza interruzioni tra le sedi senza dover ripetere l'autenticazione. [RIASSUNTO E PROSSIMI PASSI — circa 1 minuto] In sintesi: EAP-TLS rappresenta l'opzione di sicurezza più elevata, eliminando completamente le password grazie all'autenticazione reciproca tramite certificati. Richiede un'infrastruttura PKI e MDM, ma garantisce la massima conformità e il controllo degli accessi più granulare a livello di dispositivo. PEAP è la scelta pragmatica per il BYOD e per gli ambienti privi di un'infrastruttura di gestione dei certificati, offrendo una solida autenticazione crittografata con le credenziali esistenti, ma solo se la convalida del certificato del server viene applicata rigorosamente. Il quadro decisionale è semplice: se gestisci i tuoi dispositivi, usa EAP-TLS. Se gli utenti utilizzano i propri dispositivi personali, usa PEAP, ma configurandolo correttamente. Per i passaggi successivi: esegui un audit della tua attuale configurazione di autenticazione, valuta lo stato di preparazione di PKI e MDM e analizza l'infrastruttura RADIUS per verificarne la ridondanza e la latenza. Se stai implementando o aggiornando il WiFi per gli ospiti parallelamente alla rete aziendale, valuta come una piattaforma come Purple possa integrarsi con il tuo framework di autenticazione per offrire sia sicurezza che analisi utili dal tuo network. Grazie per aver ascoltato il Technical Briefing di Purple. Alla prossima.