Sunteți pe pagina 1din 32

ANDRES ROLON

RICARDO SILVA
AUDITORÍA DE BASE DE DATOS OSCAR LOPEZ
CAMILO ANDRES
XABITH MORA
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
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
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.
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.
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.
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
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.
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 programas
Rupturas por accesos no autorizados
PISTAS DE AUDITORÍA
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.
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Ó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;
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 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.
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.

S-ar putea să vă placă și