Autenticazione tramite certificato WiFi: come i certificati digitali proteggono le reti wireless

Autenticazione WiFi tramite Certificati: Come i Certificati Digitali Sicurezza le Reti Wireless. Un Briefing Tecnico di Purple. Introduzione e Contesto. Benvenuti nella serie di Briefing Tecnici di Purple. Sono il vostro ospite e oggi approfondiremo uno dei temi più importanti - e spesso meno compresi - nella sicurezza delle reti aziendali: l'autenticazione WiFi tramite certificati. Se gestite un gruppo alberghiero, una catena retail, un centro congressi o qualsiasi organizzazione in cui sia il personale sia gli ospiti si connettono alla vostra infrastruttura wireless, questo briefing è direttamente rilevante per la vostra sicurezza informatica attuale. Inquadriamo la situazione. 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 che, onestamente, non cambia mai perché modificarla significherebbe aggiornare ogni singolo dispositivo aziendale. Questo modello è superato. Lo è sempre stato. L'autenticazione basata su certificati è il modo in cui le reti aziendali serie operano da oltre un decennio e, se non avete ancora effettuato questa transizione, questo briefing vi darà la chiarezza necessaria per fare il passo. Quindi - cos'è esattamente l'autenticazione WiFi tramite certificati, perché è importante e come si distribuisce concretamente? Scopriamolo. Approfondimento Tecnico. Partiamo dalle basi. 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 il vostro endpoint di rete. A differenza di una password, che è un segreto condiviso che può essere rubato, indovinato o trapelato, un certificato è legato matematicamente a una specifica chiave privata che non lascia mai il dispositivo. Non si può fare phishing di un certificato. Non si può forzare con attacchi brute-force. E, cosa fondamentale, si può revocare nel momento esatto 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 la Root Certificate Authority - l'ancora di salvezza finale della fiducia. Al di sotto di questa, in genere si hanno una o più Intermediate Certificate Authorities, che emettono effettivamente i certificati per i dispositivi e gli utenti finali. 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 è l'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 rappresenta il gold standard per la sicurezza WiFi aziendale. Ecco il flusso di autenticazione. Quando un dispositivo client tenta di connettersi al vostro 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 vostro server RADIUS, che è l'Authentication Server nella terminologia 802.1X. Il client presenta il proprio certificato. Il server RADIUS convalida tale certificato rispetto alla vostra 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 tramite access point canaglia, in cui un malintenzionato configura una rete WiFi fittizia per sottrarre credenziali. Con EAP-TLS, entrambe le parti dimostrano la propria identità prima che venga trasmesso un singolo byte di dati. Una volta che l'autenticazione reciproca va a buon fine, 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 distribuzioni incontrano ostacoli 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 tramite due meccanismi: le CRL, ovvero 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 la verifica della revoca in tempo reale. Per le grandi installazioni aziendali, l'OCSP è fortemente preferito perché i file CRL possono diventare molto grandi e introdurre latenza. La registrazione del certificato - ovvero l'installazione iniziale dei certificati sui dispositivi - viene gestita tramite protocolli come SCEP, il Simple Certificate Enrolment Protocol, o EST, Enrolment over Secure Transport, che rappresenta il sostituto più moderno. In un ambiente Microsoft, in genere si utilizzano i servizi Active Directory Certificate Services con le Group Policy per registrare automaticamente i certificati sulle macchine collegate al dominio. Per gli scenari di gestione dei dispositivi mobili, la 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, dove si interseca tutto questo con il WiFi per gli ospiti? Questa è una distinzione importante. L'autenticazione tramite certificato è principalmente un controllo di rete aziendale. I tuoi ospiti non avranno certificati rilasciati dalla PKI della tua azienda. Per l'accesso degli ospiti, si opera in un modello di autenticazione diverso - tipicamente un Captive Portal con login social, registrazione via email o, sempre più spesso, Passpoint e OpenRoaming, che utilizzano certificati a livello di infrastruttura per consentire un roaming sicuro e trasparente tra le diverse sedi. La piattaforma di Purple si colloca esattamente in questo spazio del WiFi per gli ospiti, fornendo il livello di acquisizione delle identità, analisi e coinvolgimento sopra un'infrastruttura wireless sicura. Il principio architetturale chiave è la segmentazione della rete: l'SSID aziendale autenticato tramite certificato e l'SSID del WiFi per gli ospiti sono logicamente separati, con adeguate policy di firewall tra di essi. Questo non è negoziabile per la conformità PCI-DSS se si elaborano pagamenti con carta ovunque vicino all'infrastruttura wireless, ed è caldamente raccomandato per la conformità GDPR considerando i dati gestiti su entrambe le reti. Raccomandazioni di Implementazione ed Errori Comuni. Permettetemi di fornirvi una guida pratica alla distribuzione - e di evidenziare gli errori che vedo commettere ripetutamente dalle organizzazioni. Primo, 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. Secondo, strutturate 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 l'802.1X correttamente per poi scoprire, durante un'interruzione, che il failover RADIUS non era stato configurato sugli access point. Terzo, i periodi di validità dei certificati devono essere allineati con i cicli di aggiornamento del MDM. Se il MDM invia i rinnovi dei certificati su un ciclo di 90 giorni ma i certificati hanno una validità di 12 mesi, si creerà un divario. Automatizzate il rinnovo e impostate degli avvisi a 60 giorni dalla scadenza. Quarto - e questo coglie spesso alla sprovvista - iOS e Android gestiscono l'attendibilità dei certificati in modo diverso. iOS richiede che il certificato 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 lancio. Il quinto errore comune è la disponibilità di OCSP. Se il vostro risponditore OCSP è interno e un client non riesce a raggiungerlo durante l'autenticazione - forse perché si sta connettendo per la prima volta e non ha ancora l'accesso alla rete - l'autenticazione può fallire o ripiegare su CRL. Progettate la vostra infrastruttura OCSP in modo che sia raggiungibile dallo stato di pre-autenticazione, oppure configurate il server RADIUS per memorizzare nella cache le risposte OCSP in modo appropriato. Domande e Risposte Rapide. Lasciate che risponda alle domande che mi vengono rivolte più frequentemente. Domanda: Possiamo utilizzare l'autenticazione tramite certificato insieme al nostro portale WiFi per ospiti esistente? Assolutamente sì. Si tratta di SSID separati con meccanismi di autenticazione distinti. I vostri utenti aziendali si autenticano tramite EAP-TLS; i vostri ospiti seguono il flusso del captive portal. Purple gestisce la parte ospiti; la vostra infrastruttura RADIUS gestisce la parte aziendale. Domanda: Cosa succede quando un dispositivo viene smarrito o rubato? Il certificato viene revocato immediatamente tramite la console di gestione della 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 processo può avvenire quasi in tempo reale. Con CRL, dipende dall'intervallo di pubblicazione della CRL - in genere poche ore. Ecco perché l'OCSP è preferito per gli ambienti ad alta sicurezza. Domanda: EAP-TLS è compatibile con WPA3? Sì. Lo standard WPA3-Enterprise impone l'uso della modalità di sicurezza a 192 bit per le installazioni più sensibili, e EAP-TLS è completamente compatibile. Di fatto, WPA3-Enterprise con EAP-TLS rappresenta la configurazione di massima sicurezza oggi disponibile per il WiFi aziendale. Domanda: In che modo questo influisce sulla nostra conformità PCI-DSS? In modo positivo. I requisiti 1 e 8 del PCI-DSS beneficiano entrambi dell'autenticazione basata su certificati. L'eliminazione delle chiavi pre-condivise condivise rimuove un rilievo di audit significativo, e l'identità per singolo dispositivo garantisce un percorso di audit chiaro su 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 e 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 degli accessi granulare e si integra perfettamente con la vostra infrastruttura di identità esistente. Il percorso di implementazione è ormai consolidato: progettare la gerarchia PKI, distribuire un'infrastruttura RADIUS ridondante, integrarsi con il proprio MDM per la distribuzione dei certificati, configurare i punti di accesso per l'802.1X e testare accuratamente su tutto il parco dispositivi. Per quanto riguarda la rete ospiti, si tratta di un discorso a parte - ed è qui che piattaforme come Purple offrono un reale valore aggiunto, garantendo un onboarding degli ospiti sicuro e conforme, con funzionalità di analisi e coinvolgimento che trasformano la vostra infrastruttura WiFi in una risorsa aziendale anziché in un semplice servizio di utilità. Se state valutando la vostra attuale postura di autenticazione, il punto di partenza ideale è un audit della configurazione SSID esistente e una verifica dello stato di preparazione della vostra infrastruttura di certificati. Da lì, un roll-out graduale - partendo con un gruppo pilota di dispositivi gestiti - rappresenta il percorso a minor rischio verso un'implementazione completa. Grazie per aver seguito questo approfondimento tecnico di Purple. Per ulteriori letture, consultate 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.