Auditoría de bases de datos

Cuando una persona hace un pedido en la tienda, la aplicación se conecta a la base de datos con su propia cuenta de servicio (app_pedidos en esta tabla). La auditoría dice que la cuenta de servicio leyó una fila, no qué persona estaba detrás. Para saberlo hay que unir con el registro de la aplicación, por hora o, mejor, por un identificador de petición que las dos escriban.

La cantidad de filas de una lectura es una medida útil: la aplicación toca una o pocas por petición, un informe toca cientos. Una cuenta de persona que lee cientos de miles de filas y desde un origen que no es el esperado es candidata a una pregunta, no a una acusación: puede ser un trabajo de migración mal avisado. Compara con la tabla cuentas_bd.

Conceder un permiso es una operación rara y con consecuencias: la cuenta que lo recibe puede leer más desde ese momento. Por eso se compara con la ventana de cambios aprobada (ventanas_de_cambio). Un permiso a las 3 de la madrugada, con una ventana de 10:00 a 12:00, no demuestra mala fe, pero sí pide un ticket que lo explique.

Los inicios de sesión fallidos de una cuenta de persona, seguidos de uno correcto, son un patrón conocido: alguien probó antes de acertar. También puede ser una persona que se equivocó de clave. Cuenta los fallidos y fíjate en el origen: la tabla cuentas_bd dice desde dónde se espera que trabaje cada cuenta.

Auditar todo produce un volumen que nadie lee y que cuesta almacenar. La auditoría útil se elige: las operaciones sobre las tablas con datos personales, los cambios de permisos y de estructura, los inicios de sesión de cuentas de persona y los fallos. Las lecturas que hace la aplicación en su rutina se miden con el registro de la aplicación.