Implementar a Autenticação 802.1X em Dispositivos Móveis

PODCAST SCRIPT: Implementing 802.1X Authentication on Mobile Devices Duration: ~10 minutes | Voice: UK English, male, senior consultant tone Structure: Introduction & Context (1 min) → Technical Deep-Dive (5 min) → Implementation Recommendations & Pitfalls (2 min) → Rapid-Fire Q&A (1 min) → Summary & Next Steps (1 min) --- [INTRODUCTION & CONTEXT — ~1 minute] Bem-vindos de volta. Hoje vamos abordar algo que surge constantemente em projetos de WiFi empresarial — a autenticação 802.1X em dispositivos móveis. Se gere uma rede hoteleira, uma rede de retalho, um estádio ou qualquer espaço do setor público onde os funcionários e convidados se ligam em iPhones e dispositivos Android, este é o padrão que precisa de compreender corretamente. O 802.1X não é novo. Tem sido a espinha dorsal da segurança sem fios empresarial há mais de duas décadas. Mas os dispositivos móveis alteraram significativamente o cenário de implementação. A gestão de certificados, a seleção do método EAP, os fluxos de trabalho de aprovisionamento de MDM — estas são todas áreas onde os projetos correm mal e onde fazer as coisas bem traz uma melhoria significativa em termos de segurança e operação. Por isso, vamos analisar a arquitetura, os passos de implementação para Apple e Android e as falhas comuns que custam semanas de resolução de problemas às equipas. --- [TECHNICAL DEEP-DIVE — ~5 minutes] Comecemos pelos fundamentos. O IEEE 802.1X é um padrão de controlo de acesso à rede baseado em portas. Define três funções: o suplicante — que é o seu dispositivo móvel —, o autenticador, que é tipicamente o seu ponto de acesso sem fios ou controlador LAN sem fios, e o servidor de autenticação, quase sempre um servidor RADIUS. Quando um dispositivo tenta ligar-se a um SSID protegido por 802.1X, o ponto de acesso não concede acesso total à rede imediatamente. Em vez disso, abre uma porta controlada e inicia uma troca EAP — que é o Extensible Authentication Protocol. O dispositivo apresenta as credenciais, o ponto de acesso retransmite-as para o servidor RADIUS e o servidor RADIUS aceita ou rejeita a ligação. Apenas após a aceitação é que o ponto de acesso abre a porta não controlada e permite o tráfego total de rede. Agora, o método EAP que escolher é crítico, e é aqui que as implementações móveis divergem das redes empresariais tradicionais centradas em portáteis. O EAP-TLS é o padrão de excelência. Utiliza autenticação mútua baseada em certificados — tanto o servidor como o cliente apresentam certificados. Não há nome de utilizador ou palavra-passe na troca. É resistente a phishing de credenciais, ataques man-in-the-middle e força bruta. Tanto o iOS como o Android suportam-no nativamente. O desafio é a gestão do ciclo de vida dos certificados — precisa de uma PKI funcional e precisa de colocar os certificados de cliente nos dispositivos, o que significa que o MDM é essencialmente obrigatório. O PEAP com MSCHAPv2 é o método mais amplamente implementado na prática. Envolve o MSCHAPv2 dentro de um túnel TLS, pelo que as credenciais estão protegidas em trânsito. O iOS e o Android suportam-no nativamente. O compromisso é que depende de nome de utilizador e palavra-passe, o que introduz uma sobrecarga de gestão de credenciais e risco de exposição se o certificado do servidor não for devidamente validado no lado do cliente. O EAP-TTLS com PAP é comum em ambientes com diretórios LDAP legados. O Android suporta-no nativamente; o iOS requer um perfil de configuração. Vale a pena notar que o PAP transmite a palavra-passe em texto simples dentro do túnel TLS, pelo que a integridade do túnel é tudo aqui. O EAP-FAST é principalmente uma solução da Cisco. O iOS suporta-no nativamente; o suporte em Android é inconsistente entre fabricantes e versões do SO. Para a maioria das implementações móveis empresariais atuais, a recomendação é o EAP-TLS onde tiver cobertura de MDM, e o PEAP-MSCHAPv2 onde não tiver — com uma validação estrita do certificado do servidor aplicada. Agora vamos falar sobre o lado da infraestrutura. O seu servidor RADIUS é o coração da implementação. O Microsoft NPS, FreeRADIUS, Cisco ISE e Aruba ClearPass são as principais opções. Para implementações nativas na nuvem, o JumpCloud, Foxpass e Portnox oferecem RADIUS-as-a-service, o que remove o fardo da infraestrutura local. O seu servidor RADIUS precisa de estar configurado com o método EAP correto, o segredo partilhado para cada ponto de acesso ou WLC e o repositório de utilizadores — seja o Active Directory, LDAP ou uma base de dados local. Para o EAP-TLS, também precisa da cadeia de certificados CA para validar os certificados de cliente. No lado da autoridade de certificação, tem três opções. Uma PKI interna utilizando o Microsoft ADCS ou uma CA autónoma dá-lhe controlo total e custo zero de certificados, mas requer maturidade operacional para gerir. Um serviço de PKI na nuvem — SCEPman, Smallstep ou semelhante — integra-se bem com plataformas MDM modernas e reduz significativamente o fardo operacional. Os certificados públicos de uma CA comercial raramente são utilizados para autenticação de clientes devido ao custo e complexidade. Agora, a configuração do dispositivo. No iOS, o caminho de implementação mais limpo é o Apple Configurator ou uma plataforma MDM como o Jamf, Microsoft Intune ou Mosyle. Envia um perfil de configuração de WiFi que especifica o SSID, o método EAP, o certificado do servidor em que deve confiar e — para o EAP-TLS — o certificado do cliente. O perfil trata de tudo silenciosamente. Os utilizadores ligam-se sem quaisquer passos manuais. A configuração manual no iOS é possível, mas frágil. Os utilizadores navegam para Definições, WiFi, tocam no SSID, introduzem as credenciais e, em seguida, é-lhes apresentada uma solicitação de confiança do certificado. Se o certificado do servidor não for de uma CA fidedigna, o iOS mostra um aviso. Os utilizadores tocam rotineiramente em "Confiar" sem ler, o que anula completamente o propósito da validação do certificado. É por isso que o aprovisionamento de MDM não é opcional para implementações sérias. No Android, o cenário é mais fragmentado. O Android 11 e posterior exigem que um certificado CA seja especificado ao ligar a uma rede 802.1X — já não é possível selecionar "Não validar" no Android moderno sem um aviso. Esta é uma alteração de segurança positiva, mas significa que precisa de distribuir o seu certificado CA para os dispositivos Android, seja via MDM — Android Enterprise com Intune ou VMware Workspace ONE — ou instalando-o manualmente a partir do armazenamento do dispositivo. O Android também tem particularidades específicas de cada fabricante. Os dispositivos Samsung com One UI têm uma gestão de certificados ligeiramente diferente do Android puro. Alguns dispositivos Huawei mais antigos têm problemas de compatibilidade EAP-TLS com conjuntos de cifras específicos. Testar em toda a sua população de dispositivos-alvo antes do lançamento é inegociável. Para a infraestrutura sem fios, os seus pontos de acesso ou WLC precisam de estar configurados com o SSID definido para WPA2-Enterprise ou WPA3-Enterprise, o IP do servidor RADIUS e o segredo partilhado e — criticamente — a contabilização RADIUS se pretender visibilidade da sessão por utilizador. O WPA3-Enterprise com o modo de 192 bits é a melhor prática atual para ambientes de alta segurança e combina bem com o EAP-TLS. Se ainda não está a planear a sua migração para o WPA3, vale a pena ler o guia sobre a implementação do WPA3-Enterprise para uma segurança sem fios melhorada juntamente com este. --- [IMPLEMENTATION RECOMMENDATIONS & PITFALLS — ~2 minutes] Deixe-me apresentar-lhe as três coisas que mais frequentemente descarrilam as implementações móveis de 802.1X. Primeiro: falhas de confiança no certificado. Este é o principal gerador de pedidos de suporte. No iOS, se o certificado do servidor RADIUS não estiver incluído na lista de certificados fidedignos do perfil de WiFi, os utilizadores recebem um aviso de confiança na primeira ligação. No Android, se o certificado CA não estiver instalado, as versões modernas recusar-se-ão a ligar ou mostrarão um aviso persistente. A solução é incluir sempre a cadeia de certificados completa — CA raiz e quaisquer CAs intermédias — nos seus perfis de MDM. Não dependa do repositório de confiança do sistema do dispositivo para a sua CA interna. Segundo: timeout e latência do RADIUS. Os dispositivos móveis são impacientes. Se o seu servidor RADIUS demorar mais de dois a três segundos a responder, tanto o iOS como o Android tentarão novamente e acabarão por falhar a ligação. Isto é particularmente agudo em ambientes de alta densidade — estádios, centros de conferências — onde centenas de dispositivos se estão a autenticar em simultâneo. Garanta que a sua infraestrutura RADIUS está dimensionada adequadamente, considere a implementação de servidores proxy RADIUS regionalmente e ajuste os seus parâmetros de repetição e timeout no WLC. Terceiro: incompatibilidade do método EAP. Isto parece óbvio, mas é surpreendentemente comum. O método EAP configurado no WLC deve corresponder ao que o servidor RADIUS está a anunciar, o qual deve corresponder ao que o perfil do cliente especifica. Uma incompatibilidade resulta numa falha de autenticação silenciosa com o mínimo de informação de diagnóstico. Valide sempre a negociação EAP completa utilizando uma captura de pacotes no servidor RADIUS durante os testes iniciais. No lado do MDM, a recomendação prática é utilizar a autenticação baseada em certificados para dispositivos corporativos e PEAP para cenários BYOD onde não é possível enviar certificados de cliente. Isto dá-lhe os benefícios de segurança do EAP-TLS onde mais importa, sem a sobrecarga de gestão de certificados para a cauda longa de dispositivos pessoais. --- [RAPID-FIRE Q&A — ~1 minute] Posso executar o 802.1X e um SSID de convidados na mesma infraestrutura? Absolutamente. Execute SSIDs separados — um WPA2/3-Enterprise para 802.1X, outro para acesso de convidados com um Captive Portal. A segmentação por VLAN mantém o tráfego isolado. Preciso de um servidor RADIUS local? Já não. Os serviços RADIUS na nuvem são maduros e fiáveis. Para locais com conectividade de internet pouco fiável, ainda vale a pena considerar uma instância RADIUS local como alternativa de recurso. E quanto aos dispositivos IoT que não suportam 802.1X? Utilize o MAC Authentication Bypass — MAB — para esses dispositivos e coloque-os numa VLAN restrita com regras de firewall. Não os permita no mesmo segmento que os seus dispositivos autenticados por 802.1X. O 802.1X é suficiente para a conformidade com o PCI DSS? É um controlo forte, mas o PCI DSS exige uma abordagem em camadas. O 802.1X aborda o controlo de acesso à rede; ainda precisa de encriptação, monitorização e segmentação para cumprir todos os requisitos. --- [SUMMARY & NEXT STEPS — ~1 minute] Para resumir: a autenticação 802.1X em dispositivos móveis é um padrão maduro e bem suportado que proporciona uma melhoria significativa de segurança em relação às redes com chaves pré-partilhadas. A complexidade de implementação é real, mas gerível com as ferramentas certas — especificamente, MDM para distribuição de perfis e um servidor RADIUS local ou na nuvem devidamente dimensionado. Os seus próximos passos imediatos: audite a sua infraestrutura sem fios atual para verificar a prontidão para WPA2-Enterprise, avalie a sua cobertura de MDM em toda a frota de dispositivos e decida o seu método EAP com base na sua capacidade de PKI. Se estiver a começar do zero, o PEAP-MSCHAPv2 com integração no Active Directory é o caminho mais rápido para uma implementação funcional. Se tiver MDM e PKI, avance diretamente para o EAP-TLS. Para uma leitura mais aprofundada, o guia de implementação do WPA3-Enterprise e os recursos da Purple sobre arquitetura de WiFi empresarial são excelentes passos seguintes. Obrigado por ouvir — encontramo-nos no próximo episódio. --- END OF SCRIPT