UNIVERSIDAD PERUANA UNIÓN - core.ac.uk · 5.5.4 Referencia directa insegura a objetos ..... 69...
213
1 UNIVERSIDAD PERUANA UNIÓN ESCUELA DE POSGRADO UNIDAD DE POSGRADO DE INGENIERÍA UN MODELO PARA EL DESARROLLO DE APLICACIONES WEB SEGURAS Tesis presentada para optar el grado de Magíster en Ingeniería de Sistemas con mención en Ingeniería de Software Por: Abel Ángel Sullón Macalupú LIMA, PERÚ 2014
Transcript of UNIVERSIDAD PERUANA UNIÓN - core.ac.uk · 5.5.4 Referencia directa insegura a objetos ..... 69...
1
UNIVERSIDAD PERUANA UNIÓN
ESCUELA DE POSGRADO
UNIDAD DE POSGRADO DE INGENIERÍA
UN MODELO PARA EL DESARROLLO DE
APLICACIONES WEB SEGURAS
Tesis presentada para optar el grado de Magíster en Ingeniería de
Sistemas con mención en Ingeniería de Software
Por:
Abel Ángel Sullón Macalupú
LIMA, PERÚ
2014
ii
DEDICATORIA
A mi amada esposa, Milva Gutierrez Quispe, por motivarme
constantemente en la investigación y superación académica.
A mi adorado hijo, Jarib, por su comprensión.
iii
AGRADECIMIENTOS
A Dios, por haberme conducido en la elaboración de este proyecto.
A mi familia que es el motor de mi vida;
A mi asesor y a todas aquellas personas, quienes contribuyeron con sus aportes
relevantes en el desarrollo de la presente investigación.
iv
ÍNDICE GENERAL
DEDICATORIA ......................................................................................................... ii
AGRADECIMIENTOS .............................................................................................. iii
ÍNDICE GENERAL .................................................................................................. iv
ÍNDICE DE TABLAS ................................................................................................ ix
ÍNDICE DE FIGURAS ............................................................................................... x
ÍNDICE DE ANEXOS ............................................................................................... xi
RESUMEN ............................................................................................................. xiii
ABSTRACT ........................................................................................................... xiv
CAPÍTULO 1 ..................................................................................................... 1
INTRODUCCIÓN ..................................................................................................... 1
CAPÍTULO 2 ..................................................................................................... 4
REVISIÓN BIBLIOGRÁFICA ................................................................................... 4
2.1 Marco conceptual .................................................................................................... 4
2.1.1 Modelo de procesos del software ................................................................... 4
2.1.2 Taxonomía de la seguridad .............................................................................. 4
2.1.3 Software ........................................................................................................... 7
2.1.4 Ingeniería del software .................................................................................... 7
2.1.5 Software como un servicio (SaaS) .................................................................... 7
2.1.6 Seguridad del software .................................................................................... 8
2.1.7 Aplicaciones web.............................................................................................. 8
2.1.8 Desarrollo web ................................................................................................. 8
2.1.9 Análisis de riesgo .............................................................................................. 9
2.2 Revisión del estado del arte ..................................................................................... 9
2.2.1 Modelos de calidad del software en sintonía con la Seguridad ...................... 9
2.2.2 Modelo de McGraw con la construcción de software seguro ....................... 12
2.2.3 SSE-CMM/ISO 21827, COBIT e ITIL en relación a la seguridad del software . 13
2.2.4 Guía OWASP ................................................................................................... 19
2.2.5 Vulnerabilidades OWASP Top 10 ................................................................... 21
2.2.6 Microsoft SDL ................................................................................................. 23
2.2.7 SDL-Agile ........................................................................................................ 24
2.2.8 Sustainable software security process (S3P) ................................................. 25
2.2.9 Controles de seguridad de ISO 27001 ............................................................ 26
2.3 Procesos ágiles de desarrollo de software ............................................................ 29
2.3.1 Manifiesto ágil ................................................................................................ 29
v
2.3.2 Marco general MSF-Agile ............................................................................... 30
2.3.3 Artefactos agile UP ......................................................................................... 32
2.3.4 Prácticas XP y TDD .......................................................................................... 33
2.3.5 Prácticas Scrum .............................................................................................. 36
CAPÍTULO 3 ....................................................................................................40
MATERIALES Y MÉTODOS ...................................................................................40
3.1 Lugar de ejecución ................................................................................................. 40
3.2 Equipos y materiales .............................................................................................. 40
3.2.1 Equipos ........................................................................................................... 40
3.2.2 Software ......................................................................................................... 40
3.2.3 Servicios ......................................................................................................... 41
3.2.4 Material bibliográfico ..................................................................................... 41
3.3 Tipo de investigación ............................................................................................. 41
3.4 Indicadores de evaluación de la propuesta ........................................................... 42
3.5 Diagrama de flujo de las actividades de la Investigación....................................... 44
3.6 Cronograma de actividades ................................................................................... 46
3.7 Presupuesto y financiamiento del proyecto de tesis ............................................. 48
CAPÍTULO 4 ....................................................................................................50
CONSTRUCCIÓN DEL MODELO PARA EL DESARROLLO .................................50
DE APLICACIONES WEB SEGURAS ....................................................................50
4.1 Introducción ........................................................................................................... 50
4.2 Diseño gráfico del modelo propuesto .................................................................... 50
4.3 Principios de seguridad .......................................................................................... 51
4.3.1 Defensa en profundidad ................................................................................ 51
4.3.2 Privilegios específicos .................................................................................... 51
4.3.3 Estilo de codificación simple pero robusto .................................................... 51
4.3.4 Seguimiento ................................................................................................... 52
4.4 Backend web seguro .............................................................................................. 52
4.5 Artefactos del backend web seguro ...................................................................... 54
4.5.1 Requisitos del sistema (o requisitos para el módulo backend) ..................... 54
4.5.2 Registro de riesgos de seguridad (amenazas y vulnerabilidades). ................ 54
4.5.3 Registro de componentes de seguridad. ....................................................... 55
4.5.4 Arquitectura de la aplicación ......................................................................... 55
4.5.5 Estándares de desarrollo................................................................................ 55
4.5.6 Método de trabajo del equipo ....................................................................... 56
vi
4.5.7 Prototipos principales .................................................................................... 56
4.5.8 Diseño del sistema (para la iteración) ............................................................ 57
4.6 Análisis de riegos de seguridad .............................................................................. 57
4.7 Artefactos del análisis de riesgos de seguridad ..................................................... 59
4.8 Implementación de los componentes de seguridad .............................................. 59
4.9 Artefactos de la implementación de los componentes de seguridad ................... 61
4.9.1 Producto funcional seguro ............................................................................. 61
4.10 Demostración y validación de la seguridad ........................................................... 61
4.11 Artefactos de la demostración y validación de la seguridad ................................. 62
4.11.1 Formulario de lecciones aprendidas .............................................................. 62
4.12 Resumen ................................................................................................................ 62
CAPÍTULO 5 ....................................................................................................64
VALIDACIÓN DEL MODELO PROPUESTO ...........................................................64
WSM-DEV – PARTE 1............................................................................................64
5.1 Introducción ........................................................................................................... 64
5.2 Acerca del proyecto ............................................................................................... 64
5.2.1 Grupo InnOp Perú .......................................................................................... 64
5.2.2 Proyecto UPeU-CONCYTEC 2013 ................................................................... 64
5.2.3 Qualpaca 1.0 .................................................................................................. 65
5.2.4 Materiales y métodos .................................................................................... 65
5.3 Backend web seguro y la definición del proyecto Qualpaca ................................. 66
5.4 Análisis de riesgos de seguridad ............................................................................ 67
5.5 Implementación de los componentes de seguridad .............................................. 67
5.5.1 SQL inyection.................................................................................................. 68
5.5.2 Pérdida de autenticación y gestión de sesiones .................................... 68
5.5.3 Secuencia de comandos en sitios cruzados (XSS) ............................... 69
5.5.4 Referencia directa insegura a objetos ..................................................... 69
5.5.5 Configuración de seguridad incorrecta .................................................... 71
5.5.6 Exposición de datos sensibles .................................................................. 72
5.5.7 Ausencia de control de acceso a las funciones ...................................... 73
5.5.8 Falsificación de peticiones en sitios cruzados (CSRF) ......................... 74
5.5.9 Uso de componentes con vulnerabilidades conocidas ......................... 75
5.5.10 Redirecciones y reenvíos no validados .......................................................... 75
5.5.11 Registro de sucesos incompletos ................................................................... 76
5.5.12 Datos incompletos ......................................................................................... 77
vii
5.5.13 Permisos inconsistentes ................................................................................. 77
5.6 Demostración y validación de la seguridad ........................................................... 81
5.7 Resumen ................................................................................................................ 81
CAPÍTULO 6 ....................................................................................................82
VALIDACIÓN DEL MODELO PROPUESTO ...........................................................82
WSM-DEV – PARTE 2............................................................................................82
6.1 Introducción ........................................................................................................... 82
6.2 Análisis de riegos de seguridad .............................................................................. 82
6.3 Implementación de los componentes de seguridad .............................................. 83
6.4 Demostración y validación de la seguridad ........................................................... 83
6.5 Resumen ................................................................................................................ 84
CAPÍTULO 7 ....................................................................................................85
RESULTADOS Y DISCUSIÓN ...............................................................................85
7.1 Nuevo modelo práctico para desarrollar aplicaciones web seguras en el menor
tiempo. ............................................................................................................................... 85
7.2 Módulo backend de administración y configuración de aplicaciones web tipo SaaS
con Django. ........................................................................................................................ 86
CAPÍTULO 8 ....................................................................................................87
CONCLUSIONES Y RECOMENDACIONES ..........................................................87
8.1 Conclusiones .......................................................................................................... 87
8.2 Recomendaciones .................................................................................................. 88
REFERENCIAS ......................................................................................................90
GLOSARIO .............................................................................................................94
ANEXOS ..........................................................................................................96
Anexo 1 – Matriz de consistencia del proyecto ................................................................. 96
Anexo A1 – Requisitos del sistema .................................................................................... 97
Anexo A2 - Registro de riesgos de seguridad (amenazas y vulnerabilidades) ................... 98
Anexo A3 - Registro de componentes de seguridad .......................................................... 99
Anexo A4 – Arquitectura de la aplicación ........................................................................ 100
Anexo A5 – Estándares de desarrollo .............................................................................. 101
Anexo A6 – Método de trabajo del equipo...................................................................... 102
Anexo A7 – Prototipos principales ................................................................................... 104
Anexo A8 – Diseño del sistema ........................................................................................ 105
Anexo A9 – Formulario de lecciones aprendidas ............................................................. 106
Anexo B1 – Requisitos del Sistema (módulo backend web seguro) ................................ 107
viii
Anexo B2 - Registro de riesgos de seguridad (amenazas y vulnerabilidades) ................. 109
Anexo B3 - Registro de componentes de seguridad ........................................................ 110
Anexo B4 – Arquitectura de la aplicación ........................................................................ 111
Anexo B5 – Estándares de desarrollo .............................................................................. 112
Anexo B7 – Prototipos principales ................................................................................... 113
Anexo B8 – Diseño del sistema ........................................................................................ 140
Anexo B9 – Formulario de lecciones aprendidas ............................................................. 169
Anexo B10 – Lista de tareas de desarrollo del backend .................................................. 170
Anexo C1 – Product backlog (requisitos del sistema) ...................................................... 172
Anexo C2 - Registro de riesgos de seguridad (amenazas y vulnerabilidades) ................. 174
Anexo C3 - Registro de componentes de seguridad ........................................................ 175
Anexo C4 – Arquitectura de la aplicación ........................................................................ 176
Anexo C5 – Estándares de desarrollo .............................................................................. 177
Anexo C6 – Método de trabajo del equipo ...................................................................... 178
Anexo C7 – Prototipos principales ................................................................................... 180
Anexo C8 – Diseño del sistema ........................................................................................ 182
Anexo C9 – Formulario de lecciones aprendidas ............................................................. 187
Anexo C10 – Acta de constitución del proyecto .............................................................. 188
Anexo C11 – Sprint backlog ............................................................................................. 190
Anexo C12 – Acta de conformidad del servicio o entrega ............................................... 193
Anexo C13 – Manual del usuario ..................................................................................... 194
ix
ÍNDICE DE TABLAS
Tabla 1 – Taxonomía de requisitos de seguridad con ejemplos ................................ 5
Tabla 2 – Sintonía de la seguridad con los modelos de calidad .............................. 10
Tabla 3 – Seguridad y SSE-CMM ........................................................................... 14
Tabla 4 – Seguridad y COBIT, dominio planear y organizar ................................... 15
Tabla 5 – Seguridad y COBIT, dominio adquirir e implementar ............................... 16
Tabla 6 – Seguridad y COBIT, dominio entrega y soporte ...................................... 16
Tabla 7 – Seguridad e ITIL ..................................................................................... 17
Tabla 8 – Los diez riesgos más importantes en aplicaciones web 2013 ................. 21
Tabla 9 - Indicadores de evaluación para el modelo propuesto .............................. 42
Tabla 10 - Cronograma de actividades ................................................................... 46
Tabla 11 - Presupuesto del proyecto ...................................................................... 48
Tabla 12 - Financiamiento del proyecto .................................................................. 49
x
ÍNDICE DE FIGURAS
Figura 1 – Aspectos coincidentes entre SSE-CMM, COBIT e ITIL en relación a la
seguridad del software ............................................................................................ 18
Figura 2 – Ciclo de desarrollo seguro de OWASP .................................................. 20
Figura 3 – Modelo de madurez de aseguramiento de software Open SAMM .......... 21
Figura 4 - Vista general del método SDL ............................................................... 24
Figura 5 – Ciclo de vida de SDL-Agile .................................................................... 24
Figura 6 - Vista general del método S3P ................................................................. 25
Figura 7 – Proceso de la norma ISO/IEC 27001:2005 ............................................ 26
Figura 8 – Dominios de la norma ISO/IEC 27001:2005 .......................................... 27
Figura 9 – Proceso de implementación del SGSI utilizando la norma ISO/IEC
27001:2005 en el centro de cómputo de la ONP..................................................... 28
Figura 10 –Principales tareas y actividades de MSF Agile ...................................... 31
Figura 11 – Ciclo de vida Agile-UP ......................................................................... 32
Figura 12 – Flujo para aplicar TDD ......................................................................... 35
Figura 13 – Proceso Scrum .................................................................................... 38
Figura 14 – Esquema de elaboración de la propuesta ............................................ 41
Figura 15 – Diagrama de flujo de las actividades de la investigación ...................... 44
Figura 16 – Diseño del modelo WSM-DEV ............................................................. 50
Figura 17 – Modelo de autorización de usuarios ..................................................... 78
Figura 18 – Modelo de autorización de usuarios de aplicaciones SaaS .................. 79
xi
ÍNDICE DE ANEXOS
Anexo 1 – Matriz de consistencia del proyecto......................................... 96
Anexo A1 – Requisitos del sistema........................................................... 97
Anexo A2 - Registro de riesgos de seguridad …………………………….. 98
Anexo A3 - Registro de componentes de seguridad ................................ 99
Anexo A4 – Arquitectura de la aplicación ................................................. 100
Anexo A5 – Estándares de desarrollo ..................................................... 101
Anexo A6 – Método de trabajo del equipo ............................................... 102
Anexo A7 – Prototipos principales ........................................................... 104
Anexo A8 – Diseño del sistema ............................................................... 105
Anexo A9 – Formulario de lecciones aprendidas .................................... 106
Anexo B1 – Requisitos del Sistema (módulo backend web seguro) ....... 107
Anexo B2 - Registro de riesgos de seguridad ……………………………... 109
Anexo B3 - Registro de componentes de seguridad ............................... 110
Anexo B4 – Arquitectura de la aplicación ................................................ 111
Anexo B5 – Estándares de desarrollo ..................................................... 112
Anexo B7 – Prototipos principales ........................................................... 113
Anexo B8 – Diseño del sistema ............................................................... 140
Anexo B9 – Formulario de lecciones aprendidas .................................... 169
Anexo B10 – Lista de tareas de desarrollo del backend ......................... 170
Anexo C1 – Product backlog (requisitos del sistema) ............................. 172
Anexo C2 - Registro de riesgos de seguridad …………………………….. 174
Anexo C3 - Registro de componentes de seguridad ................................ 117
Anexo C4 – Arquitectura de la aplicación ................................................ 176
Anexo C5 – Estándares de desarrollo ..................................................... 177
Anexo C6 – Método de trabajo del equipo .............................................. 178
xii
Anexo C7 – Prototipos principales............................................................. 180
Anexo C8 – Diseño del sistema ................................................................ 182
Anexo C9 – Formulario de lecciones aprendidas .................................... 187
Anexo C10 – Acta de constitución del proyecto........................................ 188
Anexo C11 – Sprint backlog .................................................................... 190
Anexo C12 – Acta de conformidad del servicio o entrega ........................ 193
Anexo C13 – Manual del usuario .............................................................. 194
xiii
RESUMEN
El propósito de esta investigación es obtener un modelo práctico para el desarrollo
de aplicaciones web seguras y en el menor tiempo, basados en los procesos del
SSE-CMM/ISO 21827, las características de seguridad web de la OWASP 2013 y
experiencias vividas personalmente en el ámbito de la seguridad web. El modelo
propuesto se basa en cuatro principios y cuatro prácticas de seguridad como son: la
implementación preliminar de los componentes de seguridad para cada
vulnerabilidad más recurrentes en aplicaciones web, el análisis de riesgos de
seguridad en torno al negocio, la implementación y pruebas de los componentes de
seguridad para recurrentes o nuevas vulnerabilidades y, la demostración y validación
de la seguridad. El modelo propuesto fue refinado y validado mediante la aplicación
en el Proyecto QUALPACA patrocinado por CONCYTEC y la UPeU, mitigando las
vulnerabilidades al 92.30%, con una velocidad de 20 puntos mensual y una cobertura
del estilo de codificación de un 90%.
Palabras claves: Seguridad web, SSE-CMM/ISO 21827, OWASP, Riesgo de
seguridad, Ataque, Vulnerabilidad.
xiv
ABSTRACT
The purpose of this research is to obtain a practical model for the development of
secure web applications in the shortest time, based on the processes of SSE-CMM /
ISO 21827, the characteristics of web security OWASP 2013 and experiences in
person at the field of web security. The proposed model is based on four principles
and four security practices such as: preliminary implementation of safety components
for increasingly recurrent vulnerability in web applications, analysis of security risks
around the business, implementation and testing safety components for recurrent or
new vulnerabilities, demonstration and validation of safety. The proposed model was
refined and validated by applying the QUALPACA Project sponsored by CONCYTEC
and UPeU, mitigating the vulnerabilities by 92.30% and a monthly velocity of 20 points
and a coding style coverage of 90%.
Keys words: Web Security, SSE-CMM/ISO 21827, OWASP, Security risk, Attack,
Vulnerability.
1
1 CAPÍTULO 1
INTRODUCCIÓN
En los últimos años, el interés en la seguridad del software se ha ido
incrementando, surgiendo muchas investigaciones sobre el tema, pero aún falta
lograr la aplicación e implementación de estas investigaciones, lo cual deja abiertos
ámbitos de trabajo en torno al tema (Tovar E y colaboradores, 2006).
Los errores de software representan una constante amenaza para los sistemas
de información, ya que provocan pérdidas incontables en cuanto a la productividad.
La complejidad de los requisitos y el tamaño cada vez mayores de los programas,
aunados a las exigencias de una entrega oportuna en los mercados, han contribuido
al incremento de fallas o vulnerabilidades de software (Laudon K y Laudon J, 2012).
La tendencia marcada de las plataformas de software como un servicio en línea
(SaaS, por sus siglas en inglés) basado en la nube está desplazando a las
plataformas de software tradicionales. En el 2010, las empresas estadounidenses
invirtieron $29 millones de dólares (10 por ciento de la inversión total en software) en
SaaS (BEA National Income and Product Accounts, 2010 y Gartner Group, 2010
citado por Laudon K y Laudon J, 2012).
Siendo la seguridad de software, un aspecto que debe tener en cuenta tantos
mecanismos de seguridad como el diseño de la seguridad que dificulten los ataques
al software, debe ser considerada como una propiedad emergente de un sistema de
software e incorporarse desde el principio (Gasca G, 2006)
Estas vulnerabilidades se incrementan para las aplicaciones web debido al
entorno donde se ejecutan. Para alcanzar una aplicación web segura es necesario
tener fundamentos sólidos y la experiencia para la aplicación de buenas prácticas de
seguridad desde las primeras etapas del ciclo de vida del desarrollo.
Por su parte, los frameworks de programación web tradicionales, y aún los
ágiles solo consideran la seguridad para vulnerabilidades básicas como la protección
de recursos o carpetas del sistema basados en roles, dejando sueltos los problemas
de seguridad más comunes de la web y de la nube, siendo necesaria un modelo
práctico que integre las buenas prácticas de seguridad en componentes de
2
seguridad, proporcionando un estilo de codificación que muestre el uso de los
componentes de seguridad y otros utilitarios para el trabajo inicial y repetitivo de toda
aplicación web enmarcados en un módulo inicial, comúnmente denominado el
módulo backend, para así contrarrestar los riegos de la información que una
aplicación maneja sobre la Internet. Esta estrategia permite asignar directamente las
tareas de desarrollo que el negocio requiere de modo que resulte simple, de menos
a más y natural para el desarrollador.
El propósito de esta investigación es elaborar un modelo de trabajo práctico
para desarrollar aplicaciones web seguras (menores vulnerabilidades) y en el menor
tiempo basadas en los procesos de la metodología SSE-CMM/ISO 21827, el
Proyecto OWASP y experiencias vividas, proporcionando las plantillas de los
entregables para cada fase del modelo. La implementación de los Componentes de
seguridad se desarrolló para el lenguaje de programación ágil Python, liberándose la
primera versión de un backend de administración de aplicaciones web totalmente
responsivas denominada Backengo (versión actual). Este módulo integra los
recursos de seguridad y otros componentes necesarios para desarrollar una
aplicación web moderna, confiable y en el menor tiempo.
A fin de ilustrar la contribución del modelo propuesto, se presenta el caso de
su aplicación en el Desarrollo del proyecto denominado “Desarrollo de plataforma
tecnológica en la web para la competitividad de la cadena productiva de alpacas en
la región puno (Qualpaca)” patrocinado por el Consejo Nacional de Ciencia,
Tecnología e Innovación del Perú (CONCYTEC) y por la Universidad Peruana Unión
(UPeU) Filial Juliaca. Se determina si el equipo ejecutó el modelo definido
correctamente y en qué medida se mejoró la seguridad de la aplicación.
Con un modelo de trabajo definido para el Desarrollo de Aplicaciones Web
Seguras permitirá al equipo de desarrollo construir aplicaciones confiables y entregar
durante el primer mes funcionalidades importantes del negocio a los clientes junto
con la documentación necesaria del proyecto.
El informe de tesis está compuesta por 8 capítulos: en el capítulo 1, se describe
la problemática, la justificación, el objetivo del trabajo de investigación y la estructura
del documento de tesis. En el capítulo 2, se revisa los antecedentes y se explica
brevemente la teoría de las partes principales de esta tesis. En el Capítulo 3, se
describe el método utilizado y las herramientas para el desarrollo de la presente
investigación. En el Capítulo 4, se diseña y se desarrolla el modelo de seguridad
propuesto. En el Capítulo 5 y 6, se valida el modelo mediante el desarrollo de una
3
aplicación web tipo SaaS. En el capítulo 7 se presentan y se discuten los resultados
y en el Capítulo 8, se detallan las conclusiones y recomendaciones realizadas al
presente trabajo de investigación.
4
2 CAPÍTULO 2
REVISIÓN BIBLIOGRÁFICA
En este capítulo se presenta los conceptos relativos a la calidad y seguridad
del software como premisas para la elaboración de la propuesta de esta tesis. Otros
conceptos generales puede revisarse en el Glosario. Seguidamente se revisa las
investigaciones o modelos respecto a la seguridad del software y de aplicaciones
web entre ellos SSE-CMM y OWASP. Finalmente, se explica los métodos ágiles de
desarrollo de software.
2.1 Marco conceptual
2.1.1 Modelo de procesos del software
Según Somerville (2005), un modelo de procesos del software es una
descripción simplificada de un proceso del software que presenta una visión de ese
proceso. Estos modelos pueden incluir actividades que son parte de los procesos y
productos de software y el papel de las personas involucradas en la ingeniería del
software.
2.1.2 Taxonomía de la seguridad
Bashir (citado por Vega V y otros 2006), clasifica el concepto de seguridad en
múltiples dimensiones, entre las que destacan:
Autentificación: Verificar la identificación de los usuarios, es decir, que quien
se está conectando sea quien dice ser.
Control de Acceso: Regulación de los privilegios de los usuarios, que cada
usuario pueda realzar sólo las tareas que le corresponden.
Auditoria: Capacidad de registrar los eventos que afectan al sistema, para que
posteriormente se pueda reconstruir los estados pasados del sistema.
Confidencialidad: Evitar que ciertas entidades no autorizadas puedan acceder
a información confidencial.
Integridad: Que la información no pueda ser modificada mediante
mecanismos no permitidos.
Disponibilidad: Asegurar que el sistema estará disponible cuando el usuario
lo requiera.
5
No repudiación: Asegurar que alguna entidad que ha participado en una
comunicación, no pueda negar su intervención en ella.
Viega y McGraw (citado por Vega V y otros 2006), plantean los siguientes
objetivos de la seguridad:
Prevención. Siempre se debe anticipar a las posibles fallas de seguridad.
Trazabilidad y Auditoría. Una de las formas de recuperarse de un ataque es
conocer quién fue el atacante, qué hizo y cuándo lo hizo.
Monitoreo. Observar y monitorear constantemente el software en
funcionamiento, que permite detectar intrusiones.
Privacidad y confidencialidad. Mantener en secreto y bien resguardada la
información que maneja el sistema.
Multiniveles de seguridad. No toda la información requiere los mismos niveles
de seguridad, pero manejar esta diferencia no es una tarea difícil.
Administrar el anonimato. Este punto puede ser visto de dos aspectos, en
ocasiones es necesario que se mantenga el anonimato de los usuarios, pero
en otras ocasiones es primordial asegurar que no pueda existir anonimato en
las transacciones del sistema.
Autentificación. Este objetivo, junto a la confiabilidad y la integridad, son
considerados los más importantes. Al autentificación es un aspecto crucial
para la seguridad, dado que permite identificar con certeza quién realiza qué
en un sistema.
Integridad. Esta meta busca controlar los cambios realizados en la
información
Una taxonomía sirve como herramienta de educación y puede usarse como
lista de comprobación para tomar decisiones preventivas de la seguridad. Una
aproximación más completa del concepto de seguridad está dada por la combinación
de cuatro atributos principales: confidencialidad, integridad, disponibilidad y el no
repudio. La tabla 1 muestra una taxonomía de requisitos de seguridad
Tabla 1 – Taxonomía de requisitos de seguridad con ejemplos
Nivel 1 Nivel 2 Ejemplo de requisito de seguridad
No repudio No repudio El sistema debe conocer al cliente
antes de realizar una compra.
Confidencialidad Encriptación Encriptar la contraseña de los
usuarios
6
Autenticación No se permite retirar dinero de su
cuenta sin que este se haya
identificado.
Agregación No se permite que los cajeros
accedan al registro de ventas diarias.
Atribución El sistema deberá registrar los datos
del usuario y los cambios cada vez
que actualice el registro de notas.
Deberá registrarse los cambios
realizados en el acuerdo
previamente aprobados.
Consentimiento No se permitirá a los médicos del
centro médico a tener acceso a los
informes médicos de un paciente a
menos que el paciente ha aprobado
el acceso
Concurrencia No se permite más de dos
conexiones simultáneos para un
usuario
Seguimiento No se proveerá información a
aquellos usuarios que previamente
han accedido a información de otra
organización del mismo conflicto de
interés.
Integridad Edición La actualización del precio de venta
solo lo hace el contador
Eliminación El sistema no debe permitir la
eliminación de artículos
Validación de datos Aceptar solo datos numéricos
positivos para el precio de venta de
los artículos
Manejo de
excepciones
El sistema no deberá mostrar el
detalle del error al usuario.
Pre-requisitos No se permite al usuario sacar dinero
de su cuenta antes de que el sistema
7
comprueba la disponibilidad de
fondos
Separación de roles No permitirá que el comprador utilice
la opción de pagos del sistema
Disponibilidad Tiempo de respuesta Se deberá proporcionar la
información del estudiante para el
99% de sus solicitudes
Expiración Reducir el tiempo de solicitud de
conexión para tener tiempo de
espera de 1 minuto cuando el
número de solicitud de conexión es
superior a 10,000 por hora
Asignación de
recursos
El tamaño límite de un archivo debe
ser de 10MB.
Fuente: Calderón M (2007)
2.1.3 Software
Según Pressman (2004), el software es un elemento del sistema que es lógico,
como son las instrucciones (programas) quienes serán el medio de interacción entre
el factor humano y el hardware correspondiente a un sistema de información.
2.1.4 Ingeniería del software
Según Somerville (2005), la ingeniería del software es una disciplina de la
ingeniería que comprende todos los aspectos de la producción del software desde
las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste
después de que se utiliza. En síntesis, la ingeniería de software no solo está dedicada
al desarrollo del software, sino también hacia diferentes etapas durante su ciclo de
vida.
2.1.5 Software como un servicio (SaaS)
Un software as a service, es un modelo de distribución de software donde el
soporte lógico y los datos que maneja se alojan en servidores de una compañía de
tecnologías de información y comunicación (TIC), a los que se accede vía Internet
desde un cliente. La empresa proveedora TIC se ocupa del servicio de
mantenimiento, de la operación diaria y del soporte del software usado por el cliente.
Regularmente el software puede ser consultado en cualquier computador, se
encuentre presente en la empresa o no. Se deduce que la información, el
8
procesamiento, los insumos, y los resultados de la lógica de negocio del software,
están hospedados en la compañía de TIC.
2.1.6 Seguridad del software
Tovar E y colaboradores, 2006, afirma que la seguridad del software es una
idea de la Ingeniería de Software que busca que un producto desarrollado continúe
funcionando correctamente ante ataques maliciosos, y puede ser vista como una
medida de robustez de un sistema de software, respecto a una política de seguridad.
Es decir, que la raíz de muchos problemas de seguridad está en que el software falla
de forma inesperada.
La seguridad de un software es una combinación de su capacidad para
asegurar la disponibilidad de la aplicación, la integridad y confidencialidad de los
Datos. De esta forma, una falla del software en proteger cualquiera de esas
características implica una violación de seguridad o vulnerabilidad (M-Tech Identity
Management Suite 2008).
2.1.7 Aplicaciones web
Las aplicaciones web son generalmente vistas en un browser. Una aplicación
tiene 2 partes:
FrontEnd (Browser), es con lo que se encontrará el usuario final, esta interfaz
es el browser. El browser/navegador es clave ya que este nos puede dar la
posibilidad de crear aplicaciones complejas como también restringirnos (Internet
Explorer 6/7). Las aplicaciones deberán estar escritas en
HTML/JS/CSS/AJAX/JQUERY/etc., o Flash/Flex, o Java FX, o Silverlight etc.
BackEnd (Server), es el motor de estas aplicaciones web y casi siempre utilizan
una base de datos para el almacenaje de datos. Los lenguajes de programación son
variados en el backend, si el lenguaje de programación puede generar un script
HTML entonces ya puede ser considerado un lenguaje web. Ejemplos: PHP, MySQL,
XML, JSON, etc.
2.1.8 Desarrollo web
Desarrollo Web es un término utilizado para definir todo el trabajo de creación
de una página web. Desarrollo Web puede abarcar desde una simple página estática
hasta aplicaciones web bastante más complejas, tales como redes sociales como
facebook, páginas de e-commerce como ebay, aplicaciones móviles como google
maps, entre otros.
9
2.1.9 Análisis de riesgo
El análisis de riesgos, consiste en identificar los riesgos de seguridad en la
organización, determinar su magnitud e identificar las áreas que requieren implantar
salvaguardas (INTECO, 2014).
El análisis de riesgo, tiene como propósito determinar los componentes de un
sistema que requieren protección, sus vulnerabilidades que los debilitan y las
amenazas que lo ponen en peligro, con el fin de valorar su grado de riesgo. El anexo
A2 se muestra un ejemplo de la matriz de riesgos con sus principales características.
El análisis del riesgo, es el uso sistemático de la información para identificar las
fuentes y calcular o evaluar el riesgo (ISO 27001:2005)
Evaluación del riesgo, es el proceso de comparar el riesgo estimado con un
criterio de riesgo dado para determinar la importancia del riesgo (ISO 27001:2005)
Amenaza, es una causa potencial de un incidente no deseado, el cual resulta
en daño a un sistema u organización (ISO 17799:2005)
Vulnerabilidad, es la debilidad de un activo que puede ser explotada por una o
más amenazas (ISO 17799:2005)
Controles (o contramedidas o salvaguardas), son medios para manejar el
riesgo, incluyendo políticas, procedimientos, lineamientos, prácticas o estructuras
organizacionales, las cuales pueden ser administrativas, técnicas, de gestión o de
naturaleza legal (ISO 17799:2005)
2.2 Revisión del estado del arte
2.2.1 Modelos de calidad del software en sintonía con la Seguridad
La calidad es el grado en el que un conjunto de características inherentes
(propio) cumple con los requisitos o expectativa establecida (ISO 9000:2005).
La calidad total no es tan solo realizar las cosas bien hechas sino que es
mejorarlas constantemente, así el aseguramiento de calidad del software viene a ser
el conjunto de actividades de supervisión del desarrollo del software y de su
rendimiento (en distintas oportunidades durante cada fase del ciclo de vida) para
satisfacer los requisitos dados de calidad, siendo el equipo de desarrollo el
responsable por el resultado de calidad del software.
Gasca G, 2006, afirma que los modelos de calidad permiten precisar conceptos
dada la utilidad para planificar y obtener índices de calidad, puesto que ayudan en la
puesta en práctica los conceptos generales por medio de definiciones de tipo
10
operacional. Considerando los diferentes enfoques de varios modelos de calidad, la
tabla 2 resume las características bajo los parámetros de la seguridad del software
de cada uno de ellos.
Tabla 2 – Sintonía de la seguridad con los modelos de calidad
Modelo de
calidad o
estándar
Dimensión con la seguridad Objetivos de seguridad
Modelo de
McCall
Comprendido por tres ejes, dentro
de los que se encuentra la
operación del producto, para el
cual está establecido el factor
integridad, único factor dentro del
modelo, que superficialmente
toma este concepto de seguridad.
Aunque dentro de sus
objetivos la calidad del
software prima sobre
cualquier otro, la seguridad
del software no se tiene en
cuenta como un factor o
característica de la calidad
que permita asegurar que
dicho modelo contempla de
forma efectiva la seguridad
del software.
Modelo de
Boehm
La principal característica del
modelo es su orientación de la
calidad, sin embargo dentro de los
siete factores definidos la
seguridad está mínimamente
mencionada, pero se resalta la
definición de un factor de la
Facilidad de Pruebas ya que esta
característica es recomendable
como una buena práctica del
desarrollo del software seguro.
Su objetivo está orientado
al desarrollador, sin
embargo dentro de los
factores definidos la
seguridad no se encuentra
mencionada como un factor
de calidad aunque dentro
de las características se
plantea dentro de los
conceptos básicos como
confidencialidad e
integridad
Modelo de
Gilb
Aunque es un modelo orientado a
la calidad industrial, los aspectos
que proponen son pasos amplios
y con cierta flexibilidad para
encontrar su aplicabilidad dentro
El modelo no tiene definido
dentro de sus objetivos y
fines la seguridad del
software de forma
específica, sin embargo;
11
de la seguridad y aplicarla al
software.
por la generalidad de su
propuesta, los aspectos
definidos permiten enfocar
la seguridad del software.
Paradigma
GQM
La valoración de defectos es uno
de los fines de este modelo, por lo
tanto la seguridad está
involucrada desde una dimensión
posterior a la que se quiere
plantear, la medición dentro de
este paradigma se plantea
posterior a los defectos
producidos.
El paradigma introduce
conceptos y aspectos útiles
sobre la seguridad del
software, sin embargo; esta
característica está siendo
utilizada a posteriori y los
conceptos bajo los cuales
se estudia la seguridad en
este documento, invitan a
contemplar la seguridad en
etapas tempranas de ciclo
de vida de desarrollo de un
producto
Estándar ISO
9126
El modelo define la calidad del
software bajo características
como la funcionalidad dentro de la
cual el concepto de seguridad se
tiene en cuenta como un atributo
importante para impedir acceso
no autorizado, fortuito o
deliberado, a programas y datos;
que aunque no trasciende a los
conceptos de seguridad
relevantes para garantizar un
desarrollo de software seguro, el
estándar involucra la seguridad
dentro de su estructura.
La seguridad del software
está contemplada en el
modelo dentro de las
características de
funcionalidad y la filosofía
del modelo canaliza el
planteamiento de calidad
con una perspectiva de
seguridad más amplia que
los modelos hasta ahora
mencionados, de forma que
este estándar apoya la
implementación de buenas
prácticas dentro del
desarrollo de software
seguro.
Modelo CMM La representación por etapas del
modelo permite tener una
representación continua y flexible
Es un modelo que
suministra a las
organizaciones una
12
de acercamiento a la mejora de
procesos. Esta representación
organiza las áreas de proceso en
cinco niveles de madurez para
apoyar y guiar el proceso de
mejora; sin embargo
específicamente el manejo de la
seguridad se encuentra
diseminado en todas las etapas y
carece de la profundidad
necesaria para garantizar los
procesos de desarrollo de
software seguro.
orientación eficaz para
establecer el proceso de
mejora de sus programas,
pero dentro de su filosofía;
el aspecto de seguridad
está levemente inmerso
como una sub-
característica de la calidad.
Modelo
SPICE
Contiene una estructura
compuesta por nueve partes y su
filosofía es determinar la
capacidad de los procesos y
mejora de los mismos en el marco
de las características de calidad,
por lo cual la seguridad está
dentro de este concepto, sin
embargo como los demás
modelos, su enfoque no define
dimensiones de seguridad
necesarias para el desarrollo de
software seguro.
El modelo contempla los
procesos de software y
considera las iniciativas de
estandarización existentes
como el caso de CMM,
construido por especialistas
que han trabajado con
métodos y normas
existentes, pero dentro de
su objetivo general; no se
encuentra la seguridad del
software específicamente.
Fuente: Gasca G (2006)
2.2.2 Modelo de McGraw con la construcción de software seguro
McGraw (citado por Vega V y otros 2006), indica que la base de los problemas
de seguridad son la conectividad, la complejidad y la extensibilidad de los sistemas
actuales. La afirmación anterior se refiere a que actualmente la mayoría de los
productos de software están disponibles en un medio tan abierto como internet
(conectividad), y además estos mismos productos son parte de sistemas complejos
que apoyan objetivos de negocios que no son simples ni aislados (complejidad) y que
al mismo tiempo estos objetivos de negocios deben irse adecuando a los constantes
cambios que exigen los mercados actuales (extensibilidad). Como resultado de lo
13
anterior, los problemas de seguridad del software se han ido incrementando, llegando
en ocasiones, incluso a poner en riesgo el éxito y sobrevivencia de las
organizaciones.
Los aspectos de seguridad en la ingeniería de software, van más allá de la
construcción del producto y trascienden dentro del proceso de software, de ahí que
la preocupación de diferentes organizaciones expresen el interés por crear y
proponer estándares, metodologías y métodos que contemplan la seguridad desde
el punto de vista del proceso y la enmarquen como una característica de calidad del
software importante para su desarrollo, es el caso del planteamiento de la norma ISO
9126, un estándar internacional para la evaluación de la calidad de productos de
software, con el nombre “Information Technology – Software Product Evaluation –
Quality Characteristics and Guidelines for their use”.
Bajo esta misma perspectiva, y teniendo en consideración que los productos
software son parte del inventario de tecnología de la información que las
organizaciones poseen, el presente trabajo analiza el modelo SSE-CMM y OWASP
para determinar un modelo base y las vulnerabilidades existentes para el desarrollo
de aplicaciones web seguras.
2.2.3 SSE-CMM/ISO 21827, COBIT e ITIL en relación a la seguridad del
software
Tovar E y colaboradores, 2006, analizaron los modelos SSE-CMM, COBIT E
ITIL para determinar cómo se enlazan y reafirman las propuestas existentes para el
desarrollo de productos de software seguro.
Systems Security Engineering Capability Maturity Model (SSE-CMM/ISO
21827), es un modelo de referencia para la incorporación de la Ingeniería de
Seguridad en las organizaciones. SSE-CMM divide la ingeniería de seguridad en tres
áreas básicas: riesgo, ingeniería y aseguramiento. La relación de estas áreas con el
objetivo del presente artículo está dada por los siguientes argumentos:
Riesgo, busca identificar y priorizar los peligros asociados al desarrollo de
productos o sistemas.
Ingeniería, trabaja con otras disciplinas para implementar soluciones a los
peligros identificados, en este caso, se relaciona con la Ingeniería de
Software.
14
Aseguramiento, tiene como objetivo certificar que las soluciones
implementadas son confiables.
El modelo se estructura en dos dimensiones: Dominios y capacidades. Un
dominio es un conjunto de prácticas básicas que definen la ingeniería de seguridad,
mientras que una capacidad se refiere a las prácticas genéricas que determinan la
administración del proceso e institucionalizan la capacidad. Existen veintidós áreas
de proceso que contienen ciento veintinueve prácticas básicas. La tabla 3 destaca
las áreas de procesos que apoyan el desarrollo de software seguro.
Tabla 3 – Seguridad y SSE-CMM
Área de proceso Aporte a la seguridad del software
PA03. Valoración de
riesgos de seguridad
El conocimiento adquirido en esta área de proceso
puede ser utilizado para el desarrollo del análisis de
riesgos que pueden afectar al software, práctica
recomendada para el desarrollo de productos seguros
PA10. Especificar
necesidades de
seguridad
Esta área de proceso puede ser utilizada en la
Ingeniería de Requerimientos de Seguridad, para
determinar los aspectos de seguridad que deben ser
incorporados al nuevo producto
PA11. Verificación y
Validación de la
Seguridad.
Puede utilizarse para la generación de pruebas de
seguridad que deben aplicarse a los productos
software
PA17. Definir el Proceso
de Ingeniería de Sistemas
organizacional.
Aporta en la definición de procesos claros que
incorporan la seguridad en todas las dimensiones
PA18. Mejorar el Proceso
de Ingeniería de Sistemas
organizacional.
SSE-CMM define 5 niveles de madurez, por lo cual, la
mejora de los procesos debe ser continua para
alcanzar el siguiente nivel, lo que puede ser un aporte
en la incorporación gradual de prácticas de desarrollo
de software seguro
Fuente: Tovar E y colaboradores (2006)
Control Objetives for Information and related Technology (COBIT). El objetivo
de este framework es organizar y armonizar distintos estándares internacionales,
relacionados con la administración de la Tecnología de la Información en las
15
organizaciones. COBIT presenta un conjunto de mejores prácticas, enfocadas en el
control más que en la ejecución, que permiten optimizar la inversión en TI que una
organización realiza. Este modelo define un conjunto de criterios de control, en base
a requisitos de calidad, confianza y seguridad.
Dado que los sistemas de información, y sus productos software asociados,
son parte de los bienes tecnológicos que una organización posee, por lo tanto, existe
una relación y aporte entre la administración de la TI y las propuestas de desarrollo
para software seguro.
Este modelo se organiza en función de cuatro dominios, los que a su vez se
dividen en procesos formados de actividades específicas, que definen los objetivos
de control que una organización debería implementar. Las tablas 4, 5 y 6 (Una por
cada dominio de interés) muestran los procesos específicos a considerar durante la
implementación de software.
Tabla 4 – Seguridad y COBIT, dominio planear y organizar
Área de proceso Aporte a la seguridad del software
PO6. Comunicar las
aspiraciones y
directrices de la
Administración.
Dado que la incorporación de prácticas específicas para
el desarrollo de software seguro debe ser un compromiso
de todo el equipo, este proceso puede ayudar a que la
Administración defina explícitamente políticas de
seguridad y su compromiso con la calidad
PO8. Administrar la
Calidad.
Este conocimiento es un aporte, dado que la seguridad
es un atributo de calidad de los productos software, por lo
cual deben existir estándares de desarrollo que
incorporen los objetivos de seguridad desde etapas
tempranas
PO9. Valoración y
administración de
riesgos.
Es un aporte para la aplicación de la práctica de análisis
de riesgo, recomendada para la seguridad del software
Fuente: Tovar E y colaboradores (2006)
16
Tabla 5 – Seguridad y COBIT, dominio adquirir e implementar
Área de proceso Aporte a la seguridad del software
AI2. Adquirir y
mantener
aplicaciones
software.
Todo el conocimiento y experiencia de este proceso puede
ser utilizado y complementado con las nuevas propuestas de
desarrollo de software seguro
AI7. Instalación y
acreditación de
soluciones y
cambios.
Relacionado con los procedimientos de aceptación de los
nuevos productos, puede aportar a explicitar las pruebas de
seguridad
Fuente: Tovar E y colaboradores (2006)
Tabla 6 – Seguridad y COBIT, dominio entrega y soporte
Área de proceso Aporte a la seguridad del software
DS2.Administración
de servicios
prestados por
terceros.
Este punto puede ser complementado con normas y
controles explícitos para el momento exteriorizar el
desarrollo de software.
DS5. Garantizar la
seguridad de los
sistemas.
Es muy importante que se declare explícitamente la
preocupación por la seguridad, lo cual es un aporte a todas
las nuevas propuestas de seguridad del software.
DS10.
Administración de
problemas.
Los problemas de fallas de seguridad de software son parte
del conocimiento histórico que todos los desarrolladores de
software de la organización deberían tener a su disposición,
de manera tal, de evitar la repetición de errores cometidos,
en este aspecto, se debe aprovechar este proceso COBIT
Fuente: Tovar E y colaboradores (2006)
Information Technology Infraestructure Library (ITIL), ofrece un marco común
para todas las actividades del departamento TI, como parte de la provisión de
servicios, basado en la infraestructura tecnológica. Estas actividades se dividen en
procesos, que proporcionan un marco eficaz para lograr una Gestión de Servicios de
Tecnologías de la Información más madura. Proporciona una descripción detallada
de una serie de buenas prácticas, a través de una amplia lista de roles, tareas,
17
procedimientos y responsabilidades que pueden adaptarse a cualquier organización
de TI.
Los procesos que esta librería describe, bajo los cuales muestra que son
requeridos para el manejo eficiente y efectivo de la infraestructura tecnológica,
existen aquellos que velan por la disponibilidad de los activos de información como
requiere la organización y los demás que apoyan y facilitan la gestión de funciones y
actividades de seguridad como el tratamiento y solución de problemas,
implementación de controles y políticas necesarias dentro de la organización. Por lo
tanto la Tabla 7, de forma general, se presentan la relación entre el modelo que
plantea ITIL y los aspectos que se consideran más relacionados con la seguridad,
teniendo en cuenta que ITIL suministra un conjunto extenso y coherente de buenas
prácticas para la dirección del servicio de informática y los procesos relacionados,
promoviendo un enfoque de calidad para conseguir la eficacia de la empresa y la
eficiencia en el uso de TI, por lo tanto dentro de dicha calidad hacia la eficacia se
encuentra contemplada la seguridad.
Tabla 7 – Seguridad e ITIL
Librería Aporte a la seguridad del software
Soporte del Servicio: En
los aspectos
relacionados con la
Gestión de Incidentes y
Gestión de Problemas
Permiten la implementación de controles de
seguridad con el fin de mantener los aspectos
tecnológicos de la organización, lo cual podría ser
adaptado para el desarrollo de software
Provisión del Servicio: En
cuanto a los aspectos de
Gestión de Disponibilidad
y Gestión de Continuidad
de Servicios.
Influyen de forma directa con los objetivos de
seguridad, cuando se definen dentro de la
organización y se asegura la demanda que requiere
el negocio en cuanto a los activos tecnológicos que
tiene y requiere para el desempeño de sus
actividades. Esto es un aporte dado que los
productos software son un activo tecnológico.
Fuente: Tovar E y colaboradores (2006)
Tanto como SSE-CMM, COBIT e ITIL, incorporan la seguridad desde distintas
perspectivas, algunas de las cuales son coincidentes y otras complementarias. A
partir de estas singularidades y similitudes se puede determinar una definición
multidimensional de la seguridad en relación al desarrollo de software.
18
Tovar E y colaboradores (2006), concluyen que los problemas de seguridad no
se solucionan incorporando mecanismos de protección externos al producto de
software, más bien, para conseguir que un producto de software sea seguro durante
su explotación y vida útil, se deben considerar durante su desarrollo las siguientes
dimensiones:
Proceso utilizado para el desarrollo del producto.
Factores humanos relacionados con las habilidades y conocimientos que
deben poseer los equipos desarrolladores.
Prácticas organizacionales declaradas e instauradas que deben respetarse y
aplicarse, y
Productos obtenidos, para cada uno de los cuales se debe realizar una
rigurosa validación y verificación que cumple con los estándares y requisitos
de seguridad declarados
La figura 1 esquematiza los puntos coincidentes entre los modelos en relación
al desarrollo de software seguro y las dimensiones identificadas.
Figura 1 – Aspectos coincidentes entre SSE-CMM, COBIT e ITIL en relación a
la seguridad del software.
Fuente: Tovar E y colaboradores (2006)
COBIT
ITIL
SSE-CMM
Definición prácticas de
seguridad
Niveles de madurez
Necesidad de
definición
Modelos software
Administración
productos software
Definición explícita
requerimientos de
seguridad
19
El aspecto coincidente en todos los modelos, es el planteamiento de lo
importante que es que las organizaciones declaren explícitamente los requerimientos
de seguridad que apoyarán el logro de sus objetivos de negocio. Esto debe ir
acompañado de prácticas de seguridad bien definidas, conocidas, respetadas y
aplicadas por todos los integrantes de la organización.
Los modelos COBIT y SSE-CMM definen un conjunto de prácticas que
deberían tenerse en consideración. Este aspecto aporta a la dimensión de Prácticas
Organizacionales definida previamente. Tanto SSE-CMM como COBIT plantean la
necesidad que existan procesos de desarrollo de software que estén claramente
definidos. Este aspecto ayuda a la dimensión Proceso mencionada previamente. Las
organizaciones interesadas en incorporar esta dimensión, deben aplicar las
propuestas existentes respecto al desarrollo de software seguro.
Los modelos COBIT e ITIL, aportan a la dimensión Producto, desde la
perspectiva que ambos definen cómo administrar los productos correspondientes a
TI. La dimensión de Factores Humanos, se ve beneficiada por el modelo SSE-CMM,
donde se presentan una serie de procesos que deberían ser desarrollados en las
organizaciones para incorporar la seguridad, justificando la necesidad de que existan
Ingenieros de Seguridad, que trabajen en conjunto a los otros dominios de la
Ingeniería, en especial con los Ingenieros de Sistemas e Ingenieros de Software.
El modelo SSE-CMM, plantea la existencia de distintos niveles de madurez que
puede alcanzar una organización en relación a sus prácticas de seguridad, aspecto
que influye en las cuatro dimensiones de seguridad planteadas.
2.2.4 Guía OWASP
El proyecto abierto de seguridad en aplicaciones web (OWASP por sus siglas
en inglés) ofrece un punto de partida para identificar riesgos en el desarrollo de
sistemas y asegura que aplicaciones hechas a medida o adquiridas complementen
con COBIT. Los controles de OWASP corresponden a los objetivos COBIT y de la
ISO 17799 (OWASP, 2005).
OWASP ofrece dos publicaciones base: la Guía para construir aplicaciones
Web seguras y OWASP Top 10, así mismo ofrece los software WebGoat basada en
Java diseñada para enseñar lecciones de seguridad en aplicaciones Web a través
de lecciones en las que se simulan vulnerabilidades en un servidor, WebScarab
escrito en Java diseñada para analizar aplicaciones web que se comunica usando
los protocolos HTTP y HTTPS, oLabs Projects, y el .Net Projects. También provee un
conjunto de librerías de seguridad empresariales en Java denominada OWASP
20
ESAPI, en total para la versión del 2008 provee 49 proyectos de más de 300 páginas
cada una de ellas (OWASP, 2008).
Fernández J. (2006), explica el ciclo de desarrollo de aplicaciones y servicios
Web seguras con OWASP mediante la figura 2.
Figura 2 – Ciclo de desarrollo seguro de OWASP
Fuente: Fernández J (2006)
OWASP se basa en la ISO 17799 y COBIT para diseñar los controles de
seguridad que debe ser incluido en la aplicación, estos requisitos de seguridad los
modela como casos de abuso como se muestra en la figura 4, desligándolo de los
procesos de negocio. Luego se realiza un análisis de riesgos junto a los planes de
pruebas. Luego de diseñar la seguridad se procede a la codificación. Una vez
construida se ejecutan las pruebas y se realiza nuevamente un análisis de riesgos
identificando nuevos problemas de seguridad antes del despliegue.
Por su parte, el modelo abierto de madurez para el aseguramiento del software
(SAMM por sus siglas en inglés) es una guía más de OWASP para integrar la
seguridad en el desarrollo de software. Como modelo de madurez, provee recursos
para evaluar las prácticas de seguridad en software existentes en la organización
entre otros recursos relacionados a la seguridad del software. El modelo SAMM se
muestra en la figura 3.
21
Figura 3 – Modelo de madurez de aseguramiento de software Open SAMM
Fuente: Open SAMM (2010)
El modelo consta de tres niveles de madurez definidos para cada una de las
doce prácticas de seguridad. Estas definen una amplia variedad de actividades a las
que una organización se puede adherir para reducir los riesgos de seguridad e
incrementar el aseguramiento del Software. Se incluyen detalles adicionales para
medir el desempeño exitoso de las actividades, entender los beneficios del
aseguramiento asociado, estimar los costos de personal y otros costos.
2.2.5 Vulnerabilidades OWASP Top 10
OWASP (2013), publicó las 10 vulnerabilidades más frecuentes de las
aplicaciones y servicios Web, estas se muestran en la tabla 8.
Tabla 8 – Los diez riesgos más importantes en aplicaciones web 2013
Vulnerabilidad Descripción
A1 Inyección Las fallas de inyección, tales como SQL, OS, y LDAP,
ocurren cuando datos no confiables son enviados a un
intérprete como parte de un comando o consulta. Los datos
hostiles del atacante pueden engañar al intérprete en
ejecutar comandos no intencionados o acceder datos no
autorizados.
A2 Pérdida de
autenticación y
gestión de sesiones
Las funciones de la aplicación relacionadas a autenticación
y gestión de sesiones son frecuentemente implementadas
incorrectamente, permitiendo a los atacantes comprometer
contraseñas, llaves, token de sesiones, o explotar otras
fallas de implementación para asumir la identidad de otros
usuarios.
22
A3 Secuencia de
comandos en sitios
cruzados (XSS)
Las fallas XSS ocurren cada vez que una aplicación toma
datos no confiables y los envía al navegador web sin una
validación y codificación apropiada. XSS permite a los
atacantes ejecutar secuencia de comandos en el navegador
de la víctima los cuales pueden secuestrar las sesiones de
usuario, destruir sitios web, o dirigir al usuario hacia un sitio
malicioso.
A4 Referencia
directa insegura a
objetos
Una referencia directa a objetos ocurre cuando un
desarrollador expone una referencia a un objeto de
implementación interno, tal como un fichero, directorio, o
base de datos. Sin un chequeo de control de acceso u otra
protección, los atacantes pueden manipular estas
referencias para acceder datos no autorizados.
A5 Configuración de
seguridad
incorrecta(defectuosa
configuración de
seguridad, 2010)
Una buena seguridad requiere tener definida e
implementada una configuración segura para la aplicación,
marcos de trabajo, servidor de aplicación, servidor web,
base de datos, y plataforma.
Todas estas configuraciones deben ser definidas,
implementadas, y mantenidas ya que por lo general no son
seguras por defecto. Esto incluye mantener todo el software
actualizado, incluidas las librerías de código utilizadas por la
aplicación.
A6 Exposición de
datos sensibles
(almacenamiento
criptográfico
inseguro, 2010)
Muchas aplicaciones web no protegen adecuadamente los
datos sensibles, tales como tarjetas de crédito y
credenciales de autenticación con mecanismos de cifrado o
hashing. Atacantes pueden modificar o robar tales datos
protegidos inadecuadamente para conducir robos de
identidad, fraudes de tarjeta de crédito u otros crímenes.
A7 Ausencia de
control de acceso a
las funciones (falla de
restricción de acceso
a URL, 2010)
Muchas aplicaciones web verifican los privilegios de acceso
a URLs antes de generar enlaces o botones protegidos. Sin
embargo, las aplicaciones necesitan realizar controles
similares cada vez que estas páginas son accedidas, o los
atacantes podrán falsificar URLs para acceder a estas
páginas igualmente.
A8 Falsificación de
peticiones en sitios
cruzados (CSRF)
Un ataque CSRF obliga al navegador de una víctima
autenticada a enviar una petición HTTP falsificado,
incluyendo la sesión del usuario y cualquier otra información
23
de autenticación incluida automáticamente, a una aplicación
web vulnerable. Esto permite al atacante forzar al navegador
de la víctima para generar pedidos que la aplicación
vulnerable piensa son peticiones legítimas provenientes de
la víctima.
A9 Uso de
componentes con
vulnerabilidades
conocidas
Algunos componentes tales como las librerías, los
frameworks y otros módulos de software casi siempre
funcionan con todos los privilegios. Si se ataca un
componente vulnerable esto podría facilitar la intrusión en el
servidor o una perdida seria de datos. Las aplicaciones que
utilicen componentes con vulnerabilidades conocidas
debilitan las defensas de la aplicación y permiten ampliar el
rango de posibles ataques e impactos.
A10 Redirecciones y
reenvíos no validados
Las aplicaciones web frecuentemente redirigen y reenvían a
los usuarios hacia otras páginas o sitios web, y utilizan datos
no confiables para determinar la página de destino. Sin una
validación apropiada, los atacantes pueden redirigir a las
víctimas hacia sitios de phishing o malware, o utilizar
reenvíos para acceder páginas no autorizadas.
Fuente: OWASP Top 10 (2013)
2.2.6 Microsoft SDL
El método de Microsoft, denominado Ciclo de Vida de Desarrollo Seguro [SDL]
del 2004, es un proceso para el desarrollo de software que tiene que resistir el ataque
malévolo de un intruso. El proceso consiste de una serie de actividades de seguridad:
El desarrollo de modelo de amenaza durante el diseño de software.
El empleo de instrumentos de exploración de código de análisis estáticos.
Las pruebas de seguridad durante la integración de seguridad.
La revisión final de seguridad por un equipo independiente.
La integración de las medidas de seguridad descritas por el método SDL se
muestra en la Figura 4.
24
Security training Use security
development
tools &
security best
dev, test
practices
Create
security
documenta
tion an
tools for
product
Prepare
security
response
plan
Security
push
Security
service
and
response
execution
Security
Kickoff
Security
design
best
practices
Security
Architecture
Threat
modeling
Pen
testing
Figura 4 - Vista general del método SDL
Fuente: Ardi S y Shahmehri N (2008)
En este proceso, durante la fase de requerimientos, el equipo de proyecto y el
de seguridad colaboran en la planificación del proceso. En el diseño dividen en fases:
Diseño de la seguridad, la arquitectura de seguridad y el modelado de amenaza. En
la implementación, se aplican los estándares de codificación y pruebas. En la
verificación, incluyen revisiones de código de seguridad, así como la realización de
pruebas de seguridad. En la fase de lanzamiento, el software es sujeto a una
seguridad final y luego estará listo a ser entregado. Según el SDL, después del
despliegue, el equipo debe estar preparado para responder a vulnerabilidades recién
descubiertas en el producto de software. Esto es no siempre una solución aceptada
por organizaciones. SDL recomienda el apoyo de seguridad a la fase de
mantenimiento pero no es claro como este apoyo es realizado y como nuevas
vulnerabilidades son descubiertas y mitigadas. En otras organizaciones requiere el
reemplazo completo del proceso de desarrollo. (Ardi S y Shahmehri N, 2008).
2.2.7 SDL-Agile
A diferencia del SDL clásico, donde todos estos requisitos deben ser
completados antes de que el producto sea liberado, en SDL Agile sólo uno de los
requisitos de cada cubo se debe completar en cada sprint. Esta es la concesión que
SDL Agile hace a los horarios de liberación más corto de los proyectos de desarrollo
Agile. Como se suele decir, no puede caber diez libras de harina en una bolsa de
cinco libras, y los requisitos del cubo son los cinco kilos de más que se ha sacado.
La figura 5 muestra el flujo de de trabajo del método SDL Agile.
The every-sprint requirements Security verification bucket Design review bucket Response planing bucket
Threat model
Use validate request
And so on
Fuzz file inputs
Run AppVerif
And so on
Review crypto design
Privacy review
And so on
Disaster recovery plan
Update response contacts
And so on
Figura 5 – Ciclo de vida de SDL-Agile
Fuente: Microsoft (2011)
Requirements Design Implementation Verification Release Support
25
Sin embargo, a pesar de que los equipos de producto no son necesarios para
completar todos los requisitos del cubo en cada sprint, eso no significa que se puede
omitir de forma indefinida. De hecho, los equipos tienen que completar cada uno de
los requisitos del cubo por lo menos una vez al año. Además, los equipos se les
prohíbe completar el requisito de mismo cubo en dos carreras en una fila. Por
ejemplo, si el equipo del proyecto X elige para completar un análisis de la superficie
de ataque para satisfacer sus requisitos de verificación de seguridad para su cubo
de marzo de sprint, que no puede completar otro análisis de la superficie de ataque
en abril. Más concretamente, se podría completar otro análisis de la superficie de
ataque en abril si de verdad quería, sin embargo, simplemente no podría satisfacer
su compromiso de SDL.
Aparte de esas dos limitaciones, los equipos son libres de elegir lo que quieren
los requisitos del cubo para completar en cualquier sprint dado. SDL Agile no obliga
a ningún tipo de orden de selección de requerimiento. Este producto ofrece a los
equipos la máxima flexibilidad en la elección de las actividades de seguridad que se
encuentran más útiles.
2.2.8 Sustainable software security process (S3P)
Ardi S y Shahmehri N (2008) desarrollaron el método denominado proceso
sostenible de software seguro [S3P], creando un plug-in para integrar la seguridad
en el proceso de desarrollo de software para el OpenUP/Basic. Este proceso provee
criterios para la identificación de las causas de las vulnerabilidades y técnicas de
mitigación que previenen estas vulnerabilidades. La integración del S3P con el
OpenUP se muestra en la figura 6.
Figura 6 - Vista general del método S3P
Fuente: Ardi S y Shahmehri N (2008)
El S3P consiste en tres pasos principales: comienza con el modelo de
vulnerabilidades basadas en un análisis cuidadoso de vulnerabilidades de software
para identificar las causas. Los resultados de este análisis son usados en el segundo
26
paso para identificar las técnicas de mitigación que eliminan las causas de las
vulnerabilidades. Las técnicas de mitigación entonces son usadas en el tercer paso
para definir componentes de proceso de desarrollo en forma de actividades para ser
aplicadas en el desarrollo. El S3P mejora el proceso de desarrollo previniendo la
repetición de problemas de seguridad y vulnerabilidades, almacenándolos en una
base de datos de vulnerabilidades que proporciona la información sobre las clases
de vulnerabilidades y tipos de errores generales; el S3P puede ser aplicado en el
proceso OpenUP
2.2.9 Controles de seguridad de ISO 27001
La ISO/IEC 27001 es la única norma internacional auditable que define los
requisitos para un sistema de gestión de la seguridad de la información (SGSI). La
norma se ha concebido para garantizar la selección de controles de seguridad
adecuados y proporcionales. Ello ayuda a proteger los activos de información y
otorga confianza a cualquiera de las partes interesadas, sobre todo a los clientes. La
norma adopta un enfoque por procesos para establecer, implementar, operar,
supervisar, revisar, mantener y mejorar un SGSI (ISO 27001, 2005).
Para la implementación del SGSI, la ISO 27001 adopta la metodología PDCA
mostrado en la figura 7.
Figura 7 – Proceso de la norma ISO/IEC 27001:2005
Fuente: ISO 27001 (2005)
El objetivo de la fase de planificación (Plan) es establecer las políticas,
objetivos, los procedimientos y los controles de seguridad descrito en la ISO/IEC
27001 previo análisis y gestión de riesgos de los activos de información. En fase de
ejecución (Do), básicamente se manejan los recursos asignados para el SGSI para
llevar a cabo la gestión de riesgos y la puesta en marcha los controles de seguridad
de la información seleccionados en la fase de planificación. En fase de monitoreo
(Check), se miden la efectividad y el éxito de los controles implantados para verificar
27
que se hayan cumplido los requerimientos de seguridad. Por ello, es muy importante
contar con registros e indicadores que provengan de estos controles. En esta fase
también se identifican nuevos riesgos, se evalúa la efectividad de la política, costes
y cambios tecnológicos. La última fase, es la fase de mejora (Act), donde se llevan a
cabo las labores de mantenimiento del sistema. Si durante la fase anterior se ha
detectado algún punto débil, este es el momento de corregirlo o mejorarlo a través
de la implementación de medidas correctoras, preventivas y de mejora identificada
en el SGSI.
Puyo R. (2009), Oficial de seguridad de la Oficina de Normalización Previsional
[ONP] del Perú, afirma que la buena aplicación de la norma requiere una adaptación
a la organización. Consecuentemente, la figura 8 y la figura 9 muestran la adaptación
de la metodología ISO 27001 a la ONP.
Figura 8 – Dominios de la norma ISO/IEC 27001:2005
Fuente: Puyo R. (2009)
28
Figura 9 – Proceso de implementación del SGSI utilizando la norma ISO/IEC
27001:2005 en el centro de cómputo de la ONP
Fuente: Puyo R. (2009)
La implementación y certificación del SGSI del centro de cómputo de la ONP
basado en la norma ISO/IEC 27001 se llevó a cabo en más de dos años (564 días
útiles): del 07 de enero del 2007 hasta el 09 de febrero del 2009. Un año para la
implementación y operación, un año para el mantenimiento y mejora y más de medio
año para la auditoría interna y el logro de la certificación por parte de la BSI. Se
necesitó el esfuerzo directo de 3 personales de la ONP y 6 consultores, y de la
participación indirecta de 15 personales de la ONP y 14 consultores externos.
Logrando sobre todo un sistema de gestión de seguridad de la información alineado
a los objetivos institucionales. Cabe mencionar que los principales factores de éxito
fueron la disponibilidad del personal de ONP, una rápida acción ante las
observaciones del auditor, el constante compromiso de los responsables directos del
proyecto SGSI, la metodología de implementación personalizada a ONP y la
dedicación de 100% del equipo consultor al proyecto.
Piñero B. (2009), asegura que la serie ISO 27000 reemplaza a la ISO 17799 y
a UNE 71502. Al mismo tiempo define la serie 27000 como sigue:
27000: Definiciones y términos de seguridad de la información
27001: Implantación del SGSI (Certificable) evolución de BS-7799-2 y
equivale a UNE 71502
27002: Transcripción de ISO 17799:2005, catálogo de buenas
prácticas.
27003: Guía de implementación.
29
27004: Indicadores y métricas.
27005: Gestión y evaluación de riesgos.
2.3 Procesos ágiles de desarrollo de software
Este apartado se describe los métodos de desarrollo ágil de software MSF Agile
las prácticas de la programación extrema (XP, por sus siglas en inglés), las prácticas
del Desarrollo dirigido por pruebas (TDD, por sus siglas en inglés) y los principios,
conceptos y prácticas de Scrum.
2.3.1 Manifiesto ágil
Beck K y Colaboradores (2001), definieron los principios sobre los que se basan
los métodos alternativos, de desarrollo ágil de software en cuatro postulados o
valores, lo que ha quedado denominado como manifiesto ágil:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Juntamente con estos valores se redactaron los siguientes principios derivados
de estos valores:
Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana
y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del
desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar
ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos
meses, con preferencia al periodo de tiempo más corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de
forma cotidiana durante todo el proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles
el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
El método más eficiente y efectivo de comunicar información al equipo de
desarrollo y entre sus miembros es la conversación cara a cara.
El software funcionando es la medida principal de progreso.
30
Los procesos ágiles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo
constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño mejora la
agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es
esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-
organizados.
A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a
continuación ajustar y perfeccionar su comportamiento en consecuencia.
2.3.2 Marco general MSF-Agile
Microsoft solution framework (MSF) es la metodología empleada por Microsoft
para el desarrollo de software. Esta es una metodología flexible e interrelacionada
con una serie de conceptos, modelos y prácticas de uso, que controlan la
planificación, el desarrollo y la gestión de proyectos tecnológicos.
MSF se centra en los modelos de proceso y de equipo dejando en un segundo
plano las elecciones tecnológicas. El marco MSF se asienta sobre unos principios
fundamentales que definen la cultura del entorno de desarrollo:
1. Fomentar la comunicación abierta.
2. Trabajar en torno a una visión compartida.
3. Motivar a los integrantes del equipo.
4. Establecer responsabilidades claras y compartidas.
5. Centrar el objetivo en la entrega de valor para el negocio.
6. Permanecer ágiles y esperar al cambio.
7. Invertir en calidad.
8. Aprender de la experiencia.
El MSF es un conjunto integrado y configurable de procesos de desarrollo de
software, principios y prácticas probadas. En el Microsoft Visual Studio 2005 Team
System proporciona por defecto 2 plantillas configurables de la metodología MSF:
MSF for Agile Software Development, MSF for CMMi Process Improvement.
31
Meier J y Colaboradores (2007), afirman que la plantilla ágil de MSF-Agile
contienen las ideas claves del movimiento ágil de software, junto con los principios y
prácticas de MSF clásico para CMMI. El proceso apoya una estrategia de ingeniería
de software ágil que utiliza múltiples iteraciones y un enfoque basado en escenarios
para la creación de aplicaciones. La plantilla proporciona la automatización y la
orientación necesaria para apoyar a su equipo de desarrollo, incluida la gestión de
configuración, gestión de proyectos, seguimiento de elementos de trabajo, y un portal
del proyecto para la comunicación.
La plantilla de MSF-Agile define un conjunto de tareas a realizar durante las
iteraciones de los roles que intervienen en un ciclo de vida de desarrollo de software
incluyendo analistas de negocio, arquitectos, jefes de proyecto, desarrolladores y
probadores. La figura 10 muestra las principales actividades asociadas a cada una
de las tareas definidas.
Figura 10 –Principales tareas y actividades de MSF-Agile
Fuente: Meier J y Colaboradores (2007)
32
Cuando se crea un nuevo proyecto de equipo utilizando la plantilla de MSF-
Agile proceso, una página de conceptos delineando la orientación del proceso se
muestra en la ventana principal de Microsoft Visual Studio ®. Este es su punto de
vista inicial en el proceso de MSF-Agile. También puede acceder a esta información
desde la página principal del portal del proyecto.
La configuración de la herramienta va mucho más allá de la descripción del
proceso e incluye los elementos de trabajo (tales como escenarios, calidad del
servicio, las tareas, los insectos, y los riesgos), los informes del proyecto, los roles
(grupos y permisos), y un portal del proyecto. Elementos clave proporcionados por la
plantilla de MSF-Agile incluyen:
Los elementos de trabajo
Grupos y permisos de código fuente
Las áreas y las iteraciones
Informes
Portal
2.3.3 Artefactos agile UP
El proceso unificado ágil (AUP) es un desarrollo de programas basado en el
Proceso Unificado Racional (RUP) de IBM, es decir, el AUP es una versión
simplificada de RUP que incorpora técnicas de desarrollo ágiles. La figura 11
muestra el ciclo de vida del AUP.
Figura 11 – Ciclo de vida Agile UP
Fuente: Scott W. (2005)
AUP mantiene las fases del RUP: Inicio, donde se identifica el alcance inicial
del proyecto, una potencial arquitectura para el sistema, se obtiene financiamiento
para el proyecto y aceptación de los involucrados. Elaboración, donde se prueba la
arquitectura del sistema, se hace un prototipo de arquitectura que elimine los riesgos
33
técnicos para probar que el proyecto es factible. Construcción, donde se implementa
el software sobre una base incremental la que debe estar relacionada con los
objetivos de los involucrados. Y la transición, donde se valida y se entrega el sistema
en un ambiente de producción.
Sin embargo se han quitado varias disciplinas quedando las disciplinas de:
Modelo, donde se diseñan lo los procesos de negocios de la organización, el dominio
de problema que puede ser abordado por el software, y se identifica una solución
viable. Implementación, donde los diagramas del modelo se transforma en código
ejecutable y se aplican pruebas básicas en unidades particulares de prueba. Prueba,
donde se realiza una evaluación objetiva para asegurar la calidad. Esto incluye
encontrar defectos, validar que el sistema funcione como fue diseñado, y verificar
que los requerimientos estén abordados por las funcionalidades. Despliegue,
donde se planifica la entrega del sistema y se lleva a cabo el plan para que el sistema
esté disponible para los usuarios. Administración de la configuración, donde
se administra el acceso a los artefactos del proyecto. Esto no solo incluye el
seguimiento de las versiones de los artefactos, sino también controlar y administrar
los cambios sobre ellos. Administración del proyecto, donde se dirige las actividades
que forman parte del proyecto. Esto incluye administración de riesgos, dirigir
personas y coordinar personas con sistemas que están fuera del alcance del
proyecto. Y la disciplina del ambiente, donde se facilita todo el entorno que permita
el normal desarrollo del proyecto (Scott W, 2005).
Los artefactos UP que necesita un método ágil son: El diagrama de procesos
del negocio, los diagramas de clases del sistema, el diseño de la base de datos y las
interfaces de usuario.
2.3.4 Prácticas XP y TDD
Palacio J (2005), afirma que el Extreme Programming (XP) surge sobre la
suposición de que es posible desarrollar software de gran calidad a pesar, o incluso
como consecuencia del cambio continuo. Su principal asunción es que con un poco
de planificación, un poco de codificación y unas pocas pruebas se puede decidir si
se está siguiendo un camino acertado o equivocado, evitando así tener que echar
marcha atrás demasiado tarde. Los valores que inspiran XP son:
Comunicación, pone en comunicación directa y continua a clientes y
desarrolladores. El cliente se integra en el equipo para establecer prioridades y
resolver dudas. De esta forma ve el avance día a día, y es posible ajustar la
agenda y las funcionalidades de forma consecuente
34
Feedback rápido y continuo, una metodología basada en el desarrollo incremental
de pequeñas partes, con entregas y pruebas frecuentes y continuas, proporciona
un flujo de retro-información valioso para detectar los problemas o desviaciones.
o De esta forma fallos se localizan muy pronto.
o La planificación no puede evitar algunos errores, que sólo se evidencian
al desarrollar el sistema.
o La retro-información es la herramienta que permite reajustar la agenda y
los planes.
Simplicidad, consiste en desarrollar sólo el sistema que realmente se necesita.
Implica resolver en cada momento sólo las necesidades actuales. Los costes y la
complejidad de predecir el futuro son muy elevados, y la mejor forma de acertar
es esperar al futuro. Con este principio de simplicidad, junto con la comunicación
y el feedback resulta más fácil conocer las necesidades reales
Coraje, implica saber tomar decisiones difíciles. Reparar un error cuando se
detecta. Mejorar el código siempre que tras el feedback y las sucesivas
iteraciones se manifieste susceptible de mejora. Tratar rápidamente con el cliente
los desajustes de agendas para decidir qué partes y cuándo se van a entregar.
XP no es un modelo de procesos ni un marco de trabajo, sino un conjunto de
12 prácticas que se complementan unas a otras y deben implementarse en un
entorno de desarrollo cuya cultura se base en los cuatro valores citados:
Prácticas de codificación
o Simplicidad de código y de diseño para producir software fácil de
modificar.
o Reingeniería continúa para lograr que el código tenga un diseño óptimo.
o Desarrollar estándares de codificación, para comunicar ideas con claridad
a través del código.
o Desarrollar un vocabulario común, para comunicar las ideas sobre el
código con claridad.
Prácticas de desarrollo
o Adoptar un método de desarrollo basado en las pruebas para asegurar
que el código se comporta según lo esperado.
35
o Programación por parejas, para incrementar el conocimiento, la
experiencia y las ideas.
o Asumir la propiedad colectiva del código, para que todo el equipo sea
responsable de él.
o Integración continua, para reducir el impacto de la incorporación de
nuevas funcionalidades.
Prácticas de negocio
o Integración de un representante del cliente en el equipo, para encauzar
las cuestiones de negocio del sistema de forma directa, sin retrasos o
pérdidas por intermediación.
o Adoptar el juego de la planificación para centrar en la agenda el trabajo
más importante.
o Entregas regulares y frecuentes para satisfacer la inversión del cliente.
o Ritmo de trabajo sostenible, para terminar la jornada cansado pero no
agotado.
Yepes R y Chavarría R (2010), afirman que para un buen feedback, los equipos
XP requieren buenas prácticas de testing. Estos equipos practican test-driver
development (TDD) en pequeños ciclos en los que primero agregan un test y luego
escriben el código fuente necesario para pasar dicho test. De esta manera los
equipos producen código fuente con cerca del 100% de cobertura. La figura 12 ayuda
a entender estos conceptos.
Figura 12 – Flujo para aplicar TDD
Fuente: Yepes R y Chavarría R (2010)
36
Los test son ejecutados en forma conjunta. Cuando los desarrolladores liberan
código al repositorio, cada uno de los test deben pasar satisfactoriamente, lo que
significa que los desarrolladores tendrán un feedback inmediato a cerca de cómo
están haciendo su trabajo. Esta comprobación se puede realizarse de forma manual
o automatizada, interesando la segunda en lo que respecta a TDD.
Las pruebas unitarias, son realizadas a un componente individual de software.
Generalmente son dirigidas para probar los método de una clase, buscando exactitud
a la hora de identificar rápidamente cuales instrucciones están fallando en un
escenario determinado. Mientras que las pruebas de integración, son realizadas a
dos o más componentes o a todos los componentes de un software como un todo.
Aunque los test unitarios pueden dar la certeza que cada componente por separado
pueda estar funcionando correctamente, es muy probable que durante la interacción
real con sus dependencias haya problemas que únicamente son detectados con los
test de integración.
Así el análisis de código y pruebas unitarias pueden validar que los cambios de
código mitigan la vulnerabilidad expuesta por el defecto de código identificado
previamente.
2.3.5 Prácticas Scrum
Schwaber K y Sutherland J (2010), autores de Scrum, definen que Scrum se
basa en la teoría de control empírico del proceso, emplea un enfoque iterativo
incremental para optimizar la previsibilidad y controlar los riesgos. Existen tres pilares
que sostienen toda implementación del control empírico de procesos.
El primer pilar es la transparencia, la transparencia garantiza que los aspectos
del proceso que afectan al resultado, son visibles para aquellos que administran dicho
resultado. Estos aspectos no sólo deben ser transparentes, sino también conocidos.
Es decir, cuando alguien que inspecciona un proceso cree que algo está hecho, esto
debe ser equivalente a su definición de "hecho".
El segundo pilar es la inspección, se deben inspeccionar con la frecuencia
suficiente los diversos aspectos del proceso para que puedan detectarse variaciones
inaceptables en el mismo. La frecuencia de inspección debe tener en cuenta que
todos los procesos se cambian por el propio acto de inspección. El dilema se presenta
cuando la frecuencia de inspección requerida excede la tolerancia del proceso a ser
inspeccionado. Afortunadamente, esto parece no aplicar al desarrollo de software. El
otro factor es la habilidad y la diligencia de la gente que inspecciona los resultados
del trabajo.
37
Y el tercer pilar es la adaptación, si el inspector determina, a través de la
inspección, que uno o más aspectos del proceso están fuera de los límites
aceptables, y que el producto resultante será inaceptable, debe ajustar el proceso o
el material procesado. El ajuste debe realizarse lo más rápidamente posible para
minimizar una desviación mayor.
Hay tres puntos para la inspección y la adaptación en Scrum. La reunión diaria
de Scrum se utiliza para inspeccionar el avance hacia la meta de Sprint, y para hacer
las adaptaciones que optimicen el valor de la jornada de trabajo del día siguiente.
Además, la revisión de sprint y las reuniones de planificación se utilizan para
inspeccionar el progreso hacia el objetivo (la liberación de una versión) y para hacer
las adaptaciones que optimicen el valor del siguiente Sprint. Por último, la
retrospectiva de sprint se utiliza para revisar el sprint pasado y determinar qué
adaptaciones harán el siguiente sprint más productivo, satisfactorio y agradable.
El marco de Scrum se compone de un conjunto de equipos Scrum y sus roles
asociados; así como de bloques de tiempo, artefactos, y reglas.
Los equipos Scrum están diseñados para optimizar la flexibilidad y la
productividad, para lo cual, son auto-gestionados, multifuncionales, y trabajan en
iteraciones. Cada equipo Scrum tiene tres roles: 1) el Scrum master, que es
responsable de asegurar que el proceso es comprendido y seguido, 2) el Propietario
del producto, que es responsable de maximizar el valor del trabajo realizado por el
equipo Scrum, y 3) el equipo, que hace el trabajo. El equipo está formado por
desarrolladores con todos los conocimientos necesarios para convertir los
requerimientos del Propietario del producto en un incremento potencialmente
utilizable del producto al final del sprint.
Scrum emplea bloques de tiempo para crear regularidad. Los elementos de
Scrum basados en bloques de tiempo son: la reunión de planificación de la entrega,
la reunión de planificación del sprint, el sprint, el Scrum diario, la revisión del sprint,
y la retrospectiva del sprint. El corazón de Scrum es un sprint, que es una iteración
de un mes de duración o menos. La duración de cada sprint se mantiene constante
a lo largo de todo el esfuerzo de desarrollo. Todos los sprints utilizan el mismo marco
de referencia de Scrum, y proporcionan un incremento de funcionalidad
potencialmente utilizable al producto final. Cada sprint se inicia inmediatamente
después del anterior.
Scrum emplea cuatro Artefactos principales. El product backlog es una lista
priorizada de todo lo que podría ser necesario en el producto. El sprint backlog es
una lista de tareas para convertir el product backlog correspondiente a un sprint, en
38
un incremento del producto potencialmente entregable. Un burndown es una medida
del backlog restante a través del tiempo. Un burndown de versión mide el product
backlog restante durante el tiempo correspondiente a una liberación de una versión.
Un sprint burndown mide los elementos restantes del sprint backlog en el transcurso
de un sprint.
Las Reglas sirven de unión para los bloques de tiempo, los roles y los artefactos
de Scrum.
Palacio J (2011), define a Scrum como un método de gestión y control para
complementar la aplicación de otros métodos ágiles como XP que, centrados en
prácticas de tipo técnico, carecen de ellas.
Los principios de Scrum son:
Equipos autogestionados.
Una vez dimensionadas las tareas no es posible agregarles trabajo extra.
Reuniones diarias en las que los miembros del equipo se plantean 3 cuestiones:
o ¿Qué has hecho desde la última revisión?
o ¿Qué obstáculos te impiden cumplir la meta?
o ¿Qué vas a hacer antes de la próxima reunión?
Iteraciones de desarrollo de frecuencia inferior a un mes, al final de las cuales se
presenta el resultado a los externos del equipo de desarrollo, y se realiza una
planificación de la siguiente iteración, guiada por cliente.
La figura 13 muestra el método Scrum y el ciclo de vida de desarrollo ágil de
software.
Figura 13 – Proceso Scrum
Fuente: Palacio J (2011)
39
Scum denomina “Sprint” a cada iteración de desarrollo y según las
características del proyecto y las circunstancias del sprint puede determinarse una
duración desde una hasta dos meses, aunque no suele ser recomendable hacerlos
de más de un mes. El sprint es el núcleo central que proporciona la base de desarrollo
iterativo e incremental que recibe como entrada la pila de producto (product backlog).
40
3 CAPÍTULO 3
MATERIALES Y MÉTODOS
En este capítulo se describe los materiales empleados y se explica el proceso
seguido para obtener un modelo de desarrollo web seguro.
3.1 Lugar de ejecución
Esta investigación se realizó en el campus de la Universidad Peruana Unión
Filial Juliaca, del departamento de Puno.
3.2 Equipos y materiales
Los equipos y materiales empleados para la realización de la presente
investigación son:
3.2.1 Equipos
Laptop i5 (incluye windows 7)
3.2.2 Software
Microsoft Word 2010. Redacción de la tesis.
Enterprise Architect 7.x. Diseño de sistemas mediante diagramas UML.
Balsamiq 2.x. Diseño de prototipos de páginas web
Python 2.7.x. Lenguaje de programación ágil
Django 1.5.x. Framework para el desarrollo de aplicaciones web.
SublimeText 2. Editor de código fuente.
Git 2.x. Software para sincronizar repositorio locales.
Jenkins CI. Software de integración continúa.
Nginx 1.4.x. Servidor web para proyectos Django
Firefox 34.0.5 y firebug. Para la ejecución de páginas web y, el análisis
estático del código y depuración de errores respectivamente.
41
SQLite 3 y MySQL 5. Gestores de base de datos
Bootstrap 2.x. Frontend responsivo para aplicaciones web.
3.2.3 Servicios
Acceso a internet. Para la búsqueda de información y el desarrollo
colaborativo.
Github. Servicio en la nube para la codificación colaborativa
Assembla. Servicio en la nueve para el gerenciamiento del proyecto de
Qualpaca aplicando Scrum.
Impresiones y Fotocopias
3.2.4 Material bibliográfico
Laudon K, Laudon J. 2012. Sistemas de información gerencial. 12° ed.
México: Pearson educación. 640 p. ISBN 978-607-32-0949-6
3.3 Tipo de investigación
La presente investigación es de tipo evaluativa aplicada. Ya que evalúa los
modelos SSE-CMM/ISO-21827 y OWASP. Estos modelos son combinados con
experiencias vividas para obtener un nuevo modelo para desarrollar aplicaciones web
seguras y luego fue aplicado en un proyecto real con la finalidad de refinar el modelo
propuesto y mejorar las buenas prácticas de desarrollo seguro de aplicaciones web.
El esquema de los procesos de la presente investigación se muestra en la
figura 14.
Figura 14 – Esquema de elaboración de la propuesta
Propuesta: Un modelo para Desarrollar Aplicaciones
Web Seguras (WSM-DEV, por sus siglas en inglés)
METODOLOGÍAS BASE DE
SEGURIDAD DEL
SOFTWARE: SSE-
CMM/ISO 21827, OWASP
METODOLOGÍAS DE
PROCESOS
DESARROLLO DE
SOFTWARE: SCRUM,
Agile UP
42
El agrupamiento de las prácticas de seguridad del modelo propuesto
denominado WSM-DEV, tienen su fundamento en las prácticas de seguridad
(dimensiones y capacidades) del modelo SSE-CMM. La guía OWASP, proporciona
las características básicas de seguridad de una aplicación web; las otras prácticas y
características de seguridad se basan en experiencias vividas en el desarrollo de
aplicaciones web.
Por su parte, la aplicación del modelo WSM-DEV sobre los modelos de
software Scrum, permitieron la refinación de las actividades y artefactos del modelo
propuesto.
3.4 Indicadores de evaluación de la propuesta
Con la finalidad de conocer cualitativamente los resultados de la aplicación del
modelo propuesto (producto), se definen los indicadores de evaluación presentados
en la tabla 9.
Tabla 9. Indicadores de evaluación para el modelo propuesto
# Indicador Descripción Promedio ideal
1 Porcentajes de
vulnerabilidades
controladas.
Numero de vulnerabilidades mitigadas
por el número de vulnerabilidades
identificadas
90%
2 Velocidad del
equipo ágil de
desarrollo.
Cantidad de trabajo realizado en 4
semanas
20 puntos historia
(en la primera
iteración)
3 Porcentaje de
métodos que
cumplen el estilo
de codificación .
Número de métodos que siguen el estilo
de codificación por el total de métodos
de la aplicación
80%
4 Porcentaje de
líneas de código el
que cumplen los
estándares de
codificación.
Número de líneas que siguen el estilo
de codificación por el total de líneas de
la toda la aplicación
70%
5 Porcentaje de
artefactos
desarrollados.
Numero de artefactos desarrollados de
los nueve artefactos del modelo
80%
El promedio ideal puede ser referencial, ya que el nivel de seguridad va
depender también del valor de los activos de información que el negocio requiere
43
proteger. Sin embargo, toda aplicación debe mitigar las 13 vulnerabilidades de las
aplicaciones web del anexo B2.
El promedio de personas de un equipo ágil son entre 3 y 7 personas promedio.
Los 20 puntos historia del promedio ideal está en función a 3 o 4 personas. Es decir
la velocidad promedio ideal de cada persona debe ser de 4 a 5 puntos al mes (Palacio
J, 2011).
Los indicadores 3 y 4 corresponden a las coberturas de cumplimiento del estilo
de codificación a nivel de métodos y de líneas de código, que comúnmente para la
cobertura aceptable de las pruebas suele ser del 80%. La cobertura de pruebas
puede ser incluida cuando se aplica con el modelo TDD.
44
3.5 Diagrama de flujo de las actividades de la Investigación
El diagrama de flujo de las actividades de la presente investigación se muestra
en la figura 15.
Figura 15 – Diagrama de flujo de las actividades de la investigación
- Validación de la propuesta
- 6. Revisión final de la tesis
- Definición de la propuesta
Tesis con correcciones
Tesis OK
Propuesta OK Propuesta inválida
-
Documentación de la tesis
-
Organización y planificación de la investigación
Análisis de las metodologías
-
- Análisis de resultados y
elaboración de conclusiones
45
Luego de la organización y planificación de la investigación, se analizaron las
metodologías resumidas en la figura 14 y se elaboró el modelo de manera que se
integre la seguridad en el proceso de desarrollo de aplicaciones web, y a su vez se
fue documentando la tesis. Una vez definido el modelo, se realizó la validación con
el desarrollo del proyecto Qualpaca como caso de estudio, esta aplicación permitió
refinar los componentes del modelo permitiendo analizar los resultados finales y
formular las conclusiones de la investigación. Una vez terminada la documentación
tanto del modelo como de la tesis; la tesis fue enviada a revisión hasta corregir las
observaciones de los Jurados.
46
3.6 Cronograma de actividades
El desglose del trabajo realizado, luego de la organización y planificación de la
investigación, se muestra en la Tabla 10.
Tabla 10 - Cronograma de actividades
Fase Actividades
Tiempo (9 meses)
2013-2014
A M J J A S O N D
ANÁLISIS DE METODOLOGÍAS
Organización de bibliografías
Análisis de metodologías de DESARROLLO DE SOFTWARE
Análisis de metodologías de SEGURIDAD DE INFORMACIÓN
Revisión de la seguridad de los frameworks emergentes para los
lenguajes de programación ágiles y tradicionales.
DEFINICIÓN DE LA PROPUESTA
Elaboración de un modelo inicial donde las actividades de
seguridad puedan concretarse juntamente con el modelo de
desarrollo de software.
Documentar las actividades, los roles de cada componente del
modelo
Elaboración de las plantillas de cada componente del modelo de
seguridad propuesta.
Refinar el modelo de seguridad propuesto.
Crear las plantillas de los artefactos de la propuesta.
Refinar las plantillas de los artefactos del modelo de seguridad
propuesto.
47
VALIDACIÓN DE LA PROPUESTA Y DOCUMENTACIÓN
Elaborar un Backend de administración para un determinado
framework emergente que contengan los componentes de
seguridad especificados en la OWASP siguiendo el modelo
propuesto.
Validación de la propuesta aplicando a la construcción de una
Aplicación Web
Documentación del caso de estudio
Actualización del modelo propuesto
FASE FINAL
Análisis de los resultados y elaboración de conclusiones
Redacción del Documento de la Tesis
Sustentación
48
3.7 Presupuesto y financiamiento del proyecto de tesis
Tabla 11 - Presupuesto del proyecto
Descripción Unid.Med. Cantidad P.U. SubTotal S/.
MATERIALES Y EQUIPOS 5,000.00
Laptop i5 (incluye Windows 7) Unidad 1 4,500.00 4,500.00
Memoria USB Unidad 1 50.00 50.00
Textos Unidad 5 90.00 450.00
SOFTWARE .00
Python Lic. Libre 1 0.00 0.00
Sublime Text 2 Lic. Libre 1 0.00 0.00
Enterprise Architect 5 Lic. Trial 1 0.00 0.00
Balsamiq Lic. Trial 1 0.00 0.00
Git Lic. Libre 1 0.00 0.00
SERVICIOS DE TERCEROS 1,500.00
Modem + Internet Año 1 1,000.00 1,000.00
Hosting GB 1 0.00 0.00
Impresiones Unidad 500 0.20 100.00
Fotocopias Unidad 2000 0.10 200.00
Empaste Unidad 10 20.00 200.00
SERVICIOS DE CONSULTORÍA 1 15,000.00
Asesor de la tesis RR.HH. 1 1,000.00 1,000.00
Tesista RR.HH. 1 5,000.00 5,000.00
Analista-programador (backend) RR.HH. 1 9,000.00 9,000.00
SERVICIOS DE CONSULTORÍA 2 12,000.00
Dueño del proyecto RR.HH. 1 2,000.00 2,000.00
Jefe del proyecto RR.HH. 1 2,000.00 2,000.00
Analista RR.HH. 1 2,000.00 2,000.00
Programador RR.HH. 3 2,000.00 6,000.00
PAGOS DEL PROCESO DE TESIS 2,380.00
OTROS GASTOS 1,500.00
PASAJES Y VIÁTICOS 1,000.00 1,000.00
Imprevistos 500.00
Total S/. 37,380.00
49
Tabla 12 - Financiamiento del proyecto
Descripción Importe S/.
Financiamiento propio 19,380.00
Financiamiento UPeU 6,000.00
Financiamiento Grupo InnOp Perú 12,000.00
Total S/. 37,380.00
El rubro de financiamiento propio de la tabla 12, corresponde a los gastos de
la compra de materiales y equipos, más los gastos de servicios de terceros (excepto
el internet) y más los otros gatos como son pasajes y viáticos.
El rubro de financiamiento UPeU de la tabla 12, corresponde a los gastos de
internet más el pago al tesista por ser empleado a tiempo completo de dicha
institución.
El rubro de financiamiento Grupo InnOp Perú de la tabla 12, corresponde a los
gastos de servicios de consultoría que la empresa Grupo InnOp Perú pagó por el
desarrollo de Qualpaca.
50
4 CAPÍTULO 4
CONSTRUCCIÓN DEL MODELO PARA EL DESARROLLO
DE APLICACIONES WEB SEGURAS
4.1 Introducción
En este capítulo se describe el principal resultado del trabajo de tesis: el modelo
propuesto y sus elementos. Para una rápida identificación del modelo propuesto, en
adelante se denominará por sus siglas en inglés “WSM-DEV” (Web-application
Security Model for Development).
4.2 Diseño gráfico del modelo propuesto
El modelo para el desarrollo de aplicaciones web seguras (WSM-DEV, por sus siglas en inglés), pretende ser un modelo de referencia para incorporar las mejores prácticas de seguridad en el ciclo de vida de desarrollo, con la finalidad de construir aplicaciones web robustas, confiables y en el menor tiempo. Para tal fin WSM-DEV provee las plantillas y recursos para cada uno de sus procesos y artefactos.
Esta estrategia permite asignar directamente el trabajo que el negocio requiere
de modo que resulte simple, de menos a más y natural para el desarrollador. La figura
16 muestra la representación gráfica de los grupos de actividades del modelo
propuesto.
Figura 16 – Diseño del modelo WSM-DEV
51
El backend web seguro, es el primer módulo que implementa una serie de
controles de seguridad en base a vulnerabilidades recurrentes en toda aplicación web
especificados en estudios internacionales como la OWASP, entre otros estudios y
sobre todo en experiencias probadas. Este módulo indica claramente el estilo de
codificación (principios y prácticas) que el equipo debe seguir para construir el resto
del sistema. De este módulo dependerá el nivel de seguridad de la aplicación así
como el tiempo, los riesgos y el costo del proyecto. Este módulo debe ser construido
siguiendo los pasos 2 al 4 del modelo propuesto WSM-DEV.
El análisis de riesgo de seguridad, es el componente más importante del
modelo WSM-DEV, donde se identifican y se priorizan las amenazas y
vulnerabilidades asociados al desarrollo de la aplicación web para incorporarlos en
las tareas del desarrollo. Aquí se planifica el curso de acción requerido para llevar a
cabo los objetivos de seguridad de una iteración.
El siguiente proceso de WSM-DEV es el proceso de implementación de
controles de seguridad, donde se lleva a cabo las actividades planificadas
anteriormente con el fin de lograr los objetivos definidos. Al finalizar la iteración, se
debe mostrar un producto completamente funcional de acuerdo a las actividades
definidas para la Iteración con un nivel de seguridad de acuerdo a los objetivos de
seguridad de la Iteración.
El último proceso de WSM-DEV es el proceso de demostración y validación de
la seguridad donde se realizan procesos de revisión, validación y medición que
permitan certificar que el Incremento es confiable y las acciones correctivas
necesarias.
4.3 Principios de seguridad
4.3.1 Defensa en profundidad
Proveer a la aplicación más de un punto de defensa; la última línea de defensa
debe darse en el backend de la aplicación web.
4.3.2 Privilegios específicos
Definir perfiles de usuario específicos; los roles o funciones de los usuarios bien
definidas deben establecer claramente el manejo de la aplicación.
4.3.3 Estilo de codificación simple pero robusto
Escribir la cantidad mínima de líneas de código que permita que el sistema
responda frente a fallas, y cumplir con los estándares y prácticas de codificación.
52
Esto permitirá identificar las vulnerabilidades, aumentar la productividad y la calidad
del código.
4.3.4 Seguimiento
Guardar en bitácoras los sucesos del sistema ocasionados por las acciones de
usuarios e intrusos. Esto permitirá conocer cómo la aplicación está siendo atacada.
A continuación se detallan las prácticas de seguridad de este modelo.
4.4 Backend web seguro
El objetivo del backend web seguro, es elaborar los componentes que toda
aplicación web requiere antes de iniciar con su desarrollo, sobre todo los
componentes de seguridad, así como el estilo de codificación. El objetivo es definir
una línea base en seguridad web para las empresas y profesionales de software que
trabajan en el campo de la seguridad dentro del ciclo de desarrollo.
Proyectos sobre seguridad de software como la OWASP y WASC (Web
Application Security Consortium) definen un conjunto de vulnerabilidades que deben
ser consideradas en la construcción de una aplicación web, algunos de los controles
de seguridad son implementados por los frameworks actuales, pero muchas veces
toma tiempo hacer que funcione y sobre todo deja de lado el estilo de codificación de
la aplicación. Va depender de la flexibilidad de los componentes de seguridad de los
frameworks para extender su funcionalidad a nuevos controles de seguridad que
requiera una aplicación en particular.
Para iniciar el desarrollo de una aplicación, lo mínimo que se necesita es que
estos componentes de seguridad deben estar debidamente implementados, así
como los otros componentes o librerías de utilidad de desarrollo de una aplicación
web.
Las características del backend web seguro a usar o a desarrollar debe
satisfacer las características de la aplicación web a desarrollarse, más no al revés.
Si esto sucede, es necesario definir tareas de personalización al backend.
Por lo general, un Backend web seguro para aplicaciones web tipo SaaS, debe
tener las siguientes características: gestionar de manera rápida y segura a los
usuarios, perfiles, permisos, recursos del sistema, módulos del sistema, menús
dinámicos, empresas, sucursales entre otros parámetros de configuración del
sistema. De modo que los siguientes módulos puedan reutilizar los mismos
componentes de seguridad, mensajería, auditoría, plantillas web, sesiones y tokens
53
de usuarios, permitiendo incluso extender su funcionalidad para casos particulares.
De este Backend dependerá el nivel de seguridad, modernidad, riesgos, cantidad de
personal, costos y tiempos de un proyecto de software.
Estos requisitos y características del backend, debe definirse en la reunión
Project definition, ya que en esta reunión se valida los objetivos y el trabajo de todo
el proyecto. En esta reunión intervienen el Sponsor del proyecto, el Gerente del
proyecto, el Representante de los clientes, entre otros interesados del proyecto.
El backend web seguro, se puede evidenciar entonces en el Project definition
meeting obteniendo como resultado los requisitos y características del módulo del
backend web seguro.
Entradas
Requisitos del sistema (visión del proyecto)
Herramientas
Project definition meeting
Salidas
Requisitos del sistema para el módulo backend
Registro de riesgos de seguridad (amenazas y vulnerabilidades)
Registro de componentes de seguridad
Arquitectura de la aplicación
Estándares de desarrollo
Método de trabajo del equipo
Prototipos principales
Diseño de clases del sistema o ejemplos de aceptación
Por lo tanto, a partir de los requisitos del sistema, se infieren los requisitos de
seguridad y las pruebas de vulnerabilidad que ayudan a definir el software y se
asignan a componentes de software. Este conjunto de requisitos de software y de
componente de software se convierten en: la arquitectura del software, los diseños
de los componentes de software y los componentes de software. En base a la
54
arquitectura y los estándares se elaboran los Prototipos principales y el Diseño de
clases de toda la aplicación o al menos de la primera iteración y son usados en la
validación y priorización de los requisitos. En caso de estar usando TDD, basta con
agregar a los requisitos o historias de usuario los Ejemplos de aceptación del usuario.
Para el desarrollo de este backend web seguro, debe seguir los pasos 2 al 4
del modelo WSM-DEV.
4.5 Artefactos del backend web seguro
4.5.1 Requisitos del sistema (o requisitos para el módulo backend)
Los requisitos del sistema (módulo backend), es el listado de requisitos
principales que define la visión de todo el proyecto (o de todo el módulo). Vale señalar
que están incluidos los requisitos de seguridad y expectativas del cliente
debidamente priorizados y estimados. Este listado contiene las siguientes partes:
Nombre del proyecto
Fecha de actualización
Listado de los requisitos con propiedades básicas.
La plantilla para los requisitos del sistema puede verse en el anexo A1.
4.5.2 Registro de riesgos de seguridad (amenazas y vulnerabilidades).
El Registro de riesgos de seguridad (amenazas y vulnerabilidades), es el
listado de amenazas y vulnerabilidades comprometido con la aplicación web. Esta
lista inicial para el backend, puede ser obtenido a partir de guías o normas como la
OWASP, recomendaciones de expertos y experiencias vividas que estén alineados
con el objetivo del proyecto. Este listado contiene las siguientes partes:
Nombre del proyecto
Fecha de actualización
Listado de los riesgos de seguridad con propiedades básicas.
La plantilla para el registro de riesgos de seguridad (amenazas y
vulnerabilidades) del proyecto puede verse en el anexo A2.
55
4.5.3 Registro de componentes de seguridad.
El registro de componentes de seguridad, es el listado de recursos de
seguridad para contrarrestar las amenazas y vulnerabilidades comprometidas con la
aplicación web. Este listado contiene las siguientes partes:
Nombre del proyecto
Fecha de actualización
Listado de los componentes (o una matriz de componentes con riesgos).
La plantilla para el registro de componentes de seguridad del proyecto puede
verse en el anexo A3.
4.5.4 Arquitectura de la aplicación
La arquitectura de la aplicación es un esquema que muestra las capas de la
aplicación, las interacciones entre las capas basado en una arquitectura estándar y
las tecnologías que se usan para implementar cada capa. Este esquema muestra de
forma holística el nivel de calidad y seguridad de la aplicación. Este documento
consta de:
Información general
Historial de revisiones
Esquema de la arquitectura de la aplicación (cuadro o gráfico)
La plantilla de la Arquitectura de la aplicación puede verse en el anexo A4.
4.5.5 Estándares de desarrollo
El estándar de desarrollo es un documento que indica cómo se debe de
nombrar los diferentes componentes de la aplicación: nombre de las clases, atributos,
métodos, archivos, carpetas, nombre de las tablas y campos, así como nombre de
los diagramas y elementos de diseño del sistema. Todo programador, además del
estándar de desarrollo, debe seguir las técnicas y estilos de desarrollo definidas para
el proyecto. Estas técnicas y estilos se interiorizan a través del backend o de un
ejemplo completo desde el diseño hasta la implementación de un componente y
muestra el orden de las instrucciones o restricciones del programa, código depurado
56
y las pruebas que todo componente debe cumplir. Un estándar de desarrollo
contiene:
Información general
Historial de revisiones
Términos de definición de identificadores
La plantilla del estándar de desarrollo puede verse en el anexo A5.
4.5.6 Método de trabajo del equipo
El método de trabajo del equipo es un documento que resume el plan del
proyecto con la información necesaria dirigida al equipo de desarrollo. Define las
herramientas y procedimientos para minimizar riesgo, sobre todo riesgos de
seguridad. Este documento contiene las siguientes partes:
Información general
Historial de revisiones
Equipo de trabajo
Herramientas
Desafíos o retos a superar
La plantilla del método de trabajo del equipo puede verse en el anexo A6.
4.5.7 Prototipos principales
Los prototipos principales son las interfaces gráficas del usuario diseñado
mediante una herramienta para prototipos que validan las entradas de los datos, los
procesos de negocio y los reportes esperados por los usuarios y clientes. Los
prototipos principales y Los diagramas de clases de diseño del sistema son los únicos
artefactos que se necesitan para delegar tareas al equipo de desarrollo en un modelo
clásico, estos artefactos son reemplazados por los ejemplos de aceptación para un
modelo ágil. Un prototipo responde:
Proyecto
Módulo
57
Fecha
Requisito
Imagen de la Interfaz gráfica del usuario
Funcionalidad
Personal que aprueba la interface
La plantilla para un prototipo puede verse en el anexo A7.
4.5.8 Diseño del sistema (para la iteración)
El diseño del sistema o de la iteración es un reporte en HTML de la versión
actual del diseño del sistema y contiene los diagramas de clases de diseño. Un
diseño del sistema indica los componentes del sistema, sus relaciones de
dependencia, las restricciones y reglas de negocio que deben ser probadas y
validadas. El diseño debe relejar los estándares de desarrollo y la arquitectura del
sistema. En un documento formal o sistema de mensajes debe indicarse lo siguiente:
Nombre del proyecto
Historial de revisiones
Actualizaciones importantes
Links de descarga o de consulta
Estructura base del modelo.
La plantilla del diseño del sistema puede verse en el anexo A8.
4.6 Análisis de riegos de seguridad
El objetivo de este grupo de procesos es identificar y priorizar las amenazas y
vulnerabilidades de la aplicación e incorporarlos a los requisitos del sistema o
historias de usuario que se van a implementar en la Iteración. En Scrum, esta
integración se realiza en la primera parte del Sprint planning meeting. Por lo que se
precisa de un experto en seguridad que ayude al Dueños del producto a identificar
los riesgos de seguridad.
58
Por lo tanto, a partir de los requisitos del sistema, incluyendo los requisitos del
backend, se infieren los nuevos requisitos de seguridad y las pruebas de
vulnerabilidad que ayudan a definir el software y se asignan a componentes de
software. En base a la arquitectura y los estándares se elaboran los prototipos
principales de toda la aplicación o al menos de la primera iteración y son usados en
la validación y priorización de los requisitos.
Una vez identificado los riesgos de seguridad, se procede a definir los
componentes de seguridad para cada amenaza o vulnerabilidad. En Scrum, estas
actividades corresponde a la segunda parte del Sprint planning meeting, al definir las
tareas, relacionados a las historias del product backlog.
Para poder definir la lista de tareas de desarrollo, se debe tener listo el diseño
del sistema para todos los requisitos seleccionados de la Iteración. Cada componente
del diseño del sistema debe estar debidamente documentado las reglas de negocio
y las restricciones de seguridad. El diseño debe reflejar el estándar de desarrollo, las
técnicas o estilo de codificación y la arquitectura de la aplicación.
Las tareas para solucionar los errores y vulnerabilidades de la Iteración anterior
e incluso las observaciones en el diseño de los requisitos seleccionados deben ser
rediseñados y solucionados durante la Iteración en curso.
El grupo de procesos de análisis de riesgos de seguridad se puede evidenciar
entonces en la Iteration planning meeting obteniendo como resultado el registro de
componentes de seguridad.
Entradas
Requisitos del sistema
Registro de riesgos de seguridad (amenazas y vulnerabilidades)
Diseño del sistema (para la iteración)
Herramientas
Iteration planning meeting
Salidas
Entradas actualizadas
Registro de componentes de seguridad
59
A continuación se describen cada uno de los nuevos artefactos, las plantillas
pueden revisarse en los anexos referidos.
4.7 Artefactos del análisis de riesgos de seguridad
En el análisis de riesgos de seguridad no cuenta con ningún nuevo artefacto.
Las plantillas de los artefactos pueden revisarse en los anexos referidos para los
artefactos del backend web seguro.
4.8 Implementación de los componentes de seguridad
El objetivo de este grupo de procesos es llevar a cabo las tareas de
implementación, por parte del equipo de desarrollo, mediante un seguimiento visible
con el fin de lograr los objetivos de seguridad definidos para dicha iteración;
asimismo, implica tanto la coordinación de personas y recursos, así como el
entrenamiento en seguridad al equipo de desarrollo.
Las tareas de la iteración se enfocan en la codificación y testing de los
componentes de seguridad juntamente con las tareas de dicha iteración, por lo que
es importante contar con herramientas para la revisión y testing de la seguridad y
calidad del software sea manual como automatizado, estas tareas deben estar
soportadas por herramientas de desarrollo colaborativo y métodos adecuados para
su integración. A continuación se presenta las buenas prácticas para un correcto
desempeño colaborativo.
1. Antes de realizar una tarea, obtener el último commit del repositorio remoto,
es decir, actualizar el repositorio local.
2. Realizar la(s) tarea(s) según los estándares y estilos de codificación
establecidos para el proyecto.
3. Antes de subir una tarea al repositorio remoto, volver a actualizar el
repositorio local, resolver los conflictos y errores si los hubiese y
seguidamente, subir las tareas al repositorio remoto. Si se está usando un
sistema de integración continua, verificar que los reportes con la nueva
revisión o commit sigan sin errores y mantengan los indicadores de calidad
establecidos para el proyecto.
4. Comunicar el estado de la tarea según el método de trabajo establecido.
Dos prácticas básicas para los testings son:
60
1. Filtrar entradas, con el fin de asegurar que los datos de entrada sean
válidos.
2. Escapar salidas, para asegurar que los datos salientes no se
malinterpreten.
Las buenas prácticas para las pruebas de seguridad, dentro de este grupo de
procesos responden a las tareas de:
1. Filtrar entradas
Asegurar que los datos de entrada sean válidos; verificar si los datos cumplen
con ciertas reglas, así como el origen de los datos.
2. Asegurar transacciones
Asegurar que los datos se guarden o no de forma adecuada. En ambos casos,
y en especial cuando falla, el sistema debe responder robustamente.
3. Escapar salidas
Asegurar que los datos de salida no se malinterpreten, es decir codificar o
decodificar caracteres especiales de tal forma que su significado original sea
preservado.
En muchas organizaciones dedicadas a la fabricación de software, estos
componentes son desarrollados por un equipo central, dedicados a la investigación
y mejora de los componentes claves de la aplicación y, a dar soporte y capacitación
al equipo de seguridad de un determinado proyecto sobre el uso adecuado de los
componentes de seguridad y otros utilitarios. El equipo de soporte central, son los
encargados de definir el estilo de codificación para todo el proyecto, pues, frente a
un problema se tiene más de una forma de solucionarlos; pero solo una forma es la
correcta para el proyecto en cuestión.
El grupo de procesos de implementación de los componentes de seguridad se
puede evidenciar en el Security training meeting y por las herramientas de revisión y
validación automatizadas y manuales obteniendo como resultado el Incremento o
producto funcional seguro.
Entradas
Registro de componentes de seguridad
61
Herramientas
Herramientas de revisión y validación automatizados y manuales
Security training meeting
Salidas
Producto funcional o incremento seguro
A continuación se describen cada uno de los nuevos artefactos, las plantillas
pueden revisarse en los anexos referidos.
4.9 Artefactos de la implementación de los componentes de seguridad
4.9.1 Producto funcional seguro
El producto funcional seguro, es la aplicación funcionando de acuerdo a las
tareas definidas para la iteración o la suma de ellos juntamente con los objetivos de
seguridad.
4.10 Demostración y validación de la seguridad
El objetivo de este grupo de procesos es revisar el cumplimiento de los
objetivos de seguridad del proyecto mediante la presentación de resultados, se
realizan procesos de análisis, revisión y medición que permitan certificar que el
Incremento es confiable y las acciones correctivas necesarias.
Los procesos de análisis, revisión y medición se realizan de forma manual y
automática. Las herramientas de Integración Continua permiten automatizar estos
procesos. Por ejemplo, en un proceso TDD, la cobertura de la pruebas aceptable
promedio es del 80%. Estos parámetros de medición deben ser definidos al inicio del
proceso de desarrollo. Los indicadores que miden la eficacia de este modelo se
muestra en la tabla 9.
Al finalizar una iteración se debe presentar el resultado de la iteración para su
aceptación. Con respecto a la seguridad, se debe hacer pruebas de intrusión con el
fin de encontrar nuevas o recurrentes vulnerabilidades de tal manera que se lleven a
cabo acciones correctivas en la próxima iteración.
El grupo de procesos de demostración y validación de la seguridad se puede
evidenciar mediante las reuniones de revisión de la iteración y herramientas de
validación automatizadas y manuales obteniendo como resultado el registro de
riesgos de seguridad actualizado y las lecciones aprendidas.
62
Entradas
Registro de riesgos de seguridad
Incremento seguro
Herramientas
Iteration review meeting
Herramientas de validación automatizados y manuales
Salidas
Registro de riesgos de seguridad (vulnerabilidades)
Lecciones aprendidas
A continuación se describen cada uno de los nuevos artefactos, las plantillas
pueden revisarse en los anexos referidos.
4.11 Artefactos de la demostración y validación de la seguridad
4.11.1 Formulario de lecciones aprendidas
El formulario de lecciones aprendidas, es un informe de lo que salió bien o no
durante el desarrollo de la iteración y de las acciones de mejora para la siguiente
iteración. Un formulario de lecciones aprendidas contiene las siguientes partes:
Proyecto:
N° Iteración:
Qué salió bien en la iteración
Qué no salió bien en la iteración
Qué mejoras vamos a implementar en la siguiente iteración
La plantilla del formulario de lecciones aprendidas puede verse en el anexo A9.
4.12 Resumen
El modelo WSM-DEV, plantea claras actividades desde la concepción del
proyecto hasta la entrega del producto funcional soportadas por plantillas
consistentes y simplificadas con el propósito de dar cumplimiento a los procesos de
63
ingeniería de software, acelerar el desarrollo y obtener una aplicación web más
segura.
64
5 CAPÍTULO 5
VALIDACIÓN DEL MODELO PROPUESTO
WSM-DEV – PARTE 1
5.1 Introducción
En este capítulo se describe la aplicación y validación de la primera parte del
modelo propuesto WSM-DEV; sobre el backend web seguro. La segunda parte del
modelo se aplica y se valida en el siguiente capítulo.
Para ambas partes se realizan mediante el desarrollo de una aplicación web
para la cadena productiva de alpacas (patrocinado por CONCYTEC y la UPeU en el
año 2013) denominada “Qualpaca” versión 1.0
Con la aplicación y validación de esta primera parte del modelo WSM-DEV se
obtuvo el segundo resultado o aporte del trabajo de tesis: El módulo backend de
administración y configuración de aplicaciones web seguras en la nube escrita en
Django y Bootstrap. Y que también sirve como referencia para la construcción de del
módulo backend con otros framewroks o lenguajes de programación.
5.2 Acerca del proyecto
5.2.1 Grupo InnOp Perú
Grupo InnOp Perú EIRL, es una empresa dedicada a ofrecer consultoría y
servicios a terceras empresas. La consultoría y servicios en ingeniería se realizan
mediante el desarrollo de proyectos a plazo determinado e integrada por
profesionales. Grupo InnOp Perú EIRL es parte ejecutante del proyecto UPeU-
CONCYTEC 2013 denominado “Desarrollo de plataforma tecnológica en la web para
la competitividad de la cadena productiva de alpacas en la región Puno” financiado
por el Consejo Nacional de Ciencia, Tecnología e Innovación del Perú (CONCYTEC)
y por la Universidad Peruana Unión (UPeU)
5.2.2 Proyecto UPeU-CONCYTEC 2013
El proyecto UPeU-CONCYTEC 2013, es un proyecto de investigación
presentado por la Dra. Nélida Gladys Maquera Sosa y la UPeU (Universidad Peruana
Unión) en el año 2013 al CONCYTEC denominado “Desarrollo de plataforma
65
tecnológica en la web para la competitividad de la cadena productiva de alpacas en
la región Puno”, el cual consta de varios entregables entre ellos la aplicación web
funcional denominada “Qualpaca” versión 1.0.
5.2.3 Qualpaca 1.0
Qualpca 1.0, es el nombre de la plataforma tecnológica en la web para la
competitividad de la cadena productiva de alpaca en cumplimiento al proyecto UPeU-
CONCYTEC 2013.
Qualpaca 1.0, es una aplicación web para la nube que da soporte a los registros
genealógicos y reproductores de alpacas de la región Puno. La versión 1.0 consta de
los siguientes módulos:
1. Selección e identificación de alpaca
2. Empadre y gestación
3. Parición y destete
4. Sanidad
5. Esquila
6. Castración
7. Retiro
Debido al tratado de confidencialidad y con la autorización de la Gerente
General de la empresa Grupo InnOp Perú, parcialmente se pueden ver estos
documentos en los anexos referidos.
5.2.4 Materiales y métodos
Qualpaca versión 1.0 fue desarrollado con tecnologías ágiles como el
framework Django 1.5.x de Python, el gestor de base de datos MySQL 5.x y sobre el
administrador de aplicaciones Backengo 0.1 (backenddj) que a su vez integra el
Bootstrap 2.x. El equipo de desarrollo multidisciplinario estuvo conformado por 5
personas contratadas por la consultora Grupo InnOp Perú. Para el desarrollo del
proyecto se aplicó el método Scrum y para la seguridad el método WSM-DEV.
Por acuerdo de confidencialidad, solo se describe y se muestra parte de los
procesos y resultados del proyecto Qualpaca que han sido autorizados por escrito
por la autora principal Dra. Nélida Gladys Maquera Sosa, Gerente General de la
empresa Grupo InnOp Perú EIRL.
66
Seguidamente, se describe el proceso de desarrollo del backend web seguro
sobre la cual se desarrolló Qualpaca.
5.3 Backend web seguro y la definición del proyecto Qualpaca
El proyecto Qualpca 1.0, se inició formalmente el 01 de mayo del 2013, donde
solo se sabía a grandes rasgos que se desarrollaría una aplicación web para mejorar
la cadena productiva de alpacas. El sistema tendría que registrar los datos
genealógicos y datos de producción de las alpacas iniciando por todos los
productores de la región Puno.
Después de revisar los procesos de la cadena productiva de alpacas en
diferentes instituciones dedicados a la crianza de alpacas de la región Puno y con la
asesoría del Ing. Eliphas Coeli de la Universidad de Camerino de Italia, se definió la
visión del proyecto.
Seguidamente, se optó por aplicar los métodos Scrum y WSM-DEV, el lenguaje
de programación ágil Python y el framework Django, que para ese entonces solo se
tenía una versión en borrador del WSM-DEV y el principal riesgo era que no se
contaba con un backend web seguro desarrollado sobre Django, lo que hizo que el
inicio del desarrollo se postergara hasta el mes de noviembre del mismo año (seis
meses después). Sin embargo, mientras se esperaba la primera entrega del backend
para Django, se inició a diseñar el sistema.
Los prototipos del sistema se validaron el 14 de junio de 2013 en una reunión
con los representantes de las diferentes instituciones dedicados a la crianza de
alpacas de la región Puno que se llevó a cabo en el auditorio de la Dirección General
de Sistemas (DIGESI) de la UPeU Filial Juliaca. Para el 21 de junio ya se tenía
actualizado el diseño en UML de todo el sistema y desplegado en un servidor privado.
En dicho reporte UML también se indicó la Arquitectura de la aplicación donde cada
componente seguía los estándares de desarrollo previamente definidos. Así mismo,
se llevó a cabo la reunión de Project definition donde se aprobó el acta de constitución
del proyecto. Sin embargo, no podía iniciar el desarrollo mientras no se tenía el
backend de administración que el modelo WSM-DEV requiere.
Para fines de octubre del 2013 se publicó una versión beta del backend para
Django, que permitió iniciar el desarrollo el 04 de noviembre y terminar el 06 de
diciembre.
67
Para el 04 de noviembre se actualizó todo el diseño según los componentes de
seguridad y utilitarios de backend para Django, y también se actualizó el método de
trabajo del equipo entre otros documentos del proyecto.
5.4 Análisis de riesgos de seguridad
Dado que la aplicación web sería de tipo SaaS, se definió un backend para
administrar los permisos a los módulos y a los datos de diferentes empresas
productoras de fibra de alpaca. La lista de requisitos para el módulo backend web
seguro se muestra en el anexo B1.
La mayoría de los riesgos de seguridad a tener en cuenta en el backend web
seguro fueron tomados de la OWASP Top 10 del año 2013. La otra parte de la lista
de riesgos fue abstraída de experiencias personales vividas en diferentes proyectos
y diferentes frameworks como KumniaPHP, Hibernate, Spring Security, NHibernate,
Spring.Net, Flex, Silverlight, PrimeFace entre otros.
Estas características del backend y la lista base de riesgos, fue presentada,
discutida y validada en la reunión del Project definition. Con esta lista de riesgos de
seguridad se procedió a identificar los componentes de seguridad existentes para el
framework Django y evitar reinventar la rueda. El contenido de ambas listas se
muestra en los anexos B2 y B3.
Identificado los componentes se seguridad se procedió a diseñar estos
componentes y todo el módulo del backend sobre el framework Django, respetando
la arquitectura, los estándares y el estilo de codificación previamente definidos. El
anexo B10 muestra las tareas para el desarrollo del backend.
En la reunión de definición del backend web seguro, asistieron: La Dra. Gladys
Maquera Sosa representando a los Patrocinadores CONCYTEC y UPeU y a las
principales instituciones productoras de fibra de alpaca de la Región Puno. El Scrum
Master Ing. Abel Huanca Torres, y el Equipo Scrum conformado por Angel Sullón
Macalupú, Oscar Mendoza Apaza y Elvis Alí Vilca.
5.5 Implementación de los componentes de seguridad
Gran parte de las tareas de implementación fueron los estilos de cómo se usa
un componente de seguridad de Django y decidir por un estilo de programación que
guiaría el resto del proyecto.
La secuencia de comandos para proteger un activo fue asignada a
componentes con la finalidad de reutilizarlos y así minimizar las líneas de código. La
68
flexibilidad de algunos componentes permite integrar la seguridad al final del proyecto
como es el caso del componente para proteger los recursos del sistema tomando al
usuario y el lugar donde se encuentra. El registro de componentes de seguridad para
el backend se muestra en el Anexo B3.
A continuación se describen los riesgos y componentes de seguridad para el
backend. Los demos, la documentación y todo el código fuente puede ser revisada
en https://github.com/submitconsulting/backengo
5.5.1 SQL inyection
Los SELECT vulnerables toman los datos de entrada como válidos si pasar por
ningún filtro. OWASP recomienda usar una API que permita parametrizar los datos
de entrada por separado.
Django framework, cuenta con los métodos get, filter, exclude, etc. que
compara cada campo por separado. Por ejemplo:
User.objects.get(username=request.POST.get("username"),
password=request.POST.get("password"))
5.5.2 Pérdida de autenticación y gestión de sesiones
HTTP es un protocolo SIN ESTADO, esto significa que se tiene que usar una
SESSION para mantener el ESTADO para no estar autenticándose en cada pedido
HTTP. OWASP recomienda no exponer la SESSION ID en la red, en el navegador,
los logs, etc, así mismo, recomienda expirar y rotar la sesión y los tokens de
autenticación.
Por su parte, Django cuenta con los métodos login y logout para tales fines.
login(request, authenticate(username=request.POST.get("username"),
password=request.POST.get("password"))
Luego, desde cualquier petición HTTP, se puede acceder al token de
autenticación con:
user = request.user
Y para destruir la sesión:
logout(request)
69
5.5.3 Secuencia de comandos en sitios cruzados (XSS)
El atacante inyecta en el ingreso de datos secuencia de comandos, por lo
general JavaScript, que explotan el intérprete del navegador web. XSS permite a los
atacantes obtener contraseñas, llaves, token de sesión, redireccionar un usuario
hacia un sitio de malware o phishing. OWASP recomienda validar las entradas de
datos y seguir el estándar anatómico de un HTML (cuerpo, atributos, JavaScript,
CSS, o URL) para ubicar los datos no confiables.
Debido a que muchas aplicaciones requieren aceptar caracteres especiales
como parte de las entradas válidas, una solución óptima es escapar toda salida de
los datos a menos que se declare como dato confiable o sano o seguro (safe)
En Django, todas las salidas de datos son escapadas por defecto
{{ name }}
<input type="text" value="{{name}}">
Y para marcar como dato de salida seguro y quitar la protección XSS, Django
cuenta con el filtro safe:
{{ name|safe }}
5.5.4 Referencia directa insegura a objetos
Esto forma parte de realizar una AUTORIZACIÓN apropiada, junto con
Ausencia de Control de Acceso a las Funciones (5.5.7), los usuarios son capaces de
acceder a recursos y datos sin autorización. Un atacante modifica la URL o el valor
del parámetro que se refiere directamente a un objeto del sistema por otro objeto al
que no tiene acceso. OWASP recomienda comprobar el acceso con la lista de
accesos por cada usuario (identificadores de objeto, nombres de fichero o recursos).
Además de las recomendaciones de la OWASP, para una rápida protección al
acceso a datos se debe generar y comprobar llaves de seguridad combinada con el
valor de parámetro.
El sistema de seguridad avanzado de Django, protege a nivel de permiso las
acciones del usuario. Por ejemplo:
from django.contrib.auth.decorators import permission_required
@permission_required('polls')
def my_view(request):
70
if request.user.has_perm('polls.can_vote):
...
...
Esto mismo se puede realizar de muchas formas, incluso en las plantillas html,
entre otras ventajas.
Se dio mayor flexibilidad construyendo el componente decorador
@permission_resource_required, el cual identifica la URL actual y valida si el usuario
tiene o no permiso.
from apps.utils.decorators import permission_resource_required
@permission_resource_required
def my_view(request):
...
Con este componente se logra que la protección a los recursos se integre al
término de las tareas de desarrollo.
Para dar seguridad a datos, se diseñó un repositorio para el almacenamiento
temporal de identificadores claves a accesos a información clasificada denominada
UserToken. Por ejemplo, obtener el listado de las sedes de la empresa actual.
from apps.utils.security import UserToken
from apps.space.models import Headquar
headquar_list = Headquar.objects.filter(enterprise_id=UserToken.get_enterprise_id(request.session)).order_by("-id")
El otro componente de seguridad que da mayor seguridad es el componente
SecurityKey, que genera una llave de seguridad y la combina con el identificador de
los datos solicitados para luego validar la llave con la acción asociada.
Primero, en el tamplate se invoca al filtro key del templatetag app_security:
{% load app_security %}
<a href="{% url 'locality_delete' d.id|key:'locality_del' %}" ...
71
Y finalmente, al enviar la petición de eliminar; descifra el id del objeto a partir
de la llave recibida:
from apps.utils.security import SecurityKey
from django.core.exceptions import PermissionDenied
from apps.params.models import Locality
from django.shortcuts import get_object_or_404
def locality_delete(request, key):
id = SecurityKey.is_valid_key(request, key, "locality_del")
if not id:
raise PermissionDenied
try:
d = get_object_or_404(Locality, id=id)
d.delete()
except:
...
5.5.5 Configuración de seguridad incorrecta
Ocasionado por descuidos, desconocimientos y confianza ciega en el entorno
de producción. Las claves de seguridad son los mismos del entorno de desarrollo,
los archivos de ejemplos y URL conocidos están expuestos al público, la aplicación
muestra el detalle completo de los errores. Por suerte, los nuevos frameworks
permiten configurar estos parámetros de forma simple. OWASP recomienda usar
diferentes contraseñas para los entornos de Desarrollo, Aseguramiento de la calidad
(QA) y Producción. Una fuerte arquitectura de la aplicación que proporcione una
separación segura y efectiva entre los componentes. Y realizar auditorías
periódicamente para ayudar a detectar fallos de configuración.
Además de las recomendaciones de la OWASP, la configuración del entorno
de producción se debe instalar las dependencias necesarias, dejando fuera
herramientas de integración, depuración, pruebas entre otros. Esta práctica,
incrementa el tiempo de respuesta de las peticiones HTTP.
Django provee un archivo de configuración que maneja toda la aplicación
comúnmente denominado settings.py cuyas variables de configuración más
importantes son:
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = '#zqk3o8k!^3j)5g5r=rlt#xz@km+a7f5og$9(&_$69v@4^%4uh'
72
# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True #False
TEMPLATE_DEBUG = DEBUG
ALLOWED_HOSTS = ['*',]
DEBUG = True, indica un entorno de desarrollo donde Django muestra los
errores al detalle, si es False y si no se ha personalizado los errores, envía la página
de error 404. Esta variable puede ser usada para que los archivos estáticos de
terceros puedan ser llamados desde el servidor local o de un CNS. Por ejemplo, para
usar JQuery con un CDN sería:
<script src="//code.jquery.com/jquery-1.11.0.min.js"></script>
Esta práctica, incrementa la velocidad de carga.
5.5.6 Exposición de datos sensibles
Ocurre cuando no se cifran adecuadamente los datos sensitivos o cuando no
se identifican todos los lugares donde estos datos son almacenados.
También ocurre cuando una aplicación almacena archivos cifrados pero la
clave de cifrado es accesible. Por ejemplo el valor de la variable SECRET_KEY de
item anterior. Esta vulnerabilidad queda fuera del alcance de la OWASP. Sin embargo
recomienda aplicar algoritmos de cifrado fuertes y estándar así como claves fuertes
y gestionarlas de forma segura. Y finalmente, deshabilitar el autocompletar en los
formularios de recolectan datos sensibles.
Por suerte, Django mapea las URLs de la aplicación que son expuestos al
público, por lo tanto el archivo settings.py no se accede a través de una URL.
Python usa la librería hashlib para encriptar y desencriptar cadenas. Por
ejemplo:
import uuid
import hashlib
def hash_password(password):
# uuid is used to generate a random number
salt = uuid.uuid4().hex
return hashlib.sha256(salt.encode() + password.encode()).hexdigest() + ':' + salt
73
def check_password(hashed_password, user_password):
password, salt = hashed_password.split(':')
return password == hashlib.sha256(salt.encode() + user_password.encode()).hexdigest()
new_pass = raw_input('Please enter a password: ')
hashed_password = hash_password(new_pass)
print('The string to store in the db is: ' + hashed_password)
old_pass = raw_input('Now please enter the password again to check: ')
if check_password(hashed_password, old_pass):
print('You entered the right password')
else:
print('I am sorry but the password does not match')
Para el backend, solo se necesitó cifrar el password del usuario, y se aplicó el
componente set_password de Django, por ejemplo:
request.user.set_password(request.POST.get("password"))
Y para validar la autenticación, se usó el componente authenticate de Django:
from django.contrib.auth import authenticate, login, logout
if authenticate(username= request.POST.get("username "), password= request.POST.get("password")):
...
5.5.7 Ausencia de control de acceso a las funciones
Esto forma parte de realizar una AUTORIZACIÓN apropiada, junto con
Referencia directa Insegura a objetos (5.5.4), los usuarios son capaces de acceder a
recursos y datos sin autorización. Un atacante modifica la URL o el valor del
parámetro de una función con privilegios. Las recomendaciones del OWASP y los
componentes de seguridad son los mismos de la sección 5.5.4.
74
5.5.8 Falsificación de peticiones en sitios cruzados (CSRF)
Al igual que XSS, el atacante no necesariamente inyecta código en el envío de
datos, sino que manipulan el contenido de los datos de los parámetros de la URL
para realizar transacciones fraudulentas con o sin intención del usuario. Más aún,
estos datos pueden provenir de URLs maliciosos. OWASP recomienda la inclusión
de un token no predecible (secreto) en cada solicitud HTTP. Estos tokens deben ser,
como mínimo, únicos para cada sesión del usuario.
Django genera automáticamente un token secreto para cada sesión del usuario
y por defecto son validados en cada solicitud HTTP; es decir en cada acción o
método:
Para peticiones con formularios:
<form action="… >
{% csrf_token %}
</form>
Para peticiones asíncronas con Ajax:
$.ajaxSetup({
beforeSend: function(xhr, settings) {
if(settings.type == "POST"){
xhr.setRequestHeader("X-CSRFToken", getCookie('csrftoken'));
}
}
});
Para peticiones asíncronas con AngularJS:
angular.module('app', ['ngResource', 'ngRoute', 'ngCookies']).run(function ($http, $cookies) {
$http.defaults.headers.common['X-CSRFToken']= $cookies['csrftoken'];
});
Para desproteger CSRF:
from django.views.decorators.csrf import csrf_exempt
@csrf_exempt
def func_index(request):
"""
"""
75
5.5.9 Uso de componentes con vulnerabilidades conocidas
Algunos componentes de software (o frameworks de programación) son
vulnerables ante ataques conocidos, por ejemplo las vulnerabilidades Top 10 de
OWASP, entre otras vulnerabilidades. OWASP recomienda no usar componentes
que no ha codificado. Pero eso no es realista, por lo que todo proyecto de software
debería tener un proceso para identificar y revisar la seguridad de los componentes
que están usando, todo ello bajo políticas de seguridad que regulen el uso de
componentes.
5.5.10 Redirecciones y reenvíos no validados
Las redirecciones o reenvíos con parámetros hacia otras páginas o sitios web
del tipo http://example.com/login/?next=/facturas/cobranza son frecuentes. Si no
son validados, el atacante puede enviar a la víctima a un sitio de su elección, pasando
por alto los controles de seguridad. OWASP recomienda evitar el uso de
redirecciones y reenvíos, en caso de utilizar, no involucrar parámetros manipulables
por el usuario para definir el destino. Si los parámetros de destino no pueden ser
evitados, asegúrese que el valor suministrado sea válido y autorizado por el usuario.
Afortunadamente, los frameworks modernos como Django, mapean las URLs
autorizadas por la aplicación. Así, la URL http://example.com/facturas/cobranza
debe estar mapeado para ser reconocido como URL válido.
Toda aplicación Django mapea las URLs en el archivo urls.py. Por ejemplo:
from django.conf.urls import patterns, url
urlpatterns = patterns('apps.accounts.views',
url(r'^add_enterprise/$', 'add_enterprise', name='add_enterprise'),
url(r'^signup/$', 'signup_sys', name='signup_sys'),
url(r'^login/$', 'login_sys', name='login_sys'),
url(r'^load_access/(?P<headquar_id>.*)/(?P<module_id>.*)/$', 'load_access', name='load_access'),
url(r'^logout/$', 'logout_sys', name='logout_sys'),
url(r'^profile/edit/$', 'user_profile_edit', name='user_profile_edit'),
url(r'^choice_headquar/(?P<field>[\w\d\-]+)/(?P<value>.*)/$', 'choice_headquar', name='choice_headquar'),
url(r'^choice_headquar/$', 'choice_headquar', name='choice_headquar'),
)
76
5.5.11 Registro de sucesos incompletos
Los sucesos del sistema ocasionados por las acciones de los usuarios del
sistema deben ser guardados en bitácoras en un lugar seguro, que no está en
carpetas públicas donde los atacantes puedan tener acceso. Estos registros pueden
ser automáticos y manuales.
En Django, los registros de los sucesos automáticos se configura en la variable
LOGGING del archivo de configuración settings.py
LOGGING = {
...
'handlers': {
'file_django': {
'level': 'DEBUG',
'class': 'logging.FileHandler',
'filename': os.path.join(BASE_DIR, 'temp/logs',
'dj%s.txt' % (datetime.datetime.now().strftime("%Y-%m-%d"))),
'formatter': 'verbose_dj'
},
Y el registro de los sucesos manuales, mayormente son realizados cuando se
presenta alguna excepción:
import logging
from apps.utils.security import log_params
log = logging.getLogger(__name__)
…
try:
self.get_object()
except Exception, e:
log.warning(e, extra=log_params(self.request))
77
5.5.12 Datos incompletos
La falta de integridad en las transacciones de datos es frecuente, se debe hacer
pruebas de estas transacciones y asegurar que los datos se estén guardando de
forma correcta en todas las tablas de base de datos afectados.
En Django, una forma de asegurar la transacción de los datos es:
from django.db import transaction
@transaction.atomic
def user_add(request):
if request.method == "POST":
try:
sid = transaction.savepoint()
...
except Exception, e:
transaction.savepoint_rollback(sid)
message.error(request, e)
5.5.13 Permisos inconsistentes
Muchas veces se definen modelos de datos que no reflejan el control de
usuarios como el negocio requiere, siendo muy limitados y hasta fáciles de descifrar
por un atacante. Un buen diseño debe dificultar el entendimiento de un intruso de
sobre cómo se distribuyen los accesos.
La figura 17 muestra el modelo de datos que Django usa para el control
adecuado de accesos a sus usuarios.
78
Figura 17 – Modelo de autorización de usuarios Django
Django guarda los accesos a los métodos en la tabla de base de datos
Permission. Estos permisos están agrupados en la tabla Group y Group agrupa a los
usuarios en User. Así un usuario tiene accesos dependiendo de los Group asignados.
La figura 18 muestra el modelo de datos que el backend web seguro usa para
el control adecuado de accesos a sus usuarios en la nube.
class sad/models.py cloud
User
- last_headquar_id: CharField
- last_module_id: CharField
+ __unicode__( ) : self.username
django.contrib.auth.models::Group
+ __unicode__( ) : self.name
django.contrib.auth.models::
AbstractUser
- date_joined: DateTimeField
- email: EmailField
- first_name: CharField
- is_active: BooleanField
- is_staff: BooleanField
- last_name: CharField
- username: CharField
django.contrib.auth.models::
Permission
+ __unicode__( ) : self.name
+user_set 0..*
+groups
0..*+group_set 0..*
+permissions 0..*
79
Figura 18 – Modelo de autorización de usuarios de aplicaciones SaaS
En síntesis, el backend extiende la seguridad de Django para aplicaciones
SaaS, personalizando los servicios y los menús dinámicos del sistema. Esto permite
reutilizar y extender la funcionalidad de los componentes de seguridad de Django.
class sad/models.py cloud
User
- last_headquar_id: CharField
- last_module_id: CharField
+ __unicode__( ) : self.username
UserEnterprise
Module
+ __unicode__( ) : self.name
django.contrib.auth.models::Group
+ __unicode__( ) : self.name
space/models.py::Enterprise
- is_active: BooleanField
- is_actived: BooleanField
- logo: ImageField
- name: CharField
- tax_id: CharField
+ __unicode__( ) : self.name
space/models.py::Solution
- created_at: DateTimeField
- description: CharField
- is_active: BooleanField
- is_actived: BooleanField
- name: CharField
- price: FloatField
- test_date: DateTimeField
- test_image: ImageField
- updated_at: DateTimeField
+ __unicode__( ) : self.name
django.contrib.auth.models::
AbstractUser
- date_joined: DateTimeField
- email: EmailField
- first_name: CharField
- is_active: BooleanField
- is_staff: BooleanField
- last_name: CharField
- username: CharField
django.contrib.auth.models::
Permission
+ __unicode__( ) : self.name
params/models.py::Person
- birth_date: DateField
- first_name: CharField
- identity_num: CharField
- last_name: CharField
- photo: ImageField
+ __str__( ) : self.first_name, self.last_name, self.identity_num
Menu
+ __unicode__( ) : self.title
«enumeration»
MODULE_CHOICES
BACKEND = Backend Manager
WEB = Web informativa
VENTAS = Ventas
+userenterprise_set 0..*
+group 1
+module_set 0..*
+groups 0..*
+initial_groups_module_set 0..*
+initial_groups 0..*
+module_set 0..*
+solutions 0..*
+enterprise_set
0..*
+solution
0..1
+user_set 0..*
+groups
0..*
0..*
1
+userenterprise_set
0..*
+enterprise 1
+group_set 0..*
+permissions 0..*
+user 0..1
+person 0..1+menu_set 0..*
+parent 0..1
+menu_set 0..*
+permission 0..1
80
Como Django, guarda los accesos a los métodos en la tabla de base de datos
Permission. Estos permisos están agrupados en la tabla Group y Group agrupa a los
usuarios. Así un usuario tiene accesos dependiendo los Group asignados.
Los Group (perfil de usuario) son agrupados en Module, y los Module en
Solution. Cuando se asigna un Solution a una Enterprise, este conoce los Group y
Permission de sus Modules.
UserEnterprise, permite conocer los Group de un User para una Enterprise
actual. La Enterprise actual se almacena temporalmente en la clase UserToken
cuando el User la elija.
class UserToken:
"""
Clase que permite almacenar y recuperar los permisos a datos de las empresas solicitados por los usuarios.
"""
@staticmethod
def set_enterprise_id(request, enterprise_id):
request.session['enterprise_id'] = enterprise_id
@staticmethod
def get_enterprise_id(session):
return session.get('enterprise_id', False)
El método load_access permite cargar estos datos de forma segura:
from django.contrib.auth.decorators import login_required
from apps.sad.models import BACKEND
from apps.space.models import Headquar
@login_required(login_url="/accounts/login/")
def load_access(request, headquar_id, module_id):
...
# cargando permisos de datos para el usuario
headquar = Headquar.objects.get(id=headquar_id)
UserToken.set_enterprise_id(request, headquar.enterprise.id)
...
81
module = Module.objects.get(id=module_id)
if BACKEND == module.module:
return HttpResponseRedirect("/mod_backend/dashboard/")
...
Una vez que el usuario elija la Enterprise y el Module a la que está ingresando,
se carga el Menu para el User.
5.6 Demostración y validación de la seguridad
La Demostración y validación de la seguridad del backend, fueron realizados
en la reunión del Project definition para el proyecto Qualpaca.
En la pruebas de seguridad del módulo backend, de los 13 riesgos de seguridad
o vulnerabilidades identificados, todos fueron controlaron por completo por los
componentes de seguridad implementados.
Los nuevos riesgos de seguridad encontrados fueron respecto a las
particularidades de protección para los módulos del Qualpaca, lo cual se explica en
el siguiente capítulo.
En las pruebas de intrusión de módulo backend, de los 13 riesgos de seguridad
fueron mitigadas, logrando el 100% de vulnerabilidades mitigadas (respecto a las
trece vulnerabilidades).
Las líneas de código el que cumplen los estándares de codificación fueron
evaluados usando la herramienta PEP8 de Python. Logrando tener de 3 a 10 líneas
que no respetan los estándares de PEP8 de más de 100 líneas de código obteniendo
el 90% de cumplimiento.
En cuanto al cumplimiento del estilo de codificación de los métodos, no se
cuenta con herramientas para dicho cometido. Por lo que mediante una revisión
manual, se pueden observar el cumplimiento al 90%.
5.7 Resumen
El módulo backend web seguro definió las características arquitectónicas de
seguridad de una aplicación web, así como el estilo de codificación para el resto del
proyecto.
82
6 CAPÍTULO 6
VALIDACIÓN DEL MODELO PROPUESTO
WSM-DEV – PARTE 2
6.1 Introducción
En este capítulo se describe la aplicación y validación de la segunda parte del
modelo propuesto WSM-DEV; sobre los grupos de procesos 2, 3 y 4. La primera parte
del modelo se aplica y se valida en el anterior capítulo. A partir de este backend se
inicia el ciclo iterativo de los tres grupos de procesos del modelo WSM-DEV.
Para ambas partes se realizan mediante el desarrollo de una aplicación web
para la Cadena Productiva de Alpacas (patrocinado por CONCYTEC y la UPeU en
el año 2013) denominada “Qualpaca” versión 1.0
Con la aplicación y validación de esta segunda parte del modelo WSM-DEV se
logró refinar las actividades y artefactos de dicho modelo.
6.2 Análisis de riegos de seguridad
Luego de definir y validar los requisitos de Qualpaca, se analizaron los activos
de información que requieren de cierta protección, ya que el backend web seguro
contaba con componentes para dar seguridad a los recursos y datos que maneja
Qualpaca; es decir, el backend, permitió analizar directamente los riesgos de
seguridad para el negocio.
Estos entregables puede verse en los anexos C1 al C9. Además, se adjunta
parte de los demás entregables del proyecto en los anexos C10 al C12.
Para el desarrollo de la aplicación Qualpaca, por motivos de tiempo, no se
aplicó el TDD, es por eso que para distribuir las tareas se realizó el diseño del sistema
a partir de los componentes del backend web seguro. Cada componente del diseño
del sistema quedó debidamente documentado; las reglas de negocio y las
restricciones de seguridad, todo ello bajo el estilo de codificación y la arquitectura de
la aplicación.
83
Para una mejor distribución del mantenimiento de los registros de alpacas en
el sistema, se decidió asignar uno o más grupos de alpacas a un usuario técnico del
sistema, y como consecuencia se presentó el siguiente riesgo de seguridad: que otro
usuario técnico modifique los registros de alpacas de otro grupo de alpacas. Cuyo
impacto es alto, pues los datos de la alpaca son fundamentales para el mejoramiento
de la fibra.
6.3 Implementación de los componentes de seguridad
Mantener el registro de riesgos de seguridad, ayudó la implementación de los
componentes de seguridad. El motivo por la cual se incorpora en los requisitos es
justamente para su testeo y validación.
Para Qualpaca, solo se extendió la protección del componente UserToken con
la finalidad de validar la manipulación de datos no solo nivel de sucursal o sede o
rebaño, sino también a nivel de grupos o manadas de un rebaño.
El resto de actividades de la fase de implementación fueron las capacitaciones
para el uso adecuado de los componentes de seguridad del backend web seguro.
La revisión y validación de los componentes de seguridad durante la
implementación se realizó juntamente con las pruebas manuales por parte del equipo
de pruebas.
6.4 Demostración y validación de la seguridad
Los resultados de la fase de demostración y validación de la seguridad, fueron
realizados juntamente con la demostración y retrospectiva del Sprint de Scrum.
Los registros de riesgos de seguridad, y componentes de seguridad de los
anexos B2, B2, C2 y C3 fueron los checklist para verificar y validar los objetivos de
seguridad para la iteración. Como todo el desarrollo se hizo una iteración de 4
semanas, durante la semana 5, se hicieron las correcciones encomendadas.
En la pruebas de intrusión, de los 13 riesgos de seguridad del Backend, 12 se
controlaron por completo para los procesos de negocio del Proyecto Qualpaca. Esto
equivale al 92.30% de vulnerabilidades controladas o mitigadas. El riesgo de
seguridad RS03 Referencia Directa Insegura a Objetos no fue controlado a cabalidad
por lo que se agregó nuevos métodos al componente UserToken. Con este
componente se logró el 100% de vulnerabilidades mitigadas.
Se estimaron veinte (20) puntos historia para una Sprint de cuatro semanas,
logrando concretar todas las tareas en el plazo acordado, realizando así veinte
84
puntos-historia de un mes. Sin embargo, debido los cambios en los requerimientos
se tuvo que definir seis días más para dar por finalizado el proyecto.
Las líneas de código de Qualpaca que cumplen los estándares de codificación
fueron evaluados usando la herramienta PEP8 de Python. Logrando tener de
cincuenta a cien líneas que no respetan los estándares de PEP8 de más de 400
líneas de código obteniendo apenas un 75% de cumplimiento. Esto se debe a que
no se usó el PEP8 desde el inicio del proyecto.
En cuanto al cumplimiento del estilo de codificación de los métodos, no se
cuenta con herramientas para dicho cometido. Por lo que mediante una revisión
manual, se pueden observar el cumplimiento al 80%.
Se logró desarrollar los nueve artefactos que solicita el modelo entre otros
entregable que el Scrum requiere. Para la definición del proyecto Qualpaca se usó el
formato para el acta de constitución del proyecto del PMBoK (Project Management
Body of Knowledge).
6.5 Resumen
La aplicación del modelo WSM-DEV, gracias a sus plantillas y a su backend
profesional aceleró el desarrollo y se obtuvo una aplicación web moderna y confiable.
85
7 CAPÍTULO 7
RESULTADOS Y DISCUSIÓN
En este capítulo se presenta y se discute los resultados del presente trabajo de
tesis descritos en los capítulos 5, 6 y 7. Entre los principales resultado son:
7.1 Nuevo modelo práctico para desarrollar aplicaciones web seguras en el
menor tiempo.
El modelo propuesto denominado WSM-DEV, resume en 4 prácticas generales
la integración de la seguridad en el ciclo de vida de desarrollo de aplicaciones web,
mientras que la SSE-CMM contiene alrededor de 60 prácticas base de seguridad,
organizadas en 11 áreas de proceso que cubren las áreas principales de la ingeniería
de la seguridad. Lo que conlleva invertir mayores recursos de personal.
El modelo WSM-DEV provee de plantillas para cada uno de sus artefactos y,
de componentes de seguridad y utilitarios para la asignación directa de las tareas de
desarrollo de los requerimientos del negocio, permitiendo conocer la parte práctica
de cómo se aplica cada práctica; mientras que la SSE-CMM solo define qué prácticas
se debe emplear. La estrategia clave del modelo WSM-DEV consisten en
implementar primeramente el módulo backend mitigando trece vulnerabilidades de
toda aplicación web que correrá en la nube. Para el caso de implementación del
backend en el lenguaje de programación Python, estas vulnerabilidades se mitigaron
al 100% y para su aplicación en el proyecto Qualpca, este porcentaje se redujo al
92.30% debido a las particularidades de la seguridad del negocio de Qualpaca.
Así mismo, se intentó iniciar el desarrollo de Qualpaca sin contar con un
backend preliminar conduciendo a un desorden en los estándares y estilos de
codificación ya que cada programador hizo su mejor esfuerzo. Aunado al
desconocimiento de las principales vulnerabilidades y del lenguaje Python, se
comenzó a notar el retraso. Se contabilizó 6 meses de retraso (mayo a
noviembre/2013). Mientras se esperaba la primera versión del backend se fue
diseñando todo el sistema quedando cambios referentes al uso adecuado de los
componentes del backend. Terminado el backend para Django, se tuvo una semana
de capacitación y seguidamente se comenzó a desarrollar las tareas, cuya suma total
del trabajo de todas las tareas ascendió los 20 puntos historia, quedando terminado
en 5 semanas.
86
Las líneas de código de Qualpaca que cumplen los estándares de codificación
fueron evaluados usando la herramienta PEP8 de Python. Logrando tener de 50 a
100 líneas que no respetan los estándares de PEP8 de más de 400 líneas de código
obteniendo apenas un 75% de cumplimiento. Esto se debe a que no se usó el PEP8
desde el inicio del proyecto. En la depuración del backend se pudo usar la
herramienta PEP8 y se logró un 90% en el cumplimiento del uso adecuado del estilo
de codificación
En cuanto al cumplimiento del estilo de codificación de los métodos, no se
cuenta con herramientas para dicho cometido. Por lo que mediante una revisión
manual, se pueden observar el cumplimiento al 80% en el proyecto Qualpaca y a un
90% en el módulo backend
7.2 Módulo backend de administración y configuración de aplicaciones web
tipo SaaS con Django.
El módulo backend web seguro para Python del modelo WSM-DEV, cubre trece
vulnerabilidades recurrentes en aplicaciones web y con la flexibilidad de extender a
casos específicos del negocio; mientras que las API de seguridad para Java de la
OWASP cubre solo diez vulnerabilidades y algunas vulnerabilidades para PHP. Para
Java o PHP solo se cuenta con componentes pero ningún backend.
Se extendieron las funcionalidades de los componentes nativos de seguridad
de Python como de Django en nuevos componentes de seguridad con la finalidad de
definir un estilo de codificación simple pero robusta. También se crearon nuevos
complementos de seguridad para mitigar las trece vulnerabilidades identificadas en
aplicaciones web tipo SaaS. Todos los componentes de seguridad implementados
en el Backend mitigaron las trece vulnerabilidades previamente identificadas (en el
anexo B2) mitigando el 100% de vulnerabilidades (respecto a las trece
vulnerabilidades).
87
8 CAPÍTULO 8
CONCLUSIONES Y RECOMENDACIONES
En este capítulo se presenta las conclusiones principales de esta tesis, y
recomendaciones que orienten una mejor integración de la seguridad dentro del
proceso WSM-DEV, así como para nuevas investigaciones sobre la construcción de
aplicaciones web seguras.
8.1 Conclusiones
8.1.1 Se elaboró un modelo para el desarrollo de aplicaciones web seguras.
El modelo de Desarrollo de aplicaciones web seguras WSM-DEV, es el
principal aporte del trabajo de esta tesis. El modelo define cuatro principios y cuatro
prácticas de seguridad durante el ciclo de desarrollo para obtener una aplicación web
confiable en el menor tiempo. Los procesos del SSE-CMM guiaron la definición de
los componentes del WSM-DEV y las diez vulnerabilidades más frecuentes de la
OWASP definieron las características de una aplicación web confiable. Para una
aplicación rápida, se incluyen plantillas de los artefactos del modelo y una serie de
componentes de seguridad web implementados en el lenguaje de programación ágil
Python. La aplicación de este modelo en el proyecto Qualpaca, patrocinado por
CONCYTEC y la UPeU, se logró refinar sus actividades y artefactos y asignar un
peso adecuado a los indicadores de medición.
De los 13 riesgos de seguridad del backend, 12 se controlaron por completo
para los procesos de negocio del proyecto Qualpaca lo que equivale al 92.30% de
vulnerabilidades mitigadas. El riesgo que no fue completamente mitigado fue el RS03
Referencia directa insegura a objetos por lo que se agregó nuevos métodos al
componente de seguridad UserToken, logrando mitigar el 100% de vulnerabilidades
(respecto a las 13 vulnerabilidades previamente definidas).
8.1.2 La aplicación del modelo WSM-DEV es mucho más simple con modelos
ágiles de software.
El principal grupo de procesos del WSM-DEV es el análisis de riesgos de
seguridad, donde se identifican las amenazas y vulnerabilidades de la aplicación web
para la iteración; estas actividades pueden integrarse a las reuniones de planificación
de la iteración y seguir los procesos del desarrollo bajo una modelo de software ágil.
88
Sin embargo, también puede integrase a partir de la fase de requisitos en un modelo
de software formal de ingeniería.
8.1.3 Se desarrolló un backend web seguro sobre Django para aplicaciones web
de tipo SaaS
El módulo del backend para administrar aplicaciones web permite gestionar de
manera rápida y segura a los usuarios, perfiles, permisos, recursos del sistema,
módulos del sistema, menús dinámicos, empresas, sucursales entre otros
parámetros de configuración del sistema.
Este módulo se desarrolló en dos meses por una sola persona, y permitió la
implementación directa de los requisitos del proyecto Qualpaca, terminando en cinco
semanas todo el desarrollo.
El estilo de codificación del backend, permitió la concentración del equipo y
realizar las tareas del módulo de producción del proyecto Qualpaca. Logrando
desarrollar 20 puntos historia en un mes.
El cumplimiento de los estándares de codificación se verificó mediante la
herramienta PEP8 de Python, alcanzado un 90% del cumplimiento.
Finalmente, gracias al backend que sigue un estilo de codificación, pudo ser
interiorizado en todos los programadores alcanzando más del 80% del cumplimiento.
8.1.4 Se cuenta con un catálogo de componentes de seguridad
El catálogo de componentes de seguridad, especificado en el anexo B3, queda
como librerías útiles para ser aplicado o guía para las nuevas aplicaciones web que
mitigan trece principales vulnerabilidades de las aplicaciones web.
8.2 Recomendaciones
8.2.1 Completar los test automatizados para el backend web seguro
Para aplicar poder desarrollar una aplicación web completamente con TDD,
primero se debe terminar de implementar los test de unitarios del módulo backend.
8.2.2 Backend web seguro para arquitecturas Single Page Application (SPA)
El futuro de la web es JavaScript, con AngularJS como el framework más
popular; por lo que se necesita una backend con estas características.
89
8.2.3 Backend Web seguro con otros frameworks para Python u otros lenguajes
de programación.
Dado que en el mercado de Perú, los lenguajes de programación más
preferidos son .Net y Java, se requiere un backend sobre estas plataformas.
8.2.4 Antes de iniciar el desarrollo de un proyecto de software se necesita un
backend.
Para desarrollar un software, lo primero que el equipo de desarrollo debe contar
es con un backend con los componentes y librerías que una aplicación web necesita,
sobre todo, debe reflejar el estilo de codificación que facilitará la revisión de la calidad
del código. Este backend permite, atender directamente los requisitos del negocio.
Se recomienda definir una persona o un equipo que construya los nuevos
componentes y utilitarios comunes de la nueva aplicación e integrarlos en el backend
a modo de ejemplo, de modo que el equipo de desarrollo se concentre en atender
los requisitos del proyecto.
90
REFERENCIAS
Laudon K, Laudon J. 2012. Sistemas de Información Gerencial. 12° ed. México:
Pearson Educación. 640 p. ISBN 978-607-32-0949-6.
OWASP, 2013. Una Guía para Construir Aplicaciones y Servicios Web Seguros. The
Open Web Application Security Project [OWASP]. 4da ed. 311 p. Edición en
español
OWASP, 2013. OWASP Top 10 – 2013 Los diez riesgos más importantes en
Aplicaciones Web . 22 p. Edición en español
OWASP, 2008. Guía de Pruebas OWASP. 3ra ed. 372 p. Edición en español
OpenSAMM, 2010. Softwaer Assurance Maturity Model. OWASP. 1ra ed.
Ardi S, Shahmehri N, 2008. Integrating a Security Plug-in with the OpenUP/Basic
Development Process. Linköpings: Linköpings University. Department of
computer and information science. 8 p.
Ardi S, 2008. A Model and Implementation of a Security Plug-in for the Software Life
Cycle. Thesis No. 1353. Linköpings: Linköpings University. 124 p.
Gasca G. 2006. Análisis de Riesgos para el Desarrollo de Software Seguro.
Tovar E y colaboradores, 2006. Desarrollo de Productos de Software Seguros en
Sintonía con los Modelos SSE-CMM, COBIT E ITIL
ISO 27001, 2005. Tecnología de la Información – Técnicas de seguridad – Sistemas
de gestión de la información – Requerimientos. 1ra ed. 41 p. Uso para fines
didácticos.
ISO 17799, 2005. Tecnología de la Información – Técnicas de seguridad – Código
para la práctica de la gestión de la seguridad de la información. 2ra ed. 170
p.
Yepes R y Chavarría R, 2010. Un Enfoque para el Desarrollo Ágil de Aplicaciones
Web, Usando Scrum, Extreme Programing y Herramientas Open Source
sobre Plataforma Java: Caso de Estudio Mejoramiso Next. Facultad de
Ingeniería, Universidad de Antioquía
Schwaber K, Sutherland J. 2010. Scrum Guide: Scrum: Desarrollado y mantenido por
Ken Schwaber y Jeff Sutherland. 24 p.
Schwaber K, Sutherland J. 2011. Scrum Guide Update 2011. 1 p.
91
Schwaber K, Sutherland J. 2011. The Scrum Guide. The Definitive Guide to Scrum:
The Rules of the Game. 17 p.
Palacio J, Ruata C. 2011. Scrum Manager Gestión de Proyectos. Rev 1.4. 131 p.
Palacio J. 2007. Flexibilidad con Scrum. 229 p.
ISO 9000, 2005. Sistemas de gestión de la calidad – Fundamentos y vocabulario.
Ginebra, Suiza. 42 p.
Calderón M, 2007. Una Taxonomía de Requerimientos de Seguridad de Software.
Escuela de Ciencias de la Computación e Informática, Universidad de Costa
Rica. Artículo de 9 páginas.
Schwaber K. Agile Project Management with Scrum
Schwaber K. Agile Software Development with Scrum
Schwaber K. The Enterprise and Scrum
White S y Miers D, 2007. BPMN Guía de Referencia y Modelado. OMG, Quality
Softcover Perfect Bound. 226 p.
INTECO, 2010. Implantación de un SGSI en la empresa. Instituto Nacional de
Tecnologías de la Comunicación. España.
NEXUS, 2006. Parámetros fundamentales para la implantación de un Sistema de
Gestión de Seguridad de la Información según ISO 27001:2005
http://www.nexusasesores.com/docs/ISO27001-norma-e-implantacion-SGSI.pdf
visitado el 18 de abril de 2010.
NTP-ISO, 2006. Tecnología de la información. Procesos del ciclo de vida. (NTP-
ISO/IEC 12207:2006). 2da ed.
Barnum, S., McGraw, G., 2005, Knowledge for Software Security,IEEE Security &
Privacity, 74-78
McGraw, G., 2006, Software Security. Building Security In.
Viega J.; McGraw, G., 2001, Building Secure Software: How to avoid security
problems the right way,
Kan S. 1995. Metrics and Models in software Quality Engineering. Addison-Wesley
Kniberg H, Skarin M. 2010. Kanban y Scrum obteniendo lo mejor de ambos. C4Media
Inc. InfoQ. ISBN: 978-0-557-13832-6
Kniberg H. 2007. Scrum y XP desde las trincheras. C4Media Inc. InfoQ
92
Paulsson J, Westberg C. 2010. Secure Scrum During the Development of a
Configuration Tool for Generic Workflow.
Pressman R. 2002. INGENIERÍA DE SOFTWARE: UN ENFOQUE PRACTICO.
Shaw M., Garlan D. 1997. Software Architecture–Perspective son an Emerging
Discipline. Prentice Hall.
Succi G, Marchesi M. 2000. Extreme Programming Examined. IBM, 2011. Security
Compliance. http://www-01.ibm.com/software/tivoli/library/demos/
ibmscdemo/IBM_Security_Compliance.html Consultado el 04 de Octubre de
2011.
Llorente I, 2008. Seguridad en las Tecnologías de la Información. XX Seminario
“Duque de Ahumada” “Seguridad y Nuevas tecnologías”. http://dsa-
research.org/lib/exe/fetch.php?id=people%3Allorente%3Aresearch&cache=c
ache&media=people:llorente:seguridad_en_las_tecnologias_de_la_informaci
on.pdf, Consultado el 08 de Septiembre de 2011.
Cheng K. 2007. Baking in Security During the Systems Development Life Cycle. Booz
Allen Hamilton. [www.stsc.hill.af.mil/crosstalk/2007/03/index.html].
Consultado el 08 de Septiembre de 2011
Microsoft, 2011. Microsoft Security Development Lifecycle (SDL) – Process
Guidance. http://msdn.microsoft.com/en-
us/library/windows/desktop/84aed186-1d75-4366-8e61-8d258746bopq.aspx
Consultado el 08 de Septiembre de 2011
Microsoft, 2011. Security Development Lifecycle for Agile Development
http://msdn.microsoft.com/en-us/library/windows/desktop/ee790621.aspx
Consultado el 08 de Septiembre de 2011
Puyo R, 2009. Sistema de Gestión de la Seguridad de la Información SGSI ONP.
Oficina de Normalización Previsional – ONP.
http://www.pecert.gob.pe/archi/talle012009/04-caso-onp.pdf Consultado el 08
de Septiembre de 2011
Piñero B, 2009. La tecnología como facilitador del cumplimiento de los controles de
un SGSI. crsi.ie.edu/files/documentacion/Catedra_de-riesgos_Oracle.ppt
Consultado el 08 de Septiembre de 2011
Fernández J, 2006. OWASP –presentación del proyecto. Conferencias FIST
https://www.owasp.org/images/b/b6/OWASP-Testing-Project_v1.pdf
Consultado el 08 de Septiembre de 2011
93
Beck K y Colaboradores, 2001. Manifiesto por el Desarrollo Ágil de Software.
http://agilemanifesto.org/iso/es/. Consultado el 06 de Octubre de 2011.
Meier J y Colaboradores, 2007. MSF para desarrollo Ágil de software.
http://msdn.microsoft.com/en-us/library/bb668964.aspx Consultado el 06 de
Octubre de 2011.
Scott W. 2005. Scott W. Ambler's Home Page.
http://www.ambysoft.com/scottAmbler.html Consultado el 06 de Octubre de
2011
Palacio J, 2005. Procesos y técnicas para desarrollo de software.
http://www.navegapolis.net. Consultado el 06 de Octubre de 2011.
Qualys Guard. 2008. Web Application Scanning.
http://www.qualys.com/docs/QG_WAS_DS_ES.pdf. Consultado el 11 de
Octubre de 2011.
BConsultores, 2011. Arquitectura de Seguridad. Balarezo Consultores.
http://bconsultores.com/pages/arquitectura_de_seguridad.pdf Consultado el
11 de Octubre de 2011.
94
GLOSARIO
Riesgo: Es la estimación del grado de exposición de un activo o recurso, a que una
amenaza se materialice sobre él, causando daños a la organización. El riesgo indica
lo que le podría pasar a los activos si no se protegen adecuadamente.
Amenaza: Es la posibilidad de ocurrencia de cualquier tipo de evento o acción que
puede producir daño (material o inmaterial) sobre los elementos (activos, recursos)
de un sistema.
Vulnerabilidad: Son las debilidades, las condiciones y características del sistema
mismo (incluyendo la entidad que lo maneja), que lo hace susceptible a amenazas,
con el resultado de sufrir algún daño.
Impacto: Es la consecuencia de la materialización de una amenaza sobre un activo.
Riesgo intrínseco: Es la posibilidad de que se produzca un impacto determinado en
un activo.
Salvaguarda: Son las prácticas, procedimientos o mecanismos que reducen el
riesgo y disminuyen el impacto y la probabilidad.
Riesgo residual: Es el riesgo que queda tras la aplicación de salvaguardas.
Ataque: Es una amenaza que se convirtió en realidad, es decir cuando un evento se
realizó. No dice nada si o no el evento fue exitoso.
Autenticidad: La legitimidad y credibilidad de una persona, servicio o elemento debe
ser comprobable.
Confidencialidad: Datos solo pueden ser legibles y modificados por personas
autorizados, tanto en el acceso a datos almacenados como también durante la
transferencia de ellos.
Integridad: Datos son completos, non-modificados y todos los cambios son
reproducibles (se conoce el autor y el momento del cambio).
Disponibilidad: Acceso a los datos debe ser garantizado en el momento necesario.
Hay que evitar fallas del sistema y proveer el acceso adecuado a los datos.
Elementos de información: También “Activos” o “Recursos” de una institución que
requieren protección, para evitar su pérdida, modificación o el uso inadecuado de su
95
contenido, para impedir daños para la institución y las personas que salen en la
información. Se distingue y divide tres grupos, a) datos e información, b) sistemas e
infraestructura y c) personal.
Gestión de riesgo: Método para determinar, analizar, valorar y clasificar el riesgo,
para posteriormente implementar mecanismos que permitan controlarlo. Está
compuesta por cuatro fases: 1) análisis, 2) clasificación, 3) reducción y 4) control de
riesgo.
Seguridad informática: Procesos, actividades, mecanismos que consideran las
características y condiciones de sistemas de procesamiento de datos y su
almacenamiento, para garantizar su confidencialidad, integridad y disponibilidad.
Auditoría de seguridad: Permitir el registro de eventos (hay que identificar cuáles
pueden ser interesantes desde el punto de vista de la seguridad).
Gestión de seguridad: Definición de perfiles de usuario y niveles de acceso
asociados.
Autodefensa: La aplicación debe incluir sistemas de validación de su funcionamiento
y fallar de manera segura si esa validación no se cumple.
Control de acceso: Soporte de sistemas que limiten el número y tipo de sesiones,
el nivel de concurrencia y que proporcionen información sobre sesiones anteriores al
usuario para ayudar a la detección de intrusos.
Estándares de desarrollo: Define estratégicamente el nombre de los identificadores
del sistema, como son variables, clases, funciones, tablas, contantes, etc.
Estilo de codificación: Provee un orden de las instrucciones del programa para una
clase o método, en función de los estándares de desarrollo.
UML: Es el lenguaje de modelado de sistemas de software más conocido y utilizado
en la actualidad; está respaldado por el OMG (Object Management Group).
96
9 ANEXOS
10 Anexo 1 – Matriz de consistencia del proyecto
Título de la investigación: “Un modelo para el desarrollo de aplicaciones web seguras”
Problema Objetivo Marco teórico Indicadores Metodología
¿Cuales son las
dificultades para
aplicar las guías
o modelos de
seguridad?
O. General.
Elaborar un modelo de
trabajo práctico para
desarrollar aplicaciones
web seguras (menores
vulnerabilidades) y en el
menor tiempo basadas
en los procesos de la
metodología SSE-CMM,
el Proyecto OWASP y
experiencias vividas.
Objetivos específicos:
Analizar las prácticas del
SSE-CMM respecto al
ciclo de vida del
desarrollo de software.
Implementar los
controles de seguridad
según la OWASP top 10
para un
lenguaje/framework
específico.
Establecer los principios
y prácticas del modelo a
proponer.
Refinar el modelo
mediante su aplicación
en un proyecto web tipo
SaaS.
Antecedentes:
SSE-CMM
OWASP
Porcentajes de
vulnerabilidades
controladas
Tipo de
investigación:
Aplicada
Método:
Investigación
Evaluativa
Velocidad del
equipo ágil de
desarrollo
¿Por qué las
aplicaciones con
requisitos
complejos y con
límites de tiempo
han contribuido al
incremento de
fallas o
vulnerabilidades
de software?
Porcentaje de
métodos que
cumplen el estilo
de codificación
Porcentaje de
líneas de código
el que cumplen
los estándares
de codificación
¿Cuales son las
causas que
ocasionana
grandes pérdidas
monetarias, y
hasta la pérdida
de confianza de
los clientes,
empleados y
socios de
negocio?
97
Anexo A1 – Requisitos del sistema
Proyecto: ______ --_______________________________________________________
Fecha de actualización: ____/_____/______
Código/Sprint
Requisito Estado Estimac. Prioridad
RF01 /1
Requisito 1: Descripción: Pruebas de aceptación y de seguridad: 1. 2.
Nuevo 8 puntos historia
1000
RF02 /1
Requisito 2: Descripción: Pruebas de aceptación y de seguridad: 1. 2.
En Progreso
6 puntos historia
900
RF03 /1
Requisito 3: (reemplazo por RF04) Descripción: Pruebas de aceptación y de seguridad: 1. 2.
Retirado 4 puntos historia
800
RF04 /2
Requisito 4: (cambio en reemplazo de la RF03) Descripción: Pruebas de aceptación y de seguridad: 1. 2.
Hecho 4 puntos historia
700
98
Anexo A2 - Registro de riesgos de seguridad (amenazas y vulnerabilidades)
Proyecto: ______ --_______________________________________________________
Fecha de actualización: ____/_____/______
COD Riesgo de seguridad Tipo (A/V)
Probabilidad
Impacto
Prioridad
1000
A: Amenza V: Vulnerabilidad
Probabilidad: Alta, Media, Baja
Impacto: Alta, Media, Baja
99
Anexo A3 - Registro de componentes de seguridad
Proyecto: ______ --_______________________________________________________
Fecha de actualización: ____/_____/______
COD Componente de seguridad
Riesgos de seguridad
100
Anexo A4 – Arquitectura de la aplicación
1. Información general
Código y nombre del proyecto:
2. Historial de revisiones
Versión - Fecha - Elaborado por
3. Arquitectura de la aplicación MTV (equivalente a MVC)
Capa Tecnología Función
Modelo: M Django Model Entidades y mapeamientos
Django Manager Extiende utilitarios del Model
Django Test/Unit Test Pruebas unitarias del modelo
Vista: V Django View Django Form
Controlador de solicitudes y respuestas Reglas de negocio y restricciones
SAD Backend Solicitudes y respuestas con AJAX Restricciones de seguridad Logs Mensajería y Notificaciones
Django Test Pruebas de integración de las vistas y de los formularios
Template: T Django Template Interfaces gráficas de usuario para las entradas de datos y mostrar resultados
Bootstrap Diseño responsivo multidispositivo
JQUERY Utilitarios diversos
AJAX+ JSON Solicitudes y respuestas asíncronas
SAD Frontend Solicitudes y respuestas con AJAX Generación de objetos HTML en tiempo de ejecución Hojas de estilos personalizados
Selenium Pruebas funcionales en la Web
101
Anexo A5 – Estándares de desarrollo
1. Información general
Código y nombre del proyecto:
2. Historial de revisiones
Versión - Fecha - Elaborado por
3. Términos de definición de identificadores
ID Término Ejemplo
Proyecto <nombre_proyecto> agil_cont
Paquetes <nombre_carpeta> catalogo_productos
Base de datos <nombre_db> agil_cont_db
Tablas <prefix_nombre_tabla> common_natural_person
Atributo PK id id
Atributo <nombre_atributo> functional_code
Atributo FK <tabla>_id natural_person_id
Paquetes <nombre_carpeta> catalogo_productos
Clases <NombreClase><NombreCapa/vacio> class NaturalPerson
Variables <nombre_variable> functional_code
Contantes <NOMBRE_CONSTANTE> DEFAULT="DNI"
Método <nombre_metodo>(var_nombre) def add(); def edit(); def delete(); def get_by_id(id); def get_list_by_filter(filter);
Enumerators <NOMBRE_ENUM> DEFAULT="DNI" CE="CE" OTHERS="OTHERS" IDENTITY_CHOICES = ( (DEFAULT, "D.N.I."), (CE, "C.E."), (OTHERS, "Otro.") )
Archivos <nombre_pagina>.<py/html> natural_person.html
Interfaces I<NombreClase><NombreCapa/vacio> INaturalPersonService
102
Anexo A6 – Método de trabajo del equipo
1. Información general
Código y nombre del proyecto:
2. Historial de revisiones
Versión - Fecha - Elaborado por
3. Equipo de trabajo
Rol Nombre Ciudad Correo/Celular Tiempo
Product Owner Nombre del cliente 50%
Scrum Master Nombre del Jefe del proyecto 50%
Dupla 1-Doc. Nomb. Programador 1 Nomb. Programador 2
50% 50%
Dupla 2-Dev. Nomb. Programador 3 Nomb. Programador 4
100% 100%
Dupla 3-Dev. Nomb. Programador 5 Nomb. Programador 6
50% 50%
4. Herramientas
Elemento Herramienta Hosting
Portal de gerenciamiento
Assembla.com https://www.assembla.com/spaces/djangobackend
Portal de integración
Github.com https://github.com/submitconsulting/django_backend_project
Modelo y Prototipado
Enterprise Architect 7.5 Balsamiq
http://djangobackend-model.appspot.com
Lenguaje de programación
Python
Frameworks Django 1.6.2
Framework responsivo
Bootstrap
Base de datos MySQL 5.x
IDE Sublime Text 2
Comunicaciones Facebook https://www.facebook.com/groups/262927820527361
103
5. Retos a superar
Desafío Solución
Respecto a la metodología scrum Definir la duración del sprint a 4 semanas Lea la wiki y utilice el foro de discusión del portal de gerenciamiento (Mensajes)
Respecto al equipo distribuido (parcial o totalmente, horarios, idiomas diferentes)
Definir las tareas en base a una unidad de trabajo diario o semanal (que incluya testes) Informar el estado de las tareas en el portal de gerenciamiento, incluye horas restantes. Enviar el reporte de trabajo diario o semanal (StandUp) Documentación en inglés Consigue una llamada con Hangout, Facebook o Skype
Respecto a las herramientas de trabajo
Entrenamiento en las herramientas a usar
Respecto a la experiencia de los desarrolladores
Cada código, diagrama, prototipos debe seguir el estándar de desarrollo elegido Entrenamiento en las tecnologías a usar
Respecto a la documentación El diseño/prototipo/restricciones deben estar listos y validados a un Sprint de anticipación
Falta de compromiso del cliente Involucrar al cliente en las reuniones y demos
104
Anexo A7 – Prototipos principales
Proyecto:
Módulo:
Fecha:
Requisito 1:
Imagen N°
Funcionalidad:
Aprobado por:
105
Anexo A8 – Diseño del sistema
1 INFORMACIÓN GENERAL
Código y Nombre del proyecto:
2 HISTORIAL DE REVISIONES
Versión - Fecha
3 ACTUALIZACIONES IMPORTANTES
4 LINKS DE DESCARGA O DE CONSULTA
Modelo [http://djangobackend-model.appspot.com/DBackend-20131115/index.htm]
Scripts
5 ESTRUCTURA DEL MODELO
Módulo
---Modelo del dominio
--- ---app
--- --- ---Diagrama de entidades
---Modelo de clases
--- ---Capa(si es Models o Views(Views en MVC es Controllers))
--- --- ---app
--- --- --- ---Diagrama de clases de diseño
--- --- --- --- ---Ejemplo completo del diagrama (explica las relaciones a detalle)
---Requisitos
--- ---Requisitos funcionales
--- ---Requisitos no funcionales
---Interfaz de usuario
--- ---Capa(template para django)
--- --- ---app
--- --- --- ---entity o rol
--- --- --- --- ---prototipo(.html)
Diagrama Vista general del proyecto
Diagrama de procesos de negocio
106
Anexo A9 – Formulario de lecciones aprendidas
Proyecto:
N° Iteración:
Qué salió bien en la Iteración 1. 2.
Qué no salió bien en la Iteración 1. 2.
Qué mejoras vamos a implementar en la siguiente Iteración 1. 2.
107
Anexo B1 – Requisitos del Sistema (módulo backend web seguro)
Proyecto: Backengo
Fecha de actualización: __04__/__09__/__2013__
Código/Sprint
Requisito Estado Estimac. (horas)
Prioridad
RF01 /1
Gestión de permisos de usuarios Descripción: Permite distribuir determinados permisos a un Grupo de usuarios para que puedan utilizar a ciertas funcionalidades específicas del sistema según los permisos asignados a dicho Grupo. Para ello: Definir los recursos (permisos en django) del sistema a partir del módulo "auth" de django Definir los Grupos de usuarios a partir del módulo "auth" de django Definir los permisos de los Grupos de usuarios. Pruebas de aceptación y de seguridad: 1.
Hecho
RF02 /1
Gestión de los planes de servicios SaaS Descripción: Permite distribuir accesos a los usuarios de una determinada empresa y/o asociación para que pueda utilizar ciertas funcionalidades del sistema según los permisos asignados a un determinado Plan de servicio. Para ello: Definir los Módulos de la aplicación Definir los Permisos de los Módulos Definir el grupo de módulos denominado Plan de servicio (Solution) Definir los Módulos del plan (Solution) Pruebas de aceptación y de seguridad: 1.
Hecho
RF03 /1
Gestión de menús dinámicos Descripción: Permite definir el Menú de los módulos para facilitar al usuario el acceso a las funcionalidades del sistema Para ello: Definir Menú para los recursos del sistema y organizados por Módulos Pruebas de aceptación y de seguridad: 1. Cuando se elige el módulo y la sede o empresa o asociación se debe visualizar el Menú del usuario según los Permisos asignados al usuario para dicha Sede/empresa/asociación y Módulo.
Hecho
RF04 /1
Abir una cuenta en el sistema Descripción: Permite abir una cuenta para un nuevo usuario, nueva asociación y nueva empresa para que pueda utilizar las funcionalidades del sistema según el plan de servicio escogido. Pruebas de aceptación y de seguridad:
Hecho
RF05 /1
Inicio de sesión Descripción: Permite iniciar sesión de la aplicación web que sirva para utilizar ciertas funcionalidades específicas del sistema para el usuario registrado. Pruebas de aceptación y de seguridad:
Hecho
108
1. Cuando se inicia sesión de la aplicación web, Se debe cumplir que si usuario ingresa nombre de usuario y contraseña correctas, se presenta el mensaje "Bienvenido, "+nombre de usuario, mostrando la lista de empresas junto con los módulos a los cuales tiene permiso. 2. Cuando se inicia sesión de la aplicación web, Se debe cumplir que si usuario ingresa nombre de usuario incorrecto o contraseña incorrecta, se presenta el mensaje "Usuario o contraseña incorrectos".
RF06 /2
Gestión de la estructura organizacional para la nube Descripción: Permite establecer la estructura de la organiación en asociaciones, empresas y sedes Para ello: Permite que la asociación defina otras empresas Permite que la empresa agregue otras sedes, y para diversas asociaciaciones Permite que la asociación/empresa cambie de Plan de servicio Permite que la asociación/empresa/sede defina usuarios bajo ciertos perfiles o permisos Pruebas de aceptación y de seguridad:
Hecho
RF07 /2
Gestión de usuarios Descripción: Permite establecer los usuarios del sistema según los roles y las sedes/empresas/asociaciones permitidas. Para ello: Registrar, bloquear, reactivar usuarios a partir del módulo "auth" de django y bajo los permisos preasignados a la sede/empresa/asociación que se está administrando. Estas validaciones de los permisos se logra gracias a los:
Componentes para asegurar los recursos de la aplicación
Componentes para asegurar los datos de las empresas (Token de acceso a datos)
Permite visualizar el seguimiento de los motivos de bloqueos y activaciones de los usuarios Permite la actualización del perfil de usuario y contraseña Pruebas de aceptación y de seguridad: 1.
Hecho
RF08 /2
Gestión de sucesos del sistema Descripción: Permite tener el registro de sucesos del sistema que guarde información de las acciones de los usuarios. Para ello: Permite el registro, en archivos logs y tablas de base de datos, de las acciones de los usuarios y las respuestas del sistema durante el uso de la aplicación Permite la visualización de los sucesos filtrados por día.
Hecho
RF09 /2
Recuperar contraseña Descripción: Permite recuperar contraseña del usuario para que pueda iniciar sesión en la aplicación web.
Hecho
109
Anexo B2 - Registro de riesgos de seguridad (amenazas y vulnerabilidades)
Proyecto: Backengo
Fecha de actualización: __04__/__09__/__2013__
COD Riesgo de seguridad Tipo (A/V)
Probabilidad
Impacto
Prioridad
RS01 Inyección A Alta Alta 1000
RS02 Pérdida de Autenticación y Gestión de Sesiones A Alta Alta 1000
RS03 Secuencia de Comandos en Sitios Cruzados(XSS) A Alta Alta 1000
RS04 Referencia Directa Insegura a Objetos A Alta Alta 1000
RS05 Configuración de Seguridad Incorrecta A Alta Alta 1000
RS06 Exposición de Datos Sensibles A Alta Alta 1000
RS07 Ausencia de Control de Acceso a las Funciones A Alta Alta 1000
RS08 Falsificación de Peticiones en Sitios Cruzados(CSRF)
A Alta Alta 1000
RS09 Uso de Componentes con Vulnerabilidades Conocidas
A Alta Alta 1000
RS10 Redirecciones y reenvíos no validados A Alta Alta 1000
RS11 Repudio A Alta Alta 1000
RS12 Datos incompletos A Alta Alta 1000
RS13 Permisos inconsistentes A Alta Alta 1000
A: Amenza V: Vulnerabilidad
Probabilidad: Alta, Media, Baja
Impacto: Alta, Media, Baja
110
Anexo B3 - Registro de componentes de seguridad
Proyecto: Backengo
Fecha de actualización: __04__/__09__/__2013__
URL de la documentación de los componentes de seguridad:
http://educaci-dns.com:8001/admin/doc
COD Componente de seguridad Riesgos de seguridad
CS01 Django model.objects.filter Inyección
Django request. session
Pérdida de Autenticación y Gestión de Sesiones
django.contrib.auth.authenticate
django.contrib.auth.login
django.contrib.auth.logout.
apps.utils.security.UserToken
django form Secuencia de Comandos en Sitios Cruzados(XSS)
django filter safe
apps.utils.decorators.permission_resource_required
Referencia Directa Insegura a Objetos
apps.utils.security. SecurityKey
Django request. POST
Django.forms. ModelForm
apps.utils.decorators.permission_resource_required
Configuración de Seguridad Incorrecta
apps.utils.security. SecurityKey
Django settings.DEBUG
django.conf.urls.url
Exposición de Datos Sensibles
apps.utils.decorators.permission_resource_required
Ausencia de Control de Acceso a las Funciones
apps.utils.security. SecurityKey
Django csrf_token Falsificación de Peticiones en Sitios Cruzados(CSRF)
crispy form
Uso de Componentes con Vulnerabilidades Conocidas
django.conf.urls.url Redirecciones y reenvíos no validados
apps.utils.decorators.permission_resource_required
111
Anexo B4 – Arquitectura de la aplicación
1. Información general
Código y Nombre del proyecto: Backengo
Desarrollo de un Backend web seguro para Django
2. Historial de revisiones
Versión - Fecha - Elaborado por
1.0 04/04/2013 – Angel Sullón
3. Arquitectura de la aplicación MTV (equivalente a MVC)
Capa Tecnología Función
Modelo: M Django Model Entidades y mapeamientos
Django Manager Extiende utilitarios del Model
Django Test/Unit Test Pruebas unitarias del modelo
Vista: V Django View Django Form
Controlador de solicitudes y respuestas Reglas de negocio y restricciones
SAD Backend Solicitudes y respuestas con AJAX Restricciones de seguridad Logs Mensajería y Notificaciones
Django Test Pruebas de integración de las vistas y de los formularios
Template: T Django Template Interfaces gráficas de usuario para las entradas de datos y mostrar resultados
Bootstrap Diseño responsivo multidispositivo
JQUERY Utilitarios diversos
AJAX+ JSON Solicitudes y respuestas asíncronas
SAD Frontend Solicitudes y respuestas con AJAX Generación de objetos HTML en tiempo de ejecución Hojas de estilos personalizados
Selenium Pruebas funcionales en la Web
112
Anexo B5 – Estándares de desarrollo
1. Información general
Código y Nombre del proyecto: Backengo
2. Historial de revisiones
Versión - Fecha - Elaborado por
1.0 04/04/2013 – Angel Sullón
3. Términos de definición de identificadores
ID Término Ejemplo
Proyecto <nombre_proyecto> agil_cont
Paquetes <nombre_carpeta> catalogo_productos
Base de datos <nombre_db> agil_cont_db
Tablas <prefix_nombre_tabla> common_natural_person
Atributo PK id id
Atributo <nombre_atributo> functional_code
Atributo FK <tabla>_id natural_person_id
Paquetes <nombre_carpeta> catalogo_productos
Clases <NombreClase><NombreCapa/vacio> class NaturalPerson
Variables <nombre_variable> functional_code
Contantes <NOMBRE_CONSTANTE> DEFAULT="DNI"
Método <nombre_metodo>(var_nombre) def add(); def edit(); def delete(); def get_by_id(id); def get_list_by_filter(filter);
Enumerators <NOMBRE_ENUM> DEFAULT="DNI" CE="CE" OTHERS="OTHERS" IDENTITY_ CHOICES = ( (DEFAULT, "D.N.I."), (CE, "C.E."), (OTHERS, "Otro.") )
Archivos <nombre_pagina>.<py/html> natural_person.html
Interfaces I<NombreClase><NombreCapa/vacio> INaturalPersonService
113
Anexo B7 – Prototipos principales
Proyecto: Backengo
Módulo: Backend, app: accounts
Fecha:14/08/2013
Requisito 1: Mostar información resumida del proyecto
Funcionalidad: Muestra la página de inicio del proyecto
Aprobado por:
Documentación en http://backenddj-model.appspot.com/BackendDJ-20140514/index.htm
El código fuente puede descargar gratuitamente de: https://github.com/submitconsulting/backenddj y https://github.com/submitconsulting/backengo (versión actual)
ui 1-index.html
114
Proyecto: Backengo
Módulo: Backend, app: accounts
Fecha:14/08/2013
Requisito 2: Ingreso al sistema
Funcionalidad: Incia sesión de usuario
Aprobado por:
ui 2-login.html
115
Proyecto: Backengo
Módulo: Backend, app: accounts
Fecha:14/08/2013
Requisito 3: Apertura de Cuentas del sistema
Funcionalidad: Registra nuevo usuario
Aprobado por:
ui 3-signup.html
116
Proyecto: Backengo
Módulo: Backend, app: accounts
Fecha:14/08/2013
Requisito 4: Restablecer contraseña
ui 4-password_reset.html
ui 5-password_reset-done.html
117
Funcionalidad: Reestablace contraseña del usuario
Aprobado por:
ui 6-reset
ui 7-reset-done
118
Proyecto: Backengo
Módulo: Backend, app: accounts
Fecha:14/08/2013
Requisito 5: Elegir sede y módulo
Funcionalidad: Permite elegir empresa y módulo a administrar
Aprobado por:
ui 8-choice_headquar.html
ui 11-dashboard.html
119
Proyecto: Backengo
Módulo: Backend, app: accounts
Fecha:14/08/2013
Requisito 6: Agregar nueva empresa y nueva asociación al usuario actual
Funcionalidad:
Aprobado por:
ui 9-add_enterprise.html
120
Proyecto: Backengo
Módulo: Backend, app: accounts
Fecha:14/08/2013
Requisito 7: Editar perfil del usuario
Funcionalidad:
Aprobado por:
ui 10-profile_edit.html
121
Proyecto: Backengo
Módulo: Backend, app: space
Fecha:14/08/2013
Requisito 8: Editar datos de la asociación
Funcionalidad:
Aprobado por:
ui 12-edit_current.html
122
Proyecto: Backengo
Módulo: Backend, app: space
Fecha:14/08/2013
Requisito 9: Gestión de empresas
ui 13.1-index.html
ui 13.2-add.html
123
Funcionalidad:
Aprobado por:
ui 14-edit_current.html
124
Proyecto: Backengo
Módulo: Backend, app: space
Fecha:14/08/2013
Requisito 10: Gestión de sedes
Funcionalidad:
Aprobado por:
ui 15.1-index.html
ui 15.2-add.html
125
Proyecto: Backengo
Módulo: Backend, app: sad
Fecha:14/08/2013
Requisito 11: Gestión de usuarios
ui index.html
126
ui add.html
ui person_search.html
127
Proyecto: Backengo
Módulo: Backend, app: sad
Fecha:14/08/2013
Requisito 12: Gestión de recursos del sistema
Funcionalidad:
Aprobado por:
ui index.html
ui add.html
128
Proyecto: Backengo
Módulo: Backend, app: sad
Fecha:14/08/2013
Requisito 13: Gestión de perfiles de usuario
Funcionalidad:
Aprobado por:
ui index.html
ui add.html
129
Proyecto: Backengo
Módulo: Backend, app: sad
Fecha:14/08/2013
Requisito 14: Configuración de privilegios de perfiles de usuario
Funcionalidad:
Aprobado por:
ui permissions_edit.html
130
Proyecto: Backengo
Módulo: Backend, app: sad
Fecha:14/08/2013
Requisito 15: Gestión de módulos del sistema
Funcionalidad:
Aprobado por:
ui index.html
ui add.html
131
Proyecto: Backengo
Módulo: Backend, app: space
Fecha:14/08/2013
Requisito 16: Gestión de soluciones o servicios SaaS
Funcionalidad:
Aprobado por:
ui 21.1-index.html
ui 21.2-add.html
132
Proyecto: Backengo
Módulo: Backend, app: sad
Fecha:14/08/2013
Requisito 17: Configuración de planes del sistema
Funcionalidad:
Aprobado por:
ui plans_edit
133
Proyecto: Backengo
Módulo: Backend, app: sad
Fecha:14/08/2013
Requisito 18: Gestión de menús dinámicos del sistema
Funcionalidad:
Aprobado por:
ui index.html
ui add.html
134
Proyecto: Backengo
Módulo: Backend, app: sad
Fecha:14/08/2013
Requisito 19: Configuración del sistema
Funcionalidad:
Aprobado por:
ui basic.html
135
Proyecto: Backengo
Módulo: Backend, app: sad
Fecha:14/08/2013
Requisito 20: Gestión de copias de seguridad de base de datos
Funcionalidad:
Aprobado por:
ui index.html
136
Proyecto: Backengo
Módulo: Backend, app: sad
Fecha:14/08/2013
Requisito 21: Seguimiento de accesos al sistema
Funcionalidad:
Aprobado por:
ui index.html
137
Proyecto: Backengo
Módulo: Backend, app: sad
Fecha:14/08/2013
Requisito 22: Seguimiento de auditoria
Funcionalidad:
Aprobado por:
ui index.html
ui list.html
138
Proyecto: Backengo
Módulo: Backend, app: sad
Fecha:14/08/2013
Requisito 23: Seguimiento de log del sistema
Funcionalidad:
Aprobado por:
ui index.html
ui list.html
139
Proyecto: Backengo
Módulo: Backend, app: params
Fecha:14/08/2013
Requisito 24: Gestión de localidades
Funcionalidad:
Aprobado por:
ui index.html (report_pre)
ui add.html
ui report.html
140
Anexo B8 – Diseño del sistema
1 INFORMACIÓN GENERAL
Código y Nombre del proyecto: Backengo
2 HISTORIAL DE REVISIONES
Versión - Fecha
1.0 – 12-12-13
3 ACTUALIZACIONES IMPORTANTES
4 LINKS DE DESCARGA O DE CONSULTA
Modelo: http://backenddj-model.appspot.com/BackendDJ-20140514/index.htm
Scripts
5 ESTRUCTURA DEL MODELO
Módulo Backend: Este módulo consta de las siguientes aplicaciones:
---Modelo del dominio
141
--- ---params
--- --- ---Diagrama de entidades
--- ---sad
class params
backenddj
Locality
- is_active: Boolean
- location: Text
- modified_in: DateTime
- msnm: Float
- name: Char
- registered_at: DateTime
- utm: Char
Person
- birth_date: Date
- first_name: Char
- identity_num: Char
- last_name: Char
- modified_in: DateTime
- photo: Image
- registered_at: DateTime
Datos comunes de las personas naturales
(Clientes, Cta Ctes, Alumnos, Empleados,
etc.) y jurídicas (Clientes, Proveedores, etc )
LocalityType
- name: Char
«enumeration»
IDENTITY_TYPES
DEFAULT = DNI
CE = Carnet de extra...
PART_NAC = Partida de naci...
OTHERS = Otros
+identity_type
0..*
+locality_type
0..1
Nombre:
Paquete:
Versión:
Autor:
params
params
1.0
Asullom
142
--- --- ---Diagrama de entidades
--- ---space
--- --- ---Diagrama de entidades
class sad
django.contrib
backenddj
space::Headquar(sede)
- address: Text
- is_active: Boolean
- is_main: Boolean
- modified_in: DateTime
- name: Char
- phone: Char
- registered_at: DateTime
auth::User
- date_joined: datetime
- email: string
- first_name: string
- is_active: boolean
- is_staff: boolean
- is_superuser: boolean
- last_login: datetime
- last_name: string
- password: string
- username: string
auth::Group
- name: string
auth::Permission
- codename: string
- name: string
django::ContentType
- app_label: string
- model: string
- name: string
Menu
- description: Text
- icon: Char
- is_active: Boolean
- pos: Integer
- title: Char
- url: Char
UserProfileHeadquar
- registered_at: DateTime
«enumeration»
MODULES
WEB = Web informativa
VENTAS = Ventas
BACKEND = Backend Manager
equivale a Categoría del
Recurso
name=table name
app_label= app o module
model=model o controller
Aqui van las acciones: add,
change, delete convertidos en
recursos de la forma
/<app>/<controller>/<action>/
Equivale a Perfi l
Module
- description: Text
- icon: Char
- is_active: Boolean
- name: Char
los permisos del usuario referente a la
manipulación de información de la sede.
Se le da al usuario acceso a una sede tantos
perfi les(group) sea necesario: el grupo que
es asignado, automáticamente debe asignar
en user-groups
user-groups
los permisos del usuario
referente a los recursos(perm)
del sistema a través de Group.
Filtar los permisos de los
UserProfi le*.
Group-Permissions
los permisos (recursos+acciones)
definidos para el grupo=RecursoPerfi l
User-User_Permissions
nunca usar esta relacion, todo
se manejará a través de grupos
space::Enterprise
- is_active: Boolean
- logo: Image
- modified_in: DateTime
- name: Char
- registered_at: DateTime
- tax_id: Char
UserProfileEnterprise
- group: Group
- registered_at: DateTime
Análogo a
UserProfi leHeadqu
art pero para
Empresas
space::Solution
- description: Text
- is_active: Boolean
- name: Char
UserProfileAssociation
- group: Group
- registered_at: DateTime
space::Association
- is_active: Boolean
- logo: Image
- modified_in: DateTime
- name: Char
- registered_at: DateTime
Análogo a
UserProfi leHeadquart
pero para Asociación
Profile
- last_headquar_id: Char
- last_module_id: Char
params::Person
- birth_date: Date
- first_name: Char
- identity_num: Char
- last_name: Char
- modified_in: DateTime
- photo: Image
- registered_at: DateTime
extension security on cloud
0..*
1
+group_set
0..*
+permissions 0..*
+user_set
0..*
+groups0..*
+user_set
0..*
+user_permissions
0..*
0..*
1
0..*
+user 1
0..*
+permission 1
0..*
1
0..*
+user
1
0..*
+parent
0..1
0..*
1
+permission_set
0..*
+content_type 1
0..1
+user
1
0..*0..1
+initial_groups_module_set
0..*
+initial_groups
0..*
+module_set 0..*
+groups0..*
0..*
0..1
0..*
+group1
0..*
+user1
+module_set
0..*
+solutions
0..*
0..1
+person 1
0..*
0..1
Nombre:
Paquete:
Versión:
Autor:
sad
sad
1.0
Asullom
143
---Modelo de clases. Está dividido en dos capas
--- ---Models Layer
class space
backenddj
Enterprise
- is_active: Boolean
- logo: Image
- modified_in: DateTime
- name: Char
- registered_at: DateTime
- tax_id: Char
Headquar(sede)
- address: Text
- is_active: Boolean
- is_main: Boolean
- modified_in: DateTime
- name: Char
- phone: Char
- registered_at: DateTime
params::Locality
- is_active: Boolean
- location: Text
- modified_in: DateTime
- msnm: Float
- name: Char
- registered_at: DateTime
- utm: Char
«enumeration»
TYPES
GOVERMENT = Gobierno
PRIVATE = Privada
MIXED = Mixta
OTHERS = Otros
Example:
UPeU, UNI, UNMSM, etc.
Association
- is_active: Boolean
- logo: Image
- modified_in: DateTime
- name: Char
- registered_at: DateTime
Example:
UPeU Lima, UPeU Juliaca, UPeU Tarapoto, etc.
Permite que el empresario pueda manejar varias sedes y pertenecer a una o más asociaciones
IMPORTANTE: Una empresa existe si tiene una o más sedes, todo se trabaja en función a la sede (Headquart)
Solution
- description: Text
- is_active: Boolean
- name: Char
+type_e
0..*0..1
0..*
0..1
0..*
0..1
0..*
+type_a 1
+headquar_set
0..*
+locality
0..1
0..*
1
Nombre:
Paquete:
Versión:
Autor:
space
space
1.0
Asullom
144
--- --- ---params
--- --- --- ---Diagrama de clases de diseño
--- --- --- --- ---Ejemplo completo del diagrama (explica las relaciones a detalle)
class params/models.py
backenddj
Model
«models.py»
Locality
+ __unicode__( ) : self.name,self.location
Model
LocalityType
+ __unicode__( ) : self.name
Person
+ __unicode__( ) : self.first_name
+locality_set 0..*
+locality_type 0..1
Nombre:
Paquete:
Versión:
Autor:
params/models.py
params/models.py
1.0
Asullom
145
--- --- ---sad
--- --- --- ---Diagrama de clases de diseño
--- --- ---space
--- --- --- ---Diagrama de clases de diseño
class params.models
params/models.py::LocalityType
+ __unicode__(self : ) : self.name
«models.py»
params/models.py::Locality
+ __unicode__(self : ) : self.name,self.location
Seguir las técnicas de codeo del ejemplo para Locality
en params.models.py y la guía pep8
django.db.models::Model
+ delete() : Entity
+ mucho_más() : void
+ objects.fi lter(condition1 : , conditionN : ) : objects<Entity>
+ objects.get(id :int) : Entity
+ save() : Entity+locality_set 0..*
+locality_type 0..1
class sad/models.py
backenddj
Module
+ __unicode__( ) : self.name
Menu
+ __unicode__( ) : self.title
UserProfileHeadquar
UserProfileEnterprise
UserProfileAssociation
space/models.py::Solution
+ __unicode__( ) : self.name
django.contrib.auth.models::Group
+ __unicode__( ) : self.last_name
django.contrib.auth.models::
Permission
+ __unicode__( ) : self.last_name
django.contrib.auth.models::User
+ __unicode__( ) : self.username
space/models.py::Headquar(sede)
+ __unicode__( ) : self.name
space/models.py::Association
+ __unicode__( ) : self.name
space/models.py::Enterprise
+ __unicode__( ) : self.name
django.contrib.auth.models::
ContentType
+ __unicode__( ) : self.last_name
Profile
+ __unicode__( ) : self.user.username
params/models.py::Person
+ __unicode__( ) : self.first_name
+profile
0..1+user
1
+headquar_set 0..*
+enterprise 1
+association_set 0..*
+solution
0..1
+enterprise_set 0..*
+solution 0..1
+module_set
0..*
+solutions 0..*
+module_set 0..*
+groups
0..*
+initial_groups_module_set
0..*
+initial_groups
0..*
+menu_set 0..*
+parent 0..1
+headquar_set
0..*
+association
0..1
+permission_set 0..*
+content_type 1
+profile 0..1
+person 1
+menu_set
0..*
+permission
0..1
+user_set 0..*
+groups 0..*
+userprofileheadquart_set 0..*
+group
1
+userprofileenterprise_set
0..*
+group
1
+userprofileassociation_set
0..*+group
1
+userprofileheadquart_set
0..*
+user
1
+userprofileheadquart_set
0..*
+headquart 1
+group_set 0..*
+permissions
0..*
Nombre:
Paquete:
Versión:
Autor:
sad/models.py
sad/models.py
1.0
Asullom
146
--- ---Views Layer
--- --- ---accounts
--- --- --- ---Diagrama de clases de diseño
Metodo Notas Parámetro
s
add_enterprise() Enterprise in
render_to_response("accounts/add_enterprise.ht
ml", c), Redirect.to(request,
"/accounts/choice_headquar/")
Public
1° Inicializar Enterprise
2° Obtener el listado de Solution activos
ordenados por "id" y mostrarlos en el template
add_enterprise.html
3° Obtener Association.TYPES y mostrarlos en
el template add_enterprise.html
-Si method="POST":
rq [in]
request
class space/models.py
backenddj
Headquar(sede)
+ __unicode__( ) : self.name
Association
+ __unicode__( ) : self.nameEnterprise
+ __unicode__( ) : self.name
Solution
+ __unicode__( ) : self.name
Model
«models.py»
params/models.py::Locality
+ __unicode__( ) : self.name,self.location
+headquart_set
0..*+locality
0..1
+enterprise_set 0..*
+solution 0..1
+association_set 0..*
+solution 0..1
+headquar_set 0..*
+enterprise 1
+headquar_set 0..*
+association 0..1
Nombre:
Paquete:
Versión:
Autor:
space/models.py
space/models.py
1.0
Asullom
class accounts/v iews.py
#login
+ choice_headquar(request, field, value) : page< HeadquarLite> in render_to_response("accounts/choice_headquar.html", c)
+ load_access(request, headquar_id, module_id) : HttpResponseRedirect("/accounts/choice_headquar/") | Redirect.to("/mod_<name>/dashboard/")
+ login_sys(request) : render_to_response("accounts/login.html", c), HttpResponseRedirect("/accounts/choice_headquar/") | load_access
+ logout_sys(request) : HttpResponseRedirect("/")
+ user_profile_edit(request) : User in render_to_response("accounts/profile_edit.html", c), to("/accounts/choice_headquar/")
#registro de las cuentas de usuario
+ add_enterprise(request) : Enterprise in render_to_response("accounts/add_enterprise.html", c), Redirect.to(request, "/accounts/choice_headquar/")
+ signup_sys(request) : Person in render_to_response("accounts/signup.html", c), redirect("/accounts/login/")
Nombre:
Paquete:
Versión:
Autor:
accounts/views.py
accounts/views.py
1.0
Asullom
147
1° Obtener User actual con request.user
2° Si existe otro Association con el mismo
"name", retornar exception informando que el
"name" del Association ya existe
3° Salvar Association
4° Si existe otro Enterprise con el mismo
"name", retornar exception informando que el
"name" del Enterprise ya existe
5° Si existe otro Enterprise con el mismo
"tax_id", retornar exception informando que el
"tax_id" del Enterprise ya existe
6° Salvar Enterprise
7° Crear una Headquar con el name="Principal",
con la Association y Enterprise recien creadas
8° Salvar Headquar
9° Salvar los Group de la sede (de acuerdo a
la Solution elegida) en UserProfileHeadquar
10° Salvar los Group de la empresa (de acuerdo
a la Solution elegida) en
UserProfileEnterprise
11° Salvar los Group de la asociación (de
acuerdo a la Solution elegida) en
UserProfileAssociation
12° Salvar los Group de la sede, empresa y
asociación, evitando Group repetidos, usando
User.groups.add(Group)
#Si hay algun exception mantener datos
enviados en el template add_enterprise.html
sin hacer cambios en la DB
signup_sys() Person in
render_to_response("accounts/signup.html", c),
redirect("/accounts/login/")
Public
1° Si el usuario ya está is_authenticated,
intentar cargar el último acceso cargando
directamente la sede y el módulo anterior,
sino cargar
HttpResponseRedirect("/accounts/choice_headqua
r/")
2° Inicializar Person
3° Obtener el listado de Solution activos
ordenados por "id" y mostrarlos en el template
signup.html
4° Obtener Association.TYPES y mostrarlos en
el template signup.html
5° Obtener el Person.DEFAULT de
Person.IDENTITY_TYPES y mostrarlos en el
template signup.html
-Si method="POST":
1° Si existe otro User con el mismo
"username", retornar exception informando que
el "username" del User ya existe
2° Si existe otro User con el mismo "email",
retornar exception informando que el "email"
del User ya existe
3° Salvar User
4° Si existe otro Person con el mismo
"identity_num" y "identity_type", retornar
exception informando que ya existe un Person
con "identity_num" y "identity_type"
5° Si existe otro Person con el mismo
"first_name", "last_name" , "identity_num" y
"identity_type", retornar exception informando
que el Person ya existe. Use normalize
6° Salvar Person
7. Salvar Profile con User del 3er paso y con
Person del 6to paso
8° Si existe otro Association con el mismo
"name", retornar exception informando que el
"name" del Association ya existe
9° Salvar Association
10° Si existe otro Enterprise con el mismo
"name", retornar exception informando que el
"name" del Enterprise ya existe
11° Si existe otro Enterprise con el mismo
"tax_id", retornar exception informando que el
"tax_id" del Enterprise ya existe
12° Salvar Enterprise
13° Crear una Headquar con el
name="Principal", con la Association y
Enterprise recien creadas
14° Salvar Headquar
15° Salvar los Group de la sede (de acuerdo a
la Solution elegida) en UserProfileHeadquar
16° Salvar los Group de la empresa (de acuerdo
a la Solution elegida) en
rq [in]
request
148
UserProfileEnterprise
17° Salvar los Group de la asociación (de
acuerdo a la Solution elegida) en
UserProfileAssociation
18° Salvar los Group de la sede, empresa y
asociación, evitando Group repetidos, usando
User.groups.add(Group)
#Si hay algun exception mantener datos
enviados en el template signup.html sin hacer
cambios en la DB
#login
Metodo Notas Parámetr
os
choice_headquar() page< HeadquarLite> in
render_to_response("accounts/choice_headquar
.html", c)
Public
1° Obtener el listado paginado de HeadquarLite
filtrado según los parámetros enviados,
ordenado por "-association__name","-
enterprise__name","-id" y mostrar en el
template choice_headquar.html
HeadquarLite={
"association": headquar.association,
#Asociaciones del user en la cuales colabora
"enterprise": headquar.enterprise, #Empresas
de del user en la cuales colabora
"headquar": headquar, #Sedes del user en la
cuales colabora
"modules": module_list, #módulos a la cual el
user tiene acceso
"groups": group_list, #perfiles del usuario
}
rq [in]
request
str [in]
field
str [in]
value
load_access()
HttpResponseRedirect("/accounts/choice_headq
uar/") |
Redirect.to("/mod_<name>/dashboard/")
Public
1° Validar que la petición no sea con ajax,
sino, informar que ESTA OPERACION NO DEBE SER
CARGADO CON AJAX, Presione F5
2° Validar si Headquar existe en la BD, sino,
retornar exception informando que Headquar no
fué encontrado
3° Validar si Module existe en la BD, sino,
retornar exception informando que Module no
fué encontrado
4° Si el user no es superuser: (si
is_superuser tiene acceso a todo)
4.1 Validar el usuario tiene acceso a la
Headquar, sino, retornar exception informando
que No tiene privilegio para ingresar a la
Headquar
4.2 Validar el usuario tiene acceso al
Module del Headquar del paso 4.1, sino,
retornar exception informando que No tiene
privilegio para ingresar al Module
5° Cargar permisos de datos para el usuario:
DataAccessToken.set_association_id(req
uest, headquar.association.id)
DataAccessToken.set_enterprise_id(requ
est, headquar.enterprise.id)
DataAccessToken.set_headquar_id(reques
t, headquar.id)
6° Intentar Obtener Profile del User para
Salvar Profile indicando la ultima sede y el
ultimo módulo a la que ingresó el User
(last_headquar_id = headquar_id,
last_module_id = module_id), si el User no
tiene Profile, crearle uno nuevo.
7° Cargar dashboard del módulo seleccionado
rq [in]
request
str [in]
headquar_
id
str [in]
module_id
login_sys()
render_to_response("accounts/login.html", c),
HttpResponseRedirect("/accounts/choice_headq
uar/") | load_access
Public
1° Inicializar User
2° Si el usuario ya está is_authenticated,
intentar cargar el último acceso cargando
directamente la sede y el módulo anterior (de
Profile), sino cargar
HttpResponseRedirect("/accounts/choice_headqua
r/")
-Si method="POST":
1° Recuperar el d.username si el usuario está
logeándose mediante email.
rq [in]
request
149
2° Autenticar al usuario usando
django.contrib.auth.authenticate(username=d.us
ername, password=password) y
django.contrib.auth.login, sino, retornar
exception informando que la Contaseña no es
válido, o el usuario no existe o no está
activo.
3° Salvar Access con los datos requeridos
4° Si la variable "next" no es nulo ni vacío
cargar al método indicado en dicha variable.
5° Cargar en Message el saludo de bienvenida.
6° Intentar cargar el último acceso cargando
directamente la sede y el módulo anterior,
sino cargar
HttpResponseRedirect("/accounts/choice_headqua
r/")
#Si hay algun exception mantener datos
enviados en el template login.html
#El input para login y passwd solo debe
permitir valores alpanuméricos más la @,
evitando la posibilidad de codigo injection
SQL
#Validar {% csrf_token %}
logout_sys() HttpResponseRedirect("/")
Public
1° Cerrar sesión con
django.contrib.auth.logout(request)
rq [in]
request
user_profile_edit() User in
render_to_response("accounts/profile_edit.html
", c), to("/accounts/choice_headquar/")
Public
1° Obtener User actual con request.user
2° Intentar obtener Profile con User.id del
paso 1° si existe, sino dejar pasar sin
obtener datos del Profile del User
3° Obtener el listado de Group ya asignados de
User para las Headquar ( si tuviese) en
UserProfileHeadquar y mostrarlos en el
template profile_edit.html
4° Obtener el listado de Group ya asignados de
User para las Enterprise ( si tuviese) en
UserProfileEnterprise y mostrarlos en el
template profile_edit.html
5° Obtener el listado de Group ya asignados de
User para las Association ( si tuviese) en
UserProfileAssociation y mostrarlos en el
template profile_edit.html
6° Obtener Person.IDENTITY_TYPES y mostrarlos
en el template profile_edit.html
-Si method="POST":
1° Si existe otro User con el mismo "email",
retornar exception informando que el "email"
del User ya existe
2° Salvar User
3° Obtener Person a través de User.profile,
sino Salvar un Person nuevo
4. Obtener Profile a través de User, sino
Salvar un Profile nuevo con el User del paso
2° y Person del paso 3°
5° Si existe otro Person con el mismo
"first_name", "last_name" , "identity_num" y
"identity_type", retornar exception informando
que el Person ya existe. Use normalize
6° Si existe otro Person con el mismo
"identity_num" y "identity_type", retornar
exception informando que ya existe un Person
con "identity_num" y "identity_type"
7° Volver a Salvar Person con los datos
recibidos del formulario
#Si hay algun exception mantener datos
enviados en el template profile_edit.html sin
hacer cambios en la DB
rq [in]
request
--- --- ---mod_backend
--- --- --- ---Diagrama de clases de diseño
150
Metodo Notas Parámetros
mod_backend_dashboard()
render_to_response("mod_backend/dashboard.html",
c)
Public
rq [in]
request
--- --- ---params
--- --- --- ---Diagrama de clases de diseño
Metodo Notas Parámetros
locality_add() Locality in
render_to_response("params/locality/add.html",
c), to_action("index")
Public
1° Inicializar Locality
2° Obtener el listado de todos los
LocalityType ordenado por name para
mostrar en el template add.html
-Si method="POST":
1° Si existe otro Locality con el mismo
rq [in] request
class mod_backend/v iews.py
#mod_backend_dashboard
+ mod_backend_dashboard(request) : render_to_response("mod_backend/dashboard.html", c)
Nombre:
Paquete:
Versión:
Autor:
mod_backend/views.py
mod_backend/views.py
1.0
Asullom
151
name, retornar exception informando que el
name del Locality ya existe
#Si hay algun exception mantener datos
enviados en el template add.html
2° Salvar Locality
Código inicial:
d = Locality()
if request.method == "POST":
...
if normalize("NFKD", u"%s" %
d.name).encode("ascii", "ignore").lower()
in list(
normalize("NFKD", u"%s" %
col["name"]).encode("ascii",
"ignore").lower() for col in
Locality.objects.values("name").exclude(id
= d.id) #puede .filter()
):
raise
Exception(_("Locality <b>%(name)s</b>
name's already in use.") %
{"name":d.name})
d.save()
locality_type_list =
LocalityType.objects.all()
c = {
"page_module":_("Locality"),
"page_title":_("New locality."),
"d":d, #Si hay algun exception
mantener datos enviados en el template
"locality_type_list":locality_type_list,
}
locality_delete() to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave
es incorrecta
2° Validar si Locality existe en la BD,
sino, retornar exception informando que
Locality no fué encontrado
3° Validar si Locality no tiene
dependencias con otras tablas, sino,
retornar exception informando que Locality
está asignado en la tabla donde fué
encontrada
4° Eliminar Locality
Código inicial:
id = Security.is_valid_key(request, key,
"locality_del")
d = get_object_or_404(Locality, id=id)
if d.headquart_set.count() > 0:
raise Exception( ("Localidad
<b>%(name)s</b> está asignado en
headquart.") % {"name":d.name} )
d.delete()
rq [in] request
str [in] key
locality_edit() Locality in
render_to_response("params/locality/edit.html",
c), to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave
es incorrecta
2° Validar si Locality existe en la BD,
sino, retornar exception informando que
Locality no fué encontrado
3° Obtener el listado de todos los
LocalityType ordenado por name para
mostrar en el template edit.html
-Si method="POST":
1° Si existe otro Locality con el mismo
name, retornar exception informando que el
name del Locality ya existe
#Si hay algun exception mantener datos
enviados en el template edit.html
2° Salvar Locality
Código inicial:
id = Security.is_valid_key(request, key,
"locality_upd")
d = get_object_or_404(Locality, id=id)
if request.method == "POST":
...
if normalize("NFKD", u"%s" %
rq [in] request
str [in] key
152
d.name).encode("ascii", "ignore").lower()
in list(
normalize("NFKD", u"%s" %
col["name"]).encode("ascii",
"ignore").lower() for col in
Locality.objects.values("name").exclude(id
= d.id) #puede .filter()
):
raise
Exception(_("Locality <b>%(name)s</b>
name's already in use.") %
{"name":d.name})
d.save()
locality_type_list =
LocalityType.objects.all()
c = {
"page_module":_("Locality"),
"page_title":_("Update locality."),
"d":d,#Si hay algun exception mantener
datos enviados en el template
"locality_type_list":locality_type_list,
}
locality_index() page< Locality> in
render_to_response("params/locality/index.html",
c)
Public
1° Obtener el listado paginado de Locality
filtrado y ordenado según los parámetros
enviados y mostrar en el template
index.html
Código inicial:
value_f = "" if value == "None" else value
column_contains = u"%s__%s" %
(field,"contains")#WHERE column LIKE %an%
locality_list =
Locality.objects.filter(**{
column_contains: value_f
}).order_by(order)
paginator = Paginator(locality_list, 25)
locality_page =
paginator.page(request.GET.get("page"))
c = {
"page_module":_("Locality"),
"page_title":_("Localities list."),
"locality_page":locality_page,
"field":field,
"value":value.replace("/", "-"),
"order":order,
}
rq [in] request
str [in] field
str [in] value
str [in] order
locality_report() objects< Locality> in
render_to_response("params/locality/report.html",
c)
Public
1° Obtener el listado de Locality filtrado
y ordenado según los parámetros enviados y
mostrar en el template report.html
Código inicial:
value = "" if value == "None" else value
column_contains = u"%s__%s" %
(field,"contains")
locality_list =
Locality.objects.filter(**{
column_contains: value }).order_by(order)
c = {
"page_module":_("Locality"),
"page_title":_("Localities report."),
"locality_list":locality_list,
}
rq [in] request
str [in] field
str [in] value
str [in] order
locality_state() to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave
es incorrecta
2° Validar si Locality existe en la BD,
sino, retornar exception informando que
Locality no fué encontrado
3° Actualizar el campo Locality.is_active
para False/True
Código inicial:
id = Security.is_valid_key(request, key,
"locality_%s" % state )
d = get_object_or_404(Locality, id=id)
d.is_active = (True if state ==
"reactivar" else False)
d.save()
rq [in] request
str [in] state
str [in] key
153
--- --- --- --- ---Ejemplo completo del diagrama (explica las relaciones a detalle)
--- --- ---sad
--- --- --- ---Diagrama de clases de diseño
class params.v iews
params/v iews.py::#locality
+ locality_add(request) : Locality in render_to_response("params/locality/add.html", c), to_action("index")
+ locality_delete(request, key) : to_action("index")
+ locality_edit(request, key) : Locality in render_to_response("params/locality/edit.html", c), to_action("index")
+ locality_index(request, field, value, order) : page< Locality> in render_to_response("params/locality/index.html", c)
+ locality_report(request, field, value, order) : objects< Locality> in render_to_response("params/locality/report.html", c)
+ locality_state(request, state, key) : to_action("index")
«package»
django.shortcuts::Package
+ redirect(forward) : void
+ render_to_response(template, data, context) : void
django.http::
HttpResponse
- contents: String
- status_code
- template: List
django.http::
HttpResponseRedirect
- url: String
python::Context
- data: Dictionary
python::Template
+ render(context) : String
python::RequestContext
- request: HttpRequest
apps.utils.messages.py::Message
+ critical(request, msg, audit) : void
+ debug(request, msg, audit) : void
+ error(request, msg, audit) : void
+ info(request, msg, audit) : void
- set_msg(request, type, msg, audit) : void
+ warning(request, msg, audit) : void
templatetags::notify.py
+ get_notify(request) : message[]
python::logging
Seguir las técnicas de codeo
del ejemplo para Locality en
params.views.py y la guía
pep8
Model
params/models.py::LocalityType
+ __unicode__(self) : self.name
Model
«models.py»
params/models.py::Locality
+ __unicode__(self) : self.name,self.location
django.core.paginator::Paginator
+ page(current_page) : page
+ Paginator(list, per_page) : Paginator
python::Exception
apps.utils::decorators.py
+ is_admin(view_func) : wrapped
+ permission_resource_required(function, template_denied_name) : decorator(view_func)
- permission_resource_required_decorator(template_denied_name) : decorator(view_func)
templatetags::app_security.py
+ key(id, action_name) : Security.get_key(id, action_name)
apps.utils.security.py::Security
+ get_key(id, action_name) : string
+ is_valid_key(request, key_value, action_name) : void
apps.utils.security.py::Redirect
+ to(request, route, params) : return methodToCall(request) | return redirect(path)
+ to_action(request, action_name, params) : return methodToCall(request) | return redirect(path)
django.db::transaction.py
+ commit_on_success() : decorator(view_func)
django.contrib::
messages.py
+locality_set 0..*
+locality_type 0..1
Nombre:
Paquete:
Versión:
Autor:
params.views
locality (ejemplo completo)
1.0
Asullom
154
#group Metodo Notas Parámetro
s
group_add() Group in
render_to_response("sad/group/add.html", c),
to_action("index")
Public
1° Inicializar Group
-Si method="POST":
1° Si existe otro Group con el mismo "name",
retornar exception informando que el "name"
del Group ya existe
#Si hay algun exception mantener datos
enviados en el template add.html
2° Salvar Group
rq [in]
request
group_delete() to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
incorrecta
2° Validar si Group existe en la BD, sino,
retornar exception informando que Group no
fué encontrado
3° Validar si Group no tiene dependencias
con otras tablas, sino, retornar exception
informando que Group está asignado en la
tabla donde fué encontrada
4° Eliminar Group
rq [in]
request
str [in] key
class sad/v iews.py
#resource (Permission)
+ resource_add(request) : Permission in render_to_response("sad/resource/add.html", c), to_action("index")
+ resource_delete(request, key) : to_action("index")
+ resource_edit(request, key) : Permission in render_to_response("sad/resource/edit.html", c), to_action("index")
+ resource_index(request) : objects< Permission> in render_to_response("sad/resource/index.html", c)
#group
+ group_add(request) : Group in render_to_response("sad/group/add.html", c), to_action("index")
+ group_delete(request, key) : to_action("index")
+ group_edit(request, key) : Group in render_to_response("sad/group/edit.html", c), to_action("index")
+ group_index(request) : objects< Group> in render_to_response("sad/group/index.html", c)
+ group_permissions_edit(request) : objects< Group>, objects< Permission> in render_to_response("sad/group/permissions_edit.html", c)
#module
+ module_add(request) : Module in render_to_response("sad/module/add.html", c), to_action("index")
+ module_delete(request, key) : to_action("index")
+ module_edit(request, key) : Module in render_to_response("sad/module/edit.html", c), to_action("index")
+ module_index(request) : objects< Module> in render_to_response("sad/module/index.html", c)
+ module_plans_edit(request) : objects< Module>, objects< Solution> in render_to_response("sad/module/plans_edit.html", c)
+ module_state(request, state, key) : to_action("index")
#menu
+ menu_add(request) : Menu in render_to_response("sad/menu/add.html", c), to_action("index")
+ menu_delete(request, key) : to_action("index")
+ menu_edit(request, key) : Menu in render_to_response("sad/menu/edit.html", c), to_action("index")
+ menu_index(request, field, value, order) : page< Menu> in render_to_response("sad/menu/index.html", c)
+ menu_state(request, state, key) : to_action("index")
#user
+ user_add(request) : User in render_to_response("sad/user/add.html", c), to_action("index")
+ user_add_from_person(request, key) : User in render_to_response("sad/user/add_from_person.html", c), to_action("index")
+ user_delete(request, key) : to_action("index")
+ user_edit(request, key) : User in render_to_response("sad/user/edit.html", c), to_action("index")
+ user_index(request, field, value, order) : page< User> in render_to_response("sad/user/index.html", c)
+ user_person_search(request, field, value) : objects<Person> in render_to_response("sad/user/person_search.html", c)
+ user_state(request, state, key) : to_action("index")
+ user_upload(request) : json < dict>
+ user_view(request, key) : User in render_to_response("sad/user/view.html", c), to_action("index")
155
group_edit() Group in
render_to_response("sad/group/edit.html", c),
to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
incorrecta
2° Validar si Group existe en la BD, sino,
retornar exception informando que Group no
fué encontrado
-Si method="POST":
1° Si existe otro Group con el mismo "name",
retornar exception informando que el "name"
del Group ya existe
#Si hay algun exception mantener datos
enviados en el template edit.html
2° Salvar Group
rq [in]
request
str [in] key
group_index() objects< Group> in
render_to_response("sad/group/index.html", c)
Public
1° Obtener el listado de Group ordenado por
"-id" y mostrar en el template index.html
rq [in]
request
group_permissions_edit() objects< Group>,
objects< Permission> in
render_to_response("sad/group/permissions_edit.ht
ml", c)
Public
1° Obtener la lista de Permission ordenados
por
"content_type__app_label","content_type__mod
el"y mostrar en el template
group_permissions_edit.html
2° Obtener la lista de Group ordenado por "-
id" y mostrar en el template
group_permissions_edit.html
3° En una list[] Obtener los privilegios
asignados en la forma "Permission.id-
Group.id" y mostrar en el template
permissions_edit.html, donde los privilegios
asignados se marcan con check
-Si method="POST":
1° Eliminar los antiguos privilegios usando
Group.permissions.remove(Permission) para
cada par "Permission.id-Group.id" de todos
los request.POST.getlist("privilegios")
2° Salvar los nuevos privilegios marcados
con check en el template
permissions_edit.html. Usar
Group.permissions.add(Permission) para cada
par "Permission.id-Group.id" de todos los
request.POST.get("old_privilegios").split(",
")
#Si hay algun exception no hacer cambios en
la DB
rq [in]
request
#menu Metodo Notas Parámetros
menu_add() Menu in
render_to_response("sad/menu/add.html",
c), to_action("index")
Public
1° Inicializar Menu
2° Obtener el listado de Menu
padres activos y mostrarlos en
el template add.html
3° Obtener el listado de
Permission y mostrarlos en el
template add.html
4° Obtener el listado de
Menu.MODULES y mostrarlos en el
template add.html
-Si method="POST":
#Si hay algun exception mantener
datos enviados en el template
add.html
1° Salvar Menu
rq [in] request
156
menu_delete() to_action("index")
Public
1° Si no es válido la llave de
seguridad, retornar exception
informando que se ha denegado el
acceso debido a que la llave es
incorrecta
2° Validar si Menu existe en la
BD, sino, retornar exception
informando que Menu no fué
encontrado
3° Validar si Menu no es un menú
inicial
4° Eliminar Menu
rq [in] request
str [in] key
menu_edit() Menu in
render_to_response("sad/menu/edit.html",
c), to_action("index")
Public
1° Si no es válido la llave de
seguridad, retornar exception
informando que se ha denegado el
acceso debido a que la llave es
incorrecta
2° Validar si Menu existe en la
BD, sino, retornar exception
informando que Menu no fué
encontrado
3° Validar si Menu no es un menú
inicial
4° Obtener el listado de Menu
padres activos y mostrarlos en
el template edit.html
5° Obtener el listado de
Permission y mostrarlos en el
template edit.html
6° Obtener el listado de
Menu.MODULES y mostrarlos en el
template edit.html
-Si method="POST":
#Si hay algun exception mantener
datos enviados en el template
edit.html
1° Salvar Menu
rq [in] request
str [in] key
menu_index() page< Menu> in
render_to_response("sad/menu/index.html",
c)
Public
1° Obtener el listado paginado
de Menu filtrado y ordenado
según los parámetros enviados y
mostrar en el template
index.html
rq [in] request
str [in] field
str [in] value
str [in] order
menu_state() to_action("index")
Public
1° Si no es válido la llave de
seguridad, retornar exception
informando que se ha denegado el
acceso debido a que la llave es
incorrecta
2° Validar si Menu existe en la
BD, sino, retornar exception
informando que Menu no fué
encontrado
3° Actualizar el campo
Menu.is_active para False/True
rq [in] request
str [in] state
str [in] key
157
#module Metodo Notas Parámetr
os
module_add() Module in
render_to_response("sad/module/add.html",
c), to_action("index")
Public
1° Inicializar Module
2° Obtener el listado de Group ordenado por
"name" y mostrarlos en el template add.html
-Si method="POST":
1° Si existe otro Module con el mismo "name",
retornar exception informando que el "name" del
Module ya existe
#Si hay algun exception mantener datos enviados
en el template add.html
2° Salvar Module
3° Salvar los privilegios seleccionados en el
template add.html. Module.groups.add(Group) de
todos los request.POST.getlist("groups")
4° Salvar los privilegios iniciales seleccionados
en el template add.html.
Module.initial_groups.add(Group) de todos los
request.POST.getlist("initial_groups")
rq [in]
request
module_delete() to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha denegado
el acceso debido a que la llave es incorrecta
2° Validar si Module existe en la BD, sino,
retornar exception informando que Module no fué
encontrado
3° Validar si Module no tiene dependencias con
otras tablas, sino, retornar exception informando
que Module está asignado en la tabla donde fué
encontrada
4° Eliminar Module
rq [in]
request
str [in]
key
module_edit() Module in
render_to_response("sad/module/edit.html"
, c), to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha denegado
el acceso debido a que la llave es incorrecta
2° Validar si Module existe en la BD, sino,
retornar exception informando que Module no fué
encontrado
4° Obtener el listado de Group y mostrarlos en el
template edit.html
5° Obtener el listado de ids de los Group
asginados al Module y mostrarlos en el template
edit.html
6°Obtener el listado de ids de los Group
Iniciales asginados al Module y mostrarlos en el
template edit.html
7° Obtener el listado de Module.MODULES y
mostrarlos en el template edit.html
-Si method="POST":
1° Si existe otro Module con el mismo "name",
retornar exception informando que el "name" del
Module ya existe
#Si hay algun exception mantener datos enviados
en el template edit.html
2° Salvar Module
3° Eliminar los antiguos privilegios usando
Module.groups.remove(Group) de todos los
request.POST.get("old_grupos_id_list").split(",")
4° Salvar los nuevos privilegios seleccionados en
el template edit.html. Module.groups.add(Group)
de todos los request.POST.getlist("groups")
5° Eliminar los antiguos privilegios iniciales
usando Module.initial_groups.remove(Group) de
todos los
request.POST.get("old_initial_groups_id_list").sp
lit(",")
6° Salvar los nuevos privilegios iniciales
seleccionados en el template edit.html.
Module.initial_groups.add(Group) de todos los
request.POST.getlist("initial_groups")
#Si hay algun exception no hacer cambios en la DB
rq [in]
request
str [in]
key
158
module_index() objects< Module> in
render_to_response("sad/module/index.htm
l", c)
Public
1° Obtener el listado de Module ordenado por
"module", "-id" y mostrar en el template
index.html
rq [in]
request
module_plans_edit() objects< Module>,
objects< Solution> in
render_to_response("sad/module/plans_edit
.html", c)
Public
1° Obtener la lista de Module activos ordenados
por "module" y mostrar en el template
plans_edit.html
2° Obtener la lista de Solution activos ordenado
por "-id" y mostrar en el template
plans_edit.html
3° En una list[] Obtener los privilegios
asignados en la forma "Solution.id-Module.id" y
mostrar en el template plans_edit.html donde los
privilegios asignados se marcan con check
-Si method="POST":
1° Eliminar los antiguos privilegios usando
Module.solutions.remove(Solution) para cada par
"Solution.id-Module.id" de todos los
request.POST.getlist("privilegios")
2° Salvar los nuevos privilegios marcados con
check en el template plans_edit.html.
Module.solutions.add(Solution) para cada par
"Solution.id-Module.id" de todos los
request.POST.get("old_privilegios").split(",")
#Si hay algun exception no hacer cambios en la DB
rq [in]
request
module_state() to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha denegado
el acceso debido a que la llave es incorrecta
2° Validar si Module existe en la BD, sino,
retornar exception informando que Module no fué
encontrado
3° Actualizar el campo Module.is_active para
False/True
rq [in]
request
str [in]
state
str [in]
key
#resource (Permission)
Metodo Notas Parámetro
s
resource_add() Permission in
render_to_response("sad/resource/add.html",
c), to_action("index")
Public
1° Inicializar Permission
-Si method="POST":
1° Resolver "name","model" y "app_label" a
partir de los objetos recibidos del template
add.html
2° Obtener o crear la ContentType con el
"name","model" y "app_label" recibidos del
template add.html
3° Resolver "codename" y "recurso"
4° Si existe otro Permission con el mismo
"codename" para la ContentType retornar
exception informando que el "recurso" ya
existe
5° Salvar Permission
#Si hay algun exception mantener datos
enviados en el template add.html sin hacer
cambios en la DB
rq [in]
request
resource_delete() to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
rq [in]
request
159
incorrecta
2° Validar si Permission existe en la BD,
sino, retornar exception informando que
Permission o Recurso no fué encontrado
3° No permitir eliminar recursos iniciales
4° Validar si Permission no tiene dependencias
con otras tablas, sino, retornar exception
informando que Permission (en forma de
recurso) está asignado en la tabla donde fué
encontrada
5° Eliminar Permission
str [in] key
resource_edit() Permission in
render_to_response("sad/resource/edit.html",
c), to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
incorrecta
2° Validar si Permission existe en la BD,
sino, retornar exception informando que
Permission o Recurso no fué encontrado
3° No permitir editar recursos iniciales
-Si method="POST":
1° Resolver "name","model" y "app_label" a
partir de los objetos recibidos del template
edit.html
2° Obtener o crear la ContentType con el
"name","model" y "app_label" recibidos del
template edit.html
3° Resolver "codename" y "recurso"
4° Si existe otro Permission con el mismo
"codename" para la ContentType retornar
exception informando que el "recurso" ya
existe
5° Salvar Permission
#Si hay algun exception mantener datos
enviados en el template edit.html sin hacer
cambios en la DB
rq [in]
request
str [in] key
resource_index() objects< Permission> in
render_to_response("sad/resource/index.html"
, c)
Public
1° Obtener el listado de Permission ordenado
por
"content_type__app_label","content_type__model
" y mostrar en el template index.html.
rq [in]
request
#user
Metodo Notas Parámetro
s
user_add() User in
render_to_response("sad/user/add.html", c),
to_action("index")
Public
1° Inicializar User
2° Obtener el Headquar actual, id =
DataAccessToken.get_headquar_id(request.sess
ion)
3° Obtener el listado de Module activos
asignados a su Enterprise y Asociation del
Headquar actual
4° Obtener el listado de Group
pertenecientes al Module (del 3° paso) y
darle la forma indicada en la IGU y
mostrarlos en el template add.html (de la
forma Module>Group/perfil)
5° Obtener Person.IDENTITY_TYPES y
mostrarlos en el template add.html
-Si method="POST":
1° Si existe otro User con el mismo
"username", retornar exception informando
que el "username" del User ya existe
2° Si existe otro User con el mismo "email",
retornar exception informando que el "email"
del User ya existe
3° Salvar User
4° Si existe otro Person con el mismo
"first_name", "last_name" , "identity_num" y
"identity_type", retornar exception
informando que el Person ya existe. Use
normalize
5° Si existe otro Person con el mismo
rq [in]
request
160
"identity_num" y "identity_type", retornar
exception informando que ya existe un Person
con "identity_num" y "identity_type"
6° Salvar Person
7. Salvar Profile con User del 3er paso y
con Person del 6to paso
8° Salvar los Group de la sede
(request.POST.getlist("groups_sede")) en
UserProfileHeadquar
9° Salvar los Group de la empresa
(request.POST.getlist("groups_enterprise"))
en UserProfileEnterprise
10° Salvar los Group de la asociación
(request.POST.getlist("groups_association"))
en UserProfileAssociation
11° Salvar los Group de la sede, empresa
yasociación, evitando Group repetidos usando
User.groups.add(Group)
#Si hay algun exception mantener datos
enviados en el template add.html sin hacer
cambios en la DB
user_add_from_person() User in
render_to_response("sad/user/add_from_person.ht
ml", c), to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
incorrecta
2° Validar si Person existe en la BD, sino,
retornar exception informando que Person no
fué encontrado
3° Obtener el Headquar actual, id =
DataAccessToken.get_headquar_id(request.sess
ion)
4° Obtener el listado de Module activos
asignados a su Enterprise y Asociation del
Headquar actual
5° Obtener el listado de Group
pertenecientes al Module (del 4° paso) y
darle la forma indicada en la IGU y
mostrarlos en el template
add_from_person.html (de la forma
Module>Group)
6° Obtener Person.IDENTITY_TYPES y
mostrarlos en el template
add_from_person.html
-Si method="POST":
1° Si existe otro User con el mismo
"username", retornar exception informando
que el "username" del User ya existe
2° Si existe otro User con el mismo "email",
retornar exception informando que el "email"
del User ya existe
3° Salvar User
4° Si existe otro Person con el mismo
"first_name", "last_name" , "identity_num" y
"identity_type", retornar exception
informando que el Person ya existe. Use
normalize
5° Si existe otro Person con el mismo
"identity_num" y "identity_type", retornar
exception informando que ya existe un Person
con "identity_num" y "identity_type"
6° Actualizar Person, ahora con los datos
recibidos del formulario
7. Salvar Profile con User del 3er paso y
con Person del 6to paso
8° Salvar los Group de la sede
(request.POST.getlist("groups_sede")) en
UserProfileHeadquar
9° Salvar los Group de la empresa
(request.POST.getlist("groups_enterprise"))
en UserProfileEnterprise
10° Salvar los Group de la asociación
(request.POST.getlist("groups_association"))
en UserProfileAssociation
11° Salvar los Group de la sede, empresa
yasociación, evitando Group repetidos usando
User.groups.add(Group)
#Si hay algun exception mantener datos
enviados en el template add_from_person.html
sin hacer cambios en la DB
rq [in]
request
str [in] key
161
user_delete() to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
incorrecta
2° Validar si User existe en la BD, sino,
retornar exception informando que User no
fué encontrado
3° Validar si User no es admin, si lo es
enviar un mensaje "Lo sentimos, pero este
usuario no se puede eliminar."
4° Validar si User no tiene dependencias con
otras tablas, sino, retornar exception
informando que User está asignado en la
tabla donde fué encontrada
5° Eliminar User
rq [in]
request
str [in] key
user_edit() User in
render_to_response("sad/user/edit.html", c),
to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
incorrecta
2° Validar si User existe en la BD, sino,
retornar exception informando que User no
fué encontrado
3° Intentar obtener Profile con User.id del
paso 2° si existe, sino dejar pasar sin
obtener datos del Profile del User
4° Obtener el Headquar actual, id =
DataAccessToken.get_headquar_id(request.sess
ion)
5° Obtener el listado de Group ya asignados
de User para la Headquar ( si tuviese) en
UserProfileHeadquar y mostrarlos en el
template edit.html
6° Obtener el listado de Group ya asignados
de User para la Headquar.enterprise ( si
tuviese) en UserProfileEnterprise y
mostrarlos en el template edit.html
7° Obtener el listado de Group ya asignados
de User para la Headquar.association ( si
tuviese) en UserProfileAssociation y
mostrarlos en el template edit.html
8° Obtener el listado de Module activos
asignados a su Enterprise y Asociation del
Headquar actual
9° Obtener el listado de Group
pertenecientes al Module (del 8° paso) y
darle la forma indicada en la IGU y
mostrarlos en el template edit.html (de la
forma Module>Group)
10° Obtener Person.IDENTITY_TYPES y
mostrarlos en el template edit.html
-Si method="POST":
1° Si existe otro User con el mismo
"username", retornar exception informando
que el "username" del User ya existe
2° Si existe otro User con el mismo "email",
retornar exception informando que el "email"
del User ya existe
3° Salvar User
4° Obtener Person a través de User.profile,
sino Salvar un Person nuevo
5. Obtener Profile a través de User, sino
Salvar un Profile nuevo con el User del paso
3° y Person del paso 4°
6° Si existe otro Person con el mismo
"first_name", "last_name" , "identity_num" y
"identity_type", retornar exception
informando que el Person ya existe. Use
normalize
7° Si existe otro Person con el mismo
"identity_num" y "identity_type", retornar
exception informando que ya existe un Person
con "identity_num" y "identity_type"
8° Salvar nuevamente Person del paso 4°
ahora con los datos recibidos del formulario
9° Eliminar los Group de la sede asignados
al User de UserProfileHeadquar
10° Eliminar los Group de la empresa
asignados al User de UserProfileEnterprise
11° Eliminar los Group de la asociación
asignados al User de UserProfileAssociation
rq [in]
request
str [in] key
162
12° Eliminar los Group de la sede, empresa y
asociación asignados al User usando
User.groups.remove(Group)
13° Salvar los Group de la sede
(request.POST.getlist("groups_sede")) en
UserProfileHeadquar
14° Salvar los Group de la empresa
(request.POST.getlist("groups_enterprise"))
en UserProfileEnterprise
15° Salvar los Group de la asociación
(request.POST.getlist("groups_association"))
en UserProfileAssociation
16° Salvar los Group de la sede, empresa
yasociación, evitando Group repetidos usando
User.groups.add(Group)
#Si hay algun exception mantener datos
enviados en el template edit.html sin hacer
cambios en la DB
user_index() page< User> in
render_to_response("sad/user/index.html", c)
Public
1° Obtener el listado paginado de User
filtrado y ordenado según los parámetros
enviados y mostrar en el template index.html
rq [in]
request
str [in]
field
str [in]
value
str [in]
order
user_person_search() objects<Person> in
render_to_response("sad/user/person_search.html"
, c)
Public
1° Obtener el listado de Person que no están
en Profile, filtrar según los parámetros
enviados de la búsqueda, ordenar por
"last_name", "first_name" y mostrar en el
template person_search.html
rq [in]
request
str [in]
field
str [in]
value
user_state() to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
incorrecta
2° Validar si User existe en la BD, sino,
retornar exception informando que User no
fué encontrado
3° Validar si User no es admin, si lo es
enviar un mensaje "Lo sentimos, pero este
usuario no se puede inactivar."
4° Actualizar el campo User.is_active para
False/True
rq [in]
request
str [in]
state
str [in] key
163
user_upload() json < dict>
Public
1° Ejecute este método con ajax
2° Suba el archivo usando Upload.save_file(
, )
3° Devuelva información de la imagen subida
rq [in]
request
user_view() User in
render_to_response("sad/user/view.html", c),
to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
incorrecta
2° Validar si User existe en la BD, sino,
retornar exception informando que User no
fué encontrado
3° Intentar obtener Profile con User.id del
paso 2° si existe, sino dejar pasar sin
obtener datos del Profile del User
4° Obtener el listado de Group ya asignados
de User para las Headquar ( si tuviese) en
UserProfileHeadquar y mostrarlos en el
template view.html
5° Obtener el listado de Group ya asignados
de User para las Enterprise ( si tuviese)
en UserProfileEnterprise y mostrarlos en el
template view.html
6° Obtener el listado de Group ya asignados
de User para las Association ( si tuviese)
en UserProfileAssociation y mostrarlos en el
template view.html
7° Obtener Person.IDENTITY_TYPES y
mostrarlos en el template view.html
rq [in]
request
str [in] key
--- --- ---space
--- --- --- ---Diagrama de clases de diseño
164
#association
Metodo Notas Parámetr
os
association_edit_current() Association in
render_to_response("space/association/edit_curre
nt.html", c)
Public
1° Validar si Association actual existe en la
BD meidante
DataAccessToken.get_association_id(request.se
ssion), sino, retornar exception informando
que Association no fué encontrado
2° Obtener todos los Solution activos
ordenados por "id"
-Si method="POST":
1° Si existe otro Association con el mismo
name, retornar exception informando que el
name del Association ya existe
#Si hay algun exception mantener datos
enviados en el template edit_current.html
2° Salvar Association
rq [in]
request
association_upload() json < dict>
Public
1° Ejecute este método con ajax
2° Suba el archivo usando Upload.save_file( ,
)
3° Devuelva información de la imagen subida
rq [in]
request
#enterprise
class space/v iews.py
#solution
+ solution_add(request) : Solution in render_to_response("space/solution/add.html", c), to_action("index")
+ solution_delete(request, key) : to_action("index")
+ solution_edit(request, key) : Solution in render_to_response("space/solution/edit.html", c), to_action("index")
+ solution_index(request) : objects< Solution> in render_to_response("space/solution/index.html", c)
+ solution_state(request, state, key) : to_action("index")
#association
+ association_edit_current(request) : Association in render_to_response("space/association/edit_current.html", c)
+ association_upload(request) : json < dict>
#enterprise
+ enterprise_add(request) : Enterprise in render_to_response("space/enterprise/add.html", c), to_action("index")
+ enterprise_delete(request, key) : to_action("index")
+ enterprise_edit(request, key) : Enterprise in render_to_response("space/enterprise/edit.html", c), to_action("index")
+ enterprise_edit_current(request) : Enterprise in render_to_response("space/enterprise/edit_current.html", c)
+ enterprise_index(request) : objects< Enterprise> in render_to_response("space/enterprise/index.html", c)
+ enterprise_state(request, state, key) : to_action("index")
+ enterprise_upload(request) : json < dict>
#headquar
+ headquar_add(request) : Headquar in render_to_response("space/headquar/add.html", c), to_action("index")
+ headquar_change_association(request, key) : Headquar in render_to_response("space/headquar/change_association.html", c), to_action("index")
+ headquar_delete(request, key) : to_action("index")
+ headquar_edit(request, key) : Headquar in render_to_response("space/headquar/edit.html", c), to_action("index")
+ headquar_index(request) : objects< Headquar> in render_to_response("space/headquar/index.html", c)
+ headquar_state(request, state, key) : to_action("index")
Nombre:
Paquete:
Versión:
Autor:
space/views.py
space/views.py
1.0
Asullom
165
Metodo Notas Parámetr
os
enterprise_add() Enterprise in
render_to_response("space/enterprise/add.html",
c), to_action("index")
Public
1° Inicializar Enterprise
-Si method="POST":
1° Si existe otro Enterprise con el mismo
"name", retornar exception informando que el
"name" del Enterprise ya existe
2° Si existe otro Enterprise con el mismo
"tax_id", retornar exception informando que
el "tax_id" del Enterprise ya existe
3° Salvar Enterprise
4° Crear una Headquar con el
name="Principal", con la Association actual y
con el Enterprise actual
5° Si existe otro Headquar con el mismo name
para la Enterprise, retornar exception
informando que el name del Headquart para la
Enterprise ya existe
6° Salvar Headquar
#Si hay algun exception mantener datos
enviados en el template add.html sin hacer
cambios en la DB
rq [in]
request
enterprise_delete() to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
incorrecta
2° Validar si Enterprise existe en la BD,
sino, retornar exception informando que
Enterprise no fué encontrado
3° Validar si Association actual, a la que
pertenece la Sede de la Enterprise a
eliminar, no se quede si ninguna sede
asociada, sino, retornar exception informando
que Association no puede quedar sin ninguna
sede asociada
4° Validar si Enterprise no tiene
dependencias con otras tablas, sino, retornar
exception informando que Enterprise está
asignado en la tabla donde fué encontrada
5° Eliminar Enterprise
rq [in]
request
str [in]
key
enterprise_edit() Enterprise in
render_to_response("space/enterprise/edit.html",
c), to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
incorrecta
2° Validar si Enterprise existe en la BD,
sino, retornar exception informando que
Enterprise no fué encontrado
-Si method="POST":
1° Si existe otro Enterprise con el mismo
name, retornar exception informando que el
name del Enterprise ya existe
2° Si existe otro Enterprise con el mismo
tax_id, retornar exception informando que el
tax_id del Enterprise ya existe
3° Salvar Enterprise
#Si hay algun exception mantener datos
enviados en el template edit.html
rq [in]
request
str [in]
key
enterprise_edit_current() Enterprise in
render_to_response("space/enterprise/edit_curren
t.html", c)
Public
1° Validar si Enterprise actual existe en la
BD meidante DataAccessToken.get_enterprise
_id(request.session), sino, retornar
exception informando que Enterprise no fué
encontrado
2° Obtener todos los Solution activos
ordenados por "id"
-Si method="POST":
1° Si existe otro Enterprise con el mismo
name, retornar exception informando que el
name del Enterprise ya existe
rq [in]
request
166
2° Si existe otro Enterprise con el mismo
tax_id, retornar exception informando que el
tax_id del Enterprise ya existe
#Si hay algun exception mantener datos
enviados en el template edit_current.html
3° Salvar Enterprise
enterprise_index() objects< Enterprise> in
render_to_response("space/enterprise/index.html"
, c)
Public
1° Validar si Association actual existe en la
BD meidante
DataAccessToken.get_association_id(request.se
ssion), sino, retornar exception informando
que Association no fué encontrado
2° Obtener el listado de Enterprise cuya Sede
está asociada con la Association actual,
ordenado por -id y mostrar en el template
index.html.
en dicho listado debe incluirse el número de
sedes asociadas a la Association actual
rq [in]
request
enterprise_state() to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
incorrecta
2° Validar si Enterprise existe en la BD,
sino, retornar exception informando que
Enterprise no fué encontrado
3° Actualizar el campo Enterprise.is_active
para False/True
rq [in]
request
str [in]
state
str [in]
key
enterprise_upload() json < dict>
Public
1° Ejecute este método con ajax
2° Suba el archivo usando Upload.save_file( ,
)
3° Devuelva información de la imagen subida
rq [in]
request
#headquar
Metodo Notas Parámetr
os
headquar_add() Headquar in
render_to_response("space/headquar/add.html", c),
to_action("index")
Public
1° Inicializar Headquar
2° Obtener el listado en json de los
nombres de todos los Locality ordenado por
"name" y mostrar en el template add.html.
-Si method="POST":
1° Obtener o crear la Locality con el
nombre recibido del template add.html
2° Si existe otro Headquar con el mismo
"name" para la Enterprise, retornar
exception informando que el name del
Headquar ya existe para esa Enterprise
3° Salvar Headquar
#Si hay algun exception mantener datos
enviados en el template add.html sin hacer
cambios en la DB
rq [in]
request
headquar_change_association() Headquar in
render_to_response("space/headquar/change_associat
ion.html", c), to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
incorrecta
2° Validar si Headquar existe en la BD,
sino, retornar exception informando que
Headquar no fué encontrado
3° Obtener el listado en json de los
nombres de todos los Association activos
ordenado por "name" y mostrar en el
template change_association.html
rq [in]
request
str [in]
key
167
-Si method="POST":
1° Obtener la Association con el nombre
recibido del template
change_association.html, sino se encuentra,
retornar exception informando que
Association no fué encontrado, vuelva a
intentar
2° Salvar Headquar
#Si hay algun exception mantener datos
enviados en el template
change_association.html
headquar_delete() to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
incorrecta
2° Validar si Headquar existe en la BD,
sino, retornar exception informando que
Headquar no fué encontrado
3° Validar si Enterprise actual no se quede
si ninguna sede asociada, sino, retornar
exception informando que Enterprise no
puede quedar sin ninguna sede
4° Validar si Headquar no tiene
dependencias con otras tablas, sino,
retornar exception informando que Headquar
está asignado en la tabla donde fué
encontrada
5° Eliminar Headquar
rq [in]
request
str [in]
key
headquar_edit() Headquar in
render_to_response("space/headquar/edit.html", c),
to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
incorrecta
2° Validar si Headquar existe en la BD,
sino, retornar exception informando que
Headquar no fué encontrado
3° Obtener el listado en json de los
nombres de todos los Locality ordenado por
"name" y mostrar en el template edit.html
-Si method="POST":
1° Obtener o crear la Locality con el
nombre recibido del template edit.html
2° Si existe otro Headquar con el mismo
"name" para la Enterprise, retornar
exception informando que el name del
Headquar ya existe para esa Enterprise
3° Salvar Headquar
#Si hay algun exception mantener datos
enviados en el template edit.html
rq [in]
request
str [in]
key
headquar_index() objects< Headquar> in
render_to_response("space/headquar/index.html", c)
Public
1° Validar si Enterprise actual existe en
la BD meidante
DataAccessToken.get_enterprise_id(request.s
ession), sino, retornar exception
informando que Enterprise no fué encontrado
2° Obtener el listado de Headquar de la
Enterprise actual, ordenado por -id y
mostrar en el template index.html.
rq [in]
request
headquar_state() to_action("index")
Public
1° Si no es válido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave es
incorrecta
2° Validar si Headquar existe en la BD,
sino, retornar exception informando que
Headquar no fué encontrado
3° Actualizar el campo Headquar.is_active
para False/True
rq [in]
request
str [in]
state
str [in]
key
#solution
Metodo Notas Parámetros
solution_add() Solution in
render_to_response("space/solution/add.html", c),
to_action("index")
Public
1° Inicializar Solution
-Si method="POST":
1° Si existe otro Solution con el mismo
name, retornar exception informando que
el name del Solution ya existe
#Si hay algun exception mantener datos
enviados en el template add.html
2° Salvar Solution
rq [in]
request
168
solution_delete() to_action("index")
Public
1° Si no es válido la llave de
seguridad, retornar exception informando
que se ha denegado el acceso debido a
que la llave es incorrecta
2° Validar si Solution existe en la BD,
sino, retornar exception informando que
Solution no fué encontrado
3° Validar si Solution no tiene
dependencias con otras tablas, sino,
retornar exception informando que
Solution está asignado en la tabla donde
fué encontrada
4° Eliminar Solution
rq [in]
request
str [in] key
solution_edit() Solution in
render_to_response("space/solution/edit.html", c),
to_action("index")
Public
1° Si no es válido la llave de
seguridad, retornar exception informando
que se ha denegado el acceso debido a
que la llave es incorrecta
2° Validar si Solution existe en la BD,
sino, retornar exception informando que
Solution no fué encontrado
-Si method="POST":
1° Si existe otro Solution con el mismo
name, retornar exception informando que
el name del Solution ya existe
#Si hay algun exception mantener datos
enviados en el template edit.html
2° Salvar Solution
rq [in]
request
str [in] key
solution_index() objects< Solution> in
render_to_response("space/solution/index.html", c)
Public
1° Obtener el listado de Solution
ordenado por "-id" y mostrar en el
template index.html
rq [in]
request
solution_state() to_action("index")
Public
1° Si no es válido la llave de
seguridad, retornar exception informando
que se ha denegado el acceso debido a
que la llave es incorrecta
2° Validar si Solution existe en la BD,
sino, retornar exception informando que
Solution no fué encontrado
3° Actualizar el campo
Solution.is_active para False/True
rq [in]
request
str [in] state
str [in] key
169
Anexo B9 – Formulario de lecciones aprendidas
Proyecto:
N° Iteración:
Qué salió bien en la Iteración 1. 2.
Qué no salió bien en la Iteración 1. 2.
Qué mejoras vamos a implementar en la siguiente Iteración 1. Investigar todas las formas o estilos de codificación para definir el estilo de codificación de cada componentes y funciones de la aplicación 2.
170
Anexo B10 – Lista de tareas de desarrollo del backend
# Ticket Estado Estima
(h*)
Entrega
1 Inicio del proyecto Backend 01/08/2013
2 Refinación del diseño del sistema para el módulo
backend en Enterprise Architect
Hecho 48 06-ago
3 Refinación del diseño del frontend basado HTML5,
Bootstrap, JQuery, AJAX, etc
Hecho 48 11-ago
4 Componente para la Gestión de mensajería y Logs Hecho 24 14-ago
5 Componente para el Contexto de la Sesión del
Usuario en la nube
Hecho 18 16-ago
6 Componente para la seguridad de los recursos del
sistema
Hecho 24 19-ago
7 Componente para las llaves de seguridad de acceso
a datos
Hecho 8 21-ago
8 Otros componentes: Upload file, Redirect, etc. Hecho 6 22-ago
9 Gestión personalizada de Recursos (django) del
sistema
Hecho 18 25-ago
10 Gestión personalizada de PERFILES (django) de
usuarios
Hecho 6 26-ago
11 Configuración personalizada de PERMISOS (django)
o privilegios de usuarios
Hecho 12 28-ago
12 Gestión de MODULOS del sistema Hecho 12 30-ago
13 Configuración de PLANES del sistema Hecho 8 02-sep
14 CREAR CUENTA para NUEVOS USUARIOS, Empresas
y asignación de planes
Hecho 18 08-sep
15 Login y elección de la sede y módulo a administrar Hecho 12 12-sep
16 Perfil de usuario y Recuperación de contraseña Hecho 12 16-sep
17 Agregar nuevas EMPRESAS para usuarios existentes
y asignación de planes
Hecho 12 20-sep
18 Actualización de datos de la asociación Hecho 12 24-sep
19 Gestión de empresas de la asociación Hecho 12 28-sep
20 Actualización de datos de la empresa Hecho 12 02-oct
171
21 Gestión de sedes Hecho 18 07-oct
22 Gestión de usuarios Hecho 18 13-oct
23 Menú dinámico Hecho 12 17-oct
24 Depuración Hecho 18 23-oct
25 Publicación y distribución en Github Hecho 3 26-oct
26 Entrenamiento de integración Hecho 12 30-oct
27 Actualización de la documentación y prototipos Hecho 48 15-nov
28 Entrega al 100% del Backend 15/11/2013
Sumas: 451
172
Anexo C1 – Product backlog (requisitos del sistema)
Proyecto: QUALPACA -- Desarrollo de Plataforma Tecnológica en la Web para la
Competitividad de la Cadena Productiva de Alpacas en la Región Puno
Fecha de actualización: __04__/__11__/__2013__
Código/Sprint
Requisito Estado Estimac. (horas)
Prioridad
RF01 /1
Requisito 1: Identificación y registro de alpacas Descripción: Registro de alpacas según su procedencia, código de identificación, sexo, color, tipo o raza, datos de nacimiento, padres, localidad donde vive, asociación, rebaño y grupo a la que pertenece. Pruebas de aceptación y de seguridad: 1. Al añadir o seleccionar o buscar una alpaca el sistema
debe redirigir a la página que muestra el resumen de la información de la alpaca para su posterior actualización. El resumen dependerá de la información suministrada; esta información son: edad, datos reproductivos, producción de fibra, estado de salud y árbol genealógico.
2. La información de su grupo, padre y madre son opcionales. Si son ingresados los datos de los padres, el sistema debe generar su árbol genealógico hasta sus bisabuelos.
3. Debe mostrar en HTML los registros de alpacas reproductoras y no reproductoras dado un rango de fecha y un grupo.
4. El usuario debe tener acceso de “Administrador” o “Técnico de campo” al rebaño o al grupo para poder actualizar el Registro de alpacas. El usuario no puede visualizar ni actualizar registros del grupo o rebaño que no le está autorizado.
5. Poder rastrear al usuario que actualizó el Registro de alpacas.
Nuevo 40 10
RF02 /1
Requisito 2: Empadre y gestación Descripción: Pruebas de aceptación y de seguridad: 1. 2.
Nuevo 40 8
RF03 /1
Requisito 3: Parición y destete Descripción: Pruebas de aceptación y de seguridad: 1. 2.
Nuevo 20 6
RF04 /2
Requisito 4: Sanidad Descripción:
Nuevo 4
173
Pruebas de aceptación y de seguridad: 1. 2.
Requisito 5: Esquila Descripción: Pruebas de aceptación y de seguridad: 1. 2.
Nuevo 20 3
Requisito 6: Retiro Descripción: Pruebas de aceptación y de seguridad: 1. Alpaca X ya no está en el registro de alpacas
reproductoras 2.
Nuevo 10 2
Requisito 7: Castración Descripción: Pruebas de aceptación y de seguridad: 1. 2.
Nuevo 10 1
174
Anexo C2 - Registro de riesgos de seguridad (amenazas y vulnerabilidades)
Proyecto: QUALPACA -- Desarrollo de Plataforma Tecnológica en la Web para la
Competitividad de la Cadena Productiva de Alpacas en la Región Puno
Fecha de actualización: __04__/__11__/__2013__
COD Riesgo de seguridad Tipo (A/V)
Probabilidad
Impacto
Prioridad
RS-Q01
El sistema permite visualizar y actualizar información de alpacas de otros rebaños. Un usuario debe tener acceso únicamente a los registros de los Grupos previamente asignados.
V Alto Alto 1000
A: Amenza V: Vulnerabilidad
Probabilidad: Alta, Media, Baja
Impacto: Alta, Media, Baja
175
Anexo C3 - Registro de componentes de seguridad
Proyecto: QUALPACA -- Desarrollo de Plataforma Tecnológica en la Web para la
Competitividad de la Cadena Productiva de Alpacas en la Región Puno
Fecha de actualización: __04__/__11__/__2013__
COD Componente de seguridad Riesgos de seguridad
CS-B01
UserToken. Contiene información de accesos a los Gupos de un determinado rebaño, bajo ciertos perfiles de usuario. Con lo cual permite el control del acceso a datos de alpacas de cierto Grupo.
RS-Q01.
class UserToken: @staticmethod def set_grupo_id_list(request , grupo_id_list): request.session['grupo_id_list'] = grupo_id_list @staticmethod def get_grupo_id_list(session): return session.get('grupo_id_list', False)
Ejemplo de uso: Asignación del privilegio:: grupo_id_list = list({d.id: d for d in Headquart.grupo_set.all()}) UserToken.set_grupo_id_list(request, grupo_id_list)
Validación:: if camelido.id in UserToken.get_grupo_id_list(request.session): #OK else: raise Exception( "Falta de privilegios ")
176
Anexo C4 – Arquitectura de la aplicación
1. Información general
Código y Nombre del proyecto: QUALPACA
2. Historial de revisiones
Versión - Fecha - Elaborado por
1.0 04/04/2013 – Angel Sullón
3. Arquitectura de la aplicación MTV (equivalente a MVC)
Capa Tecnología Función Modelo: M Django Model Entidades y mapeamientos Django Test/Unit Test Pruebas unitarias del modelo
Vista: V Django View Django Business
Controlador de solicitudes y respuestas Reglas de negocio y restricciones
SAD Backend Solicitudes y respuestas con AJAX Restricciones de seguridad Logs Mensajería y Notificaciones
Django Test Pruebas de integración de las vistas y de los formularios
Template: T Django Template Interfaces gráficas de usuario para las entradas de datos y mostrar resultados
Bootstrap Diseño responsivo multidispositivo
JQUERY Utilitarios diversos
AJAX+ JSON Solicitudes y respuestas asíncronas
SAD Frontend Solicitudes y respuestas con AJAX Generación de objetos HTML en tiempo de ejecución Hojas de estilos personalizados
Selenium Pruebas funcionales en la Web
177
Anexo C5 – Estándares de desarrollo
1. Información general
Código y Nombre del proyecto: QUALPACA
2. Historial de revisiones
Versión - Fecha - Elaborado por
1.0 04/04/2013 – Angel Sullón
3. Términos de definición de identificadores
ID Término Ejemplo
Proyecto <nombre_proyecto> agil_cont
Paquetes <nombre_carpeta> catalogo_productos
Base de datos <nombre_db> agil_cont_db
Tablas <prefix_nombre_tabla> common_natural_person
Atributo PK id id
Atributo <nombre_atributo> functional_code
Atributo FK <tabla>_id natural_person_id
Paquetes <nombre_carpeta> catalogo_productos
Clases <NombreClase><NombreCapa/vacio> class NaturalPerson
Variables <nombre_variable> functional_code
Contantes <NOMBRE_CONSTANTE> DEFAULT="DNI"
Método <nombre_metodo>(var_nombre) def add(); def edit(); def delete(); def get_by_id(id); def get_list_by_filter(filter);
Enumerators <NOMBRE_ENUM> DEFAULT="DNI" CE="CE" OTHERS="OTHERS" IDENTITY_TYPES = ( (DEFAULT, "D.N.I."), (CE, "C.E."), (OTHERS, "Otro.") )
Archivos <nombre_pagina>.<py/html> natural_person.html
Interfaces I<NombreClase><NombreCapa/vacio> INaturalPersonService
178
Anexo C6 – Método de trabajo del equipo
1. Información general
Código y Nombre del proyecto: QUALPACA
Desarrollo de Plataforma Tecnológica en la Web para la Competitividad de la Cadena Productiva de Alpacas en la Región Puno
2. Historial de revisiones
Versión - Fecha - Elaborado por
1.0 04/04/2013 – Angel Sullón
3. Equipo de trabajo
Rol Nombre Ciudad Correo/Celular Tiempo
Product Owner
Dra. Nelida Gladys Maquera Sosa
Juliaca [email protected] 50%
Scrum Master
Ing. Fredy Abel Huanca Torres
Puno [email protected] 30%
Dupla 1-Doc./Dev.
Ing. Fredy Abel Huanca Torres
Puno [email protected] 20%
Ing. Ángel Sullón Macalupú
Chullunquiani [email protected] 50%
Dupla 2-Dev.
Est. Oscar David Mendoza Apaza
Juliaca
[email protected] 100%
Est. Elvis Alí Vilca Juliaca [email protected]
50%
4. Herramientas
Elemento Herramienta Hosting
Portal de gerenciamiento
Assembla.com https://www.assembla.com/spaces/concytec-qualpaca
Portal de integración Github.com https://github.com/abelthf/qualpaca-project
Modelo y Prototipado Enterprise Architect 7.5 Balsamiq
http://grupoinnop.pe/design
Lenguaje de programación
Python
Frameworks Django 1.6.8
Framework responsivo Bootstrap 2
Base de datos MySQL 5.x
IDE Sublime Text 2
Comunicaciones Facebook https://www.facebook.com/groups/513850221984640
179
5. Retos a superar
Desafío Solución
Respecto a la metodología scrum Definir la duración del sprint a 4 semanas Lea la wiki y utilice el foro de discusión del portal de gerenciamiento (Mensajes)
Respecto al equipo distribuido (parcial o totalmente, horarios, idiomas diferentes)
Definir las tareas en base a una unidad de trabajo diario o semanal (que incluya testes) Informar el estado de las tareas en el portal de gerenciamiento, incluye horas restantes. Enviar el reporte de trabajo diario o semanal (StandUp) Documentación en inglés Consigue una llamada con Hangout, Facebook o Skype
Respecto a las herramientas de trabajo
Entrenamiento en las herramientas a usar
Respecto a la experiencia de los desarrolladores
Cada código, diagrama, prototipos debe seguir el estándar de desarrollo elegido Entrenamiento en las tecnologías a usar
Respecto a la documentación El diseño/prototipo/restricciones deben estar listos y validados a un Sprint de anticipación
Falta de compromiso del cliente Involucrar al cliente en las reuniones y demos
180
Anexo C7 – Prototipos principales
Proyecto: QUALPACA
Módulo: Producción
Fecha:
Requisito 1: Identificación y registro de alpacas
ui index.html
181
Funcionalidad: Página que permite la administración de registros de alpacas.
Aprobado por: Dra. Gladys Maquera Sosa
ui add.html
182
Anexo C8 – Diseño del sistema
1 INFORMACIÓN GENERAL
Código y Nombre del proyecto: QUALPACA
Desarrollo de Plataforma Tecnológica en la Web para la Competitividad de la Cadena Productiva de Alpacas en la Región Puno
2 HISTORIAL DE REVISIONES
Versión - Fecha
1.0 – __04__/__11__/__2013__
3 ACTUALIZACIONES IMPORTANTES
Diseño integrado con los componentes de Backengo versión 1.0
4 LINKS DE DESCARGA O DE CONSULTA
Modelo [http://grupoinnop.pe/design] (Este hosting requiere contraseña)
Scripts: No es necesario, Django genera automáticamente las tablas.
5 ESTRUCTURA DEL MODELO
Módulo
---Modelo del dominio
--- ---app registro
pkg Qualpaca Modules
El alcance de Qualpaca versión 1.0 consta de 3 módulos:
backend: para configurar el sistema y administrar las cuentas de los usuarios (acceso restringido para
superusers).
production: crianza mejorada de alpacas. Registro, empadre, parición, sanidad y esquila
web: la página web de Qualpaca (completamente independiente de los otros módulos, se integra vía json o
webservices)
183
--- --- ---Diagrama de entidades
---Modelo de clases
--- ---Capa(si es Models o Views(Views en MVC es Controllers))
--- --- ---registro app
--- --- --- ---Diagrama de clases de diseño – Business Layer
--- --- --- ---Diagrama de clases de diseño – View Layer
class registro
Camelido
- codigo_arete: Char
- consanguinidad_adn: Char
- diametro_fibra: Char
- fecha_destete: DateTime
- fecha_nac: DateTime
- imagen: Image
- nombre: Char
- observaciones: Text
- parecido: Char
- peso_bellon: Char
- peso_nac: Char
- procedencia_det: Text
- registered_at: DateTime
space::Headquar(sede)
- address: Text
- is_active: Boolean
- is_main: Boolean
- modified_in: DateTime
- name: Char
- phone: Char
- registered_at: DateTime
space::Grupo
- majada: Boolean
- nombre: Char
GrupoCamelido
- fecha_grupo: DateTime
- registered_at: DateTime
0..*
+sede
1
0..*
+grupo
0..1
0..*
+sede 1
0..*
+camelido
0..1
class registro.business
«business.py»
CamelidoBusiness
+ get_arbol_gen_by_id(id :int) : json<Camelido>
+ get_by_id(id :int) : Camelido
+ get_list_by_headquart_and_fechas_and_grupo(rebanho_id :int, fecha_ini :DateTime, fecha_fin :DateTime, grupo_id :int?) : objects<Camelido>
+ get_list_by_headquart_and_filter(rebanho_id :int, fi lter :string?) : objects<Camelido>
+ get_list_by_headquart_and_sexo_and_filter(rebanho :Headquart, sexo :string, fi lter :string) : objects<Camelido>
+ get_list_by_sexo_and_filter(sexo :string, fi lter :string) : objects<Camelido>
+ get_page_by_headquart_and_grupo(rebanho_id :int, grupo_id :int?, order :string?, num_rows :int?, page_index :int?) : objects<Camelido>
+ get_retiro_list_by_headquart_and_fechas_and_grupo(rebanho_id :int, fecha_ini :DateTime, fecha_fin :DateTime, grupo_id :int?) : objects<Camelido>
+ initialize() : Camelido()
+ remove(id :int) : Camelido
+ save(camelido :Camelido) : Camelido
class registro.v iews
camelido
+ camelido_add(request :HttpRequest) : render_to_response,camelido_edit|HttpResponseRedirect
+ camelido_edit(request :HttpRequest, id :Integer) : render_to_response,camelido_edit|HttpResponseRedirect
+ camelido_ficha(request :HttpRequest, id :Integer) : render_to_response
+ camelido_json_by_filter(request :HttpRequest, fi l ter :string) : render_to_response
+ camelido_report(request :HttpRequest, fecha_ini :DateTime, fecha_fin :DateTime, grupo_id :int?) : render_to_response
+ camelido_report_retiro(request :HttpRequest, fecha_ini :DateTime, fecha_fin :DateTime, grupo_id :int?) : render_to_response
+ camelido_retiro(request :HttpRequest, id :Integer) : camelido_remove|HttpResponseRedirect
+ hembra_json_by_filter(request :HttpRequest, fi l ter :string) : render_to_response
+ macho_json_by_filter(request :HttpRequest, fi l ter :string) : render_to_response
184
Diagrama de procesos de negocio para el módulo de producción
act Manejo Reproductiv o en Alpacas
Inicio
fin
Manejo reproductivo en alpacas
Obs.
Calendario ganadero (genérico y personalizado
por zonas)
Calendairo sanitario
Selección e Identificación
(registro)
Empadre y
Gestación(empadre)
Parición(paricion)
Castración (componente
opcional)
Esquila
Faeneo,Venta, Descarte,...
(retiro)
Sanidad
Actividades simultáneas
Quedó
preñada?
fin
Destete
[Más de 4 servicios]
[Hasta 4 servicios]
[no]
[si]
185
Operaciones de la clase business “CamelidoBusiness”
Metodo Notas Parámetros
get_arbol_gen_by_id() json<Camelido>
Public
int [in] id
get_by_id() Camelido
Public
int [in] id
get_list_by_headquart_and_fec
has_and_grupo() objects<Camelido> Public
order by -id Para el reporte de Registro de
alpacas(entradas).
if grupo_is is None: Traer todos los grupos
cuyo estado es seleccionado excepto Majada.
No traer alpacas con algún estado de retiro
(venta, muerte, etc.)
int [in] rebanho_id
DateTime [in] fecha_ini
DateTime [in] fecha_fin
int? [in] grupo_id
get_list_by_headquart_and_filte
r() objects<Camelido>
Public
order by codigo_arete Este método será para buscar alpaca en el
texbox principal, la view lo convertirá en
formato json
debe buscar según el filter en todos los
Grupos, incluso en Majada. No traer los que
tienen algun estado de retiro
Debe mostrar el último estado (parición,
seleccionado. descartado si es majada)
La validación de seguridad si el usuario
puede o no editar información de ese Grupo se
hará cuando el usuario invoque la acción
int [in] rebanho_id
string? [in] filter
get_list_by_headquart_and_sex
o_and_filter() objects<Camelido>
Public
order by codigo_arete Traer los que tienen como último
estado=seleccionado
este método se usará para buscar su madre o
padre
Headquart [in] rebanho
string [in] sexo
string [in] filter
get_list_by_sexo_and_filter() objects<Camelido>
Public
order by codigo_arete Traer los que tienen como último
estado=seleccionado
este método se usará para buscar su madre o
padre
Debe buscar en todos los rebaños (heardquar)
string [in] sexo
string [in] filter
get_page_by_headquart_and_gr
upo() objects<Camelido> Public
order by -id Si grupo_id es None, traer todos los grupos,
incluso Majada. No traer los que tienen algún
estado de retiro (venta, muerte, etc.)
Debe mostrar el último estado (parición,
seleccionado. descartado si es majada)
La validación de seguridad si el usuario
puede o no editar información de ese Grupo se
hará cuando el usuario invoque la acción
int [in] rebanho_id
int? [in] grupo_id
string? [in] order
int? [in] num_rows
int? [in] page_index
get_retiro_list_by_headquart_a
nd_fechas_and_grupo() objects<Camelido> Public
order by -id Para el reporte de Registro de
alpacas(entradas).
if grupo_is is None: Traer todos los grupos
cuyo estado es seleccionado excepto Majada.
No traer alpacas con algún estado de retiro
(venta, muerte, etc.)
int [in] rebanho_id
DateTime [in] fecha_ini
DateTime [in] fecha_fin
int? [in] grupo_id
initialize() Camelido()
Public
remove() Camelido Public
Retirar es cambiar su estado para algún
estado de retiro a una alpaca.
int [in] id
save() Camelido
Public
Camelido [in] camelido
186
Operaciones de la clase view “camelido”
Metodo Notas Parámetros
camelido_add() render_to_response,camelido_edit
|HttpResponseRedirect Public
HttpRequest [in] request
camelido_edit() render_to_response,camelido_edit|HttpResponseRedirect
Public
HttpRequest [in] request
Integer [in] id
camelido_ficha() render_to_response
Public
Llamar los métodos según correspondan
HttpRequest [in] request
Integer [in] id
camelido_json_by_filter() render_to_response
Public
HttpRequest [in] request
string [in] filter
camelido_report() render_to_response Public
llama a get_list_by_headquart_and_fechas_and_grupo
HttpRequest [in] request
DateTime [in] fecha_ini
DateTime [in] fecha_fin
int? [in] grupo_id
camelido_report_retiro() render_to_response Public
llama a get_list_by_headquart_and_fechas_and_grupo
HttpRequest [in] request
DateTime [in] fecha_ini
DateTime [in] fecha_fin
int? [in] grupo_id
camelido_retiro() camelido_remove|HttpResponseRedirect
Public
llama a remove
HttpRequest [in] request
Integer [in] id
hembra_json_by_filter() render_to_response
Public
HttpRequest [in] request
string [in] filter
macho_json_by_filter() render_to_response
Public
HttpRequest [in] request
string [in] filter
187
Anexo C9 – Formulario de lecciones aprendidas
Proyecto: QUALPACA
N° Iteración: 1
Qué salió bien en la Iteración 1. La distribución de tareas fue acertada en tiempo, gracias al modelado de procesos de negocio, al diseño detallado del sistema y al empeño del equipo de desarrollo. 2. El estilo de uso de los componentes de seguridad indicados en el backend permitieron escribir código limpio y en menos líneas de código.
Qué no salió bien en la Iteración 1. La resolución de conflictos durante la sincronización del código en el repositorio remoto github.com 2.
Qué mejoras vamos a implementar en la siguiente Iteración 1. 2.
188
Anexo C10 – Acta de constitución del proyecto
1 INFORMACIÓN GENERAL
Código y Nombre del proyecto: QUALPACA - Desarrollo de Plataforma Tecnológica en la Web para la Competitividad de la Cadena Productiva de Alpacas en la Región Puno
Organización: CONCYTEC-UPeU/Grupo InnOp Perú
Modalidad del servicio: Contrato
Fecha de inicio: 01-05-2013
Fecha de vencimiento: 30-09-2013 (Plazo de entrega: 4 meses)
Presupuesto estimado: S/. 12,000.00 NUEVOS SOLES
Presupuesto tope: S/. 12,000.00 NUEVOS SOLES
Dueño del producto: Gladys Maquera
Patrocinador del proyecto: CONCYTEC a través de Gladys Maquera
Gerente del proyecto (Master): Abel Huanca
2 HISTORIAL DE REVISIONES
Versión - Fecha - Elaborado por
1.0 - 21/06/2013 - Abel Huanca
3 OBJETIVOS DEL PROYECTO
Desarrollar e implementar una plataforma tecnológica basada en la Web moderna para la Competitividad de la Cadena Productiva de Alpacas en la Región Puno
4 JUSTIFICACIÓN DEL PROYECTO
Proporcionar un sistema de información que colabore con el fortalecimiento de las capacidades de mejoramiento genético de la crianza de Alpacas que es la base fundamental del Primer eslabón de la cadena productiva.
5 ALCANCE DEL PROYECTO
El proyecto consta de los siguientes actividades:
Evaluación y pruebas de las diferentes método y tecnologías para desarrollo web moderna y segura
Creación e implementación de la plataforma tecnológica basada en la Web moderna para la Competitividad de la Cadena Productiva de Alpacas en la Región Puno
Creación e implementación de la página web donde se divulgará la información referente a la mejora productiva de alpacas.
6 DESCRIPCIÓN GENERAL DEL SOFTWARE
El software es un aplicación web como servicio (SaaS) totalmente responsivo compatible con cualquier navegador web que registra y proporciona información para el mejoramiento genético de alpacas basado en el sistema de empadre controlado, así como la producción de fibra del rebaño.
Módulos:
1. Backend para la nube que gestione la información de muchas empresas y asociaciones productoras de fibra de alpaca, donde los usuarios acceden a la información según sus funciones predefinidas.
2. Módulo de producción: Selección e identificación, empadre y gestación, parición y destete, sanidad, esquila, castración y retiro de alpacas
189
3. Página Web donde se divulgará la información referente a la mejora productiva de alpacas.
7 BENEFICIARIOS FINALES DEL SOFTWARE
Instituciones públicas y privadas productoras de fibra de alpacas de la Región Puno
Productores independientes
8 REFERENCIAS
Product backlog o Requisitos del Sistema
9 FIRMA DE AUTORIZACIÓN DE LAS PARTES
Dra. Gladys Maquera Sosa Por el CONCYTEC
Ing. Abel Huanca Torres Gerente del Proyecto Qualpaca
190
Anexo C11 – Sprint backlog
Proyecto: QUALPACA -- Desarrollo de Plataforma Tecnológica en la Web para la
Competitividad de la Cadena Productiva de Alpacas en la Región Puno
Nombre del Sprint: 1
Fecha de actualización: __05__/__11__/__2013__
Objetivos: [Funcionalidad del negocio que se va a generar]
1. Permitir el levantamiento de información de identificación, clasificación, empadre,
gestación, parición, destete, sanidad, esquila, castración y retiro.
COD Sprint 1 Estado Trabajo restante
Responsable
T01 Tarea: Desarrollar el MODELO de datos para el módulo de PRODUCCIÓN y generar la administración automática Django. Descripción: Actualizar las apps: apps/params apps/rrhh apps/sad apps/space Crear las apps: apps/registro apps/empadre apps/paricion apps/registro apps/sanidad apps/esquila apps/castración apps/mod_produccion (sin tablas) Crear las carpetas templates templates/registro templates/empadre templates/paricion templates/registro templates/sanidad templates/esquila templates/castración templates/mod_produccion templates/partials/producción Pruebas de aceptación y de seguridad: 1. Poder ingresar datos de prueba para todas las tablas del módulo de PRODUCCIÓN mediante el administrador de Django. 2. Las tablas deben quedar integrados con las tablas de seguridad del Backend en caso que así lo ameriten.
Hecho 4 horas Ángel Sullon
191
T02 Tarea: Desarrollar la página index del módulo de producción para listar y buscar alpacas. Descripción: Replicar template base para el mod_produccion con menú sidebar: templates/base_mod_produccion.html templates/base_mod_produccion_sidebar.html templates/denied_mod_produccion.html Listado de alpacas en : templates/mod_produccion/camelido_list.html apps/mod_produccion/views.camelido_list Búsqueda asíncrona (AJAX) de alpacas en: templates/partials/produccion/header.html apps/mod_produccion/views.camelido_json_by_filter Redirigir a: templates/registro/registro/index.html (dejar vacío) apps/registro/views.registro_index Pruebas de aceptación y de seguridad: 1. Visualizar o buscar alpacas del rebaño y al encontrar mostrar detalles del registro en otra ventana. 2. Al actualizar con método GET en caso de errores, debe mantenerse en el módulo de PRODUCCION.
Hecho 4horas Oscar Mendoza
T03 Tarea: Refinar el listado y búsqueda de alpacas Descripción: Estos resultados deben mostrar alpacas con el último estado del camélido y según privilegios del usuario. Listado de alpacas en : apps/mod_produccion/views.camelido_list Búsqueda asíncrona (AJAX) de alpacas en: apps/mod_produccion/views.camelido_json_by_filter Pruebas de aceptación y de seguridad: 1. En el listado o búsqueda, mostrar alpacas con el último estado. 2. Permitir listar o buscar alpacas para los rebaños o grupos asignados al usuario. También usar llave de seguridad.
Hecho 8horas Elvis Ali
T04 Tarea: Agregar y editar datos del camélido. Descripción: Agregar alpaca en : templates/registro/add.html apps/registro/views.registro_add Resultados en formato JSON: apps/registro/views.macho_json_by_filter apps/registro/views.hembra_json_by_filter
Hecho 16horas Oscar Mendoza
192
apps/registro/views.camelido_upload Redirigir a: templates/registro/registro/edit.html (cargar datos) apps/registro/views.registro_edit y desarrollar el método editar. Pruebas de aceptación y de seguridad: 1. Registrar y actualizar datos de alpacas, verificar datos obligatorios. 2. Registrar usuario que registra los datos de la alpaca. 3. No se debe permitir actualizar los datos de la alpaca si el usuario no tiene permisos.
T05 …
193
Anexo C12 – Acta de conformidad del servicio o entrega
1 INFORMACIÓN GENERAL
Código y Nombre del proyecto: QUALPACA - Desarrollo de Plataforma Tecnológica en la Web para la Competitividad de la Cadena Productiva de Alpacas en la Región Puno
Organización: CONCYTEC-UPeU/Grupo InnOp Perú
Fecha de inicio: 01-05-2013
Fecha de vencimiento: (Plazo de entrega)
Presupuesto estimado: S/. 12,000.00 NUEVOS SOLES
Presupuesto tope: S/. 12,000.00 NUEVOS SOLES
Dueño del producto: Dra. Gladys Maquera
Patrocinador del proyecto: CONCYTEC a través de Gladys Maquera
Gerente del proyecto (Master): Ing. Abel Huanca
FECHA DE ENTREGA: 04-12-2013
2 RESULTADO
Conforme: Si
Días atraso: 6 a partir del inicio del desarrollo
3 OBSERVACIONES
No hubo observaciones relevantes.
4 FIRMA DE CONFORMIDAD DEL CLIENTE O PATROCINADOR
Dra. Gladys Maquera Sosa
194
Anexo C13 – Manual del usuario
Nombre de la Aplicación
BACKEND PARA APLICACIONES CON DJANGO Manual del Usuario
Última revisión
14-05-2014
Elaborado por
Angel Sullón Macalupú
Características Módulo Backend para aplicaciones web SaaS seguras escritas en Django y con la elegancia de Bootstrap. Permite gestionar diferentes partes del sistema: usuarios, perfiles, recursos, permisos, módulos, planes, menús, asociaciones, empresas, sedes, logs, seguridad, internacionalización y mucho más.
Descarga, Instalación y Ejecución
Descarga gratis de GitHub https://github.com/submitconsulting/backengo e instale las dependecias:
$ pip install -r requirements.txt Para ejecutar: $python manage.py runserver
Página de Inicio
195
Crear cuenta de usuario
Formulario de ingreso
196
Elección de la empresa/sede y módulo
Configuración de los planes SaaS
Creación de recursos
197
Creación de menús
Formulario registro de nuevas empresas
Gestión de empresas
198
Gestión de sedes
Gestión de usuarios
199
