Justiça decide que provedores de conteúdo têm obrigação de guardar dados relativos a portas lógicas de origem

Em decisão unânime, os desembargadores da 1ª Câmara de Direito Empresarial do Tribunal de Justiça de São Paulo (TJSP), determinaram que os sites de venda online forneçam os registros de criação e acesso de anúncios de suas plataformas, bem como das contas responsáveis pela criação, com endereço de IP, data, hora, fuso horário e porta lógica de origem, restritos temporalmente ao período de seis meses antes da intimação da decisão liminar em 1º Grau.

Em outras palavras, a decisão estabelece que os provedores devem guardar dados relativos a portas lógicas de origem (dado capaz de identificar e individualizar um usuário dentro do provedor de conexão, ainda que o mesmo IP tenha sido distribuído para um grupo de pessoas).

O presidente da AbraCloud, Roberto Bertó, explica em detalhes o funcionamento deste processo e como ele impacta na segurança dos dados.

“Embora tal ação já fosse tecnicamente necessária, agora a justiça entende que é obrigatório nós (provedores) guardarmos os dados, se gerenciamos a aplicação, ou o cliente quando a gerência. Precisamos guardar a porta de origem por causa dos CGNATs (Carrier-Grade Network Address Translation), usados pelos provedores de acesso no IPv4 para otimizar o uso do IPv4.

Entendemos que os provedores de aplicação e de conexão devem guardar a porta lógica só quando é um IPv4 disfarçado de 6. Não é só quando tem IPv6 com nat para IPv4. É possível apenas usando IPv4, sem nem usar IPv6, também ter CGNAT”, completa ele

“Um exemplo seria termos um IPv4 público e dividir em vários clientes por range de porta. Ou seja, não é possível saber o que o provedor de acesso está fazendo. Então, para garantirmos a segurança dos dados, na prática, devemos logar a porta de origem sempre. Se há entendimento de tribunal e entendimento técnico, então é preciso oferecer uma orientação bem importante, pois, por padrão, os sistemas operacionais não logam a porta de origem.

E ainda existe um agravante: na maioria dos servidores de aplicação utiliza-se um load balancer na frente, também conhecido como proxy reverso, e aí o load balancer também precisa fazer a configuração de pegar a porta de origem e passar via header para o servidor final. Afinal, gravar o log pode ocorrer no proxy reverso (no primeiro contato do usuário na rede do provedor de conteúdo) ou então no servidor de aplicação final. E, para agravar a situação, é extremamente comum ter inúmeros proxy reversos um atrás do outro.

Neste caso, temos um problema bem grande, porque quando se atualiza qualquer uma dessas camadas a chance de uma delas parar de mandar a porta de origem adiante é enorme. É preciso ter muita atenção para manter as configurações gravando porta de origem, em especial porque a qualquer momento pode parar de funcionar. Assim, ninguém monitora se as portas estão sendo logadas, é uma confusão.

E ainda: muitas aplicações usam cloudflare ou similares (que é o primeiro contato do usuário a um servidor http). Seria mais fácil que o log fosse feito nesta primeira camada. Porém, cloudflare só grava log e entrega ao cliente dela (o dono da aplicação,) no plano enterprise, de uns $120 mil anuais, com contrato anual.

E um agravante: eu estou falando aplicação http, e este é apenas um dos protocolos. Os demais protocolos têm software de servidor que nem sequer tem opção de logar porta de origem. E para complicar a situação, cada provedor de conteúdo não tem um servidor central. É comum o provedor ter centenas de servidores, e cada um precisa ser configurado para atender a lei, independente um do outro”, finaliza Bertó.

Fonte: Provedores de aplicação têm dever de guarda de dados relativos a portas lógicas de origem, decide TJSP. TI Inside, 2024. Disponível em: https://tiinside.com.br/07/08/2024/provedores-de-aplicacao-tem-dever-de-guarda-de-dados-relativos-a-portas-logicas-de-origem-decide-tjsp/?amp

Acesso em: 07/08/2024