Типичная ситуация: конфликт прав в Битрикс
Часто к нам приходят с жалобой: менеджер случайно удалил товар, а редактор не видит свои разделы. В 1С-Битрикс права доступа — мощный, но сложный инструмент. Без системного проектирования ролевой модели доступа 1С-Битрикс роли назначаются хаотично, возникают конфликты: пользователь входит в несколько групп с разными привилегиями, и отладка занимает полдня. Мы проектируем ролевую модель доступа под бизнес-задачи: от анализа процессов до настройки каждого модуля. Это исключает ручное переопределение прав и снижает риск инцидентов. За время работы мы выполнили более 50 проектов по разграничению доступа, типичный проект сокращает количество групп в 3 раза — с 15-20 до 5-7. При этом матрица прав становится прозрачной для заказчика и разработчика. Проектирование ролевой модели доступа в 3 раза эффективнее хаотичного назначения прав — меньше конфликтов и простоев.
Как устроена система прав в 1С-Битрикс?
Платформа работает с тремя уровнями доступа:
- Группы пользователей — базовая единица. Права назначаются группе, а не конкретному пользователю. Пользователь может состоять в нескольких группах; финальные права вычисляются по максимуму среди всех групп.
- Права на модули — каждый модуль (iblock, catalog, sale, crm, im и т.д.) имеет собственный реестр прав. Например, модуль iblock знает про права iblock_read, iblock_edit, iblock_admin. Это не глобальные константы — каждый модуль определяет свои.
- Права на объекты — инфоблоки, разделы, элементы могут иметь точечные ограничения через
CIBlock::SetPermission()или через интерфейс «Настройка доступа».
Как отмечено в [документации 1С-Битрикс](https://dev?
1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=234), каждый модуль определяет собственные константы прав. В D7-компонентах и REST API работает отдельный механизм — Bitrix\Main\Access, основанный на правилах (AccessRule), провайдерах (AccessProvider) и субъектах (AccessSubject). Если проект активно использует D7, права нужно проектировать с учётом этого слоя.
Почему важно проектировать ролевую модель?
Без проектирования права настраиваются «на коленке»: дали группе полный доступ на модуль «временно», а через месяц она остаётся. В результате один пользователь может нечаянно изменить цену или удалить товар. Ручное назначение занимает 2-3 дня, но порождает 5-10 конфликтов. Проектирование с матрицей занимает 3-7 дней, но даёт прозрачную систему без сюрпризов.
Как проходит процесс проектирования?
Работа начинается не с Битрикса, а с анализа бизнес-процессов заказчика. Нужно понять: кто создаёт контент, кто модерирует, кто публикует, кто только смотрит, кто администрирует технически. Это пять типов акторов.
На практике разработка ролевой модели проходит через этапы:
- Аудит существующих групп. На живых проектах часто обнаруживаются 15–20 групп, половина из которых — устаревшие. Начинаем с инвентаризации:
b_group,b_user_group. - Матрица доступа. Составляем таблицу «роль × ресурс».
- Маппинг на группы Битрикса. Определяем, нужно ли отображение 1:1 или одна бизнес-роль покрывается несколькими техническими группами.
- Настройка прав на инфоблоки. Для крупных каталогов права задаются отдельно на чтение, запись, полный доступ и наследуются через
CIBlockSection. - Тестирование прав. Создаём тестовых пользователей и проверяем граничные сценарии.
| Роль | Каталог (catalog) | Заказы (sale) | Инфоблоки (iblock) | Администрирование |
|---|---|---|---|---|
| Контент-менеджер | catalog_read | нет | iblock_edit (товары) | нет |
| Менеджер продаж | catalog_read | sale_edit | нет | нет |
| Технический администратор | catalog_admin | sale_admin | iblock_admin | full |
Кейс из нашей практики: разграничение доступа в B2B-магазине
Наш клиент — оптовый интернет-магазин с ролями: оператор склада, менеджер продаж, региональный руководитель, контент-менеджер, технический администратор. Итого 5 ролей, 3 инфоблока (товары, новости, баннеры), модули catalog, sale, iblock.
Проблема при первоначальной настройке: менеджеры по продажам случайно получили право редактировать цены — через группу «Сотрудники», которой дали catalog_admin временно и забыли убрать. Обнаружили через три недели, когда один менеджер изменил цену на позицию с высоким оборотом.
Решение: пересобрали группы с нуля, применив принцип минимально необходимых прав (RBAC). Для каталога разделили права: catalog_read — склад, iblock_edit только на инфоблок товаров — контент-менеджер, полный catalog_admin — только технический администратор. Права на инфоблоки назначили явно через CIBlock::SetPermission(), убрав наследование от общих настроек модуля.
Результат: 5 групп вместо 17, задокументированная матрица доступа, которую понимает не только разработчик, но и технический директор заказчика. Проектирование сократило время настройки прав в 3 раза по сравнению с ручным методом.
Особенности Enterprise-проектов
На проектах с редакцией «Энтерпрайз» (множество сайтов под одной лицензией) добавляется измерение сайтов: пользователь может быть администратором одного сайта, но не иметь доступа к другому. Это управляется через b_user_site и требует отдельного проектирования — матрица становится трёхмерной: роль × ресурс × сайт.
Для REST API и интеграций проектируется отдельный слой: webhook-пользователи и приложения получают только скоупы, необходимые для конкретной интеграции. Давать интеграции права администратора — типичная ошибка, которая обнаруживается только при инциденте безопасности.
Что входит в работу и сроки
| Этап | Длительность (типовой проект) | Результат |
|---|---|---|
| Анализ бизнес-процессов | 1 день | Список акторов и их потребностей |
| Составление матрицы доступа | 1 день | Таблица «роль × ресурс» |
| Согласование | 1 день | Утверждённая матрица |
| Реализация в Битрикс | 2-3 дня | Настроенные группы и права |
| Тестирование | 1 день | Тест-протокол |
| Документация | 1 день | Матрица, рекомендации |
Проектирование ролевой модели для стандартного набора ролей (5–8) и типовых модулей занимает 3–7 рабочих дней. Сложные Enterprise-проекты с множеством сайтов и нестандартными модулями — 2–4 недели. В результат работы входят: задокументированная матрица доступа, настроенные группы пользователей, тест-протокол проверки прав, рекомендации по поддержке модели при росте команды.
Чек-лист для проверки прав
- Убедитесь, что каждый пользователь состоит только в нужных группах.
- Проверьте, что права на модули не дублируются.
- Протестируйте доступ к ключевым разделам от имени каждой роли.
- Убедитесь, что интеграции (REST, обмен с 1С) имеют минимально необходимые скоупы.
- Задокументируйте матрицу доступа.
Получите консультацию по проектированию ролевой модели. Свяжитесь с нами — мы поможем настроить безопасное и прозрачное разграничение прав. Закажите анализ текущей системы доступа.