Come implementare SCEP per l'assegnazione automatizzata dei certificati WiFi
Questa guida spiega come implementare SCEP (Simple Certificate Enrollment Protocol) per l'assegnazione automatizzata dei certificati WiFi nelle sedi aziendali. Copre l'intero schema architetturale - dalla progettazione PKI e integrazione MDM alla sequenza obbligatoria di implementazione in tre passaggi - e mostra ai manager IT e agli architetti di rete come eliminare le credenziali condivise, automatizzare la gestione del ciclo di vita dei certificati e soddisfare i requisiti PCI DSS e GDPR su scala globale.
Ascolta questa guida
Visualizza trascrizione del podcast
Sintesi esecutiva
Per i gestori di location che offrono il Guest WiFi in hotel, punti vendita, stadi e centri congressi, affidarsi a chiavi pre-condivise o a Captive Portal di base per l'accesso alla rete del personale rappresenta un rischio per la sicurezza. La moderna architettura di rete richiede l'autenticazione 802.1X tramite EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), garantendo che ogni dispositivo sia verificato crittograficamente prima di accedere alla rete. La sfida risiede nella distribuzione: come distribuire certificati client univoci a migliaia di dispositivi Windows, iOS e Android senza sovraccaricare l'helpdesk?
La risposta è SCEP (Simple Certificate Enrollment Protocol). Formalizzato dall'IETF come RFC 8894 nel 2020, SCEP automatizza la registrazione dei certificati su flotte di dispositivi gestiti. Se integrato con una piattaforma MDM come Microsoft Intune o Jamf, SCEP offre un provisioning dei certificati zero-touch: i dispositivi richiedono, ricevono e rinnovano i propri certificati senza alcun intervento da parte dell'IT. La chiave privata viene generata localmente sul dispositivo e non viene mai trasmessa sulla rete, un vantaggio fondamentale in termini di sicurezza rispetto alla distribuzione basata su PKCS.
Questa guida illustra l'intero flusso di lavoro dell'implementazione di SCEP: l'architettura PKI, la configurazione del gateway NDES, la sequenza obbligatoria di implementazione dell'MDM in tre passaggi e i controlli operativi (in particolare il controllo CRL e il targeting dei gruppi) che determinano il successo o il blocco di una distribuzione. Due scenari reali illustrano l'approccio nei settori dell'ospitalità e del retail. Purple opera in oltre 80.000 location attive e conta 350 milioni di utenti unici; i modelli descritti qui riflettono ciò che funziona su tale scala.
Approfondimento tecnico
Cosa fa concretamente SCEP
SCEP si colloca tra la piattaforma MDM e la Certificate Authority (CA). Fornisce un meccanismo standardizzato basato su HTTP che consente ai dispositivi di richiedere, ricevere e rinnovare certificati X.509 senza richiedere credenziali associate a un dominio o l'intervento manuale di un amministratore. Il protocollo è stato originariamente sviluppato nei primi anni 2000 e ha ottenuto un'ampia adozione negli ambienti MDM aziendali prima che l'IETF lo pubblicasse formalmente come RFC 8894.
Il flusso di registrazione in sei passaggi funziona come segue. Primo, il dispositivo gestito si connette all'URL del gateway SCEP preconfigurato nel suo profilo MDM. Secondo, il dispositivo genera localmente una coppia di chiavi privata/pubblica e crea una Certificate Signing Request (CSR). Terzo, il gateway SCEP convalida l'autorizzazione del dispositivo utilizzando una challenge password o OTP incorporata nella policy MDM. Quarto, il gateway inoltra la CSR convalidata alla CA. Quinto, la CA firma il certificato e lo restituisce al gateway. Sesto, il gateway distribuisce il certificato firmato al dispositivo. I rinnovi futuri seguono lo stesso percorso automatizzato: il dispositivo si registra nuovamente prima della scadenza senza alcun intervento da parte dell'utente o dell'amministratore.
SCEP vs PKCS: la decisione che conta
Microsoft Intune e la maggior parte delle piattaforme MDM supportano due meccanismi di distribuzione dei certificati: SCEP e PKCS. La differenza è architetturale, non estetica.
Con SCEP, la chiave privata viene generata sul dispositivo e rimane lì. La CA non la vede mai. Il TPM del dispositivo (su Windows) o il Secure Enclave (su iOS/macOS) protegge la chiave a livello hardware. Con PKCS, la CA genera la coppia di chiavi centralmente e la trasmette al dispositivo tramite la rete. La CA ne conserva una copia, consentendo il key escrow, utile per la crittografia delle email S/MIME ma che introduce rischi non necessari per l'autenticazione di rete.
Per l'autenticazione WiFi 802.1X, usa SCEP. La chiave privata non lascia mai il dispositivo. Questa è la regola.
| Criterio | SCEP | PKCS |
|---|---|---|
| Chiave privata generata su | Dispositivo | CA (centralmente) |
| Chiave privata trasmessa sulla rete | Mai | Sì |
| Supporta TPM / Secure Enclave | Sì | No |
| Consigliato per auth WiFi | Sì | No |
| Consigliato per crittografia email (S/MIME) | No | Sì |
| Key escrow possibile | No | Sì |
802.1X e EAP-TLS: il framework di autenticazione
IEEE 802.1X è lo standard di controllo dell'accesso alla rete basato su porta che alla base della sicurezza dei sistemi WiFi enterprise. Definisce tre ruoli: il supplicant (il dispositivo client), l'authenticator (l'access point - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet) e l'authentication server (un server RADIUS come Microsoft NPS, FreeRADIUS o Cisco ISE).
EAP-TLS è il metodo EAP più sicuro per lo standard 802.1X. Entrambe le parti presentano dei certificati: il server RADIUS presenta il proprio certificato al client, e il client presenta il proprio certificato fornito tramite SCEP al server RADIUS. Nessuna delle due parti può impersonare l'altra senza un certificato valido e non revocato proveniente dalla gerarchia CA attendibile. Questo modello di autenticazione reciproca elimina il furto di credenziali, gli attacchi Evil Twin e i rischi di access point non autorizzati con un'unica decisione architetturale.
EAP-TLS soddisfa il requisito PCI DSS 4.0 8.6 per l'autenticazione a più fattori a livello di rete. È richiesto per le implementazioni WPA3 Enterprise a 192 bit (Suite B). Per qualsiasi rete wireless rientrante nell'ambito del trattamento dei dati dei titolari di carta - punti vendita al dettaglio, reception di hotel, biglietterie di stadi - EAP-TLS è la scelta corretta.
Per un'analisi più approfondita dell'architettura per il secure WiFi e di come l'autenticazione basata su certificati si inserisca in un contesto di sicurezza più ampio, consulta la nostra guida essenziale.
Guida all'implementazione
La sequenza di distribuzione non è negoziabile. Intune e Jamf risolvono le dipendenze dei profili in ordine: il profilo WiFi dipende dal profilo SCEP, che a sua volta dipende dal profilo Trusted Root. Se vengono distribuiti fuori sequenza, l'applicazione del profilo WiFi fallirà.
Passaggio 1: Progetta la tua PKI
Prima di toccare una console MDM, progetta la tua gerarchia di certificati. Una PKI a due livelli rappresenta lo standard: una CA radice (root CA) offline e una CA emittente (issuing CA) online. La chiave privata della root CA è l'ancora di attendibilità principale per l'intera infrastruttura dei certificati: mantienila isolata (air-gapped). La CA emittente gestisce il rilascio quotidiano dei certificati e pubblica la Certificate Revocation List (CRL) e il risponditore OCSP.
Per la maggior parte delle distribuzioni in spazi aziendali, Active Directory Certificate Services (AD CS) di Microsoft in esecuzione su Windows Server fornisce la CA emittente. I servizi PKI ospitati in cloud di provider come SCEPman o SecureW2 eliminano completamente la necessità di un'infrastruttura on-premises e vale la pena valutarli per distribuzioni su proprietà distribuite, come catene alberghiere, catene di vendita al dettaglio o organizzazioni del settore pubblico multi-sito.
Passaggio 2: Distribuisci il server NDES (o il gateway SCEP cloud)
NDES (Network Device Enrollment Service) è il ruolo di Microsoft Windows Server che funge da gateway SCEP tra l'MDM e la CA. Requisiti di configurazione chiave:
- Pubblica l'URL di NDES esternamente tramite Azure AD Application Proxy (o proxy inverso equivalente). Ciò consente ai dispositivi remoti di registrarsi prima del loro arrivo in sede, senza aprire porte in entrata sul firewall.
- L'account di servizio NDES richiede le autorizzazioni di Lettura e Registrazione sul modello di certificato della CA.
- Configura il modello di certificato con Key Usage impostato su Firma digitale e Crittografia chiave (Digital Signature e Key Encipherment), e Extended Key Usage impostato su Autenticazione client (Client Authentication - OID: 1.3.6.1.5.5.7.3.2).
- Imposta un periodo di validità del certificato appropriato. Un anno è lo standard per i certificati client; due anni sono accettabili per i certificati dei dispositivi in flotte stabili. Se preferisci evitare l'infrastruttura NDES on-premises, i gateway SCEP cloud si integrano direttamente con Intune e la tua CA tramite API, eliminando completamente la dipendenza da IIS.
Passaggio 3: Distribuisci il profilo del certificato Root attendibile
Nella tua piattaforma MDM, crea un profilo Certificato attendibile e carica il certificato della tua Root CA (e qualsiasi certificato CA intermedio) come file .cer. Distribuisci questo profilo ai tuoi gruppi di dispositivi di destinazione prima di qualsiasi altro profilo di certificato o WiFi. Senza questo passaggio, i dispositivi non possono convalidare il certificato del server RADIUS durante l'handshake EAP-TLS e non possono considerare attendibile la CA emittente quando richiedono il proprio certificato SCEP.
Regola pratica: Indirizza sempre lo stesso gruppo Azure AD (Utenti o Dispositivi) in tutti e tre i profili correlati. Un disallineamento in questo punto è la causa singola più comune di errori di distribuzione del profilo WiFi.
Passaggio 4: Configura il profilo del certificato SCEP
Crea un profilo di configurazione del certificato SCEP nel tuo MDM:
- Formato del nome del soggetto (Subject name format): Per l'autenticazione basata sull'utente, usa
CN={{UserPrincipalName}}. Per l'autenticazione del dispositivo (consigliata per dispositivi condivisi e IoT), usaCN={{AAD_Device_ID}}. - Utilizzo chiave (Key usage): Firma digitale, Crittografia chiave.
- Utilizzo chiave esteso (Extended key usage): Autenticazione client (OID: 1.3.6.1.5.5.7.3.2).
- URL del server SCEP: L'URL NDES pubblicato esternamente.
- Certificato root: Collega al profilo Root attendibile del Passaggio 3.
- Periodo di validità del certificato: Deve corrispondere al modello configurato sulla CA.
Passaggio 5: Distribuisci il profilo WiFi 802.1X
Crea un profilo di configurazione WiFi:
- SSID: Inserisci il nome della rete esattamente come trasmesso dai tuoi punti di accesso.
- Tipo di sicurezza: WPA2-Enterprise o WPA3-Enterprise.
- Tipo di EAP: EAP-TLS.
- Certificato di autenticazione client: Seleziona il profilo del certificato SCEP dal Passaggio 4.
- Convalida del server: Specifica il certificato Root attendibile del Passaggio 3 e inserisci il nome del server RADIUS previsto. Ciò impedisce ai dispositivi di connettersi a punti di accesso non autorizzati che presentano certificati fraudolenti.
Best practice
Imponi un controllo CRL rigoroso sul tuo server RADIUS
La revoca del certificato è il controllo operativo che colma il divario tra la disattivazione di un account e il blocco dell'accesso alla rete. Quando un dispositivo viene smarrito, rubato o un dipendente lascia l'azienda, disabilita l'account AD e revoca il certificato presso la CA. Il tuo server RADIUS deve essere configurato per controllare la CRL a ogni tentativo di autenticazione. Se la CRL non è disponibile, ad esempio perché il CDP (CRL Distribution Point) non è raggiungibile, la maggior parte dei server RADIUS si sblocca per impostazione predefinita in modalità aperta (fail open), il che costituisce un rischio per la sicurezza. Assicurati che i tuoi CDP siano altamente disponibili e che il tuo server RADIUS sia configurato per bloccarsi in modalità chiusa (fail closed) se non è possibile recuperare la CRL.
Per la revoca in tempo reale, configura OCSP (Online Certificate Status Protocol) in aggiunta alla CRL. OCSP fornisce risposte sullo stato del singolo certificato senza richiedere al server RADIUS di scaricare e analizzare l'intera CRL.
Utilizza i certificati di dispositivo per i dispositivi condivisi e IoT
Per i dispositivi condivisi (tablet del servizio di pulizia degli hotel, terminali POS per il retail, lettori per il controllo degli accessi negli stadi) utilizza i certificati di dispositivo anziché quelli utente. I certificati di dispositivo sono legati all'identità della macchina e non a un account utente. Ciò significa che il dispositivo si autentica indipendentemente dall'utente che ha effettuato l'accesso, e la revoca è legata al record del dispositivo piuttosto che all'uscita di un dipendente.
Per le distribuzioni nel settore retail , i certificati di dispositivo sull'hardware POS soddisfano anche i requisiti PCI DSS per l'identità del dispositivo a livello di rete, senza introdurre la complessità delle credenziali utente nel punto vendita.
Automatizza il rinnovo dei certificati
SCEP supporta il rinnovo automatico: l'MDM ordina al dispositivo di registrarsi nuovamente prima della scadenza del certificato. Configura il tuo profilo SCEP per attivare il rinnovo al 20% del periodo di validità rimanente del certificato. Per un certificato di un anno, il rinnovo inizia circa 73 giorni prima della scadenza. Questa finestra temporale offre il tempo sufficiente per risolvere eventuali errori di rinnovo prima che il certificato scada e i dispositivi perdano l'accesso alla rete.
I certificati scaduti che causano errori di autenticazione di massa sono il disservizio operativo più comune nelle distribuzioni 802.1X. Il rinnovo automatizzato tramite SCEP elimina completamente questo rischio.
Segmenta le reti in base agli attributi del certificato
I server RADIUS possono leggere gli attributi dei certificati (Subject, SAN o OID personalizzati) e utilizzarli per assegnare dinamicamente i dispositivi alle VLAN. Un tablet del servizio di pulizia con un certificato emesso dal modello HousekeepingDevices viene inserito nella VLAN del servizio di pulizia. Un terminale POS con un certificato proveniente dal modello RetailPOS finisce nella VLAN inclusa nel perimetro PCI. Questa è una segmentazione della rete applicata crittograficamente, molto più affidabile degli approcci basati su SSID o indirizzi MAC.
Per gli operatori del settore hospitality che gestiscono il Guest WiFi insieme al Staff WiFi sulla stessa infrastruttura fisica, l'assegnazione della VLAN tramite gli attributi del certificato assicura che gli ospiti e lo staff si trovino sempre su segmenti di rete separati, indipendentemente dal SSID a cui si connette un dispositivo.
Risoluzione dei problemi e mitigazione dei rischi
Il profilo WiFi mostra 'Errore' o 'Non applicabile' in Intune
Causa principale: Mancata corrispondenza del gruppo di destinazione. Il profilo SCEP è assegnato a un gruppo diverso rispetto al profilo WiFi. Intune non è in grado di risolvere la dipendenza del certificato.
Soluzione: Controlla tutti e tre i profili (Trusted Root, SCEP, WiFi). Assicurati che siano tutti assegnati esattamente allo stesso gruppo di Azure AD. Se la distribuzione è destinata agli Utenti, tutti e tre i profili devono avere come destinazione un gruppo di Utenti. Se la distribuzione è destinata ai Dispositivi, tutti e tre devono avere come destinazione un gruppo di Dispositivi.
NDES restituisce errori HTTP 403
Causa principale: L'account di servizio di Intune Certificate Connector non dispone delle autorizzazioni di Lettura (Read) o Registrazione (Enroll) sul modello di certificato della CA, oppure il filtro URL del firewall sta bloccando le stringhe di query SCEP.
Soluzione: Verificare che l'account del connettore disponga delle autorizzazioni di Lettura e Registrazione (Read and Enroll) sul modello nella console della CA. Controllare i log del firewall per identificare eventuali richieste bloccate contenenti ?operation=GetCACaps o ?operation=PKIOperation. Queste stringhe di query devono transitare senza alcuna modifica.
I dispositivi non riescono a rinnovare i certificati prima della scadenza
Causa principale: La finestra di rinnovo SCEP è troppo breve oppure il server NDES non è raggiungibile al momento del rinnovo.
Soluzione: Impostare la soglia di rinnovo al 20% della validità del certificato. Assicurarsi che l'URL di NDES sia pubblicato tramite un reverse proxy ad alta disponibilità. Monitorare i log IIS di NDES per rilevare eventuali errori nelle richieste di rinnovo e attivare avvisi proattivi.
RADIUS rifiuta certificati validi
Causa principale: L'archivio delle CA attendibili del server RADIUS non include il certificato della CA emittente, oppure la CRL è obsoleta.
Soluzione: Importare l'intera catena della CA (Root CA + Issuing CA) nell'archivio attendibile del server RADIUS. Verificare che la CRL venga recuperata correttamente e che l'URL CDP sia raggiungibile dal server RADIUS. Controllare la data del prossimo aggiornamento della CRL: se è trascorsa, la CA deve pubblicare una nuova CRL.
Per considerazioni più ampie sulle prestazioni di rete insieme alla sicurezza, consultare la nostra guida alla gestione della larghezza di banda .
ROI e impatto aziendale
Il caso aziendale per la registrazione dei certificati basata su SCEP è immediato. Il WiFi basato su password genera un volume prevedibile di ticket di assistenza: scadenze delle credenziali, blocchi di account, condivisione delle password da parte del personale con gli ospiti e attriti nell'onboarding dei nuovi assunti. L'autenticazione basata su certificati è invisibile per l'utente finale. I dispositivi si connettono automaticamente. Non ci sono password da far scadere, condividere o dimenticare.
Le organizzazioni che passano dal WiFi basato su password a EAP-TLS con SCEP registrano solitamente una riduzione del 70-80% dei ticket di assistenza relativi al WiFi (dati interni Purple, 2024, basati su implementazioni in settori hospitality e retail). Il solo risparmio sul supporto tecnico spesso giustifica i costi di implementazione entro il primo anno.
L'impatto sulla conformità è altrettanto concreto. EAP-TLS soddisfa il requisito 8.6 dello standard PCI DSS 4.0 per l'autenticazione a più fattori a livello di rete. Per gli ambienti del settore sanitario , si allinea con i requisiti di tutela tecnica previsti dal GDPR e dalle normative del settore per l'accesso alle reti wireless. Per le organizzazioni del settore pubblico, supporta i requisiti di certificazione NCSC Cyber Essentials Plus per il controllo dell'accesso alla rete.
Per gli operatori del settore trasporti (concessioni ferroviarie, operatori aeroportuali, reti di autobus), l'autenticazione basata su certificati sui dispositivi del personale garantisce che le reti operative che trasportano dati critici per la sicurezza siano isolate dal WiFi dei passeggeri e protette da attacchi basati sul furto di credenziali.
La piattaforma WiFi Analytics di Purple si integra con le reti protette da 802.1X per fornire insight sui dati di prima parte senza compromettere il livello di sicurezza dell'infrastruttura sottostante. I 29 miliardi di punti dati raccolti attraverso la rete di Purple dimostrano che la sicurezza e l'analisi sono obiettivi complementari, non concorrenti.
Per la gestione dei feedback e dell'esperienza in parallelo alla distribuzione della tua rete sicura, consulta la nostra guida per la raccolta dei feedback nei locali .
Definizioni chiave
SCEP (Simple Certificate Enrollment Protocol)
Un protocollo standardizzato IETF (RFC 8894) che automatizza la registrazione dei certificati X.509 per i dispositivi gestiti. Il dispositivo genera la propria chiave privata localmente e invia solo una Certificate Signing Request alla CA tramite un gateway. La chiave privata non lascia mai il dispositivo.
I team IT incontrano il protocollo SCEP durante la configurazione delle piattaforme MDM (Intune, Jamf) per distribuire i certificati di autenticazione WiFi su scala. Rappresenta il meccanismo consigliato per le distribuzioni 802.1X EAP-TLS poiché la chiave privata è protetta a livello hardware sull'endpoint.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Il metodo di autenticazione 802.1X più sicuro. Sia il dispositivo client che il server RADIUS presentano certificati X.509. Nessuna delle due parti può autenticarsi senza un certificato valido e non revocato proveniente dalla gerarchia CA attendibile.
EAP-TLS è il protocollo di autenticazione di destinazione abilitato dalla distribuzione dei certificati SCEP. Soddisfa il requisito PCI DSS 4.0 8.6 ed è necessario per le distribuzioni WPA3 Enterprise a 192 bit (Suite B).
PKCS (Public Key Cryptography Standards)
Un meccanismo di consegna dei certificati in cui la CA genera centralmente sia la coppia di chiavi pubblica che privata e le trasmette all'endpoint. La CA conserva una copia della chiave privata, consentendo il deposito della chiave.
I team IT scelgono tra SCEP e PKCS quando configurano i profili dei certificati in Intune. PKCS è appropriato per la crittografia delle e-mail S/MIME in cui è richiesto il deposito della chiave (key escrow). Non è consigliato per l'autenticazione WiFi perché la chiave privata viene trasmessa sulla rete.
NDES (Network Device Enrollment Service)
Un ruolo di Microsoft Windows Server che funge da gateway SCEP tra una piattaforma MDM e un'Autorità di Certificazione (CA). Convalida le richieste di registrazione dei dispositivi e inoltra le CSR alla CA.
NDES è un componente infrastrutturale richiesto per le distribuzioni SCEP on-premises con Microsoft Intune. Deve essere pubblicato esternamente tramite un proxy applicativo per consentire la registrazione dei dispositivi remoti. I gateway SCEP cloud rappresentano un'alternativa che elimina la dipendenza da NDES on-premises.
CRL (Certificate Revocation List)
Un elenco pubblicato dalla CA contenente i numeri di serie dei certificati che sono stati revocati prima della loro data di scadenza. I server RADIUS controllano la CRL per garantire che i dispositivi con certificati revocati non possano autenticarsi.
Il controllo della CRL è la misura di controllo operativo che applica la revoca dei certificati. I team IT devono configurare il proprio server RADIUS in modo da controllare la CRL a ogni tentativo di autenticazione e garantire che il CRL Distribution Point (CDP) sia altamente disponibile.
802.1X
Uno standard IEEE per il controllo dell'accesso alla rete basato su porte. Definisce il framework di autenticazione a tre parti (supplicant, authenticator, authentication server) utilizzato nelle reti WiFi aziendali e cablate.
Il protocollo 802.1X è il framework all'interno del quale operano EAP-TLS e SCEP. I team IT lo incontrano quando configurano gli SSID WPA2-Enterprise o WPA3-Enterprise e quando impostano i criteri del server RADIUS.
RADIUS (Remote Authentication Dial-In User Service)
Un protocollo di rete che fornisce autenticazione, autorizzazione e tracciamento (AAA) centralizzati per l'accesso alla rete. Nelle distribuzioni 802.1X, il server RADIUS convalida i certificati client e applica le policy di assegnazione delle VLAN.
Il server RADIUS rappresenta il punto decisionale di autenticazione in ogni distribuzione 802.1X. Le implementazioni più comuni includono Microsoft NPS, FreeRADIUS e Cisco ISE. Deve essere configurato con la catena di CA attendibili e un controllo rigoroso di CRL o OCSP.
CSR (Certificate Signing Request)
Un blocco di testo codificato generato da un dispositivo che contiene la chiave pubblica del dispositivo e le informazioni identificative. Il dispositivo invia la CSR alla CA (tramite il gateway SCEP) per richiedere un certificato firmato. La corrispondente chiave privata viene generata e conservata sul dispositivo.
La CSR è l'elemento fondamentale nel flusso di registrazione SCEP. I team IT configurano il formato della CSR (nome del soggetto, utilizzo della chiave, EKU) nel profilo del certificato SCEP all'interno della propria piattaforma MDM.
PKI (Public Key Infrastructure)
La combinazione di hardware, software, criteri e procedure necessari per creare, gestire, distribuire e revocare certificati digitali. Una PKI aziendale standard è costituita da una CA radice (root) offline e da una CA emittente (issuing) online.
La PKI è il prerequisito per qualsiasi distribuzione EAP-TLS. I team IT devono progettare e distribuire una gerarchia CA a due livelli prima di configurare SCEP. I servizi PKI ospitati nel cloud riducono il carico infrastrutturale per le distribuzioni su parchi dispositivi distribuiti.
VLAN (Virtual Local Area Network)
Un segmento di rete logico che isola il traffico al Livello 2 (Layer 2). Nelle distribuzioni 802.1X, i server RADIUS assegnano dinamicamente i dispositivi alle VLAN in base agli attributi del certificato, all'identità dell'utente o alle policy.
L'assegnazione delle VLAN tramite RADIUS è il meccanismo che applica la segmentazione della rete nei WiFi aziendali. I team IT lo utilizzano per separare i dispositivi POS su VLAN dedicate all'ambito PCI, i dispositivi degli ospiti su VLAN con solo accesso a Internet e i dispositivi del personale su VLAN aziendali, il tutto partendo da una singola infrastruttura fisica.
Esempi pratici
Una struttura Premier Inn da 200 camere deve implementare un WiFi sicuro per 150 dispositivi iOS del personale di servizio. Attualmente, lo staff condivide una password WPA2-Personal con gli ospiti, creando un rischio di conformità e operativo. Il Direttore IT deve eliminare la password condivisa senza interrompere le attività quotidiane.
Il Direttore IT implementa una distribuzione SCEP gestita da Jamf in tre fasi. Fase uno: il certificato Root CA viene inviato a tutti i 150 dispositivi iOS tramite un profilo Jamf Trusted Certificate, destinato al gruppo smart "Housekeeping Devices". Fase due: viene distribuito un profilo di certificato SCEP che indirizza i dispositivi a un server NDES pubblicato tramite Azure AD App Proxy. Il nome del soggetto utilizza CN={{SERIALNUMBER}} per legare il certificato all'hardware del dispositivo. Fase tre: viene inviato un profilo WiFi WPA2-Enterprise, specificando EAP-TLS e collegandolo al certificato SCEP. I dispositivi si autenticano in modo silenzioso. L'SSID con password condivisa viene disattivato. Il server RADIUS è configurato con un controllo CRL rigoroso e l'assegnazione della VLAN: i dispositivi del personale di servizio vengono inseriti nella VLAN 20 (operazioni), i dispositivi degli ospiti nella VLAN 10 (solo internet).
Una catena di vendita al dettaglio con 500 punti vendita deve proteggere il WiFi aziendale per i tablet POS Windows che eseguono software di elaborazione dei pagamenti. La conformità allo standard PCI DSS 4.0 richiede l'autenticazione a più fattori a livello di rete. L'attuale configurazione WPA2-Personal non supera la valutazione del requisito PCI DSS 8.6.
L'architetto di rete distribuisce EAP-TLS tramite Microsoft Intune e SCEP in tutti i 500 punti vendita. La distribuzione utilizza certificati di dispositivo con CN={{AAD_Device_ID}} come nome del soggetto, legando ciascun certificato al record del dispositivo in Intune. La sequenza dei tre profili (Trusted Root, SCEP, WiFi) viene distribuita al gruppo Azure AD "POS Devices", lo stesso gruppo per tutti e tre i profili. Il server RADIUS assegna i dispositivi POS a una VLAN dedicata all'ambito PCI (VLAN 100) in base al modello di emissione del certificato. La CRL viene pubblicata su un endpoint ospitato su CDN ad alta disponibilità con una finestra di validità di quattro ore. OCSP è abilitato per il controllo della revoca in tempo reale. La distribuzione viene convalidata rispetto al requisito PCI DSS 4.0 8.6 da parte del QSA.
Domande di esercitazione
Q1. Hai distribuito i profili certificato Trusted Root e SCEP al gruppo di utenti 'All Staff' in Intune. Successivamente, distribuisci il profilo WiFi al gruppo di dispositivi 'Corporate Devices'. I dispositivi ricevono i certificati ma il profilo WiFi mostra 'Errore' nella console di Intune. Qual è la causa più probabile e come si risolve?
Suggerimento: Considera come Intune risolve le dipendenze tra i profili e cosa succede quando i profili hanno come target tipi di gruppo diversi.
Visualizza risposta modello
La causa principale è una mancata corrispondenza del target di gruppo. Il profilo WiFi dipende dal profilo SCEP, che a sua volta dipende dal profilo Trusted Root. Intune non può risolvere queste dipendenze quando i profili hanno come target tipi di gruppo diversi (Utenti vs Dispositivi). Soluzione: ridistribuire tutti e tre i profili allo stesso gruppo. Se il profilo WiFi ha come target 'Corporate Devices' (un gruppo di dispositivi), anche i profili SCEP e Trusted Root devono avere come target 'Corporate Devices'. In alternativa, sposta tutti e tre in un gruppo di utenti se è richiesta l'autenticazione basata sull'utente.
Q2. Viene segnalato il furto dell'iPad di un addetto alle pulizie dell'hotel. Disabiliti immediatamente l'account Active Directory dell'addetto. La mattina successiva, l'iPad rubato si connette ancora alla rete WPA2-Enterprise dell'hotel. Perché e quali due azioni intraprendi per impedire questo comportamento?
Suggerimento: Pensa a cosa convalida effettivamente il server RADIUS durante l'autenticazione EAP-TLS e quali controlli regolano la validità del certificato.
Visualizza risposta modello
La disattivazione dell'account AD non revoca il certificato client memorizzato sull'iPad. Il server RADIUS convalida il certificato, non lo stato dell'account AD, durante l'autenticazione EAP-TLS. Le due azioni richieste sono: (1) revocare il certificato del dispositivo presso la CA - questo aggiunge il numero di serie del certificato alla CRL; (2) assicurarsi che il server RADIUS sia configurato con un controllo rigoroso della CRL in modo che scarichi la CRL aggiornata e rifiuti il certificato revocato al successivo tentativo di autenticazione. Per una revoca più rapida, configura l'OCSP sul server RADIUS per i controlli dello stato del certificato in tempo reale.
Q3. Una catena di vendita al dettaglio sta distribuendo il WiFi 802.1X in 500 punti vendita POS. L'architetto della sicurezza propone l'uso della consegna dei certificati PKCS anziché SCEP per evitare la distribuzione di un server NDES. Il QSA che esamina la valutazione PCI DSS 4.0 solleva una preoccupazione. Qual è la preoccupazione e qual è la raccomandazione corretta?
Suggerimento: Considera ciò che il PCI DSS stabilisce in merito alla gestione delle chiavi private e ciò che il PKCS fa con la chiave privata durante la consegna.
Visualizza risposta modello
La preoccupazione del QSA è che il PKCS trasmette la chiave privata sulla rete dalla CA al dispositivo. Il requisito 3.5 del PCI DSS 4.0 richiede che le chiavi private utilizzate per l'autenticazione siano protette dalla divulgazione. La trasmissione della chiave privata sulla rete - anche se crittografata - introduce un rischio che il SCEP elimina completamente. La raccomandazione corretta è quella di utilizzare il SCEP, in cui la chiave privata viene generata sul dispositivo POS e non lo lascia mai. Per evitare l'infrastruttura NDES on-premises, l'architetto dovrebbe valutare un servizio gateway SCEP cloud che si integra direttamente con Intune e la CA tramite API.
Q4. Stai progettando una rete WiFi per un grande centro congressi che ospita oltre 50 eventi all'anno. I dispositivi del personale devono essere su una rete protetta 802.1X. Vuoi garantire che, se il dispositivo di un fornitore esterno viene compromesso, possa essere isolato dalla rete entro 15 minuti. Quale meccanismo di revoca dei certificati configuri e perché?
Suggerimento: Confronta CRL e OCSP in termini di latenza di revoca e cosa determina la rapidità con cui un server RADIUS agisce su una revoca.
Visualizza risposta modello
Configura OCSP (Online Certificate Status Protocol) sul server RADIUS. La revoca basata su CRL presenta una latenza determinata dal periodo di validità della CRL, in genere da una a 24 ore, il che significa che un certificato revocato potrebbe comunque autenticarsi fino a quando il server RADIUS non recupera la CRL successiva. L'OCSP fornisce risposte sullo stato dei singoli certificati in tempo reale: quando un certificato viene revocato presso la CA, il risponditore OCSP restituisce immediatamente uno stato di 'revocato' alla query successiva. Con l'OCSP configurato sul server RADIUS, il certificato di un fornitore revocato viene bloccato al successivo tentativo di autenticazione, in genere entro pochi secondi. Assicurati che il risponditore OCSP sia altamente disponibile: se non è raggiungibile e il server RADIUS è configurato per bloccarsi in caso di errore (fail closed), tutte le autenticazioni falliranno.
Continua a leggere questa serie
Come configurare SCEP per la registrazione automatica dei certificati WiFi aziendali
Questa guida spiega come configurare SCEP (Simple Certificate Enrollment Protocol) per la registrazione automatica dei certificati WiFi aziendali, coprendo l'intera architettura, da PKI e NDES fino alla distribuzione dei profili MDM e alla convalida RADIUS. Si rivolge a responsabili IT, architetti di rete e CTO di hotel, catene di vendita al dettaglio, stadi, centri congressi e organizzazioni del settore pubblico che hanno l'esigenza di superare le chiavi precondivise e implementare un'autenticazione 802.1X EAP-TLS scalabile e basata sull'identità. La piattaforma cloud overlay 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.
La guida enterprise a SCEP: implementare il Simple Certificate Enrollment Protocol per la sicurezza automatizzata del WiFi nei campus
Questa guida di riferimento tecnico fornisce un modello architetturale definitivo e una strategia di implementazione passo-passo per la distribuzione dei certificati WiFi aziendali tramite SCEP. Copre le differenze cruciali tra SCEP e PKCS, l'esatta sequenza di implementazione necessaria per il successo e le strategie reali di mitigazione del rischio per i leader IT.
Comprendere Cisco SUDI: Identità del Dispositivo Basata su Hardware nel Controllo dell'Accesso alla Rete
Questa guida descrive in dettaglio l'architettura tecnica di Cisco SUDI, spiegando come l'identità ancorata all'hardware protegga il controllo dell'accesso alla rete. Fornisce passaggi di implementazione pratici per i leader IT per distribuire l'autenticazione 802.1X EAP-TLS e automatizzare il Zero Touch Provisioning in tutte le sedi aziendali.