mirror of
https://github.com/marcogll/hr_soul23.git
synced 2026-01-13 13:25:16 +00:00
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.
227 lines
4.0 KiB
Markdown
227 lines
4.0 KiB
Markdown
# 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.read`
|
||
* `socias.update`
|
||
* `vacaciones.create`
|
||
* `vacaciones.approve`
|
||
* `permisos.read`
|
||
* `config.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.
|