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

Tema 6. Restricciones a la Base de Datos:

Integridad y seguridad

Juan Ignacio Rodr´ıguez de Le ´on

Resumen

Las restricciones desde el punto de vista de integridad de bases de datos. se presentan dependencias funcionales, integridad refer-encial y otros mecanismos para mantenimiento de integridad, tales como disparadores y afirmaciones. El objetivo es la protecci ´on de la base de datos de accidentes. Restricciones de los dominios. Integri-dad referencial. Asertos (asserts). Disparadores (triggers). SeguriIntegri-dad y autorizaci ´on. Autorizaci ´on en SQL. Cifrado y autenticaci ´on

´Indice

1. Restricciones de los dominios 3

2. Integridad referencial 4

2.1. Integridad referencial en el modelo E-R . . . 4

2.2. Modificaci ´on de la base de datos . . . 4

2.3. Integridad referencial en SQL . . . 5

3. Asertos 6 4. Disparadores (triggers) 7 4.1. Necesidad de los disparadores . . . 7

4.2. Disparadores en SQL . . . 7

4.3. Cuando no deben usarse disparadores . . . 8

5. Seguridad y autorizaci ´on 8 5.1. Violaciones de la seguridad . . . 8

5.2. Autorizaciones . . . 9

5.3. Autorizaciones y vistas . . . 9

5.4. Concesi ´on de privilegios . . . 10

5.5. El concepto de papel (rol) . . . 10

5.6. Trazas de auditor´ıa . . . 10

´INDICE 2

6. Autorizaci ´on en SQL 11

6.1. privilegios en SQL . . . 11

6.1.1. Papeles o roles . . . 12

6.1.2. El privilegio de conceder privilegios . . . 12

6.1.3. Otras caracter´ısticas . . . 12

7. Cifrado y autenticaci ´on 13 7.1. T´ecnicas de cifrado . . . 13

1 RESTRICCIONES DE LOS DOMINIOS 3

En este tema se tratar´an las restricciones a la base de datos. Las restric-ciones son limitarestric-ciones 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 ´on de los valores posibles de los atributos a un subconjunto, lo que denomin´abamos

dominiodel atributo.

1.

Restricciones de los dominios

Las restricciones de los dominios son la forma m´as simple de restricci ´on de integridad. El sistema las verifica f´acilmente siempre que se introduce en la base de datos un nuevo elemento de datos.

La cl´ausulacreate domainse puede usar para definir nuevos dominios. Por ejemplo, las instrucciones:

create domainEurosnumeric(12,2) create domainD ´olaresnumeric(12,2)

Un intento de asignar un valor de tipo D´olaresa una variable de tipo

Eurosresultar´ıa en un error sint´actico, aunque ambos tengan el mismo tipo

num´erico.

SQL tambi´en proporciona las cl´ausulasdrop domainyalter domainpara borrar o modificar dominios que se hayan declarado anteriormente.

La cl´ausulacheckde SQL permite restringir aun m´as los dominios; per-mite al dise ˜nador del esquema especificar un predicado que debe satisfacer cualquier valor para poder pertenecer al dominio. V´ease, como ejemplo: create domainsueldo-por-horanumeric(5,2)

constraintcomprobaci ´on-valor-sueldo check(value≥_4.00)

El dominio sueldo-por-hora tiene una restricci ´on que asegura que el sueldo por hora sea mayor que 4,00.

Tambi´en puede utilizarse para restringir un dominio para que no con-tenga valores nulos, o se puede limitar para que concon-tenga s ´olo un conjunto especificado de valores usando la cl´ausulain.

las condicionescheckpermiten subconsultas que se refieren a otras rela-ciones. Por ejemplo, esta restricci ´on se podr´ıa especificar sobre la relaci ´on pr´estamo:

check(nombre-sucursalin

2 INTEGRIDAD REFERENCIAL 4

La condici ´on check verifica que nombre-sucursal en cada tupla en la relaci ´on pr´estamo es realmente el nombre de una sucursal de la relaci ´on cuenta. As´ı, la condici ´on no s ´olo se debe comprobar cuando se inserte o modifique pr´estamo, sino tambi´en cuando cambie la relaci ´on sucursal (en este caso, cuando se borre o modifique la relaci ´on cuenta).

La restricci ´on anterior es realmente un ejemplo de una clase de restric-ci ´on muy habitual denominadas restricrestric-ci ´on de integridad referenrestric-cial. En el Apartado 2 se estudian estas restricciones y como especificarlas en SQL.

Las condiciones check complejas pueden ser ´utiles 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 ´on para un conjunto de atributos determinado aparezca tambi´en en otra relaci ´on para un cierto conjunto de atributos. Esta condici ´on se denomina integridad referencial.

El caso m´as normal es cuando queremos garantizar que el valor al-macenado en una clave externa est´a tambi´en como clave primaria en la relaci ´on referenciada. En caso contrario, se dice que la tupla de la relaci ´on referenciante est´acolgante.

Las tuplas colgantes pueden ser aceptables o no, dependiendo del mod-elo de datos. En el caso de que no sean aceptables, hay que imponer una

integridad referencialodependencia de subconjunto.

2.1. 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 ´on que proceda de un conjunto de relaciones tendr´a restricciones de integridad referencial.

Otra fuente de restricciones de integridad referencial son los conjuntos de entidades d´ebiles; el esquema de la relaci ´on de cada conjunto de enti-dades d´ebiles incluye una clave externa, lo que lleva a una restricci ´on de integridad referencial.

2.2. Modificaci ´on de la base de datos

La modificaci ´on de la base de datos puede ocasionar violaciones de la integridad referencial. Las comprobaciones a realizar son sencilla al in-sertar un dato, simplemente se exige la existencia de las claves primarias relacionadas.

2 INTEGRIDAD REFERENCIAL 5

El borrar se da un caso m´as 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 ´on.

Realizar la operaci ´on, y borrar las tuplas de las relaciones dependi-entes, de forma que se garantic´e la consistencia de los datos. Las op-eraciones de borrados que se realizan en respuesta al borrado inicial se denominanborrados en cascada.

Realizar la operaci ´on, y poner en la clave externa de las tuplas de las relaciones dependientes, o bien valores nulos, o bien valores pre-definidos, de forma que se garantice la consistencia de los datos. Las operaciones de actualizaci ´on que se realizan en respuesta al borrado inicial se denominanactualizaciones en cascada.

Para las actualizaciones, hay que considerar dos casos, las actualiza-ciones en la tabla referenciada o maestra y las realizadas en la tabla referen-ciante o de detalle.

Si se modifica la clave externa, en la tabla de detalles, el nuevo val-or debe existir en la tabla maestra. En caso contrario, se cancela la operaci ´on.

Si se modifica la clave primaria, en la tabla maestra, se debe realizar una comprobaci ´on similar a la realizada en el borrado, que puede incluir tambi´en la cancelaci ´on de la operaci ´on o la realizaci ´on de actualizaciones en cascada

2.3. Integridad referencial en SQL

Las claves externas pueden especificarse como parte de la instrucci ´on create table de SQL usando la cl´ausulaforeign key.

De manera predeterminada, una clave externa referencia los atributos que forman la clave primaria de la tabla referenciada (SQL tambi´en so-porta una versi ´on de la cl´ausula references, donde se puede especificar expl´ıcitamente una lista de atributos de la relaci ´on referenciada).

Se usa la siguiente sintaxis para declarar que un atributo forma una clave externa:

foreign key(A1[,A2, . . . ,An]) referencesR

Cuando se viola una restricci ´on de integridad referencial, el proced-imiento normal es rechazar la acci ´on que provoc ´o la violaci ´on. Sin embargo,

3 ASERTOS 6

la cl´ausulaforeign keypuede especificar las acciones a tomar para restaurar la integridad referencial.

La cl´ausula on delete cascadeasociada con la declaraci ´on de la clave externa, provoca que el borrado se realice en cascada. La cl´ausulaon up-date cascade, de forma similar realiza una actualizaci ´on en cascada, si se modifica la clave primaria.

SQL tambi´en permite una acci ´on 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´ausulaset default.

Si hay una cadena de dependencias de claves externas entre varias relaciones, un borrado o una actualizaci ´on en uno de sus extremos puede propagarse por toda la cadena, de ah´ı la denominaci ´on 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 ´on. Las restricciones de integridad se comprueban s ´olo al final de la transacci ´on, no en los pasos intermedios.

3.

Asertos

Un aserto es un predicado que expresa una condici ´on 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 ´on especial porque se pueden verificar con facilidad y se aplican a una gran variedad de aplica-ciones de bases de datos. Sin embargo, hay muchas restricaplica-ciones que no se pueden expresar utilizando ´unicamente estas formas especiales. Ejemplos de estas restricciones pueden ser:

La suma de todos los importes de los pr´estamos de cada sucursal debe ser menor que la suma de todos los saldos de las cuentas de esa sucursal.

Cada pr´estamo tiene al menos un cliente que tiene una cuenta con un saldo m´ınimo de 1.000 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´alido, s ´olo se permiten las modificaciones posteriores de la base de datos que no hagan que se viole el aserto.

Esta comprobaci ´on puede introducir una sobrecarga importante si se han realizado asertos complejos. Por tanto, los asertos deben utilizarse con precauci ´on.

4 DISPARADORES (TRIGGERS) 7

4.

Disparadores (triggers)

Un disparador es una orden que el sistema ejecuta de manera autom´atica como efecto secundario de la modificaci ´on de la base de datos.

Para dise ˜nar 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 ´on del disparador y una condici ´on que se debe cumplir para ejecutar el dis-parador.

Especificar las acciones que se van a realizar cuando se ejecute el disparador.

Este modelo de disparadores se denomina modelo evento–condici ´on– acci ´on.

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 ´on correspondiente.

4.1. Necesidad de los disparadores

Los disparadores son mecanismos ´utiles para alertar a los usuarios o para realizar de manera autom´atica ciertas tareas cuando se cumplen de-terminadas condiciones.

Obs´ervese que los sistemas de disparadores en general no pueden re-alizar 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 ´o 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 ´on lo dispara:insert,updateodelete(No hay disparadores en los select porque estos no modifican los datos). Adem´as debe indicar,cuando se va a ejecutar, antes (before) o despu´es (after) de la operaci ´on). Tambi´en se puede especificar una predicado de condici ´on necesario para la acti-vaci ´on del trigger, mediante la cl´ausulawhen. Para las actualizaciones, el disparador puede especificar aquellas columnas cuya actualizaci ´on cause la ejecuci ´on del disparador.

5 SEGURIDAD Y AUTORIZACI ´ON 8

El c ´odigo que se ejecuta en el disparador puede necesitar los valores de los atributos antes y despu´es de ser modificados. para ello se utilizan las cl´ausulasreferencing new row asyreferencing old row as. Los valores nuevos son accesibles en disparadores de inserci ´on o actualizaci ´on, y los valores antiguos en disparadores de actualizaci ´on o borrado.

Estos disparadores pueden servir como restricciones extras que pueden evitar actualizaciones no v´alidas. Por ejemplo, si no se desea permitir des-cubiertos, se puede crear un disparadorbeforeque retroceda la transacci ´on si el nuevo saldo es negativo.

En lugar de realizar una acci ´on por cada fila afectada, se puede realizar una acci ´on ´unica para la instrucci ´on SQL completa que caus ´o la inserci ´on, borrado o actualizaci ´on. Para hacerlo se usa la cl´ausulafor each statement en lugar defor each row. Las cl´ausulasreferencing old table aso referenc-ing new table as se pueden usar entonces para hacer referencia a tablas temporales (denominadas tablas de transici´on) conteniendo todas las filas afectadas. Las tablas de transici ´on 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).

4.3. Cuando no deben usarse disparadores

No se deben usar disparadores para resolver problemas que ya tiene otro mecanismo de resoluci ´on, 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´en 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 re-alizar copias de los datos, usando los disparadores para marcar los registros que se hayan modificador, creado o borrado desde la ´ultima copia. La may-or parte de los sistemas gestmay-ores modernos permiten realizar estas r´eplicas bajo el control del gestor.

Por ´ultimo, las bases de datos orientadas o objetos incluyen varios mecanismos de encapsulamiento que tambi´en pueden sustituir y mejorar la funcionalidad que nos pueden dar los disparadores.

5.

Seguridad y autorizaci ´on

Existen varias formas de acceso que pueden ser mal utilizadas. Conc-retamente hay que impedir las operaciones de lectura no autorizada, las modificaciones no autorizadas, y la destrucci ´on de datos no autorizada

5 SEGURIDAD Y AUTORIZACI ´ON 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 ´ultimo, pero no menos importante, a nivel humano.

Las dos ´ultimas son especialmente importantes, ya que romper la se-guridad a esos niveles m´as bajos normalmente conlleva el poder salt´arsela a niveles m´as altos. Pi´ensese, por ejemplo, lo que podr´ıa hacer un intruso que obtuviera, mediante enga ˜nos, el identificador de usuario y la contrase ˜na del administrador, o con acceso f´ısico a las m´aquinas y a los discos que gestionan y almacenan la base de datos.

5.2. Autorizaciones

Un esquema de seguridad muy utilizado es elautorizaciones, que permi-tir´ıa realizar (o no) determinadas operaciones sobre los datos. Por ejemplo, podemos tener una autorizaci ´on para lectura, otra para inserci ´on, otra para modificaci ´on y otro para borrado. Se le pueden asignar a un usuario todos los tipos de autorizaci ´on, ninguno o una combinaci ´on de ellos.

Adem´as 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 ´on derecursos. El usuario con la autorizaci ´on de recursos que crea una relaci ´on nueva recibe autom´aticamente 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´etera. Esta forma de autorizaci ´on es an´aloga a la proporcionada al superusuario u operador del sistema op-erativo.

5.3. Autorizaciones y vistas

Como se vio en el tema 3, se pueden utilizar vistas para ocultar deter-minada informaci ´on, que el usuario de la vista no desea o no deba ver.

La creaci ´on de vistas no requiere la autorizaci ´on de recursos. El usuario que crea una vista no recibe necesariamente todos los privilegios sobre la misma. S ´olo recibe los privilegios que no a ˜naden nuevas autorizaciones a las que ya posee. Por ejemplo, un usuario no puede recibir la autorizaci ´on de actualizaci ´on sobre una vista si no tiene la autorizaci ´on de actualizaci ´on sobre las relaciones utilizadas para definir la vista.

5 SEGURIDAD Y AUTORIZACI ´ON 10

5.4. Concesi ´on de privilegios

Un usuario al que se le ha concedido una autorizaci ´on puede ser autor-izado 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 ´on de la autorizaci ´on de un usuario a otro puede represen-tarse mediante un grafo. Los nodos de este grafo son los usuarios. Un arco Ui →Ujindica que el usuarioUiconcede una autorizaci ´on aUj. La ra´ız de todos los grafos ser´a el administrador de la base de datos.

Un usuario tiene autorizaci ´on si y s ´olo si hay un camino desde el ad-ministrador 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´endose autorizaci ´on mutuamente. 5.5. El concepto de papel (rol)

Los papeles o roles son una forma de simplificar la asignaci ´on de autor-izaciones a los usuarios. Las autorautor-izaciones 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 identifi-cador 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 deter-minada transacci ´on, conduciendo a problemas de seguridad.

5.6. Trazas de auditor´ıa

Una traza de auditor´ıa es un registro hist ´orico de todos los cambios (inserciones, borrados o actualizaciones) de la base de datos, junto con informaci ´on sobre qui´en realiz ´o el cambio y cuando.

Es posible crear una traza de auditor´ıa definiendo disparadores (usan-do variables definidas del sistema que identifican el nombre de usuario y la hora). Sin embargo, muchos sistemas de bases de datos proporcio-nan mecanismos incorporados para crear trazas de auditor´ıa, que son m´as convenientes de utilizar.

6 AUTORIZACI ´ON EN SQL 11

6.

Autorizaci ´on en SQL

La norma SQL incluye los privilegios delete, insert,select yupdate . SQL tambi´en incluye un privilegioreferences que permite a un usuario o papel declarar claves externas al crear relaciones. Si la relaci ´on que se va a crear incluye una clave externa que hace referencia a atributos de otra relaci ´on, el usuario o papel debe haber recibido el privilegio references sobre esos atributos.

El lenguaje de definici ´on de datos de SQL incluye ´ordenes para conceder y retirar privilegios. La instrucci ´ongrantse utiliza para conferir autoriza-ciones.

grant<lista de privilegios>on<nombre de relaci ´on o de lista>to<lista de usuarios/papeles>

Para retirar una autorizaci ´on se utiliza la instrucci ´on revoke. Adopta una forma casi id´entica a la de grant:

revoke<lista de privilegios>on<nombre de relaci ´on o de vista>from

<lista de usuarios o papeles>[restrict|_cascade]

Las autorizaci ´onupdateeinsertpuede concederse sobre todos los atrib-utos de la relaci ´on o s ´olo sobre algunos. la lista de atribatrib-utos sobre los que se va a conceder la autorizaci ´on opcionalmente aparece entre par´entesis justo despu´es de la palabra clave update o insert. Si se omite la lista de atributos se concede sobre todos los atributos de la relaci ´on.

El privilegio SQLreferencestambi´en se concede con grant. La siguiente instrucci ´on grant permite al usuario U1 crear relaciones que hagan

refer-encia a la clave nombre-sucursal de la relaci ´on sucursal como si fuera una clave externa:

grant references(nombre-sucursal)onsucursaltoU1

En un principio puede parecer que no hay ning ´un motivo para evitar que los usuarios creen claves externas que hagan referencia a otra relaci ´on. Sin embargo, hay que recordar que las restricciones de las claves exter-nas pueden limitar las operaciones de borrado y de actualizaci ´on sobre la relaci ´on a la que hacen referencia.

El privilegioall privilegespuede utilizarse como una forma abreviada de todos los privilegios que se pueden conceder. De manera parecida, el nombre de usuariopublichace referencia a todos los usuarios presentes y futuros del sistema.

6 AUTORIZACI ´ON EN SQL 12

6.1.1. Papeles o roles

Los papeles se pueden crear como sigue: create rolecajero

Se pueden conceder privilegios a los papeles al igual que a los usuarios, como se ilustra en la siguiente instrucci ´on

grant select oncuentatocajero

Los papeles se pueden asignar a los usuarios, as´ı como a otros papeles, como muestran estas instrucciones.

grantcajerotoJuan create rolegestor grantcajerotogestor grantgestortomar´ıa

N ´otese que esto puede generar una cadena de papeles. Los privilegios efectivos consisten en todos los privilegios concedidos directamente m´as los concedidos indirectamente.

Debido a esto, la retirada de un privilegio a un usuario o papel puede hacer que otros usuarios o papeles tambi´en lo pierdan. Este comportamiento se denominaretirada en cadena.

6.1.2. El privilegio de conceder privilegios

Un usuario o papel al que se le concede un privilegio no est´a 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 ˜nadir la cl´ausulawith grant optiona la orden grant correspondiente. Por ejemplo, si se desea conceder aU1 el privilegioselect sobre sucursal y que pueda

transmitirlo a otros, hay que escribir

grant select onsucursaltoU1with grant option

6.1.3. Otras caracter´ısticas

El creador de un objeto (relaci ´on, vista o papel) obtiene todos los priv-ilegios sobre el objeto, incluyendo el privilegio de conceder privpriv-ilegios a otros.

7 CIFRADO Y AUTENTICACI ´ON 13

7.

Cifrado y autenticaci ´on

Para informaci ´on 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´en forma la base de los buenos esquemas para la autenticaci ´on de usuarios en una base de datos.

7.1. T´ecnicas de cifrado

Una buena t´ecnica de cifrado tiene las propiedades siguientes:

Es relativamente sencillo para los usuarios autorizados cifrar y de-scifrar los datos.

El esquema de cifrado no depende de lo poco conocido que sea el algoritmo, sino m´as bien de un par´ametro 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´etricos (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 ´ublica utilizan claves distintas para el cifrado y para el descifrado, por lo que puede evitar en parte el problema de la distribuci ´on de la clave.

Cada usuarioUitiene una clave p ´ublicaCiy una clave privadaDi. Las claves p ´ublicas, como su nombre indica, son de dominio p ´ublico: cualquiera puede verlas. La clave privada, por el contrario, s ´olo es conocida por el usuario al que pertenece. Si el usuarioU1desea guardar datos cifrados, los

cifra utilizando su clave p ´ublicaC1. Descifrarlos requiere la clave privada

D1(Que s ´olo el conoce).

Como la clave de cifrado de cada usuario es p ´ublica es posible inter-cambiar informaci ´on de manera segura. Si el usuarioU1 desea compartir

los datos conU2los codifica utilizandoC2, la clave p ´ublica deU2. Dado que

s ´oloU2conoce la manera de descifrar los datos, la informaci ´on se transmite

de manera segura.

Para que el cifrado de clave p ´ublica funcione debe haber un esquema de cifrado que pueda hacerse p ´ublico sin permitir a la gente descubrir el esquema de descifrado. En otros t´erminos, debe ser dif´ıcil deducir la clave privada dada la clave p ´ublica.

7 CIFRADO Y AUTENTICACI ´ON 14

Pese a que el cifrado de clave p ´ublica es seguro, tambi´en es costoso en cuanto a c´alculo. Se suele utilizar un esquema h´ıbrido para la comunicaci ´on segura: Se establece una clave de sesi ´on, utilizando cifrado sim´etrico, por ejemplo DES. las claves se trasmite mediante un cifrado de clave p ´ublica y posteriormente se utiliza el cifrado DES para los datos transmitidos. 7.2. Autenticaci ´on

La autenticaci ´on 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´as simple consiste en una contrase ˜na o password que se debe presentar cuando se abra una conexi ´on a la base de datos. Sin embargo, el uso de contrase ˜nas tiene algunos inconvenientes, especialmente en una red. Un esquema m´as seguro es el sistema dedesaf´ı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 ˜na 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 ˜nas no circulen por la red.

Los sistemas de clave p ´ublica tambi´en se pueden usar para cifrar en un sistema de desaf´ıo/respuesta. se cifra la cadena de desaf´ıo usando la clave p ´ublica del usuario y se le env´ıa al usuario. ´Este 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 ˜nadida de no almacenar la contrase ˜na en la base de datos.