- Purple
- Enterprise WiFi security and authentication: a complete guide
- Guida alla configurazione SCEP Enterprise: autenticazione WiFi basata su certificati per l'istruzione superiore e reti di grandi dimensioni
Guida alla configurazione SCEP Enterprise: autenticazione WiFi basata su certificati per l'istruzione superiore e reti di grandi dimensioni
Questa guida fornisce un progetto tecnico completo per l'implementazione dell'autenticazione WiFi basata su certificati tramite SCEP. Copre la transizione architetturale dalle chiavi pre-condivise a EAP-TLS, le sequenze di distribuzione sulle piattaforme MDM e le strategie critiche di mitigazione del rischio per reti su larga scala.
Video overview
Ascolta questa guida
Visualizza trascrizione del podcast
Parte della nostra serie principale: Guida alla sicurezza WiFi Enterprise →
- Sintesi Esecutiva
- Approfondimento tecnico: architettura SCEP e 802.1X
- SCEP (Simple Certificate Enrolment Protocol)
- EAP-TLS e autenticazione reciproca
- Guida all'implementazione: sequenza di distribuzione
- Passo 1: Distribuire il profilo del certificato Root attendibile
- Passo 2: Configurare il profilo del certificato SCEP
- Passaggio 3: Distribuisci il profilo WiFi 802.1X
- Best Practice e standard di settore
- Posizionamento e sicurezza del server NDES
- RADIUS e controllo della CRL
- Distribuzione indipendente dall'hardware
- Risoluzione dei problemi e mitigazione dei rischi
- Problema: Impossibile applicare il profilo WiFi
- Problema: Errore NDES 403 Accesso negato

Sintesi Esecutiva
Per le sedi aziendali - che si tratti di un moderno campus universitario, di un'operazione retail multi-sito o di un grande gruppo alberghiero - affidarsi a chiavi pre-condivise per la rete WiFi del personale e operativa introduce vulnerabilità di sicurezza e complessità operative inaccettabili. La moderna architettura di rete richiede l'autenticazione 802.1X tramite EAP-TLS, garantendo che ogni dispositivo sia verificato crittograficamente prima di ottenere l'accesso alla rete.
La sfida risiede nella distribuzione: distribuire certificati client univoci a migliaia di dispositivi Windows, iOS e Android senza seppellire l'helpdesk sotto una valanga di ticket di supporto. Microsoft Intune, Jamf e altre piattaforme MDM risolvono questo problema attraverso la gestione automatizzata del ciclo di vita dei certificati. Utilizzando il protocollo SCEP (Simple Certificate Enrolment Protocol), i team IT possono inviare in modo invisibile certificati root e client attendibili agli endpoint gestiti.
Questa guida fornisce un modello architetturale definitivo e una strategia di implementazione dettagliata per la distribuzione dei certificati SCEP aziendali. Esploreremo la sequenza di distribuzione necessaria per il successo, delineeremo le strategie di mitigazione del rischio nel mondo reale e descriveremo in dettaglio come l'approccio di rete basato sull'identità di Purple si allinea con questi requisiti.
Approfondimento tecnico: architettura SCEP e 802.1X
Quando si progetta una strategia di implementazione WiFi basata su certificati, la comprensione delle interazioni dei protocolli sottostanti è fondamentale. SCEP è il meccanismo di distribuzione; EAP-TLS è il protocollo di autenticazione.
SCEP (Simple Certificate Enrolment Protocol)
SCEP è lo standard di settore per la registrazione dei dispositivi aziendali. In un flusso di lavoro SCEP, il servizio MDM indica all'endpoint di generare la propria coppia di chiavi privata e pubblica. Il dispositivo crea una richiesta di firma del certificato (CSR) e la invia alla Certificate Authority (CA) tramite un server NDES (Network Device Enrolment Service) o un gateway cloud. La CA firma la richiesta e restituisce il certificato pubblico al dispositivo.
Il principale vantaggio in termini di sicurezza di SCEP è che la chiave privata non lascia mai il dispositivo. Viene generata localmente, memorizzata nell'enclave hardware sicuro del dispositivo e non viene mai trasmessa sulla rete. Questo rende SCEP il metodo caldamente raccomandato per l'autenticazione 802.1X.

EAP-TLS e autenticazione reciproca
EAP-TLS (Extensible Authentication Protocol with Transport Layer Security) risiede all'interno del framework 802.1X. EAP-TLS è ampiamente considerato il metodo di autenticazione più sicuro per le reti wireless aziendali perché richiede un'autenticazione reciproca. Sia il dispositivo client che il server RADIUS devono presentare certificati validi. Nessuna delle due parti si fida dell'altra senza una prova crittografica. Questa autenticazione reciproca protegge la rete da access point non autorizzati e dalla sottrazione di credenziali.
Quando un dispositivo si connette al tuo SSID WiFi, presenta il suo certificato al server RADIUS. Il server RADIUS convalida il certificato rispetto alla catena di attendibilità della CA, controlla la Certificate Revocation List (CRL) per verificare che il certificato non sia stato revocato e, in caso di successo, invia un messaggio di accettazione all'access point.
Guida all'implementazione: sequenza di distribuzione
La configurazione corretta di un profilo WiFi MDM per 802.1X richiede il rispetto rigoroso di una specifica sequenza di distribuzione. Le dipendenze del profilo impongono che l'attendibilità debba essere stabilita prima di poter configurare l'autenticazione.
Passo 1: Distribuire il profilo del certificato Root attendibile
Prima che qualsiasi dispositivo possa richiedere un certificato client o considerare attendibile il server RADIUS, deve considerare attendibile la Certificate Authority emittente.
- Esporta il certificato della CA radice come file .cer.
- Nel tuo MDM (ad es. Intune o Jamf), crea un profilo Certificato attendibile.
- Carica il file .cer e distribuisci questo profilo ai gruppi di dispositivi di destinazione.
Passo 2: Configurare il profilo del certificato SCEP
Una volta stabilita l'attendibilità, configura il profilo SCEP per istruire i dispositivi su come ottenere i loro certificati client.
- Crea un nuovo profilo di configurazione e seleziona il certificato SCEP.
- Configura il formato del nome del soggetto (Subject name format). Per l'autenticazione gestita dall'utente, utilizza lo User Principal Name.
- Imposta l'utilizzo della chiave (Key usage) su Firma digitale (Digital signature) e Cifratura chiave (Key encipherment).
- In Utilizzo esteso della chiave (Extended key usage), specifica Autenticazione client (Client Authentication).
- Collega questo profilo al profilo del certificato Root attendibile creato nel Passaggio 1.
- Fornisci l'URL esterno del tuo server NDES o del gateway SCEP.
Passaggio 3: Distribuisci il profilo WiFi 802.1X
Il passaggio finale consiste nell'inviare la configurazione WiFi che associa i certificati al SSID di rete.
- Crea un profilo di configurazione WiFi.
- Inserisci il nome della rete (SSID) esattamente come trasmesso dai tuoi access point.
- Seleziona WPA2-Enterprise o WPA3-Enterprise come tipo di sicurezza.
- Imposta il tipo EAP su EAP-TLS.
- Seleziona il profilo del certificato SCEP creato nel Passaggio 2 come certificato di autenticazione client.
- Specifica il certificato Root attendibile per la convalida del server.
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
Quando implementi la distribuzione dei certificati SCEP, attieniti a queste best practice indipendenti dal fornitore per garantire conformità e affidabilità.
Posizionamento e sicurezza del server NDES
Per consentire ai dispositivi remoti di richiedere i certificati prima del loro arrivo in sede, il server NDES deve essere accessibile da Internet. Tuttavia, esporre direttamente un server interno a Internet rappresenta un grave rischio per la sicurezza. Pubblica l'URL NDES utilizzando Azure AD Application Proxy o utilizza un gateway SCEP ospitato nel cloud. Questo fornisce un accesso remoto sicuro senza aprire porte in entrata nel firewall.
RADIUS e controllo della CRL
La distribuzione dei certificati è solo una metà dell'equazione di sicurezza; la revoca è altrettanto critica. Se un dipendente lascia l'azienda, il suo certificato client rimane valido e, se il server RADIUS non controlla rigorosamente la Certificate Revocation List (CRL), disabilitare il suo account Active Directory potrebbe non revocare immediatamente il suo accesso WiFi. Configura il tuo server RADIUS per applicare un controllo rigoroso della CRL e assicurati che i tuoi punti di distribuzione CRL siano altamente disponibili.
Distribuzione indipendente dall'hardware
SCEP e EAP-TLS sono standard indipendenti dal fornitore. La tua distribuzione deve essere agnostica rispetto all'hardware, funzionando senza problemi su infrastrutture Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.
Risoluzione dei problemi e mitigazione dei rischi
Nonostante una corretta pianificazione, le distribuzioni dei certificati possono riscontrare problemi.
Problema: Impossibile applicare il profilo WiFi
Questo problema è quasi sempre causato da una mancata corrispondenza nel target del gruppo. Se il profilo SCEP è assegnato a un gruppo di utenti, ma il profilo WiFi è assegnato a un gruppo di dispositivi, l'MDM non può risolvere la dipendenza. Assicurati che i profili Root attendibile, SCEP e WiFi siano tutti distribuiti esattamente allo stesso gruppo.
Problema: Errore NDES 403 Accesso negato
I dispositivi non riescono a recuperare i certificati SCEP. Ciò è probabilmente dovuto al fatto che il modello di certificato non dispone delle autorizzazioni richieste per l'account di servizio Intune Certificate Connector, oppure il filtro URL del firewall sta bloccando parametri specifici della stringa di query utilizzati da SCEP.## ROI e impatto aziendale
Il passaggio alla distribuzione dei certificati SCEP 802.1X offre ritorni misurabili in termini di sicurezza e operazioni.

- Riduzione dei ticket di helpdesk: Il WiFi basato su password genera un volume elevato di ticket di supporto. L'autenticazione basata su certificato è invisibile all'utente, riducendo in genere i carichi di lavoro dell'helpdesk relativi al WiFi fino al 70%.
- Miglioramento del livello di sicurezza: EAP-TLS elimina il rischio di furto di credenziali e attacchi man-in-the-middle. Questo è fondamentale per la conformità a framework come PCI DSS e GDPR.
- Onboarding fluido: Per le organizzazioni che gestiscono grandi flotte di dispositivi Apple insieme a Windows, l'integrazione con i flussi di lavoro MDM esistenti garantisce un'esperienza di provisioning unificata e a zero tocchi.
- Segmentazione dinamica: Supporta l'assegnazione dinamica della VLAN in base all'identità, isolando i dispositivi IoT dai dati aziendali senza richiedere SSID separati.
Per ulteriori letture, consulta le nostre guide correlate: Enterprise WiFi Security: A Complete Guide for 2026 e How to revoke WiFi access when an employee leaves.
Definizioni chiave
SCEP (Simple Certificate Enrollment Protocol)
Un protocollo che automatizza la richiesta e il rilascio di certificati digitali ai dispositivi gestiti senza intervento umano.
Utilizzato dalle piattaforme MDM per fornire in modo sicuro identità univoche ai dispositivi per l'autenticazione di rete.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Il metodo di autenticazione 802.1X più sicuro, che richiede sia al client che al server RADIUS di presentare certificati digitali validi.
Il protocollo di autenticazione di destinazione che i certificati SCEP sono predisposti per supportare.
802.1X
Uno standard IEEE per il controllo dell'accesso alla rete basato su porta che fornisce un meccanismo di autenticazione ai dispositivi che desiderano connettersi a una LAN o WLAN.
Il framework generale che protegge le reti aziendali dagli accessi non autorizzati.
RADIUS
Un protocollo di rete che fornisce una gestione centralizzata di autenticazione, autorizzazione e tracciamento per gli utenti che si connettono e utilizzano un servizio di rete.
Il componente server che convalida il certificato client e determina a quale VLAN deve associarsi il dispositivo.
CSR (Certificate Signing Request)
Un blocco di testo codificato fornito a un'autorità di certificazione quando si richiede un certificato SSL/TLS, contenente la chiave pubblica e le informazioni sull'identità.
Generato localmente sul dispositivo durante il processo di registrazione SCEP.
NDES (Network Device Enrollment Service)
Un ruolo di Windows Server Microsoft che funge da ponte, consentendo ai dispositivi di ottenere certificati tramite SCEP.
Il gateway che riceve la CSR dal dispositivo e la inoltra all'autorità di certificazione interna.
CRL (Certificate Revocation List)
Un elenco pubblicato dall'autorità di certificazione contenente i numeri di serie dei certificati che sono stati revocati e non devono più essere considerati affidabili.
Verificato dal server RADIUS durante l'autenticazione per garantire che il dispositivo di un dipendente licenziato non possa connettersi.
VLAN (Virtual Local Area Network)
Una sottorete logica che raggruppa un insieme di dispositivi provenienti da diverse LAN fisiche.
Utilizzato in combinazione con RADIUS per segmentare dinamicamente il traffico di rete in base all'identità presentata nel certificato SCEP.
Esempi pratici
Un hotel di 400 camere deve implementare un WiFi operativo sicuro per 150 dispositivi del personale (tablet e laptop) garantendo al contempo una rigorosa separazione dalla rete Guest WiFi.
Il team IT configura un gateway SCEP cloud integrato con il proprio MDM. Distribuisce un profilo Trusted Root, seguito da un profilo SCEP destinato al gruppo di dispositivi 'Hotel Operations'. Viene quindi distribuito un profilo WiFi per l'SSID 'Staff-Secure', configurato per WPA3-Enterprise ed EAP-TLS. Il server RADIUS è configurato per assegnare questi dispositivi autenticati alla VLAN 40, isolandoli completamente dal Guest WiFi (VLAN 50).
Un grande campus universitario con 25.000 studenti e 3.000 dipendenti deve proteggere la sua rete 'Edu-Secure'. Attualmente utilizzano PEAP con nomi utente e password, il che comporta oltre 500 ticket di helpdesk al mese a causa della scadenza delle password.
L'università migra i dispositivi del personale e dei docenti a EAP-TLS utilizzando Intune e SCEP. Distribuisce i profili di certificato nella sequenza rigorosa (Root -> SCEP -> WiFi) ai gruppi di utenti del personale. Per i dispositivi BYOD non gestiti degli studenti, distribuisce un portale di onboarding separato che fornisce certificati temporanei o utilizza la piattaforma Guest WiFi di Purple con autenticazione basata su profilo per un accesso sicuro e trasparente.
Domande di esercitazione
Q1. Il tuo team sta distribuendo un nuovo profilo di certificato SCEP a una flotta di 500 laptop Windows. Il profilo Trusted Root è stato distribuito al gruppo "All Corporate Devices". Il profilo SCEP è stato distribuito al gruppo "All Corporate Users". Il profilo WiFi risulta come "Non applicabile" sui laptop. Qual è la causa principale?
Suggerimento: Considera le regole di dipendenza del profilo Intune e i requisiti di targeting del gruppo.
Visualizza risposta modello
La causa principale è una discrepanza nel targeting dei gruppi. Intune richiede che i profili dipendenti (Root, SCEP, WiFi) siano distribuiti esattamente allo stesso tipo di gruppo. Poiché il profilo Root si rivolge ai dispositivi e il profilo SCEP si rivolge agli utenti, la catena di dipendenza è interrotta. Tutti e tre i profili devono rivolgersi allo stesso gruppo di dispositivi o allo stesso gruppo di utenti.
Q2. Un direttore delle operazioni alberghiere desidera proteggere la rete WiFi del personale utilizzando EAP-TLS. Suggerisce di utilizzare PKCS anziché SCEP perché non richiede un server NDES. In qualità di network architect, perché dovresti sconsigliare questa scelta per l'autenticazione WiFi?
Suggerimento: Pensa a dove viene generata la chiave privata e a come viaggia.
Visualizza risposta modello
Dovresti sconsigliare PKCS per l'autenticazione WiFi perché richiede che la chiave privata venga generata centralmente dalla CA e trasmessa attraverso la rete al dispositivo. SCEP è significativamente più sicuro perché il dispositivo genera la chiave privata localmente e la memorizza in un enclave hardware sicuro; la chiave privata non lascia mai il dispositivo.
Q3. Durante un controllo di rete, scopri che il server RADIUS è configurato per ignorare gli errori di controllo della CRL (Certificate Revocation List). Quale specifico rischio per la sicurezza introduce questo comportamento quando un dipendente viene licenziato?
Suggerimento: Considera cosa succede alla validità del certificato se l'MDM annulla la registrazione del dispositivo ma il server RADIUS non può verificare lo stato di revoca.
Visualizza risposta modello
Se il controllo della CRL viene ignorato o fallisce consentendo comunque l'accesso, un dipendente licenziato il cui dispositivo è stato rimosso (e il cui certificato è stato revocato dalla CA) potrebbe essere ancora in grado di connettersi alla rete WiFi. Il server RADIUS vedrà un certificato crittograficamente valido e, senza controllare la CRL, concederà l'accesso, creando una grave vulnerabilità di sicurezza.
Continua a leggere questa serie
Conformità CIPA: checklist di conformità per i gestori di sedi
Sarai in grado di decidere se la conformità CIPA vincola il tuo WiFi, quindi segmentare le reti, instradare il DNS tramite Purple Shield e chiudere i percorsi di bypass. Saprai anche quali prove conservare per la certificazione del Form 486 o del Form 479. La checklist assegna ogni requisito a un responsabile, in modo che la certificazione del prossimo anno di finanziamento non presenti lacune.
Errori di connessione in modalità di transizione WPA3: una checklist di implementazione per Cisco Meraki, HPE Aruba e Ruckus
Usa questa checklist per diagnosticare il motivo per cui i dispositivi non riescono a connettersi a un SSID in modalità di transizione WPA3 SAE e risolvere il problema su Cisco Meraki, HPE Aruba o Ruckus. Imparerai a far corrispondere i codici di stato 802.11 alle relative cause, a isolare i problemi di PMF, 802.11r e 6GHz, e a decidere quando passare a un SSID solo WPA3.
Miglior filtraggio DNS: una guida completa per le aziende
Questa guida di riferimento tecnica spiega come il filtraggio DNS aziendale protegga le reti pubbliche bloccando i domini dannosi a livello di risoluzione - prima ancora che venga stabilita una connessione. Offre ai direttori IT, agli architetti di rete e ai team operativi delle strutture l'architettura di implementazione, la configurazione del firewall e il contesto di conformità necessari per proteggere il WiFi per gli ospiti nei settori dell'ospitalità, del retail e del settore pubblico. Purple Shield blocca malware, botnet e contenuti inappropriati a livello DNS in oltre 80.000 sedi attive.
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.