Guia de RADIUS-as-a-Service para Redes Multi-site
Published
A rede de convidados do hotel funciona, mas o SSID dos funcionários tem uma palavra-passe partilhada diferente em cada propriedade, uma caixa registadora foi parar à VLAN errada e ninguém consegue confirmar se o dispositivo de um antigo prestador de serviços ainda tem acesso. A equipa de rede pode resolver cada problema localmente, mas o mesmo trabalho continua a reaparecer em vários locais, pisos e plataformas de pontos de acesso.
O RADIUS-as-a-Service transfere as decisões de autenticação para uma plataforma alojada, deixando os pontos de acesso, switches e controladores encarregues de as aplicar. Isto pode simplificar as políticas numa infraestrutura distribuída, mas não torna a rede independente da WAN, do fornecedor de identidade ou da infraestrutura de certificados. Uma avaliação sólida começa com uma pergunta mais difícil do que saber se o serviço tem um SLA: o que acontece a cada classe de utilizador e dispositivo quando uma dependência falha?
Índice
- Por que a centralização das decisões de rede muda tudo
- As origens e os padrões por trás do Hosted RADIUS moderno
- Como funciona realmente uma arquitetura de RADIUS-as-a-Service
- Comparação entre Hosted RADIUS e implementações On-Premises
- SLA, failover de várias regiões e o que realmente falha
- Segurança, conformidade e migração a partir do RADIUS legado
- Escolha e implementação de um serviço Hosted RADIUS
Por Que Razão a Centralização das Decisões de Rede Muda Tudo
Um padrão familiar numa cadeia de hotéis é um SSID de convidados que se multiplicou ao longo do tempo, credenciais de funcionários partilhadas entre equipas e portas de switch configuradas de acordo com quem trabalhou em último lugar nesse piso. O problema não é apenas a dispersão da configuração. É que os dispositivos locais detêm partes da política de acesso, pelo que uma alteração numa propriedade pode não corresponder à alteração noutra.
O RADIUS oferece uma forma de centralizar a decisão. Um ponto de acesso ou servidor de acesso à rede envia um pedido de autenticação a um serviço partilhado, que verifica a identidade e devolve uma decisão de acesso. O dispositivo de rede continua a aplicar essa decisão, mas o operador pode gerir a identidade e as políticas centralmente, em vez de duplicar regras em cada controlador ou switch.
Essa divisão é a ideia central por trás do RADIUS alojado. Um serviço central pode retornar atributos que mapeiam um funcionário, convidado, prestador de serviços ou dispositivo para uma rede ou VLAN apropriada. Quando alguém sai, uma identidade gerida centralmente pode ser revogada em vez de depender de cada local para atualizar as definições locais. Os registos de contabilização (accounting) também podem ajudar os operadores a investigar que identidade utilizou a rede e quando.
Os alertas de urgência ainda importam
A centralização reduz alguns tipos de trabalho operacional, mas não remove a responsabilidade pelo design da rede. O serviço alojado não pode corrigir um registo de identidade incorreto, uma VLAN mal associada ou um ponto de acesso que não consegue alcançar o seu endpoint configurado. Nem decide automaticamente que dispositivos devem manter o acesso quando uma filial perde a conectividade.
Para quem está de prevenção, a mudança passa de manter servidores e políticas de autenticação locais para gerir as dependências e o comportamento em caso de falha de um serviço partilhado. Isso inclui testar a acessibilidade, validar os atributos devolvidos, monitorizar a contabilidade e acordar o que deve acontecer durante uma interrupção.
Regra operacional: Centralize a política de rotina, mas torne a política de falha explícita para cada grupo de utilizadores e dispositivos.
A sessão de um convidado, o portátil de um funcionário, uma caixa registadora, uma câmara e um sensor de edifício não precisam necessariamente do mesmo recurso (fallback). Tratá-los como uma população genérica de "WiFi" pode transformar uma interrupção na autenticação quer numa interrupção de negócio quer numa exceção de segurança evitável.
As Origens e os Padrões por Trás do RADIUS Alojado Moderno
O RADIUS começou em 1991 após a Merit Network ter solicitado um sistema de autenticação centralizado para acesso dial-up à NSFNET. A Livingston Enterprises construiu a primeira implementação para os seus servidores de acesso à rede PortMaster. A decisão de design que ainda molda as implementações foi a combinação de autenticação, autorização e contabilidade num único modelo cliente-servidor, em vez de sistemas proprietários separados para cada função. História do RADIUS e enquadramento do protocolo
Essa divisão é importante para mais do que a compatibilidade. Como a separação entre NAS e autenticador é fixa no protocolo, uma falha na WAN ou no fornecedor de identidade altera quem consegue alcançar o servidor partilhado, e não as funções em si, razão pela qual o design de recurso (fallback), e não a escolha do protocolo, decide o que acontece no local.
O histórico de normas mostra como o modelo se tornou interoperável. O IETF documentou o RADIUS em janeiro de 1997 como RFC 2058 para autenticação e RFC 2059 para accounting. O RFC 2138 e o RFC 2139 substituíram-nos no final desse ano, seguidos pelo RFC 2865 e pelo RFC 2866 em 2000. O RFC 2865 refinou o protocolo após as primeiras implementações revelarem problemas em maior escala, um lembrete útil de que esta especificação foi consolidada por falhas operacionais e não concebida teoricamente sem falhas. Documentos do grupo de trabalho IETF RADIUS
Por que razão os padrões antigos ainda importam
Para um grupo hoteleiro ou operador de recintos, a separação entre o dispositivo de acesso e o servidor de autenticação continua a ser muito útil. Um controlador sem fios de um fabricante e switches de outro podem enviar pedidos para um serviço de políticas comum, desde que implementem um comportamento RADIUS compatível. As decisões centralizadas de identidade e acesso tornam-se possíveis sem a necessidade de comprar o ecossistema completo de controlo de acessos de um único fornecedor.
As atribuições de portas mostram como o trabalho de normalização afeta as operações diárias. As primeiras implementações utilizavam comummente a porta UDP 1645, enquanto a porta UDP 1812 se tornou a atribuição formal para autenticação ao abrigo da RFC 2865. Os equipamentos que ainda utilizam a porta 1645 por predefinição irão falhar contra um ponto de extremidade alojado que espera a porta 1812, pelo que deve verificar o suporte de cada dispositivo antes de configurar firewalls, pontos de extremidade regionais e planos de migração.
A segurança do transporte é uma preocupação atual. O RFC 6614 define RADIUS sobre TLS, ou RadSec, com a porta TCP 2083 como o destino predefinido e requisitos de proteção de integridade. Também alerta que o estado e o processamento da ligação TLS podem criar uma carga mais elevada do que o UDP tradicional, pelo que uma arquitetura segura necessita de reutilização de ligações, tentativas limitadas e planeamento de capacidade, e não apenas de uma nova porta. Trate esse aviso de carga como uma questão de modo de falha: um ponto de extremidade que cede quando centenas de pontos de acesso se voltam a ligar em simultâneo após uma falha na WAN é pior do que um que degrada gradualmente. RFC 6614 sobre RADIUS sobre TLS
O RFC 9813 de 2025 da IETF documenta considerações operacionais para chaves pré-partilhadas TLS e a migração de RADIUS/UDP para RADIUS/TLS. Esse trabalho é relevante ao avaliar como um fornecedor gere certificados ou chaves, limites de proxy e migração faseada. Normas IETF RADIUS e trabalho relacionado
Como funciona realmente uma arquitetura RADIUS-as-a-Service
Um design RADIUS alojado é mais fácil de avaliar quando separa as suas três funções dos seus três planos. As funções são a autenticação, a autorização e a contabilização (accounting). Os planos são a identidade, o transporte e os relatórios. A proposta de um fornecedor pode juntá-los, mas os operadores precisam de saber qual o componente que valida a identidade, qual o que transporta o pedido e onde vão parar os dados de sessão.
Do pedido de ligação à política de rede
Quando um utilizador ou dispositivo tenta ligar-se, um ponto de acesso ou controlador atua como o Servidor de Acesso à Rede. Envia o pedido para o RADIUS. O serviço verifica a identidade enviada ou as credenciais do dispositivo, frequentemente utilizando um fornecedor de identidades ligado ou um acordo de confiança de certificados, e depois devolve uma decisão de aceitação ou rejeição.
Um pedido aceite pode conter atributos de autorização, como a atribuição de VLAN ou outros parâmetros de rede. O ponto de acesso ou controlador aplica essas instruções. Numa analogia com um hotel, o ponto de acesso é o porteiro, o serviço RADIUS alojado é o diretório de identidades e os atributos devolvidos são a pulseira que determina em que áreas a pessoa pode entrar.
O serviço alojado liga o plano de identidade a sistemas como o Microsoft Entra ID, Okta, Google Workspace, uma plataforma de gestão de dispositivos móveis ou um sistema de gestão hoteleira (PMS). A integração exata depende do serviço e do método de acesso. Não assuma que a existência de um conector significa que todas as políticas podem ser avaliadas da forma que o seu local exige. Teste casos de identidade e de dispositivos, incluindo ex-colaboradores, dispositivos partilhados e clientes de terceiros.
A contabilização (Accounting) não é um extra opcional
Os registos de contabilidade (Accounting) registam eventos de sessão e informações de utilização de forma independente da decisão inicial de autenticação. Esses registos podem suportar auditorias, planeamento de capacidade, imputação de custos e investigações, mesmo quando outro sistema realiza parte da verificação de identidade. Para operações em múltiplos locais, defina como gerir atualizações diferidas, retransmissões, registos de paragem em falta e failover de endpoints regionais.
O plano de transporte transporta pedidos entre o dispositivo de rede e o RADIUS. O RADIUS tradicional usa comummente UDP; o RadSec utiliza TCP e TLS. O plano de relatórios recolhe evidências de autenticação e contabilidade para que os operadores possam rever decisões em vez de inferir o acesso apenas a partir dos registos de associação sem fios.
Ao comparar serviços, mapeie cada componente e fluxo de dados antes de assinar. Um recurso útil é este guia sobre soluções de controlo de acesso à rede, especialmente se o RADIUS fizer parte de um design mais amplo de políticas e aplicação.
Comparar o RADIUS alojado com implementações locais
O RADIUS alojado e o RADIUS no local (on-premises) utilizam o mesmo protocolo. Os dispositivos de acesso continuam a ser Network Access Servers em qualquer um dos casos; o que muda é quem executa o servidor de autenticação partilhado e o que fica posicionado entre este e os seus locais. Se for gerido por si, a disponibilidade é um problema de engenharia na sua sala de servidores. Se for adquirido como serviço alojado, o mesmo problema é transferido para os seus caminhos WAN, cadeia de identidade e confiança de certificados - nenhum dos quais o fornecedor detém em seu nome.
| Critério | RADIUS alojado | RADIUS On-Premises |
|---|---|---|
| Trabalho de infraestrutura | O fornecedor opera a plataforma alojada; a sua equipa continua a gerir a configuração do cliente, as políticas e a integração. | A sua equipa opera o servidor, o software, o sistema operativo, a monitorização e os planos de recuperação. |
| Política multi-site | Uma política central pode servir equipamentos em vários locais, dependendo da conectividade e de implementações compatíveis. | Um servidor central ou uma implementação site a site podem funcionar, mas a sua equipa é responsável pelo modelo de replicação e consistência. |
| Compatibilidade com dispositivos de rede | Depende dos atributos RADIUS suportados, das opções de transporte e dos dispositivos de acesso implementados. | A sua equipa controla a configuração do servidor, mas continua a ser necessário validar o comportamento em switches, controladores e pontos de acesso. |
| Segurança de transporte | O suporte a RadSec pode proteger o transporte, com gestão de certificados e capacidade TLS a projetar. | O RadSec também pode ser implementado localmente, mas a sua equipa gere os certificados, as ligações e o dimensionamento. |
| Responsabilidade por falhas | O fornecedor trata das operações da plataforma; a sua equipa deve testar o comportamento da WAN, da identidade, dos pontos finais e do fallback local. | A sua equipa controla a disponibilidade local, mas deve conceber e manter a redundância e a recuperação. |
| Estrutura de custos | Frequentemente fornecido como uma subscrição do serviço; avalie o contrato e o âmbito operacional incluído. | Pode utilizar a infraestrutura existente, mas o tempo da equipa, a manutenção e a substituição continuam a ser da sua responsabilidade. |
Decida pelo modo de falha, não por slogans
O RFC 2865 codifica a separação entre o dispositivo de acesso e o servidor de autenticação partilhado (RFC 2865); a disponibilização em nuvem altera onde esse servidor é executado, e não a função que os seus switches, controladores e pontos de acesso desempenham. Portanto, a questão útil é idêntica para ambos os modelos: quando a autenticação fica inacessível, o que continua a funcionar no local?
Utilize uma solução alojada quando puder aceitar que uma falha no caminho da WAN num hotel ou arena é um problema que tem de resolver localmente, através de SSIDs sobreviventes, políticas em cache ou de recurso e comportamentos de AP que tenha testado. Utilize uma solução local quando tiver capacidade para manter operações de servidor 24 horas por dia, 7 dias por semana, assumindo a rotação de certificados, a aplicação de patches e a redundância. Um servidor gerido localmente não é mais resiliente por predefinição. Já auditei muitos servidores locais únicos a executar certificados expirados e sem failover, mantendo a rede operacional por hábito e não por conceção.
O modelo de implementação determina menos do que o design de tolerância a falhas que o envolve.
A postura de segurança depende da implementação e não da localização. Pergunte onde são armazenados os segredos partilhados e certificados, quem pode ler os dados de accounting, como as solicitações são protegidas em trânsito e como o serviço encaminha por proxy as solicitações às quais não consegue responder diretamente. Caixas registadoras, WiFi de convidados, câmaras e dispositivos IoT partilham tipicamente o mesmo caminho de autenticação, pelo que um ponto fraco em qualquer um dos modelos tende a emergir em todo o lado ao mesmo tempo. Se está a ponderar entre uma plataforma alojada e uma infraestrutura gerida pelo cliente, uma comparação de RADIUS alojado localmente ajuda a definir quais as responsabilidades operacionais que manteria.
SLA, failover de várias regiões e o que realmente falha
O tempo de atividade da plataforma de um fornecedor, o seu compromisso de serviço RADIUS e a disponibilidade de autenticação num local específico estão relacionados, mas não são intermutáveis. Uma plataforma alojada pode estar operacional enquanto um hotel não a consegue alcançar devido a uma falha de WAN ou DNS. Um local também pode alcançar o RADIUS enquanto o seu fornecedor de identidade ou cadeia de certificados impede uma autenticação bem-sucedida.
Classifique a resposta a falhas por utilizador e dispositivo
- Interrupção da WAN: As novas autenticações na nuvem podem falhar. As sessões existentes podem continuar, dependendo do comportamento da rede local e da política de sessão. Questione se a sobrevivência local foi testada na sua parque de pontos de acesso.
- Falha de DNS: Os dispositivos podem não resolver os pontos finais do serviço se a sua configuração depender de DNS. Confirme como os pontos finais são aprovisionados e o que o equipamento de acesso faz quando a resolução falha.
- Interrupção do fornecedor de identidade: O serviço RADIUS pode estar acessível, mas incapaz de validar uma nova identidade. As credenciais em cache podem ajudar, mas também podem manter o acesso após a alteração do estado de um utilizador.
- Expiração do certificado ou interrupção da CA: A autenticação baseada em certificados pode falhar quando um certificado necessário for inválido, expirar ou não for de confiança. A monitorização do ciclo de vida dos certificados deve incluir os dispositivos e a cadeia de confiança envolvida, e não apenas o servidor RADIUS.
- Interrupção do plano de gestão: Os operadores podem perder a capacidade de alterar políticas ou revogar acessos, mesmo que a autenticação continue. Estabeleça como as alterações de emergência são efetuadas e registadas.
Um SSID de emergência com palavra-passe partilhada, o acesso baseado em MAC e credenciais em cache não são formas equivalentes de resiliência. Cada uma troca a disponibilidade imediata por segurança: as chaves partilhadas são difíceis de revogar de forma direcionada, os identificadores MAC podem ser falsificados e as decisões em cache podem durar mais do que o estado de identidade que deveriam refletir.
Solicite uma política de falha utilizador a utilizador: Os funcionários, convidados, caixas registadoras, câmaras, residentes e dispositivos IoT devem falhar fechados (fail closed), utilizar um recurso local limitado ou continuar numa sessão previamente autorizada?
A presença em várias regiões é um requisito de conceção, não uma prova
Os endpoints RADIUS multirregião podem reduzir a dependência de uma única região de serviço, mas os dispositivos de acesso precisam de uma forma viável de os alcançar e de fazer failover entre eles. Verifique se os pontos de acesso e controladores implantados efetuam novas tentativas automaticamente, como escolhem um endpoint alternativo e se a perda de uma região exige intervenção manual. Teste também como é processada a contabilização (accounting) durante a retransmissão e a recuperação.
Antes da aquisição, pergunte quanto tempo a autenticação em cache permanece válida, quem pode revogar o acesso de emergência, com que frequência o failover é testado e que provas pode o fornecedor apresentar desses testes. Para hotéis e grandes recintos, realize o teste com dispositivos e serviços representativos, e não apenas com o portátil de um funcionário. Um resultado útil é uma matriz de falhas por escrito que identifique a população afetada, o comportamento esperado, o responsável e a ação de recuperação.
Segurança, conformidade e migração do RADIUS legado
Trate a migração como um projeto de segurança e não como uma alteração do endereço de um servidor. A afirmação de um "RADIUS seguro" pode referir-se a vários aspetos diferentes: proteger o transporte, autenticar dispositivos de rede, validar a identidade do utilizador ou dispositivo ou retornar a autorização correta. Estes controlos resolvem problemas distintos.
O RadSec utiliza TLS para proteger o transporte RADIUS, e a autenticação mútua por certificado pode ajudar a garantir que o servidor e o dispositivo cliente são de confiança. No entanto, a encriptação por si só não garante que o utilizador correto receba a VLAN correta, nem que o acesso de quem sai seja revogado atempadamente. Os operadores devem também confirmar como o serviço lida com o Message-Authenticator, proteções contra repetição e falsificação (spoofing), inspeção de proxy e integridade de contabilidade quando os pacotes são reenviados ou os pontos de extremidade mudam.
Peça provas, não apenas garantias
Ao avaliar um fornecedor, faça perguntas diretas:
- Gestão de certificados: Os certificados são geridos por cliente, tenant, local ou dispositivo de rede? Como são monitorizados a expiração e a rotação?
- Limites de transporte: Onde termina o TLS? Os proxies intermédios podem inspecionar ou reencaminhar pedidos e que proteção permanece de ponta a ponta?
- Provas de auditoria: Pode rever as decisões de autenticação, alterações de políticas, acessos administrativos e registos de accounting?
- Postura de segurança: Que certificações possui o fornecedor e qual o seu âmbito de aplicação? Se necessitar de ISO 27001 ou Cyber Essentials, verifique as provas atuais e a aplicabilidade em vez de confiar apenas num logótipo.
- Migração e reversão: O fornecedor pode suportar uma transição faseada de UDP para TLS e qual é o plano de reversão testado se um modelo de dispositivo de acesso se comportar de forma diferente?
Uma sequência de migração deve começar com um inventário de clientes RADIUS, fontes de identidade, métodos de autenticação, regras de VLAN, segredos partilhados, certificados e consumidores de contabilidade. Em seguida, documente a política de destino e teste-a com identidades e dispositivos representativos. Faça um piloto num local, compare as decisões devolvidas com os resultados pretendidos e, depois, faça a transição serviço a serviço. Mantenha um plano de reversão até que o comportamento de contabilidade e acesso seja totalmente compreendido em produção.
A conformidade precisa de acompanhar o tráfego e os registos que o seu ambiente processa. Para uma perspetiva prática de controlo de rede, consulte este guia sobre conformidade PCI e WiFi. A questão útil não é se um produto alega estar em conformidade, mas se a sua implementação produz provas para os controlos que a sua organização tem de demonstrar.
Existe um risco adicional entre a especificação do protocolo e a rede instalada. As orientações de segurança podem exigir verificações que alguns dispositivos de acesso ou proxies não implementam de forma consistente. Pergunte aos fornecedores quais os controlos que aplicam, quais os que dependem do firmware do cliente e como validam o comportamento nos seus equipamentos.
Escolher e implementar um serviço RADIUS alojado
Escolha um fornecedor com base no comportamento em caso de falha e nas evidências operacionais que pode verificar, e não apenas pelo rótulo de nuvem. Confirme a cobertura regional, o suporte a fornecedores de identidade, a gestão de chaves por cliente (per-tenant) quando necessário, o acesso a auditorias, os processos de certificado e RadSec, e o que acontece quando o contrato termina.
Faça a implementação de forma controlada: inventarie as dependências atuais de AAA e de dispositivos; defina a política de identidade para a rede; realize pilotos em locais e tipos de dispositivos representativos; faça a transição por fases; e, por fim, valide as decisões de acesso e a contabilidade em relação aos registos de identidade ou de gestão de propriedades. Acompanhe as autenticações falhadas, a gestão de revogações, a reconciliação de contabilidade e o desempenho da rede de convidados como sinais operacionais, e não como prova de resiliência por si só.
O Purple Access oferece Cloud RADIUS alojado em conjunto com opções de rede abertas, seguras e xPSK, com acesso baseado em identidade através de pontos de acesso existentes. Avalie-o com base nos mesmos testes de falha, requisitos de política e evidências que solicitaria a qualquer fornecedor.
Se está a planear a implementação do RADIUS em vários locais, mapeie as suas dependências de WAN, identidade, certificados e contingência local antes de alterar o percurso de autenticação. Visite o Purple Access para analisar as suas opções de Cloud RADIUS e acesso à rede para redes de convidados, funcionários e dispositivos.
