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 - como se fosse 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 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 exibem erros de certificado e chamados no helpdesk, 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 se conectar a 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á meu certificado, me deixe 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 access point ou switch permite apenas a passagem de um tipo de tráfego muito restrito: quadros EAPOL, que significa Extensible Authentication Protocol over LAN. Todo o resto é bloqueado. Assim 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, existem três atores nesta peça. Primeiro, o suplicante - o dispositivo cliente. Segundo, o autenticador - seu access point 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 contra 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 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 é tomada. O EAP-TLS - que significa Protocolo de Autenticação Extensível com Segurança de Camada de Transporte - é 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, nos quais 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 WPA3-Enterprise em seu modo de segurança mais alto, além de estar alinhado com as exigências do NIST SP 800-171 para verificação de identidade de dispositivos. O PEAP - EAP Protegido - é 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 utiliza hashing MD4, que é considerado comprometido desde 1995. Se um usuário se conectar a um ponto de acesso invasor que apresente um certificado que pareça 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 próprio suplicante - especificamente na escolha entre suplicantes nativos do sistema operacional e softwares de cliente de terceiros. Todos os principais sistemas operacionais vêm com um suplicante 802.1X integrado. O Windows oferece suporte nativo desde o XP, por meio dos serviços de Configuração Automática Sem Fio e Configuração Automática Com Fio. O macOS e o iOS lidam com o 802.1X através de seus perfis de configuração de rede. O Android 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 via Jamf - você pode enviar perfis de configuração 802.1X de forma silenciosa via MDM, e os usuários nunca verão um aviso. O dispositivo se autentica automaticamente toda vez que entra no raio de alcance. Suplicantes 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ê precisar de um gerenciamento de configuração consistente em um parque de sistemas operacionais mistos e quiser bloquear as configurações do suplicante 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 - elas configuram o suplicante nativo em vez de substituí-lo, orientando os usuários no registro de certificados e na instalação de perfis. [medium pause] Deixe-me guiar você por dois cenários do mundo real para tornar isso concreto. Primeiro, um hotel de 400 quartos. Atualmente, a propriedade opera 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, telefones Android pessoais usados para o software de gestão da propriedade e algumas máquinas legadas com Windows 7 na área administrativa. A abordagem aqui é em fases. Comece com a frota gerenciada de Windows. 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 BYOD Android, implante um portal de integração de autoatendimento - os usuários visitam uma URL, baixam um perfil de configuração e o suplicante é configurado para eles. As máquinas legadas com Windows 7 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 de convidados. A conformidade 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 "PDV" - a política RADIUS o atribui à VLAN do PCI. O tablet de um funcionário apresenta um certificado com "Funcionário" - ele vai para a 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 suplicante nos terminais de PDV é bloqueada via MDM. Nenhuma interação do usuário é necessária. Os terminais 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 de autenticação em massa. Os certificados de cliente têm um período de validade. Se você não tiver a renovação automática 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 inconsistente do solicitante. O Android, em particular, possui 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 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 solicitante. A Microsoft alterou o comportamento do 802.1X em várias atualizações do Windows 11. Especificamente, a atualização 24H2 introduziu alterações na forma como o solicitante nativo lida com o fallback do EAP-TLS. Teste seus perfis de solicitante em relação às novas versões do SO antes de implantá-los em produção. [medium pause] Perguntas rápidas agora. Os dispositivos IoT podem suportar 802.1X? A maioria não pode. Os dispositivos IoT geralmente 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 falsificados, por isso 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 no topo do seu hardware existente - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist e outros. Em redes WiFi de funcionários, o complemento SecurePass da Purple se integra ao seu provedor de identidade - Microsoft Entra ID, Okta ou Google Workspace - para aplicar a autenticação 802.1X e aplicar políticas de VLAN por usuário sem exigir infraestrutura RADIUS local. [medium pause] 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 de solicitante. Os solicitantes nativos do 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 de SO mistos que exigem configuração consistente ou integração BYOD por autoatendimento. As três coisas fundamentais a reter: 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 a 802.1X - IoT, hardware legado - em VLANs dedicadas com MAC Authentication Bypass como alternativa. Para saber mais sobre como o Purple se integra à sua arquitetura de acesso à rede, visite purple dot ai. Obrigado por ouvir.