Независимые права подчинённых объектов 1С: что это и как настроить

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

Механизм независимых прав подчинённых объектов разрывает эту связь. Когда он включён, права на подчинённый объект проверяются отдельно, по своим ролям, а не «протягиваются» от объекта-владельца. Это даёт гибкость: например, можно запретить менеджеру читать регистр сведений с ценами закупки, даже если он работает с документами, которые делают записи в этот регистр.

Механизм относится к разделу администрирования и разработки: его настройка выполняется в конфигураторе и напрямую влияет на поведение ролей и производительность проверки прав. Ошибки здесь приводят либо к избыточному доступу к чувствительным данным, либо к массовым ошибкам «Нарушение прав доступа» у пользователей.

Что такое подчинённые объекты и как наследуются права по умолчанию

Подчинёнными в 1С называют объекты, которые не существуют сами по себе, а привязаны к владельцу. Типичные примеры: подчинённый справочник (элементы имеют смысл только в контексте владельца), регистр сведений, подчинённый регистратору (записи формируются документом), регистры накопления и бухгалтерии, движения которых принадлежат документу-регистратору.

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

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

Что меняет режим независимых прав

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

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

Где включается настройка

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

1. 1
   Определите, какие подчинённые объекты должны проверяться независимо: перечислите регистры и подчинённые справочники с чувствительными данными.
2. 2
   Создайте или скорректируйте роли на эти объекты: явно задайте права на чтение, добавление, изменение, удаление.
3. 3
   Включите режим независимых прав в свойствах конфигурации (параметр совместимости прав доступа).
4. 4
   Обновите конфигурацию базы данных, предварительно сделав резервную копию.
5. 5
   Зайдите под тестовым пользователем с ограниченной ролью и проверьте: доступ к владельцу есть, доступ к подчинённому объекту соответствует задуманному.
6. 6
   Проверьте обратный сценарий: пользователь с полными правами не потерял доступ к регистрам и отчётам.

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

Когда независимые права действительно нужны

Механизм оправдан не всегда. Включать его имеет смысл в конкретных ситуациях, когда наследование прав создаёт реальную проблему безопасности или методологии учёта.

Маршрут решения

Как выбрать действие

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

Нужно запретить ручное редактирование записей регистра, подчинённого регистратору, в обход документаНастройте роли регистра без прав на интерактивное изменение и включите независимую проверку

Все пользователи работают с одним набором данных и разграничение внутри документов не требуетсяОставьте наследование — независимые права добавят накладные расходы без пользы

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

Частый сценарий — разделение «оперативного» и «аналитического» контуров. Кладовщик должен проводить приходные документы, но не должен видеть регистр с финансовыми результатами. Бухгалтер, наоборот, анализирует регистры, но не редактирует первичные документы. Наследование прав такую схему не реализует, независимые права — реализуют.

Ограничения и побочные эффекты

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

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

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

Типичные ошибки при настройке

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

Как проверить, что настройка работает

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

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

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

Открытие документа-владельца под ограниченным пользователем

Норма

Документ открывается и проводится

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

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

Открытие подчинённого регистра напрямую (через список регистра)

Норма

Регистр недоступен или доступен только на чтение — согласно задумке

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

Регистр открывается на редактирование, хотя должен быть закрыт

Отчёт по регистру у пользователя без роли на регистр

Норма

Отчёт пустой или выдаёт корректное сообщение о правах

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

Отчёт показывает данные, которые должны быть скрыты

Работа пользователя с полными правами

Норма

Все функции доступны, ничего не сломалось

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

Появились ошибки доступа там, где их не должно быть

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

FAQ

Независимые права и RLS — это одно и то же?

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

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

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

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

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

Сломаются ли отчёты после смены режима?

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

Нужно ли снимать конфигурацию с поддержки для изменения ролей?

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

Как понять, что в базе уже используется независимая проверка прав?

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