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

Para activar la auditoría y que los datos se almacenen en la base de datos, ejecutamos el siguiente comando:

ALTER SYSTEM SET audit_trail=db scope=spfile;

Para comprobar que se ha activado correctamente, ejecutamos el siguiente comando:

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

Para activar la auditoría de los intentos de acceso exitosos al sistema, ejecutamos el siguiente comando:

AUDIT CREATE SESSION WHENEVER SUCCESSFUL;

Ahora, tras acceder a la base de datos con el usuario restaurante (de una práctica anterior), haciendo la siguiente consulta, puedo ver que se ha almacenado la información del acceso:

SELECT OS_USERNAME, USERNAME, EXTENDED_TIMESTAMP, ACTION_NAME FROM DBA_AUDIT_SESSION;

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

Primero, para vaciar la tabla de auditoría, ejecuto el siguiente comando:

TRUNCATE table sys.AUD$;

Ahora creo una sesión de auditoría para los accesos fallidos:

AUDIT CREATE SESSION WHENEVER NOT SUCCESSFUL;

He obtenido el significado de los códigos de error de la siguiente página: http://johanlouwers.blogspot.com/2013/01/oracle-database-login-audit.html

Ahora, creo el procedimiento en PL/SQL:

CREATE OR REPLACE PROCEDURE accesosFallidos
IS
    CURSOR c_accesos IS
        SELECT USERNAME, EXTENDED_TIMESTAMP, ACTION_NAME, RETURNCODE
        FROM DBA_AUDIT_SESSION
        WHERE RETURNCODE <> 0;
begin
    for i in c_accesos loop
        dbms_output.put_line('HORA: ' || i.EXTENDED_TIMESTAMP);
        dbms_output.put_line(CHR(9)||'-USUARIO: ' || i.USERNAME);
        case i.RETURNCODE
            when 00911 then
                dbms_output.put_line(CHR(9)||'-El nombre de usuario o la contrasena contiene un caracter no valido');
            when 00988 then
                dbms_output.put_line(CHR(9)||'-Falta la contrasena o no es valida');
            when 01004 then
                dbms_output.put_line(CHR(9)||'-Inicio de sesion denegado');
            when 01005 then
                dbms_output.put_line(CHR(9)||'-contrasena nula');
            when 01017 then
                dbms_output.put_line(CHR(9)||'-contrasena / usuario no validos');
            when 01031 then
                dbms_output.put_line(CHR(9)||'-Sin privilegios');
            when 01045 then
                dbms_output.put_line(CHR(9)||'-El usuario no tiene el privilegio CREATE SESSION');
            when 01918 then
                dbms_output.put_line(CHR(9)||'-No existe el user ID');
            when 01920 then
                dbms_output.put_line(CHR(9)||'-No existe el rol');
            when 09911 then
                dbms_output.put_line(CHR(9)||'-contrasena incorrecta');
            when 28000 then
                dbms_output.put_line(CHR(9)||'-La cuenta esta bloqueada');
            when 28001 then
                dbms_output.put_line(CHR(9)||'-La contrasena ha caducado');
            when 28002 then
                dbms_output.put_line(CHR(9)||'-La contrasena caducara pronto, se debe cambiar ahora');
            when 28003 then
                dbms_output.put_line(CHR(9)||'-La contrasena no es lo suficientemente compleja');
            when 28007 then
                dbms_output.put_line(CHR(9)||'-La contrasena no se puede reutilizar');
            when 28008 then
                dbms_output.put_line(CHR(9)||'-contrasena antigua no valida');
            when 28009 then
                dbms_output.put_line(CHR(9)||'-La conexión a sys se debe realizar desde sysdba o sysoper');
            when 28011 then
                dbms_output.put_line(CHR(9)||'-La cuenta va a caducar pronto, se debe cambiar la contrasena');
            when 28221 then
                dbms_output.put_line(CHR(9)||'-La contrasena original no ha sido suministrada');
        end case;
    end loop;
end;
/

Compruebo que funciona correctamente:

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

Activo la auditoría de las operaciones DML realizadas por SCOTT:

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

Ahora inserto un empleado en la tabla emp:

INSERT INTO emp VALUES (9999, 'Roberto', 'Director', 7839, TO_DATE('21/02/2023', 'DD/MM/YYYY'), 5000, 0, 10);

Y se ve reflectado en la tabla de auditoría:

SELECT USERNAME, OBJ_NAME, ACTION_NAME, EXTENDED_TIMESTAMP FROM DBA_AUDIT_OBJECT;

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

La auditoría de grano fino (FGA) es como una versión extendida de la auditoría estándar. Registra los cambios en datos muy concretos a nivel de columna.

Para realizar la auditoría de grano fino, primero tengo que crear una política de auditoría:

BEGIN
    DBMS_FGA.ADD_POLICY (
    OBJECT_SCHEMA      => 'SCOTT',
    OBJECT_NAME        => 'EMP',
    POLICY_NAME        => 'SALARIO_MAYOR_2000',
    AUDIT_CONDITION    => 'SAL < 2000',
    STATEMENT_TYPES    => 'INSERT'
    );
END;
/

Ahora inserto varios empleados:

INSERT INTO emp VALUES (2222, 'Bill Gates', 'Director', 7839, TO_DATE('21/02/2023', 'DD/MM/YYYY'), 1000, 0, 10);
INSERT INTO emp VALUES (3333, 'Steve Jobs', 'Director', 7839, TO_DATE('21/02/2023', 'DD/MM/YYYY'), 5000, 0, 10);

Y compruebo que aparece en la tabla de auditoría:

SELECT DB_USER, OBJECT_NAME, SQL_TEXT, EXTENDED_TIMESTAMP FROM DBA_FGA_AUDIT_TRAIL WHERE POLICY_NAME='SALARIO_MAYOR_2000';

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

Las operaciones by access se auditan por cada acceso a la base de datos, mientras que las operaciones by session se auditan por cada sesión de usuario. Por ejemplo, si un usuario realiza 10 accesos a la base de datos, se auditarán 10 operaciones by access, mientras que si realiza 10 accesos en una misma sesión, se auditarán 1 operación by session.

La sintaxis es la siguiente:

AUDIT [operación] [tabla] BY [usuario] BY {ACCESS | SESSION};

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

Ambos parámetros indican que la auditoría está activada. La diferencia es que el parámetro db guarda la información en la tabla de auditoría, mientras que el parámetro db, extended guarda la información en la tabla de auditoría y en el archivo de alerta.

Para cambiar el parámetro, utilizo el siguiente comando:

ALTER SYSTEM SET audit_trail = db, extended SCOPE = SPFILE;

Reinicio la base de datos y compruebo que el parámetro se ha cambiado correctamente, con la consulta del ejercicio 1:

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

Ejercicio 1

En postgres no se puede realizar el ejercicio 1, ya que se registran los inicios de sesión fallidos en el archivo de log, pero no los exitosos.

Ejercicio 2

No se puede realizar un procedimiento ya que los accesos fallidos no está registrado en la base de datos, sino en el archivo de log, sin embargo, en el propio archivo de log, se encuentran explicados con palabras y en español, el objetivo final del procedimiento:

Ejercicio 3

Para realizar la auditoría voy a usar Trigger 91plus, una herramienta creada por la comunidad que permite auditar las operaciones DML en postgres.

Para instalarla, primero tengo que descargar de github el siguiente fichero

wget https://raw.githubusercontent.com/2ndQuadrant/audit-trigger/master/audit.sql

Y luego lo instalo:

\i audit.sql

No puede realizar auditorías de todo lo que realiza un usuario, sino de tablas. Por lo que voy a especificar las tablas del usuario scott que quiero auditar:

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

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

Ejercicio 1

Para obtener los datos de los inicios de sesión, edito el fichero /etc/mysql/mariadb.conf.d/50-server.cnf:

general_log_file       = /var/log/mysql/mysql.log
general_log            = 1
log_error = /var/log/mysql/error.log

Cambio el propietario del directorio de los logs y reinicio el servicio:

chown -R mysql:mysql /var/log/mysql
systemctl restart mariadb.service

Ahora, tras varios inicios de sesión, compruebo el fichero de logs /var/log/mysql/mysql.log:

Ejercicio 3

Para realizar la auditoría voy a instalar el plugin server_audit:

INSTALL SONAME 'server_audit';

Ahora edito el fichero /etc/mysql/mariadb.conf.d/50-server.cnf y reinicio mariadb:

[server]
server_audit_events=CONNECT,QUERY,TABLE
server_audit_logging=ON
server_audit_incl_users=scott

Tras insertar un nuevo empleado, compruebo el fichero de log /var/lib/mysql/server_audit.log:

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

Para realizar las auditorías, es necesario instalar la versión Enterprise. La documentación de instalación oficial se encuentra en el siguiente enlace https://www.mongodb.com/docs/manual/tutorial/install-mongodb-enterprise-on-debian/. Una vez instalado podemos hacer lo siguiente:

• Habilitar las auditorías en el syslog desde la consola:

mongod --dbpath /var/lib/mongodb/ --auditDestination syslog

• Habilitar las auditorías en un fichero JSON desde la consola:

mongod --dbpath /var/lib/mongodb/ --auditDestination file --auditFormat JSON --auditPath /var/lib/mongodb/auditLog.json

• Habilitar las auditorías en un fichero BSON desde la consola:

mongod --dbpath /var/lib/mongodb/ --auditDestination file --auditFormat BSON --auditPath /var/lib/mongodb/auditLog.bson

• Habilitar las auditorías en la consola desde la consola:

mongod --dbpath /var/lib/mongodb/ --auditDestination console

He utilizado la salida por consola y preferencia de formato ya que se trata también de un json.

mongod --dbpath /var/lib/mongodb/ --auditDestination console | jq

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