Como Configurar WiFi Corporativo em Dispositivos Android com 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 Boas-vindas à série de Briefings Técnicos da Purple. Sou o seu anfitrião e hoje vamos detalhar as especificidades da implantação da autenticação 802.1X EAP-TLS em dispositivos Android - quer você esteja gerenciando uma rede de hotéis, 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 utiliza 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 das estruturas 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 implantaçõ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 atua como o chamado autenticador. Ele não toma a decisão de autenticação por si só; ele apenas repassa a conversa entre o dispositivo e um servidor RADIUS, que é o servidor de autenticação propriamente dito. O EAP-TLS - Protocolo de Autenticação Extensível com Segurança de Camada de Transporte - é o método de autenticação executado dentro dessa estrutura 802.1X. O que o diferencia do EAP-PEAP ou do EAP-TTLS, que utilizam nome de usuário e senha dentro de um túnel TLS, é que o EAP-TLS utiliza 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 é a 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 versões posteriores introduziram requisitos de validação de certificado mais rigorosos. Se você estiver implantando no Android 11 ou superior - o 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 depender apenas do 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 instalados 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 SCEP via Intune. Segundo, um certificado de servidor emitido para 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 dot-P12 ou dot-PFX - que contém o certificado e a chave privada criptografada. Em um dispositivo configurado manualmente, o usuário importa esse arquivo através de Configurações, depois Segurança, e então 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 de 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 faz o check-in, ele recebe o certificado e o perfil de WiFi, e se conecta à sua rede 802.1X automaticamente. Sem interação do usuário, sem chamadas 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 VMware Workspace ONE e Jamf Connect, o processo é arquitetonicamente idêntico - perfil de certificado SCEP ou PKCS, seguido por um perfil de WiFi que o referencia. A interface de usuário específica difere, mas a cadeia de certificados e os requisitos de configuração do RADIUS são os mesmos. Uma coisa importante a destacar no lado do RADIUS: se você estiver executando 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 com 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 ERROS COMUNS - aproximadamente 2 minutos Certo, vamos falar sobre o que realmente dá errado em campo, porque é aqui que a maioria das implantações encontra problemas. O primeiro e mais comum erro é a confiança no certificado. O Android 11 e superior 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 repositório de certificados do usuário do dispositivo via MDM e faça referência explícita a ele no campo de certificado de CA do perfil de WiFi. Não deixe isso como "Não validar" - isso é uma falha de segurança e falhará em algumas versões do Android de qualquer maneira. O segundo erro comum é 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á um dia e descobrirá que metade dos seus dispositivos perdeu o acesso ao WiFi simultaneamente. Crie a automação de renovação de certificados no 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 simultâneas, não para a carga média. Finalmente, no 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 escala. Os dispositivos Samsung, em particular, historicamente exigem que o campo de identidade seja definido explicitamente, mesmo quando ele pode ser deduzido 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 escala, considere se o EAP-TTLS com PAP ou PEAP-MSCHAPv2 é uma compensação mais prática, com o EAP-TLS reservado 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 WPA3-Enterprise em ambientes de alta segurança, o EAP-TLS é sua única opção compatível. 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, force a validação explícita do certificado CA. Para o Android 13 e superior, você pode aproveitar as APIs de gerenciamento de certificados aprimoradas 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 visitantes usam o captive portal da Purple no SSID de convidados. Ambos coexistem na mesma infraestrutura de ponto de acesso, com a separação por VLAN fornecendo o limite de segurança. - RESUMO E PRÓXIMOS PASSOS - aproximadamente 1 minuto Para encerrar: 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ê deve acertar são: uma PKI configurada corretamente 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 você estiver implantando em um local com tráfego misto de corporativo e visitantes, 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 bem. Para os próximos passos: revise nosso diagrama de arquitetura no guia completo, trabalhe no 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, escale com confiança. Obrigado por ouvir o Informativo Técnico da Purple. Você encontrará o guia escrito completo, diagramas e referências de configuração em purple.ai. Até a próxima.