Direcciones IP y tus formularios

El RGPD define los datos personales en el artículo 4(1) como información sobre una persona identificada o identificable, y cita «un identificador en línea» como una forma de identificar a una persona. El considerando 30 pone las direcciones IP como ejemplo de ese identificador.

El Tribunal de Justicia resolvió el caso más complejo en Breyer contra Bundesrepublik Deutschland (C-582/14), dictado el 19 de octubre de 2016. Un responsable de un sitio web normalmente no puede saber quién está detrás de una dirección IP dinámica. El Tribunal sostuvo que la dirección sigue siendo un dato personal para el responsable cuando dispone de medios legales para identificar a la persona con datos adicionales que tiene el proveedor de internet, por ejemplo a través de las autoridades tras un ataque. El caso se resolvió con la antigua Directiva 95/46, pero la definición que interpretó pasó al RGPD.

En la práctica, para quien es titular de un formulario: trata las direcciones IP que recogen tus formularios como datos personales y diseña en consecuencia.

• Registros del servidor web y del proxy, de la página que muestra el formulario.
• El backend del formulario, que a menudo guarda la dirección junto con el envío para limitar la frecuencia de peticiones y comprobar abusos.
• Una CDN o un cortafuegos delante de cualquiera de ellos.
• Un CAPTCHA o una comprobación de bots, con la que el navegador del visitante se comunica directamente.
• Analítica en la página, si la hay.

Cada uno es una copia distinta, con su propio periodo de conservación y, a menudo, su propia ubicación. Al redactar tu registro de actividades de tratamiento, enuméralos todos, no solo el backend del formulario.

Un atajo habitual es guardar un hash SHA-256 de la dirección. Parece ilegible, pero el espacio IPv4 tiene solo unos 4.300 millones de direcciones. Calcular el hash de todas ellas requiere poco tiempo con hardware normal, y después cada hash almacenado vuelve directamente a su dirección.

Un hash con clave (un HMAC con una clave secreta) cierra esa brecha para cualquiera que no tenga la clave. En términos del RGPD, eso es seudonimización según el artículo 4, apartado 5: los datos ya no pueden vincularse a una persona sin información adicional que se conserve por separado. El considerando 26 es explícito: los datos seudonimizados siguen siendo datos personales. Por tanto, un hash con clave es una buena medida de protección con arreglo a los artículos 25 y 32, no una salida del reglamento.

La protección contra spam y abusos es el motivo habitual por el que un formulario conserva una dirección IP. El considerando 49 establece que el tratamiento estrictamente necesario para la seguridad de la red y de la información es un interés legítimo, lo que apunta al artículo 6, apartado 1, letra f. Esa base exige una prueba de ponderación, y en ella el equilibrio favorece conservar lo mínimo durante el menor tiempo posible.

Un límite de peticiones necesita la dirección durante minutos, no meses. Si nada más depende de ella, hay poca razón para mantener la IP vinculada a un envío durante el mismo tiempo que el propio mensaje. Sea cual sea tu elección, indícalo en tu aviso de privacidad.

• Hash con clave al recibir. La dirección de quien envía se somete a un hash con HMAC-SHA-256 y una sal secreta del lado del servidor antes de almacenar nada. La dirección original no se escribe en disco.
• Usado para el límite de peticiones. El hash es lo que cuenta el límite de peticiones por IP y por formulario. Por defecto son 50 envíos por minuto por dirección, y puedes establecer un límite más bajo o más alto para cada formulario.
• Eliminación a las 24 horas. En el Centro de privacidad, un propietario o administrador del espacio de trabajo puede configurar un formulario para que elimine el hash 24 horas después de cada envío. Una limpieza se ejecuta cada 15 minutos. Sin esa opción, el hash se conserva tanto tiempo como el envío.
• Formularios alojados anónimos. Un formulario alojado configurado como anónimo no almacena ningún hash de IP junto a sus envíos.
• Registros del servidor. Los registros de acceso del servidor web solo conservan una dirección truncada, tal como se describe en la política de privacidad.

Hay una excepción fuera de los servidores de Formward. Si activas Cloudflare Turnstile en un formulario, el navegador del visitante se comunica con Cloudflare, una empresa estadounidense, que ve datos del desafío como la dirección IP y señales del navegador, pero no las respuestas del formulario. Está desactivado salvo que lo habilites, y aparece en el registro de subencargados del tratamiento. El honeypot _gotcha y el límite de peticiones funcionan sin él.