Klucze API, tokeny i poświadczenia - bezpieczne uwierzytelnianie

Pełny artykuł

💡 18+. Materiał techniczny na platformy, studia (RGS/live), agregatory i usługi pokrewne (jackpoty, KYC/AML). Ani telefonu do zabawy.

1) Dlaczego to wszystko: model zagrożenia dla iGaming

Pieniądze i PII: kluczowy kompromis → oszustwa, przecieki, grzywny.

Integracja sieci: dziesiątki zewnętrznych dostawców, różne regiony/licencje.

Wysokie stawki SLA: proste lub podwójne płatności - ryzyko reputacyjne i prawne.

Wniosek: uwierzytelnianie i autoryzacja powinny być „domyślnie bezpieczne”, z minimalnymi uprawnieniami i ścisłą obserwowalnością.

2) Narzędzia: Co mamy w naszym arsenale

Klucze API: statyczne identyfikatory klienta. Łatwa integracja, wysokie ryzyko wycieków.

OAuth2 (Credentials Client): krótkotrwałe żetony na okaziciela z zakresem/publicznością.

mTLS: wzajemne sprawdzenie TLS, silne powiązanie klienta z kanałem.

Podpisy HMAC/EdDSA: integralność kryptograficzna organu wnioskującego i ochrona przed powtórzeniami (znacznik czasowy + nonce).

Dowód posiadania: żetony związane z MTLS lub DPoP (podpisanie żądania HTTP za pomocą klucza klienta).

JWT/PASETO: samodzielnie opisujące się żetony (najlepiej z krótkim TTL).

RBAC/ABAC: autoryzacja na podstawie roli/atrybutów (OPA/decyzje dotyczące polityki).

Delegacja/STS: Bilety czasowe i celowe wydane na określony scenariusz.

3) Podstawowe zasady („znaki stop”)

1. Najmniejszy przywilej: każdy klucz/token ma jak najniższe prawa.

2. Krótkotrwały domyślnie: TTL minut, nie dni. Obrót jest automatyczny.

3. Powiązanie z kanałem: wiązanie żetonów z mTLS/DPoP jest bezużyteczne po wycieku.

4. Dla marki/regionu: klucze/certyfikaty i uprawnienia - dla marki/licencji/regionu.

5. Brak wspólnych tajemnic w kodzie: sekrety tylko przez skarbiec/HSM/KMS, ani w Git/logs.

6. Audyt WORM: niezmienne dzienniki wszystkich operacji/problemów/rotacji.

7. Idempotencja na zapisach: każde powtórzenie z tym samym kluczem nie zmienia pieniędzy po raz drugi.

4) Kiedy korzystać z czego (kontekst iGaming)

Scenariusz	zalecane
Cash RPC (portfel autoryzować/rozliczać, kasjer)	mTLS + OAuth2 CC z żetonami MTLS; „X-Idempotency-Key”, „X-Trace-Id' headers”
Haki internetowe (wydarzenia)	HMAC/EdDSA + sygnatura nadwozia timestamp/nonce, źródła listy zezwoleń, przekładki z deduplication
Katalogi/raporty B2B	OAuth2 CC (krótkotrwały okaziciel) + limity stawek
Delegacja maszyny (jackpot → portfel)	Giełda STS/Token o wąskim zakresie i TTL ≤ 5 min
Panel administracyjny/operacje	OIDC dla ludzi + RBAC/ABAC, MFA/biometria, „cztery oczy”

5) Projektowanie biletów dostępu (zakresy, publiczność, warunki)

Zakres (przykłady):

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

Publiczność: do której skierowany jest token (na przykład "aud: portfel. api ").

Ograniczenia (drobnoziarniste):

'brand _ id',' region ',' ip/cidr ',' time _ of _ day ',' rate _ limit ',' max _ amount '.
Przechowywany w tokenie (roszczenia JWT) lub w pisemnym „mandacie” w Vault/STS.

6) Przepływ odniesienia

6. Platforma ⇄ 1 RGS: Pieniądze RPC

1. Uścisk dłoni mTLS (na certyfikaty marki/regionu).

2. OAuth2 CC: RGS otrzymuje 'access _ token' (TTL 2-5 min, 'aud = portfel. api ',' scope = bets: napisać settlements: write ').

3. Żądanie 'POST/v1/bets/authorize' z nagłówkami:

"Autoryzacja: Bearer ", "X-Idempotence-Key", "X-Trace-Id'.
4. Odpowiedź + napisz do audytu WORM (kto/co/kiedy/gdzie).
5. Obrót żetonu jest bez szwu, po wygaśnięciu - powtórzyć CC.

6. 2 Platforma Webhooks → dostawca

Nagłówek „X-Signature: eddsa = ” lub „sha256 =...”, „X-Timestamp”, „X-Nonce”.

Sprawdzenie dostawcy: okno ważności (± 5 min), nonce, podpis nadwozia.

Jeśli niedostępny - przekładać z backoff, dedup przez 'event _ id'.

6. 3 Delegacja (jackpot service → portfel)

JP wywołuje STS: „daj tymczasowy symbol na 'portfelu: kredyt' dla 'player _ id = p _...', suma ≤ X, TTL 2 min”.

STS sprawdza zasady/limity → wydaje bilet (wąski token).

JP zapisuje portfel z tym tokenem. Nie ma sensu kompromitować takiego znaku: krótki TTL, wąskie prawa, wiążące dla mTLS.

7) Konstrukcje zapytań

7. 1 Idempotencja (wymagana)


POST/v1/zakłady/rozrachunek
Autoryzacja: Bearer <MTLS-related>
X-Idempotency-Key: settle_r_8c12_1
X-Trace-Id: tr_a1b2
{
"bet_id":"b_001," "round_id":"r_8c12," "wygraj': {" kwota ": 1460," waluta ":" EUR "}
}
→ 200 {„status „: „uznany”, „settlement_id":"st_77”}
(powtarzać z tym samym kluczem → ta sama odpowiedź)

7. Podpis 2 Webhook (HMAC)


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

8) Zarządzanie tajemnicami i kluczem

Skarbiec/HSM/KMS: generowanie, przechowywanie, obracanie, wycofywanie.

Per-environment: piaskownica/prod - różne korzenie zaufania.

Per-marka/region: poszczególne klucze i certyfikaty.

Automatyczny obrót: cron/alerty; okresy nakładania się na bezszwowe zamienniki.

Zakaz w kodzie/dziennikach: sekrety nie są zapisywane do stdout, nie dostają się do raportów awarii.

Identyfikacja urządzenia/obciążenia roboczego: SPIFFE/SPIRE, Konto K8s, → mTLS bez tajemnic ręcznych.

9) Polityka autoryzacji (RBAC/ABAC) i OPA

RBAC: рола „rgs”, „wallet”, „jackpot”, „reporting”.

ABAC: „if 'region = EU' and 'brand = A' rules → allow 'wallet: credit' ≤ 10k”.

OPA/REGO lub analogi: scentralizowane podejmowanie decyzji, wersioning polityki, testy suche.

10) Obserwowalność i audyt

End-to-end trace _ id i client _ id w każdym żądaniu/zdarzeniu.

Wskaźniki: opóźnienie p50/p95/p99 według punktów końcowych, wskaźnik błędów według kodów („AUTH _ FAILED”, „SCOPE _ DENIED”, „IDEMPOTENCY _ MISMATCH”), wskaźnik rotacji, udział tokenów wygasłych.

Dziennik WORM: token issues/recalls, key changes, policy changes.

Wpisy: 'AUTH _ FAILED' spike, anomalie geo/ASN, 'overdue/withdrawn' growth> threshold.

11) Rezydencja regionalna i segmentacja

Żetony/certyfikaty są specyficzne dla danego regionu (EU/UK/BR/...).

W markach - „region”, bramy platformy zakazują połączeń międzysregionalnych.

oddzielne klastry KMS i Vault dla każdego regionu; klucze nie „napędzają” między regionami.

12) Incydenty i wspomnienia

Kompromisowy odtwarzacz: natychmiastowe odwołanie klucza/tokena, blok sieci/ASN, zamknięcie zakresu.

Kill-switch na poziomie bramy: „brak nowych sesji/funduszy”.

Postmortem: „jak dostał się do dzienników/repozytorium”, „dlaczego DLP/tajny skaner nie działa”.

13) Listy kontrolne

A. Dla platformy

Wszystkie ścieżki zapisu: mTLS + OAuth2 CC (TTL ≤ 5 min), 'X-Idempotency-Key', 'X-Trace-Id'.
Haki internetowe: HMAC/EdDSA + timestamp + nonce, dedup by 'event _ id'.
Keistor: Vault/HSM/KMS, rotacja i wycofanie, podział na marki/region.
OPA/polityki: RBAC/ABAC, dzienniki zmian, testy.
Tablice kontrolne WORM i SLO (opóźnienie, błąd, cofnięcie/obrót).
Nauki DR/xaoc: utracone żetony, spoofing podpisu, MITM bez mTLS.

B. Dla dostawcy (RGS/live/JP)

Nie mam tajemnic w kodzie; za pomocą skarbca/substytucji za pomocą zmiennych środowiskowych.
Automatyczne obracanie żetonów; uchwyt 401/403 z aktualizacją.
Sign webhooks/check validity windows and disposability.
Audyt kluczowych działań i odpowiedź na nagłówki Deprecation/Sunset.
Idempotencja na wszystkich wezwaniach do pisania, dedup by 'Idempotence-Key'.

14) Anty-wzory (czerwone flagi)

Statyczne klucze API bez daty ważności w sprzedaży.

Żetony na okaziciela bez wiązania z kanałem (bez MTLS/DPoP).

Przechowywanie tajemnic w konfiguracji Git/CI.

Wspólny klucz/certyfikat dla wielu marek/regionów.

Haki bez podpisu i okna czasowego → powtórka.

Brak scentralizowanych informacji zwrotnych i dziennika WORM.

Brak idempotencji → duplikat debetów/kredytów.

15) Mini szablony polityki (przykład, czytelny dla ludzi)

Bilet 'rgs → portfel' (UE, marka A):

'aud = portfel. api ', 'scope = [„bets: write „, „settlements: write”] '
"constraints: region = UE, marka = A, ip in {asn:...}, max_amount=5000 EUR, ttl = 300 s'
„binding: mTLS (cert_hash=sha256:...)”

Portfel Webhook'a. kredytu. OK ':

'alg = Ed25519', okno '± 30s', 'nonce' unikalne, dziadek 'event _ id' 24 godziny.

Bezpieczne uwierzytelnianie w iGaming to połączenie praktyk: krótkotrwałych mandatów, wiązania kanałów (mTLS/DPoP), wąskiego zakresu/publiczności, ścisłej idempotencji, audytu Vault/HSM i WORM, segmentacji regionalnej i obserwowalności. Taki stos nie zakłóca szybkości integracji, ale radykalnie zmniejsza ryzyko wycieków i incydentów finansowych - pieniądze i dane pozostają pod kontrolą, aktualizacje są przewidywalne, a zgodność jest wykonywana poza pudełkiem.