Buenas prácticas para servicios de red residencial basados en consentimiento

1. Propósito

Los servicios de red residencial (a veces denominados proxies residenciales, uso compartido de ancho de banda o redes de acceso web) enrutan el tráfico de clientes empresariales a través de dispositivos de consumo cuyos propietarios han aceptado participar. Bien ejecutado, este modelo se sustenta en el consentimiento informado del consumidor por un lado y en una verificación rigurosa de los clientes por el otro. Mal ejecutado, expone a los consumidores a un uso oculto de sus recursos y expone a internet a tráfico abusivo.

Este documento recomienda los estándares mínimos que debería cumplir cualquier operador de este sector, en una forma apta para su adopción por legisladores, reguladores y organismos de normalización. Está organizado en torno a cuatro pilares:

• Consentimiento e información al consumidor
• Protección de los datos del consumidor
• Salvaguardas técnicas a nivel de dispositivo
• Verificación de clientes y prevención del abuso

Concluye con recomendaciones sobre cómo debería comprobarse y gobernarse la conformidad.

2. Consentimiento e información al consumidor

Un operador no debería incorporar un dispositivo sin una decisión informada, afirmativa y reversible de su propietario.

Requisitos recomendados:

• Aceptación afirmativa. La incorporación requiere una acción explícita del usuario. Sin casillas premarcadas. Sin incluir la participación de forma silenciosa en una instalación, una actualización o una función no relacionada.
• Igual prominencia. Las opciones de aceptar y rechazar se presentan con el mismo peso visual. Rechazar no debe degradar la funcionalidad esencial de la aplicación anfitriona más allá de retener cualquier incentivo por participar.
• Información en el punto de decisión. Antes de incorporarse, el usuario ve en lenguaje claro: qué significa participar, que el tráfico de terceros saldrá a través de su conexión y qué recursos del dispositivo se utilizan (ancho de banda, CPU, electricidad).
• Términos enlazados. Enlaces directos a los términos de licencia y a la política de privacidad del operador en la propia pantalla de consentimiento.
• Revocable en cualquier momento. Baja con un solo clic desde la configuración del dispositivo o de la aplicación, con efecto inmediato.
• Nuevo consentimiento ante cambios sustanciales. Si la naturaleza de la participación cambia de forma sustancial, se debe volver a solicitar el consentimiento a los usuarios existentes, en lugar de migrarlos de forma silenciosa.

Requisitos de la aplicación anfitriona. Cuando la red se integra mediante un SDK en una aplicación de terceros, debería exigirse a la aplicación anfitriona que: divulgue la integración en sus propios términos de servicio y aviso de privacidad, presente el flujo de consentimiento completo sin modificaciones e identifique por su nombre al operador de la red. El operador debería seguir siendo responsable de forma independiente ante el usuario final con independencia de la relación de integración, y debería revisar cada integración conforme a estos requisitos antes de su lanzamiento.

3. Protección de los datos del consumidor

Requisitos recomendados:

• Minimización de datos. Recopilar únicamente lo que la operación requiere. Apropiado: IP de sesión, identificador anónimo del dispositivo, ubicación aproximada (a nivel de ciudad), especificaciones del dispositivo, estadísticas de ancho de banda.
• Recopilación prohibida. Historial de navegación, uso de aplicaciones, contenido de archivos, comunicaciones personales, ubicación GPS precisa.
• Límite de conservación. Los datos del lado del participante se depuran conforme a un calendario breve y fijo (60 días es un referente alcanzable en el sector), conservando los registros operativos solo durante el tiempo que exijan los controles de seguridad y la ley.
• Sin uso secundario. Los datos de los participantes no se venden ni se utilizan para fines ajenos a la operación de la red.

4. Salvaguardas técnicas a nivel de dispositivo

La sesión de un cliente nunca debe poder utilizarse para alcanzar la propia red privada del dispositivo participante, su interfaz de loopback o los endpoints de metadatos de la nube. Sin esto, el tráfico del cliente podría sondear la red doméstica del participante o robar credenciales de infraestructura coubicada.

Requisitos recomendados:

• Bloqueo de salida a rangos privados. Bloquear el tráfico del cliente hacia loopback, rangos privados RFC 1918, direcciones link-local y de metadatos de la nube, espacio de NAT de nivel de operador y equivalentes en IPv6 (link-local, unique-local).
• Aplicación consciente de la resolución. Bloquear una solicitud si cualquier dirección resuelta por DNS cae dentro de un rango protegido. Validar directamente los literales de IP. Desencapsular y validar las direcciones IPv6 mapeadas a IPv4. Rechazar si la resolución falla.
• Aplicación del lado del servidor como mínimo. Dado que el software cliente desplegado se actualiza con lentitud (los ciclos de las tiendas de aplicaciones de TV y móviles pueden retrasarse meses o años), la aplicación del lado del servidor que cubra todo el tráfico debería ser obligatoria. El bloqueo del lado del cliente es una valiosa defensa en profundidad, pero no puede ser el único control, ya que los clientes antiguos permanecen en circulación.
• Restricciones de puertos. El tráfico del cliente se limita a los puertos web estándar. Los puertos de correo (SMTP y relacionados) y los puertos de administración remota (SSH, RDP, SMB, Telnet) se bloquean en la capa de red, ya que permiten spam, ataques a credenciales y movimiento lateral.

5. Controles de abuso en tiempo de ejecución

La verificación se realiza una vez; los controles de abuso funcionan de forma continua. Un cliente aprobado puede aun así comportarse indebidamente, resultar comprometido o sufrir el robo de sus credenciales. Los operadores deberían aplicar límites en tiempo de ejecución que hagan que la red sea estructuralmente resistente al abuso, con independencia de quién la utilice.

Requisitos recomendados:

• Límites de rendimiento de ancho de banda por dispositivo. Acotar el tráfico que transporta cualquier dispositivo participante, protegiendo la conexión del participante e impidiendo que un solo dispositivo sea utilizado como arma.
• Limitación de tasa. Límites de tasa de solicitudes por cliente y por sesión que hagan que el abuso volumétrico (participación en DDoS, credential stuffing, ráfagas agresivas de scraping) resulte inviable a nivel de red, y no meramente prohibido sobre el papel.
• Detección de anomalías de tráfico. Vigilar patrones compatibles con el abuso: picos repentinos de volumen, ráfagas con alta tasa de errores contra un único objetivo, patrones de solicitudes distribuidas que coincidan con firmas de ataque conocidas.
• Respuesta automatizada. Limitar o suspender automáticamente la sesión del cliente infractor ante una anomalía, sin perjuicio para el dispositivo participante.
• Interruptor de emergencia. El operador debe poder detener de inmediato el tráfico por cliente y por dispositivo.

6. Verificación de clientes y respuesta ante el abuso

Las protecciones del lado del consumidor significan poco si cualquiera puede comprar acceso de forma anónima.

Requisitos recomendados:

• Conocer al cliente antes del acceso a producción. Incorporación por fases en la que el acceso completo a la red se concede solo después de: verificación de la identidad individual o empresarial, revisión del caso de uso conforme a una política de uso aceptable publicada, revisión de la titularidad real para perfiles de mayor riesgo, validación del pago y cribado de sanciones (OFAC, EU, UK, UN).
• Niveles de escrutinio reforzado. Revisión adicional para revendedores, sectores sensibles (servicios financieros, sanidad, gobierno), exposición jurisdiccional de alto riesgo y casos de uso próximos a los límites de la política.
• Usos prohibidos publicados. Como mínimo: denegación de servicio, distribución de malware, CSAM (con notificación obligatoria al NCMEC o a la autoridad nacional aplicable), spam, credential stuffing, escaneo no autorizado y cualquier actividad ilícita.
• Aplicación gradual y documentada. Respuesta escalonada por gravedad, desde la advertencia hasta la terminación inmediata sin plazo de subsanación, con preservación de pruebas y remisión a las fuerzas del orden cuando corresponda.
• Responsabilidad en la cadena contractual. Los clientes son contractualmente responsables de la conducta de sus propios usuarios posteriores, de modo que la responsabilidad subsiste tras la reventa.
• Proceso ante las fuerzas del orden. Recepción documentada con revisión de validez, jurisdicción y alcance; entrega de ámbito estrictamente delimitado; notificación al participante y al cliente cuando esté legalmente permitido.

7. Cómo debería comprobarse y gobernarse la conformidad

Para los organismos de normalización y los esquemas de certificación, la forma en que se comprueba un estándar importa tanto como lo que este exige. Principios recomendados:

• Pruebas basadas en resultados y neutrales respecto a la implementación. Juzgar la conformidad según si el resultado prohibido puede producirse realmente (por ejemplo: ¿puede una solicitud a un rango privado bloqueado salir efectivamente de un dispositivo participante?), y no según qué mecanismo lo impide. Los criterios que imponen un mecanismo concreto permiten que la arquitectura de un operador se convierta en el estándar.
• Pruebas reproducibles, no listas comerciales. La conformidad se mide mediante la prueba documentada y reproducible del propio esquema. Nunca mediante la inclusión en una lista de bloqueo o un feed de reputación controlado por un participante del mercado.
• Garantías procesales antes de conclusiones adversas. Notificación previa a la publicación, un plazo de comentarios y derecho a repetir la prueba. Sin inclusión adversa por un resultado impugnado antes de agotar la apelación.
• Gobernanza neutral de las listas. Cualquier criterio o lista de bloqueo debe ser de titularidad neutral, versionado y con un proceso documentado de impugnación por parte del operador. Ningún participante o proveedor de detección la cura en solitario.
• Divulgación de conflictos y abstención. Todo participante que venda servicios competidores de detección o puntuación, o que se encuentre en litigio activo con otro participante, divulga el conflicto y se abstiene de juzgar a esa parte.

8. Lista de verificación resumida