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

Speak in British English with a confident, authoritative, and conversational tone - like a senior consultant briefing a client. Measured pace, clear diction, warm but direct. Occasional natural pauses for emphasis: Benvenuti nella 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 scala senza che diventi un onere operativo a tempo pieno. [medium pause] 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 del certificato: dalla configurazione della gerarchia della CA, attraverso l'implementazione 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] 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 un nome utente e una password, EAP-TLS utilizza un'autenticazione reciproca basata su certificati. Il dispositivo prova la sua identità con un certificato client. Il server RADIUS prova la sua identità con un certificato server. Entrambe le parti verificano l'altra. Nessuna password da violare tramite phishing. Nessuna credenziale da rubare. Ecco perché il PCI-DSS 4.0 e la guida zero-trust del 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 installare i certificati sui dispositivi - cioè lo 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 incontra presto difficoltà. Il modello corretto è un modello a tre livelli. Avete una Root CA in cima - questa dovrebbe essere offline, isolata fisicamente, e attivata online solo per firmare il certificato della vostra 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, emettete due tipi di certificati: certificati server per la vostra infrastruttura RADIUS e certificati client per i vostri dispositivi e utenti. [medium pause] Perché questo è importante? Perché se la vostra Root CA viene compromessa, dovete 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. Questa è la tesi 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 hanno imposto una durata massima dei certificati più breve. 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 è una durata comune - ma la tendenza è verso durate più brevi e il rinnovo automatizzato rispetto a 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. Con 500 dispositivi, si riescono a gestire i rinnovi a mano con un po' di fatica. Se i dispositivi diventano 5.000 in 50 sedi diverse, non è più possibile. È necessario ricorrere a SCEP - Simple Certificate Enrolment Protocol - o al 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 da criteri di gruppo tramite Active Directory Certificate Services. Il dispositivo si autentica nel dominio, la CA emette automaticamente un certificato e quest'ultimo viene rinnovato prima della scadenza senza alcun intervento manuale. Questo è il percorso più lineare per le infrastrutture con una forte presenza di Windows. [medium pause] Ora, la revoca. Questa è la parte su cui le aziende spesso investono meno, ed è la parte 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 suo certificato. Esistono due meccanismi: CRL - Certificate Revocation Lists - e OCSP - Online Certificate Status Protocol. [medium pause] CRL è il meccanismo più datato. 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 con 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 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 comunque l'accesso o bloccarlo. Per gli ambienti ad alta sicurezza, il blocco dell'accesso è la scelta corretta. Per gli ambienti operativi in cui la disponibilità è fondamentale, è possibile configurare un breve periodo di tolleranza OCSP. [medium pause] Vorrei presentarvi due scenari concreti per rendere tutto questo più tangibile. [medium pause] Primo: un gruppo alberghiero con 150 proprietà. 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. I profili SCEP sono stati distribuiti a tutti i dispositivi Windows e iOS. Active Directory Certificate Services è stato configurato 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 se ne andava, il suo certificato veniva revocato nell'MDM entro pochi minuti dalla disattivazione del suo account in Microsoft Entra ID. Il team IT ha stimato di aver risparmiato circa 40 ore a trimestre in reimpostazioni di password e ticket di assistenza. [medium pause] Secondo: una catena di vendita al dettaglio multisede 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. Hanno utilizzato 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 autenticazione RADIUS gestita da un servizio RADIUS ospitato nel 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 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 funziona 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 improvvise di massa. Se emettete tutti i certificati nello stesso momento con lo stesso periodo di validità, scadranno tutti contemporaneamente. 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 CA radice a tutti i dispositivi prima di implementare EAP-TLS. Se il dispositivo non si fida della vostra CA radice, 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 nell'MDM. [medium pause] Quarto: disponibilità del risponditore OCSP. Se il risponditore OCSP va offline e il server RADIUS è configurato per negare l'accesso 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 usare 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 la propria CA 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 il BYOD? Il BYOD è il caso più difficile. Non è possibile distribuire 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] In che modo questo 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 la corretta architettura fin dall'inizio. Gerarchia CA a tre livelli. Registrazione automatizzata tramite SCEP o MDM. Cicli di vita dei certificati brevi con rinnovo automatico. Revoca in tempo reale tramite OCSP. Testate tutto, in particolare la revoca. E integrate il ciclo di vita dei certificati con il vostro provider di identità - 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 tutto il resto dell'elenco hardware canonico - non siete vincolati agli strumenti PKI di un singolo fornitore. [medium pause] 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 la completa automazione è ben definito. Grazie per l'ascolto.