Está en la página 1de 8

AUDITORIA DE BASE DE DATOS.

La auditoría de bases de datos consiste en un proceso de monitoreo continuo y riguroso de los controles que la
administración ha establecido dentro de los sistemas de bases de datos y todos sus componentes para obtener
una seguridad razonable de la utilización adecuada de los datos que son almacenados por los usuarios mediante
los sistemas de información.

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

Cuando el auditor, se encuentra en explotación de la información, deberá estudiar el SGBD y el entorno. El


desarrollo y mantenimiento de sistemas informativos entornos de BD, deberían considerarse el control, la
integridad y la seguridad de los datos compartidos por múltiples usuarios, por tal razón deben abarcase todos los
componentes de la BD, pero cabe resaltar que el entorno es cada vez más complejo y no puede limitarse al
propio de una SGBD.

SISTEMA DE GESTION DE BASE DE DATOS (SGBD)


En estos sistemas, los programas de aplicación no acceden a los datos o realizan directamente funciones de
gestión de los mismos; en lugar de ello, el SGBD actúa como una interfaz para todos los programas que
acceden los datos.
Entre sus componentes puede destacarse:
 El núcleo (Kernel)
 El catálogo, componente para asegurad la seguridad de la BD
 Las utilidades del administrador de la BD, entre las que se pueden crear usuarios, conceder privilegios y
resolver otros asuntos relativos a la confidencialidad.
 Las que se encargan de la recuperación de BD
 Rearranque, copias de respaldo, archives diarios
 Funciones de auditoria
 Lenguaje de cuarta generación (LG4) que incorpora el propio SGBD.
En cuanto a las funciones de auditoria que ofrece el propio sistema, prácticamente todos los
productos del mercado permiten registrar la mayoría de las operaciones.

SOFTWARE DE AUDITORIA:
Un software de auditoria es un tipo de programa informático que realiza una amplia gama de funciones
de gestión de auditoria. El objetivo principal de este tipo de software es resaltar las excepciones de los
datos e informar a los auditores de los errores probables. «El software de auditoría». Estos pueden
emplearse para facilitar la labor del auditor, en cuanto a la extracción de datos de la base, el
seguimiento de las transacciones.

SISTEMA DE MONITORIZACIÓN Y AJUSTE (TUNING):


Este tipo de sistema 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 (SO):
El SO es una pieza clave del entorno puesto que el SGBD se apoyará en mayor medida de los servicios que le
ofrezca el SO en cuanto control, memoria, gestión de almacenamiento, manejo de errores, control de
confidencialidad, mecanismos de interbloqueo, etc.
Desafortunadamente, el auditor informático tiene serias dificultades para controlar de manera rigurosa la
interfaz entre el SGBD y el S0, debido a que, en parte, constituye información reservada de los fabricantes de
los productos, además de requerir unos conocimientos excepcionales que entran en el campo de la técnica de
sistemas.
MONITOR DE TRANSACCIONES:

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

PROTOCOLOS Y SISTEMAS DISTRIBUIDOS:


La vulnerabilidad de las BD se acentúa por su accesibilidad a través de la red por lo que Moeller establece cinco
objetivos de control a la hora de revisar la distribución de datos:
1. 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.

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

3. Deben existir pistas de auditoría para todas las actividades realizadas por las aplicaciones contra sus
propias bases de datos y otras compartidas.

4. Deben existir controles software para prevenir interferencias de actualización sobre las bases de
datos en sistemas distribuidos.

5. Deben realizarse las consideraciones adecuadas de costes y beneficios en el diseño de entornos


distribuidos.

PAQUETE DE SEGURIDAD:
El paquete de seguridad garantiza la integridad y confiabilidad de los datos almacenados, garantizando que los
usuarios accedan y actualicen la información a la que tienen permiso en dependencia de los privilegios que
posea. (Oscar Lucero Moya, 2014).
Un grave inconveniente de este tipo de software es que a veces no se encuentra bien integrado con el
SGBD, pudiendo resultar poco útil su implantación si los usuarios pueden "saltarse" los controles a
través del propio SGDB.

DICCIONARIO DE DATOS:
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. Los diccionarios de datos se
pueden auditar de manera análoga a las bases de datos, ya que, después de todo, son bases de datos de
metadatos.

Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas y puntuales de los
datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y
organización. Identifica los procesos donde se emplean durante el análisis de flujo de datos y auxilia a los
analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea
durante el diseño.
HERRAMIENTAS CASE:
Son un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y
desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software. Constituyen una
herramienta clave para que el auditor pueda revisar el diseño de la base de datos, comprobar si se
ha empleado correctamente la metodología y asegurar un nivel mínimo de calidad.
LENGUAJES DE CUARTA DIMENSIÓN:
Los 4GL son entornos de desarrollo de aplicaciones constituidos por un conjunto de herramientas integradas. Se
centran principalmente en las fases de Construcción e Implantación del ciclo de vida del desarrollo de software.
De los objetivos de control para los L4G, destacan los siguientes:
El L4G debe ser capaz de operar en el entorno de proceso de datos con controles adecuados.
Las aplicaciones desarrolladas con L4G deben seguir los mismos procedimientos de automatización y petición
que los proyectos de desarrollo convencionales.
Las aplicaciones desarrolladas con L4G deben sacar ventajas de las características incluidas en el mismo.
Uno de los peligros más graves de los L4G es que no se aplican controles con el mismo rigor que a los
programas desarrollados con lenguajes de tercera generación. Otros problemas pueden ser la ineficacia
y elevado consumo de recursos

El Auditor deberá estudiar los controles disponibles en los L4G, en caso negativo, recomendar su
construcción con lenguajes de tercera generación.

FACILIDADES DE USUARIO DE BASES DE DATOS:


demuestran facilidades para dotar el usuario final de las más modernas y completas facilidades resultantes de la
utilización de base de datos y de los ambientes que ofrecen los lenguajes de cuarta generación.
El auditor deberá investigar las medidas de seguridad que ofrecen estas herramientas (Interfaz gráfica de
usuario) y bajo qué condiciones han sido instaladas; las herramientas de este tipo deberían proteger a los
usuarios de sus propios errores.
Objetivos de control:
La documentación de las aplicaciones desarrollada por usuarios finales debe ser suficiente para que tanto sus
usuarios principales como cualquier otro pueda operar y mantenerlas.
Los cambios de estas aplicaciones requieren la aprobación de la dirección y deben documentarse de forma
completa.
HERRAMIENTAS DE MINERIA DE DATOS:
La minería de datos o exploración de datos, es un campo referido al proceso que intenta descubrir patrones en
grandes volúmenes de conjuntos de datos.
Estas herramientas ofrecen soporte a la toma de decisiones sobre datos de calidad integrados en el almacén de
datos
Se deberá controlar la política de refresco y carga de los datos en el almacén a partir de las bases de datos
operacionales existentes, así como la existencia de mecanismos de retroalimentación que modifican las bases de
datos operacionales a partir de los datos del almacén.
APLICACIONES:
El auditor deberá controlar que las aplicaciones no atentan contra la integridad de los datos.
TENICAS PARA EL CONTROL DE BASES DE DATOS

Existen muchos elementos del entorno del SGDB que influyen en la seguridad e integridad de los datos, en los
que cada uno de apoya en la operación correcta y predecidle de otra. El efecto de esto es: “debilitar la seguridad
global del sistema, reduciendo la fiabilidad e introduciendo un conjunto de controles descoordinados y
solapados, difíciles de gestionar”.
Cuando el auditor se enfrenta a un entorno de este tipo, puede emplear, entre otras, dos técnicas de control.

Matrices de Control

Estas matrices sirven para identificar los conjuntos de datos del SI junto con los controles de
seguridad o integridad implementados sobre los mismos.

Esta matriz que por un lado lleva un elemento a controlar, y por otro, los tipos de controles de seguridad
(preventivos, detectivos, correctivos) que se han diseñado para ello. En su cruce llevará la enumeración de
dichos controles y la opinión del auditor sobre su funcionamiento.

DATOS CONTROLES DE SEGURIDAD

PREVENTIVOS DETECTIVOS CORRECTIVOS

TRANSACCIONES Verificación
DE Informe de Reconciliación
ENTRADA

REGISTRO DE BASE Cifrado


DE Informe de excepción Copia de seguridad
DATOS

Análisis de los Caminos de Acceso


Los caminos de acceso representan la secuencia y tipo de acceso a los datos persistentes
del sistema, que deben realizar los procesos primitivos a partir del modelo lógico de datos
normalizado, o los módulos/clases a partir del modelo físico de datos.
Los Análisis de los Caminos de Acceso:
 Documentan todas las fases (flujos) por las que pasa un dato desde su introducción por un ente (usuario /
máquina) hasta que se almacena en la Base de Datos, identificando los componentes por los que pasa y
los controles asociados (definidos por la entidad).
 Esto mismo se hace con los datos que se obtienen del proceso de otros (por qué componentes pasa –
programa, cadenas, almacenamientos transitorios – y a qué controles es sometido.
 Esta técnica permite detectar debilidades del sistema que pongan a los datos que pongan en riesgo a
nivel de: Integridad, confidencialidad y seguridad.
 Hay que poner especial cuidado en el análisis de los interfaces entre los componentes y los
almacenamientos transitorios (debilidades de seguridad).

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

Se pueden auditar tres tipos de acciones:

 Intentos de inicio de sesión


 Accesos a objetos
 Acciones de la base de datos.

Las Pistas de Auditoría o “Audit Trail” son un conjunto de transacciones que reflejan los cambios
hechos a una base de datos.
A partir del análisis de esta información se puede llegar a determinar la forma en la que los datos o
elementos obtuvieron su valor actual. Son un componente fundamental para la implementación del
“accountability” o rendición de cuentas.

En una base de datos de una aplicación estándar de una organización, se pueden generar pistas de
auditoría para:

 Conexiones a la base de datos.

 Modificaciones al modelo de datos.

 Modificaciones a los datos.

Los tipos de pistas de auditoría que encontramos en una base de datos son los siguientes:

 Registros de auditoría.
 Logs de base de datos.
 Pistas de auditoría basadas en aplicación.

REGISTROS DE AUDITORÍA

Requeridos únicamente cuando se modifican los datos en una tabla maestra o transaccional. A
diferencia de los logs de base de datos son registros de “historia” y no se utilizan para registrar las
conexiones a la base de datos o modificaciones al modelo de datos, sino que se enfocan en las
modificaciones a los datos originadas desde cualquier origen. Su implementación es a través de
“triggers”, típicamente antes o después de los eventos “insert”, “delete” o “update”. Se guarda la
imagen del registro antes y después del evento, existiendo la opción de registrar la imagen de la fila
entera, o registrar únicamente las columnas que han cambiado durante la operación.

Logs de base de datos:

Generalmente provistas con opciones que se configuran directamente en la base de datos (dependiendo del
motor) e incluyen acciones como auditoría de sentencias, auditoría de privilegios y auditoría de objetos de la
base de datos. La información generada se guarda en archivos propios de la base de datos. Es una opción costosa
en recursos de almacenamiento y para revisar la información generada usualmente se requieren recursos
adicionales tales como una herramienta para identificar y monitorear los eventos verdaderamente críticos.

Pistas de auditoría basadas en aplicación: 

se implementan a través de procedimientos almacenados invocados desde las aplicaciones o


directamente en el código de las aplicaciones. Consisten en agregar, y modificar cuando sea necesario,
los siguientes campos en cada una de las tablas (maestras o transaccionales) de una aplicación:

creado_por – nombre o código de identificación del usuario que creó el registro


fecha_creación – fecha y hora en la que el registro fue creado

modificado_por – nombre o código de identificación del último usuario que modificó el registro

fecha_modificación – fecha y hora de la última modificación del registro

origen – nombre de la función de la aplicación desde la que se realizó la última acción sobre el registro.

Para su funcionamiento se requiere que nunca se eliminen registros de la base de datos, sino que
únicamente se les cambie el estado, de tal forma que para el usuario final estos registros ya no existan,
pero físicamente seguirán en la base de datos.