Migração de RADIUS Local (NPS) para RADIUS as a Service

GUIÃO DE PODCAST: Migrar de RADIUS On-Premises (NPS) para RADIUS as a Service Duração: ~10 minutos | Voz: Inglês do Reino Unido, Masculino, tom de Consultor Sénior --- SEGMENTO 1: INTRODUÇÃO E CONTEXTO Bem-vindo à série de briefings técnicos da Purple WiFi. Hoje estamos a abordar uma migração que está no roteiro de um número significativo de equipas de TI empresariais neste momento: a transição do RADIUS on-premises — especificamente o Network Policy Server da Microsoft — para um modelo de RADIUS as a Service alojado na nuvem. Se gere a autenticação WiFi numa cadeia de hotéis, numa rede de retalho, num estádio ou num campus do setor público, isto é diretamente relevante para si. O modelo NPS on-premises serviu-nos bem durante a maior parte de duas décadas, mas a sobrecarga operacional, o risco de ponto único de falha e as limitações de escala são cada vez mais difíceis de justificar — especialmente quando as alternativas nativas da nuvem oferecem agora fiabilidade de nível empresarial a uma fração do custo total de propriedade. Nos próximos dez minutos, iremos cobrir a arquitetura técnica de ambas as abordagens, percorrer uma metodologia de migração estruturada, analisar dois cenários de implementação do mundo real e terminar com as principais estruturas de decisão de que necessita para tomar esta decisão com confiança. Vamos a isso. --- SEGMENTO 2: ANÁLISE TÉCNICA DETALHADA Primeiro, vamos garantir que estamos alinhados sobre o que o RADIUS realmente faz na sua pilha de rede. O RADIUS — Remote Authentication Dial-In User Service — é o protocolo definido no RFC 2865 que lida com a autenticação, autorização e contabilização do acesso à rede. Num contexto de WiFi, é a espinha dorsal do controlo de acesso baseado em portas IEEE 802.1X. Quando um dispositivo se liga a um SSID WPA2-Enterprise ou WPA3-Enterprise, o ponto de acesso funciona como um cliente RADIUS — o que chamamos de Network Access Server — e encaminha o pedido de autenticação para o servidor RADIUS. O servidor valida as credenciais, normalmente contra o Active Directory ou um diretório LDAP, e devolve uma resposta Access-Accept ou Access-Reject. Esse é o fluxo fundamental. Agora, no modelo NPS on-premises — o Network Policy Server é a implementação RADIUS da Microsoft incluída no Windows Server — está a executar essa lógica de autenticação em hardware próprio, num centro de dados ou sala de servidores que mantém. O servidor NPS aloja as suas políticas de rede, a sua infraestrutura de certificados para EAP-TLS ou PEAP-MSCHAPv2 e as suas políticas de pedido de ligação. Funciona. É maduro. Mas traz consigo um conjunto de realidades operacionais que se acumulam ao longo do tempo. A primeira é a dependência de hardware. O seu servidor NPS é uma máquina física ou virtual que requer aplicação de patches, planeamento de capacidade e eventual renovação de hardware. Numa implementação multi-site — por exemplo, um grupo hoteleiro com propriedades em todo o Reino Unido — ou está a executar um NPS centralizado com dependência de WAN, ou está a implementar instâncias de NPS em cada local e a geri-las individualmente. Nenhuma das opções é elegante. O segundo é a disponibilidade. Uma única instância NPS é um ponto único de falha para toda a sua infraestrutura de autenticação. Sim, pode implementar o NPS num par de failover, mas isso duplica os seus custos de hardware e licenciamento, e continua a não lhe dar a redundância geográfica que um serviço de nuvem fornece nativamente. O terceiro é a escalabilidade. O NPS foi concebido para ambientes LAN corporativos. Quando está a lidar com milhares de pedidos de autenticação simultâneos durante um evento num estádio ou num pico de um centro de conferências, as limitações de rendimento de uma única instância NPS tornam-se muito evidentes. A latência de autenticação dispara e os utilizadores sofrem falhas de ligação exatamente no momento em que menos se pode dar ao luxo de as ter. O RADIUS as a Service aborda todas estas três restrições a nível de arquitetura. O fornecedor de RADIUS na nuvem executa um cluster distribuído e geo-redundante de servidores RADIUS. Os seus pontos de acesso apontam para endpoints RADIUS alojados na nuvem, em vez de um servidor local. Os pedidos de autenticação são equilibrados em termos de carga em todo o cluster, e o failover é automático e transparente. O fornecedor trata da aplicação de patches, do dimensionamento da capacidade e da gestão de certificados. Do seu ponto de vista como operador de rede, o RADIUS torna-se um serviço consumido em vez de um componente gerido. Os protocolos de autenticação em si não mudam. Continua a executar o IEEE 802.1X com EAP-TLS, PEAP-MSCHAPv2 ou EAP-TTLS, dependendo do seu mix de dispositivos cliente. A diferença reside no local onde o servidor RADIUS reside e em quem é responsável pela sua continuidade operacional. Existe uma consideração de segurança importante aqui que quero abordar diretamente, porque surge em quase todas as conversas com clientes. Mover o RADIUS para a nuvem significa que o seu tráfego de autenticação está a atravessar a internet pública para chegar ao endpoint RADIUS na nuvem. Isto é mitigado através de dois mecanismos. Primeiro, o tráfego RADIUS entre o Network Access Server e o servidor RADIUS é protegido através de um segredo partilhado e de autenticação de mensagens baseada em MD5. Segundo, e mais importante para implementações modernas, deve executar o RadSec — RADIUS sobre TLS, definido no RFC 6614 — que envolve toda a conversa RADIUS num túnel TLS. Isto proporciona-lhe uma encriptação na camada de transporte equivalente a HTTPS, eliminando a vulnerabilidade do MD5 e fornecendo autenticação mútua entre o NAS e o servidor RADIUS. Qualquer fornecedor de RADIUS na nuvem que valha a pena considerar deve suportar o RadSec como padrão. Do lado da integração de identidade, os serviços de RADIUS na nuvem suportam tipicamente ligações LDAP e LDAPS de volta ao seu Active Directory local, ou integração nativa com o Azure Active Directory e Entra ID via SAML ou SCIM. Isto significa que não precisa de migrar o seu diretório de utilizadores — o serviço de RADIUS na nuvem consulta o seu repositório de identidades existente, mantendo os seus processos de gestão de ciclo de vida de utilizadores atuais. Para organizações preocupadas com a conformidade — e isso inclui qualquer pessoa que lide com dados de cartões de pagamento sob o PCI DSS, ou dados pessoais sob o GDPR — os fornecedores de RADIUS na nuvem com certificação SOC 2 Type II e acreditação ISO 27001 oferecem uma postura de conformidade mais forte do que a maioria das organizações consegue alcançar com uma infraestrutura NPS autogerida. --- SEGMENTO 3: RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS Muito bem, vamos falar sobre como executar esta migração sem colocar a sua infraestrutura de autenticação offline. A metodologia que recomendo é uma abordagem em cinco fases. A fase um é a auditoria e inventário. Documente cada cliente RADIUS — cada ponto de acesso, cada switch, cada concentrador VPN — juntamente com o seu segredo partilhado atual, o método EAP que está a utilizar e quaisquer atributos específicos do fornecedor nas suas políticas NPS. Este é o trabalho menos glamoroso, mas ignorá-lo é a causa número um de falhas na migração. A fase dois é a implementação piloto. Ative a sua instância de RADIUS na nuvem e aponte um SSID que não seja de produção ou um único site de testes para a mesma. Valide se o seu método EAP funciona de ponta a ponta, se a sua integração de identidade está a funcionar e se os seus dados de accounting estão a fluir corretamente. A fase três é o funcionamento em paralelo. Este é o passo crítico de mitigação de riscos. Configure os seus pontos de acesso com o servidor NPS local e o servidor RADIUS na nuvem como alvos de autenticação, com o serviço na nuvem como primário e o NPS como fallback. Execute esta configuração durante um mínimo de duas semanas ao longo de um ciclo de negócios completo. Monitorize as taxas de sucesso de autenticação, a latência e quaisquer discrepâncias de políticas. A fase quatro é a transição definitiva (cutover). Remova a configuração de fallback do NPS e assuma o RADIUS na nuvem como a sua única infraestrutura de autenticação. Faça isto durante uma janela de manutenção planeada e tenha um procedimento de reversão (rollback) documentado e testado. A fase cinco é a desativação. Depois de validar o funcionamento estável durante trinta dias após a transição, desative os servidores NPS e recupere os recursos de hardware ou de máquinas virtuais. Os erros que vejo com mais frequência são: problemas na cadeia de confiança de certificados — especificamente, dispositivos de clientes que não confiam no certificado do servidor RADIUS na nuvem porque a CA não está na sua lista de fidedignos. Resolva isto através do seu MDM ou de Políticas de Grupo antes da transição. O segundo erro comum são as regras de firewall. O RADIUS na nuvem requer tráfego de saída UDP 1812 e 1813 dos seus pontos de acesso para os endpoints na nuvem, ou TCP 2083 para RadSec. Certifique-se de que o perímetro da sua rede permite este tráfego. Terceiro: complexidade dos segredos partilhados. Se os seus segredos partilhados do NPS existentes forem fracos, aproveite a migração como uma oportunidade para rodar para segredos criptograficamente fortes ou, melhor ainda, mude para RadSec e elimine totalmente os segredos partilhados. --- SEGMENTO 4: PERGUNTAS E RESPOSTAS RÁPIDAS Deixe-me passar pelas perguntas que recebo com mais frequência sobre este tema. Podemos manter o Active Directory local? Sim, absolutamente. O RADIUS na nuvem liga-se ao seu AD local via LDAPS. O seu diretório permanece onde está. O que acontece se a nossa ligação à internet falhar? Esta é a principal mudança de dependência. Com o RADIUS na nuvem, a conectividade à internet torna-se uma dependência para a autenticação. Mitigue isto com ligações WAN redundantes ou um proxy RADIUS local que armazene em cache a autenticação de dispositivos conhecidos durante as interrupções. Isto afeta a nossa conformidade com o PCI DSS? A transição para um fornecedor certificado de RADIUS na nuvem melhora, tipicamente, o seu estado de conformidade. Certifique-se de que o seu fornecedor pode fornecer relatórios SOC 2 Type II e que está incluído no âmbito da sua avaliação anual de QSA. Quanto tempo demora uma migração completa? Para um único local, duas a quatro semanas. Para uma infraestrutura multilocal de cinquenta ou mais localizações, planeie de três a seis meses com uma implementação faseada. --- SEGMENTO 5: RESUMO E PRÓXIMOS PASSOS Para concluir: os argumentos a favor da migração do NPS local para o RADIUS como Serviço são convincentes a nível operacional, financeiro e de conformidade. A migração em si é de baixo risco quando executada com uma fase estruturada de funcionamento em paralelo. As principais decisões técnicas são a seleção do seu método EAP, a sua abordagem de integração de identidade e a implementação ou não do RadSec para segurança de transporte — o que eu recomendaria vivamente para qualquer nova implementação. Os seus próximos passos imediatos: realize a auditoria dos seus atuais clientes e políticas RADIUS, contacte o seu fornecedor de RADIUS na nuvem para obter um ambiente piloto e reveja as suas regras de firewall e cadeias de fidedignidade de certificados antes de começar. Para organizações que utilizam a plataforma de acesso de convidados da Purple WiFi, a funcionalidade de RADIUS como Serviço integra-se diretamente com o fluxo de autenticação de WiFi de convidados, proporcionando-lhe um único painel de controlo tanto para a autenticação corporativa 802.1X como para a gestão de acessos à rede de convidados — com análises e relatórios de conformidade integrados. Obrigado por ouvir. O guia de referência técnica completo está disponível no website da Purple, e a nossa equipa de soluções está disponível para uma conversa de definição de âmbito se estiver pronto para avançar. --- FIM DO GUIÃO