NexTool Solutions

На аудите никто не спрашивает «у кого есть доступ к ERP». Спрашивают «кто может УДАЛИТЬ проводку в ERP» — и таблица доступов редко может на это ответить. Access Matrix переносит эту матрицу решений внутрь GLPI: внешние системы, их модули и четыре CRUD-флага (Создание, Чтение, Изменение, Удаление), разрешаемые по должности, группе и пользователю. В этом руководстве показаны модель разрешения, SQL-диагностика прямо в базе, формат миграции между средами и ловушки, которые проявляются только в продуктиве.

Реальная проблема: таблица, которой никто не доверяет

При сопровождении клиентских сред запрос, обнажающий слабость контроля через таблицу, всегда один и тот же. Приходит аудит (ISO 27001, SOX или отчёт о доступах для LGPD), и запрос детальный: «перечислите все должности, которые могут создавать и удалять записи в финансовой системе». Таблица «есть доступ / нет доступа» на это не отвечает: она не отделяет чтение от записи, не хранит историю того, кто что изменил, и уже устарела, потому что последнее увольнение в ней не отражено. Access Matrix закрывает этот пробел: моделирует доступ с детализацией до CRUD и держит всё внутри GLPI, рядом с остальной работой службы поддержки.

Что моделирует модуль: системы, модули и четыре флага

Структура намеренно проста. Вы заводите внешние системы (ERP, CRM, BI, сторонние порталы) и внутри каждой — значимые модули (например, «Кредиторская задолженность», «Выставление счетов», «Отчёты»). Для каждого сочетания должности и модуля отмечаются четыре флажка: Создание, Чтение, Изменение, Удаление. Право можно задать на уровне всей системы или для конкретного модуля. В базе это превращается в столбцы can_create, can_read, can_update, can_delete (tinyint 0/1), где модуль равен NULL, если правило действует для всей системы.

Честное и важное уточнение: Access Matrix — это не прокси, который блокирует вход в ERP, и он не перехватывает внешнюю систему. Это авторитетная матрица решений — источник истины, который документирует, разрешает и показывает, у кого должно быть каждое право, чтобы команда, предоставляющая доступ (или проверяющий аудитор), работала с надёжными данными внутри GLPI, а не с разрозненной таблицей.

Разрешение в 4 уровня (OR: побеждает самый разрешающий)

Фактическое право пользователя берётся не из одного места. Модуль объединяет четыре источника по логике OR — для каждого CRUD-флага, если его предоставляет любой уровень, пользователь его получает. На практике результат по каждому флагу — это max() по уровням:

1. Должность пользователя — поле, определяющее должность, настраивается (Категория, Должность (Title) или Группа по умолчанию в GLPI) параметром role_source.
2. Группы прав, привязанные к должности — переиспользуемые наборы CRUD, назначенные должности.
3. Группы прав, привязанные напрямую к пользователю — точечные исключения без изменения должности.
4. Индивидуальные права, назначенные непосредственно учётной записи.

На вкладке просмотра модуль показывает фактические права любого пользователя с метками, указывающими, с какого уровня пришёл каждый доступ (Должность, Группа или Индивидуально), — это делает разрешение проверяемым, а не чёрным ящиком.

Диагностика прямо в базе (SQL)

На аудите чаще всего спрашивают «кто может записывать (создавать, изменять или удалять) в каждой системе». Ответить можно прямым SELECT к таблице прав по должностям. Пример ниже предполагает источник по умолчанию (usercategories_id, Категория пользователя) и выводит только тех, у кого есть хотя бы один флаг записи:

-- 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;

Этот SELECT только читает данные и охватывает уровень должности (базовый). Итоговое фактическое право — с учётом групп и индивидуальных настроек по OR четырёх уровней — разрешается модулем на PHP; для консолидированного значения по пользователю используйте вкладку просмотра. SQL нужен для быстрых проверок при аудите перед углублённым анализом.

Миграция между средами: Import/Export CSV

Настроить матрицу в тестовой среде и перенести её в продуктив без ручной переделки позволяет Import/Export CSV. Экспорт создаёт единый файл с системами, модулями и правами в формате:

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

Столбец type различает строки системы, модуля и права; в строках прав role_source указывает, с какого уровня приходит это правило. Перед применением модуль показывает предпросмотр изменений и записывает автоматическую резервную копию (JSON-снимок) предыдущего состояния, чтобы откатиться, если что-то пойдёт не так, как ожидалось.

Интеграция с заявкой

В форме каждой заявки появляется отдельная вкладка, где уже выбран инициатор и показаны его фактические права. На практике, когда приходит заявка вида «предоставьте такому-то доступ к модулю X в ERP», специалист сразу видит, что у этого пользователя уже есть в каждой системе, — не выходя из заявки, не открывая другой экран и не завися от той самой таблицы.

Практические ловушки (типичная ошибка — ...)

Три детали проявляются только после того, как матрица начала использоваться, и основаны на прямом опыте эксплуатации:

• OR никогда не отзывает. Типичная ошибка — пытаться «забрать» доступ, снимая флаги на индивидуальном уровне пользователя, тогда как группа прав продолжает предоставлять этот CRUD. Поскольку разрешение идёт по OR (побеждает самый разрешающий), право продолжает действовать. Не существует «запрета», который перекрывал бы «разрешение» с другого уровня: чтобы действительно убрать доступ, уберите его с того уровня, который его предоставляет.
• Пользователь без заполненной должности не наследует матрицу должности. Если вы настроили источник как Категорию, а у учётной записи пользователя Категория пуста, уровень 1 просто не применяется — действуют только группы пользователя и индивидуальные права. Модуль предупреждает об этом при просмотре, но в повседневной работе симптом звучит как «я настроил должность, а у пользователя по-прежнему нет доступа». Проверьте поле должности в карточке, прежде чем подозревать модуль.
• Смена источника должности не удаляет то, что вы настроили. Если перевести role_source с Категории на Должность (Title), права, сохранённые по Категории, не исчезают — они остаются в базе в спящем состоянии и не отображаются, пока не включён их режим. Возврат к прежнему источнику возвращает всё обратно. Экспериментировать безопасно, но знайте: «всё пропало» при смене источника почти всегда означает именно это, а не потерю данных.

Один раз смоделировать матрицу — простая часть; поддерживать её в согласии с увольнениями, сменами должностей и регулярными аудитами — это работа сопровождения. Именно этим занимается NexTool: познакомьтесь с Access Matrix или обратитесь в службу сопровождения GLPI от NexTool, чтобы выстроить контроль доступа к внешним системам с управлением и журналом аудита.

Проверено командой NexTool Solutions.