Migração de RADIUS On-Premises (NPS) para RADIUS as a Service

ROTEIRO DE PODCAST: Migrar de RADIUS On-Premises (NPS) para RADIUS-as-a-Service Duração: ~10 minutos | Voz: Inglês do Reino Unido, Masculina, tom de Consultor Sénior --- SEGMENTO 1: INTRODUÇÃO E ENQUADRAMENTO Bem-vindo à série de briefings técnicos da Purple WiFi. Hoje abordamos uma migração que faz parte do plano de trabalho de um número significativo de equipas de TI empresariais neste momento: a transição de um RADIUS on-premises - especificamente o Network Policy Server da Microsoft - para um modelo de RADIUS-as-a-Service alojado na cloud. Se gere a autenticação WiFi num grupo 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 prestou-nos um bom serviço durante a maior parte das últimas duas décadas, mas a sobrecarga operacional, o risco de ponto único de falha e as limitações de escalabilidade são cada vez mais difíceis de justificar - particularmente quando as alternativas nativas da cloud oferecem agora fiabilidade de classe 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 reais de implementação 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 infraestrutura de rede. O RADIUS - Remote Authentication Dial-In User Service - é o protocolo definido no RFC 2865 que lida com autenticação, autorização e gestão de contas para 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 age 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 de RADIUS da Microsoft incluída no Windows Server - está a correr essa lógica de autenticação em hardware que possui, num data center 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 do 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 de hotéis com propriedades em todo o Reino Unido - está a correr um NPS centralizado com dependência de WAN, ou está a implementar instâncias de NPS em cada site e a geri-las individualmente. Nenhuma das duas opções é elegante. O segundo é a disponibilidade. Uma única instância de 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 custos de hardware e licenciamento, e continua a não oferecer a redundância geográfica que um serviço de nuvem fornece de forma nativa. O terceiro é a escalabilidade. O NPS foi concebido para ambientes de 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 de NPS tornam-se muito evidentes. A latência de autenticação aumenta e os utilizadores sofrem falhas de ligação exactamente no momento em que menos se pode dar ao luxo disso. O RADIUS-as-a-Service aborda todas estas três limitaçõ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 de RADIUS alojados na nuvem, em vez de um servidor local. Os pedidos de autenticação são equilibrados em termos de carga por 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 802.1X com EAP-TLS, PEAP-MSCHAPv2 ou EAP-TTLS, dependendo da combinação de dispositivos dos seus clientes. A diferença reside no local onde o servidor RADIUS se encontra e em quem é responsável pela sua continuidade operacional. Existe uma consideração de segurança importante que quero abordar diretamente, porque surge em quase todas as conversas com os 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 do RADIUS na nuvem. Isto é mitigado através de dois mecanismos. Primeiro, o tráfego RADIUS entre o Servidor de Acesso à Rede 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 as implementações modernas, deve estar a executar RadSec - RADIUS sobre TLS, definido no RFC 6614 - que envolve toda a conversação RADIUS num túnel TLS. Isto proporciona-lhe uma encriptação na camada de transporte equivalente ao 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 digno de consideração deve suportar o RadSec como padrão. Do lado da integração de identidade, os serviços de RADIUS na nuvem suportam normalmente ligações LDAP e LDAPS de volta ao seu Active Directory local, ou integração nativa com o Azure Active Directory e Microsoft 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 identidade existente, mantendo os seus processos de gestão do ciclo de vida do utilizador existentes. Para organizações conscientes da conformidade - e isso inclui qualquer pessoa que lide com dados de cartões de pagamento sob a norma PCI-DSS, ou dados pessoais ao abrigo do 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 pode 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 de 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. Configure a sua instância de RADIUS na nuvem e aponte um SSID que não seja de produção ou um único site de teste para ela. 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 contabilidade (accounting) estão a fluir corretamente. A fase três é a execução 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 destinos de autenticação, com o serviço na nuvem como primário e o NPS como fallback. Execute nesta configuração durante um período 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 (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 rollback documentado e testado. A fase cinco é o desmantelamento (decommission). Assim que validar o funcionamento estável durante trinta dias após a transição, desmantele 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 fidedignas. Resolva isto através do seu MDM ou de Política 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 do segredo partilhado. Se os seus segredos partilhados do NPS existentes forem fracos, utilize 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 alteração de dependência. Com o RADIUS na nuvem, a conectividade à internet torna-se uma dependência para a autenticação. Mitigue esta situação 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, por norma, a sua postura 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 QSA. Quanto tempo demora uma migração completa? Para um único local, duas a quatro semanas. Para um património multilocal de cinquenta ou mais localizações, planeie 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-as-a-Service são convincentes a nível operacional, financeiro e de conformidade. A migração em si apresenta um risco reduzido 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 de RadSec para segurança de transporte - o que recomendo 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 confiança de certificados antes de começar. Para as organizações que executam a plataforma de acesso de convidados da Purple WiFi, a funcionalidade RADIUS-as-a-Service integra-se diretamente com o fluxo de autenticação de WiFi de convidados, proporcionando-lhe um único plano de controlo para a autenticação corporativa 802.1X e para a gestão de acessos à rede de convidados - com as análises e relatórios de conformidade integrados. Agradecemos a sua atenção. 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