Gestione dei Certificati Digitali per l'Autenticazione WiFi EAP-TLS

Parla in inglese britannico con un tono sicuro, autorevole e colloquiale, come un consulente senior che fa un briefing a un cliente. Ritmo misurato, dizione chiara, caloroso 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. [medium pause] Se siete responsabili del WiFi aziendale o del personale su più sedi, che si tratti di un gruppo alberghiero, di un patrimonio retail, di un campus universitario o di un ente del settore pubblico, questo briefing fa al caso vostro. 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 cosa può andare storto, perché le cose vanno storte, e di come evitare le trappole più comuni. [medium pause] Partiamo dalle basi. 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 affida a 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 phishare. Nessuna credenziale da rubare. Ecco perché il PCI DSS 4.0 e le linee guida zero-trust dell'NCSC indicano entrambi l'autenticazione basata su certificati per le reti del personale. [medium pause] Ora, l'architettura. Sono necessarie tre cose per far funzionare EAP-TLS. Primo, una Public Key Infrastructure: la vostra gerarchia di CA. Secondo, un meccanismo per trasferire i certificati sui dispositivi, ovvero SCEP o la vostra piattaforma MDM. Terzo, un server RADIUS che si fidi della vostra CA e possa convalidare i certificati client in tempo reale. [medium pause] La gerarchia delle CA è il punto in cui la maggior parte delle organizzazioni riscontra problemi fin da subito. Il modello corretto è quello a tre livelli. In cima si ha una Root CA, che dovrebbe essere offline, isolata (air-gapped) e portata online solo per firmare il certificato della CA intermedia. La CA intermedia, a volte chiamata Issuing CA, è quella che firma effettivamente i certificati quotidiani. È online, ma la sua chiave privata è ben protetta. Al di sotto di essa, si emettono due tipi di certificati: certificati server per l'infrastruttura RADIUS e certificati client per i dispositivi e gli utenti. [medium pause] Perché questo è importante? Perché se la Root CA viene compromessa, è necessario ricostruire l'intera PKI da zero e registrare nuovamente ogni dispositivo. Mantenerla offline elimina questo rischio. La CA intermedia può essere sostituita senza toccare la Root. Questo è l'argomento della resilienza operativa a favore del modello a tre livelli. [medium pause] Parliamo dei periodi di validità dei certificati. C'è stato un cambiamento significativo nel settore. Apple, Google e Mozilla si sono mossi tutti 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 automatici, piuttosto che certificati a lungo termine gestiti manualmente. Il motivo è semplice: una durata più breve 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, si possono quasi gestire i rinnovi manualmente. Se si hanno 5.000 dispositivi distribuiti su 50 siti, non è possibile. È necessario SCEP (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: la registrazione automatica basata su Criteri di gruppo tramite Active Directory Certificate Services. Il dispositivo si autentica nel dominio, la CA emette un certificato automaticamente 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 parliamo della revoca. Questo è l'aspetto su cui le organizzazioni investono meno spesso, ed è quello che conta di più quando qualcosa va storto. Se un dispositivo viene smarrito, rubato o se un dipendente lascia l'azienda, è necessario revocare immediatamente il relativo certificato. Esistono due meccanismi: CRL (Certificate Revocation Lists) e OCSP (Online Certificate Status Protocol). [medium pause] Il 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 ed effettua una verifica su di esso. Il problema del CRL è la latenza: se il 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 query al risponditore OCSP per ogni tentativo di autenticazione e riceve una risposta immediata di validità o revoca. Il compromesso è che il risponditore OCSP diventa una dipendenza critica: se non è disponibile, è necessario decidere se consentire l'accesso (fail open) o bloccarlo (fail closed). Per gli ambienti ad alta sicurezza, la risposta corretta è fail closed. Per gli ambienti operativi in cui la disponibilità è fondamentale, è possibile configurare un breve periodo di tolleranza OCSP. [medium pause] Permettetemi di presentarvi due scenari concreti per rendere il concetto più reale. [medium pause] Primo: un gruppo alberghiero con 150 strutture. Utilizzavano PEAP con una password condivisa per la WiFi del personale. La rotazione delle password era trimestrale, il che significava 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. Profili SCEP inviati a tutti i dispositivi Windows e iOS. Active Directory Certificate Services come CA. Il risultato: zero eventi di rotazione delle password, rinnovo dei certificati gestito automaticamente 30 giorni prima della scadenza e, quando un dipendente lasciava l'azienda, il suo certificato veniva revocato nell'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 per la reimpostazione delle password e i 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 in questo caso 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 puntati sullo stesso server SCEP supportato da una CA intermedia Microsoft ADCS. L'infrastruttura WiFi era Cisco Meraki, con autenticazione RADIUS gestita da un servizio RADIUS ospitato in cloud e 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 dalla scadenza. Ciò ha garantito una comoda finestra di rinnovo senza creare sovraccarico operativo. [medium pause] Ora, le insidie. Ce ne sono quattro che riscontro 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, verificate 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 concentrate. Se emettete tutti i certificati contemporaneamente con lo stesso periodo di validità, scadranno tutti nello stesso momento. Scaglionate l'emissione o, per lo meno, 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 si fida della vostra Root CA, rifiuterà il certificato del server RADIUS e l'autenticazione fallirà. Sembra ovvio, ma coglie impreparate le organizzazioni che hanno dispositivi BYOD o laptop di collaboratori esterni non registrati nell'MDM. [medium pause] Quarto: disponibilità del risponditore OCSP. Se il vostro risponditore OCSP va offline e il server RADIUS è configurato per bloccarsi 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 tolleranza con un monitoraggio adeguato. [medium pause] Bene, passiamo a una serie di domande rapide. [medium pause] Posso usare una CA pubblica per i certificati client EAP-TLS? Tecnicamente sì, ma all'atto pratico 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 benissimo e semplifica la distribuzione del trust. [medium pause] E per quanto riguarda il BYOD? Il BYOD è il caso più complesso. Non è possibile inviare i certificati ai 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] Come interagisce questo con il WPA3? WPA3-Enterprise impone la modalità di sicurezza a 192 bit per gli ambienti sensibili, il che richiede suite di cifratura specifiche. EAP-TLS è completamente compatibile con WPA3-Enterprise ed è, di fatto, il metodo di autenticazione consigliato. [medium pause] In sintesi. 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. Durata breve dei certificati con rinnovo automatico. Revoca in tempo reale tramite OCSP. Testare tutto, in particolare la revoca. E integrare il ciclo di vita dei certificati con il provider di identità - Microsoft Entra ID, Okta o Google Workspace - in modo che la revoca del certificato venga avviata automaticamente quando un account viene deprovisionato. [medium pause] Se si utilizzano 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 standard: non si è vincolati agli strumenti PKI di un singolo fornitore. [medium pause] Passi successivi: verificare l'inventario attuale dei certificati. Se non si sa quanti certificati si possiedono, quando scadono e chi li ha emessi, questa è la prima cosa da risolvere. Da lì, il percorso verso la completa automazione è ben definito. Grazie per l'ascolto.