Está a olhar para um Network Policy Server que ninguém quer atualizar, um controlador sem fios a apontar para uma única caixa RADIUS numa sala de comunicações e uma fila de suporte cheia de redefinições de palavras-passe. A identidade mudou para o Entra ID ou Okta, mas a autenticação WiFi ainda depende da infraestrutura local construída para o Active Directory no local. É nessa incompatibilidade que as organizações começam a procurar um servidor radius em nuvem, não porque mudar um servidor seja entusiasmante, mas porque o modelo antigo já não se adequa à forma como os utilizadores, dispositivos e locais funcionam.
O Que É um Servidor Cloud RADIUS
Pense no RADIUS como um guarda de segurança à entrada de um edifício. Uma pessoa chega, apresenta um crachá e o guarda verifica o crachá em relação a uma lista aprovada antes de abrir a porta. Se o crachá for válido, o guarda também decide a que pisos essa pessoa pode aceder. Se não for, a porta permanece fechada.
Um servidor cloud RADIUS move essa proteção de uma guarita local para um serviço gerido centralmente. A verificação continua a acontecer à entrada - que, em termos de WiFi, é o seu ponto de acesso ou switch. No entanto, a decisão vem de um serviço alojado que configura através de políticas, em vez de servidores que tem de atualizar, fazer cópias de segurança e agrupar em cluster por si próprio.
Como Funciona o Fluxo de Autenticação
Um portátil ou telemóvel liga-se a um SSID WPA-Enterprise protegido por 802.1X. O ponto de acesso não toma decisões sozinho. Encaminha o pedido de autenticação para o servidor RADIUS em nuvem, que valida a credencial, o certificado ou a identidade do dispositivo em relação ao seu diretório ou autoridade de certificação.
O servidor devolve uma aceitação ou rejeição, frequentemente com atributos como uma 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, nem o seu fornecedor de identidade em si.
- Suplicante: O portátil, telefone ou dispositivo que solicita acesso e apresenta uma credencial ou certificado.
- Autenticador: O ponto de acesso, controlador ou switch que encaminha o pedido e aplica o resultado.
- Fonte de identidade: Microsoft Entra ID, Okta, Google Workspace, Active Directory ou uma autoridade de certificação que detém o registo de autoridade.
Por Que Razão o Modelo Híbrido É o Ponto de Partida Normal
As organizações do Reino Unido não mudaram tudo para a nuvem de uma só vez. O Cloud Industry Forum reportou que 84% das organizações do Reino Unido tinham adotado formalmente pelo menos um serviço de nuvem no seu estudo de 2016, em comparação com os 48% em 2010, o que ajuda a explicar por que motivo o RADIUS em nuvem é normalmente implementado como parte de uma arquitetura híbrida em vez de uma substituição imediata de todos os componentes locais, conforme exposto na pesquisa de adoção de nuvem do Cloud Industry Forum no Reino Unido para 2016.
Na prática, os 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 a consegue aplicar em todos os locais. Essa é uma definição mais precisa e útil do que chamar-lhe uma simples substituição de servidor alojado.
Cloud RADIUS vs RADIUS On-Premises
A comparação honesta não é "nuvem é boa, no local é mau". Trata-se de quem carrega a carga operacional, de quanto controlo necessita e do que falha quando algo avaria. Um par no local bem gerido pode funcionar durante anos. Um par negligenciado torna-se num ponto único de falha no qual ninguém se atreve a tocar.
As infraestruturas no Reino Unido também permanecem mistas. Uma análise do governo do Reino Unido de 2025 concluiu que aproximadamente 55% das organizações do governo central reportaram ter mais de 60% da sua infraestrutura tecnológica na nuvem, enquanto cerca de 28% das infraestruturas tecnológicas do governo central permaneciam legadas, de acordo com o State of Digital Government Review. Essa mistura é precisamente a razão pela qual ainda precisa de ligar a identidade em nuvem a edifícios e redes sem fios que permanecem no local.
Custo e Manutenção Lado a Lado
| Critério | Cloud RADIUS | RADIUS On-Premises |
|---|---|---|
| Custo de capital | Baixo, baseado em subscrição | Hardware e licenciamento iniciais mais elevados |
| Manutenção | O fornecedor aplica patches e opera o serviço | A sua equipa aplica patches ao SO, RADIUS e certificados |
| Escalabilidade | Adicione locais através de configuração | Adicione servidores, clusters e balanceamento de carga |
| Controlo | Controlo de políticas, menos controlo de infraestrutura | Controlo total, responsabilidade total |
| Resiliência | Endpoints redundantes do fornecedor | A sua equipa projeta e testa o failover |
O FreeRADIUS parece gratuito até contar o tempo dos engenheiros, as renovações de certificados, a monitorização e a resolução de problemas fora do horário de expediente. O Microsoft NPS parece incluído até precisar de integração nativa com um diretório na nuvem para o qual não foi construído. O Cisco ISE oferece funcionalidades de política avançadas, mas exige licenças e competências especializadas que muitas equipas não conseguem justificar apenas para o WiFi.
O Mal-entendido Sobre Segurança
A localização do servidor não torna a autenticação segura. A configuração, a integração de identidade, o transporte encriptado e a monitorização é que o fazem.
A nuvem transfere o risco em vez de o eliminar. Ganha a aplicação consistente de patches e políticas multilocal, mas passa a depender da conetividade à internet, do plano de controlo do fornecedor e do fornecedor de identidade. A infraestrutura local mantém o tráfego local, mas um único servidor sem patches aplicados e com segredos partilhados por todo o lado não é mais seguro apenas por estar no seu edifício.
Escolha a nuvem quando não tiver pessoal para gerir adequadamente um par de alta disponibilidade, operar muitos locais ou se já tiver migrado a identidade para a nuvem. Mantenha no local quando regulamentos, latência ou um local desligado exigirem genuinamente decisões locais. Muitas migrações de RH e TI seguem a mesma lógica híbrida, razão pela qual este guia para equipas de RH com Microsoft 365 é uma leitura paralela útil sobre a migração de sistemas essenciais sem fingir que o legado desaparece do dia para a noite.
Integração com Microsoft Entra ID, Okta e Certificados
Um servidor RADIUS em nuvem justifica o seu valor nos pontos de integração. Se não conseguir comunicar de forma limpa com o seu diretório, com a sua autoridade de certificação e com os seus fluxos de convidados, comprou um ponto de estrangulamento alojado. Garanta os padrões de integração corretos e o acesso à rede começará a seguir a mesma lógica de gestão de ciclo de vida de utilizadores (joiner, mover e leaver) do resto do departamento de IT.
O RADIUS por si só não suporta federação web moderna. Se a sua equipa está a tentar esclarecer onde termina a autenticação de rede e onde começa o single sign-on da aplicação, esta visão geral da autenticação SAML e OIDC ajuda a separar essas camadas. O RADIUS gere a admissão à rede, enquanto o SAML e o OIDC normalmente gerem a autenticação na aplicação após o utilizador já estar ligado.
Autenticação Suportada por Diretório para Colaboradores
Com o Microsoft Entra ID ou Okta, o serviço RADIUS verifica o utilizador ou dispositivo em relação a grupos e atributos no diretório. Um utilizador da área financeira pode ficar numa função diferente da de um prestador de serviços de instalações, mesmo no mesmo SSID. Quando os RH desativam uma conta, essa alteração deve ser refletida no acesso à rede sem ser necessário um pedido separado para a equipa de rede.
Especificamente para o Microsoft Entra ID, valide como os grupos, objetos de dispositivo e sinais condicionais se mapeiam na política RADIUS antes de implementar amplamente, conforme abordado neste guia de integração do Microsoft Entra ID RADIUS-as-a-Service. Teste uma saída de colaborador, uma alteração de função e um dispositivo desativado durante o piloto. Estes três casos revelam mais do que cem acções de início de sessão com sucesso.
Certificados para Dispositivos Geridos por Si
O EAP-TLS utiliza certificados em ambos os lados, pelo que não há palavra-passe para ser alvo de phishing, partilhada ou forçada por força bruta. É o modelo mais forte para computadores portáteis geridos, desde que consiga emitir, renovar e revogar certificados através de MDM ou SCEP sem esforço manual. Se o aprovisionamento de certificados for instável, os utilizadores vão pressioná-lo para voltar às palavras-passe - e vão vencer.
- Emitir identidade: Envie um certificado de utilizador ou dispositivo através do Intune, Jamf ou do seu MDM com um proprietário e validade claros.
- Validar confiança: Configure o serviço RADIUS para confiar na sua CA emissora e verificar o estado 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 em simultâneo quando um dispositivo for perdido ou uma pessoa sair da organização.
Visitantes e Dispositivos Que Não Suportam 802.1X
Os visitantes não devem precisar de uma conta corporativa para obter acesso seguro. O Passpoint e o OpenRoaming permitem que um dispositivo se autentique uma vez e se volte a ligar com acesso encriptado em visitas futuras, o que é ideal para hotéis, pontos de transporte e locais com múltiplos edifícios. Para impressoras, terminais de pagamento e equipamentos IoT mais antigos que não conseguem apresentar certificados, utilize a eliminação de autenticação MAC ou chaves pré-partilhadas individuais com segmentação rigorosa, e trate esses dispositivos como não fiáveis por predefinição.
Considerações de Segurança e Zero-Trust
Trate um servidor RADIUS em nuvem como um limite de confiança e não como um utilitário conveniente. Ele decide quem entra na sua rede, comunica com o seu diretório e a sua consola 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 controlos ao seu redor precisam de ser escrutinados.
O NCSC recomenda que as interfaces de serviços na nuvem exponham o acesso apenas a identidades autenticadas e autorizadas, com autenticação contextual através de 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, isto significa tratar o serviço e as suas interfaces administrativas como limites de confiança separados, com identidades de serviço únicas, permissões estritamente limitadas e eventos de autenticação auditáveis em vez de credenciais de administração partilhadas.
Deixe de Confiar na Localização da Rede
O Zero Trust altera a questão de "este dispositivo está na nossa VLAN?" para "quem é este utilizador, qual é este dispositivo e a que devem ter acesso neste momento?". A presença numa VLAN empresarial ou de convidados não é prova de autorização. O acesso deve permanecer condicional à identidade autenticada e à política definida para essa sessão, cliente e local.
Esse princípio tem consequências práticas para a conceção do WiFi. O portátil de um prestador de serviços e o portátil do departamento financeiro podem partilhar um SSID, mas não devem partilhar a acessibilidade. O seu conjunto mais amplo de controlos deve alinhar-se com um guia de segurança WiFi empresarial para acesso à rede Zero Trust, para que as decisões de autenticação se associem à segmentação, monitorização e ao privilégio mínimo, e não apenas ao facto de conseguir ligação.
Controlos a Exigir a um Fornecedor
- Transporte encriptado: 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 credenciais partilhadas para alterações de políticas.
- Registos úteis: Eventos de autenticação, alterações de políticas e ações de administração exportados para o seu SIEM com retenção clara.
Regra prática: Se comprometer um único local ou conta de integração conceder a um atacante autoridade sobre outros clientes ou sobre o plano de controlo, a conceção falhou.
Faça perguntas exigentes logo de início. Quem pode ver os registos de autenticação, onde são armazenados e como é que o acesso de gestão do fornecedor é separado do seu plano de dados. Se um fornecedor não conseguir responder claramente, isso já é uma resposta.
Padrões de Implantação para Enterprise e Multi-Tenant WiFi
Um hotel no check-in, uma enfermaria com dispositivos médicos e um centro comercial num sábado não partilham o mesmo perfil de risco. Podem partilhar um servidor RADIUS em nuvem, desde que cada população tenha a sua própria política e a rede garanta a separação após a autenticação. O erro é assumir que um início de sessão bem-sucedido equivale a uma rede segmentada.
Os dados do inquérito governamental indicam que 85% das grandes empresas do Reino Unido mantiveram redes WiFi de funcionários e visitantes separadas, registando uma queda face aos 93% anteriores, no capítulo do Cyber Security Breaches Survey 2025 sobre controlos 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 proporcionar uma segmentação real, e não apenas uma autenticação mais agradável.
O Que os Diferentes Locais Realmente Precisam
Na hotelaria, os hóspedes autenticam-se à chegada, os dispositivos do pessoal são verificados em relação ao diretório e os terminais de pagamento ficam num segmento restrito que não consegue ver nenhum dos dois. Na saúde, o pessoal clínico, os auxiliares, os pacientes e o equipamento médico coexistem, e parte desse equipamento nunca suportará certificados. A política tem de refletir essa realidade em vez de forçar cada dispositivo a entrar num único modelo.
As cadeias de retalho enfrentam um problema de escala em vez de um problema de complexidade em cada loja. A sede pretende um acesso consistente para os funcionários e a separação dos convidados em todas as filiais sem ter de enviar servidores para cada local. Os pontos de transporte adicionam o roaming, onde um passageiro espera que a ligação em que se registou numa estação funcione na seguinte. Um serviço central adapta-se a ambos os padrões, pois a política acompanha a identidade.
Edifícios Multicliente Necessitam de Isolamento por Conceção
Os residentes em alojamento multifamiliar (build-to-rent) ou estudantil esperam uma experiência de WiFi semelhante à de casa, mas os dispositivos de cada lar devem permanecer invisíveis para os vizinhos. Isto exige políticas por inquilino, chaves individuais para dispositivos legados e acesso da equipa que não se misture com as redes dos residentes. Vale a pena analisar um guia de WiFi multitenant para redes de residentes isoladas juntamente com a sua arquitetura RADIUS, porque a autenticação só ajuda se a separação subjacente dos inquilinos for sólida.
Antes da implementação, mapeie cada classe de dispositivos que possui, e não a lista organizada do registo de ativos. Funcionários, convidados, prestadores de serviços, IoT, caixas registadoras, scanners e a impressora antiga da contabilidade precisam de um caminho definido. Os dispositivos não planeados tornam-se a exceção que compromete a política.
Melhores Práticas de Implementação e Operação
A maioria dos problemas de RADIUS em nuvem não são problemas de protocolo. São surpresas operacionais que ninguém testou, tais como uma conta revogada que continua a funcionar, um local que perde acesso à internet ou um início de sessão de emergência que não deixa registo de auditoria. Planeie para esses casos antes do primeiro local entrar em funcionamento, e não durante a primeira interrupção.
O Cyber Security Breaches Survey 2025 do Governo do Reino Unido revelou que 43% das empresas comunicaram uma violação ou ataque nos 12 meses anteriores, no entanto, apenas 31% realizaram avaliações formais de risco cibernético, conforme relatado nas conclusões do Cyber Security Breaches Survey 2025 a 2026. Essa lacuna é a razão pela qual precisa de respostas explícitas para interrupções do fornecedor, tempo de inatividade do fornecedor de identidade e perda de conetividade, além de acesso de emergência auditado.
Definir o Comportamento em Caso de Falha por SSID
Decida por escrito onde a autenticação falha em modo fechado (fail closed) e onde um recurso de contingência limitado é aceitável. Os SSIDs de pessoal privilegiado e os segmentos sensíveis devem falhar em modo fechado, porque o acesso aberto durante uma interrupção anula o propósito do 802.1X. Serviços operacionalmente críticos podem justificar uma contingência estritamente delimitada e com limite de tempo, mas esta deve gerar alarme, ser registada em log e ser revista.
- Realize um piloto num local e num SSID: Comprove a autenticação, a atribuição de VLAN e o registo de logs em dispositivos reais, incluindo o seu hardware suportado mais antigo.
- Avoaria intencionalmente o sistema: Desative uma conta de teste, revogue um certificado e simule a perda do endpoint principal, medindo depois o impacto na experiência dos utilizadores.
- 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 registe o resultado no manual de procedimentos.
- Teste o caminho de saída: Confirme que consegue exportar a configuração e os logs, reencaminhando os pontos de acesso para outro serviço sem ter de reconstruir as políticas de memória.
Opere-o Como uma Infraestrutura Crítica
Monitorize as taxas de sucesso e falha de autenticação, a integridade dos pontos finais e picos invulgares por local. Reveja os registos para detetar falhas repetidas num único dispositivo, pois trata-se frequentemente de uma má configuração, um certificado expirado ou algo a sondar a sua rede. Acorde a retenção de registos, as necessidades de residência de dados no Reino Unido e a resposta de suporte no contrato, e não numa reunião de vendas.
Não meça o sucesso apenas pela ativação do 802.1X. Meça se o isolamento funciona, se a revogação é rápida e se um local reduz a funcionalidade de forma previsível quando a conectividade falha.
Revise o risco de fornecedores anualmente, incluindo suboperadores e a origem do acesso de suporte. Mantenha um manual de procedimentos simples que um engenheiro de serviço possa seguir à noite sem a equipa do projeto. Se esse manual não existir, ainda não tem um modelo operacional definido.
Principais Conclusões e Próximos Passos
Um servidor cloud RADIUS faz sentido quando a identidade já reside na nuvem, opera vários locais ou a sua equipa não consegue manter um par local resiliente com um elevado padrão de qualidade. Elimina a manutenção do servidor e centraliza a política. Não elimina a sua responsabilidade quanto à segmentação, revogação, registo de logs ou planeamento de interrupções.
Também não se trata de segmentação por si só. A autenticação decide quem um dispositivo alega ser. As VLANs dinâmicas, as políticas baseadas em funções e as regras de menor privilégio decidem o que esse dispositivo pode alcançar - e precisa de ambas a funcionar em conjunto.
Uma Breve Lista de Verificação de Avaliação
- Adequação de identidade: Integração nativa com o seu diretório e comportamento testado para novos colaboradores, alterações de função e saídas.
- Gestão de certificados: Emissão, renovação e revogação geridas que a sua frota de dispositivos consiga suportar.
- Comportamento em caso de falha: Bloqueio por omissão (fail closed) para SSIDs sensíveis, com qualquer alternativa restrita, registada em log e limitada no tempo.
- Evidências: Logs exportáveis, residência de dados clara, administração baseada em funções e separação entre instâncias (tenants).
- Saída: Exportação de configuração e logs, garantindo que a mudança de fornecedor seja apenas um projeto em vez de uma reconstrução do zero.
Comece com um piloto num local ou SSID, meça o sucesso da autenticação e a latência de revogação, e simule falhas na integração intencionalmente antes que os utilizadores dependam dela. Dimensione apenas quando esses resultados forem previsíveis e consistentes. A previsibilidade é o grande indicador de uma boa autenticação em produção.
A Purple oferece RADIUS-as-a-Service para WiFi de convidados, funcionários e multitenant, integrando-se com o Microsoft Entra ID, Google Workspace e Okta para que possa desativar servidores RADIUS no local e aplicar um acesso consistente e baseado em identidade em todos os locais. Se está a planejar um piloto ou a substituir uma configuração frágil de NPS ou FreeRADIUS, visite a Purple para ver como o RADIUS gerido na nuvem, o Passpoint e o isolamento por inquilino funcionam com a sua infraestrutura existente da Meraki, Aruba, Ruckus, Mist ou UniFi.
