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

Como Configurar WiFi Corporativo em Dispositivos Android com EAP-TLS Um Briefing Técnico da Purple — Aproximadamente 10 Minutos --- INTRODUÇÃO E CONTEXTO — aproximadamente 1 minuto Bem-vindo à série de Briefings Técnicos da Purple. Eu sou o seu anfitrião e hoje vamos entrar nos detalhes da implantação da autenticação 802.1X EAP-TLS em dispositivos Android — quer você esteja gerenciando uma rede hoteleira, uma rede de varejo, um estádio ou um campus do setor público. Se você é responsável por uma rede que precisa autenticar dispositivos Android corporativos ou BYOD sem depender de senhas compartilhadas, este episódio é para você. O EAP-TLS é o padrão ouro para a segurança de WiFi corporativo — ele usa autenticação mútua baseada em certificados, o que significa que não há credenciais para sofrer phishing, não há senhas para rotacionar e oferece uma postura de conformidade que atende ao PCI DSS, ISO 27001 e à maioria dos frameworks de segurança do setor público. Ao final deste briefing, você entenderá exatamente como o EAP-TLS funciona no Android, quais são as suas opções de implantação e os três erros mais comuns que causam falhas nas implementações. Vamos começar. --- MERGULHO TÉCNICO PROFUNDO — aproximadamente 5 minutos Vamos começar com a arquitetura. O 802.1X é o padrão IEEE que rege o controle de acesso à rede baseado em porta. Quando um dispositivo Android se conecta a uma rede WiFi corporativa — configurada como WPA2-Enterprise ou WPA3-Enterprise —, o ponto de acesso age como o que chamamos de autenticador. Ele não toma a decisão de autenticação por si só; ele apenas intermedia a conversa entre o dispositivo e um servidor RADIUS, que é o servidor de autenticação real. O EAP-TLS — que significa Extensible Authentication Protocol com Transport Layer Security — é o método de autenticação executado dentro desse framework 802.1X. O que o diferencia do EAP-PEAP ou EAP-TTLS, que usam usuário e senha dentro de um túnel TLS, é que o EAP-TLS usa 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 se validam mutuamente. Isso é autenticação mútua, e é o que torna o EAP-TLS a opção mais segura disponível. Agora, especificamente no Android, há algumas coisas que você precisa entender. O Android 11 e as versões posteriores introduziram requisitos de validação de certificado mais rígidos. Se você estiver implantando no Android 11 ou superior — que a esta altura representa a grande maioria dos seus dispositivos —, o dispositivo se recusará a conectar a menos que o certificado do servidor RADIUS seja explicitamente confiável. Você não pode confiar apenas no repositório de confiança do sistema; você deve enviar o certificado da CA raiz para o dispositivo ou configurar o perfil de WiFi para referenciá-lo explicitamente. Vamos falar sobre a cadeia de certificados. Você precisa de três componentes configurados antes que um único dispositivo Android possa se autenticar via EAP-TLS. Primeiro, uma Autoridade Certificadora — seja sua PKI interna, o Microsoft Active Directory Certificate Services ou uma PKI em 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 usuário, também assinado pela mesma CA. O dispositivo apresenta seu certificado de cliente durante o handshake TLS, e o servidor RADIUS o valida 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 arquivo PKCS12 — que é um arquivo ponto-P12 ou ponto-PFX — que contém tanto o certificado quanto a chave privada criptografada. Em um dispositivo configurado manualmente, o usuário importa esse arquivo através de Configurações, depois Segurança e, em seguida, Instalar um Certificado. Em um dispositivo gerenciado por MDM, o certificado é enviado silenciosamente para o keystore gerenciado do dispositivo — sem necessidade de interação do usuário. Agora vamos falar sobre o perfil de WiFi em si. Ao configurar uma conexão WiFi corporativa no Android, você precisa especificar: o SSID, o tipo de segurança — WPA2-Enterprise ou WPA3-Enterprise —, o método EAP — que é TLS —, o certificado da CA para validação do servidor, o certificado do cliente para autenticação do dispositivo e a string de identidade, que normalmente é o Common Name do dispositivo ou o UPN do usuário. No Android 11 e superior, você também precisa especificar a correspondência de sufixo de domínio ou o assunto do certificado do servidor para evitar ataques man-in-the-middle. Para implantações de MDM — e é aqui que entra a verdadeira escala —, você envia tudo isso como um perfil de configuração estruturado. No Microsoft Intune, você cria um perfil de certificado SCEP que solicita e instala automaticamente um certificado de cliente exclusivo em cada dispositivo Android registrado. Em seguida, você cria um perfil de configuração de WiFi que faz referência a esse perfil de certificado. Quando o dispositivo se conecta, ele recebe tanto o certificado quanto o perfil de WiFi, conectando-se à sua rede 802.1X automaticamente. Sem interação do usuário, sem chamados de suporte. Se você estiver usando o Intune para isso, nosso guia complementar sobre como usar o Microsoft Intune para enviar certificados de WiFi para dispositivos detalha as etapas exatas de configuração — recomendo a leitura desse material junto com este briefing. Para o VMware Workspace ONE e o Jamf Connect, o processo é arquitetonicamente idêntico — perfil de certificado SCEP ou PKCS, seguido por um perfil de WiFi que faz referência a ele. A interface do usuário específica difere, mas a cadeia de certificados e os requisitos de configuração do RADIUS são os mesmos. Uma coisa que vale a pena destacar do lado do RADIUS: se você estiver executando o FreeRADIUS, Microsoft NPS ou Cisco ISE, certifique-se de que o certificado do seu servidor inclua os atributos corretos de Uso Estendido de Chave (EKU) — especificamente, Autenticação de Servidor, OID 1.3.6.1.5.5.7.3.1. O Android é rigoroso quanto a isso. Um certificado que funciona perfeitamente com clientes Windows pode falhar no Android se o EKU estiver ausente ou configurado incorretamente. --- RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS — aproximadamente 2 minutos Certo, vamos falar sobre o que realmente dá errado em campo, porque é aqui que a maioria das implantações enfrenta problemas. O primeiro e mais comum erro é a confiança no certificado. O Android 11 e versões superiores não se conectarã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 usuário do dispositivo via MDM e faça referência explícita a ele no campo de certificado CA do perfil de WiFi. Não deixe isso como "Não validar" — isso é uma brecha de segurança e falhará em algumas versões do Android de qualquer maneira. A segunda armadilha é a expiração do certificado. Os certificados de cliente normalmente têm um período de validade de um a dois anos. Se você não tiver a renovação automatizada configurada via SCEP ou NDES, acordará uma manhã e descobrirá que metade dos seus dispositivos perdeu o acesso ao WiFi simultaneamente. Integre a automação de renovação de certificados ao seu fluxo de trabalho de 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 caros do que os handshakes PEAP devido à troca mútua completa de certificados. Em um estádio ou centro de conferências com milhares de autenticações simultâneas, um servidor RADIUS subdimensionado se tornará um gargalo. Dimensione sua infraestrutura RADIUS para o pico de autenticações concorrentes, não para a carga média. Finalmente, do lado do Android, esteja ciente de que diferentes fabricantes — Samsung, Google, Xiaomi — têm implementações ligeiramente diferentes da API de configuração de WiFi. Teste seus perfis enviados por MDM em dispositivos representativos de cada fabricante em sua empresa antes de implantar em grande escala. Os dispositivos Samsung, em particular, historicamente exigem que o campo de identidade seja definido explicitamente, mesmo quando ele pode ser deduzido a partir do certificado. --- PERGUNTAS E RESPOSTAS RÁPIDAS — aproximadamente 1 minuto Algumas perguntas rápidas que recebo regularmente. Posso usar EAP-TLS para dispositivos BYOD? Sim, mas isso exige que o usuário instale um certificado de cliente em seu dispositivo pessoal. Para BYOD em larga escala, considere se o EAP-TTLS com PAP ou PEAP-MSCHAPv2 é uma alternativa mais prática, reservando o EAP-TLS para dispositivos de propriedade da empresa. O EAP-TLS funciona com WPA3-Enterprise? Sim, e o WPA3-Enterprise com modo de 192 bits na verdade exige o EAP-TLS. Se você estiver implantando o WPA3-Enterprise em ambientes de alta segurança, o EAP-TLS é sua única opção em conformidade. Qual é a versão mínima do Android que devo segmentar? 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, você pode aproveitar as APIs aprimoradas de gerenciamento de certificados para um controle mais granular. A plataforma da Purple pode se integrar com redes EAP-TLS? A plataforma de guest WiFi e analytics da Purple opera em um SSID separado da sua rede corporativa 802.1X. Seus dispositivos corporativos se autenticam via EAP-TLS no SSID seguro, enquanto os dispositivos de convidados usam o Captive Portal da Purple no SSID de convidados. Ambos coexistem na mesma infraestrutura de pontos de acesso, com a separação por VLAN fornecendo o limite de segurança. --- RESUMO E PRÓXIMOS PASSOS — aproximadamente 1 minuto Para resumir: o EAP-TLS no Android é o método de autenticação WiFi corporativo mais seguro disponível e, com as ferramentas modernas de MDM, é totalmente prático de implantar em escala. As três coisas que você precisa acertar são: uma PKI configurada corretamente com renovação automatizada 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 você estiver implantando em um local com tráfego misto de corporativo e convidados, a plataforma da Purple oferece a camada de analytics e engajamento na rede de convidados, enquanto sua infraestrutura EAP-TLS protege o lado corporativo. Ambos se complementam perfeitamente. Para os seus próximos passos: revise nosso diagrama de arquitetura no guia completo, siga o passo a passo de implantação do Intune e execute um piloto em um subconjunto de dispositivos antes de implantar 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, expanda com confiança. Obrigado por ouvir o Briefing Técnico da Purple. Você encontrará o guia escrito completo, diagramas e referências de configuração em purple.ai. Até a próxima.