CLÁUSULA DE CESIÓN DE DERECHO DE PUBLICACIÓN DE TESIS Yo………………………………………………………………….……………………............ autor/a de la tesis titulada: PROPUESTA DE SERVICIO BASADO EN SOFTWARE LIBRE Y ESTÁNDARES ABIERTOS PARA LA INTEROPERABILIDAD DE ADMINISTRACIÓN DE USUARIOS CON SISTEMAS MONOLÍTICOS mediante el presente documento, declaro que la obra mencionada es de mi exclusiva autoría y producción. Esta tesis ha sido elaborada como uno de los requisitos previos para la obtención del título de: “Magíster en Software Libre” en la Universidad Andina Simón Bolívar, Sede Central Sucre. Cesión de Derechos: 1. Derechos Cedidos: A partir de la fecha de la defensa de grado, cedo a la Universidad Andina Simón Bolívar, Sede Central Sucre, los derechos exclusivos de reproducción, comunicación pública, distribución y divulgación de la obra. La Universidad está autorizada a utilizar esta obra por cualquier medio, actualmente conocido o que se desarrolle en el futuro, siempre y cuando dicha utilización no se realice con fines de lucro. Esta cesión incluye la reproducción total o parcial en formatos virtual, electrónico, digital, u óptico, así como su uso en red local e Internet. 2. Responsabilidades del Autor: Declaro que, en caso de presentarse cualquier reclamación o demanda por parte de terceros respecto de los derechos de autor de la obra mencionada, asumiré toda la responsabilidad legal frente a dichos terceros y frente a la Universidad, incluyendo, sin limitación, la defensa de tales reclamaciones y el mantenimiento de la Universidad indemne frente a las mismas. 3. Entrega de Ejemplares: En esta fecha, entrego a la biblioteca de la Universidad un ejemplar de la obra y sus anexos, en formatos impreso y digital o electrónico. Fecha. …………………… Firma: ………………………………………… UNIVERSIDAD ANDINA SIMÓN BOLÍVAR SEDE CENTRAL Sucre – Bolivia MAESTRÍA EN SOFTWARE LIBRE PROPUESTA DE SERVICIO BASADO EN SOFTWARE LIBRE Y ESTÁNDARES ABIERTOS PARA LA INTEROPERABILIDAD DE ADMINISTRACIÓN DE USUARIOS CON SISTEMAS MONOLÍTICOS Tesis presentada para optar al Grado Académico de Magíster en Software Libre MAESTRANTE: WINDSOR ALVAREZ DAVILA Sucre – Bolivia 2024 UNIVERSIDAD ANDINA SIMÓN BOLÍVAR SEDE CENTRAL Sucre – Bolivia MAESTRÍA EN SOFTWARE LIBRE PROPUESTA DE SERVICIO BASADO EN SOFTWARE LIBRE Y ESTÁNDARES TABIERTOS PARA LA INTEROPERABILIDAD DE ADMINISTRACIÓN DE USUARIOS CON SISTEMAS MONOLÍTICOS Tesis presentada para optar al Grado Académico de Magíster en Software Libre MAESTRANTE: WINDSOR ALVAREZ DAVILA TUTOR: MAURICIO CANSECO TORRES Sucre – Bolivia 2024 DEDICATORIA Y AGRADECIMIENTOS Dedicatoria A Dios Por su amor incondicional, y bendición sobre mí y toda mi familia. A mi esposa Mariela Por haberme dado el apoyo, motivación y la fuerza para poder concluir esta etapa de mi vida y empezar otras nuevas. A mi hijito Vincito Por su carismática sonrisa, que me llena de fuerzas y energías, por su amor y por haberme dado la dicha de vivir la experiencia de ser padre. A mis familiares A mi padre Windsor, mi madre Marcela y mi hermano Marcelo por su eterno apoyo y cariño, los amo mucho. Agradecimientos A Dios por darme la oportunidad de seguir adelante. A toda mi familia por estar conmigo en las buenas y las malas. A mi tutor por la paciencia y sabiduría proporcionada de manera incondicional. A mis tribunales por el tiempo dedicado en la corrección y mejoras del presente trabajo de investigación. A los docentes por el tiempo brindado en compartir conocimiento y experiencias. A mis compañeros por formar un equipo tan lindo que siempre será recordado A la Universidad Andina Simón Bolívar por gestionar el programa, acogerme como su estudiante. i RESUMEN Los sistemas informáticos en las instituciones se convirtieron en procedimientos necesarios para optimizar el funcionamiento y garantizar la continuidad de negocio; así como también la mayoría de las empresas o instituciones contemplan en su funcionamiento la aplicabilidad de diferentes tipos de sistemas para cada proceso. El objetivo del presente estudio es de proponer un servicio basado en software libre y estándares abiertos para la interoperabilidad de un módulo de administración de usuarios con los diferentes sistemas monolíticos. Para ello se utilizó la metodología de investigación tecnológica, con alcance exploratorio, de enfoque positivista y con los métodos analítico y demostración en base a una investigación cuasi experimental; donde se realizó un análisis respecto a indicadores, directrices y características propias de las herramientas a ser utilizadas para la elaboración de la propuesta. Finalmente, se elaboró un cuasi experimento como propuesta del servicio, el cual fue aceptado, por la facilidad y rapidez de interoperabilidad con diferentes microservicios, el cual podrá ser integrado a los diferentes sistemas monolíticos que lo requieran para generalizar y mejorar la administración de usuarios. ii ABSTRACT Computer systems in institutions became necessary procedures to optimize operations and ensure business continuity; as well as most of the companies or institutions contemplate in their operation the applicability of different types of systems for each process. The objective of this study is to propose a service based on free software and open standards for the interoperability of a user management module with the different monolithic systems. For this, the technological research methodology was used, with an exploratory scope, a positivist approach and with analytical and demonstration methods based on a quasi-experimental investigation; where an analysis was carried out regarding indicators, guidelines and characteristics of the tools to be used for the preparation of the proposal. Finally, a quasi-experiment was developed as a service proposal, which was accepted due to the ease and speed of interoperability with different microservices, which can be integrated into the different monolithic systems that require it to generalize and improve the management of services. users. iii ÍNDICE CAPÍTULO I. INTRODUCCIÓN .................................................................................... 1 1.1 Antecedentes............................................................................................................ 1 1.2 Planteamiento del Problema .................................................................................... 3 1.2.1 Situación Problemática ..................................................................................... 3 1.2.2 Situación Deseada ............................................................................................. 3 1.2.3 Formulación del Problema ................................................................................ 4 1.3 Objetivos ................................................................................................................. 4 1.3.1 Objetivo General ............................................................................................... 4 1.3.2 Objetivo Específico .......................................................................................... 4 1.4 Alcances y delimitaciones ....................................................................................... 4 1.5 Justificación ............................................................................................................. 5 1.6 Revisión del Estado del Arte ................................................................................... 7 1.7 Metodología de la Investigación ............................................................................. 8 1.7.1 Técnicas ............................................................................................................ 8 1.7.2 Métodos ............................................................................................................ 8 1.7.3 Instrumentos ..................................................................................................... 8 CAPÍTULO II. MARCO TEÓRICO .............................................................................. 10 2.1 Interoperabilidad............................................................................................... 10 2.2 Microservicios .................................................................................................. 11 2.2.1 Arquitectura Monolítica ............................................................................ 11 2.2.2 Arquitectura Microservicios ........................................................................... 13 2.2.3 Microservicios Poliglotas ............................................................................... 21 2.3 Protocolos de autenticación ................................................................................... 22 2.4 Seguridad en servicios ........................................................................................... 24 2.5 Seguridad en Autenticación ................................................................................... 27 iv 2.6 Software Libre ....................................................................................................... 30 2.6.1 Las cuatro libertades del Software Libre ........................................................ 31 2.6.2 El manifiesto de GNU .................................................................................... 31 2.6.3 Código Abierto ............................................................................................... 32 2.6.4 Estándar Abierto ............................................................................................. 32 2.6.5 Licencias de software libre ............................................................................. 33 2.7 Base de datos PostgreSQL .................................................................................... 35 2.7.1 Características ................................................................................................. 35 2.7.2 Funciones ........................................................................................................ 37 2.7.3 Ventajas .......................................................................................................... 38 2.8 Docker ................................................................................................................... 38 2.9 Golang ................................................................................................................... 42 2.9.1 Creadores ........................................................................................................ 42 2.9.2 Diferencias de Go respecto a otros lenguajes ................................................. 42 2.9.3 Empresas que usan Go .................................................................................... 42 2.9.4 Ventajas de Go ................................................................................................ 43 2.9.5 Desventajas de Go .......................................................................................... 43 2.9.6 Excepciones .................................................................................................... 44 2.9.7 POO en Go ...................................................................................................... 44 2.9.8 Gorm con Go .................................................................................................. 45 2.9.9 Gin con Go ...................................................................................................... 46 CAPÍTULO III. ANÁLISIS DE LAS HERRAMIENTAS ............................................ 48 3.1 Tecnologías analizadas ...................................................................................... 48 3.2 Identificación de indicadores de evaluación para la aplicación o integración con el cuasi experimento. ............................................................................................... 56 3.3 Directrices y lineamientos para la creación del servicio.................................... 56 v 3.4 Análisis de herramientas de la institución de estudio. ....................................... 58 CAPÍTULO IV. DESARROLLO ................................................................................... 59 4.1 Diseño del experimento ......................................................................................... 59 4.2 Variables o entidades del experimento .................................................................. 60 4.3 Diccionario de datos .............................................................................................. 60 4.3.1 Historias de usuario ........................................................................................ 65 4.3.2 Caso de estudio ............................................................................................... 67 4.4 Descripción del diseño experimental como propuesta de servicio ........................ 67 4.5 Desarrollo del cuasi experimento .......................................................................... 68 4.5.1 Despliegue de PostgreSQL en Docker ........................................................... 69 4.5.2 Diseño de entidades Code-First y conexión a la base de datos ...................... 70 4.5.3 Configuración JWT ........................................................................................ 71 4.5.4 Configuración OTP ......................................................................................... 73 4.5.5 Interoperabilidad con Email Service .............................................................. 74 4.5.6 Interoperabilidad con Zeus Pro ....................................................................... 75 4.5.7 Interoperabilidad con Segip ............................................................................ 76 4.5.8 Controladores .................................................................................................. 77 4.5.9 Rutas ............................................................................................................... 78 4.5.10 Middlewares ................................................................................................. 80 4.5.11 Pruebas de Registro sin doble factor y Login ............................................... 80 4.5.12 Pruebas de Login Two Factor ....................................................................... 84 4.5.13 Asignación de sistemas al usuario, creación de roles y permisos ................. 88 4.5.14 Arquitectura de módulo de usuarios de sistema Zeus Pro ............................ 93 4.5.15 Integración del servicio propuesto con el Login del sistema Zeus Pro ........ 93 4.5.16 Análisis de resultados ................................................................................... 98 CAPÍTULO V. CONCLUSIONES ............................................................................... 100 vi LINEAS DE INVESTIGACIÓN FUTURAS ............................................................... 101 REFERENCIAS BIBLIOGRÁFICAS .......................................................................... 102 GLOSARIO .................................................................................................................. 104 ANEXOS ...................................................................................................................... 107 vii ÍNDICE DE FIGURAS FIGURA 1 ARQUITECTURA MONOLÍTICA .......................................................................... 12 FIGURA 2 ARQUITECTURA MICRO SERVICIOS ................................................................... 17 FIGURA 3 ARQUITECTURA MÚLTIPLE O POLIGLOTA .......................................................... 22 FIGURA 4 PROTOCOLO OPENID CONNECT ....................................................................... 23 FIGURA 5 CICLO DE VIDA DE JWT.................................................................................... 27 FIGURA 6 LICENCIAS DE SOFTWARE LIBRE ...................................................................... 35 FIGURA 7 INFRAESTRUCTURA DOCKER ............................................................................ 40 FIGURA 8 DIFERENCIA ENTRE VMS Y DOCKER ................................................................ 41 FIGURA 9 DISEÑO DE LA BASE DE DATOS ......................................................................... 59 FIGURA 10 DISEÑO DE SERVICIO PROPUESTO ARCONTE ................................................... 68 FIGURA 11 ARQUITECTURA DE ARCHIVOS ARCONTE ....................................................... 69 FIGURA 12 DOCKER COMPOSE PARA LEVANTAR POSTGRES ............................................. 69 FIGURA 13 DOCKER DE ARCONTEDB EN DOCKER DESKTOP ........................................... 70 FIGURA 14 DOCKER DE ARCONTEDB EN DOCKER PS ....................................................... 70 FIGURA 15 MODELO DE ARCONTE ................................................................................... 70 FIGURA 16 CONEXIÓN A LA BASE DE DATOS .................................................................... 71 FIGURA 17 GENERACIÓN DEL TOKEN BEARER ................................................................. 71 FIGURA 18 VALIDACIÓN DEL TOKEN BEARER .................................................................. 72 FIGURA 19 FORMA DE APLICACIÓN DEL MIDDLEWARE DE AUTORIZACIÓN ....................... 72 FIGURA 20 FUNCIÓN MIDDLEWARE PARA AUTORIZACIÓN ............................................... 72 FIGURA 21 GENERACIÓN DEL SECRETKEY Y ENVIÓ AL EMAIL DEL USUARIO ................... 73 FIGURA 22 VALIDACIÓN DEL CÓDIGO GENERADO POR LA APLICACIÓN ............................ 73 FIGURA 23 MODELO PARA BODY DEL SERVICIO DE CORREO .......................................... 74 FIGURA 24 FUNCIÓN DE ENVIÓ DE CORREO ...................................................................... 74 FIGURA 25 RESPUESTA DEL SERVICIO DE ZEUS ................................................................ 75 FIGURA 26 FUNCIÓN DE INTEROPERABILIDAD CON ZEUS SERVICE ................................... 75 FIGURA 27 FUNCIÓN DE INTEROPERABILIDAD CON SEGIP ................................................ 76 FIGURA 28 EJEMPLO RESPUESTA SERVICIO DE SEGIP ....................................................... 77 FIGURA 29 CONTROLADORES DE ARCONTE ..................................................................... 77 FIGURA 30 RUTAS DEFINIDAS EN ROUTE.GO..................................................................... 78 FIGURA 31 FUNCIÓN DE INICIALIZACIÓN DEL SERVIDOR WEB ......................................... 78 viii FIGURA 32 PUERTO DEL SERVICIO CORRIENDO ................................................................ 79 FIGURA 33 MIDDLEWARES DE ARCONTE ......................................................................... 80 FIGURA 34 MÉTODO USE DE GIN QUE RECIBE MIDDLEWARE ........................................... 80 FIGURA 35 CREACIÓN DE PERSONA Y USUARIO ............................................................... 81 FIGURA 36 SERVICIO DE CONSULTA DE USUARIO ............................................................. 82 FIGURA 37 RESPUESTA DE CREDENCIALES INCORRECTAS. ............................................... 83 FIGURA 38 CORREO DE LLAVE SECRETA TWO-FACTOR ................................................... 84 FIGURA 39 GOOGLE AUTENTICADOR CON EL CÓDIGO PARA ARCONTE ............................ 85 FIGURA 40 SERVICIO DE LOGIN CON TWOFACTOR ........................................................... 86 FIGURA 41 RESPUESTA LOGIN TWOFACTOR .................................................................... 87 FIGURA 42 RESPUESTA LOGIN TWOFACTOR (CONTINUACIÓN) ......................................... 87 FIGURA 43 RESPUESTA LOGIN TWOFACTOR (CONTINUACIÓN) ......................................... 88 FIGURA 44 CREACIÓN DE PERMISO .................................................................................. 89 FIGURA 45 CREACIÓN DE UN ROL .................................................................................... 90 FIGURA 46 CREACIÓN DE SISTEMA .................................................................................. 91 FIGURA 47 ASIGNACIÓN DE SISTEMAS Y ROLES AL USUARIO ............................................ 92 FIGURA 48 ARQUITECTURA SISTEMA ZEUS PRO .............................................................. 93 FIGURA 49 DIAGRAMA DE SECUENCIA DE INTEGRACIÓN .................................................. 94 FIGURA 50 MODELO DE LOGIN MODIFICADO PARA LA INTEGRACIÓN DEL SERVICIO PROPUESTO ............................................................................................................... 94 FIGURA 51 VISTA DE LOGIN MODIFICADA DE ZEUS PRO ................................................... 95 FIGURA 52 DTO LOGIN PARA REQUEST ............................................................................ 95 FIGURA 53 DTO LOGIN PARA RESPONSE .......................................................................... 96 FIGURA 54 MÉTODO LOGIN INTEGRADO CON EL SERVICIO PROPUESTO ............................ 96 FIGURA 55 RESULTADO DE UNA AUTENTICACIÓN EXITOSA .............................................. 97 FIGURA 56 INTEGRACIÓN CON ZEUS PRO OFICINAS ......................................................... 98 FIGURA 57 API GATEWAY PARA LÍNEAS FUTURAS ......................................................... 101 ix ÍNDICE DE TABLAS TABLA 1 VENTAJAS Y DESVENTAJAS DE OTP .................................................................. 30 TABLA 2 ANÁLISIS DE MICROSERVICIOS CON INDICADORES ............................................. 48 TABLA 3 COMPARACIÓN MICROSERVICIOS Y MONOLÍTICO EN BASE A INDICADORES ....... 51 TABLA 4 VENTAJAS E INCONVENIENTES DE PROTOCOLOS DE AUTENTICACIÓN ............... 52 TABLA 5 VENTAJAS Y DESVENTAJAS DE SEGURIDAD EN SERVICIOS ................................. 53 TABLA 6 VENTAJAS Y DESVENTAJAS DE SEGURIDAD EN AUTENTICACIÓN ........................ 55 TABLA 7 INDICADOR - DIRECTRIZ O CARACTERÍSTICA DESEADA ..................................... 57 TABLA 8 TABLA DE VALORES DE CUMPLIMIENTO............................................................. 57 TABLA 9 DICCIONARIO DE DATOS. ................................................................................... 60 TABLA 10 HISTORIA DE USUARIO - ADMINISTRACIÓN DE USUARIOS ................................ 66 TABLA 11 HISTORIA DE USUARIO - REGISTRO DE USUARIOS, ROLES, PERMISOS ............... 66 TABLA 12 HISTORIA DE USUARIO - LOGIN DE USUARIOS .................................................. 66 TABLA 13 VALORES DE CUMPLIMIENTO LLENADOS SEGUN ANÁLISIS ............................... 99 1 CAPÍTULO I. INTRODUCCIÓN 1.1 Antecedentes Interoperabilidad es una aproximación para unir requisitos de sistemas futuros a través de la integración de sistemas, es la formación de un “sistema de sistemas”, al interconectar componentes aislados (stand-alone) (Young, 2002). “La interoperabilidad entre sistemas no incluye solamente la habilidad de los sistemas para intercambiar información, sino también la capacidad de interacción y la ejecución de tareas conjuntas”. (Pitoura, 1997). Por tanto, el objetivo es crear un “sistema de sistemas” que no provea solamente interconectividad entre sistemas, sino que logre una unión de sistemas interoperables (Wileden, 1991) Una primera dificultad para lograr la interoperabilidad entre componentes heterogéneos de una unión de sistemas es que estos se suelen desarrollar independientemente, sin ningún requisito para interoperar. Así, los sistemas tienen diversas arquitecturas, plataformas de hardware, sistemas operativos, lenguajes de máquina y modelos de datos, con la dificultad de volver a desarrollar un nuevo sistema usando los requisitos consolidados de los diferentes componentes de los sistemas; y, además, una arquitectura, plataforma de hardware, sistema operativo y lenguaje de equipo común (una aproximación prohibitiva por el costo). Lo anterior obliga la concepción de un medio para lograr la meta de interoperabilidad de componentes con el presupuesto dado. “La literatura especializada presenta algunas opciones empleadas para superar estas limitaciones”. (Zapata & Gonzales Calderon, 2009) El gobierno del Estado Plurinacional de Bolivia promulgo el Decreto Supremo N° 2514 de 9 de septiembre de 2015, en el Parágrafo I de su Artículo 19 establece que la AGETIC coordinará con las entidades del sector público la implementación de servicios de interoperabilidad de Gobierno Electrónico, así como los datos e información que deben estar disponibles. También el pleno del Consejo de Tecnologías de Información y Comunicación del Estado Plurinacional de Bolivia aprueba el 7 de septiembre de 2017, el documento técnico Lineamientos para la Implementación de Servicios de Interoperabilidad en las Entidades del Sector Público, en miras al Gobierno Electrónico que como fin principal tiene la simplificación de trámites del ciudadano, como indica el 2 Decreto Supremo N° 3525, de 4 de abril de 2018, establece en el Parágrafo II de su Artículo 12 que para facilitar la realización de trámites a la ciudadanía, las entidades públicas, en el marco de su normativa específica, deberán intercambiar entre ellas datos e información mediante interoperabilidad. Los mecanismos y condiciones de publicación y acceso a los servicios de interoperabilidad serán establecidos por el Ente Rector de Gobierno Electrónico y Tecnologías de Información y Comunicación. Es importante mencionar que el trabajo de investigación no es ajeno a los tres planes institucionales de tecnologías de la información y comunicación propuestos por el gobierno central que son el Plan de implementación de Software Libre y Estándares Abiertos (PISLEA), Plan de Implementación de Gobierno Electrónico (PIGE), Plan de Implementación de Seguridad de la Información (PISI). El Decreto Supremo N° 1793 establece como principios para el desarrollo y uso de aplicaciones informáticas en las entidades públicas, la soberanía tecnológica, seguridad informática y la descolonización del conocimiento. En los Parágrafos I y II del Artículo 17 del mismo Decreto Supremo, se establecen como objetivos del Gobierno Electrónico: I. Modernizar y transparentar la gestión pública, otorgando servicios y atención de calidad a la ciudadanía, garantizando el derecho a la información, así como contribuir a la eficiencia y eficacia de los actos administrativos del gobierno, mediante el uso de las TIC y otras herramientas. II. Generar mecanismos tecnológicos de participación y control social por parte de los ciudadanos, organizaciones sociales y pueblos y naciones indígena originario campesinos. El Decreto Supremo N° 27330, Simplificación de Trámites, de 31 de enero de 2004, declara como prioridad nacional e interés público la Simplificación de Trámites, con la finalidad de agilizar, optimizar tiempos y reducir costos de los mismos. En este sentido el presente trabajo de investigación intenta abordar el tema de la interoperabilidad con sistemas monolíticos de diferentes arquitecturas y tecnologías para que estos puedan realizar una interoperabilidad exitosa con un único módulo de administración de usuarios. 3 1.2 Planteamiento del Problema 1.2.1 Situación Problemática Se puede observar que las diferentes empresas o instituciones en cuanto al desarrollo de sus sistemas están basadas en arquitectura monolítica, ya que dichos sistemas cuentan con una gama completa de todo tipo de funcionalidad, lo cual hace que el mantenimiento y operatividad sea costosa, es importante hacer notar que en el ámbito empresarial como institucional, la burocracia en los procesos viene siendo un problema recurrente. Otro problema es que existen instituciones que poseen sistemas con software privativo, siendo este un indicador de costos altos en la adquisición de diferentes tipos de licencias. Otro problema es la no existencia de normas o políticas de interoperabilidad entre sistemas propios de las instituciones. Para poder tener una interoperabilidad con agentes externos es recomendable haber realizado previamente interoperabilidad dentro de la empresa o institución, de esta manera la retroalimentación será mejor aprovechada y la experiencia adquirida mejor aplicada. Los sistemas monolíticos, casi en su totalidad poseen un módulo propio de administración de usuarios, lo cual es un problema complejo debido a que se estaría duplicando información de los usuarios. Con varios usuarios en diferentes sistemas para una persona, se genera otro problema de seguimiento institucional ya que en el momento de reincorporación o cesación del funcionario se tendrá que realizar la revisión en todos los sistemas donde esa persona tuvo un usuario, ya sea para dar de baja o realizar cambio o actualización de roles o permisos. 1.2.2 Situación Deseada Es la de poder proponer un servicio de interoperabilidad con Software Libre y estándares abiertos de acuerdo a diferentes lineamientos vigentes del país, validando dicha investigación con la administración de usuarios como un módulo o servicio único interoperable con los sistemas monolíticos adaptables. 4 1.2.3 Formulación del Problema ¿Es posible establecer un mecanismo basado en software libre y estándares abiertos que permita lograr interoperabilidad de un módulo de administración de usuarios con sistemas monolíticos aplicado en el Órgano Judicial en el periodo de la gestión 2022? 1.3 Objetivos 1.3.1 Objetivo General Proponer un servicio basado en software libre y estándares abiertos para la interoperabilidad de un módulo de administración de usuarios con los diferentes sistemas monolíticos del Órgano Judicial en el periodo de la gestión 2022. 1.3.2 Objetivo Específico 1. Analizar las ventajas y desventajas de una arquitectura monolítica frente a la arquitectura de microservicios con el propósito de poder comparar ambas arquitecturas para una mejor aplicabilidad en la investigación. 2. Evaluar la arquitectura de microservicios y los diferentes protocolos o métodos de autenticación con el propósito de contar con una arquitectura y protocolos acordes a un módulo de autenticación. 3. Diseñar la estructura del cuasi experimento para que cumpla con las características de un servicio que contenga los usuarios de diferentes sistemas con el propósito de demostrar que la integración de usuarios descentralizados es una solución acorde al objetivo general. 4. Desarrollar la investigación cuasi-experimental en base a un servicio de administración de usuarios con estándares abiertos y software libre con el propósito de demostrar que el experimento llegue a solucionar los problemas planteados. 1.4 Alcances y delimitaciones La presente investigación será realizada en el país de Bolivia, departamento Chuquisaca en la ciudad de Sucre durante la gestión 2022 dado que la institución que presenta los 5 problemas y donde se realizó los requerimientos es el Órgano Judicial con sede a nivel nacional en la ciudad de Sucre. La presente investigación solo abarca el desarrollo backend como propuesta de un servicio en base a una investigación cuasi-experimental, ya que es el núcleo de la propuesta y esta es suficiente para demostrar la resolución de los problemas identificados, el desarrollo frontend será asumido como líneas de investigación futuras. La presente investigación no abarca el desarrollo del Api Gateway la cual será desarrollada como líneas de investigación futuras, esta tendrá que ser aplicada cuando se haya abarcado de manera oficial con la propuesta, debido a que su integración será a más de treinta sistemas monolíticos. La presente investigación no abarca el tema de migración de información de los módulos de administración de usuarios propios al propuesto, debido a la responsabilidad limitada del investigador y la misma deberá ser asumida por los administradores de bases de datos. 1.5 Justificación La presente investigación busca ser precisa en la elaboración de un servicio basado en software libre y estándares abiertos para la interoperabilidad de un módulo de administración de usuarios con sistemas monolíticos, buscando la unificación, integración, celeridad y eficiencia en el proceso, resolviendo el problema de duplicidad de información y el seguimiento institucional. El servicio será aprovechado para realizar un módulo de administración de usuarios, donde cada sistema monolítico interoperará con dicho servicio; al tratarse de modularidad los cambios de requerimientos con relación al tiempo serán tolerables. La adaptación de cada sistema al servicio propuesto será de acuerdo al contexto de cada sistema, por lo que el servicio propuesto deberá indicar la manera de interoperabilidad, tomando en cuenta las variables de contexto, arquitectura, el lenguaje de programación, las tecnologías usadas, la estructura de base de datos, la funcionalidad del cliente y el nivel de experiencia de los desarrolladores. El servicio a ser propuesto estará desarrollado con software libre y estándares abiertos, por lo cual no se tiene costos de licencia de software. 6 Tecnológicamente el servicio propuesto, simplificará los tramites de movilidad del funcionario público, por lo cual la respuesta será rápida y oportuna por parte de la Institución, de esta manera se estaría dando cumplimiento al DS 27330 de simplificación de trámites en el contexto de movilidad del funcionario público. La unificación de información es un impulso importante tanto para la administración de sistemas como para el soporte de sistemas ya que con el servicio propuesto los tiempos en soporte serán disminuidos. Para la interoperabilidad se tiene varios caminos, por ejemplo, montar un api Gateway institucional o no, para el presente trabajo de investigación no se utilizará un API Gateway dimitiendo esta implementación para líneas de investigación futuras. Es de importancia contar con un servicio basado en software libre y estándares abiertos para la interoperabilidad de administración de usuarios con sistemas monolíticos, el cual debe garantizar la unificación, interoperabilidad, celeridad y eficiencia en el proceso de registro de usuarios, login y obtener información específica. De esta manera ya no se crearían más usuarios en los diferentes sistemas sino únicamente la creación seria a través del servicio propuesto, eliminando la duplicidad de usuarios y dando por evidente un seguimiento institucional unificado. El servicio viene a ser una alternativa económicamente factible ya que en la actualidad existen diferentes soluciones de pago con costos muy altos; al mismo tiempo al tratarse de una solución novedosa exige la constante actualización de los sistemas como de los procedimientos en el contexto a aplicar. 7 1.6 Revisión del Estado del Arte Actualmente existen numerosas soluciones basadas en la administración de usuarios, pero estas son totalmente aisladas lo cual evita poder utilizar dicha información. El sistema operativo Windows posee una administración de usuarios denominada Active Directory la cual puede integrarse y realizar toda la administración a partir de dicha solución, la desventaja es que la solución necesitaría del sistema operativo Windows para funcionar. Se tiene una solución basada en software libre que es OpenLDAP pero al igual que Active Directory usan el mismo protocolo y la desventaja es que su integración te hace dependiente al sistema operativo. Así mismo la Agencia de Gobierno Electrónico de Tecnologías de la Información y Comunicación de Bolivia a razón de la Ley 1080, desarrollaron mecanismos de ciudadanía digital, para el control y autenticación de personas denominadas en el contexto como ciudadanos digitales. Dicho sistema es completo ya que este puede ser integrado a diferentes proyectos siguiendo un estricto procedimiento de normas técnicas de adhesión solo válidas para instituciones públicas y privadas que firmen un convenio con Agetic. La solución mencionada tiene la desventaja de no tener la información de roles del ciudadano digital en los diferentes sistemas donde se integrarán los mecanismos de ciudadanía digital, también la ley 1080 no obliga a los ciudadanos bolivianos a contar con dicho mecanismo, sino que la misma es opcional. También existen mecanismos físicos de autenticación o validación de accesos como son la biometría, tarjetas inteligentes, verificación de voz, verificación de patrones oculares dichos periféricos son en su mayoría integrables a soluciones que se vayan a desarrollar ya sea con algún complemento de API o SDK Como otras soluciones actuales nos encontramos con los protocoles de autenticación que son implementados por las diferentes empresas de renombre que son Facebook, Google, Twitter; la cual consiste en la autenticación mediante sus plataformas con una variedad de permisos que el usuario final acepte entregar al sistema solicitante. 8 1.7 Metodología de la Investigación La presente investigación utiliza la metodología de la investigación tecnológica, con alcance exploratorio, de enfoque positivista y con los métodos analítico y demostrativo en base a una investigación cuasi-experimental. 1.7.1 Técnicas Para la identificación de los problemas se usa la técnica de observación en dependencias de la Unidad Nacional de Sistemas Informáticos y Comunicaciones del Órgano Judicial donde poseen diferentes sistemas monolíticos e interoperabilidad entre algunos sistemas tanto internos como externos; buscando la formulación del problema en base al análisis de causas y efectos, identificación del problema central y, análisis de objetivos para determinar las metas que se deben lograr para considerar el problema solucionado. La búsqueda y recopilación de información en el área de estudio está enfocada en la exploración bibliográfica en revistas científicas de tecnología, tesis, libros, publicaciones, foros y en las comunidades de software libre referente a interoperabilidad, modularidad, y protocolos de autenticación; con el fin de conocer el estado del arte de las implementaciones o tendencias actuales sobre interoperabilidad con sistemas monolíticos o micro servicios. Tocando, además, temáticas referidas a definiciones generales de arquitectura monolítica, arquitectura micro-servicios, interoperabilidad, estado actual del país referente a la interoperabilidad, normativa vigente; para luego organizar la información de acuerdo a conceptos generales, estándares y técnicas. 1.7.2 Métodos Siguiendo el método analítico, se realiza la búsqueda de ideas, analizando los diferentes tipos de interoperabilidad encontradas que actualmente están siendo utilizadas; identificando positivamente las ventajas y desventajas de cada una, para luego mediante la inducción identificar criterios de evaluación y elaborar una comparación entre cada alternativa existente respecto a los criterios planteados. 1.7.3 Instrumentos Para poder tener una idea más clara respecto a la problemática y el negocio en particular se aplicaron guías de entrevistas a los administradores de los sistemas monolíticos, los 9 cuales expresaron de manera repetitiva el problema de tener diferentes módulos de administración de usuarios en cada sistema que administran. En consecuencia, estas ideas evaluadas servirán para el planteamiento de soluciones, en donde se pretende establecer las directrices que debería considerar el cuasi experimento de interoperabilidad de administración de usuarios con sistemas monolíticos y proponer una primera aproximación al servicio ideal; luego es necesario realizar el diseño de pruebas y evaluación del servicio elaborado, consiguiendo desarrollar un cuasi experimento y someterlo a pruebas exhaustivas en la institución de estudio para su afinación y obtener así una propuesta final del servicio. 10 CAPÍTULO II. MARCO TEÓRICO En el presente capitulo se realiza una exposición del marco teórico de todas las herramientas o definiciones a ser aplicadas en la presente investigación, para su posterior aplicabilidad en el experimento en cuestión. 2.1 Interoperabilidad “La capacidad de comunicar, ejecutar programas, o transferir datos entre varias unidades funcionales de forma que el usuario no tenga la necesidad de conocer las características únicas de estas unidades” (ISO, 2000). Interoperabilidad entre microservicios: Los microservicios emplean protocolos abiertos y livianos para la comunicación, lo que permite que cualquier aplicación o componente pueda interactuar con ellos, independientemente de la tecnología en la que estén desarrollados. Cada servicio de interoperabilidad tiene características específicas que determinan su naturaleza según el tipo de datos que proporciona. Por lo tanto, se sugiere que la entidad que busque implementar un servicio de interoperabilidad identifique inicialmente el tipo de servicio que ofrecerá para comprender cómo interactuará con los datos. “Los tipos de servicios de interoperabilidad son de lectura o transaccional, individual o masivo, y agregado estadístico o desagregado, los cuales se describen a continuación”: (CTIC, 2017) 1. Tipo de servicio de lectura/consulta o transaccional Cuando un servicio de interoperabilidad únicamente permite la lectura de datos sin modificar la fuente primaria, se clasifica como un servicio de lectura o consulta. Este tipo de servicio puede involucrar el procesamiento y la creación de una respuesta personalizada. Por otro lado, cuando el servicio de interoperabilidad facilita la creación, actualización o eliminación de datos, se considera como un servicio transaccional. Es posible que un servicio transaccional también incluya capacidades de lectura o consulta. Es importante destacar que, al identificar un servicio transaccional, se deben aplicar medidas de seguridad adicionales durante su implementación. 11 2. Tipo de servicio individual o masivo Un servicio de interoperabilidad individual devuelve un conjunto de datos relacionados y estructurados entre sí, como los datos de una persona, como su nombre, número de identificación y fecha de nacimiento. Por otro lado, un servicio de interoperabilidad masivo devuelve un listado de datos relacionados y estructurados, como una lista de personas. Al implementar un servicio de interoperabilidad masivo, se recomienda aplicar criterios de paginación, filtros y búsqueda, así como otros criterios de disponibilidad debido a la gran cantidad de datos que pueden ser solicitados por los consumidores. 3. Tipo de servicio agregado estadístico o desagregado Un servicio agregado proporciona datos procesados y estadísticas, como promedios o sumas, lo que permite al consumidor acceder a la información sin necesidad de procesarla. Por otro lado, un servicio desagregado expone los datos de forma individual y sin procesamiento. En el caso de un servicio agregado estadístico, se debe considerar la cantidad de datos a procesar, ya que, si la cantidad es considerable y el cálculo se realiza en tiempo real, se recomienda aplicar criterios de disponibilidad. 2.2 Microservicios 2.2.1 Arquitectura Monolítica Una arquitectura monolítica representa el enfoque convencional y unificado para la creación de software. En este contexto, implica que el software se encuentra integrado como una única entidad. Este tipo de software está diseñado para operar de manera autónoma, donde sus componentes están estrechamente vinculados e interdependientes en lugar de presentar una baja interconexión, como es común en los programas de software modulares. Además, cualquier actualización en un componente del programa monolítico requiere una reescritura de toda la aplicación, a diferencia de una aplicación modular donde es posible modificar cada módulo individualmente (como un microservicio) sin afectar otras partes del programa. (programadores, 2018) 12 Las arquitecturas modulares disminuyen la probabilidad de que una modificación realizada en un elemento genere cambios inesperados en otros elementos, ya que los módulos son relativamente independientes entre sí. Además, los programas modulares facilitan la adopción de procesos iterativos en comparación con los programas monolíticos. Un monolito puede ser considerado como un estilo arquitectónico o un patrón de desarrollo de software. Estos estilos y patrones suelen adaptarse a distintos tipos de vistas, que son conjuntos o categorías de perspectivas que se pueden integrar fácilmente. Algunos de los tipos de vista fundamentales incluyen: • Vista de Módulo: Describe las unidades de código y sus relaciones durante la etapa de compilación. • Vista de Asignación: Representa el mapeo del software en su entorno. • Vista de Tiempo de Ejecución: Define la estructura estática de los elementos de software y cómo interactúan entre sí durante la ejecución. Figura 1 Arquitectura Monolítica Fuente: Lewis, Fowler (2014) 13 2.2.2 Arquitectura Microservicios La Arquitectura de Microservicios, también conocida como MSA (por sus siglas en inglés, Micro Services Architecture), es un enfoque de desarrollo de software que implica la construcción de una aplicación como una serie de servicios pequeños. Estos servicios se ejecutan de manera independiente en sus propios procesos y se comunican entre sí a través de mecanismos livianos, típicamente mediante una API de recursos HTTP. Cada servicio se encarga de implementar una funcionalidad específica del negocio. Además, cada servicio se despliega de manera independiente y puede estar desarrollado en distintos lenguajes de programación y utilizar diversas tecnologías de almacenamiento de datos. (Fowler, 2014) Características: ● Los componentes son servicios: La principal manera de crear componentes es mediante la inserción de un botón que automáticamente por detrás, gestione la descomposición en servicios en lugar de bibliotecas. Los servicios son componentes separados que se comunican mediante mecanismos como los servicios web o los RPC en lugar de usar llamadas a funciones en memoria como hacen las bibliotecas. ● Organizada en torno a las funcionalidades del negocio: El sistema se divide en distintos servicios donde cada uno está organizado en torno a una capacidad del negocio. Es muy importante limitar la responsabilidad de cada servicio. Cada servicio implementa toda la funcionalidad del negocio que agrupa desde la interfaz de usuario, la persistencia en el almacenamiento y cualquiera de las colaboraciones externas. ● Productos no proyectos: En esta arquitectura normalmente se sigue la idea de que un equipo debe estar a cargo de un componente (servicio) durante todo el ciclo de vida del mismo, desde la etapa de diseño y construcción, la fase de producción y hasta la de mantenimiento. Esta mentalidad se acopla bien a con la vinculación a una capacidad del negocio. En lugar de ver el software como un conjunto de funcionalidades terminadas se ve como una relación continua, donde la pregunta es cómo puede el software ayudar a sus usuarios a mejorar la funcionalidad del 14 negocio que implementa. Esto es facilitado por el bajo nivel de granularidad que ofrecen los microservicios. ● Extremos inteligentes tuberías bobas: Las aplicaciones creadas desde microservicios pretenden ser tan disociadas y cohesivas como sea posible, ellas poseen su propia lógica de dominio y actúan como filtros en el clásico sentido UNIX: recibe una solicitud, aplica la lógica apropiada y produce una respuesta. Estos pasos son coreografiados usando protocolos simples (típicamente HTTP con REST o mensajería liviana como RabbitMQ o ZeroMQ) en lugar de protocolos complejos como WS-BPEL. ● Tener gobierno descentralizado permite usar tecnologías que se adapten mejor a cada funcionalidad: Con el sistema con múltiples servicios colaborativos, podemos decidir utilizar diferentes lenguajes de programación y tecnologías dentro de cada servicio. De esta forma podemos elegir la herramienta adecuada para cada tipo de trabajo en lugar de tener una estandarizada. Por ejemplo, si una parte del sistema necesita mejorar su rendimiento es posible usar una tecnología, quizás más complicada, que permita alcanzar el nivel de rendimiento requerido. Otro ejemplo sería usar para ciertas cosas (reflejar interacciones entre usuarios) una base de datos orientada a grafos, y usar para otras bases de datos orientadas a documentos. La arquitectura de microservicios permite adoptar nuevas tecnologías más rápido y en aquello lugares donde se puede aprovechar su potencial ya que se acota el impacto. ● Gestión de datos descentralizada: Los microservicios prefieren dejar a cada servicio que gestione su propia base de datos, sean estas diferentes instancias de la misma tecnología de base de datos o sistemas de base de datos completamente diferentes. Por ejemplo, podríamos tener Redis para sesiones de usuarios (base de datos en memoria), MySQL (relacional) para los datos de pago, MongoDB (orientada a documentos) para el catálogo de productos, Neo4j (orientada a grafos) para las recomendaciones y Apache Cassandra (orientado a clave-valor) para el análisis de logs y analíticas. El estilo de microservicios tiene implicaciones en el manejo de las actualizaciones las cuales tradicionalmente han usado transacciones para garantizar la consistencia. Las transacciones imponen un acoplamiento temporal lo que se vuelve problemático cuando hay varios servicios. 15 Como las transacciones distribuidas son mucho más difíciles de implementar, las arquitecturas de microservicios promueven la coordinación no transaccional entre servicios, con el reconocimiento explícito que la consistencia puede ser una consistencia eventual y los problemas son compensados operativamente. El sistema merece la pena siempre y cuando el costo de solucionar los errores sea menor que el costo de perder negocios por una mayor consistencia. Los microservicios no obligan a tener distintas tecnologías de almacenamiento, solo lo permiten. ● Diseño tolerante a fallos: Las aplicaciones necesitan ser diseñadas de modo que puedan tolerar las fallas de los distintos servicios. Cualquier llamada de servicio puede fallar y el cliente tiene que ser capaz de responder a esto con la mayor facilidad y eficacia posible, evitando los muy habituales fallos en cascada de las arquitecturas distribuidas. Patrones más importantes para conseguir estabilidad que se usan en la arquitectura de microservicios: o Usar tiempos de espera máximos: Es un mecanismo simple que permite dejar de seguir esperando por una respuesta que consideramos que ya no vendrá. Asociado al vencimiento de un tiempo de espera es frecuente que aparezcan: ▪ Reintento. Consiste en repetir una operación para el cual finalizó su tiempo de espera. ▪ Encolar para reintentar la operación para ser realizada más tarde o Disyuntores: Funcionan de forma similar a los interruptores automáticos accionados por sobrecargas que hay en las instalaciones eléctricas. En el software existen para permitir que un subsistema ante una falla no destruya el sistema entero por sobrecarga y una vez que el peligro ha pasado pueda reestablecerse. Este mecanismo se suele usar para envolver operaciones peligrosas con un componente y así poder esquivar las llamadas cuando el sistema no esté operativo. Si el disyuntor detecta que las fallas superan una frecuencia umbral el disyuntor salta abriéndose y las llamadas fallan sin realizan ningún intento de ejecutar una operación real. Después de esperar un tiempo adecuado se decide que la operación tiene una oportunidad y pasa a un estado de semi abierto en el que la próxima llamada es permitida, 16 si tiene éxito entonces el disyuntor se vuelve a cerrar y todo vuelve a funcionar normalmente, si falla el disyuntor se vuelve a abrir y se vuelve a esperar el tiempo adecuado para intentar. o Compartimentos aislados: para contención de daños manteniéndolos aislados. La forma más común de tenerlos es usando redundancia física teniendo por ejemplo varios servidores y dentro de cada servidor varias instancias. A gran escala podríamos tener varias granjas de servidores. ● Automatización de la infraestructura: La mayoría de los productos y sistemas desarrollados con el enfoque de microservicios han sido construidos por equipo que usan entrega continua y su precursor la integración continua. Para conseguir esto es necesario: o Automatizar todo el proceso, desde el chequeo del código, pruebas, despliegue. o Control de versiones y gestión de configuración. Todo el software tiene que estar versionado y poder gestionar las distintas configuraciones para conseguir la entrega continua. o Arquitectura adecuada. La arquitectura tiene que permitir realizar cambios sin que afecten al resto del sistema. La arquitectura de microservicios lo hace posible. ● Diseño evolutivo: Cuando se divide el sistema en servicios hay que tener en cuenta que cada uno tiene que poder ser reemplazado o actualizado de forma independiente. Es decir, tiene que permitir una fácil evolución. El diseño del servicio tiene que ser de tal forma que evite en lo posible que la evolución de los servicios afecte a sus consumidores. 17 Figura 2 Arquitectura micro servicios Fuente: Lewis, Fowler (2014) Integración de servicios: Cuando nos enfrentamos a problemas complejos que involucran la gestión de procesos de negocio que abarcan varios servicios, es fundamental considerar dos enfoques: Orquestación y Coreografía. La orquestación implica utilizar un software que guíe y coordine el proceso de manera centralizada, de manera similar a la labor de un director de orquesta. Por otro lado, la coreografía implica permitir que cada parte del sistema realice su función de manera autónoma y se encargue de los detalles, como lo hacen los bailarines en un ballet. Este enfoque es más adecuado para la arquitectura de microservicios, ya que cada servicio sabe cómo actuar en cada momento y cómo interactuar con otros servicios, en lugar de depender de una coordinación centralizada. Por esta razón, para la integración de servicios, suele preferirse la coreografía. 18 Ventajas de una solución basada en microservicios: (Torre, 2017) 1. Cada microservicio es de tamaño reducido, lo que facilita su gestión y desarrollo. Específicamente: ● Es sencillo para los desarrolladores entender y comenzar a trabajar con eficiencia rápidamente. ● Los contenedores se crean con rapidez, lo que aumenta la productividad de los desarrolladores. ● Cada microservicio puede ser diseñado, desarrollado e implementado de manera independiente, lo que agiliza el proceso de implementación de nuevas versiones con frecuencia. 2. Es factible escalar horizontalmente áreas individuales de la aplicación. Por ejemplo, puede ser necesario aumentar la capacidad del servicio de catálogo o de la cesta de la compra, pero no del proceso de pedidos. En comparación con una arquitectura monolítica, una infraestructura de microservicios utiliza de manera más eficiente los recursos durante el escalado horizontal. 3. El trabajo de desarrollo se puede distribuir entre múltiples equipos. Cada servicio puede ser gestionado por un equipo de desarrollo único, lo que permite que cada equipo administre, desarrolle, implemente y escale su servicio de manera independiente a los demás equipos. 4. Los problemas se encuentran más aislados. Si surge un problema en un servicio, en principio solo afecta a ese servicio (excepto en casos de diseño incorrecto con dependencias directas entre los microservicios), y los demás servicios pueden continuar procesando las solicitudes. En cambio, un fallo en un componente en una arquitectura monolítica puede afectar a todo el sistema, especialmente si implica recursos como una fuga de memoria. Además, al resolver un problema en un microservicio, se puede implementar dicho microservicio sin afectar al resto de la aplicación. 5. Se pueden emplear las tecnologías más recientes. Dado que es posible desarrollar y ejecutar los servicios de manera independiente y simultánea gracias a los contenedores, es factible adoptar oportunamente las tecnologías y plataformas más modernas en lugar de quedar limitado a una pila o marco de trabajo obsoleto para toda la aplicación. 19 Desventajas de una solución basada en microservicios: Una solución basada en microservicios como esta también tiene algunas desventajas: 1. Aplicación distribuida. La distribución de una aplicación introduce complicaciones adicionales para los desarrolladores durante el diseño y la creación de los servicios. Por ejemplo, requiere que los desarrolladores establezcan la comunicación entre los servicios utilizando protocolos como HTTP o AMPQ, lo cual añade complejidad a las pruebas y al manejo de excepciones. Además, puede aumentar la latencia en el sistema (Torre, 2017). 2. Complejidad de la implementación. Una aplicación que consta de numerosos tipos de microservicios y requiere una gran escalabilidad (necesita crear múltiples instancias para cada servicio y distribuirlos entre varios hosts) presenta un nivel considerable de complejidad en términos de implementación para las operaciones de TI y la administración. Si no se cuenta con una infraestructura específicamente diseñada para microservicios (como un orquestador y un planificador), esta complejidad adicional podría demandar muchos más recursos de desarrollo que la propia construcción de la aplicación empresarial (Torre, 2017). 3. Transacciones atómicas. Por lo general, no es posible llevar a cabo transacciones atómicas que involucren varios microservicios. Los requisitos del negocio deben asegurar la coherencia final entre los diferentes microservicios (Torre, 2017). 4. Aumento de las necesidades de recursos globales. En muchos casos, al cambiar de una aplicación monolítica a un enfoque basado en microservicios, es probable que la nueva aplicación requiera una mayor cantidad de recursos globales en comparación con la infraestructura necesaria para la aplicación monolítica original. Esto se debe a que la mayor granularidad y la distribución de servicios demandan más recursos en general. Sin embargo, debido al costo relativamente bajo de los recursos y a la capacidad de escalar horizontalmente solo partes específicas de la aplicación, en comparación con los costos a largo plazo asociados con el desarrollo de aplicaciones monolíticas, el incremento en el uso de recursos suele considerarse una ventaja para aplicaciones grandes a largo plazo (Torre, 2017). 5. Problemas de comunicación directa de cliente a microservicio. Cuando una aplicación alcanza un tamaño considerable, con numerosos microservicios, surgen 20 problemas y limitaciones si se requiere que la aplicación establezca comunicaciones directas con cada microservicio. Una de las dificultades radica en el riesgo de una incompatibilidad entre las necesidades del cliente y las interfaces de programación de aplicaciones (API) expuestas por cada uno de los microservicios. En ocasiones, esto puede resultar en que la aplicación cliente deba realizar múltiples solicitudes independientes para construir la interfaz de usuario, lo cual puede ser ineficiente a través de Internet y poco práctico en redes móviles. Por consiguiente, es importante minimizar las solicitudes de la aplicación cliente al sistema back-end (Torre, 2017). Otro inconveniente de las comunicaciones directas entre el cliente y el microservicio es la posibilidad de que algunos de estos últimos utilicen protocolos no adecuados para la web. Es factible que un servicio emplee un protocolo binario, mientras que otro utilice mensajería de AMQP. Estos protocolos pueden no ser compatibles con los firewalls y ser más útiles cuando se emplean internamente. Generalmente, una aplicación debería utilizar protocolos como HTTP y WebSockets para las comunicaciones fuera del firewall (Torre, 2017). Una desventaja adicional de este enfoque directo de cliente a servicio es la dificultad para refactorizar los contratos de esos microservicios con el tiempo. Los desarrolladores pueden considerar cambiar la forma en que el sistema se divide en servicios, como combinar dos servicios o dividir uno en dos o más. Sin embargo, si los clientes se comunican directamente con los servicios, realizar este tipo de refactorización puede afectar la compatibilidad con las aplicaciones cliente (Torre, 2017). Como se mencionó en la sección sobre arquitectura, al diseñar y crear una aplicación compleja basada en microservicios, podría ser beneficioso considerar el uso de múltiples puertas de enlace de API específicas en lugar del enfoque más simple de comunicación directa entre el cliente y el microservicio (Torre, 2017). 6. Creación de particiones de los microservicios. Finalmente, sin importar el enfoque seleccionado para la arquitectura de microservicios, surge otro desafío crucial: decidir cómo dividir una aplicación completa en múltiples microservicios. Como se mencionó en la sección de arquitectura de la guía, existen diversas técnicas y enfoques que se pueden adoptar para este propósito. En esencia, se trata 21 de identificar las áreas de la aplicación que pueden separarse del resto y que tienen pocas dependencias fuertes. En muchos casos, esto implica la creación de particiones de servicios basadas en casos de uso específicos. Por ejemplo, en una aplicación de tienda en línea, puede haber un servicio dedicado a los pedidos, encargado de toda la lógica de negocios relacionada con el proceso de pedidos. Además, puede haber servicios separados para el catálogo de productos y para la gestión de la cesta de la compra, cada uno implementando funciones distintas. Idealmente, cada servicio debería tener un conjunto limitado de responsabilidades, siguiendo el principio de responsabilidad única (SRP) aplicado a las clases en la programación, que establece que una clase debe tener una única razón para cambiar. Sin embargo, en el caso de los microservicios, este alcance es más amplio que el de una sola clase. En resumen, un microservicio debe ser completamente autónomo, desde su inicio hasta su finalización, lo que incluye la responsabilidad sobre sus propios datos de origen (Torre, 2017). 2.2.3 Microservicios Poliglotas Los desarrolladores y arquitectos de software usan muchos modelos arquitectónicos. Los siguientes son algunos de ellos (se combinan estilos y modelos arquitectónicos) (Torre, 2017): ● CRUD simple, de un nivel y una capa. ● Tradicional de N capas. ● Diseño controlado por dominios de N capas. ● Arquitectura limpia. ● Segregación de responsabilidades de consultas de comandos (CQRS). ● Arquitectura controlada por eventos (EDA). 22 Figura 3 Arquitectura múltiple o poliglota Fuente: Torre (2017) Es fundamental comprender que no existe un modelo o estilo arquitectónico único ni una tecnología específica que sea óptima para abordar todas las situaciones. 2.3 Protocolos de autenticación OpenID Connect 1.0 es una capa de autenticación que se basa en el protocolo OAuth 2.0. Su función es permitir que los clientes verifiquen la identidad del usuario final a través de un servidor de autorización. Además, posibilita la obtención de información básica del perfil del usuario final de manera interoperable y mediante un enfoque de tipo REST. Esta tecnología permite a diversos tipos de clientes, como aquellos basados en web, móviles y JavaScript, solicitar y recibir datos sobre sesiones autenticadas y usuarios finales. El conjunto de especificaciones es extensible, lo que permite a los participantes utilizar funciones opcionales como el cifrado de datos de identidad, el descubrimiento de proveedores de OpenID y la gestión de sesiones, cuando tenga sentido para ellos. (Sakimura, s.f.) La especificación OpenID Connect 1.0 consta de estos documentos: ● Núcleo: Establece la función principal de OpenID Connect, que se basa en la autenticación construida sobre OAuth 2.0 y el uso de notificaciones para transmitir información sobre el usuario final. 23 ● Descubrimiento: (opcional) Define el método mediante el cual los clientes pueden descubrir de manera dinámica información sobre los proveedores de OpenID. ● Registro dinámico: (opcional) Define el proceso mediante el cual los clientes pueden registrarse automáticamente con los proveedores de OpenID. ● Tipos de respuesta múltiple de OAuth 2.0: Introduce varios tipos de respuesta específicos nuevos dentro del contexto de OAuth 2.0. ● Modo de respuesta posterior al formulario de OAuth 2.0: (Opcional) Describe cómo se deben devolver los parámetros de respuesta de autorización de OAuth 2.0 (incluyendo los de autenticación de OpenID Connect) utilizando valores de formulario HTML enviados automáticamente mediante HTTP POST por el agente de usuario. ● Administración de sesión: (opcional) Establece cómo deben gestionarse las sesiones de OpenID Connect, incluyendo funciones de cierre de sesión basadas en mensajes posteriores y cierre de sesión iniciado por el proveedor de servicios. ● Cierre de sesión de canal frontal: (opcional) Define un método de cierre de sesión que no utiliza un iframe de proveedor de servicios en las páginas del cliente. ● Cierre de sesión del canal posterior: (Opcional) Establece un mecanismo de cierre de sesión que implica comunicación directa del canal posterior entre el proveedor de identidad y los proveedores de servicios que se están desconectando. ● Federación de OpenID Connect: (Opcional) Describe cómo conjuntos de proveedores de identidad y proveedores de servicios pueden establecer confianza utilizando un operador de federación. Figura 4 Protocolo OpenID Connect Fuente: openid (2014) 24 2.4 Seguridad en servicios JWT (JSON Web Token) es una normativa de código abierto, detallada en el RFC 7519, que establece un procedimiento eficiente y completo para encriptar y transmitir afirmaciones sobre una entidad determinada entre diferentes entidades de forma segura, empleando objetos JSON. Se puede confiar y verificar el contenido del token cuando este está firmado digitalmente (JWS, RFC 7515). La autenticación puede ser realizada mediante claves de tipo simétrico (HMAC) o claves de tipo asimétrico (RSA o ECDSA). Además, los JWT pueden incluir información encriptada (JWE, RFC 7516) para salvaguardar datos confidenciales, aunque este último aspecto no es el foco de la investigación actual. Es importante resaltar que, por defecto, los tokens no están cifrados, y que la cadena que vemos es simplemente una serialización usando codificación base64url, que puede decodificarse fácilmente para ver el contenido JSON del token en claro. (Jones, 2015) Clases de tokens y sus usos • Token de datos: En su formato compacto de JWT, es fácil de transmitir a través de solicitudes HTTP y se emplea para el intercambio de información. • Token de identificación: Generado por un gestor de identidades a solicitud de una aplicación cliente después de autenticar a un usuario. Esto permite que la aplicación cliente acceda a los datos del usuario de manera segura sin tener que manejar directamente sus credenciales. • Token de acceso: Emitido por un servidor de autorización a petición de una aplicación cliente, otorgándole acceso a un recurso protegido en nombre de un usuario. Este token se usa como método de autenticación y autorización por parte de la aplicación cliente frente al servidor que aloja el recurso. (Jones, 2015) JWT ofrece una forma segura y eficiente de intercambiar datos entre distintas partes, superando otros estándares como SAML debido a su tamaño reducido, lo que lo hace especialmente adecuado para los siguientes escenarios: 25 • Intercambio de información de sesión entre cliente y servidor: Gracias a su capacidad de serialización, a veces se utilizan para transmitir datos de sesión y estado entre el servidor y sus clientes. A menudo se emplean "tokens no seguros" (sin firma) para este propósito. • Autenticación federada: Elimina la necesidad de que las aplicaciones administren las credenciales de los usuarios, permitiendo que un gestor de identidad de confianza maneje el proceso de autenticación. Este gestor genera un token verificable para la aplicación que contiene la información necesaria del usuario. • Autorización de acceso: El token contiene la información necesaria para que un servicio de APIs pueda evaluar si la operación solicitada por el tenedor del token se puede permitir. (Jones, 2015) Cada escenario de uso implica destinatarios diferentes (la aplicación cliente y el servicio de API). Sin embargo, si hay control simultáneo sobre ambos, un solo token puede ser empleado para ambos casos. A continuación, se detallan las prácticas óptimas al trabajar con JWT, concentrándonos exclusivamente en su generación y validación. Proceso de Generación de Tokens 1. Siempre emitir tokens firmados: Excepto en raras ocasiones (como cuando se utilizan en el lado del cliente para transportar información de sesión y datos para reconstruir la interfaz de usuario), los tokens no deben emitirse sin firma. La firma proporciona una protección básica que permite a los consumidores del token confiar en él y asegurarse de que no ha sido alterado. 2. Utilizar algoritmos criptográficos robustos: Al elegir el algoritmo de firma, es importante considerar que los algoritmos de clave simétrica son vulnerables a ataques de fuerza bruta si la clave utilizada no es lo suficientemente fuerte. Por otro lado, los algoritmos de clave asimétrica simplifican la custodia de la clave, ya que solo se necesita en la parte del servidor que genera el token. 26 3. Incluir fecha de expiración e identificador único: Un token, una vez firmado, es válido indefinidamente si no tiene una fecha de expiración. Asignar identificadores a los tokens permite su revocación en caso de que el token sea comprometido. 4. Especificar emisor y destinatario: Identificar el emisor y todos los posibles destinatarios facilita la gestión por parte de los consumidores de los tokens, permitiéndoles identificar la clave de validación y verificar que el token está dirigido a ellos. 5. Evitar incluir datos sensibles sin cifrar en los claims: Los tokens no están cifrados por defecto, por lo que es importante tener cuidado con la información que se incluye en ellos, si fuera necesario incluir información sensible o secretos hay que usar tokens cifrados. (Jones, 2015) Validación del token 1. No aceptar tokens sin firma: La firma es la única forma de verificar que los datos contenidos dentro del token son confiables. Después de verificar el formato, la primera validación que se debe realizar es que el token esté firmado. Nunca se debe aceptar un token con "none"' en su cabecera. 2. Validar claims de cabecera: Nunca confiar en la inocuidad de la información recibida en la cabecera o en los reclamos. Siempre se deben sanitizar antes de usarlos para evitar ataques de inyección. 3. Siempre validar emisor y destinatarios: Antes de aceptar un token, es crucial verificar que esté dirigido al receptor correcto y que haya sido emitido por la entidad esperada. 4. Almacenar claves de firma por emisor y algoritmo: 27 Al seleccionar la clave para validar la firma, se debe considerar tanto el emisor como el algoritmo. Esto ayuda a prevenir posibles ataques de cambio de algoritmo por parte de un atacante. Si nosotros no hiciéramos esta validación podríamos aceptar como válido el token cuando realmente no lo es. (Jones, 2015) Ciclo de vida de JWT Figura 5 Ciclo de vida de JWT Fuente: Macias (2018) 2.5 Seguridad en Autenticación Una contraseña de un solo uso, también conocida como One-Time Password (OTP), es un código que tiene validez únicamente para una única ocasión y posteriormente pierde su efectividad. En español, también se la identifica como contraseña de uso único o contraseña de un solo uso. A veces, se emplea la abreviatura en inglés OTP o el término compuesto "código OTP". (Ionos, 2022) Generalmente, la contraseña de uso único está formada por un código alfanumérico OTP (letras y números) y se crea para un único proceso de inicio de sesión. Después de que el usuario haya iniciado sesión con la contraseña de un solo uso, esta perderá su validez y no podrá utilizarse para futuros inicios de sesión. (Ionos, 2022) 28 Es habitual que las contraseñas de un solo uso se utilicen como parte de un proceso de autenticación de doble factor, especialmente en servicios bancarios en línea y cada vez más en diversas empresas. En este proceso, el usuario primero ingresa los datos de inicio de sesión estándar. Posteriormente, genera una contraseña dinámica de un solo uso, por ejemplo, utilizando un generador de códigos, que también es requerido para la autenticación. (Ionos, 2022) Incorporar este paso adicional incrementa considerablemente el nivel de seguridad: incluso si una persona no autorizada logra obtener la contraseña convencional durante el proceso de inicio de sesión, todavía necesitaría la contraseña dinámica de un solo uso, que solo se genera en el momento necesario. Por esta razón, cada vez más servicios en línea están adoptando la autenticación de doble factor, especialmente cuando se trata de datos sensibles. (Ionos, 2022) ¿Cómo funciona una contraseña OTP? Para que un proceso de inicio de sesión utilizando One-Time Password (OTP) sea exitoso, tanto el usuario como el sistema en el que se va a utilizar deben estar al tanto de la contraseña de un solo uso. Para garantizar esto, existen dos métodos distintos. Lista de contraseñas Este método implica crear una lista previa de varias contraseñas que son conocidas tanto por el usuario como por el sistema. Cuando se utiliza una de estas contraseñas de un solo uso, el usuario simplemente la elimina de la lista. Sin embargo, la desventaja de este enfoque es evidente: si el usuario pierde la lista, podría caer en manos de personas no autorizadas. Aunque este tipo de listas de contraseñas de One-Time Password todavía se utilizan en la banca electrónica, cada vez más proveedores están optando por contraseñas OTP generadas dinámicamente debido a esta desventaja. One-Time Passwords generadas de manera dinámica Este es actualmente el método más comúnmente empleado. Una opción frecuente es el uso de generadores de contraseñas de hardware, como dispositivos en forma de llavero o cubo que generan una contraseña cada vez que se necesita. Estos dispositivos, también conocidos como tokens OTP, generalmente tienen una pantalla y generan una contraseña de un solo uso para el proceso de inicio de sesión correspondiente con solo presionar un 29 botón. Por lo general, estas contraseñas de un solo uso se utilizan junto con otros elementos de autenticación, como códigos PIN o identificaciones de usuario. Para crear una One-Time Password, se utiliza un algoritmo especial diseñado para generar la contraseña cuando sea necesario. Este algoritmo puede activarse de tres maneras distintas. (Ionos, 2022) Activación por tiempo En este procedimiento, tanto el generador de contraseñas (cliente) como el servidor generan contraseñas adaptadas y temporalmente sincronizadas utilizando el mismo algoritmo. Estas contraseñas, conocidas como Time-based One-Time Passwords (TOTP), son conocidas tanto por el usuario como por el servidor y su validez está ligada a un período de tiempo determinado, que suele oscilar entre uno y quince minutos. (Ionos, 2022) Activación por evento Las One-Time Passwords activadas por evento se generan al realizar una acción específica, como presionar una tecla en el token generador. Tanto el usuario como el servidor utilizan el mismo algoritmo, y la contraseña se calcula basándose en la contraseña válida anteriormente, lo que permite compararla con el servidor. (Ionos, 2022) Solicitud del servidor (activación por estímulo-respuesta) En este procedimiento, el servidor emite una solicitud que el cliente debe responder. El cliente recibe un valor específico del servidor y utiliza ese valor para calcular la One- Time Password. Como el servidor conoce el algoritmo y el valor indicado, puede verificar la contraseña generada. ¿En qué casos tiene sentido utilizar una contraseña de un solo uso? Las contraseñas de un solo uso son altamente recomendadas en todos los sitios web y servicios en línea que manejan datos especialmente sensibles y críticos. Por ejemplo: • Banca electrónica. • Servicios financieros, como plataformas para depósitos de acciones en línea o mercados de valores para criptomonedas. 30 • Información confidencial de empresas. • Canales de comunicación confidenciales Aunque las contraseñas de un solo uso no son obligatorias para todos los sitios web, es importante asegurarse de utilizar contraseñas seguras en general. Incluso si se utiliza una contraseña en repetidas ocasiones, los estudios muestran que, a pesar del aumento de la ciberdelincuencia, los usuarios no siempre son lo suficientemente conscientes del riesgo al que están expuestos. (Ionos, 2022) Ventajas y desventajas de OTP Tabla 1 Ventajas y Desventajas de OTP Ventajas Desventajas Riesgo mínimo en caso de ataques de replay Requieren tecnología adicional Imposibilidad de que una contraseña robada se use en varias páginas o servicios Los tokens de seguridad pueden fallar o averiarse Mayor seguridad para el usuario El proceso de generación de las contraseñas OTP es, en parte, muy complicado Fuente: Ionos (2022) 2.6 Software Libre Según la Fundación para el Software Libre (FSF), el concepto de software libre se centra en tener el dominio sobre la tecnología que empleamos en nuestros entornos domésticos, educativos y empresariales. Esto implica que los ordenadores deben trabajar en favor de nuestro beneficio tanto individual como colectivo, en contraposición a estar subordinados a empresas que desarrollan software privativo o gobiernos que podrían intentar limitar nuestras libertades y vigilar nuestras actividades. La Fundación para el Software Libre se dedica a garantizar la libertad de los usuarios de computadoras promoviendo tanto el desarrollo como el uso de software y documentación libres, con un enfoque especial en el sistema operativo GNU. Además, realiza campañas para contrarrestar amenazas que puedan surgir contra las libertades de los usuarios de computadoras, como la Gestión Digital de Restricciones (DRM) y las patentes de software. 31 2.6.1 Las cuatro libertades del Software Libre Según la FSF, un programa se considera software libre si los usuarios tienen acceso a las cuatro libertades fundamentales: 1. La libertad de ejecutar el programa para cualquier propósito (libertad 0). 2. La libertada de estudiar cómo funciona el programa y cambiarlo según sus necesidades (libertada 1). El acceso al código fuente es una condición necesaria para ello. 3. La libertad de redistribuir copias del programa para beneficiar a otros (libertad 2). 4. La libertad de distribuir versiones modificadas del programa a terceros (libertad 3). Esto le permite que la comunidad se beneficie de las mejoras realizadas. También requiere acceso al código fuente. Un programa solo se considera software libre si garantiza todas estas libertades de manera efectiva. De lo contrario, no se puede considerar libre. El incumplimiento de estas libertades con fines lucrativos se considera éticamente cuestionable, aunque la persona tiene la libertad de tomar sus propias decisiones, siendo la comunidad o la sociedad testigos de su comportamiento. Es importante destacar que "software libre" no significa que el programa no tenga propósitos comerciales. De hecho, un programa libre debe estar disponible para su uso, desarrollo y distribución comercial. La práctica de desarrollar software libre con fines comerciales es cada vez más común y relevante. Los usuarios pueden adquirir copias del software libre ya sea mediante pago o de forma gratuita, pero en ambos casos conservan la libertad de copiar, modificar y distribuir el software. 2.6.2 El manifiesto de GNU El manifiesto de GNU escrito por Richard Stallman (1985), declara públicamente los principios e intenciones respecto al proyecto GNU como parte del movimiento del Software Libre, que promueve la libertad de los usuarios de software. GNU quiere decir que “GNU No es Unix”. En el manifiesto se solicita apoyo a cualquier persona para colaborar en el sistema operativo GNU, mismo que podrá entregarse libremente a cualquier persona; dando la posibilidad, sin restricción de modificar y redistribuir. Por 32 sobre todo no autorizando las modificaciones privativas, buscando asegurarse que todas las versiones de GNU permanezcan libre. 2.6.3 Código Abierto La esencia de código abierto se especifica en las cuatro libertades escritas en la General Public License (GPL) de la fundación de software libre, es decir que cualquier usuario pueda usar, estudiar, redistribuir y mejorar el código fuente de un software. La gente debe mejorarlo, adaptarlo y rectificarlo (Open Source Initiaive, 2007). 2.6.4 Estándar Abierto Según la Open Source Initiative (2007), un estándar abierto se refiere a que se cumpla mínimamente con los siguientes requisitos: 1. Transparencia absoluta: El estándar no debe ocultar ningún detalle necesario para lograr una implementación interoperable. Dado que las fallas son inevitables, la norma debe establecer un proceso para corregir cualquier fallo identificado durante la implementación y las pruebas de interoperabilidad. Estas correcciones deben incorporarse en una versión revisada o actualizada de la norma, que se publicará bajo términos compatibles con el OSR (Open Source Requirement). 2. Accesibilidad: El estándar debe estar fácilmente disponible para el público de forma gratuita, preferiblemente desde un sitio web establecido. Además, debe ofrecerse bajo condiciones libres de regalías, a un costo razonable y sin discriminación. 3. Gestión de patentes: Todas las patentes esenciales para la implementación del estándar deben estar sujetas a una licencia libre de regalías que permita su uso sin restricciones. Alternativamente, deben estar cubiertas por una promesa de no afirmación cuando se implementan con software de código abierto. 4. Eliminación de acuerdos restrictivos: No debe haber ningún requisito de acuerdo de licencia, NDA (Acuerdo de No Divulgación), concesión, clic o cualquier otra forma de papeleo para implementar el estándar de manera conforme. 33 5. Independencia total del OSR: La implementación del estándar no debe depender de ninguna otra tecnología que no cumpla con los criterios establecidos en este requisito, garantizando así la compatibilidad con el OSR. 2.6.5 Licencias de software libre Tampoco debemos confundir el concepto de software libre con el de software gratuito. El software libre puede ser gratuito o de pago, pero lo fundamental es que el usuario siempre mantendrá la libertad de utilizarlo según sus necesidades. En contraste, el software gratuito a menudo se denomina como freeware. Aunque este tipo de software no tiene costo alguno, está sujeto a restricciones impuestas por licencias, lo que limita la libertad del usuario en comparación con el software libre. Los diferentes tipos licencias Entre las diferentes licencias de software libre podemos destacar las siguientes: a. Licencias GPL: una de las licencias más comunes es la conocida como GNU GPL. Con esta licencia, el desarrollador retiene los derechos de autor, pero permite la distribución, modificación y uso libre del software. Sin embargo, si se realiza alguna modificación en el software, el nuevo programa resultante también debe mantener la misma licencia. Incluso si el software con licencia GPL se utiliza como parte de otro programa, este último también debe mantener la misma licencia. La GNU GPL es considerada como la primera licencia copyleft, lo que significa que cualquier código fuente licenciado bajo esta debe estar disponible para copias ilimitadas y para cualquier persona que lo solicite. Desde la perspectiva del usuario final, el software licenciado bajo la GPL es completamente gratuito, y los costos pueden limitarse únicamente a los gastos de copia y distribución. b. Licencia AGPL: Se encuentra dentro de las licencias derivadas del derecho de autor de GNU. La característica distintiva de la AGPL es que, además de incluir las cláusulas estándar de una GNU GPL, requiere que el software destinado a brindar servicios a través de una red de computadoras se distribuya libremente. 34 En otras palabras, si se utiliza como parte del desarrollo de un nuevo software, este último estaría sujeto a la obligación de distribución gratuita. c. Licencia BSD: Es un claro ejemplo de una licencia permisiva que establece pocas condiciones sobre el uso del software por parte de los usuarios. El software bajo esta licencia es la menos restrictiva para los desarrolladores, ya que no impone obligaciones significativas, como la necesidad de distribuir el código fuente. Además, una aplicación licenciada bajo BSD permite que otras versiones puedan tener diferentes tipos de licencias, tanto libres como propietarias. Un ejemplo destacado es el sistema operativo Mac OS X, desarrollado bajo esta licencia. Asimismo, BSD permite la posibilidad de cobrar por la distribución de objetos binarios. d. Licencia Apache: La licencia de este tipo permite al usuario distribuir, modificar y compartir versiones alteradas del software, siempre y cuando se respeten el derecho de autor y el aviso de exención de responsabilidad. En el caso de la licencia Apache, no se requiere que las versiones modificadas se distribuyan bajo la misma licencia, ni siquiera que sean de código abierto; simplemente se requiere que se informe a los receptores sobre el uso de código con esta licencia. Por lo tanto, al crear nuevas piezas de software, los desarrolladores deben incluir dos archivos en el directorio principal de los paquetes de software redistribuidos: una copia de la licencia y un documento de texto que contenga los avisos obligatorios relacionados con el software presente en la distribución. e. Licencias Creative Commons: su definición se basa en cuatro condiciones: i. Atribución, Permite la distribución, exhibición, representación, etc., siempre y cuando se reconozca y se cite al autor. ii. No comercial, Prohíbe el uso del software con fines comerciales. iii. No derivadas, Impide la modificación de la obra. iv. Compartir igual, Permite la creación de obras derivadas siempre y cuando mantengan la misma licencia original. 35 Figura 6 Licencias de Software Libre Fuente: BBVA Open4u (2014) 2.7 Base de datos PostgreSQL PostgreSQL, conocido también como Postgres, es un sistema de gestión de bases de datos relacional orientado a objetos que opera bajo una licencia de código abierto, la cual es comparable a las licencias BSD o MIT. Al igual que varios otros proyectos de código abierto, PostgreSQL no está bajo el control de una sola empresa o individuo; en su lugar, es gestionado por una comunidad de desarrolladores que contribuyen de manera voluntaria, independiente o respaldados por entidades comerciales. Esta comunidad se conoce como el PGDG (Grupo de Desarrollo Global de PostgreSQL). PostgreSQL no tiene un gestor de errores (bugs), haciendo muy difícil conocer el estado de corrección de los mismos. (Jake Edge, 2015) 2.7.1 Características Algunas de sus principales características son, entre otras: Alta concurrencia Usando un método conocido como MVCC (Control de Concurrencia Multiversión), PostgreSQL posibilita que múltiples procesos accedan a una tabla mientras otro proceso 36 está escribiendo en ella, sin requerir bloqueos. De esta forma, cada usuario obtiene una vista coherente de los datos. PostgreSQL ofrece una amplia gama de tipos de datos nativos, que incluyen: • Números de precisión arbitraria. • Texto de largo ilimitado. • Figuras geométricas, con diversas funciones asociadas. • Direcciones IP (tanto IPv4 como IPv6). • Bloques de direcciones en formato CIDR. • Direcciones MAC. • Arrays. Además, los usuarios tienen la capacidad de crear sus propios tipos de datos, los cuales pueden ser completamente indexables gracias a la infraestructura GiST de PostgreSQL. Algunos ejemplos de estos tipos de datos son los tipos GIS desarrollados por el proyecto PostGIS. Otras funcionalidades incluidas en PostgreSQL son • Claves foráneas, también conocidas como llaves foráneas o claves ajenas. • Disparadores (triggers): definidos como acciones específicas que se ejecutan en respuesta a eventos dentro de la base de datos. En PostgreSQL, los disparadores implican la ejecución de procedimientos almacenados basados en acciones sobre tablas específicas. Cada disparador se define por seis características principales: o Nombre. o Momento de activación. o Evento. o Tabla. o Frecuencia de ejecución. o Función asociada. Combinando estas seis características, PostgreSQL ofrece una amplia gama de funcionalidades a través de su sistema de disparadores (triggers), que incluye: https://es.wikipedia.org/wiki/Precisi%C3%B3n_arbitraria https://es.wikipedia.org/wiki/Direcci%C3%B3n_IP https://es.wikipedia.org/wiki/CIDR https://es.wikipedia.org/wiki/Direcci%C3%B3n_MAC https://es.wikipedia.org/wiki/Vector_(programaci%C3%B3n) 37 • Vistas. • Mantenimiento de la integridad transaccional. • Herencia de tablas. • Manipulación de tipos de datos y operaciones geométricas. • Soporte para transacciones distribuidas. Esto permite que PostgreSQL se integre en sistemas distribuidos que constan de varios recursos, como bases de datos PostgreSQL u Oracle, colas de mensajes IBM MQ JMS y ERPs SAP, gestionados por un servidor de aplicaciones. En este contexto, el éxito de la transacción global está determinado por el éxito de las transacciones locales. 2.7.2 Funciones Los bloques de código ejecutados en el servidor, conocidos como disparadores o triggers en inglés, pueden estar escritos en varios lenguajes, aprovechando la potencia que cada uno ofrece. Estos lenguajes abarcan desde operaciones básicas de programación, como bifurcaciones y bucles, hasta las complejidades de la programación orientada a objetos o funcional. Se pueden emplear varios lenguajes para esta tarea, entre ellos: • PL/PgSQL, un lenguaje propio similar al PL/SQL de Oracle. • C. • C++. • Java PL/Java web. • PL/Perl. • plPHP. • PL/Python. • PL/Ruby. • PL/sh. • PL/Tcl. • PL/Scheme. • Lenguaje para aplicaciones estadísticas R a través de PL/R. 38 PostgreSQL es compatible con funciones que devuelven conjuntos de resultados, los cuales pueden tratarse como un conjunto de valores que se manejan de manera similar a una fila devuelta por una consulta. Estas funciones pueden definirse para ejecutarse con los permisos del usuario que las llama o con los permisos de un usuario previamente especificado. En otros sistemas de gestión de bases de datos, este concepto de funciones se conoce a menudo como "procedimientos almacenados" (stored procedures en inglés). 2.7.3 Ventajas • Garantía de seguridad en general. • Mantenimiento de la integridad en la base de datos mediante restricciones de dominio. • Preservación de la integridad referencial. • Uso de afirmaciones (assertions) para validaciones específicas. • Aplicación de disparadores (triggers) para acciones automáticas en respuesta a eventos. • Gestión de autorizaciones para controlar el acceso a los datos. • Conexión a sistema de gestión de bases de datos • Implementación de transacciones y copias de seguridad para asegurar la consistencia y disponibilidad de los datos. 2.8 Docker Docker es un proyecto de código abierto que automatiza el despliegue de aplicaciones dentro de contenedores de software, proporcionando una capa adicional de abstracción y automatización de virtualización de aplicaciones en múltiples sistemas operativos (O'Gara, 2013) . Docker utiliza características de aislamiento de recursos del kernel Linux, tales como cgroups y espacios de nombres (namespaces) para permitir que "contenedores" independientes se ejecuten dentro de una sola instancia de Linux, evitando la sobrecarga de iniciar y mantener máquinas virtuales El soporte del kernel Linux para los espacios de nombres aísla la vista que tiene una aplicación de su entorno operativo (Walsh, 2014), incluyendo árboles de proceso, red, ID 39 de usuario y sistemas de archivos montados, mientras que los cgroups del kernel proporcionan aislamiento de recursos, incluyendo la CPU, la memoria, el bloque de E/S y de la red. Desde la versión 0.9, Docker incluye la biblioteca libcontainer como su propia manera de utilizar directamente las facilidades de virtualización que ofrece el kernel Linux, además de utilizar las interfaces abstraídas de virtualización mediante libvirt, LXC (Linux Containers) y systemd-nspawn. (Vaughan-Nichols, 2014) Segín el análisis realizado por la firma especializada en la industria 451 Research, “ Docker es una utilidad que tiene la capacidad de encapsular una aplicación junto con sus requerimientos en un contenedor virtual. Este contenedor puede ser ejecutado en cualquier servidor que utilice el sistema operativo Linux. Esta característica facilita la flexibilidad y portabilidad de la aplicación, permitiendo su ejecución tanto en servidores físicos como en entornos de nube pública o privada.” Docker utiliza una interfaz de programación de aplicaciones (API) de nivel superior para ofrecer contenedores ligeros que ejecutan procesos de forma aislada. Basado en las capacidades ofrecidas por el kernel de Linux, como cgroups y namespaces, un contenedor de Docker, a diferencia de una máquina virtual, no necesita contener un sistema operativo propio. En cambio, se apoya en las funcionalidades del kernel y emplea la separación de recursos (CPU, memoria, E/S de bloque, red, etc.) y espacios de nombres (namespaces) distintos para aislar la perspectiva de una aplicación del sistema operativo. Docker accede a la virtualización del kernel Linux ya sea directamente a través de la biblioteca libcontainer (disponible desde Docker 0.9), o indirectamente a través de libvirt, LXC o systemd-nspawn. (Avram, 2013) Empleando contenedores, es posible aislar recursos, limitar servicios y conceder a los procesos una visión prácticamente privada del sistema operativo, con su propio identificador de espacio de proceso, estructura del sistema de archivos e interfaces de red. Aunque varios contenedores comparten el mismo núcleo, cada uno puede ser limitado para utilizar solamente una cantidad específica de recursos como CPU, memoria y E/S. Utilizar Docker para crear y administrar contenedores puede simplificar la configuración de sistemas altamente distribuidos, lo que permite que múltiples aplicaciones, tareas de trabajadores y otros procesos operen de manera autónoma en una sola máquina física o 40 en varias máquinas virtuales. Esto facilita el despliegue de nodos a medida que se disponen de recursos o cuando se necesitan más nodos, permitiendo un estilo de plataforma como servicio (PaaS) para desplegar y escalar sistemas como Apache Cassandra, MongoDB o Riak. Además, Docker simplifica la creación y operación de tareas de carga de trabajo, colas y otros sistemas distribuidos. Figura 7 Infraestructura Docker Fuente: Vaughan-Nichols (2014) Diferencias entre VMs y Dockers En el contexto de las máquinas virtuales, existen tres niveles de base en el servidor host, en orden ascendente: la infraestructura, el sistema operativo host y un hipervisor. Además de estos niveles, cada máquina virtual posee su propio sistema operativo y todas las bibliotecas necesarias. En contraste, en el caso de Docker, el servidor host únicamente incluye la infraestructura y el sistema operativo. Sobre esta base, se sitúa el motor de contenedores de Docker, el cual mantiene el contenedor aislado, aunque con la capacidad de compartir los servicios del sistema operativo base. Debido a que los contenedores demandan menos recursos, como la ausencia de un sistema operativo completo, pueden iniciarse de manera rápida y desplegarse con facilidad. Esto posibilita una densidad mayor, lo que implica la capacidad de ejecutar más servicios en una misma unidad de hardware, lo que a su vez conlleva a una reducción de costos. 41 El propósito principal de una imagen es asegurar que el entorno, incluyendo las dependencias, sea idéntico en diferentes implementaciones. Esto implica que pueda depurarlo en su propio equipo y, luego, implementarlo en otra máquina con la certeza de que el entorno será el mismo. Una imagen de contenedor representa una forma de encapsular una aplicación o servicio para su despliegue de manera consistente y predecible. Se podría argumentar que Docker no solo es una herramienta tecnológica, sino también una filosofía y un enfoque operativo. Cuando se emplea Docker, es poco probable que los desarrolladores expresen la frase común "Funciona en mi máquina, ¿por qué no en producción?". En su lugar, simplemente indicarán que "Se ejecuta en Docker", ya que la aplicación empaquetada con Docker puede ejecutarse en cualquier entorno compatible con Docker y funcionará de manera consistente en todos los destinos de despliegue, como desarrollo, control de calidad, ensayo y producción. Figura 8 Diferencia entre VMs y Docker Fuente: Oracle (2020) 42 2.9 Golang • Go es un lengu