Проектирование ролевой модели доступа 1С-Битрикс

Проектирование ролевой модели доступа 1С-Битрикс

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

Как устроена система прав в 1С-Битрикс

Платформа работает с тремя уровнями доступа:

Группы пользователей — базовая единица. Права назначаются группе, а не конкретному пользователю. Пользователь может состоять в нескольких группах; финальные права вычисляются по максимуму среди всех групп.

Права на модули — каждый модуль (iblock, catalog, sale, crm, im и т.д.) имеет собственный реестр прав. Например, модуль iblock знает про права iblock_read, iblock_edit, iblock_admin. Это не глобальные константы — каждый модуль определяет свои.

Права на объекты — инфоблоки, разделы, элементы могут иметь точечные ограничения через CIBlock::SetPermission() или через интерфейс «Настройка доступа» на конкретном инфоблоке.

Кроме этого, в D7-компонентах и REST API работает отдельный механизм — Bitrix\Main\Access, основанный на правилах (AccessRule), провайдерах (AccessProvider) и субъектах (AccessSubject). Если проект активно использует D7, права нужно проектировать уже с учётом этого слоя.

Процесс проектирования

Работа начинается не с Битрикса, а с анализа бизнес-процессов заказчика. Нужно понять: кто создаёт контент, кто модерирует, кто публикует, кто только смотрит, кто администрирует технически. Это пять типов акторов, которые в реальных проектах перемешиваются в самых неожиданных комбинациях.

На практике разработка ролевой модели проходит через следующие этапы:

1. Аудит существующих групп. На живых проектах часто обнаруживаются 15–20 групп, половина из которых — устаревшие эксперименты. Начинаем с инвентаризации: b_group, b_user_group — смотрим, кто куда входит и есть ли вообще логика.

2. Матрица доступа. Составляем таблицу «роль × ресурс». Строки — функциональные роли (контент-менеджер каталога, менеджер заказов, SEO-специалист, технический администратор). Столбцы — модули и объекты. Ячейки — уровень доступа (нет / чтение / редактирование / администрирование).

3. Маппинг на группы Битрикса. Определяем, нужно ли отображение 1:1 или одна бизнес-роль покрывается несколькими техническими группами. Иногда выгоднее сделать «базовую» группу с общими правами и «специализированные» с дополнительными.

4. Настройка прав на инфоблоки. Для крупных каталогов критично: права задаются отдельно на чтение, запись, полный доступ — и могут наследоваться по разделам иерархически через CIBlockSection.

5. Тестирование прав. Создаём тестовых пользователей под каждую роль и вручную проверяем граничные сценарии: может ли менеджер экспортировать прайс, видит ли SEO-специалист вкладку «SEO» в элементах, но не вкладку «Цены».

Кейс: разграничение доступа в оптовом интернет-магазине

Проект — B2B-каталог с ролями: оператор склада, менеджер по продажам, региональный руководитель, контент-менеджер, технический администратор. Итого 5 ролей, 3 инфоблока (товары, новости, баннеры), модули catalog, sale, iblock.

Проблема при первоначальной настройке: менеджеры по продажам случайно получили право редактировать цены — через группу «Сотрудники», которой дали catalog_admin «на время» и забыли убрать. Обнаружили через три недели, когда один менеджер изменил цену на позицию с высоким оборотом.

Решение: пересобрали группы с нуля. Ввели принцип «минимально необходимых прав»: каждая группа получает ровно то, что нужно для работы, и не больше. Для каталога разделили права: catalog_read — склад, iblock_edit только на инфоблок товаров — контент-менеджер, полный catalog_admin — только технический администратор. Права на инфоблоки назначили явно через CIBlock::SetPermission(), убрав наследование от общих настроек модуля.

Результат: 5 групп вместо 17, задокументированная матрица доступа, которую понимает не только разработчик, но и технический директор заказчика.

Особенности Enterprise-проектов

На проектах с редакцией «Энтерпрайз» (множество сайтов под одной лицензией) добавляется измерение сайтов: пользователь может быть администратором одного сайта, но не иметь доступа к другому. Это управляется через b_user_site и требует отдельного проектирования — матрица становится трёхмерной: роль × ресурс × сайт.

Для REST API и интеграций проектируется отдельный слой: webhook-пользователи и приложения получают только скоупы, необходимые для конкретной интеграции. Давать интеграции права администратора — типичная ошибка, которая обнаруживается только при инциденте безопасности.

Сроки и что входит в работу

Проектирование ролевой модели для проекта со стандартным набором ролей (5–8) и типовыми модулями занимает 3–7 рабочих дней: анализ, составление матрицы, согласование, реализация, тестирование и документация. Сложные Enterprise-проекты с множеством сайтов и нестандартными модулями — 2–4 недели.

В результат работы входят: задокументированная матрица доступа, настроенные группы пользователей в системе, тест-протокол проверки прав, рекомендации по поддержке модели при росте команды.