Направление работ: Back Код раздела: 1.2 Аккаунты и пользователи > Организация доступа к системе > ABAC Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 01.07.26
1. Назначение
Документ фиксирует требования к ABAC-реализации доступа для партнерского кабинета v3.0.
Система должна принимать решение о доступе к операции на основании атрибутов субъекта, объекта и действия, а также возвращать однозначный результат проверки с причиной.
Требования уточняют реализацию модели доступа из Back 1.2 и не заменяют детальные матрицы ролей, тарифов и интерфейсные сценарии.
2. Ключевые понятия
ABAC — модель контроля доступа, в которой решение рассчитывается по атрибутам субъекта, объекта и действия.
PEP — точка применения политики в сервисе, которая собирает контекст операции, обращается за решением к PDP и выполняет или блокирует операцию.
PDP — точка принятия решения, которая проверяет запрос авторизации и возвращает разрешение или отказ с причиной.
PIP — источник атрибутов для PDP: данные ролей, прав, тарифа, scope и кэша профиля.
PAP — администрирование ролей, прав и каталога permissions.
SubjectProfile — профиль субъекта для авторизации, собранный из данных аккаунта, ролей, тарифа и scope.
EffectivePermissions — итоговый набор прав аккаунта, сформированный из ролей и ограниченный тарифом.
ResourceScope — область ресурса в иерархии партнерская зона > база > комната.
PolicySet — набор политик авторизации, объединенных правилом deny-overrides.
Before / After — область ресурса до и после операции, используемая для проверки операций перемещения.
3. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе
| ID | Требование | Комментарий | Тип требования | Вес |
|---|---|---|---|---|
| #BR1.2-ABAC-1 | Система должна использовать ABAC-модель для проверки доступа к операции | Решение рассчитывается по атрибутам субъекта, объекта и действия. Роль не является отдельным механизмом RBAC, а используется как источник атрибута “набор прав”. | Системное | 1 |
| #BR1.2-ABAC-2 | Система должна разделять аутентификацию и авторизацию | Gateway проверяет валидность токена и передает идентификаторы субъекта. Решение “можно ли выполнить операцию” принимает PDP. | Системное | 1 |
| #BR1.2-ABAC-3 | PDP должен быть единой точкой принятия решения по авторизации | PDP принимает запрос авторизации и возвращает ALLOW или DENY с причиной. Бизнес-сервисы не должны самостоятельно дублировать полный набор политик авторизации. | Техническое | 1 |
| #BR1.2-ABAC-4 | Контракты авторизации должны быть едиными для сервисов, которые обращаются к PDP | Базовые контракты: AuthorizationRequest, AuthorizationDecision, SubjectProfile, ResourceScopeDto. | Техническое | 1 |
| #BR1.2-ABAC-5 | PEP должен собирать контекст авторизации в сервисе, где выполняется операция | Сервис знает затронутый ресурс, измененные поля, Before/After scope и специфичные атрибуты операции. Gateway этот контекст не собирает. | Техническое | 1 |
| #BR1.2-ABAC-6 | Запрос авторизации должен передавать коды требуемых прав и область затронутых ресурсов | Состав запроса: accountId, source, required permissions, Before/After resource scopes, признаки необходимости scope и активного тарифа, специфичные атрибуты операции. | Техническое | 1 |
| #BR1.2-ABAC-7 | SubjectProfile должен хранить полный снимок атрибутов субъекта для проверки доступа | Состав профиля: AccountId, Source, Tariff, EffectivePermissions, Scope, IsAdmin. Для отдельных операций профиль может включать доменные ограничения роли, например CancellableStatuses. | Системное | 1 |
| #BR1.2-ABAC-8 | EffectivePermissions должен формироваться как итоговый набор прав аккаунта с учетом ролей и тарифа | В набор объединяются права основной роли, дополнительных ролей и роли в партнерской зоне, после чего набор ограничивается тарифом. | Системное | 1 |
| #BR1.2-ABAC-9 | Тариф должен применяться как потолок прав в партнерской зоне | При неактивном тарифе доступ к операциям должен ограничиваться продлением доступа. Расширяемые права доступны только если они открыты тарифом. | Бизнес | 1 |
| #BR1.2-ABAC-10 | Scope субъекта должен задавать, к каким партнерским зонам, базам и комнатам у аккаунта есть доступ | Доступ применяется по иерархии партнерская зона > база > комната. Доступ к зоне означает доступ ко всем ее базам и комнатам, если scope не сужен. | Бизнес | 1 |
| #BR1.2-ABAC-11 | Модель Permission должна хранить метаданные, необходимые для проверки ABAC | Состав метаданных: код права, категория, группа, тип права, необходимость resource scope, необходимость активного тарифа, состояние active/deprecated, версия. | Техническое | 1 |
| #BR1.2-ABAC-12 | Каталог permissions v3.0 должен быть источником прав для PDP | Каталог должен покрывать партнерский набор v3.0: заказы, календарь, цены, скидки, объекты, площадки, абонементы и тарифные возможности. | Системное | 1 |
| #BR1.2-ABAC-13 | Каталог permissions должен выделять отдельные коды для операций с самостоятельным бизнес-правилом или тарифным гейтом | Кандидаты на детализацию: отмена по правилам и без правил, финансовые оси отмены, перенос заказа, платные режимы цен и календаря, абонементы, Open API. | Бизнес | 1 |
| #BR1.2-ABAC-14 | Для старых и новых permissions должен быть задан mapping | Mapping связывает текущие грубые права read/write/delete с новыми детализированными permissions. Enforce-код, используемый в обработчике, должен присутствовать в каталоге или иметь явное соответствие. | Техническое | 1 |
| #BR1.2-ABAC-15 | Система должна предоставлять API для управления каталогом прав, ролями, назначениями ролей и scope | Нужны операции получения каталога permissions с фильтрами, создания и изменения ролей, назначения permissions ролям, назначения ролей сотрудникам, получения effective permissions и настройки scope на уровне зоны, базы и комнаты. | Системное | 1 |
| #BR1.2-ABAC-16 | Решение PDP должно складываться из независимых политик по правилу deny-overrides | Если любая политика возвращает отказ, итоговое решение должно быть DENY. Базовые политики: AdminBypass, PermissionPolicy, TariffPolicy, ResourceScopePolicy и operation-specific policies. | Системное | 1 |
| #BR1.2-ABAC-17 | На MVP система должна поддерживать временный AdminBypass по признаку IsAdmin | Если IsAdmin = true, операция разрешается до проверки остальных политик. После MVP bypass должен быть заменен системной ролью. | Техническое | 2 |
| #BR1.2-ABAC-18 | PermissionPolicy должна разрешать операцию только при наличии всех требуемых permissions в EffectivePermissions | Если хотя бы один обязательный код отсутствует в итоговом наборе прав субъекта, PDP возвращает отказ с причиной PermissionDenied. | Системное | 1 |
| #BR1.2-ABAC-19 | TariffPolicy должна блокировать операции, требующие активного тарифа, если тариф неактивен | При неактивном тарифе PDP возвращает отказ с причиной TariffExpired, кроме операций продления доступа. | Системное | 1 |
| #BR1.2-ABAC-20 | ResourceScopePolicy должна проверять каждый scope из Before и After относительно scope субъекта | Для каждой области ресурса проверяется принадлежность разрешенной партнерской зоне, базе и комнате. При несовпадении PDP возвращает отказ с причиной ResourceAccessDenied. | Системное | 1 |
| #BR1.2-ABAC-21 | Любой ресурс, требующий проверки доступа к месту, должен приводиться к ResourceScopeDto | Заказ, позиция, цена и другие ресурсы сводятся к иерархии партнерская зона > база > комната. Для нестандартных ресурсов используется резолвер scope, но сама проверка выполняется общей ResourceScopePolicy. | Техническое | 1 |
| #BR1.2-ABAC-22 | Operation-specific policies должны проверять доменные ограничения, влияющие на доступ к конкретной операции | Пример: для отмены заказа проверяется, входит ли статус заказа в CancellableStatuses субъекта. | Системное | 1 |
| #BR1.2-ABAC-23 | PEP должен определять требуемые permissions по diff измененных полей операции | Если команда меняет несколько полей, PEP передает в PDP коды только для фактически измененных полей. Например, изменение даты и площадки требует коды редактирования даты/времени и площадки. | Техническое | 1 |
| #BR1.2-ABAC-24 | Команда с несколькими измененными полями должна выполняться только при успешной авторизации по всем требуемым permissions | Если по одному из измененных полей право отсутствует или scope не проходит проверку, операция должна быть отклонена целиком. | Системное | 1 |
| #BR1.2-ABAC-25 | При переносе заказа на другую площадку система должна проверять доступ к исходной и целевой области ресурса | Для изменения BaseId или RoomId PEP передает Before и After scope, а ResourceScopePolicy требует доступ и к старой, и к новой базе или комнате. | Бизнес | 1 |
| #BR1.2-ABAC-26 | При изменении позиций заказа система должна добавлять scope каждой позиции в общий список проверки | Позиции проверяются тем же механизмом ResourceScopePolicy, что и заказ. Отдельная политика для позиций не требуется. | Системное | 2 |
| #BR1.2-ABAC-27 | Отмена заказа должна проверяться через базовое право отмены и дополнительные права для явно выбранных осей отмены | Базовая отмена по правилам требует partner.order.cancel. Явные значения по осям штрафа и предоплаты требуют дополнительные коды, например отмену без штрафа или удержание предоплаты. | Бизнес | 1 |
| #BR1.2-ABAC-28 | Доступность отмены по статусу заказа должна проверяться как атрибут объекта относительно настроек роли субъекта | Статус заказа передается в контекст авторизации. Набор разрешенных статусов для субъекта хранится в CancellableStatuses; для владельца и администратора доступен максимальный набор. | Бизнес | 2 |
| #BR1.2-ABAC-29 | PDP не должен рассчитывать деньги, штрафы, возвраты и квоты | PDP отвечает только на вопрос доступа. Денежные правила, размер сбора, возврат, лимиты и счетчики рассчитывает соответствующий бизнес-сервис или домен. | Системное | 1 |
| #BR1.2-ABAC-30 | PDP должен работать на своих данных PIP и не обращаться к бизнес-сервисам на горячем пути проверки | Профиль субъекта, роли, права, тариф и scope берутся из PIP и кэша профиля. | Техническое | 1 |
| #BR1.2-ABAC-31 | SubjectProfile должен кэшироваться и инвалидироваться при изменении данных, влияющих на доступ | Кэш профиля должен иметь короткий TTL со случайным разбросом и сбрасываться при изменении ролей, permissions, тарифа или scope. Ориентир TTL: 3-5 минут. | Техническое | 1 |
| #BR1.2-ABAC-32 | При сбое PDP или невозможности получить решение система должна запрещать операцию | Поведение fail-closed снижает риск случайного предоставления доступа при ошибке авторизации. | Системное | 1 |
| #BR1.2-ABAC-33 | Каждое решение авторизации должно фиксироваться в audit с причиной результата | Логируются allow, deny и errors. Для отказов фиксируются причины, например PermissionDenied, TariffExpired, ResourceAccessDenied, StatusNotAllowed. | Техническое | 1 |
| #BR1.2-ABAC-34 | Система должна поддерживать метрики и shadow mode для безопасного включения ABAC | Метрики должны показывать allow, deny и errors. Shadow mode нужен для проверки влияния новых политик до блокировки реальных операций. | Техническое | 2 |
| #BR1.2-ABAC-35 | Для ABAC должны быть подготовлены миграции и сиды данных | Минимальный набор данных: permissions, roles, role_permissions, employee_roles, employee_scopes, tariff_permissions. | Техническое | 1 |