IGI GSC/APL 16 Servicio de Aplicaciones Wordpress

(1)

IGI‐GSC/APL‐16 Servicio de Aplicaciones Wordpress

Sistema de gestión de calidad y ambiental Guía General Gerencia Sistemas y Comunicaciones

24/02/2017

REVISADO: APROBADO:

FECHA: Febrero, 2017 FECHA: Febrero, 2017

Borrador

Paseo de la Habana, 138 28036 Madrid. España

(2)

“El contenido de este documento es propiedad de Ineco no pudiendo ser reproducido total o parcialmente sin la autorización expresa del propietario. Las copias no registradas y asignadas no se mantienen actualizadas a sus destinatarios”.

(3)

Índice

1 OBJETO ...5

2 ALCANCE ...5

3 REFERENCIAS ...5

4 ESPECIFICACIONES TÉCNICAS ... 6

4.1 DATOS TÉCNICOS ... 6

4.1.1 ENTORNO ... 6

4.2 BUENAS PRÁCTICAS ... 6

4.3 10BELEMENTOS DE CONFIGURACIÓN ... 7

4.3.1 ARCHIVO DE CONFIGURACION ... 7

4.3.2 DIRECTORIO RAÍZ ... 7

4.4 13BSERVICIO DE MAIL ... 7

4.5 SEGURIDAD ... 8

5 SOLICITUD DE NUEVA APLICACIÓN ... 8

6 5BDESPLIEGUE Y ACTUALIZACIONES ... 9

6.1 17BServidor de Aplicaciones ... 9

6.2 18Bbase de datos ... 11

6.3 19Bciclo de vida ... 11

6.4 HORARIOS ... 11

7 6BMONITORIZACIÓN ... 11

8 ANEJOS ... 12

8.1 Anejo 1: Reseña de modificaciones de la guia ... 13

8.2 Anejo 3: Horarios de soporte ... 13

8.3 Anejo 4: Requisitos de seguridad ... 14

8.3.1 Implementación de la comunicación por https ... 14

(4)

(5)

1 OBJETO

El objeto del presente documento es el de definir toda la infraestructura que rodea al servicio de aplicaciones Wordpress ofrecido por Ineco, así como los diferentes procedimientos asociados a éste.

2 ALCANCE

Este documento sólo es aplicable en aplicaciones Web desarrolladas bajo Wordpress que tienen como fin ser desplegadas en un servidor de aplicaciones Wordpress corporativo. Se contempla la posibilidad de acceder a bases de datos MySQL. Se ha de tener en cuenta que aquellas aplicaciones que hagan uso de plugins o temas no estándar, deberán ser estudiadas por el Área de Sistemas y Comunicaciones de la Subdirección de Desarrollo y Sistemas Corporativos y que pertenece a la Dirección de Servicios Corporativos dentro de la Dirección General Corporativa, para evitar posibles incompatibilidades o errores inesperados.

3 REFERENCIAS

 ITIL v.3.

 Catálogo de Servicios de la Gerencia de Área de Sistemas y Comunicaciones.

 Guías y Manuales de Sistemas

 Guía de Desarrollo Web Seguro

(6)

4 ESPECIFICACIONES TÉCNICAS

4.1 DATOS TÉCNICOS

4.1.1 ENTORNO

Las especificaciones técnicas de las versiones de los distintos entornos corporativos son las siguientes:

 Sistema Operativo: Linux (Debian 8)

 Versión de Apache: Apache 2.4.10

 Versión de Wordpress: Última versión disponible

 Versión de PHP: 5.6.14 / 7.x

 Versión de RDBMS: MySQL 5.5.x / MySQL 5.7.x

4.2 BUENAS PRÁCTICAS

A la hora de desplegar código dentro de la infraestructura de Ineco, se asume una concienciación del desarrollo en base a unas buenas prácticas en distintos aspectos.

El registro de variables globales, es decir, aquellas variables externas que vienen del entorno, o vía GET, POST, Cookie y Server, queda desactivado a través de la directiva de configuración (php.ini) register_globals, ya que de esta forma los contextos de las diferentes aplicaciones de un mismo servidor mantienen su propio ámbito para sus variables de forma independiente, e impediría a un supuesto atacante que inyecte sus propias variables con alcance global. Estos valores no son ya accesibles para el script como lo son las variables internas, sino como valores de array, lo que obliga a chequear mínimamente su origen, filtrando los datos enviados al script desde fuera, y así tener clasificadas estas variables externas atendiendo a su origen (get, post, cookie, etc).

Cambiar el valor de la directiva register_globals es posible dinámicamente con la función init_set(), pero no sirve de nada, ya que la directiva incluida en php.ini es la que se aplica al tiempo de ejecución del script.

En caso de detectar que algún aplicativo haga uso de fuentes externas a los scripts directamente, se solicitará a los responsables su eliminación o transformación al empleo de $_GET o $_POST, según el sistema previsto de envío, cómo método de acceso.

El uso de etiquetas cortas <? ?> no está permitido, y es necesario hacer uso de su versión larga, es decir

<?php ?>. También hay que tener en mente ciertos aspectos de seguridad básicos, recogidos en el punto 4.8, en los diseños de desarrollo.

(7)

Dependiendo de cada uno de los parámetros que se necesiten, deberán ser introducidos tal y como se indican los puntos siguientes, y cualquier otro parámetro que no esté recogido en este documento y que necesite la aplicación, deberá ser igualmente introducido como un parámetro de configuración.

4.3

^10B

ELEMENTOS DE CONFIGURACIÓN

4.3.1 ARCHIVO DE CONFIGURACION

Todos los parámetros que puedan ser configurables en la aplicación deben encontrase en el archivo de configuración de la aplicación. Este archivo se encuentra en la siguiente ruta y su nombre debe ser config.php:

/var/www/<NombreAplicacion>/config.php

En este fichero es obligatorio recoger todos parámetros que sean referenciados en el aplicativo y que sean dependientes del entorno:

 El contenido del fichero de configuración estándar de Wordpress wp‐config.php debe contener únicamente un include al fichero config.php donde estarán todos los parámetros de configuración de la aplicación.

 El directorio de datos wp‐content tendrá permisos de escritura, alta disponibilidad, backup y optimización de rendimiento.

4.3.2 DIRECTORIO RAÍZ

Es el directorio base donde cuelgan todos los ficheros PHP relacionados con un aplicativo concreto y donde se dan los permisos sólo de lectura y ejecución. En este nivel es donde debe estar el fichero de configuración config.php del aplicativo. Si es necesario realizar alguna escritura en disco, no hay que hacerlo directamente en este directorio, sino en el siguiente, el directorio de datos, que es el directorio con permisos de escritura.

4.4

^13B

SERVICIO DE MAIL

Las aplicaciones desplegadas en estos entornos en caso de implementar funcionalidades de envío de correo electrónico deberán hacerlo con autenticación. Todas aquellas aplicaciones que soporten el envío de emails y no lo implementen con autenticación no funcionarán correctamente, ya que se rechazarán todas las peticiones de envío que realicen.

Para la correcta autenticación se deberá utilizar un usuario, password y servidor que vendrán definidos de forma específica para cada aplicación a través de parámetros de configuración.

(8)

4.5 SEGURIDAD

Los servidores están configurados teniendo en cuenta ciertos aspectos de seguridad, que deberían ser transparentes, pero aun así es posible que parte de la funcionalidad se vea afectada, ya que algunas funciones están deshabilitadas. Para evitar que se dé el caso, el responsable revisará si su aplicación hará uso de alguna de estas funciones y solicitará a sistemas que las habilite.

La lista de funciones deshabilitadas es la siguiente:

apache_setenv, define_syslog_variables, escapeshellcmd, eval, fp, fput, highlight_file, ini_alter, ini_get_all, ini_restore, inject_code, openlog, passthru, php_uname, phpAds_remoteInfo, phpAds_XmlRpc, phpAds_xmlrpcDecode, phpAds_xmlrpcEncode, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_setuid, posix_uname, proc_close, proc_nice, proc_open, proc_terminate, shell_exec, show_source, system, xmlrpc_entity_decode.

El intérprete php está limitado para lectura/escritura en el directorio de datos, y de lectura en el directorio de despliegue. En el primero es donde se ubican los datos del aplicativo y el segundo es donde se ubican los ficheros php, por lo que no es necesario escribir dentro del directorio de despliegues.

Worpress publica periódicamente nuevas versiones del sistema base para corregir vulnerabilidades de seguridad. El equipo de Sistemas y Comunicaciones se encargará de tener actualizada la plataforma Wordpress corporativa a la última versión disponible para corregir estas vulnerabilidades. Siempre se comenzará la actualización por el entorno de PRE y una vez finalizada se indicará al equipo de Desarrollo que valide la aplicación web por si tuviera que corregir posibles problemas (incompatibilidades de versión de plugins, temas, etc... Una vez dado el OK por parte del equipo de Desarrollo al entorno de PRE, se repetirá el proceso de la misma forma en el entorno de PRO.

5 SOLICITUD DE NUEVA APLICACIÓN

Para solicitar el alojamiento de una aplicación dentro de los servidores Wordpress de Ineco se ha de enviar un correo a la dirección [email protected] incluyendo en copia al responsable de la unidad organizativa del grupo de trabajo que lo solicite. En él se ha de indicar la siguiente información:

 Nombre de la aplicación.

 Si necesita o no acceso desde el exterior de Ineco.

 Nombre del dominio que se desea.

 Información necesaria para poder verificar que la aplicación está funcionando correctamente.

(9)

 Manual de instalación (en caso necesario).

6

^5B

DESPLIEGUE Y ACTUALIZACIONES

6.1

^17B

SERVIDOR DE APLICACIONES

El despliegue de una nueva aplicación se hará siguiendo los pasos indicados en el apartado anterior y para siguientes entregas mediante un mail a la dirección [email protected]. El proceso de despliegue o actualización de la aplicación se describe en los puntos los siguientes:

 En aquellos casos en que el equipo de desarrollo esté ubicado en alguna de las sedes de Ineco o tenga comunicación por VPN y trabaje sobre máquinas en dominio ineco.es, una vez tenga el equipo preparado el código de la entrega, lo ubicará en un directorio de su equipo local que se compartirá (por samba o CIFs) dando permisos de lectura y escritura al usuario servicios.aplic.

 En él deberán estar los scripts que serán desplegados en el servidor de aplicaciones, por ejemplo en un directorio llamado “despliegues_<NombreAplicación>” donde quedaría el contenido del aplicativo.

 Para dar los permisos a la carpeta despliegues_<NombreAplicación>: botón derecho  Properties  Sharing  Advanced Sharing  Share this folder  Permissions  Add.

Agregar al usuario servicios.aplic con Add, pinchar en Check Names para comprobar el nombre y OK, dándole los permisos de Read, Change y Full Control.

 Luego en Security  Edit, se vuelve a agregar al usuario servicios.aplic y se quitan el resto con Remove, pinchar en Check Names para comprobar el nombre y OK, dándole los permisos de Read, Change y Full Control.

 Por último en Security  Advanced  Change Permissions, activar: Replace all child object permissions with the inheritable permissions from this object.

 Enviar una solicitud al equipo de Sistemas y Comunicaciones ([email protected]), que contenga la siguiente información:

 Nombre de la aplicación.

 Dirección compartida por red (ejemplo:

\\X081204899.ineco.es\despliegues_<NombreAplicación>).

 Información necesaria para poder verificar que la aplicación está funcionando correctamente.

 En aquellos casos en que el equipo de desarrollo esté ubicado fuera de las sedes de Ineco y no tenga comunicación por VPN o no trabaje sobre máquinas en dominio ineco.es, una vez tenga el equipo preparado el código de la entrega, lo entregará en el servicio FTP de Ineco (ftp://servicioftp.ineco.es) a través del usaurio que se haya creado para ello (si no se posee

(10)

usuario de ftp se deberá mandar un mail a [email protected] solicitándolo, poniendo en copia al responsble del proyecto e indicando el nombre del proyecto o aplicación para el que se utilizará). Una vez subida la entrega al servicio FTP en la solicitud de despliegue del punto anterior se indicará en qué carpeta concreta se ha realizado la subida.

 El equipo de Sistemas y Comunicaciones realizará remotamente el commit, garantizando que sólo se suben al svn aquellos archivos que hayan cambiado, se hayan añadido o se hayan eliminado, optimizando así sobre todo los casos de re‐entregas masivas de ficheros sin cambios.

 Una vez realizado el commit se desplegará la aplicación, contestaremos al mail indicando el número de revisión generado, y se verificará con ayuda del equipo de desarrollo el correcto funcionamiento.

 El despliegue del aplicativo en el servidor se realizará evitando, en la medida de lo posible, la parada del servicio. Este despliegue consta de los siguientes pasos:

 Si no hay modificaciones en Base de Datos:

- Se desplegará la aplicación sobre la máquina.

- Se verificará que la aplicación funciona correctamente, con la colaboración por el equipo de desarrollo y de los usuarios funcionales de la aplicación, en la máquina.

 Si hay modificaciones en Base de Datos:

- Se ejecutará el script de modificación de la base de datos.

- Se desplegará la aplicación sobre la máquina.

- Se verificará que la aplicación funciona correctamente, con la colaboración por el equipo de desarrollo y de los usuarios funcionales de la aplicación, en el máquina.

 Tras haber verificado el correcto funcionamiento se podrá hacer una nueva solicitud al equipo de sistemas y comunicaciones ([email protected]), que contenga la siguiente información:

 Nombre de la aplicación.

 Revisión de la aplicación.

 Servidor al que desplegar.

 Dirección compartida por red (ejemplo:

\\X081204899.ineco.es\despliegues_<NombreAplicación>).

En posteriores entregas se eliminaría todo el contenido del directorio local

“despliegues_<NombreAplicación>”, se copiaría el nuevo proyecto y se volvería a seguir el procedimiento

(11)

anterior. En el escenario de entregas a através del servicio FTP también se eliminaría todo rastro de la entrega anterior para poder subir los archivos de la nueva entrega.

6.2

^18B

BASE DE DATOS

Para el despliegue o modificación de la base de datos es necesario que el equipo de desarrollo proporcione al equipo de sistemas la siguiente información:

 Nombre de la base de datos y entorno.

 Script de creación o modificación de la base de datos.

 Script de vuelta atrás para revertir el cambio en caso de que se desee volver a la situación anterior.

6.3

^19B

CICLO DE VIDA

Todas las aplicaciones para su utilización dentro de esta plataforma, primero serán desplegadas sobre el entorno de preproducción donde se harán todas las pruebas pertinentes para comprobar que todo funciona de forma correcta. Una vez verificado todo será desplegado en el entorno de Producción.

6.4 HORARIOS

Las nuevas versiones de las aplicaciones se subirán de 7‐9 de la mañana y deberán haber sido probadas correctamente en el entorno de preproducción. El equipo de sistemas debe recibir la confirmación de que todo funciona correctamente en el entorno de preproducción, al menos 24 horas antes de poder ser subida a producción.

7

^6B

MONITORIZACIÓN

Los servidores de aplicaciones se encuentran monitorizados y se envían avisos por mail pertinentes en caso de error. En caso de desear que se monitorice una aplicación en concreto es necesario que se proporcione la URL de acceso para chequear su código de respuesta HTTP.

También es necesario que se proporcionen las direcciones de correo de las personas que han de ser avisadas en caso de producirse alguna incidencia en el servicio.

El servicio de monitorización está activo las 24h del día, pero en planes de mantenimiento planificados, no se podrán notificar posibles caídas durante ese periodo.

(12)

8 ANEJOS

Anejo1: Reseña de modificaciones de la guía

Anejo 2: Ejemplos de codificación Anejo 3: Horarios de soporte Anejo 4: Requisitos de seguridad

(13)

8.1 ANEJO 1: RESEÑA DE MODIFICACIONES DE LA GUIA

EDICIÓN

DEL PROCEDIMIENTO MODIFICACIONES

Nº Fecha

0.1 Febrero, 2017 Borrador

8.2 ANEJO 3: HORARIOS DE SOPORTE

El servicio descrito en el presente documento, así como las plataformas que lo forman y el conjunto de los aplicativos que son desplegados en ellas, se da dentro del siguiente horario de soporte:

 Jornada de Invierno:

o Lunes a Jueves: 8h a 18h o Viernes: 8h a 15h

 Jornada de Verano:

o Lunes a Viernes: 8h a 15h

Fuera de dicho horario los equipos técnicos no se responsabilizan de la disponibilidad el servicio.

(14)

8.3 ANEJO 4: REQUISITOS DE SEGURIDAD

Como resultado de las distintas medidas integrales en materia de seguridad que se están tomando en la compañía, se establece el siguiente criterio de seguridad para los servicios de aplicaciones web:

 Es obligatorio publicar los aplicativos web Wordpress a través del protocolo HTTPS ya sean accesibles desde fuera de Ineco (Internet) o desde dentro (Intranet) y en cualquier entorno (PRE y PRO).

 Toda aplicación Wordpress que requiera envío o recepción de correo deberá utilizar protocolos seguros (SMTP, POP e IMAP sobre SSL o TLS).

8.3.1 IMPLEMENTACIÓN DE LA COMUNICACIÓN POR HTTPS

La implementación de la comunicación a través del protocolo HTTPS implica la utilización de certicados web por parte del servidor por cada dominio publicado. Según las necesidades de cada aplicativo esto se traduce en 4 escenarios distintos:

8.3.1.1 Aplicativos que requieren de un dominio propio y de certificado validable a nivel mundial En este escenario los responsables del aplicativo deberán adquirir, además del dominio en Internet, el certificado correspondiente a dicho dominio y renovarlos cada año hasta el fin de vida del aplicativo.

8.3.1.2 Aplicativos que requieren de un dominio propio aunque no de certificado validable a nivel mundial

Respecto al certificado, se podrá utilizar uno emitido por la CA (Entidad de Certificación) de Ineco para dicho dominio, sin coste adicional.

El hecho de utilizar un certificado de estas características implica que todos aquellos usuarios que entrasen a la Web deberían instalarse el certificado de validación de la CA de Ineco para que el navegador no le mostrase ningún warning o aviso. En caso de no hacerse los usuarios seguiríran pudiendo acceder a la web una vez acceptado el aviso.

De este grupo de usuarios habría que excluir a todos aquellos que utilizasen equipos corporativos en el dominio Ineco (todos los de las sedes), pues dichos certificados de validación ya se instalan de forma automática en ellos.

Este comportamiento, aunque no supone ninguna limitación funcional, puede no ser aceptable para determinados aplicativos por lo que es importante que los responsables tengan claro en qué escenario encaja su proyecto.

(15)

8.3.1.3 Aplicativos que no requieren de un dominio propio pero si de certificado validable a nivel mundial

En este escenario se recomienda publicar el aplicativo en un subdominio de ineco.com como por ejemplo: https://mail.ineco.com

De esta manera el aplicativo utilizaría el certificado wildcard de Ineco (*.ineco.com), el cual validará las comunicaciones sin coste adicional (ni por el dominio ni por el certificado).

Una segunda opción sería publicar el aplicativo en la ruta www.ineco.com/web/<nombre_aplicativo>

De esta manera quedará colgando del dominio www.ineco.com, cuyo certificado validará las comunicaciones sin coste adicional (ni por el dominio ni por el certificado).

Si estas opciones no fuesen válidas entonces aplicaría el primer escenario (Aplicativos que requieren de un dominio propio y de certificado validable a nivel mundial).

8.3.1.4 Aplicativos que no requieren de un dominio propio ni de certificado validable a nivel mundial

En este último escenario se podrían aplicar las medidas del tercer escenario y colgar el aplicativo bajo www.ineco.com.

También se puede utilizar una ruta diferente siempre que acabe en ineco.com o ineco.es pues ese conjunto de nombres ya pertenecen a Ineco y no implican un coste adicional. En esos casos se podrían publicar por ejemplo en nombres como git.ineco.es y utilizar certificados de la CA de Ineco tal como se describe en el segundo escenario.

Si no fuese válido publicar el aplicativo bajo un nombre con sufijo ineco.com o ineco.es entonces aplicaría el segundo escenario.

8.3.1.5 Posibles incidencias a tener en cuenta

Al migrar aplicativos que actualmente se estén publicando por HTTP al protocolo HTTPS pueden surgir aspectos problemáticos a tener en cuenta para valorar adecuadamente las implicaciones que conlleva:

 Todas aquellas aplicaciones que importen librerías para montar dinámicamente su web en el navegador del usuario deberán importarlas por HTTPS no por HTTP, para evitar que salgan warnings de seguridad en el navegador del usuario.

 Todas aquellas aplicaciones que tengan implementado un manejador propio que gestione dinámicamente las peticiones web para validar, redirigir (a una página de bienvenida o ruta interna,…), etc. deberán revisar que dicho manejador soporte y trate adecuadamente el protocolo HTTPS. En algunos casos incluso será necesario comunicarlo al grupo de sistemas para que revise la configuración de los servidores por posibles necesidades de reconfiguración.