Права доступа и группы в Битрикс: настройка без ошибок

Неправильная группа в 1С-Битрикс может дать контент-менеджеру доступ к настройкам сайта, а редактору каталога — возможность удалить чужие элементы. Ниже — рабочая схема для 1С-Битрикс: Управление сайтом 24.x–25.x: за 30–60 минут вы создадите отдельную роль, ограничите её разделами и проверите результат под тестовой учётной записью.

Что нужно подготовить до настройки

Инструкция рассчитана на административную панель 1С-Битрикс: Управление сайтом 24.x–25.x. В разных редакциях и после обновлений названия отдельных пунктов могут отличаться, но логика прав остаётся той же.

• Учётную запись с правами администратора или доступом к управлению пользователями и инфоблоками.
• Понимание, что именно должен делать сотрудник: редактировать новости, добавлять товары, менять цены или только просматривать заказы.
• Отдельную тестовую учётную запись, которая не входит в группу администраторов.
• Список инфоблоков, разделов и модулей, к которым сотруднику действительно нужен доступ.

Не настраивайте права на реальном пользователе. Сначала создайте роль и проверьте её на тестовом аккаунте, иначе ошибку можно заметить только после изменения или удаления данных.

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

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

Настройка прав по шагам

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

   Проверка: в описании роли есть действие, объект и граница доступа: что менять, где менять и чего нельзя касаться.

2. Создайте отдельную группу. В административной панели откройте раздел управления пользователями и перейдите к группам. Добавьте новую группу с понятным названием, например «Редакторы новостей» или «Менеджеры каталога». Не включайте её в административные группы и не копируйте права администратора «для удобства».

   Проверка: новая группа отображается в списке, а в её настройках нет лишних групп-наследников и признаков административного доступа.

3. Добавьте тестового пользователя. Откройте карточку тестовой учётной записи и назначьте ей только созданную группу. Если аккаунт уже состоит в группах «Зарегистрированные пользователи», «Контент-менеджеры» или других ролях, временно уберите лишние членства: иначе вы будете проверять не одну роль, а их комбинацию.

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

4. Выдайте доступ к нужному модулю. Права на модуль и права на конкретные данные — разные уровни. Для редактора новостей обычно нужен доступ к управлению соответствующим инфоблоком, но не к настройкам пользователей, рекламы, резервного копирования и конфигурации сайта. Оставляйте минимальный уровень, при котором сотрудник может выполнить задачу.

   Проверка: после входа тестового пользователя в меню видны только необходимые разделы, а попытка открыть лишний административный раздел заканчивается отказом в доступе.

5. Настройте права инфоблока. Откройте настройки нужного инфоблока и найдите блок, связанный с правами доступа. Назначьте группе только необходимый уровень: просмотр, добавление элементов, изменение элементов или полный доступ к этому инфоблоку. Полный доступ к инфоблоку не означает полный доступ ко всему сайту, но для роли редактора он обычно избыточен.

   Проверка: тестовый пользователь может открыть нужный инфоблок и выполнить разрешённое действие, например создать черновик новости, но не может изменить настройки самого инфоблока.

6. Ограничьте разделы, если данные разделены по структуре. Если один инфоблок содержит новости, пресс-релизы и внутренние материалы, не выдавайте группе доступ ко всему инфоблоку автоматически. Настройте права на нужные разделы или вынесите материалы в отдельный инфоблок, если разделение прав становится слишком сложным.

   Проверка: тестовая учётная запись видит разрешённый раздел, а при попытке открыть закрытый раздел получает отказ или не видит его в рабочем интерфейсе.

7. Проверьте публичную часть сайта. Административное право редактировать элемент не гарантирует, что сотрудник увидит нужную кнопку в публичной части. Это зависит от настроек компонента, режима правки и авторизации. Проверьте сценарий, которым сотрудник будет пользоваться каждый день: открыть список, найти элемент, изменить его, сохранить и отменить изменение.

   Проверка: разрешённый сценарий проходит от начала до конца, а кнопки и ссылки на недоступные действия не появляются.

8. Проверьте запреты прямым URL. Скрытое меню не является защитой. Войдите тестовой учётной записью и откройте несколько административных страниц, к которым доступ не нужен. Такой тест выявляет ситуацию, когда пункт меню исчез, но разрешение осталось.

   Проверка: при открытии запрещённого раздела Битрикс не показывает настройки и данные, доступ к которым не предусмотрен ролью.

9. Зафиксируйте результат. Запишите название группы, назначенные модули, инфоблоки и границы разделов. Отдельно укажите владельца роли — человека, который будет отвечать за её пересмотр после изменения структуры сайта.

   Проверка: другой администратор может понять назначение группы без устного объяснения.

Как не перепутать уровни доступа

В Битрикс права встречаются на нескольких уровнях, и ошибки чаще всего возникают из-за смешения этих настроек.

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

Что ломается чаще всего

Пользователь видит больше, чем должен

Проверьте все группы, в которые он входит. Дополнительное членство может дать более широкие права, чем созданная вами роль. Частая причина — оставшаяся группа с полным доступом к контенту.

Пользователь не видит нужный инфоблок

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

Пункт меню скрыт, но страница открывается

Меню и разрешения — не одно и то же. Скрытие ссылки не запрещает доступ само по себе. Откройте страницу прямым адресом под тестовой учётной записью и исправьте права на модуль или объект.

После обновления изменилось поведение

Сверьте права группы, настройки инфоблока и работу компонентов после обновления ядра и модулей. Перед обновлением сохраните описание текущей схемы и проверьте ключевые роли на копии сайта или тестовом контуре.

Один сотрудник должен видеть несколько разных областей

Не создавайте для него группу с максимальными правами. Если роли действительно независимы, назначьте несколько узких групп, например «Редактор новостей» и «Менеджер каталога», а затем проверьте итоговый доступ как одну комбинацию.

Где схема с группами перестаёт быть удобной

Группы хорошо подходят для устойчивых ролей: редактор, менеджер каталога, оператор заказов. Они начинают мешать, когда права зависят от десятков исключений, конкретного автора, филиала или временного проекта.

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

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

Что сделать после настройки

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

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

Официальная документация по управлению пользователями и правами может отличаться по редакции продукта, поэтому перед изменением рабочей системы сверяйте названия пунктов панели с документацией для вашей версии.

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