ANEXO 1 Consideraciones para la homogeneización del entorno

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.