[Backlog] Hardening de superadmin y migración de privilegios a permisos persistidos

[unnamedpilot]

Descripción

Actualmente el acceso de superadmin depende de credenciales de entorno (ADMIN_EMAIL + ADMIN_PASSWORD/ADMIN_PASSWORD_HASH) y una bandera calculada en login. Este mecanismo es útil como break-glass, pero como único esquema de privilegios limita trazabilidad, revocación granular y escalabilidad de seguridad.

Se propone dejar en backlog la evolución a un modelo de permisos persistidos (BD/claims) para superadmin, manteniendo opcionalmente una cuenta de emergencia por entorno. El objetivo es reducir riesgo operativo sin romper el flujo actual en el corto plazo.

Usuarios afectados

• Equipo técnico (frontend/backend/devops).
• Administradores de plataforma.
• Seguridad/soporte (auditoría e incident response).

Criterios de aceptación

• Se define diseño objetivo de superadmin persistido (ej. Is_SuperAdmin en Staff o tabla de permisos).
• Se conserva opción de cuenta break-glass por entorno con uso acotado y auditado.
• Se documenta estrategia de migración sin downtime desde el esquema actual.
• Se define plan de endurecimiento de sesión para admins/superadmin (alineado con middleware/guards).
• Queda documentado runbook de rotación/revocación de credenciales críticas.

Alcance técnico

• src/pages/api/auth/login/index.ts
• src/lib/auth/apiAuth.ts
• src/hooks/useAdminAuth.ts
• src/pages/api/admin/**
• src/pages/api/staff/**
• src/db/schema.sql (si se agrega campo/tabla de permisos)
• specs/ (documentación de arquitectura y operación)

Consideraciones / Riesgos

• Cambios de auth pueden afectar rutas protegidas y UX de login/logout.
• Debe evitarse confiar solo en guards cliente; autorización server-side sigue siendo obligatoria.
• Requiere coordinación con otras iniciativas de hardening para no duplicar esfuerzos.

Dependencias

• Relacionado con [REQ] Hardening de acceso con proxy y centralización de guards #67 (middleware + centralización de guards).
• Relacionado con [EPIC] Descomposición de vistas monolíticas en src/app #59 y sub-issues de refactor UI (acceso y permisos por vista).
• Prioridad: backlog (no inmediata).