PDF de programación - Auditoria de base de datos

\AUDITORIA DE BASE DE DATOS

INDICE
01. Introducción
02. Metodologías para la auditoría de bases de datos.
03. Estudio previo y plan de trabajo.
04. Concepción de la base de datos y selección del equipo.
05. Diseño y carga
06. Explotación y mantenimiento.
07. Revisión post­implantación.

01. INTRODUCCION

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

Normalmente la auditoria informática se aplica de dos formas distintas;  por un lado se 
auditan las principales áreas del departamento de informática:  explotación,  dirección, 
metodología de desarrollo,   sistema operativo,   telecomunicaciones,   bases de datos, 
etc.;  
  se   auditan   las   aplicaciones   desarrolladas   internamente, 
(subcontratadas   o   adquiridas)   que   funcionan   en   la   empresa.     La   importancia   de   la 
auditoria del entorno de bases de datos radica en que es el punto de partida para poder 
realizar la auditoria de las aplicaciones que utilizan esta tecnología.

  por   otro,  

  y,  

02. METODOLOGÍAS PARA LA AUDITORÍA DE BASES DE DATOS.

Aunque   existen   distintas   metodologías   que   se   aplican   en   auditoría   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 Base de Datos?     S              N      NA

(S es si,  N  no  y NA  no aplicable),  debiendo registrar el auditor el resultado de su 
investigación.

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. 

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.  A continuación,  una lista de los riesgos más importantes según 2 autores:

● Incremento   de   la   “dependencia”   del   servicio   informático   debido   a   la 

concentración de datos

● Mayores posibilidades de acceso en la figura del administrador de la base de 

datos

● Incompatibilidad entre sistemas de seguridad de acceso  propios del SGBD y el 

general de la instalación.

● Mayor   impacto   de   los   errores   en   datos   o   programas   que   en   los   sistemas 

tradicionales

● Ruptura de enlaces o cadenas por fallos del software o de los programas de 

aplicación

● Mayor impacto de accesos no autorizados al diccionario de la base de datos que 

a un fichero tradicional.

● Mayor dependencia del nivel de conocimientos técnicos del personal que realice 
tareas   relacionadas   con   el   software   de   base   de   datos   (administrador, 
programadores,  etc.)

Como en la auditoría de desarrollo, se puede seguir la misma metodología,  donde se 
establecen primeramente:

Objetivo de control  (ejemplo:   El SGBD deberá preservar la confidencialidad de la 
base de datos).
Técnicas de control. Una vez establecidos los objetivos de control,  se especifican las 
técnicas específicas correspondientes a dichos objetivos (ejemplo: Se deberán establecer 
los tipos de usuarios, perfiles y privilegios necesarios para controlar el acceso a las 
bases de datos).
Un objetivo de control puede llevar asociadas varias técnicas que permiten cubrirlo en 
su totalidad.   Estas técnicas pueden ser preventivas,   detectivas (como monitorizar la 
BD) o correctivas (por ejemplo,  una copia de respaldo  o backup).
Pruebas de cumplimiento.  En caso de que los controles existan,   se diseñan unas 
pruebas (denominada pruebas de cumplimiento)  que permiten verificar la consistencia 
de los mismos.  Por ejemplo: 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 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.
Esta será la técnica a utilizar para auditor el entorno general de un sistema de bases de 
datos,  tanto en su desarrollo como durante la explotación.
 PRINCIPALES OBJETIVOS DE CONTROL EN EL CICLO DE VIDA DE UNA 
BASE DE DATOS

Revisión 

post­

implantació

nn

Concepción 
de la BD y 
selección 
del equipo
dd

Diseño y 
carga
cc

Explotació

n y 

mantenimi

entoe

Estudio 
previo y 
plan de 
trabajo
tt

  

 

 

 

 

 

 

 

03. 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 de 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 base de datos) así como la 
disyuntiva entre desarrollar y comprar (en la práctica, a veces encontramos con que se 
ha   desarrollado   una   aplicación   que   ya   existía   en   mercados,     cuya   compra   hubiese 
supuesto un riesgo menor,   asegurándonos incluso una mayor cantidad a un precio 
inferior).
Lamentablemente,  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 ser poco rentables.
El auditor debe comprobar también que la alta dirección revisa los informes de los 
estudios de viabilidad y que es la que decide seguir adelante o no con el proyecto.  Esto 
es fundamental porque los técnicos que 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 de 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 importante en esta fase es la aprobación de la estructura orgánica del 
proyecto en particular,  sino también de la unidad que tendrá la responsabilidad de la 
gestión y control de la base de datos;  recordemos que,  para que un entorno de base de 
datos funcione debidamente,  esta unidad es imprescindible.
 

Tareas del administrador de datos

o Realizar el diseño conceptual y lógico de la base de datos
o Apoyar al personal de sistemas durante el desarrollo de aplicaciones
o Formar al personal
o Establecer estándares de diseño de b.d. desarrollo y contenido del diccionario de 

datos

o Desarrollar políticas de gestión de datos
o Desarrollar planes estratégicos y tácticos para la manipulación de  los datos
o Desarrollar los requisitos de los elementos del diccionario de datos
o Desarrollar normas para la denominación
o Controlar la integridad y seguridad de los datos
o Planificar la evolución de la bd de la empresa
o Identificar oportunidades de compartición de datos
o Trabajar con los auditores en la auditoría de la base de d.
o Proporcionar controles de seguridad
o Realizar el diseño físico de la b.d.
o Asesorar en la adquisición de hw y sw
o Soportar el SGBD
o Resolver problemas del SGBD y del software asociado
o Monitorizar el rendimiento del SGBD
o Ayudar en el desarrollo de planes que aseguren la capacidad hw.
o Asegurar la integridad de los datos,  comprobando que se implantan los 

controles adecuados

o Asegurar la seguridad y confidencialidad
o Proporcionar facilidades de prueba
o Integrar paquetes, procedimientos, utilidades, etc. De soporte para al SGND
o Desarrollar estándares,  procedimientos y documentarlos

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:

o El personal de desarrollo de sistemas y el de explotación
o Explotación y control de datos
o Administración de base de datos y desarrollo 

Debería existir también una separación de funciones entre el administrador de 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 y 
pequeñas y medianas empresas)   pero sí que es un aspecto importante de control 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 el auditor