Ролевая модель и RACI

Около 4 мин

Ролевая модель и RACI

Раздел отвечает на два вопроса архитектурного ревью: как в системе устроено разграничение доступа (RBAC) и кто в организации отвечает за каждый процесс работы с ней (RACI).

Как складываются права

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

Уровень	Настройка	Кто задаёт	Что определяет
1	Право участника в команде	Администратор команды	Потолок возможностей: администратор, чтение и изменение, только чтение, просмотр
2	Группы прав	Администратор команды	Конкретные разрешённые действия с объектами: папками, реестром, справочниками, оргструктурой
3	Ограничения папок и страниц вики	Администратор команды или владелец папки	Закрытые области: правила «разрешить» и «запретить» с наследованием вниз по дереву

Поверх этих трёх уровней действуют ещё два ограничения, не зависящих от настроек прав:

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

Полная матрица привилегий

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

Право участника в команде

Право	Что даёт	Ограничения
Администратор	Полные права в команде: участники, группы прав, настройки, все материалы	—
Чтение и изменение	Правка материалов команды в объёме выданных групп прав	Обязательное условие для правки чужих моделей и выдачи доступов
Только чтение	Чтение материалов команды, полный контроль над своими моделями	Чужие модели — только на просмотр
Просмотр	Просмотровое рабочее место: чтение того, к чему открыт доступ	Не включается в группы прав; любой выданный доступ понижается до просмотра

Право «Просмотр» обойти нельзя

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

Группы прав

Привилегии выдаются не человеку напрямую, а группе; участник получает права, входя в группу. При создании команды заводятся три группы по умолчанию — «Администраторы», «Чтение и редактирование», «Только чтение». Их состав можно менять, можно создавать собственные группы. Участник может входить в несколько групп — права суммируются.

Ограничение доступа к папкам и вики

Настройка	Варианты
Кому выдаётся	Всей команде, отдельному участнику, группе прав
Что разрешается	Чтение, изменение, управление доступом, полный доступ
Тип правила	Разрешение или запрет; запрет всегда сильнее разрешения
Наследование	По умолчанию распространяется на вложенные папки и страницы, можно отключить

Решение принимается по порядку: проверка членства в команде → запрет → разрешение → отказ. Чтение, изменение и управление доступом проверяются независимо друг от друга.

Типовые роли и их настройка

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

Организационная роль	Право в команде	Группа прав	Типовые задачи
Методолог, владелец методологии	Администратор	Администраторы	Ведёт структуру реестра, справочники, элементы архитектуры, роли, настройки команды
Бизнес-аналитик	Чтение и изменение	Чтение и редактирование	Моделирует процессы, заполняет карточки, отправляет модели на согласование
Владелец процесса	Чтение и изменение	Чтение и редактирование	Отвечает за содержание процесса, инициирует изменения, принимает результат
Согласующий	Только чтение или чтение и изменение	Только чтение	Рассматривает модели и выносит решение по согласованию
Читатель, исполнитель	Просмотр или только чтение	Только чтение (для «Просмотра» группы не назначаются)	Читает утверждённые модели и карточки процессов
Администратор команды	Администратор	Администраторы	Управляет участниками, группами прав, ограничениями папок
Администратор системы	Не требуется право в команде	—	Разворачивает и обновляет систему, отвечает за конфигурацию и резервное копирование
Служба информационной безопасности	Не требуется право в команде	—	Настраивает и контролирует аудит-логирование, проверяет доступы

Администратор системы — не администратор команды

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

Кто может выдавать доступы

Чтобы выдать доступ к чужой модели или папке, нужно выполнить все три условия:

Право в команде — «Чтение и изменение» либо «Администратор».
Привилегия на изменение моделей команды.
Право на изменение папки, в которой лежит модель, — если папка ограничена.

Автор своей модели раздаёт доступ к ней сам, в пределах собственных привилегий. Проверка стоит на самом действии, а не только в интерфейсе: обойти её через REST API или интеграции нельзя.

Матрица RACI по процессам

Матрица описывает распределение ответственности при типовом внедрении. R — исполняет, A — отвечает за результат, C — консультирует, I — информируется.

Процесс	Владелец процесса	Бизнес-аналитик	Методолог	Согласующий	Администратор команды	Администратор системы	Служба ИБ
Создание и правка модели процесса	A	R	C	—	—	—	—
Отправка модели на согласование	A	R	I	I	—	—	—
Согласование модели	C	I	I	R	—	—	—
Публикация модели (статус «Готов»)	A	R	C	I	—	—	—
Архивирование устаревшей модели	A	R	C	—	—	—	—
Ведение карточки процесса в реестре	A	R	C	—	—	—	—
Настройка структуры реестра, статусов, полей	C	C	A/R	—	I	—	—
Ведение справочников, ролей, элементов архитектуры	C	C	A/R	—	I	—	—
Ведение организационной структуры	C	R	A	—	I	—	—
Приглашение участников в команду	I	I	C	—	A/R	I	I
Назначение прав и групп	I	I	C	—	A/R	I	C
Ограничение доступа к папкам и вики	C	I	C	—	A/R	—	C
Блокировка и удаление учётной записи	I	—	—	—	R	A	C
Учёт лицензионных мест	—	—	I	—	R	A	I
Установка и обновление системы	—	—	I	—	I	A/R	C
Настройка аутентификации и интеграции с IdP	—	—	—	—	I	R	A
Настройка и контроль аудит-логирования	—	—	—	—	I	R	A
Резервное копирование и восстановление	—	—	—	—	I	A/R	C
Мониторинг и реагирование на инциденты	—	—	—	—	I	A/R	C

Матрица — отправная точка

Распределение зависит от того, как в организации устроено владение процессами и кто отвечает за методологию. Согласуйте матрицу с владельцами процессов до защиты проекта: на ревью почти всегда спрашивают, кто именно принимает решение о публикации модели и кто отвечает за выдачу прав.

Разделение обязанностей

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

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