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] Bem-vindo de volta. Estou falando hoje como arquiteto de soluções sênior e, se você está ouvindo isso, provavelmente está diante de um projeto de segurança de rede que envolve 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 está rodando em 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 corporativo - o mecanismo que garante que cada dispositivo conectado à sua rede seja positivamente identificado e autorizado antes de receber 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 o GDPR e 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 orientar você pela arquitetura técnica, pela configuração de RADIUS, pela implantação de certificados e pelos cenários do mundo real onde isso se complica. Vamos lá. [MERGULHO TÉCNICO PROFUNDO — aproximadamente 5 minutos] Certo, então a estrutura do 802.1X possui três componentes. Você tem o Solicitante (Supplicant) - que é o dispositivo cliente, o laptop, o telefone, o sensor IoT. Você tem o Autenticador - que é o seu ponto de acesso ou o seu switch de rede, às vezes chamado de NAS, o Servidor de Acesso à Rede. E você tem o Servidor de Autenticação - quase universalmente um servidor RADIUS em implantações corporativas. Veja como funciona o handshake. 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 passa apenas tráfego EAP, o Protocolo de Autenticação Extensível. O AP envia uma solicitação de identidade EAP (EAP-Request Identity) ao dispositivo. O dispositivo responde com sua identidade. O AP então encaminha isso para o servidor RADIUS, encapsulado 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ê configurou - e envia de volta um Access-Accept ou um Access-Reject. Somente no caso de 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 porém é 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 Microsoft Active Directory e 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, passa as credenciais de nome de usuário e senha dentro desse túnel. É compatível com praticamente todos os dispositivos de fábrica, integra-se diretamente com o Active Directory via NPS no Windows Server e não exige certificados de cliente. A desvantagem é que ele é vulnerável a ataques de captura 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 possui mais flexibilidade no método interno de autenticação. É comum em ambientes Linux e onde você precisa oferecer suporte a back-ends de autenticação herdados. O EAP-FAST foi desenvolvido pela Cisco como uma resposta às fraquezas do LEAP. Ele usa credenciais de acesso protegido (Protected Access Credentials) em vez de certificados. É relevante principalmente se você estiver em um ambiente focado em Cisco ou lidando com dispositivos herdados que não oferecem suporte aos outros métodos. O EAP-SIM e o EAP-AKA são usados em implantações de nível de operadora - como OpenRoaming ou Passpoint - onde a autenticação está vinculada a um cartão SIM ou USIM. Estes são cada vez mais relevantes para redes WiFi de locais públicos onde você deseja uma integração segura e contínua sem a necessidade de um Captive Portal. Agora vamos falar sobre a configuração do RADIUS. Independentemente de você estar 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 - que 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 no mínimo 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 de grupo no Active Directory, tipo de dispositivo, hora do dia - e atribui atributos - ID de VLAN, tempo limite 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 com o número da sua VLAN. Terceiro, você configura a sua política de solicitação de conexão. Isso informa ao NPS como lidar com as solicitações RADIUS recebidas - se devem ser autenticadas localmente ou encaminhadas para outro servidor RADIUS. Em uma implantação distribuída, você pode ter um servidor RADIUS central com proxies NPS em cada site. Do 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 estiver usando uma CA interna, você precisará distribuir o certificado raiz para todos os dispositivos clientes via Diretiva de Grupo ou sua plataforma MDM. Especificamente para EAP-TLS, você também precisa de certificados de cliente. Em um ambiente Active Directory, você usaria o ADCS com auto-registro via Diretiva de Grupo para distribuir certificados para dispositivos ingressados no domínio. Para dispositivos BYOD, você usaria seu MDM - Intune, Jamf, VMware Workspace ONE - para distribuir tanto o certificado quanto o perfil de WiFi. Do 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 tarifação RADIUS na porta UDP 1813, insere o segredo compartilhado e habilita a atribuição dinâmica de VLAN se estiver usando. A maioria das plataformas de AP corporativas - Cisco Meraki, Aruba, Ruckus, Extreme - possui uma interface gráfica 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 dar errado, pois é aqui que eu justifico meus honorários de consultoria. O ponto de falha mais comum é a validação do certificado. Já vi organizações implantarem o PEAP-MSCHAPv2 corretamente no lado do servidor, mas deixarem os perfis de suplicantes dos clientes configurados para aceitar qualquer certificado. Isso compromete totalmente o modelo de segurança. Cada perfil de suplicante - seja distribuído via Diretiva de Grupo ou MDM - deve especificar a CA raiz confiável e o nome do servidor esperado. Sem isso, você fica vulnerável a ataques de evil twin. O segundo problema comum é o gerenciamento do segredo compartilhado RADIUS. Já vi redes de produção rodando com o segredo compartilhado definido como "radius" ou o padrão do fabricante. Esses segredos são as chaves da 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 dinâmica de VLAN é poderosa - ela permite colocar dispositivos de funcionários na VLAN corporativa, prestadores de serviços em uma VLAN restrita e dispositivos IoT em uma VLAN isolada, tudo a partir do mesmo SSID. Mas se os atributos RADIUS não estiverem configurados corretamente, ou se as portas de tronco dos switches não estiverem transportando as VLANs corretas, os dispositivos falharão ao conectar ou cairão no segmento errado. Teste isso minuciosamente em um 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 secundário configurado em cada AP. Em implantações de grande porte, considere clusters de proxy RADIUS com monitoramento de integridade. Quinto, e isso é específico para ambientes de hotelaria e varejo: separação entre convidados e corporativo. Seu SSID corporativo 802.1X e seu SSID de WiFi para convidados devem ser completamente separados - VLANs diferentes, políticas de firewall diferentes, DNS diferente. Uma plataforma como o Purple lida com o lado dos convidados com seu próprio Captive Portal e camada de análise, enquanto sua infraestrutura 802.1X lida com 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 oferecem suporte. Você configura os detalhes do servidor RADIUS no painel da nuvem, e os APs cuidam do proxy EAP. Preciso do 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 com 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 lida com dados confidenciais, processa pagamentos ou opera em um ambiente regulamentado, ele é a base para a segurança de WiFi empresarial. A arquitetura é bem estabelecida, as ferramentas são maduras e o caminho de implantação é claro. Comece com a seleção do método EAP - PEAP-MSCHAPv2 se precisar de resultados rápidos e ampla compatibilidade, EAP-TLS se tiver a infraestrutura de PKI e precisar de uma postura de segurança mais robusta. Configure seu servidor RADIUS e garanta a redundância antes de tocar em um único AP. Envie os perfis do solicitante via Diretiva de Grupo ou MDM antes de entrar em operação. E mantenha o 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 solicitante consistente enviado por MDM em toda a sua frota de dispositivos. Obrigado por 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 de 802.1X e quer discutir as especificidades do seu ambiente, entre em contato diretamente com a equipe da Purple.