RGPD y autenticación de los emails: dos ángulos que no hay que confundir

RUA frente a RUF: el buen ajuste del lado de la privacidad

La consecuencia práctica es clara, y coincide con la posición cada vez más extendida en el ecosistema: dar prioridad a los informes agregados, y tratar los informes forenses con extrema prudencia, o renunciar a ellos por defecto. La distinción entre ambos, y por qué el RUF se desaconseja hoy, se desarrolla en informes DMARC rua frente a ruf y, desde el ángulo específico de la privacidad, en la confidencialidad de los informes forenses DMARC.

El razonamiento RGPD es el de la minimización: no recoger más que lo necesario para la finalidad perseguida. Ahora bien, esa finalidad — asegurar el dominio y cartografiar sus fuentes de envío — se satisface por completo con los informes agregados. El forense añade poco valor de seguridad mientras multiplica la exposición en datos personales. El cálculo se inclina, por tanto, masivamente a favor del agregado solo.

Minimización, conservación, encargados del tratamiento

Cuando una organización explota informes DMARC, algunos principios del RGPD se aplican directamente:

• Base jurídica y finalidad. El tratamiento reposa sobre el interés legítimo del responsable en asegurar su dominio y sus comunicaciones — una base sólida, siempre que la finalidad siga siendo la seguridad y no un uso desviado.
• Minimización. Preferir el agregado, evitar el forense, y no extraer más campos de los necesarios.
• Plazo de conservación. Fijar un plazo proporcionado y aplicarlo: los informes de varios años ya no tienen utilidad de seguridad y se convierten en un pasivo. Un nivel de conservación explícito, purgado automáticamente, es la buena práctica.
• Encargados del tratamiento. Cuando el análisis de los informes se confía a un proveedor, este se convierte en encargado del tratamiento en el sentido del RGPD: hay que encuadrar la relación contractualmente y verificar dónde se alojan los datos. El alojamiento en la Unión, bajo derecho europeo, simplifica considerablemente el análisis de conformidad.

Estas mismas exigencias alimentan el registro de actividades de tratamiento y se documentan de una vez por todas — un trabajo que enlaza directamente con la lógica de prueba de un SGSI ISO 27001.

El doble beneficio: conformidad y protección de las personas

Hay una elegancia en este cruce. Al llevar su dominio a p=reject, una organización responde a su obligación de seguridad y protege directamente a los interesados — clientes, usuarios, empleados — contra los fraudes que explotarían su identidad para sacarles datos. La conformidad y la protección real apuntan, aquí, en la misma dirección, lo que dista mucho de ser siempre el caso en materia regulatoria.

Es también por eso que las entidades sujetas a NIS2 o a otros regímenes sectoriales ganan tratando DMARC como un control común: el mismo esfuerzo satisface la obligación de seguridad del RGPD, la exigencia de resiliencia regulatoria y la protección concreta de las personas.

Un ejemplo concreto

Sirva de ejemplo una pyme cuyo dominio se ha quedado en p=none. Un atacante envía a su base de clientes un email mostrando la dirección auténtica del servicio de atención al cliente, anunciando una «actualización de seguridad de la cuenta» y remitiendo a una página de recogida de credenciales. Varios clientes introducen su información. Desde el punto de vista del RGPD, la empresa se enfrenta a una posible violación que afecta a los datos de sus clientes, explotando su propio dominio como vector — una situación incómoda en la que es a la vez víctima y responsable del tratamiento interpelado sobre sus medidas de seguridad.

El mismo escenario, con el dominio en p=reject, termina de otro modo: el mensaje falsificado es rechazado en la entrega, no alcanza nunca las bandejas, y no hay ni recogida, ni violación, ni notificación. Es la demostración más tangible de que la autenticación de email es una medida de seguridad en el sentido del artículo 32, y no una abstracción técnica.

DMARC y la notificación de violaciones

El RGPD impone notificar ciertas violaciones de datos a la autoridad de control en un plazo de 72 horas, y a veces informar a los interesados. Ahora bien, una campaña de suplantación exitosa de un dominio puede ser una violación, o desencadenar una: credenciales sacadas a los clientes, datos personales extraídos por un falso mensaje en nombre de la organización, es exactamente el tipo de evento que activa la obligación de notificación, con su cortejo de investigación, comunicación y tensión regulatoria.

El razonamiento enlaza con el de la resiliencia operativa: cada suplantación que DMARC bloquea aguas arriba es una violación que no ocurre. Reducir estructuralmente la capacidad de un atacante de hacerse pasar por la organización es reducir la frecuencia de los incidentes notificables — un beneficio de conformidad concreto, medible en incidentes evitados, no solo en principio.

Documentar el tratamiento en el registro

Cuando una organización explota informes DMARC, el análisis constituye un tratamiento que hay que inscribir en su registro en virtud del artículo 30. La buena noticia: es un tratamiento simple de describir. Finalidad — seguridad del dominio y cartografía de las fuentes de envío legítimas. Categorías de datos — esencialmente direcciones IP de origen y metadatos de autenticación para el agregado, y eso es todo si el perímetro se limita a él. Base jurídica — interés legítimo en asegurar las comunicaciones. Plazo — un nivel de conservación acotado, purgado automáticamente. Destinatarios — el eventual proveedor de análisis, encuadrado como encargado del tratamiento.

Cumplimentado una vez, este registro se reutiliza tal cual como pieza de prueba en un dispositivo ISO 27001, que comparte la misma exigencia de documentación. No hay duplicación del esfuerzo: se describe un tratamiento limpio y se presenta bajo los dos marcos.

¿Hace falta una evaluación de impacto (EIPD)?

La pregunta vuelve a menudo. Para los informes agregados solos, la exposición en datos personales es baja y la finalidad de seguridad está bien encuadrada: una evaluación de impacto relativa a la protección de datos no suele ser necesaria, aunque una evaluación rápida del riesgo sigue siendo buena higiene. El cálculo cambia en cuanto se activan los informes forenses, que pueden acarrear datos personales de terceros en volumen y con una granularidad mucho más intrusiva. Es una razón más, en el terreno de la privacidad esta vez, para atenerse al agregado por defecto — el propio principio de minimización que estructura todo este razonamiento.

Medir la exposición

El punto de partida es el diagnóstico gratuito. Un dominio pasa por nuestro analizador DMARC gratuito para saber si es actualmente suplantable, y nuestra política de privacidad detalla cómo aplicamos nosotros mismos estos principios al análisis de dominios. La postura de un sector entero también puede compararse en el Observatorio DMARC.

Encuadrar como es debido la autenticación — aplicación de la política del lado de la seguridad, ajuste prudente de los informes del lado de la privacidad — es exactamente lo que facilita Thomas, el RSSI virtual: identifica las fuentes de envío a partir de los informes agregados, sin depender jamás del forense, y guía el dominio hasta p=reject. Análisis DMARC gratuito de un dominio · explorar el Observatorio · empezar con Thomas.