RADIUS Accounting: Rastreio de Sessões, Utilização e Logs de Auditoria

Este guia fornece uma referência técnica abrangente sobre RADIUS accounting — como este regista os dados de início, fim e atualizações provisórias de sessões WiFi, quais os atributos capturados e como potenciar esses dados para auditoria de segurança, conformidade com o GDPR e planeamento de capacidade. É uma leitura essencial para equipas de operações de rede e de segurança que necessitam de registos de auditoria defensáveis a partir de eventos de autenticação WiFi, e para operadores de espaços que procuram integrar dados de sessão em plataformas SIEM e painéis de análise.

📖 9 min de leitura📝 2,044 palavras🔧 2 exemplos práticos❓ 3 perguntas de prática📚 9 definições principais

Ouça este guia

Ver transcrição do podcast

Bem-vindo de volta ao Purple Technical Briefing. Eu sou o seu anfitrião e hoje vamos mergulhar num componente crítico, mas muitas vezes incompreendido, da infraestrutura de WiFi empresarial: o RADIUS Accounting. Especificamente, como rastreamos sessões, monitorizamos a utilização e criamos registos de auditoria robustos. Se é um gestor de TI, um arquiteto de rede ou um diretor de operações de espaços, isto é para si. Vamos saltar a teoria académica e ir direto à aplicação prática.

Comecemos pelos aspetos fundamentais. Para o CTO que precisa de uma apresentação rápida de 60 segundos: o que é o RADIUS accounting e em que é que difere da autenticação RADIUS?

De forma simples, a autenticação é o segurança à porta a verificar a sua identidade. O Accounting é o barman que regista quanto tempo permanece e quanto consome. A autenticação utiliza a porta UDP 1812 e trata de quem e como acede à rede. O Accounting utiliza a porta UDP 1813 e regista meticulosamente o quê, quando e quanto. Monitoriza quando uma sessão começa, quando termina, quantos bytes foram transferidos e que endereço IP foi atribuído ao dispositivo do cliente.

Portanto, é a pista de auditoria. Mas como é que captura exatamente estes dados? Qual é o mecanismo?

Baseia-se em três tipos principais de pacotes enviados pelo Network Access Server — normalmente o seu Access Point ou Controlador Sem Fios — para o servidor RADIUS. Estes são chamados pacotes Accounting-Request. Primeiro, temos o pacote Start. Este é enviado no momento em que um utilizador se liga com sucesso. Estabelece o registo de base na base de dados de accounting, capturando a identidade do utilizador, o endereço MAC do dispositivo, o endereço IP atribuído e o AP ao qual o utilizador se ligou. Depois, temos o pacote Stop, enviado quando o utilizador se desliga, contendo as estatísticas cumulativas finais de toda a sessão.

Isso parece simples. Start e Stop. Trabalho concluído.

Não propriamente. Depender apenas de pacotes Start e Stop é um risco operacional significativo. Considere o seguinte: o que acontece se um hóspede se ligar num hotel e permanecer ligado durante três dias? Se depender apenas do Start e do Stop, terá zero visibilidade sobre a sua utilização durante esses três dias. Ou pior, e se o Access Point perder energia? Nunca envia o pacote Stop, e fica com uma sessão obsoleta na sua base de dados que parece continuar ativa indefinidamente.

Então, qual é a solução?

O terceiro tipo de pacote: o Interim-Update. Este é crítico e é o elemento configurado incorretamente com mais frequência em implementações de RADIUS accounting. Configura-se o Controlador Sem Fios para enviar uma atualização, por exemplo, a cada 15 minutos durante uma sessão ativa. Funciona como um batimento cardíaco e fornece um instantâneo contínuo da utilização atual — bytes transferidos, duração da sessão e contagem de pacotes. Se o servidor RADIUS deixar de receber atualizações provisórias de uma sessão específica, saberá que a sessão terminou, mesmo que nunca tenha recebido um pacote Stop. A regra de ouro aqui é simples: Sem Interim, Sem Insight.

Agora vamos falar sobre os dados em si. Que atributos específicos estamos a analisar nestes pacotes que são tão valiosos para registos de auditoria e relatórios de conformidade?

Existem vários que são fundamentais. O Acct-Session-Id é a chave primária que une os pacotes Start, Interim-Update e Stop num registo de sessão coerente. Sem isto, não é possível correlacionar os três tipos de pacotes. Depois temos o Calling-Station-Id, que é tipicamente o endereço MAC do cliente — o identificador de hardware do dispositivo. O Framed-IP-Address é o endereço IP atribuído ao cliente para essa sessão. O Acct-Input-Octets e o Acct-Output-Octets monitorizam o volume de dados recebidos e enviados para o cliente. E o Acct-Terminate-Cause, incluído nos pacotes Stop, indica por que razão a sessão terminou — se o utilizador se desligou manualmente, se atingiu um limite de tempo por inatividade ou se a ligação foi perdida.

Como é que utilizamos esses atributos num cenário do mundo real? Vamos analisar a conformidade com o GDPR ou um pedido de interceção legal.

É precisamente aqui que a monitorização de acessos RADIUS (RADIUS accounting) prova o seu retorno sobre o investimento. Imaginemos que as autoridades abordam uma cadeia de retalho e dizem: um endereço IP no vosso WiFi de convidados foi utilizado para aceder a conteúdos maliciosos na passada terça-feira às 14:00. Quem foi? Se apenas tiver registos de firewall, tem apenas um endereço IP. Mas os endereços IP mudam constantemente com o DHCP. Precisa de associar esse IP a um dispositivo específico num momento específico no tempo. Assim, consulta a sua base de dados de RADIUS accounting. Procura uma sessão onde o Framed-IP-Address corresponda ao IP do registo de firewall e onde o carimbo de data/hora do incidente se situe entre a hora de Start e a hora de Stop da sessão. Esse registo dar-lhe-á o Calling-Station-Id — o endereço MAC do dispositivo. Acabou de associar a camada de rede à camada de dispositivo. Esse é o seu registo de auditoria completo.

Vejamos outro cenário: um grande hotel. O setor da hotelaria está particularmente exposto aqui. Um hotel de 300 quartos com instalações para conferências pode ter milhares de sessões WiFi simultâneas. A equipa de operações precisa de compreender os períodos de pico de utilização para o planeamento de capacidade, enquanto a equipa de conformidade precisa de demonstrar que os dados dos hóspedes são tratados de forma adequada ao abrigo do GDPR.

Neste ambiente, o RADIUS accounting fornece ambos. Os dados de sessão alimentam uma plataforma de analítica de WiFi, que traduz bytes em bruto e durações de sessão em métricas de afluência e tendências de consumo de largura de banda. Em simultâneo, os mesmos dados alimentam um módulo de relatórios de conformidade que pode demonstrar aos auditores exatamente quais os dados que foram recolhidos, durante quanto tempo foram retidos e como foram protegidos.

Por isso, para que tudo isto aconteça, precisamos de extrair estes dados do servidor RADIUS e colocá-los em sistemas onde possamos consultá-los e agir com base neles. Como é que as equipas devem estruturar o design desse fluxo de dados?A primeira regra é: não deixe os registos em ficheiros de texto simples no servidor RADIUS. Configure o servidor para escrever dados de contabilidade numa base de dados relacional estruturada — PostgreSQL ou MySQL são escolhas comuns. A partir daí, tem duas vias principais de consumo. Primeiro, encaminhe os registos para o seu SIEM — Splunk, Microsoft Sentinel ou IBM QRadar — usando Syslog ou uma REST API. Isto permite que a sua equipa de segurança correlacione eventos de autenticação WiFi com bloqueios de firewall, alertas de deteção de intrusão ou gatilhos de prevenção de perda de dados. Segundo, envie os dados para a sua plataforma de análise. O WiFi Analytics da Purple, por exemplo, pode ingerir estes dados de sessão e transformá-los em informações práticas sobre o fluxo de visitantes, tempo de permanência e utilização de capacidade.

Agora vamos falar sobre as armadilhas comuns. Onde é que as implementações correm mal?

Dois modos principais de falha. Primeiro, como discutimos, falhar por completo a ativação de Interim-Updates. Isto é surpreendentemente comum. Os administradores configuram a autenticação corretamente, mas nunca tocam nas definições de contabilidade. Segundo, e isto é igualmente prejudicial, definir o intervalo de Interim-Update de forma demasiado agressiva. Se tiver 10.000 utilizadores simultâneos e definir o intervalo para 1 minuto, estará a gerar 10.000 operações de escrita na base de dados por minuto apenas para atualizações de contabilidade. Isso irá saturar a capacidade de I/O do seu servidor RADIUS muito rapidamente. O ponto ideal para a maioria das implementações empresariais é de 10 a 15 minutos. Oferece uma granularidade suficiente para visibilidade operacional sem criar uma carga de escrita insustentável.

Vamos passar por um conjunto rápido de cenários.

Cenário um: Um gestor de espaço reporta que o painel de análise mostra utilizadores ligados durante 48 horas, mas o espaço está fechado durante a noite.

Isso é um problema de sessão desatualizada. Os Access Points não estão a enviar pacotes Stop — provavelmente devido a um ciclo de energia ou interrupção de rede — e as sessões nunca estão a ser fechadas na base de dados. A solução é implementar um script de limpeza de sessões inativas no servidor RADIUS. Qualquer sessão que não tenha recebido uma atualização provisória num período correspondente a duas a três vezes o intervalo configurado deve ser fechada automaticamente.

Cenário dois: A equipa de segurança de uma cadeia de retalho afirma que os registos de firewall apenas mostram endereços IP, tornando impossível auditar qual o terminal de ponto de venda específico que acedeu a um IP externo suspeito.

Garantir que os Access Points estão configurados para incluir o atributo Framed-IP-Address nos pacotes de contabilidade RADIUS, e integrar essa base de dados de contabilidade RADIUS com o SIEM para correlacionar o endereço IP com o endereço MAC.

Cenário três: O servidor RADIUS está a registar uma elevada carga de CPU durante as horas de pico, causando atrasos na autenticação.

Verifique primeiro o intervalo de atualização provisório (interim update interval). Se estiver definido para 1 ou 2 minutos em toda a infraestrutura, aumente para 15 minutos. Verifique também se a base de dados de accounting possui índices apropriados nas colunas Acct-Session-Id e User-Name. Tabelas sem índices causarão varrimentos completos da tabela (full table scans) em cada escrita, o que é catastrófico à escala. E considere separar as cargas de trabalho de autenticação e accounting em instâncias de servidor dedicadas.

Para concluir, aqui estão as principais conclusões para qualquer gestor de TI ou arquiteto de rede que esteja a implementar ou a auditar a sua infraestrutura de RADIUS accounting.

Primeiro: O RADIUS accounting é diferente da autenticação. Monitoriza dados de sessão, não decisões de acesso. Ambos são essenciais, mas servem objetivos operacionais e de conformidade diferentes.

Segundo: Ative sempre os Interim-Updates. Sem eles, não terá visibilidade sobre as sessões ativas e nenhum mecanismo para detetar registos obsoletos.

Terceiro: Os três atributos que deve sempre capturar são Acct-Session-Id, Framed-IP-Address e Calling-Station-Id. Estes três formam a base de qualquer registo de auditoria significativo.

Quarto: Exporte os seus dados de accounting. Não os deixe em ficheiros planos. Escreva numa base de dados estruturada, reencaminhe para um SIEM e alimente uma plataforma de análise.

Quinto: Desenhe a pensar na escala. Um intervalo de atualização provisório de 15 minutos é o equilíbrio certo para a maioria das implementações empresariais. Ajuste com base nos seus requisitos de conformidade específicos e na capacidade da infraestrutura.

O ponto crucial é este: O RADIUS accounting não é um extra opcional. Em qualquer ambiente regulado — hotelaria, retalho, saúde, setor público — é a base do seu registo de auditoria de WiFi. Se o fizer bem, terá uma ferramenta poderosa para segurança, conformidade e inteligência operacional. Se o fizer mal, terá uma lacuna no seu registo de auditoria que poderá custar muito caro.

Obrigado por ouvir o Purple Technical Briefing. Até à próxima.

Principais Conclusões

✓A contabilidade RADIUS (RFC 2866) é distinta da autenticação: regista dados de utilização da sessão — duração, bytes transferidos, atribuição de IP — em vez de tomar decisões de controlo de acesso.
✓Os três tipos de pacotes — Start, Interim-Update e Stop — devem estar todos configurados e operacionais para um registo de auditoria completo. Os Interim-Updates são a configuração que mais frequentemente é esquecida.
✓Os atributos Acct-Session-Id, Framed-IP-Address e Calling-Station-Id formam o registo de auditoria mínimo viável, permitindo a correlação de IP para dispositivo para investigações de segurança e conformidade.
✓As sessões inactivas (causadas pela falta de pacotes Stop) devem ser geridas com um script de limpeza de sessões mortas usando a regra do intervalo de atualização provisório de 2.5x.
✓Os dados de contabilidade RADIUS devem ser exportados para uma base de dados estruturada e integrados com um SIEM e plataforma de analítica para fornecer o seu total valor operacional e de conformidade.
✓Para a conformidade com PCI DSS, GDPR e interceção legal, a capacidade de associar um endereço IP a um endereço MAC num ponto específico no tempo é o requisito central que a contabilidade RADIUS cumpre.
✓À escala (mais de 5.000 utilizadores simultâneos), separe as instâncias do servidor de autenticação e de contabilidade e considere uma base de dados de séries temporais para as escritas de contabilidade para evitar a degradação do desempenho.

Resumo Executivo

Para as equipas de TI e operações de rede empresariais, autenticar utilizadores numa rede WiFi é apenas metade da batalha. Assim que um dispositivo se liga, compreender o que esse dispositivo faz — quanto tempo permanece ligado, quantos dados consome e quando se desliga — é crítico para a segurança, planeamento de capacidade e conformidade regulamentar. É aqui que a contabilidade RADIUS se torna indispensável. Enquanto a autenticação RADIUS lida com o quem e como do acesso à rede, a contabilidade RADIUS regista meticulosamente o quê, quando e quanto.

Este guia fornece uma análise técnica aprofundada sobre a contabilidade RADIUS, explorando os mecanismos dos pacotes Start, Stop e Interim-Update, bem como os atributos que os tornam valiosos. Descreve como os operadores de espaços em Hotelaria , Retalho e outros setores podem tirar partido destes dados para manter registos de auditoria robustos, garantir a conformidade com o GDPR e fornecer inteligência acionável a plataformas SIEM ou sistemas de WiFi Analytics . Ao dominar a contabilidade RADIUS, os arquitetos de rede podem transformar registos de sessão brutos em ativos estratégicos que impulsionam a eficiência operacional e mitigam riscos.

Análise Técnica Aprofundada

Contabilidade RADIUS vs. Autenticação RADIUS

O RADIUS (Remote Authentication Dial-In User Service), definido no RFC 2865 e estendido para contabilidade no RFC 2866 , opera num modelo cliente-servidor. Numa implementação típica de WiFi empresarial, o Ponto de Acesso (AP) ou o Controlador de LAN Sem Fios (WLC) atua como o Network Access Server (NAS) — o cliente RADIUS. O servidor RADIUS (ex. FreeRADIUS, Cisco ISE, Aruba ClearPass) recebe e processa os pedidos.

A distinção entre autenticação e contabilidade é fundamental:

Dimensão	Autenticação RADIUS	Contabilidade RADIUS
Objetivo	Verificar identidade e conceder/recusar acesso	Registar a utilização e atividade da sessão
Porta UDP	1812	1813
Referência RFC	RFC 2865	RFC 2866
Tipos de Pacote	Access-Request, Access-Accept, Access-Reject	Accounting-Request (Start/Stop/Interim)
Dados Capturados	Credenciais, atribuição de VLAN, política	Tempo de sessão, bytes transferidos, endereço IP
Função de Conformidade	Controlo de acesso	Registo de auditoria, interceção legal

Para equipas que implementam Guest WiFi em grande escala, ambas as funções são necessárias — mas a contabilidade é a que o mantém em conformidade e defensável.

Os Três Tipos de Pacotes de Contabilidade

A contabilidade RADIUS depende de três tipos principais de pacotes Accounting-Request, cada um definido pelo atributo Acct-Status-Type:

Start (Acct-Status-Type = 1): Enviado pelo NAS quando um utilizador se liga com sucesso e uma sessão é iniciada. Estabelece o registo de base na base de dados de accounting, capturando a identidade do utilizador, o endereço MAC do dispositivo, o endereço IP atribuído e o AP ao qual o utilizador se ligou.
Interim-Update (Acct-Status-Type = 3): Enviado periodicamente durante uma sessão ativa. Estes pacotes fornecem instantâneos contínuos da utilização atual — bytes transferidos, duração da sessão e contagem de pacotes. Funcionam como um batimento cardíaco (heartbeat) para confirmar que a sessão ainda está ativa e fornecem visibilidade sobre sessões de longa duração sem ter de esperar pela desativação.
Stop (Acct-Status-Type = 2): Enviado quando a sessão termina — seja devido a uma desativação iniciada pelo utilizador, reinicialização do AP, tempo limite de inatividade (idle timeout) ou tempo limite de sessão. Contém as estatísticas finais acumuladas de toda a sessão.

Figura 1: O ciclo de vida do pacote de accounting RADIUS ao longo de uma sessão WiFi.

Atributos Chave de Accounting

Para monitorizar eficazmente as sessões e criar registos de auditoria defensáveis, o NAS preenche os pacotes Accounting-Request com atributos específicos. Os seguintes são os mais significativos do ponto de vista operacional:

Atributo	Descrição	Relevância de Conformidade
Acct-Session-Id	Identificador único de sessão gerado pelo NAS	Chave primária para correlacionar registos de Start, Interim e Stop
User-Name	Identidade autenticada (nome de utilizador ou endereço MAC)	Mapeia a sessão para um utilizador ou dispositivo específico
NAS-IP-Address	Endereço IP do AP ou WLC reportador	Identifica o segmento de rede e a localização física
Framed-IP-Address	Endereço IP atribuído ao dispositivo cliente	Crítico para correlação com logs de firewall e proxy web
Calling-Station-Id	Endereço MAC do dispositivo cliente	Identidade ao nível da camada de dispositivo para rasto de auditoria
Called-Station-Id	Endereço MAC do AP e SSID	Identifica o rádio e a rede específicos aos quais o utilizador se ligou
Acct-Input-Octets	Bytes recebidos do cliente	Monitorização de largura de banda e planeamento de capacidade
Acct-Output-Octets	Bytes enviados para o cliente	Monitorização de largura de banda e planeamento de capacidade
Acct-Session-Time	Duração da sessão em segundos	Análise de tempo de permanência e faturação
Acct-Terminate-Cause	Razão pela qual a sessão terminou	Resolução de problemas e deteção de anomalias

Para as equipas que trabalham com Autenticação 802.1X , o atributo User-Name conterá a identidade autenticada da troca EAP, fornecendo um rasto de auditoria mais rico do que o MAC Authentication Bypass (MAB) sozinho.

Guia de Implementação

Implementar uma infraestrutura robusta de accounting RADIUS exige uma configuração cuidadosa, tanto ao nível do NAS como do servidor RADIUS. Segue-se uma abordagem neutra em termos de fabricante para estabelecer um fluxo de accounting fiável.

Passo 1: Configurar o NAS (Access Points / Controladores)

A configuração do NAS é onde a maioria das implementações falha. Os administradores configuram frequentemente a autenticação de forma correta, mas deixam o accounting nas definições predefinidas ou totalmente desativado.

Definir o Servidor de Accounting: Especifique o endereço IP do servidor RADIUS e o segredo partilhado para a porta UDP 1813. Em implementações de elevada disponibilidade, configure um servidor de accounting secundário para evitar a perda de dados caso o principal fique inacessível.
Ativar Interim Updates: Este é o passo de configuração mais importante de todos. Defina um intervalo adequado — normalmente entre 10 a 15 minutos para implementações empresariais. Intervalos mais curtos (por exemplo, 1 minuto) fornecem dados mais detalhados, mas geram uma carga de escrita insustentável em grande escala; intervalos mais longos (por exemplo, 30 minutos) reduzem a sobrecarga, mas atrasam a visibilidade sobre as sessões ativas.
Garantir a Sincronização Temporal: Configure o NTP em todos os dispositivos NAS e no servidor RADIUS. Carimbos de data/hora precisos são inegociáveis para registos de auditoria e correlação em SIEM. Um desvio de relógio de 5 minutos pode invalidar uma pista de auditoria num cenário de interceção legal.

Passo 2: Configurar o Servidor RADIUS

Integração de Base de Dados: Configure o servidor RADIUS para registar os dados de accounting numa base de dados relacional estruturada (por exemplo, PostgreSQL, MySQL) em vez de ficheiros de texto simples. O armazenamento estruturado permite consultas eficientes, indexação e integração com sistemas a jusante. Garanta a existência de índices em Acct-Session-Id, User-Name, Framed-IP-Address e no carimbo de data/hora de início de sessão.
Políticas de Retenção de Dados: Implemente scripts automatizados de arquivo ou eliminação alinhados com os seus requisitos de conformidade. O Artigo 5.º, n.º 1, alínea e), do GDPR exige que os dados sejam mantidos apenas pelo tempo necessário; contudo, os regulamentos de interceção legal em muitas jurisdições (por exemplo, o Investigatory Powers Act 2016 do Reino Unido) podem exigir a retenção por um período de até 12 meses.

Passo 3: Construir o Fluxo de Dados

Para maximizar o valor dos dados de accounting, estes devem ser exportados para plataformas de consumo onde possam ser consultados, correlacionados e visualizados.

Integração com SIEM: Configure o servidor RADIUS ou a base de dados subjacente para reencaminhar os registos para o seu SIEM (por exemplo, Splunk, Microsoft Sentinel, IBM QRadar) utilizando Syslog ou uma API REST. Isto permite que as equipas de segurança correlacionem eventos de autenticação de WiFi com bloqueios de firewall, alertas de deteção de intrusões ou acionadores de prevenção de perda de dados.- Integração de Analytics: Insira dados de sessão em plataformas como o WiFi Analytics da Purple para transformar bytes brutos e endereços MAC em informações acionáveis sobre fluxo de pessoas, tempo de permanência e períodos de pico de utilização. Isto é particularmente valioso para operadores de Retalho e Hotelaria que precisam de alinhar a contratação de pessoal e o investimento em infraestrutura com os padrões de utilização reais.

Figura 2: O pipeline de dados de accounting RADIUS desde os Pontos de Acesso até às plataformas de SIEM e analytics.

Melhores Práticas

Utilize Sempre Interim Updates. Confiar apenas em pacotes Start e Stop cria lacunas operacionais. Uma ligação caída ou uma falha de energia no AP pode impedir o envio de um pacote Stop, deixando uma sessão obsoleta na base de dados indefinidamente. Os interim updates fornecem o mecanismo para detetar e encerrar estas sessões obsoletas. A regra de ouro: se uma sessão não tiver enviado um interim update num intervalo de duas a três vezes o período configurado, trate-a como terminada.

Correlacione o Accounting RADIUS com os Logs de DHCP. O accounting RADIUS fornece o Framed-IP-Address, mas os tempos de concessão de DHCP podem ser mais curtos do que a duração das sessões em alguns ambientes. Manter os logs de DHCP juntamente com os logs RADIUS oferece um registo de auditoria mais resiliente, particularmente em locais de alta densidade onde a reciclagem de endereços IP é frequente.

Proteja o Transporte com RadSec. O tráfego RADIUS tradicional é transmitido sobre UDP com encriptação mínima — apenas o campo da palavra-passe do utilizador é ofuscado. Em implementações distribuídas, particularmente as que abrangem múltiplos locais ou servidores RADIUS alojados na nuvem, utilize RadSec (RADIUS sobre TLS, definido no RFC 6614) ou túneis IPsec para proteger os dados de accounting em trânsito. Este é um requisito ao abrigo da norma PCI DSS 4.0 para qualquer rede que processe dados de titulares de cartões.

Monitorize a Fila de Accounting. Se o servidor RADIUS ficar inacessível, os dispositivos NAS colocarão os pacotes de accounting numa fila local. Monitorize o comprimento desta fila; uma fila cheia resultará em pacotes perdidos e na perda de dados de auditoria. Configure alertas sobre a profundidade da fila e implemente um servidor de accounting secundário para implementações de alta disponibilidade.

Separe os Servidores de Autenticação e de Accounting em Escala. Em implementações que excedam os 5.000 utilizadores concorrentes, a carga de escrita proveniente do accounting pode degradar os tempos de resposta da autenticação. Servidores de accounting dedicados com instâncias de base de dados separadas evitam esta contenção.

Resolução de Problemas e Mitigação de Riscos

O Problema da Sessão Obsoleta

Sintoma: A base de dados RADIUS mostra que um utilizador esteve ligado durante 48 horas, mas o local fechou durante a noite.

Causa Raiz: O NAS falhou o envio de um pacote Stop — normalmente devido a uma falha de energia, reinicialização do AP ou interrupção de rede — e o pacote nunca foi recebido pelo servidor RADIUS.

Mitigação: Implemente um script de limpeza de sessões mortas no servidor RADIUS. O script deve analisar periodicamente as sessões ativas onde o último pacote recebido (Start ou Interim-Update) é mais antigo do que um limiar definido (por exemplo, 2,5x o intervalo de atualização provisória). As sessões que excedam este limiar devem ser terminadas à força com um registo Stop sintético, registando a causa de terminação como 'Lost-Carrier' ou 'Admin-Reset'.

Alta Carga de CPU e I/O no Servidor RADIUS

Sintoma: Os tempos de resposta de autenticação degradam-se durante as horas de pico; o servidor RADIUS reporta uma elevada utilização de CPU e I/O de disco.

Causa Raiz: Um intervalo de atualização provisória excessivamente agressivo (por exemplo, 1 minuto) em milhares de APs gera um volume insustentável de gravações na base de dados.

Mitigação: Aumente o intervalo de atualização provisória para 15 minutos. Verifique se a base de dados de accounting possui os índices adequados. Considere separar a autenticação e o accounting em instâncias de servidor dedicadas. Avalie se uma base de dados de séries temporais (por exemplo, InfluxDB) é mais adequada do que uma base de dados relacional para dados de accounting de alto volume.

Falha de Framed-IP-Address nos Registos de Accounting

Sintoma: Existem registos de accounting RADIUS, mas o campo Framed-IP-Address está vazio ou ausente, impossibilitando a correlação de IP para MAC.

Causa Raiz: O NAS pode estar a enviar o pacote Start antes de o DHCP ter atribuído um endereço IP ao cliente. O IP só fica disponível após a conclusão da troca de mensagens DHCP.

Mitigação: Configure o NAS para atrasar o envio do pacote Start até após a atribuição do DHCP, caso a plataforma o suporte. Alternativamente, dependa dos pacotes Interim-Update, que são enviados após a atribuição do DHCP e conterão o Framed-IP-Address. Garanta que as suas consultas de auditoria contabilizam isto, verificando os registos Interim-Update se o registo Start carecer de um IP.

ROI e Impacto no Negócio

A implementação de um accounting RADIUS robusto proporciona um valor de negócio mensurável em três dimensões:

Mitigação de Riscos de Conformidade e Legais. Em caso de incidente de segurança, de um pedido de acesso a dados pelo titular ao abrigo do GDPR, ou de uma ordem de interceção legal, os registos de accounting precisos fornecem a pista de auditoria necessária para identificar qual o utilizador ou dispositivo que detinha um endereço IP específico num momento específico. Sem isto, as organizações enfrentam potenciais sanções regulatórias ao abrigo do GDPR (até 4% do volume de negócios anual global) e danos na reputação. O custo de implementar uma infraestrutura de accounting adequada é uma fração do custo de uma única ação de aplicação regulatória.

Planeamento de Capacidade e ROI de Infraestrutura. Ao analisar as tendências de Acct-Input-Octets e Acct-Output-Octets ao longo do tempo, os arquitetos de rede podem identificar padrões de consumo de largura de banda, períodos de pico de utilização e os APs ou SSIDs específicos que geram a maior carga. Estes dados informam diretamente as decisões de atualização de WAN e as estratégias de colocação de APs, garantindo que o investimento em infraestrutura seja direcionado para onde oferece o maior impacto. Para hubs de Transporte e grandes espaços, isto pode representar poupanças significativas de despesas de capital.

Analytics Avançado e Inteligência de Espaços. Quando os dados de sessão RADIUS são combinados com plataformas como o WiFi Analytics e Sensors da Purple, os dados brutos de faturação são transformados em inteligência de espaços. Ficam disponíveis métricas de tempo de permanência derivadas da duração da sessão, identificação de visitantes frequentes a partir do histórico de Calling-Station-Id e análise de pico de ocupação a partir do número de sessões simultâneas. Para operadores de Hotelaria , estes dados informam diretamente os modelos de pessoal, a colocação de F&B e as estratégias de personalização de marketing. Para mais contexto sobre como a infraestrutura de WiFi apoia estas capacidades, consulte os nossos guias sobre Wireless Access Points e Soluções Modernas de WiFi para Hotelaria .

Definições Principais

RADIUS Accounting

O processo de recolha e registo de dados sobre o consumo de recursos de rede por parte do utilizador, incluindo as horas de início e fim da sessão, o volume de dados transferido e a atribuição do endereço IP. Definido no RFC 2866.

Essencial para faturação, planeamento de capacidade, conformidade com o GDPR e manutenção de registos de auditoria de segurança em qualquer implementação de WiFi empresarial.

Acct-Status-Type

Um atributo RADIUS (ID de Atributo 40) que indica o objetivo de um pacote de accounting. Os valores incluem Start (1), Stop (2) e Interim-Update (3).

Utilizado pelo servidor RADIUS para determinar se deve criar um novo registo de sessão, atualizar um registo existente ou fechá-lo. O atributo mais fundamental em qualquer pacote de accounting.

Interim-Update

Um pacote de RADIUS accounting periódico enviado pelo NAS durante uma sessão ativa para reportar estatísticas de utilização atuais, incluindo os bytes transferidos e a duração da sessão.

Crítico para monitorizar sessões de longa duração e detetar sessões obsoletas caso um cliente se desligue inesperadamente sem enviar um pacote Stop.

Acct-Session-Id

Uma string única gerada pelo NAS para identificar uma instância específica de ligação do utilizador. Este valor é consistente em todos os pacotes de accounting (Start, Interim-Update, Stop) para a mesma sessão.

A chave primária utilizada para correlacionar todos os registos de accounting pertencentes à mesma sessão. Sem esta, é impossível reconstruir um histórico de sessão completo.

NAS (Network Access Server)

O dispositivo — tipicamente um Wireless Access Point ou Wireless LAN Controller — que controla o acesso físico à rede e atua como o cliente RADIUS, gerando e enviando pacotes de accounting.

O NAS é responsável pela precisão e integridade dos dados de accounting. Erros de configuração ao nível do NAS (por exemplo, accounting desativado, atributos em falta) não podem ser corrigidos ao nível do servidor RADIUS.

Framed-IP-Address

O endereço IP atribuído ao dispositivo do cliente durante a sessão, incluído nos pacotes de RADIUS accounting.

Crítico para correlacionar registos de RADIUS accounting com outros registos de rede, tais como registos de firewall, proxy web ou DNS. A ausência deste atributo torna impossível a correlação entre o IP e o dispositivo.

Calling-Station-Id

Tipicamente o endereço MAC do dispositivo do cliente que se liga à rede, formatado como uma string hexadecimal separada por dois pontos (por exemplo, AA:BB:CC:DD:EE:FF).

Utilizado para identificar o dispositivo de hardware específico, independentemente do endereço IP que lhe é atribuído. A âncora ao nível do dispositivo para o registo de auditoria.

Acct-Terminate-Cause

Um atributo incluído nos pacotes Stop que especifica a razão pela qual uma sessão terminou. Os valores comuns incluem User-Request, Lost-Carrier, Idle-Timeout, Session-Timeout e Admin-Reset.

Valioso para a resolução de problemas de conectividade e para a deteção de anomalias — por exemplo, uma taxa elevada de terminações Lost-Carrier num AP específico pode indicar um problema de hardware ou de interferência.

RadSec

RADIUS sobre TLS (Transport Layer Security), definido no RFC 6614. Fornece transporte encriptado e autenticado para pacotes RADIUS, substituindo o tradicional transporte baseado em UDP.

Necessário em qualquer implementação onde o tráfego RADIUS atravesse redes não confiáveis (por exemplo, servidores RADIUS na nuvem ligados à Internet). Cada vez mais exigido pelo PCI DSS 4.0 para ambientes de dados de titulares de cartões.

Exemplos Práticos

Um hotel de 300 quartos com instalações para conferências está a implementar uma nova rede WiFi para hóspedes. O gestor de TI precisa de garantir que a implementação cumpre os requisitos do GDPR relativos à minimização de dados e integridade do registo de auditoria, fornecendo também à equipa de marketing análises de tempo de permanência e visitantes repetidos. O hotel utiliza um servidor RADIUS alojado na nuvem e APs Cisco Meraki.

A implementação deve ser configurada da seguinte forma. No painel da Meraki, navegue até Network-wide > RADIUS servers e adicione o servidor RADIUS de nuvem na porta 1813 com um segredo partilhado forte. Ative o accounting e defina o intervalo de atualização provisório (interim update) para 15 minutos. No servidor RADIUS, configure o accounting para escrever numa base de dados PostgreSQL com o seguinte esquema: session_id (chave primária), user_name, nas_ip, framed_ip, calling_station_id, called_station_id, session_start, session_end, input_octets, output_octets, terminate_cause. Implemente uma política de retenção de dados que arquive automaticamente registos com mais de 12 meses em armazenamento frio (cold storage) e elimine registos com mais de 24 meses, documentada no Registo de Atividades de Tratamento sob o GDPR do hotel. Configure uma integração com o Purple WiFi Analytics para ingerir os dados de sessão, permitindo que a equipa de marketing aceda a relatórios de tempo de permanência e painéis de frequência de visitantes repetidos. Garanta que o NTP está sincronizado em todos os APs Meraki e no servidor RADIUS com uma diferença máxima de 1 segundo.

Comentário do Examinador: Este cenário demonstra a dupla finalidade do accounting RADIUS: conformidade e análise. O intervalo de atualização provisório de 15 minutos é adequado para um ambiente hoteleiro onde as sessões podem durar dias. O desenho do esquema PostgreSQL garante que todos os campos relevantes para o GDPR são capturados, evitando simultaneamente a recolha desnecessária de dados. A política de retenção de 12/24 meses equilibra os requisitos do UK Investigatory Powers Act com os princípios de minimização de dados do GDPR.

Uma cadeia de lojas de retalho com 150 lojas precisa de cumprir os requisitos da norma PCI DSS 4.0 para monitorização de acessos à rede. Os seus terminais de ponto de venda utilizam MAC Authentication Bypass (MAB) na rede WiFi. A equipa de segurança recebeu um pedido do seu QSA (Qualified Security Assessor) para demonstrar que conseguem identificar qual o terminal POS específico que acedeu à rede de pagamentos num determinado momento, utilizando apenas um endereço IP de origem e o carimbo de data/hora de um registo de firewall.

A solução requer uma integração de três componentes. Primeiro, verifique se todos os controladores LAN sem fios estão configurados para incluir o atributo Framed-IP-Address nos pacotes de accounting RADIUS. Isto nem sempre está ativado por predefinição e deve ser explicitamente configurado. Segundo, integre a base de dados de accounting RADIUS com a plataforma SIEM (ex. Splunk). Crie uma tabela de correspondência no Splunk que associe o Framed-IP-Address e os intervalos de tempo da sessão ao Calling-Station-Id (endereço MAC). Terceiro, crie uma pesquisa guardada no Splunk que aceite um IP de origem e um carimbo de data/hora como entradas e devolva o endereço MAC correspondente, o NAS-IP-Address (identificando a loja e o AP) e o User-Name a partir dos registos de accounting RADIUS. O QSA poderá então visualizar este fluxo de trabalho: dado um registo de firewall que mostra o IP de origem 10.5.12.44 às 14:23:07 numa data específica, a pesquisa devolve o endereço MAC do terminal POS, o AP ao qual estava ligado e a localização da loja.

Comentário do Examinador: Este cenário destaca o papel crítico do atributo Framed-IP-Address na ponte entre a identidade da camada de rede (endereço IP) e a identidade da camada de dispositivo (endereço MAC). A abordagem com tabela de correspondência no SIEM é o método padrão do setor para este tipo de correlação. Note que em ambientes com tempos de concessão DHCP (lease times) muito curtos, a correlação deve utilizar uma consulta por intervalo de tempo em vez de uma procura num ponto específico no tempo, uma vez que o mesmo IP pode ter sido atribuído a vários dispositivos num curto espaço de tempo.

Perguntas de Prática

Q1. O gestor de TI de um hotel nota que o dashboard de analytics do WiFi mostra muito poucos utilizadores ativos durante o dia, embora o lobby e o restaurante estejam visivelmente movimentados. No entanto, os relatórios históricos do dia anterior mostram um pico massivo na utilização de dados. Os logs do servidor RADIUS confirmam que os pacotes Start estão a ser recebidos, mas a base de dados mostra muito poucos registos de Interim-Update. Qual é a configuração incorreta mais provável e como a resolveria?

Dica: Considere como a utilização de dados é reportada durante uma sessão ativa versus no momento da desconexão.

Ver resposta modelo

A causa mais provável é que os Interim-Updates estão desativados ou não configurados no Wireless LAN Controller. Sem atualizações intermédias, o servidor RADIUS apenas recebe um pacote Start quando o utilizador se liga e um pacote Stop quando se desliga. O dashboard de analytics não consegue exibir a utilização atual porque não estão a ser reportados dados em sessão. Assim que os utilizadores saem e se desligam, os pacotes Stop chegam com o total de dados acumulados, causando o pico atrasado nos relatórios históricos. A resolução consiste em ativar os Interim-Updates no WLC e definir um intervalo adequado — recomenda-se 15 minutos para um ambiente hoteleiro. Após a ativação, verifique se o servidor RADIUS está a receber pacotes Interim-Update consultando a base de dados de accounting por registos com Acct-Status-Type = 3.

Q2. Durante a investigação de um incidente de segurança, o seu SIEM sinalizou que um endereço IP na rede WiFi de convidados acedeu a um servidor de comando e controlo conhecido às 09:47:23 numa data específica. Precisa de identificar o dispositivo físico responsável. O seu tempo de concessão (lease time) de DHCP está definido para 30 minutos. Descreva a lógica exata de consulta que utilizaria na base de dados de accounting do RADIUS para identificar o dispositivo.

Dica: Os endereços IP não são estáticos. Deve utilizar uma consulta por intervalo de tempo, não uma pesquisa de ponto no tempo, e ter em conta a reciclagem de concessões DHCP.

Ver resposta modelo

Deve consultar a base de dados de accounting do RADIUS para sessões onde: (1) o Framed-IP-Address seja igual ao endereço IP sinalizado, E (2) o timestamp session_start seja anterior ou igual a 09:47:23, E (3) o timestamp session_end seja posterior ou igual a 09:47:23, OU o session_end seja NULL (sessão ainda ativa no momento da consulta). Se várias sessões corresponderem (possível com um lease DHCP de 30 minutos), reveja os registos de Interim-Update para confirmar qual a sessão que estava ativamente a reportar utilização às 09:47:23. O registo de sessão correspondente conterá o Calling-Station-Id (endereço MAC do dispositivo) e o User-Name (identidade autenticada, se foi utilizado 802.1X). Cruze o endereço MAC com o seu inventário de dispositivos ou logs do servidor DHCP para identificar o dispositivo físico e o seu proprietário.

Q3. É o arquiteto de rede de um centro de conferências que acolhe eventos com até 8.000 utilizadores WiFi simultâneos. O seu servidor RADIUS atual está a registar saturação de escrita na base de dados durante eventos de pico, causando atrasos de autenticação de 3 a 5 segundos. O seu intervalo de atualização intermédia atual está definido para 2 minutos. Descreva um plano de remediação em várias etapas que aborde tanto o problema de desempenho imediato como o risco de arquitetura subjacente.

Dica: Considere tanto as alterações de configuração como as alterações de arquitetura. O objetivo é manter a integridade do registo de auditoria, reduzindo ao mesmo tempo a carga de escrita.

Ver resposta modelo

O plano de remediação deve abordar três camadas. Primeiro, como correção imediata, aumente o intervalo de atualização intermédia (interim update) de 2 minutos para 15 minutos em todos os Wireless Controllers. Isto reduz a carga de escrita de accounting em aproximadamente 87% (de uma escrita a cada 2 minutos para uma a cada 15 minutos por sessão), o que deve aliviar imediatamente a pressão de E/S da base de dados. Segundo, separe os fluxos de autenticação e de accounting em instâncias de servidor dedicadas. O servidor de autenticação processa pacotes Access-Request/Accept/Reject, enquanto um servidor de accounting dedicado processa pacotes Accounting-Request e escreve numa base de dados separada. Isto evita que a carga de escrita de accounting afete os tempos de resposta de autenticação. Terceiro, para o risco de arquitetura subjacente, avalie se uma base de dados de séries temporais (ex. InfluxDB ou TimescaleDB) é mais adequada do que uma base de dados relacional para a carga de accounting. As bases de dados de séries temporais são otimizadas para escritas sequenciais de alto volume e consultas por intervalo de tempo, o que corresponde exatamente ao padrão de dados de accounting. Migre as escritas de accounting para a base de dados de séries temporais, mantendo a base de dados relacional para consultas de relatórios de conformidade.

Continue a ler esta série

Medir o ROI de Negócio do Guest WiFi e Analytics de Localização

Este guia fornece uma estrutura técnica e operacional para medir o ROI de negócio do guest WiFi e analytics de localização. Detalha como calcular o valor dos investimentos em hardware através do aumento do tempo de permanência, eficiência operacional e captura de dados primários em setores como retalho, hotelaria e recintos públicos. Os diretores de TI, arquitetos de rede, CTOs e diretores de operações de recintos encontrarão estruturas de medição concretas, estudos de caso do mundo real e orientações de conformidade para justificar e maximizar o seu investimento em WiFi.

Privacy by Design: Anonimização de Dados de WiFi para Conformidade com o GDPR

Este guia de referência detalha a arquitetura técnica e as estratégias de implementação para a anonimização de dados de WiFi para garantir a conformidade com o GDPR. Fornece aos líderes de TI e arquitetos de rede estruturas práticas para equilibrar análises robustas de locais com requisitos estritos de privacidade de dados.

Heatmapping vs Análise de Presença: Diferenças Técnicas

Este guia técnico de referência detalha as diferenças críticas, tanto arquitetónicas como operacionais, entre o heatmapping WiFi e a análise de presença para operadores de espaços empresariais. Disponibiliza aos líderes de TI, arquitetos de rede e diretores de operações estruturas de implementação práticas, cenários de implementação reais e as melhores práticas independentes de fornecedores para extrair o máximo ROI da sua infraestrutura sem fios existente.