normativa de las infraestructuras corporativas para las ... · las peticiones .jsp a los servidores...

DGTNT-070003-TSI-NORM

Página 1 de 36

Telecomunicaciones y Sistemas Estado: Definitivo

Normativa de las Infraestructuras corporativas para lasAplicaciones del Gobierno de Canarias

Rev. Fecha Descripción

06 06/09/2018 Revisión completa del documento. Se añaden requisitos de desarrollo y exigenciade HTTPS.

05 31/01/2018 Se modifica el apartado 8 y se actualizan datos de contacto.

04 17/07/2017 Se revisa el documento, se eliminan las referencias a RedHat, se actualiza a laplantilla de DGTNT, se actualiza apartado 11.

Fecha 1ª Aprobación: 26/03/2015

Documento: DGTNT-070003-TSI-NORMNormativa de las Infraestructuras corporativas paralas Aplicaciones del Gobierno de Canarias

Ubicación: http s ://www.gobiernodecanarias.net/cibercentro/documentos/normativas/index.html

Nivel de Seguridad: Interno

Preparado por Revisado por Aprobado por

DGTNT_CiberCentro

Fecha: 06/09/2018

José Damián Ferrer Quintana

Fecha: 06/09/2018

Manuel Ángel Castellano Trujillo

Fecha: 06/09/2018

En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada laautenticidad de esta copia, mediante el número de documento electrónico siguiente:

0of3YIJZx6zGSujJftPzLQSUDtlJmqi70

https://www.gobiernodecanarias.net/cibercentro/documentos/normativas/index.html



https://sede.gobcan.es/sede/verifica_doc


Página 2 de 36

ÍNDICE

1. INTRODUCCIÓN...............................................................................................................4

2. OBJETIVO.........................................................................................................................4

3. DESTINATARIOS..............................................................................................................5

4. ALCANCE..........................................................................................................................5

5. RESPONSABILIDADES...................................................................................................5

6. ARQUITECTURA DE LA INFRAESTRUCTURA WEB....................................................6

6.1. DESCRIPCIÓN DE LA ARQUITECTURA PHP...........................................................................................76.2. DESCRIPCIÓN DE LA ARQUITECTURA JSP...........................................................................................76.3. DESCRIPCIÓN DE LA ARQUITECTURA ASP...........................................................................................86.4. BASE DE DATOS............................................................................................................................8

7. REQUISITOS Y RECOMENDACIONES EN EL DESARROLLO Y DESPLIEGUE.........9

7.1. DIFERENCIACIÓN DE ENTORNOS.........................................................................................................97.2. METODOLOGÍA..............................................................................................................................97.3. CARACTERÍSTICAS RECOMENDABLES..................................................................................................97.4. ESTRUCTURA DE CONTENIDOS.........................................................................................................107.5. USO DE PÁGINAS DE ERROR CORPORATIVAS.......................................................................................107.6. NOMENCLATURA DE LAS URL(S) DE ACCESO....................................................................................117.7. RECOMENDACIONES DE DISEÑO WEB E IMAGEN CORPORATIVA.................................................................117.8. DOCUMENTACIÓN.........................................................................................................................117.9. SEGURIDAD................................................................................................................................12

7.9.1. CUMPLIMIENTO NORMATIVO......................................................................................................127.9.2. MEDIDAS OBLIGATORIAS.........................................................................................................127.9.3. AUTENTICACIÓN CON CERTIFICADO DIGITAL................................................................................137.9.4. TRAZAS – LOGS...................................................................................................................13

7.10. RECOMENDACIONES GENERALES...................................................................................................14

8. SERVICIOS OFRECIDOS...............................................................................................15

8.1. ENTORNOS DISPONIBLES...............................................................................................................158.2. ALOJAMIENTO DE APLICACIONES.....................................................................................................15

8.2.1. SOLICITUD DE PUBLICACIÓN DE UNA APLICACIÓN...........................................................................158.2.1.1. Alta en el entorno de Pre-Explotación....................................................................178.2.1.2. Alta en el entorno de Explotación...........................................................................178.2.2. PUBLICACIÓN DE CONTENIDOS..................................................................................................178.2.3. BAJA DE APLICACIONES Y/O RECURSOS......................................................................................20

8.3. ALTA DISPONIBILIDAD..................................................................................................................208.3.1. BALANCEO SOFTWARE...........................................................................................................218.3.2. BALANCEO HARDWARE..........................................................................................................21

8.4. COPIAS DE SEGURIDAD................................................................................................................228.4.1. SERVIDORES DE APLICACIONES................................................................................................22





Página 3 de 36

8.4.2. BASES DE DATOS.................................................................................................................238.5. INTEGRACIÓN DE CAPTURA DE ERRORES DE APLICACIÓN EN SIRVETE...................................................24

9. REFERENCIAS...............................................................................................................24

9.1. DOCUMENTOS EXTERNOS A LA ORGANIZACIÓN....................................................................................249.2. DOCUMENTOS INTERNOS A LA ORGANIZACIÓN.....................................................................................25

10. CONTACTOS................................................................................................................26

1. ANEXO 1 DESCRIPCIÓN DE CONFIGURACIONES APACHE....................................27

2. ANEXO 2 DESCRIPCIÓN DE CONFIGURACIÓN PHP.................................................29

3. ANEXO 3 DESCRIPCIÓN DE CONFIGURACIÓN TOMCAT........................................32

4. ANEXO 4 DESCRIPCIÓN DE CONEXIONES A BASES DE DATOS...........................35

5. ANEXO 5 DESCRIPCIÓN DE CONFIGURACIONES DE LOS SERVIDORES IIS.......36





Página 4 de 36

1. INTRODUCCIÓN

El Gobierno de Canarias pone a disposición de las instituciones que lo componen, lainfraestructura necesaria para que puedan alojar sus aplicaciones. Dicha infraestructurase rige bajo una serie de normas y requisitos que se definen según los requerimientos deseguridad que una institución como el Gobierno de Canarias precisa y que pasa poradoptar un modelo de desarrollo óptimo.

Para conseguirlo se dota a los usuarios de una serie de normas para que desarrollen suscontenidos siguiendo la estructura de datos y la plataforma de desarrollo que la DirecciónGeneral de Telecomunicaciones y Nuevas Tecnologías (en adelante DGTNT) ha definido.

Actualmente se soportan contenidos estáticos sobre servidores Apache o IIS, sistemasoperativos Unix (Linux) y Windows, contenidos dinámicos en Java, JSP, PHP, ASP otecnologías .NET y accesos a servicios de Bases de Datos.

El modelo de publicación del que se dota a los usuarios (acceso mediante FTP a losservidores de contenido y modelo de Pre-explotación y Explotación para verificado de loscontenidos antes de su publicación final) se considera el más acertado tanto para losusuarios como para los administradores del Gobierno de Canarias.

2. OBJETIVO

Este documento define un conjunto de especificaciones organizativas y técnicas paraestandarizar el desarrollo, despliegue y, en general, gestión del ciclo de vida de lasaplicaciones que pretendan alojarse en la plataforma corporativa CiberGestionada delGobierno de Canarias, con el fin de:

Aumentar la estabilidad. Eliminar cuellos de botella. Aislar aplicaciones. Compatibilidad de versiones. Cumplir la legislación vigente relacionada con la seguridad de la información

(ENS1, RGPD2 y LOPD3). Facilitar la creación de planes de contingencia para minimizar los efectos

negativos frente a siniestros. Facilitar el alojamiento (Hosting) de las aplicación en entornos gestionados por

la DGTNT.

1 Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la AdministraciónElectrónica.2 Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo de 27 de abril de 2016 relativo a la protección de las personasfísicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva95/46/CE.3 Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal.





Página 5 de 36

Asegurar la elaboración, durante el desarrollo, de una documentación completade la aplicación, para permitir su completo entendimiento y, en caso necesario,su continuación y mantenimiento.

Minimizar los costes de mantenimiento. Aprovechar al máximo los recursos disponibles. Asegurar la calidad del software desarrollado. Facilitar la integración de la aplicación con otros sistemas de la organización. Estimar las necesidades de recursos de la aplicación.

3. DESTINATARIOS

Responsables de las aplicaciones, y grupos implicados en el desarrollo/adquisición,despliegue y/o gestión de aplicaciones de los órganos y organismos asociados delGobierno de Canarias.

El personal destinatario (tanto personal del Gobierno de Canarias como empresas deservicios) realizará todos los trabajos necesarios para dar cumplimiento a los requisitosestablecidos.

4. ALCANCE

Este procedimiento cubre la plataforma corporativa CiberGestionada del Gobierno deCanarias, y cualquier aplicación, ya sea web o cliente-servidor, o servicio web que se alojesobre ella.

Se recomienda que las aplicaciones sean siempre web y no cliente-servidor parareducir las dependencias con los equipos cliente.

5. RESPONSABILIDADES

Las responsabilidades son:− CiberCentro: disponibilidad de la plataforma.− Servicios de desarrollo: diseño y estabilidad de la aplicación software

desarrollada.





Página 6 de 36

6. ARQUITECTURA DE LA INFRAESTRUCTURA WEB

La plataforma web del Gobierno de Canarias está formada por diversas capastecnológicas. Su estructura completa es compleja, por lo que la descripción a continuaciónse limita a aportar una idea resumida de las capas más relevantes a efectos de estedocumento:

• Primera capa: primero se encuentra una capa electrónica de red formada por losbalanceadores de peticiones web, que reparten las peticiones de forma equitativa ala capa inferior (frontales web). Es capaz a su vez de detectar sobrecargas ypérdida de servicio de dichas máquinas para no enviarles peticiones en dichosmomentos. Así pues, provee a la plataforma de tolerancia a fallos y altadisponibilidad.

• Segunda capa: seguidamente y conectados a los balanceadores se encuentranlos frontales web en arquitectura Linux con el software Apache. Estos servidores seencargan de procesar las peticiones a los dominios web que aloja el Gobierno deCanarias en los diferentes niveles que provee (www, www2, www3,…). Ver Anexo1.

Esta separación en niveles de los frontales web permite repartir de forma ordenadala carga de estos frontales, y separar aquellas aplicaciones que se hayan quedadoobsoletas o con rendimiento insuficiente.

En concreto, el primer nivel (www) se encargará de procesar y servir aquellaspeticiones de código estático, PHP, o que se encuentren programadas en códigoJava y funcionen sobre servidores de aplicaciones Tomcat o JBoss a través delconector Apache Jserv Protocol (AJP).

• Tercera Capa: a continuación se encuentran los servidores donde se alojan lasaplicaciones web. Servidores de aplicaciones TOMCAT, JBOSS o IIS.

• Cuarta Capa: Por último, los datos de las aplicaciones pueden estar disponibles enel servicio de base de datos (Normativa para el uso de BBDD corporativas en lasinfraestructuras de Sistemas del Gobierno de Canarias)

Las versiones soportadas por los distintos niveles de la infraestructura web del Gobiernode Canarias se establecen en el documento “Normativa de utilización de herramientascorporativas en las Infraestructuras de Sistemas del Gobierno de Canarias”.





Página 7 de 36

Ilustración 1. Descripción de la arquitectura

6.1. Descripción de la arquitectura PHP

PHP es un lenguaje interpretado de propósito general ampliamente usado y que estádiseñado especialmente para desarrollo web y puede ser incrustado dentro de códigoHTML. Se ejecuta en un servidor web Apache, tomando el código en PHP como suentrada y creando páginas web como salida.

Dentro de la infraestructura corporativa se dispone de soporte para aplicaciones PHP enla versión aprobada por la DGTNT. Con motivo de lograr un correcto funcionamiento delas aplicaciones corporativas ya existentes y a modo de guía para las futuras, en laplataforma corporativa se han modificado una serie de parámetros con respecto a laconfiguración por defecto del motor PHP y la manera de compilarlo. La informacióntécnica de esta configuración y la relación de módulos instalados se encuentran en elAnexo 2.

6.2. Descripción de la arquitectura JSP

Los frontales web, en función de la configuración y del tipo de páginas, pasarán laspeticiones .jsp a los servidores de aplicaciones corporativos correspondientes, a travésdel módulo mod_jk instalado en cada uno de los frontales o del módulomod_proxy_balancer propio de Apache.





Página 8 de 36

Los servidores de aplicaciones corporativos, en general, estarán sirviendo en grupos de almenos dos servidores idénticos, balanceados ante fallos por el conector en unaconfiguración “JK_TRUE”, con el objetivo de que tengan el mismo comportamiento. En elcaso de que el responsable lo requiera (por necesidades funcionales), la aplicación seapuntará a un único servidor de aplicaciones.

Dichos servidores podrán ser de dos tipos:

• Tomcat (también llamado Jakarta Tomcat o Apache Tomcat), que funciona comoun contenedor de servlets desarrollado bajo el proyecto Jakarta en la ApacheSoftware Foundation. Tomcat implementa las especificaciones de los servlets y deservicios de Bases de Datos. Ver Anexo 3.

• JBoss, que es un servidor de aplicaciones J2EE de código abierto implementadoen Java puro. Al estar basado en Java, JBoss puede ser utilizado en cualquiersistema operativo que lo soporte.

Ambos tipos de servidores son los encargados de procesar el código JSP para proveer elsoporte a aplicaciones Java diseñadas para un entorno J2EE. Estos servidores estánsobre plataforma con sistema operativo Linux.

6.3. Descripción de la arquitectura ASP

Los frontales web, en función de la configuración y del tipo de páginas, encaminarán laspeticiones a través de la tecnología de Proxy Inverso a los servidores de aplicacionesInternet Information Server (IIS) de Microsoft, balanceados por Hardware, cuando se tratede páginas ASP o ASP.NET, incluyendo si es necesario contenido HTML.

6.4. Base de datos

En un siguiente nivel estaría el acceso a las Bases de Datos. Los sistemas de gestión debases de datos soportados, así como los requisitos adicionales específicos a tener encuenta en el desarrollo y despliegue de aplicaciones que deseen hacer uso de BBDDcorporativas se detallan en el documento “Normativa para el uso de BBDD corporativasen las Infraestructuras de Sistemas del Gobierno de Canarias”. Ver Anexo 4.





Página 9 de 36

7. REQUISITOS Y RECOMENDACIONES EN EL DESARROLLO Y DESPLIEGUE

7.1. Diferenciación de entornos

De conformidad con el Esquema Nacional de Seguridad, deben existir entornosdiferenciados de desarrollo y explotación, y cualquier cambio debe ser probado antes depasar a producción. Así, deben existir tres entornos bien diferenciados en el ciclo de vidade una aplicación:

• Entorno de Desarrollo, donde los desarrolladores programarán las aplicaciones yrealizarán cualquier modificación posterior que deba sufrir una aplicación.

• Entorno de Pre-explotación, donde los desarrolladores integrarán inicialmente lasaplicaciones y realizarán todas las pruebas que consideren oportunas, hastaobtener la conformidad del responsable de la aplicación.

• Entorno de Explotación, donde se trasladarán las aplicaciones tras laconformidad del responsable de aplicación, siguiendo el procedimiento de Gestiónde Cambios. Una vez en Explotación, si se quiere modificar contenidos, deberánprobarse en Pre-explotación y verificar su operatividad antes de pasar aExplotación a través de un Cambio.

7.2. Metodología

El desarrollo seguirá la metodología Metrica v3, recomendada por el Ministerio deAdministraciones Públicas (MAP).

La notación a usar será la de Metrica v3, o en su defecto UML (Unified Model Language).

7.3. Características recomendables

Estos aspectos serán en todo caso obligatorios en los casos en los que el ENS así lodetermine:

• La aplicación debe estar basada en arquitecturas abiertas.• La aplicación será multicapa, manteniendo la independencia de la interfaz gráfica

respecto al diseño de los procesos de negocio y éstos, a su vez, con la base dedatos, pudiendo cada capa actuar en diferentes equipos en comunicación con elresto y facilitando la administración y mantenimiento remotos.

• Idealmente se intentará que cualquiera de los navegadores de Internet másimplantados pueda ser cliente de la aplicación, sin necesidad de elementosespeciales adicionales.

• La plataforma de desarrollo que se utilice deberá permitir tecnologías estándar,Java (servlets y/o JSP), XML.

• El aplicativo debe incluir un proceso automático de instalación y control deversiones que permita la instalación y actualización de manera local o remota sinintervención de los usuarios.





Página 10 de 36

• Se evitará el uso de componentes de software que requieran el pago de licencias“runtime”. De necesitarse alguna herramienta adicional, siempre compatible con elentorno descrito, se indicará su importe unitario, función, así como las condicionesde mantenimiento y distribución

7.4. Estructura de contenidos

El contenido de las aplicaciones debe ubicarse en las cabinas de almacenamiento,mientras que los datos que almacena y gestiona la aplicación han de almacenarse enbases de datos.

7.5. Uso de páginas de error corporativas

En la actualidad, el Gobierno de Canarias especifica siete páginas de error normalizadaspara que estas se muestren cuando se produzca alguna casuística de error dentro de lasdiferentes aplicaciones. Estas páginas son las que se enumeran a continuación:

− Error 400. Petición no válida https://www.gobiernodecanarias.org/errors/errorctrl400.html

− Error 401. Se requiere autorización:https://www.gobiernodecanarias.org/errors/errorctrl401.html

− Error 403. Acceso prohibido:https://www.gobiernodecanarias.org/errors/errorctrl403.html

− Error 404. Documento No Encontrado:https://www.gobiernodecanarias.org/errors/errorctrl404.html

− Error 500. Página no disponible: https://www.gobiernodecanarias.org/errors/errorctrl500.html

− Error 502. Petición Errónea: https://www.gobiernodecanarias.org/errors/errorctrl502.html

− Error 503. Servicio del Servidor no Disponible: https://www.gobiernodecanarias.org/errors/errorctrl503.html

Las aplicaciones publicadas deben hacer uso de las páginas de error indicadas. A tal fin:

• Estas páginas de error se han definido por defecto en los servidores APACHE e IIScorporativos del Gobierno de Canarias, y los desarrollos habrán de tener especialcuidado en no definir páginas de error particulares para los códigos de error que semuestran en el listado.

• Para las aplicaciones alojadas en servidores corporativos Tomcat y JBoss cadauno de los desarrollos deberá incluir dichas páginas de error personalizadas.



https://www.gobiernodecanarias.org/errors/errorctrl503.html










Página 11 de 36

7.6. Nomenclatura de las URL(s) de acceso

Las url(s) de acceso a las aplicaciones se componen del dominio seleccionado al que seha de añadir el departamento/unidad administrativa y el identificador (nombre deaplicación) elegido. Es decir, una aplicación 'aaa' del departamento 'bbb' publicada en eldominio 'gobiernodecanarias.net', tendría la siguiente url:

'www.gobiernodecanarias.net/ bbb / aaa '.

De manera análoga, cualquier “servicio web / interface” que se ofrezca desde losdominios corporativos han de seguir las mismas pautas para construir la url desde la queserán servidos. De este modo, si se desea ofrecer un WebService de nombre 'aaa_ws',éste debe ubicarse tras el departamento/unidad administrativa en el que se inscriba elservicio; p.e.:

'www.gobiernodecanarias.net/ bbb / aaa _ ws '.

Para el caso de ofrecer una API, esta debe ubicarse tras el departamento/unidadadministrativa en el que se inscriba; p.e.:

'www.gobiernodecanarias.net/bbb/api' o en su caso, según proceda

'www.gobiernodecanarias.net/bbb/aaa/api'.

A continuación se muestra un ejemplo, en el que un usuario llamado user01, tiene bajo suresponsabilidad la siguiente aplicación “app01”:

http://www.gobiernodecanarias.org/ bbb / app01/

7.7. Recomendaciones de diseño web e imagen corporativa

Los contenidos web alojados en los servidores del Gobierno de Canarias deben seguirunas pautas de diseño.

El diseño y características de los signos de identificación de la identidad corporativagráfica del Gobierno de Canarias se especifican en el Manual de Identidad Corporativa,disponible en:

http://www.gobiernodecanarias.org/cpj/dgmcs/temas/imagen/identidad.html

7.8. Documentación

La documentación deberá ser completa, generándose toda la documentación necesariapara realizar el seguimiento del proyecto y garantizar su calidad. El material adjunto a laaplicación incluirá los manuales necesarios para los distintos tipos de usuarios presentes



http://www.gobiernodecanarias.org/cpj/dgmcs/temas/imagen/identidad.html

http://www.gobiernodecanarias.org/app01/




http://www.gobiernodecanarias.net/bbb/api

http://www.gobiernodecanarias.net/bbb/api

http://www.gobiernodecanarias.net/BBB/AAA_WS






http://www.gobiernodecanarias.net/BBB/AAA






Página 12 de 36

en el sistema, y permitirá el completo entendimiento de la misma, y en caso necesario lacontinuación y mantenimiento de la aplicación.

Se consultará el procedimiento de Gestión de la Entrega para el alta de las aplicacionesen los sistemas corporativos.

La aplicación deberá ofrecer ayuda en línea sensible al contexto para el usuario

7.9. Seguridad

En este apartado se establecen requisitos adicionales a los establecidos en la Normativasobre los requisitos de Seguridad en Aplicaciones Web.

7.9.1. Cumplimiento normativo

Las aplicaciones deberán cumplir los requisitos del ENS y el RGPD, debiendo prestarseespecial atención a los mecanismos de identificación y autenticación, los mecanismos deprotección de la información tratada y la generación y tratamiento de logs como parteintegral del diseño.

Adicionalmente a los requisitos legalmente establecidos, en la “Normativa de uso deBBDD” se establecen requisitos específicos para las aplicaciones que deseen hacer usode las BBDD corporativas, y en la “Normativa sobre requisitos de Seguridad deaplicaciones web” se establecen requisitos específicos a tener en cuenta durante eldesarrollo y despliegue de las aplicaciones web que hagan uso de recursos corporativos.

7.9.2. Medidas obligatorias

Desde el punto de vista de la seguridad, la publicación de aplicaciones y servicios web hade cumplir una serie de obligaciones:

• Los contenidos han de estar separados en directorios dependiendo de laplataforma que sirva a cada uno de ellos.

• Los contenidos habrán de estar en un sistema de ficheros externo a la máquinaque presta el servicio, y accesibles sólo en modo lectura.

• Cualquier publicación de una página web de Gobierno deberá estar referenciada alprimer nivel (www), independientemente de que sea servida por un nivelsecundario. De esta forma, se evitarán problemas derivados de cambios de nivelpor necesidades del servicio.

• En el caso de que se solicite una redirección de una URL a máquinas de la redinterna que no están alojadas en la infraestructura corporativa y la solicitud seaaprobada, dicha redirección será aplicada en una línea de frontales secundaria





Página 13 de 36

(www2, www3,…) mediante la directiva de ProxyPass inverso. La gestión deCiberCentro consistirá en establecer una pasarela hasta una IP de destino ycualquier necesidad adicional relacionada con reglas de Apache, como la gestiónde balanceos, habrá de aplicarse en el servidor de destino. De igual forma, lasaplicaciones desarrolladas en versiones de PHP anteriores a la actual sonredirigidas a una línea secundaria, por incompatibilidad con la primera línea (PHP).En cualquier caso, el primer nivel se encargará de realizar unaRedirección/Redirect (Código http 304) hacia el nivel final, de forma que el serviciosiempre responda al ciudadano desde el primer nivel (www).

• Si la aplicación necesitara enviar correos es necesario que lo haga de formaautenticada, ya que los frontales de correo corporativo sólo aceptan SMTPautenticado.

• Toda aplicación debe pasar un proceso de certificación como requisito previo parael paso a Explotación. Para más detalle, consultar la Normativa sobre requisitos deseguridad de aplicaciones web y el Proceso para certificar la seguridad de lasaplicaciones Web.

7.9.3. Autenticación con Certificado Digital

Las aplicaciones que deban hacer uso de validación con certificado habrán de hacerlomediante JSP bajo plataforma Linux, usando los frontales web corporativos del Gobiernode Canarias como pasarela de entrada.

La información personal de los certificados digitales de los usuarios será obtenida por losfrontales web corporativos y ofrecidos a las aplicaciones ubicadas tras los mismosmediante las APIs estándar de JAVA, para su correspondiente gestión en estos últimos.

7.9.4. Trazas – Logs

Dado que los servidores de aplicaciones están configurados al mínimo nivel en laescritura de trazas, se otorga la posibilidad de solicitar una carpeta con permisos deescritura, visible desde el conjunto de servidores, para poder configurar la utilidad log4jcon el nivel de traza necesario a los requerimientos de la aplicación.

Se dispondría de una ruta física del tipo /data/gobiernodecanarias.org/aplicacion01 que severía desde los servidores de aplicaciones que alojan la aplicación y sería accesiblemediante el usuario FTP, designado a tal efecto. Además, y para evitar la escritura sobreel mismo fichero desde más de un servidor de aplicaciones, se configurará una variableservidor -Dservidor="${HOSTNAME}.${LOGNAME}" en donde se guardará el nombre delhost y del servidor de aplicaciones.

A modo de ejemplo, la traza podría obtener un nombre de estas características:host.servidor.aplicacion.log.2015-05-15.





Página 14 de 36

Nota: Es importante destacar la volatilidad de este alojamiento destinado al logado deaplicaciones, ya que por tareas de mantenimiento del servicio se pueden llevar a cabotareas de borrado de todos los ficheros de una antigüedad mayor de un año, o bien queen su conjunto acumulen un volumen mayor que 1 Gb de capacidad.

El directorio DATA no se puede usar como repositorio de configuraciones ocódigo dinámico que afecte al funcionamiento de la aplicación porque podría

perderse sin garantías de recuperación

Los administradores de las aplicaciones podrán solicitar una carpeta con permisos deescritura, visible a través del FTP, donde podrán incluir los logs de su aplicación, ya quelos servidores de aplicaciones están configurados al mínimo nivel de trazas (véaseapartado 6.2 –Carpeta especial DATA–).

Los servidores de aplicación están configurados con el mínimo nivel de detalle de log, porlo que se hace recomendable el correcto uso del espacio dedicado a cada aplicación parael almacenado de este tipo de información.

Los responsables de cada aplicación habrán de velar porque no se vuelquen logs, enespecial con información sensible, en las ubicaciones propias de los servidores deaplicaciones, sino en las ubicaciones establecidas a tal efecto para cada una de ellas. Encaso de detectarse esta práctica de manera incontrolada, se podría proceder a ladeshabilitación de la aplicación por motivos de seguridad.

7.10. Recomendaciones generales

• Separar la capa de presentación del código• Separar la lógica de Negocio, del acceso a datos, etc.• Preferencia por la programación orientada a objetos• Utilizar algoritmos eficientes y realizar pruebas de rendimiento• Utilizar patrones de diseño• Tener en cuenta portabilidad, reusabilidad, modularidad• Evitar duplicación de código; utilizar funciones• Normalizar código fuente

•





Página 15 de 36

8. SERVICIOS OFRECIDOS

8.1. Entornos disponibles

La infraestructura del Gobierno de Canarias proporciona un entorno de Pre-explotación yun entorno de Explotación, presentando ambos las mismas versiones, para su uso porparte de los desarrolladores conforme a lo descrito anteriormente

8.2. Alojamiento de aplicaciones

Se pone a disposición de las aplicaciones que lo deseen, la infraestructura web descrita,para lo cual deben cumplir los requisitos descritos en las Normas y recomendacionesestablecidas por la DGTNT.

El Gobierno de Canarias provee tres portales principales que actúan como raíz de ciertoscontenidos o proyectos bien definidos:

1. http s ://www.gobiernodecanarias.org : portal para las aplicaciones y contenidos delGobierno de Canarias y de cada una de sus Consejerías y Organismos.

2. http s ://www.gobiernodecanarias.net : portal para las aplicaciones y contenidosinternos del Gobierno de Canarias y de cada una de sus Consejerías yOrganismos. Los contenidos en este portal son accesibles de forma interna, nosiendo posible su acceso desde Internet.

3. https://sede.gobcan.es: portal para todas las aplicaciones de Sede electrónica delGobierno de Canarias y de sus Consejerías y Organismos

En este apartado se describen los procedimientos relativos al alojamiento de aplicacionesen infraestructura web CiberGestionada. No obstante existen otras opciones dealojamiento web, cuyas características y requisitos se describen en la Normativa deGestión de Alojamiento de Aplicaciones.

8.2.1. Solicitud de publicación de una aplicación

Cuando un usuario desee publicar una nueva aplicación en la plataforma del Gobierno deCanarias deberá, en primer lugar, solicitar un alta en el entorno de Pre-explotación. ElResponsable de Gobierno de la aplicación será el responsable de realizar las pruebas queconsidere necesarias para determinar que la aplicación ha alcanzado una versión estable.Durante la fase de pruebas, cuando se requiera alguna actuación sobre las máquinas(reinicio de los servidores de aplicaciones, problemas de conexión a BBDD, etc.), losinteresados deberán ponerse en contacto con CiberCentro, a través de SIRVETE, paracrear una incidencia relacionada con la petición.



https://www.gobiernodecanarias.net/cibercentro/sirvete/

https://sede.gobcan.es/



http://www.gobiernodecanarias.net/



https://www.gobiernodecanarias.org/





Página 16 de 36

NOTA: Tanto la solicitud de alta en el entorno de Pre-explotación, se hace comoincidencias y el entorno de pro como la solicitud de cambio para el paso a Explotación dela aplicación deberán ser realizadas como se indica en el procedimiento de Cambios.

A continuación se explica este proceso en detalle:

2. Ilustración 2. Flujo de puesta en Explotación





Página 17 de 36

8.2.1.1. Alta en el entorno de Pre-Explotación

Para solicitar el alta de una nueva aplicación en la infraestructura del Gobierno deCanarias se hará a través del formulario Alta de Aplicación. Durante el proceso de alta dela aplicación, el usuario habrá de especificar la URL deseada, conforme a los requisitosdescritos en el apartado 7.6 .

Con esta información, y una vez que la URL sea autorizada, CiberCentro creará elentorno de la aplicación, así como los usuarios de FTP en ftp.gobiernodecanarias.org, conlos que los administradores de la aplicación podrán cargar los contenidos en losdirectorios correspondientes, y visualizar el resultado en las url’s de Pre-explotación(véase el apartado 8.2.2 –Publicación de contenidos-).

Una vez creado el entorno de Pre-explotación, los contenidos serán visibles con URLs deltipo https://www-pre seguida del domino correspondiente.

8.2.1.2. Alta en el entorno de Explotación

Toda aplicación, para su paso a Explotación, debe cumplir con los requisitos de Gestiónde la Entrega, entre los que se encuentran:

• Documentos necesarios para el mantenimiento de la aplicación (manuales deprueba, instalación, marcha atrás, etc.) (para más detalle ver la Plantilla de Gestiónde la Entrega).

• Certificación de seguridad (para más detalle ver la “Normativa sobre los requisitosde seguridad en aplicaciones web” y el “Proceso de certificación de seguridad deaplicaciones web”).

• Registro previo de tratamiento de datos personales cuando aplique (que debehaberse informado a la DGTNT en la solicitud de alta de aplicación).

Una vez se cumpla con todos los requisitos se podrá proceder a solicitar el paso aExplotación de la aplicación mediante un Cambio a través del Comité de Cambios.

8.2.2. Publicación de contenidos

La provisión de contenidos se realizará a través del protocolo FTP, contra el servicioftp.gobiernodecanarias.org, haciendo uso el administrador de la aplicación de suidentificador personal corporativo (UID) y su contraseña asociada.

En el caso del entorno de Explotación, el administrador sólo podrá modificar contenidosen Explotación una vez que haya solicitado un cambio al Comité de Cambios y éste seapruebe. En ese caso, se le asignará un periodo temporal para cargar las modificacionespertinentes. Si se detectan problemas en el aplicativo tras hacer efectivos los cambios, sevolverá a la configuración previa.



ftp://ftp.gobiernodecanarias.org/

ftp://ftp.gobiernodecanarias.org/

http://www.gobiernodecanarias.net/cibercentro/sirvete/peticion/crearPeticion.xhtml?id_peticion=29



Página 18 de 36

Para el caso de Portales desplegados sobre la plataforma OpenCMS, existen carpetascon contenido estático habilitadas cuya apertura está preautorizada y podrá hacerse usode las mismas en horario de 7:00 a 19:00.

A partir de la versión 6 de JBoss, la subida de contenidos .war o .ear se actualizará en losservidores con una cierta frecuencia. Es decir, si se sube un nuevo fichero .war o .ear víaFTP, éste se actualizará en un período máximo de 30 minutos en Pre-explotación,realizándose automáticamente un nuevo despliegue de la aplicación. Para el caso deExplotación, la subida de contenidos debe ser autorizada por el Comité de Cambios. Unavez autorizado y en la fecha acordada, se forzaría el nuevo despliegue de la aplicaciónpor parte de CiberCentro una vez subido el nuevo fichero.

Cada administrador de una aplicación, al entrar en su cuenta de administración de dichoespacio, se encontrará con una estructura de directorios de acuerdo a los datos facilitadosa los administradores del sistema (CiberCentro) en cuanto al tipo de aplicación que va adesarrollar. Así, en un primer nivel, se encuentran los directorios de los distintos entornosque se hayan habilitado para las aplicaciones que administra el usuario (pre, exp).

Una vez dentro de cualquiera de esos directorios, existirá una serie de carpetas con elformato tipo_contenido.dominio.nombre_aplicacion, donde:

tipo_contenido: identifica a cada uno de los distintos tipos de contenidos quepuedan tener las aplicaciones: https (contenidos seguros), https-cgi (contenidos cgien seguro), ajp13 (java sobre Tomcat), JBoss (java sobre JBoss), data (carpeta deescritura para recepción de logs), moodle (contenidos plataforma Moodle),…

dominio: dominio al que pertenece la aplicación en particular(www.gobiernodecanarias.net, www.gobiernodecanarias.org,...).

nombre_aplicacion: nombre de la aplicación sobre la que se tienen permisos deadministración.

Este modelo permite organizar los contenidos de cada una de las aplicaciones de cadausuario, y permite al usuario tener control sobre los mismos, de forma aislada a lainfraestructura de servidores.



http://www.gobiernodecanarias.org/



Página 19 de 36

A continuación se muestra un ejemplo de cómo queda el árbol de directorios en el ftp:

Ilustración3:Árbol de directorio FTP

Por ejemplo, el caso de un administrador que sólo es responsable de una aplicación conuna URL dada. Dicho usuario, al entrar en su cuenta de administración, se encontrará conuna distribución de directorios similar a esta:





Página 20 de 36

Considérese que la web del que este usuario es responsable está bajo el url:http s ://www.gobiernodecanarias.org/ bbb/ aplicacion01/

Con esta estructura, todo lo que el administrador ponga debajo del directorio/pre/https.gobiernodecanarias.org.aplicacion01/, corresponderá a los contenidos estáticosde la raíz de su web en la Pre-explotación.

Actualmente las Pre-explotaciones para la URL http s ://www.gobiernodecanarias.or g/bbb se realizan en http s ://www-pre.gobiernodecanarias.org/ bbb .

De la misma forma, todo lo que el usuario ponga bajo el directorio/exp/https.gobiernodecanarias.org.aplicacion01/ aparecerá reflejado de forma automáticaen la infraestructura de Explotación creada a tal efecto en el urlhttp s ://www.gobiernodecanarias.org/ bbb/ aplicacion01/ .

Siguiendo con el mismo ejemplo, si la aplicación incluye contenidos java, dependiendo desi estos contenidos están montados sobre un Tomcat o un JBoss, el directorio en el que eladministrador de la aplicación debe incluirlos (para el entorno de Pre-explotación) será/pre/ajp13.gobiernodecanarias.org.aplicacion01/ o/pre/jboss.gobiernodecanarias.org.aplicacion01/, respectivamente. En el caso del entornode Explotación, sólo hay que sustituir el directorio de pre por el de exp.

8.2.3. Baja de aplicaciones y/o recursos

El Responsable de Gobierno de la aplicación informara a CiberCentro de la no utilizaciónde la aplicación una vez deje de dar servicio y proceder a presentar la baja de la misma yde aquellos recursos que procedan.

CiberCentro se reserva el derecho de auditar las configuraciones de los servidores deaplicaciones y redirecciones. En caso de encontrar aplicaciones que no estén en uso, oredirecciones a páginas sin contenidos, solicitará al responsable de dicha aplicación suconfirmación y será eliminada en caso contrario.

8.3. Alta disponibilidad

Con el fin de poder cumplir los niveles deseados de disponibilidad de los servicios en elentorno de Explotación, se requiere el uso de una arquitectura en alta disponibilidad, esdecir, a prueba de caídas de los sistemas que prestan el servicio. El entorno de Pre-explotación es un entorno de integración y pruebas y no se puede asegurar una altadisponibilidad del mismo.

Para lograr la alta disponibilidad, se dota a la infraestructura de sistemas de balanceo decarga, con las siguientes repercusiones:



http://www.gobiernodecanarias.org/aplicacion01/





http://www-pre.gobiernodecanarias.org/



http://www.gobiernodecanarias.or/bbb











Página 21 de 36

• Reparten la carga entre varios servidores de configuración cuasi-simétrica.

• Las aplicaciones y contenidos deberán ser totalmente transparentes al nombre dehost del dominio, de manera que sean totalmente operativas independientementedel dominio en que sean alojados. De esta manera no dependerán del mencionadonombre host/dominio para poder implementar mecanismos de calidad de servicioen la plataforma.

• En el caso de que uno de los sistemas que presta el servicio caiga, el usuario finalno percibe caída de servicio, puesto que el resto de los sistemas asumen la cargade los usuarios que estaban siendo atendidos por el sistema que ha caído.

• Permiten una política de gestión de cambios efectiva: ante una actualizaciónsoftware de un determinado sistema, se le retira del grupo de balanceo, se leactualiza y, una vez probado, se le integra en el grupo de balanceo, pero con lasnuevas versiones de software activadas, sin caída de servicio de cara al usuariofinal.

Nota: En consecuencia, aquellos sistemas que utilizasen recursos comocontadores basados en la modificación de ficheros locales (y no en bases dedatos) no serían balanceables debido a que el resultado que daría cada servidordel balanceo no sería consistente con el que darían los otros. Es por ello por lo queprácticas como la escritura en los sistemas de ficheros locales no sonrecomendables y han de abandonarse, ya que impiden el escalado horizontal delas aplicaciones.

• El impacto provocado por el cambio a nivel de usuario final será mínimo en tiempo,colaborando en el mantenimiento de un máximo nivel de servicio

Para lograr la alta disponibilidad se ofrecen dos tipos de balanceo:

8.3.1. Balanceo Software

La infraestructura corporativa basada en Tomcat y JBoss, por defecto, dispone de unbalanceo software basado en el módulo mod_jk en configuración “JK_TRUE”), lo quepermite la distribución del tráfico en caso de fallos, instalado en cada uno de los frontalesweb o del módulo mod_proxy_balancer propio de Apache. Por tanto, están disponibles las siguientes opciones de balanceo:

− Distribución del tráfico por carga en servidores (persistencia por IP origen).− Distribución del tráfico por carga en servidores con función tipo “proxy”

(persistencia por IP origen).

8.3.2. Balanceo Hardware





Página 22 de 36

El balanceo hardware está disponible para la infraestructura de IIS y cualquier otroservicio o aplicación que lo requiera. Si se requiriese de una configuración de balanceohardware para un servicio ubicado en la infraestructura corporativa de Tomcat o JBoss,este debe ser revisado previamente.

Los balanceadores hardware ofrecen un abanico de configuraciones que permiten adaptarla gestión del tráfico y persistencias a las necesidades de cada servicio. Para detalle delos servicios de balanceo disponibles se recomienda ver la documentación de laNormativa de Servicios Balanceados.

8.4. Copias de seguridad

El Servicio de Copias de Seguridad y Restauración del Gobierno de Canarias ofrece unrespaldo y recuperación en caso necesario, de los datos que almacenan las aplicacionesalojadas en las instalaciones del Gobierno de Canarias. La ”Normativa de copias deseguridad y restauración” soporta dicho servicio y garantiza su ejecución en lascondiciones previstas.

Cada elemento que conforma una aplicación tiene su propia política de copias, de cara aeste documento se describen los comunes a todas las aplicaciones.

Los sistemas de copia de seguridad de las cabinas de almacenamiento y de los sistemasde gestión de bases de datos son totalmente independientes el uno del otro, con lo quelas tareas de backup de cada uno de ellos se realizan en diferentes periodos de tiempo. Elhecho de que las aplicaciones almacenen datos únicamente en la BBDD asegura la totaldisponibilidad de la aplicación ante la necesidad de recuperar una copia de la misma, yaque se evitan posibles incoherencias entre los datos almacenados en las cabinas yBBDD.

8.4.1. Servidores de Aplicaciones

La infraestructura para aplicaciones está diseñada de forma que los contenidos seencuentran en cabinas de almacenamiento (NAS), evitando así el uso de directorioslocales en los servidores. Las cabinas de almacenamiento disponen de una configuraciónde copias por defecto. En caso de requerir una configuración de copias distinta, esta sedebe solicitar.

Por otro lado, los servidores de aplicaciones de versiones soportadas están respaldadospor copias de seguridad de los contenidos del middleware necesario para la ejecución delas aplicaciones.

La siguiente tabla muestra las frecuencias de las copias que dispone cualquier aplicaciónque se integra en la infraestructura:





Página 23 de 36

Copia Frecuencia Comentarios

Contenidos de aplicaciones en cabinasde almacenamiento

Diariamente

Capacidad de recuperación últimos 20 días. Ver documento “CIBERC-NGE-000810 Normas de uso del servicio de ficheros en red” para más detalle.

Contenido del Middleware propio de cada servidor de aplicaciones

Diariamente

Tabla 1. Frecuencia de copias de respaldo

8.4.2. Bases de Datos

Las Bases de Datos se encuentran en una infraestructura que, por defecto, incorpora suspropias políticas de copias de seguridad. Se harán agendas con políticas independientespara el sistema operativo, las copias físicas y las copias lógicas de la BBDD:

• Copia Tipo 1.- Sistemas Operativos:◦ Un ciclo de dos o tres copias totales, una copia por mes.

• Copia Tipo 2.- BBDD – Copia física de BBDD en Explotación:◦ Copia realizada sin cortar el servicio en caso de soportarlo el SGBD.◦ Se realizan copias incrementales diarias (incluyendo los archivos de

transacciones) durante una semana.

• Copia Tipo 3.- BBDD- Copia lógica de la BBDD en Explotación:◦ Se usan los ficheros de exports (dmp).◦ Se realiza una copia mensual.◦ Un ciclo de 60 copias totales (2 años), una copia de cada mes.

• Copia Tipo 4.- BBDD – Copia lógica de la BBDD de Desarrollo o Pre-explotaciónsin datos (solo estructuras):◦ Se usan los ficheros de exports (dmp) SIN datos.◦ Se realizan copias diarias (de estructura sin datos) durante 1 semana.

Las recuperaciones parciales de datos son susceptibles de estar sujetas a la normativavigente en materia de Protección de Datos Personales y deberán ser solicitadas por elresponsable de cada aplicación.

En cuanto a las aplicaciones que han sido catalogadas como críticas, existe un “plan decontinuidad” para restaurar los datos, con pérdida de información, en provincia contrariaen caso de desastre. Dicho plan sólo afecta a aplicaciones críticas. Sólo el sistema deBBDD corporativo está incluido dentro del “plan de continuidad”. Eventualmente, ymientras se disponga de capacidad, se seguirá manteniendo replicación de BBDD paralas aplicaciones críticas alojadas en los sistemas de BBDD soportadas. No se da soportede continuidad a las aplicaciones en sistemas de BBDD a extinguir.





Página 24 de 36

8.5. Integración de captura de errores de aplicación en SIRVETE

Desde CiberCentro se ha establecido un mecanismo para facilitar la interacción entre losusuarios de la aplicaciones y el soporte de las mismas, permitiendo de forma cómoda,transparente, fiable y rápida para el usuario trasladar toda la información técnicarelacionada con los errores mencionados en el apartado 7.5.

Dicho mecanismo consiste en la integración de la aplicación con SIRVETE, tal y como seencuentra procedimentado en el documento CIBERC-MGT-706700 Manual deintegración de captura de errores de aplicación en SIRVETE.

9. REFERENCIAS

9.1. Documentos externos a la organización

Documento Disposiciones normativas nacionales aplicables a las Administraciones Públicas

Ubicación https://www.boe.es/

Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad enel ámbito de la Administración Electrónica.

Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional deInteroperabilidad en el ámbito de la Administración Electrónica.

Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo de 27 de abril de 2016 relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/46/CE.

Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal.

Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollode la LOPD.

Documento Disposiciones normativas autonómicas aplicables a la Administración Pública de laComunidad Autónoma de Canarias

Ubicación http s ://www.gobiernodecanarias.org/boc/

Resolución de Presidencia del Gobierno de 25 de junio de 2018, por el que se dispone lapublicación del Acuerdo que aprueba las instrucciones que conforman la Normativa de seguridaden el uso de los recursos informáticos, telefónicos y de redes de comunicación de laAdministración Pública de la Comunidad Autónoma de Canarias.



http://www.gobiernodecanarias.org/boc/



https://www.boe.es/



Página 25 de 36

9.2. Documentos internos a la organización

Documento Normas y recomendaciones establecidas por la Dirección General deTelecomunicaciones y Nuevas Tecnologías (DGTNT) en los servicios ofrecidos porCiberCentro

Ubicación https://www.gobiernodecanarias.net/cibercentro/documentos/normativas/index.html

Normativa para el uso de BBDD corporativas en las infraestructuras de Sistemas del Gobierno deCanariasNormativa sobre utilización de herramientas corporativasNormativa sobre los requisitos de Seguridad en Aplicaciones WebNormativa de servicios balanceadosNormativa de copias de seguridad y restauración

Documento Procesos de ITIL

Ubicación https://www.gobiernodecanarias.net/cibercentro/documentos/procesos_itil/index.html

Procedimiento de Gestión de CambiosProcedimiento de Gestión de la EntregaGuía para la solicitud de aplicaciones en la infraestructura corporativa

Documento Proceso para certificar la seguridad de las aplicaciones Web

Descripción Proceso para certificar la seguridad de las aplicaciones Web

Ubicación https://www.gobiernodecanarias.net/cibercentro/documentos/seguridad/index.html

Documento FAQ para desarrolladores de aplicaciones alojadas en la infraestructura corporativade Gobierno de Canarias

Descripción Respuestas a las consultas más frecuentes

Ubicación https://www.gobiernodecanarias.net/cibercentro/documentos/soporte/index.html

Documento CIBERC-MGT-706700 Manual de integración de captura de errores de aplicación enSIRVETE

Descripción Manual de integración de capturas de errores




https://www.gobiernodecanarias.net/cibercentro/documentos/procesos_itil/index.html



Página 26 de 36

Documento Alta de Aplicación

Descripción Formulario de Alta de Aplicación

Ubicación https://www.gobiernodecanarias.net/cibercentro/sirvete/

Documento Plataforma Tomcat

Descripción Definir los requisitos y requerimientos de la plataforma


10.CONTACTOS

Persona de contacto CiberCentro

Acceso Web https://www.gobiernodecanarias.net/cibercentro/sirvete/

Correo electrónico [email protected]

Teléfono interno 912

Teléfonos 902 111 912 - 922 922 912 - 928 117 912



mailto:[email protected]





Página 27 de 36

1. ANEXO 1 DESCRIPCIÓN DE CONFIGURACIONES APACHE

En este anexo se describen brevemente las principales herramientas de las que se haceuso en los ficheros de configuración de Apache para dar servicio a las distintasaplicaciones que se alojan en los dominios del Gobierno de Canarias.

1. Módulos incluidos

Los módulos que se incluyen en el arranque de Apache 2.4 (primera línea de frontalesweb) son los siguientes:

access_compat_module core_module proxy_balancer_moduleactions_module dir_module proxy_connect_modulealias_module env_module proxy_express_moduleauth_basic_module headers_module proxy_fcgi_moduleauthn_core_module http_module proxy_ftp_moduleauthn_file_module jk_module proxy_http_moduleauthnz_ldap_module lbmethod_bybusyness_module proxy_moduleauthz_core_module lbmethod_byrequests_module proxy_scgi_moduleauthz_groupfile_module lbmethod_bytraffic_module rewrite_moduleauthz_host_module lbmethod_heartbeat_module setenvif_moduleauthz_user_module ldap_module slotmem_shm_moduleautoindex_module log_config_module so_modulecache_disk_module mime_module socache_shmcb_modulecache_module mpm_prefork_module ssl_modulecgi_module php5_module status_modulecharset_lite_module proxy_ajp_module unixd_module

Tabla 2. Módulos de Apache

2. Redirección a línea secundaria

Cuando una aplicación es redirigida a otra línea de frontales (www2, www3,…), se utilizauna redirección sencilla del tipo:RewriteRule ^/nombre_aplicacion/(.*)

http://wwwX.gobiernodecanarias.org/nombre_aplicacion/$1 [R]

3. Redirección a máquinas externas

En el caso de que la DGTNT apruebe que una aplicación sea redirigida a una máquina dela red del Gobierno de Canarias ajena a los servidores web corporativos, se estableceráuna conexión del tipo ProxyPass:ProxyPass /bbb/nombre_aplicacion/

http://ip:puerto/bbb/nombre_aplicacion/ProxyPassReverse /bbb/nombre_aplicacion/ http://ip:puerto/bbb/nombre_aplicacion/





Página 28 de 36

En este caso, para evitar problemas con los direccionamientos de la aplicación, esnecesario que la ruta en la que se encuentran los contenidos de la aplicación en lamáquina externa coincida con la parte de la URL que sigue al dominio correspondiente.

Esto es, si se quiere redireccionar,

http s ://www.gobiernodecanarias.org/presidencia/noticias/

a una máquina externa, los contenidos de la aplicación en esa máquina deben estar en laruta presidencia/noticias/, de forma que la redirección quedará de la forma:

ProxyPass /presidencia/noticias/http://ip:puerto/presidencia/noticias/

ProxyPassReverse /presidencia/noticias/http://ip:puerto/presidencia/noticias/

4. KeepAlive

Mediante la directiva KeepAlive y sus directivas asociadas se establecen los criterios conlos que se mantienen abiertas las conexiones tras una petición al servidor web. Esta es laconfiguración que se establece en los frontales web del Gobierno de Canarias:KeepAlive OnMaxKeepAliveRequests 500KeepAliveTimeout 2

5. Securización de Apache mediante HTTPS

Los contenidos HTTPS alojados en la infraestructura del Gobierno de Canarias songestionados por los frontales web, de manera que la comunicación segura se produceentre cliente (navegador) y frontal web, donde finaliza.

En caso de necesidad de mantener el canal seguro hasta un tercer servidor, desdeCiberCentro se establecerá un segundo túnel seguro entre el frontal web y dicho servidor,siguiendo el método de redirección establecido en el punto 3.

Como parte de la obligación de usar HTTPS (URLs del tipo "https://www…"), se habilitaráuna redirección desde NO-SSL (tipo "http://www... (https://www...)"), de manera que losusuarios que invoquen la URL sin especificar protocolo (http/https) sean dirigidos aldestino correcto.



http://www.gobiernodecanarias.org/presidencia/noticias/





Página 29 de 36

2. ANEXO 2 DESCRIPCIÓN DE CONFIGURACIÓN PHP

PHP (HyperText Preprocessor) es un lenguaje de scripting que permite la generacióndinámica de contenidos en un servidor web.

El código PHP puede incluirse dentro del código HTML de la página. Es posible delimitarla sección de código PHP de varias formas:

− Usando las etiquetas <?php y <? − Usando las etiquetas <? y ?>− Mediante <script languaje="php"> </script>

El funcionamiento de las páginas en PHP alojadas en un servidor es el siguiente: − El navegador del cliente solicita el documento PHP.− Llega la solicitud al servidor y éste localiza el documento, lanza el intérprete de

PHP y ejecuta todo su código.− Una vez ejecutado el código, se genera el resultado en HTML y el intérprete lo

devuelve al servidor.− El servidor transfiere el resultado en HTML al cliente y este lo muestra en el

navegador.

1. Directivas

A continuación se describen las modificaciones realizadas sobre la configuración pordefecto del motor PHP (php.ini) y la manera de compilarlo:

− Para evitar problemas con las variables que contienen comillas, como por ejemplo,que en un formulario de entrada de datos se encuentre un nombre como“D’Adamo”, y evitar problemas en las sentencia insert, se hace uso de “magicquotes” on (evitar SQL Inject o mal funcionamiento).Magic Quotes es un proceso que automáticamente coloca caracteres de escape enlos datos entrantes. Los valores por defecto son los siguientes:Para datos entrantes mediante métodos GET/POST/Cookie.magic_quotes_gpc = On (valor por defecto)Para datos generados en tiempo de proceso, ejemplo: datos de SQL, exec()magic_quotes_runtime = Off (valor por defecto)Cuando el parámetro se encuentra en ON, a las comillas simples, comillas dobles,backslash y caracteres null, se les agregará automáticamente el carácter deescape “\” Para ampliar la información se puede consultar: http://es2.php.net/magic_quotes.Otra posibilidad o buena práctica es utilizar la función addslashes()http://es2.php.net/manual/en/function.addslashes.php



http://es2.php.net/manual/en/function.addslashes.php

http://es2.php.net/magic_quotes



Página 30 de 36

− Se modifica el valor del parámetro “max_execution_time” a 3000 segundos (valorpor defecto, 512). Es el máximo tiempo de ejecución permitido por el “parser” acualquier script antes de ser terminado por el mismo. Esto evita ejecucionescostosas de código pobremente escrito.

max_execution_time = 3000

− Se modifica el valor del parámetro “max_input_time” a 240 segundos (valor pordefecto, 120). Este valor configura el máximo de tiempo que se le permite a unscript parsear datos con métodos como POST, GET ó file uploads.

max_input_time = 240

− Se utiliza la directiva --disable-memory-limit al momento de compilación, por lo queno se limita el uso de memoria.Aunque no se limita el uso de memoria, el valor del parámetro “memory_limit” se haconfigurado a 100M (valor por defecto, 8M), por si fuese necesario su activación.Este parámetro indica la máxima cantidad de memoria que se le permite alocar aun script PHP, debe ser recompilado utilizando la directiva --enable-memory-limit.

memory_limit = 100M

− En entornos de Explotación, los errores no son mostrados por pantalla (puedesolicitarse expresamente, para ser utilizado en entornos de Pre-Explotación)

display_errors = Off

− Deshabilitadas extensiones snmp http://es.php.net/manual/en/ref.snmp.php

;extension=snmp.so

− Directiva fuera del “default” (browser detection). Ubicación del fichero:

browscap = /usr/local/lib/php/extra/browscap.ini



http://es.php.net/manual/en/ref.snmp.php



Página 31 de 36

2. Módulos instalados

La relación de módulos instalados en PHP es la siguiente:

[PHP Modules]

bcmath ftp Mysql Posix sysvshmbz2 gd mysqlnd Reflection tokenizercalendar gettext oci8 Session wddxctype hash Openssl Shmop xmlcurl json Pcre SimpleXML xmlreaderdate ldap PDO soap xmlwriterdba libxml pdo_dblib Sockets zlibdom Mbstring pdo_mysql SPLereg Mcrypt PDO_OCI SQLite3exif Mhash pdo_sqlite standardfilter Mssql Phar sysvsem

Tabla 3. Módulo de PHP

[Zend Modules]eAccelerator





Página 32 de 36

3. ANEXO 3 DESCRIPCIÓN DE CONFIGURACIÓN TOMCAT

1. Librerías por defecto en Tomcat

Para asegurar la mayor estabilidad posible, y una gestión eficiente de los recursos, laplataforma corporativa de Tomcat presenta una serie de librerías para todas lasaplicaciones. Estas librerías son las que vienen por defecto en el producto. Cualquier otralibrería que pueda necesitar una aplicación debería ir alojada en los contenidos de lapropia aplicación.

Podrá consulta el documento Plataforma Tomcat.

2. Configuración JSP/MOD_JK

En una aplicación JSP+Java existe lo que se conoce como el “contexto” de la aplicación.A modo de ejemplo se muestra a continuación un segmento de un fichero XML deconfiguración en el que se declaran dos aplicaciones en un servidor Tomcat:

<Host name="www.gobiernodecanarias.org"><Context path="/videtec"

docBase="/array01/gobiernodecanarias.org/tomcat/videtec"debug="0"reloadable="false"crossContext="false"trusted="false" >

</Context> <Context path="/urban" docBase="/array01/gobiernodecanarias.org/tomcat/urban" debug="0" reloadable="false" crossContext="false" trusted="false" > </Context></host>





Página 33 de 36

En el ejemplo anterior se observa claramente que lo que hace es establecer unacorrespondencia entre lo que se denomina el “contexto” de la aplicación (/videtec) y undirectorio base del sistema de ficheros donde realmente se encuentra dicha aplicación(/array01/gobiernodecanarias.org/tomcat/videtec).

Lo realmente importante es que esos directorios nunca se exportan a los servidores web,y que dichos servidores, mediante un conector, se encargan de solicitar a los servidoresde aplicaciones todo aquello que sean ficheros *.jsp y clases java contenidas dentro delcontexto, en el directorio /servlet (que es un directorio que en realidad no existe).

Cuando los usuarios desarrollan una aplicación java (por ejemplo, app01), el árbol dedirectorios resultante de dicho desarrollo es algo similar a:

Ilustración4: Árbol de directorios

En este ejemplo hay contenidos que son más propios de un servidor web que de unservidor de aplicaciones como, por ejemplo, el directorio images, los ficheros *.html, losficheros *.swf, etc.

De hecho, los únicos contenidos que son importantes para los servidores de aplicacionesJava son los ficheros *.jsp, y el directorio WEB-INF con todo lo que contiene (losdirectorios de librerías y clases).

Por consiguiente, los contenidos estáticos deberían ser servidos por el servidor web, y loscontenidos Java deberían ser ejecutados y servidos por los servidores de aplicaciones.

La infraestructura está configurada al efecto de descomponer este árbol de directorios endos árboles distintos:

− El árbol de contenidos web.− El árbol de contenidos JSP + Servlet.





Página 34 de 36

El resultado quedaría representado por el siguiente gráfico:

App01 WEB-INF classes

lib

index.html

index.jsp

intro.swf

images Imagen01.jpg

Imagen02.jpg

App01

index.html

intro.swf

images Imagen01.jpgImagen02.jpg

App01 WEB-INF classes

lib

index.jsp

+=

Contenidosweb

ContenidosJava

Ilustración5: Árbol de contenidos web

Donde se puede apreciar que el aplicativo original es descompuesto en sus doscomponentes:

− Los contenidos web propiamente dichos, o contenido estático.− Los contenidos java, o dinámicos.

Con este tipo de descomposición se consigue optimizar el funcionamiento del sistema almáximo, pues es el servidor Apache el que sirve las páginas HTML, y el servidor deaplicaciones el que sirve los contenidos Java.

El resultado es que si este usuario tuviese varias aplicaciones y esta fuera la aplicaciónapp01, en su directorio http aparecería un directorio app01 que contendría la parte webde la aplicación, y en sus directorios Tomcat (Pre-explotación y Explotación) apareceríanlos directorios app01 de la parte java de dicha aplicación.





Página 35 de 36

4. ANEXO 4 DESCRIPCIÓN DE CONEXIONES A BASES DE DATOS

Debido a la necesidad de administración de la plataforma y a la conveniencia deindependizar la gestión global de la misma y la gestión particular de cada aplicación, lasaplicaciones sólo podrán usar JDBC para definir las conexiones a las distintas BBDD,quedando descartada la definición de la conexión mediante JNDI (resource en elcontext.xml de la aplicación).

Las configuraciones de acceso a las bases de datos deben estar perfectamenteidentificadas y documentado el proceso para su posible modificación cuando se requiera(migraciones de Instancias, cambios de credenciales, etc.).

En las cadenas de configuración no se usarán IP’s y sólo debe detallarse el nombre delservicio o instancia suministrado por el Departamento de BBDD.





Página 36 de 36

5. ANEXO 5 DESCRIPCIÓN DE CONFIGURACIONES DE LOS SERVIDORES IIS

Dentro del árbol de contenidos web para ser tratados por IIS no se distinguen directoriosespecíficos para los contenidos estáticos y dinámicos, dejando en todo caso a criterio delcreador de contenidos la ubicación diferenciada de páginas con contenido estático(HTML) o dinámico (ASP, ASP.NET), teniendo en cuenta que ambos contenidos van a serprocesados por los mismos frontales.

Una práctica a erradicar es la del uso de las extensiones del Frontpage que se suelenemplear para crear contadores de visitas o para motores de búsqueda. El Gobierno deCanarias no soporta el uso de estas técnicas ya que violan las normativas de seguridaden cuanto a escritura en disco local y rompen el equilibrio que debe haber entre losservidores balanceados (el caso de los contadores).

Se recomienda emplear otros métodos de programación para este tipo de utilidades,como puede ser usar una base de datos de contadores o mediante una API que elGobierno de Canarias pone a disposición de los usuarios. En cuanto a los motores debúsqueda, se debe consultar con el responsable de Gobierno de Canarias de la aplicación(también por las APIs existentes para aplicaciones externas) sobre la posibilidad deutilizar el motor general del Gobierno.

En los servidores IIS se recomienda que las conexiones desde un aplicativo web a lasbases de datos se realicen desde el propio aplicativo, codificando todas las funcionesnecesarias en el fichero global.asa, para el caso de ASP, o en el fichero web.config, en elcaso de ASP.NET, de tal forma que no dependan de definiciones de bases de datosexistentes en forma de DSN’s (Data Source Names) de sistema en dichos entornosWindows.

Este documento ha sido firmado electrónicamente por:

MANUEL ANGEL CASTELLANO TRUJILLO - DIRECTOR GNRAL.TELECOMUNICACIONES Y N.T.JOSE DAMIAN FERRER QUINTANA - JEFE AREA TELECOMUNICAC.Y SISTEMASHERLINDA HERNANDEZ PERERA - JEFE DE PROYECTO

Fecha: 07/09/2018 - 14:55:40Fecha: 06/09/2018 - 12:32:24Fecha: 06/09/2018 - 12:25:51



El presente documento ha sido descargado el 10/09/2018 - 08:10:19


normativa de las infraestructuras corporativas para las ... · las peticiones .jsp a los servidores...

Documents