ავთენტიფიკაცია და ავტორიზაცია

AuthN/AuthZ- ის საიმედო წრე არის ჭეშმარიტების ერთი წერტილი, თუ ვინ ხართ (ავთენტიფიკაცია) და რა მოგეცემათ (ავტორიზაცია). პლატფორმაში, რომელსაც აქვს მრავალი ბრენდი, რეგიონი, ინტეგრაცია და მაღალი მარეგულირებელი მოთხოვნები, ეს წრე უნდა იყოს მოდულური, დაკვირვებული და კონტროლირებადი პოლიტიკოსების მიერ, და არა „მომსახურებისთვის if-of“.

1) ძირითადი ტერმინები და როლები

იდენტიფიკაცია (ID): პიროვნების დადგენა (მომხმარებელი, მომსახურება, პროვაიდერი).
ავთენტიფიკაცია (AuthN): პიროვნების მტკიცებულება (პაროლი, MFA, სერთიფიკატი).
ავტორიზაცია (AuthZ): პოლიტიკოსისა და კონტექსტის საფუძველზე გადაწყვეტილების მიღება „შესაძლებელია/შეუძლებელია“.
PDP/PEP: Policy Decision Point (გადაწყვეტს )/Policy Enforcement Point (გამოიყენება).
IDP: იდენტიფიკაციის პროვაიდერი (OIDC).
Subject/Resource/Action/Context: ვინ/რა/რას აკეთებს/რა პირობებში.

2) მიკროსქემის ზოგადი არქიტექტურა

[ IdP (OIDC) ]
│ OIDC/OAuth 2. 1 (PKCE, JAR/JARM)

[ Token Service / JWKS / KMS ]
│klyuchi (rotate)
│ JWT/Access/Refresh, mTLS

[API Gateway (PEP)] Solution/Policy ──kesh
│ authN/CSRF/CORS/rate-limit

[ Microservices (PEP)]──PDP (OPA/cedar) ──Policy Store (GitOps)
│audit/metriki

[ Data/Providers ]── service-to-service (mTLS+JWT/Spiffe)

პრინციპები: ტოქსინების თაობის ცენტრალიზაცია და პოლიტიკოსი, ადგილობრივი გამოყენება; „მინიმალური პრივილეგიები“ და აშკარა დელეგაციები.

3) მომხმარებლის ავთენტიფიკაცია (OIDC/OAuth 2). 1)

• Authorization Code + PKCE (ყოველთვის SPA/Mobile- ისთვის).
• SSO: გარე IDP (SAML/OIDC) მხარდაჭერა b2b/ოპერატორებისთვის.
• MFA: TOTP/WebAuthn/SMS (რეკომენდებულია WebAuthn და TOTP; SMS — fallback).
• Risk-based Step-Up: მგრძნობიარე მოქმედებებით (თანხების გატანა, დეტალების შეცვლა) მოითხოვეთ MFA/pe-Auth.

• Refresh Token Rotation + RT რეესტრი ხელახლა გამოყენების დეტალებით.
• Nonce/State + PKCE, მკაცრი CORS/CSRF ბრაუზერის ნაკადებისთვის.
• Short-lived access tokens (5–15 мин) + silent refresh/RT.
• Device binding (DpoP/mtls-bound tokens) კრიტიკული ოპერაციებისთვის.

json
{
"iss": "https://auth. example. com",
"sub": "user_9f12",
"aud": ["wallet","catalog"],
"exp": 1730385600,
"iat": 1730384700,
"tenant": "brand_eu",
"region": "EE",
"amr": ["pwd, ""webauthn"] ,//authentication methods
"scp": ["wallet:read","bets:place","kyc:status. read"],
"sid": "sess_a1b2c3",      // session id
"acr": "urn: mfa: strong "//warranty level
}

4) მომსახურების ავთენტიფიკაცია (mTLS, SPIFFE, JWT)

mTLS სერვისებს შორის + SPIFFE/SPIRE workload მუდმივი იდენტიფიკატორებისთვის.
Service JWT მოკლე ვადით (5 წუთი), რომელსაც ხელს აწერს HSM/KMS; გაცემის აუდიტი.
Audience-scoped: JWT შესაფერისია მხოლოდ კონკრეტული სერვისის/დომენისთვის.
ნდობის სფეროები: მომსახურება სხვა რეგიონიდან/ტენანტიდან - ცალკეული PKI და პოლიტიკა.

5) ავტორიზაციის მოდელები: RBAC, ABAC, ReBAC

RBAC (ნებართვის როლები): მარტივი და გამჭვირვალე (შესაფერისია ადმინისტრაციული პანელებისთვის, ოპერატორებისთვის).
ABAC (საგნის/რესურსის/კონტექსტის ატრიბუტები): მოქნილი წესები "tenant =... AND region=… AND kyc_tier≥2».
ReBAC (ურთიერთობები): სასარგებლოა რთული საკუთრებისთვის („ვინ ფლობს ბრენდს/მამაჩემს/კამპანიას“).

რეკომენდაცია: ჰიბრიდი - ძირითადი RBAC + კონტექსტური ABAC პირობები + წერტილოვანი ReBAC ურთიერთობები.

6) პოლიტიკოსები და მათი შესრულება (PDP/PEP)

PEP Gateway და სერვისებში: ამოიღეთ კონტექსტი (JWT, მანდატები, IP/ASN, დრო, რეგიონი, KYC დონე), ქმნის თხოვნას PDP- სთვის.

json
{
"subject": { "sub":"user_9f12", "roles":["support"], "kyc":2, "tenant":"brand_eu" },
"action": "bets. place",
"resource": { "game_id":"g_42", "provider":"pr_x" },
"context": { "region":"EE", "ip_asn":"AS12345", "time":"2025-10-31T12:34:56Z" }
}

და უბრუნდება 'ALLOW/DENY' + განმარტებას.

PEP გადაწყვეტილებების ქეში (TTL 30-120 გ) ამცირებს ლატენტობას; ღონისძიებების ინვალიდობა „როლების შეცვლა/პოლიტიკოსი“.

rego package bets

default allow = false

allow {
input. action == "bets. place"
input. subject. kyc >= 2 input. subject. tenant == input. context. tenant not blocked_region within_limits
}

blocked_region { input. context. region == "NL" }
within_limits { input. context. bet_amount <= data. limits. max_bet[input. subject. tenant] }

7) სკუპები და ნებართვები

• რესურსი: მოქმედება - 'wallet: read', 'wallet: transfer', 'bets: place', 'kyc: status. read`.
• ადმინებისთვის - 'admin:' იზოლირებულ დომენში.
• პროვაიდერებისთვის - 'provider: ანგარიში. read`, `provider:events. push`.

მინიმალური შეღავათების პრინციპი: ჩვენ მხოლოდ საჭირო დანამატებს ვადგენთ; „ესკალაცია“ (უფლებების დროებითი გაფართოება) - თიკეტისა და TTL- სთან.

8) მულტფილმები და რეგიონები (რეპრესიები)

ნიშნები შეიცავს 'tenant', 'region', 'licence'; PDP ამოწმებს რესურსის შესაბამისობას.
როლები/პოლიტიკა - სახელების ადგილები per tenant ('role: brand _ eu/support').
ხელმოწერის გასაღებების და მიმოხილვის სიების გამიჯვნა რეგიონებში; ჯვარედინი რეგიონალური მოთხოვნები - მხოლოდ სანდო კარიბჭეების საშუალებით.

9) სხდომებისა და მოწყობილობების მართვა

Server side session store ვებ (მოწყობილობის/ბრაუზერის ბმული, იდენტიფიკატორის როტაცია).
Idle/Absolute Timeout (მაგ., 30 წთ/24 სთ); მგრძნობიარე მოქმედებები - re-Auth/MFA.
აქტიური მოწყობილობების ჩამონათვალი, „ყველასგან გამოსავალი“.
ანომალიები: ერთდროული შესასვლელი სხვადასხვა რეგიონიდან, ხშირი MFA წარუმატებლობები - რისკის სიგნალები.

10) დელეგაცია და თანხმობა (თანხმობა)

On-behalf-of (OBO): სერვისი მოქმედებს მომხმარებლის სახელით (მარიონეტული ნიშანი ინდივიდუალური 'sub '/' act').
თანხმობა: აშკარა ეკრანი პარტნიორის მონაცემებზე წვდომისთვის, მიმოხილვის თანხმობის ჟურნალი.
დროებითი access-mandates: N საათის/დღის უფლებები ავტომატურად იწურება.

11) გასაღებები, ხელმოწერები და როტაცია

JWKs 'kid', ავტომატური როტაცია, პირადი გასაღებების შენახვა KMS/HSM- ში.
ალგორითმები: ES256/EdDSA JWT- სთვის; TLS 1. 2+/mTLS.
ორმაგი კეის პერიოდი: ორივე 'kid' მიღება მომხმარებელთა განახლების დასრულებამდე.
RT და Token Introspection- ის მიმოხილვა კრიტიკული ინციდენტებისთვის.

12) კლიენტის პროგრამების უსაფრთხოება

SPA: Authorization Code + PKCE, no `implicit`, строгий CORS/Content-Security-Policy.
Mobile: App Attestation/Device Check, რომელიც დაცულია RT საცავიდან, დაცვა რუთისგან/ველბრიკისგან.
Desktop: სისტემის ბრაუზერი ლოგინისთვის (no embedded web-views), PKCE.

13) მოსახერხებელი SDK კონტრაქტები

http
POST /authz/evaluate
Authorization: Bearer <access_jwt>
Body: { "action":"bets. place", "resource":{"game_id":"g_42"}, "context":{"bet_amount":5. 0} }
→ 200 { "decision":"ALLOW", "ttlMs":60000, "explain":"kyc>=2, limit ok" }

http
POST /oauth/token grant_type=urn:ietf:params:oauth:grant-type:token-exchange subject_token=<user_jwt>&actor_token=<service_jwt>&audience=wallet

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

• `authn_success_rate`/`mfa_challenge_rate`/`mfa_fail_rate`
• `authz_p95_ms`, `authz_denied_rate{reason}`
• `invalid_token_rate`, `jwks_skew_ms`, `rt_reuse_detected`
• შესასვლელი ანომალიები (ახალი მოწყობილობები, geo-velocity), საეჭვო ნაკრები.

• `who/what/when/where/why`, `decision`, `policy_version`, `token_kid`, `client_id`.
• ექსპორტი შესაბამისობისთვის (მარეგულირებელი/მოვაჭრე აუდიტი).

15) პერიმეტრისა და კლიენტის დაცვა

Gateway PEP: rate-limit, bot/signature checks, CSRF დაცვა, მკაცრი CORS, HSTS.
შიდა ტრაფიკი: mTLS + სერვისული JWT + შეზღუდული ქსელები.
ვებჰუკი/გარე კოლბეკი: სხეულის ხელმოწერები (HMAC/JWS), დროის ფანჯრები, ანტი-მიმღები.

16) ტიპიური შეცდომები

გრძელი წვდომის ნიშნები - გაჟონვა.
იმპლიციტური OAuth ნაკადი SPA- ში.
გასაღებების როტაციის ნაკლებობა და Dual-Key პერიოდი.
პოლიტიკოსის ნაცვლად უხეში როლები (შეუძლებელია გადაწყვეტილების აუდიტი/ახსნა).
ტენანტების/რეგიონების ნაზავი ერთ „როლში“ ან „კეი“.
მგრძნობიარე ქმედებებზე MFA არ არსებობს.
AuthZ გადაწყვეტილებების ქეში შეზღუდული შესაძლებლობის გარეშე როლების ცვლილებებზე.

17) Playbooks (runbooks)

1. JWT ხელმოწერის გასაღების კომპრომისი

დაუყოვნებლივი revoke 'kid', ახალი JWKS- ის გამოქვეყნება, RT/სესიების იძულებითი ინვალიდობა, აუდიტის ანგარიში.

2. მასობრივი 'invalid _ token'

შეამოწმეთ საათების რასინქრონი/ცხოვრების დრო, JWKS- ის აქტუალობა, ქეშის გაუმართაობა.

3. შესასვლელი ანომალიები

ჩართეთ გაზრდილი რისკის ესკიზი, მოითხოვეთ step-up, შეატყობინეთ მომხმარებელს, დროებით შეზღუდეთ გადახდები.

4. IDP უკმარისობა

გადასვლა სესიების ქეშზე/როლურ აპარატზე, შეზღუდეთ ახალი ლოგინები, გამართეთ არსებული სესიები TTL- ზე.

18) ჩეკის სია გაყიდვამდე

• OIDC/OAuth 2. 1 PKCE- ით, მოკლე AT- ით, RT როტაციით, კრიტიკული ოპერაციებისთვის მოწყობილობებით.
• MFA (WebAUthn/TOTP) და step-up დასკვნების/ჩანაცვლების/როლის ესკალაციების შესაცვლელად.
• მომსახურება: mTLS + SPIFFE, მოკლე სერვისული JWT.
• AuthZ პოლიტიკოსები (RBAC + ABAC/ReBAC) ცენტრალიზებულ PDP- ში; PEP gateway და სერვისებში.
• შეზღუდული შესაძლებლობის მქონე გადაწყვეტილებების ქეში; audit trail უცვლელი.
• მულტფილმი-ჩრდილები/რეგიონები: გასაღების იზოლაცია/პოლიტიკოსი/ლოგოები, ლიცენზიების აღრიცხვა.
• JWKS/გასაღებები KMS/HSM, ორმაგი კეი როტაცია, მონიტორინგი 'kid'.
• CSRF/CORS/HSTS/Rate-limit/bot ფილტრები პერიმეტრზე.
• ინციდენტების ფლეიბუკები, revoke/rotate/lockdown ღილაკები.
• ტესტების ნაკრები: unit (პოლიტიკა), contract (SDK/Flows), chaos (IDP, JWKS), e2e (step-up, OBO, revoke).

19) მინი კონფიგურაციის შაბლონები

yaml scopes:
wallet: read: {desc: "Reading balance"}
wallet: transfer: {desc: "Transfer of funds," sensitive: true, step_up: true}
bets: place: {desc: "Bet"}
kyc:status. read: {desc: "KYC status"}
roles:
support:
allow: [wallet:read, kyc:status. read]
finance:
allow: [wallet:read, wallet:transfer]
player:
allow: [bets:place]

yaml deny:
- when: { region: ["NL","BE"] }
actions: ["bets."]

დასკვნა

ავთენტიფიკაციისა და ავტორიზაციის კონტური არ არის ბიბლიოთეკა, არამედ პლატფორმის უნარი: მოკლევადიანი ნიშნები და კონტროლირებადი გასაღებები, ცენტრალიზებული პოლიტიკოსები და მათი ადგილობრივი გამოყენება, მულტიფაქტორი და step-up, ტენდერების/რეგიონების მკაცრი იზოლაცია, აუდიტი და ტელემეტრია. ასეთი დიზაინი ცვლილებებს უსაფრთხოდ ხდის, მარეგულირებლისთვის აიხსნება და პროდუქტისთვის გამჭვირვალეა - და ბაზრებისა და გუნდების მასშტაბები ხდება რუტინული ოპერაცია და არა ექსპლუატაცია.