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

Como Implementar a Autenticação 802.1X com Cloud RADIUS Uma Sessão de Informação de Inteligência da Purple WiFi --- INTRODUÇÃO E ENQUADRAMENTO (aprox. 1 minuto) --- Bem-vindo à Sessão de Informação de Inteligência da Purple WiFi. Sou o vosso anfitrião e hoje vamos detalhar a autenticação 802.1X com Cloud RADIUS - o que é, por que razão é crucial neste momento e como implementá-la eficazmente numa infraestrutura multi-site. Se gere a infraestrutura de WiFi de um grupo hoteleiro, de uma cadeia de retalho, de um estádio ou de uma organização do setor público, este é um daqueles temas que surge constantemente - e por um bom motivo. O panorama das ameaças mudou. As redes PSK partilhadas 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 ciber estão a fazer perguntas cada vez mais exigentes sobre o controlo de acessos à rede. E a boa notícia é que o RADIUS baseado na nuvem tornou o 802.1X genuinamente viável de implementar à escala, sem os custos fixos de infraestrutura local que anteriormente o tornavam impraticável para redes distribuídas. Vamos então começar. --- ANÁLISE TÉCNICA DETALHADA (aprox. 5 minutos) --- Primeiro, vamos garantir que estamos todos alinhados com a mesma definição. O IEEE 802.1X é uma norma de controlo de acessos à rede baseada em portas. Define uma estrutura de autenticação que funciona na Camada 2 do modelo OSI - ou seja, opera antes de ser concedida qualquer conectividade IP ao dispositivo. Esta é a principal diferença em relação à autenticação na camada de aplicação. Com o 802.1X, um dispositivo não consegue entrar na rede até que tenha sido autenticado positivamente. O protocolo tem três componentes. O requerente (supplicant) - 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 nas implementações modernas é o seu serviço de 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 - 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 transmite essa troca para o servidor RADIUS utilizando o protocolo RADIUS através de UDP, tipicamente na porta 1812 para autenticação e 1813 para contabilidade (accounting). O servidor RADIUS valida as credenciais num diretório de identidades - como o Active Directory, Azure AD ou um diretório LDAP - e devolve uma mensagem de Access-Accept ou de 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 são extremamente importantes. Atualmente, a seleção do método EAP é o ponto onde muitas implementações falham. Existem vários métodos EAP de uso comum que apresentam perfis de segurança e requisitos operacionais muito diferentes. O EAP-TLS é o padrão de ouro. Requer autenticação mútua de certificados - tanto o servidor como o cliente apresentam um certificado. Isto elimina inteiramente o risco de roubo de credenciais, porque não existem palavras-passe para roubar. Mas requer uma infraestrutura de PKI e um mecanismo para enviar os certificados de cliente para os dispositivos, o que normalmente significa uma solução de MDM. Para ambientes corporativos de BYOD e implementações de alta segurança, esta é a resposta certa. O PEAP com MSCHAPv2 é o método mais amplamente implementado em ambientes empresariais. Apenas requer 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 é ser 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 é não negociável. O EAP-TTLS é semelhante ao PEAP, mas mais flexível no método de autenticação interno. É particularmente útil em ambientes com dispositivos mistos, onde tem uma combinação de dispositivos Windows, macOS, iOS e Android com diferentes capacidades de suplicante. Para o suporte de dispositivos legados - pense em hardware de ponto de venda mais antigo ou sensores de IoT - o EAP-FAST pode ser uma escolha pragmática, pois não requer certificados e utiliza, em alternativa, uma Credencial de Acesso Protegido. Agora, a vertente de cloud RADIUS. 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 cloud RADIUS altera significativamente esse cálculo. Um serviço de cloud RADIUS é alojado e gerido pelo fornecedor. Os seus pontos de acesso enviam pedidos RADIUS através da internet para o serviço de cloud, 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 cloud RADIUS sã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 os fornecedores de identidade é a dependência crítica. A maioria das plataformas de cloud RADIUS suporta LDAP, LDAPS, SAML 2.0 e integração direta com Azure AD ou Okta. Para as organizações que já executam 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 imposição de MFA, tudo a alimentar a sua camada de controlo de acesso à rede. Para recintos que implementam WiFi para convidados juntamente 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 analytics de WiFi funciona em ambos, oferecendo 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) --- Deixe-me apresentar a sequência prática de implementação e destacar 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 em 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. Segundo, 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 uma 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 de certificados funcione corretamente. Este é o passo que costuma ser ignorado e que causa incidentes de segurança. Terceiro, configure os seus clientes RADIUS - que são os seus pontos de acesso e controladores - com o segredo partilhado correto e o IP do servidor ou nome de anfitrião. Utilize um segredo partilhado forte, gerado aleatoriamente, e não uma palavra de dicionário. E se o seu fornecedor de RADIUS em 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. Quarto, teste com um grupo-piloto antes da implementação total. As falhas de autenticação em larga 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 vulnerabilidade 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 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 recurso 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 trata da 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 nova autenticaçã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 centralmente num parque distribuído. A implementação não é trivial, mas é perfeitamente gerível com a preparação correta. Comece por configurar corretamente a integração com o 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 RadSec se a sua infraestrutura o suportar. E teste antes de implementar em escala. Se gere uma rede mista de convidados e funcionários - como a maioria dos operadores de hotelaria e retalho - plataformas como a Purple oferecem-lhe a capacidade de gerir ambos os modelos de autenticação a partir de um único painel de controlo, com a camada de analítica a abranger todo o parque. 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 para os restantes. Obrigado por nos ouvir. Estão disponíveis mais resumos técnicos em purple.ai.