Спадкування прав і політик

1) Навіщо екосистемі успадкування

• Швидкість масштабування: нові вузли/продукти отримують стандартизовані політики «з коробки».
• Однаковість і комплаєнс: верхньорівневі guardrails автоматично діють на дочірні ресурси.
• Прозорість і аудит: передбачуваний порядок застосування, мінімізація винятків.

2) Базова онтологія доступу

2. 1 Ієрархічні рівні

1. Організація/Екосистема → глобальні політики безпеки/даних/RG.
2. Тенант/Партнер → квоти, юрисдикції, межі даних, SLO-обмеження.
3. Домен (контент, платежі, KYC, афіліати, аналітика, події) → профіль доступу та мережеві периметри.
4. Сервіс/Додаток → API/топіки/сховища.
5. Ресурс → таблиця/топік/ендпоінт/секрет/стрім.

2. 2 Моделі авторизації

RBAC (ролі): швидко, прозоро, добре успадковується (роль → набір дозволів).
ABAC (атрибути): гнучкість (гео, юрисдикція, ризик-скор, час).
ReBAC (відносини): доступ «до ресурсів, пов'язаних з моїми сутностями» (оператор ↔ кампанія ↔ дані).
Практика: гібрид RBAC + ABAC, ReBAC - для графів володіння/кампаній.

3) Політики, скоупи та пріоритети

3. 1 Типи політик

Allow/Deny: явний дозвіл/заборона.
Guardrails: обов'язкові обмеження (PII out-of-scope, ліміти експорту, time-based).
Quotas/Rate: ліміти rps/txn/stream/event по тенанту/каналу/регіону.
Contextual: умови щодо гео/ASN/пристрою/часу/верифікації/ризик-скорингу.
Delegation: делегування частини прав з обмеженим скоупом/TTL.

3. 2 Спадкування та порядок застосування

Deny-first: заборона сильніша за дозвіл.
Precedence: `Guardrails (root) > Deny (parent) > Allow (parent) > Deny (child) > Allow (child)`.
Shadowing: дочірній Allow не скасовує батьківський Guardrail/Deny.
Override за винятками: тільки письмово оформлені «justified exceptions» з TTL і автосняттям.

3. 3 Скоупи

Org/Tenant: глобальні правила і квоти.
Environment: prod/stage/sandbox - жорсткість зростає до prod.
Jurisdiction: локалізація даних, RG-обмеження.
Data Class: `Public/Internal/Confidential/PII-Sensitive/Financial`.
Operation: read/write/admin/export/impersonate.

4) Дерева політик (Policy Trees)

4. 1 Структура

/org
/tenants/{tenantId}
/domains/{payments    kyc    content    affiliates    analytics    events}
/services/{api    broker    db    storage    sfu}
/resources/{endpoint    topic    table    bucket    secret}

На кожному вузлі: список політик (allow/deny/guardrail/quota/context). Спадкування зверху вниз, локальні політики додають обмеження, але не знімають глобальні заборони.

4. 2 Приклади

Guardrail org-level: «PII не можна виводити у вебхуки за межі білого списку країн».
Tenant-level: "KYC-оператори з країн X заборонені; експорт звітів тільки агрегати".
Domain payments: «Write тільки через сервіс-аккаунт з mTLS і ключем ≤ 24год».
Service api: «POST/deposits тільки з'Idempotency-Key'».
Resource topic: "Читання'kyc _ status'тільки службам з роллю'KYC. moderation` и ABAC `verified=true`».

5) Делегування та тимчасові права

Just-in-Time (JIT) Access: видача на час виконання (TTL, single-use).
Break-Glass: екстрений доступ з негайним аудитом і подальшим розбором.
Scoped Tokens: мінімальний набір «scopes» (read:topic/kyc; write:api/deposit) + audience/issuer.
Chain-of-Trust: міжсервісні токени з прив'язкою до пристрою/ASN/підмережі.
Impersonation: тільки через проксі-сервіс з журналом і лімітами.

6) Спадкування в доменах

6. 1 Платежі (PSP/APM)

Батьківський guardrail: "всі виклики - через mTLS + JWS, таймаут ≤ N, ретраї з джиттером; чарджбек-хук обов'язковий".
Дочірній сервіс може додавати квоти/капси на АРМ/регіон. Deny на прямі виклики в обхід оркестратора.

6. 2 KYC/AML

Батьківський Deny: «сирий документ не можна писати в аналітику».
Дочірній Allow: «передавати тільки hash/вердикт/категорії ризику».

6. 3 Контент/стрімінг

Org guardrail: «мінімальний бітрейт і latency-SLO».
Tenant-override: «зниження якості в роумінгу, але не нижче SLO».
Resource: доступ до конкретного live-столу - тільки сегментів з RG-OK.

6. 4 Події/EDA

Root: схеми/версії in-registry, exactly-once за бізнес-змістом.
Domain: ключі партій, дедуп-політика.
Service: хто може писати/читати топік; quotas/lag-budget.

7) Приватність і Zero Trust

PII-мінімізація і токенізація за замовчуванням, політика «не можна де-токенізувати поза сейф-зон».
Сегментація мереж: vendor-VPC, egress-allow-list, міжзонні політики міша.
mTLS/JWS/HMAC для S2S і вебхуків, короткоживучі ключі (JWKS/rotation).
SoD (Segregation of Duties): ролі читання ≠ ролі адміністрування ≠ ролі випуску ключів.
Юрисдикції: успадковані правила локалізації, заборона транскордонного експорту ПДн без DPA/DPIA.

8) Спостережуваність і аудит спадкування

Policy Evaluation Trace: журнал «яка політика де спрацювала» з'traceId'.
Diff-лог: хто/коли змінив дерево політик; WORM-сховище.
Conformance-тести: регулярні прогони сценаріїв доступу (allow/deny; export; impersonation).
Алерти: спрацьовування deny/guardrail, перевищення квот, спроби обходу.

9) Конфлікти та їх вирішення

Визначити клас: колізія Allow/Deny, порушення guardrail, перетин ABAC-умов.
Застосувати порядок precedence (див. § 3. 2).
Класифікувати виняток: тимчасове (TTL), постійне (правило), помилкове (rollback).
Внести артефакти: RFC/CR-заявка, посилання на ризик-оцінку, автоперевірки в CI.

10) Анти-патерни

Ручні видані права без TTL («назавжди»).
Allow-за-замовчуванням і «мовчазні» винятки.
Успадкування без видимих guardrails - дочірні гілки перекривають безпечні правила.
Змішання ролей (адмін = аналітик = оператор) - немає SoD.
Експорт сирих ПДн в сторонні сервіси, «тимчасові» вебхуки без підпису.
Відключений аудит при break-glass.
Плаваючі версії схем: роз'їжджається аналітика/EDA, deny не спрацьовує на нові поля.

11) Чек-лист проектування дерева політик

1. Класифікуйте дані (Public/Internal/Confidential/PII/Financial).
2. Визначте рівні ієрархії та власників вузлів (RACI).
3. Задайте guardrails на корені (Zero Trust, PII, RG, юрисдикції).
4. Сформуйте ролі RBAC і атрибути ABAC; увімкніть SoD.
5. Опишіть скоупи (org/tenant/env/jurisdiction/data class/operation).
6. Включіть делегування/TTL і break-glass з аудиторським шлейфом.
7. Пропишіть precedence і конфліктологію (deny-first, override-процес).
8. Налаштуйте спостережуваність: evaluation-trace, diff-лог, алерти.
9. Запустіть conformance-набір і регулярні рев'ю винятків.
10. Документуйте: портал політик, приклади, пісочниці, симулятори.

12) Метрики зрілості

Coverage: частка ресурсів, покритих наслідуваними політиками і конформанс-тестами.
Drift: число локальних виключень/100 ресурсів; середній TTL виключення.
SoD Score: частка користувачів з поділом обов'язків.
PII Exposure: число експортів за межі сейф-зон (цільове = 0).
Auditability: % запитів з evaluation-trace; MTTR по конфліктах доступу.
Change Velocity: час CR з політики з урахуванням спадкування.

13) Приклади шаблонів (схематично)

• Deny: `export:PII` if `destination. country ∉ whitelist`
• Require: `mTLS && JWS` for `webhook:`
• Quota: `read:event: ≤ X rps per tenant`

• Allow: `write:api/deposit` if `verified && risk_score < T && geo ∈ allowed`
• Deny: `direct:psp/`

• Allow: `read` for role `KYC. moderation` where `jurisdiction == resource. jurisdiction`
• Deny: `write` except service `kyc-orchestrator`

14) Дорожня карта еволюції

v1 (Foundation): дерево політик, guardrails на корені, RBAC, deny-first, аудит змін.
v2 (Integration): ABAC, делегування/TTL, conformance-набір, evaluation-trace.
v3 (Automation): авто-скоупінг за юрисдикцією/даними, policy-as-code, автоперевірки в CI/CD, автокарантин порушень.
v4 (Networked Governance): міжпартнерська федерація політик, крос-тенант делегування з криптопідписом, предиктивні підказки (ризик-скор) для видачі прав.

Коротке резюме

Спадкування прав і політик - це каркас безпечної і швидкої екосистеми. Побудуйте policy-tree з guardrails на корені, застосовуйте deny-first і precedence, комбінуйте RBAC + ABAC + ReBAC, використовуйте делегування з TTL і строгий аудит. Автоматизуйте перевірки і управління винятками - і у вас вийде масштабована, комплаєнтна і передбачувана модель доступу для всієї мережі учасників.