Атомарные роли в 1С: что это такое и как их применять

Атомарная роль в 1С — это роль, которая предоставляет доступ к одному конкретному объекту метаданных или одной узкой операции и не содержит в себе прав на другие объекты. Такой подход противопоставляется «монолитным» ролям вроде «Полные права» или «Менеджер по продажам», где в одну роль собраны сотни разрешений сразу. Атомарность означает неделимость: роль нельзя разложить на более мелкие осмысленные части без потери её назначения.

Концепция атомарных ролей активно применяется в библиотеке стандартных подсистем (БСП) и в типовых конфигурациях на её основе. Там права разбиты на мелкие роли вида «Добавление изменение контрагентов», «Чтение номенклатуры», «Просмотр отчёта продажи», которые затем собираются в профили групп доступа. Это позволяет администратору гибко комбинировать права под конкретного пользователя, не лезя в конфигуратор.

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

Чем атомарная роль отличается от обычной (составной)

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

Атомарная роль решает эту проблему декомпозицией. Вместо одной большой роли создаётся набор мелких: «Чтение контрагентов», «Добавление и изменение контрагентов», «Чтение договоров», «Проведение реализации товаров». Права пользователя складываются из суммы назначенных ему ролей — в 1С права объединяются по принципу логического «ИЛИ»: если хотя бы одна роль разрешает действие, оно разрешено.

Важное следствие: атомарная роль никогда не должна «запрещать». В 1С нет запрещающих ролей — есть только разрешающие. Поэтому безопасность достигается не отключением прав, а их отсутствием в наборе пользователя. Если роль содержит лишнее разрешение, убрать его у конкретного сотрудника, не трогая роль, невозможно.

Сравнение вариантов

Атомарные роли

Подходят для типовых конфигураций на БСП и крупных внедрений: права собираются из мелких блоков, легко аудировать и комбинировать. Минус — больше объектов ролей в конфигурации.

Составные (функциональные) роли

Подходят для небольших самописных решений с 2–3 типовыми должностями. Минус — любое отклонение от шаблона требует новой роли, аудит прав затруднён.

Полные права / Администратор

Только для разработчиков и администраторов. Выдача рядовым пользователям — критический риск для данных.

Как устроена модель прав на атомарных ролях в типовых конфигурациях

В конфигурациях на базе БСП (1С:ERP, «Управление торговлей», «Зарплата и управление персоналом», «Бухгалтерия предприятия») модель прав двухуровневая. Первый уровень — атомарные роли в конфигураторе, их создаёт и поддерживает разработчик. Второй уровень — профили групп доступа, которые администратор собирает из ролей уже в режиме предприятия, без изменения конфигурации.

Названия атомарных ролей в типовых решениях следуют шаблону: действие + объект. Например: «Добавление изменение базовой нормативно-справочной информации», «Чтение информации по начислению зарплаты», «Просмотр отчёта остатки товаров». Роли на чтение и на изменение разделены намеренно — это позволяет дать сотруднику просмотр данных без права их портить.

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

Как спроектировать атомарные роли в собственной конфигурации

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

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

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

1. 1
   Откройте конфигуратор, ветвь «Общие — Роли», создайте новую роль с говорящим именем по шаблону «ДействиеОбъект».
2. 2
   Установите права только на один целевой объект: например, для роли чтения — флажки «Чтение» и «Просмотр» у нужного справочника.
3. 3
   При необходимости добавьте шаблон RLS на закладке «Шаблоны ограничений» для ограничения видимых записей.
4. 4
   Проверьте зависимости: интерактивные права (интерактивное добавление, интерактивное изменение) нужны для работы через формы.
5. 5
   Включите роль в профиль группы доступа (для БСП) или назначьте пользователю напрямую и протестируйте под тестовой учётной записью.

Как проверить, что права настроены правильно

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

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

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

Контрольные точки

Как проверить результат

Открытие рабочего списка документов

Норма

Список открывается, видны только разрешённые записи

Тревожный признак

Ошибка «Нарушение прав доступа» или пустой список при наличии данных

Проведение документа

Норма

Документ проводится, движения по регистрам формируются

Тревожный признак

Ошибка прав на регистр или связанный справочник при проведении

Попытка закрытого действия

Норма

Команда недоступна или выдаёт отказ в доступе

Тревожный признак

Действие выполняется — в наборе лишняя роль

Отчёты пользователя

Норма

Открываются только разрешённые отчёты с корректными данными

Тревожный признак

Отчёт открывается, но пустой (сработал RLS) либо видны чужие данные

Типичные ошибки при работе с атомарными ролями

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

Вторая ошибка — забыть про интерактивные права. В 1С право «Добавление» и «Интерактивное добавление» — разные вещи: первое нужно для программного создания объектов, второе — для работы пользователя через формы. Если поставить только неинтерактивные права, пользователь увидит отказ при попытке создать элемент в интерфейсе.

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

Ограничения подхода и когда атомарные роли не нужны

Атомарная модель требует дисциплины: каждый новый объект метаданных должен сразу получить свои роли, иначе он окажется доступен только администраторам, и пользователи начнут жаловаться после каждого обновления. В небольших конфигурациях с двумя-тремя типовыми должностями полная декомпозиция избыточна — достаточно нескольких функциональных ролей.

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

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

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

FAQ: частые вопросы об атомарных ролях в 1С

Чем атомарная роль отличается от профиля группы доступа?

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

Можно ли назначить пользователю несколько ролей одновременно?

Да, это нормальная практика. Права суммируются по принципу «ИЛИ»: пользователю доступно всё, что разрешено хотя бы одной из его ролей. Запрещающих ролей в 1С не существует.

Почему пользователь с нужной ролью всё равно получает «Нарушение прав доступа»?

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

Что такое RLS и как он связан с атомарными ролями?

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

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

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

Сколько атомарных ролей должно быть в конфигурации?

Жёсткой нормы нет. Ориентир — одна роль на каждую осмысленную комбинацию «действие + объект», которую реально требуется раздавать отдельно. Если два действия всегда выдаются вместе, объединяйте их в одну роль, чтобы не раздувать конфигурацию.