Права API в веб-приложении: RBAC, ABAC и ReBAC

Проверка права через условие вроде user.role == "admin" работает до первого сложного сценария: менеджер видит только свой отдел, подрядчик — выданный ему проект, а владелец документа может поделиться им с конкретным человеком. На этом этапе API приходится выбирать между RBAC, ABAC и ReBAC. Ошибка стоит не только времени на переделку: слишком широкое правило открывает данные, а слишком сложное превращает каждую проверку доступа в отдельный источник сбоев.

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

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

Для API полезно описывать проверку четырьмя сущностями:

• субъект — пользователь, сервис или команда, от имени которой пришёл запрос;
• действие — чтение, создание, изменение, удаление, экспорт или публикация;
• объект — заказ, документ, проект, запись клиента;
• контекст — организация, IP-адрес, время, статус объекта и другие условия.

Код ответа тоже должен быть предсказуемым. Если запрос не прошёл аутентификацию, API обычно возвращает 401 Unauthorized. Если личность установлена, но права недостаточны, используется 403 Forbidden. Нельзя маскировать каждую ошибку прав под 404 Not Found: иногда это оправдано, чтобы не раскрывать существование объекта, но такое решение должно быть единым для конкретного класса ресурсов.

Термин: PDP (Policy Decision Point) — компонент, который принимает решение по политике доступа. PEP (Policy Enforcement Point) — место, где это решение применяется, например middleware или обработчик запроса.

Три модели доступа

RBAC: права через роли

Role-Based Access Control связывает пользователя с ролью, а роль — с набором разрешений. Например, support_agent может читать обращения и менять их статус, но не экспортировать базу клиентов. Проверка получается быстрой и понятной: API получает роль и смотрит, есть ли у неё нужное разрешение.

RBAC хорошо подходит для административных панелей, внутренних сервисов и систем, где набор должностей стабилен. Его слабое место — контекст объекта. Правило «менеджер может редактировать отчёты» не отвечает, какие именно отчёты доступны менеджеру. Добавление ролей вроде manager_moscow_readonly и manager_moscow_editor быстро приводит к взрыву количества комбинаций.

ABAC: права через атрибуты

Attribute-Based Access Control принимает решение по атрибутам субъекта, объекта, действия и окружения. Правило может звучать так: «пользователь с атрибутом department = sales может читать заказ, если заказ относится к той же организации и находится в статусе draft».

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

ReBAC: права через отношения

Relationship-Based Access Control строит решение вокруг связей: пользователь является владельцем документа, состоит в команде проекта или получил роль редактора в конкретном пространстве. Такая модель естественна для совместных редакторов, корпоративных дисков, CRM и систем с делегированием.

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

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

Что выбрать для API

Не обязательно выбирать только одну модель. На практике часто работает композиция: RBAC определяет крупную область полномочий, а ABAC или ReBAC ограничивает доступ к конкретному объекту. Например, роль project_manager даёт право менять задачи, связь с проектом определяет доступный проект, а атрибут статуса запрещает редактирование закрытой задачи.

Когда достаточно RBAC

Начинайте с RBAC, если у вас меньше нескольких десятков стабильных разрешений, пользователи принадлежат к фиксированным группам, а доступ в основном разделён по разделам приложения. Храните не только название роли, но и атомарные permissions: orders.read, orders.update, reports.export. Тогда роль можно менять без переписывания обработчиков.

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

Когда переходить к ABAC

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

Не передавайте в policy-проверку весь объект без необходимости. Сформируйте минимальный контекст и явно определите значения по умолчанию. Отсутствующий атрибут должен вести к безопасному отказу, а не к неявному разрешению.

Когда оправдан ReBAC

ReBAC оправдан, если пользовательские права меняются от объекта к объекту: один человек редактирует проект, второй только читает, третий получил доступ к отдельной папке. В такой системе отношения — часть доменной модели, а не техническая таблица исключений.

Перед внедрением проверьте отзыв доступа. Если пользователь удалён из команды, запрос к уже открытому документу не должен продолжать работать из-за долгого кеша или старого токена. Отдельно протестируйте вложенные группы и массовое удаление связей.

Где подходы ломаются

• Проверка только на маршруте. Два endpoint могут обращаться к одному объекту с разными правилами. Защищайте не только URL, но и бизнес-операцию.
• Смешивание списка и карточки. Пользователь может иметь право видеть название объекта в списке, но не иметь права открыть его детали. Эти разрешения нужно моделировать отдельно.
• Кеширование без учёта субъекта. Ответ, сформированный для одного пользователя, нельзя отдавать другому только потому, что URL совпал. Ключ кеша должен учитывать все параметры, влияющие на решение.
• Расхождение сервисов. Один сервис считает пользователя владельцем, другой — участником организации. Зафиксируйте источник истины для каждой связи и не копируйте политику вручную.
• Непроверенные массовые операции. Проверка права на первый объект не заменяет проверку всего набора. Экспорт, архивирование и пакетное удаление требуют отдельного сценария авторизации.

Как сравнить решения до внедрения

Составьте матрицу доступа не по экранам, а по действиям и объектам. Для каждой строки укажите разрешённый случай, запрет, причину отказа и источник данных. Минимальный набор тестов должен включать владельца, обычного участника, пользователя из другой организации, отозванного участника и неаутентифицированный запрос.

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

Для расследования инцидентов журналируйте субъект, действие, тип и идентификатор объекта, результат, версию политики и корреляционный идентификатор запроса. Не записывайте токены и лишние персональные данные. Формулировка «доступ запрещён» полезна меньше, чем «запрещено политикой организации: субъект и объект относятся к разным tenant».

Что делать дальше

Возьмите пять самых чувствительных endpoint и выпишите для каждого субъект, действие, объект и контекст. Если решения зависят только от должности, начните с RBAC. Если важны атрибуты организации и состояния, добавьте ABAC. Если доступ определяется членством или владением конкретным объектом, проектируйте ReBAC.

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