\AUDITORIA DE BASE DE DATOS INDICE 01. Introduccién 02. Metodologias para la auditoria de bases de datos. 03. Estudio previo y plan de trabajo. 04. Concepeién de la base de datos y seleccién del equipo. 05. Disefio y carga 06. Explotacién y mantenimiento. 07. Revisién post-implantacién. 01. INTRODUCCION én de los Sistemas de Gestidn de Bases de Datos (SGBD), junto con la consagracién de los datos como uno de los recursos fundamentales de las empresas, ha hecho que los temas relativos a su control intemo y auditoria cobren, cada dfa, mayor interés. Normalmente la auditoria informatica se aplica de dos formas distintas; por un lado se auditan las principales éreas del departamento de informatica: explotacién, direccién, metodologia de desarrollo, sistema operative, telecomunicaciones, bases de datos, etc; y, por otro, se auditan las aplicaciones desarrolladas internamente, (subcontratadas © adquiridas) que funcionan en la empresa. La importancia de la auditoria del entorno de bases de datos radica en que es el punto de partida para poder realizar la auditoria de las aplicaciones que utilizan esta tecnologia. 02. METODOLOGIAS PARA LA AUDITORIA DE BASES DE DATOS. Aunque existen distintas metodologfas que se aplican en auditorfa informatica (pricticamente cada firma de auditores y cada empresa desarrolla la suya propia), se pueden agrupar en dos clases: ‘Metodologia tradicional.- En este tipo de metodologia el auditor revisa el entorno con Ja ayuda de una lista de control (checklist), que consta de una serie de cuestiones a verificar. Por ejemplo: {Existe una metodologia de Disefio de Base de Datos? S N NA (Ses 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 auditoria de productos de bases de datos, especificdndose en Ia lista de control todos los aspectos a tener en cuenta, Metodologia de evaluacién de riesgos: Este tipo de metodologia, 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 seguin 2 autores: @ Incremento de la “dependencia” del servicio informatio debido a la concentracién de datos © Mayores posibilidades de acceso en Ia figura del administrador 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 0 programas que en los sistemas tradicionales © Ruptura de enlaces o cadenas por fallos del software 0 de los programas de aplicacién © Mayor impacto de accesos no autorizados al diccionario de la base de datos que aun 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.) Como en Ia auditorfa de desarrollo, se puede seguir la misma metodologfa, donde se establecen primeramente: Objetivo de control (ejemplo: El SGBD deberd preservar la confidencialidad de la base de datos) ‘Técnicas de control. Una vez establecidos los objetivos de control, se especi san las técnicas especificas correspondientes a dichos objetivos (ejemplo: Se deberdn establecer los tipos de usuarios, perfiles y privilegios necesarios para controlar el acceso a las bases de datos). Un objetivo de control puede evar asociadas varias téenicas que permiten cubrirlo en su totalidad. Estas téenicas pueden ser preventivas, detectivas (como monitorizar la BD) 0 correctivas (por ejemplo, una copia de respaldo o backup). Pruebas de cumplimiento. En caso de que los controles existan, se disefian unas pruebas (denominada pruebas de cumplimiento) que permiten verificar la consistencia de los mismos. Por ejemplo: Listar los privilegios y perfiles existentes en el SGBD. Si estas pruebas detectan inconsistencias en los controles, 0 bien, si los controles no existen, se pasa a disefiar 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 comparindola 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 conclusiones que serin comentadas y discutidas con los responsables directos de las dreas afectadas con el fin de corroborar los resultados. Por tiltimo, el auditor deberé emitir una serie de comentarios donde se describa la situacién, el riesgo existente y la deficiencia a solucionar, yen su caso, sugeriré la posible solucién, Esta sera la técnica a utilizar para auditor el entorno general de un sistema de bases de datos, tanto en su desarrollo como durante la explotacién. PRINCIPALES OBJETIVOS DE CONTROL EN EL CICLO DE VIDA DE UNA BASE DE DATOS Revisién post- implantacié Estudio previo y . Concepeién dela BD y seleccién Explotacié 4 ny mantenimi, | Diseito y ent carga 03. 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 acompaiiados de un anilisis de costo-beneficio para cada una de las opciones. Se debe considerar entre estas alternativas la posibilidad de no Ievar a cabo el proyecto (no siempre esté justificada la implantacién de un sistema de base de datos) asf como la disyuntiva entre desarrollar y comprar (en la practica, a veces encontramos con que se ha desarrollado una aplicacién que ya existfa en mercados, cuya compra hubiese supuesto un riesgo menor, asegurdndonos incluso una mayor cantidad a un precio inferior). Lamentablemente, en bastantes empresas este estudio de viabilidad no se Heva a cabo con el rigor necesario, con lo que a medida que se van desarrollando, los sistemas demuestran ser poco rentables. EI auditor debe comprobar también que la alta direcci6n revisa los informes de los estudios de viabilidad y que es la que decide seguir adelante 0 no con el proyecto. Esto s fundamental porque los téenicos 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 implantaci6n de sistema 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 gestidn de proyectos que tengan aprobados la organizacién. Otro aspecto importante en esta fase es la aprobacién de la estructura orgénica del proyecto en particular, sino también de la unidad que tendra la responsabilidad de la gestidn y control de la base de datos; recordemos que, para que un entorno de base de datos funcione debidamente, esta unidad es imprescindible.Tareas del administrador de datos Realizar el diseiio conceptual y ligico de la base de datos Apoyar al personal de sistemas durante el desarrollo de aplicaciones Formar al personal Establecer estindares de disefio de b.d. desarrollo y contenido del diccionario de datos Desarrollar politicas de gestidn de datos Desarrollar planes estratégicos y tcticos para la manipulacidn de los datos Desarrollar los requisitos de los elementos del diccionario de datos Desarrollar normas para la denominacién Controlar la integridad y seguridad de los datos Planificar la evolucién de la bd de la empresa Identificar oportunidades de comparticién de datos ‘Trabajar con los auditores en la auditoria de la base de d. Proporcionar controles de seguridad Realizar el diseito fisico de la bd Asesorar en la adquisicién de hw y sw Soportar el SGBD Resolver problemas del SGBD y del software asociado Monitorizar el rendimiento del SGBD Ayudar en el desarrollo de planes que aseguren la capacidad hw. Asegurar la integridad de los datos, comprobando que se implantan los controles adecuados ‘Asegurar la seguridad y confidencialidad Proporcionar facilidades de prueba Integrar paquetes, procedimientos, utilidades, etc. De soporte para al SGND Desarrollar estindares, procedimientos y documentarlos 2000000000000000 o000 2000 A la hora de detallar las responsabilidades de estas funciones hay que tener en cuenta uno de los principios fundamentales del control interno: Ia separacién de funciones. Se recomienda una separaciGn de funciones entre: © El personal de desarrollo de sistemas y el de explotacién © Explotacién y control de datos © Administracién de base de datos y desarrollo Deberfa existir también una separaci6n de funciones entre el administrador de seguridad y el administrador de la base de datos. Esto no quiere decir que estas tareas tengan forzosamente que desempefiarlas personas distintas (lo que no serfa viable en muchas y pequefias y medianas empresas) pero sf que es un aspecto importante de control a considerar, por lo que en caso de que no pueda lograrse la separacién de funciones, debersin establecerse controles compensatorios o alternatives: como, por ejemplo, una mayor atencién de la direccién y la comprobacién por parte de algiin usuario del contenido y de las salidas mas importantes producidas a partir de la BD.La situacion que el auditor encuentra normalmente en las empresas es que al no existir una descripcidn detallada de los puestos de trabajo (que incluyan responsabilidades, conocimientos, etc.), la separacién de funciones es muy dificil de verificar. 04, CONCEPCION DE LA BASE DE DATOS Y SELECCION DEL EQUIPO. En esta fase se empieza a disefiar la base de datos. La metodologia de disefio deberia también emplearse para especificar los documentos fuentes, los mecanismos de control, las caracteristicas de seguridad y las pistas de auditoria a incluir en el sistema, estos tiltimos aspectos generalmente se descuidan, lo que produce mayores costos y problemas cuando se quieren incorporar una vez concluida la implementaci6n de la base de datos y la programacién de las aplicaciones. El auditor debe por tanto, en primer lugar, analizar la metodologfa de disefio con el fin de determinar si es 0 no aceptable, y luego comprobar su correcta utilizacién, Como minimo, una metodologia de disefio de BD deberia contemplar dos fases de disefio: légico y fisico, aunque la mayoria de las empleadas en la actualizad contempla 3 fases: ademiés de las dos anteriores, una fase previa de disefio conceptual que seria abordada en este momento del ciclo de vida de la base de datos. Un punto importante a considerar, 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éigico de tecnologfas de la informacién © Datos y diccionario de datos corporativo 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, deberd realizarse utilizando procedimiento riguroso; en el que se considere por un lado, las necesidades de Ia empresa (debidamente ponderadas) y, por otto, las prestaciones que ofrecen los distintos SGBD candidatos (puntuados de manera oportuna). 05, DISENO Y CARGA En esta fase se levarén a cabo los disefios I6gico y fisico de la base de datos, por lo que el auditor tendré que examinar si estos disefios se han realizado correctamente: determinando si la definicién de datos contemplan ademés de su estructura, las sociaciones y las restricciones oportunas, asf 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, indices) 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, Ja alta direcci6n, aprueben el diseiio de los datos, al igual que el de tas aplicaciones. Una vez disefiada una BD se procederd a su carga, ya sea migrando datos de un soporte magnético o introduciéndolos manualmente.Las migraciones o conversions de sistemas, con el paso de un sistema de ficheros a uno de base de datos, 0 de un tipo de SGBD (de jerarquico a racional), entrafian un riesgo muy importante, por lo que deberdn estar claramente planificadas para evitar pérdida de informacién y la transmisi6n al nuevo sistema de datos erréneos. También se deberan realizar pruebas en paralelo, verificando que la decisién real de dar por terminada la prueba en paralelo, se atenia a los criterios establecidos por la direccién y que se haya aplicado un control estricto de Ta correceién de ertores 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. A este respecto, cabe destacar que Jas 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 diseiio de los documentos fuentes minimicen los errores y las omisiones, asf como el establecimiento de procedimientos de autorizacién de datos. Un aspecto muy importante es el tratamiento de 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. 06. EXPLOTACION Y MANTENIMIENTO. Una vez realizadas las pruebas de aceptacién, con la participaci6n 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 s6lo se modifica mediante la autorizacién adecuada. Serfa conveniente también que el auditor pudiera evar a cabo una auditorfa sobre el rendimiento del Sistema de BD, comprobando si se leva a cabo un proceso de ajuste y optimizacién adecuados que no s6lo consiste en el rediseiio fisico o I6gico de la BD, sino que también abarca ciertos pardmetros del SO ¢ incluso Ia forma en que acceden las transacciones a la BD. Recordemos que la “funcién de administracién de Ta base de datos debe ser la responsable de monitorizar el rendimiento y la integridad de los sistemas de BD”. 07. REVISION POST-IMPLANTACION. Aunque en bastantes organizaciones no se lleva a cabo, por falta de tiempo y recursos, se deberfa establecer el desarrollo de un plan para efectuar una revisién pos implantacién de todo sistema nuevo 0 modificado con el fin de evaluat si © Se han conseguido los resultados esperados © Se satisfacen las necesidades de los usuarios © Los costos y beneficios coinciden con lo previsto