API გასაღებები, ნიშნები და წვდომის მანდატები: უსაფრთხო ავთენტიფიკაცია

სტატიის სრული ტექსტი

💡 18+. ტექნიკური მასალა პლატფორმების, სტუდიების (RGS/live), აგრეგატორებისა და მასთან დაკავშირებული სერვისებისთვის (ჯეკპოტები, KYC/AML). არა თამაშის მოწოდება.

1) რატომ არის ეს ყველაფერი: iGaming- ის საფრთხის მოდელი

ფული და PII: გასაღების კომპრომისი - frode, გაჟონვა, ჯარიმები.

ქსელის ინტეგრაცია: ათობით გარე პროვაიდერი, სხვადასხვა რეგიონი/ლიცენზია.

მაღალი SLA განაკვეთები: მარტივი ან ორმაგი გადახდა - რეპუტაციის და იურიდიული რისკები.

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

2) ინსტრუმენტები: რა გვაქვს არსენალში

API გასაღებები: კლიენტის სტატიკური იდენტიფიკატორები. ინტეგრაცია მარტივია, გაჟონვის მაღალი რისკი.

OAuth2 (Client Credentials): მოკლემეტრაჟიანი Bearer ნიშნები scope/audience.

mTLS: ურთიერთგამომრიცხავი TLS შემოწმება, კლიენტის ძლიერი დაკავშირება არხზე.

HMAC/EdDSA ხელმოწერები: მოთხოვნის სხეულის კრიპტოგრაფიული მთლიანობა და ფრაგმენტებისგან დაცვა (timestamp + nonce).

Proof-of-possession: MTLS-bound ნიშნები ან DPOP (HTTP მოთხოვნის ხელმოწერა კლიენტის გასაღებით).

JWT/PASETO: თვითწერილი ნიშნები (სასურველია მოკლე TTL).

RBAC/ABAC: საავტორო უფლებების როლი/ატრიბუტი (ORA/პოლიტიკოსის გადაწყვეტილებები).

დროებითი წვდომის მანდატები (delegation/STS): კონკრეტული სცენარისთვის გაცემული ბილეთები შეზღუდული დროით და მიზნებით.

3) ძირითადი პრინციპები („გაჩერების ნიშნები“)

1. Least Privilege: თითოეული გასაღები/ნიშანი - მინიმალური შესაძლო უფლებები.

2. მოკლე დროში default: TTL წუთები, არა დღეები. როტაცია ავტომატურია.

3. Bind to channel: ნიშნების დაკავშირება mTLS/DPOP- ზე გაჟონვის დროს აზრი არ აქვს.

4. Per-brand/region: გასაღებები/სერთიფიკატები და ნებართვები - ბრენდი/ლიცენზია/რეგიონი.

5. კოდში არ არის აშკარა საიდუმლოებები: საიდუმლოებები მხოლოდ Vault/HSM/KMS- ის მეშვეობით, არც Git/logs.

6. WORM აუდიტი: ყველა ოპერაციის/გაცემის/როტაციის უცვლელი ლოგოები.

7. Idempotention write ბილიკებზე: იგივე გასაღებით ნებისმიერი გამეორება მეორედ არ ცვლის ფულს.

4) როდესაც გამოიყენებთ (iGaming კონტექსტი)

სცენარი	რეკომენდებულია
ფულადი RPC (wallet authorize/settle, cashier)	mTLS + OAuth2 CC MTLS-bound ნიშნით; სათაურები 'X-Idempotency-Key', 'X-Trace-Id'
ვებჰუკი (მოვლენები)	HMAC/EdDSA + timestamp/nonce, allow-list წყაროების ხელმოწერა, retray ბაბუასთან
B2B კატალოგები/მოხსენებები	OAuth2 CC (მოკლემეტრაჟიანი Bearer) + rate-limits
მანქანების დელეგაცია (ჯეკპოტი და საფულე)	STS/Token Exchange ვიწრო scope და TTL 5 წთ
Admin პანელი/ოპერაციები	OIDC ადამიანებისთვის + RBAC/ABAC, MFA/ბიომეტრია, „ოთხი თვალი“

5) წვდომის მანდატების დიზაინი (scopes, audience, პირობები)

Scope-y (მაგალითები):

`bets:write`, `settlements:write`, `wallet:credit`, `wallet:debit`, `rg:read`, `rg:enforce`, `jackpot:trigger`.

აუდიენცია: ვის მიმართავს ნიშანი (მაგალითად, 'aud: wallet). api`).

Constraints (fine-grained):

`brand_id`, `region`, `ip/cidr`, `time_of_day`, `rate_limit`, `max_amount`.
ისინი ინახება ტოკენში (JWT claims) ან Vault/STS- ში გამოქვეყნებულ „მანდატში“.

6) საცნობარო flow

6. 1 პლატფორმა - RGS: ფული RPC- ზე

1. mTLS handshake (სერთიფიკატები per brand/region).

2. OAuth2 CC: RGS იღებს 'access _ token' (TTL 2-5 წუთი, 'aud = wallet). api`, `scope=bets:write settlements:write`).

3. მოთხოვნა 'POST/v1/bets/authorize' სათაურებით:

`Authorization: Bearer `, `X-Idempotency-Key`, `X-Trace-Id`.
4. პასუხი + ჩაწერა WORM აუდიტში (ვინ/რა/როდის/საიდან).
5. ნიშნის როტაცია უსადენო, ამის შემდეგ - CC გამეორება.

6. 2 ვებჰუკი პლატფორმა - პროვაიდერი

სათაური 'X-Signature: eddsa = ' ან 'sha256 =...', 'X-Timestamp', 'X-Nonce'.

პროვაიდერი ამოწმებს: შესაბამისობის ფანჯარა (± 5 წთ), ერთჯერადი 'nonce', სხეულის ხელმოწერა.

მიუწვდომლობის შემთხვევაში - backoff restray, dedup 'event _ id'.

6. 3 დელეგაცია (ჯეკპოტის სერვისი - საფულე)

JP იწვევს STS: "მიეცი დროებითი ნიშანი 'wallet: credit' for 'player _ id = p _...", თანხა X, TTL 2 წუთი ".

STS ამოწმებს პოლიტიკას/შეზღუდვებს და აძლევს მანდატს (ვიწრო ნიშანი).

JP სესხებს საფულეს ამ ნიშნით. აზრი არ აქვს ამგვარი ნიშნის კომპრომეტირებას: მოკლე TTL, ვიწრო უფლებები, mTLS- ის სავალდებულო.

7) მოთხოვნის სტრუქტურები

7. 1 Idempotence (აუცილებლად)


POST /v1/bets/settle
Authorization: Bearer <MTLS-bound>
X-Idempotency-Key: settle_r_8c12_1
X-Trace-Id: tr_a1b2
{
"bet_id":"b_001",  "round_id":"r_8c12",  "win":{"amount":1460,"currency":"EUR"}
}
→ 200 { "status":"credited", "settlement_id":"st_77" }
(იგივე გასაღების გამეორება - იგივე პასუხი)

7. 2 ვებჰუკის ხელმოწერა (HMAC)


X-Signature: sha256=BASE64(HMAC(secret, timestamp + "." + nonce + "." + body))
X-Timestamp: 1730000000
X-Nonce: 1f7a...

8) საიდუმლოების და გასაღებების მართვა

Vault/HSM/KMS: თაობა, შენახვა, როტაცია, მიმოხილვა.

პერ გარემო: sandbox/scream - ნდობის სხვადასხვა ფესვები.

პერ ბრენდი/რეგიონი: ინდივიდუალური გასაღებები და სერთიფიკატები.

მანქანის როტაცია: cron/შეტყობინებები; overlap პერიოდები უვარგისი ჩანაცვლებისთვის.

აკრძალვა კოდში/ლოგოებში: საიდუმლოებები არ იწერება stdout- ში, არ შედის crash მოხსენებებში.

Device/Workload იდენტურობა: SPIFFE/SPIRE, K8s Direct Account და mTLS სახელმძღვანელო საიდუმლოებების გარეშე.

9) ავტორიზაციის პოლიტიკა (RBAC/ABAC) და OPA

RBAC: роли «rgs», «wallet», «jackpot», «reporting».

ABAC: წესები „თუ 'region = EU' და 'brand = A' დაუშვებელია 'wallet: credit' 10k“.

OPA/REGO ან ანალოგები: ცენტრალიზებული გადაწყვეტილების მიღება, პოლიტიკოსის ვერსირება, მშრალი ტესტები.

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

თითოეული მოთხოვნის/მოვლენის მეშვეობით „trace _ id“ და „client _ id“.

მეტრიკა: p50/p95/p99 ლატენტობა ენდოინტებში, error-rate კოდებით ('AUTH _ FAILED', 'SCOPE _ DENIED', 'IDEMPOTENCY _ M'), როტრაფიკის სიხშირე, წილი ვადაგასული ნიშნები.

WORM ჟურნალი: ტოქსინების ექსტრადიცია/მიმოხილვები, კლავიშების შეცვლა, პოლიტიკოსის შეცვლა.

ალერტები: „AUTH _ FAILED“ - ის ზრდა, გეო/ASN ანომალიები, ზრდა „ვადაგადაცილებული/მოხსნილი“> ბარიერი.

11) რეგიონალური რეზიდენცია და სეგმენტი

ნიშნები/სერთიფიკატები უკავშირდება რეგიონს (EU/UK/BR/...).

სტიგმებში - 'region', პლატფორმის კარიბჭეები კრძალავს ჯვარედინი რეგიონალური გამოწვევებს.

ცალკეული KMS და Vault კლასტერები რეგიონში; გასაღებები არ „მართავს“ რეგიონებს შორის.

12) ინციდენტები და მიმოხილვა

Compromise playbook: მყისიერი revoke გასაღებები/ნიშნები, ქსელის ბლოკი/ASN, scope დახურვა.

Kill-switch კარიბჭის დონეზე: „new sessions/funds“.

პოსტმორტემი: „როგორ ჩავარდა ლოგები/საცავი“, „რატომ არ მუშაობდა DLP/საიდუმლოების სკანერი“.

13) ჩეკის ფურცლები

A. პლატფორმისთვის

ყველა write ბილიკი: mTLS + OAuth2 CC (TTL - 5 წთ), 'X-Idempotence-Key', 'X-Trace-Id'.
ვებჰუკი: HMAC/EdDSA + timestamp + nonce, dedup 'event _ id'.
კეისტორი: Vault/HSM/KMS, როტაცია და მიმოხილვა, per brand/region გამიჯვნა.
ORA/პოლიტიკოსები: RBAC/ABAC, ცვლილებების ჟურნალები, ტესტები.
WORM აუდიტი და SLO დაშბორდები (latency, error, revoke/rotate).
DR/xaoc სწავლებები: ამოწურული ნიშნები, ხელმოწერის შეცვლა, MITM mTLS- ის გარეშე.

B. პროვაიდერისთვის (RGS/live/JP)

არ ვიცავ საიდუმლოებებს კოდში; მე ვიყენებ Vault/შეცვლას საშუალო ცვლადების საშუალებით.
ტოქსინების ავტომატური როტაცია; handle 401/403 განახლებით.
ხელს ვაწერ ვებჰუკებს/ვამოწმებ შესაბამისობას და ერთჯერადობას.
ვატარებ საკვანძო მოქმედებების აუდიტს და ვპასუხობ დეპრესიას/Sunset სათაურებს.
Idempotention ყველა write გამოწვევაზე, Idempotency-Key- ზე.

14) ანტი-ნიმუშები (წითელი დროშები)

სტატიკური API გასაღებები გაყიდვაში შენახვის ვადის გარეშე.

Bearer ნიშნები არხზე მითითების გარეშე (არა MTLS/DPOP).

საიდუმლოებების შენახვა Git/CI-log- ში/ფრონტის კონფისკაცია.

საერთო გასაღები/სერთიფიკატი რამდენიმე ბრენდისთვის/რეგიონისთვის.

ვებჰუკი ხელმოწერისა და დროებითი ფანჯრის გარეშე არის წარწერა.

ცენტრალიზებული მიმოხილვისა და WORM ჟურნალის არარსებობა.

იდემპოტენტურობის არარსებობა - დებატების/სესხების დუბლი.

15) პოლიტიკის მინი შაბლონები (მაგალითი, რომელიც ადამიანურია)

მანდატი 'rgs-wallet' (EU, brand A):

`aud=wallet. api`, `scope=["bets:write","settlements:write"]`
`constraints: region=EU, brand=A, ip in {asn:…}, max_amount=5000 EUR, ttl=300s`
`binding: mTLS(cert_hash=sha256:…)`

ვებჰუკი 'wallet. credit. ok`:

'alg = Ed25519', ფანჯარა '± 300s', 'nonce' უნიკალურია, დედაპლატი 'ღონისძიება _ id' 24 საათი.

უსაფრთხო ავთენტიფიკაცია iGaming- ში არის პრაქტიკის ერთობლიობა: ხანმოკლე მანდატები, არხზე ბმული (mTLS/DPOP), ვიწრო scope/audience, მკაცრი idempotence, Vault/HSM და WORM აუდიტი, რეგიონალური სეგმენტი და დაკვირვება. ასეთი დასტის შეფერხება არ უშლის ინტეგრაციის სიჩქარეს, მაგრამ რადიკალურად ამცირებს გაჟონვის რისკს და ფინანსურ ინციდენტებს - ფული და მონაცემები რჩება კონტროლის ქვეშ, განახლება პროგნოზირებულია, ხოლო შესაბამისობა ხორციელდება „ყუთიდან“.