Noviembre 2011

Mg. Sc. Miguel Cotaña Mier

AUDITORIA DE BASE DE DATOS

UNIVERSIDAD MAYOR DE SAN ANDRES

FACULTAD DE CIENCIAS ECONOMICAS Y FINANCIERAS

CARRERA DE AUDITORIA

AUDITORIA DE SISTEMAS INFORMATICOS

La gran difusión de los SGBD, junto con la

consagración de los datos como de 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 ASI se aplica de 2 formas distintas: se

auditan las principales áreas del departamento de

informática y por otro se auditan las aplicaciones.

1. INTRODUCCION

Los Sistemas de Gestión de Bases de Datos proveen

mecanismos que garantizan la seguridad,

consistencia y reglas de integridad. Es de gran

importancia par el auditor de sistemas, conocerlos y

apoyarse en ellos para verificar el ambiente de

control establecido en la instalación.

Todo sistema va ingresando datos a su computadora

o servidor, en sus correspondientes bases de

datos. Suele suceder que dicha información va

engrosándose con el tiempo y otras veces son el

resultado de la convergencia de distintos sistemas,

versiones, o inclusive debido a "cargas iniciales por

compras de carteras" o, "transformaciones" de

formas de acceso a los archivos (claves).

Esto genera que cuando queremos utilizar estos

datos, no necesariamente están completos o son

correctos (por ejemplo: clientes de los cuales no

tengo su número de documento, clientes con el

mismo número de documento, domicilios

incompletos o erróneos, teléfonos erróneos,

descripciones mal armadas de sus materias primas

o productos, proveedores sin números que son

requeridos impositivamente o con situaciones

fiscales equivocadas).

Esta problemática se acrecienta aún más en los

casos de entidades financieras:

"Las entidades bancarias deben mantener una

base con "clave de cliente único" de manera

que permita establecer correctamente la

totalidad de las operaciones pasivas y activas

de cada cliente".

Todo esto genera a la organización, debilidades y

costos innecesarios. Por ejemplo: cuando tiene que

implementar estrategias de márketing como ser envío

de piezas postales que simplemente no puede hacer por

no tener domicilios confiables en su base de datos; o

bien cuando decide realizar campañas de venta

telefónica y se encuentra que este medio tan efectivo y

rápido no puede ser correctamente utilizado (está

iniciando llamados y está contactando a gente que en

realidad Ud. no está interesado en contactar).

Los ASI, deben diagnosticar cuán "saludable" se

encuentra la BD y entregarle un plan de acción

concreto para aproximarla lo más posible a la

veracidad que Ud. necesita para utilizarla en el

negocio.

En el caso en que los datos "convivan" en varios

lugares de la empresa, (cada sector o sistema

trabaja con su base propia), se debe ayudar a evitar

estas duplicaciones innecesarias y costosas,

unificando lo que por coherencia e integridad

debería ser único.

Los ASI, deben diagnosticar cuán "saludable" se

encuentra la BD y entregarle un plan de acción

concreto para aproximarla lo más posible a la

veracidad que Ud. necesita para utilizarla en el

negocio.

En el caso en que los datos "convivan" en varios

lugares de la empresa, (cada sector o sistema

trabaja con su base propia), se debe ayudar a evitar

estas duplicaciones innecesarias y costosas,

unificando lo que por coherencia e integridad

debería ser único.

Los tópicos que se incluyen tienen que ver

con la exactitud, consistencia y confiabilidad

de la información y con la privacidad y

confidencialidad de los datos. Las Bases de

Datos tienen dentro de sus características

elementos que pueden ser utilizados para

garantizar la calidad de la información

almacenada y procesada:

SEGURIDAD EN B.D.

Claves primarias;

Dominios de los atributos;

Reglas de integridad;

Vistas;

Perfiles de usuario y acceso a la BD;

Auditoria;

Criptografía;

Disparadores o triggers.

Investigar actividades dudosas sobre la BD

Recopilar información acerca de actividades

específicas de la BD

Recopilar estadísticas sobre qué tablas se están

actualizando, cuantas E/S lógicas se realizan y

cuántos usuarios se conectan de forma

simultánea en las horas de máxima actividad

La auditoría se puede realizar por sesión ó por

acceso

OBJETIVOS DE LA AUDITORIA

Se debe definir lo que se desea auditar:

Usuarios, sentencias u objetos

Ejecuciones de sentencias correctas,

ejecuciones de sentencias incorrectas ó ambas

Se debe gestionar los registros de la auditoría:

Controlar el aumento de los registros de la

auditoría

Protejer los registros de auditoría de un acceso

no autorizado

GESTION DE LA AUDITORIA

Obtener el inventario de recursos (Hw, Sw, orgware

y liveware) y la información relevante para apoyar

el examen que el equipo de ASI realizara. El

resultado de esta recopilación se organiza en un

archivo de papeles de trabajo denominado archivo

permanentemente o expediente continuo de

Auditoría.

“Conocimiento del negocio y del Sistema”

Información sobre la empresa y su objeto social,

sobre sus políticas y normas. Además toda la

información referente al Sistema de Bases de Datos.

METODOLOGIA: Investigación Preliminar

Información que se debe solicitar y analizar:

1. Políticas y normas del negocio en relación con

las actividades apoyadas con el SGBD

2. Información de objetos de la BD (tablas, vistas,

procedimientos almacenados, triggers, etc.).

3. Diagrama de sistema y de redes del servidor de

bases de datos, servidores de replicación y

servidores de aplicaciones. Todas las conexiones

clientes a la base de datos incluyendo interfaces de

red, direcciones IP, conexiones LAN y WAN.

4. Listado de usuarios de la BD con sus roles y

privilegios.

5. Documentación de las aplicaciones sobre la BD

6. Cuadros organizacionales y descripción de

funciones y procedimientos del personal que

soporta las bases de datos

7. Políticas de administración y procedimientos

sobre la BD incluyendo procedimientos de

seguridad, programas de backup y procedimientos

de recover o restauración.

8. Documentación de pruebas de recovery o

restauraciones.

9. Documentación de espacio en disco, tablas de

espacio y monitoreo.

10. Archivos de arranque de bases de datos.

11. Script de utilidades.

12. Archivos de configuración

13. Listados a través de SO de los directorios de la

BD mostrando propietarios y permisos hasta el

nivel de archivos.

14. Listados a través de SO de los directorios de

programas de aplicación que accedan las BD,

mostrando propietarios y permisos hasta el nivel de

archivos.

15. Listado de archivos de usuarios y grupos de

usuarios.

16. Listado de información de archivos de logs.

17. Listado de los servicios habilitados

(exposiciones a Internet).

“Importancia del SGBD en la empresa”

“Alcance de auditoría”

1. Objetos de la base de datos y reportes.

Permiso en SGBD

Permisos SO

Informacion fuera de tablas. Importac

Export

Privacidad y Confidencialidad.

Informes a quien no son DBA

Acceso a los datos fuera de DBMS

Politicas de seguridad.

METODOLOGIA: Definir grupos de riesgo

2. Programas de aplicación y utilitarios.

Acceso lógico

Permiso en SGBD

Datos en Programas

Modificaciones a Aplicaciones

Estándares de Desarrollo

Documentación Cambios

Autorización a cambios, pruebas y puesta en

marcha.

Acceso a fuentes.

Copias de los nuevos programas.

Adicionar rutinas de auditoria

3. Auditoría y Seguimiento

Logs.

Riesgos: logs muy grandes.

Desconocimiento de la informacion

contenida

4. Planes de Respaldo y Contingencia.

5. Metadatos.

6. Seguridad en la Red.

7. Acceso a traves de Internet.

8. Seguridad Instalaciones y acceso físico.

9. Diseño de la Base de Datos.

Llaves Primarias logicas

Integridad Referencial o mecanismos

Normalizacion

Triggers mal diseñados.

10. Eficiencia y economía de recursos.

11. Almacenamiento.

Cambios no afectan a programas

Agrupación:

a. Inseguridad en instalaciones y acceso físico.

Objetivos:

i. Evaluar la seguridad de las instalaciones

contra diferentes riesgos.

ii. Evaluar la existencia de planes de acción ante

siniestros que involucren las instalaciones.

iii. Evaluar las medidas existentes para el control

de acceso físico a las instalaciones.

b. Riesgos relacionados con el acceso lógico y la

privacidad a las bases de datos.

c. Causados por la relación Sistema Operativo - DBMS.

d. Riesgos asociados a las aplicaciones y utilitarios.

e. Problemas relacionados con el Diseño de la BD

Objetivos:

i. Investigar sobre la metodología de diseño

usada.

ii. Evaluar la integridad y consistencia de los

datos.

iii. Evaluar si el Sistema respeta y apoya las

reglas del negocio.

f. Asuntos concernientes al Diccionario de datos y

documentación

g. Problemas con el Respaldo y planes de contingencia

h. Riesgos por personal y organización.

Objetivos:

i. Evaluar las funciones del DBA

ii. Evaluar si el sistema respeta la segregación

de funciones

iii. Evaluar las condiciones del personal

involucrado con el Sistema de Bases de

Datos.

i. Auditabilidad.

Objetivos:

i. Existencia de logs donde se registre las

actividades relacionadas con la BD

ii. Evaluar el grado de uso de la información

registrada en los logs si existen.

Los pasos anteriores son base para determinar la

naturaleza y extensión de las pruebas de auditoría

que deban efectuarse.

Las pruebas de auditoría, como se sabe, son de dos

tipos: De cumplimiento y sustantivas. Buscan

obtener evidencia que los controles establecidos

existen en realidad y se utilizan y ejecutan

correctamente.

Al conjunto de pruebas resultante se denomina

Programa de auditoría.

DISEÑO DE PRUEBAS DE AUDITORIA

El modo en que se verificó cada respuesta de los

cuestionarios, debe ser incluida en los checklist.

Es un trabajo de escritorio donde se especifica la

instalación a evaluar, el número de la prueba, el

objetivo de la misma, las técnicas a emplear, el tipo

de prueba (de cumplimiento o sustantiva), los

recursos necesarios para aplicarla, en cuanto a

información, software, hardware y personal. Se

describe, además el procedimiento a emplear.

Su propósito es obtener evidencia sobre los

controles establecidos, su utilización, y el

entendimiento y ejecución de los mismos por parte

de las personas. Para cada prueba ejecutada deben

adjuntarse los soportes correspondientes.

Análisis de efectos de debilidades

Diseño de controles

EJECUCION DE PRUEBAS

Análisis de Riesgos

Propósito. Aprovechar el conocimiento de la

relación SO, aplicación, sgdb para realizar una

auditoria basada en riesgos.

1. Control del ambiente de login en SO:

a. Asegúrese que el usuario esta adecuadamente restringido por el

programa de aplicación o por la seguridad de un menú de opciones.

b. Asegúrese que el usuario no puede escaparse del nivel del

programa de aplicación y obtener acceso al SO a la base de datos.

c. Asegúrese que el acceso al SGBD (roles, privilegios) esta limitado

a los objetos de programas de aplicación y el acceso a los objetos del

sistema esta restringido desde el identificador de la aplicación de BD

PROCEDIMIENTOS DE AUDITORIA

2. Asegúrese que cada usuario se autentica con la

base de datos.

a. Asegúrese que cada usuario esta propiamente

restringido por el programa o por el menú de

seguridad dentro de la aplicación.

b. Asegúrese que cada usuario esta restringido

desde la administración de bases de datos y las

herramientas de desarrollo, igualmente desde las

herramientas de consultas.

3. Si los usuarios se conectan a las bases de datos a

través de interfaces de administración o desarrollo

a.Asegúrese que cada perfil de usuario en las

tablas de usuarios es auditado.

b. Asegúrese que los roles y privilegios son

auditados usuario por usuario.

4. Realice una detallada revisión de los login,

procesos de autenticación, perfiles de usuario y

roles y privilegios.

5. Si un programa es una aplicación Web a través de

http o Programas CGI en el servidor:

a. Determine si el enrutador y/o firewall restringe

el acceso a la Base de Datos.

b. Determine que son adecuados los controles de

accesos al servidor web.

c. Que se realizan procesos de auditoria sobre los

usuarios del sistema operativo y de la base de

datos.

Objetivo. Determinar si el acceso a la base datos a

través del sistema operativo es seguro

1. Usuario de base de datos y sistema operativo.

a. verifique que todos los usuarios creados en

el sistema operativo representan un usuario

valido.

b. Asegúrese que las conexiones remotas están

controladas.

SEGURIDAD EN EL SO

2. Seguridad de los archivos de BD en el SO. a. Asegúrese que el propietario de todos los directorios

y archivos de BD es el usuario DBA

b. Asegúrese que el grupo propietario es DBA

c. Asegúrese de los permisos en los directorios

d. Para Unix que el parámetro umask este determinado

para que los archivos log no sean escribibles o leíbles

por todo el mundo.

e. En el caso de NT asegúrese que los permisos de

archivos sean restringidos para que no sean de libre

acceso para el grupo everyone.

3. Auditoria a la seguridad de la base de datos para

propietarios y grupos. a. Asegúrese que la cuenta del dba, realmente es usada

por el administrador de la base de datos.

b. En el caso unix, asegúrese que los miembros del

grupo dba son limitados a los usuarios de cuenta en la

base de datos.

c. Asegúrese que los permisos para los archivos de

administración de la BD están restringidos con acceso

solo a la cuenta del administrador del sistema.

Objetivo. Asegurarse que todos los procesos y

usuarios son autorizados y autenticados en la BD y

que los procesos de usuario son controlados.

1. Sobre las tablas de usuarios: a. Determine que todos los usuarios representan un usuario valido

y autenticado.

b. Prueba que el passwords por defecto en las cuentas de

administración del sistema han sido cambiadas.

c. Verifique que están definidos los procedimientos para cambios

de claves periódicamente y que los passwords son seguros.

d. Si la conexión a la base de datos se hace a través de programas

o utilidades, asegúrese que están protegidos por permisos de

archivos y directorios.

CONEXION Y AUTENTICACION

2. En una impresión de la bitácora de sesiones de

usuarios:

a. Asegúrese que todas los intentos de conexión

no exitosos son almacenados, revisados y se les

hecho seguimiento.

b. En sistemas pequeños considere la posibilidad

de auditar todas las conexiones, tanto exitosas

como no exitosas.

1. Obtenga listado de todos los archivos de

privilegios y roles de usuarios. a. asegúrese que los usuarios interactivos y en

ambientes de producción están restringidos solo al

privilegio de select. Además la información

confidencial debe ser restringida para los usuarios.

b. Identifique los procedimientos almacenados y

asegúrese que los privilegios para estos están

limitados a select y execute a los usuarios que así lo

requieran.

c. Asegúrese que el privilegio de with grant option esta

restringido solo al DBA.

CONTROL DE ACCESO A LA BD

2. Obtenga listado de los archivos de logs:

a. Asegúrese que los comandos críticos sobre los

objetos (create, alter, drop, etc) son registrados,

revisados y se les hace el seguimiento.

Propósito. Examinar la disponibilidad de la BD

para los usuarios y procesos y las apropiadas

medidas para limitar los efectos de las fallas en los

elementos del sistema.

1. Usando comandos similares a df: a. Identifique espacios de almacenamientos críticos.

b. Verifique que los archivos de logs y los archivos de control son

montados en diferentes discos y de estos se tienen copias

c. Asegúrese que cada disco usa un controlador independiente

para minimizar le efecto en una falla del controlador.

d. Asegúrese que los requerimientos de espacio de

almacenamiento, en el momento del diseño tuvieron en cuenta las

proyecciones a futuro.

DISPONIBILIDAD, RESPALDO

2. Obtenga un listado de los procedimientos de

backup de la BD, cronogramas de backup y

programas utilitarios de backup. a. Asegúrese que como mínimo un backup incremental se esta

realizando todas las noches

b. Asegúrese que los backup lógicos de la BD son programados

en la noche, cuando los usuarios están fuera y los procesos de

lotes han finalizado.

c. verifique que cuando se hacen backup lógicos la BD se

encuentra en modo restringido

d. Determine si se hace un backup lógico completo cada semana,

para asegurarse que la base de datos completa esta respaldada.

e. Asegúrese que un backup es realizado por lo menos cada mes.

3. Evaluar los medios de almacenamiento, los

procedimientos usados, la revisión de las copias, la

correcta etiquetada (interna y externa), la seguridad

del sitio de almacenamiento y la correcta rotación

de las copias.

4. Obtenga y revise la documentación de los

procesos de pruebas de recuperación.

Propósito. Determinar que las BD en red han sido

diseñadas para soportar los requerimientos de

disponibilidad y seguridad de las aplicaciones.

1. Partiendo de un diagrama de red donde se

especifique los servidores de bases de datos y sus

conexiones físicas y lógicas al resto de la red: a. Determine si los altos usos SQL entre componentes en la red

(Servidor y aplicaciones) están soportados por canales alta

velocidad y alto ancho de banda.

b. Usando comandos o aplicaciones tipo netstat (protocolo,

dirección remota y local y estado) revise el ruteo y

direccionamiento IP usado para los servidores de bases de datos.

BD EN RED