#std689¶

Настройка ролей и прав доступа¶

Действует для конфигураций УП (ERP), УТ 11 и входящих в них библиотек. Для других конфигураций рекомендуется к применению.

1.¶

Общие положения.

1.1.¶

Стройте роли атомарно: одна роль должна покрывать одну элементарную функцию.

Из атомарных ролей формируйте профили пользователей. Профили назначайте пользователям средствами БСП.

1.2.¶

Роли ПолныеПрава и АдминистраторСистемы обеспечивают максимальный доступ. Подробности: #std488: Стандартные роли.

1.3.¶

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

После добавления нового объекта проверяйте это в роли ПолныеПрава.

1.4.¶

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

1.5.¶

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

1.6.¶

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

1.7.¶

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

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

Проверки¶

_{#v8cs:document-post-in-privileged-mode}

1.8.¶

Для функциональных опций обычно включайте привилегированный режим получения.

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

Проверки¶

_{#v8cs:functional-option-privileged-get-mode}

1.9.¶

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

1.10.¶

Для неконфиденциальных и общедоступных данных права чтения включайте в:

• БазовыеПрава<ИмяБиблиотеки>;
• БазовыеПраваВнешнихПользователей<ИмяБиблиотеки> (если есть внешние пользователи).

1.11.¶

Одна роль не должна объединять права на объекты разных библиотек и разных подсистем. Подробности: #std668: Разработка ролей в библиотеках.

2.¶

Правила создания ролей к элементарным функциям.

2.1.¶

При проектировании доступа сначала объединяйте объекты в элементарные функции.

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

2.2.¶

Если есть сомнение, относятся ли два объекта к одной функции, разделяйте их.

2.3.¶

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

2.4.¶

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

3.¶

Ссылочные объекты и регистры.

3.1.¶

Для функций со ссылочными объектами и независимыми регистрами сведений обычно создавайте две роли:

• Чтение<ИмяФункции> (Read<FeatureName>);
• ДобавлениеИзменение<ИмяФункции> или Изменение<ИмяФункции>.

Роль изменения должна включать права роли чтения плюс права изменения.

3.2.¶

Для регистров, подчиненных регистратору, права изменения обычно не назначают (см. п. 1.7).

4.¶

Журналы документов.

4.1.¶

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

4.2.¶

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

5.¶

Константы.

5.1.¶

Если константу должен менять только администратор, права изменения должны быть только у ПолныеПрава и/или АдминистраторСистемы.

5.2.¶

Если константу может менять пользователь, добавляйте права в существующую настроечную роль или создавайте отдельную роль Изменение<ИмяКонстанты>.

5.3.¶

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

5.4.¶

Для конфиденциальных констант создавайте отдельную роль чтения, если это действительно нужно.

6.¶

Подсистемы, отображаемые в главном командном интерфейсе.

6.1.¶

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

6.2.¶

Если часть функций подсистемы вынесена в отдельную форму (например, «Настройки и справочники»), роль подсистемы должна включать права просмотра этой формы.

7.¶

Отчеты.

7.1.¶

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

7.2.¶

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

7.3.¶

Если отчет использует данные из нескольких элементарных функций, создавайте отдельную роль ПросмотрОтчета<ИмяОтчета>.

7.4.¶

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

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

8.¶

Обработки и общие формы.

8.1.¶

Для каждой обработки-рабочего места (есть отдельная команда в интерфейсе) создавайте роль ИспользованиеОбработки<ИмяОбработки> (UseDataProcessor<DataProcessorName>).

8.2.¶

Права на вспомогательные обработки и обработки с общим служебным кодом назначайте в роли БазовыеПрава<ИмяБиблиотеки>.

8.3.¶

Права к обработкам только для администратора назначайте только через ПолныеПрава и/или АдминистраторСистемы.

8.4.¶

Те же правила применяются к общим формам. Для общих форм используйте роль ИспользованиеОбщейФормы<ИмяОбщейФормы>.

8.5.¶

Исключения из этого подхода допустимы только в явно обоснованных сценариях проектирования интерфейса (см. п. 6.2).

9.¶

Команды.

9.1.¶

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

Права на печатные команды в общих обработках назначайте базовым ролям библиотеки.

9.2.¶

Для команды, которая изменяет данные, право просмотра назначайте роли, дающей право изменения соответствующих объектов.

10.¶

Права, не связанные с доступом к объектам.

10.1.¶

Если нужно выдать дополнительное прикладное право, создавайте отдельную роль <НаименованиеПрава>, которая не дает доступ к объектам метаданных.

В имени роли не используйте слово Право.

10.2.¶

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

Для проверки используйте Пользователи.РолиДоступны.

10.3.¶

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

11.¶

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

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

Например:

• СамообслуживаниеОформлениеПретензий;
• СамообслуживаниеПросмотрОтчетаСостояниеВыполненияЗаказа;
• СамообслуживаниеДобавлениеИзменениеКонтрагентов.

12.¶

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

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

См. также¶

• #std488: Стандартные роли
• #std485: Использование привилегированного режима
• #std534: Удаление устаревших объектов метаданных из конфигурации
• #std658: Эффективные условия запросов
• #std668: Разработка ролей в библиотеках
• #std705: Отнесение библиотечных объектов к подсистемам
• #std737: Проверка прав доступа

Проверки¶

_{#v8cs:using-isinrole}

_{#acc:226 #acc:227 #acc:228 #acc:229 #acc:232 #acc:233 #acc:234 #acc:290 #acc:291 #acc:336 #acc:359 #acc:360 #acc:375 #acc:419 #acc:420 #acc:421 #acc:422 #acc:423 #acc:424 #acc:442 #acc:443 #acc:507 #acc:508 #acc:510 #acc:511 #acc:512 #acc:513 #acc:541 #acc:1375}

Источник¶

https://its.1c.ru/db/v8std#content:689