Ролевая модель доступа: как построить и проверить матрицу ролей
Ролевая модель доступа связывает рабочие обязанности с разрешениями в информационных системах. Сотруднику назначают роль, а роль определяет, какие действия ему доступны. Чтобы такая модель работала в компании, для каждого набора прав нужно определить владельца, условия назначения, ограничения и порядок отзыва.
В модели RBAC пользователи получают разрешения через роли; модель может включать иерархию и ограничения совместимости. Это базовая конструкция, описанная в материалах NIST о RBAC. Практический порядок ниже — редакционная методика SecRadar для подготовки проекта управления доступом. Пример вымышленный: его нужно адаптировать к своим процессам и приложениям.
С чего начать: процесс, а затем список групп
Возьмите один понятный процесс, например подготовку и согласование платежей. Определите, кто создаёт документ, кто проверяет реквизиты, кто утверждает операцию и кто только читает отчёты. Затем сопоставьте эти действия с реальными разрешениями в учётной системе.
Название должности само по себе недостаточно. Два бухгалтера могут работать с разными юридическими лицами; руководитель отдела не обязательно должен проводить платёж; временный заместитель может получить часть полномочий на неделю. Эти различия нужно отразить до массового назначения ролей.
Полезный результат первого этапа — небольшой согласованный перечень рабочих действий. Перечень групп AD пригодится для технического сопоставления, но не объяснит, зачем сотруднику нужна каждая группа.
Что входит в матрицу ролей
Удобно вести два связанных представления: состав роли и правила её назначения. Это позволяет изменить техническое разрешение, не переписывая весь кадровый процесс.
Таблицу можно прокрутить вправо.
| Поле | Что записать | Пример |
|---|---|---|
| Идентификатор роли | Стабильный код, который переживёт переименование | FIN_PAY_PREPARE |
| Рабочая задача | Какую операцию выполняет сотрудник | Подготовка платёжных документов |
| Владелец роли | Кто подтверждает необходимость и состав прав | Владелец процесса платежей |
| Система и область данных | Где действует разрешение и на какие данные | Учётная система, юридическое лицо А |
| Разрешения | Конкретные действия или прикладные роли | Создать черновик, исправить черновик, отправить на проверку |
| Условия назначения | Какие атрибуты или согласование нужны | Сотрудник расчётной группы, действующее трудоустройство |
| Ограничения | С чем роль несовместима | Нельзя одновременно утверждать собственный платёж |
| Срок и отзыв | Когда право прекращает действовать | При переводе из группы; для замещения — в указанную дату |
| Основание | Где зафиксировано решение | Заявка или утверждённая версия матрицы |
Не смешивайте должность, роль и учётную запись в одной колонке. Одна роль может включать разрешения нескольких приложений, а у человека может быть несколько учётных записей. Связь между ними должна быть проверяемой.
Пример матрицы: подготовка и утверждение платежа
Таблицу можно прокрутить вправо.
| Действие | Подготовка платежа | Утверждение платежа | Просмотр отчётов |
|---|---|---|---|
| Создать черновик | Да | Нет в этом примере | Нет |
| Исправить черновик | Да, до отправки | Нет в этом примере | Нет |
| Утвердить платёж | Нет | Да, с ограничениями процесса | Нет |
| Просмотреть результат | Да, в своей области | Да, в своей области | Да, в согласованной области |
Это пример проектного решения, а не универсальные требования к бухгалтерской системе. Если приложение не умеет различать автора и утверждающего конкретного платежа, одно только разделение групп пользователей не обеспечит такой контроль.
Здесь полезно разделить назначения ролей и действия с конкретным платежом. Статические ограничения SoD в RBAC ограничивают сочетания назначенных ролей, динамические — их одновременную активацию в сеансе. Проверка «может ли автор утвердить собственный платёж» дополнительно требует контроля на уровне приложения: её нельзя обещать только на основании наличия SoD в IDM. NIST: структура RBAC и SoD.
Как построить модель за семь шагов
- Выберите границы первого этапа. Зафиксируйте подразделение, системы и процессы. Укажите, какие технические и внешние учётные записи пока рассматриваются отдельно.
- Соберите фактические права. Выгрузите пользователей, группы, прямые назначения, вложенные группы и прикладные разрешения. Сохраните дату выгрузки: это снимок состояния, а не вечная истина.
- Найдите владельцев. Для каждой учётной записи установите человека или ответственного за сервис. Для роли определите бизнес-владельца. Неразобранные записи вынесите в отдельный список.
- Согласуйте нужные действия. Попросите владельца процесса подтвердить, какие операции требуются для работы. Исторически выданный доступ не должен автоматически становиться эталонным.
- Соберите роли и ограничения. Задайте состав, область данных, несовместимые сочетания, правила назначения и исключения.
- Проверьте кадровые изменения. Пройдите приём, перевод, замещение и увольнение. Проверьте результат в целевых приложениях, включая повторное появление сотрудника в кадровом источнике.
- Назначьте порядок пересмотра. Определите ответственного, события для внеплановой проверки и срок действия исключений. Сохраняйте решения вместе с версией модели.
Начинать стоит с участка, на котором владелец процесса может проверить каждое разрешение. Размер первой группы выбирают по возможности провести такую проверку, а не по универсальной норме количества сотрудников.
Где помогает role mining
Role mining ищет повторяющиеся сочетания фактических доступов и предлагает кандидатов в роли. Он полезен, когда вручную трудно разобрать много назначений. Но повторяемость доступа ещё не означает его обоснованность: одинаковая лишняя группа у всего отдела тоже образует устойчивый шаблон.
Поэтому сначала изучают предложения, затем согласуют состав с владельцем процесса и только после этого меняют назначения. Такой управляемый порядок есть, например, в документации Platform V IDM 3.3.1: анализ формирует предложения бизнес-ролей, администратор их уточняет и принимает решение о миграции. Руководство: анализ ролей.
Перед внедрением проверьте именно реализацию выбранного продукта: какие данные он анализирует, как учитывает исключения, можно ли предварительно увидеть изменения и вернуть прежние назначения. Наличие в описании слов «ИИ» или «автоматизация» не отвечает на эти вопросы.
Перевод сотрудника: самая полезная проверка модели
Предположим, сотрудник перешёл из подготовки платежей в отчётность. Недостаточно добавить ему новую роль. Нужно определить, какие старые права отозвать, какие временно оставить для передачи дел и когда закончится исключение.
В протокол проверки включите четыре состояния:
- до перевода — фактические права во всех выбранных системах;
- после обработки кадрового события — назначенные и отозванные роли;
- после выполнения операций коннекторов — фактические права в приложениях;
- после окончания передачи дел — отсутствие временно сохранённых разрешений.
Так можно обнаружить ситуацию, когда IDM уже показывает правильную модель, а целевая система ещё не приняла отзыв. Отдельно испытайте недоступность коннектора: где появляется ошибка, кто её получает и как операция повторяется.
Как учитывать исключения и временный доступ
У исключения должны быть причина, владелец решения, ограниченная область и дата окончания. Запись «по просьбе руководителя» без срока быстро превращается в постоянное право, которое никто не помнит.
Для замещения проверьте начало и окончание доступа, возможность досрочного отзыва и поведение при пересечении нескольких оснований. Если роль одновременно назначена по должности и по замещению, окончание замещения не обязательно должно удалить законное назначение по должности. Ожидаемый результат нужно описать заранее.
Сервисные учётные записи проверяйте отдельно от сотрудников. Для них важны владелец сервиса, назначение, зависимости и порядок вывода из эксплуатации. Увольнение ответственного человека должно запускать разбор владения, а не бесконтрольное удаление рабочей интеграции.
Как понять, что модель готова к автоматизации
Проверьте, можете ли вы ответить для каждого назначения: кому выдали право, зачем, кто его подтвердил и при каком событии оно будет отозвано. Затем выполните сценарии на тестовых записях.
Для протокола пригодятся доля записей с установленным владельцем, число бессрочных исключений, количество расхождений модели и фактических прав, время исполнения отзыва и число операций с ошибками. Целевые значения определяет организация с учётом своего риска и инфраструктуры; приведённый список не задаёт обязательных нормативов.
Описание работы класса есть в обзоре IDM/IGA. Реализации функций и их ограничения смотрите в сравнении IDM-решений, а различия базовых подходов — в словаре управления доступом.
Частые вопросы
Можно ли построить рол��вую модель без IDM?
Можно подготовить и согласовать модель в таблице. При этом выдачу, отзыв, сверку и контроль сроков придётся организовать другими средствами. IDM выбирают с учётом того, какие процессы требуется автоматизировать и с какими приложениями работать.
Должна ли каждой должности соответствовать одна роль?
Это необязательное правило. Должность может участвовать в условии назначения, но доступ также зависит от рабочей задачи, области данных, проекта и временного замещения. Важно сохранить понятное основание каждого разрешения.
Нужно ли начинать с полного удаления всех лишних прав?
Сначала подтвердите, какие права действительно лишние и какие зависимости есть у процесса. Изменения лучше проверять на ограниченном участке с владельцем системы и согласованным способом восстановления. Массовое удаление по одному результату автоматического анализа — плохой способ проверить корректность модели.