Hisoblar va sub foydalanuvchilar ierarxiyasi

(Bo’lim: Operatsiyalar va Boshqaruv)

1) Vazifa va prinsiplar

Hisoblar ierarxiyasi tashkilotlar va odamlar platforma resurslaridan qanday foydalanishini, huquqlar, kvotalar, byudjetlar va javobgarlik qanday taqsimlanishini belgilaydi.

• Separation of Concerns: biznes tuzilmasini mohiyat daraxtida, huquqlarni esa siyosatda aks ettiramiz.
• Least Privilege: andoza - minimal rollar, JIT orqali vaqtinchalik oshirish.
• Composability: rollar/kvotalar/limitlar meros qilib olinadi va qayta belgilanadi.
• Policy-as-Code: kirish siyosati, kvotalar, billing - versiya qilinadigan artefaktlar.
• Auditability: har bir harakat subyekt, kontekst va imzo bilan bog’liq.

2) Ierarxiyaning referens-modeli

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: shartnomalar, yuqori darajadagi billing, global siyosat va SSO egasi.
• Account: alohida javobgarlik zonasi (brend/mamlakat/BE); o’z budjetlari/limitlari.
• Sub-account: ish birligi (mahsulot/oqim/buyruq); o’z kalitlari, kvotalari, rollari va auditi.

3) Avtorizatsiya modellari

RBAC: роли Owner/Admin/Operator/Viewer/Billing/Compliance.
ABAC: атрибуты `region`, `tenant`, `account`, `environment`, `risk_score`, `device_posture`.
ReBAC: loyihalar va sirlar uchun «egalik/ishtirok/revyuit» munosabatlari.

Amaliyot: gibrid - RBAC o’qish bazasi sifatida, ABAC kontekst cheklovlari uchun (mintaqa/vaqt/qurilma), ReBAC resurslarga egalik qilish uchun.

4) Topshirish va meros

Pastga topshirish: Tenant-admin Account Admin rolini beradi, u Sub-account Maintainer.
Qayta belgilash: kvotalar/limitlar/siyosatlar yogʻoch boʻylab qattiqlashishi mumkin.
Trust Boundaries: PII/moliya - faqat Account darajasidagi «ishonch zonalarida»; Sub-account token/agregatlarni koʻradi.
Break-glass: qisqa TTL, avto-alert va post-mortem bilan avariya holatida kirish.

5) Kvotalar, budjetlar, billing

Kvotalar: so’rovlar/sek, voqealar/kun, egress, saqlash, kalitlar/vebxuklar.
Budjetlar: oylik kaplar va alertlar (80/90/100%), avto-trotling/to’xtatib turish.
Billing: Tenant/Account darajasidagi invoyslar; Sub-account va teglar bo’yicha kesmalar (cost centers).
Transfer Pricing: BU/mintaqalar orasidagi ichki tartib.
Fair-use: ommaviy limitlar, rate-limits, burstlardan himoya qilish.

6) Identifikatsiyalar va SSO/SCIM

SSO (SAML/OIDC): Tenant darajasidagi markazlashtirilgan kirish.
SCIM: Foydalanuvchi/guruhlarni avtomatik ravishda yaratish/oʻchirish va rollarga bogʻlash.
JML (Joiner/Mover/Leaver): boshlang’ich rollarni avtomatik berish, o’tkazishda qayta ko’rib chiqish, ishdan bo’shatilganda darhol chaqirib olish.
MFA/FIDO2: ma’murlar, moliya va PII dan foydalanish majburiydir.
Device Posture: qurilmaning holati boʻyicha ruxsat (shifrlash, EDR).

7) Servis hisob-kitoblari va kalitlari

Service Account per Sub-Account + Environment, shared-sirlarsiz.
Workload Identity: qisqa jonli tokenlar, pod/funksiyalarga bogʻlash.
KMS/Vault: sirlarni almashtirish, rollarga kirish, DSSE imzolari.
Vebxuklar: HMAC/EdDSA,’nonce + timestamp’, TTL-oyna imzolari.

8) Ma’lumotlar modeli (soddalashtirilgan holda)

`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 kontraktlari

• ’POST/tenants/{ id }/accounts’ - Account (siyosat/kvota/billing) yaratish.
• ’POST/accounts/{ id }/sub-accounts’ - Sub-account (kalitlar, vebxuklar) yaratish.
• ’PUT/roles/{ id}’ - rol siyosati;’POST/memberships’- rol tayinlash.
• ’POST/access/elevate’ - TTL va asosli JIT-oshirish.
• ’GET/quotas/usage’ - foydalanish/kaps;’POST/quotas/override’.

• `GET /audit/events? scope =...’- imzolangan loglar.
• ’GET/status/access’ - amaldagi rollar/TTL/kalitlar.
• Вебхуки: `QuotaCapReached`, `RoleExpiring`, `KeyRotationDue`, `PolicyChanged`.

10) RACI (asosiy sohalar)

11) Metrika va SLO

TTG (Time-to-Grant): standart foydalanish vositasi ≤ 4 soat.
JIT Coverage: vaqtinchalik rollar orqali imtiyozli operatsiyalarning 80% ≥.

SoD Violations: 0 в prod; TTR bartaraf etish ≤ 24 soat

Orphaned Access: «unutilgan» huquqlar ulushi ≤ 0. 1%.
Quota Accuracy: hisoblash/foydalanish mos kelishi ≥ 99. 99%.
Audit Completeness: 100% tanqidiy harakatlar imzo/kvitansiya bilan.

12) Dashbordlar

Access Health: darajalar bo’yicha faol rollar, tugaydigan TTL, SoD buzilishlari.
FinOps: kvotalardan foydalanish, byudjet prognozi, egress/compute anomaliyalari.
Security: kalitlarning aylanishi, MFA/SSO muvaffaqiyatsizliklari, xavf-tezkor kogortlar.
Compliance: resertlash maqomi, audit-loglar, siyosatni buzish.
Operations: MTTR kirish soʻrovlari, yangi buyruqlar uchun TTFI.

13) Ma’lumotlarni chegaralash va maxfiylik

Data Domains: PII/moliya - faqat Account darajasida; Sub-account - agregatlar/tokenlar.
Hududiylik: per-region (ishonch zonasi) ma’lumotlari va kalitlarini mahalliylashtirish.
PIIga so’rovlar: faqat tasdiqlangan joblar orqali; tokenlash va niqoblash.

14) Xatarlar va anti-patternlar

Flat-model: hammasi - «adminlar» → hodisalar va oqishlar.
Shared-sirlar: kuzatib bo’lmasligi va sharhlarning mumkin emasligi.
SoD yo’q: bir kishi to’lovlar/limitlarni yaratadi va tasdiqlaydi.
Joylashmagan muhit: dev-kalitlar prodga; test va haqiqiy ma’lumotlarni aralashtirish.
«Cheksiz» rollar: TTL/resertifikatsiyasiz → xavflarning to’planishi.
Kuchsiz kvotalar: bitta Sub-account hamma sigʻimini «yeydi».

15) Hodisalar pleybuklari

Sub-account kalitini buzish: zudlik bilan qaytarib olish, qaramliklarni almashtirish, kvotalarni qayta hisoblash, oxirgi 7-30 kunlik audit.
Kvotalardan oshib ketishi: avtomatik trottling/pauzer, egasini xabardor qilish, vaqtinchalik budjet kapitali.
SoD buzilishi: operatsiyani blokirovka qilish, rolni vaqtincha olib tashlash, siyosatni tekshirish va qayd etish.
Vebxuklarni almashtirish: imzosiz/TTLdan tashqarida qabul qilishni taqiqlash, re-key, solishtirma holati.

16) Onbording va hayot sikli

1. Tenant tashabbusi: SSO/SCIM, billing profili, global siyosatchilar.
2. Account yaratish: hududlar, kvotalar, byudjetlar, maʼlumotlar zonalari, asosiy rollar.
3. Sub-account: kalitlar/vebxuklar, jamoalar rollari, integratsiya.
4. JML/Resertifikatsiya: huquqlarni har chorakda qayta ko’rib chiqish, «uxlayotgan» larni avto-olib tashlash.
5. EOL: arxiv, kalitlarni qaytarib olish, egalikni o’zgartirish, billingni yopish.

17) Joriy etish chek-varaqasi

• Tenant daraxti → Account → Sub-account va meros qoidalarini kelishish.
• Rollar (RBAC) va kontekstli siyosatlar (ABAC), SoD matritsasini tavsiflash.
• SSO/SCIM, JML va JIT jarayonlarini ishga tushiring.
• Kvotalar/byudjetlar/kapt-qoidalar va alerting joriy etilsin.
• KMS/Vault, rotatsiya va shared sirlarini taqiqlash.
• Kodli siyosatni, imzolangan relizlarni va WORM jurnallarini kiritish.
• Boshqaruv API/vebxuklarini, status-endpointlarni va auditni moslash.
• Access/FinOps/Security/Compliance dashbordlarini qurish.
• O’tkazing GameDay: kalit sizib chiqishi, kvota bo’roni, IdP nosozligi, SoD buzilishi.
• Rollarni muntazam ravishda qayta ko’rib chiqish va limitlarni qayta ko’rib chiqish.

18) FAQ

Account va Sub-account chegarasini qayerda saqlash kerak?
Moliyaviy/komplayens/regulyator (Account) o’zgaradigan, Sub-account esa jamoa/mahsulot/muhit haqida.

Bir nechta Sub-account kvotalarini yopishtirish mumkinmi?
Ha, hovuzlar va ustuvorliklar orqali, lekin sig’imning «kuyishiga» qarshi himoya bilan.

Vaqtinchalik kirishni qanchalik tez berish kerak?
MFA va TTL bilan JIT-ariza, avtologlashtirish va imtiyozli sessiyalar uchun post-mortem.

Chorshanba kuni turli kalitlar kerakmi?
Majburiy: alohida Service Accounts/dev/stage/prod uchun tarmoqlar va huquqlar izolyatsiyalangan kalitlar.

Xulosa: Hisoblar va subpudratchilar ierarxiyasi - bu boshqaruvning asosi: mohiyatning o’qiladigan tuzilishi, meros siyosati, qat’iy kvotalar va billing, xavfsiz o’ziga xoslik va isbotlanadigan audit. RBAC/ABAC/ReBAC, JIT/SoD va policy-as-code gibridini joriy etish orqali siz mahsulotlar, jamoalar va hududlar bo’yicha ko’paytirishda tezkor onbording, oldindan aytib bo’ladigan xarajatlar va barqaror xavfsizlikka ega bo’lasiz.