Como Implementar a Autenticação 802.1X com Cloud RADIUS

Como Implementar a Autenticação 802.1X com Cloud RADIUS Um Informativo de Inteligência Purple WiFi --- INTRODUÇÃO E CONTEXTO (aprox. 1 minuto) --- Bem-vindo ao Informativo de Inteligência Purple WiFi. Sou seu anfitrião e hoje vamos nos aprofundar nos detalhes da autenticação 802.1X com Cloud RADIUS — o que é, por que importa agora e como realmente implantá-la em uma propriedade com vários locais. Se você gerencia infraestrutura de WiFi para um grupo de hotéis, uma rede de varejo, um estádio ou uma organização do setor público, este é um daqueles tópicos que sempre surgem — e por um bom motivo. O cenário de ameaças mudou. As redes PSK compartilhadas são cada vez mais vistas como uma responsabilidade de conformidade, não apenas um inconveniente de segurança. Reguladores, auditores e seguradoras cibernéticas estão fazendo perguntas mais difíceis sobre o controle de acesso à rede. E a boa notícia é que o RADIUS fornecido pela nuvem tornou o 802.1X genuinamente implantável em escala, sem a sobrecarga de infraestrutura local que costumava torná-lo inviável para propriedades distribuídas. Então, vamos ao que interessa. --- MERGULHO TÉCNICO PROFUNDO (aprox. 5 minutos) --- Primeiro, vamos garantir que todos estejamos trabalhando com a mesma definição. O IEEE 802.1X é um padrão de controle de acesso à rede baseado em porta. Ele define uma estrutura de autenticação que fica na Camada 2 do modelo OSI — portanto, opera antes que um dispositivo receba qualquer conectividade IP. Essa é a principal diferença em relação à autenticação na camada de aplicação. Com o 802.1X, um dispositivo não pode entrar na rede até que tenha sido autenticado positivamente. O protocolo tem três componentes. O supplicant — que é o dispositivo final, seja um laptop, um smartphone ou um terminal de ponto de venda. O authenticator — normalmente seu ponto de acesso WiFi ou seu switch gerenciado. E o servidor de autenticação — que nas implantações modernas é o seu serviço Cloud RADIUS. O fluxo funciona assim. Um dispositivo tenta se associar a um ponto de acesso. O ponto de acesso não concede acesso total à rede imediatamente. Em vez disso, ele abre uma porta controlada e inicia uma troca EAP — que é o Extensible Authentication Protocol — com o dispositivo. O dispositivo apresenta suas credenciais, que podem ser um nome de usuário e senha, um certificado digital ou uma identidade baseada em SIM. O ponto de acesso retransmite essa troca para o servidor RADIUS usando o protocolo RADIUS sobre UDP, normalmente na porta 1812 para autenticação e 1813 para tarifação. O servidor RADIUS valida as credenciais em um repositório de identidade — Active Directory, Azure AD ou um diretório LDAP — e retorna uma mensagem Access-Accept ou Access-Reject. Se aceito, o ponto de acesso abre a porta e o dispositivo obtém acesso à rede. Se rejeitado, ele permanece bloqueado. Simples em princípio, mas os detalhes da implementação importam enormemente. Agora, a seleção do método EAP é onde muitas implantações dão errado. Existem vários métodos EAP em uso comum, e eles têm perfis de segurança e requisitos operacionais muito diferentes. O EAP-TLS é o padrão ouro. Ele exige autenticação mútua de certificados — tanto o servidor quanto o cliente apresentam um certificado. Isso elimina totalmente o risco de roubo de credenciais, pois não há senhas para roubar. Mas exige uma infraestrutura de PKI e um mecanismo para enviar certificados de cliente para os dispositivos, o que normalmente significa uma solução de MDM. Para ambientes corporativos de BYOD e implantações de alta segurança, essa é a resposta certa. O PEAP com MSCHAPv2 é o método mais amplamente implantado em ambientes corporativos. Ele exige apenas um certificado do lado do servidor e canaliza a troca de credenciais dentro do TLS. É compatível nativamente com o Active Directory, o que o torna operacionalmente simples. O risco é que ele é vulnerável à coleta de credenciais se os usuários se conectarem a um ponto de acesso invasor com um certificado autoassinado — portanto, a validação do certificado no lado do cliente não é negociável. O EAP-TTLS é semelhante ao PEAP, mas mais flexível no método de autenticação interna. É particularmente útil em ambientes de dispositivos mistos, onde você tem uma combinação de dispositivos Windows, macOS, iOS e Android com capacidades variadas de supplicant. Para suporte a dispositivos legados — pense em hardwares de ponto de venda mais antigos ou sensores de IoT — o EAP-FAST pode ser uma escolha pragmática, pois não exige certificados e usa uma Credencial de Acesso Protegido em seu lugar. Agora, a parte do Cloud RADIUS. Tradicionalmente, o RADIUS era um serviço local — FreeRADIUS em um servidor Linux ou Microsoft NPS no Windows Server. Esse modelo funciona, mas tem custos operacionais reais: manutenção de hardware, configuração de alta disponibilidade, aplicação de patches e a necessidade de infraestrutura local em cada site que precisa de autenticação de baixa latência. O Cloud RADIUS muda essa lógica significativamente. Um serviço Cloud RADIUS é hospedado e gerenciado pelo provedor. Seus pontos de acesso enviam solicitações RADIUS pela internet para o serviço de nuvem, que lida com a autenticação em relação ao seu provedor de identidade. A preocupação com a latência é real, mas gerenciável — os serviços modernos de Cloud RADIUS são distribuídos globalmente, e as viagens de ida e volta de autenticação normalmente são concluídas em menos de 100 milissegundos, o que é imperceptível para os usuários finais. A integração com provedores de identidade é a dependência crítica. A maioria das plataformas Cloud RADIUS suporta LDAP, LDAPS, SAML 2.0 e integração direta com Azure AD ou Okta. Para organizações que já executam o Microsoft 365, a integração com o Azure AD é o caminho natural — você obtém logon único, políticas de acesso condicional e aplicação de MFA, tudo alimentando sua camada de controle de acesso à rede. Para locais que implantam WiFi para visitantes ao lado de redes de funcionários, a arquitetura normalmente separa essas redes em SSIDs distintos com políticas de autenticação diferentes. As redes de funcionários usam 802.1X com credenciais corporativas. As redes de visitantes usam um Captive Portal ou fluxo de login social. A plataforma da Purple suporta ambos os modelos, e a camada de análise de WiFi abrange ambos, oferecendo visibilidade sobre o comportamento do dispositivo, tempo de permanência e utilização da rede sem comprometer a segmentação de segurança. --- RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS (aprox. 2 minutos) --- Deixe-me apresentar a sequência prática de implantação e apontar os modos de falha que vejo com mais frequência. Comece com a integração do seu provedor de identidade. Antes de tocar em um único ponto de acesso, confirme se o seu serviço Cloud RADIUS pode se autenticar no seu diretório. Teste com uma conta de serviço, valide a associação LDAP e confirme se os atributos de associação de grupo estão sendo retornados corretamente — porque você precisará deles para as políticas de atribuição de VLAN. Segundo, planeje sua estratégia de certificados. Se você optar pelo EAP-TLS, precisará de uma CA, precisará decidir se usará uma CA pública ou interna e precisará de um plano de implantação de MDM para certificados de cliente. Se você optar pelo PEAP, precisará de um certificado de servidor de uma CA confiável — não autoassinado — e precisará enviar o certificado da CA para todos os dispositivos clientes para que a validação do certificado funcione corretamente. Esta é a etapa que costuma ser ignorada e causa incidentes de segurança. Terceiro, configure seus clientes RADIUS — que são seus pontos de acesso e controladores — com o segredo compartilhado e o IP ou nome de host do servidor corretos. Use um segredo compartilhado forte e gerado aleatoriamente, não uma palavra de dicionário. E se o seu provedor de Cloud RADIUS suportar RADIUS sobre TLS — RadSec — use-o. Ele criptografa o tráfego RADIUS em trânsito, o que é particularmente importante quando esse tráfego está atravessando a internet pública. Quarto, teste com um grupo piloto antes da implantação completa. Falhas de autenticação em escala são disruptivas e difíceis de diagnosticar sob pressão. Execute um piloto com dez a vinte dispositivos, valide os logs de autenticação, confirme se a atribuição de VLAN está funcionando e verifique se os registros de tarifação estão sendo gravados corretamente. Os modos de falha que vejo com mais frequência: validação de certificado desativada nos clientes, levando a vulnerabilidades de man-in-the-middle. Segredos compartilhados muito curtos ou reutilizados em vários locais. Lista de permissões de IP do servidor RADIUS não configurada, fazendo com que as solicitações de autenticação de novos locais sejam descartadas silenciosamente. E perfis de MDM não sendo atualizados quando os certificados expiram, causando falhas de autenticação em massa no dia da renovação. --- PERGUNTAS E RESPOSTAS RÁPIDAS (aprox. 1 minuto) --- Algumas perguntas que recebo regularmente. Posso executar o 802.1X em uma rede que também possui dispositivos IoT que não suportam EAP? Sim — use o MAC Authentication Bypass como uma alternativa para dispositivos que não podem executar um supplicant, mas coloque esses dispositivos em uma VLAN restrita com regras rígidas de firewall. O 802.1X substitui a criptografia WPA2 ou WPA3? Não — o 802.1X lida com a autenticação. O WPA2-Enterprise ou WPA3-Enterprise lida com a criptografia. Você precisa de ambos. O WPA3-Enterprise com 802.1X é a melhor prática atual para novas implantações. Qual é o impacto da latência na autenticação? Com um serviço Cloud RADIUS bem configurado, espere de 50 a 150 milissegundos por autenticação. Para cenários de roaming, a transição rápida de BSS 802.11r pode reduzir significativamente a sobrecarga de reautenticação. Isso é compatível com o PCI DSS? O 802.1X com EAP-TLS ou PEAP em uma rede devidamente segmentada atende aos Requisitos 1 e 8 do PCI DSS para controle de acesso à rede. Envolva seu QSA desde o início. --- RESUMO E PRÓXIMOS PASSOS (aprox. 1 minuto) --- Para resumir tudo: o 802.1X com Cloud RADIUS é a resposta certa para qualquer organização que precise demonstrar controle de acesso à rede para auditores, reduzir o raio de alcance de uma credencial comprometida ou gerenciar a autenticação centralmente em uma propriedade distribuída. A implantação não é trivial, mas é absolutamente gerenciável com a preparação correta. Acerte primeiro na integração do seu provedor de identidade. Escolha seu método EAP com base na sua frota de dispositivos e na sua capacidade operacional de gerenciar certificados. Use RadSec se sua infraestrutura suportar. E teste antes de implantar em escala. Se você opera uma rede mista de visitantes e funcionários — o que a maioria dos operadores de hotelaria e varejo faz — plataformas como a Purple oferecem a capacidade de gerenciar ambos os modelos de autenticação a partir de um único painel, com a camada de análise cobrindo toda a propriedade. Para os seus próximos passos: faça uma auditoria na sua postura atual de controle de acesso à rede, identifique quais locais ainda estão executando PSK compartilhado e crie um plano de migração em fases. Comece com os locais de maior risco — aqueles no escopo do PCI DSS ou que lidam com dados confidenciais — e avance a partir daí. Obrigado por ouvir. Mais informativos técnicos estão disponíveis em purple.ai.