La auditoría de base de datos, finalmente, es un proceso implementado por los auditores de sistemas con el fin de auditar los accesos a los datos, por lo general siguiendo bien una metodología basada en un checklist que contempla los puntos que se quieren comprobar o mediante la evaluación de riesgos potenciales.

En concreto, se realiza un examen de los accesos a los datos almacenados en las bases de datos con el fin de poder medir, monitorear y tener constancia de los accesos a la información almacenada en las mismas. Si bien el objetivo puede variar en función de la casuística, en todos los casos el fin último persigue, de uno u otro modo, la seguridad corporativa.

Activar auditoria en los intentos de acceso fallido.

Por defecto Oracle trae por defecto activada la auditoria, para comprobarla vamos a ejecutar el siguiente comando:

El comando audit es el encargado de administrar las distintas auditorias de oracle.

Auditorias de inicio de sesión

Cada intento de conexión con la base de datos por parte de un usuario, para iniciar dicha auditoria audit session, esto auditara tanto los intentos de fallos como los aciertos.

Si solo queremos auditar los fallos audit session whenever not successful;, en el caso de querer auditar las conexiones correctas audit session whenever successful;

Por lo tanto activamos la auditoria para controlar lo fallos en el inicio de sesión:

Ahora comprobamos el funcionamiento al conectarnos por ejemplo a system con una contraseña incorrecta:

Nos conectamos como system y miramos en el diccionario de datos dba_audit_session los fallos de inicio de sesion:

Activa la auditoria de las operaciones DML realizadas por SCOTT

Vamos a activar la auditoria sobre las operaciones DML sobre en el usuario SCOTT.

Ahora crearemos una tabla de ejemplo a la cual vamos a llamar “profesores”, vamos a insertar filas:

También podemos actualizar una fila:

Por ultimo podemos comprobar a eliminar una fila:

Nos conectamos como system y comprobamos las modificaciones realizadas:

Realiza una auditoría de grano fino para almacenar información sobre la inserción de empleados del departamento 10 en la tabla emp de scott.

Creamos un procedimiento para controlar la inserción de empleados:

Ahora insertamos una fila para comprobar su funcionamiento:

Comprobar funcionamiento

Para comprobar su funcionamiento nos conectamos como usuario system y comprobamos la auditoria:

Explica la diferencia entre auditar una operación by access o by session.

Si auditamos una operación By access la auditoria nos almacenará todas las acciones realizadas, sean acciones repetidas o no. En cambio, By session, nos almacenará un registro solo de una misma acción que hagamos repetidas veces.

Diferencias entre los valores db y db, extended del parámetro audit_trail de ORACLE

  • db: activa la auditoría y los datos se almacenarán en la taba SYS.AUD$ de Oracle.
  • db, extended: activa la auditoría y los datos se almacenarán en la taba SYS.AUD$ de Oracle. Además se escribirán los valores correspondientes en las columnas SQLBIND y SQLTEXT de la tabla SYS.AUD$.

Ver estado actual de audit_trail

Activamos el modo db extended

Al volver a realizar un show parameter audit;, nos volvera a devolver lo mismo que en el punto anterior por lo tanto debemos parar y arrancar la instancia:

Localizar en enterprise manager las posibilidades para realizar una auditoria

Una vez instalado oracle accedemos a un navegador y ponemos la siguiente dirección https://localhost:1158/em/

Nos dirigimos a Sevidor - Seguridad - Valores de Auditoría, una vez ahi podemos observar los dos tipos que hemos procesado en los pasos anteriores:

Conexiones fallidas

En esta pestaña podemos ver las conexiones fallidas:

Objetos auditados

Y en esta otra los objetos auditados:

Averigua si en postgres se pueden reailzar los primeros 3 puntos

Leyendo detalladamente la documentación de la web oficial de POSTGRES, he llegado a la conclusión de que las auditorias en POSTGRES no se realizan igual que en ORACLE, eso si podemos llegar a realizarlas a través, de procedimientos y trigger en PL/PGSQL

Averigua si en MySQL se pueden realizar los tres primeros apartados

En mySQL mediante trigger podemos auditar las acciones dml realizadas sobre una tabla.
Primero vamos a crear dos bases de datos, una donde guardaremos la tabla para registrar los logs y otra en la cual haremos modificaciones para que se registren en la tabla logs.

Base de datos proyectos

Creamos la base de datos en la cual vamos a realizar modificaciones:

Creamos un usuario con el nombre “juanlu” y le damos permisos:

Creamos una tabla en dicha base de datos, en la cual posteriormente vamos a añadir datos:

Base de datos auditorias

Creamos la base de datos de auditorias:

Creamos una tabla donde llegaran los datos auditados por el trigger que crearemos a continuación:

Y creamos el tigger correspondiente:

Ahora salimos de mysql y accedemos con el usuario creado anteriormente “root”.

Accedemos como “root” a la base de datos de auditorías y comprobamos la tabla creada anteriormente:

Averigua las posibilidades que ofrece mongoDB para auditar los cambios que va sufriendo el documento

MongoDB nos permite auditar ciertas tareas, para especificarle que eventos queremos auditar usamos la opción -auditFilter.

Por ejemplo, podemos auditar la creación de colecciones de la siguiente forma:

Con esta sentencia auditaríamos la creación o eliminación de colecciones indicando como salida un fichero en formato BSON

Averigua si en mongoDB se pueden auditar los accesos al sistema

Para auditar los accesos a la base de datos utilizamos la siguiente sentencia: