OCA: Auditoria en base de datos Oracle.

Auditoria significa capturar y almacenar información acerca de lo que está sucediendo en el sistema, este proceso por lo tanto aumenta la cantidad de trabajo que el sistema debe de hacer. La auditoria debe ser enfocada a solo aquellos eventos que son de interes, una auditoria apropiadamente direccionada tiene un mínimo impacto sobre el desempeño del sistema, pero una auditoria no adecuada puede tener un impacto significativo negativo sobre el desempeño del sistema. El monitoreo y la auditoria debe ser una parte integral de tus procedimientos de seguridad, los cuales incluyen:

Auditoria obligatoria:

Todas las bases de datos Oracle auditan ciertas acciones a pesar de que las opciones ó parámetros de auditoria esten desactivados, la razón para una auditoria obligatoria es que la base de datos necesita registrar algunas actividades de base de datos críticas como son el inicio ó apagado del sistema.

Auditoria standard

Este tipo de auditoria es una caracteristica que se usa a nivel del sistema, usando un parámetro de inicialización, dicho parámetro es AUDIT_TRAIL. Después de que habilitaste la auditoria, ahora debes de seleccionar los objetos y privilegios que quieras auditar.

Auditoria basada en valores

Este tipo de auditoría extiende la auditoría standard, capturando no solo los eventos de auditoria que han ocurrido sino tambien los valores actuales que han sido insertados, actualizados o borrados, la auditoría basada en valores es implementada a través de triggers de base de datos.

Auditoría detallada

La auditoria detallada extiende la auditoria standard, capturando las declaraciones SQL actuales que han sido ejecutadas y no solo el evento que ha ocurrido.

Mucha teoria, veamos algo de practica sobre como podemos implementar la auditoría detallada en Oracle:

Supongamos que tú como DBA quieres saber cuando un usuario a seleccionado ciertos registros que son de vital importancia para la empresa, los registros los vamos a crear de la siguiente manera:

Objetos a crear:

Una tabla en el schema hr llamada empleados, el ddl es el siguiente:

create table hr.empleados(

codigo char(2) constraint nn_codigo_emp not null,

nombres varchar2(40) constraint nn_nombres_emp not null,

apellidos varchar2(40) constraint nn_apellidos_emp not null,

sueldo number(10,2) constraint nn_sueldo_emp not null,

primary key(codigo)

);

-- y el dml el siguiente:

insert into hr.empleados values('01','nombres1','apellidos1',1000);

insert into hr.empleados values('02','nombres2','apellidos2',2000);

insert into hr.empleados values('03','nombres3','apellidos3',3000);

insert into hr.empleados values('04','nombres4','apellidos4',4000);

insert into hr.empleados values('05','nombres5','apellidos5',5000);

Una vez creada la tablita vamos a auditar(seguir los pasos) de los usuarios que seleccionan los registros de los empleados que ganan más de S/.3000 (campo sueldo de la tabla hr.empleados)

Creamos un par de usuarios y le asignamos los privilegios de conexion y consulta sobre la tabla creada anteriormente:

create user sapo01 identified by sapo01;

create user sapo02 identified by sapo02;

grant connect to sapo01,sapo02;

grant select on hr.empleados to sapo01,sapo02;

Usamos el paquete dbms_fga para crear una politica de auditoria sobre una tabla o vista determinada(en nuestro caso la tabla hr.empleados), si cualquiera de las filas retornadas desde una consulta(query sql) ejecutadas por cualquier usuario coincide con la columna auditada y la condición de auditoria especificada entonces un evento de auditoria será creado y almacenado en las pistas de auditoria de Oracle. Opcionalmente, el evento de auditoria puede tambien ejecutar un procedimiento, La auditoria detallada se enfoca en un nivel declarativo(sql) es así que una declaración select que retorna cientos de filas generará solo un registro de auditoria.

El bloque pl/sql que crea la politica de auditoria es el siguiente:

begin

dbms_fga.add_policy (

object_schema=>'hr',

object_name=>'empleados',

policy_name=>'auditoria_sueldo_empleado',

audit_condition=>'sueldo>3000',

audit_column=>'sueldo',

handler_schema=>null,

handler_module=>null,

enable=>true,

statement_types=>'select');

end;

Ahora entramos con cualquiera de los usuarios creados enteriormente desde sqlplus y ejecutamos una consulta sobre la tabla que ya hemos configurado para que sea auditada:

C:\Documents and Settings\Pc>sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on Sßb Ago 1 22:27:18 2009

Copyright (c) 1982, 2005, Oracle. All rights reserved.

nolog> connect sapo01/sapo01@optimus;

Conectado.

SAPO01: OPTIMUS> select * from hr.empleados where sueldo=4000;

CO NOMBRES

-- ----------------------------------------

APELLIDOS SUELDO

---------------------------------------- ----------

04 nombres4

apellidos4 4000

SAPO01: OPTIMUS>

Ahora como usuario dba vemos los registros de auditoria creados, consultando a la vista dba_fga_audit_trail vemos algunos datos relevantes, entre los que destacan:

DB_USER, el usuario que realizó la consulta

OS_USER, el usuario desde donde se inició la sesión del sistema operatico cliente

USERHOST, nombre de la máquina del usuario que realizó la consulta

OBJECT_SCHEMA, el nombre del esquema auditado(hr en nuestro caso)

OBJECT_NAME, nombre de la tabla ó vista auditada(empleados en nuestro caso)

POLICY_NAME, nombre de la politica creada(auditoria_sueldo_empleado)

SQL_TEXT, el sql que ejecutó el usuario

El proceso de auditoría creado es bastante simple, en tu trabajo quizás quieras auditar tablas o vistas críticas que involucran miles de accesos por minuto, por lo que estos tipos de registros de auditoria debes de hacerlo con mucho cuidado y solo en casos en que lo amerite, como dije al comienzo una auditoría mal creada puede devenir en un performance negativo.