AUDITORIA DE

BASE DE DATOS
 INTENGRANTES

Balladares Romero
Madriz Torrez
Martínez Gómez
Payan Duarte
 AUDITORIA 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.
 AREAS A AUDITAR

Controles en aplicaciones

Cada aplicación debe llevar controles incorporados para

garantizar la entrada, actualización, validez y
mantenimiento completos y exactos de los datos. Las
cuestiones más importantes en el control de los dalos
son:
 Control de entrada de datos: procedimientos
de conversión y, de entrada, validación y
01 corrección de datos.

Controles de tratamientos de datos para

asegurar que no se dan de alta modifican o
02 borran datos no autorizados para garantizar la
integridad de los mismos mediante procesos
no autorizados.

Controles de salidas de dalos: sobre el

03 cuadre y reconciliación de salidas,
procedimientos de distribución de salidas,
de gestión de errores en las salida.
 Controles en Sistemas de Gestión de Bates de Dalos

 El software de gestión de bases de datos para prever el acceso a, la estructuración y

control sobre los dalos compartidos, deberá instalarse y mantenerse de modo tal que
asegure la integridad del software, las bases de dalos y las instrucciones de control que
definen el entorno

 Que están definidas las responsabilidades sobre la planificación. Organización dotación

y control de los activos de datos, es decir, un administrador de datos.

 Que existen procedimientos para la descripción y cambios de datos, así como para el
mantenimiento del diccionario de dalos.

 Controles sobre el acceso a datos y de concurrencia.

 Controles para minimizar fallos, recuperar el entorno de las bases de
datos hasta el punto de la caída y minimizar el tiempo necesario para
recuperación.

 Controles para asegurar la integridad de los dalos: programas de

utilidad para comprobar los enlaces físicos -punteros- asociados a los
datos, registros de control para mantener los balances transitorios de
transacciones para su posterior cuadre con totales generados por el
usuario o por otros sistemas.
METODOLOGÍAS PARA LA
AUDITORÍA DE BASES DE
DATOS

Aunque existen distintas metodologías que se aplican en

auditoria informática (prácticamente cada firma de auditores
y cada empresa desarrolla la suya propia), se pueden agrupar
en dos clases.
 Metodología tradicional

En este tipo de metodología el auditor revisa el entorno con la ayuda de una lista de control
(checklist), que consta de una serie de cuestiones a verificar. Por ejemplo:
¿Existe una metodología de diseño de BD? S N NA

El auditor deberá, registrar el resultado de su investigación: S, si la respuesta es afirmativa, N,

en caso contrario, o NA (no aplicable).

Este tipo de técnica suele ser aplicada a la auditoría de productos de bases de datos,
especificándose en la lista de control todos los aspectos a tener en cuenta. Así, por ejemplo, si el
auditor se enfrenta a un entorno Oracle 8, en la lista de control se recogerán los parámetros de
instalación que más riesgos comportan, señalando cuál es su rango adecuado. De esta manera, si
el auditor no cuenta con la asistencia de un experto en el producto, puede comprobar por lo
menos los aspectos más importantes de su instalación.
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

 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.
 Objetivo de Control
El SGBD deberá preservar la confidencialidad de la base
de datos.

Una vez establecidos los objetivos de control, se especifica

las técnicas específicas correspondientes a dichos
objetivos.
 Técnica de Control

Se deberán establecer los tipos de usuarios,

perfiles y privilegios necesarios para
controlar el acceso a la base de datos.
Un objetivo de control puede llevar asociadas varias técnicas que permiten
cubrirlo en su totalidad. Estas técnicas pueden ser preventivas (como la arriba
mencionada)" detectivas (como monitorizar los accesos a la BD) o correctivas
(por ejemplo, una copia de respaldo-backup-).

En caso de que los controles existan, se diseñan unas pruebas (denominadas

pruebas de cumplimiento) que permiten verificar la consistencia de los mismos,
por ejemplo:
 Prueba de cumplimiento

Listar los privilegios y perfiles existentes en el SGBD

Si estas pruebas detectan inconsistencias en los controles, o bien, si los

controles no existen, se pasa a diseñar otro tipo de pruebas-denominadas
pruebas sustantivas que permitan dimensionar el impacto de estas deficiencias
 Prueba sustantiva

Comprobar si la información ha sido corrompida comparándola con otra fuente, o

revisando los documentos de entrada de datos y las transacciones que se han
ejecutado.

Una vez valorados los resultados de las pruebas se obtienen unas conclusiones que
serán comentadas y discutidas con los responsables directos de las áreas afectadas
con el fin de corroborar los resultados. Por último, el auditor deberá emitir una serie
de comentarios donde se describa la situación, el riesgo existente y la deficiencia a
solucionar, y, en su caso, sugerirá la posible solución.
Como resultado de la auditoría, se presentará un informe
final en el que o expongan las conclusiones más importantes
a las que se ha llegado, así como el alcance que ha tenido la
auditoría.

Ésta será la técnica a utilizar para auditar el entorno general

de un sistema de bases de datos, tanto en su desarrollo como
durante la explotación.
 Los controles

Cuando se plantea la forma más adecuada de hacer la auditoría, existe

además la interrogante de ¿cuál es el lugar más adecuado para
implantar los controles? Existen tres posibilidades, la primera es poner
los controles en el nivel de las aplicaciones, es decir, directamente en
los programas o interfaces del usuario. La segunda posibilidad es
ponerlos en medio de las aplicaciones y la base de datos, lo que
llamamos controles en la red y la tercera posibilidad es ubicar el
control en la base de datos, lo que se llama control en la fuente.
 Los controles en las aplicaciones
La primera alternativa implica que, a cada sistema, módulo o programa,
se le debe adicionar el control; esto implica modificaciones de código,
compilaciones de programas y otros procesos necesarios para asegurar
que todas las aplicaciones contengan el control.

Esta alternativa resulta ser muy vulnerable, ya que es posible acceder a

la base de datos por otros medios. Tiene la desventaja de la actualización
del control, con esto se quiere decir que, si el control sufre alguna
modificación, entonces será necesario actualizar todas las aplicaciones,
y en este caso es posible que alguna quede sin actualizar.
 Los controles en la red

La segunda alternativa, que consiste en poner el control entre el usuario y la

base de datos, significa realmente tenerlo en la red.

Esta alternativa tiene la ventaja de un único control, ubicado en una

posición estratégica fácil de modificar y de administrar. El control es como
un programa espía que captura todos los mensajes entre los usuarios y la
base de datos, se puede capturar todos los estatutos de tipo SQL, entre ellos
y las actividades de conexión, las horas y días que ellos interactúan. Existe
un único problema en esta alternativa de ubicación, que consiste en conocer
cómo eran los valores de los datos antes y después de que el usuario los
actualizara.
Por ejemplo, imaginase que una tabla de la base de datos tiene el monto de un recibo
pendiente de pagar, si un usuario no autorizado puede de alguna forma cambiar este
valor, sería difícil conocer el monto anterior del recibo, ya que el programa espía lo
que detecta es que el usuario envió una sentencia de actualización como la siguiente:

Update recibo set saldo = 10,000

where recibo = 34,567

En este ejemplo perdemos la información del monto anterior. El programa espía sólo
graba la sentencia, pero no el valor, esto puede traer consecuencias no deseadas en el
departamento de cuentas por cobrar.
 Control en la fuente

La tercera alternativa es la de poner el control directamente en la base de

datos. Al igual que la segunda, hablamos de un único control, fácil de
implementar y de administrar. Con esta alternativa y en este caso sí es
posible conocer los valores de los datos antes y después de la actualización,
ya que podemos utilizar mecanismos de la base de datos que permiten llegar
a ese nivel.
 Tipos de auditorías de bases de datos
Consideramos dos grandes tipos de auditorías de la base de datos, esta división está relacionada
directamente con las actividades que los usuarios realizan, suponga que un usuario desea cambiar la
dirección de envío de pedidos a un cliente. Para lograr esto se requiere que el usuario realice una serie de
pasos, por ejemplo:

1. Conectarse a la base de datos.

2. Ejecutar el cambio de dirección.
3. Desconectarse.

Los pasos 1 y 3 se lograrían si cuenta con los privilegios o derechos necesarios para conectarse o
desconectarse; para el paso 2 el usuario debe tener privilegios de acceso a la tabla de clientes, y la
posibilidad de hacer una modificación. Basándonos en esta secuencia de pasos establecemos el primer
tipo de auditoría, y la llamamos auditoría de actividades de los usuarios.

El segundo tipo de auditoría está inmersa en el paso 2. ¿Qué ocurrió realmente cuando cambió el dato,
qué valores quedaron?, ¿qué valores había?, en otras palabras, ¿qué cambios produjo la transacción? Los
controles que establezcamos para conocer lo que realmente ocurrió los llamaremos auditoría de
transacciones.
 Auditoría de actividades
El primer tipo de auditoría lo llamamos auditoría de actividades, que
consiste en controlar las actividades que realizan los usuarios en los
objetos de la base de datos y entenderemos como objetos todas las tablas,
vistas, restricciones de integridad que los usuarios crean en la base de
datos.

Este proceso de monitoreo de las actividades de los usuarios permite

encontrar posibles accesos a objetos no autorizados, conexiones en horas
o días fuera de horarios normales. Toda esta actividad se va almacenando
en una tabla o en un archivo que llamaremos el registro de auditoría.
El registro de auditoría (RA) tiene un
crecimiento muy alto, por lo que es necesario
administrarlo adecuadamente, muchas veces
este registro llega a ser igual o mayor en
tamaño que la base de datos.

Imagínese el RA de una organización de más

de 2000 empleados, que además permite el
acceso de clientes por Internet, o el registro de
auditoría de un banco, que puede recibir más
de 20 transacciones por minuto.
 Auditoría de transacciones
La auditoría de transacciones consiste en implementar una serie de
controles que permiten llevar una bitácora de todas las transacciones que
los usuarios realizan, pero a un nivel tal que podamos establecer una
historia de cómo se produjeron los cambios. Al igual que en el tipo
anterior, es necesario crear un registro de auditoría al que llamaremos
registro de auditoría de transacciones (RAT). El crecimiento del RAT es
superior al del RA, ya que es posible que un usuario que se conecte una
sola vez, pueda hacer 30 transacciones. En este caso el RA almacena las
actividades de conexión y desco-nexión, básicamente mientras que el
RAT almacena 30 registros correspondientes a la información antes y
después de cada transacción.
La administración del registro de auditoría

El gran volumen de información que se almacena en el RA y el RAT hace

pensar en algunas organizaciones donde este control puede ser innecesario,
que el costo de almacenamiento es muy alto, y el rendimiento de la base de
datos se puede ver afectado. Es posible que tengan razón, y eviten con estas
justificaciones establecer los controles, dejando la base de datos
completamente vulnerable.
Es necesario pensar entonces en una serie de consideraciones respecto a la
administración del RA, para evitar que afecte y se opte por eliminarlo, dos de
las principales recomendaciones son:

• Audite sólo lo necesario o sólo las excepciones.

• Haga respaldo y limpieza del RA y el RAT.
Como buena práctica, es necesario analizar qué tipo de información deseamos
auditar, qué es relevante y qué no, qué nos sirve en una investigación y qué
información no tiene sentido auditar, de este modo no produciremos tanta
información y se disminuye la posibilidad de afectar el rendimiento del
servidor.
Gracias!!
CREDITS: This presentation template was created by Slidesgo,
including icons by Flaticon, and infographics & images by Freepik