Registro de logs do proxy e privacidade
Um site pode ver um IP de proxy no lugar do seu, enquanto o provedor de proxies sabe qual conta de cliente abriu a conexão. Essas são duas visões diferentes da mesma solicitação. Mudar o endereço visível para um site não torna sua atividade invisível à empresa que a transporta.
O registro de logs do proxy significa manter registros de como o serviço é utilizado: conexões, destinos, volumes de tráfego, erros e, em alguns produtos, solicitações e respostas. Este artigo explica práticas do setor. Assim como em outras políticas dos provedores de proxies, os detalhes dependem do serviço. A seção final descreve como a ProxyCompass trata os dados do serviço.
O que um proxy pode ver ao se conectar a um site HTTPS
Considere um leilão ilustrativo: sua aplicação envia um lance de €180 para https://bid.example/lot/218/bids. Com um túnel de proxy comum, o HTTPS protege a troca entre sua aplicação e o site usando o protocolo de segurança TLS. O provedor pode ver o IP do cliente que se conecta, o destino bid.example:443 e o horário da conexão; também pode medir o volume de dados transferidos. A URL completa, o lote selecionado, a ação do cliente, o valor do lance, os cookies e a resposta do leilão ficam dentro do HTTPS. Com a verificação correta de certificados e sem interceptação, o provedor não consegue lê-los.
O domínio pode ser exposto antes de essa troca criptografada começar. O HTTP CONNECT normalmente informa o host e a porta de destino. O SOCKS5 pode receber um nome de domínio ou um endereço IP; se a aplicação pedir ao proxy para se conectar por nome de domínio, o proxy fica sabendo esse nome. Um IP de destino sozinho não identifica necessariamente um site específico, já que vários sites podem compartilhá-lo.
O HTTP sem criptografia é diferente: seus cabeçalhos, caminho da página e conteúdo ficam disponíveis para um proxy que transporta a solicitação. O SOCKS5 não acrescenta criptografia a uma troca da aplicação que, de outra forma, não é criptografada. HTTPS por SOCKS5 mantém sua proteção HTTPS; HTTP por SOCKS5 continua legível.
O próprio site recebe a solicitação descriptografada. Ele consegue ler o login, os cookies e os campos de formulário que você envia e reconhecer uma conta existente após uma mudança do IP do proxy. O HTTPS protege os dados em trânsito; não os oculta de seu destinatário pretendido.
Por que alguns provedores de proxies exigem a instalação de um certificado
Alguns provedores exigem que os clientes confiem em seu próprio certificado raiz para determinados serviços que inspecionam tráfego HTTPS. Essa exigência vem do provedor, não do site visitado, e não se aplica a todos os proxies. A ProxyCompass não exige que os clientes instalem seu certificado raiz.
Com um túnel HTTPS comum, o proxy não consegue ler o conteúdo das solicitações e respostas. Se um serviço precisa verificar os dados enviados, aplicar regras a eles ou analisar as respostas dos sites, precisa de acesso a esse conteúdo. A inspeção de HTTPS fornece esse acesso: o serviço descriptografa o tráfego que passa por ele.
Um certificado raiz é um documento digital que uma aplicação usa como base para confiar em outros certificados. Acrescentar o certificado do provedor ao conjunto confiável permite que a aplicação aceite certificados de sites emitidos por esse provedor. No modo de inspeção, o proxy apresenta um desses certificados no lugar do certificado original do site. Sem a confiança correspondente, a verificação normal de certificados falha.
O proxy estabelece duas conexões criptografadas separadas: uma com sua aplicação e outra com o site. Entre elas, ele consegue ler solicitações e respostas. No exemplo ilustrativo do leilão, isso expõe o endereço completo https://bid.example/lot/218/bids, o número do lote, o lance enviado de €180, os cookies e a resposta que aceita o lance. O provedor consegue ver o que o cliente realmente faz no site.
Essa exigência depende do produto, do modo e do método de acesso específicos. Ela pode aparecer em serviços que automatizam o acesso a sites ou quando a análise de tráfego é ativada em um gerenciador de proxies. Apenas a designação “residencial” ou “datacenter” não informa se ela se aplica. Às vezes basta fornecer o certificado a um script; instalá-lo no sistema inteiro é desnecessário.
Instalar um certificado não direciona, por si só, todo o tráfego pelo provedor. O acesso descrito aqui ocorre quando as solicitações passam por um serviço com a inspeção ativada. Um certificado usado apenas para verificar o próprio endereço HTTPS do proxy também não significa que o conteúdo da conexão com o site de destino seja descriptografado.
Conseguir ler dados e salvá-los em logs são questões separadas. O certificado ajuda a explicar quem pode acessar o conteúdo da conexão, mas não informa nada sobre prazos de retenção ou acesso de funcionários. Desativar a verificação de certificados também não oculta os dados de um serviço que os descriptografa.
APIs de scraping e navegadores remotos recebem o conteúdo
Com uma API de scraping, você dá uma tarefa ao serviço: abrir esta URL e retornar a página ou os dados extraídos. O serviço faz sua própria conexão com o site e recebe a resposta em formato legível. Ele pode fazer isso sem pedir que você instale um certificado, pois é o cliente que busca a página.
Um navegador hospedado pelo provedor funciona nas máquinas dele. As páginas, os cookies e as sessões do navegador são processados ali, mesmo que a conexão usada para controlar o navegador seja criptografada. Dependendo do produto, sua tarefa pode incluir URLs completas, cabeçalhos personalizados, cookies, dados de formulário e instruções para interagir com uma página.
Esse acesso é necessário para executar a tarefa. Ele não estabelece que toda página seja arquivada nem que funcionários leiam rotineiramente os resultados dos clientes. Significa, porém, que as regras do produto para o tratamento de tarefas e resultados importam: uma promessa que cobre túneis de proxy comuns pode não cobrir sua API ou seu navegador hospedado.
Para uma empresa, as informações sensíveis podem ser uma lista de produtos monitorados, uma sequência de buscas ou um conjunto de alvos de pesquisa. Mesmo quando todas as páginas de origem são públicas, a coleta e a forma como ela é usada podem revelar um projeto comercial.
O que pode aparecer nos logs de proxy
Um provedor pode manter vários tipos de registro. Eles não precisam ser armazenados juntos: uma conexão pode se referir a um número de conta, enquanto o endereço de e-mail, o pedido e o pagamento ficam em outros sistemas.
| Tipo de registro | Conteúdo possível |
|---|---|
| Conexões | Horário de início e duração, IP que se conecta, IP do proxy usado para acessar o site, endereço ou domínio de destino, portas e erros de conexão. |
| Uso | Bytes transferidos, contagens de conexões e totais de uma conta ou período de cobrança. |
| Conta e acesso | Dados de cadastro, logins, IPs autorizados dos clientes, alterações de credenciais, pedidos e referências de pagamento. |
| Suporte e incidentes | Chamados, anexos, reclamações de sites e registros da investigação. |
| Solicitações e resultados | URLs completas, cabeçalhos, corpos de solicitação ou páginas buscadas, quando o produto consegue lê-los e suas configurações permitem o registro. |
Essas são categorias possíveis, não uma lista que todo provedor necessariamente coleta. Um serviço pode processar um valor para abrir uma conexão sem retê-lo. Também pode manter um contador total de tráfego sem preservar um registro permanente de cada destino.
O IP do cliente em um log é o endereço do dispositivo ou intermediário que se conecta diretamente ao proxy. Em uma conexão direta, costuma ser o IP público do cliente; com outro intermediário antes dele, pode ser o endereço desse intermediário.
O que uma declaração de não manter logs realmente abrange
“Não armazenamos o conteúdo do seu tráfego” pode coexistir com registros de domínios de destino, horários de conexão e uso. “Mantemos apenas os totais de uso” descreve outro arranjo. Uma indicação curta de não manter logs não informa qual dessas promessas o provedor está fazendo.
Leia a declaração à luz dos dados e do produto mencionados. Ela exclui o conteúdo das páginas, os registros de conexões individuais, o histórico de destinos ou os três? Cobre apenas a operação normal ou também o registro de logs de diagnóstico? O que permanece nos sistemas de conta, pagamento, suporte e abuso?
Uma declaração de uso apenas de RAM descreve um método de armazenamento. Ela não informa se as informações são enviadas a outro sistema antes de a memória ser limpa. Da mesma forma, o armazenamento criptografado protege os registros contra determinados tipos de acesso não autorizado; não significa que o provedor não consiga lê-los.
Designações como privado, dedicado ou elite não respondem a essas perguntas. Elas descrevem outras propriedades do proxy. Um site de verificação de IP consegue inspecionar a solicitação que chega àquele site, mas não consegue verificar as práticas internas de registro de logs do provedor.
Como os logs ajudam com falhas, cobrança e reclamações por abuso
Os registros de conexão podem distinguir uma falha de autenticação de um destino que não respondeu. Os totais de uso ajudam a explicar uma franquia de tráfego consumida. Uma mudança repentina nos padrões de conexão também pode revelar um script com problemas ou uso inesperado de uma conta.
Uma distinção útil é entre uma conexão de proxy bem-sucedida e uma solicitação ao site bem-sucedida. Uma resposta CONNECT bem-sucedida confirma que um túnel foi aberto. Dentro dele, o site ainda pode retornar um CAPTCHA ou HTTP 403. Um túnel comum não lê essa resposta criptografada; assim, seu resultado de conexão e o resultado do site na aplicação podem diferir.
O site de destino tem outra visão. Se recebe tentativas de adivinhar senhas, pode informar as solicitações, o IP do proxy, o horário e outros detalhes da conexão. Se o provedor tiver registros correspondentes suficientes, pode relacionar a reclamação à conta de cliente usada nessas conexões. Ficar sabendo o caminho de uma solicitação pela reclamação do site não significa que o provedor descriptografou o tráfego HTTPS original.
Um IP de proxy compartilhado não impede esse cruzamento. Registros detalhados podem relacionar uma conexão de cliente autenticada à conexão feita com o site. Registros precisos de horário, incluindo milissegundos quando registrados, portas e o destino ajudam a distinguir conexões simultâneas. IPs rotativos também podem continuar vinculados à mesma conta. Mudar ou compartilhar um endereço não apaga os registros do provedor.
Por quanto tempo os registros permanecem
Logs de conexão, faturas, chamados de suporte e resultados de scraping podem ter prazos de retenção diferentes. Uma política útil explica esses prazos por categoria ou declara as condições usadas para decidir por quanto tempo cada categoria é necessária.
O histórico visível em um painel não é necessariamente o período completo de armazenamento. Se a interface mostra apenas a atividade recente, isso informa o que você pode visualizar ali. Não estabelece quando registros internos, arquivos de incidentes ou backups são excluídos.
Encerrar uma conta não apaga necessariamente todos os registros associados. Registros de cobrança ou incidentes podem permanecer quando houver um motivo legal para retê-los. A exclusão dos sistemas ativos e a expiração das cópias de backup também podem ocorrer em calendários diferentes.
Substituir o nome de um cliente por um ID de conta não torna os registros anônimos se a empresa mantém o vínculo entre esse ID e o cliente. A pergunta relevante é se as informações restantes ainda podem ser relacionadas a uma conta ou pessoa.
Quem pode acessar as informações
A existência de logs e a permissão para lê-los são questões diferentes. O suporte pode precisar de erros de conexão, a área financeira precisa de registros de pagamento e uma equipe de segurança pode precisar de informações sobre um incidente. A política de privacidade deve explicar o acesso e o compartilhamento; os controles de segurança devem limitar o acesso às pessoas que precisam dele.
Um revendedor e a empresa que opera a rede de proxies podem manter partes diferentes dos registros. Processadores de pagamento, empresas de hospedagem e plataformas de suporte também podem tratar determinados dados. Verifique quais empresas estão envolvidas e quais informações recebem.
O país de um IP de proxy não determina, por si só, onde os registros dos clientes são mantidos nem quais regras legais se aplicam ao provedor. A empresa contratada, seus arranjos de tratamento e a legislação aplicável também importam. Um provedor pode ter de divulgar informações retidas às autoridades por uma exigência legal vinculante. As condições aplicáveis devem ser lidas em sua política; não há uma regra mundial única para todos os serviços de proxy.
Escolher condições de privacidade para sua carga de trabalho
Para um projeto que precisa manter o conteúdo das páginas dentro da sua própria aplicação, a distinção entre um túnel HTTPS normal e um serviço gerenciado de busca de páginas é relevante. Um túnel pode manter o conteúdo ilegível para o intermediário e ainda expor metadados de conexão. Uma API gerenciada pode reduzir seu próprio trabalho de desenvolvimento, mas recebe a tarefa e o resultado.
Os metadados de destino também podem importar. Uma lista de domínios, os horários das visitas e seu volume podem revelar quais empresas ou mercados uma equipe está estudando. Decida se essas informações são sensíveis antes de tratar a criptografia do conteúdo como proteção suficiente para o projeto.
Por fim, considere o que você mesmo envia ao suporte. Um arquivo de configuração ou uma captura de rede pode conter senhas de proxy, tokens de acesso, cookies e corpos de solicitação que nunca apareceram nos logs de tráfego do provedor. Remova segredos sem relação com o problema antes de compartilhar material de diagnóstico.
Antes de começar o trabalho, estabeleça o que o produto escolhido consegue ler, o que mantém, quando esses registros são removidos e quem pode recebê-los. Esses detalhes tornam uma política de privacidade útil para uma tarefa real.