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. Falo hoje como um 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 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 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 a GDPR e os padrões de segurança de dados do NHS e, francamente, para qualquer organização que execute mais do que um punhado de pontos de acesso, é a arquitetura correta. Nos próximos dez minutos, vou guiar você 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á. [IMERSÃO TÉCNICA — aproximadamente 5 minutos] Certo, então a estrutura do 802.1X possui 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 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. Aqui está 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 Identidade de Solicitação EAP para o dispositivo. O dispositivo responde com sua identidade. O AP então encaminha isso para o servidor RADIUS, encapsulado em um pacote de Solicitação de Acesso RADIUS. O servidor RADIUS executa a autenticação - verificando as credenciais no Active Directory, em um repositório de certificados ou em qualquer backend de identidade que você tenha configurado - e envia de volta um Aceite de Acesso ou uma Rejeição de Acesso. Somente em caso de Aceite 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 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 distribuir 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 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 interna. É comum em ambientes Linux e onde você precisa oferecer suporte a backends de autenticação legados. O EAP-FAST foi desenvolvido pela Cisco como uma resposta às fraquezas do LEAP. Ele usa Credenciais de Acesso Protegido em vez de certificados. É relevante principalmente se você estiver em um ambiente predominantemente 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 - 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 WiFi em locais públicos onde você deseja uma integração segura e contínua sem um Captive Portal. Agora vamos falar sobre a configuração do RADIUS. Quer você esteja implantando 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 controladoras 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 - VLAN ID, 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 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. No lado do certificado, para PEAP e EAP-TLS, seu servidor RADIUS precisa de um certificado de servidor confiável por 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 por todos os principais sistemas operacionais. Se estiver usando uma CA interna, você precisa enviar 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 registro automático via Diretiva de Grupo para enviar certificados a 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 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 GUI para isso que leva cerca de dez minutos após o servidor RADIUS estar pronto. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS - aproximadamente 2 minutos] Certo, vamos falar sobre onde as implantações dão errado, porque é aqui que eu justifico minhas taxas de consultoria. O ponto de falha mais comum é a validação de certificados. Já vi organizações implantarem o PEAP-MSCHAPv2 corretamente no lado do servidor e, em seguida, deixarem os perfis do suplicante cliente configurados para aceitar qualquer certificado. Isso compromete totalmente o modelo de segurança. Cada perfil de suplicante - seja enviado 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 de segredos compartilhados do RADIUS. Já vi redes de produção funcionando com o segredo compartilhado definido como "radius" ou o padrão do fornecedor. 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 em uma programação. Terceiro: configuração incorreta de VLAN. A atribuição dinâmica de VLAN é poderosa - ela permite que você coloque 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 forem configurados corretamente, ou se as portas de tronco do switch não estiverem transportando as VLANs corretas, os dispositivos falharão ao se conectar ou cairão no segmento errado. Teste isso minuciosamente em um laboratório antes de implantar 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 status. 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 a Purple gerencia o lado dos convidados com seu próprio Captive Portal e camada de análise, 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 isso. 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 contra LDAP, bancos de dados SQL, arquivos planos ou até mesmo APIs REST. Mas a integração com 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] Então, para resumir: o 802.1X não é apenas um recurso opcional. Para qualquer organização que lide com dados confidenciais, processe pagamentos ou opere em um ambiente regulamentado, ele é a linha de base para a segurança do 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 precisar de resultados rápidos e ampla compatibilidade, EAP-TLS se você tiver a infraestrutura de PKI e precisar do nível de segurança mais forte. Configure seu servidor RADIUS e garanta sua redundância antes de tocar em um único AP. Envie seus perfis de suplicante via Diretiva de Grupo ou MDM antes de entrar em operação. E mantenha o seu WiFi para 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 enviado por MDM em toda a sua frota de dispositivos. Obrigado por nos ouvir. O guia escrito completo, os diagramas de arquitetura e os checklists de configuração estão disponíveis em purple.ai. Se você está planejando uma implantação 802.1X e deseja discutir as especificidades do seu ambiente, entre em contato diretamente com a equipe da Purple.