PDF Universidad De Castilla-la Mancha - Uclm

The development of this system was entrusted to Tecnobit, Grupo Oesía, which started the development of EKMS-ESP or Electronic Key Management System Spain. As expected, evaluating such a system is a key process in project development and can be somewhat complex.

AGRADECIMIENTOS

INTRODUCCIÓN

INTRODUCCIÓN 25

Esto garantiza la autenticidad del remitente, pero también la integridad de los datos y el no repudio porque asegura que durante la transmisión de los datos nadie ha realizado ningún cambio en ellos, ya que el cifrado utilizado por el delincuente sería diferente al original. Es similar al método de autenticación, la diferencia es que antes de cifrar los datos, se les aplica una función hash y luego se cifran con la clave privada.

Cifrado con Clave Privada del Emisor

INTRODUCCIÓN 27

La gestión de claves de este nivel de confidencialidad requiere el uso de algoritmos de cifrado seguros y altamente eficientes, por lo que el hardware mencionado anteriormente se utiliza en el proceso de transferencia de claves. Distribución segura de claves electrónicas y no electrónicas desde el nodo maestro NDA a SubDas.

INTRODUCCIÓN 29

MOTIVACIÓN
CONTRIBUCIONES

El sistema desarrollado en este TFG se muestra en la Figura 1.6 y se denomina como. Para comprender el contexto en el que fue desarrollado, en la Figura 1.6 se agregan tanto el sistema EKMS-ESP, un sistema verificado por el sistema de prueba automático, como los componentes externos que interactúan con él.

INTRODUCCIÓN 31

ESTRUCTURA DEL DOCUMENTO

Desarrollo del TFG Este capítulo detalla los procedimientos llevados a cabo para desarrollar el TFG utilizando la metodología explicada en el Capítulo 4. Conclusiones Este capítulo contrasta los objetivos detallados en el Capítulo 2 con lo que finalmente se logró.

OBJETIVO

OBJETIVO PRINCIPAL

OBJETIVOS SECUNDARIOS

ANTECEDENTES

ANTECEDENTES 37

INTEGRACIÓN CONTINUA

ANTECEDENTES 39
ANTECEDENTES 41

AUTOMATIZACIÓN DE LA VERIFICACIÓN

ANTECEDENTES 43
ANTECEDENTES 45
ANTECEDENTES 47

TESTING DE APLICACIONES WEB

ANTECEDENTES 49

Dado que el propósito es introducir el sistema de pruebas en un modelo de integración continua, las pruebas desarrolladas son pruebas de integración. Su principal característica es que es una herramienta "Out of Box", es decir, no requiere instalaciones o configuraciones previas para comenzar a utilizarla. Si se trata de una aplicación web, las pruebas que se suelen realizar son pruebas de aceptación del usuario, pruebas de integración, pruebas de regresión y pruebas del sistema.

Protractor es un marco de prueba de un extremo a otro para aplicaciones desarrolladas en Angular y AngularJS en particular, pero también es compatible con cualquier aplicación que se ejecute en un navegador.

METODOLOGÍA

METODOLOGÍA DE DESARROLLO EN CASCADA

En el caso de este proyecto, los 'clientes' son los propios compañeros de equipo, los requisitos del sistema de pruebas se cubrieron mediante diversas reuniones de intercambio de ideas entre todos los miembros, donde se hicieron propuestas de posibles soluciones. Luego se debe realizar un análisis de los requerimientos cubiertos para determinar las características del software a desarrollar, se especifica todo lo que debe hacer el sistema, detallando sus aspectos técnicos. No se utilizó ningún software de captura específico para capturar los requisitos, sino que se creó una lista de ellos y se clasificó según las prioridades establecidas utilizando la notación MOSKVA (debe, debería, podría, no).

Cabe señalar que si bien este modelo no permite específicamente agregar requisitos en etapas distintas a la etapa de Captura de Requisitos, ya que es un sistema de prueba que determina sus requisitos con base en las necesidades de otro sistema (el sistema a probar se convierte en) el cual está en desarrollo. , a medida que sus requisitos evolucionen, surgirán nuevas necesidades que agregar al sistema de prueba, por lo que serán tratadas como modificaciones realizadas en la etapa de mantenimiento.

METODOLOGÍA 53

TECNOLOGÍA UTILIZADA

PC de desarrollo: ordenador de trabajo de la empresa donde se realizarán las tareas de desarrollo de software. JService Server: este servidor aloja el servicio Jenkins y estará conectado a la misma red local que el resto del equipo de desarrollo. AService Server: Este servidor físico alojará el servidor HT TP Apache donde se ejecuta la propia aplicación, entre otras cosas está conectado a la misma red local que el resto del equipo de desarrollo.

Dispositivo criptográfico de clave electrónica: Dispositivo hardware para la gestión de claves electrónicas. Es uno de los componentes que forma parte del sistema real y se encarga de cifrar y descifrar las claves al transportarlas entre dispositivos.

METODOLOGÍA 55

DESARROLLO DEL PROYECTO

PRIMERA ETAPA: CAPTURA Y ANÁLISIS DE REQUISITOS
DESARROLLO DEL PROYECTO 59

SEGUNDA ETAPA: DISEÑO

TERCERA ETAPA: IMPLEMENTACIÓN

Se debe determinar si hay una pérdida de memoria en el sistema (relacionada con el Subobjetivo O2). Se evalúan las acciones que se pueden realizar sobre los usuarios existentes en el sistema. Se marcan las acciones que se pueden realizar en los usuarios existentes en el sistema.

Un aspecto importante del sistema que necesitaba ser probado es cómo se comporta el sistema cuando se realizan múltiples actualizaciones al repositorio de Subversion simultáneamente.

INTEGRACIÓN DEL SISTEMA EN EL PROYECTO EKMS-ESP

ARQUITECTURA FINAL DEL SISTEMA
EJEMPLO EJECUCIÓN DE TEST
INTEGRACIÓN DEL SISTEMA EN EL PROYECTO EKMS-ESP 75

RESULTADOS DEL TFG

La cuenta principal de la NDA corresponderá a la cuenta que inicia sesión en el sistema e inicia la operación de distribución. Finalmente, verifique que la cuenta previamente seleccionada se encuentre en el árbol de Claves seleccionadas. Con estas pruebas se detectó una gran cantidad de errores en el sistema EKMS-ESP.

En el sistema se desarrolla un test para cada objeto (Computadores, contraseñas, cuentas, usuarios, roles, etc.) que verifica con precisión la obligación de operar estos campos.

CONCLUSIONES

PRINCIPALES CONTRIBUCIONES

Tanto la generación de los resultados de cada batería de pruebas como su almacenamiento en el repositorio de Jenkins se explican en los Apéndices A y B. Como se explica en el apéndice, el uso de complementos de Jenkins, en particular VectorCAST Coverage, permite determinar el grado de cobertura generado por la Casos de prueba. Después de numerosas ejecuciones de las baterías de prueba con este sistema durante la fase de pruebas, fue posible determinar la precisión de estas pruebas, como se explica en el apartado 5.3.4.

Se ha podido determinar la independencia total entre las pruebas mediante pruebas realizadas en la fase de pruebas, tal y como se explica en el apartado 5.3.4.

CONCLUSIONES 93

TRABAJO FUTURO
OPINIÓN PERSONAL

Actualmente se trabaja en la creación de un Docker que permita sustituir la máquina virtual por el EKMS-ESP y el simulador para incluirlo tanto en el ordenador de desarrollo como en la máquina de ejecución. El hecho de que sea un producto útil para la empresa, que sea un proyecto individual pero que al mismo tiempo requiera comunicación y coordinación con el resto de miembros del equipo y las dimensiones del proyecto lo hacen muy enriquecedor tanto a nivel profesional como personal. El conocimiento adquirido sobre el EKMS-ESP necesario para el desarrollo de este TFG ha creado ciertas inquietudes sobre el campo de la ciberseguridad que pueden ser satisfechas con cursos de especialización en el futuro.

En cuanto a los conocimientos adquiridos en el grado anterior a este TFG, fueron de bastante utilidad tanto a nivel de eficiencia en la programación como en el diseño de un sistema desde cero.

ANEXO A

CONFIGURACIÓN DE JASMINE

Para este sistema se utilizaron tres tipos de informes: los que muestra la consola en tiempo de ejecución para que pueda comprobar el estado de la ejecución en tiempo real, informes en archivos .xml que son utilizados por los complementos de Jenkins para preparar sus informes. informes personalizados (explicados más adelante, en la sección de Jenkins) e informes en formato HTML para una mejor visualización. En la Figura A.1 se muestra un ejemplo del formato de estos informes. Como se explicó anteriormente, estos archivos .xml son los que Jenkins usa para generar sus propios informes, que muestra en su propia página de la herramienta.

Finalmente, el complemento transportador protractor-beautiful-reporter se utiliza para generar informes HTML.

ANEXO B

CONFIGURACIÓN DE JENKINS

Este complemento le permite agregar comentarios a las pruebas que fallaron. Estos comentarios se enviarán por correo electrónico al equipo de desarrolladores para que todos estén al tanto del estado del sistema en todo momento. Este complemento mide la cobertura del código fuente a probar después de la ejecución de las pruebas. Este complemento genera gráficos sobre el informe actual y sobre el historial de informes gracias al .xml de Jasmine.

Gracias a estos complementos, es posible cumplir con varios de los requisitos del sistema, como generar cobertura, automatizar comunicados y almacenar informes.

ANEXO C

CONFIGURACIÓN DE PROTRACTOR

Al inicio del archivo se definen los informes a utilizar cada vez que se llama a la rutina de generación de informes, en este caso son tres; Además, se define la ruta donde se guardarán los informes. Posteriormente se definen las pruebas a ejecutar utilizando el parámetro specs, en este caso todas las pruebas siguen un formato de nomenclatura 'EKMS/tests/*.js, donde * es el nombre de la prueba específica. Las opciones determinan el navegador que se utilizará y el tamaño de la ventana del programa.

Todo informe necesita la especificación de ciertos atributos, en el caso del reportero que genera el xml y el que muestra los resultados en pantalla lo único que se especifica es la ruta donde se guardan los informes.

ANEXO D

FUNCIÓN WAITFOR()

ANEXO E

DOCUMENTO DE ESPECIFICACIÓN DE REQUISITOS SOFTWARE

Criterio de Cumplimiento: El sistema genera informes de cobertura luego de realizar las pruebas. Descripción: El sistema debe tener una herramienta para detectar pérdidas de memoria al ejecutar pruebas. Descripción: El sistema debe poder paralelizar la ejecución de pruebas y debe ser paralelizable.

Criterio de conformidad: el sistema se ejecuta en una computadora con Debian 8.

BIBLIOGRAFÍA