API Anahtarları, Belirteçler ve Kimlik Bilgileri - Güvenli Kimlik Doğrulama

Tam makale

💡 18+. Platformlar, stüdyolar (RGS/canlı), toplayıcılar ve ilgili hizmetler (ikramiyeler, KYC/AML) için teknik malzeme. Oynamak için bir çağrı değil.

1) Neden tüm bunlar: iGaming için tehdit modeli

Para ve PII: anahtar uzlaşma - dolandırıcılık, sızıntılar, para cezaları.

Ağ entegrasyonları: düzinelerce harici sağlayıcı, farklı bölgeler/lisanslar.

Yüksek SLA oranları: basit veya çift ödeme - itibar ve yasal riskler.

Sonuç: Kimlik doğrulama ve yetkilendirme, minimum ayrıcalık ve sıkı gözlemlenebilirlik ile "varsayılan olarak güvenli" olmalıdır.

2) Araçlar: Cephaneliğimizde ne var

API anahtarları: statik istemci kimlikleri. Kolay entegrasyon, yüksek sızıntı riski.

OAuth2 (Müşteri Kimlik Bilgileri): Kapsamı/kitlesi olan kısa ömürlü Bearer belirteçleri.

mTLS: Karşılıklı TLS kontrolü, müşterinin kanala güçlü bir şekilde bağlanması.

HMAC/edDSA imzaları: istek gövdesinin kriptografik bütünlüğü ve tekrarlara karşı koruma (zaman damgası + nonce).

Sahip Olma Kanıtı: MTLS'ye bağlı belirteçler veya DPoP (HTTP isteğini istemci anahtarıyla imzalama).

JWT/PASETO: kendini tanımlayan belirteçler (tercihen kısa bir TTL ile).

RBAC/ABAC: rol/nitelik tabanlı yetkilendirme (OPA/politika kararları).

Delegasyon/STS: Belirli bir senaryo için verilen zaman ve amaç sınırlı biletler.

3) Temel ilkeler ("Dur işaretleri")

1. En Az Ayrıcalık: Her anahtar/belirteç mümkün olan en düşük haklara sahiptir.

2. Varsayılan olarak kısa ömürlü: TTL dakika, gün değil. Rotasyon otomatiktir.

3. Kanala bağlayın: mTLS/DPoP'ye bağlanma belirteçleri sızdırıldığında işe yaramaz.

4. Marka/bölge başına: anahtarlar/sertifikalar ve izinler - marka/lisans/bölge için.

5. Kodda paylaşılan sırlar yok: sırlar yalnızca Vault/HSM/KMS aracılığıyla veya Git/günlüklerinde.

6. WORM denetimi: Tüm işlemlerin/sorunların/rotasyonların değişmeyen günlükleri.

7. Yazma üzerine idempotans: Aynı anahtarla yapılan herhangi bir tekrar, parayı ikinci kez değiştirmez.

4) Neyin ne zaman kullanılacağı (iGaming bağlamı)

Senaryo	Tavsiye edilen
Nakit RPC (cüzdan yetkilendirme/ödeme, kasiyer)	MTLS'ye bağlı belirteçlerle mTLS + OAuth2 CC; 'X-Idempotency-Key', 'X-Trace-Id' başlıkları
Webhooks (etkinlikler)	HMAC/EdDSA + zaman damgası/nonce gövde imzası, izin-listesi kaynakları, veri tekilleştirme ile retrays
B2B kataloglar/raporlar	OAuth2 CC (kısa ömürlü Taşıyıcı) + hız limitleri
Makine delegasyonu (jackpot - cüzdan)	Dar kapsam ve TTL ile STS/Token Değişimi ≤ 5 dk
Yönetici Paneli/İşlemler	İnsanlar için OIDC + RBAC/ABAC, MFA/biyometri, "dört göz"

5) Erişim biletlerinin tasarımı (kapsamlar, seyirci, koşullar)

Kapsam (örnekler):

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

Kitle: belirtecin kime hitap ettiği (örneğin, 'aud: cüzdan. api ').

Kısıtlamalar (ince taneli):

'brand _ id', 'region', 'ip/cidr', 'time _ of _ day', 'rate _ limit', 'max _ amount'.
Bir belirteçte (JWT iddiaları) veya Vault/STS'de yazılı bir "yetki'de saklanır.

6) Referans akışı

6. 1 RGS ⇄ Platformu: RPC Para

1. mTLS el sıkışma (marka/bölge sertifikalarına göre).

2. OAuth2 CC: RGS 'access _ token' alır (TTL 2-5 dakika, 'aud = cüzdan. api ',' scope = bets: write settlements: write ').

3. 'POST/v1/bets/authorized' başlıklarını başlıkla isteyin:

'Authorization: Bearer ', 'X-Idempotency-Key', 'X-Trace-Id'.
4. Cevap + WORM denetimine yaz (kim/ne/ne/ne zaman/nerede).
5. Belirtecin dönüşü, son kullanma tarihinden sonra sorunsuzdur - CC tekrarı.

6. 2 Webhooks platformu sağlayıcı

Başlık 'X-Signature: eddsa = ' veya 'sha256 =...', 'X-Timestamp', 'X-Nonce'.

Sağlayıcı kontrolleri: geçerlilik penceresi (± 5 dakika), nonce, vücut imzası.

Kullanılamıyorsa - 'event _ id'ile geri alma, dedup ile geri alma.

6. 3 Delegasyon (jackpot hizmeti - cüzdan)

JP, STS'yi çağırır: "'player _ id = p _...' için' cüzdan: kredi 'üzerine geçici bir jeton verin, toplam ≤ X, TTL 2 dk".

STS politikayı/limitleri kontrol eder - bir bilet verir (dar belirteç).

JP bu token ile bir cüzdana kredi verir. Böyle bir tokenden ödün vermek anlamsızdır: kısa TTL, dar haklar, mTLS'ye bağlanma.

7) Sorgu yapıları

7. 1 Idempotency (gerekli)


POST/v1/bets/settle
Yetkilendirme: Taşıyıcı <MTLS-bağlı>
X-Idempotency-Key: settle_r_8c12_1
X-Trace-Id: tr_a1b2
{
"bet_id":"b_001," round_id":"r_8c12, "win": {"miktar": 1460, "para birimi": "EUR"}
}
^ 200 {"durum ": "kredilendirilmiş", "settlement_id":"st_77"}
(aynı anahtarla tekrarla - aynı cevap)

7. 2 Webhook İmzası (HMAC)


X-Signature: sha256 = BASE64 (HMAC (gizli, zaman damgası + ". + nonce +". "+ gövde))
X-Zaman Damgası: 1730000000
X-Nonce: 1f7a...

8) Sırları ve anahtarları yönetin

Vault/HSM/KMS: üretim, depolama, rotasyon, geri çağırma.

Çevre başına: sandbox/prod - farklı güven kökleri.

Marka/bölge başına: bireysel anahtarlar ve sertifikalar.

Otomatik döndürme: cron/uyarılar; Kesintisiz değiştirmeler için çakışan dönemler.

Kodda/günlüklerde yasaklama: sırlar stdout'a yazılmaz, çarpışma raporlarına girmezler.

Aygıt/İş yükü kimliği: SPIFFE/SPIRE, K8s ServiceAccount - mTLS manuel sırlar olmadan.

9) Yetkilendirme Politikaları (RBAC/ABAC) ve OPA

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

ABAC: "if 'region = EU've' brand = A 'rules - allow' wallet: credit '≤ 10k".

OPA/REGO veya benzerleri: merkezi karar verme, politika sürümleri, kuru testler.

10) Gözlemlenebilirlik ve denetim

Her istek/olayda uçtan uca trace _ id ve client _ id.

Metrikler: Uç noktalara göre p50/p95/p99 gecikme, kodlara göre hata oranı ('AUTH _ FAILED', 'SCOPE _ DENIED', 'IDEMPOTENCY _ MISMATCH'), rotasyon oranı, süresi dolan belirteçlerin payı.

WORM günlüğü: belirteç sorunları/geri çağırmalar, önemli değişiklikler, politika değişiklikleri.

Uyarılar: 'AUTH _ FAILED' spike, geo/ASN anomalileri, 'gecikmiş/geri çekilmiş' büyüme> eşiği.

11) Bölgesel ikamet ve segmentasyon

Belirteçler/sertifikalar bölgeye özgüdür (AB/İngiltere/BR/...).

Markalarda - 'bölge', platform ağ geçitleri bölgeler arası çağrıları yasaklar.

Bölge başına ayrı KMS ve Vault kümeleri; Anahtarlar bölgeler arasında "sürmez".

12) Olaylar ve Geri Çağırmalar

Uzlaşma oyun kitabı: anlık anahtar/belirteç iptali, ağ bloğu/ASN, kapsam kapatma.

Ağ geçidi düzeyinde Kill-switch:'yeni oturum/fon yok ".

Postmortem: "Kayıtlara/depoya girerken", "neden DLP/gizli tarayıcı çalışmadı".

13) Kontrol listeleri

A. Platform için

Tüm yazma yolları: mTLS + OAuth2 CC (TTL ≤ 5 dk), 'X-Idempotency-Key', 'X-Trace-Id'.
Webhooks: HMAC/EdDSA + timestamp + nonce, dedup by 'event _ id'.
Keistor: Vault/HSM/KMS, rotasyon ve geri çağırma, marka/bölge başına bölünme.
OPA/politikalar: RBAC/ABAC, değişiklik günlükleri, testler.
WORM denetimi ve SLO panoları (gecikme, hata, iptal/döndürme).
DR/xaoc öğretileri: süresi dolmuş belirteçler, imza sahteciliği, mTLS'siz MITM.

B. Sağlayıcı için (RGS/canlı/JP)

Kodda sır saklamam; Ortam değişkenleri üzerinden Vault/substitution kullanımı.
Belirteçlerin otomatik dönüşü; Güncelleme ile 401/403 ele.
Webhook'ları imzalayın/geçerlilik pencerelerini ve değiştirilebilirliği kontrol edin.
Temel faaliyetleri denetleyin ve Amortisman/Sunset başlıklarına yanıt verin.
Tüm yazma çağrılarında idempotency, 'Idempotency-Key'tarafından dedup.

14) Anti-desenler (kırmızı bayraklar)

Satışlarda son kullanma tarihi olmayan statik API anahtarları.

Kanala bağlanmadan taşıyıcı belirteçler (MTLS/DPoP yok).

Git/CI günlüğü/frontend yapılandırmasında sırların saklanması.

Birden fazla marka/bölge için paylaşılan anahtar/sertifika.

İmzasız webhooks ve zaman penceresi - tekrar oynatma.

Merkezi geri bildirim ve WORM günlüğü eksikliği.

Idempotency eksikliği - yinelenen borçlar/krediler.

15) Mini politika şablonları (örnek, insan tarafından okunabilir)

Bilet 'rgs - cüzdan' (AB, marka A):

'aud = cüzdan. api ', 'scope = ["bets: write ", "settlements: write"] '
'trains: region = EU, brand = A, ip in {asn:...}, max_amount=5000 EUR, tl = 300 s'
'binding: mTLS (cert_hash=sha256:...)'

Webhook 'wallet. Kredi. Tamam ':

'alg = Ed25519', pencere '± 30'lar', 'nonce' benzersiz, büyükbaba'olay _ id '24 saat.

IGaming'de güvenli kimlik doğrulama, uygulamaların bir kombinasyonudur: kısa ömürlü mandalar, kanal bağlama (mTLS/DPoP), dar kapsam/kitle, sıkı idempotency, Vault/HSM ve WORM denetimi, bölgesel segmentasyon ve gözlemlenebilirlik. Böyle bir yığın entegrasyonların hızına müdahale etmez, ancak sızıntı ve finansal olay riskini radikal bir şekilde azaltır - para ve veriler kontrol altında kalır, yükseltmeler öngörülebilir ve uyumluluk kutudan çıkar.