Experimento Sprint 3 - ISIS2503-202310-S2-LasDivinas/Documentacion_Arquitectura GitHub Wiki

Escenarios de prueba

ASR 1: Notificar falla en instancia

Para comprobar que el ASR de notificar la falla en una instancia funciona de forma adecuada, se propone el siguiente escenario de prueba:

1. Detención de una instancia. Manualmente se detiene la ejecución de una de las instancias de máquinas virtuales que ejecutan la aplicación. El resultado esperado de esta prueba es que a más tardar dos minutos después del fallo inducido se obtenga una notificación del mismo por correo electrónico.
2. Comprobación de la recepción de la notificación. Se ingresa a alguno de los correos configurados para la recepción de la notificación tras la detección del fallo de alguna de las instancias en las que está desplegada la aplicación. Se comprueba que en dicho correo electrónico se tenga un mensaje referente a la falla detectada recién.

ASR 2: Impedir edición no autorizada de historias clínicas

Para comprobar que siempre que se intenta realizar una edición de historia clínica se utiliza la táctica de autenticación para evitar que actores no autorizados realicen esa acción, se diseñó el siguiente escenario de prueba, que consiste de tres momentos:

1. No autenticación: Se intenta realizar la edición de una historia clínica sin haberse autenticado previamente. El resultado esperado de este escenario de prueba es que no se permite la edición de las historias clínicas y se obtiene un mensaje que indica la falta de autorización del usuario actual.
2. Autenticación sin el rol apropiado: Se realiza el proceso de autenticación, pero con una cuenta que no cuenta con el rol necesario para editar historias clínicas, en concreto, con una cuenta que no tiene el rol de médico. El resultado esperado de esta prueba es idéntico a la anterior: se espera obtener un mensaje que indica la falta autorización del usuario actual para realizar la acción que intenta.
3. Autenticación y rol apropiado: Se realiza el proceso de autenticación con una cuenta que si tiene los permisos esperados para poder realizar la edición de historias clínicas, es decir, con una cuenta que tiene el rol de médico. El resultado esperado de esta prueba es que después de una autenticación exitosa, el usuario sea capaz de realizar la acción intentada.

ASR 3: Registrar confidencialmente creación de historias clínicas

Para cerciorarse que cuando un usuario crea una historia clínica se guarda el registro de quién y en qué momento realizó dicha creación usando cifrado simétrico para conservar la confidencialidad, se diseñó el siguiente escenario de prueba:

1. Se crea una nueva historia clínica. Se tienen en cuenta las restricciones impuestas por el ASR anterior, es decir, se realiza previamente el proceso de autenticación con un usuario que tiene el rol apropiado para crear historias clínicas. El resultado esperado de este paso es que el identificador único del usuario, así como el identificador de la historia clínica que fue creada y la fecha de creación, sean cifradas simétricamente y queden almacenadas en un archivo de registro. El archivo se maneja en formato JSON.
2. Se revisa el cifrado simétrico. Se realiza la revisión de que el cifrado simétrico almacenado en el archivo JSON sea correcto. Se toma el cifrado simétrico y se realiza el proceso de descifrado, para corroborar que la información almacenada en el archivo de registro sí corresponde con el usuario y el momento en el que se creó la historia clínica.
3. Se consulta el registro de creación. Una vez se ha concretado la creación de la historia clínica, se intenta consultar el registro de creación que debió haberse generado recién. Para ello, antes de la consulta, se realiza el proceso de autenticación con el rol de administrador de sistema, que es el único autorizado para consultar los registros. Una vez hecho eso, el resultado esperado de esta prueba es únicamente con el rol de administrador del sistema sea posible observar la información que se almacena con cada creación de cada historia clínica, que como mencionaba antes, es el identificador único del usuario que creó la historia, el identificador único de la historia clínica que fue creada y la fecha de creación de la historia clínica.

Implementación de la prueba

Sprint 3

Análisis de resultados

ASR 1: Notificar falla en instancia

Mientras se está corriendo la aplicación, se realiza la conexión por SSH a una de las instancias y se detiene su ejecución, simulando una caída en el servicio. Nótese que en la imagen se detiene la ejecución a las 12:43:52 GMT.

Posteriormente, se espera a la llegada del correo electrónico. En promedio, en las pruebas realizadas, el correo llega un minuto después de ocurrido el fallo. En este caso, el correo llegó a las 7:44 GMT-5 (hora colombiana, equivalente a 12:44 GMT), es decir, se demoró como máximo 68 segundos (en caso de que haya llegado a las 7:44:59 GMT-5).

ASR 2: Impedir edición no autorizada de historias clínicas

En primer lugar, se intenta realizar la edición de la historia clínica 678.

Dado que el usuario no se había autenticado previamente, el usuario es redirigido a la interfaz de login para que este pueda continuar.

Se realiza el proceso de autenticación, pero con una cuenta que no cuenta con el rol necesario para editar historias clínicas. En este caso, se usa la cuenta "juanse", el cual tiene el rol de "enfermero".

Dado que la cuenta "juanse" no tiene el rol apropiado para editar historias clínicas, se obtiene el siguiente mensaje, lo cual demuestra el correcto funcionamiento de la autenticación de la aplicación. Este impide que un usuario que no tenga el rol de "medico" realice alguna edición en una historia clínica arbitraria.

ASR 3: Registrar confidencialmente creación de historias clínicas

Primero, tras haberse autenticado con el usuario "ana", el cual posee el rol de "medico", se crea una historia clínica nueva. Esta cuenta con el id 89.

En la siguiente captura de pantalla se puede evidenciar como la historia clínica recién creada queda registrada.

Acto seguido, se revisa el log del JSON que almacena el registro de todas las historias clínicas creadas. Para esta prueba, se busca el registro de la historia clínica 89. A continuación, se evidencia que efectivamente el registro se encuentra almacenado en el log y esta cifrado.

Posteriormente, para verificar la precisión del cifrado almacenado en el JSON, se procede a descifrar el texto correspondiente. Como se puede notar en la siguiente captura de pantalla, al descifrar el mensaje de texto se obtiene el id del usuario que creo la historia clínica, el rol de dicho usuario, la fecha de creación, y el id de la historia clínica creada. Estos datos coinciden con la historia clínica 89 y con el usuario "ana", quien creo la historia clínica.

Finalmente, se consulta el registro de creación de la aplicación. Para ello, primero el usuario debe autenticarse con una cuenta de rol "administrador", por lo cual se utilizo para la prueba el usuario "p4d8". Después de autenticarse, el administrador tiene la capacidad de visualizar el registro de historias clínicas que ha sido creado. La correspondencia entre los datos de la historia clínica número 89 y los datos descifrados en la captura de pantalla anterior se puede observar claramente en la imagen siguiente.