Come configurare il WiFi Enterprise sui dispositivi Android con EAP-TLS

Come configurare il Wi-Fi aziendale sui dispositivi Android con EAP-TLS Una guida tecnica Purple — Circa 10 minuti --- INTRODUZIONE E CONTESTO — circa 1 minuto Benvenuti alla serie di guide tecniche Purple. Sono il vostro presentatore e oggi entreremo nei dettagli dell'implementazione dell'autenticazione 802.1X EAP-TLS sui dispositivi Android, sia che gestiate un patrimonio alberghiero, una catena di negozi, uno stadio o un campus del settore pubblico. Se siete responsabili di una rete che deve autenticare dispositivi Android aziendali o BYOD senza fare affidamento su password condivise, questa puntata fa al caso vostro. EAP-TLS è il gold standard per la sicurezza Wi-Fi aziendale: utilizza l'autenticazione reciproca basata su certificati, il che significa che non ci sono credenziali da carpire tramite phishing, nessuna password da ruotare e una postura di conformità che soddisfa i requisiti GDPR, PCI DSS, ISO 27001 e la maggior parte dei framework di sicurezza del settore pubblico. Al termine di questa sessione, capirete esattamente come funziona EAP-TLS su Android, quali sono le opzioni di distribuzione e i tre errori più comuni che causano il fallimento dei rollout. Cominciamo. --- APPROFONDIMENTO TECNICO — circa 5 minuti Iniziamo con l'architettura. 802.1X è lo standard IEEE che disciplina il controllo dell'accesso alla rete basato su porte. Quando un dispositivo Android si connette a una rete Wi-Fi aziendale — configurata come WPA2-Enterprise o WPA3-Enterprise — l'access point funge da autenticatore. Non prende direttamente la decisione di autenticazione, ma passa la conversazione tra il dispositivo e un server RADIUS, che è il server di autenticazione vero e proprio. EAP-TLS — ovvero Extensible Authentication Protocol con Transport Layer Security — è il metodo di autenticazione che viene eseguito all'interno del framework 802.1X. Ciò che lo differenzia da EAP-PEAP o EAP-TTLS, che utilizzano nome utente e password all'interno di un tunnel TLS, è che EAP-TLS utilizza certificati X.509 su entrambi i lati. Il server RADIUS presenta un certificato server al dispositivo e il dispositivo presenta un certificato client al server RADIUS. Entrambe le parti si convalidano a vicenda. Questa è l'autenticazione reciproca, ed è ciò che rende EAP-TLS l'opzione più sicura disponibile. Ora, specificamente su Android, ci sono alcune cose da comprendere. Android 11 e versioni successive hanno introdotto requisiti di convalida dei certificati più severi. Se state effettuando la distribuzione su Android 11 o versioni successive — che a questo punto rappresentano la stragrande maggioranza dei vostri dispositivi — il dispositivo rifiuterà di connettersi a meno che il certificato del server RADIUS non sia esplicitamente attendibile. Non potete fare affidamento solo sul trust store di sistema; dovete inviare il certificato CA radice al dispositivo o configurare il profilo Wi-Fi in modo che vi faccia esplicitamente riferimento.Parliamo della catena di certificati. Sono necessari tre componenti prima che un singolo dispositivo Android possa autenticarsi tramite EAP-TLS. Primo, un'Autorità di Certificazione (CA) — la tua PKI interna, Microsoft Active Directory Certificate Services o una PKI cloud come SCEP tramite Intune. Secondo, un certificato server emesso per il tuo server RADIUS, firmato da quella CA. Terzo, un certificato client univoco emesso per ciascun dispositivo o utente, anch'esso firmato dalla stessa CA. Il dispositivo presenta il proprio certificato client durante l'handshake TLS e il server RADIUS lo convalida rispetto all'elenco di revoca dei certificati della CA (CRL) o tramite OCSP (Online Certificate Status Protocol). Per Android, il certificato client e la chiave privata sono in genere confezionati come file PKCS12 — ovvero un file .P12 o .PFX — che contiene sia il certificato sia la chiave privata crittografata. Su un dispositivo configurato manualmente, l'utente importa questo file tramite Impostazioni, poi Sicurezza, quindi Installa un certificato. Su un dispositivo gestito tramite MDM, il certificato viene inviato in modo automatico e invisibile al keystore gestito del dispositivo — senza richiedere alcuna interazione da parte dell'utente. Ora parliamo del profilo WiFi stesso. Quando si configura una connessione WiFi aziendale su Android, è necessario specificare: l'SSID, il tipo di sicurezza — WPA2-Enterprise o WPA3-Enterprise — il metodo EAP — che è TLS — il certificato CA per la convalida del server, il certificato client per l'autenticazione del dispositivo e la stringa d'identità, che in genere è il Common Name del dispositivo o l'UPN dell'utente. Su Android 11 e versioni successive, è inoltre necessario specificare la corrispondenza del suffisso del dominio o il soggetto del certificato del server per prevenire attacchi man-in-the-middle. Per le distribuzioni MDM — ed è qui che entra in gioco la vera scalabilità — si invia tutto questo come profilo di configurazione strutturato. In Microsoft Intune, si crea un profilo di certificato SCEP che richiede e installa automaticamente un certificato client univoco su ciascun dispositivo Android registrato. Successivamente, si crea un profilo di configurazione WiFi che fa riferimento a quel profilo di certificato. Quando il dispositivo si connette per il check-in, riceve sia il certificato sia il profilo WiFi e si connette automaticamente alla rete 802.1X. Nessuna interazione da parte dell'utente, nessuna chiamata al supporto tecnico. Se si utilizza Intune per questo scopo, la nostra guida complementare su come utilizzare Microsoft Intune per inviare certificati WiFi ai dispositivi illustra i passaggi esatti di configurazione — si consiglia di leggerla insieme a questa panoramica. Per VMware Workspace ONE e Jamf Connect, il processo è identico dal punto di vista dell'architettura — profilo di certificato SCEP o PKCS, seguito da un profilo WiFi che vi fa riferimento. L'interfaccia utente specifica varia, ma i requisiti della catena di certificati e della configurazione RADIUS sono gli stessi. Un aspetto importante da segnalare sul lato RADIUS: se si utilizza FreeRADIUS, Microsoft NPS o Cisco ISE, assicurarsi che il certificato del server includa gli attributi corretti di Extended Key Usage (EKU) — nello specifico, Autenticazione Server, OID 1.3.6.1.5.5.7.3.1. Android è molto rigido su questo aspetto. Un certificato che funziona perfettamente con i client Windows potrebbe non funzionare su Android se l'EKU manca o è configurato in modo errato. --- RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE COMUNI — circa 2 minuti Bene, parliamo di ciò che va effettivamente storto sul campo, perché è qui che la maggior parte delle implementazioni incontra difficoltà. Il primo e più comune errore riguarda l'affidabilità del certificato. Android 11 e versioni successive non si connetteranno se la catena di certificati del server RADIUS non può essere convalidata. La soluzione è semplice: distribuire il certificato della CA radice nell'archivio dei certificati utente del dispositivo tramite MDM e farvi riferimento esplicitamente nel campo del certificato CA del profilo WiFi. Non lasciare questa opzione su "Non convalidare" — rappresenta una falla di sicurezza e fallirà comunque su alcune versioni di Android. La seconda trappola è la scadenza del certificato. I certificati client hanno in genere un periodo di validità da uno a due anni. Se non si dispone di un rinnovo automatico tramite SCEP o NDES, ci si sveglierà una mattina scoprendo che metà della flotta di dispositivi ha perso l'accesso al WiFi contemporaneamente. Integrate l'automazione del rinnovo dei certificati nel flusso di lavoro MDM fin dal primo giorno, non come ripensamento. Il terzo problema è la capacità del server RADIUS. Gli handshake EAP-TLS sono computazionalmente più onerosi rispetto agli handshake PEAP a causa del completo scambio reciproco di certificati. In uno stadio o in un centro congressi con migliaia di autenticazioni simultanee, un server RADIUS sottodimensionato diventerà un collo di bottiglia. Dimensionate l'infrastruttura RADIUS per i picchi di autenticazioni simultanee, non per il carico medio. Infine, sul lato Android, tenete presente che diversi produttori — Samsung, Google, Xiaomi — presentano implementazioni leggermente diverse dell'API di configurazione WiFi. Testate i profili distribuiti tramite MDM su dispositivi rappresentativi di ciascun produttore della vostra flotta prima di procedere con la distribuzione su larga scala. I dispositivi Samsung, in particolare, storicamente richiedono che il campo dell'identità sia impostato esplicitamente, anche quando può essere dedotto dal certificato. --- DOMANDE E RISPOSTE RAPIDE — circa 1 minuto Alcune domande rapide che mi vengono poste regolarmente. Posso usare EAP-TLS per i dispositivi BYOD? Sì, ma richiede che l'utente installi un certificato client sul proprio dispositivo personale. Per il BYOD su larga scala, valutate se EAP-TTLS con PAP o PEAP-MSCHAPv2 rappresenti un compromesso più pratico, riservando EAP-TLS ai dispositivi aziendali. EAP-TLS funziona con WPA3-Enterprise? Sì, e WPA3-Enterprise con modalità a 192 bit richiede obbligatoriamente EAP-TLS. Se state distribuendo WPA3-Enterprise in ambienti ad alta sicurezza, EAP-TLS è l'unica opzione conforme. Qual è la versione minima di Android che dovrei considerare come target? Android 8 e versioni successive supportano EAP-TLS in modo nativo. Per Android 11 e versioni successive, applica la convalida esplicita del certificato CA. Per Android 13 e versioni successive, puoi sfruttare le API di gestione dei certificati migliorate per un controllo più granulare. La piattaforma di Purple può integrarsi con le reti EAP-TLS? La piattaforma guest WiFi e analytics di Purple opera su un SSID separato rispetto alla tua rete aziendale 802.1X. I tuoi dispositivi aziendali si autenticano tramite EAP-TLS sull'SSID sicuro, mentre i dispositivi guest utilizzano il captive portal di Purple sull'SSID guest. I due coesistono sulla stessa infrastruttura di access point, con la separazione VLAN che funge da confine di sicurezza. --- RIEPILOGO E PROSSIMI PASSI — circa 1 minuto Per riassumere: l'EAP-TLS su Android è il metodo di autenticazione WiFi aziendale più sicuro disponibile e, con i moderni strumenti MDM, è assolutamente pratico da distribuire su larga scala. I tre aspetti fondamentali da definire correttamente sono: una PKI configurata correttamente con rinnovo automatico dei certificati, un trust esplicito dei certificati CA su Android 11 e versioni successive e un'infrastruttura RADIUS dimensionata per i carichi di picco. Se stai implementando la soluzione in una sede con traffico misto aziendale e guest, la piattaforma di Purple ti offre il layer di analytics e di engagement sulla rete guest, mentre la tua infrastruttura EAP-TLS protegge il lato aziendale. Le due soluzioni si completano a vicenda perfettamente. Per i prossimi passi: esamina il nostro diagramma di architettura nella guida completa, segui la procedura guidata di distribuzione di Intune ed esegui un pilot su un sottoinsieme di dispositivi prima di estendere la distribuzione a tutta l'azienda. Inizia con un gruppo controllato di cinquanta dispositivi, valida la consegna dei certificati e la connettività WiFi, quindi scala con sicurezza. Grazie per aver ascoltato il Purple Technical Briefing. Troverai la guida scritta completa, i diagrammi e i riferimenti di configurazione su purple.ai. Alla prossima.