Атрибутная модель доступа (ABAC)

1. Основа модели

1. Модель доступа в системе: ABAC-first.
2. Ролевые признаки (SUPER_ADMIN, ORG_ADMIN, ANALYST и т.д.) не заменяют ABAC, а выступают атрибутами субъекта.
3. Доступ принимается по политике вида:

Permit if Subject.Attributes + Resource.Attributes + Action + Context satisfy Policy

2. Наборы атрибутов

1. Subject (кто): user_id, org_id, roles, clearance_level.
2. Resource (к чему): resource_type, owner_org_id, region_id, brand_id, sensitivity.
3. Action (что делает): read, export, edit, delete, admin.
4. Context (в каких условиях): time, ip_zone, mfa_verified, session_risk, subscription_plan.

3. Примеры политик

1. Аналитик читает только данные своей организации:

allow read when subject.org_id == resource.owner_org_id

2. Экспорт доступен только при MFA и активной подписке:

allow export when context.mfa_verified = true and context.subscription_plan in [pro, enterprise]

3. Доступ по региону и бренду:

allow read when resource.region_id in subject.allowed_regions
           and resource.brand_id in subject.allowed_brands

4. Админ-операции только для привилегированных ролей и корпоративной сети:

allow admin when 'SUPER_ADMIN' in subject.roles and context.ip_zone = 'corp'

4. Поток авторизации

1. Пользователь проходит аутентификацию в Keycloak.
2. API получает JWT и извлекает атрибуты субъекта.
3. Сервис дополняет атрибутами ресурса и контекста.
4. Policy Engine принимает решение permit/deny.
5. Результат, причина и policy-id логируются в audit trail.

5. Требования к реализации

1. Deny by default для всех неописанных политик.
2. Версионирование политик (policy_version, effective_from).
3. Трассировка причины отказа без утечки чувствительных данных.
4. Единый формат PDP/PEP логов во всех сервисах.

6. Контроль и сверка

1. Для каждой роли/сценария фиксируется матрица test-cases permit/deny.
2. На релизе выполняются автоматические policy regression tests.
3. Любое изменение ABAC-политик проходит change review.