UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA GRADO EN INGENIERÍA EN INFORMÁTICA TRABAJO FIN DE GRADO

Transcripción

1 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

2

3 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 Izquierdo Director: David García Rosado Septiembre, 2014

4

5 TRIBUNAL: Presidente: Vocal: Secretario: FECHA DE DEFENSA: CALIFICACIÓN: PRESIDENTE VOCAL SECRETARIO Fdo.: Fdo.: Fdo.: I

6 II

7 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 correspondientes 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 mantenimiento 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 diferentes 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 subsistemas para dar soporte a cualquier tipo de empresa. III

8 IV

9 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

10 VI

11 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

12 VIII

13 ÍNDICE 1. INTRODUCCIÓN Estructura del documento OBJETIVOS DEL TFG 7 3. ANTECEDENTES, ESTADO DE LA CUESTIÓN Sistema experto Evolución histórica Características y arquitectura de los Sistemas Expertos Tipos de sistemas Basados en el Conocimiento Campos de Aplicación Ventajas y desventajas de los Sistemas Expertos Motor de Inferencia Herramienta Web Cloud Computing Seguridad Tecnologías MÉTODO DE TRABAJO Sistema experto Características del sistema experto Estudio de viabilidad Adquisición del conocimiento Implantación Evaluación y pruebas Motor de inferencia Herramienta Web Metodología SCRUM Ciclo de vida SCRUM IX

14 Validación Fases dentro del desarrollo RESULTADOS Sistema experto Características del sistema experto Estudio de viabilidad Adquisición del conocimiento Implantación Hechos posibles Reglas Evaluación y pruebas Verificación Validación Herramienta Web Análisis Autenticación Elegir Empresa Mi perfil (modificar perfil) Definir Roles Creación de Usuarios Importar Usuarios Configurar LDAP Diseño Autenticación Autenticación con DNIe Elegir empresa Modificar conexión Comprobar conexión Añadir política Modificar política X

15 Clases de dominio Estructura de Base de Datos CONCLUSIONES Y PROPUESTAS Conclusiones Líneas de futuro 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

16 ÍNDICE DE FIGURAS 1. Ciencias que intervienen en la inteligencia artificial Arquitectura de un sistema experto Encadenamiento hacia delante Ciclo base del motor de inferencia Clasificación Cloud Computing Conocimiento y adopción del SaaS Beneficios del SaaS Secuencia PHP Tecnologías que conformas AJAX Modelo clásico frente a Ajax Flujo de creación y mantenimiento de un sistema experto Etapas del proceso de adquisición del Conocimiento Cliclo SCRUM Diagrama de casos de uso genérico Diagrama de secuencia genérico Diagrama de casos de uso general 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 Diagrama de casos de uso de gestión de usuarios Diagrama de casos de uso de conexiones Diagrama de casos de uso de seguridad Clases de análisis en el caso de uso de Autenticación contra BBDD Clases de análisis en el caso de uso de Autenticación con DNIe Clases de análisis en el caso de uso elegir empresa Clases de análisis en el caso de uso Mi perfil (modificar perfil) Clases de análisis en el caso de uso insertar rol Clases de análisis en el caso de uso eliminar rol XII

17 29. Clases de análisis en el caso de uso insertar usuario Clases de análisis en el caso de uso eliminar usuario Clases de análisis en el caso de uso modificar usuario Clases de análisis en el caso de uso importar usuario desde CSV Clases de análisis en el caso de uso importar usuario desde LDAP/AD Clases de análisis en el caso de uso modificar conexión LDAP Clases de análisis en el caso de uso comprobar conexión LDAP Clases de análisis en el caso de uso insertar configuración LDAP avanzada Diagrama de secuencia para el caso de uso de autenticación Diagrama de secuencia para el caso de uso de autenticación con DNIe Diagrama de secuencia para el caso de uso de elegir empresa Diagrama de secuencia para el caso de uso de modificar conexión LDAP/AD Diagrama de secuencia para el caso de uso de comporbar conexión LDAP/AD Diagrama de secuencia para el caso de uso de añadir política de seguridad Diagrama de secuencia para el caso de uso de modificar política de seguridad Diagrama de clases de dominio Estructura de las clases control y broker Estructura de Base de Datos ÍNDICE DE TABLAS 1. Características de posibilidad Características de Justificación Características de Adecuación Características de Éxito Resultados del estudio de viabilidad Planificación SCRUM Descripción textual del caso de uso de Autenticación contra BBDD Descripción textual del caso de uso de Autenticación con DNIe Descripción textual del caso de uso elegir empresa Descripción textual del caso de uso mi perfil (modificar perfil) XIII

18 11. Descripción textual del caso de uso insertar rol Descripción textual del caso de uso eliminar rol Descripción textual del caso de uso insertar usuario Descripción textual del caso de uso eliminar usuario Descripción textual del caso de uso modificar usuario Descripción textual del caso de uso importar usuario desde CSV Descripción textual del caso de uso importar usuario desde LDAP/AD Descripción textual del caso de uso modificar conexión LDAP Descripción textual del caso de uso comprobar conexión LDAP Descripción textual del caso de uso insertar configuración LDAP avanzada Nivel de seguridad/características Nivel seguridad/medidas XIV

19 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 dentro 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 directorios (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 consolidar 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 administradores 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

20 LDAP son numerosas y están aumentando en cantidad y calidad. El proyecto está motivado por la necesidad de conectar desarrollos software a los sistemas 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 seguir 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 Direcció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 equivalente 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 personales, 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 segura 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

21 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 accedan 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 conocimiento 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 características le permiten almacenar datos y conocimiento, sacar conclusiones lógicas, tomar decisiones, aprender de la experiencia y los datos existentes, comunicarse con expertos humanos, 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 especializado. 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

22 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 exponiendo 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, mostrando 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 herramienta. Se indican a su vez, las principales líneas de trabajo futuro. 4

23 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

24

25 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 adecuado 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. Relacionado 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 diferentes 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

26 Estudio de los diferentes sistema existentes para el almacenamiento de usuarios y contraseñ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 utilizar 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 autenticación en el caso del sistema propio. 8

27 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 varias 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 diferentes 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

28 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. Matemáticas Otras Ciencias Ingeniería Del Conocimiento Robótica Demostración Automática De teoremas Ciencia cognoscitiva Psicología Inteligencia artificial Programación Heurística Programación Informática Figura 1: Ciencias que intervienen en la inteligencia artificial 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 proposicional 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

29 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 Inteligencia 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 procesamiento 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 : 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. Estaba escrito en Lisp. Su principal función consistía en el diagnóstico de enfermedades 11

30 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 experto 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 utilizar 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 permanecen hasta hoy (Shells) como EMYCIN, EXPERT, OPSS. 1981: Kazuhiro Fuchi anuncia el proyecto japonés de la quinta generación de computadoras, 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

31 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 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 condiciones de aplicación. 13

32 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 largo 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 resolució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 encadena, 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 Base de Hechos Motor de Inferencias Interfaz de Usuario Base de 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

33 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 consultas 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 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

34 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 formada 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 probabilidades 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 reglas 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 conocimiento. Naturaleza del problema Teniendo en el punto de mira la naturaleza de la tarea a realizar o el problema a solucionar 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

35 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 capacidad 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 aquellos 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 decisiones. 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 confirmados, conocimientos incierto (reglas no siempre validas), Terminología ambigua. 17

36 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, razonamiento 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 procedimentales. 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 anteriormente 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

37 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 pueden 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 clasificar 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 concretas, formación de opinión, emisión del informe, auditoría interna, auditoría informá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 contables. 19

38 Análisis de estados financieros: Salud financiera de la empresa, análisis del patrimonio, 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 considerablemente, 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

39 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 competitiva 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écnicas 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 terceros. 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. Partiendo 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 efectividad 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

40 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 establecidos. 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

41 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 simulació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 aeronaves 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 tener 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, diagnosticar 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

42 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 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 campos, lo que hace difícil que puedan aparecer nuevos especialistas humanos. Sin embargo 24

43 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 Expertos no son capaces. Un experto humano es capaz de adaptarse a los cambios que se producen en un determinado 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 sistema. Existe la dificultad de manipular información no estructurada, incompleta, inconsistente o errónea 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 implementació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 Apache, que implementa la conexión con CLIPS pero esta librería es del 2004 y actualmente 25

44 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 utilizará en la implementación del motor de inferencia. El funcionamiento del encadenamiento hacia delante se detalla a continuación. A partir de la BH 1 se intenta deducir una BH n en la que se cumple la consulta. Ejecutando sucesivamente las reglas R i de la Base de reglas. Cada ejecución de una regla caracteriza un ciclo de razonamiento CC k. BH1 BH2 BHn 1 BHn R1 R2... Rm CC1 CC2 CCn 1 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 inferencia se divide en 4 partes: Detección de reglas aplicables, Selección de una regla aplicable, 26

45 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 de reglas aplicables Elección de reglas Aplicación Actualizar base de hechos Figura 4: Ciclo base del motor de inferencia Detección de reglas aplicables. Se selecciona un conjunto de reglas candidatas para ser ejecutadas, estas reglas deben ser compatibles con la Base de Hechos actual. Este paso proporciona 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

46 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 terminació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

47 3.2 Herramienta Web Cloud Computing Introducción La computación en nube [24] o cloud computing es un modelo que proporciona servicios 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 proveedor 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 mantenimiento 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. Algunas 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 internet. Los datos críticos del negocio se almacenan fuera de las instalaciones de la empresa, lo que provoca una alta vulnerabilidad a la sustracción de información. 29

48 Enabling Technologies Clasificación Aunque el término cloud computing se aplica a multitud de servicios ofrecidos en internet, habitualmente estos se clasifican en tres tipos (ver figura 5): Web Services SaaS PaaS IaaS Cloud Infraestructure Managers Web Services VIM VMM VMs MapReduce DFS Hardware Technologies Figura 5: Clasificación Cloud Computing [24] Infraestructure as a Service (IaaS): La infraestructura como servicio proporciona mediante acceso web capacidad de almacenamiento y cómputo, normalmente mediante plataformas de virtualización. El usuario no necesita gestionar la infraestructura 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

49 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 distribució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 informació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

50 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 100% 85% de las anteriores lo utilizan Un 95% seguirán utilizando SaaS 68% 65% 46% 85% 95% 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

51 No preocuparse por las actualizaciones Rapidez y abaratamiento de la implantación Poder pagar por uso/si comprar licencia Menor inversión inicial Ahorro en servidor de aplicaciones Ahorro en personal y formación especial Acceder en cualquier momento y lugar Cuaota mensual/anual Añadir o elminar usuarios con facilidad Incrementar la efectividad de la seguridad Figura 7: Beneficios del SaaS [25] Entre todos, cabe señalar la importancia de abstraerse de las actualizaciones del software, 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 organizació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 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, confidencialidad 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

52 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 invasor 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. Esta 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 informació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 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 Language), 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

53 Servidor Solicita una página al servidor Es una página PHP La página HTML se envía al cliente HTML La página se ejecuta para convertirse en código HTM PHP Figura 8: Secuencia PHP Fue creado por Rasmus Lerdoff en 1994 como un conjunto de scripts en Perl y posteriormente 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 PHP4 fue liberado en 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

54 mente funcional aunque no se encuentra en su versión estable. Las principales caracterí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 programació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 multiusuario. Se basa en el estándar de bases de datos relacionales ANSI SQL (Structured Query Language), desplegado originariamente por IBM en 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

55 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 compilació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 primera vez en el producto de Netscape llamado Nestcape Navigator

56 AJAX AJAX [22] es un acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono 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íncrona. 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 desencadenan 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

57 crea una buena sensación al usuario. Cuando se realizan peticiones continuas al servidor, 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, evitando 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. Navegador del cliente Interfaz del usuario Navegador del cliente Interfaz del usuario Llamada Javascript Datos HTML+CSS Motor Ajax Transporte http(s) Datos HTML+CSS Petición HTTP Transporte http(s) Datos XML Servidor web Servidor web/xml BBDD, backend, sistemas heredados Servidor Modelo clásico BBDD, backend, sistemas heredados Servidor Modelo Ajax Figura 10: Modelo clásico frente a Ajax [22] 39

58 Normalmente el envío de información del servidor al cliente como respuesta de la petició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 Microsystems 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 herramientas 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 compilació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 bibliotecas de clases de Java fueron desarrolladas por Sun Microsystems en 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 implementaciones 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

59 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 Modelado. 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 documentos HTML, manejar eventos y desarrollar animaciones. Soporta el uso de extensiones 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 construcció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 entorno web. Blowfish: Librería para Javascript que implementa el método blowfish de cifrado de datos. 41

60 DNIe El Documento Nacional de Identidad electrónico (DNI electrónico) emitido por la Direcció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 personales, 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 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 comunicació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, sustituyendo 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

61 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 implementar un sistema experto. En la figura 11 se muestra el ciclo general de creación y mantenimiento 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

62 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 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 problema 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 ingeniero. 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 acuerdo 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 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

63 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 estimación. El método del Test de SLAGEL se define en el Anexo I 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 ejemplo, libros, conferencias, Internet, etc.) Deducción de conocimientos a partir de los expertos. 45

64 PERSPECTIVAS FASES DEL PROCESO Qué del entorno Deducción Entorno Extracción Usuarios 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 conocimiento. 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 inteligencia 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 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

65 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 haciendo, 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 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 especialista. 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 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

66 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 activaciones 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 activaciones 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 determinar 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

67 4.2 Herramienta Web A lo largo de este capítulo se detallará el proceso seguido para desarrollar la herramienta de autenticación 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 Incremento, 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

68 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 funcionamiento 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 requisitos 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ándose 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 implantació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

69 Definición de roles El personal implicado en el desarrollo de la herramienta se divide en dos grupos: Cerdos 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

70 Seguimiento de sprint: Es una reunión diaria con una duración máxima de 15 minutos 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, principalmente debido a problemas de disponibilidad del Scrum Master (el director del proyecto), 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 modificaciones 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 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

71 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 funcionalidades 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ísticas 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. Tambié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 propiedades y el comportamiento de las clases a las que pertenecen. 53

72 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 negocio 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 comprobar 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 tuvieron 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 aceptació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 están incorporando nuevas funcionalidades no previstas en un principio, así como mejoras en las existentes, a petición de los usuarios del sistema. 54

73 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, además esta empresa desarrolla proyectos software para clientes donde también se han incluido dichas funcionalidades de autenticación 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 problema 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 diagrama 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

74 Caso de uso 1 <<Include>> Caso de uso general <<Include>> Caso de uso 2 Actor 1 <<Include>> Caso de uso 3 Actor 2 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 importante 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 realizar 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 1 Objeto 2 Objeto 3 Objeto 4 Actor 1: Acción 2: Acción 3: Acción 6: Acción 4: Acción 5: Acción Figura 15: Diagrama de secuencia genérico 56

75 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 Características del sistema experto El sistema experto que se desea implementar evalúa unos parámetros de entrada compuestos 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 seguridad, 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 introduciendo 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.

76 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 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, despué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. Categoría Peso Valor Característica Tipo EX P Existen expertos. E EX P 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 D métodos pero no categoriza. TA P Existen suficientes casos de prueba; normales, típicos, ejemplares, correosos, etc. E 58

77 TA P La tarea está bien estructurada y se D entiende. TA P Sólo requiere habilidad cognoscitiva. D TA P8 9 8 No precisan resultados verdaderamente D comprometidos con el pro- yecto. TA P9 9 8 La tarea no requiere sentido común. D DU P Los directivos están verdaderamente 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 conocimientos 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

78 Características de Justificación Categoría Id. Categoría Peso Valor Característica Tipo EX J El experto NO está disponible. E EX J Hay escasez de experiencia humana. D TA J3 8 8 Existe necesidad de experiencia simultanea D en muchos lugares. TA J Necesidad de experiencia en entornos E hostiles, penosos, y/o poco gra- tificantes. TA J5 8 8 No existen soluciones alternativas. E DU J6 7 7 Se espera una alta tasa de recuperación D de la inversión. 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

79 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. Categoría Peso Valor Característica Tipo EX A1 5 7 La experiencia del experto está poco D organizada. 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 D es de conocimiento intensivo, tanto propio del dominio, como de manipulación de la información. TA A6 6 9 Es de tamaño manejable, y/o es posible D un enfoque gradual y/o, una descomposición en subtareas independientes. EX A7 7 9 La transferencia de experiencia entre E humanos es factible. TA A8 6 8 Estaba identificada como un problema D en el área y los efectos de la in- troducción de un SE pueden planificarse. TA A9 9 9 No requiere respuestas en tiempo real Inmediato. E 61

80 TA A La tarea no requiere investigación E básica y usa, si alguna, poca generación y entendimiento del lenguaje natural. TA A El experto usa básicamente razonamiento D simbólico que implica fac- tores subjetivos. TA A 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 recorrido 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 desmotivando 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

81 Características de Éxito Categoría Id. Categoría Peso Valor Característica Tipo EX E1 8 9 No se sienten amenazados por el proyecto,son capaces de sentirse intelectualmente unidos al proyecto EX E2 6 8 Tienen un brillante historial en la realización de esta tarea. EX E3 5 7 Hay acuerdos en lo que constituye una buena solución a la tarea. EX E4 5 9 La única justificación para dar un paso en la solución es la calidad de la solución final. EX E5 6 9 No hay un plazo de finalización estricto, ni ningún otro proyecto depende de esta tarea. TA E No está influenciada por vaivenes políticos. TA E7 8 7 Existen ya SS.EE. que resuelvan esa o parecidas tareas. TA E8 8 8 Hay cambios mínimos en los procedimientos habituales. TA E9 5 9 Las soluciones son explicables o interactivas. TA E La tarea es de I+D de carácter práctico, pero no ambas cosas simultáneamente. D D D D D E D D D E 63

82 DU E Están mentalizados y tienen expectativas realistas tanto en el alcance como en las limitaciones. DU E No rechazan de plano esta tecnología. DU E El sistema interactúa inteligente y amistosamente con el usuario usuario. DU E El sistema es capaz de explicar al usuario su razonamiento. DU E La inserción del sistema se efectúa sin traumas; es decir, apenas se interfiere en la rutina cotidiana de la empresa. DU E Están comprometidos durante toda la duración del proyecto, incluso después de su implantación. DU E Se efectúa una adecuada transferencia tecnológica. D E D D D D 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

83 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 evaluació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 siguiendo 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 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

84 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 seguridad 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 diferentes entrevistas que se realizaron 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

85 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 variables (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 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

86 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 electró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 usuario. 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

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

88 (cambio_obligado) => (assert(nivel4))) Esta regla acepta como hechos de entrada características de la contraseña y da como resultado un nivel de seguridad, es decir, si en la memoria de trabajo se tienen los hechos longitud_minima, longitud_mayor_8, mayusculas, numeros, especiales, cambio_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 Evaluación y pruebas El proceso de evaluación de un sistema experto puede dividirse en dos fases: verificació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

89 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 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 documentació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 cuales 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 presentaban 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

90 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 acceso las que se enfrentan los sistemas de autentica- Sprint 1 12 Análisis de las vulnerabilidades y amenazas a ción web. Soluciones para el proyecto e implementación de las mismas (dificultad/beneficio) 72

91 Creación de la Plataforma Sprint 2 16 Creación de la Estructura necesaria para comenzar 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ñadir funcionalidades. Página Login(index.php) Página Inicio Página Mi Perfil Página Administración Creación del index 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

92 Configuración de Reglas de Conexió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 Autenticación con DNIe Plataforma para crear usuario Relacionar los usuarios con las políticas. Vista de usuarios por grupos de políticas Sprint 3 6 Sistema de autenticación al uso. Simplemente login y pw. Sprint 3 16 Funcionalidad para poder logarse en la plataforma con DNIe. Sprint 3 8 Sería la parte de Administración (opción usuarios) donde el administrador puede crear nuevos usuarios y determinar su configuración personalizada (siempre cogiendo por defecto la configuración general) pudiendo añadir nuevos permisos de seguridad (más caracteres a la contraseña, caducidad en menos tiempo, pw para el dnie...). Sprint 4 6 Sprint 4 6 Crear una tercera pestaña dentro de políticas de seguridad donde se muestren los usuarios pertenecientes a una política. 74

93 Autenticación cogiendo datos LDAP Importar Usuarios Diferencia entre roles de Gauth y empresa Configuración avanzada del LDAP Opciones en importar usuarios. Sprint 4 16 Sería el usuario y pw pero cogiendo los datos del LDAP del cliente Sprint 4 16 Debe permitirse desde la opción de usuario la importación de listados completos de usuario a través de CSV Sprint 5 8 Diferencia entre roles de Gauth y Roles definidos por una empresa, implementar todo lo necesario para realizar esta diferencia. Sprint 5 8 Realizar un formulario para relacionar los campos que utiliza la herramienta con los posibles atributos de las clases que se encuentran en el LDAP 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 nombre automáticamente si ya existe el nombre del usuario. etc... Tabla 6: Planificación SCRUM 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 sistema, el administrador del sistema y la base de datos. Cabe resaltar que el administrador realiza las mismas acciones que un usuario normal, 75

94 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 Autenticación Usuario Modulo inicio BBDD Modulo administración Administrador 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

95 login bbdd <<Include>> Modulo inicio <<Include>> login Active Directory Usuario <<Include>> login LDAP Administrador Figura 17: Diagrama de casos de uso de Autenticación Cambiar empresa usuario Mi perfil <<Include>> modificar perfil BBDD <<Include>> cambiar contraseña Administrador Figura 18: Diagrama de casos de uso del módulo de inicio 77

96 Definir reglas de seguridad extension points evaluar/configurar seguridad Configurar LDAP Usuario Configurar Active Directory Administrador Definir Roles <<Extend>> Creación de usuarios Importar usuarios evaluar/configurar seguridad Figura 19: Diagrama de casos de uso del módulo de administración 78

97 <<Include>> Insertar rol Definir Roles <<Include>> Eliminar rol Usuario <<Include>> Modificar rol <<Include>> Insertar usuario Creación de usuarios <<Include>> Eliminar usuario Administrador <<Include>> Modificar usuario <<Include>> importar desde LDAP Importar usuarios <<Include>> importar desde Active Directory <<Include>> importar desde CSV Figura 20: Diagrama de casos de uso de gestión de usuarios 79

98 modificar conexión <<Include>> Configurar LDAP <<Include>> comprobar conexión Usuario <<Include>> insertar configuración avanzada Administrador <<Include>> modificar conexión Configurar Active Directory <<Include>> comprobar conexión <<Include>> insertar configuración avanzada Figura 21: Diagrama de casos de uso de conexiones Usuario Definir reglas de seguridad extension points evaluar/configurar seguridad <<Include>> <<Include>> nueva politica modificar politica Administrador <<Extend>> evaluar/configurar seguridad 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

99 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 Autenticación Este caso de uso consiste en el acceso a la herramienta para poder 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

100 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

101 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

102 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

103 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

104 Ventana Agente Controlador Sesión Figura 24: Clases de análisis en el caso de uso de Autenticación con DNIe 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 misma. Nombre: Elegir Empresa Abstracto: No Precondiciones: El usuario deberá haberse autenticado y tener los permisos de acceso a esta área del sistema Postcondiciones: Se cargará en el sistema todos los datos pertenecientes a la empresa seleccionada. 86

105 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 sistema. 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 asociados 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 continuar la modificación de los datos de una empresa. Tabla 9: Descripción textual del caso de uso elegir empresa Ventana Agente Controlador Usuario Empresa Figura 25: Clases de análisis en el caso de uso elegir empresa 87

106 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 valores 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

107 Ventana Agente Controlador Usuario Figura 26: Clases de análisis en el caso de uso Mi perfil (modificar perfil) 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

108 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

109 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

110 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

111 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

112 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

113 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

114 Ventana Agente Controlador Usuario Figura 31: Clases de análisis en el caso de uso modificar usuario 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

115 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 cabeceras 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

116 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

117 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

118 Ventana Agente Controlador LDAP/AD Usuario Figura 33: Clases de análisis en el caso de uso importar usuario desde LDAP/AD Configurar LDAP Este caso de uso consiste en la configuración de las conexiones 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

119 Descripción: Este caso de uso se ejecuta cuando el administrador desea insertar/modificar una conexión LDAP que será utilizada posteriormente para importar/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

120 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

121 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 avanzada (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 insertar/modificar una configuración avanzada para una conexión LDAP que será utilizada 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

122 Ventana Agente Controlador LDAP Figura 36: Clases de análisis en el caso de uso insertar configuración LDAP avanzada 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

123 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. ventana de login controlador sesión broker presentación usuario 1: introducir datos 2: pulsar botón entrar 3: envío de datos 3: petición datos 5: devuelve datos 6: comprobar datos 7: crear sesión 10: cargar datos sesión 12: mostrar opciones Figura 37: Diagrama de secuencia para el caso de uso de autenticación 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. ventana de applet DNIe controlador sesión broker presentación login usuario 1: Elegir login DNIe 3: Mostrar autenticación DNIe 2: cargar autenticación DNIe 4: Introducir DNIe 5: Envío de datos 6: comprobar datos 7: confirmación de datos 8: petición datos 9: devuelve datos 10: comprobar datos 11: crear sesión 12: cargar datos... 13: mostrar opciones Figura 38: Diagrama de secuencia para el caso de uso de autenticación con DNIe Elegir empresa En la figura 39 se muestra el diagrama de secuencia para el caso de uso elegir empresa. 105

124 presentación controlador empresa broker usuario 1: elegir empresa 2: seleccionar empresa 3: obtener empresa 4: devuelve datos empresa 5: crear objeto empresa 6: devolver objeto empresa 7: carga de la empresa Figura 39: Diagrama de secuencia para el caso de uso de elegir empresa 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. presentación controlador LDAP broker Administrador 1: pulsar guardar datos 2: modificar datos LDAP 3: modificar objeto 4: guardar datos 6: mensaje de confirmación 5: confirmación Figura 40: Diagrama de secuencia para el caso de uso de modificar conexión LDAP/AD 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

125 presentación controlador LDAP broker Administrador 1: pulsar comprobar conexión 2: modificar datos LDAP 3: modificar objeto 4: guardar datos 6: mensaje de confirmación 5: confirmación Figura 41: Diagrama de secuencia para el caso de uso de comporbar conexión LDAP/AD Añadir política En la figura 42 se muestra el diagrama de secuencia para el caso de uso añadir política. Administrador 1: crear política presentación 2: petición nuevo objeto controlador 3: crear objeto vacío política de acceso broker 6: añade una nueva política 4: devuelve objeto 5: guardar objeto Figura 42: Diagrama de secuencia para el caso de uso de añadir política de seguridad Modificar política En la figura 43 se muestra el diagrama de secuencia para el caso de uso modificar política de seguridad. 107

126 presentación controlador política de acceso broker Administrador 1: seleccionar política 2: petición nuevo objeto 3: obtener objeto 4: devuelve objeto 5: cargar datos política 7: modificar datos política 6: guardar objeto 8: pulsar guardar datos 9: petición de modificación 10: actualizar objeto 13: mensaje de confirmación 11: guardar campos modificados 12: confirmación Figura 43: Diagrama de secuencia para el caso de uso de modificar política de seguridad 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. Contacto 0..1 Usuario Rol 0..* * Grupo_AD 1 0..* 1 1 Empresa 1 Conexion_AD 1 Politica_Seguridad 0..* AD_Avanzado 1 LDAP 0..* Rol_Definido 1 1 LDAP_Avanzado Figura 44: Diagrama de clases de dominio Un aspecto a destacar, es la definición de las clases correspondientes al controlador (control) y el agente de base de datos (broker). Además de la clase lib_db que contiene las funciones de conexión, desconexión, ejecución de consultas y tratamiento de resultados, que 108

127 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. control #_init_broker +control(conectividad : int) +getbroker() : broker +connect(conectividad : int) : void +disconnect() : void broker lib_db 0 +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 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 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

128 politicas_acceso id INT(10) roles_empresas codigo_cliente INT(10) id INT(10) nombre VARCHAR(45) nombre VARCHAR(45) longitud INT(2) id_interno VARCHAR(45) letras TINYINT(3) numeros TINYINT(3) 1..* codigo_cliente INT(10) nivel INT(10) especiales TINYINT(3) descripcion TEXT caducidad VARCHAR(45) primera_sesion TINYINT(3) 1..* envio_credenciales TINYINT(3) clave_dni TINYINT(3) defecto TINYINT(3) 1..* configuracion_active_directory id INT(11) grupos_active_directory id INT(11) nombre VARCHAR(100) identificador VARCHAR(100) descripcion TEXT conexion INT(11) codigo_cliente INT(10) 1..* 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) VARCHAR(512) 1 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) 1..* web VARCHAR(512) pais VARCHAR(256) limiteusuarios INT(10) 0..1 codigo_cliente INT(10) configuracion_ad_avanzado tipo_cliente VARCHAR(45) id INT(10) * 1 login INT(10) pass INT(10) nombre INT(10) apellidos 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) INT(10) dni INT(10) nombreg INT(10) * 1..* 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) rol INT(10) cargo INT(10) telefono INT(10) INT(10) dni INT(10) nombreg INT(10) 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 object_classes_ldap id INT(10) nombre VARCHAR(45) descripcion TEXT Figura 46: Estructura de Base de Datos 110

129 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 satisfactoriamente, en mayor o menor medida. Estudio de las diferentes políticas de seguridad usadas por parte de las empresas. El resumen 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 apartado 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 apartado 5.2 de este documento se muestra la documentación generada en la implementació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 beneficios. Estas ventajas se listan a continuación:

130 Sencilla distribución de la herramienta a las organizaciones. Mediante un simple comunicado compuesto por la URL de acceso junto a las credenciales del usuario es suficiente para que éste acceda a la herramienta. Fácil utilización por parte de la organización. El software no precisa ningún requerimiento 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

131 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

132

133 REFERENCIAS [1] BOOCH, G., RUMBAUGH, J. Y JACOBSON, I., El Lenguaje Unificado de Modelado. Addison Wesley, Madrid, 2006, ISBN: [2] PIATTINI, M., et al. Tecnología y diseño de Bases de Datos. Ra-Ma, Madrid, 2006, ISBN: [3] RUMBAUGH, J, JACOBSON, I. Y BOOCH, G., El Lenguaje Unificado de Modelado. Manual de Referencia. Addison Wesley, Madrid, 2007, ISBN: [4] POLO, M., Apuntes de Ingeniería del Software II (temario de teoría). Universidad de Castilla-La Mancha, Disponible en Internet: [5] POLO, M., Manual de Ingeniería del Software II. Universidad de Castilla-La Mancha, Disponible en Internet: [6] JOSE ANGEL OLIVAS VARELA, Apuntes de la asignatura de Sistemas Basados en el Conocimiento. Universidad de Castilla-La Mancha, [7] E.RICH, KNIGHT., Inteligencia Artificial. Gustavo-Gili, [8] STUART J. RUSSELL Y PETER NORVIG, Inteligencia Artificial, Un enfoque moderno. Prentice Hall, 2 o Edición, [9] PETE DEEMER,BAS VODDE, GABRIELLE BENEFIELD, CRAIG LARMAN., The SCRUM primer. [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 [13] Documento An overview of Scrum. Disponible en 115

134 [14] KNIBERG, H., Scrum y XP desde las trincheras. Disponible en [15] SUTHERLAND, J., SCHWABER, K., The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework. Disponible en [16] Documentación asociada al curso Curso de Desarrollo Ágil. Disponible en [17] Documentación asociada al curso Curso de Introducción al DNI electrónico. Disponible en [18] Documentación asociada al curso Curso de Desarrollo y Certificación de aplicaciones sobre DNI electrónico. Disponible en [19] MINISTERIO DEL INTERIOR, Guía de referencia básica sobre DNIe. Disponible en [20] ANDI GUTMANS, STIG SAETHER BAKKEN, DERICK RETHANS, PHP5 Power Programming. Prentice Hall, [21] PAUL DUBOIS, MySQL. Addison Wesley, 2012 [22] JOSÉ MANUEL ALARCÓN AGUÍN, Fundamentos de JavaScript y AJAX para desarrolladores y diseñadores web. Krasis Press, 2012 [23] ASOCIACIÓN NACIONAL DE EMPRESAS DE INTERNET, Manual de introducción a la seguridad en el ámbito empresarial [24] GILLAM, L., Cloud Computing: Principles, Systems and Applications. Springer [25] IDC, SaaS: aumenta la adopción, se dispara el conocimiento. Disponible resumen de prensa en [26] OWASP, The Open Web Application Security Project. Disponible en [27] Historia de PHP. Disponible en 116

135 [28] SHU-HSIEN LIAO, Expert system methodologies and applications - a decade review from 1995 to [29] CRUZ ROBERTO, Área de Bases de Datos e Inteligencia Artificial. Disponible en [30] BONSÓN ENRIQUE, Tecnologías Inteligentes para la Gestión. Rama, 3 a edición, [31] DGPGC, DNIe - Guía de referencia básica. Disponible en v1.4,

136 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 dimensió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

137 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) 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) 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 Vci Valor global de una aplicación en una dimensión (VC1,..) Vu Valor umbral de una aplicación (habitualmente consideramos 7) // 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

138 cada dimensión. VC 1 = VC 2 = VC 3 = VC 4 = i=1,2,5 i=1,4,5,7 i=4,7,9,10 i=6,10,12,17 (V pi//vui)( 10 i=1 (V ji//vui)( (Vai//Vui)( (Vei//Vui)( 7 i=1 12 i=1 17 i=1 Ppi V pi) 1/10 P ji V ji) 1/7 Pai Vai) 1/12 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 = 4 i=1 (VC i/4) si 4 i=1 VC i 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 (%) 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

139 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 procede, 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 Sí Tipo de datos sensibles 6 1 No Red interna No Red externa 5 1 No Límite de intentos con bloqueo de usuario Sí Existe Captcha Sí La contraseña se envía por correo No 121

140 Conexión segura ssl 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) Sí Tabla 21: Nivel de seguridad/características Relación de los niveles de seguridad y las medidas a tomar N o mínimo de caracteres >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

141 III DOCUMENTOS ADQUISICIÓN DE CONOCIMIENTO Fecha: Hora: Lugar: Asistentes: Conocimiento anterior a la entrevista Síntesis del conocimiento obtenido en las entrevistas 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 realizar para obtener el conocimiento. Resultado de la sesión Aquí se transcriben las respuestas obtenidas a las preguntas del planteamiento 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

142 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 seguridad. 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 dominio 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 estructuradas. Planteamiento de la sesión 124

143 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á utilizando es una herramienta situada en una red interna. 2. En algunas empresas cada uno de los empleados debe autenticarse contra un dominio 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 tenemos. 125

144 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

145 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 empresa 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 caracterí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

146 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 tomarse 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 simplemente 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 equivocación, se obliga a todos los usuarios que modifiquen la contraseña en el primer acceso. 128

147 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

148 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

149 (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

150 (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

151 (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

152 (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

153 (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

154 (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

155 (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

156 (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

157 (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

158 (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

159 (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

160 (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

161 (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

162 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

163 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

164 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

165 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 empresa. 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

166 Usuario y contraseña, se debe introducir un usuario y contraseña validos en las casillas 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

167 Para cambiar el nombre de usuario hay que introducir el nuevo nombre en el campo Nombre 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 introducida 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

168 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

169 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

170 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 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 LDAP y los campo de usuario que se tienen en la herramienta. 152

171 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

172 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

173 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

174 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 necesario 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

175 157