Как спроектировать роли и права доступа в бизнес-системе: модель, ошибки и чек-лист

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

Главная ошибка — выдать широкую роль «сотрудник» и надеяться, что интерфейс скроет лишнее. Интерфейс можно обойти прямым запросом, поэтому решение о доступе должно находиться в доверенном серверном слое. Ниже — способ спроектировать права до разработки и проверить их на тестовых сценариях.

Начните с короткого discovery: опишите роли, чувствительные объекты и действия, а затем свяжите их с критериями приёмки. Релевантный контур Paladin Engineering есть на странице веб-разработки; для обсуждения конкретной модели можно оставить заявку.

Сначала разделите аутентификацию и авторизацию

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

• Субъект: сотрудник, подрядчик, сервисная учётная запись или администратор.
• Действие: просмотр, создание, изменение, согласование, экспорт, удаление.
• Объект: заявка, договор, клиент, файл, отчёт или строка справочника.
• Контекст: организация, филиал, проект, статус, срок и канал запроса.

Как выбрать модель: RBAC, ABAC или отношения

RBAC связывает пользователя с ролью и роль с разрешениями. Это прозрачно для небольшого числа устойчивых должностей, но быстро разрастается, когда права зависят от филиала, проекта или владельца. ABAC учитывает атрибуты пользователя, ресурса и окружения. Relationship-based подход описывает связи вроде «автор документа», «куратор клиента» или «участник проекта».

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

Deny by default и минимальные полномочия

OWASP рекомендует подход deny by default: если правило явно не разрешает действие, запрос отклоняется. Та же рекомендация дополняется принципом наименьших привилегий и проверкой разрешений на каждом запросе. Дополнительные права можно выдавать осознанно, а не принимать широкую роль за безопасный компромисс.

• Запретить неизвестные комбинации субъект–действие–объект.
• Не доверять роли, идентификатору организации или владельцу из клиента.
• Проверять доступ к API, файлам, фоновым задачам и экспортам.
• Логировать отказ без записи токенов и полных персональных данных.
• Регулярно пересматривать временные и административные полномочия.

Матрица доступа — минимальный рабочий артефакт

До прототипа соберите таблицу, где одна строка описывает действие над объектом. Отдельно укажите условия: организация пользователя, статус записи, принадлежность к проекту и необходимость второго согласования. Так разговор «менеджер видит клиентов» превращается в проверяемые сценарии.

Где чаще всего ломается защита

Ошибки доступа появляются не только в новых экранах. Часто забывают проверить вложенные объекты, прямые идентификаторы, массовые операции и фоновые задачи. Если API принимает id документа и возвращает его без проверки связи с пользователем, скрытый пункт меню не спасает.

• Проверка есть в UI, но отсутствует в API.
• Просмотр проверяется, а экспорт или архив — нет.
• Администратор используется как универсальная роль поддержки.
• Удалённая роль оставляет право у старого токена или задачи.
• Тесты проверяют happy path, но не соседнюю организацию.

Как тестировать роли до запуска

OWASP ASVS можно использовать как основу для требований проверки безопасности и критериев приёмки. Для каждой важной операции создайте позитивные и негативные тесты: разрешённый пользователь, пользователь другой организации, изменённый идентификатор, просроченный статус, повторный запрос и массовый экспорт. Важен не только HTTP-код: ошибка не должна раскрывать существование чужого объекта.

В acceptance-сценариях фиксируйте журналирование: кто запросил действие, над каким объектом, какое правило сработало и почему операция отклонена. При этом в лог не должны попадать токены, пароли и полные персональные данные. Paladin Engineering может помочь разложить роли на сценарии, требования и тестовый контур, но статья не заменяет полноценный security-аудит.

Что подготовить перед разработкой

• Список объектов и их владельцев.
• Глоссарий ролей без должностных синонимов.
• Матрицу действий: read, create, update, approve, export, delete.
• Правила видимости по организации, проекту, филиалу и статусу.
• Требования к аудиту, сроку действия и отзыву прав.
• Набор негативных тестов и критерии безопасного отказа.

Если нужен личный кабинет, корпоративный портал или внутренняя система с несколькими уровнями доступа, обсудите задачу с Paladin Engineering. Принесите обезличенный список ролей и два спорных сценария — этого достаточно для предметного разговора.

FAQ: проектирование прав доступа

Достаточно ли RBAC для внутреннего портала?

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

Можно ли проверять доступ только на фронтенде?

Нет. UI улучшает интерфейс, но доверенное решение должно приниматься на сервере для каждого защищённого действия.

Нужен ли отдельный администратор для каждой функции?

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

Как проверить, что пользователь не видит чужие данные?

Тестируйте изменённые идентификаторы, соседнюю организацию, другой проект, архивный статус и массовые операции.

Когда подключать security-специалиста?

До фиксации архитектуры, если есть персональные данные, платежи, внешние подрядчики, сложные роли или требования регулятора.

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