როლური ძრავა

1) ავტორიზაციის მოდელები

RBAC (Role-Based წვდომის კონტროლი): სუბიექტი იღებს როლებს, როლებს უკავშირდება უფლებები. უბრალოდ მართვა, კარგია ტიპიური პასუხისმგებლობებისთვის.
ABAC (Atribute-Based წვდომის კონტროლი): გამოსავალი დამოკიდებულია საგნის, რესურსის, მოქმედებისა და გარემოს ატრიბუტებზე (დრო, IP, რეგიონი, რისკი). მოქნილი და მასშტაბური რთული წესებისთვის.
RBAC + ABAC ჰიბრიდი: როლები იძლევა „ძირითად“ უნარს, ატრიბუტები ვიწროვდება მას.
(სურვილისამებრ) ReBAC/Relationship-based: ურთიერთობების გრაფიკი (მფლობელი, გუნდის წევრი, დელეგატი), სასარგებლოა დოკუმენტური და ორგანული სტრუქტურებისთვის.

2) არქიტექტურა: PDP/PEP და ნაკადები

PEP (Policy Enforcement Point): გამოსავალი (API კარიბჭე, ზურგჩანთა მეთოდი, SQL ფენა, UI).
PDP (პოლიტიკა Decision Point): მომსახურება/ბიბლიოთეკა, რომელიც გამოითვლება 'ALLOW/DENY "პოლიტიკოსებისა და ატრიბუტებისთვის.
PIP (Policy Information Point): ატრიბუტების წყაროები (IdP/პროფილი, რესურსის მეტამონაცემები, რისკის ნაკადი, გეო).
PAP (პოლიტიკა ადაპტაციის წერტილი): ადმინისტრაციული ინტერფეისი/საცავი პოლიტიკოსი (ვერსიები, მონახაზები, პუბლიკაცია).

ნაკადი: მოთხოვნა PEP ქმნის კონტექსტს - PDP აძლიერებს დაკარგული ატრიბუტებს (PIP- ის საშუალებით) და ითვლის გადაწყვეტილებას PEP იყენებს (ველების დაშვება/აკრძალვა/შეწყვეტა).

3) მონაცემთა მოდელი

• `subject` (user/service) с атрибутами: `tenant_id`, `roles`, `departments`, `risk_level`, `mfa_verified`, `scopes`, `claims`.
• 'resource' c ტიპი და ატრიბუტები: 'ტიპი', 'owner _ id', 'tenant _ id', 'classification' (public/confidential), 'region', 'tags'.
• `action`: `read`, `write`, `delete`, `export`, `approve`, `impersonate` и т. п.
• `environment`: `time`, `ip`, `device`, `geo`, `auth_strength`, `business_context` (канал, тариф).

• 'roles (id, tenant _ id, name, inherits [])' - მხარი დაუჭირეთ იერარქიებსა და შაბლონებს.
• `permissions(id, resource_type, action, constraint?)`.
• `role_permissions(role_id, permission_id)`.
• 'assignments (subect _ id, role _ id, scope)' - scope: გლობალური/პროექტის/ობიექტის მიხედვით.

• `policy(id, effect=allow|deny, target: {subject, resource, action}, condition: expr, priority, version, status)`.

4) გადაწყვეტილების მიღების პრინციპები

Deny-overrides: აშკარა აკრძალვები უფრო პრიორიტეტულია, ვიდრე ნებართვები.
Least Privilege (PoLP): მიეცით მინიმალური საჭირო წვდომა, გააფართოვეთ პირობები.
Separation of Duties (SoD): როლების/მოქმედებების კომბინაციის აკრძალვა (მაგალითად, „შექმნა გადახდა“).
შემდეგი: გააძლიერეთ მოთხოვნები გაზრდილი რისკით (არა MFA, საეჭვო IP).
Determinism: იგივე კონტექსტი - იგივე პასუხი; ჩაწერეთ პოლიტიკის ვერსია ჟურნალში.

5) განხორციელების ნიმუშები

5. 1 ჰიბრიდი RBAC - ABAC (კონდიციონერი)

yaml
Declarative Policy Example
- id: doc_read_own effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","owner"] }
condition: resource. owner_id == subject. id

- id: doc_read_team effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","viewer"] }
condition: subject. team_id in resource. shared_team_ids

- id: doc_read_confidential_external effect: deny target: { action: read, resource. type: document }
condition: resource. classification == "confidential" and subject. tenant_id!= resource. tenant_id priority: 100 # deny high priority

5. 2 Row/Field-Level Security

DD დონეზე: RLS პოლიტიკოსები ('tenant _ id', 'owner _ id').
API დონეზე: გაფილტრეთ კოლექციები და შენიღბეთ ველები, თუ არა 'allow: read _ sensitive _ fields'.

5. 3 ნაბიჯის გადაწყვეტილებები

allow if action == "export" and subject. mfa_verified == true else deny

5. 4 დროებითი დაშვება

გრანტები TTL: 'assignment. expires _ at ', წვდომის „ფანჯრები“ (რესურსის რეგიონის სამუშაო საათებში).

6) პროდუქტიულობა და ქეშირება

decision cache გასაღები '(subect _ hash, resource _ key, action, policy _ version)' მოკლე TTL- ით.
საგნის ატრიბუტების Edge ქეში (კლაიმები ტოკენში) + lazy-fetch რესურსის ატრიბუტები.
Incremental invalidation: მოვლენების ინვალიდობა (როლების შეცვლა, პოლიტიკის შეცვლა, რესურსის გადაცემა „კონფიდენციალურობაში“).
Batch- ის შემოწმება: სიებისთვის - შეაფასეთ „ფილტრაცია“, ისე რომ PDP ხაზგარეშე არ გადააგდოთ.

7) მრავალფეროვნება (მულტი-ტენანტი)

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

8) პოლიტიკის ადმინისტრირება და სასიცოცხლო ციკლი

ვერსია: 'policy. version 'საპასუხოდ PDP, შეინახეთ აუდიტი.
ოთხშაბათები: draft-canary (ტრაფიკის/ჩრდილის რეჟიმი) - skaft.
Test matrix: ჭეშმარიტების ცხრილი საკვანძო როლებზე/ატრიბუტებში (საკონტრაქტო ტესტები).
Change Management: Merge-Records უსაფრთხოების/Complaence პოლიტიკის შესახებ.

9) აუდიტი და დაკვირვება

Журнал решений: `decision_id`, `subject`, `action`, `resource_ref`, `result`, `matched_policies`, `policy_version`, `attributes_digest`.
მეტრიკა: QPS PDP, ლატენტობა p95, hit-rate ქეში, დენის წილი, ნაბიჯის სიხშირე, SoD ინციდენტები.
ტრეკები: PDP ზარი; კორელაცია API- ს მოთხოვნით.
რეპლეი: პოლიტიკის ახალ ვერსიაზე ისტორიული გადაწყვეტილებების „გადალახვის“ შესაძლებლობა.

10) ინტეგრაცია ავთენტიფიკაციასთან და ნიშნებთან

თვითმყოფადობა - IDP- დან (OIDC/SAML). ნიშნებს აქვთ მინიმალური ატრიბუტები: 'sub', 'tenant', 'roles', 'auth _ time', 'amr', 'scopes'.
ABAC- სთვის, აიღეთ „მძიმე“ ნიშნები სერვერის მხრიდან (PIP) ისე, რომ არ გააფართოვოს ნიშანი.
ხელმოწერილი resource tokens (capability/მოსაწვევები) - მკაცრად შეზღუდული დელეგაციებისთვის.

11) ფსევდო კოდი PDP (გამარტივებული)

python def decide(subject, resource, action, env, policies):
matched = []
effect = "deny"
Explicit DENYs with priority for p in sorted (policies, key = lambda x: x.priority, reverse = True):
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
if p. effect == "deny":
return Decision("deny", matched, p. version)
Looking for ALLOW for p in policies:
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
effect = "allow"
break return Decision(effect, matched, max_version(matched, policies))

12) ანტი შაბლონები

„როლი = გვერდი“ (ასობით მცირე როლი საგნობრივი არეალის მოდელის გარეშე).
პოლიტიკოსის შენახვა მხოლოდ კოდში, ვერსიების/აუდიტის გარეშე.
დენის-ოვერრიდისა და SoD- ის არარსებობა თაღლითობის რისკის ზრდაა.
მკაცრი სიები 'user _ id' წესებში (ატრიბუტების/ურთიერთობების ნაცვლად).
ფილტრაციის არარსებობა მონაცემთა დონეზე (RLS) ფილტრის თანდასწრებით მხოლოდ UI- ში.
როლების სინქრონიზაცია ხელით სკრიპტების საშუალებით, მოვლენების და ქაშის ინვალიდობის გარეშე.

13) კეისი და რეცეპტები

13. 1 დონის ველი შენიღბვა:

allow read invoice when subject. roles includes "support"
mask fields ["card_last4", "billing_email"] unless subject. role == "finance"

13. 2 მონაცემთა ექსპორტი მხოლოდ MFA- სთან:

allow export if subject. mfa_verified and env. ip in cidr("203. 0. 113. 0/24")

13. 3 SoD:

deny approve_payment if subject. performed_actions includes ("create_payment" within last 24h)

13. 4 დელეგაცია (შეზღუდული ნიშანი):

Capability ნიშანი შეიცავს' resource _ id', 'actions = [“ read“]', 'expires _ at', 'aud'. PEP ამოწმებს ხელმოწერას და ვადას.

14) ტესტირება

პოლიტიკოსის ერთეულის ტესტები: ჭეშმარიტების ცხრილები მთავარ კომბინაციებში.
Property-based: შემთხვევითი ატრიბუტების წარმოება „ხვრელების“ მოსაძებნად.
Golden-tests: კრიტიკული endpoints- ის გადაწყვეტილებების ნაკრების დაფიქსირება.
Canary/Shadow: პოლიტიკოსის ძველი და ახალი ვერსიების პარალელური შეფასება განსხვავებების გაუმჯობესებით.

15) დანაყოფის „არქიტექტურა და ოქმები“

ავთენტიფიკაცია და ავტორიზაცია (OIDC/OAuth2)

თანხმობის მართვა

ტოკენიზაცია და კლავიშების მართვა

დაკვირვება: ლოგოები, მეტრიკები, ტრეკები

გეო-მარშრუტიზაცია და ლოკალიზაცია

დაშიფვრა At Rest/In Transit

16) არქიტექტორის ჩეკის სია

1. განსაზღვრულია არსებითი როლები და მათი იერარქიები?
2. არსებობს ჰიბრიდული მოდელი: როლები + პირობები ატრიბუტებზე?
3. ხორციელდება PDP დენის-overrides, SoD და step-up?
4. სად არის PEP? (კარიბჭე, ზურგჩანთა, BD, UI) - ყველგან ერთფეროვანია?
5. გაქვთ გადაწყვეტილებების ქეში და მოვლენების ინვალიდობა?
6. პოლიტიკოსების ვერსია, ტესტირება, პროცესის გასწვრივ?
7. ჩართულია გადაწყვეტილებების, მეტრიკის და ტრეკების აუდიტი?
8. მხარს უჭერს მრავალფეროვნება და RLS/ველი-მასკინგი?
9. არსებობს runbook ინციდენტებზე და პოლიტიკოსის რეგრესიაზე?

დასკვნა

RBAC უზრუნველყოფს მართვას, ABAC არის კონტექსტი და სიზუსტე. როლების ატრიბუტურ პირობებთან შერწყმით, PDP/PEP- ის გაზიარებით, ქეშირების, აუდიტის და პოლიტიკოსის ტესტირების დანერგვით, თქვენ აშენებთ ავტორიზაციას, როგორც პლატფორმის უნარს: პროგნოზირებადი, გადამოწმებული და მასშტაბური პროდუქტისა და მარეგულირებელი მოთხოვნებისთვის.