Universidad Austral de Chile

Transcripción

1 Universidad Austral de Chile Facultad de Ciencias de la Ingeniería Escuela de Ingeniería Civil en Informática PROPUESTA METODOLÓGICA PARA LA IMPLEMENTACIÓN DE SISTEMAS DE GESTIÓN DE IDENTIDADES EN PEQUEÑAS Y MEDIANAS EMPRESAS DE LA REGIÓN DE LOS RÍOS Tesis para optar al Título de: Ingeniero Civil en Informática Profesor Patrocinante: Sr. Luis Vidal Vidal Ingeniero Civil en Informática Universidad Austral de Chile Profesor Co-Patrocinante: Sr. Raimundo Vega Vega Doctor en Informática Master en Informática Universidad Politécnica de Madrid Estadístico Universidad Austral de Chile Profesor Informante: Sra. María Eliana de la Maza Werner Ingeniero Civil en Informática Universidad Austral de Chile Magíster en Informática Educativa Universidad de la Frontera. JUAN CARLOS MARDONES KONING VALDIVIA - CHILE 2013

2

3

4

5 ii Dedicado a mis seres queridos...

6 ÍNDICE DE CONTENIDOS 1. INTRODUCCIÓN Propósito del Trabajo Objetivo general Objetivos Específicos Importancia del trabajo Organización de la tesis MARCO TEÓRICO Arquitectura Empresarial Marco de Trabajo Zachman Marco de Trabajo TOGAF Identidad e identidad digital Ciclo de vida de las identidades digitales Sistemas de gestión de identidades en Tecnologías de la Información Características de los sistemas de gestión de identidades en TI ARQUITECTURA DE SOLUCIÓN PARA SISTEMAS DE GESTIÓN DE IDENTIDADES Arquitectura de Solución Arquitectura funcional/lógica Arquitectura operacional/física Ejemplos de escenarios de implementación Seguridad en archivos y directorios Sistemas de apoyo a la docencia y educación Sistemas de misión crítica con tolerancia a fallos y alta disponibilidad METODOLOGÍA Metodología de investigación Hipótesis Propuesta de Metodología para sistemas de gestión de identidades Modelar la Arquitectura empresarial Identificar factores críticos de éxito del sector Cumplir con los criterios para el uso de sistemas de gestión de identidades Analizar la cantidad de usuarios Análisis y aplicación de la metodología iii

7 4.4.1 Paso 1. Modelar Arquitectura Empresarial Paso 2. Identificar Factores críticos de éxito Paso 3. Cumplir con los criterios para el uso de sistemas de gestión de identidades Paso 4. Analizar la cantidad de usuarios Resultado final CONCLUSIONES Y RECOMENDACIONES Conclusiones Recomendaciones REFERENCIAS ANEXOS A. Definición de Términos y Variables B. Información de la empresa Misión Visión Valores iv

8 ÍNDICE DE FIGURAS FIGURA PÁGINA 1 Metodología del desarrollo de la arquitectura TOGAF Resumen del marco de contenidos de TOGAF Ciclo de vida de las identidades digitales Diagrama esquemático de un sistema de control de accesos en una empresa Diagrama del proceso de SSO Árbol de directorio LDAP Diagrama de arquitectura funcional/lógica Diagrama de arquitectura operacional/física de una implementación de sistema de gestión de identidades Arquitectura funcional/lógica en la implementación de políticas de seguridad en recursos compartidos Arquitectura operacional/físicaen la implementación de políticas de seguridad en recursos compartidos Diagrama de tecnologías presentes en LAMS Arquitectura funcional/lógica para implementación de LAMS con MSAD Arquitectura operacional para la implementación de LAMS con MSAD Diagrama de implementación de solución para el control de accesos en alta disponibilidad Factores determinantes para la implementación de sistemas de gestión de identidades Diagrama de la cadena de Valor del sector Diagrama de la arquitectura de los proyectos de apoyo a la enseñanza y educación v

9 ÍNDICE DE TABLAS TABLA PÁGINA 1 Vistas empresariales del marco de trabajo de Zachman Vistas empresariales del marco de trabajo de Zachman aplicado a la empresa vi

10 RESUMEN El presente trabajo tiene como objetivo entregar a las pequeñas y medianas empresas de la región de los Ríos las herramientas necesarias para tomar la decisión acerca de la implementación de sistemas de gestión de identidades, permitiendo aportar en el desarrollo, crecimiento y seguridad de dichos tipos de organizaciones. Con el fin de lograr este objetivo, primeramente se describieron formas de analizar una organización utilizando diversos puntos de vista, esto permitió descubrir cuáles son las necesidades de esa organización y entrega luces acerca del horizonte de dicha organización. Posteriormente se entregaron las bases teóricas acerca de los conceptos relacionados con identidad, entregando los cimientos necesarios para entender qué es un sistema de gestión de identidades y cuál es su rol dentro de la organización. A continuación se analizaron diversos escenarios de implementación de sistemas de gestión de identidades, con el fin de ilustrar ejemplos concretos de uso y aplicación. Para finalizar, se construyó la propuesta metodológica y se validó en una organización de la región de los Ríos, verificando con ello veracidad de la hipótesis planteada y la efectividad de esta propuesta. vii

11 ABSTRACT This paper is intended to give small and medium companies of the region de los Ríos the necessary tools to decide about the deployment of identity management systems. This IT deployment can help to the development, growth and security of these types of organizations. To accomplish this goal, it was first described ways to analyze an organization using different points of view. This allowed to discover what the organization needs are and helped to discover insights about the organization horizon. Subsequently, it was given the theoretical foundations about the concepts related to identity, providing the foundations required to understand what an identity management system is and what the role is in the organization. Then, it was analyzed different identity management system deployment scenarios in order to illustrate specific examples of use and application. Finally, the proposed methodology was built and validated in an organization, thereby verifying the veracity of the proposed hypothesis and the effectiveness of the proposal. viii

12 1. INTRODUCCIÓN A medida que trascurre el tiempo se van creando nuevas pequeñas y medianas empresas en la Región de los Ríos. Si dichas empresas pueden ser conscientes de que existen herramientas que pueden aportar en sus procesos de negocio, mejorarlos y asegurarlos desde una perspectiva tanto tecnológica como organizacional, existe una posibilidad de que dichas empresas puedan incrementar sus ventas así como también las medidas de seguridad con el fin de proteger uno de los activos que pueden ser más importantes hoy en día: la información. La investigación que se describe en el presente trabajo de título tiene relación con la creación de una metodología para determinar la necesidad de implementar un sistema de gestión de identidades en las pequeñas y medianas empresas de la Región de los Ríos, con el fin de aportar en el desarrollo, crecimiento, seguridad y estabilidad de dichos tipos de empresas. 1.1 Propósito del Trabajo continuación: Los objetivos generales y específicos del presente estudio se detallan a Objetivo general El objetivo general de este trabajo consiste en una propuesta de metodología para la implementación de sistemas de gestión de identidades en las pequeñas y medianas empresas de la Región de los Ríos. 1

13 1.1.2 Objetivos Específicos Los objetivos específicos de este estudio son los siguientes: 1. Describir marcos de trabajo que permitan modelar la arquitectura empresarial de las pequeñas y medianas empresas de la Región de los Ríos. 2. Identificar y definir los factores críticos que crean la necesidad de utilizar sistemas de gestión de identidades en las pequeñas y medianas empresas de la Región de los Ríos. 3. Describir arquitecturas de solución para sistemas de gestión de identidades. 4. Establecer una propuesta de metodología para precisar la necesidad de uso de Sistemas de Gestión de Identidades en las pequeñas y medianas empresas de la Región de los Ríos. 5. Analizar la propuesta de metodología creada para relacionar y contrastar la realidad de las pequeñas y medianas empresas de la Región de los Ríos. 1.2 Importancia del trabajo Este estudio motiva a la investigación acerca de como las pequeñas y medianas empresas están utilizando la tecnología para realizar y facilitar sus procesos de negocios, lo que eventualmente entregaría nuevas oportunidades de negocios en empresas donde no se están utilizando tecnologías de la información para automatizar y/o facilitar los procesos de negocios. Los resultados del presente trabajo benefician a la creación de estudios similares centrados en el uso de nuevas tecnologías como factor crítico de diferenciación e innovación. Finalmente este estudio podría eventualmente ayudar al crecimiento de las pequeñas y medianas empresas de la Región de los Ríos, aportando en la evolución, seguridad y estabilidad de dichos tipos de empresas. 2

14 1.3 Organización de la tesis Este trabajo contiene un total de cinco capítulos y dos anexos, que se describen a continuación: Capítulo 1. Introducción. En este capítulo se describe el origen del presente trabajo, su objetivo principal junto con los secundarios. Se detalla la importancia, el alcance y las limitaciones de éste, así como la organización del documento de tesis. Capítulo 2. Marco teórico. Aquí se detallan las bases que servirán para entender capítulos posteriores. Se ilustra la forma de modelar una arquitectura empresarial y se entregan las bases teóricas acerca de los sistemas de gestión de identidades. Capítulo 3. Arquitectura de solución para sistemas de gestión de identidades. Este capítulo abarca la arquitectura de solución para la implementación de sistemas de gestión de identidades, se entregan los componentes típicos junto con ejemplos concretos para este tipo de implementaciones. Capítulo 4. Propuesta Metodológica. El cuarto capítulo se centra en entregar la propuesta metodológica, describiendo el método utilizado junto con los resultados del uso de la metodología aplicándola a una empresa de la región de los Ríos. Capítulo 5. Conclusiones y recomendaciones. Finalmente se ofrecen las conclusiones más relevantes que se surgen de este trabajo, así como las recomendaciones para la continuación de futuros estudios. Anexo A. Definición de términos y variables. Este anexo describe los términos, acrónimos y definiciones más relevantes utilizadas en el presente trabajo. Anexo B. Información de la Empresa. Este anexo describe la información de la empresa utilizada en la prueba de la propuesta de metodología. 3

15 2. MARCO TEÓRICO Modelar la arquitectura de una empresa puede llegar a ser una tarea compleja, especialmente si se desconocen las herramientas necesarias para la comprensión de cada uno de los componentes que conforman la organización y las interacciones que estos componentes tienen con la empresa. Es importante destacar que la forma de ver y entender una empresa muchas veces depende del rol que desempeñe esa persona dentro de la organización, por lo que sus opiniones, juicios y razonamientos estarán enmarcados a las perspectivas que dicha persona posea de la empresa, especialmente cuando se habla de la implementación de proyectos en tecnologías de la información. El presente capítulo entrega las bases teóricas para modelar una arquitectura empresarial utilizando vistas de diversos actores de la organización con el fin de describir la empresa como una sola unidad funcional, adicionalmente se definen los cimientos para entender la problemática de la identidad digital y como esta problemática se relaciona con los sistemas de gestión de identidades. 2.1 Arquitectura Empresarial Al acercarse al concepto de arquitectura empresarial, en inglés Enterprise Architecture (EA), Sessions [Ses08] propone que una arquitectura empresarial es una descripción de los objetivos de una organización, como estos objetivos son realizados por los procesos de negocios y como estos procesos pueden mejorar a través de la tecnología. El foro de investigación de EA de Sudáfrica, aporta otra perspectiva con respecto a esta definición, señalando que EA es la práctica continua de describir los elementos esenciales de una organización socio-técnica, sus relaciones entre sí y con el ambiente, con el fin de comprender la complejidad y gestionar los cambios. [Erf12]. El concepto de EA se inició hace ya veintiséis años atrás, algunos autores como Sessions [Ses08] y Godínez [God10] aseguran que la primera y más influyente metodología de EA es el marco de trabajo de Zachman, que se introdujo por primera vez en 1987 por John Zachman. Transcurrido unos años, específicamente en el año 1991, el Departamento de Defensa de los Estados Unidos completó el primer borrador de una 4

16 metodología basada en los principios de Zachman, que se denominó Technical Architecture Framework for Information Management (TAFIM). Posteriormente, en el año 1995, TAFIM fue utilizado como el eje principal para crear la primera versión de The Open Group Architecture Framework, más conocido como TOGAF, por el consorcio The Open Group. Dada la importancia y el reconocimiento que estos dos enfoques entregan a la construcción de una EA, se detallarán a continuación los marcos de trabajo de Zachman y TOGAF con el fin de entregar herramientas que permitirán proporcionar un método para generar una arquitectura empresarial Marco de Trabajo Zachman Antes de comenzar con la descripción de este enfoque de EA, es necesario aclarar el concepto de marco de trabajo, que de acuerdo al diccionario Oxford [Oxf10], es una estructura esencial que sirve como fundamento para la construcción de un sistema o concepto. En ese contexto, el marco de trabajo de Zachman sirve de cimiento para representar diferentes perspectivas de una empresa y es ampliamente reconocido como uno de los primeros marcos de trabajo que incorpora la noción de EA [Rey10]. Está basado en una matriz de seis por seis, como se puede apreciar en la Tabla 1, donde se definen 36 vistas empresariales, que de acuerdo a Subramanian [Sub08], definen una construcción lógica para controlar las interfaces y componentes de un entorno de sistemas de información y proporciona un método estandarizado para la consideración de todos los aspectos de una infraestructura de tecnologías de la información. Siguiendo en la misma línea de trabajo, Bente, Bombosch y Langade [Ben12], proponen que el aporte del marco de trabajo de Zachman es que proporciona un esquema de clasificación, intentando poner orden en el mundo de los negocios y las tecnologías de la información. El conjunto total de las representaciones descriptivas para detallar una empresa está dado en la matriz de la Tabla 1. Las columnas son llamadas abstracciones y responden a preguntas clave sobre la empresa: Qué? (Datos), Cómo? (Actividades), Dónde? (Ubicaciones), Quién? (Personas), Cuándo? (Ritmo), y Por 5

17 Qué? (Motivación), mientras que las filas son llamadas perspectivas, ya que cada fila representa el punto de vista de un solo grupo de interesados. Tabla 1: Vistas empresariales del marco de trabajo de Zachman 1. En consecuencia, es posible resumir el marco de trabajo de Zachman en seis reglas que se detallan a continuación: 1. Las columnas no tienen un orden y cada columna es igualmente importante. 2. Cada columna tiene un modelo simple, que describe un aspecto de la empresa. 3. Cada columna es única ya que son abstracciones del mismo aspecto de la empresa, sin embargo, cada modelo representa un concepto distinto. 4. Cada fila representa una vista distinta. Las filas describen perspectivas de los distintos interesados (ejecutivos, analistas de negocios, arquitectos, ingenieros y técnicos). 5. Cada celda es única y cada modelo de representación o célula se diferencia de los demás en esencia y no sólo en el nivel de detalle. 1 Fuente: Traducción de figura 1.1 del libro Requirements analysis: From business views to architecture [Hay03] 6

18 6. Combinar las celdas de una fila forma una visión completa. Cada fila ofrece una visión global de la empresa desde la perspectiva de un grupo de partes interesadas Marco de Trabajo TOGAF Como se explicó anteriormente en este mismo capítulo, The Open Group desarrolló su propio marco de trabajo: El Esquema de Arquitectura de Open Group, del inglés The Open Group Architecture Framework o simplemente TOGAF. Inicialmente estaba basado en el TAFIM del departamento de defensa de Estados Unidos, pero con el transcurso del tiempo ha sido revisado hasta llegar a la versión actual, TOGAF 9, que dentro de sus herramientas principales está posibilidad de modelar el ciclo de vida para el desarrollo de una EA, conocido como Architecture Development Methodology (ADM) y la construcción de los contenidos que se emplean en esta ADM, utilizando el marco de contenido [Rao11]. Las fases de ADM pueden apreciarse en la figura 1, Reese [Ree10] entrega una breve explicación acerca de cada una de las fases de ADM, las cuales se resumen a continuación: Fase preliminar, que describe las actividades de preparación e inicialización necesarias para emprender la creación de la EA. Fase de Gestión de Requerimientos, en este conjunto de procesos se certifica que los requisitos son los que impulsan la creación de la EA, siendo depurados y conservados durante todo el ciclo de ADM. Fase A Visión de la Arquitectura, donde se especifica el motivo de la arquitectura y es la primera iteración de la metodología. Fase B Arquitectura del negocio, aquí se concentra el desarrollo de la arquitectura empresarial, que está formada por los requerimientos, las métricas del negocio y la identificación de las capacidades necesarias en la arquitectura. Fase C - Arquitectura de los Sistemas de Información, en esta fase de ADM se especifica la información, datos, y arquitecturas de aplicaciones necesarias para cumplir con los requisitos del negocio. Fase D Arquitectura Tecnológica, donde se especifican los componentes técnicos de la arquitectura de TI necesarios para apoyar la arquitectura de sistemas de información. Esto incluye el software, middleware y hardware necesarios para satisfacer las necesidades del negocio. 7

19 Fase E Oportunidades y Soluciones, ofrece las opciones para la implementación junto con los costos y beneficios. Incluye planes de implementación y transición para la entrega de las arquitecturas especificadas en las fases anteriores. Fase F Planificación de la migración, es aquí donde se proporcionan los planes de migración para la transición a las nuevas arquitecturas. Esto incluye la identificación de recursos y las inversiones necesarias para llevar a cabo los planes de transición utilizando un enfoque por etapas. Fase G Gestión de la Implementación, esta fase abarca el modelo de administración de las arquitecturas, es decir, el establecimiento de un comité de revisión o de otros comités con la supervisión y el cumplimiento de estándares. Para finalizar, se termina el ciclo de ADM con la Fase H Gestión de los cambios de la Arquitectura, esta fase proporciona la supervisión y un modelo para impulsar el cambio a través de los diferentes dominios de TI afectados por las arquitecturas y los planes de implementación. Figura 1: Metodología del desarrollo de la arquitectura TOGAF. 2 2 Fuente: Elaboración propia en base a traducción de Figura libro FEAC Certified Enterprise Architect CEA Study Guide [Rao11]. 8

20 Para una revisión en detalle de TOGAF es recomendable revisar el documento oficial del estándar [Tog11], sin embargo, es necesario aclarar que ADM describe el proceso para crear una EA base, para luego modificarla de forma continua con el fin de mejorarla utilizando para ello iteraciones del proceso. El marco de contenido proporciona una estructura subyacente de la ADM que define las entradas y salidas con detalle y sitúa cada resultado en el contexto de la visión holística de la arquitectura de la empresa. El marco de contenido, que se ilustra en la figura 2, se utiliza como un complemento de ADM. La metodología describe lo que hay que hacer para crear una EA y la estructura de contenido describe los contenidos que deberían tener los documentos relacionados con cada una de las fases de ADM. Figura 2: Resumen del marco de contenidos de TOGAF 3 3 Fuente: Elaboración propia en base a traducción de la especificación TOGAF 9.1 [Tog11] 9

21 2.2 Identidad e identidad digital En el mundo físico, las personas están familiarizas con el concepto de identidad, ya que se utiliza constantemente para obtener accesos, beneficios, derechos y obligaciones. La Real Academia Española [Rae01] define identidad como el Conjunto de rasgos propios de un individuo o de una colectividad que los caracterizan frente a los demás. Fröhlich [Fro93], en su diccionario de psicología, define identidad como la organización relativamente constante de características que posee un individuo. Algunos ejemplos del uso de las identidades son la comprobación de la identidad al utilizar bienes o servicios relacionados con la mayoría de edad, el cobrar un cheque en el banco, sacar el permiso de conducir, la cedula de identidad, la recepción de comunicación privada, entre muchos otros. Estos ejemplos de características que se encuentran en el mundo físico también se pueden encontrar en el mundo virtual, razón por la cual se define identidad digital como la representación digital de la información conocida acerca de un individuo u organización especifico [Ber11]. La identidad digital puede incluir atributos como el nombre, el número de identificación nacional ( por ejemplo el Rol Único Nacional en el caso de Chile, el Número de Seguro Social en Estados Unidos, el documento Nacional de Identidad en España, etc.), dirección, estado civil, fecha de nacimiento, género, entre muchos otros. Siguiendo con el concepto de identidad digital, la Unión Internacional de Telecomunicaciones (UIT), en la Recomendación UIT-T Y.2720 [UIT09] define identidad como la Información acerca de una entidad, entendiendo entidad como todo lo que tiene existencia separada y distinta y puede identificarse unívocamente, que resulta suficiente para identificar a dicha entidad en un determinado contexto. De acuerdo a esta recomendación, una identidad consiste en tres diferentes tipos de datos: i. Identificadores [UIT07]: Serie de dígitos, caracteres y símbolos o cualquier otra forma de datos utilizados para identificar una entidad, como por ejemplo: identidad de usuario, dirección de correo electrónico, números de teléfono, direcciones IP, entre otros. 10

22 ii. iii. Credenciales: Son objetos identificables que se pueden utilizar para acreditar que el declarante es quien declara ser, así como para autorizar los derechos de acceso del declarante. Atributos [ETS09]: Es la información descriptiva vinculada a una entidad que especifica alguna característica de dicha entidad Ciclo de vida de las identidades digitales Durante el transcurso del tiempo, una identidad digital puede sufrir varios cambios, por lo que es conveniente analizar estos cambios desde un punto de vista del ciclo de vida de las identidades digitales. Los ciclos de vida ocurren en todo orden de cosas, desde el pequeño organismo unicelular hasta las grandes estrellas que pueden permanecer cientos de miles de años activas antes de morir y dejar de entregar su energía. Con el fin de formalizar la definición del concepto, conviene mencionar que el diccionario Ingles Oxford [Oxf10] define ciclo de vida como la serie de cambios en la vida de un organismo. En el caso del ser humano, pasamos por diversos estados a lo largo de nuestra existencia: nacemos, crecemos a la niñez, pasamos a la adolescencia, continuamos a la edad adulta y por último se llega a la senectud. En lo que respecta al ciclo de vida de las identidades digitales, Windley [Win05] propone cinco etapas bien diferenciadas que se ilustran en la figura 3 y se definen a continuación: Figura 3: Ciclo de vida de las identidades digitales 4. 4 Fuente: Elaboración propia en base a traducción de Figura 5-1 libro Digital Identity [Win05] 11

23 a) Creación: Es la etapa en donde se crea el registro de identidad y se ingresan los atributos, ejemplos de atributos pueden ser nombres, correo electrónico, dirección, teléfono, entre otros. Esta etapa suele ser realizada por la acción de un administrador o por el mismo usuario que utilizará el servicio mediante un sistema de registro de auto servicio, donde ingresando los datos requeridos por el sistema, es posible crear y dar de alta la identidad en el sistema. b) Propagación: Los registros de identidad pueden necesitar ser propagados a otros sistemas como parte del ciclo de vida dependiendo de la naturaleza del sistema en el cual la identidad fue creada. Esta propagación debe ocurrir cada vez que se modifican los registros de identidad. c) Uso: Una vez que la identidad ha sido creada y propagada ya puede ser utilizada por los sistemas que se conectan al repositorio de identidades. Esta etapa tiene directa relación con la lectura de la identidad de parte de los sistemas y la acreditación y autorización para la realización de acciones por parte del usuario. d) Mantenimiento: Es común que los atributos de una identidad cambien. Un ejemplo concreto que se puede citar es el hecho de que, para satisfacer nuevos requerimientos del negocio, el esquema de los registros de una identidad sea modificado para agregar nuevos campos. El mantenimiento de las identidades puede ser una de las actividades más costosas en el uso diario, debido principalmente a que los usuarios olvidan las contraseñas de los sistemas. Mientras más acciones pueda realizar el usuario por el mismo, más se ahorrará en costos de mantenimiento de las identidades en relación a los requerimientos a soporte. e) Eliminación o desactivación: Tan importante como la tarea de crear la identidad es el hecho de eliminarla o desactivarla de los sistemas una vez que ha terminado su ciclo de vida. Frecuentemente la tarea de eliminar o desactivar las identidades que no se necesitan es una tarea crítica, ya que de no realizarse esta importante tarea, existe una oportunidad para la realización de fraudes, robos, acceso a datos críticos de la empresa por parte de personas ajenas a la organización o simplemente suplantación de identidad. Conocer el ciclo de vida de las identidades digitales permite entender cómo van cambiando los roles y actividades de las personas a medida que transcurre el tiempo. Es aquí donde es posible formalizar la siguiente interrogante: Que se necesita para 12

24 administrar las operaciones que existen durante el ciclo de vida de una identidad digital? La respuesta a esta pregunta la entregan los sistemas de gestión de identidades Sistemas de gestión de identidades en Tecnologías de la Información Existen diversas perspectivas con respecto a la definición de los sistemas de gestión de identidades. La primera que se mencionará la entrega la UIT [UIT09], señalando que la gestión de identidades es el conjunto de funciones y capacidades de administración, gestión y mantenimiento, descubrimiento, intercambio de comunicación, correlación y vinculación, cumplimiento de políticas, acreditación, y asertos que se utilizan para garantizar la información de identidad, garantizar la identidad de una entidad y para habilitar aplicaciones de negocios y de seguridad. Montoya y Restrepo [Mon12] complementan la definición anterior agregando que el concepto de gestión de identidades es un término que se puede entender como el conjunto de procesos de negocio, tecnologías, infraestructura y políticas que permiten realizar la gestión de las identidades de usuario y controlar el acceso de éstos a los diferentes recursos organizacionales. Mencionan adicionalmente que este término no debe entenderse como una tecnología o herramienta que se implementa en una organización de forma general, ya que esto involucra diferentes procesos y áreas en la organización, desde la alta gerencia hasta las áreas de soporte y apoyo; cuya implementación y buenos resultados depende de la disposición y el grado de compromiso que demuestre cada uno de los diferentes actores al interior de la compañía en el desarrollo de un proyecto de este tipo Características de los sistemas de gestión de identidades en TI Es posible distinguir a lo menos tres características comunes cuando se habla de un sistema de gestión de identidades, que dependiendo de las necesidades y requerimientos del negocio pueden ser solicitados en mayor o menor medida. Estas características son: (i) administración de identidades y control de acceso, (ii) inicio único de sesión y (iii) servicios de directorio. Los cuales son detallados a continuación. 13

25 Administración de Identidades y Control de Acceso Como se ha revisado con anterioridad en este mismo capítulo, una identidad digital está compuesta por atributos, como por ejemplo los nombres de una persona, el correo electrónico, el teléfono, además de otra información que hace posible identificar a dicha persona. Las organizaciones guardan esa información con el fin de realizar variadas tareas, siendo de las más comunes, su utilización en los sistemas de financieros, sistemas de recursos humanos y sistemas de administración de la relación con los clientes. En algunas empresas, la cuenta de usuario de una persona permite ingresar al computador personal, al correo electrónico y tiene asociado un nombre de usuario y contraseña que le permite al usuario el ingreso a variadas aplicaciones empresariales. La acción de iniciar sesión es denominada autenticación y la acción de entregar los accesos al sistema se denomina autorización. Misra [Mis11] define los dos procesos anteriormente señalados, indicando que el proceso de autenticación es la verificación para comprobar que el usuario es el que dice ser. Añade además que una identidad de un usuario es verificada a través de credenciales presentadas por ese usuario como son: a) Algo que tiene, por ejemplo, credenciales hechas por una autoridad confiable como puede ser un pasaporte, cedula de identidad o una tarjeta inteligente. b) Algo que se conoce, como por ejemplo un secreto compartido como una contraseña. c) Algo que se es, por ejemplo información biométrica de los dedos u ojos. Una combinación de diversos tipos de credenciales se conoce como autenticación fuerte, un ejemplo frecuente de este tipo de autenticación se puede encontrar en sistemas bancarios, donde el mencionado sistema solicita al usuario las coordenadas de una tarjeta o token de seguridad ( algo que se tiene ), sumado al hecho de una contraseña para validar la identidad, es decir algo que se conoce. Una vez finalizado el proceso de autenticación, se inicia el proceso de autorización o control de acceso. La autorización es el proceso que permite entregar el acceso a recursos específicos basados en los privilegios que posea un usuario que ya está autenticado. Los privilegios están definidos por uno o más atributos, donde un atributo es una propiedad, característica o rol de un usuario. Para facilitar la contextualización de lo anteriormente descrito conviene ilustrar el siguiente ejemplo: 14

26 David es el director de una revista internacional, su rol en la empresa le entrega el privilegio de decidir el contenido de cada uno de las ediciones de la revista. En el sistema informático de edición de contenidos, David posee el rol de administrador. Dicho rol tiene los privilegios de creación, edición y eliminación de contenido de la revista. De acuerdo a Williamson [Wil09], un ambiente de gestión de identidades proporciona suministro y gestión de roles, siendo los principales retos para una organización los siguientes: Creación de los derechos de acceso a nuevos empleados mediante la incorporación de los identificadores de usuario hacia los sistemas que lo requieran. Gestionar los cambios organizacionales, por ejemplo los derechos de acceso para personas que se cambian de departamento, las personas que reciben aumentos, entre otros. Deshabilitar los derechos de acceso de las personas que salen de la empresa. La figura 4 muestra un diagrama esquemático del proceso de control de accesos en una empresa. En este sistema los usuarios pueden acceder a diferentes recursos de la organización dependiendo de sus roles y privilegios, independiente del dispositivo en el cual hayan iniciado sesión. Figura 4: Diagrama esquemático de un sistema de control de accesos en una empresa 5. 5 Fuente: Elaboración propia. 15

27 Inicio Único de Sesión El inicio único de sesión, en ingles Single Sign-On (SSO), es un mecanismo donde una única acción del usuario para autenticar y autorizar, permite a dicho usuario acceder a una variedad de recursos seguros donde ese usuario tiene permisos de acceso sin la necesidad de ingresar nuevamente sus credenciales en cada uno de esos recursos [Poh08]. De acuerdo con Pohlman [Poh08], existen tres motivos principales por los cuales se implementaría SSO en una organización: 1. Facilidad de uso: ya que las personas no tendrían que cuidar distintas credenciales de autenticación por cada distinto sistema. 2. Administración de usuarios: Un solo sistema de administración puede reforzar una política global de contraseñas. Se pueden unificar reglas y relaciones de confianza entre un grupo de entidades, por lo que los costos operacionales se pueden ver reducidos. 3. Seguridad: SSO tiene el potencial de incrementar el nivel total de seguridad, primeramente desde la perspectiva del usuario, ya que es más sencillo mantener una credencial de seguridad que muchas. Adicionalmente, reforzar una política global de contraseñas reduce el riesgo errores humanos y abusos. Si bien es cierto que se ha señalado la seguridad como un punto positivo, también es la principal desventaja desde el punto de vista de la seguridad informática y protección de la información: la falla en la seguridad de las credenciales de SSO puede resultar en la pérdida de todas las cuentas conectadas al sistema de SSO. Por lo que se tienen que reforzar las políticas de seguridad para reducir los riesgos asociados a la pérdida o mal uso de las credenciales de seguridad. La figura 5 muestra un diagrama del proceso de SSO. Este proceso se detalla a continuación: 16

28 Figura 5: Diagrama del proceso de SSO 6 1. El usuario ingresa sus credenciales al sistema de SSO. 2. El servidor de SSO valida si las credenciales son correctas, si no lo son, el servidor devuelve un mensaje de error al usuario para que este ingrese nuevamente sus credenciales. 3. En el caso que las credenciales sean correctas, el servidor de SSO permite al usuario el acceso a los recursos de la organización Servicios de Directorios En términos de TI, un directorio es una base de datos especializada, que puede también denominarse repositorio de datos, donde se almacena información acerca de entidades. Una característica especial de los directorios es que estos son accedidos, ya sea para leer o buscar información, mucho más a menudo que para actualizar o crear nueva información. Por este mismo hecho, deben ser capaces de soportar un alto número de peticiones de lectura y están optimizados para accesos de lectura y búsqueda [Joh98]. El Protocolo Ligero de Acceso a Directorios, más conocido como Lightweight Directory Access Protocol (LDAP) es un protocolo estándar y está especificado en el 6 Fuente: Elaboración propia. 17

29 RFC4510 "Lightweight Directory Access Protocol Technical Specification Road Map" [RFC4510]. LDAP define un protocolo de mensajes, que es utilizado por clientes y servidores de directorios, definiendo un método estándar para acceder y actualizar información en un directorio. Todos los servidores LDAP comparten características básicas como lo son el protocolo [RFC4511], los modelos de información del directorio [RFC4512], métodos de autenticación y mecanismos de seguridad [RFC4513], representación de los filtros de búsquedas [RFC4515], sintaxis y reglas de coincidencia [RFC4517], caracteres en distintos idiomas [RFC4518] y esquema para las aplicaciones de usuario [RFC4519]. Con respecto a LDAP y los servicios de directorios, la Guía de Administración de OpenLDAP [Ope12] entrega la siguiente definición: los datos contenidos en el servidor de directorios están organizados en colecciones de información denominadas entradas. Un ejemplo de entradas se puede apreciar en la figura 6. Figura 6: Árbol de directorio LDAP 7. Una entrada contiene atributos y un identificador único, denominado Distinguished Name (DN), para el ejemplo entregado en la figura 5, el DN seria cn=juan Mardones, ou=ventas, dc=oracle,dc=cl. Cada uno de los atributos de una 7 Fuente: Elaboración propia basado en la figura 1.1 de libro OpenLDAP Software 2.4 Administrator's Guide" [Ope12] 18

30 entrada tiene un tipo, un valor y una sintaxis asociada al tipo de datos. Para contextualizar la definición anterior conviene realizar un ejemplo: para el atributo nombre la sintaxis es una cadena de caracteres, en contraste, para revisar el estado de una cuenta de usuario, se puede usar un cero para indicar que la cuenta está desactivada o un uno para indicar que está activa, por lo que la sintaxis seria de valor binario. Las entradas en un directorio están organizadas en una estructura jerárquica, de manera similar a un árbol, donde tradicionalmente se ve reflejada la estructura de la organización. 19

31 3. ARQUITECTURA DE SOLUCIÓN PARA SISTEMAS DE GESTIÓN DE IDENTIDADES El paso previo que se ejecuta antes de realizar la implementación de cualquier tipo de proyecto acostumbra ser la realización del diseño y la estructura operacional de lo que se va a implementar. Este concepto es conocido como arquitectura de solución y es de vital importancia para entender los componentes que conforman una solución. 3.1 Arquitectura de Solución De acuerdo a Buecker y Jeremic [Bue09], una arquitectura de solución describe la estructura y relaciones entre los componentes del sistema. Usualmente una arquitectura puede ser examinada bajo dos diferentes puntos de vista: 1. Arquitectura funcional/lógica: Describe los componentes y las relaciones entre productos desde una perspectiva de intercambio de datos. 2. Arquitectura operacional/física: Describe los requerimientos de hardware, el diseño a nivel de red, protocolos de comunicación, posicionamiento de cortafuegos, uso de puertos y otros componentes de la infraestructura involucrados en el despliegue operacional del sistema. Es por esta razón que los análisis detallados a continuación utilizarán estos dos enfoques para la entrega de las soluciones de sistemas de gestión de identidades. 3.2 Arquitectura funcional/lógica Los componentes que están involucrados en un sistema de gestión de identidades se pueden resumir en cuatro: usuarios, recursos protegidos, sistema de gestión de identidades y almacenes de datos. La interacción de cada uno de estos componentes se puede apreciar en la figura 7, que ilustra el diagrama de la arquitectura funcional/lógica de una implementación de un sistema de gestión de identidades. Los detalles acerca del diagrama se entregan a continuación: 20

32 1. El usuario inicia una petición de acceso a algún recurso tecnológico organizacional protegido. 2. El recurso protegido reconoce que es necesario de autenticación/autorización para poder abrir el contenido, por lo que envía una petición de acceso al servidor de gestión de identidades para que retorne si el usuario tiene derecho a utilizar dicho recurso. 3. La petición de acceso es recibida por el servidor de bases de datos, que contiene la información acerca del usuario. 4. El servidor de base de datos devuelve la información acerca de los roles y privilegios del usuario al sistema de autenticación 5. El servidor de autenticación entrega la respuesta de los accesos al recurso protegido 6. El recurso protegido devuelve al usuario la información. En caso de que el usuario tenga permisos para acceder, se le entrega la información requerida. Finalmente, en el caso de que el usuario no tenga los privilegios para acceder a la información, se le avisa que no tiene los permisos suficientes para acceder a dicho recurso. Figura 7: Diagrama de arquitectura funcional/lógica Arquitectura operacional/física En el nivel operacional es posible detallar los equipos que interactúan en el flujo de peticiones de acceso. Como se puede apreciar en la figura 8, que ilustra el diagrama de la arquitectura operacional/física de una implementación de un sistema de gestión de identidades, existen una serie de componentes que hasta ahora se habían nombrado. 8 Fuente: Elaboración propia 21

33 Figura 8: Diagrama de arquitectura operacional/física de una implementación de sistema de gestión de identidades 9. 9 Fuente: Elaboración propia basada en la experiencia y en la guía para despliegues de Oracle [Des12] 22

34 Los detalles del diagrama se especifican a continuación: 1. El usuario envía una petición para acceder a algún recurso organizacional protegido, en este caso, la petición es enviada a un servidor Web utilizando encriptación, usando el protocolo de comunicación HTTPS a través del puerto La petición del usuario pasa por Internet y llega a la Capa de Seguridad, en donde la petición es examinada para ver si es eliminada, o si pasa a la capa siguiente. A. La petición llega primeramente al Cortafuegos, en donde se decide si la petición sigue su curso validando únicamente los puertos de origen y destino, en este caso el destino es el puerto 443. B. Si la petición es validada y aceptada por el cortafuegos, llega al sistema de prevención/detección de intrusos (IPS/IDS). Este último revisa si la petición es válida y certifica que no contenga ningún ataque conocido por la base de datos del IPS/IDS. C. Finalmente y una vez que la petición es validada y aceptada por el IPS/IDS, llega al Cortafuegos de aplicación Web, del Inglés Web Application Firewall (WAF). Este último revisa si la petición es válida y analiza que no pertenezca al conjunto de ataques Web conocidos dentro de la base de datos del WAF. 3. Si la petición fue validada y aceptada por la Capa de Seguridad, entonces llega a la Capa Web. Este segmento de Red está aislado del resto de los recursos computacionales organizaciones y se le conoce como Zona Pública. El servidor Web reconoce que el recurso necesita de autenticación y autorización, por lo que envía una petición usando encriptación al Servidor de Identificación utilizando el protocolo LDAPS, a través del puerto Después de que la petición ha pasado por la Capa Web, ésta llega al segmento de red conocido como Zona Privada pasando por un Cortafuegos, esto implica que los accesos a este segmento de red están restringidos a un limitado número de operaciones, con el fin de incrementar la seguridad y protección de la información. La petición es recibida en la Capa de Identidades por el servidor de directorios y este último envía una petición a la base de datos para obtener la información de los usuarios (autenticación) y las políticas de acceso (autorización). La petición al servidor de base de datos es enviada al puerto 1521 usando una sesión de comandos SQL. 23

35 5. Finalmente la petición llega a la Capa de Datos, donde se encuentran la información almacenada en formato reconocible por el lenguaje de máquina. 3.4 Ejemplos de escenarios de implementación Luego de haber revisado la arquitectura de solución genérica de los sistemas de gestión de identidades, resulta conveniente ilustrar estas arquitecturas con ejemplos concretos acerca de dónde se pueden aplicar los sistemas de gestión de identidades. Se revisaron tres casos basados en la experiencia como analista sénior en sistemas de gestión de identidades: el primero tiene relación con la implementación de políticas de seguridad en archivos y directorios compartidos, el segundo caso revisa la arquitectura de implementación de un sistema de gestión de identidades aplicado a un sistema de apoyo a la docencia y educación y por último se revisa la implementación de un escenario que incluye componentes de alta disponibilidad y consolidación de directorios de información Seguridad en archivos y directorios El siguiente ejemplo ilustra una implementación, realizada como consultor en una mediana empresa de la región de los Ríos, del servicio de directorios Microsoft Active Directory (MSAD) con el fin de acceder a archivos compartidos utilizando privilegios a través de grupos de usuarios. Esta implementación se realizó con el fin de compartir información de proyectos, costos, plazos y contrataciones, entre equipos de trabajo de la empresa de manera segura. Fueron creados 3 grupos de usuarios: gerencia, administrativos y operaciones. Los empleados que pertenecían al grupo gerencia podían acceder a todos los archivos y directorios, mientras que los administrativos y operaciones solo podían compartir archivos dentro de sus respectivos grupos, existiendo adicionalmente un directorio común donde era posible transferir libremente archivos y directorios entre esos dos grupos. Si un usuario no formaba parte de alguno de esos grupos, dicho usuario no tenía privilegios para leer, escribir o ejecutar archivos, aumentando de esa forma la seguridad en el caso de que una nueva persona ingrese al grupo de trabajo de la empresa. 24

36 De acuerdo a Stanek [Sta09], "MSAD es el servicio de directorio incluido en los servidores Windows, e incluye el directorio que almacena información acerca de los recursos distribuidos, así como los servicios que hacen que la información sea útil y se mantenga disponible". MSAD es uno de los servicios de directorios más populares y ampliamente utilizados en el mercado, debido a su facilidad de uso e implementación. La arquitectura funcional/lógica de la implementación se puede apreciar en la figura 9 y se detalla a continuación: Figura 9: Arquitectura funcional/lógica en la implementación de políticas de seguridad en recursos compartidos El usuario inicia sesión en su computador y realiza una petición para acceder a un recurso tecnológico protegido, como puede ser un archivo, una impresora o una carpeta. 2. El computador realiza una petición al servidor DNS para resolver el nombre del recurso. 3. El servidor de DNS retorna el resultado de la consulta al computador del usuario. 4. El computador del usuario realiza la petición de acceso al recurso protegido. 5. El recurso protegido envía una petición al servidor de directorios MSAD para consultar acerca de los privilegios que tiene el recurso protegido. 10 Elaboración propia en base a experiencia realizada como consultor en implementación de sistemas de archivos compartidos. 25

37 6. El servidor MSAD retorna los usuarios/grupos y privilegios que tiene el recurso protegido 7. En base a la información retornada por MSAD, se le entrega la información a la maquina del usuario acerca del acceso al recurso. 8. Finalmente el usuario recibe el mensaje acerca del resultado del acceso al recurso. La arquitectura operacional/física para este ejemplo se puede apreciar en la figura 10 y se describe a continuación: Figura 10: Arquitectura operacional/física en la implementación de políticas de seguridad en recursos compartidos Elaboración propia en base a experiencia previa en implementación de sistemas de archivos compartidos. 26

38 1. Computador del usuario 2. Servidor de DNS. La petición es enviada a través del puerto 53 TCP/UDP. 3. Recurso compartido. Puede ser una impresora conectada en Red, una unidad extraíble, archivos y carpetas, entre otros. El acceso a estos recursos compartidos se realiza a través del puerto 139 TCP/NetBIOS. 4. Servidor de Directorios MSAD. El acceso a este servidor se realiza por el puerto 636 TCP/ LDAPS. 5. Los componentes de red se encuentran interconectados a través de un Switch. Este tipo de implementaciones es conveniente de realizar en organizaciones donde cohabitan equipos de trabajo diferenciados que necesiten compartir información de manera segura. Es aquí donde se puede entregar conciencia de los peligros de los archivos sin protección con un ejemplo real de aplicación: En una mediana empresa dedicada a la creación y diseño de planos para la construcción, se acercó un cliente que solicitó una cotización para la realización de un trabajo y conectó su computador personal a la red de la empresa para revisar su correo electrónico. Como la empresa no contaba con mecanismos de autenticación y autorización, el supuesto cliente hurtó todos los archivos de los planos de la empresa, los cuales se encontraban en una carpeta compartida sin protección Sistemas de apoyo a la docencia y educación Los sistemas de apoyo a la docencia y educación entregan las bases para complementar o substituir la docencia en el aula, eliminando la necesidad de mantener espacios físicos para entregar o recibir la enseñanza. Como la cantidad de personas que trabajan o estudian en instituciones educacionales a menudo es elevado, especialmente en instituciones de educación superior, mantener y gestionar sistemas informáticos con esa cantidad de usuarios resulta ser una tarea que requiere bastante atención, por lo que cobra sentido la integración de sistemas de apoyo a la docencia y educación con sistemas de gestión de 27

39 identidades, delegando de esta manera la gestión, seguridad y manutención de las cuentas de usuarios a los sistemas de gestión de identidades. Este tipo de integraciones puede ser ejemplificada por una pequeña empresa de la Región de los Ríos que ofrezca, como servicio gestionado, una plataforma de apoyo a la docencia y educación a algún colegio, liceo o universidad que mantengan una base de datos de sus estudiantes y docentes, bastando solo conectar dicha plataforma con los usuarios existentes del plantel educacional. Las plataformas educacionales que soportan este tipo de integraciones con sistemas de gestión de identidades, generalmente tienen conectores que permiten integrar las plataformas con servidores compatibles con el protocolo LDAP para obtener la información de los usuarios. El siguiente ejemplo ilustra una implementación, realizada como consultor, de la plataforma para la creación de diseños de aprendizaje Learning Activity Management System (LAMS), con el servicio de directorios Microsoft Active Directory (MSAD), para una pequeña empresa de la región de los Ríos. Con respecto a LAMS, de acuerdo a su sitio web oficial [Lam13a], es una herramienta para el diseño, gestión y entrega de actividades de aprendizaje colaborativas. LAMS entrega a profesores un entorno de edición visual para la creación de secuencias de actividades de aprendizaje. Estas actividades pueden incluir una serie de tareas individuales, trabajos en grupos y actividades sobre la base de contenidos de aprendizaje y la colaboración. A nivel de tecnologías, según lo especificado en la Arquitectura de LAMS 2 [Lam13b] y como se aprecia en la figura 11, LAMS utiliza el servidor Web Apache como proxy para redirigir las consultas enviadas por el usuario, desde el navegador web, hacia el servidor de aplicaciones JavaBeans Open Source Software Application Server, más conocido como JBOSS, con el fin de ejecutar las aplicaciones internas de LAMS. Como interfaz hacia los datos, LAMS utiliza las librerías Hibernate para interactuar con bases de datos como MySQL, utilizando un conector JDBC. 28

40 Figura 11: Diagrama de tecnologías presentes en LAMS 12 La arquitectura funcional/lógica de la solución se puede apreciar en la figura 12 y se detalla a continuación: Figura 12: Arquitectura funcional/lógica para implementación de LAMS con MSAD El usuario (alumno, profesor, revisor, diseñador, entre otros) intenta acceder a un recurso protegido, como puede ser un curso o la creación de un nuevo diseño de aprendizaje. 12 Fuente: Elaboración propia en base a diagrama de tecnologías presentes en LAMS [Lam13b] 13 Fuente: Elaboración propia en base a experiencia previa en implementación de proyectos en sistemas de gestión de identidades. 29

41 2. LAMS inicia una petición de acceso a MSAD, enviando los detalles del usuario y la contraseña. 3. MSAD devuelve a LAMS la información del usuario, primeramente enviando si es que puede iniciar sesión en la plataforma (autenticación). Si es que puede iniciar sesión en la plataforma, MSAD envía la información de los roles y grupos del usuario. 4. Finalmente LAMS, envía la respuesta al usuario, entregando los accesos a los cuales el usuario tiene derecho. La arquitectura operacional/física se puede apreciar en la figura 13 y se detalla a continuación: 1. El usuario (alumno, profesor, revisor, diseñador, entre otros) intenta acceder al portal LAMS, a través de un navegador web, utilizando una conexión al puerto 8080 utilizando el protocolo HTTP. 2. La petición del usuario pasa por Internet y llega a la Capa de Seguridad, en donde la petición es inspeccionada primeramente por el Cortafuegos Institucional, en donde se decide si la petición sigue su curso validando los puertos de origen y destino. Si la petición es validada y aceptada por el cortafuegos, llega al sistema de prevención/detección de intrusos (IPS/IDS), donde se revisa si la petición es válida y no contenga ataques conocidos. 3. Si la petición fue validada y aceptada por la Capa de Seguridad, llega a la Capa Web en la Zona Pública. La petición llega al servidor de aplicaciones JBOSS, por el puerto TCP El servidor de aplicaciones reconoce que se está iniciando sesión, por lo que envía una petición, usando encriptación, al servidor MSAD utilizando el protocolo LDAPS, a través del puerto 636 TCP. 4. La petición llega al servidor MSAD, y este devuelve a LAMS la información del usuario, primeramente enviando si es que puede iniciar sesión en la plataforma (autenticación). Si es que puede iniciar sesión en la plataforma, MSAD envía la información de los roles y grupos del usuario. 5. Una vez que el usuario esta autenticado y autorizado puede acceder a la información de LAMS, que se guarda en una base de datos MySQL. LAMS se conecta al servidor de base datos utilizando el puerto 3306 TCP. 30

42 Figura 13: Arquitectura operacional para la implementación de LAMS con MSAD Fuente: Elaboración propia en base a experiencia como consultor en implementación de proyectos en sistemas de gestión de identidades. 31

43 La integración de sistemas de gestión de identidades con plataformas para apoyar la docencia y el aprendizaje permiten gestionar el ciclo de vida de las identidades digitales de los estudiantes, que comienza con la creación de las nuevas cuentas de usuarios al comenzar el año escolar y finaliza una vez que el estudiante se gradúa y/o desvincula de la institución, permitiendo de esta forma utilizar la plataforma educacional para lo que se diseñó: entregar apoyo a la educación, delegando la administración de los usuarios a los sistemas que fueron diseñados para ese propósito: sistemas de gestión de identidades Sistemas de misión crítica con tolerancia a fallos y alta disponibilidad Misión crítica es una expresión empleada en tecnologías de la información para simbolizar la importancia de la aplicación, ambiente o sistema. Cuando un ambiente es considerado de misión crítica, se intenta hacer todo lo posible para conservar el ambiente continuamente disponible. Si algo le pasa a este ambiente, los servicios se verán impactados, afectando directamente a los negocios o personas. Dicho ambiente debe estar construido para evitar interrupciones temporales, sin importar lo pequeño que sean, y para reducir la posibilidad de pérdida de datos. Usualmente los ambientes considerados como de misión crítica mantienen una disponibilidad del 99,89% anual, es decir, estos sistemas dejan de prestar sus funciones aproximadamente 10 horas al año [Hoc07]. Los servicios de misión crítica poseen la habilidad de entregar una capacidad permanente, independiente de la falla de uno o más de sus componentes, lo que se conoce como sistemas con tolerancia a fallos, lo que en la práctica es encontrado generalmente en la infraestructura de redes, sistemas de almacenamiento, bases de datos y servidores [Bro13]. El siguiente ejemplo ilustra la implementación de un sistema de gestión de identidades, realizada como consultor, que asegura tres diferentes aplicaciones Web: finanzas, recursos humanos y ventas. Al mantener conectadas tres aplicaciones vitales para la organización, el sistema de gestión de identidades se vuelve un sistema crítico, por esta razón, se realizó la implementación del sistema de gestión de identidades como 32

44 un sistema de misión critica, agregando componentes de alta disponibilidad y replicación de información. Las aplicaciones mencionadas están desplegadas en el servidor de aplicaciones Oracle Weblogic Server (WLS), el sistema de gestión de accesos utilizado fue Oracle Access Manager (OAM) y el servicio de directorios fue Oracle Internet Directory (OID). Se utilizó sincronización con el servicio de directorios MSAD en un ambiente de alta disponibilidad y la base de datos donde se aloja la información de OID y de los datos de OAM es una base de datos Oracle RAC. Este tipo de implementaciones es común apreciarlas en corporaciones multinacionales, que necesitan infraestructura replicada con el fin de tener tolerancia a fallos, alta disponibilidad de los servicios y cumplimiento de normas internacionales. La figura 14 muestra un diagrama de una implementación de un sistema de gestión de identidades para una solución que requiera de tolerancia a fallos y alta disponibilidad. Los detalles del diagrama se entregan a continuación: 1. El usuario envía una petición para acceder a alguna aplicación protegida (finanzas, recursos humanos o marketing). La petición es enviada a un servidor Web, usando el protocolo de comunicación HTTPS a través del puerto La petición del usuario pasa por Internet y llega a la Capa de Seguridad, en donde es examinada. La petición llega primeramente al Cortafuegos, en donde se decide si la petición sigue su curso validando los puertos de origen y destino, en este caso el destino es el puerto 443. Luego, llega al IPS/IDS, donde se revisa que la petición sea válida y que no contenga ataques conocidos por la base de datos del IPS/IDS. Posteriormente, llega al WAF, donde se revisa que la petición sea válida, analizando que no pertenezca al conjunto de ataques Web conocidos dentro de la base de datos del WAF. Finalmente, la petición llega al balanceador de carga, donde se despacha a un servidor Web. 3. Si la petición fue validada y aceptada por la Capa de Seguridad, entonces llega a la Capa Web. La petición llega desde el balanceador de carga, donde se elige un servidor web para enviar la petición. El servidor Web reconoce que la aplicación Web necesita de autenticación y autorización, por lo que se envía una petición a uno de los Servidores de Control de Accesos OAM. 33

45 4. Después de que la petición ha pasado por la Capa Web, llega al segmento de red conocido como Zona Privada pasando por un Cortafuegos, esto implica que los accesos a este segmento de red están restringidos a un limitado número de operaciones, con el fin de incrementar la seguridad y protección de la información. La petición llega a la capa de Aplicación, en esta capa hay dos servidores, cada uno contiene tres distintas aplicaciones de administración: servidor de aplicaciones Oracle WebLogic, servidor de control de accesos OAM, servidor de directorios OID. Cuando la petición llega al servidor de control de accesos, se envían dos peticiones: hacia la base de datos Oracle RAC, por el puerto 1521 TCP y hacia el servicio de directorios OID, por el puerto 636 TCP LDAPS. 5. Finalmente las peticiones llegan a la Capa de Directorios, la petición que va dirigida a la base de dados desde OAM, entrega la información de la configuración de las políticas de seguridad asociadas a la aplicación protegida. La petición que va hacia OID entrega la información de los usuarios y grupos que tiene asociado el usuario. Los dos servicios de directorios OID están conectados a una única base de datos Oracle RAC, entregando de esa manera alta disponibilidad en esa aplicación. Adicionalmente OID sincroniza parte de los usuarios desde MSAD utilizando Directory Information Platform (DIP). Los dos MSAD están sincronizados entre sí, lo que permite una replicación de la información en caso de que uno de los dos MSAD falle. 34

46 Figura 14: Diagrama de implementación de solución para el control de accesos en alta disponibilidad Fuente: Elaboración propia en base al documento Enterprise Deployment Guide de Oracle [Des12] 35

47 Controlar y asegurar los accesos a las aplicaciones permite que solo las personas que necesitan tener acceso a los contenidos puedan utilizar dichas aplicaciones. Esta implementación tiene importancia cuando la información es uno de los pilares fundamentales para la creación de valor en la empresa, y el hecho de no proteger dicha información podría tener consecuencias fatales para el éxito de la organización, ya sea en términos económicos, sociales o políticos. 36

48 4. METODOLOGÍA La real academia española [Rae01] define metodología como el conjunto de métodos que se siguen en una investigación científica, entendiendo como método, el modo de decir o hacer siguiendo un determinado orden. En ese contexto, es importante describir los métodos, el orden con que han sido realizados y las hipótesis que se plantean, ya que esto permitiría la validación y aceptación de la metodología expuesta en el presente trabajo. 4.1 Metodología de investigación El método de investigación que se utilizó en el trabajo de tesis fue el siguiente: 1. Se describieron los conceptos de arquitectura empresarial y sistemas de gestión de identidades con el fin de crear las bases teóricas de la investigación. 2. Se ilustraron casos de ejemplo que justificaron el uso de sistemas de gestión de identidades en las pequeñas y medianas empresas de la Región de los Ríos. 3. En base a una hipótesis, se creó la propuesta de metodología para precisar la necesidad de uso de los sistemas de gestión de identidades en las pequeñas y medianas empresas de la Región de los Ríos, utilizando ciertos criterios. 4. Se utilizó la metodología en una pequeña empresa de la Región de los Ríos con el fin de verificar la hipótesis y analizar la efectividad de la propuesta. 5. Para finalizar, se entregaron conclusiones y recomendaciones acerca de la propuesta de metodología para precisar la necesidad de uso de los sistemas de gestión de identidades en las pequeñas y medianas empresas de la Región de los Ríos. 37

49 4.2 Hipótesis Como se ha mencionado anteriormente, la problemática a resolver por la propuesta de metodología apunta a precisar la necesidad de uso de sistemas de gestión de identidades en pequeñas y medianas empresas de la Región de los Ríos. Con el fin de precisar dicha necesidad se utilizó la siguiente hipótesis: Existen criterios para precisar el uso de sistemas de gestión de identidades en pequeñas y medianas empresas de la Región de los Ríos. Los criterios que se emplearon para precisar dicho uso se detallan a continuación y están basados en la definición de sistemas de gestión de identidades que fue revisada con anterioridad en el capítulo dos: 1. Cumplir con políticas organizacionales en el área de Tecnologías de la Información: Las organizaciones intentan estandarizar sus procesos de negocio utilizando políticas institucionales. Un ejemplo de la aplicación de una política organizacional de seguridad es que todas las contraseñas de los sistemas de información de la organización cumplan con un largo mínimo de diez caracteres, utilizando por lo menos un número, una letra mayúscula, una minúscula y un carácter especial. 2. Consolidar la información de una entidad: Este criterio plantea a la necesidad de consolidar la información en el caso de que numerosos repositorios de datos contengan información de la entidad. Por ejemplo, en el caso de que una entidad tenga información en diferentes fuentes, existe la posibilidad de que dicha entidad tenga información inconsistente y/o desactualizada, pudiendo perjudicar al negocio. 3. Gestionar la identidad de una entidad: Aquí se propone la necesidad que tiene la empresa de gestionar el ciclo de vida de las identidades digitales. Ejemplos de las tareas que conlleva gestionar las identidades son la creación, modificación y eliminación de una identidad. 38

50 4. Controlar los accesos a recursos organizacionales: Para revisar este criterio es necesario responder a la siguiente pregunta: Es necesario que en esta organización se proteja algún recurso tecnológico?, Es posible que todos los empleados puedan hacer uso de todos los recursos en la misma medida? Ejemplos de recursos organizacionales pueden ser documentos, aplicaciones, impresoras, sistemas corporativos, entre otros. 5. Inicio único de sesión: Este criterio apunta a la necesidad que tiene la empresa de que para utilizar sus recursos tecnológicos, el usuario pueda acceder sin la necesidad de ingresar nuevamente su contraseña en cada uno de esos recursos. El inicio único de sesión es útil cuando la cantidad de aplicaciones que tiene la empresa es numeroso, dificultando a las personas el acceso a las aplicaciones, ya que estas tendrían que acceder a cada una de ellas con su usuario y contraseña. 4.3 Propuesta de Metodología para sistemas de gestión de identidades La siguiente propuesta entrega los lineamientos acerca de lo que se tiene que considerar con el fin de determinar si es necesario aplicar sistemas de gestión de identidades en pequeñas y medianas empresas de la región de los Ríos. Conviene aclarar que la metodología se debe ajustar a cada organización dependiendo de las necesidades del rubro o negocio Modelar la Arquitectura empresarial En el capítulo dos se revisó el concepto de arquitectura empresarial, describiendo dos marcos de trabajo que permiten crear una arquitectura empresarial. En la metodología se usarán estos conceptos. Primeramente, fue necesario crear las vistas empresariales del marco de trabajo de Zachman, con el fin de representar las diferentes perspectivas de la empresa, utilizando para ello la matriz de 6x6 que fue ilustrada en la Tabla 1 del capítulo dos. Esta matriz ayudó a entender el contexto global de la empresa, considerando todos los aspectos de la infraestructura de tecnologías de la información de la organización. 39

51 Posteriormente, se realizó una iteración del ciclo de ADM de TOGAF, que es ilustrado en la Figura 1 del capítulo 2, lo que permitió crear la arquitectura empresarial base. Con la arquitectura empresarial creada, es posible seguir con el paso siguiente: reconocimiento de los factores críticos de éxito de la organización Identificar factores críticos de éxito del sector De acuerdo Bhattacharyya [Bha12], los factores críticos de éxito son las áreas clave identificadas para el logro de las metas organizacionales y son entregados por el mercado. Por ejemplo, en el área de la minería, los factores críticos de éxito son la seguridad de las personas y la calidad de los trabajos realizados. En este punto, ya se posee la arquitectura empresarial de la organización, por lo que será necesario reconocer los factores críticos de éxito del sector utilizando para ello la arquitectura creada en el paso anterior. Si los factores críticos de éxito del sector dependen de la seguridad de la información, necesitando de identificación y autorización para acceder a recursos organizacionales, cumplir con estándares internacionales o garantizar la identidad de una entidad, entonces se necesitan de sistemas de gestión de identidades. Es interesante analizar este punto con un ejemplo: un banco necesita de la identificación y autorización de las personas que utilizan sus servicios, esto forma parte del negocio y de los factores críticos de éxito. Si las plataformas de gestión de identidades dejan de funcionar, el negocio se ve impactado profundamente, ya que los usuarios no podrían ingresar a las plataformas bancarias, haciendo necesario contar con un sistema de gestión de identidades en un ambiente de alta disponibilidad. Por contraejemplo es posible mencionar a una empresa que se dedique a la venta de comida rápida al por menor. En dicho sector los sistemas de gestión de identidades no aportan valor en las ventajas competitivas del segmento de mercado al cuál se está apuntando. 40

52 4.3.3 Cumplir con los criterios para el uso de sistemas de gestión de identidades Al comenzar este capítulo se entregaron una lista de cinco criterios que justifican el uso de los sistemas de gestión de identidades: Cumplir con políticas organizacionales en el área de Tecnologías de la Información. Consolidar la información de una entidad. Gestionar la identidad de una entidad. Controlar los accesos a recursos organizacionales. Inicio único de sesión. Por lo menos uno de estos criterios debe cumplirse para continuar con la metodología. Cabe destacar que estos criterios no tienen que ver con los factores de éxito del sector, sino más bien con la utilidad de los sistemas de gestión de identidades. Los sistemas de gestión de identidades deben ser capaces de entregar valor a la empresa y cumplir con la funcionalidad para los cuales fueron diseñados Analizar la cantidad de usuarios Para finalizar la metodología para determinar el uso de los sistemas de gestión de identidades, fue necesario analizar la cantidad de usuarios que utilizan los servicios tecnológicos de la organización. Cabe destacar que a mayor cantidad de usuarios, mayor es la necesidad de uso de sistemas de gestión de identidades, siendo criterio de la empresa determinar el número para decidir si vale la pena implementar este tipo de sistemas en la organización. De acuerdo a la experiencia, con más de doscientos cincuenta usuarios conviene utilizar un sistema de gestión de identidades, aunque es posible implementar este tipo de sistemas cuando hay menos usuarios, siempre y cuando los factores críticos de éxito, determinados en el punto anterior, indiquen que la seguridad agrega valor al negocio. 41

53 4.4 Análisis y aplicación de la metodología Como se puede apreciar en la figura 15, los pasos para determinar si es necesario el uso de sistemas de gestión de identidades son resumidos en cuatro fases: 1. Modelar la Arquitectura empresarial. 2. Identificar los factores críticos de éxito 3. Cumplir con los criterios para el uso de sistemas de gestión de identidades 4. Analizar la cantidad de usuarios. 2. Identificar Factores Críticos de Éxito 3. Cumplir criterios de uso 1. Modelar la Arquitectura Empresarial Sistemas de Gestión de Identidades 4. Analizar la Cantidad de Usuarios Figura 15: Factores determinantes para la implementación de sistemas de gestión de identidades. 16 Con el fin de ilustrar y analizar el uso de la metodología, se utilizó una pequeña empresa de la región de los Ríos. El rubro de la empresa es el de servicios y asesorías en informática, esta empresa se dedica a ayudar a instituciones educacionales a mejorar mediante las tecnologías de la información los procesos de enseñanza y aprendizaje. El detalle de la empresa puede ser revisado en el Anexo B de este documento y la aplicación de la metodología se describe a continuación: 16 Fuente: Elaboración propia en base a los factores que determinan la necesidad de uso de sistemas de gestión de identidades. 42

54 4.4.1 Paso 1. Modelar Arquitectura Empresarial El primer paso que se siguió fue el de modelar la arquitectura empresarial, para esto se crearon las vistas empresariales del marco de trabajo de Zachman, con el fin de representar las diferentes perspectivas de la empresa. El resultado se puede apreciar en la matriz de 6x6 que se ilustra en la Tabla 2. Esta matriz ayudó a entender el contexto global de la empresa, considerando los aspectos de la infraestructura de tecnologías de la información de la organización. Tabla 2: Vistas empresariales del marco de trabajo de Zachman aplicado a la empresa 17. Posteriormente, se realizó una iteración del ciclo de ADM de TOGAF, lo que permitió crear la arquitectura empresarial base. Los detalles se describen a continuación: Fase A Visión de la Arquitectura: El motivo de la creación de la arquitectura es para determinar si es necesaria la implementación de sistemas de gestión de identidades. En esta fase fue necesario realizar un diagrama de la cadena de valor de la empresa con el fin de clarificar los actores presentes en el sector: proveedores, factores externos, competidores y clientes. Este diagrama se puede apreciar en la figura Fuente: Elaboración propia en base a la aplicación del marco de trabajo de Zachman en una empresa de la región de los Ríos. 43

55 Figura 16: Diagrama de la cadena de Valor del sector. 18 Fase B Arquitectura del negocio: aquí se concentró el desarrollo de la arquitectura empresarial, que está formada por los requerimientos, las métricas del negocio y la identificación de las capacidades necesarias en la arquitectura. Requerimientos del negocio: el negocio de la empresa es la instalación y configuración de plataformas educacionales, es decir, apoyar de manera tecnológica a la enseñanza y el aprendizaje. Desde la perspectiva del estudiante, se inicia sesión en la plataforma educacional, lo que permite acceder a los cursos que actualmente está cursando. Desde la perspectiva del profesor, debe tener acceso a la plataforma con el fin de gestionar a sus estudiantes y entregar contenidos digitales de sus cursos. Tanto los estudiantes como los profesores no deben tener acceso a los contenidos de otras asignaturas que no les corresponda. Métricas del negocio: La métrica del negocio es la satisfacción del cliente por los productos y servicios entregados, esta métrica puede ser medida en base a una encuesta de satisfacción por los servicios y productos. Capacidades de la arquitectura: la arquitectura tecnológica debe ser capaz de escalar en caso de ser necesario, por ejemplo con el aumento de la cantidad de usuarios. Adicionalmente, debe ser capaz de soportar la alta disponibilidad de los servicios. 18 Fuente: Elaboración propia en base a un análisis de la cadena de valor del sector de servicios TI que apoyan a los servicios de educación. 44