Qué cubre el enmascarado por reglas en un ticket o un chat — y qué sigue visible

Pegar no es una copia. Son varias copias que ya no recuperas.

La gente trata el enmascarado como cortesía: cambiar el número completo por asteriscos para que el mensaje «se vea profesional». El daño empieza después del pegado. El almacén del ticket guarda el cuerpo. El chat guarda el mensaje. El monitor de errores raspa la pila. La reproducción de sesión graba el recuadro. La cola externalizada exporta otro archivo. Cambiar unos caracteres en tu pantalla no cambia las copias ya escritas. Un «editar el ticket» posterior solo edita la fila actual. El historial de búsqueda, los avisos por correo y el analytics de abajo a menudo siguen teniendo el original.

La hoja de trucos de registro de OWASP lo formula como una restricción de ingeniería, no como un consejo de estilo. Lista datos que deberían excluirse, enmascararse, sanitizarse, hashearse o cifrarse antes de aterrizar en un registro: datos personales sensibles e identificadores (información de salud, documentos de identidad), contraseñas de autenticación, tokens de acceso, claves criptográficas y otros secretos maestros, cuentas bancarias y datos del titular de una tarjeta. Dentro de una empresa, los tickets y los grupos de chat suelen funcionar como registros informales: fáciles de buscar, con permisos más flojos que producción y una retención más larga. Pegar las palabras del cliente tal cual es inventar un registro que OWASP dice que no deberías guardar.

HTTPS solo protege el salto frente a quien escucha en el camino. No borra el texto en claro que ya entregaste al siguiente sistema. La nota anterior decía lo mismo de las cadenas de consulta: acaban en el historial, el Referer y los registros de acceso. Un número en un párrafo es la misma clase de exposición. El vehículo es una frase en lugar de una URL. La pregunta antes de enviar no es «¿esta herramienta de tickets es segura?». Es «¿este párrafo lleva un campo que no debería salir de esta pestaña?».

Las reglas reconocen una forma y un dígito de control. No leen la frase.

El enmascarado por reglas es un trabajo estrecho. Una expresión regular encuentra un candidato. Un validador descarta los aciertos que fallan una comprobación pública. Una lista de prioridad resuelve solapamientos. El escáner no sabe que «Laura Méndez» es una persona ni que «déjalo en portería, calle Mayor 12» es una dirección. Sí sabe si once cifras parecen un móvil de China continental, si dieciocho pasan el control de un documento de identidad, si dieciséis pasan la prueba de Luhn que usan las tarjetas.

Eso es un camino distinto de «enviar el ticket a un modelo y que reescriba los datos personales». Un escaneo saliente a un modelo entrega el texto fuente a otro encargado del tratamiento. Un redactor en la pasarela hace lo mismo. Un escaneo por reglas puede quedarse en esta pestaña: la entrada no sale del navegador y la salida es una copia enmascarada. El precio es la cobertura. Los documentos fuera de la lista, los prefijos de token caseros y las cifras partidas por espacios se le escapan.

Un dígito de control baja los falsos positivos. No demuestra que «esta persona existe». Un documento chino de 18 cifras calcula el último carácter con GB 11643-1999 / ISO 7064 MOD 11-2: multiplica las 17 primeras cifras por los pesos 7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2; toma la suma módulo 11; y proyecta el resto sobre la tabla 10X98765432. El resto 2 da X, que representa 10. Un aprobado significa «esta cadena está bien formada». No significa que un registro civil tenga a esa persona. Las tarjetas usan el algoritmo de Luhn de ISO/IEC 7812: desde la derecha, se duplica cada segunda cifra, se resta 9 si el resultado es mayor que 9, y se acepta el número solo si el total es divisible por 10. La mayoría de las cadenas de 16 cifras que escribes al azar fallan Luhn. Una regla no debería tratarlas como tarjetas.

Un DNI español clásico (ocho cifras y una letra de control, según la tabla módulo 23) no entra en esa lista de validadores. El chip de la herramienta puede llamarse «DNI / doc» porque agrupa documentos con forma pública; los controles que sí comprueba son el de 18 cifras chino, el SSN estadounidense con forma AAA-GG-SSSS y el NINO británico. Un 12345678Z de manual —ficticio, de los que salen en cualquier tutorial— a menudo sobrevive. Eso no es un fallo de «el español no está soportado como idioma». Es el límite de una regla: solo nombra las formas que sabe comprobar.

Seis tipos de campo: qué puede nombrar una regla y cómo se ve la máscara

Los campos que una regla puede nombrar con cierta confianza son los que tienen un formato público más una segunda comprobación. La tabla sigue el orden en que suelen aparecer en un texto saliente. Las formas de máscara asumen el enmascarado «inteligente»: se queda un poco de cabeza o de cola y el medio se sustituye por asteriscos. Pasa a máscara completa cuando incluso las cifras que quedan deberían desaparecer.

Las reglas de teléfono tienen que aceptar tanto una racha continua de 11 cifras como números partidos por espacios, paréntesis o guiones. Un móvil continental que empieza por 1[3-9] y corre 11 cifras es una forma pública de numeración, no una tabla privada del operador. Los internacionales se cogen por el aspecto habitual de E.164: un + inicial y de 7 a 15 cifras detrás. Las cadenas demasiado cortas, o las que viven dentro de una racha más larga, deberían descartarse, o los pedidos y los números de seguimiento se tratan como teléfonos.

Un móvil español de nueve cifras sin prefijo —612345678 pegado de un tirón, sin espacios ni +34— a menudo no entra. La regla pide puntuación, o diez cifras al estilo norteamericano, o las once del móvil continental. El mismo número escrito +34 612 345 678 sí suele nombrarse: hay un + y hay espacios. Si tu cola de tickets está llena de móviles españoles «en crudo», no des por hecho que el chip Teléfono los va a tapar todos.

En documentos, un número chino de 18 cifras también necesita un código de región distinto de cero, un año de nacimiento en los 1900 o los 2000, y un mes y un día de calendario reales. Un Social Security Number estadounidense escrito AAA-GG-SSSS tiene exclusiones oficiales: área 000, 666 o un 9 inicial; grupo 00; serial 0000. Un National Insurance Number británico son dos letras, seis cifras y una A–D final, y excluye prefijos como BG y GB. Esas pruebas suben la confianza de que la cadena parece un documento. No son prueba de que la persona exista.

En tarjetas, el sector de pagos separa «cuántas cifras pueden verse en una pantalla» de «cómo se trunca un PAN almacenado». El PCI Security Standards Council, en su nota sobre BIN de 8 cifras, reitera un tope de visualización que las marcas siguen aceptando: las seis primeras y las cuatro últimas. Un rol que solo necesita las cuatro últimas para una devolución de llamada debería ver solo las cuatro últimas. Compartir un ticket no es adquirir una tarjeta. Dejar por defecto las cuatro últimas es el hábito saliente más seguro. Eso no es una afirmación de certificación PCI. Solo dice que pegar las 16 cifras en un chat ya rebasa el límite habitual de pantalla.

Una máscara de correo que oculta solo la parte local y deja el dominio entero sigue diciéndole al destinatario en qué empresa trabaja esa persona. Las reglas de claves dependen de prefijos públicos: los tokens clásicos de GitHub usan ghp_ más 36 caracteres; los de grano fino, github_pat_. Los identificadores de clave de acceso de AWS IAM suelen empezar por AKIA más 16 caracteres. Las claves secretas en vivo de Stripe usan sk_live_. Esos prefijos existen para que los SDK y los escáneres los reconozcan —y por eso una regla puede cogerlos. Un token casero sin prefijo estable, o una cadena partida como «g h p guion bajo…», es texto ordinario para el escáner.

Las IP se cogen por rangos decimales con puntos (cada octeto 0–255) para que una cadena de versión como 1.2.3 tenga menos probabilidad de coincidir. Las demos y los canarios deberían usar rangos de documentación, no direcciones de producción. RFC 5737 reserva 192.0.2.0/24, 198.51.100.0/24 y 203.0.113.0/24 y dice que no deben aparecer en el enrutado público. Las demos de correo deberían usar example.com, de los nombres reservados en RFC 2606, no una empresa real.

Un documento y una tarjeta pueden reclamar la misma racha de cifras

Un documento de 18 cifras es todo dígitos (el último carácter puede ser X). Si alguien alimenta un documento numérico a la regla de tarjeta, Luhn a veces aprueba. Cuando ambas reglas se sientan sobre un mismo párrafo, hace falta una prioridad, o el mismo tramo se enmascara dos veces —o se enmascara con la forma equivocada.

Un orden estable es: documento antes que claves, claves antes que teléfonos, teléfonos antes que correos, correos antes que tarjetas, tarjetas antes que IP. Las razones son concretas. Primero el documento, para que un número de identidad de 18 cifras no se trague como tarjeta. Un prefijo de clave es más distintivo que «cifras que parecen un teléfono». Las cifras dentro de un correo no deberían cortarse otra vez por la regla de teléfono. La IP es la red más ancha, así que corre la última y tiene menos probabilidad de comerse cadenas de versión o números con puntos de un pedido. En un solapamiento, quédate el acierto de mayor prioridad, o el más largo.

Si apagas «DNI / doc» y dejas «Tarjeta» encendido, debería ocurrir lo contrario: esa racha de cifras puede tratarse como tarjeta. Eso es esperable cuando depuras una regla. No es la política de envío por defecto. El valor por defecto es los seis tipos encendidos, y luego un pase humano para nombres y direcciones que las reglas no tocan.

Los asteriscos no son anonimización, y tampoco una seudonimización terminada

El RGPD traza una línea que el enmascarado no cruza. El considerando 26 dice que el reglamento no se aplica a la información anónima: la que no se refiere a una persona física identificada o identificable, o a datos personales convertidos en anónimos de forma que la persona ya no sea identificable. También dice que hay que considerar todos los medios que razonablemente puedan usarse para identificar a alguien, incluidos los que el responsable o un tercero podrían usar. El artículo 4.5 define la seudonimización como el tratamiento de datos personales de manera que ya no puedan atribuirse a una persona concreta sin información adicional, y esa información adicional debe guardarse por separado bajo medidas técnicas y organizativas. La AEPD lo resume sin rodeos: el conjunto seudonimizado sigue bajo el RGPD; el anónimo, no. Los asteriscos en medio de un número no figuran en el reglamento como un control terminado.

El enmascarado inteligente deja a propósito una cola comprobable: las cuatro últimas de un teléfono, las cuatro últimas de una tarjeta, el dominio del correo, el prefijo de la clave. Si el ticket también tiene un nombre, una calle o un ID interno de cliente, esas cuatro cifras a menudo bastan para pasar a la persona de «identificable» a «identificada». Eso es, como mucho, un paso hacia la seudonimización. No es anonimización. Una máscara completa sustituye el acierto por el mismo número de asteriscos, lo que quita un empalme. Aún deja la longitud, la posición y la frase de alrededor. La frase puede seguir diciendo «llame al titular de la cuenta» o «el escaneo del DNI está en el adjunto».

Por eso «pasamos las reglas» no puede escribirse como «este párrafo puede entrar en una base de conocimiento pública» ni «esto satisface una certificación». La página de la herramienta no afirma marcas de cumplimiento RGPD ni otras. La frase exacta es: las formas conocidas se sustituyeron por una máscara; las formas desconocidas no se tocaron; si una persona concreta sigue siendo identificable es un juicio que haces tú a partir del contexto.

Lo que las reglas no ven suele ser la frase que provoca el incidente

Una lista de fallos es más útil que una lista de aciertos. Primero: identificadores directos sin forma estable de cifras —nombres de pila, calles, empleadores, notas clínicas, el colegio de un menor. No hay una «tabla nacional de nombres» que una expresión regular pueda consultar, y los etiquetadores de nombres en la nube siguen marcando mal palabras ordinarias. Segundo: secretos reescritos: «seis uno dos tres cuatro cinco seis siete ocho», cifras de ancho completo, una partícula o un carácter de ancho cero metido en medio, una captura en lugar de texto. Una expresión regular ve la secuencia actual de puntos de código. No oye el número que una persona dictó.

Tercero: secretos sin prefijo público. Una URL de base de datos, un JWT de tres partes, un token= casero, una cookie de sesión de un chat o de una app interna —ninguno de esos está en la lista corta de ghp_ / AKIA. Cuarto: adjuntos y texto enriquecido: una cabecera de Word, una columna oculta de hoja de cálculo, un teléfono en la firma del correo, una capa dentro de un PDF. Las reglas solo escanean el texto plano que pegaste en el recuadro. Quinto: secretos semánticos: el importe de un contrato no publicado, un escrito de vulnerabilidad, una queja en las propias palabras del cliente. No son formas de PII. Reenviarlos igual causa daño.

Hay también el «acertó, pero el acierto equivocado». Los números de pedido, los IDs de paquete y las extensiones de mesa a veces parecen teléfonos. Una versión de documento 10.20.30.40 parece IPv4. Los dígitos de control y el filtro de «ninguna cifra a los lados» quitan algunos. No los quitan todos. Por eso un panel de resultado debería nombrar tipos de acierto y recuentos, no solo devolver un párrafo con estrellas. Estás comprobando si el tipo es el correcto, no si hay suficientes asteriscos.

Para quien trabaja en español hay dos fallos especialmente frecuentes. El DNI clásico de ocho cifras más letra, y el NIE con letra inicial y letra final, no coinciden con los validadores de 18 cifras, SSN o NINO: a menudo se quedan en claro aunque el chip diga «DNI / doc». El móvil de nueve cifras sin +34 y sin espacios hace lo mismo con el chip Teléfono. Si tu demostración solo usa un 202-555-0100 o un 13800138000, habrás visto aciertos. No habrás visto el ticket real de tu cola.

Compruébalo aquí: un canario en el recuadro y luego una búsqueda en Red

«Enmascarado local, no se sube nada» no puede demostrarse como eslogan. Cuatro cosas que puedes ver en una sentada: qué tipos se nombraron, si la forma de la máscara es la correcta, si una frase que querías dejar en paz sigue ahí, y si el texto fuente salió como dato de negocio.

Construye un canario que no contenga ninguna identidad real. Para un teléfono norteamericano, usa una forma reservada a ficción como 202-555-0100. Para la forma de móvil continental, 13800138000 es un dummy publicado en anuncios y documentación —no sustituyas el tuyo. Para un móvil español, escribe +34 612 345 678 con espacios (es una forma, no un abonado). Correo: canario@example.com. IP: 203.0.113.10. Tarjeta: 4111111111111111. Clave: un token desechable con prefijo público, por ejemplo ghp_ más 36 caracteres que inventes y luego trates como quemados. No uses el DNI de nadie. Si quieres ver el límite del documento español, pega un 12345678Z de manual y etiquétalo «ficticio»: lo esperable es que sobreviva.

Mete el canario en un ticket ordinario: «El usuario canario@example.com no puede entrar. Devolver llamada al 202-555-0100, al 13800138000 o al +34 612 345 678. IP de origen 203.0.113.10. Tarjeta de prueba 4111111111111111. Token ghp_…. Envío a Calle Mayor 12, Madrid. DNI 12345678Z.» Tras la pasada, el correo, los teléfonos con forma reconocida, la IP, la tarjeta y el token deberían aparecer en los recuentos y convertirse en máscaras como en la tabla. «Calle Mayor 12, Madrid» debería sobrevivir sin cambios. El 12345678Z también, si las reglas son las de forma pública descritas arriba. Eso es el límite de la regla, no un fallo. Si la calle también queda enmascarada, no estás ante un conjunto puro de reglas, o las reglas se ampliaron, y los falsos positivos se inspeccionan aparte.

Luego abre Red (Network) en las herramientas de desarrollo, activa Conservar registro y busca las cadenas únicas del canario: 13800138000, canario@example.com o el token falso completo. No deberían aparecer en la línea, la consulta o el cuerpo de una petición XHR o Fetch, ni en la consulta o el cuerpo de analytics. Un nombre de script estático que contenga «privacy» o «redact» es esperable. Que el texto fuente salga como campo de negocio es un fallo.

1. Escribe un ticket con un teléfono de ficción, un correo example.com, una dirección RFC 5737, un PAN de prueba y un token falso con prefijo. Deja a propósito una calle en castellano y, si quieres ver el límite, un DNI de manual.
2. Tras la pasada, mira los tipos de acierto: los campos de número o cuenta reconocidos deberían nombrarse; la calle —y a menudo el DNI clásico— deberían seguir en el resultado.
3. Busca en Red el original del canario. Cualquier petición de negocio que acierte es la entrada saliendo de esta pestaña.

La prueba es estrecha. En esta pasada, las formas conocidas se volvieron máscaras, la frase de la dirección se dejó en paz y el texto fuente no salió de esta pestaña como campo HTTP observado. No demuestra que una extensión no haya leído el recuadro. No demuestra que un ticket real no vaya a fallar. Después de cambiar de navegador o de conmutar una regla, vuelve a correr el canario.

Practica el límite en una página de enmascarado que se abre sin cuenta

Si quieres una página que deja a la vista los interruptores de tipo y los recuentos de acierto, empieza por el modo Ocultar datos de Limpiar enlaces en MakePwd. Se abre sin cuenta y sin inicio de sesión. El análisis y la máscara se ejecutan en esta pestaña. Según las notas del producto, el texto fuente no se envía como petición ni se escribe en analytics. Los seis tipos comprobables son los de arriba: teléfono, DNI / doc, tarjeta, correo, API key e IP. El enmascarado inteligente es el valor por defecto; puedes pasar a máscara completa. Un pegado está limitado a 512 KB. La página dice los límites en lenguaje llano: no reconoce todos los formatos de documento, no puede demostrar que el texto cumpla un régimen de cumplimiento, y el correo saliente importante sigue necesitando un pase humano.

Practica solo con canarios. Tras una pasada, mira tres sitios a la vez: los recuentos por tipo, si la calle del resultado se dejó en paz, y si Red contiene el original. Los recuentos responden «¿nombró los tipos correctos?». La calle responde «¿dónde se detiene la regla?». Red responde «¿se subió?». Cuando los tres pasan, puedes decirle a un compañero: enmascaré estos tipos, sé que la dirección sigue ahí y busqué el canario en el cable.

Los parámetros de seguimiento de una URL son otro trabajo. Si el ticket también pegó una URL completa que aún tiene utm_source o fbclid, quita primero la consulta por clave y luego trata los números del cuerpo. Los pasos están en Qué datos de seguimiento envías al pegar un enlace UTM completo en el chat. Si después del enmascarado aún tienes un secreto que debe llegar intacto, envíalo una vez con un enlace de un solo uso y deja la clave en el fragmento # de la URL. Para un archivo entero, cífralo en este dispositivo con Cifrar archivo a .lock / .enc (un archivo, como máximo 5 GB) y luego usa un disco o el correo. Ninguno de esos pasos exige una cuenta.

Preguntas frecuentes

Tras los asteriscos, ¿sigue siendo un dato personal?

Casi siempre sí. El considerando 26 del RGPD deja fuera del reglamento solo la información anónima: la que no se refiere a una persona identificada o identificable. El artículo 4.5 define la seudonimización como un tratamiento que aún necesita información adicional, guardada por separado, para atribuir el registro. Un teléfono que conserva las cuatro últimas cifras, o un correo que conserva el dominio, más el contexto del ticket, a menudo se pueden volver a unir. El enmascarado por reglas, como mucho, se acerca a una seudonimización. No es una anonimización.

¿El enmascarado por reglas sustituye una revisión humana?

No. Las reglas reconocen formas y dígitos de control, no el significado. Nombres, calles, cifras dictadas, capturas y tokens reescritos se cuelan. Revisa tú el texto importante antes de enviarlo. La página de la herramienta no afirma certificación RGPD ni otras.

¿Al enmascarar se sube el texto original?

Según las notas del producto, el análisis y la máscara se ejecutan en esta pestaña. El texto fuente no se envía en el cuerpo de una petición ni se escribe en analytics. Puedes buscar en Red (Network) un canario de ficción para comprobar esta ejecución. Eso no demuestra que una extensión no haya leído el recuadro.

¿Cómo envío un secreto que el enmascarado no termina de cubrir?

Usa las reglas para teléfonos y documentos sueltos. Para una contraseña entera, material no publicado o una clave que debe llegar intacta, envíala una vez con un enlace de un solo uso y deja la clave en el fragmento # de la URL. Para un archivo entero, cífralo en este dispositivo con Cifrar archivo a .lock o .enc y luego usa el correo o un disco.

Tres cosas que recordar antes del próximo envío

Primero: pegar es copiar. El ticket, el chat, el monitor y la exportación guardan cada uno una fila. Editar la página actual no reclama el texto que ya salió. Segundo: las reglas solo cazan campos con formato y comprobables. Nombres, calles, cifras dictadas y tokens caseros son un pase humano, y las colas que quedan más el contexto aún pueden identificar a una persona. Tercero: mira tres sitios —tipos de acierto, la frase que querías dejar, y una búsqueda en Red del canario.

Si la siguiente pregunta es si la consulta de una URL completa debería viajar con el envío, lee Qué datos de seguimiento envías al pegar un enlace UTM completo en el chat. Si necesitas demostrar que el texto en claro no salió de esta pestaña como dato de negocio, lee Cifrar en el navegador: cómo comprobar que el original no salió de este dispositivo. Esta nota solo dibuja una línea que puedes escribir en una conclusión: qué puede hacer el enmascarado por reglas con el cuerpo de un ticket, y qué no debes afirmar que hizo.