TEMA 5

AUDITORIA A LAS BASES DE DATOS

5.1. Introducción
La gran difusión de los Sistemas de Gestión de Bases de Datos (SGBD), junto con la
congregación de los datos como uno de los recursos fundamentales de las empresas, ha
hecho que los temas relativos a su control interno y auditoría cobren cada día, mayor
interés.

5.2. Metodologías para la Auditoría de Bases de Datos

Aunque existen distintas metodologías que se aplican en auditoría informática. Se pueden

agrupar en dos clases.

5.2.1 .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 cuestionarios a verificar. Por ejemplo:

¿Existe una metodología de BD?

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

5.2.2. Metodología de evaluación de riesgos

Este tipo de metodología conocida también por RISK oriented approach, es la que propone
la ISACA, y empieza fijando los objetivos de control que minimizan los riesgos potenciales
a los que está sometido el entorno.

Objetivo de control:

El SGBD deberá preservar la confidencialidad de la base de datos

Una vez establecidos los objetivos de control, se especifican las técnicas específicas
correspondientes a dichos objetivos:

Técnica de control:
Se deberán establecer los tipos de usuario, 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. Esta 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 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
permiten dimensionar el impacto de estas deficiencias.

Pruebas sustantivas:
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 presentara un informe final en el que se expongan las
conclusiones más importantes a las que se ha llegado, así como el alcance que ha tenido la
auditoría.

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

5.3. Objetivos de control en el ciclo de vida de una base de datos

5.3.1. Estudio previo y plan de trabajo

En esta primera fase, es muy importante elaborar un estudio tecnológico de viabilidad en el

cual se contemplen distintas alternativas para alcanzar los objetivos del proyecto
acompañados de un análisis costo-beneficio para cada una de las opciones.
Se debe considerar entre estas alternativas la posibilidad de no llevar a cabo el proyecto
(no siempre está justificada la implantación de un sistema de bases de datos) así como la
disyuntiva entre desarrollar y comprar ( en la práctica, a veces nos encontramos con que se
ha desarrollado una aplicación que ya existía en el mercado, cuya compra hubiese supuesto
un riesgo menor, asegurándonos incluso una mayor calidad a un precio inferior)
Desafortunadamente, en bastantes empresas este estudio de viabilidad no se lleva a cabo
con el rigor necesario, con lo que a medida que se van desarrollando, los sistemas
demuestran, a veces, ser poco rentables.

El auditor debe comprobar también que la alta dirección revisa los informes de estudios de
viabilidad y que es la que decide seguir adelante o no con el proyecto. Esto es fundamental
porque los técnicos han de tener en cuenta que si no existe una decidida voluntad de la
organización en su conjunto, impulsada por los directivos, aumenta considerablemente el
riesgo de fracasar en la implantación del sistema.
En caso de que se decida llevar a cabo el proyecto es fundamental que se establezca un plan
director, debiendo el auditor verificar que efectivamente dicho plan se emplea para el
seguimiento y gestión del proyecto y que cumple con los procedimientos generales de
gestión de proyectos que tengan aprobados la organización

Otro aspecto muy importante en esta fase es la aprobación de la estructura orgánica no sólo
del proyecto en particular, sino también de la unidad que tendrá la responsabilidad de la
gestión y un control de la base de datos, recordemos que, para que un entorno de base de
datos funcione debidamente, esta unidad es imprescindible.

Se pueden establecer acerca de este tema dos objetivos de control. “ deben asignarse
responsabilidades para la planificación, organización, dotación de plantillas y control, de
los activos de datos de la organización (administrador de datos) y ” debe asignarse la
responsabilidad de la administración del entorno de la base de datos” (administrador de la
base de datos); señalando la mayor parte de los autores que ambas funciones tienen que
posicionarse a un nivel lo suficientemente alto en el organigrama para asegurar su
independencia.

En las figuras 5.1 y 5.2 se muestran algunas de las funciones y responsabilidades tanto del
administrador de datos como del administrador de la base de datos.

Realizar el diseño conceptual y lógico de la BD

Apoyar al personal de sistemas durante el desarrollo de aplicaciones
Formar al personal
Establecer estándares de diseño de BD, desarrollo y contenido del diccionario de datos
Diseñar la documentación incluida en el diccionario
Diseñar políticas de gestión de BD
Desarrollar planes estratégicos y tácticos parta la manipulación de los datos
Desarrollar los requisitos de los elementos del diccionario de datos
Controlar la integridad y seguridad de los datos
Planificar la evolución de la BD le empresa
Identificar oportunidades de compartición de datos
Trabajar con los auditores en la auditoria de la base
Proporcionar controles de seguridad

figura 5.1.Tareas del administrador de datos

Realizar el diseño físico de la BD
Asesorar en la adquisición de hardware / software
Soportar el SGBD
Resolver problemas del SGBD y del software asociado
Monitorizar el rendimiento del SGBD
Ayudar en el desarrollo de planes que aseguren la capacidad de hardware
Asegurar la integridad de los datos, comprobando que se implanten los controles
necesarios
Asegurar la confidencialidad y seguridad
Proporcionar facilidades de prueba
Integrar paquetes, procedimientos, utilidades, etc.
De soporte al SGBD
Desarrollar estándares, procedimientos y documentación.
Figura 5.2. Tareas del administrador de la base de datos

A la hora de detallar las responsabilidades de estas funciones hay que tener en cuenta uno
de los principios fundamentales del control interno: la separación de funciones. Se
recomienda una separación de funciones entre:

- el personal de desarrollo de sistemas y el de explotación

- explotación y control de datos
- administración de bases de datos y desarrollo

Debería existir también una separación de funciones entre el administrador de la seguridad

y el administrador de la base de datos. Esto no quiere decir que estas tareas tengan
forzosamente que desempeñarlas personas distintas (lo que no sería viable en muchas
pequeñas y medianas empresas) pero si que es un aspecto importante a considerar, por lo
que en caso de que no pueda lograrse la separación de funciones, deberán establecerse
controles compensatorios o alternativos; como, por ejemplo una mayor atención de la
dirección y la comprobación por parte de algún usuario del contenido y de las salidas más
importantes producidas a partir de la BD.

La situación que normalmente encuentra el auditor en las empresas es que al no existir una
descripción detallada de los puestos de trabajo (que incluyan responsabilidades,
conocimientos, etc), la separación de funciones es muy difícil de verificar.

5.3.2. Concepción de la base de datos y selección del equipo

En esta fase se empieza a diseñar la base de datos, por lo que deben utilizarse los modelos y
las técnicas definidos en la metodología de desarrollo de sistemas de la empresa.
La metodología de diseño debería también emplearse para especificar los documentos
fuentes, los mecanismos de control, las características de seguridad y las pistas de auditoría
a incluir en el sistema, estos últimos aspectos generalmente se descuidan, lo que produce
mayores costos y problemas cuando se quieren incorporar una vez concluida la
implementación de la base de datos y la programación de las aplicaciones.
El auditor debe por tanto en primer lugar, analizar la metodología de diseño con el fin de
determinar si es o no aceptable, y luego comprobar su correcta utilización. Como mínimo
una metodología de diseño de base de datos debería contemplar dos fases de diseño lógico
y físico, aunque la mayoría de las empleadas en la actualidad contemplan tres fases; además
de las dos anteriores, una fase previa de diseño conceptual que sería abordada en ese
momento del ciclo de vida de la base de datos.

5.3.2.1. Componentes básicos de una metodología

 Herramienta "cualquier recurso particular a disposición de la metodología para realizar

las operaciones que en ella se prevén", BATINI ET AL. (1981); diagramas, grafos,
teorías, etc.

 Modelo de datos "conjunto de conceptos, reglas y convenciones que permiten describir

y manipular los datos de la parcela del mundo real que constituye nuestro universo del
discurso".

 Un Lenguaje de datos está siempre basado en un determinado modelo de datos y es el

resultado de definir una sintaxis para el mismo, lo que va a permitir expresar un
esquema.

 La documentación nos permitirá describir de forma normalizada los resultados de cada

etapa, facilitando así la labor del diseñador y ayudando al mantenimiento de la base.

 Las reglas actuarán sobre los elementos de entrada en cada fase para conseguir (de
manera semiautomática) las salidas de cada una de ellas, permitiendo en algunos casos
elaborar distintas alternativas de diseño.

En cuanto a la selección del equipo, en caso de que la empresa no disponga ya de uno,

deberá realizarse utilizando un procedimiento riguroso; en el que se consideren, por un
lado, las necesidades de la empresa (debidamente ponderadas) y, por otro, las prestaciones
que ofrecen los distintos SGBD candidatos (puntuados de manera oportuna).

5.3.3. Diseño y carga

En esta fase se lleva a cabo los diseños lógico y físico de la base de datos, por lo que el
auditor tendrá que examinar si estos diseños se han realizado correctamente; determinando
si la definición de los datos contemplan además de su estructura, las asociaciones y las
restricciones oportunas, así como las especificaciones de almacenamiento de datos y las
cuestiones relativas a la seguridad. El auditor tendrá que tomar una muestra de ciertos
elementos (tablas, vistas, índices) y comprobar que su definición es completa, que ha sido
aprobada por el usuario y que el administrador de la base de datos participo en su
establecimiento.

Una vez diseñada la BD, se procederá a su carga, ya sea migrando datos de un soporte
magnético o introduciéndolos manualmente.
Las migraciones o conversiones de sistemas, como el paso de un sistema de ficheros a uno
de bases de datos, o de un tipo de SGBD (de jerárquico a relacional), entrañan un riesgo
muy importante, por lo que deberán estar claramente planificados para evitar pérdida de
información y la transmisión del nuevo sistema de datos erróneos. También se deberán
realizar las pruebas en paralelo, verificando que la decisión real de dar por terminada la
prueba en paralelo se atenía a los criterios establecidos por la dirección y que se haya
aplicado un control estricto de la corrección de errores detectados en esta fase.

Por lo que respecta a la entrada manual de datos, hay que establecer un conjunto de
controles que aseguren la integridad de los mismos. A este respecto, cabe destacar que las
declaraciones escritas de procedimientos de la organización referentes a la entrega de datos
a ser procesados deben asegurar que los datos se autorizan, recopilan, preparan, transmiten,
y se comprueba su integridad de forma apropiada.
También es aconsejable que los procedimientos y el diseño de los documentos fuentes
minimicen los errores y las omisiones, así como el establecimiento de unos procedimientos
de autorización de datos.

Un aspecto muy importante es el tratamiento de datos de entrada erróneos, para los que
deben cuidarse con atención los procedimientos de re introducción de forma que no
disminuyan los controles, a este respecto lo ideal es que los datos se validen y corrijan tan
cerca del punto de origen como sea posible.
Como sabemos, no toda la semántica de los datos puede siempre almacenarse en el
esquema de la base de datos, por lo que parte de esta semántica se ve obligada a residir en
los programas. Será necesario, por tanto, comprobar que los programas implementan de
forma adecuada esta integridad.

5.3.4. Explotación y mantenimiento

Una vez realizadas las pruebas de aceptación, con la participación de los usuarios, el
sistema se pondrá (mediante las correspondientes autorizaciones y siguiendo los
procedimientos establecidos para ello) en explotación.

En esta fase, se debe comprobar que se establecen los procedimientos de explotación y

mantenimiento que aseguren que los datos se tratan de forma congruente y exacta y que el
contenido de los sistemas sólo se modifica mediante la autorización adecuada.

Sería conveniente también que el auditor pudiera llevar a cabo una auditoría sobre el
rendimiento del sistema de BD, comprobando si se lleva a cabo un proceso de ajuste y
optimización adecuados que no sólo consiste en el rediseño físico o lógico de la BD, sino
que también abarca parámetros del SO e incluso la forma en que acceden las transacciones
a la BD. Recordemos que “la función de administración de la base de datos debe ser la
responsable de monitorizar el rendimiento y la integridad de los sistemas de BD”.

5.3.5. Revisión post-implantación

Aunque en bastantes organizaciones no se lleva a cabo, por falta de tiempo y recursos, se
debería establecer el desarrollo de un plan para efectuar una revisión post-implantación de
todo sistema nuevo modificado con el fin de evaluar si:
- Se han conseguido los resultados esperados
- Se satisfacen las necesidades de los usuarios.
- Los costes y beneficios coinciden con los previstos.

5.3.6. Otros procesos auxiliares

A lo largo de todo el ciclo de vida de la base de datos se deberá controlar la formación que
precisan tantos usuarios informáticos (administrador, analistas, programadores, etc.) como
no informáticos, ya que la formación es una de las claves para minimizar el riesgo en la
implantación de una base de datos.
Esta formación no se puede basar simplemente en cursos sobre el producto que se esta
instalando, sino que suele ser precisa una formación de base que resulta imprescindible
cuando se pasa de trabajar de un entorno de ficheros orientado al proceso a un entorno de
bases de datos, por lo que supone de “cambio filosófico; lo mismo puede decirse que se
cambia de tipo de SGBD (por ejemplo, de relacional a orientado a objetos)
Hay que tener en cuenta que usuarios poco formados constituyen uno de los peligros más
importantes de un sistema. Esta formación no debería limitarse al área de las bases de
datos, sino que tendría que ser complementada con formación relativa a los conceptos de
control y seguridad.
Además, el auditor tendrá que revisar la documentación que se produce a lo largo de todo
el proceso, para verificar si es suficiente y si se ajusta a los estándares establecidos por la
metodología adoptada por la empresa.
Al respecto resulta muy importante que se haya llevado a cabo un aseguramiento de
calidad, como por ejemplo a través de la normalización.

5.4. Auditoría y control interno en un entorno de Bases de Datos

Cuando el auditor se encuentra en el sistema en explotación, deberá estudiar el SGBD y su

entorno. El gran problema de las BD es que su entorno es cada vez más complejo y no
puede limitarse sólo al propio SGBD.
En la siguiente figura se muestra un posible entorno de bases de datos en el que aparecen
los elementos más usuales:

5.4.1. Sistema de gestión de Bases de Datos (SGBD)

Entre los componentes del SGBD podemos destacar el núcleo (kernel), el catálogo
(componente fundamental para asegurar la seguridad de la base de datos), las utilidades
para el administrador de la base de datos (entre las que suelen encontrar algunas para crear
usuarios, conceder privilegios y resolver otras cuestiones relativas a la confidencialidad);las
que se encargan de la recuperación de la BD.: rearranque, copias de respaldo, ficheros
diarios y algunas funciones de auditoría, así como los lenguajes de cuarta generación
(L4G)que incorpora el propio SGBD.
En cuanto a las funciones de auditoría que ofrece el propio sistema, prácticamente todos los
productos del mercado permiten registrar ciertas operaciones realizadas sobre la base de
datos en un fichero (o en un conjunto de tablas) de pistas de auditoría. El propio modelo de
referencia de gestión de datos ISO 1993) considera las pistas de auditoría como un
elemento esencial del SGBD, señalando que “el requisito para la auditoría es que la causa y
el efecto de todos los cambios de la base de datos sean verificables”.
El auditor deberá revisar, por tanto, la utilización de todas las herramientas que ofrece el
propio SGBD y las políticas y procedimientos que sobre su utilización haya definido el
administrador, para valorar si son suficientes o si deben ser mejorados.