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

Benvenuti a questo briefing tecnico di Purple. Sono il vostro ospite e oggi approfondiremo la configurazione di SCEP per il provisioning sicuro di WiFi aziendali e BYOD. Per i responsabili IT, i network architect e i CTO che operano nei settori dell'ospitalità, del retail e pubblico, la gestione dell'accesso alla rete è un costante bilanciamento 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 non sono semplicemente più all'altezza. Affidarsi a chiavi precondivise, o PSK, per il WiFi del personale e dei dispositivi BYOD è una vulnerabilità di sicurezza pronta a 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. Gli smartphone moderni utilizzano per impostazione predefinita indirizzi MAC casuali, il che compromette completamente il funzionamento del MAB, senza contare che 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 sia verificato crittograficamente prima di accedere alla rete. Ma la sfida è questa: come distribuire certificati client univoci a migliaia di dispositivi non gestiti senza sovraccaricare l'helpdesk? La risposta è il Simple Certificate Enrollment Protocol, o SCEP. Partiamo dall'architettura. SCEP è lo standard di settore per la registrazione dei dispositivi aziendali, definito nella RFC 8894. Esiste dal 1999, originariamente creato da VeriSign, e ha superato la prova del tempo perché risolve in modo elegante un problema decisamente 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 Enrollment Service, noto come NDES, alla 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 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 sulla rete. Questo è ciò che rende SCEP di gran lunga superiore ad alternative come PKCS per l'autenticazione di rete, in cui la CA genera la coppia di chiavi a livello centrale e la trasmette al dispositivo. Ora parliamo di BYOD. È qui che la questione diventa davvero interessante dal punto di vista operativo. Desiderate che il personale possa utilizzare i propri dispositivi personali per accedere agli strumenti interni, ma non volete costringerli a registrarsi nel vostro MDM aziendale. Si tratta di un problema di privacy che incontra una forte resistenza da parte dei dipendenti. 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 è un walled garden, che limita l'accesso a tutto tranne che al portale di onboarding e al tuo identity provider. L'utente si autentica utilizzando le proprie credenziali aziendali, in genere tramite integrazione SAML con Microsoft Entra ID, Okta o Google Workspace. Una volta completata con successo l'autenticazione, il sistema genera un certificato client univoco e specifico per il dispositivo tramite SCEP. Un profilo di configurazione viene inviato al dispositivo contenente il certificato, il certificato CA radice e le impostazioni di rete. Il dispositivo si connette quindi automaticamente al SSID aziendale sicuro utilizzando EAP-TLS. È un processo fluido per l'utente e sicuro per l'azienda. Non hanno bisogno di sapere nulla di certificati o 802.1X. Devono solo accedere una volta e sono connessi. Ora, esaminiamo l'implementazione nel dettaglio. La sequenza di implementazione è fondamentale, e sbagliarla è la causa più comune di fallimento. Fase uno: distribuire il Certificato Radice Attendibile. Prima che un dispositivo possa richiedere un certificato client o considerare attendibile il server RADIUS, deve considerare attendibile l'Autorità di Certificazione emittente. Esporta il certificato della CA radice come file .cer e distribuiscilo ai gruppi di dispositivi di destinazione. Questo passaggio non è negoziabile. Senza di esso, l'intera catena fallisce. Fase due: configurare il Profilo del Certificato SCEP. Questo indica ai dispositivi come ottenere il proprio certificato client. È necessario configurare il formato del nome del soggetto. Per l'autenticazione gestita dall'utente, lo standard è CN uguale a UserPrincipalName. Per l'autenticazione del dispositivo, usa CN uguale all'ID dispositivo di Azure AD. Imposta l'utilizzo della chiave su firma digitale e cifratura della chiave. In utilizzo avanzato della chiave, specifica Autenticazione Client con l'OID 1.3.6.1.5.5.7.3.2. Collega questo profilo al profilo del certificato Radice 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 viene 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 Radice Attendibile per la convalida del server. Questa sequenza è la cosa più importante da ricordare di tutta questa sessione. Attendibilità, poi certificato, poi WiFi. In questo ordine, ogni volta. Ora lascia che ti illustri 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 eseguire il provisioning dei certificati prima del loro arrivo in sede. Ma esporre un server interno direttamente a Internet rappresenta un rischio significativo per la sicurezza. Application Proxy ti offre un accesso remoto sicuro senza aprire porte in entrata nel firewall. In secondo luogo, implementare certificati a breve durata per i dispositivi BYOD. Invece di un certificato valido per tre anni, emettere certificati validi per 90 giorni. Alla scadenza del certificato, l'utente deve autenticarsi nuovamente tramite il portale di onboarding. Questo elimina naturalmente i dispositivi obsoleti 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, configurare il 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 WiFi se il suo certificato client rimane valido. Il server RADIUS deve controllare la CRL prima di concedere l'accesso. Assicurarsi che i CRL Distribution Points siano altamente disponibili. Se il server RADIUS non riesce a raggiungere la CRL, l'autenticazione fallisce per tutti. Questo si traduce in 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, si tratta di un disallineamento 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. Verificare le assegnazioni. Assicurarsi che tutti e tre i profili si rivolgano esattamente allo stesso gruppo. Il secondo problema comune riguarda 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, oppure da un firewall che blocca i parametri specifici della stringa di query utilizzati da SCEP. Verificare che l'account del connettore disponga delle autorizzazioni di Lettura e Registrazione sul modello CA. Controllare i log del firewall per assicurarsi che gli URL contenenti il parametro operation equals GetCACaps non vengano bloccati. Permettetemi di presentarvi due scenari reali per illustrare come questo si traduce in pratica. Scenario uno: un hotel di 200 camere con 50 addetti alle pulizie che utilizzano smartphone personali per accedere all'app di pianificazione. Il responsabile IT vuole evitare la registrazione completa all'MDM 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 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 Staff WiFi utilizzando EAP-TLS. Il server RADIUS assegna questi dispositivi a una VLAN limitata che consente l'accesso solo all'app di pianificazione. Quando un membro del personale si dimette, il suo account Entra ID viene disattivato e il server RADIUS nega istantaneamente l'accesso alla rete. Scenario due: una catena di vendita al dettaglio nazionale con 500 negozi che distribuisce un WiFi sicuro per i tablet aziendali dedicati ai punti vendita. L'architetto di rete deve garantire che, anche in caso di furto di un tablet, non sia possibile estrarre le credenziali. 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 hardware secure enclave. Il tablet invia una CSR al server NDES, riceve il certificato client e si connette all'SSID Retail POS utilizzando EAP-TLS. Poiché la chiave privata viene generata localmente e non viene mai trasmessa, le credenziali di un tablet rubato non possono essere utilizzate altrove. Ciò soddisfa i requisiti di conformità PCI DSS. Parliamo ora del caso aziendale. Il passaggio 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 assistenza. Scadenze delle password, blocchi, errori di battitura. L'autenticazione basata su certificati è invisibile all'utente. I dispositivi si connettono automaticamente. Questo 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à al PCI DSS negli ambienti di vendita al dettaglio e al GDPR in tutti i settori. Il costo di una violazione dei dati supera di gran lunga il costo della distribuzione di un'infrastruttura PKI adeguata. 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 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. Vorrei concludere con una sintesi rapida 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 devono essere validi i certificati? 90 giorni per il 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 dell'accesso dell'utente. Utilizzate il targeting per utente per il BYOD, dove il certificato deve essere legato al singolo individuo. Come gestire la frammentazione di Android? Utilizzate Passpoint, noto anche come Hotspot 2.0, dove possibile. Offre un'esperienza di connessione coerente tra i vari produttori Android. E infine, qual è l'aspetto più importante da gestire correttamente? Il controllo CRL sul server RADIUS. Senza di esso, un certificato revocato può comunque concedere 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 dei certificati EAP-TLS sono disponibili sul sito web di Purple all'indirizzo purple.ai. Grazie per l'ascolto.