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