TEMA 15. - kybele.etsii.urjc.es · confidencialidad, algunos SGBD (ej. ORACLE) suelen incorporar...
-
Upload
duongtuyen -
Category
Documents
-
view
242 -
download
1
Transcript of TEMA 15. - kybele.etsii.urjc.es · confidencialidad, algunos SGBD (ej. ORACLE) suelen incorporar...
TEMA 15.
SEGURIDAD EN BASES DE DATOS
© 2012 Grupo Kybele22
Indice
1. Introducción y Motivación
2. Confidencialidad
Mecanismos de Control de Acceso a BD
SGBD Multinivel
3. Disponibilidad
Concepto de Transacción
El fichero diario (log)
Técnicas de recuperación
4. Integridad
Integridad Semántica
Integridad Operacional
5. Auditabilidad
© 2012 Grupo Kybele33
Introducción y Motivación (I)
El aspecto global de la seguridad de información
está muy vinculado al propio concepto de BD:
Un conjunto de datos integrados, adecuado a varios
usuarios y a diferentes usos.
El propio uso de los datos por parte de usuarios o
programas plantea problemas de seguridad.
WH
O?
AS
SE
TS
TP1 TP2 TPN
TP – Technological Product
© 2012 Grupo Kybele44
Introducción y Motivación (II)
La protección de datos deberá realizarse contra:
Fallos Físicos (CPU, RAM, Disco, …).
Fallos Lógicos (Programación, SO, …).
Fallos Humanos (Intencionales y no intencionales).
Atendiendo los cinco aspectos fundamentales que
comprende la seguridad:
Confidencialidad.
Disponibilidad.
Integridad.
Auditabilidad.
No repudio.
© 2012 Grupo Kybele55
Introducción y Motivación (III)
Debemos ser conscientes que las medidas de
seguridad que debemos establecer afectan:
Comunicaciones (Canales cifrados).
Sistemas Operativos (Actualizaciones de Seguridad).
Tecnologías instaladas (Oracle, LDAP, …).
SGBD (Control de Acceso, …).
Medidas de Seguridad Físicas (Más de un CPD).
Organizativas (Normas, Políticas, ISO-27000, …).
Legales (LOPD).
© 2012 Grupo Kybele66
Indice
1. Introducción y Motivación
2. Confidencialidad
Mecanismos de Control de Acceso a BD
SGBD Multinivel
3. Disponibilidad
Concepto de Transacción
El fichero diario (log)
Técnicas de recuperación
4. Integridad
Integridad Semántica
Integridad Operacional
5. Auditabilidad
© 2012 Grupo Kybele77
Confidencialidad (I)
Definición ISO-17779
“Garantizar que la información sólo sea accedida por
aquellas personas autorizadas a tener acceso”.
El sistema debe identificar, autenticar y
autorizar a los usuarios que intentan acceder al
sistema:IBM Host
IBM RACFA
cces
s C
on
tro
l
Data
ProgramsIden
tifi
cati
on
Au
then
tica
tio
n
© 2012 Grupo Kybele88
Confidencialidad (II)
Mecanismos de Identificación y Autenticación:
Usuario y contraseña.
Identificación por hardware.
Biométricos (huellas dactilares, voz, retina, …).
Token de seguridad.
Información predefinida (aficiones, datos culturales, …).
El mecanismo de autorización o control de
acceso se encarga de denegar o conceder el
acceso a los usuarios.
© 2012 Grupo Kybele99
Confidencialidad Control de Acceso (I)
Tipos de Control de Acceso
Control de Acceso Discrecional: Se utilizan para
otorgar privilegios a los usuarios que tiene creados el
SGDB.
Control de Acceso Obligatorio: sirven para imponer
seguridad en múltiples niveles, clasificando los datos y
los usuarios en varias clases de seguridad.
© 2012 Grupo Kybele1010
Confidencialidad Control de Acceso (II)
En el Control de Acceso Discrecional, el administrador de
los datos, deberá especificar los privilegios de un usuario
autorizado sobre los objetos de la BD:
IMPORTANTE: A cada usuario se le deben dar los
permisos mínimos para realizar las funciones
que tiene asignadas
© 2012 Grupo Kybele1111
Confidencialidad Control de Acceso (III)
Para facilitar la administración de la
confidencialidad, algunos SGBD (ej. ORACLE)
suelen incorporar los siguientes conceptos:
Usuario: Son los requisitos que necesita un usuario
para que se le asigne un rol (Profesor, Alumno, …).
Rol: agrupa una serie de privilegios que se asigna de
forma global a un usuario o perfil.
CREATE USER alumno_Vicalvaro
IDENTIFIED BY miclavesecreta;
CREATE ROLE alumnos_URJC;
GRANT SELECT, INSERT, UPDATE,
DELETE ON T_MATRICULAS TO
alumnos_URJC;
GRANT alumnos_URJC TO
alumno_Vicalvaro;
© 2012 Grupo Kybele1212
Confidencialidad Control de Acceso (IV)
Es muy importante que cada BD que creemos
dentro de nuestro SGBD, tenga mínimo un
usuario específico con permisos de acceso a la
nueva BD.
Objetivo => Cada una de las aplicaciones que
interactúan con el SGBD no deben acceder a las
BBDD mediante el usuario root (MySQL) o
dba_admin (ORACLE).
¿Tiene sentido mantener el usuario root
dentro de nuestro SGBD?
© 2012 Grupo Kybele1313
Confidencialidad BD Multinivel (I)
Los SGDB Multinivel soportan el control de acceso
obligatorio a través de datos con diferentes
niveles o clases de confidencialidad (clases de
seguridad) y usuarios con diferentes clases de
autoridad.
Una clase de confidencialidad consta de dos
componentes:
Uno jerárquico: ALTO SECRETO (TS), SECRETO (S),
CONFIDENCIAL (C), NO CLASIFICADO (U)
◦ TS S C U
Un conjunto de categorías no jerárquicas (Finanzas,
Ventas, Investigación, etc.).
© 2012 Grupo Kybele1414
Confidencialidad BD Multinivel (II)
Ladiferencia con respecto a la seguridad discrecional
radica en que los datos tienen un nivel de seguridad
por sí mismos, con independencia de los permisos que se
atribuyan a los usuarios.
El modelo que suele usarse para la seguridad multinivel es
el modelo de Bell-LaPadula:
Asigna a cada sujeto (usuario, programa, ...) y objeto
(relación, tupla, columna, vista,...) una de las clases de
seguridad (TS, S, C o U).
Nos referiremos a la clasificación de un sujeto S como
clase(S).
Nos referiremos a la clasificación de un objeto O como
clase(O).
© 2012 Grupo Kybele1515
Confidencialidad BD Multinivel (III)
El modelo Bell-LaPadula asegura el cumplimiento de dos
restricciones:
Regla de lectura-no-ascendente (no-read-up), o propiedad de
seguridad simple: ”Un sujeto S no puede tener acceso de lectura a
un objeto O a menos que clase(S) clase(O).”
◦ Es la encargada de proteger los datos contra accesos no
autorizados, ya que ningún sujeto podrá leer un objeto cuya
clasificación de seguridad sea más alta que la clasificación del
propio sujeto.
Reglas de escritura-no-descendente (no-write-down), o
propiedad "*" (estrella): ”Un sujeto S no puede tener acceso de
escritura a un objeto O a menos que clase(S) clase(O)”
◦ Es la encargada de proteger los datos contra su contaminación,
ya que prohíbe a un sujeto escribir a un objeto que tenga la
clasificación de seguridad menor que la clasificación del sujeto.
◦ Cumpliendo la regla no-read-up => clase(S) =clase(O)
© 2012 Grupo Kybele1616
Confidencialidad SGBD Multinivel (IV)
En caso de un SGBD Relacional Multinivel se deben
clasificar los datos a nivel de atributo, tupla (fila) o
relación.
Así, cada atributo A está asociado a un atributo de clasificación C
en el esquema, y cada valor de atributo de una tupla está asociado
a una clasificación de seguridad correspondiente.
Además, en algunos modelos se añade un atributo de clasificación
de tupla CT a los atributos de la relación.
Una relación multinivel R con N atributos con protección a
nivel atributo se representa: R (A1, C1, ... , An, Cn, CT),
donde Ci representa el atributo de clasificación asociado
al atributo Ai.
Empleado (DNI, C, Nombre, U, Productividad, S, S)
© 2012 Grupo Kybele1717
Confidencialidad SGBD Multinivel (V)
SGBD Relacional Multinivel
El nombre de la relación también tiene una
clasificación. (que debe ser tan alta como la
clasificación más alta de los atributos contenidos en la
relación).
Una relación R puede ser accedida por cualquier sujeto
S que cumpla: clase (S) clase (R), caso contrario habrá
que estudiar clase por clase cada uno de los atributos.
© 2012 Grupo Kybele1818
Indice
1. Introducción y Motivación
2. Confidencialidad
Mecanismos de Control de Acceso a BD
SGBD Multinivel
3. Disponibilidad
Concepto de Transacción
El fichero diario (log)
Técnicas de recuperación
4. Integridad
Integridad Semántica
Integridad Operacional
5. Auditabilidad
© 2012 Grupo Kybele1919
Disponibilidad (I)
Definición: “es la característica, cualidad o
condición de la información de encontrarse a
disposición de quienes deben acceder a ella, ya
sean personas, procesos o aplicaciones”.
Para asegurar la disponibilidad de una BD se
deben utilizar herramientas ajenas al SGDB:
Máquinas tolerantes a fallos.
Sistemas de alimentación ininterrumpida.
Técnicas de tolerancia para redes de comunicaciones…
En este tema, sólo nos vamos a centrar en la
funcionalidad que proporciona el SGBD.
© 2012 Grupo Kybele2020
Disponibilidad (II)
En lo que afecta al SGBD existen dos tipos
importantes de fallos:
Los que provocan la pérdida de memoria volátil,
usualmente debidos a la interrupción del suministro
eléctrico o por funcionamiento anormal del hardware.
Los que provocan la pérdida de contenido de
memoria secundaria, por ejemplo, el producido al
patinar las cabezas de un disco.
El principio básico en el que se apoya la recuperación
de información de la base de datos ante cualquier
fallo es la redundancia física.
© 2012 Grupo Kybele2121
Disponibilidad Transacción (I)
Def. Transacción: “secuencia de operaciones que
han de ejecutarse de forma atómica”.
Propiedades de una transacción:
Atomicidad: se ejecutan todas las sentencias o
ninguna.
Preservación de la consistencia: la ejecución de una
transacción debe dejar a la BD en un estado
consistente.
Aislamiento: una transacción no muestra los cambios
que produce hasta que finaliza.
Persistencia: puesto que una vez la transacción finaliza
con éxito, sus efectos perduran en la BD.
© 2012 Grupo Kybele2222
Disponibilidad Transacción (II)
Después de ejecutar una transacción nos
podemos encontrar en dos estados:
Éxito: en cuyo caso las actualizaciones que constan la
transacción se graban (commit), es decir, se hacen
persistentes.
Fracaso: en cuyo caso debe ser restaurado el estado
inicial en el que se encontraba la BD antes de que
empezara a ejecutarse la transacción. Las
modificaciones deberán deshacerse (rollback).
© 2012 Grupo Kybele2323
Disponibilidad Transacción (III)
Arquitectura de un SGBD en la gestión de
transacciones y recuperación
GESTOR
DE “MEMORIA
INTERMEDIA”
establevolátil
© 2012 Grupo Kybele2424
Disponibilidad Transacción (IV)
Copia Doble
Las grandes organizaciones mantienen los datos
originados por las transacciones duplicados en dos
lugares distintos (como mínimo), separados físicamente
por centenas y millares de KM.
El gestor de memoria intermedia cada vez que se
realiza una transacción con éxito debe almacenar los
datos en dos cabinas (o más) de discos.
¿Creéis que este proceso tiene riesgo tolerable?
© 2012 Grupo Kybele2525
Disponibilidad El Fichero Diario (I)
Un registro del fichero diario (log) suele constar:
Identificador de la transacción
Usuario
Hora de la modificación
Identificador del registro afectado
Tipo de acción
Valor anterior del registro
Nuevo valor del registro
Información adicional
© 2012 Grupo Kybele2626
Disponibilidad El Fichero Diario (II)
Log write-ahead protocol: cambios en la BD y no
en el fichero diario producen problemas; se obliga
a que los registros que se modifican se escriban
antes en el fichero diario que en la base de datos.
El fichero diario:
Puede ser un fichero circular.
Puede constar de dos partes:
◦ La primera, en-línea (en disco), que almacena las
actualizaciones hasta que se llena.
◦ Momento en el que se pasa el contenido a la segunda parte
(por ejemplo, en cinta).
© 2012 Grupo Kybele2727
Disponibilidad Técnicas de Recuperación (I)
Recuperación en caliente
Al ocurrir un fallo de memoria volátil, el sistema consulta el
fichero diario para determinar las transacciones que hay que
deshacer porque no han sido completadas y las que hay que
rehacer porque, si bien se han completado, no habían sido
grabadas en la BD cuando se produjo el fallo.
© 2012 Grupo Kybele2828
Disponibilidad Técnicas de Recuperación (II)
Recuperación en frío
Se produce cuando ocurre un fallo de memoria estable.
Consiste en utilizar una copia de seguridad de la BD,
también llamada de respaldo (backup), que permitirá, junto
con los ficheros diarios, reconstruir la BD.
Error fatal
Se produce cuando se pierde el fichero diario grabado en
un soporte.
En este caso resulta imposible recuperar la BD a su estado
actual. La mejor solución para evitar este problema es
permitir la gestión de copias del fichero diario en
dispositivos independientes.
© 2012 Grupo Kybele2929
Indice
1. Introducción y Motivación
2. Confidencialidad
Mecanismos de Control de Acceso a BD
SGBD Multinivel
3. Disponibilidad
Concepto de Transacción
El fichero diario (log)
Técnicas de recuperación
4. Integridad
Integridad Semántica
Integridad Operacional
5. Auditabilidad
© 2012 Grupo Kybele3030
Integridad
Objetivo
Proteger la BD contra operaciones que introduzcan
inconsistencias en los datos: corrección, validez o
precisión de los datos.
El subsistema de integridad de un SGBD debe
detectar y corregir las operaciones incorrectas.
Existen dos tipos de operaciones que pueden atentar
contra la integridad de los datos:
Operaciones semánticamente inconsistentes.
Interferencias debidas a accesos concurrentes.
© 2012 Grupo Kybele3131
Integridad Integridad Semántica (I)
Existen operaciones que pueden violar restricciones definidas
al diseñar la BD (sobre dominios o sobre atributos).
Los SGBD tienen que ofrecer facilidades que permitan describir
las restricciones, con una sintaxis adecuada y gran
flexibilidad.
Las reglas de integridad se almacenan en el diccionario
(control centralizado de la semántica); ya no han de incluirse
en los programas, con lo que se consiguen las siguientes
ventajas:
Las reglas de integridad son más sencillas de entender y de
cambiar, facilitando su mantenimiento.
Se detectan mejor las inconsistencias.
Se protege mejor la integridad, ya que ningún usuario podrá
escribir un programa que las viole.
© 2012 Grupo Kybele3232
Integridad Integridad Semántica (II)
El subsistema de integridad del SGBD debe
realizar las siguientes funciones:
Comprobar la coherencia de las reglas que se
definen.
Controlar las distintas transacciones.
Detectar las violaciones de integridad.
Cuando se produce una violación, ejecutar las
acciones pertinentes.
© 2012 Grupo Kybele3333
Integridad Integridad Semántica (III)
Problema
En muchas organizaciones no se permiten identificar
restricciones para controlar la integridad semántica
dentro del SGBD.
Solución
Aportar un aplicativo externo al SGBD que haga las
comprobaciones de integridad semántica antes de
incluir la información en la BD.
Esta solución implica:
◦ Más facilidades para los programadores a la hora de realizar
sus diseños.
◦ Mayor complejidad a la hora de mantener la integridad de los
sistemas de información.
© 2012 Grupo Kybele3434
Integridad Integridad Operacional (I)
En sistemas multiusuario es imprescindible un
mecanismo de control de concurrencia para
conservar la integridad de la BD.
Si no tuviéramos estos mecanismos, al interactuar
con la BD se podrían:
Perder operaciones.
Obtener salidas inconsistentes.
Acceder a datos no reproducibles.
Estado inconsistente de la BD
© 2012 Grupo Kybele3535
Integridad Integridad Operacional (II)
© 2012 Grupo Kybele3636
Integridad Integridad Operacional (III)
Las técnicas de control de concurrencia más
habituales son:
Bloqueo.
Marcas de tiempo.
Técnicas optimistas.
Técnicas avanzadas
© 2012 Grupo Kybele3737
Integridad Integridad Operacional (IV)
Bloqueo o cerrojo
Variable asociada a cada elemento de datos, describiendo el
estado de dicho elemento respecto a las posibles
operaciones (recuperación o actualización).
El propio SGBD gestiona ciertos bloqueos.
Los usuarios también pueden bloquear, de forma
explícita, los objetos deseados.
Estos bloqueos pueden ser :
Bloqueos exclusivos (o de escritura)
Bloqueos compartidos (o de lectura)
PROBLEMA INTERBLOQUEOS
© 2012 Grupo Kybele3838
Integridad Integridad Operacional (V)
Granularidad del Bloqueo
Los bloqueos afectan fuertemente al rendimiento del
sistema.
Los SGBD difieren en los niveles del bloqueo:
◦ Un campo/un atributo
◦ Un registro/una tupla
◦ Una tabla/una relación
◦ La base de datos en su totalidad
Si se utilizan bloqueos de distintas granularidades,
puede hacer ineficiente el sistema.
© 2012 Grupo Kybele3939
Esta técnica permite ordenar las transacciones y controlar
un acceso en secuencia de las mismas a los datos.
Integridad Integridad Operacional (VI)
Marcas de tiempo (timestamping)
Identificadores únicos que se asignan a las
transacciones. Pueden considerarse como el tiempo
de inicio de la transacción.
Con esta técnica no existen interbloqueos.
Todas las actualizaciones físicas se retrasan hasta la
grabación de las transacciones.
Si una transacción quiere acceder a algún dato que ha
sido actualizado por una más reciente, se deshace y se
vuelve a empezar.
© 2012 Grupo Kybele4040
Integridad Integridad Operacional (VII)
Existen varios protocolos basados en marcas de
tiempo:
WAIT-DIE que fuerza a una transacción a:
◦ Esperar en caso de que entre en conflicto con otra transacción
cuya marca de tiempo sea más reciente, o
◦ Morir (abortar y reiniciar) si la transacción que se está
ejecutando es más antigua.
WOUND-WAIT:
◦ Permite a una transacción matar a otra que posea una marca
de tiempo más reciente, o
◦ Fuerza a la transacción peticionaria a esperar.
© 2012 Grupo Kybele4141
Integridad Integridad Operacional (VIII)
Ejemplo 1
Tenemos dos transacciones: transacción 1 (T1) y la
transacción 2 (T2).
T1 es más antigua que T2
Utilizando el protocolo WAIT-DIE, ¿qué ocurriría si T1
solicita un objeto que está siendo usado por T2?
Utilizando el protocolo WAIT-DIE, ¿qué ocurriría si T2
solicita un objeto que está siendo usado por T1?
Ejemplo 2
¿Qué ocurriría si estuviéramos utilizando un protocolo
WOUND-WAIT?
© 2012 Grupo Kybele4242
Integridad Integridad Operacional (IX)
Técnicas Optimistas
Permiten que las transacciones accedan libremente a
los objetos.
Se determina, antes de su finalización, si ha habido o
no interferencias.
Cada transacción consta de dos o más fases:
◦ Una fase de lectura
◦ Una fase de validación
◦ Y, posiblemente, una fase de escritura.
Durante la fase de lectura todas las escrituras tienen
lugar en copias locales (versiones transitorias).
© 2012 Grupo Kybele4343
Integridad Integridad Operacional (X)
Técnicas avanzadas
Las aplicaciones avanzadas de BD (CAD/CAM, CASE,
OIS, GIS) requieren nuevos mecanismos de control de
concurrencia:
◦ Transacciones anidadas (definiendo árboles de
transacciones, de diferentes niveles de imbricación).
◦ Transacciones de larga duración (días, semanas).
◦ Transacciones de cooperativas (orientadas a grupos,
conversacionales, de diseño, etc. que pretenden facilitar
la coordinación del acceso a los recursos gestionados por
la BD).
© 2012 Grupo Kybele4444
Indice
1. Introducción y Motivación
2. Confidencialidad
Mecanismos de Control de Acceso a BD
SGBD Multinivel
3. Disponibilidad
Concepto de Transacción
El fichero diario (log)
Técnicas de recuperación
4. Integridad
Integridad Semántica
Integridad Operacional
5. Auditabilidad
© 2012 Grupo Kybele4545
Auditabilidad (I)
Auditoría Informática
Es un proceso que consiste en recoger, agrupar y
evaluar evidencias para determinar si un sistema de
información:
◦ Salvaguarda los activos de información de la organización.
◦ Mantiene la integridad de los datos.
◦ Utiliza eficientemente los recursos.
◦ Cumple con las leyes y regulaciones establecidas.
Auditar consiste principalmente en estudiar los
mecanismos de seguridad que están implantados en
una empresa u organización.
© 2012 Grupo Kybele4646
Auditabilidad (II)
Auditorías en BBDD
Se debe comprobar que los controles de acceso, los
sistemas de actualización, los sistemas de integridad
y la calidad de los datos son los exigidos dentro de los
requisitos de la organización.
Oracle permite auditorías selectivas de las acciones de
los usuarios para ayudar en la investigación de uso
dudoso de la BD. Se pueden realizar a tres niveles: de
sentencias, de privilegios o de objetos.
El resultado de la auditoría se almacena en una tabla
denominada rastro de la auditoría.
© 2012 Grupo Kybele4747
Bibliografía
1. TECNOLOGÍA Y DISEÑO DE BASES DE DATOS
M.Piattini, E. Marcos, C.Calero y B. Vela Ed.: RA-MA, 2006
Octubre
2. MORANT, J.L., RIBAGORDA, A. y SANCHO, J. (1994)
"Seguridad y protección de la información". Ed.
Fundación Ramón Areces, Madrid.
3. CASTANO, S., FUGINI, M., MARTELLA, G. y
SAMARATI, P. (1995) "Database Security". Addison-
Wesley, Wokingham, Inglaterra.
4. BERNSTEIN, P.A, HADZILACOS, V. y GOODMAN, N.
(1987) "Concurrency Control and Recovery in Database
Systems". Addison-Wesley, Reading, Massachusetts.