Пока над сайтом работают три человека, вопрос прав не стоит: все сидят под администратором, всё видно, всё можно. Сложности начинаются, когда в проекте появляются контент-менеджер по акциям, менеджер каталога, SEO-специалист на аутсорсе, бухгалтер, которому нужны только заказы, и подрядчик по вёрстке, которого пустили «на пару правок» ещё прошлой весной.
Дальше сценарии повторяются от компании к компании. Кто-то удаляет раздел каталога, перепутав его с тестовым. Прайс уезжает в публикацию до согласования. Аутсорсер, с которым разошлись, до сих пор заходит в админку. Бывает и обратная крайность: права нарезаны так плотно, что любое действие требует администратора, и вся команда упирается в одного человека, который к тому же иногда бывает в отпуске.
1С-Битрикс даёт достаточно инструментов, чтобы ни один из этих сценариев не случился. Но система прав здесь устроена многоэтажно, и без понимания её логики настройка превращается в набор разрозненных галочек, которые потом никто не может объяснить.
Три этажа прав, которые работают независимо друг от друга
В 1С-Битрикс нет одного экрана, где настраивается всё. Права проверяются на трёх разных уровнях, и каждый живёт по своим правилам.
Права на файлы и каталоги проверяются раньше всего, в прологе, до того как загрузится ядро. Это самый низкий и самый быстрый уровень: если пользователю закрыт доступ к папке, он не увидит её содержимое независимо от того, что ему разрешено дальше.
Права модулей отвечают за функционал внутри системы: кто может редактировать структуру сайта, кто работает с торговым каталогом, кто видит заказы, кто заходит в настройки.
Права на объекты касаются конкретных сущностей: инфоблоков, разделов, элементов, публичных страниц, файлов. Здесь настраивается самое тонкое разграничение, вплоть до отдельного элемента каталога.
Практический вывод из этого простой. Если сотрудник «не видит раздел», причина может лежать на любом из трёх этажей, и проверять их нужно по очереди. Отсюда же типичная ошибка при аудите: проблему ищут только в группе пользователя, хотя закрыт доступ к папке или снят доступ к модулю.
Пользователь, группа, уровень доступа: как связаны эти три сущности
Права в 1С-Битрикс не выдаются человеку напрямую. Между пользователем и разрешением стоят два промежуточных звена: группа пользователей и уровень доступа. Пользователя включают в одну или несколько групп, группе назначают уровни доступа к модулям, а уровень доступа представляет собой именованный набор разрешённых операций.
Стандартные уровни обозначаются буквами, и эти обозначения встречаются по всей админке:
- D, Deny, доступ запрещён;
- R, Read, просмотр без изменений;
- U, редактирование через документооборот, то есть с обязательным согласованием;
- W, Write, редактирование и добавление данных;
- X, Full, полный контроль, включая управление доступом других.
Свои уровни тоже создаются, в разделе Настройки → Пользователи → Уровни доступа. При создании выбирают модуль, привязку к функционалу, буквенное обозначение, описание, а на вкладке «Включаемые операции» отмечают разрешённые действия. Для большой команды это ключевая возможность. Вместо того чтобы каждый раз объяснять, почему у менеджера каталога стоит галочка вот здесь и здесь, вы один раз собираете уровень «Редактор каталога без удаления» и дальше назначаете его группе целиком.
Часть групп существует в системе изначально. Это «Администраторы» с полным доступом ко всем модулям, «Все пользователи», куда попадают в том числе неавторизованные посетители, «Зарегистрированные пользователи», «Администраторы интернет-магазина» и «Контент-редакторы». Есть и служебные группы, связанные с правом голосовать за рейтинг и за авторитет. Стандартный набор удобно использовать как отправную точку, но переносить его на реальную структуру компании один в один не стоит: названия совпадают с должностями лишь на первый взгляд, а набор операций внутри чаще всего приходится пересобирать под конкретный проект.
Есть правило, которое ломает много схем и о котором регулярно забывают. Если пользователь состоит в нескольких группах, он получает максимальный уровень прав среди всех своих групп. Права суммируются, а не пересекаются. Поэтому закрыть человеку доступ, добавив его в ограничительную группу, не получится: сработает та группа, где прав больше. Ограничивать нужно, убирая из групп.
Из этого же правила следует ещё одно: права группы «Все пользователи» не должны быть выше прав остальных групп. Иначе вся тонкая настройка по ролям перекрывается снизу, и разграничение существует только на бумаге.
Права на модули: два входа, один результат
Доступ к модулю настраивается из двух мест, и оба ведут к одной и той же записи. Первый вход находится в разделе Настройки → Пользователи → Группы пользователей, в форме группы, на вкладке «Доступ»: здесь вы видите весь список модулей глазами одной группы. Второй вход, Настройки → Настройки продукта → Настройки модулей, нужный модуль, вкладка «Доступ», показывает один модуль глазами всех групп.
Что задано в одном месте, автоматически отображается в другом. Разница только в удобстве. Когда вы заводите новую роль, идти нужно от группы. Когда разбираетесь, кто вообще имеет доступ к интернет-магазину, идти нужно от модуля.
В настройках каждого модуля есть поле «По умолчанию». Оно задаёт уровень для всех групп, у которых нет отдельного переопределения. Для большой команды это удобная страховка: выставляете «Доступ закрыт» по умолчанию и дальше открываете точечно. Схема «разрешено всё, кроме перечисленного» на проекте с тридцатью пользователями рано или поздно даёт дыру, обратная схема ведёт себя предсказуемее.
Не все модули работают через уровни доступа. Часть построена на ролевой модели, например CRM. Смешивать эти две логики в одной голове не стоит: если модуль ролевой, искать в нём буквы D, R и W бессмысленно.
И бытовая, но регулярно съедающая полчаса деталь. Если вы выдали группе доступ, а участники по-прежнему его не видят, попросите их выйти и авторизоваться заново. Новые права не подхватываются в уже открытой сессии.
Инфоблоки: где заканчивается простой режим
Доступ к инфоблоку настраивается на вкладке «Доступ» в форме его редактирования, и здесь есть два режима.
Простой режим раздаёт права группам на инфоблок целиком. Контент-редакторам «Изменение», остальным «Чтение». В форме всегда присутствуют две обязательные группы: «Все пользователи» и «Администраторы». Для новостей, статей, баннеров и любого инфоблока, который целиком ведёт один отдел, этого достаточно, и усложнять не нужно.
Расширенное управление правами включается отдельно и меняет картину принципиально. В расширенном режиме права назначаются не только группам, но и конкретным пользователям, причём на отдельные разделы и отдельные элементы. Права наследуются по цепочке: инфоблок, затем раздел, затем элемент.
Именно расширенный режим решает задачу, ради которой крупные команды и приходят к нормальной настройке. Возьмём каталог производственной компании, где восемь товарных направлений и за каждым закреплён свой менеджер. В простом режиме у вас два варианта: либо все восемь редактируют весь каталог, либо все восемь ходят к администратору. В расширенном каждый менеджер получает права на свою ветку разделов, а корень каталога и структуру категорий держит руководитель направления. Дерево при этом остаётся одно, дублировать инфоблоки не нужно.
Цена этой гибкости в сложности поддержки. Расширенные права легко превращаются в лоскутное одеяло, где через год никто не помнит, почему у конкретного элемента персональное правило. Поэтому включать расширенный режим стоит осознанно: там, где схема действительно ветвится, и с обязательной фиксацией того, кто на что имеет права, во внешнем документе.
Файлы, папки и публичные страницы
Права на файловую структуру настраиваются через Контент → Структура сайта → Файлы и папки, пункт «Права на доступ». Технически они хранятся в файлах .access.php в самих папках, и синтаксис там прозрачный: указывается имя папки, идентификатор группы и уровень доступа. Символ * означает «для всех групп» и обычно используется, чтобы закрыть каталог целиком, а затем открыть его отдельным строкам.
Поскольку эти права проверяются в прологе, до загрузки ядра, они работают быстро и надёжно. Но и ошибку здесь заметить сложнее: закрытая папка не выдаёт понятного сообщения о нехватке прав, она просто не отдаёт содержимое.
Для публичных страниц и разделов есть отдельный механизм. При создании или редактировании страницы доступна опция «Ограничить доступ», которая позволяет выбрать группы, видящие страницу. На вкладке «Доступ» задаются индивидуальные правила для конкретных пользователей. Это рабочий инструмент для закрытых зон: личного кабинета дилера, документов для партнёров, внутренних инструкций.
Как собрать матрицу ролей для команды из тридцати человек
Настройка прав в большой команде начинается не в админке, а в таблице. В админку вы приходите последним шагом, когда решение уже принято.
Первый шаг, инвентаризация: выпишите всех, у кого сейчас есть доступ к сайту, включая подрядчиков и бывших сотрудников. Здесь обычно всплывают две-три учётные записи, о которых никто не помнит. Дальше рядом с каждым человеком укажите, что он делает на сайте фактически, не по должности, а по реальным действиям за последний квартал.
Следующий шаг, группировка. Люди с одинаковым набором действий образуют роль. У среднего проекта их получается от пяти до девяти: администратор, контент-редактор, менеджер каталога, менеджер заказов, SEO-специалист, разработчик-подрядчик, наблюдатель с правом только чтения. Больше десяти ролей означает, что вы описали не роли, а людей, и через полгода схема перестанет соответствовать реальности.
Затем каждая роль раскладывается на модули и объекты. По строкам роли, по столбцам модули, инфоблоки и разделы файловой структуры, в ячейках уровень доступа. Пустая ячейка означает «доступ закрыт», а не «разберёмся потом».
Отдельно проговорите три вещи, которые чаще всего забывают. Кто имеет право удалять: этот круг почти всегда должен быть уже, чем круг тех, кто имеет право редактировать. Кто может менять сами права: здесь стоит оставить одного-двух человек, иначе схема расползётся. И что происходит при увольнении: у каждой роли нужен описанный сценарий отзыва доступа, включая внешних подрядчиков.
Только после этого настройка переносится в систему. Создаются группы, при необходимости собственные уровни доступа с нужным набором операций, права выставляются группам, пользователи распределяются по группам. И проверяется всё не под администратором, а под тестовой учётной записью каждой роли: только так видно, что человек действительно видит и может.
Как это выглядит на живом проекте
Пример ниже собирательный, а не описание конкретного клиента, но картина повторяется у дистрибьюторов и производственных компаний.
Есть сайт на 1С-Битрикс с каталогом на несколько тысяч позиций, разделом новостей, закрытой зоной для дилеров и подключённым интернет-магазином. С сайтом работают двадцать восемь человек: четыре менеджера товарных направлений, два контент-менеджера, отдел продаж, который смотрит заказы, маркетолог, внешний SEO-подрядчик и системный администратор.
Первое, что обнаруживается при разборе: двадцать один пользователь с полными правами. Не потому, что так решили, а потому, что каждый раз, когда у кого-то что-то не открывалось, вопрос закрывали быстрым способом. Ещё три учётные записи принадлежат людям, которые в компании уже не работают.
Дальше собирается матрица. Менеджеры направлений получают права на редактирование своих веток каталога через расширенное управление правами инфоблока, структуру категорий им не отдают. Контент-менеджеры работают с новостями и статьями в простом режиме, каталога не касаются вовсе. Отделу продаж выдаётся доступ к заказам без права трогать товары и цены. Маркетологу открывается редактирование посадочных страниц, но закрывается файловая структура. SEO-подрядчику достаётся чтение по всему сайту и запись только в поля метатегов, для чего создаётся отдельный уровень доступа с нужным набором операций. Права пользователей сайта в публичной части составляют отдельный слой: закрытая дилерская зона ограничивается через опцию «Ограничить доступ» на разделе.
Полный доступ остаётся у двоих: системного администратора и его резервного заместителя. Все изменения фиксируются в таблице, которая лежит рядом с остальной проектной документацией. Через полгода, когда двое из восьми человек сменятся, схему не придётся восстанавливать по памяти.
Пять ошибок, которые встречаются почти на каждом проекте
Первая: права выданы конкретному сотруднику, а не группе. Работает ровно до первого нового человека на этой позиции, дальше начинается копирование настроек по памяти.
Вторая: полный доступ роздан «чтобы не мешал работать». В команде из тридцати человек это означает, что тридцать человек могут удалить всё что угодно, а разобраться, кто именно это сделал, будет заметно сложнее.
Третья: за живыми учётками никто не следит. Подрядчик закончил работу два года назад, учётная запись активна. Регулярная сверка списка пользователей со списком тех, кто реально работает с сайтом, снимает этот риск за полчаса в квартал.
Четвёртая: расширенный режим включён на всякий случай. Инфоблок с десятком новостей переведён в расширенное управление правами без реальной необходимости, и теперь его настройки понимает только тот, кто их делал.
Пятая: схема нигде не описана. Права разложены грамотно, но существуют только в голове администратора и в интерфейсе. При смене человека всё приходится реконструировать заново.
Что стоит проверять после настройки
Разграничение прав не бывает разовой задачей, у неё есть эксплуатационный цикл. Разумный минимум выглядит так. Раз в квартал сверяем активные учётные записи с фактическим составом команды. При каждом уходе сотрудника или завершении работ подрядчика отзываем доступ в тот же день, а не когда вспомнится. При появлении новой роли сначала появляется строка в матрице, потом настройка в системе.
Полезно заглядывать и в журнал вторжений модуля «Проактивная защита». Он регистрирует происходящие в системе события, включая нештатные, и позволяет заметить попытки подобрать доступ. Для учётных записей с расширенными правами имеет смысл рассмотреть одноразовые пароли: этот механизм дополняет стандартную авторизацию вторым фактором и заметно усложняет вход по украденному паролю.
Если разбирать всё это внутри некому или система прав на проекте уже накопила слой исторических решений, работу разумно отдать наружу вместе с аудитом текущего состояния. Мы в B2BPRO.KZ занимаемся этим в рамках сопровождения проектов на 1С-Битрикс: разбираем действующую схему, собираем матрицу ролей вместе с заказчиком и переносим её в систему. Подробнее на странице разработки и сопровождения сайтов.
Грамотно настроенные роли доступа в 1С-Битрикс обычно никто не замечает, потому что каждый сотрудник видит ровно то, что ему нужно, и не натыкается на чужие разделы. Замечают всегда обратное: когда прав слишком много и что-то удалили, или когда прав слишком мало и половина команды стоит в очереди к администратору. Настройка нужна ровно для того, чтобы ни один из этих дней не наступил.
Частые вопросы
Можно ли выдать права конкретному пользователю, минуя группы?
На уровне модулей нет, права работают через группы. Индивидуальные правила доступны на уровне объектов: в расширенном режиме управления правами инфоблоков и на вкладке «Доступ» публичных страниц и разделов. Но как основной способ раздачи прав это плохая практика: такие настройки не переносятся на нового сотрудника и быстро теряются.
Сотрудник состоит в двух группах с разными правами. Какие сработают?
Максимальные из двух. Права разных групп суммируются, поэтому ограничить человека, добавив его в более строгую группу, не получится. Нужно убирать его из группы с избыточными правами.
Выдал доступ, но сотрудник его не видит. Что не так?
Сначала попросите его выйти и авторизоваться заново, права не подхватываются в открытой сессии. Если не помогло, проверяйте по очереди все три уровня: доступ к папке, доступ к модулю и права на сам объект. Причина может быть на любом из них.
Обязательно ли включать расширенное управление правами инфоблоков?
Нет. Простого режима хватает, когда инфоблок целиком ведёт один отдел. Расширенный нужен тогда, когда внутри одного инфоблока за разные разделы отвечают разные люди, например в большом каталоге с несколькими товарными направлениями.
Сколько ролей должно быть в компании на тридцать человек?
Обычно от пяти до девяти. Если получается больше десяти, скорее всего описаны не роли, а отдельные люди, и такая схема перестаёт отражать реальность уже через несколько месяцев.