Guarda de logs em provedor com CGNAT: o que precisa estar registrado
Por Hemily LimaCom CGNAT, o registro de conexão só identifica um assinante se guardar IP público, porta de origem, IP privado e o horário com fuso. O Marco Civil pede guarda por um ano. Sem a porta, o log existe mas não aponta ninguém, e a responsabilidade continua sendo do provedor.
Todo provedor de conexão guarda registro. A pergunta que quase ninguém testa é se esse registro serve para alguma coisa quando chega um ofício pedindo quem estava atrás de um IP às 21h47 de uma terça-feira.
Com CGNAT, na maioria dos casos, não serve.
O que o Marco Civil pede do provedor de conexão?
O Marco Civil da Internet (Lei 12.965/2014) determina que o provedor de conexão guarde os registros de conexão por um ano, em ambiente controlado e de segurança. Registro de conexão é o conjunto de informações que permite identificar quem usou determinado endereço IP em determinado momento.
A palavra que importa nessa definição é identificar. Guardar dado não cumpre a obrigação. Guardar dado que chega numa pessoa cumpre.
Por que o IP público sozinho não identifica ninguém?
Porque no CGNAT centenas de assinantes dividem o mesmo IP público ao mesmo tempo. O que separa um do outro é a faixa de portas de origem que cada um recebeu. Um log que registra apenas IP público e horário aponta para um grupo, não para uma pessoa.
Na prática o provedor entrega uma lista com 200 nomes e a resposta é inútil para quem pediu. Pior: a obrigação de identificar não deixa de existir porque a arquitetura da rede dificultou. Ela continua sendo do provedor.
Isso pega provedor de todo porte. Quem tem IPv4 sobrando e entrega IP público por assinante não vive esse problema. Quem colocou CGNAT para esticar o bloco de IPs, que é a maioria, vive.
O que precisa estar em cada registro?
O registro precisa permitir a correlação completa, do endereço público de volta ao assinante. Na prática são seis campos.
| Campo | Por que ele existe |
|---|---|
| IP público de saída | É o que chega no ofício |
| Faixa de portas de origem | É o que separa um assinante dos outros que dividem o IP |
| IP privado interno | Liga a sessão ao equipamento do cliente |
| Data e hora com fuso | Sem fuso declarado, uma diferença de 3 horas aponta para outra pessoa |
| Identificador do assinante | Login PPPoE, contrato ou CPF, conforme o cadastro |
| Início e fim da alocação | Delimita a janela em que aquela faixa era daquele cliente |
Faltando a faixa de portas, os outros cinco não resolvem. É o campo que mais falta nas configurações que a gente encontra.
Por quanto tempo guardar e onde?
Um ano é o piso legal para o provedor de conexão. Guardar mais que isso é decisão de risco de cada empresa, e guardar menos deixa o provedor descoberto justamente no período em que a maioria dos ofícios chega, que costuma ser meses depois do fato.
O volume assusta na primeira conta e depois acomoda. Registro de alocação de faixa de portas gera muito menos linha que log de sessão individual, porque uma faixa cobre milhares de conexões do mesmo assinante. O erro comum é dimensionar o armazenamento pensando em log de fluxo, que é outra coisa e não é o que a lei pede.
Sobre onde: precisa ser ambiente controlado, com acesso restrito e registro de quem consultou. Servidor de log com senha compartilhada pela equipe inteira não é ambiente controlado.
Como testar se a sua rastreabilidade funciona?
Pega uma data e um horário de três meses atrás, escolhe um IP público que estava em uso e tenta chegar no assinante. Se a resposta demorar mais que uma hora ou depender de uma pessoa específica estar disponível, você tem um problema de processo além do problema técnico.
Esse teste é o mais barato que existe em conformidade e quase ninguém faz. Ele responde de uma vez se o log está completo, se o backup daquele período sobreviveu e se alguém além do responsável direto sabe fazer a consulta.
O que costuma quebrar na prática?
Quatro coisas, em ordem de frequência no que a gente encontra:
- A porta de origem não é registrada. O log existe, ocupa disco e não identifica.
- O relógio dos equipamentos está fora de sincronia. Sem NTP confiável, o horário do log não bate com o horário do ofício.
- A retenção real é menor que a configurada, porque a rotação de disco apaga antes do prazo quando o volume cresce.
- Só uma pessoa sabe fazer a consulta. Quando ela sai de férias, o prazo de resposta corre igual.
Nenhum desses quatro aparece no dia a dia. Todos aparecem juntos no dia do ofício.
Perguntas frequentes
Provedor pequeno também precisa guardar log de conexão?
Sim. A obrigação do Marco Civil é do provedor de conexão, sem faixa de corte por número de assinantes. Provedor com 300 clientes responde pelo mesmo dever de guarda que provedor com 30 mil.
Quem não usa CGNAT precisa registrar porta de origem?
Não. Se cada assinante recebe IP público exclusivo, o próprio IP mais o horário já identificam. A porta de origem só vira obrigatória quando vários assinantes compartilham o mesmo endereço público.
Log de navegação e registro de conexão são a mesma coisa?
Não. Registro de conexão guarda quem usou qual IP e quando. Registro de acesso a aplicação guarda quais sites foram visitados, e o provedor de conexão não deve coletar isso.
Quanto tempo leva para adequar a guarda de logs?
Quando o equipamento já suporta o registro de faixa de portas, a adequação costuma levar poucos dias e é mais configuração que investimento. O prazo cresce quando o equipamento de borda não suporta e entra decisão de arquitetura.
Quer olhar isso na sua rede com quem faz há 15 anos?
Uma conversa de 30 minutos com a Hemily para dizer o que resolve primeiro, o que pode esperar e o que não precisa de investimento nenhum.
Sem custo e sem compromisso de contratar nada.
Leia também em Conformidade