Направление работ: Back Код раздела: 1.2 Аккаунты и пользователи > Организация доступа к системе Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 22.06.26
1. Назначение
Организация доступа определяет, какие зоны системы доступны Аккаунту и какие действия он может выполнять в каждой зоне.
Система хранит связь доступа с зоной, тарифом, ролью и категорией права, а затем использует эти данные при проверке операций.
Документ фиксирует модель доступа на уровне системы; детальные матрицы ролей, тарифов и интерфейсные сценарии описываются в соседних разделах.
2. Ключевые понятия
Доступ — список прав и разрешений, которые определяют, какие действия пользователь может выполнять в системе.
Зона доступа — область действия прав: клиентская зона, партнерская зона или сервисная зона.
Клиентская зона — зона базовых и расширенных клиентских возможностей для управления своими данными и заказами.
Партнерская зона — зона управления площадками, бронированиями и операционной деятельностью конкретной партнерской зоны.
Сервисная зона — зона управления системой и глобальными настройками.
Роль — набор прав, который определяет доступ пользователя в партнерской или сервисной зоне.
Тариф — условие, которое открывает доступ к клиентской или партнерской зоне и может расширять набор прав.
Категория права доступа — справочная характеристика права, которая определяет формат реализации возможности в системе.
3. Scope
Входит
- S1 Зоны доступа: клиентская, партнерская и сервисная зоны, а также область действия доступа в каждой зоне.
- S2 Тарифы и роли: выдача доступа через тарифы в клиентской и партнерской зонах и через роли в партнерской и сервисной зонах.
- S3 Права доступа: категории прав доступа и единый список прав доступа — таблица.
- S4 Проверка и расширение доступа: проверка права перед выполнением операции, отказ доступа и возможность расширения прав без привязки к интерфейсу.
Не входит
- Back: 1.1 Организация Аккаунтов, учетные данные и токены доступа
- Back: 1.2.1 Группировка прав по ролям и тарифам
- Back: 1.3.1 Клиентская зона доступа
- Back: 1.4.1 Партнерская зона доступа
- Back: 8.1 Настройка доступа к сервисной зоне
- Back: 8.3.1 Доступ и комиссия
- Back: 8.3.4 Подписки
- WebLk: 3.6 Сотрудники и доступ
- AdmLk: 3.7 Сотрудники и доступ к сервисной зоне
- Mobile: 5.6 Подписки
- Catalog: 4.1.3 Работа с подписками
4. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе
| ID | Требование | Комментарий | Тип требования | Вес | Статус |
|---|---|---|---|---|---|
| S1: #BR1.2-1 | Один Аккаунт может иметь Доступ в нескольких зонах одновременно | Бизнес | 1 | Реализовано | |
| S1: #BR1.2-2 | Доступ должен применяться только в границах своей зоны действия | Область действия: * клиентская зона — конкретный клиент * партнерская зона — конкретная партнерская зона * сервисная зона — сущности и элементы системы в пределах сервисной роли | Системное | 1 | Частично · #OQ1.2-5 |
| S1: #BR1.2-3 | Доступ Аккаунта в партнерской зоне должен ограничиваться разрешенными ему партнерскими зонами и базами (ABAC) | Доступ применяется по иерархии партнерская зона > база. Доступ к зоне означает доступ ко всем ее базам, если область доступа не сужена. | Бизнес | 1 | Реализовано |
| S2: #BR1.2-4 | Доступ в клиентской и партнерской зонах должен выдаваться на основании активного тарифа | Тариф определяет доступность зоны и может расширять набор прав: * клиентская зона — Клиент или Про-клиент * партнерская зона — партнерские тарифы | Бизнес | 1 | Частично · #OQ1.2-2 |
| S2: #BR1.2-5 | Доступ в партнерской и сервисной зонах также должен определяться ролью пользователя | Область применения роли: * партнерская зона — Владелец партнерской зоны или Сотрудник партнера * сервисная зона — Владелец сервиса или Сотрудник сервиса. В сервисной зоне доступ выдается только через роль, без тарифа. | Бизнес | 1 | Реализовано |
| S3: #BR1.2-6 | Каждое право доступа должно иметь категорию права | Допустимые категории: * UI — визуальное представление функционала без операций с системой * C — создание * R — чтение * U — редактирование * A — архивация * D — удаление * DB — формат и состав данных, выдаваемых системой | Системное | 1 | Частично · #OQ1.2-3 |
| S3: #BR1.2-7 | Система должна использовать единый список прав доступа как источник для проверки операций | Полный список прав доступа ведется в отдельной таблице и должен быть перенесен в BRD в формате Markdown по итогу реализации. | Системное | 1 | Реализовано |
| S3: #BR1.2-8 | Отдельные права доступа должны выделяться для операций с самостоятельным бизнес-правилом или тарифным ограничением (ABAC) | Кандидаты на детализацию: отмена по правилам и без правил, действия с заказами в зависимости от их статусов, перенос заказа, платные режимы цен и календаря, абонементы, Open API. | Бизнес | 1 | Частично · #OQ1.2-4 |
| S3: #BR1.2-9 | Отмена заказа должна управляться базовым правом отмены и дополнительными правами для выбранных условий отмены (ABAC) | Базовая отмена по правилам требует отдельного права отмены. Условия по штрафу и предоплате требуют дополнительных прав, например отмену без штрафа или удержание предоплаты. | Бизнес | 1 | Частично · #OQ1.2-4 |
| S4: #BR1.2-10 | Перед выполнением операции система должна проверять право Аккаунта на эту операцию | Проверка учитывает зону доступа, область действия доступа, тариф или роль и категорию права. | Системное | 1 | Реализовано |
| S4: #BR1.2-11 | Перенос заказа на другую площадку должен выполняться только при наличии доступа к исходной и целевой области заказа (ABAC) | Для изменения базы проверяется доступ и к старой, и к новой базе. | Бизнес | 1 | Реализовано |
| S4: #BR1.2-12 | Если право не найдено или не действует в нужной зоне, система должна отказать в выполнении операции | Системное | 1 | Реализовано · #OQ1.2-6 | |
| S4: #BR1.2-13 | Система должна поддерживать расширение прав доступа без жесткой привязки к интерфейсу (после релиза реализация) | Один интерфейс может поддерживать работу прав из нескольких зон доступа. Например, при входе в виджет партнер видит партнерский функционал и права доступа к виджету, а клиент использует клиентский сценарий бронирования. | Системное | 3 | Реализовано |
5. Открытые вопросы
Пин сверки: BRD версия 0.1 (обновлено 22.06.26) · Репозиторий
booking-monorepo, веткаorigin/main, commit82359296(2026-09-07) · Дата сверки: 2026-09-08 · Якорь в коде:src/services/booking.abac(PDP/PAP, каталог permissions и ролей),src/services/booking.apigateway/Musbooking.ApiGateway/PolicyEnforcementPoint(PEP),src/libs/booking.domain.abstractions/.../Contracts/Abac(общие контракты авторизации),src/services/booking.authentication(аккаунты, сотрудники партнёра, сервисные сотрудники),src/services/booking.clients(клиентский тариф),src/services/booking.partner-management(партнёрский тариф) · Гайдбук не передан — маршрутизация вопросов без сверки с гайдбуком.
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| #OQ1.2-1 | Гайдбук | Подтвердить, что полный список прав доступа в таблице актуален и может быть перенесен в BRD в формате Markdown по итогу реализации | Back-команда | Open | ||
| #OQ1.2-2 | Код | Требование говорит, что доступ в клиентской и партнерской зонах должен выдаваться на основании активного тарифа. В коде политика TariffPolicy, которая должна это проверять, реализована (src/services/booking.abac/src/Abac.Persistence/Policies/TariffPolicy.cs:1-69), но оба места, которые собирают профиль субъекта для авторизации, сейчас всегда кладут в профиль пустой тариф (план "", IsActive=false) с явным TODO-комментарием разработчиков «TariffPolicy пропускает проверку»: src/services/booking.abac/src/Abac.Persistence/Consumers/AccessTokenCreatedConsumer.cs:79-81 и src/services/booking.abac/src/Abac.Persistence/Caching/MemoryAuthorizationSubjectContextProvider.cs:122-124. Из-за этого TariffPolicy.IsApplicable (строки 22-25 того же файла) пропускает проверку для всех субъектов, и тарифная проверка сейчас фактически не работает (fail-open) — партнёр получает доступ так, как будто активность тарифа не проверяется вовсе. | Разработка | Open | Завершить связывание тарифа партнёра (и клиента) с профилем субъекта, убрать fail-open условие в TariffPolicy.IsApplicable после этого, добавить тест на сценарий «неактивный тариф → отказ». | |
| #OQ1.2-3 | Код | Требование говорит, что каждое право должно иметь категорию из фиксированного списка UI/C/R/U/A/D/DB. В коде такой таксономии нет: PermissionType — это View/Create/Edit/Delete/Manage/SpecialAction (src/services/booking.abac/src/Abac.Domain/Common/Enums/PermissionType.cs:6-38), а поле Category в PermissionCode — свободная строка с функциональными группами каталога (calendar, content, profile, reports, support, addons), а не типами операций. Более того, загрузчик действующего каталога permissions-v3 (src/services/booking.abac/src/Abac.Persistence/Catalog/Reconciliation/CatalogFile.cs:15-22,115-121) принимает только 4 из 6 значений PermissionType (view/create/update/delete) — Manage и SpecialAction в текущем каталоге не используются. | Разработка | Open | Синхронизировать формулировку BRD с фактической моделью (PermissionType + Category) либо явно спланировать доработку каталога под категории UI/C/R/U/A/D/DB, если бизнес-необходимость в них сохраняется. | |
| #OQ1.2-4 | Код | Требование говорит, что для отмены заказа должны быть отдельные права по осям штрафа и удержания предоплаты, а каталог permissions должен выделять коды и для Open API. В коде базовая отмена по статусу и режиму «по правилам/без правил» реализована отдельными кодами (order_reserve_cancel_by-rules/no-rules, order-paid_cancel_by-rules/no-rules, order-closed_cancel_by-rules/no-rules — операция CancelOrder, src/services/booking.abac/src/Abac.Persistence/Migrations/20260825101541_OperationsSeedV3.cs:743-746). Но политика, которая должна проверять именно ось штрафа/предоплаты — PenaltyPolicy — является заглушкой: src/services/booking.abac/src/Abac.Persistence/Policies/PenaltyPolicy.cs:11-14 всегда возвращает Indeterminate с комментарием «Penalty policy настроена, но penalty-контекст для операции не определён в модели данных». Отдельного домена/группы прав для Open API в действующем каталоге (все строки docs/access-control/permissions-v3.csv имеют domain=partner) не найдено. | Разработка | Open | Уточнить срок доработки PenaltyPolicy (донести penalty-контекст до PDP) и подтвердить, планируется ли отдельная категория прав для Open API в каталоге, либо это доработка следующей итерации. | |
| #OQ1.2-5 | Код | Требование говорит, что доступ должен применяться только в границах своей зоны действия — в т.ч. в клиентской зоне в границах конкретного клиента. Для партнерской и сервисной зоны граница подтверждена в PDP (AuthorizationScopeDto + ScopePolicy/ScopeMembershipPolicy — src/services/booking.abac/src/Abac.Domain/Common/Dtos/AuthorizationScopeDto.cs:6-34, src/services/booking.abac/src/Abac.Persistence/Policies/ScopePolicy.cs). Клиентская зона в модели ABAC не представлена вовсе: ни как отдельный тип ресурса, ни как поле scope. Судя по контекстному документу «ABAC Требования к реализации доступа», ABAC v3.0 намеренно нацелен на партнерский кабинет — вероятно, ограничение клиента его собственными данными выполняется другим (не-ABAC) механизмом в booking.clients, но это не подтверждено в рамках данного обхода. | Разработка | Open | Подтвердить, каким механизмом сегодня ограничивается доступ клиента только к своим данным, и стоит ли зафиксировать это явно в BRD как cross-layer примечание. | |
| #OQ1.2-6 | Код (обратный проход) | Основной путь PDP отказывает, если право не найдено (DecideAccessQueryHandler.Deny(...) — множественные ветки в src/services/booking.abac/src/Abac.Application/AccessDecisions/DecideAccessQueryHandler.cs) и PEP уходит в отказ при любой ошибке похода к PDP («fail-closed: любая ошибка похода в PDP = отказ в доступе» — src/services/booking.apigateway/Musbooking.ApiGateway/PolicyEnforcementPoint/Service/PepService.cs:83-92). Но для случая «операция не зарегистрирована в каталоге» в коде есть конфигурационный флаг Abac:AllowUnknownOperations, который при включении разрешает операцию вместо отказа (DecideAccessQueryHandler.cs:57,79-89). Это отступление от «право не найдено → отказ» для конкретного случая незарегистрированной операции. | Разработка | Open | Подтвердить целевое состояние флага Abac:AllowUnknownOperations на проде (выключен/включён) и сценарий его использования — временный предохранитель на раскатке или постоянный режим. |