diccionario/directorio y seguridad de datos

Universidad Central de Venezuela
Facultad de Ciencias
Escuela de Computación
DICCIONARIO/DIRECTORIO Y
SEGURIDAD DE DATOS
María Gertrudis López
Centro de investigación en Sistemas de Información
CISI.
1
INDICE
INDICE ______________________________________________________________ 2
5.
Diccionario / directorio de Datos (D/D) [10] _____________________________ 3
5.1.
Sistema Diccionario / directorio (Sistema D/D) ______________________ 3
5.2.
Objetivos del Sistema D/D _______________________________________ 3
5.3.
Beneficios de un Sistema D/D_____________________________________ 3
5.4.
Clasificación de los Sistemas D/D _________________________________ 4
5.5.
Componentes funcionales de un Sistema D/D _______________________ 5
5.6.
Casos de Estudio [12]___________________________________________ 6
5.6.1.
Oracle ____________________________________________________ 6
6.
Seguridad [11] _____________________________________________________ 7
6.1.
Conceptos básicos ______________________________________________ 7
6.2.
Políticas de seguridad de base de datos_____________________________
6.2.1.
Políticas sobre la administración de seguridad _____________________
6.2.2.
Políticas para la especificación del control del acceso ______________
6.2.3.
Políticas de control de flujo de la información _____________________
6.2.4.
Políticas para asegurar el control _______________________________
7
7
8
9
9
6.3.
Modelos de seguridad de base de datos_____________________________ 9
6.3.1.
Modelo básico para el control de acceso de base de datos ____________ 9
6.3.2.
Extensiones al Modelo Básico ________________________________ 10
6.3.3.
Modelo Multinivel _________________________________________ 11
6.3.4.
Un Modelo de Flujo de Información ___________________________ 11
6.3.5.
Comparación de Modelos ____________________________________ 12
6.4.
Casos de Estudio [12]__________________________________________ 12
6.4.1.
Oracle ___________________________________________________ 12
7.
REFERENCIAS BIBLIOGRAFICAS _________________________________ 14
2
5. Diccionario / directorio de Datos (D/D) [10]
Es el lugar donde se encuentra la información acerca de la definición de los datos de una
organización tales como características de identificación, relaciones existentes, autorizaciones,
etc.
El diccionario de datos almacena información sobre los datos relativos al origen de éstos,
descripción, relación con otros datos, uso, responsabilidad y formato. Es la misma BD que
almacena “datos sobre los datos”. El diccionario de datos es una guía y contiene el mapa de la
ruta hacia la BD.
Diccionario
Directorio
Significado de los datos
Describe los atributos físicos de los datos
Aspecto lógico de los datos
¿Dónde esta almacenado el dato?
¿Qué datos están almacenados en el sistema y ¿Cómo puede ser obtenido?
que significan?
Usuarios humanos
Usuario = Componentes del sistema que se
encargan de proveer acceso a los datos
almacenados
El D/D contiene meta datos (datos acerca de los datos).
5.1. Sistema Diccionario / directorio (Sistema D/D)
•
•
•
•
Es un sistema automatizado compuesto de:
Una base de datos llamada D/D.
Procesos que generan consultas acerca de los meta datos.
Herramientas que ayudan a garantizar la seguridad, integridad, validez y acceso compartido
a los datos del D/D.
Interfaces de software que permiten a otros sistemas extraer o actualizar información del
D/D.
5.2. Objetivos del Sistema D/D
1. Coleccionar datos: Sirve como punto de control central para la descripción y especificación
de los datos. Sirve como fuente generadora de información actualizada y confiable de
cualquier entidad de datos.
El primer paso en el diseño de una BD es recabar información sobre la empresa, esto es,
acerca del uso, relaciones y significado de los datos. Al avanzar el proceso de diseño es
necesario almacenar información sobre los modelos conceptual, lógico, interno y externo, en
un lugar central. La herramienta que da la posibilidad de controlar y manejar la información
sobre los datos en las fases de diseño, implantación, operación y expansión de una BD es
llamado D/D.
2. Apoyar el análisis de datos: Provee a los analistas y diseñadores de un mecanismo para
detectar inconsistencias y redundancias en las entidades de datos.
El diseñador y el usuario deben estar convencidos de que cuando usan un término se
refieren a lo mismo. El objetivo básico de un diccionario de datos es ayudar a establecer
una comunicación efectiva entre el diseñador y los usuarios y entre usuarios.
3. Documentar datos: Produce y maneja información de definición y significado de los datos, lo
cual sirve de documentación. Puesto que la BD sirve a varios usuarios, es vital que cada
uno de ellos entienda precisamente que son los datos y que significan.
4. Estandarizar datos: Mediante el sistema D/D se establecen estándares de uso,
representación y responsabilidad de los datos.
5.3. Beneficios de un Sistema D/D
1. Permite documentar datos y programas: Los costos de desarrollo son menores debido a la
mejor documentación de las especificaciones y al más claro entendimiento de todo lo
3
2.
3.
4.
5.
implicado. Asimismo, el mantenimiento de la BD debería ser menos costoso con la ayuda de
un diccionario de datos que en un medio donde se carece de él, debido a la mejor
documentación, al análisis más rápido de los efectos de los cambios propuestos y a la mejor
comunicación entre el personal de mantenimiento y la gente que solicita los cambios.
Permite conocer las relaciones entre los programas y los elementos de datos. El diccionario
de datos hace más completa y sistemática la retención de la información sobre los datos.
Los ahorros con un sistema D/D serán mayores en un medio con un gran número de campos
de datos y relaciones.
Permite saber que información existe de los elementos de datos y donde se encuentra. El
fácil acceso a una BD como consecuencia del uso de un diccionario de datos, como la fácil
referencia de un libro haciendo uso del índice, no puede expresarse en $.
Permite saber quienes son los dueños y los usuarios de los datos. Un diccionario de datos
mejora la habilidad de crear registros de la información accedida y de las personas que lo
hicieron.
Permite establecer controles de acceso, seguridad y privacidad de la información. Debido a
que la información sobre la BD y su uso esta localizada centralmente, es más fácil para los
auditores revisar la BD y su uso.
5.4. Clasificación de los Sistemas D/D
1. De acuerdo al grado de integración con el ambiente con el que interactúa, un sistema D/D
puede ser:
• Activo: Un sistema D/D es activo con respecto a un componente de procesamiento sii
ese componente es completamente dependiente del sistema D/D para obtener sus meta
datos.
• Pasivo: Un sistema D/D es pasivo con respecto a un componente de procesamiento sii el
componente de procesamiento no depende del sistema D/D para obtener sus meta
datos. En este caso, el sistema D/D sólo registra la meta data de la organización.
• Potencialmente activo: Es cuando el sistema D/D tiene la capacidad de producir meta
data para un componente de procesamiento, pero ese componente no depende
exclusivamente de esa meta data para funcionar.
• En línea: Es cuando el sistema D/D esta directamente en línea con todas las funciones
que ejecuta el componente de procesamiento en tiempo de ejecución.
2. De acuerdo a su complejidad, un sistema D/D puede ser:
• Básico: Almacena los componentes básicos de los objetos de datos (nombre, código,
definición, descripción). Su función es listar y mantener la información de los elementos
de datos.
• Promedio: Almacena la misma información que el básico, pero además contiene: fuentes
de datos, estructuras de datos, nombre del componente de procesamiento de origen,
etc. La entrada al sistema D/D la puede tener un usuario autorizado como también
programas específicos.
• Sofisticado: Provee definición de datos precisas que reducen el tiempo de codificación
de los programadores. Incluye información de descripción de sistemas, definición y
descripción de archivos, asociaciones, generación de reportes, colección y evaluación de
estadísticas de ejecución, etc.
3. De acuerdo a su integración con el SMBD, puede ser:
• Independiente: El sistema D/D es autónomo, es decir, las actividades de manipulación,
organización, acceso y control del D/D son ejecutadas por el software del mismo sistema
D/D, por lo que es independiente de cualquier SMBD, y lo que da la capacidad de
interactuar con varios de ellos.
• Aplicación de un SMBD: El D/D es para el SMBD otra BD más sometida a su control. En
este caso el sistema D/D puede interactuar dinámicamente con el SMBD del cual es
aplicación y puede interactuar estáticamente con otros SMBD que operen bajo el mismo
hardware.
4
•
Dependiente o embebido: El D/D es un componente del SMBD. Él es la única fuente de
meta data para el SMBD. Los utilidades del SMBD proveen facilidades de manejo del
D/D y el SMBD usa el D/D para acceder las BD almacenadas.
Ventajas:
Dependiente
Independiente
Las descripciones de los datos no están
almacenadas redundantemente en un paquete
de diccionario de datos y en el SMBD. Esto
reduce la ocurrencia de errores debido a fallas
en las actualizaciones de los 2 lugares.
Hay menos riesgo al implantar en el SMBD, un
diccionario independiente que uno integrado.
También la implantación de un diccionario
independiente es más sencilla, ya que el
diccionario no tiene que ajustarse a las
características de implantación de un SMBD.
Un diccionario de datos integrado necesita al
mismo tiempo todas las descripciones de los
datos requeridas para una BD, mientras que
estas descripciones se le pueden proporcionar
por
etapas
al
diccionario
de
datos
independiente.
En un diccionario de datos independiente existe
la opción de recuperar las descripciones
apropiadas de los datos del diccionario mismo, o
bien
proporcionarle
al
diccionario
las
descripciones.
El diccionario de datos tiene acceso a los datos
de la BD. Un uso potencial del diccionario de
datos puede ser en el área de seguimiento de
acceso a los datos, al proporcionar estadísticas
valiosas para mejorar el funcionamiento.
Un diccionario de datos puede servir como una
herramienta de control mucho más poderosa
cuando esta integrada con el SMBD, ya que el
diseñador de la BD y los usuarios tendrán que
reforzar el diccionario de datos como una
herramienta para la documentación y el control
de los datos.
En un diccionario de datos integrado es Un diccionario de datos independiente puede
necesario verificar la exactitud de las requerir o no una verificación de la actualización
descripciones de los datos antes de la ejecución de las descripciones antes de ejecutar un
de un programa.
programa.
El diccionario de datos es un lugar central de información sobre descripciones de los
datos, tales como significado, relaciones con otros datos y responsabilidad de tener los datos
actualizados, así como tener registrados los orígenes. En un medio de BD, la información
almacenada en un diccionario de datos es sobre los datos almacenados en la base, mientras
que en un medio ajeno a una BD, la información almacenada en un diccionario de datos es sobre
los datos almacenados en archivos de BD. Es necesario instalar software (sw) para crear y
manejar el diccionario de datos de una BD. El sw también se conoce como diccionario de datos.
El paquete del diccionario de datos se puede integrar dentro de un SMBD o tratarse
aisladamente.
5.5. Componentes funcionales de un Sistema D/D
Los componentes funcionales
1. Función de Mantenimiento: Interpreta los requerimientos de transacciones para añadir,
cambiar o borrar ocurrencias de las entidades del D/D.
2. Función de Extensibilidad: Permite que la estructura del D/D pueda ser extendida por la
definición de entidades, atributos y/o relaciones adicionales. Esta función debe incluir
también extensibilidad de procesamiento.
3. Función de Procesador de Reportes: Provee reportes predefinidos sobre información
contenida en el D/D y debe permitir la creación de nuevos reportes según las necesidades
de los usuarios.
4. Función de Procesador de Consultas: Se usa para recuperar poco volumen de información
del D/D utilizando lenguajes de consulta.
5. Función de Conversión: Los programas de aplicación, librerías y esquemas generan las
transacciones de actualización que son la entrada de la función de mantenimiento,
describiendo la meta data en las fuentes de entrada.
5
6. Función de Interfaz de Software: Permite que el sistema D/D provea meta data a otros
sistemas de software tales como compiladores y procesadores de DDL y a su vez permite a
estos sistemas proporcionar y actualizar información al D/D. Tipos de interfaces:
• Dinámica: Provee acceso directo de la información del D/D a otros módulos de software
que necesitan esta información para su funcionamiento. Permite que un programa de
aplicación interactúe con el D/D al momento de ejecución. Se usa principalmente
cuando la implementación del SMBD es en base a interpretación.
• Estática: Producen archivos, registros y descripciones de BD desde el D/D para los
programas usuarios. En este caso, cada componente de software tiene mecanismos
independientes para disponer de la meta data y también del mismo D/D.
7. Función de Facilidades de Exit: Permite agregar rutinas nuevas al sistema, como por
ejemplo, rutinas para el manejo de seguridad e integridad.
8. Función de manejo de directorio: Lleva a cabo tareas de manejo de BD tales como acceso
interno al D/D, control de concurrencia, manejo de integridad, seguridad, etc.
5.6. Casos de Estudio [12]
5.6.1. Oracle
El diccionario de datos de Oracle contiene descripciones de los objetos en la base de
datos. Incluye dos tipos de objetos:
• Tablas bases que almacenan las descripciones de la Base de Datos asociada.
• Vistas que resumen y muestran la información almacenada en las tablas base.
En general, el diccionario de datos de Oracle es un conjunto de tablas y vistas de solo
lectura que provee información sobre las Bases de datos asociadas. Este provee información
sobre: estructuras de datos físicas y lógicas de la base de datos, definiciones y ubicaciones de
los objetos, restricciones de integridad, usuarios, roles, privilegios, información de auditoria, etc.
Las vistas del diccionario de datos son divididas en tres categorías, distinguibles por un
prefijo:
• DBA: Vista del administrador. Contiene todos los objetos en la Base de datos.
• ALL: Vista Expandida del usuario. Contiene los objetos accesibles por el usuario actual.
• USER: Vista del usuario. Contiene los objetos que son propiedad del usuario.
A manera de ejemplo se mencionan algunas vistas del diccionario de Oracle:
DBA_TABLES,
DBA_OBJECTS,
DBA_CONSTRAINTS,
DBA_TAB_COLUMNS,
DBA_SEGMENTS,
DBA_EXTENTS,
DBA_FREE_SPACE,
DBA_DATAFILES,
DBA_TABLESPACES, etc.
6
6. Seguridad [11]
La operación continua exitosa de una empresa con sus operaciones computarizadas
demanda:
1. Que la dada confidencial esté disponible sólo para las personas autorizadas, de manera
tal que los requerimientos de privacidad sean satisfechos y los secretos de la empresa
sean guardados.
2. Que la data refleje precisamente el estado de la empresa, esto es, que la data esté
protegida contra alteraciones o destrucciones accidentales o premeditadas.
La información ha sido reconocida como un recurso con valor económico para la
empresa y como sucede con otra clase de recursos, la información necesita ser protegida y
administrada para maximizar su valor. Sin embargo, en contraste con otros bienes tangibles, el
valor de la información es difícil de cuantificar pero usualmente la información crítica puede ser
identificada y se pueden tomar medidas contra accesos no autorizados y así asegurar su
precisión y disponibilidad.
Tan importante como el valor económico de la información es la privacidad de los
individuos. El efecto de alterar o revelar información de una persona puede ser catastrófico para
ella. Por esto que existen también razones legales para que una empresa mantenga la
seguridad e integridad de su información.
6.1. Conceptos básicos
Seguridad de la información: es la protección de la información contra destrucción,
alteración o revelación no autorizada.
Seguridad de base de datos: es la protección de la información mantenida en la base
de datos.
Privacidad: es el derecho que tienen los individuos de controlar la información
disponible de ellos mismos.
Autorización: es la especificación de reglas que definen, para un sujeto, que derechos
de acceso tiene sobre que objetos de información.
Protección: en un ambiente computacional son mecanismos de seguridad que se
refieren a técnicas que controlan el acceso de usuarios y programas a la data almacenada.
Control de acceso: es el proceso que asegura que la información y otros objetos
protegidos sean accesados solamente en formas autorizadas.
6.2. Políticas de seguridad de base de datos
Política de seguridad: son lineamientos de alto nivel que tienen que ver con la
seguridad de la información. Estas políticas son dictadas por las necesidades de los usuarios, el
ambiente de instalación, las regulaciones de la institución y restricciones legales.
Mecanismos de seguridad: son conjuntos de funciones que son usadas para asegurar
e implementar diferentes políticas de seguridad. Las funciones pueden ser implementadas en
hardware, software o a través de procedimientos administrativos. Los mecanismos de propósito
general son útiles en sistemas que se usan en diferentes ambientes con diferentes políticas de
seguridad, tal y como sucede con los SMBD. Los mecanismos de propósito especial tienen la
ventaja de ser más simples de implementar y por esto es más fácil implementarlos
correctamente.
Una política de seguridad es de poco valor si se implementa incorrectamente, y esto
puede conllevar dos tipos de errores:
1. Que un acceso sea negado cuando, de acuerdo con la política, ha debido ser permitido.
2. Que un acceso sea permitido cuando, de acuerdo con la política, ha debido ser
rechazado.
6.2.1. Políticas sobre la administración de seguridad
•
Control centralizado vs. control descentralizado
7
Con control centralizado, un único autorizado (o grupo) controla todos los aspectos de
seguridad del sistema (por ejemplo, INGRES). En un sistema descentralizado diferentes
administradores controlan diferente porciones de la bd, normalmente siguiendo lineamientos que
aplican sobre la bd completa.
• Propietario vs. administrador
El propietario de una bd es algunas veces considerado la persona que es responsable
de crear la data. Por ejemplo, una bd de nómina exclusivamente actualizada por el
departamento de nómina puede ser considerado como poseída por el gerente del departamento
de nómina. Pero, cuando las bd son compartidas es difícil identificar un propietario único.
Entonces, mientras puede o no existir el concepto de propietario, siempre existe la necesidad de
una función de administración cuyo objetivo es definir la data compartida por los usuarios y
controlar su uso. Esta función puede ser realizada por el propietario, si existe, o por un
administrador de bd. La distinción básica entre estas dos políticas es que mientras al propietario
se le permite cualquier tipo de acceso, el administrador posee sólo los derechos de control de la
data.
6.2.2. Políticas para la especificación del control del acceso
•
Política del menor privilegio
Esta política restringe la información a aquellas personas que realmente necesitan la
información para su trabajo haciendo que todos los usuarios y programas operen con el menor
conjunto de privilegios necesarios para realizar sus funciones.
• Máxima compartición de los datos
La intención es hacer el máximo uso de la información de la bd. Esto no significa que
cada usuario tenga todos los accesos permitidos a toda la información ya que se tienen que
cumplir ciertos requerimientos de privacidad y se debe proteger a la data sensitiva.
• Sistemas abiertos y cerrados
En un sistema cerrado el acceso es permitido sólo explícitamente autorizado. En un
sistema abierto el acceso es permitido a menos que esté explícitamente prohibido. Un sistema
cerrado es el soporte básico de la política de menor privilegio mientras que un sistema abierto es
el soporte básico de la política de máximo compartición.
• Control de acceso dependiente del nombre
Como mínimo, se debe poder especificar los objetos de datos que pueden acceder un
usuario (objeto de dato: grupo de ocurrencias de data ítems y relaciones que tienen un nombre
conocido por el SMBD). La granularidad de los accesos de los objetos de datos es otra política
de decisión. En SMBD relacionales, la granularidad más fina permitida es a nivel de columnas o
atributos; en CODASYL es el data ítem o campo.
• Control de acceso dependiente del contenido
La política del menor privilegio puede ser extendida aún más especificando reglas de
acceso que hacen referencia al contenido de las ocurrencias (como también a los nombres)
proveyendo así una granularidad más fina de control de acceso.
• Tipos de acceso
Consiste en especificar los tipos de acceso que el usuario puede tener sobre los objetos
de datos, tales como READ, UPDATE, INSERT, DELETE ó alguna combinación de ellos.
Cuando los usuarios sólo necesitan información sumarizada o información estadística, la política
del menor privilegio requiere que no tengan acceso a los datos base de la información. Para
este control de acceso funcional, el concepto de tipos de acceso puede ser extendido para incluir
tipos de acceso funcionales para así poder especificar que un usuario tiene acceso al promedio
de los salarios pero no tiene acceso a los salarios individuales.
• Control dependiente del contexto
Una faceta de esta política restringe los campos que pueden ser accesados juntos. Por
ejemplo, si se tiene una relación que contiene los nombres y los sueldos de los empleados juntos
y se quiere evitar que algunos usuarios vean los salarios de los empleados correspondientes, se
puede permitir accesos separados a los nombres y a los salarios, evitando que estos sean
accesados juntos en un mismo requerimiento o en un conjunto específico de requerimiento (por
ejemplo, en un mismo programa)
8
•
Control dependiente de la historia
En general, no es suficiente controlar sólo el contexto de los requerimientos inmediatos
si se quiere prevenir que los usuarios hagan ciertas deducciones. Por ejemplo, si la relación
empleado también contiene el número de proyecto, un usuario puede listar primero todos los
empleados y los números de proyecto y luego listar los sueldos y los proyectos. Entonces, se
puede hacer una correlación entre el nombre y los salarios. El prevenir esta clase de
deducciones requiere control de acceso dependiente de la historia, el cual toma en cuenta no
sólo el contexto del requerimiento inmediato, sino también todos los requerimientos pasados. Se
restringe el acceso actual del usuario debido a los accesos que ya hecho en el pasado.
6.2.3. Políticas de control de flujo de la información
Las políticas anteriormente descritas controlan el acceso a la data, pero no controlan
como la usa el programa una vez que ha sido accedida. Este tipo de control es necesario para
prevenir, por ejemplo, la fuga de información desde un programa autorizado a uno no autorizado.
Cuando un autorizador puede dar derechos a otros se habla de control de acceso
discrecional. Un enfoque más simple pero menos flexible es “compartamentalizar” el uso de la
información y seguir una política fija donde la data que pertenezca a un comportamiento o
categoría no pueda ser accedida por usuarios asignados a otras categorías. Este es un ejemplo
de control de acceso no discrecional. Una extensión de esta política es la política de control
multinivel donde la información además de pertenecer a categorías, la información es clasificada
(de acuerdo a su sensibilidad) en niveles de confidencialidad, por ejemplo, no clasificada,
confidencial, secreta y supersecreta. Los usuarios también tienen asignados niveles de
categorías. Se define un nivel de seguridad como un par (nivel, categoría) y un nivel del
seguridad se considera que domina a otro si el nivel del primero es mayor o igual que el nivel del
segundo y el conjunto de categorías del primero contiene a las del segundo. La política
establece que un usuario puede leer data a menos que el nivel de seguridad del usuario sea
mayor o igual al nivel de seguridad de la data, y que la estructura no cause flujo de información
de un nivel más alto de seguridad a uno más bajo.
6.2.4. Políticas para asegurar el control
Para esto pueden usarse mecanismos preventivos o mecanismos detectivos. En el caso
de los detectivos, el sistema puede permitir que sean satisfechos pero también los va a registrar
en un log. El log puede ser auditado para determinar si un usuario ha violado las políticas de
seguridad y si ese es el caso tomar las medidas necesarias.
6.3. Modelos de seguridad de base de datos
6.3.1. Modelo básico para el control de acceso de base de datos
Este modelo tiene tres componentes básicos: un conjunto de objetos, un conjunto de
sujetos y un conjunto de tipos de acceso. Las reglas de autorización definen que tipo de acceso
tiene el sujeto para un objeto.
El conjunto de todas las reglas de acceso puede representarse a través de una matriz de
acceso en donde las columnas representan los objetos a ser protegidos, las filas representan los
sujetos y cada entrada de la matriz contiene una lista de los tipos de acceso permitidos para ese
sujeto sobre ese objeto.
En un modelo relacional los valores posibles del conjunto “O” pudieran ser los nombres
de todas las relaciones y atributos a proteger. Los sujetos pudieran ser usuarios finales, grupos
de ellos o programas. Los tipos de acceso son operaciones tales como READ, WRITE, ADD,
DELETE, etc.
Las matriz de acceso es capaz de modelar políticas de control de acceso dependiente
del nombre a cualquier nivel de granularidad soportado por el SMBD. Con el objeto de
representar las reglas de acceso dependientes del contenido, el modelo necesita ser extendido
para que la regla de acceso contenga un predicado p. Un predicado es una expresión que define
9
los miembros de un conjunto. Entonces, se puede representar una regla de acceso por las
tuplas (s, O, t , p), la cual especifica que el sujeto s tiene acceso sobre las ocurrencias de O
para las cuales el predicado p es verdad. A través del uso de ciertos predicados, ciertos
controles de acceso dependiente del contexto se pueden especificar. Por ejemplo, un predicado
puede enumerar campos que no pueden aparecer juntos en una consulta.
El control de acceso involucra algo más que sólo especificar reglas de acceso. Debe
haber también un proceso de validación que asegure que todos los accesos a la bd están
autorizados por reglas de acceso. Un posible modelo de validación se muestra en la siguiente
figura:
Figura 1: Modelo de validación de acceso
En este modelo todos los requerimientos de acceso son interceptados y pasados al
proceso de validación en la forma (s, O, t , p’). Se asume que la identidad del sujeto s ha sido
autentificada previamente. Si la matriz de acceso contiene una regla con el mismo (s, O, t), se
recupera la data para evaluar el predicado; en otro caso el requerimiento es denegado. Si el
predicado en la regla de acceso se refiere a data ítems no incluidos en O, es necesario
chequear que el sujeto tiene derecho de READ sobre esos datas ítems. Por ejemplo, una
consulta puede requerir una lista de nombres de empleados que ganen más de 100.000 Bs. No
es suficiente chequear que tenga derechos sobre los nombres de los empleados, es necesario
chequear que s tenga derechos sobre los salarios, porque de lo contrario no puede acceder la
información requerida. Luego, se evalúa el predicado en la regla, si es falso el requerimiento es
negado, de lo contrario se ejecuta.
6.3.2. Extensiones al Modelo Básico
Se extiende el modelo básico introduciendo tres nuevos componentes a la regla de
acceso, que son reglas para validar autorizaciones y requerimientos e interpretaciones
adicionales de sujetos, objetos y predicados.
Tal y como está especificado, el modelo básico no permite implementar políticas sobre
quienes escribe las reglas de acceso. Una de estas políticas establece que sólo el autorizador
puede hacer modificaciones a la regla de acceso. Para este propósito, se le agrega a la regla de
acceso un autorizador que es la persona que escribe la regla. Entonces, la regla queda de la
forma (a, s, O, t, p).
El modelo debe cubrir también políticas de delegación de derechos. Un derecho es la
(O, t, p) de la regla de acceso. A un sujeto s1 que tiene el derecho (O1, t1, p1) se le puede
permitir delegar este derecho a otro sujeto s2; esta delegación es equivalente a insertar una
nueva regla de acceso (s1, s2, O1, t1, p1). En el modelo se añade una bandera de copia f que
10
indica que el sujeto tiene derecho a delegar este derecho a otros usuarios, de manera tal que la
regla de acceso quedaría como (a, s, O, t, f, p).
La última extensión a aplicar a la regla es la especificación de procedimientos auxiliares
a ser realizado cuando la regla es usada durante la fase de validación de requerimientos. Estos
procedimientos pueden ser usados antes o después de que se toma la decisión de acceso; y su
uso después de la decisión puede ser un mecanismo de contingencia. Un ejemplo de este
mecanismo de contingencia es para acciones cuando el requerimiento de acceso es negado,
momento en el que se puede notificar a un monitor de seguridad para que registre en el log
cierta información. Entonces, se introduce una lista de pares (c1, pa1), ..., (cn, pan) que
especifica los procedimientos auxiliares a ser invocados y sus condiciones de invocación.
Finalmente, la regla de acceso queda de la forma (a, s, O, t, f, p, [(c1, pa1), ..., (cn, pan)]) .
6.3.3. Modelo Multinivel
Los modelos de seguridad multinivel tiene que ver con control de acceso no
discrecionales y, a diferencia de los anteriores, no sólo controla el acceso a la información, sino
también el flujo de información dentro del sistema.
Características Básicas de los Modelos Multinivel
Bell y LaPadula introducen los conceptos de nivel y categoría. A cada sujeto se le
asigna un nivel de clearance y cada objeto se le asigna un n nivel de clasificación. Cada sujeto y
cada objeto también tienen un conjunto de categorías. Un nivel de seguridad es una
composición de (nivel de clasificación, conjunto de categorías) y se dice que un nivel de
seguridad ns1 domina a un nivel de seguridad ns2 sii:
1. El nivel de ns1 es ≥ el nivel de ns2.
2. El conjunto de categorías de ns1 contiene el conjunto de categorías de ns2.
Un acceso a un objeto puede implicar observar el objeto (extraer información de él) o
alterar el objeto (insertar información en él). Según las combinaciones de estos accesos, los
tipos de acceso posibles son:
• Ni observar ni alterar
• Sólo observar (READ)
• Sólo alterar (APPEND)
• Observar y alterar (WRITE)
El modelo considera los estados de un sistema seguro, los cuales son descritos por:
• El conjunto de acceso actuales que es un conjunto de tripletas (s, o, t)
• Una matriz de acceso
• El nivel de seguridad de cada sujeto y
• Los niveles de seguridad máximo y actual de cada sujeto.
Un estado seguro se define por dos propiedades:
• La propiedad de seguridad simple: Para cada acceso actual (s, o, t) con un tipo de
acceso “observe”, el nivel de seguridad del sujeto domina el nivel de seguridad del
objeto.
• La propiedad *: un acceso actual (s, o, t) implica:
Si t = READ: ns(o) < ns(s)
Si t = APPEND: ns(o) ≥ ns(s)
Si t = WRITE: ns(o) = ns(s)
6.3.4. Un Modelo de Flujo de Información
En este modelo, un concepto de clases y categorías esta adaptado por un único
concepto llamado clase de seguridad y se introduce un operador de combinación variable. Un
modelo de flujo de información que describe a un sistema específico se define por cinco
componentes, que son:
1. Un conjunto de objetos
2. Un conjunto de procesos
3. Un conjunto de clases de seguridad
11
4. Un operador de combinación de clases ⊕: especifica la clase de resultado de cualquier
operación. Por ejemplo, si se concatenan dos objetos a y b, cuyas clases son a y b, la
clase del resultado es a ⊕ b.
5. Una relación de flujo: una relación de flujo entre dos clases, por ejemplo A Æ B, significa
que a la información de la clase A le es permitida fluir a la clase B. Un modelo de flujo
es seguro si una relación de flujo no puede ser violada.
En la siguiente figura se muestra un ejemplo de un modelo de este tipo:
Figura 2: Ejemplo de un Modelo de Flujo
La figura anterior representa un sistema que contiene data de tres tipos: médica,
financiera, y criminal.
Las clases muestran todos los subconjuntos del conjunto {m, f, c}; ellas representan
combinaciones de los tipos de datos. Los flujos de información son mostrados por flechas. El
operador ⊕ representa la unión de dos clases. Una violación de flujo pudiera ocurrir si se intenta
mover información de la clase {médica, financiera} a clase {médica}.
6.3.5. Comparación de Modelos
En general, los modelos se pueden clasificar en dos grandes categorías:
a) Los que controlan el acceso a los objetos y son extensiones del enfoque de matriz de
acceso.
b) Los que controlan el flujo de la información.
Una ventaja de los modelos a) es su flexibilidad para permitir la especificación fácil de un
amplio rango de políticas de seguridad. Su principal desventaja es el flujo de
información, cosa que hace los modelos tipo b), pero la desventaja de éstos modelos es
que cuando se crean nuevos objetos de bases de datos con nuevos requerimientos de
seguridad, se puede requerir una reestructuración completa del reticulado de clases, y
también requieren chequeos en tiempo de ejecución.
6.4. Casos de Estudio [12]
6.4.1. Oracle
El administrador de la base de datos define los nombres de los usuarios que tienen
acceso a la base de datos. Antes de que un usuario pueda acceder a la base de datos, debe ser
autentificado por medio de una de las siguientes alternativas: Por la Base de datos, por el
sistema operativo o por la red.
Existen dos tipos de privilegios en Oracle:
• Privilegios del sistema: Permite ejecutar una operación sobre la base de datos. Existen 126
privilegios del sistema. Los privilegios del sistema incluye la creación, eliminación y
alteración sobre tablas, vistas, índices, sesiones, tablespaces, etc.
• Privilegios del objeto: Permite ejecutar una operación sobre un objeto especifico.
La autentificación por medio del password file (por red) incluye los privilegios de
SYSDBA y SYSOPER. Conectarse como SYSDBA le da al usuario privilegios sin restricción
para ejecutar cualquier operación sobre la Base de datos o los objetos que incluye. SYSDBA
contiene los privilegios del SYSOPER, mas otros privilegios adicionales como son: la creación de
la base de datos, recuperación de la base de datos, etc.
12
Oracle también provee la facilidad del manejo de privilegios a través de roles. Un rol no
es mas que un grupo de privilegios que se le asigna a los usuarios ó a otros roles.
Existen roles predefinidos en Oracle, como son:
• CONNECT, RESOURCE: Provisto por compatibilidad con versiones anteriores.
• DBA: Todos los privilegios del sistema.
• EXP_FULL_DATABASE: Privilegio para exportar la base de datos.
• IMP_FULL_DATABASE: Privilegio para importar la base de datos.
• DELETE_CATALOG_ROLE: Privilegio de borrado sobre las tablas del diccionario.
• EXECUTE_CATALOG_ROLE: Privilegio de ejecución de paquetes del diccionario.
• SELECT_CATALOG_ROLE: Privilegio de consulta sobre las tablas del diccionario.
13
7. REFERENCIAS BIBLIOGRAFICAS
[1] Date C.J. “An Introduction to Database Systems”. 7th edition, Addison-Wesley, 2000.
[2] Gio Wiederhold. “Database Design”. 2a edición. Nueva York, N.Y.; McGraw-Hill (1983).
[3] T.H. Merret. “Relational Information Systems”. Reston, Va: Reston Publishing Company Inc.
(1984).
[4] Michael Stonebraker. “Operating System Support for Database Management”. CACM 24, núm
7. Julio 1981.
[5] Pratt P. and Adamski J. “Database Systems Management and Design”. Third Edition. Boyd &
Fraser publishing company. 1994.
[6] R. Bayer y C. McCreight. “Organization and maintenance of Large Ordered Indexes”. Acta
Informática 1, núm 3 (1972).
[7] Elmasri / Navathe. “Sistemas de Bases de Datos. Conceptos fundamentales”. Addison
Wesley. Segunda Edición 1997.
[8] Öszu, Tamar and Valduriez, P. “Principles of Distributed Database Systems”. 2nd Ed. Prentice
Hall, 1998.
[9] Korth H., Silberschatz A, Sudarshan, S. “Fundamentos de bases de datos”. Tercera edición.
McGraw-Hill. 1998. ISBN 84-481-2021-3
[10] Leon-Hong B., Plagman B., “Data Dictionary Directory Systems”. J. Wiley, 1982.
[11] Fernandez E., Summers R., Wood C. “Database Security and Integrity”. Addison Wesley,
1981.
[12] Loney, Kevin. “ORACLE 8. Manual del administrador”. McGrawHill. Primera Edición 2000.
FUENTES ELECTRÓNICAS
[13] Sybase. “Fast Track to Adaptive Server Enterprise 11.9.2”. 2001.
URL: www.sybase.com.
14