ანგარიშებისა და მომხმარებლების იერარქია

(განყოფილება: ოპერაციები და კონტროლი)

1) ამოცანა და პრინციპები

ანგარიშის იერარქია განსაზღვრავს, როგორც ორგანიზაციებს და ადამიანებს აქვთ წვდომა პლატფორმის რესურსებზე და როგორ ნაწილდება უფლებები, კვოტები, ბიუჯეტები და პასუხისმგებლობა.

• საკონსულტაციო განყოფილება: ბიზნესის სტრუქტურა ასახულია ერთეულების ხეში, ხოლო უფლებები - პოლიტიკოსებში.
• Least Privilege: ნაგულისხმევი - მინიმალური როლები, დროებითი ზრდა JIT- ის საშუალებით.
• კომპოზიცია: როლები/კვოტები/ლიმიტები მემკვიდრეობით მიიღება და განისაზღვრება.
• 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)

• ტენანტი: ხელშეკრულებების მფლობელი, მაღალი დონის ბილინგი, გლობალური პოლიტიკოსი და SSO.
• ანგარიში: იზოლირებული პასუხისმგებლობის არეალი (ბრენდი/ქვეყანა/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 Admin გამოსცემს Account Admin- ის როლს, ეს არის Sub-account Maintainer.
განსაზღვრება: კვოტები/ლიმიტები/პოლიტიკოსები შეიძლება გამკაცრდეს ხეზე.
Trust Boundaries: PII/ფინანსები - მხოლოდ Account დონის „ნდობის ზონებში“; Sub-account ხედავს ნიშნებს/ერთეულებს.
Break glass: გადაუდებელი წვდომა მოკლე TTL, Alert alert და post-mortem.

5) კვოტები, ბიუჯეტები, ბილინგი

კვოტები: მოთხოვნები/წმ, მოვლენები/დღე, egress, საცავი, გასაღებები/ვებჰუკი.
ბიუჯეტები: ყოველთვიური ქუდი და ალერტები (80/90/100%), trotling/შეჩერება.
ბილინგი: ინვოისი Tenant/Account დონეზე; Sub-account და ჭდეების ჭდეები (cost centers).
Transfer Pricing: შიდა დემონტაჟი BU/რეგიონებს შორის.
Fair-use: საზოგადოებრივი ლიმიტები, საბინაო-ლიმიტები, დაცვა „ბუჩქებისგან“.

6) იდენტურობა და SSO/SCIM

SSO (SAML/OIDC): ცენტრალიზებული შესასვლელი Tenant დონეზე.
SCIM: მომხმარებლების/ჯგუფების ავტომატური შექმნა/დეაქტივაცია და როლების დაკავშირება.
JML (Joiner/Mover/Leaver): საწყისი როლების მანქანის გაცემა, თარგმანის გადასინჯვა, მყისიერი მიმოხილვა თანამდებობიდან გათავისუფლების შემდეგ.
MFA/FIDO2: სავალდებულოა admins, ფინანსები და PII წვდომა.
Device Posture: წვდომა მოწყობილობის მდგომარეობის შესახებ (დაშიფვრა, EDR).

7) მომსახურების ანგარიშები და გასაღებები

Service Account per Sub-account + Environment, საიდუმლოებების გარეშე.
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/წვდომა/სიჩქარე' - JIT ზრდა TTL- ით და დასაბუთება.
• 'GET/= tas/usage' - გამოყენება/კაპი; 'POST/= tas/override'.

• `GET /audit/events? scope =... '- ხელმოწერილი ლოგები.
• 'GET/status/Access' - მოქმედი როლები/TTL/გასაღებები.
• Вебхуки: `QuotaCapReached`, `RoleExpiring`, `KeyRotationDue`, `PolicyChanged`.

10) RACI (ძირითადი სფეროები)

11) მეტრიკა და SLO

• JIT Coverage: სასურველი ოპერაციების 80% -ზე მეტი დროებითი როლების საშუალებით.
• SoD Violations: 0 в prod; TTR აღმოფხვრა 24 საათზე
• Orphaned Access: „დავიწყებული“ უფლებების წილი 0. 1%.
• É ta Accuracy: დარიცხვის/გამოყენების დამთხვევა 99 ევრო. 99%.
• Audit Completeness: კრიტიკული მოქმედებების 100% ხელმოწერით/ქვითრით.

12) დაშბორდი

Access Health: აქტიური როლი TTL ამოწურვის დონეზე, SoD დარღვევები.
FinOps: კვოტების გამოყენება, ბიუჯეტის პროგნოზი, egress/compute ანომალიები.
უსაფრთხოება: გასაღებების როტაცია, MFA/SSO წარუმატებლობა, რისკის კოჰორტის შემცირება.
Compliance: რეცენზიფიკაციის სტატუსი, აუდიტის ლოგოები, პოლიტიკის დარღვევები.
ოპერაციები: MTTR წვდომის მოთხოვნა, TTFI ახალი გუნდებისთვის.

13) მონაცემების დელიმიტაცია და კონფიდენციალურობა

Data Domains: PII/ფინანსები - მხოლოდ Account დონეზე; Sub-account - დანაყოფები/ნიშნები.
რეგიონალურობა: მონაცემთა ლოკალიზაცია და ნდობის ზონები.
მოთხოვნები PII- სთვის: მხოლოდ დამტკიცებული ჯობის საშუალებით; ტოქსიკაცია და შენიღბვა.

14) რისკები და ანტი-ნიმუშები

Flat მოდელი: ყველა - „ადმირალი“ - ინციდენტები და გაჟონვა.
Shared საიდუმლოებები: მიმოხილვების უუნარობა და შეუძლებლობა.
არა SoD: ერთი ადამიანი ქმნის და ამტკიცებს გადახდებს/შეზღუდვებს.
განუყოფელი გარემო: dev გასაღებები; ტესტის და რეალური მონაცემების ნაზავი.
„გაუთავებელი“ როლები: TTL/რეცენზიფიკაციის გარეშე - რისკების დაგროვება.
სუსტი კვოტები: ერთი Sub-account „ჭამს“ ყველას.

15) ინციდენტების ფლეიბუკი

Sub-account გასაღების კომპრომისი: დაუყოვნებელი მიმოხილვა, დამოკიდებულების როტაცია, კვოტების დათვლა, ბოლო 7-30 დღის აუდიტი.
კვოტების ჭარბი რაოდენობა: ავტომატური trottling/პაუზერი, მფლობელის შეტყობინება, დროებითი ბიუჯეტის ქუდი.
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, როტაცია და საიდუმლოების აკრძალვა.
• ჩართეთ პოლიტიკოსები, როგორც კოდი, ხელმოწერილი გამოცემები და WORM ჟურნალები.
• კონფიგურაცია API/webhuks კონტროლი, სტატუს ენდოინტები და აუდიტი.
• Access/FinOps/Securiance/Compliance dashbords- ის აშენება.
• გაატარეთ GameDay: გასაღების გაჟონვა, კვოტა-ქარიშხალი, IDP უკმარისობა, SoD დარღვევა.
• რეგულარულად გადააკეთეთ როლები და გადახედეთ ლიმიტებს.

18) FAQ

სად უნდა შევინარჩუნოთ საზღვარი Account- სა და Sub-account- ს შორის?
სადაც იცვლება ფინანსები/შესაბამისობა/მარეგულირებელი (ანგარიში), ხოლო Sub-account - გუნდის/პროდუქტის/გარემოს შესახებ.

შესაძლებელია თუ არა რამდენიმე Sub-account- ის კვოტების „წებოვანი“?
დიახ, აუზებითა და პრიორიტეტებით, მაგრამ დაუკრავენ „დაწვის“ შესაძლებლობისგან.

როგორ სწრაფად მივცეთ დროებითი წვდომა?
JIT განაცხადი MFA და TTL- ით, ავტოლოგიისა და პრივილეგირებული სესიებისთვის.

საჭიროა ოთხშაბათს სხვადასხვა გასაღებები?
დარწმუნდით: ცალკეული სერვისის აკონტები/გასაღებები dev/stage/country ქსელებისა და უფლებების იზოლაციით.

რეზიუმე: ანგარიშების იერარქია და ქვე-მომხმარებლები არის მართვის ჩარჩო: ერთეულების წაკითხული სტრუქტურა, მემკვიდრეობითი პოლიტიკოსები, მკაცრი კვოტები და ბილინგი, უსაფრთხო თვითმყოფადობა და დადასტურებული აუდიტი. RBAC/ABAC/ReBAC, JIT/SoD და პოლიცია-as-code ჰიბრიდის შემოღებით, თქვენ მიიღებთ სწრაფ ონბორდს, პროგნოზირებულ ხარჯებს და სტაბილურ უსაფრთხოებას პროდუქციის, გუნდებისა და რეგიონების მასშტაბით.