Come utilizzare Microsoft Intune per distribuire certificati WiFi ai 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. Vi parlo oggi a nome di Purple, la piattaforma aziendale di WiFi intelligence, e questo episodio è un briefing focalizzato 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, in una catena retail, in uno stadio o in un complesso del settore pubblico, conoscerete bene il problema che sto per descrivere. Avete centinaia o migliaia di dispositivi gestiti. Desiderate 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 configurare manualmente ogni singolo dispositivo. E volete che tale 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, le modalità di distribuzione e le insidie che ostacolano la maggior parte dei team al primo tentativo. [APPROFONDIMENTO TECNICO — circa 5 minuti] Iniziamo con l'architettura. La base di partenza è lo standard IEEE 802.1X - lo standard di controllo dell'accesso alla rete basato su porte che rappresenta la spina dorsale della sicurezza del WiFi aziendale da oltre vent'anni. Quando un dispositivo si connette al vostro WiFi, lo standard 802.1X richiede che si autentichi prima di ottenere qualsiasi accesso alla rete. Il processo di autenticazione avviene tra tre parti: il dispositivo - chiamato supplicant - il vostro access point 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. EAP-TLS utilizza un'autenticazione reciproca basata su 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 Enrolment 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 Certificate Signing Request, la invia alla Certificate Authority tramite un server intermediario chiamato NDES - Network Device Enrolment Service - e la CA emette il certificato di risposta. La chiave privata non lascia mai il dispositivo. Questo è l'approccio più sicuro ed è consigliato per gli ambienti BYOD e per le distribuzioni ad alta sicurezza. Con PKCS, la Certificate Authority genera la coppia di chiavi e l'Intune Certificate Connector distribuisce la chiave privata e il certificato al dispositivo. È più semplice da configurare - non è richiesto alcun server NDES - ma la chiave privata transita attraverso il connettore, il che rappresenta una considerazione importante per il vostro livello di sicurezza. Per la maggior parte delle distribuzioni aziendali consiglierei 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 roll-out falliti. Fase uno: configurare la Certificate Authority. È necessario un modello di certificato sull'istanza Active Directory Certificate Services - o se siete completamente cloud-native, Cloud PKI di Intune di Microsoft è ora generalmente disponibile ed elimina completamente il requisito della CA on-premises. Il modello necessita delle corrette estensioni per l'utilizzo della chiave: l'autenticazione client è obbligatoria. Impostate la dimensione minima della chiave su 2048 bit, o 4096 se la policy di sicurezza della vostra organizzazione lo richiede. Fase due: distribuire il certificato root attendibile. Prima che qualsiasi dispositivo possa convalidare il certificato del server RADIUS, deve considerare attendibile la CA che lo ha emesso. Create un profilo di configurazione Trusted Certificate in Intune, caricate il certificato root della CA e assegnatelo ai 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 degli 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 alla Certificate Authority. Il Subject Alternative Name deve includere lo User Principal Name per i certificati utente, o l'AAD Device ID per i certificati del dispositivo. Questa distinzione è importante: i certificati utente autenticano l'utente connesso, i certificati del dispositivo autenticano la macchina stessa, il che significa che il dispositivo può connettersi al WiFi prima che un utente acceda - utile per scenari di join a dominio e installazioni kiosk. Fase quattro: creare il profilo di configurazione WiFi. In Intune, questo si trova sotto Dispositivi, Profili di configurazione, Modelli, Wi-Fi. Impostate il tipo di WiFi su Enterprise, inserite l'SSID, impostate il tipo 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 di 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 NPS per gli ambienti Windows Server: dall'inizio del 2024, Microsoft ha reso più severi i requisiti di mappatura dei certificati. Se utilizzi certificati di dispositivo con dispositivi registrati in Azure AD che eseguono l'autenticazione con NPS on-premises, devi assicurarti che l'attributo altSecurityIdentities sull'oggetto computer in Active Directory sia popolato con l'identificazione (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 DA EVITARE — circa 2 minuti] Permettetemi di illustrare le tre trappole che riscontro più frequentemente nelle distribuzioni aziendali. Trappola numero uno: interruzioni 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 sia quello intermedio. Ho visto implementazioni fallire per settimane perché qualcuno aveva distribuito il certificato radice ma non quello intermedio. Trappola numero due: 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 prima che i profili si propaghino dopo l'assegnazione. Non effettuare i test subito dopo la creazione dei 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 che non esiste ancora, il profilo fallirà in modo silenzioso su alcune piattaforme. Trappola numero tre: revoca dei certificati BYOD. Quando un dispositivo viene rimosso da Intune - ad esempio perché un dipendente lascia l'azienda o un dispositivo viene smarrito - è necessario un processo per revocare il certificato. Se utilizzi SCEP con ADCS, configura correttamente il punto di distribuzione della CRL (Certificate Revocation List) e assicurati che il server RADIUS controlli la CRL o l'OCSP a ogni autenticazione. Questo è un requisito di conformità previsto da framework come 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 in ambienti di pagamento al dettaglio - l'autenticazione 802.1X basata su certificato è il controllo più sicuro per l'accesso alla rete wireless. Soddisfa il Requisito 1.3 di PCI-DSS 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 nel settore pubblico, la separazione tra la rete aziendale 802.1X e la rete WiFi per gli 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 gli 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 dovrebbero mai condividere l'infrastruttura di autenticazione. [D&R RAPIDE - circa 1 minuto] Passiamo in rassegna alcune domande che sorgono regolarmente. Posso utilizzare Intune Cloud PKI al posto 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 prive di un'infrastruttura ADCS esistente, è il percorso consigliato. Funziona per i dispositivi macOS e iOS? Sì. Intune supporta i profili di 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 principale - 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 emesso un certificato. Se il dispositivo non è più conforme - nessun blocco dello schermo, sistema operativo obsoleto - 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 del captive portal, la gestione del consenso e l'analisi. La rete aziendale 802.1X e il WiFi per gli ospiti di Purple funzionano in parallelo - stessa infrastruttura fisica, SSID e VLAN diversi - 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. Scegliete SCEP per il BYOD e gli ambienti ad alta sicurezza; PKCS per flotte aziendali più semplici. Definite correttamente la sequenza, gestite il requisito di mappatura del certificato NPS e create un flusso di lavoro per la revoca dei certificati fin dal primo giorno. I vantaggi per l'azienda sono evidenti: eliminate le password WiFi condivise, ottenete registri di autenticazione per singolo dispositivo e utente, soddisfate i requisiti di sicurezza wireless PCI-DSS e ISO 27001 e riducete i costi di gestione IT per le credenziali WiFi su un parco dispositivi di grandi dimensioni. Se stai pianificando una distribuzione e desideri comprendere come la piattaforma di analisi e guest WiFi di Purple si inserisce all'interno dell'architettura della tua rete aziendale, visita purple.ai. Offriamo guide dettagliate sull'integrazione di Azure Entra ID, sull'architettura 802.1X e sulla progettazione di reti guest per i settori dell'ospitalità, del commercio al dettaglio e pubblico. Grazie per l'attenzione. Alla prossima.