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