Come configurare il WiFi aziendale su dispositivi Android con EAP-TLS

Come configurare il WiFi Enterprise sui dispositivi Android con EAP-TLS Un briefing tecnico Purple - Circa 10 minuti --- INTRODUZIONE E CONTESTO - circa 1 minuto Benvenuti alla serie di briefing tecnici di Purple. Sono il vostro ospite e oggi entreremo nei dettagli dell'implementazione dell'autenticazione 802.1X EAP-TLS sui dispositivi Android, sia che gestiate una catena di hotel, 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 WiFi aziendale - utilizza un'autenticazione reciproca basata su certificati, il che significa nessuna credenziale da intercettare tramite phishing, nessuna password da ruotare e una postura 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 del rollout. Cominciamo. --- APPROFONDIMENTO TECNICO - circa 5 minuti Iniziamo con l'architettura. Lo standard 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 WiFi aziendale - configurata come WPA2-Enterprise o WPA3-Enterprise - l'access point funge da cosiddetto 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 eseguito 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 del server al dispositivo e il dispositivo presenta un certificato del client al server RADIUS. Entrambe le parti si convalidano a vicenda. Si tratta di un'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 del certificato più rigidi. Se state implementando 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 considerato attendibile. Non potete affidarvi esclusivamente all'archivio di attendibilità del sistema; dovete inviare il certificato CA radice al dispositivo o configurare il profilo WiFi in modo che faccia esplicitamente 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 PKI interna, i Microsoft Active Directory Certificate Services o una PKI cloud come SCEP tramite Intune. In secondo luogo, un certificato server emesso per il server RADIUS, firmato da tale CA. In terzo luogo, 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, 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 con estensione .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 in background al keystore gestito del dispositivo - senza richiedere alcuna interazione da parte dell'utente. Ora parliamo del profilo WiFi vero e proprio. 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 della CA per la convalida del server, il certificato client per l'autenticazione del dispositivo e la stringa di 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 di tipo man-in-the-middle. Per le distribuzioni MDM - ed è qui che entra in gioco la vera scalabilità - tutto questo viene inviato 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 di assistenza. 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 questo briefing. 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 la catena di certificati e i requisiti di configurazione RADIUS sono gli stessi. Un aspetto importante da segnalare per quanto riguarda RADIUS: se utilizzate FreeRADIUS, Microsoft NPS o Cisco ISE, assicuratevi che il certificato del server includa gli attributi corretti di Extended Key Usage (EKU) - 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 è mancante o configurato in modo errato. --- RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE COMUNI - circa 2 minuti Bene, parliamo di ciò che va storto sul campo, perché è qui che la maggior parte delle distribuzioni incontra problemi. Il primo errore, nonché il più comune, riguarda l'affidabilità dei certificati. Android 11 e versioni successive non si connetteranno se la catena di certificati del server RADIUS non può essere convalidata. La soluzione è semplice: distribuite il certificato della CA radice nell'archivio dei certificati utente del dispositivo tramite MDM e inserite un riferimento esplicito nel campo del certificato CA del profilo WiFi. Non lasciate questa opzione su "Non convalidare" - è una vulnerabilità di sicurezza e in ogni caso non funzionerà su alcune versioni di Android. La seconda trappola è la scadenza dei certificati. I certificati client hanno solitamente un periodo di validità da uno a due anni. Se non disponete di un rinnovo automatico tramite SCEP o NDES, vi sveglierete una mattina scoprendo che metà del vostro parco dispositivi ha perso contemporaneamente l'accesso al WiFi. 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 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. Dimensionate la vostra 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 differenti delle API di configurazione WiFi. Testate i vostri profili distribuiti tramite MDM su dispositivi rappresentativi di ciascun produttore del vostro parco macchine prima di procedere a un rilascio 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 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, valutate 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 state distribuendo 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 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 di analisi e guest WiFi di Purple funziona su un SSID separato dalla 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 fornisce la barriera di sicurezza. - RIASSUNTO E PROSSIMI PASSI - circa 1 minuto Per riassumere: 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 da gestire correttamente sono: una PKI configurata correttamente con rinnovo automatico dei certificati, la fiducia esplicita nel certificato CA su Android 11 e versioni successive e un'infrastruttura RADIUS dimensionata per il carico di picco. Se stai effettuando la distribuzione in una sede con traffico misto aziendale e guest, la piattaforma di Purple ti offre il livello di analisi e coinvolgimento sulla rete guest, mentre la tua infrastruttura EAP-TLS protegge il lato aziendale. I due si completano a vicenda in modo eccellente. Per i tuoi prossimi passi: consulta il nostro diagramma dell'architettura nella guida completa, segui la procedura guidata di distribuzione 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 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.