CSI Tema4

1
SEGURIDAD EN EL DISEO
DE BASES DE DATOS Y
SISTEMAS DE
INFORMACIN
Dr. Eduardo Fernndez-Medina
Grupo de Investigacin Alarcos
Escuela Superior de Informtica de Ciudad Real
Universidad de Castilla-La Mancha
Eduardo.FdezMedina@uclm.es
2
Contenido de la Presentacin
Introduccin
Tcnicas de Control de Acceso
Modelos de Seguridad en Bases de Datos
Tecnologa en Bases de Datos Seguras
Diseo de Bases de Datos Seguras
Ejercicio de diseo e implementacin
Conclusiones
Bibliografa
3
Introduccin
Conclusiones
Bibliografa
4
Las bases de datos almacenan informacin
importante en todos los mbitos: comerciales,
militares, mdicos, administrativos, judiciales, etc.,
etc.
La informacin ha pasado a ser el activo ms
importante de las organizaciones, por encima incluso
de los activos tradicionales (econmicos, humanos y
materias primas).
Adems, hay datos especiales (personales) que estn
protegidos por leyes en casi todos los pases.
5
Calidad del Software
Usabilidad
Eficiencia
Fiabilidad
Mantenibilidad
Funcionalidad
Portabilidad
ISO 9126
Seguridad
6
LEGALES
ORGANIZATIVAS
FSICAS
COMUNICACIONES
Seguridad en Bases de Datos
7
Seguridad es la capacidad de un producto
software de proteger los datos y la informacin
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 informacin. En
general la Confidencialidad se refiere a la
proteccin de datos implicados en entornos
altamente protegidos, como entornos militares,
comerciales, etc. Privacidad se refiere a
informacin sobre individuos. En la mayora de
los pases la Privacidad est protegida por las
leyes.
9
Integridad: prevenir / detectar / impedir la modificacin
inadecuada de informacin. 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 organizacin 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 semntica: 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 denegacin 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.
Tambin relacionada con los
mecanismos de recuperacin de la base de
datos ante cadas del sistema.
11
La proteccin de bases de datos puede obtenerse a
travs de medidas de seguridad para:
-Control del flujo de informacin
-Control de inferencia
-Control de acceso a la informacin
Para estos controles, las tcnicas criptogrficas
pueden ayudar, pero no resuelven el problema.
12
Control de Flujo:
Regula la distribucin de informacin 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
informacin no se controla puede dar lugar a
situaciones de prdida de confidencialidad o
privacidad.
El problema se acenta con polticas de control
de acceso discrecionales y obligatorias.
13
Ejemplo de Control de Flujo:
Dados dos usuarios, U1 y U2, y dos recursos de
informacin R1 y R2, un problema de control de flujo
se producira por ejemplo cuando un usuario U1 accede
a un recurso R1 (para el que U1 tiene acceso y U2 no),
y escribe cierta informacin de R1 en el recurso R2,
para el que U2 tiene acceso.
El problema es que ha habido un flujo de informacin
que le permite a un usuario acceder a informacin para
la que en condiciones normales no estara autorizado.
14
Control de Inferencia:
Trata de proteger los datos de descubrimientos
indirectos de informacin. 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-instanciacin.
-Inferencia de informacin en base a los datos
que son accesibles:
-Saber el salario de los individuos teniendo
acceso a la categora 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-instanciacin)
Datos correlacionados. Ejemplo: z=t*k. Si t y k son visibles, y z
no es visible, el valor de z puede ser inferido fcilmente. Saber el
salario de los individuos teniendo acceso a la categora
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 informacin
confidencial: Clasificar datos en una base de datos de acuerdo a
rangos concretos. Los usuarios, analizando la informacin
pueden inferir esos rangos de acuerdo a la informacin que
pueden ver.
17
El problema de la inferencia estadstica
Implica la deduccin de datos. Las bases de datos estadsticas
permiten la consulta de datos estadsticos sobre grupos de
individuos. En esas bases de datos, el acceso a datos sobre
individuos individuales no est permitido, puesto que los
datos son slo accesibles a travs de funciones estadsticas.
Sin embargo, analizando datos estadsticos 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
estadsticas que podran revelar al usuario informacin
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 polticas de
proteccin definidas.
19
Deficiencias en la seguridad pueden generar
diferentes tipos de problemas:
Prdidas econmicas
Prdidas de imagen
Prdida de clientes
Problemas legales
Empresas
Individuos
Privacidad
20
Cambios que se producirn en la Sociedad de la Informacin durante el perodo
2001-2005 (Telefnica, 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
Promocin de asociaciones
Participacin en decisiones polticas
Libertad
Intimidad
Generacin de riqueza
Disponibilidad de tiempo
Dif erencias econmicas
Desarrollo de seas 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 ormacin
Acceso a la educacin
Vasectoma
21
Importancia de la regulacin de aspectos de la Sociedad de la Informacin
durante el perodo de 2001-2005 (Telefnica, 2001)
Importancia: Menos Ms
. . _ _
Valor jurdico de
documentos electrnicos
Responsabilidad civil
Registro de nombres de
dominios Internet
Proteccin de datos
personales
Nuevas condiciones
laborales
Lmites legales
nacionales
Fiscalidad
Derechos de propiedad
intelectual
Contenidos
potencialmente nocivos
22
Amenazas contra la seguridad en la informacin (mbito internacional) (Ernst &
Young, 1998)
Amenaza Para la Seguridad de la Informacin
(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 ormticos
1997
1998
23
Desafos 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 Direccin
Presupuesto
Disponibilidad de Personal Apropiado
Herramientas o Soluciones de Seguridad
Concienciacin de los Empleados
24
En relacin con la proteccin de datos personales:
1992 LORTAD
Junio 1999 Reglamento de Seguridad
Diciembre 1999 Nueva Ley de
Proteccin de Datos Personales
Diversos autores (en varios foros) reclaman la
integracin de seguridad en el proceso de desarrollo
de software (IEEE Software, Vol 19, N 1, 2002)
Seguridad es considerada en alguno de los ms
importantes SGBDs (Oracle9i Label Security)
Europa
Espaa
1995 Directiva Europea 95/46/CE
25
Introduccin
Conclusiones
Bibliografa
26
Es el mecanismo a travs del que intentamos
asegurar que solamente los sujetos autorizados
pueden acceder a los recursos del sistema de
informacin.
Regla de Autorizacin = <sujeto, objeto, privilegio>
27
28
<s,o,p>
OBJETOS DE AUTORIZACIN
- FICHEROS Y DIRECTORIOS
- RELACIONES, VISTAS, ATRIBUTOS
- CLASES, JERARQUAS DE CLASES
29
<s,o,p>
SUJETOS DE AUTORIZACIN
- USUARIOS
- GRUPOS DE USUARIOS
- ROLES
- PROCESOS
30
<s,o,p>
PRIVILEGIOS DE AUTORIZACIN
- LEER, ESCRIBIR, EJECUTAR
- SELECCIONAR, INSERTAR, ACTUALIZAR,
REFERENCIAR, INDEXAR
31
Las polticas de control de acceso se pueden clasificar en dos grupos:
Cerradas: Solamente los accesos autorizados
explcitamente son permitidos
32
Abiertas: Los accesos que no son explcitamente
prohibidos son permitidos.
33
Tipos de polticas de control de acceso
Discrecional
Obligatorio
Basado en Roles
Basado en Tareas
Basado en Restricciones
34
POLTICA DE CONTROL DE ACCESO DISCRECIONAL
Acceso basado en la identidad de los sujetos y en reglas de autorizacin 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 informacin
35
La implementacin de esas matrices conceptuales, tradicionalmente se ha llevado
a cabo a travs de tres enfoques:
Tabla de autorizacin
36
Lista de control de acceso
Capacidades
37
Existen muchas variantes de esta poltica de control de acceso:
+POSITIVA / NEGATIVA
Segn la autorizacin positiva, la existencia de la regla de
autorizacin indica que se puede realizar el acceso, mientras que la no
existencia de la misma prohbe el acceso.
En cambio mediante la autorizacin negativa, el acceso se
permite slo cuando no existe una regla de autorizacin negativa, mientras
que la existencia de la regla prohbe el acceso.
La principal diferencia es que en el caso de autorizacin positiva,
si un sujeto no tiene autorizacin, en algn momento se puede producir
una propagacin de privilegios de tal forma que otro sujeto le ceda el
acceso, en cuyo caso estara burlando el control de acceso. Eso no puede
suceder con el mecanismo de autorizacin negativa.
38
Existen muchas variantes de esta poltica de control de acceso:
+FUERTE / DBIL
Autorizaciones fuertes, tanto positivas como negativas son
aquellas que no pueden ser invalidadas, mientras que las dbiles s pueden
ser invalidadas por otras autorizaciones fuertes o dbiles, de acuerdo a
unas reglas especficas.
+EXPLCITA / IMPLCITA
Las autorizaciones implcitas son automticamente derivadas
por el sistema desde el conjunto de autorizaciones explcitas, de acuerdo
a un conjunto de reglas. Por ejemplo, una autorizacin implcita podra
ser aquella que expresa que un sujeto puede acceder a un objeto dado
slo si otro sujeto tiene un acceso explcito denegado.
39
Las bases de datos que utilizan esta poltica 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 organizacin, Juan es un gerente de alto nivel que crea un
fichero llamado Ventas, que contiene informacin muy
importante para la organizacin. Esta informacin, es muy
sensible, y de acuerdo con la poltica de la organizacin debera ser
protegida ante cualquier acceso no autorizado. Consideremos
ahora a Jos, que es uno de los subordinados de Juan, que quiere
descubrir la informacin almacenada en el fichero Ventas.
40
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. Adems, Jos
modifica una aplicacin que generalmente es usada por Juan,
incluyendo dos operaciones ocultas, una operacin de lectura
sobre el fichero Ventas y una operacin de escritura sobre el
fichero Ilegal. Supongamos ahora que Juan ejecuta ahora la
aplicacin. Puesto que la aplicacin 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 ejecucin de esa
aplicacin, informacin sensible ha sido transferida del fichero
Ventas al fichero Ilegal, y est disponible ahora para Jos.
41
42
43
POLTICA DE CONTROL DE ACCESO OBLIGATORIO
Consiste en la clasificacin de tanto los sujetos como los objetos en el
sistema en clases de acceso que determinan sus caractersticas 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 categoras.
Cada nivel de seguridad es un elemento de un conjunto jerrquicamente
ordenado como alto secreto (TS), secreto (S), confidencial (C) y sin
clasificar (U), donde TS > S > C > U.
El conjunto de categoras es un subconjunto de un conjunto desordenado,
donde los elementos pueden reflejar reas funcionales o diferentes
competencias como por ejemplo finanzas, administracin, ventas y
compras para sistemas comerciales
44
El orden parcial es definido por una relacin de dominio que se
denota con .
La relacin de dominio es definida de la siguiente forma: una
clase de acceso C1 domina () a otra clase de acceso C2 si y slo
si el nivel de seguridad de C1 es mayor o igual que el de C2 y las
categoras de C1 incluyen las de C2.
TS,
S,{
45
Esta poltica est basada en el Modelo de Bell-La Padula:
El objetivo principal es garantizar la confidencialidad de la
informacin, 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
Si la escritura fuese hacia abajo podra existir flujo de
informacin inadecuado. Un usuario con nivel Confidencial
tendra acceso a la informacin almacenada por un usuario con
nivel Alto Secreto
D
o
m
i
n
a
n
c
e
47
Por la regla de No-Escritura-Hacia-Abajo, sera 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 distincin 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 peticin, la
clase de acceso que se considera es la del sujeto generado al
conectarse al sistema.
48
Si no se cumplen las dos reglas de acceso se podran producir
situaciones como la siguiente:
En una organizacin, Juan es un gerente con un nivel de seguridad
secreto, que crea un fichero llamado Ventas, que tambin tiene
un nivel de seguridad secreto y que contiene informacin muy
importante para la organizacin.
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 informacin almacenada en el fichero Ventas.
49
Para conseguirlo, Jos crea otro fichero, llamado Ilegal con un
nivel de seguridad sin clasificar y modifica una aplicacin que
generalmente es usada por Juan, incluyendo dos operaciones ocultas,
una operacin de lectura sobre el fichero Ventas y una operacin
de escritura sobre el fichero Ilegal.
Supongamos ahora que Juan ejecuta ahora la aplicacin. Si Juan se
ha conectado con el nivel secreto, y el principio de acceso de
escritura no se cumple, tanto la operacin de lectura como la de
escritura se llevaran a cabo y se estara descubriendo informacin
sensible, pero si el principio de acceso de escritura se cumple, la
operacin de lectura ser realizada, pero al intentar realizar la
operacin de escritura el sistema avisara 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 Mara SC Dep2 SC 10 SC SC Mara SC Dep2 SC 10 SC
S Jos S Dep1 S 40 S SC Ivn SC Dep1 SC - SC
SC Ivn SC Dep1 SC 30 S
(a) Relacin Multinivel

(b) Vista de un sujeto de nivel Sin Clasificar

51
Esta clasificacin de informacin trae consigo una serie de
problemas importantes. El principal es el conocido como Poli-
instanciacin o Poli-instauracin.
El problema viene debido a la necesidad de coexistir en el sistema
de mltiples 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 mximo 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
Si el sistema da un mensaje de error, estara proporcionando
informacin confidencial a un usuario no autorizado.
El sistema por el contrario lo que tendra que hacer es permitir que
este usuario cree esa tupla, en cuyo caso, existiran 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.
Adems, tambin habr que pagar el coste de gestionar tuplas
repetidas.
La poli-instanciacin es el principal motivo del xito limitado
de las bases de datos seguras en el entorno comercial
53
Aunque esta poltica de control de acceso ofrece proteccin frente a
prdidas de informacin, no garantiza una completa confidencialidad
de la informacin. De hecho es muy complicado controlar la no
existencia de canales ocultos.
Por ejemplo, si un usuario sin clasificar escribe una informacin en
nivel secreto (aceptado por la regla de escritura), y se produce un
error por el que el sistema le informa, estaramos de nuevo en un
caso de descubrimiento de informacin confidencial.
54
POLTICA DE CONTROL DE ACCESO BASADA EN ROLES
Esta poltica regula el control de acceso de usuarios a la
informacin, 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
56
Esta poltica ofrece un conjunto de ventajas:
Gestin de autorizaciones: Hay una independencia
lgica entre la actividad de asignar roles a usuarios y
asignar privilegios de acceso a los roles. Esto facilita
mucho la gestin.
Jerarqua de roles: En muchas aplicaciones hay una
jerarqua natural de roles, basadas en los principio bien
conocidos de generalizacin y especializacin. Esto puede
dar lugar a autorizaciones implcitas como por ejemplo:
El secretario o secretaria hereda todos los permisos del
personal de administracin.
57
58
Privilegios mnimos: Los roles permiten que un usuario tenga los
privilegios estrictamente necesarios para realizar una tarea
particular. Esto minimiza los peligros de dao debido a un exceso de
privilegios.
Separacin de responsabilidades: Se refiere al principio de que
ningn usuario debera 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
especificacin de requisitos de proteccin que pueden ser necesarias
en las situaciones reales. Ejemplo: nmero mximo de usuarios en un
rol, etc.
59
Constraints
60
Introduccin
Conclusiones
Bibliografa
61
El objetivo de los modelos de seguridad es producir un modelo
conceptual de alto nivel, independiente del software que describa las
necesidades de proteccin del sistema.
Un modelo de seguridad proporciona lo siguiente:
Una representacin semntica de las propiedades de
seguridad del sistema.
La facilidad a los desarrolladores de dar una definicin de
alto nivel de los requisitos de proteccin y las polticas del
sistema, describiendo de manera precisa el comportamiento
del sistema
Demostrar que el sistema satisface algunas propiedades de
seguridad.
62
Han sido propuestos un gran nmero de modelos de seguridad, y en
general se podran clasificar en dos categoras:
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 poltica (Discrecional, Obligatoria)
Enfoque de la poltica (confidencialidad / integridad)
Tipo de control (acceso directo /acceso indirecto de
informacin)
63
64
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
informacin 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 informacin desde el objeto al sujeto
y/o desde el sujeto al objeto.
65
Polticas: Son las leyes que orquestan el control de acceso.
Generalmente de alto nivel.
Autorizaciones: Definen qu accesos podrn realizar los
usuarios sobre los objetos y qu otros no.
Permisos administrativos (implementadas por primitivas como
grant, revoke, own): permiten la modificacin de
autorizaciones: En sistemas discrecionales, la posesin de
privilegios de administracin 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
autorizacin es definido utilizando una matriz que relaciona
sujetos, objetos y las autorizaciones de cada sujeto sobre cada
objeto.
Estados de autorizacin
68
El estado de autorizacin 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 tambin son vistos como objetos). Por lo tanto O
S. En SO: ficheros, memoria, segmentos, procesos. En Bases de
Datos: base de datos, relacin, 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.
69
En la aplicacin de este modelo a las bases de datos, en la
especificacin de autorizaciones, se pueden incluir condiciones que
deben ser satisfechas para que el sujeto utilice el objeto. Consistira
en incluir en las posiciones de la matriz reglas de decisin que
especifiquen determinadas condiciones.
70
Algunas de estas condiciones pueden ser:
Dependientes de datos: Un sujeto s puede estar autorizado a
leer de una tabla Empleado slo aquellos empleados cuyo
salario es >= 1000.
Dependientes del tiempo: Un sujeto puede estar autorizado
para leer de la tabla Empleado slo 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 ningn
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
Modos de Acceso
El modo de acceso depende del tipo de objetos considerados.
Habitualmente son los privilegios de lectura, escritura, append,
ejecucin 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 travs de un conjunto
de comandos que sern una secuencia de operaciones primitivas
que permiten modificar la matriz de accesos:
Operaciones
72
73
Comandos
Los comandos estn formados por dos partes, una de condicin y otra
de accin. 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
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
La inclusin 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).
Detrs de estas palabras se esconden unas teoras y especificaciones
relativamente complejas. Por ejemplo, es posible especificar comandos que
mediante la utilizacin de operaciones primitivas se exprese la gestin en la
administracin de autorizaciones.
Administracin de Autorizaciones
76
No es viable utilizar una matriz
rectangular debido al enorme
espacio necesario. Por lo que se
escoge entre alguna de estas
soluciones:
Implementacin 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 propagacin de privilegios
(creando arcos que representan propagacin de privilegios, etc.).
Action-Entity: Considera un conjunto mucho ms rico de
privilegios de administracin y da soporte a predicados en las
autorizaciones.
Wood y otros: Especialmente dirigido a la proteccin de
informacin en bases de datos basado en la arquitectura de tres
niveles de abstraccin ANSI/SPARC, y considerando el problema de
autorizaciones en esquemas relacionales multidimensionales. Est
basado en reglas de derivacin 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 informacin 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 informacin.
Precisamente, preserva la integridad evitando que existan flujos de
informacin 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-
instanciacin
79
Introduccin
Conclusiones
Bibliografa
80
Prototipos de Bases de Datos Seguras
Casi todas las marcas comerciales han desarrollado algn
prototipo para implementar bases de datos seguras, pero sin tener
ninguna repercusin 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
versin 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 polticas de seguridad OLS
82
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 funcin
del nivel de sensibilidad del dato y del nivel de
habilitacin del usuario.
Discrecional Mediante poltica de privilegios
Obligatoria Mediante control de etiquetas
83
Componentes de las Etiquetas de Datos.
Informacin del nivel de sensibilidad de la informacin.
Distintas categoras organizacionales de informacin.
Distintos grupos jerrquicos de informacin.
Toda esta informacin se almacena codificada en una columna de
datos en cada tabla.
84
El nivel de seguridad es un elemento que permite denotar la
sensibilidad de la informacin etiquetada. La informacin ser ms
sensible a medida que el nivel de seguridad sea ms alto.
Forma
numrica Forma larga
Forma
Corta
40
Alta Sensibilidad AS
30 Sensible S
20 Confidencial C
10 Pblico P
OLS define para cada nivel de
seguridad varios elementos que
ayudan a manejar este concepto de
manera ms cmoda, como por
ejemplo una forma numrica 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 descripcin
completa del nivel, y la forma
corta para trabajar con ms
agilidad.
85
Las categoras son opcionales,
y puede haber cero, una o
varias en la definicin de una
etiqueta.
En el caso de las categoras, la
forma numrica no denotar
ningn tipo de ordenacin.
Forma
numrica Forma larga
Forma
Corta
40
Financiera FIN
30 Qumica QUIM
20 Operacional OPER
Las categoras 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 categora.
86
Los grupos identifican una relacin de posesin o de acceso a los datos.
Todos los datos pertenecientes a un cierto departamento podrn tener el
grupo de dicho departamento en su etiqueta. Los grupos son tiles para
controlar la diseminacin de datos y para oportunas reacciones de
cambios organizacionales. Cuando una compaa se reorganiza, el
control de acceso puede cambiar con la reorganizacin.
Regin de
Madrid
Madrid
Ventas
Madrid
Recursos
Humanos
Madrid
Finanzas
Madrid
Facturas a
Cobrar
Madrid
Facturas a
Pagar
Los grupos podrn ser
jerrquicos, es decir, se
podrn definir un
conjunto de grupos
correspondientes a una
jerarqua organizacional
como este ejemplo.
87
Para un caso como el anterior, el administrador de la base de datos creara
una estructura con el contenido siguiente.
Forma
numrica
Forma larga Forma Corta Padre
1000 Regin 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 Categoras Grupos
Defensa
Alto Secreto
Secreto
Confidencial
Sin Clasificar
Alfa
Delta
Sigma
Reino Unido
OTAN
Espaa
Servicios
Financieros
Adquisiciones
Empresa
Cliente
Operaciones
Seguros
Activos
Obligaciones
Prstamos Comerciales
Prstamos al Consumo
Clientes
Administradores
Beneficiarios
Gestin
Personal
Justicia
Seguridad Nacional
Sensible
Pblico
Civil
Criminal
Administracin
Defensa
Acusacin
Juzgado
Salud
Mdico
Paciente Confidencial
Paciente Pblico
Farmacutica
Enfermedades Infecciosas
Cuidados Intensivos
Investigacin
Personal de Enfermera
Personal de Hospital
Negocios
Negocio Secreto
Propietario
Compaa Confidencial
Pblico
Mercado
Finanzas
Ventas
Personal
Empresa 1
Empresa 2
Empresa 3
Empresa 4
89
Componentes de las Etiquetas de Usuarios.
Un usuario slo puede acceder a los datos que estn en su rango
de autorizacin. Para ello, en las etiquetas de los usuarios se
almacena la siguiente informacin:
Un nivel mximo, uno mnimo y otro de la sesin.
Un conjunto de categoras autorizadas.
Un conjunto de grupos autorizados. De lectura, de escritura y
por defecto. Evidentemente, de manera implcita quedaran
incluidos los grupos heredados de los grupos explcitos
registrados en este lugar.
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
Usuario 1 no puede acceder a la Fila 1
porque no tiene acceso a la categora de
Qumica. Para tener acceso a esta fila, el
usuario debera de tener un nivel de
seguridad igual o superior al nivel de
seguridad del dato, debera incluir todas
las categoras que tiene el dato, y debera
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
categora Qumica y porque no est
autorizado a acceder a la
informacin del grupo RM (Regin
de Madrid)
91
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 sesin 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 categoras que
incluya el dato.
Si la etiqueta del usuario cumple estas condiciones, entonces se
dir que domina a la etiqueta de la fila.
92
Para determinar si un usuario puede escribir en una determinada
fila de datos, OLS evala las siguientes reglas y en el siguiente
orden:
El nivel en los datos debe ser mayor o igual que el mnimo nivel
del usuario y menor o igual que el nivel de la sesin 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). Adems la
etiqueta del usuario debe incluir todas las categoras de la etiqueta
del dato.
Cuando no hay grupos, la etiqueta del usuario debe tener acceso
de escritura a todas las categoras 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
POLTICA DE SEGURIDAD
Nombre de Poltica
Nombre de Columna de Etiquetas
Niveles de Sensibilidad de la
Poltica
Categoras de la Poltica
Grupos de la Poltica
Datos de Acreditacin:
Nivel del Usuario: Maximo,
Mnimo, por Defecto, de Fila
Categoras 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
Definicin
de datos de acreditacin
del usuario
Definicin de privilegios
del usuario
Cdigo en PL/SQL
Unidades de
Programacin
Nombre de la Unidad
de Programacin
Privilegios otorgados:
READ, FULL, COMPACCESS,
PROFILE_ACCESS, WRITEUP,
WRITEDOWN, WRITEACROSS
FUNCIONES DE
ETIQUETADO
PREDICADOS
OPCIONES DE
SEGURIDAD
PARTICULARES
Asignacin
de Privilegios a
Unidades de
Programacin
Ejecucin de
Unidades de
Programacin
Aplicacin
de una
Poltica
a un
Esquema
Ejecucin de
Operaciones directas
del Usuario sobre
las Tablas
Aplicacin de
una Poltica
a una Tabla
94
OLS permite lo siguiente (a nivel de administracin):
Lnea de comandos y herramienta visual
Polticas de seguridad
Valores de seguridad (niveles, categoras y grupos) para cada poltica
Usuarios y su informacin de autorizacin y privilegios
Opciones por defecto en las polticas
Funciones de etiquetado y predicados
Aplicar polticas de seguridad a tablas y a esquemas
Seguridad de programas almacenados
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)
96
SET_LEVELS(SecurityPolicy, User1, T, S, S)
SET_GROUPS(SecurityPolicy, User1, O, O, O)
SET_USER_PRIVS(SecurityPolicy, User1, FULL, WRITEUP,
WRITEDOWN, WRITEACROSS)
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
Begin
MyLabel := T::O ;
Return TO_LBAC_DATA_LABEL(SecurePolicy, MyLabel);
End;
98
CREATE FUNCTION Function3(Refunds: Real) Return LBACSYS.LBAC_LABEL
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)
99
Introduccin
Conclusiones
Bibliografa
100
Diseo de Seguridad en Bases de Datos (Castano et al., 1994)
Diseo Conceptual
Diseo Fsico
Diseo Lgico
Anlisis Preliminar
Requisitos y polticas
de seguridad
Mecanismos
de seguridad
Implementacin
Lenguaje de
especificacin de
requisitos de
seguridad
Modelo
conceptual de
seguridad
Modelo lgico
de seguridad
Modelo fsico
de seguridad
Tecnologa del sistema
de gestin de bases de
datos
Esquema lgico
de seguridad
Parmetros
del proyecto
101
Diseo Conceptual de Bases de Datos Seguras
Semantic Data Model for Security (Smith, 1990 and 1991)
PROFESOR
ALUMNO
DEPARTA-
MENTO
DIRECCIN
SALARIO
FECHA-INGRESO
PRESUPUESTO
DNI
CODIGO
NOMBRE
CODIGO
(S)
(C,S)
(C)
(C,S)
(C)
(C)
(C)
(C)
NOMBRE
(C)
(C)
(C)
NOMBRE
DIRECCIN
102
Multilevel Object Modeling Technique (MOMT)
Modelo de objetos multinivel
Modelo dinmico multinivel
Modelo funcional multinivel
El diseo de la base de datos no se
considera en esta metodologa
103
Principal Objetivo:
Poder construir bases de
datos seguras mediante
procesos de ingeniera
Captura de
requisitos
Anlisis de la
Base de Datos
Diseo de la
Base de Datos
lenguajes
de
restricciones
ms
aceptados
lenguajes
de
restricciones
ms
aceptados
modelo de
seguridad
modelo de
seguridad
modelos
de proceso
ms
aceptados
modelos
de proceso
ms
aceptados
estndares de
modelado ms
aceptados
estndares de
modelado ms
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 Metodologa
1. Captura de Requisitos
2. Anlisis
3. Diseo Lgico
4. Diseo Lgico Especfico
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 Informacin Permanente
Buscar Elementos de Informacin 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
Revisin de Casos de Uso
Revisin 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
Anlisis
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 informacin de acuerdo a
sus propiedades de confidencialidad y
especificando las restricciones de
seguridad necesarias
109
Anlisis
Actividades
Anlisis de la
Arquitectura
Anlisis de la
Arquitectura
Anlisis de Seguridad
Anlisis de Paquetes
Anlisis de Paquetes
Anlisis de Clases
Anlisis de Clases
Anlisis de Casos de
Uso
Anlisis de Casos de
Uso
Identificar paquetes de anlisis
Identificar clases evidentes
Identificar relaciones
Identificar clases de un CU
Revisin de Clases
Identificar Atributos
Identificar Relaciones
Revisar Atributos y Asociaciones
110
Anlisis de
Seguridad
Anlisis de
Seguridad
Especificar niveles de
seguridad
Asignar roles de usuario
Especificar restricciones
de seguridad
Analizar otras
restricciones de seguridad
Analizar seguridad en
actores
Revisin 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 jerarqua 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
Diseo Lgico
Descripcin de Relaciones
Metainformacin
Restricciones de Seguridad
Objetivos
Artefactos
Representar a travs de un modelo lgico la
informacin que ha sido recogida en la etapa
anterior de la metodologa, evitando la prdida de
informacin, y dejando el modelo listo para ser
adaptado a cualquier modelo lgico especfico
Modelo Multinivel Extendido
115
Actividades
Adaptacin de Paquetes de Clases
Adaptacin de Paquetes de Clases
Transformacin de Asociaciones Binarias
Transformacin de Asociaciones Binarias
Transformacin de Asociaciones N-arias
Transformacin de Asociaciones N-arias
Transformacin de Relaciones de Generalizacin
Transformacin de Relaciones de Generalizacin
Transformacin de Agregaciones
Transformacin de Agregaciones
Adaptacin de Restricciones de Seguridad (OSCLRMSCL)
Adaptacin de Restricciones de Seguridad (OSCLRMSCL)
Transformacin de Clases
Transformacin de Clases
Adaptacin de Tipos de Datos
Adaptacin de Tipos de Datos
Diseo Lgico
Revisin del Modelo
Revisin del Modelo
116
Modelo Multinivel Extendido
- Estructura Relacional: Un conjunto de filas que
especifican las relaciones y atributos del modelo
- Metainformacin: Un conjunto de filas que
especifican los tipos de datos y la informacin 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 lgico, la
informacin relacional, la informacin de
clasificacin y las restricciones de seguridad
Componentes del
Modelo
117
Diseo Lgico Especfico (Oracle9i Label Security)
Actividades
Definir Esquema de la Base de Datos
Definir Esquema de la Base de Datos
Crear Usuarios Autorizados y asignarles informacin de
autorizacin y privilegios
Crear Usuarios Autorizados y asignarles informacin de
autorizacin y privilegios
Definir funciones de etiquetado para asignar informacin de
sensibilidad en las tablas
Definir funciones de etiquetado para asignar informacin 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 Vlidos en la Poltica
Definir Niveles y Grupos Vlidos en la Poltica
Crear la Poltica de Seguridad y sus Opciones por defecto
Crear la Poltica de Seguridad y sus Opciones por defecto
118
Permite definir niveles de seguridad y la jerarqua
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 automticamente las restricciones
inherentes
Fcil de aprender
Objetivo
general
Caractersticas
Dar soporte automatizado a la metodologa,
haciendo posible la creacin y gestin de los
modelos ms importantes
Prototipo de Herramienta CASE
119
120
121
122
123
Centro de Procesamiento de Datos de la
Excelentsima Diputacin de Ciudad Real
Sistema para la Gestin Contable
Problemas de Confidencialidad
Se gestionan datos personales y econmicos
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 Investigacin 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
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
Introduccin
Conclusiones
Bibliografa
134
Considerando informacin de tu entorno (tu empresa, o entidad, o
datos de algn proyecto desarrollado) que resulte sensible desde en
punto de vista de la confidencialidad, realiza un modelado
conceptual de una pequea base de datos, distinguiendo claramente
las clases de acceso de los datos (en el modelo conceptual) y de los
usuarios (mediante algn rbol que represente la jerarqua 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 Carcter
Personal.
Para el modelo conceptual puedes utilizar el modelo entidad-
interrelacin o el modelo de clases, incluyendo de alguna forma
grfica intuitiva la clasificacin de la informacin.
135
Introduccin
Conclusiones
Bibliografa
136
Conclusiones
Importancia de la Seguridad en Bases de Datos
Necesidad de Mtodos de Diseo
Aplicacin a otras tecnologas
Bases de Datos Multimedia
Bibliotecas Digitales
Almacenes de Datos
137
Introduccin
Conclusiones
Bibliografa
138
Bibliografa
Castano, S., Fugini, M., Martella, G. y Samarati, P. (1994). Database
Security. Addison-Wesley.
Fernndez-Medina, E., Piattini, M. y Serrano, M. A. (2001). Seguridad
en Bases de Datos. Fundacin Dintel, Madrid.
Fernndez-Medina, E. y Piattini, M. (2002). Una Metodologa para
Disear Bases de Datos Seguras Implementadas en Oracle9i Label
Security. Cuore, Vivat Academia. N 3. Noviembre.
Fernndez-Medina, E., Moya, R. y Piattini, M. (2003). Seguridad en
TI. La Construccin para una Sociedad Conectada. AENOR. Madrid.
Piattini, M. y Fernndez-Medina, E. (2001). Specification of Security
Constraints in UML. Actas del 35
th
Annual 2001 IEEE International
Carnahan Conference on Security Technology (ICCST 2001), pginas
163-171. Octubre de 2001. Londres (Reino Unido).
139
SEGURIDAD EN EL DISEO
DE BASES DE DATOS Y
SISTEMAS DE
INFORMACIN
Dr. Eduardo Fernndez-Medina
Grupo de Investigacin Alarcos
Escuela Superior de Informtica de Ciudad Real
Universidad de Castilla-La Mancha

CSI Tema4

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CSI Tema4

Загружено:

Авторское право:

Доступные форматы

1

Вам также может понравиться