CGNAT e logs: como atender o Marco Civil sem dor de cabeça

Todo provedor que opera CGNAT vai, mais cedo ou mais tarde, receber um ofício. Um juiz pede que você identifique quem usava um determinado IP público em uma data e horário específicos. Se você só tem o IP e a data, a resposta é inútil: por trás daquele IP havia dezenas ou centenas de assinantes ao mesmo tempo. Sem a porta de origem, não dá para apontar o cliente, e a ausência de uma resposta adequada deixa o provedor exposto. Este artigo trata do que precisa estar registrado, por quanto tempo, e como montar isso sem virar um pesadelo de armazenamento.

Por que o CGNAT quebra a rastreabilidade

Com o IPv4 esgotado, o Carrier-Grade NAT virou regra. Você compartilha um pool de IPs públicos entre muitos assinantes IPv4 privados (tipicamente no range 100.64.0.0/10). O equipamento traduz IP privado + porta para IP público + porta na saída.

O problema de compliance nasce aí: o IP público sozinho não é mais um identificador único. A combinação que identifica uma conexão é:

IP público de origem
Porta de origem traduzida
IP e porta de destino
Protocolo (TCP/UDP)
Timestamp preciso

Um ofício típico chega com IP de destino, IP público de origem, porta de origem e horário. Se o seu log de NAT não amarra a porta de origem ao assinante naquele instante, não há como responder. É um dos erros mais comuns: o provedor faz CGNAT, mas nunca configurou o logging da tradução.

O que o Marco Civil exige na prática

O Marco Civil da Internet (Lei 12.965/2014) e seu decreto regulamentador (Decreto 8.771/2016) definem dois registros distintos, e é importante não confundir:

Registros de conexão (art. 13) — guarda obrigatória pelo provedor de conexão (o ISP) por 1 ano. É o conjunto de informações sobre data, hora de início e término da conexão à internet, sua duração e o IP usado pelo terminal.
Registros de acesso a aplicações (art. 15) — guarda por 6 meses, e é obrigação do provedor de aplicação, não do ISP de acesso.

Como ISP, sua obrigação central é o registro de conexão de um ano. O ponto que a lei não detalha tecnicamente, mas que a realidade do CGNAT impõe, é que o IP público sem a porta de origem não cumpre a finalidade do registro. Na prática, para responder a uma ordem judicial você precisa do log de tradução NAT (qual assinante usava qual IP público e qual faixa de portas, em qual janela de tempo). Sem isso, o registro de conexão existe, mas não serve para identificar ninguém.

Pontos que evitam dor de cabeça mais tarde:

Os registros só podem ser disponibilizados mediante ordem judicial (autoridade não pega log sem mandado). Tenha um processo claro de quem libera o quê.
Sincronização de relógio é inegociável. Se seus timestamps derivam alguns segundos do horário real, um log de NAT com rotação rápida de portas vira lixo probatório. Use NTP confiável e horário oficial brasileiro.
Guarde com integridade e sob sigilo. Vazar log de conexão é tão grave quanto não tê-lo.

Estratégias de logging que escalam

Logar cada tradução NAT (per-flow) é tecnicamente correto e juridicamente o mais robusto, mas gera volume enorme. Um BNG de borda pode produzir um número muito alto de novos fluxos por segundo em horário de pico, e guardar isso por um ano em texto cru raramente é viável. As abordagens que funcionam:

1. Alocação de blocos de portas (Port Block Allocation / NAT determinístico). Em vez de logar fluxo a fluxo, você aloca blocos contíguos de portas por assinante. Quando o cliente conecta, ele recebe, por exemplo, as portas 4096–4607 do IP público X. Você loga uma única linha: "assinante Y → IP X, portas 4096–4607, das 14h02 às 18h47". Isso reduz o volume de logs em ordens de grandeza e ainda responde a qualquer ofício dentro daquele bloco. MikroTik (RouterOS), Cisco, Juniper e Huawei suportam variações disso (port-block, paired-address-pooling, deterministic NAT). É a recomendação mais comum para a maioria dos provedores.

2. NAT determinístico puro. Você pré-aloca de forma algorítmica a relação assinante↔porta, de modo que o mapeamento pode ser revertido por cálculo, gerando log mínimo. Exige planejamento de capacidade (quantas portas por cliente, taxa de oversubscription) e funciona bem quando a base é estável.

3. Exportação estruturada via IPFIX/NetFlow. Em redes maiores, exporte os eventos de NAT (create/delete de binding) via IPFIX para um coletor, em vez de cuspir syslog. Fica indexável, comprimível e pesquisável por IP + porta + timestamp.

Independentemente da estratégia, defina retenção de um ano alinhada ao art. 13, com expurgo automático depois disso — guardar além do prazo sem necessidade só aumenta o risco e o custo.

O calcanhar de Aquiles: capacidade de portas

Cada IP público tem cerca de 64 mil portas. A título de exemplo, se você der blocos de 512 portas por assinante, cabem em torno de 128 clientes por IP — antes de qualquer oversubscription. Subdimensionar a faixa de portas por cliente gera exaustão de portas: aplicações falham silenciosamente (VoIP, jogos, múltiplas abas) e o suporte recebe chamados que ninguém consegue diagnosticar. Dimensionar o pool de IPs CGN, o tamanho do bloco e a taxa de compartilhamento é uma decisão de engenharia, não um chute. E essa configuração precisa estar documentada, porque meses depois ninguém lembra por que aquele cliente recebeu aquela faixa.

Onde isso encontra a operação

O ponto cego não costuma ser técnico — é organizacional. Quando o ofício chega, alguém precisa: localizar o equipamento de borda certo, achar o log do período, cruzar IP público + porta + horário com a base de assinantes e produzir uma resposta defensável. Se isso depende de um técnico abrir SSH em cada BNG e fazer grep em arquivo, o processo é frágil e não audita.

É exatamente o tipo de coisa que estruturamos no dia a dia de NOC: documentação viva da topologia, inventário de quem faz CGNAT e como, padronização de NTP e retenção, e um fluxo claro de atendimento a ordens judiciais. No NetPulse, nossa plataforma de NOC, o inventário/DCIM e a documentação ficam centralizados e versionados, com cofre de credenciais 2FA para o acesso aos equipamentos de borda — o que reduz o tempo de localizar o BNG, a configuração de NAT e o responsável quando o ofício bate.

Checklist mínimo

CGNAT configurado com log de tradução (não só NAT cru)
Estratégia de port-block / determinístico para volume sustentável
Porta de origem sempre registrada junto do IP público
NTP sincronizado em todos os equipamentos de borda
Retenção de 1 ano com expurgo automático
Acesso aos logs restrito e liberado só sob ordem judicial
Dimensionamento de portas documentado para evitar exaustão

CGNAT não é opcional num mundo sem IPv4 — mas operá-lo cego de logs é assumir um risco jurídico que ninguém precisa correr. A boa notícia: estruturar isso direito é um problema de engenharia bem definido, com solução conhecida.

Se você opera CGNAT e não tem certeza se conseguiria responder a um ofício hoje, a CloudFace pode ajudar — desde o desenho do logging e da retenção até a operação contínua via NOC, com o NetPulse organizando inventário e documentação. Faça um diagnóstico inicial gratuito com a gente pelo WhatsApp: olhamos sua configuração de NAT sem compromisso.