Аккаунттар мен қосалқы пайдаланушылардың иерархиясы

(Бөлім: Операциялар және Басқару)

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: оқшауланған жауапкершілік аймағы (бренд/ел/BE); меншікті бюджеттер/лимиттер.
• 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: қысқа 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' - TTL және негіздемесі бар JIT-жоғарылату.
• 'GET/quotas/usage' - пайдалану/kap; '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) Енгізу чек-парағы

• Tree 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 квоталарын «желімдеуге» бола ма?
Иә, пулдар мен басымдықтар арқылы, бірақ сыйымдылықты «күйдіруден» сақтандырғыштармен.

Уақытша кіруді қалай тез беруге болады?
MFA және TTL бар JIT-өтінім, автологиялық және артықшылықты сессиялар үшін пост-мортем.

Сәрсенбі күндері әртүрлі кілттер керек пе?
Міндетті: жеке Service Accounts/dev/stage/prod кілттері желілер мен құқықтарды оқшаулаумен.

Түйіндеме: Аккаунттар мен қосалқы пайдаланушылардың иерархиясы - бұл басқарудың қаңқасы: мәнінің оқылатын құрылымы, мұраға қалған саясаткерлер, қатаң квоталар мен биллинг, қауіпсіз сәйкестілік және дәлелденетін аудит. RBAC/ABAC/ReBAC, JIT/SoD және policy-as-code гибридтерін енгізу арқылы сіз өнімдер, командалар және өңірлер бойынша масштабтау кезінде жылдам онбординг, болжамды шығындар және тұрақты қауіпсіздік аласыз.