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

Speak in British English with a confident, authoritative, conversational tone - like a senior network security consultant briefing a client. Measured pace, clear diction, professional but not stiff. Occasional natural pauses for emphasis: Bem-vindo à série de briefings técnicos da Purple. Hoje vamos abordar algo que está no centro da segurança de WiFi empresarial - o suplicante 802.1X. Se alguma vez se perguntou por que razão alguns dispositivos se ligam à sua rede corporativa sem solicitarem uma palavra-passe, enquanto outros apresentam erros de certificado e geram tickets de suporte, este episódio é para si. [pausa média] Comecemos pelo básico. O suplicante 802.1X é o componente de software num dispositivo cliente - um portátil, um smartphone, um tablet - que gere o handshake de autenticação quando esse dispositivo tenta ligar-se a uma rede protegida por IEEE 802.1X. Pense nele como o apresentador do cartão de identificação do dispositivo. A rede não deixa entrar qualquer um. Pede credenciais. O suplicante é quem dá um passo em frente e diz: aqui está quem eu sou, aqui está o meu certificado, deixe-me entrar. O próprio padrão - IEEE 802.1X - define o controlo de acesso à rede baseado em portas. Antes de a autenticação ser bem-sucedida, o ponto de acesso ou switch apenas permite a passagem de um tipo de tráfego muito restrito: tramas EAPOL, que significa Extensible Authentication Protocol over LAN. Tudo o resto é bloqueado. Assim que o suplicante prova a sua identidade ao servidor RADIUS através do autenticador, a porta abre-se e o tráfego normal flui. [pausa média] Agora, existem três intervenientes nesta peça. Primeiro, o suplicante - o dispositivo cliente. Segundo, o autenticador - o 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 face a um diretório como o 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 a sua identidade. Essa identidade é encaminhada para o servidor RADIUS, que depois desafia o suplicante com o método EAP acordado. Se tudo estiver correto, o servidor RADIUS envia um Access-Accept, a porta abre-se 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 implementação são tomadas. EAP-TLS — ou seja, Extensible Authentication Protocol com Transport Layer Security — é o padrão de excelência. Requer que tanto o cliente como o servidor apresentem certificados. Autenticação mútua. Sem palavra-passe. 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 não autorizado tenta recolher credenciais. O EAP-TLS é concluído em doze passos e utiliza criptografia de chave pública-privada em todo o processo. É o método exigido para o WPA3-Enterprise no seu modo de segurança mais elevado 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 palavra-passe, normalmente o MSCHAPv2, dentro de um túnel TLS. O servidor apresenta um certificado; o cliente não. Isto significa que a implementação é mais simples — não precisa de aprovisionar certificados de cliente — mas é menos segura. O MSCHAPv2 utiliza hashing MD4, que é considerado comprometido desde 1995. Se um utilizador se ligar a um ponto de acesso não autorizado que apresente um certificado aparentemente fidedigno, as suas credenciais podem ser capturadas. A validação do certificado do servidor do lado do cliente é, por isso, inegociável ao executar o PEAP. [medium pause] Agora vamos focar-nos no próprio suplicante — especificamente na escolha entre os suplicantes nativos do SO e o software de cliente de terceiros. Cada sistema operativo principal inclui um suplicante 802.1X integrado. O Windows suporta-o nativamente desde o XP, através dos serviços Wireless AutoConfig e Wired AutoConfig. O macOS e o iOS gerem o 802.1X através dos seus perfis de configuração de rede. O Android suporta-o através do painel de definições de WiFi. Estes suplicantes nativos cobrem EAP-TLS e PEAP-MSCHAPv2 em todas as plataformas atuais. A vantagem dos suplicantes nativos é óbvia: sem software adicional para implementar, sem custos de licenciamento, atualizações automáticas de segurança do SO e uma forte integração com o repositório de certificados do sistema operativo. Para frotas de dispositivos geridos — computadores Windows registados no Microsoft Intune, Macs geridos através do Jamf — pode enviar perfis de configuração 802.1X de forma silenciosa via MDM, e os utilizadores nunca veem um aviso. O dispositivo autentica-se automaticamente sempre que entra no alcance. Os suplicantes de terceiros entram em jogo em cenários específicos. Se estiver a executar infraestrutura Cisco e pretender utilizar o EAP-FAST - o método EAP proprietário da Cisco - necessita do software cliente da Cisco, historicamente o Secure Services Client ou o AnyConnect Network Access Manager. Se precisar de uma gestão de configuração consistente num parque de SO mistos e quiser bloquear as definições do suplicante para que os utilizadores não as configurem incorretamente por acidente, um cliente de terceiros oferece-lhe esse controlo. Ferramentas como o pacote JoinNow da SecureW2 também funcionam como agentes de integração - configuram o suplicante nativo em vez de o substituir, orientando os utilizadores através do registo de certificados e da instalação de perfis. [medium pause] Permita-me apresentar-lhe dois cenários do mundo real para tornar isto concreto. Primeiro, um hotel de 400 quartos. Atualmente, a propriedade gere uma rede de funcionários em WPA2-Enterprise com PEAP-MSCHAPv2. A equipa de TI pretende migrar para EAP-TLS para eliminar a autenticação baseada em palavra-passe e reduzir o risco de roubo de credenciais. O desafio: os dispositivos dos funcionários são uma mistura de portáteis Windows geridos através do Intune, telemóveis Android pessoais utilizados para o software de gestão da propriedade e um punhado de máquinas legacy Windows 7 no back-of-house. A abordagem aqui é faseada. Comece pela frota gerida de Windows. Envie um perfil de configuração do Intune que instala o certificado CA de raiz do servidor RADIUS, configura o perfil de WiFi para EAP-TLS e aciona o registo de certificados baseado em SCEP a partir da PKI interna. Esses dispositivos autenticam-se automaticamente desde o primeiro dia. Para os dispositivos Android BYOD, implemente um portal de integração self-service - os utilizadores acedem a um URL, transferem um perfil de configuração e o suplicante é configurado por eles. As máquinas legacy Windows 7 mantêm-se em PEAP com validação rigorosa de certificado de servidor aplicada, isoladas numa VLAN separada com acesso limitado, até serem desativadas. [medium pause] Segundo cenário: uma grande cadeia de retalho com 200 lojas. Cada loja tem uma mistura de terminais de ponto de venda, tablets de funcionários e uma rede WiFi de convidados. O PCI DSS exige que os ambientes de dados de titulares de cartões sejam isolados de outros segmentos de rede. O retalhista utiliza 802.1X nas redes de funcionários e POS, com a atribuição de VLAN orientada por atributos de certificado. Um terminal POS apresenta um certificado de dispositivo com uma unidade organizacional de "POS" - a política RADIUS atribui-o à VLAN PCI. Um tablet de funcionário apresenta um certificado com "Staff" - este entra na VLAN de funcionários. Os dispositivos de convidados ligam-se a um SSID totalmente separado, gerido por uma solução de Captive Portal. A configuração do suplicante nos terminais POS é bloqueada via MDM. Não é necessária qualquer interação do utilizador. Os terminais autenticam-se silenciosamente ao iniciar. A renovação de certificados é automatizada através de SCEP, pelo que não há intervenção manual quando os certificados expiram. [medium pause] Agora, os erros de implementação. Deixe-me apresentar-lhe os quatro mais comuns. Número um: falta de validação do certificado do servidor em implementações PEAP. Se não configurar o suplicante para validar o certificado do servidor RADIUS e verificar o nome do servidor, os utilizadores ficam vulneráveis à ligação a um ponto de acesso nocivo. Especifique sempre a CA de raiz fidedigna e o nome do servidor no perfil do suplicante. Número dois: expiração de certificados a causar falhas de autenticação em massa. Os certificados de cliente têm um período de validade. Se não tiver uma renovação automatizada em vigor via SCEP ou NDES, enfrentará um evento crítico em que centenas de dispositivos deixam de se autenticar em simultâneo. Desenvolva a automação de renovação antes de entrar em produção. Número três: dispositivos BYOD com comportamento de suplicante inconsistente. O Android, em particular, tem suporte 802.1X fragmentado entre fabricantes. Algumas versões exigem que o utilizador instale manualmente o certificado CA antes que o perfil de WiFi o aceite. Um portal de integração que trate deste passo reduz significativamente o volume do helpdesk. Número quatro: atualizações de funcionalidades do Windows 11 a quebrar a configuração do suplicante. 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 suplicante nativo lida com o fallback de EAP-TLS. Teste os seus perfis de suplicante em novas versões do SO antes de os lançar para 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 suplicante. A alternativa é o MAC Authentication Bypass - MAB - onde o servidor RADIUS autentica o dispositivo com base no seu endereço MAC. Os endereços MAC podem ser falsificados, pelo que os dispositivos MAB devem sempre ser colocados numa VLAN de IoT isolada com regras de firewall estritas. Preciso de uma PKI para executar o 802.1X? Para PEAP, não - apenas precisa de um certificado de servidor no servidor RADIUS. Para EAP-TLS, sim - precisa de uma PKI para emitir certificados de cliente. Os serviços de PKI baseados na nuvem reduzem consideravelmente a sobrecarga de infraestrutura. Como é que o 802.1X interage com a plataforma de acesso à rede da Purple? A Purple funciona como uma sobreposição de nuvem no topo do seu hardware existente - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, entre outros. Em redes de WiFi para funcionários, o suplemento SecurePass da Purple integra-se com o seu fornecedor de identidade - Microsoft Entra ID, Okta ou Google Workspace - para impor a autenticação 802.1X e aplicar políticas de VLAN por utilizador sem necessitar de infraestrutura RADIUS local. [medium pause] Para concluir: o suplicante 802.1X é o agente do lado do dispositivo que faz funcionar o controlo de acesso à rede baseado em portas. A sua escolha do método EAP - EAP-TLS para máxima segurança, PEAP como opção de transição - determina os seus requisitos de PKI e a sua abordagem de configuração de suplicante. Os suplicantes nativos do SO cobrem a maioria dos cenários de dispositivos geridos quando implementados via MDM. Os clientes de terceiros acrescentam valor em casos específicos: métodos EAP proprietários, parques de SO mistos que exigem uma configuração consistente ou integração BYOD em self-service.As três principais conclusões: valide o certificado do seu servidor RADIUS em cada perfil de suplicante, automatize a renovação de certificados antes de implementar o EAP-TLS à escala e isole os dispositivos que não suportam 802.1X — IoT, hardware legado — em VLANs dedicadas com MAC Authentication Bypass como recurso. Para saber mais sobre como a Purple se integra na sua arquitetura de acesso à rede, visite purple dot ai. Obrigado por ouvir.