Você está olhando para um Network Policy Server que ninguém quer atualizar, um controlador sem fio apontando para um único servidor RADIUS em uma sala de comunicação e uma fila de suporte cheia de redefinições de senha. A identidade foi movida para o Entra ID ou Okta, mas a autenticação WiFi ainda depende de uma infraestrutura local construída para o Active Directory local. Essa incompatibilidade é onde as organizações começam a considerar um servidor cloud radius - não porque mover um servidor seja empolgante, mas porque o modelo antigo não se adapta mais à forma como usuários, dispositivos e locais funcionam.
O que é um servidor RADIUS na nuvem
Pense no RADIUS como um segurança na entrada de um edifício. Uma pessoa chega, mostra um crachá e o segurança verifica o crachá em uma lista de autorizados antes de abrir a porta. Se o crachá for válido, o segurança também decide a quais andares essa pessoa pode ter acesso. Se não for, a porta permanece fechada.
Um servidor cloud radius transfere essa segurança de uma cabine local para um serviço gerenciado centralmente. A verificação ainda ocorre na porta - que, no contexto do WiFi, é o seu ponto de acesso ou switch. No entanto, a decisão vem de um serviço hospedado que você configura por meio de políticas, em vez de servidores que você mesmo precisa atualizar, fazer backup e agrupar em clusters.
Como funciona o fluxo de autenticação
Um notebook ou celular se conecta a um SSID WPA2/WPA3-Enterprise protegido por 802.1X. O ponto de acesso não toma decisões por conta própria. Ele encaminha a solicitação de autenticação para o servidor cloud RADIUS, que valida a credencial, certificado ou identidade do dispositivo junto ao seu diretório ou autoridade certificadora.
O servidor retorna uma aceitação ou rejeição, geralmente com atributos como VLAN, função ou limite de sessão. O ponto de acesso aplica essa decisão localmente. Essa separação é importante, porque o RADIUS é o ponto de decisão, não a rede inteira e nem o seu provedor de identidade em si.
- Suplicante: O laptop, telefone ou dispositivo que solicita acesso e apresenta uma credencial ou certificado.
- Autenticador: O ponto de acesso, controlador ou switch que encaminha a solicitação e aplica o resultado.
- Fonte de identidade: Microsoft Entra ID, Okta, Google Workspace, Active Directory ou uma autoridade certificadora que mantém o registro definitivo.
Por que o modelo híbrido é o ponto de partida normal
As organizações do Reino Unido não moveram tudo para a nuvem de uma só vez. O Cloud Industry Forum relatou que 84% das organizações do Reino Unido haviam adotado formalmente pelo menos um serviço em nuvem em sua pesquisa de 2016, acima dos 48% em 2010, o que ajuda a explicar por que o RADIUS em nuvem é geralmente implantado como parte de uma arquitetura híbrida em vez de uma substituição imediata de todos os componentes locais, conforme apresentado na pesquisa de adoção de nuvem no Reino Unido do Cloud Industry Forum para 2016.
Na prática, seus switches, pontos de acesso, impressoras e sistemas legados permanecem no local. O que muda é onde a decisão de autenticação é tomada e com que consistência você pode aplicá-la entre os locais. Essa é uma definição mais precisa e útil do que simplesmente chamá-la de uma troca de servidor hospedado.
RADIUS na nuvem vs RADIUS local
A comparação honesta não é "nuvem é boa, local é ruim". É sobre quem carrega a carga operacional, quanto controle você precisa e o que falha quando algo quebra. Um par local bem administrado pode funcionar por anos. Um negligenciado se torna um ponto único de falha que ninguém tem coragem de mexer.
As estruturas no Reino Unido também permanecem mistas. Uma análise do governo do Reino Unido de 2025 revelou que aproximadamente 55% das organizações do governo central relataram ter mais de 60% de sua estrutura de tecnologia na nuvem, enquanto cerca de 28% das estruturas tecnológicas do governo central permaneciam legadas, de acordo com o State of Digital Government Review. Essa mistura é exatamente o motivo pelo qual você ainda precisa conectar a identidade em nuvem a edifícios e redes sem fio que permanecem locais.
Custo e manutenção lado a lado
| Critério | Cloud RADIUS | RADIUS local |
|---|---|---|
| Custo de capital | Baixo, baseado em assinatura | Hardware e licenças iniciais mais altos |
| Manutenção | O provedor atualiza e opera o serviço | Sua equipe atualiza o sistema operacional, RADIUS e certificados |
| Escalabilidade | Adicione locais via configuração | Adicione servidores, clustering e balanceamento de carga |
| Controle | Controle de políticas, menos controle de infraestrutura | Controle total, responsabilidade total |
| Resiliência | Endpoints redundantes do provedor | Você mesmo projeta e testa o failover |
O FreeRADIUS parece gratuito até você contabilizar o tempo dos engenheiros, as renovações de certificados, o monitoramento e a solução de problemas fora do horário comercial. O Microsoft NPS parece incluído até que você precise de integração nativa com um diretório em nuvem para o qual ele não foi projetado. O Cisco ISE oferece recursos de políticas avançados, mas exige licenças e habilidades especializadas que muitas equipes não conseguem justificar apenas para o WiFi.
O equívoco sobre segurança
A localização do servidor não torna a autenticação segura. O que garante a segurança são a configuração, a integração de identidade, o transporte criptografado e o monitoramento.
A nuvem transfere o risco em vez de eliminá-lo. Você ganha na aplicação consistente de patches e em políticas para múltiplos locais, mas passa a depender da conectividade com a internet, do plano de controle do provedor e do provedor de identidade. Uma solução local mantém o tráfego restrito à rede interna, mas um único servidor sem patches com segredos compartilhados em todos os lugares não é mais seguro só porque está no seu prédio.
Escolha a nuvem quando não tiver equipe para operar adequadamente um par de alta disponibilidade, administrar muitos locais ou já tiver migrado a identidade para a nuvem. Permaneça no local (on-premises) quando regulamentações, latência ou um local desconectado exigirem genuinamente decisões locais. Muitas migrações de RH e TI seguem a mesma lógica híbrida, e é por isso que este guia para equipes de RH no Microsoft 365 é uma leitura paralela útil sobre a transição de sistemas essenciais sem fingir que a infraestrutura legada desaparece da noite para o dia.
Integração com Microsoft Entra ID, Okta e Certificados
Um servidor cloud RADIUS prova seu valor nas integrações. Se ele não conseguir se comunicar de forma limpa com seu diretório, sua autoridade certificadora e seus fluxos de convidados, você comprou um gargalo hospedado. Acerte os padrões de integração e o acesso à rede começará a seguir a mesma lógica de entrada, movimentação e saída de funcionários do restante do TI.
O RADIUS em si não suporta federação web moderna. Se a sua equipe está tentando entender onde termina a autenticação de rede e onde começa o logon único de aplicações, esta visão geral sobre autenticação SAML e OIDC ajuda a separar essas camadas. O RADIUS cuida da admissão na rede, enquanto o SAML e o OIDC normalmente gerenciam o login na aplicação depois que o usuário já está conectado.
Autenticação Baseada em Diretório para Funcionários
Com o Microsoft Entra ID ou Okta, o serviço RADIUS verifica o usuário ou dispositivo com base em grupos e atributos no diretório. Um usuário do setor financeiro pode ter uma função diferente de um prestador de serviços de instalações, mesmo no mesmo SSID. Quando o RH desativa uma conta, essa alteração deve ser refletida diretamente no acesso à rede, sem a necessidade de um chamado separado para a equipe de rede.
Especificamente para o Microsoft Entra ID, valide como grupos, objetos de dispositivos e sinais condicionais se mapeiam nas políticas de RADIUS antes de fazer uma implantação ampla, conforme abordado neste guia de integração de RADIUS-as-a-Service com o Microsoft Entra ID. Teste um funcionário desligado, uma alteração de função e um dispositivo desativado durante a fase piloto. Esses três casos revelam mais do que cem logins bem-sucedidos.
Certificados para dispositivos que você gerencia
O EAP-TLS usa certificados em ambos os lados, portanto não há senha para sofrer phishing, ser compartilhada ou ser alvo de força bruta. É o padrão mais seguro para notebooks gerenciados, desde que você possa emitir, renovar e revogar certificados via MDM ou SCEP sem esforço manual. Se o provisionamento de certificados for instável, os usuários pressionarão para voltar às senhas, e eles vencerão.
- Emitir identidade: Envie um certificado de usuário ou dispositivo por meio do Intune, Jamf ou seu MDM com um proprietário e data de expiração claros.
- Validar a confiança: Configure o serviço RADIUS para confiar na sua CA emissora e verificar o status de revogação.
- Vincular à política: Mapeie campos de certificados e grupos de diretório para VLANs ou funções no ponto de acesso.
- Revogar rapidamente: Remova o certificado e o acesso ao diretório simultaneamente quando um dispositivo for perdido ou uma pessoa se desligar.
Visitantes e dispositivos que não suportam 802.1X
Os visitantes não deveriam precisar de uma conta corporativa para obter acesso seguro. O Passpoint e o OpenRoaming permitem que um dispositivo se autentique uma vez e se reconecte com acesso criptografado nas visitas seguintes, o que é ideal para hotéis, hubs de transporte e locais com múltiplas unidades. Para impressoras, terminais de pagamento e equipamentos IoT antigos que não conseguem apresentar certificados, use o bypass de autenticação MAC ou chaves pré-compartilhadas individuais com segmentação rígida, tratando esses dispositivos como não confiáveis por padrão.
Considerações de segurança e Zero-Trust
Trate um servidor cloud RADIUS como um limite de confiança, não como um utilitário conveniente. Ele decide quem entra na sua rede, comunica-se com o seu diretório e seu console de administração pode alterar políticas para todos os locais de uma só vez. Essa concentração de poder é útil, e é exatamente por isso que os controles ao seu redor precisam de análise rigorosa.
O NCSC recomenda que as interfaces de serviços em nuvem exponham o acesso apenas a identidades autenticadas e autorizadas, com autenticação contextual usando asserções criptográficas ou troca segura de chaves, conforme descrito no Princípio 10 do NCSC sobre identidade e autenticação. Para o cloud RADIUS, isso significa tratar o serviço e suas interfaces administrativas como limites de confiança separados, com identidades de serviço exclusivas, permissões estritamente delimitadas e eventos de autenticação auditáveis, em vez de credenciais de administrador compartilhadas.
Pare de confiar na localização da rede
O Zero Trust muda a pergunta de "este dispositivo está na nossa VLAN?" para "quem é este usuário, qual é este dispositivo e o que ele deve acessar agora?". A presença em uma VLAN corporativa ou de convidados não é prova de autorização. O acesso deve permanecer condicional à identidade autenticada e à política referente àquela sessão, locatário e local.
Esse princípio tem consequências práticas para o projeto de WiFi. O laptop de um fornecedor e o laptop do setor financeiro podem compartilhar um SSID, mas não deveriam compartilhar a alcanceabilidade de rede. Seu conjunto mais amplo de controles deve estar alinhado a um guia de segurança de WiFi empresarial para acesso a redes Zero Trust, para que as decisões de autenticação estejam vinculadas à segmentação, ao monitoramento e ao menor privilégio, e não apenas ao ato de se conectar.
Controles que você deve exigir de um provedor
- Transporte criptografado: RadSec ou proteção equivalente para tráfego RADIUS, além de TLS moderno para APIs e acesso de administração.
- Rotação e revogação: Rotação documentada de certificados e segredos, e revogação rápida quando contas ou dispositivos são desativados.
- Administração baseada em funções: Funções separadas de leitor, operador e administrador, sem logins compartilhados para alterações de políticas.
- Registros que você pode usar: Eventos de autenticação, alterações de políticas e ações administrativas exportados para seu SIEM com retenção clara.
Regra prática: Se comprometer um único local ou conta de integração conceder ao atacante autoridade sobre outros clientes ou sobre o plano de controle, o projeto falhou.
Faça perguntas difíceis logo no início. Quem pode ver os logs de autenticação, onde eles são armazenados e como o acesso de gerenciamento do provedor é separado do seu plano de dados. Se um fornecedor não puder responder claramente, isso já é uma resposta.
Padrões de Implantação para WiFi Empresarial e Multi-Tenant
Um hotel no check-in, uma enfermaria com dispositivos médicos e um shopping center em um sábado não compartilham o mesmo perfil de risco. Eles podem compartilhar um servidor cloud RADIUS, desde que cada público tenha sua própria política e a rede garanta a separação após a autenticação. O erro é presumir que um login bem-sucedido equivale a uma rede segmentada.
Dados de pesquisas governamentais indicam que 85% das grandes empresas do Reino Unido mantinham redes WiFi separadas para funcionários e visitantes, abaixo dos 93% anteriores, no capítulo do Cyber Security Breaches Survey 2025 sobre controles de segurança de rede. A separação não é um problema resolvido, mesmo para grandes organizações. O RADIUS em nuvem deve, portanto, ser combinado com VLANs dinâmicas ou aplicação de políticas para oferecer segmentação real, e não apenas uma autenticação mais amigável.
O que diferentes locais realmente precisam
No setor de hotelaria, os hóspedes se autenticam na chegada, os dispositivos dos funcionários são verificados no diretório e os terminais de pagamento ficam em um segmento restrito que não consegue ver nenhum dos dois. Na área da saúde, equipes clínicas, portadores, pacientes e equipamentos médicos coexistem, sendo que alguns desses equipamentos nunca suportarão certificados. A política precisa refletir essa realidade em vez de forçar todos os dispositivos a seguir um único modelo.
As redes de varejo enfrentam um problema de escala, e não de complexidade, em cada loja. A matriz deseja um acesso consistente para os funcionários e a separação de visitantes em todas as filiais sem precisar enviar servidores para cada local. Os hubs de transporte adicionam o roaming, no qual o passageiro espera que a conexão iniciada em uma estação funcione na próxima. Um serviço centralizado atende a ambos os padrões porque a política viaja junto com a identidade.
Edifícios Multilocatários Precisam de Isolamento por Projeto
Moradores de empreendimentos build-to-rent ou moradias estudantis esperam um WiFi residencial, mas os dispositivos de cada residência devem permanecer invisíveis para os vizinhos. Isso exige políticas por locatário, chaves individuais para dispositivos legados e acesso de funcionários que não afete as redes dos residentes. Vale a pena revisar um guia de WiFi multilocatário para redes residentes isoladas junto com o seu projeto de RADIUS, pois a autenticação só ajuda se a separação subjacente de locatários for sólida.
Antes da implantação, mapeie cada classe de dispositivo que você possui, não apenas a lista organizada no registro de ativos. Funcionários, visitantes, prestadores de serviço, IoT, caixas, scanners e a impressora antiga do financeiro precisam de um caminho definido. Dispositivos não planejados se tornam a exceção que compromete a política.
Melhores Práticas para Implementação e Operação
A maioria dos problemas de cloud RADIUS não são falhas de protocolo. São surpresas operacionais que ninguém testou, como uma conta revogada que continua funcionando, um local que perde o acesso à internet ou um login de emergência que não deixa rastros de auditoria. Planeje esses cenários antes que o primeiro local entre em operação, e não durante a primeira interrupção.
A pesquisa Cyber Security Breaches Survey 2025, do governo do Reino Unido, constatou que 43% das empresas relataram uma violação ou ataque nos 12 meses anteriores, embora apenas 31% tenham realizado avaliações formais de risco cibernético, conforme divulgado nos resultados da Cyber Security Breaches Survey 2025 a 2026. Essa lacuna é o motivo pelo qual você precisa de respostas explícitas para interrupção de provedores, tempo de inatividade do provedor de identidade e perda de conectividade, além de acesso de emergência auditado.
Defina o comportamento de falha por SSID
Decida por escrito onde a autenticação falha fechada (fail closed) e onde um fallback restrito é aceitável. SSIDs de funcionários privilegiados e segmentos sensíveis devem falhar fechados, pois o acesso aberto durante uma interrupção anula o propósito do 802.1X. Serviços operacionalmente críticos podem justificar um fallback com escopo reduzido e limite de tempo, mas isso deve gerar alertas, registros em log e revisões.
- Faça um piloto em um local e um SSID: Comprove a autenticação, atribuição de VLAN e registro de logs com dispositivos reais, incluindo seu hardware mais antigo com suporte.
- Simule falhas intencionalmente: Desative uma conta de teste, revogue um certificado e simule a perda do endpoint principal, depois meça a experiência dos usuários.
- Meça a velocidade de revogação: Cronometre quanto tempo uma conta desativada do Microsoft Entra ID ou Okta mantém o acesso à rede e registre o resultado no manual de execução.
- Testa o caminho de saída: Confirme se você pode exportar as configurações e os logs e redirecionar os pontos de acesso para outro serviço sem ter que reconstruir as políticas do zero.
Opere como uma infraestrutura crítica
Monitore as taxas de sucesso e falha de autenticação, a integridade dos endpoints e picos incomuns por local. Revise os logs em busca de falhas repetidas em um único dispositivo, pois isso geralmente indica uma configuração incorreta, um certificado expirado ou uma tentativa de varredura na sua rede. Defina a retenção de logs, requisitos de residência de dados do UK GDPR e resposta de suporte no contrato, e não em uma conversa de vendas.
Não meça o sucesso apenas pelo fato de o 802.1X estar ativado. Meça se o isolamento funciona, se a revogação é rápida e se um local degrada de forma previsível quando a conectividade cai.
Revise o risco do fornecedor anualmente, incluindo suboperadores e a origem do acesso do suporte. Mantenha um manual simples que um engenheiro de plantão possa seguir à noite sem a equipe do projeto. Se esse manual não existir, você ainda não tem um modelo operacional.
Principais conclusões e próximos passos
Um servidor cloud radius faz sentido quando a identidade já reside na nuvem, você opera em vários locais ou sua equipe não consegue manter um par local resiliente em alto nível. Ele elimina a manutenção de servidores e centraliza as políticas. No entanto, ele não exime sua responsabilidade sobre segmentação, revogação, logs ou planejamento de interrupções.
Ela também não é a segmentação por si só. A autenticação decide quem um dispositivo afirma ser. VLANs dinâmicas, políticas baseadas em funções e regras de privilégio mínimo decidem o que esse dispositivo pode acessar, e você precisa que ambos funcionem juntos.
Uma lista de verificação rápida para avaliação
- Ajuste de identidade: Integração nativa com seu diretório e comportamento testado de entrada, alteração e saída de usuários.
- Gerenciamento de certificados: Emissão, renovação e revogação gerenciadas que sua frota de dispositivos possa suportar.
- Comportamento em caso de falha: Fail-closed para SSIDs confidenciais, com qualquer alternativa restrita, registrada em log e com limite de tempo.
- Evidências: Logs exportáveis, residência de dados clara, administração baseada em funções e separação entre leatários (tenants).
- Saída: Exportação de configurações e logs, para que a troca de provedor seja um projeto planejado e não uma reconstrução do zero.
Comece com um piloto em um local ou SSID, meça o sucesso da autenticação e a latência de revogação, e simule falhas na integração de propósito antes que os usuários dependam dela. Escale somente quando esses resultados forem previsíveis. Previsibilidade é a marca de uma boa autenticação em produção.
A Purple oferece RADIUS como serviço para WiFi de visitantes, funcionários e multilocatários, integrando-se com Microsoft Entra ID, Google Workspace e Okta para que você possa desativar servidores RADIUS locais e aplicar um acesso consistente e baseado em identidade em todos os locais. Se você está planejando um projeto piloto ou substituindo uma estrutura frágil de NPS ou FreeRADIUS, visite a Purple para ver como o RADIUS gerenciado na nuvem, o Passpoint e o isolamento por locatário funcionam com seu ambiente existente da Meraki, Aruba, Ruckus, Mist ou UniFi.
