Tema 6. Restricciones a la Base de Datos: Integridad y seguridad

Transcripción

1 Tema 6. Restricciones a la Base de Datos: Integridad y seguridad Juan Ignacio Rodríguez de León Resumen Las restricciones desde el punto de vista de integridad de bases de datos. se presentan dependencias funcionales, integridad referencial y otros mecanismos para mantenimiento de integridad, tales como disparadores y afirmaciones. El objetivo es la protección de la base de datos de accidentes. Restricciones de los dominios. Integridad referencial. Asertos (asserts). Disparadores (triggers). Seguridad y autorización. Autorización en SQL. Cifrado y autenticación Índice 1. Restricciones de los dominios 3 2. Integridad referencial Integridad referencial en el modelo E-R Modificación de la base de datos Integridad referencial en SQL Asertos 6 4. Disparadores (triggers) Necesidad de los disparadores Disparadores en SQL Cuando no deben usarse disparadores Seguridad y autorización Violaciones de la seguridad Autorizaciones Autorizaciones y vistas Concesión de privilegios El concepto de papel (rol) Trazas de auditoría

2 ÍNDICE 2 6. Autorización en SQL privilegios en SQL Papeles o roles El privilegio de conceder privilegios Otras características Cifrado y autenticación Técnicas de cifrado Autenticación

3 1 RESTRICCIONES DE LOS DOMINIOS 3 En este tema se tratarán las restricciones a la base de datos. Las restricciones son limitaciones que deseamos imponer en nuestra sistema, de forma que sea imposible almacenar datos incorrectos. Algunas de las restricciones ya se han visto, por ejemplo, la limitación de los valores posibles de los atributos a un subconjunto, lo que denominábamos dominio del atributo. 1. Restricciones de los dominios Las restricciones de los dominios son la forma más simple de restricción de integridad. El sistema las verifica fácilmente siempre que se introduce en la base de datos un nuevo elemento de datos. La cláusula create domain se puede usar para definir nuevos dominios. Por ejemplo, las instrucciones: create domain Euros numeric(12,2) create domain Dólares numeric(12,2) Un intento de asignar un valor de tipo Dólares a una variable de tipo Euros resultaría en un error sintáctico, aunque ambos tengan el mismo tipo numérico. SQL también proporciona las cláusulas drop domain y alter domain para borrar o modificar dominios que se hayan declarado anteriormente. La cláusula check de SQL permite restringir aun más los dominios; permite al diseñador del esquema especificar un predicado que debe satisfacer cualquier valor para poder pertenecer al dominio. Véase, como ejemplo: create domain sueldo-por-hora numeric(5,2) constraint comprobación-valor-sueldo check (value 4.00) El dominio sueldo-por-hora tiene una restricción que asegura que el sueldo por hora sea mayor que 4,00. También puede utilizarse para restringir un dominio para que no contenga valores nulos, o se puede limitar para que contenga sólo un conjunto especificado de valores usando la cláusula in. las condiciones check permiten subconsultas que se refieren a otras relaciones. Por ejemplo, esta restricción se podría especificar sobre la relación préstamo: check (nombre-sucursal in (select nombre-sucursal from sucursal))

4 2 INTEGRIDAD REFERENCIAL 4 La condición check verifica que nombre-sucursal en cada tupla en la relación préstamo es realmente el nombre de una sucursal de la relación cuenta. Así, la condición no sólo se debe comprobar cuando se inserte o modifique préstamo, sino también cuando cambie la relación sucursal (en este caso, cuando se borre o modifique la relación cuenta). La restricción anterior es realmente un ejemplo de una clase de restricción muy habitual denominadas restricción de integridad referencial. En el Apartado 2 se estudian estas restricciones y como especificarlas en SQL. Las condiciones check complejas pueden ser útiles cuando se desee asegurar la integridad de los datos, pero se deben usar con cuidado, dado que pueden ser costosas de comprobar. 2. Integridad referencial A menudo se desea asegurar que un valor que aparece en una relación para un conjunto de atributos determinado aparezca también en otra relación para un cierto conjunto de atributos. Esta condición se denomina integridad referencial. El caso más normal es cuando queremos garantizar que el valor almacenado en una clave externa está también como clave primaria en la relación referenciada. En caso contrario, se dice que la tupla de la relación referenciante está colgante. Las tuplas colgantes pueden ser aceptables o no, dependiendo del modelo de datos. En el caso de que no sean aceptables, hay que imponer una integridad referencial o dependencia de subconjunto Integridad referencial en el modelo E-R Si se obtiene el esquema de la base de datos relacional creando tablas a partir de los diagramas E-R, cada relación que proceda de un conjunto de relaciones tendrá restricciones de integridad referencial. Otra fuente de restricciones de integridad referencial son los conjuntos de entidades débiles; el esquema de la relación de cada conjunto de entidades débiles incluye una clave externa, lo que lleva a una restricción de integridad referencial Modificación de la base de datos La modificación de la base de datos puede ocasionar violaciones de la integridad referencial. Las comprobaciones a realizar son sencilla al insertar un dato, simplemente se exige la existencia de las claves primarias relacionadas.

5 2 INTEGRIDAD REFERENCIAL 5 El borrar se da un caso más interesante. Si borramos de la tabla que contiene la clave primaria, pueden existir tuplas dependientes en otras relaciones. En ese caso, se pueden tomar tres opciones diferentes: Impedir la operación. Realizar la operación, y borrar las tuplas de las relaciones dependientes, de forma que se garanticé la consistencia de los datos. Las operaciones de borrados que se realizan en respuesta al borrado inicial se denominan borrados en cascada. Realizar la operación, y poner en la clave externa de las tuplas de las relaciones dependientes, o bien valores nulos, o bien valores predefinidos, de forma que se garantice la consistencia de los datos. Las operaciones de actualización que se realizan en respuesta al borrado inicial se denominan actualizaciones en cascada. Para las actualizaciones, hay que considerar dos casos, las actualizaciones en la tabla referenciada o maestra y las realizadas en la tabla referenciante o de detalle. Si se modifica la clave externa, en la tabla de detalles, el nuevo valor debe existir en la tabla maestra. En caso contrario, se cancela la operación. Si se modifica la clave primaria, en la tabla maestra, se debe realizar una comprobación similar a la realizada en el borrado, que puede incluir también la cancelación de la operación o la realización de actualizaciones en cascada 2.3. Integridad referencial en SQL Las claves externas pueden especificarse como parte de la instrucción create table de SQL usando la cláusula foreign key. De manera predeterminada, una clave externa referencia los atributos que forman la clave primaria de la tabla referenciada (SQL también soporta una versión de la cláusula references, donde se puede especificar explícitamente una lista de atributos de la relación referenciada). Se usa la siguiente sintaxis para declarar que un atributo forma una clave externa: foreign key (A 1 [, A 2,..., A n ]) references R Cuando se viola una restricción de integridad referencial, el procedimiento normal es rechazar la acción que provocó la violación. Sin embargo,

6 3 ASERTOS 6 la cláusula foreign key puede especificar las acciones a tomar para restaurar la integridad referencial. La cláusula on delete cascade asociada con la declaración de la clave externa, provoca que el borrado se realice en cascada. La cláusula on update cascade, de forma similar realiza una actualización en cascada, si se modifica la clave primaria. SQL también permite una acción diferente: establecer a nulo o darle un valor predeterminado a los atributos de la clave externa, de forma que se mantenga la integridad referencial, con la cláusula set default. Si hay una cadena de dependencias de claves externas entre varias relaciones, un borrado o una actualización en uno de sus extremos puede propagarse por toda la cadena, de ahí la denominación de actualizaciones o borrados en cascada. Las transacciones pueden consistir en varios pasos, y las restricciones de integridad se pueden violar temporalmente dentro de una transacción. Las restricciones de integridad se comprueban sólo al final de la transacción, no en los pasos intermedios. 3. Asertos Un aserto es un predicado que expresa una condición que se desea que la base de datos satisfaga siempre. Las restricciones de dominio y las de integridad referencial son formas especiales de los asertos. Se les ha prestado una atención especial porque se pueden verificar con facilidad y se aplican a una gran variedad de aplicaciones de bases de datos. Sin embargo, hay muchas restricciones que no se pueden expresar utilizando únicamente estas formas especiales. Ejemplos de estas restricciones pueden ser: La suma de todos los importes de los préstamos de cada sucursal debe ser menor que la suma de todos los saldos de las cuentas de esa sucursal. Cada préstamo tiene al menos un cliente que tiene una cuenta con un saldo mínimo de Euros. En SQL los asertos adoptan la forma: create assertion <nombre-aserto> check <predicado> Cuando se crea un aserto el sistema comprueba su validez. Si el aserto es válido, sólo se permiten las modificaciones posteriores de la base de datos que no hagan que se viole el aserto. Esta comprobación puede introducir una sobrecarga importante si se han realizado asertos complejos. Por tanto, los asertos deben utilizarse con precaución.

7 4 DISPARADORES (TRIGGERS) 7 4. Disparadores (triggers) Un disparador es una orden que el sistema ejecuta de manera automática como efecto secundario de la modificación de la base de datos. Para diseñar un mecanismo disparador hay que cumplir dos requisitos: Especificar las condiciones en las que se va a ejecutar el disparador. Esto se descompone en un evento que causa la comprobación del disparador y una condición que se debe cumplir para ejecutar el disparador. Especificar las acciones que se van a realizar cuando se ejecute el disparador. Este modelo de disparadores se denomina modelo evento condición acción. Una vez se almacena un disparador en la base de datos, el sistema de base de datos asume la responsabilidad de ejecutarlo cada vez que ocurra el evento especificado y se satisfaga la condición correspondiente Necesidad de los disparadores Los disparadores son mecanismos útiles para alertar a los usuarios o para realizar de manera automática ciertas tareas cuando se cumplen determinadas condiciones. Obsérvese que los sistemas de disparadores en general no pueden realizar actualizaciones fuera de la base de datos, 4.2. Disparadores en SQL Los sistemas de bases de datos SQL usan ampliamente los disparadores, aunque antes de SQL:1999 no fueron parte de la norma. Por desgracia, cada sistema de bases de datos implementó su propia sintaxis para los disparadores, conduciendo a incompatibilidades (La sintaxis SQL:1999 para los disparadores es similar a la sintaxis de los sistemas de bases de datos DB2 de IBM y de Oracle). El disparador debe especificar sobre que tabla se va a activar, y que operación lo dispara: insert, update o delete (No hay disparadores en los select porque estos no modifican los datos). Además debe indicar, cuando se va a ejecutar, antes (before) o después (after) de la operación). También se puede especificar una predicado de condición necesario para la activación del trigger, mediante la cláusula when. Para las actualizaciones, el disparador puede especificar aquellas columnas cuya actualización cause la ejecución del disparador.

8 5 SEGURIDAD Y AUTORIZACIÓN 8 El código que se ejecuta en el disparador puede necesitar los valores de los atributos antes y después de ser modificados. para ello se utilizan las cláusulas referencing new row as y referencing old row as. Los valores nuevos son accesibles en disparadores de inserción o actualización, y los valores antiguos en disparadores de actualización o borrado. Estos disparadores pueden servir como restricciones extras que pueden evitar actualizaciones no válidas. Por ejemplo, si no se desea permitir descubiertos, se puede crear un disparador before que retroceda la transacción si el nuevo saldo es negativo. En lugar de realizar una acción por cada fila afectada, se puede realizar una acción única para la instrucción SQL completa que causó la inserción, borrado o actualización. Para hacerlo se usa la cláusula for each statement en lugar de for each row. Las cláusulas referencing old table as o referencing new table as se pueden usar entonces para hacer referencia a tablas temporales (denominadas tablas de transición) conteniendo todas las filas afectadas. Las tablas de transición no se pueden usar con los disparadores before, pero sí con los after, independientemente de si son disparadores de instrucciones (statement) o de filas (row) Cuando no deben usarse disparadores No se deben usar disparadores para resolver problemas que ya tiene otro mecanismo de resolución, es decir, no se deben usar disparadores para limitar el rango de valores de un atributo (Para eso se usan los dominios), o para preservar la integridad referencial, por ejemplo. A veces se utilizan también para proporcionar datos consolidados o resumidos, obtenidos a partir de los datos reales. Si el sistema gestor lo permite, es mejor utilizar vistas materializadas. Otro uso típico que se puede evitar es el uso de disparadores para realizar copias de los datos, usando los disparadores para marcar los registros que se hayan modificador, creado o borrado desde la última copia. La mayor parte de los sistemas gestores modernos permiten realizar estas réplicas bajo el control del gestor. Por último, las bases de datos orientadas o objetos incluyen varios mecanismos de encapsulamiento que también pueden sustituir y mejorar la funcionalidad que nos pueden dar los disparadores. 5. Seguridad y autorización 5.1. Violaciones de la seguridad Existen varias formas de acceso que pueden ser mal utilizadas. Concretamente hay que impedir las operaciones de lectura no autorizada, las modificaciones no autorizadas, y la destrucción de datos no autorizada

9 5 SEGURIDAD Y AUTORIZACIÓN 9 Para proteger la base de datos hay que adoptar medidas de seguridad en varios niveles: A nivel de Base de datos, a nivel de Sistema operativo, de redes, seguridad física y por último, pero no menos importante, a nivel humano. Las dos últimas son especialmente importantes, ya que romper la seguridad a esos niveles más bajos normalmente conlleva el poder saltársela a niveles más altos. Piénsese, por ejemplo, lo que podría hacer un intruso que obtuviera, mediante engaños, el identificador de usuario y la contraseña del administrador, o con acceso físico a las máquinas y a los discos que gestionan y almacenan la base de datos Autorizaciones Un esquema de seguridad muy utilizado es el autorizaciones, que permitiría realizar (o no) determinadas operaciones sobre los datos. Por ejemplo, podemos tener una autorización para lectura, otra para inserción, otra para modificación y otro para borrado. Se le pueden asignar a un usuario todos los tipos de autorización, ninguno o una combinación de ellos. Además de estas autorizaciones, se pueden tener autorizaciones para trabajar con índices, modificar el esquema, etc... La capacidad de crear nuevas relaciones queda regulada mediante la autorización de recursos. El usuario con la autorización de recursos que crea una relación nueva recibe automáticamente todos los privilegios sobre la misma. La forma superior de autoridad es la concedida al administrador de la base de datos. El administrador de la base de datos puede autorizar usuarios nuevos, reestructurar la base de datos, etcétera. Esta forma de autorización es análoga a la proporcionada al superusuario u operador del sistema operativo Autorizaciones y vistas Como se vio en el tema 3, se pueden utilizar vistas para ocultar determinada información, que el usuario de la vista no desea o no deba ver. La creación de vistas no requiere la autorización de recursos. El usuario que crea una vista no recibe necesariamente todos los privilegios sobre la misma. Sólo recibe los privilegios que no añaden nuevas autorizaciones a las que ya posee. Por ejemplo, un usuario no puede recibir la autorización de actualización sobre una vista si no tiene la autorización de actualización sobre las relaciones utilizadas para definir la vista.

10 5 SEGURIDAD Y AUTORIZACIÓN Concesión de privilegios Un usuario al que se le ha concedido una autorización puede ser autorizado a transmitirla a otros usuarios. Sin embargo, hay que tener cuidado con el modo en que se hace, para poder asegurar que la misma pueda retirarse en el futuro. La transmisión de la autorización de un usuario a otro puede representarse mediante un grafo. Los nodos de este grafo son los usuarios. Un arco U i U j indica que el usuario U i concede una autorización a U j. La raíz de todos los grafos será el administrador de la base de datos. Un usuario tiene autorización si y sólo si hay un camino desde el administrador de la base de datos hasta el nodo que representa a ese usuario. Esto se hace así para evitar que un par de usuarios eludan las reglas de retirada de autorizaciones concediéndose autorización mutuamente El concepto de papel (rol) Los papeles o roles son una forma de simplificar la asignación de autorizaciones a los usuarios. Las autorizaciones se conceden a los papeles, de igual modo que se conceden a usuarios individuales. En la base de datos se crea un conjunto de papeles. Se concede uno o varios papeles a cada usuario de la base de datos. Una alternativa similar, pero menos preferible, sería crear un identificador de usuario cajero y permitir que cada cajero se conectase a la base de datos usando este identificador. El problema con este esquema es que no sería posible identificar exactamente al cajero que ha realizado una determinada transacción, conduciendo a problemas de seguridad Trazas de auditoría Una traza de auditoría es un registro histórico de todos los cambios (inserciones, borrados o actualizaciones) de la base de datos, junto con información sobre quién realizó el cambio y cuando. Es posible crear una traza de auditoría definiendo disparadores (usando variables definidas del sistema que identifican el nombre de usuario y la hora). Sin embargo, muchos sistemas de bases de datos proporcionan mecanismos incorporados para crear trazas de auditoría, que son más convenientes de utilizar.

11 6 AUTORIZACIÓN EN SQL Autorización en SQL 6.1. privilegios en SQL La norma SQL incluye los privilegios delete, insert, select y update. SQL también incluye un privilegio references que permite a un usuario o papel declarar claves externas al crear relaciones. Si la relación que se va a crear incluye una clave externa que hace referencia a atributos de otra relación, el usuario o papel debe haber recibido el privilegio references sobre esos atributos. El lenguaje de definición de datos de SQL incluye órdenes para conceder y retirar privilegios. La instrucción grant se utiliza para conferir autorizaciones. grant <lista de privilegios> on <nombre de relación o de lista> to <lista de usuarios/papeles> Para retirar una autorización se utiliza la instrucción revoke. Adopta una forma casi idéntica a la de grant: revoke <lista de privilegios> on <nombre de relación o de vista> from <lista de usuarios o papeles> [restrict cascade] Las autorización update e insert puede concederse sobre todos los atributos de la relación o sólo sobre algunos. la lista de atributos sobre los que se va a conceder la autorización opcionalmente aparece entre paréntesis justo después de la palabra clave update o insert. Si se omite la lista de atributos se concede sobre todos los atributos de la relación. El privilegio SQL references también se concede con grant. La siguiente instrucción grant permite al usuario U 1 crear relaciones que hagan referencia a la clave nombre-sucursal de la relación sucursal como si fuera una clave externa: grant references (nombre-sucursal) on sucursal to U 1 En un principio puede parecer que no hay ningún motivo para evitar que los usuarios creen claves externas que hagan referencia a otra relación. Sin embargo, hay que recordar que las restricciones de las claves externas pueden limitar las operaciones de borrado y de actualización sobre la relación a la que hacen referencia. El privilegio all privileges puede utilizarse como una forma abreviada de todos los privilegios que se pueden conceder. De manera parecida, el nombre de usuario public hace referencia a todos los usuarios presentes y futuros del sistema.

12 6 AUTORIZACIÓN EN SQL Papeles o roles Los papeles se pueden crear como sigue: create role cajero Se pueden conceder privilegios a los papeles al igual que a los usuarios, como se ilustra en la siguiente instrucción grant select on cuenta to cajero Los papeles se pueden asignar a los usuarios, así como a otros papeles, como muestran estas instrucciones. grant cajero to Juan create role gestor grant cajero to gestor grant gestor to maría Nótese que esto puede generar una cadena de papeles. Los privilegios efectivos consisten en todos los privilegios concedidos directamente más los concedidos indirectamente. Debido a esto, la retirada de un privilegio a un usuario o papel puede hacer que otros usuarios o papeles también lo pierdan. Este comportamiento se denomina retirada en cadena El privilegio de conceder privilegios Un usuario o papel al que se le concede un privilegio no está autorizado de manera predeterminada a concederlo. Si se desea conceder un privilegio a un usuario y permitirle que lo transmita a otros usuarios hay que añadir la cláusula with grant option a la orden grant correspondiente. Por ejemplo, si se desea conceder a U 1 el privilegio select sobre sucursal y que pueda transmitirlo a otros, hay que escribir grant select on sucursal to U 1 with grant option Otras características El creador de un objeto (relación, vista o papel) obtiene todos los privilegios sobre el objeto, incluyendo el privilegio de conceder privilegios a otros.

13 7 CIFRADO Y AUTENTICACIÓN Cifrado y autenticación Para información extremadamente reservada es necesario cifrar los datos. Los datos cifrados no se pueden leer a menos que el lector sepa la manera de descifrarlos. El cifrado también forma la base de los buenos esquemas para la autenticación de usuarios en una base de datos Técnicas de cifrado Una buena técnica de cifrado tiene las propiedades siguientes: Es relativamente sencillo para los usuarios autorizados cifrar y descifrar los datos. El esquema de cifrado no depende de lo poco conocido que sea el algoritmo, sino más bien de un parámetro del algoritmo denominado clave de cifrado. Es extremadamente difícil para un intruso determinar la clave de cifrado. Los esquemas como DES, TripleDES o Rijndael son esquemas de cifrado simétricos (Se usa la misma clave para cifrar que para descifrar). Para que este esquema funcione los usuarios autorizados deben proveerse de la clave de cifrado mediante un mecanismo seguro, por lo que el esquema es tan seguro como lo sea este mecanismo. Los cifrados de clave pública utilizan claves distintas para el cifrado y para el descifrado, por lo que puede evitar en parte el problema de la distribución de la clave. Cada usuario U i tiene una clave pública C i y una clave privada D i. Las claves públicas, como su nombre indica, son de dominio público: cualquiera puede verlas. La clave privada, por el contrario, sólo es conocida por el usuario al que pertenece. Si el usuario U 1 desea guardar datos cifrados, los cifra utilizando su clave pública C 1. Descifrarlos requiere la clave privada D 1 (Que sólo el conoce). Como la clave de cifrado de cada usuario es pública es posible intercambiar información de manera segura. Si el usuario U 1 desea compartir los datos con U 2 los codifica utilizando C 2, la clave pública de U 2. Dado que sólo U 2 conoce la manera de descifrar los datos, la información se transmite de manera segura. Para que el cifrado de clave pública funcione debe haber un esquema de cifrado que pueda hacerse público sin permitir a la gente descubrir el esquema de descifrado. En otros términos, debe ser difícil deducir la clave privada dada la clave pública.

14 7 CIFRADO Y AUTENTICACIÓN 14 Pese a que el cifrado de clave pública es seguro, también es costoso en cuanto a cálculo. Se suele utilizar un esquema híbrido para la comunicación segura: Se establece una clave de sesión, utilizando cifrado simétrico, por ejemplo DES. las claves se trasmite mediante un cifrado de clave pública y posteriormente se utiliza el cifrado DES para los datos transmitidos Autenticación La autenticación se refiere a la tarea de verificar la identidad de una persona o software que se conecte a una base de datos. La forma más simple consiste en una contraseña o password que se debe presentar cuando se abra una conexión a la base de datos. Sin embargo, el uso de contraseñas tiene algunos inconvenientes, especialmente en una red. Un esquema más seguro es el sistema de desafío/respuesta. El sistema de bases de datos envía una cadena de desafío al usuario. El usuario cifra la cadena de desafío usando una contraseña secreta como clave de cifrado y devuelve el resultado. El sistema de bases de datos puede verificar la autenticidad del usuario descifrando la cadena, y comparando el resultado con la cadena de desafío original. La ventaja de este sistema es que las contraseñas no circulen por la red. Los sistemas de clave pública también se pueden usar para cifrar en un sistema de desafío/respuesta. se cifra la cadena de desafío usando la clave pública del usuario y se le envía al usuario. Éste descifra la cadena con su clave privada y devuelve el resultado al sistema de bases de datos. El sistema de bases de datos comprueba entonces la respuesta. Este esquema tiene la ventaja añadida de no almacenar la contraseña en la base de datos.