Как внедрить ролевую модель доступа: пошаговый план

Ролевая модель выглядит просто в описании и вызывает трудности при внедрении. Основная ошибка — начинать с составления списка ролей. Начинать нужно с другого.

Шаг 1. Перечислите действия, а не должности

Соблазн велик: взять штатное расписание и объявить каждую должность ролью. Так делать не стоит.

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

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

Список получится длинным, и это нормально: он основа всего дальнейшего.

Шаг 2. Сгруппируйте действия в роли

Теперь действия объединяются в наборы по принципу «что нужно человеку, чтобы выполнять свою работу целиком».

Ориентир по количеству: ролей должно быть заметно меньше, чем сотрудников. Если их сопоставимо, модель выродилась в поштучную выдачу прав с дополнительным слоем.

Обратная крайность тоже вредна: одна роль «сотрудник» с широкими правами формально соблюдает подход, но ничего не даёт.

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

Шаг 3. Проверьте каждую роль на риск

По каждой роли задайте один вопрос: что произойдёт, если учётная запись с этой ролью будет скомпрометирована?

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

Отдельно проверьте, не оказались ли административные возможности в роли, выдаваемой массово. Изменение настроек безопасности и управление составом организации не должны попадать в общий набор.

Шаг 4. Продумайте исключения заранее

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

Плохое решение — расширить базовую роль. Она раздувается ради одного случая и остаётся такой навсегда.

Хорошее — отдельная роль с ограниченным сроком. Замещение оформляется дополнительной ролью, которая снимается по окончании. Ключевое условие: срок задаётся при выдаче, а не «мы потом вспомним».

Шаг 5. Уберите старые индивидуальные права

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

В результате ролевая модель существует на бумаге, а фактический доступ определяется накопленными за годы разрешениями.

Переход считается завершённым, когда права выдаются только через роли.

Иерархия ролей

Когда ролей становится много, помогает наследование: старшая роль включает права младшей и добавляет свои.

Это упрощает сопровождение — общие права правятся в одном месте. Но есть риск: при глубокой иерархии перестаёт быть очевидно, какие права у человека в итоге. Разумная глубина — два-три уровня, не больше.

Регулярный пересмотр

Роли устаревают так же, как учётные записи. Обязанности меняются, появляются новые системы, старые выводятся из эксплуатации.

Пересмотр раз в квартал или полгода отвечает на вопросы:

• используются ли все заведённые роли;
• соответствуют ли права ролей текущим обязанностям;
• не появились ли персональные права в обход модели;
• у всех ли временных ролей истёк или продлён срок;
• кто обладает административными возможностями и обоснованно ли это.

Без такой процедуры модель постепенно вырождается: права накапливаются, роли перестают отражать реальность.

Типичные трудности

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

Неясная ответственность. Должно быть определено, кто утверждает состав роли и кто принимает решение по исключениям. Иначе решения принимает тот, к кому первым обратились.

Спешка. Попытка описать все роли за один заход обычно даёт неработающую модель. Разумнее начать с самых массовых должностей и добавлять остальные постепенно.

Как это устроено в Keydee

• Роли создаются под задачи компании и действуют в границах её организации.
• Набор прав роли настраивается в кабинете.
• Сотруднику назначаются одна или несколько ролей, итоговые права — их объединение.
• Права передаются приложениям в токене, поэтому проверка выполняется без дополнительных запросов.
• Системная роль отделена от пользовательских — административные возможности не смешиваются с обычными.
• Изменения фиксируются в журнале: видно, кто и когда менял состав ролей.

Короткий план

1. Перечислите действия, доступные в системах.
2. Сгруппируйте их в роли по реальным обязанностям.
3. Проверьте каждую роль вопросом о последствиях компрометации.
4. Заведите отдельные временные роли для исключений.
5. Снимите ранее выданные персональные права.
6. Назначьте регулярный пересмотр.