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 conversacional - como um consultor sénior de segurança de rede a dar instruções a um cliente. Ritmo compassado, 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á mesmo no coração 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 tickets de suporte, este é o episódio para si. [pausa média] Comecemos pelo básico. O suplicante 802.1X é o componente de software num dispositivo cliente - um computador 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 nisto 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] Ora, 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 contra 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] Falemos sobre os métodos EAP, porque é aqui que a maioria das decisões de implementação são tomadas. O 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 palavras-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", 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 do início ao fim. É o método exigido para o WPA3-Enterprise no seu modo de segurança mais elevado e está alinhado com os requisitos do NIST SP 800-171 para verificação de identidade de dispositivos. O PEAP - Protected EAP - é o ponto de partida mais comum para organizações que ainda não dispõem de uma PKI completa. 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 malicioso que apresente um certificado de aspeto 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 suplicantes nativos do sistema operativo 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 cobrem o EAP-TLS e o 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 integração estreita 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 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 raio de alcance. Os suplicantes de terceiros entram em jogo em cenários específicos. Se estiver a executar uma infraestrutura Cisco e quiser utilizar o EAP-FAST - o método EAP proprietário da Cisco - necessita 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 a suite 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] Deixe-me guiar-lhe por 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 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 através do Intune, telemóveis Android pessoais utilizados para software de gestão de propriedades e um punhado de máquinas legacy Windows 7 na área administrativa. A abordagem aqui é faseada. Comece com a frota Windows gerida. Aplique 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 dispositivos BYOD Android, implemente um portal de integração self-service - os utilizadores visitam um URL, descarregam um perfil de configuração e o suplicante é configurado para eles. As máquinas legacy Windows 7 permanecem em PEAP com validação estrita de certificado de servidor imposta, isoladas numa VLAN separada com acesso limitado, até serem descontinuadas. [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 para 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 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 do 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. Nenhuma interação do utilizador é necessária. 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, 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 malicioso. Especifique sempre a CA de raiz fidedigna e o nome do servidor no perfil do suplicante. Número dois: a expiração de certificados que causa 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 configurada via SCEP ou NDES, enfrentará um cenário crítico em que centenas de dispositivos deixam de se autenticar em simultâneo. Desenvolva a automatização de renovação antes de avançar para a produção. Número três: dispositivos BYOD com comportamento de suplicante inconsistente. O Android, em particular, tem um suporte 802.1X fragmentado entre fabricantes. Algumas versões exigem que o utilizador instale manualmente o certificado de CA antes que o perfil de WiFi o aceite. Um portal de integração que trate desta etapa reduz significativamente o volume de pedidos de suporte. Número quatro: as atualizações de funcionalidades do Windows 11 que quebram 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 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 consegue. Os dispositivos IoT normalmente carecem de um suplicante por completo. 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 na nuvem em cima do seu hardware existente - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, entre outros. Em redes WiFi de colaboradores, 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 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 - 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 via MDM. Os clientes de terceiros acrescentam valor em casos específicos: métodos EAP proprietários, parques com SO mistos que requerem uma configuração consistente ou integração BYOD em regime de self-service. As três principais conclusões são: valide o certificado do seu servidor RADIUS em todos os perfis de suplicante, automatize a renovação de certificados antes de implementar o EAP-TLS em escala e isole os dispositivos que não suportam 802.1X - IoT, hardware legado - em VLANs dedicadas com MAC Authentication Bypass como alternativa. Para saber mais sobre como a Purple se integra com a sua arquitetura de controlo de acessos à rede, visite purple dot ai. Obrigado por ouvir.