Перейти к основному содержимому

Разрешения и роли

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

Зачем три уровня?​

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

  • Доступна только для чтения большинству пользователей (наблюдатели видят инвентарь, но не могут редактировать)
  • Редактируема общей командой EA (участники могут обновлять любую карточку)
  • Управляема конкретным человеком, ответственным за данное приложение (Технический владелец приложения может редактировать и утверждать статус, даже не имея прав редактирования в масштабе всей организации)
  • Полностью подконтрольна администраторам (которые могут делать всё)

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

Уровень 1 — Роли приложения​

Роли приложения назначаются пользователям и действуют на всей платформе. Они определяются и управляются в разделе Администрирование → Пользователи и роли.

Каждая роль имеет JSON-набор разрешений. Встроенные роли:

РольКлючОбласть
АдминистраторadminПодстановочный знак {"*": true} — неограниченный доступ
Администратор BPMbpm_adminПолный BPM + полный инвентарь, без admin.*
УчастникmemberПолный инвентарь + редактирование BPM, без admin.*
НаблюдательviewerТолько просмотр во всех доменах

Пользовательские роли могут создаваться с любым сочетанием доступных ключей разрешений, сгруппированных по доменам: inventory.*, reports.*, bpm.*, ppm.*, grc.*, todos.*, admin.*.

Используйте роли приложения, когда нужно управлять тем, что определённая категория пользователей может делать на всей платформе.

Уровень 2 — Роли заинтересованных сторон​

Роли заинтересованных сторон назначаются пользователям для конкретных карточек. Каждый тип карточки определяет собственный набор ролей заинтересованных сторон (например, для карточек Application это «Technical Application Owner», «Business Application Owner», «Data Steward»). Они настраиваются в разделе Администрирование → Метамодель → [тип] → Роли заинтересованных сторон.

Каждое определение роли заинтересованной стороны содержит набор разрешений уровня карточки — таких как card.edit, card.approve, card.manage_relations. Когда пользователь добавляется в качестве заинтересованной стороны для карточки, он получает эти разрешения только для данной карточки.

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

Уровень 3 — Эффективные разрешения​

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

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

Результат — объединение обоих наборов. Пользователь, являющийся Наблюдателем (в масштабе платформы), но занимающий роль Технического владельца приложения для одной карточки, может редактировать эту карточку, поскольку роль заинтересованной стороны предоставляет card.edit, даже если роль Наблюдателя этого не делает.

Эффективные разрешения текущего пользователя для данной карточки доступны через GET /cards/{id}/effective-permissions и управляют всеми элементами редактирования/утверждения/удаления в интерфейсе.

Подстановочный знак администратора​

Роль Администратора использует {"*": true} в качестве набора разрешений. Это оценивается как «разрешить всё» — включая разрешения, которые не существовали на момент создания роли. Это означает, что новые модули и новые ключи разрешений автоматически становятся доступными для администраторов без каких-либо обновлений роли.

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

Структура ключей разрешений​

Все ключи разрешений следуют шаблону домен.действие:

  • inventory.view — чтение карточек
  • inventory.edit — обновление карточек
  • inventory.create — создание карточек
  • admin.metamodel — управление типами карточек и типами связей
  • admin.impersonate — временно действовать в качестве другой роли (см. Имитация роли)
  • bpm.approve — утверждение версий потока процессов BPMN
  • todos.view / todos.create / todos.manage — доступ к задачам и управление ими
  • risks.manage — создание и обновление записей реестра рисков

Полный список допустимых ключей находится в файле backend/app/core/permissions.py, который является единственным источником истины. Новые ключи разрешений должны быть добавлены туда, прежде чем они смогут быть предоставлены какой-либо роли.

Типичные сценарии​

Ограничить модуль для команды: Создайте пользовательскую роль только с разрешениями ppm.* и inventory.view. Назначьте её команде управления проектным портфелем. Они смогут работать в PPM, но не смогут редактировать основной инвентарь.

Предоставить права утверждения без прав редактирования: Назначьте бизнес-заинтересованной стороне роль «Business Application Owner» для конкретных карточек Application. Настройте эту роль так, чтобы она включала card.approval_status, но не card.edit. Они смогут утверждать карточки, заполненные командой EA, но не смогут изменять данные.

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

Тестирование с конкретной ролью: Пользователи с admin.impersonate могут переключаться на любую роль, отличную от администраторской, из меню пользователя (Просмотр от имени роли…), чтобы точно проверить, что эта роль видит и может делать — без создания отдельной тестовой учётной записи. Сеанс имитации существует только в JWT и не оставляет следов в базовой учётной записи. Подробнее см. Имитация роли.

Смотрите также​