UNIDAD 5: SEGURIDAD.

Implementa los mecanismos técnicos de seguridad para salvaguardar la información en la organización.

5.1 Espejeo (mirroring).

Base de Datos Espejo (Database Mirroring) es una configuración donde dos o tres servidores de dase de datos, ejecutándose en equipos independientes, cooperan para mantener copias de la base de datos y archivo de registro de transacciones (log). Tanto el servidor primario como elservidor espejo mantienen una copia de la base de datos y el registro de transacciones, mientras que el tercer servidor, llamado el servidor árbitro, es usado cuando es necesario determinar cuál de los los otros dos servidores puede tomar la propiedad de la base de datos.

El árbitro no mantiene una copia de la base de datos. La configuración de los tres servidores de base de datos (el primario, el espejo y el árbitro) es llamado Sistema Espejo (Mirroring System), y el servidor primarioy espejo juntos son llamados Servidores Operacionales (Operational Servers) o Compañeros (Partners).

 

Existen varios tipos de mirroring:

• ·    Alta disponibilidad: Garantiza la consistencia transaccional entre el servidor principal y el servidor de espejo y ofrece Automatic Failover mediante un servidor testigo.
• ·    Alta Protección: Garantiza la consistencia transaccional entre el servidor principal y el espejo.
• ·    Alto Rendimiento: Aplica las transacciones en el Servidor Espejo de manera asíncrona ocasionando mejoras significativas en el rendimiento del servidor principal pero no garantiza que dichas transacciones se hallan realizado de manera exitosa en el espejo.

 

Beneficios:

Mirroring esta tecnica fue introducida en la edicion 2005, se puede decir que es la evolución del log shipping. La principal diferencia es el tiempo de espera para tener la información mas actual el espejeo es un recurso mas rapido que el log shipping. Otra diferencia es que el servidor en stand by automaticamente puede levantarse en caso de que el servidor principal fallara (a esto se le llama espejeo de alta disponiblidad, y para esto requerimos de un tercer servidor al que nombran testigo), sin tener que restaurar los registros (en realidad, los registros se fusionan de forma continua en este escenario – no es de extrañar que se llama Espejo).

Las ventajas adicionales incluyen la creación de reflejo de apoyo a nivel NET Framework. Además de algunas nuevas características como la recuperación automática de páginas incluidas en SQL Server 2008. periodicamente a un servidor en stand by. Si el servidor activo va para abajo se puede subir el servidor en stand by restaurando todos los logs transferidos.

Creación de espacios de disco con espejo

Una vez preparados los discos, para crear el RAID, y si hemos seguido la misma estructura de mi ejemplo, usaremos las siguientes órdenes, suponiendo que los discos nos los ha identificado como sda, sdb, sdc y sdd:

mdadm --create --level=raid1 --raid-devices=2 /dev/sda1 /dev/sdb1 /dev/sdc1

/dev/sdd1

mdadm --create --level=raid5 --raid-devices=4 /dev/sda3 /dev/sdb3 /dev/sdc3

/dev/sdd3

 La primera orden nos creará un RAID de tipo RAID1 con sólo 2 componentes activos, empleando para ello la primera partición de cada disco. Como le indicamos menos dispositivos de raid (2) que dispositivos físicos, lo que hace es poner los otros dos como spares.

La segunda orden nos creará un RAID5 con la tercera partición de todos los discos indicados. En este caso, el parámetro --raid-devices=4 es superfluo y se podría omitir, ya que si no decimos nada sobreentiende que queremos usar todos los discos.

Recomendaciones

Use una copia de seguridad completa muy reciente o una copia de seguridad diferencial reciente de la base de datos principal.

Si se programa un trabajo de copia de seguridad de registros para que se ejecute muy a menudo en la base de datos principal, puede que sea necesario deshabilitar el trabajo de copia de seguridad hasta que se haya iniciado la creación de reflejo.

Si es posible, la ruta de acceso (incluida la letra de unidad) de la base de datos reflejada debería ser idéntica a la de la base de datos principal.
Si las rutas de acceso de archivo deben ser diferentes (por ejemplo, si la base de datos principal se encuentra en la unidad 'F:' pero el sistema reflejado no tiene unidad F:), se debe incluir la opción MOVE en RESTORE STATEMENT.

5.2 Réplica (replication).

Una replicación de base de datos es una técnica mediante la cual copiamos de forma exacta en otra ubicación una instancia de la base de datos. Se utiliza en entornos distribuidos de Sistemas de Gestión de Bases de Datos donde una sola base de datos tiene que ser utilizada y actualizada en varios lugares de forma simultánea.

 

 

Actualmente existen en la red multitud de aplicaciones y de sistemas que tienen por debajo una base de datos que sigue el modelo cliente-servidor. Muchas veces esos sistemas deben de tener garantizada la accesibilidad por lo que para evitar problemas es necesario utilizar este tipo de técnicas de replicación de base de datos de forma que un fallo en uno de los servidores de base de datos no impida a los usuarios seguir utilizando la aplicación.

Mediante la replicación de base de datos, usuarios de todo el mundo pueden estar accediendo a lo que para ellos son los mismos datos, aunque en realidad, físicamente esos datos pueden estar de forma transparente para el usuario, en diferentes nodos o localidades.

Tipos de replicación de base de datos

• ·         Replicación Instantánea: los datos de un servidor son simplemente copiados a otro servidor o a otra base de datos dentro del mismo servidor. Al copiarse todo no necesitas un control de cambios. Se suele utilizar cuando los datos cambian con  muy poca frecuencia.
• ·         Replicación Transaccional: primero se envía una copia completa de la base de datos y luego se van enviando de forma periódica (o a veces continua) las actualizaciones de los datos que cambian. Se utiliza cuando necesitas que todos los nodos con todas las instancias de la base de datos tengan los mismos datos a los pocos segundos de realizarse un cambio.
• ·         Replicación de mezcla: los datos de dos o más bases de datos se combinan en una sola base de datos. En primer lugar se envía una copia completa de la base de datos. Luego el Sistema de Gestión de Base de Datos va comprobando los cambios que van apareciendo en los distintos nodos y a una hora programada o a petición los datos se sincronizan. Es sobre todo útil cuando cada nodo suele utilizar solo los datos que se actualizan allí pero que por circunstancias necesita tener también los datos de los otros sitios.

 Beneficios de la replicación de base de datos

La replicación te puede ofrecer grandes beneficios relacionados principalmente con el rendimiento, disponibilidad y seguridad de los datos.

1. 1.    Aumento de la fiabilidad: mediante la replicación de base de datos a través de múltiples servidores, te aseguras que los datos van a estar disponibles incluso en el caso de que una de las máquinas tenga un fallo grave de hardware. El sistema distribuido de gestión de bases de datos debe ser capaz de enrutar a los usuarios afectados a otro de los nodos disponibles.
2. 2.    Mejora en el rendimiento: al estar los datos distribuidos en diferentes servidores, los múltiples accesos no saturan los servidores. Esto es importante sobre todo en el caso de aplicaciones que pueden tener miles o cientos de miles de peticiones simultáneas. El rendimiento de las aplicaciones aumenta notablemente.
3. 3  Mejora en la seguridad de los datos: en un sistema transaccional tradicional, todas las actualizaciones de una base de datos se guardan en un mismo disco. La seguridad de tus datos queda entonces en manos de la estrategia de copias de seguridad que tengas implementada en ese servidor. Con la replicación de base de datos aumentas la seguridad de los datos ya que las actualizaciones están siendo escritas en varios servidores. Es decir, varios discos, varias fuentes de alimentación, CPU’s, etc. son utilizadas para asegurar que tus datos estarán a salvo en algunos servidores, aunque pueda ocurrir un desastre en otros. En definitiva la replicación de base de datos se utiliza para propagar los datos en entornos de base de datos distribuidas de forma que se mejora la confiabilidad y el rendimiento de las aplicaciones que la utilizan. Tienes diferentes tipos de replicación de base de datos que puedes utilizar. El escoger uno u otro dependerá de la naturaleza y utilización de los mismos.

5.3 Métodos de respaldo de un SGBD.

El respaldo es uno de los pasos más importantes que puedes dar para proteger tu información. Cuando algo sale mal, como fallas en disco duro, borrado accidental de archivos o infecciones por malware, son tu último recurso.

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 este manejando (InnoDB, MyISAM, ISAM).

Así por ejemplo para la presente práctica se utilizó el tipo de tabla InnoDB y el método de backup utilizado es el que funciona con este tipo de tablas. InnoDB es una de las tecnologías de almacenamiento que utiliza mySQL, es de codigo abierto.

Entre sus características principales estan 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 mas un conjunto de datos que no denotan infomació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 mas de espacio que myISAM.

Como Respaldar:

En general, existen dos recursos en los que puedes respaldar tu información: medios físicos o almacenamiento en la nube. Ejemplos de medios físicos incluyen DVD’S, dispositivos USB, cintas magnéticas o discos duros adicionales.

Evita respaldar en el mismo dispositivo que contiene los archivos originales. Cuando uses medios físicos asegúrate de etiquetarlos, tanto interna (en el nombre del archivo) como externamente (sobre el dispositivo), para que puedas identificar fácilmente fecha y hora del respaldo.

Puedes almacenar el respaldo en un contenedor con llave, a prueba de fuego y de agua, dependiendo del medio que elegiste. Una opción más robusta es almacenar copias de tus respaldos fuera de las instalaciones. Para respaldos personales, puede ser tan simple como almacenarlos en casa de un miembro de la familia o en una caja de seguridad.

Las organizaciones quizá deseen contratar un servicio profesional para transportar y almacenar los respaldos de forma segura. Dependiendo de qué tan sensibles sean y dónde se almacenen los respaldos, tal vez convenga cifrarlos.

5.4 Métodos de recuperación de un SGBD.

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: 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 de la 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).

 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.

5.5 Migración de la Base de Datos.

La migración de bases de datos es generalmente una tarea compleja que no sólo supone transferir datos entre tipos de almacenaje y formatos de un servidor de base de datos a otro; sino que también supone reescribir sentencias SQL o incluso procedimientos (SPL) de lógica de negocio.

En comparación con los esquemas estándares de migración a mano, ofrecemos una potente gama de herramientas desarrolladas de probada eficacia en complejos módulos de bases de datos relacionales. Estas herramientas y nuestros especialistas pueden asegurar que las transiciones de las bases de datos se realicen perfectamente, independientemente de la naturaleza del sistema.

Desde la experiencia, estamos familiarizados con la complejidad, el coste que supone una larga migración de bases de datos y los problemas que aparecen durante el proceso cuando se emplean métodos inapropiados; ya que siempre comprobamos con los clientes potenciales que el uso de nuestras herramientas y métodos pueda ofrecer una ventaja significativa.

 Herramientas de migración:

En comparación con la consultoría estándar de migraciones, la cual puede ofrecer poco más que soporte a la base de datos, nosotros tenemos gran experiencia en escribir grandes aplicaciones para empresas en sintaxis de la base de datos nativa y cross. Además, enseñamos a los equipos de las empresas una metodología y les proporcionamos una potente gama de herramientas para reducir costes y optimizar el proceso de migración.