Realiza y documenta adecuadamente las siguientes operaciones:
1. Activa desde SQL*Plus la auditoría de los intentos de acceso fallidos al sistema. Comprueba su funcionamiento.
Para activar la auditoría de los intentos de acceso fallidos primero tenemos que ver los parámetros de auditoría:
05-02-2020 17:42:51 SYS@XE SQL> SHOW PARAMETER AUDIT
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest string /u01/app/oracle/admin/XE/adump
audit_syslog_level string
audit_sys_operations boolean FALSE
audit_trail string NONE
05-02-2020 17:46:55 SYS@XE SQL>
Vamos a activar audit_tail:
1
05-02-2020 17:46:55 SYS@XE SQL> ALTER SYSTEM SET audit_trail=db scope=spfile;
Vamos a ejecutar los cambios: Tedremos que reiniciar para que se ejecuten estos cambios.
A continuación vamos a activar la auditoría:
1
2
3
2020/02/05 17:58:33 SYS@XE SQL> AUDIT CREATE SESSION WHENEVER NOT SUCCESSFUL;
Audit succeeded.
Tengo que añadir, que no se puede crear para el usuario SYS.
Podemos ver las auditorías que están activas con el siguiente comando:
1
2
3
4
5
6
7
8
2020/02/05 18:00:16 SYS@XE SQL> SELECT * FROM dba_priv_audit_opts;
USER_NAME PROXY_NAME
------------------------------ ------------------------------
PRIVILEGE SUCCESS FAILURE
---------------------------------------- ---------- ----------
CREATE SESSION BY ACCESS BY ACCESS
Como podemos ver está la que hemos creado previamente.
Ejemplo de accesos fallidos:
1
2
05-02-2020 18:14:16 SYS@XE SQL> SELECT os_username, username, extended_timestamp, action_name, returncode
2 FROM dba_audit_session;
Una vez terminados se puede desactivar con el siguiente comando:
1
2
3
05-02-2020 18:16:15 SYS@XE SQL> NOAUDIT CREATE SESSION WHENEVER NOT SUCCESSFUL;
Noaudit succeeded.
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.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
CREATE OR REPLACE FUNCTION Mostrarfallos(p_fallo NUMBER)
RETURN VARCHAR2
IS
fallos VARCHAR2(25);
BEGIN
CASE p_fallo
WHEN 1017 THEN
fallos:='Contraseña incorrecta';
WHEN 28000 THEN
fallos:='Cuenta bloqueada';
ELSE
fallos:='Error desconocido';
END CASE;
RETURN fallos;
END;
/
CREATE OR REPLACE PROCEDURE MostrarAccesos
IS
CURSOR c_pruebaacceso
IS
SELECT username, returncode, timestamp
FROM dba_audit_session
WHERE action_name='LOGON'
AND returncode != 0
ORDER BY timestamp;
v_motivo VARCHAR2(25);
BEGIN
FOR prueba IN c_pruebaacceso LOOP
v_motivo:=Mostrarfallos(prueba.returncode);
DBMS_OUTPUT.PUT_LINE('Usuario: '||prueba.username||CHR(9)||CHR(9)|| 'Fecha: '||
prueba.timestamp||CHR(9)|| 'Motivo: '||v_motivo);
END LOOP;
END;
/
1
EXEC MostrarAccesos;
3. Activa la auditoría de las operaciones DML realizadas por SCOTT. Comprueba su funcionamiento.
1
2
3
05-02-2020 18:18:46 SYS@XE SQL> AUDIT INSERT TABLE, UPDATE TABLE, DELETE TABLE BY SCOTT BY ACCESS;
Audit succeeded.
Consulta las modificaciones y acciones que hemos realizado:
1
2
3
05-02-2020 18:34:35 SYS@XE SQL> select OS_USERNAME, username, action_name, timestamp
2 from dba_audit_object
3 where username='SCOTT';
4. 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.
Lo primero que tenemos que hacer es crear el procedimiento para controlar la inserción de los empleados del departamento:
1
2
3
4
5
6
7
8
9
10
BEGIN
DBMS_FGA.ADD_POLICY (
object_schema => 'SCOTT',
object_name => 'EMP',
policy_name => 'policy1',
audit_condition => 'DEPTNO = 10',
statement_types => 'INSERT'
);
END;
/
1
2
SELECT object_schema, object_name, policy_name, policy_text
FROM dba_audit_policies;
Referencia: Documentación oficial de Oracle
Esta opción la he tenido que hacer en una máquina con Oracle 12, a partir de esta versión se implementó.
5. Explica la diferencia entre auditar una operación by access o by session.
By access, nos almacena todas las acciones y nos crea un registro por cada sentencia auditada. Oracle recomienda usar esta opción.
By session, nos almacena las sentencias en un registro por cada sesión iniciada.
Vamos a ver un ejemplo de los dos:
By access:
1
2
3
SQL> SELECT owner, obj_name, action_name, timestamp, priv_used
2 FROM dba_audit_object
3 WHERE username='SYSTEM';
By session:
1
2
3
SQL> select obj_name, action_name, timestamp
2 from dba_audit_object
3 where username='SCOTT';
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.
Vamos a ver las principales diferencias entre db y db, extended con el parámetro audit_trail.
db: Activa la auditoría y los datos se almacenan en la tabla
SYS.AUD$.db, extended: Aparte de almacenar los datos en la tabla
SYS.AUD$, este escribirá los valores en las columnasSQLBINDySQLTEXTde la misma tabla;SYS.AUD$.
Referencia: Documentación oficial de Oracle
Vamos a ver un ejemplo:
Primero vamos a ver el estado de audit_trail:
1
SQL> show parameter audit;
Activaremos db, extended con el siguiente comando.
1
SQL> ALTER SYSTEM SET audit_trail = DB,EXTENDED SCOPE=SPFILE;
Reiniciamos para que se ejecute los cambios:
Como podemos apreciar ya hemos activado el valor al parámetro audit_trail.
7. Localiza en Enterprise Manager las posibilidades para realizar una auditoría e intenta repetir con dicha herramienta los apartados 1, 3 y 4.
Vamos a iniciar Enterprise Manager 12c:
Solo he podido encontrar lo siguiente, acerca de las auditorías en esta versión.
Esto es lo unico que se puede ver en Oracle Enterprise Manager 12c, como se puede apreciar está muy limitado a la hora de gestionar auditorías o parámetros de configuración
Voy a intentar realizar las mismas pruebas con Oracle Enterprise Manager 11g:
Con está versión se puede realizar una auditoría si navegamos a través de las siguientes pestañas:
1
2
3
- Sevidor
- Seguridad
- Valores de Auditoría
- Valores de Auditoría:
En la ventana de Valores de Auditoría podremos ver Pistas de Auditoría de Base de Datos, aquí tendremos las Conexiones Fallidas Auditadas, (donde veremos las conexiones fallidas que tiene la base de datos, al igual que hemos visto en el Ejercicio 1), Privilegios Auditados y Objetos auditados.
- Conexiones Fallidas Auditadas:
Aqui podremos encontrar las conexiones fallidas que tenemos en nuestra base de datos:
Vamos a realizar unas pruebas de inicio de sesión: 
Como podemos apreciar aparecen las nuevas pruebas que acabamos de realizar correctamente.
- Objetos Auditados:
Al igual que antes, aquí podremos encontrar los objetos auditados
8. Averigua si en Postgres se pueden realizar los apartados 1, 3 y 4. Si es así, documenta el proceso adecuadamente.
Leyendo la documentación de PostgreSQL, he podido leer que no se pueden realizar igual que en Oracle, la forma de hacerlo es mediante funciones y procedimientos
Referencia: Auditoria de tablas en PostgreSQL
9. Averigua si en MySQL se pueden realizar los apartados 1, 3 y 4. Si es así, documenta el proceso adecuadamente.
Creamos la base de datos y añadimos una tabla.
1
2
3
4
5
6
7
8
9
10
11
12
13
MariaDB [(none)]> create database prueba;
Query OK, 1 row affected (0.001 sec)
MariaDB [(none)]> use prueba;
Database changed
MariaDB [prueba]> create table clientes(
-> dni varchar(9),
-> nombre varchar(15),
-> apellido varchar(50),
-> telefono varchar(9),
-> constraint pk_dni primary key (dni));
Query OK, 0 rows affected, 1 warning (0.012 sec)
Creamos la base de datos auditorias:
1
2
3
4
5
6
7
MariaDB [prueba]> create database auditorias;
Query OK, 1 row affected (0.001 sec)
MariaDB [prueba]> use auditorias
Database changed
MariaDB [auditorias]>
Tabla para almacenar la salida del trigger:
1
2
3
4
5
6
7
8
CREATE TABLE accesos
(
codigo int(11) NOT NULL AUTO_INCREMENT,
usuario varchar(100),
fecha datetime,
PRIMARY KEY (`codigo`)
)
ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;
1
2
3
4
5
6
7
8
delimiter $$
CREATE TRIGGER prueba.ernesto
BEFORE INSERT ON prueba.clientes
FOR EACH ROW
BEGIN
INSERT INTO auditorias.accesos (usuario, fecha)
values (CURRENT_USER(), NOW());
END$$
Entramos a la base de datos prueba y añadimos un nuevo registro a la tabla clientes.
1
2
3
MariaDB [(none)]> use prueba
MariaDB [prueba]> insert into clientes
-> values ('47426968X','Ernesto','Vazquez Garcia','640514267');
Ahora vamos a ver si ha realizado bien el triger mirando la tabla accesos.
1
2
MariaDB [(none)]> use auditorias
MariaDB [auditorias]> select * from accesos;
Como podemos apreciar en la imagen, se ha creado correctamente el nuevo registro en la tabla accesos. Esta es la forma de auditar en MySQL. Es algo distinto a Oracle pero se puede tener algo parecido con este trigger.
10. Averigua las posibilidades que ofrece MongoDB para auditar los cambios que va sufriendo un documento.
MongoDB si nos permite realizar ciertas auditorías para ver los permitidos pondremos el siguiente comando:
1
--auditFilter
Vamos a ver un ejemplo:
Con la siguiente sentencia solamente audita las acciones createCollection y dropCollection:
1
{ atype: { $in: [ "createCollection", "dropCollection" ] } }
Podremos el filtro entre comillas simples para pasar el documento como una cadena.
1
mongod --dbpath data/db --auditDestination file --auditFilter '{ atype: { $in: [ "createCollection", "dropCollection" ] } }' --auditFormat BSON --auditPath data/db/auditLog.bson
Referencia: Documentación oficial de MongoDB.
11. Averigua si en MongoDB se pueden auditar los accesos al sistema.
Si, leyendo la documentacion de MongoDB, he llegado a la conclusión que es algo parecido a lo realizado anteriormente, solamente tendremos que cambiar los parametros:
1
{ atype: "authenticate", "param.db": "test" }
Al igual que antes podemos usarlo como una cadena, si lo ponemos entre comillas simples.
1
mongod --dbpath data/db --auth --auditDestination file --auditFilter '{ atype: "authenticate", "param.db": "test" }' --auditFormat BSON --auditPath data/db/auditLog.bson
Referencia: Operaciones de autenticación