Auditoría de base de datos

1. Auditoría de base de datos
Lic. Mario Cesar Alvarez Patty
DESARROLLO DE SISTEMAS DE INFORMACION CONTABLE

2. AUDITORÍA DE BASE DE DATOS
Es 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

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

4. IMPORTANCIA
Toda 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ón
Las organizaciones deben mitigar los riesgos asociados a la perdida de
datos y a la fuga de información
La 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.

5. ACCIONES AUDITABLES
Se 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.

6. RECOLECCIÓN DE DATOS
Sentencias SQL: Registro de los intentos de conexión con la base d
datos
Privilegios: Recopila las operaciones que se han efectuado sobre la base
de datos y los usuarios
Objetos: 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.

7. EVALUACIÓN DE LA AUDITORÍA
Definición de estructuras físicas y lógicas de las bases de datos
Control de carga y mantenimiento de las bases de datos
Integridad de los datos y protección de accesos
Estándares para análisis y programación en el uso de bases de datos
Procedimientos de respaldo y de recuperación de datos

8. PLANIFICACIÓN
1. 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.

9. MÉTODOLOGIAS PARA
AUDITAR BASES DE DATOS

10. 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.

11. 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 programas
Rupturas por accesos no autorizados

12. PISTAS DE AUDITORÍA

13. PISTAS DE AUDITORÍA
Las 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.

14. 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.

15. 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.

16. 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.

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

18. 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.

19. 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;

20. 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.

21. AUDITORÍA DE INICIO DE SESIÓN

22. AUDITORÍA DE INICIO DE SESIÓN

23. AUDITORÍA DE INICIO DE SESIÓN
Para 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;

24. 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:

25. 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

26. 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).

27. 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.

28. AUDITAR ACCIONES SOBRE UN OBJETO

29. 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 importante
reflejar 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.

30. 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

31. 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:

32. 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.