Крипто казино
Torrent Gear
API кілттері, токендер және қол жеткізу мандаттары: қауіпсіз аутентификация
Мақаланың толық мәтіні
1) Бұл не үшін: iGaming үшін қауіп-қатер моделі
Ақша және PII: кілттің компрометациясы → фрод, жылыстау, айыппұлдар.
Желілік интеграция: ондаған сыртқы провайдерлер, әртүрлі өңірлер/лицензиялар.
Жоғары SLA ставкалары: қарапайым немесе қосарланған төлем - беделді және заңды тәуекелдер.
Қорытынды: аутентификация және авторизация «әдепкі қауіпсіз» болуы керек, ең аз артықшылықтармен және қатаң бақылаумен.
2) Құралдар: бізде арсеналда не бар
API кілттері: клиенттің статикалық идентификаторлары. Интеграция оңай, ағып кету қаупі жоғары.
OAuth2 (Client Credentials): scope/audience бар қысқа тұратын Bearer-токендер.
mTLS: өзара TLS-тексеру, клиентті арнаға күшті байланыстыру.
HMAC/EdDSA қолтаңбалары: сұрау салудың криптографиялық тұтастығы және реплеядан қорғау (timestamp + nonce).
Proof-of-Possession: MTLS-bound токендері немесе DPoP (клиент кілтімен HTTP сұрауының қолы).
JWT/PASETO: өздігінен жазылатын токендер (мүмкіндігінше қысқа TTL).
RBAC/ABAC: рөлі/атрибут-бейзд авторизациясы (ОРА/саясат шешімдері).
Уақытша қол жеткізу мандаттары (delegation/STS): нақты сценарийге берілетін уақыты мен мақсаттары бойынша шектелген билеттер.
3) Базалық қағидаттар («тоқтату белгілері»)
1. Least Privilege: әрбір кілт/токенге - ең аз мүмкін құқықтар.
2. Short-lived by default: TTL минуттармен, күндермен емес. Ротация - автоматты түрде.
3. Bind to channel: mTLS/DPoP → токендері ағып кеткенде пайдасыз.
4. Per-brand/region: кілттер/сертификаттар және рұқсаттар - брендке/лицензияға/өңірге.
5. Кодтағы No shared secrets: құпиялар тек Vault/HSM/KMS арқылы, не Git/log.
6. WORM-аудит: барлық операциялардың/берулердің/ротациялардың өзгермейтін логтары.
7. Write жолдарындағы теңсіздік: сол кілтпен кез келген қайталау ақшаны екінші рет өзгертпейді.
4) Не пайдалану керек (iGaming-контекст)
5) Қол жеткізу мандаттарының дизайны (scopes, audience, шарттар)
Scope-лар (мысалдар):- `bets:write`, `settlements:write`, `wallet:credit`, `wallet:debit`, `rg:read`, `rg:enforce`, `jackpot:trigger`.
Audience: кімге арналған токен (мысалы, 'aud: wallet. api`).
Constraints (fine-grained):- `brand_id`, `region`, `ip/cidr`, `time_of_day`, `rate_limit`, `max_amount`.
- Токенде (JWT claims) немесе Vault/STS жазылған «мандатта» сақталады.
6) Эталондық флоу
6. 1 RGS ⇄ платформасы: RPC бойынша ақша
1. mTLS handshake (per brand/region сертификаттары).
2. CC OAuth2: RGS 'access _ token' (TTL 2-5 мин., 'aud = wallet) алады. api`, `scope=bets:write settlements:write`).
3. 'POST/v1/bets/authorize' сұрауы
`Authorization: Bearer
4. Жауап + WORM-аудитке жазу (кім/не/қашан/қайдан).
5. Токеннің ротациясы жіксіз, аяқталғаннан кейін - CC қайталануы.
6. 2 Вебхактар платформасы → провайдер
'X-Signature: eddsa =
Провайдер тексереді: дәлдік терезесі (± 5 мин), бір реттік 'nonce', дененің қолы.
Қол жеткізбегенде - backoff, дедуп 'event _ id'.
6. 3 Жіберу (джекпот қызметі → әмиян)
JP STS шақырады: «Уақытша 'wallet: credit' үшін 'player _ id = p _...', сомасы ≤ X, TTL 2 мин».
STS саясатты/лимиттерді тексереді → мандатты береді (тар токен).
JP осы белгісі бар әмиянды несиелендіреді. Мұндай токенді бұзудың мәні жоқ: қысқа TTL, тар құқықтар, mTLS-ке байланыстыру.
7) Сұрау конструкциялары
7. 1 Сәйкессіздік (міндетті түрде)
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/prod - сенімнің әртүрлі тамыры.
Пер-бренд/өңір: жеке кілттер мен сертификаттар.
Авто-ротация: cron/құлақтандыру; overlap - жіксіз ауыстыру кезеңдері.
Тыйым салу: құпиялар stdout-та жазылмайды, crash-репорттарға түспейді.
Device/Workload identity: SPIFFE/SPIRE, K8s ServiceAccount → 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 latency эндпоинттер бойынша, error-rate кодтар бойынша ('AUTH _ FAILED', 'SCOPE _ DENIED', 'IDEMPOTENCY _ MISMATCH'), айналу жиілігі, мерзімі өткен токендер үлесі.
WORM журналы: токендер/пікірлер, кілттерді ауыстыру, саясатты өзгерту.
Алерттар: 'AUTH _ FAILED', гео/ASN бойынша аномалиялар, «мерзімі өткен/қайтарып алынған»> шегі.
11) Өңірлік резиденттілік және сегменттеу
Токендер/сертификаттар аймаққа байланыстырылған (EU/UK/BR/...).
«region» деген таңбаларда платформалық шлюздер кросс-өңірлік шақыруларға тыйым салады.
Аймаққа бөлек KMS және Vault-кластер; кілттер өңірлер арасында «жүрмейді».
12) Инциденттер және кері қайтарып алу
Compromise playbook: кілттер/токендер, желі блогы/ASN, scope жабу.
Kill-switch шлюз деңгейінде: «no new sessions/funds».
Постмортем: «логиге/репозиторийге қалай түсті», «неге DLP/құпия сканері жұмыс істемеді».
13) Чек парақтары
A. платформасы үшін
- Барлық write-жолдар: mTLS + OAuth2 CC (TTL ≤ 5 мин), 'X-Idempotency-Key', 'X-Trace-Id'.
- Вебхактар: HMAC/EdDSA + timestamp + nonce, дедуп бойынша 'event _ id'.
- Кейстор: Vault/HSM/KMS, ротация және кері қайтару, per brand/region.
- ОРА/саясат: RBAC/ABAC, өзгерістер журналдары, тесттер.
- WORM-аудит және SLO-дашбордтар (latency, error, revoke/rotate).
- DR/xaoc-жаттығулар: ескірген белгілер, қолтаңбаларды ауыстыру, mTLS жоқ MITM.
B, Провайдер үшін (RGS/live/JP)
- Құпияларды кодта сақтамаймын; Vault/ауыспалы орта арқылы алмастыруды пайдаланамын.
- Токендердің авто-ротациясы; handle 401/403 жаңартылған.
- Вебхукке қол қоямын/Дәлдік және біржолғы терезелерді тексеремін.
- Негізгі әрекеттерге аудит жүргізіп, Deprecation/Sunset тақырыптарына жауап беремін.
- Барлық write-шақырулардағы ұқсастық, «Idempotency-Key» дедупы.
14) Қарсы үлгілер (қызыл жалаулар)
Өнімдегі жарамдылық мерзімі жоқ статикалық API-кілттер
Арнаға байланыссыз Bearer-токендер (MTLS/DPoP жоқ).
Git/CI-логда/фронтенд конфигасында құпияларды сақтау.
Бірнеше брендтер/аймақтар үшін ортақ кілт/сертификат.
Қолтаңбасы жоқ және уақытша терезесі жоқ вебхактар → реплика.
Орталықтандырылған пікір мен 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:…)`
- 'alg = Ed25519', '± 300s', 'nonce' терезесі бірегей, дедуп 'event _ id' 24 сағат.
iGaming-тегі қауіпсіз аутентификация - бұл практикалардың комбинациясы: қысқа мерзімдік мандаттар, арнаға байланыстыру (mTLS/DPoP), тар scope/audience, қатаң теңсіздік, Vault/HSM және WORM-аудит, өңірлік сегментация және бақылау. Мұндай стек интеграция жылдамдығына кедергі келтірмейді, бірақ ақтару және қаржылық оқыс оқиғалар қаупін түбегейлі төмендетеді - ақша мен деректер бақылауда қалады, апгрейдтер болжамды түрде өтеді, ал комплаенс «қораптан» орындалады.