6.2 AUDITORIA

 

Una auditoría, en el contexto de la economía y el mundo empresarial, es el proceso de evaluación minuciosa de una sociedad u organización con el ánimo de conocer sus características específicas, así como sus fortalezas y debilidades.

Por medio de trabajos de auditoría, es posible llevara cabo valoraciones de todo tipo atendiendo a criterios de análisis y medición exhaustivos.

Principalmente, una auditoría persigue localizar aspectos relacionados con la rentabilidad o la eficiencia en los diferentes departamentos o delegaciones corporativas que conforman una empresa. 

Del mismo modo ocurre con otros conglomerados como fundaciones, ONGs e incluso instituciones y administraciones públicas. 

Toda organización es susceptible de ser controlada y vigilada sea cual sea su misión o su naturaleza económica. El hecho de que exista una actividad auditora y de valoración ayuda a que todo tipo de sociedades no caigan en irregularidades fiscales, legales o de muchos otros tipos. 

A la vez, auditar periódicamente a estas supone un punto de mejora continua de los trabajos que realizan cotidianamente, localizando puntos débiles u otros aspectos organizacionales a mejorar. 

Características principales de una auditoría

Todo trabajo auditor, independientemente de su naturaleza u objetivos, debe estar reglado por una serie de aspectos esenciales:

v  El proceso de auditoría debe seguir unas pautas o criterios previamente establecidos.

v  La observación y medición de muy variados tipos de procesos organizacionales es el núcleo de esta labor.

v  Deben tenerse en cuenta todo tipo de recursos materiales e inmateriales que forman parte de la actividad económica, así como su aplicación productiva y su relevancia para la corporación.

v  Tras el análisis apropiado, deben emplearse los datos como base sólida. Esto, con la intención de emitir unas conclusiones por medio de un informe de auditoría.

v  Al tiempo, una auditoría debe servir como punto de inflexión. Esto supone la aportación de nuevas ideas y estrategias adaptadas a la naturaleza y recursos de la empresa analizada, de manera que esta pueda verse beneficiada con su aplicación,

Tipos de auditoría

Alternativamente, una auditoría puede ser ejercida por profesionales auditores pertenecientes a la propia organización o procedentes del exterior. De ese modo, y atendiendo a dicha distinción, es posible distinguir entre las modalidades de auditoría interna y externa. 

Siguiendo otros criterios, es posible encontrar otras prácticas en el ámbito de la auditoría. Existiendo ejemplos como la auditoría de cumplimiento, la auditoría de gestión o la auditoría contable entre otras muchas. 

Con el desarrollo del modelo de empresa y su adaptación al nuevo marco tecnológico y comunicacional, la faceta analítica de la auditoría debe evolucionar al tiempo adaptándose a las nuevas características existentes en los mercados actuales.

Auditoria de Bases 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:                       

v  Quién accede a los datos.

v  Cuándo se accedió a los datos.

v  Desde qué tipo de dispositivo/aplicación.

v  Desde que ubicación en la Red.

v  Cuál fue la sentencia SQL ejecutada.

v  Cuál fue el efecto del acceso a la base de datos.

Objetivos Generales de la Auditoría de BD

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:

v  Mitigar los riesgos asociados con el manejo inadecuado de los datos.

v  Apoyar el cumplimiento regulatorio.

v  Satisfacer los requerimientos de los auditores.

v  Evitar acciones criminales.

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.

La Auditoría de BD es importante porque:

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

v  Se debe poder demostrar la integridad de la información almacenada en las bases de datos.

v  Las organizaciones deben mitigar los riesgos asociados a la pérdida de datos y a la fuga de información.

v  La información confidencial de los clientes, son responsabilidad de las organizaciones.

v  Los datos convertidos en información a través de bases de datos y procesos de negocios representan el negocio.

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

Mediante la auditoría de bases de datos se evaluará:

v  Definición de estructuras físicas y lógicas de las bases de datos.

v  Control de carga y mantenimiento de las bases de datos.

v  Integridad de los datos y protección de accesos.

v  Estándares para análisis y programación en el uso de bases de datos.

v  Procedimientos de respaldo y de recuperación de datos.

6.1 MONITOREO

Es un término no incluido en el diccionario de la Real Academia Española (RAE). Su origen se encuentra en monitor, que es un aparato que toma imágenes de instalaciones filmadoras o sensores y que permite visualizar algo en una pantalla. El monitor, por lo tanto, ayuda a controlar o supervisar una situación.

Esto nos permite inferir que monitoreo es la acción y efecto de monitorear, el verbo que se utiliza para nombrar a la supervisión o el control a través de un monitor. Por extensión, el monitoreo es cualquier acción de este tipo, más allá de la utilización de un monitor.

MONITOREO GENERAL DE UN DBMS

DAP: un término que Gartner desarrolló para remplazar el anterior concepto de DAM se refiere a las suites de herramientas que se utilizan para apoyar la identificación y reportar comportamiento inapropiado, ilegal o de otra forma indeseable en las RDBMSs, con mínimo impacto en las operaciones y la productividad del usuario. Estas suites han evolucionado de herramientas DAM que ofrecían análisis de la actividad del usuario en las RDBMSs y alrededor de ellas para abarcar un conjunto más integral de capacidades, que incluyen:

v  Descubrimiento y clasificación.

v  Gestión de vulnerabilidades.

v  Análisis al nivel de aplicación.

v  Prevención de intrusión.

v  Soporte de seguridad de datos no estructurados.

v  Integración de gestión de identidad y acceso.

v  Soporte de gestión de riesgos.

 

MONITOREO DE ESPACIO EN DISCO

 

El abaratamiento de los discos ha reducido considerablemente la incidencia del espacio ocupado por los usuarios. No obstante, los discos requieren administración: hay que instalarlos, darles formato, montarlos en otras máquinas, respaldarlos, monitorearlos. Aunque el espacio en disco sea suficiente, es preciso insistir ante los usuarios para hacer un uso racional del recurso.

MONITOREO DE LOGS

Monitorear el log de transacciones es una de las actividades más importantes para los administradores de bases de datos, ya que en caso de que este llegara a llenarse, no podrían llevarse a cabo más transacciones sobre esta base de datos quedando fuera de servicio.

Monitoreando el log de transacciones (SQL SERVER)

Monitorear el log regularmente puede ayudarnos a resolver varios problemas dentro de nuestros sistemas, ya que este puede indicarnos si existen demasiadas transacciones realizadas por una sola aplicación, que podría resultar en un mal diseño o simplemente la necesidad de planear mejor los recursos de log en nuestro servidor de base de datos.

Applications Manager permite ver en detalle los indicadores clave de rendimiento de las bases de datos para asegurarse de que los administradores entiendan el estado del rendimiento de su base de datos en un momento dado, sintonicen sus bases de datos en función de la información suministrada y detecten cualquier anomalía de la base de datos antes de que los usuarios se vean afectados. Monitoree los atributos de la base de datos que son críticos para sus operaciones comerciales y visualícelos en un dashboard personalizado.

v  Utilización de la CPU

v  Utilización de la memoria

v  Estadísticas de conexión

v  Detalles de la memoria caché del búfer

v  Rendimiento de las consultas

v  Pool de recursos

v  Sesiones de usuario

v  Detalles del interbloqueo

v  Errores del sistema y del usuario

5.5 MIGRACIÓN DE LA BASE DE DATOS

 

La migración de bases de datos es el proceso mediante el que se migran datos de una o más bases de datos de origen a una o más bases de datos de destino mediante un servicio de migración de bases de datos. Cuando finaliza una migración, el conjunto de datos en las bases de datos de origen reside completo, aunque posiblemente reestructurado, en las bases de datos de destino. Los clientes que accedían a las bases de datos de origen se pasan a las bases de datos de destino, y las bases de datos de origen se desactivan.

En el siguiente diagrama, se ilustra este proceso de migración de las bases de datos.

En este documento, se describe la migración de bases de datos desde el punto de vista arquitectónico:

v  Los servicios y tecnologías involucrados en la migración de la base de datos

v  Las diferencias entre la migración de bases de datos homogéneas y heterogéneas

v  Las compensaciones y la selección de una tolerancia para el tiempo de inactividad de migración

v  Una arquitectura de configuración que admite un resguardo si se producen errores imprevistos durante una migración

En este documento, no se describe cómo configurar una tecnología de migración de base de datos en particular. En su lugar, presenta los principios, conceptos y fundamentos de la migración de bases de datos.

En el siguiente diagrama, se muestra una arquitectura de migración de base de datos genérica.

Un servicio de migración de bases de datos se ejecuta en Google Cloud y accede a las bases de datos de origen y de destino.

Se representan dos variantes: 

(a)  muestra la migración de una base de datos de origen desde un centro de datos local o una nube remota a una base de datos administrada como Cloud Spanner;

 (b) muestra una migración a una base de datos en Compute Engine.

Aunque las bases de datos de destino son de diferente tipo (administrado y no administrado) y configuración, la arquitectura y la configuración de migración de la base de datos es la misma para ambos casos.

Terminología

Los términos de migración de datos más importantes para estos documentos se definen de la siguiente manera:

Base de datos de origen: Es una base de datos que contiene datos para migrar a una o más bases de datos de destino.

Base de datos de destino: Es una base de datos que recibe datos migrados desde una o más bases de datos de origen.

Migración de bases de datos: Es una migración de datos desde bases de datos de origen hacia bases de datos de destino con el objetivo de desactivar los sistemas de bases de datos de origen una vez que se completa la migración. Se migra el conjunto de datos completo o un subconjunto.

Migración homogénea: Es una migración desde las bases de datos de origen hacia las bases de datos de destino en la que las bases de origen y de destino pertenecen al mismo sistema de administración de bases de datos, del mismo proveedor.

Migración heterogénea: Es una migración desde las bases de datos de origen hacia las bases de datos de destino en la que las bases de datos de origen y de destino pertenecen a diferentes sistemas de administración de bases de datos, de diferentes proveedores.

Sistema de migración de bases de datos: Es un sistema o servicio de software que se conecta a bases de datos de origen y de destino y realiza migraciones de datos desde bases de datos de origen hacia bases de datos de destino.

Proceso de migración de datos: Es un proceso configurado o implementado que ejecuta el sistema de migración de datos para transferir datos de bases de datos de origen a bases de destino, durante el cual es posible que los datos se transformen.

Replicación de base de datos: Es una transferencia continua de datos desde bases de datos de origen hacia bases de datos de destino sin la intención de desactivar las bases de datos de origen. La replicación de bases de datos (a veces llamada transmisión de bases de datos) es un proceso continuo.

Clasificación de las migraciones de bases de datos

Existen diferentes tipos de migraciones de bases de datos que pertenecen a diferentes clases. En esta sección, se describen los criterios que definen esas clases.

Comparación entre la replicación y la migración

En una migración de bases de datos, mueves datos de bases de datos de origen a bases de datos de destino. Una vez que los datos se migran por completo, borras las bases de datos de origen y redireccionas el acceso de los clientes a las bases de datos de destino. A veces, puedes mantener las bases de datos de origen como una medida de resguardo en caso de que surjan problemas imprevistos con las bases de datos de destino. Sin embargo, una vez que las bases de datos de destino funcionan de manera confiable, debes borrar las bases de datos de origen.

En cambio, con la replicación de base de datos, transfieres datos de forma continua desde las bases de datos de origen hacia las bases de datos de destino, sin borrar las de origen. A veces, la replicación de bases de datos se conoce como transmisión de bases de datos. Si bien hay una hora de inicio definida, por lo general, no se establece una hora de finalización. La replicación puede detenerse o convertirse en una migración.

Comparación entre la migración parcial y la migración completa

La migración de bases de datos se entiende como una transferencia de datos completa y coherente. Debes definir que el conjunto de datos inicial se transfiera como una base de datos completa o parcial (un subconjunto de los datos en la base de datos), además de que se transfiera cada cambio posterior confirmado en el sistema de base de datos de origen.

Comparación entre la migración heterogénea y la migración homogénea

Una migración de bases de datos homogénea es una migración entre bases de datos de origen y de destino con la misma tecnología de base de datos, por ejemplo, una migración desde una base de datos de MySQL hacia una de MySQL, o desde una base de datos de Oracle® hacia una de Oracle. Las migraciones homogéneas también incluyen migraciones entre un sistema de base de datos alojado en sí mismo, como PostgreSQL, y una versión administrada, como Cloud SQL (una variante de PostgreSQL).

En una migración de bases de datos homogénea, es probable que los esquemas de las bases de datos de origen y de destino sean idénticos. Si los esquemas son diferentes, los datos de las bases de datos de origen deben transformarse durante la migración.

La migración de base de datos heterogénea es una migración entre bases de datos de origen y de destino con diferentes tecnologías de base de datos, por ejemplo, desde una base de datos de Oracle hacia una de Spanner. La migración de base de datos heterogénea puede ser entre los mismos modelos de datos (por ejemplo, de un modelo relacional a uno relacional) o entre diferentes modelos de datos (por ejemplo, de un modelo relacional a uno de clave-valor).

La migración entre diferentes tecnologías de base de datos no siempre implica diferentes modelos de datos. Por ejemplo, Oracle, MySQL, PostgreSQL y Spanner admiten el modelo de datos relacionales. Sin embargo, las bases de datos de varios modelos, como Oracle, MySQL o PostgreSQL, admiten diferentes modelos de datos. Los datos almacenados como documentos JSON en una base de datos de varios modelos se pueden migrar a MongoDB con poca o ninguna transformación, ya que el modelo de datos es el mismo en las bases de datos de origen y de destino.

Aunque la distinción entre la migración homogénea y heterogénea se basa en tecnologías de base de datos, una categorización alternativa se basa en los modelos de bases de datos involucrados. Por ejemplo, una migración de una base de datos de Oracle a una de Spanner es homogénea si ambas usan el modelo de datos relacionales; una migración es heterogénea si, por ejemplo, los datos almacenados como objetos JSON en Oracle se migran a un modelo relacional en Spanner.

5.4 MÉTODOS DE RECUPERACIÓN DE UN DBMS

La recuperación consiste en tres pasos principales: Análisis: Identifica las páginas sucias y el conjunto de transacciones activas en el momento de la caída y el punto del log apropiado para empezar la operación REHACER Rehacer: se replican las operaciones del log. Deshacer: Se recorre el log hacia atrás y se deshacen las transacciones activas en el momento de la caída, o iniciadas después, de las que no se ha encontrado confirmación. Recuperación en Oracle Red Log Files: dos o más archivos donde se registra cualquier modificación transaccional de una memoria intermedia del BD.

 

Archivos de control: metadatos necesarios para operar en la base de datos, incluyendo información sobre copias de seguridad.

Segmento Rollback: guarda las últimas sentencias realizadas sobre la BD y sabe cuándo se ha confirmado o no una transacción.

 En la Recuperación de un fallo:

Recupera los datos con REHACER (Desde Redo Log File). Deshace las transacciones no comprometidas con Deshacer (Desde el segmento de rollback).

Comandos para recuperación

Cada vez que se ejecuta una tarea de copia de seguridad, CA ARCserve Backup registra la información en la base de datos sobre los equipos, directorios y archivos de los que se ha realizado copia de seguridad y los medios utilizados. Esto permite localizar archivos para cuando sea necesario restaurarlos. El comando de recuperación de base de datos (ca_recoverdb) es una opción de protección propia que permite recuperar una base de datos de CA ARCserve Backup si se ha perdido y se ha realizado copia de seguridad mediante el dominio de CA ARCserve Backup que está utilizando la base de datos. La utilidad ca_recoverdb sólo se utiliza para recuperar una base de datos de ARCserve (ASDB) en el mismo equipo o dominio de ARCserve en el que se ha realizado la copia de seguridad de ASDB. Si desea realizar la copia de seguridad de ASDB en un equipo y recuperarla en otro (los dos equipos no se encuentran en el mismo dominio de ARCserve), no se puede utilizar este comando. Ante esta situación dispone de dos soluciones:

Solución

1: Realizar una copia de seguridad de recuperación de desastres desde el equipo A y después recuperarla en el equipo B. Esta solución necesita que esté instalada la opción de recuperación de desastres (DR, Disaster Recovery).

La recuperabilidad significa que, si se da algún error en los datos, hay un bug de programa ó de hardware, el DBA (Administrador de base de datos) puede traer de vuelta la base de datos al tiempo y estado en que se encontraba en estado consistente antes de que el daño se causara. Las actividades de recuperación incluyen el hacer respaldos de la base de datos y almacenar esos respaldos de manera que se minimice el riesgo de daño o pérdida de los mismos, tales como hacer diversas copias en medios de almacenamiento removibles y almacenarlos fuera del área en antelación a un desastre anticipado.

Funciones de recuperación de bases de datos

Los servicios Ontrack Recuperación de Datos disponen de varias opciones de servicio para adaptarse a las necesidades de cada cliente.
Tipos de Recuperación de bases de datos:

·         Recuperación de servidores SQL

·         Recuperación de bases de datos de servidores Exchange

·         Recuperación de bases de datos SharePoint

·         Recuperación de bases de datos de Oracle

·         Recuperación de bases de datos de Lotus Notes

·         Recuperación de bases de datos de Access

Recuperación de bases de datos – Causas de la pérdida de datos

·         Daños en el software del dispositivo de almacenamiento (disco duro, SAN o RAID)

·         Daños en el sistema de archivos: controlado por el sistema operativo, el sistema de archivos almacena y organiza los archivos de los usuarios y el sistema

·         Daños en los archivos: la pérdida de datos se puede producir en el propio archivo

5.3 MÉTODOS DE RESPALDO DE UN SGBD

Es la obtención de una copia de los datos en otro medio magnético, de tal modo que a partir de dicha copia es posible restaurar el sistema al momento de haber realizado el respaldo. Por lo tanto, los respaldos deben hacerse con regularidad, con la frecuencia preestablecida y de la manera indicada, a efectos de hacerlos correctamente.

Existen varias maneras de respaldar base de datos MySQL, en este post únicamente mostraré una manera de hacerlo utilizando mysqldump() y PHP.

Básicamente lo que se realiza es un respaldo de todas las bases de datos, por lo que el script debe ejecutarse como un usuario que tenga permisos sobre todas las bases. Adicionalmente se mantiene en disco las ultimas 3 copias de los respaldos.

En mySQL existen varios métodos para la realización de un backup y esto se debe principalmente a que mySQL guarda las tablas como archivos y al tipo de tablas que se esté manejando (InnoDB, MyISAM, ISAM).

InnoDB es una de las tecnologías de almacenamiento que utiliza mySQL, es de codigo abierto. Entre sus características principales están que soporta transacciones con características ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad), tiene bloque de registros e integridad referencial (cosa que no maneja ISAM, ni myISAM). Esta última es una de sus características más importantes pues una base de datos sin integridad referencial, es nada más un conjunto de datos que no denotan información.

Este tipo de almacenamiento también ofrece una alta fiabilidad y consistencia. El mismo gestiona el control de los datos y no se lo deja al sistema operativo, una de sus desventajas es que no tiene una buena compresión de datos, por lo que ocupa un poco más de espacio que myISAM.

Normalmente cuando uno plantea que va a respaldar los datos de su PC a una persona en una compañía uno tiene que definir muy bien cuál es la información crítica para la empresa, por ejemplo la música que guarde un empleado en su PC no es crítica para las actividades de la empresa ni lo son las fotos de su última fiesta. En cambio su correo electrónico, proyectos, informes y papeles administrativos si lo suelen ser y tener un respaldo de estos es clave para el funcionamiento de la empresa en caso de cualquier eventualidad.

Normalmente lo datos o información que es respaldada por las empresas es:

v   Archivos creados por aplicaciones, como por ejemplo .doc, .odt, .xls, .mdb, .pdf, .ppt entre otros.

v   Archivos de correo electrónico

v   Directorios telefónicos y de contactos

v   Favoritos de los navegadores como Firefox e Internet Explorer

v   Base de datos

v   Configuraciones de los equipos

v   Archivos de CAD, PSD, XCF, etc.

v   Imágenes y Fotografías de proyectos

v   Configuraciones de servicios

 

Clasificación de Respaldos

·         Copias de Información (Backups)

 Estos respaldos son sólo duplicados de archivos que se guardan en "Tape Drives" de alta capacidad. Los archivos que son respaldados pueden variar desde archivos del sistema operativo, bases de datos, hasta archivos de un usuario común. Existen varios tipos de Software que automatizan la ejecución de estos respaldos, pero el funcionamiento básico de estos paquetes depende del denominado archive bit.

Este archive bit indica un punto de respaldo y puede existir por archivo o al nivel de "Bloque de Información" (típicamente 4096 bytes), esto dependerá tanto del software que sera utilizado para los respaldos así como el archivo que sera respaldado. Este mismo archive bit es activado en los archivos (o bloques) cada vez que estos sean modificados y es mediante este bit que se llevan a cabo los tres tipos de respaldos comúnmente utilizados:

·         Respaldo Completo ("Full")

Guarda todos los archivos que sean especificados al tiempo de ejecutarse el respaldo. El archive bit es eliminado de todos los archivos (o bloques), indicando que todos los archivos ya han sido respaldados.

·         Respaldo de Incremento ("Incremental")

Cuando se lleva a cabo un Respaldo de Incremento, sólo aquellos archivos que tengan el archive bit serán respaldados; estos archivos (o bloques) son los que han sido modificados después de un Respaldo Completo. Además cada Respaldo de Incremento que se lleve a cabo también eliminará el archive bit de estos archivos (o bloques) respaldados.

·         Respaldo Diferencial ("Differential")

Este respaldo es muy similar al "Respaldo de Incremento", la diferencia estriba en que el archivo bit permanece intacto.

·         Frecuencia de Actualización de la Información

Hay dos puntos importantes en cuanto a la actualización de la información:

·         Que tan frecuentemente se actualiza la información

·         Si queremos guardar un histórico de la información o no

No toda la información se actualiza con la misma frecuencia, hay información que puede durar años sin ser modificada y otra que se actualice constantemente todos los días, es importante definir qué información se actualiza y en qué momento para hacer una política de respaldo más eficiente.

La mayoría de las aplicaciones de respaldos hacen esto automáticamente fijándose en la fecha de modificación del archivo y comparándola con la que tiene en el respaldo.

El otro punto es si queremos hacer un respaldo con históricos o duplicados, en este caso tenemos que indicarle al programa que no queremos que nos borre o sobrescriba ningún archivo y que vaya guardando los archivos con su respectiva fecha y con qué frecuencia queremos hacer el respaldo.

En caso de que haya información que se pueda sobrescribir o actualizar, se realiza un respaldo incremental donde sólo se actualiza lo que ha cambiado del archivo lo que mejora la eficiencia de nuestro sistema. Esto realmente va a depender del tipo de información y varía de empresa a empresa pero es algo importante que tengamos que tomar en cuenta ya que toda la información no es igual.