Mudar o seu servidor RADIUS para a nuvem não é, por si só, uma estratégia de segurança WiFi. O conselho popular de substituir o FreeRADIUS ou o Windows NPS por um endpoint alojado ignora as perguntas mais difíceis: de quem é a identidade que controla o acesso, como é que quem sai da empresa o perde e o que acontece quando o local não consegue aceder ao serviço.
O RADIUS as a Service é mais útil como um controlo de governação de identidades, e não apenas como uma troca de servidor. Para locais e empresas do Reino Unido, a arquitetura certa combina frequentemente a autenticação de colaboradores associada ao diretório com chaves exclusivas para dispositivos que não conseguem utilizar a autenticação empresarial moderna. Uma transição exclusiva por certificados não é automaticamente a opção mais forte.
O Que o RADIUS as a Service Muda no WiFi
O RADIUS as a Service é um plano de controlo alojado para autenticação, autorização e contabilização (AAA). O seu ponto de acesso ou controlador WLAN continua a ser o ponto de aplicação de políticas. O serviço alojado decide se permite a entrada de um utilizador ou dispositivo e devolve a política de rede a aplicar.
Comparação entre RADIUS no local, na nuvem e federado
| Modelo | Quem opera o AAA | Fonte de identidade | Tolerância a falhas e crescimento | Ideal para |
|---|---|---|---|---|
| FreeRADIUS no local ou Windows NPS | A sua equipa aplica correções e monitoriza o serviço | Diretório local ou um fornecedor de identidades alcançado através do seu servidor | A sua equipa aplica correções, cria clusters e monitoriza cada instância, configurando depois sites adicionais | Um único site com competências internas em RADIUS |
| RADIUS as a Service na nuvem | O fornecedor aplica correções e monitoriza o serviço alojado | Entra ID, Okta, Google Workspace ou outro fornecedor de identidades suportado | Endpoints e SLA do fornecedor, com novos sites adicionados sem novos servidores de autenticação | Locais com múltiplos sites sem uma equipa dedicada a RADIUS |
| Proxy RADIUS federado | Operadores de proxy partilhados e o fornecedor de identidades de origem | Credenciais da organização de origem | Infraestrutura de proxy nacional ou partilhada liga os sites participantes | Utilizadores em itinerância entre sites geridos de forma independente |
Mudar o servidor não cria uma arquitetura de confiança zero (zero trust). A segurança continua a depender de identidades únicas, revogação imediata e uma regra definida para decidir se o acesso falha em modo aberto ou fechado quando a autenticação estiver indisponível.
Uma frase de passe WiFi partilhada não consegue identificar uma pessoa de forma fiável. Nem permite revogar o acesso de um colaborador que sai da empresa sem alterar essa palavra-passe para todos os outros. Manter os visitantes afastados dos sistemas dos colaboradores também exige políticas de rede, e não apenas uma palavra-passe diferente.
Separe o modelo operacional da política de acesso
O alojamento na nuvem altera 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 a sua equipa aplicar correções ou gerir a redundância em servidores de autenticação no local. A sua equipa continua a controlar as regras de acesso, os grupos do diretório e a arquitetura da rede local.
A federação resolve um problema diferente: permitir que as pessoas se autentiquem em locais geridos de forma independente. Segundo o resumo de gestão do eduroam da Jisc, o serviço do Reino Unido foi lançado a 2 de maio de 2006, redirecionando a autenticação dos visitantes para a sua instituição de origem em vez de exigir que os locais visitados administrem contas de visitantes locais. Trata-se de uma gestão delegada de identidades, e não meramente de um alojamento remoto de servidores.
Regra prática: Identifique o modelo que corresponde a quem gere a identidade atualmente e, em seguida, decida se essa titularidade deve mudar.
A autenticação também não é uma solução para má cobertura de rádio, congestionamento ou uma ligação à Internet fraca. O guia da Madeira Remote sobre como melhorar o WiFi para videochamadas mais fluidas é um contexto útil para separar o trabalho de qualidade de ligação do trabalho de controlo de acessos. Corrigir a admissão à rede não vai reparar um canal sem fios sobrecarregado.
A decisão é, portanto, operacional e técnica. Pode externalizar a manutenção dos servidores, mantendo a responsabilidade exata sobre quem acede a cada rede.
Como o Cloud RADIUS Decide o Acesso
Um portátil gerido liga-se a um SSID configurado para WPA2-Enterprise ou WPA3-Enterprise. Em vez de comprovar o conhecimento de uma frase de passe válida para todo o edifício, inicia uma troca com o Extensible Authentication Protocol (EAP) através do ponto de acesso.
O ponto de acesso ou controlador empacota essa troca num Access-Request de RADIUS e envia-o para o serviço alojado. O EAP pode exigir várias trocas antes que o serviço tenha informação suficiente para tomar uma decisão.
Testar as funções de AAA separadamente
A documentação da arquitetura FreeRADIUS do governo do Reino Unido descreve o serviço através de autenticação, autorização e contabilização. Trate estas componentes como testes de aceitação separados, e não como nomes intercambiáveis para um início de sessão bem-sucedido.
- A autenticação estabelece a identidade. O serviço avalia a credencial ou certificado através do método configurado. Um Access-Challenge continua a troca, um Access-Reject nega a admissão e um Access-Accept permite-a.
- A autorização atribui permissões. A resposta pode incluir uma VLAN, função, lista de controlo de acessos (ACL) ou limite de sessão. O controlador tem de compreender e aplicar esses atributos.
- A contabilização regista a sessão. Recolhe inícios de sessão, atualizações intermédias e paragens com identificadores estáveis de identidade e dispositivo, carimbos de data/hora e identificadores de sessão.
Um Access-Accept não prova que a segmentação funcionou. Suponhamos que um prestador de serviços se autentica com sucesso, mas acaba na VLAN de colaboradores porque o controlador ignora um atributo de função. A autenticação teve êxito, mas a arquitetura de acessos falhou.
Da mesma forma, o resultado da autenticação num painel de controlo do fornecedor não substitui a contabilização de sessões. É necessário associar uma identidade a um dispositivo, local e sessão, incluindo o momento exato em que o acesso começou e terminou.
Projete a pensar em endpoints inacessíveis
Configure endpoints de serviço redundantes, monitorização de estado de funcionamento e temporizadores de nova tentativa limitados. Tentativas infinitas podem deixar os clientes pendentes e dificultar o diagnóstico. O nosso RADIUS na nuvem funciona com failover de várias regiões respaldado por um SLA de 99,9% de disponibilidade, mas a conetividade do local e o comportamento do controlador ainda exigem os seus próprios testes.
Defina a regra para falhas antes da entrada em produção. O comportamento fail-open pode admitir dispositivos sem as verificações pretendidas, criando potencialmente acessos sem restrições. O comportamento fail-closed nega novas admissões, o que protege o perímetro, mas pode interromper terminais de pagamento ou outro equipamento operacional.
Não assuma que as sessões existentes e as novas ligações se comportam da mesma forma durante uma falha. Teste a autenticação inicial, a reautenticação e a recuperação de endpoints separadamente, e obtenha por escrito o compromisso de disponibilidade e a arquitetura de failover.
Conclua o piloto com evidências observáveis:
- Sessão aceite: O cliente acede à VLAN pretendida e apenas aos serviços permitidos.
- Identidade desativada: Uma nova tentativa de autenticação recebe uma rejeição (reject).
- Contabilização pesquisável: Um administrador consegue encontrar posteriormente o registo de sessão resultante.
Controlos de Segurança que um Serviço Alojado Deve Comprovar
Em 2024, 50% das empresas do Reino Unido sofreram uma violação ou ataque informático nos 12 meses anteriores, com a taxa a ultrapassar os 70% nas médias e grandes empresas, de acordo com a análise sobre zero trust da Consultancy.uk. Um serviço de início de sessão alojado não responde a essa exposição por si só.
Zero trust significa autenticar e autorizar acessos em vez de confiar num dispositivo apenas porque este acedeu ao SSID corporativo. Um serviço na nuvem pode continuar a aplicar políticas fracas através de credenciais partilhadas, falta de verificações nos dispositivos ou permissões demasiado abrangentes.
Exija evidências em cada limite
Comece pela credencial e examine depois o transporte, a administração e a aplicação de políticas. Cada uma destas etapas apresenta um modo de falha diferente.
- Identidades nominais: Utilize contas individuais ou identidades de dispositivo, com remoção baseada no diretório em vez de uma lista de acessos mantida manualmente.
- Autenticação forte do cliente: Privilegie a autenticação de dispositivos baseada em certificados para endpoints geridos. Utilize métodos resistentes a phishing onde suportado e exija autenticação multifator (MFA) para a administração e fluxos adequados de integração (onboarding).
- Transporte protegido: Proteja o caminho entre o controlador e o serviço com um transporte encriptado adequado, como o RadSec ou um túnel seguro. O segredo partilhado do RADIUS por si só não encripta toda a troca.
- Administração separada: Mantenha as identidades de administrador com privilégios separadas das contas do dia a dia e conserve um registo de auditoria das alterações de políticas.
- Funções de menor privilégio: Conceda aos colaboradores, prestadores de serviços, equipamentos clínicos e sistemas de gestão de edifícios apenas o acesso estritamente necessário.
Não assuma que o pedido de MFA baseado em browser de um diretório na nuvem pode surgir dentro de qualquer troca EAP. O método EAP escolhido, o software cliente e a integração de identidades devem suportar o fluxo de autenticação pretendido.
Verifique também os controlos operacionais e sem fios
Configure a segurança empresarial sem fios com validação de certificados de servidor, autenticação mútua e tramas de dados encriptadas. Exija Protected Management Frames (PMF) onde suportado e adequado ao modo WPA escolhido, em vez de considerar a classificação empresarial como prova de que todas as proteções estão ativas.
Para a definição global de políticas, o nosso guia de segurança WiFi empresarial é um complemento útil. O nosso WiFi para colaboradores oferece segurança de nível empresarial sem a complexidade de um NAC, mas os administradores continuam a ter de definir os limites de acesso e monitorizar a sua operação.
A infraestrutura física continua a ser relevante mesmo quando a autenticação é alojada. As orientações da ABCO Security Services Australia sobre o reforço da segurança em datacenters oferecem um contexto complementar para proteger as instalações que suportam os serviços de rede.
Uma credencial válida não deve conceder a um dispositivo permissão para aceder a tudo no edifício.
Atribua um responsável pelos alertas de rejeições repetidas, alterações inesperadas de privilégios e atividades administrativas suspeitas. Os registos (logs) só são úteis se alguém os puder interpretar e agir.
Ligar Diretórios sem um Segundo Armazém de Utilizadores
O diretório autoritativo deve continuar a ser o local onde o estado de emprego e a pertença a grupos são geridos. Quer se trate do Entra ID, Okta ou Google Workspace, a integração do RADIUS alojado deve traduzir a identidade em permissões de rede, e não criar uma base de dados de palavras-passe desligada.
O método de integração é importante. Um conector pode sincronizar grupos, validar credenciais através de um mecanismo suportado ou associar certificados a identidades do diretório. Não assuma que todos os diretórios na nuvem disponibilizam a mesma interface de validação de palavras-passe.
Acompanhe as entradas, mobilidades e saídas de colaboradores
Pense num novo colaborador a entrar para a equipa de instalações. Assim que a sua pertença ao diretório estiver correta e o seu dispositivo registado, o serviço deve atribuir a função de rede correspondente às instalações sem que o administrador tenha de criar uma conta WiFi separada.
Quando esse colaborador se mudar para a área financeira, a alteração no diretório deve resultar na VLAN ou ACL adequada na avaliação de política seguinte. Uma arquitetura bem-concebida elimina a necessidade de editar controladores individuais, mas deve especificar quando é que as associações em cache e as sessões existentes são atualizadas.
No caso de uma saída de colaborador, a desativação da conta no diretório deve impedir autenticações subsequentes dentro de um prazo acordado. A alteração de autorização (Change of Authorisation ou CoA) pode desligar ou alterar uma sessão ativa quando o controlador a suportar e a integração a acionar. As implementações baseadas em certificados também exigem um processo explícito de revogação de certificados ou verificações de estado da identidade.
Condição de aceitação: Acorde com que rapidez uma alteração no diretório afeta as novas autenticações e as sessões ativas. Teste ambas as situações em vez de aceitar "automático" como um compromisso de tempo.
O princípio de controlo de identidades e acessos do NCSC defende a verificação e autorização de utilizadores, dispositivos e sistemas antes de conceder acesso. Aplicado ao WiFi, isto torna a gestão do ciclo de vida um requisito de segurança e não apenas uma comodidade de integração.
Confirme o limite de integração
O CoA, as funções dinâmicas e o comportamento de jardim murado (walled garden) dependem do controlador do local. Em parques de equipamentos Meraki, Aruba, Ruckus, Mist e UniFi, confirme o modelo exato, o firmware e o suporte de funcionalidades em vez de confiar apenas no nome do fabricante.
Os portáteis geridos podem utilizar EAP-TLS ou outro método empresarial sem palavra-passe suportado. Os visitantes não devem ter de passar pelo mesmo processo de certificados de dispositivos geridos. O SSO deve estar presente na consola administrativa e nos fluxos de integração de colaboradores adequados, mas não substitui o 802.1X na ligação sem fios.
Para uma implementação liderada pelo Entra, utilize a 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 colaborador configurado corretamente deve conseguir ligar-se.
- Mobilidade: Uma alteração de grupo deve atribuir a função de rede pretendida.
- Saída: Uma conta desativada numa hora de teste registada deve falhar dentro do prazo de revogação acordado.
Padrões de Acesso para Visitantes, Colaboradores e Ambientes Multi-inquilino
Um edifício alberga diferentes populações com diferentes limites de confiança. Um hóspede de um hotel, o portátil de um colaborador e a televisão de um inquilino não devem herdar a mesma política de acesso apenas por utilizarem os mesmos pontos de acesso.
Escolha a linha correspondente à população antes de selecionar o ecrã de integração. O método tem de funcionar no dispositivo, enquanto a rede deve impedir o acesso a utilizadores e sistemas não relacionados.
Padrão de acesso por população
| População | Método de autenticação | Isolamento | Como termina o acesso |
|---|---|---|---|
| Visitante | E-mail ou identidade temporária, com encriptação onde se utilize enterprise ou Passpoint | Função ou VLAN de visitante sem rota para colaboradores | Expiração da sessão ou política do portal |
| Colaboradores e dispositivos geridos | Identidade do diretório via EAP, frequentemente certificados ou autenticação empresarial sem palavra-passe | Função, VLAN ou ACL proveniente do grupo do diretório | Desativação no diretório, além de CoA se o controlador o suportar |
| Prestador de serviços | Grupo de diretório com limite temporal | Função restrita, e não a VLAN completa dos colaboradores | Expiração do grupo ou fim do pedido de suporte |
| Dispositivos legados e IoT | PSK única ou outra credencial com âmbito estritamente definido | Segmento próprio sem caminho lateral além dos serviços explicitamente permitidos | Rotação de chave ou desassociação do proprietário |
| Residente em espaço multi-inquilino | PSK única por pessoa ou habitação | Rede privada isolada dos restantes inquilinos | Revogação da chave no momento da saída |
Mantenha a integração fácil separada de acessos abrangentes
Os visitantes precisam de uma integração sem complicações, frequentemente através de identificação por e-mail. Contudo, uma página de entrada (splash page) não encripta por si só a ligação sem fios. Selecione um método de acesso encriptado onde suportado e não utilize a conclusão bem-sucedida do portal como permissão para aceder a sistemas internos.
Os colaboradores precisam de autenticação empresarial associada ao diretório. Os prestadores de serviços necessitam de uma data de expiração e de uma função mais restrita, mesmo quando trabalham lado a lado com os funcionários. Atribua aos responsáveis operacionais a responsabilidade de prorrogar o acesso de prestadores de serviços, em vez de deixar contas ativas indefinidamente.
Os residentes e inquilinos comerciais têm outro requisito: os seus próprios dispositivos devem funcionar em conjunto sem os expor aos vizinhos. O nosso guia de WiFi multi-inquilino analisa esse modelo de rede privada.
Utilize chaves exclusivas para dispositivos limitados
Impressoras, televisores, consolas e scanners podem não suportar o método EAP necessário. Uma chave pré-partilhada exclusiva (unique pre-shared key), frequentemente chamada iPSK ou xPSK, permite associar o seu acesso a uma pessoa, habitação ou dispositivo sem repor uma palavra-passe geral para todo o edifício.
A chave por si só não cria isolamento. O controlador e a rede devem mapeá-la para o segmento privado pretendido e aplicar os caminhos permitidos. Trate a credencial como transferível, registe o seu proprietário e revogue-a quando essa titularidade terminar.
Disponibilizamos WiFi para visitantes, segurança 802.1X para colaboradores e Redes de Área Privada xPSK numa única plataforma na nuvem. O nosso xPSK e WiFi multi-inquilino concede a cada residente, inquilino ou dispositivo uma chave exclusiva com isolamento de inquilinos, incluindo conetividade privada para consolas e televisores sem browser.
Para operadores residenciais, coordene a saída digital com a remoção do acesso físico. O controlo de acesso a portões para habitações multifamiliares da Nimbio é um paralelo útil para refletir sobre a posse de credenciais por parte dos residentes. Nem o acesso de um ex-residente ao portão nem a sua chave de rede devem permanecer ativos após a saída.
Como Migrar sem Recorrer a uma Palavra-passe Partilhada de Recurso
Uma migração deve comprovar que cada população de dispositivos se consegue ligar em segurança antes de desativar a estrutura antiga. O erro operacional consiste em tratar cada exceção como um motivo para manter uma palavra-passe de emergência para todo o edifício.
A necessidade de um planeamento deliberado vai além do WiFi: o relatório da Cyber Magazine sobre um inquérito da Hiscox indica que dois terços das empresas inquiridas planeiam implementar uma arquitetura zero trust até 2030. Trata-se de uma intenção futura declarada, e não de prova de que as suas redes atuais cumprem o modelo.
Execute a transição numa sequência controlada
- Classifique os clientes. Separe os endpoints de colaboradores compatíveis com 802.1X, o equipamento legado ou sem browser e os visitantes. Registe a titularidade dos dispositivos e a sua criticidade operacional.
- Valide as capacidades do controlador. Confirme a autenticação empresarial, VLANs ou funções dinâmicas, CoA e qualquer jardim murado (walled garden) necessário. Verifique o firmware instalado e não apenas a família de produtos.
- Realize um piloto com um SSID limitado num site selecionado. Ligue-o ao diretório e documente o comportamento em fail-closed. Inclua um dispositivo operacional representativo, e não apenas um portátil do departamento de TI.
- Aprovisione dispositivos de colaboradores geridos. Utilize certificados ou um método empresarial sem palavra-passe suportado. O nosso WiFi para colaboradores funciona sobre pontos de acesso existentes sem necessidade de criar uma PKI no cliente.
- Atribua credenciais delimitadas a dispositivos limitados. Emita chaves PSK exclusivas para impressoras, equipamento médico e IoT, onde apropriado. Permita apenas os destinos estritamente necessários.
- Mantenha os visitantes numa política separada. Teste se os dispositivos de visitantes não conseguem aceder aos recursos dos colaboradores, mesmo quando a integração e a autenticação partilham a mesma plataforma de gestão.
- Simule o cenário de falha. Interrompa o acesso ao fornecedor de identidades e a conetividade do local à Internet de forma separada. Comprove a recuperação sem distribuir uma palavra-passe comum.
- Efetue a transição de forma progressiva. Reveja a contabilização, a segmentação e o comportamento dos clientes em cada site. Remova a frase de passe antiga após o sucesso dos testes de aceitação acordados.
Saiba quando não deve migrar
Sites isolados (air-gapped) não podem depender de um plano de controlo na nuvem. Os controladores incapazes de processar os atributos RADIUS necessários também podem bloquear a arquitetura pretendida, mesmo que a autenticação básica funcione.
O requisito interno de manter os metadados de autenticação no Reino Unido deve ser resolvido através de locais de processamento e acordos com subcontratados devidamente documentados. Ter apenas um escritório do fornecedor no Reino Unido não satisfaz esse requisito. A retenção de registos, o acesso administrativo e os acordos de recuperação também devem fazer parte da aprovação de aquisição.
O nosso serviço funciona como uma sobreposição na nuvem (cloud overlay) sobre pontos de acesso existentes, pelo que não exige a substituição integral da infraestrutura. O nosso xPSK e WiFi multi-inquilino suportam hardware Meraki, Aruba, Ruckus e UniFi, sujeito às capacidades do controlador exigidas pela arquitetura.
Um modelo híbrido de autenticação empresarial e chaves exclusivas resolve a compatibilidade dos clientes, mas não necessariamente a dependência de falhas na nuvem. Onde a autonomia local for essencial, mantenha uma arquitetura de autenticação local adequada ou permaneça no local. Não disfarce um requisito de resiliência não resolvido como uma palavra-passe de exceção.
Decida se o Cloud RADIUS se Adequa à Sua Infraestrutura
Escolha o cloud RADIUS quando múltiplos sites precisarem de um acesso coerente baseado em identidades e a sua equipa não quiser manter servidores de autenticação. O argumento mais forte é operacional: as alterações no diretório devem reger o acesso à rede sem criar mais carga de trabalho na administração de contas.
Permaneça no local se a sua equipa já operar com sucesso uma solução RADIUS resiliente, se um serviço alojado entrar em conflito com requisitos de processamento ou se o controlador não conseguir aplicar a política proposta. Uma migração que elimina um servidor, mas enfraquece a disponibilidade local, não representa um progresso.
Tome a decisão com base num inventário da infraestrutura
Escolha um modelo de acesso híbrido se os endpoints geridos dos colaboradores suportarem 802.1X, mas o edifício também contiver televisores, impressoras, scanners ou equipamento médico que exijam chaves delimitadas. O objetivo é garantir a segurança adequada para cada população, e não disponibilizar credenciais idênticas para todos os dispositivos.
Elabore um inventário com:
- Infraestrutura sem fios: SSIDs, fabricante do controlador, modelo e firmware.
- Titularidade da identidade: Diretório autoritativo, responsáveis pelos grupos e processo de saída de colaboradores.
- Capacidade dos clientes: Que dispositivos podem utilizar certificados e quais não podem.
- Dependências operacionais: Sistemas que têm de permanecer disponíveis durante uma perda de conetividade.
Compare compromissos por escrito, não demonstrações
Faça as mesmas perguntas a todos os serviços pré-selecionados: o que cobre o compromisso de disponibilidade durante falhas em múltiplos sites, durante quanto tempo são mantidos os registos (logs), onde são processados os metadados de autenticação, que subcontratados podem aceder aos mesmos e como é que a recuperação evita o recurso a uma palavra-passe partilhada?
Inclua a Purple na lista de candidatos juntamente com outros fornecedores quando a sua infraestrutura corresponder ao padrão de visitantes, colaboradores e multi-inquilinos. Suportamos estes ambientes desde 2012 em comerciantes, organizações de saúde, estádios, interfaces de transportes e centros urbanos. Os preços do nosso WiFi para colaboradores não estão publicados, pelo que deve contactar-nos para obter um orçamento com base na infraestrutura que vai migrar.
O seu passo seguinte é um plano de aceitação fundamentado num inventário. Uma demonstração perfeita nunca deve substituir a aprovação real com o seu controlador, o seu diretório e os seus dispositivos mais complexos.
A Purple oferece RADIUS alojado para autenticação de colaboradores, a par de WiFi para visitantes e acesso multi-inquilino isolado. Visite a Purple com o inventário dos seus controladores, requisitos do fornecedor de identidades e lista de dispositivos legados para discutir uma implementação e preços ajustados à sua infraestrutura.
