Guida alla configurazione SCEP Enterprise: autenticazione WiFi basata su certificati per l'istruzione superiore e grandi reti

Guida alla configurazione SCEP Enterprise: autenticazione WiFi basata su certificati per l'istruzione superiore e le grandi reti Un briefing tecnico di Purple - Sceneggiatura del podcast (circa 10 minuti) --- INTRODUZIONE E CONTESTO - circa 1 minuto Benvenuti alla serie di briefing tecnici di Purple. Oggi parlerò di un argomento che arriva in molte caselle di posta dell'IT ma che raramente riceve una risposta chiara: come si distribuisce effettivamente l'autenticazione WiFi basata su certificati su scala, utilizzando SCEP, su una rete di grandi dimensioni - che si tratti di un campus universitario, di un gruppo alberghiero multisede o di un grande patrimonio del settore pubblico? Copriremo il quadro completo. Cosa fa effettivamente SCEP, come si inserisce in un'architettura 802.1X, la sequenza di implementazione che la maggior parte dei team sbaglia, due scenari di implementazione reali e le insidie che vi costeranno un intero fine settimana se non le pianificate in anticipo. Questo è un briefing per consulenti, non un tutorial. Presumo che sappiate cos'è un server RADIUS e che abbiate probabilmente già deciso di abbandonare le chiavi pre-condivise. Ciò di cui avete bisogno ora è la mappa di implementazione. Entriamo nel vivo. --- APPROFONDIMENTO TECNICO - circa 5 minuti Quindi, partiamo dai principi fondamentali. SCEP sta per Simple Certificate Enrollment Protocol. È stato formalizzato dall'IETF come RFC 8894 nel 2020, sebbene fosse già in uso diffuso a livello aziendale da oltre un decennio prima. Il suo compito è semplice: automatizzare il processo di installazione di un certificato digitale su un dispositivo gestito senza richiedere l'intervento umano su ogni macchina. Nel contesto dell'autenticazione WiFi, SCEP è il meccanismo di distribuzione. Il protocollo di autenticazione effettivo a cui vi rivolgete è EAP-TLS - Extensible Authentication Protocol con Transport Layer Security - che si colloca all'interno del framework 802.1X. EAP-TLS è ampiamente considerato come il metodo di autenticazione più sicuro per le reti wireless aziendali perché richiede sia al dispositivo client che al server RADIUS di presentare certificati validi. Nessuna delle due parti si fida dell'altra senza una prova crittografica. Questa autenticazione reciproca è ciò che protegge dagli attacchi di tipo "evil twin" - in cui un utente malintenzionato attiva un access point canaglia per sottrarre le credenziali. Ecco come funziona l'intera catena. Un dispositivo gestito - il laptop di uno studente, il telefono di un dipendente, un terminale point-of-sale di un hotel - deve connettersi alla rete wireless aziendale. La tua piattaforma MDM, che potrebbe essere Microsoft Intune o Jamf, invia un payload SCEP a quel dispositivo. Il payload contiene due elementi: l'URL SCEP, che punta al tuo server NDES o al gateway SCEP cloud, e una password di verifica o segreto condiviso. Il dispositivo genera localmente la propria coppia di chiavi pubblica e privata. Questo passaggio è fondamentale. La chiave privata non lascia mai il dispositivo. Viene generata sul dispositivo, memorizzata nell'enclave sicura o nel TPM, e non viene mai trasmessa in rete. Il dispositivo crea quindi una Certificate Signing Request - una CSR - e la invia al gateway SCEP. Il gateway convalida la verifica, inoltra la CSR alla tua Certificate Authority, e la CA la firma restituendo il certificato pubblico al dispositivo. Da quel momento in poi, quando il dispositivo si connette al tuo SSID WiFi, presenta quel certificato al server RADIUS. Il server RADIUS convalida il certificato confrontandolo con la catena di attendibilità della tua CA, controlla la Certificate Revocation List per confermare che il certificato non sia stato revocato e, se tutto è in regola, invia un messaggio di accettazione all'access point. Il dispositivo è connesso alla rete. L'intero processo è invisibile per l'utente. Ora, analizziamo la differenza tra SCEP e l'alternativa, ovvero PKCS. Lo standard PKCS - Public Key Cryptography Standards - è l'altro metodo di distribuzione dei certificati supportato da piattaforme come Intune. Con il PKCS, la CA genera sia la chiave pubblica che quella privata a livello centrale, e il connettore del certificato invia la coppia di chiavi al dispositivo. Ciò significa che la chiave privata viaggia sulla rete, introducendo una potenziale superficie di attacco. Il PKCS è adatto per casi d'uso come la crittografia e-mail S/MIME, dove il deposito delle chiavi è effettivamente auspicabile. Per l'autenticazione WiFi, SCEP è la scelta corretta. La chiave privata rimane sul dispositivo, senza eccezioni. Infine, il livello hardware. SCEP ed EAP-TLS sono standard aperti e indipendenti dai fornitori, il che significa che funzionano su access point Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. La tua configurazione RADIUS - che si tratti di Windows NPS, FreeRADIUS o di un servizio RADIUS cloud - è il luogo in cui definisci la policy di convalida dei certificati e, soprattutto, dove configuri l'assegnazione dinamica della VLAN. Le VLAN dinamiche consentono di segmentare la rete in base all'identità. Il dispositivo di uno studente ottiene la VLAN 20 - solo accesso a Internet. Il dispositivo di un docente ottiene la VLAN 10 - accesso ai sistemi di ricerca interni. Un dispositivo di gestione della struttura ottiene la VLAN 30 - accesso ai sistemi di gestione dell'edificio. Tutto questo è guidato dagli attributi del certificato e dalla policy RADIUS, senza alcun intervento manuale per singolo dispositivo. Per l'integrazione con l'identity provider, gli attributi del certificato SCEP - nello specifico il Subject Alternative Name - possono contenere il nome principale dell'utente da Microsoft Entra ID, Okta o Google Workspace. Questo lega il certificato a un'identità specifica, il che significa che quando si disabilita un account in Entra ID e l'MDM annulla la registrazione del dispositivo, il certificato viene revocato e l'accesso WiFi viene interrotto automaticamente. Questa è la storia di revoca che le chiavi pre-condivise semplicemente non possono offrire. - RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE COMUNI - circa 2 minuti Bene, parliamo della sequenza di implementazione, perché è qui che la maggior parte dei team inciampa. La sequenza non è negoziabile: prima il certificato Trusted Root, poi il profilo del certificato SCEP e infine il profilo WiFi. Intune e Jamf applicano entrambi le dipendenze del profilo. Se il tuo profilo WiFi fa riferimento a un certificato SCEP che non è ancora stato distribuito sul dispositivo, il profilo WiFi fallirà con un errore criptico che sembra una configurazione errata ma è in realtà solo un problema di tempistica. La seconda trappola è il targeting dei gruppi. Tutti e tre i profili - Trusted Root, SCEP e WiFi - devono essere distribuiti esattamente allo stesso gruppo Azure AD o Jamf. Se il profilo SCEP ha come target un gruppo di utenti e il profilo WiFi ha come target un gruppo di dispositivi, Intune non può risolvere la dipendenza e il profilo WiFi mostrerà lo stato Not Applicable. Questo coglie costantemente i team alla sprovvista. Terzo: accessibilità del server NDES. Il tuo server NDES deve essere raggiungibile da Internet in modo che i dispositivi possano registrarsi prima di arrivare in sede. Il modo corretto per farlo è tramite Azure AD Application Proxy, non aprendo una porta nel firewall. App Proxy ti offre un accesso remoto sicuro senza porte in entrata e ti consente di applicare i criteri di Conditional Access al flusso di registrazione. Quarto: disponibilità della CRL. Il tuo server RADIUS controlla la Certificate Revocation List ogni volta che un dispositivo si autentica. Se il tuo CRL Distribution Point non è disponibile - perché un server è spento o l'URL è cambiato - l'autenticazione fallisce per ogni dispositivo sulla rete contemporaneamente. Questo significa un'interruzione a livello di intero campus. Rendi i tuoi endpoint CRL altamente disponibili e testa la revoca prima di andare online. Per le reti di grandi dimensioni - qualsiasi cosa sopra i 500 dispositivi - considera un gateway SCEP cloud piuttosto che un NDES on-premises. I gateway cloud eliminano il single point of failure di NDES, scalano orizzontalmente e in genere si integrano direttamente con i servizi RADIUS cloud, rimuovendo un'altra dipendenza infrastrutturale. - DOMANDE E RISPOSTE RAPIDE - circa 1 minuto SCEP può gestire dispositivi BYOD che non sono registrati nell'MDM? Non direttamente. SCEP richiede la registrazione MDM per inviare il payload del certificato. Per i BYOD non gestiti, serve un approccio diverso - un portale di onboarding self-service o un SSID separato che utilizza un Captive Portal con verifica dell'identità. La piattaforma di Purple gestisce questo livello di ospiti e BYOD in modo pulito, affiancandosi alla rete del personale autenticata tramite certificato. Che dire di iOS e Android? Entrambe le piattaforme supportano SCEP nativamente. iOS supporta SCEP fin da iOS 4. Android Enterprise supporta SCEP tramite Intune e altri MDM. La configurazione è leggermente diversa per ciascuna piattaforma, ma il protocollo sottostante è identico. EAP-TLS funziona con WPA3? Sì. WPA3-Enterprise impone la modalità di sicurezza a 192 bit per gli ambienti sensibili e EAP-TLS è completamente compatibile. Di fatto, WPA3-Enterprise con EAP-TLS è la combinazione consigliata dalla Wi-Fi Alliance per le reti governative e finanziarie. - RIASSUNTO E PROSSIMI PASSI - circa 1 minuto Per riassumere. L'autenticazione WiFi tramite certificati SCEP è l'architettura corretta per qualsiasi rete con più di 50 dispositivi gestiti. Elimina le credenziali condivise, offre un'identità per singolo dispositivo, consente la segmentazione dinamica delle VLAN e si integra direttamente con il vostro provider di identità per la revoca automatizzata. La sequenza di distribuzione - prima Trusted Root, poi profilo SCEP, infine profilo WiFi - è fissa. Il targeting dei gruppi deve essere coerente. La disponibilità della CRL non è opzionale. Nello specifico per l'istruzione superiore, la combinazione di SCEP per i dispositivi del personale e dei docenti, insieme a un livello WiFi guest separato per gli studenti sui dispositivi personali, offre sia sicurezza sia un'ottima esperienza utente senza compromessi. Se desiderate approfondire, la guida di Purple sull'autenticazione WiFi aziendale senza Active Directory o un server on-premises copre il percorso cloud-native. E se state pensando a cosa succede quando un dipendente lascia l'azienda, la nostra guida sulla revoca dell'accesso WiFi illustra l'intero flusso di lavoro di revoca. Grazie per l'attenzione. Sono del team tecnico di Purple e ci vediamo al prossimo briefing. - FINE DELLO SCRIPT