Ролевой движок

1) Модели авторизации

RBAC (Role-Based Access Control): субъект получает роли, роли связаны с правами (permissions). Просто управлять, хорошо для типовых обязанностей.
ABAC (Attribute-Based Access Control): решение зависит от атрибутов субъекта, ресурса, действия и окружения (время, IP, регион, риск). Гибко и масштабируется на сложные правила.
Гибрид RBAC+ABAC: роли дают «базовую» способность, атрибуты сужают ее (conditions).
(Опционально) ReBAC/Relationship-based: граф отношений (владелец, член команды, делегат), полезно для документ- и орг-структур.

2) Архитектура: PDP/PEP и потоки

PEP (Policy Enforcement Point): место применения решения (API-шлюз, бэкенд-метод, SQL-прослойка, UI).
PDP (Policy Decision Point): сервис/библиотека, вычисляющая `ALLOW/DENY` по политикам и атрибутам.
PIP (Policy Information Point): источники атрибутов (IdP/профиль, метаданные ресурса, риск-скор, гео).
PAP (Policy Administration Point): административный интерфейс/репозиторий политик (версии, черновики, публикация).

Поток: запрос → PEP формирует контекст → PDP подтягивает недостающие атрибуты (через PIP) → вычисляет решение → PEP применяет (разрешить/запретить/отрезать поля) → аудит.

3) Модель данных

• `subject` (user/service) с атрибутами: `tenant_id`, `roles`, `departments`, `risk_level`, `mfa_verified`, `scopes`, `claims`.
• `resource` c типом и атрибутами: `type`, `owner_id`, `tenant_id`, `classification` (public/confidential), `region`, `tags`.
• `action`: `read`, `write`, `delete`, `export`, `approve`, `impersonate` и т. п.
• `environment`: `time`, `ip`, `device`, `geo`, `auth_strength`, `business_context` (канал, тариф).

• `roles(id, tenant_id, name, inherits[])` — поддержите иерархии и шаблоны.
• `permissions(id, resource_type, action, constraint?)`.
• `role_permissions(role_id, permission_id)`.
• `assignments(subject_id, role_id, scope)` — scope: глобальный/по проекту/по объекту.

• `policy(id, effect=allow|deny, target: {subject, resource, action}, condition: expr, priority, version, status)`.

4) Принципы принятия решений

Deny-overrides: явные запреты приоритетнее разрешений.
Least Privilege (PoLP): выдавайте минимально необходимый доступ, расширяйте через условия.
Separation of Duties (SoD): запрет комбинаций ролей/действий (например, «создал платеж» ≠ «апрувнул»).
Context-aware: усиливайте требования при повышенном риске (нет MFA, подозрительный IP).
Determinism: одинаковый контекст → одинаковый ответ; фиксируйте версию политики в журнале.

5) Паттерны реализации

5.1 Гибрид RBAC→ABAC (кондиционирование)

yaml
Declarative Policy Example
- id: doc_read_own effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","owner"] }
condition: resource. owner_id == subject. id

- id: doc_read_team effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","viewer"] }
condition: subject. team_id in resource. shared_team_ids

- id: doc_read_confidential_external effect: deny target: { action: read, resource. type: document }
condition: resource. classification == "confidential" and subject. tenant_id!= resource. tenant_id priority: 100 # deny high priority

5.2 Row/Field-Level Security

На уровне БД: политики RLS (по `tenant_id`, `owner_id`).
На уровне API: фильтруйте коллекции и маскируйте поля, если нет `allow: read_sensitive_fields`.

5.3 Решения «step-up»

allow if action == "export" and subject. mfa_verified == true else deny

5.4 Временные допуски

Гранты с TTL: `assignment.expires_at`, «окна» доступа (в рабочее время региона ресурса).

6) Производительность и кэширование

Кэш решений (decision cache) по ключу `(subject_hash, resource_key, action, policy_version)` с коротким TTL.
Edge-кэш атрибутов субъекта (claims в токене) + lazy-fetch атрибутов ресурса.
Incremental invalidation: инвалидация по событиям (смена ролей, изменение политики, перевод ресурса в «confidential»).
Batch-проверки: для списков — оценивайте «фильтром» (policy-predicate pushdown), чтобы не дергать PDP построчно.

7) Многоарендность (Multi-tenant)

В каждой таблице — `tenant_id`; политики по умолчанию ограничивают доступ внутри аренды.
Администраторы аренды управляют только ролями/правами своей аренды.
Кросс-арендный доступ — исключительно через явные приглашения/шэринг с явным deny-override.

8) Администрирование и жизненный цикл политик

Версионирование: `policy.version` в ответе PDP, храните в аудите.
Среды: draft → canary (части трафика/теневой режим) → prod.
Test matrix: таблицы истинности по ключевым ролям/атрибутам (контрактные тесты).
Change management: мерж-реквесты на политики с рецензированием безопасности/комплаенса.

9) Аудит и наблюдаемость

Журнал решений: `decision_id`, `subject`, `action`, `resource_ref`, `result`, `matched_policies`, `policy_version`, `attributes_digest`.
Метрики: QPS PDP, латентность p95, hit-rate кэша, доля deny, частота step-up, инциденты SoD.
Трассировки: span на вызов PDP; корреляция с запросом API.
Реплей: возможность «переиграть» исторические решения на новой версии политики (safety check).

10) Интеграция с аутентификацией и токенами

Идентичность — из IdP (OIDC/SAML). Токены несут минимум атрибутов: `sub`, `tenant`, `roles`, `auth_time`, `amr`, `scopes`.
Для ABAC подтягивайте «тяжелые» признаки с серверной стороны (PIP), чтобы не надувать токен.
Подписанные resource tokens (capability/приглашения) — для строго ограниченных делегирований.

11) Псевдокод PDP (упрощенно)

python def decide(subject, resource, action, env, policies):
matched = []
effect = "deny"
Explicit DENYs with priority for p in sorted (policies, key = lambda x: x.priority, reverse = True):
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
if p. effect == "deny":
return Decision("deny", matched, p. version)
Looking for ALLOW for p in policies:
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
effect = "allow"
break return Decision(effect, matched, max_version(matched, policies))

12) Анти-паттерны

«Роль = страница» (сотни мелких ролей без модели предметной области).
Хранение политик только в коде без версий/аудита.
Отсутствие deny-override и SoD → повышение риска мошенничества.
Жесткие списки `user_id` в правилах (вместо атрибутов/отношений).
Отсутствие фильтрации на уровне данных (RLS) при наличии фильтра только в UI.
Синхронизация ролей через ручные скрипты без событий и инвалидации кэшей.

13) Кейсы и рецепты

13.1 Поле-уровневая маскировка:

allow read invoice when subject. roles includes "support"
mask fields ["card_last4", "billing_email"] unless subject. role == "finance"

13.2 Экспорт данных только с MFA:

allow export if subject. mfa_verified and env. ip in cidr("203. 0. 113. 0/24")

13.3 SoD:

deny approve_payment if subject. performed_actions includes ("create_payment" within last 24h)

13.4 Делегирование (ограниченный токен):

Capability-токен содержит `resource_id`, `actions=["read"]`, `expires_at`, `aud`. PEP проверяет подпись и срок.

14) Тестирование

Юнит-тесты политик: таблицы истинности по основным комбинациям.
Property-based: генерация случайных атрибутов для поиска «дырок».
Golden-tests: фиксация набора решений для критичных эндпойнтов.
Canary/Shadow: параллельная оценка старой и новой версий политик с логированием расхождений.

15) Связанные способности раздела «Архитектура и Протоколы»

Аутентификация и авторизация (OIDC/OAuth2)

Управление согласиями

Токенизация и управление ключами

Наблюдаемость: логи, метрики, трассировки

Гео-маршрутизация и локализация

Шифрование At Rest / In Transit

16) Чек-лист архитектора

1. Определены предметные роли и их иерархии?
2. Есть ли гибридная модель: роли + условия на атрибутах?
3. Реализован PDP с deny-overrides, SoD и step-up?
4. Где PEP? (шлюз, бэкенд, БД, UI) — везде ли единообразно?
5. Настроены кэши решений и инвалидация по событиям?
6. Политики версионируются, тестируются, раскатываются по процессу?
7. Включены аудит решений, метрики и трассировки?
8. Поддерживается многоарендность и RLS/field-masking?
9. Есть runbook на инциденты и регрессию политик?

Заключение

RBAC обеспечивает управляемость, ABAC — контекст и точность. Комбинируя роли с атрибутными условиями, разделяя PDP/PEP, внедряя кэширование, аудит и тестирование политик, вы строите авторизацию как платформенную способность: предсказуемую, проверяемую и масштабируемую для продуктовых и регуляторных требований.