Аутентификация және авторизация

AuthN/AuthZ сенімді контуры - бұл сіз кім екеніңіз (аутентификация) және сізге рұқсат етілген (авторизация) туралы ақиқаттың бірыңғай нүктесі. Көптеген брендтері, өңірлері, интеграциялары және жоғары реттеуші талаптары бар платформада бұл контур «сервистер бойынша if-лердің шашырауы» емес, модульді, бақыланатын және саясаткерлер басқаратын болуы тиіс.

1) Негізгі терминдер мен рөлдер

ID: жеке тұлғаны анықтау (user, service, provider).
Аутентификация (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: b2b/операторлар үшін сыртқы IdP (SAML/OIDC) қолдау.
• 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)

Тұрақты workload идентификаторлары үшін + SPIFFE/SPIRE қызметтері арасындағы mTLS.
HSM/KMS қол қойған Service JWT қысқа мерзіммен (5 минутқа ≤); беру аудиті.
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 c) жасырындылықты төмендетеді; «рөлдердің/саясаттың өзгеруі» оқиғалары бойынша мүгедектік.

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: report. read`, `provider:events. push`.

Ең төменгі артықшылықтар қағидаты: тек қажетті сатып алуларды ғана тағайындаймыз; «эскалация» (құқықтардың уақытша кеңеюі) - тикет бойынша және TTL-мен.

8) Мульти-тенант және өңірлер (residency)

Токендерде 'tenant', 'region', 'licence' бар; PDP ресурсқа сәйкестігін тексереді.
Рөлдер/саясаттар - per tenant аттарының кеңістігі ('role: brand _ eu/support').
Қолтаңба кілттерін және кері қайтару тізімдерін өңірлер бойынша бөлу; кросс-өңірлік сұраулар - тек сенімді шлюздер арқылы.

9) Сессиялар мен құрылғыларды басқару

web үшін server-side session store (құрылғыға/браузерге байланыстыру, идентификаторды ротациялау).
Idle/Absolute Timeout (мысалы, 30 мин/24 сағ); сезімтал әрекеттер - re-Auth/MFA.
Белсенді құрылғылардың листингі, «барлығынан шығу».
Аномалиялар: әртүрлі өңірлерден бір мезгілде кіру, MFA-ның жиі бұзылуы - тәуекел сигналдары.

10) Жіберу және келісім (consent)

On-behalf-of (OBO): сервис пайдаланушының атынан әрекет етеді (жеке 'sub '/' act' бар прокси-токен).
Келісім: Серіктестің деректерге қол жеткізуі үшін айқын экран, пікірі бар келісім журналы.
Уақытша access-mandates: N сағат/күн құқықтары автоматты түрде аяқталады.

11) Кілттер, қолтаңбалар және ротация

JWKS с 'kid', автоматты ротация, KMS/HSM жеке кілттерді сақтау.
Алгоритмдер: JWT үшін ES256/EdDSA; TLS 1. 2+/mTLS.
Dual-key кезеңі: клиенттерді жаңарту аяқталғанға дейін екі '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`
• Кіру ауытқулары (new device, 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) Типтік қателер

Ұзақ өмір сүретін access-токендер → ағулар.
SPA-ға OAuth имплициттік ағыны.
Кезең кілттері мен Dual-Key ротациясының болмауы.
Саясаттың орнына кәдімгі рөлдер (шешімдерді тыңдау/түсіндіру мүмкін емес).
Бір 'role' немесе 'key' ішінде тенанттарды/аймақтарды араластыру.
Сезімтал әрекеттерде step-up MFA жоқ.
Рөлдердің өзгеруі бойынша мүгедектіксіз AuthZ шешімдерінің кэші.

17) Плейбуктар (runbooks)

1. JWT қолтаңба кілті

Дереу revoke 'kid', жаңа JWKS жариялау, RT/сессияларды мәжбүрлеп мүгедектендіру, аудит есебі.

2. Жаппай 'invalid _ token'

Рассинхронды/өмір сүру уақытын, JWKS өзектілігін, кэш ақауларын тексеру.

3. Кіріс ауытқулары

Жоғары тәуекел-скорингті қосу, step-up талап ету, пайдаланушыны хабардар ету, төлемдерді уақытша шектеу.

4. IdP жаңылысы

Сессия кэшіне/рольдік аппаратқа ауысу, жаңа логиндерді шектеу, қолданыстағы сессияларды TTL дейін ұстап тұру.

18) Азық-түлік алдындағы чек-парағы

• OIDC/OAuth 2. 1 PKCE, қысқа АТ, RT ротациясы, сыни операциялар үшін device binding.
• MFA (WebAuthn/TOTP) және деректемелерді/рөлді-эскалацияларды шығару/ауыстыру үшін step-up.
• Service-to-service: mTLS + SPIFFE, қысқа мерзімді JWT сервистік.
• Орталықтандырылған PDP-де AuthZ (RBAC + ABAC/ReBAC) саясаты; PEP gateway және сервистерде.
• Мүгедектігі бар шешімдердің кэші; audit trail өзгермейді.
• Мульти-тенант/өңірлер: кілттерді/саясаттарды/логтарды оқшаулау, лицензияларды есепке алу.
• JWKS/кілттер KMS/HSM, dual-key ротация, мониторинг 'kid'.
• CSRF/CORS/HSTS/Rate-limit/бот-сүзгілер периметрде.
• Оқиғалар ойнатқыштары, run-кнопкасы revoke/rotate/lockdown.
• Тесттер жиынтығы: unit (policies), 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, тенанттарды/өңірлерді қатаң оқшаулау, аудит және телеметрия. Мұндай дизайн өзгерістерді қауіпсіз, реттеуші үшін түсінікті және өнім үшін мөлдір етеді - ал нарықтар мен командалар бойынша масштабтау ерлікке емес, дағдылы операцияға айналады.