sql >> Base de Datos >  >> RDS >> Oracle

Seguridad de la base de datos Oracle:auditoría de la base de datos

En este artículo, continuaré con Oracle Database Security y presentaré algunos datos importantes sobre la auditoría estándar de bases de datos, activadores de auditoría y políticas de auditoría en Oracle. La auditoría de bases de datos tiene dos componentes:monitoreo y registro persistente de conjuntos de actividades y eventos de bases de datos establecidos. Los fines de la auditoría de bases de datos son el no repudio, la investigación de actividades sospechosas, la detección de problemas generados por las configuraciones en cuanto a la autorización (acceso a recursos), el cumplimiento de la legislación vigente y el control.

Auditoría estándar

¿Qué actividades auditamos? Oracle audita implícitamente el inicio y la detención de la base de datos, así como las conexiones realizadas por el administrador de la base de datos, y los datos se almacenan automáticamente en el sistema operativo. La siguiente tabla muestra otras actividades que pueden ser monitoreadas:

¿Dónde guardamos las actividades auditadas?

  • en la base de datos , utilizando el registro de auditoría de la base de datos, donde tenemos dos posibilidades:
    • audit_trail =DB
      que se puede hacer con el siguiente código:

      alter system set audit_trail=db scope=spfile;
    • audit_trail =DB,EXTENDIDO
      usando el siguiente código:

      alter system set audit_trail= db, extended scope=spfile;

    La diferencia entre DB y DB,EXTENDED es que el segundo rellena las columnas SQLBIND y SQLTEXT CLOB de la tabla SYS.AUD$.

  • externo , utilizando la pista de auditoría del sistema operativo, con las siguientes posibilidades:
    • audit_trail =OS
      y el código utilizado es:

      alter system set audit_trail=os scope=spfile;
    • audit_trail =XML y AUDIT_FILE_DEST =ruta del archivo (implícitamente es $ORACLE_BASE/admin/$ORACLE_SID/adump)
      con el código:

      alter system set audit_trail=xml scope=spfile;

Para encontrar la configuración actual de las actividades auditadas almacenadas, se puede ejecutar la siguiente consulta, escrita con minúsculas:

select value from v$parameter where name='audit_trail';

Comandos más útiles:

[identificación de la tabla=43 /]

Ahora veamos algunos ejemplos de auditoría de bases de datos.

Aquí hay un ejemplo de una auditoría estándar con información auditada almacenada en la base de datos:

La información auditada consiste en las sentencias SELECT ejecutadas en las tablas de la base de datos.

En SQL Developer, ejecute el siguiente script:

alter system set audit_trail= db, extended scope=spfile;
AUDIT SELECT TABLE;

Luego, se debe reiniciar la base de datos. Para hacer eso, en la terminal SQLPlus, conéctese con el nombre de usuario sys como sysdba / contraseña y ejecute las siguientes declaraciones:

SHUTDOWN IMMEDIATE
STARTUP

Tenga en cuenta que los tamaños anteriores difieren de un sistema a otro.

Para verificar si la pista de auditoría está configurada correctamente, ejecute la siguiente consulta:

select value from v$parameter where name='audit_trail';

o:

show parameter audit_trail;

Cuando desee detener la auditoría, ejecute:

NOAUDIT SELECT TABLE;

Para ver las declaraciones registradas por la auditoría, puede usar:

select dbms_lob.substr( sqltext, 4000, 1 )
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS');

o

select count(*), OBJ$NAME, USERID
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS')
group by rollup (OBJ$NAME, USERID);

Otro ejemplo es para auditoría estándar con datos auditados almacenados en un archivo XML, en la ruta estándar.

alter system set audit_trail=xml scope=spfile;
AUDIT SELECT, INSERT, UPDATE, DELETE ON employees WHENEVER NOT
SUCCESSFUL;

Nuevamente, reinicie la base de datos:conéctese a la terminal SQLPlus con el nombre de usuario sys como sysdba / contraseña y ejecute los comandos APAGADO INMEDIATO e INICIO.

Luego, cada vez que falla una consulta de selección, inserción, actualización y eliminación en la tabla de empleados, debe registrarse en el archivo XML.

Cuando queremos detener la auditoría, ejecutamos los siguientes comandos en el entorno de desarrollo de la base de datos:

NOAUDIT ALL;
NOAUDIT ALL ON DEFAULT;

Y restaurar la pista de auditoría predeterminada:

alter system set audit_trail=db scope=spfile;

A continuación se muestra un ejemplo de una parte de un archivo de auditoría XML:

¿Cómo eliminamos la información auditada?

El volumen de los datos auditados puede volverse muy grande debido al número de actividades auditadas y su frecuencia. Por eso se recomienda archivar periódicamente los datos auditados y eliminarlos del sistema de producción.

Si los datos auditados se almacenan en la base de datos (pista de auditoría de la base de datos), entonces podemos usar declaraciones de eliminación (¡pero solo después de haber archivado los datos!):

DELETE FROM SYS.AUD$;

Puede optar por eliminar la información auditada para un objeto de base de datos específico, por ejemplo, una tabla denominada productos:

DELETE FROM SYS.AUD$ WHERE OBJ$NAME='PRODUCTS';

Disparadores de auditoría

Un disparador es un bloque PL/SQL o la instrucción CALL de un procedimiento PL/SQL que se ejecuta automáticamente cada vez que ocurre un evento. Hay dos tipos de activadores:a nivel de la base de datos (declaraciones de la base de datos) ya nivel de la aplicación (por ejemplo, al presionar un botón en un formulario de Oracle). Los activadores utilizados para la auditoría son los activadores de nivel de base de datos. Se clasifican en las siguientes categorías:

  • Disparadores DML:donde se activa una instrucción DML en una tabla. Esos activadores se pueden ejecutar una vez en el nivel de comando, independientemente del número de registros (activadores en el nivel de declaración) o se pueden ejecutar PARA CADA FILA (activadores en el nivel de registro). Tipos de activadores de nivel de registro:ANTES DE LA DECLARACIÓN, DESPUÉS DE LA DECLARACIÓN, ANTES DE CADA FILA, DESPUÉS DE CADA FILA;
  • Desencadenadores INSTEAD OF:donde se desencadena una instrucción DML en una vista;
  • Activadores del SISTEMA:activados por eventos como iniciar/detener la base de datos, declaraciones DDL, inicio/cierre de sesión del usuario. Tipos de activadores del sistema:DESPUÉS DEL EVENTO, ANTES DEL EVENTO.

Consultando el SYS.TRIGGER$ tabla o ALL_TRIGGERS view ofrece información sobre todos los disparadores de nivel de base de datos. Por ejemplo, el tipo de disparador distinto de la base de datos se puede encontrar de la siguiente manera:

SELECT DISTINCT TRIGGER_TYPE FROM ALL_TRIGGERS;

La vista DBA_TRIGGERS ofrece información sobre los disparadores creados automáticamente por los productos de Oracle en la instalación. Si queremos encontrar información sobre los activadores del SISTEMA ('ANTES DEL EVENTO' y 'DESPUÉS DEL EVENTO'), podemos ejecutar la siguiente instrucción:

SELECT SUBSTR(OWNER,1,20) OWNER ,SUBSTR(TRIGGER_NAME,1,30),
TRIGGER_NAME, SUBSTR(TRIGGERING_EVENT,1,30) TRIGGERING_EVENT,
TRIGGER_TYPE
FROM DBA_TRIGGERS
WHERE TRIGGER_TYPE='BEFORE EVENT' OR TRIGGER_TYPE='AFTER EVENT'
ORDER BY TRIGGER_TYPE DESC;

Además, durante la instalación, los disparadores DML se crean automáticamente en el esquema de usuario de recursos humanos:

SELECT SUBSTR(TABLE_NAME,1,20) TABLE_NAME,
SUBSTR(TRIGGER_TYPE,1,30) TRIGGER_TYPE,TRIGGER_BODY
FROM DBA_TRIGGERS
WHERE OWNER='HR';

Para la auditoría, podemos crear disparadores personalizados para registrar la información deseada, pero se debe crear una tabla especial para almacenar la información auditada.

Es importante asegurarse de que los activadores desarrollados no influyan en la actividad normal de la base de datos. El propósito de la auditoría es monitorear pasivamente la actividad diaria normal de la base de datos y almacenarla para su posterior análisis. En consecuencia, no se recomienda crear activadores INSTEAD OF para devolver los resultados de las tablas de destino a la tabla de auditoría.

Los disparadores DML a nivel de declaración pueden coexistir con disparadores DML a nivel de registro. El orden de llamada es:

  • desencadenar sentencia ANTES
  • para cada registro afectado
    • activar ANTES de grabar
    • acción DML actual
    • activar DESPUÉS del registro
  • desencadenar declaración DESPUÉS

Los disparadores definidos por el usuario se ejecutarán solo si, según Oracle, la declaración es correcta y puede ocurrir. Para una declaración DML incorrecta o que viole una restricción, se devolverá un error y no se ejecutará el disparador. Por lo tanto, para la auditoría, se recomienda utilizar especialmente los disparadores LMD a nivel de declaración.

Ejemplo de activador de auditoría:

Supongamos que queremos crear un disparador para registrar en una tabla de auditoría (llamada TAB_AUDIT_EMP) información sobre las declaraciones DML que establecen salarios superiores a 20000 (la moneda no es importante aquí) para los empleados de la empresa. Queremos almacenar en TAB_AUDIT_EMP el número de secuencia de la consulta, el nombre de usuario, la sesión, el host y la fecha.

Esto se puede hacer con lo siguiente:

CREATE TABLE TAB_AUDIT_EMP

(secv_id NUMBER(3) PRIMARY KEY,
username VARCHAR2(20),
session_nr NUMBER(10),
hostname VARCHAR2(100),
query_date DATE
);

CREATE SEQUENCE secv_aud_emp START WITH 1 INCREMENT BY 1;
CREATE OR REPLACE TRIGGER huge_salary
AFTER INSERT OR UPDATE OR DELETE OF SALARY ON EMPLOYEES
FOR EACH ROW WHEN (NEW.salary>20000)
BEGIN
INSERT INTO TAB_AUDIT_EMP
VALUES(secv_aud_emp.NEXTVAL , sys_context('userenv', 'session_user'), sys_context('userenv', 'sessionid'), sys_context('userenv', 'host'), sysdate);
END;

Supongamos que hacemos una modificación salarial para los empleados de un departamento específico:

UPDATE EMPLOYEES
SET SALARY=25000
WHERE ID_DEPARTMENT = 1;

Y luego verificamos el seguimiento:

select secv_id, substr(username,1,20) username, session_nr, substr(hostname,1,30) hostname, query_date
from TAB_AUDIT_EMP;

Políticas de auditoría

El tercer método de auditoría se refiere a las políticas de auditoría. La definición de una política de auditoría contiene lo siguiente:

  • especificación del objeto (esquema, nombre de objeto, columnas) sujeto a monitoreo
  • especificación de las acciones auditadas para un objeto (SELECCIONAR, INSERTAR, ACTUALIZAR, ELIMINAR):implícitamente es SELECCIONAR
  • especificación de las condiciones que se deben cumplir para registrar la información auditada, se hace en la cláusula WHEN del trigger y es opcional
  • un controlador de eventos que además maneja el evento, que es opcional.

Una política de auditoría puede estar activa (estado HABILITADO) o inactiva (estado DESHABILITADO). La lista de políticas de auditoría se puede obtener consultando la vista ALL_AUDIT_POLICIES:

SELECT POLICY_TEXT, ENABLED
FROM ALL_AUDIT_POLICIES

Para la administración de políticas de auditoría contamos con el paquete DBMS_FGA. Para usar este paquete, es necesario otorgar privilegios a los usuarios que escribirán el código PL/SQL:

grant execute on dbms_fga to username;

Ejemplo de política de auditoría:

Queremos crear una política de auditoría para registrar las declaraciones DML que modifican los gerentes (MANAGER_ID) en la tabla DEPARTAMENTOS. Podemos optar por crear un manejador para la política, llamado proc_audit_alert, que nos informe de una modificación respecto al gestor:

CREATE OR REPLACE PROCEDURE proc_audit_alert ( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2 ) AS
BEGIN
DBMS_OUTPUT.PUT_LINE('Alert! Manager Changed !');
END;

Y la política puede ser:

CREATE OR REPLACE PROCEDURE proc_audit_manager AS
BEGIN
DBMS_FGA.ADD_POLICY
(
object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager',
audit_column=>'ID_MANAGER',
enable=>false,
statement_types=>'UPDATE',
handler_module=>'proc_audit_alert'
);
DBMS_FGA.ENABLE_POLICY
( object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager');
END;

Tenga en cuenta que object_schema, object_name, policy_name, audit_column, statement_types y handler_module deben adaptarse a la política que desea escribir.

Luego, ejecutamos el procedimiento:

EXECUTE proc_audit_manager;

Podemos verificar si la política está habilitada:

SELECT ENABLED, POLICY_NAME
FROM ALL_AUDIT_POLICIES
WHERE OBJECT_NAME='DEPARTMENTS';

Luego, verifique si el procedimiento y la política funcionan correctamente, ejecutando una actualización:

UPDATE DEPARTMENTS
SET ID_MANAGER=2
WHERE ID_DEPARTAMENT=1;

En conclusión, la auditoría es necesaria para cada base de datos y los métodos proporcionados anteriormente lo ayudan a encontrar una actividad sospechosa que pueda afectar la seguridad de su base de datos. Para obtener más detalles sobre la auditoría de la base de datos de Oracle, consulte la bibliografía a continuación.

Bibliografía:

  • http://www.datadisk.co.uk/html_docs/oracle/auditing.htm
  • http://docs.oracle.com/cd/B10501_01/server.920/a96521/audit.htm
  • https://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm#TDPSG50000