Saltar a contenido

Auditoría sobre los SGBDs

Las auditorías se refieren al proceso de monitoreo y registro de actividades en una base de datos Oracle para garantizar la seguridad, la conformidad y la integridad de los datos.

Para empezar con la práctica, lo primero será iniciar la instancia de Oracle.

sqlplus / as sysdba
startup;
set serveroutput on;
COLUMN name FORMAT A30;
COLUMN value FORMAT A20;

1. Activa desde SQL*Plus la auditoría de los intentos de acceso exitosos al sistema. Comprueba su funcionamiento.

Lo primero que haremos, será comprobar si las auditorías están activadas en nuestra base datos, para ello podemos ejecutar la siguiente sentencia.

SELECT name, value FROM v$parameter WHERE name like 'audit_trail';

Untitled

Como podemos ver, el valor es NONE, esto quiere decir que las auditorías están deshabilitadas, para activarlas necesitaremos ejecutar la siguiente sentencia.

ALTER SYSTEM SET audit_trail=db scope=spfile;

Para aplicar los cambios es necesario reiniciar la instancia.

SHUTDOWN
STARTUP

Si consultamos de nuevo el atributo audit_trail, podemos comprobar que ahora tiene el valor DB, esto quiere decir que las auditorías han sido activadas.

Untitled

Para comprobar que ha funcionado, voy a provocar un intento fallido de inicio de sesión con un usuario.

Hecho esto, podemos habilitar una auditoría para los accesos exitosos.

AUDIT CREATE SESSION BY ACCESS;

Untitled

Me loguearé ahora con cualquier usuario a la base de datos y compruebo con la siguiente sentencia si se han registrado los accesos, en este caso solo me interesa conocer el nombre de usuario, pero podemos obtener mucha mas informacion de DBA_AUDIT_SESSION.

select username from dba_audit_session where action_name = 'LOGON';

Untitled

Para deshabilitar la auditoría, simplemente ejecutamos esta sentencia y reiniciamos la instancia.

ALTER SYSTEM SET AUDIT_TRAIL=NONE SCOPE=SPFILE;

2. Realiza un procedimiento en PL/SQL que te muestre los accesos fallidos

junto con el motivo de los mismos, transformando el código de error almacenado en un mensaje de texto comprensible. Contempla todos los motivos posibles para que un acceso sea fallido.**

Función que contiene los mensajes de error.

CREATE OR REPLACE FUNCTION DevolverMensaje(p_error NUMBER)
RETURN VARCHAR2
IS
    mensaje VARCHAR2(200);
BEGIN
    CASE p_error
        WHEN 911 THEN
            mensaje := 'El dato ingresado contiene caracteres no válidos';
        WHEN 1004 THEN
            mensaje := 'Acceso denegado: no tienes permisos suficientes para realizar esta operación';
        WHEN 1017 THEN
            mensaje := 'Nombre de usuario o contraseña inválidos';
        WHEN 1045 THEN
            mensaje := 'Permiso denegado: no tienes el privilegio de crear una sesión';
        WHEN 28000 THEN
            mensaje := 'La cuenta está bloqueada debido a intentos de inicio de sesión fallidos';
        WHEN 28001 THEN
            mensaje := 'La contraseña ha caducado y debe ser cambiada';
        WHEN 28002 THEN
            mensaje := 'La contraseña caducará pronto, por favor cámbiala';
        WHEN 28003 THEN
            mensaje := 'La contraseña no cumple con los requisitos mínimos de complejidad';
        WHEN 28007 THEN
            mensaje := 'No puedes reutilizar una contraseña previamente utilizada';
        WHEN 28008 THEN
            mensaje := 'Contraseña anterior no válida';
        WHEN 28009 THEN
            mensaje := 'La conexión a SYS debe realizarse a través de SYSDBA o SYSOPER';
        WHEN 28011 THEN
            mensaje := 'La contraseña caducará pronto, por favor cámbiala';
        WHEN 28009 THEN
            mensaje := 'La contraseña original no ha sido proporcionada';
        ELSE
            mensaje := 'Contacta con el administrador para obtener más información sobre el error';
    END CASE;
    RETURN mensaje;
END DevolverMensaje;
/

Procedimiento principal.

CREATE OR REPLACE PROCEDURE MostrarAccesosFallidos
IS
    CURSOR c_accesos IS
        SELECT username, returncode, timestamp
        FROM dba_audit_session
        WHERE action_name='LOGON'
        AND returncode != 0
        ORDER BY timestamp;
    v_motivo VARCHAR2(200);
BEGIN
    DBMS_OUTPUT.PUT_LINE(CHR(10)||CHR(9)||CHR(9)||'-- ACCESOS FALLIDOS --');
    DBMS_OUTPUT.PUT_LINE(CHR(10)||CHR(9)||'USUARIO'||CHR(9)||CHR(9)||'FECHA'||CHR(9)||CHR(9)||CHR(9)||'DESCRIPCION');
    DBMS_OUTPUT.PUT_LINE(CHR(9)||'----------------------------------------------------------------');
    FOR acceso IN c_accesos LOOP
        v_motivo := DevolverMensaje(acceso.returncode);
        DBMS_OUTPUT.PUT_LINE(CHR(10)||CHR(9)||acceso.username||CHR(9)||CHR(9)||TO_CHAR(acceso.timestamp,'YY/MM/DD DY HH24:MI')||CHR(9)||v_motivo);
    END LOOP;
END MostrarAccesosFallidos;
/

Ejecuto el procedimiento despues de realizar un par de intentos fallidos.

Untitled

3. Activa la auditoría de las operaciones DML realizadas por SCOTT. Comprueba su funcionamiento.

Activamos la auditoría con la siguiente instrucción.

AUDIT INSERT TABLE, UPDATE TABLE, DELETE TABLE BY C##SCOTT BY ACCESS;

Untitled

Posteriormente, me conecto como usuario SCOTT y realizo algunas operaciones.

connect C##SCOTT/TIGER
CREATE TABLE PRUEBA(NOMBRE VARCHAR2(20),APELLIDO VARCHAR2(30));
INSERT INTO PRUEBA VALUES('Fabio','Gonzalez del Valle');
INSERT INTO PRUEBA VALUES('Alvaro','Perez Cano');
UPDATE PRUEBA SET APELLIDO = 'Gonzalez' WHERE NOMBRE='Fabio';
DELETE FROM PRUEBA WHERE NOMBRE = 'Alvaro';

Una vez hechas las operaciones DML, podemos comprobar la auditoría ejecutando la siguiente sentencia como usuario SYS.

SELECT obj_name, action_name, timestamp FROM dba_audit_object WHERE username='C##SCOTT';

Untitled

De esta forma, quedará un registro de todas las operaciones DML ejecutadas por el usuario C##SCOTT

4.Realiza una auditoría de grano fino para almacenar información sobre la inserción de empleados con sueldo superior a 2000 en la tabla emp de scott.

Con este bloque conseguimos que se registren las inserciones de la tabla emp cuyo salario sea mayor a 2000.

BEGIN
    DBMS_FGA.ADD_POLICY (
        object_schema => 'C##SCOTT',
        object_name   => 'EMP',
        policy_name   => 'practica_auditoria',
        audit_condition => 'SAL > 2000',
        statement_types => 'INSERT'
    );
END;
/

Untitled

Ahora, me conectaré como usuario SCOTT y realizaré inserciones en la tabla afectada.

connect C##SCOTT/usuario

INSERT INTO EMP VALUES (9001,'Fabio','Jefe',null,sysdate,2500,1700,20);

INSERT INTO EMP VALUES (9002,'Jose','Profe',null,sysdate,7200,400,50);

INSERT INTO EMP VALUES (9003,'Rafa','Profe',null,sysdate,800,null,20);

INSERT INTO EMP VALUES (9004,'Raul','Profe',null,sysdate,200,null,20);

INSERT INTO EMP VALUES (9005,'Conchi','Profe',null,sysdate,3900,null,40);

Como vemos, el tercer y cuarto valor que hemos insertado son valores con sueldo menor a 2000, ahora vamos a comprobar que estas inserciones se han guardado ejecutando la siguiente sentencia como usuario SYS. 

SELECT sql_text FROM dba_fga_audit_trail WHERE policy_name='PRACTICA_AUDITORIA';

Posteriormente a esto fui insertando mas registros para obtener mas valores, como podemos ver, la auditoria creada solo filtra los registros cuyo sueldo es mayor a 2000.

Untitled

5. Explica la diferencia entre auditar una operación by access o by session ilustrándolo con ejemplos.

  • Auditorías By Access → En este tipo de auditoría, se auditan eventos individuales o acciones específicas, lo que significa que se registra cada vez que ocurre una acción específica, independientemente de quién la realiza o cuándo se realiza. Este tipo de auditorías son mas detalladas que las auditorías By Session.
  • Auditorías By Session → En este tipo de auditoría, se audita toda la actividad realizada por una sesión de usuario específica. Esto significa que se registra todo lo que hace un usuario durante su sesión.

Pruebas de funcionamiento:

  • By Session

    Ejecutamos la auditoría.

    sql AUDIT INSERT TABLE, UPDATE TABLE, DELETE TABLE BY C##SCOTT BY SESSION;

    Me conecto como usuario Scott y realizo algunas sentencias.

    sql INSERT INTO dept VALUES(50,'SALES','Dos Hermanas'); UPDATE dept SET loc='Montequinto' WHERE deptno=50; DELETE FROM dept WHERE deptno=50; COMMIT;

Untitled

Hecho esto, compruebo el registro como usuario SYS.

SELECT obj_name, action_name, timestamp FROM dba_audit_object WHERE username='C##SCOTT';

Untitled

  • By Access
AUDIT INSERT TABLE, UPDATE TABLE, DELETE TABLE BY SCOTT BY ACCESS;

Me vuelvo a conectar como SCOTT y realizo las mismas sentencias

CONN SCOTT/TIGER
INSERT INTO dept VALUES(50,'SALES','Dos Hermanas');
UPDATE dept SET loc='Montequinto' WHERE deptno=50;
DELETE FROM dept WHERE deptno=50;
COMMIT;

Untitled

Comprobamos el registro como usuario SYS.

SELECT obj_name, action_name, timestamp FROM dba_audit_object WHERE username='C##SCOTT';

Untitled

En resumen, la auditoría "by access" registra operaciones individuales sin importar quién los realiza o cuándo, mientras que la auditoría "by session" registra todas las operaciones realizadas por una sesión de usuario específica durante su duración.

6. Documenta las diferencias entre los valores db y db, extended del parámetro audit_trail de ORACLE. Demuéstralas poniendo un ejemplo de la información sobre una operación concreta recopilada con cada uno de ellos.

El parámetro audit_trail de Oracle determina el nivel de información que se va a registrar en la tabla DBA_AUDIT_TRAIL. Los valores "db" y "db, extended" son dos opciones disponibles para este parámetro y se diferencian en la cantidad de información que se registra en los archivos de auditoría.

  • DB:
    • Este valor indica que los registros de auditoría se guardarán en la base de datos Oracle.
    • Con este valor, se registrarán eventos básicos de auditoría, como inicio de sesión, cierre de sesión, operaciones de inicio y apagado del sistema, creación de objetos y otorgamiento de privilegios.
    • Los detalles específicos de la operación auditada no se incluirán en el registro de auditoría.
  • DB, EXTENDED:
    • Este valor también indica que los registros de auditoría se guardarán en la base de datos Oracle.
    • Incluye detalles adicionales sobre las operaciones que han sido auditadas
    • Estos detalles incluyen información como el usuario que realizó la operación, el momento exacto en que se realizó, el tipo de operación (por ejemplo, INSERT, UPDATE, DELETE), y los valores antes y después de la operación.

Podemos comprobar el valor del parámetro audit_trail de la siguiente manera.

SHOW PARAMETER AUDIT_TRAIL;

Untitled

Como podemos comprobar, el audit_trail ya se encuentra con el valor DB, voy a ejecutar algunas sentencias con el usuario SCOTT para que se registren y comprobar los datos.

INSERT INTO EMP VALUES (9080,'MARIO','CLERK',9080,sysdate,800,NULL,20);
UPDATE EMP SET SAL = 2000 WHERE EMPNO = 9080;
DELETE FROM EMP WHERE EMPNO = 9080;

Como usuario administrador vamos a comprobar la información registrada con la siguiente sentencia.

SELECT OS_USERNAME, USERNAME, USERHOST, TERMINAL, SES_ACTIONS, ACTION_NAME, SESSIONID, EXTENDED_TIMESTAMP, INSTANCE_NUMBER, OS_PROCESS, RETURNCODE, SQL_BIND, SQL_TEXT
FROM DBA_AUDIT_TRAIL
WHERE USERNAME = 'C##SCOTT'
ORDER BY EXTENDED_TIMESTAMP DESC;

Untitled

Podemos comprobar que los campos SQL_BIND y SQL_TEXT se encuentran vacíos, vamos a hacer la comprobación ahora poniendo el parámetro DB, EXTENDED

ALTER SYSTEM SET AUDIT_TRAIL=DB,EXTENDED SCOPE=SPFILE;
SHUTDOWN
STARTUP
SHOW PARAMETER AUDIT_TRAIL;

Untitled

Una vez hemos cambiado el valor de este atributo, voy a relizar las mismas sentencias que anteriormente para comprobar las diferencias.

INSERT INTO EMP VALUES (9080,'MARIO','CLERK',9080,sysdate,800,NULL,20);
UPDATE EMP SET SAL = 2000 WHERE EMPNO = 9080;
DELETE FROM EMP WHERE EMPNO = 9080;

Untitled

Y compruebo los registros como usuario SYS.

SELECT OS_USERNAME, USERNAME, USERHOST, TERMINAL, SES_ACTIONS, ACTION_NAME, SESSIONID, EXTENDED_TIMESTAMP, INSTANCE_NUMBER, OS_PROCESS, RETURNCODE, SQL_BIND, SQL_TEXT
FROM DBA_AUDIT_TRAIL
WHERE USERNAME = 'C##SCOTT'
ORDER BY EXTENDED_TIMESTAMP DESC;

Untitled

Como podemos comprobar, la columna SQL_TEXT se ha rellenado, mostrando las sentencias ejecutadas. La columna SQL_BIND sigue vacía ya que no se han usado variables en las consultas.

7. Averigua si en Postgres se pueden realizar los cuatro primeros apartados. Si es así, documenta el proceso adecuadamente.

7.1 Activa desde SQL*Plus la auditoría de los intentos de acceso exitosos al sistema. Comprueba su funcionamiento.

Para esto, podemos activar el parametro log_connections de nuestra base de datos Postgres.

sudo -u postgres psql

ALTER SYSTEM SET log_connections = 'ON';

Untitled

Con esto conseguimos que los logs de acceso a una instancia de Postgres sean registrados en /var/log/postgresql/postgresql-x-main.log. El nombre dependerá de la versión de Postgres que estemos usando, en mi caso es /var/log/postgresql/postgresql-15-main.log

Para que los cambios sean aplicados, tendremos que reiniciar el servidor PostgreSQL

sudo systemctl restart postgresql

Ahora me conectaré a la base de datos como usuario Scott y comprobaré los logs.

psql -h localhost -U scott -d scott

sudo tail /var/log/postgresql/postgresql-15-main.log

Untitled

7.2 Realiza un procedimiento en PL/SQL que te muestre los accesos fallidos junto con el motivo de los mismos, transformando el código de error almacenado en un mensaje de texto comprensible. Contempla todos los motivos posibles para que un acceso sea fallido.

7.3 Activa la auditoría de las operaciones DML realizadas por SCOTT. Comprueba su funcionamiento.

ACLARACIÓN: La ****herramienta que usaré a continuación no funciona correctamente en la ultima versión de PostgreSQL, para demostrar su funcionamiento he usado la versión 13 de Postgres. Continuo con el ejercicio.

Para esto voy a importar una herramienta externa, ya que Postgres no incorpora nativamente una heramienta para gestionar las auditorías.

wget [https://raw.githubusercontent.com/2ndQuadrant/audit-trigger/master/audit.sql](https://raw.githubusercontent.com/2ndQuadrant/audit-trigger/master/audit.sql)

Con este comando, hemos obtenido un Script creado por la comunidad de Postgresql, el cual nos va a permitir tener un control sobre las auditorías.

Untitled

Una vez descargado, la importamos a la base de datos.

\i audit.sql

Untitled

Una vez importado, activamos las auditorías para ambas tablas del usuario Scott.

SELECT audit.audit_table('scott.emp');
SELECT audit.audit_table('scott.dept');

Untitled

Untitled

Para comprobar el funcionamiento, haré algunas modificaciones en ambas tablas y posteriormente compruebo los registros.

INSERT INTO emp VALUES (8888, 'Fabio', 'Gonzalez', 8888, TO_DATE('25/02/2024', 'DD/MM/YYYY'), 2555, 2555, 10);
INSERT INTO dept VALUES (8888, 'Fabio', 'Gonzalez');

DELETE FROM emp WHERE empno = 8888;
DELETE FROM dept WHERE deptno = 8888;

select session_user_name, action, table_name, action_tstamp_clk, client_query 
from audit.logged_actions;

Untitled

Podemos comprobar que la auditoría se está realizando correactamente, nos aporta información relacionada con la operación realizada, el usuario que ha realizado la información, fecha y hora, etc…

También tenemos la opción de gestionar las auditorías empleando el uso de triggers, siguiendo esta documentación.

7.4 Realiza una auditoría de grano fino para almacenar información sobre la inserción de empleados con sueldo superior a 2000 en la tabla emp de scott.

Para realizar este apartado, voy a utilizar un trigger, el cual inserta en una tabla las inserciones de la tabla emp cuyos sueldos son mayor a 2000.

CREATE TABLE emp_audit (
    audit_id SERIAL PRIMARY KEY,
    empno INTEGER,
    ename VARCHAR(10),
    salary NUMERIC(7, 2),
    action_timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE OR REPLACE FUNCTION emp_insert_audit_trigger()
RETURNS TRIGGER AS $$
BEGIN
    IF NEW.sal > 2000 THEN
        INSERT INTO emp_audit (empno, ename, salary)
        VALUES (NEW.empno, NEW.ename, NEW.sal);
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER emp_insert_audit_trigger
AFTER INSERT ON emp
FOR EACH ROW EXECUTE FUNCTION emp_insert_audit_trigger();

Después de compilar los programas, podemos insertar algun valor en la tabla emp y comprobar que los datos son replicados en la tabla audit_emp creada.

INSERT INTO emp (empno, ename, sal) VALUES (9999, 'John', 3000);

Untitled

8. Averigua si en MySQL se pueden realizar los apartados 1, 3 y 4. Si es así, documenta el proceso adecuadamente.

8.1 Activa desde SQL*Plus la auditoría de los intentos de acceso exitosos al sistema. Comprueba su funcionamiento.

Para activar los registros de intentos fallidos de acceso, debemos habilitar el siguiente parámetro en la configuración de mariadb.

nano /etc/mysql/mariadb.conf.d/50-server.cnf

Untitled

Posteriormente reiniciamos mysql.

sudo systemctl restart mysql

Hecho esto, me logueo como usuario scott y compruebo los logs.

Untitled

8.3 Activa la auditoría de las operaciones DML realizadas por SCOTT. Comprueba su funcionamiento.

Para esto, vamos a instalar un plugin de MySql.

INSTALL SONAME 'server_audit';

Tras esto, configuraremos la auditoría para el usuario scott.

nano /etc/mysql/mariadb.conf.d/50-server.cnf

Añadimos las siguientes líneas.

[server]

server_audit_events=CONNECT,QUERY,TABLE
server_audit_logging=ON
server_audit_incl_users=scott
server_audit_file_path=/var/log/mysql/audit.log

Y reiniciamos el servicio.

sudo systemctl restart mariadb.server

Ahora me conecto como usuario Scott y realizo algunas sentencias.

INSERT INTO emp VALUES (5,'Fabio Gonzalez',70000);

UPDATE emp SET salario = 100000 WHERE emp_id = 5;

DELETE FROM emp WHERE emp_id = 5;

Hecho esto, podemos mirar el fichero de logs y comprobar los registros.

Untitled

8.4 Realiza una auditoría de grano fino para almacenar información sobre la inserción de empleados con sueldo superior a 2000 en la tabla emp de scott.

Creo la tabla y el trigger.

CREATE TABLE emp_audit (
    audit_id INT AUTO_INCREMENT PRIMARY KEY,
    empno INT,
    ename VARCHAR(100),
    salary DECIMAL(7, 2),
    action_timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

DELIMITER //

CREATE OR REPLACE TRIGGER emp_insert_audit_trigger
AFTER INSERT ON emp
FOR EACH ROW
BEGIN
    IF NEW.salario > 2000 THEN
        INSERT INTO emp_audit (empno, ename, salary)
        VALUES (NEW.emp_id, NEW.nombre, NEW.salario);
    END IF;
END;
//

DELIMITER ;

Inserto datos para hacer la prueba.

INSERT INTO emp VALUES (8,'profe',5000);
INSERT INTO emp VALUES (9,'raul',7000);
INSERT INTO emp VALUES (10,'rafa',3000);
INSERT INTO emp VALUES (11,'jose',1500);

Compruebo que la tabla audit_emp se rellena.

Untitled

9. Averigua las posibilidades que ofrece MongoDB para auditar los cambios que va sufriendo un documento. Demuestra su funcionamiento.

Para contar con las opciones de auditoría que nos ofrece MongoDB, será necesario que contemos con la versión Enterprise de Mongo. Podemos seguir los pasos que nos ofrece la guía oficial de MongoDB para instalar esta versión.

Untitled

Una vez aclarado esto, tenemos 3 opciones para activar las auditorías en Mongo:

  • Guardar las auditorías en syslog.
  • Guardar las auditorías en cheros JSON o BSON.
  • Hacer que las auditorías aparezcan en la consola.

Podemos habilitarlas a través del fichero de configuración de MongoDB que se encuentra por defecto en /etc/mongod.conf, veremos que hay que modificar en el fichero para cada caso.

  • Syslog:
storage:
    dbPath: data/db
auditLog:
    destination: syslog
  • JSON/BSON:
storage:
    dbPath: data/db
auditLog:
    destination: file
    format: {JSON,BSON}
    path: data/db/auditLog.{json,bson}
  • Consola:
storage:
    dbPath: data/db
auditLog:
    destination: console

Para hacer este ejemplo, he decidido la opción de usar un ficjero JSON y mostrar los logs por consola, mi fichero mongod.conf queda de la siguiente manera.

vagrant@mongo:~$ sudo cat /etc/mongod.conf 
# mongod.conf

# for documentation of all options, see:
#   http://docs.mongodb.org/manual/reference/configuration-options/

# Where and how to store data.
storage:
  dbPath: /var/lib/mongodb
#  engine:
#  wiredTiger:

# where to write logging data.
systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log
  component:
    write:
      verbosity: 2
# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1

# how the process runs
processManagement:
  timeZoneInfo: /usr/share/zoneinfo

security:
    authorization: enabled
#operationProfiling:

#replication:

#sharding:

## Enterprise-Only Options:

auditLog:
   destination: file
   format: JSON
   path: /var/log/mongodb/auditLog.json

#snmp:

Crearé una nueva base de datos e inserto registros en ella.

mongosh
use admin
db.createUser({
  user: "admin",
  pwd: "admin",
  roles: [ { role: "root", db: "admin" } ]
})
exit
mongosh -u admin -p admin --authenticationDatabase admin

use practica_auditoria

db.createCollection("asignaturas")
db.createCollection("profesores")

db.asignaturas.insertMany( [
    { nombre: "BD", id: 101 },
    { nombre: "SO", id: 102 }
])

db.profesores.insertMany( [
    { nombre: "David", id: 201 },
    { nombre: "Ana", id: 202 }
])

db.createRole({
    role: "nada",
    privileges: [
        { resource: { db: "practica_auditoria", collection: "" }, actions: ["remove"] }
    ],
    roles: []
})

db.createUser({
    user: "usuario1",
    pwd: "password",
    roles: ["nada"]
})

Me conecto con el usuario1 y como administrador para hacer varias operaciones, posteriormente, podemos comprobar el log generado.

mongosh -u usuario1 -p password --authenticationDatabase practica_auditoria

db.asignaturas.find()

db.profesores.find()

El usuario 1 no puede buscar en esta base de datos, ahora me conecto como admin y hago cambios.

Untitled

Hecho esto, podemos comprobar los logs.

sudo cat /var/lib/mongodb/auditLog.json | jq | less

La información que obtenemos es muy extensa, con less podemos buscar palabras concretas.

Inserts.

Untitled

Creación de colecciones.

Untitled

Creación de roles.

Untitled

Con esto, hemos comprobado que las auditorías en Mongo nos pueden ser de una gran ayuda y nos devuelven mucha información relevante sobre la base de datos.

10. Averigua si en MongoDB se pueden auditar los accesos a una colección concreta. Demuestra su funcionamiento.

En Mongo podemos conseguir auditar los accesos a una colección concreta usando filtros de auditoría, para esto vamos a modificar de nuevo el fichero de configuración de MongoDB.

sudo nano /etc/mongod.conf

auditLog:
   destination: file
   format: JSON
   path: /var/log/mongodb/auditLog2.json
   filter: '{ atype: "authCheck", "param.ns": "practica_auditoria.profesores", "param.command": { $in: [ "find", "insert", "delete", "update", "findandmodify" ] } }'

setParameter: { auditAuthorizationSuccess: true }

Con esto, conseguimos hacer una auditoría sobre la colección profesores de la base de datos practica_auditoria, ahora reiniciamos el servicio y comprobamos que funciona.

sudo systemctl restart mongod.service

Untitled

Ejecutamos el siguiente comando para mirar el contenido del fichero de logs.

sudo jq '. | select(.param.command == "find")' /var/log/mongodb/auditLog2.json

Untitled

Podemos filtrar mediante la sentencia que queramos buscar simplemtente modificando el comando anterior.

sudo jq '. | select(.param.command == "insert")' /var/log/mongodb/auditLog2.json

Untitled

Así comprobamos que se pueden hacer auditorías dedicadas a colecciones específicas en MongoDB.