O que é um Suplicante 802.1X? Tipos de Clientes e Configuração de Dispositivos

Fale em inglês britânico com um tom confiante, autoritativo e de conversação - como um consultor sênior de segurança de rede instruindo um cliente. Ritmo medido, dicção clara, profissional, mas não rígido. Pausas naturais ocasionais para ênfase: Bem-vindo à série de briefings técnicos da Purple. Hoje vamos cobrir algo que está bem no coração da segurança de WiFi corporativo - o suplicante 802.1X. Se você já se perguntou por que alguns dispositivos se conectam à sua rede corporativa sem solicitar senha, enquanto outros apresentam erros de certificado e chamados no suporte, este é o episódio para você. [pausa média] Vamos começar com o básico. O suplicante 802.1X é o componente de software em um dispositivo cliente - um laptop, um smartphone, um tablet - que lida com o handshake de autenticação quando esse dispositivo tenta ingressar em uma rede protegida pelo IEEE 802.1X. Pense nele como o apresentador do cartão de identidade do dispositivo. A rede não deixa qualquer um entrar. Ela pede credenciais. O suplicante é quem dá um passo à frente e diz: aqui está quem eu sou, aqui está meu certificado, deixe-me entrar. O próprio padrão - IEEE 802.1X - define o controle de acesso à rede baseado em porta. Antes que a autenticação ocorra com sucesso, o ponto de acesso ou switch permite apenas um tipo muito estreito de tráfego: quadros EAPOL, que significa Extensible Authentication Protocol over LAN. Todo o resto é bloqueado. Assim que o suplicante prova sua identidade ao servidor RADIUS através do autenticador, a porta se abre e o tráfego normal flui. [pausa média] Agora, existem três atores nesta peça. Primeiro, o suplicante - o dispositivo cliente. Segundo, o autenticador - seu ponto de acesso ou switch, hardware como Cisco Meraki, HPE Aruba, Ruckus ou Juniper Mist. Terceiro, o servidor de autenticação - quase sempre um servidor RADIUS, que valida as credenciais em um diretório como Microsoft Entra ID ou Okta. O suplicante inicia o processo enviando uma mensagem EAPOL-Start. O autenticador responde com um EAP-Request de identidade. O suplicante responde com sua identidade. Essa identidade é encaminhada para o servidor RADIUS, que então desafia o suplicante com o método EAP acordado. Se tudo estiver correto, o servidor RADIUS envia um Access-Accept, a porta se abre e o dispositivo é colocado na VLAN correta. [pausa média] Vamos falar sobre os métodos EAP, porque é aqui que a maioria das decisões de implantação são tomadas. EAP-TLS - ou seja, Extensible Authentication Protocol com Transport Layer Security - é o padrão ouro. Ele exige que tanto o cliente quanto o servidor apresentem certificados. Autenticação mútua. Sem senhas. O certificado do cliente comprova a identidade do dispositivo; o certificado do servidor comprova que a rede é legítima, o que protege contra ataques de evil twin onde um ponto de acesso invasor tenta capturar credenciais. O EAP-TLS é concluído em doze etapas e utiliza criptografia de chave pública-privada do início ao fim. É o método exigido para o WPA3-Enterprise em seu modo de segurança mais alto e alinha-se com os requisitos do NIST SP 800-171 para verificação de identidade de dispositivos. PEAP - Protected EAP - é o ponto de partida mais comum para organizações que ainda não possuem uma PKI completa implementada. O PEAP envolve um método interno baseado em senha, normalmente o MSCHAPv2, dentro de um túnel TLS. O servidor apresenta um certificado; o cliente não. Isso significa que a implantação é mais simples - você não precisa provisionar certificados de cliente - mas é menos segura. O MSCHAPv2 usa hash MD4, que é considerado comprometido desde 1995. Se um usuário se conectar a um ponto de acesso invasor que apresente um certificado de aparência confiável, suas credenciais poderão ser capturadas. A validação do certificado do servidor no lado do cliente é, portanto, inegociável ao executar o PEAP. [medium pause] Agora vamos entrar no suplicante em si - especificamente na escolha entre suplicantes nativos do sistema operacional e softwares de cliente de terceiros. Cada sistema operacional principal vem com um suplicante 802.1X integrado de fábrica. O Windows o suporta nativamente desde o XP, por meio dos serviços Wireless AutoConfig e Wired AutoConfig. O macOS e o iOS gerenciam o 802.1X por meio de seus perfis de configuração de rede. O Android o suporta por meio do painel de configurações de WiFi. Esses suplicantes nativos cobrem EAP-TLS e PEAP-MSCHAPv2 em todas as plataformas atuais. A vantagem dos suplicantes nativos é óbvia: nenhum software adicional para implantar, sem custo de licenciamento, atualizações automáticas de segurança do sistema operacional e forte integração com o repositório de certificados do sistema operacional. Para frotas de dispositivos gerenciados - máquinas Windows registradas no Microsoft Intune, Macs gerenciados pelo Jamf - você pode enviar perfis de configuração 802.1X silenciosamente via MDM, e os usuários nunca verão um aviso. O dispositivo se autentica automaticamente sempre que entra no raio de alcance. Supplicants de terceiros entram em jogo em cenários específicos. Se você estiver executando uma infraestrutura Cisco e quiser usar o EAP-FAST - o método EAP proprietário da Cisco - precisará do software cliente da Cisco, historicamente o Secure Services Client ou o AnyConnect Network Access Manager. Se você precisa de um gerenciamento de configuração consistente em um ambiente de sistema operacional misto e deseja bloquear as configurações do supplicant para que os usuários não as desconfigurem acidentalmente, um cliente de terceiros oferece esse controle. Ferramentas como o pacote JoinNow da SecureW2 também atuam como agentes de onboarding - elas configuram o supplicant nativo em vez de substituí-lo, orientando os usuários no registro de certificados e na instalação de perfis. [medium pause] Deixe-me orientar você por dois cenários do mundo real para tornar isso concreto. Primeiro, um hotel de 400 quartos. A propriedade opera hoje uma rede de funcionários em WPA2-Enterprise com PEAP-MSCHAPv2. A equipe de TI deseja migrar para EAP-TLS para eliminar a autenticação baseada em senha e reduzir o risco de roubo de credenciais. O desafio: os dispositivos dos funcionários são uma mistura de notebooks Windows gerenciados via Intune, celulares Android pessoais usados para o software de gerenciamento de propriedades e algumas máquinas antigas com Windows 7 na área administrativa. A abordagem aqui é em fases. Comece com a frota Windows gerenciada. Envie um perfil de configuração do Intune que instale o certificado CA raiz do servidor RADIUS, configure o perfil de WiFi para EAP-TLS e acione o registro de certificado baseado em SCEP a partir da PKI interna. Esses dispositivos se autenticam automaticamente desde o primeiro dia. Para dispositivos Android BYOD, implante um portal de onboarding de autoatendimento - os usuários visitam uma URL, baixam um perfil de configuração e o supplicant é configurado para eles. As máquinas herdadas com Windows 7 permanecem em PEAP com validação estrita de certificado de servidor aplicada, isoladas em uma VLAN separada com acesso limitado, até serem desativadas. [medium pause] Segundo cenário: uma grande rede de varejo com 200 lojas. Cada loja possui uma mistura de terminais de ponto de venda, tablets de funcionários e uma rede WiFi para convidados. O PCI DSS exige que os ambientes de dados de portadores de cartão sejam isolados de outros segmentos de rede. O varejista usa 802.1X nas redes de funcionários e PDV, com atribuição de VLAN orientada por atributos de certificado. Um terminal de PDV apresenta um certificado de dispositivo com uma unidade organizacional de "POS" - a política RADIUS o atribui à VLAN PCI. Um tablet de funcionário apresenta um certificado com "Staff" - ele cai na VLAN de funcionários. Os dispositivos de convidados se conectam a um SSID totalmente separado, gerenciado por uma solução de Captive Portal. A configuração do supplicant nos terminais de PDV é bloqueada via MDM. Nenhuma interação do usuário é necessária. Os terminais se autenticam silenciosamente na inicialização. A renovação de certificados é automatizada por meio de SCEP, portanto não há intervenção manual quando os certificados expiram. [medium pause] Agora, armadilhas de implementação. Deixe-me apresentar as quatro mais comuns. Número um: ausência de validação do certificado do servidor em implantações PEAP. Se você não configurar o supplicant para validar o certificado do servidor RADIUS e verificar o nome do servidor, os usuários ficarão vulneráveis à conexão com um ponto de acesso invasor (rogue). Sempre especifique a CA raiz confiável e o nome do servidor no perfil do supplicant. Número dois: expiração de certificado causando falhas massivas de autenticação. Os certificados de cliente têm um período de validade. Se você não tiver uma renovação automatizada configurada via SCEP ou NDES, enfrentará um evento crítico em que centenas de dispositivos param de autenticar simultaneamente. Desenvolva a automação de renovação antes de entrar em operação. Número três: dispositivos BYOD com comportamento inconsistente do supplicant. O Android, em particular, possui um suporte 802.1X fragmentado entre os fabricantes. Algumas versões exigem que o usuário instale manualmente o certificado CA antes que o perfil de WiFi o aceite. Um portal de integração (onboarding) que lida com essa etapa reduz significativamente o volume do helpdesk. Número quatro: atualizações de recursos do Windows 11 quebrando a configuração do supplicant. A Microsoft alterou o comportamento do 802.1X em várias atualizações do Windows 11. Especificamente, a atualização 24H2 introduziu mudanças na forma como o supplicant nativo lida com o fallback do EAP-TLS. Teste seus perfis de supplicant com novas versões do sistema operacional antes de implantá-los em produção. [medium pause] Perguntas rápidas agora. Os dispositivos IoT podem suportar 802.1X? A maioria não. Os dispositivos IoT normalmente carecem totalmente de um supplicant. A alternativa é o MAC Authentication Bypass - MAB - onde o servidor RADIUS autentica o dispositivo com base em seu endereço MAC. Os endereços MAC podem ser clonados (spoofed), portanto, os dispositivos MAB devem sempre ser direcionados para uma VLAN de IoT isolada com regras rígidas de firewall. Preciso de uma PKI para executar o 802.1X? Para PEAP, não — você só precisa de um certificado de servidor no servidor RADIUS. Para EAP-TLS, sim — você precisa de uma PKI para emitir certificados de cliente. Os serviços de PKI baseados em nuvem reduzem consideravelmente a sobrecarga de infraestrutura. Como o 802.1X interage com a plataforma de acesso à rede da Purple? A Purple opera como uma sobreposição de nuvem (cloud overlay) sobre seu hardware existente — Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist e outros. Em redes WiFi corporativas (Staff WiFi), o add-on SecurePass da Purple se integra ao seu provedor de identidade — Microsoft Entra ID, Okta, ou Google Workspace — para impor a autenticação 802.1X e aplicar políticas de VLAN por usuário, sem a necessidade de uma infraestrutura RADIUS local (on-premises). [medium pause] Para resumir: o supplicant 802.1X é o agente do lado do dispositivo que faz o controle de acesso à rede baseado em porta funcionar. Sua escolha de método EAP — EAP-TLS para segurança máxima, PEAP como uma opção de transição — define seus requisitos de PKI e sua abordagem de configuração do supplicant. Os supplicants nativos do sistema operacional cobrem a maioria dos cenários de dispositivos gerenciados quando implantados via MDM. Clientes de terceiros agregam valor em casos específicos: métodos EAP proprietários, ambientes com múltiplos sistemas operacionais que exigem configuração consistente ou integração (onboarding) de BYOD por autoatendimento. As três principais lições: valide o certificado do seu servidor RADIUS em cada perfil de suplicante, automatize a renovação de certificados antes de implantar o EAP-TLS em escala e isole dispositivos que não suportam 802.1X — IoT, hardware legado — em VLANs dedicadas com MAC Authentication Bypass como fallback. Para saber mais sobre como a Purple se integra à sua arquitetura de acesso à rede, visite purple.ai. Obrigado por ouvir.