Auditoria de Bases de Datos

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:

SQL> select name , value from v$parameter where name like 'audit_trail';

NAME                 VALUE
-------------------- --------------------
audit_trail          DB

SQL>

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:

SQL> audit session whenever not successful;

Audit succeeded.

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

Enter user-name: system
Enter password:
ERROR:
ORA-01017: invalid username/password; logon denied


Enter user-name:

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

SQL> Select Username, userhost, extended_timestamp, action_name
  2  from dba_audit_session
  3  where username='SYSTEM';

USERNAME   USERHOST        EXTENDED_TIMESTAMP   ACTION_NAME
---------- --------------- -------------------- --------------------
SYSTEM     debian          09-FEB-17 06.21.26.2 LOGON
                           77573 PM +01:00

Activa la auditoria de las operaciones DML realizadas por SCOTT

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

SQL> audit insert table, update table, delete table by SCOTT;

Audit succeeded.

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

SQL> insert into profesores
  2  values ('36987412P','David','Moreno Cruz','01','614576324');

1 row created.

También podemos actualizar una fila:

SQL> update profesores set nombre='Pepe' where despacho='01';

1 row updated.

Por ultimo podemos comprobar a eliminar una fila:

SQL> delete from profesores where despacho='01';

1 row deleted.

Nos conectamos como system y comprobamos las modificaciones realizadas:

SQL> select OS_USERNAME, username, action_name, timestamp
  2  from dba_audit_object
  3  where username='SCOTT';

OS_USERNAME     USERNAME   ACTION_NAME     TIMESTAMP
--------------- ---------- --------------- ---------------
oracle          SCOTT      INSERT          10-FEB-17
oracle          SCOTT      UPDATE          10-FEB-17
oracle          SCOTT      DELETE          10-FEB-17
oracle          SCOTT      DELETE          10-FEB-17

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:

SQL> begin
  2  DBMS_FGA.ADD_POLICY (
  3  object_schema      =>  'SCOTT',
  4  object_name        =>  'EMP',
  5  policy_name        =>  'InsertEmp1',
  6  audit_condition    =>  'DEPTNO = 10',
  7  statement_types    =>  'INSERT');
  8  end;
  9  /

PL/SQL procedure successfully completed.

Ahora insertamos una fila para comprobar su funcionamiento:

SQL> INSERT INTO EMP VALUES(7950, 'JUANLU', 'DEV', 7566,TO_DATE('02-OCT-1995','DD-MON-YYYY'), 87600, NULL, 10);

1 row created.

Comprobar funcionamiento

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

SQL> select db_user, object_name, policy_name, sql_text
  2  from dba_fga_audit_trail;

DB_USER    OBJECT_NAME     POLICY_NAME     SQL_TEXT
---------- --------------- --------------- -----------------------------------
SCOTT      EMP             INSERTEMP1      INSERT INTO EMP VALUES(7950, 'JUANL
                                           U', 'DEV', 7566,TO_DATE('02-OCT-199
                                           5','DD-MON-YYYY'), 87600, NULL, 10)

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

SQL> show parameter audit;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest                      string      /opt/oracle/admin/orcl/adump
audit_sys_operations                 boolean     TRUE
audit_syslog_level                   string
audit_trail                          string      DB
unified_audit_sga_queue_size         integer     1048576

Activamos el modo db extended

SQL> ALTER SYSTEM SET audit_trail = DB,EXTENDED SCOPE=SPFILE;

System altered.

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:

#Paramos
SQL> shutdown
Database closed.
Database dismounted.
ORACLE instance shut down.

#Arrancamos
SQL> startup
ORACLE instance started.

Total System Global Area  843055104 bytes
Fixed Size                  2929984 bytes
Variable Size             583011008 bytes
Database Buffers          251658240 bytes
Redo Buffers                5455872 bytes
Database mounted.
Database opened.

SQL> show parameter audit;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest                      string      /opt/oracle/admin/orcl/adump
audit_sys_operations                 boolean     TRUE
audit_syslog_level                   string
audit_trail                          string      DB, EXTENDED
unified_audit_sga_queue_size         integer     1048576

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:

mysql> create database proyectos;
Query OK, 1 row affected (0.00 sec)

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

mysql> create database proyectos;
Query OK, 1 row affected (0.00 sec)

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

mysql> create table profesores(
    -> dni varchar(9),
    -> nombre varchar(15),
    -> apellido varchar(50),
    -> despacho varchar(10),
    -> telefono varchar(9),
    -> constraint pk_dni primary key (dni));
Query OK, 0 rows affected (0.01 sec)

Base de datos auditorias

Creamos la base de datos de auditorias:

mysql> create database auditorias;
Query OK, 1 row affected (0.00 sec)

mysql> use auditorias
Database changed

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

mysql> CREATE TABLE log_accesos
    -> (
    ->   codigo int(11) NOT NULL AUTO_INCREMENT,
    ->   usuario varchar(100),
    ->   fecha datetime,
    ->   PRIMARY KEY (`codigo`)
    -> )
    -> ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;
Query OK, 0 rows affected (0.00 sec)

Y creamos el tigger correspondiente:

mysql> delimiter $$
mysql>     CREATE TRIGGER proyectos.juanlu
    ->     BEFORE INSERT ON proyectos.profesores
    ->     FOR EACH ROW
    ->     BEGIN
    ->       INSERT INTO auditorias.log_accesos (usuario, fecha)
    ->           values (CURRENT_USER(), NOW());
    ->     END$$
Query OK, 0 rows affected (0.00 sec)

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

root@debian-virtual:/home/usuario# mysql -u root -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 45
Server version: 5.5.54-0+deb8u1 (Debian)

Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use proyectos
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> insert into profesores
    -> values ('36987412P','David','Moreno Cruz','01','614576324');
Query OK, 1 row affected (0.00 sec)

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

mysql> use auditorias
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select * from log_accesos;
+--------+----------------+---------------------+
| codigo | usuario        | fecha               |
+--------+----------------+---------------------+
|      1 | root@localhost | 2017-02-12 14:22:36 |
+--------+----------------+---------------------+
1 rows in set (0.00 sec)

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:

{ atype: { $in: [ "createCollection", "dropCollection" ] } }

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

mongod –dbpath data/db –auditDestination file –auditFilter ‘{ atype: { $in: [ “createCollection”, “dropCollection” ] } }’ –auditFormat BSON –auditPath data/db/auditLog.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:

{ atype: "authenticate", "param.db": "test" }