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

Fale em inglês britânico com um tom confiante, autoritário e conversacional - como um consultor sénior de segurança de rede a instruir um cliente. Ritmo medido, dicção clara, profissional mas não rígido. Pausas naturais ocasionais para dar ênfase: 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 pedir palavra-passe, enquanto outros apresentam erros de certificado e originam pedidos de suporte, este episódio é para si. [pausa média] Vamos começar 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 aceder 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 é o que 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 desafia então 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 métodos EAP, porque é aqui que a maioria das decisões de implementação são tomadas. EAP-TLS - que significa Extensible Authentication Protocol com Transport Layer Security - é o padrão de ouro. Exige que tanto o cliente como o servidor apresentem certificados. Autenticação mútua. Sem palavras-passe. O certificado do cliente prova a identidade do dispositivo; o certificado do servidor prova que a rede é legítima, o que protege contra ataques "evil twin", em que um ponto de acesso malicioso 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 do dispositivo. PEAP - Protected EAP - é o ponto de partida mais comum para organizações que ainda não têm 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 apresenta. Isto significa que a implementação é mais simples - não necessita 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 malicioso que apresente um certificado que pareça fidedigno, as suas credenciais podem ser capturadas. A validação do certificado do servidor do lado do cliente é, portanto, não negociável ao executar PEAP. [medium pause] Agora vamos entrar no próprio suplicante - especificamente na escolha entre suplicantes nativos do SO e software de cliente de terceiros. Todos os principais sistemas operativos incluem 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 abrangem 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 de segurança automáticas do SO e integração estreita com o repositório de certificados do sistema operativo. Para frotas de dispositivos geridos - máquinas Windows registadas no Microsoft Intune, Macs geridos através do Jamf - pode implementar perfis de configuração 802.1X de forma silenciosa via MDM, e os utilizadores nunca chegam a ver 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 utilizar uma infraestrutura Cisco e quiser utilizar o EAP-FAST - o método EAP proprietário da Cisco - precisa do software de 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 sistemas operativos mistos e quiser bloquear as definições do suplicante para que os utilizadores não as desconfigurem acidentalmente, um cliente de terceiros oferece-lhe esse controlo. Ferramentas como o JoinNow suite da SecureW2 também funcionam como agentes de integração - configuram o suplicante nativo em vez de o substituir, orientando os utilizadores no registo de certificados e na instalação de perfis. [medium pause] Vou orientá-lo através de dois cenários do mundo real para tornar isto mais 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 quer 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 via Intune, telemóveis Android pessoais utilizados para software de gestão de propriedades e um punhado de máquinas legacy com Windows 7 na área administrativa. A abordagem aqui é faseada. Comece pela frota gerida de Windows. Envie um perfil de configuração do Intune que instale o certificado de CA raiz do servidor RADIUS, configure o perfil de WiFi para EAP-TLS e acione o registo de certificados baseado em SCEP a partir da PKI interna. Esses dispositivos autenticam-se automaticamente desde o primeiro dia. Para os dispositivos BYOD Android, implemente um portal de integração self-service - os utilizadores acedem a um URL, descarregam um perfil de configuração e o suplicante é configurado para eles. As máquinas legacy com Windows 7 mantêm-se em PEAP com validação estrita 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. A 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 de 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 inteiramente 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 no arranque. 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, armadilhas de implementação. Deixe-me apresentar-lhe as 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 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 implementada via SCEP ou NDES, enfrentará um cenário crítico em que centenas de dispositivos deixam de se autenticar em simultâneo. Crie a automatizaçã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, apresenta um suporte fragmentado para 802.1X entre fabricantes. Algumas versões exigem que o utilizador instale manualmente o certificado CA antes de o perfil de WiFi o aceitar. Um portal de integração que trate deste passo reduz significativamente o volume de trabalho do suporte técnico. 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 a alternativa EAP-TLS. Teste os seus perfis de suplicante em novas versões de SO antes de os implementar 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 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 ser sempre colocados numa VLAN de IoT isolada com regras de firewall rigorosas. 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 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 aplicar a autenticação 802.1X e aplicar políticas de VLAN por utilizador sem necessitar de infraestrutura RADIUS local. [medium pause] Para resumir: o suplicante 802.1X é o agente do lado do dispositivo que faz com que o controlo de acesso à rede baseado em portas funcione. A sua escolha do método EAP - EAP-TLS para máxima segurança, PEAP como uma opção de transição - orienta os seus requisitos de PKI e a sua abordagem de configuração do suplicante. Os suplicantes nativos do SO cobrem a maioria dos cenários de dispositivos geridos quando implementados através de MDM. Os clientes de terceiros acrescentam valor em casos específicos: métodos EAP proprietários, parques com sistemas operativos mistos que requerem uma configuração consistente ou integração BYOD em regime de self-service. As três conclusões principais a reter: valide o certificado do seu servidor RADIUS em cada perfil de suplicante, automatize a renovação de certificados antes de implementar EAP-TLS em larga escala, e isole os dispositivos que não suportam 802.1X - IoT, hardware antigo - em VLANs dedicadas com MAC Authentication Bypass como recurso de contingência. Para saber mais sobre como a Purple se integra na sua arquitetura de controlo de acesso à rede, visite purple ponto ai. Obrigado por ouvir.