Роли — минимальные привилегии, свои роли под префиксом

Директивный

Правило

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

Зачем

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

// Жёсткая привязка к имени роли: право «Проведение» может давать
// и другая роль профиля — пользователь получит ложный отказ.
Если РольДоступна("КИ_МенеджерПродаж") Тогда
    ПровестиДокумент();
КонецЕсли;

// Проверяем само право на объект, независимо от того, какой ролью оно пришло.
Если ПравоДоступа("Проведение", Метаданные.Документы.ЗаказКлиента) Тогда
    ПровестиДокумент();
КонецЕсли;

Право конкретной роли (для аудита, без создания тестового пользователя) проверяется третьим параметром: ПравоДоступа(Право, ОбъектМетаданных, МетаданныеРоли).

Аудит: кто что может на самом деле

«Минимальные привилегии» без периодической проверки деградируют — права накапливаются с задачами и не отзываются. Что проверять при аудите:

Право → роли. Какие роли дают опасное право (например, ТонкийКлиент, Администрирование, Проведение по ключевым документам) — перебором ролей через ПравоДоступа(Право, ОбъектМетаданных, МетаданныеРоли), без создания тестовых пользователей.
Пользователь → профили. В БСП связка «пользователь → профиль» живёт в двух местах, и это классическая ловушка отчётов по правам: обычные группы доступа перечисляют пользователей в табличной части «Пользователи», а персональные группы хранят пользователя в реквизите шапки Пользователь. Выборка только из табчасти молча теряет персональные назначения — в отчёте пользователь выглядит «без профиля», хотя доступ у него есть.
Административные профили. Отдельно выделять профили, содержащие роли ПолныеПрава/АдминистраторСистемы, и сверять их состав с коротким утверждённым списком (см. инвентаризацию доступов).

Когда не применять

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

См. также

Секреты в безопасном хранилище; техпользователь с минимальными правами
Паттерны работы с БСП — профили групп доступа, персональные группы.
Грабли расширений (CFE) — роль расширения и заимствование объектов.