Wiki · Веб-разработка

Ролевая модель доступа

5 мин чтенияАвтор: Дмитрий КолесниковСоавторы: Евгений Баев

Ролевая модель доступа (RBAC, Role-Based Access Control) – это способ раздавать права в системе через роли, а не каждому человеку отдельно. Пользователю назначают роль, например «менеджер» или «клиент», и он видит только положенные ей разделы и данные и делает только разрешённые действия.

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

Пользователь, роль, права и матрица прав

Сущностей три: пользователь, роль и права. Права привязаны к роли, роль к пользователю. Когда меняются правила, правят одну роль, и изменение получают все, у кого она есть. Формальную модель RBAC описали Дэвид Феррайоло и Рик Кун из NIST в 1992 году, а в 2004-м её приняли как американский стандарт ANSI/INCITS 359.

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

Для каждой роли отвечают на три вопроса:

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

Второй вопрос забывают чаще всего. Роль «Магазин» может видеть раздел заявок, но только заявки своей точки. Это ограничение по данным, а не по меню.

Итог проектирования удобно свести в матрицу прав. В упрощённом виде для личного кабинета она выглядит так:

Раздел	Клиент	Менеджер	Администратор
Заявки	свои: смотреть, создавать	своих клиентов: все действия	все
Счета и акты	свои: смотреть, скачивать	своих клиентов: создавать	все
Пользователи	нет доступа	нет доступа	создавать, блокировать
Настройки	нет доступа	нет доступа	все

Пять шагов проектирования ролей

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

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

Роли в портале поставщика персонала и в кабинете IT-компании

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

В личном кабинете для клиентов IT-компании ролей три. Пользователь редактирует профиль и видит только разрешённые данные своей организации. Администратор клиента видит все данные своей организации, настраивает права и отправляет запросы на создание, блокировку и удаление пользователей. Администратор со стороны компании видит все организации, меняет типы пользователей и права, а сам в списках пользователей не отображается.

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

Когда ролей не хватает: атрибутная модель ABAC

У ролей есть предел. Если доступ зависит от многих условий, например региона, суммы сделки и статуса договора, ролей становится столько же, сколько сочетаний. Для таких систем есть атрибутная модель ABAC: решение о доступе принимают по свойствам пользователя, объекта и обстоятельств, её описывает руководство NIST SP 800-162. В порталах и кабинетах модели обычно сочетают: роль задаёт разделы и действия, а правило «только своя организация» ограничивает данные.

Роли в 1С-Битрикс и Битрикс24

В CMS 1С-Битрикс права назначают группам пользователей. Если человек состоит в нескольких группах, его права складываются из максимальных прав всех этих групп, поэтому одна лишняя группа может открыть доступ, который в других закрыт.

В Битрикс24 роли создают в разделе «Права доступа» и назначают отделам или отдельным сотрудникам. В CRM для роли настраивают чтение, добавление, изменение, удаление, экспорт и импорт, а для чтения ещё и охват: все записи, свои или своего отдела. Справка Битрикс24 советует давать пользователю только те права, которые нужны для его задач, и напоминает, что «Администратор» – это лишь название роли: права ей выставляют отдельно.

Из-за чего роли перестают защищать данные

Дать всем права администратора «на время». Временное остаётся навсегда.
Заводить роль под каждого человека. Через год ролей больше, чем сотрудников, и модель перестаёт работать.
Прятать кнопку, но не закрывать данные на сервере. Пункт меню скрыт, а по прямой ссылке документ открывается.
Не решить заранее, кто выдаёт и снимает роли. Тогда это делает тот, кто оказался рядом.
Открывать кабинет без HTTPS. Логин и пароль тогда передаются в открытом виде, и роли уже ничего не защищают.

Роли и права проектируем в услугах Разработка личного кабинета и Разработка внутреннего корпоративного портала, а для компаний на Битрикс24 настраиваем их во внедрении корпоративного портала.

Сколько ролей заводить, кто их выдаёт и где проверять права

Сколько ролей заводить в личном кабинете?

Столько, сколько у пользователей разных наборов задач, и обычно это немного. В кабинете для клиентов IT-компании хватило трёх ролей. В портале поставщика персонала сначала было четыре, а пятую, для сотрудников, добавили уже по ходу работы. Если ролей больше, чем групп людей с разными задачами, модель пора пересматривать.

Чем роль отличается от группы пользователей?

Группа собирает людей, роль собирает права. Во многих системах их совмещают: группе назначают роль, и все её участники получают одинаковый доступ. Главное, чтобы права настраивали у роли или группы, а не у каждого сотрудника по отдельности.

Почему мало скрыть кнопку в интерфейсе?

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

Как дать сотруднику часть прав другой роли?

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

Почему в 1С-Битрикс у сотрудника больше прав, чем у его группы?

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

Кто должен выдавать и снимать роли?

Тот, о ком договорились до запуска, иначе роли раздаёт любой, у кого есть доступ к настройкам. В кабинете для клиентов IT-компании новых пользователей заводит и блокирует администратор со стороны компании, а администратор клиента присылает ему заявки на эти действия.

Чем RBAC отличается от ABAC?

RBAC решает вопрос доступа по роли человека, ABAC по набору признаков: кто пользователь, что за объект и при каких условиях пришёл запрос, например регион или сумма сделки. Роли проще настроить и проверить, атрибуты гибче, когда правил много. В кабинетах их часто совмещают: роль открывает разделы, а условие «только своя организация» отсекает чужие данные.