Un proveedor de proxies se sitúa en el camino de tu tráfico. Tus scrapers, trabajos de monitorización y suites de pruebas envían solicitudes a través de su red, a menudo con credenciales adjuntas, así que antes de aprobar un plan de proxies residenciales, tu equipo de seguridad querrá respuestas por escrito.
La mayoría de las empresas parten de un cuestionario estándar como el SIG de Shared Assessments o el CAIQ de la Cloud Security Alliance, un conjunto de preguntas de sí o no mapeadas a su Cloud Controls Matrix. Eso cubre lo básico de cualquier proveedor. Una red de proxies plantea algunas preguntas que esos cuestionarios no hacen, principalmente de dónde proceden las IPs y qué puede ver el proveedor. Esta lista cubre ambos aspectos, sección por sección, con lo que debería parecer una buena respuesta.
Esto es información general, no asesoramiento legal ni de auditoría.
Por qué un proveedor de proxies merece su propia revisión
Tres cosas distinguen a los proveedores de proxies de un proveedor de SaaS típico.
- Ven tu tráfico. En las solicitudes HTTPS, el proveedor ve los hosts a los que te conectas, el tiempo y el volumen. En HTTP plano ve el contenido.
- Tienen credenciales que pueden gastar dinero. Una contraseña de proxy filtrada permite que otra persona genere tráfico con tu cuenta.
- Las IPs de salida pertenecen a otra persona. Las IPs residenciales y móviles proceden de dispositivos de personas reales. Cómo se unieron esos dispositivos a la red es una cuestión legal y reputacional tanto para ti como para el proveedor.
El último punto no es teórico. En mayo de 2024, el Departamento de Justicia de EE. UU. anunció que había desmantelado la botnet 911 S5, un servicio de proxies residenciales asociado a más de 19 millones de direcciones IP únicas, creado mediante la propagación de malware a través de programas VPN e instaladores empaquetados. En mayo de 2025, el FBI advirtió de que servicios de proxies delictivos estaban instalando proxies en routers domésticos fuera de soporte. En enero de 2026, el Threat Intelligence Group de Google describió la interrupción de la red IPIDEA, cuyos nodos de salida observó siendo usados por más de 550 grupos de amenazas, y concluyó que las afirmaciones de obtención ética “deben estar respaldadas por pruebas transparentes y auditables de consentimiento del usuario”.
Sección 1: obtención de IPs y consentimiento
- ¿Cómo se obtienen las IPs residenciales y móviles: un SDK en aplicaciones asociadas, una aplicación de compartición de ancho de banda, acuerdos con ISP?
- ¿Puedes mostrar la pantalla de consentimiento que ve el propietario del dispositivo, y cómo la retira?
- ¿Auditáis las aplicaciones asociadas que incorporan vuestro SDK, y qué ocurre cuando una incumple las normas?
- ¿Compráis o revendéis IPs de otras redes?
Buena respuesta: un modelo de obtención con nombre, un flujo de consentimiento que puedes ver y un proceso de auditoría. Señal de alarma: “nuestras IPs se obtienen de forma ética” sin nada que lo respalde. Nuestra guía sobre cómo obtienen los proveedores las IPs residenciales explica los modelos y qué pruebas esperar.
Sección 2: qué ve y registra el proveedor
- ¿Qué datos de las solicitudes registráis: IP de origen, host de destino, marcas de tiempo, bytes, URLs completas?
- ¿Cuánto tiempo se conserva cada registro, y quién dentro de la empresa puede acceder a él?
- ¿Inspeccionáis o modificáis el tráfico, por ejemplo interceptando TLS?
- ¿Divulgaréis registros a terceros, y bajo qué proceso legal?
Buena respuesta: una lista campo por campo con períodos de retención y sin interceptación de TLS. Señal de alarma: “no registramos nada” por parte de un proveedor que factura por ancho de banda y destino, ya que tiene que contar algo. Nuestro artículo sobre si los proxies residenciales son seguros explica qué puede ver un proxy y qué no.
Sección 3: control de acceso y credenciales
- ¿Qué métodos de autenticación admitís: usuario y contraseña, lista blanca de IPs, ambos?
- ¿Podemos crear credenciales separadas por equipo, proyecto o entorno, y revocar una sin afectar a las demás?
- ¿El panel admite inicio de sesión único y autenticación multifactor, con roles?
- ¿Existe un registro de auditoría de los cambios en la cuenta y los restablecimientos de credenciales?
Buena respuesta: credenciales por proyecto con sus propios límites, y MFA en el panel. Los sub-usuarios separados por equipo o cliente también permiten ver qué trabajo usó qué.
Sección 4: cifrado en tránsito
- ¿Qué versiones de TLS aceptan el panel, la API y los endpoints de proxy?
- ¿Puede cifrarse la conexión desde nuestro cliente hasta el propio proxy?
Buena respuesta: TLS 1.2 o más reciente, con soporte para TLS 1.3. La guía del NIST para los sistemas federales de EE. UU. (SP 800-52 Rev. 2) establece ese mínimo, y es un listón razonable para cualquier proveedor.
Sección 5: auditorías y certificaciones
- ¿Disponéis de un informe SOC 2? ¿Tipo 1 o Tipo 2, de qué período, y qué categorías de Trust Services (seguridad, disponibilidad, integridad del procesamiento, confidencialidad, privacidad)?
- ¿Estáis certificados según ISO/IEC 27001:2022, y cuál es el alcance?
- ¿Cuándo fue vuestra última prueba de penetración independiente, y podemos ver un resumen?
Buena respuesta: un informe Tipo 2 reciente cuyo alcance incluya la infraestructura de proxies, no solo el sitio web de facturación. Un informe Tipo 1 solo indica que los controles estaban diseñados adecuadamente en un momento dado; el Tipo 2 añade una opinión sobre si funcionaron de forma eficaz durante un período. Señal de alarma: un certificado cuyo alcance excluye los sistemas que vas a usar.
Sección 6: protección de datos y subencargados
- ¿Firmaréis un acuerdo de tratamiento de datos? Según el artículo 28 del RGPD, un encargado actúa solo bajo instrucciones documentadas y necesita la autorización previa por escrito del responsable antes de contratar a otro encargado.
- ¿Qué subencargados usáis (alojamiento, registro, pagos), y en qué países?
- ¿Mantenéis el registro de actividades de tratamiento que exige el artículo 30 a los encargados?
Buena respuesta: un DPA estándar, una lista de subencargados publicada y un plazo de aviso para los cambios. Para el panorama más amplio del RGPD, consulta nuestra guía sobre proxies residenciales y cumplimiento del RGPD.
Sección 7: incidentes y abusos
- ¿Cómo y con qué rapidez nos informaréis de un incidente de seguridad que afecte a nuestra cuenta o datos? El artículo 33 del RGPD exige a los encargados notificar a los responsables “sin dilación indebida”, y a los responsables notificar a la autoridad en un plazo de 72 horas cuando sea posible.
- ¿Cómo gestionáis los reportes de abuso sobre el tráfico procedente de vuestra red?
- ¿Qué objetivos y usos bloqueáis, y verificáis a los clientes?
Buena respuesta: un contacto designado, un compromiso de notificación en el contrato y una política de uso aceptable por escrito que se aplica. Los controles de abuso también te protegen a ti: cada cliente comparte la reputación de las mismas IPs.
Sección 8: continuidad y salida
- ¿Qué disponibilidad os comprometéis a ofrecer, cómo se mide, y cuál es la compensación cuando no se cumple?
- Si dejáis de darnos servicio, ¿cómo recuperamos nuestros datos y cerramos las credenciales?
El cuestionario en una página
| Sección | Pide | Señal de alarma |
|---|---|---|
| Obtención | Flujo de consentimiento, modelo de obtención, auditorías de socios | ”Obtenido éticamente” sin pruebas |
| Registro | Lista de campos y retención por registro | ”No registramos nada” |
| Acceso | Credenciales por proyecto, MFA, registro de auditoría | Una contraseña compartida por empresa |
| Cifrado | TLS 1.2+, soporte para 1.3 | Panel o API en texto plano |
| Auditorías | SOC 2 Tipo 2 o ISO 27001 con alcance de proxy | Alcance que excluye la red |
| Protección de datos | DPA, lista de subencargados | Sin DPA para clientes de la UE |
| Incidentes | Aviso contractual, política de abuso | Sin contacto de seguridad designado |
La conclusión
Un proveedor de proxies merece la misma revisión que cualquier proveedor que toque tu tráfico, más algunas preguntas que solo plantean las redes de proxies. Envía tu cuestionario estándar, añade las secciones de obtención, registro y abuso anteriores, y pide pruebas en lugar de afirmaciones. Las respuestas te dirán más sobre una red que su página de precios.
Fuentes y referencias
- US Department of Justice, 911 S5 botnet dismantled (29 May 2024): justice.gov
- Google Threat Intelligence Group, disrupting the largest residential proxy network (January 2026): cloud.google.com
- FBI, Cyber Criminal Proxy Services Exploiting End of Life Routers (May 2025): ic3.gov
- Cloud Security Alliance, Cloud Controls Matrix and CAIQ: cloudsecurityalliance.org
- Shared Assessments, SIG questionnaire: sharedassessments.org
- AICPA, SOC 2 reporting: aicpa-cima.com
- ISO/IEC 27001:2022: iso.org
- GDPR, Articles 28, 30 and 33: eur-lex.europa.eu
- NIST SP 800-52 Rev. 2: csrc.nist.gov