Seguridad

OnClock está diseñado como plataforma multi-tenant desde el primer día. Cada empresa vive en una base de datos Postgres aislada, con autenticación JWT con refresh, cifrado AES-256 para secretos sensibles y auditoría completa de cada acción privilegiada.

Multi-tenant

OnClock usa database-per-tenant: cada empresa tiene su propia base de datos Postgres con su propio schema. Ventajas:

• Aislamiento físico: un bug que exponga datos entre tenants es imposible. Las queries de una empresa nunca pueden tocar otra DB.
• Backups independientes: puedes exportar o restaurar una empresa sin afectar a las demás.
• Compliance: más fácil cumplir residencia de datos por cliente si se requiere.
• Escalabilidad: una empresa grande no degrada el performance de otras.

Una DB master centralizada guarda solo metadatos globales: lista de empresas, usuarios globales, configuración del super-admin, claves de API compartidas.

Autenticación

JWT con refresh tokens rotatorios:

• Access token: vida corta (30 min) — firmado con HS256.
• Refresh token: vida más larga (30 días), rotatorio: cada uso genera uno nuevo y el anterior se invalida.
• Hash de contraseñas: bcrypt con cost ≥ 12.
• Magic links para invitaciones: un solo uso, caducan en 24h.
• Password reset con tokens firmados de un solo uso.

Permisos y roles

Tres niveles de permisos:

Rol global (DB master)

• super_admin: administra la plataforma (todas las empresas).
• admin: administra una o varias empresas.
• pmo: privilegios de PMO en sus proyectos.
• user: rol por defecto.

Rol por empresa (DB tenant)

Un usuario puede pertenecer a varias empresas. En cada empresa tiene un rol independiente: admin, pmo, integrante, viewer.

Rol por proyecto

Dentro de una empresa, un integrante puede ser PMO de algunos proyectos y solo integrante en otros. El rol por proyecto se define en ProjectMember.

Permisos granulares

Además del rol, cada integrante tiene permisos finos que el PMO puede activar/desactivar:

• can_manage_members, can_assign_pmo
• can_create_tasks, can_edit_tasks, can_delete_tasks
• can_upload_documents, can_view_reports
• can_create_incidents, can_chat_agent
• y 10 más...

Cifrado

• En tránsito: TLS 1.2+ obligatorio en todas las comunicaciones.
• En reposo: Postgres con volumen cifrado. Secretos sensibles (API keys de proveedores AI, credenciales SMTP, tokens OAuth) cifrados con AES-256-GCM + HKDF.
• Passwords: nunca se guardan en texto plano. Hash bcrypt con salt único.
• Signed URLs: para descargar documentos, se generan URLs firmadas de un solo uso con caducidad.

Auditoría

Cada acción privilegiada (cambios de rol, borrado de datos, invitaciones, modificaciones de plan) queda registrada en la tabla audit_log de la DB master con:

• Usuario que ejecutó la acción.
• IP origen y user-agent.
• Timestamp preciso.
• Diff del antes/después (JSON).
• Resultado (éxito / fallo / motivo).

Los admins de empresa pueden descargar el audit log de su empresa en CSV desde Admin → Auditoría. El super-admin tiene acceso al log completo.

Rate limiting

Implementado con Redis + slowapi:

• Auth endpoints (login, register, password reset): 10 req/min por IP.
• API endpoints: 100 req/s por usuario autenticado.
• Agente AI: 60 mensajes/minuto por usuario.
• Email poller: respeta los límites del proveedor IMAP.

Compliance

• GDPR: cada empresa puede exportar sus datos en JSON desde Admin → Exportar. También puede solicitar el borrado completo (data deletion request).
• Retención: backups automáticos diarios con retención configurable por plan (30d / 90d / 1y).
• Headers de seguridad: CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Permissions-Policy configurados en nginx.
• CORS estricto: solo el origen del frontend puede llamar al backend. Headers explícitos (no wildcard).