Post on 23-Jan-2023
Universidad de Matanzas
Facultad de Ciencias Económicas e Informáticas
Departamento de Informática
Extensión de Common Warehouse Metamodel para representar la seguridad
en el modelo Entidad-Relación.
Trabajo de Diploma en opción al Título de Ingeniería Informática
Autora: Annalie Barreras González
Tutores: Ing. Anelis Pereira Vale
Dr. Emilio Delfín Soler Cárdenas
Matanzas, 2012
Dedicatoria
A mi abuela Tania por su maravillosa educación. A mis hermanas: Annelis, Irene y Heisel.
Agradecimientos Quiero agradecerles a todas las personas que han aportado su granito de arena en este logro, y no me
refiero solo a la etapa de la Universidad, sino a los 17 años que resumen mi vida estudiantil.
A mi abuela Tania por su dedicación y estar siempre presente. A mi abuelo Félix porque en su momento
aprendí mucho de él.
A mi mamá y a Carlos por preocuparse siempre por mí y hacer que todo sea más confortable.
A mi abuela Esperanza por estar siempre pendiente de todas sus nietas.
A mi papá que estando muy lejos siempre conté con su apoyo. A Cristina porque en sus correos siempre
encontraba las palabras que me tranquilizaban.
A mi titico por toda su ayuda y por soportarme en momentos difíciles.
A mi tía por proporcionarme el transporte y por estar siempre de tan buen humor.
A mi primo Duniesky por ser un ejemplo para mí y por preocuparse siempre.
A mis tíos postizos Grisel y Enrique, Pucha, Maurilio y Carmita, con su familia incluida, por preguntar
siempre cómo iba todo.
A Larisa y Héctor por ayudarme con las figuras de la tesis.
A todos los amigos que me dio la Universidad, unos al principio, otros al final: Bárbara, Héctor, Arturo,
Patricia, Claudia P., Larisa, Mairene.
A todos los profesores de la Facultad en especial a Marielena, Robertico, Roger, Patrick.
A mis amigas de la vocacional por siempre estar ahí: Rocío, Claudia.
Al Dr. José Norberto Mazón López, de la Universidad de Alicante, España, por su valiosa e incondicional
ayuda vía e-mail.
A mi tutora Anelis por su ayuda y aguantarme este tiempo. A mi tutor Emilio que aunque no estuvo mucho
tiempo presente me enseñó a enfrentarme sola a una investigación.
A todos, simplemente, GRACIAS.
Annalie Barreras González
Matanzas, 5 de junio del 2012
Declaración de autoría Yo, Annalie Barreras González, declaro que soy la única autora de este trabajo y autorizo a la Universidad
“Camilo Cienfuegos”, especialmente a la Facultad Ciencias Económicas e Informática a que hagan el uso
que estimen pertinente de él.
Y para que así conste, firmo la presente a los 23 días del mes de mayo del 2012.
Annalie Barreras González Dr. Emilio Delfín Soler Cárdenas
Autora Tutor
Ing. Anelis Pereira Vale
Tutora Tutora
Resumen
Resumen
La información ha pasado a ser el activo más importante de las empresas, incluso superando a los activos
tradicionales como los económicos, humanos y las materias primas. Por ello, la seguridad en las bases de
datos es un aspecto que se tiene que tener muy en cuenta desde etapas tempranas de su diseño. En este
trabajo de tesis se proponen diferentes tareas de investigación cuya consecución lleva a elaborar una
extensión formal del modelo Entidad-Relación de Common Warehouse Metamodel para modelar aspectos
de seguridad de las bases de datos. Para ello, se utiliza la herramienta Rational Rose, identificándose los
conceptos y analizando el funcionamiento de esta herramienta con vista a corroborar el objetivo de la
investigación. Se presenta a su vez un add-in prototipo en la herramienta Rational Rose para el diseño de
bases de datos seguras y se comprueba su factibilidad sobre un caso de estudio relacionado con la
gestión de medicamentos en una empresa farmacéutica. La utilización del add-in prototipo permite validar
el modelo y generar un script para el Sistema Gestor de Base de Datos SQL Server Express 2005.
Abstract
Abstract
The information has become the most important asset in the companies, even overcoming to the traditional
assets as the economic, human and the matters cousins. For it, the security in the databases is an aspect
that one has to have very in bill from early stages of its design. In this thesis work they intend different
investigation tasks whose attainment takes to elaborate a formal extension of the pattern Entity-relationship
of Common Warehouse Metamodel to model aspects of security of the databases. For it, the tool Rational
Rose is used, being identified the concepts and analyzing the operation of this tool with view to corroborate
the objective of the investigation. It is presented an in turn add-in prototype in the tool Rational Rose for the
design of sure databases and it is proven their feasibility on a case of study related with the administration
of medications in a pharmaceutical company. The use of the one add-in prototype allows to validate the
pattern and to generate a script for the System Management of Database SQL Server Express 2005.
Índice general
vi
Índice general
Índice de Figuras ....................................................................................................................................... ix
Índice de Tablas ........................................................................................................................................ xi
Introducción .............................................................................................................................................. 1
CAPÍTULO I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el
modelo Entidad-Relación. ......................................................................................................................... 6
1.1 Introducción. ............................................................................................................................................. 6
1.2 Objeto de estudio. .................................................................................................................................... 6
1.2.1 Bases de Datos ................................................................................................................................ 6
1.2.2 Modelo Entidad-Relación ................................................................................................................ 7
1.2.3 Seguridad en las Bases de Datos .................................................................................................. 9
1.2.3.1 Diseño de Seguridad en Bases de Datos ............................................................................. 13
1.2.4 Implementación de la seguridad en Sistemas Gestores de Bases de Datos ............................ 14
1.2.5 Herramientas para el modelado .................................................................................................... 16
1.2.5.1 Rational Rose .......................................................................................................................... 17
1.2.5.1.1 Rational Rose Extensibility Interface (REI) ........................................................................ 18
1.3 Trabajo relacionado ................................................................................................................................ 19
1.4 Estándares de Object Managment Group (OMG) ............................................................................... 21
1.4.1 Model Driven Architecture (MDA) ................................................................................................. 23
1.4.2 Software Process Engineering Metamodel Specification (SPEM) ............................................ 23
1.4.3 Unified Model Language (UML) .................................................................................................... 23
1.4.4 Common Warehouse Metamodel (CWM) .................................................................................... 24
1.5 Método de Investigación en Ingeniería de Software empleado......................................................... 26
1.5.1 Investigación cualitativa: Investigación- Acción .......................................................................... 27
1.5.2 Aplicación del método Investigación-Acción ............................................................................... 28
1.6 Conclusiones del Capítulo .................................................................................................................... 30
CAPÍTULO II: Elaboración de la extensión de CWM para representar la seguridad en el modelo
Entidad-Relación. ..................................................................................................................................... 32
Índice general
vii
2.1 Introducción. ............................................................................................................................................... 32
2.2 Mecanismos de extensión de CWM. ....................................................................................................... 32
2.3 Modelo de Control de Acceso utilizado. ..................................................................................................33
2.4 Extensión propuesta. ................................................................................................................................. 34
2.4.1 Herencia .............................................................................................................................................. 35
2.4.2 Nuevos tipos de datos ....................................................................................................................... 36
2.4.3 Nuevas metaclases seguras y principales asociaciones ................................................................ 38
2.5 Definición de un add-in prototipo para Rational Rose ............................................................................ 40
2.5.1 Estereotipos ....................................................................................................................................... 40
2.5.2 Valores etiquetados ............................................................................................................................ 45
2.5.3 Restricciones ....................................................................................................................................... 45
2.5.4 Reglas bien formadas ........................................................................................................................ 45
2.6 Implementación del add-in prototipo ........................................................................................................ 46
2.6.1 Registro .............................................................................................................................................. 46
2.6.2 Archivo de Configuración ................................................................................................................... 48
2.6.3 Definición de etiquetas ....................................................................................................................... 49
2.6.4 Elementos del menú ............................................................................................................................ 51
2.6.5 Fichero de validación y fichero de obtención de código .................................................................. 51
2.7 Conclusiones del Capítulo ....................................................................................................................... 52
CAPÍTULO III: Pruebas y funcionamiento del add-in prototipo ........................................................... 53
3.1 Introducción ................................................................................................................................................ 53
3.2 Introducción al caso de estudio ................................................................................................................ 53
3.3 Utilización del add-in prototipo en el caso de estudio ............................................................................ 54
3.4 Obtención de código seguro ..................................................................................................................... 57
3.5 Implementación en el SGBD SQL Server Express 2005 ....................................................................... 60
3.6 Implantación del add-in en Rational Rose ................................................................................................. 61
3.7 Conclusiones del Capítulo ......................................................................................................................... 63
Conclusiones Generales .......................................................................................................................... 64
Recomendaciones .................................................................................................................................... 66
Índice general
viii
Referencias Bibliográficas ....................................................................................................................... 67
Anexos ...................................................................................................................................................... 70
Índice de Figuras
ix
Índice de Figuras
Figura 1.1 Entidad ........................................................................................................................................ 8
Figura 1.2 Atributo ....................................................................................................................................... 8
Figura 1.3 Interrelación ................................................................................................................................ 8
Figura 1.4 Entidad débil ............................................................................................................................... 8
Figura 1.5 Política de control de acceso cerrada ....................................................................................... 11
Figura 1.6 Política de control de acceso abierta ......................................................................................... 11
Figura 1.7 Modelo de control de acceso basado en roles .......................................................................... 12
Figura 1.8 Diseño de seguridad en las BD ................................................................................................. 14
Figura 1.9 Aplicación de RR y Componentes de REI ................................................................................. 18
Figura 1.10 Arquitectura de 4 capas y estándares de OMG ....................................................................... 22
Figura 1.11 Capas del metamodelo de CWM con sus paquetes ................................................................ 25
Figura 1.12 Paquete Entity-Relationship de CWM ..................................................................................... 26
Figura 1.13 Carácter cíclico de Investigación- Acción ............................................................................... 29
Figura 2.1 Herencia en el metamodelo del modelo ER seguro................................................................... 36
Figura 2.2 Nuevos tipos de datos para el modelo ER seguro ..................................................................... 38
Figura 2.3 Nuevas metaclases y asociaciones ........................................................................................... 39
Figura 2.4 Diferentes formas de representación de un estereotipo ............................................................ 40
Figura 2.5 Figura de los estereotipos definidos .......................................................................................... 41
Figura 2.6 Add-In Manager en Rational Rose ............................................................................................ 47
Figura 2.7 Sub-llave del add-in creado en el registro de Microsoft Windows .............................................. 48
Figura 2.8 Definición general para los estereotipos .................................................................................... 49
Figura 2.9 Definición de un estereotipo de tipo class y otro de tipo attribute .............................................. 49
Figura 2.10 Código para especificar las nuevas propiedades (valores etiquetados) .................................. 50
Figura 2.11 Nuevas propiedades para un elemento class .......................................................................... 50
Figura 2.12 Código para obtener nuevos elementos de menú ................................................................... 51
Figura 2.13 Procedimiento principal de MER Validate ............................................................................... 52
Figura 2.14 Procedimiento principal de MER DDL Generate ..................................................................... 52
Figura 3.1 Arquitectura de funcionamiento de la empresa farmacéutica .................................................... 54
Índice de Figuras
x
Figura 3.2 Pantalla de RR: caso de estudio modelado ............................................................................... 55
Figura 3.3 Jerarquía de roles del caso de estudio ...................................................................................... 56
Figura 3.4 Valores etiquetados y estereotipos de los atributos................................................................... 57
Figura 3.5 Generación de código seguro a partir del add-in prototipo en RR ............................................. 58
Figura 3.6 Tablas obtenidas en código SQL .............................................................................................. 59
Figura 3.7 Obtención en código SQL de la seguridad asociada al modelo ................................................. 59
Figura 3.8 SQL Server Express 2005 con las tablas obtenidas del script ................................................... 60
Figura 3.9 Roles implementados en el SGBD ............................................................................................ 61
Figura 3.10 Procedimiento para incluir los botones en el diagrama de clases ............................................ 62
Índice de Tablas
xi
Índice de Tablas
Tabla 1 Estereotipos de la extensión ......................................................................................................... 41
Tabla 2 Valores etiquetados definidos ....................................................................................................... 45
Tabla 3 Código que ejecuta el archivo mer.reg .......................................................................................... 47
Introducción
1
Introducción
De forma sencilla, una base de datos o banco de datos (en ocasiones abreviada con la sigla BD) es un
conjunto de datos pertenecientes a un mismo contexto los cuales son almacenados sistemáticamente
para su posterior uso. En este sentido, una biblioteca puede considerarse una base de datos compuesta
en su mayoría por documentos y textos impresos en papel e indexados para su consulta. La
representación será única e integrada, a pesar de que en algunos casos debe permitir el acceso a
diferentes usuarios de forma simultánea, además de poder ser compartida. Por ello, para diseñar
correctamente una base de datos es necesario realizar un análisis adecuado de los requisitos, así como
cumplir un conveniente diseño conceptual, lógico y físico. Actualmente, y debido al desarrollo tecnológico
de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital
(electrónico), que ofrece un amplio rango de soluciones al problema de almacenar datos.
Durante su desarrollo, las BD han pasado por diferentes fases. En sus inicios, allá por los años sesenta
del siglo pasado, las mismas estaban pensadas para realizar una tarea muy específica, por lo que
acostumbraban a darse por lotes a través de ficheros. Posteriormente, se comenzaron a escribir los
primeros códigos que permitieron las consultas multiusuarios de forma simultánea, utilizando el incipiente
desarrollo de las líneas de comunicación, los discos y los terminales. Finalmente los ficheros con
estructuras complejas se pudieron relacionar entre sí e incorporarlos a las aplicaciones para ser
compartidos por varios usuarios, siendo éste el concepto que se conoce hoy en día como el de “bases de
datos”.
En la actualidad, las BD representan el método eficaz para almacenar datos, por lo que su importancia ha
dejado de estar en entredicho desde hace mucho tiempo y su uso es masivo. Basta sólo indicar que
desde las complejas aplicaciones multiusuario, hasta los teléfonos móviles y las agendas electrónicas
utilizan la tecnología de las bases de datos para asegurar la integridad de los mismos y facilitar, sobre
todo, su manejo por parte de los usuarios.
Las BD almacenan información importante relacionada con todos los ámbitos (comerciales, militares,
médicas, administrativas, judiciales, entre otras), por lo que la información ha pasado a ser el activo más
importante de las empresas [1], por encima incluso de los activos más tradicionales como el económico, o
los recursos humanos. Por otra parte, el propio desarrollo de la sociedad moderna obliga al negocio
Introducción
2
evolucionar, así como a manejar la información correctamente en el orden de lograr sus objetivos y
sobrevivir en la era digital, lo hace imprescindible su protección. Esta protección abarca una gran cantidad
de aspectos, como: la seguridad física, la autenticación, la biometría, la seguridad en las redes de
comunicación, la criptografía y la seguridad jurídica, entre otras [1]. Dentro de todos estos aspectos
destaca la seguridad de las BD, que es donde residen los datos a partir de los cuales las organizaciones
obtienen la información y los conocimientos necesarios para su supervivencia.
La seguridad en las BD ha sido ampliamente investigada desde hace varios años, pero debido a los
continuos avances tecnológicos, los cada vez más complejos requisitos organizacionales, la difusión de
las comunicaciones, el incremento de la vulnerabilidad de los sistemas de información y los cambios
legislativos, todavía constituye un problema que no se encuentra resuelto [1].
Diseñar una BD es complejo y consume tiempo, más aún en el caso que debe prestarse atención a la
seguridad de la información, siendo considerada para la representación en la BD. Para simplificar la
actividad, es necesario mirar la aplicación de la BD a un nivel abstracto usando el modelo conceptual de
datos, por ejemplo, el modelo Entidad-Relación (ER) [2]. Con tal propósito se han desarrollado diferentes
propuestas que muestran extensiones realizadas al modelo ER para poder representar la seguridad desde
esta etapa de diseño, tales como la propuesta de Pernul et al. [2], Smith [3, 4], Sell [5], Marks et al. [6] y
Burns [7]. Sus principales inconvenientes son, por una parte, que la extensión realizada al modelo ER no
está formalizada. De igual forma, algunas no detectan los conflictos de restricciones, otras no proponen
una notación gráfica para la nueva extensión y ninguna propone automatizar este proceso a través de un
prototipo de herramienta de ingeniería de software asistida por ordenador (CASE según sus siglas en
inglés, Computer Aided Software Engineering) para el diseño y desarrollo de BD seguras. También existe
otra propuesta de Fernández–Medina et al. [1], que proponen una metodología para el diseño de BD
seguras pero la extensión se realiza mediante Unified Model Language (UML).
Para representar la seguridad desde el diagrama ER es necesario hacer una extensión de este que
permita tal propósito. Una extensión formal requiere de un metamodelo del cual se puedan derivar estas
extensiones [8]. El Common Warehouse Metamodel (CWM) permite el almacenamiento de metadatos de
inteligencia del negocio y el fácil intercambio entre las herramientas de almacenaje. Dentro de sus
paquetes se encuentra el modelo ER, por lo que utilizando los mecanismos de extensión que permite
CWM se llega a una extensión formalizada. En las búsquedas bibliográficas realizadas por la autora de
Introducción
3
esta tesis no se encontró ninguna propuesta que aborde el uso de CWM para extender el modelo ER con
el objetivo de representar la seguridad de las BD1.
Se tiene entonces como situación problémica, las dificultades en la representación de la seguridad en
las BD a nivel conceptual.
Se define entonces como problema científico a resolver, la siguiente interrogante: ¿cómo facilitar la
representación de la seguridad en las BD desde el nivel conceptual?
La respuesta a esta pregunta conduce, sin lugar a dudas a definir, como objeto de estudio, al proceso de
representación de la seguridad en el modelo ER.
Para resolver el problema planteado, en esta tesis se propuso como objetivo general elaborar una
extensión de CWM para representar la seguridad en el modelo ER.
De esta forma, el campo de acción se enmarca en la extensión de CWM para representar la seguridad
en el modelo ER.
Para poder cumplir el objetivo general propuesto se formularon las siguientes preguntas científicas:
¿Cómo demostrar la necesidad de selección del campo de acción y objeto de estudio en dicha
investigación?
¿Cómo demostrar la validez y funcionamiento de la extensión realizada?
Las tareas de investigación que se desarrollaron fueron:
Estudiar y analizar el trabajado relacionado con el objeto de estudio como punto de partida y
antecedentes de la investigación.
Desarrollar un add-in prototipo para el diseño del diagrama ER con las restricciones de
seguridad incluidas como prueba de conceptos a la extensión elaborada.
Comprobar el funcionamiento del add-in prototipo a través de un caso de estudio.
1 En el epígrafe 1.3 del Capítulo I se explica a fondo los criterios y la forma en que se realizó la búsqueda.
Introducción
4
La novedad de esta tesis radica en la propuesta de extensión a CWM para incluir la seguridad en el
modelo ER. Por otra parte, se podrían enumerar los siguientes beneficios o aportes de la misma. Estos
son: (i) se basa en un estándar CWM del Object Management Group (OMG) para el modelado seguro de
las BD, (ii) se garantiza consistencia ya que la extensión evita tener situaciones en las que existen
diferentes definiciones y propiedades para un mismo concepto en el modelo. En la literatura consultada no
se encontró ninguna propuesta similar a esta.
Para darle solución al problema planteado y cumplir el objetivo trazado se utilizaron en la investigación los
siguientes métodos:
Histórico-lógico: Permite desentrañar la historicidad del asunto referido al modelo ER y a la
seguridad en las BD.
Análisis sintético: Se utilizó durante la revisión bibliográfica y el análisis de los resultados,
permitiendo descomponer lo complejo en sus partes y cualidades, la división mental del todo en
sus múltiples relaciones, para luego unir las partes analizadas, descubrir las relaciones y las
características generales entre ellas.
Inducción-deducción: Su uso fue necesario tanto en la revisión bibliográfica, como en el análisis de
los resultados, permitiendo arribar a conclusiones derivadas de las propiedades y a las relaciones
existentes entre los elementos del fenómeno objeto de estudio. De hechos singulares se puede
pasar a proposiciones generales.
Enfoque de sistema: Facilitó la orientación general del estudio como una realidad integral formada
por elementos que interaccionan unos con otros.
Modelación: Permitió la realización de abstracciones y procedimientos lógicos de asimilación
teórica de la realidad, para la creación de modelos ER, como eslabón fundamental en la obtención
de las BD que sustentarán las aplicaciones informáticas.
Criterio de especialistas: Se utilizó para obtener criterios a partir de las experiencias de los
especialistas, basado en el área del conocimiento en que se enmarca la investigación.
Por otra parte, en la Ingeniería del Software existen métodos de trabajo adecuados en función del tipo de
investigación que se ha realizado. Como ejemplo de los métodos cualitativos [9] se encuentra el de
Investigación-Acción, que tiene una doble finalidad: generar un beneficio al “cliente” de la investigación y,
al mismo tiempo, crear “conocimiento de investigación” relevante [10]. Por tanto, la Investigación-Acción
Introducción
5
es una forma de investigar de carácter colaborativo que busca unir teoría y práctica entre investigadores y
practicantes mediante un proceso de naturaleza cíclica. En la investigación desarrollada se ha aplicado
este método conjuntamente con los descritos anteriormente.
El resto de la memoria de la tesis se estructura en tres Capítulos que se describen a continuación:
Capítulo 1: Fundamentación teórica de la extensión de CWM para representar la seguridad en el
modelo ER. Se tiene en cuenta el objeto de estudio de la investigación. En él se exponen los resultados
de la búsqueda bibliográfica realizada sobre los trabajos relacionados con la investigación ya publicados,
se explican los métodos de investigación de Ingeniería de Software aplicados, así como las metodologías
y tecnologías utilizadas para dar cumplimiento a los objetivos trazados.
Capítulo 2: Elaboración de la extensión de CWM para representar la seguridad en el modelo ER. Se
describe con más detalle los mecanismos de extensión que propone CWM. A su vez, se presenta la
extensión propuesta para representar la seguridad en el modelo ER, así como el add-in prototipo para
comprobar la viabilidad de la extensión.
Capítulo 3: Pruebas y funcionamiento del add-in prototipo. Se expone el funcionamiento del add-in
prototipo en la herramienta CASE Rational Rose a través de un caso de estudio. Se verifica la validez del
add-in comprobando el script generado en su correspondiente Sistema Gestor de BD SQL Server Express
2005.
Para complementar la investigación después del último capítulo se encuentran las Conclusiones Genera-
les, las Recomendaciones y los Anexos.
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
6
CAPÍTULO I: Fundamentación teórica de la extensión de CWM para
representar la seguridad en el modelo Entidad-Relación.
1.1 Introducción.
Las bases de datos almacenan información importante relacionada con todos los ámbitos: comerciales,
militares, médicas, administrativas y judiciales, entre otras muchas. Es por esto que la información ha
pasado a ser el activo más importante de las empresas, por encima incluso de los activos tradicionales
(económicos, humanos y materias primas), por lo que se hace necesario tratar la seguridad en las bases
de datos desde etapas tempranas de su diseño.
En este Capítulo se analizan las bases teóricas que sustentan y fundamentan la investigación. Se abordan
elementos que ayudan a entender los procesos objetos de estudio, así como los trabajos relacionados con
los mismos. Se aborda además, la metodología que ha permitido dar respuesta a la problemática
existente. Así como los métodos de investigación que se aplicaron en Ingeniería de Software.
1.2 Objeto de estudio.
1.2.1 Bases de Datos
Las aplicaciones informáticas de los años sesenta acostumbraban a darse totalmente por lotes (batch) a
través de ficheros y estaban pensadas para una tarea muy específica. A medida que se fueron
introduciendo las líneas de comunicación, los terminales y los discos, se comenzaron a escribir programas
que permitían a varios usuarios consultar los mismos ficheros on-line y de forma simultánea. Más adelante
surgió la necesidad de hacer las actualizaciones también on-line, así como lograr la interrelación entre los
ficheros. Estos conjuntos de ficheros interrelacionados, necesarios para la integración de las aplicaciones,
con estructuras complejas y compartidas por varios procesos de forma simultánea (unos on-line y otros
por lotes), recibieron el nombre de Data Banks. Luego a inicios de los años setenta se cambia por el de
Data Bases, o sea en español BD [11]. Date [12], considerado uno de los pioneros en las BD, las define
como sigue:
“Una BD de un Sistema de Información (SI) es la representación integrada de los conjuntos de entidades,
instancia correspondiente a las diferentes entidades tipo del SI, y de sus interrelaciones. Esta
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
7
representación informática (o conjunto estructurado de datos) debe poder ser utilizada de forma
compartida por muchos usuarios de distintos tipos” [11, 12].
En otras palabras, una BD es un conjunto estructurado de datos que representa entidades y sus
interrelaciones. La representación será única e integrada, a pesar de que debe permitir utilizaciones varias
y simultáneas.
Las BD son el método preferido para el almacenamiento estructurado de datos. Desde las grandes
aplicaciones multiusuario, hasta los teléfonos móviles y las agendas electrónicas utilizan tecnología de
bases de datos para asegurar la integridad de los datos y facilitar la labor tanto de usuarios como de los
programadores que las desarrollaron.
En el diseño de una BD se suelen distinguir cuatro fases: análisis de requisitos, diseño conceptual, lógico
y físico [8]. En el modelado de los sistemas transaccionales tradicionalmente se utiliza el modelo de
Entidad-Relación y por su expresividad gráfica alcanzó gran aceptación.
1.2.2 Modelo Entidad-Relación
En 1976, Peter Chen publicó el modelo ER [13], indicando que, de forma general, el modelo ER:
adopta la vista más natural que el mundo real consiste en entidades y relaciones,
incorpora alguna de la información semántica importante sobre el mundo real,
puede usarse como una base para una vista unificada de data stored en red, relacional.
Sobre esta primera versión han trabajado numerosos autores, generando distintas extensiones de mayor
o menor utilidad y de aceptación variable en el medio académico y profesional. Muchas de estas
extensiones son muy útiles, pero han sido poco difundidas, debido principalmente a la ausencia de
herramientas automatizadas que apoyen su uso. [14]
El modelo ER es uno de los enfoques de modelización de datos que más se utiliza actualmente por su
simplicidad y legibilidad. Su legibilidad [11] se ve favorecida porque proporciona una notación en forma de
diagrama muy comprensiva. Es una herramienta útil tanto para ayudar al diseñador a reflejar en un
modelo conceptual los requisitos del mundo real de interés, como para comunicarse con el usuario final
sobre el modelo conceptual obtenido y, de este modo, poder verificar si satisface sus requisitos.
A continuación se definen los diferentes elementos del modelo ER, necesarios para comprenderlo [11,
12]:
Por Entidad se entiende un objeto del mundo real que se distingue del resto de los objetos y del que
interesa algunas propiedades. Se representa como se observa en la Figura 1.1.
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
8
Figura 1.1 Entidad
Las propiedades de los objetos que interesan se denominan Atributos. Su representación se observa en
la Figura 1.2.
Figura 1.2 Atributo
Se define Interrelación a la asociación entre más de dos entidades. Cada una de las entidades
asociadas puede estar conectada con conectividad “uno” o bien con conectividad “muchos”. Existe un
caso particular llamada autorrelación, en la cual una entidad se relaciona con ella misma, siguiendo las
mismas conectividades. Se representa como se encuentra en la Figura 1.3.
Figura 1.3 Interrelación
Una Entidad débil es una entidad cuyos atributos no la identifican completamente, sino que sólo la
identifican de forma parcial. Esta entidad debe participar en una interrelación que ayuda a identificarla y se
representa como se muestra en la Figura 1.4.
Figura 1.4 Entidad débil
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
9
La generalización/especialización permite reflejar el hecho de que hay una entidad general, que se
denomina entidad superclase, y se puede especializar en entidades subclase:
La entidad superclase permite modelar las características comunes de la entidad vista de una
forma genérica.
Las entidades subclase permiten modelar las características propias de sus especializaciones.
Es necesario que se cumpla que toda ocurrencia de una entidad subclase sea también una ocurrencia de
su entidad superclase.
Según [15], el diagrama ER moderno usualmente omite el diamante que representa una interrelación
(Figura 1.3), construyéndose entonces un rectángulo que contiene la lista de atributos de esa entidad.
1.2.3 Seguridad en las Bases de Datos
Las organizaciones cada vez más dependen de los SI, que cuenta con BD grandes, y estas BD necesitan
por consiguiente aumentar la calidad y seguridad [16]. Así la seguridad es la capacidad de un producto de
software de proteger los datos y la información para que otras personas no autorizadas no puedan leerlos
o modificarlos; garantizando asimismo que el acceso no sea denegado a personal autorizado [17].
Como apunta [8] la seguridad en el mundo de la informática está bien establecida. Diversas soluciones de
seguridad se han aceptado globalmente, sin embargo, de manera continua se estudian y se proponen
diversas propuestas para garantizar la construcción de software seguro. La seguridad de la información es
un tema que no debe descuidarse, sino, por el contrario, es un requisito serio que debe ser considerado y
estar presente en todas las etapas del ciclo de desarrollo, desde el análisis de requisitos hasta la
implementación y el mantenimiento. No obstante, la seguridad de BD en relación con el diseño con
frecuencia no se tiene en cuenta, enfocando la seguridad de los datos desde el punto de vista criptográfico
[18].
La seguridad está definida por tres conceptos fundamentales [17]:
Confidencialidad: de forma que se pueda prevenir/detectar/impedir el descubrimiento de
información. En general la confidencialidad se refiere a la protección de datos implicados en
entornos altamente protegidos, como militares, comerciales, entre otros.
Privacidad: se refiere a información sobre individuos. En la mayoría da los países la Privacidad
está protegida por las leyes.
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
10
Integridad: para prevenir/detectar/impedir la modificación inadecuada de información. Por ejemplo,
en un entorno militar, el mando responsable de un misil no debe ser modificado inadecuadamente.
En un entorno comercial, la integridad de los datos es especialmente relevante, puesto que el éxito
de una organización depende de las correctas operaciones que se llevan a cabo y la coherencia de
los datos. Dentro de este concepto están:
Integridad semántica: que es el respeto en todo momento a las reglas de integridad
definidas en la BD.
Integridad operacional: que garantiza la consistencia de la base de datos con respecto al
uso concurrente de la misma.
Disponibilidad: encargada de prevenir/detectar/impedir la denegación inadecuada del acceso a los
servicios ofrecidos por el sistema.
Estos conceptos están presentes a la hora de establecer las técnicas de control de acceso, pero antes de
adentrarnos en este tema, es necesario conocer las definiciones asociadas a estos términos [17].
Control de acceso: Es el responsable de asegurar que todos los accesos directos a los objetos del
sistema se producen exclusivamente de acuerdo a los modos y reglas definidas por las políticas de
protección definidas.
Técnicas de control de acceso: Es el mecanismo a través del cual se intenta asegurar que solamente los
sujetos autorizados acceden a los recursos del SI.
Las políticas de control de acceso se pueden clasificar en dos grupos:
Cerradas: Solamente los accesos autorizados explícitamente son permitidos, como se muestra en
la Figura 1.5.
Abiertas: Los accesos que no son explícitamente prohibidos son permitidos, como se puede
observar en la Figura 1.6.
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
11
Figura 1.5 Política de control de acceso cerrada
Figura 1.6 Política de control de acceso abierta
Según [19], existen diferentes tipos de políticas de control de acceso:
Discrecional: acceso basado en la identidad de los sujetos y en reglas de autorización que indican
para cada sujeto, las acciones que puede realizar y las que no puede realizar sobre cada objeto
del sistema. Las BD que utilizan esta política de control de acceso son susceptibles de recibir
ataques por parte de sujetos que aparentemente realicen un acceso correcto a los datos, pero que
en realidad han recibido el permiso de acceso por parte de otro de forma fraudulenta.
Obligatorio: consiste en la clasificación de los sujetos y los objetos en el sistema en clases de
acceso que determinan sus características de confidencialidad. Una clase de acceso es un
elemento de un conjunto de clases parcialmente ordenadas. Las clases de acceso se definen
como un conjunto formado por dos componentes, un nivel de seguridad y un conjunto de
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
12
categorías. Cada nivel de seguridad es un elemento de un conjunto jerárquicamente ordenado
como “alto secreto” (TS), “secreto” (S), “confidencial” (C) y “sin clasificar” (U), donde TS > S > C >
U. El conjunto de categorías es un subconjunto de un conjunto desordenado, donde los elementos
pueden reflejar áreas funcionales o diferentes competencias como por ejemplo finanzas,
administración, ventas y compras para sistemas comerciales. Aunque esta política de control de
acceso ofrece protección frente a pérdidas de información, no garantiza una completa
confidencialidad de la información. De hecho es muy complicado controlar la no existencia de
canales ocultos.
Basada en Roles: regula el control de acceso de usuarios a la información, en base a las
actividades y responsabilidades organizacionales que los usuarios tienen en el sistema. Se
asocian “permisos” con “roles”. Los usuarios se hacen miembros de esos roles obteniendo así los
permisos. Cada rol representa un grupo funcional con responsabilidades similares. Permite de
manera sencilla cambios organizacionales. El esquema que representa esta política se puede
observar en la Figura 1.7.
Figura 1.7 Modelo de control de acceso basado en roles
Esta política ofrece un conjunto de ventajas:
Gestión de autorizaciones: hay una independencia lógica entre la actividad de asignar roles a
usuarios y asignar privilegios de acceso a los roles. Esto facilita mucho la gestión.
Jerarquía de roles: en muchas aplicaciones hay una jerarquía natural de roles, basadas en los
principios bien conocidos de generalización y especialización. Esto puede dar lugar a
autorizaciones implícitas como por ejemplo: el secretario (o la secretaria) hereda todos los
permisos del personal de administración. Esto se muestra claramente en la Figura 1.7.
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
13
Privilegios mínimos: los roles permiten que un usuario tenga los privilegios estrictamente
necesarios para realizar una tarea particular. Esto minimiza los peligros de daño debido a un
exceso de privilegios.
Separación de responsabilidades: se refiere al principio de que ningún usuario debería tener
suficientes privilegios para darle un uso inadecuado al sistema en su propio beneficio. Por
ejemplo, la persona autorizada a pagar un cheque no debe ser la misma que la persona que lo
prepara. Esto se puede hacer cumplir distinguiendo roles usuarios entre roles conflictivos.
Cumplimiento de restricciones: los roles dan una base para la especificación de requisitos de
protección que pueden ser necesarias en las situaciones reales. Ejemplo: número máximo de
usuarios en un rol.
1.2.3.1 Diseño de Seguridad en Bases de Datos
Según Castano et al. [19], el diseño de seguridad en BD se puede expresar como se muestra en la Figura
1.8. Obsérvese como desde el comienzo de diseño se tiene en cuenta la seguridad. Dada la riqueza
semántica que se puede modelar desde la etapa de diseño conceptual permitirá a etapas posteriores,
mayor claridad para la futura implementación de la seguridad.
A continuación se explicarán las etapas de acuerdo a las especificaciones presentadas en la Figura 1.8.
El Análisis Preliminar se realiza para formalizar los requisitos y crear un modelo que represente
conceptualmente la estructura de la BD. Luego, se clasifica la información de acuerdo a sus propiedades
de confidencialidad. Más tarde, se procede a especificar las restricciones de seguridad necesarias. En la
etapa de Diseño Conceptual se construye el modelo pensado en la fase de Análisis que ya incluiría las
restricciones de seguridad especificadas. El Diseño Lógico se representaría a través de un modelo lógico
que ha sido recogido en la etapa anterior. En esta etapa se pierde información semántica que fue recogida
en el Diseño Conceptual. Ya en el Diseño Físico solo se representaría lo que realmente puede ser
implementado en los Sistemas Gestores de BD (SGBD).
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
14
Figura 1.8 Diseño de seguridad en las BD
1.2.4 Implementación de la seguridad en Sistemas Gestores de Bases de Datos
El mercado de los SGBD en estos tiempos es el segmento de herramientas de desarrollo de aplicaciones
más importante del sector del software, sólo superado en dimensión por el mercado de sistemas
operativos [20]. Según las consultas realizadas en diferentes sitios web2 los principales SGBD son Oracle
y Microsoft.
2 http://www.idg.es/computerworld/secc/mercado
http://www.idg.es/computerworld/La-demanda-mundial-de-bases-de-datos-relacionales./seccion-/articulo-42174 biblioteca.utec.edu.sv/siab/virtual/articulos_soft_libre/Microsoft_SQL_Server,_MySQL_y_PostgreSQL.pdf
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
15
En esta sección, tomando como base la selección presentada anteriormente se presenta una discusión de
los SGBD Oracle 10g, DB2 de IBM, SQL Server 2005 de Micosoft haciendo énfasis en la capacidad para
implementar características avanzadas relacionadas con la seguridad.
SGBD Oracle 10g. De manera tradicional el SGBD Oracle le asigna privilegios a roles sobre los objetos
del esquema y sobre las cuentas de usuario, por ello se afirma que Oracle soporta el modelo de control de
acceso basado en roles (RBAC, por sus siglas en inglés Role Based Access Control). Oracle 10g permite
definir políticas de seguridad y auditoría mediante los componentes Oracle Label Security (OLS10g),
Virtual Private Databases (VPD) y Oracle Fine-Grained Auditing (FGA). OLS10g define etiquetas que
contienen información de confidencialidad para las filas e información de autorización para usuarios.
Toda la información de seguridad especificada tiene que ser ejecutada dentro del contexto de una política
de seguridad. Además, OLS10g ofrece mecanismos llamados funciones etiquetadas (labeling function)
que definen la información de una etiqueta de seguridad según el valor de las columnas de las filas que
son insertadas o actualizadas. Este mecanismo que ofrece OLS posibilita que Oracle 10g soporte modelos
de control de acceso del tipo discrecional (Discretionary Access Control, DAC).
VPD permite restringir al acceso a filas específicas de una tabla. VPD también se puede usar para definir
una función de la política de seguridad que le permita a cualquier usuario individual ver un conjunto
completamente diferente de datos, que consta sólo de aquellos datos que el usuario particular está
autorizado para ver. Por su parte, FGA permite definir e implementar políticas de seguridad a través de las
cuales audita las expresiones select, update, insert y delete en tablas y vistas según la condición de
auditoría especificada en la política de seguridad [8].
SGBD SQL Server 2005 de Microsoft. El SGBD SQL Server ofrece cuatro ediciones: Express,
Workgroup, Standard y Enterprise. Estas cuatro nuevas ediciones ofrecen desde una alta disponibilidad y
sólida escalabilidad, hasta herramientas avanzadas de inteligencia comercial, diseñadas para ofrecer a los
usuarios de una organización una plataforma productiva de gestión de datos más segura, fiable y
productiva.
En materia de seguridad SQL Server 2005 incorpora procesos de desarrollo para que los productos sean
seguros en materia de diseño, configuración y desarrollo. Todo esto bajo la iniciativa de la Informática
Fiable (Trustworthy Computing) lanzada por Microsoft en enero de 2002, pensada para mejorar cuestiones
de seguridad, privacidad, confiabilidad e integridad de negocios. La autenticación en SQL Server 2005
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
16
está basada en: (i) Microsoft Data Access Client (MDAC), el cliente utilizará una dll, (ii) Socket connection,
MDAC intentara establecer una conexión a una socket connection a SQL Server, (iii) hello packet, enviado
por el cliente a SQL Server para ser verificado, (iv) protocol negotiation, SQL Server responde a través de
la respuesta con la información necesaria para la negociación del protocolo a utilizar en las futuras
comunicaciones, (v) login packet, el cliente responde a través del envío de un login packet hacia SQL
Server y (vi) acknowledgement, SQL Server envía al cliente una aceptación.
SQL Server 2005 soporta la creación de roles y grupos de usuarios para asignarle permisos de acceso a
los diferentes objetos de la base de datos y del servidor en general. El administrador de la base de datos
puede utilizar los roles por defecto que ofrece SQL Server 2005 o crear nuevos roles, en ambos casos los
roles representan a usuarios personalizados que ocupan diferentes responsabilidades dentro de la BD. De
esta manera el servidor soporta el modelo de control de acceso. Para dar soporte al modelo de control de
acceso obligatorio (Mandatory Access Control, MAC) es necesario utilizar disparadores (triggers), aunque
Microsoft ha desarrollado la herramienta SQL Server 2005 Label Security Toolkit, con ella consigue
implementar un modelo de seguridad basado en niveles para filas y celdas en una aplicación de BD, es
decir, implementar un modelo MAC. Para realizar funciones de auditoría SQL Server 2005 ofrece la
herramienta SQL Server Audit. Esta proporciona las herramientas y procesos necesarios para habilitar,
almacenar y analizar auditorías en objetos del servidor y de la BD [8].
1.2.5 Herramientas para el modelado
La herramientas de modelado, llamadas herramientas CASE es la mejor base para el proceso de análisis
y desarrollo de software.
Según [21] las herramientas CASE se iniciaron con un procesador de palabras que fue usado para crear y
manipular documentación. Los 70‟s vieron la introducción de técnicas gráficas y diagramas de flujo de
datos. Sobre este punto, el diseño y el establecimiento de especificaciones en forma pictórica han sido
extremadamente complejos y consumían mucho tiempo para realizar cambios.
La introducción de las herramientas CASE para ayudar en este proceso ha permitido que los diagramas
puedan ser fácilmente creados y modificados, mejorando la calidad de los diseños de software. Los
diccionarios de datos, un documento muy usado que mantiene los detalles de cada tipo de dato y los
procesos dentro de un sistema, son el resultado directo de la llegada del diseño de flujo de datos y análisis
estructural, hecho posible a través de las mejoras en las Herramientas CASE.
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
17
Todos estos procesos pueden saberse integrados en una simple herramienta CASE que soporta todo el
ciclo de desarrollo. La primera herramienta comercial se remonta a 1982, aunque algunos especialistas
indican que algunos ejemplos de herramientas para diagramación ya existían.
No fue sino hasta 1985 cuando las herramientas CASE se volvieron realmente importantes en el proceso
de desarrollo de software. Los proveedores prometieron a la Industria que muchas actividades serían
beneficiadas por la ayuda de las CASE.
El objetivo en 1985 para muchos vendedores era producir software más rápidamente. Las herramientas
CASE serían una familia de métodos favorablemente estructurados para planeamiento, análisis y diseño.
Esto llevaría a la generación automática de código para desarrollo de software. Esto traería como
beneficio: Una mejora en la calidad, fiabilidad, utilidad y rendimiento.
Dentro de las herramientas CASE más utilizadas, de acuerdo al análisis de diferentes sitios3, se
encuentran: Visual Paradigm, StartUML, ArgoUML, Eclipse, Enterprise Architect, Rational Rose, entre
otras.
A continuación se analizará la herramienta seleccionada para el propósito de este trabajo.
1.2.5.1 Rational Rose
Según [22] Rational Rose (RR) es una de las herramientas para el modelado visual más conocida. RR es
extensible por medios de add-ins, los cuales permiten al usuario la personalización de sus paquetes y la
automatización de las características que ofrece a través de Rational Rose Extensibility Interface (REI).
RR proporciona varias maneras de realizar una extensión y personalizar sus capacidades específicas para
satisfacer las necesidades de desarrollo de software. En particular, RR permite al usuario:
Personalizar los menús.
Automatizar las funciones manuales a través de los Scripts.
Ejecutar funciones desde dentro de otra aplicación usando la herramienta Automatization Object.
3 exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/monerica.pdf
en.wikipedia.org/wiki/Eclipse http://www.apexnet.com.ar/index.php/news/main/38/event=view redalyc.uaemex.mx/pdf/215/21513706.pdf www.arqui.com/users/taller/Presentaciones/Evaluaci%C3%B3n%20de%20herramientas%20CASE%20paraUML.pdf
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
18
Acceder a las clases, propiedades y métodos dentro de un entorno de desarrollo de software
incluyendo la librería Extensibility Type Library.
Activar add-ins mediante el Add-In Manager.
Un add-in es básicamente una colección de algunas combinaciones: elementos principales de menú,
especificaciones personalizadas, propiedades (valores etiquetados Unified Model Language (UML)), tipos
de datos, estereotipos UML, ayuda en línea, manejo de eventos [22].
1.2.5.1.1 Rational Rose Extensibility Interface (REI)
El modelo REI es esencialmente un metamodelo del modelo de RR que permite el manejo de paquetes,
clases, propiedades y métodos que define y controlan la aplicación de RR y todas sus funciones. La
Figura 1.9 muestra los componentes de Rose y de REI e ilustra las relaciones entre ellos. Estos son [22]:
Figura 1.9 Aplicación de RR y Componentes de REI
Aplicación RR: objetos de Rose Extensibility que unen la funcionalidad de la aplicación de RR.
REI: Este es el conjunto común de interfaces usadas por Rose Script y Rose Automation para
acceder a RR.
Rose Script: es el conjunto de objetos de Rose Script que permiten generar scripts para
automatizar la funcionalidad de RR.
Rose Automation: es el conjunto de objetos de Rose Automation que permite a RR funcionar como
un controlador automático o servidor Object Linking and Embedding (OLE).
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
19
Diagramas: objetos de Rose Extensibility que unen los diagramas y vistas de RR.
Elementos del modelo: objetos de Rose Extensibility que unen los elementos del modelo de RR.
1.3 Trabajo relacionado
En este epígrafe se detallan los trabajos más importantes relacionados con el objetivo a desarrollar. Para
ello se investigó si el tema ha sido abordado previamente por algunos especialistas y se realizó una
extensa búsqueda bibliográfica, encontrando varios artículos relacionados que sirvieron para aclarar ideas
y proponer soluciones viables las cuales se adoptaron durante la realización del trabajo.
El criterio utilizado en la búsqueda fue considerar todos las publicaciones desde el 2004 hasta la fecha,
con las palabras claves: Common Warehouse Metamodel; modelo Entidad-Relación; definición de add-in;
Rational Rose; seguridad en el modelo Entidad-Relación. La búsqueda se realizó en las siguientes bases
de datos de reconocido prestigio dentro del mundo académico de las ciencias de la computación: ACM
Digital Library4, Digital Bibliography & Library Project (DBLP)5, Google6 (y su versión académica Scholar
Google7), IEEE Digital Library8 y Science Direct (en el área de ciencias de la computación).
En su tesis doctoral [22] plantea las ventajas que tiene el modelo ER, el cual se usa para el diseño de BD
porque traza bien el modelo relacional y es simple y fácil de entender con un mínimo de entrenamiento.
Este autor también pone al descubierto sus deficiencias, como son: que no es un estándar, los diagramas
tienden a estar desarreglados y son difícil de leer. También hace una comparación con UML sin dejar de
mencionar que UML se construyó teniendo en consideración al modelo ER.
Diseño de BD. Las tradicionales metodologías de diseño de BD [1, 23, 24] no consideran la seguridad.
Por consiguiente, estas metodologías no son útiles desarrollando las BD seguras. Por ello uno de
aspectos primordiales es la necesidad de conocer la importancia de la seguridad en las BD. Sobre esto en
[1] se expresa que la seguridad es un problema que debe ser considerado como un requisito fundamental
en el desarrollo de sistemas de información, y particularmente en el modelo de la BD. Para ello
desarrollaron una metodología muy interesante de diseño de BD seguras, pero a través de un perfil UML
4 http://www.acm.org/
5 http://dblp.uni-trier.de/
6 http://www.google.com
7 http://www.scholar.google.com
8 http://www.ieee.org
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
20
con el fin de poder crear casos de usos seguros. Esta propuesta se basa en una extensión hecha a UML,
y por lo tanto no utiliza como modelado de la BD el modelo ER si no con diagramas de “Casos de Usos”.
Por otra parte Fernández-Medina et al. en [25], crean un modelo de control de acceso para el diseño de
Almacenes de Datos seguros: Control de Acceso y Auditoría (ACA). Este va a ser utilizado en nuestra
propuesta por su flexibilidad y por la facilidad de adaptarse a cualquier modelo conceptual de datos,
además de su fortaleza semántica para poder representar la seguridad desde la primera etapa de diseño.
Integración de la seguridad en el proceso de desarrollo de software. Muchas iniciativas han sido
probadas en el orden de lograr estos objetivos [1], pero ninguna de las soluciones son completamente
satisfactorias. Smith [3] propone un modelo de datos semántico para diseñar conceptualmente BD
seguras. Marks et al. [6], por otra parte, proponen una técnica de modelado de objeto multinivel, la cual es
una extensión de la técnica de modelado de objeto en el orden de diseñar multiniveles de BD. Estas dos
iniciativas son ideas interesantes, pero ninguna fue desarrollada completamente. Hall y Chapman [18]
propusieron diferentes ideas para integrar la seguridad dentro del proceso de desarrollo de sistemas, pero
ellos solo consideran la seguridad de BD desde el punto de vista criptográfico.
Por otra parte, Lodderstedt et al. [26], aunque investigaron sobre la seguridad de los sistemas distribuidos
al modelarlos con UML, modelan la seguridad con el control de acceso basado en roles que está muy de
moda hoy en día, dejando claro las ventajas que ofrece la elección de este modelo para representar la
seguridad. Esta propuesta se ha tomado como referencia para la dar solución a la problemática en
cuestión. También refiriéndose a esta política de control de acceso, en [27] afirman que los procesos
necesitan el soporte de las políticas de seguridad basadas en asuntos, como accesos basados en
competencias, conflictos de reglas de interés, o el acceso basado en un contexto estricto de menor
privilegio. Soportando tales políticas sin desatender la estructura organizativa, se tiene la posibilidad de
restringir el acceso basado en una función del usuario o rol dentro de la empresa. Por lo que esta política
es de gran importancia para mantener la seguridad de los datos y aplicaciones dentro de una
organización.
Pernul et al. [2] en su artículo proponen un extensión realizada al modelo ER. Plantean que para un
modelado con éxito de la seguridad en las BD es necesario capturar no solo la semántica de los datos,
sino también las propiedades seguridad de estos. La política de seguridad utilizada es un modelo MAC
específicamente diseñado con un multinivel de seguridad Multi Level Security (MLS). La propuesta se
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
21
enfoca más en la implementación de la política de seguridad en las bases de datos y por tanto no se
ajusta a al propósito pues no ofrece un metamodelo formalizado y no llega a realizar la implementación.
El primer intento a usar un modelo conceptual para representar la seguridad semántica está propuesto por
Smith en [3] y [4]. El autor desarrolla el modelo semántico para la seguridad basado en un modelo
conceptual de BD y extiende el lenguaje de restricciones ALICE (propuesto en [28]) que incluye
restricciones de seguridad. El modelo de esta propuesta no está completamente formalizado y no detecta
conflictos existentes en las restricciones.
En [5] y [29] los autores desarrollaron el modelo SPEAR, el cual es un modelo de datos de alto nivel y
similar al modelo ER. El mismo consiste en una descripción informal del dominio de la aplicación y una
especificación matemática formal usando la notación Z. El modelo parece ser poderoso, pero no ofrece
ninguna notación gráfica y tiene limitaciones para detectar conflictos en las restricciones.
Otras extensiones al modelo ER se han realizado en [7] y [30]. La primera propuesta captura la dinámica
limitada que incluye operaciones como „create‟, „find‟ y „link‟ en la representación conceptual de la BD. La
segunda propuesta usa el modelo ER como un parte estática de una aplicación de MLS. Ninguna de las
dos propuestas ofrece un chequeo consistente de las restricciones de seguridad especificadas.
Se puede afirmar por tanto, que de acuerdo a la revisión bibliográfica realizada no se encontró ninguna
propuesta que cumpla con los objetivos de esta investigación.
1.4 Estándares de Object Managment Group (OMG)
El OMG9 es una organización internacional sin ánimos de lucro soportada por 600 socios, incluyendo
vendedores de SI, desarrolladores y usuarios. Fundada en 1989, el OMG promociona la teoría y la
práctica de la tecnología orientada a objetos en el desarrollo del software. Se encarga, además, de la
definición y el mantenimiento de estándares para aplicaciones de la industria de la computación. Algunos
de los estándares definidos por el OMG son: UML, Software Process Engineering Metamodel Specification
(SPEM), Model Driven Architecture (MDA), Query/View/Transformation (QVT), CWM, etc.
9 http://www.omg.org/
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
22
Por otro lado, OMG define una arquitectura basada en cuatro niveles de abstracción que van a permitir
distinguir entre los distintos niveles conceptuales que intervienen en el modelado de un sistema. Esos
niveles se les denominan comúnmente con las iniciales M0, M1, M2 y M3. CWM está concebido para ser
definido en la capa M2, es decir, mediante la definición de metamodelos de la capa M2 cuya instancia sea
el modelo ER con seguridad, además es necesario especificar la necesaria transformación entre ellos.
En la Figura 1.10 se muestra la arquitectura de 4 capas para el modelado definida por el OMG. En la parte
superior de la arquitectura aparece el meta-metamodelo (MOF) que define un marco y un lenguaje
abstracto para especificar y construir metamodelos. Esta es la fundación para definir cualquier lenguaje de
modelado tales como UML o aún el mismo CWM. Todos los metamodelos estándar o personalizados
definidos por MOF son situados en la capa M2, como por ejemplo, UML, CWM, SPEM, etc. Los modelos
del mundo real, representados por conceptos definidos en el correspondiente metamodelo de la capa M2,
como por ejemplo metamodelos UML, se sitúan en la capa M1. Finalmente, en la capa M0 se sitúan
objetos del mundo real. Por ejemplo, si la clase de MOF (M3) es usada para definir la clase UML Persona
(M2), la cual se usa para definir modelos: Persona (clase UML) [8].
En los siguientes epígrafes se explican brevemente algunos de los estándares contenidos en OMG,
incluyendo el empleado en esta investigación.
Figura 1.10 Arquitectura de 4 capas y estándares de OMG
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
23
1.4.1 Model Driven Architecture (MDA)
MDA es el nuevo paradigma para el desarrollo del software propuesto por el OMG que considera como
artefacto primario a los modelos. Este desarrollo se llama ingeniería de modelos, en ella todo el proceso
de desarrollo del software está guiado por modelos [31]. MDA está basado en la arquitectura de
metamodelado de 4 capas y en varios estándares complementarios de OMG, que se puede ver en la
Figura 1.10. Los estándares son Meta Object Facility (MOF), UML, XML Metadata Interchange (XMI). Las
capas son: capa M3 (meta-metamodel), capa M2 (metamodel), capa M1 (model) y capa M0 (instancias).
MDA parte de la idea tradicional y bien establecida de separar la especificación de la operación de un
sistema de los detalles de su plataforma [31]. De este modo, MDA promueve la especificación de un
Modelo Independiente de la Plataforma (Platform Independent Model, PIM) que no contiene información
específica para la plataforma o la tecnología que será usada para desarrollarlo. Este PIM puede ser
transformado en uno o varios Modelos Específicos de Plataforma (Platform Specific Model, PSM), para
incluir información acerca de la tecnología especificada que será usada en el desarrollo sobre una
plataforma específica. Después, cada PSM se transforma en código para ser ejecutado en una plataforma
y obtener el producto software final. Por encima de estos modelos (PIM y PSM), MDA describe un modelo
para la especificación de los requisitos de un sistema, el Modelo Independiente de la Computación
(Computation Independent Model, CIM).
1.4.2 Software Process Engineering Metamodel Specification (SPEM)
El principal propósito de SPEM es dar soporte a la definición de procesos de desarrollo de software,
específicamente a aquellos procesos que incluyen o recomiendan el uso de UML, tales como el proceso
unificado de Rational (Rational Unified Process, RUP) [8], entre otros. SPEM está relacionado
directamente con otras especificaciones del OMG, como los perfiles UML, MOF 1.3, XMI y Workflows [32].
La especificación de SPEM está estructurada como un perfil UML que proporciona un metamodelo
completo basado en MOF, es decir, un único metamodelo construido mediante una extensión de un
subconjunto del metamodelo de UML [32].
1.4.3 Unified Model Language (UML)
UML proporciona un paquete de mecanismos de extensión que permite a los diseñadores adaptar UML a
un dominio, contexto o modelo particular [33]. A continuación se resume cómo se define un perfil UML con
los diferentes elementos que contiene (estereotipos, valores etiquetados y restricciones).
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
24
UML es un lenguaje de modelado general (no orientado a un dominio específico) que proporciona un rico
conjunto de conceptos de modelado y notaciones que responden a las necesidades de los proyectos
típicos de modelado del software. Sin embargo, puede suceder que UML no se adapte correctamente a
algún proyecto y que los usuarios requieran de características adicionales. Para suplir estas necesidades
UML incorpora mecanismos de extensión evitando que los usuarios definan nuevos elementos de
modelado de manera no controlada. De esta manera UML agrega nuevos elementos de modelado al
repertorio del modelador, como también adjunta información adicional a los elementos.
El paquete de mecanismos de extensión de UML es un sub-paquete del metamodelo de UML que
especifica cómo los elementos de un modelo particular se personalizan y se extienden con una nueva
semántica. Esto se realiza mediante estereotipos (stereotypes), valores etiquetados (tagged values) y
restricciones (constraints). Brevemente, un estereotipo define la construcción de un nuevo elemento, un
valor etiquetado especifica una nueva propiedad de un elemento existente o de uno nuevo y una
restricción describe la semántica de los nuevos elementos. Un conjunto coherente de tales extensiones,
definidas para un propósito específico constituye un perfil UML. Por ejemplo, UML incluye un perfil
estándar para el modelado de los procesos de desarrollo del software y otro para el modelado del negocio.
La especificación de la superestructura de UML (UML Superstructure Specification) define dos tipos de
mecanismos de extensión para UML 2.0 [33]: (1) el mecanismo de perfiles, que no es un mecanismo de
extensión de primera clase (es decir, no permite la modificación de metamodelos existentes) y (2) la
extensibilidad de primera clase, manipulada a través de MOF, en la cual no hay restricciones en lo que se
permite hacer con un metamodelo (es posible agregar y quitar metaclases y relaciones tanto como sea
necesario).
1.4.4 Common Warehouse Metamodel (CWM)
El principal propósito de CWM es permitir el almacenamiento de los metadatos de inteligencia del negocio
y el fácil intercambio entre las herramientas de almacenaje, las plataformas de almacenaje y los
repositorios de metadatos en ambientes heterogéneos y distribuidos [34]. CWM está basado en los tres
estándares de la industria:
i) UML - un estándar de OMG para el modelado,
ii) MOF - Meta Object Facility, un estándar de OMG para el metamodelado y repositorio de metadatos, y
iii) XMI - XML Metadata Interchange, un estándar de OMG para el intercambio.
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
25
El estándar UML define un rico lenguaje de modelado que está soportado por un amplio rango de
herramientas de diseño gráfico. El estándar MOF define un marco extensible para definir modelos para
metadatos y ofrecer herramientas con interfaces programables para almacenar y poder acceder a los
metadatos en un repositorio. El estándar XMI permite que los metadatos sean intercambiados mediante
un flujo o mediante ficheros con un formato estándar basado en XML. CWM ha sido diseñado para
ajustarse al modelo MOF perteneciendo al metamodelo de la capa M2.
CWM está organizado en 21 paquetes separados, agrupados en cinco capas escalables por medio de
roles similares, como se muestra en la Figura 1.11. Para ver más detalles se puede consultar [34].
Figura 1.11 Capas del metamodelo de CWM con sus paquetes
Dentro de sus paquetes, y debido a su importancia como un diseño y modelo de herramienta, el CWM
incluye al modelo ER, desde el cual los modelos de la herramienta individuales pueden derivar sus
extensiones específicas; mejorando así, hasta el punto en que pueden intercambiarse modelos de ER
entre los varios ambientes de herramientas. En la Figura 1.12 se muestra el paquete de Entity
Relationship de CWM.
El paquete Entity Relationship depende de los siguientes paquetes:
org.omg::CWM::Core
org.omg::CWM::Relationships
org.omg::CWM::Foundation::Expressions
org.omg::CWM::Foundation::KeysIndexes
Muchos de los conceptos del modelo ER mapean directamente con los conceptos equivalentes de CWM,
haciendo parecer las clases ER solo un renombramiento de las clases de CWM. Sin embargo, el cambio
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
26
de nombre proporcionado por la derivación de las clases del modelo ER desde las clases apropiadas de
CWM es considerado valioso para promover la comprensión [35].
Figura 1.12 Paquete Entity-Relationship de CWM
1.5 Método de Investigación en Ingeniería de Software empleado
En este epígrafe se presenta la metodología de trabajo que ha sido utilizada para dar cumplimiento a los
objetivos planteados en un principio, la cual consiste en la aplicación del método de investigación
cualitativo conocido como Investigación-Acción (Action-Research). En los siguientes sub-epígrafes se
explica cómo se aplicó este durante la extensión de CWM desarrollada.
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
27
1.5.1 Investigación cualitativa: Investigación- Acción
La Investigación-Acción como método de investigación cualitativa tiene una doble finalidad: por una parte
generar un beneficio al “cliente” de la investigación y, al mismo tiempo, generar “conocimiento de
investigación” relevante [10].
En un análisis más formal de los participantes en Investigación-Acción, Wadsworth [36] identifica los
siguientes cuatro tipos de roles en este método (en algunas ocasiones la misma persona o equipo puede
desempeñar más de un rol):
a) El investigador, que es el individuo o grupo que lleva a cabo de forma activa el proceso investigador.
b) El objeto investigado, es decir, el problema a resolver.
c) El grupo crítico de referencia, aquel para quien se investiga desde la perspectiva que tiene un problema
a resolver. Participa en el proceso de investigación (aunque menos activamente que el investigador).
d) El beneficiario (stakeholder), aquel para quien se investiga en el sentido de que puede beneficiarse del
resultado de la investigación, aunque no participa directamente en el proceso. Puede ser el receptor de
documentos, informes, etc. En este grupo, por ejemplo, caben tanto las empresas que se benefician de un
nuevo método para resolver problemas en tecnologías de la información, como los técnicos que aplican
dicha metodología.
Por otro lado, se puede distinguir varios tipos de Investigación-Acción [37].
De diagnóstico: el investigador se adentra en una situación problemática, la diagnostica y realiza
recomendaciones al grupo crítico de referencia, pero sin que haya un control posterior de sus
efectos.
Participativa: el grupo crítico de referencia pone en práctica las recomendaciones realizadas por el
investigador, compartiendo con él sus efectos y resultados.
Empírica: el grupo crítico de referencia realiza un registro amplio y sistemático de sus acciones y
sus efectos. Esta característica hace que esta variante sea difícilmente aplicable.
Experimental: consiste en evaluar las diferentes opciones que existen para conseguir un objetivo.
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
28
Un proceso de investigación que emplea Investigación-Acción se halla compuesto de grupos de
actividades organizadas formando un ciclo característico (Figura 1.13). Los siguientes pasos, deben
seguirse en las investigaciones que utilicen este método [38].
i. Planificación: se identifican las cuestiones relevantes, que guiarán la investigación, las cuales deben
estar directamente relacionadas con el objeto que se está investigando y ser susceptibles de encontrarles
respuesta.
ii. Acción: se realiza la variación de la práctica, de forma cuidadosa, deliberada y controlada. Se efectúa
una simulación o prueba de la solución. Es cuando el investigador interviene sobre la realidad.
iii. Observación: se recoge la información, se toman datos y se documenta lo que ocurre. Esta
información puede proceder prácticamente de cualquier sitio (bibliografía, medidas, resultados de
pruebas, observaciones, entrevistas, documentos, etc.). También se conoce como “evaluación”.
iv. Reflexión: se comparten y analizan los resultados con el resto de los interesados, de tal manera que se
invite al planteamiento de nuevas cuestiones relevantes. También se conoce como “especificación del
aprendizaje”. En algunas variantes de Investigación-Acción no es una etapa realmente, sino un proceso
continuo que ocurre durante todo el tiempo.
1.5.2 Aplicación del método Investigación-Acción
Como se planteó anteriormente el objetivo general de esta tesis es el de “elaborar una extensión de
CWM que permita representar la seguridad en el modelo Entidad-Relación”. Por ello, se ha
considerado que el tipo de Investigación-Acción más adecuado para dichos propósitos es la variante
Participativa. Siguiendo el criterio de Wadsworth [36] se definieron los roles participantes en la
investigación de de la siguiente manera:
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
29
Figura 1.13 Carácter cíclico de Investigación- Acción
a) Investigador: corresponde al propio estudiante, asesorado por los tutores de la tesis.
b) Objeto investigado: el modelo ER seguro, la seguridad durante esta fase de modelado.
c) Grupo crítico de referencia: forman parte de este grupo los propios tutores del trabajo en su empeño por
la mejora constante del resultado final, así como los asistentes a los eventos donde se ha presentado el
mismo.
d) Beneficiarios: serán todas aquellas organizaciones o empresas que puedan beneficiarse de los
resultados del trabajo, es decir, todas aquellas empresas de desarrollo y mantenimiento del software que
disponen de BD.
La aplicación del método Investigación-Acción al objeto investigado ha seguido los pasos propuestos por
Padak y Padak ([38]) de la siguiente forma:
Planificación: una vez conocida la problemática de elaborar una extensión de CWM que permita
representar la seguridad en el modelo ER, la solución más adecuada sería analizar el metamodelo
seleccionado para así poder realizar la extensión. Esta planificación también presupone el
desarrollo de un add-in prototipo como prueba de conceptos.
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
30
Acción: una vez identificados los requisitos se elabora la extensión. Después se procede a
aplicarla, con el diseño e implementación de la herramienta prototipo para la representar la
seguridad en el modelo ER.
Observación: a partir de que se establezca la extensión y se desarrolle el prototipo, se procede a
refinarlos y optimizarlos, producto de una evaluación del trabajo realizado y su aplicación a partir
de un caso de estudio.
Reflexión: en esta primera fase los resultados se han compartido con el grupo crítico de referencia
con el fin de plantear nuevas cuestiones relevantes y profundizar en el conocimiento adquirido.
Con tales propósitos, los resultados se han presentado en el Fórum de Ciencia y técnica de la
Facultad de Ciencias Económicas e Informática. Ha sido expuesto también, en la Jornada
Científica de la Facultad de Informática y fue aceptado para formar parte del programa científico de
VI Convención Científica Internacional de la Universidad de Matanzas (CIUM 2011).
1.6 Conclusiones del Capítulo
En este capítulo se ha presentado de manera crítica todo el soporte teórico-metodológico y las tecnologías
que permitieron desarrollar dicha investigación. En este epígrafe se presenta un breve resumen de los
principales aspectos que han sido analizados en el capítulo.
Se comprobó que el modelo ER para el diseño de BD expresa la semántica de los datos desde un nivel
más abstracto.
Se analizó la necesidad de tener en cuenta la seguridad desde etapas tempranas de diseño.
Diversas propuestas de extensión del modelo ER han sido realizadas. Una de ellas se enfoca en el
modelado de BD segura aunque no se han formalizado ni se ha llegado a la obtención de un código
seguro a través de una herramienta CASE. Otras se han enfocado en realizar extensiones a este modelo
de datos y tienen en cuenta la seguridad pero con muchas imprecisiones. Algunas han tenido en cuenta la
seguridad de las BD pero con extensiones realizadas a UML y no al modelo ER. Por lo que en la revisión
bibliográfica realizada no se encontró ninguna proposición que responda a los objetivos de la
investigación.
Capítulo I: Fundamentación teórica de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
31
Se describieron las herramientas CASE más utilizadas actualmente, explicándose de forma exhaustiva la
seleccionada para el propósito general.
Se analizaron los estándares de OMG para la selección del correcto para la solución del problema
planteado.
El método de investigación de Ingeniería de Software utilizado facilitó el estudio de cada uno de los
aspectos durante el desarrollo de esta tesis. En el siguiente capítulo se presenta en detalle la propuesta
de extensión del modelo ER para representar la seguridad así como su implementación en la herramienta
CASE ante mencionada.
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
32
CAPÍTULO II: Elaboración de la extensión de CWM para representar la seguridad
en el modelo Entidad-Relación.
2.1 Introducción.
Diseñar una BD es un proceso costoso en tiempo y más aún si se tiene en cuenta la seguridad de la
misma. Para simplificar la actividad, es necesario mirar la aplicación de la BD a un nivel abstracto usando
el modelo conceptual de datos, o sea el modelo ER. La discusión del Capítulo anterior evidencia que no
se ha formalizado una extensión del modelo ER que represente la seguridad.
En este Capítulo se presenta una propuesta de extensión realizada basada en CWM, la cual permite a los
usuarios diseñar una BD segura, siguiendo con la estructura propuesta en [22]. En el resto del Capítulo se
explican los mecanismos de extensión utilizados por CWM; se presenta el modelo de Control de Acceso
empleado para representar la seguridad; se expone la definición de un add-in prototipo para RR.
2.2 Mecanismos de extensión de CWM.
CWM proporciona mecanismos de extensión para construir metamodelos específicos. Según [39], hay dos
técnicas generales para extender a CWM:
Uso del mecanismo general de extensión que ofrece UML Object Model mediante valores
etiquetados y estereotipos. Esta aproximación es normalmente empleada para extensiones
menores (por ejemplo, para adicionarle atributos al modelo de objetos) que no son lo
suficientemente significativas para requerir la creación de un modelo específico.
Los estereotipos definen elementos adicionales, permitiendo de esta forma fijarle un nuevo
significado semántico a los elementos del modelo.
Los valores etiquetados (Tagged Value) son meta atributos adicionales, que se asocian a un
estereotipo y una restricción describe la semántica de los nuevos elementos.
Las extensiones de modelos no normativas o extensiones modeladas (a veces llamada
extensiones de subclases [35]) documentados como paquetes de metamodelos adicionales que
extienden el metamodelo de CWM. Esta propuesta es utilizada para extensiones más complejas,
ya que el propio CWM está construido siguiendo este tipo de extensión.
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
33
Una técnica adicional de extensión disponible para los desarrolladores de extensiones XMI de
CWM se presenta en [35]. Aunque el uso de las extensiones XMI es una técnica más deseada por
los programadores profesionales, quienes están interesados en construir herramientas específicas
de intercambio para CWM.
2.3 Modelo de Control de Acceso utilizado.
Para el modelado de la seguridad se seleccionó el modelo (ACA) propuesto por Fernández-Medina y et
al., en [25]. A continuación se presenta una visión general del modelo ACA, dada la importancia que tiene
en el desarrollo de esta investigación.
El modelo ACA define la noción de clase de acceso basándose en tres formas diferentes de clasificar a las
entidades y a los usuarios del sistema, esto es, mediante securityLevels (SL), securityRoles (SR) y
securityCompartments (SC). Aunque el modelo también ofrece la posibilidad de definir restricciones de
seguridad (AuditRule, AuthorizationRule y SecurityRule).
Las clases de acceso forman un conjunto parcialmente ordenado de clases, luego, es posible que existan
clases que no puedan se comparadas [25]. Este hecho se evita mediante restricciones bien formadas
(escritas en OCL) que exige el modelo ER cuando se instancia el modelo ACA (para más detalles vea
[25]) se tienen en cuenta las siguientes definiciones de acceso:
Los niveles de seguridad (SL) para un atributo tienen que ser igual o más restrictivo que los niveles
de seguridad para sus clases. La misma regla se aplica a las jerarquías de roles (SR) y categorías
de usuarios (SC).
Cuando una clase SEntity se especializa en varias subclases SEntity, los niveles de seguridad de
las subclases tienen que ser iguales o más restrictivos que los niveles de seguridad de las clases.
La misma regla se aplica a las jerarquías de roles (SR) y categorías de usuarios (SC).
Si la clase A tiene una asociación del tipo 1..n con la clase B, significa que la información de A
agrupa información de B, de esta manera B es más específica que A. El nivel de seguridad de la
clase B tiene que ser más restrictivo que el nivel de seguridad definido para la clase A. La misma
regla se aplica a las jerarquías de roles (SR) y categorías de usuarios (SC).
Teniendo en cuenta el concepto de clase de acceso se define la noción de información de seguridad más
(o menos) restrictiva. Obsérvese en las restricciones anteriores, cómo se aplica el concepto de
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
34
información de seguridad más restrictiva entre una entidad y cualquiera de sus atributos, y entre dos
entidades de un modelo ER.
El modelo ACA describe un mecanismo de control de acceso basado en la confidencialidad y la auditoría
para los Almacenes de Datos y BD, pero es muy flexible y adaptable a cualquier modelo conceptual. El
modelo se basa en la combinación del modelo MAC (en forma de política de seguridad multinivel) y de un
modelo RBAC que permiten la clasificación de las entidades y usuarios del sistema. Esta clasificación usa
clases de acceso basadas en tres formas diferentes pero compatibles a la hora de clasificar usuarios: por
su nivel de seguridad, por su rol y por su categoría. Una clase de acceso es un elemento de un conjunto
de clases parcialmente ordenado, donde una clase de acceso c1 domina una clase de acceso c2 si y sólo
si el nivel de seguridad de c1 es mayor o igual que el nivel de seguridad de c2, las categorías de c1
incluyen a las de c2 y, al menos, uno de los roles de usuario de c1 se define para c2. Para poder
especificar un modelo ACA, se deben definir las siguientes clases:
Roles de seguridad de usuario: usado por una compañía para organizar usuarios según una
estructura jerárquica, dependiendo de las responsabilidades de cada tipo de trabajo. Cada usuario
puede tener más de un rol.
Niveles de seguridad: indican el nivel de acreditación del usuario. Usualmente, corresponde a un
elemento de un conjunto ordenado jerárquicamente, tal como Top Secret (TS), Secret (S),
Confidential (C) y Unclassified (U), donde TS > S > C > U.
Categorías de seguridad de usuario: indican una clasificación horizontal de usuarios atendiendo a
ciertos criterios como localización geográfica o área de trabajo. Cada usuario puede pertenecer a
una o más categorías.
2.4 Extensión propuesta.
Como se analizó en la sección 1.4 del Capítulo I dentro de los estándares de OMG se encuentra el
estándar CWM que dentro de sus paquetes contiene al modelo ER. Desde este, se pueden derivar sus
extensiones específicas [34].
Para representar requisitos de seguridad a nivel conceptual se necesita introducir nuevas clases y
asociaciones, por ello, la extensión no normativa es el mecanismo preferido, pues no se trata de una
simple extensión [35]. La extensión que se realiza al paquete Entity-Relationship de CWM constituye una
extensión no-normativa.
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
35
Esta extensión del paquete Entity-Relationship de CWM define nuevas metaclases para poder representar
a nivel conceptual todos los requisitos de seguridad y auditoría de las BD.
2.4.1 Herencia
En la Figura 2.1 se muestran en color gris las nuevas metaclases que conforman el modelo ER seguro.
Las metaclases SEntity y UserEntity especializan a la metaclase Entity. La metaclase UserEntity una vez
instanciada almacenará la información de los usuarios con acceso al sistema, estos derechos son
especificados por SecurityProperty (securityLevel, securityCompartment y securityRole). SEntity y
SAttribute tienen asociada información de seguridad mediante SecurityProperty (securityLevel,
securityCompartment y securityRole). Además SecurityProperty (securityLevel, securityCompartment y
securityRole) especializa a la metaclase Entity, que a la vez esta se especializa en la metaclase Class del
Core, y con ella se establecen las propiedades de acceso sobre entidades y atributos que el usuario debe
cumplir para poder acceder mediante los valores de securityLevel, securityCompartment y securityRole.
Por otra parte, AuditConstraint es útil para analizar y registrar los accesos a entidades y atributos
realizados por los usuarios durante el uso del sistema, mientras que ARConstraint permite definir reglas
para especificar las políticas de seguridad multinivel en tablas y columnas. AURConstraint, puede coexistir
con ARConstraint para especificar el acceso a tablas y columnas, de esta manera permite definir modelos
de seguridad mucho más elaborados. La metaclase SecurityConstraint, como sugiere el nombre de la
clase, hereda propiedades de la clase Constraint del Core. Los tipos de datos se estudian más a fondo en
la siguiente sección.
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
36
Figura 2.1 Herencia en el metamodelo del modelo ER seguro
2.4.2 Nuevos tipos de datos
En general, los paquetes de CWM solo soportan atributos cuyos tipos de datos son considerados
necesarios para el intercambio de información entre sistemas [39]. Para representar a nivel conceptual
información de seguridad y auditoría se necesitan nuevos tipos de datos. En la Figura 2.2 aparecen en
color gris las nuevas metaclases, que en un caso heredan de DataType y en otro de Enumeration. Estos
nuevos tipos de datos son necesarios para modelar tanto propiedades de acceso (mediante
securityProperty) como requisitos y restricciones (mediante SConstraint) a SEntity, UserEntity y SColumn.
La metaclase SequenceType representa un tipo de dato que permite especificar todos los niveles de
seguridad que pueden ser usados por los elementos del modelo (ordenados del menos al más restrictivo).
Asimismo, Level es una enumeración ordenada compuesta por todos los niveles de seguridad
considerados (unclassified, confidential, secret y top Secret), y Compartment es una enumeración
compuesta por todas las categorías de usuario consideradas. Por otro lado, Privilege es una enumeración
compuesta por todos los privilegios considerados (read, insert, delete, update, all); mientras que Attempt
es una enumeración compuesta por los diferentes tipos de accesos considerados (all, frustratedAttempt,
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
37
successfullAccess, none). Finalmente, Levels es un intervalo de niveles de seguridad compuesto por
lowerlevel y upperlevel. Si esos niveles de seguridad coinciden, todas las instancias tendrán el mismo
nivel de seguridad. En caso contrario, el nivel específico será definido de acuerdo a una
securityConstraint.
OCLExpression define una expresión Object Constraint Language (OCL) que tienen que cumplir los
usuarios del sistema en alguna condición.
Role representa una jerarquía de roles definida. SetRoleType especifica un conjunto de roles de usuarios.
Así cada rol es la raíz de un sub-árbol en la jerarquía de roles considerada. SetCompartmentType
representa al conjunto de compartments definidos por la organización. SetPrivilegeType especifica los
privilegios que un usuario puede recibir o perder. La clase SetOCLType especifica las entidades
involucradas en una consulta realizada por un usuario del sistema. SetLogInfo especifica los elementos
que se quieren registrar para una futura auditoría, normalmente se refiere al sujeto que solicita el acceso
(subjectID), las entidades o atributos accedidas (objectID), la operación solicitada (action), el tiempo de la
solicitud (time) y el responsable del control de acceso (response).
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
38
Figura 2.2 Nuevos tipos de datos para el modelo ER seguro
2.4.3 Nuevas metaclases seguras y principales asociaciones
La extensión propuesta define a las metaclases SEntity y UserEntity que heredan de Entity. La metaclase
UserEntity contiene los atributos necesarios para especificar las propiedades de acceso (SecurityProperty)
que tiene el usuario. UserEntity a diferencia de SEntity es única y no tiene asociación con el resto de las
entidades del sistema.
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
39
Figura 2.3 Nuevas metaclases y asociaciones
Para representar medidas de seguridad y auditoría en el nuevo metamodelo, se han agregado algunas
metaclases al modelo ER de CWM. La metaclase SecurityProperty hereda de la metaclase Class (del
Core) y se especializa como las metaclases SecurityLevels, SecurityCompartments y SecurityRoles.
Además, para representar las restricciones de seguridad, reglas de autorización y reglas de auditoría, en
el nuevo metamodelo se han añadido las metaclases ARConstraint, AURConstraint y AuditConstraint que
heredan de SecurityConstraint. Para especificar las restricciones dependiendo de una información
particular de un usuario o un grupo de usuarios, se introduce la metaclase UserEntity. Obsérvese en la
Figura 2.3 las nuevas metaclases que se han añadido al paquete relacional de CWM, así como las nuevas
asociaciones entre ellas. Las nuevas clases contienen metaatributos cuyos tipos aparecen especificados
en la Figura 2.2. Estos metaatributos permiten representar toda la información de seguridad capturada
durante la etapa del modelado conceptual de las BD.
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
40
2.5 Definición de un add-in prototipo para Rational Rose
Para la definición del add-in prototipo fue necesario definir nuevos estereotipos y valores etiquetados,
definiciones explicadas en el epígrafe anterior.
Para ello se definieron once estereotipos. De ellos, uno fue especializado como un paquete
(RolePackage) en el modelo. Como Class se especificaron cuatro (SecurityEntity, SecurityWeakEntity,
UserEntity, EREntity), así como otras cuatro se definieron como Attribute (ERAttribute, KeyAttribute,
SecurityKeyAttribute, SecurityAttribute). También se han definido un AssociationClass (AssociationEntity)
y el estereotipo Relationship se ha definido como Association. Además se especificaron tres valores
etiquetados que son aplicados a determinado elemento dentro de la extensión, los cuales están asociados
a Class y Attribute. En la Tabla 2 se definen más detalladamente los valores etiquetados.
2.5.1 Estereotipos
Los estereotipos son representados gráficamente dentro de cajas, definidos con la palabra
<<stereotype>>, mediante figuras creadas para cada estereotipo o la unión de ambos; en la Figura 2.4 se
muestran las diversas formas de representación de un estereotipo. En la Figura 2.5 se muestran las
imágenes creadas para los nuevos estereotipos. En la Tabla 1, siguiendo la estructura que propone Luján
en [22], se muestran los estereotipos de la extensión. Estos estereotipos heredan de Class, Attribute,
AssociationClass y Association.
Figura 2.4 Diferentes formas de representación de un estereotipo
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
41
Figura 2.5 Figura de los estereotipos definidos
Tabla 1 Estereotipos de la extensión
Estereotipo de AssociationClass
Nombre: AssociationEntity
Clase Base: Association Class
Descripción: Las clases de este estereotipo representan entidades en el MER.
Icono: Figura 2.5h)
Restricciones: -Todos los atributos de AssociationEntity tienen que ser ERAttribute o SecurityAttribute Self.feature-> select(fe| fe.ocllsKindOf(Attribute))->forAll(f|f.oclIsTypeOf(ERAttribute) or f.ocllsTypeOf(SecurityAttribute)) -Los finales de una AssociationEntity tiene que ser SecurityEntity. Self.connection.participant->exist(me| me.oclIsTypeOf(SecurityEntity)) and self.connection->exist(me|me.oclIsTypeOf(SecurityEntity))
Valores Etiquetados:
Ninguno
Estereotipos de Class
Nombre: SecurityEntity
Clase Base: Class
Descripción: Las clases de este estereotipo representan entidades seguras en el MER.
Icono: Figura 2.5i)
Restricciones: -Una entidad tiene al menos un atributo llave (que puede ser seguro o no), si tiene más de uno tienen que ser diferentes entre sí.
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
42
Self.feature->select(fe|fe.oclIsTypeOf(Attribute))-> select(f|f.oclIsTypeOf(KeyAttribute) or f.ocllsTypeOf(SecurityKeyAttribute))-> size>=1 -Una SEntity pude relacionarse con una ella misma, con una WeakEntity y con una AssociationClass Self.allOppositeAssociationEnds->forAll(ae|ae.participant.ocllsTypeOf(SecurityEntity) or ae.participant.oclIsTypeOf(SecurityWeakEntity) -Todos los atributos de una SecurityEntity tienen que ser ERAttribute, SecurityAttribute, SecurityKeyAttribute, KeyAttribute. Self.feature->select(fe|fe.oclIsTypeOf(Attribute))-> select(f|f.oclIsTypeOf(KeyAttribute) or f.ocllsTypeOf(SecurityKeyAttribute) or f.ocllsTypeOf(SecurityAttribute) or f.oclIsTypeOf(ERAttribute)) -Una SecurityEntity puede solo heredar de otra SecurityEntity Self.generalization->size>0 implies self.generalization.parent-> forAll(me| me.oclIsTypeOf(SecurityEntity)) -Una SecurityEntity puede solo ser hijo de otra SecurityEntity Self.specialization->size>0 implies self.specialization.child-> forAll(me| me.oclIsTypeOf(SecurityEntity))
Valores Etiquetados:
SL, SC, SR.
Nombre: SecurityWeakEntity
Clase Base: Class
Descripción: Las clases de este estereotipo representan entidades débiles seguras en el MER.
Icono: Figura 2.5j)
Restricciones: -Una SecurityWeakEntity puede tener un atributo llave (que puede ser seguro o no), si tiene más de uno tienen que ser diferentes entre sí. Self.feature->select(fe|fe.ocllsTypeOf(Attribute))-> select(f|f.oclIsTypeOf(KeyAttribute) or f.ocllsTypeOf(SecurityKeyAttribute))-> size<=1 -Una SecurityWeakEntity pude relacionarse con una ella misma y con una SecurityEntity Self.allOppositeAssociationEnds->forAll(ae|ae.participant.oclIsTypeOf(SecurityEntity) or ae.participant.ocIlsTypeOf(SecurityWeakEntity) -Todos los atributos de una SecurityWeakEntity tienen que ser ERAttribute, SecurityAttribute, SecurityKeyAttribute, KeyAttribute. Self.feature->select(fe|fe.ocllsTypeOf(Attribute))->
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
43
select(f|f.oclIsTypeOf(KeyAttribute) or f.ocllsTypeOf(SecurityKeyAttribute) or f.ocllsTypeOf(SecurityAttribute) or f.ocllsTypeOf(ERAttribute)) -Una SecurityWeakEntity puede solo heredar de otra SecurityWeakEntity Self.generalization->size>0 implies self.generalization.parent-> forAll(me| me.oclIsTypeOf(SecurityWeakEntity)) -Una SecurityWeakEntity puede solo ser hijo de otra SecurityEntity Self.specialization->size>0 implies self.specialization.child-> forAll(me| me.oclIsTypeOf(SecurityWeakEntity))
Valores Etiquetados:
SL, SC,SR
Nombre: UserEntity
Clase Base: Class
Descripción: Las clases de este estereotipo representan entidades de usuarios en el MER.
Icono: Figura 2.5g)
Restricciones: -Es única. Inv self.classes->forAll(oclIsTypeOf(UserEntity)->size()<=1) - No tiene relación con ninguna otra entidad ni con ella misma. Self.AssociationEnd.size()=0
Valores Etiquetados:
Ninguno
Estereotipos de Attribute
Nombre: ERAttribute
Clase Base: Attribute
Descripción: Atributos que representan características de alguna entidad o relación.
Icono: Figura 2.5d)
Restricciones: -Pude pertenecer solo a SecurityEntity, SecurityWeakEntity, UserEntity y AssociationEntity. Self.owner.oclIsTypeOf(SecurityEntity) or Self.owner.oclIsTypeOf(SecurityWeakEntity) or Self.owner.oclIsTypeOf(UserEntity) or Self.owner.oclIsTypeOf(AssociationEntity)
Valores Etiquetados:
Ninguno
Nombre: SecurityAttribute
Clase Base: Attribute
Descripción: Atributos que representan características con seguridad de alguna entidad o relación.
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
44
Icono: Figura 5c)
Restricciones: -Pude pertenecer solo a SecurityEntity y SecurityWeakEntity,. Self.owner.oclIsTypeOf(SecurityEntity) or Self.owner.oclIsTypeOf(SecurityWeakEntity)
Valores Etiquetados:
SL, SC, SR.
Nombre: KeyAttribute
Clase Base: Attribute
Descripción: Atributos que representan características e identifica de forma única alguna entidad o relación.
Icono: Figura 2.5b)
Restricciones: -Pude pertenecer solo a SecurityEntity, SecurityWeakEntity y UserEntity. Self.owner.oclIsTypeOf(SecurityEntity) or Self.owner.oclIsTypeOf(SecurityWeakEntity) or Self.owner.oclIsTypeOf(UserEntity)
Valores Etiquetados:
Ninguno
Nombre: SecurityKeyAttribute
Clase Base: Attribute
Descripción: Atributos que representan características de alguna entidad o relación.
Icono: Figura 2.5a)
Restricciones: -Pude pertenecer solo a SecurityEntity y SecurityWeakEntity, Self.owner.oclIsTypeOf(SecurityEntity) or Self.owner.oclIsTypeOf(SecurityWeakEntity) or
Valores Etiquetados:
SL, SR, SC.
Estereotipo de Association
Nombre: Relationship
Clase Base: Association
Descripción: Este estereotipo representa la relación que se establece entre SecurityEntity, SecurityWeakEntity, AssociationEntity.
Icono: Figura 2.5f)
Restricciones: -Los finales de una Relationship pueden ser: SecurityEntity, SecurityWeakEntity y AssociationEntity. Self.connection.participant-> forAll(pa|pa.oclIsTypeOf(SecurityEntity) or pa.oclIsTypeOf(SecurityWeakEntity) or pa.oclIsTypeOf(AssociationEntity))
Valores Etiquetados:
Ninguno
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
45
2.5.2 Valores etiquetados
Los valores etiquetados definidos en la extensión se muestran en la tabla siguiente según la estructura
propuesta por Luján en [22].
Tabla 2 Valores etiquetados definidos
Valores etiquetados del modelo ER
Valor Etiquetado Tipo de dato Multiplicidad Descripción
SL Levels 1 Especifica los diferentes
niveles de seguridad.
SR SetRoleType 1 Especifica los diferentes roles.
SC SetCompartmetType 1 Especifica las diferentes
categorías.
2.5.3 Restricciones
Las restricciones se encuentran asociadas a los estereotipos, y valores etiquetados. Su función es
restringir o adicionar determinadas acciones de los elementos del metamodelo, por lo que permiten refinar
su semántica. Mediante las restricciones se verifica si el modelo definido está “bien formado” [22]. Pueden
ser expresadas en lenguaje natural o en OCL, en este caso han sido expresadas de las dos formas.
2.5.4 Reglas bien formadas
Las reglas bien formadas son presentadas en lenguaje natural e implementadas en OCL. Estas reglas
especifican restricciones adicionales sobre la extensión presentada. En este proyecto se han especificado
las siguientes:
Todas las clases en el modelo ER seguro tienen que ser SecurityEntity, SecurityWeakEntity, UserEntity, AssociationClass o EREntity:
Self.allContents-> forAll( oclIsKindOf(Classes) implies (oclIsTypeOf(SecurityEntity) or oclIsTypeOf(SecurityWeakEntity) or oclIsTypeOf(UserEntity) or oclIsTypeOf(AssociationEntity) or oclIsTypeOf(EREntity) ) )
El paquete utilizado en el modelo ER tienen que ser RolePackage:
Self.allContents-> forAll( oclIsKindOf(Package) implies (oclIsTypeOf(RolePackage) ) ) -> size<=1
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
46
2.6 Implementación del add-in prototipo
El add-in prototipo está compuesto por la definición de 5 ficheros y 32 archivos gráficos para los diferentes
íconos de los estereotipos, tal como lo explica Luján en [22]. Brevemente, los cinco ficheros son:
mer.ini: contiene la definición de los estereotipos.
mer.mnu: contiene la definición de las nuevas opciones de menú con las acciones asociadas (en
este caso, ejecutar el script mervalidate.ebx y el script ddlgenerate.ebx).
mer.pty: contiene la definición de las nuevas propiedades.
mer.reg: contiene las instrucciones necesarias para dar de alta en el registro del sistema operativo
Windows el nuevo add-in. Se tiene que ejecutar una vez (es como un proceso de instalación) y la
próxima vez que se ejecute Rational Rose estarán disponibles los nuevos estereotipos.
mervalidate.ebs: contiene el código de script que valida un modelo.
mervalidate.ebx: es la versión compilada del fichero anterior.
ddlgenerate.ebs: contiene el código que va a generar un fichero con extensión .sql el cual contiene
instrucciones SQL.
ddlgenerate.ebx: es la versión compilada del fichero anterior.
2.6.1 Registro
El archivo mer.reg contiene el registro que instala el add-in en el sistema [22]. Una vez que el add-in haya
sido instalado, el Add-In Manager, que se encuentra en la barra de herramientas de Rational Rose,
permite al usuario activarlo o desactivarlo, como se puede ver en la Figura 2.6. En la Tabla 3 se muestra el
código que ejecuta el fichero cuando se importa en el registro.
El archivo de registro actualiza el registro de Microsoft Windows:
Creando una sub-llave de registro para el add-in.
Puebla la sub-llave con los valores y nombres apropiados (por ejemplo, InstallDir, MenuFile, entre
otros).
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
47
Adiciona el nombre del archivo de configuración del estereotipo (.ini) a la sub-llave llamada
StereotypeCfgFile.
Figura 2.6 Add-In Manager en Rational Rose
Tabla 3 Código que ejecuta el archivo mer.reg
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Rational Software\Rose\AddIns\MER]
"Active"="Yes"
"Company"="SLM"
"Copyright"="Copyright © 2012 Annalie Barreras González"
"InstallDir"="C:\\Archivos de programa\\Rational\\Rose\\MER"
"LanguageAddIn"="No"
"MenuFile"="mer.mnu"
"PropertyFile"="mer.pty"
"StereotypeCfgFile"="mer.ini"
"ToolDisplayName"="MER Modeling"
"ToolName"="MER Modeling"
"Version"="1.0"
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
48
En la Figura 2.7 se muestra parte del registro de Microsoft Windows después de haber registrado el add-
in.
2.6.2 Archivo de Configuración
mer.ini es el archivo de configuración que personaliza los nuevos estereotipos con sus correspondientes
íconos.
En la Figura 2.8 se muestra el código para la definición general de los estereotipos. En la Figura 2.9 se
muestran los códigos correspondientes a un estereotipo de tipo class y a otro de tipo attribute. El resto de
las definiciones se pueden ver en los Anexos.
Figura 2.7 Sub-llave del add-in creado en el registro de Microsoft Windows
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
49
Figura 2.8 Definición general para los estereotipos
Figura 2.9 Definición de un estereotipo de tipo class y otro de tipo attribute
2.6.3 Definición de etiquetas
El archivo de propiedad mer.pty define un espacio de nombre para estas propiedades y una etiqueta en el
editor de especificación para tener las herramientas personalizadas, conjuntos y propiedades. Asimismo,
el add-in prototipo define dos nuevos conjuntos de propiedades: para un elemento class y para un
elemento attribute. El código que se ejecuta para la creación de estas nuevas propiedades se observa en
la Figura 2.10.
En la Figura 2.11 se muestra la nueva “etiqueta” que se adiciona a la especificación de un elemento class.
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
50
Figura 2.10 Código para especificar las nuevas propiedades (valores etiquetados)
Figura 2.11 Nuevas propiedades para un elemento class
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
51
2.6.4 Elementos del menú
El fichero mer.mnu, como se ve a continuación, define los nuevos elementos del menú que son
adicionados a las herramientas del menú de RR.
El código por el que se obtiene los nuevos elementos del menú se expone a continuación, en la Figura
2.12.
Figura 2.12 Código para obtener nuevos elementos de menú
2.6.5 Fichero de validación y fichero de obtención de código
Los archivos mervalidate.ebs y ddlgenerate.ebs contienen los códigos Rose Script del add-in prototipo.
El primero valida las restricciones que acarrea el modelo y es diseñado siguiendo el REI, metamodelo
explicado en el epígrafe 1.2.5.1.1 del Capítulo I. El segundo genera código SQL de lenguaje de definición
de datos o DDL por sus siglas en inglés Data Definition Language; es utilizado para la descripción de las
estructuras de información y los programas que se usan para construir, actualizar e introducir la
información que contiene una BD. Este último tiene extensión .sql que luego puede ser ejecutado en el
SGBD SQL Server.
A continuación, sólo se mostrarán fragmentos del procedimiento principal de los ficheros mervalidate.ebs
y ddlgenerate.ebs en la Figura 2.13 y Figura 2.14 que se ejecutan cuando es seleccionada la opción
MER Validate y MER DDL Generate respectivamente.
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
52
Figura 2.13 Procedimiento principal de MER Validate
Figura 2.14 Procedimiento principal de MER DDL Generate
Capítulo II: Elaboración de la extensión de CWM para representar la seguridad en el modelo Entidad-Relación
52
2.7 Conclusiones del Capítulo
En este Capítulo se presentó la extensión que se propone basada en el estándar CWM que permitió
definir los requisitos de seguridad a nivel conceptual y modelarlos en la herramienta CASE RR, a través
de la definición e implementación de un add-in prototipo para la misma. La extensión contiene los
estereotipos, valores etiquetados y restricciones necesarios para modelar de manera formal el modelo ER
con seguridad.
Capítulo III: Pruebas y funcionamiento del add-in prototipo
53
CAPÍTULO III: Pruebas y funcionamiento del add-in prototipo
3.1 Introducción
En este capítulo se muestran los beneficios de la utilización del add-in de RR para el diseño de BD
segura. Para ello, los desarrollos se aplican a un caso de estudio relacionado con la gestión de
medicamentos de una empresa farmacéutica. El Capítulo desarrolla el caso de estudio utilizando el add-in
definido en el Capítulo anterior para la herramienta RR y, a partir de esta representación se obtiene su
correspondiente implementación en el SGBD SQL Server Express 2005.
3.2 Introducción al caso de estudio
El caso de estudio que se presenta en este Capítulo se corresponde con una empresa farmacéutica que
administra varias farmacias y ofrece el servicio de ventas de medicamentos a la comunidad. Esta empresa
desea analizar los resultados de la venta de medicamentos a través de recetas médicas. Por tanto, se
centra en el proceso de negocio relacionado con las ventas.
En la Figura 3.1 se presenta un esquema general del funcionamiento de la empresa. En cada farmacia se
lleva un estricto control de las ventas de medicamentos mediante recetas médicas, así como de los
medicamentos que están en existencia. Una receta de un paciente contiene los datos del paciente, la
información relacionada con su padecimiento y el medicamento que debe adquirir. Dentro de la empresa
existen varios grupos:
un grupo de vigilancia de fármacos que comprueba el correcto uso de ciertas medicinas,
un comité que vela por la salud de los clientes (pacientes) y, finalmente,
un grupo comercial encargado de gestionar la venta de los medicamentos.
Estos grupos se representan en la Figura 3.1 a través de las siglas GVF (grupo de vigilancia de fármacos),
CSC (comité por la salud de los clientes) y GC (grupo comercial).
Dentro de la empresa existen trabajadores que ocupan diferentes funcionalidades. Existe el empleado que
se especializa a su vez en farmacéutico y no farmacéutico. El farmacéutico es el encargado del correcto
funcionamiento de la farmacia en cuestión, así como de los medicamentos que se les venden a los
pacientes. Este se especializa en técnico y asistente. El asistente es el que se ocupa de la venta de
medicamentos con recetas de las farmacias, así como el número de pacientes que son atendidos en cada
Capítulo III: Pruebas y funcionamiento del add-in prototipo
54
farmacia. Por otro lado, el administrador es el encargado de llevar un estricto control de las farmacias
que maneja la empresa, así como el acceso de los pacientes a cada una. También se encarga de
controlar la venta de medicamentos con recetas que se realizan en cada farmacia.
Figura 3.1 Arquitectura de funcionamiento de la empresa farmacéutica
Otro trabajador es el suministrador, el cual, como su nombre indica, tiene la responsabilidad de
garantizar el adecuado suministro de todos los medicamentos y de estar pendiente de las ventas que se
realizan con recetas médicas.
Para satisfacer las exigencias que presupone el problema anteriormente planteado se requiere del diseño
e implementación de una BD segura. En este tipo de problema que involucra aspectos relacionados con la
salud de la población es vital extremar las medidas de seguridad. Según se han evidenciado durante el
desarrollo de esta tesis, las mismas deben ser consideradas y desarrolladas desde las etapas tempranas
de diseño de la BD hasta las fases de implementación y la validación.
En la sección 3.3 se explica la utilización del add-in de RR. En el resto de las secciones se empleará para
validar el add-in prototipo, obtener el script correspondiente, así como una descripción del empleo del add-
in en RR.
3.3 Utilización del add-in prototipo en el caso de estudio
En el epígrafe 2.6 del Capítulo II, se discutió el desarrollo del add-in prototipo, el cual permite usar el
modelo ER seguro en RR.
Capítulo III: Pruebas y funcionamiento del add-in prototipo
55
En la Figura 3.2 se puede observar la pantalla de RR que muestra el modelo ER seguro del caso de
estudio presentado en el epígrafe anterior. La Figura 3.3 muestra a su vez la jerarquía de roles obtenida
del problema. Algunos comentarios han sido añadidos a la pantalla para resaltar elementos importantes:
los nuevos botones de la barra, los nuevos estereotipos (presentados en el Capítulo anterior) y los nuevos
íconos mostrados en el navegador del modelo.
Figura 3.2 Pantalla de RR: caso de estudio modelado
Capítulo III: Pruebas y funcionamiento del add-in prototipo
56
Figura 3.3 Jerarquía de roles del caso de estudio
También se puede ver en la Figura 3.4, los estereotipos de los atributos así como los valores etiquetados
asociados a las entidades, dándole la confidencialidad que se previó para cada una de ellas.
La confidencialidad que se refiere se observa con los valores etiquetados. En el caso de SL, o
SecurityLevels visto en el Capítulo anterior, contiene el intervalo de seguridad que puede tener cierta
entidad. Por ejemplo, en el caso de la Figura 3.4, SL tiene un nivel de seguridad Confidencial por lo que
sólo pueden tener acceso a esta los que tienen mayor o igual nivel de seguridad. Por otro lado SR, o
SecurityRole, tiene el o los roles que pueden tener algún tipo de permiso sobre esta entidad. Los permisos
considerados van a ser correspondidos en dependencia del nivel que obtenga cada uno de los roles en
esta entidad y pueden ser SELECT, INSERT, UPDATE y DELETE. Para SC, o SecurityCompartment, se
incluye las categorías de usuarios que puedan tener el acceso a esta entidad.
Capítulo III: Pruebas y funcionamiento del add-in prototipo
57
Figura 3.4 Valores etiquetados y estereotipos de los atributos
Todos estos elementos de seguridad se encuentran implementados en el modelo ACA, discutido en el
Capítulo II. En el add-in prototipo, aunque se definen los tres valores etiquetados para cada entidad en la
implementación sólo se tiene en cuenta el SR.
3.4 Obtención de código seguro
Después de desarrollar el caso de estudio propuesto, se está en condiciones de validar cómo el prototipo
de prueba de conceptos permite la generación de código seguro para el SGBD SQL Server Express 2005,
del cual se analizó las funcionalidades que ofrece en cuanto a la seguridad en el epígrafe 1.2.4 del
Capítulo I.
En la Figura 3.5 se observa cómo se procede en RR para generar el script correspondiente al modelo
realizado.
Para la obtención del script del modelo propuesto:
Se realiza el modelo al cual se le quiere extraer el script,
se va al menú MER DDL Generate de la barra de herramientas en la opción Tools, y finalmente,
se especifica la ruta donde se desea guardar el script generado.
Luego de haber obtenido el script en la dirección especificada, se procede a ejecutarlo en el SGBD para
obtener la implementación física del modelo conceptual de BD segura. En la Figura 3.6 se muestra una
primera parte del código derivado. Como resultado, este código permite obtener las nuevas tablas
Capítulo III: Pruebas y funcionamiento del add-in prototipo
58
normalizadas que van a aparecer en la BD, así como sus relaciones (de 1..1, 1..n, n..n, entre otras) con
las otras tablas generadas.
La seguridad asociada al modelo se ve en la Figura 3.7 (este código pertenece al mismo script generado
con las tablas y asociaciones). En ella se observan los roles y los permisos asociados a estos de acuerdo
con el diseño conceptual realizado y la jerarquía de roles detallada en el modelo. Para adicionar estos
permisos a los roles generados se siguió un algoritmo propuesto por los tutores conjunto a la autora de
este trabajo, puesto que desde el nivel conceptual no se tienen en cuentan los permisos. Los permisos
que ha sido asociado a los roles fueron visto en el epígrafe 3.3.
Figura 3.5 Generación de código seguro a partir del add-in prototipo en RR
Capítulo III: Pruebas y funcionamiento del add-in prototipo
59
Figura 3.6 Tablas obtenidas en código SQL
Figura 3.7 Obtención en código SQL de la seguridad asociada al modelo
Capítulo III: Pruebas y funcionamiento del add-in prototipo
60
3.5 Implementación en el SGBD SQL Server Express 2005
Luego de haber obtenido el script correspondiente al modelo del caso de estudio se procede a ejecutarlo
en el SGBD seleccionado para comprobar su validez. En la Figura 3.8 se muestran las tablas obtenidas.
Cada una de ellas contiene sus atributos y la llave primaria de la o las tablas a las que está relacionada.
En la Figura 3.9, se observa al rol Asistente y los permisos que tiene para la tabla Farmacia. Aquí el
diseñador tiene la oportunidad de agregar o rechazar cualquier permiso que necesite y no se obtuvo en el
script derivado. Esto permite que se obtenga una BD con la seguridad incluida, a nivel de Gestor de BD,
facilitando el trabajo de los diseñadores de BD.
Figura 3.8 SQL Server Express 2005 con las tablas obtenidas del script
Capítulo III: Pruebas y funcionamiento del add-in prototipo
61
Figura 3.9 Roles implementados en el SGBD
3.6 Implantación del add-in en Rational Rose
Para registrar el add-in en el registro de Microsoft Windows es necesario primero copiar la carpeta MER
en el directorio de instalación de RR, por ejemplo, dentro de C:\Archivos de programa\Rational\Rose.
Luego se registra el nuevo add-in, siguiendo el camino Inicio\Ejecutar y en la ventana que se muestra se
accede al editor de registro mediante la palabra reservada REGEDIT y luego se importa el fichero con
extensión .reg para instalar el add-in en el sistema, como se explica en el Capítulo anterior.
Capítulo III: Pruebas y funcionamiento del add-in prototipo
62
Ya concluida estas operaciones se procede incluir los nuevos estereotipos en la pantalla principal de RR
para pode trabajar con ellos. En la Figura 3.10 se observa el procedimiento que se realiza para ejecutar
esta acción.
Para que aparezcan los botones que pintan los nuevos estereotipos en el diagrama de clases, es
necesario configurar la barra de herramientas: menú View\Toolbars\Configura\ pestaña Toolbars\pulsar el
botón para UML, en la lista Botones disponibles aparecerán los iconos de los nuevos estereotipos,
agregarlos a la lista Botones de la barra de herramientas.
Figura 3.10 Procedimiento para incluir los botones en el diagrama de clases
Capítulo III: Pruebas y funcionamiento del add-in prototipo
63
3.7 Conclusiones del Capítulo
En este capítulo se ha presentado un caso de estudio basado en el control de la venta de medicamentos a
través de recetas médicas que realiza una empresa farmacéutica, para ejemplificar la aplicabilidad del
modelo ER con la seguridad propuesta en el epígrafe 2.4 del Capítulo II. Después de desarrollar el caso
de estudio se ha explicado cómo el add-in prototipo para prueba de conceptos permite implementar a nivel
físico una BD segura de acuerdo al modelo ER realizado.
Los resultados obtenidos corroboran la factibilidad del prototipo desarrollo con sus nuevas funcionalidades
puesto que se obtiene un script que contiene las tablas y sus relaciones a nivel físico con sólo modelarlas.
También se obtiene en el script los roles y sus respectivos permisos asociados a cada tabla, dándole
seguridad y confidencialidad a la BD que ejecute el script generado.
Conclusiones Generales
64
Conclusiones Generales
En la presente tesis se ha propuesto una extensión de CWM para representar la seguridad en el modelo
ER. La extensión contiene además los necesarios estereotipos, valores etiquetados y restricciones para
modelar de manera formal un modelo ER con la seguridad incluida. Las principales contribuciones de esta
investigación se describen mediante la aportación de nuevos elementos:
Una extensión formal de CWM al modelo ER que permite incluir la seguridad en este.
El desarrollo de un prototipo de prueba de conceptos para la herramienta CASE Rational Rose, lo
que ofrece la posibilidad de generar de manera automática un script, a partir de un modelo, que
contiene las sentencias SQL necesarias para una BD segura.
En esta tesis se definieron diferentes tareas de investigación cuya consecución pretendía cumplir el
objetivo general de: “elaborar una extensión de CWM que permita representar la seguridad en el
modelo ER”. A continuación se presenta una valoración del grado de cumplimiento de las tareas de
investigación realizadas:
Tarea 1. Estudiar y analizar el trabajado relacionado con el objeto de estudio como punto de partida y
antecedentes de la investigación.
Se realizó un profundo análisis del trabajo relacionado con las extensiones realizadas al modelo ER para
incluirle la seguridad (ver apartado 1.3 del Capítulo I). Se comprobó las diversas propuestas encaminadas
a tal propósito, ninguna está formalizada a través de un metamodelo ni proponen automatizar este
proceso a través de un prototipo de herramienta CASE. Lo anterior permitió llegar a la conclusión que es
necesario realizar una extensión formal de un metamodelo que integre las medidas de seguridad en el
diseño conceptual de BD.
Tarea 2. Desarrollar un prototipo para el diseño del modelo ER las restricciones de seguridad incluidas
como prueba de conceptos a la extensión elaborada.
Se describió el desarrollo de un prototipo de la herramienta CASE Rational Rose que implementa como
prueba de conceptos el modelo ER con seguridad propuesto (ver apartado 2.5 del Capítulo II). Se
Conclusiones Generales
65
definieron varios ficheros que constituyen el add-in prototipo, siendo necesario crear nuevos estereotipos y
valores etiquetados. Así, el fichero mer.ini contiene la definición de los estereotipos; el mer.mnu con la
definición de las nuevas opciones de menú; el mer.pty, el mer.reg, el mervalidate.ebs, el mervalidate.ebx,
el fichero dddlgenerate.ebs y ddlgenerate.ebx.
Tarea 3. Comprobar el funcionamiento del add-in prototipo a través de un caso de estudio.
Los beneficios de la utilización del add-in de RR para el diseño de la BD quedan patentes en el capítulo III,
donde se presenta un caso de estudio relacionado con la gestión de medicamentos en una empresa
farmacéutica que administra varias farmacias y ofrece diversos tipos de servicios a la comunidad. Esta
empresa desea analizar los resultados de la venta de medicamentos a través de recetas médicas. Se
demostró que el prototipo de add-in para la prueba de conceptos permite implementar a nivel físico una
BD segura de acuerdo al modelo ER realizado.
Para finalizar, tras haber cumplido todas las tareas de esta tesis, se puede concluir que el objetivo general
propuesto inicialmente (elaborar una extensión de CWM que permita representar la seguridad en el
modelo ER) también se cumplió. Según la búsqueda bibliográfica realizada antes de acometer la
investigación para conocer el estado del arte del tema, se demostró la originalidad de este trabajo ya que
no existía ninguna propuesta que con objetivos similares.
Recomendaciones
66
Recomendaciones
Para la continuidad de la investigación se recomienda:
Continuar implementando los diferentes modelos de control de acceso que permite el modelo ACA
para el add-in.
Generar un script que contenga los modelos de control de acceso que faltan para el SGBD SQL
Server Express 2005.
Referencias Bibliográficas
67
Referencias Bibliográficas
[1] E. Fernández-Medina and M. Piattini, "Designing Secure Data Base," 2004.
[2] G. Pernul, W. Winiwarter, and A. M. Tjoa, "The Entity-Relationship Model for Multilevel Security,"
pp. 12.
[3] S. G. W., "Modeling security-relevant data semantics," in Modeling security-relevant data
semantics, I. T. o. S. Engineering, Ed., 1991, pp. 1195-1203.
[4] S. G. W., "The Semantic Data Model for Security: Represeneting the Security Semantics of an
Application," presented at Proc. of the 6th Int. Conf. on Data Engineering (ICDE'90), 1990.
[5] S. P. J., "The SPEAR Data Dedign Method," presented at Proc. 6th IFIP WG 11.3. Working Conf.
on Database Security, Burnaby, BC, Aug. 1992.
[6] M. D., S. P., and T. B., "MOMT: a multi-level object modeling technique for designing secure
database application," Journal of Object=Oriented Programming 9, pp. 22-29, 1996.
[7] B. R. K., "A Conceptual Model for Multilevel Database Design," presented at Proc. 5th Rome
Laboratory Database Security Workshop, Oct 1992.
[8] E. D. Soler Cárdenas, "SEDAWA: Un proceso de ingeniería dirigido por modelos para el desarrollo
de Almacenes de Datos Seguros," in Departamento de Lenguajes y Sistemas Informáticos.
Alicante: Universidad de Alicante, 2008, pp. 211.
[9] M. D. Myers, "Qualitative research in information systems," pp. 241-242.
[10] N. Kock and F. Lau, "Information systems action research: Serving two demanding masters".: Infor-
mation Technology & People (special issue on Action Research in Information Systems), 2001.
[11] R. Camps Paré, L. A. Castillas Santillán, D. Costal Costa, M. G. Ginestá, C. Martín Escofet, and O.
Pérez Mora, "Bases de Datos", 1era ed. Barcelona, 2005.
[12] C. J. Date, "Introducción a los sistema de Bases de datos", 7ma Edición ed. Cuba, 2003.
[13] P. Chen, "The entity-relationship model, -toward a unified view of data," presented at The
International Conference on Very Large Databases, 1976.
[14] M. Varas, "Modelamiento de datos. Conceptos fundamentales," pp. 80, 1999.
[15] R. Jennings, "Professional ADO.NET 3.5 with LINQ and the Entity Framework". Indiana, 2009.
Referencias Bibliográficas
68
[16] D. Brinkley and R. Schell, "What is there to worry about? An Introduction to thr Computer Security"
Problem M. Abrams, S. Jajodia, H. Podell, 1995.
[17] E. Fernández-Medina, "Seguridad en el diseño de bases de datos y sistemas de información."
[18] H. A. and C. R., "Correctness by construction: Developing a commercial secure system.," I.
Software, Ed., 2002, pp. 18-25.
[19] S. Castano, M. Fugini, G. Martella, and P. Samarati, Database Security, 1994.
[20] IDC, 2002.
[21] V. José, "Herramientas CASE para Bases de datos," 2005.
[22] S. Luján Mora, "Data Warehouse Desing with UML," in Department of Software and Computing
Systems. Alicante: University of Alicante, 2005, pp. 348.
[23] B. C., C. S., and N. S., "Conceptual database desing. An entity-relationship approach". New York:
Addison- Wesley, 1991.
[24] C. T. and B. C., "A practical approach to design, implementation, and management:" Addison-
Wesley, 2002.
[25] E. Fernández-Medina, J. Trujillo, R. Villarroel, and M. Piattini, "Access control and audit model for
the multidimensional modelling of data warehouses," 2004.
[26] T. Lodderstedt, D. Basin, and J. Doser, "Secure UML: A UML-Based Modeling Language for Model-
Driven Security," 2002.
[27] F. David, K. D. Richard, and C. Ramaswamy, "Role-based Access Control (RBAC)," Information
Systems Control Journal, vol. 5, 2004.
[28] U. S. D., "ALICE: an assertion language for integrity constraint expression," presented at Proc.
Computer Software and Appl. Conf., Sep. 1989.
[29] W. S., "Abstract and Concrete Models for Secure Database Applications," presented at Proc. 5th
IFIP WG 11.3. Working Conf. on Database Security, Shepherdstown, WV, Nov. 1991.
[30] G. Pernul, "Security Constraint Processing During MLS Database Design," presented at Proc. 8th
Ann. Computer Security Applications Conf. (ACSAC'92).
[31] O. M. Group, "MDA Guide 1.0.1."
[32] O. M. Group, "SPEM: Software Process Engineering Metamodel Specification."
[33] O. M. Group, "Unified Model Language 2.0."
[34] O. M. Group, "Common Warehouse Metamodel (CWM)", vol. Volume 2. Extensions, 2001.
Referencias Bibliográficas
69
[35] J. Poole, D. Chang, D. Tolbert, and D. Mellor, "Common Warehouse Metamodel". New York:
Robert Ipsen, 2002.
[36] Y. Wadsworth, "What is participatory action research?," Action Research International.
[37] W. L. French and C. H. Bell, "Desarrollo Organizacional", edn 5 ed: Prentice-Hall, 1996.
[38] N. Padak and G. Padak, "Guidelines for planning action research projects."
[39] O. M. Group, "Common Warehouse Metamodel Specification."