Declaración de Seguridad para PROCESA Engine v.1.7.3

Transcripción

1 MNEMO EVOLUTION & INTEGRATION SERVICES, S.A. PROCESA Engine v1.7.3 Declaración de Seguridad para PROCESA Engine v V1.6 Página 1 de 50

2 HOJA DE CONTROL DOCUMENTAL Nombre del PROCESAEngine_v1.7.3_Declaración_de_seguridad_ _v1.6 documento: Resumen: Declaración de seguridad para la versión 1.7.x de PROCESA Engine Autor: Juan José Rodríguez Gutiérrez Fecha Versión: 22/03/2010 Revisado por: Fernando García Vicent Fecha Revisión: 22/03/2010 Aprobado por: Fernando García Vicent Fecha Aprobación: 22/03/2010 Anexos: N/A Nº de páginas: 50 CONTROL DE VERSIONES Versión Fecha Autor Descripción /06/2009 Juan José Rodríguez Creación del documento Gutiérrez /07/2009 Juan José Rodríguez Modificación de los requisitos Gutiérrez funcionales, aumentos +ASE_SPD.1, +ASE_OBJ.2, +ASE_REQ /08/2009 Juan José Rodríguez Modificaciones para corregir errores Gutiérrez detectados en auditoria previa /09/2009 Juan José Rodríguez Gutiérrez Modificaciones para corregir errores de inconsistencia de información relacionada con la identificación y los requisitos de seguridad /10/2009 José Peñalba Morales Modificaciones para corregir errores de inconsistencia del Componente Auditoria /12/2009 José Peñalba Morales Modificaciones para corregir las no conformidades con la versión 1.4 del documento /03/2010 José Peñalba Morales Modificaciones para corregir las no conformidades con la versión 1.5 del documento Página 2 de 50

3 ÍNDICE 1 INTRODUCCIÓN IDENTIFICACIÓN GLOSARIO REFERENCIAS TOE OVERVIEW Tipo y uso de TOE Hardware y software no incluido en el TOE TOE DESCRIPTION CONFIGURACIÓN EVALUADA Componentes del TOE Arquitectura lógica Arquitectura física del TOE Arquitectura física de la configuración evaluada Requisitos de la configuración evaluada CONFORMIDAD DEFINICIÓN DEL PROBLEMA DE SEGURIDAD ACTIVOS A PROTEGER Activo 01: Confidencialidad de las contraseñas almacenadas en base de datos o ficheros de configuración Activo 02: Integridad de la gestión de roles de proceso Activo 03: Gestión del ciclo de vida de los procesos Activo 04: Gestión del ciclo de vida de las tareas Activo 05: Servicios de acceso a datos Activo 06: Servicios de administración Activo 07: Servicios de gestión documental AMENAZAS Amenaza 01: Violación de la confidencialidad de las contraseñas almacenadas en base de datos o ficheros de configuración Amenaza 02: Violación de la integridad en la gestión de roles de proceso Amenaza 03: Violación de la integridad en la gestión del ciclo de vida de los procesos Amenaza 04: Violación de la integridad en la gestión del ciclo de vida de las tareas Amenaza 05: Violación de la integridad de los servicios de acceso a datos Amenaza 06: Violación de la integridad de los servicios de administración Amenaza 07: Violación de la integridad de los servicios de gestión documental POLÍTICAS DE SEGURIDAD ORGANIZACIONAL Política 01: Restricción de acceso al TOE Política 02: Disposición de datos de usuario y privilegios de acceso Política 03: Configuración segura de conexiones externas del TOE Política 04: Revisión de auditorías HIPÓTESIS DE USO SEGURO Hipótesis 01: Administrador del sistema confiable Hipótesis 02: Administrador de la auditoría HIPÓTESIS DE ENTORNO Hipótesis de Entorno 01: Entorno seguro y confiable Hipótesis de Entorno 02: Conexión entidades externas segura OBJETIVOS DE SEGURIDAD OBJETIVOS DE SEGURIDAD PARA EL TOE Objetivo 01: Confidencialidad de contraseñas almacenadas en BD y en ficheros de configuración Objetivo 02: Registro de las peticiones realizadas Objetivo 03: Identificación y Control de acceso OBJETIVOS DE SEGURIDAD PARA EL ENTORNO Objetivo entorno 01: Garantizar el entorno seguro y confiable Objetivo entorno 02: Garantizar la conexión a entidades externas segura...25 Página 3 de 50

4 4.2.3 Objetivo entorno 03: Revisión de auditorías RAZONAMIENTO DE LOS OBJETIVOS DE SEGURIDAD Amenazas Políticas Hipótesis REQUISITOS DE SEGURIDAD REQUISITOS FUNCIONALES DE SEGURIDAD Relación de objetos Relación de sujetos y sus atributos REQUISITOS DE CONTROL DE ACCESO FDP_ACC.2 Complete Access control FDP_ACF.1 Security attribute based access control FMT_MSA.3 Static attribute initialization FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FIA_UID.2 User identification before any action FIA_UAU.2 User authentication before any action FIA_UAU.4 Single-use authentication mechanisms REQUISITOS RELATIVOS A AUDITORÍA DE EVENTOS FAU_GEN.1 Audit data generation FAU_GEN.2 User identity association REQUISITOS RELATIVOS A CONFIDENCIALIDAD DE LAS CONTRASEÑAS FCS_COP.1 Cryptographic operation FCS_CKM.1 Cryptographic key generation FCS_CKM.4 Cryptographic key destruction REQUISITOS DE ASEGURAMIENTO: CLASE ASE SECURITY TARGET EVALUATION ASE_INT.1 ST introduction ASE_CCL.1 Conformance claims ASE_OBJ.2 Security objectives ASE_SPD.1 Security problem definition ASE_ECD.1 Extended components definition ASE_REQ.2 Derived security requirements ASE_TSS.1 TOE summary specification REQUISITOS DE ASEGURAMIENTO: CLASE ADV DEVELOPMENT ADV_FSP.1 Basic functional specification REQUISITOS DE ASEGURAMIENTO: CLASE AGD GUIDANCE DOCUMENTS AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures REQUISITOS DE ASEGURAMIENTO: CLASE ALC - LIFE-CYCLE SUPPORT ALC_CMC.1 Labelling of the TOE ALC_CMS.1 TOE CM coverage ALC_FLR.1 Basic flaw remediation REQUISITOS DE ASEGURAMIENTO: CLASE ATE - TESTS ATE_IND.1 Independent testing - conformance REQUISITOS DE ASEGURAMIENTO: CLASE AVA - VULNERABILITY ASSESSMENT AVA_VAN.1 Vulnerability survey RAZONAMIENTO DE REQUISITOS Razonamiento de requisitos funcionales Razonamiento requisitos de aseguramiento ESPECIFICACIÓN RESUMIDA FDP_ACC.2 COMPLETE ACCESS CONTROL FDP_ACF.1 SECURITY ATTRIBUTE BASED ACCESS CONTROL FMT_MSA.1 MANAGEMENT OF SECURITY ATTRIBUTES FMT_MSA FMT_MSA.3 STATIC ATTRIBUTE INITIALISATION FMT_SMR.1 SECURITY ROLES...48 Página 4 de 50

5 6.6 FMT_SMF.1 SPECIFICATION OF MANAGEMENT FUNCTIONS FIA_UID.2 USER IDENTIFICATION BEFORE ANY ACTION FIA_UAU.2 USER AUTHENTICATION BEFORE ANY ACTION FIA_UAU.4 SINGLE-USE AUTHENTICATION MECHANISMS FCS_CKM.1 CRYPTOGRAPHIC KEY GENERATION FCS_CKM.4 CRYPTOGRAPHIC KEY DESTRUCTION FCS_COP.1 CRYPTOGRAPHIC OPERATION FAU_GEN.1 AUDIT DATA GENERATION FAU_GEN.2 USER IDENTITY ASSOCIATION...50 ÍNDICE DE ILUSTRACIONES Ilustración 1- Arquitectura de PROCESA...13 Ilustración 2- Componentes del TOE...14 Ilustración 3 Arquitectura lógica de la configuración evaluada...15 Ilustración 4 - Arquitectura física de la configuración evaluada...17 ÍNDICE DE TABLAS Tabla 1 - Identificación del TOE...6 Tabla 2- Glosario de términos...7 Tabla 5 - Razonamiento de los requisitos funcionales...46 Página 5 de 50

6 1 Introducción El presente documento contiene la información relativa a la declaración de seguridad del producto PROCESA Engine aplicable a la versión En el documento se incluyen los elementos necesarios para determinar el Objeto de Evaluación (en adelante TOE), así como los objetivos de seguridad y los mecanismos para asegurarlos que se han determinado. 1.1 Identificación En este apartado se resume la información para la identificación de la presente declaración de seguridad (en adelante ST), así como del Objeto de Evaluación (TOE) al que ésta hace referencia. Identificador Descripción Identificador del documento: PROCESAEngine_v1.7.3_Declaracion_de_ seguridad_ _v1.6 Versión: 1.6 Título: Declaración de seguridad para PROCESA Engine v Autores: Juan José Rodríguez Gutiérrez José Peñalba Morales Estado del documento: Finalizado Fecha de publicación: 15/03/2010 Identificador del TOE: PROCESA Engine v1.7.3 Versión Common Criteria: Common Criteria v 3.1. Revision 3. EAL: EAL1+ALC_FLR.1 +ASE_SPD.1 +ASE_OBJ.2 +ASE_REQ.2 Evaluación declaración seguridad: Epoche & Espri Tabla 1 - Identificación del TOE 1.2 Glosario Los siguientes términos y acrónimos son usados a lo largo del documento. Término/Acrónimo Autorización Evento Modelo Tarea Rol de proceso HTTP/HTTPS (HyperText Transfer Protocol) LDAP (Lightweight Directory Access Protocol) Servicio TOE Descripción El proceso de aprobación de una solicitud Cualquier acción o suceso que ocurre dentro del sistema provocado por la intervención de un agente externo. Representación de una secuencia de tareas que pueden ser ejecutas por una serie de personas Agrupación de acciones tanto interactivas como automáticas que se pueden ejecutar en un modelo Papel o funciones que desempeña un usuario o grupo de usuarios encargados de la ejecución de una serie de tareas. Protocolos usados en cada transacción de la Web. Protocolo de red que permite el acceso a un servicio de directorio ordenado y distribuido para buscar información en un entorno de red. Conjunto de servicios del Objeto de Evaluación que se publican al exterior para ofrecer Página 6 de 50

7 SOAP (Simple Object Access Protocol) TOE (Target of Evaluation) Webservice 1.3 Referencias funcionalidades. Protocolo estándar creado por Microsoft, IBM y otros, que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. Objeto de Evaluación. Colección de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Tabla 2- Glosario de términos La presente Declaración de Seguridad ha sido elaborado siguiendo las especificaciones recogidas dentro del Common Criteria for Information Technology Security Evaluation, versión 3.1 Revision 3. Partes 1,2 y TOE Overview PROCESA es un producto BPMS especialmente diseñado para la construcción y ejecución de procesos de Administración Electrónica y de Tramitación Electrónica, sobre la base del concepto de reutilización de servicios. Utiliza lo mejor de las tecnologías BPM y SOA para la construcción de sistemas de información basados en procesos, en los cuales cada tarea es ejecutada por la combinación de la ejecución de los distintos tipos de servicios accesibles desde el servidor que está realizando la ejecución del proceso. El núcleo de PROCESA, en que consiste precisamente el objeto de evaluación (TOE), es el módulo PROCESA Engine, entre cuyas características destacan las siguientes: Es un servicio inteligente de BPM-workflow sobre objetos reutilizables, mediante arquitecturas SOA e invocación de servicios web. Permite la construcción de una Plataforma de Servicios para el diseño de sistemas de información basados en flujos de procesos y árboles de tramitación complejos, para los cuales el número de caminos, el volumen de tareas por cada camino y la probabilidad de cambio en las especificaciones funcionales y técnicas asociadas a cada tarea son muy elevados. Aplicación práctica de las tecnologías BPM, SOA y utilización de estándares (XML, WebServices, XPDL, BPEL, etc.). Diseñado teniendo en cuenta requisitos de construcción de sistemas globales e interoperables (eadministración). Integrable de forma natural en estrategias SOA corporativas en las que se incluyen tecnologías de terceros. El producto se identifica por los siguientes puntos: o Capacidad real para diseñar sistemas de información complejos en términos manejables de tiempo, coste y capacidad de mantenimiento evolutivo. La principal característica de PROCESA es su sencillez y rapidez de implantación, así como la inmediata capacidad para la obtención de resultados en términos de desarrollo rápido de aplicaciones, con unos considerables aumentos de productividad. Página 7 de 50

8 o o o o o o o o o Actualizado a las últimas tecnologías líderes de mercado. Adecuación perfecta a requisitos de usuario para los sistemas de información construidos con el producto. Orientación completa sobre Reutilización de Servicios, Interoperabilidad y Accesibilidad Web. RAD: Rapid Application Development. Capacidad para definir modelos de proceso verticales: CMMI, ITIL, eadministración, etc. Compatible con productos BPM de fabricante: BEA AquaLogic BPM, ORACLE BPM, Oracle BPEL, IBM WebSphere, etc. Construcción de procesos sobre servicios de PROCESA, corporativos o de terceros. Directamente implantable sobre una arquitectura de Bus de Servicios. Gestión de Contenidos integrada dentro de los modelos de procesos. Las principales funciones de seguridad ofrecidas por el TOE para garantizar la seguridad, trazabilidad y auditoría de los procedimientos, tareas y acciones ejecutadas son las siguientes: Autenticación: Permite la autenticación de los usuarios y aplicaciones remotas. La herramienta utiliza para ello la identificación mediante usuario y contraseña. Trazabilidad: Almacena información de todos los eventos que ocurren en el sistema permitiendo de ésta forma realizar el seguimiento completo de la ejecución de los procesos. Auditoría: Asociado a cada evento que se produce en el sistema se almacena información relativa al usuario o aplicación que provocó dicho evento en el sistema. No forman parte del TOE, aunque si de PROCESA, otros módulos cuyas características principales son: Conjunto completo de herramientas de Definición, Diseño y Construcción de los modelos de procesos, y un Motor de Ejecución de Procesos que presenta aplicaciones finales al usuario (Web y Movilidad) Tipo y uso de TOE PROCESA Engine es una aplicación basada en una arquitectura orientada a servicios que permite la gestión del ciclo de vida de procesos, tareas y acciones encargadas de ser ejecutadas por ciertas personas o grupo de personas ofreciendo sus funcionalidades en base a servicios web. PROCESA Engine (TOE) es el encargado de gestionar la ejecución de todos los procesos de negocio definidos, las instancias, la gestión del flujo de ejecución y toda la gestión del ciclo de vida de las tareas de PROCESA. Su Arquitectura Orientada a Servicios (SOA) permite su interconexión y reutilización de servicios ya existentes en una organización, así como su futuro uso en caso de existir en la actualidad. Así mismo, permite que otros sistemas o componentes externos puedan hacer uso de los servicios que ofrece el propio producto de forma estándar para su interacción. Página 8 de 50

9 1.4.2 Hardware y software no incluido en el TOE Los requisitos software y hardware, así como las opciones referidas son los que se indican a continuación. Estos elementos no se incluyen en el TOE, por tanto es necesario disponer de los mismos: Servidor de aplicaciones. El servidor de aplicaciones ha de soportar una máquina virtual Java J2SE ó superior. Servidor Aplicaciones compatible J2EE 1.4 o superior (JBoss 5.0.X o superior, Weblogic 9 o superior, Websphere 6.1 o superior, OAS 10g o superior) con mínimo 2 procesadores y 2GB RAM. Servidor de portal. El servidor de portales ha de soportar una máquina virtual Java J2SE ó superior. Servidor Portal compatible con el estándar JSR-168 (JBoss Portal 2.7.X +, Weblogic Portal 9.2+, Websphere Portal 6.1+, Oracle Portal 10g+) con mínimo 2 procesadores y 2GB RAM. Servidor base de datos. El servidor de base de datos ha de tener disponible un driver de tipo JDBC. Entre otros puede ser Oracle 9i,10g,11g. SQLServer 2000, MySQL 5.x. DB2 8 o superior. Sistema operativo. El sistema operativo de los equipos puede ser cualquiera sobre el que se puedan instalar de forma certificada los servidores de aplicaciones anteriormente descritos. Java Runtime Enviroment. Respecto a la versión del runtime Java (J2SE) sobre el que se ejecutará el servidor de aplicaciones es necesario como mínimo que sea J2RE o superior. Servidor LDAP. Como servidor LDAP se puede utilizar cualquiera que soporta la especificación LDAP v3. Como por ejemplo, OpenLDAP, Active Directory Gestor de contenido. PROCESA utiliza un gestor de contenido para almacenar los documentos asociados a los procesos que se ejecutan dentro del motor de ejecución de procesos (PROCESA Engine). El gestor de contenidos tiene que soportar el estándar JSR170. Navegadores. Cualquiera de los siguientes es válido: o Microsoft Internet Explorer v6.0 Service Pack 2 o superior. o Netscape Comunicator v6 o superior. o Mozilla v4.1 o superior. o Firefox 3.0.x o superior. El detalle de la configuración tanto lógica como física requerida y seleccionada para la evaluación se encuentra en el apartado 1.6 Configuración evaluada. Página 9 de 50

10 1.5 TOE Description Como se indicó anteriormente, es necesario distinguir entre PROCESA como producto y el objeto de evaluación (TOE): PROCESA: un producto basado en SOA que contiene una gestor BPM, los servicios necesarios para su administración y ejecución y herramientas para la creación e interacción con los procesos e instancias. TOE: el objeto de evaluación que consiste en el módulo PROCESA Engine, el núcleo principal de PROCESA, y que engloba el motor de BPM y la aplicación SOA junto con todos los servicios de administración y ejecución. El TOE objeto de la presente Declaración de Seguridad posee como interfaz de cara al exterior una serie de servicios Web agrupados en entidades y publicados para ofrecer sus funcionalidades. En adelante, este conjunto será referido con la denominación Servicio del TOE. Se incluye, además, un componente adicional denominado PROCESA Engine Administrator, que no forma parte del TOE y que proporciona un interfaz web para el despliegue, configuración, monitorización y gestión del TOE. Teniendo en cuenta lo anterior, a continuación se presenta una breve descripción de la totalidad de los módulos que componen el producto PROCESA. Dichos módulos a su vez se dividen en componentes, los cuales y para el caso del TOE, ofrecen los servicios y utilidades del TOE. PROCESA consta de los siguientes módulos principales: o Herramienta de Modelización de Procesos: PROCESA Model o Herramienta de Diseño y Construcción de Procesos: PROCESA Builder o Servicio Universal de Acceso a Datos de Aplicación: PROCESA SRDA o Diseño de Interfaz de Usuario: PROCESA Web Designer o Presentación de Páginas y Diálogos de Usuario: PROCESA Painter o Motor de Ejecución: PROCESA Engine (TOE) o Administración y Monitorización: PROCESA Engine Administrator o Generador de Informes: PROCESA Reports o API de Integración con PROCESA: PROCESA Integrator Mediante PROCESA Model, los analistas de negocio pueden crear los modelos de procesos correspondientes a las funcionalidades requeridas por el sistema de información que se está diseñando, con toda la sencillez que se precisa para esta tarea por parte de usuarios no técnicos, al mismo tiempo que el trabajo realizado sirve para definir el proceso de forma real, almacenándose en un formato estructurado que pueden utilizar posteriormente los técnicos que deben construir las tareas de cada proceso. Mediante PROCESA Builder, los diseñadores de aplicaciones workflow tienen la posibilidad de diseñar y construir las tareas de los modelos de procesos definidos por los analistas de negocio. Los diseñadores pueden construir dichas tareas sin necesidad de programar una sola línea de código, ya que dicha construcción se realiza mediante la invocación de servicios que componen todas las acciones que son necesarias para construir cualquier tarea de un proceso administrativo. El módulo PROCESA SRDA consiste en un servicio de repositorio de datos de aplicación que proporciona acceso para lectura y actualización transaccional de datos y meta-datos de las aplicaciones construidas con PROCESA. De esta forma, se aísla la complejidad de las distintas fuentes de datos de la construcción de los procesos. Página 10 de 50

11 El módulo PROCESA Web Designer permite el diseño del interfaz gráfico de usuario del sistema mediante la utilización de servicios de diseño sobre estándares de portales web. Web Designer permite construir todos los diálogos de usuario que son directamente instalables en el portal que gobierna el proceso. PROCESA Painter es el componente de ejecución que presenta todas las páginas de usuario en el portal de Administración Electrónica, así como los diálogos con el usuario necesarios para la ejecución de las tareas del proceso. Una vez construidos todos los objetos y reglas que definen el sistema BPM final (Modelo de Aplicación). PROCESA Engine se encarga de interpretar el modelo y presentar las aplicaciones a los usuarios en tiempo real. Para administrar el sistema y monitorizar los procesos y las tareas que definen el sistema BPM final (Modelo de Aplicación). Este módulo es el Objeto de Evaluación (TOE) de la presente Declaración de Seguridad. PROCESA Engine Administrator se encarga de administrar y monitorizar el sistema en tiempo real. El módulo PROCESA Reports consiste en un generador de informes para perfiles de desarrollo, que permite el diseño y construcción de los informes de las aplicaciones construidas con PROCESA. El módulo PROCESA Integrator proporciona el API (Application Program Interface) completo basado en Java y en Servicios Web, para la integración de cualquier sistema externo con las aplicaciones PROCESA. Una vez descritos los módulos del producto PROCESA nos centraremos en describir en mayor detalle las características y componentes que incluye el módulo PROCESA Engine (TOE). Como características principales referentes a la seguridad el TOE es capaz de realizar el registro de las operaciones realizadas a los servicios que componen el Servicio del TOE. La generación de las auditorías las realiza un subsistema específico, Componente Auditoría, que registra el comienzo y el fin de la ejecución de un servicio invocado por una aplicación externa. El TOE dispone igualmente de la capacidad de controlar el acceso de las peticiones a los webservices del TOE por parte de las aplicaciones externas. Para ello, el TOE dispone de manejadores automáticos que verifican las peticiones recibidas y autentican las mismas dentro del sistema. Por lo que respecta a la aplicación de administración y configuración del TOE, módulo PROCESA Engine Administrator, permite configurar todo lo necesario para el uso del Servicio del TOE, permitiendo extraer información acerca de los procesos que se encuentran en ejecución, los roles de los usuarios, etc. La autenticación para el uso de la aplicación de administración PROCESA Engine Administrator se realiza por usuario/contraseña, utilizando los servicios de control de acceso disponibles en el TOE. Como se ha indicado anteriormente, las funcionalidades ofrecidas por el TOE se encuentran disponibles a través de un conjunto de componentes que pueden interaccionar entre sí. Estos componentes pueden trabajar de forma independiente y de forma distribuida. Dichos componentes pueden ser distribuidos en diferentes servidores, comunicándose entre sí a través de protocolos seguros SSL con o sin autenticación de cliente. Página 11 de 50

12 El TOE ofrece sus servicios a través de interfaces de tipo Webservice (SOAP/XML), es decir, el TOE publica sus funcionalidades de forma que puedan ser invocadas desde cualquier servidor utilizando diferentes tecnologías, lenguajes de programación, o sistemas operativos. La invocación de dichos interfaces es posible realizarse ya sea directamente mediante el fichero de definición del servicio web (Web Service Definition Language WSDL) o mediante la utilización de un componente cliente que encapsula las invocaciones a los servicios mediante la utilización de un interfaz Java. El acceso a dichos servicios puede realizarse utilizando comunicación HTTP o HTTPS, recomendándose únicamente HTTPS para la configuración más segura con el objeto de garantizar la confidencialidad de la información intercambiada. Todos los servicios interactúan con el componente de control de acceso el cual se encarga de la identificación y autenticación de la aplicación llamante, y únicamente en caso de estar correctamente identificada permitir el acceso al servicio. PROCESA Engine es el encargado de gestionar la ejecución de todos los procesos de negocio definidos, las instancias, la gestión del flujo de ejecución y toda la gestión del ciclo de vida de las tareas de PROCESA. Su Arquitectura Orientada a Servicios (SOA) permite su interconexión y reutilización de servicios ya existentes en una organización, así como su futuro uso en caso de existir en la actualidad. Así mismo, permite que otros sistemas o componentes externos puedan hacer uso de los servicios que ofrece el propio producto de forma estándar para su interacción. Para conseguir esta Arquitectura Orientada a Servicios, el propio PROCESA Engine incorpora como su espina dorsal un componente clave que es el Intermediador de Servicios (ESB), utilizando para ello la implementación Open Source llamada MULE ESB, sobre el cual se desarrollan e interconectan los restantes componentes y servicios que completan la arquitectura. En la siguiente figura se aprecia la relación entre los distintos componentes y tecnologías que componen el módulo PROCESA Engine que constituye el núcleo de PROCESA: Página 12 de 50

13 Ilustración 1- Arquitectura de PROCESA 1.6 Configuración evaluada En esta sección se especifican las características y requerimientos de la configuración evaluada del TOE. En particular, se detallan: 1) Detalle de componentes del módulo PROCESA Engine dentro de la configuración evaluada, indicados en el punto Componentes del TOE. 2) Diagrama de la arquitectura lógica de componentes del TOE, descrito en el apartado Arquitectura lógica del TOE. 3) Diagrama de arquitectura física de componentes del TOE, descrito en el apartado Arquitectura física del TOE. 4) Relación de componentes de terceros que deben ser utilizados junto con el TOE en su configuración evaluada, descritos en el apartado Requisitos de la configuración evaluada. Página 13 de 50

14 1.6.1 Componentes del TOE El conjunto de componentes que integran el TOE se detallan de forma gráfica en la siguiente figura: Ilustración 2- Componentes del TOE Todos los componentes que componen el módulo PROCESA Engine serán objeto de evaluación, siendo los componentes denominados Componente Auditoria y Servicios PROCESA (Servicios del TOE) el interfaz exterior dado que se tratan de los componentes que participan en el acceso a las funcionalidades expuestas por el motor de ejecución de procesos. Los Servicios del TOE están agrupados de la siguiente manera: Servicios de gestión del ciclo de vida de los procesos. Servicios de gestión del ciclo de vida de las tareas. Servicios de administración Servicios de gestión del acceso a datos. Servicios de gestión de contenido. Servicios de gestión de roles de proceso. Página 14 de 50

15 1.6.2 Arquitectura lógica La arquitectura lógica de la configuración evaluada se representa en la Ilustración 3 Arquitectura lógica de la configuración evaluada. En dicha arquitectura se diferencian dos casos, dependiendo de quién invoca los servicios del TOE. Estos son los siguientes: Administrador del sistema: Para configurar el TOE, el administrador del sistema utiliza el módulo PROCESA Engine Administrator. En la configuración evaluada, la comunicación entre este tipo de usuario y la consola de administración se realiza mediante el protocolo HTTPS. El administrador indica los datos que quiere configurar y la consola de administración invoca a los servicios de administración que son los encargados de almacenar la información suministrada en base de datos. El módulo PROCESA Engine Administrator utiliza siempre los servicios de administración del TOE por lo que se le puede considerar como una aplicación externa más con los mismos requisitos de identificación y seguridad que el resto de las aplicaciones externas. Aplicaciones externas: Las aplicaciones externas, así como el resto de los módulos que componen PROCESA, pueden interactuar con el Servicio del TOE, pero no con la consola de administración. En la configuración evaluada, los servicios del TOE están desplegados como servicios Web y las invocaciones se realizan vía HTTPS encapsulando mensajes SOAP en formato XML y haciendo uso de las cabeceras de seguridad de servicios Web (UsernameToken y timestamp). Existe la posibilidad igualmente de utilizar el componente cliente de invocación a los Servicios del TOE el cual facilita las labores de integración permitiendo utilizar a las aplicaciones externas un interfaz basado en Java para realizar las invocaciones a los servicios del TOE. De forma gráfica: Ilustración 3 Arquitectura lógica de la configuración evaluada La comunicación con el TOE, ya que publica sus funcionalidades vía webservices, puede realizarse de dos formas. Una, invocando directamente los servicios por parte de la aplicación usuaria mediante el interfaz de definición de los servicios. Dos, usando el módulo cliente PROCESA EngineClient que permite a las aplicaciones usuarias su uso directo como interfaz Página 15 de 50

16 Java y que se encarga de la construcción de los mensajes para la invocación a los servicios web. Su utilización es una facilidad que incorpora PROCESA pero no es de obligado uso. La configuración evaluada admite el uso del módulo cliente para agilizar las labores de integración Arquitectura física del TOE Ya se ha mostrado la arquitectura lógica del TOE en el apartado anterior. A nivel físico, el TOE consiste en: Por un lado, un único archivo que contiene todos los módulos de PROCESA Engine empaquetados y que es posible desplegar en un servidor de aplicaciones (JBOSS, Weblogic, IBM WebSphere, ) Por otro, una serie de archivos de configuración en los que se establecen los parámetros de funcionamiento del PROCESA Engine Arquitectura física de la configuración evaluada La arquitectura física de la configuración evaluada se representa en la Ilustración 4 Arquitectura física de la configuración evaluada. En dicha arquitectura el módulo PROCESA Engine (TOE) y el módulo PROCESA Engine Administrator estarán ubicados en un servidor, la invocación entre ellos se realizará usando el módulo PROCESA EngineClient, el cual encapsula las llamadas a los servicios web del TOE. Por lo que respecta a las aplicaciones usuarias éstas se alojarán en un equipo diferente al anteriormente citado. Este segundo equipo albergará a los módulos PROCESA WebDesigner y PROCESA Painter los cuales utilizarán también el módulo PROCESA EngineClient para realizar las invocaciones a los servicios del TOE. Lo anterior queda igualmente reflejado en la Ilustración 4 Arquitectura física de la configuración evaluada. De esta forma, la configuración evaluada incluirá únicamente las invocaciones remotas a los servicios del TOE. El administrador se comunica con el TOE a través de protocolo HTTPS. La interacción entre las aplicaciones usuarias (PROCESA WebDesigner y PROCESA Painter) y el TOE se efectúa mediante la invocación a los servicios web usando protocolo HTTPS y utilizando las cabeceras de seguridad web para la identificación y autenticación de las mismas. Página 16 de 50

17 Ilustración 4 - Arquitectura física de la configuración evaluada La consola de administración (PROCESA Engine Administrator) es el módulo a través del cual se realiza la inserción y/o edición de la información alojada en la base de datos del motor de ejecución PROCESA Engine. El módulo PROCESA Engine Administrator es utilizado únicamente por el administrador del sistema, y se comunica únicamente con el módulo PROCESA Engine (TOE). La autenticación ante la consola de administración se realiza mediante usuario/contraseña pero la validación de la autenticación del usuario se realiza mediante la invocación a los servicios del TOE encargados de la autenticación. Por tanto la consola de administración delega la autenticación del usuario al componente de control de acceso del módulo PROCESA Engine. De la arquitectura anterior debe tenerse en cuenta que tanto la Base de Datos, como el Gestor de Contenidos y el Servidor LDAP no son componentes que pertenezcan al TOE, sino un software de terceros. El resto de componentes de terceros requeridos para el funcionamiento de la configuración base (Servidor de Aplicaciones, Servidor de Directorio, Servidor de Portal, Servidor Base de Datos, Gestor de Contenidos, JDK) se instalarán siguiendo las indicaciones recogidas en el apartado Requisitos de la configuración evaluada Requisitos de la configuración evaluada A continuación se detallan los requisitos necesarios para la instalación en un entorno seguro de la configuración evaluada del TOE presentada en el apartado 1.6 Configuración evaluada. Los requisitos software y hardware, así como las opciones referidas son los que se indican a continuación. Así, para el funcionamiento de PROCESA es necesario disponer de los siguientes componentes software: Servidor de aplicaciones. El servidor de aplicaciones ha de soportar una máquina virtual Java J2SE ó superior. Servidor Aplicaciones compatible J2EE 1.4 o superior (JBoss 5.0.X o superior, Weblogic 9 o superior, Websphere 6.1 o superior, OAS 10g o superior) con mínimo 2 procesadores y 2GB RAM. Servidor de portal. El servidor de portales ha de soportar una máquina virtual Java J2SE ó superior. Servidor Portal compatible con el estándar JSR-168 (JBoss Portal Página 17 de 50

18 2.7.X +, Weblogic Portal 9.2+, Websphere Portal 6.1+, Oracle Portal 10g+) con mínimo 2 procesadores y 2GB RAM. Servidor base de datos. El servidor de base de datos ha de tener disponible un driver de tipo JDBC. Entre otros puede ser Oracle 9i, 10g, 11g. SQLServer 2000, MySQL 5.x. DB2 8 o superior. Sistema operativo. El sistema operativo de los equipos puede ser cualquiera sobre el que se puedan instalar de forma certificada los servidores de aplicaciones anteriormente descritos. Java Runtime Enviroment. Respecto a la versión del runtime Java (J2SE) sobre el que se ejecutará el servidor de aplicaciones es necesario como mínimo que sea J2RE o superior. Servidor LDAP. Como servidor LDAP se puede utilizar cualquiera que soporta la especificación LDAP v3. Como por ejemplo, OpenLDAP, Active Directory Gestor de contenido. PROCESA utiliza un gestor de contenido para almacenar los documentos asociados a los procesos que se ejecutan dentro del motor de ejecución de procesos (PROCESA Engine). El gestor de contenidos tiene que soportar el estándar JSR170. Navegadores. Cualquiera de los siguientes es válido: o Microsoft Internet Explorer v6.0 Service Pack 2 o superior. o Netscape Comunicator v6 o superior. o Mozilla v4.1 o superior. o Firefox 3.0.x o superior. Dentro de todas las posibilidades que ofrecen estos requisitos software, la configuración que se ha elegido para su evaluación es la siguiente: Servidor de aplicaciones. JBoss Enterprise Application Platform Servidor de portal. JBoss Portal Server Servidor base de datos. Oracle Sistema operativo: Red Hat Enterprise Linux 5 Java Runtime Enviroment: JRE 1.6u18 Navegadores: Mozilla Firefox Servidor LDAP: OpenLDAP Gestor de contenidos: Jackrabbit Página 18 de 50

19 El despliegue de los servicios web del TOE para permitir el acceso a las aplicaciones externas (usuarias) se realizará utilizando la siguiente configuración: Conexión mediante protocolo SSL (https) SOAP Cabeceras de seguridad web (Web Service Secutiry) para la identificación y autenticación de la aplicación externa (UsernameToken + Timestamp) 2 Conformidad Se declara la conformidad del TOE con las Partes 2 y 3 de Common Criteria for Information Technology Security Evaluation, v3.1 Revisión 3 de Junio de En concreto, con: Requerimientos Funcionales de seguridad de la Parte 2 de CC Version 3.1. Revision 3. Requerimientos de Garantía de Seguridad de la Parte 3 de CC Version 3.1 Revision 3 para el Nivel de Certificación EAL1+ (ALC-FLR.1, +ASE_SPD.1, +ASE_OBJ.2, +ASE_REQ.2.). Página 19 de 50

20 3 Definición del problema de seguridad Las principales características que se deben asegurar son: Autenticación: garantiza la identidad de los usuarios remotos. Control de acceso: garantiza que solo los usuarios autorizados puedan acceder a los servicios. Capacidad de recuperación: asegura que la información, así como los procedimientos asociados a su generación y uso, puedan ser recuperados en el momento en el que se necesiten, quedando accesibles a los usuarios autorizados. 3.1 Activos a proteger Con el objeto de asegurar las características anteriormente descritas se han detectado una serie de activos que es necesario proteger, garantizando el cumplimiento de dichas características para cada uno de ellos. Se presenta a continuación la enumeración y descripción de estos activos Activo 01: Confidencialidad de las contraseñas almacenadas en base de datos o ficheros de configuración Existen varias contraseñas que han de ser almacenadas en base de datos o en ficheros de configuración de manera confidencial (es decir, cifradas), y protegidas de lecturas no permitidas. Éstas son las siguientes: Contraseña de acceso a la base de datos interna de PROCESA Engine. Contraseñas de acceso para las aplicaciones externas clientes de PROCESA Engine. (Estas aplicaciones clientes envían los datos de su identidad en las cabeceras de seguridad de la invocación de los servicios web del TOE) Contraseñas de acceso al repositorio de datos interno y de contenidos. Contraseñas de acceso a LDAPs: con ellas se accede al correspondiente repositorio LDAP, en el caso de que el acceso no sea anónimo. Contraseñas de acceso servidor de correo: utilizada para establecer la conexión con el servidor de correo corporativo Activo 02: Integridad de la gestión de roles de proceso Para poder ejecutar un proceso previamente modelado es necesario que se realice una asignación segura y confiable de los roles de proceso definidos en los modelos con los usuarios, grupos de usuarios o perfiles concretos de una organización. Esta asociación permite que las tareas queden únicamente accesibles a determinados usuarios o grupos de usuarios por lo tanto tiene que ser gestionada de forma segura. Es necesario aclarar que no es lo mismo una aplicación externa que un usuario. Las aplicaciones externas son las que hacen uso de los servicios del TOE, los usuarios son los actores que van a participar en los servicios específicos de BPM. La gestión de los roles de proceso se realiza integrada con el directorio LDAP corporativo, dicha asociación se realiza utilizando la información de usuarios, grupos y perfiles disponibles en un Página 20 de 50