Guida alla configurazione di SCEP Enterprise: Autenticazione Wi-Fi basata su certificati per l'istruzione superiore e le grandi reti

Guida alla configurazione SCEP aziendale: autenticazione WiFi basata su certificati per l'istruzione superiore e le grandi reti Un briefing tecnico di Purple - Scaletta 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 finisce spesso nella casella di posta dei dipartimenti IT, ma che raramente riceve una risposta chiara: come implementare concretamente l'autenticazione WiFi basata su certificati su larga scala, utilizzando SCEP, in una rete complessa, che si tratti di un campus universitario, di un gruppo alberghiero multi-sito o di un grande patrimonio del settore pubblico? Esamineremo il quadro completo. Cosa fa effettivamente lo SCEP, come si inserisce in un'architettura 802.1X, la sequenza di implementazione in cui la maggior parte dei team sbaglia, due scenari di implementazione reali e le insidie che vi costeranno un fine settimana di lavoro se non le pianificate in tempo. Questo è un briefing di consulenza, non un tutorial. Do per scontato che sappiate cos'è un server RADIUS e che abbiate probabilmente già deciso di abbandonare le chiavi precondivise. Quello di cui avete bisogno ora è la mappa di implementazione. Entriamo nel vivo. --- APPROFONDIMENTO TECNICO - circa 5 minuti Partiamo dai principi fondamentali. SCEP sta per Simple Certificate Enrollment Protocol. È stato formalizzato dall'IETF come RFC 8894 nel 2020, anche se era già ampiamente utilizzato 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 manuale su ciascuna macchina. Nel contesto dell'autenticazione WiFi, SCEP è il meccanismo di distribuzione. Il protocollo di autenticazione effettivo a cui si mira è 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 che sia il dispositivo client sia il server RADIUS presentino 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 non autorizzato per sottrarre 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 in cloud, e una password di verifica o un segreto condiviso. Il dispositivo genera localmente la propria coppia di chiavi pubblica e privata. Questo è un passaggio critico. 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 rispetto alla 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, vediamo dove si posiziona SCEP rispetto all'alternativa, ovvero PKCS. Lo standard PKCS (Public Key Cryptography Standards) è l'altro metodo di distribuzione dei certificati supportato da piattaforme come Intune. Con 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. PKCS è ideale per casi d'uso come la crittografia delle e-mail S/MIME, dove l'escrow delle chiavi è effettivamente auspicabile. Per l'autenticazione WiFi, SCEP è la scelta corretta. La chiave privata rimane sul dispositivo, senza eccezioni. Infine, lo strato hardware. SCEP ed EAP-TLS sono standard indipendenti dal fornitore, il che significa che funzionano su access point Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Nella configurazione del tuo RADIUS (che si tratti di Windows NPS, FreeRADIUS o di un servizio RADIUS in cloud) definisci la policy di convalida dei certificati e, soprattutto, configuri l'assegnazione dinamica delle 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 è gestito dagli attributi del certificato e dalla policy RADIUS, senza alcun intervento manuale sul singolo dispositivo. Per l'integrazione con l'identity provider, gli attributi del certificato SCEP - in particolare 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 disattiva un account in Entra ID e l'MDM rimuove 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, infine il profilo WiFi. Sia Intune che Jamf impongono dipendenze tra i profili. Se il 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 un'errata configurazione ma che 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 si rivolge a un gruppo di utenti e il profilo WiFi si rivolge a un gruppo di dispositivi, Intune non può risolvere la dipendenza e il profilo WiFi risulterà come Non Applicabile. Questo trae in inganno i team di continuo. Terzo: accessibilità del server NDES. Il 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 offre un accesso remoto sicuro senza porte in entrata e consente di applicare criteri di Conditional Access al flusso di registrazione. Quarto: disponibilità della CRL. Il server RADIUS controlla l'elenco di revoca dei certificati (CRL) ogni volta che un dispositivo si autentica. Se il punto di distribuzione della CRL non è disponibile - perché un server è inattivo o l'URL è cambiato - l'autenticazione fallisce contemporaneamente per ogni dispositivo sulla rete. Questo significa un'interruzione a livello di intero campus. Rendete gli endpoint CRL altamente disponibili e testate la revoca prima di andare online. Per le reti di grandi dimensioni - oltre i 500 dispositivi - prendete in considerazione 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 Lo SCEP può gestire i dispositivi BYOD che non sono registrati nell'MDM? Non direttamente. Lo SCEP richiede la registrazione MDM per inviare il payload del certificato. Per i BYOD non gestiti, è necessario un approccio diverso: un portale di onboarding self-service o un SSID separato che utilizzi un Captive Portal con verifica dell'identità. La piattaforma di Purple gestisce in modo pulito questo livello di ospiti e BYOD, affiancandosi alla rete del personale autenticata tramite certificato. E per quanto riguarda 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 raccomandata 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 VLAN dinamica e si integra direttamente con il tuo identity provider per la revoca automatizzata. La sequenza di implementazione - Trusted Root, poi profilo SCEP, infine profilo WiFi - è fissa. Il targeting dei gruppi deve essere coerente. La disponibilità della CRL non è opzionale. In particolare 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, garantisce sia la sicurezza che un'ottima esperienza utente senza compromessi. Se desideri approfondire, la guida di Purple sull'autenticazione WiFi enterprise senza Active Directory o un server on-premises copre il percorso cloud-native. E se stai pensando a cosa succede quando un dipendente lascia l'azienda, la nostra guida sulla revoca dell'accesso WiFi illustra l'intero workflow di revoca. Grazie per l'attenzione. Sono del team tecnico di Purple e ci vediamo al prossimo briefing. --- FINE DELLO SCRIPT