Права доступа в Битрикс: как настроить роли и группы сотрудников

Права доступа в Битрикс - не чекбокс, который выставил один раз при запуске и забыл. У меня было несколько проектов, где спустя год-два после старта в системе накапливалось по 15-20 групп пользователей с пересекающимися правами, и в компании уже никто не мог объяснить, кто и почему может менять цены в каталоге или удалять чужие заказы. Разберу, как настроить права доступа в Битрикс так, чтобы структура групп и ролей оставалась понятной и через два года после запуска.

Зачем вообще разграничивать доступ, а не выдавать всем админку

Соблазн простой: на старте проекта в компании три человека, все всё делают, и проще дать каждому полный доступ. Через полгода команда вырастает до десяти, кто-то из менеджеров случайно меняет структуру каталога, кто-то удаляет инфоблок с отзывами, думая, что это тестовые данные. Я разбирал такие инциденты минимум в трёх проектах на WordPress и Битрикс - восстановление удалённого раздела каталога через бэкап отнимает от двух часов до целого дня, если бэкапы вообще настроены на нужную глубину.

Вторая причина - 152-ФЗ и внутренние регламенты. Если в базе хранятся персональные данные клиентов (ФИО, телефоны, адреса доставки через СДЭК), доступ к этим данным должен быть у ограниченного круга сотрудников, а не у всех, кто залогинен в админку. При аудите информационной безопасности первым делом смотрят именно на матрицу прав - кто может выгрузить базу клиентов целиком.

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

Группы пользователей и роли: в чём разница на практике

В классическом ядре 1С-Битрикс: Управление сайтом нет отдельной сущности «роль», как в Bitrix24 с его ролевой моделью для CRM. Здесь всё строится вокруг групп пользователей (Пользователи → Группы пользователей), и роль - это по сути комбинация прав, которую я собираю через одну или несколько групп.

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

Стандартные группы, которые есть «из коробки»

В любой установке Битрикс уже есть три системные группы: «Все пользователи (в том числе неавторизованные)», «Авторизованные пользователи» и «Администраторы». Их лучше не трогать под конкретные задачи бизнеса - я завожу отдельные группы под каждую роль, а системные оставляю для базовой логики движка (например, для настройки видимости контента гостям сайта).

Пошаговая настройка групп пользователей

Захожу в Настройки → Настройки продукта → Пользователи → Группы пользователей → Добавить группу. Дальше по шагам:

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

Отдельно обращаю внимание на модуль «Управление структурой» - доступ к нему фактически равен доступу к правке шаблонов и файлов сайта через визуальный редактор. Давать его контент-менеджеру, который должен только публиковать статьи, не стоит: это открывает возможность менять код страниц через встроенный редактор компонентов.

Права на разделы инфоблоков: тонкая настройка каталога и контента

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

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

Важный нюанс, о который спотыкаются даже опытные админы: права на инфоблок и права на модуль «Каталог» - это разные настройки. Пользователь может иметь полный доступ к инфоблоку «Товары» как к контенту, но без прав на модуль «Каталог» не увидит вкладки с ценами, торговыми предложениями и остатками на складе.

Роли для интернет-магазина: менеджер, кладовщик, бухгалтер

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

Ограничение «доступ к своим заказам» для менеджера по продажам настраивается не через стандартные группы, а через фильтр в компоненте списка заказов или кастомный обработчик события OnAfterUserAuthorize с проверкой ответственного менеджера - стандартная ролевая модель Битрикс такой сценарий из коробки не покрывает. Если у вас несколько менеджеров и заказы должны быть видны только «своим» - это отдельная доработка, а не настройка через админку.

При интеграции с СДЭК или эквайрингом вроде Т‑Банка я обычно даю доступ к настройкам платёжных систем и служб доставки только администратору и, при необходимости, бухгалтеру - по чтению. Ключи API эквайринга и токены доставки не должны быть доступны сотрудникам без явной служебной необходимости, это база любого аудита безопасности интернет-магазина.

Проверка прав в коде: что упускают при кастомных доработках

Стандартная ошибка на проектах с кастомными компонентами - права настроены в админке, но собственный PHP-код компонента их не проверяет. Например, если менеджер добавил свой обработчик для массового изменения цен через AJAX, права модуля «Каталог» на этот обработчик не распространяются автоматически - их нужно проверять явно.

global $USER;

if (!$USER->IsAuthorized() || !$USER->CanDoOperation('edit_price')) {
    header('HTTP/1.1 403 Forbidden');
    die('Доступ запрещён');
}

// либо проверка по конкретной группе
$arGroups = $USER->GetUserGroupArray();
if (!in_array(7, $arGroups)) {
    die('Операция доступна только группе «Менеджер по продажам»');
}

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

Типичные ошибки при настройке прав доступа

За несколько лet работы с Битрикс-проектами я вывел список ошибок, которые встречаю чаще всего:

• Группа «Все авторизованные пользователи» получает права по умолчанию выше, чем нужно - потом это наследуется во все новые группы;
• Права раздают через дублирование существующей группы «на всякий случай», в итоге через год десяток почти одинаковых групп с разницей в одну настройку;
• Забывают, что права на модуль и права на конкретный инфоблок - разные уровни, и настраивают только один из них;
• Не проверяют права в кастомном коде, полагаясь только на то, что кнопка скрыта в интерфейсе;
• Держат больше двух-трёх «суперадминов» - чем больше людей с полным доступом, тем сложнее расследовать инцидент, если что-то сломалось или пропало.

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

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

Частые вопросы

Сколько администраторов с полным доступом стоит держать в Битрикс

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

Можно ли ограничить доступ конкретного менеджера только его заказами

Стандартными группами - нет, права в Битрикс работают на уровне модулей и разделов инфоблоков, а не на уровне отдельных записей с привязкой «мой заказ / чужой заказ». Такое ограничение реализуется через кастомный фильтр в компоненте списка заказов или обработчик события с проверкой ответственного менеджера.

Что делать, если сотрудник уволился, а у него был полный доступ

Сразу деактивировать учётную запись через «Заблокировать пользователя» в профиле, а не просто удалять из групп - удаление из группы не сбрасывает активные сессии. После блокировки стоит проверить, не использовал ли сотрудник свой доступ для создания собственных API-ключей или дополнительных учётных записей с правами администратора.

Нужно ли настраивать права доступа, если сайтом пользуются два-три человека

Даже при небольшой команде разграничение прав снимает риск случайного повреждения данных: например, контент-менеджер без доступа к модулю «Управление структурой» физически не сможет сломать шаблон сайта, пытаясь поправить текст. Настройка занимает час-полтора, а восстановление после случайной ошибки в шаблоне - от нескольких часов работы разработчика.