Bases de Datos Conferencia 13 Temas Avanzados de Seguridad en Bases de Datos. Control de la Protección y la Concurrencia.

Seguridad en Bases de Datos Introducción a la seguridad Confidencialidad Disponibilidad Integridad

Aspectos fundamentales de la seguridad en BD Confidencialidad. No mostrar datos a usuarios no autorizados. Comprende también la privacidad (protección de datos personales). Accesibilidad. La información debe estar disponible. Integridad. Permite asegurar que los datos no han sido falseados.

Necesidad de seguridad en BD Cuestiones éticas y legales relativas al derecho a tener acceso a cierta información. Cuestiones de política en el nivel gubernamental, institucional o corporativo relacionadas con la información que no debe estar disponible para el público. Cuestiones relacionadas con el sistema. Necesidad en algunas organizaciones de identificar múltiples niveles de seguridad y de clasificar los datos y los usuarios según estos niveles.

Seguridad de los SGBD Los SGBD cuentan con un subsistema de seguridad. Seguridad Integrada al S.O Seguridad Estándar SQL El SGBD debe proveer técnicas que permitan a ciertos usuarios tener acceso a porciones selectas de una base de datos sin tener acceso al resto. Un SGBD cuenta con un subsistema de seguridad de autorización de la BD que se encarga de garantizar la seguridad de porciones de la base de datos contra el acceso no autorizado.

Mecanismos de Seguridad Discrecionales: Se usan para otorgar privilegios a los usuarios. Obligatorios: Sirven para imponer seguridad de múltiples niveles clasificando los datos y los usuarios en varias clases de seguridad e implementando después la política de seguridad apropiada de la organización.

Garantizando la seguridad Obligaciones del diseñador de BD Creación de cuentas Concesión de privilegios Revocación de privilegios Asignación de niveles de seguridad Autorizaciones Discrecionales Autorización Obligatoria

Amenazas a la seguridad de las BD Hardware Falta de corriente Interferencias eléctricas Daños físicos SGBD y Software de aplicación Alteración de programas Robos de programas Fallos de los mecanismos de seguridad Redes de comunicación Ruptura de conexiones Problemas con el cableado Bases de Datos Copias de datos no autorizadas Robo de datos Datos corruptos por cortes eléctricos Usuarios Entrar con la cuenta ajena Virus Hackers Programadores - Operadores Políticas y procedimientos de seguridad inadecuados Software inseguro Administradores de BD

Confidencialidad

Controlar el acceso a los datos Identificación y autenticación de usuarios Código y contraseña Identificación por hardware Características bioantropométricas (huellas dactilares, voz, retina del ojo) Conocimientos, aptitudes y hábitos del usuario Información predefinida En un SGBD existen diversos elementos que ayudan a controlar el acceso a los datos. En primer lugar el sistema debe identificar y autenticar a los usuarios utilizando alguno de las siguientes formas.

Controlar el acceso a los datos Privilegios de cada usuario sobre los objetos de la base de datos Acceder a una base de datos Consultar determinados datos Actualizar datos …

Confidencialidad Para facilitar la administración los SGBD suelen incorporar el concepto de perfil, rol o grupo de usuarios que agrupa una serie de privilegios por lo que el usuario que se asigna a un grupo hereda todos los privilegios del grupo. El mecanismo de control de acceso se encarga de denegar o conceder el acceso a los usuarios.

Tipos de Autorización Autorización explícita. Normalmente usada en los sistemas tradicionales. Consiste en almacenar qué sujetos pueden acceder a ciertos objetos con determinados privilegios. Autorización implícita. Consiste en que una autorización definida sobre un objeto puede deducirse a partir de otras.

Tipos de Autorización Autorización fuerte: Las autorizaciones deducidas a partir de la misma no pueden ser invalidadas. Autorización débil: Se permiten excepciones sobre las autorizaciones implícitas.

Tipos de Autorización Autorización positiva: Indica la existencia de autorización a ciertos objetos de la base de datos. Autorización negativa: Es la denegación explícita de una autorización.

Aspectos relacionados con los tipos de autorización La política de control elegida. Pudiendo el SGBD operar como uno de los siguientes sistemas. Sistema abierto (en el que un usuario puede acceder a todos los objetos excepto a aquellos que se prohíben explícitamente) Sistema cerrado (el usuario accede sólo a aquellos objetos para los que tiene autorización previa) El modelo de datos

Confidencialidad en SQL Niveles de privilegios Nivel de cuenta en el que el administrador de bases de datos especifica los privilegios particulares que tiene cada usuario, independientemente de las relaciones de la base de datos. Nivel de relación en el que podemos controlar el privilegio para tener acceso a cada relación o vista individual de la base de datos

Confidencialidad en SQL Nivel de cuenta CREATE SCHEMA CREATE TABLE CREATE VIEW ALTER DROP MODIFY SELECT Nivel de relación SELECT MODIFY REFERENCES

Ejemplo. Conceder privilegios. < sentencia de concesión> GRANT <privilegios> ON <nombre de objeto> TO <concedido> [<coma><concedido>...] [WITH GRANT OPTION] <lista de acción> SELECT | DELETE | INSERT [<parent. izq.><lista de columnas><parent. derecha>] | UPDATE [<parent. izq.><lista de columnas><parent. derecha>] | REFERENCES [<parent. izq.><lista columnas><parent. derecha>] | USAGE

Ejemplo. Revocar privilegios. <sentencia de revocación> REVOKE [GRANT OPTION FOR] <privilegios> ON <nombre de objeto> FROM <concedido> [{<coma><concedido>...}] <comportamiento de borrado> CASCADE | RESTRICT RESTRICT no dejará revocar privilegios que hayan sido concedidos a otros usuarios, mientras que si se emplea la opción en cascada, se borrarán todos los privilegios.

Disponibilidad

Disponibilidad Los sistemas de bases de datos deben asegurar la disponibilidad de los datos a aquellos usuarios que tienen derecho, por lo que proporcionan mecanismos que permiten recuperar la base de datos contra fallos lógicos o físicos que destruyan todos los datos o parte de ellos

Transacción Unidades de ejecución que pueden definirse como secuencias de operaciones que han de ejecutarse de forma atómica, es decir, o bien se realizan todas las operaciones que comprenden la transacción globalmente o bien no se realiza ninguna

Propiedades de las transacciones Atomicidad Preservación de la consistencia Aislamiento. Una transacción no muestra los cambios que se producen hasta que se finaliza. Persistencia. Una vez que la transacción finaliza con éxito sus efectos perduran en la BD

Estado de las transacciones Exitosas. Las operaciones que incluye la transacción se ejecutan completamente en la base de datos (COMMIT) Fallidas. En cuyo caso debe ser restaurado el estado inicial de la BD antes de que se ejecutara la transacción. Las operaciones incluidas en la transacción deben deshacerse (ROLLBACK)

Transacciones Los principales componentes del SGBD que se encargan de la gestión y recuperación de las transacciones Gestor de Transacciones Planificador Gestor de Recuperación Gestor de Memoria Intermedia Estable Volátil BD LOG Datos de la BD Datos de Recup.

Recuperación de la BD Recuperación en caliente. El sistema consulta el fichero diario para determinar las transacciones que hay que deshacer pues no han sido completadas y las que hay que rehacer. Recuperación en frío. Consiste en utilizar una copia de seguridad de la base de datos, también llamada de respaldo (backup)

Disponibilidad en SQL COMMIT ROLLBACK Las transacciones se inician al ejecutar sentencias del lenguaje de definición de datos o del lenguaje de manipulación de datos.

Ejemplos DECLARE @TranName VARCHAR(20) SELECT @TranName = 'MyTransaction' BEGIN TRANSACTION @TranName GO USE pubs GO UPDATE roysched SET royalty = royalty * 1.10 WHERE title_id LIKE 'Pc%' COMMIT TRANSACTION MyTransaction La sentencia ejecutarse está programada transaccionalmente

Integridad

Integridad Proteger a la BD contra operaciones que introducen inconsistencias en 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.

Integridad semántica Violación de restricciones definidas al diseñar la BD como pueden ser restricciones sobre los dominios o los atributos. El SGBD debe ofrecer en su lenguaje de definición facilidades que permitan describir las restricciones. (declaración de índices y constrains visualmente)

Integridad operacional En sistemas multiusuario es imprescindible, además, un mecanismo de control de concurrencia para conservar la integridad de la base de datos, ya que se pueden producir importantes inconsistencias derivadas del acceso concurrente.

¿Concurrentes?

Necesidad del control de la concurrencia Para cada vuelo se incluye un registro que, entre otros datos almacena el número de asientos reservados. Se trabaja con dos transacciones de ejemplo: - T1 cancela N reservas desde un vuelo que tiene X asientos reservados y las cambia a otro vuelo que tiene Y asientos reservados - T2 reserva M asientos adicionales a los X ya reservados en el primer vuelo.

Representando las transacciones Leer_item(X); X := X-N; Escribir_item(X); Leer_item(Y); Y := Y+N; Escribir_item(Y); T2 X := X+M;

Modificación perdida Ocurre cuando dos transacciones que acceden a los mismos items tienen sus operaciones intercaladas de tal forma que ponen el valor de algún ítem incorrectamente.

Modificación perdida T1 y T2 comienzan aproximadamente al mismo tiempo, y sus operaciones están intercaladas, el valor final del ítem X será incorrecto porque T2 lee el valor de X antes de que T1 lo cambie en la BD, y el valor modificado resultante de T1 se pierde.

Modificación perdida

Modificación temporal Esta situación ocurre cuando una transacción modifica un ítem y a continuación la transacción falla por alguna razón. El ítem modificado es accedido por otra transacción antes de que el cambio sea desecho y el ítem vuelva a su valor original. Por ejemplo, T2 lee un valor de X cambiado por T1, y posteriormente T1 falla, por lo que el valor leído por T2 es incorrecto.

Modificación temporal

Totalización incorrecta Este problema se produce si una transacción está calculando una función de totalización agregada sobre varios registros mientras otra transacción está modificando algunos de estos registros. La función agregada puede calcular algunos valores antes de que sean modificados y otros después.

Totalización incorrecta Por ejemplo, una transacción T3 que está calculando el número total de reservas en todos los vuelos; mientras tanto, la transacción T1 se está ejecutando. Si las operaciones están intercaladas el resultado de T3 tendrá un déficit en una cantidad N porque T3 lee el valor de X después de que N asientos le sean sustraídos y lee el valor de Y antes de que los N asientos le sean adicionados.

Totalización incorrecta

Lectura no repetible Ocurre cuando una transacción T1 lee un ítem de datos dos veces y otra transacción T2 modifica dicho ítem entre las dos lecturas. Por tanto, T1 recibe dos valores diferentes del mismo ítem en sus lecturas.

Transacciones

Necesidad de la recuperación Cuando una transacción es remitida a un SGBD para su ejecución, el sistema es responsable de asegurar que ocurra una de las dos situaciones siguientes: Todas las operaciones de la transacción son completadas y su efecto es registrado permanentemente en la BD. La transacción no tiene ningún efecto en la BD o en alguna otra transacción.

Tipos de fallos en transacciones Fallo del sistema: Un error hardware o software ocurre en el sistema durante la ejecución de la transacción. Si el fallo es de hardware, los contenidos de la memoria interna pueden perderse. Un error de sistema en la transacción: Algunas operaciones en las transacciones pueden causar su fallo, por ejemplo, una división por cero. Fallos en la transacción pueden ocurrir también por valores de parámetros erróneos, error lógico del programa, o incluso, porque el usuario interrumpe la transacción

Tipos de fallos en transacciones Errores locales o condiciones de excepción detectados por la transacción: Durante la ejecución de una transacción, ciertas condiciones pueden obligar a cancelar la transacción. Por ejemplo, un saldo insuficiente en una retirada de fondos de una cuenta bancaria. Estas cancelaciones pueden realizarse por programación con una orden ABORT ó ROLLBACK dentro de la propia transacción

Tipos de fallos en transacciones Imposiciones del control de concurrencia: Los métodos de control de concurrencia pueden decidir abortar una transacción, para ser restaurada después. Fallo de disco: Algunos bloques de disco pueden perder sus datos por un mal funcionamiento de los procesos de lectura y/o escritura física.

Estados de una transacción BEGIN: Esta operación marca el comienzo de la ejecución de la transacción. READ ó WRITE: Especifican operaciones de lectura y/o escritura de ítems que son ejecutados como parte de una transacción. END: Indica que las operaciones de lectura y escritura de la transacción han concluido y marca el fin de la ejecución de la transacción. En este punto es necesario chequear si los cambios realizados por la transacción pueden ser aplicados permanentemente a la BD (COMMIT) o si la transacción ha sido abortada.

Estados de una transacción COMMIT: Señala un final adecuado de la transacción y que cualquier modificación de ítems ejecutada por la transacción puede ser transferida definitivamente a la BD y no será desecha. ROLLBACK (ABORT): Indica que la transacción ha concluido de forma inadecuada y por tanto, cualquier cambio o efecto que la transacción haya podido tener sobre la BD debe ser desecho.

Transición de estados de una transacción

Fichero de bitácora Contiene los datos de todas las operaciones de las transacciones que afectan a valores de los ítems de la BD Necesario para recuperar desde transacciones fallidas Las entradas de este fichero tienen una estructura bien definida

Entradas del fichero de bitácora [start_transaction, T]: La transacción T (identificador generado por el sistema que identifica unívocamente a cada transacción) comienza su ejecución. [write_ítem, T, X, valor_viejo, valor_nuevo]: La transacción T cambia el valor del ítem X de valor_viejo a valor_nuevo.

Entradas del fichero de bitácora [read_ítem, T, X]: La transacción T lee el valor del ítem X. [commit, T]: La transacción T ha completado todos sus accesos a la BD, y sus efectos pueden ser confirmados (registrados permanentemente en la BD)

Punto de confirmación [commit, T]: La transacción T ha completado todos sus accesos a la BD, y sus efectos pueden ser confirmados (registrados permanentemente en la BD) Si ocurre un fallo del sistema, se busca hacia atrás en la bitácora para encontrar todas las transacciones que han escrito un registro [start_transaction, T] pero no tienen el registro [commit, T] todavía. Estas transacciones tienen que ser deshechas (rollback) para deshacer sus efectos en la BD.

Puntos de control Un punto de control es registrado en la bitácora periódicamente en el momento en que el sistema ha registrado en la BD los efectos de todas las operaciones de escritura de las transacciones confirmadas. Todas las transacciones que tienen su registro [commit, T] en la bitácora antes de un registro [checkpoint], no requerirán que sus operaciones de escritura sean rehechas en caso de un fallo del sistema.

Planificación de Transacciones Dos usuarios solicitan al SGBD la ejecución de las transacciones T1 y T2, ambas aproximadamente al mismo tiempo. Si no se permite intercalado, sólo son posibles dos ordenamientos de las operaciones de las transacciones: 1. Ejecutar todas las operaciones de T1 seguidas por todas las operaciones de T2. 2. Ejecutar todas las operaciones de T2 seguidas por todas las operaciones de T1.

Planes seriales con T1 y T2

Serializabilidad de planes Planes seriales. Las operaciones de cada transacción son ejecutadas sin ninguna operación de otra transacción intercalada. Planes no seriales. Las transacciones no son realizadas secuencialmente sin intercalaciones Planes serializables Estudio Independiente + Equivalencia de planes

Planes no seriales

Control de concurrencia

Control de concurrencia Técnicas de Bloqueo Bloqueo (locking) de los ítems de datos para prevenir que múltiples transacciones accedan a los ítems concurrentemente. Marcas de tiempo (timestamp) que identifican unívocamente a cada transacción. Estas marcas son generadas por el sistema, de forma que las transacciones pueden ser ordenadas según sus marcas para asegurar la serializabilidad.

Tipos de bloqueo Bloqueos binarios Bloqueos compartidos y exclusivos Bloqueos en dos fases Bloqueo mortal Bloqueo activo

Bloqueo binario Dos posibles estados o valores valor = 1 Bloqueado valor = 0 Desbloqueado Se asocia a cada ítem un bloque diferente Si el ítem está bloqueado no puede ser accedido por operaciones de la BD El valor de bloque de un ítem X se representa Lock(X)

Bloquear un ítem X Bloquear_ítem(X): B: Si Lock(X)=0 entonces {ítem desbloqueado} Lock(X) <- 1 {bloquear el ítem} Sino Esperar_que(Lock(X)=0 y el gestor de bloqueos levante la transacción) Ir a B Fin Si

Desbloquear un ítem X Desbloquear_ítem(X): Lock(X) <- 0 {desbloquear el ítem} Si hay transacciones esperando entonces Levantar una de ellas Fin_Si

Reglas del bloqueo binario Una transacción T debe realizar una operación Bloquear_ítem(X) antes que un Leer_Ítem(X) o Escribir_ítem(X). Una transacción T debe realizar una operación Desbloquear_ítem(X) después de que todos los Leer_ítem(X) y Escribir_ítem(X) en T se hayan completado. Una transacción T no realizará un Bloquear_ítem(X) si ya posee el bloqueo de X. Una transacción T no realizará un Desbloquear_ítem(X) salvo que posea el bloquea de X.

Bloqueo binario Bloquear_ítem(X) y Desbloquear_ítem(X) en la transacción T, equivale a decir que T posee el bloqueo de X. Sólo una transacción puede poseer el bloqueo de X en cada momento No pueden existir dos transacciones accediendo al mismo ítem concurrentemente

Bloque binario Las transacciones pueden ser procesadas concurrentemente si acceden a diferentes ítems de la BD. Restrictivo, pues sería mejor permitir que varias transacciones pudieran acceder al mismo ítem X si todas ellas lo requieren sólo con propósitos de lectura.

Bloqueos compartidos y exclusivos Bloquear ítem para lectura Bloquear ítem para escritura Desbloquear ítem

Bloqueos compartidos y exclusivos Un ítem bloqueado para lectura se dice que tiene un bloqueo compartido porque otras transacciones también pueden leer el ítem. Un ítem bloqueado para escritura se diceque tiene un bloqueo exclusivo porque una única transacción posee exclusivamente el bloqueo del ítem.

Bloquear para lectura Bloquear_para_lectura(X): B: Si Lock(X)='desbloqueado' entonces Lock(X) <- 'bloqueado-para-lectura' Nº_lecturas(X) <- 1 Sino Si Lock(X)='bloqueado-para-lectura' entonces Nº_lecturas(X) <- Nº_lecturas(X)+1 Esperar_que(Lock(X)='desbloqueado' y el gestor de bloqueos levante la transacción) Ir_a B Fin_Si

Bloquear para escritura Bloquear_para_escritura(X): B: Si Lock(X)='desbloqueado' entonces Lock(X) <- 'bloqueado-para-escritura' Sino Esperar_que(Lock(X)='desbloqueado' y el gestor de bloqueos levante la transacción) Ir_a B Fin_Si

Desbloquear ítem Si Lock(X)='bloqueado-para-escritura' entonces Lock(X) <- 'desbloqueado' Si hay transacciones esperando entonces levantar una de ellas Sino Si Lock(X)='bloqueado-para-lectura' entonces Nº_lecturas(X) <- Nº_lecturas(X)-1 Si Nº_lecturas(X)=0 entonces Si hay transacciones esperando entonces levantar una de ellas Fin_Si

Reglas bloqueos modo múltiple Una transacción debe ejecutar la operación Bloquear_para_Lectura(X) o Bloquear_para_Escritura(X) antes de Leer_Item(X) en T. Una transacción T debe realizar la operación Bloquear_para_escritura(X) antes de cualquier Escribir_Item(X) en T

Reglas bloqueos modo múltiple Una transacción T debe usar la operación Desbloquear_ítem(X) después de todas las operaciones Leer_ítem(X) y Escribir_ítem(X) en T. Una transacción T no debe usar una operación Bloquear_para_lectura(X) si ya posee un bloqueo compartido o exclusivo sobre el ítem X

Reglas bloqueos modo múltiple Una transacción T no debe usar una operación Bloquear_para-escritura(X) si ya posee un bloqueo compartido o exclusivo sobre el ítem X. Una transacción T no debe usar una operación Desbloquear(X) a menos que posea un bloqueo compartido o exclusivo sobre el ítem X

Estudio Independiente Para el seminario investigar Características de los bloqueos en dos fases Bloqueo mortal Bloqueo activo

Marcas de tiempo Una marca de tiempo es un identificador único creado por el SGBD para identificar una transacción. Los valores de las marcas de tiempo se asignan por el orden en el cual las transacciones son remitidas al sistema, de forma que una marca de tiempo puede ser considerada como el momento de inicio de una transacción. Marca de tiempo de la transacción T se representa TS(T).

Ordenación por marcas de tiempo 1. TS_lectura(X): Marca de tiempo de lectura del ítem X. Es la mayor entre todas las marcas de tiempo de las transacciones que sucesivamente han leído el ítem X. 2. TS_escritura(X): Marca de tiempo de escritura de X. Es la mayor entre todas las marcas de tiempo de las transacciones que sucesivamente han escrito el ítem X.

Control basado en timestamps La transacción T intenta una operación Escribir_ítem(X) La transacción T intenta una operación Leer_ítem(X)

Granularidad de los ítems de datos Una tupla de la base de datos Un valor de un campo (atributo) de una tupla Un bloque de disco Un fichero completo Toda la base de datos

Estudio Independiente Técnicas de recuperación de información Modificación diferida Modificación inmediata Copias de seguridad Realizar los ejercicios del Seminario No. 2

Conclusiones Importancia de la seguridad de las bases de datos Confidencialidad Disponibilidad Integridad Control de concurrencia Transacciones Protocolos para el control de la concurrencia Bloqueos Marcas de tiempo