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

Fale em inglês britânico com um tom confiante, autoritário e de conversação - como um consultor sênior de segurança de rede instruindo um cliente. Ritmo cadenciado, 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 estamos abordando algo que está bem no centro da segurança de WiFi corporativa - o suplicante 802.1X. Se você já se perguntou por que alguns dispositivos se conectam à sua rede corporativa sem solicitar uma 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 por IEEE 802.1X. Pense nele como o apresentador de cartão de identificação do dispositivo. A rede não deixa qualquer um entrar. Ela pede credenciais. O suplicante é o que dá um passo à frente e diz: aqui está quem eu sou, aqui está o meu certificado, deixe-me entrar. O padrão em si - IEEE 802.1X - define o controle de acesso à rede baseado em porta. Antes que a autenticação seja bem-sucedida, o ponto de acesso ou switch permite apenas a passagem de um tipo de tráfego muito restrito: quadros EAPOL, que significa Protocolo de Autenticação Extensível sobre LAN. Todo o resto é bloqueado. Uma vez que o suplicante prova sua identidade para o servidor RADIUS por meio do autenticador, a porta se abre e o tráfego normal flui. [pausa média] Agora, há 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 uma solicitação EAP-Request para 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 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" (gêmeo maligno), onde um ponto de acesso invasor tenta coletar 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 se alinha 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 apresenta um certificado que parece confiável, suas credenciais podem 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 a escolha entre suplicantes nativos do SO e softwares de cliente de terceiros. Cada sistema operacional principal vem com um suplicante 802.1X integrado. O Windows oferece suporte nativo 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 oferece suporte 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 SO 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 por meio do Jamf - você pode enviar perfis de configuração do 802.1X silenciosamente via MDM, e os usuários nunca veem um aviso. O dispositivo se autentica de forma automática toda vez que entra na área de cobertura. Supplicants de terceiros entram em jogo em cenários específicos. Se você estiver executando uma infraestrutura Cisco e quiser usar EAP-FAST - o método EAP proprietário da Cisco - você 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 parque de sistemas operacionais mistos e deseja bloquear as configurações de supplicant para que os usuários não as desconfigurem acidentalmente, um cliente de terceiros oferece esse controle. Ferramentas como a suíte JoinNow da SecureW2 também atuam como agentes de integração - eles 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 o 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 laptops Windows gerenciados via Intune, telefones Android pessoais usados para o software de gerenciamento de propriedades e algumas máquinas Windows 7 herdadas na área administrativa. A abordagem aqui é em fases. Comece com a frota Windows gerenciada. Envie um perfil de configuração do Intune que instala o certificado CA raiz do servidor RADIUS, configura o perfil de WiFi para EAP-TLS e aciona o registro de certificado baseado em SCEP a partir da PKI interna. Esses dispositivos autenticam automaticamente desde o primeiro dia. Para dispositivos Android BYOD, implante um portal de integração de autoatendimento - os usuários visitam uma URL, baixam um perfil de configuração e o supplicant é configurado para eles. As máquinas Windows 7 herdadas permanecem em PEAP com validação estrita de certificado de servidor aplicada, isoladas em uma VLAN separada com acesso limitado, até que sejam 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 de 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 "PDV" - a política RADIUS o atribui à VLAN do PCI. O tablet de um 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, tratado 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 do certificado é 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: validação de certificado de servidor ausente em implantações PEAP. Se você não configurar o solicitante para validar o certificado do servidor RADIUS e verificar o nome do servidor, os usuários ficarão vulneráveis a se conectar a um ponto de acesso invasor. Sempre especifique a CA raiz confiável e o nome do servidor no perfil do solicitante. Número dois: expiração de certificado causando falhas em massa na autenticação. Os certificados de cliente possuem um período de validade. Se você não tiver uma renovação automatizada configurada via SCEP ou NDES, enfrentará um evento crítico onde 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 de solicitante inconsistente. 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 de CA antes que o perfil de WiFi o aceite. Um portal de integração que lida com essa etapa reduz significativamente o volume de chamados no suporte. Número quatro: atualizações de recursos do Windows 11 que quebram a configuração do solicitante. 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 solicitante nativo lida com o fallback de EAP-TLS. Teste seus perfis de solicitante com as novas versões do sistema operacional antes de implantá-los em produção. [pausa média] Perguntas rápidas agora. Os dispositivos IoT podem suportar 802.1X? A maioria não. Os dispositivos IoT normalmente não possuem um solicitante. 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, 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. 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 no topo do seu hardware existente - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist e outros. Em redes WiFi corporativas, o complemento SecurePass da Purple se integra ao seu provedor de identidade - Microsoft Entra ID, Okta ou Google Workspace - para aplicar autenticação 802.1X e políticas de VLAN por usuário sem exigir infraestrutura RADIUS local. [pausa média] Para encerrar: o solicitante 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 - direciona seus requisitos de PKI e sua abordagem de configuração do solicitante. Os solicitantes nativos de SO 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 sistemas operacionais mistos que exigem configuração consistente ou integração de BYOD em autoatendimento. As três coisas principais a lembrar: 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 os dispositivos que não oferecem suporte ao 802.1X - IoT, hardware legado - em VLANs dedicadas com desvio de autenticação MAC como alternativa. Para saber mais sobre como a Purple se integra com a arquitetura de controle de acesso da sua rede, visite purple dot ai. Obrigado por ouvir.