Доступ редакторов к Битрикс: какие права нужны маркетологу, менеджеру и подрядчику

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

Маркетологу нужно поправить описание услуги, но для этого ему передают общий аккаунт администратора. Через некоторое время тем же доступом пользуются редактор, подрядчик и руководитель. Уже трудно понять, кто менял настройки и кому можно закрыть вход без остановки чужой работы.

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

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

Речь в статье идёт о CMS для сайта. Права сотрудников в CRM устроены иначе и разобраны отдельно в материале о доступах Битрикс24. Одинаковое слово «Битрикс» не делает настройки двух продуктов взаимозаменяемыми.

Почему одна галочка не описывает все возможности пользователя

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

Инфоблоком в Битрикс называют структурированное хранилище содержимого: например, новости, услуги или товары. Доступ к его записям не равен возможности менять любые файлы сайта. А разрешение работать с файлами может затрагивать совсем другой круг действий. Заказчику полезно различать эти области хотя бы на уровне задач.

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

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

Составьте небольшую матрицу реальных обязанностей

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

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

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

Что уточнить при доступе к разделам и элементам инфоблока

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

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

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

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

Разделите подготовку, публикацию и удаление

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

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

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

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

Каталог и обмен требуют отдельной договорённости

Менеджер может иметь право менять карточку товара, но часть её полей приходит из 1С. Ручная правка в CMS тогда способна исчезнуть после следующего обмена. Это вопрос не только доступа, но и источника данных: разрешённое действие может оказаться бесполезным или противоречащим процессу.

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

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

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

Выдавайте персональные учётные записи и ограничивайте срок

У каждого сотрудника и подрядчика должна быть собственная учётная запись. Так проще прекратить доступ одного человека и разобраться в изменениях без смены общего пароля для всей команды. Назначение общих аккаунтов оставляйте только для специально обоснованных технических случаев с отдельным контролем.

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

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

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

Как проверить права без риска для рабочих данных

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

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

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

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

Что сделать при смене роли или завершении договора

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

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

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

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

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

Для настройки доступа с ШТАБ ИТ подготовьте обязанности сотрудников и несколько примеров необходимых действий. Начните с роли, которая сейчас использует общий административный аккаунт. Результат принимайте по реальной работе персонального пользователя: нужные операции выполняются, запрет на остальные проверен, а отзыв доступа понятен компании.