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

ROTEIRO DE PODCAST: Implementar a Autenticação 802.1X em Dispositivos Móveis Duração: ~10 minutos | Voz: Inglês do Reino Unido, masculino, tom de consultor sénior Estrutura: Introdução e Contexto (1 min) → Aprofundamento Técnico (5 min) → Recomendações de Implementação e Armadilhas (2 min) → Perguntas e Respostas Rápidas (1 min) → Resumo e Próximos Passos (1 min) --- [INTRODUÇÃO E CONTEXTO - ~1 minuto] Bem-vindo 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 funcionários e convidados se ligam em iPhones e telemóveis 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 durante mais de duas décadas. Mas os dispositivos móveis mudaram significativamente o cenário de implementação. A gestão de certificados, a seleção do método EAP, os fluxos de trabalho de provisionamento de MDM - estas são todas áreas onde os projetos correm mal, e onde acertar proporciona uma melhoria significativa ao nível operacional e de segurança. Por isso, vamos analisar a arquitetura, as etapas de implementação para Apple e Android, e os modos de falha comuns que custam semanas de resolução de problemas às equipas. --- [APROFUNDAMENTO TÉCNICO - ~5 minutos] Vamos começar com os 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 é normalmente o seu ponto de acesso sem fios ou controlador de rede 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 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 a totalidade do tráfego de rede. Ora, o método EAP que escolher é fundamental, 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 existe nome de utilizador ou palavra-passe na troca. É resistente a phishing de credenciais, ataques do tipo "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. Este encapsula o MSCHAPv2 dentro de um túnel TLS, garantindo que as credenciais fiquem protegidas em trânsito. O iOS e o Android suportam-no nativamente. A desvantagem é que depende de nome de utilizador e palavra-passe, o que introduz custos adicionais 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-o nativamente; o iOS requer um perfil de configuração. Vale a pena notar que o PAP transmite a palavra-passe em texto limpo dentro do túnel TLS, pelo que a integridade do túnel aqui é tudo. O EAP-FAST é essencialmente uma solução Cisco. O iOS suporta-o nativamente; o suporte para 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 validação rigorosa 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 elimina a carga da infraestrutura local. O seu servidor RADIUS precisa de ser configurado com o método EAP correto, o segredo partilhado para cada ponto de acesso ou WLC, e o repositório de utilizadores - quer seja Active Directory, LDAP ou uma base de dados local. Para o EAP-TLS, também necessita da cadeia de certificados da CA para validar os certificados de cliente. No lado da autoridade de certificação, tem três opções. Uma PKI interna que utilize o Microsoft ADCS ou uma CA autónoma oferece-lhe controlo total e custo zero de certificado, mas exige maturidade operacional para gerir. Um serviço de PKI na nuvem - SCEPman, Smallstep ou semelhante - integra-se bem com plataformas de MDM modernas e reduz significativamente a carga 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. O utilizador envia um perfil de configuração WiFi que especifica o SSID, o método EAP, o certificado do servidor em que deve confiar e - para o EAP-TLS - o certificado de 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, é apresentada uma solicitação de confiança de 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 objetivo da validação do certificado. É por isso que o provisionamento via MDM não é opcional para implementações sérias. No Android, o cenário é mais fragmentado. O Android 11 e versões posteriores exigem a especificação de um certificado CA 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 pelos 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 um processamento de certificados ligeiramente diferente do Android padrão. Alguns dispositivos Huawei mais antigos apresentam problemas de compatibilidade EAP-TLS com pacotes de cifras específicos. Testar em toda a sua população de dispositivos de destino antes do lançamento é inegociável. Para a infraestrutura sem fios, os seus pontos de acesso ou WLC precisam de ser configurados com o SSID definido para WPA2-Enterprise ou WPA3-Enterprise, o IP do servidor RADIUS e o segredo partilhado e, fundamentalmente, a contabilidade RADIUS se pretender visibilidade da sessão por utilizador. O WPA3-Enterprise com modo de 192 bits é a melhor prática atual para ambientes de alta segurança e funciona muito 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 segurança sem fios reforçada em conjunto com este. - [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS - ~2 minutos] Deixe-me apresentar-lhe as três coisas que mais frequentemente descarrilam as implementações móveis de 802.1X. Primeira: falhas de confiança no certificado. Este é o gerador número um 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 recusam a ligação ou mostram um aviso persistente. A solução consiste em incluir sempre a cadeia de certificados completa - CA raiz e quaisquer CAs intermediárias - nos seus perfis MDM. Não dependa do repositório de confiança do sistema do dispositivo para a sua CA interna. Segunda: limite de tempo e latência do RADIUS. Os dispositivos móveis são impacientes. Se o seu servidor RADIUS demorar mais do que dois a três segundos a responder, tanto o iOS como o Android vão tentar novamente e, eventualmente, falhar a ligação. Isto é particularmente agudo em ambientes de alta densidade - estádios, centros de conferências - onde centenas de dispositivos se autenticam em simultâneo. Garanta que a sua infraestrutura RADIUS está dimensionada adequadamente, considere implementar servidores proxy RADIUS regionalmente e ajuste os seus parâmetros de tentativa e limite de tempo na WLC. Terceira: incompatibilidade do método EAP. Parece óbvio, mas é surpreendentemente comum. O método EAP configurado na 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 um output de diagnóstico mínimo. Valide sempre a negociação EAP completa utilizando uma captura de pacotes no servidor RADIUS durante os testes iniciais. Do lado do MDM, a recomendação prática é utilizar a autenticação baseada em certificados para dispositivos corporativos e PEAP para cenários de BYOD onde não é possível implementar certificados de cliente. Isto oferece os benefícios de segurança do EAP-TLS onde é mais importante, sem a sobrecarga de gestão de certificados para a longa cauda de dispositivos pessoais. - [PERGUNTAS E RESPOSTAS RÁPIDAS - ~1 minuto] Posso executar o 802.1X e um SSID de convidado na mesma infraestrutura? Absolutamente. Execute SSIDs separados - um WPA2/3-Enterprise para 802.1X, um para acesso de convidados com um Captive Portal. A segmentação de VLAN mantém o tráfego isolado. Preciso de um servidor RADIUS no local? Já não. Os serviços RADIUS na nuvem são maduros e fiáveis. Para locais com conectividade de internet instável, uma instância RADIUS local como alternativa ainda vale a pena considerar. E quanto aos dispositivos IoT que não suportam 802.1X? Utilize o bypass de autenticação MAC - MAB - para esses dispositivos e coloque-os numa VLAN restrita com regras de firewall. Não permita que entrem 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. - [RESUMO E PRÓXIMOS PASSOS - ~1 minuto] 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 a redes com chaves pré-partilhadas. A complexidade da implementação é real, mas gerível com as ferramentas certas - especificamente, MDM para distribuição de perfis e um servidor RADIUS na nuvem ou no local devidamente dimensionado. Os seus próximos passos imediatos: audite a sua infraestrutura wireless atual para verificar a prontidão para WPA2-Enterprise, avalie a cobertura do seu MDM em todo o parque de dispositivos e decida sobre 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 do 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 WiFi empresarial são excelentes próximos passos. Obrigado por ouvir - encontramo-nos no próximo episódio. - FIM DO ROTEIRO