Перенос ролей и прав доступа на Битрикс: карта групп, матрица проверок и приёмка

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

Что входит в перенос ролей и прав доступа на Битрикс

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

Границы задачи стоит зафиксировать письменно до начала работ. В перенос ролей и прав входят: инвентаризация групп и ролей на старой CMS, описание прав на разделы и модули, таблица соответствия старых и новых ролей, настройка групп и ролей на Битрикс, проверка доступа после переноса и чек-лист приёмки. Не входят: перенос паролей, настройка SSO, интеграции с внешними системами аутентификации, юридическая оценка обработки персональных данных (требует отдельного согласования). Эти темы требуют отдельного специалиста и отдельного согласования.

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

Исходные данные и ответственные за перенос ролей

До настройки соберите входные данные. Без них таблица соответствия превращается в догадки. Минимальный набор: выгрузка групп пользователей из старой CMS, описание ролей (кто за что отвечает), перечень разделов и модулей, к которым нужен доступ, список сотрудников с указанием текущих групп, перечень внешних подрядчиков и их зон доступа. Если в старой системе права задавались точечно для каждого пользователя, это фиксируется отдельно — иначе при переносе исключения потеряются.

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

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

Варианты переноса ролей и критерии выбора

Есть несколько практических подходов. Первый — прямое соответствие: каждой старой группе назначается одна новая. Подходит, когда роли в старой CMS описаны аккуратно и совпадают с ролями Битрикс по смыслу. Второй — укрупнение: несколько старых групп сводятся в одну новую, если права пересекаются. Третий — дробление: одна старая группа разбивается на несколько новых, если внутри неё были разные зоны ответственности. Четвёртый — пересборка с нуля: роли проектируются заново, а старые группы используются только как источник сведений о том, кто чем пользовался.

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

Если в проекте используется CRM, стоит заранее уточнить, как в вашей версии продукта устроены роли и права: в документации для разработчиков описано, что права в CRM настраиваются на уровне ролей, роль можно назначить пользователю, группе или подразделению, а уровень прав может быть простым (есть доступ или нет) и более сложным — например, зависеть от принадлежности к отделу. Это ориентир для проектирования: конкретные возможности нужно сверять с вашей версией и конфигурацией.

Предметная последовательность действий

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

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

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

Таблица соответствия старых и новых ролей

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

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

Матрица проверок доступа после переноса

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

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

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

Учебный пример переноса ролей и прав

Учебный пример. Условная компания переезжает на Битрикс с другой CMS. В старой системе 6 групп: редакторы, менеджеры каталога, руководители, подрядчики, администраторы и группа «старые пользователи». Входные условия: 40 сотрудников, 3 внешних подрядчика, каталог из нескольких тысяч позиций, раздел новостей и блог. Пароли не переносятся — это отдельная задача.

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

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

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

Чек-лист приёмки переноса ролей и прав

• Карта групп и ролей заполнена и согласована с владельцем проекта
• Таблица соответствия старых и новых ролей подписана
• Все старые группы разобраны: перенесены, объединены или закрыты
• Права на разделы выставлены и проверены по матрице
• Права на модули выставлены и проверены по матрице
• Доступ внешних подрядчиков ограничен согласованными разделами
• Административный доступ проверен отдельно
• Расхождения зафиксированы и исправлены, проверка повторена
• План возврата описан и проверен на тестовой копии
• Персональные данные и юридические границы сверены с профильным специалистом

Чек-лист не заменяет матрицу проверок, а дополняет её. Матрица показывает, что именно проверять, чек-лист — что не забыть на приёмке. Если пункт нельзя подтвердить документально, он не считается выполненным.

Ограничения, типичные ошибки и следующий шаг

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

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

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

Если вы планируете переезд целиком, посмотрите перенос сайтов на 1С-Битрикс — там описаны этапы миграции, частью которых является перенос ролей. Для проектов на других системах полезны материалы Перенос WordPress на Битрикс: карта данных, адреса и приёмка и Перенос Тильды на Битрикс: карта миграции, проверка и приёмка. Если переезжает интернет-магазин, пригодится Миграция каталога интернет-магазина: как перенести большой каталог и не потерять товары — права на каталог удобно проверять вместе с самим каталогом.