NexTool Solutions

В GLPI право — это не выключатель «вкл/выкл»: это произведение трёх осей, которые перемножаются, — профиля, организации и интерфейса. Ошибка в этой комбинации — причина номер один заявок о «пропавшем доступе» и утечек видимости между подразделениями. В этом руководстве показаны реальная модель, место хранения прав в базе данных и ловушки, которые проявляются только в среде с несколькими организациями.

Модель RBAC по трём осям

Управление доступом в GLPI (RBAC, Role-Based Access Control) сочетает три независимых измерения, которые многие воспринимают как одно целое:

• Профиль — набор прав, то есть что человек может делать (создавать, редактировать, удалять, настраивать).
• Организация — область данных, то есть где он видит: какую организацию, филиал или отдел.
• Интерфейс — как он работает: Helpdesk (упрощённый, для конечного пользователя) или Central (полный, для операционной работы).

Путаница возникает потому, что эти три оси комбинируются через назначение, а не через автоматическое наследование. Таблица glpi_profiles_users связывает пользователя с профилем внутри организации, а флаг is_recursive определяет, распространяется ли доступ на дочерние организации. Поэтому один и тот же пользователь может быть специалистом в организации «ИТ» и Self-Service в организации «HR»: это две отдельные строки в этой таблице, у каждой своя область.

Матрица профилей, которую мы используем как базовую

Вместо того чтобы настраивать семь заводских профилей GLPI, мы начинаем с компактной матрицы и клонируем профили из неё. Меньше профилей с чёткими границами порождают меньше инцидентов, чем десять почти одинаковых профилей, различие между которыми никто не помнит.

Практическое правило: если два профиля отличаются одним-единственным правом, скорее всего, это должен быть один профиль. Разрастание числа профилей — технический долг в безопасности: каждый лишний профиль — ещё один объект для аудита.

Где на самом деле хранятся права

Экран профилей (Администрирование > Профили) — лишь оболочка над таблицей glpi_profilerights. Каждая строка хранит пару (профиль, объект) и столбец rights, который является целочисленной битовой маской. Понимание этого меняет подход к аудиту: вместо того чтобы прокликивать десятки вкладок, вы читаете право прямо из базы.

-- Rights of a profile over key objects (the bitmask is an integer)
SELECT p.name    AS profile,
       pr.name   AS object,
       pr.rights AS bitmask
FROM   glpi_profilerights pr
JOIN   glpi_profiles p ON p.id = pr.profiles_id
WHERE  p.name = 'Technician'   -- match the name in your install language
  AND  pr.name IN ('ticket', 'computer', 'config', 'user', 'entity')
ORDER  BY pr.name;

-- Decoding the base bits (valid for most itemtypes):
--   READ = 1, UPDATE = 2, CREATE = 4, DELETE = 8, PURGE = 32
-- E.g.: bitmask 15 = READ+UPDATE+CREATE+DELETE (CRUD, no purge)

Базовые биты действуют для большинства типов объектов, но такие объекты, как заявка (ticket), упаковывают в то же целое число дополнительные флаги: видимость «мои / моей группы / все», назначение, перехват, изменение приоритета. Не пытайтесь угадывать эти биты по памяти — сверяйтесь с интерфейсом и проверяйте тестовой сессией, прежде чем считать что-то верным.

Быстрая диагностика: у кого что есть

Прежде чем трогать какой-либо профиль, зафиксируйте текущее состояние. Этот запрос отвечает на вопрос «у кого какой профиль, в какой организации и распространяется ли он на дочерние» — именно такой картины чаще всего не хватает при аудите доступа:

-- Who has which profile, in which entity, with or without recursion
SELECT u.name          AS user,
       p.name          AS profile,
       p.interface     AS interface,
       e.completename  AS entity,
       pu.is_recursive AS cascades_to_subentities
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 = 'john.doe'
ORDER  BY e.completename;

Регулярный запуск — как минимум ежемесячно — дешёвый способ выявить накопление привилегий: бывшие участники группы, которые остаются супервизорами, или административный профиль, выданный «просто для теста», который никто не убрал. При серьёзном сопровождении этот SELECT становится плановым отчётом, а не ручными поисками, когда проблема уже случилась.

Практические ловушки

При сопровождении клиентских сред с несколькими организациями повторяющаяся заявка «у меня пропало право» почти никогда не является ошибкой: это кэш сессии. GLPI загружает права профиля в $_SESSION в момент входа. Если вы меняете битовую маску, пока специалист в системе, у него остаются старые права, пока он не сменит организацию в селекторе или не войдёт заново. Мы приучились включать «попросите выйти и войти снова» в сам сценарий проверки и всегда тестировать в новой или анонимной сессии — иначе вы клянётесь, что всё настроили правильно, а пользователь клянётся, что не работает, и оба одновременно правы.

Остальные ловушки, чаще всего приводящие к инцидентам:

• Видимость «Все» для специалиста — право «видеть все заявки» позволяет специалисту видеть заявки всех организаций, к которым у него есть доступ, а не только своей. У клиента с чувствительными подразделениями (HR, юристы) это тихая утечка. Предпочитайте «моей группы».
• Забытый is_recursive — если назначить профиль в корневой организации без отметки рекурсии, пользователь не увидит ни одной дочерней организации. Классический симптом — «я вхожу, но ничего не вижу». Обратная ситуация, лишняя рекурсия, даёт слишком широкий доступ, и никто этого не замечает.
• Права Central в профиле Helpdesk — интерфейс Helpdesk игнорирует большинство прав Central. Отметка прав на активы в профиле helpdesk ничего не даёт: в этом интерфейсе такого меню просто нет.
• Правила назначения не по порядку — те, кто использует LDAP или SSO, назначают профили через Правила назначения полномочий (RuleRight). Общее правило «назначить Self-Service» должно стоять последним; если оно наверху без «прекратить обработку», оно побеждает все конкретные правила, и все получают Self-Service.
• Не тестировать от лица Self-Service — многие дефекты проявляются только в интерфейсе Helpdesk. Держите тестового пользователя для каждого профиля и проходите реальный сценарий, прежде чем выпускать в продуктив.

Чек-лист усиления профилей

1. Начинайте с минимальной матрицы; клонируйте профили вместо редактирования заводских.
2. По умолчанию задавайте видимость заявок «моей группы»; «Все» — только с письменным обоснованием.
3. Проверяйте флаг is_recursive в каждом назначении организации.
4. Запускайте диагностический SQL ежемесячно и убирайте накопленные привилегии.
5. Держите тестового пользователя для каждого профиля и проверяйте в новой сессии после любого изменения.
6. Ограничьте круг тех, кто редактирует профили и правила: право UPDATE на profile и rule на практике равно праву администратора.

Нужно управлять доступом к экранам и внешним системам прямо в GLPI, с проверяемой матрицей? Познакомьтесь с модулем Access Matrix. А если вы предпочитаете отдать проектирование и сопровождение профилей на аутсорс, NexTool внедряет и поддерживает среды GLPI с несколькими организациями с регулярным пересмотром управления доступом.

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