Auditoría de la base y registros de consultas

Las bases escriben varios registros distintos, y cada uno responde a otra pregunta. El registro de errores del motor cuenta lo que falló. El registro de consultas lentas cuenta lo que tardó. El de la nube (por ejemplo, el de actividad de la cuenta) cuenta quién cambió la configuración del servicio. El registro de auditoría de la base cuenta quién se conectó, desde qué dirección, qué sentencia ejecutó, sobre qué objeto y, según la configuración, cuántas filas tocó.

Una auditoría bien montada manda sus registros a un destino que no controla quien administra la base, con una retención acorde a la política. Si el administrador puede borrar el registro de lo que hizo, la auditoría no protege de él.

Abre el laboratorio con ls y lee configuracion-de-auditoria.txt y politica-de-auditoria.txt. La política exige para los datos Restringidos auditoría activada, destino fuera de la propia base y retención de 365 días. Una base Restringida no está auditada en absoluto.

Ahora el registro: registro-ln-pedidos.jsonl tiene una entrada por línea, con la hora (UTC), el usuario, el origen, la acción, el objeto y las filas. Las conexiones normales vienen de la red de la aplicación y de la oficina. Con grep puedes filtrar por usuario o por acción. Una conexión de madrugada llama la atención porque viene de un origen que no es ninguno de los dos.

Quien revisa no solo dice «hubo una lectura masiva»: dice cuánta. Con las lecturas (SELECT) de la tabla de envíos hechas por ese usuario desde esa dirección, suma las filas que devolvieron. Las lecturas pequeñas del mismo usuario desde otro origen no cuentan para esta cifra.

La auditoría de cambios de permisos es la que cuenta lo que se dejó atrás. En el mismo bloque de actividad de madrugada hay una sentencia que concede un permiso de lectura sobre la tabla de envíos a otro usuario, y ese usuario aparece después leyendo. Lee la línea con la acción de permisos.