Cloud RADIUS vs On-Premise RADIUS: Guia de Decisão para Equipes de TI
Este guia oferece a diretores de TI, arquitetos de rede e equipes de operações de locais um framework definitivo para escolher entre serviços RADIUS hospedados na nuvem e servidores RADIUS on-premise tradicionais. Ele aborda a arquitetura técnica, compensações de latência e confiabilidade, custo total de propriedade e considerações de conformidade para implantações em vários locais nos setores de hotelaria, varejo e setor público. Ao final, os leitores terão um modelo de decisão claro e alinhado às restrições específicas de sua infraestrutura e ao apetite de risco de suas organizações.
Ouça este guia
Ver transcrição do podcast
Resumo Executivo
A autenticação RADIUS está no centro de toda implantação de WiFi corporativa. Quer você esteja protegendo o acesso de funcionários via IEEE 802.1X ou gerenciando a integração de convidados em uma propriedade de vários locais, a decisão de onde hospedar sua infraestrutura RADIUS tem consequências diretas no tempo de atividade, na sobrecarga operacional e no custo total de propriedade.
Os serviços Cloud RADIUS fornecem infraestrutura de autenticação gerenciada e distribuída globalmente com alta disponibilidade integrada, rotação automática de certificados e escalabilidade elástica — eliminando a carga de manutenção por local que assola as implantações locais distribuídas (on-premise). O RADIUS on-premise, seja executando FreeRADIUS ou Microsoft NPS, oferece autenticação local de submilisegundos, soberania total de dados e independência de conectividade WAN — vantagens que permanecem decisivas em ambientes específicos de alta densidade ou regulamentados.
Para a maioria dos operadores de vários locais — grupos hoteleiros, redes de varejo, centros de conferências — o Cloud RADIUS oferece um resultado operacional superior com um custo total de propriedade em cinco anos menor. As exceções são bem definidas: ambientes isolados (air-gapped), mandatos rígidos de residência de dados e implantações de local único muito grandes onde o desempenho da LAN local é primordial. Este guia fornece a estrutura para determinar em qual categoria sua implantação se enquadra e como agir de acordo com essa decisão.
Análise Técnica Detalhada
O Protocolo RADIUS e seu Papel na Infraestrutura 802.1X
O RADIUS (Remote Authentication Dial-In User Service, RFC 2865) opera como o intermediário de autenticação entre sua camada de acesso à rede e seu diretório de identidade. Em uma implantação 802.1X , o ponto de acesso ou switch atua como o Network Access Server (NAS), encaminhando quadros de autenticação EAP para o servidor RADIUS via UDP (porta 1812 para autenticação, porta 1813 para contabilização/accounting). O servidor RADIUS valida as credenciais do solicitante em um diretório de back-end — Active Directory, LDAP ou um Provedor de Identidade em nuvem — e retorna uma resposta Access-Accept ou Access-Reject, incluindo opcionalmente atributos de atribuição de VLAN.
Essa arquitetura é fundamentalmente a mesma se o seu servidor RADIUS for um equipamento montado em rack em sua sala de servidores ou um serviço de nuvem distribuído globalmente. A diferença está em onde esse servidor reside, quem o mantém e como ele escala.
RADIUS On-Premise: Arquitetura e Trade-offs
As duas plataformas de RADIUS on-premise dominantes são o FreeRADIUS e o Microsoft Network Policy Server (NPS). O FreeRADIUS é o servidor RADIUS mais amplamente implantado no mundo, oferecendo suporte a uma ampla variedade de métodos EAP, incluindo EAP-TLS, PEAP-MSCHAPv2, EAP-TTLS e EAP-PWD. Ele se integra a praticamente qualquer diretório de backend via LDAP, SQL ou REST, e está disponível sem custo de licenciamento. No entanto, exige uma administração especializada: a configuração é baseada em arquivos, a depuração requer experiência em análise de logs e o dimensionamento em dezenas de locais exige um planejamento cuidadoso de replicação e failover.
O Microsoft NPS integra-se nativamente com o Active Directory e é a escolha padrão para ambientes centrados em Windows. Ele oferece suporte a PEAP-MSCHAPv2 e EAP-TLS nativamente e é gerenciado por meio da interface familiar do Windows Server. O trade-off é a forte dependência do licenciamento do Windows Server e um conjunto de métodos EAP mais limitado em comparação com o FreeRADIUS.
Para implantações on-premise de alta disponibilidade, as organizações normalmente implantam clusters RADIUS ativo-ativo ou ativo-passivo. Os pontos de acesso são configurados com um endereço de servidor RADIUS primário e secundário; se o primário não responder dentro do tempo limite configurado (geralmente de 3 a 5 segundos), o NAS faz failover para o secundário. Essa arquitetura exige servidores geograficamente dispersos — o que introduz sua própria complexidade — ou um par de servidores na mesma instalação, o que não protege contra uma interrupção no nível do local.
Perfil de latência: O RADIUS on-premise oferece tempos de ida e volta (round-trip) de autenticação de menos de 1 milissegundo em uma LAN local. Para ambientes de alta densidade que processam milhares de autenticações simultâneas — um estádio de 68.000 assentos durante um evento lotado, por exemplo —, essa capacidade de processamento local é uma vantagem operacional real.
Cloud RADIUS: Arquitetura e Trade-offs
As plataformas Cloud RADIUS hospedam a infraestrutura RADIUS em várias zonas de disponibilidade distribuídas geograficamente. Quando um ponto de acesso envia uma solicitação de autenticação, ela é roteada para o nó de borda de nuvem (edge node) mais próximo, geralmente adicionando de 5 a 50 milissegundos de latência de ida e volta, dependendo da proximidade do ponto de presença do provedor com o local. Para a grande maioria dos casos de uso de autenticação, essa latência é imperceptível para os usuários finais. The high-availability model is fundamentally different from on-premise. Rather than configuring a primary/secondary pair, the cloud platform's load balancer automatically routes requests away from failed nodes. Enterprise Cloud RADIUS providers typically publish SLAs of 99.99% uptime, backed by multi-region redundancy. Achieving equivalent redundancy on-premise requires deploying active-active clusters across multiple geographically dispersed data centres — a significant engineering and capital investment.
Cloud RADIUS platforms integrate natively with cloud Identity Providers. If your organisation uses Okta, Azure Active Directory, or Google Workspace, a Cloud RADIUS service connects via SAML, LDAP-over-TLS, or proprietary API connectors. For a detailed walkthrough of Okta integration specifically, see our guide: Okta and RADIUS: Extending Your Identity Provider to WiFi Authentication .
Certificate management is one of the most compelling operational arguments for Cloud RADIUS. EAP-TLS and PEAP both rely on server-side digital certificates. On-premise, certificate expiry is a leading cause of authentication outages — a certificate expiring on a FreeRADIUS server causes every connected client to reject the server's identity, resulting in a complete WiFi outage until the certificate is renewed and deployed. Cloud RADIUS providers automate certificate rotation entirely, eliminating this failure mode.
WPA3-Enterprise and Protocol Considerations
The WiFi Alliance's WPA3-Enterprise specification introduces a 192-bit security mode mandating EAP-TLS with Suite B cryptography (ECDHE, ECDSA, AES-256-GCM). This is increasingly relevant for healthcare, finance, and government deployments. Most modern Cloud RADIUS platforms support WPA3-Enterprise natively. On-premise deployments running older FreeRADIUS versions (pre-3.0.x) or legacy NPS configurations may require upgrades before WPA3-Enterprise can be deployed. If WPA3-Enterprise is on your roadmap, validate your RADIUS platform's support before committing to an infrastructure path.
For organisations considering the SD-WAN layer that underpins multi-site cloud RADIUS deployments, our guide on The Core SD-WAN Benefits for Modern Businesses provides complementary context on WAN resilience architecture.
Implementation Guide
Step 1: Audit Your Current Authentication Dependencies
Before selecting a deployment model, document every SSID, VLAN, EAP method, and backend directory that your current authentication infrastructure touches. Include MAC Authentication Bypass (MAB) policies for headless devices — printers, IoT sensors, point-of-sale terminals — as these are frequently overlooked during migrations and can cause significant post-cutover incidents.
Passo 2: Avaliar a Preparação do Provedor de Identidade
Se o seu diretório de usuários for um Active Directory local (on-premise) e não puder ser sincronizado com um IdP em nuvem, suas opções de Cloud RADIUS ficam limitadas a plataformas que suportam proxy LDAP para diretórios locais. Se você puder implantar o Azure AD Connect ou uma ferramenta de sincronização semelhante, toda a gama de plataformas Cloud RADIUS estará disponível. Essa decisão única — IdP em nuvem versus diretório local — é frequentemente o fator determinante na escolha entre RADIUS em nuvem ou local.
Passo 3: Avaliar a Resiliência da WAN em Cada Local
O Cloud RADIUS é tão confiável quanto a conexão de internet em cada local. Antes de migrar, audite a conectividade WAN em todos os locais. Unidades com uma única conexão de ISP e sem failover representam um risco significativo. Implemente conectividade dual-ISP ou failover de SD-WAN antes de implantar o Cloud RADIUS como sua infraestrutura de autenticação primária. Para ambientes de varejo onde os sistemas de ponto de venda dependem de autenticação de rede, a resiliência da WAN é inegociável.
Passo 4: Planejar a Migração de Certificados (Implantações Locais)
Ao implantar ou manter RADIUS local com EAP-TLS, estabeleça um processo de gerenciamento do ciclo de vida dos certificados. Implemente alertas de monitoramento aos 90, 60 e 30 dias antes do vencimento do certificado. Considere implantar uma PKI interna (como Microsoft ADCS ou HashiCorp Vault) para automatizar a emissão e renovação de certificados. Nunca dependa apenas de lembretes de calendário para o gerenciamento de certificados em ambientes de produção.
Passo 5: Configurar Políticas de Sobrevivência
Para implantações de Cloud RADIUS, configure uma política de sobrevivência local em seus controladores sem fio ou access points. As opções incluem: armazenar em cache o último estado de autenticação conhecido por um período configurável, fazer fallback para MAC Authentication Bypass para listas de dispositivos pré-aprovados ou rotear SSIDs de equipes críticas por meio de um caminho de autenticação secundário. Para operadores de hospitalidade , garanta que o onboarding de WiFi de convidados por meio de plataformas como o Guest WiFi da Purple tenha um comportamento de fallback definido durante a indisponibilidade do RADIUS.
Passo 6: Executar uma Implantação Paralela
Implante a nova plataforma RADIUS em paralelo com a infraestrutura existente. Crie um SSID de teste dedicado mapeado para o novo servidor RADIUS e valide todos os métodos EAP, atribuições de VLAN e aplicação de políticas antes de migrar os SSIDs de produção. Este período de execução paralela deve ser de, no mínimo, duas semanas para uma implantação em local único e de quatro a seis semanas para uma migração multilocal.
Passo 7: Executar uma Migração Faseada Local por Local
Para implantações multilocal, migre os locais sequencialmente, em vez de simultaneamente. Comece com locais de menor risco — unidades menores com menos tráfego e usuários mais tolerantes — antes de migrar locais de alta prioridade, como lojas conceito ou propriedades hoteleiras com grande volume de conferências. Documente o procedimento de rollback para cada local antes de iniciar a transição.
Melhores Práticas
Higiene de segredos compartilhados: Os segredos compartilhados do RADIUS entre os pontos de acesso e o servidor RADIUS devem ter no mínimo 32 caracteres, ser gerados aleatoriamente e ser exclusivos por dispositivo NAS. Reutilizar segredos compartilhados em todos os pontos de acesso significa que comprometer um único dispositivo expõe toda a infraestrutura de autenticação. Rotacione os segredos compartilhados anualmente ou após qualquer suspeita de comprometimento.
Segmentação de VLAN: Use VLANs atribuídas por RADIUS (por meio dos atributos Tunnel-Type, Tunnel-Medium-Type e Tunnel-Private-Group-ID) para segmentar dinamicamente o tráfego por função de usuário. Dispositivos de convidados devem ir para uma VLAN isolada com acesso exclusivo à internet; dispositivos corporativos na VLAN de produção; dispositivos IoT em uma VLAN restrita dedicada. Essa segmentação é um requisito do PCI DSS para qualquer rede que processe dados de portadores de cartão.
Contabilidade e registro de auditoria: Ative a contabilidade do RADIUS (porta 1813) e retenha os registros de contabilidade por no mínimo 12 meses. Esses logs registram os horários de início/término das sessões, volumes de dados e endereços IP atribuídos — essenciais para investigação de incidentes de segurança e conformidade com o GDPR. As plataformas de Cloud RADIUS normalmente exportam dados de contabilidade para sistemas SIEM via syslog ou API; implantações locais (on-premise) devem direcionar os dados de contabilidade para uma plataforma centralizada de gerenciamento de logs.
Seleção do método EAP: Para redes de funcionários corporativos, o EAP-TLS (baseado em certificado) oferece a postura de segurança mais robusta e é recomendado para ambientes de saúde e PCI DSS. O PEAP-MSCHAPv2 é aceitável para ambientes de menor risco, mas é vulnerável a ataques de coleta de credenciais se o certificado do servidor não for validado corretamente pelos solicitantes. Evite totalmente o EAP-MD5 — ele foi descontinuado e não fornece autenticação mútua.
RadSec (RADIUS sobre TLS): O protocolo RADIUS tradicional transmite dados via UDP com apenas o atributo User-Password criptografado. O RadSec (RFC 6614) envolve o RADIUS em TLS, fornecendo criptografia de transporte completa e autenticação mútua entre o NAS e o servidor RADIUS. A maioria das plataformas modernas de Cloud RADIUS suporta RadSec. Para novas implantações, o RadSec deve ser a opção de transporte padrão.
Para implantações nos setores de saúde e transporte , onde as obrigações de tratamento de dados sob o GDPR e regulamentações específicas do setor são particularmente rigorosas, garanta que sua plataforma RADIUS forneça um Acordo de Processamento de Dados (DPA) e suporte a residência de dados regional.
Solução de problemas e mitigação de riscos
Modo de falha comum 1: Expiração de certificado (Local/On-Premise)
Sintoma: Todos os clientes falham repentinamente ao se autenticar; os logs do RADIUS mostram falhas no handshake TLS.
Causa raiz: O certificado do lado do servidor no servidor RADIUS expirou. Os solicitantes do cliente rejeitam a identidade do servidor.
Mitigação: Implemente o monitoramento automatizado de certificados com alertas de 90/60/30 dias. Use uma CA interna com renovação automatizada. O Cloud RADIUS elimina totalmente esse modo de falha por meio da rotação automatizada de certificados.
Modo de Falha Comum 2: Queda de WAN Bloqueando o Cloud RADIUS
Sintoma: A autenticação falha em um site específico; outros sites não são afetados. A rede local está operacional.
Causa raiz: A conexão de internet do site falhou, impedindo que os pontos de acesso alcancem o serviço Cloud RADIUS.
Mitigação: Implante conectividade dual-ISP ou SD-WAN com failover automático. Configure políticas de sobrevivência do ponto de acesso para armazenar credenciais em cache ou fazer fallback para MAB em dispositivos críticos.
Modo de Falha Comum 3: Divergência de Segredo Compartilhado (Shared Secret Mismatch)
Sintoma: As solicitações de autenticação são descartadas silenciosamente; os logs do RADIUS mostram erros de "invalid authenticator" ou "message authenticator".
Causa raiz: O segredo compartilhado configurado no ponto de acesso não corresponde ao segredo configurado no servidor RADIUS.
Mitigação: Use um sistema centralizado de gerenciamento de segredos (HashiCorp Vault, AWS Secrets Manager) para garantir a consistência. Valide os segredos compartilhados após qualquer alteração de configuração do NAS ou do servidor RADIUS.
Modo de Falha Comum 4: Desconfiguração do Supplicant
Sintoma: Dispositivos individuais falham na autenticação, enquanto outros no mesmo SSID têm sucesso.
Causa raiz: O supplicant 802.1X no dispositivo com falha não está configurado para confiar no certificado do servidor RADIUS ou está configurado para um método EAP incompatível.
Mitigação: Implante a configuração do supplicant via MDM ou Diretiva de Grupo para garantir a consistência. Para ambientes BYOD, forneça um guia de integração claro. A plataforma de WiFi Analytics da Purple pode ajudar a identificar padrões de falha de autenticação em todo o seu parque de dispositivos.
Modo de Falha Comum 5: Timeout do RADIUS Sob Carga
Sintoma: Atrasos ou falhas de autenticação durante períodos de pico (início de eventos, troca de turno).
Causa raiz: O servidor RADIUS está sobrecarregado por solicitações de autenticação simultâneas; o timeout do NAS é excedido antes que uma resposta seja recebida.
Mitigação: Local (on-premise): dimensione a capacidade do servidor RADIUS antes de eventos de pico conhecidos; implemente limitação de taxa de conexão nos pontos de acesso. Cloud RADIUS: verifique se o seu nível de assinatura suporta o seu rendimento de autenticação de pico; a maioria das plataformas de nuvem corporativas escala automaticamente.
ROI e Impacto nos Negócios
Custo Total de Propriedade: Comparação de Cinco Anos
A análise a seguir é baseada em uma rede de varejo representativa de 20 sites, com aproximadamente 50 pontos de acesso por site e 200 dispositivos autenticados simultaneamente por site no pico.
| Componente de Custo | RADIUS Local (20 sites) | Cloud RADIUS (20 sites) |
|---|---|---|
| Hardware (servidores, pares HA) | £80.000–£120.000 | £0 |
| Licenciamento de SO e Software | £10.000–£30.000 | £0 |
| Assinatura Anual | £0 | £18.000–£40.000/ano |
| Energia e Resfriamento (5 anos) | £15.000–£25.000 | £0 |
| Tempo de Engenharia (5 anos) | £60.000–£100.000 | £10.000–£20.000 |
| Total de 5 Anos | £165.000–£275.000 | £100.000–£220.000 |
| A diferença no tempo de engenharia é o fator mais significativo. O RADIUS on-premise em 20 locais exige aplicação constante de patches, gerenciamento de certificados, monitoramento e resposta a incidentes. O Cloud RADIUS reduz isso ao gerenciamento de políticas e à manutenção de integração — uma fração do esforço. |
Medindo o Sucesso
Os principais indicadores de desempenho para a sua implantação do RADIUS devem incluir: taxa de sucesso de autenticação (meta: >99,5% para ambientes de produção), latência média de autenticação (meta: <100ms para nuvem, <5ms para LAN on-premise), tempo médio de recuperação de interrupções de autenticação (meta: <15 minutos) e incidentes de expiração de certificado (meta: zero, alcançável com a automação adequada).
Para operadores do setor de hospitalidade que utilizam a plataforma Guest WiFi da Purple, a confiabilidade da infraestrutura de autenticação impacta diretamente os índices de satisfação dos hóspedes. Um atraso de autenticação de 2 segundos durante os períodos de pico de check-in é mensurável no feedback dos hóspedes. O Cloud RADIUS com políticas de sobrevivência devidamente configuradas supera consistentemente as implantações on-premise ad-hoc nessa métrica.
As organizações que migraram de implantações distribuídas do FreeRADIUS on-premise para o Cloud RADIUS relatam consistentemente uma redução de 30% a 50% nos incidentes de TI relacionados à autenticação e uma redução significativa nas horas de engenharia alocadas para a manutenção do RADIUS — horas que são realocadas para projetos estratégicos de melhoria de rede. A plataforma da Purple, que se integra a ambos os modelos de implantação, fornece dados de WiFi Analytics e Sensors para quantificar essas melhorias em relação às métricas de referência capturadas antes da migração.
Para operadores de locais que consideram o contexto mais amplo de modernização de rede, os recursos de Wayfinding da Purple e a integração de dados de autenticação com análises de fluxo de pessoas representam a próxima camada de valor que uma infraestrutura RADIUS bem arquitetada possibilita. Os eventos de autenticação são, em sua essência, dados de presença — e quando expostos por meio da camada de análise da Purple, tornam-se uma ferramenta poderosa para entender o comportamento do visitante, o tempo de permanência e as taxas de retorno em todas as suas propriedades.
Definições principais
RADIUS (Remote Authentication Dial-In User Service)
Um protocolo de rede (RFC 2865) que fornece autenticação, autorização e contabilização (AAA) centralizadas para usuários que se conectam a uma rede. O RADIUS opera sobre UDP e atua como intermediário entre os equipamentos de acesso à rede (pontos de acesso, switches) e o diretório de identidade (Active Directory, LDAP, IdP em nuvem).
As equipes de TI encontram o RADIUS sempre que implementam a autenticação 802.1X para WiFi ou redes cabeadas. Ele é o protocolo fundamental para o controle de acesso à rede corporativa e é obrigatório para implantações WPA2-Enterprise e WPA3-Enterprise.
802.1X
Um padrão IEEE para controle de acesso à rede baseado em porta que define a estrutura para autenticação baseada em EAP. Em um contexto de WiFi, o 802.1X requer três componentes: o suplicante (dispositivo cliente), o autenticador (ponto de acesso) e o servidor de autenticação (RADIUS). O ponto de acesso bloqueia todo o tráfego do cliente até que o RADIUS retorne um Access-Accept.
O 802.1X é o mecanismo de autenticação para redes WPA2-Enterprise e WPA3-Enterprise. As equipes de TI o utilizam para garantir que apenas dispositivos e usuários autorizados possam se conectar ao WiFi corporativo, com atribuição dinâmica de VLAN baseada na identidade do usuário.
EAP (Extensible Authentication Protocol)
Uma estrutura de autenticação flexível usada no 802.1X que suporta múltiplos métodos de autenticação. Os métodos EAP comuns incluem EAP-TLS (baseado em certificado, segurança mais forte), PEAP-MSCHAPv2 (baseado em senha com validação de certificado do servidor) e EAP-TTLS (autenticação por senha em túnel protegido).
A escolha do método EAP afeta diretamente a postura de segurança e a complexidade da implantação. O EAP-TLS exige certificados de cliente em cada dispositivo, tornando a implantação mais complexa, porém significativamente mais resistente a ataques de roubo de credenciais. Equipes de TI em setores regulamentados (saúde, finanças) devem adotar o EAP-TLS por padrão.
FreeRADIUS
O servidor RADIUS de código aberto mais amplamente implantado no mundo, que processa a autenticação de centenas de milhões de usuários globalmente. O FreeRADIUS suporta uma ampla gama de métodos EAP e integrações de backend, está disponível sem custo de licença e roda em Linux. Exige administração especializada e configuração baseada em arquivos.
O FreeRADIUS é a escolha padrão para implantações RADIUS locais em ambientes que não são da Microsoft. As equipes de TI que avaliam a decisão entre nuvem e local devem analisar se possuem a experiência interna necessária para operar o FreeRADIUS de maneira eficaz, já que a configuração incorreta é uma das principais causas de incidentes de autenticação.
NPS (Network Policy Server)
O servidor RADIUS integrado da Microsoft, incluído no Windows Server. O NPS se integra nativamente ao Active Directory e suporta PEAP-MSCHAPv2 e EAP-TLS. É gerenciado por meio da interface gráfica do Windows Server e é a escolha padrão de RADIUS para ambientes focados em Microsoft.
As equipes de TI que executam infraestrutura Windows Server geralmente implantam o NPS como seu servidor RADIUS local. O NPS é fortemente vinculado ao licenciamento do Windows Server e ao Active Directory, o que simplifica a implantação em ambientes Microsoft, mas limita a flexibilidade em ambientes heterogêneos ou nativos da nuvem.
MAC Authentication Bypass (MAB)
Um método de autenticação que utiliza o endereço MAC do dispositivo como credencial, permitindo que dispositivos sem interface de usuário (impressoras, sensores de IoT, terminais de ponto de venda) que não podem executar um suplicante 802.1X se autentiquem na rede. O endereço MAC é verificado em relação a uma lista de permissões no servidor RADIUS.
O MAB é essencial para qualquer rede com dispositivos IoT ou equipamentos legados. As equipes de TI devem manter inventários de endereços MAC precisos e implementar processos para adicionar novos dispositivos. As plataformas Cloud RADIUS geralmente oferecem um painel centralizado para o gerenciamento de listas MAB em todos os locais, o que é significativamente mais eficiente do que gerenciar arquivos de configuração locais no FreeRADIUS.
RadSec (RADIUS over TLS)
Uma extensão do protocolo RADIUS (RFC 6614) que transporta pacotes RADIUS sobre TLS em vez de UDP. O RadSec fornece criptografia total de transporte e autenticação mútua entre o NAS e o servidor RADIUS, corrigindo várias vulnerabilidades de segurança documentadas no protocolo RADIUS tradicional baseado em UDP.
O RADIUS tradicional criptografa apenas o atributo User-Password; todos os outros atributos, incluindo nomes de usuário e dados de sessão, são transmitidos em texto claro. O RadSec é o mecanismo de transporte moderno e seguro para o RADIUS e é suportado pela maioria das plataformas Cloud RADIUS corporativas e fornecedores de pontos de acesso modernos. As equipes de TI que implantam uma nova infraestrutura RADIUS devem avaliar o RadSec como transporte padrão.
VLAN Assignment (RADIUS-assigned VLAN)
Uma funcionalidade do RADIUS que atribui dinamicamente um dispositivo de conexão a uma VLAN específica com base no resultado da autenticação. O servidor RADIUS retorna os atributos Tunnel-Type (13=VLAN), Tunnel-Medium-Type (6=802) e Tunnel-Private-Group-ID (ID da VLAN) na resposta Access-Accept, e o ponto de acesso coloca o dispositivo na VLAN especificada.
A atribuição dinâmica de VLAN é o mecanismo pelo qual as equipes de TI implementam a segmentação de rede com base na identidade do usuário. Um único SSID pode atender a vários tipos de usuários — convidados, funcionários, prestadores de serviços, dispositivos IoT — com cada tipo posicionado automaticamente na VLAN apropriada com base no resultado de sua autenticação RADIUS. Este é um requisito do PCI DSS para redes que processam dados de portadores de cartão.
High Availability (HA) RADIUS
Uma arquitetura de implantação RADIUS que garante que os serviços de autenticação permaneçam disponíveis mesmo em caso de falhas em servidores individuais. Os padrões comuns de HA incluem cluster ativo-ativo (ambos os servidores processam o tráfego simultaneamente, com balanceamento de carga), failover ativo-passivo (o servidor secundário assume quando o primário falha) e redundância distribuída geograficamente (servidores em locais físicos distintos).
A alta disponibilidade (HA) é uma consideração de projeto crítica para qualquer implantação de RADIUS em produção. As equipes de TI devem definir seu Objetivo de Tempo de Recuperação (RTO) — a rapidez com que a autenticação deve ser restaurada após uma falha — e projetar sua arquitetura de HA de acordo. Os provedores de Cloud RADIUS oferecem HA como um serviço integrado; a HA local exige um projeto arquitetônico explícito e manutenção contínua.
Exemplos práticos
Um grupo hoteleiro europeu opera 45 propriedades em seis países. Cada propriedade possui entre 150 e 400 quartos de hóspedes, além de instalações para conferências. A equipe central de TI é composta por três engenheiros de rede. Atualmente, eles executam o FreeRADIUS em máquinas virtuais em cada propriedade — 45 instâncias separadas. A expiração de um certificado em uma propriedade causou uma interrupção completa do WiFi de hóspedes durante uma grande conferência. O CTO deseja eliminar esse tipo de incidente e reduzir os custos de manutenção. Qual é a arquitetura recomendada?
Arquitetura Recomendada: Cloud RADIUS com Integração Purple Guest WiFi
Selecione um provedor de Cloud RADIUS com residência de dados europeia (para atender às obrigações do GDPR) e integração nativa com seu IdP existente. Se o grupo hoteleiro usa o Azure AD para identidade de funcionários, selecione uma plataforma com suporte ao conector LDAP do Azure AD.
Migre os SSIDs de WiFi de hóspedes primeiro. A autenticação de hóspedes é o alvo de migração de maior volume e menor risco. Configure o Captive Portal da Purple para lidar com a integração de hóspedes (captura de dados, consentimento, página de login personalizada) e passe as sessões autenticadas para o back-end do Cloud RADIUS. Isso elimina imediatamente a manutenção do FreeRADIUS por propriedade para a rede de hóspedes.
Migre os SSIDs de funcionários propriedade por propriedade, começando pelas propriedades menores. Para cada propriedade, execute uma implantação paralela de duas semanas com um SSID de teste antes de virar o tráfego de produção.
Configure a sobrevivência de WAN em cada propriedade. Implemente conectividade SD-WAN ou dual-ISP. Configure o controlador sem fio para armazenar em cache as credenciais dos funcionários localmente por até 8 horas, garantindo que a equipe de operações do hotel possa se autenticar mesmo durante breves interrupções de internet.
Desative as VMs do FreeRADIUS em cada propriedade após a migração. Retenha snapshots das VMs por 30 dias como uma rede de segurança para rollback.
Centralize o gerenciamento de políticas por meio do painel do Cloud RADIUS. Defina políticas de atribuição de VLAN uma vez e aplique-as em todas as 45 propriedades — uma tarefa que anteriormente exigia edições em arquivos de configuração por propriedade.
Resultados esperados: Eliminação de incidentes de expiração de certificados (rotação automatizada), redução do tempo de engenharia relacionado ao RADIUS em aproximadamente 40% e melhoria na latência de autenticação nas propriedades localizadas em países onde o provedor de nuvem possui nós de borda locais.
Um estádio nacional de esportes com 68.000 assentos sedia 30 grandes eventos por ano. O pico de usuários simultâneos de WiFi excede 25.000 durante partidas com ingressos esgotados. O estádio possui uma conexão dedicada de internet de 10Gbps, mas a equipe de segurança de TI tem um requisito rígido: todos os logs de autenticação devem permanecer em solo do Reino Unido e não devem trafegar pela internet pública. O estádio também opera uma rede de ponto de venda em conformidade com o PCI DSS para concessões. Qual arquitetura RADIUS é apropriada?
Arquitetura Recomendada: RADIUS Local com Cluster Ativo-Ativo e DR em Co-location
Implante um cluster RADIUS ativo-ativo primário dentro da sala de dados local do estádio. Use dois servidores físicos executando FreeRADIUS em configuração ativo-ativo, com balanceamento de carga por meio da lista de servidores RADIUS do controlador sem fio. Cada servidor deve ser capaz de lidar com a carga total de autenticação de forma independente — dimensionado para mais de 3.000 autenticações por minuto no pico de entrada do evento.
Implante um cluster secundário em uma instalação de co-location no Reino Unido a até 30 milhas do estádio, conectado por meio de um link WAN privado dedicado (não a internet pública). Isso fornece recuperação de desastres no nível do site sem violar o requisito de soberania de dados.
Segmente o ambiente PCI DSS com uma política RADIUS dedicada para o SSID do ponto de venda. Atribua dispositivos de PDV a uma VLAN dedicada por meio de atributos RADIUS. Garanta que os logs de auditoria do RADIUS para autenticação de PDV sejam retidos por no mínimo 12 meses, armazenados localmente em conformidade com o Requisito 10 do PCI DSS.
Implemente EAP-TLS para todas as autenticações de funcionários e dispositivos de PDV. Implante uma Autoridade Certificadora interna (Microsoft ADCS ou equivalente) para emitir e gerenciar certificados de cliente. Configure a renovação automatizada de certificados com alertas antecipados de 90 dias.
Implante o RadSec (RADIUS sobre TLS) entre os pontos de acesso e o cluster RADIUS local para criptografar o tráfego de autenticação na rede interna — particularmente importante dado o ambiente público de alta densidade.
Pré-provisione capacidade antes de grandes eventos. Trabalhe com a equipe de operações de eventos do estádio para receber números de público confirmados com 72 horas de antecedência e valide a capacidade do servidor RADIUS em relação às taxas de pico de autenticação esperadas.
Resultados esperados: Latência de autenticação inferior a um milissegundo durante o pico de entrada do evento, conformidade total com a soberania de dados, registro de autenticação em conformidade com PCI DSS e disponibilidade de 99,99%+ por meio da arquitetura de cluster ativo-ativo.
Questões práticas
Q1. Uma rede nacional de farmácias opera 320 lojas em todo o Reino Unido. Cada loja possui uma única conexão de internet de um grande provedor (ISP) sem failover. A rede utiliza o Microsoft 365 e o Azure Active Directory para a identidade de toda a equipe. A equipe de TI, composta por 8 engenheiros, gerencia atualmente instâncias do FreeRADIUS em uma máquina virtual em cada loja. O CISO alertou que 23% das lojas têm certificados RADIUS que expirarão em 90 dias. O CTO deseja resolver isso e reduzir a sobrecarga de manutenção contínua. Qual arquitetura RADIUS você recomenda e qual é a mudança de infraestrutura mais crítica necessária antes da migração?
Dica: Considere o requisito de resiliência de WAN com cuidado — o que acontece com as operações na loja se a conexão de internet falhar após a implantação do Cloud RADIUS?
Ver resposta modelo
Arquitetura recomendada: Cloud RADIUS integrado ao Azure Active Directory, substituindo as 320 instâncias do FreeRADIUS. A integração com o Azure AD é simples devido à implantação existente do Microsoft 365, e o Cloud RADIUS elimina a crise de gerenciamento de certificados imediatamente por meio de rotação automatizada.
Mudança crítica de infraestrutura antes da migração: Resiliência de WAN. Cada loja possui atualmente uma única conexão de ISP sem failover. O Cloud RADIUS é totalmente dependente de conectividade de internet. Antes de migrar qualquer loja, implemente SD-WAN com failover de dual-ISP ou, no mínimo, configure o controlador wireless para fazer cache local das credenciais dos funcionários por 8 a 12 horas. Sem isso, uma loja que perder a conectividade de internet não conseguirá autenticar a equipe na rede corporativa — bloqueando potencialmente o acesso aos sistemas de ponto de venda, gerenciamento de estoque e outras operações dependentes da rede.
Sequência de migração: (1) Implantar SD-WAN ou cache de credenciais em todas as 320 lojas. (2) Migrar primeiro os 23% das lojas com expiração de certificado iminente — isso resolve o risco imediato. (3) Migrar as lojas restantes em lotes de 20 a 30 por semana. (4) Desativar as VMs FreeRADIUS pós-migração. Resultado esperado: zero incidentes de expiração de certificado, redução de 60 a 70% no tempo de engenharia relacionado ao RADIUS, gerenciamento de políticas centralizado em todas as 320 lojas.
Q2. Uma operadora de centro de convenções gerencia um único espaço principal com capacidade para 5.000 participantes. O local sedia 200 eventos por ano, variando de pequenas reuniões de diretoria a grandes conferências internacionais. O pico de usuários de WiFi simultâneos chega a 4.500 durante grandes eventos. O local possui uma conexão de internet dedicada de 1Gbps com SLA de 99,9%. A equipe de TI é composta por dois engenheiros de rede. Não há requisitos específicos de soberania de dados. O servidor FreeRADIUS on-premise atual está chegando ao fim de sua vida útil. Eles devem substituí-lo por uma nova implantação on-premise ou migrar para o Cloud RADIUS?
Dica: Considere o perfil de pico de carga e o tamanho da equipe. Ter 4.500 usuários simultâneos em um único local é um forte argumento para on-premise ou o tamanho da equipe e a sobrecarga de gerenciamento mudam a balança?
Ver resposta modelo
Arquitetura recomendada: Cloud RADIUS. Apesar do perfil de alta densidade em um único local, a combinação de uma equipe de TI pequena (2 engenheiros), a ausência de requisitos de soberania de dados e uma conexão de internet dedicada confiável torna o Cloud RADIUS a escolha mais robusta.
Justificativa: O pico de carga de 4.500 usuários simultâneos está bem dentro da capacidade de throughput das plataformas de Cloud RADIUS corporativas, que são projetadas para volumes muito maiores. A latência adicional de 5 a 20 ms do roteamento em nuvem é imperceptível em um ambiente de conferência. A conexão de internet dedicada de 1Gbps com SLA de 99,9% oferece confiabilidade de WAN suficiente para a dependência do Cloud RADIUS.
O fator decisivo é o tamanho da equipe. Dois engenheiros gerenciando a substituição de um FreeRADIUS on-premise — incluindo aquisição de hardware, hardening do SO, gerenciamento de certificados, configuração de EAP e manutenção contínua — representam uma sobrecarga contínua significativa para uma equipe pequena. O Cloud RADIUS reduz isso ao gerenciamento de políticas, liberando ambos os engenheiros para as necessidades mais amplas de infraestrutura de rede do local.
Nota de implementação: Configure o cache de credenciais no controlador wireless para o SSID da equipe de operações do local, proporcionando redundância durante qualquer breve interrupção de internet. Certifique-se de que o provedor de Cloud RADIUS possua um nó de borda no Reino Unido ou na Europa para minimizar a latência de autenticação no cenário de eventos de alta densidade.
Q3. Um consórcio regional do NHS opera 12 hospitais em uma região administrativa. Os requisitos de autenticação incluem: (1) acesso da equipe médica à rede clínica via 802.1X com EAP-TLS, (2) WiFi para visitantes/pacientes via Captive Portal, e (3) autenticação de dispositivos médicos via MAB (MAC Authentication Bypass). A equipe de governança de informações do consórcio determinou que todos os dados relacionados a pacientes, incluindo logs de autenticação, devem permanecer em data centers aprovados pelo NHS na Inglaterra. O consórcio utiliza Active Directory on-premise sem planos atuais de migração para o Azure AD. Qual arquitetura você recomenda?
Dica: Este cenário possui múltiplos limites rígidos. Identifique cada um e determine se eles eliminam o Cloud RADIUS completamente ou apenas parcialmente.
Ver resposta modelo
Arquitetura recomendada: Híbrida — RADIUS on-premise para autenticação da equipe clínica e de dispositivos médicos; Cloud RADIUS (compatível com o NHS) ou on-premise para WiFi de visitantes/pacientes.
Análise das restrições:
- Soberania de dados (data centers ingleses aprovados pelo NHS): Isso elimina a maioria dos provedores comerciais de Cloud RADIUS, a menos que ofereçam residência de dados compatível com o NHS. Alguns provedores oferecem implantações específicas para o NHS; estes devem ser avaliados. Se não houver opção de nuvem compatível, o on-premise é obrigatório para todas as autenticações.
- Active Directory on-premise sem sincronização na nuvem: Esta é uma restrição rígida para a integração com Cloud RADIUS. Sem o Azure AD Connect ou equivalente, o Cloud RADIUS não pode consultar o diretório de funcionários do consórcio. O RADIUS on-premise é necessário para a autenticação da equipe.
- EAP-TLS para equipe clínica: Suportado tanto pelo FreeRADIUS on-premise quanto pelo NPS. Requer uma PKI interna (Microsoft ADCS recomendado para um ambiente integrado ao AD).
Implantação recomendada: Implante RADIUS on-premise (NPS ou FreeRADIUS) em cada um dos 12 hospitais em pares ativo-passivo, integrados ao Active Directory on-premise do consórcio. Use VLANs atribuídas por RADIUS para segmentar o tráfego clínico, administrativo e de dispositivos médicos. Para o WiFi de visitantes/pacientes, implante o Captive Portal da Purple para captura de dados e gerenciamento de consentimento em conformidade com a GDPR — isso não requer RADIUS para autenticação de visitantes e contorna completamente a restrição de soberania de dados para a rede de visitantes. As políticas de MAB para dispositivos médicos são gerenciadas no servidor RADIUS on-premise com listas de endereços MAC mantidas centralmente por meio de uma ferramenta de gerenciamento de configuração.
Risco principal a mitigar: Gerenciamento de certificados para EAP-TLS em 12 locais. Implante o Microsoft ADCS com registro automatizado de certificados via Diretiva de Grupo (Group Policy) para garantir que todos os dispositivos clínicos recebam e renovem os certificados automaticamente.
Continue a ler esta série
Per-Device PSK por Vendor: Comparativo de iPSK, DPSK, MPSK e PPSK (e Suporte a WPA3)
Uma comparação abrangente das implementações de PSK por dispositivo no Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet e Ubiquiti UniFi. Saiba como o WPA3-SAE impacta as estratégias de chaves por dispositivo e quando implantar modos de transição em vez de migrar para o 802.1X.
Métodos de Autenticação de Captive Portal Comparados
Este guia de referência técnica definitivo avalia as compensações arquitetônicas, operacionais e de conformidade de cinco métodos principais de autenticação de captive portal. Ele fornece a arquitetos de rede, diretores de TI e gerentes de marketing os dados quantitativos e as estruturas de decisão necessários para equilibrar a fricção no onboarding de convidados com os requisitos de coleta de dados em locais corporativos.
O que é autenticação por endereço MAC? Quando usar e quando evitar
Este guia de referência técnica abrangente aborda a autenticação por endereço MAC em ambientes de WiFi corporativos — como a autenticação MAC baseada em RADIUS funciona na Camada 2, suas vulnerabilidades de segurança inerentes (incluindo spoofing de MAC e o impacto da randomização de MAC no nível do SO) e os contextos operacionais precisos onde ela continua sendo uma ferramenta válida para gerenciar IoT e dispositivos headless. Ele fornece orientações de implantação práticas para gerentes de TI e arquitetos de rede em setores como hotelaria, varejo, saúde e locais públicos, com exemplos práticos reais, estruturas de decisão e contexto de integração para a plataforma de guest WiFi e analytics da Purple.