Distribuzione di certificati WiFi Microsoft Intune tramite SCEP e PKCS

Sintesi Esecutiva

Per le sedi aziendali - che si tratti di un dinamico ambiente Hospitality, di un'operazione Retail multi-sito o di un moderno campus aziendale - affidarsi a chiavi pre-condivise o a Captive Portal di base per la rete WiFi del personale rappresenta una vulnerabilità di sicurezza e un collo di bottiglia operativo. La moderna architettura di rete richiede l'autenticazione 802.1X tramite EAP-TLS, garantendo che ogni dispositivo sia verificato crittograficamente prima di accedere alla rete.

Tuttavia, la sfida risiede nella distribuzione: come distribuire certificati client univoci a migliaia di dispositivi Windows, iOS e Android senza sommergere il servizio di assistenza di ticket di supporto? Microsoft Intune risolve questo problema attraverso la gestione automatizzata del ciclo di vita dei certificati. Sfruttando i profili di certificato SCEP (Simple Certificate Enrolment Protocol) o PKCS (Public Key Cryptography Standards), i team IT possono distribuire silenziosamente certificati root e client affidabili agli endpoint gestiti.

Questa guida fornisce un progetto di architettura definitivo e una strategia di implementazione dettagliata per la distribuzione dei certificati WiFi tramite Intune. Esploreremo le differenze critiche tra SCEP e PKCS, spiegheremo l'esatta sequenza di distribuzione necessaria per il successo e delineeremo le strategie di mitigazione del rischio nel mondo reale per garantire che il vostro Guest WiFi e le reti aziendali rimangano sicuri e performanti.

Ascolta il podcast informativo di accompagnamento:

Approfondimento Tecnico: SCEP vs. PKCS

Durante la progettazione della strategia di distribuzione dei certificati WiFi tramite Intune, la prima decisione architetturale riguarda la selezione del meccanismo di consegna dei certificati. Intune supporta sia SCEP che PKCS, ma operano in modo fondamentalmente diverso.

SCEP (Simple Certificate Enrolment Protocol)

SCEP è lo standard di settore per la registrazione dei dispositivi aziendali. In un flusso di lavoro SCEP, il servizio Intune istruisce l'endpoint a generare la propria coppia di chiavi privata/pubblica. Il dispositivo crea quindi una richiesta di firma del certificato (CSR) e la invia tramite un server NDES (Network Device Enrolment Service) alla Certificate Authority (CA). La CA firma la richiesta e restituisce il certificato pubblico al dispositivo.

Il vantaggio critico in termini di sicurezza di SCEP è che la chiave privata non lascia mai il dispositivo. Viene generata localmente, archiviata nell'enclave sicura del dispositivo (come il TPM su Windows o il Secure Enclave su iOS) e non viene mai trasmessa in rete. Questo rende SCEP l'approccio fortemente raccomandato per l'autenticazione 802.1X.

PKCS (Public Key Cryptography Standards)

Al contrario, con PKCS, l'Autorità di Certificazione genera sia la chiave pubblica che quella privata a livello centrale. Il Microsoft Intune Certificate Connector esporta quindi in modo sicuro questa coppia di chiavi e la distribuisce al dispositivo di destinazione.

Sebbene il PKCS elimini la necessità di implementare e gestire un server NDES - semplificando l'ingombro dell'infrastruttura - introduce un rischio teorico di sicurezza perché la chiave privata viene trasmessa sulla rete. Il PKCS è generalmente più adatto per i casi d'uso in cui è richiesto il deposito della chiave, come la crittografia delle e-mail S/MIME, piuttosto che per l'autenticazione di rete.

Guida all'implementazione: La sequenza di distribuzione

La corretta configurazione di un profilo WiFi Intune per 802.1X richiede il rigoroso rispetto di una specifica sequenza di distribuzione. Le dipendenze del profilo Intune impongono che la fiducia debba essere stabilita prima di poter configurare l'autenticazione.

Passaggio 1: Distribuzione del profilo del certificato Root attendibile

Prima che un dispositivo possa richiedere un certificato client o considerare attendibile il server RADIUS, deve considerare attendibile l'Autorità di Certificazione emittente.

1. Esporta il certificato della CA Root (e gli eventuali certificati della CA intermedia) come file .cer.
2. Nel centro di amministrazione di Microsoft Endpoint Manager, passa a Dispositivi > Profili di configurazione > Crea profilo.
3. Seleziona la piattaforma di destinazione (ad esempio, Windows 10 e versioni successive) e scegli il tipo di profilo Certificato attendibile.
4. Carica il file .cer e distribuisci questo profilo ai gruppi di dispositivi di destinazione.

Regola empirica: punta sempre allo stesso gruppo (Utenti o Dispositivi) in tutti i profili correlati per evitare discrepanze nella distribuzione.

Passaggio 2: Configurazione del profilo del certificato SCEP

Una volta stabilita la fiducia, configura il profilo SCEP per indicare ai dispositivi come ottenere il loro certificato client.

1. Crea un nuovo profilo di configurazione e seleziona Certificato SCEP.
2. Configura il Formato del nome del soggetto. Per l'autenticazione basata sull'utente, CN={{UserPrincipalName}} è lo standard. Per l'autenticazione del dispositivo, utilizza CN={{AAD_Device_ID}}.
3. Imposta l'Utilizzo della chiave su Firma digitale e Cifratura della chiave.
4. In Utilizzo avanzato della chiave, specifica Autenticazione client (OID: 1.3.6.1.5.5.7.3.2).
5. Collega questo profilo al profilo del certificato Root attendibile creato al Passaggio 1.
6. Fornisci l'URL esterno del tuo server NDES.

Passaggio 3: Distribuzione del profilo WiFi 802.1X

Il passaggio finale consiste nel distribuire la configurazione WiFi che associa i certificati al SSID di rete.

1. Crea un profilo di configurazione WiFi.
2. Inserisci il Nome di rete (SSID) esattamente come viene trasmesso dai tuoi Wireless Access Points.
3. Seleziona WPA2-Enterprise o WPA3-Enterprise come tipo di sicurezza.
4. Imposta il Tipo EAP su EAP-TLS.5. Nelle impostazioni di autenticazione, seleziona il profilo del certificato SCEP creato al passaggio 2 come certificato di autenticazione client.
5. Specifica il certificato Trusted Root per la convalida del server, garantendo così che il dispositivo si connetta esclusivamente al tuo server RADIUS legittimo.

Best Practice e Standard di Settore

Durante l'implementazione della distribuzione dei certificati WiFi tramite Intune, attieniti alle seguenti best practice indipendenti dal fornitore per garantire conformità e affidabilità.

Posizionamento e Sicurezza del Server NDES

Il server NDES deve essere accessibile da Internet per consentire ai dispositivi remoti di eseguire il provisioning dei certificati prima del loro arrivo in sede. Tuttavia, esporre direttamente un server interno a Internet costituisce un grave rischio per la sicurezza.

Raccomandazione: Pubblica l'URL di NDES utilizzando l'Application Proxy di Azure AD. Questo approccio fornisce un accesso remoto sicuro senza aprire porte in entrata sul firewall e ti consente di applicare i criteri di Accesso Condizionale al flusso di registrazione.

RADIUS e Controllo della CRL

La distribuzione dei certificati rappresenta solo metà della sicurezza aziendale; la revoca è altrettanto critica. Se un dipendente viene licenziato, disabilitare il suo account Active Directory potrebbe non revocare immediatamente il suo accesso WiFi se il certificato client rimane valido e il server RADIUS non esegue un controllo rigoroso della Certificate Revocation List (CRL).

Raccomandazione: Configura il tuo Network Policy Server (NPS) o il tuo server RADIUS per applicare una verifica rigorosa della CRL. Assicurati che i tuoi CRL Distribution Points (CDP) siano a elevata disponibilità; se il server RADIUS non riesce a raggiungere la CRL, l'autenticazione fallirà, causando un disservizio diffuso.

Per ulteriori approfondimenti sulla progettazione di reti sicure, consulta The Core SD WAN Benefits for Modern Businesses.

Risoluzione dei Problemi e Mitigazione dei Rischi

Anche con una pianificazione meticolosa, la distribuzione dei certificati può riscontrare problemi. Di seguito sono riportati i casi di errore più comuni e le relative strategie di mitigazione.

Problema: Impossibile Applicare il Profilo WiFi

Sintomo: Il dispositivo riceve i certificati Trusted Root e SCEP, ma il profilo WiFi viene visualizzato come "Errore" o "Non applicabile" in Intune.

Causa principale: Questo problema è quasi sempre causato da una mancata corrispondenza nei gruppi di destinazione. Se il profilo SCEP è assegnato a un Gruppo Utenti, mentre il profilo WiFi è assegnato a un Gruppo Dispositivi, Intune non è in grado di risolvere la dipendenza.

Soluzione: Verifica le assegnazioni. Assicurati che i profili Trusted Root, SCEP e WiFi siano tutti distribuiti esattamente allo stesso gruppo Azure AD.

Problema: Errori NDES 403 Forbidden

Sintomo: I dispositivi non riescono a recuperare il certificato SCEP e i log IIS di NDES mostrano errori HTTP 403.

Causa principale: L'account di servizio del Certificate Connector di Intune non dispone delle autorizzazioni necessarie sul modello di certificato, oppure il filtro URL sul tuo firewall sta bloccando i parametri specifici della query string utilizzati da SCEP.Risoluzione: Verificare che l'account del connettore disponga delle autorizzazioni 'Read' e 'Enrol' sul template della CA. Controllare i log del firewall per assicurarsi che gli URL contenenti ?operation=GetCACaps non vengano bloccati.

ROI e Impatto Aziendale

La transizione alla distribuzione dei certificati 802.1X con Microsoft Intune offre vantaggi misurabili in termini di sicurezza e operazioni.

1. Riduzione dei ticket di helpdesk: Le reti WiFi basate su password generano un volume significativo di ticket di supporto (scadenze delle password, blocchi dell'account, errori di digitazione). L'autenticazione basata su certificati è invisibile all'utente e riduce tipicamente il volume di ticket correlati al WiFi del 70-80%.
2. Miglioramento del livello di sicurezza: EAP-TLS elimina il rischio di furto di credenziali e di attacchi Man-in-the-Middle (MitM). Questo è fondamentale per la conformità a framework come PCI DSS e GDPR, in particolare negli ambienti sanitari (Healthcare) e retail.
3. Onboarding fluido: Per le organizzazioni che gestiscono ampie flotte di dispositivi Apple insieme a Windows, l'integrazione di Intune con i flussi di lavoro MDM esistenti (vedere la nostra guida su Jamf and RADIUS: Certificate-Based WiFi Authentication for Apple Device Fleets) garantisce un'esperienza di provisioning unificata e zero-touch fin dal primo giorno.