Роли и права доступа: чек-лист перед продакшеном

Проверьте не названия ролей, а границы доступа

Пользователь без кнопки «Удалить» всё ещё может удалить запись, если сервер принимает прямой запрос без проверки права. Перед продакшеном важно проверить не только список ролей, но и каждую операцию с данными: кто может читать, создавать, менять и удалять объект, при каких условиях и в каком контексте. Этот чек-лист подходит для веб-сервисов и API независимо от фреймворка; конкретные настройки и синтаксис зависят от вашей платформы.

Сначала выберите модель — и запишите её ограничения

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

В ABAC решение принимается с учётом атрибутов пользователя, объекта и запроса: например, менеджер может видеть заказ только своей команды. Гибридная схема использует роли как базовый уровень, а атрибуты — для ограничений на конкретный объект. Цена гибкости — больше условий, которые нужно документировать, тестировать и поддерживать.

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

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

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

Чек-лист перед выпуском

1. Составьте карту ресурсов и действий. Перечислите защищаемые данные и операции: просмотр профиля, изменение заказа, экспорт отчёта, управление пользователями. Не ограничивайтесь экранами: API, фоновые задачи, выгрузки и административные инструменты тоже выполняют действия от имени пользователя. Проверка готова, когда у каждой операции есть владелец и понятный ответ на вопрос, кто вправе её выполнить.
2. Определите минимальные разрешения. Для каждой роли выпишите нужные действия и отдельно отметьте запрещённые. Новая учётная запись не должна автоматически получать широкие права только потому, что для неё не настроили исключение. Проверка готова, когда можно показать матрицу «роль — действие — ресурс» и объяснить каждую разрешённую ячейку.
3. Проверьте доступ к чужим объектам. Создайте тестовые записи двух пользователей или команд и попробуйте получить, изменить и удалить чужие данные через прямой запрос. Скрытая кнопка в интерфейсе не считается защитой. Проверка готова, когда сервер отклоняет запрос, даже если клиент самостоятельно подставил идентификатор чужого объекта.
4. Проверьте каждую точку входа. Сверьте проверки в браузерных маршрутах, API, фоновых обработчиках, экспорте и админке. Один и тот же объект не должен открываться через менее защищённый альтернативный путь. Проверка готова, когда список операций сопоставлен со списком серверных обработчиков и для каждой есть тест разрешённого и запрещённого сценария.
5. Определите поведение при ошибке. Если проверка не смогла подтвердить право из-за отсутствующих данных или сбоя зависимости, безопаснее не выдавать доступ. Разведите ответы «пользователь не вошёл» и «пользователю запрещено», если это важно для вашего интерфейса, но не раскрывайте в сообщении лишние сведения о существовании чужой записи. Проверка готова, когда сбой проверки не превращается в разрешение.
6. Проверьте изменение и отзыв прав. Уточните, что происходит при смене роли, увольнении, удалении пользователя и отзыве членства в команде. Если разрешения кэшируются, проверьте, как быстро изменение вступает в силу и какие копии доступа нужно инвалидировать. Проверка готова, когда вы можете отозвать доступ и подтвердить это повторным запросом, а не только обновлением страницы.
7. Разберите опасные привилегии отдельно. Экспорт, массовое удаление, изменение ролей и управление интеграциями могут иметь больший ущерб, чем обычное редактирование. Проверьте, ограничен ли круг пользователей и остаётся ли след операции в журнале. Проверка готова, когда для критичных действий определены исполнитель, время и объект, а доступ к самому журналу также ограничен.
8. Протестируйте матрицу, а не только счастливый путь. Добавьте проверки для каждой роли, важного действия и границы владения объектом. Отдельно проверьте сочетания ролей: если пользователь состоит в двух командах, его права не должны неожиданно расширяться. Проверка готова, когда тесты фиксируют как разрешённые сценарии, так и ожидаемые отказы.

Что обычно ломается после запуска

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

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

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

Когда выбирать RBAC, ABAC или гибрид

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

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

Что сделать перед следующим релизом

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

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