Kriptovalyutalar
Torrent Gear
API açarları, tokenlər və giriş mandatları: təhlükəsiz autentifikasiya
Məqalənin tam mətni
1) Niyə bütün bunlar: iGaming üçün təhdid modeli
Pul və PII: açarın kompromasiyası → frod, sızma, cərimələr.
Şəbəkə inteqrasiyası: onlarla xarici provayder, müxtəlif regionlar/lisenziyalar.
Yüksək SLA dərəcələri: sadə və ya ikiqat ödənişlər - nüfuz və hüquqi risklər.
Nəticə: Autentifikasiya və avtorizasiya minimum imtiyazlar və ciddi müşahidə ilə «default təhlükəsiz» olmalıdır.
2) Alətlər: arsenalda nə var
API açarları: statik müştəri identifikatorları. Sadə inteqrasiya, yüksək sızma riski.
OAuth2 (Client Credentials): scope/audience ilə qısamüddətli Bearer tokenləri.
mTLS: qarşılıqlı TLS-yoxlama, güclü kanal müştəri bağlama.
HMAC/EdDSA imzalar: kriptoqrafik sorğu bədən bütövlüyü və repleylər qarşı müdafiə (timestamp + nonce).
Proof-of-Possession: MTLS-bound tokenləri və ya DPoP (müştərinin açarı ilə HTTP sorğusunun imzası).
JWT/PASETO: özünü yazan tokenlər (tercihen qısa TTL ilə).
RBAC/ABAC: rol/atribut-bayzd authorization (ORA/siyasətçi həlləri).
Müvəqqəti giriş mandatları (delegation/STS): xüsusi ssenari üçün verilən vaxt və məqsədlər üzrə məhdud biletlər.
3) Əsas prinsiplər («stop işarələri»)
1. Least Privilege: Hər bir açar/token - minimum mümkün hüquqlar.
2. Short-lived by default: TTL dəqiqə, gün deyil. Rotasiya - avtomatik.
3. Bind to channel: mTLS/DPoP → tokenləri sızma zamanı faydasızdır.
4. Per-brand/region: marka/lisenziya/region üçün açarlar/sertifikatlar və icazələr.
5. Kodda No shared secrets: Sıralar yalnız Vault/HSM/KMS vasitəsilə, nə də Git/log.
6. WORM-audit: bütün əməliyyatların/ekstradisiyaların/rotasiyaların dəyişməz qeydləri.
7. Write yollarında idempotentlik: eyni açar ilə hər hansı bir təkrarlama ikinci dəfə pul dəyişmir.
4) Nə zaman istifadə etmək (iGaming konteksti)
5) Giriş mandatlarının dizaynı (scopes, audience, şərtlər)
Scope-lar (nümunələr):- `bets:write`, `settlements:write`, `wallet:credit`, `wallet:debit`, `rg:read`, `rg:enforce`, `jackpot:trigger`.
Audience: kimə ünvanlanmış token (məsələn, 'aud: wallet. api`).
Constraints (fine-grained):- `brand_id`, `region`, `ip/cidr`, `time_of_day`, `rate_limit`, `max_amount`.
- Tokendə (JWT claims) və ya Vault/STS-də yazılan «mandatda» saxlanılır.
6) istinad flow
6. 1 RGS ⇄ platforması: RPC pulu
1. mTLS handshake (per brand/region sertifikatları).
2. OAuth2 CC: RGS 'access _ token' alır (TTL 2-5 dəq, 'aud = wallet. api`, `scope=bets:write settlements:write`).
3. Başlıqlı 'POST/v1/bets/authorize' sorğusu:- `Authorization: Bearer
`, `X-Idempotency-Key`, `X-Trace-Id`. - 4. Cavab + WORM-audit qeyd (kim/nə/nə vaxt/haradan).
- 5. Tokenin rotasiyası sorunsuz, sonra - CC təkrarı.
6. 2 Webhook platforma → provayder
Başlıq 'X-Signature: eddsa =
Provayder yoxlayır: etibarlılıq pəncərəsi (± 5 dəq), birdəfəlik 'nonce', bədən imzası.
Əlçatmazlıqda - c backoff retrai, 'event _ id' dedupu.
6. 3 Nümayəndəlik (cekpot xidməti → cüzdan)
JP STS çağırır: «'wallet: credit' üçün müvəqqəti token 'player _ id = p _...', cəmi ≤ X, TTL 2 dəq».
STS siyasət/limitləri yoxlayır → mandat verir (dar token).
JP bu token ilə cüzdan kredit verir. Belə bir tokeni güzəştə getməyin mənası yoxdur: qısa TTL, dar hüquqlar, mTLS-ə qoşulma.
7) Dizayn sorğular
7. 1 İdempotentlik (mütləq)
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" }
(eyni açar ilə təkrar → eyni cavab)7. 2 Webhook imzası (HMAC)
X-Signature: sha256=BASE64(HMAC(secret, timestamp + "." + nonce + "." + body))
X-Timestamp: 1730000000
X-Nonce: 1f7a...8) Sirlərin və açarların idarə edilməsi
Vault/HSM/KMS: nəsil, saxlama, rotasiya, geri çağırış.
Per-mühit: sandbox/prod - müxtəlif etimad kökləri.
Per-marka/region: fərdi açarlar və sertifikatlar.
Avtomatik rotasiya: cron/xəbərdarlıq; sorunsuz əvəz üçün overlap-dövrlər.
Kod/log qadağası: sirlər stdout-da yazılmır, qəza-reportajlara düşmür.
Device/Workload identity: SPIFFE/SPIRE, K8s ServiceAccount → mTLS əl sirləri olmadan.
9) Avtorizasiya Siyasəti (RBAC/ABAC) və OPA
RBAC: роли «rgs», «wallet», «jackpot», «reporting».
ABAC: qaydalar «əgər 'region = EU' və 'brand = A' → icazə 'wallet: credit' ≤ 10k».
OPA/REGO və ya analoqları: mərkəzləşdirilmiş qərar qəbulu, siyasət versiyası, quru testlər.
10) Müşahidə və audit
Hər bir sorğu/hadisədə 'trace _ id' və 'client _ id' vasitəsilə.
Metriklər: endpointlər üzrə p50/p95/p99 latency, kodlar üzrə error-rate ('AUTH _ FAILED', 'SCOPE _ DENIED', 'IDEMPOTENCY _ MISMATCH'), rotasiya tezliyi, vaxtı keçmiş tokenlərin payı.
WORM jurnalı: tokenlərin verilməsi/rəyləri, açarların dəyişdirilməsi, siyasətlərin dəyişdirilməsi.
Alertlər: 'AUTH _ FAILED' sıçrayışı, geo/ASN anomaliyaları, boy «gecikmiş/geri çağırılmış»> eşik.
11) Regional rezidentlik və seqmentləşdirmə
Tokenlər/sertifikatlar bölgəyə bağlıdır (EU/UK/BR/...).
«region» markalarında platforma şlüzləri kross-regional çağırışları qadağan edir.
Bölgədə ayrı KMS və Vault-klaster; açarlar bölgələr arasında «sürmür».
12) Hadisələr və rəy
Compromise playbook: ani açar/token revoke, şəbəkə blok/ASN, scope bağlama.
Kill-switch: «no new sessions/funds».
Postmortem: «log/anbara necə düşdü», «niyə DLP/Secret Scanner işləmədi».
13) Çek vərəqləri
A. Platforma üçün
- Bütün write yolları: mTLS + OAuth2 CC (TTL ≤ 5 dəq), 'X-Idempotency-Key', 'X-Trace-Id'.
- Vebhuke: HMAC/EdDSA + timestamp + nonce, dedup 'event _ id'.
- Keystor: Vault/HSM/KMS, rotasiya və geri çağırış, bölmə per brand/region.
- ORA/siyasət: RBAC/ABAC, dəyişikliklər jurnalları, testlər.
- WORM-audit və SLO-daşbordları (latency, error, revoke/rotate).
- DR/xaoc-təlimlər: köhnəlmiş tokenlər, imzaların dəyişdirilməsi, mTLS olmadan MITM.
B. Provayder üçün (RGS/live/JP)
- Kodda sirləri saxlamıram; Vault istifadə/mühit dəyişənləri vasitəsilə əvəz.
- Tokenlərin avtomatik rotasiyası; yeniləmə ilə 401/403 əl.
- Vebhuk imzalayıram/etibarlılıq və birdəfəlik pəncərələri yoxlayıram.
- Əsas hərəkətlərin auditini aparıram və Deprecation/Sunset başlıqlarına cavab verirəm.
- Bütün write zənglərində idempotentlik, 'Idempotency-Key' dedupu.
14) Anti-nümunələr (qırmızı bayraqlar)
Prod istifadə müddəti olmadan statik API açarları.
Kanal bağlantısı olmayan Bearer tokenləri (MTLS/DPoP yoxdur).
Git/CI-log/konfiqe frontenddə sirlərin saxlanması.
Bir neçə marka/bölgə üçün ümumi açar/sertifikat.
Vebhuka imzasız və vaxt pəncərəsi → replies.
Mərkəzləşdirilmiş rəy və WORM jurnalı yoxdur.
İdempotentliyin olmaması → debet/kreditlərin dublları.
15) Mini siyasət şablonları (nümunə, oxunan)
Mandat '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:…)`
- 'alg = Ed25519', pəncərə '± 300s', 'nonce' unikaldır, dedupt 'event _ id' 24 saat.
iGaming-də təhlükəsiz autentifikasiya təcrübələrin birləşməsidir: qısamüddətli mandatlar, kanal bağlantısı (mTLS/DPoP), dar skope/audience, ciddi idempotentlik, Vault/HSM və WORM auditi, regional seqmentasiya və müşahidə. Belə bir yığını inteqrasiya sürətinə mane olmur, lakin sızma və maliyyə hadisələri riskini kökündən azaldır - pul və məlumatlar nəzarət altında qalır, yeniləmələr proqnozlaşdırıla bilər və uyğunluq «qutudan» yerinə yetirilir.