How to Set Up Enterprise WiFi on Android Devices with EAP-TLS

Como Configurar WiFi Empresarial em Dispositivos Android com EAP-TLS Uma Apresentação Técnica da Purple — Cerca de 10 Minutos --- INTRODUÇÃO E CONTEXTO — cerca de 1 minuto Bem-vindo à série de Apresentações Técnicas da Purple. Sou o seu anfitrião e hoje vamos analisar os detalhes da implementação da autenticação 802.1X EAP-TLS em dispositivos Android — quer esteja a gerir um complexo hoteleiro, uma cadeia de retalho, um estádio ou um campus do setor público. Se é responsável por uma rede que precisa de autenticar dispositivos Android corporativos ou BYOD sem depender de palavras-passe partilhadas, este episódio é para si. O EAP-TLS é o padrão de excelência para a segurança de WiFi empresarial — utiliza autenticação mútua baseada em certificados, o que significa que não há credenciais para phish, não há palavras-passe para renovar e garante uma postura de conformidade que satisfaz o PCI DSS, a ISO 27001 e a maioria dos referenciais de segurança do setor público. No final desta apresentação, compreenderá exatamente como o EAP-TLS funciona no Android, quais são as suas opções de implementação e os três erros mais comuns que causam falhas nas implementações. Vamos a isso. --- ANÁLISE TÉCNICA DETALHADA — cerca de 5 minutos Comecemos pela arquitetura. O 802.1X é a norma IEEE que rege o controlo de acesso à rede baseado em portas. Quando um dispositivo Android se liga a uma rede WiFi empresarial — configurada como WPA2-Enterprise ou WPA3-Enterprise — o ponto de acesso funciona como o chamado autenticador. Este não toma a decisão de autenticação por si só; limita-se a transmitir a conversação entre o dispositivo e um servidor RADIUS, que é o servidor de autenticação propriamente dito. O EAP-TLS — ou seja, Extensible Authentication Protocol com Transport Layer Security — é o método de autenticação executado dentro dessa estrutura 802.1X. O que o distingue do EAP-PEAP ou do EAP-TTLS, que utilizam nome de utilizador e palavra-passe dentro de um túnel TLS, é o facto de o EAP-TLS utilizar certificados X.509 em ambos os lados. O servidor RADIUS apresenta um certificado de servidor ao dispositivo, e o dispositivo apresenta um certificado de cliente de volta ao servidor RADIUS. Ambas as partes validam-se mutuamente. Trata-se de autenticação mútua, e é isso que torna o EAP-TLS a opção mais segura disponível. Agora, especificamente no Android, há alguns aspetos que precisa de compreender. O Android 11 e as versões posteriores introduziram requisitos de validação de certificados mais rigorosos. Se estiver a implementar no Android 11 ou superior — o que, nesta altura, representa a grande maioria do seu parque de dispositivos — o dispositivo recusará a ligação a menos que o certificado do servidor RADIUS seja explicitamente fidedigno. Não pode depender apenas do repositório de fidedignidade do sistema; deve enviar o certificado da CA raiz para o dispositivo ou configurar o perfil de WiFi para o referenciar explicitamente. Vamos falar sobre a cadeia de certificados. Precisa de três componentes implementados antes que um único dispositivo Android se possa autenticar via EAP-TLS. Primeiro, uma Autoridade de Certificação — seja a sua PKI interna, o Microsoft Active Directory Certificate Services ou uma PKI na nuvem como o SCEP via Intune. Segundo, um certificado de servidor emitido para o seu servidor RADIUS, assinado por essa CA. Terceiro, um certificado de cliente exclusivo emitido para cada dispositivo ou utilizador, também assinado pela mesma CA. O dispositivo apresenta o seu certificado de cliente durante o handshake TLS, e o servidor RADIUS valida-o em relação à lista de revogação de certificados da CA, ou CRL, ou via OCSP — Online Certificate Status Protocol. Para o Android, o certificado de cliente e a chave privada são normalmente empacotados como um ficheiro PKCS12 — que é um ficheiro ponto-P12 ou ponto-PFX — que contém tanto o certificado como a chave privada encriptada. Num dispositivo configurado manualmente, o utilizador importa este ficheiro através de Definições, depois Segurança e, em seguida, Instalar um Certificado. Num dispositivo gerido por MDM, o certificado é enviado silenciosamente para o keystore gerido do dispositivo — sem necessidade de interação do utilizador. Agora vamos falar sobre o próprio perfil de WiFi. Ao configurar uma ligação WiFi empresarial no Android, precisa de especificar: o SSID, o tipo de segurança — WPA2-Enterprise ou WPA3-Enterprise — o método EAP — que é TLS — o certificado CA para validação do servidor, o certificado de cliente para autenticação do dispositivo e a string de identidade, que é normalmente o Common Name do dispositivo ou o UPN do utilizador. No Android 11 e superior, também precisa de especificar a correspondência do sufixo do domínio ou o assunto do certificado do servidor para evitar ataques man-in-the-middle. Para implementações de MDM — e é aqui que entra a verdadeira escala — está a enviar tudo isto como um perfil de configuração estruturado. No Microsoft Intune, cria um perfil de certificado SCEP que solicita e instala automaticamente um certificado de cliente exclusivo em cada dispositivo Android registado. Em seguida, cria um perfil de configuração de WiFi que faz referência a esse perfil de certificado. Quando o dispositivo faz o check-in, recebe tanto o certificado como o perfil de WiFi, e liga-se à sua rede 802.1X automaticamente. Sem interação do utilizador, sem chamadas de suporte. Se estiver a utilizar o Intune para isto, o nosso guia complementar sobre como utilizar o Microsoft Intune para enviar certificados de WiFi para dispositivos detalha os passos exatos de configuração — recomendo a leitura desse guia em conjunto com este briefing. Para o VMware Workspace ONE e Jamf Connect, o processo é arquitetonicamente idêntico — perfil de certificado SCEP ou PKCS, seguido de um perfil de WiFi que o referencia. A interface de utilizador específica difere, mas a cadeia de certificados e os requisitos de configuração do RADIUS são os mesmos. Uma questão importante a assinalar do lado do RADIUS: se estiver a utilizar FreeRADIUS, Microsoft NPS ou Cisco ISE, certifique-se de que o certificado do seu servidor inclui os atributos corretos de Extended Key Usage — especificamente, Server Authentication, OID 1.3.6.1.5.5.7.3.1. O Android é rigoroso quanto a isto. Um certificado que funciona perfeitamente com clientes Windows pode falhar no Android se o EKU estiver em falta ou mal configurado. --- RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS — aproximadamente 2 minutos Muito bem, vamos falar sobre o que realmente corre mal no terreno, porque é aqui que a maioria das implementações encontra problemas. A primeira e mais comum falha é a confiança no certificado. O Android 11 e versões superiores não se ligarão se a cadeia de certificados do servidor RADIUS não puder ser validada. A solução é simples: envie o certificado da sua CA raiz para o armazenamento de certificados do utilizador no dispositivo através de MDM e faça referência explícita ao mesmo no campo de certificado CA do perfil de WiFi. Não deixe isto como "Não validar" — isso é uma falha de segurança e, de qualquer forma, irá falhar em algumas versões do Android. O segundo erro comum é a expiração do certificado. Os certificados de cliente têm normalmente um período de validade de um a dois anos. Se não tiver uma renovação automatizada implementada via SCEP ou NDES, irá acordar uma manhã e descobrir que metade dos dispositivos da sua empresa perdeu o acesso ao WiFi em simultâneo. Integre a automatização da renovação de certificados no fluxo de trabalho do seu MDM desde o primeiro dia, e não como uma reflexão tardia. O terceiro problema é a capacidade do servidor RADIUS. Os handshakes EAP-TLS são computacionalmente mais exigentes do que os handshakes PEAP devido à troca mútua completa de certificados. Num estádio ou centro de conferências com milhares de autenticações simultâneas, um servidor RADIUS subdimensionado tornar-se-á um estrangulamento. Dimensione a sua infraestrutura RADIUS para picos de autenticações simultâneas, e não para a carga média. Finalmente, do lado do Android, tenha em atenção que diferentes fabricantes — Samsung, Google, Xiaomi — têm implementações ligeiramente diferentes da API de configuração de WiFi. Teste os perfis enviados por MDM em dispositivos representativos de cada fabricante na sua empresa antes de os implementar em grande escala. Os dispositivos Samsung, em particular, exigiram historicamente que o campo de identidade fosse explicitamente definido, mesmo quando este pode ser deduzido a partir do certificado. --- PERGUNTAS E RESPOSTAS RÁPIDAS — aproximadamente 1 minuto Algumas perguntas rápidas que me fazem regularmente. Posso usar EAP-TLS para dispositivos BYOD? Sim, mas exige que o utilizador instale um certificado de cliente no seu dispositivo pessoal. Para BYOD em grande escala, considere se o EAP-TTLS com PAP ou PEAP-MSCHAPv2 é um compromisso mais prático, reservando o EAP-TLS para dispositivos propriedade da empresa. O EAP-TLS funciona com WPA3-Enterprise? Sim, e o WPA3-Enterprise com modo de 192 bits exige obrigatoriamente o EAP-TLS. Se estiver a implementar WPA3-Enterprise em ambientes de alta segurança, o EAP-TLS é a sua única opção em conformidade. Qual é a versão mínima do Android que devo visar? O Android 8 e superior suporta EAP-TLS nativamente. Para o Android 11 e superior, imponha a validação explícita do certificado CA. Para o Android 13 e superior, pode tirar partido das APIs de gestão de certificados melhoradas para um controlo mais granular. A plataforma da Purple pode integrar-se com redes EAP-TLS? A plataforma de guest WiFi e analytics da Purple funciona num SSID separado da sua rede corporativa 802.1X. Os seus dispositivos corporativos autenticam-se via EAP-TLS no SSID seguro, enquanto os dispositivos de convidados utilizam o Captive Portal da Purple no SSID de convidados. Ambos coexistem na mesma infraestrutura de pontos de acesso, com a separação por VLAN a fornecer a barreira de segurança. --- RESUMO E PRÓXIMOS PASSOS — aproximadamente 1 minuto Para concluir: O EAP-TLS no Android é o método de autenticação WiFi empresarial mais seguro disponível e, com as ferramentas modernas de MDM, é totalmente viável de implementar à escala. Os três aspetos a garantir são: uma PKI devidamente configurada com renovação automática de certificados, confiança explícita no certificado CA no Android 11 e superior, e uma infraestrutura RADIUS dimensionada para a carga de pico. Se está a implementar num espaço com tráfego misto de colaboradores e convidados, a plataforma da Purple oferece-lhe a camada de analytics e engagement na rede de convidados, enquanto a sua infraestrutura EAP-TLS protege o lado corporativo. Ambos se complementam perfeitamente. Para os seus próximos passos: reveja o nosso diagrama de arquitetura no guia completo, siga o passo a passo de implementação do Intune e execute um piloto num subconjunto de dispositivos antes de implementar em toda a sua infraestrutura. Comece com um grupo controlado de cinquenta dispositivos, valide a entrega de certificados e a conectividade WiFi e, em seguida, dimensione com confiança. Obrigado por ouvir o Purple Technical Briefing. Encontrará o guia escrito completo, diagramas e referências de configuração em purple.ai. Até à próxima.