You are on page 1of 139

1

SEGURIDAD EN EL DISEÑO
DE BASES DE DATOS Y
SISTEMAS DE
INFORMACIÓN
Dr. Eduardo Fernández-Medina
Grupo de Investigación Alarcos
Escuela Superior de Informática de Ciudad Real
Universidad de Castilla-La Mancha
Eduardo.FdezMedina@uclm.es
2
Contenido de la Presentación
•Introducción
•Técnicas de Control de Acceso
•Modelos de Seguridad en Bases de Datos
•Tecnología en Bases de Datos Seguras
•Diseño de Bases de Datos Seguras
•Ejercicio de diseño e implementación
•Conclusiones
•Bibliografía
3
Contenido de la Presentación
•Introducción
•Técnicas de Control de Acceso
•Modelos de Seguridad en Bases de Datos
•Tecnología en Bases de Datos Seguras
•Diseño de Bases de Datos Seguras
•Ejercicio de diseño e implementación
•Conclusiones
•Bibliografía
4
•Las bases de datos almacenan información
importante en todos los ámbitos: comerciales,
militares, médicos, administrativos, judiciales, etc.,
etc.
•La información ha pasado a ser el activo más
importante de las organizaciones, por encima incluso
de los activos tradicionales (económicos, humanos y
materias primas).
•Además, hay datos especiales (personales) que están
protegidos por leyes en casi todos los países.
5
Calidad del Software
Usabilidad
Eficiencia
Fiabilidad
Mantenibilidad
Funcionalidad
Portabilidad
ISO 9126
Seguridad
6
LEGALES
ORGANIZATIVAS
FÍSICAS
COMUNICACIONES
Seguridad en Bases de Datos
7
Seguridad es la capacidad de un producto
software de proteger los datos y la información
para que personas no autorizadas no puedan
leerlos o modificarlos, y que el acceso no sea
denegado a personal autorizado (ISO/IEC,
1999b)
Confidencialidad
Integridad
Disponibilidad
Confidencialidad
8
• Confidencialidad: prevenir / detectar /
impedir el descubrimiento de información. En
general la Confidencialidad se refiere a la
protección de datos implicados en entornos
altamente protegidos, como entornos militares,
comerciales, etc. Privacidad se refiere a
información sobre individuos. En la mayoría de
los países la Privacidad está protegida por las
leyes.
9
• Integridad: prevenir / detectar / impedir la modificación
inadecuada de información. Por ejemplo en un entorno
militar, el mando responsable de un misil no debe ser
modificado inadecuadamente. En un entorno comercial, la
integridad de los datos es especialmente relevante, puesto
que el éxito de una organización depende de lo correctas
que son las operaciones que se llevan a cabo y la
coherencia en los datos. Por ejemplo, un trabajador no
debe poder modificar su salario.
•Integridad semántica: Respeto en todo momento de
las reglas de integridad definida en la base de datos.
•Integridad Operacional: Garantizar la consistencia
de la base de datos con respecto al uso concurrente
de la misma.
10
• Disponibilidad: prevenir / detectar / impedir
la denegación inadecuada del acceso a servicios
ofrecidos por el sistema. Por ejemplo, en un
entorno militar, cuando el mando
correspondiente da la orden de lanzar el misil,
el misil es disparado. En entornos comerciales,
las órdenes de pago deben ser hechas en el
momento.
•También relacionada con los
mecanismos de recuperación de la base de
datos ante caídas del sistema.
11
La protección de bases de datos puede obtenerse a
través de medidas de seguridad para:
-Control del flujo de información
-Control de inferencia
-Control de acceso a la información
Para estos controles, las técnicas criptográficas
pueden ayudar, pero no resuelven el problema.
12
Control de Flujo:
Regula la distribución de información entre
objetos accesibles. Un flujo entre el objeto X y el
objeto Y se produce cuando un sujeto lee el valor
de X y escribe el valor en Y. Si el flujo de
información no se controla puede dar lugar a
situaciones de pérdida de confidencialidad o
privacidad.
El problema se acentúa con políticas de control
de acceso discrecionales y obligatorias.
13
Ejemplo de Control de Flujo:
Dados dos usuarios, U1 y U2, y dos recursos de
información R1 y R2, un problema de control de flujo
se produciría por ejemplo cuando un usuario U1 accede
a un recurso R1 (para el que U1 tiene acceso y U2 no),
y escribe cierta información de R1 en el recurso R2,
para el que U2 tiene acceso.
El problema es que ha habido un flujo de información
que le permite a un usuario acceder a información para
la que en condiciones normales no estaría autorizado.
14
Control de Inferencia:
Trata de proteger los datos de descubrimientos
indirectos de información. Ocurre cuando un
conjunto de items de datos X puede ser leido por
un usuario, y puede ser usado para obtener el
conjunto de datos Y de la forma Y=f(X).
Un ‘canal de inferencia’ es un canal donde los
usuarios pueden encontrar un item X y entonces
usarlo para derivar Y.
15
Ejemplo de Control de Inferencia:
-El problema que provoca la poli-instanciación.
-Inferencia de información en base a los datos
que son accesibles:
-Saber el salario de los individuos teniendo
acceso a la categoría profesional y a una tabla de
equivalencias
16
Los principales canales de inferencia son:
• Acceso Indirecto. Ejemplo: insertar una tupla cuya clave primaria
es la misma de una tupla no visible para el usuario. Cuando el
sistema avisa del problema, inferimos la existencia de una tupla a
la que no podemos acceder (poli-instanciación)
• Datos correlacionados. Ejemplo: z=t*k. Si t y k son visibles, y z
no es visible, el valor de z puede ser inferido fácilmente. Saber el
salario de los individuos teniendo acceso a la categoría
profesional y a una tabla de equivalencias
• Valores ocultos. A veces, la existencia de valores nulos o no
visibles, puede dar sospechas de que se esconde información
confidencial: Clasificar datos en una base de datos de acuerdo a
rangos concretos. Los usuarios, analizando la información
pueden inferir esos rangos de acuerdo a la información que
pueden ver.
17
El problema de la inferencia estadística
Implica la deducción de datos. Las bases de datos estadísticas
permiten la consulta de datos estadísticos sobre grupos de
individuos. En esas bases de datos, el acceso a datos sobre
individuos individuales no está permitido, puesto que los
datos son sólo accesibles a través de funciones estadísticas.
Sin embargo, analizando datos estadísticos se pueden obtener
datos sobre individuos concretos. Para hacer frente a este tipo
de problemas se suelen utilizar dos tipos de controles:
–Control de consultas: Restringen las consultas
estadísticas que podrían revelar al usuario información
confidencial
–Perturbaciones de datos. Introducen algunos tipos de
modificaciones durante el procesamiento de la consulta.
18
Control de acceso:
Es el responsable de asegurar que todos los
accesos directos a objetos del sistema se
producen exclusivamente de acuerdo a los
modos y reglas definidos por las políticas de
protección definidas.
19
Deficiencias en la seguridad pueden generar
diferentes tipos de problemas:
Pérdidas económicas
Pérdidas de imagen
Pérdida de clientes
Problemas legales

Empresas
Individuos
Privacidad

20
Cambios que se producirán en la Sociedad de la Información durante el período
2001-2005 (Telefónica, 2001)
En 2005 será Menor Igual Mayor
0 1 0 0 2 0 0 3 0 0 4 0 0 5 0 0 6 0 0
Promoción de asociaciones
Participación en decisiones políticas
Libertad
Intimidad
Generación de riqueza
Disponibilidad de tiempo
Dif erencias económicas
Desarrollo de señas culturales dif erenciadas
Desarrollo de la identidad individual
Calidad en las relaciones laborales
Calidad de vida en áreas aisladas
Calidad de las relaciones personales
Bienestar social
Acceso a la inf ormación
Acceso a la educación
Vasectomía
21
Importancia de la regulación de aspectos de la Sociedad de la Información
durante el período de 2001-2005 (Telefónica, 2001)
Importancia: Menos Más
´ ± ´ .´´ .± ´ ± ´´ ± ± ´ ¯ ´´ ¯ ± ´ _´´ _± ´ ± ´´
Valor jurídico de
documentos electrónicos
Responsabilidad civil
Registro de nombres de
dominios Internet
Protección de datos
personales
Nuevas condiciones
laborales
Límites legales
nacionales
Fiscalidad
Derechos de propiedad
intelectual
Contenidos
potencialmente nocivos
22
Amenazas contra la seguridad en la información (ámbito internacional) (Ernst &
Young, 1998)
Amenaza Para la Seguridad de la Información
(Internacional)
0 5 10 15 20 25 30
Usuarios Autorizados / Empleados
Distribuidores Autorizados
Trabajadores Subcontratados / Consultores
Auditores
Clientes
Usuarios no Autorizados
Exempleados
La competencia
Terroristas de Computadores
Piratas Inf ormáticos
1997
1998
23
Desafíos para obtener los niveles adecuados de seguridad (Ernst & Young, 2001)
Retos Para Lograr el Nivel de Seguridad Requerido
8%
26%
37%
40%
44%
56%
0% 10% 20% 30% 40% 50% 60%
Otras Razones
Apoyo de la Dirección
Presupuesto
Disponibilidad de Personal Apropiado
Herramientas o Soluciones de Seguridad
Concienciación de los Empleados
24
En relación con la protección de datos personales:
1992 ¬LORTAD
Junio 1999 ¬Reglamento de Seguridad
Diciembre 1999 ¬Nueva Ley de
Protección de Datos Personales
Diversos autores (en varios foros) reclaman la
integración de seguridad en el proceso de desarrollo
de software (IEEE Software, Vol 19, Nº 1, 2002)
Seguridad es considerada en alguno de los más
importantes SGBD’s (Oracle9i Label Security)
Europa
España
1995 ¬Directiva Europea 95/46/CE
25
Contenido de la Presentación
•Introducción
•Técnicas de Control de Acceso
•Modelos de Seguridad en Bases de Datos
•Tecnología en Bases de Datos Seguras
•Diseño de Bases de Datos Seguras
•Ejercicio de diseño e implementación
•Conclusiones
•Bibliografía
26
Técnicas de Control de Acceso
Es el mecanismo a través del que intentamos
asegurar que solamente los sujetos autorizados
pueden acceder a los recursos del sistema de
información.
Regla de Autorización = <sujeto, objeto, privilegio>
27
Técnicas de Control de Acceso
28
<s,o,p>
OBJETOS DE AUTORIZACIÓN
- FICHEROS Y DIRECTORIOS
- RELACIONES, VISTAS, ATRIBUTOS
- CLASES, JERARQUÍAS DE CLASES
29
<s,o,p>
SUJETOS DE AUTORIZACIÓN
- USUARIOS
- GRUPOS DE USUARIOS
- ROLES
- PROCESOS
30
<s,o,p>
PRIVILEGIOS DE AUTORIZACIÓN
- LEER, ESCRIBIR, EJECUTAR
- SELECCIONAR, INSERTAR, ACTUALIZAR,
REFERENCIAR, INDEXAR
31
Las políticas de control de acceso se pueden clasificar en dos grupos:
• Cerradas: Solamente los accesos autorizados
explícitamente son permitidos
32
• Abiertas: Los accesos que no son explícitamente
prohibidos son permitidos.
33
Tipos de políticas de control de acceso
× Discrecional
× Obligatorio
× Basado en Roles
× Basado en Tareas
× Basado en Restricciones
34
POLÍTICA DE CONTROL DE ACCESO DISCRECIONAL
×Acceso basado en la identidad de los sujetos y en reglas de autorización que
indican para cada sujeto, las acciones que puede realizar y las que no puede
realizar sobre cada objeto del sistema
×Permite conceder privilegios de acceso sobre otros usuarios de forma
discrecional
×Se soportan en matrices de acceso que almacenan toda la información
35
POLÍTICA DE CONTROL DE ACCESO DISCRECIONAL
La implementación de esas matrices conceptuales, tradicionalmente se ha llevado
a cabo a través de tres enfoques:
×Tabla de autorización
36
POLÍTICA DE CONTROL DE ACCESO DISCRECIONAL
×Lista de control de acceso
×Capacidades
37
POLÍTICA DE CONTROL DE ACCESO DISCRECIONAL
Existen muchas variantes de esta política de control de acceso:
+POSITIVA / NEGATIVA
Según la autorización positiva, la existencia de la regla de
autorización indica que se puede realizar el acceso, mientras que la no
existencia de la misma prohíbe el acceso.
En cambio mediante la autorización negativa, el acceso se
permite sólo cuando no existe una regla de autorización negativa, mientras
que la existencia de la regla prohíbe el acceso.
La principal diferencia es que en el caso de autorización positiva,
si un sujeto no tiene autorización, en algún momento se puede producir
una propagación de privilegios de tal forma que otro sujeto le ceda el
acceso, en cuyo caso estaría burlando el control de acceso. Eso no puede
suceder con el mecanismo de autorización negativa.
38
POLÍTICA DE CONTROL DE ACCESO DISCRECIONAL
Existen muchas variantes de esta política de control de acceso:
+FUERTE / DÉBIL
Autorizaciones fuertes, tanto positivas como negativas son
aquellas que no pueden ser invalidadas, mientras que las débiles sí pueden
ser invalidadas por otras autorizaciones fuertes o débiles, de acuerdo a
unas reglas específicas.
+EXPLÍCITA / IMPLÍCITA
Las autorizaciones implícitas son automáticamente derivadas
por el sistema desde el conjunto de autorizaciones explícitas, de acuerdo
a un conjunto de reglas. Por ejemplo, una autorización implícita podría
ser aquella que expresa que un sujeto puede acceder a un objeto dado
sólo si otro sujeto tiene un acceso explícito denegado.
39
POLÍTICA DE CONTROL DE ACCESO DISCRECIONAL
Las bases de datos que utilizan esta política de control de acceso
son susceptibles de recibir ataques por parte de sujetos que
aparentemente realicen un acceso correcto a los datos, pero que en
realidad han recibido el permiso de acceso por parte de otro sujeto
de forma fraudulenta.
Ejemplo:
En una organización, Juan es un gerente de alto nivel que crea un
fichero llamado ‘Ventas’, que contiene información muy
importante para la organización. Esta información, es muy
sensible, y de acuerdo con la política de la organización debería ser
protegida ante cualquier acceso no autorizado. Consideremos
ahora a José, que es uno de los subordinados de Juan, que quiere
descubrir la información almacenada en el fichero ‘Ventas’.
40
POLÍTICA DE CONTROL DE ACCESO DISCRECIONAL
Para conseguirlo, José crea otro fichero, llamado ‘Ilegal’, y le
da a Juan permisos de escritura sobre el fichero. Notar que
Juan puede no ser consciente de la existencia del fichero
‘Ilegal’ o de que tiene permiso de acceso sobre él. Además, José
modifica una aplicación que generalmente es usada por Juan,
incluyendo dos operaciones ocultas, una operación de lectura
sobre el fichero ‘Ventas’ y una operación de escritura sobre el
fichero ‘Ilegal’. Supongamos ahora que Juan ejecuta ahora la
aplicación. Puesto que la aplicación es ejecutada en nombre de
Juan, todos los accesos son comprobados contra los permisos
de acceso de Juan, y tanto las operaciones de lectura y de
escritura son permitidas. Como resultado de la ejecución de esa
aplicación, información sensible ha sido transferida del fichero
‘Ventas’ al fichero ‘Ilegal’, y está disponible ahora para José.
41
POLÍTICA DE CONTROL DE ACCESO DISCRECIONAL
42
POLÍTICA DE CONTROL DE ACCESO DISCRECIONAL
43
POLÍTICA DE CONTROL DE ACCESO OBLIGATORIO
Consiste en la clasificación de tanto los sujetos como los objetos en el
sistema en ‘clases de acceso’ que determinan sus características de
confidencialidad.
Una ‘clase de acceso’ es un elemento de un conjunto de ‘clases’
parcialmente ordenadas. Las clases de acceso se definen como un
conjunto formado por dos componentes, un ‘nivel de seguridad’ y un
‘conjunto de categorías’.
Cada ‘nivel de seguridad’ es un elemento de un conjunto jerárquicamente
ordenado como ‘alto secreto’ (TS), ‘secreto’ (S), ‘confidencial’ (C) y ‘sin
clasificar’ (U), donde TS > S > C > U.
El conjunto de categorías es un subconjunto de un conjunto desordenado,
donde los elementos pueden reflejar áreas funcionales o diferentes
competencias como por ejemplo ‘finanzas’, ‘administración’, ‘ventas’ y
‘compras’ para sistemas comerciales
44
POLÍTICA DE CONTROL DE ACCESO OBLIGATORIO
El orden parcial es definido por una relación de dominio que se
denota con ‘≥’.
La relación de dominio ≥ es definida de la siguiente forma: una
clase de acceso C1 domina (≥) a otra clase de acceso C2 si y sólo
si el nivel de seguridad de C1 es mayor o igual que el de C2 y las
categorías de C1 incluyen las de C2.
TS,
S,{
45
POLÍTICA DE CONTROL DE ACCESO OBLIGATORIO
Esta política está basada en el Modelo de Bell-La Padula:
El objetivo principal es garantizar la confidencialidad de la
información, y para ello se definen dos reglas de acceso:
Regla de lectura no ascendente (propiedad de seguridad
simple):
“Un sujeto tiene acceso de lectura a un objeto si su clase de
acceso domina a la clase de acceso del objeto”
Regla de escritura no descendente (propiedad *, estrella):
“Un sujeto tiene acceso de escritura a un objeto si su clase
de acceso es dominado por la clase de acceso del objeto”
46
POLÍTICA DE CONTROL DE ACCESO OBLIGATORIO
Si la escritura fuese hacia abajo podría existir flujo de
información inadecuado. Un usuario con nivel ‘Confidencial’
tendría acceso a la información almacenada por un usuario con
nivel ‘Alto Secreto’
D
o
m
i
n
a
n
c
e
47
POLÍTICA DE CONTROL DE ACCESO OBLIGATORIO
Por la regla de No-Escritura-Hacia-Abajo, sería imposible que un
usuario pueda escribir datos en niveles inferiores.
Para evitar este problema, se permite que los usuarios pueden
conectarse al sistema utilizando cualquier ‘clase de acceso’ que esté
dominado por su ‘clase de acceso’, generando de este modo un
‘sujeto’ con esa ‘clase de acceso’ (notar la distinción entre ‘usuario’
y ‘sujeto’).
Por ejemplo, un usuario que tenga asignado el nivel de seguridad
‘secreto’ se podrá conectar al sistema como ‘secreto’, ‘confidencial’
y ‘sin clasificar’. Así, cuando un ‘usuario’ realiza una ‘petición’, la
‘clase de acceso’ que se considera es la del ‘sujeto‘ generado al
conectarse al sistema.
48
POLÍTICA DE CONTROL DE ACCESO OBLIGATORIO
Si no se cumplen las dos reglas de acceso se podrían producir
situaciones como la siguiente:
En una organización, Juan es un gerente con un nivel de seguridad
‘secreto’, que crea un fichero llamado ‘Ventas’, que también tiene
un nivel de seguridad ‘secreto’ y que contiene información muy
importante para la organización.
Consideremos ahora a José que tiene un nivel de seguridad ‘sin
clasificar’, y que es uno de los subordinados de Juan que quiere
descubrir la información almacenada en el fichero ‘Ventas’.
49
POLÍTICA DE CONTROL DE ACCESO OBLIGATORIO
Para conseguirlo, José crea otro fichero, llamado ‘Ilegal’ con un
nivel de seguridad ‘sin clasificar’ y modifica una aplicación que
generalmente es usada por Juan, incluyendo dos operaciones ocultas,
una operación de lectura sobre el fichero ‘Ventas’ y una operación
de escritura sobre el fichero ‘Ilegal’.
Supongamos ahora que Juan ejecuta ahora la aplicación. Si Juan se
ha conectado con el nivel ‘secreto’, y el principio de acceso de
escritura no se cumple, tanto la operación de lectura como la de
escritura se llevarían a cabo y se estaría descubriendo información
sensible, pero si el principio de acceso de escritura se cumple, la
operación de lectura será realizada, pero al intentar realizar la
operación de escritura el sistema avisaría de que se está intentando
realizar un acceso no autorizado.
50
SGBD Relacional Multinivel
• Estas bases de datos se caracterizan por poder clasificar
distintos elementos de la base de datos (columna, fila,
elemento individual, tabla o incluso la base de datos entera)
en diferentes clases de acceso
NT Nombre NN Dept. ND Salario NS NT Nombre NN Dept. ND Salario NS
SC Juan SC Dep1 SC 20 SC SC Juan SC Dep1 SC 20 SC
SC María SC Dep2 SC 10 SC SC María SC Dep2 SC 10 SC
S José S Dep1 S 40 S SC Iván SC Dep1 SC - SC
SC Iván SC Dep1 SC 30 S
(a) Relación Multinivel

(b) Vista de un sujeto de nivel ‘Sin Clasificar’

51
SGBD Relacional Multinivel
Esta clasificación de información trae consigo una serie de
problemas importantes. El principal es el conocido como ‘Poli-
instanciación’ o ‘Poli-instauración’.
El problema viene debido a la necesidad de coexistir en el sistema
de múltiples instancias de la misma entidad del mundo real, donde
las instancias difieren solamente de su clase de acceso.
Este problema se da si queremos garantizar al máximo la
confidencialidad en situaciones como la siguiente: Existe una tupla
con nivel de seguridad ‘alto secreto’ y cuya clave es ‘1’. Si un
usuario con nivel de seguridad ‘sin clasificar’ (que no debe saber
nada sobre las tuplas clasificadas en niveles superiores) intenta
insertar una tupla con nivel ‘sin clasificar’ y con clave ‘1’.
52
SGBD Relacional Multinivel
Si el sistema da un mensaje de error, estaría proporcionando
información confidencial a un usuario no autorizado.
El sistema por el contrario lo que tendría que hacer es permitir que
este usuario cree esa tupla, en cuyo caso, existirían dos tuplas con
el mismo valor en el campo clave, lo cual hace violar la regle de
integridad de la unicidad de la clave primaria.
La única alternativa es unir el o los campo clave a el atributo de
seguridad para formar la nueva clave.
Además, también habrá que pagar el coste de gestionar tuplas
repetidas.
¬La poli-instanciación es el principal motivo del éxito limitado
de las bases de datos seguras en el entorno comercial
53
SGBD Relacional Multinivel
Aunque esta política de control de acceso ofrece protección frente a
pérdidas de información, no garantiza una completa confidencialidad
de la información. De hecho es muy complicado controlar la no
existencia de canales ocultos.
Por ejemplo, si un usuario ‘sin clasificar’ escribe una información en
nivel ‘secreto’ (aceptado por la regla de escritura), y se produce un
error por el que el sistema le informa, estaríamos de nuevo en un
caso de descubrimiento de información confidencial.
54
POLÍTICA DE CONTROL DE ACCESO BASADA EN ROLES
Esta política regula el control de acceso de usuarios a la
información, en base a las actividades y responsabilidades
organizacionales que los usuarios tienen en el sistema
×Se asocian permisos con Roles
×Los usuarios se hacen miembros de esos roles obteniendo
así permisos
×Cada rol representa un grupo funcional con
responsabilidades similares
×Permite de manera sencilla cambios organizacionales
55
POLÍTICA DE CONTROL DE ACCESO BASADA EN ROLES
56
POLÍTICA DE CONTROL DE ACCESO BASADA EN ROLES
Esta política ofrece un conjunto de ventajas:
× Gestión de autorizaciones: Hay una independencia
lógica entre la actividad de asignar roles a usuarios y
asignar privilegios de acceso a los roles. Esto facilita
mucho la gestión.
× Jerarquía de roles: En muchas aplicaciones hay una
jerarquía natural de roles, basadas en los principio bien
conocidos de generalización y especialización. Esto puede
dar lugar a autorizaciones implícitas como por ejemplo:
El secretario o secretaria hereda todos los permisos del
personal de administración.
57
POLÍTICA DE CONTROL DE ACCESO BASADA EN ROLES
58
POLÍTICA DE CONTROL DE ACCESO BASADA EN ROLES
× Privilegios mínimos: Los roles permiten que un usuario tenga los
privilegios estrictamente necesarios para realizar una tarea
particular. Esto minimiza los peligros de daño debido a un exceso de
privilegios.
× Separación de responsabilidades: Se refiere al principio de que
ningún usuario debería tener suficientes privilegios para darle un uso
inadecuado al sistema en su propio beneficio. Por ejemplo, la persona
autorizada a pagar un cheque no debe ser la misma que la persona
que lo prepara. Esto se puede hacer cumplir distinguiendo roles
usuarios entre roles conflictivos.
× Cumplimiento de restricciones: Los roles dan una base para la
especificación de requisitos de protección que pueden ser necesarias
en las situaciones reales. Ejemplo: número máximo de usuarios en un
rol, etc.
59
POLÍTICA DE CONTROL DE ACCESO BASADA EN ROLES
Constraints
60
Contenido de la Presentación
•Introducción
•Técnicas de Control de Acceso
•Modelos de Seguridad en Bases de Datos
•Tecnología en Bases de Datos Seguras
•Diseño de Bases de Datos Seguras
•Ejercicio de diseño e implementación
•Conclusiones
•Bibliografía
61
Modelos de Seguridad en Bases de Datos
El objetivo de los modelos de seguridad es producir un modelo
conceptual de alto nivel, independiente del software que describa las
necesidades de protección del sistema.
Un modelo de seguridad proporciona lo siguiente:
• Una representación semántica de las propiedades de
seguridad del sistema.
• La facilidad a los desarrolladores de dar una definición de
alto nivel de los requisitos de protección y las políticas del
sistema, describiendo de manera precisa el comportamiento
del sistema
•Demostrar que el sistema satisface algunas propiedades de
seguridad.
62
Modelos de Seguridad en Bases de Datos
Han sido propuestos un gran número de modelos de seguridad, y en
general se podrían clasificar en dos categorías:
• Discrecionales
• Obligatorios
Todos estos modelos, tanto discrecionales como obligatorios se
pueden subdividir atendiendo a los siguientes criterios:
• Elementos que se desean proteger (BD, SO, etc.)
• Tipo de política (Discrecional, Obligatoria)
• Enfoque de la política (confidencialidad / integridad)
• Tipo de control (acceso directo /acceso indirecto de
información)
63
Modelos de Seguridad en Bases de Datos
64
Modelos de Seguridad en Bases de Datos
Al describir un modelo de seguridad, siempre aparecen los
siguientes conceptos:
• Sujetos: Son las entidades activas del sistema que piden
accesos sobre objetos.
• Objetos: Son entidades pasivas del sistema, que contienen
información que debe ser protegida ante accesos o
modificaciones no autorizados.
• Modos de acceso: Son los tipos de acceso que los sujetos
pueden ejercitar sobre los objetos. Siempre que se produce un
acceso, causa un flujo de información desde el objeto al sujeto
y/o desde el sujeto al objeto.
65
Modelos de Seguridad en Bases de Datos
• Políticas: Son las leyes que orquestan el control de acceso.
Generalmente de alto nivel.
•Autorizaciones: Definen qué accesos podrán realizar los
usuarios sobre los objetos y qué otros no.
• Permisos administrativos (implementadas por primitivas como
‘grant’, ‘revoke’, ‘own’): permiten la modificación de
autorizaciones: En sistemas discrecionales, la posesión de
privilegios de administración en los sujetos, indica que pueden
otorgar y revocar privilegios (autorizaciones) a otros sujetos.
• Axiomas: Son propiedades que deben ser satisfechas por el
sistema.
66
67
Modelo de Matriz de Acceso de Harrison-Ruzzo-Ullman
• Modelo de seguridad tanto para Sistemas Operativos como para
Bases de Datos.
• Se han definido varias extensiones y versiones
El modelo deriva su nombre por el hecho de que el estado de
autorización es definido utilizando una matriz que relaciona
sujetos, objetos y las autorizaciones de cada sujeto sobre cada
objeto.
Estados de autorización
68
El estado de autorización es descrito por la tripleta Q=(S,O,A), donde:
• S es el conjunto de sujetos, que pueden ser un usuario, un
conjunto de usuarios, un proceso o un dominio (contexto o
entorno dentro del cual un proceso puede operar).
• O es el conjunto de objetos, que consiste tanto en entidades
pasivas (los recursos del sistema) como en entidades activas
(sujetos, que también son vistos como objetos). Por lo tanto O ⊂
S. En SO: ficheros, memoria, segmentos, procesos. En Bases de
Datos: base de datos, relación, atributo, registro, campos en
registro.
• A es la matriz de acceso. La entrada A[s,o] contiene los modos de
acceso para los que el sujeto s está autorizado sobre el objeto o.
Modelo de Matriz de Acceso de Harrison-Ruzzo-Ullman
69
Modelo de Matriz de Acceso de Harrison-Ruzzo-Ullman
En la aplicación de este modelo a las bases de datos, en la
especificación de autorizaciones, se pueden incluir condiciones que
deben ser satisfechas para que el sujeto utilice el objeto. Consistiría
en incluir en las posiciones de la matriz reglas de decisión que
especifiquen determinadas condiciones.
70
Modelo de Matriz de Acceso de Harrison-Ruzzo-Ullman
Algunas de estas condiciones pueden ser:
• Dependientes de datos: Un sujeto s puede estar autorizado a
leer de una tabla Empleado sólo aquellos empleados cuyo
salario es >= 1000.
• Dependientes del tiempo: Un sujeto puede estar autorizado
para leer de la tabla Empleado sólo entre las 8 y las 17 horas.
• Dependientes del contexto: Un sujeto puede estar autorizado a
leer el nombre y el salario de los empleados, pero no puede
leerlos juntos y así obtener el par nombre-salario en ningún
caso.
• Dependientes de la historia: Un sujeto puede estar autorizado
a leer el salario de los empleados si previamente no ha leido
el nombre de los empleados.
71
Modelo de Matriz de Acceso de Harrison-Ruzzo-Ullman
Modos de Acceso
El modo de acceso depende del tipo de objetos considerados.
Habitualmente son los privilegios de lectura, escritura, append,
ejecución y propiedad.
La entrada A[s,o] que contiene el modo de acceso ‘propietario’
indica que s es considerado el propietario de o, y que por lo tanto,
está permitido a administrar autorizaciones sobre o.
El estado del sistema puede ser modificado a través de un conjunto
de comandos que serán una secuencia de operaciones primitivas
que permiten modificar la matriz de accesos:
Operaciones
72
73
Modelo de Matriz de Acceso de Harrison-Ruzzo-Ullman
Comandos
Los comandos están formados por dos partes, una de condición y otra
de acción. Ejemplo:
Command CREATE(process,file)
create object file
enter O into (process,file)
End.
Este comando expresa la idea de que siempre que un usuario cree un
nuevo fichero, éste recibirá el privilegio de propiedad sobre el
fichero.
74
Modelo de Matriz de Acceso de Harrison-Ruzzo-Ullman
Command GRANT
READ
(owner,friend,file)
If O in A[owner,file]
Then enter R into A[friend,file]
End.
Este comando expresa el comando de otorgar permiso de lectura a
otro usuario. Se comprueba que el sujeto que otorga el permiso es
realmente el propietario del objeto, y si es así, se introduce en la
matriz el permiso de lectura para el otro usuario sobre el objeto
deseado.
(No está incluida en las diapositivas impresas)
75
Modelo de Matriz de Acceso de Harrison-Ruzzo-Ullman
La inclusión del privilegio de ‘propiedad’ permite la posibilidad de permitir
que los sujetos administren autorizaciones en los objetos que han creado.
Así, el propietario de un objeto puede otorgar o revocar a otros sujetos
cualquier privilegio sobre sus objetos (excepto el de ‘propiedad’, que no
puede ser transferido).
En algunos sistemas es posible que el propietario de un objeto, propague el
privilegio de ‘otorgar’ privilegios (grant).
Detrás de estas palabras se esconden unas teorías y especificaciones
relativamente complejas. Por ejemplo, es posible especificar comandos que
mediante la utilización de operaciones primitivas se exprese la gestión en la
administración de autorizaciones.
Administración de Autorizaciones
76
Modelo de Matriz de Acceso de Harrison-Ruzzo-Ullman
No es viable utilizar una matriz
rectangular debido al enorme
espacio necesario. Por lo que se
escoge entre alguna de estas
soluciones:
Implementación del Modelo
77
Otros Modelos de Seguridad
• Take-Grant: Usa una estructura de grafo para representar el estado
del sistema, enfocando el tema a la propagación de privilegios
(creando arcos que representan propagación de privilegios, etc.).
• Action-Entity: Considera un conjunto mucho más rico de
privilegios de administración y da soporte a predicados en las
autorizaciones.
• Wood y otros: Especialmente dirigido a la protección de
información en bases de datos basado en la arquitectura de tres
niveles de abstracción ANSI/SPARC, y considerando el problema de
autorizaciones en esquemas relacionales multidimensionales. Está
basado en reglas de derivación y controles de consistencia de
autorizaciones en diferentes niveles del esquema.
78
Otros Modelos de Seguridad
• Bell & LaPadula: El objetivo es salvaguardar la confidencialidad
evitando flujos de información de objetos de alto nivel a objetos de
bajo nivel.
•BIBA: Modelo muy similar al de Bell & LaPadula, pero con el
objetivo de salvaguardar la integridad de la información.
Precisamente, preserva la integridad evitando que existan flujos de
información de objetos de bajo nivel a objetos de alto nivel.
• Dion: Trata de preservar tanto la confidencialidad como la
integridad mediante una mezcla de las ideas del modelo de seguridad
de Bell&LaPadula y de Biba.
• Sea View
• Jajodia-Sandhu
Basados en modelo de Bell&LaPadula pero
tratando de diferente forma el problema de la Poli-
instanciación
79
Contenido de la Presentación
•Introducción
•Técnicas de Control de Acceso
•Modelos de Seguridad en Bases de Datos
•Tecnología en Bases de Datos Seguras
•Diseño de Bases de Datos Seguras
•Ejercicio de diseño e implementación
•Conclusiones
•Bibliografía
80
Prototipos de Bases de Datos Seguras
Casi todas las marcas comerciales han desarrollado algún
prototipo para implementar bases de datos seguras, pero sin tener
ninguna repercusión en el mercado. Por ejemplo, alguno de estos
prototipos son:
TRUDATA
Secure Sybase
Trusted Oracle
Trusted Informix
Recientemente ha aparecido un nuevo producto de Oracle en su
versión 9 que parece prometedora: Oracle9i Label Security
81
Oracle9i Label Security (OLS)
• Implementa bases de datos multinivel
• Control de acceso basado en unas etiquetas para datos y
usuarios.
• Control de acceso a nivel de fila.
• Capa virtual que gestiona las etiquetas y asegura el
cumplimiento de las políticas de seguridad OLS
82
Oracle9i Label Security (OLS)
• El control de acceso es mixto:
• Para que un usuario tenga acceso sobre una determinada fila de
una tabla, deben cumplirse las siguientes condiciones:
× Que el usuario esté autenticado por la base de datos.
× Que el usuario tenga los privilegios sobre la fila (CA
discrecional).
× Que el usuario cumpla las reglas de acceso en función
del nivel de sensibilidad del dato y del nivel de
habilitación del usuario.
×Discrecional ¬Mediante política de privilegios
×Obligatoria ¬Mediante control de etiquetas
83
Componentes de las Etiquetas de Datos.
• Información del nivel de sensibilidad de la información.
• Distintas categorías organizacionales de información.
• Distintos grupos jerárquicos de información.
Toda esta información se almacena codificada en una columna de
datos en cada tabla.
Oracle9i Label Security (OLS)
84
El nivel de seguridad es un elemento que permite denotar la
sensibilidad de la información etiquetada. La información será más
sensible a medida que el nivel de seguridad sea más alto.
Forma
numérica Forma larga
Forma
Corta
40
Alta Sensibilidad AS
30 Sensible S
20 Confidencial C
10 Público P
OLS define para cada nivel de
seguridad varios elementos que
ayudan a manejar este concepto de
manera más cómoda, como por
ejemplo una forma numérica para
representar el nivel de seguridad
que se utilizará internamente para
hacer comparaciones de niveles de
manera eficiente, o una forma larga
para almacenar la descripción
completa del nivel, y la forma
corta para trabajar con más
agilidad.
85
Las categorías son opcionales,
y puede haber cero, una o
varias en la definición de una
etiqueta.
En el caso de las categorías, la
forma numérica no denotará
ningún tipo de ordenación.
Forma
numérica Forma larga
Forma
Corta
40
Financiera FIN
30 Química QUIM
20 Operacional OPER
Las categorías identifican áreas que describen la sensibilidad de
un dato etiquetado. Asocian el dato con una o varias áreas de
seguridad. Todos los datos relacionados con un determinado
proyecto o sector pueden ser etiquetados con la misma categoría.
86
Los grupos identifican una relación de posesión o de acceso a los datos.
Todos los datos pertenecientes a un cierto departamento podrán tener el
grupo de dicho departamento en su etiqueta. Los grupos son útiles para
controlar la diseminación de datos y para oportunas reacciones de
cambios organizacionales. Cuando una compañía se reorganiza, el
control de acceso puede cambiar con la reorganización.
Región de
Madrid
Madrid
Ventas
Madrid
Recursos
Humanos
Madrid
Finanzas
Madrid
Facturas a
Cobrar
Madrid
Facturas a
Pagar
Los grupos podrán ser
jerárquicos, es decir, se
podrán definir un
conjunto de grupos
correspondientes a una
jerarquía organizacional
como este ejemplo.
87
Para un caso como el anterior, el administrador de la base de datos crearía
una estructura con el contenido siguiente.
Forma
numérica
Forma larga Forma Corta Padre
1000 Región de Madrid M
1100 Madrid Ventas MV M
1200 Madrid Recursos
Humanos
MRH M
1300 Madrid Finanzas MF M
1310 Madrid Facturas a
Cobrar
MFC MF
1320 Madrid Facturas a
Pagar
MFP MF
88
Tipo de Entorno Niveles Categorías Grupos
Defensa
Alto Secreto
Secreto
Confidencial
Sin Clasificar
Alfa
Delta
Sigma
Reino Unido
OTAN
España
Servicios
Financieros
Adquisiciones
Empresa
Cliente
Operaciones
Seguros
Activos
Obligaciones
Préstamos Comerciales
Préstamos al Consumo
Clientes
Administradores
Beneficiarios
Gestión
Personal
Justicia
Seguridad Nacional
Sensible
Público
Civil
Criminal
Administración
Defensa
Acusación
Juzgado
Salud
Médico
Paciente Confidencial
Paciente Público
Farmacéutica
Enfermedades Infecciosas
Cuidados Intensivos
Investigación
Personal de Enfermería
Personal de Hospital
Negocios
Negocio Secreto
Propietario
Compañía Confidencial
Público
Mercado
Finanzas
Ventas
Personal
Empresa 1
Empresa 2
Empresa 3
Empresa 4
89
Componentes de las Etiquetas de Usuarios.
Un usuario sólo puede acceder a los datos que están en su rango
de autorización. Para ello, en las etiquetas de los usuarios se
almacena la siguiente información:
• Un nivel máximo, uno mínimo y otro de la sesión.
• Un conjunto de categorías autorizadas.
• Un conjunto de grupos autorizados. De lectura, de escritura y
por defecto. Evidentemente, de manera implícita quedarían
incluidos los grupos heredados de los grupos explícitos
registrados en este lugar.
Oracle9i Label Security (OLS)
90
AS FIN RM
S FIN MV
S QUIM,FIN RM
AS FIN
U FIN
C FIN MV
Etiquetas de Usuario
Etiquetas de Datos
Usuario 1
Usuario 2
Fila 1
Fila 4
Fila 2
Fila 3
Oracle9i Label Security (OLS)
Usuario 1 no puede acceder a la Fila 1
porque no tiene acceso a la categoría de
Química. Para tener acceso a esta fila, el
usuario debería de tener un nivel de
seguridad igual o superior al nivel de
seguridad del dato, debería incluir todas
las categorías que tiene el dato, y debería
de pertenecer al menos a uno de los grupos
que se especifican en la etiqueta del dato.
Usuario 2 no puede acceder a la
Fila 1 porque no tiene acceso a la
categoría Química y porque no está
autorizado a acceder a la
información del grupo RM (Región
de Madrid)
91
Oracle9i Label Security (OLS)
Cuando el acceso que se desea realizar es de lectura, las reglas
que se han de cumplir son las siguientes:
• El nivel del usuario (el de la sesión bajo la que está conectado)
debe ser mayor o igual que el nivel del dato.
• La etiqueta del usuario debe incluir al menos uno de los grupos
que pertenecen al dato (o el grupo padre de uno de los subgrupos).
• La etiqueta del usuario debe incluir todas las categorías que
incluya el dato.
Si la etiqueta del usuario cumple estas condiciones, entonces se
dirá que domina a la etiqueta de la fila.
92
Oracle9i Label Security (OLS)
Para determinar si un usuario puede escribir en una determinada
fila de datos, OLS evalúa las siguientes reglas y en el siguiente
orden:
• El nivel en los datos debe ser mayor o igual que el mínimo nivel
del usuario y menor o igual que el nivel de la sesión del usuario.
• Cuando hay grupos, la etiqueta del usuario debe incluir al menos
uno de los grupos con acceso de escritura de los que aparezca en la
etiqueta del dato (o el padre de uno de los subgrupos). Además la
etiqueta del usuario debe incluir todas las categorías de la etiqueta
del dato.
• Cuando no hay grupos, la etiqueta del usuario debe tener acceso
de escritura a todas las categorías de la etiqueta de los datos.
93
O
r
a
c
l
e
9
i

L
a
b
e
l

S
e
c
u
r
i
t
y

(
O
L
S
)
Opciones por Defecto:
HIDE, LABEL_DEFAULT, LABEL_UPDATE,
CHECK_CONTROL, READ_CONTROL,
INSERT_CONTROL, DELETE_CONTROL,
UPDATE_CONTROL, ALL_CONTROL,
NO_CONTROL
POLÍTICA DE SEGURIDAD
Nombre de Política
Nombre de Columna de Etiquetas
Niveles de Sensibilidad de la
Política
Categorías de la Política
Grupos de la Política
Datos de Acreditación:
Nivel del Usuario: Maximo,
Mínimo, por Defecto, de Fila
Categorías del Usuario
Grupos del Usuario
USUARIOS
Nombre de Usiuario
Privilegios otorgados:
READ, FULL, COMPACCESS,
PROFILE_ACCESS, WRITEUP,
WRITEDOWN, WRITEACROSS
ESQUEMA DE LA BASE DE DATOS
TABLA DEL
ESQUEMA
Definición
de datos de acreditación
del usuario
Definición de privilegios
del usuario
Código en PL/SQL
Unidades de
Programación
Nombre de la Unidad
de Programación
Privilegios otorgados:
READ, FULL, COMPACCESS,
PROFILE_ACCESS, WRITEUP,
WRITEDOWN, WRITEACROSS
FUNCIONES DE
ETIQUETADO
PREDICADOS
OPCIONES DE
SEGURIDAD
PARTICULARES
Asignación
de Privilegios a
Unidades de
Programación
Ejecución de
Unidades de
Programación
Aplicación
de una
Política
a un
Esquema
Ejecución de
Operaciones directas
del Usuario sobre
las Tablas
Aplicación de
una Política
a una Tabla
94
OLS permite lo siguiente (a nivel de administración):
• Línea de comandos y herramienta visual
• Políticas de seguridad
• Valores de seguridad (niveles, categorías y grupos) para cada política
• Usuarios y su información de autorización y privilegios
• Opciones por defecto en las políticas
• Funciones de etiquetado y predicados
• Aplicar políticas de seguridad a tablas y a esquemas
• Seguridad de programas almacenados
Oracle9i Label Security (OLS)
95
CREATE_POLICY(‘SecurityPolicy’,‘SecurityLabel’, ‘HIDE, CHECK_CONTROL,
READ_CONTROL, WRITE_CONTROL’)
CREATE_LEVEL(‘SecurityPolicy’, 1000, ‘U’, ‘Unclassify’)
CREATE_LEVEL(‘SecurityPolicy’, 2000, ‘C’, ‘Confidential’)
CREATE_LEVEL(‘SecurityPolicy’, 3000,‘S’, ‘Secret’)
CREATE_LEVEL(‘SecurityPolicy’, 4000, ‘T’, ‘Top Secret’)
CREATE_GROUP(‘SecurityPolicy’, 1, ‘L’, ‘LocalGovermmentEmploee’)
CREATE_GROUP(‘SecurityPolicy’, 2, ‘O’, ‘Operator’, ‘L’)
CREATE_GROUP(‘SecurityPolicy’, 3, ‘SY’, ‘SystemAdministrator’, ‘L’)
CREATE_GROUP(‘SecurityPolicy’, 4, ‘S’, ‘SuperUser’, ‘SA’)
CREATE_GROUP(‘SecurityPolicy’, 5, ‘A’, ‘NormalAdministrator’, ‘SA’)
CREATE_GROUP(‘SecurityPolicy’, 6, ‘SR’, ‘SecurityResponsible’, ‘SA’)
CREATE_GROUP(‘SecurityPolicy’, 7, ‘E’, ‘Experienced’, ‘O’)
CREATE_GROUP(‘SecurityPolicy’, 8, ‘NE’, ‘Non-Experienced’, ‘O’)
CREATE_GROUP(‘SecurityPolicy’, 9, ‘AAO’, ‘AccountAreaOperator’, ‘E’)
CREATE_GROUP(‘SecurityPolicy’, 10, ‘PAO’, ‘PersonnelAreaOperator’, ‘E’)
CREATE_GROUP(‘SecurityPolicy’, 11, ‘OAC’, ‘AdministrativeAreaOperator’, ‘E’)
Oracle9i Label Security (OLS)
96
SET_LEVELS(‘SecurityPolicy’, ‘User1’, ‘T’, ‘S’, ‘S’)
SET_GROUPS(‘SecurityPolicy’, ‘User1’, ‘O’, ‘O’, ‘O’)
SET_USER_PRIVS(‘SecurityPolicy’, ‘User1’, ‘FULL, WRITEUP,
WRITEDOWN, WRITEACROSS’)
Oracle9i Label Security (OLS)
97
CREATE FUNCTION Function1 (BankDescription: VarChar)
Return LBACSYS.LBAC_LABEL
As MyLabel varchar2(80);
Begin
If BankDescription=’Non-Spanish bank’ then MyLabel := ‘S::AAO,OAC’;
else MyLabel := ‘U::OAA,OAC’;
end if;
Return TO_LBAC_DATA_LABEL(‘SecurityPolicy’, MyLabel);
End;
CREATE FUNCTION Function2( ) Return LBACSYS.LBAC_LABEL
As MyLabel varchar2(80);
Begin
MyLabel := ‘T::O’ ;
Return TO_LBAC_DATA_LABEL(‘SecurePolicy’, MyLabel);
End;
Oracle9i Label Security (OLS)
98
CREATE FUNCTION Function3(Refunds: Real) Return LBACSYS.LBAC_LABEL
As MyLabel varchar2(80);
Begin
If Refunds <=3000 the MyLabel := ‘U::O’;
else if Refunds <= 10000 then MyLabel := ‘S::O’; else MyLabel := ‘T::O’;
end if;
end if;
Return TO_LBAC_DATA_LABEL(‘SecurityPolicy’, MyLabel);
End;
APPLY_TABLE_POLICY (‘SecurityPolicy’, ‘BankingData’, ‘Scheme’, ,‘Function1’)
APPLY_TABLE_POLICY (‘SecurityPolicy’,
LaterFinancialYearsCreditorAndDefaulter’, ‘Scheme’, , ‘Function2’)
APPLY_TABLE_POLICY (‘SecurityPolicy’, ‘CreditorOfTheExpenseBudget’,
‘Scheme’, ,‘Function3’)
Oracle9i Label Security (OLS)
99
Contenido de la Presentación
•Introducción
•Técnicas de Control de Acceso
•Modelos de Seguridad en Bases de Datos
•Tecnología en Bases de Datos Seguras
•Diseño de Bases de Datos Seguras
•Ejercicio de diseño e implementación
•Conclusiones
•Bibliografía
100
Diseño de Seguridad en Bases de Datos (Castano et al., 1994)
Diseño Conceptual
Diseño Físico
Diseño Lógico
Análisis Preliminar
Requisitos y políticas
de seguridad
Mecanismos
de seguridad
Implementación
Lenguaje de
especificación de
requisitos de
seguridad
Modelo
conceptual de
seguridad
Modelo lógico
de seguridad
Modelo físico
de seguridad
Tecnología del sistema
de gestión de bases de
datos
Esquema lógico
de seguridad
Parámetros
del proyecto
101
Diseño Conceptual de Bases de Datos Seguras
Semantic Data Model for Security (Smith, 1990 and 1991)
PROFESOR
ALUMNO
DEPARTA-
MENTO
DIRECCIÓN
SALARIO
FECHA-INGRESO
PRESUPUESTO
DNI
CODIGO
NOMBRE
CODIGO
(S)
(C,S)
(C)
(C,S)
(C)
(C)
(C)
(C)
NOMBRE
(C)
(C)
(C)
NOMBRE
DIRECCIÓN
102
Multilevel Object Modeling Technique (MOMT)
• Modelo de objetos multinivel
• Modelo dinámico multinivel
• Modelo funcional multinivel
El diseño de la base de datos no se
considera en esta metodología
103
Principal Objetivo:
Poder construir bases de
datos seguras mediante
procesos de ingeniería
Captura de
requisitos
Análisis de la
Base de Datos
Diseño de la
Base de Datos
lenguajes
de
restricciones
más
aceptados
lenguajes
de
restricciones
más
aceptados
modelo de
seguridad
modelo de
seguridad
modelos
de proceso
más
aceptados
modelos
de proceso
más
aceptados
estándares de
modelado más
aceptados
estándares de
modelado más
aceptados
P
r
o
c
e
s
o

U
n
i
f
i
c
a
d
o

A
d
a
p
t
a
d
o
Modelo CU Extendido
Modelo C Extendido
OSCL
RMSCL
Modelo Multinivel
104
Principales etapas de esta Metodología
1. Captura de Requisitos
2. Análisis
3. Diseño Lógico
4. Diseño Lógico Específico
105
Captura de Requisitos
Diagrama de Casos de Uso Extendido
Objetivos
Artefactos
Identificar y organizar los
requisitos de la bases de datos,
teniendo en cuenta los requisitos
de confidencialidad
106
Captura de Requisitos
Actividades
Catalogar Requisitos Tentativos
Catalogar Requisitos Tentativos
Buscar Casos de Uso
Buscar Casos de Uso
Buscar Elementos de Información Permanente
Buscar Elementos de Información Permanente
Describir Casos de Uso
Describir Casos de Uso
Analizar la Seguridad en Casos de Uso y Actoress
Analizar la Seguridad en Casos de Uso y Actoress
Dar Prioridades a Casos de Uso
Dar Prioridades a Casos de Uso
Estructurar el modelo de Casos de Uso
Estructurar el modelo de Casos de Uso
Buscar Relaciones entre Casos de Uso
Buscar Relaciones entre Casos de Uso
Revisión de Casos de Uso
Revisión de Casos de Uso
Buscar Actores
Buscar Actores
Crear el Modelo de Negocio y el Glosarios del Sistema
Crear el Modelo de Negocio y el Glosarios del Sistema
Analizar la Seguridad en Casos de Uso y Actores
Analizar la Seguridad en Casos de Uso y Actores
107
Administrative
«Accredited-Actor»
Modify the balance of a customer
account
<<Secure-UC>>
Customers
«Database»
Modelo Extendido de Casos de Uso
108
Análisis
El modelo de clases extendido
Objetivos
Artefactos
Formalizar los requisitos y construir un
modelo que represente conceptualmente
la estructura de la base de datos,
clasificando la información de acuerdo a
sus propiedades de confidencialidad y
especificando las restricciones de
seguridad necesarias
109
Análisis
Actividades
Análisis de la
Arquitectura
Análisis de la
Arquitectura
Análisis de Seguridad
Análisis de Seguridad
Análisis de Paquetes
Análisis de Paquetes
Análisis de Clases
Análisis de Clases
Análisis de Casos de
Uso
Análisis de Casos de
Uso
Identificar paquetes de análisis
Identificar clases evidentes
Identificar relaciones
Identificar clases de un CU
Revisión de Clases
Identificar Atributos
Identificar Relaciones
Revisar Atributos y Asociaciones
Análisis de Seguridad
Análisis de Seguridad
110
Análisis de
Seguridad
Análisis de
Seguridad
Especificar niveles de
seguridad
Asignar roles de usuario
Especificar restricciones
de seguridad
Analizar otras
restricciones de seguridad
Analizar seguridad en
actores
Revisión de la Seguridad
Definir niveles de seguridad para la base de datos
Definir NS para cada clase
Definir NS para atributos y asociaciones
Comprobar restricciones inherentes
Analizar la jerarquía de usuarios
Definir RU para cada clase
Definir RU para atributos y asociaciones
Comprobar restricciones inherentes
Comprobar coherencia entre NS y RU
Analizar NS de cada actor
Analizar los RU que juega cada actor
111
Account {SL = S..T; Roles = Staff}
accountID {SL = S} : OID
balance {SL = S..T} : Integer
movements {SL = S} : Movements
openingDate {SL = S} : Date
<<persistent>>
Customer {SL = C; Roles = Direction, Cashier}
personID {SL = C} : OID
name {SL = C} : Name
sex {SL = C} : Sex
birthDate {SL = S} : Date
address {SL = S} : Address
maritalStatus {SL = S} : MaritalStatus
comment {SL = S} : Varchar(2000)
<<persistent>>
1..* 1 1..* 1
has {SL = S..T; Roles = Director, Cashier}
Modelo Extendido de Clases
112
Satellite_image {SL = U .. TS}
Id : Integer
Image : RGB
Accuracy : Integer
Purpose : String
Frequency : Real
Compression_Format : String
context Satellite_image
inv:
self.SL= (if self.Accuracy >= 90 then U else
(if self.Accuracy >= 10 then C else (if
self.Accuracy >= 2 then S else TS endif)
endif) endif)
Modelo Extendido de Clases
113
Object Security Constraint Language (OSCL)
context Satellite_Image inv:
self.SL = (if self.Purpose = “Military”
then TS
else (if self.Purpose = “Spying”
then (if self.Accuracy >= 10
then S
else TS
endif)
else (if self.Purpose = “Maps”
then (if self.Accuracy >= 90
then U
else (if self.Accuracy >= 10
then C
else (if self.Accuracy >= 2
then S
else TS
endif)
endif)
endif)
endif)
endif)
endif)
114
Diseño Lógico
Descripción de Relaciones
Metainformación
Restricciones de Seguridad
Objetivos
Artefactos
Representar a través de un modelo lógico la
información que ha sido recogida en la etapa
anterior de la metodología, evitando la pérdida de
información, y dejando el modelo listo para ser
adaptado a cualquier modelo lógico específico
Modelo Multinivel Extendido
115
Actividades
Adaptación de Paquetes de Clases
Adaptación de Paquetes de Clases
Transformación de Asociaciones Binarias
Transformación de Asociaciones Binarias
Transformación de Asociaciones N-arias
Transformación de Asociaciones N-arias
Transformación de Relaciones de Generalización
Transformación de Relaciones de Generalización
Transformación de Agregaciones
Transformación de Agregaciones
Adaptación de Restricciones de Seguridad (OSCL¬RMSCL)
Adaptación de Restricciones de Seguridad (OSCL¬RMSCL)
Transformación de Clases
Transformación de Clases
Adaptación de Tipos de Datos
Adaptación de Tipos de Datos
Diseño Lógico
Revisión del Modelo
Revisión del Modelo
116
Modelo Multinivel Extendido
- Estructura Relacional: Un conjunto de filas que
especifican las relaciones y atributos del modelo
- Metainformación: Un conjunto de filas que
especifican los tipos de datos y la información de
seguridad relativa a los elementos que han sido
definidos en el componente anterior
- Restricciones: Un conjunto de restricciones
especificados mediante el lenguaje RMSCL
Objetivos
Poder especificar mediante un modelo lógico, la
información relacional, la información de
clasificación y las restricciones de seguridad
Componentes del
Modelo
117
Diseño Lógico Específico (Oracle9i Label Security)
Actividades
Definir Esquema de la Base de Datos
Definir Esquema de la Base de Datos
Crear Usuarios Autorizados y asignarles información de
autorización y privilegios
Crear Usuarios Autorizados y asignarles información de
autorización y privilegios
Definir funciones de etiquetado para asignar información de
sensibilidad en las tablas
Definir funciones de etiquetado para asignar información de
sensibilidad en las tablas
Definir funciones de etiquetado y predicados para
implementar las restricciones de seguridad
Definir funciones de etiquetado y predicados para
implementar las restricciones de seguridad
Especificar operaciones y controlar su seguridad
Especificar operaciones y controlar su seguridad
Definir Niveles y Grupos Válidos en la Política
Definir Niveles y Grupos Válidos en la Política
Crear la Política de Seguridad y sus Opciones por defecto
Crear la Política de Seguridad y sus Opciones por defecto
118
Permite definir niveles de seguridad y la jerarquía
de roles de usuario
Crear y gestionar el modelo de casos de uso
extendido
Crear y gestionar el modelo de clases extendido
Especificar restricciones de seguridad
Comprobar automáticamente las restricciones
inherentes
Fácil de aprender
Objetivo
general
Características
Dar soporte automatizado a la metodología,
haciendo posible la creación y gestión de los
modelos más importantes
Prototipo de Herramienta CASE
119
120
121
122
123
Centro de Procesamiento de Datos de la
Excelentísima Diputación de Ciudad Real
Sistema para la Gestión Contable
Problemas de Confidencialidad
Se gestionan datos personales y económicos
124
Seguridad en Modelos Multidimensionales
Actions := action (logicalOperator action)*
Action := ”READ”
c)
Objects := objectIdentifier objectExpression
objectIdentifier := (“CL” className) | (“ATT” className”.”attributeName)
objectExpression := (“COND” OCLExpression)*
b)
Subjects := subjectIdentification subjectExpression
subjectIdentification := subjectIdentifier (logicalOperator
subjectIdentifier)*
subjectIdentifier := (“ALLSUBJECTS” | “ID” userID) | (“RID” roleID) |
(“CID” compartmentID) | (“SL” securityLevel)
logicalOperator := “AND” | “OR”
subjectExpression := (“COND“ OCLExpression)*
a)
125
AR := “OBJECTS” Objects “LOGTYPE” logType “LOGINFO” logInformation
logType := “none” | “all” | “frustratedAttempts” | “successfulAttempts”
logInformation := subjectID? objectID? action? Time? response?
f)
AUR := “SUBJECTS” Subjects “OBJECTS” Objects “ACTIONS” Actions “SIGN” Sign
(“INVCLASSES” involvedClasses)?
Sign := “+” | “-“
e)
SIAR := “OBJECTS” Objects (“INVCLASSES” involvedClasses)?
(“SECINF” securityInformation | “COND” conditionAssignment)
involvedClasses := Objects (logicalOperator Objects)*
securityInformation := (“SL” securityLevel)? (“SR” userRole+)? (“SC”
userCompartment+)?
conditionAssignment := “IF” booleanExpression
“THEN” (securityInformation |
conditionAssignment)
(“ELSE” (securityInformation |
conditionAssignment) )? “ENDIF”
d)
126
Year
(OID,D) number
Province
(OID) code
(D) name
population
State
(OID,D) name
population
1..*
1
1..*
Quarter
(OID,D) number
1
1..*
1
1..*
City
(OID) code
(D) name
population
1
1..* 1..*
Area
(OID) name
population
1..*
1..* 1..*
Month
(OID) number
(D) nameOfMonth
1
1..*
1
1..*
Patient
(OID) ssn
(D) name
dateOfBirth
address
1
1..*
1
1..*
1..*
1..*
1..*
Time
(OID,D) date
dayOfYear
vacation
bigEvent
1
1..* 1..*
Admission
type
cost
income
/ benefit
0..* 0..*
1
0..*
1
+ValidFrom
0..*
1
0..*
1
+ValidTo
0..*
1
Diagnosis_Group
(OID) code
(D) description
Diagnosis
(OID) codeDiagnosis
(D) description
healthArea
validFrom
validTo
0..*
1
0..*
1
1
1..*
{Completeness}
benefit = income - cost
127
OBJECTS CL Diagnosis_group SECINF SL
Confidential
SIAR 6
OBJECTS ATT Patient.address SECINF SR Admin
SIAR 5
OBJECTS CL Patient SECINF SL Secret SR (Health,
Admin)
SIAR 4
OBJECTS CL Diagnosis SECINF SL Secret SR Health
SIAR 3
OBJECTS ATT Admission.cost SECINF SR Admin
SIAR 2
OBJECTS CL Admission SECINF SL Secret SR
(Health, Admin)
SIAR 1
128
OBJECTS CL Admission INVCLASSES CL Patient COND IF
self.cost>10000 THEN SL topSecret ELSE SL Secret ENDIF
SIAR 9
OBJECTS CL Admission INVCLASSES CL Diagnosis AND CL
Diagnosis_group AND CL Patient COND IF
self.Diagnosis.Diagnosis_group.description=’Cancer’ or
self.Disgnosis.Diagnosis_group.description=’AIDS’ THEN SL
topSecret ELSE SL Secret ENDIF
SIAR 8
OBJECTS CL City SECINF SL Confidential
SIAR 7
129
OBJECTS CL Admission LOGTYPE frustratedAttempts
LOGINFO subjectID ObjectID time
AR 1
SUBJECTS ALLSUBJECTS COND userProfile.name=self.name
OBJECTS CL Patient ACTION READ SIGN +
AUR 2
SUBJECTS RID Health COND
userProfile.workingArea<>self.diagnosis.healthArea OBJECTS
CL Admission ACTION READ SIGN – INVCLASSES CL
Diagnosis AND CL Diagnosis_group AND CL Patient
AUR 1
130
City {SL=C}
(OID) code
population
{D} name
Patient {SL=S; SR=Health, Admin}
(OID) ssn
(D) name
dateOfBirth
address {SR = Admin}
1
1..*
Admission {SL=S; SR=Health, Admin}
type
cost {SR = Admin}
0..* 0..*
1
Diagnosis_group {SL=C}
(OID) code
(D) description
Diagnosis {SL=S; SR=Health}
0..* 0..*
1
1
1..*
{exceptSign = +}
{exceptCond = (self.name =
UserProfile.name)}
{logType = frustratedAttempts}
{logInfo = subjectId, objectID,
time}
{involvedClasses = (Diagnosis , Diagnosis_group & Patient)}
self.SL = (If self.Diagnosis.Diagnosis_group.description =
"cancer" or self.Diagnosis.Diagnosis_group.description= "AIDS"
then TS else S )
UserProfile
userCode
name
securityLevel
securityRoles
citizenship
hospital
workingArea
dateContract
<<UserProfile>>
{involvedClasses= (Diagnosis,
Diagnosis_group & Patient}
Self.SR = {Health}
{exceptSign = -}
{exceptCond = (self.diagnosis.healthArea
<> userProfile.workingArea)}
{involvedClasses= (Patient)}
self.SL = (if self.cost>10000 then TS
else S)
4
1
2
3
5
(OID) codeDiagnosis
(D) description
healthArea
validFrom
validTo
131
Campo de Investigación muy amplio:
Campo de Investigación muy amplio:
• Access control
• Anonymity
• Authentication
• Data integrity
• Formal methods in security
• Information flow control
• System security
• Digital rights management
• Cryptography
• Covert channels
• Cybercrime
• Denial of service attacks
• Firewalls
• Inference control
• Steganography
• Transaction management
• Data and application security
• Intellectual property protection
• Language-based security
• Privacy-enhancing technology
• Trustworthy user devices
• Identity management
• Security and quality of service
• Secure electronic commerce
• Security administration
• Security management
• Security models
• Security requirements engineering
• Survivability
• Information dissemination control
132
Campo de Investigación muy amplio:
Campo de Investigación muy amplio:
• Audit
• Biometrics
• Certification and accreditation
• Database Security
• Enterprise security
• Mobile security
• Operating system security
• Privacy
• Web application security
• Knowledge discovery and
privacy
• Concurrency control
• Methodologies for security
information systems development
• Personal data protection
• Database security
• Data warehouses security
• Standards for information system
security
• Metadata for web and multmedia
security
• Etc.
• Etc.
133
Contenido de la Presentación
•Introducción
•Técnicas de Control de Acceso
•Modelos de Seguridad en Bases de Datos
•Tecnología en Bases de Datos Seguras
•Diseño de Bases de Datos Seguras
•Ejercicio de diseño e implementación
•Conclusiones
•Bibliografía
134
Ejercicio de diseño e implementación
Considerando información de tu entorno (tu empresa, o entidad, o
datos de algún proyecto desarrollado) que resulte sensible desde en
punto de vista de la confidencialidad, realiza un modelado
conceptual de una pequeña base de datos, distinguiendo claramente
las clases de acceso de los datos (en el modelo conceptual) y de los
usuarios (mediante algún árbol que represente la jerarquía de
usuarios). Recordar que hay algo que enlaza directamente con el
enfoque obligatorio (basado en niveles de seguridad), que es el
Reglamento de Medidas de Seguridad sobre Datos de Carácter
Personal.
Para el modelo conceptual puedes utilizar el modelo entidad-
interrelación o el modelo de clases, incluyendo de alguna forma
gráfica intuitiva la clasificación de la información.
Eduardo.FdezMedina@uclm.es
135
Contenido de la Presentación
•Introducción
•Técnicas de Control de Acceso
•Modelos de Seguridad en Bases de Datos
•Tecnología en Bases de Datos Seguras
•Diseño de Bases de Datos Seguras
•Ejercicio de diseño e implementación
•Conclusiones
•Bibliografía
136
Conclusiones
• Importancia de la Seguridad en Bases de Datos
• Necesidad de Métodos de Diseño
• Aplicación a otras tecnologías
× Bases de Datos Multimedia
× Bibliotecas Digitales
× Almacenes de Datos
137
Contenido de la Presentación
•Introducción
•Técnicas de Control de Acceso
•Modelos de Seguridad en Bases de Datos
•Tecnología en Bases de Datos Seguras
•Diseño de Bases de Datos Seguras
•Ejercicio de diseño e implementación
•Conclusiones
•Bibliografía
138
Bibliografía
• Castano, S., Fugini, M., Martella, G. y Samarati, P. (1994). Database
Security. Addison-Wesley.
• Fernández-Medina, E., Piattini, M. y Serrano, M. A. (2001). Seguridad
en Bases de Datos. Fundación Dintel, Madrid.
• Fernández-Medina, E. y Piattini, M. (2002). Una Metodología para
Diseñar Bases de Datos Seguras Implementadas en Oracle9i Label
Security. Cuore, Vivat Academia. Nº 3. Noviembre.
• Fernández-Medina, E., Moya, R. y Piattini, M. (2003). Seguridad en
TI. La Construcción para una Sociedad Conectada. AENOR. Madrid.
• Piattini, M. y Fernández-Medina, E. (2001). Specification of Security
Constraints in UML. Actas del 35
th
Annual 2001 IEEE International
Carnahan Conference on Security Technology (ICCST 2001), páginas
163-171. Octubre de 2001. Londres (Reino Unido).
139
SEGURIDAD EN EL DISEÑO
DE BASES DE DATOS Y
SISTEMAS DE
INFORMACIÓN
Dr. Eduardo Fernández-Medina
Grupo de Investigación Alarcos
Escuela Superior de Informática de Ciudad Real
Universidad de Castilla-La Mancha
Eduardo.FdezMedina@uclm.es