Tema 6.

Restricciones a la Base de Datos:

Integridad y seguridad
Juan Ignacio Rodrguez de Leo
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 proteccio n de
la base de datos de accidentes. Restricciones de los dominios.
Integri- dad referencial. Asertos (asserts). Disparadores (triggers).
Seguridad y autorizacio n. Autorizacio n en SQL. Cifrado y
autenticacio n

I ndice
1. Restricciones de los dominios

2. Integridad referencial
2.1. Integridad referencial en el modelo E-R . . . . . . . . . . . .
2.2. Modificacio n de la base de datos . . . . . . . . . . . . . . . .
2.3. Integridad referencial en SQL . . . . . . . . . . . . . . . . . .

4
4
4
5

3. Asertos

4. Disparadores (triggers)
4.1. Necesidad de los disparadores . . . . . . . . . . . . . . . . .
4.2. Disparadores en SQL . . . . . . . . . . . . . . . . . . . . . . .
4.3. Cuando no deben usarse disparadores . . . . . . . . . . . . .

7
7
7
8

5. Seguridad y autorizacio n
8
5.1. Violaciones de la seguridad . . . . . . . . . . . . . . . . . . .
8
5.2. Autorizaciones . . . . . . . . . . . . . . . . . . . . . . . . . .
9
5.3. Autorizaciones y vistas . . . . . . . . . . . . . . . . . . . . . .
9
5.4. Concesio n de privilegios . . . . . . . . . . . . . . . . . . . . . 10
5.5. El concepto de papel (rol) . . . . . . . . . . . . . . . . . . . . . 10
5.6. Trazas de auditora . . . . . . . . . . . . . . . . . . . . . . . . 10

I
NDICE
6. Autorizacio n en SQL
6.1. privilegios en SQL . . . . . . . . . . . . . .
6.1.1. Papeles o roles . . . . . . . . . . . .
6.1.2. El privilegio de conceder privilegios
6.1.3. Otras caractersticas . . . . . . . .
.
7. Cifrado y autenticacio n
7.1. Te cnicas de
. . . . . . . . . . . . . .
cifrado
7.2.
Autenticacio n . . . . . . . . . . . . . . . .
.

.
.
.
.

11
11
12
12
12

. . . . . . . . . .
. . . . . . . . . .

13
13
14

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

1 RESTRICCIONES DE LOS DOMINIOS

En este tema se tratara n las restricciones a la base de datos. Las

restric- ciones 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 limitacio n de
los valores posibles de los atributos a un subconjunto, lo que denomina
bamos dominio del atributo.

1.

Restricciones de los dominios

Las restricciones de los dominios son la forma ma s simple de restriccio

n de integridad. El sistema las verifica fa cilmente siempre que se
introduce en la base de datos un nuevo elemento de datos.
La cla usula create domain se puede usar para definir nuevos
dominios. Por ejemplo, las instrucciones:
create domain Euros numeric(12,2)
create domain Do lares numeric(12,2)
Un intento de asignar un valor de tipo Dolares a una variable de tipo
Euros resultara en un error sinta ctico, aunque ambos tengan el mismo
tipo nume rico.
SQL tambie n proporciona las cla usulas drop domain y alter domain para
borrar o modificar dominios que se hayan declarado anteriormente.
La cla usula check de SQL permite restringir aun ma s los dominios;
per- mite al disen ador del esquema especificar un predicado que debe
satisfacer cualquier valor para poder pertenecer al dominio. Ve ase, como
ejemplo:
create domain sueldo-por-hora numeric(5,2)
constraint comprobacio n-valor-sueldo
check (value 4.00)
El dominio sueldo-por-hora tiene una restriccio n que asegura que el
sueldo por hora sea mayor que 4,00.
Tambie n puede utilizarse para restringir un dominio para que no
con- tenga valores nulos, o se puede limitar para que contenga so lo un
conjunto especificado de valores usando la cla usula in.
las condiciones check permiten subconsultas que se refieren a otras relaciones. Por ejemplo, esta restriccio n se podra especificar sobre la relacio
n pre stamo:
check (nombre-sucursal in
(select nombre-sucursal from sucursal))

2 INTEGRIDAD REFERENCIAL

La condicio n check verifica que nombre-sucursal en cada tupla en la

relacio n pre stamo es realmente el nombre de una sucursal de la relacio
n cuenta. As, la condicio n no so lo se debe comprobar cuando se
inserte o modifique pre stamo, sino tambie n cuando cambie la relacio n
sucursal (en este caso, cuando se borre o modifique la relacio n cuenta).
La restriccio n anterior es realmente un ejemplo de una clase de
restric- cio n muy habitual denominadas restriccio n de integridad
referencial. En el Apartado 2 se estudian estas restricciones y como
especificarlas en SQL.
Las condiciones check complejas pueden ser u 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 relacio n

para un conjunto de atributos determinado aparezca tambie n en otra relacio
n para un cierto conjunto de atributos. Esta condicio n se denomina
integridad referencial.
El caso ma s normal es cuando queremos garantizar que el valor almacenado en una clave externa esta tambie n como clave primaria en la

relacio n referenciada. En caso contrario, se dice que la tupla de la relacio

n referenciante esta 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.

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 relacio n que proceda de un conjunto
de relaciones tendra restricciones de integridad referencial.
Otra fuente de restricciones de integridad referencial son los conjuntos
de entidades de biles; el esquema de la relacio n de cada conjunto de
enti- dades de biles incluye una clave externa, lo que lleva a una
restriccio n de integridad referencial.

2.2.
datos

Modificacio n de la base de

La modificacio n 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.

El borrar se da un caso ma 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 operacio n.
Realizar la operacio n, y borrar las tuplas de las relaciones
dependi- entes, de forma que se garantice la consistencia de los
datos. Las op- eraciones de borrados que se realizan en respuesta al
borrado inicial se denominan borrados en cascada.
Realizar la operacio n, 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 actualizacio 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
operacio n.
Si se modifica la clave primaria, en la tabla maestra, se debe realizar
una comprobacio n similar a la realizada en el borrado, que
puede incluir tambie n la cancelacio n de la operacio n o la
realizacio n de actualizaciones en cascada

2.3. Integridad referencial en SQL

Las claves externas pueden especificarse como parte de la instruccio
n create table de SQL usando la cla usula foreign key.
De manera predeterminada, una clave externa referencia los atributos
que forman la clave primaria de la tabla referenciada (SQL tambie n soporta una versio n de la cla usula references, donde se puede
especificar explcitamente una lista de atributos de la relacio n
referenciada).
Se usa la siguiente sintaxis para declarar que un atributo forma una
clave externa:
foreign key (A1 [, A2 , . . . , An ])
references R
Cuando se viola una restriccio n de integridad referencial, el
proced- imiento normal es rechazar la accio n que provoco la violacio n.
Sin embargo,

3 ASERTOS

la cla usula foreign key puede especificar las acciones a tomar para
restaurar la integridad referencial.
La cla usula on delete cascade asociada con la declaracio n de la
clave externa, provoca que el borrado se realice en cascada. La cla usula
on up- date cascade, de forma similar realiza una actualizacio n en
cascada, si se modifica la clave primaria.
SQL tambie n permite una accio 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 cla usula set default.
Si hay una cadena de dependencias de claves externas entre varias
relaciones, un borrado o una actualizacio n en uno de sus extremos
puede propagarse por toda la cadena, de ah la denominacio 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 transaccio n.
Las restricciones de integridad se comprueban so lo al final de la transaccio
n, no en los pasos intermedios.

3.

Asertos

Un aserto es un predicado que expresa una condicio 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 atencio n 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 restricciones
que no se pueden expresar utilizando u nicamente estas formas
especiales. Ejemplos de estas restricciones pueden ser:
La suma de todos los importes de los pre stamos de cada
sucursal debe ser menor que la suma de todos los saldos de las
cuentas de esa sucursal.
Cada pre stamo tiene al menos un cliente que tiene una cuenta con
un saldo mnimo 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 va lido, so lo se permiten las modificaciones posteriores de la base de
datos que no hagan que se viole el aserto.
Esta comprobacio n puede introducir una sobrecarga importante si
se han realizado asertos complejos. Por tanto, los asertos deben utilizarse
con precaucio n.

4 DISPARADORES (TRIGGERS)

4.

Disparadores (triggers)

Un disparador es una orden que el sistema ejecuta de manera automa

tica como efecto secundario de la modificacio n de la base de datos.
Para disen 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 comprobacio n
del disparador y una condicio n 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 eventocondicio n
accio 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 condicio n correspondiente.

4.1. Necesidad de los disparadores

Los disparadores son mecanismos u tiles para alertar a los usuarios
o para realizar de manera automa tica ciertas tareas cuando se cumplen
de- terminadas condiciones.
Obse rvese 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 implemento 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
operacio n lo dispara: insert, update o delete (No hay disparadores en
los select porque estos no modifican los datos). Adema s debe indicar,
cuando se va a ejecutar, antes (before) o despue s (after) de la operacio n).
Tambie n se puede especificar una predicado de condicio n necesario
para la acti- vacio n del trigger, mediante la cla usula when. Para las
actualizaciones, el disparador puede especificar aquellas columnas cuya
actualizacio n cause la ejecucio n del disparador.

5 SEGURIDAD Y AUTORIZACIO
N

El co digo que se ejecuta en el disparador puede necesitar los

valores de los atributos antes y despue s de ser modificados. para ello se
utilizan las cla usulas referencing new row as y referencing old row as.
Los valores nuevos son accesibles en disparadores de insercio n o
actualizacio n, y los valores antiguos en disparadores de actualizacio n o
borrado.
Estos disparadores pueden servir como restricciones extras que pueden
evitar actualizaciones no va lidas. Por ejemplo, si no se desea permitir
des- cubiertos, se puede crear un disparador before que retroceda la
transaccio n si el nuevo saldo es negativo.
En lugar de realizar una accio n por cada fila afectada, se puede
realizar una accio n u nica para la instruccio n SQL completa que causo
la insercio n, borrado o actualizacio n. Para hacerlo se usa la cla usula for
each statement en lugar de for each row. Las cla usulas referencing old
table as o referenc- ing new table as se pueden usar entonces para hacer
referencia a tablas temporales (denominadas tablas de transicion)
conteniendo todas las filas afectadas. Las tablas de transicio 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).

4.3. Cuando no deben usarse disparadores

No se deben usar disparadores para resolver problemas que ya tiene
otro mecanismo de resolucio 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 tambie 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 tpico 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 u ltima copia. La
may- or parte de los sistemas gestores modernos permiten realizar estas re
plicas bajo el control del gestor.
Por u ltimo, las bases de datos orientadas o objetos incluyen varios
mecanismos de encapsulamiento que tambie n pueden sustituir y
mejorar la funcionalidad que nos pueden dar los disparadores.

5.

Seguridad y autorizacio 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 destruccio n de datos no autorizada

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 fsica y por u ltimo, pero no menos importante, a
nivel humano.
Las dos u ltimas son especialmente importantes, ya que romper la
se- guridad a esos niveles ma s bajos normalmente conlleva el poder salta
rsela a niveles ma s altos. Pie nsese, por ejemplo, lo que podra hacer un
intruso que obtuviera, mediante engan os, el identificador de usuario y
la contrasen a del administrador, o con acceso fsico a las ma quinas y
a los discos que gestionan y almacenan la base de datos.

5.2. Autorizaciones
Un esquema de seguridad muy utilizado es el autorizaciones, que permitira realizar (o no) determinadas operaciones sobre los datos. Por
ejemplo, podemos tener una autorizacio n para lectura, otra para insercio
n, otra para modificacio n y otro para borrado. Se le pueden asignar a un
usuario todos los tipos de autorizacio n, ninguno o una combinacio n de
ellos.
Adema 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
autorizacio n de recursos. El usuario con la autorizacio n de recursos que
crea una relacio n nueva recibe automa 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, etce tera. Esta forma de autorizacio
n es ana loga 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 determinada informacio n, que el usuario de la vista no desea o no deba ver.
La creacio n de vistas no requiere la autorizacio n de recursos. El
usuario que crea una vista no recibe necesariamente todos los privilegios
sobre la misma. So lo recibe los privilegios que no an aden nuevas
autorizaciones a las que ya posee. Por ejemplo, un usuario no puede
recibir la autorizacio n de actualizacio n sobre una vista si no tiene la
autorizacio n de actualizacio n sobre las relaciones utilizadas para definir
la vista.

5.4. Concesio n de privilegios

Un usuario al que se le ha concedido una autorizacio n 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 transmisio n de la autorizacio n de un usuario a otro puede
represen- tarse mediante un grafo. Los nodos de este grafo son los
usuarios. Un arco Ui U j indica que el usuario Ui concede una
autorizacio n a U j . La raz de todos los grafos sera el administrador de
la base de datos.
Un usuario tiene autorizacio n si y so lo 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 concedie ndose autorizacio n mutuamente.

5.5. El concepto de papel (rol)

Los papeles o roles son una forma de simplificar la asignacio n de
autor- izaciones 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, sera 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 sera posible identificar exactamente al cajero que ha realizado una
deter- minada transaccio n, conduciendo a problemas de seguridad.

5.6. Trazas de auditora

Una traza de auditora es un registro histo rico de todos los
cambios (inserciones, borrados o actualizaciones) de la base de datos,
junto con informacio n sobre quie n realizo el cambio y cuando.
Es posible crear una traza de auditora 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 auditora,
que son ma s convenientes de utilizar.

6 AUTORIZACIO N EN
SQL

6.

11

Autorizacio n en SQL

6.1. privilegios en SQL

La norma SQL incluye los privilegios delete, insert, select y update .
SQL tambie n incluye un privilegio references que permite a un usuario o
papel declarar claves externas al crear relaciones. Si la relacio n que se
va a crear incluye una clave externa que hace referencia a atributos de
otra relacio n, el usuario o papel debe haber recibido el privilegio
references sobre esos atributos.
El lenguaje de definicio n de datos de SQL incluye o rdenes para
conceder y retirar privilegios. La instruccio n grant se utiliza para conferir
autoriza- ciones.
grant <lista de privilegios> on <nombre de relacio n o de lista> to
<lista de usuarios/papeles>
Para retirar una autorizacio n se utiliza
Adopta una forma casi ide ntica a la de grant:

la instruccio n revoke.

revoke <lista de privilegios> on <nombre de relacio n o de vista> from

<lista de usuarios o papeles> [restrict | cascade]
Las autorizacio n update e insert puede concederse sobre todos los
atrib- utos de la relacio n o so lo sobre algunos. la lista de atributos sobre
los que se va a conceder la autorizacio n opcionalmente aparece entre pare
ntesis justo despue s de la palabra clave update o insert. Si se omite la lista
de atributos se concede sobre todos los atributos de la relacio n.
El privilegio SQL references tambie n se concede con grant. La
siguiente instruccio n grant permite al usuario U1 crear relaciones que
hagan refer- encia a la clave nombre-sucursal de la relacio n sucursal
como si fuera una clave externa:
grant references (nombre-sucursal) on sucursal to U1
En un principio puede parecer que no hay ningu n motivo para
evitar que los usuarios creen claves externas que hagan referencia a otra
relacio n. Sin embargo, hay que recordar que las restricciones de las
claves exter- nas pueden limitar las operaciones de borrado y de
actualizacio n sobre la relacio 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.

6 AUTORIZACIO N EN
SQL

12

6.1.1. 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 instruccio 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
No tese que esto puede generar una cadena de papeles. Los
privilegios efectivos consisten en todos los privilegios concedidos
directamente ma s los concedidos indirectamente.
Debido a esto, la retirada de un privilegio a un usuario o papel puede
hacer que otros usuarios o papeles tambie n lo pierdan. Este
comportamiento se denomina retirada en cadena.
6.1.2. El privilegio de conceder privilegios
Un usuario o papel al que se le concede un privilegio no esta
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 an adir la cla usula
with grant option
a la orden grant
correspondiente. Por ejemplo, si se desea conceder a U1 el privilegio
select sobre sucursal y que pueda transmitirlo a otros, hay que escribir
grant select on sucursal to U1 with grant option
6.1.3. Otras caractersticas
El creador de un objeto (relacio n, vista o papel) obtiene todos los privilegios sobre el objeto, incluyendo el privilegio de conceder privilegios a
otros.

7 CIFRADO Y AUTENTICACIO
N

7.

13

Cifrado y autenticacio n

Para informacio 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 tambie n forma la base de los buenos
esquemas para la autenticacio n de usuarios en una base de datos.

7.1. Te cnicas de cifrado

Una buena te 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 ma s bien de un para metro del algoritmo
denominado clave de cifrado.
Es extremadamente difcil para un intruso determinar la clave
de cifrado.
Los esquemas como DES, TripleDES o Rijndael son esquemas de
cifrado sime 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 pu blica utilizan claves distintas para el
cifrado y para el descifrado, por lo que puede evitar en parte el
problema de la distribucio n de la clave.
Cada usuario Ui tiene una clave pu blica Ci y una clave privada Di .
Las claves pu blicas, como su nombre indica, son de dominio pu blico:
cualquiera puede verlas. La clave privada, por el contrario, so lo es
conocida por el usuario al que pertenece. Si el usuario U1 desea guardar
datos cifrados, los cifra utilizando su clave pu blica C1 . Descifrarlos
requiere la clave privada D1 (Que so lo el conoce).
Como la clave de cifrado de cada usuario es pu blica es posible intercambiar informacio n de manera segura. Si el usuario U1 desea
compartir los datos con U2 los codifica utilizando C2 , la clave pu blica de
U2 . Dado que so lo U2 conoce la manera de descifrar los datos, la
informacio n se transmite de manera segura.
Para que el cifrado de clave pu blica funcione debe haber un
esquema de cifrado que pueda hacerse pu blico sin permitir a la gente
descubrir el esquema de descifrado. En otros te rminos, debe ser difcil
deducir la clave privada dada la clave pu blica.

7 CIFRADO Y AUTENTICACIO
N

14

Pese a que el cifrado de clave pu blica es seguro, tambie n es costoso

en cuanto a ca lculo. Se suele utilizar un esquema hbrido para la
comunicacio n segura: Se establece una clave de sesio n, utilizando
cifrado sime trico, por ejemplo DES. las claves se trasmite mediante un
cifrado de clave pu blica y posteriormente se utiliza el cifrado DES para
los datos transmitidos.

7.2.
n

Autenticacio

La autenticacio 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 ma s simple consiste en una contrasen a o password que se
debe presentar cuando se abra una conexio n a la base de datos. Sin
embargo, el uso de contrasen as tiene algunos inconvenientes,
especialmente en una red.
Un esquema ma s seguro es el sistema de desafo/respuesta. El sistema
de bases de datos enva una cadena de desafo al usuario. El usuario
cifra la cadena de desafo usando una contrasen 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 desafo original. La ventaja de este
sistema es que las contrasen as no circulen por la red.
Los sistemas de clave pu blica tambie n se pueden usar para cifrar en
un sistema de desafo/respuesta. se cifra la cadena de desafo usando la
clave pu blica del usuario y se le enva al usuario. E 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 an adida de no almacenar la contrasen a en la base de
datos.