Администрирование · 11 мин
Атомарные роли в 1С: что это такое и как их использовать
Что такое атомарные роли в 1С, чем они отличаются от обычных ролей, как настроить доступ к объектам без перегрузки прав и проверить результат.
Атомарная роль в 1С — это роль, которая предоставляет доступ к одному конкретному объекту конфигурации или к одной узкой операции: например, только чтение справочника «Контрагенты» или только проведение документа «Реализация товаров». Слово «атомарный» означает неделимость: такую роль нельзя уменьшить дальше, не потеряв её смысл. Подход противопоставляется «монолитным» ролям вроде «Менеджер» или «Бухгалтер», которые сразу открывают десятки объектов.
Идея атомарных ролей пришла из практики разграничения прав в крупных внедрениях. Когда в базе работают сотни пользователей с разными должностными обязанностями, выдавать им типовые широкие роли опасно: сотрудник получает доступ к данным, которые ему не нужны, а аудит прав превращается в ручной перебор галочек. Атомарные роли позволяют собирать профиль доступа как конструктор — из мелких, понятных блоков.
В типовых конфигурациях 1С (Управление торговлей, ERP, Зарплата и управление персоналом) механизм реализован через профили групп доступа из библиотеки стандартных подсистем (БСП). Там роли уже разбиты на мелкие — «Чтение номенклатуры», «Добавление изменение контрагентов» и т.п., а администратор комбинирует их в профили под конкретные должности. Понимание этой логики нужно и администраторам, и разработчикам, которые проектируют собственные роли в конфигураторе.
Чем атомарные роли отличаются от обычных ролей
Обычная (составная, монолитная) роль объединяет права на множество объектов сразу. Например, типовая роль «Менеджер по продажам» может включать доступ к заказам, реализациям, счетам, прайсам, отчётам по продажам и части справочников. Это удобно для быстрого старта, но плохо масштабируется: если одному менеджеру нужно видеть цены поставщиков, а другому нет, приходится либо создавать отдельную роль-копию, либо смириться с избыточным доступом.
Атомарная роль решает эту проблему декомпозицией. Каждое право — чтение, добавление, изменение, проведение, удаление — выносится в отдельную роль по каждому объекту. Профиль пользователя собирается из нужного набора, а лишние блоки просто не включаются.
Сравнение подходов
Быстро назначаются, подходят для маленьких компаний с типовыми должностями. Минус — избыточные права и сложность аудита.
Точная настройка под должность, прозрачный аудит, безопасное делегирование. Минус — больше первоначальной работы и дисциплины при сопровождении.
Базовые типовые роли плюс атомарные для чувствительных объектов. Практичный вариант при частичной переработке конфигурации.
Где атомарные роли применяются в типовых конфигурациях
В конфигурациях на базе БСП (1С:ERP, УТ 11, КА, ЗУП, Бухгалтерия 3.0) права назначаются не напрямую пользователю, а через профили групп доступа. Профиль — это набор ролей, и значительная часть этих ролей атомарна: «Чтение банковских счетов», «Добавление изменение договоров контрагентов», «Просмотр отчёта по взаиморасчётам».
Найти их можно в разделе «Администрирование → Настройки пользователей и прав → Профили групп доступа». Открыв любой типовой профиль, вы увидите список ролей с флажками — именно здесь видно атомарную структуру. Разрешённые действия сгруппированы по подсистемам, и администратор может снять отдельный флажок, не создавая новую роль в конфигураторе.
Важно понимать: в типовых решениях атомарность уже реализована разработчиками фирмы «1С». Задача администратора — не писать роли с нуля, а грамотно комбинировать существующие и при необходимости создавать копии профилей под нестандартные должности.
Как спроектировать атомарные роли в собственной конфигурации
Если вы разрабатываете или дорабатываете конфигурацию, проектирование начинается с матрицы доступа: по строкам — объекты метаданных, по столбцам — должности или бизнес-роли. На пересечении отмечаются нужные операции: чтение (R), добавление и изменение (C/U), проведение, удаление. Эта матрица становится спецификацией для набора ролей.
Далее в конфигураторе создаются роли по принципу «одна роль — один объект — один набор операций». Имена принято строить единообразно, например: Чтение_Номенклатура, ДобавлениеИзменение_ЗаказКлиента, Проведение_РеализацияТоваров. Единый шаблон имён критически важен: без него через год сопровождения никто не сможет быстро понять, что делает каждая роль.
- 1Составьте матрицу доступа: объекты × должности с указанием операций
- 2Создайте в конфигураторе роли по шаблону: одна роль — один объект — одна операция
- 3Задайте единый формат имён и синонимов ролей
- 4Соберите роли в профили групп доступа под реальные должности
- 5Проверьте работу под тестовым пользователем каждой должности
- 6Задокументируйте состав профилей и правила их изменения
Не дробите роли до абсурда. Права «чтение» и «просмотр» одного объекта почти всегда идут вместе — разносить их по разным ролям смысла нет. Атомарность оправдана там, где операции реально раздаются разным людям: например, один сотрудник вводит документы, другой их проводит, третий только смотрит отчёты.
Ограничение доступа на уровне записей (RLS) и атомарные роли
Атомарные роли управляют доступом на уровне объектов метаданных: какие справочники и документы видит пользователь. Но часто требуется тоньше — чтобы менеджер видел только своих клиентов или документы своей организации. Это решается механизмом RLS (Record Level Security) — ограничением доступа на уровне записей, которое задаётся в шаблонах ограничений внутри роли.
При проектировании атомарных ролей RLS-шаблоны обычно выносятся в отдельные роли-ограничители или включаются в роли чтения. В типовых конфигурациях это уже сделано: достаточно в профиле группы доступа указать разрешённые значения (организации, склады, контрагентов), а механизм БСП сам подставит ограничения.
Проверка и аудит назначенных прав
После настройки профилей обязательно проверяйте результат от имени реального пользователя. Создайте тестовую учётную запись, включите её в группу доступа и пройдите рабочие сценарии: создание документа, проведение, открытие отчёта, попытка открыть запрещённый объект. Проверка «от администратора» бессмысленна — у полных прав всё открывается всегда.
Для аудита в типовых конфигурациях есть отчёт «Права доступа» (в разделе администрирования), который показывает, какие роли и объекты доступны конкретному пользователю или группе. При атомарной структуре этот отчёт читается легко: видно, из каких именно «кирпичиков» собран доступ. При монолитных ролях приходится вскрывать каждую роль в конфигураторе.
Как проверить результат
Открываются только нужные разделы и объекты
Видны лишние подсистемы или, наоборот, пустой интерфейс
Документ проводится, движения формируются
Ошибка «Нарушение прав доступа» при проведении
Состав ролей соответствует матрице доступа
Есть роли, которых нет в матрице, или не хватает нужных
Объект не отображается в интерфейсе
Объект открывается или виден в списках
Типичные ошибки при работе с атомарными ролями
Самая частая ошибка — редактирование типовых ролей и профилей напрямую. При обновлении конфигурации изменения затрутся или приведут к конфликтам. Правильный путь — копировать типовой профиль и изменять копию, а собственные роли добавлять через расширение конфигурации.
Вторая ошибка — забыть про «сопутствующие» права. Пользователь получил роль на проведение документа, но не получил чтение связанных регистров и справочников — в результате документ не проводится с ошибкой доступа. Атомарные роли требуют продумывать зависимости: проведение документа тянет за собой чтение и изменение регистров, по которым он делает движения.
Когда атомарные роли оправданы, а когда нет
Атомарный подход окупается в базах с десятками пользователей, разными должностями, требованиями к информационной безопасности и регулярными проверками прав. Там, где нужно точно ответить на вопрос «кто имеет доступ к зарплате», атомарная структура даёт ответ за минуту.
В небольшой компании с пятью пользователями и типовой Бухгалтерией проектировать собственные атомарные роли избыточно: достаточно типовых профилей. Трудозатраты на проектирование, тестирование и документирование не окупятся, а поддерживать систему будет некому.
Как выбрать действие
Частые вопросы об атомарных ролях в 1С
Атомарная роль — это стандартный термин платформы 1С?
Нет, в документации платформы такого термина нет. Это устоявшееся в сообществе разработчиков и внедренцев название подхода, при котором роль отвечает за один объект и одну операцию. Формально это обычные роли конфигурации, спроектированные по принципу минимальности.
Можно ли назначить пользователю несколько атомарных ролей сразу?
Да, именно так и работает подход: права в 1С суммируются, и профиль пользователя собирается из множества мелких ролей. В типовых конфигурациях для этого служат профили групп доступа — пользователь включается в группу, а группа связана с профилем, содержащим набор ролей.
Почему после выдачи роли на документ пользователь не может его провести?
Проведение документа требует прав не только на сам документ, но и на регистры, по которым он формирует движения, а иногда и на связанные справочники. Проверьте, что в профиль включены роли на изменение соответствующих регистров накопления и сведений — типовые профили обычно уже содержат нужные связки.
Чем профиль группы доступа отличается от роли?
Роль — объект конфигурации, задающий права на объекты метаданных. Профиль группы доступа — пользовательский объект базы данных, который объединяет роли и настройки ограничений (RLS) без изменения конфигурации. Администратор работает с профилями, разработчик — с ролями.
Теряются ли настройки атомарных ролей при обновлении конфигурации?
Роли, созданные в основной конфигурации с изменением типовых объектов, могут конфликтовать при обновлении. Безопасные варианты: создавать собственные роли в расширении конфигурации и менять права через копии профилей групп доступа — эти настройки хранятся в базе и обновление не затрагивает.
Как быстро узнать, какие роли есть у конкретного пользователя?
В типовых конфигурациях откройте «Администрирование → Настройки пользователей и прав» и воспользуйтесь отчётом «Права доступа» с отбором по пользователю. Он покажет список ролей и доступные объекты. Альтернатива — посмотреть, в какие группы доступа входит пользователь, и проверить состав профилей этих групп.
Что важно запомнить
Атомарные роли — это минимальные роли «один объект — одна операция», из которых собираются профили доступа. В типовых конфигурациях они уже реализованы через профили групп доступа; в собственных разработках проектируйте их по матрице доступа, добавляйте через расширение и обязательно проверяйте работу под тестовым пользователем.