Salvaguarda y seguridad de los datos. IFCT0310

ic editorial

Salvaguarda y seguridad de los datos. IFCT0310

Autor: Enrique San Martín González

1ª Edición

© IC Editorial, 2014

Editado por: IC Editorial

C.I.F.: B-92.041.839

c/ Cueva de Viera, 2, Local 3 Centro Negocios CADI

29200 ANTEQUERA, Málaga

Teléfono: 952 70 60 04

Fax: 952 84 55 03

Correo electrónico: iceditorial@iceditorial.com

Internet: www.iceditorial.com

IC Editorial ha puesto el máximo empeño en ofrecer una información completa y precisa. Sin embargo, no asume ninguna responsabilidad derivada de su uso, ni tampoco la violación de patentes ni otros derechos de terceras partes que pudieran ocurrir. Mediante esta publicación se pretende proporcionar unos conocimientos precisos y acreditados sobre el tema tratado. Su venta no supone para IC Editorial ninguna forma de asistencia legal, administrativa ni de ningún otro tipo.

Reservados todos los derechos de publicación en cualquier idioma.

Según el Código Penal vigente ninguna parte de este o cualquier otro libro puede ser reproducida, grabada en alguno de los sistemas de almacenamiento existentes o transmitida por cualquier procedimiento, ya sea electrónico, mecánico, reprográfico, magnético o cualquier otro, sin autorización previa y por escrito de IC EDITORIAL;

su contenido está protegido por la Ley vigente que establece penas de prisión y/o multas a quienes intencionadamente reprodujeren o plagiaren, en todo o en parte, una obra literaria, artística o científica.

ISBN: 978-84-16433-31-5

Nota de la editorial: IC Editorial pertenece a Innovación y Cualificación S. L.

Presentación del manual

El Certificado de Profesionalidad es el instrumento de acreditación, en el ámbito de la Administración laboral, de las cualificaciones profesionales del Catálogo Nacional de Cualificaciones Profesionales adquiridas a través de procesos formativos o del proceso de reconocimiento de la experiencia laboral y de vías no formales de formación.

El elemento mínimo acreditable es la Unidad de Competencia. La suma de las acreditaciones de las unidades de competencia conforma la acreditación de la competencia general.

Una Unidad de Competencia se define como una agrupación de tareas productivas específica que realiza el profesional. Las diferentes unidades de competencia de un certificado de profesionalidad conforman la Competencia General, definiendo el conjunto de conocimientos y capacidades que permiten el ejercicio de una actividad profesional determinada.

Cada Unidad de Competencia lleva asociado un Módulo Formativo, donde se describe la formación necesaria para adquirir esa Unidad de Competencia, pudiendo dividirse en Unidades Formativas.

El presente manual desarrolla la Unidad Formativa, UF1473: Salvaguarda y seguridad de los datos,

perteneciente al Módulo Formativo, MF0225_3: Gestión de bases de datos,

asociado a la unidad de competencia UC0225_3: Configurar y gestionar la base de datos,

del Certificado de Profesionalidad Administración de bases de datos.

Índice

Portada

Título

copyright

Presentación

Índice

Capítulo 1 Salvaguarda y recuperación de los datos

1. Introducción

2. Conceptos previos

3. Descripción de los diferentes fallos posibles (tanto físicos como lógicos) que se pueden plantear alrededor de una base de datos

4. Enumeración y descripción de los elementos de recuperación ante fallos lógicos que aportan los principales SGBD

5. Distinción de los diferentes tipos de soporte utilizados para la salvaguarda de datos y sus ventajas e inconvenientes en un entorno de backup

6. Concepto de RAID y niveles más comúnmente utilizados en las empresas

7. Servidores remotos de salvaguarda de datos

8. Diseño y justificación de un plan de salvaguarda y un protocolo de recuperación de datos para un supuesto de entorno empresarial

9. Tipos de salvaguardas de datos

10. Empleo de mecanismos de verificación de la integridad de las copias de seguridad

11. Resumen

Ejercicios de repaso y autoevaluación

Capítulo 2 Bases de datos distribuidas desde un punto de vista orientado a la distribución de los datos y la ejecución de las consultas

1. Introducción

2. Definición de SGBD distribuido

3. Características esperadas de un SGBD distribuido

4. Clasificación de los SGBD distribuidos

5. Enumeración y explicación de las reglas de DATE para SGBD distribuidos

6. Replicación de la información en bases de datos distribuidas

7. Procesamiento de consultas

8. Descomposición de consultas y localización de datos

9. Resumen

Ejercicios de repaso y autoevaluación

Capítulo 3 Seguridad de los datos

1. Introducción

2. Conceptos de seguridad de los datos: confidencialidad, integridad y disponibilidad

3. Normativa legal vigente sobre datos

4. Seguimiento de la actividad de los usuarios

5. Introducción básica a la criptografía

6. Desarrollo de uno o varios supuestos prácticos en los que se apliquen los elementos de seguridad vistos con anterioridad

7. Resumen

Ejercicios de repaso y autoevaluación

Capítulo 4 Transferencia de datos

1. Introducción

2. Descripción de las herramientas para importar o exportar datos

3. Clasificación de herramientas

4. Muestra de un ejemplo de ejecución de una exportación o importación de datos

5. Migración de datos entre diferentes SGBD

6. Empleo de alguno de los mecanismos de verificación del traspaso de datos

7. Interconexión con otras bases de datos

8. Configuración de acceso remoto a bases de datos

9. Resumen

Ejercicios de repaso y autoevaluación

Bibliografía

Capítulo 1Salvaguarda y recuperación de los datos
1.Introducción

Los datos son un activo muy importante en cualquier entidad y empresa, por eso es muy necesario tenerlos a buen recaudo y siempre disponibles.

La pérdida de datos provoca un daño difícil de valorar, como la disminución de oportunidades de negocio, deterioro de la reputación y clientes decepcionados. Por otra parte, la tecnología no está exenta de errores que pueden llevar al traste con los datos almacenados.

En este capítulo se estudiarán las distintas amenazas que se pueden cernir sobre los datos, así como los elementos de que dispone un Sistema de Gestión de Base de Datos (SGBD) para soportar y recuperarse de estas incidencias.

Se verán los soportes más utilizados para el almacenamiento, describiendo las ventajas de unos sobre otros, y se analizará la importancia que tienen los sistemas RAID de almacenamiento para la protección de las actuales bases de datos.

Asimismo, y gracias al avance de la velocidad en las telecomunicaciones, los servidores remotos de bases de datos son hoy en día una solución muy efectiva y práctica para el almacenamiento. Pero cualquier actuación relacionada con la salvaguarda de datos debe estar documentada y estudiada por un plan de contingencias, que indique unas pautas a seguir que han sido previamente analizadas, en el desgraciado caso de que ocurra algún incidente de seguridad.

El concepto de salvaguarda de datos corresponde al hecho de que se tengan los datos sin posibilidad de perderlos, siempre a salvo y con posibilidad de recuperarlos en caso de cualquier tipo de incidente.

2.Conceptos previos

Es importante introducir una serie de conceptos generales para poder desarrollar el tema. La recuperación surge como la necesidad que hay de establecer un punto fijo y fiable donde se pueda proteger la información frente a posibles fallos del sistema.

Es muy importante el concepto de transacción, que es un conjunto de operaciones que forman una única unidad lógica de trabajo, un sistema de base de datos. Hay que asegurarse en todo caso que la ejecución de una transacción se realiza toda ella, o que no se realiza ninguna parte de ella.

En este breve ejemplo se ve que hay dos operaciones: (leer) y (escribir).

En la operación leer, la base de datos simplemente toma el dato almacenado en memoria sin realizar ninguna modificación en este. Mientras, en la operación escribir se sustituye el valor que tiene el dato por el valor nuevo que le quedaría después de hacer las operaciones correspondientes, modificando por tanto el dato y, por consiguiente, la base de datos.

La transacción consiste en quitar 100 de la cuenta1 (apuntarlo nuevamente en la base de datos) y luego estos 100 añadirlos a la cuenta2, y apuntarlo asimismo en la base de datos.

Todo este conjunto de las seis operaciones constituye una transacción única.

Para asegurar la integridad de los datos se necesita que cualquier sistema de base de datos cumpla las propiedades ACID (Atomicidad, Consistencia Aislamiento y Durabilidad), donde:

Nota: ACID es un acrónimo de Atomicity, Consistency, Isolation and Durability: Atomicidad, Consistencia, Aislamiento y Durabilidad en español.

Atomicidad: significa que o bien se realizan correctamente todas las operaciones de la transacción, o no se realiza ninguna de ellas.

En este ejemplo, puede ocurrir que la cuenta1 tenga un valor de 500, y se le quite 100, y que por cualquier incidencia se ejecute hasta el punto 3) Escribir(cuenta1), y no se ejecute el resto de la transacción. En la cuenta1 se modificaría el importe incorrectamente, porque no estaría añadido a cuenta2. Se habrían perdido 100.

Consistencia: significa que la ejecución por sí sola de una transacción (que no se ejecute ninguna más con ella) deja a la base de datos en un estado de consistencia. Es decir, después de ejecutar la transacción la base de datos queda en un estado correcto.

El ejemplo anterior serviría para ver que el total de la suma de cuenta1 y cuenta2 se vería alterado.

Aislamiento: significa que aunque se ejecuten varias transacciones a la vez, el sistema asegura que una transacción T no muestra los cambios hasta que finaliza, es decir, cada transacción no tiene en cuenta al resto de las transacciones que se están ejecutando concurrentemente en el sistema.Dicho de otra manera, para dos transacciones Ti y Tj, que se ejecutan a la vez, se cumple para Ti que Tj terminó su ejecución antes que empiece Ti o bien Tj comenzó desde que Ti termine.

Se añade ahora otra transacción más:

Ahora se están ejecutando estas dos transacciones a la vez. Lógicamente el valor de cuenta1 será distinto, y no se puede hacer la transacción 2 sin haber finalizado la transacción 1 o viceversa, porque si no el valor de cuenta1 sería distinto.

Durabilidad: significa que una vez finalizada correctamente una transacción y confirmada, los cambios en la base de datos se mantendrán, incluso aunque haya fallos en el sistema. Para eso es necesario que al terminar cada transacción se guarde en el disco o en algún tipo de memoria no volátil que se pueda recuperar siempre.

Una transacción cumple el siguiente orden de estados, que es importante conocer para poder establecer los sistemas de recuperación.

Cuando se inicia una transacción esta comienza en un estado de ACTIVA. esa transacción se puede ejecutar correctamente realizándose en ellas operaciones de leer o escribir, lo que haría que pasase a un estado de PARCIALMENTE CONFIRMADA o abortar por cualquier causa, por lo que daría lugar a un estado de FALLIDA, CANCELADA o (ROOLLBACK) y se TERMINA.

Si está en estado de PARCIALMENTE CONFIRMADA y cumple una serie de verificaciones, la transacción pasa a confirmarse, a escribirse en memoria no volátil y pasaría al estado de CONFIRMADA y se termina. Si por cualquier causa estando en estado de PARCIALMENTE CONFIRMADA no cumple determinadas reglas o no se puede escribir a memoria no volátil la transacción, se pasará a estado de FALLIDA y se TERMINA.

Es muy importante el correcto conocimiento de este estado de transacción para saber cómo funcionan los sistemas de recuperación que tienen los Sistemas de Gestión de Bases de Datos.

Actividades

1.Señale qué tipo de error se produciría en una base de datos si en la casilla de la cantidad de dinero disponible se ingresa el nombre de su provincia.

3.Descripción de los diferentes fallos posibles (tanto físicos como lógicos) que se pueden plantear alrededor de una base de datos

Existen varios tipos de fallos: el más fácil de tratar es el que no conduce a la pérdida de información y el más difícil, el que produce una pérdida de información.

Para poder definir cómo un sistema de base de datos puede recuperarse antes los fallos es muy importante definir previamente los modos de fallo que pueden ocurrir en la base de datos y así establecer un plan de reparación o recuperación.

En una primera aproximación pueden dividirse en:

3.1.Fallos lógicos. tipos

Cualquier fallo que afecta a los procesos y transacciones abiertos en la bases de datos. Pueden ser de tres tipos:

Fallos de transacción

Estos se caracterizan por que el resto de las transacciones continúan ejecutándose (salvo a la que le afecte el fallo), y pueden ser de dos tipos:

Fallos locales previstos por la aplicación. La transacción no puede continuar ejecutándose normalmente a causa de alguna condición interna, como puede ser una entrada de datos incorrecta, datos que no aparecen, desbordamiento, etc.

Fallos locales no previstos. El sistema en ese momento está en un estado no deseado, en el que la transacción no puede ejecutarse normalmente en ese momento (pero se podrá ejecutar más tarde), por ejemplo, un interbloqueo.

Fallos por imposición del control de concurrencia

Por ejemplo, si este subsistema decide abortar una transacción para reiniciarla luego, porque se vulneró la seriabilidad de las transacciones o porque alguna está en bloqueo mortal.

Nota

El control de concurrencia es el que evita que las transacciones que se ejecutan a la vez no interfieran entre sí.

Fallos del sistema

Como un error en el software del sistema operativo, que causa la pérdida de la memoria volátil, aunque el contenido de la memoria no volátil se mantiene. Todas las transacciones que se realizaron y que estaban afectadas en ese momento deben ser recuperadas.

Un ejemplo sería el error en el sistema operativo que hace reiniciar el equipo en un momento determinado.

3.2.Fallos Físicos. tipos

Estos fallos son debidos a algún dispositivo físico cuyo mal funcionamiento puede dar lugar incluso a la pérdida total de la base de datos, no únicamente a las transacciones que se están realizando en el momento del incidente. Pueden ser de dos tipos:

Fallos de disco

Que es la caída de cualquier tipo de dispositivo físico de almacenamiento, como puede ser el fallo de disco en el que una parte de este puede perder su información por cualquier tipo de fallo físico en el mismo. Igual que en el anterior, todas las transacciones afectadas en ese momento deben ser recuperadas.

Fallos catastróficos

Pueden ser debidos a fenómenos tales como un corte en la energía eléctrica, cualquier hecho catastrófico, inundación, incendio, robo, sabotaje, etc.

Como se aprecia en el mismo, no siempre los fallos que se piensan que son más habituales son los que realmente ocurren

Actividades

2.Señale qué podría ocurrir en la base de datos de un sistema bancario si dos personas intentan acceder a una misma cuenta bancaria en el mismo momento y desde dos ubicaciones diferentes. Averigüe si se produciría algún tipo de fallo e indique cuál.

Aplicación práctica

Imagine que se encuentra a un amigo que le dice que acaba de abrir una clínica y que tiene una base de datos de los clientes en su ordenador que es muy importante para su negocio, pero que como es muy pequeña y su ordenador muy potente dice que es imposible que falle. ¿Podría rebatirle su argumento?

SOLUCIÓN

Una posible solución sería indicarle que su base de datos podría tener un montón de problemas que él no espera o no imagina, por ejemplo: puede introducir mal algún dato, puede quedarse colgado el ordenador y no poder introducir en un momento determinado datos de un cliente, puede inundarse o quemarse el negocio, puede estropearse el disco donde guarda los datos, pueden robarle, etc.

Hay muchas incidencias que podrían surgir que desconoce y si realmente es importante, el daño a su clínica puede ser mayor de lo esperado.

4.Enumeración y descripción de los elementos de recuperación ante fallos lógicos que aportan los principales SGBD

El sistema de recuperación es el que restaura la base de datos a un estado en que se sepa que es correcto tras cualquier incidente que le haya ocurrido a la misma, y que le hubiese producido quedar en un estado incorrecto o inconsistente.

En el proceso de recuperación, los algoritmos tienen que realizar dos tipos de acciones:

Acciones durante el procesamiento normal de las transacciones.

Acciones después del fallo.

Los Sistemas de Gestión de Base de Datos (SGBD) disponen de distintos mecanismos y herramientas para la recuperación ante cualquier fallo que pueda ocurrir. De esta operación se encarga el gestor de recuperaciones.

Este ejecuta una serie de algoritmos de recuperación para garantizar la consistencia y atomicidad de las transacciones.

Lo primero que tiene que asegurar el gestor de recuperaciones es que una vez que una transacción se ha confirmado no es necesario deshacerla.

Las transacciones se ordenan con un determinado orden, que es lo que se llama planificación.

Una planificación P de n transacciones T1…. Tn es un ordenamiento de las operaciones de cada una de las transacciones, que respeta el orden interno de las operaciones dentro de cada transacción.

En función de la recuperabilidad de las transacciones, estas se clasifican en:

Planificaciones recuperables

Son aquellas en las que una vez que una transacción T se confirma nunca será necesario deshacerla.

Una planificación P es recuperable si ninguna transacción T se confirma antes de que se hayan confirmado todas las transacciones T’ que han escrito un elemento que T lee posteriormente.

Es decir, una determinada transacción que lee o escribe un elemento no se podrá confirmar si no se ha modificado antes cualquier transacción que modificó dicho elemento anteriormente.

En el ejemplo anterior, se puede ver cómo cuando la transacción T2 llega a comprometerse no lee ningún elemento que haya escrito antes T1, por lo tanto es recuperable.

Si ahora la transacción sigue la siguiente secuencia, entonces es no recuperable:

La planificación anterior no es recuperable porque la transacción T2 se confirma después de leer el elemento x, después de que T1 lo haya escrito. Si por cualquier razón hay que cancelar la transacción T1 el valor que ha leído T2 es erróneo.

Actividades

3.Averigüe cómo podría cambiarse la planificación del ejemplo anterior para que fuese recuperable.

En un plan recuperable puede ocurrir el fenómeno llamado revisión en cascada, en el que una transacción T no confirmada se deshace por haber leído un elemento de una transacción fallada. Esto puede consumir muchos recursos.

En el ejemplo anterior, se ve que si hay que abortar la transacción T1, la transacción T2 también será necesario abortarla, ya que ha leído un elemento que ha escrito T1 que ha sido abortado.

Este proceso se puede dar en cadena, lo que produce un excesivo consumo de recursos. Por eso, es conveniente elegir un plan sin cascada, que es aquel en que toda transacción solo lee datos escritos por transacciones confirmadas.

En el ejemplo anterior, se ve que para que fuese un plan sin aborto en cascada sería suficiente con retrasar el momento de la lectura de la transacción T2 a un momento posterior al compromiso de la transacción T1.