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" }
No se han encontrado comentarios