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

Como Implementar a Autenticação 802.1X com Cloud RADIUS Um Briefing de Informação da Purple WiFi --- INTRODUÇÃO E CONTEXTO (aprox. 1 minuto) --- Bem-vindo ao Briefing de Informação da Purple WiFi. Sou o vosso anfitrião e hoje vamos entrar em detalhe sobre a autenticação 802.1X com Cloud RADIUS — o que é, por que razão é importante neste momento e como implementá-la de forma prática numa infraestrutura multi-site. Se gere infraestruturas de WiFi para um grupo hoteleiro, uma cadeia de retalho, um estádio ou uma organização do setor público, este é um daqueles temas que continua a surgir — e por um bom motivo. O panorama de ameaças mudou. As redes com PSK partilhado são cada vez mais vistas como um risco de conformidade, e não apenas como um inconveniente de segurança. Reguladores, auditores e seguradoras de riscos cibernéticos estão a fazer perguntas mais difíceis sobre o controlo de acesso à rede. E a boa notícia é que o RADIUS fornecido na nuvem tornou o 802.1X genuinamente implementável em escala, sem a sobrecarga de infraestrutura local que costumava torná-lo impraticável para propriedades distribuídas. Por isso, vamos a isso. --- ANÁLISE TÉCNICA DETALHADA (aprox. 5 minutos) --- Primeiro, vamos garantir que estamos todos a partir da mesma definição. O IEEE 802.1X é um padrão de controlo de acesso à rede baseado em portas. Define uma estrutura de autenticação que se situa na Camada 2 do modelo OSI — ou seja, opera antes de ser concedida qualquer conectividade IP ao dispositivo. Essa é a principal distinção da autenticação na camada de aplicação. Com o 802.1X, um dispositivo não consegue entrar na rede até ser positivamente autenticado. O protocolo tem três componentes. O suplicante — que é o dispositivo final, seja um portátil, um smartphone ou um terminal de ponto de venda. O autenticador — normalmente o seu ponto de acesso WiFi ou o seu switch gerido. E o servidor de autenticação — que em implementações modernas é o seu serviço cloud RADIUS. O fluxo funciona da seguinte forma. Um dispositivo tenta associar-se a um ponto de acesso. O ponto de acesso não concede acesso total à rede imediatamente. Em vez disso, abre uma porta controlada e inicia uma troca EAP — que é o Extensible Authentication Protocol — com o dispositivo. O dispositivo apresenta as suas credenciais, que podem ser um nome de utilizador e palavra-passe, um certificado digital ou uma identidade baseada em SIM. O ponto de acesso retransmite essa troca para o servidor RADIUS utilizando o protocolo RADIUS sobre UDP, normalmente na porta 1812 para autenticação e 1813 para monitorização (accounting). O servidor RADIUS valida as credenciais num repositório de identidades — Active Directory, Azure AD ou um diretório LDAP — e devolve uma mensagem de Access-Accept ou Access-Reject. Se for aceite, o ponto de acesso abre a porta e o dispositivo obtém acesso à rede. Se for rejeitado, permanece bloqueado. Simples em teoria, mas os detalhes de implementação importam imenso. Ora, a seleção do método EAP é onde muitas implementações falham. Existem vários métodos EAP de uso comum, e estes têm perfis de segurança e requisitos operacionais muito diferentes. O EAP-TLS é o padrão de excelência. Requer autenticação mútua por certificado — tanto o servidor como o cliente apresentam um certificado. Isto elimina totalmente o risco de roubo de credenciais, porque não existem palavras-passe para roubar. No entanto, requer uma infraestrutura PKI e um mecanismo para enviar os certificados de cliente para os dispositivos, o que normalmente implica uma solução MDM. Para ambientes BYOD corporativos e implementações de alta segurança, esta é a resposta certa. O PEAP com MSCHAPv2 é o método mais amplamente implementado em ambientes empresariais. Requer apenas um certificado do lado do servidor e canaliza a troca de credenciais dentro de TLS. É nativamente compatível com o Active Directory, o que o torna operacionalmente simples. O risco é que é vulnerável à recolha de credenciais se os utilizadores se ligarem a um ponto de acesso não autorizado com um certificado autoassinado — pelo que a validação do certificado do lado do cliente é inegociável. O EAP-TTLS é semelhante ao PEAP, mas mais flexível no método de autenticação interno. É particularmente útil em ambientes de dispositivos mistos onde existe uma combinação de dispositivos Windows, macOS, iOS e Android com capacidades de suplicante variadas. Para suporte de dispositivos legados — como hardware de ponto de venda mais antigo ou sensores IoT — o EAP-FAST pode ser uma escolha pragmática, pois não requer certificados e utiliza, em alternativa, uma Credencial de Acesso Protegido (PAC). Agora, a vertente do RADIUS na nuvem. Tradicionalmente, o RADIUS era um serviço local — FreeRADIUS num servidor Linux ou Microsoft NPS em 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 local que necessite de autenticação de baixa latência. O RADIUS na nuvem altera significativamente esse cálculo. Um serviço RADIUS na nuvem é alojado e gerido pelo fornecedor. Os seus pontos de acesso enviam pedidos RADIUS através da Internet para o serviço na nuvem, que trata da autenticação junto do seu fornecedor de identidade. A preocupação com a latência é real, mas gerível — os serviços modernos de RADIUS na nuvem estão distribuídos globalmente e as viagens de ida e volta de autenticação são normalmente concluídas em menos de 100 milissegundos, o que é impercetível para os utilizadores finais. A integração com fornecedores de identidade é a dependência crítica. A maioria das plataformas RADIUS na nuvem suporta LDAP, LDAPS, SAML 2.0 e integração direta com Azure AD ou Okta. Para organizações que já utilizam o Microsoft 365, a integração com o Azure AD é o caminho natural — obtém início de sessão único, políticas de acesso condicional e aplicação de MFA, tudo a alimentar a sua camada de controlo de acesso à rede. Para locais que implementam WiFi de convidados em paralelo com redes de funcionários, a arquitetura normalmente separa-as em SSIDs distintos com diferentes políticas de autenticação. As redes de funcionários utilizam 802.1X com credenciais corporativas. As redes de convidados utilizam um Captive Portal ou fluxo de login social. A plataforma da Purple suporta ambos os modelos, e a camada de WiFi analytics abrange ambos, proporcionando-lhe visibilidade sobre o comportamento dos dispositivos, tempo de permanência e utilização da rede sem comprometer a segmentação de segurança. --- RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS (aprox. 2 minutos) --- Permita-me apresentar a sequência prática de implementação e sinalizar os modos de falha que vejo com mais frequência. Comece com a integração do seu fornecedor de identidade. Antes de tocar num único ponto de acesso, confirme que o seu serviço RADIUS na nuvem consegue autenticar-se no seu diretório. Teste com uma conta de serviço, valide a ligação LDAP e confirme que os atributos de pertença a grupos estão a ser devolvidos corretamente — porque precisará deles para as políticas de atribuição de VLAN. Em segundo lugar, planeie a sua estratégia de certificados. Se optar por EAP-TLS, precisa de uma CA, precisa de decidir se vai utilizar uma CA pública ou interna, e precisa de um plano de implementação de MDM para certificados de cliente. Se optar por PEAP, precisa de um certificado de servidor de uma CA fidedigna — não autoassinado — e precisa de enviar o certificado da CA para todos os dispositivos clientes para que a validação do certificado funcione corretamente. Este é o passo que costuma ser ignorado e que causa incidentes de segurança. Em terceiro lugar, configure os seus clientes RADIUS — ou seja, os seus pontos de acesso e controladores — com o segredo partilhado correto e o IP ou nome de anfitrião do servidor. Utilize um segredo partilhado forte, gerado aleatoriamente, e não uma palavra de dicionário. E se o seu fornecedor de RADIUS na nuvem suportar RADIUS sobre TLS — RadSec — utilize-o. Este encripta o tráfego RADIUS em trânsito, o que é particularmente importante quando esse tráfego atravessa a internet pública. Em quarto lugar, teste com um grupo piloto antes da implementação total. As falhas de autenticação em grande escala são disruptivas e difíceis de diagnosticar sob pressão. Realize um piloto com dez a vinte dispositivos, valide os registos de autenticação, confirme se a atribuição de VLAN está a funcionar e verifique se os registos de contabilidade estão a ser gravados corretamente. Os modos de falha que vejo com mais frequência: validação de certificados desativada nos clientes, levando a vulnerabilidades de man-in-the-middle. Segredos partilhados demasiado curtos ou reutilizados em vários locais. Lista de permissões de IP do servidor RADIUS não configurada, fazendo com que os pedidos de autenticação de novos locais sejam rejeitados silenciosamente. E perfis de MDM que não são 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 me fazem regularmente. Posso executar 802.1X numa rede que também tenha dispositivos IoT que não suportam EAP? Sim — utilize o MAC Authentication Bypass como alternativa para dispositivos que não conseguem executar um suplicante, mas coloque esses dispositivos numa VLAN restrita com regras de firewall rigorosas. O 802.1X substitui a encriptação WPA2 ou WPA3? Não — o 802.1X lida com a autenticação. O WPA2-Enterprise ou WPA3-Enterprise lida com a encriptação. Precisa de ambos. O WPA3-Enterprise com 802.1X é a melhor prática atual para novas implementações. Qual é o impacto da latência na autenticação? Com um serviço RADIUS na nuvem bem configurado, conte com 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. Isto está em conformidade com o PCI DSS? O 802.1X com EAP-TLS ou PEAP numa rede devidamente segmentada cumpre o Requisito 1 e o Requisito 8 do PCI DSS para controlo de acesso à rede. Envolva o seu QSA desde o início. --- RESUMO E PRÓXIMOS PASSOS (aprox. 1 minuto) --- Para resumir: o 802.1X com RADIUS na nuvem é a resposta certa para qualquer organização que precise de demonstrar o controlo de acesso à rede a auditores, reduzir o raio de impacto de uma quebra de credenciais ou gerir a autenticação de forma centralizada num património distribuído. A implementação não é trivial, mas é absolutamente gerível com a preparação correta. Acerte primeiro na integração do seu fornecedor de identidade. Escolha o seu método EAP com base no seu parque de dispositivos e na sua capacidade operacional para gerir certificados. Utilize o RadSec se a sua infraestrutura o suportar. E teste antes de implementar em grande escala. Se gere uma rede mista de convidados e funcionários — o que acontece com a maioria dos operadores de hotelaria e retalho — plataformas como a Purple dão-lhe a capacidade de gerir ambos os modelos de autenticação a partir de um único painel de controlo, com a camada de análise a abranger todo o património. Para os seus próximos passos: audite a sua postura atual de controlo de acesso à rede, identifique quais os locais que ainda utilizam PSK partilhado e elabore um plano de migração faseado. Comece pelos locais de maior risco — aqueles que estão no âmbito do PCI DSS ou que lidam com dados sensíveis — e avance a partir daí. Obrigado por ouvir. Estão disponíveis mais briefings técnicos em purple.ai.