ERS - OAJ Operations Gateway Manager

Transcripción

1 Observatorio Astrofísico de Javalambre ERS - OAJ Operations Gateway Manager Name: ERS pdf Prepared by Luis Guillén Reviewed by:, Approved by: Released by: CENTRO DE ESTUDIOS DE FÍSICA DEL COSMOS DE ARAGÓN

2 Page: 2 of 46 Change Records Issue Date Section affected Remarks 1 20 December 2013 First draft (LG) 1 20 January 2014 All document First relase (LG)

3 Page: 3 of 46 Table of Contents Change Records 2 Table of Contents 3 1 Introducción Propósito Alcance Definiciones, acrónimos y abreviaturas Referencias Visión general del documento Descripción Global Perspectiva del producto Interfaces de sistema Interfaces de Usuario Interfaces Hardware Interfaces Software Interfaces de Comunicaciones Operaciones Funciones del producto Diagramas Actores Casos de uso Características de los usuarios Restricciones Prorratear los requisitos Requisitos futuros Requisitos específicos Requisitos de interfaces externos Interfaz del usuario Interfaz del hardware Interfaz del software Interfaces de comunicaciones

4 Page: 4 of Requisitos funcionales Gestionar recursos de red Gestionar perfiles de acceso Gestionar clientes de acceso Gestionar gateway Gestionar las conexiones al gateway Requisitos del desarrollo Requisitos de rendimiento Restricciones del diseño

5 Page: 5 of Introducción El presente documento contiene una Especificación de Requisitos de Software para la solución informática que permitirá gestionar los accesos a una red virtual desde la que poder operar con los dispositivos de control del Observatorio Astrofísico de Javalambre. 1.1 Propósito El objeto de la especificación de requisitos es definir de manera clara y precisa tanto las funcionalidades como las posibles restricciones del sistema de información a construir. Dicho documento irá dirigido tanto a los departamentos de ingeniería y de astronomía del CEFCA como al personal encargado de desarrollar la solución. En él, se establecen las bases sobre las cuales el equipo de desarrollo procederá al diseño y posterior construcción del nuevo sistema. También servirá de modelo en el cual basar las pruebas funcionales de aceptación por parte del cliente y la evaluación final del producto por parte del mismo. 1.2 Alcance El producto a obtener será una solución mediante la que gestionar y controlar los accesos a las redes en las que se encuentran los sistemas de control del Observatorio Astrofísico de Javalambre desde los equipos personales del personal de ingeniería y astronomía. Definiremos a la solución como OAJ Operations Gateway Manager. El OAJ dispone de un conjunto de redes de control a las cuales se conectan multitud de dispositivos que realizan las más diversas tareas: control de telescopios, cúpulas, monitores, estación meteorológica, climatización, SAIs... El personal puede interactuar con dichos dispositivos a través de unos terminales de acceso restringido que se encuentran en un red especial llamada Red de Operaciones. Esta solución no cubre todas las necesidades ya que es necesario el acceso directo a dichas redes por parte del personal de ingeniería y astronomía desde sus equipos personales para realizar tareas de desarrollo, actualización o mantenimiento. Además existe la necesidad de poder realizar dichas tareas independientemente de cual sea su ubicación: ya sea el OAJ, oficinas del CEFCA o en su casa a través de la VPN. El objetivo es que los accesos desde estos equipos personales a los dispositivos ubicados en las redes de control se realicen desde una red virtual denominada Red Virtual de Operaciones. Para poder conectar a dicha red virtual será necesario que los usuarios dispongan del software cliente de VPN y un certificado válido. Una vez realizada la conexión contra el servidor de VPN, dicho servidor les concederá acceso a la red virtual y realizará las funciones

6 Page: 6 of 46 de enrutamiento y filtrado de paquetes hacia los dispositivos con los que estén autorizados a operar. Estas funciones de red privada virtual y filtrado la realizarán productos open source ampliamente consolidados: OpenVPN y Linux con Netfilter e IPTables. Será responsabiliad de OAJ Operations Gateway Manager de dotar a los administradores de sistemas de las herramientas necesarias para gestionar de manera fácil y productiva los accesos a dicha red así como de desarrollar los componentes necesarios para realizar la integración de los distintos productos software. Aunque la solución es específica, es un problema común en entornos industriales y entornos críticos donde se necesita tener un control discrecional del acceso a red, por lo que el problema se modelará teniendo en mente la generalización a este tipo de entornos. 1.3 Definiciones, acrónimos y abreviaturas SRS: Software Requirements Specification ERS: Especificación de Requisitos Software OAJ: Observatorio Astrofísico de Javalambre VPN: Red Privada Virtual CU: Caso de Uso OAJog: OAJ Operations Gateway. OAJogm: OAJ Operations Gateway Manager. Es el software con el que gestionaremos el Operations Gateway. PKI: Infraestructura de clave pública y privada CRL: Certificate Revocation List SGBD: sistema gestor de bases de datos CLI: Command Line Interface. GUI: Graphical User Interface NAT: Network Address Translation. Proceso en el cual se realiza una modificación en el origen/destino de las cabeceras IP. CA: Certification Authority. Autoridad en la que se confía y está encargada de la emisión de certificados. UML: Lenguaje de Modelado Unificado. Lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad. NIDS: Sistema de detección de intrusos en una Red.

7 Page: 7 of 46 CN: Canonical name Gateway: es un dispositivo que permite interconectar redes con protocolos y arquitecturas diferentes a todos los niveles de comunicación. Redes de control del OAJ: Conjunto de redes informáticas que interconexionan los dispositivos de control del OAJ. Red de servicio del OAJ: Red en la cual se ofrecen servicios generales y es accesible por todas las redes del OAJ. Red de Operaciones del OAJ: Red desde la cual se opera con los terminales de operación. Iptables: software de espacio de usuario que permite manipular las reglas de filtrado Netfilter. Netfilter: software de filtrado de paquetes IP incluido en el kernel de Linux. OpenVPN: software de conexión vpn. Se compone de una parte servidor, en adelante servidor VPN y una parte cliente, en adelante cliente VPN. Debian GNU/Linux: Distribución de sistema operativo LInux. Certificados x.509: Certificados de clave privada/pública emitidos por una entidad de confianza CA. SSH: es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red. Bash: Shell de línea de comandos por defecto en la mayoría de las distribuciones. PHP: Lenguaje de programación muy popular, especialmente en entornos web. Zend Framework: Framework de desarrollo para el lenguaje PHP. PHPki: software web de gestión de CA. XCA: software de escritorio de gestión de CA. MySQL: Popular gestor de base de datos relacional. Apache: En el contexto del documento, servidor web producido por la fundación Apache. RSA: popular sistema criptográfico de clave pública at y cron: populares herramientas UNIX que permiten la programación de tareas en el sistema.

8 Page: 8 of 46 Batch: ejecución de una serie de programas en un computador sin la interacción humana. Snort: es un sniffer de paquetes y un detector de intrusos basado en red. SCRUM: marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software. RF: Requisito funcional RNF: Requisito no funcional RNF INT CLI: Requisito no funcional de la interfaz de usuario CLI RNF INT GUI: Requisito no funcional de la interfaz de usuario GUI RNF INT HW: Requisito no funcional de la interfaz del hardware RNF INT SW: Requisito no funcional de la interfaz del software RNF INT COM: Requisito no funcional de la interfaz de comunicaciones RNF DEV: Requisito no funcional del desarrollo RNF REN: Requisito no funcional del rendimiento RNF DIS: Requisito no funcional del diseño RF NET: Requisito funcional de la gestión de recursos de red RF PRF: Requisito funcional de la gestión de perfiles de acceso RF CLI: Requisito funciona de la gestión de clientes de acceso RF GW: Requisito funcional de la gestión del gateway RF CN: Requisito funcional de la gestión de conexiones al gateway 1.4 Referencias Documentación de manual Openvpn openvpn-20x-manpage.html Interfaz de gestión del servicio Openvpn management-interface.html Ejemplo de verificación de cn scripts/verify-cn

9 Page: 9 of 46 Patrón de diseño Service Layer Patrón de diseño Data Mapper Patrón de diseño Repository Visión general del documento El presente documento está estructurado en tres secciones: Capítulo 2.- Descripción global. Visión general del documento. Capítulo 3.- Características del Producto. Descripción general del sistema a desarrollar, con el fin de indicar los factores que afectan al producto y sus requerimientos. Proporciona las principales características a cumplir por el producto. Capítulo 4.- Requisitos específicos: Especificación detallada de los requerimientos a satisfacer por el producto.

10 Page: 10 of Descripción Global 2.1 Perspectiva del producto El sistema OAJ Operations Gateway Manager no es autónomo. El software deberá interactuar con un servidor OpenVPN en diferentes procesos: autorización de usuarios asignación dinámica del direccionamiento de red ver conexiones y desconectar clientes mediante el protocolo de management de Open- VPN El software deberá además comunicarse con el sistema operativo Debian GNU/Linux para: suministrar dinámicamente las reglas del cortafuegos parar/detener servicio VPN De manera externa a la solución, será necesario: el empleo de un SGBD que lleve a cabo la persistencia de la información del aplicativo el empleo de software de gestión de una PKI para la emisión de certificados y publicación de la CRL Para una perspectiva global del sistema y la relación con los otros sistemas se ha elaborado el diagrama de bloques adjunto en la figura 2.1. A continuación se pasa a realizar una breve descripción: Mgmt Server: bloque que contiene los componentes necesarios para las tareas de gestión y administración del sistema. Los componentes son: OAJogm CLI Interface: componente software que provee de la interfaz de línea de comandos de administración con la que el administrador operará con el sistema. OAJogm GUI Interface: componente software que provee de una interfaz web de administración con la que el administrador operará con el sistema. OAJogm Core Application: componente software que contiene la lógica general de aplicación y proveerá de los servicios necesarios para llevarla a cabo.

11 Page: 11 of 46 Figura 2.1 Diagrama de bloques del sistema

12 Page: 12 of 46 OAJogm Webservice: servicio web que se usará como interfaz expuesta de la aplicación de gestión a otros componentes del sistema. OAJogm OgControlAgent: componente software que realizará labores de control bajo demanda sobre el Gateway. Data Mgmt Server: bloque que contiene los componentes necesarios para la persistencia de la información de la aplicación de gestión. Persistent Storage: SGBD. PKI Server: bloque que contiene los componentes necesarios para la gestión de la PKI. PKI Software: software encargado de la gestión de los certificados x.509. Gateway Server: bloque que contiene los componentes necesarios para la conexión vpn y filtrado. OpenVPN Server: software de servidor OpenVPN IPTables Firewall: software de espacio de usuario para la administración de reglas Netfilter. OAJog AuthHelper: componente software que integrará OpenVPN con la aplicación para las labores de autorización. OAJog ClientConfigHelper: componente software que integrará OpenVPN con la aplicación para las labores de configuración dinámica del cliente VPN. OAJog IptablesConfigHelper: componente software que cargará en el Gateway las reglas IPTables generadas dinámicamente por la aplicación. OAJog OgControlBroker: componente software que servirá de intermediario para OgControlAgent, el protocolo de gestión OpenVPN y el sistema operativo subyacente. Gateway Client: bloque que contiene los componentes necesarios para el conexionado de los usuarios a la infraestructura. OpenVPN Client: software cliente OpenVPN Aunque se hayan representado como bloques diferenciados, los bloques Mgmt Server, Gateway Server, Data Mgmt Server y PKI Server, podrían encontrarse en el mismo servidor Interfaces de sistema Como puede apreciarse en el diagrama, el sistema deberá dotar de: Interfaces de gestión para el administrador del sistema Interfaces de integración con los demás sistemas involucrados Interfaces de acceso a usuarios de Red Virtual de Operaciones

13 Page: 13 of 46 Interfaces de gestión para el administrador del sistema El sistema ha de proveer de interfaces a los administradores del sistema con las que podrán interactuar para gestionar el sistema. Interfaces de integración con los demás sistemas involucrados Necesitamos tres interfaces de integración: Interfaz de integración de la autenticación y configuración dinámica de clientes Open- VPN Interfaz de integración de la obtención dinámica de reglas IPTables Interfaz de integración para el control del sistema operativo del Gateway A continuación se realiza una descripción de dichas interfaces: Interfaz de integración de la autenticación y configuración OpenVPN Para entender mejor estas interfaces de integración, se muestra el diagrama de actividades de la figura 2.2 en el que se ilustra la secuencia de conexión de un cliente VPN a nuestro sistema. Fase de autenticación: Aunque la fase de autenticación es ajena a nuestro sistema en el sentido de que es algo que tiene lugar entre cliente y servidor VPN mediante los certificados x.509, se ilustra para aclarar el proceso. Una interfaz externa necesaria es a obtención de la CRL para ver si el certificado no ha sido revocado y tiene lugar via http con el servidor de la PKI. Esta fase afectará al desarrollo únicamente a nivel de configuración. Fase de autorización: en esta fase sí tiene lugar interacción entre los sistemas y es necesario dotar de un componente para dicha fase. El componente será OAJog AuthHelper. La interfaz viene definida por OpenVPN: será el servidor el que llamará a este componente mediante la directiva de configuración tls-verify. El sistema precisa un ejecutable que recibirá por parámetro la cadena cn. Este ejecutable llamará al servicio web para comprobar que el usuario está autorizado a conectar, interpretará el resultado y retornará al sistema operativo 0 (y entregado al proceso openvpn) si la verificación es correcta. Para más detalles ver en referencias Ejemplo de verificación de cn. Fase de configuración: en esta fase también tiene interacción entre los sistemas y es necesario dotar de un componente. El componente será OAJog ClientConfigHelper. La interfaz viene definida por OpenVPN: será el servidor el que llamará a este componente mediante la directiva client-connect. El sistema precisa un ejecutable que recibirá vía variables de entorno información acerca del cliente de conexión. Este ejecutable llamará al servicio web para comprobar que ha sido previamente autorizado, obtener la información de configuración IP y especificará por la salida estándar

14 Page: 14 of 46 Figura 2.2 Diagrama de actividades proceso de conexión a la VPN

15 Page: 15 of 46 la configuración del cliente. Esta salida estándar será recogida por el proceso openvpn y la entregará al cliente. Además retornará al sistema operativo 0 (y entregado al proceso openvpn) si el proceso ha ido bien. Para más detalles ver en referencias Documentación de manual OpenVPN. Interfaz de integración de obtención de reglas IPTables Otra interfaz de sistema necesaria será la obtención de las reglas de cortafuegos dinámicamente desde nuestro sistema de gestión. Para ello será necesario el componente OAJog IptablesConfigHelper, que obtendrá un script con las reglas necesarias desde la interfaz ofrecida por el servicio web y recargará las reglas. La llamada a este componente podrá ser realizada en el momento de inicio del Gateway (junto con el arranque del servicio OpenVPN) o mediante la interfaz de control vista a continuación. Interfaz de integración para el control del sistema operativo del Gateway La interfaz de integración se escribirá en el componente OAJog OgControlBroker. Este componente tendrá las funciones de: Control de conexiones del servidor OpenVPN. Para esto deberá implementar el protocolo de gestión proporcionado por OpenVPN. Para más detalles ver en referencias Interfaz de gestión del servicio Openvpn Control del demonio OpenVPN y recarga de de reglas vía OAJog IptablesConfigHelper. Para esto deberá implementar las llamadas necesarias. Interfaces de acceso a usuarios de Red Virtual de Operaciones La interfaz de acceso a usuarios no estará implementada en el aplicativo, sino que la proveerá el propio cliente OpenVPN directamente o a través de software de terceros Interfaces de Usuario El administrador del sistema se comunicará con el sistema a través de: Interfaz CLI: se encontrará en el propio servidor de gestión y podrá ser usada vía consola local o vía ssh. La interfaz deberá seguir filosofía UNIX, disponer de ayuda en línea y una salida fácil de filtrar. Interfaz GUI: podrá accederse a ella mediante un navegador. La interfaz deberá cumplir con los estándares web de modo que pueda usarse con cualquier navegador Interfaces Hardware Como se ha descrito anteriormente, la solución podrá integrarse en un único servidor o en distintos servidores según los bloques indicados. El hardware sobre el que correrán los sistemas podrá ser físico o virtual. Dicho hardware deberá cumplir un mínimo de: Arquitectura x86, mínimo Pentium IV

16 Page: 16 of MB RAM 8 GB HD Dos tarjetas de red ethernet en el caso del Gateway Server. El hardware cliente de acceso (gateway client) podrá ser cualquier tipo de dispositivo que admita un cliente OpenVPN: PCs Smartphones Tablets Interfaces Software Mgmt Server: Sistema operativo Debian Wheezy Bash shell Servidor Apache2 PHP con interfaz CLI y módulo apache, extensiones mysql PHP Zend Framework 1.12 Data Mgmt Server: Servidor MySQL y cualquier sistema operativo que lo soporte: Linux, Windows, MacOS X Gateway Server: Sistema operativo Debian Wheezy Paquetes iptables, iproute2, openvpn-server, curl Bash shell PHP con interfaz CLI, extensiones php5-curl PHP Zend Framework 1.12 Gateway Client: Cliente OpenVPN y cualquier sistema operativo que lo soporte: Linux, Windows, MacOS X, Android PKI Server: Software pki que se elija, ejemplos: PHPki, XCA

17 Page: 17 of Interfaces de Comunicaciones Desde el punto de vista funcional Si prestamos atención al diagrama de bloques con los componentes del sistema podemos ver que existe comunicación entre diferentes componentes. Se describirán a continuación: La comunicación entre todos los componentes OAJogm se comunicarán entre si mediante llamadas a funciones y programas locales. La comunicación entre todos los componentes OAJog se comunicarán entre si mediante llamadas a funciones y programas locales salvo en el caso del OgControlBroker con el servidor OpenVPN, que se utilizará un socket local de Management. Para más información ver protocolo de management de OpenVPN. La comunicación de OAJogm Core Application con Persistent Storage se realizará por el propio protocolo ofrecido por el gestor de bases de datos. Las comunicaciones de OAJog AuthHelper, ClientConfigHelper y IptablesConfigHelper con OAJogm Webservice se realizarán mediante protocolo HTTPS. La comunicación de OAJogm OgControlAgent con OAJog OgControlBroker se realizará mediante SSH. La comunicación del OpenVPN Server y el servidor web del PKI Server se realizará mediante protocolo HTTP. La comunicación entre el OpenVPN Client y el OpenVPN Server se realizará mediante el propio protocolo especificado por OpenVPN. Desde el punto de vista de networking En el siguiente diagrama de red genérico simplificado de la figura 2.3 se muestra la topología lógica de la red sobre la que se aplicará la solución. Se han omitido los componentes Mgmt Server, Data Mgmt Server y PKI Server por simplicidad y para una mejor ilustración de los requerimientos. Estos componentes podrían encontrarse en el mismo Gateway Server o en sistemas independientes conectados en alguna red con las que el Gateway Server tuviera conectividad. Desde el punto de vista físico: interfaz física en red de servicio interfaz física en red de control la interfaz de la Red Virtual de Operaciones es virtual y es creada por un driver del kernel. Desde el punto de vista lógico:

18 Page: 18 of 46 Figura 2.3 Diagrama de red genérico simplificado interfaz lógica en red de servicio: a través de dicha interfaz se realizarán las conexiones al servidor vpn interfaz lógica en red virtual de operaciones: a través de dicha interfaz se realizará el enrutamiento y se aplicará en su entrada el filtrado de paquetes a las redes de control interfaz lógica en red de control: a través de dicha interfaz pasarán los paquetes que han sido enrutados y filtrados desde la interfaz en la red virtual de operaciones Nótese que los paquetes desde la red virtual de operaciones serán enrutados y no serán manipulados haciendo NAT, lo que implica que las redes de control deben conocer la ruta de vuelta a la Red Virtual de Operaciones. Esto es importante ya que nos permitirá: agregar ACLs a nivel de servicio en los propios dispositivos de control usar protocolos que requieran lanzar conexiones en sentido inverso tener registros en los dispositivos de control de las IPs que se conectaron Operaciones Desde el punto de vista de operaciones, la aplicación podrá usarse: modo interactivo: desde la GUI o la CLI, el administrador ejecutará acciones que se aplicarán inmediatamente modo batch: gracias a que dispone de interfaz CLI, el administrador podrá escribir sus scripts de comandos pudiendo, además de ejecutar secuencias, realizar programaciones con las utilidades estándar de UNIX at y cron. Las operaciones de backup consistirán en el volcado de la base de datos del Persistent Storage y se agregarán al conjunto de operaciones de backups de los sistemas del OAJ.

19 Page: 19 of Funciones del producto A continuación mostraremos las funciones del producto valiéndonos del lenguaje UML. Cada caso de uso está numerado y se detallará la funcionalidad asociada a cada uno de ellos. De manera adicional, se agrega un diagrama de clases a modo de ilustrar el modelo de datos Diagramas Diagrama general de casos de uso: figura 2.4 Diagrama desglosado de caso de uso 1: figura 2.5 Diagrama desglosado de caso de uso 2: figura 2.6 Diagrama desglosado de caso de uso 3: figura 2.7 Diagrama desglosado de caso de uso 4: figura 2.8 Diagrama de clases básico del modelo de datos: figura Actores Administrador: se trata de los administradores de sistemas Servidor VPN: se trata del software de servidor VPN que se integra como parte de la solución Usuario: se tratará de los usuarios de la Red Virtual de Operaciones Casos de uso CU 1. Gestionar recursos de red: este caso de uso está desglosado en un diagrama independiente. CU 1.1. Mostrar lista de recursos de red: Se mostrará al administrador una lista de los recursos de red definidos por pantalla. La lista incluirá: nombre identificativo del recurso de red, tipo de recurso y la descripción si la tuviese. CU 1.2. Crear recurso de red: El administrador introducirá de manera obligatoria un nombre identificativo de un recurso de red, el tipo de recurso de red, los datos asociados al tipo de recurso y, de manera opcional, una descripción del recurso de red. CU 1.3. Modificar recurso de red: El administrador, indicando el nombre identificativo del recurso de red, podrá modificar los datos asociados al tipo de recurso y la descripción del recurso. El nombre identificativo y el tipo de recurso no podrán cambiarse.

20 Page: 20 of 46 CU 1.4. Eliminar recurso de red: El administrador indicará el nombre identificativo y el sistema eliminará el recurso. CU 1.5. Ver información de recurso de red: El administrador indicará el nombre identificativo y el sistema mostrará toda la información del recurso: fecha de creación, fecha de última actualización, nombre, descripción, tipo de recurso y datos específicos del tipo de recurso. CU 2. Gestionar perfiles de acceso: este caso de uso está desglosado en un diagrama independiente. CU 2.1. Mostrar listado de perfiles de acceso: Se mostrará al administrador una lista con los perfiles de acceso definidos por pantalla. La lista incluirá: nombre identificativo del perfil de acceso y descripción si la tuviese. CU 2.2. Crear perfil de acceso: El administrador introducirá de manera obligatoria un nombre identificativo de perfil de acceso y de manera opcional la descripción del perfil. CU 2.3. Modificar información de perfil de acceso: El administrador, indicando el nombre identificativo del perfil de acceso, podrá modificar la descripción del perfil. CU 2.4. Permitir a un perfil el acceso a un recurso de red: El administrador, indicando los nombres identificativos de perfil de acceso y recurso de red, permitirá el acceso al recurso a dicho perfil. CU 2.5. Eliminar a un perfil el acceso a un recurso acceso a recurso de red a un perfil: El administrador, indicando los nombres identificativos de perfil de acceso y recurso de red, eliminará el perfil de acceso. CU 2.6. Eliminar perfil de acceso: El administrador, indicando el nombre identificativo de perfil de acceso, eliminará el acceso. CU 2.7. Ver información de perfil de acceso: El administrador, indicando el nombre identificativo de perfil de acceso, mostrará la información del perfil: fecha de creación, fecha de última actualización, nombre, descripción y listado con los recursos de red asociados. CU 3. Gestionar clientes de acceso: este caso de uso está desglosado en un diagrama independiente. CU 3.1. Mostrar listado de clientes de acceso: Se mostrará al administrador una lista con los clientes de acceso por pantalla. La lista incluirá nombre identificativo de cliente de acceso, perfil de acceso al que pertenece y la descripción si la tuviese.

21 Page: 21 of 46 CU 3.2. Crear cliente de acceso: El administrador introducirá de manera obligatoria los nombres identificativos de cliente de acceso y perfil de acceso y de manera opcional la descripción del cliente. Durante este proceso el sistema obtendrá una ip no asignada dentro del pool de direcciones de la vpn de operaciones disponible y se la asignará al nuevo cliente de acceso. En caso de no existir direcciones libres en el pool, el sistema dará un error. CU 3.3. Modificar cliente de acceso: El administrador introducirá de manera obligatoria el nombre identificativo del cliente de acceso y la información a modificar: perfil o descripción. CU 3.4. Mostrar información de cliente de acceso: El administrador, indicando el nombre identificativo del cliente, mostrará la información del cliente: fecha de creación, fecha de última actualización, nombre, perfil de acceso, si se encuentra habilitado o no, si tiene el logging iptables habilitado, fecha hora del último logging realizado, la dirección ip asignada y la descripción. CU 3.5. Eliminar cliente de acceso: El administrador, indicando el nombre identificativo del cliente, eliminará el cliente y liberará la dirección ip que se le asignó. CU 3.6. Bloquear acceso a cliente: El administrador, indicando el nombre identificativo del cliente, bloqueará el acceso al gateway. CU 3.7. Desbloquear acceso a cliente: El administrador, indicando el nombre identificativo del cliente, desbloqueará el acceso al gateway. CU 3.8. Mostrar listado de clientes con los últimos logins realizados: El administrador obtendrá un listado con una relación de identificadores y fecha hora de acceso. CU 3.9. Mostrar listado de logins de un cliente: El administrador, indicando el nombre identificativo del cliente, mostrará un listado con la fecha hora de los logings realizados por un cliente. CU Habilitar logging iptables a cliente de acceso: El administrador, indicando el nombre identificativo de cliente, habilitará el logging iptables en el sistema del gateway para el cliente especificado. CU Deshabilitar logging iptables a cliente de acceso: El administrador, indicando el nombre identificativo de cliente, deshabilitará el logging iptables en el sistema del gateway para el cliente especificado. CU 4. Gestionar Gateway: este caso de uso está desglosado en un diagrama independiente. CU 4.1. Mostrar clientes conectados en el gateway: El administrador obtendrá un listado con los nombres identificativos de los clientes conectados en el momento al gateway.