El seguimiento de los cambios en los datos es una piedra angular del mantenimiento de registros y la integridad de los datos. En el mundo altamente regulado de la banca y las instituciones financieras, la capacidad de realizar un seguimiento preciso y reconstruir los cambios en los datos no es solo una buena práctica, sino un requisito normativo fundamental.

Las instituciones financieras manejan información de clientes y datos transaccionales en los que incluso una alteración menor y no documentada puede tener importantes implicaciones fiscales y legales. Este artículo explora el seguimiento de los cambios en los datos y examina su implementación práctica en las bases de datos Oracle y SQL Server.

¿Qué es el seguimiento de los cambios en los datos?

En lo que respecta a la auditoría, el mantenimiento de registros y la integridad de los datos, hay tres medidas que los clientes encuentran confusas:

• La auditoría de consultas tiene como objetivo registrar todas las solicitudes de acceso para ver los datos. Este tipo de auditoría tiene como objetivo combatir el robo de datos mediante la inspección y/o el control de quién accede a qué. Eso es algo en lo que podemos ayudarle, pero no entra dentro del alcance de este artículo.
• La auditoría de modificación de datos tiene como objetivo evitar cambios no autorizados mediante la inspección y/o el control de quién cambia los datos. Esto incluye insertar filas, eliminar datos o modificar registros. También podemos ayudarle con esto, pero no entra dentro del alcance de este artículo.
• El seguimiento de cambios en los datos tiene como objetivo rastrear el linaje de cada dato, lo que le permite deshacer los cambios. Ese es el tema de este artículo, y vamos a explicarlo un poco más.

Entonces, ¿en qué se diferencia el seguimiento de cambios en los datos de la auditoría de modificaciones?

Supongamos que tenemos una columna de saldo y alguien emite un SQL que lo cambia. Por ejemplo:

saldo = saldo + 1000

En la auditoría, registramos el SQL, quién lo ejecutó y cuándo. En el seguimiento de cambios en los datos, registramos los valores anteriores y nuevos del saldo (por ejemplo, 10 000 y 11 000). Esos valores no están en el SQL, ya que el SQL solo pidió añadir 1000 al valor anterior.

Si el SQL anterior modificó 10 filas, la auditoría registrará el SQL y el hecho de que modificó 10 filas. Sin embargo, la auditoría no enumerará qué filas cambiaron. El seguimiento de cambios en los datos registrará cada cambio, enumerando los 10 valores anteriores y los 10 nuevos.

Del mismo modo, si alguien eliminó varias filas, la auditoría registrará el SQL y el número de filas eliminadas. El seguimiento de cambios registrará los valores de cada fila eliminada.

El seguimiento de cambios en los datos es un requisito importante común en entornos altamente regulados, como bancos e instituciones financieras. Significa que conoceremos los valores antes y después de cada cambio. Esto es fundamental para llevar un registro detallado.

Las Regulaciones

El seguimiento de los cambios en los datos es la piedra angular de un buen mantenimiento de registros. Significa que conocemos el origen de cada dato y podemos revertirlo si alguien realiza un cambio no autorizado. Por lo tanto, es un requisito de todas las regulaciones de cumplimiento para bancos y otras instituciones financieras.

En los Estados Unidos, la FINRA (Autoridad Reguladora de la Industria Financiera) y el FFIEC (Consejo Federal de Examen de Instituciones Financieras) publican directrices para bancos e instituciones financieras.

Por ejemplo, la norma 4511 de la FINRA y la norma 17a-4 de la SEC en la que se basa tratan sobre el mantenimiento de registros electrónicos y exigen que el registro de auditoría incluya «todas las modificaciones y eliminaciones del registro o de cualquier parte del mismo» (17a-4(f)(2)(i)(A)(1)).

Existen directrices similares del BCE (Banco Central Europeo), la BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht) en Alemania, la ACPR (Autorité de contrôle prudentiel et de résolution) en Francia y la CNMV (Comisión Nacional del Mercado de Valores) en España.

En América Latina, los reguladores también tienen requisitos estrictos de la CNBV (Comisión Nacional Bancaria y de Valores) en México, la SFC (Superintendencia Financiera de Colombia) en Colombia, la SBS (Superintendencia de Banca, Seguros y Administradoras Privadas de Fondos de Pensiones) en Perú y muchos más.

BCBS 239 (Comité de Supervisión Bancaria de Basilea – Principios para la agregación eficaz de datos de riesgo y la presentación de informes de riesgo) es una guía bancaria global que influye en la mayoría de los reguladores de todo el mundo. La mayoría de las interpretaciones tienden a coincidir en que también exige este tipo de registro detallado.

Implementaciones

El seguimiento de los cambios en la base de datos es posible a través de diferentes mecanismos. Aunque cada base de datos es ligeramente diferente y se revisa a continuación, los principios generales y las ventajas e inconvenientes son similares.

Los desencadenadores son fragmentos de código que se ejecutan cuando se producen cambios en los datos. Uno de los métodos más sencillos para realizar un seguimiento de los cambios en una base de datos es utilizar un desencadenador que registre los cambios en una tabla de auditoría. Esto es algo que cualquier administrador de bases de datos puede implementar en cualquier base de datos.

Sin embargo, los disparadores tienen un gran inconveniente: un alto impacto en el rendimiento. El registro adicional en la tabla de auditoría forma parte de la transacción y la ralentiza considerablemente. El impacto típico es de al menos un 100 %, lo que hace que todo tarde el doble de tiempo.

Los desencadenantes ligeros son una variante de la implementación clásica de los desencadenantes. En lugar de una inserción, ejecutan un SQL ficticio que incluye los datos que han cambiado. El uso de un SQL ficticio reduce significativamente la sobrecarga de rendimiento. Core Audit Full Capture puede ver estos SQL internos en los desencadenantes, extraer los datos y registrarlos en el servidor Core Audit.

Una de las ventajas de los desencadenantes ligeros es que permiten correlacionar los cambios en los datos con el resto de los datos de auditoría, incluida la sesión exacta en la que se produjeron.

Los desencadenantes ligeros funcionarán en cualquier base de datos siempre que se disponga de la tecnología Core Audit Full Capture para recopilar los datos. Por ejemplo, la información de los desencadenantes ligeros de SQL Server almacenada en Core Audit puede tener este aspecto:

Time	2025/05/16 15:38:19
Session	714000000000002308 (link to Core Audit session)
Username	sa
Session Info	OSQL-32 local
Owner	test
Table	emp
Operation	UPDATE
New Values	id=1 first=’John’ last=’Doe’ salary=11000
Old Values	id=1 first=’James’ last=’Doe’ salary=10000

Los registros de rehacer o registros de transacciones son nombres diferentes para lo mismo. Se trata de registros que existen en todas las bases de datos y que registran cada cambio en los datos. Son una parte fundamental de la base de datos, ya que permiten la recuperación tras un fallo y la recuperación en un momento determinado, lo que garantiza la integridad de los datos.

Dado que estos registros siempre existen y registran cada cambio, se pueden extraer para obtener los cambios que se desean rastrear. La principal ventaja de extraer estos registros es que no forma parte del SQL y no ralentiza las transacciones de la base de datos.

La desventaja es que la extracción de estos registros aumenta el consumo de recursos en el servidor y, lo que es más importante, se limita a la información almacenada en los registros. Por ejemplo, algunas bases de datos registran la información de la sesión, mientras que otras solo registran el cambio en sí, sin ninguna referencia a quién lo ha realizado. A continuación se ofrece información específica para cada tipo de base de datos, incluidas las desventajas que dependen de la base de datos.

Registros de rehacer de Oracle

Puede controlar la información de los registros de rehacer de Oracle a través de la configuración de registro suplementario de Oracle. Si su objetivo es extraer cambios de los registros, debe, como mínimo, ejecutar este SQL:

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Sin ello, «update» a veces aparece como «delete» e «insert». Puede habilitar el registro adicional para registrar más información sobre claves primarias, otras columnas y mucho más.

Oracle Logminer le permite consultar los registros de rehacer en línea y archivados para extraer información de los registros de rehacer de Oracle.

Core Audit puede utilizar Logminer para consultar los registros de rehacer y almacenar la información en el servidor Core Audit. Por ejemplo, la información de Logminer almacenada en Core Audit puede tener este aspecto:

Time	2025/05/15 12:22:55
Session	68
Serial#	3787
Username	HRAPP
Session Info	login_username=HRAPP client_info= OS_username=bluecore Machine_name=WORKGROUP\BLUECORE2 OS_terminal=BLUECORE2 OS_process_id=5976:5220 OS_program_name=sqlplus.exe
Owner	HRAPP
Table	SALARIES
Operation	UPDATE
Redo SQL	update “HRAPP”.”SALARIES” set “SALARY” = ‘11000’ where “SALARY” = ‘10000’ and ROWID = ‘AABnEEAAEAAAAJUAAE’;
Undo SQL	update “HRAPP”.”SALARIES” set “SALARY” = ‘10000’ where “SALARY” = ‘11000’ and ROWID = ‘AABnEEAAEAAAAJUAAE’;
New Values	Salary=11000
Old Values	Salary=10000
Field

Registros de transacciones de SQL Server

Los registros de transacciones de SQL Server no contienen información de sesión, por lo que es imposible vincular los cambios a los usuarios que los realizaron.

Core Audit puede aprovechar el motor de replicación de SQL Server para extraer información de los registros de transacciones. Se trata de una extracción de alto rendimiento casi en tiempo real, pero ocupa el motor de replicación, por lo que no se puede utilizar la replicación de SQL Server junto con la extracción de registros de transacciones de Core Audit.

Por ejemplo, la información de los registros de transacciones de SQL Server almacenada en Core Audit puede tener este aspecto:

Time	2025/05/16 13:42:33
Owner	test
Table	emp
Operation	update
Redo SQL	update [dbo].[emp] set [salary] = 11000 where [id] = 1

SQL Server también cuenta con mecanismos integrados para extraer información de los registros de transacciones. Estos mecanismos también se limitan a la misma información disponible en los registros. El seguimiento de cambios es el mecanismo antiguo, y la captura de datos modificados (CDC) es el más reciente. CDC es mejor, pero aún así requiere cierta administración y mantenimiento regular, y los resultados no son fáciles de entender.

Resumen

El seguimiento de los cambios en los datos es vital para un buen mantenimiento de los registros y esencial en los sistemas bancarios y financieros.

Este requisito tiene múltiples opciones de implementación, y Core Audit las admite todas. Aunque la mejor opción puede depender de su entorno, muchos clientes consideran que las limitadas desventajas de los desencadenantes ligeros y la alta calidad de la información son convincentes.