HABILITAR AUDITORIA EN ORACLE DATABASE

En algún momento nos hemos encontrado con la necesidad de habilitar el proceso de auditoría de nuestra base de datos, bien sea por políticas de seguridad en nuestra empresa o por que a alguien se le ocurrió la grandiosa idea.

Hay que tener en presente que el habilitar el proceso de auditoria puede ocasionar un impacto negativo a nivel del rendimiento de nuestra base de datos (Se debe evaluar muy bien) sobre todo cuando nuestro sistema es altamente transaccional y precisamente los objetos a auditar son los que intervienen en el proceso transaccional.

Bueno en mi caso fue por solicitud directa de uno de mis clientes, el cual requiera controlar todas las actividades de ciertos usuarios de la organización (Desarrollo). Este cliente utiliza Oracle 10gR2 (Que esta fuera de soporte).

Intentare explicar esta sencilla tarea y una buena práctica que recomiendan los que saben, por temas de seguridad y disponibilidad de la base de datos.

1.       Lo primero que debemos hacer antes de activar el proceso de auditoría, es crear un TABLESPACE exclusivo para registrar la información de rastro que se va generar (Una buena práctica, ya que la tabla sys.aud$ está en el TABLESPACE SYSTEM por default), para el reléase 10.2.0.4 (Mi caso) el procedimiento se debe hacer de manera manual (Procedimiento no certificado por Oracle). A partir de 10.2.0.5 se cuenta con el paquete AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION (Posterior generare una nueva entrada con la utilización del mismo), que lo hace de manera automática, para nuestro caso explicare la forma manual.

a)      Todo el procedimiento lo realizamos conectados con el usuario SYS, procedemos con la creación del nuevo TABLESPACES (En mi caso tengo ASM).

CREATE TABLESPACE AUDTBS

        DATAFILE '+DG1' SIZE 1024 m

                AUTOEXTEND ON MAXSIZE UNLIMITED

/

b)      Creación de nueva tabla que será utilizada para almacenar los rastros de auditoria sobre el TBS creado en el punto anterior (Se crea con la misma estructura de la tabla sys.aud$).

CREATE TABLE audt TABLESPACE AUDTBS

   STORAGE (INITIAL 50 k NEXT 50 k PCTINCREASE 0)

      AS SELECT * FROM aud$ WHERE 1 = 2

/

c)       Procedemos a renombrar la tabla actual y poner la nueva que creamos como principal.

RENAME aud$ TO aud$$

/

RENAME audt TO aud$

/

Nota: Validamos que no existan objetos descompilados o con estado INVALID, de encontrarlos procedemos a compilarlos.

d)      Procedemos con la creación de índice sobre la nueva tabla.

CREATE  INDEX i_aud2

  ON aud$(sessionid, ses$tid)

    TABLESPACE "AUDIT_TBS" STORAGE(INITIAL 50 k NEXT 50 k PCTINCREASE 0)

/

2.       Una vez que tenemos la tabla reubicada en un nuevo TBS evitando que por cosas del destino se nos llene nuestro TBS SYSTEM, procedemos a activar el proceso de auditoría. Para nuestro ejercicio se habilitara el registro extendido y almacenado en la base de datos, podemos también cambiar por almacenamiento en SO y formato XML (Esto será dependiendo de tus necesidades).

SHOW PARAMETER AUDIT

/

NAME                  TYPE        VALUE

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

audit_file_dest      string  /oracle/dbs/oracle/admin/TEST/adump

audit_sys_operations  boolean FALSE

audit_syslog_level    string 

audit_trail           string  NONE

ALTER SYSTEM SET audit_trail= DB,EXTENDED SCOPE=SPFILE SID='*'

/

System altered.

Nota: Para que los cambios tengan efecto debemos reiniciar nuestra base de datos.

3.       Una vez tenemos todo arriba nuevamente, podemos validar que los cambios hayan tenido efecto y procedemos a aplicar las políticas de auditoria solicitadas.

SHOW PARAMETER AUDIT

/

NAME                  TYPE        VALUE

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

audit_file_dest      string  /oracle/dbs/oracle/admin/TEST/adump

audit_sys_operations  boolean FALSE

audit_syslog_level    string 

audit_trail           string  DB,EXTENDED

Nos aseguramos que cualquier cambio sobre la tabla de auditoria sys.aud$ quede rastro.

AUDIT INSERT, UPDATE, DELETE ON sys.aud$ BY ACCESS;

El siguiente script puede ser útil cuando tenemos varios usuarios por auditar.

SELECT 'AUDIT ALL BY ' || username || ' BY ACCESS;'

  FROM dba_users

 WHERE username LIKE '%USR%'

UNION ALL

SELECT 'AUDIT SELECT TABLE, UPDATE TABLE, INSERT TABLE, DELETE TABLE BY ' || username || ' BY ACCESS;'

  FROM dba_users

 WHERE username LIKE '%USR%'

UNION ALL

SELECT 'AUDIT EXECUTE PROCEDURE BY ' || username || ' BY ACCESS;'

  FROM dba_users

 WHERE username LIKE '%USR%'

/

AUDIT ALL BY USR1 BY ACCESS

/

AUDIT SELECT TABLE, UPDATE TABLE, INSERT TABLE, DELETE TABLE BY USR1 BY ACCESS

/

AUDIT EXECUTE PROCEDURE BY USR1 BY ACCESS

/

Nota: Por defecto Oracle almacena la información de conexión y desconexión de los usuarios a la base de datos.     

Propongo estas tres consultas básicas para validar la información almacenada en la tabla de auditoria.

Con esta consulta podemos validar las vistas de auditoria que la base de datos posee.

SELECT   view_name

    FROM dba_views

   WHERE view_name LIKE 'DBA%AUDIT%'

ORDER BY view_name

/

Esta consulta permite validar los usuarios conectados al sistema que están siendo auditados.

SELECT *

  FROM dba_audit_exists

/

Consultar información básica de registros de auditoria.

SELECT   username, extended_timestamp, owner, obj_name, action_name, sql_bind, sql_text

    FROM dba_audit_trail

   WHERE username = 'USR1' AND owner = 'SCHEMA'

ORDER BY TIMESTAMP

/

Nota: Se debe programar actividades de backup y limpieza de la información de auditoria con cierta periodicidad, esto depende del volumen de información y la cantidad de políticas y usuarios auditados.

Espero que sea de ayuda, en una próxima entrada hablare de cómo podemos habilitar políticas de auditoria fina (FGA).

En el centro de cada dificultad se encuentra una oportunidad.
Albert Einstein (1879 - 1955), físico.