NexTool Solutions

Numa auditoria, ninguém pergunta "quem tem acesso ao ERP". Perguntam "quem pode EXCLUIR um lançamento no ERP" - e a planilha de acessos raramente sabe responder. O Access Matrix leva essa matriz de decisão para dentro do GLPI: sistemas externos, seus módulos e quatro flags CRUD (Criar, Ler, Atualizar, Excluir) resolvidos por cargo, grupo e usuário. Este guia mostra o modelo de resolução, um diagnóstico SQL direto no banco, o formato de migração entre ambientes e as armadilhas que só aparecem em produção.

O problema real: a planilha que ninguém confia

Na sustentação de ambientes de clientes, o pedido que expõe a fragilidade do controle por planilha é sempre o mesmo. Chega uma auditoria (ISO 27001, SOX, ou um relatório de acesso para a LGPD) e o pedido é granular: "liste todos os cargos que podem criar e excluir registros no sistema financeiro". Uma planilha de "tem acesso / não tem acesso" não responde isso: não separa leitura de escrita, não tem histórico de quem mudou o que, e já está desatualizada porque o último desligamento não foi refletido. O Access Matrix ataca esse vazio: modela o acesso na granularidade CRUD e mantém tudo dentro do GLPI, junto do resto da operação de service desk.

O que o módulo modela: sistemas, módulos e quatro flags

A estrutura é deliberadamente simples. Você cadastra os sistemas externos (ERP, CRM, BI, portais de terceiros) e, dentro de cada um, os módulos relevantes (por exemplo "Contas a Pagar", "Faturamento", "Relatórios"). Para cada combinação de cargo e módulo, marca quatro checkboxes: Criar, Ler, Atualizar, Excluir. Uma permissão pode ser definida no nível do sistema inteiro ou por módulo específico. No banco, isso vira colunas can_create, can_read, can_update, can_delete (tinyint 0/1), com o módulo em NULL quando a regra vale para o sistema todo.

Um esclarecimento honesto e importante: o Access Matrix não é um proxy que bloqueia o login no ERP nem intercepta o sistema externo. É a matriz de decisão autoritativa - a fonte de verdade que documenta, resolve e exibe quem deve ter cada permissão, para que o time que provisiona o acesso (ou o auditor que revisa) trabalhe sobre um dado confiável dentro do GLPI, e não sobre uma planilha solta.

Resolução em 4 camadas (OR: a mais permissiva vence)

A permissão efetiva de um usuário não vem de um lugar só. O módulo combina quatro fontes com lógica OR - para cada flag CRUD, se qualquer camada concede, o usuário tem. Na prática, o resultado de cada flag é um max() entre as camadas:

1. Cargo do usuário - o campo que define o cargo é configurável (Categoria, Título ou Grupo padrão do GLPI), via o parâmetro role_source.
2. Grupos de permissão vinculados ao cargo - conjuntos reutilizáveis de CRUD atribuídos ao cargo.
3. Grupos de permissão vinculados diretamente ao usuário - exceções pontuais sem mexer no cargo.
4. Permissões individuais atribuídas diretamente à conta.

Na aba de consulta, o módulo mostra a permissão efetiva de qualquer usuário com badges indicando de qual camada cada acesso veio (Cargo, Grupo ou Individual) - o que torna a resolução auditável, e não uma caixa-preta.

Diagnóstico direto no banco (SQL)

Numa auditoria, a pergunta mais frequente é "quem pode escrever (criar, atualizar ou excluir) em cada sistema". Dá para responder com um SELECT direto na tabela de permissões por cargo. O exemplo abaixo assume a fonte padrão (usercategories_id, a Categoria do usuário) e lista apenas quem tem alguma flag de escrita:

-- Cargos (Categoria do usuario) com poder de ESCRITA em cada sistema externo
-- Fonte de cargo padrao = usercategories_id
SELECT s.name                                AS sistema,
       COALESCE(m.name, '(sistema inteiro)') AS modulo,
       c.name                                AS cargo,
       p.can_create, p.can_update, p.can_delete
FROM        glpi_plugin_nextool_accessmatrix_perm_categories p
JOIN        glpi_plugin_nextool_accessmatrix_systems s
              ON s.id = p.plugin_nextool_accessmatrix_systems_id
LEFT JOIN   glpi_plugin_nextool_accessmatrix_modules  m
              ON m.id = p.plugin_nextool_accessmatrix_modules_id
JOIN        glpi_usercategories c
              ON c.id = p.usercategories_id
WHERE       p.can_create = 1 OR p.can_update = 1 OR p.can_delete = 1
ORDER  BY   s.name, cargo;

Esse SELECT é somente-leitura e cobre a camada de cargo (a base). A permissão efetiva final - somando grupos e ajustes individuais com o OR das 4 camadas - é resolvida pelo módulo em PHP; use a aba de consulta para o valor consolidado por usuário. O SQL serve para varreduras rápidas de auditoria antes de aprofundar.

Migração entre ambientes: Import/Export CSV

Configurar a matriz em homologação e promover para produção sem refazer tudo na mão é feito por Import/Export CSV. O export gera um arquivo único com sistemas, módulos e permissões, no formato:

type,system_name,module_name,comment,is_active,role_source,role_id,can_create,can_read,can_update,can_delete
system,ERP Protheus,,Gestao financeira,1,,0,0,0,0,0
module,ERP Protheus,Contas a Pagar,,1,,0,0,0,0,0
permission,ERP Protheus,Contas a Pagar,,0,usercategories_id,5,1,1,1,0
permission,ERP Protheus,,,0,groups_id,12,0,1,0,0

A coluna type distingue linhas de sistema, módulo e permissão; nas linhas de permissão, role_source diz de qual camada aquela regra vem. Antes de aplicar, o módulo mostra um preview das mudanças e grava um backup automático (snapshot JSON) do estado anterior, para reverter caso algo saia diferente do esperado.

Integração com o chamado

Uma aba dedicada aparece no formulário de cada ticket, já pré-selecionando o requerente e exibindo suas permissões efetivas. Na prática, quando abre um chamado do tipo "libere fulano no módulo X do ERP", o técnico vê na hora o que aquele usuário já tem em cada sistema - sem sair do chamado, sem abrir outra tela, sem depender da tal planilha.

Armadilhas de campo (o erro comum é...)

Três detalhes só aparecem depois que a matriz está em uso, e valem por experiência direta de operação:

• OR nunca revoga. O erro comum é tentar "tirar" um acesso desmarcando as flags na camada individual do usuário, enquanto um grupo de permissão continua concedendo aquele CRUD. Como a resolução é OR (a mais permissiva vence), a permissão continua valendo. Não existe "negar" que sobrepõe um "conceder" de outra camada: para remover de verdade, tire da camada que concede.
• Usuário sem cargo preenchido não herda a matriz de cargo. Se você configurou a fonte como Categoria mas a conta do usuário está com a Categoria em branco, a camada 1 simplesmente não se aplica - só valem os grupos do usuário e as permissões individuais. O módulo avisa isso na consulta, mas o sintoma no dia a dia é "configurei o cargo e o usuário continua sem acesso". Confira o campo de cargo no cadastro antes de suspeitar do módulo.
• Trocar a fonte de cargo não apaga o que você configurou. Se você migrar o role_source de Categoria para Título, as permissões salvas por Categoria não somem - ficam dormentes no banco e param de ser exibidas enquanto o modo não for o delas. Voltar a fonte antiga traz tudo de volta. É seguro experimentar, mas saiba que "sumiu tudo" ao trocar a fonte quase sempre é isso, não perda de dados.

Modelar a matriz uma vez é a parte fácil; mantê-la coerente com desligamentos, trocas de função e auditorias recorrentes é trabalho de sustentação. É o que a NexTool faz: conheça o Access Matrix ou fale com a sustentação de GLPI da NexTool para estruturar o controle de acessos a sistemas externos com governança e trilha de auditoria.

Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.