Ієрархія акаунтів і субкористувачів

(Розділ: Операції та Управління)

1) Завдання і принципи

Ієрархія акаунтів визначає як організації і люди отримують доступ до ресурсів платформи і як розподіляються права, квоти, бюджети і відповідальність.

• Separation of Concerns: структуру бізнесу відображаємо в дереві сутностей, а права - в політиках.
• Least Privilege: за замовчуванням - мінімальні ролі, тимчасове підвищення через JIT.
• Composability: ролі/квоти/ліміти успадковуються і перевизначаються.
• Policy-as-Code: політики доступу, квоти, білінг - версіоновані артефакти.
• Auditability: кожна дія корелюється з суб'єктом, контекстом і підписом.

2) Референс-модель ієрархії

Tenant
├─ Account - legally/operationally significant unit
│ ├─ Sub-account - Product/Region/Team/Project
│ │ ├─ Spaces/Projects/Environments: prod/stage/dev
│ │ └─ Roles and Groups (RBAC/ABAC) for People and Services
│ └─ Shares (limits, budgets, keys, integrations)
└─ Marketplace/Integrations/Affiliates (Outer Loops)

• Tenant: власник договорів, білінгу високого рівня, глобальних політик і SSO.
• Account: ізольована зона відповідальності (бренд/країна/БЕ); власні бюджети/ліміти.
• Sub-account: робоча одиниця (продукт/потік/команда); свої ключі, квоти, ролі та аудит.

3) Моделі авторизації

RBAC: роли Owner/Admin/Operator/Viewer/Billing/Compliance.
ABAC: атрибуты `region`, `tenant`, `account`, `environment`, `risk_score`, `device_posture`.
ReBAC: відносини «володіє/бере участь/рев'юїт» для проектів і секретів.

Практика: гібрид - RBAC як базис, що читається, ABAC для контекстних обмежень (регіон/час/пристрій), ReBAC для володіння ресурсами.

4) Делегування та успадкування

Делегування вниз: Tenant-адмін видає роль Account Admin, той - Sub-account Maintainer.
Перевизначення: квоти/ліміти/політики можуть посилюватися вниз по дереву.
Trust Boundaries: PII/фінанси - тільки в «зонах довіри» рівня Account; Sub-account бачить токени/агрегати.
Break-glass: аварійний доступ c коротким TTL, авто-алертом і пост-мортемом.

5) Квоти, бюджети, білінг

Квоти: запити/сек, подій/день, egress, сховище, ключі/вебхуки.
Бюджети: місячні капи та алерти (80/90/100%), авто-тротлінг/призупинення.
Білінг: інвойси на рівні Tenant/Account; розрізи по Sub-account і тегам (cost centers).
Transfer Pricing: внутрішні рознарядки між BU/регіонами.
Fair-use: публічні ліміти, rate-limits, захист від «бурстів».

6) Ідентичності та SSO/SCIM

SSO (SAML/OIDC): централізований вхід на рівні Tenant.
SCIM: автоматичне створення/деактивація користувачів/груп і прив'язка до ролей.
JML (Joiner/Mover/Leaver): авто-видача стартових ролей, перегляд при перекладі, миттєвий відгук при звільненні.
MFA/FIDO2: обов'язкова для адмінів, фінансів і доступу до PII.
Device Posture: допуск за станом пристрою (шифрування, EDR).

7) Сервісні обліки та ключі

Service Account per Sub-account + Environment, без shared-секретів.
Workload Identity: короткоживучі токени, прив'язка до поду/функції.
KMS/Vault: ротація секретів, доступ за ролями, DSSE-підписи.
Вебхуки: підписи HMAC/EdDSA,'nonce + timestamp', TTL-вікно.

8) Модель даних (спрощено)

`tenant` `{id, name, sso, billing_profile, policies[]}`

`account` `{id, tenant_id, region, legal_entity, quotas{}, budgets{}, risk_tier}`

`sub_account` `{id, account_id, product, environment, keys[], webhooks[], limits{}}`

`role` `{id, scope: tenant|account|sub_account, permissions[]}`

`membership` `{subject_id, role_id, scope_ref, ttl, justification}`

`policy` `{type: rbac|abac|sod|quota, version, rules, signature}`

`audit_event` `{who, what, where, when, trace_id, signature}`

`quota_usage` `{scope_ref, metric, window, used, cap}`

9) Контракти API

• 'POST/tenants/{ id }/accounts'- створити Account (політики/квоти/білінг).
• 'POST/accounts/{ id }/sub-accounts'- створити Sub-account (ключі, вебхуки).
• 'PUT/roles/{ id}'- політика ролі;'POST/memberships'- призначити роль.
• 'POST/access/elevate'- JIT-підвищення з TTL і обгрунтуванням.
• 'GET/quotas/usage'- використання/кап;'POST/quotas/override'.

• `GET /audit/events? scope =...'- підписані логи.
• 'GET/status/access'- діючі ролі/TTL/ключі.
• Вебхуки: `QuotaCapReached`, `RoleExpiring`, `KeyRotationDue`, `PolicyChanged`.

10) RACI (ключові області)

11) Метрики та SLO

TTG (Time-to-Grant): медіана видачі стандартного доступу ≤ 4 год.
JIT Coverage: ≥ 80% привілейованих операцій через тимчасові ролі.
SoD Violations: 0 в prod; TTR усунення ≤ 24 год.
Orphaned Access: частка «забутих» прав ≤ 0. 1%.
Quota Accuracy: збіг нарахувань/використання ≥ 99. 99%.
Audit Completeness: 100% критичних дій з підписом/квитанцією.

12) Дашборди

Access Health: активні ролі за рівнями, що закінчуються TTL, порушення SoD.
FinOps: використання квот, прогноз бюджету, аномалії egress/compute.
Security: ротація ключів, провали MFA/SSO, ризик-скор когорт.
Compliance: статус рецертифікації, аудит-логи, порушення політик.
Operations: MTTR запитів на доступ, TTFI для нових команд.

13) Розмежування даних і приватність

Data Domains: PII/фінанси - тільки на рівні Account; Sub-account - агрегати/токени.
Регіональність: локалізація даних і ключів per-region (зони довіри).
Запити до PII: тільки через затверджені джоби; токенізація та маскування.

14) Ризики та анти-патерни

Flat-модель: всі - «адміни» → інциденти і витоки.
Shared-секрети: невідслідковуваність і неможливість відгуків.
Немає SoD: одна людина створює і затверджує виплати/ліміти.
Нерознесені середовища: dev-ключі в prod; змішування тестових і реальних даних.
«Нескінченні» ролі: без TTL/рецертифікації → накопичення ризиків.
Слабкі квоти: один Sub-account «з'їдає» ємність всіх.

15) Плейбуки інцидентів

Компрометація ключа Sub-account: негайний відгук, ротація залежностей, перерахунок квот, аудит останніх 7-30 днів.
Перевищення квот: автоматичний тротлінг/паузер, повідомлення власника, тимчасовий бюджетний капітал.
Порушення SoD: блокування операції, тимчасове зняття ролі, розслідування і фіксація політики.
Підміна вебхуків: заборона прийому без підпису/поза TTL, re-key, статус-ендпоінт звірок.

16) Онбординг і життєвий цикл

1. Ініціалізація Tenant: SSO/SCIM, білінг-профіль, глобальні політики.
2. Створення Account: регіони, квоти, бюджети, зони даних, базові ролі.
3. Sub-account: ключі/вебхуки, ролі команд, інтеграції.
4. JML/Рецертифікація: щоквартальний перегляд прав, авто-зняття «сплячих».
5. EOL: архів, відкликання ключів, перенесення володіння, закриття білінгу.

17) Чек-лист впровадження

• Узгодити дерево Tenant → Account → Sub-account і правила спадкування.
• Описати ролі (RBAC) і контекстні політики (ABAC), матрицю SoD.
• Запустити SSO/SCIM, JML-процеси і JIT-підвищення.
• Ввести квоти/бюджети/кап-правила і алертинг.
• Розгорнути KMS/Vault, ротації і заборона shared-секретів.
• Включити політики-як-код, підписані релізи і WORM-журнали.
• Налаштувати API/вебхуки управління, статус-ендпоінти і аудит.
• Побудувати дашборди Access/FinOps/Security/Compliance.
• Провести GameDay: витік ключа, квота-шторм, відмова IdP, порушення SoD.
• Регулярно рецертифікувати ролі і переглядати ліміти.

18) FAQ

Де тримати межу між Account і Sub-account?
Там, де змінюються фінанси/комплаєнс/регуляторика (Account), а Sub-account - про команду/продукт/середовище.

Чи можна «склеювати» квоти декількох Sub-account?
Так, через пули і пріоритети, але із запобіжниками від «випалювання» ємності.

Як швидко видати тимчасовий доступ?
JIT-заявка з MFA і TTL, автологування і пост-мортем для привілейованих сесій.

Чи потрібні різні ключі по середах?
Обов'язково: окремі Service Accounts/ключі для dev/stage/prod з ізоляцією мереж і прав.

Резюме: Ієрархія акаунтів і субкористувачів - це каркас керованості: читана структура сутностей, успадковані політики, строгі квоти і білінг, безпечні ідентичності і доказовий аудит. Впровадивши гібрид RBAC/ABAC/ReBAC, JIT/SoD і policy-as-code, ви отримаєте швидкий онбординг, передбачувані витрати і стійку безпеку при масштабуванні по продуктах, командах і регіонах.