NexTool Solutions

No GLPI, uma permissão não é um botão de ligar/desligar: é o produto de três eixos que se multiplicam - perfil, entidade e interface. Errar essa combinação é a causa número um de pedidos de "acesso desaparecido" e da fuga de visibilidade entre áreas. Este guia mostra o modelo real, onde os direitos vivem no fundo de dados e as armadilhas que só aparecem em ambiente multi-entidade.

O modelo RBAC em três eixos

O controlo de acesso do GLPI (RBAC, Role-Based Access Control) combina três dimensões independentes que muita gente trata como uma só:

• Perfil - o conjunto de direitos, ou seja, o que a pessoa pode fazer (abrir, editar, eliminar, configurar).
• Entidade - o âmbito dos dados, ou seja, onde ela vê: que organização, filial ou departamento.
• Interface - como ela navega: Helpdesk (simplificada, para o utilizador final) ou Central (completa, para a operação).

O que confunde é que os três se combinam por atribuição, e não por herança automática. A tabela glpi_profiles_users liga um utilizador a um perfil dentro de uma entidade, com um sinalizador is_recursive que decide se o acesso desce para as sub-entidades. Por isso o mesmo utilizador pode ser Técnico na entidade "TI" e Self-Service na entidade "RH": são duas linhas distintas nessa tabela, cada uma com o seu âmbito.

A matriz de perfis que usamos como referência

Em vez de personalizar ao acaso os sete perfis de origem do GLPI, partimos de uma matriz enxuta e clonamos a partir dela. Menos perfis, com fronteiras claras, geram menos incidentes do que dez perfis quase idênticos cuja diferença ninguém recorda.

Regra prática de terreno: se dois perfis diferem numa única permissão, provavelmente deveriam ser um só. A proliferação de perfis é dívida técnica de segurança: cada perfil extra é mais uma coisa para auditar.

Onde os direitos vivem de facto

O ecrã de Perfis (Administração > Perfis) é apenas uma casca sobre a tabela glpi_profilerights. Cada linha guarda o par (perfil, objeto) e uma coluna rights que é um bitmask inteiro. Perceber isto muda o jogo na auditoria: em vez de clicar por dezenas de separadores, lê o direito diretamente no fundo de dados.

-- Direitos de um perfil sobre objetos-chave (o bitmask e um inteiro)
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'   -- ajuste ao nome no idioma de instalacao
  AND  pr.name IN ('ticket', 'computer', 'config', 'user', 'entity')
ORDER  BY pr.name;

-- Descodificacao dos bits base (validos para a maioria dos itemtypes):
--   READ = 1, UPDATE = 2, CREATE = 4, DELETE = 8, PURGE = 32
-- Ex.: bitmask 15 = READ+UPDATE+CREATE+DELETE (CRUD, sem purgar)

Os bits base valem para a maioria dos itemtypes, mas objetos como o pedido (ticket) empacotam sinalizadores extra no mesmo inteiro: visibilidade "meus / meu grupo / todos", atribuir, roubar, mudar prioridade. Não tente adivinhar esses bits de cor - confirme na interface e valide com uma sessão de teste antes de dar por certo.

Diagnóstico rápido: quem tem o quê

Antes de tocar em qualquer perfil, fotografe o estado atual. Esta consulta responde a "quem tem que perfil, em que entidade, e se desce para as filhas" - precisamente o retrato que mais falta numa auditoria de acesso:

-- Quem tem que perfil, em que entidade, com ou sem recursao
SELECT u.name          AS utilizador,
       p.name          AS perfil,
       p.interface     AS interface,
       e.completename  AS entidade,
       pu.is_recursive AS desce_para_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 = 'joao.silva'
ORDER  BY e.completename;

Correr isto periodicamente - mensalmente, no mínimo - é a forma barata de apanhar acumulação de privilégios: antigos membros de um grupo que continuam Supervisor, ou um perfil administrativo atribuído "só para testar" que ninguém removeu. Numa sustentação séria, este SELECT torna-se um relatório agendado, não uma caça manual quando o problema já rebentou.

Armadilhas de terreno

Na sustentação de ambientes multi-entidade de clientes, o pedido recorrente de "a minha permissão desapareceu" quase nunca é um bug: é a cache de sessão. O GLPI carrega os direitos do perfil no $_SESSION no momento do início de sessão. Se ajustar o bitmask enquanto o técnico está autenticado, ele mantém os direitos antigos até trocar de entidade no seletor ou voltar a iniciar sessão. Aprendemos a colocar "peça ao utilizador para sair e entrar de novo" no próprio guião de validação e a testar sempre numa sessão nova ou anónima - senão jura que configurou bem e o utilizador jura que não funciona, ambos com razão ao mesmo tempo.

As restantes que mais incidentes geram:

• Visibilidade "Todos" para o técnico - dar "ver todos os pedidos" faz o técnico ver pedidos de todas as entidades a que tem acesso, não só da sua. Num cliente com áreas sensíveis (RH, Jurídico), isto é uma fuga silenciosa. Prefira "do meu grupo".
• Esquecer o is_recursive - atribuir o perfil na entidade-raiz sem assinalar a recursão faz o utilizador não ver nenhuma sub-entidade. O sintoma clássico é "entro, mas não vejo nada". O inverso, recursão indevida, dá um acesso demasiado amplo sem ninguém reparar.
• Direito da Central num perfil Helpdesk - a interface Helpdesk ignora a maioria dos direitos da Central. Assinalar permissões de ativos num perfil helpdesk não faz nada; o menu simplesmente não existe nessa interface.
• Regras de atribuição fora de ordem - quem usa LDAP ou SSO atribui perfil por Regras de atribuição de autorizações (RuleRight). A regra genérica "atribuir Self-Service" tem de vir por último; se estiver no topo sem "parar de processar", ganha a todas as específicas e toda a gente cai como Self-Service.
• Não testar na pele do Self-Service - muitos defeitos só aparecem na interface Helpdesk. Mantenha um utilizador de teste por perfil e percorra o percurso real antes de libertar para produção.

Checklist de endurecimento de perfis

1. Parta da matriz mínima; clone perfis em vez de editar os de origem.
2. Defina a visibilidade de pedidos como "do meu grupo" por omissão; "Todos" só com justificação escrita.
3. Reveja o sinalizador is_recursive em cada atribuição de entidade.
4. Corra o SQL de diagnóstico mensalmente e remova o privilégio acumulado.
5. Mantenha um utilizador de teste por perfil e valide numa sessão nova após qualquer alteração.
6. Restrinja quem edita Perfis e Regras: o direito de UPDATE em profile e rule é, na prática, um direito de administrador.

Precisa de controlo de acesso a ecrãs e sistemas externos a partir do próprio GLPI, com uma matriz auditável? Conheça o módulo Access Matrix. E, se preferir subcontratar o desenho e a sustentação dos perfis, a NexTool implanta e mantém ambientes GLPI multi-entidade com governação de acesso revista periodicamente.

Revisto pela equipa NexTool Solutions.