مفاتيح API والرموز وأوراق الاعتماد - مصادقة آمنة

مقالة كاملة

💡 18+. مواد تقنية للمنصات والاستوديوهات (RGS/live) والمجمعات والخدمات ذات الصلة (الجوائز الكبرى، KYC/AML). ليست دعوة للعب.

1) لماذا كل هذا: نموذج التهديد لـ iGaming

المال و PII: حل وسط رئيسي → الاحتيال والتسريبات والغرامات.

تكامل الشبكة: العشرات من المزودين الخارجيين، مناطق/تراخيص مختلفة.

ارتفاع معدلات اتفاق استكهولم: الدفع البسيط أو المزدوج - مخاطر السمعة والمخاطر القانونية.

الاستنتاج: يجب أن يكون التوثيق والترخيص «آمنين افتراضيًا»، مع الحد الأدنى من الامتيازات وقابلية المراقبة الصارمة.

2) الأدوات: ما لدينا في ترسانتنا

مفاتيح واجهة برمجة التطبيقات: معرفات العملاء الثابتة. تكامل سهل، خطر كبير من التسريبات.

OAuth2 (أوراق اعتماد العميل): رموز حاملها قصيرة العمر ذات نطاق/جمهور.

mTLS: فحص TLS المتبادل، ربط قوي للعميل بالقناة.

توقيعات HMAC/EdDSA: سلامة التشفير لهيئة الطلب والحماية من الإعادة (timestamp + nonce).

إثبات الحيازة: رموز مرتبطة بـ MTLS أو DPoP (توقيع طلب HTTP مع مفتاح العميل).

JWT/PASETO: الرموز التي تصف نفسها بنفسها (ويفضل أن يكون ذلك باستخدام TTL قصير).

RBAC/ABAC: الإذن بالدور/السمة على أساس (OPA/مقررات السياسة العامة).

التفويض/STS: إصدار تذاكر محدودة الوقت والغرض لسيناريو محدد.

3) المبادئ الأساسية («علامات التوقف»)

1. أقل امتياز: يتمتع كل مفتاح/رمز بأقل حقوق ممكنة.

2. قصير الأجل افتراضيًا: دقائق TTL وليس أيام. الدوران تلقائي.

3. الارتباط بالقناة: رموز الرمز إلى mTLS/DPoP → عديمة الفائدة عند التسريب.

4. لكل علامة تجارية/منطقة: المفاتيح/الشهادات والأذونات - للعلامة التجارية/الترخيص/المنطقة.

5. لا توجد أسرار مشتركة في الكود: الأسرار فقط من خلال Vault/HSM/KMS، ولا في Git/logs.

6. مراجعة WORM: سجلات ثابتة لجميع العمليات/المشكلات/التناوب.

7. الغباء في الكتابة: أي تكرار بنفس المفتاح لا يغير المال مرة ثانية.

4) متى تستخدم ما (سياق iGaming)

السيناريو	الموصى به
النقدية RPC (ترخيص/تسوية المحفظة، أمين الصندوق)	mTLS + OAuth2 CC مع رموز مرتبطة بـ MTLS ؛ "X-Idempotency-Key"، رؤوس "X-Trace-Id'
حواجز شبكية (أحداث)	HMAC/EdDSA + timestamp/nonce body signature, engine-list sources, retrays with deuplication
كتالوجات/تقارير B2B	OAuth2 CC (حامل قصير العمر) + حدود المعدل
تفويض الآلة (الجائزة الكبرى → المحفظة)	STS/Token Exchange بنطاق ضيق و TTL ≤ 5 دقائق
فريق/عمليات الإدارة	OIDC للبشر + RBAC/ABAC، MFA/biometrics، «أربع عيون»

5) تصميم تذاكر الوصول (النطاقات والجمهور والشروط)

النطاق (أمثلة):

"bets: write"، "settlements: write"، "wallet: credit'،" wallet: debit'، "rg: read'،" rg: enforce "،" Gaxpot: trigger ".

الجمهور: لمن يتم توجيه الرمز المميز (على سبيل المثال، "aud: wallet. api ').

القيود (دقيقة الحبيبات):

"brand _ id"، "region"، "ip/cidr"، "time _ of _ day"، "rate _ limit'،" max _ cumber ".
مخزن في رمز (مطالبات JWT) أو في «تفويض» مكتوب في Vault/STS.

6) التدفق المرجعي

6. 1 منصة ⇄ RGS: أموال RPC

1. مصافحة mTLS (لكل علامة تجارية/شهادات المنطقة).

2. OAuth2 CC: RGS تحصل على «access _ token» (TTL 2-5 min، 'aud = wallet. api ',' scope = bets: write settlements: write ').

3. اطلب «POST/v1/bets/allege» بالرؤوس:

«الترخيص: حامل <رمز>،» X-Idempotency-Key «،» X-Trace-Id'.
4. الجواب + الكتابة إلى مراجعة WORM (من/ماذا/متى/أين).
5. دوران الرمز سلس، بعد انتهاء الصلاحية - كرر CC.

6. 2 مزود → منصة Webhooks

العنوان 'X-Signature: eddsa = أو' sha256 = '...،' X-Timestamp '،' X-Nonce '.

فحص المزود: نافذة الصلاحية (± 5 دقائق)، غير موجود، توقيع الجسم.

إذا لم يكن متاحًا - قم بإعادة الدرس مع النسخ الاحتياطي، والتخلص من "event _ id'.

6. 3 تفويض (خدمة الجائزة الكبرى → محفظة)

JP يتصل بـ STS: "أعط رمزًا مؤقتًا على" المحفظة: الائتمان "لـ" player _ id = p _...'، sum ≤ X، TTL 2 min ".

تتحقق STS من السياسة/الحدود → تصدر تذكرة (رمز ضيق).

ينسب JP الفضل إلى محفظة بهذا الرمز. من غير المجدي التنازل عن مثل هذا الرمز: TTL قصير، حقوق ضيقة، ملزم بـ mTLS.

7) بنى الاستعلام

7. 1 الخصوصية (مطلوب)


POST/v1/bets/settle
الإذن: حامل <متجه إلى MTLS>
X-Idempotency-Key: settle_r_8c12_1
X-Trace-Id: tr_a1b2
{
"bet_id":"b_001," round_id":"r_8c12, "" الفوز ": {" المبلغ ": 1460،" العملة ":" اليورو "}
}
→ 200 {«الحالة «: «الائتمان»، «settlement_id":"st_77»}
(كرر بنفس المفتاح → نفس الإجابة)

7. 2 توقيع Webhook (HMAC)


توقيع x: sha256 = BASE64 (HMAC (سري، timestamp +. «.» + nonce +. «» + body))
X-Timestamp: 1730000000
X-Nonce: 1f7a...

8) إدارة الأسرار والمفاتيح

Vault/HSM/KMS: التوليد والتخزين والتناوب والاستدعاء.

لكل بيئة: صندوق رملي/حث - جذور مختلفة للثقة.

لكل علامة تجارية/منطقة: مفاتيح وشهادات فردية.

التدوير التلقائي: كرون/تنبيهات ؛ فترات متداخلة للاستبدال السلس.

الحظر في الرمز/السجلات: لا يتم كتابة الأسرار بشكل شجاع، ولا تدخل في تقارير التصادم.

هوية الجهاز/عبء العمل: SPIFFE/SPIRE، K8s ServiceAccount → mTLS بدون أسرار يدوية.

9) سياسات الترخيص (RBAC/ABAC) و OPA

RBAC: роли "rgs'،" محفظة "،" جائزة كبرى "،" تقرير ".

ABAC: "إذا كانت" region = EU "و" brand = A "القواعد → تسمح بـ" wallet: credit' ≤ 10k ".

OPA/REGO أو نظائرها: صنع القرار المركزي، إصدار السياسات، الاختبارات الجافة.

10) قابلية الملاحظة ومراجعة الحسابات

تتبع من طرف إلى طرف _ معرف وعميل _ معرف في كل طلب/حدث.

المقاييس: p50/p95/p99 زمن الوصول حسب نقاط النهاية، معدل الخطأ بالرموز ('AUTH _ FAILL'، 'SCOPE _ DENED'، 'IDEMPOTENCY _ MISMATCH')، معدل التناوب، حصة من الرموجات منتهية الصلازمة.

سجل WORM: مشكلات/عمليات استدعاء رمزية، تغييرات رئيسية، تغييرات في السياسة.

التنبيهات: ارتفاع "AUTH _ FAILl'، شذوذ geo/ASN، نمو" متأخر/مسحوب "> عتبة.

11) الإقامة الإقليمية والتجزئة

الرموز/الشهادات خاصة بالمنطقة (EU/UK/BR/...).

في العلامات التجارية - «المنطقة»، تحظر بوابات المنصة المكالمات عبر المناطق.

عناقيد منفصلة من طراز KMS و Vault لكل منطقة ؛ المفاتيح لا «تقود» بين المناطق.

12) الحوادث وعمليات الاستدعاء

دليل التسوية: إلغاء المفتاح/الرمز الفوري، كتلة الشبكة/ASN، إغلاق النطاق.

تبديل القتل على مستوى البوابة: «لا جلسات/أموال جديدة».

بعد الوفاة: «عندما دخلت إلى السجلات/المستودع»، «لماذا لم يعمل DLP/الماسح السري».

13) القوائم المرجعية

ألف - للمنبر

جميع مسارات الكتابة: mTLS + OAuth2 CC (TTL ≤ 5 دقائق)، 'X-Idempotency-Key'، 'X-Trace-Id'.
عناوين الويب: HMAC/EdDSA + timestamp + nonce، dedup بواسطة "event _ id'.
Keistor: Vault/HSM/KMS، التناوب والاستدعاء، مقسم لكل علامة تجارية/منطقة.
OPA/policies: RBAC/ABAC، جذوع التغيير، الاختبارات.
لوحات متابعة مراجعة WORM و SLO (زمن الكمون، الخطأ، الإلغاء/التناوب).
تعاليم DR/xaoc: رموز منتهية الصلاحية، انتحال التوقيع، MITM بدون mTLS.

باء - للمزود (RGS/live/JP)

أنا لا أحتفظ بأسرار في الكود ؛ استخدام القبو/الاستبدال من خلال متغيرات البيئة.
التناوب التلقائي للرموز ؛ التعامل مع 401/403 مع التحديث.
وقع على خطوط الويب/تحقق من نوافذ الصلاحية وإمكانية التخلص منها.
مراجعة الأنشطة الرئيسية والاستجابة لعناوين Deprecation/Sunset.
الفراغ في جميع مكالمات الكتابة، التخلص من «Idempotency-Key».

14) الأنماط المضادة (الأعلام الحمراء)

مفاتيح واجهة برمجة التطبيقات الثابتة بدون تاريخ انتهاء الصلاحية في المبيعات.

رموز حامل دون ربط القناة (لا MTLS/DPoP).

تخزين الأسرار في Git/CI log/frontend config.

مفتاح/شهادة مشتركة لعلامات تجارية/مناطق متعددة.

خطافات الويب بدون توقيع ونافذة زمنية → إعادة التشغيل.

عدم وجود تغذية مرتدة مركزية وسجل WORM.

الافتقار إلى الخصوصية → ازدواجية الديون/الائتمانات.

15) نماذج السياسة المصغرة (مثال، مقروء بشري)

تذكرة «rgs→wallet» (الاتحاد الأوروبي، العلامة التجارية أ):

'aud = المحفظة. api ',' scope = ["bets: write", "settlements: write"] "
'قيود: المنطقة = الاتحاد الأوروبي، العلامة التجارية = A، ip in {asn:...}، max_amount=5000 EUR، tl = 300'
«ملزمة: mTLS (cert_hash=sha256:...)»

ممر Webhook. الائتمان. حسنًا:

"alg = Ed25519"، نافذة "± 30"، حدث "nonce" فريد، الجد "_ id '24 ساعة.

المصادقة الآمنة في iGaming هي مزيج من الممارسات: تفويضات قصيرة الأجل، ربط القناة (mTLS/DPoP)، ضيق النطاق/الجمهور، الخصوصية الصارمة، تدقيق Vault/HSM و WORM، التجزئة الإقليمية، وقابلية الملاحظة. لا تتداخل مثل هذه المكدسة مع سرعة التكامل، ولكنها تقلل بشكل جذري من مخاطر التسريبات والحوادث المالية - تظل الأموال والبيانات تحت السيطرة، ويمكن التنبؤ بالترقيات، ويتم الامتثال خارج الصندوق.