Implementazione di SCEP per BYOD sicuro e WiFi 802.1X nell'istruzione superiore

Implementazione di SCEP per WiFi sicuro in modalità BYOD e 802.1X nell'Istruzione Superiore Un briefing tecnico Purple - circa 10 minuti [INTRODUZIONE E CONTESTO - 1 minuto] Benvenuti al briefing tecnico Purple. Vi guiderò attraverso uno dei punti critici più comuni che riscontriamo nell'IT dell'istruzione superiore: come connettere migliaia di dispositivi di studenti e personale a una rete WiFi protetta e autenticata tramite certificati, senza che il vostro helpdesk venga sommerso di ticket. La risposta breve coinvolge tre lettere: SCEP. Si tratta del Simple Certificate Enrollment Protocol. E quando lo si abbina a 802.1X e a un servizio RADIUS in cloud, si ottiene qualcosa di veramente potente - una rete in cui ogni dispositivo dimostra la propria identità prima di ottenere l'accesso, i certificati vengono emessi e rinnovati automaticamente e il vostro team IT non deve intervenire manualmente su ciascun dispositivo. Le università sono sottoposte a una forte pressione su questo fronte. Ci sono decine di migliaia di studenti che arrivano ogni settembre con i propri laptop, telefoni e tablet. È necessario connetterli a una rete sicura in modo rapido. E dovete assicurarvi che quando uno studente se ne va o un dispositivo viene smarrito, l'accesso venga revocato in modo pulito. SCEP è il meccanismo che consente a tutto questo di funzionare su scala. Entriamo nei dettagli tecnici. [APPROFONDIMENTO TECNICO - 5 minuti] In primo luogo, definiamo chiaramente cos'è SCEP. È un protocollo - originariamente sviluppato da Cisco - che automatizza il processo di richiesta e ricezione di un certificato digitale da un'Autorità di Certificazione. Prima di SCEP, l'installazione di un certificato su un dispositivo richiedeva un processo manuale con una chiavetta USB e molti clic, oppure una complessa registrazione basata sul web che confondeva la maggior parte degli utenti finali. SCEP automatizza completamente questa stretta di mano. Ecco come funziona il flusso in un contesto BYOD universitario. Uno studente arriva nel campus. Il suo dispositivo - che sia un MacBook, un telefono Android o un laptop Windows - viene registrato nella vostra piattaforma di Mobile Device Management, o MDM. L'MDM invia un profilo di configurazione al dispositivo. Tale profilo contiene l'URL SCEP che punta alla vostra Autorità di Certificazione, una password di verifica per l'autenticazione e il modello di certificato da utilizzare. Il dispositivo genera localmente una coppia di chiavi - la chiave privata non lascia mai il dispositivo - e invia una richiesta di firma del certificato alla CA tramite SCEP. La CA convalida la richiesta, emette un certificato e lo restituisce al dispositivo. L'intero processo richiede pochi secondi e non richiede alcuna interazione da parte dell'utente oltre alla registrazione iniziale all'MDM. Ora, perché questo è importante in particolare per il WiFi? Perché 802.1X - lo standard IEEE per il controllo dell'accesso alla rete basato sulle porte - può utilizzare quel certificato come credenziale di autenticazione. Invece di un nome utente e di una password, il dispositivo presenta il proprio certificato al server RADIUS. Il server RADIUS convalida il certificato rispetto alla CA, conferma che il dispositivo è noto e attendibile e concede l'accesso. Questo è EAP-TLS - Extensible Authentication Protocol con Transport Layer Security - ed è il gold standard per l'autenticazione WiFi.I vantaggi in termini di sicurezza rispetto agli approcci basati su password sono significativi. I certificati non possono essere oggetto di phishing. Uno studente non può accidentalmente cedere il proprio certificato a una rete fittizia. La chiave privata non lascia mai il dispositivo, quindi anche se un certificato venisse intercettato, sarebbe inutile senza la corrispondente chiave privata. E poiché il certificato contiene l'identità del dispositivo, ottieni una visibilità granulare su quale dispositivo esatto si trova sulla tua rete in qualsiasi momento. Ora parliamo dei componenti infrastrutturali necessari. Occorre una Certificate Authority - questa può essere Microsoft Active Directory Certificate Services, che la maggior parte delle università possiede già, o una CA basata su cloud. È necessario un server NDES - ovvero Network Device Enrollment Service - che funga da proxy SCEP tra i tuoi dispositivi e la tua CA. È necessario un server RADIUS per gestire l'autenticazione 802.1X. E sono necessari access point che supportino WPA2-Enterprise o WPA3-Enterprise con 802.1X. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi e Fortinet supportano tutti questa funzionalità in modo nativo. Per la componente RADIUS, SecurePass di Purple utilizza un servizio RADIUS cloud-native. Il server primario è rad1-secure.purple.ai e il secondario è rad2-secure.purple.ai, entrambi sulla porta di autenticazione standard 1812 e sulla porta di accounting 1813. Questo elimina la necessità di gestire una propria infrastruttura RADIUS on-premises - che storicamente ha rappresentato un onere operativo significativo per i team IT delle università. Per i passaggi di configurazione completi, la documentazione di supporto di Purple su support.purple.ai copre l'esatto processo di installazione. Un aspetto che vale la pena sottolineare: SecurePass è basato sullo standard Passpoint - noto anche come Hotspot 2.0. Ciò significa che uno studente che si registra presso la tua università non ottiene solo un accesso sicuro nel campus. Il suo dispositivo si connetterà automaticamente in una qualsiasi delle oltre 80.000 sedi abilitate a OpenRoaming in tutto il mondo - aeroporti, hotel, stazioni ferroviarie. L'identità basata su certificato viaggia con lui. Questo è un vantaggio davvero utile per gli studenti che viaggiano. La configurazione del SSID è importante che sia corretta. SecurePass richiede un SSID dedicato con WPA2 o WPA3-Enterprise e Hotspot 2.0 abilitato. Non devi riutilizzare il tuo SSID Captive Portal esistente. L'SSID deve essere trasmesso - gli SSID nascosti impediscono il comportamento di connessione automatica che fa funzionare l'intero sistema. Per l'integrazione con l'identity provider, SecurePass si sincronizza con Microsoft Entra ID e Google Workspace. Questo è fondamentale per il flusso di lavoro di inserimento, mobilità e uscita del personale. Quando uno studente si laurea o un membro del personale se ne va, il suo account viene disabilitato in Entra ID e l'accesso viene revocato automaticamente. Nessuna revoca manuale del certificato richiesta. Questo è il tipo di automazione che fa risparmiare tempo reale al tuo team IT. [CONSIGLI DI IMPLEMENTAZIONE E TRAPPOLE DA EVITARE - 2 minuti] Permettetemi di darvi le raccomandazioni pratiche che darei a qualsiasi team IT universitario che inizia questo progetto. In primo luogo, inizia con il personale prima degli studenti. I dispositivi del personale sono tipicamente gestiti - hai la copertura MDM, conosci l'inventario dei dispositivi e la popolazione è più ridotta. Perfeziona il processo con il personale, risolvi i casi limite, poi passa agli studenti. In secondo luogo, pianifica attentamente la durata del certificato. Una durata del certificato di un anno è una scelta comune, ma pensa al tuo calendario accademico. Se i certificati scadono in agosto, avrai un'ondata di rinnovi proprio prima dell'inizio del nuovo anno accademico. Valuta di allineare la scadenza a metà semestre, oppure utilizza il rinnovo automatico tramite SCEP per evitare del tutto il problema. In terzo luogo, testa a fondo la tua configurazione NDES prima del lancio. NDES è il componente che causa problemi più comunemente. La password di verifica deve essere generata ex novo per ogni richiesta di registrazione - ha una finestra di validità breve. Se il tuo MDM genera la richiesta SCEP troppo lentamente dopo aver recuperato la password di verifica, la registrazione fallirà. Esegui i test con una gamma di tipi di dispositivi e versioni di sistemi operativi. In quarto luogo, non trascurare la matrice di compatibilità dei dispositivi. iOS, macOS, Android e Windows gestiscono tutti SCEP in modo leggermente diverso. iOS e macOS hanno un supporto SCEP nativo integrato e funzionano perfettamente con i profili distribuiti tramite MDM. Il comportamento di Android varia a seconda del produttore. Windows richiede il connettore NDES o un agente MDM di terze parti. Documenta le tue configurazioni supportate e comunicale chiaramente agli studenti. La trappola più comune che riscontro è il sotto-investimento nel livello MDM. SCEP è efficace solo in base alla copertura del tuo MDM. Se gli studenti hanno dispositivi che non sono registrati nell'MDM, non possono ricevere il profilo SCEP. È necessario un processo di onboarding chiaro - idealmente integrato nel flusso di lavoro di registrazione degli studenti - che inserisca i dispositivi nell'MDM prima del loro arrivo nel campus. [D&R RAPIDE - 1 minuto] Alcune domande rapide che mi vengono poste regolarmente. SCEP può funzionare senza un MDM? Tecnicamente sì - puoi distribuire i profili SCEP manualmente - ma su scala universitaria, hai bisogno di un MDM. Senza di esso, si torna ai processi manuali. Cosa succede ai dispositivi che non supportano 802.1X? Continuano a passare attraverso il tuo Captive Portal esistente come di consueto. SecurePass è integrativo - i dispositivi non supportati non vengono bloccati. Questo funziona per i dispositivi IoT nel campus? I dispositivi IoT in genere non supportano 802.1X. Segmentali su una VLAN separata con regole di firewall appropriate. Non cercare di inserire i sensori del tuo edificio intelligente sulla stessa rete dei laptop degli studenti. EAP-TLS è l'unica opzione? No. PEAP con MSCHAPv2 è un'alternativa comune che utilizza nome utente e password anziché i certificati. Ma EAP-TLS con certificati emessi tramite SCEP è significativamente più sicuro ed elimina il sovraccarico di gestione delle password. [RIASSUNTO E PROSSIMI PASSI - 1 minuto] In sintesi: SCEP automatizza la registrazione dei certificati su scala. Combinato con 802.1X ed EAP-TLS, offre una rete in cui ogni dispositivo viene autenticato crittograficamente, i certificati vengono rilasciati e rinnovati senza l'intervento dell'IT e l'accesso viene revocato automaticamente quando qualcuno se ne va. Per un'università con migliaia di dispositivi BYOD, questa è la differenza tra una rete gestibile e un incubo per l'helpdesk. I componenti chiave sono: una Certificate Authority, un server proxy NDES o SCEP, un servizio RADIUS in cloud e access point che supportano WPA2 o WPA3-Enterprise. SecurePass di Purple fornisce il livello RADIUS in cloud e la distribuzione dei profili basata su Passpoint, integrandoli con la directory Microsoft Entra ID o Google Workspace esistente. I tuoi prossimi passi: esamina la copertura del tuo MDM e identifica eventuali lacune, valuta l'infrastruttura della tua CA e contatta il fornitore dell'hardware di rete per verificare il supporto a Passpoint. Successivamente, visita il sito support.purple.ai per consultare la guida alla configurazione di SecurePass e l'elenco di compatibilità hardware. Grazie per l'attenzione. Se hai domande, il team di Purple è a tua disposizione su purple.ai.