Como configurar a autenticação WiFi 802.1X: um guia passo a passo

Como Configurar a Autenticação WiFi 802.1X: Um Guia Passo a Passo Um Podcast da Purple Enterprise WiFi Intelligence [INTRODUÇÃO — aproximadamente 1 minuto] Seja bem-vindo de volta. Estou falando hoje como arquiteto de soluções sênior e, se você está ouvindo isso, provavelmente está encarando um projeto de segurança de rede que envolve a autenticação 802.1X — seja porque sua equipe de conformidade sinalizou isso, sua seguradora perguntou a respeito ou você acabou de herdar uma rede que funciona com um PSK compartilhado e sabe que isso não é mais suficiente. Então, vamos direto ao assunto. O 802.1X é o padrão IEEE para controle de acesso à rede baseado em porta. É a espinha dorsal da segurança de WiFi corporativa — o mecanismo que garante que cada dispositivo que se conecta à sua rede seja positivamente identificado e autorizado antes de passar um único byte de tráfego. Isso não é opcional para organizações que lidam com dados de cartões de pagamento sob o PCI DSS, não é opcional para ambientes de saúde sob a GDPR e os padrões de segurança de dados do NHS e, francamente, para qualquer organização que opere mais do que um punhado de pontos de acesso, é a arquitetura correta. Nos próximos dez minutos, vou orientá-lo pela arquitetura técnica, pela configuração do RADIUS, pela implantação de certificados e pelos cenários do mundo real onde isso se complica. Vamos lá. [APROFUNDAMENTO TÉCNICO — aproximadamente 5 minutos] Certo, então a estrutura do 802.1X tem três componentes. Você tem o Suplicante — que é o dispositivo cliente, o laptop, o telefone, o sensor de IoT. Você tem o Autenticador — que é o seu ponto de acesso ou switch de rede, às vezes chamado de NAS, o Network Access Server. E você tem o Servidor de Autenticação — quase universalmente um servidor RADIUS em implantações corporativas. É assim que o handshake funciona. Quando um dispositivo tenta se conectar a um SSID protegido por 802.1X, o ponto de acesso não apenas permite a entrada. Em vez disso, ele abre o que é chamado de porta controlada — um canal limitado que só passa tráfego EAP, o Extensible Authentication Protocol. O AP envia uma solicitação de identidade EAP (EAP-Request Identity) para o dispositivo. O dispositivo responde com sua identidade. O AP então encaminha isso para o servidor RADIUS, empacotado em um pacote RADIUS Access-Request. O servidor RADIUS executa a autenticação — verificando as credenciais no Active Directory, em um repositório de certificados ou em qualquer back-end de identidade que você tenha configurado — e envia de volta um Access-Accept ou um Access-Reject. Somente após um Accept o AP abre a porta de dados completa e atribui o dispositivo à VLAN apropriada. Agora, o método EAP que você escolhe aqui importa enormemente. Existem cinco que você encontrará em implantações corporativas. O EAP-TLS é o padrão-ouro. Tanto o cliente quanto o servidor apresentam certificados X.509. Não há senhas envolvidas. É a opção mais segura e a exigida para os níveis mais altos de conformidade com o PCI DSS. O detalhe é que você precisa de uma PKI completa — uma Infraestrutura de Chaves Públicas — para emitir e gerenciar certificados de cliente. Isso significa uma Autoridade Certificadora, gerenciamento do ciclo de vida dos certificados e um mecanismo para enviar os certificados para cada dispositivo. Para organizações com o Microsoft Active Directory e o Active Directory Certificate Services, isso é totalmente viável. Para organizações sem essa infraestrutura, representa um investimento significativo. O PEAP-MSCHAPv2 é o método mais amplamente implantado na prática. Ele cria um túnel TLS usando apenas um certificado do lado do servidor e, em seguida, transmite as credenciais de usuário e senha dentro desse túnel. É compatível com praticamente todos os dispositivos prontos para uso, integra-se diretamente com o Active Directory via NPS no Windows Server e não requer certificados de cliente. O ponto negativo é que ele é vulnerável a ataques de coleta de credenciais se os usuários forem induzidos a se conectar a um AP invasor — porque o cliente não valida o certificado do servidor por padrão. Você deve impor a validação do certificado do servidor em seus perfis de suplicante. O EAP-TTLS é semelhante ao PEAP, mas mais flexível no método de autenticação interno. É comum em ambientes Linux e onde você precisa oferecer suporte a backends de autenticação legados. O EAP-FAST foi desenvolvido pela Cisco em resposta às vulnerabilidades do LEAP. Ele usa Credenciais de Acesso Protegido em vez de certificados. É relevante principalmente se você estiver em um ambiente focado em Cisco ou lidando com dispositivos legados que não suportam os outros métodos. O EAP-SIM e o EAP-AKA são usados em implantações de nível de operadora — pense em OpenRoaming ou Passpoint — onde a autenticação está vinculada a um cartão SIM ou USIM. Estes são cada vez mais relevantes para WiFi em locais públicos, onde você deseja um onboarding contínuo e seguro sem um Captive Portal. Agora vamos falar sobre a configuração do RADIUS. Quer você esteja implantando o Microsoft NPS, FreeRADIUS, Cisco ISE ou Aruba ClearPass, as etapas principais de configuração são as mesmas. Primeiro, você define seus clientes RADIUS — estes são seus pontos de acesso ou controladores de LAN sem fio. Cada cliente é registrado com seu endereço IP e um segredo compartilhado. Esse segredo compartilhado é usado para autenticar as mensagens RADIUS entre o AP e o servidor. Use um mínimo de 22 caracteres, gerados aleatoriamente e exclusivos por dispositivo NAS. Segundo, você configura sua política de rede. É aqui que você define quem tem acesso a quê. Em termos de NPS, você está criando uma Política de Rede que corresponde a condições — associação a grupos no Active Directory, tipo de dispositivo, hora do dia — e atribui atributos — ID de VLAN, limite de tempo de sessão, limites de largura de banda. O atributo RADIUS que você mais usará é a atribuição de VLAN, especificamente Tunnel-Type definido como VLAN, Tunnel-Medium-Type definido como 802 e Tunnel-Private-Group-ID definido como o número da sua VLAN. Terceiro, você configura sua política de solicitação de conexão. Isso informa ao NPS como lidar com as solicitações RADIUS recebidas — se deve autenticar localmente ou encaminhar para outro servidor RADIUS. Em uma implantação distribuída, você pode ter um servidor RADIUS central com proxies NPS em cada localidade. No lado do certificado, para PEAP e EAP-TLS, seu servidor RADIUS precisa de um certificado de servidor confiável para seus clientes. O caminho mais simples é usar um certificado de uma CA pública — DigiCert, Sectigo, Let's Encrypt — porque esses certificados raiz já são confiáveis para todos os principais sistemas operacionais. Se você estiver usando uma CA interna, precisará enviar o certificado raiz para todos os dispositivos clientes via Diretiva de Grupo ou sua plataforma de MDM. Especificamente para EAP-TLS, você também precisa de certificados de cliente. Em um ambiente Active Directory, você usaria o ADCS com inscrição automática via Diretiva de Grupo para enviar certificados para dispositivos ingressados no domínio. Para dispositivos BYOD, você usaria seu MDM — Intune, Jamf, VMware Workspace ONE — para enviar tanto o certificado quanto o perfil de WiFi. No lado do ponto de acesso, a configuração é simples. Você cria um novo SSID, define a segurança como WPA2-Enterprise ou WPA3-Enterprise, aponta o servidor de autenticação RADIUS para o IP do seu NPS na porta UDP 1812, define o servidor de contabilidade RADIUS na porta UDP 1813, insere o segredo compartilhado e ativa a atribuição de VLAN dinâmica se estiver usando-a. A maioria das plataformas de AP corporativas — Cisco Meraki, Aruba, Ruckus, Extreme — possui uma GUI para isso que leva cerca de dez minutos após o servidor RADIUS estar pronto. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS — aproximadamente 2 minutos] Certo, vamos falar sobre onde as implantações costumam falhar, porque é aqui que eu justifico meus honorários de consultoria. O ponto de falha mais comum é a validação de certificado. Já vi organizações implantarem o PEAP-MSCHAPv2 corretamente no lado do servidor e, em seguida, deixarem os perfis de suplicantes dos clientes configurados para aceitar qualquer certificado. Isso compromete totalmente o modelo de segurança. Todo perfil de suplicante — seja enviado via Diretiva de Grupo ou MDM — deve especificar a CA raiz confiável e o nome de servidor esperado. Sem isso, você fica vulnerável a ataques de evil twin (clone malicioso). O segundo problema comum é o gerenciamento do segredo compartilhado do RADIUS. Já vi redes de produção rodando com o segredo compartilhado definido como "radius" ou com o padrão do fabricante. Esses segredos são as chaves para a sua infraestrutura de autenticação. Gere-os aleatoriamente, armazene-os em um gerenciador de segredos e faça a rotação deles periodicamente. Terceiro: configuração incorreta de VLAN. A atribuição de VLAN dinâmica é poderosa — ela permite colocar os dispositivos dos funcionários na VLAN corporativa, prestadores de serviço em uma VLAN restrita e dispositivos de IoT em uma VLAN isolada, tudo a partir do mesmo SSID. Mas se os atributos RADIUS não forem configurados corretamente ou se as portas de tronco do switch não estiverem transportando as VLANs corretas, os dispositivos falharão na conexão ou cairão no segmento errado. Teste isso minuciosamente em laboratório antes de colocar em produção. Quarto: redundância. Seu servidor RADIUS agora é uma peça crítica de infraestrutura. Se ele cair, ninguém se conecta. Você precisa de, no mínimo, um servidor RADIUS primário e um secundário configurados em cada AP. Em grandes implantações, considere clusters de proxy RADIUS com monitoramento de integridade. Quinto, e isso é específico para ambientes de hotelaria e varejo: separação entre rede de convidados e corporativa. Seu SSID corporativo 802.1X e seu SSID de WiFi de convidados devem ser completamente separados — VLANs diferentes, políticas de firewall diferentes, DNS diferente. Uma plataforma como a Purple gerencia o lado dos convidados com seu próprio Captive Portal e camada de analytics, enquanto sua infraestrutura 802.1X gerencia o lado corporativo. Esses são sistemas complementares, não concorrentes. [PERGUNTAS E RESPOSTAS RÁPIDAS — aproximadamente 1 minuto] Deixe-me passar pelas perguntas que recebo com mais frequência. Posso executar o 802.1X em uma plataforma de AP gerenciada na nuvem? Sim — Meraki, Aruba Central e Ruckus Cloud suportam essa função. Você configura os detalhes do servidor RADIUS no painel da nuvem, e os APs cuidam do proxying EAP. Preciso de Active Directory? Não. O FreeRADIUS pode autenticar em LDAP, bancos de dados SQL, arquivos simples ou até mesmo APIs REST. Mas a integração AD via NPS é, de longe, o caminho corporativo mais comum. E quanto aos dispositivos IoT que não suportam 802.1X? Use o MAC Authentication Bypass — MAB — como alternativa. O endereço MAC do dispositivo é enviado ao RADIUS como nome de usuário e senha. Não é tão seguro quanto o EAP, mas permite integrar dispositivos IoT mantendo-os em uma VLAN restrita. O 802.1X funciona com WPA3? Sim. O WPA3-Enterprise é essencialmente o WPA3 com autenticação 802.1X. Ele adiciona uma criptografia mais forte — 192 bits no modo de alta segurança — e é o padrão recomendado para novas implantações. [RESUMO E PRÓXIMOS PASSOS — aproximadamente 1 minuto] Para resumir: o 802.1X não é um recurso opcional. Para qualquer organização que lide com dados confidenciais, processe pagamentos ou opere em um ambiente regulamentado, ele é a base para a segurança de WiFi corporativo. A arquitetura está bem estabelecida, o ferramental está maduro e o caminho de implantação é claro. Comece com a seleção do seu método EAP — PEAP-MSCHAPv2 se você precisa de resultados rápidos e ampla compatibilidade, EAP-TLS se você tiver a infraestrutura de PKI e precisar do nível mais forte de segurança. Configure seu servidor RADIUS e garanta sua redundância antes de tocar em um único AP. Distribua seus perfis de suplicante via Diretiva de Grupo ou MDM antes de entrar em operação. E mantenha seu WiFi de convidados completamente separado — use uma plataforma dedicada para essa camada. Se você opera um ambiente com vários locais — hotéis, redes de varejo, estádios — a complexidade aumenta com o número de sites, mas a arquitetura não muda. A chave é o RADIUS centralizado com redundância local por site e um perfil de suplicante consistente distribuído via MDM em toda a sua frota de dispositivos. Obrigado por nos ouvir. O guia escrito completo, os diagramas de arquitetura e as listas de verificação de configuração estão disponíveis em purple.ai. Se você está planejando uma implantação do 802.1X e quer discutir as especificidades do seu ambiente, entre em contato diretamente com a equipe do Purple.