🔐 Validar Logs De Acceso Y Auditoría Por Perfil De Usuario

by Admin 60 views
🔐 Validación de Logs de Acceso y Auditoría por Perfil de Usuario

¡Hola, equipo! En este artículo, vamos a sumergirnos en la implementación de pruebas automáticas para garantizar que nuestros logs de acceso y auditoría se filtren correctamente según el perfil del usuario. Esto es crucial para la seguridad, el cumplimiento normativo y la confianza en nuestro sistema. ¡Vamos a ello!

🎯 Objetivo: Implementar Pruebas de Validación Automática

El objetivo principal es establecer una validación automática mediante pruebas (tests) que aseguren que los logs de acceso y auditoría se filtran adecuadamente según el perfil del usuario, respetando el modelo multi-tenancy del sistema. En otras palabras, queremos asegurarnos de que los diferentes tipos de usuarios solo puedan ver los datos a los que tienen acceso, evitando cualquier fuga de información o acceso no autorizado. Esto no solo mejora la seguridad, sino que también facilita el cumplimiento de las regulaciones y audiciones.

La correcta implementación de estas pruebas nos permitirá detectar problemas de permisos y accesos indebidos de manera temprana, lo que reduce el riesgo de incidentes de seguridad y facilita la resolución de problemas. Además, al automatizar estas pruebas, nos aseguramos de que cada cambio en el sistema no comprometa la integridad de los logs y la información que contienen. El objetivo final es tener un sistema robusto, seguro y confiable que cumpla con todos los requisitos de auditoría.

📋 Contexto: Tipos de Usuarios y sus Permisos

En nuestro sistema, Ticket Home, tenemos cuatro tipos de usuarios, cada uno con diferentes permisos y acceso a la información:

  • Superusuario (clinic_id = NULL): Este usuario tiene acceso a TODOS los logs y puede ver el campo clinic_id, lo que le permite tener una vista completa de todos los datos en el sistema. Este tipo de usuario suele ser el administrador principal del sistema, con la capacidad de supervisar todas las actividades.
  • Admin (clinic_id = 1,2,3...): Los administradores solo pueden ver los logs relacionados con su propia clínica. Esto significa que están aislados y solo tienen acceso a la información relevante para su clínica específica. El clinic_id identifica a qué clínica pertenece cada administrador.
  • Clinical: Este tipo de usuario opera de manera similar a los administradores, con el mismo nivel de aislamiento y acceso a los datos de su clínica.
  • Visualizador: Los visualizadores también tienen el mismo nivel de aislamiento que los administradores, lo que garantiza que solo puedan ver los datos de su clínica.

Este modelo de multi-tenancy es esencial para la seguridad y la privacidad de los datos, ya que evita que los usuarios de una clínica puedan acceder a la información de otras clínicas. La correcta implementación de los permisos es fundamental para el funcionamiento del sistema.

🧪 Tests a Implementar: Garantizando la Integridad de los Logs

Para garantizar que el sistema funcione correctamente, implementaremos una serie de pruebas (tests) que cubran los diferentes escenarios y roles de usuario. Estas pruebas nos ayudarán a detectar cualquier problema en el filtrado de los logs y asegurarán que los usuarios solo puedan acceder a la información que les corresponde.

Test 1: Superusuario ve todos los logs

Este test verificará que el superusuario, al ser el usuario con más permisos, pueda ver todos los logs de acceso. Esto incluye logs de todas las clínicas, lo que le permite tener una vista global del sistema. Además, el test debe verificar que la columna clinic_id esté visible en la interfaz de usuario para el superusuario, ya que esta columna proporciona información crucial sobre la clínica a la que pertenece cada log.

def test_superuser_sees_all_login_logs(client, superuser, clinic1_admin, clinic2_admin):
    # Crear logs de diferentes clínicas
    # Login como superusuario
    # Verificar que ve logs de TODAS las clínicas
    # Verificar que columna clinic_id es visible en UI
    pass

Test 2: Admin solo ve logs de su clínica

Este test se enfoca en verificar que los administradores solo puedan ver los logs correspondientes a su clínica. El test creará logs para diferentes clínicas y, luego, iniciará sesión como administrador de una clínica específica. La prueba verificará que el administrador solo pueda ver los logs de su clínica y que no pueda acceder a los logs de otras clínicas, garantizando el aislamiento de los datos.

def test_admin_only_sees_own_clinic_logs(client, clinic1_admin, clinic2_admin):
    # Crear logs de clínica 1 y 2
    # Login como admin de clínica 1
    # Verificar que SOLO ve logs de clínica 1
    # Verificar que NO ve logs de clínica 2
    pass

Test 3: ActionAudit respeta multi-tenancy

Este test se centra en asegurar que la funcionalidad de ActionAudit respete el modelo multi-tenancy. Esto significa que las acciones realizadas en una clínica no deben ser visibles para los usuarios de otras clínicas. El test creará acciones en diferentes clínicas, iniciará sesión como usuario de una clínica específica y verificará que solo pueda ver las acciones realizadas en su propia clínica, garantizando el aislamiento de los datos y la seguridad.

def test_action_audit_multi_tenancy(client, clinic1_user, clinic2_user):
    # Crear acciones en diferentes clínicas
    # Login como user de clínica 1
    # Verificar isolation
    pass

Test 4: Superusuario puede filtrar por clínica

Este test se asegura de que el superusuario, además de ver todos los logs, pueda filtrarlos por clínica específica. Esto es útil para que el superusuario pueda concentrarse en los logs de una clínica en particular cuando sea necesario. El test creará logs de múltiples clínicas, iniciará sesión como superusuario, aplicará un filtro por clínica específica y verificará que solo se muestren los logs de esa clínica.

def test_superuser_can_filter_by_clinic(client, superuser):
    # Crear logs de múltiples clínicas
    # Login como superusuario
    # Aplicar filtro por clínica específica
    # Verificar que solo muestra esa clínica
    pass

📁 Archivos a Modificar/Crear: Estructura de las Pruebas

Para implementar estas pruebas, deberemos modificar y crear los siguientes archivos:

tests/
├── test_audit_logs.py           # NUEVO: Tests de auditoría
└── conftest.py                  # Agregar fixtures de logs

routes/
└── admin.py                     # Verificar que queries filtran correctamente

templates/admin/
├── login_audit.html             # Verificar que muestra clinic_id para superusuarios
└── action_audit.html            # Verificar isolation
  • tests/test_audit_logs.py: Este es el archivo donde implementaremos las pruebas de auditoría descritas anteriormente. Aquí definiremos las funciones de prueba (tests) y las lógicas necesarias para validar el comportamiento del sistema.
  • tests/conftest.py: Este archivo se utilizará para definir las fixtures necesarias para las pruebas. Las fixtures son funciones que preparan el entorno para las pruebas, como la creación de usuarios, la configuración de la base de datos y la creación de logs de ejemplo.
  • routes/admin.py: Este archivo contiene las rutas y la lógica de la aplicación que se encarga de la gestión de los logs de acceso y auditoría. Deberemos verificar que las consultas (queries) que se ejecutan en estas rutas filtren correctamente los logs según el perfil del usuario.
  • templates/admin/login_audit.html: Este archivo contiene la plantilla HTML que se utiliza para mostrar los logs de acceso. Deberemos verificar que la columna clinic_id sea visible para los superusuarios y que no se muestre para otros usuarios.
  • templates/admin/action_audit.html: Esta plantilla HTML se utiliza para mostrar los logs de auditoría de acciones. Deberemos verificar que la información mostrada respete el aislamiento de los usuarios y que solo se muestren las acciones correspondientes a su clínica.

🔍 Casos de Prueba Críticos: Escenarios Clave

Estos son los casos de prueba críticos que deben ser cubiertos para asegurar que los logs de acceso y auditoría funcionen correctamente:

LoginAudit

  1. ✅ Superusuario ve todos los logins
  2. ✅ Admin solo ve logins de su clínica
  3. ✅ Columna clinic_id visible solo para superusuarios
  4. ✅ Filtros respetan multi-tenancy

ActionAudit

  1. ✅ Superusuario ve todas las acciones
  2. ✅ Admin solo ve acciones de su clínica
  3. ✅ Acciones de creación de tickets tienen clinic_id correcto
  4. ✅ Modificaciones de FPA tienen clinic_id correcto

Estos casos de prueba cubren los escenarios clave que debemos verificar para garantizar que los logs de acceso y auditoría funcionen correctamente. Cada uno de estos casos es importante para asegurar la seguridad, el cumplimiento y la confianza en nuestro sistema.

📊 Queries a Validar: Asegurando el Filtrado Correcto

Es fundamental validar que las consultas SQL se ejecuten correctamente según el perfil del usuario. Esto garantizará que los datos se filtren adecuadamente y que los usuarios solo puedan acceder a la información que les corresponde.

Superusuario

-- DEBE ejecutar query SIN filtro de clinic_id
SELECT * FROM login_audit 
ORDER BY timestamp DESC;

Para el superusuario, la consulta SQL debe ejecutarse sin un filtro por clinic_id. Esto permite al superusuario ver todos los logs de acceso y auditoría, ya que tiene acceso a toda la información del sistema. La consulta solo ordena los resultados por marca de tiempo (timestamp) en orden descendente.

Admin de Clínica

-- DEBE ejecutar query CON filtro de clinic_id
SELECT * FROM login_audit 
WHERE clinic_id = :current_user_clinic_id
ORDER BY timestamp DESC;

Para los administradores de clínica, la consulta SQL debe incluir un filtro por clinic_id. El filtro se basa en el valor de current_user_clinic_id, que representa el clinic_id del administrador que ha iniciado sesión. Esto asegura que el administrador solo pueda ver los logs de acceso y auditoría correspondientes a su clínica, garantizando el aislamiento de los datos y la seguridad.

✅ Definition of Done: Criterios de Finalización

Para considerar que este trabajo ha sido completado, debemos cumplir con los siguientes criterios:

  • [ ] Tests de LoginAudit implementados (4 tests)
  • [ ] Tests de ActionAudit implementados (4 tests)
  • [ ] Test de filtros de búsqueda (2 tests)
  • [ ] Test de creación de logs con clinic_id correcto (2 tests)
  • [ ] Todos los tests pasan
  • [ ] Coverage de rutas de auditoría >80%
  • [ ] Documentación en tests/README.md actualizada

Estos criterios aseguran que todas las pruebas se hayan implementado y que el sistema funcione correctamente, garantizando la seguridad y el cumplimiento normativo.

📚 Documentación de Referencia: Profundizando en el Tema

Para una comprensión más profunda de los logs de acceso y auditoría por perfil de usuario, puedes consultar la explicación completa en: EXPLICACION_LOGS_PERFIL.html. Esta documentación proporciona detalles adicionales sobre el funcionamiento del sistema y la importancia de la seguridad de los datos.

🎯 Beneficios: ¿Por Qué es Importante?

La implementación de estas pruebas y la correcta gestión de los logs de acceso y auditoría ofrecen múltiples beneficios:

  • Seguridad: Previene fugas de información entre clínicas, protegiendo los datos sensibles.
  • Compliance: La auditoría correcta es un requerimiento legal en muchos sectores.
  • Confianza: Los tests automáticos previenen bugs y errores, aumentando la confianza en el sistema.
  • Debugging: Facilita la identificación y resolución de problemas de permisos, agilizando el proceso de desarrollo y mantenimiento.

🏷️ Labels: Categorización del Trabajo

Las siguientes etiquetas (labels) se han aplicado a este trabajo para facilitar su seguimiento y organización:

  • testing: Indica que este trabajo se centra en la implementación de pruebas.
  • security: Destaca la importancia de la seguridad en este proyecto.
  • audit: Relacionado con la auditoría de logs.
  • priority: high: Indica que este trabajo es de alta prioridad.

¡Eso es todo, equipo! Con la implementación de estas pruebas, estaremos un paso más cerca de tener un sistema robusto, seguro y confiable. ¡A trabajar!