Implementando Autenticação 802.1X em Dispositivos Móveis

ROTEIRO DE PODCAST: Implementando Autenticação 802.1X em Dispositivos Móveis Duração: ~10 minutos | Voz: Inglês britânico, masculino, tom de consultor sênior Estrutura: Introdução e Contexto (1 min) → Imersão Técnica (5 min) → Recomendações de Implementação e Erros Comuns (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 corporativos - a autenticação 802.1X em dispositivos móveis. Se você gerencia uma rede de hotel, um complexo de varejo, um estádio ou qualquer local do setor público onde funcionários e convidados se conectam em iPhones e aparelhos Android, este é o padrão que você precisa entender perfeitamente. O 802.1X não é novo. Tem sido a espinha dorsal da segurança sem fio corporativa por mais de duas décadas. Mas os dispositivos móveis mudaram significativamente o cenário de implementação. O gerenciamento de certificados, a seleção do método EAP, os fluxos de trabalho de provisionamento de MDM - todas essas são áreas onde os projetos costumam falhar e onde acertar oferece uma melhora operacional e de segurança muito significativa. Então, vamos analisar a arquitetura, as etapas de implementação para Apple e Android, e os modos de falha comuns que custam semanas de solução de problemas às equipes. --- [IMERSÃO TÉCNICA - ~5 minutos] Vamos começar com os fundamentos. O IEEE 802.1X é um padrão de controle de acesso à rede baseado em porta. Ele define três papéis: o suplicante - que é o seu dispositivo móvel -, o autenticador, que normalmente é o seu ponto de acesso sem fio ou controlador de LAN sem fio, e o servidor de autenticação, quase sempre um servidor RADIUS. Quando um dispositivo tenta se conectar a um SSID protegido por 802.1X, o ponto de acesso não concede acesso total à rede imediatamente. Em vez disso, ele abre uma porta controlada e inicia uma troca EAP - que é o Extensible Authentication Protocol. O dispositivo apresenta credenciais, o ponto de acesso as retransmite para o servidor RADIUS e o servidor RADIUS aceita ou rejeita a conexão. Somente após a aceitação o ponto de acesso abre a porta não controlada e permite o tráfego total de rede. Agora, o método EAP que você escolhe é crítico, e é aqui que as implantações móveis divergem das redes corporativas tradicionais centradas em notebooks. O EAP-TLS é o padrão ouro. Ele usa autenticação mútua baseada em certificados - tanto o servidor quanto o cliente apresentam certificados. Não há nome de usuário ou senha na troca. É resistente a phishing de credenciais, ataques de man-in-the-middle e força bruta. Tanto o iOS quanto o Android oferecem suporte nativo. O desafio é o gerenciamento do ciclo de vida dos certificados - você precisa de uma PKI funcional e precisa instalar os certificados de cliente nos dispositivos, o que significa que o MDM é essencialmente obrigatório. PEAP com MSCHAPv2 é o método mais amplamente implantado na prática. Ele envolve o MSCHAPv2 dentro de um túnel TLS, para que as credenciais fiquem protegidas em trânsito. O iOS e o Android oferecem suporte nativo a ele. A desvantagem é que ele depende de nome de usuário e senha, o que introduz uma sobrecarga de gerenciamento de credenciais e risco de exposição se o certificado do servidor não for validado corretamente no lado do cliente. O EAP-TTLS com PAP é comum em ambientes com diretórios LDAP herdados. O Android oferece suporte nativo; o iOS exige um perfil de configuração. Vale notar que o PAP transmite a senha em texto limpo dentro do túnel TLS, portanto, a integridade do túnel é tudo aqui. O EAP-FAST é focado principalmente em ambientes Cisco. O iOS oferece suporte nativo; o suporte para Android é inconsistente entre fabricantes e versões do SO. Para a maioria das implantações móveis corporativas atuais, a recomendação é o EAP-TLS onde você tem cobertura de MDM, e PEAP-MSCHAPv2 onde não tem - com validação estrita de certificado de servidor aplicada. Agora vamos falar sobre o lado da infraestrutura. O seu servidor RADIUS é o coração da implantação. Microsoft NPS, FreeRADIUS, Cisco ISE e Aruba ClearPass são as principais opções. Para implantações nativas em nuvem, JumpCloud, Foxpass e Portnox oferecem RADIUS-as-a-Service, o que elimina a sobrecarga da infraestrutura local. Seu servidor RADIUS precisa ser configurado com o método EAP correto, o segredo compartilhado para cada ponto de acesso ou WLC, e o armazenamento de usuários - seja ele Active Directory, LDAP ou um banco de dados local. Para o EAP-TLS, ele também precisa da cadeia de certificados da CA para validar os certificados de cliente. No lado da autoridade certificadora, você tem três opções. Uma PKI interna usando Microsoft ADCS ou uma CA independente oferece controle total e custo zero de certificado, mas exige maturidade operacional para gerenciar. Um serviço de PKI em nuvem - SCEPman, Smallstep ou similar - se integra bem com plataformas de MDM modernas e reduz significativamente a sobrecarga operacional. Certificados públicos de uma CA comercial são raramente usados para autenticação de cliente devido ao custo e à complexidade. Agora, a configuração do dispositivo. No iOS, o caminho de implantação mais limpo é o Apple Configurator ou uma plataforma de MDM como Jamf, Microsoft Intune ou Mosyle. Você envia um perfil de configuração de WiFi que especifica o SSID, o método EAP, o certificado do servidor em que confiar e - para o EAP-TLS - o certificado do cliente. O perfil lida com tudo de forma silenciosa. Os usuários se conectam sem nenhuma etapa manual. A configuração manual no iOS é possível, mas frágil. Os usuários navegam até Ajustes, WiFi, tocam no SSID, inserem as credenciais e recebem uma solicitação de confiança de certificado. Se o certificado do servidor não for de uma CA confiável, o iOS exibirá um aviso. Os usuários costumam tocar em "Confiar" sem ler, o que anula completamente o propósito da validação do certificado. É por isso que o provisionamento por MDM não é opcional para implantações sérias. No Android, a situação é mais fragmentada. O Android 11 e versões posteriores exigem que um certificado CA seja especificado ao conectar a uma rede 802.1X - você não pode mais selecionar "Não validar" no Android moderno sem um aviso. Esta é uma mudança de segurança positiva, mas significa que você precisa distribuir seu certificado CA para 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 apresenta peculiaridades específicas de cada fabricante. Dispositivos Samsung rodando One UI têm um manuseio de certificados ligeiramente diferente do Android padrão. Alguns dispositivos Huawei mais antigos apresentam problemas de compatibilidade EAP-TLS com suítes de criptografia específicas. Testar em toda a sua população de dispositivos de destino antes do lançamento é inegociável. Para a infraestrutura sem fio, seus pontos de acesso ou WLC precisam ser configurados com o SSID definido como WPA2-Enterprise ou WPA3-Enterprise, o IP do servidor RADIUS e o segredo compartilhado, e - de forma crítica - a contabilidade RADIUS se você deseja visibilidade de sessão por usuário. O WPA3-Enterprise com modo de 192 bits é a melhor prática atual para ambientes de alta segurança e combina muito bem com o EAP-TLS. Se você ainda não está planejando sua migração para o WPA3, vale a pena ler o guia sobre a implementação do WPA3-Enterprise para segurança sem fio aprimorada junto com este. - [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS - ~2 minutos] Deixe-me apresentar as três coisas que mais comumente atrapalham as implantações móveis de 802.1X. Primeiro: falhas de confiança de certificado. Este é o gerador número um de chamados de suporte. No iOS, se o certificado do servidor RADIUS não estiver incluído na lista de certificados confiáveis do perfil de WiFi, os usuários recebem um aviso de confiança na primeira conexão. No Android, se o certificado CA não estiver instalado, as versões modernas se recusarão a conectar ou exibirão um aviso persistente. A solução é sempre incluir a cadeia de certificados completa - CA raiz e quaisquer CAs intermediárias - em seus perfis de MDM. Não dependa do armazenamento de confiança do sistema do dispositivo para sua CA interna. Segundo: tempo limite 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 para responder, tanto o iOS quanto o Android tentarão novamente e, eventualmente, falharão na conexão. Isso é particularmente agudo em ambientes de alta densidade - estádios, centros de conferências - onde centenas de dispositivos estão se autenticando simultaneamente. Certifique-se de que sua infraestrutura RADIUS esteja dimensionada adequadamente, considere implantar servidores proxy RADIUS regionalmente e ajuste seus parâmetros de repetição e tempo limite na WLC. Terceiro: incompatibilidade do método EAP. Isso parece óbvio, mas é surpreendentemente comum. O método EAP configurado na WLC deve corresponder ao que o servidor RADIUS está anunciando, que por sua vez deve corresponder ao que o perfil do cliente especifica. Uma incompatibilidade resulta em falha de autenticação silenciosa com saída de diagnóstico mínima. Sempre valide a negociação EAP completa usando uma captura de pacotes no servidor RADIUS durante os testes iniciais. Do lado do MDM, a recomendação prática é usar autenticação baseada em certificado para dispositivos da empresa e PEAP para cenários de BYOD onde você não pode implantar certificados de cliente. Isso oferece os benefícios de segurança do EAP-TLS onde é mais importante, sem a complexidade de gerenciamento de certificados para a grande massa de dispositivos pessoais. - [PERGUNTAS E RESPOSTAS RÁPIDAS - ~1 minuto] Posso executar o 802.1X e um SSID de visitante na mesma infraestrutura? Com certeza. Execute SSIDs separados - um WPA2/3-Enterprise para 802.1X e um para acesso de visitantes com um Captive Portal. A segmentação de VLAN mantém o tráfego isolado. Preciso de um servidor RADIUS local? Não mais. Os serviços de RADIUS em nuvem são maduros e confiáveis. Para locais com conectividade de internet instável, uma instância local de RADIUS como backup ainda é uma opção a ser considerada. E quanto aos dispositivos IoT que não suportam 802.1X? Use o MAC Authentication Bypass - MAB - para esses dispositivos e coloque-os em uma VLAN restrita com regras de firewall. Não permita que eles entrem no mesmo segmento que os seus dispositivos autenticados por 802.1X. O 802.1X é suficiente para a conformidade com o PCI-DSS? É um controle forte, mas o PCI-DSS exige uma abordagem em camadas. O 802.1X aborda o controle de acesso à rede; você ainda precisa de criptografia, monitoramento e segmentação para atender a todos os requisitos. - [RESUMO E PRÓXIMOS PASSOS - ~1 minuto] Para resumir tudo: a autenticação 802.1X em dispositivos móveis é um padrão maduro e amplamente suportado que oferece uma melhoria de segurança significativa em relação às redes com chaves pré-compartilhadas. A complexidade de implementação existe, mas é gerenciável com as ferramentas certas - especificamente, MDM para distribuição de perfis e um servidor RADIUS em nuvem ou local devidamente dimensionado. Seus próximos passos imediatos: audite sua infraestrutura sem fio atual para verificar a compatibilidade com WPA2-Enterprise, avalie a cobertura do seu MDM em todo o parque de dispositivos e decida o método EAP com base na sua capacidade de PKI. Se estiver começando do zero, o PEAP-MSCHAPv2 com integração ao Active Directory é o caminho mais rápido para uma implantação funcional. Se você possui MDM e PKI, vá direto 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 corporativo são ótimos próximos passos. Obrigado por ouvir - nos vemos no próximo episódio. - FIM DO ROTEIRO