Seus registros estão seguros antes de você precisar deles?
Como a Logfull guarda, protege e entrega os registros do seu provedor quando a requisição chega
Todo provedor sabe que precisa guardar logs. O que vemos com frequência na Logfull é outra coisa: a requisição chega e o registro de oito meses atrás estava num concentrador que foi resetado, num disco que encheu sem ninguém perceber, ou num servidor sem backup que morreu na última queda de energia.
Na hora de responder, “os logs estão no servidor” não basta. É preciso localizar o período, correlacionar os dados corretamente e apresentar uma informação confiável.
Foi para isso que estruturamos a Logfull: o provedor gera os registros na sua rede, e nós cuidamos de guardar, proteger e encontrar esses registros quando eles forem necessários.
Dois registros diferentes, e os dois importam
Antes de falar em segurança, é preciso separar dois tipos de registro. Confundi-los está por trás de boa parte dos problemas que encontramos.
Registros de conexão
Os registros de conexão vêm da autenticação e do accounting do assinante, normalmente via RADIUS. Eles informam qual cliente recebeu qual endereço, quando a sessão começou e quando terminou. É a guarda que o art. 13 do Marco Civil exige: um ano, sob sigilo, em ambiente controlado e de segurança.
Esse registro precisa incluir tanto o IPv4 quanto o IPv6 entregue ao assinante. No IPv6, o cliente recebe um prefixo exclusivo, normalmente por delegação de prefixo (DHCPv6-PD) vinculada à sessão autenticada. Como a prática atual das redes IPv6 não utiliza NAT, cada prefixo atribuído identifica um único assinante, e o registro de conexão sozinho já é suficiente para chegar a ele.
Isso só vale se o IPv6 estiver bem configurado. O prefixo precisa ser entregue dentro da sessão do assinante e aparecer no accounting RADIUS, junto com o IPv4. Um prefixo distribuído fora desse controle não fica vinculado a ninguém.
Se o provedor aplicar alguma técnica de mascaramento no IPv6, como NAT66 ou NPTv6, ou de tradução entre protocolos, como NAT64, vários assinantes passam a sair pelo mesmo endereço. Nesse caso, os registros de tradução tornam-se obrigatórios também para o IPv6, exatamente como acontece no IPv4 com CGNAT.
Registros de NAT/CGNAT
Na operação atual dos provedores, os registros de NAT/CGNAT são uma questão de IPv4. Com a escassez de endereços IPv4 públicos, o CGNAT faz dezenas de assinantes compartilharem o mesmo IPv4 público, e o endereço sozinho não identifica ninguém.
Os registros de NAT mostram qual IPv4 privado utilizou qual IPv4 público e qual porta, em que instante. Não contêm conteúdo de navegação, apenas a tradução de endereços.
No IPv4 com CGNAT, só a combinação dos dois registros permite chegar ao assinante: o NAT leva do IPv4 público e da porta ao IPv4 privado, e o RADIUS leva do IPv4 privado ao cliente.
Esse ponto ficou explícito na regulamentação em 2026. O Decreto nº 12.975/2026 incluiu no Decreto nº 8.771/2016 que a guarda do endereço IP abrange também a porta lógica de origem, sempre que ela for necessária para identificar de forma inequívoca o terminal de origem.
O que é do provedor e o que é da Logfull
Contratar a Logfull não elimina a responsabilidade do provedor sobre a geração correta dos logs em cada equipamento. O sistema remoto tem a obrigação de guardar o que for enviado, mas a rede é do provedor.
Na prática, a divisão é esta.
Cabe ao provedor
O provedor deve garantir que todos os concentradores, BNGs e equipamentos de CGNAT estejam enviando os registros. Isso inclui três pontos:
relógio sincronizado via NTP em todos os equipamentos;
accounting RADIUS ativo, com o IPv4 e o prefixo IPv6 de cada sessão;
exportação de NAT (NetFlow, IPFIX ou syslog) configurada com IP, porta e timestamp.
Um equipamento novo que entra em produção sem enviar logs é um buraco na guarda que nenhuma plataforma consegue preencher depois.
O IPv6 exige cuidado redobrado. O prefixo de cada cliente precisa ser entregue e controlado pelo mesmo sistema de autenticação que controla o IPv4. Encontramos com frequência provedores que simplesmente ativam um DHCPv6 ou anúncio de prefixo na rede e deixam qualquer equipamento pegar endereço, sem vínculo com a sessão RADIUS.
O resultado é grave. O endereço IPv6 usado não aparece em nenhum registro associado a um assinante. Chega a acontecer de um cliente bloqueado por inadimplência continuar navegando normalmente: o bloqueio foi aplicado só no IPv4, e o IPv6 segue funcionando porque o provedor não tem controle sobre ele. Se esse cliente for alvo de uma requisição, não há como identificá-lo.
Por isso, bloqueios, suspensões e encerramentos de sessão precisam valer para os dois protocolos. O prefixo IPv6 precisa constar no accounting de cada sessão, lado a lado com o IPv4.
Cabe à Logfull
A Logfull recebe esses registros, preserva-os íntegros durante todo o período de retenção e os mantém disponíveis mesmo diante de falhas. Também controlamos e auditamos quem os acessa e apoiamos o provedor na localização e correlação dos dados quando houver uma requisição.
Nosso time técnico ajuda o provedor a validar o envio correto a partir de cada equipamento, inclusive a presença do prefixo IPv6 no accounting. Mas a origem do dado está sempre na rede do cliente.
Como protegemos os seus registros
Infraestrutura própria. Os registros ficam no datacenter da Logfull, com sistema próprio, sem depender de nuvem pública de terceiros.
Acesso controlado e individualizado. Não trabalhamos com contas compartilhadas. Cada usuário é identificado individualmente e acessa apenas o que sua função exige, como prevê o Decreto nº 8.771/2016.
Integridade. Os registros são protegidos contra alteração e exclusão indevidas durante todo o prazo de guarda. O que entrou é o que será apresentado.
Trilha de auditoria. Todo acesso aos registros fica registrado: quem acessou, quando, por quanto tempo e o que foi consultado. É o inventário de acessos exigido pelo decreto, mantido automaticamente.
Redundância e backup. Uma falha de hardware não pode significar perda de registros. A guarda é estruturada para continuar disponível mesmo com a indisponibilidade de um componente.
Retenção controlada. Mantemos os registros pelo prazo legal de um ano. Quando uma autoridade requer cautelarmente a preservação por prazo maior, esse período é estendido para os dados envolvidos. Encerrado o prazo, os dados são excluídos, seguindo o princípio de retenção mínima do próprio decreto.
Quando a requisição chega
Aqui está a diferença entre ter logs guardados e estar preparado.
Quando o provedor recebe uma requisição judicial ou de autoridade competente, ele nos encaminha o pedido. Nosso time valida a solicitação antes de qualquer consulta: confere se o pedido está formalmente adequado e se o período e os dados solicitados correspondem à operação do cliente.
Validado o pedido, localizamos os registros do período, correlacionamos NAT e conexão, em IPv4 e IPv6, e entregamos ao provedor as informações organizadas e estruturadas para a resposta. O provedor não precisa procurar arquivos espalhados em servidores nem montar a correlação manualmente sob prazo.
Sua operação está preparada?
Vale responder a estas perguntas antes de uma requisição real chegar:
Todos os equipamentos que fazem NAT estão enviando registros com IP, porta e horário?
Os relógios estão sincronizados?
O accounting RADIUS está completo, com início e fim de cada sessão?
O prefixo IPv6 de cada cliente aparece no accounting RADIUS, junto com o IPv4?
O bloqueio de um assinante também corta o IPv6?
Quando um equipamento novo entra em produção, alguém confere se ele está enviando logs?
Se a requisição pedir um horário de oito meses atrás, quanto tempo leva para chegar ao assinante?
Se alguma dessas respostas depende de “acho que sim” ou de uma pessoa específica da equipe, existe um ponto de atenção.
Registro seguro é registro preparado antes
O provedor gera os registros na sua rede. A Logfull guarda, protege, audita e ajuda a encontrar o que for necessário, com infraestrutura própria e suporte técnico quando a requisição chegar.
Seus registros precisam estar prontos antes de você precisar deles. Conheça a Logfull.
Referências
Marco Civil da Internet — Lei nº 12.965/2014
Decreto nº 8.771/2016, com alterações do Decreto nº 12.975/2026
Lei Geral de Proteção de Dados — Lei nº 13.709/2018
