Что такое RBAC: ролевая модель доступа

Ролевая модель доступа (Role-Based Access Control, RBAC) — подход, при котором права выдаются не напрямую пользователю, а роли, а пользователь получает права через назначенную ему роль.

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

Как это работает

Схема состоит из трёх уровней:

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

Когда сотрудник переходит на другую должность, ему меняют роль. Все права пересчитываются автоматически, потому что они никогда не были привязаны к нему лично.

Почему поштучная выдача прав не работает

Схема «выдадим права конкретному человеку» кажется гибкой и на маленькой команде даже удобна. Проблемы начинаются с ростом.

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

Никто не знает, у кого что есть. Ответ на вопрос «кто имеет доступ к финансовым данным» требует обхода всех учётных записей вручную.

Новый сотрудник настраивается по образцу коллеги. Права копируются вместе с накопившимися излишками, и цикл повторяется.

Аудит невозможен. Проверяющий спрашивает, кто может изменять платёжные реквизиты. Внятного ответа нет.

RBAC решает это тем, что права описаны один раз, в понятных терминах, и проверяются на уровне ролей, а не людей.

Принцип минимальных привилегий

Главный смысл ролевой модели — не удобство администратора, а ограничение ущерба.

Учётная запись с правами, которые сотруднику не нужны, — это расширенная поверхность атаки. Если она будет скомпрометирована, злоумышленник получит ровно те возможности, которые были выданы «на всякий случай».

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

RBAC и другие модели

Модель	На чём основано решение	Когда уместна
RBAC	Роль пользователя	Понятная оргструктура, стабильные должности
ABAC	Атрибуты: отдел, устройство, время, местоположение	Нужен контекст: «только из офиса», «только в рабочие часы»
ACL	Список доступа у конкретного объекта	Файлы и документы с индивидуальными правами

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

Начинать имеет смысл с RBAC: он проще в проектировании и покрывает большинство задач. Усложнять стоит тогда, когда простая модель перестаёт справляться, а не заранее.

Ошибки проектирования ролей

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

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

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

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

Административные права в общей роли. Возможность менять настройки безопасности не должна попадать в роль, которую выдают массово.

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

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

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

С чего начать

1. Опишите, какие действия вообще возможны в ваших системах. Не должности, а действия.
2. Сгруппируйте их в роли по принципу «что нужно человеку, чтобы делать свою работу».
3. Проверьте каждую роль вопросом: что произойдёт, если учётная запись с этой ролью будет скомпрометирована.
4. Назначьте роли и уберите ранее выданные индивидуальные права — иначе старая схема продолжит существовать параллельно.
5. Заведите регулярный пересмотр: раз в квартал или полгода.