Configurazione di SCEP per l'autenticazione sicura WiFi e BYOD nel settore dell'istruzione superiore

Benvenuti al Purple Technical Briefing. Sono il vostro ospite e oggi parleremo di un argomento ricorrente nel settore IT dell'istruzione superiore: l'implementazione di SCEP per l'autenticazione sicura di BYOD e WiFi. Se utilizzate PEAP-MSCHAPv2 sulla rete del vostro campus, questo briefing vi riguarda direttamente. E se state già pianificando il passaggio all'autenticazione basata su certificati, vi forniremo l'architettura, le insidie e la sequenza di implementazione per arrivarci. Partiamo dal problema. Le università sono, per loro natura, ambienti aperti. A settembre gli studenti arrivano con due, tre, a volte cinque dispositivi personali. Si aspettano di connettersi immediatamente, in modo sicuro e senza dover contattare l'helpdesk. La realtà per la maggior parte degli istituti è una coda dell'helpdesk che raggiunge i duemila ticket entro quarantotto ore dall'inizio del trimestre. Questo non è un problema di personale. È un problema di architettura. La causa principale è quasi sempre la stessa: l'autenticazione WiFi basata su password. Quando si utilizza WPA2-Enterprise con PEAP e MSCHAPv2, si chiede agli studenti di configurare manualmente le impostazioni 802.1X su ogni dispositivo. Un'impostazione errata e diventano vulnerabili a un attacco man-in-the-middle. Peggio ancora, quando l'università impone il ripristino della password ogni novanta giorni, ogni dispositivo nel campus perde contemporaneamente l'accesso al WiFi. Questo è un disastro prevedibile e prevenibile. La risposta è l'autenticazione basata su certificati tramite EAP-TLS, e il meccanismo che la rende scalabile è SCEP: il Simple Certificate Enrollment Protocol. SCEP è stato formalizzato dall'IETF nell'RFC 8894 nel 2020, sebbene sia in uso fin dai primi anni 2000. Automatizza il processo di richiesta e installazione dei certificati digitali X.509 sui dispositivi, senza richiedere alcun intervento IT manuale per singolo dispositivo. Ecco come funziona in sintesi. La vostra piattaforma MDM, che si tratti di Microsoft Intune o Jamf, invia un payload SCEP a ciascun dispositivo registrato. Tale payload contiene due elementi: l'URL del gateway SCEP e una password di verifica (challenge password) condivisa. Il dispositivo genera una Certificate Signing Request, la invia al gateway SCEP, che convalida la password di verifica e inoltra la richiesta alla vostra Certificate Authority. La CA firma il certificato e lo restituisce al dispositivo. Da quel momento in poi, il dispositivo si autentica alla rete WiFi utilizzando EAP-TLS: il certificato dimostra l'identità del dispositivo al server RADIUS, mentre il certificato del server RADIUS dimostra l'identità della rete al dispositivo. Autenticazione reciproca. Nessuna password scambiata via etere. Questo elemento di autenticazione reciproca è fondamentale. Con PEAP, uno studente che si connette a un access point canaglia che trasmette il vostro SSID cederà volentieri le proprie credenziali. Con EAP-TLS, il dispositivo verifica il certificato del server RADIUS prima di procedere. Se non corrisponde alla CA attendibile, la connessione si interrompe silenziosamente. In questo modo avrete eliminato l'intera classe di attacchi evil twin. Ora parliamo di architettura. Un'implementazione SCEP in produzione per un'università prevede sei componenti principali. In primo luogo, l'identity provider: Microsoft Entra ID, Okta o Google Workspace. In secondo luogo, la piattaforma MDM: Intune per Windows e Android, Jamf per macOS e iOS. In terzo luogo, la Certificate Authority: Microsoft Active Directory Certificate Services on-premises oppure una PKI cloud. In quarto luogo, il gateway SCEP: l'endpoint HTTP che riceve le richieste di certificato. In quinto luogo, il server RADIUS per l'autenticazione. In sesto luogo, l'access layer: access point Cisco Meraki, HPE Aruba, Ruckus o Juniper Mist configurati per 802.1X. La catena di attendibilità funziona così. La CA emette un certificato root. Tale root viene distribuito a ogni dispositivo tramite MDM, stabilendo la relazione di attendibilità. La CA emette quindi i certificati client per i dispositivi tramite SCEP. Quando un dispositivo si connette, presenta il proprio certificato client al server RADIUS, e il server RADIUS presenta il proprio certificato server al dispositivo. Entrambe le parti effettuano la verifica rispetto alla root attendibile. L'accesso viene consentito o negato in base alla validità del certificato, non a una password. Vediamo ora la sequenza di implementazione. Questo è l'ordine corretto. Fase uno: pulizia dell'identity store. Verifica che Active Directory o Entra ID presentino gruppi ben definiti per studenti, personale e ospiti. Le policy dei certificati e le assegnazioni VLAN saranno collegate a questi gruppi. Fase due: implementazione della Certificate Authority. Se utilizzi Microsoft ADCS, configura una gerarchia a due livelli: una CA root offline e una CA di emissione online. La CA root dovrebbe essere isolata dopo la configurazione iniziale. Fase tre: configurazione del gateway SCEP. Questo è l'endpoint HTTP verso cui l'MDM indirizzerà i dispositivi. Assicurati che sia accessibile dal segmento di rete in cui i dispositivi eseguono la registrazione iniziale, in genere l'SSID di onboarding. Fase quattro: configurazione del server RADIUS. Importa il certificato della CA di emissione come CA attendibile. Configura EAP-TLS como metodo di autenticazione. Imposta gli attributi di ritorno VLAN in modo che RADIUS possa assegnare dinamicamente gli studenti al segmento di rete corretto. Fase cinque: configurazione dei profili MDM. In Intune, crea prima un profilo Certificato attendibile, poi un profilo Certificato SCEP e infine un profilo WiFi che faccia riferimento al certificato SCEP. Distribuisci questi profili esattamente in questo ordine. Ciascuno di essi dipende dalla presenza di quello precedente. Fase sei: configurazione degli access point. Su Cisco Meraki, HPE Aruba, Ruckus o Juniper Mist, configura il tuo SSID sicuro per WPA2-Enterprise o WPA3-Enterprise. Imposta il timeout RADIUS ad almeno cinque secondi per gestire la latenza di convalida dei certificati durante i picchi di onboarding. Ora, le potenziali insidie. Ho visto questi errori compromettere ripetutamente le implementazioni. Il primo consiste nel distribuire i profili MDM nell'ordine errato. Se il profilo WiFi arriva sul dispositivo prima del profilo del certificato SCEP, il dispositivo non disporrà di alcun certificato con cui autenticarsi. Di conseguenza, la connessione fallirà e l'utente contatterà l'assistenza. Il secondo errore comune è dimenticare i dispositivi BYOD. Intune e Jamf gestiscono la flotta di proprietà dell'istituto. Ma i dispositivi personali degli studenti non sono registrati nel vostro MDM. Per questi, serve un portale di onboarding self-service. Lo studente si autentica tramite Single Sign-On utilizzando le proprie credenziali universitarie, e il portale utilizza SCEP per emettere il certificato. La piattaforma di Purple integra questo flusso di onboarding direttamente nell'esperienza del Captive Portal, così gli studenti completano la registrazione in meno di due minuti senza alcun intervento dell'IT. Il terzo errore comune sono i timeout di RADIUS durante i picchi di onboarding. Eseguite test di carico sulla vostra infrastruttura RADIUS prima di settembre, non durante. Implementate il bilanciamento del carico su almeno due nodi RADIUS. Il quarto errore comune è la revoca dei certificati. Quando uno studente se ne va, o un dispositivo viene smarrito o rubato, è necessario revocare immediatamente il certificato. Assicuratevi che la vostra CA pubblichi una Certificate Revocation List e che il server RADIUS la controlli a ogni autenticazione. Passiamo ora a una rapida sessione di domande e risposte sui quesiti che sentiamo più spesso. Il SCEP può funzionare senza un MDM? Tecnicamente sì, ma praticamente no. Senza un MDM che distribuisca il payload SCEP e il profilo WiFi, si torna alla configurazione manuale del dispositivo. Quanto dovrebbe durare la validità di un certificato? Per i dispositivi degli studenti, lo standard è da uno a due anni. Abbastanza a lungo da superare l'anno accademico senza problemi di rinnovo, abbastanza breve da limitare i rischi se un certificato viene compromesso. Cosa fare con i dispositivi IoT che non supportano lo standard 802.1X? Utilizzate il MAC Authentication Bypass con un portale di registrazione dei dispositivi self-service. Gli studenti registrano l'indirizzo MAC della propria console di gioco o smart TV, e il sistema NAC lo inserisce nella VLAN corretta. Funziona con eduroam? Sì. EAP-TLS è pienamente supportato dalla federazione eduroam. I certificati emessi dalla CA del campus possono autenticare gli studenti su eduroam in qualsiasi istituto aderente nel mondo. Per concludere, ecco le tre decisioni che definiscono un deployment SCEP di successo. Primo: scegliete l'architettura della CA prima di ogni altra cosa. ADCS on-premises offre un controllo totale. La PKI cloud offre semplicità operativa. Una scelta errata in questa fase costa mesi di lavoro extra. Secondo: automatizzate l'onboarding BYOD fin dal primo giorno. Non presupponete che gli studenti configurino i propri dispositivi personali manualmente. Non lo faranno. Create il portale self-service prima dell'inizio delle lezioni. Terzo: testate la capacità di carico di RADIUS prima di settembre. Un'interruzione di RADIUS il primo giorno di lezione è del tutto prevenibile. La piattaforma di Purple supporta tutti e tre questi aspetti: integrazione PKI cloud overlay, onboarding BYOD self-service tramite il nostro Captive Portal e un'infrastruttura RADIUS testata su ottantamila location attive con un uptime del novantanove virgola nove nove nove percento. Grazie per aver partecipato al Technical Briefing di Purple. Per ulteriori informazioni, visitate purple.ai.