Mecanismos de seguridad de la plataforma FIWARE

Equation Chapter 1 Section 1 Trabajo de Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Mecanismos de seguridad de la plataforma FIWARE Autor: Javier Saavedra Galiano Tutor: Juan Antonio Ternero Muíz Departamento Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2019 ii iii Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Mecanismos de seguridad de la plataforma FIWARE Autor: Javier Saavedra Galiano Tutor: Juan Antonio Ternero Muñiz Profesor colaborador Departamento de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2019 iv v Trabajo de Fin de Grado: Mecanismos de seguridad de la plataforma FIWARE Autor: Javier Saavedra Galiano Tutor: Juan Antonio Ternero Muñiz El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2019 vi El Secretario del Tribunal vii A mi familia A mis maestros viii ix Agradecimientos Gracias, en especial a mi familia por tanto apoyo brindado en estos años de tanto esfuerzo y dedicación. A mi padre, que gracias a sus charlas y consejos me han ayudado a lograr mi mayor objetivo. A mi madre, que con su apoyo y cariño ha conseguido que cada día tuviera ilusión por ir a la Escuela. A mis profesores, con los que he aprendido y disfrutado mucho de este maravilloso Grado, ya que de todos y cada uno de ellos he aprendido algo. A mi novia, por aguantarme y seguir apoyándome a pesar de cualquiera de las circunstancias que se acontecieran. Gracias por estos años tan especiales. Javier Saavedra Galiano Sevilla, 2019 xvi xvii ÍNDICE DE ILUSTRACIONES Ilustración 1: Arquitectura del Sistema 3 Ilustración 2: Sensor U-Blox NEO-6M 7 Ilustración 3: Raspberry Pi Model B+ 8 Ilustración 4: Ordenador portátil ASUS 9 Ilustración 5 - Logo VMware 10 Ilustración 6: Logo Ubuntu 10 Ilustración 7: Logo Postman 10 Ilustración 8: Interfaz gráfica Postman 11 Ilustración 9: Comando Curl en Postman 12 Ilustración 10: Logo Python 15 Ilustración 11: Logo Docker-compose 16 Ilustración 12: Logo Docker 16 Ilustración 13: Logo Orion Context Broker 16 Ilustración 14: Logo Keyrock 17 Ilustración 15: Logo MySQL 17 xviii Ilustración 16: Logo mongoDB 17 Ilustración 17: Esquema básico de una Smart-Solution 19 Ilustración 18: Entidad que muestra datos sobre una tienda 20 Ilustración 19: Comunicación con el Context Broker 21 Ilustración 20: Arquitectura FIWARE usando Cygnus 22 Ilustración 21: Arquitectura de un sistema Fiware usando MQTT 24 Ilustración 22: Formato de mensajes usando el protocolo MQTT 24 Ilustración 23: Formato de mensajes usando el protocolo Ultralight 25 Ilustración 24: Arquitectura de un sistema Fiware usando Ultralight 25 Ilustración 25: Ejemplo de mashup de aplicaciones usando Wirecloud 26 Ilustración 26: Página de inicio de sesión en Keyrock 31 Ilustración 27: Arquitectura de un sistema con nivel de seguridad intermedio 32 Ilustración 28: Gestión de roles y permisos en Keyrock 33 Ilustración 29: Ventana de asignación de usuarios y roles. 34 Ilustración 30: Arquitectura del sistema con nivel de seguridad avanzado. 35 Ilustración 31: Métodos de autenticación usando el protocolo OAuth2 en Keyrock 36 Ilustración 32: Arquitectura del sistema 38 Ilustración 33: Mensaje POST enviado al agente IOT. 39 Ilustración 34: Creación de la entidad encargada de almacenar la información de contexto. 40 Ilustración 35: gps.py 41 Ilustración 36: Resultado de la ejecución del programa gps.py 42 Ilustración 37: Petición HTTP GET a Orion para consultar los valores del dispositivo Move01 42 Ilustración 38: Parejas clave/valor del dispositivo Move01 43 Ilustración 39: Registro de usuario en Keyrock 44 Ilustración 40: Página de bienvenida de Keyrock 45 Ilustración 41: Petición de un token de acceso a Keyrock 46 Ilustración 42: Cuerpo de la petición de token de acceso a la aplicación. 46 Ilustración 43: Respuesta correcta da la petición de un token de acceso 46 Ilustración 44: Petición GET al proxy PEP para obtener los datos del sensor GPS con token válido 47 Ilustración 45: Respuesta de la petición GET que pedía la información de contexto de MOVE. 47 Ilustración 46: Petición GET al proxy PEP para obtener los datos del sensor GPS con token no válido 47 Ilustración 47: Mensaje de respuesta al enviar un token erróneo 48 Ilustración 48: Raspberry Pi Model B+ conectado a sensor U-Blox NEO-6M 53 Ilustración 49: Conexiones de Raspberry Pi Model B+ 54 Ilustración 50: Conexiones del sensor GPS 54 Ilustración 51: Resultado de la ejecución del programa gps.py 56 Ilustración 52: Resultado de la ejecución del comando docker --version 60 Ilustración 53: Resultado de la ejecución del comando docker-compose --version 60 Ilustración 54: Script de servicio para la puesta en marcha del sistema 61 xix Ilustración 55: Función waitForKeyrock 61 Ilustración 56: Función displayServices 62 Ilustración 57: Función startContainers 62 Ilustración 58: Función stoppingContainers 62 Ilustración 59: Contenedor Orion en archivo orion.xml 62 Ilustración 60: Contenedor IoT-Agent en el archivo orion.yml 63 Ilustración 61: Contenedor Keyrock en el archivo orion.yml 64 Ilustración 62: Contenedor de Proxy PEP Wilma en el archivo orion.yml 65 Ilustración 63: Resultado de la ejecución del comando sudo ./services orion 67 xx 1 1 INTRODUCCIÓN 1.1 Motivación ste proyecto se ha desarrollado para analizar la actual situación de las aplicaciones del IoT 2 en lo que a seguridad se refiere. Se ha realizado un sistema basado en la plataforma FIWARE en el que se utiliza un sensor GPS para la recogida de datos, conectado a una Raspberry Pi para poder enviar la información recogida por el sensor al resto de componentes que forman nuestro sistema. En este proyecto se han incorporado nuevos elementos que mejoran los aspectos de seguridad como la autenticación y la gestión de permisos de nuestra smart-solution. La plataforma FIWARE es una plataforma impulsada por la Unión Europea que empezó a desarrollarse en el año 2011. Esta plataforma es una iniciativa Open Source 3 cuyo objetivo es el desarrollo de aplicaciones y soluciones destinadas principalmente para la Smart City 4 . Al ser una plataforma Open Source, tiene una gran comunidad de desarrolladores que aportan sus conocimientos e ideas innovadoras a esta iniciativa[2]. En cualquier smart-solution es necesario recopilar y administrar información de contexto, procesar esa información e informar a los actores externos, lo que les permite actuar y, por lo tanto, modificar el contexto actual en base a la información recopilada. El componente FIWARE Context Broker es el componente principal de cualquier plataforma "Powered by FIWARE", el cual proporciona la API 5 NGSIv2. Esta API permite realizar actualizaciones, consultas o suscribirse a cambios en la información de nuestro sistema [3]. FIWARE proporciona componentes para mejorar la seguridad de las Smart-soluitions que utilicen su plataforma. El componente principal es Keyrock, el cuál se encarga de la gestión de la identidad basado en protocolos como OAuth2, lo que nos permite administrar la autenticación de usuarios y dispositivos, gestionar perfiles de los usuarios registrados en nuestro sistema y preservar la privacidad de los datos personales [4]. 2 Internet of Things: Concepto que comprende la conexión a internet de cualquier dispositivo cotidiano. 3 Plataforma de código abierto: La licencia forma parte del dominio público. 4 Ciudad inteligente: Ciudad que está dotada de sensores y actuadores, integradas en una Smart solution. 5 Application Programming Interface: Las API permiten que sus productos y servicios se comuniquen con otros, sin necesidad de saber cómo están implementados. E 2 2 Mecanismos de seguridad de la plataforma FIWARE 1.2 Objetivos El objetivo principal de este proyecto es analizar e implementar las herramientas de seguridad que proporciona la plataforma FIWARE para el desarrollo de Smart-solutions. Para ello se desarrollará un sistema que cuenta con un sensor GPS encargado de la recogida de datos, conectado a un agente IOT que se encarga de traducir los mensajes que envían los dispositivos IOT a mensajes en formato NGSI 6 . Al bloque anterior se le conecta el Context Broker, que se encarga de actualizar la información de contexto que envía el agente IOT y, finalmente, se incorporan las figuras encargadas de proveer seguridad a nuestro sistema. Por un lado, se incorpora el componente Keyrock, que se encargará de la gestión de identidad de los usuarios que formen parte de nuestro sistema. En segundo lugar, se añade el proxy PEP 7 Wilma, encargado de permitir o denegar las peticiones procedentes de las aplicaciones en función de los permisos que tenga el usuario y la aplicación que los envíe. Para la comprobación del correcto funcionamiento del sistema, se utilizará una aplicación web sin interfaz gráfica. 1.3 Antecedentes El punto de partida de este proyecto es el Trabajo de Fin de Grado de Luis Martínez Ruiz [2], realizado en el año 2018. En dicho proyecto se desarrolla un sistema formado por los siguientes componentes: Un sensor GPS, un giroscopio/acelerómetro, una Raspberry Pi, un Context Broker (Orion) y finalmente un dashboard (Freeboard) para la representación de los datos recogidos por los dispositivos IOT del sistema. En el presente proyecto, se ha hecho una ampliación del sistema indicado anteriormente y se han llevado a cabo una serie de mejoras respecto a la versión anterior del mismo. En primer lugar, se ha incorporado la figura del agente IOT, el cuál facilita la comunicación entre el Context Broker y los dispositivos IOT. En nuestro caso el dispositivo IOT está formado por un sensor GPS, cuyos datos transmite la Raspberry Pi. En segundo lugar, se añaden los componentes Keyrock y Wilma, encargados de proporcionar herramientas de seguridad en el acceso a los datos. Finalmente, se ha prescindido de la figura del dashboard 8 para la representación de los datos, ya que este no es compatible con todas las funcionalidades que proporciona Keyrock. En lugar de un dashboard, se ha elegido el software Postman para realizar peticiones HTTP a las diferentes APIs que proporcionan componentes del sistema. 1.4 Descripción de la solución En este apartado se explicará los componentes que forman el sistema y se detallarán las funciones de cada uno de ellos. 6 API Rest desarrollada por Fiware que permite la comunicación entre los diferentes componentes de Fiware y Orion Context Broker. 7 Policy Execution Point: Punta de ejecución de Políticas 8 Aplicación que permite la visualización mediante widgets de los datos. 3 3 Mecanismos de seguridad de la plataforma FIWARE 1.4.1 Arquitectura del Sistema Ilustración 1: Arquitectura del Sistema 1.4.2 Funcionalidades En esta sección se procede a explicar de forma general los diferentes componentes que conforman el sistema. Para ello, se va a dividir el sistema en cuatro bloques funcionales. • Bloque 1: Este bloque lo forman el sensor GPS y la Raspberry Pi B+. Su función es la de recoger información de interés a partir del sensor para su posterior procesamiento y tratamiento. Esta información se envía a la Raspberry Pi, la cual recupera esta información mediante un programa desarrollado en el lenguaje Python. • Bloque 2: Este bloque lo forman el agente IOT, Orion Context Broker y MongoDB. La función de este bloque es la más compleja, ya que es la pieza central de nuestro sistema. El agente IOT procesa la información que recibe de la Rapsberry Pi para que Orion pueda almacenar los datos de interés en la base de datos MongoDB. El agente IOT recibe mensajes en formato Ultralight de la Raspberry y los traduce al mensajes en formato NGSI para que Orion pueda almacenar esa información de contexto en MongoDB. • Bloque 3. Este bloque lo forman Wilma PEP Proxy, Keyrock y MySQL. Estos componentes son los encargados proveer diversos mecanismos de seguridad, tales como autenticación y gestión de permisos a partir de unos roles determinados. Keyrock es la pieza central de este bloque, ya que es el encargado de decidir si permite o deniega el acceso por parte de un usuario o aplicación a cierta información. En nuestro sistema Keyrock ocupa la figura de PDP 9 . El siguiente componente es el proxy PEP Wilma, cuya función es permitir o denegar el acceso a un recurso del sistema en función de la decisión que tome el PDP. Para la gestión de la autenticación se utiliza una base de datos Mysql, con la cuál se comunica Keyrock para tomar las decisiones. • Bloque 4: Este bloque lo conforma únicamente el programa Postman. Este programa será el encargado de realizar todas las tareas dentro de nuestro sistema, ya que carecemos de aplicaciones web con interfaz gráfica o dashboards compatibles con las funcionalidades que nos proporciona Keyrock. Estas tareas se llevarán a cabo a través de peticiones HTTP a las diferentes APIs del sistema en función de la tarea que se quiera realizar. 9 Policy Decision Point: Punto de decisión de Políticas. 4 4 Mecanismos de seguridad de la plataforma FIWARE 1.5 Estructura de la memoria En este apartado se proporciona a modo de guía, un breve resumen de los apartados que componen la memoria: 1. Introducción: Explicación del sistema desarrollado y de la necesidad del mismo. 2. Recursos utilizados: Muestra los recursos empleados para el desarrollo de la smart-solution. Esto incluye los recursos software y hardware necesarios para el correcto funcionamiento del Sistema. 3. Tecnologías utilizadas: Introducción de las diferentes tecnologías utilizadas en el Sistema. 4. Plataforma FIWARE: Explicación amplia de FIWARE en la que se detallan los diferentes componentes que lo forman. 5. Mecanismos de seguridad en FIWARE. Estudio de los diferentes mecanismos de seguridad que ofrece FIWARE y su integración en el sistema. 6. Smart-Solution desarrollada: Explicación de cada uno de los componentes del Sistema desarrollado y sus funcionalidades. 7. Conclusiones y líneas futuras: Tras el Desarrollo del Proyecto, se exponen las diferentes concluiiones obtenidas e ideas para futuras aplicaciones que tengan como punto de partida el presente Proyecto. Finalmente se ofrece una serie de anexos a modo de manual para poder hacer uso del Sistema desarorollado: - Anexo A: Configuración de Rapsberry Pi y sensor GPS. - Anexo B: Instalación de los componentes del sistema. 5 5 Mecanismos de seguridad de la plataforma FIWARE 12 12 Mecanismos de seguridad de la plataforma FIWARE Ilustración 9: Comando Curl en Postman Una vez se accede a la ventana de la Ilustración 9, se elige en la esquina superior izquierda el formato que deseamos del código, que en nuestro caso sera Curl. 13 13 Mecanismos de seguridad de la plataforma FIWARE 15 3 TECNOLOGÍAS UTILIZADAS e procede a detallar en este capítulo cada una de las tecnologías empleadas para el desarrollo de la Smartsolution. Cabe destacar que se comentará todo tipo de tecnologías empleadas, desde lenguajes de programación a las diferentes herramientas utilizadas. 3.1 Python Python es el lenguaje de programación que se ha usado para interpretar los datos recogidos por el sensor GPS y por el giroscopio/acelerómetro. También se ha empleado esta tecnología para enviar los datos de los sensores desde la Rapsberry Pi hasta el agente IOT, mediante peticiones HTTP POST [10]. La decision de utilizar esta tecnología se debe a que Python dispone de librerías como gpsd que recogen los datos de los sensores conectados a los puertos de la Raspberry Pi. 3.2 Docker y Docker-compose Docker es la tecnología elegida para alojar el grueso de los componentes que forman el sistema. Esta tecnología utiliza el kernel de Linux y las herramientas de este para separar los procesos, lo cual permite la ejecución de cada uno de los mismos de forma independiente. Cada uno de estos procesos están ejecutándose en contenedores independientes unos de otros, lo cuál conserva la seguridad de estos procesos al funcionar como sistemas separados [11]. S Ilustración 10: Logo Python 16 16 Mecanismos de seguridad de la plataforma FIWARE Esta tecnología ofrece un modelo basado en imágenes, es decir, permite obtener una aplicación o servicio junto a todas y cada una de las dependencias necesarias para poder usarlas. Para simplificar el uso de Docker se ha utilizado la herramienta Docker-compose, la cuál permite generar scripts que facilitan el diseño y la construcción de estos servicios [12]. Con esta herramienta se pueden definir y ejecutar aplicaciones Docker multi-contenedor, como es el caso de este proyecto. Se detallará la configuración y uso de Docker y Docker-compose en el anexo B. 3.3 Orion Context Broker Orion Context Broker es la piedra angular del Sistema. Se trata de una implementación en C++ de la API REST NGSIv2. Orion Context Broker permite gestionar la información de contexto mediante actualizaciones, consultas, registros y subscripciones [13]. Esto es posible gracias a elementos de contexto como las entidades, en las cuales se almacena la información de contexto para su posterior tratamiento. Se entrará más en detalle en el Capítulo 4. Ilustración 12: Logo Docker Ilustración 11: Logo Docker-compose Ilustración 13: Logo Orion Context Broker 17 17 Mecanismos de seguridad de la plataforma FIWARE 3.4 Keyrock y Wilma PEP Proxy Keyrock ocupa la figura de Identity Manager 13 dentro del sistema. La gestión de identidad concede derechos individuales para acceder a determinados recursos en un momento concreto y por unas razones determinadas [4]. Esta herramienta de FIWARE proporciona una serie de componentes separados encargados de comprobar quíen o qué tiene acceso a cada uno de los recursos dentro del sistema, todo ello conociendo de antemano la identidad de la figura que realice la petición de acceso a cada recurso. Keyrock es el PDP del sistema, es decir, se encarga de tomar la decisión de permitir o denegar las peticiones que hacen los componentes del sistema , ya sea una aplicación o un usuario, en base a los permisos que estos tengan. A este componente se le añade la figura del proxy PEP Wilma [14], cuya función de es de ejercer la decisión que tome Keyrock respecto a las peticiones que se produzcan. Se entrará más en detalle en el Capítulo 5. 3.5 MongoDB y MySQL MongoDB y MySQL son los sistemas de base de datos utilizados en el sistema. MongoDB se usa para almacenar la información de contexto que registran tanto Orion Context Broker como el agente IOT. MySQL es el encargado de almacenar la información de autenticación y permisos que gestiona Keyrock. MongoDB es un sistema de base de datos NoSQL 14 que almacena la información en estructuras de datos BSON 15 . Es una base de datos orientada a documentos, ya que en vez de almacenar la información en tablas y registros como se hacía tradicionalmente, se almacenan los datos en documentos [15]. MySQL es un sistema de base de datos relacional, es decir, utiliza tablas que se relacionan entre sí para almacenar la información y seguir una organización eficiente. Para el acceso y manejo de los datos en MySQL se utiliza el lenguaje SQL [16]. 13 Gestor de identidad: Es la entidad responsable de la gestión de la identidad en un sistema. 14 Son aquellos sistemas de bases de datos que no utilizan SQL para su gestión. 15 Consiste en un formato de intercambio de datos basado en el término JSON (JSON Binario) Ilustración 14: Logo Keyrock Ilustración 16: Logo mongoDB Ilustración 15: Logo MySQL 18 18 Mecanismos de seguridad de la plataforma FIWARE 19 4 PLATAFORMA FIWARE 4.1 Introducción a FIWARE FIWARE es una iniciativa impulsada por la Unión Europea cuya finalidad es favorever el desarrollo de aplicaciones y soluciones principalmente vinculadas a las Smart Cities. Esta iniciativa Open Source se desarrolló en el año 2011 y cuenta con una amplia comunidad de desarrolladores que siguen aportando ideas para el continuo crecimiento de esta plataforma. También cuenta con el respaldo de importantes empresas como Atos, Telefónica y NEC entre otros [17]. Esta plataforma tiene como principal objetivo construir un ecosistema abierto basado en estándares de dominio público y en herramientas que faciliten el desarrollo de nuevas aplicaciones inteligentes, capaces de adaptarse a cualquier sector. Este proyecto se ha podido desarrollar gracias a la extensa documentación que aporta esta plataforma a los desarroladores. Estos estándares reciben el nombre de Generic Enablers 16 . FIWARE proporciona una serie de Generic Enablers para facilitar el desarrollo de aplicaciones y ahorrarles tiempo de desarrollo a aquellos que decidan realizar una Smart-Solution. Estos estándares son desarrollados por empresas de terceros y proporcionan APIIs cuyas especificaciones son públicas. Para que una herramienta reciba el nombre de FIWARE Generic Enabler, el desarrollador debe solicitar a FIWARE que dicha herramienta forme parte de su catalogo, cumpliendo previamente una serie de condiciones. Para desarrollar una smart-solution no es necesario el uso de todos y cada uno de los Generic Enablers que existen, el único componente indispensable es el Context Broker. El resto de Generic Enablers sirven como complemento al Context Broker, y se discutirá la utilidad de estos en función de la aplicación a desarrollar[18]. Las Smart-solutions tienen como principal característica la recogida de datos de contexto desde dispositivos IOT. Estos dispositivos pueden ser sensores, aplicaciones móviles etc. Esta información se recopila y se administra para tomar decisiones en base a los datos obtenidos. 16 Componente estándar que proporciona la plataforma Fiware. Ilustración 17: Esquema básico de una Smart-Solution 20 20 Mecanismos de seguridad de la plataforma FIWARE 4.2 FIWARE Generic Enablers En esta sección se procede a explicar los diferentes Generic Enablers que proporciona FIWARE y las funcionalidades que aportan los mismos. 4.2.1 Core Context Management 4.2.1.1 Orion Context Broker El componente principal de cualquier Smart-solution "Powered by FIWARE" es Orion Context Broker. Este estándar proporciona mecanismos de administración, actualización, registro y subscripción a la información de contexto del sistema [19]. Orion organiza la información de contexto en entidades, de forma que estas se puedan relacionar entre sí fácilmente. Estas entidades representan información del mundo real y son accedidas desde los diferentes componentes del sistema donde cada uno de ellos realiza una acción sobre la información de contexto almacenada. Los campos imprescindibles en toda entidades son: • Id: Identificador único en el sistema que identifica unívocamente a la entidad. • Type: Identifica el tipo de la entidad. Este campo se utiliza para identificar el objeto del mundo real en el sistema. • Atributos: Muestran los datos del mundo real de la entidad en cuestión. Estos atributos dependerán del tipo de la entidad. Por ejemplo, la entidad “termómetro” tendrá un atributo de nombre “temperatura”. Ilustración 18: Entidad que muestra datos sobre una tienda 21 21 Mecanismos de seguridad de la plataforma FIWARE La principal carácteristica de Orion Context Broker es que implementa la API NGSIv2, la cual permite actualizar, consultar y subscribirnos a la información de contexto, la cuál se encuentra almacenada en entidades. NGSI es una API Rest que permite la comunicación mediante mensajes HTTP entre los diferentes componentes del sistema. Con estos mensajes HTTP se accede a la información de las entidades, ya sea modificándola, consultándola, etc. Los datos se recogen en la capa de gestión por sensores, robots o sistemas de terceros y se almacenan temporalmente en el Context Broker, es decir, Orion solo almacena el último dato recibido por la capa de adquisición de datos. Con el objetivo proporcionar una capa de persistencia a los datos que maneja Orion, este se comunica con un gestor de base de datos para almacenarlos [20]. Ilustración 19: Comunicación con el Context Broker Existen dos tipos de componentes que actúan sobre el Context Broker: • Context Producers: Aquellos dispositivos IOT capaces de recoger información y enviarsela al context broker en el formato correcto. • Context Consumers: Son aquellos que interactúan con el context broker para consultar o modificar la información de contexto almacenada. Lo normal es que esta figura sea una aplicación que haga peticiones a la API NGSI que implementa el context broker. 4.2.1.2 STH Comet STH 17 Comet es un componente del ecosistema FIWARE encargado de almacenar y recuperar la información histórica de los datos de contexto registrados de una instancia de Orion Context Broker. Todas las comunicaciones que se establecen con Comet están estandarizadas por la API NGSI [21]. Con este componente se puede analizar el comportamiento de una entidad observando los datos brutos 18 históricos almacenados en Orion Context Broker en un intervalo de tiempo. Para su correcto funcionamiento, Comet se basa en los siguientes conceptos: 17 Short Time Historic: Histórico de tiempo limitado. 18 Estado en que se encuentra la información al obtenerse del mundo real. 28 28 Mecanismos de seguridad de la plataforma FIWARE • Análisis del habla. La integración de todas estas características son posibles gracias a la arquitectura modular de este Generic Enabler. Gracias a ello se integran multitud de algoritmos de procesamiento de terceros que los desarrolladores de aplicaciones pueden usar de forma transparente. Los protocolos de comunicación empleados pueden ser: - HTTP - RTP - WebRTC. 29 29 Mecanismos de seguridad de la plataforma FIWARE 30 5 SEGURIDAD EN FIWARE ste capítulo trata de estudiar las diferentes herramientas que proporciona FIWARE para mejorar la seguridad de las Smart-Solutions. Hasta el momento, se han visto las diferentes herramientas que FIWARE pone a disposición de los desarrolladores para que lleven a cabo sus Smart-Solutions y realicen las funcionalidades que deseen. En este capítulo, se tratarán todos los aspectos de seguridad que tiene que ver con un sistema FIWARE. Se analizarán los diferentes protocolos que se han empleado para el transporte de datos, asi como los mecanismos de seguridad proporcionados por los Generic Enablers que ofrece FIWARE, entre los que destaca Keyrock. También se explicará cómo se relacionan el resto de Generic Enablers con cada uno de los componentes cuya función es proporcionar seguridad al sistema. 5.1 Keyrock Identity Management Keyrock es el componente principal encargado de proveer al sistema de la seguridad necesaria para que la información de contexto sea accedida por aquellos componentes que tengan los permisos necesarios para hacerlo. Keyrock proporciona mecanismos para gestionar la identidad, de forma que se pueda conocer en todo momento quién o qué está accediendo a la información de contexto del sistema. También proporciona una API propia con la que llevar a cabo tareas de seguridad que se detallarán mas adelante. Para administrar Keyrock, se establece un usuario por defecto en la instalación del mismo, cuya contraseña se recomienda cambiar al momento de la instalación. Con este usuario administrador, se procede a gestionar el acceso de los diferentes componentes del sistema a los datos. Para poder gestionar la seguridad del sistema, Keyrock ofrece una interfaz gráfica en la que se acceden a diferentes herramientas de gestión. El primer paso para empezar a gestionar la seguridad del sistema es acceder a la página de inicio de sesión y loguearse con un usuario ya existente o el usuario administrador creado al instalar esa herramienta. El acceso a la interfaz gráfica se configura en la instalación de Keyrock. Se explica con más detalle en el anexo B.2. En nuestro caso, para acceder a la interfaz gráfica introduciremos en un navegador la dirección http://localhost:3005 . E 31 31 Mecanismos de seguridad de la plataforma FIWARE Ilustración 26: Página de inicio de sesión en Keyrock Una vez se ha iniciado sesión con un usuario válido, se muestran las diferentes funcionalidades que dispone Keyrock, desde donde se pueden gestionar todos los aspectos de seguridad citados anteriormente. 5.1.1 Nivel Básico de Seguridad El nivel básico de seguridad se adquiere cuando el sistema dispone de un mecanismo de autenticación capaz de tener multitud de usuarios asociados a varias aplicaciones. Cada usuario tendrá acceso a los recursos que la aplicación a la que estén registrados permita. Con este nivel podremos permitir o denegar desde Keyrock el acceso a todos o a ninguno de los recursos en función de si el usuario es válido o no. Para hacer efectivo este nivel de seguridad es necesario tener un usuario registrado en Keyrock. Esto se puede hacer desde la página de inicio de sesión. Se entrará más en detalle en el Capítulo 6. Una vez haya un usuario registrado en Keyrock, este debe estar asociado a una o varias aplicaciones a través de las cuales acceder a la información de contexto. Para que una aplicación pueda hacer uso de las funcionalidades de Keyrock, esta debe estar registrada. Este paso se detalla en el Capítulo 6. Llegados a este punto, se ha registrado una aplicación y un usuario capaces de acceder a los recursos del sistema. Es decir, si un usuario está registrado en una aplicación, que a su vez está registrada en Keyrock, el usuario puede acceder a la información de contexto almacenada. En este nivel de seguridad, Keyrock ejerce como PDP. Es decir, Keyrock es el encargado de tomar la decisión de aceptar o denegar el acceso de un usuario en función de si el usuario es válido o no [32]. 5.1.1.1 Proxy PEP Wilma Para proporcionar el nivel básico de seguridad, necesitamos de la figura del proxy PEP Wilma. Este es el componente intermedio entre la aplicación y Keyrock. Es el encargado de ejercer la decisión que toma Keyrock respecto de la petición de acceso a un recurso determinado. En este esquema de funcionamiento, Keyrock ejerce de PDP y Wilma ejerce de PEP. Este proxy PEP es el encargado de permitir a los usuarios la capacidad de acceder a los Generic Enablers de nuestro sistema y a los servicios REST. De hecho, el componente con el que los usuarios tendrán que interactuar mediante la API NGSI es con el proxy PEP, ya que será el componente que ejecute la decisión tomada por keyrock. Dicha respuesta la comunica el proxy PEP, informando de que se ha aceptado o denegado la solicitud. Este componente carece de interfaz gráfica alguna, su configuración se lleva a cabo en el momento de la instalación [33]. 32 32 Mecanismos de seguridad de la plataforma FIWARE 5.1.2 Nivel Intermedio de Seguridad El nivel intermedio de seguridad se obtiene a partir de la asignación de roles a los usuarios que componen el sistema. Una vez se hayan establecido los roles que necesite la aplicación, se establecen una serie de permisos a cada uno de estos roles. Los usuarios pueden pertenecer a una o varias organizaciones, cuya función es proporcionar permisos comunes a todos aquellos que pertenezcan a la misma organización. Por ejemplo, la organización de “administración” dispondrá de diferentes permisos que la organización de “solo acceso”. Para asignar nuevos roles se accede a la página de la aplicación y se pulsa el botón “Manage Roles”. En este menú se podrán crear o eliminar los roles asociados a la aplicación. A cada uno de estos roles se les pueden asignar permisos. Ilustración 27: Arquitectura de un sistema con nivel de seguridad intermedio 33 33 Mecanismos de seguridad de la plataforma FIWARE Para crear un nuevo permiso, basta con pulsar en el símbolo “+” situado en la parte superior izquierda de la página de “Gestión de Roles”. Para crear un nuevo permiso, se deben rellenar los siguientes campos: - Nombre del permiso. - Descripción del permiso - Acción HTTP: Se decide que acción HTTP es la que se evalúa en este permiso. Suelen ser peticiones HTTP GET o HTTP POST. - Recurso: Se indica el recurso al que se permite acceder a la aplicación. Es decir, keyrock limita las acciones que puede realizar cada usuario en función de este campo. Por ejemplo, si se desea cambiar el precio de un elemento y la URL que lleva a cabo dicha acción en la aplicación acaba en “/app/pricechange”, este texto es el que se pondría en el campo de recurso. Por último, para asignar usuarios a aplicaciones, basta con entrar en el detalle de la aplicación y, en la sección “Usuarios autorizados” pulsar sobre el botón “Autorizar”. Finalmente añadimos el usuario en cuestión y le asignamos un rol o roles para esta aplicación. Ilustración 28: Gestión de roles y permisos en Keyrock 34 34 Mecanismos de seguridad de la plataforma FIWARE Con este nivel de seguridad, cada aplicación ofrece un control en el acceso a la información de contexto que maneja dicha aplicación. 5.1.3 Nivel avanzado de Seguridad El nivel avanzado de seguridad se alcanzaría con la implementación en nuestro sistema de Authzforce, cuya función en el sistema es de ejercer de PDP. Esta herramienta proporciona una API para obtener decisiones de autorización basadas en unas políticas determinadas y en las peticiones de autorización procedentes de los PEPs. La API proporcionada es una API REST y está compilado en XACML 23 . XACML es un estánar OASIS 24 que describe el formato de las políticas de autorización y lógica de evaluación. También se definen el formato de la solicitud o respuesta de la decisión de autorización. Todo ello recogido en un archivo en formato XML [34]. Este componente ofrece dos APIs: • PDP API: Proporciona una API a partir de la cuál obtener decisiones de autorización definidas en XACML. • PAP 25 API: Proporciona una API para la gestión de políticas XACML que serán utilizadas por el servicio de Autorización PDP. 23 eXtensible Access Control Markup Language: Lenguaje extensible de marcas de acceso de control. 24 Consorcio internacional orientado al desarrollo, convergencia y adopción de estándares de comercio electrónico y servicios web. 25 Policy Administration Point: Punto de administración de Políticas Ilustración 29: Ventana de asignación de usuarios y roles. 35 35 Mecanismos de seguridad de la plataforma FIWARE Ilustración 30: Arquitectura del sistema con nivel de seguridad avanzado. Con esta nueva arquitectura, observamos que el PEP es el proxy PEP Wilma y el PDP es Authzforce. Keyrock deja de tener el papel de PDP en este caso, ya que delega la decisión final en Authzforce [33]. Este componente es útil si el sistema tiene una gran complejidad, ya que proporciona gran variedad de mecanismos de seguridad. Pero para la mayoría de sistemas, esta herramienta carece de utilidad al no sacarle partido y no usar la gran mayoría de utilidades que ofrece. 5.1.4 OAuth2 OAuth2 es un protocolo de autorización que surgió a partir del nacimiento de las redes sociales. Permite que los usuarios autoricen a terceros a acceder a su información sin necesidad de que estos conozcan las credenciales del usuario [35]. Las entidades involucradas en el flujo OAuth2 son: • Propietario de recursos: Componente encargado de autorizar el acceso a los recursos protegidos. Se puede elegir la autorización a unos recursos y a otros no. En general esta figura es un humano • Cliente: Sitio Web o aplicación que accederá a los recursos protegidos de un usuario con la autorización del mismo. 36 36 Mecanismos de seguridad de la plataforma FIWARE • Proveedor: o Servidor de autenticación: Valida usuario y credenciales y genera tokens de acceso. o Servidor de recursos: Recibe peticiones de acceso a los recursos protegidos autorizando el acceso si el token incluido en la petición es válido. Las diferentes opciones para acceder a los recursos protegidos son: - Acceso en función de credenciales: Este método es el más usado tradicionalmente. Se inicia sesión en una aplicación web y se comprueba que las credenciales son correctas viendo si coincide con los datos almacenados en el sistema. En caso positivo, el sistema otorga un token de acceso al sistema. - Solicitud de código de autorización: La entidad cliente envía una petición con una serie de parámetros completados al propietario de los recursos. El usuario accede con sus credenciales y acepta la petición del cliente a acceder a ciertos recursos. Automáticamente se redirigirá a la url configurada incluyendo el código de autorización, que le dará acceso al recurso en cuestión. Finalmente, se intercambiará el código de autorización por un token de acceso. Un ejemplo claro del uso de este protocolo es el registro en multitud de aplicaciones de terceros, que ofrecen la posibilidad de registro a partir de la cuenta de Facebook. El usuario accede con las credenciales de facebook y la aplicación en cuestión recoge los datos necesarios para su registro [33]. Ilustración 31: Métodos de autenticación usando el protocolo OAuth2 en Keyrock 37 37 Mecanismos de seguridad de la plataforma FIWARE 44 44 Mecanismos de seguridad de la plataforma FIWARE Para ello, se accede a la página de inicio de sesión http://localhost:3005 y se registra por primera vez, completando los campos: - Nombre de usuario - E-mail - Password (2 veces para confirmar) - Aceptar los términos y condiciones de FIWARE Lab. Una vez se cree el usuario, el administrador debe activarlo desde la página de gestión de usuarios. Estos nuevos usuarios se almacenan en la base de datos mySQL[31]. Ilustración 39: Registro de usuario en Keyrock 45 45 Mecanismos de seguridad de la plataforma FIWARE 6.3.2.2 Registro de aplicación en Keyrock Una vez se dispone del usuario para acceder a la herramienta Keyrock, se inicia sesión. Ilustración 40: Página de bienvenida de Keyrock En segundo lugar, se ofrece un mecanismo de registro de aplicaciones que harán uso de este Generic Enabler. Para registrar una aplicación es necesario completar los siguientes campos: • Nombre de la aplicación. • Descripción de la aplicación. • URL en la que se encuentra alojada la aplicación. • Callback URL: URL a la que Keyrock redirigirá el flujo una vez se haya completado el proceso de autenticación. • Sign-out Callback URL: URL a la que Keyrock redirigirá el flujo una vez se haya completado el cierre de la sesión del usuario, tanto de la aplicación como de Keyrock. • Grant Type: Se establecen los métodos que se podrán emplear en la aplicación para verificar la identidad del usuario, los cuales los proporciona el protocolo de autorización OAuth2, detallados posteriormente. • Provider: Establece el usuario propietario de la aplicación o la organización encargada. En este proyecto, no es necesaria la configuración de la aplicación, ya que no se dispone de aplicación alguna. Se carece de aplicación web que haga uso de los datos recogidos. También se prescinde de dashboards, ya que la mayoría no son compatibles con las funcionalidades que ofrece Keyrock. No obstante, se puede comprobar la seguridad del sistema simplemente mediante la autenticación de los usuarios, sin importar a qué aplicación pertenezcan. Una vez registrada la aplicación, se entra al detalle de dicha aplicación. Ahora, es necesario copiar los campos “Client ID”y “Client ID Secret” concatenarlos en una línea y separado por el caracter “:”, con ClientIdSecret a continuación de ClientID. Posteriormente, se busca un codificador base 64 y se anota el resultado de la codificación. 46 46 Mecanismos de seguridad de la plataforma FIWARE 6.3.2.3 Acceso autorizado a la información de contexto Una vez hemos tenemos todos los requisitos, solicitamos información de contexto al proxy PEP, ya que es el componente con el que debemos comunicarnos para acceder a los datos almacenados en el context broker de forma segura. En primer lugar, se inicia sesión para que Keyrock nos conceda un token de acceso para acceder a los recursos de nuestro sistema. Ilustración 41: Petición de un token de acceso a Keyrock En esta petición se pueden observar las siguientes cabeceras: • Authorization: Basic dhV….: Esta cabecera indica el nivel de seguridad del sistema junto al client id y client id secret codificado en base 64. • El cuerpo del mensaje es el siguiente: En el cuerpo del mensaje simplemente se indican las credenciales y el tipo de autenticación que van a llevar a cabo. La respuesta, en caso de que el usuario sea válido, es la siguiente: Una vez obtenido el token de acceso que permite consultar la información de contexto almacenada en el Context Broker, se procede a realizar una petición de consulta de los datos recogidos por el sensor GPS al proxy PEP. Es importante diferenciar las peticiones, ya que la comunicación con el PEP Proxy requiere de un token de acceso siempre, mientras que si se establece la comunicación con Orion Context Broker, este no solicita ningún tipo de autenticación. Ilustración 42: Cuerpo de la petición de token de acceso a la aplicación. Ilustración 43: Respuesta correcta da la petición de un token de acceso 47 47 Mecanismos de seguridad de la plataforma FIWARE Como se puede observar, se requiere de una cabecera de nombre “X-Auth-Token” en la que va una cadena aleatoria generada previamente por Keyrock y que se ha recuperado del mensaje de respuesta al inicio de sesión. También es necesaro incluir el nombre del grupo de servicio (TFG) y el fiware-servicepath (/). La respuesta a dicha petición es: Ilustración 45: Respuesta de la petición GET que pedía la información de contexto de MOVE. 6.3.2.4 Acceso no autorizado a la información de contexto Para ilustrar un ejemplo de acceso no deseado, se procede a hacer una petición a los mismos recursos que en el apartado anterior en el que el token de acceso es inválido. Ilustración 44: Petición GET al proxy PEP para obtener los datos del sensor GPS con token válido Ilustración 46: Petición GET al proxy PEP para obtener los datos del sensor GPS con token no válido 48 48 Mecanismos de seguridad de la plataforma FIWARE El mensaje de respuesta será el siguiente: Por tanto, se ha demostrado que el sistema tiene un nivel de seguridad básico, ya que es capaz de permitir o denegar el envío de información de contexto en base a si un usuario es válido o no. Ilustración 47: Mensaje de respuesta al enviar un token erróneo 49 49 Mecanismos de seguridad de la plataforma FIWARE 50 7 CONCLUSIONES Y LÍNEAS FUTURAS 7.1 Conclusiones La realización de este proyecto ha hecho que descubra infinidad de herramientas y plataformas que no conocía hasta el momento. El IoT es un concepto que desconocía y, gracias a la plataforma FIWARE, he descubierto multitud de herramientas que facilitan en gran medida el desarrollo de smart-solutions que hagan uso del IoT. FIWARE proporciona una documentación muy extensa, lo cuál permite al desarrollador aprender a utilizar todos y cada uno de los componentes del sistema de forma guiada. Ofrece información detallada de todos los Generic Enablers disponibles y la funcionalidad que tiene cada uno de ellos. Además, pone a disposición del desarrollador aplicaciones que ya se han desarrollado previamente con este conjunto de herramientas que proporciona la plataforma FIWARE. Al aprender a utilizar las herramientas de FIWARE, he descubierto tecnologías muy interesantes como Docker, la cuál conocía al haber leído algún artículo pero nunca lo había usado. A partir de este proyecto, he investigado y aprendido a usar esta tecnología, junto con Docker-compose. También ha sido necesario el aprendizaje de lenguajes de programación como Python, ya que lo desconocía hasta la actualidad. Este lenguaje de programación es el más usado para el desarrollo de aplicaciones de Rapsberry Pi que accedan a los datos que se le envía a través de los pines de entrada. En definitiva, la realización de este proyecto me ha descubierto un mundo que antes no había explorado, como es el IoT. A partir del estudio e investigación de las múltiples soluciones que permiten interactuar con estos dispositivos IOT, he descubierto que existe una gran variedad de oportunidades que aún están por desarrollar, y, en un futuro, me gustaría dedicarme a la realización de alguna de estas soluciones. 51 51 Mecanismos de seguridad de la plataforma FIWARE 7.2 Líneas futuras En este apartado, se procede a detallar algunas ideas que pretenden ampliar las funcionalidades llevadas a cabo en el presente proyecto: • Aplicación Web: La incorporación de una aplicación web al sistema desarrollado en el presente proyecto, otorgaría multitud de ventajas respecto al estado actual del mismo: o Permitiría poder establecer niveles de seguridad intermedios y avanzados, al disponer de recursos de nivel de aplicación a los que asignar permisos. o Establecería una comunicación más intuitiva con el sensor GPS que se usa en el presente proyecto. o Ofrecería una interfaz de usuario que proporciona un nivel más alto de abstracción en el que no es necesario que el usuario conozca el acceso a la API NGSI ni el formato de las peticiones HTTP. • Integración con Wirecloud: Una de las herramientas que he descubierto durante la realización del proyecto es Wirecloud, el cuál se ha explicado en el apartado 4.2.3.1. Ofrece multitud de herramientas que encajarían de forma perfecta con el sistema actual. Proporcionaría una visualización de los datos más intuitivo que los mensajes JSON que se reciben en la actualidad. • Desarrollo de una app para móviles. También sería interesante la integración de una app para móviles que indique la información GPS que recoge el sensor del propio móvil. Con esta información se pueden realizar multitud de aplicaciones, como por ejemplo una aplicación que ubique permanentemente a un menor de edad en un mapa para estar localizado en todo momento. • Integración del sistema con Authzforce. Como hemos explicado en este proyecto, Authzforce proporciona multitud de mecanismos de seguridad. A medida que vayamos haciendo mas complejo un sistema, va creciendo la necesidad de utilizar Authzforce para proveeder de seguridad al sistema completo. 52 52 Mecanismos de seguridad de la plataforma FIWARE 53 ANEXO A: CONFIGURACIÓN DE RASPBERRY PI Y SENSOR GPS En este capítulo se procede a explicar de forma detallada los pasos que han sido necesarios para el correcto funcionamiento de la Raspberry Pi B+ junto con el sensor GPS U-Blox 6M. Para poder empezar a configurar la Raspberry Pi, es necesaria la instalación del Sistema Operativo Raspbian. Este sistema Operativo se debe instalar en una tarjeta de memoria microSD de al menos 4 GB. Raspberry Pi utiliza como dispositivo de arranque la tarjeta SD, pero, una vez se ejecute por primera vez el sistema, se puede configurar la Raspberry para arrancar a partir de una memoria USB. Para llevar a cabo las conexiones y configuración de la Raspberry Pi, se han seguido los pasos que detalla Luis Martínez Ruiz en su Trabajo de Fin de Grado, junto con el apoyo de alguna referencia extra. El requisito indispensable para que nuestro sistema funcione, es la de estar conectado a internet. En nuestro caso, se ha utilizado un disposirivo Wireless USB Network para conectarnos a internet vía Wi-Fi. Ilustración 48: Raspberry Pi Model B+ conectado a sensor U-Blox NEO-6M 60 60 Mecanismos de seguridad de la plataforma FIWARE 5. Finalmente, se installa el recurso Docker: Un paso adicional es comprobar que el recurso se ha instalado correctamente. Esto se puede hacer mediante el comando: Docker-compose El siguiente paso es instalar el software Docker-componse, el cuál se encarga de ejecutar varios contenedores a la vez. También permite la conexión entre estos contenedores para que funcionen como un único sistema. 1. Descargar la versión actual estable de Docker-compose desde la plataforma github. Para ello ejecutaremos el siguiente comando: 2. Una vez obtenido el recurso, le otorgamos permisos de ejecución: Al igual que en la instalación de Docker, se ejecuta el siguiente comando para comprobar que se ha realizado correctamente la instalación: $ sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" $ docker --version Ilustración 52: Resultado de la ejecución del comando docker --version $ sudo curl -L "https://github.com/docker/compose/releases/download/1.24.1/docker-compose- $(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose $ sudo chmod +x /usr/local/bin/docker-compose $ docker-compose --version Ilustración 53: Resultado de la ejecución del comando docker-compose --version 61 61 Mecanismos de seguridad de la plataforma FIWARE B.2 Creación de los componentes del sistema En este apartado se va a detallar cómo se han creado cada uno de los componentes del sistema y las herramientas utilizadas para ello. Cabe destacar que todos los componentes están definidos a partir de imágenes en un único archivo llamado orion.yml, al cuál se accede desde Docker-compose. Para facilitar el uso de de esta herramienta y evitar la ejecución multitud de comandos, se ha adaptado un script de servicio que proporciona FIWARE, el cual se encarga de llevar a cabo todas las tareas necesarias para poner en marcha nuestro sistema. Script de servicio Se pueden usar los siguientes comandos: • ./services help: Muestra los comandos disponibles. • ./services orion: Se encarga de levantar todos los contenedores situados en el archivo orion.yml • ./services stop: Se encarga de para y eliminar los contenedores que están ejecutandose actualmente. • ./services create: Se encarga de hacer pull 26 de las necesarias para poder llevar a cabo el posterior arranque el sistema completo. Estas imágenes están almacenadas en la variable “image” dentro de cada contenedor en el archivo orion.yml. Ilustración 54: Script de servicio para la puesta en marcha del sistema Estos servicios hacen uso de las siguientes funciones: - waitForKeyRock: Se encarga de hacer healthchecks 27 de Keyrock para comprobar su funcionamiento y muestra la respuesta por pantalla. Ilustración 55: Función waitForKeyrock 26 Descarga de las imágenes necesarias a partir de un registro. 27 Chequeos de funcionamiento. Normalmente se hacen peticiones sencillas que esperan una respuesta concreta para verificar el correcto funcionamiento del recurso. 62 62 Mecanismos de seguridad de la plataforma FIWARE - displayServices: Se encarga de mostrar los contenedores que están ejecutándose en Keyrock una vez se ha finalizado el arranque de todos los componentes, para comprobar que todos están funcionando. Ilustración 56: Función displayServices - startContainers: Se encarga de levantar todos los componentes del sistema alojados en el archivo orion.yml. Para ello ejecuta un comando de docker-compose. Ilustración 57: Función startContainers - stoppingContainers: Se encarga de detener todos los contenedores definidos en el archivo orion.yml. Ilustración 58: Función stoppingContainers Archivo orion.yml En este archivo es dónde se llevan a cabo todas las configuraciones de cada uno de los contenedores que conponen el sistema. Se procede a detallar cada uno de ellos. Orion Context Broker Ilustración 59: Contenedor Orion en archivo orion.xml 63 63 Mecanismos de seguridad de la plataforma FIWARE En esta configuración, Orion Context Broker se establece en el puerto 1026. Este será el puerto con el que tendremos que establecer la comunicación para enviar o solicitar datos al context broker. Este contenedor depende del contenedor mongo-DB. Se asigna una dirección IP ficticia dentro de la red que conecta cada uno de los contenedores. Esta red se definirá más tarde. Agente IOT Ultralight Ilustración 60: Contenedor IoT-Agent en el archivo orion.yml Este contenedor depende del context broker Orion y de la base de datos mongoDB. Se observa que este contenedor cuenta con dos puertos, lo cuál cumple lo explicado en el apartado 4.2.2. Por último se observan diversas variables de entorno, de las cuales procedemos a comentar las más interesantes: - IOTA_CD_HOST=orion y IOTA_CD_PORT=1026. Establece a Orion Context Broker como el destino al que actualizar su contexto. - IOTA_NORT_PORT=4041 y IOTA_HHTP_PORT=7896. Con estas variables se establecen los puertos norte y sur, cada uno de ellos encargado de una tarea concreta. - IOTA_PROVIDER_URL=hhtp://iot-agent:4041. Establece una URL con la que establecer la comunicación. 64 64 Mecanismos de seguridad de la plataforma FIWARE Keyrock Identity Management Este componente depende exclusivamente de la base de datos my-sql, donde se almacena toda la información necesaria para el correcto funcionamiento de Keyrock. Se establece una dirección IP ficticia de nuevo para poder comunicarse con los diferentes componentes del sistema. Se procede a comentar las variables de entornos más interesantes: • IDM_HOST: http://localhost:3005 : Se establece URL para comunicarnos con Keyrock, ya sea a través de su API o a través de la interfaz gráfica que proporciona. • IDM_HTTPS_ENABLED = ${IDM_HTTPS_ENABLED}. Activa o desactiva el soporte para el protocolo HTTPS. • IDM_ADMIN_USER=javier, IDM_ADMIN_EMAIL = [email protected], IDM_ADMIN_PASS=test. Con estas variables creamos un usuario administrador en el momento de la instalación del sistema, para poder gestionar Keyrock desde el principio. Ilustración 61: Contenedor Keyrock en el archivo orion.yml 65 65 Mecanismos de seguridad de la plataforma FIWARE Wilma PEP Proxy Este componente depende únicamente de keyrock, el cuál es el PDP del sistema y Wilma el componente PEP, como ya se explicó en el apartado 5.1.1 Se establece una dirección IP para poder comunicarse con los diferentes componentes del sistema. Se procede a comentar algunas de las variables más interesantes: • PEP_PROXY_IDM_HOST=keyrock. Se establece como IDM por defecto a Keyrock. • PEP_PROXY_APP_ID=app-dckr-site.0000-xpresswebapp. Es el identificador único de una aplicación concreta, a la cuál Wilma le provee de seguridad. Ilustración 62: Contenedor de Proxy PEP Wilma en el archivo orion.yml 66 66 Mecanismos de seguridad de la plataforma FIWARE mongoDB, mySQL y network Estos son los contenedores que alojan a los diferentes sistemas de bases de datos, cuya funcionalidad ya se detalló en el apartado 3.5. 67 67 Mecanismos de seguridad de la plataforma FIWARE Puesta en marcha del Sistema Para llevar a cabo el proceso de puesta en marcha, se deben seguir los siguientes pasos: 1. Ejecutar el siguiente comando para hacer pull de los elementos necesarios: 2. Ejecutar el comando encargado de la puesta en marcha del sistema: Finalmente, comprobamos que el sistema se ha desplegado correctamente, observando el mensaje final que muestra por pantalla el comando anterior. Ilustración 63: Resultado de la ejecución del comando sudo ./services orion A partir de este momento, ya se puede utilizar el sistema, siempre y cuando se haya ejecutado el programa gps.py en la Raspberry Pi. $ sudo ./services create $ sudo ./services orion 68 68 Mecanismos de seguridad de la plataforma FIWARE 69 69 Mecanismos de seguridad de la plataforma FIWARE 76 76 Mecanismos de seguridad de la plataforma FIWARE 77 77 Mecanismos de seguridad de la plataforma FIWARE 78 ANEXO D: ARCHIVOS ADJUNTOS En el CD adjunto se encuentran todos los archivos necesarios para reproducir el comportamiento del presente proyecto. Se procede a detallar el contenido: /Archivos_adjuntos /Docker /docker-compose orion.yml /mysql-data (vacío) secrets.txt services /Postman TFG.postman_collection.json (Peticiones utilizadas en Postman) /Raspberry gps.py 79 79 Mecanismos de seguridad de la plataforma FIWARE REFERENCIAS [1] Luis Martinez Ruiz, Aplicación web con Freeboard para la recolección de datos de sensores de acelerómetro y gps mediante Orion Context Broker de Fiware, Sevilla 2018. [2] [En línea] Available: https://www.blog.andaluciaesdigital.es/que-es-fiware-y-por-que-es-clave-para-el- emprendimiento/ [3] [En línea] Available: https://www.fiware.org/developers/ [4] [En línea] Available: https://fiware-idm.readthedocs.io/en/latest/#identity-manager-keyrock [5] [En línea] Available: https://naylampmechatronics.com/sensores-posicion-inerciales-gps/106-modulo- gps.html [6] [En línea] Available: https://www.electronicoscaldas.com/es/boards-raspberry-pi/800-raspberry-pi-1- modelo-b-plus.html [8] [En línea] Available: https://www.pcbox.com/productos/ask3557/portatil-asus-f550-x798h-core-i7-3537u [9] [En línea] Available: https://www.paradigmadigital.com/dev/postman-gestiona-construye-tus-apis- rapidamente/ [10] [En línea] Available: https://code.tutsplus.com/es/tutorials/using-the-requests-module-in-python--cms- 28204 [11] [En línea] Available: https://www.redhat.com/es/topics/containers/what-is-docker [12] [En línea] Available: https://docs.docker.com/compose/ [13] [En línea] Available: https://fiware-orion.readthedocs.io/en/1.8.0/index.html [14] [En línea] Available: https://fiware-academy.readthedocs.io/en/latest/security/wilma/index.html [15] [En línea] Available: https://www.genbeta.com/desarrollo/mongodb-que-es-como-funciona-y-cuando- podemos-usarlo-o-no [16] [En línea] Available: https://neoattack.com/neowiki/mysql/ 80 80 Mecanismos de seguridad de la plataforma FIWARE [17] [En línea] Available: https://www.fiware.org/about-us/ [18] [En línea] Available: https://www.fiware.org/developers/catalogue/ [19] [En línea] Available: https://fiware-orion.readthedocs.io/en/master/index.html [20] [En línea] Available: https://pt.slideshare.net/FI-WARE/orion-context-broker-webminar/4 [21] [En línea] Available: https://fiware-sth-comet.readthedocs.io/en/latest/ [22] [En línea] Available: https://fiware-cygnus.readthedocs.io/en/latest/ [23] [En línea] Available: https://flume.apache.org/ [24] [En línea] Available: https://fiware-iotagent-json.readthedocs.io/en/latest/index.html [25] [En línea] Available: https://ricveal.com/blog/primeros-pasos-mqtt/ [26] [En línea] Available: https://fiware-iotagent-ul.readthedocs.io/en/latest/usermanual/index.html#userprogrammers-manual [27] [En línea] Available: https://wirecloud.readthedocs.io/en/stable/ [28] [En línea] Available: https://knowage.readthedocs.io/en/latest/ [29] [En línea] Available: https://kurento.readthedocs.io/en/stable/ [30] [En línea] Available: http://localhost:3005/login [31][Enlínea] Available: https://fiware-idm.readthedocs.io/en/latest/user_and_programmers_guide/user_guide/index.html [32][Enlínea]Available: https://fiwareidm.readthedocs.io/en/latest/user_and_programmers_guide/application_guide/index.html [33] [En línea] Available: https://www.slideshare.net/FI-WARE/fiware-wednesday-webinars-how-to-secure- fiware-architectures [34] [En línea] Available: https://es.slideshare.net/rOzacC/xacml-37071981 [35] [En línea] Available: https://solidgeargroup.com/oauth2-protocolo-de-autorizacion?lang=es 81 81 Mecanismos de seguridad de la plataforma FIWARE 82 82 Mecanismos de seguridad de la plataforma FIWARE 83 83 Mecanismos de seguridad de la plataforma FIWARE 84 84 Mecanismos de seguridad de la plataforma FIWARE