latentAlcance del resultado grabado
Masker transfiere filas bancarias sintéticas mediante un productor y un consumidor. La ejecución guardada usa un productor Pi y un consumidor emulado. Ese detalle delimita lo que realmente se probó.
fintechP contiene el origen, fintechT el destino y bus.mq.messages transporta peticiones y respuestas. Los clientes deben cargarse antes de direcciones y cuentas; después vienen tarjetas y transacciones. Enmascarar correctamente y conservar la integridad relacional son criterios de aceptación separados.
Arquitectura y punto de control
Petición del consumidor → buzón → consulta en fintechP
→ maskRow(entity, row) → resultado para el modelo → buzón
→ inserción en fintechT → marca de avance
query_masked transforma las filas antes de devolverlas al modelo productor. El proceso de base de datos ve los originales: memoria, credenciales, extensiones y registros siguen dentro de la revisión. Enmascarar solo la respuesta final dejaría expuesto el resultado original de la herramienta.
El hook del productor permite mailbox_wait, mailbox_send y query_masked. Bloquea otras herramientas del entorno, incluidas shell y archivos. No constituye un aislamiento del sistema operativo. El manifiesto identifica los archivos inspeccionados y sus hashes.
Información que permanece
| Campo | Información conservada o reemplazo |
|---|---|
| Apellido | Primera letra |
| SSN | Últimos cuatro dígitos |
| Correo | Primer carácter y dominio |
| Nacimiento | Año; mes y día cambian a 1 de enero |
| Tarjeta | Primeros y últimos cuatro dígitos |
| CVV | Asteriscos |
Las reglas conservan utilidad y también información. Una fecha reducida al año no permite calcular la edad exacta cerca del cumpleaños. Una tarjeta enmascarada puede incumplir restricciones numéricas o Luhn del destino. Las transacciones pasan sin cambios y los atributos retenidos permiten posibles cruces con otros datos.
La implementación copia la fila antes de reemplazar campos. Una columna nueva pasa sin cambios si la política no la contempla. Cada cambio de esquema requiere revisión; una lista explícita de columnas de salida daría un comportamiento más conservador. Es enmascaramiento selectivo, no una prueba de anonimato.
Entrega, reintentos y marcas de avance
El buzón usa FOR UPDATE SKIP LOCKED. Cada trabajador puede saltar una fila bloqueada por otro. Eso coordina la toma de mensajes, pero no vuelve atómicos la inserción en destino y el acuse en otra base.
Una caída después de insertar y antes de confirmar puede repetir el lote. Confirmar primero puede perder datos si falla la inserción. Hay que revisar identificadores de lote, restricciones únicas, idempotencia y reinicio antes de afirmar entrega exactamente una vez. El máximo de 200 filas limita una respuesta, no el acceso acumulado.
La carga incremental usa el identificador local más alto. Detecta nuevas inserciones, pero omite cambios a IDs anteriores y eliminaciones. La visibilidad fuera de orden también necesita revisión. No es captura general de cambios.
Verificación independiente
La comprobación guardada encontró cero coincidencias con patrones de SSN y números de 16 dígitos sin formato. Solo cubre esas expresiones en esos mensajes; no detecta todos los formatos ni determina si los atributos retenidos son sensibles.
Empieza por la función pura y datos sintéticos: nulos, identificadores cortos, correos malformados, columnas extra y cada entidad. Compara originales con salidas además de usar expresiones regulares. Luego valida conteos y llaves foráneas. Interrumpe la entrega después de insertar y antes del acuse para revisar repetición. Estos son pasos propuestos, no nuevas pruebas aprobadas.
El artículo técnico explica el control guardado y enlaza la implementación. Conserva manifiesto y archivos: la revisión identifica HEAD al recolectar, mientras los hashes identifican los bytes inspeccionados.