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

Come configurare il WiFi Enterprise su dispositivi Android con EAP-TLS Un briefing tecnico di Purple - Circa 10 minuti - - - INTRODUZIONE E CONTESTO - circa 1 minuto Benvenuti alla serie di briefing tecnici di Purple. Sono il vostro ospite e oggi esamineremo i dettagli dell'implementazione dell'autenticazione 802.1X EAP-TLS sui dispositivi Android, sia che stiate gestendo un hotel, una catena retail, 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, questo episodio è per voi. EAP-TLS è il gold standard per la sicurezza WiFi aziendale - utilizza un'autenticazione reciproca basata su certificati, il che significa nessuna credenziale da hackerare con phishing, nessuna password da ruotare e un livello di conformità che soddisfa PCI-DSS, ISO 27001 e la maggior parte dei framework di sicurezza del settore pubblico. Al termine di questo briefing, capirete esattamente come funziona EAP-TLS su Android, quali sono le opzioni di implementazione e i tre errori più comuni che causano il fallimento dei rollout. Iniziamo. - - - APPROFONDIMENTO TECNICO - circa 5 minuti Iniziamo con l'architettura. 802.1X è lo standard IEEE che governa il controllo dell'accesso alla rete basato su porta. Quando un dispositivo Android si connette a una rete WiFi aziendale - configurata come WPA2-Enterprise o WPA3-Enterprise - l'access point agisce come quello che viene chiamato autenticatore. Non prende autonomamente la decisione di autenticazione; trasmette la conversazione tra il dispositivo e un server RADIUS, che è l'effettivo server di autenticazione. EAP-TLS - ovvero Extensible Authentication Protocol con Transport Layer Security - è il metodo di autenticazione in esecuzione all'interno di quel framework 802.1X. Ciò che lo differenzia da 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, nello specifico di Android, ci sono alcune cose da comprendere. Android 11 e versioni successive hanno introdotto requisiti di convalida del certificato più severi. Se state effettuando l'implementazione su Android 11 o versioni successive - che a questo punto rappresenta la stragrande maggioranza dei vostri dispositivi - il dispositivo si rifiuterà di connettersi a meno che il certificato del server RADIUS non sia esplicitamente attendibile. Non potete fare affidamento solo sul keystore di sistema; dovete inviare il certificato CA radice al dispositivo o configurare il profilo WiFi per fare esplicito riferimento ad esso.Parliamo della catena di certificati. Sono necessari tre componenti prima che un singolo dispositivo Android possa autenticarsi tramite EAP-TLS. In primo luogo, una Certificate Authority - la vostra PKI interna, i servizi Microsoft Active Directory Certificate Services o una PKI in cloud come SCEP tramite Intune. In secondo luogo, un certificato server emesso per il server RADIUS, firmato da quella CA. In terzo luogo, un certificato client unico 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, o CRL, o tramite OCSP - Online Certificate Status Protocol. Per Android, il certificato client e la chiave privata sono in genere confezionati come file PKCS12 - si tratta di 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 da MDM, il certificato viene inviato silenziosamente 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 - ovvero TLS - il certificato della 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 implementazioni 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 effettua 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. Se utilizzate 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 - vi consigliamo di leggerla insieme a questo briefing. Per VMware Workspace ONE e Jamf Connect, il processo è identico dal punto di vista architetturale - profilo di certificato SCEP o PKCS, seguito da un profilo WiFi che lo referenzia. L'interfaccia utente specifica differisce, ma la catena di certificati e i requisiti di configurazione RADIUS sono gli stessi. Un aspetto importante da segnalare per quanto riguarda il lato RADIUS: se si utilizza FreeRADIUS, Microsoft NPS o Cisco ISE, assicurarsi che il certificato del server includa gli attributi Extended Key Usage corretti - nello specifico, Server Authentication, OID 1.3.6.1.5.5.7.3.1. Android è molto rigido su questo punto. 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 distribuzioni incontra problemi. Il primo e più comune errore riguarda la fiducia nel 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 esplicito riferimento nel campo del certificato CA del profilo WiFi. Non lasciare questa opzione su "Non convalidare" - si tratta di una falla di sicurezza che in ogni caso non funzionerà su alcune versioni di Android. La seconda trappola è la scadenza dei certificati. 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 contemporaneamente l'accesso WiFi. Integrare l'automazione del rinnovo dei certificati nel flusso di lavoro MDM fin dal primo giorno, non come un ripensamento tardivo. Il terzo problema è la capacità del server RADIUS. Gli handshake EAP-TLS sono computazionalmente più costosi degli handshake PEAP a causa dello scambio reciproco completo dei certificati. In uno stadio o in un centro congressi con migliaia di autenticazioni simultanee, un server RADIUS sottodimensionato diventerà un collo di bottiglia. Dimensionare l'infrastruttura RADIUS per i picchi di autenticazioni simultanee, non per il carico medio. Infine, sul lato Android, è importante essere consapevoli che diversi produttori - Samsung, Google, Xiaomi - presentano implementazioni leggermente diverse delle API di configurazione WiFi. Testare i profili inviati tramite MDM su dispositivi rappresentativi di ciascun produttore presenti nella propria flotta prima di procedere con la distribuzione su larga scala. I dispositivi Samsung in particolare hanno storicamente richiesto che il campo dell'identità fosse impostato in modo esplicito, anche quando poteva essere dedotto dal certificato. --- DOMANDE E RISPOSTE RAPIDE - circa 1 minuto Alcune brevi domande 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, valutare se EAP-TTLS con PAP o PEAP-MSCHAPv2 rappresenti un compromesso più pratico, riservando EAP-TLS ai dispositivi di proprietà aziendale. EAP-TLS funziona con WPA3-Enterprise? Sì, e WPA3-Enterprise in modalità a 192 bit richiede obbligatoriamente EAP-TLS. Se si distribuisce WPA3-Enterprise in ambienti ad alta sicurezza, EAP-TLS è l'unica opzione conforme. Qual è la versione minima di Android che dovrei supportare? Android 8 e versioni successive supportano nativamente EAP-TLS. 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 di analisi e guest WiFi di Purple opera su un SSID separato rispetto alla rete aziendale 802.1X. I tuoi dispositivi aziendali si autenticano tramite EAP-TLS sull'SSID sicuro, mentre i dispositivi degli ospiti utilizzano il captive portal di Purple sull'SSID guest. I due coesistono sulla stessa infrastruttura di access point, con la separazione VLAN a fornire il limite di sicurezza. - RIASSUNTO 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 implementare su scala. I tre aspetti da gestire correttamente sono: una PKI configurata correttamente con rinnovo automatico dei certificati, l'attendibilità esplicita del certificato CA su Android 11 e versioni successive e un'infrastruttura RADIUS dimensionata per il carico di picco. Se stai effettuando l'implementazione in una sede con traffico misto aziendale e guest, la piattaforma di Purple ti offre il livello di analisi e di engagement sulla rete guest, mentre la tua infrastruttura EAP-TLS protegge il lato aziendale. Le due soluzioni si completano a vicenda. Per i tuoi prossimi passi: esamina il nostro diagramma dell'architettura nella guida completa, segui la procedura dettagliata di implementazione di Intune ed esegui un progetto pilota su un sottoinsieme di dispositivi prima di estenderlo a tutto il tuo parco macchine. Inizia con un gruppo controllato di cinquanta dispositivi, convalida la distribuzione dei certificati e la connettività WiFi, quindi scala con sicurezza. Grazie per aver ascoltato il Technical Briefing di Purple. Troverai la guida scritta completa, i diagrammi e i riferimenti di configurazione su purple.ai. Alla prossima.