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

Ciao e benvenuti a questo briefing tecnico di Purple. Sono il vostro presentatore e oggi entreremo nei dettagli del protocollo SCEP - Simple Certificate Enrollment Protocol - e di come configurarlo correttamente per un accesso sicuro ai dispositivi BYOD e per l'autenticazione di rete 802.1X. Se siete responsabili IT, architetti di rete o CTO responsabili dell'infrastruttura WiFi di un gruppo alberghiero, di un patrimonio retail, di uno stadio o di un'organizzazione del settore pubblico, questo argomento vi riguarda direttamente. Oggi non faremo teoria. Parleremo di architettura e decisioni. Cominciamo. [SEZIONE: Introduzione e contesto - circa 1 minuto] Ecco il problema che probabilmente vi trovate ad affrontare. Avete dispositivi del personale, laptop di collaboratori esterni e telefoni personali che hanno tutti bisogno di accedere alla rete. Probabilmente avete un mix di dispositivi gestiti e non gestiti. E da qualche parte nella vostra infrastruttura c'è ancora una chiave pre-condivisa WPA2 che dodici persone conoscono, tre delle quali hanno lasciato l'azienda l'anno scorso. Questa non è una postura di sicurezza. Questa è una vulnerabilità. La risposta è 802.1X - lo standard IEEE per il controllo dell'accesso alla rete basato su porta. Assicura che nessun dispositivo trasmetta traffico finché non è stato esplicitamente autenticato. Ma 802.1X è solo il framework. La vera domanda è quale metodo di autenticazione risieda al suo interno. E per il BYOD su scala, la risposta è EAP-TLS con certificati distribuiti tramite SCEP. Questo è ciò che analizzeremo oggi. [SEZIONE: Approfondimento tecnico - circa 5 minuti] Iniziamo con quello che fa effettivamente il protocollo SCEP. Lo SCEP - Simple Certificate Enrollment Protocol - è stato originariamente pubblicato come Internet Draft dall'IETF nel 1999, creato da VeriSign. È stato formalizzato come RFC 8894. Il suo compito è semplice: automatizzare il processo di emissione di certificati digitali X.509 ai dispositivi su scala, senza richiedere che un operatore umano generi e installi manualmente ciascuno di essi. Ecco il flusso in quattro passaggi. Fase 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 Autorità di Certificazione. Fase due: il dispositivo presenta una richiesta di verifica SCEP - un segreto condiviso che dimostra che è autorizzato a richiedere un certificato. In un ambiente gestito da MDM come Microsoft Intune, questa richiesta di verifica viene fornita in modo dinamico e univoco per ogni dispositivo, il che è molto più sicuro di una password statica condivisa tra tutti i dispositivi. Fase tre: il dispositivo genera localmente la propria coppia di chiavi privata e pubblica. Crea una richiesta di firma del certificato - una 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 - ovvero il TPM su Windows o il Secure Enclave su iOS - e non viene mai trasmessa. Questo è il motivo per cui 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. Fase quattro: l'Autorità di Certificazione convalida la richiesta CSR, la firma con la chiave privata della CA e restituisce il certificato X.509 firmato al dispositivo. Il dispositivo possiede ora un'identità crittografica unica. Ora, come viene utilizzato questo certificato per l'autenticazione 802.1X? Quando il dispositivo si connette al tuo 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 tuo server RADIUS, che potrebbe essere Microsoft NPS, Cisco ISE o Aruba ClearPass. Il server RADIUS avvia un handshake EAP-TLS. Il dispositivo presenta il proprio certificato client fornito tramite SCEP. Il server RADIUS convalida tre elementi: la catena dei certificati fino alla CA radice attendibile, la data di scadenza del certificato e se il certificato è stato revocato - verificandolo rispetto a un elenco di revoca dei certificati, o CRL, o tramite OCSP, l'Online Certificate Status Protocol. Se tutti e tre i controlli vanno a buon fine, il server RADIUS invia un messaggio di EAP-Success e l'access point apre la porta. Il dispositivo è connesso alla rete. Questa è un'autenticazione reciproca. Anche il dispositivo convalida il certificato del server RADIUS. Se qualcuno configura un access point fittizio, il dispositivo lo rifiuterà poiché il certificato del server non verrà convalidato dalla CA attendibile. Questa è la tua protezione contro gli attacchi "evil twin". Parliamo ora della sequenza di implementazione in Microsoft Intune, poiché si tratta della piattaforma MDM più comune che riscontriamo negli ambienti enterprise. È necessario distribuire tre profili di configurazione di Intune, in ordine rigoroso. Primo, il profilo Trusted Root Certificate - questo distribuisce il certificato della CA radice su ogni dispositivo in modo che considerino attendibile la tua PKI. Secondo, il profilo SCEP Certificate - questo comunica ai dispositivi l'URL SCEP, il formato del nome del soggetto, l'utilizzo della chiave e l'utilizzo esteso della chiave per l'autenticazione del client. L'OID per l'autenticazione del 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, definisce il tipo di EAP su EAP-TLS e lo collega al profilo del certificato SCEP. L'ordine è fondamentale. Il profilo WiFi ha una dipendenza dal profilo SCEP, il quale a sua volta dipende dal profilo Trusted Root. Se li distribuisci fuori sequenza, riceverai degli errori. Una decisione architetturale da prendere riguarda dove ospitare il server NDES. Questo 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. In questo modo si evita di aprire porte in entrata sul firewall e si possono applicare i criteri di accesso condizionale al flusso di registrazione. Per le organizzazioni che desiderano eliminare completamente l'infrastruttura on-premise, i provider di PKI cloud - come Cloud PKI di Microsoft in Intune o opzioni di terze parti - eliminano del tutto la dipendenza da NDES. [SECTION: Raccomandazioni di implementazione ed errori comuni - circa 2 minuti] Lasciate che vi mostri le tre modalità di errore più comuni che riscontriamo. Modalità di errore uno: mancata corrispondenza del target di gruppo. Questa è la causa più frequente di fallimento del deployment dei profili WiFi in Intune. Se il profilo Trusted Root è assegnato a un gruppo Utenti, il profilo SCEP a un gruppo Dispositivi e il profilo WiFi a un gruppo Utenti diverso, Intune non può risolvere la catena di dipendenze. Tutti e tre i profili devono avere come target lo stesso identico gruppo Azure AD - o tutti Utenti o tutti Dispositivi. Sceglietene uno e siate coerenti. Modalità 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 le 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 OCSP come un'alternativa più resiliente al controllo CRL. Modalità di errore tre: mancata imposizione della convalida del certificato del server sui client. Questa è l'errata configurazione in assoluto più impattante nei deployment 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 qualsiasi certificato. Questo vanifica l'intero scopo di EAP-TLS. Configurate sempre la convalida del server nel vostro profilo WiFi. [SECTION: Domande e Risposte Rapide - circa 1 minuto] Facciamo qualche domanda rapida. Domanda: Abbiamo bisogno di WPA3? Sì. Passate a WPA3-Enterprise. Questo impone 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 quanto riguarda i dispositivi che non supportano l'802.1X - come i sensori IoT o le stampanti legacy? Utilizzate il MAC Authentication Bypass come fallback, ma posizionate questi 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 dei visitatori e degli ospiti - il Captive Portal, la cattura dei dati, l'analitica. La vostra infrastruttura 802.1X e SCEP gestisce l'accesso del personale e dei dispositivi gestiti. Operano su SSID separati e VLAN separate. Purple si integra con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet - salvaguardando così il vostro investimento hardware. [SECTION: Riepilogo e Prossimi Passi - circa 1 minuto] Per concludere. SCEP automatizza l'emissione dei certificati su scala. La chiave privata rimane sul dispositivo - questo è il vantaggio in termini di sicurezza rispetto a PKCS. Eseguite il deployment tramite MDM in sequenza rigorosa: Trusted Root, poi profilo SCEP, infine profilo WiFi, puntando tutti allo stesso gruppo. Pubblicate NDES tramite Application Proxy o passate a una PKI in 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 si sta ancora utilizzando una chiave pre-condivisa comune 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 solitamente riduce i ticket di assistenza relativi al WiFi del 70 - 80 percento una volta distribuita. Per la guida tecnica completa, i diagrammi di architettura e gli esempi pratici, visita purple dot ai. Grazie per l'ascolto.