Existe una pregunta que todo sistema corporativo necesita responder con precisión: ¿quién puede hacer qué? Responder “depende” no sirve. El módulo de Roles del Portal Nyverra ITSM implementa RBAC (control de acceso basado en roles) para dar a cada persona exactamente los permisos que necesita — ni más, ni menos.

Esta guía explica cómo funcionan los roles, permisos, el alcance por cliente, la protección de funciones sensibles con 2FA y la delegación temporal.

Interfaz del módulo en el Portal Nyverra ITSM.

Roles, permisos y usuarios

El modelo tiene tres capas:

Capa	Qué es
Permiso	La acción específica (p. ej., TICKET_VIEW_ALL, TICKET_UPDATE_ALL, CONFIG_VIEW)
Rol	Un conjunto de permisos agrupados por función
Usuario	Recibe uno o más roles, y el Portal habilita recursos según los permisos resultantes

Este diseño evita conceder permisos “sueltos” a cada persona: se modela la función una vez y se asigna el rol.

Permisos granulares

Los permisos son específicos por recurso y acción, lo que permite separar visualización de modificación, y alcance “propio” de “global”. Ejemplos del día a día:

• TICKET_VIEW_OWN / TICKET_VIEW_ASSIGNED / TICKET_VIEW_ALL — lo que el usuario ve.
• TICKET_UPDATE_OWN / ..._ASSIGNED / ..._ALL — lo que modifica.
• TICKET_DELETE, CONFIG_VIEW, MODULE_MANAGE, RELEASE_*, CHANGE_* — operaciones sensibles.

Es esta granularidad la que hace que el módulo sirva tanto a un cliente (que ve solo su alcance) como a un administrador global.

Alcance por cliente

Además de los permisos, muchos accesos están limitados por cliente: un técnico puede ser VIEW_ALL en un cliente y VIEW_OWN en otro (o mediante delegación por contexto). En MSPs, esto es lo que evita que un técnico acceda a datos de una cuenta que no es suya.

Funciones sensibles y 2FA

Los permisos que modifican configuraciones globales, gestionan usuarios o aprueban cambios no deberían depender solo de una contraseña simple. El Portal permite exigir 2FA (segundo factor) para roles sensibles, reforzando la protección justamente donde el impacto de un acceso indebido es mayor.

Delegación temporal

¿Y si el aprobador se va de vacaciones? En lugar de conceder el permiso “para siempre”, el módulo permite delegación con fecha de fin: el usuario recibe los permisos por un período y expiran automáticamente. Es control de acceso con fecha de vencimiento — mucho más seguro que olvidarse de revocar manualmente.

Quién lo usa

Perfil	Uso
Administrador	Crear/editar roles y asignarlos a los usuarios
Super administrador	Cuentas privilegiadas y elevación de perfil
Gestor	Solicitar/conceder delegaciones por período

Cómo usar: paso a paso

1. Mapee las funciones de la operación (N1, N2, gestor, admin, cliente).
2. Cree roles con el conjunto mínimo de permisos.
3. Asigne los roles a los usuarios.
4. Proteja funciones sensibles con 2FA.
5. Conceda delegaciones temporales con fecha de fin cuando sea necesario.
6. Revise roles y asignaciones periódicamente.

Reglas de negocio

Regla	Explicación
Menor privilegio	Conceda solo lo necesario para la función.
Super admin	Solo este perfil promueve administradores o edita cuentas privilegiadas.
Delegación	Los permisos temporales exigen justificación y fecha de fin.
2FA	Puede ser obligatorio para roles sensibles.

Buenas prácticas

• Aplique el menor privilegio por defecto.
• Evite roles “hazlo todo”: prefiera roles enfocados.
• Prefiera la delegación temporal a conceder permiso permanente.
• Exija 2FA para funciones de alto impacto.
• Revise los permisos ante cada cambio de función o baja.

Errores comunes

Situación	Qué hacer
Usuario “no ve” algo	Revise el rol, permiso y alcance de cliente.
Privilegios acumulados	Revise las asignaciones; elimine lo que ya no es necesario.
Delegación olvidada	Use fecha de fin; revise las delegaciones activas.

Preguntas frecuentes

¿Cuál es la diferencia entre rol y permiso?
El permiso es la acción; el rol es el conjunto de permisos asignado a personas.

¿Puedo conceder acceso temporal?
Sí, mediante delegación con fecha de fin.

¿Los roles sustituyen a los grupos de operadores?
No. Los roles definen qué puede hacer; los grupos definen la cola de atención.

Automatice vía API

Los roles y permisos se exponen por API (/api/roles, /api/permissoes, /api/rbac), con soporte para delegación. Referencia en developer.nyverra.com.

Escenarios de uso: el RBAC en la práctica

1. Técnico de cliente. Recibe un rol que le permite ver y actualizar solo los tickets de su alcance (VIEW_OWN/UPDATE_OWN). No ve datos de otras organizaciones — aislamiento por alcance.

2. Gestor de cola. Su rol incluye VIEW_ALL y UPDATE_ASSIGNED, lo que le permite administrar la cola del grupo sin acceder a configuraciones globales.

3. Administrador con 2FA. El rol administrativo exige segundo factor, porque modifica configuraciones que afectan a toda la instancia.

4. Vacaciones del aprobador. Se concede una delegación temporal con fecha de fin — el aprobador sustituto decide por un período, y el permiso expira automáticamente.

KPIs y gobernanza de acceso

Indicador	Qué revela
Roles creados vs usuarios por rol	Simplicidad del modelo
Roles con permisos “hazlo todo”	Riesgo de privilegio excesivo
Delegaciones activas	Control de cobertura
Usuarios con 2FA en roles sensibles	Postura de seguridad

Menor privilegio: teoría y práctica

El principio es simple y difícil de mantener: cada persona con lo mínimo necesario. En la práctica, exige revisión periódica — las funciones cambian, las personas cambian, los privilegios se acumulan. El RBAC del Portal Nyverra combina permisos granulares, alcance por cliente, 2FA en funciones críticas y delegación con plazo. Juntos, estos recursos hacen que el control de acceso sea, al mismo tiempo, seguro y gestionable — lo que separa el RBAC “de papel” del RBAC que funciona.

Checklist de RBAC

1. Mapee las funciones de la operación.
2. Cree roles con permisos mínimos.
3. Asocie usuarios a los roles correctos.
4. Exija 2FA en funciones sensibles.
5. Configure delegaciones con fecha de fin.
6. Revise permisos periódicamente.

Preguntas frecuentes adicionales

¿Rol y grupo son lo mismo?
No: rol = permisos; grupo = cola de atención.

¿Cómo conceder acceso temporal?
Mediante delegación con fecha de fin.

¿Un usuario puede tener más de un rol?
Sí, y los permisos resultantes se suman.

Conclusión

Con Roles, el Portal Nyverra ITSM ofrece control fino de acceso y fortalece seguridad y conformidad. Roles claros, permisos granulares, 2FA en las funciones sensibles y delegación con plazo hacen que el RBAC funcione de verdad — en el papel y en la práctica.