NexTool Solutions

En GLPI, un permiso no es un interruptor de encendido/apagado: es el producto de tres ejes que se multiplican - perfil, entidad e interfaz. Equivocar esa combinación es la causa número uno de tickets de "acceso desaparecido" y de la fuga de visibilidad entre áreas. Esta guía muestra el modelo real, dónde viven realmente los derechos en la base de datos y las trampas que solo aparecen en un entorno multientidad.

El modelo RBAC en tres ejes

El control de acceso de GLPI (RBAC, Role-Based Access Control) combina tres dimensiones independientes que mucha gente trata como una sola:

• Perfil - el conjunto de derechos, es decir, qué puede hacer la persona (abrir, editar, borrar, configurar).
• Entidad - el alcance de los datos, es decir, dónde ve: qué organización, sucursal o departamento.
• Interfaz - cómo navega: Helpdesk (simplificada, para el usuario final) o Central (completa, para la operación).

Lo que confunde es que los tres se combinan por asignación, no por herencia automática. La tabla glpi_profiles_users vincula un usuario a un perfil dentro de una entidad, con un flag is_recursive que decide si el acceso desciende a las subentidades. Por eso el mismo usuario puede ser Técnico en la entidad "TI" y Self-Service en la entidad "RR. HH.": dos filas distintas en esa tabla, cada una con su alcance.

La matriz de perfiles que usamos como base

En lugar de personalizar al azar los siete perfiles de fábrica de GLPI, partimos de una matriz reducida y clonamos a partir de ella. Menos perfiles con fronteras claras generan menos incidentes que diez perfiles casi idénticos cuya diferencia nadie recuerda.

Regla práctica de campo: si dos perfiles difieren en un solo permiso, probablemente deberían ser uno. La proliferación de perfiles es deuda técnica de seguridad: cada perfil extra es una cosa más que auditar.

Dónde viven realmente los derechos

La pantalla de Perfiles (Administración > Perfiles) es solo una capa sobre la tabla glpi_profilerights. Cada fila guarda el par (perfil, objeto) y una columna rights que es un bitmask entero. Entender esto cambia el juego en la auditoría: en lugar de hacer clic en decenas de pestañas, lees el derecho directamente en la base de datos.

-- Derechos de un perfil sobre objetos clave (el bitmask es un entero)
SELECT p.name    AS perfil,
       pr.name   AS objeto,
       pr.rights AS bitmask
FROM   glpi_profilerights pr
JOIN   glpi_profiles p ON p.id = pr.profiles_id
WHERE  p.name = 'Tecnico'   -- ajusta al nombre del idioma de instalacion
  AND  pr.name IN ('ticket', 'computer', 'config', 'user', 'entity')
ORDER  BY pr.name;

-- Decodificacion de los bits base (validos para la mayoria de itemtypes):
--   READ = 1, UPDATE = 2, CREATE = 4, DELETE = 8, PURGE = 32
-- Ej.: bitmask 15 = READ+UPDATE+CREATE+DELETE (CRUD, sin purgar)

Los bits base valen para la mayoría de los itemtypes, pero objetos como el ticket (ticket) empaquetan flags adicionales en el mismo entero: visibilidad "míos / mi grupo / todos", asignar, robar, cambiar prioridad. No intentes adivinar esos bits de memoria - confírmalos en la interfaz y valida con una sesión de prueba antes de darlo por hecho.

Diagnóstico rápido: quién tiene qué

Antes de tocar cualquier perfil, fotografía el estado actual. Esta consulta responde "quién tiene qué perfil, en qué entidad, y si desciende a las hijas" - justo la imagen que más falta en una auditoría de acceso:

-- Quien tiene que perfil, en que entidad, con o sin recursion
SELECT u.name          AS usuario,
       p.name          AS perfil,
       p.interface     AS interfaz,
       e.completename  AS entidad,
       pu.is_recursive AS baja_a_subentidades
FROM   glpi_profiles_users pu
JOIN   glpi_users    u ON u.id = pu.users_id
JOIN   glpi_profiles p ON p.id = pu.profiles_id
JOIN   glpi_entities e ON e.id = pu.entities_id
WHERE  u.name = 'juan.perez'
ORDER  BY e.completename;

Ejecutar esto de forma periódica - mensual como mínimo - es la manera barata de detectar acumulación de privilegios: ex miembros de un grupo que siguen siendo Supervisor, o un perfil administrativo asignado "solo para probar" que nadie quitó. En un mantenimiento serio, este SELECT se convierte en un informe programado, no en una búsqueda manual cuando el problema ya explotó.

Trampas de campo

En el mantenimiento de entornos multientidad de clientes, el ticket recurrente de "mi permiso desapareció" casi nunca es un bug: es la caché de sesión. GLPI carga los derechos del perfil en $_SESSION en el momento del login. Si ajustas el bitmask mientras el técnico está conectado, sigue con los derechos antiguos hasta que cambie de entidad en el selector o vuelva a iniciar sesión. Aprendimos a poner "pide al usuario que salga y vuelva a entrar" en el propio guion de validación y a probar siempre en una sesión nueva o de incógnito - de lo contrario juras que lo configuraste bien y el usuario jura que no funciona, ambos con razón al mismo tiempo.

Las demás que más incidentes generan:

• Visibilidad "Todos" para el técnico - dar "ver todos los tickets" hace que el técnico vea tickets de todas las entidades a las que tiene acceso, no solo de la suya. En un cliente con áreas sensibles (RR. HH., Legal) esto es una fuga silenciosa. Prefiere "de su grupo".
• Olvidar is_recursive - asignar el perfil en la entidad raíz sin marcar la recursión hace que el usuario no vea ninguna subentidad. El síntoma clásico es "entro pero no veo nada". Lo contrario, recursión indebida, da un acceso demasiado amplio sin que nadie se dé cuenta.
• Derecho de la Central en un perfil Helpdesk - la interfaz Helpdesk ignora la mayoría de los derechos de la Central. Marcar permisos de activos en un perfil helpdesk no hace nada; el menú simplemente no existe en esa interfaz.
• Reglas de asignación en mal orden - quien usa LDAP o SSO asigna perfil por Reglas de asignación de autorizaciones (RuleRight). La regla genérica "asignar Self-Service" debe ir la última; si está arriba sin "detener el procesamiento", gana a todas las específicas y todo el mundo cae como Self-Service.
• No probar en la piel del Self-Service - muchos defectos solo aparecen en la interfaz Helpdesk. Mantén un usuario de prueba por perfil y recorre el trayecto real antes de liberar a producción.

Checklist de endurecimiento de perfiles

1. Parte de la matriz mínima; clona perfiles en lugar de editar los de fábrica.
2. Define la visibilidad de tickets como "de su grupo" por defecto; "Todos" solo con justificación escrita.
3. Revisa el flag is_recursive en cada asignación de entidad.
4. Ejecuta el SQL de diagnóstico mensualmente y quita el privilegio acumulado.
5. Mantén un usuario de prueba por perfil y valida en una sesión nueva tras cualquier cambio.
6. Restringe quién edita Perfiles y Reglas: el derecho de UPDATE en profile y rule es, en la práctica, un derecho de administrador.

¿Necesitas control de acceso a pantallas y sistemas externos desde el propio GLPI, con una matriz auditable? Conoce el módulo Access Matrix. Y si prefieres externalizar el diseño y el mantenimiento de los perfiles, NexTool implanta y mantiene entornos GLPI multientidad con gobernanza de acceso revisada periódicamente.

Revisado por el equipo de NexTool Solutions.