Vai al contenuto principale

Come configurare SCEP per la registrazione automatizzata dei certificati WiFi aziendali

Questa guida spiega come configurare SCEP (Simple Certificate Enrollment Protocol) per la registrazione automatizzata dei certificati WiFi aziendali, coprendo l'intera architettura da PKI e NDES fino alla distribuzione dei profili MDM e alla convalida RADIUS. È rivolta a responsabili IT, architetti di rete e CTO di hotel, catene di vendita al dettaglio, stadi, centri congressi e organizzazioni del settore pubblico che devono superare le chiavi precondivise e implementare un'autenticazione 802.1X EAP-TLS scalabile e basata sull'identità. La piattaforma overlay cloud di Purple, indipendente dall'hardware, si integra direttamente con questa architettura, fornendo il livello WiFi per ospiti e BYOD che si affianca alla rete del personale autenticata tramite certificato.

Pubblicato Aggiornato
📖 10 minuti di lettura2,646 parole2 esempi pratici3 domande di esercitazione9 definizioni chiave

Video overview

Ascolta questa guida

Visualizza trascrizione del podcast
Benvenuto alla serie Purple Technical Briefing. Oggi parlerò di un argomento che arriva spesso nelle caselle di posta dei reparti IT ma che raramente riceve una risposta chiara: come distribuire concretamente l'autenticazione WiFi basata su certificati su scala globale, utilizzando SCEP, all'interno di una rete di grandi dimensioni. Che si tratti di un campus universitario, di un gruppo alberghiero multi-sito o di una grande struttura del settore pubblico, le sfide sono identiche. Copriremo l'intero scenario. Che cosa fa effettivamente SCEP, come si inserisce in un'architettura 802.1X, la sequenza di implementazione che la maggior parte dei team sbaglia, due scenari di implementazione reali e le insidie che vi costeranno un intero fine settimana se non pianificate per tempo. Questo è un briefing di consulenza, non un tutorial. Presumo che sappiate già cos'è un server RADIUS e che abbiate probabilmente già deciso di abbandonare le chiavi pre-condivise. Ciò di cui avete bisogno ora è la mappa di implementazione. Entriamo nel vivo. Primi principi. SCEP sta per Simple Certificate Enrollment Protocol. È stato formalizzato dall'IETF come RFC 8894 nel 2020, anche se era già in uso diffuso a livello aziendale da oltre un decennio. Il suo compito è semplice: automatizzare il processo di installazione di un certificato digitale su un dispositivo gestito senza richiedere l'intervento manuale di un operatore su ciascuna macchina. Nel contesto dell'autenticazione WiFi, SCEP rappresenta il meccanismo di distribuzione. Il protocollo di autenticazione effettivo a cui vi rivolgete è EAP-TLS, Extensible Authentication Protocol con Transport Layer Security, che si colloca all'interno del framework 802.1X. EAP-TLS è ampiamente considerato come il metodo di autenticazione più sicuro per le reti wireless aziendali poiché richiede che sia il dispositivo client sia il server RADIUS presentino certificati validi. Nessuna delle due parti si fida dell'altra senza una prova crittografica. Questa autenticazione reciproca è ciò che vi protegge dagli attacchi evil twin, in cui un utente malintenzionato attiva un access point canaglia per sottrarre credenziali. Ecco come funziona l'intera catena. Un dispositivo gestito, come il computer portatile di uno studente, il telefono di un dipendente o il terminale POS di un hotel, deve connettersi alla rete wireless aziendale. La vostra piattaforma MDM, che potrebbe essere Microsoft Intune o Jamf, invia un payload SCEP a quel dispositivo. Il payload contiene due elementi: l'URL SCEP, che punta al vostro server NDES o gateway SCEP cloud, e una password di verifica o un segreto condiviso. Il dispositivo genera localmente la propria coppia di chiavi pubblica e privata. Questo passaggio è fondamentale. La chiave privata non lascia mai il dispositivo. Viene generata sul dispositivo, memorizzata nell'enclave sicura o nel TPM, e non viene mai trasmessa in rete. Il dispositivo crea quindi una Certificate Signing Request, una CSR, e la invia al gateway SCEP. Il gateway convalida la richiesta, inoltra la CSR alla vostra Certificate Authority, e la CA la firma restituendo il certificato pubblico al dispositivo. Da quel momento in poi, quando il dispositivo si connette al tuo SSID WiFi, presenta il certificato al server RADIUS. Il server RADIUS convalida il certificato rispetto alla catena di attendibilità della CA, controlla l'elenco di revoca dei certificati per confermare che il certificato non sia stato revocato e, se tutto è in regola, invia un messaggio di accettazione all'access point. Il dispositivo è in rete. L'intero processo è invisibile all'utente. Ora parliamo di dove si colloca lo SCEP rispetto all'alternativa, che è PKCS. PKCS, Public Key Cryptography Standards, è l'altro metodo di distribuzione dei certificati supportato da piattaforme come Intune. Con PKCS, la CA genera sia la chiave pubblica che la chiave privata in modo centralizzato e il connettore del certificato spinge la coppia di chiavi sul dispositivo. Ciò significa che la chiave privata viaggia sulla rete, il che introduce una teorica superficie di attacco. Il PKCS va bene per casi d'uso come la crittografia delle e-mail S/MIME, dove il deposito delle chiavi è effettivamente auspicabile. Per l'autenticazione WiFi, lo SCEP è la scelta giusta. La chiave privata rimane sul dispositivo, senza eccezioni. Ora, il livello hardware. SCEP ed EAP-TLS sono standard indipendenti dal fornitore, il che significa che funzionano su access point Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. La configurazione RADIUS, sia essa Windows NPS, FreeRADIUS o un servizio RADIUS in cloud, è il luogo in cui si definiscono i criteri di convalida dei certificati e, soprattutto, in cui si configura l'assegnazione dinamica delle VLAN. Le VLAN dinamiche consentono di segmentare la rete in base all'identità. Un dispositivo di uno studente ottiene la VLAN 20 solo per l'accesso a Internet. Un dispositivo di un docente ottiene la VLAN 10 per l'accesso ai sistemi di ricerca interni. Un dispositivo di gestione delle strutture ottiene la VLAN 30 per l'accesso ai sistemi di gestione dell'edificio. Tutto questo è guidato dagli attributi del certificato e dalle policy RADIUS, senza alcun intervento manuale per dispositivo. Per l'integrazione con l'identity provider, gli attributi del certificato SCEP, in particolare il Subject Alternative Name, possono contenere il nome principale dell'utente da Microsoft Entra ID, Okta o Google Workspace. Questo lega il certificato a un'identità specifica, il che significa che quando si disabilita un account in Entra ID e l'MDM annulla la registrazione del dispositivo, il certificato viene revocato e l'accesso WiFi viene interrotto automaticamente. Questo è lo scenario di revoca che le chiavi precondivise semplicemente non possono offrire. Bene, parliamo della sequenza di distribuzione, perché è qui che la maggior parte dei team si blocca. La sequenza non è negoziabile: prima il certificato Trusted Root, poi il profilo del certificato SCEP, infine il profilo WiFi. Intune e Jamf applicano entrambi le dipendenze del profilo. Se il tuo profilo WiFi fa riferimento a un certificato SCEP che non è ancora stato distribuito sul dispositivo, il profilo WiFi fallirà con un errore criptico che sembra una configurazione errata ma è in realtà solo un problema di tempistica. Il secondo errore comune riguarda il targeting dei gruppi. Tutti e tre i profili, Trusted Root, SCEP e WiFi, devono essere distribuiti esattamente allo stesso gruppo di Azure AD o Jamf. Se il profilo SCEP ha come target un gruppo di utenti e il profilo WiFi ha come target un gruppo di dispositivi, Intune non sarà in grado di risolvere la dipendenza e il profilo WiFi risulterà come Non Applicabile. Questo è un errore in cui i team incorrono continuamente. Terzo: l'accessibilità del server NDES. Il server NDES deve essere raggiungibile da internet in modo che i dispositivi possano registrarsi prima di arrivare in sede. Il modo corretto di procedere è tramite Azure AD Application Proxy, non aprendo una porta nel firewall. App Proxy offre un accesso remoto sicuro senza porte in ingresso e consente di applicare i criteri di Conditional Access al flusso di registrazione. Quarto: la disponibilità della CRL. Il server RADIUS controlla la Certificate Revocation List ogni volta che un dispositivo esegue l'autenticazione. Se il punto di distribuzione CRL non è disponibile, a causa di un server offline o di un URL modificato, l'autenticazione fallisce contemporaneamente per tutti i dispositivi della rete. Questo significa un'interruzione del servizio a livello di intero campus. Rendete gli endpoint della CRL altamente disponibili e testate la revoca prima di andare online. Per le reti di grandi dimensioni, con più di 500 dispositivi, prendete in considerazione un gateway SCEP cloud anziché un server NDES on-premises. I gateway cloud eliminano il single point of failure di NDES, scalano orizzontalmente e in genere si integrano direttamente con i servizi RADIUS cloud, eliminando un'ulteriore dipendenza dall'infrastruttura. Rispondiamo ora ad alcune domande rapide che riceviamo spesso dai CTO. Il protocollo SCEP può gestire i dispositivi BYOD non registrati in un MDM? Non direttamente. SCEP richiede la registrazione MDM per inviare il payload del certificato. Per i dispositivi BYOD non gestiti, è necessario un approccio diverso, come un portale di onboarding self-service o un SSID separato che utilizza un Captive Portal con verifica dell'identità. Purple gestisce questo livello di dispositivi guest e BYOD in modo pulito, affiancandosi alla rete del personale autenticata tramite certificato. Cosa succede con iOS e Android? Entrambe le piattaforme supportano SCEP nativamente. iOS supporta SCEP fin da iOS 4. Android Enterprise supporta SCEP tramite Intune e altri MDM. La configurazione differisce leggermente in base alla piattaforma, ma il protocollo sottostante è identico. Il protocollo EAP-TLS funziona con WPA3? Sì. Lo standard WPA3-Enterprise impone la modalità di sicurezza a 192 bit per gli ambienti sensibili ed EAP-TLS è pienamente compatibile. Di fatto, WPA3-Enterprise con EAP-TLS è la combinazione raccomandata dalla Wi-Fi Alliance per le reti governative e finanziarie. Per riassumere. L'autenticazione WiFi tramite certificati SCEP è l'architettura corretta per qualsiasi rete con più di 50 dispositivi gestiti. Elimina le credenziali condivise, offre un'identità per singolo dispositivo, consente la segmentazione dinamica delle VLAN e si integra direttamente con l'identity provider per la revoca automatica. La sequenza di distribuzione, Trusted Root, poi profilo SCEP e infine profilo WiFi, è fissa. Il targeting dei gruppi deve essere coerente. La disponibilità della CRL non è opzionale. Nello specifico per l'istruzione superiore, la combinazione di SCEP per i dispositivi del personale e dei docenti, insieme a un livello di WiFi per ospiti separato per gli studenti sui dispositivi personali, offre sia sicurezza che un'ottima esperienza utente senza compromessi. Se desideri approfondire, la guida di Purple sull'autenticazione WiFi aziendale copre il percorso nativo del cloud. E se stai pensando a cosa succede quando un dipendente lascia l'azienda, la nostra guida sulla revoca dell'accesso al WiFi illustra l'intero flusso di lavoro di revoca. Grazie per l'attenzione. Sono del team tecnico di Purple e ci vediamo al prossimo briefing.

Parte della nostra serie principale: Guida alla sicurezza del WiFi aziendale

Come configurare SCEP per la registrazione automatizzata dei certificati WiFi aziendali

Sintesi esecutiva

Per gli ambienti aziendali - che si tratti di un hotel da 200 camere, di una catena retail con 50 punti vendita o di un grande centro congressi - affidarsi a chiavi pre-condivise per il WiFi dei dipendenti rappresenta un rischio per la sicurezza e un collo di bottiglia operativo. Una sola password trapelata espone l'intera rete. L'autenticazione basata su certificati tramite IEEE 802.1X e EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) elimina completamente questo rischio. Ogni dispositivo dimostra la propria identità in modo crittografico prima che l'access point conceda l'accesso alla rete.

La sfida risiede nella distribuzione. Implementare manualmente certificati client univoci su migliaia di dispositivi Windows, iOS e Android non è fattibile. Il protocollo SCEP (Simple Certificate Enrollment Protocol), formalizzato come RFC 8894 dall'IETF nel 2020, risolve questo problema. Automatizza il processo di richiesta, emissione e installazione dei certificati digitali sui dispositivi gestiti tramite la piattaforma MDM - senza alcuna interazione da parte dell'utente.

Questa guida copre l'intera architettura: cosa fa lo SCEP, come si integra con Microsoft Intune, Jamf e altre piattaforme MDM, l'esatta sequenza di implementazione che la maggior parte dei team sbaglia e le insidie operative che causano interruzioni del servizio. Esaminiamo inoltre due scenari reali di implementazione nel settore alberghiero e retail, e spieghiamo come si colloca la piattaforma di Guest WiFi di Purple accanto alla rete dei dipendenti autenticata tramite certificato.

Ascolta il podcast informativo complementare:


Analisi tecnica dettagliata: SCEP, PKI e 802.1X

Cosa fa realmente il SCEP

Il SCEP non sostituisce la tua Public Key Infrastructure (PKI). È il livello di registrazione automatizzato che si posiziona sopra di essa. La tua PKI - solitamente una gerarchia a due livelli con una CA radice offline e una CA emittente online - rimane l'ancora di fiducia. Il SCEP automatizza la fase in cui un dispositivo richiede un certificato a tale CA, eliminando la necessità di generazione manuale di CSR e installazione di certificati.

Nel contesto dell'autenticazione WiFi, il protocollo di destinazione è EAP-TLS. Questo è il metodo di autenticazione 802.1X che richiede sia al dispositivo client sia al server RADIUS di presentare certificati X.509 validi. Nessuna delle due parti si fida dell'altra senza una prova crittografica. Questo modello di autenticazione reciproca elimina il furto di credenziali e protegge dagli attacchi di tipo "evil twin", in cui un utente malintenzionato crea un punto di accesso falso per raccogliere nomi utente e password.

Per un'analisi dettagliata dell'handshake EAP-TLS, consulta la nostra guida su WiFi Certificate Authentication: Secure Network Access.

Come configurare SCEP per la registrazione automatizzata dei certificati WiFi aziendali - scep architecture overview

Il flusso di registrazione SCEP, passo dopo passo

L'intera catena di registrazione funziona nel modo seguente. La tua piattaforma MDM - Microsoft Intune, Jamf o un altro MDM - invia un payload SCEP a un dispositivo gestito. Tale payload contiene due elementi: l'URL SCEP che punta al tuo server NDES (Network Device Enrollment Service) o gateway SCEP cloud, e una password di verifica o segreto condiviso.

Il dispositivo genera localmente la propria coppia di chiavi pubblica e privata. Questa è la proprietà di sicurezza fondamentale del SCEP: la chiave privata viene generata sul dispositivo, memorizzata nell'enclave sicura o nel chip TPM, e non viene mai trasmessa sulla rete. Il dispositivo crea quindi una Certificate Signing Request (CSR) e la invia al gateway SCEP. Il gateway convalida la password di verifica, inoltra la CSR alla tua Autorità di Certificazione (CA), e la CA la firma e restituisce il certificato pubblico al dispositivo.

Da quel momento in poi, quando il dispositivo si connette al tuo SSID WiFi, presenta tale certificato al server RADIUS. Il server RADIUS convalida il certificato rispetto alla sua catena di fiducia della CA, controlla la Lista di Revoca dei Certificati (CRL) per confermare che il certificato non sia stato revocato e, se tutto è corretto, invia un messaggio Access-Accept al punto di accesso. Il dispositivo è in rete. L'intero processo è invisibile per l'utente.

SCEP vs. PKCS: quale utilizzare per il WiFi

As plataformas MDM como o Intune suportam dois mecanismos de entrega de certificados: SCEP e PKCS (Public Key Cryptography Standards). A diferença arquitetónica é significativa.

Com o SCEP, a chave privada é gerada no dispositivo e nunca sai dele. Com o PKCS, a Autoridade de Certificação gera a chave pública e a privada centralmente, e o conector de certificados envia o par de chaves para o dispositivo através da rede. Isso significa que a chave privada é transmitida, o que introduz uma superfície de ataque teórica.

O PKCS é adequado para casos de utilização em que a custódia de chaves é necessária, como a encriptação de e-mail S/MIME. Para a autenticação WiFi, o SCEP é a escolha correta. A chave privada permanece no dispositivo.

Propriedade SCEP PKCS
Geração de chave privada No dispositivo (TPM/Secure Enclave) Centralizada (CA)
Transmissão de chave privada Nunca Através da rede
Servidor NDES necessário Sim (ou gateway na nuvem) Não
Recomendado para WiFi Sim Não
Recomendado para S/MIME Não Sim

Compatibilidade de hardware

O SCEP e o EAP-TLS são normas independentes de fornecedor. Funcionam em pontos de acesso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A sua configuração RADIUS - quer seja Windows NPS, FreeRADIUS ou um serviço RADIUS na nuvem - é onde define a política de validação de certificados e a atribuição dinâmica de VLAN.

A atribuição dinâmica de VLAN é a forma como segmenta a rede através da identidade do dispositivo. Um dispositivo de um funcionário recebe a VLAN 10 com acesso a sistemas internos. O dispositivo de um prestador de serviços recebe a VLAN 20 apenas com acesso à internet. Um terminal de ponto de venda recebe a VLAN 30 apenas com acesso a sistemas de processamento de pagamentos. Tudo isto é gerido por atributos de certificado e pela política RADIUS, sem qualquer intervenção manual por dispositivo.

Para saber mais sobre como o WiFi Analytics se integra com a segmentação de rede baseada em identidade, consulte a nossa visão geral da plataforma de analytics.


Guia de implementação: a sequência de implementação

A configuração bem-sucedida do SCEP para WiFi empresarial exige a adesão estrita a uma sequência de implementação específica. As plataformas MDM impõem dependências de perfil: um perfil de WiFi que faça referência a um certificado SCEP não pode ser aplicado até que esse certificado exista no dispositivo. A violação desta sequência é a causa mais comum de falhas na implementação.

A sequência é: primeiro a Raiz de Confiança (Trusted Root), segundo o perfil SCEP, terceiro o perfil WiFi. Esta ordem não é negociável.

Come configurare SCEP per la registrazione automatizzata dei certificati WiFi aziendali - deployment checklist infographic

Passo 1: implementare il profilo del Certificato Root attendibile (Trusted Root)

Prima che qualsiasi dispositivo possa richiedere un certificato client o considerare attendibile il server RADIUS, deve considerare attendibile l'Autorità di Certificazione (CA) emittente. Esporta il certificato della CA Root - e qualsiasi certificato della CA intermedia - come file .cer. Nel centro di amministrazione MDM, crea un profilo Certificato Attendibile, carica il file .cer e distribuiscilo al gruppo di dispositivi di destinazione.

Se disponi di una gerarchia PKI a due livelli (consigliata), devi distribuire sia il certificato della CA root sia quello della CA emittente come profili Certificato Attendibile separati, o come catena in un singolo profilo, a seconda della piattaforma MDM.

Passo 2: configurare il profilo del Certificato SCEP

Una volta stabilita l'attendibilità, configura il profilo SCEP per istruire i dispositivi su come ottenere il proprio certificato client.

Crea un nuovo profilo di configurazione e seleziona il tipo di profilo certificato SCEP. Configura il formato del Nome Soggetto (Subject name). Per l'autenticazione basata sull'utente, il formato standard è CN={{UserPrincipalName}}. Per l'autenticazione del dispositivo (dispositivi condivisi, IoT, terminali POS), utilizza CN={{AAD_Device_ID}}. Imposta l'Uso della chiave (Key usage) su Firma digitale e Cifratura chiave. Imposta l'Uso della chiave avanzato (Extended Key Usage) su Autenticazione client (OID: 1.3.6.1.5.5.7.3.2). Associa questo profilo al profilo del certificato Root attendibile creato al Passo 1. Fornisci l'URL esterno del tuo server NDES. Per Microsoft Intune nello specifico, il server NDES deve essere pubblicato tramite Azure AD Application Proxy per consentire la registrazione dei dispositivi remoti prima che arrivino on-premise. Non esporre direttamente NDES a Internet.

Passo 3: distribuire il profilo WiFi 802.1X

Il passo finale consiste nell'inviare la configurazione WiFi che associa i certificati al SSID della rete. Crea un profilo di configurazione WiFi. Inserisci il Nome della rete (SSID) esattamente come viene trasmesso dai tuoi punti di accesso. Seleziona WPA2-Enterprise o WPA3-Enterprise come tipo di sicurezza. Imposta il tipo di EAP su EAP-TLS. Nelle impostazioni di autenticazione, seleziona il profilo del certificato SCEP creato al Passo 2 come certificato di autenticazione del client. Specifica il certificato Trusted Root per la convalida del server - questo garantisce che il dispositivo si connetta solo al tuo server RADIUS legittimo e non a un punto di accesso non autorizzato.

Integrazione del provider di identità

Gli attributi del certificato SCEP - nello specifico il Subject Alternative Name (SAN) - possono contenere il nome utente principale di Microsoft Entra ID, Okta o Google Workspace. Questo associa il certificato a un'identità specifica. Quando si disattiva un account in Entra ID e l'MDM rimuove la registrazione del dispositivo, il certificato viene revocato e l'accesso al WiFi viene interrotto automaticamente. Questa revoca automatizzata è il vantaggio di sicurezza che le chiavi pre-condivise non possono eguagliare.

Per saperne di più su EAP Method WiFi: A Guide to Secure Network Access, inclusi i percorsi di migrazione PEAP-MSCHAPv2, consultare la nostra guida dedicata.

-

Hai domande sulla tua configurazione specifica?

Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.

Best practice e standard di settore

Posizionamento del server NDES

Il server NDES deve essere accessibile da internet in modo che i dispositivi possano registrarsi prima di arrivare in sede. Pubblicare l'URL del NDES tramite Azure AD Application Proxy. Questo fornisce un accesso remoto sicuro senza aprire porte firewall in entrata e consente di applicare criteri di Accesso Condizionato al flusso di registrazione. Non esporre mai il NDES direttamente a internet.

Per le reti con più di 500 dispositivi gestiti, considerare un gateway SCEP nel cloud anziché un NDES locale. I gateway nel cloud eliminano il single point of failure del NDES, scalano orizzontalmente e, in genere, si integrano direttamente con i servizi RADIUS nel cloud.

Disponibilità della CRL

Il server RADIUS verifica la Certificate Revocation List (CRL) ogni volta che un dispositivo si autentica. Se il CRL Distribution Point (CDP) non è disponibile - perché un server è offline o l'URL è cambiato - l'autenticazione fallisce contemporaneamente per tutti i dispositivi sulla rete. Configurare il server NPS o RADIUS per imporre una verifica rigorosa della CRL e rendere gli endpoint CRL ad alta disponibilità. Testare la revoca prima di passare in produzione.

Il Requisito 8.6 dello standard PCI-DSS 4.0 richiede l'autenticazione a più fattori a livello di rete per gli ambienti con dati dei titolari di carta. L'EAP-TLS con certificati distribuiti tramite SCEP soddisfa questo requisito per le reti wireless nei settori Retail e Hospitality.

Compatibilità con WPA3

L'EAP-TLS è completamente compatibile con il WPA3-Enterprise. Il WPA3-Enterprise con la suite di sicurezza a 192 bit (Suite B) richiede l'EAP-TLS ed è la combinazione consigliata dalla Wi-Fi Alliance per le reti governative, finanziarie e sanitarie. Se si sta implementando in ambienti della Saúde o dei Transportes con severi requisiti di conformità, il WPA3-Enterprise con EAP-TLS è l'architettura di riferimento corretta.

BYOD e WiFi per gli ospiti

Lo SCEP richiede l'iscrizione al MDM per inviare il payload del certificato. Non copre i dispositivi BYOD non gestiti o gli ospiti. Per questi casi d'uso, è necessario un SSID separato con un Captive Portal e la verifica dell'identità. La piattaforma Purple gestisce questo livello in modo pulito, coesistendo con la rete aziendale autenticata tramite certificato. La nostra piattaforma di Guest WiFi supporta opt-in conformi, l'acquisizione di dati di prima parte (first-party) e l'integrazione con Microsoft Entra ID, Okta e Google Workspace per la verifica dell'identità.

-

Risoluzione dei problemi e mitigazione dei rischi

Mancata applicazione del profilo WiFi

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

Causa principale: Incompatibilità di targeting del gruppo. Se il profilo SCEP è destinato a un gruppo di Utenti e il profilo WiFi a un gruppo di Dispositivi, il MDM non riesce a risolvere la dipendenza.

Soluzione: Controlla le assegnazioni. Assicurati che i profili Trusted Root, SCEP e WiFi siano tutti destinati esattamente allo stesso gruppo di directory.

Errori NDES 403 Forbidden

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

Causa principale: L'account di servizio del connettore di certificati MDM non dispone delle autorizzazioni di Lettura e Registrazione (Read and Enroll) sul modello di certificato, oppure il filtraggio degli URL del firewall blocca i parametri della query string dello SCEP.

Soluzione: Verifica che l'account del connettore disponga delle autorizzazioni di Lettura e Registrazione nel modello della CA. Controlla i log del firewall per assicurarti che gli URL contenenti ?operation=GetCACaps non siano bloccati.

Errore di autenticazione di massa dopo la scadenza della CRL

Sintomo: Tutti i dispositivi sulla rete non riescono a completare l'autenticazione contemporaneamente.

Causa principale: La CRL è scaduta o l'URL del CDP è inaccessibile. Il server RADIUS non è in grado di confermare se i certificati sono validi e blocca l'accesso per sicurezza.

Soluzione: Configura il monitoraggio e gli avvisi per la CRL. Pubblica le CRL con un periodo di validità notevolmente superiore all'intervallo di pubblicazione. Verifica l'accessibilità del CDP dal server RADIUS prima del rilascio.

Scadenza del certificato con conseguenti errori silenziosi

Sintomo: I singoli dispositivi perdono la connessione in modo intermittente, senza un pattern chiaro.

Causa principale: I certificati client sono scaduti e il MDM non è riuscito a rinnovarli.

Soluzione: Configura il rinnovo del certificato per l'attivazione all'80% della durata del certificato stesso. Monitora i report sullo stato di registrazione del MDM per individuare i dispositivi con errori di certificato. Definisci periodi di validità del certificato adatti al ciclo di aggiornamento dei tuoi dispositivi - in genere da uno a due anni per gli endpoint gestiti.

-

ROI e impatto aziendale

Il passaggio all'autenticazione tramite certificato 802.1X basata su SCEP garantisce ritorni misurabili in termini di sicurezza, operazioni e conformità.

Riduzione dei ticket di supporto: Il WiFi basato su password genera un volume significativo di richieste di supporto - scadenze delle password, blocchi di account ed errori di digitazione. L'autenticazione basata su certificato è invisibile all'utente. Le organizzazioni registrano tipicamente una riduzione del 70-80% del volume di supporto relativo al WiFi dopo la migrazione.

Postura di sicurezza: EAP-TLS elimina il furto di credenziali e gli attacchi Man-in-the-Middle. Questo supporta direttamente la conformità allo standard PCI-DSS 4.0 per le reti del settore retail e hospitality, oltre ai requisiti dell'Articolo 32 del GDPR per le misure tecniche di sicurezza adeguate.

Revoca automatizzata: Quando un dipendente lascia l'azienda, la disattivazione del suo account in Microsoft Entra ID attiva la revoca automatica del certificato e la disassociazione dal MDM. L'accesso al WiFi viene interrotto senza alcun intervento manuale da parte del team di rete.

Segmentazione della rete: L'assegnazione dinamica della VLAN tramite gli attributi del certificato RADIUS offre una segmentazione della rete applicata in modo crittografico. I dispositivi accedono al segmento di rete corretto in base alle proprietà del certificato e non alla selezione dell'SSID o al filtraggio degli indirizzi MAC - entrambi facilmente aggirabili.

Purple opera in oltre 80.000 sedi attive con un tempo di attività del 99,999% e la nostra piattaforma vanta le certificazioni ISO 27001, GDPR, CCPA e Cyber Essentials. La nostra architettura cloud sovrapposta e agnostica rispetto all'hardware si integra con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet - per far sì che la rete dei tuoi dipendenti autenticata tramite certificato e il nostro livello di WiFi per gli ospiti funzionino sulla stessa infrastruttura.

Per saperne di più su come l'analisi comportamentale (Behavioral Analytics: Insights for WiFi Networks) può integrare l'implementazione della tua rete sicura, consulta la nostra guida all'analisi.

-

Riferimenti

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council

Definizioni chiave

SCEP (Simple Certificate Enrollment Protocol)

Un protocollo formalizzato in RFC 8894 che consente ai dispositivi gestiti di richiedere e ricevere automaticamente certificati digitali X.509 da un'Autorità di Certificazione tramite HTTP, utilizzando una password di verifica condivisa per l'autenticazione iniziale. La chiave privata viene generata sul dispositivo e mai trasmessa.

Il meccanismo standard utilizzato dalle piattaforme MDM come Microsoft Intune e Jamf per distribuire i certificati di autenticazione WiFi agli endpoint gestiti su scala.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

Il metodo di autenticazione 802.1X più sicuro, che richiede sia al dispositivo client che al server RADIUS di presentare certificati X.509 validi. L'autenticazione reciproca significa che nessuna delle due parti si fida dell'altra senza una prova crittografica.

Il protocollo di autenticazione di riferimento per il WiFi aziendale. Obbligatorio o fortemente raccomandato da PCI-DSS 4.0, WPA3-Enterprise a 192 bit (Suite B) e HIPAA per le reti wireless che gestiscono dati sensibili.

NDES (Network Device Enrollment Service)

Un ruolo di Microsoft Windows Server che funge da Autorità di Registrazione (RA) tra i dispositivi abilitati per SCEP e un'Autorità di Certificazione. Convalida le password di verifica e inoltra le CSR alla CA per conto dei dispositivi che non dispongono di credenziali di dominio.

Infrastruttura richiesta per la distribuzione SCEP con Microsoft Intune. Dovrebbe essere pubblicata tramite Azure AD Application Proxy anziché esposta direttamente a Internet.

PKI (Public Key Infrastructure)

La gerarchia di Autorità di Certificazione, criteri e procedure utilizzati per emettere, gestire e revocare certificati digitali. Una PKI a due livelli è composta da una CA radice offline (l'ancora di attendibilità principale) e da una CA di emissione online (che gestisce l'emissione quotidiana dei certificati).

Il prerequisito non negoziabile per la distribuzione di EAP-TLS e SCEP. La CA radice deve essere mantenuta isolata dalla rete (air-gapped); la sua chiave privata è il fondamento dell'intera catena di attendibilità dei certificati.

CSR (Certificate Signing Request)

Un messaggio generato da un dispositivo contenente la sua chiave pubblica e le informazioni di identità, inviato a un'Autorità di Certificazione per richiedere un certificato digitale firmato. In SCEP, la CSR viene generata sul dispositivo e protetta in una busta PKCS prima della trasmissione.

Generata automaticamente dal dispositivo durante il flusso di registrazione SCEP. La chiave privata utilizzata per firmare la CSR non lascia mai il dispositivo.

CRL (Certificate Revocation List)

Un elenco pubblicato dalla Certificate Authority contenente i numeri di serie dei certificati che sono stati revocati prima della loro data di scadenza. I server RADIUS controllano la CRL a ogni tentativo di autenticazione per garantire che i certificati revocati non possano accedere alla rete.

La disponibilità del CRL Distribution Point (CDP) è fondamentale. Se il server RADIUS non può raggiungere la CRL, si blocca in modalità di sicurezza (fail closed) e nega tutte le autenticazioni, causando un'interruzione su tutta la rete.

RADIUS (Remote Authentication Dial-In User Service)

Un protocollo di rete che fornisce autenticazione, autorizzazione e tracciamento (AAA) centralizzati per l'accesso alla rete. Nel WiFi 802.1X, il server RADIUS convalida i certificati client, controlla la CRL e restituisce un messaggio di Access-Accept o Access-Reject all'access point.

Il server di autenticazione nel modello supplicant-authenticator-server di 802.1X. Le implementazioni comuni includono Windows NPS, FreeRADIUS e servizi cloud RADIUS.

Assegnazione dinamica della VLAN

Una funzionalità RADIUS che colloca un dispositivo autenticato su una specifica VLAN in base agli attributi del certificato o all'appartenenza a gruppi di directory, anziché affidarsi alla selezione dell'SSID o al filtraggio degli indirizzi MAC. Applica la segmentazione della rete in base all'identità del dispositivo.

Consente a un singolo SSID di servire più tipi di dispositivi con diversi livelli di accesso alla rete. Un dispositivo del personale ottiene la VLAN 10 (accesso interno); il dispositivo di un fornitore ottiene la VLAN 20 (solo internet); un terminale POS ottiene la VLAN 30 (solo sistemi di pagamento).

MDM (Mobile Device Management)

Software utilizzato dai team IT per registrare, configurare, proteggere e gestire smartphone, tablet e laptop. Le piattaforme MDM come Microsoft Intune e Jamf utilizzano i profili SCEP per inviare istruzioni di registrazione del certificato ai dispositivi gestiti senza alcuna interazione da parte dell'utente.

Il prerequisito per la distribuzione dei certificati basata su SCEP. I dispositivi devono essere registrati nell'MDM prima di poter ricevere i profili SCEP e WiFi. I dispositivi BYOD non gestiti richiedono un approccio di onboarding separato.

Esempi pratici

Una struttura Premier Inn da 200 camere deve mettere in sicurezza il WiFi del personale per i tablet dei punti vendita e gli smartphone del servizio di pulizia. Attualmente utilizzano una chiave precondivisa che è stata divulgata a terzi. Gestiscono i dispositivi tramite Microsoft Intune e hanno un mix di dispositivi iOS e Android. La struttura utilizza access point HPE Aruba.

  1. Distribuire una PKI interna Microsoft AD CS a due livelli. Configurare NDES su un Windows Server dedicato e pubblicarlo tramite Azure AD Application Proxy.
  2. In Intune, creare un profilo di certificato radice attendibile contenente i certificati Root CA e Issuing CA. Distribuire a un gruppo Azure AD "Dispositivi del personale della struttura".
  3. Creare un profilo di certificato SCEP in Intune che punti all'URL esterno NDES. Impostare il formato del nome soggetto su CN={{AAD_Device_ID}} poiché si tratta di dispositivi condivisi. Impostare Key Usage su Digital Signature e Key Encipherment, ed Extended Key Usage su Client Authentication. Distribuire a "Dispositivi del personale della struttura".
  4. Creare un profilo Wi-Fi per l'SSID del personale, configurando WPA2-Enterprise ed EAP-TLS. Selezionare il profilo SCEP per l'autenticazione client e la Root CA per la convalida del server. Distribuire a "Dispositivi del personale della struttura".
  5. Configurare le impostazioni RADIUS di HPE Aruba per puntare a Windows NPS. Su NPS, configurare un criterio di rete che richieda EAP-TLS e assegni la VLAN 10 per i dispositivi del personale.
  6. Una volta che i dispositivi ricevono i profili e si connettono con successo, ruotare la PSK sul vecchio SSID e pianificarne la dismissione.
Commento dell'esaminatore: Questo approccio identifica correttamente che i dispositivi condivisi (POS, servizio di pulizia) richiedono un'autenticazione basata sul dispositivo (CN={{AAD_Device_ID}}) anziché basata sull'utente, poiché più membri del personale utilizzano lo stesso dispositivo. Segue la sequenza obbligatoria di distribuzione dei profili e garantisce che tutti e tre i profili abbiano come target lo stesso gruppo Azure AD. La pubblicazione di NDES tramite App Proxy anziché l'esposizione diretta a Internet è la corretta postura di sicurezza per un ambiente ricettivo.

Una catena di vendita al dettaglio con 50 sedi desidera implementare l'autenticazione 802.1X per i laptop aziendali in tutte le sedi. Utilizzano access point Cisco Meraki e Microsoft Intune. Non desiderano distribuire e gestire server NDES locali o infrastrutture AD CS in ciascuna sede o nel proprio data center.

  1. Implementare un servizio gateway SCEP e PKI basato su cloud che si integra con Intune tramite il protocollo SCEP. La CA cloud emette i certificati; il gateway SCEP cloud gestisce la convalida delle CSR.
  2. Configurare il servizio RADIUS cloud (fornito dal fornitore PKI) all'interno della dashboard Cisco Meraki in Wireless > Controllo di accesso per l'SSID aziendale. Impostare la sicurezza su WPA2-Enterprise e indirizzare il RADIUS al servizio cloud.
  3. In Intune, creare un profilo di certificato radice attendibile contenente il certificato radice della CA cloud. Distribuire al gruppo di dispositivi "Corporate Laptops".
  4. Creare un profilo di certificato SCEP che punti all'URL del gateway SCEP cloud. Impostare il Nome soggetto su CN={{UserPrincipalName}} per l'autenticazione basata su utente. Distribuire a "Corporate Laptops".
  5. Creare un profilo WiFi per l'SSID aziendale con EAP-TLS, facendo riferimento al profilo SCEP e alla radice della CA cloud. Distribuire a "Corporate Laptops".
  6. Quando i laptop si registrano in Intune, richiedono automaticamente i certificati alla CA cloud tramite il gateway SCEP cloud. Non è richiesta alcuna infrastruttura on-premises in nessuna delle 50 sedi.
Commento dell'esaminatore: Questa è l'architettura moderna ottimale per ambienti retail distribuiti. Sfruttando la PKI cloud e il RADIUS cloud, l'organizzazione elimina la necessità di mantenere una complessa infrastruttura on-premises (NDES, AD CS, NPS) in ciascun sito. Il gateway SCEP cloud si ridimensiona orizzontalmente ed è intrinsecamente ad alta disponibilità, eliminando il singolo punto di guasto introdotto da NDES on-premises. L'architettura gestita via cloud di Cisco Meraki si allinea perfettamente con questo approccio.

Domande di esercitazione

Q1. La tua organizzazione sta migrando da PEAP-MSCHAPv2 a EAP-TLS. Hai distribuito con successo i profili Trusted Root e SCEP al tuo gruppo Azure AD "Corporate Users" in Intune. Distribuisci il profilo WiFi a "All Corporate Devices". Gli utenti segnalano di non potersi connettere e il profilo WiFi risulta come Non applicabile.

Suggerimento: Controlla le dipendenze del profilo e le regole di targeting del gruppo. Intune risolve le dipendenze del profilo in base al gruppo assegnato.

Visualizza risposta modello

Il problema è un disallineamento nel targeting del gruppo. Il profilo WiFi dipende dal profilo SCEP, che era destinato a un gruppo di utenti ("Corporate Users"). Il profilo WiFi era invece destinato a un gruppo di dispositivi ("All Corporate Devices"). Intune non può risolvere la dipendenza tra tipi di gruppi diversi. La soluzione consiste nel modificare l'assegnazione di tutti e tre i profili - Trusted Root, SCEP e WiFi - per indirizzarli allo stesso gruppo. Decidi se utilizzare un gruppo di utenti o un gruppo di dispositivi in base al tuo modello di autenticazione (basato sull'utente rispetto a quello basato sul dispositivo) e applicalo in modo coerente a tutti e tre i profili.

Q2. Un audit di sicurezza rivela che quando un dipendente viene licenziato e il suo account Microsoft Entra ID viene disattivato, il suo smartphone aziendale può ancora connettersi alla rete WiFi del personale fino a una settimana dopo il licenziamento.

Suggerimento: Considera come il server RADIUS determina se un certificato è ancora valido dopo che l'account è stato disattivato. Qual è il meccanismo per comunicare lo stato di revoca?

Visualizza risposta modello

Il server RADIUS non sta eseguendo un controllo rigoroso della Certificate Revocation List, oppure la CRL viene pubblicata raramente. Quando un dipendente viene licenziato, l'MDM dovrebbe annullare la registrazione del dispositivo e la CA dovrebbe revocare il certificato. Tuttavia, se il server RADIUS non controlla la CRL a ogni tentativo di autenticazione - o se la CRL viene pubblicata solo settimanalmente - il certificato revocato continua ad essere accettato. La risoluzione prevede tre passaggi: configurare il server RADIUS per imporre un controllo rigoroso della CRL su ogni autenticazione; configurare la CA per pubblicare la CRL a un intervallo più breve (giornaliero o più frequente); e assicurarsi che l'MDM sia configurato per attivare la revoca del certificato quando un dispositivo viene rimosso dalla registrazione.

Q3. È necessario fornire un accesso WiFi sicuro per dispositivi IoT headless (termostati intelligenti, lettori di segnaletica digitale) che non possono eseguire un agente MDM e non possono visualizzare un Captive Portal. È possibile utilizzare SCEP per questi dispositivi e, in caso contrario, qual è l'alternativa consigliata?

Suggerimento: Considera i prerequisiti per la registrazione SCEP e quali alternative esistono per i dispositivi che non possono essere registrati tramite MDM o interagire con un browser.

Visualizza risposta modello

Non è possibile utilizzare SCEP per questi dispositivi. SCEP richiede un agente MDM per ricevere l'URL di registrazione e la password di verifica, generare la coppia di chiavi e installare il certificato risultante. I dispositivi IoT headless che non possono eseguire un agente MDM non possono partecipare al flusso di registrazione SCEP. Le alternative consigliate sono: (1) MAC Authentication Bypass (MAB) combinato con una rigorosa segmentazione VLAN - il server RADIUS consente l'accesso al dispositivo in base al suo indirizzo MAC e lo inserisce in una VLAN IoT isolata senza accesso ai sistemi aziendali; (2) se il dispositivo lo supporta, EST (Enrolment over Secure Transport, RFC 7030) può fornire certificati ai dispositivi che supportano HTTPS ma non l'MDM; (3) per i dispositivi dotati di un'interfaccia di gestione, alcuni fornitori supportano la registrazione SCEP direttamente tramite il firmware del dispositivo senza richiedere un agente MDM. In ogni caso, i dispositivi IoT dovrebbero essere isolati su una VLAN dedicata, indipendentemente dal metodo di autenticazione utilizzato.

Continua a leggere questa serie

Come segmentare in sicurezza le reti WiFi del personale e degli ospiti: Best Practice per LAN aziendali

Questa guida fornisce ai responsabili IT e agli architetti di rete un progetto tecnico, indipendente dai vendor, per proteggere le LAN aziendali segmentando correttamente il traffico WiFi del personale e degli ospiti. Copre l'autenticazione 802.1X, il cloud RADIUS, l'isolamento VLAN e la gestione del ciclo di vita delle credenziali necessaria per eliminare le password condivise e proteggere le risorse aziendali.

Leggi la guida →

Il miglior filtro DNS: una guida completa per le aziende

Questa guida tecnica di riferimento spiega in che modo il filtraggio DNS aziendale protegge le reti pubbliche bloccando i domini dannosi a livello di risoluzione - prima ancora che venga stabilita una connessione. Fornisce ai direttori IT, agli architetti di rete e ai team operativi delle sedi l'architettura di implementazione, la configurazione del firewall e il contesto di conformità necessari per proteggere il WiFi per gli ospiti in ambienti alberghieri, retail e del settore pubblico. Purple Shield blocca malware, botnet e contenuti inappropriati a livello DNS in oltre 80.000 sedi attive.

Leggi la guida →

Comprensione di Cisco SUDI: Identità ancorata all'hardware nel controllo degli accessi di rete sicuro

Questa guida spiega come Cisco SUDI fornisca un'identità crittograficamente sicura e ancorata all'hardware per l'infrastruttura di rete aziendale. Scopri come sostituire gli indirizzi MAC facilmente falsificabili con certificati 802.1AR immutabili per proteggere il controllo degli accessi alla rete della tua struttura.

Leggi la guida →

Hai domande sulla tua configurazione specifica?

Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.