EAP-TLS vs. PEAP: Qual o Protocolo de Autenticação Adequado para a Sua Rede?

EAP-TLS vs PEAP: Qual o Protocolo de Autenticação Adequado para a Sua Rede? Um Briefing Técnico da Purple [INTRODUÇÃO — aproximadamente 1 minuto] Bem-vindo ao Briefing Técnico da Purple. Sou o vosso anfitrião e hoje vamos abordar uma das decisões mais consequentes que irá tomar ao desenhar ou atualizar a sua infraestrutura sem fios empresarial: a escolha entre EAP-TLS e PEAP para a sua estrutura de autenticação 802.1X. Se é um gestor de TI, arquiteto de rede ou CTO responsável por um grupo hoteleiro, uma rede de retalho, um estádio ou uma organização do setor público, esta decisão afeta a sua postura de segurança, a sua conformidade regulamentar e a carga operacional diária que a sua equipa suporta. Por isso, vamos diretos ao assunto. Tanto o EAP-TLS como o PEAP são métodos de autenticação 802.1X. Ambos dependem de um servidor RADIUS para processar os pedidos de autenticação e ambos oferecem uma segurança significativamente mais forte do que uma palavra-passe partilhada WPA2. Mas a forma como verificam a identidade é fundamentalmente diferente — e essa diferença tem implicações profundas na forma como implementa, gere e dimensiona a sua rede. [ANÁLISE TÉCNICA DETALHADA — aproximadamente 5 minutos] Comecemos pelo EAP-TLS — Extensible Authentication Protocol Transport Layer Security. O EAP-TLS é o padrão de excelência da autenticação WiFi empresarial. A característica que o define é a autenticação mútua por certificado. O que isto significa na prática é o seguinte: quando um dispositivo tenta ligar-se à sua rede, o servidor RADIUS apresenta um certificado digital ao dispositivo. O dispositivo verifica esse certificado face às suas Autoridades de Certificação fidedignas. Mas aqui reside a diferença crítica em relação ao PEAP — o dispositivo apresenta depois o seu próprio certificado de volta ao servidor. O servidor valida esse certificado de cliente e, apenas se ambos os certificados forem válidos e fidedignos, a rede concede o acesso. Não há palavras-passe envolvidas. Nenhuma. A autenticação baseia-se inteiramente em certificados. Isto torna o EAP-TLS extraordinariamente resistente ao roubo de credenciais, a ataques de dicionário e a ataques Man-in-the-Middle. É simplesmente impossível roubar uma palavra-passe que não existe no fluxo de autenticação. Em contrapartida, a desvantagem é a complexidade de implementação. Para executar o EAP-TLS à escala, necessita de uma Infraestrutura de Chaves Públicas — uma PKI — para emitir, gerir e revogar certificados para cada um dos dispositivos na sua rede. Também precisa de uma solução de Gestão de Dispositivos Móveis para instalar silenciosamente esses certificados nos terminais. Se gere um parque empresarial com o Microsoft Intune ou o Jamf, isto é perfeitamente gerível. Caso contrário, o EAP-TLS torna-se um empreendimento complexo. A outra consideração operacional é a gestão do ciclo de vida dos certificados. Os certificados expiram. Se o certificado do seu servidor RADIUS expirar, todos os dispositivos na sua rede falharão a autenticação em simultâneo. Trata-se de uma falha catastrófica. Os processos de monitorização e renovação de certificados são inegociáveis. Agora, vejamos o PEAP — Protected Extensible Authentication Protocol. O PEAP foi concebido para responder à complexidade de implementação do EAP-TLS, mantendo uma segurança robusta. A principal ideia por trás do PEAP é esta: apenas precisa que o servidor tenha um certificado. O cliente não precisa de nenhum. Eis como funciona. O servidor RADIUS apresenta o seu certificado ao dispositivo cliente. O cliente valida o servidor — tal como no EAP-TLS. Isto estabelece um túnel TLS encriptado. Dentro desse túnel, o cliente realiza então a autenticação padrão baseada em palavra-passe, normalmente utilizando MSCHAPv2, contra o seu repositório de identidades — Active Directory, LDAP, Google Workspace, o que quer que esteja a utilizar. A palavra-passe nunca viaja em texto limpo. Está sempre protegida dentro do túnel encriptado. Portanto, o PEAP é genuinamente seguro — desde que seja configurado corretamente. E é aqui que precisamos de falar sobre a configuração incorreta mais comum e mais perigosa nas implementações de PEAP. Se um dispositivo cliente não estiver configurado para validar rigorosamente o certificado do servidor RADIUS, um atacante pode configurar um ponto de acesso falso com o mesmo nome de rede, apresentar um certificado fraudulento, e o dispositivo irá ligar-se alegremente. O atacante captura então a troca de autenticação MSCHAPv2, que pode ser decifrada offline. Este não é um ataque teórico — é uma técnica bem documentada utilizada em testes de intrusão do mundo real. A correção é simples: utilize Políticas de Grupo, perfis de MDM ou ferramentas de integração para impor uma validação rigorosa do certificado do servidor em cada dispositivo cliente. Mas a realidade operacional é que, em ambientes BYOD, garantir que esta configuração é aplicada de forma consistente em milhares de dispositivos pessoais não geridos é genuinamente difícil. Deixe-me dar-lhe uma comparação concreta. Considere uma cadeia de retalho com 500 localizações. Têm tablets e scanners portáteis propriedade da empresa, todos geridos através do Microsoft Intune. O EAP-TLS é a escolha certa. O Intune envia os certificados automaticamente. Se um scanner for perdido, a equipa de TI revoga o seu certificado e este fica fora da rede em minutos — sem redefinições de palavras-passe, sem alterações de frases de acesso partilhadas em 500 lojas. A segurança é absoluta. Agora considere um grande centro de conferências que disponibiliza WiFi para 3.000 colaboradores nos seus dispositivos pessoais. Sem MDM. Os colaboradores utilizam o Google Workspace. O PEAP integrado com o Google Secure LDAP é a escolha pragmática. Os colaboradores autenticam-se com as suas credenciais padrão. A equipa de TI fornece documentação de integração para configurar a validação de certificados. É implementável em dias, não em meses. A arquitetura que sustenta ambos os protocolos é o mesmo modelo 802.1X de três componentes: o suplicante — que é o dispositivo cliente —, o autenticador, que é o seu ponto de acesso ou switch, e o servidor RADIUS. O autenticador funciona como um guardião, bloqueando todo o tráfego até que o servidor RADIUS sinalize que a autenticação foi bem-sucedida. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS — aproximadamente 2 minutos] Então, quais são as recomendações práticas? Primeiro: se tem uma solução de MDM e dispositivos de propriedade corporativa, implemente o EAP-TLS. O investimento inicial em PKI e gestão de certificados traz dividendos na redução de riscos e na simplificação de auditorias de conformidade. Para ambientes regulados — saúde, finanças, setor público — isto não é opcional. É a arquitetura que os seus auditores esperam ver. Segundo: se opera num ambiente BYOD ou não possui infraestrutura de MDM, implemente o PEAP. Mas não ignore a configuração de validação do certificado do servidor. Utilize ferramentas de integração (onboarding), portais de controlo de acesso à rede ou perfis de MDM, sempre que possível, para impor esta validação. Trate isto como uma etapa de implementação obrigatória, e não como uma medida de segurança opcional. Terceiro: independentemente do protocolo que escolher, integre redundância RADIUS na sua arquitetura. A autenticação é um caminho crítico. Uma única falha no servidor RADIUS significa que ninguém consegue aceder à rede. As soluções RADIUS alojadas na nuvem podem proporcionar resiliência sem a sobrecarga de gerir uma infraestrutura local redundante. Quarto: segmente a sua rede após a autenticação. Uma autenticação 802.1X bem-sucedida não deve conceder acesso ilimitado a toda a sua rede corporativa. Utilize políticas de atribuição de VLAN para colocar os utilizadores nos segmentos de rede adequados com os controlos de acesso apropriados. Os erros comuns a evitar: a expiração de certificados a causar falhas de autenticação em massa em implementações EAP-TLS; dispositivos clientes a não validar os certificados do servidor em implementações PEAP; e problemas de timeout do RADIUS causados por latência elevada entre o controlador sem fios e o servidor de autenticação — particularmente relevante em propriedades distribuídas geograficamente. [PERGUNTAS E RESPOSTAS RÁPIDAS — aproximadamente 1 minuto] Deixe-me abordar algumas perguntas que oiço frequentemente. Posso executar o EAP-TLS e o PEAP na mesma rede? Sim. Muitas organizações executam o EAP-TLS para dispositivos corporativos num SSID e o PEAP para BYOD ou acesso de convidados num SSID separado, com a devida segmentação de rede entre eles. O WPA3 altera esta decisão? O WPA3 Enterprise exige o modo de segurança de 192 bits para implementações de alta segurança, o que se alinha com o EAP-TLS. O WPA3 Personal utiliza SAE em vez de PSK, mas para implementações enterprise 802.1X, a seleção do método EAP continua a ser relevante. O PEAP está em conformidade com o PCI DSS? Sim, quando corretamente configurado com a validação do certificado do servidor ativada. No entanto, para ambientes que lidam com dados de titulares de cartões, o EAP-TLS é cada vez mais a abordagem recomendada nas avaliações de segurança. E quanto ao OpenRoaming? O OpenRoaming utiliza autenticação baseada em certificados nos bastidores, alinhando-se com os princípios do EAP-TLS. Plataformas como a Purple podem funcionar como um fornecedor de identidade para o OpenRoaming, permitindo um roaming contínuo e seguro entre locais sem necessidade de nova autenticação. [RESUMO E PRÓXIMOS PASSOS — aproximadamente 1 minuto] Em resumo: o EAP-TLS é a opção de maior segurança, eliminando totalmente as palavras-passe através de autenticação mútua por certificados. Requer infraestrutura PKI e MDM, mas oferece a postura de conformidade mais robusta e o controlo de acesso ao nível do dispositivo mais granular. O PEAP é a escolha pragmática para BYOD e ambientes sem infraestrutura de gestão de certificados, fornecendo uma autenticação encriptada forte utilizando as credenciais existentes — mas apenas quando a validação do certificado do servidor é rigorosamente aplicada. O modelo de decisão é simples: se gere os seus dispositivos, utilize o EAP-TLS. Se os seus utilizadores trazem os seus próprios dispositivos, utilize o PEAP — mas configure-o corretamente. Para os seus próximos passos: audite a sua configuração de autenticação atual, avalie a sua preparação para PKI e MDM e reveja a sua infraestrutura RADIUS para redundância e latência. Se está a implementar ou a atualizar o WiFi de convidados em paralelo com a sua rede corporativa, considere como uma plataforma como a Purple se pode integrar com a sua estrutura de autenticação para fornecer segurança e análises acionáveis a partir da sua rede. Obrigado por ouvir o Purple Technical Briefing. Até à próxima.