c39a2d67b1
This document outlines the security criteria, access control, and testing guidelines for the HR Platform system, along with visual guidelines for maintaining a minimalist and consistent aesthetic. It aims to ensure that the system is secure, verifiable, and governable before scaling to production.
4.0 KiB
SECURITY & TESTING – Roles, Permisos y Estética
Este documento define los criterios de seguridad, control de acceso y pruebas del sistema HR Platform, así como lineamientos visuales para mantener una estética minimalista y consistente.
Su objetivo es garantizar que el sistema sea seguro, verificable y gobernable, incluso antes de escalar a producción.
1. Lineamientos de estética (UI / UX)
1.1 Principios visuales
- Estilo minimalista: menos ruido, más claridad.
- Jerarquía visual clara.
- Interfaces predecibles.
- Priorizar legibilidad sobre decoración.
1.2 Paleta
- Base: Catppuccin Latte.
- Fondos claros, suaves.
- Contrastes suficientes para accesibilidad.
- Acentos discretos (no saturados).
1.3 Iconografía
Se permite el uso de:
- Catppuccin Icons.
- Google Material Icons.
Reglas:
- Uso consistente.
- Tamaños uniformes.
- Íconos funcionales, no decorativos.
2. Modelo de seguridad
2.1 Principios
- Menor privilegio por defecto.
- Todo acceso es explícito.
- Los permisos se configuran, no se codifican.
- La seguridad es verificable mediante pruebas.
3. Tipos de usuario
El sistema acepta tres tipos de usuario.
3.1 Root
Rol reservado para control total del sistema.
Permisos:
- Acceso completo a todos los módulos.
- Gestión de configuraciones globales.
- Definición de roles y permisos.
- Acceso a logs y eventos.
- Gestión de webhooks.
Este rol debe existir en número mínimo.
3.2 Admin
Rol operativo con permisos elevados.
Permisos típicos:
- Crear, editar y consultar socias.
- Aprobar o rechazar vacaciones.
- Aprobar o rechazar permisos.
- Consultar reportes.
- Acceso limitado a configuraciones.
No puede:
- Cambiar reglas globales críticas.
- Modificar permisos del rol Root.
3.3 User
Rol estándar.
Permisos base:
- Ver información permitida.
- Crear solicitudes propias (vacaciones, permisos).
- Modificar únicamente campos explícitamente autorizados.
No puede:
- Ver información sensible global.
- Editar reglas.
- Aprobar solicitudes.
4. Sistema granular de permisos
4.1 Modelo
El sistema utiliza un modelo granular basado en checkboxes, no en roles rígidos.
Cada permiso es una bandera configurable.
Ejemplos:
socias.readsocias.updatevacaciones.createvacaciones.approvepermisos.readconfig.edit
4.2 Niveles
Los permisos pueden aplicarse a:
- Rol completo.
- Usuario específico.
- Módulo.
- Acción.
Esto permite combinaciones finas sin crear nuevos roles.
4.3 UI de permisos
- Interfaz con checkboxes.
- Agrupación por módulo.
- Visualización clara de lo permitido y lo bloqueado.
- Cambios auditados.
5. Control de acceso
- Middleware de autorización en backend.
- Validación por permiso, no solo por rol.
- Reglas evaluadas en tiempo de ejecución.
6. Pruebas de seguridad
6.1 Tests de roles
- Verificar acceso correcto por rol.
- Validar bloqueos esperados.
- Intentos de escalación de privilegios.
6.2 Tests de permisos granulares
- Usuario con permisos parciales.
- Usuario con combinaciones específicas.
- Revocación dinámica de permisos.
6.3 Tests de endpoints
- Acceso autorizado.
- Acceso denegado.
- Manipulación de payload.
6.4 Tests de eventos y webhooks
- Emisión solo desde acciones válidas.
- No emisión desde acciones no autorizadas.
- Registro correcto de eventos.
7. Auditoría
-
Registro de:
- Cambios de permisos.
- Accesos críticos.
- Acciones administrativas.
-
Logs inmutables.
8. Criterios de aceptación de seguridad
El sistema se considera válido cuando:
- Un usuario nunca puede hacer más de lo permitido.
- Todos los accesos están trazados.
- Los permisos pueden cambiar sin deploy.
- Las pruebas cubren roles y permisos.
9. Nota final
La seguridad no es una capa.
Es una propiedad emergente del diseño.
Este documento define cómo se prueba y cómo se protege el sistema.