NexTool Solutions

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

O problema real: a folha de cálculo em que ninguém confia

Na sustentação de ambientes de clientes, o pedido que expõe a fragilidade do controlo por folha de cálculo é sempre o mesmo. Chega uma auditoria (ISO 27001, SOX, ou um relatório de acesso para a proteção de dados) e o pedido é granular: "liste todos os cargos que podem criar e eliminar registos no sistema financeiro". Uma folha de "tem acesso / não tem acesso" não responde a isso. Não separa leitura de escrita, não tem histórico de quem alterou o que, e já está desatualizada porque a última saída nunca foi refletida. O Access Matrix ataca exatamente essa lacuna: 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 indicadores

A estrutura é deliberadamente simples. Regista os sistemas externos (ERP, CRM, BI, portais de terceiros) e, dentro de cada um, os módulos relevantes (por exemplo "Contas a Pagar", "Faturação", "Relatórios"). Para cada combinação de cargo e módulo, marca quatro caixas: Criar, Ler, Atualizar, Eliminar. Uma permissão pode ser definida ao nível do sistema inteiro ou por módulo específico. Na base de dados, isto torna-se as colunas can_create, can_read, can_update, can_delete (tinyint 0/1), com o módulo a NULL quando a regra se aplica ao sistema todo.

Um esclarecimento honesto e importante: o Access Matrix não é um proxy que bloqueia o início de sessão no ERP. Não interceta o sistema externo. É a matriz de decisão autoritativa - a fonte de verdade que documenta, resolve e apresenta quem deve ter cada permissão, para que a equipa que aprovisiona o acesso (ou o auditor que o revê) trabalhe sobre um dado fiável dentro do GLPI e não sobre uma folha solta.

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

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

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

No separador de consulta, o módulo mostra a permissão efetiva de qualquer utilizador com badges a indicar de que camada veio cada acesso (Cargo, Grupo ou Individual) - o que torna a resolução auditável, e não uma caixa negra.

Diagnóstico direto na base de dados (SQL)

Numa auditoria, a pergunta mais frequente é "quem pode escrever (criar, atualizar ou eliminar) em cada sistema". Dá para responder com um SELECT direto na tabela de permissões por cargo. O exemplo assume a fonte predefinida (usercategories_id, a Categoria do utilizador) e lista apenas quem tem algum indicador de escrita:

-- Cargos (Categoria do utilizador) com poder de ESCRITA em cada sistema externo
-- Fonte de cargo predefinida = 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;

Este SELECT é apenas de leitura e cobre a camada de cargo (a base). A permissão efetiva final - somando grupos de permissões e ajustes individuais com o OR das 4 camadas - é resolvida pelo módulo em PHP; use o separador de consulta para o valor consolidado por utilizador. O SQL serve para varredduras rápidas de auditoria e para conferir a base antes de aprofundar.

Migração entre ambientes: Importação/Exportação CSV

Configurar a matriz em pré-produção e promover para produção sem refazer tudo à mão é feito por Importação/Exportação CSV. A exportação gera um ficheiro ú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 que camada vem aquela regra. Antes de aplicar, o módulo mostra uma pré-visualização das alterações e grava uma cópia de segurança automática (snapshot JSON) do estado anterior, para reverter caso algo saia diferente do esperado.

Integração com o pedido

Um separador dedicado aparece no formulário de cada ticket, já a pré-selecionar o requerente e a apresentar as suas permissões efetivas. Na prática, quando entra um pedido do tipo "dê acesso ao fulano no módulo X do ERP", o técnico vê de imediato o que aquele utilizador já tem em cada sistema - sem sair do pedido, sem abrir outro ecrã, sem depender da tal folha de cálculo.

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

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

• O OR nunca revoga. O erro comum é tentar "retirar" um acesso desmarcando os indicadores na camada individual do utilizador enquanto um grupo de permissões continua a conceder aquele CRUD. Como a resolução é OR (vence a mais permissiva), a permissão continua válida. Não existe "negar" que se sobreponha a um "conceder" de outra camada: para remover a sério, retire da camada que concede.
• Utilizador sem cargo preenchido não herda a matriz de cargo. Se configurou a fonte como Categoria mas a conta do utilizador está com a Categoria em branco, a camada 1 simplesmente não se aplica - só contam os grupos do utilizador e as permissões individuais. O módulo avisa disto na consulta, mas o sintoma no dia a dia é "configurei o cargo e o utilizador continua sem acesso". Confira o campo de cargo no registo antes de suspeitar do módulo.
• Trocar a fonte de cargo não apaga o que configurou. Se migrar o role_source de Categoria para Título, as permissões gravadas por Categoria não desaparecem - ficam dormentes na base de dados e deixam de ser apresentadas enquanto o modo não for o delas. Voltar à fonte antiga traz tudo de volta. É seguro experimentar, mas saiba que "desapareceu tudo" ao trocar a fonte quase sempre é isto, não perda de dados.

Modelar a matriz uma vez é a parte fácil; mantê-la coerente com saídas, mudanças 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 controlo de acessos a sistemas externos com governança e trilho de auditoria.

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