წვდომის კონტროლი და RBAC API- ში

1) რატომ უნდა აკონტროლოთ API- ში შესვლა

ავტორიზაცია არის პასუხი კითხვაზე "შესაძლებელია თუ არა ამ მსახიობს ამ მოქმედების შესრულება ახლა ამ რესურსზე? ». შეცდომები იწვევს BOLA/IDOR გაჟონვას, უფლებების ესკალაციას და რეგულატორების მოთხოვნების დარღვევას. მიზანია მრავალ დონის მოდელის შექმნა: პერიმეტრი - მომსახურება-მესი - ბიზნესის წესები, აშკარა პოლიტიკოსებითა და შემოწმებებით ობიექტის დონეზე.

2) ავტორიზაციის მოდელები: როდის უნდა აირჩიოთ რა

RBAC (Role-Based Accontrol) - რეზოლუციის როლი. მარტივი, სტაბილური, მაგრამ მიდრეკილია „როლების აფეთქებისკენ“.
ABAC (Attribute-Based) - გადაწყვეტილება საგნის/ობიექტის/კონტექსტის ატრიბუტების შესახებ (ქვეყანა, KYC დონე, რესურსის მფლობელი, რისკი).
ReBAC (Relationship-Based) - ურთიერთობების რაოდენობა (მფლობელი, გუნდის წევრი, „პროექტის მენეჯერი“); წყვეტს რთულ იერარქიებს.
Scopes (OAuth) არის ხელშეკრულება კლიენტსა და რესურსის სერვერს შორის „წვდომის ზონის“ შესახებ (მაგალითად, 'payments: write').
პრაქტიკა: RBAC საბაზო მატრიცისთვის, ABAC კონტექსტისა და შეზღუდვებისთვის, ReBAC რთული იერარქიებისთვის (საქაღალდეები, ორგანიზაციები, ლიმიტები და ქვე-ანგარიშები).

3) რესურსებისა და მოქმედებების ტაქსონომია

იერარქია: 'org-project-wallet-transaction'. ზემოდან უფლებების მემკვიდრეობა შესაძლო „შეზღუდვებით“.
მოქმედებები: CRUD + domain სპეციფიკური ('approve', 'refund', 'settle').
რესურსების თვისებები: მფლობელი, რეგიონი, სტატუსი, რისკის ტეგები (AML/KYC), ლიმიტები.
მრავალფეროვნება: ყველა გამოსავალი შეიცავს 'tenant _ id'; ჯვრის ჩრდილოვანი მოთხოვნების აკრძალვა (deny-by-default).

4) არქიტექტურა: სად მიიღება გადაწყვეტილება

PEP (Policy Enforcement Point) - გადამოწმების ადგილი: კარიბჭე/API gateway, sidecar Mesh, თავად სერვისი.
PDP (Policy Decision Point) - პოლიტიკოსის ძრავა: ცენტრალიზებული (OPA სერვისი, Cedar ძრავა) ან ჩაშენებული ბიბლიოთეკა.
PIP (Policy Information Point) - ატრიბუტების წყაროები: მომხმარებლის/როლების კატალოგი, ტენანტის პროფილი, KUS/რისკი, რესურსების ფლობის რუკა.
PAP (პოლიტიკა ადაპტაციის წერტილი) - პოლიტიკოსის ვერსიების მენეჯმენტი, პუბლიკაცია, აუდიტი.

რეკომენდაცია: ცენტრალიზებული PDP + ადგილობრივი გადაწყვეტილებების ქეში PEP- ში; სერვისში რთული ობიექტის შემოწმება აფეთქების ღუმელის ინვარიანტების თანდასწრებით.

5) ნიშნები, სტიგმები და თვითმყოფადობა

OIDC/OAuth2: 'sub' (საგნის იდენტიფიკატორი), 'aud' (სამიზნე სერვისი), 'scope '/' roles', 'tenant', 'kyc _ level', 'risk _ tier'.
JWT: RS/ES ხელმოწერა, მოკლე 'exp', ხელახლა გამოცემა. ნუ დადებთ PII; გამოიყენეთ 'jti' გაწვევისთვის/ტრეკის აუდიტი.
mTLS/HMAC: სერვისული მომსახურება და პარტნიორები; სტიგმები გამოიყოფა 'client _ id' კატალოგიდან.
Device/Context: IP/ASN, geo, დღის დრო - შესასვლელი ABAC გადაწყვეტილებით (მაგალითად, აკრძალვა სამუშაო საათების გარეთ).

6) ობიექტის დონის ავტორიზაცია (BOLA-first)

თითოეულმა ოპერაციამ უნდა უპასუხოს „არის თუ არა სუბიექტი მფლობელი/აქვს თუ არა უფლება ამ 'resource _ id'?“

საკუთრების შემოწმება: 'resource. owner_id == subject. id 'ან წევრობა „ორგში“ როლით.
შერჩევის ფილტრაცია: ყოველთვის დააჭირეთ 'WHERE Resource. tenant_id =:tenant AND...` (row-level security).
ბმული ოპერაციებისთვის (ID გზაზე/სხეულში) - ნორმალიზება და დალაგება ბიზნესის ლოგიკაში.

7) RBAC- ის დიზაინი: როლები, რეზოლუციები, ნაკრები

ნებართვები (ნებართვები) - ატომური უფლებები: 'wallet. read`, `wallet. write`, `payment. refund`.
როლები - დასახელებული ნებართვების ნაკრები: 'admin', 'მხარდაჭერა. read`, `cashier`, `fraud. analyst`.
Scopes არის გარე კონტრაქტი მომხმარებლებისთვის (mapping scope - permissions).

• ძირითადი როლები + „ზებუნებრივი პაკეტები“,
• შეზღუდვები ABAC (ქვეყანა/რეგიონი/ტენანტი),
• „დროებითი ზრდა“ (Just-In-Time წვდომა, მოქმედების ხანგრძლივობა).

8) Avas/კონტექსტური შეზღუდვები

გეო/იურისდიქცია: აკრძალული ქვეყნებიდან აკრძალვის აკრძალვა (სანქციები/მარეგულირებელი).
დრო/რისკი: „risk _ score <threshold“ დიდი ოპერაციებისთვის.
KUS/limites: 'kyc _ level> = 2' დასკვნებისთვის> X; გარიგებებს შორის „გაცივების“ კონტროლი.
„სანდო მოწყობილობები“: მოითხოვეთ mTLS პარტნიორებისთვის საშიში მარშრუტებზე.

9) ReBAC და უფლებების რაოდენობა

სასარგებლოა რთული ბიზნეს სტრუქტურებისთვის (ჯგუფები, გუნდები, ბრენდები, ფილიალები).

ურთიერთობები: 'member', 'admin', 'owner', 'viewer'.
წარმოებული უფლებები: 'viewer' რესურსი მემკვიდრეობით მიიღება პროექტიდან 'member', რომელიც ეკუთვნის 'org'.
გრაფიკის საცავი: BD ურთიერთობის მატრიქსით, სპეციალიზირებული მომსახურება (Zanzibar მიდგომის სულისკვეთებით). Check- ის პასუხები (subject, relation, object) '.

10) გადაწყვეტილებები და პროდუქტიულობა

Kash PDP PEP დონეზე (მაგალითად, კარიბჭეში) გასაღები: 'sub' tenant 'resource' action 'policy _ version'.
TTL მოკლეა (წამები-წუთები) + მოვლენების ინვალიდობა: როლების/ურთიერთობების/ტენანტის შეცვლა.
Batch შემოწმებები (bulk authz) სიებისთვის: ისინი ამცირებენ PDP ჩარგებს.
გაზომეთ გამოსავალი; დეგრადაციის დროს - graceful-degradation მხოლოდ read (არასოდეს write/amble).

11) პოლიტიკოსის მაგალითები

11. 1 JWT სტიგმები - უხეში PEP (ფსევდო გეითვეი)

yaml
- match: { prefix: "/api/v1/wallets" }
authz:
require:
- claim: "aud"
equals: "wallet-service"
- claim: "scope"
includes_any: ["wallet. read", "wallet. write"]
context:
tenant_from: "claim:tenant"

11. 2 OPA/Rego (ABAC + BOLA)

rego package authz

default allow = false

allow {
input. action == "wallet. read"
input. subject. tenant == input. resource. tenant some role role:= input. subject. roles[_]
role == "support. read"
}

allow {
input. action == "payment. refund"
input. subject. tenant == input. resource. tenant input. subject. kyc_level >= 2 input. subject. risk_tier <= 2 input. subject. id == input. resource. owner_id # BOLA
}

11. 3 იურისდიქციის შეზღუდვა (დენის სია)

rego deny[msg] {
input. action == "withdraw. create"
input. context. country in {"IR","KP","SY"}
msg:= "Jurisdiction not allowed"
}

11. 4 ReBAC პოლიტიკა (ფსევდო)

allow(subject, "wallet. write", wallet) --
related(subject, "member", wallet. project) ∧ related(subject, "admin", wallet. org)   ∧ wallet. tenant == subject. tenant.

12) პოლიტიკოსებისა და ვერსიების მართვა

პოლიტიკის ვერსია ('policy _ version') და კანარი საშიში ცვლილებებისთვის.
„მშრალი რგოლები“ (dry-run/shadow decisions) - ლოგიკური 'allow/deny' გავლენის გარეშე.
პოლიტიკისა და მიგრაციის კატალოგი: ვინ, როდის და რატომ შეიცვალა; ინციდენტებთან შედარება.
ნეგატიური სცენარების ტესტები (აკრძალული შემთხვევები) სავალდებულოა CI- ში.

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

გადაწყვეტილებების ლოგოები: 'trace _ id', 'subect', 'tenant', 'action', 'resource _ id', 'result', 'policy _ version', უარის თქმის მიზეზი.
მეტრიკები: 'authz _ decision _ latence', 'authz _ denied _ total {action', BOLA მცდელობების წილი, ქეში-ჰიტის მცდელობა.
დაშბორდი: მოქმედებების/ტენანტების ტოპ უარის თქმის შესახებ, პოლიტიკოსის გათავისუფლების შემდეგ ტენდენციები.

14) უსაფრთხოება და სტაბილურობა

Deny-by-default: აშკარა ნებართვის არარსებობა = აკრძალვა.
Fail-closed: თუ PDP მიუწვდომელია, კრიტიკული write არის აკრძალვა (ან მკაცრად დამოწმებული როლების „მინიმალური პაკეტის“ დეგრადაცია).
ადგილობრივი „სახელმძღვანელო შემოწმებები“ კრიტიკული ინვარიანტებისთვის (მაგალითად, 'tenant '/' owner').
წებოვანი მინიმიზაცია JWT- ში; მგრძნობიარე ატრიბუტების გადატვირთვა PIP- ის საშუალებით დაცული არხის საშუალებით.

15) iGaming/ფინანსების სპეციფიკა

როლები: 'cashier', 'kyc. agent`, `aml. officer`, `fraud. analyst`, `vip. manager`, `risk. admin`.
შეზღუდვები: გადახდის ოპერაციები დამოკიდებულია 'kyc _ level', პასუხისმგებელი გადასახადების ლიმიტები, AML/სანქციების სტატუსი.
საკეტის რეესტრები: 'org/brand/Device/payment _ instrument' - ABAC ფილტრები write- ზე.
აუდიტის ჟურნალები უცვლელია KYC/AML/დასკვნებისთვის; შენახვა მარეგულირებელი ვადების შესაბამისად.
პარტნიორი API: mTLS + საკონტრაქტო 'scopes' მარშრუტებზე, გეო/ASN ფილტრები პერიმეტრზე.

16) ტესტირება და გადამოწმება

ნეგატიური მატრიცა: ჩამოთვალეთ აშკარა „აკრძალული“ შემთხვევები და უზრუნველყეთ ტესტები.
Fuzz ავტორიზაციის: ჩანაცვლება 'tenant _ id', 'owner _ id', ფილტრების გვერდის ავლით პაგინაციის/დახარისხების დროს.
Load PDP ტესტი: შეამოწმეთ ქეშის ლატენტობა და ქცევა p95/p99.
პოლიტიკოსის გამოშვება: dry-run + canary + მანქანა, მოსალოდნელი დენის/ალოუ.
ინციდენტები: შეკითხვა სტენდზე პოლიტიკოსის ზუსტი ვერსიით.

17) ანტიპატერები

დაეყრდნოს მხოლოდ „სკოპს“ ობიექტის შემოწმების გარეშე (BOLA).
აურიეთ ბიზნეს ლოგიკა და უფლებების შემოწმება თითოეულ ჰენდლერში ცენტრალიზებული მოდელის გარეშე.
შეაფასა როლები UI- ში და ენდობა კლიენტის გადაწყვეტილებებს.
'tenant '/' owner' ფილტრების არარსებობა მონაცემთა ბაზის მოთხოვნით.
არ არსებობს ქეშის გადაწყვეტილებების ინვალიდობა როლების/ურთიერთობების შეცვლისას.
გრძელი JWT გაწვევის/როტაციის გარეშე.

18) მზადყოფნის ჩეკის სია

• განისაზღვრება რესურსები/მოქმედებები, იერარქია და მრავალფეროვნება.
• ძირითადი RBAC მატრიცა + ABAC შეზღუდვები, სადაც საჭიროა - ReBAC.
• PDP/PEP შექმნილია; არსებობს ადგილობრივი გადაწყვეტილებების ქეში და მისი ინვალიდობა.
• პოლიტიკის ვერსია, უარყოფითი სცენარების ტესტები CI- ში.
• BOLA შემოწმება თითოეულ write/read სპეციფიკური 'resource _ id'.
• JWT მინიმალური სტიგმებით, მოკლე 'exp'; აუდიტი/მიმოხილვა 'jti'.
• მრიცხველები/გადაწყვეტილებების ლოგოები, დაშბორდები, ალერტები დენის/ლატენტისთვის.
• Fail-closed კრიტიკული write; fallback რეჟიმი დოკუმენტირებულია.
• დოკუმენტაცია მომხმარებლებისთვის: 'scopes', შეცდომების კოდი (401/403/404/409), მაგალითები.

19) TL; DR

BOLA-first: ცენტრალური PDP + გადაწყვეტილებების ქეში, RBAC, როგორც საფუძველი, ABAC კონტექსტისთვის, ReBAC ურთიერთობებისთვის. ყველა მოთხოვნა - 'tenant' და კონკრეტული 'resource _ id "კონტექსტში; deny-by-default, მოკლე JWT, ობიექტის ფილტრები BD- ში. გააფორმეთ და შეამოწმეთ პოლიტიკოსები, გაზომეთ ლატენტობა/დენი, ინციდენტები რეპროდუცირებით. IGaming- ისთვის - ინდივიდუალური როლები (KYC/AML/სალარო), მკაცრი ABAC შეზღუდვები და უცვლელი აუდიტი.