Gestione dei certificati digitali per l'autenticazione WiFi EAP-TLS

Parla in inglese britannico con un tono fiducioso, autorevole e colloquiale - come un consulente senior che fa un briefing a un cliente. Ritmo misurato, dizione chiara, caldo ma diretto. Pause naturali occasionali per dare enfasi: Benvenuti alla serie di briefing tecnici di Purple. Oggi parliamo della gestione dei certificati EAP-TLS - nello specifico, di come gestire un programma di autenticazione WiFi basato su certificati su larga scala senza che diventi un onere operativo a tempo pieno. [pausa media] Se siete responsabili del WiFi aziendale o del personale in più sedi - che si tratti di un gruppo alberghiero, di un patrimonio retail, di un campus universitario o di un patrimonio del settore pubblico - questo briefing fa per voi. Copriremo l'intero ciclo di vita dei certificati: dalla configurazione della gerarchia delle CA, alla distribuzione automatizzata tramite SCEP e MDM, fino al rinnovo e alla revoca. E parleremo di dove le cose vanno male, perché succedono, e di come evitare le trappole più comuni. [pausa media] Iniziamo con i fondamentali. EAP-TLS - ovvero Extensible Authentication Protocol con Transport Layer Security - è il gold standard per l'autenticazione WiFi 802.1X. A differenza di PEAP, che si basa su nome utente e password, EAP-TLS utilizza l'autenticazione reciproca basata su certificati. Il dispositivo dimostra la propria identità con un certificato client. Il server RADIUS dimostra la propria identità con un certificato server. Entrambe le parti verificano l'altra. Nessuna password da sottrarre tramite phishing. Nessuna credenziale da rubare. Ecco perché PCI-DSS 4.0 e la guida zero-trust del NCSC indicano entrambe l'autenticazione basata su certificati per le reti del personale. [pausa media] Ora, l'architettura. Per far funzionare EAP-TLS sono necessarie tre cose. Primo, una Public Key Infrastructure - la vostra gerarchia di CA. Secondo, un meccanismo per installare i certificati sui dispositivi - ovvero SCEP o la vostra piattaforma MDM. Terzo, un server RADIUS che si fidi della vostra CA e che possa convalidare i certificati client in tempo reale. [pausa media] La gerarchia delle CA è il punto in cui la maggior parte delle organizzazioni incontra difficoltà all'inizio. Il modello corretto è un modello a tre livelli. Avete una Root CA in cima - questa dovrebbe essere offline, isolata fisicamente, e attivata solo per firmare il certificato della vostra Intermediate CA. La Intermediate CA - a volte chiamata Issuing CA - è quella che effettivamente firma i certificati quotidiani. È online, ma la sua chiave privata è ben protetta. Al di sotto di questa, emettete due tipi di certificato: certificati server per la vostra infrastruttura RADIUS e certificati client per i vostri dispositivi e utenti. [pausa media] Perché questo è importante? Perché se la vostra Root CA viene compromessa, dovete ricostruire l'intera PKI da zero e registrare nuovamente ogni dispositivo. Tenerla offline elimina questo rischio. La Intermediate CA può essere sostituita senza toccare la Root. Questa è l'argomentazione sulla resilienza operativa per il modello a tre livelli. [pausa media] Parliamo del periodo di validità dei certificati. C'è stato un cambiamento significativo nel settore in questo ambito. Apple, Google e Mozilla si sono mossi per imporre durate massime dei certificati più brevi. Per i certificati server TLS, il massimo è ora di 398 giorni. Per i certificati client nel WiFi aziendale, si ha maggiore flessibilità - uno o due anni è comune - ma la tendenza è verso durate più brevi e rinnovi automatizzati piuttosto che certificati a lungo termine gestiti manualmente. Il motivo è semplice: una durata inferiore limita la finestra di esposizione in caso di compromissione del certificato. [medium pause] Questo ci porta all'automazione. La gestione manuale dei certificati non è scalabile. Se si hanno 500 dispositivi, è possibile gestire i rinnovi a mano. Se si hanno 5.000 dispositivi su 50 siti, non è possibile. È necessario SCEP - il Simple Certificate Enrolment Protocol - o il suo successore moderno, EST. SCEP si integra direttamente con le piattaforme MDM, tra cui Microsoft Intune, Jamf Pro e VMware Workspace ONE. L'MDM invia un profilo di configurazione SCEP al dispositivo. Il dispositivo genera una coppia di chiavi, invia una richiesta di firma del certificato al server SCEP e riceve in risposta un certificato firmato - il tutto senza alcuna interazione da parte dell'utente. [medium pause] Per i dispositivi Windows in un ambiente Active Directory, esiste un'alternativa: l'auto-enrolment gestito tramite Group Policy tramite Active Directory Certificate Services. Il dispositivo si autentica nel dominio, la CA emette automaticamente un certificato e il certificato viene rinnovato prima della scadenza senza alcun intervento manuale. Questo è il percorso più fluido per le infrastrutture prevalentemente basate su Windows. [medium pause] Ora, la revoca. Questa è la parte su cui le organizzazioni spesso investono meno, ed è quella che conta di più quando qualcosa va storto. Se un dispositivo viene perso, rubato o se un dipendente lascia l'azienda, è necessario revocare immediatamente il suo certificato. Esistono due meccanismi: CRL - Certificate Revocation Lists - e OCSP - Online Certificate Status Protocol. [medium pause] La CRL è il meccanismo più vecchio. La CA pubblica un elenco di numeri di serie di certificati revocati a un URL noto. Il server RADIUS scarica periodicamente questo elenco e lo controlla. Il problema della CRL è la latenza - se la CRL ha un periodo di validità di 24 ore, un certificato revocato può ancora autenticarsi fino a 24 ore dopo la revoca. [medium pause] OCSP è l'alternativa in tempo reale. Il server RADIUS invia una richiesta al responder OCSP per ogni tentativo di autenticazione e riceve una risposta live di stato valido o revocato. Il compromesso è che il responder OCSP diventa una dipendenza critica - se non è disponibile, è necessario decidere se consentire comunque l'accesso (fail open) o bloccarlo (fail closed). Per gli ambienti ad alta sicurezza, fail closed è la risposta corretta. Per gli ambienti operativi in cui la disponibilità è fondamentale, è possibile configurare un breve periodo di tolleranza OCSP. [medium pause] Consentitemi di presentarvi due scenari concreti per rendere il tutto più reale. [medium pause] Primo: un gruppo alberghiero con 150 strutture. Utilizzavano PEAP con una password condivisa per il WiFi del personale. La rotazione delle password era trimestrale, il che comportava una finestra di due settimane ogni trimestre in cui il personale rimaneva bloccato fuori o utilizzava la vecchia password. Sono passati a EAP-TLS utilizzando Microsoft Intune per la distribuzione dei certificati, con profili SCEP inviati a tutti i dispositivi Windows e iOS e Active Directory Certificate Services come CA. Il risultato: zero eventi di rotazione delle password, rinnovo del certificato gestito automaticamente 30 giorni prima della scadenza e, quando un membro del personale si licenziava, il suo certificato veniva revocato nel MDM entro pochi minuti dalla disattivazione del suo account in Microsoft Entra ID. Il team IT ha stimato un risparmio di circa 40 ore a trimestre in reimpostazioni di password e ticket di helpdesk. [medium pause] Secondo: una catena di vendita al dettaglio multi-sito con 3.000 dispositivi del personale in 200 negozi. La sfida qui era la diversità dei dispositivi - un mix di laptop Windows, palmari Android e dispositivi iOS. Utilizzavano Jamf Pro per i dispositivi Apple e Microsoft Intune per Windows e Android, entrambi puntanti allo stesso server SCEP supportato da una CA intermedia Microsoft ADCS. L'infrastruttura WiFi era Cisco Meraki, con l'autenticazione RADIUS gestita da un servizio RADIUS ospitato in cloud integrato con Purple. La decisione di progettazione chiave è stata quella di emettere certificati con una validità di 12 mesi e configurare il rinnovo automatico a 60 giorni prima della scadenza. Ciò ha garantito una comoda finestra di rinnovo senza creare sovraccarico operativo. [medium pause] Ora, le insidie. Ce ne sono quattro che vedo costantemente. [medium pause] Primo: non testare la revoca. Le organizzazioni configurano la propria PKI, distribuiscono i certificati e non testano mai effettivamente se la revoca funzioni end-to-end. Testatela. Revocate un certificato di prova, confermate che il server RADIUS rilevi la revoca entro la finestra temporale prevista e verificate che al dispositivo venga negato l'accesso. [medium pause] Secondo: scadenze di massa impreviste. Se emettete tutti i certificati nello stesso momento con lo stesso periodo di validità, scadranno tutti contemporaneamente. Scaglionate l'emissione o, come minimo, scaglionate i trigger di rinnovo. Un tasso di errore di rinnovo del 10% su 5.000 dispositivi contemporaneamente rappresenta un incidente significativo. [medium pause] Terzo: non distribuire il certificato della Root CA a tutti i dispositivi prima di implementare EAP-TLS. Se il dispositivo non considera attendibile la vostra Root CA, rifiuterà il certificato del server RADIUS e l'autenticazione fallirà. Sembra ovvio, ma coglie di sorpresa le organizzazioni quando hanno dispositivi BYOD o laptop di collaboratori esterni che non sono registrati nel MDM. [medium pause] Quarto: disponibilità del responder OCSP. Se il vostro responder OCSP smette di funzionare e il vostro server RADIUS è configurato per bloccare gli accessi in caso di errori OCSP, l'intera rete WiFi smette di funzionare. Integrate la ridondanza nella vostra infrastruttura OCSP o configurate un breve periodo di grazia con un monitoraggio adeguato. [medium pause] Bene, passiamo alle domande rapide. [medium pause] Posso utilizzare una CA pubblica per i certificati client EAP-TLS? Tecnicamente sì, ma in pratica no. Le CA pubbliche non emettono certificati client per dispositivi arbitrari. È necessaria una CA propria per i certificati client. Per il certificato del server RADIUS, una CA pubblica va bene e semplifica la distribuzione della attendibilità. [medium pause] E per quanto riguarda il BYOD? Il BYOD è il caso più complesso. Non è possibile distribuire certificati a dispositivi non gestiti tramite MDM. Le opzioni includono un portale di controllo degli accessi alla rete che emette certificati a breve scadenza dopo l'autenticazione dell'utente, o semplicemente mantenere il BYOD su un SSID separato con un metodo di autenticazione diverso. [medium pause] In che modo interagisce con WPA3? WPA3-Enterprise impone la modalità di sicurezza a 192 bit per gli ambienti sensibili, che richiede suite di cifratura specifiche. EAP-TLS è completamente compatibile con WPA3-Enterprise ed è infatti il metodo di autenticazione consigliato. [medium pause] Per riassumere. La gestione dei certificati EAP-TLS non è semplice, ma è gestibile se si imposta correttamente l'architettura fin dall'inizio. Gerarchia CA a tre livelli. Registrazione automatizzata tramite SCEP o MDM. Breve durata dei certificati con rinnovo automatico. Revoca in tempo reale tramite OCSP. Testate tutto, specialmente la revoca. E integrate il ciclo di vita dei certificati con il vostro identity provider - Microsoft Entra ID, Okta o Google Workspace - in modo che la revoca del certificato venga avviata automaticamente quando un account viene rimosso. [medium pause] Se utilizzate server RADIUS collegati a Purple, i punti di integrazione sono l'URL del server SCEP, il certificato del server RADIUS e l'endpoint CRL o OCSP. L'architettura indipendente dall'hardware di Purple consente il funzionamento con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist e il resto dell'elenco hardware canonico - non siete vincolati agli strumenti PKI di un singolo fornitore. [medium pause] I prossimi passi: verificate il vostro attuale inventario dei certificati. Se non sapete quanti certificati avete, quando scadono e chi li ha emessi, questa è la prima cosa da risolvere. Da lì, il percorso verso l'automazione completa è ben definito. Grazie per l'ascolto.