Рольовий рушій

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'з типом і атрибутами: `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, впроваджуючи кешування, аудит і тестування політик, ви будуєте авторизацію як платформну здатність: передбачувану, що перевіряється і масштабується для продуктових і регуляторних вимог.