Plataforma técnica · Seguridad

Seguridad del Sistema

Seguridad

La seguridad del ecosistema Nostromo se organiza como defensa en profundidad. Cada solicitud debe pasar por controles de identidad, autorización, alcance de tenant, validación de entrada, auditoría y protección de datos antes de modificar información contable, laboral o tributaria.

Superficie Protegida

Identidad y sesión

Orchestrator autentica usuarios con POST /api/auth/login, emite una cookie sid HttpOnly y valida cada solicitud contra auth.user_sessions.

Autorización RBAC

authenticateToken, authorizeRoute y requireRole restringen rutas según rol, recurso y operación.

Aislamiento de tenant

tenantResolver resuelve la base de datos activa por usuario o por tenant_id explícito cuando el rol es SUPER_ADMIN.

Auditoría

auditMiddleware y auditLog registran login, logout, mutaciones, denegaciones, exportaciones y cambios de configuración.

Modelo de Controles

flowchart LR
  Browser["Sevastopol"] --> Edge["Edge HTTPS"]
  Edge --> API["Orchestrator API"]
  API --> Auth["authenticateToken"]
  Auth --> Session["auth.user_sessions"]
  Auth --> RBAC["authorizeRoute / requireRole"]
  RBAC --> Tenant["tenantResolver"]
  Tenant --> Domain["Servicio de dominio"]
  Domain --> DB["Base tenant"]
  Domain --> Audit["auditLog"]
  Audit --> Monitoring["monitoring.audit_log"]

Controles por Capa

Capa	Control	Implementación principal	Criterio de aceptación
Transporte	HTTPS, CORS y headers de seguridad	`helmet`, `cors` y plataforma de despliegue	El tráfico público opera por TLS y solo acepta orígenes configurados
Identidad	Login con contraseña y sesión revocable	`routes/command/auth.ts`, `middleware/auth.ts`	La cookie `sid` existe solo tras credenciales válidas y sesión persistida
Segundo factor	TOTP y códigos de respaldo	`domain/auth/totp`	Usuarios con TOTP habilitado no reciben sesión hasta verificar el desafío
Autorización	RBAC por ruta y rol explícito	`lib/rbac.ts`, `requireRole`	Las rutas sensibles devuelven `403` para roles no autorizados
Tenant scope	Resolución controlada de base tenant	`lib/tenantResolver.ts`	Usuarios normales no eligen tenant arbitrario; `SUPER_ADMIN` debe declararlo
Auditoría	Registro de eventos y mutaciones	`lib/audit.ts`	Login, logout, cambios y errores relevantes quedan trazables
Datos	Clasificación, cifrado y redacción	Guías de protección de datos	No se registran secretos, tokens, RUT reales ni remuneraciones en claro

Riesgos y Mitigaciones

Riesgo	Mitigación vigente	Revisión esperada
Fuerza bruta sobre login	`loginRateLimiter` limita a 5 intentos por 15 minutos	Verificar que el proxy conserva IP real mediante `x-forwarded-for` o `x-real-ip`
Sesión comprometida	Sesiones persistidas en `auth.user_sessions` y revocables por logout o kill switch	Revisar sesiones activas desde Command ante incidente
Escalada de privilegios	`authorizeRoute`, `requireRole` y rutas declaradas en RBAC	Cada endpoint nuevo declara middleware antes del handler
Fuga entre tenants	Resolución de base por usuario y estado activo del tenant	Toda operación tenant-scoped usa `getDatabaseNameForUser` o contexto equivalente
Exposición en logs	Sanitización de auditoría y regla de no registrar datos críticos	Revisar logs antes de merge cuando se agregan campos sensibles
Inyección SQL	Consultas parametrizadas y builders compartidos	No concatenar entradas de usuario en SQL

Flujo de Revisión

Identificar si la ruta es pública, autenticada, administrativa o tenant-scoped.
Confirmar que el handler valida entrada antes de invocar servicios de dominio.
Verificar que la ruta usa authenticateToken y, cuando corresponde, authorizeRoute o requireRole.
Confirmar que el servicio opera contra el tenant correcto y no acepta tenant_id arbitrario para usuarios no privilegiados.
Revisar que errores y logs no expongan credenciales, tokens, RUT reales, remuneraciones ni datos financieros críticos.
Agregar o actualizar documentación cuando el control sea parte del contrato público de seguridad.