universidad de castilla-la mancha escuela superior de informática
TRANSCRIPT
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
GRADO EN INGENIERÍA EN INFORMÁTICA
TECNOLOGÍA ESPECÍFICA DE COMPUTACIÓN
TRABAJO FIN DE GRADO
SISTEMA DE AUTENTICACIÓN INTEGRAL
Ángel Durán Izquierdo
Septiembre, 2014
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
TECNOLOGÍAS Y SISTEMAS DE INFORMACIÓN
TECNOLOGÍA ESPECÍFICA DE COMPUTACIÓN
TRABAJO FIN DE GRADO
SISTEMA DE AUTENTICACIÓN INTEGRAL
Autor: Ángel Durán IzquierdoDirector: David García Rosado
Septiembre, 2014
TRIBUNAL:
Presidente:
Vocal:
Secretario:
FECHA DE DEFENSA:
CALIFICACIÓN:
PRESIDENTE VOCAL SECRETARIO
Fdo.: Fdo.: Fdo.:
I
II
RESUMEN
Las empresas, ya sean del ámbito tecnológico o no, manejan una cantidad importante de
servicios, cada uno de estos servicios tiene asociado diferentes usuarios y sus correspon-
dientes contraseñas por lo tanto surge la necesidad de herramientas que faciliten, tanto a los
administradores de los sistemas como a los usuarios de los mismos, la tarea de mantenimien-
to de dichas autenticaciones.
Un usuario debe recordar o en su defecto almacenar por medio de algún sistema una gran
cantidad de usuarios y password asociados a herramientas web, accesos a dominios, etc. por
lo que al final se termina utilizando un mismo nombre de usuario y una misma clave para
todos ellos, el problema surge cuando, por políticas de empresa o por políticas de las dife-
rentes herramientas, la contraseña debe ser cambiada.
En este proyecto se realiza un estudio de los diferentes métodos utilizados por las empresas
para controlar el acceso de sus usuarios y de los sistemas más comunes de autenticación con
el fin de ofrecer una herramienta centralizada donde se pueda gestionar de manera eficiente
la autenticación de los usuarios ofreciendo un único sistema para la gestión de accesos. Este
sistema debe ser lo suficientemente flexible y debe abarcar un amplio espectro de subsiste-
mas para dar soporte a cualquier tipo de empresa.
III
IV
ABSTRACT
Companies, in information technology area or any other field, handled a large number
of services, each of these services has associated different users and their corresponding
passwords therefore there is a need for tools that facilitate both the system administrators
and users thereof, the task of maintaining such authentications.
User must remember or store, using some system, a large number of logins and associated
password to web platform, access domains, etc. so they end up using the same username and
the same key for all of them, the problem arises when, for company policies or policies of
the different tools, the password must be changed.
The aim of this project is to study the different methods used by companies to control
access by users and the most common authentication systems in order to provide a centralized
tool where you can efficiently manage the user authentication is performed providing a single
system for access management. This system should be flexible enough and should cover a
wide range of subsystems to support any type of company.
V
VI
Agradezco y dedico este proyecto a mis padres, por la comprensión, motivación y apoyo
que me han brindado para lograr llegar hasta aquí y ser la persona que soy.
A mis compañeros de trabajo por su ayuda e ideas.
A Miriam por su paciencia y apoyo.
VII
VIII
ÍNDICE
1. INTRODUCCIÓN 1
1.1. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. OBJETIVOS DEL TFG 7
3. ANTECEDENTES, ESTADO DE LA CUESTIÓN 9
3.1. Sistema experto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Evolución histórica . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2. Características y arquitectura de los Sistemas Expertos . . . . . . . 13
3.1.3. Tipos de sistemas Basados en el Conocimiento . . . . . . . . . . . 15
3.1.4. Campos de Aplicación . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.5. Ventajas y desventajas de los Sistemas Expertos . . . . . . . . . . . 24
3.1.6. Motor de Inferencia . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2. Herramienta Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1. Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.2. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.3. Tecnologías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4. MÉTODO DE TRABAJO 43
4.1. Sistema experto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.1. Características del sistema experto . . . . . . . . . . . . . . . . . . 44
4.1.2. Estudio de viabilidad . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.3. Adquisición del conocimiento . . . . . . . . . . . . . . . . . . . . 45
4.1.4. Implantación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.5. Evaluación y pruebas . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.6. Motor de inferencia . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2. Herramienta Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1. Metodología SCRUM . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.2. Ciclo de vida SCRUM . . . . . . . . . . . . . . . . . . . . . . . . 52
IX
4.2.3. Validación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.4. Fases dentro del desarrollo . . . . . . . . . . . . . . . . . . . . . . 55
5. RESULTADOS 57
5.1. Sistema experto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1.1. Características del sistema experto . . . . . . . . . . . . . . . . . . 57
5.1.2. Estudio de viabilidad . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.1.3. Adquisición del conocimiento . . . . . . . . . . . . . . . . . . . . 65
5.1.4. Implantación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.1.4.1. Hechos posibles . . . . . . . . . . . . . . . . . . . . . . 67
5.1.4.2. Reglas . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.1.5. Evaluación y pruebas . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.1.5.1. Verificación . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.5.2. Validación . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2. Herramienta Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2.1. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.1.1. Autenticación . . . . . . . . . . . . . . . . . . . . . . . 81
5.2.1.2. Elegir Empresa . . . . . . . . . . . . . . . . . . . . . . 86
5.2.1.3. Mi perfil (modificar perfil) . . . . . . . . . . . . . . . . . 88
5.2.1.4. Definir Roles . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2.1.5. Creación de Usuarios . . . . . . . . . . . . . . . . . . . 92
5.2.1.6. Importar Usuarios . . . . . . . . . . . . . . . . . . . . . 96
5.2.1.7. Configurar LDAP . . . . . . . . . . . . . . . . . . . . . 100
5.2.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.2.2.1. Autenticación . . . . . . . . . . . . . . . . . . . . . . . 105
5.2.2.2. Autenticación con DNIe . . . . . . . . . . . . . . . . . . 105
5.2.2.3. Elegir empresa . . . . . . . . . . . . . . . . . . . . . . . 105
5.2.2.4. Modificar conexión . . . . . . . . . . . . . . . . . . . . 106
5.2.2.5. Comprobar conexión . . . . . . . . . . . . . . . . . . . 106
5.2.2.6. Añadir política . . . . . . . . . . . . . . . . . . . . . . . 107
5.2.2.7. Modificar política . . . . . . . . . . . . . . . . . . . . . 107
X
5.2.2.8. Clases de dominio . . . . . . . . . . . . . . . . . . . . . 108
5.2.2.9. Estructura de Base de Datos . . . . . . . . . . . . . . . . 109
6. CONCLUSIONES Y PROPUESTAS 111
6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.2. Líneas de futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Referencias 115
Anexos 118
I. Método para el estudio de la viabilidad 118
II. Tablas de correspondencia Variable/Nivel de seguridad 121
III. Documentos adquisición de conocimiento 123
IV. Reglas del sistema experto 130
V. Acrónimos 144
VI. Manual de usuario 147
XI
ÍNDICE DE FIGURAS
1. Ciencias que intervienen en la inteligencia artificial . . . . . . . . . . . . . 10
2. Arquitectura de un sistema experto . . . . . . . . . . . . . . . . . . . . . . 14
3. Encadenamiento hacia delante. . . . . . . . . . . . . . . . . . . . . . . . . 26
4. Ciclo base del motor de inferencia . . . . . . . . . . . . . . . . . . . . . . 27
5. Clasificación Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . 30
6. Conocimiento y adopción del SaaS . . . . . . . . . . . . . . . . . . . . . . 32
7. Beneficios del SaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8. Secuencia PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9. Tecnologías que conformas AJAX . . . . . . . . . . . . . . . . . . . . . . 38
10. Modelo clásico frente a Ajax . . . . . . . . . . . . . . . . . . . . . . . . . 39
11. Flujo de creación y mantenimiento de un sistema experto . . . . . . . . . . 43
12. Etapas del proceso de adquisición del Conocimiento . . . . . . . . . . . . . 46
13. Cliclo SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
14. Diagrama de casos de uso genérico . . . . . . . . . . . . . . . . . . . . . . 56
15. Diagrama de secuencia genérico . . . . . . . . . . . . . . . . . . . . . . . 56
16. Diagrama de casos de uso general . . . . . . . . . . . . . . . . . . . . . . 76
17. Diagrama de casos de uso de Autenticación . . . . . . . . . . . . . . . . . 77
18. Diagrama de casos de uso del módulo de inicio . . . . . . . . . . . . . . . 77
19. Diagrama de casos de uso del módulo de administración . . . . . . . . . . 78
20. Diagrama de casos de uso de gestión de usuarios . . . . . . . . . . . . . . 79
21. Diagrama de casos de uso de conexiones . . . . . . . . . . . . . . . . . . . 80
22. Diagrama de casos de uso de seguridad . . . . . . . . . . . . . . . . . . . 80
23. Clases de análisis en el caso de uso de Autenticación contra BBDD . . . . . 83
24. Clases de análisis en el caso de uso de Autenticación con DNIe . . . . . . . 86
25. Clases de análisis en el caso de uso elegir empresa . . . . . . . . . . . . . . 87
26. Clases de análisis en el caso de uso Mi perfil (modificar perfil) . . . . . . . 89
27. Clases de análisis en el caso de uso insertar rol . . . . . . . . . . . . . . . . 90
28. Clases de análisis en el caso de uso eliminar rol . . . . . . . . . . . . . . . 91
XII
29. Clases de análisis en el caso de uso insertar usuario . . . . . . . . . . . . . 93
30. Clases de análisis en el caso de uso eliminar usuario . . . . . . . . . . . . . 94
31. Clases de análisis en el caso de uso modificar usuario . . . . . . . . . . . . 96
32. Clases de análisis en el caso de uso importar usuario desde CSV . . . . . . 98
33. Clases de análisis en el caso de uso importar usuario desde LDAP/AD . . . 100
34. Clases de análisis en el caso de uso modificar conexión LDAP . . . . . . . 101
35. Clases de análisis en el caso de uso comprobar conexión LDAP . . . . . . . 102
36. Clases de análisis en el caso de uso insertar configuración LDAP avanzada . 104
37. Diagrama de secuencia para el caso de uso de autenticación . . . . . . . . . 105
38. Diagrama de secuencia para el caso de uso de autenticación con DNIe . . . 105
39. Diagrama de secuencia para el caso de uso de elegir empresa . . . . . . . . 106
40. Diagrama de secuencia para el caso de uso de modificar conexión LDAP/AD 106
41. Diagrama de secuencia para el caso de uso de comporbar conexión LDAP/AD 107
42. Diagrama de secuencia para el caso de uso de añadir política de seguridad . 107
43. Diagrama de secuencia para el caso de uso de modificar política de seguridad 108
44. Diagrama de clases de dominio . . . . . . . . . . . . . . . . . . . . . . . . 108
45. Estructura de las clases control y broker . . . . . . . . . . . . . . . . . . . 109
46. Estructura de Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . 110
ÍNDICE DE TABLAS
1. Características de posibilidad . . . . . . . . . . . . . . . . . . . . . . . . . 59
2. Características de Justificación . . . . . . . . . . . . . . . . . . . . . . . . 60
3. Características de Adecuación . . . . . . . . . . . . . . . . . . . . . . . . 62
4. Características de Éxito . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5. Resultados del estudio de viabilidad . . . . . . . . . . . . . . . . . . . . . 65
6. Planificación SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7. Descripción textual del caso de uso de Autenticación contra BBDD . . . . 83
8. Descripción textual del caso de uso de Autenticación con DNIe . . . . . . . 85
9. Descripción textual del caso de uso elegir empresa . . . . . . . . . . . . . 87
10. Descripción textual del caso de uso mi perfil (modificar perfil) . . . . . . . 88
XIII
11. Descripción textual del caso de uso insertar rol . . . . . . . . . . . . . . . 90
12. Descripción textual del caso de uso eliminar rol . . . . . . . . . . . . . . . 91
13. Descripción textual del caso de uso insertar usuario . . . . . . . . . . . . . 92
14. Descripción textual del caso de uso eliminar usuario . . . . . . . . . . . . . 94
15. Descripción textual del caso de uso modificar usuario . . . . . . . . . . . . 95
16. Descripción textual del caso de uso importar usuario desde CSV . . . . . . 97
17. Descripción textual del caso de uso importar usuario desde LDAP/AD . . . 99
18. Descripción textual del caso de uso modificar conexión LDAP . . . . . . . 101
19. Descripción textual del caso de uso comprobar conexión LDAP . . . . . . . 102
20. Descripción textual del caso de uso insertar configuración LDAP avanzada . 103
21. Nivel de seguridad/Características . . . . . . . . . . . . . . . . . . . . . . 122
22. Nivel seguridad/Medidas . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
XIV
1 INTRODUCCIÓN
En la actualidad las empresas utilizan múltiples aplicaciones y sistemas para gestionar sus
procesos de negocio, en la mayoría de los casos cada uno de estos sistemas lleva asociado
una autenticación, además también existen herramientas externas, es decir, que no están den-
tro de la infraestructura de la propia empresa. De todo esto surge la necesidad de gestionar o
proveer un sistema que permita a un mismo empleado/usuario utilizar sus credenciales para
acceder a cada una de las plataformas. Las empresas suelen tener un sistema de gestión de
usuarios donde mantienen de forma centralizada la información de los empleados junto con
los credenciales, de esta forma tienen control sobre los tipos de contraseñas o políticas que
se deben aplicar a cada uno de los usuarios. Los sistemas que se utilizan para este fin son los
sistemas basados en directorios, por ejemplo LDAP. El Protocolo ligero de acceso a directo-
rios (en inglés, Lightweight Directory Access Protocol, LDAP) es un conjunto de protocolos
abiertos usados para acceder a información guardada de forma centralizada a través de la
red. Está basado en el estándar X.500 para compartir directorios. El estándar X.500 es un
directorio que contiene información de forma jerárquica y categorizada, que puede incluir
nombres, directorios y otros datos. LDAP o cualquier otro sistema de directorios, organiza la
información en un modo jerárquico usando directorios. Estos directorios pueden almacenar
una gran variedad de información y se pueden incluso usar de forma similar al Servicio de
información de red, permitiendo que cualquiera pueda acceder a su cuenta desde cualquier
máquina en la red acreditada con LDAP. La mayor ventaja de LDAP es que se puede conso-
lidar información para toda una organización dentro de un repositorio central. Por ejemplo,
en vez de administrar listas de usuarios para cada grupo dentro de una organización, puede
usar LDAP como directorio central, accesible desde cualquier parte de la red. Puesto que
LDAP soporta la Capa de conexión segura (SSL) y la Seguridad de la capa de transporte, los
datos confidenciales se pueden proteger de los curiosos. LDAP también soporta un número
de bases de datos back-end en las que se guardan directorios. Esto permite que los adminis-
tradores tengan la flexibilidad para desplegar la base de datos más indicada para el tipo de
información que el servidor tiene que diseminar. También, ya que LDAP tiene una interfaz
de programación de aplicaciones bien definida, el número de aplicaciones acreditadas para
1
LDAP son numerosas y están aumentando en cantidad y calidad.
El proyecto está motivado por la necesidad de conectar desarrollos software a los siste-
mas utilizados por las empresas, una buena forma de incentivar a un usuario a utilizar una
herramienta es permitir que acceda a la misma con los mismos credenciales que utiliza en
su empresa. Por otro lado añade valor al producto de cara a la empresa ya que pueden se-
guir gestionando a sus usuarios de forma centralizada, simplemente creando un usuario en la
nueva herramienta e indicando que dicho usuario se autenticará contra un Active Directory,
LDAP o cualquier otro sistema de estas características implementado en la empresa.
Además de la conexión a través de un servicio de directorios muchas empresas utilizan
otros tipos de autenticación, uno de los más extendidos, sobre todo en servicios públicos o
banca, es la autenticación utilizando DNI electrónico.
El Documento Nacional de Identidad electrónico (DNI electrónico) emitido por la Direc-
ción General de la Policía (Ministerio del Interior), es el documento que además de acreditar
físicamente la identidad personal de su titular permite:
Acreditar electrónicamente y de forma inequívoca la identidad de la persona.
Firmar digitalmente documentos electrónicos, otorgándoles una validez jurídica equi-
valente a la que les proporciona la firma manuscrita.
La principal novedad del documento es que incorpora un pequeño circuito integrado
(chip), que contiene los mismos datos que aparecen impresos en la tarjeta (datos persona-
les, fotografía, firma digitalizada, huella dactilar digitalizada) junto con los Certificados de
Autenticación y de Firma Electrónica.
De esta forma, cualquier persona podrá realizar múltiples gestiones online de forma se-
gura con las Administraciones Públicas, con las empresas públicas y privadas y con otros
ciudadanos, a cualquier hora y sin tener que desplazarse ni hacer colas.
Con el DNI electrónico se obtienen dos certificados:
Certificado de Autenticación: Garantiza electrónicamente la identidad del ciudadano al
realizar una transacción telemática. Este Certificado asegura que la comunicación electrónica
se realiza con la persona que dice que es, con el certificado de identidad y la clave privada
asociada al mismo.
2
Certificado de Firma: Permite la firma de trámites o documentos, sustituyendo a la firma
manuscrita. Por tanto, garantiza la identidad del suscriptor y del poseedor de la clave privada
de identificación y firma.
Se utilizará el certificado de autenticación para permitir a la empresa que sus usuarios ac-
cedan a una herramienta con sus DNIe, el resultado de este proyecto comprobará la identidad
del empleado y que el usuario asociado a dicho empleado tiene acceso a la herramienta.
Existen otro tipo de empresas, que por desconocimiento o por falta de medios no usan
ningún sistema centralizado, para este tipo de empresas este proyecto ofrece por una parte un
sistema para la creación, modificación y eliminación de usuarios y lo que es más importante
la gestión de políticas de seguridad que pueden asociarse a estos usuarios, de esta forma se
crea un sistema sustituto al LDAP en lo que a autenticación se refiere.
Del punto anterior se desprende un posible problema, si una empresa no dispone de los
conocimientos técnicos para montar un LDAP puede que no disponga tampoco del conoci-
miento necesario para configurar una política de seguridad acorde con las características de
su sistema. Para este caso se desarrolla e integra en el producto final un sistema experto.
Los Sistemas Expertos, rama de la Inteligencia Artificial, son sistemas informáticos que
simulan el proceso de aprendizaje, de memorización, de razonamiento, de comunicación y
de acción en consecuencia de un experto humano en cualquier rama de la ciencia. Estas ca-
racterísticas le permiten almacenar datos y conocimiento, sacar conclusiones lógicas, tomar
decisiones, aprender de la experiencia y los datos existentes, comunicarse con expertos hu-
manos, explicar el por qué de las decisiones tomadas y realizar acciones como consecuencia
de todo lo anterior. Técnicamente un sistema experto, contiene una base de conocimientos
que incluye la experiencia acumulada de expertos humanos y un conjunto de reglas para
aplicar ésta base de conocimientos en una situación particular que se le indica al programa.
Cada vez el sistema se mejora con adiciones a la base de conocimientos o al conjunto de
reglas.
Se ha decidido implementar un sistema experto ya que con su ayuda, personas con poca
experiencia pueden resolver problemas que requieren un “conocimiento formal especiali-
zado”. Los Sistemas Expertos pueden obtener conclusiones y resolver problemas de forma
más rápida que los expertos humanos. Se ha comprobado que los Sistemas Expertos tienen
3
al menos, la misma competencia que un especialista humano.
El sistema experto a desarrollar permitirá al administrador del sistema crear políticas
adecuadas e incluso evaluar si la política aplicada actualmente es correcta para su sistema.
Todo lo anteriormente descrito se enmarca dentro de una aplicación web, haciendo uso
del cloud computing, más concretamente el modelo de distribución de software utilizado se
denomina Saas (Software as a Service), donde el soporte lógico y los datos que maneja se
alojan en servidores de una compañía de tecnologías de información y comunicación (TIC),
a los que se accede con un navegador web desde un cliente, a través de Internet.
1.1 Estructura del documento
Este documento se ha estructurado en capítulos y anexos. El contenido de los mismos es
el siguiente:
Capitulo 1. Introducción. Este capítulo contiene una introducción al tema tratado expo-
niendo la problemática actual como justificación de la realización del TFG.
Capítulo 2. Objetivos del TFG. Se concretan y exponen los objetivos del proyecto y los
recursos que se han utilizado para el desarrollo del proyecto.
Capítulo 3. Antecedentes, Estado de la Cuestión. Se realiza una revisión del estado del
arte. Se presentan los principales conceptos teóricos sobre los que se asienta el proyecto
y se muestran y explican trabajos similares.
Capítulo 4. Método de trabajo. Se explica cómo se ha solucionado el problema, mostran-
do el plan de trabajo y describiendo los métodos y técnicas de la Ingeniería del Software
utilizados.
Capítulo 5. Resultados. Se describe la aplicación de trabajo a partir del plan de trabajo del
capítulo 4 junto con los resultados obtenidos de esa aplicación de trabajo.
Capítulo 6. Conclusiones y propuestas. En este capítulo se exponen las conclusiones que
se extraen del trabajo desarrollado y se muestran las limitaciones que presenta la herra-
mienta. Se indican a su vez, las principales líneas de trabajo futuro.
4
Los anexos complementan los contenidos presentados en los capítulos de esta memoria
con la siguiente información:
Anexo I. Método de estudio de la viabilidad de un sistemas experto.
Anexo II. Análisis de la correspondencia entre las variables de un sistema y sus requisitos
de seguridad.
Anexo III. Documento base para la realización de entrevistas.
Anexo IV. Reglas que definen el sistema experto.
Anexo V. Glosario de términos.
Anexo VI. Manual de usuario.
5
2 OBJETIVOS DEL TFG
El objetivo general de este proyecto fin de carrera es el desarrollo de una herramienta
totalmente funcional que permita la integración de varios sistemas de autenticación para una
misma aplicación, se pretende estudiar los sistemas actuales de seguridad y autenticación
para que el producto final sea lo más flexible y útil posible, permitiendo la integración en
varios sistemas. Uno de los aspectos mas importantes de este proyecto es la integración de
un sistema experto que permita la configuración y evaluación de las medidas de seguridad
aplicadas, este sistema experto pretende trasladar el conocimiento sobre seguridad que pueda
tener un experto en sistemas e integrarlo en la herramienta para facilitar la implementación
de las políticas de seguridad adecuadas para una aplicación o sistema concreto, todo esto sin
la necesidad de tener conocimientos avanzados por parte de los usuarios.
El objetivo general de este proyecto de fin de grado puede dividirse en varios objetivos
específicos:
Estudio de la usabilidad frente a la seguridad en relación a los diferentes sistemas de
autenticación. En los sistemas actuales es muy importante la optimización de recursos
a la vez que se desea ofrecer al usuario una experiencia de uso satisfactoria. Si se lleva
esto al ámbito de la seguridad lo que se necesita es que un sistema sea seguro y ade-
cuado para la información que se desea proteger. Por ejemplo no tiene sentido obligar
a un usuario a utilizar una clave de 25 caracteres para acceder a un sistema que ofrece
información de carácter público. En este sentido se pretende estudiar la variables que
afectarían al nivel de seguridad exigible.
Estudio de las diferentes políticas de seguridad usadas por parte de las empresas. Rela-
cionado con el punto anterior, se desea estudiar las diferentes configuraciones posibles
para las políticas de seguridad y ver como estas configuraciones se correspondes a di-
ferentes niveles de securización.
Estudio de los sistemas de autenticación que usan como principal herramienta el DNIe.
En la actualidad existen herramientas o aplicaciones cuyo sistema de login es el propio
DNI electrónico, se pretende estudiar la implementación de dichos sistemas.
7
Estudio de los diferentes sistema existentes para el almacenamiento de usuarios y con-
traseñas y principalmente los sistemas que son usados en las empresas.
Uso de un sistema experto para la evaluación de las políticas de seguridad.
Creación de un motor de inferencia para un entorno de desarrollo web. Se necesita
implementar un motor de inferencia compatible con la tecnología que se utiliza en este
proyecto, este motor tiene como entrada una serie de parámetros (hechos) y a través de
la aplicación de reglas infiere nuevos hechos, el resultado final es una lista de hechos que
aportan la misma información que un experto humano. Este motor de inferencia estará
basado en el motor que utiliza CLIPS pero simplificado, para adaptarlo a la finalidad
del proyecto.
Desarrollo de un software que facilitará la gestión de usuarios y contraseñas entre una
suit de aplicaciones y la empresa que ha contratado los servicios de esta herramienta
web (suit). Los objetivos relacionados con la herramienta pueden verse a continuación:
• Las políticas de contraseñas que se fijen en la empresa serán las mismas para utili-
zar la suit de herramientas web.
• Sistema propio de almacenamiento de usuario y contraseñas como alternativa para
las empresas que no disponen de sistema propio.
• Posibilidad de elección de diferentes políticas de seguridad para el sistema propio.
• Uso de DNIe electrónico tanto para la autenticación con la empresa como la auten-
ticación en el caso del sistema propio.
8
3 ANTECEDENTES, ESTADO DE LA CUESTIÓN
El proyecto, aunque presenta una herramienta final única, está formado por dos partes
bien diferenciadas. La primera parte consta de un sistema experto que se debe integrar en el
resultado final, este sistema experto da soporte a la configuración y evaluación de las políticas
de seguridad, además aporta al proyecto el desarrollo de un motor de inferencia simplificado
que permite el funcionamiento de este sistema experto sobre una tecnología web. La otra
parte del proyecto es el desarrollo de una herramienta web, donde esta integrado el sistema
experto, que permite centralizar la configuración de políticas de seguridad y el acceso a través
de diferentes sistemas de autenticación.
Debido a la naturaleza del proyecto, descrito anteriormente, este capítulo está dividido en
dos partes, en la primera de ella se hablará sobre los antecedentes relacionados con el sistema
experto. La segunda parte trata el estado de la cuestión de la parte de seguridad (herramienta
web).
3.1 Sistema experto
Como puede verse en la figura 1, la inteligencia artificial se compone de la unión de va-
rias ciencias que van desde las ciencias más puras como pueden ser las matemáticas hasta
ciencias del ámbito del conocimiento humano como puede ser la filosofía o la psicología.
Al estar compuesta por tantas fuentes de conocimiento sus campos de aplicación y sus di-
ferentes ramas de investigación son muy variadas, en concreto existe un campo dentro de la
inteligencia artificial al que se le atribuye la facultad de reproducir el razonamiento de un
experto humano en un ámbito concreto: el de los sistemas expertos. Los Sistemas Expertos
pueden mejorar la productividad, ahorrar tiempo, hacer permanentes los conocimientos y
difundirlos más fácilmente.
Estos sistemas permiten la creación de máquinas que reproducen un proceso intelectual
como el hombre, limitándose a un espacio de conocimientos concreto, esta afirmación es muy
importante ya que un sistema experto debe estar muy centrado en un área de aplicación, de
lo contrario al intentar abarcar tanto espacio de conocimiento suele conducir al fracaso de la
implementación de este tipo de sistemas. En teoría son capaces de realizar un razonamiento
siguiendo los pasos que seguiría un experto humano (médico, analista, empresario, etc.)
para la resolución de un problema concreto. Estos modelos de conocimiento por computador
ofrecen un amplio campo de posibilidades en aprendizaje y resolución de problemas.
Inteligencia artificial
Matemáticas
DemostraciónAutomática
Deteoremas
ProgramaciónHeurística
ProgramaciónInformática
Otra
sC
ienc
ias
Inge
nier
íaD
elC
onoc
imie
nto
Rob
ótic
a
Psicología
Ciencia
cognoscitiva
Figura 1: Ciencias que intervienen en la inteligencia artificial
3.1.1 Evolución histórica
Warren McCulloch y Walter Pitts (1943) han sido reconocidos como los primeros autores
de un trabajo de Inteligencia artificial. Usando como puntos de partida los conocimientos
sobre la filosofía básica, el funcionamiento neuronal, el análisis formal de la lógica proposi-
cional de Russell - Whitehead y la teoría de computación de Turing propusieron un modelo
formado con neuronas artificiales donde cada una de ellas se caracterizaba por estar activada
o desactivada. Una neurona se activaba si un gran número de las neuronas vecinas estaban
activas. Mostraron que cualquier función de computo podría calcularse mediante un red de
neuronas interconectadas. Estos dos autores también sugirieron que redes adecuadamente
definidas podrían llegar a adquirir conocimiento o lo que es lo mismo, aprender.
10
Es a partir de los años 50 cuando la inteligencia artificial [8] experimenta un notable
avance (Rama de computación).
A continuación se muestran lo hitos más importantes en la evolución de los Sistemas
Expertos.
1950: Weiner introduce la idea de circularidad a través del concepto de retroalimentación o
feedback. El feedback se define como la capacidad de respuesta para poder mantener un
estado de equilibrio. El feedback es entonces un mecanismo que persigue la regulación
de un sistema, esta regulación se produce siempre tras perder el estado de equilibrio. Es
decir, cuando el estado ideal no coincide con el estado actual. En este caso, el sistema
actúa para poder alcanzar de nuevo un estado de equilibrio, de esta forma se sientan las
bases para los sistemas de control.
1955: Los informáticos Allen Newell y Herbert Simon presentan la “Máquina de la Teoría
Lógica”,que era un avance de lo que pronto se configuraría como inteligencia artificial.
1956: En una conferencia en Vermont(USA) John McCarthy utiliza el término de “Inteli-
gencia artificial”.
1957: Newell y Simon continúan su trabajo con el desarrollo del General Problem Solver
(GPS). GPS era un sistema orientado a la resolución de problemas.
1958: John McCarthy desarrolla en el Instituto de Tecnología de Massachusetts (MIT), el
LISP. Su nombre se deriva de LISt Processor. LISP fue el primer lenguaje para proce-
samiento simbólico.
1963: El Instituto de Tecnología de Massachusetts recibe una subvención importante para la
investigación en el área de la inteligencia artificial.
1965-1975: Se desarrolla DENDRAL, iniciado por Buchanan, Feigenbaum y Lederberg, es
el primer Sistema Experto, que asiste a químicos en estructuras químicas complejas
euclidianas.
1972: Edgar ShortLiffe desarrolla el sistema MYCIN, en la Universidad de Stanford. Es-
taba escrito en Lisp. Su principal función consistía en el diagnóstico de enfermedades
11
infecciosas de la sangre; posteriormente, también era capaz de recetar medicaciones
personalizadas a cada paciente (según su estatura, peso, etc.).
1973: Alain Colmenauer y su equipo de investigación en la Universidad de Aix-Marseille
desarrollan PROLOG (PROgrammation en LOGique) un lenguaje de programación
ampliamente utilizado en IA.
1973: Se desarrolla el sistema experto llamado TIERESIAS. El cometido de este sistema ex-
perto era el de servir de intérprete entre MYCIN y los especialistas que lo manejaban, a
la hora introducir nuevos conocimientos en su base de datos. El especialista debía utili-
zar MYCIN de una forma normal, y cuando este cometiera un error en un diagnóstico
(hecho producido por la falta o fallo de información en el árbol de desarrollo de teorías)
TEIRESIAS corregiría dicho fallo destruyendo la regla si es falsa o ampliándola si es
eso lo que se necesita.
Finales de los 70, principio de los 80 Creció el uso de sistemas expertos, como MYCIN:
R1/XCON, ABRL, PIP, PUFF, CASNET, INTERNIST/CADUCEUS, etc. Algunos per-
manecen hasta hoy (Shells) como EMYCIN, EXPERT, OPSS.
1981: Kazuhiro Fuchi anuncia el proyecto japonés de la quinta generación de computado-
ras, su objetivo era el desarrollo de una clase de computadoras que utilizarían técnicas
de inteligencia artificial al nivel del lenguaje de máquina y serían capaces de resolver
problemas complejos, como la traducción automática de una lengua natural a otra.
1986: McClelland y Rumelhart publican Parallel Distributed Processing, lo que representa
el principio de las Redes Neuronales.
1988: Se establecen los lenguajes Orientados a Objetos, este principo es muy importante a
la hora de implementar programas.
1997: Garry Kasparov, campeón mundial de ajedrez pierde ante la computadora autónoma
Deep Blue.
2009: Hay en desarrollo sistemas inteligentes terapéuticos que permiten detectar emociones
para poder interactuar con niños autistas.
12
2011: IBM desarrolla una supercomputadora llamada Watson , la cual ganó una ronda de
tres juegos seguidos de Jeopardy, venciendo a sus dos máximos campeones, y ganando
un premio de 1 millón de dólares que IBM donó a obras de caridad.
3.1.2 Características y arquitectura de los Sistemas Expertos
Los Sistemas Expertos al ser programas que representan y debe actuar, o por lo menos
aproximarse lo mas posible, como un experto humano deben cumplir en la medida de lo
posible con las siguientes características:
Habilidad para adquirir conocimiento.
Fiabilidad.
Solidez en el dominio de conocimiento.
Capacidad para resolver problemas.
Al tener un alto grado de complejidad en los problemas puede darse cierta duda sobre la
validez de la respuesta dada por parte del sistema experto por lo tanto es indispensable que el
sistema sea capaz de explicar su proceso de razonamiento o dar la razón del por qué solicita
cierta información o dato.
La arquitectura de los Sistemas Expertos se organiza tradicionalmente alrededor de tres
elementos principales [7], ver figura 2, estos elementos se detallan a continuación.
Base de conocimiento
Es una estructura de datos que contiene una gran cantidad de información sobre un área
específica, generalmente introducida por un experto humano en dicho tema, sobre el
cual se desarrolla y orienta la aplicación. Este conocimiento generalmente esta formado
por:
Objetos a tener en cuenta y sus relaciones.
Casos particulares, excepciones y diferentes estrategias de resolución con sus con-
diciones de aplicación.
13
Base de hechos
Es una memoria auxiliar que contiene a la vez los datos sobre la situación actual en
la cual se va a realizar la aplicación y los resultados intermedios obtenidos a lo lar-
go del procedimiento de deducción. Esta base en principio no se conserva y depende
exclusivamente de la situación estudiada.
Motor de inferencia
Es el núcleo del SE, ya que ponen en acción los elementos de la base de conocimientos
para construir los razonamientos. Ejecuta las inferencias durante el proceso de resolu-
ción, ya sea por modificación o por adjunción de los elementos de la base de hechos.
Frente a una situación dada, detecta los conocimientos que interesan, los utiliza, los en-
cadena, y construye un plan de resolución independiente del dominio. Aunque el motor
de inferencia, sea un programa procedimental la forma en que utiliza el conocimiento
nunca está determinada por el programador.
Representación del conocimiento Razonamiento
Interfazde
Usuario
Motorde
Inferencias
Basede
Hechos
Basede
Conocimientos
Figura 2: Arquitectura de un sistema experto
Además de estos elementos existen otros sistemas o módulos que dan apoyo al sistema
experto y al usuario.
14
Interface de usuario También denominado Sistema de Consulta. Es el que controla el diá-
logo entre el usuario y el sistema. Su objetivo es el de permitir un diálogo en un lenguaje
natural o casi natural con la máquina. Esta comunica al motor de inferencia las consul-
tas del usuario y a este los resultados de la consulta y viceversa.
Sistema de control de coherencia: Este componente evita la entrada de información que
no sea coherente en la base de conocimiento. Es un componente muy necesario, a pesar
de ser un componente de implementación reciente.
Sistema de adquisición de conocimiento: Se encarga de controlar si las entradas de nuevo
conocimiento a la base de datos es redundante. Solamente almacena la información que
no se encuentra en la base de datos.
Sistema de demanda de información: Se encarga de completar el conocimiento necesario
y reanuda el proceso de inferencia hasta obtener alguna conclusión válida. El usuario
puede indicar la información necesaria en este proceso ayudado de una interfase de
usuario (la cual facilita la comunicación entre el Sistema Experto y el usuario).
Sistema de incertidumbre: Este componente se encarga de almacenar la información de
tipo difuso y propaga la incertidumbre asociada a esta información.
Sistema de ejecución de tareas: Permite realizar acciones al Sistema Experto basadas en el
motor de inferencia.
Sistema de explicación: Este componente entra en ejecución cuando el usuario solicita una
explicación de las conclusiones obtenidas por el SE. Esto se facilita mediante el uso de
una interface.
3.1.3 Tipos de sistemas Basados en el Conocimiento
Existen diferentes formas de clasificar los Sistemas Expertos a continuación se expondrán
algunos de ellos.
Almacenamiento del conocimiento
Se pueden distinguir sistemas basados en probabilidad y sistemas basados en reglas. En
el primer caso se opera mediante la evaluación de probabilidades condicionales, en el
15
segundo caso, el conocimiento se almacena en forma de hechos y reglas, el motor de
inferencia opera mediante encadenamiento de reglas hacia atrás y adelante. Finalmente
también hay diferencias a la hora de realizar la adquisición del conocimiento y en el
método de llevar a cabo la explicación.
Modelo probabilístico: en este modelo la base de conocimiento puede estar forma-
da por hechos o de forma mas abstracta puede estar representada por una estructura
probabilística, el motor de inferencia lo que hace es realizar una evaluación de pro-
babilidades condicionales basándose en el teorema de Bayes. Por último indicar
que la adquisición del conocimiento se realiza a través de un espacio probabilístico
introduciendo parámetros.
Modelo basado en reglas: en este modelo la base de conocimiento almacena re-
glas y el motor de inferencia realiza encadenamiento de reglas hacia atrás y hacia
delante infiriendo nuevos hechos de esta manera este modelo obtiene nuevo cono-
cimiento.
Naturaleza del problema
Teniendo en el punto de mira la naturaleza de la tarea a realizar o el problema a solu-
cionar se puede tener el siguiente esquema de clasificación.
Clasificación o Diagnostico: se dispone de un repositorio de soluciones y se tratan
de clasificarlas o diagnosticarlas en función de una serie de datos. Por ejemplo:
sistema de diagnóstico médico.
Monitorización: se basa en analizar el comportamiento de un sistema buscando
posibles errores, en este caso es importante contemplar la evolución del sistema
pues no siempre los mismos datos dan lugar a idénticas soluciones.
Diseño: Se busca la construcción de la solución a un problema, que en principio es
desconocida, a partir de datos y restricciones que se tienen que satisfacer.
Predicción: se estudia el comportamiento de un sistema y se intenta saber como
va a reaccionar a ciertas entradas, lo que se pretende conseguir es adelantarse o
predecir el comportamiento, es decir, saber lo que va a pasar antes de que ocurra.
16
Interacción con el usuario
En función de la interacción del sistema experto con el usuario se podrían clasificar
como sigue:
Apoyo: el sistema aconseja el usuario, aunque es el usuario el que tiene la capaci-
dad de realizar al última decisión.
Control: el sistema funciona sin intervención humana.
Crítica: su misión es analizar decisiones tomadas por el usuario.
Tiempo de respuesta
Dependiendo del tiempo en el cual la respuesta del sistema experto sea necesaria se
puede tener la siguiente clasificación.
Tiempo ilimitado: no disponen de tiempo fijado para realizar el trabajo, son aque-
llos que emplean conocimiento casual, que busca orígenes de un problema que ha
ocurrido y cuyo análisis no necesita ser inmediato.
Tiempo limitado o tiempo real: sistemas que controlan o monitorizan dispositivos
y que han de tomar decisiones inmediatas en caso de que ocurra algún problema.
Variación del conocimiento
Esta clasificación se basa en si la base de conocimiento evoluciona a lo largo del tiempo.
Estáticos: la base del conocimiento no se modifica durante el proceso de decisión.
Dinámicos: se realizan cambios en la base de conocimiento durante la toma de de-
cisiones. Estos cambios pueden ser predecibles o impredecibles y además pueden
añadir información o modificar la información almacenada.
Certeza de la información
Completa: se tienen conocimiento de todos los datos y reglas necesarias para la
decisión.
Incompleta: falta información para tomar decisiones, datos inciertos o no confir-
mados, conocimientos incierto (reglas no siempre validas), Terminología ambigua.
17
3.1.4 Campos de Aplicación
En los últimos años se han producido grandes cambios en el entorno de las empresas y las
organizaciones, como consecuencia de los avances producidos por las nuevas tecnologías en
el ámbito de la producción, la información y las comunicaciones. En este nuevo escenario,
tan complejo y cambiante, para poder tomar decisiones de una manera eficaz, es necesario
disponer, en todo momento y de una forma rápida de información suficiente, actualizada y
oportuna. Realizar esto solamente es viable usando las computadores y las herramientas que
proporcionan las tecnologías de la información. Debido a las investigaciones realizadas en el
ámbito de la inteligencia artificial, el desarrollo de los sistemas basados en el conocimiento
y los Sistemas Expertos, también se han conseguido grandes avances en el tratamiento del
conocimiento, hecho fundamental para la toma de decisiones.
A continuación se mostrará el papel que juegan los Sistemas Expertos en cada uno de los
campos más importantes donde se aplican [28] [29] [30].
Medicina
Los Sistemas Expertos realizan tareas tales como la resolución de problemas, razona-
miento automático y aprendizaje automático. Es normal el estudio de estos sistemas
inteligentes en dominios específicos del conocimiento, como puede ser la medicina.
Las aplicaciones en esta área se pueden clasificar en:
Métodos de respuesta prefijada, formados por algoritmos lógicos, en los cuales el
control y el conocimiento están unidos y están escritos en lenguajes procedimen-
tales.
Métodos estadísticos que se clasificaban en Bayesianos, de análisis discriminantes
y análisis secuencial.
Contabilidad
Las actividades administrativas, financieras y contables también son campos en los que
se pueden utilizar los Sistemas Expertos, ya que se realizan muchas de las tareas ante-
riormente descritas y, además, cumplen la mayoría de los requisitos que son necesarios
para poder desarrollar un sistema experto
Las tareas requieren conocimiento especializado.
18
Existen auténticos expertos en la materia.
Los expertos son escasos.
El conocimiento necesita ser localizado en distintos lugares.
La mayor parte de las tareas necesitan soluciones heurísticas.
Hay que tener en cuenta que no en todas las tareas que se realizan en el campo de la
contabilidad y las finanzas es necesario utilizar los Sistemas Expertos. Por ejemplo,
en las tareas de auditoría que están muy bien estructuradas, son mecánicas y pueden
expresarse en forma de algoritmo (balances, cálculo de ratios, muestreo) se puede, y
es conveniente, utilizar la informática convencional (programas informáticos normales,
procesador de textos, bases de datos); en las tareas que estén semiestructuradas se pue-
den utilizar los sistemas de ayuda a la decisión (hojas de cálculo, sistemas de consulta
de archivos, sistemas de representación y análisis de datos); reservándose los Sistemas
Expertos para las tareas que estén muy poco o nada estructuradas, pues en este tipo de
tareas se requiere mucho del conocimiento de un experto y se utilizan reglas heurísticas
para llegar a una solución, dado que el campo de soluciones puede ser muy amplio. En
principio, los Sistemas Expertos se pueden utilizar en todas las áreas de la contabilidad.
Como esta clasificación resultaría muy amplia y, además, es poco práctica, se va a cla-
sificar las aplicaciones potenciales de los Sistemas Expertos en contabilidad de acuerdo
con las siguientes áreas:
Auditoría: Análisis de la materialidad y del riesgo, evaluación del control interno,
planificación de la auditoría, evaluación de la evidencia, análisis de cuentas con-
cretas, formación de opinión, emisión del informe, auditoría interna, auditoría in-
formática, etc.
Contabilidad de costes y de gestión: Cálculo y asignación de costes, asignación
de recursos escasos, control y análisis de desviaciones, planificación y control de
gestión, diseño de sistemas de información de gestión, etc.
Contabilidad: normas y principios contables, regulación legal, recuperación y aná-
lisis de registros contables, diseñar sistemas contables, consolidar estados conta-
bles.
19
Análisis de estados financieros: Salud financiera de la empresa, análisis del patri-
monio, financiero y económico de los estados contables, cálculo e interpretación
de ratios.
Servicios financieros
Los SE enfocados a la planificación financiera tienen sus principales aplicaciones en:
Análisis de mercados.
Análisis en seguros.
Impuestos.
Asesoría jurídica y fiscal.
Créditos y préstamos.
Evaluación de riesgos en bolsa.
Inversiones.
Fondos de pensiones.
Previsión de los cambios en los tipos de interés.
Prevenir las fluctuaciones dentro del mercado de divisas.
Valorar la situación financiera de un cliente o empresa.
Verificar firmas.
Auditoría
Los grandes cambios producidos en las empresas por el avance en tecnología han dado
como consecuencia que el trabajo de auditoría se haya visto modificado considerable-
mente, los rasgos mas característicos de estos cambios son:
crecimiento de las normas y procedimientos de auditoría.
Aumento en la complejidad de los procedimientos y las normas de auditoría.
Exigencia de un mayor control y una mayor calidad a la hora de realizar los trabajos
de auditoría dando como resultado unas remuneraciones más bajas.
Oferta de nuevos servicios(asesoría fiscal, asesoramiento informático).
20
Nuevos tipos de auditoría(auditoría informática, medioambiental)
Estas circunstancias han derivado en que la profesión de la auditoría sea más competi-
tiva y por lo tanto se haya visto forzada a recurrir a las nuevas técnicas y herramientas
soportadas por la tecnología de la información y la inteligencia artificial, para de este
modo llegar a conseguir una información más relevante que facilite a los auditores la
toma de decisiones de una forma rápida pudiendo aumentar la eficacia y el nivel de
calidad de la auditoría. La auditoría externa es “la actividad, realizada por una persona
cualificada e independiente, consistente en analizar, mediante la utilización de las téc-
nicas de revisión y verificación idóneas, la información económico-financiera deducida
de los documentos contables examinados, y que tiene como objeto la emisión de un
informe dirigido a poner de manifiesto su opinión responsable sobre la fiabilidad de la
citada información, a fin de que se pueda conocer y valorar dicha información por terce-
ros”. Los campos potenciales de la auditoría en los que se pueden aplicar los Sistemas
Expertos son variados, extendiéndose prácticamente a todas las tareas de la auditoría
en las que se necesite del conocimiento y del juicio profesional del auditor. Partien-
do de esto, es apropiado establecer una clasificación. En principio las aplicaciones de
Sistemas Expertos en auditoría se podrían clasificar según estas categorías:
1. SE en auditoría interna.
2. SE en auditoría externa.
3. SE en auditoría informática.
Militar
Las aplicaciones de los Sistemas Expertos en el área militar se centran en:
Selección inteligente de contramedidas electrónicas para obtener la mayor efecti-
vidad con unos recursos limitados.
Guiado de proyectiles y vehículos.
Planificación militar estratégica.
Reconocimiento automático de objetivos.
Detección de planes del enemigo.
21
Interpretación de señales de sensores.
Optimización de la carga.
Industria
En la industria los Sistemas Expertos se aplican principalmente en:
Control de calidad.
Actuación en caso de alarmas y emergencias.
Configurar equipos y sistemas.
Controlar los procesos industriales.
Gestionar de forma óptima de los recursos.
Tecnología de información
En este área las aplicaciones principales de los Sistemas Expertos son:
Diseñar circuitos de alto grado de integración.
Sistemas inteligentes que permiten el autodiagnóstico.
Configuración de equipos y sistemas.
Controlar las redes de comunicación.
Automatización de la programación.
Configurar equipos y sistemas.
Optimización de aplicaciones software.
Robótica
Los robots son muy apreciados en ambientes peligrosos para el ser humano, como por
ejemplo en el manejo de bombas y explosivos, altas temperaturas, atmósfera no apta
para el ser humano y en general bajo cualquier situación donde una persona no pueda
trabajar sin poner en riesgo su vida. La gran parte de los robots tienen un brazo con
varias uniones móviles, donde todos sus elementos están controlados por un sistema de
control desarrollado para realizar varias tareas bajo una secuencia de pasos estableci-
dos. Los investigadores de Inteligencia Artificial pretenden añadir al robot métodos y
técnicas que le permitan moverse como si tuviera un pequeño grado de inteligencia, lo
cual se quiere lograr con la conjunción de todas las áreas de la IA.
22
Aeronáutica
En al ámbito de la aeronáutica es donde los Sistemas Expertos han aportado más avance,
los Sistemas Expertos apoyan a los pilotos a realizar prácticas de simulación, control,
diagnósticos, entrenamiento, etc.
Las prácticas de simulación en la Ingeniería aeronáutica son de gran importancia, en
este sentido los Sistemas Expertos apoyan de forma más precisa los procesos de si-
mulación que llevan a cabo los pilotos. Las practicas de simulación permiten evitar
graves accidentes, es decir, los practicantes durante su entrenamiento no usarán aero-
naves reales, sino sistemas que simulan estos aviones, es aquí precisamente donde los
Sistemas Expertos apoyan estas practicas, otorgando a los practicantes conocimiento
sobre mecanismos de vuelo, control, solución de problemas, etc. El diagnostico es una
de las tareas que desempeñan muy bien los sistemas expertos, ya que estos permiten te-
ner siempre un control, el Sistema en este caso juega un papel muy importante, ya que
será un asistente con una carga masiva de conocimiento que permitirá detectar, diag-
nosticar y solucionar los fallos del avión. El experto humano no siempre tiene de forma
clara el conocimiento, ya que bajo factores de miedo, presión o estrés el conocimiento
tiende a ausentarse de la mente.
Después de ver las áreas de aplicación de los Sistemas Expertos se mostrarán algunos de
los Sistemas Expertos que existen actualmente.
ADICORP: Diagnóstico de equipos industriales.
CASHVALUE: Permite evaluar proyectos de inversión.
COACH: Es un observador de las acciones del usuario que está aprendiendo a operar
un área y basándose en ellas implementa un modelo adaptado para él.
DELTA: Diagnóstico y reparación de locomotoras diésel y eléctricas.
GUIDON: GUIDON es una reorganización de MYCIN con intenciones educativas.
HERSAY: Diseñado para detectar e identificar las palabras a partir de la voz humana.
LABEIN: Sistema inteligente para el diseño de motores eléctricos.
23
MYCIN: Diseñado para ayudar a los médicos a diagnosticar y tratar infecciones de
meningitis y bacteriemia. Una serie de pruebas han demostrado que MYCIN es igual
de eficiente que un médico.
PROSPECTOR: Evaluación de emplazamientos geológicos.
PUFF: Construido utilizando MYCIN, fue diseñado para interpretar los resultados de
pruebas respiratorias en pacientes.
TROPICAID: Diseñado para obtener información adicional de los medicamentos mas
utilizados, seleccionar los posibles diagnósticos a partir de analizar el cuadro médico y
propone un tratamiento óptimo.
VATIA: Asesora acerca del I.V.A.
3.1.5 Ventajas y desventajas de los Sistemas Expertos
Las ventajas de los Sistema Expertos en general son:
El conocimiento adquirido por un sistema experto puede ser copiado y almacenado
fácilmente, siendo muy complicado la pérdida de éstos datos.
Los Sistemas Expertos siempre está a pleno rendimiento y disponibles mientras que los
expertos humanos no.
La experiencia humana es muy difícil de documentar mientras que la crear un sistema
experto se genera la documentación necesaria.
El comportamiento humano no es predecible, ante las mismas entradas puede que un
experto humano no produzca las mismas salidas mientras que el comportamiento de un
sistema experto es totalmente predecible, es siempre consistente.
Un experto humano es costoso mientras que un sistema experto es fácilmente replicable
y por lo tanto no requiere una inversión constante.
Un humano necesita mucho tiempo para convertirse en un especialista en ciertos cam-
pos, lo que hace difícil que puedan aparecer nuevos especialistas humanos. Sin embargo
24
un sistema experto puede copiarse de una maquina a otra disponiendo inmediatamente
de un experto nuevo.
Las desventajas de los Sistema Expertos son:
Los humanos pueden actuar creativamente a situaciones inusuales, los Sistemas Exper-
tos no son capaces.
Un experto humano es capaz de adaptarse a los cambios que se producen en un deter-
minado ambiente, un sistema experto no es capaz de reaccionar en situaciones que no
conoce.
Los Sistemas Expertos no son capaces de enfrentarse a problemas que están fuera de su
área.
En general las limitaciones de los Sistema Expertos son:
Son difíciles de implementar y precisan mantenimiento complejo.
En tiempo y dinero para extraer el conocimiento de los especialistas humanos pueden
ser altos.
Cuando se producen cambios en el ámbito de aplicación hay que reprogramar el siste-
ma.
Existe la dificultad de manipular información no estructurada, incompleta, inconsistente
o errónea.
3.1.6 Motor de Inferencia
En este apartado se detalla más en profundidad el funcionamiento y las características de
un motor de inferencia, es importante ya que un objetivo de este proyecto es la implementa-
ción de un motor de inferencia sobre el cual funcione el sistema experto a desarrollar.
La elección de implementar un motor de inferencia en lugar de utilizar el propio de CLIPS
viene por la imposibilidad de conectar una aplicación web desarrollada en PHP con CLIPS.
Buscando alternativas se ha encontrado PHLIPS, una librería para el servidor web Apa-
che, que implementa la conexión con CLIPS pero esta librería es del 2004 y actualmente
25
se encuentra obsoleta. Para utilizar la librería anteriormente mencionada se debería utilizar
versiones de PHP y apache antigüas y por lo tanto con algunos fallos de seguridad y sin
funcionalidades que se utilizan hoy en día.
Un motor de inferencia es un mecanismo automático que permite obtener hechos nuevos
a partir de una base de conocimiento basada en reglas. Existen dos posibles estrategias de
inferencia para las bases de conocimiento basadas en reglas.
Encadenamiento hacia delante.
Encadenamiento hacia atrás.
En este caso nos centraremos en el encadenamiento hacia delante, pues es el que se uti-
lizará en la implementación del motor de inferencia. El funcionamiento del encadenamiento
hacia delante se detalla a continuación.
A partir de la BH1 se intenta deducir una BHn en la que se cumple la consulta.
Ejecutando sucesivamente las reglas Ri de la Base de reglas.
Cada ejecución de una regla caracteriza un ciclo de razonamiento CCk.
R1
R2
...
Rm
BH1 BH2 BHn1 BHn
CC1
CCn1
CC2
Ri Rj Rk
Figura 3: Encadenamiento hacia delante.
Tal y como se muestra en la figura 4 un ciclo de razonamiento dentro de un motor de infe-
rencia se divide en 4 partes: Detección de reglas aplicables, Selección de una regla aplicable,
26
Ejecución de una regla y Actualización de la Base de Hechos. A continuación se describen
pormenorizadamente cada uno de los mismos.
Detección dereglas aplicables
Elección de reglas
Aplicación
Actualizarbase de hechos
Figura 4: Ciclo base del motor de inferencia
Detección de reglas aplicables. Se selecciona un conjunto de reglas candidatas para ser eje-
cutadas, estas reglas deben ser compatibles con la Base de Hechos actual. Este paso pro-
porciona un conjunto de reglas que pueden ser ejecutadas pero por cada iteración sólo
se aplicará una, en la etapa siguiente se proporcionan los mecanismos para seleccionar
una única regla del conjunto.
Seleccionar una regla aplicable. Partimos de un conjunto de reglas que son compatibles
con la Base de Hechos actual, es decir, que pueden ser ejecutadas, para la selección de
una única regla se debe seguir un criterio concreto. A continuación se muestran algunos
de estas estrategias de selección.
Prioridad explícita: asignar valores de prioridad a cada regla.
Prioridad implícita: orden de de las reglas en la propia Base de Reglas.
27
Refracción: historia de una regla (la más/menos ejecutada).
Especificidad: dar prioridad a las reglas con más/menos condiciones.
La más antigua en el conjunto conflicto (estrategia de amplitud).
La más nueva en el conjunto conflicto (estrategia de profundidad).
Selección de reglas que se aplican a los objetos más recientes.
Asignación de prioridades a las patrones más comunes de la Base de Hechos.
Aplicación o ejecución de una regla. Una vez se ha seleccionado una regla, basándose en
la estrategia de selección definida, se ejecutan todas las acciones del consecuente de la
regla.
Actualizar Base de Hechos. Se modifica la Base de Hechos actual dando lugar a una Base
de Hechos nueva al añadir y borrar elementos de la primera, la Base de Hechos nueva
se tomará como punto de partida en el siguiente ciclo de funcionamiento.
El motor de inferencia debe tener una condición de parada, en caso contrario la ejecución
sería un bucle infinito sin control. Se pueden tomar dos casos para determinar la parada de la
ejecución.
Cuando no hay más reglas aplicables en el conjunto conflicto.
Cuando el consecuente de una regla ejecuta un comando de parada (regla de termina-
ción, puede codificar la consulta) (halt en CLIPS).
El motor de inferencia a desarrollar estará basado en el motor de CLIPS, en el capitulo
siguiente se exponen las características del mismo.
28
3.2 Herramienta Web
3.2.1 Cloud Computing
Introducción
La computación en nube [24] o cloud computing es un modelo que proporciona servi-
cios de computación, software, acceso a datos y almacenamiento que no necesita que
el usuario final tenga conocimientos sobre la gestión de recursos que se usan.
Este modelo proporciona gran número de ventajas:
Prestación de servicios a nivel mundial. Permite al usuario acceder a los sistemas
mediante un navegador web, independientemente de su localización, así como del
dispositivo empleado.
Sin inversiones iniciales. Permite un ahorro en hardware y licencias. Habitualmente
el sistema de pago se realiza por alquiler del período de uso dado a la aplicación.
Esto permite repartir el gasto entre todos los usuarios.
Sin necesidad de mantenimiento. El usuario, una vez contratado el servicio, no
debe preocuparse de actualizaciones ni del mantenimiento de la aplicación. El pro-
veedor realiza las mejoras al servicio, además de responsabilizarse de la seguridad
y de las copias de respaldo de los datos.
Esfuerzos centrados en el negocio. La empresa no debe dedicar esfuerzos al man-
tenimiento de los sistemas, por lo que esto le permite optimizar sus procesos.
Sin embargo, la computación en nube aún dispone de varias desventajas frente a los
sistemas tradicionales que provocan cierta desconfianza entre los posibles usuarios. Al-
gunas de ellas son:
La centralización de las aplicaciones y el almacenamiento de los datos produce una
cierta dependencia de los proveedores de servicios.
La disponibilidad de los servicios depende de la disponibilidad del acceso a inter-
net.
Los datos críticos del negocio se almacenan fuera de las instalaciones de la empre-
sa, lo que provoca una alta vulnerabilidad a la sustracción de información.
29
Clasificación
Aunque el término cloud computing se aplica a multitud de servicios ofrecidos en in-
ternet, habitualmente estos se clasifican en tres tipos (ver figura 5):
SaaS
PaaS
IaaS
Cloud InfraestructureManagers
VIM
VMM
VMs MapReduce DFS
Web Services
Hardware Technologies
Enablin g Tech nologie s
Web Services
Figura 5: Clasificación Cloud Computing [24]
Infraestructure as a Service (IaaS): La infraestructura como servicio proporcio-
na mediante acceso web capacidad de almacenamiento y cómputo, normalmente
mediante plataformas de virtualización. El usuario no necesita gestionar la infraes-
tructura distribuida que hay subyacente, pero puede controlar el sistema operativo,
el almacenamiento y las aplicaciones instaladas.
Platform as a Service (PaaS): La plataforma como servicio permite ofrecer las
herramientas para el desarrollo y almacenamiento de aplicaciones web. Pueden dar
soporte a todas las fases del ciclo de desarrollo y pruebas del software, o centrarse
en algún área como puede ser los Sistemas de Gestión de Contenidos.
Software as a Service (SaaS): El software como servicio permite ofrecer aplicacio-
30
nes completas a múltiples dispositivos cliente a través de una interfaz como puede
ser un navegador web.
SaaS
El software como servicio (Software as a Service, SaaS) es un modelo de distribución
de software donde el propio software y los datos que maneja se alojan en servidores de
la compañía que ofrece el servicio. La aplicación es accedida mediante un navegador
web a través de internet.
La empresa que ofrece el servicio es quien proporciona el mantenimiento y soporte
del software. Esto permite que las actualizaciones en el mismo se lleven a cabo de
forma centralizada y transparente al usuario, el cual no necesita realizar instalaciones o
realizar ninguna otra acción.
Además, en el modelo más habitual, el pago no se realiza por compra de licencia, que
se restringe a una versión del producto, si no por el pago de alquiler del servicio, bien
de forma mensual, anual o por otros períodos de tiempo, lo cual suele incluir todas las
actualizaciones de versiones que se lleven a cabo.
Aunque el modelo SaaS dispone de una serie de desventajas frente al modelo de dis-
tribución de software tradicional, entre las que destacan la dependencia del servicio de
Internet para poder acceder al software así como los riesgos de externalización de in-
formación privada a la empresa, actualmente su uso está aumentando rápidamente en el
mercado, así como la confianza que depositan los clientes en ella.
Un estudio realizado por IDC [25] establece que las empresas que eligen SaaS como
vía de adquisición de software está creciendo mucho más rápido que las que optan por
los modelos tradicionales.
Este aumento se debe al mayor conocimiento de las características de este modelo. Si
se observa la figura 6, se puede observar que a medida que aumenta el conocimiento
por parte de las empresas del modelo SaaS, aumenta su interés en buscar proveedores,
y a su vez, en adoptar este modelo.
31
100%
68%65%
46% 85% 95%
Un 68% del total de empresas están familiarizada con SaaS
Un 65% de las que están familiarizadas conocen no sólo el modelo sino también proveedores
Un 46% de las que conocen el modelo poseen un conocimiento profundo
85% de las anteriores lo utilizan
Un 95% seguirán utilizando SaaS
Figura 6: Conocimiento y adopción del SaaS [25]
También cabe destacar el dato de que sólo un 5% de las empresas que utilizan SaaS
deciden abandonarlo y volver al modelo tradicional de distribución de software.
Además, este estudio analiza los principales beneficios que encuentran las empresas
que están evaluando la adopción de SaaS (ver figura 7).
32
Incrementar la efectividad de la seguridad
Añadir o elminar usuarios con facilidad
Cuaota mensual/anual
Acceder en cualquier momento y lugar
Ahorro en personal y formación especial
Ahorro en servidor de aplicaciones
Menor inversión inicial
Poder pagar por uso/Si comprar licencia
Rapidez y abaratamiento de la implantación
No preocuparse por las actualizaciones
0 10 20 30 40 50 60 70
Figura 7: Beneficios del SaaS [25]
Entre todos, cabe señalar la importancia de abstraerse de las actualizaciones del soft-
ware, además de sus bajos costes de implantación, y la flexibilidad en la forma de pago
frente al software tradicional.
Todos estos datos garantizan una gran expansión del uso de este tipo de software tanto
a medio como largo plazo. Aunque tampoco hay que olvidar los temores de la orga-
nización a la hora de adquirir este tipo de servicios, que se deberían poder mitigar.
Principalmente, los riesgos de seguridad, así como la dependencia del proveedor del
servicio y la dificultad de extraer la información de dichas aplicaciones.
3.2.2 Seguridad
En cualquier tipo de proyecto software existen numerosos tipos de problemas y agujeros
de seguridad que comprometen el funcionamiento del mismo, y la integridad, confidenciali-
dad y disponibilidad de la información que manejan.
En el caso de las aplicaciones web basadas en el modelo SaaS, estas aumentan debido a
la naturaleza pública y accesible a través de Internet de este tipo de software.
33
Como se ha mostrado en el apartado anterior, la seguridad es uno de los aspectos más
importantes y que más preocupa a las empresas para la adopción de este tipo de software.
A continuación se enumeran distintos tipos de vulnerabilidades y problemas de seguridad
que afectan a este tipo de software [26]:
Inyección SQL: La inyección SQL o SQL Injection permite incrustar código SQL in-
vasor dentro del código SQL programado en la aplicación, alterando el funcionamiento
normal del programa. Este funcionamiento alterado permitiría acceder a información
no accesible en un principio, o incluso la eliminación de la propia información. Es-
ta vulnerabilidad se produce debido a la incorrecta validación o filtrado de los datos
introducidos en el programa.
Ataque Man-in-the-middle: Este tipo de ataque permite leer, insertar o modificar infor-
mación entre dos partes sin que ninguna conozca que la comunicación ha sido violada.
Para ello, el atacante deberá ser capaz de interceptar los mensajes entre ambas víctimas.
Escalada de privilegios: Esta vulnerabilidad aparece debido a fallos en la programación
de la aplicación, que permite a un usuario autenticado correctamente en la aplicación a
acceder a funcionalidad o información a la que no debería poder acceder según su rol.
3.2.3 Tecnologías
PHP
Actualmente, la función de las páginas web va más allá de ser páginas estáticas donde
se muestra información no variable en documentos HTML (Hypertext Markup Lan-
guage), sino que han ido derivando en páginas web dinámicas, las cuales responden
las peticiones del navegador ejecutando código en el servidor, derivando en completas
aplicaciones web.
PHP (PHP Hypertext Pre-Processor) [27] es un lenguaje de programación interpretado
(no se compila para obtener un código máquina, sino que un intérprete ejecuta el código
fuente), que permite crear páginas web dinámicas ejecutando código en el servidor y
devolviendo una página HTML al cliente, la secuencia de ejecución se muestra en la
figura 8.
34
Servidor
PHPHTML La página se ejecuta para convertirse en código HTM
La página HTML se envía al cliente
Solicita una página al servidor
Es una página PHP
Figura 8: Secuencia PHP
Fue creado por Rasmus Lerdoff en 1994 como un conjunto de scripts en Perl y pos-
teriormente traducido a C. Zeev Suraski y Andi Gutmans reescribieron el analizador
sintáctico incluyendo nuevas funcionalidades como el soporte a nuevos protocolos de
Internet y el soporte a la gran mayoría de las bases de datos comerciales, como MySQL
y Postgre SQL, además de muchos otros módulos creados por otros desarrolladores.
Con estas mejoras surgió PHP3 en 1998.
PHP4 fue liberado en 2000. Utilizaba el motor Zend (intérprete del código PHP), e
incorporaba grandes avances aparte de un gran aumento de rendimiento, entre las que
se encontraban el soporte para la mayoría de servidores web, uso de sesiones HTTP y
validación de entradas de usuario.
En julio de 2005 se lanzó PHP5, la última versión estable de PHP. Dispone de un nuevo
motor denominado Zend Engine 2.0 el cual contiene un nuevo modelo de objetos y
diversas nuevas opciones.
Actualmente se encuentra en fase de pruebas la versión 6 de PHP, esta versión es total-
35
mente funcional aunque no se encuentra en su versión estable. Las principales caracte-
rísticas son que es compatible con el estandar Unicode y además tiene implementadas
diversas mejoras en la orientación a objetos.
En un futuro está previsto el lanzamiento de PHP7 o PHPNG, el cambio más importante
respecto a versiones anteriores es una increíble mejora en su rendimiento llegando a ser
dos veces más rápido que su antecesor.
PHP es de código abierto (Open Source) por lo que es uno de los lenguajes de progra-
mación web más extendidos. Entre sus principales características están:
Es un lenguaje multiplataforma.
Permite utilizar el paradigma de programación orientada a objetos.
Débilmente tipado.
Manejo de excepciones (desde PHP5).
Capacidad de conexión con la mayoría de motores de base de datos.
MySQL
MySQL [21] es un sistema de gestión de bases de datos relacional, multihilo y multi-
usuario. Se basa en el estándar de bases de datos relacionales ANSI SQL (Structured
Query Language), desplegado originariamente por IBM en 1981.
El desarrollo de MySQL lo lleva a cabo una empresa privada aunque su publicación
está bajo licencia GPL aunque si una empresa desea utilizarlo en un producto comercial
debe compara una licencia especifica para ese uso. En su mayor parte está realizado en
C.
Este sistema gestor de bases de datos es ampliamente utilizado en aplicaciones web,
debido a la baja concurrencia en la modificación de datos y en la alta frecuencia de
lectura de datos de este tipo de aplicaciones.
Dispone de diversos motores de almacenamiento útiles en diferentes casos, como son
MyISAM que permite una gran velocidad en las consultas, ó InnoDB el cual permite
realizar transacciones de tipo ACID y mantener la integridad referencial.
Su última versión estable publicada es la 5.6.
36
Sus principales características son:
Implementación de un amplio subconjunto del estándar ANSI SQL 99, además de
varias extensiones del mismo.
Soporte multiplataforma.
Disparadores (Triggers).
Cursores.
Vistas actualizables.
Varios motores de almacenamiento.
Sistema de reserva de memoria muy rápido basado en threads.
Joins muy rápidos usando un multi-join de un paso optimizado.
APIs disponibles para múltiples lenguajes, como C, C++, Java, Perl, PHP, Python
o Ruby entre otros.
Uso de multi-hilo mediante threads del kernel.
Javascript
Javascript [22] es un lenguaje de programación interpretado (no necesita de compila-
ción previa a la ejecución), basado en el estándar ECMAScript. Se usa principalmente
en páginas web dinámicas permitiendo diversas mejoras en la interfaz de usuario y en
la usabilidad de aplicaciones web. Actualmente, todos los navegadores interpretan este
lenguaje.
Dispone de una sintaxis similar a C, aunque adopta algunos nombres y convenciones
de Java. Sin embargo, más allá de eso, no tiene ninguna relación con Java, sirviendo a
propósitos diferentes. Para interactuar con los elementos de una página web, Javascript
dispone de una implementación del DOM (Document Object Model), que proporciona
un conjunto estándar de objetos para representar documentos HTML y XML.
El lenguaje fue inventado por Brendan Eich en la empresa Netscape Communications,
que es la que desarrolló los primeros navegadores web comerciales. Apareció por pri-
mera vez en el producto de Netscape llamado Nestcape Navigator 2.0.
37
AJAX
AJAX [22] es un acrónimo de Asynchronous JavaScript And XML (JavaScript asín-
crono y XML), es una técnica de desarrollo web para crear aplicaciones interactivas.
Consta de distintas tecnologías (ver figura 9) como son:
XHTML y CSS, para crear una presentación basada en estándares.
DOM, permite la interacción y manipulación dinámica de la presentación.
XML, JSON y XSLT, para realizar el intercambio de información.
XMLHttpRequest, permite realizar el intercambio de información de forma asín-
crona.
JavaScript, para realizar las llamadas de Ajax y utilizar el resto de tecnologías.
XHTML CSS XML JSON
DOM XMLHttpRequest
JAVASCRIPT
Figura 9: Tecnologías que conformas AJAX [22]
En las aplicaciones web tradicionales, las acciones del usuario en la página desenca-
denan llamadas al servidor. Una vez recibida y procesada la petición del usuario, el
servidor genera el código de una nueva página en lenguaje HTML y la devuelve al
navegador web.
Esta técnica tradicional para crear aplicaciones web funciona correctamente, pero no
38
crea una buena sensación al usuario. Cuando se realizan peticiones continuas al servi-
dor, el usuario experimenta la sensación de lentitud ya que debe esperar a que la página
de recargue de nuevo con los cambios solicitados. De esta forma la aplicación que debe
realizar peticiones continuas provoca que su uso se convierta en algo molesto.
AJAX permite mejorar completamente la interacción del usuario con la aplicación, evi-
tando las recargas constantes de la página, ya que el intercambio de información con el
servidor se produce en un segundo plano.
Los programas implementados con AJAX eliminan la recarga constante de páginas
mediante la creación de un elemento intermedio entre el servidor y el usuario. La capa
intermedia de AJAX produce una mejora la respuesta del programa, ya que el usuario
nunca se encuentra con una ventana del navegador vacía esperando la respuesta del
servidor. En la figura 10 se puede observar el flujo de peticiones y respuestas del modelo
clásico de aplicación web y el que se produce mediante el uso de AJAX.
Interfaz del usuario
Servidor web
BBDD, backend, sistemas heredados
Interfaz del usuario
Motor Ajax
Servidor web/XML
BBDD, backend, sistemas heredados
Transporte http(s) Transporte http(s)
Navegador del cliente
Navegador del cliente
Servidor Servidor
Datos HTML+CSS Datos XML
Petición HTTP
Datos HTML+CSSLlamada Javascript
Modelo clásico Modelo Ajax
Figura 10: Modelo clásico frente a Ajax [22]
39
Normalmente el envío de información del servidor al cliente como respuesta de la peti-
ción realizada por AJAX suele estar en un lenguaje estructurado como puede ser JSON
o XML, aunque no es necesario, ya que la respuesta puede enviarse como texto.
También es de destacar el hecho de que mediante AJAX se pueden realizar llamadas
síncronas al servidor, aunque sin recargar la página. Esto produce que se bloquee la
ejecución del código en el cliente hasta que se haya obtenido la respuesta a la petición.
Java (applet)
Java es un lenguaje de programación orientado a objetos desarrollado por Sun Mi-
crosystems a principios de los años 90. El lenguaje en sí mismo toma mucha de su
sintaxis de C y C++, pero tiene un modelo de objetos más simple y elimina herramien-
tas de bajo nivel, que suelen inducir a muchos errores, como la manipulación directa de
punteros o memoria.
Un compilador es un programa que permite traducir el código fuente de un programa en
lenguaje de alto nivel, a otro lenguaje de nivel inferior (típicamente lenguaje máquina).
De esta manera un programador puede diseñar un programa en un lenguaje mucho más
cercano a como piensa un ser humano, para luego compilarlo a un programa manejable
por un ordenador. Este proceso de traducción se conoce como compilación.
Los programas escritos en Java están compilados en un bytecode, aunque la compila-
ción en código máquina también es posible. En tiempo de ejecución, el bytecode es
interpretado o compilado a código nativo para la ejecución, aunque la ejecución directa
por hardware del bytecode por un procesador Java también es posible.
La implementación original y de referencia del compilador, la máquina virtual y las bi-
bliotecas de clases de Java fueron desarrolladas por Sun Microsystems en 1995. Desde
entonces, Sun ha controlado las especificaciones, el desarrollo y evolución del lenguaje
a través del Java Community Process, si bien otros han desarrollado también imple-
mentaciones alternativas de estas tecnologías de Sun, algunas incluso bajo licencias de
software libre.
Un applet es un una aplicación que se ejecuta dentro de otro programa, por ejemplo
dentro de un navegador web. Concretamente un applet Java es un programa escrito en
40
este lenguaje que se integra dentro de un documento web y que se ejecuta cuando el
navegador carga la pagina HTML.
UML
UML son las siglas de “Unified Modeling Language” o “Lenguaje Unificado de Mode-
lado”. Se trata de un estándar que se ha adoptado a nivel internacional por numerosos
organismos y empresas para crear esquemas, diagramas y documentación relativa a los
desarrollos de software.
Librerías
Para la realización de este Proyecto Fin de Grado, se han utilizado diversas librerías de
las que se va a realizar una breve descripción.
PHPMailer: Librería que permite el envío de correos electrónicos desde PHP, y que
entre otras características permite conectar con servidores SMTP, adjuntar archivos,
enviar correos en HTML a múltiples destinatarios, incluyendo con copia oculta (CCO).
Facilita el control de errores en el envío o la conexión, y amplia el comportamiento de
la función mail() propia de PHP.
jQuery: Es un framework de JavaScript que permite simplificar la interacción con do-
cumentos HTML, manejar eventos y desarrollar animaciones. Soporta el uso de exten-
siones o plugins, de los cuales cuenta con un gran catálogo.
DHTMLX: Es una biblioteca desarrollada en JavaScript con múltiples componentes
que permiten construir interfaces web dinámicamente. Entre otros, permite la cons-
trucción de tablas, árboles, conjuntos de pestañas y menús que permiten mostrar la
información de una manera estructurada, además de interaccionar con ella.
ADLDAP: Es una librería que proporciona autenticación contra LDAP e integración
con Active directory.
GreyBox: Librería para la implementación de ventanas emergentes dentro de un en-
torno web.
Blowfish: Librería para Javascript que implementa el método blowfish de cifrado de
datos.
41
DNIe
El Documento Nacional de Identidad electrónico (DNI electrónico) emitido por la Di-
rección General de la Policía (Ministerio del Interior), es el documento que además de
acreditar físicamente la identidad personal de su titular permite [31]:
Acreditar electrónicamente y de forma inequívoca la identidad de la persona.
Realizar la Firma digital de documentos electrónicos, dandoles así una validez
jurídica equivalente a la que proporciona la firma manuscrita.
La principal novedad del documento es que incorpora un pequeño circuito integrado
(chip), que contiene los mismos datos que aparecen impresos en la tarjeta (datos per-
sonales, fotografía, firma digitalizada, huella dactilar digitalizada) junto con los Certi-
ficados de Autenticación y de Firma Electrónica.
De esta forma, cualquier persona podrá realizar múltiples gestiones online de forma
segura con las Administraciones Públicas, con las empresas públicas y privadas y con
otros ciudadanos.
El certificado electrónico es un documento digital que expedido por una Autoridad de
Certificación identifica a una persona (física o jurídica) con sus respectivas claves.
Con el DNI electrónico se obtienen dos certificados:
Certificado de Autenticación, que garantiza la identidad del ciudadano dentro del
ámbito electrónico al realizar una transacción telemática. Asegura que la comuni-
cación electrónica se realiza realmente con la persona adecuada, con el certificado
de identidad y la clave privada asociada al mismo.
Certificado de Firma,permite realizar la firma de trámites y documentos, sustitu-
yendo así a la firma tradicional. De esta forma, garantiza la identidad del firmante
y del poseedor de la clave privada de identificación y firma.
El DNI electrónico es por lo tanto un instrumento de impulso de la Sociedad de la
Información dado que permite trasladar al mundo digital las mismas certezas con las
que operamos cada día en el mundo físico.
42
4 MÉTODO DE TRABAJO
Como en el apartado anterior, el método de trabajo se divide en dos partes. Por un lado
se muestra la metodología seguida para la implementación del sistema experto y por otra
se define el marco de trabajo elegido para el desarrollo de la aplicación. Cabe destacar que
la metodología de desarrollo afecta también a la implementación del sistema experto pero
debido a la naturaleza específica de este se ha optado por separarlas.
4.1 Sistema experto
En este apartado se enumeran y posteriormente detallan los pasos a seguir para imple-
mentar un sistema experto. En la figura 11 se muestra el ciclo general de creación y mante-
nimiento de un sistema experto.
Planteamiento del Problema
Encontrar Expertos Humanos
Diseñar Sistema Experto
Elegir Herramienta Desarrollo
Construir Prototipo
Probar Prototipo
Refinamiento y Generalización
Mantenimiento y Puesta al día
Figura 11: Flujo de creación y mantenimiento de un sistema experto
A continuación se enumeran los pasos específicos para la creación del sistema experto [6].
Características del sistema experto.
Estudio de viabilidad.
Adquisición del conocimiento.
Implantación.
Evaluación y pruebas.
4.1.1 Características del sistema experto
Cuando se desea implementar un sistema experto en primer lugar debe definirse el alcance
y los limites de dicho sistema, se deben indicar que aspectos cubre el sistema experto y que
aspectos quedan fuera del ámbito del sistema.
Define las características del problema. Se pretende determinar la naturaleza del proble-
ma y los objetivos precisos que indique exactamente cómo se espera que el sistema experto
contribuya a la solución de los problemas. Existirá una interacción entre experto e ingenie-
ro. Cuando el experto en el dominio muestre distintos casos, el ingeniero del conocimiento
desarrolla una "primera"descripción del problema. Normalmente el experto no esta de acuer-
do con ella, o mejor dicho, no siente que se representa el problema en su totalidad, entonces
el ingeniero reformulará la descripción. Esta actividad prosigue hasta que los dos estén de
acuerdo en la descripción.
4.1.2 Estudio de viabilidad
Teniendo claro el alcance del sistema experto debe estudiarse si la implementación del
mismo es posible desde el punto de vista de la computación. Para esto se realiza un estudio de
viabilidad, en este caso se utiliza un estudio de viabilidad basado en el test de SLAGEL [6].
Este estudio establece si el proyecto cumple las siguientes características.
Plausible, Determina si es posible resolver el problema desde el punto de vista de la
ingeniería del conocimiento.
44
Justificable, Analiza si está justificado el desarrollo del sistema desde la perspectiva
de la ingeniería del conocimiento, se basa en temas como la necesidad del sistema y la
inversión a realizar.
Adecuado, Establece si el problema a resolver está dentro del marco de la ingeniería
del conocimiento, existen problemas que son más adecuados resolverlos por métodos
tradicionales.
Éxito, Determina las probabilidades de éxito del sistema a desarrollar, es una estima-
ción.
El método del Test de SLAGEL se define en el Anexo I.
4.1.3 Adquisición del conocimiento
Una de las partes más importantes y a la vez más complicadas de la implementación de
un sistema experto es obtener el conocimiento, normalmente de un experto, y volcarlo en
el sistema experto. Existen muchas herramientas y métodos para obtener este conocimiento
entre las cuales está la entrevista, la observación y la creación de escenarios.
La adquisición del conocimiento es la principal complicación en el desarrollo de Sistemas
Expertos. Consiste en que las personas no expertas en el dominio donde se va a desarrollar
el Sistema Experto extraigan el conocimiento necesario para resolver problemas de diversas
fuentes. El proceso de adquisición del conocimiento ha seguido diferentes etapas que podrían
resumirse en las siguientes:
Primeras reuniones con los expertos y evaluación de la viabilidad del proyecto.
Extracción de conocimientos (A partir de la documentación disponible, como por ejem-
plo, libros, conferencias, Internet, etc.)
Deducción de conocimientos a partir de los expertos.
45
PERSPECTIVAS FASES DEL PROCESO
Qué del entorno
Entorno
Usuarios
Deducción
Extracción
Primeras reuniones
Figura 12: Etapas del proceso de adquisición del Conocimiento
Además se logra la familiarización del Ingeniero del Conocimiento en el contexto en el
que va a trabajar. Se busca en las primeras reuniones describir conocimientos generales, así
como afianzarse con la terminología.
La estructura de las entrevistas se define en el anexo III.
Una vez obtenido el conocimiento hay que designar estructuras para organizar el conoci-
miento. Después de haber determinado el problema en toda su magnitud, sin haberse referido
a técnicas de programación o a indagar solo en los métodos que son exitosos en inteligen-
cia artificial, es en esta etapa donde el ingeniero del conocimiento selecciona estructuras
apropiadas a este sistema experto en particular. Es decir, que dan solución total o parcial al
problema analizado en las etapas precedentes. Una de las responsabilidades principales del
ingeniero del conocimiento es analizar situaciones tipo y a partir de ellas extraer las reglas
que describan el conocimiento del experto en el dominio.
4.1.4 Implantación
Desarrolla la transformación de los conocimientos representados en el modelo formal en
un modelo computable.
Elaboración de las reglas que incorporen el conocimiento. Se pretende en esta ocasión
46
usar las herramientas y técnicas predeterminadas para implementar una primera versión o
prototipo del sistema. Este prototipo esta destinado a evaluar los progresos que se van ha-
ciendo, y por ende, retornar a etapas anteriores si es necesario.
Una vez que el sistema prototipo se ha perfeccionado lo suficiente para ser ejecutado, el
sistema experto estará listo para ser probado.
4.1.5 Evaluación y pruebas
Establece el grado de experiencia alcanzado por el sistema. De manera tal que expertos
en el área que han o no participado en el desarrollo del proyecto se comprometen a evaluar el
desempeño del sistema, tratando de vislumbrar la calidad de asistencia que brinda el Sistema
Experto ante diferentes casos de problemas a resolver por software. También se evalúa la
amplitud y generalidad de marcos compuestos que posee el repositorio y cómo el sistema
guía su uso.
Se considera que el sistema experto esta terminado cuando realiza trabajos a nivel del es-
pecialista. Entonces, el proceso de "prueba"no esta listo hasta que las soluciones propuestas
por el sistema sean tan válidas como las propuestas por el experto humano.
4.1.6 Motor de inferencia
El sistema experto que se va a desarrollar siguiendo la metodología anterior va a funcionar
sobre un motor de inferencia desarrollado para tal fin, el motor de inferencia se basa en el
motor implementado para CLIPS y a continuación se van a detallar las características de
dicho motor.
Algoritmo de selección de reglas aplicables en CLIPS
Elegir la regla aplicable con máxima prioridad.
Elegir la regla según estrategia de resolución de conflictos.
Elegir de forma arbitraria.
Las estrategias definidas en el motor de inferencia de CLIPS para la selección de reglas
aplicables o activas son varias.
47
Depth Strategy (estrategia por defecto). Una activación que contiene el hecho más
reciente se sitúa por encima de las activaciones con igual o mayor antigüedad.
Breadth Strategy. Una activación que contiene el hecho más reciente se sitúa por
debajo de las activaciones con igual o mayor antigüedad.
Complexity Strategy. Las nuevas activaciones se sitúan por encima de las activa-
ciones con igual o menor especificidad (no de comparaciones que han de realizarse
en el antecedente una la regla).
Simplicity Strategy. Las nuevas activaciones se sitúan por debajo de las activacio-
nes con igual o mayor especificidad.
LEX Strategy. Se ordenan los time-tag en orden decreciente y se comparan uno a
uno, hasta encontrar uno mayor que otro, en caso de que no haya el mismo número
de time-tag se añaden ceros al final.
MEA Strategy. Parecido a LEX, pero mirando sólo el primer patrón que equipara
en la regla.
Random Strategy. A cada activación se le asigna un número aleatorio para deter-
minar su orden en la agenda.
Definición prioridades en CLIPS
Asignar un valor de prioridad (entero positivo) a cada regla.
En CLIPS se definen como propiedades de reglas.
Se recomienda minimizar el uso de prioridades de reglas.
48
4.2 Herramienta Web
A lo largo de este capítulo se detallará el proceso seguido para desarrollar la herramienta
de autenticación.
4.2.1 Metodología SCRUM
Para el desarrollo de la herramienta se ha utilizado una metodología basada en Scrum [9]
que se trata de un modelo de desarrollo iterativo e incremental. A continuación se detallan
las características del modelo:
Iteranciones
Cada una de las iteraciones del proceso de desarrollo se denomina “Sprint”. Este Sprint
deberá tener una duración de entre 15 y 30 días, al final del cual se obtiene un Incre-
mento, que es un resultado completamente terminado y en condiciones de ser usado.
Reunión inicio de SPRINT
Reunión diaria
Desarrollo de tareas
Fase de pruebas
Reunión fin de SPRINT
Figura 13: Cliclo SCRUM
Para este Proyecto de Fin de Grado se han realizado sprints de 30 días (4 semanas)
49
de duración. De este tiempo, 3 semanas han sido dedicadas al desarrollo de las tareas
definidas en la Pila de tareas del sprint, así como a las pruebas unitarias o de funciona-
miento de las mismas. La última semana se ha dedicado a pruebas de integración, así
como de seguridad en un entorno real. Esta estructura se puede ver en más detalle en la
figura 13.
En el capítulo siguiente se tiene una tabla con los sprints realizados y la funcionalidad
implementada en cada uno de ellos.
Definición de elementos
Existe una serie de elementos o documentos importantes a lo largo de todo el proceso:
Product Backlog (Pila de producto): Está formado por una lista de todos los re-
quisitos del sistema (historias de usuario), descritos en alto nivel y priorizados. Es
accesible a todas las personas que intervienen en el desarrollo. Puede ir modificán-
dose durante todo el ciclo de vida.
Sprint Backlog (Pila de tareas de sprint): Es la lista de todas las tareas a realizar
durante el sprint para obtener el incremento deseado. Las tareas tienen estimados el
tiempo y los recursos necesarios para realizarlos. Ninguna de las tareas debe tener
una duración mayor de 16 horas, en cuyo caso habrá que subdividirla.
Incremento: Es el resultado que se obtiene después de cada iteración o sprint. Este
resultado está completamente terminado y puede ser usado.
Para el desarrollo de este proyecto, la pila de producto la conforma desde un principio
todas las funcionalidades a implementar, obtenidas a partir de la metodología de im-
plantación. Estas funcionalidades pueden estudiarse con mayor detalle en el capítulo
siguiente, así como el análisis y diseño realizado sobre las mismas.
Estas tareas de análisis han sido realizadas mediante casos de uso modelados mediante
UML.
Además de las funcionalidades iniciales identificadas, a lo largo del proyecto se han
ido añadiendo otras tareas a la Pila de producto, como generación de informes para las
distintas partes, el manual de usuario asociado, o pequeñas mejoras identificadas una
vez entregado el producto de cada sprint.
50
Definición de roles
El personal implicado en el desarrollo de la herramienta se divide en dos grupos: “Cer-
dos” y “Gallinas”. Los Cerdos son el personal implicado en el desarrollo del proyecto.
Los roles dentro de este grupo son:
Product Owner (propietario del producto): Representa al cliente. Se encarga de
escribir las historias de usuario, priorizarlas y colocarlas en la Pila de producto.
Scrum Master (responsable de Scrum): Se encarga de asegurarse que el proceso de
desarrollo definido se cumple y existe el menor número de desviaciones.
Equipo: El equipo de desarrollo es responsable de entregar el producto.
En el caso de este Proyecto de Fin de Grado, los roles Product Owner y Scrum Master
han sido desempeñados por el director de proyecto, mientras que el equipo de trabajo
lo ha formado una única persona que es el autor del proyecto.
Los roles Gallinas no forman parte del proceso, aunque se deben tener en cuenta, ya que
de ellos se debe obtener retroalimentación después de cada sprint así como requisitos y
prioridades en las reuniones de planificación. Los roles que se incluyen en este grupo
son: usuarios, clientes, inversores y otros stakeholders.
En este caso concreto, los roles Gallinas han sido los usuarios finales de la herramienta,
dirección de la empresa y expertos en seguridad.
Definición de reuniones
En la metodología Scrum existen distintos tipos de reuniones que sirven para realizar
la planificación de tareas de un sprint, el análisis de nuevas tareas a incorporar en la
Pila de producto, realizar un seguimiento del mismo, así como para validar el resultado
obtenido en cada uno de los sprints. Estos tipos de reuniones son las siguientes:
Planificación de sprint (o reunión de inicio de sprint): En ella se selecciona de la
pila de producto el trabajo que se va a realizar en ese sprint, se realiza un análisis
de los requisitos, y se estima la duración de cada tarea. En esta reunión, donde
participan Cerdos y Gallinas, tiene una duración de unas 8 horas. Su resultado será
la pila de tareas del sprint.
51
Seguimiento de sprint: Es una reunión diaria con una duración máxima de 15 mi-
nutos para revisar el trabajo realizado desde la reunión anterior, planificar el trabajo
a realizar hasta la próxima reunión y comentar los problemas que se han tenido en
caso de ocurrir desviaciones en la duración de las tareas. En ella sólo participa el
equipo de desarrollo y el Scrum Master.
Revisión de sprint (o reunión de fin de sprint): Es una reunión para revisar el trabajo
completado y no completado, presentar el trabajo completado (incremento) a los
interesados, analizar causas de desviaciones. Tiene una duración de unas 4 horas.
Para este proyecto, las reuniones de inicio de sprint han servido para definir las tareas a
incluir en el mismo, además de definir junto con los usuarios finales de la herramienta
requisitos concretos de usabilidad y apariencia para las funcionalidades a implementar.
Las reuniones diarias de seguimiento del sprint no se han realizado siempre, principal-
mente debido a problemas de disponibilidad del Scrum Master (el director del proyec-
to), pero como mínimo se han realizado una vez por semana, y han servido para evitar
que problemas respecto a la implementación de las tareas supusieran retrasos graves en
la planificación de los sprints, además de evitar que se tuvieran que realizar modifica-
ciones sobre dichas tareas en sprints posteriores.
Las reuniones de fin de sprint se han utilizado para realizar una demo o presentación de
la funcionalidad implementada a las partes interesadas, en las cuales se han propuesto
cambios o mejoras sobre la misma, que se han incluido en la Pila de tareas.
4.2.2 Ciclo de vida SCRUM
El ciclo de vida de Scrum consta de cinco fases. Estas son:
Concepto: En esta fase se define la visión del producto por parte del cliente y el alcance
del mismo así como el equipo de trabajo.
Especulación: Partiendo de la visión del producto se realizan hipótesis (especulaciones)
acerca de lo que se desea producir. Estas hipótesis se contrastan con la realidad. Esta
fase está presente en cada iteración del desarrollo.
52
Exploración: En esta fase se desarrollan las funcionalidades y se genera un incremento
del producto.
Revisión: Se verifica el cumplimiento de la visión y los objetivos por parte del (sub)producto
generado.
Cierre: En esta fase se realiza la entrega pactada de un (sub)producto listo, revisado y
probado.
Fase I: Concepto
En esta fase, se ha definido el producto que se desea obtener. Este es el conseguir una
herramienta que permita La autenticación de un sistema utilizando diferentes fuente
para realizar dicha autenticación además de permitir la creación de reglas de seguridad.
Entre sus principales características debe estar:
Interfaz usable que permita una rápida familiarización con la misma.
Adaptación a empresas de diferentes sectores y tamaños.
Fase II: Especulación
Para el desarrollo de este proyecto, las especulaciones han tomado forma de funcionali-
dades descritas mediante casos de uso, que se han analizado al comienzo del proyecto,
así como nuevas mejoras propuestas al final de cada sprint.
Fase III: Exploración
Para la implementación de las distintas funcionalidades se ha utilizado el paradigma de
Programación Orientación a Objetos (POO). Esta es una de las razones por las que se
eligió el lenguaje PHP, ya que tiene soporte para ello. Entre sus principales característi-
cas están: el encapsulamiento, que permite agrupar todos los elementos pertenecientes
a una misma entidad lo que aumenta la cohesión de los componentes del sistema. Tam-
bién el principio de ocultación, por el cual cada objeto está aislado del exterior y cada
clase expone una interfaz a otros objetos que especifica cómo pueden interactuar con
los objetos de esa clase. Por último, otra característica importante es la herencia, que
permite definir una jerarquía de clasificación, por la cual los objetos heredan las pro-
piedades y el comportamiento de las clases a las que pertenecen.
53
Para el desarrollo del proyecto se han utilizado distintos patrones de diseño. Estos son:
Patrón Modelo-Vista-Controlador: este patrón permite separar la lógica de nego-
cio de la interfaz de usuario, lo cual facilita la evolución por separado de ambos
aspectos e incrementa la reutilización y flexibilidad del código.
Patrón Agente base de datos (Broker): el agente de base de datos es un patrón que
se utiliza como adaptador entre una aplicación y el gestor de base de datos que
se esté utilizando. La idea de su utilización es que todas las clases persistentes
accedan a la base de datos a través del agente.
Patrón una clase, una tabla: mediante este patrón, se construye una tabla por cada
clase en el diagrama de clases, las asociaciones, agregaciones y composiciones
se transforman a relaciones de clave externa con la multiplicidad indicada por la
propia multiplicidad de la asociación, y las relaciones de herencia se transforman
a relaciones de clave externa con multiplicidad 1:1.
Fase IV: Revisión
En la fase de revisión se enmarcan las reuniones de fin de sprint, que sirven para com-
probar el cumplimiento de los objetivos del mismo, así como la adecuación del producto
implementado a las funcionalidades planificadas.
Como comentario a esta fase, se indica que todas las reuniones de fin de sprint tuvie-
ron un resultado satisfactorio, salvo pequeñas mejoras propuestas, principalmente en el
campo de la usabilidad.
Fase V: Cierre
La entrega final del producto se realizó una vez finalizada la implementación y acepta-
ción de todas las funcionalidades iniciales de la pila de producto, además de diversas
mejoras propuestas durante el ciclo de desarrollo.
Actualmente la herramienta se encuentra en una fase de mantenimiento, en la que se es-
tán incorporando nuevas funcionalidades no previstas en un principio, así como mejoras
en las existentes, a petición de los usuarios del sistema.
54
4.2.3 Validación
La validación, adecuación e idoneidad de la metodología y la herramienta asociada, se
ha realizado mediante su aplicación en un caso real. Cabe destacar que la mayor parte de la
funcionalidad desarrollada se utiliza actualmente en las herramientas de una empresa, ade-
más esta empresa desarrolla proyectos software para clientes donde también se han incluido
dichas funcionalidades de autenticación.
4.2.4 Fases dentro del desarrollo
Dentro de la metodología seguida, SCRUM, se debe proceder a la implementación de las
tareas, existen algunas tareas donde simplemente se realiza una investigación sobre el área
para después aplicar dichos resultados a una implementación posterior. Por otro lado hay
tareas que implican un desarrollo de código. Antes de empezar a realizar la implementación
se necesita cubrir unas fases críticas, estas fases son:
Análisis: En esta etapa se debe entender y comprender de forma detallada cual es el pro-
blema a resolver, verificando el entorno en el cual se encuentra dicho problema, de tal
manera que se obtenga la información necesaria y suficiente para afrontar su respectiva
solución. Esta etapa es conocida como la del QUÉ se va a hacer. En este proyecto el
análisis se realizará mediante casos de uso. Los diagramas de casos de uso representan
la forma en la que un cliente(Actor) opera con el sistema a desarrollar, por otro lado
también muestran la forma, el tipo y orden en como los elementos interactúan. Un dia-
grama de casos de uso consta de actores, casos de uso, relaciones entre los elementos.
En la figura 14 puede verse un diagrama de casos de uso genérico donde se expone un
caso de uso general que incluye varios casos de uso más específicos. También se puede
ver que existe un actor que interacciona con este caso de uso.
55
Caso de usogeneral
Caso de uso 1
Caso de uso 2
Caso de uso 3
Actor 2
Actor 1
<<Include>>
<<Include>>
<<Include>>
Figura 14: Diagrama de casos de uso genérico
Diseño: Una vez que se tiene la suficiente información del problema a solucionar, es impor-
tante determinar la estrategia que se va a utilizar para resolver el problema. Esta etapa
es conocida bajo el CÓMO se va a hacer. Para este proyecto se usarán diagramas de
secuencia para el diseño. Un diagrama de secuencia muestra los pasos que hay que rea-
lizar para llevar a cabo una tarea, en este caso para la implementación de un caso de uso.
Para ello se muestran lineas de secuencia entre los diferentes elementos que componen
el sistema e intervienen en la funcionalidad. En la figura 15 se muestra un ejemplo de
diagrama de secuencia donde se puede ver que un actor comienza una acción y provoca
que diferentes acciones o paso de mensajes se vayan lanzando entre diferentes objetos
o componentes.
Objeto 4Objeto 3Objeto 2Objeto 1
Actor
5: Acción6: Acción
4: Acción
3: Acción
2: Acción1: Acción
Figura 15: Diagrama de secuencia genérico
56
5 RESULTADOS
En esta sección del documento se explican los resultados obtenidos tras la aplicación del
método de trabajo descrito en el capítulo anterior.
5.1 Sistema experto
En este apartado se muestran los resultados de aplicar el método de trabajo, referente al
sistema experto, expuesto en el anterior apartado.
5.1.1 Características del sistema experto
El sistema experto que se desea implementar evalúa unos parámetros de entrada com-
puestos por unas características, estas características están predefinidas, esto es que existen
un repositorio o lista de características que pueden ser usadas. Las características son en
realidad elementos o configuraciones que se encuentran asociadas a una política de seguri-
dad, a un software y/o a una infraestructura. Los parámetros de entrada han sido definidos a
partir del estudio de la configuración de la seguridad en las empresas, en el Anexo II pueden
verse los resultados de dicho estudio. Estos parámetros son introducidos por el usuario a
través de un formulario interactivo, este formulario será desarrollado en la segunda parte de
este proyecto. Una vez introducidos los datos, el sistema experto procesa estos parámetros
infiriendo hechos que se toman como resultados finales o como nuevos datos para seguir el
proceso de inferencia. Para inferir dichos hechos se ha desarrollado un motor de inferencia
asociado al sistema experto que a partir de los parámetros que el usuario puede ir introdu-
ciendo en la aplicación y de reglas de producción que se han definido es capaz de inferir
información.
Parámetros de configuración de la contraseña (longitud, mayúsculas, minúsculas, nú-
meros, otros caracteres, caducidad, etc. . . )
Tipo de herramienta a la que se accede.
Localización de la herramienta (pública, privada, vpn).
Tipos de datos que trata la herramienta.
Existencia de captcha.
Existencia de límite de intentos.
La contraseña se envía por correo.
Se utilizan conexiones seguras.
Basándose en las variables anteriores el sistema experto determina si la configuración
elegida para la política de seguridad de la contraseña es adecuada, es decir, cumple con un
mínimo exigible.
De forma adicional el sistema experto propondrá la configuración óptima para los valores
de entrada. Los datos de referencia se basan en las tablas mostradas en el anexo II.
5.1.2 Estudio de viabilidad
Se procederá a realizar un estudio de viabilidad basado en el test de SLAGEL, este test
asigna pesos a una serie de características a evaluar divididas en diferentes categorías, des-
pués de los cálculos pertinentes se obtiene un porcentaje de viabilidad, para obtener un
porcentaje real se procederá por último a normalizar el resultado obtenido, en el apartado
anterior puede encontrase la definición del método seguido para el cálculo del estudio de
viabilidad.
Características de Posibilidad
Categoría Id. Catego-
ría
Peso Valor Característica Tipo
EX P1 10 9 Existen expertos. E
EX P2 10 9 El experto asignado es genuino. E
EX P3 8 8 El experto es cooperativo. D
EX P4 7 8 El experto es capaz de articular sus
métodos pero no categoriza.
D
TA P5 10 8 Existen suficientes casos de prueba;
normales, típicos, ejemplares, co-
rreosos, etc.
E
58
TA P6 10 9 La tarea está bien estructurada y se
entiende.
D
TA P7 10 8 Sólo requiere habilidad cognosciti-
va.
D
TA P8 9 8 No precisan resultados verdadera-
mente comprometidos con el pro-
yecto.
D
TA P9 9 8 La tarea no requiere sentido común. D
DU P10 7 7 Los directivos están verdaderamen-
te comprometidos con el proyecto.
D
Tabla 1: Características de posibilidad
ES: Expertos TA: Tarea DU: Directivos/Usuarios E: Esencial D: Deseable
Fundamentos Posibilidad
A continuación se fundamentan algunos de los valores elegidos para las características de
Posibilidad.
P1 - Existen expertos en el área empresarial y en el ámbito universitario con amplios co-
nocimientos sobre la seguridad y los criterios a seguir para evaluar la fiabilidad de las
contraseñas.
P3 - El experto pertenece a la empresa donde se va a desarrollar el proyecto por lo tanto es
altamente cooperativo, ya que este proyecto le permitirá rebajar su carga de trabajo una
vez finalizado.
P5 - Existen numerosos casos de prueba y métodos para comprobar si la composición de las
claves evitan que puedan ser comprometidas.
P7 - Sólo se requiere tener ciertos conocimientos sobre las pautas a seguir para alcanzar la
consecución correcta de la tarea.
P9 - La tarea no depende del sentido común, siguiendo una serie de reglas se pude cumplir
con la tarea.
59
Características de Justificación
Categoría Id. Catego-
ría
Peso Valor Característica Tipo
EX J1 10 8 El experto NO está disponible. E
EX J2 10 7 Hay escasez de experiencia huma-
na.
D
TA J3 8 8 Existe necesidad de experiencia si-
multanea en muchos lugares.
D
TA J4 10 7 Necesidad de experiencia en entor-
nos hostiles, penosos, y/o poco gra-
tificantes.
E
TA J5 8 8 No existen soluciones alternativas. E
DU J6 7 7 Se espera una alta tasa de recupera-
ción de la inversión.
D
DU J7 8 9 Resuelve una tarea útil y necesaria. E
Tabla 2: Características de Justificación
ES: Expertos TA: Tarea DU: Directivos/Usuarios E: Esencial D: Deseable
Fundamentos Justificación
A continuación se fundamentan algunos de los valores elegidos para las características de
Justificación.
J1 -Existen muchas empresas que no disponen de un experto en seguridad y que no tienen
los conocimientos necesarios para establecer una políticas de seguridad apropiada.
J2 -Podría decirse que no existe escasez de experiencia humana desde una visión global
pero dentro de nuestro ámbito de acción, empresas con poco conocimiento tecnológico
la experiencia humana no está presente. Por este motivo se valora esta característica con
un valor más bien alto.
J5 -No existen herramientas integradas, o por lo menos no se han encontrado, en los propios
sistemas de gestión que valoren si las políticas de seguridad son adecuadas al entorno
60
al que van dirigidas.
J6 -La tasa de recuperación no es directa pero evita brechas de seguridad que podrían hacer
perder a la empresa clientes y por consiguiente dinero.
J7 -Se podría decir que esta tarea es vital, la seguridad en los accesos es una de las partes
más importantes dentro de un sistema.
Características de Adecuación
Categoría Id. Catego-
ría
Peso Valor Característica Tipo
EX A1 5 7 La experiencia del experto está po-
co organizada.
D
TA A2 6 9 Tiene valor práctico. D
TA A3 7 8 Es más táctica que estratégica. D
TA A4 7 7 Sirve a necesidades a largo plazo. E
TA A5 5 8 La tarea no es demasiado fácil, pero
es de conocimiento intensivo, tanto
propio del dominio, como de mani-
pulación de la información.
D
TA A6 6 9 Es de tamaño manejable, y/o es po-
sible un enfoque gradual y/o, una
descomposición en subtareas inde-
pendientes.
D
EX A7 7 9 La transferencia de experiencia en-
tre humanos es factible.
E
TA A8 6 8 Estaba identificada como un proble-
ma en el área y los efectos de la in-
troducción de un SE pueden plani-
ficarse.
D
TA A9 9 9 No requiere respuestas en tiempo
real “Inmediato”.
E
61
TA A10 9 10 La tarea no requiere investigación
básica y usa, si alguna, poca gene-
ración y entendimiento del lenguaje
natural.
E
TA A11 5 8 El experto usa básicamente razona-
miento simbólico que implica fac-
tores subjetivos.
D
TA A12 5 9 Es esencialmente de tipo heurístico. E
Tabla 3: Características de Adecuación
ES: Expertos TA: Tarea E: Esencial D: Deseable
Fundamentos Adecuación
A continuación se fundamentan algunos de los valores elegidos para las características de
Adecuación.
A1 -El experto tienen los conocimientos pero a la hora de evaluar una política de seguridad
no sigue un método fijo sino que se guía más por su experiencia anterior pudiendo en
algunos casos fallar en la elección.
A2 -Como ya se ha indicado en apartados anteriores la seguridad y la elección de una política
de seguridad adecuada para cada caso es esencial y se aplica desde el primer momento.
A4 -Este sistema no se basa en la solución de un problema puntual sino que tendrá un reco-
rrido en el tiempo y por lo tanto permitirá captar clientes añadiendo valor a la aplicación
web, de esta forma se puede decir que cubre una necesidades a largo plazo.
A5 -La tarea no es fácil, aunque se podría elegir un nivel de seguridad alto para todos los
casos, podríamos estar forzando al usuario a realizar un esfuerzo excesivo y desmoti-
vando el uso de ciertas herramientas por su complejidad de acceso. Por lo tanto elegir
un nivel adecuado requiere de unos conocimientos intensivos del dominio.
A8 -La seguridad es siempre un área crítica en todos los sistemas de información, de esta
forma se denota que el sistema resuelve un problema en su campo de aplicación.
62
Características de Éxito
Categoría Id. Catego-
ría
Peso Valor Característica Tipo
EX E1 8 9 No se sienten amenazados por el
proyecto,son capaces de sentirse in-
telectualmente unidos al proyecto
D
EX E2 6 8 Tienen un brillante historial en la
realización de esta tarea.
D
EX E3 5 7 Hay acuerdos en lo que constituye
una buena solución a la tarea.
D
EX E4 5 9 La única justificación para dar un
paso en la solución es la calidad de
la solución final.
D
EX E5 6 9 No hay un plazo de finalización es-
tricto, ni ningún otro proyecto de-
pende de esta tarea.
D
TA E6 7 10 No está influenciada por vaivenes
políticos.
E
TA E7 8 7 Existen ya SS.EE. que resuelvan
esa o parecidas tareas.
D
TA E8 8 8 Hay cambios mínimos en los proce-
dimientos habituales.
D
TA E9 5 9 Las soluciones son explicables o in-
teractivas.
D
TA E10 7 8 La tarea es de I+D de carácter prác-
tico, pero no ambas cosas simultá-
neamente.
E
63
DU E11 6 9 Están mentalizados y tienen expec-
tativas realistas tanto en el alcance
como en las limitaciones.
D
DU E12 7 9 No rechazan de plano esta tecnolo-
gía.
E
DU E13 6 8 El sistema interactúa inteligente y
amistosamente con el usuario usua-
rio.
D
DU E14 9 9 El sistema es capaz de explicar al
usuario su razonamiento.
D
DU E15 8 10 La inserción del sistema se efectúa
sin traumas; es decir, apenas se in-
terfiere en la rutina cotidiana de la
empresa.
D
DU E16 6 7 Están comprometidos durante toda
la duración del proyecto, incluso
después de su implantación.
D
DU E17 8 9 Se efectúa una adecuada transferen-
cia tecnológica.
E
Tabla 4: Características de Éxito
ES: Expertos TA: Tarea DU: Directivos/Usuarios E: Esencial D: Deseable
Fundamentos Éxito
A continuación se fundamentan algunos de los valores elegidos para las características de
Éxito.
E1 -Este sistema experto disminuye la carga de trabajo en los expertos, que pueden dedicar
tiempo a otras tareas mientras otro tipo de usuario realiza el trabajo con el sistema
experto.
E4 -El fin último de este sistema experto es dar la solución más adecuada al problema, no es
64
suficiente con fijar siempre una política de nivel muy alto sino que debe corresponderse
con el nivel del ámbito donde se aplica.
E8 -El procedimiento es el mismo, lo único que cambia es que se puede realizar una evalua-
ción anterior o posterior para verificar si la elección es correcta.
E9 -Todos los resultados son coherentes y dependen directamente de los datos introducidos.
Resultado
En la tabla 5 se muestra el resultado de la evaluación de las diferentes dimensiones siguien-
do las fórmulas enunciadas en el test de Slagel. Una vez evaluadas dichas dimensiones se
obtiene la media y se normaliza el valor, es decir, se expresa en tanto por ciento.
Característica ∏(Valor total) ∏(Peso Total) Resultado Resultado VC
Posibilidad 31,752E8 13,377E8 (42,475E17)1/10 72,9145
Justificación 35,840E5 15,805E5 (56,647E11)1/7 66,3563
Adecuación 37,507E8 11,851E10 (44,451E19)1/12 52,5602
Éxito 98,323E12 60,4775E14 (3,25E18)1/17 56,4191
VC Total 62,0625
VC Normalizado Aprox. 86%
Tabla 5: Resultados del estudio de viabilidad
VC: Valor Característica
Conclusión
El porcentaje obtenido en la evaluación es suficiente como para seguir adelante con el
proyecto, además si normalizamos el resultado el porcentaje sube hasta un 86%, porcentaje
más que suficiente para confiar en la viabilidad del proyecto.
5.1.3 Adquisición del conocimiento
Las primeras entrevistas que se realizaron con los expertos y posibles usuarios del Sistema
Experto, en nuestro caso los responsables de sistemas, sirvieron para recoger los diferentes
requerimientos, requisitos funcionales del sistema, necesidades de los usuarios del futuro
sistema y lo que los usuarios esperan del mismo.
65
El siguiente paso en el proceso de adquisición ha sido el estudio de la documentación
existente. En este estudio se ha conseguido aprender sobre los diferentes sistemas de seguri-
dad y sus aplicaciones en los diferentes ámbitos.
Y en el último paso de la adquisición del conocimiento se han obtenido los conocimientos
privados de los expertos. Proceso de interacción de un experto humano con el propósito de
construir un Sistema Experto. Estos procesos se realizaron en forma de entrevistas abiertas
y mediante mensajería instantánea.
En el Anexo III se define la estructura de las entrevista y se detallan algunas de las dife-
rentes entrevistas que se realizaron.
5.1.4 Implantación
Para simplificar la implantación e implementación del sistema experto se ha optado por
utilizar un sistema de reglas compatible con CLIPS, es decir, el motor de inferencia que se
ha implementado está basado en el motor de CLIPS (Las características del motor de CLIPS
y por lo tanto del motor de inferencia implementado pueden verse en el apartado anterior,
sección del sistema experto, apartado “Motor de inferencia”) y por lo tanto es conveniente
que la creación de las reglas se haga siguiendo el formato fijado por CLIPS. Además de
esta manera se obtiene un sistema experto 100% compatible con CLIPS y si en un futuro
se desea conectar directamente este sistema experto con CLIPS podría hacerse sin modificar
las reglas.
En primer lugar se va a detallar el formato que sigue CLIPS para la formalización de las
reglas y los comandos que se utilizan para el manejo de los hechos.
Hechos
(facts) Lista los hechos de la Memoria de Trabajo.
(assert <hecho>) Añade un hechos a la Memoria de Trabajo.
(retract <indice-hecho>) Elimina un hecho de la MT.
(clear) Elimina todos los hechos y construcciones de la MT.
(reset) Elimina todos los hechos de la MT, elimina las activaciones de reglas y
restaura las condiciones iniciales.
66
Hipótesis del mundo cerrado, todo lo que no se encuentra en la Base de Hechos es
“falso”.
Reglas
Sintaxis.
(defrule <nombre_regla>
[<documentación opcional>][<caracteristicasop.>]
(premisa 1)(premisa 2)...(premisa N)
=>
(acción 1)(acción 2)...(acción M))
Semántica
Si “se cumplen” todas las premisas, se ejecutan todas las acciones.
Elementos de las premisas
1. Patrones. Existencia / ausencia de los hechos en la Base de Hechos, pueden
“instanciar” variables a partir de hechos.
2. Restricciones. Restricciones como premisas (tipo test), restricciones de varia-
bles (conectivas).
Una vez definida la estructura de las reglas se muestra el resultado en forma de conjunto
de reglas que definen el sistema experto, en primer lugar se enumeraran los hechos y después
se listaran las reglas.
5.1.4.1. Hechos posibles
sin_politica, indica que no hay ninguna política definida para los accesos, en este caso debe
evaluarse la política.
con_politica, indica que existe una política ya definida, a partir de ahora se intentará evaluar
dicha política.
67
longitud_minima, existe un mínimo número de caracteres de los que consta una contraseña,
es otro caso se define como contraseña mal definida.
longitud_mayor_8, la longitud de la contraseñas del sistema deben ser iguales o superiores
a 8 caracteres.
mayusculas, se obliga a que las contraseñas contengan letras en mayúscula.
numeros, se obliga a que las contraseñas contengan como mínimo un número.
especiales, se obliga a que las contraseñas contengan como mínimo un carácter especial ($,
&, etc. . . ).
caducidad, existe un peridodo máximo de uso para cada contraseña, llegado a ese tiempo
debe ser modificada obligatoriamente.
cambio_obligado, en el primer inicio de sesión se obliga a todos los usuarios a modificar la
contraseña que se le asigna.
envio_automatico, los credenciales se envían automáticamente a través de un correo elec-
trónico.
datos_sensibles, los datos que se tratan son datos críticos.
autenticacion_adicional, existen otros sistemas de seguridad que deben cumplirse antes de
acceder a la herramienta.
red_interna, el sistema se encuentra en una red interna.
limite_intentos, se define un número finito de intentos de acceso al sistema para cada usua-
rio.
captcha, junto a la contraseña existe una prueba de Turing completamente automática y
pública para diferenciar ordenadores de humanos.
ssl, existencia de conexión segura.
no_clientes, se permite a usuarios de los que no se tiene información acceder al sistema.
pass_comun, existen contraseñas comunes de acceso para varios usuarios.
68
logs, existe un registro de acciones y cambios donde se puede identificar a cada usuario.
tokens, existe un sistema de generación de tokens.
nivel1, define el nivel de la política.
nivelh1, define el nivel de la herramienta.
nivel2, define el nivel de seguridad.
nivelh2, define el nivel de la herramienta.
nivel3, define el nivel de seguridad.
nivelh3, define el nivel de la herramienta.
nivel4, define el nivel de seguridad.
nivelh4, define el nivel de la herramienta.
nivel5, define el nivel de seguridad.
nivelh5, define el nivel de la herramienta.
nivel6, define el nivel de seguridad.
nivelh6, define el nivel de la herramienta.
finalh, indica que el nivel definido para la empresa no va a cambiar.
5.1.4.2. Reglas
Las reglas que definen el sistema experto se detallan en el Anexo V del presente documento, a
modo de ejemplo se muestran a continuación un par de reglas y se explica su funcionamiento.
(defrule regla_7
(longitud_minima)
(longitud_mayor_8)
(mayusculas)
(numeros)
(especiales)
69
(cambio_obligado)
=>
(assert(nivel4)))
Esta regla acepta como hechos de entrada características de la contraseña y da como re-
sultado un nivel de seguridad, es decir, si en la memoria de trabajo se tienen los hechos
“longitud_minima”, “longitud_mayor_8”, “mayusculas”, “numeros”, “especiales”, “cam-
bio_obligado” la regla introduce un nuevo hecho “nivel4” infiriendo que con esos parámetros
de entrada el nivel de la política es 4.
(defrule regla_10
(con_politica)
(nivel1)
(nivelh1)
(finalh)
(evaluar)
=>
(printout t " La política de seguridad es adecuada " crlf))
Esta regla define un estado final, a partir de los parámetros de entrada se infiere que la
política de seguridad es adecuada, esta regla funciona como sigue, si existe una política
definida, el nivel de dicha política es 1, además se ha definido un nivel para el sistema, esto
se ve con los hechos nivelh1 y finalh, se quiere evaluar el sistema y además coinciden el nivel
de la política y el nivel del sistema se deduce que la política de seguridad es adecuada.
5.1.5 Evaluación y pruebas
El proceso de evaluación de un sistema experto puede dividirse en dos fases: verifica-
ción y validación. En el proceso de verificación se identificarán las posibles redundancias
de información, la completitud del sistema y la consistencia del mismo. En el proceso de
validación se comprobará que el sistema se comporta de la manera esperada y para los fines
para los cuales ha sido diseñado.
70
5.1.5.1. Verificación
En primer lugar se han identificado la información redundante o innecesaria, en el proceso
de implementación del experto se ha filtrado toda información que no era útil para nuestro
sistema, a su vez se ha intentado que no existiera información duplicada o redundante. El
sistema es completo en el sentido de que cubre todos los posibles puntos de falla a la hora
de configurar una política de seguridad en la herramienta si bien existen problemas que no
son del ámbito o no están cubiertos por el alcance de este sistema experto, en general podría
decirse que se ha cumplido con el alcance definido en el proyecto. Por último se ha analizado
la consistencia del sistema y se ha visto que en todos los casos en los que se han introducido
ciertos datos el resultado era siempre el mismo, es decir, no se da el caso en que los mismos
datos produzcan resultados diferentes.
5.1.5.2. Validación
Comparación con resultados conocidos En primer lugar se ha realizado una batería de
pruebas comparando las salidas obtenidas con los resultados que aparecen en la docu-
mentación y registros de incidencias aportados por la empresa Audisec y concretamente
por su director de sistemas. En la mayoría de los casos el resultado obtenido coincidía
con el resultado reflejado en la documentación de la empresa. En los casos en los cua-
les no hubo coincidencia se debía a errores que no estaban tipificados o situaciones
excepcionales que no se suelen reproducir y que carecen de consistencia.
Comparación frente a un experto Por último se plantearon algunos escenarios al experto,
en este caso el experto es el mismo del cual se ha extraído el conocimiento. En cada
uno de los escenarios se le pedía al experto que evaluará los “síntomas” que se presen-
taban y diese un diagnostico aproximado al fallo, incluso se han utilizado herramientas
de simulación de redes para hacer dichos casos más reales. En dichos escenarios los
resultados obtenidos han sido significativos ya que en algunos casos el sistema experto
encontraba la solución donde el propio experto no daba con ella.
71
5.2 Herramienta Web
En este apartado se van a explicar los principales productos resultantes de la fase de
análisis y diseño de los requisitos funcionales detectados.
Para el análisis, se van a realizar una serie de casos de uso, que representan la vista
funcional del sistema que se quiere desarrollar. Cada caso de uso representará un requisito
funcional del sistema, mostrándose mediante los diagramas las relaciones entre actores y las
interfaces del sistema o incluso interfaces externas al sistema.
En cuanto al diseño, se llevará a cabo mediante diagramas de secuencia de los casos de
uso más complejos. Estos muestran las iteraciones entre los objetos ordenadas en secuencia
temporal. Muestra los objetos que se encuentran en el escenario y la secuencia de mensajes
intercambiados entre los objetos para llevar a cabo la funcionalidad descrita por el escenario.
En primer lugar se muestra la tabla 6 donde se puede ver la planificación de los primeros
sprint del proyecto (se muestran 5 de los 8 sprint totales) y la separación de las tareas, cada
una de estas tareas tiene dos subtareas denominadas Análisis y Diseño donde se define la
tarea y se realiza la documentación asociada a la misma, como casos de uso, diagramas de
clases, etc.
Tarea Sprint Horas Descripción
Curso de DNIe Sprint 1 48 Terminar el curso de DNIe
Seguridad en ac-
ceso
Sprint 1 12 Análisis de las vulnerabilidades y amenazas a
las que se enfrentan los sistemas de autentica-
ción web. Soluciones para el proyecto e imple-
mentación de las mismas (dificultad/beneficio)
72
Creación de la
Plataforma
Sprint 2 16 Creación de la Estructura necesaria para comen-
zar el proyecto:
GIT
Dominios en desarrollo.
Esquema de base de datos.
Creación del sistema de carpetas.
Visualización Sprint2 18 Sería crear la plataforma para comenzar a aña-
dir funcionalidades.
Página Login(index.php)
Página Inicio
Página Mi Perfil
Página Administración
Creación del in-
dex y el login
Sprint 2 10 Crear la pagina para entrar a la herramienta y
toda la lógica para iniciar una sesión.
Formulario perfil
usuario
Sprint 2 8 Crear un formulario para que el usuario pueda
ver su perfil y pueda modificar su contraseña o
algunos de sus datos.
Elegir empresa Sprint2 12 Dar la posibilidad de elegir una empresa para
modificar sus datos.
73
Configuración de
Reglas de Cone-
xión
Sprint 3 12 Dentro del sistema de autenticación manual se
deben poder definir las siguientes reglas:
Complejidad.
Caducidad.
Cambio Automático de contraseña en la
primera conexión.
Envío automático de credenciales.
Autenticación
Manual
Sprint 3 6 Sistema de autenticación al uso. Simplemente
login y pw.
Autenticación
con DNIe
Sprint 3 16 Funcionalidad para poder logarse en la platafor-
ma con DNIe.
Plataforma para
crear usuario
Sprint 3 8 Sería la parte de Administración (opción usua-
rios) donde el administrador puede crear nuevos
usuarios y determinar su configuración perso-
nalizada (siempre cogiendo por defecto la con-
figuración general) pudiendo añadir nuevos per-
misos de seguridad (más caracteres a la contra-
seña, caducidad en menos tiempo, pw para el
dnie...).
Relacionar los
usuarios con las
políticas.
Sprint 4 6
Vista de usuarios
por grupos de po-
líticas
Sprint 4 6 Crear una tercera pestaña dentro de políticas de
seguridad donde se muestren los usuarios perte-
necientes a una política.
74
Autenticación
cogiendo datos
LDAP
Sprint 4 16 Sería el usuario y pw pero cogiendo los datos
del LDAP del cliente
Importar Usua-
rios
Sprint 4 16 Debe permitirse desde la opción de usuario la
importación de listados completos de usuario a
través de CSV
Diferencia entre
roles de Gauth y
empresa
Sprint 5 8 Diferencia entre roles de Gauth y Roles defini-
dos por una empresa, implementar todo lo ne-
cesario para realizar esta diferencia.
Configuración
avanzada del
LDAP
Sprint 5 8 Realizar un formulario para relacionar los cam-
pos que utiliza la herramienta con los posibles
atributos de las clases que se encuentran en el
LDAP
Opciones en im-
portar usuarios.
Sprint 5 8 Se debe permitir al usuario configurar algunas
opciones para la importación de usuarios, por
ejemplo sobrescribir los usuarios que existan,
no crear usuarios si ya existen, cambiar el nom-
bre automáticamente si ya existe el nombre del
usuario. etc...
Tabla 6: Planificación SCRUM
5.2.1 Análisis
A continuación, se muestra el diagrama de casos de uso de los requisitos funcionales de
la herramienta (ver figura 16). Para permitir una mejor visualización de los casos de uso
definidos, el sistema se ha dividido a su vez en varios subsistemas, que son Administración,
Inicio los cuales se tratarán en los siguientes apartados.
Como se puede observar, se han identificado tres actores principales: El usuario del siste-
ma, el administrador del sistema y la base de datos.
Cabe resaltar que el administrador realiza las mismas acciones que un usuario normal,
75
además de poder elegir la empresa a tratar de entre todos los creados en el sistema y poder
gestionar la seguridad de empresas y usuarios.
Sistema
Modulo inicio
Moduloadministración
Autenticación
BBDD
Administrador
Usuario
Figura 16: Diagrama de casos de uso general
En las imágenes que se muestran a continuación se pueden ver los casos de uso que
conforman el sistema. En la mayoría de estos diagramas se ha obviado al actor BBDD para
simplificar la visualización del caso de uso. Los diagramas de casos de uso generales se
realizaron en un primer momento para identificar casos de uso más específicos, en primer
lugar se muestra que que sprint fueron realizados.
Sprint 2
• Diagrama de casos de uso de Autenticación.
• Diagrama de casos de uso del módulo de inicio.
• Diagrama de casos de uso del módulo de administración.
Sprint 3
• Diagrama de casos de uso de gestión de usuarios.
• Diagrama de casos de uso de seguridad.
Sprint 4
• Diagrama de casos de uso de conexiones.
76
Modulo inicio
login bbdd
login Active Directory
login LDAP
Administrador
Usuario
<<Include>>
<<Include>>
<<Include>>
Figura 17: Diagrama de casos de uso de Autenticación
Cambiarempresa
Mi perfil
modificar perfil
cambiarcontraseña
Administrador
usuarioBBDD
<<Include>>
<<Include>>
Figura 18: Diagrama de casos de uso del módulo de inicio
77
evaluar/Configurar seguridadextension points
Definir reglas de seguridad
Configurar LDAP
Configurar ActiveDirectory
Definir Roles
Creación deusuarios
Importar usuarios
evaluar/Configurarseguridad
Administrador
Usuario
<<Extend>>
Figura 19: Diagrama de casos de uso del módulo de administración
78
Definir Roles
Creación deusuarios
Importar usuarios
Insertar rol
Eliminar rol
Modificar rol
Insertar usuario
Eliminar usuario
Modificar usuario
importar desdeLDAP
importar desdeActive Directory
importar desdeCSV
Administrador
Usuario
<<Include>>
<<Include>>
<<Include>>
<<Include>>
<<Include>>
<<Include>>
<<Include>>
<<Include>>
<<Include>>
Figura 20: Diagrama de casos de uso de gestión de usuarios
79
Configurar LDAP
Configurar ActiveDirectory
modificar conexión
comprobar conexión
insertar configuraciónavanzada
modificar conexión
comprobar conexión
insertar configuraciónavanzada
Administrador
Usuario
<<Include>>
<<Include>>
<<Include>>
<<Include>>
<<Include>>
<<Include>>
Figura 21: Diagrama de casos de uso de conexiones
evaluar/Configurar seguridadextension points
Definir reglas de seguridad
evaluar/Configurarseguridad
nueva politica
modificar politica
Administrador
Usuario
<<Include>>
<<Include>>
<<Extend>>
Figura 22: Diagrama de casos de uso de seguridad
A continuación se realizará una descripción textual de los casos de uso más significativos
dejando los que no aporten más información sin la descripción textual. Se indicaran las
principales funciones realizadas por el actor y junto con la descripción textual de los casos
80
de uso se detallarán las clases de análisis que intervienen en su ejecución.En primer lugar se
listan los sprint y los casos de uso realizados en cada uno de ellos.
Sprint 2
• Autenticación contra BBDD.
• Elegir Empresa.
• Mi perfil (modificar perfil).
Sprint 3
• Autenticación con DNIe.
• Insertar Usuario.
• Eliminar Usuario.
• Modificar Usuario.
Sprint 4
• Importar Usuario desde CSV.
• Modificar conexión LDAP.
• Comprobar conexión LDAP.
Sprint 5
• Insertar configuración LDAP avanzada.
Sprint 6
• Insertar Rol.
• Eliminar Rol.
• Importar Usuario desde LDAP/Active Directory.
5.2.1.1. Autenticación Este caso de uso consiste en el acceso a la herramienta para po-
der realizar el resto de acciones. Este caso de uso está formado por tres casos de uso más
particulares, se expondrán dos de los mismos.
81
Nombre: Autenticación contra BBDD
Abstracto: No
Precondiciones: –
Postcondiciones: –
Flujo normal:
1. El usuario introduce el login, la contraseña y el código de seguridad en una
ventana.
2. La ventana crea una sesión con el login y la contraseña.
3. La sesión comprueba que se han introducido los 3 campos.
4. La sesión valida sus parámetros con la base de datos a través del agente, que
son correctos.
5. Se añade la sesión a la lista de sesiones como correcta.
6. El usuario queda autenticado en el sistema.
7. La ventana muestra una nueva ventana con varias opciones.
Flujo alternativo 1:
1. El usuario introduce el login, la contraseña y el código de seguridad en una
ventana.
2. La ventana crea una sesión con el login y la contraseña.
3. La sesión comprueba que no se han introducido los 3 campos.
4. Se muestra un mensaje de error en la ventana del usuario.
82
Flujo alternativo 2:
1. El usuario introduce el login, la contraseña y el código de seguridad en una
ventana.
2. La ventana crea una sesión con el login y la contraseña.
3. La sesión comprueba que se han introducido los 3 campos.
4. La sesión valida sus parámetros con la base de datos a través del agente, que
son incorrectos.
5. Se muestra un mensaje de error en la ventana del usuario.
Descripción: Este caso de uso se ejecuta cuando un usuario desea conectarse al
sistema.
Tabla 7: Descripción textual del caso de uso de Autenticación contra BBDD
Ventana Agente
Controlador Sesión
Figura 23: Clases de análisis en el caso de uso de Autenticación contra BBDD
Nombre: Autenticación con DNIe
Abstracto: No
83
Precondiciones: Tener lector de tarjetas compatible con DNIe y el DNIe insertado
en el mismo.
Postcondiciones: –
Flujo normal:
1. El usuario pulsa sobre el botón “Usar DNIe”.
2. La ventana carga el formulario de autenticación con DNIe.
3. El usuario introduce su nombre de usuario y pulsa acceder.
4. Se obtienen los datos del DNIe.
5. La ventana crea una sesión con el login y los datos del DNIe.
6. La sesión comprueba que se han introducido los campos correctos.
7. La sesión valida sus parámetros con la base de datos a través del agente, que
son correctos.
8. Se añade la sesión a la lista de sesiones como correcta.
9. El usuario queda autenticado en el sistema.
10. La ventana muestra una nueva ventana con varias opciones.
84
Flujo alternativo 1:
1. El usuario pulsa sobre el botón “Usar DNIe”.
2. La ventana carga el formulario de autenticación con DNIe.
3. El usuario introduce su nombre de usuario y pulsa acceder.
4. Se obtienen los datos del DNIe.
5. La ventana crea una sesión con el login y los datos del DNIe.
6. La sesión comprueba que no se han introducido el campo login.
7. Se muestra un mensaje de error en la ventana del usuario.
Flujo alternativo 2:
1. El usuario pulsa sobre el botón “Usar DNIe”.
2. La ventana carga el formulario de autenticación con DNIe.
3. El usuario introduce su nombre de usuario y pulsa acceder.
4. Se obtienen los datos del DNIe.
5. La ventana crea una sesión con el login y los datos del DNIe.
6. La sesión comprueba que se han introducido los campos.
7. La sesión valida sus parámetros con la base de datos a través del agente, que
son incorrectos.
8. Se muestra un mensaje de error en la ventana del usuario.
Descripción: Este caso de uso se ejecuta cuando un usuario desea conectarse al
sistema utilizando su DNIe como clave de acceso.
Tabla 8: Descripción textual del caso de uso de Autenticación con DNIe
85
Ventana Agente
Controlador Sesión
Figura 24: Clases de análisis en el caso de uso de Autenticación con DNIe
5.2.1.2. Elegir Empresa Este caso de uso consiste en elegir de una tabla en la que se
muestran las empresas definidas en el sistema, para cargar todos los datos asociados la mis-
ma.
Nombre: Elegir Empresa
Abstracto: No
Precondiciones: El usuario deberá haberse autenticado y tener los permisos de ac-
ceso a esta área del sistema
Postcondiciones: Se cargará en el sistema todos los datos pertenecientes a la em-
presa seleccionada.
86
Flujo normal:
1. El usuario selecciona la opción de cambiar empresa.
2. La ventana muestra una tabla con las distintas empresas que están en el siste-
ma.
3. El usuario elige una empresa.
4. La ventana envía la petición del usuario al controlador.
5. El controlador comprueba la petición y la solicita al Agente.
6. El Agente realiza la consulta a la base de datos y devuelve los permisos aso-
ciados a la consulta.
7. La ventana muestra los datos de la empresa.
Descripción: Este caso de uso se ejecuta cuando el usuario desea comenzar o con-
tinuar la modificación de los datos de una empresa.
Tabla 9: Descripción textual del caso de uso elegir empresa
Ventana Agente Controlador
EmpresaUsuario
Figura 25: Clases de análisis en el caso de uso elegir empresa
87
5.2.1.3. Mi perfil (modificar perfil) Este caso de uso consiste en la modificación de los
datos del perfil del usuario con el que se ha ingresado en la herramienta.
Nombre: Mi perfil (modificar perfil)
Abstracto: No
Precondiciones: El usuario deberá haberse autenticado en el sistema.
Postcondiciones: –
Flujo normal:
1. El usuario selecciona en una ventana la visualización de su perfil de usuario.
2. Se muestra una ventana con los campos definidos para el usuario con los valo-
res actuales. El usuario los modifica y envía una petición de modificación de
los valores.
3. La ventana envía la petición al controlador del caso de uso, modifica el usuario,
al que se le asignan los valores tecleados por el usuario.
4. El controlador modifica el Usuario en la base de datos a través del Agente.
5. La ventana muestra la visualización del usuario modificado.
Descripción: Este caso de uso se ejecuta cuando el usuario desea modificar los
valores asociados a su usuario en el sistema.
Tabla 10: Descripción textual del caso de uso mi perfil (modificar perfil)
88
Ventana Agente
Controlador Usuario
Figura 26: Clases de análisis en el caso de uso Mi perfil (modificar perfil)
5.2.1.4. Definir Roles Este caso de uso consiste en la creación de un rol de empresa que
puede ser asignado posteriormente a un usuario de la empresa. Este caso de uso está formado
por tres casos de uso más particulares.
Nombre: Insertar Rol
Abstracto: No
Precondiciones: El administrador deberá haberse autenticado en el sistema.
Postcondiciones:
Flujo normal:
1. El administrador pulsa sobre el botón “Nuevo” en la ventana que muestra una
tabla con los roles.
2. La ventana envía la petición del administrador al controlador del caso de uso.
3. El controlador comprueba los datos y los envía al Agente que los introduce en
la base de datos.
4. La ventana muestra el formulario con los datos introducidos.
89
Descripción: Este caso de uso se ejecuta cuando el administrador desea crear un
rol asociado a la empresa.
Tabla 11: Descripción textual del caso de uso insertar rol
Ventana Agente
Controlador Rol
Figura 27: Clases de análisis en el caso de uso insertar rol
Nombre: Eliminar Rol
Abstracto: No
Precondiciones: El administrador deberá haberse autenticado en el sistema y debe
existir al menos un rol introducido con anterioridad.
Postcondiciones:
90
Flujo normal:
1. El administrador debe seleccionar un rol contenido en la tabla que se muestra
en la ventana de roles.
2. El administrador pulsa sobre el botón “Eliminar” en la ventana que muestra
una tabla con los roles.
3. La ventana envía la petición del administrador al controlador del caso de uso.
4. El controlador comprueba los datos y los envía al Agente que los elimina en la
base de datos.
5. La ventana muestra el formulario con los datos introducidos.
Descripción: Este caso de uso se ejecuta cuando el administrador desea eliminar
un rol asociado a la empresa.
Tabla 12: Descripción textual del caso de uso eliminar rol
Ventana Agente
Controlador Usuario
Figura 28: Clases de análisis en el caso de uso eliminar rol
91
5.2.1.5. Creación de Usuarios Este caso de uso consiste en la creación/eliminación/modificación
de usuarios. Este caso de uso está formado por tres casos de uso más particulares.
Nombre: Insertar Usuario
Abstracto: No
Precondiciones: El administrador deberá haberse autenticado en el sistema.
Postcondiciones:
Flujo normal:
1. El administrador pulsa sobre el botón “Nuevo” en la ventana que muestra una
tabla con los usuarios de la empresa seleccionada.
2. La ventana envía la petición del administrador al controlador del caso de uso.
3. El controlador comprueba los datos y los envía al Agente que los introduce en
la base de datos.
4. La ventana muestra el formulario con los datos introducidos.
Descripción: Este caso de uso se ejecuta cuando el administrador desea crear un
usuario asociado a la empresa.
Tabla 13: Descripción textual del caso de uso insertar usuario
92
Ventana Agente
Controlador Sesión
Figura 29: Clases de análisis en el caso de uso insertar usuario
Nombre: Eliminar Usuario
Abstracto: No
Precondiciones: El administrador deberá haberse autenticado en el sistema y debe
existir al menos un usuario introducido con anterioridad.
Postcondiciones:
Flujo normal:
1. El administrador debe seleccionar un usuario contenido en la tabla que se
muestra en la ventana de usuarios.
2. El administrador pulsa sobre el botón “Eliminar” en la ventana que muestra
una tabla con los usuarios.
3. La ventana envía la petición del administrador al controlador del caso de uso.
4. El controlador comprueba los datos y los envía al Agente que los elimina en la
base de datos.
5. La ventana muestra el formulario con los datos introducidos.
93
Descripción: Este caso de uso se ejecuta cuando el administrador desea eliminar
un usuario asociado a la empresa.
Tabla 14: Descripción textual del caso de uso eliminar usuario
Ventana Agente
Controlador Usuario
Figura 30: Clases de análisis en el caso de uso eliminar usuario
Nombre: Modificar Usuario
Abstracto: No
Precondiciones: El administrador deberá haberse autenticado en el sistema y debe
existir al menos un usuario introducido con anterioridad.
Postcondiciones:
94
Flujo normal:
1. El administrador debe seleccionar un usuario contenido en la tabla que se
muestra en la ventana de usuarios.
2. Se muestra una ventana con un formulario que contiene los datos del usuario,
y donde se puede modificar, consultar o eliminar la información necesaria.
3. El administrador realiza los cambios oportunos.
4. El administrador pulsa sobre el botón “Guardar” en la ventana.
5. La ventana envía la petición del administrador al controlador del caso de uso.
6. El controlador comprueba los datos y los envía al Agente que los inserta en la
base de datos.
7. La ventana muestra el formulario con los datos introducidos.
Descripción: Este caso de uso se ejecuta cuando el administrador desea modificar
los datos de un usuario asociado a la empresa.
Tabla 15: Descripción textual del caso de uso modificar usuario
95
Ventana Agente
Controlador Usuario
Figura 31: Clases de análisis en el caso de uso modificar usuario
5.2.1.6. Importar Usuarios Este caso de uso consiste en la obtención de usuarios desde
diferentes fuentes. Este caso de uso está formado por tres casos de uso más particulares.
Nombre: Importar Usuario desde CSV
Abstracto: No
Precondiciones: El administrador deberá haberse autenticado en el sistema.
Postcondiciones:
96
Flujo normal:
1. El administrador debe seleccionar el archivo desde donde se desea importar
los usuarios.
2. Se muestra una ventana con un formulario que contiene los datos de las cabe-
ceras de las columnas contenidas en el fichero.
3. El administrador realiza el mapeo oportuno entre los campos de base de datos
y los campos del fichero.
4. El administrador pulsa sobre el botón “Importar” en la ventana.
5. La ventana envía la petición del administrador al controlador del caso de uso.
6. El controlador comprueba los datos y los envía al Agente que los inserta en la
base de datos.
7. La ventana muestra el formulario con los datos introducidos.
Descripción: Este caso de uso se ejecuta cuando el administrador desea importar
usuarios desde un fichero CSV a la base de datos de la herramienta.
Tabla 16: Descripción textual del caso de uso importar usuario desde CSV
97
Ventana Agente
Controlador Sesión
Figura 32: Clases de análisis en el caso de uso importar usuario desde CSV
Nombre: Importar Usuario desde LDAP/Active Directory
Abstracto: No
Precondiciones: El administrador deberá haberse autenticado en el sistema y debe
existir una conexión LDAP/AD válida en el sistema.
Postcondiciones:
98
Flujo normal:
1. El administrador debe seleccionar el origen desde donde se desea importar los
usuarios.
2. La ventana envía la petición del administrador al controlador del caso de uso.
3. Se muestra una ventana con un formulario que contiene los datos de la base
de datos de la herramienta y los datos de los usuarios que se pueden importar
desde el origen seleccionado.
4. El administrador selecciona que usuarios desea importar o actualizar.
5. El administrador pulsa sobre el botón “Importar” en la ventana.
6. La ventana envía la petición del administrador al controlador del caso de uso.
7. El controlador comprueba los datos y los envía al Agente que inserta/modifica
los usuarios en la base de datos.
Descripción: Este caso de uso se ejecuta cuando el administrador desea importar
usuarios desde un sistema LDAP/AD a la base de datos de la herramienta.
Tabla 17: Descripción textual del caso de uso importar usuario desde LDAP/AD
99
Ventana Agente
Controlador UsuarioLDAP/AD
Figura 33: Clases de análisis en el caso de uso importar usuario desde LDAP/AD
5.2.1.7. Configurar LDAP Este caso de uso consiste en la configuración de las conexio-
nes a LDAP. Este caso de uso está formado por tres casos de uso más particulares.
Nombre: Modificar conexión LDAP
Abstracto: No
Precondiciones: El administrador deberá haberse autenticado en el sistema.
Postcondiciones:
Flujo normal:
1. El administrador modifica el formulario que muestra la configuración (vacía o
con datos) existente en la herramienta y que es mostrada por la ventana.
2. El administrador pulsa sobre el botón “Guardar” en la ventana.
3. La ventana envía la petición del administrador al controlador del caso de uso.
4. El controlador comprueba los datos, crea el objeto LDAP y lo envía al Agente
que lo inserta en la base de datos.
5. La ventana muestra el formulario con los datos introducidos.
100
Descripción: Este caso de uso se ejecuta cuando el administrador desea inser-
tar/modificar una conexión LDAP que será utilizada posteriormente para impor-
tar/actualizar usuarios.
Tabla 18: Descripción textual del caso de uso modificar conexión LDAP
Ventana Agente
Controlador LDAP
Figura 34: Clases de análisis en el caso de uso modificar conexión LDAP
Nombre: Comprobar conexión LDAP
Abstracto: No
Precondiciones: El administrador deberá haberse autenticado en el sistema y los
datos de conexión a LDAP debe estar introducidos en el formulario implementado
para ese fin.
Postcondiciones:
101
Flujo normal:
1. El administrador pulsa sobre el botón “comprobar conexión” que se encuentra
en la ventana de configuración de conexión LDAP.
2. La ventana envía la petición del administrador al controlador del caso de uso.
3. El controlador comprueba los datos, crea el objeto LDAP.
4. Con el objeto LDAP creado se abre una conexión al sistema que contiene el
LDAP configurado en el objeto.
5. El controlador recibe si la conexión en correcta y envía una respuesta a la
ventana.
6. La ventana muestra un mensaje indicando el estado de la conexión.
Descripción: Este caso de uso se ejecuta cuando el administrador desea verificar
una conexión LDAP.
Tabla 19: Descripción textual del caso de uso comprobar conexión LDAP
Ventana Agente
Controlador LDAP
Figura 35: Clases de análisis en el caso de uso comprobar conexión LDAP
102
Nombre: Insertar configuración LDAP avanzada
Abstracto: No
Precondiciones: El administrador deberá haberse autenticado en el sistema.
Postcondiciones:
Flujo normal:
1. El administrador debe acceder a la configuración avanzada de la conexión
LDAP.
2. El administrador modifica el formulario que muestra la configuración avanza-
da (vacía o con datos) existente en la herramienta y que es mostrada por la
ventana.
3. El administrador pulsa sobre el botón “Guardar” en la ventana.
4. La ventana envía la petición del administrador al controlador del caso de uso.
5. El controlador comprueba los datos, crea el objeto LDAP_Avanzado y lo envía
al Agente que lo inserta en la base de datos.
6. La ventana muestra el formulario con los datos introducidos.
Descripción: Este caso de uso se ejecuta cuando el administrador desea inser-
tar/modificar una configuración avanzada para una conexión LDAP que será utiliza-
da posteriormente para importar/actualizar usuarios. Esta conexión indica el mapeo
entre los campos de la herramienta y los campos del LDAP.
Tabla 20: Descripción textual del caso de uso insertar configuración LDAP avanzada
103
Ventana Agente
Controlador LDAP
Figura 36: Clases de análisis en el caso de uso insertar configuración LDAP avanzada
5.2.2 Diseño
En este apartado se especificarán mediante diagramas de secuencia los casos de uso que
por su entidad podrían ser los más importantes o complejos del sistema, a continuación se
muestra el listado de los diagramas de uso que se van a presentar ordenados por sprint.
Sprint 2
• Autenticación con usuario y contraseña.
• Elegir empresa.
Sprint 3
• Autenticación con DNIe.
• Añadir política de seguridad.
• Modificar política de seguridad.
Sprint 4
• Modificar conexión LDAP/AD.
• Comprobar conexión LDAP/AD.
104
5.2.2.1. Autenticación En la figura 37 se muestra el diagrama de secuencia para el caso
de uso de autenticación contra la base de datos de la propia herramienta.
presentaciónbrokersesióncontroladorventana delogin
usuario
12: mostrar opciones
6: comprobar datos
2: pulsar botón entrar
5: devuelve datos
3: petición datos
10: cargar datos sesión
7: crear sesión
3: envío de datos
1: introducir datos
Figura 37: Diagrama de secuencia para el caso de uso de autenticación
5.2.2.2. Autenticación con DNIe En la figura 38 se muestra el diagrama de secuencia
para el caso de uso de autenticación utilizando el DNIe.
presentaciónbrokersesióncontroladorapplet DNIeventana delogin
usuario
13: mostrar opciones
9: devuelve datos
8: petición datos
12: cargar datos...
11: crear sesión
10: comprobar datos
7: confirmación de datos
6: comprobar datos
5: Envío de datos
3: Mostrar autenticación DNIe
4: Introducir DNIe
2: cargarautenticación DNIe
1: Elegir login DNIe
Figura 38: Diagrama de secuencia para el caso de uso de autenticación con DNIe
5.2.2.3. Elegir empresa En la figura 39 se muestra el diagrama de secuencia para el caso
de uso elegir empresa.
105
controlador empresapresentación
usuario
broker
7: carga de la empresa
6: devolver objeto empresa
5: crear objeto empresa
4: devuelve datos empresa
3: obtener empresa2: seleccionar empresa
1: elegir empresa
Figura 39: Diagrama de secuencia para el caso de uso de elegir empresa
5.2.2.4. Modificar conexión En la figura 40 se muestra el diagrama de secuencia para el
caso de uso modificar conexión, este caso de uso esta realizado para conexiones LDAP pero
es totalmente válido para conexiones con Active Directory.
brokerLDAPcontroladorpresentación
Administrador
6: mensaje de confirmación
5: confirmación
4: guardar datos
3: modificar objeto2: modificar datos LDAP
1: pulsar guardar datos
Figura 40: Diagrama de secuencia para el caso de uso de modificar conexión LDAP/AD
5.2.2.5. Comprobar conexión En la figura 41 se muestra el diagrama de secuencia para
el caso de uso comprobar conexión, este caso de uso esta realizado para conexiones LDAP
pero es totalmente válido para conexiones con Active Directory.
106
brokerLDAPcontroladorpresentación
Administrador
5: confirmación
4: guardar datos
3: modificar objeto
6: mensaje de confirmación
2: modificar datos LDAP
1: pulsar comprobar conexión
Figura 41: Diagrama de secuencia para el caso de uso de comporbar conexión LDAP/AD
5.2.2.6. Añadir política En la figura 42 se muestra el diagrama de secuencia para el caso
de uso añadir política.
brokerpolítica deacceso
controladorpresentación
Administrador
5: guardar objeto6: añade una nueva política
4: devuelve objeto
3: crear objeto vacío
2: petición nuevo objeto1: crear política
Figura 42: Diagrama de secuencia para el caso de uso de añadir política de seguridad
5.2.2.7. Modificar política En la figura 43 se muestra el diagrama de secuencia para el
caso de uso modificar política de seguridad.
107
brokerpolítica deacceso
controladorpresentación
Administrador
13: mensaje de confirmación12: confirmación
11: guardar campos modificados
10: actualizar objeto
9: petición de modificación8: pulsar guardar datos
7: modificar datos política 6: guardar objeto
4: devuelve objeto
3: obtener objeto
5: cargar datos política
2: petición nuevo objeto1: seleccionar política
Figura 43: Diagrama de secuencia para el caso de uso de modificar política de seguridad
5.2.2.8. Clases de dominio En la figura 44 se muestra el diagrama que contiene parte de
las clases que conforman la lógica de dominio de la herramienta.
Empresa
Usuario
Grupo_AD
Politica_Seguridad
Conexion_AD
Rol
AD_Avanzado
Contacto
LDAP
LDAP_Avanzado
Rol_Definido
1
0..*
0..1 10..1
0..1
0..*
0..* 1
1
0..*
1
1
1
1
1
0..*
1
1
1
1
1
Figura 44: Diagrama de clases de dominio
Un aspecto a destacar, es la definición de las clases correspondientes al controlador (con-
trol) y el agente de base de datos (broker). Además de la clase lib_db que contiene las fun-
ciones de conexión, desconexión, ejecución de consultas y tratamiento de resultados, que
108
permite al broker abstraerse de esas tareas.
Se han definido dos clases abstractas, control y broker, con las funciones comunes a todos
los controladores y brokers de cada caso de uso. Estas funciones son, en caso del control,
funciones dedicadas a la conexión y desconexión, eliminando la instancia del broker creada
en su constructor, y en el caso del broker, funciones genéricas de operación con la base de
datos (insert, update, delete) que evitan tener que definirlas en cada broker específico.
Como se puede observar en la figura 45, se ha definido una clase control y otra broker
específico para cada caso de uso, las cuales heredan los atributos y funciones de las clases
abstractas.
#_init_broker
+control(conectividad : int)+getBroker() : broker+connect(conectividad : int) : void+disconnect() : void
control
+broker(conectividad : int)+getDb() : lib_db+setDb() : lib_db+insert(tabla : string, campos : string, valores : string) :...+update(tabla : string, set : string, condición : string) : int+delete(tabla : string, condición : string) : int
broker
0
1 lib_db0
1
control_inicio control_administracion broker_inicio broker_administracion... ...
Figura 45: Estructura de las clases control y broker
Con este diseño se han logrado diversas metas, como son el tener una alta cohesión ya que
las funciones definidas en cada control y broker específico de cada caso de uso solo llevan
a cabo acciones para cada funcionalidad, además de un acoplamiento reducido entre las
distintas clases. Todo ello facilita el mantenimiento del código y la reutilización de funciones.
5.2.2.9. Estructura de Base de Datos Por último en la figura 46 se muestra parte del
diagrama ER de base de datos que define la estructura utilizada para este proyecto, se he
intentado ser lo más fiel posible al patrón Una clase-Una tabla.
109
classes_attributes_ad
id INT(10)
class INT(10)
nombre VARCHAR(45)
descripcion TEXT
classes_attributes_ldap
id INT(10)
class INT(10)
nombre VARCHAR(45)
descripcion TEXT
configuracion_active_directory
id INT(11)
codigo_cliente INT(10)
name VARCHAR(100)
user VARCHAR(100)
pass VARCHAR(100)
host VARCHAR(100)
port INT(11)
name_domain VARCHAR(200)
use_ssl TINYINT(4)
sufix VARCHAR(200)
real_primary_group TINYINT(4)
avanzado INT(10)
configuracion_ad_avanzado
id INT(10)
login INT(10)
pass INT(10)
nombre INT(10)
apellidos INT(10)
rol INT(10)
cargo INT(10)
telefono INT(10)
email INT(10)
dni INT(10)
nombreg INT(10)
configuracion_ldap
id INT(10)
codigo_cliente INT(10)
dominio VARCHAR(45)
ip VARCHAR(100)
dn VARCHAR(255)
puerto VARCHAR(10)
usuario VARCHAR(45)
pass TEXT
usuarios VARCHAR(45)
grupos VARCHAR(45)
cifrado_pass VARCHAR(45)
avanzado INT(10)
configuracion_ldap_avanzado
id INT(10)
login INT(10)
pass INT(10)
nombre INT(10)
apellidos INT(10)
rol INT(10)
cargo INT(10)
telefono INT(10)
email INT(10)
dni INT(10)
nombreg INT(10)
empresas
id INT(10)
cif VARCHAR(16)
razon_social VARCHAR(512)
consultora INT(10)
persona_contacto VARCHAR(512)
telefono VARCHAR(64)
direccion VARCHAR(512)
poblacion VARCHAR(256)
provincia VARCHAR(256)
cp VARCHAR(16)
sedes VARCHAR(1024)
email VARCHAR(512)
web VARCHAR(512)
pais VARCHAR(256)
limiteUsuarios INT(10)
codigo_cliente INT(10)
tipo_cliente VARCHAR(45)
grupos_active_directory
id INT(11)
nombre VARCHAR(100)
identificador VARCHAR(100)
descripcion TEXT
conexion INT(11)
codigo_cliente INT(10)
object_classes_ldap
id INT(10)
nombre VARCHAR(45)
descripcion TEXT
politicas_acceso
id INT(10)
codigo_cliente INT(10)
nombre VARCHAR(45)
longitud INT(2)
letras TINYINT(3)
numeros TINYINT(3)
especiales TINYINT(3)
caducidad VARCHAR(45)
primera_sesion TINYINT(3)
envio_credenciales TINYINT(3)
clave_dni TINYINT(3)
defecto TINYINT(3)
roles_empresas
id INT(10)
nombre VARCHAR(45)
id_interno VARCHAR(45)
codigo_cliente INT(10)
nivel INT(10)
descripcion TEXT
1..*1..*1..*1..*1..*
0..10..10..10..10..1
1..*1..*1..*1..*1..*0..10..10..10..10..1
1..*1..*1..*1..*1..*0..10..10..10..10..1
1..*1..*1..*1..*1..*
11111
1..*1..*1..*1..*1..*
11111
1..*1..*1..*1..*1..*
11111
1..*1..*1..*1..*1..*
11111
1..*1..*1..*1..*1..*
11111
Figura 46: Estructura de Base de Datos
110
6 CONCLUSIONES Y PROPUESTAS
6.1 Conclusiones
Tras la finalización de este TFG cabe destacar una serie de aspectos. En primer lugar,
creemos que todos los objetivos marcados al inicio del mismo se han cumplido satisfactoria-
mente, en mayor o menor medida.
Estudio de las diferentes políticas de seguridad usadas por parte de las empresas. El re-
sumen de esta investigación se encuentra en el Anexo II-Tabla 23 donde pueden verse
las relaciones entre las políticas de seguridad usadas por parte de las empresas.
Estudio de los sistemas de autenticación que usan como principal herramienta el DNIe.
En el apartado 3 de este documento puede verse los ámbitos donde se está usado el
DNIe.
Estudio de los diferentes sistema, usados en empresas, para la gestión de usuarios Como
resultado de la investigación a lo largo de la realización del proyecto concluyó en que
los sistemas más usados son los basados en directorios, sus principales representantes
son LDAP y Active Directory. Estos sistemas son los que se ha optado por conectar en
la herramienta web.
Uso de un sistema experto para la evaluación de las políticas de seguridad. En el apar-
tado 5.1 de este documento se exponen los motivos y la implementación del sistema
experto incorporado a la herramienta web.
Desarrollo de un software que facilitará la gestión de usuarios y contraseñas. En el apar-
tado 5.2 de este documento se muestra la documentación generada en la implementa-
ción de la herramienta web. Además en el anexo VI se encuentra el manual de usuario
de dicha herramienta.
La elección de tecnología Web para desarrollar la herramienta ha aportado una serie de be-
neficios. Estas ventajas se listan a continuación:
Sencilla distribución de la herramienta a las organizaciones. Mediante un simple comu-
nicado compuesto por la URL de acceso junto a las credenciales del usuario es sufi-
ciente para que éste acceda a la herramienta.
Fácil utilización por parte de la organización. El software no precisa ningún requerimien-
to tecnológico especial, salvo una estación de trabajo con acceso a Internet.
Cómoda actualización del software. Si se desea incluir nuevas opciones en la herramienta,
no es necesario volver a distribuir el paquete software a las organizaciones ya que se
realiza la actualización de forma centralizada y transparente.
En cuanto a las funcionalidades que se identificaron como objetivo del proyecto, todas se
han conseguido desarrollar e incluir en la herramienta.
Entre todas las funcionalidades de desarrollo destaca la inclusión de un sistema experto
que permite configurar y evaluar la seguridad de acceso a la empresa. Esta evaluación se
sustenta sobre un motor de inferencia que ha sido desarrollado para este fin y que funciona
en un entorno web.
6.2 Líneas de futuro
La herramienta desarrollada permite una serie de ampliaciones que podrían ser útiles y
que permitirían una mayor potencia respecto a la funcionalidad actual.
En primer lugar podría desarrollarse un modulo para conectar directamente la herramienta
con el motor de inferencia que incluye CLIPS, de esta forma se conseguiría toda la potencia y
funcionalidad que ofrece CLIPS. Una vez conectado con CLIPS podría aumentarse el ámbito
de aplicación del sistema experto.
Creación de un formulario parametrizable para la creación automática de las políticas de
seguridad óptimas en función de las características de la empresa o sistema.
Por otro lado podría modificarse la herramienta para que funcionase como un módulo
independiente que pueda incluirse en diferentes herramientas que utilizan un entorno web.
Así mismo esta ampliación tendría como objetivo adicional que la herramienta se conectase
con diferentes bases de datos, en este momento está preparada para conectarse con MySQL o
MariaDB pero puede ser interesante permitir la conexión con bases de datos Oracle o incluso
112
sistemas No SQL.
Por último se podría ampliar el sistema experto o incluir uno diferente para ayudar con la
configuración de las conexiones, tanto a LDAP como a AD.
113
REFERENCIAS
[1] BOOCH, G., RUMBAUGH, J. Y JACOBSON, I., El Lenguaje Unificado de Modelado.
Addison Wesley, Madrid, 2006, ISBN: 84-7829-076-1.
[2] PIATTINI, M., et al. Tecnología y diseño de Bases de Datos. Ra-Ma, Madrid, 2006,
ISBN: 978-84-7897-733-3.
[3] RUMBAUGH, J, JACOBSON, I. Y BOOCH, G., El Lenguaje Unificado de Modelado.
Manual de Referencia. Addison Wesley, Madrid, 2007, ISBN: 978-84-7829-087-1.
[4] POLO, M., Apuntes de Ingeniería del Software II (temario de teoría). Universidad de
Castilla-La Mancha, Disponible en Internet: http://www.inf-cr.uclm.es/www/mpolo/.
[5] POLO, M., Manual de Ingeniería del Software II. Universidad de Castilla-La Mancha,
Disponible en Internet: http://www.inf-cr.uclm.es/www/mpolo/.
[6] JOSE ANGEL OLIVAS VARELA, Apuntes de la asignatura de Sistemas Basados en
el Conocimiento. Universidad de Castilla-La Mancha, 2012.
[7] E.RICH, KNIGHT., Inteligencia Artificial. Gustavo-Gili, 1995.
[8] STUART J. RUSSELL Y PETER NORVIG, Inteligencia Artificial, Un enfoque mo-
derno. Prentice Hall, 2o Edición, 2004.
[9] PETE DEEMER,BAS VODDE, GABRIELLE BENEFIELD, CRAIG LARMAN., The
SCRUM primer. www.ScrumTI.com.
[10] CHARLES P. PFLEEGER, SHARI LAWRENCE PFLEEGE, Security in Computing.
4th Edition.
[11] ROSS ANDERSON, Security Engineering. 2nd Edition.
[12] PALACIO, J., Flexibilidad con Scrum. Principios de diseño e implantación de campos
de Scrum. Disponible en http://www.navegapolis.net/content/view/694/.
[13] Documento An overview of Scrum. Disponible en
http://www.mountaingoatsoftware.com/.
115
[14] KNIBERG, H., Scrum y XP desde las trincheras. Disponible en
http://santimacnet.wordpress.com/category/metodologias-agiles/.
[15] SUTHERLAND, J., SCHWABER, K., The Scrum Papers: Nut, Bolts, and Origins of
an Agile Framework. Disponible en http://scrum.jeffsutherland.com/.
[16] Documentación asociada al curso “Curso de Desarrollo Ágil”. Disponible en
https://formacion-online.inteco.es.
[17] Documentación asociada al curso “Curso de Introducción al DNI electrónico”. Dis-
ponible en https://formacion-online.inteco.es.
[18] Documentación asociada al curso “Curso de Desarrollo y Certificación de aplicacio-
nes sobre DNI electrónico”. Disponible en https://formacion-online.inteco.es.
[19] MINISTERIO DEL INTERIOR, Guía de referencia básica sobre DNIe. Disponible en
http://www.dnielectronico.es/Guia_Basica/index.html.
[20] ANDI GUTMANS, STIG SAETHER BAKKEN, DERICK RETHANS, PHP5 Power
Programming. Prentice Hall, 2005.
[21] PAUL DUBOIS, MySQL. Addison Wesley, 2012
[22] JOSÉ MANUEL ALARCÓN AGUÍN, Fundamentos de JavaScript y AJAX para desa-
rrolladores y diseñadores web. Krasis Press, 2012
[23] ASOCIACIÓN NACIONAL DE EMPRESAS DE INTERNET, Manual de introduc-
ción a la seguridad en el ámbito empresarial. 2006
[24] GILLAM, L., Cloud Computing: Principles, Systems and Applications. Springer. 2010
[25] IDC, SaaS: aumenta la adopción, se dispara el conocimiento. Dispo-
nible resumen de prensa en http://www.saasmania.com/wordpress/wp-
content/uploads/2011/02/Resumen-prensa-SaaS-2011_portada.pdf
[26] OWASP, The Open Web Application Security Project. Disponible en
https://www.owasp.org/
[27] Historia de PHP. Disponible en http://www.php.net/manual/es/history.php.php
116
[28] SHU-HSIEN LIAO, Expert system methodologies and applications - a decade review
from 1995 to 2004. 2005.
[29] CRUZ ROBERTO, Área de Bases de Datos e Inteligencia Artificial. Disponible en
http://dcc.ing.puc.cl/investigacion/areas/bases_dat.html, 2005.
[30] BONSÓN ENRIQUE, Tecnologías Inteligentes para la Gestión. Rama, 3a edición,
2003.
[31] DGPGC, DNIe - Guía de referencia básica. Disponible en www.dnielectronico.es, v1.4,
2014.
117
ANEXOS
I MÉTODO PARA EL ESTUDIO DE LA VIABILIDAD
El estudio de viabilidad (Test de SLAGEL) se compone de tres etapas.
Definición de las características.
Asignación de los pesos.
Evaluación de cada aplicación candidata.
En la definición de las características se consideran cuatro dimensiones.
Plausibilidad.
Justificación.
Adecuación.
Éxito.
Sobre cada una de las dimensiones se establecen tres categorías.
Directivos y/o Usuarios.
Los expertos.
La tarea.
Para cada categoría se establecen las características mas importantes que definen esa dimen-
sión. La características pueden ser.
Esenciales, no deben tener un valor inferior a un umbral, normalmente fijado en 7, en
una escala de 1 a 10.
Deseables.
Lo primero que debe hacerse es asignar pesos, de 0 a 10, a cada una de las características,
estos pesos están definidos en función de la importancia relativa de la característica. Cada uno
118
de estos pesos es constante para evitar que se ajuste la evaluación a la aplicación. Teniendo
en cuenta las siguientes definiciones.
Leyenda Descripción Rango
P Peso de las características (fijo a priori) 0. . . 10
Ppi Peso de una característica de posibilidad Pp1. . . Pp10
Pji Peso de una característica de justificación Pj1. . . Pj7
Pai Peso de una característica de adecuación Pa1. . . Pa12
Pei Peso de una característica de éxito Pe1. . . Pe17
V Valor de las características (lo asignamos nosotros) 0. . . 10
Vpi Valor de una característica de posibilidad (plausibilidad) Vp1. . . Vp10
Vji Valor de una característica de justificación Vj1. . . Vj7
Vai Valor de una característica de adecuación Va1. . . Va12
Vei Valor de una característica de éxito Ve1. . . Ve17
VC Valor total de una aplicación candidata 0. . . 100
Vci Valor global de una aplicación en una dimensión (VC1,..) 0. . . 100
Vu Valor umbral de una aplicación (habitualmente consideramos 7) 0. . . 100
// División entera –
Una vez asignados los pesos se procede de la siguiente manera.
1. Asignación de un valor V de 0 (ausente) a 10 (totalmente presente) a cada característica.
Si el valor de una característica esencial no alcanza el umbral exigido, su cómputo es
cero y la aplicación queda rechazada.
2. Multiplicar cada valor de una característica por su correspondiente peso para obtener
los valores ponderados de las características. Este cálculo se efectuará para cada una de
las dimensiones en que se han establecido las características.
3. Multiplicar, para cada dimensión, estos valores ponderados de las características.
4. Para cada dimensión se calculará la raíz n-ésima del producto obtenido en el apartado
anterior, utilizando como índice de la raíz el valor máximo de los índices usados en
119
cada dimensión.
VC1 = ∏i=1,2,5
(V pi//Vui)(10
∏i=1
Ppi∗V pi)1/10
VC2 = ∏i=1,4,5,7
(V ji//Vui)(7
∏i=1
P ji∗V ji)1/7
VC3 = ∏i=4,7,9,10
(Vai//Vui)(12
∏i=1
Pai∗Vai)1/12
VC4 = ∏i=6,10,12,17
(Vei//Vui)(17
∏i=1
Pei∗Vei)1/17
5. Dividir la suma de los valores globales de cada aplicación candidata, en las cuatro
dimensiones, entre cuatro. Se obtendrá el valor total general de cada aplicación.
VC =
∣∣∣∣∣∣ ∑4i=1(VCi/4) si∏
4i=1VCi 6= 0
0 en otro caso
6. Por último se normaliza el valor obtenido, para esto procedemos con las siguiente regla
de tres.
Valor obtenido→ Valor máximo posible
Valor real (%)→ 100
7. Si el valor supera un mínimo aceptable daremos el estudio de viabilidad por satisfecho
y se procederá a la implementación del sistema.
120
II TABLAS DE CORRESPONDENCIA VARIABLE/NIVEL DE SEGU-
RIDAD
Una vez realizada la investigación sobre las topologías de las diferentes empresas en relación
al campo de la seguridad y después de las diferentes entrevistas con los expertos para adquirir
el conocimiento necesario, se han obtenido los datos suficientes como para implementar el
sistema experto.
A continuación, a modo de resumen, se puede ver de forma esquemática algunas de las
decisiones tomadas en la implementación, para hacer mas fácil la lectura de estos datos se
ha optado por dividir las diferentes características que afectan a la seguridad de una empresa
en niveles, de 1 a 6, aplicándose el menor número cuando el aspecto analizado no incide de
forma importante a la seguridad. De esta forma, una vez asignados los niveles, se pueden
combinar los diferentes aspectos y obtener un nivel que defina a dichos aspectos. Además se
asignan pesos a los aspectos para evitar que muchas características de perfil bajo sumadas a
una de perfil alto deje al sistema desprotegido.
A cada uno de los niveles se le asigna una configuración de seguridad por defecto y es
el sistema experto el que evalúa si la política actual se aproxima al nivel ideal fijado con
anterioridad.
Se recuerda que en este apartado se esquematiza de forma muy resumida como se proce-
de, siendo las reglas que aplica el sistema experto más complejas y precisas.
Relación entre seguridad y característica de la empresa
Característica Nivel Peso Rebaja el nivel
Otro tipo de autenticación con política 1 0.25 Sí
Tipo de datos sensibles 6 1 No
Red interna 3 0.5 No
Red externa 5 1 No
Límite de intentos con bloqueo de usuario 2 0.5 Sí
Existe Captcha 3 0.25 Sí
La contraseña se envía por correo 4 0.5 No
121
Conexión segura ssl 3 0.5 Sí
Acceso por parte de no clientes 6 1 No
Varios usuarios con una misma contraseña 5 1 No
Existen logs de cambios(registro de usuarios
que realizan cambios)
3 0.25 Sí
Tabla 21: Nivel de seguridad/Características
Relación de los niveles de seguridad y las medidas a tomar
1 2 3 4 5 6
No mínimo de caracteres 6 6 6 8 8 >8
Letras obligatorias X X X X X
Números obligatorios X X X X X
Caracteres especiales obligatorios X X X
Caducidad X X
Cambio al iniciar primera sesión X X X X
Generador de tokens X
Tabla 22: Nivel seguridad/Medidas
122
III DOCUMENTOS ADQUISICIÓN DE CONOCIMIENTO
Fecha:
Hora:
Lugar:
Asistentes:
Conocimiento anterior a la entrevista Síntesis del conocimiento obtenido en las entrevis-
tas anteriores.
Objetivos de la entrevista El objetivo que se pretende alcanzar con la entrevista.
Fuentes de conocimiento Personas de las cuales se obtienen el conocimiento o lo que es lo
mismo las personas que van a ser entrevistadas.
Modo Entrevista estructurada o Entrevista parcialmente estructurada. para identificación de
dichos errores.
Planteamiento de la sesión En este apartado se muestran las preguntas que se desean reali-
zar para obtener el conocimiento.
Resultado de la sesión Aquí se transcriben las respuestas obtenidas a las preguntas del plan-
teamiento de la sesión.
Plan de análisis Pasos a realizar para analizar.
Resultado del análisis Resultado final de la entrevista.
A continuación se muestran algunas entrevistas realizadas a partir del formato anterior.
Entrevista 1 (inicial)
Fecha: 13/01/2014
Hora: 11:00
123
Lugar: Oficinas Audisec S.L. , Ciudad Real
Asistentes: Enrique Mozos (Experto), Rafael Díaz (Experto), Ángel Durán
Conocimiento anterior a la entrevista
El punto de partida de la entrevista es la identificación de los elementos relacionados
con la problemática que se aborda. Lista de elementos:
Características de las empresas.
Aspectos de seguridad.
Controles de seguridad.
Objetivos de la entrevista
Completar conocimiento sobre el dominio.
Identificar las diferentes formas en las que una empresa puede gestionar la seguri-
dad.
Obtener los elementos que afectan a las políticas de seguridad de una empresa.
Fuentes de conocimiento
Se ha elegido a los responsables de sistemas por su conocimiento sobre el dominio
y por que son los encargados de llevar a cabo la implementación de los sistemas que
vamos a analizar. Debido a sus conocimientos nos permitirá completar la información
sobre el dominio e identificar los problemas surgidos a la hora de establecer políticas
de seguridad.
Modo
Entrevista parcialmente estructurada, se pretende adquirir conocimiento sobre el domi-
nio pero no se tiene la base suficiente como para guiar la entrevista, se intentará cumplir
los objetivos fijados al principio y que permitirán que las siguientes entrevistas puedan
ser entrevistas estructuradas aunque después contengan partes parcialmente estructura-
das.
Planteamiento de la sesión
124
1. Respecto a la seguridad, ¿Cual es la principal característica a tener en cuenta en
una herramienta a la hora de la seguridad?
2. ¿Existen sistemas adicionales de seguridad antes de la propia seguridad de una
herramienta?
3. ¿Los datos que se manejan afectan a la seguridad?
4. ¿Los tipos de usuario a los que va dirigida la herramienta afectan a la seguridad?
5. ¿Qué elementos adicionales de seguridad, que no pertenezcan a la propia política,
pueden verse en la actualidad?
6. ¿Cuales son los mecanismos por los cuales se comunica un nuevo acceso a un
usuario?
7. ¿Existe la posibilidad de tener registros de cambios por parte de un usuario?
Resultado de la sesión
1. Un aspecto muy importante a tener en cuenta es si la herramienta que se está utili-
zando es una herramienta situada en una red interna.
2. En algunas empresas cada uno de los empleados debe autenticarse contra un do-
minio antes de acceder a su puesto de trabajo, una vez dentro cada una de las
herramientas pueden tener sistemas de autenticación adicionales.
3. Este aspecto también es crítico, no es lo mismo un sistema que trata con datos
públicos que un sistema que trata con datos privados, por ejemplo, según la agencia
de protección de datos los datos relacionados con la salud son de nivel alto y por
lo tanto deben tratarse con especial cuidado, tratándolos con medidas de seguridad
adicionales.
4. No tiene porque afectar directamente a la seguridad aunque es cierto que no es lo
mismo que el que accede a la información sea el dueño de la misma a que sea un
tercero.
5. Hay diferentes herramientas que se pueden utilizar, entre las más utilizadas tene-
mos.
125
SSL.
CAPTCHAS.
Limitar el número de intentos de acceso.
6. Normalmente se suele utilizar el correo electrónico para comunicar a un empleado
o usuario sus claves de acceso.
7. Algunas herramientas disponen de cierta trazabilidad, pudiendo saber quien ha
realizado cambios en un determinado registro.
Plan de análisis
(a) Identificar términos.
(b) Identificar aspectos de seguridad.
(c) Completar glosario.
Resultado del análisis
Términos
Captcha.
SSL.
Herramienta interna.
Nivel de datos.
Red interna.
Aspecto seguridad
Conexión segura.
Herramienta en red interna.
Tipos de usuarios.
Autenticación anterior.
Sistemas adicionales de seguridad.
Envío de datos por correo.
126
Limite de intentos de acceso.
Varios usuarios con una misma contraseña.
Entrevista 2
Fecha: 21/01/2014
Hora: 11:45
Lugar: Oficinas Audisec S.L. , Ciudad Real
Asistentes: Rafael Díaz (Experto), Ángel Durán
Conocimiento anterior a la entrevista
Hasta el momento se han identificado los diferentes aspectos que afectan a la seguridad
de una herramienta y por lo tanto de una empresa.
Objetivos de la entrevista
Completar conocimiento sobre el dominio.
Identificar las políticas aplicables a la seguridad de una empresa.
Fuentes de conocimiento
En esta entrevista se ha elegido únicamente al responsable de la configuración de las
políticas de seguridad de su empresa. Rafael Díaz es el director de sistemas de la empre-
sa Audisec por lo tanto es el encargado y responsable de este tipo de sistemas teniendo
los conocimientos necesarios para resolver las dudas que se plantean.
Modo
Entrevista estructurada, respecto a la obtención del conocimiento sobre las carac-
terísticas de de empresa que afectan a la seguridad.
Entrevista parcialmente estructurada, obtención de información sobre las políticas
aplicables a la seguridad de las herramientas de una empresa.
127
Planteamiento de la sesión
1. ¿Cómo se puede configurar un política de seguridad?
2. ¿Que aspecto referentes a contraseñas son las más críticas?
3. El envío de credenciales por mail puede ser peligroso, ¿qué medidas pueden to-
marse para aumentar la seguridad?
4. ¿Dentro de las contraseñas que herramientas dan mayor seguridad?
5. ¿Que criterios de caducidad pueden aplicarse?
Resultado de la sesión
1. La política de seguridad afecta a varias partes de un sistema, no se basa simple-
mente en configurar una contraseña. Pero en el caso que nos ocupa existen varios
sistemas para configurar una contraseña como puede ser un LDAP o un AD. Estas
herramientas de autenticación se usan de forma general para acceder a equipos o
puestos de trabajo.
2. Centrándonos en las contraseñas las configuraciones o aspectos que son sensibles
de configuración son:
Longitud de la contraseña.
Obligación de meter letras.
Obligar a que contenga números.
Obligar a que contenga algún carácter especial ($,&,etc. . . ).
No utilizar datos personales en la contraseña.
3. En nuestros sistemas para evitar que una contraseña que se ha enviado por correo
pueda ser utilizada por otra persona, bien sea por que ha podido acceder a dicho
correo o por que se haya dado a conocer el contenido de dicho correo por equivo-
cación, se obliga a todos los usuarios que modifiquen la contraseña en el primer
acceso.
128
4. Existe un tipo especial de contraseña denominada tokens, este sistema se basa en
una llave especial que genera contraseñas cada minuto siendo dicha contraseña
válida para ese intervalo de tiempo, se suele utilizar para sistemas muy críticos en
los cuales usuarios externos deben acceder a una herramienta.
5. En general depende de la empresa, una buena práctica es obligar a modificar la
contraseña una vez al mes.
Plan de análisis
(a) Identificar términos.
(b) Identificar configuraciones de políticas de seguridad.
(c) Completar glosario.
Resultado del análisis
Términos
LDAP.
AD.
Tokens.
Aspecto seguridad
Número mínimo de caracteres.
Obligar a meter letras, números y/o caracteres especiales.
Obligar a cambiar contraseña en la primera autenticación.
Caducidad obligada pero en intervalos de tiempo no definidos.
129
IV REGLAS DEL SISTEMA EXPERTO
Lista de reglas definidas para la implementación del sistema experto.
(defrule regla_1
(sin_politica)
=>
(assert(proponer))
)
(defrule regla_2
(con_politica)
=>
(assert(evaluar))
)
(defrule regla_3
(longitud_minima)
=>
(assert(nivel1)))
(defrule regla_4
(not(longitud_minima))
=>
(assert(nivel0))
(defrule regla_5
(longitud_minima)
(mayusculas)
(numeros)
=>
130
(assert(nivel2)))
(defrule regla_6
(longitud_minima)
(mayusculas)
(numeros)
(cambio_obligado)
=>
(assert(nivel3)))
(defrule regla_7
(longitud_minima)
(longitud_mayor_8)
(mayusculas)
(numeros)
(especiales)
(cambio_obligado)
=>
(assert(nivel4)))
(defrule regla_8
(longitud_minima)
(longitud_mayor_8)
(mayusculas)
(numeros)
(especiales)
(cambio_obligado)
(caducidad)
=>
(assert(nivel5)))
131
(defrule regla_9
(longitud_minima)
(longitud_mayor_8)
(mayusculas)
(numeros)
(especiales)
(cambio_obligado)
(caducidad)
(tokens)
=>
(assert(nivel6)))
(defrule regla_10
(con_politica)
(nivel1)
(nivelh1)
(finalh)
(evaluar)
=>
(printout t " La politica de seguridad es adecuada " crlf))
(defrule regla_11
(con_politica)
(nivel2)
(nivelh2)
(finalh)
(evaluar)
=>
(printout t " La politica de seguridad es adecuada " crlf))
132
(defrule regla_12
(con_politica)
(nivel3)
(nivelh3)
(finalh)
(evaluar)
=>
(printout t " La politica de seguridad es adecuada " crlf))
(defrule regla_13
(con_politica)
(nivel4)
(nivelh4)
(finalh)
(evaluar)
=>
(printout t " La politica de seguridad es adecuada " crlf))
(defrule regla_14
(con_politica)
(nivel5)
(nivelh5)
(finalh)
(evaluar)
=>
(printout t " La politica de seguridad es adecuada " crlf))
(defrule regla_15
(con_politica)
133
(nivel6)
(nivelh6)
(finalh)
(evaluar)
=>
(printout t " La politica de seguridad es adecuada " crlf))
(defrule regla_16
(con_politica)
(nivel1)
(not(nivelh1))
(finalh)
(evaluar)
=>
(printout t " La politica de seguridad NO es adecuada " crlf))
(defrule regla_17
(con_politica)
(nivel2)
(not(nivelh2))
(finalh)
(evaluar)
=>
(printout t " La politica de seguridad NO es adecuada " crlf))
(defrule regla_18
(con_politica)
(nivel3)
(not(nivelh3))
(finalh)
134
(evaluar)
=>
(printout t " La politica de seguridad NO es adecuada " crlf))
(defrule regla_19
(con_politica)
(nivel4)
(not(nivelh4))
(finalh)
(evaluar)
=>
(printout t " La politica de seguridad NO es adecuada " crlf))
(defrule regla_20
(con_politica)
(nivel5)
(not(nivelh5))
(finalh)
(evaluar)
=>
(printout t " La politica de seguridad NO es adecuada " crlf))
(defrule regla_21
(con_politica)
(nivel6)
(not(nivelh6))
(finalh)
(evaluar)
=>
(printout t " La politica de seguridad NO es adecuada " crlf))
135
(defrule regla_22
(nivelh1)
(proponer)
(finalh)
=>
(assert(proponer_nivel1)))
(defrule regla_23
(nivelh2)
(proponer)
(finalh)
=>
(assert(proponer_nivel2)))
(defrule regla_24
(nivelh3)
(proponer)
(finalh)
=>
(assert(proponer_nivel3)))
(defrule regla_25
(nivelh4)
(proponer)
(finalh)
=>
(assert(proponer_nivel4)))
(defrule regla_26
136
(nivelh5)
(proponer)
(finalh)
=>
(assert(proponer_nivel5)))
(defrule regla_27
(nivelh6)
(proponer)
(finalh)
=>
(assert(proponer_nivel6)))
(defrule regla_28
(datos_sensibles)
=>
(assert(nivelh6))
(assert(finalh)))
(defrule regla_29
(no_clientes)
=>
(assert(nivelh6))
(assert(finalh)))
(defrule regla_30
(not(no_clientes))
=>
(assert(finalh)))
137
(defrule regla_31
(pass_comun)
=>
(assert(nivelh5)))
(defrule regla_32
(nivelh1)
=>
(retract(nivelh2))
(retract(nivelh3))
(retract(nivelh4))
(retract(nivelh5))
(retract(nivelh6)))
(defrule regla_33
(nivelh2)
=>
(retract(nivelh1))
(retract(nivelh3))
(retract(nivelh4))
(retract(nivelh5))
(retract(nivelh6)))
(defrule regla_34
(nivelh3)
=>
(retract(nivelh1))
(retract(nivelh2))
(retract(nivelh4))
(retract(nivelh5))
138
(retract(nivelh6)))
(defrule regla_35
(nivelh4)
=>
(retract(nivelh1))
(retract(nivelh2))
(retract(nivelh3))
(retract(nivelh5))
(retract(nivelh6)))
(defrule regla_36
(nivelh5)
=>
(retract(nivelh1))
(retract(nivelh2))
(retract(nivelh3))
(retract(nivelh4))
(retract(nivelh6)))
(defrule regla_37
(nivelh5)
=>
(retract(nivelh1))
(retract(nivelh2))
(retract(nivelh3))
(retract(nivelh4))
(retract(nivelh5)))
(defrule regla_38
139
(autenticacion_adicional)
=>
(assert(nivelh1)))
(defrule regla_39
(limite_intentos)
=>
(assert(nivelh2)))
(defrule regla_40
(captcha)
=>
(assert(nivelh3)))
(defrule regla_41
(ssl)
=>
(assert(nivelh3)))
(defrule regla_42
(logs)
=>
(assert(nivelh3)))
(defrule regla_43
(red_interna)
(not(autenticacion_adicional))
=>
(assert(nivelh3)))
140
(defrule regla_44
(red_interna)
(autenticacion_adicional)
=>
(assert(nivelh2)))
(defrule regla_45
(envio_automatico)
(not(autenticacion_adicional))
=>
(assert(nivelh4)))
(defrule regla_46
(envio_automatico)
(autenticacion_adicional)
=>
(assert(nivelh3)))
(defrule regla_47
(not(ssl))
(not(red_interna))
=>
(assert(nivelh5)))
(defrule regla_48
(not(red_interna))
(ssl)
=>
(assert(nivelh4)))
141
(defrule regla_49
(pass_comun)
=>
(assert(nivelh5)))
(defrule regla_50
(nivel1)
=>
(retract(nivel2))
(retract(nivel3))
(retract(nivel4))
(retract(nivel5))
(retract(nivel6)))
(defrule regla_51
(nivel2)
=>
(retract(nivel1))
(retract(nivel3))
(retract(nivel4))
(retract(nivel5))
(retract(nivel6)))
(defrule regla_52
(nivel3)
=>
(retract(nivel1))
(retract(nivel2))
(retract(nivel4))
(retract(nivel5))
142
(retract(nivel6)))
(defrule regla_53
(nivel4)
=>
(retract(nivel1))
(retract(nivel2))
(retract(nivel3))
(retract(nivel5))
(retract(nivel6)))
(defrule regla_54
(nivel5)
=>
(retract(nivel1))
(retract(nivel2))
(retract(nivel3))
(retract(nivel4))
(retract(nivel6)))
(defrule regla_55
(nivel6)
=>
(retract(nivel1))
(retract(nivel2))
(retract(nivel3))
(retract(nivel4))
(retract(nivel5)))
143
V ACRÓNIMOS
A
ACID. Atomicity, Consistency, Isolation and Durability.
AD. Active Directory.
AJAX. Asynchronous JavaScript And XML.
API. Application Programming Interface.
B
BBDD. Bases de Datos
BH. Base de Hechos.
BR. Base de Reglas.
C
CAPTCHA. Prueba de Turing completamente automática y pública para diferenciar
computadoras de humanos
CLIPS. C Language Integrated Production System.
COBIT. Control Objectives for Information and Related Technology.
CSS. Cascading Style Sheets.
CSV. Comma-Separated Values.
D
DNI. Documento Nacional de Identidad.
DNIe. Documento Nacional de Identidad electrónico.
DOM Document Object Model.
E
ER. Entity–relationship model.
F
144
FTP. File Transfer Protocol.
G
GPL. General Public License.
H
HTML. HyperText Markup Language.
HTTP. HyperText Transfer Protocol.
HTTPS. HyperText Transfer Protocol Secure.
I
IA. Inteligencia Artificial.
IaaS. Infraestructure as a Service.
IDE. Entorno Integrado de Desarrollo.
J
JSON. JavaScript Object Notation.
L
LDAP. Lightweight Directory Access Protocol.
M
MT. Memoria de Trabajo.
P
PaaS. Platform as a Service.
TFG. Trabajo Fin de Grado.
PHP. PHP Hypertext Pre-processor.
POO. Programación Orientada a Objetos.
S
145
SaaS. Software as a Service
SE Sistema Experto.
SGBD. Sistema de Gestión de Bases de Datos.
SS.BC. Sistemas Basados en el Conocimiento.
SSL. Secure Socket Layer.
T
TIC. Tecnologías de la Información y la Comunicación.
U
UML. Lenguaje Unificado de Modelado.
URL. Localizador Uniforme de Recursos.
X
XML. eXtensible Markup Language.
146
VI MANUAL DE USUARIO
Descripción de la herramienta
Se trata de una aplicación pensada para gestionar las políticas de seguridad de una empre-
sa. Estas políticas de seguridad pueden ser definidas y evaluadas a través de la herramienta
web.
Inicio
Pestaña inicial donde se elige la empresa con la que se quiere trabajar y se permite la
modificación de los datos del propio usuario.
Acceso a la plataforma
El acceso a la herramienta se realiza mediante un navegador web, introducciones la url
donde se ha montado el servicio en la barra de navegación. En la siguiente figura se muestra
el formulario de acceso.
Para acceder a la plataforma hay dos posibilidades:
147
Usuario y contraseña, se debe introducir un usuario y contraseña validos en las casi-
llas correspondientes, estos usuarios pueden autenticarse contra LDAP, AD o la propia
BBDD de la herramienta.
DNIe, utilizando un lector de DNIe puede realizarse la autenticación.
Cambiar empresa
Para empezar a trabajar, por defecto, se selecciona la empresa del usuario que accede. A
través de esta opción se realiza la elección del cliente con el que se quiere trabajar. Para ello,
en primer lugar aparece un formulario que nos permite: o bien introducir unas opciones de
filtrado o mostrar la tabla completa.
Si bien introducimos algún dato para poder filtrar y pinchamos en el botón “Buscar” o le
damos al botón “Mostrar todos”, se mostrará la siguiente imagen.
Mi perfil
Al acceder a la opción Mi perfil de la pestaña Inicio se encuentra en la parte derecha un
formulario que permite cambiar tanto el nombre de usuario como la contraseña del usuario
autenticado.
148
Para cambiar el nombre de usuario hay que introducir el nuevo nombre en el campo Nom-
bre de Usuario y acto seguido pulsar sobre el botón "Guardar". Para cambiar la contraseña
del usuario se debe introducir la contraseña dos veces en cada uno de los campos de texto
destinados a tal efecto y después pulsar sobre el botón "Guardar". Si la contraseña introduci-
da coincide en ambos cuadros de texto, la contraseña es modificada; sino, se informa de que
no ha sido posible el cambio de contraseña.
Administración
Pestaña donde se permite administrar las políticas de seguridad permitiendo:
Definir reglas.
Configurar LDAP para la empresa.
Configurar Active Directory.
Definir roles de usuario.
Crear usuarios.
Importar usuarios.
Evaluar las políticas de seguridad.
149
Definir reglas
En esta opción se realiza la definición de las reglas o políticas de seguridad, cuando se
accede puede verse que la opción se divide en tres pestañas, cada una de ellas se detalla a
continuación.
Reglas por defecto
En esta pestaña se muestra el formulario donde se define la política de seguridad por defecto,
esto quiere decir que cualquier usuario que sea creado en un principio tendrá está regla
asociada.
Reglas personalizadas
En esta pestaña se muestra una tabla con las diferentes políticas que han sido definidas para
la empresa, estas políticas se podrán asociar posteriormente a cada uno de los usuarios.
150
Para añadir una nueva política se debe pulsar sobre el botón “Nuevo”, al hacerlo aparece
una nueva fila en la tabla, los campos de esta regla se modifican directamente sobre la tabla.
Para eliminar una regla simplemente hay que seleccionarla y posteriormente pulsar sobre el
botón “Eliminar”.
Usuario/Política
En esta pestaña se muestra una tabla con los usuarios que pertenecen a una determinada
política, es decir, los usuarios que tienen asociada una regla.
Para ver dicha lista hay que seleccionar una política en el selector que aparece sobre
la tabla, al seleccionar la regla se cargan automáticamente todos los usuarios que la tienen
asociada
151
Configurar LDAP
En esta opción se permite configurar una conexión a un sistema LDAP introduciendo los
parámetros necesarios. También debe introducirse el nodo donde se encuentra los usuarios,
los grupos y la codificación que se utiliza para el cifrado de las contraseñas.
Una vez introducidos los datos de la conexión puede comprobarse dicha conexión pulsan-
do sobre el botón “Comprobar conexión”, si la conexión se realiza correctamente se devuelve
un mensaje de confirmación, en caso contrario se indica el error.
Configuración avanzada
Esta opción, a la cual se accede pulsando sobre el botón “Configuración avanzada” que
aparece en la parte superior del formulario, permite realizar un mapeo entre los atributos del
objeto que se trae del LDAP y los campo de usuario que se tienen en la herramienta.
152
Configurar Active Directory
En esta opción se permite configurar una conexión a un sistema AD introduciendo los
datos necesarios para dicha conexión. De forma adicional pueden definirse los grupos del
AD.
Una vez introducidos los datos de la conexión puede comprobarse pulsando sobre el botón
“Comprobar conexión”, si la conexión se realiza correctamente se devuelve un mensaje de
confirmación, en caso contrario se indica el error.
Configuración avanzada
Esta opción, a la cual se accede pulsando sobre el botón “Configuración avanzada” que
aparece en la parte superior del formulario, permite realizar un mapeo entre los atributos del
objeto que se trae del AD y los campo de usuario que se tienen en la herramienta.
153
Definir roles
En esta opción se pueden gestionar (crear/modificar/eliminar) los roles de los usuarios,
estos roles se definen a nivel de empresa y no tienen nada que ver con los roles de usuario
de la herramienta, es decir, no afectan al usuario de la herramienta sino que afecta a las
responsabilidades del usuario dentro de la empresa.
Para añadir un nuevo rol se debe pulsar sobre el botón “Nuevo”, insertando de esta forma
una nueva fila en la tabla, una vez insertada pude modificarse cada campo directamente en
la tabla. Si se desea eliminar un registro, se debe seleccionar y seguidamente pulsar sobre el
botón “Eliminar”.
154
Creación de usuarios
En esta opción se gestionan los usuarios de la empresa, al acceder se muestra una tabla
con todos los usuarios.
Para añadir un nuevo usuario se debe pulsar sobre el botón “Nuevo”, insertando de esta
forma una nueva fila en la tabla. Si se desea eliminar un usuario, se debe seleccionar y
seguidamente pulsar sobre el botón “Eliminar”. Para modificar los datos de un usuario se
debe pulsar sobre el nombre del mismo mostrándose un formulario con los datos que puede
ser modificado.
En este formulario se pude asociar al usuario un rol de empresa y una política de seguridad
definida anteriormente. Además se muestra el tipo de autenticación del mismo (LDAP, AD,
155
usuario/contraseña, etc).
Importar usuarios
En esta opción se permite la importación de usuarios, los sistemas desde los cuales se
puede hacer dicha importación son:
CSV
LDAP
Active Directory
Para comenzar con el procese se debe seleccionar la fuente, si se seleccionar CSV se da
la posibilidad de subir un archivo de ese tipo y realizar el mapeo entre BBDD y las columnas
contenidas en el CSV. En caso de elegirse LDAP o AD la herramienta se conecta con el
sistema configurado y obtiene la lista de todos lo usuarios. Una vez cargados los usuarios se
muestra una vista de comparación entre lo que existe en BBDD y lo que hay en el sistema
externo. Finalmente se da la posibilidad de configurar la importación, eligiendo si se desea
importar las modificaciones, los usuarios nuevos o todo.
Evaluar seguridad
En esta opción se va realizando un cuestionario para evaluar el nivel de seguridad necesa-
rio para la empresa y el nivel de la política se seguridad que se aplica, dependiendo del caso
se obtendrá una respuesta sobre si el nivel es adecuado o se propondrá dicho nivel para las
características definidas.
156
157
