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 seu anfitrião e hoje vamos analisar uma das decisões mais consequentes que irá tomar ao conceber 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, o seu estado de conformidade 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 frase de passe WPA2 partilhada. Mas a forma como verificam a identidade é fundamentalmente diferente - e essa diferença tem implicações importantes na forma como implementa, gere e dimensiona a sua rede. [ANÁLISE TÉCNICA DETALHADA - aproximadamente 5 minutos] Vamos começar com o 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 definidora é 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 em relação às suas Autoridades de Certificação fidedignas. Mas aqui está a diferença crítica em relação ao PEAP - o dispositivo apresenta então 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 existem palavras-passe envolvidas. Nenhumas. A autenticação é inteiramente baseada em certificados. Isto torna o EAP-TLS extraordinariamente resistente a roubo de credenciais, ataques de dicionário e ataques Man-in-the-Middle. É simplesmente impossível roubar uma palavra-passe que não existe no fluxo de autenticação. Por outro lado, o compromisso é a complexidade da implementação. Para executar o EAP-TLS em escala, precisa de uma Infraestrutura de Chaves Públicas - uma PKI - para emitir, gerir e revogar certificados para cada dispositivo individual na sua rede. Também precisa de uma solução de Gestão de Dispositivos Móveis para enviar esses certificados silenciosamente para os terminais. Se estiver a gerir um parque corporativo com o Microsoft Intune ou o Jamf, isto é inteiramente gerível. Caso contrário, o EAP-TLS torna-se um empreendimento significativo. 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 da sua rede falharão a autenticação em simultâneo. Isso representa uma falha catastrófica. Os processos de monitorização e renovação de certificados são inegociáveis. Agora vamos analisar o PEAP - Protected Extensible Authentication Protocol. O PEAP foi concebido para resolver a complexidade de implementação do EAP-TLS, continuando a fornecer uma segurança robusta. A principal ideia por trás do PEAP é esta: apenas precisa que o servidor tenha um certificado. O dispositivo cliente não precisa de um. 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 a autenticação padrão baseada em palavra-passe, normalmente utilizando MSCHAPv2, contra o seu fornecedor de identidade - Active Directory, LDAP, Google Workspace, seja qual for o que estiver 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 é aí 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 malicioso com o mesmo nome de rede, apresentar um certificado fraudulento, e o dispositivo ligar-se-á de bom grado. 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 solução é simples: utilizar Políticas de Grupo, perfis de MDM ou ferramentas de integração para impor a validação rigorosa do certificado do servidor em cada dispositivo cliente. Mas a realidade operacional é que, em ambientes BYOD, garantir que esta configuração seja 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 leitores de mão de propriedade corporativa, todos geridos através do Microsoft Intune. O EAP-TLS é a escolha certa. O Intune distribui os certificados automaticamente. Se um leitor se perder, a equipa de TI revoga o seu certificado e este fica fora da rede em poucos minutos - sem reposiçõ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 controlador de acessos, bloqueando todo o tráfego até que o servidor RADIUS sinalize que a autenticação foi bem-sucedida. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS - aproximadamente 2 minutos] Quais são, então, as recomendações práticas? Primeiro: se tiver uma solução MDM e dispositivos propriedade da empresa, implemente EAP-TLS. O investimento inicial em PKI e gestão de certificados traz dividendos na redução de riscos e na simplificação das 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 estiver a operar num ambiente BYOD ou não tiver infraestrutura MDM, implemente PEAP. Mas não ignore a configuração de validação de certificado do servidor. Utilize ferramentas de integração, portais de controlo de acesso à rede ou perfis de MDM, sempre que possível, para forçar esta validação. Trate isto como uma etapa de implementação obrigatória, e não como uma medida opcional de reforço de segurança. 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 cloud 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 que causa falhas de autenticação em massa em implementações EAP-TLS; dispositivos de clientes que não validam os certificados do servidor em implementações PEAP; e problemas de timeout do RADIUS causados por uma latência elevada entre o controlador wireless e o servidor de autenticação - particularmente relevante em propriedades distribuídas geograficamente. [PERGUNTAS E RESPOSTAS RÁPIDAS - aproximadamente 1 minuto] Vou responder rapidamente a algumas perguntas que ouço com frequência. Posso executar EAP-TLS e PEAP na mesma rede? Sim. Muitas organizações executam EAP-TLS para dispositivos corporativos num SSID e 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 802.1X empresariais, 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 atuar como um fornecedor de identidade para o OpenRoaming, permitindo um roaming seguro e contínuo entre locais sem necessidade de nova autenticação. [RESUMO E PRÓXIMOS PASSOS - aproximadamente 1 minuto] Para resumir: o EAP-TLS é a opção de maior segurança, eliminando totalmente as palavras-passe através de autenticação mútua de certificados. Requer infraestrutura PKI e MDM, mas oferece a postura de conformidade mais forte 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 forte autenticação encriptada com credenciais existentes - mas apenas quando a validação do certificado do servidor é rigorosamente aplicada. O quadro de decisão é simples: se gere os seus dispositivos, utilize EAP-TLS. Se os seus utilizadores trazem os seus próprios dispositivos, utilize PEAP - mas configure-o corretamente. Para os seus próximos passos: audite a sua configuração de autenticação atual, avalie a sua prontidão de PKI e MDM e reveja a sua infraestrutura RADIUS para redundância e latência. Se está a implementar ou a atualizar o seu WiFi de convidados juntamente com a sua rede corporativa, considere como uma plataforma como a Purple se pode integrar com o seu framework de autenticação para fornecer segurança e análises acionáveis a partir da sua rede. Obrigado por ouvir o Briefing Técnico da Purple. Até à próxima.