ÍNDICE

CAPÍTULO 1: INFORMACIÓN DE LA EMPRESA ................................Error! Bookmark not defined.

1.1. Razón Social.........................................................................Error! Bookmark not defined.
1.2. Descripción de la Empresa ..................................................Error! Bookmark not defined.
1.2.1. Ubicación Geográfica ......................................................Error! Bookmark not defined.
1.2.2. Estructura Orgánica .........................................................Error! Bookmark not defined.
1.2.3. Misión ..............................................................................Error! Bookmark not defined.
1.2.4. Visión ...............................................................................Error! Bookmark not defined.
1.2.5. Objetivos .........................................................................Error! Bookmark not defined.
1.3. Matriz FODA ........................................................................Error! Bookmark not defined.
1.4. Diagrama de contexto .........................................................Error! Bookmark not defined.
1.4.1. Stakeholders Externos .....................................................Error! Bookmark not defined.
1.4.2. Stakeholders Internos .....................................................Error! Bookmark not defined.
CAPÍTULO 2: AUDITORÍA DE BASE DE DATOS ............................................................................... 3
2.1. Definición .......................................................................................................................... 3
2.2. Objetivos ........................................................................................................................... 3
2.3. Importancia ....................................................................................................................... 3
2.4. Recolección de datos......................................................................................................... 4
2.5. Metodologías .................................................................................................................... 4
2.5.1. Tradicional ..................................................................................................................... 5
2.5.2. De evaluación de riesgos ............................................................................................... 5
2.6. Objetivos de control en el ciclo de vida de una base de datos ......................................... 6
2.6.1. Estudio previo y plan de trabajo ................................................................................... 6
2.6.2. Concepción de la base de datos y selección de equipo ................................................ 8
2.6.3. Diseño y carga ............................................................................................................... 9
2.6.4. Explotación y mantenimiento ....................................................................................... 9
2.6.5. Revisión post-implantación ......................................................................................... 11
CAPÍTULO 3: INFORME DE AUDITORÍA DE BASE DE DATOS........................................................ 11
3.1. Introducción .................................................................................................................... 11
3.2. Alcance ............................................................................................................................ 11
3.3. Justificación ..................................................................................................................... 11
3.4. Objetivos ......................................................................................................................... 11
3.5. Metodología utilizada ..................................................................................................... 11
3.6. Estudio previo y plan de trabajo ..................................................................................... 11
3.7. Concepción de la base de datos y selección de equipo .................................................. 11
3.8. Diseño y carga ................................................................................................................. 11
3.9. Explotación y mantenimiento ......................................................................................... 11
3.10. Revisión post-implantación ......................................................................................... 11
3.11. Auditoría de SQL Server .............................................................................................. 11
3.12. Hallazgos Potenciales (Resultados) ............................................................................. 11
3.13. Conclusiones................................................................................................................ 11
3.14. Recomendaciones ....................................................................................................... 11
BIBLIOGRAFIA .............................................................................................................................. 11
ANEXOS ....................................................................................................................................... 11
CAPÍTULO 2: AUDITORÍA DE BASE DE DATOS
1.1. Definición

Las bases de datos son componentes esenciales en los sistemas computacionales.

Al final, es en ellos que las empresas confían para mantener sus datos de forma
segura y consistente. Para que estas cualidades sean garantizadas, es importante que
la auditoría en base de datos sea una política de la organización.
La 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:

 Quién accede a los datos.

 Cuándo se accedió a los datos.
 Desde qué tipo de dispositivo/aplicación.
 Desde qué ubicación en la red a accedido.
 Cuál fue la sentencia SQL ejecutada.
 Cuál fue el efecto del acceso a la base de datos.

1.2. Objetivos

 Investigar actividades dudosas sobre la BD.

 Recopilar información acerca de actividades específicas de la BD.
 Recopilar estadísticas sobre qué tablas actualizadas, E/S lógicas, cantidad
de usuarios conectados concurrentes.
 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.
 Evitar acciones criminales.

1.3. Importancia

La auditoría en la base de datos ayuda a mantener y entender la actividad de la base

de datos, obteniendo así información sobre discrepancias o anomalías que pudieran
existir.
Esto es esencial para identificar posibles preocupaciones en el negocio o sospechas
de violaciones de seguridad en los sistemas de las organizaciones. Con la auditoría
es posible:
 Definir categorías de acciones a ser auditadas.
 Utilizar informes previamente configurados para analizar las operaciones.
 Encontrar acontecimientos sospechosos, actividades inusuales y tendencias.
La necesidad de auditoría aumenta según se utiliza la base de datos. Las
metodologías usadas en este proceso pueden ser desarrolladas por la propia
 empresa. La idea es establecer qué ítems deben ser revisados, de acuerdo con las
necesidades de la compañía, para garantizar la seguridad del sistema.
1.4. Recolección 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.
Esta tabla es AUD$ para las auditorías normales y FGA_LOG$ para las auditorías
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.
 Sentencias SQL: Registro de los intentos de conexión con la base de
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.

1.5. Metodologías

Siguiendo la metodología de auditoría propuesta por la ISACA, se empezaría

fijando los objetivos de control que minimizan los riesgos potenciales a los que está
sometido el entorno de la Base de Datos.
Considerando estos riesgos, se podría definir por ejemplo en siguiente:

Objetivo de control
El SGBD deberá preservar la confidencialidad de la base de datos.

Técnica de Control
Una vez establecidos los objetivos de control, se especifican las técnicas
específicas correspondientes a dichos objetivos, por ejemplo: 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 permitan
cubrirlo en su totalidad. Estas técnicas pueden ser preventivas (como la arriba
mencionada), detectivas (como, por ejemplo, monitorizar los accesos al BD), o
correctivas (por ejemplo, uno copia de respaldo –backup-).

Prueba de Cumplimiento
 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: listar los privilegios y perfiles 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 valorado 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 obtenidos. Por último, el auditor deberá
emitir una serie de comentarios donde se describa la situación, el riesgo existente,
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 se
expongan las conclusiones más importantes a las que se ha llegado, así como el
alcance que ha tenido la auditoria.
Esta será la técnica a utilizar para auditar el entorno general de un sistema de base
de datos, tanto en su desarrollo como en la explotación.

1.5.1. 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 base
de datos, especificándose en la lista de control todos los aspectos a tener en
cuenta.

1.5.2. 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 estos dos
autores:
  Incremento de la “dependencia” del servicio debido a la
concentración de datos.
 Mayores posibilidades de acceso en la figura del administrados 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.)
Al igual que en la auditoria de desarrollo, se puede seguir la misma
metodología, donde se establezcan principalmente:
 Objetivo Control
 Técnicas de Control
 Pruebas de Cumplimiento
 Prueba Sustantiva

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

A continuación, expondremos algunos objetivos y técnicas de control más

específicos a tener en cuenta a lo largo del ciclo de vida de una base de datos, que
abarca desde el estudio previo hasta su explotación.

Figura 1: Ciclo de vida de una base de datos

1.6.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 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 nos 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 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 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 implementación de Sistema.

Es importante destacar la necesidad de llevar a cabo una gestión de riesgos

(valoración, identificación, medida, plan de acción y aceptación), que es
objeto de atención, afortunadamente de un número cada día mayor de
organizaciones.

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 control de la base de datos;
recordemos que, para que un entorno de base de datos funcione
debidamente, esta unidad es imprescindible.

A la hora de detallar las responsabilidades de estas funciones hay que tener

en cuenta uno de los principios fundamentales de 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 áreas 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 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: 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 encuentra normalmente 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.
1.6.2. Concepción de la base de datos y selección de equipo

En esta fase se empieza a diseñar la base de datos. 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 BD
debería contemplar dos fases de diseño: lógico y físico, aunque la mayoría
de los empleados en la actualidad contempla 3 fases: además de las dos
anteriores, una fase previa de diseño conceptual que sería abordada en este
momento del ciclo de vida de la base de datos.

Un punto importante a considerar, objetivos de control relativos a:

o Modelo de arquitectura de información y su actualización, que es

necesaria para el modelo consistente con las necesidades de los usuarios
con el plan estratégico de tecnologías de la información.
o Datos corporativo o esquema de clasificación
o Esquema de clasificación de datos en cuanto a seguridad.
o Niveles de seguridad para cada anterior clasificación de datos.

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

ya de uno, deberá realizarse utilizando procedimiento riguroso; en el que se
considere, 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).
1.6.3. Diseño y carga

En esta fase se llevarán 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 datos con
contemplan además 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 participó en su establecimiento.

Es importante que la dirección del departamento de informática, los

usuarios e incluso, en algunas ocasiones, la alta dirección, aprueben el
diseño de los datos, al igual que el de las aplicaciones.

Una vez diseñada una BD se procederá a su carga, ya sea migrando datos d

e un soporte magnético o introduciéndolos manualmente.

Las migraciones o conversiones de sistemas, con el paso de un sistema de

ficheros a uno de base de datos, o de un tipo de SGBD (de jerárquico o
racional), entrañan un riesgo muy importante, por lo que deberán estar
claramente planificadas para evitar pérdida de información y la transmisión
al nuevo sistema de datos erróneos. También se deberán realizar pruebas 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. Al 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 procedimientos de autorización de datos.

Un aspecto muy importante es el tratamiento de los datos de entrada

erróneos, para los que deben cuidarse con atención los procedimientos de
reintroducció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.
1.6.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. Para esto nos apoyaremos en
herramientas como COBIT, así como ISACA que son un conjunto de buenas
prácticas que nos servirán para realizar la auditoría de la base de datos.

1. Procedimientos de preparación de datos.

2. Procedimientos de autorización de documentos fuente.
3. Recogida de datos de documentos fuente.
4. Manejo de errores de documentos fuente.
5. Retención de documentos fuente.
6. Procedimientos de autorización de datos.
7. Verificación de exactitud, compleción y autorización.
8. Manejo de errores de entrada de datos.
9. Integridad del procedimiento de datos.
10. Edición y validación del procesamiento de datos.
11. Manejo de errores de procesamiento de datos.
12. Retención y manejo de salidas.
13. Distribución de salidas.
14. Reconciliación y balanceo de salidas.
15. Manejo de errores y revisión de salidas.
16. Medidas de seguridad para informes de salidas.
17. Protección de información sensible.
18. Protección de información sensible dispuesta.
19. Gestión de almacenamiento.
20. Periodos de retención y términos de almacenamiento.
21. Sistema de gestión de la biblioteca de medios.
22. Responsabilidades de gestión de la biblioteca de medios.
23. Copias de respaldo y recuperación.
24. Trabajos de copias de respaldo.
25. Almacenamiento de respaldo.

Figura 2. Clasificación de los objetivos de control para la gestión de datos, ISACA (1996)

Sería conveniente también que el auditor pudiera llevar a cabo una auditoría
sobre el rendimiento del sistema de base de datos, comprobando si se lleva
a cabo un proceso de ajuste (tuning) 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
ciertos parámetros del SO e incluso la forma en que acceden las
transacciones a la base de datos.
 Verificar que existen procedimientos de exploración aprobados y
contenidos/mantenimiento de los sistemas sólo se realizan mediante
autorizaciones adecuadas.
  Es muy recomendable realizar pruebas de rendimiento, y comprobar
que el administrador de la BD ha respondido adecuadamente a los
posibles mensajes de degradación que haya presentado el sistema.
 Procedimientos de preparación.
 Integridad del procedimiento de datos.
 Manejo de errores de salida.
 Distribución de salidas.
 Procedimientos utilizados para la protección de la información
sensible.

1.6.5. Revisión post-implantación

La revisión o auditoría post implantación es el seguimiento del sistema ERP

(Enterprise Resource Planning) como una oportunidad para evaluar la
situación, objetivos, problemas y oportunidades. Los resultados de este
proceso pueden ser detallados en un plan de mejora continua de la empresa.
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 o 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 lo previsto.

CAPÍTULO 3: INFORME DE AUDITORÍA DE BASE DE DATOS

2.1. Introducción
2.2. Alcance
2.3. Justificación
2.4. Objetivos
2.5. Metodología utilizada
2.6. Estudio previo y plan de trabajo
2.7. Concepción de la base de datos y selección de equipo
2.8. Diseño y carga
2.9. Explotación y mantenimiento
2.10. Revisión post-implantación
2.11. Auditoría de SQL Server
2.12. Hallazgos Potenciales (Resultados)
2.13. Conclusiones
2.14. Recomendaciones

BIBLIOGRAFIA

ANEXOS
(contrato)