ANEXO 1 Consideraciones para la homogeneización del entorno tecnológico con otros proyectos del Gobierno de Aragón ANEXO 1 ....................................................................................................................................................1 1 INTRODUCCIÓN..............................................................................................................................3 1.1 REQUISITOS TÉCNICOS ....................................................................................................................3 1.1.1 Requisitos de las plataformas...............................................................................................3 1.1.2 Requisitos de los desarrollos ................................................................................................4 1.2 RECOMENDACIONES PARA LA INTEGRACIÓN DE DATOS Y APLICACIONES .......................................6 1.2.1 Integración de datos y middleware.......................................................................................6 1.2.2 Presentación e intercambio de datos....................................................................................7 1.2.3 Seguridad..............................................................................................................................8 1.3 ESTÁNDARES ABIERTOS Y SOFTWARE LIBRE ...................................................................................9 1 Introducción Se indican a continuación diversas consideraciones a observar por parte de la adjudicataria en orden a homogenizar el entorno tecnológico de este proyecto con otros ya impulsados por el Gobierno de Aragón tanto en aspectos técnicos como de intercambio de datos o relativos al tipo de licencia del software desarrollado. Partiendo de esta base, se valorará especialmente en las soluciones tecnológicas propuestas su planteamiento homogéneo de integración con otras arquitecturas y servicios, así como su cumplimiento de los estándares europeos para la conexión entre administraciones. 1.1 Requisitos Técnicos Se indicará la arquitectura técnica planteada por la empresa licitadora para dar soporte al desarrollo e implantación del sitio web 2.0 y las funcionalidades recogidas en la oferta, que en todo caso deberá cumplir lo señalado en este capítulo. 1.1.1 Requisitos de las plataformas Las plataformas propuestas deberán construirse sobre arquitecturas abiertas, que estarán especialmente enfocadas a la integración de los servicios que se implanten con los de otras arquitecturas y aplicaciones. Los objetivos principales que deberán cumplir las arquitecturas son los siguientes: • Modular. La arquitectura deberá ser modular, permitiendo que los nuevos servicios que se implanten puedan ser tratados como unidades independientes, fácilmente integrables en el conjunto del sistema. • Escalabilidad. La plataforma seleccionada será altamente escalable, garantizando de este modo el crecimiento de la solución en función del desarrollo de futuros servicios y contenidos, y del incremento de usuarios. • Alta disponibilidad. Se configurará un sistema de alta disponibilidad que minimice los puntos de fallo, de manera que si cualquiera de las partes críticas de la aplicación sufre un fallo en su nivel de servicio, éste no afecte al conjunto de la aplicación. • Fiabilidad. Los sistemas deberán ofrecer una disponibilidad no inferior al 90%, y su diseño garantizará la integridad de los datos involucrados, en caso de producirse un fallo en el funcionamiento de los sistemas. • Seguridad. Se implementarán las soluciones de seguridad necesarias, tanto desde el punto de vista físico como lógico, que permitan cumplir al menos las normativas recogidas el apartado sobre Seguridad del presente documento. • Rendimiento. La respuesta a los usuarios será tan rápida como sea técnicamente posible conseguir con los condicionamientos impuestos. Esta característica deberá mantenerse a medida que el sitio y el número de usuarios aumenten. • Tolerancia a fallos. Se implementarán mecanismos de tolerancia a fallos, quedando garantizado el funcionamiento de los sistemas ante anomalías tanto de hardware como de software. • Configuración del sistema. Toda la información relativa al comportamiento, configuración o explotación del sistema deberá residir en ficheros estructurados basados en formatos estándar abiertos y completamente documentados. • Sistemas de monitorización y alerta. La plataforma seleccionada incorporará las herramientas necesarias para la gestión de los sistemas, su monitorización, visualización y tratamiento de alertas, etc. • Adecuación, en lo posible, a las actuaciones puestas en marcha por parte de la administración como: programa PISTA, programa IDABC de la Unión Europea, etc. 1.1.2 Requisitos de los desarrollos Las aplicaciones y servicios desarrollados sobre las plataformas abiertas mencionadas en el apartado anterior deberán cumplir los siguientes requisitos: • Portabilidad. Los desarrollos realizados tendrán en cuenta las tendencias actuales de última generación en materia de programación y portabilidad a otros entornos (multiplataforma). • Accesibilidad. Se adoptarán los mecanismos necesarios para cumplir los requisitos en materia de accesibilidad establecidos por el W3C a través de la WAI (Iniciativa para una Web Accesible, del Consorcio World Wide Web) y, en concreto, las especificaciones de la Recomendación de 5 de mayo de 1999 sobre Pautas de Accesibilidad del Contenido en la Web (en su última versión). En cualquier caso, se exigirá la accesibilidad que normativamente hayan establecido las administraciones públicas, tanto nacionales como europeas. Los desarrollos se orientarán para conseguir un grado mínimo de accesibilidad A, intentando por todos los medios alcanzar el grado AA. En todo caso, deberá de cumplir lo establecido en los estándares y normativa vigente, especialmente la Ley 34/2002 de 11 de Julio de Servicios de la Sociedad de la Información y Comercio Electrónico que obliga a las Webs de las Administraciones Públicas a cumplir las pautas de accesibilidad establecidas por la W3C, la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los servicios públicos, en su artículo 4.c), establece el principio de accesibilidad a la información y a los servicios por medios electrónicos en los términos establecidos por la normativa vigente en esta materia, a través de sistemas que permitan obtenerlos de manera segura y comprensible, garantizando especialmente la accesibilidad universal y el diseño para todos los soportes, canales y entornos con objeto de que todas las personas puedan ejercer sus derechos en igualdad de condiciones, incorporando las características necesarias para garantizar la accesibilidad de aquellos colectivos que lo requieran, así como los requisitos en materia de accesibilidad establecidos en el Real Decreto 1494/2007, de 12 de noviembre, por el que se aprueba el Reglamento sobre las condiciones básicas para el acceso de las personas con discapacidad a las tecnologías, productos y servicios relacionados con la sociedad de la información y medios de comunicación social. • Usabilidad. Se mantendrán en la aplicación unos criterios de usabilidad mínimos siguiendo las normas elaboradas al efecto por el Laboratorio de Usabilidad del Gobierno de Aragón ubicado en Walqa • Navegabilidad. Se evitará en lo posible el uso de aplicaciones que usen código no estandarizado y que obliguen a la obtención de un Plug-In para la visualización del resultado. El sistema desarrollado estará disponible para los navegadores más extendidos entre la comunidad de Internet, como mínimo Internet Explorer v5.5 y Mozilla Firefox. • Las herramientas y aplicaciones desarrolladas estarán separadas de su Base de Datos, accediendo a la información mediante métodos neutros de forma que se genere una capa de abstracción de cara a hacer posible su portabilidad o el uso remoto de bases de datos. • Plantillas y archivos de configuración. Toda la información relativa al comportamiento, configuración o explotación del portal deberá residir en ficheros estructurados basados en formatos estándar abiertos y completamente documentados. • Diseño. El diseño de la imagen de las aplicaciones deberá adaptarse a las normas de Imagen Corporativa del Gobierno de Aragón. 1.2 Recomendaciones aplicaciones para la integración de datos y Aunque el ámbito de las cuestiones que afectan a la interoperabilidad es muy extenso, el acuerdo sobre un conjunto de normas facilita la interoperabilidad y permite que el despliegue de las aplicaciones se pueda realizar de forma más rápida, más flexible y con menor coste. En este sentido, XML se plantea como el estándar más adecuado para el intercambio de información entre sistemas. XML permite definir estructuras de información como un conjunto de componentes modulares y fáciles de gestionar. Estos componentes se pueden crear, expandir, buscar, modificar, y enlazar con otros componentes, por medio de software que permita el uso de esquemas XML. 1.2.1 Integración de datos y middleware 1.2.1.1 Estándares XML Se recomienda emplear XML (Extensible Mark-up Language), y protocolos asociados, para interoperabilidad e integración de datos: • XML, para estandarizar documentos y dar formato a datos y mensajes • XSD, para la descripción de esquemas XML • XUL, para definir interfaces de usuario • XSL, XLST, para la conversión de formatos • XMI, para el intercambio de metadatos • DSML, para la integración de directorios • Wf-XML, para interoperabilidad de workflow • etc… 1.2.1.2 SOAP y Web Services Los desarrollos estarán orientados a la integración con servicios web (web services o web map services), incorporando la posibilidad de usar al menos el protocolo SOAP, valorándose la posibilidad de utilizar otros. Se tomarán como referencia las especificaciones respecto a web services generadas por el W3C. 1.2.1.3 Java y J2EE Preferentemente, se hará uso de Java 2 Enterprise Edition para el desarrollo e integración de aplicaciones; sin perjuicio de la utilización de otras herramientas de desarrollo que garanticen en todo caso, la capacidad de integración con otras aplicaciones. 1.2.1.4 EbXML EbXML es un estándar para la lógica de negocio electrónico. EbXML define una arquitectura para realizar transacciones de negocio basadas en mensajes XML dentro del contexto de procesos de negocio estándar. 1.2.1.5 Otras Interfaces Se valorará la disponibilidad de APIs de acceso a los servicios y aplicaciones, que permitan maximizar la interacción de los sistemas desarrollados con los nuevos desarrollos de aplicaciones en otros sitios web sobre biodiversidad, y que faciliten la reutilización de componentes en dichas aplicaciones. Estas APIs deben ser de acceso público y estar perfectamente documentadas. 1.2.2 Presentación e intercambio de datos Se recomienda que el conjunto de los desarrollos sea compatible con las últimas versiones de los estándares principales en formato de almacenamiento y tratamiento de la información, de manera especial con las establecidas por el W3C. Se utilizarán aquellos formatos de datos y programas para los que en la medida de lo posible se disponga de especificaciones públicas y libres de royalties y patentes. Se usarán esquemas de almacenamiento de la información que permitan una reutilización de la misma, y la generación de la presentación de la misma en formatos independientes del contenido. 1.2.2.1 Estándares de datos • Formatos de texto: TXT, PDF, RTF, XML, HTML, SXW, CSV, Encapsulated Postscript • Hojas de estilo: CSS, XSL • Formatos de datos estructurados: XML, Bases de Datos (usar bases de datos relacionales conformes con las normas internacionales sobre SQL, ANSI X3.135-1992/ISO 9075:1992), MIME (para mensajes de correo electrónico e intercambio electrónico de datos y ficheros adjuntos), etc. • Formatos Gráficos: JPEG, GIF, TIF, PNG, FAX, CGM, EPS, VML • Formatos Áudio y Vídeo: MPEG, MP3, GIF Animado, Real, Quick Time • Formatos comprimidos: ZIP, GZIP 1.2.3 Seguridad Los sistemas deberán disponer de las medidas de seguridad adecuadas, en proporción a la naturaleza de la información y del tratamiento que se le va a dar, así como de los riesgos a los que esté expuesta y del estado del arte actual de las tecnologías a utilizar. En particular, se deberán utilizar medios seguros para la autenticación e identificación de los usuarios donde esta identificación sea requerida y se contemplará el cifrado de la información, sobre todo para su transmisión por las redes. Cuando la información incluya datos de carácter personal deberá cumplirse con lo dispuesto en el Real Decreto 1720/2007, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal. 1.2.3.1 Autenticación Se plantean dos tipos de autenticación: • Autenticación fuerte: Se realizará, cuando sea necesario, haciendo uso de la plataforma de firma y autenticación telemática del Gobierno de Aragón. • Autenticación débil. La autenticación débil estará basada en nombre de usuario y contraseña. Se podrá exigir que las contraseñas tengan un número mínimo de caracteres, así como que sean cambiadas periódicamente y será posible limitar el número de intentos en los accesos. 1.2.3.2 Identificación de usuarios Se recomienda que los proyectos desarrollados hagan uso de una arquitectura de identificación basada en directorios. Los directorios almacenan información de los usuarios, y de sus perfiles, por lo que son la base para la autenticación y autorización de usuarios en las aplicaciones. LDAP es el estándar recomendado para hacer uso de servicios de directorios. Para la interoperabilidad entre directorios, se hará uso de estándares basados en XML, como DSML. 1.2.3.3 Confidencialidad e integridad de la información Se recomienda cifrar la información cuando la naturaleza de los datos y de los tratamientos y los riesgos a los que estén expuestos lo requiera, tanto en transacciones o comunicaciones como en almacenamiento. Los algoritmos deberán permitir una longitud mínima de claves de 128 bits, y se utilizarán preferentemente 3DES, IDEA, RC4, RC5, AES, o equivalentes. Para el establecimiento de sesión web cifrada se deberá utilizar el protocolo SSL v3/TLS v1 o superior con cifrado simétrico de, al menos, 128 bits. En correo electrónico seguro se deberá utilizar el estándar S/MIME. En sesiones de administración remota se deberá utilizar SSH. En las transacciones en que sea necesario garantizar la integridad de la información, se utilizarán procedimientos de firma electrónica. 1.2.3.4 Firma electrónica En el caso de implementarse mecanismos de firma electrónica, estos se realizarán mediante los algoritmos y certificaciones de clave pública utilizados por Prestadores de Servicios de Certificación reconocidos. En cualquier caso los desarrollos permitirán la identificación y firma mediante el DNI electrónico. 1.3 Estándares abiertos y Software libre Este proyecto debe avenirse a las recomendaciones y obligaciones respecto a estándares abiertos y software libre fijadas en el marco europeo, el Plan de Acción eEurope 2005 dicta que “El Marco Europeo de Interoperabilidad se basará en normas abiertas y fomentará el uso de programas de fuente abierta”. Así pues, se recomienda adoptar programas y aplicaciones de fuente abierta en aquellos ámbitos donde pueda haber soluciones de este tipo que satisfagan las necesidades y requisitos de la aplicación o información a conservar. En particular, se debe tener en cuenta para aprovisionarse, bien de productos o bien de desarrollos de software a medida, la oferta global de software disponible distribuido según diversos tipos de licencias y aplicar los criterios de racionalidad técnica y económica, evaluando, por tanto, todas las posibles alternativas en el marco de las obligaciones e intereses legítimos de la Administración, con independencia de cuáles sean los procedimientos de adquisición aplicables en cada caso.