Роли создаются «атомарными»

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

Неограниченный доступ

Роль ПолныеПрава (англ. FullAccess) совместно с ролью АдминистраторСистемы (англ. SystemAdministrator) дает (без RLS) ко всем объектам.

Интерактивное удаление ссылочных объектов

Ни одна роль (в т.ч. ПолныеПрава и АдминистраторСистемы) не должна давать право на интерактивное удаление ссылочных объектов.

• после создания нового объекта нужно зайти в роль ПолныеПрава и отключить право интерактивного удаления у ссылочных объектов.

Удаление ссылочных объектов

Только роль ПолныеПрава и АдминистраторСистемы должна давать право на удаление ссылочных объектов.

Устанавливать права для новых объектов

Только для роли ПолныеПрава должен быть установлен флаг «Устанавливать права для новых объектов». Для всех остальных ролей этот флаг должен быть снят.

При добавлении новой роли, флажок «Устанавливать права для реквизитов и табличных частей по умолчанию» должен быть установлен, а флажок «Независимые права подчиненных объектов» должен быть снят.

При необходимости установить в роли права только на поля какого-либо объекта метаданных (права просмотр, редактирование на реквизиты, табличные части, измерения, команды и т.п. без этих прав на сам объект), предварительно требуется следующее. В роли установить флажок «Независимые права подчиненных объектов», а флажок «Устанавливать права для реквизитов и табличных частей по умолчанию» снять с очисткой прав на все реквизиты и табличные части.

При добавлении в конфигурацию новых объектов или новых полей существующих объектов следует настроить права на эти объекты или поля в соответствующих ролях.

Право для администратора

Если какое-то право может быть использовано только администратором системы (например, использование какого-то отчета, обработки, константы), то достаточно, чтобы это предоставлялось одной из ролей ПолныеПрава и АдминистраторСистемы, создавать отдельные роли в этом случае не требуется.

Общие права

Не должно быть ролей, кроме стандартных ролей БСП, которые дают общие права (такие как Администрирование, ТонкийКлиент, Толстый клиент, Интерактивное открытие внешних обработок и т.п.).

• при создании новой роли нужно следить, чтобы эти права были выключены.

Чтение, Просмотр, Ввод по строке

В отдельных случаях для неконфиденциальных данных и общедоступных функций не требуется создавать отдельную роль на чтение (а также просмотр и ввод по строке - для ссылочных данных), а следует включать эти права в роли БазовыеПрава<ИмяБиблиотеки> (англ. BasicAccess<LibraryName>) и БазовыеПраваВнешнихПользователей<ИмяБиблиотеки> (англ. BasicAccessExternalUser<LibraryName>)  (эта роль необходима только если в конфигурации предусмотрена работа с внешними пользователями).

Например, это константы, общенациональные классификаторы, общие формы выбора периода, ввода контактной информации и др.

так же:

• вспомогательные обработки, которые нельзя вызвать из глобального командного интерфейса, а можно открыть только из других объектов, например, подбор товаров;

• обработки, в которых расположен общий код, например, код формирования печатных форм;

• команды не изменяющие данные

Права на объекты разных подсистемам

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

Например, в хранилище УП (ERP) нельзя, чтобы одна роль давала права на объекты, которые есть в УТ 11 и на объекты, которых в УТ 11 нет.

Права на объекты одной функции

Объекты необходимо объединить в элементарные функции.

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

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

Каждый объект должен быть отнесен к элементарной функции, и только к одной.

Объекты, относящиеся к разным библиотекам не могут быть отнесены к одной элементарной функции.

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

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

Обязательные роли

В конфигурации должны быть определены три обязательные роли устанавливаться как основные роли конфигурации (свойство ОсновныеРоли):
ПолныеПрава (синоним «Полные права»), АдминистраторСистемы (синоним «Администратор системы») и ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок (синоним «Интерактивное открытие внешних отчетов и обработок»).

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

• Чтение<ИмяФункции> (англ. Read<FeatureName>);

• ДобавлениеИзменение<ИмяФункции> (англ. InsertUpdate<FeatureName>)  (или Изменение<ИмяФункции> (англ. Update<FeatureName>), если добавление выполняется автоматически, либо только администратором).

Роли должны содержать следующие права (когда они имеются у объекта метаданных):

• Чтение<ИмяФункции> содержит права:

  • Чтение, Просмотр, Ввод по строке.

• Изменение<ИмяФункции> содержит те же права, что и роль Чтение<ИмяФункции>, а также:

  • Изменение, Редактирование;

  • Проведение, Отмена проведения, Интерактивное проведение, Интерактивная отмена проведения, Интерактивное изменение проведенных (для документов);

  • Управление итогами (для регистров).

• ДобавлениеИзменение<ИмяФункции> содержит те же права, что и роль Изменение<ИмяФункции>, а также:

  • Добавление, Интерактивное добавление;

  • Интерактивная пометка удаления, Интерактивное снятие пометки удаления.

Необходимо помнить, что для регистров, подчиненных регистратору, обычно не требуется назначать права на изменение

Право на Просмотр Подсистемы

Для каждой подсистемы верхнего уровня должна быть создана роль Подсистема<ИмяПодсистемы> (англ. Subsystem<SubsystemName>), дающая право на просмотр

Если интерфейс подсистемы организован так, что часть настроек и справочников отображаются в отдельной форме, то роль, дающая право на подсистему, должна включать права на просмотр этой формы (например, в УП(ERP) часть справочников в разделах командного интерфейса не вынесены и отображаются в форме, вызываемой командой «Настройки и справочники»).

Дополнительные права, не связанные с доступом к объектам

В случае если возникает необходимость давать пользователям какие-то дополнительные права, не связанные с доступом к объектам, нужно создавать роль <НаименованиеПрава>, не дающую доступ ни к одному объекту. При этом в наименовании не нужно использовать слово «Право».

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

Использование других механизмов, кроме проверки наличия роли (или какого-то права) при реализации дополнительных прав пользователя, не допускается.

Пример:
Правильно ОтклонениеОтУсловийЗакупок
Неправильно ПравоСозданияВыпускПродукцииБезЗаказа

Права для внешних пользователей

Роли, предназначенные исключительно для предоставления прав доступа внешним пользователям (представленным в программе одним из объектов, например, элементами справочников Сотрудники, Партнеры, Физические лица и др.), следует называть с определенным префиксом.

Например, префикс Самообслуживание для доступа к рабочему месту по самообслуживанию клиентов в торговом решении:

• СамообслуживаниеОформлениеПретензий, синоним Самообслуживание: оформление претензий

• СамообслуживаниеПросмотрОтчетаСостояниеВыполненияЗаказа, синоним Самообслуживание: просмотр отчета «Состояние выполнения заказа»

• СамообслуживаниеДобавлениеИзменениеКонтрагентов, синоним Самообслуживание: добавление и изменение контрагентов

Права к устаревшим объектам

Устаревшие объекты метаданных с префиксом Удалить должны быть исключены из всех ролей, кроме ролей ПолныеПрава или АдминистраторСистемы.

Роли в расширениях конфигурации

При разработке расширений конфигурации не рекомендуется заимствовать и изменять роли АдминистраторСистемы и ПолныеПрава. Вместо этого необходимо добавить в расширение собственные роли по следующему принципу.

В простейшем случае, если права на все объекты расширения одинаковы для всех категорий пользователей, то создать одну роль с указанным именем, настроить в ней необходимые права на объекты расширения и включить ее в основные роли расширения:

• <ПрефиксРасширения>ОбщиеПрава

Если права на объекты расширения различаются для администратора и пользователей, то создать две роли с именами:

• <ПрефиксРасширения>ПолныеПрава (включить в основные роли расширения)

• <ПрефиксРасширения>БазовыеПрава

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

• <ПрефиксРасширения>ПолныеПрава (включить в основные роли расширения)

• <ПрефиксРасширения>БазовыеПрава

• <ПрефиксРасширения>БазовыеПраваВнешнихПользователей

Профили в расширениях конфигурации

В конфигурациях на базе Библиотеки стандартных подсистем  роли расширений из пп. 6.1-6.3 автоматически включаются в профили групп доступа при установке расширений в информационную базу:

• Роль <ПрефиксРасширения>ОбщиеПрава включается во все профили с ролями  БазовыеПраваБСП, БазовыеПраваВнешнихПользователейБСП, ПолныеПрава.

• Роль <ПрефиксРасширения>БазовыеПрава включается в профили с ролью БазовыеПраваБСП.

• Роль <ПрефиксРасширения>БазовыеПраваВнешнихПользователей включается в профили с ролью БазовыеПраваВнешнихПользователейБСП.

• Роль <ПрефиксРасширения>ПолныеПрава включается в профили с ролью ПолныеПрава.

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

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

Привилегированный режим

Привилегированный режим позволяет

• выполнить операции с данными от лица пользователей, которым данные недоступны;

• ускорить работу, так как в привилегированном режиме не накладываются ограничения на доступ к данным.

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

• когда требуется с логической точки зрения отключить проверку прав;

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

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

Подробнее описано тут.

Привилегированный режим при проведении» и «Привилегированный режим при отмене проведения»

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

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

Привилегированный режим при получении

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

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

Пример: Есть параметризованная ФО ИспользоватьВалютуПриРасчетеСПерсоналом, которая параметризуется организацией. Если пользователь будет получать ее значение в контексте своих прав, то он не увидит поле «валюта» в документе, если у него нет ни одной организации, где применяется валютный учет.

Большое количество ролей в конфигурации (от нескольких десятков)

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

• при сильных различиях внешнего вида и функциональности формы в зависимости от наличия тех или иных ролей у пользователя – разрабатывать отдельные формы, специализированные под конкретный набор прав пользователя;

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

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

Проверка прав ролей с доступом к объектам

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

Например, неправильно:

Если РольДоступна("ДобавлениеИзменениеСтранМира") Тогда ...
Если РольДоступна("ПросмотрОтчетаПопулярныеСтраны") Тогда ...

правильно:

Если ПравоДоступа("Редактирование", Метаданные.Справочники.СтраныМира) Тогда ...
Если ПравоДоступа("Просмотр", Метаданные.Отчеты.ПопулярныеСтраны) Тогда ...

Проверка прав ролей без доступа к объектам

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

Пример проверки дополнительных ролей, без использования БСП:

Если РольДоступна(...) Или <ЭтоПолноправныйПользователь> Или ПривилегированныйРежим() Тогда ...

Либо аналогичная проверка с использованием БСП:

Если Пользователи.РолиДоступны(...) Тогда ...

ключевого слова "РАЗРЕШЕННЫЕ" в запросах

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

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

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

производительность при изменении значений параметров сеанса и функциональных опций

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

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

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