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.
Video overview
Ascolta questa guida
Visualizza trascrizione del podcast
Parte della nostra serie principale: Guida alla sicurezza del WiFi aziendale →
- Sintesi esecutiva
- Analisi tecnica dettagliata: SCEP, PKI e 802.1X
- Cosa fa realmente il SCEP
- Il flusso di registrazione SCEP, passo dopo passo
- SCEP vs. PKCS: quale utilizzare per il WiFi
- Compatibilidade de hardware
- Guia de implementação: a sequência de implementação
- Passo 1: implementare il profilo del Certificato Root attendibile (Trusted Root)
- Passo 2: configurare il profilo del Certificato SCEP
- Passo 3: distribuire il profilo WiFi 802.1X
- Integrazione del provider di identità
- Best practice e standard di settore
- Posizionamento del server NDES
- Disponibilità della CRL
- Compatibilità con WPA3
- BYOD e WiFi per gli ospiti
- Risoluzione dei problemi e mitigazione dei rischi
- Mancata applicazione del profilo WiFi
- Errori NDES 403 Forbidden
- Errore di autenticazione di massa dopo la scadenza della CRL
- Scadenza del certificato con conseguenti errori silenziosi
- ROI e impatto aziendale
- Riferimenti

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.

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.

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.
- Distribuire una PKI interna Microsoft AD CS a due livelli. Configurare NDES su un Windows Server dedicato e pubblicarlo tramite Azure AD Application Proxy.
- 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".
- 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".
- 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".
- 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.
- Una volta che i dispositivi ricevono i profili e si connettono con successo, ruotare la PSK sul vecchio SSID e pianificarne la dismissione.
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.
- 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.
- 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.
- In Intune, creare un profilo di certificato radice attendibile contenente il certificato radice della CA cloud. Distribuire al gruppo di dispositivi "Corporate Laptops".
- 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".
- 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".
- 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.
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.
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.
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.
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.