Registros y privacidad de los proxies
Un sitio web puede ver una IP de proxy en lugar de la tuya, mientras que el proveedor de proxies sabe qué cuenta de cliente abrió la conexión. Son dos perspectivas diferentes de la misma solicitud. Cambiar la dirección visible para un sitio no hace invisible tu actividad para la empresa que la transporta.
Registrar la actividad del proxy significa conservar registros de cómo se utiliza el servicio: conexiones, destinos, volúmenes de tráfico, errores y, en algunos productos, solicitudes y respuestas. Este artículo explica prácticas del sector. Como ocurre con otras políticas de los proveedores de proxies, los detalles dependen del servicio. La sección final describe cómo gestiona ProxyCompass los datos del servicio.
Qué puede ver un proxy al conectarse a un sitio HTTPS
Considera una subasta ilustrativa: tu aplicación envía una puja de 180 € a https://bid.example/lot/218/bids. Con un túnel proxy normal, HTTPS protege el intercambio entre tu aplicación y el sitio web mediante el protocolo de seguridad TLS. El proveedor puede ver la IP del cliente que se conecta, el destino bid.example:443 y la hora de conexión; también puede medir el volumen de datos transferidos. La URL completa, el lote seleccionado, la acción del cliente, el importe de la puja, las cookies y la respuesta de la subasta permanecen dentro de HTTPS. Con una verificación correcta del certificado y sin interceptación, el proveedor no puede leerlos.
El dominio puede revelarse antes de que empiece ese intercambio cifrado. HTTP CONNECT suele indicar el host y el puerto de destino. SOCKS5 puede recibir un nombre de dominio o una dirección IP; si la aplicación pide al proxy que se conecte por nombre de dominio, el proxy lo conoce. Una IP de destino por sí sola no identifica necesariamente un sitio concreto, ya que varios pueden compartirla.
HTTP sin cifrar es diferente: sus cabeceras, la ruta de la página y el contenido están disponibles para el proxy que transporta la solicitud. SOCKS5 no añade cifrado a un intercambio de aplicación que de otro modo no está cifrado. HTTPS a través de SOCKS5 conserva su protección HTTPS; HTTP a través de SOCKS5 sigue siendo legible.
El propio sitio web recibe la solicitud descifrada. Puede leer las credenciales, las cookies y los campos de formulario que le envías, y reconocer una cuenta existente después de un cambio de IP del proxy. HTTPS protege los datos en tránsito; no los oculta a su destinatario previsto.
Por qué algunos proveedores de proxies exigen instalar un certificado
Algunos proveedores exigen que los clientes confíen en su propio certificado raíz para ciertos servicios que inspeccionan tráfico HTTPS. Este requisito procede del proveedor, no del sitio visitado, y no se aplica a todos los proxies. ProxyCompass no exige que los clientes instalen su certificado raíz.
En un túnel HTTPS normal, el proxy no puede leer el contenido de las solicitudes y respuestas. Si un servicio necesita comprobar los datos enviados, aplicarles reglas o analizar las respuestas de los sitios, necesita acceder a ese contenido. La inspección HTTPS proporciona ese acceso: el servicio descifra el tráfico que lo atraviesa.
Un certificado raíz es un documento digital que una aplicación utiliza como base para confiar en otros certificados. Añadir el certificado del proveedor al conjunto de confianza permite a la aplicación aceptar certificados de sitios web emitidos por ese proveedor. En el modo de inspección, el proxy presenta uno de estos certificados en lugar del original del sitio. Sin la confianza correspondiente, la verificación normal del certificado falla.
El proxy establece dos conexiones cifradas independientes: una con tu aplicación y otra con el sitio web. Entre ambas, puede leer las solicitudes y respuestas. En el ejemplo ilustrativo de la subasta, esto expone la dirección completa https://bid.example/lot/218/bids, el número de lote, la puja enviada de 180 €, las cookies y la respuesta que acepta la puja. El proveedor puede ver lo que hace realmente el cliente en el sitio.
Este requisito depende del producto, el modo y el método de acceso concretos. Puede aparecer en servicios que automatizan el acceso a sitios web o cuando se activa el análisis de tráfico en un gestor de proxies. La etiqueta «residencial» o «centro de datos» por sí sola no indica si se aplica. A veces solo necesitas facilitar el certificado a un script; no hace falta instalarlo para todo el sistema.
Instalar un certificado no dirige por sí mismo todo el tráfico a través del proveedor. El acceso descrito aquí se produce cuando las solicitudes pasan por un servicio con la inspección activada. Un certificado utilizado solo para verificar la propia dirección HTTPS del proxy tampoco significa que se descifre el contenido de la conexión con el sitio de destino.
Poder leer datos y guardarlos en registros son cuestiones distintas. El certificado ayuda a explicar quién puede acceder al contenido de la conexión, pero no dice nada sobre los plazos de conservación o el acceso del personal. Desactivar la verificación del certificado tampoco oculta los datos a un servicio que los descifra.
Las API de extracción de datos y los navegadores remotos reciben el contenido
Con una API de extracción de datos, encargas al servicio una tarea: abrir esta URL y devolver la página o los datos extraídos. El servicio establece su propia conexión con el sitio y recibe la respuesta en formato legible. Puede hacerlo sin pedirte que instales un certificado, porque él es el cliente que obtiene la página.
Un navegador alojado por el proveedor funciona en sus equipos. Las páginas, las cookies y las sesiones del navegador se procesan allí, aunque esté cifrada la conexión que utilizas para controlarlo. Según el producto, tu tarea puede incluir URL completas, cabeceras personalizadas, cookies, datos de formularios e instrucciones para interactuar con una página.
Este acceso es necesario para realizar la tarea. No demuestra que se archive cada página ni que los empleados lean habitualmente los resultados de los clientes. Sí significa que importan las reglas del producto para tratar las tareas y los resultados: una promesa que cubre túneles proxy normales puede no cubrir su API o navegador alojado.
Para una empresa, la información sensible puede ser una lista de productos supervisados, una secuencia de búsquedas o un conjunto de objetivos de investigación. Aunque todas las páginas de origen sean públicas, la recopilación y la forma de utilizarla pueden revelar un proyecto comercial.
Qué puede aparecer en los registros del proxy
Un proveedor puede mantener varios tipos de registros. No tienen por qué almacenarse juntos: una conexión puede remitir a un número de cuenta, mientras que el correo, el pedido y el pago se guardan en otros sistemas.
| Tipo de registro | Contenido posible |
|---|---|
| Conexiones | Hora de inicio y duración, IP que se conecta, IP del proxy utilizada para llegar al sitio, dirección o dominio de destino, puertos y errores de conexión. |
| Uso | Bytes transferidos, número de conexiones y totales de una cuenta o período de facturación. |
| Cuenta y acceso | Datos de registro, inicios de sesión, IP de cliente autorizadas, cambios de credenciales, pedidos y referencias de pago. |
| Soporte e incidentes | Tickets, archivos adjuntos, reclamaciones de sitios web y registros de la investigación. |
| Solicitudes y resultados | URL completas, cabeceras, cuerpos de solicitud o páginas obtenidas, cuando el producto puede leerlos y su configuración permite registrarlos. |
Son categorías posibles, no una lista que recopile necesariamente todo proveedor. Un servicio puede procesar un valor para abrir una conexión sin conservarlo. También puede mantener un contador total de tráfico sin guardar un registro permanente de cada destino.
La IP del cliente de un registro es la dirección del dispositivo o intermediario que se conecta directamente al proxy. Con una conexión directa, suele ser la IP pública del cliente; si hay otro intermediario delante, puede ser la dirección de ese intermediario.
Qué cubre realmente una declaración de ausencia de registros
«No almacenamos el contenido de tu tráfico» puede coexistir con registros de dominios de destino, horas de conexión y uso. «Solo conservamos totales de uso» describe una modalidad diferente. Una etiqueta breve de «sin registros» no indica cuál de esas promesas hace el proveedor.
Lee la declaración teniendo en cuenta los datos y el producto mencionados. ¿Excluye el contenido de las páginas, los registros de conexiones individuales, el historial de destinos o las tres cosas? ¿Cubre solo el funcionamiento normal o también los registros de diagnóstico? ¿Qué permanece en los sistemas de cuenta, pagos, soporte y abusos?
Una declaración de uso exclusivo de RAM describe un método de almacenamiento. No indica si la información se envía a otro sistema antes de vaciar la memoria. Del mismo modo, el almacenamiento cifrado protege los registros frente a ciertos tipos de acceso no autorizado; no significa que el proveedor no pueda leerlos.
Las etiquetas privado, dedicado o élite no responden a estas preguntas. Describen otras propiedades del proxy. Un sitio de comprobación de IP puede inspeccionar la solicitud que llega a ese sitio, pero no verificar las prácticas internas de registro del proveedor.
Cómo ayudan los registros con los fallos, la facturación y los avisos de abuso
Los registros de conexión pueden distinguir un fallo de autenticación de un destino que no respondió. Los totales de uso ayudan a explicar un cupo de tráfico consumido. Un cambio repentino en los patrones de conexión también puede revelar un script defectuoso o un uso inesperado de una cuenta.
Una distinción útil es la conexión satisfactoria al proxy frente a la solicitud satisfactoria al sitio web. Una respuesta CONNECT correcta confirma que se abrió un túnel. Dentro de él, el sitio puede seguir devolviendo un CAPTCHA o un HTTP 403. Un túnel normal no lee esa respuesta cifrada, por lo que su resultado de conexión y el resultado del sitio en la aplicación pueden diferir.
El sitio de destino tiene otra perspectiva. Si recibe intentos de adivinar contraseñas, puede comunicar las solicitudes, la IP del proxy, la hora y otros detalles de conexión. Si el proveedor tiene suficientes registros correspondientes, puede asociar el aviso a la cuenta utilizada en esas conexiones. Conocer una ruta de solicitud a partir de la reclamación del sitio no significa que el proveedor descifrara el tráfico HTTPS original.
Una IP de proxy compartida no impide esa asociación. Los registros detallados pueden vincular la conexión de un cliente autenticado con la conexión realizada al sitio. Las marcas de tiempo precisas, incluidos los milisegundos cuando se registran, los puertos y el destino ayudan a distinguir conexiones simultáneas. Las IP rotativas también pueden seguir vinculadas a la misma cuenta. Cambiar o compartir una dirección no borra los registros del proveedor.
Cuánto tiempo permanecen los registros
Los registros de conexión, las facturas, los tickets de soporte y los resultados de extracción de datos pueden tener plazos de conservación diferentes. Una política útil explica esos plazos por categoría o indica las condiciones utilizadas para decidir cuánto tiempo se necesita cada categoría.
El historial visible en un panel no es necesariamente todo el plazo de almacenamiento. Si la interfaz solo muestra actividad reciente, eso indica lo que puedes ver allí. No demuestra cuándo se eliminan los registros internos, los archivos de incidentes o las copias de seguridad.
Cerrar una cuenta no borra necesariamente todos los registros asociados. Los registros de facturación o incidentes pueden permanecer cuando existe un motivo legal para conservarlos. La eliminación de los sistemas activos y la caducidad de las copias de seguridad también pueden ocurrir en momentos distintos.
Sustituir el nombre de un cliente por un ID de cuenta no convierte los registros en anónimos si la empresa conserva la relación entre ese ID y el cliente. La pregunta pertinente es si la información restante todavía puede vincularse a una cuenta o persona.
Quién puede acceder a la información
La existencia de registros y el permiso para leerlos son cuestiones diferentes. El soporte puede necesitar errores de conexión, el área financiera necesita registros de pago y un equipo de seguridad puede necesitar información de un incidente. La política de privacidad debe explicar el acceso y la divulgación; los controles de seguridad deben limitar el acceso a quienes lo necesitan.
Un revendedor y la empresa que opera la red de proxies pueden conservar partes distintas del registro. Los procesadores de pago, las empresas de alojamiento y las plataformas de soporte también pueden tratar ciertos datos. Comprueba qué empresas participan y qué información reciben.
El país de una IP de proxy no determina por sí solo dónde se conservan los registros de clientes ni qué normas legales se aplican al proveedor. También importan la empresa contratante, sus acuerdos de tratamiento y la legislación aplicable. Un proveedor puede tener que revelar información conservada a las autoridades en virtud de una obligación legal vinculante. Las condiciones aplicables deben leerse en su política; no existe una única regla mundial para todos los servicios de proxies.
Elegir condiciones de privacidad para tu carga de trabajo
En un proyecto que deba mantener el contenido de las páginas dentro de tu propia aplicación, importa distinguir entre un túnel HTTPS normal y un servicio gestionado de obtención de páginas. Un túnel puede mantener el contenido ilegible para el intermediario mientras expone los metadatos de conexión. Una API gestionada puede reducir tu trabajo de desarrollo, pero recibe la tarea y el resultado.
Los metadatos de destino también pueden importar. Una lista de dominios, el horario de las visitas y su volumen pueden revelar qué empresas o mercados estudia un equipo. Decide si esa información es sensible antes de considerar suficiente el cifrado del contenido para proteger el proyecto.
Por último, considera lo que tú mismo envías al soporte. Un archivo de configuración o una captura de red pueden contener contraseñas de proxies, tokens de acceso, cookies y cuerpos de solicitud que nunca aparecieron en los registros de tráfico del proveedor. Elimina los secretos ajenos al problema antes de compartir material de diagnóstico.
Antes de empezar a trabajar, determina qué puede leer el producto elegido, qué conserva, cuándo se eliminan esos registros y quién puede recibirlos. Esos detalles hacen útil una política de privacidad para una tarea real.