הילוך טורנט

מפתחות API, אסימונים ואישורים - אימות מאובטח

מאמר מלא

💡 18+. חומר טכני לפלטפורמות, אולפנים (RGS/Live), אגרגטורים ושירותים קשורים (jackpots, KYC/AML). לא שיחה לשחק.

1) למה כל זה: מודל האיום עבור iGaming

כסף ומח "ש: פשרת מפתח. הונאה, הדלפות, קנסות.

שילוב רשת: עשרות ספקים חיצוניים, אזורים/רישיונות שונים.

שיעורי ה ־ SLA הגבוהים: תשלום פשוט או כפול - סיכונים משפטיים ומוניטין.

מסקנה: אימות ואישור צריכים להיות ”בטוחים כברירת מחדל”, עם זכויות מינימליות ויכולת הבחנה קפדנית.

2) כלים: מה שיש לנו בארסנל

מפתחות API: זיהוי לקוח סטטי. אינטגרציה קלה, סיכון גבוה לדליפות.

OAuth2, אסימונים קצרי ימים עם היקף/קהל.

בדיקת TLS הדדית, קשירה חזקה של הלקוח לערוץ.

חתימות HMAC/EDDSA: שלמות קריפטוגרפית של הגוף המבוקש והגנה מפני הילוכים חוזרים (timamp + nonce).

הוכחת החזקה: אסימונים בעלי MTLS או DPoP (חתימה על בקשת HTTP עם מפתח לקוח).

JWT/PASETO: אסימונים המתארים את עצמם (רצוי עם TTL קצר).

RBAC/ABAC: אישור על בסיס תפקיד/מאפיין (OPA/מדיניות).

זמן וכרטיסים מוגבלים למטרה שהונפקו עבור תרחיש מסוים.

3) עקרונות בסיסיים (”תמרורי עצור”)

1. חיסיון מינימלי: לכל מפתח/אסימון יש את הזכויות הנמוכות ביותר האפשריות.

2. קצר ימים כברירת מחדל, דקות טי-טי-אל, לא ימים. הסיבוב הוא אוטומטי.

3. קשירה לערוץ: קשירת אסימונים ל ־ mTLS/DPoP חסרת תועלת בעת הדלפתם.

4. לכל מותג/אזור: מפתחות/תעודות והרשאות למותג/רישיון/אזור.

5. אין סודות משותפים בקוד: סודות רק דרך כספת/HSM/KMS, וגם לא ברישומים/Git.

6. ביקורת תולעת: יומנים לא משתנים של כל הפעולות/נושאים/סיבובים.

7. כל חזרה על אותו מפתח אינה משנה כסף בפעם השנייה.

4) מתי להשתמש באיזה הקשר (iGaming)

תרחיש	מומלץ על כך
Cash RPC (ארנק לאשר/להתיישב, קופאי)	MTLS + OAuth2 CC עם אסימונים בעלי MTLS; X-Idempotency-Key, "X-Trace-Id' Headers
Webhooks (אירועים)	HMAC/EDDSA + חותמת זמן/חתימת גוף nonce, מאפשרים-list מקורות, מגשים מחדש עם dauplication
קטלוגים/דיווחים של B2B	OAuth2 CC (נושא קצר ימים) + דירוג גבולות
משלחת מכונות (זכייה בארנק)	STS/Token Exchange עם היקף צר ו-TTL 5
לוח ניהול/מבצעים	OIDC לבני אדם + RBAC/ABAC, MFA/ביומטריה, ”ארבע עיניים”

5) עיצוב כרטיסי גישה (סקופים, קהל, תנאים)

היקף (דוגמאות):

”Bets': לכתוב”, ”התנחלויות: לכתוב”, ”ארנק: אשראי”, ”ארנק: חיוב”, ”rg: לקרוא”, ”rg: לאכוף”, ”כל הקופה: טריגר”.

קהל: למי ממוען האסימון (לדוגמה, 'אוד: ארנק. אפי ').

אילוצים (גרגירים עדינים):

'brand _ id',' region ',' ip/cidr ',' time _ of _ day ',' rate _ limit ',' max _ sume '.
מאוחסן באסימון (טענות JWT) או בכתב ”מנדט” בכספת/STS.

6) זרימת התייחסות

6. 1 RGS ⇄ פלטפורמה: RPC Money

1. לחיצת יד (MTLS).

2. OAuth2 CC: RGS מקבל ”גישה _ token” (TTL 2-5 דקות, 'aud = ארנק. api ',' היקף = הימורים: לכתוב התנחלויות: לכתוב '.

3. בקשה 'POST/V1/הימורים/אישור' with כותרות:

אישור: Bearer ””, X-Idempotency-Key ”,” X-Trace-Id'.
4. תשובה + כתוב לביקורת תולעת (מי/מה/מתי/איפה).
5. סיבוב האסימון הוא חלק, לאחר תפוגה - CC חוזר.

6. 2 webhooks platform @ info: whatsth

כותרת ”X-חתימה: eddsa = ” או ”Sha256 =”..., ”X-Timestamp”, ”X-Nonce”.

בדיקת הספק: חלון תוקף (non 5 min), nice, חתימת גוף.

אם לא זמין - מגש מחדש עם גיבוי, dedup by "event _ id'.

6. 3 משלחת (שירות הקופה * ארנק)

JP קורא ל-STS: ”תן סימן זמני על 'ארנק: קרדיט' עבור 'שחקן _ id = p _...', sum lold X, TTL 2 min”.

STS בודק את המדיניות/הגבולות.

ג 'יי-פי זוכה בארנק עם האסימון הזה. אין טעם להתפשר על אסימון כזה: TTL קצר, זכויות צרות, המחייב MTLS.

7) בניית שאילתות

7. 1 אידמפוטנטיות (נדרש)


פוסט/v1/הימורים/להתיישב
אישור: Bearer <MTLS-bound>
מפתח X-Idempotency: settle_r_8c12_1
אקס-טרייס-ID: tr_a1b2
{
”bet_id":"b_001,” ”round_id":"r_8c12,” ”לנצח ”: [”סכום ”: 1460,” מטבע”:” EUR”]
}
# 200 (”סטטוס ”): ”קרדיט”, ”settlement_id":"st_77”
(חזור עם אותו מפתח = תשובה זהה)

7. 2 חתימת Webhook (HMAC)


X-חתימה: Sha256 = BASE64 (סוד, חותמת זמן +. ”” + nonce + ”” + body)
חותמת X-Timestamp: 1730000000
X-Nonce: 1 f7a...

8) ניהול סודות ומפתחות

כספת/HSM/KMS: דור, אחסון, סיבוב, החזרה.

לכל סביבה: ארגז חול/פרוד - שורשים שונים של אמון.

לכל מותג/אזור: מפתחות אישיים ותעודות.

סיבוב אוטומטי: cron/התראות; חפיפה תקופות להחלפות ללא תפרים.

איסור בקוד/יומנים: סודות לא נכתבים כדי לעמוד, הם לא נכנסים לדיווחי התרסקות.

זהות התקן/עומס עבודה: SPIFFE/SPIRE, K8s Service Account # mTLS ללא סודות ידניים.

9) מדיניות אישור (RBAC/ABAC) ואופ "א

RBAC: rough "rgs'," ארנק "," כל הקופה "," דיווח ".

ABAC: "אם 'region = EU' and 'brand' כללים =" let' wallet: credit '10k ".

OPA/REGO או אנלוגים: קבלת החלטות מרכזיות, ויסות מדיניות, בדיקות יבשות.

10) יכולת תצפית וביקורת

עקבות מקצה לקצה _ id ולקוח _ id בכל בקשה/אירוע.

Metrics: p50/p95/p99 latency by Endpoints, IDEMPOTENCY _ MISMATCH), שיעור סיבוב, נתח אסימונים שפג תוקפם.

יומן תולעת: סוגיות אסימון/זכרונות, שינויי מפתח, שינויי מדיניות.

התראות: ”AUTH _ Appliced” Spike, Geo/ASN אנומליות, ”איחור/משיכה” growth> סף.

11) תושבות אזורית וקטע

אסימונים/תעודות (באנגלית: Tokens/Advictions) הם אזורי-ספציפי (EU/UK/BR/...).

במותגים, 'אזור', שערי פלטפורמה אוסרים קריאות חוצות-אזוריות.

מקבצי KMS וכספת נפרדים לכל אזור; מפתחות לא ”לנהוג” בין האזורים.

12) אירועים ונזכרים

משחק פשרה: ביטול מפתח מיידי/אסימון, בלוק רשת/ASN, סגירת היקף.

מתג חיסול ברמת שער: ”אין מפגשים/קרנות חדשות”.

לאחר המוות: "כאשר הוא נכנס ליומנים/מאגר," מדוע הסורק הסודי/DLP לא עבד ".

13) רשימות בדיקה

א. עבור פלטפורמה

כל המסלולים: mTLS + CC (TTL 5 Min), X-Idempotency-Key, X-Trace-ID.

[ ] Webhooks: HMAC/EDSA + חותמת זמן + nonce, dedup by "event _ id'.

[ ] קיסטור: כספת/HSM/KMS, סיבוב וחזרה, מפוצלת לכל מותג/אזור.

[ ] אופ "א/מדיניות: RBAC/ABAC, שינוי יומנים, בדיקות.

[ ] ביקורת תולעת ולוחות מחוונים של SLO (latency, image, ביטול/סיבוב).

[ ] תורות DR/xaoc: אסימונים שפג תוקפם, חיקוי חתימה, MITM ללא mTLS.

B. לספק (RGS/Live/JP)

[ ] אני לא שומר סודות בקוד; באמצעות כספת/החלפה באמצעות משתני סביבה.

[ ] סיבוב אוטומטי של אסימונים; להתמודד עם 401/403 עם עדכון.

[ ] לחתום על פתקי אינטרנט/לבדוק חלונות תוקף וחד פעמי.

[ ] פעילויות מפתח ביקורת ולהגיב לכותרות Decretation/Sunset.

[ ] אידמפוטנטיות על כל שיחות כתיבה, dedup על ידי 'Idempotency-Key'.

14) אנטי דפוסים (דגלים אדומים)

מפתחות סטטיים ללא תאריך פקיעה במכירות.

אסימונים ללא קשירה לערוץ (ללא MTLS/DPoP).

אחסון סודות ביומן Git/CI/frontend config.

מפתח/תעודה משותפת עבור מספר מותגים/אזורים.

Hooks ללא חתימה ו חלון זמן _ שידור חוזר.

היעדר משוב מרכזי ויומן תולעת.

חוסר אידמפוטנטיות * לשכפל חיובים/קרדיטים.

15) תבניות מדיניות מיני (דוגמה, אדם קריא)

כרטיס 'rgs = ארנק' (EU, מותג A):

'Aud = ארנק. api ', 'היקף = [ ”הימורים: לכתוב ”, ”התנחלויות: לכתוב” ]
constraints: אזור = האיחוד האירופי, מותג = A, ip in {...}, max_amount=5000 EUR, tl = 300s&fos
”מתחבר: MTLS (cert_hash=sha256:...)”

Webhook 'wallet. אשראי. בסדר ":

'alg = Ed25519', חלון 'שנות ה -30,' nce 'ייחודי, אירוע' סבא _ id '24 שעות.

אימות מאובטח ב-iGaming הוא שילוב של פרקטיקות: מנדטים קצרי ימים, קשרי ערוץ (mTLS/DPoP), היקף צר/קהל, אידיאפוטנטיות קפדנית, Vault/HSM וביקורת תולעת, קטגוריות אזוריות ויכולת תצפית. ערימה כזו אינה מפריעה למהירות האינטגרציה, אלא מפחיתה באופן קיצוני את הסיכון לדליפות ולתקריות פיננסיות - כסף ונתונים נשארים תחת שליטה, שדרוגים צפויים ומבוצעים מתוך התיבה.