Тот, кто отправил карточку, не может согласовать её сам
Разделение полномочий проверяет регулятор, и проверяет он не регламент, а экран. Поэтому права здесь — не «роль администратора» и не галочка «редактирование», а перечисляемая модель: объект, тип объекта, действие. Двенадцать типов объектов защиты, пять действий, двадцать семь именованных действий пользователя, права до отдельной вкладки карточки — и меню, которое собирается из выданных прав, а не показывается серым.
Разделение полномочий — на уровне отдельного действия
Обычная уязвимость самописных реестров: у сотрудника есть право «редактировать», и внутри него спрятано всё — и отправить, и согласовать, и закрыть. Один человек проводит запись по всему маршруту, а в истории остаётся одна фамилия. Здесь так не получится.
Два разных права вместо одного «редактировать»
«Отправить карточку на согласование» и «Согласовать карточку или отправить на доработку» — самостоятельные именованные действия. Их выдают разным сотрудникам. Сверх того кнопки согласующего вообще не появляются на экране, пока карточка не находится в статусе «На согласовании»: даже обладатель права не может согласовать то, что ему ещё не отправили.
| Этап карточки | Автор карточки | Согласующий |
|---|---|---|
| Создан | взять в работу, редактировать | кнопок согласования нет |
| В работе | редактировать, отправить на согласование | кнопок согласования нет |
| На согласовании | редактирование закрыто | согласовать или отправить на доработку |
| На доработке | редактировать, отправить повторно | кнопок согласования нет |
| Согласовано | отправить на согласование снова | кнопок согласования нет |
Возврат на доработку не проходит без комментария, а каждая смена этапа записывается в историю с автором и временем.
Модель разрешений: объект, тип объекта, действие
Разрешение — это тройка. Не «роль с описанием на словах», а набор строк, который выгружается и согласуется с владельцем процесса. Типов объектов защиты двенадцать, действий пять: чтение, запись, добавление, удаление, выполнение.
| Тип объекта защиты | Действия | Что этим разграничивают |
|---|---|---|
| Реестры | чтение, запись, добавление, удаление | кто вообще видит реестр и кто в нём заводит записи |
| Шаблоны | чтение, запись, добавление, удаление | кто меняет состав полей карточек для всех |
| Справочники | чтение, запись, добавление, удаление | кто добавляет значения, по которым потом собирается отчётность |
| Пункты меню | чтение | какие разделы вообще появятся у сотрудника |
| Представления | чтение | доступ к настраиваемым видам реестров |
| Действия | выполнение | 27 именованных действий жизненного цикла |
| Отчёты | выполнение | кто может выгрузить данные наружу |
| Риск — вкладки карточки | чтение | шесть вкладок выдаются по отдельности |
| Лимит — вкладки карточки | чтение | пять вкладок выдаются по отдельности |
| Нарушение — вкладки карточки | чтение | пять вкладок выдаются по отдельности |
| Обработка данных | чтение | доступ к журналам уведомлений и загрузок |
| Настройки приложения | чтение, запись, добавление, удаление | расписания задач, дашборды, статусная модель |
Двадцать семь именованных действий пользователя
Каждое действие ниже выдаётся отдельно. Это и есть материал для матрицы разделения полномочий: её не надо придумывать заново — достаточно решить, кому какие строки.
Движение карточки по маршруту 4 действия
- Взять карточку в работу
- Отправить карточку на согласование
- Согласовать карточку или отправить на доработку
- Восстановить карточку
Закрытие и подтверждение по существу 9 действий
- Переоценить риск
- Подтвердить устранение нарушения
- Закрыть манипулирование
- Завершить задачу
- Завершить проверку
- Пересмотреть конфликт интересов
- Подтвердить исключение конфликта интересов
- Переоткрыть конфликт интересов
- Подтвердить отправку ответа на запрос или предписание
Административные дела 2 действия
- Подтвердить рассмотрение дела
- Подтвердить вынесение решения
Отчётность и выгрузка наружу 8 действий
- Отправить на первую линию
- Отправить на вторую линию
- Подтвердить отправку в надзорный орган
- Переделать отчет
- Сформировать отчет по реестру предписаний и неофициальных запросов
- Сформировать отчет контролера
- Сформировать отчет о существенных событиях по регуляторным рискам
- Автоматическая фильтрация по существенным регуляторным рискам
Представления и загрузка данных 4 действия
- Настроить представление
- Удалить или очистить представление
- Импорт данных о манипулировании
- Импорт запросов и предписаний
Права до отдельной вкладки карточки
Гранулярность до раздела недостаточна там, где в одной карточке лежат и описание риска, и связанные инциденты, и переписка. Вкладка карточки — самостоятельный объект защиты с правом на чтение.
| Карточка | Вкладки, выдаваемые отдельно |
|---|---|
| Риск | содержание · нарушения · корректирующие мероприятия · инциденты · история переоценки · комментарии |
| Лимит | содержание · корректирующие мероприятия · инциденты · история переоценки · комментарии |
| Нарушение | содержание · мероприятия · инциденты · история изменений · комментарии |
Для остальных карточек отдельные перечни вкладок в продукте не заведены — состав вкладок там общий для тех, у кого есть доступ к реестру. Пишем как есть.
Меню собирается из прав — попробуйте сами
Пункт меню отображается только при наличии права на чтение соответствующего объекта. Узел, у которого не осталось доступных потомков, из дерева выбрасывается целиком: сотрудник не видит серых разделов, по которым бесполезно кликать. Снимите и поставьте права — дерево слева пересоберётся.
Сборка дерева навигации по выданным правам
Отметьте право на чтение — и посмотрите, что появится в меню.
Выданные права на чтение
Что увидит сотрудник в меню
Прав не выдано — меню пустое. Сотрудник видит экран отказа в доступе, а не список недоступных разделов.
Демонстрация механизма на части объектов. В продукте так же собираются все девять разделов верхнего уровня.
Внешнему проверяющему — срез, а не учётная запись во всей системе
Когда аудитору или проверяющему нужно показать данные, обычно происходит одно из двух: либо ему выгружают файл, который потом живёт своей жизнью, либо заводят учётную запись «с ограничениями», про которые все забывают. В продукте для этого заведены отдельные объекты: реестр регуляторных рисков для внешнего проверяющего и реестр регуляторных рисков для внешнего пользователя — оба только на чтение.
- Это отдельные реестры, а не фильтр над общим: «забыть применить» его нельзя.
- Доступ выдаётся правом на чтение конкретного объекта, а не набором исключений.
- Остальные разделы у такого пользователя не отображаются вовсе — меню собирается из его прав.
Роли и подразделения: ролевая модель — ваша
Разрешения приходят из внешнего модуля безопасности, поэтому роли вы задаёте под свою оргструктуру, а не подгоняете структуру под продукт. Ниже — ориентир, от которого удобно отталкиваться: какие наборы прав обычно ложатся на какие подразделения.
| Кто в вашей организации | Что обычно выдаётся | Чего обычно не выдаётся |
|---|---|---|
| Специалист департамента внутреннего контроля | ведение реестров, «Отправить на согласование», настройка своих представлений | «Согласовать или отправить на доработку», подтверждение отправки наружу |
| Руководитель подразделения внутреннего контроля, контролёр | «Согласовать или отправить на доработку», формирование отчётов, подтверждение отправки в надзорный орган | права заводить и вести карточки, которые он же согласует |
| Вторая линия контроля, риск-подразделение | «Отправить на вторую линию», чтение реестров и вкладок по существу | права первой линии по тем же отчётам |
| Смежное бизнес-подразделение | чтение отдельных реестров и отдельных вкладок карточки | комментарии, инциденты, журналы, настройки |
| Внешний проверяющий, аудитор | чтение отдельного реестра «только чтение» | всё остальное — разделы просто не отображаются |
| Администратор системы | настройки приложения: задачи по расписанию, дашборды, статусная модель | действия жизненного цикла по существу — согласование и отправка наружу |
Таблица — отправная точка для обсуждения: набор ролей и матрица прав определяются вашей организацией и настраиваются во внешнем модуле безопасности. Продукт свою ролевую модель не навязывает.
Что это даёт ИТ-директору
- Аутентификация вынесена наружу: рабочий режим — OpenID Connect через Keycloak, с проверкой токена по набору ключей провайдера. Отдельного хранилища паролей продукт не заводит.
- Разрешения приходят по REST из внешнего модуля безопасности вместе с идентификатором сотрудника. Управление доступом остаётся в вашем контуре управления доступом, а не расползается по прикладным системам.
- Модель прав перечисляема: 12 типов объектов, 5 действий, 27 именованных действий пользователя, вкладки карточек. Матрицу можно выгрузить и согласовать, а не пересказывать.
- События безопасности журналируются; экран отказа в доступе — отдельная страница, а не «пустой раздел без объяснений». Таймаут сессии — 60 минут.
- Есть встроенный режим аутентификации по файлу пользователей — он предназначен для разработки и на продуктивном контуре не используется. Пишем прямо, чтобы это не всплыло на аудите.
Проверить разделение полномочий на стенде
Заводим двух пользователей с разными правами и показываем, что видит каждый: меню, кнопки на карточке, доступные вкладки и реестр «только чтение».