Autora: Annalie Barreras González

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


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.


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


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.


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.


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


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.


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).


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


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


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.


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


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).


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


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


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/


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


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).


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.


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


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.


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.


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:


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.


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.


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.


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


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.


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.


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,


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).


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.


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.


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


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í.


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))


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))->


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))


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


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)


Ninguno

Nombre: SecurityAttribute


Descripción: Atributos que representan características con seguridad de alguna entidad o relación.


44

Icono: Figura 5c)

Restricciones: -Pude pertenecer solo a SecurityEntity y SecurityWeakEntity,. Self.owner.oclIsTypeOf(SecurityEntity) or Self.owner.oclIsTypeOf(SecurityWeakEntity)


SL, SC, SR.

Nombre: KeyAttribute


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)


Ninguno

Nombre: SecurityKeyAttribute


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


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))


Ninguno


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


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).


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"


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


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.


50

Figura 2.10 Código para especificar las nuevas propiedades (valores etiquetados)

Figura 2.11 Nuevas propiedades para un elemento class


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.


52

Figura 2.13 Procedimiento principal de MER Validate

Figura 2.14 Procedimiento principal de MER DDL Generate


52


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


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.


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


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.


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


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


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


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


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.


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


63


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


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


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


[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.


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.


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."

Anexos

70

Anexos

Anexo 1 Definición de los estereotipos de tipo class

Anexos

71

Anexo 2 Definición de los estereotipos de tipo attribute y association

Anexos

72

Anexo 3 Declaración de variables en el método principal de MER DDL Generate

Autora: Annalie Barreras González

Documents

Transcript of Autora: Annalie Barreras González