Mover seu servidor RADIUS para a nuvem não é, por si só, uma estratégia de segurança de WiFi. O conselho popular de substituir o FreeRADIUS ou o Windows NPS por um endpoint hospedado ignora as perguntas mais difíceis: de quem é a identidade que controla o acesso, como um ex-colaborador o perde e o que acontece quando o local não consegue se conectar ao serviço.
O RADIUS as a service é mais útil como um controle de governança de identidade, e não apenas como uma troca de servidor. Para locais e empresas no Reino Unido, o projeto ideal muitas vezes combina autenticação de colaboradores vinculada ao diretório com chaves exclusivas para dispositivos que não suportam autenticação empresarial moderna. Uma transição baseada apenas em certificados não é automaticamente a opção mais robusta.
O que o RADIUS as a Service muda para o WiFi
O RADIUS as a service é um plano de controle hospedado de autenticação, autorização e contabilização (AAA). Seu ponto de acesso ou controlador WLAN permanece como o ponto de execução da política. O serviço hospedado decide se permite o acesso de um usuário ou dispositivo e retorna a política de rede a ser aplicada.
Comparativo: RADIUS local, na nuvem e federado
| Modelo | Quem opera o AAA | Fonte de identidade | Failover e crescimento | Uso ideal |
|---|---|---|---|---|
| FreeRADIUS ou Windows NPS local | Sua equipe atualiza e monitora o serviço | Diretório local ou provedor de identidade acessado por meio do seu servidor | Você atualiza, cria clusters e monitora cada instância para depois configurar locais adicionais | Um único local com equipe especializada em RADIUS |
| RADIUS as a service na nuvem | O provedor atualiza e monitora o serviço hospedado | Entra ID, Okta, Google Workspace ou outro provedor de identidade compatível | Endpoints e SLA do provedor, permitindo adicionar novos locais sem implantar novos servidores de autenticação | Locais múltiplos sem uma equipe dedicada a RADIUS |
| Proxy RADIUS federado | Operadores de proxy compartilhado mais o provedor de identidade de origem | Credenciais da organização de origem | A infraestrutura de proxy nacional ou compartilhada conecta os locais participantes | Usuários em roaming por locais gerenciados de forma independente |
Mover o servidor não cria uma arquitetura de Zero Trust. A segurança ainda depende de identidades exclusivas, revogação imediata e uma regra bem definida para determinar se o acesso falha em modo aberto ou fechado quando a autenticação está indisponível.
Uma senha compartilhada de WiFi não identifica uma pessoa de forma confiável. Da mesma forma, não é possível revogar o acesso de um colaborador desligado sem alterar essa senha para todos os demais. Manter visitantes afastados dos sistemas corporativos também exige políticas de rede, não apenas uma senha diferente.
Separe o modelo operacional da política de acesso
A hospedagem na nuvem muda quem mantém a infraestrutura de autenticação. Na Purple, operamos o RADIUS na nuvem que substitui o FreeRADIUS ou o Windows NPS, eliminando a necessidade de servidores de autenticação locais para sua equipe atualizar ou gerenciar em failover. Sua equipe continua controlando as regras de acesso, os grupos de diretório e a topologia da rede local.
A federação resolve um problema diferente: permitir que pessoas se autentiquem em locais gerenciados de forma independente. De acordo com o relatório de gestão do eduroam da Jisc, o serviço no Reino Unido foi lançado em 2 de maio de 2006, redirecionando a autenticação dos visitantes para sua instituição de origem em vez de exigir que os locais visitados administrem contas locais para visitantes. Isso é gestão delegada de identidades, não mero hospedagem remota de servidores.
Regra prática: Identifique o modelo alinhado a quem possui a gestão de identidades hoje e depois decida se essa posse deve mudar.
A autenticação também não resolve problemas de cobertura de rádio ruim, congestionamento ou conexão lenta à internet. O guia da Madeira Remote para melhorar o WiFi para videochamadas mais estáveis traz um contexto útil para separar ações de qualidade de conexão de ações de controle de acesso. Ajustar a admissão na rede não vai reparar um canal sem fio sobrecarregado.
Portanto, a decisão é tanto operacional quanto técnica. Você pode terceirizar a manutenção do servidor e, ao mesmo tempo, reter a responsabilidade de definir exatamente quem acessa cada rede.
Como o RADIUS na nuvem decide o acesso
Um notebook gerenciado conecta-se a um SSID configurado para WPA2-Enterprise ou WPA3-Enterprise. Em vez de exigir uma senha única para todo o edifício, o dispositivo inicia uma troca do protocolo EAP (Extensible Authentication Protocol) por meio do ponto de acesso.
O ponto de acesso ou controlador empacota essa troca em uma solicitação RADIUS Access-Request e a envia ao serviço hospedado. O protocolo EAP pode exigir várias trocas até que o serviço tenha informações suficientes para tomar uma decisão.
Teste as funções de AAA separadamente
A documentação de arquitetura do FreeRADIUS do governo do Reino Unido descreve o serviço por meio de autenticação, autorização e contabilização (AAA). Trate essas etapas como testes de aceitação distintos, e não como nomes intercambiáveis para um login bem-sucedido.
- A autenticação estabelece a identidade. O serviço avalia a credencial ou o certificado usando o método configurado. Um Access-Challenge dá continuidade à troca, um Access-Reject nega a admissão e um Access-Accept a permite.
- A autorização atribui permissões. A resposta pode incluir VLAN, função, lista de controle de acesso (ACL) ou limite de sessão. O controlador deve reconhecer e aplicar esses atributos.
- A contabilização registra a sessão. Colete inícios de sessão, atualizações intermediárias e encerramentos com identificadores estáveis de identidade e dispositivo, marcações de data/hora e IDs de sessão.
Um Access-Accept não prova que a segmentação funcionou. Suponha que um prestador de serviços se autentique com sucesso, mas termine na VLAN de funcionários porque o controlador ignorou o atributo de função. A autenticação foi bem-sucedida, mas o projeto de acesso falhou.
Da mesma forma, o resultado de autenticação exibido no painel do provedor não substitui o registro de contabilização da sessão. Auditorias precisam conectar uma identidade a um dispositivo, local e sessão, incluindo os horários exatos de início e término do acesso.
Projete para cenários de endpoints inacessíveis
Configure endpoints de serviço redundantes, monitoramento de integridade e temporizadores de retentativa delimitados. Retentativas infinitas podem travar os dispositivos clientes e dificultar o diagnóstico. Nosso RADIUS na nuvem opera com failover multirregional respaldado por um SLA de 99,9% de disponibilidade, mas a conectividade do local e o comportamento do controlador ainda exigem testes próprios.
Defina a regra para indisponividades antes de ir para a produção. O comportamento fail-open pode permitir a entrada de dispositivos sem as verificações necessárias, gerando acesso irrestrito. Já o comportamento fail-closed nega novos acessos, o que protege o perímetro, mas pode interromper o funcionamento de terminais de pagamento ou outros equipamentos operacionais.
Não presuma que sessões existentes e novas conexões se comportem da mesma forma durante uma queda. Teste a autenticação inicial, a reautenticação e a recuperação de endpoints separadamente, e exija o compromisso de disponibilidade e o projeto de failover por escrito.
Conclua o piloto com evidências observáveis:
- Sessão aceita: O cliente acessa a VLAN correta e apenas os serviços permitidos.
- Identidade desativada: Uma nova tentativa de autenticação recebe uma rejeição.
- Contabilização pesquisável: O administrador consegue localizar o registro da sessão resultante posteriormente.
Controles de segurança que um serviço hospedado deve comprovar
Em 2024, 50% das empresas do Reino Unido sofreram uma violação ou ataque cibernético nos 12 meses anteriores, com essa taxa ultrapassando 70% entre médias e grandes empresas, de acordo com a análise sobre Zero Trust da Consultancy.uk. Um serviço de login hospedado não resolve essa exposição sozinho.
Zero Trust significa autenticar e autorizar o acesso continuamente em vez de confiar em um dispositivo só porque ele se conectou ao SSID corporativo. Um serviço em nuvem ainda pode implementar políticas fracas por meio de credenciais compartilhadas, ausência de verificação de dispositivos ou permissões amplas demais.
Exija evidências em cada perímetro
Comece pela credencial e avalie o transporte, a administração e a execução da política. Cada camada tem um modo de falha diferente.
- Identidades nominais: Use contas individuais ou identidades de dispositivos, com remoção automatizada via diretório em vez de uma lista de acesso mantida manualmente.
- Autenticação forte de clientes: Dê preferência à autenticação de dispositivos baseada em certificados para endpoints gerenciados. Use métodos resistentes a phishing quando compatíveis e exija MFA para administração e fluxos de integração adequados.
- Transporte protegido: Proteja o caminho entre o controlador e o serviço com um transporte criptografado adequado, como RadSec ou um túnel seguro. O segredo compartilhado do RADIUS por si só não criptografa toda a troca.
- Administração segregada: Mantenha as identidades de administradores privilegiados separadas das contas de uso diário e conserve uma trilha de auditoria para alterações de políticas.
- Funções de menor privilégio: Conceda a colaboradores, prestadores de serviço, equipamentos clínicos e sistemas de automação predial apenas o acesso estritamente necessário.
Não presuma que a solicitação de MFA baseada no navegador de um diretório na nuvem possa ser exibida em qualquer troca EAP. O método EAP escolhido, o software cliente e a integração de identidade precisam suportar o fluxo de autenticação pretendido.
Verifique também os controles operacionais e sem fio
Configure a segurança sem fio corporativa com validação de certificado do servidor, autenticação mútua e quadros de dados criptografados. Exija Protected Management Frames (PMF) onde for compatível e adequado ao modo WPA selecionado, em vez de tratar o rótulo "enterprise" como garantia de que todas as proteções estão ativas.
Para a concepção abrangente de políticas, nosso guia de segurança de WiFi corporativo serve como um excelente complemento. Nosso WiFi para colaboradores oferece segurança de nível corporativo sem a complexidade de um NAC, mas os administradores ainda precisam definir limites de acesso e monitorar sua operação.
A infraestrutura física continua relevante mesmo quando a autenticação é hospedada na nuvem. As orientações da ABCO Security Services Australia sobre reforçar a segurança de data centers trazem um contexto complementar para proteger as instalações que dão suporte aos serviços de rede.
Uma credencial válida não deve conceder a um dispositivo permissão para acessar tudo o que está no prédio.
Atribua um responsável para alertas de rejeição repetida, alterações inesperadas de privilégios e atividades administrativas suspeitas. Registros só têm valor quando há alguém capaz de interpretá-los e agir.
Conectando diretórios sem criar um segundo banco de usuários
O diretório autoritativo deve continuar sendo o local de gestão do status do vínculo empregatício e da associação a grupos. Seja o Entra ID, Okta ou Google Workspace, a integração do RADIUS hospedado deve traduzir identidades em permissões de rede, em vez de criar um banco de dados de senhas desconectado.
O método de integração importa. Um conector pode sincronizar grupos, validar credenciais por meio de um mecanismo compatível ou associar certificados a identidades do diretório. Não presuma que todo diretório na nuvem exporá a mesma interface de validação de senha.
Acompanhe o ciclo de vida: entrada, movimentação e saída
Pense em um novo funcionário que entra para a equipe de instalações. Assim que seu cadastro no diretório estiver correto e seu dispositivo for registrado, o serviço deve atribuir a função de rede correspondente, sem que o administrador precise criar uma conta de WiFi separada.
Quando esse funcionário for transferido para o setor financeiro, a alteração no diretório deve resultar na VLAN ou ACL adequada durante a avaliação de política seguinte. Um projeto bem-sucedido elimina a necessidade de editar controladores individualmente, mas precisa especificar quando as associações em cache e as sessões ativas serão atualizadas.
No caso de um desligamento, a desativação da conta no diretório deve impedir autenticações posteriores dentro do prazo acordado. O recurso Change of Authorisation (CoA) pode desconectar ou alterar uma sessão ativa quando o controlador for compatível e a integração acionar essa instrução. Implantações baseadas em certificado também precisam de um processo explícito para revogação de certificado ou verificação do status da identidade.
Condição de aceitação: Acorde com que rapidez uma mudança no diretório se reflete em novas autenticações e em sessões ativas. Teste ambos os cenários em vez de aceitar o termo “automático” como compromisso de tempo.
O princípio de controle de acesso e identidade do NCSC defende a verificação e autorização de usuários, dispositivos e sistemas antes de conceder o acesso. Aplicado ao WiFi, isso torna a gestão do ciclo de vida um requisito de segurança, e não uma mera conveniência de integração.
Confirme os limites da integração
O CoA, as funções dinâmicas e o comportamento de jardim murado dependem do controlador do local. Em parques de equipamentos da Meraki, Aruba, Ruckus, Mist e UniFi, confirme o modelo exato, o firmware e o suporte a recursos em vez de confiar apenas no nome do fabricante.
Notebooks gerenciados podem usar EAP-TLS ou outro método empresarial sem senha compatível. Visitantes não devem precisar do mesmo fluxo de certificados voltado a dispositivos gerenciados. O SSO deve ser usado no console administrativo e em fluxos de integração de colaboradores adequados, mas não substitui o 802.1X na conexão sem fio.
Para uma implantação centrada no Entra, consulte nossa visão geral da integração com o Entra ID para estruturar os requisitos de identidade. Em seguida, execute um pequeno teste de ciclo de vida:
- Entrada: Um novo usuário provisionado corretamente deve conseguir se conectar.
- Movimentação: Uma alteração de grupo deve resultar na atribuição da função de rede pretendida.
- Saída: Uma conta desativada no momento registrado do teste deve ter o acesso negado dentro da janela de revogação acordada.
Padrões de acesso para visitantes, colaboradores e ambientes multi-inquilino
Um edifício abriga diferentes perfis de usuários com limites de confiança distintos. O hóspede de um hotel, o notebook de um funcionário e a televisão de um inquilino não devem ter a mesma política de acesso só porque compartilham os mesmos pontos de acesso.
Defina a linha correspondente ao perfil antes de escolher a tela de entrada. O método precisa funcionar no dispositivo e, ao mesmo tempo, a rede deve bloquear o acesso de usuários e sistemas não relacionados.
Padrão de acesso por perfil de usuário
| Perfil de usuário | Método de autenticação | Isolamento | Como o acesso é encerrado |
|---|---|---|---|
| Visitante | E-mail ou identidade temporária, com criptografia onde enterprise ou Passpoint for utilizado | Função ou VLAN para visitantes sem rota para a rede de colaboradores | Expiração da sessão ou política do portal |
| Colaboradores e dispositivos gerenciados | Identidade do diretório via EAP, frequentemente certificados ou autenticação empresarial sem senha | Função, VLAN ou ACL derivada do grupo do diretório | Desativação no diretório, além de CoA se o controlador for compatível |
| Prestador de serviço | Grupo de diretório com prazo definido | Função restrita, em vez da VLAN completa de colaboradores | Expiração do grupo ou término do chamado |
| Dispositivos legados e IoT | PSK exclusiva ou outra credencial de escopo restrito | Segmento próprio sem rota lateral além dos serviços explicitamente permitidos | Rotação da chave ou desvinculação do proprietário |
| Residente multi-inquilino | PSK exclusiva por pessoa ou residência | Rede privativa isolada de outros inquilinos | Revogação da chave no momento da mudança (saída) |
Mantenha a integração facilitada separada do acesso amplo
Visitantes precisam de um processo de entrada sem atritos, geralmente informando o e-mail. No entanto, uma tela de boas-vindas não criptografa a conexão sem fio por si só. Escolha um método de acesso criptografado sempre que houver suporte e não utilize a conclusão no portal como autorização para acessar sistemas internos.
Colaboradores precisam de autenticação empresarial vinculada ao diretório. Prestadores de serviço precisam de prazo de expiração e funções mais restritas, mesmo quando trabalham lado a lado com funcionários. Atribua aos responsáveis operacionais a tarefa de prorrogar o acesso de terceiros em vez de manter contas ativas por tempo indeterminado.
Moradores e inquilinos comerciais têm outra exigência: seus próprios dispositivos devem se comunicar entre si sem ficarem expostos aos vizinhos. Nosso guia de WiFi multi-inquilino analisa esse modelo de rede privativa.
Use chaves exclusivas para dispositivos limitados
Impressoras, TVs, consoles e scanners podem não suportar o método EAP exigido. Uma chave pré-compartilhada exclusiva, frequentemente chamada de iPSK ou xPSK, permite associar o acesso a uma pessoa, residência ou dispositivo sem ter de retornar a uma senha única para todo o edifício.
A chave isoladamente não gera o isolamento. O controlador e a rede precisam mapeá-la para o segmento privativo desejado e aplicar as rotas permitidas. Trate a credencial como transferível, registre seu proprietário e revogue-a assim que essa posse for encerrada.
Oferecemos WiFi para visitantes, segurança 802.1X em WiFi para colaboradores e redes de área privada xPSK em uma única plataforma na nuvem. Nosso WiFi multi-inquilino e xPSK fornece a cada residente, inquilino ou dispositivo uma chave exclusiva com isolamento de inquilino, incluindo conectividade privativa para TVs e consoles sem navegador.
Para operadores residenciais, coordene a saída digital com a remoção do acesso físico. O controle de acesso a portões residenciais da Nimbio oferece um paralelo útil para analisar a titularidade de credenciais dos residentes. Nem o acesso do ex-residente ao portão nem sua chave de rede devem continuar ativos após a mudança.
Como migrar sem depender de uma senha compartilhada de contingência
A migração deve comprovar que cada perfil de dispositivo consegue se conectar com segurança antes de desativar a estrutura antiga. O erro operacional é tratar cada exceção como justificativa para manter uma senha de emergência para todo o edifício.
A necessidade de um planejamento criterioso vai além do WiFi: uma reportagem da Cyber Magazine sobre uma pesquisa da Hiscox indica que dois terços das empresas entrevistadas planejam implementar uma arquitetura Zero Trust até 2030. Isso demonstra uma intenção futura, não que suas redes atuais estejam em conformidade com o modelo.
Execute a transição em uma sequência controlada
- Classifique os dispositivos clientes. Separe os endpoints de colaboradores compatíveis com 802.1X, equipamentos legados ou sem navegador e visitantes. Registre a propriedade dos dispositivos e a criticidade operacional.
- Valide os recursos do controlador. Confirme o suporte a autenticação empresarial, VLANs ou funções dinâmicas, CoA e qualquer jardim murado exigido. Verifique o firmware instalado, não apenas a família do produto.
- Faça um piloto com um SSID limitado em um local selecionado. Conecte-o ao diretório e documente o comportamento fail-closed. Inclua um dispositivo operacional representativo, e não apenas um notebook da equipe de TI.
- Provisione os dispositivos gerenciados dos colaboradores. Use certificados ou um método empresarial sem senha compatível. Nosso WiFi para colaboradores opera nos pontos de acesso existentes sem que o cliente precise construir uma PKI.
- Forneça credenciais de escopo definido a dispositivos limitados. Emita chaves PSK exclusivas para impressoras, equipamentos médicos e IoT quando pertinente. Autorize apenas os destinos necessários.
- Mantenha os visitantes em uma política separada. Teste para garantir que dispositivos de visitantes não acessem recursos de colaboradores, mesmo que o onboarding e a autenticação compartilhem a mesma plataforma de gestão.
- Simule cenários de indisponibilidade. Interrompa o acesso ao provedor de identidade e a conexão de internet do local em testes separados. Comprove a recuperação sem ter de distribuir uma senha genérica.
- Faça a transição progressiva. Revise o registro de contabilização, a segmentação e o comportamento dos clientes em cada local. Remova a senha antiga somente após a aprovação nos testes de aceitação.
Saiba quando não fazer a migração
Locais isolados da internet (air-gapped) não podem depender de um plano de controle na nuvem. Controlador de rede incapaz de processar os atributos RADIUS exigidos também pode inviabilizar o projeto, mesmo que a autenticação básica funcione.
Requisitos internos de manter os metadados de autenticação no Reino Unido devem ser atendidos por meio de documentação formal de locais de processamento e contratos com subcontratados. Ter apenas um escritório no Reino Unido não é suficiente. Retenção de registros, acesso administrativo e planos de recuperação também devem fazer parte do processo de aprovação de compras.
Nosso serviço funciona como uma sobreposição na nuvem nos pontos de acesso já instalados, não exigindo a substituição da infraestrutura existente. Nosso WiFi multi-inquilino e xPSK é compatível com hardwares da Meraki, Aruba, Ruckus e UniFi, sujeito aos recursos do controlador exigidos pelo projeto.
Uma abordagem híbrida com autenticação empresarial e chaves exclusivas resolve a compatibilidade de dispositivos clientes, mas não necessariamente a dependência em relação a quedas na nuvem. Onde a autonomia local for indispensável, mantenha uma estrutura adequada de autenticação local ou permaneça com servidores locais. Não mascare um requisito de resiliência não resolvido criando uma senha de exceção.
Decida se o RADIUS na nuvem é adequado para o seu parque de rede
Escolha o RADIUS na nuvem quando múltiplos locais precisarem de acesso consistente baseado em identidade e sua equipe não desejar realizar a manutenção de servidores de autenticação. A justificativa mais forte é operacional: alterações no diretório devem reger o acesso à rede sem gerar uma carga extra de administração de contas.
Permaneça no modelo local quando sua equipe já opera uma estrutura de RADIUS resiliente com eficiência, quando um serviço hospedado conflita com requisitos de processamento de dados ou se o controlador não conseguir aplicar a política proposta. Uma migração que elimina um servidor, mas reduz a disponibilidade local, não é um avanço.
Tome a decisão com base no inventário da sua infraestrutura
Escolha um modelo de acesso híbrido quando os endpoints gerenciados dos colaboradores forem compatíveis com 802.1X, mas o edifício também abrigar TVs, impressoras, scanners ou equipamentos médicos que exigem chaves de escopo restrito. O objetivo é oferecer o nível adequado de segurança para cada perfil, e não credenciais idênticas para todos os dispositivos.
Monte um inventário com:
- Infraestrutura sem fio: SSIDs, fabricante do controlador, modelo e versão de firmware.
- Gestão de identidades: Diretório autoritativo, responsáveis pelos grupos e processo de desligamento.
- Capacidade dos clientes: Quais dispositivos suportam certificados e quais não suportam.
- Dependências operacionais: Sistemas que precisam permanecer disponíveis durante uma perda de conectividade.
Compare compromissos por escrito, não apenas demonstrações
Faça as mesmas perguntas a todos os provedores pré-selecionados: o que o compromisso de disponibilidade cobre durante falhas em múltiplos locais, por quanto tempo os registros são mantidos, onde os metadados de autenticação são processados, quais subcontratados têm acesso a eles e como a recuperação evita o uso de senhas compartilhadas de contingência?
Inclua a Purple entre os provedores avaliados se a sua infraestrutura se encaixar no padrão de visitantes, colaboradores e multi-inquilino. Damos suporte a esses ambientes desde 2012 em redes de varejo, organizações de saúde, estádios, hubs de transporte e centros urbanos. Os preços do nosso WiFi para colaboradores não são publicados, portanto entre em contato para receber uma cotação personalizada para a sua infraestrutura.
Seu próximo passo é criar um plano de aceitação fundamentado no inventário. Uma demonstração impecável jamais deve substituir a aprovação prática utilizando o seu controlador, o seu diretório e os seus dispositivos mais complexos.
A Purple oferece RADIUS hospedado para autenticação de colaboradores, além de WiFi para visitantes e acesso multi-inquilino isolado. Visite a Purple com seu inventário de controladores, requisitos do provedor de identidade e lista de dispositivos legados para discutir uma implantação e valores adequados à sua infraestrutura.
