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ó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
2.1. Integridad referencial en el modelo E-R . . . . . . . . . . . .
2.2. Modificación de la base de datos . . . . . . . . . . . . . . . .
2.3. Integridad referencial en SQL . . . . . . . . . . . . . . . . . .
4
4
4
5
3. Asertos
6
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 autorización
5.1. Violaciones de la seguridad
5.2. Autorizaciones . . . . . . .
5.3. Autorizaciones y vistas . . .
5.4. Concesión de privilegios . .
5.5. El concepto de papel (rol) . .
5.6. Trazas de auditorı́a . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
9
9
10
10
10
ÍNDICE
6. Autorizació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 caracterı́sticas . . . . . . . . .
2
.
.
.
.
11
11
12
12
12
7. Cifrado y autenticación
7.1. Técnicas de cifrado . . . . . . . . . . . . . . . . . . . . . . . .
7.2. Autenticación . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13
14
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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))
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.
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ó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.
2.2.
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.
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 (A1 [, A2 , . . . , An ])
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,
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 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á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.
4
DISPARADORES (TRIGGERS)
4.
7
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.
4.1.
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.
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).
4.3.
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.
5.1.
Seguridad y autorización
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
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.
5.2.
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.
5.3.
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.
5
SEGURIDAD Y AUTORIZACIÓN
5.4.
10
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
Ui → U j indica que el usuario Ui 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.
5.5.
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.
5.6.
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.
6
AUTORIZACIÓN EN SQL
6.
6.1.
11
Autorización en SQL
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 U1 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 U1
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.
6
AUTORIZACIÓN EN SQL
6.1.1.
12
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.
6.1.2.
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 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 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.
7
CIFRADO Y AUTENTICACIÓN
7.
13
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.
7.1.
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 Ui tiene una clave pública Ci y una clave privada Di . 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 U1 desea guardar datos cifrados, los
cifra utilizando su clave pública C1 . Descifrarlos requiere la clave privada
D1 (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 U1 desea compartir
los datos con U2 los codifica utilizando C2 , la clave pública de U2 . Dado que
sólo U2 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.
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.
7.2.
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.