AUDITORÍA DE BASE DE DATOS

Mónica Muro VelázquezEnrique Navarrete PérezStephanie Torres Juan

AUDITORÍA DE BASE DE DATOSEs el proceso que permite medir, asegurar, demostrar, monitorear y registrar los accesos a la información almacenada en las bases de datos incluyendo la capacidad de determinar:

Quien accede a los datos

Cuando se accedió a los datos

Desde que tipo de dispositivo/aplicación

Desde que ubicación en la Red

Cual fue la sentencia SQL ejecutada

Cual fue el efecto del acceso a la base de datos

OBJETIVOSRecopilar información acerca de actividades específicas de la base de datosRecopilar estadísticas sobre qué tablas actualizadas, E/S lógicas, cantidad de usuarios conectados concurrentementeRecopilar inverosimilitudes en los datos(detección de errores)Recopilar los errores por pérdida de informaciónMitigar los riesgos asociados con el manejo inadecuado de los datos

IMPORTANCIAToda la información financiera reside en base de datos y deben existir controles relacionados con el acceso a las mismas.Se debe poder demostrar la integridad de la informaciónLas organizaciones deben mitigar los riesgos asociados a la perdida de datos y a la fuga de informaciónLa información confidencial de los clientes, son responsabilidad de las organizaciones.Los datos convertidos en información a través de base de datos.

Los riesgos hacen que las vulnerabilidades dentro de un sistema de información sean una puerta para que las amenazas sean una fuente de peligro.

ACCIONES AUDITABLESSe pueden auditar tres tipos de acciones: Intentos de inicio de sesión Accesos a objetos Acciones de la base de datos

Cuando se realizan auditorías, la funcionalidad de la base de datos es dejar constancia de los comandos correctos e incorrectos. Esto puede modificarse cuando se configura cada tipo de auditoría.

Por ejemplo, se pueden registrar todos los intentos de actualizar los datos de una tabla o sólo los intentos fallidos, también se pueden registrar todos los inicios de sesión en Oracle o sólo los intentos fallidos.

RECOLECCIÓN DE DATOSSentencias SQL: Registro de los intentos de conexión con la base d datosPrivilegios: Recopila las operaciones que se han efectuado sobre la base de datos y los usuariosObjetos: Se pueden recoger operaciones realizadas sobre determinados objetos de la base de datos

La recolección de datos se basa en un conjunto de vistas que actúan sobre la tabla donde se guardan los registros de auditoría. Ésta tabla es AUD$ para la auditoría normales y FGA_LOG$ para la auditoría de grano fino.

Cada vista ofrece distintos tipos de información de forma más clara para el auditor o administrador de la base de datos.

EVALUACIÓN DE LA AUDITORÍADefinición de estructuras físicas y lógicas de las bases de datosControl de carga y mantenimiento de las bases de datosIntegridad de los datos y protección de accesosEstándares para análisis y programación en el uso de bases de datosProcedimientos de respaldo y de recuperación de datos

PLANIFICACIÓN1. Identificar todas las bases de datos de la organización

2. Clasificar los niveles de riesgo de los datos en las bases de datos

3. Analizar los permisos de acceso

4. Analizar los controles existentes de acceso a las bases de datos

5. Establecer los modelos de auditoria de BD a utilizar

6. Establecer las pruebas a realizar para cada BD, aplicación Y/O usuarios

7. Evaluación de resultados: Los datos recopilados se someten a un riguroso análisis, de tal manera que se pueda concluir si hay controles, si son suficientes y eficientes y si cumplen con los objetivos para los cuales fueron diseñados.

8. Elaboración del Informe: El auditor considera que en su opinión el sistema es confiable, porque tiene los mecanismos de seguridad necesarios, o por el contrario considere que no es seguro ni confiable y que amerita una revisión e implantación de controles.

MÉTODOLOGIAS PARA AUDITAR BASES DE

DATOS

METODOLOGÍA TRADICIONAL El auditor revisa el entorno con la ayuda de una lista de control (Checklist), que consta de una serie de cuestiones a verificar, registrando los resultados de su investigación. La evaluación consiste en identificar la existencia de controles establecidos.

METODOLOGÍA ROA (RISK ORIENTED APPROACH)El análisis de riesgos es la consideración del daño probable que puede causar en el negocio un fallo en la seguridad de la información, con las consecuencias potenciales de pérdida de confidencialidad, integridad y disponibilidad de la información.

Fija los objetivos de control que minimizan los riesgos potenciales a los que esta sometido el entrono.

Considerando los riesgos de:Dependencia por la concentración de Datos.Accesos no restringidos en la figura del DBA Incompatibilidades entre el sistema de seguridad de accesos del SGBD y el

general de instalación Impactos de los errores en Datos y programasRupturas por accesos no autorizados

PISTAS DE AUDITORÍA

PISTAS DE AUDITORÍALas Pistas de Auditoría o “Audit Trail” son un conjunto de transacciones que reflejan los cambios hechos a una base de datos.

A partir del análisis de esta información se puede llegar a determinar la forma en la que los datos o elementos obtuvieron su valor actual. Son un componente fundamental para la implementación del “accountability” o rendición de cuentas.

En una base de datos de una aplicación estándar de una organización, se pueden generar pistas de auditoría para:Conexiones a la base de datos.Modificaciones al modelo de datos.Modificaciones a los datos.

El uso más provechoso es para proactivamente monitorear la seguridad de la base de datos. Esto puede ser realizado por el administrador de la base de datos.

AUDITORÍA EN ORACLE En el caso de Oracle Database, la auditoría es un conjunto de características que permite al administrador de la base de datos y a los usuarios hacer un seguimiento del uso de la base de datos.

El administrador de base de datos puede definir la actividad de auditoría predeterminada. La información de las auditorías se almacena en el diccionario de datos, en la tabla SYS.AUD$ o en la pista de auditoría del sistema operativo (si lo permite). Lo anterior viene definido en el parámetro audit_trail.

AUDITORÍA EN ORACLE La auditoría en Oracle consiste en la monitorización y almacenamiento de información de nuestro servidor Oracle, la auditoría es una parte importante de la seguridad del sistema que no debe olvidarse.

Ventajas:

o Dispondremos de información de las operaciones del sistema.

o Protegeremos mejor nuestro sistema.

o Podemos prevenir ataques y detectar posibles intrusos.

Inconvenientes:

o Mayor consumo de recursos del sistema.

ACTIVACIÓN DE LA AUDITORIA EN ORACLE

Para activar la auditoría estándar en Oracle, necesitamos cambiar el paramétro Audit_trail del init.ora (por defecto “none”), podemos ver el estado de este parámetro con el comando “show parameter audit” POSIBLES VALORES DEL PARÁMETRO

AUDIT_TRAIL none: Auditoria de base de datos desactivada os: Activa la auditoría de la bd. Los sucesos se

escribirán en la pista de auditoría del SO, no se auditará en Oracle sino en el SO anfitrión.

db: Activa la auditoría y los datos se almacenarán en la taba SYS.AUD$ de Oracle.

xml: Activa la auditoría de la bd, sucesos escritos en ficheros XML.

ACTIVACIÓN DE LA AUDITORIA EN ORACLE El comando para activar la auditoría en Oracle es el siguiente:

VISTAS DEL DD CON RELACIÓN A LA AUDITORÍA

Oracle Database almacena en el diccionario de datos, en la tabla SYS.AUD$ o en la pista de auditoría del sistema operativo (si lo permite); Existen varias vistas que se basan en esta tabla (SYS.AUD$) para mostrar distintos resultados, según la información que se quiera obtener, las principales son:

DBA_AUDIT_OBJECT: lista de los registros de auditoría de todos los objetos del sistema

DBA_AUDIT_SESSION: guarda la información relativa a la auditoría de los inicios de sesión de los usuarios.

DBA_AUDIT_TRAIL: muestra la auditoría estándar (de la tabla AUD$).

USER_AUDIT_TRAIL: muestra la auditoría estándar (de la tabla AUD$) relativa al usuario actual.

DBA_FGA_AUDIT_TRAIL: muestra información de auditoría de grano fino (obtenida de FGA_LOG$). La auditoría de grano fino (FGA) extiende la auditoría estándar y, además, captura la sentencia SQL que ha sido ejecutada.

NOTA: Existen otras vistas más, para verlas todas podemos usar esta sentencia: SELECT view_name FROM dba_views WHERE view_name LIKE '%AUDIT%' ORDER BY view_name;

AUDITORÍA DE INICIO DE SESIÓN Cada intento de conexión con la base de datos por parte de un usuario(una aplicación externa o aplicaciones de Oracle) puede ser auditado. El comando para iniciar la auditoría de los intentos de inicio de sesión es, Audit Session, este comando auditará tanto los intentos fallidos como los aciertos.

Para auditar los inicios de sesión de la base de datos usaremos la sentencia “AUDIT SESSION” (la cual podemos filtrar por usuarios de la siguiente forma “AUDIT SESSION BY usuario1, usuario2;” Al igual que el comando AUDIT tenemos el comando NOAUDIT para desactivar la política de auditoría previamente activada.

AUDITORÍA DE INICIO DE SESIÓN

AUDITORÍA DE INICIO DE SESIÓN

AUDITORÍA DE INICIO DE SESIÓNPara auditar sólo los intentos fallidos se utiliza el comando: audit session whenever not successful; Para auditar sólo las conexiones correctas se utiliza el comando: Audit session whenever successful;

AUDITORÍA DE ACCIÓN Cualquier acción que afecte a un objeto de la base de datos (tabla, enlace de base de datos, espacio de tablas, sinónimo, segmento de anulación, usuario, índice, etc.) puede auditarse. Las posibles acciones que pueden auditarse (create, alter, drop) sobre estos objetos pueden agruparse para simplificar la cantidad de esfuerzo administrativo necesario para determinar y mantener las opciones de configuración de la auditoría.

Se puede auditar cualquier acción que afecte a cualquier objeto de la BD. Para facilitar la gestión, las acciones a auditar se encuentran agrupadas según los grupos que se muestran en la siguiente tabla:

AUDITARÍA DE ACCIÓN Pongámonos en la situación que por ejemplo vamos a auditar todas las sentencias que creen una tabla, para este ejemplo vamos a auditar los CREATE TABLE de VPY

AUDITORÍA DE OBJETO Además de las acciones a nivel de sistema sobre objetos, también es posible auditar las acciones de manipulación de datos sobre objetos.

Se pueden auditar operaciones de select, insert, update y delete (selección, inserción, modificación y borrado) sobre tablas. Este tipo de auditoría es similar a la anterior de auditoría de acción, la única diferencia es que el comando "Audit" incorpora un parámetro nuevo "by session" (el registro de auditoría se Estudio e Implantación de Audit Vault escribirá una única vez por sesión) o "by access" (el registro de auditoría se escribirá cada vez que se acceda al objeto auditado).

AUDITAR ACCIONES SOBRE UN OBJETO Auditando acciones sobre objetos tendremos seguridad sobre la actividad de los usuarios que han interactuado con ese objeto, vamos a ver como se audita una tabla.

AUDITAR ACCIONES SOBRE UN OBJETO

PROTECCIÓN DE LA TABLA SYS.AUD$

Los registros de la tabla SYS.AUD$ pueden ser objeto de intentos de acceso para ser eliminados ya que pueden reflejar acciones no autorizadas en la BD, por eso es importantereflejar ese tipo de acciones con el siguiente comando:audit all on sys.aud$ by access; De este modo cualquier acción contra la tabla SYS.AUD$ quedará registrado.

LOGS DE BASE DE DATOS Generalmente provistas con opciones que se configuran directamente en la base de datos (dependiendo del motor) e incluyen acciones como auditoría de sentencias, auditoría de privilegios y auditoría de objetos de la base de datos. La información generada se guarda en archivos propios de la base de datos. Es una opción costosa en recursos de almacenamiento y para revisar la información generada usualmente se requieren recursos adicionales tales como una herramienta para identificar y monitorear los eventos verdaderamente críticos

LOGMINER El Logminer es una herramienta de las bases de datos Oracle, que se utiliza para extraer sentencias DML directamente de los archivos de redo log. De estos es posible extraer la sentencia sql original que realizó la transacción y la sentencia que puede ser utilizada para deshacerla. Ayuda de una manera sencilla y comoda a interpretar los reso logs.

Para ver el valor inicial del log miner lo hacemos de la siguiente manera:

REGISTROS DE AUDITORÍA Requeridos únicamente cuando se modifican los datos en una tabla maestra o transaccional. A diferencia de los logs de base de datos son registros de “historia” y no se utilizan para registrar las conexiones a la base de datos o modificaciones al modelo de datos, sino que se enfocan en las modificaciones a los datos originadas desde cualquier origen. Su implementación es a través de “triggers”, típicamente antes o después de los eventos “insert”, “delete” o “update”. Se guarda la imagen del registro antes y después del evento, existiendo la opción de registrar la imagen de la fila entera, o registrar únicamente las columnas que han cambiado durante la operación.