Um fornecedor de proxy fica no caminho do seu tráfego. Seus scrapers, tarefas de monitoramento e suítes de teste enviam requisições através da sua rede, muitas vezes com credenciais anexadas, então antes que um plano de proxy residencial seja aprovado, sua equipe de segurança vai querer respostas por escrito.
A maioria das empresas parte de um questionário padrão como o SIG da Shared Assessments ou o CAIQ da Cloud Security Alliance, um conjunto de perguntas de sim ou não mapeadas à sua Cloud Controls Matrix. Isso cobre o básico de qualquer fornecedor. Uma rede de proxy levanta algumas perguntas que esses questionários não fazem, principalmente de onde vêm os IPs e o que o fornecedor consegue ver. Esta checklist cobre ambos os pontos, seção por seção, com o que uma boa resposta parece.
Isto é informação geral, não aconselhamento jurídico ou de auditoria.
Por que um fornecedor de proxy recebe sua própria avaliação
Três coisas diferenciam fornecedores de proxy de um fornecedor de SaaS típico.
- Eles veem seu tráfego. Para requisições HTTPS o fornecedor vê os hosts aos quais você se conecta, o tempo e o volume. Para HTTP simples ele vê o conteúdo.
- Eles detêm credenciais que podem gastar dinheiro. Uma senha de proxy vazada permite que outra pessoa rode tráfego na sua conta.
- Os IPs de saída pertencem a outra pessoa. IPs residenciais e móveis vêm de dispositivos de pessoas reais. Como esses dispositivos entraram na rede é uma questão legal e reputacional tanto para você quanto para o fornecedor.
O último ponto não é teórico. Em maio de 2024 o Departamento de Justiça dos EUA anunciou ter desmantelado a botnet 911 S5, um serviço de proxy residencial associado a mais de 19 milhões de endereços IP únicos, construído espalhando malware através de programas VPN e instaladores empacotados. Em maio de 2025 o FBI alertou que serviços de proxy criminosos estavam instalando proxies em roteadores domésticos fora de suporte. Em janeiro de 2026 o Threat Intelligence Group do Google descreveu ter interrompido a rede IPIDEA, cujos nós de saída observou sendo usados por mais de 550 grupos de ameaça, e concluiu que alegações de obtenção ética “devem ser respaldadas por prova transparente e auditável de consentimento do usuário.”
Seção 1: Origem de IPs e consentimento
- Como são obtidos os IPs residenciais e móveis: um SDK em aplicativos parceiros, um aplicativo de compartilhamento de banda, acordos com ISPs?
- Vocês podem mostrar a tela de consentimento que o dono do dispositivo vê, e como ele a revoga?
- Vocês auditam os aplicativos parceiros que carregam seu SDK, e o que acontece quando um deles descumpre as regras?
- Vocês compram ou revendem IPs de outras redes?
Boa resposta: um modelo de origem nomeado, um fluxo de consentimento que você pode ver, e um processo de auditoria. Sinal de alerta: “nossos IPs são obtidos eticamente” sem nada por trás disso. Nosso guia sobre como provedores obtêm IPs residenciais explica os modelos e qual prova esperar.
Seção 2: O que o fornecedor vê e registra
- Quais dados de requisição vocês registram: IP de origem, host de destino, timestamps, bytes, URLs completas?
- Por quanto tempo cada registro é mantido, e quem dentro da empresa pode acessá-lo?
- Vocês inspecionam ou modificam o tráfego, por exemplo interceptando TLS?
- Vocês divulgarão registros a terceiros, e sob qual processo legal?
Boa resposta: uma lista campo por campo com períodos de retenção e nenhuma interceptação de TLS. Sinal de alerta: “não registramos nada” vindo de um fornecedor que cobra por banda e destino, já que ele precisa contar alguma coisa. Nosso artigo sobre se proxies residenciais são seguros cobre o que um proxy pode e não pode ver.
Seção 3: Controle de acesso e credenciais
- Quais métodos de autenticação vocês suportam: usuário e senha, lista de IPs permitidos, ambos?
- Podemos criar credenciais separadas por equipe, projeto ou ambiente, e revogar uma sem afetar as demais?
- O painel suporta single sign-on e autenticação multifator, com papéis definidos?
- Existe um registro de auditoria de alterações na conta e redefinições de credenciais?
Boa resposta: credenciais por projeto com limites próprios, e MFA no painel. Sub-usuários separados por equipe ou cliente também tornam possível ver qual tarefa usou o quê.
Seção 4: Criptografia em trânsito
- Quais versões de TLS o painel, a API e os endpoints de proxy aceitam?
- A conexão do nosso cliente até o próprio proxy pode ser criptografada?
Boa resposta: TLS 1.2 ou mais recente, com suporte a TLS 1.3. A orientação do NIST para sistemas federais dos EUA (SP 800-52 Rev. 2) estabelece essa base, e é um patamar razoável para qualquer fornecedor.
Seção 5: Auditorias e certificações
- Vocês possuem um relatório SOC 2? Tipo 1 ou Tipo 2, qual período, e quais categorias de Trust Services (segurança, disponibilidade, integridade de processamento, confidencialidade, privacidade)?
- Vocês são certificados pela ISO/IEC 27001:2022, e qual é o escopo?
- Quando foi seu último teste de penetração independente, e podemos ver um resumo?
Boa resposta: um relatório Tipo 2 recente cujo escopo inclua a infraestrutura de proxy, não apenas o site de faturamento. Um relatório Tipo 1 apenas diz que os controles foram desenhados adequadamente em um ponto no tempo; o Tipo 2 acrescenta uma opinião sobre se operaram efetivamente ao longo de um período. Sinal de alerta: um certificado cujo escopo exclui os sistemas que você vai usar.
Seção 6: Proteção de dados e subprocessadores
- Vocês assinarão um acordo de processamento de dados? Sob o Artigo 28 do GDPR, um processador age apenas conforme instruções documentadas e precisa de autorização prévia por escrito do controlador antes de contratar outro processador.
- Quais subprocessadores vocês usam (hospedagem, registro de logs, pagamentos), e em quais países?
- Vocês mantêm o registro das atividades de processamento exigido pelo Artigo 30 dos processadores?
Boa resposta: um DPA padrão, uma lista de subprocessadores publicada e um prazo de aviso para mudanças. Para o panorama mais amplo do GDPR, veja nosso guia sobre proxies residenciais e conformidade com o GDPR.
Seção 7: Incidentes e abuso
- Como e com que rapidez vocês nos informarão sobre um incidente de segurança que afete nossa conta ou dados? O Artigo 33 do GDPR exige que processadores notifiquem os controladores “sem demora indevida”, e que controladores notifiquem a autoridade em até 72 horas quando viável.
- Como vocês tratam relatos de abuso sobre tráfego originado da sua rede?
- Quais alvos e usos vocês bloqueiam, e vocês verificam os clientes?
Boa resposta: um contato nomeado, um compromisso de notificação no contrato, e uma política de uso aceitável escrita e aplicada. Controles de abuso também protegem você: todo cliente compartilha a reputação dos mesmos IPs.
Seção 8: Continuidade e saída
- Qual disponibilidade vocês se comprometem a entregar, como ela é medida, e qual é a solução quando não é cumprida?
- Se vocês deixarem de nos atender, como recuperamos nossos dados e encerramos as credenciais?
O questionário em uma página
| Seção | Peça | Sinal de alerta |
|---|---|---|
| Origem | Fluxo de consentimento, modelo de origem, auditorias de parceiros | ”Obtido eticamente” sem evidências |
| Registro | Lista de campos e retenção por registro | ”Não registramos nada” |
| Acesso | Credenciais por projeto, MFA, registro de auditoria | Uma única senha compartilhada por empresa |
| Criptografia | TLS 1.2+, com suporte a 1.3 | Painel ou API em texto simples |
| Auditorias | SOC 2 Tipo 2 ou ISO 27001 com escopo de proxy | Escopo que exclui a rede |
| Proteção de dados | DPA, lista de subprocessadores | Sem DPA para clientes da UE |
| Incidentes | Aviso contratual, política de abuso | Sem contato de segurança nomeado |
Conclusão
Um fornecedor de proxy merece a mesma avaliação que qualquer fornecedor que toca seu tráfego, mais algumas perguntas que só redes de proxy levantam. Envie seu questionário padrão, acrescente as seções de origem, registro e abuso acima, e peça evidências em vez de declarações. As respostas dirão mais sobre uma rede do que sua página de preços.
Fontes e referências
- Departamento de Justiça dos EUA, botnet 911 S5 desmantelada (29 de maio de 2024): justice.gov
- Google Threat Intelligence Group, interrompendo a maior rede de proxy residencial (janeiro de 2026): cloud.google.com
- FBI, Cyber Criminal Proxy Services Exploiting End of Life Routers (maio de 2025): ic3.gov
- Cloud Security Alliance, Cloud Controls Matrix e CAIQ: cloudsecurityalliance.org
- Shared Assessments, questionário SIG: sharedassessments.org
- AICPA, relatório SOC 2: aicpa-cima.com
- ISO/IEC 27001:2022: iso.org
- GDPR, Artigos 28, 30 e 33: eur-lex.europa.eu
- NIST SP 800-52 Rev. 2: csrc.nist.gov