UNIVERSIDAD PERUANA

LOS ANDES

FACULTAD DE INGENIERIA
ESPECIALIDAD INGENIERIA DE SISTEMAS Y COMPUTO

TEMA:

AUDITORIA EN BASE DE DATOS

PROFESOR : Ing. Amelia Celinda Chumpen Elera

CURSO : Auditoria de Sistemas de Información

INTEGRANTES :
OJEDA BENITO, Jenny
QUINTANA SOLIS, Jonatan
ZELAYA GIRON, Alan
LORENZO CASTILLO, Misael

-2020-
 DEDICATORIA

Para todas aquellas

personas que nos apoyan y
nos brindan su amor
incondicional
 INDICE

Introducción

1. Definición
2. Metodología
.1. Metodología tradicional
.1. Metodología de la evaluación de riesgos
3. Objetivos y control del ciclo de vida de una base de datos
.1. Estudio previo y plan de trabajo
3.2. Concepción de la base de datos y selección de equipos
3.3. Diseño y carga
3.4. Explotación y mantenimiento
3.5. Revisión post implantación
4. Técnicas para el control
4.1. Matriz de control
4.2. Análisis de los caminos de acceso
5. Planificación de la auditoria en base de datos
6. Auditoría y control interno de la base de datos
7. Componentes de un SGBD
8. Importancia
9. Protocolos y sistemas de distribución
10. Pasos para elaborar un informe de auditoria
11. Aplicaciones
 NTRODUCCION

En este trabajo de investigación se plasman los puntos mas importantes de una

auditoria de BASE DE DATOS y cuan importante es este aspecto para la empresa.
Conoceremos el ciclo de vida de una base de datos y su implicancia por lo que
debe existir una excelente consistencia y robustez en la calidad y alcance de la
información, los pasos para elaborar el informe y finalmente ejemplo de aplicación
en ORACLE.
 AUDITORIA EN LA BASE DE DATOS

1. DEFINICIÓN

DEFINICION DE AUDITORIA DE SISTEMAS

Según muñoz (2002) «Es la revisión técnica, especializada y exhaustiva que se

realiza a los sistemas computacionales, software e información utilizados en
una empresa, sean individuales, compartidos y/ó de redes.»

DEFINICION DE 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:

 Quién accede a los datos.

 Cuando se accedió a los datos.
 Desde qué tipo de dispositivo/aplicación.
 Desde que ubicación en la Red.
 Cuál fue la sentencia SQL ejecutada.
 Cuál fue el efecto del acceso a la base de datos.

QUE AUDITAN
AUDITORIA DE SISTEMAS

APLICACIÓN: analiza todos los procedimientos y métodos de la empresa

con la intención de mejorar su eficiencia.

QUE AUDITA: líneas y redes de las instalaciones informáticas

PARA QUE SE AUDITA: examinar y analizar de los procedimientos

administrativos y de los sistemas de control interno de la entidad auditada
 AUDITORIA DE LA BASE DE DATOS

FIGURA 1 Auditoria de base de datos

OBJETIVOS

Disponer de mecanismos que permitan tener trazas de auditoría completas y

automáticas relacionadas con el acceso a las bases de datos incluyendo la
capacidad de generar alertas con el objetivo de:
– Mitigar los riesgos asociados con el manejo inadecuado de los datos.
– Apoyar el cumplimiento regulatorio.
– Satisfacer los requerimientos de los auditores.
– Evitar acciones criminales.
– Disponer de mecanismos que permitan tener trazas de auditoría
completas y automáticas relacionadas con el acceso a las bases de
datos incluyendo la capacidad de generar alertas con el objetivo de:
 Monitorear y registrar el uso de los datos por los usuarios
Autorizados o no.
  Mantener trazas de uso y del acceso a bases de datos  Permitir
investigaciones
 Generar alertas en tiempo real
– Evitar multas por incumplimiento.

2. METODOLOGÍA

Metodología para la Auditoría de Base 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. Estas metodologías se pueden agrupar en dos clases.

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 cuestiones a
verificar. Por ejemplo:
S__ N__ NA__

¿Existe una metodología de diseño de BD?

El auditor deberá, registrar el resultado de su investigación: S, sí la
respuesta es afirmativa, N, en caso contrario, o NA (No aplicable).
 FIGURA 2 Tabla de preguntas
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.

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. Considerando estos riesgos, se podría definir por ejemplo el
siguiente:

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

2.2.2. 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, detectivas o correctivas.
En caso de que los controles existan, se diseñan las pruebas de
cumplimiento que permiten verificar la consistencia de los
mismos.

2.2.3. 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 prueba
 llamadas pruebas sustantivas, que permiten dimensionar el
impacto de estas deficiencias.

2.2.4. 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 forme 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.
Ejemplos de control:
BASE DE DATOS

OBJETIVO DE EL SGBD deberá preservar la confidencial de la base de datos

CONTROL

TECNICAS DE se deberá establecer los tipos de usuarios, perfiles y privilegios

CONTROL necesarios para controlar el acceso a la base de datos
PRUEBAS DE Listar los privilegios y perfiles existentes en el SGBD
CUMPLIMIENTO

Comprobar si la información ha sido corrompida comparándola con

PRUEBAS
otra fuente, o revisando los documentos de entrada de datos y las
SUSTANTIVAS
tracciones que se han ejecutado

DEFINIR LA ARQUITECTURA DE INFORMACION

OBJETIVO DE La base de datos se deberá de definir el nivel interno de la arquitectura

CONTROL de información.
TECNICAS DE Se deberá modelar la estructura física de almacenamiento de la base
CONTROL de datos
PRUEBAS DE Listar las entidades que se emplea en el modelo físico de datos
CUMPLIMIENTO

PRUEBAS Comprobar si las entidades que se emplea en el modelo físico de

SUSTANTIVAS datos están bien definidas y mantienen su jerarquía

REQUISITOS DE SEGURIDAD PARA GESTION DE DATOS

OBJETIVO DE La base de datos se deberá de definir el nivel interno de la arquitectura

CONTROL de información.
TECNICAS DE Se deberá modelar la estructura física de almacenamiento de la base
CONTROL de datos
PRUEBAS DE Listar las entidades que se emplea en el modelo físico de datos
CUMPLIMIENTO
 PRUEBAS Comprobar si las entidades que se emplea en el modelo físico de
SUSTANTIVAS datos están bien definidas y mantienen su jerarquía

3. OBJETIVOS Y CONTROL DEL CICLO DE VIDA DE UNA BASE DE DATOS

FIGURA 3 flujo grama de ciclo de vida de la base de datos

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 coste-beneficio para cada
una de las opciones.

FASE 1: Estudio previo y plan de trabajo

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 menos,
asegurándonos incluso una mayor calidad a un precio inferior).
.
A la hora de detallar las responsabilidades de las 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.

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, la separación de
funciones es muy difícil de verificar.

FIGURA 4 flujo grama de estudio previo y plan de trabajo

Fase 1.1. Decisión Política fijación de objetivos y plazo:

• Llamado “Estudio de viabilidad”.
• Los directivos fijan objetivos claros y concretos, que serán la pauta de
todo el proceso de desarrollo.
 • Esta fase es corta, pero fundamental para la integración el nuevo
sistema de información en el organismo.
• La intervención de los técnicos es limitada, tienen que contar con el
apoyo de los directivos, sino aumentan las probabilidades de fracaso.

Fase 1.2. Evaluación previa de medios y costes .

• Una vez tomada la decisión

• Dar orden de magnitud al coste global del proyecto.
• Proporcionar a los responsables del organismo una cifra aproximada de
los gastos que representará la implantación del sistema,
mantenimiento, medios (personal)

Fase 1.3. Aprobación de una estructura orgánica

• Definir y documentar la organización de la unidad administrativa de la
BD por la dirección del organismo que tendrá:
• Responsabilidad de la gestión de la BD
• Responsabilidad del control de la BD
• Determinar la estructura y componentes del equipo de desarrollo.
• Determinar quien será el administrador de la BD, y sus funciones
serán: responsable del contenido de la BD, actualización,
estandarización de la información.

Fase 1.4. Plan de trabajo detallado

• Definir las fases del desarrollo del proyecto, concretando sus plazos y
medios requeridos.
• Da buenos resultados el desarrollo del sistema de forma gradual, se
consigue:
• Aprender de la experiencia no cometiendo los mismos errores
• Adaptación gradual de usuarios (informáticos como no informáticos)
• Resultados en menores plazos
• Contar con los usuarios para la planificación. El plan de trabajo debe
ser aprobado por los directivos
FASE 2: Concepción de la base de datos y selección del equipo

FIGURA 5 flujograma de la base de datos y selección de 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.

Fase 2.1. Concepción de la BD

• Análisis del sistema existente (si existe) informaciones
• Determinar necesidades de los usuarios que la organización necesita y
- Funciones a integrar en BD requisitos del
• Modificaciones en las aplicaciones existentes sistema

Así, se podrá concretar los datos de entrada, procedimientos y medios que se

precisan para obtener dichas informaciones.

• Describir actividades de la organización

• características del sistema y su arquitectura
• contenido de la BD
 • Construcción del esquema conceptual que contrastándolo con la
realidad se ira adaptando hasta conseguir la síntesis de los esquemas
externos.
• Esta fase es independiente de la máquina donde se va a implantar y el
SGBD que se utilizará en su puesta en marcha.

Fase 2.1. Especificación del equipo

• Evaluar las exigencias del equipo respecto al SGBD: memorias
principal y secundaria, capacidad de proceso, etc.
• El organismo deberá disponer de un equipo que será el que se utilice
para implementar el sistema.
• Respecto al SGBD: Obligado a uno por condicionantes externos Elegir
uno de los SGBD existentes en el mercado

Un importante aspecto a considerar, al que los COBIT dedican un apartado

específico, es la definición, de la arquitectura de la información, que contempla
cuatro objetivos de control relativos a:
• Modelo de arquitectura de información, y su actualización, que es
necesaria para mantener el modelo consistente con las necesidades
de los usuarios y con el plan estratégico de tecnologías de la
información.
• Datos y diccionario de datos corporativo.
• Esquema de clasificación de datos en cuanto a su seguridad.
• Niveles de seguridad para cada anterior clasificación de datos.

FASE 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 los datos contempla 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 participó en
su establecimiento.

FIGURA 5 flujograma de diseño y carga

Fase 3.1. Diseño Lógico Diseño físico

• Transformación del esquema conceptual a un esquema lógico de acuerdo a
las características del SGBD elegido. Definida la estructura lógica de la BD,
se pasa a obtener la estructura física (esquema de almacenamiento)

Fase 3.2. Carga y optimización

• Ya definida la BD, se pueden cargar los datos (aplicaciones automatizadas,
migración de SGBD, los nuevos introduciéndolos en la BD). Si los datos no
están en soporte de ordenador, se incrementaran los plazos y los costes.
• Paralelo a la fase de diseño, se debe desarrollar los programas necesarios
para implementar la gestión, para que cuando se carguen los datos, se
puedan ir probando los programas que manejan esos datos.
• Medir rendimientos para ajustar la estructura física o incluso lógica si es
necesario
FASE 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.

En los nuevos COBIT se dedican un apartado completo a detallar los objetivos

de control para la gestión de datos, clasificándolos en un conjunto.
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 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 BD.
• 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.

FASE 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 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 los previstos.

4. TECNICAS PARA EL CONTROL

Sirven para identificar los conjuntos de datos del SI junto con los controles de
seguridad o integridad implementados sobre los mismos (defectivos,
preventivos y correctivos).

4.1. MATRIZ DE CONTROL

El SGBD influyen en la seguridad e integridad de los datos, en los que cada

uno se apoya en la operación correcta y predecible de otros, el efecto es
debilitar la seguridad global del sistema, reduciendo la fiabilidad e
introduciendo un conjunto de controles descoordinados y difíciles de gestionar.
La dirección de la empresa tiene, por tanto la responsabilidad fundamental por
lo que se refiere a la coordinación de los distintos elementos y a la aplicación
consistente de los controles de seguridad. Para llevar a cabo esta labor se
deben fijar claramente las responsabilidades sobre los diferentes
componentes, utilizar informes de excepción efectivos que permitan
monitorizar los controles, establece procedimientos adecuados, implantar una
gestión rigurosa de la configuración del sistema. Por lo que es recomendable
realizar matrices de control; estas matrices sirven para identificar los conjuntos
de datos de SI junto con los controles de seguridad o integridad
implementados sobre los mismos.
 FIGURA 6 Control de seguridad
4.2. ANALISIS DE LOS CAMINOS DE ACCESO

Es una técnica que se utiliza para documentar el flujo, almacenamiento y

procesamiento de los datos que pasa en cada fase, considerando desde el
momento en que se introducen e identifican los componentes del sistema tanto
el hardware como el software y también los controles asociados

FIGURA 7 Análisis de los caminos de acceso

5. TECNICAS PARA EL MUESTREO DE DATOS

El empleo de procedimientos de muestreo eficaces mejorará el alcance, el

enfoque y la eficiencia de las auditorías y permite al auditor proporcionar
aseguramiento sobre los procesos de negocio que sean relevantes para que la
organización cumpla con sus metas y objetivos. Es importante que los
auditores internos comprenda los consejos y los estándares aceptados en
materia de muestreo, junto con los procesos del negocio y los datos con los
que esté trabajando, cuando proceda a elegir la técnica de muestreo más
apropiada para la auditoría
El muestreo en auditoría se emplea para obtener una evidencia real y una
base razonable para la formulación de conclusiones sobre una población de la
cual se extrae la muestra. El auditor interno deberá diseñar y seleccionar una
muestra, ejecutar los procedimientos de auditoría y evaluar los resultados de la
muestra para obtener una evidencia suficiente, fiable, relevante y útil para
cumplir con los objetivos de la auditoría.

Existen varias técnicas para el muestreo en auditoría. Ejemplos de estas

técnicas son;

 Muestreo aleatorio – la selección de los ítems de la muestra no

contempla condiciones predeterminadas y cada ítem de la población
tiene la misma probabilidad de ser seleccionado para la muestra.
 Muestreo por unidades monetarias – utilizado para identificar errores
monetarios en los “sumas y saldos” de una cuenta de balance.
 Muestreo estratificado – utilizado para separar la población entera en
subgrupos; habitualmente se selecciona para la revisión de una muestra
aleatoria de cada subgrupo.
 Muestreo por atributos – utilizado para determinar las características
de una población.
 Muestreo variable – utilizado para determinar el impacto económico de
algunas características de una población.
 Muestreo basado en juicio– basado en el juicio profesional del auditor
para centrarse y confirmar la existencia de una condición que se intuye
razonablemente.
 Muestreo por descubrimiento – utilizado cuando la evidencia de un
solo error o condición es motivo de mayor escrutinio o investigación.

Al diseñar el tamaño y la estructura de una muestra de auditoría, el auditor

deberá considerar los objetivos específicos de la auditoría, la naturaleza de
la población y las técnicas de muestreo y extracción. El auditor deberá
contemplar la posible participación de especialistas apropiados para el
diseño y el análisis de la metodología de muestreo.

Al emplear una muestra estadística, el auditor deberá considerar conceptos

como el riesgo del muestreo y el margen de error tolerable y esperado. El
riesgo del muestreo se define como el riesgo de que la conclusión a la que
llega el auditor interno, que se basa en una muestra determinada, pudiera
diferir de la conclusión que se hubiera obtenido aplicado la misma técnica
de auditoría al total de la población. Existen dos tipos de riesgo de la
muestra.

Aceptación incorrecta – el riesgo de que el atributo u objetivo evaluado se

clasifica como poco probable, cuando en la realidad es probable.

Rechazo incorrecto – el riesgo de que el atributo u objetivo evaluado se

clasifica como probable, cuando en realidad es poco probable.

Los errores tolerables representan el número máximo de errores que el

auditor está dispuesto a aceptar y aún así, llegar a la conclusión de que el
objetivo es correcto. En muchos casos, no siempre será un criterio del
auditor y el error tolerable puede determinarse en función de la naturaleza
del negocio, tras consulta con la Dirección o de acuerdo a las mejores
prácticas. En algunos casos, un error de un ítem no será tolerable.

Los errores esperados son errores que el auditor espera encontrar en una
población basada en los resultados de auditorías anteriores, en cambios en
los procesos o de acuerdo a evidencias o conclusiones de otras fuentes.

Para determinar el tamaño de la muestra, el auditor considerará el riesgo

del muestreo, el error tolerable y el error esperado. El riesgo de la muestra
deberá considerarse en conjunto con el riesgo de enfoque de auditoría y
sus componentes, incluyendo el riesgo inherente, el riesgo de control y el
riesgo de detección.

MUESTRA Y RIESGO EN AUDITORIA

6. PLANIFICACION DE LA AUDITORIA EN BASE DE DATOS:
a. Identificar todas las bases de datos de la organización.
b. Clasificar los niveles de riesgo de los datos en las bases de datos.
c. Analizar los permisos de accesos.
d. Analizar los controles existentes de acceso a las bases de datos.
e. Establecer los modelos de auditoria de bases de datos a utilizar.
f. Establecer las pruebas a realizar para cada base de datos, aplicación y/o
usuario.

7. AUDITORIA Y CONTROL INTERNO EN UN ENTORNO DE BASE DE

DATOS.

Sistema de gestión de base de datos (SGBD)

Existen diferentes componentes del SGBD como el catalogo( componente
fundamental que asegura la seguridad de la BD), las utilidades para el
administrador (se 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: copias de respaldo, archivos diarios,
etc. Entre otras.

Software de auditoría
Son paquetes que pueden emplearse para facilitar la labor del auditor, en
cuanto a la extracción de datos de la base, el seguimiento de las
transacciones, datos de prueba, etc. Hay también productos muy interesantes
que permiten cuadrar datos de diferentes entornos permitiendo realizar una
verdadera “auditoría de dato”.

Sistema de monitorización y ajuste (tunning)

Este tipo de sistemas complementan las facilidades ofrecidas por el propio
SGBD, ofreciendo mayor información para optimizar el sistema, llegando a ser
en determinadas ocasiones verdaderos sistemas expertos que proporcionan la
estructura óptima de la base de datos y de ciertos parámetros del SGBD y del
SO.
 Sistema Operativo
El SO es una pieza clave del entorno, puesto que el SGBD se apoyará, en
mayor o menor medida en los servicios que le ofrezca el SO en cuanto a
control de memoria, gestión de áreas de almacenamiento intermedio (buffers),
manejo de errores, control de confidencialidad, mecanismos de interbloqueo,
etc

Monitor de transacciones
Algunos autores lo incluyen dentro del SGBD, pero actualmente, puede
considerarse un elemento más del entorno con responsabilidades de
confidencialidad y rendimiento.

8. COMPONENTES

Un SGBD (sistema de gestión de base de datos) sistema gestor de base de

datos es un conjunto de programas que permiten el almacenamiento,
modificación y extracción de la información en una base de datos.

1. Procesador de consultas: Transforma las consultas en instrucciones

2. Gestor de base de datos: Acepta las consultas examina los esquemas
conceptual y externo para determinar que registros necesita llama el
gestor de archivo.
3. Gestor de archivos: Manipula los archivos almacenados gestiona
asignación de espacio de disco
4. Preprocesador DML: Convierte las instrucciones DML de un programa
de aplicación en llamadas de funciones en lenguaje host
5. Compilador DDL: Convierte las instrucciones DDL en una serie de
tablas que contiene metadatos y estas se almacenan
6. Gestor de catálogo: Gestiona y mantiene el catálogo del sistema.
 FIGURA 8 componentes de un SGBD

9. IMPORTANCIA
 Toda la información financiera de la organización reside en bases de datos
y deben existir controles relacionados con el acceso a las mismas.
 Se debe poder demostrar la integridad de la información almacenada en
las bases de datos.
 Las organizaciones deben mitigar los riesgos asociados a la pérdida 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 bases de datos y
procesos de negocios representan el negocio.
 Las organizaciones deben tomar medidas mucho más allá de asegurar sus
datos. Deben monitorearse perfectamente a fin de conocer quién o qué les
hizo exactamente qué, cuándo y cómo.
10. PROTOCOLOS Y SISTEMAS DE DISTRIBUCION
Moeller establece cinco objetivos de control a la hora de revisar la distribución
de datos:
 El sistema de proceso distribuido debe tener una función de administración
de datos centralizada que establezca estándares generales para la
distribución de datos a través de las aplicaciones.
 Deben establecerse unas funciones de administración de datos y de base
de datos fuertes, para que puedan controlar la distribución de los datos.
 Deben existir pistas de auditoría para todas las actividades realizadas por
las aplicaciones contra sus propias bases de datos y otras compartidas.
 Deben existir controles software para prevenir interferencias de
actualización sobre las bases de datos en sistemas distribuidos.
Deben realizarse las consideraciones adecuadas de costes y beneficios en el
diseño de entornos distribuidos

PAQUETES DE SEGURIDAD
Existen en el mercado varios productos que permiten la implantación efectiva
de una política de seguridad, puesto que centralizan el control de accesos, la
definición de privilegios, perfiles de usuarios.

DICCIONARIO DE DATOS
Este tipo de sistemas, que empezaron a implantarse en los años setenta,
también juegan un papel primordial en el entorno de los SGBD en cuanto a la
integración de componentes y al cumplimiento de la seguridad de los datos, es
un conjunto de definiciones que contiene las características lógicas y
puntuales de los datos que se van a utilizar en el sistema, puede introducir
errores de forma repetitiva a lo largo del tiempo.
 TABLA 1 Modelo De Diccionario De Datos

HERRAMIENTA DE MINERIA DE DATOS

En los últimos años ha explosionado el fenómeno de los almacenes de datos
datawarehouses y las herramientas para la explotación o “minería” de datos
(datamining). Estas herramientas ofrecen soporte a la toma de decisiones
sobre datos de calidad integrados en el almacén de datos
 FIGURA 9 Proceso de minería de datos
11. PASOS PARA ELABORAR UN INFORME DE AUDITORIA

 Se requieren varios pasos para realizar una auditoría. El auditor de

sistemas debe evaluar los riesgos globales y luego desarrollar un programa
de auditoria que consta de objetivos de control y procedimientos de
auditoria que deben satisfacer esos objetivos
 El proceso de auditoria exige que el auditor de sistemas reúna evidencia,
evalúe fortalezas y debilidades de los controles existentes basado en la
evidencia recopilada, y que prepare un informe de auditoria que presente
esos temas en forma objetiva a la gerencia. Asimismo, la gerencia de
auditoría debe garantizar una disponibilidad y asignación adecuada de
recursos para realizar el trabajo de auditoria además de las revisiones de
seguimiento sobre las acciones correctivas emprendidas por la gerencia.
 La importancia de la auditoría del entorno de bases de datos radica en que
es el punto de partida para poder realizar la auditoría de las aplicaciones
que utiliza esta tecnología.
PRUEBA PARA EVALUAR EL ENTORNO DE LA BASE DE DATOS
12. APLICACIONES

QUE ES ORACLE?

Oracle es básicamente una herramienta cliente/servidor para la gestión de

Bases de Datos. Es un producto vendido a nivel mundial, aunque la gran
potencia que tiene y su elevado precio hace que sólo se vea en empresas muy
grandes y multinacionales, por norma general.

 Intentos de inicio de sesión

 Accesos a Objetos
 Acciones de las bases de datos

Se pueden auditar tres tipos de acciones:

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

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

Auditar las acciones de manipulación de datos sobre objetos

Por ejemplo, para auditar los “insert” realizados sobre una tabla:
audit insert on <TABLA> by access;
Nota: al indicar “by access” hay que tener cuidado pues registrará un suceso
de auditoría por cada insert, esto puede afectar al rendimiento. De ser así
siempre será mejor optar por “by session” que sólo registrará un suceso de
auditoría por sesión, aunque es menos exaustivo.
 BIBLIOGRAFIA

1. Mosqueda Y, Ramírez E, Tapia J & Torres I. (2009) Titulo. Auditoria a la base de

datos SQL del sistema de seguridad de presas Conagua [Fecha de consulta 09
de enero 2021] Disponible en. https://docplayer.es/1918307-Auditoria-a-la-base-
de-datos-sql-del-sistema-de-seguridad-de-presas-conagua.html

2. Muro M, Navarrete E., Torres E., (2015) Auditoria de base de datos [fecha de
consulta 09 de enero del 2021] Disponible en
https://slideplayer.es/slide/13907163/

3. Piattini Mario ( ) Titulo. Enfoque practico de auditoria informática. [Fecha de

consulta 05 de enero del 2021] Disponible en :
http://cotana.informatica.edu.bo/downloads/ld-Auditoria-informatica-un-enfoque-
practico-Mario-Piattini-pdf.pdf

4. https://prezi.com/75cq2kapz-3m/auditoria-de-base-de-datos/

5. https://es2.slideshare.net/joinergac/ejemplo-de-una-auditoria