Come configurare SCEP per il WiFi aziendale sicuro e il provisioning BYOD

Benvenuto in questo briefing tecnico di Purple. Sono il tuo host e oggi approfondiremo la configurazione di SCEP per il provisioning sicuro del WiFi aziendale e del BYOD. Per i responsabili IT, gli architetti di rete e i CTO che operano nei settori dell'ospitalità, del retail e della pubblica amministrazione, la gestione dell'accesso alla rete è un costante gioco di equilibrio tra sicurezza ed efficienza operativa. Vi trovate a gestire centinaia, a volte migliaia di dispositivi che si connettono alla vostra rete ogni giorno. Smartphone del personale, laptop di collaboratori esterni, tablet per i punti vendita. E i vecchi metodi per gestire tutto questo semplicemente non sono più all'altezza. Affidarsi a chiavi precondivise, o PSK, per il WiFi del personale e dei dispositivi BYOD rappresenta una vulnerabilità di sicurezza pronta per essere sfruttata. Una password condivisa, una volta compromessa, consente a chiunque di accedere alla rete. E il MAC Authentication Bypass, o MAB, non è da meno. I moderni smartphone utilizzano di default indirizzi MAC casuali, il che compromette completamente il funzionamento del MAB, e gli indirizzi MAC possono essere contraffatti in pochi secondi. La moderna architettura di rete richiede l'autenticazione 802.1X tramite EAP-TLS. Questo garantisce che ogni dispositivo venga verificato crittograficamente prima di accedere alla rete. Ma la sfida è questa: come distribuire certificati client unici a migliaia di dispositivi non gestiti senza sovraccaricare l'helpdesk? La risposta è il Simple Certificate Enrolment Protocol, o SCEP. Iniziamo con l'architettura. Lo SCEP è lo standard di settore per la registrazione dei dispositivi aziendali, definito nella specifica RFC 8894. Esiste dal 1999, originariamente creato da VeriSign, ed è sopravvissuto alla prova del tempo perché risolve in modo elegante un problema oggettivamente complesso. In un flusso di lavoro SCEP, il dispositivo genera localmente la propria coppia di chiavi privata e pubblica. Crea una richiesta di firma del certificato, o CSR, e la invia tramite un Network Device Enrolment Service, noto come NDES, alla tua Certificate Authority, o CA. La CA convalida la richiesta e restituisce il certificato pubblico firmato al dispositivo. Il vantaggio cruciale in termini di sicurezza è che la chiave privata non lascia mai il dispositivo. Viene generata localmente e memorizzata nell'enclave sicura dell'hardware del dispositivo. Su un laptop Windows, si tratta del Trusted Platform Module, o TPM. Su un iPhone, è il Secure Enclave. La chiave privata non viene mai trasmessa in rete. Questo è ciò che rende lo SCEP estremamente superiore ad alternative come il PKCS per l'autenticazione di rete, in cui la CA genera la coppia di chiavi centralmente e la trasmette al dispositivo. Ora parliamo di BYOD. È qui che le cose si fanno davvero interessanti da un punto di vista operativo. Desideri che il personale sia in grado di utilizzare i propri dispositivi personali per accedere agli strumenti interni, ma non vuoi costringerli a registrarsi nel tuo MDM aziendale. Si tratta di un problema di privacy che incontra una forte resistenza da parte del personale.La soluzione è un portale di onboarding self-service. Ecco come funziona. L'utente connette il proprio dispositivo personale a un SSID di provisioning dedicato. Questa rete è una "walled garden", che limita l'accesso a tutto tranne che al portale di onboarding e al provider di identità. L'utente si autentica utilizzando le proprie credenziali aziendali, solitamente tramite integrazione SAML con Microsoft Entra ID, Okta o Google Workspace. Una volta completata l'autenticazione, il sistema genera un certificato client unico e specifico per il dispositivo tramite SCEP. Al dispositivo viene inviato un profilo di configurazione contenente il certificato, il certificato CA root e le impostazioni di rete. Il dispositivo si connette quindi automaticamente al SSID aziendale sicuro utilizzando EAP-TLS. Il processo è fluido per l'utente e sicuro per l'azienda. Gli utenti non devono sapere nulla di certificati o 802.1X. Devono solo accedere una volta e sono connessi. Ora, esaminiamo l'implementazione in dettaglio. La sequenza di distribuzione è fondamentale e l'errore in questa fase è la causa più comune di fallimento. Fase uno: distribuire il Certificato Root Attendibile. Prima che qualsiasi dispositivo possa richiedere un certificato client o considerare attendibile il server RADIUS, deve considerare attendibile l'Autorità di Certificazione emittente. Esporta il certificato CA Root come file .cer e distribuiscilo ai gruppi di dispositivi di destinazione. Questa fase non è negoziabile. Senza di essa, l'intera catena fallisce. Fase due: configurare il Profilo del Certificato SCEP. Questo indica ai dispositivi come ottenere il loro certificato client. È necessario configurare il formato del nome del soggetto. Per l'autenticazione guidata dall'utente, lo standard è CN uguale a UserPrincipalName. Per l'autenticazione del dispositivo, usa CN uguale all'ID dispositivo Azure AD. Imposta l'utilizzo della chiave su firma digitale e crittografia della chiave. In utilizzo esteso della chiave, specifica Autenticazione Client con l'OID 1.3.6.1.5.5.7.3.2. Collega questo profilo al profilo del certificato Root Attendibile della fase uno. E fornisci l'URL esterno del tuo server NDES. Fase tre: distribuire il Profilo WiFi 802.1X. Questo collega i certificati al SSID di rete. Inserisci il nome della rete esattamente come trasmesso dai tuoi punti di accesso. Imposta il tipo di sicurezza su WPA2-Enterprise o WPA3-Enterprise. Imposta il tipo EAP su EAP-TLS. Seleziona il profilo del certificato SCEP come certificato di autenticazione client. E specifica il certificato Root Attendibile per la convalida del server. Questa sequenza è la cosa più importante da ricordare di tutta questa sessione. Trust, poi certificato, poi WiFi. In questo ordine, ogni volta. Ora ti illustrerò alcune best practice che ti eviteranno notevoli problemi in produzione. In primo luogo, pubblica il tuo server NDES tramite Azure AD Application Proxy. Il server NDES deve essere accessibile da Internet per consentire ai dispositivi remoti di configurare i certificati prima del loro arrivo in sede. Tuttavia, esporre direttamente un server interno a Internet rappresenta un rischio significativo per la sicurezza. Application Proxy offre un accesso remoto sicuro senza aprire porte firewall in entrata. In secondo luogo, implementa certificati a breve termine per i dispositivi BYOD. Invece di un certificato valido per tre anni, emetti certificati validi per 90 giorni. Alla scadenza del certificato, l'utente deve autenticarsi nuovamente tramite il portale di onboarding. Questo elimina naturalmente i dispositivi inattivi dalla rete. Un dispositivo che non è stato utilizzato per 90 giorni viene semplicemente rimosso. Nessuna pulizia manuale richiesta. In terzo luogo, e questo è assolutamente fondamentale, configura il tuo server RADIUS per applicare un controllo rigoroso della Certificate Revocation List. Quando un dipendente lascia l'organizzazione, la disattivazione del suo account Active Directory potrebbe non revocare immediatamente il suo accesso alla WiFi se il suo certificato client rimane valido. Il tuo server RADIUS deve controllare la CRL prima di concedere l'accesso. Assicurati che i tuoi CRL Distribution Points siano altamente disponibili. Se il server RADIUS non riesce a raggiungere la CRL, l'autenticazione fallisce per tutti. Si tratterebbe di un disservizio diffuso. Esaminiamo ora alcune delle modalità di guasto più comuni e come evitarle. Il problema più frequente è la mancata applicazione del profilo WiFi. Il dispositivo riceve i certificati Trusted Root e SCEP, ma il profilo WiFi viene visualizzato come Errore nella console MDM. Nove volte su dieci, ciò è dovuto a un errore di corrispondenza nel targeting dei gruppi. Se il profilo SCEP è assegnato a un Gruppo Utenti, ma il profilo WiFi è assegnato a un Gruppo Dispositivi, l'MDM non può risolvere la dipendenza. Controlla le tue assegnazioni. Assicurati che tutti e tre i profili abbiano come target lo stesso identico gruppo. Il secondo problema comune sono gli errori NDES 403 Forbidden. I dispositivi non riescono a recuperare il certificato SCEP e i log IIS di NDES mostrano errori HTTP 403. Questo è solitamente causato dal fatto che l'account del servizio connettore non dispone delle autorizzazioni necessarie sul modello di certificato, o da un firewall che blocca i parametri specifici della stringa di query utilizzati da SCEP. Verifica che l'account del connettore disponga delle autorizzazioni di Lettura e Registrazione sul modello CA. Controlla i log del firewall per assicurarti che gli URL contenenti il parametro operation equals GetCACaps non vengano bloccati. Permettimi di presentarti due scenari reali per illustrare come funziona in pratica. Scenario uno: un hotel di 200 camere con 50 addetti alle pulizie che utilizzano smartphone personali per accedere all'applicazione di pianificazione. Il responsabile IT vuole evitare la registrazione MDM completa per rispettare la privacy del personale. La soluzione è un portale self-service integrato con Microsoft Entra ID. Il personale si connette all'SSID di provisioning, effettua l'accesso con le proprie credenziali Microsoft Entra ID e scarica un profilo SCEP. Il server SCEP emette un certificato client di 30 giorni direttamente sul dispositivo. Il dispositivo si connette all'SSID della WiFi del personale utilizzando EAP-TLS. Il server RADIUS assegna questi dispositivi a una VLAN limitata che consente solo l'accesso all'applicazione di pianificazione. Quando un membro del personale si dimette, il suo account Microsoft Entra ID viene disattivato e il server RADIUS nega istantaneamente l'accesso alla rete. Scenario due: una catena retail nazionale con 500 negozi che implementa un WiFi sicuro per i tablet dei punti vendita di proprietà aziendale. L'architetto di rete deve garantire che, anche in caso di furto di un tablet, le credenziali non possano essere estratte. La soluzione è Microsoft Intune che distribuisce i certificati tramite SCEP. Intune distribuisce il certificato Trusted Root, seguito da un profilo SCEP che indica al tablet di generare la propria chiave privata nel suo enclave sicuro hardware. Il tablet invia un CSR al server NDES, riceve il certificato client e si connette al SSID Retail POS utilizzando EAP-TLS. Poiché la chiave privata viene generata localmente e mai trasmessa, le credenziali di un tablet rubato non possono essere utilizzate altrove. Questo soddisfa i requisiti di conformità PCI-DSS. Ora parliamo del caso aziendale. La transizione alla distribuzione dei certificati SCEP 802.1X offre ritorni misurabili in termini di sicurezza e operazioni. Il WiFi basato su password genera un volume significativo di ticket di helpdesk - scadenze delle password, blocchi, errori di battitura. L'autenticazione basata su certificati è invisibile all'utente. I dispositivi si connettono automaticamente. Ciò riduce tipicamente il volume dell'helpdesk relativo al WiFi del 70%. Si tratta di una riduzione materiale dei costi operativi. EAP-TLS elimina il rischio di raccolta delle credenziali e di attacchi Man-in-the-Middle. Questo è fondamentale per la conformità con PCI-DSS negli ambienti retail e GDPR in tutti i settori. Il costo di una violazione dei dati supera di gran lunga il costo dell'implementazione di un'adeguata infrastruttura PKI. E per le organizzazioni che già utilizzano la piattaforma di Guest WiFi e analytics di Purple, l'estensione dell'onboarding sicuro ai dispositivi BYOD del personale offre una strategia di gestione della rete unificata. L'overlay cloud indipendente dall'hardware di Purple si integra con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet, in modo da non essere vincolati a un singolo fornitore di hardware. Purple opera in 80.000 sedi attive e ha elaborato 440 milioni di accessi nel 2024, possedendo le certificazioni ISO 27001, GDPR, CCPA e Cyber Essentials. Permettetemi di concludere con un rapido riepilogo delle decisioni chiave che dovete prendere. Dovreste usare SCEP o PKCS? Utilizzate SCEP per l'autenticazione WiFi. La chiave privata rimane sul dispositivo. Utilizzate PKCS solo per la crittografia delle e-mail in cui è richiesto il deposito delle chiavi. Quanto tempo devono essere validi i certificati? 90 giorni per i BYOD. Da uno a due anni per i dispositivi gestiti dall'azienda. Dovreste utilizzare il targeting per utente o per dispositivo nel vostro MDM? Utilizzate il targeting per dispositivo per i dispositivi aziendali che devono connettersi prima del login dell'utente. Utilizzate il targeting per utente per i BYOD in cui il certificato deve essere legato al singolo individuo. Come gestite la frammentazione di Android? Utilizzate Passpoint, noto anche come Hotspot 2.0, ove possibile. Offre un'esperienza di connessione coerente tra i vari produttori di Android. E infine, qual è l'unica cosa più importante da fare bene? Il controllo CRL sul vostro server RADIUS. Senza di esso, un certificato revocato può comunque garantire l'accesso alla rete. Con questo si conclude il briefing di oggi. Se desideri approfondire uno di questi argomenti, le guide tecniche di Purple sulla sicurezza WiFi aziendale e sull'autenticazione tramite certificati EAP-TLS sono disponibili sul sito web di Purple all'indirizzo purple.ai. Grazie per l'ascolto.