Права доступа в Битрикс: как не раздавать админа всем

Контент-менеджеру нужно править новости, и самый короткий путь — добавить его в группу «Администраторы». Через месяц он случайно удаляет раздел каталога, а через полгода уходит из компании, оставив активную учётную запись с полным доступом к /bitrix/admin. Группа с ID 1 получает доступ ко всему, поэтому последствия такой «экономии» настройкой потом не исправить. Их нужно не допускать.

Из чего складываются права

Материал написан для «1С-Битрикс: Управление сайтом» 23.x–24.x. В других версиях названия пунктов меню могут отличаться, поэтому сначала проверяйте всё на тестовой копии.

Битрикс проверяет доступ на четырёх уровнях, и закрыть дверь на одном из них мало:

• группы пользователей: право получает группа, а не человек. Две служебные: «Администраторы» (ID 1) и «Все пользователи» (ID 2, в неё попадают и гости);
• модули: у main, iblock, sale, catalog и других свой уровень доступа для каждой группы;
• файлы и папки публичной части: настраиваются в «Структуре сайта»;
• инфоблоки: право на инфоблок целиком или, в расширенном режиме, на отдельные разделы и элементы.

Сноска. Операция — одно элементарное действие, например «просмотр» или «редактирование». Задача (task) — набор операций. Когда вы назначаете группе уровень доступа к модулю, вы выбираете именно задачу. В административном разделе есть список задач, где при необходимости можно собрать свою, если штатных уровней мало.

Группа «Администраторы» — не уровень доступа, а отмена проверок. Выдавать её стоит так же осторожно, как пароль от сервера.

Подходы и их цена

Схема на ролях

Строить права нужно от ролей, а не от людей. Человек приходит и уходит, а роль «менеджер заказов» остаётся.

1. Составьте список ролей: контент-менеджер, менеджер заказов, SEO-специалист, внешний подрядчик. Проверка: каждую роль можно описать одной фразой, и ни одна не звучит как «делает всё».
2. Создайте группу на каждую роль и заполните у неё символьный идентификатор. Он пригодится в коде вместо номера группы. Проверка: в списке групп у каждой роли есть понятный идентификатор.
3. В настройках каждого модуля, на вкладке прав доступа, начните с минимального уровня и повышайте его только при реальной необходимости. Проверка: у роли нет доступа к модулям, которыми она не пользуется.
4. В настройках каждого инфоблока откройте вкладку доступа и задайте уровень для каждой группы. Проверка: группа «Все пользователи» не получила лишнего.
5. В «Структуре сайта» через контекстное меню папки откройте права доступа и закройте служебные разделы публичной части. Проверка: гость на закрытой странице видит форму авторизации или отказ.
6. Создайте тестового пользователя, добавьте его только в одну группу и зайдите под ним в отдельном профиле браузера. Пройдите рабочий сценарий роли. Проверка: нужное делается, лишнее даёт отказ.

Простой или расширенный режим инфоблока

В простом режиме группе назначается одна буква на весь инфоблок: от «доступ закрыт» (D) через «чтение» (R) и «запись» (W) до «полного доступа» (X). Расширенный режим включается на вкладке доступа и позволяет раздавать права по разделам и элементам. Переключайтесь сначала на копии сайта и после смены режима проверьте, что права остались прежними.

Права в Битриксе складываются: пользователь получает максимум из прав всех своих групп. Отобрать то, что уже дано группе «Все пользователи», у отдельной группы нельзя. Если чтение инфоблока открыто всем, закрыть его для одной роли не получится.

Проверка прав в своём коде

Если вы пишете компонент или обработчик, привязка к номеру группы — типичная мина. На другом сайте или после переноса базы под этим номером окажется другая группа. Спрашивайте у ядра, а не угадывайте. Ниже схема для классического API «Управления сайтом» 23.x–24.x.

<?php
use Bitrix\Main\Loader;

if (!defined('B_PROLOG_INCLUDED') || B_PROLOG_INCLUDED !== true) {
    die();
}

Loader::includeModule('iblock');

global $USER;

// Плохо: номер группы 7 на другом сайте окажется другой группой
// if (in_array(7, $USER->GetUserGroupArray())) { $canEdit = true; }

// Лучше: спрашиваем ядро о праве на конкретный инфоблок
$newsIblockId = 5; // подставьте ID своего инфоблока

// Буквы уровней идут по возрастанию прав: D, R, U, W, X
if (!$USER->IsAuthorized() || CIBlock::GetPermission($newsIblockId) < 'W') {
    ShowError('Недостаточно прав для редактирования новостей');
    return;
}

Сигнатуру CIBlock::GetPermission и набор возвращаемых букв сверьте с документацией вашей версии модуля iblock. Для администратора метод вернёт максимальный уровень, это нормально.

Что ломается

• Закрыли в одной группе, а у пользователя есть вторая, где открыто. Права складываются, побеждает максимум. Смотрите все группы пользователя, а не только основную.
• Кеш компонента. У стандартных компонентов есть параметр «Учитывать права доступа» (CACHE_GROUPS). Если отключить его при включённом кешировании, закрытые данные могут попасть в общий кеш и показаться гостям.
• Новый инфоблок. После создания откройте его вкладку доступа и проверьте каждую группу. Не рассчитывайте, что настройки подтянутся из соседнего.
• Права по номеру группы в шаблонах и обработчиках. При переносе на другой сайт всё поедет. Используйте символьный идентификатор или проверку права.
• Ушедший сотрудник. Учётная запись остаётся активной, пока вы её не отключите. Добавьте отключение в чек-лист увольнения.
• Закрытая папка вместо закрытых данных. Страница недоступна, но тот же список элементов выводится на другой открытой странице.

Когда что выбирать

• Роли различаются только на уровне «весь инфоблок» или «весь модуль»: простой режим и права на модули. Этого хватает большинству сайтов.
• Один инфоблок, а разные группы должны видеть разные разделы (филиалы, регионы): расширенный режим. Если таких границ много и они меняются каждую неделю, разнесите данные по отдельным инфоблокам.
• Нужен закрытый раздел с готовыми страницами: права на папку.
• Группа «Администраторы»: только технический специалист, и лучше с отдельной учётной записью для повседневной работы.

Двухэтапная аутентификация и ограничение входа в админку по IP — отдельные темы. Здесь мы их не разбираем.

Что делать дальше

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