Come utilizzare Microsoft Intune per distribuire certificati WiFi sui dispositivi

COME UTILIZZARE MICROSOFT INTUNE PER DISTRIBUIRE CERTIFICATI WIFI SUI DISPOSITIVI Un briefing informativo di Purple Enterprise WiFi Intelligence [INTRODUZIONE E CONTESTO — circa 1 minuto] Benvenuti. Oggi parlo a nome di Purple, la piattaforma di enterprise WiFi intelligence, e questo episodio è un briefing mirato su una delle funzionalità più pratiche — e onestamente più sottovalutate — del toolkit di Microsoft Intune: la distribuzione automatizzata dei certificati per l'autenticazione WiFi 802.1X. Se gestite il WiFi in un patrimonio alberghiero, una catena di negozi, uno stadio o un patrimonio del settore pubblico, conoscerete bene il problema che sto per descrivere. Avete centinaia o migliaia di dispositivi gestiti. Volete che si connettano al vostro WiFi aziendale in modo automatico e sicuro, senza che gli utenti debbano digitare password e senza che l'IT debba intervenire su ogni singolo dispositivo. E volete che la connessione sia crittograficamente forte — non una semplice password condivisa che qualcuno ha già inviato via email a mezza organizzazione. Questo è esattamente ciò che risolve la distribuzione dei certificati di Intune. E nei prossimi nove minuti vi guiderò attraverso il suo funzionamento, come distribuirlo e le insidie che mettono in difficoltà la maggior parte dei team al primo tentativo. [APPROFONDIMENTO TECNICO — circa 5 minuti] Iniziamo con l'architettura. La base qui è lo standard IEEE 802.1X — lo standard di controllo dell'accesso alla rete basato su porta che rappresenta la spina dorsale della sicurezza WiFi aziendale da oltre due decenni. Quando un dispositivo si connette al vostro WiFi, lo standard 802.1X richiede che si autentichi prima di ottenere qualsiasi accesso alla rete. La conversazione di autenticazione avviene tra tre parti: il dispositivo — chiamato supplicant —, il vostro punto di accesso WiFi, che funge da autenticatore, e il vostro server RADIUS, che è il server di autenticazione che prende la decisione finale. Ora, lo standard 802.1X supporta diversi metodi di autenticazione. Il più sicuro è EAP-TLS — Extensible Authentication Protocol con Transport Layer Security. L'EAP-TLS utilizza l'autenticazione reciproca tramite certificati: il dispositivo presenta un certificato per dimostrare la propria identità e il server RADIUS presenta un certificato per dimostrare la propria. Nessuna password richiesta. Nessuna credenziale che possa essere oggetto di phishing. Questo è il nostro obiettivo. La sfida è sempre stata quella di installare questi certificati sui dispositivi su larga scala. È qui che entra in gioco Microsoft Intune. Intune supporta due meccanismi di distribuzione dei certificati: SCEP — Simple Certificate Enrollment Protocol — e PKCS, che sta per Public Key Cryptography Standards. Capire la differenza è fondamentale. Con SCEP, la chiave privata viene generata sul dispositivo stesso. Il dispositivo crea una richiesta di firma del certificato (Certificate Signing Request), la invia alla vostra Autorità di Certificazione (CA) tramite un server intermediario chiamato NDES — Network Device Enrollment Service — e la CA rilascia il certificato. La chiave privata non lascia mai il dispositivo. Questo è l'approccio più sicuro ed è consigliato per gli ambienti BYOD e le distribuzioni ad alta sicurezza. Con PKCS, l'Autorità di Certificazione genera la coppia di chiavi e l'Intune Certificate Connector distribuisce la chiave privata e il certificato al dispositivo. È più semplice da configurare — non richiede alcun server NDES — ma la chiave privata transita attraverso il connettore, il che rappresenta un fattore da considerare per la vostra postura di sicurezza. Per la maggior parte delle distribuzioni aziendali raccomando SCEP per gli ambienti BYOD e con dispositivi misti, e PKCS laddove si disponga di una flotta omogenea di dispositivi Windows di proprietà aziendale e si desideri ridurre al minimo la complessità dell'infrastruttura. Ora parliamo della sequenza di distribuzione — perché l'ordine è importante e sbagliarlo è la causa più comune di fallimento dei rollout. Fase uno: configurare l'Autorità di Certificazione. È necessario un modello di certificato sull'istanza di Active Directory Certificate Services — o, se siete completamente cloud-native, la Cloud PKI di Microsoft Intune è ora generalmente disponibile ed elimina del tutto il requisito della CA on-premises. Il modello deve avere le estensioni di utilizzo della chiave corrette: l'autenticazione client è obbligatoria. Impostate la dimensione minima della chiave a 2048 bit, o 4096 se la politica di sicurezza della vostra organizzazione lo richiede. Fase due: distribuire il certificato root attendibile. Prima che un dispositivo possa convalidare il certificato del server RADIUS, deve considerare attendibile la CA che lo ha emesso. Create un profilo di configurazione Certificato Attendibile in Intune, caricate il certificato della CA root e assegnatelo ai vostri gruppi di dispositivi. Questo deve arrivare sui dispositivi prima di qualsiasi profilo WiFi o profilo di certificato client. Se sbagliate la sequenza, i dispositivi rifiuteranno il server RADIUS e passerete il pomeriggio a fissare l'Event ID 20271 nel registro eventi di Windows. Fase tre: distribuire il profilo del certificato client. Si tratta del profilo SCEP — che punta all'URL del server NDES — o del profilo PKCS, che punta all'Autorità di Certificazione. Il Subject Alternative Name deve includere lo User Principal Name per i certificati utente, o l'AAD Device ID per i certificati dispositivo. Questa distinzione è importante: i certificati utente autenticano l'utente connesso, i certificati dispositivo autenticano la macchina stessa, il che significa che il dispositivo può connettersi al WiFi prima che un utente acceda — utile per scenari di domain join e distribuzioni di chioschi. Fase quattro: creare il profilo di configurazione WiFi. In Intune, questo si trova in Dispositivi, Profili di configurazione, Modelli, Wi-Fi. Impostate il tipo di WiFi su Enterprise, inserite il vostro SSID, impostate il tipo di EAP su EAP-TLS, configurate le impostazioni di attendibilità del server — qui è dove fate riferimento al nome del certificato del server RADIUS — e per l'autenticazione client, fate riferimento al profilo del certificato creato nella fase tre. Fase cinque: assegnare tutto ai gruppi corretti e convalidare. Assegnate il certificato root, il certificato client e i profili WiFi agli stessi gruppi di dispositivi o utenti. Utilizzate la reportistica integrata di Intune per monitorare lo stato di distribuzione dei profili. Una distribuzione riuscita mostra tutti e tre i profili come Riuscito nell'elenco dei profili di configurazione del dispositivo. Un punto critico sulla configurazione di NPS per gli ambienti Windows Server: dall'inizio del 2024, Microsoft ha reso più rigidi i requisiti di mappatura dei certificati. Se utilizzi certificati di dispositivo con dispositivi aggiunti ad Azure AD che si autenticano su un NPS locale, devi assicurarti che l'attributo altSecurityIdentities sull'oggetto computer in Active Directory sia popolato con l'impronta digitale (thumbprint) del certificato. Questo non avviene automaticamente: è necessario uno script o un flusso di lavoro per gestirlo, solitamente attivato quando la CA emette un nuovo certificato. [RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE COMUNI — circa 2 minuti] Permettetemi di illustrare le tre trappole che riscontro più frequentemente nelle distribuzioni aziendali. Prima trappola: lacune nella catena dei certificati. Il dispositivo deve considerare attendibile ogni certificato della catena, dalla CA radice fino al certificato del server RADIUS. Se il certificato del server RADIUS è stato emesso da una CA intermedia, è necessario distribuire ai dispositivi sia il certificato radice che quello intermedio. Ho visto distribuzioni fallire per settimane perché qualcuno aveva distribuito il certificato radice ma non quello intermedio. Seconda trappola: tempistica di assegnazione dei profili. I profili Intune non arrivano sui dispositivi istantaneamente. In un parco macchine di grandi dimensioni, possono essere necessari da 15 a 30 minuti per la propagazione dei profili dopo l'assegnazione. Non effettuare test subito dopo aver creato i profili. Utilizza il pulsante Sincronizza nel portale Intune per forzare un controllo, quindi attendi. Inoltre, i profili dei certificati client devono essere distribuiti e confermati prima dell'applicazione del profilo WiFi: se il profilo WiFi fa riferimento a un certificato non ancora esistente, su alcune piattaforme il profilo fallirà in modo invisibile. Terza trappola: revoca dei certificati BYOD. Quando un dispositivo viene rimosso da Intune (perché un dipendente si dimette o un dispositivo viene smarrito), è necessario un processo per revocare il certificato. Se utilizzi SCEP con ADCS, configura correttamente il punto di distribuzione della Certificate Revocation List (CRL) e assicurati che il server RADIUS verifichi la CRL o l'OCSP a ogni autenticazione. Questo è un requisito di conformità previsto da framework come il GDPR e il PCI DSS, che impone la revoca tempestiva dei meccanismi di controllo degli accessi quando non sono più necessari. In tema di conformità: se operi in un ambito PCI DSS (ad esempio, ambienti di pagamento al dettaglio), l'autenticazione 802.1X basata su certificato è il controllo più solido per l'accesso alla rete wireless. Soddisfa il requisito PCI DSS 1.3 relativo ai controlli di accesso alla rete e il requisito 8.6 relativo ai fattori di autenticazione. Documenta il processo di gestione del ciclo di vita dei certificati come parte delle prove di conformità. Per gli ambienti regolamentati dal GDPR, in particolare nel settore dell'ospitalità e del settore pubblico, la separazione tra la rete aziendale 802.1X e la rete WiFi ospiti è fondamentale. La rete aziendale gestita da Intune deve trovarsi su una VLAN e un SSID completamente separati da qualsiasi rete per ospiti o visitatori. La piattaforma WiFi per ospiti di Purple gestisce il lato rivolto ai visitatori — captive portal, acquisizione del consenso, analisi — mentre la rete aziendale gestita da Intune gestisce il personale e i dispositivi operativi. Queste due reti non devono mai condividere l'infrastruttura di autenticazione. [DOMANDE E RISPOSTE RAPIDE — circa 1 minuto] Esaminiamo alcune domande che sorgono regolarmente. Posso usare Intune Cloud PKI invece di ADCS on-premises? Sì. Intune Cloud PKI di Microsoft, rilasciato nel 2024, fornisce una CA completamente gestita in Azure. Elimina il requisito del server NDES per SCEP e semplifica notevolmente la configurazione del connettore. Per le nuove distribuzioni o per le organizzazioni senza un'infrastruttura ADCS esistente, è il percorso consigliato. Funziona per i dispositivi macOS e iOS? Sì. Intune supporta i profili certificato per Windows, iOS, iPadOS, Android e macOS. I tipi di profilo e le opzioni di configurazione variano leggermente a seconda della piattaforma, ma l'architettura di base — root attendibile, certificato client, profilo WiFi — è coerente. E per i dispositivi personali in un programma BYOD? SCEP è la soluzione ideale in questo caso. Con le policy di conformità dei dispositivi di Intune, è possibile richiedere che un dispositivo soddisfi gli standard minimi di sicurezza prima che venga rilasciato un certificato. Se il dispositivo non è più conforme — nessun blocco schermo, sistema operativo non aggiornato — il certificato può essere revocato e l'accesso alla rete rimosso automaticamente. Purple può integrarsi con questa architettura? Assolutamente sì. La piattaforma di Purple si colloca sul lato della rete ospiti, gestendo l'autenticazione tramite captive portal, la gestione del consenso e l'analisi dei dati. La rete aziendale 802.1X e il WiFi ospiti di Purple operano in parallelo — stessa infrastruttura fisica, diversi SSID e VLAN — offrendo una separazione completa tra la connettività del personale e il coinvolgimento dei visitatori. [RIASSUNTO E PROSSIMI PASSI — circa 1 minuto] Per riassumere: la distribuzione dei certificati WiFi tramite Intune è un processo in cinque fasi — configurazione della CA, distribuzione della root attendibile, profilo del certificato client, profilo WiFi e assegnazione dei gruppi. Scegli SCEP per il BYOD e gli ambienti ad alta sicurezza; PKCS per flotte aziendali più semplici. Definisci correttamente la sequenza, gestisci il requisito di mappatura dei certificati NPS e crea un flusso di lavoro per la revoca dei certificati fin dal primo giorno. Il caso aziendale è semplice: elimini le password WiFi condivise, ottieni log di autenticazione per singolo dispositivo e utente, soddisfi i requisiti di sicurezza wireless PCI DSS e ISO 27001 e riduci i costi operativi IT per la gestione delle credenziali WiFi su un vasto parco macchine. Se stai pianificando un'implementazione e desideri comprendere come la piattaforma di guest WiFi e analytics di Purple si integri con l'architettura della tua rete aziendale, visita purple.ai. Abbiamo guide dettagliate sull'integrazione con Azure Entra ID, sull'architettura 802.1X e sulla progettazione di reti guest per i settori hospitality, retail e pubblico. Grazie per l'ascolto. Alla prossima.