Como Configurar WiFi Corporativo em Dispositivos Android com EAP-TLS

Como Configurar WiFi de Grande Empresa em Dispositivos Android com EAP-TLS Uma Breve Apresentação Técnica Purple - Aproximadamente 10 Minutos --- INTRODUÇÃO E CONTEXTO - aproximadamente 1 minuto Bem-vindo à série de Breves Apresentações Técnicas Purple. Sou o seu anfitrião e hoje vamos entrar nos detalhes da implementação da autenticação 802.1X EAP-TLS em dispositivos Android - quer esteja a gerir um complexo hoteleiro, uma cadeia de lojas, 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 rodar e assegura 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 em 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. --- MERGULHO TÉCNICO PROFUNDO - aproximadamente 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. Não toma a decisão de autenticação por si só; transmite a conversação entre o dispositivo e um servidor RADIUS, que é o servidor de autenticação real. 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, é que o EAP-TLS utiliza certificados X.509 de 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 uma autenticação mútua e é isso que torna o EAP-TLS a opção mais segura disponível. Agora, especificamente no Android, há algumas coisas 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, neste momento, 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 confiar apenas no repositório de confiança 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 configurados antes que um único dispositivo Android possa autenticar-se 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 com extensão .p12 ou .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 de forma silenciosa para o keystore gerido do dispositivo - sem necessidade de interação do utilizador. Agora vamos falar sobre o perfil de WiFi em si. 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 de personificação (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 WiFi que faz referência a esse perfil de certificado. Quando o dispositivo se liga, 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 WiFi para dispositivos detalha os passos exatos de configuração - recomendo a leitura do mesmo juntamente com este documento. Para o 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 UI específica difere, mas os requisitos de cadeia de certificados e configuração RADIUS são os mesmos. Uma coisa que vale a pena assinalar do lado do RADIUS: se estiver a executar o 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 em relação a isto. Um certificado que funciona bem 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 seu certificado CA raiz para o repositório de certificados do utilizador do 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 falhará de qualquer forma 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 automática implementada através de SCEP ou NDES, irá acordar uma manhã e descobrir que metade dos seus dispositivos perdeu o acesso ao WiFi em simultâneo. Integre a automação de 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 dispendiosos 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 pelo seu 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 definido explicitamente, mesmo quando este pode ser deduzido 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 de propriedade corporativa. O EAP-TLS funciona com WPA3-Enterprise? Sim, e o WPA3-Enterprise com o modo de 192 bits na verdade exige 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, force 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 opera num SSID separado da sua rede corporativa 802.1X. Os seus dispositivos corporativos autenticam-se através de EAP-TLS no SSID seguro, enquanto os dispositivos de convidados utilizam o captive portal da Purple no SSID de convidados. Os dois 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, é perfeitamente prático de implementar à escala. As três coisas a garantir são: uma PKI corretamente configurada 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 está a fazer a implementação num local com tráfego misto corporativo e de 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 mutuamente. Para os seus próximos passos: reveja o nosso diagrama de arquitetura no guia completo, siga o passo a passo de implementação no 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.