Come configurare SCEP per il BYOD sicuro e l'autenticazione di rete 802.1X

Ciao e benvenuti a questo briefing tecnico di Purple. Sono il vostro ospite e oggi entreremo nei dettagli di SCEP - il Simple Certificate Enrollment Protocol - e di come configurarlo correttamente per un BYOD sicuro e l'autenticazione di rete 802.1X. Se siete un IT manager, un network architect o un CTO responsabile dell'infrastruttura WiFi in un gruppo alberghiero, una catena di negozi, uno stadio o un'organizzazione del settore pubblico, questo vi riguarda direttamente. Oggi non faremo teoria. Parleremo di architettura e decisioni. Iniziamo. [SEZIONE: Introduzione e contesto - circa 1 minuto] Ecco il problema che probabilmente state affrontando. Avete dispositivi del personale, laptop di collaboratori esterni e telefoni personali che necessitano tutti di accesso alla rete. Probabilmente avete un mix di dispositivi gestiti e non gestiti. E da qualche parte nella vostra infrastruttura c'è ancora una chiave precondivisa WPA2 che dodici persone conoscono, tre delle quali hanno lasciato l'azienda l'anno scorso. Questa non è una postura di sicurezza. È una vulnerabilità. La risposta è 802.1X, lo standard IEEE per il controllo dell'accesso alla rete basato su porta. Garantisce che nessun dispositivo trasmetta traffico finché non è stato esplicitamente autenticato. Ma l'802.1X è solo il framework. La vera domanda è quale metodo di autenticazione si trova al suo interno. E per il BYOD su larga scala, la risposta è EAP-TLS con certificati distribuiti tramite SCEP. Questo è ciò che analizzeremo oggi. [SEZIONE: Approfondimento tecnico - circa 5 minuti] Iniziamo con ciò che fa effettivamente SCEP. SCEP - Simple Certificate Enrollment Protocol - è stato originariamente pubblicato come Internet Draft dall'IETF nel 1999, creato by VeriSign. È stato formalizzato come RFC 8894. Il suo compito è semplice: automatizzare il processo di emissione di certificati digitali X.509 ai dispositivi su larga scala, senza richiedere a una persona di generare e installare manualmente ciascuno di essi. Ecco il flusso in quattro passaggi. Passaggio uno: il dispositivo si connette a un endpoint SCEP, un URL ospitato on-premises tramite un ruolo di Windows Server chiamato NDES (Network Device Enrollment Service) o tramite un provider PKI cloud. Questo URL è il gateway per la vostra Certificate Authority. Passaggio due: il dispositivo presenta una challenge SCEP, un segreto condiviso che dimostra che è autorizzato a richiedere un certificato. In un ambiente gestito da MDM come Microsoft Intune, questa challenge viene fornita in modo dinamico e univoco per dispositivo, il che è molto più sicuro di una password statica condivisa tra tutti i dispositivi. Passaggio tre: il dispositivo genera localmente la propria coppia di chiavi privata e pubblica. Crea una Certificate Signing Request (CSR) utilizzando la chiave pubblica e la invia al server SCEP. Ecco il punto critico per la sicurezza: la chiave privata non lascia mai il dispositivo. Viene generata localmente, memorizzata nell'enclave sicura del dispositivo (il TPM su Windows o la Secure Enclave su iOS) e non viene mai trasmessa. Ecco perché SCEP è la scelta giusta per l'autenticazione di rete, a differenza di PKCS, in cui la CA genera la chiave centralmente e deve inviarla al dispositivo. Passaggio quattro: la Certificate Authority convalida la CSR, la firma con la chiave privata della CA e restituisce il certificato X.509 firmato al dispositivo. Il dispositivo ora ha un'identità crittografica univoca. Ora, come viene utilizzato questo certificato per l'autenticazione 802.1X? Quando il dispositivo si connette al vostro SSID WiFi, l'access point (che si tratti di Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist o Ubiquiti UniFi) funge da autenticatore. Non prende direttamente la decisione di autenticazione, ma inoltra lo scambio EAP al vostro server RADIUS. Questo potrebbe essere Microsoft NPS, Cisco ISE o Aruba ClearPass. Il server RADIUS avvia un handshake EAP-TLS. Il dispositivo presenta il suo certificato client fornito tramite SCEP. Il server RADIUS convalida tre elementi: la catena di certificati fino alla CA radice attendibile, la data di scadenza del certificato e se il certificato è stato revocato, verificandolo rispetto a una Certificate Revocation List (CRL) o tramite OCSP (Online Certificate Status Protocol). Se tutti e tre i controlli hanno esito positivo, il server RADIUS invia un messaggio EAP-Success e l'access point apre la porta. Il dispositivo è sulla rete. Questa è un'autenticazione reciproca. Il dispositivo convalida anche il certificato del server RADIUS. Se qualcuno configura un access point non autorizzato, il dispositivo lo rifiuterà perché il certificato del server non verrà convalidato rispetto alla CA attendibile. Questa è la vostra protezione contro gli attacchi evil twin. Ora parliamo della sequenza di distribuzione in Microsoft Intune, poiché è la piattaforma MDM più comune che vediamo negli ambienti aziendali. Si distribuiscono tre profili di configurazione di Intune, in ordine rigoroso. Primo, il profilo Trusted Root Certificate: questo invia il certificato della CA radice a ogni dispositivo in modo che si fidi della vostra PKI. Secondo, il profilo SCEP Certificate: questo indica ai dispositivi l'URL SCEP, il formato del nome del soggetto, l'utilizzo della chiave e l'utilizzo esteso della chiave per l'autenticazione client. L'OID per l'autenticazione client è 1.3.6.1.5.5.7.3.2. Terzo, il profilo WiFi: questo specifica l'SSID, imposta il tipo di sicurezza su WPA2-Enterprise o WPA3-Enterprise, imposta il tipo EAP su EAP-TLS e si collega al profilo del certificato SCEP. L'ordine è importante. Il profilo WiFi ha una dipendenza dal profilo SCEP, che a sua volta ha una dipendenza dal profilo Trusted Root. Se li distribuite fuori sequenza, otterrete degli errori. Una decisione architetturale da prendere riguarda dove ospitare il server NDES. Deve essere raggiungibile da Internet in modo che i dispositivi possano registrarsi prima di arrivare in sede. Il modo sicuro per farlo è pubblicare l'URL NDES tramite Microsoft Entra ID Application Proxy. Questo evita di aprire porte in entrata nel firewall e consente di applicare criteri di accesso condizionale al flusso di registrazione. Per le organizzazioni che desiderano eliminare completamente l'infrastruttura on-premises, i provider PKI cloud (come Cloud PKI di Microsoft in Intune o opzioni di terze parti) rimuovono completamente la dipendenza da NDES. [SEZIONE: Raccomandazioni di implementazione ed errori comuni - circa 2 minuti] Permettetemi di elencarvi i tre scenari di errore più comuni che riscontriamo. Scenario di errore uno: mancata corrispondenza nella destinazione dei gruppi. Questa è la causa più frequente di errori di distribuzione dei profili WiFi in Intune. Se il profilo Trusted Root è assegnato a un gruppo di Utenti, il profilo SCEP a un gruppo di Dispositivi e il profilo WiFi a un gruppo di Utenti diverso, Intune non può risolvere la catena di dipendenze. Tutti e tre i profili devono avere come destinazione lo stesso identico gruppo Azure AD (tutti gli Utenti o tutti i Dispositivi). Sceglietene uno e siate coerenti. Scenario di errore due: disponibilità della CRL. Il server RADIUS controlla la CRL per verificare che i certificati non siano stati revocati. Se il CRL Distribution Point (l'URL CDP incorporato nel certificato) non è raggiungibile, l'autenticazione fallisce per ogni dispositivo. Questa è una causa comune di interruzioni di massa dopo modifiche alla rete. Assicuratevi che i vostri CDP siano altamente disponibili, idealmente pubblicati sia su un URL interno che su un URL esterno per i dispositivi remoti. Considerate l'OCSP come un'alternativa più resiliente al controllo della CRL. Scenario di errore tre: mancata imposizione della convalida del certificato del server sui client. Questa è la singola configurazione errata con il maggiore impatto nelle distribuzioni 802.1X. Se il profilo WiFi distribuito tramite MDM non specifica la CA attendibile e il nome del server RADIUS previsto, i dispositivi si connetteranno a qualsiasi server che presenti un certificato qualsiasi. Ciò vanifica l'intero scopo di EAP-TLS. Configurate sempre la convalida del server nel vostro profilo WiFi. [SEZIONE: Domande e risposte rapide - circa 1 minuto] Facciamo qualche domanda rapida. Domanda: Abbiamo bisogno di WPA3? Sì. Migrate a WPA3-Enterprise. Rende obbligatori i Protected Management Frames, bloccando gli attacchi di deautenticazione. Tutto l'hardware di Cisco Meraki, HPE Aruba, Ruckus e Juniper Mist lo supporta. Domanda: E per i dispositivi che non supportano l'802.1X, come i sensori IoT o le stampanti legacy? Utilizzate il MAC Authentication Bypass come fallback, ma collocate tali dispositivi su una VLAN fortemente limitata senza accesso alle risorse aziendali. Domanda: Come si inserisce Purple in tutto questo? La piattaforma Guest WiFi di Purple gestisce il livello di accesso per visitatori e ospiti: il Captive Portal, l'acquisizione dei dati, la reportistica. La vostra infrastruttura 802.1X e SCEP gestisce l'accesso del personale e dei dispositivi gestiti. Funzionano su SSID separati e VLAN separate. Purple si integra con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet, proteggendo così il vostro investimento hardware. [SEZIONE: Riepilogo e passaggi successivi - circa 1 minuto] Per concludere. SCEP automatizza l'emissione dei certificati su larga scala. La chiave privata rimane sul dispositivo: questo è il vantaggio in termini di sicurezza rispetto a PKCS. Distribuite tramite MDM in sequenza rigorosa: Trusted Root, poi profilo SCEP, infine profilo WiFi, tutti con lo stesso gruppo di destinazione. Pubblicate NDES tramite Application Proxy o passate a una PKI cloud. Imponete il controllo CRL o OCSP sul vostro server RADIUS. E configurate sempre la convalida del certificato del server sui supplicant dei client. Se utilizzate ancora una chiave precondivisa per il WiFi del personale, questo è il cambiamento da fare in questo trimestre. L'infrastruttura dei certificati richiede più lavoro iniziale, ma elimina un'intera classe di attacchi basati su credenziali e in genere riduce i ticket di assistenza relativi al WiFi del 70-80% una volta implementata. Per la guida tecnica completa, i diagrammi architetturali e gli esempi pratici, visitate purple.ai. Grazie per l'ascolto.