WiFi Certificate Authentication: How Digital Certificates Secure Wireless Networks

Autenticazione tramite certificato WiFi: come i certificati digitali proteggono le reti wireless. Un briefing tecnico di Purple. Introduzione e contesto. Benvenuti alla serie di briefing tecnici di Purple. Sono il vostro ospite e oggi approfondiremo uno degli argomenti più importanti — e spesso fraintesi — della sicurezza delle reti aziendali: l'autenticazione tramite certificato WiFi. Se gestite un gruppo alberghiero, una catena di negozi, un centro congressi o qualsiasi organizzazione in cui sia il personale che gli ospiti si connettono alla vostra infrastruttura wireless, questo briefing è direttamente rilevante per la vostra postura di sicurezza in questo momento. Lasciate che vi presenti lo scenario. L'approccio tradizionale per proteggere il WiFi aziendale è stato una chiave pre-condivisa — una password che tutti conoscono, che viene scritta sulle lavagne, condivisa nei canali Slack e, francamente, non viene mai cambiata perché cambiarla significherebbe aggiornare ogni dispositivo dell'azienda. Questo modello è superato. Lo è sempre stato. L'autenticazione basata su certificati è il modo in cui le reti aziendali serie gestiscono questo aspetto da oltre un decennio e, se non avete ancora effettuato la transizione, questo briefing vi fornirà la chiarezza necessaria per prendere questa decisione. Quindi — cos'è esattamente l'autenticazione tramite certificato WiFi, perché è importante e come si distribuisce concretamente? Entriamo nel dettaglio. Approfondimento tecnico. Iniziamo con i concetti fondamentali. Un certificato digitale, nel contesto dell'autenticazione WiFi, è una credenziale digitale X.509 — essenzialmente un documento firmato crittograficamente che prova l'identità di un dispositivo o di un utente. Pensatelo come un passaporto per l'endpoint della vostra rete. A differenza di una password, che è un segreto condiviso che può essere rubato, indovinato o trapelato, un certificato è legato matematicamente a una chiave privata specifica che non lascia mai il dispositivo. Non è possibile fare phishing di un certificato. Non è possibile forzarlo con attacchi brute-force. E, cosa fondamentale, è possibile revocarlo nel momento stesso in cui un dispositivo viene smarrito o un dipendente lascia l'azienda. L'infrastruttura sottostante che rende possibile tutto questo si chiama PKI — Public Key Infrastructure. La PKI è una gerarchia di fiducia. In cima si trova una Root Certificate Authority — l'ancora di fiducia finale. Al di sotto, in genere, si trovano una o più Intermediate Certificate Authorities, che emettono effettivamente i certificati dell'entità finale per i dispositivi e gli utenti. Questa gerarchia è importante perché significa che la Root CA può essere mantenuta completamente offline e isolata, riducendo drasticamente la superficie di attacco. Se una Intermediate CA viene compromessa, la si revoca senza toccare la Root. Ora, come funziona concretamente su una rete WiFi? Lo stack di protocolli è IEEE 802.1X — lo standard di controllo dell'accesso alla rete basato su porta — combinato con EAP-TLS, che sta per Extensible Authentication Protocol con Transport Layer Security. Questo è il gold standard per la sicurezza del WiFi aziendale. Ecco il flusso di autenticazione. Quando un dispositivo client tenta di connettersi al tuo SSID aziendale, l'access point — che agisce come quello che lo standard 802.1X definisce Authenticator — non concede immediatamente l'accesso alla rete. Al contrario, fa da proxy per una conversazione EAP tra il client e il tuo server RADIUS, che è l'Authentication Server nella terminologia 802.1X. Il client presenta il proprio certificato. Il server RADIUS convalida tale certificato rispetto alla tua PKI — verificando la catena delle firme, il periodo di validità e lo stato di revoca. Contemporaneamente — e questa è la parte che rende l'EAP-TLS realmente superiore alla maggior parte degli altri metodi EAP — anche il client convalida il certificato del server. Questa autenticazione reciproca previene gli attacchi da parte di access point non autorizzati (rogue AP), in cui un utente malintenzionato configura una rete WiFi fittizia per sottrarre credenziali. Con l'EAP-TLS, entrambe le parti dimostrano la propria identità prima che venga trasmesso un singolo byte di dati. Una volta che l'autenticazione reciproca ha successo, il server RADIUS invia un messaggio di Access-Accept all'access point e il client viene inserito nel segmento di rete appropriato — che si tratti della VLAN aziendale, di un segmento guest limitato o di un gruppo di criteri specifico basato sugli attributi del certificato. Parliamo del ciclo di vita dei certificati, perché è qui che molte implementazioni incontrano attriti operativi. I certificati vengono emessi, hanno un periodo di validità — in genere da uno a tre anni per i certificati dei dispositivi — e devono essere rinnovati prima della scadenza. Possono anche essere revocati prima della scadenza se un dispositivo viene rubato o dismesso. La revoca viene gestita attraverso due meccanismi: le CRL, o Certificate Revocation Lists, che sono elenchi pubblicati periodicamente di numeri di serie di certificati revocati; e l'OCSP, l'Online Certificate Status Protocol, che consente il controllo della revoca in tempo reale. Per le grandi distribuzioni aziendali, l'OCSP è fortemente preferito perché i file CRL possono diventare molto grandi e introdurre latenza. L'enrolment dei certificati — ovvero l'installazione iniziale dei certificati sui dispositivi — viene gestito tramite protocolli come SCEP, il Simple Certificate Enrolment Protocol, o EST, l'Enrolment over Secure Transport, che è il sostituto più moderno. In un ambiente Microsoft, in genere si utilizzano gli Active Directory Certificate Services con le Group Policy per l'auto-enrolment dei certificati sulle macchine aggiunte al dominio. Per gli scenari di gestione dei dispositivi mobili, la tua piattaforma MDM — che si tratti di Intune, Jamf o di un'altra soluzione — gestisce la distribuzione dei certificati come parte del profilo di configurazione del dispositivo. Ora, in che modo questo si interseca con il guest WiFi? Questa è una distinzione importante. L'autenticazione tramite certificato è principalmente un controllo di rete aziendale. I tuoi ospiti non avranno certificati emessi dalla PKI della tua azienda. Per l'accesso degli ospiti, si opera in un modello di autenticazione diverso — tipicamente un Captive Portal con social login, registrazione via e-mail o, sempre più spesso, Passpoint e OpenRoaming, che utilizzano certificati a livello di infrastruttura per consentire un roaming sicuro e senza interruzioni tra le diverse sedi. La piattaforma di Purple si colloca esattamente in questo spazio del guest WiFi, fornendo il livello di acquisizione dell'identità, analisi e coinvolgimento sopra un'infrastruttura wireless sicura. Il principio architetturale chiave è la segmentazione della rete: il tuo SSID aziendale autenticato tramite certificato e il tuo SSID guest WiFi sono logicamente separati, con politiche di firewall appropriate tra di essi. Questo è non negoziabile per la conformità PCI DSS se si elaborano pagamenti con carta in prossimità della propria infrastruttura wireless, ed è fortemente raccomandato per la conformità GDPR dati i dati gestiti su entrambe le reti. Raccomandazioni di implementazione e insidie comuni. Permettetemi di fornirvi una guida pratica all'implementazione — e le insidie in cui vedo cadere ripetutamente le organizzazioni. In primo luogo, pianificate la vostra PKI prima di toccare un singolo access point. L'errore più comune è implementare l'autenticazione tramite certificato con una struttura CA piatta a livello singolo. Implementate sempre almeno una gerarchia a due livelli con una Root CA offline. Il sovraccarico operativo è minimo; il vantaggio in termini di sicurezza è sostanziale. In secondo luogo, definite al meglio la vostra infrastruttura RADIUS. Un singolo server RADIUS rappresenta un singolo punto di vulnerabilità (single point of failure). Distribuite almeno due server RADIUS in configurazione active-passive o active-active e testate il failover. Ho visto organizzazioni implementare correttamente l'802.1X per poi scoprire, durante un'interruzione, che il failover RADIUS non era configurato sugli access point. In terzo luogo, i periodi di validità dei certificati devono essere allineati con i cicli di aggiornamento dell'MDM. Se il vostro MDM invia i rinnovi dei certificati su un ciclo di 90 giorni ma i vostri certificati hanno una validità di 12 mesi, avrete un divario. Automatizzate il rinnovo e impostate avvisi a 60 giorni dalla scadenza. In quarto luogo — e questo coglie spesso di sorpresa — iOS e Android gestiscono l'affidabilità dei certificati in modo diverso. iOS richiede che il certificato della Root CA sia esplicitamente considerato attendibile dall'utente al primo collegamento, a meno che non venga inviato tramite MDM. Il comportamento di Android varia a seconda della versione e del produttore. Testate l'esperienza del client su ogni classe di dispositivo prima del go-live. La quinta insidia è la disponibilità dell'OCSP. Se il vostro risponditore OCSP è interno e un client non può raggiungerlo durante l'autenticazione — forse perché si connette per la prima volta e non ha ancora accesso alla rete — l'autenticazione può fallire o ripiegare sulla CRL. Progettate la vostra infrastruttura OCSP in modo che sia raggiungibile dallo stato di pre-autenticazione, oppure configurate il vostro server RADIUS per memorizzare nella cache le risposte OCSP in modo appropriato. Domande e risposte rapide. Lascia che ti illustri le domande che mi vengono poste più di frequente. Domanda: Possiamo utilizzare l'autenticazione tramite certificato insieme al nostro portale WiFi per gli ospiti esistente? Assolutamente sì. Si tratta di SSID separati con meccanismi di autenticazione distinti. I tuoi utenti aziendali si autenticano tramite EAP-TLS; i tuoi ospiti seguono il flusso del Captive Portal. Purple gestisce la parte ospiti; la tua infrastruttura RADIUS gestisce la parte aziendale. Domanda: Cosa succede quando un dispositivo viene smarrito o rubato? Revochi immediatamente il certificato tramite la console di gestione della tua CA. La volta successiva che il dispositivo tenta di connettersi, il server RADIUS verifica lo stato di revoca e rifiuta la connessione. Con OCSP, questo può avvenire quasi in tempo reale. Con CRL, dipende dall'intervallo di pubblicazione della CRL, in genere ore. Questo è il motivo per cui OCSP è preferito per gli ambienti ad alta sicurezza. Domanda: EAP-TLS è compatibile con WPA3? Sì. WPA3-Enterprise impone l'uso della modalità di sicurezza a 192 bit per le distribuzioni più sensibili ed EAP-TLS è completamente compatibile. Di fatto, WPA3-Enterprise con EAP-TLS è la configurazione di sicurezza più elevata disponibile oggi per il WiFi aziendale. Domanda: In che modo questo influisce sulla nostra conformità al GDPR e PCI DSS? In modo positivo. I requisiti PCI DSS 1 e 8 beneficiano entrambi dell'autenticazione basata su certificato. L'eliminazione delle chiavi pre-condivise condivise rimuove un rilievo di audit significativo, e l'identità per singolo dispositivo significa che avrai una traccia di audit chiara di quale dispositivo ha effettuato l'accesso a quale segmento di rete e quando. Riepilogo e prossimi passi. Per riassumere: l'autenticazione tramite certificato WiFi via 802.1X ed EAP-TLS è l'approccio corretto per qualsiasi organizzazione che prenda sul serio la sicurezza della propria rete. Elimina i segreti condivisi, fornisce un'autenticazione reciproca, consente un controllo granulare degli accessi e si integra perfettamente con la tua infrastruttura di identità esistente. Il percorso di implementazione è ben definito: progetta la tua gerarchia PKI, distribuisci un'infrastruttura RADIUS ridondante, integrati con il tuo MDM per la distribuzione dei certificati, configura i tuoi access point per l'802.1X ed esegui test approfonditi su tutto il parco dispositivi. Per la tua rete ospiti, si tratta di un discorso a parte, ed è qui che piattaforme come Purple aggiungono un valore reale, offrendoti un onboarding degli ospiti sicuro e conforme, con funzionalità di analisi e coinvolgimento che trasformano la tua infrastruttura WiFi in una risorsa aziendale anziché in un semplice servizio di utilità. Se stai valutando la tua attuale postura di autenticazione, il punto di partenza corretto è un audit della configurazione SSID esistente e una revisione dello stato di preparazione della tua infrastruttura di certificati. Da lì, un roll-out graduale, a partire da un gruppo pilota di dispositivi gestiti, rappresenta il percorso a minor rischio verso una distribuzione completa. Grazie per aver ascoltato questo Briefing Tecnico Purple. Per ulteriori letture, consulta le nostre guide sulla sicurezza del WiFi aziendale e sui metodi di autenticazione WiFi più sicuri sul sito web di Purple all'indirizzo purple.ai.