Auditoria y Control Interno en Un Entorno de Base de Datos
Auditoria y Control Interno en Un Entorno de Base de Datos
Auditoria y Control Interno en Un Entorno 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.
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.
Algunos autores lo incluyen dentro del propio SGBD, pero actualmente, puede considerarse
un elemento más del entorno con responsabilidades de confidencialidad y rendimiento.
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.
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.
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.
TRANSACCIONES Verificación
DE Informe de Reconciliación
ENTRADA
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.
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:
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.
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.
modificado_por – nombre o código de identificación del último usuario que modificó el 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.