2.1.- PRÁCTICAS DE DESARROLLO

No es el objetivo de esta guía valorar las distintas metodologías utilizadas para la gestión del desarrollo de aplicaciones, ya que existen múltiples factores que pueden hacer recomendable el uso de una u otra. Lo que sí recogemos es una lista de buenas prácticas, recomendaciones y reglas de obligatorio cumplimiento.

• La metodología a utilizar deberá aportar al proyecto la agilidad necesaria para incluir iterativamente los requisitos transmitidos por los interlocutores del IASS, y aportará las herramientas necesarias para la validación de esos requisitos (maquetas o prototipos). Se aporta a modo de referencia la metodología SCRUM.
• El desarrollo deberá ser, en la medida de lo posible, orientado a tests para asegurar la calidad del software y su robustez ante cambios.
• Se exigirá trabajar con el sistema de control de versiones corporativo. Se recomienda seguir las Mejores prácticas para control de versiones. recomendadas por Gitlab.
• Para la evolución y despliegue de la aplicación se contará con la plataforma corporativa para integración y despliegue continuos. Se aconseja leer el siguiente conjunto de mejores prácticas y consultar con el equipo de Informática sobre los criterios establecidos internamente al respecto.
  • Mejores prácticas para integración continua.

  • Mejores prácticas para integración y despliegue continuos.

• Las aplicaciones se desplegarán preferentemente en contenedores utlizando Docker como runtime. En el apartado Orientación a la nube de esta guía se señala un conjunto de buenas prácticas específico para trabajar con esta tecnología.
• No hay que olvidar que el software es un producto vivo. Es muy importante que cuando se desarrolle una aplicación se tenga en cuenta, respecto a su mantenimiento, además de la evolución funcional, la evolución técnológica, con el fin de que dicha aplicación se pueda ir adaptando a la progresión de la tecnología.
• Como norma general, las aplicaciones que necesiten autentificación de usuarios/as deberán implementar de manera obligatoria la integración con LDAP contra el Directorio Activo corporativo, salvo que estas personas usuarias sean externas a la corporación, y por parte del equipo de Informática se plantee otra forma de autentificación. Asimismo desde el IASS se podría estimar conveniente, en ciertos casos, la integración con el CAS (Central Authentication Service) corporativo en lugar de LDAP. Por último, se recomieda que se permita además el uso del certificado electrónico y se acordará con la persona responsable del proyecto por parte de la corporación, los tipos de certificado a aceptar (Certificados de empleado público, de persona física, de representante, DNI electrónico, etc).
• La aplicación deberá contar con un adecuado registro de logs, siguiendo las siguientes mejores prácticas:
• Establecer objetivos claros para su registro.
  • Utilizar los niveles de registro correctamente.
  • Estructurar bien los registros.
  • Escribir entradas de registro significativas.
  • Realizar pruebas.
  • Emplear líneas de registro canónicas por solicitud.
  • Agregar y centralizar los registros.
  • Posibilitar la configuración de una política de retención.

• Usabilidad y accesibilidad. El IASS se esfuerza para que las aplicaciones desarrolladas sean fácilmente utilizables y accesible por la mayor parte posible de la ciudadanía y/o del funcionariado en su caso. Por tanto, respecto a los principios de usabilidad y accesibilidad, sean referidos a aplicaciones web publicadas en la Intranet como en Internet, aplicará lo recogido en la Norma de presencia en internet. En el caso de imposibilidad de cumplimiento debido a razones técnicas derivadas de las características de una determinada funcionalidad, la empresa lo deberá justificar a la persona responsable por parte del IASS, quien valorará internamente con su equipo y responsables funcionales, si se publica la aplicación en cuestión con el referido déficit, o se procede a modificar la funcionalidad para eliminarlo. Respecto a este tema se puede encontrar material de ayuda en la web Accesibilidad del Portal de administración electrónica nacional.

• Los textos que se incluyan en las aplicaciones y portales que se desarrollen para el IASS deberán hacer uso de un lenguaje no sexista.

2.2.- NORMATIVA Y PROCEDIMIENTOS

La siguiente lista de documentos se debe tener en cuenta en el desarrollo de los proyectos

• En el caso de que el desarrollo a realizar tenga visibilidad hacia la ciudadanía a través de un portal, deberá tener en cuenta lo recogido en la Norma de presencia en internet.
• Para el desarrollo de aplicaciones encargadas por el IASS, se deberá cumplir con la normativa que se relaciona en el apartado específico relativo a la seguridad en esta guía.

3.1.- BUENAS PRÁCTICAS

En este apartado se relacionan una serie de directrices en base a las medidas del Anexo II del Esquema Nacional de Seguridad mp.sw.1 Desarrollo de aplicaciones y mp.sw.2 Aceptación y puesta en servicio, que se consideran fundamentales, sin embargo la empresa desarrolladora podrá y deberá tener en cuenta otras buenas prácticas que considere apropiadas para optimizar la calidad del software desde el punto de vista de la seguridad.

• Seguir las normas, estándares y requisitos de seguridad en todas las fases del desarrollo. Adopción de conjuntos de buenas prácticas o recomendaciones reconocidas sobre desarrollo seguro como BP/28 Recomendaciones de seguridad sobre desarrollo seguro.
• Disponer de normas de programación segura, especialmente en lo relativo al control de asignación y liberación de la memoria y al desbordamiento de la memoria.
• Cumplir con el Marco de Trabajo dispuesto en esta guía en relacion a: los mecanismos de identificación y autenticación, los mecanismos de protección de la información tratada y la generación y tratamiento de logs.
• La capacitación y concienciación de los y las profesionales que intervienen en el proyecto.
• Realizar seguimiento diario a las publicaciones de nuevas vulnerabilidades. Como fuentes de información se aconseja la atención a las recomendaciones de los fabricantes y proveedores de las tecnologías utilizada, así como a las publicaciones de entidades públicas como por ejemplo INCIBE o CCN-CERT
• Utilización de herramientas y procedimientos para la evaluación de la seguridad del código.
• Realización de pruebas de seguridad automatizada con herramientas de análisis de código para asegurar la detección de vulnerabilidades u otros eventos que puedan impactar en la seguridad del software. Se deberían verificar las checklists asociadas a la normativa de desarrollo seguro de software basadas en guías de estándares y metodologías Open Source Security Testing Methodology Manual (OSSTMM), Open Web Application Security Project (OWASP), o equivalentes.
• Una vez confirmada una vulnerabilidad, estudiar, planificar y priorizar su resolución en función de su gravedad y potencial impacto.
• Revisión regular del código con el fin de mantener librerías, sistemas operativos, parches de seguridad, etc. lo más actualizados posible.
• Evaluación de la seguridad de las dependencias de terceros como librerías o APIs antes de su integración.
• Utilizar mecanismos robustos de autenticación, como LDAP y/o Certificado electrónico.
• Atender siempre al principio de menor privilegio.
• Cifrado adecuado para proteger los datos sensibles durante el almacenamiento, la transmisión o el procesamiento de acuerdo a la CCN STIC 807 Criptología de empleo en el Esquema Nacional de Seguridad y conforme al refuerzo 3 que el Esquema Nacional de Seguridad nos propone como parte de su medida mp.sw.1.
• Como medida fundamental de salvaguarda ante potenciales vulnerabilidades se establece la reducción del software a instalar al mínimo imprescindible, por lo que las personas desarrolladoras del software deberán tener en cuenta esta premisa, especialmente a la hora de crear las imágenes de los contenedores Docker.
• La empresa acordará con la persona responsable por parte de IASS, si será necesaria la integreación del software con ciertos microservicios corporativos destinados a garantizar la seguridad entre otros fines.
• En relación al tratamiento de datos sensibles en los entornos de preproducción o desarrollo, la empresa deberá recurrir a la anonimización o a la seudonimización de los mismos, minimizando la utilización de datos personales no disociados y priorizando el empleo de datos sintéticos o creados artificialmente. La utilización en los referidos entornos de los datos de producción, quedará restringida a los casos en los que no sea posible trabajar de otra forma y deberá justificarse debidamente.

3.2.- NORMATIVA Y PROCEDIMIENTOS

• Auditorías internas: Todo el software desarrollado para el IASS será susceptible de ser auditado por el equipo de Seguridad. Tras la evaluación se informará a la empresa desarrolladora de los resultados y de las correcciones que deberá realizar de forma obligatoria si fuese necesario, así como de otras mejoras recomendadas.
• Acciones correctivas: La empresa adjudicataria deberá atender con la urgencia que se le requiera en función de cada caso, las comunicaciones, solicitudes e indicaciones que la persona interlocutora por parte del IASS, del proyecto o del equipo de seguridad, les hagan llegar en relación a posibles vulnerabilidades del software. Todo ello dentro del marco establecido por la norma Procedimiento de gestión del mantenimiento y parches de seguridad (vulnerabilidades) .

3.3.- PROTECCIÓN DE DATOS

Se considera especialmente importante en materia de seguridad la protección de los datos personales y la seguridad de la información, por este motivo las empresas desarrolladoras deberán tener presente la siguiente normativa a la hora de desarrollar o proponer mejoras:

Reglamento General de Protección de Datos.
Ley Orgánica de Protección de Datos Personales y Garantía de los Derechos Digitales.
Esquema Nacional de Seguridad.

4.1.- SOFTWARE BASE SERVIDOR

Productos y tecnologías que el equipo de Informática consideran apropiados para nuevos desarrollos de software, y plataformas con las que dicho software podría tener que integrarse.

En los casos en los que la solución tecnológica elegida no haya sido acordada en el contrato, la empresa desarrolladora deberá argumentar el uso de la misma y será necesario el visto bueno de la persona responsable del proyecto por parte del IASS.

Si se justifica adecuadamente podría valorarse la selección de opciones no incluidas en la siguiente tabla.

En general se hará uso de las últimas versiones estables, salvo que desde el IASS se indique otra.

4.2.- SOFTWARE EN EQUIPOS CLIENTES

Las aplicaciones a desarrollar para el IASS tendrán preferentemente una arquitectura web, de manera que el elemento más importante a tener en cuenta en estos equipos es el navegador. Salvo justificación expresa y aceptada por el STIC, las aplicaciones deberán ser compatibles con los estándares web actuales y deberán poderse visualizar en los navegadores más utilizados, que son los siguientes:

Dependencias potenciales a tener en cuanta a la hora del desarrollo del software contratado por el IASS.

Las integraciones relacionadas en los apartados de esta página se refieren a configuraciones y/o desarrollos específicos realizados sobre las aplicaciones entregadas al IASS, con el fin de posibilitar la comunicación con las soluciones, sistemas y dependencias que se mencionan, si ello fuese necesario.

5.1.- Aplicaciones de la Administración General del Estado (AGE)

Es posible que algunas de las aplicaciones desarrolladas para el IASS deban inegrarse con ciertas soluciones que provee la AGE, por lo que la empresa deberá revisar la correspondiente documentación técnica en el Portal de administración electrónica (Pae)- Se relacionan a continuación algunos ejemplos:

• Validación de firmas electrónicas y sellado de tiempo: @firma .
• Verificación y consulta de datos Plataforma de Intermediación.
• Registro de documentos: Geiser.
• Autenticación por parta de la ciudadanía: cl@ve.
• Gestión de notificaciones electrónicas: Notifica.
• Gestión de documentos y expedientes electrónicos: Inside.
• Autenticación del funcionariado: Autentica.

Hay que tener en cuenta que el acceso a las plataformas anteriores se realiza mediante la Red Sara del Gobierno de Canarias, lo que dificulta el acceso a las mismas desde los entornos de desarrollo de las empresas.

En los casos en los que entre las funcionalidades de la aplicación a desarrollar se encuentre la de intermediación de datos con otras AAPP, se deberá atender a lo establecido en el Esquema Nacional de Interoperabilidad.

5.2.- Aplicaciones CORPORATIVAS

Es posible que algunos de los nuevos desarrollos tengan que integrarse con ciertas aplicaciones corporativas como podrían ser por ejemplo el Gestor de Expedientes, Secretaría o Portafirmas entre otras. En esos casos, la persona responsable del proyecto en el IASS facilitará los manuales y la documentación necesaria a la empresa adjudicataria y acordará con la misma la solución técnica a utilizar (API REST, etc.)

6.1.- Fase de DESARROLLO

Uno de las principales fases del proyecto afectadas por la orientación hacia la nube es la fase de desarrollo, pues condiciona la arquitectura y diseño de las soluciones informáticas. Las mejores prácticas en esta fase son:

• Crecimiento vertical: Las aplicaciones deben estar diseñadas para ejecutarse sobre una sola máquina. El crecimiento de las necesidades se harán en base al hardware de esta máquina.
• Crecimiento horizontal: Las aplicaciones deben estar diseñadas para poder tener múltiples instancias de la misma ejecutandose sobre varias máquinas. Para ello, las aplicaciones deberán ser Stateless, o disponer de un mecanismo de compartición de los datos de sesión compatible con los entornos de la nube.
• Generación de datos y métricas: Las aplicaciones deberán recopilar y generar todos los datos necesarios para que puedan ser centralizados y consumidos de cara a evaluar su estado, disponibilidad, nivel de servicio y detectar necesidades de crecimiento/corrección. 

6.2.- Fase de INTEGRACIóN

La integración del software desarrollado, dentro de la nube corporativa, implica la contenerización del mismo. Se exponen a continuación una serie de buenas prácticas para este proceso:

• Se crearán preferentemente imágenes Docker basadas en sistemas operativos minimalistas que refuercen la seguridad al reducir la superficie de ataque y faciliten la administra ción y el mantenimiento, como por ejemplo Alpine Linux.
• Con el mismo objetivo del punto anterior, la instalación del resto de software se reducirá al mínimo imprescindible.
• En aras de conseguir la reducción de imágenes explicada en el apartado anterior, y otras ventajas como las de facilitar la integración y despliegue continuos, se utilizará la técnica multistage de creación de contenedores en los casos en los que sea posible.
• Se utilizarán repositorios oficiales.
• Los datos que se deban persistir serán almacenados fuera del contenedor.
• La imagen docker deberá ser configurada de tal forma que se le pueda proveer al contendor todos los datos necesarios para su correcta ejecución, mediante variables de entorno o parámetros.
• Procurar desplegar una única aplicación por contenedor.
• Se debe ejecutar el contenedor con un usuario con mínimos privilegios, nobody si fuera posible.
• Las empresas desarrolladoras entregarán siempre el archivo Dockerfile y no la imagen ya creada.
• Dentro del dockerfile, se deberán organizar las diferentes líneas que lo componen para optimizar la cache
• La creación de artefactos debe ser autocontenida salvo que se justifique lo contrario. La configuración e instalación de los artefactos que componen la aplicación (paquetes, librerías ejecutables, etc) debe proveerse como parte de la propia generación del contenedor de aplicación de forma que el entorno de creación de estos artefactos (compiladores, librerías y otras herramientas) sea reproducible y quede explícitamente documentado en un Dockerfile.
• La creación de los contenedores de aplicación para su despliegue no debe depender de la máquina en la que se generen estos contenedores.
• Se aconseja seguir siempre estas y otras Mejores prácticas para trabajar con Docker.

7.1.- DESARROLLOS A MEDIDA

Cuando el IASScontrata el desarrollo de una aplicación, o la adaptación a sus necesidades de una aplicación ya desarrollada, necesita garantizar la posibilidad de mantenerla y evolucionarla. Para ello es fundamental disponer del código fuente de la misma y los scripts necesarios para su generación. Es fundamental que el equipo de Informática se asegure de que cuenta con todo lo necesario para generar las imágenes de los contenedores a desplegar. Por tanto no se aceptará la aplicación previamente construida. Teniendo esto en cuenta la forma de entrega de las aplicaciones deberá ser el siguiente:

• La empresa deberá subir la aplicación (Dockerfile, código fuente, librerías, makefiles, ficheros POM o scripts de generación de contenedores, etc.) al respositorio de software corporativo, en la actualidad soportado por GitLab.
• La persona responsable del proyecto por parte del IASS, comprobará que es capaz de generar la aplicación e instalarla.
• En caso de que, por sus características propias, la aplicación no pudiera ser contenerizada, la configuración del servidor o servidores que alojen a la misma deberán ir definidos por código haciendo uso de scripts de Puppet o Ansible. Siempre adaptándose al entorno tecnológico corporativo del cual el responsable del contrato por parte del IASS informará a la empresa. 

7.2.- Contenidos formativos para la plataforma Moodle 

En los casos en los que el proyecto incluya sesiones formativas para personas usuarias, administradoras o desarrolladoras, la empresa deberá entregar, de los siguientes contenidos formativos, los que se acuerden con el/la responsable del contrato por parte del IASS. Será la propia empresa la que se encargará de la subida de los mismos al curso correspondiente en la plataforma Moodle.

• Temas a estudiar por el alumnado.
• Transparencias utilizadas durante la formación.
• Ejercicios y/o cuestionarios.
• Material audiovisual.

7.3.- Licenciamiento

Junto al software desarrollado deberá aportarse en todo caso un archivo donde se especifique el tipo de licencia

Si en el marco del proyecto de desarrollo fuese necesario además adquirir un paquete de software comercial o libre, deberá proporcionarse los entregables propios de este producto (Enlace a la web de descarga, documentación, etc.).