مراقبة الدخول و RBAC في API
1) لماذا التحكم في وصول واجهة برمجة التطبيقات
التفويض هو الجواب على السؤال "هل يستطيع هذا الممثل أداء هذا الإجراء على هذا المورد الآن ؟ ». تؤدي الأخطاء إلى تسرب BOLA/IDOR وتصاعد الحقوق وانتهاك المتطلبات التنظيمية. الهدف هو بناء نموذج متعدد المستويات: هريس محيط الخدمة → → قواعد العمل، مع سياسات وفحوصات صريحة على مستوى الكائن.
2) نماذج الترخيص: متى تختار ما
RBAC (التحكم في الوصول القائم على الأدوار) - الأدوار → الأذونات. بسيطة ومستقرة ولكنها عرضة «لانفجار الأدوار».
ABAC (على أساس السمة) - قرار بشأن سمات الموضوع/الهدف/السياق (البلد، مستوى KYC، مالك الموارد، المخاطر).
ReBAC (القائم على العلاقات) - الرسم البياني للعلاقة (المالك، عضو الفريق، «مدير المشروع») ؛ يحل التسلسلات الهرمية المعقدة.
Scopes (OAuth) - عقد بين العميل وخادم الموارد حول «منطقة الوصول» (على سبيل المثال، «المدفوعات: الكتابة»).
الممارسة: المكتب الإقليمي لآسيا والمحيط الهادئ للمصفوفة الأساسية، و ABAC للسياق والقيود، و ReBAC للتسلسلات الهرمية المعقدة (المجلدات والمنظمات والحدود والحسابات).
3) تصنيف الموارد والإجراءات
التسلسل الهرمي: «org → project → wallet → traction». ميراث الحقوق من أعلى إلى أسفل مع «محددات» محتملة.
الإجراءات: CRUD + domain-specific («الموافقة»، «استرداد»، «تسوية»).
خصائص الموارد: المالك، المنطقة، الحالة، بطاقات المخاطر (AML/KYC)، الحدود.
تعدد الإيجارات: تحتوي جميع الحلول على «مستأجر - هوية» ؛ الإنكار الافتراضي.
4) الهندسة المعمارية: حيث يتم اتخاذ القرار
PEP (نقطة إنفاذ السياسة) - موقع التحقق: بوابة/بوابة برمجة التطبيقات، هريس جانبي، خدمة نفسها.
PDP (نقطة قرار السياسة) - محرك السياسة: مركزي (خدمة OPA، محرك الأرز) أو مكتبة مدمجة.
PIP (نقطة معلومات السياسة) - مصادر السمة: دليل المستخدم/الدور، موجز المستأجر، CCP/المخاطر، خريطة ملكية الموارد.
PAP (Policy Administration Point) - إصدار السياسات والنشر والتدقيق.
توصية: مخبأ مركزي للحلول المحلية في برنامج تطوير البرامج ؛ فحص الجسم المعقد في الخدمة في وجود ثوابت المجال.
5) الرموز والطوابع والهوية
OIDC/OAuth2: 'sub' (محدد الموضوع)، 'aud' (الخدمة المستهدفة)،' scope '/' roles '،' مستأجر '،' kyc _ level'، 'risk _ tier'.
JWT: توقيع RS/ES، «exp» قصير، إعادة الإصدار عن طريق التحديث. لا تضع PII ؛ استخدام 'jti' لإلغاء/تتبع مراجعة الحسابات.
MTLS/HMAC: الخدمة إلى الخدمة والشركاء ؛ يتم سحب الطوابع من الدليل بواسطة «lient _ id».
الجهاز/السياق: IP/ASN، geo، الوقت من اليوم - تسجيل الدخول إلى حل ABAC (على سبيل المثال، حظر الكتابة خارج ساعات العمل).
6) الإذن على مستوى الكائن (BOLA-first)
يجب أن ترد كل عملية على «هل الموضوع هو المالك/له الحق في هذا» المورد _ معرف «؟».
التحقق من الملكية: "مورد. owner_id = = الموضوع. أو العضوية في 'مؤسسة' لها دور.
عينات المرشح: تتراكب دائمًا "حيث الموارد. tenant_id =: المستأجر و... '(أمن على مستوى الصف).
بالنسبة للعمليات المرجعية (معرف في المسار/الجسم) - تطبيع المنطق التجاري والتحقق منه.
7) تصميم RBAC: الأدوار، الأذونات، المجموعات
الأذونات - الحقوق الذرية: "المحفظة. اقرأ «،» المحفظة. «،» الدفع. استرداد ".
الأدوار - مجموعات الإذن المسماة: «المشرف»، «الدعم». اقرأ «،» أمين الصندوق «،» الاحتيال. محلل '.
النطاقات - عقد خارجي للعملاء (رسم خرائط scope→permissions)
تجنب الأدوار المتفجرة:- الأدوار الأساسية + حزم الإذن،
- قيود ABAC (البلد/المنطقة/المستأجر)،
- «الوصول في الوقت المناسب».
8) ABAC/قيود السياق
الجغرافيا/الولاية القضائية: حظر الكتابة من البلدان المحظورة (الجزاءات/اللوائح).
الوقت/المخاطر: «المخاطر _ النتيجة <العتبة» للعمليات الكبيرة.
ACC/limits: 'kyc _ level> = 2' for pins> X; السيطرة على «التبريد» بين المعاملات.
«الأجهزة الموثوقة»: تتطلب mTLS للشركاء على الطرق الخطرة.
9) ReBAC ورسم بياني للحقوق
مفيد لهياكل الأعمال المعقدة (المجموعات والفرق والعلامات التجارية والفروع).
العلاقات: «عضو»، «مدير»، «مالك»، «مشاهد».
الحقوق المشتقة: «عارض» المورد موروث من «عضو» في المشروع الذي ينتمي إلى «org».
تخزين الرسوم البيانية: قاعدة بيانات ذات مصفوفة علاقات، خدمة متخصصة (بروح نهج زنجبار). Cache 'check (الموضوع، العلاقة، الكائن) الردود.
10) ذاكرة التخزين المؤقت للحلول والأداء
مخبأ PDP على مستوى PEP (على سبيل المثال، في البوابة) مع المفتاح: "مستأجر فرعي" مورد "إجراء" سياسة _ نسخة ".
TTL قصيرة (ثوانٍ - دقائق) + الإعاقة حسب الحدث: الدور/العلاقة/تغيير المستأجر.
فحص الدفعات (أصيل بالجملة) للقوائم: خفض رسوم PDP.
قياس حلول الكمون ؛ أثناء التدهور - التدهور الرشيق فقط للقراءة (ليس للكتابة/النقد).
11) أمثلة السياسة العامة
11. 1 طوابع JWT → PEP تقريبية (بوابة زائفة)
yaml
- match: { prefix: "/api/v1/wallets" }
authz:
require:
- claim: "aud"
equals: "wallet-service"
- claim: "scope"
includes_any: ["wallet. read", "wallet. write"]
context:
tenant_from: "claim:tenant"
11. 2 OPA/Rego (ABAC + BOLA)
rego package authz
default allow = false
allow {
input. action == "wallet. read"
input. subject. tenant == input. resource. tenant some role role:= input. subject. roles[_]
role == "support. read"
}
allow {
input. action == "payment. refund"
input. subject. tenant == input. resource. tenant input. subject. kyc_level >= 2 input. subject. risk_tier <= 2 input. subject. id == input. resource. owner_id # BOLA
}
11. 3 تقييد الولاية القضائية (سياسة رفض القائمة)
rego deny[msg] {
input. action == "withdraw. create"
input. context. country in {"IR","KP","SY"}
msg:= "Jurisdiction not allowed"
}
11. 4 سياسة ReBAC (زائفة)
allow(subject, "wallet. write", wallet) --
related(subject, "member", wallet. project) ∧ related(subject, "admin", wallet. org) ∧ wallet. tenant == subject. tenant.
12) إدارة السياسات والنسخ
إصدار السياسة («policy _ version») والكناري للتغييرات الخطيرة.
«التشغيل الجاف» (قرارات التشغيل الجاف/الظل) - سجل 'السماح/الرفض' دون تأثير.
دليل السياسات والهجرة: من تغير متى ولماذا ؛ رسم خرائط للحوادث.
اختبارات السيناريوهات السلبية (الحالات المحظورة) - مطلوبة في CI.
13) قابلية الملاحظة ومراجعة الحسابات
سجلات القرار: 'تتبع _ معرف'، 'موضوع'، 'مستأجر'، 'إجراء'، 'مورد _ معرف'، 'نتيجة'، 'سياسة _ نسخة'، سبب الفشل.
المقاييس: «authz _ decision _ latency»، «authz _ densed _ total {action}»، حصة من محاولات BOLA، معدل إصابة مخبأ.
لوحات القيادة: أهم الإخفاقات من قبل الإجراءات/المستأجرين، الاتجاهات بعد إصدارات السياسة.
14) السلامة والاستدامة
الإنكار الافتراضي: لا يوجد إذن صريح = الرفض.
فشل مغلق: عندما يكون PDP غير متاح، → الكتابة النقدية محظورة (أو تتدهور إلى «المجموعة الدنيا» من الأدوار التي تم التحقق منها بدقة).
«عمليات التحقق من الحراسة» المحلية ضمن الخدمات المقدمة للثوابت الحرجة (مثل «المستأجر »/« المالك»).
تقليل السمات المميزة في JWT ؛ تحميل السمات الحساسة عبر PIP عبر قناة آمنة.
15) تفاصيل iGaming/Finance
الأدوار: "أمين الصندوق"، "kyc. العميل '،' aml. ضابط، "احتيال. محلل '،' vip. مدير '،' خطر. الإدارة '.
القيود: تعتمد معاملات الدفع على 'kyc _ level'، وحدود المدفوعات المسؤولة، وحالة/جزاءات مكافحة غسل الأموال.
سجلات القفل: «org/brand/device/payment _ instrument» - مرشحات ABAC عند الكتابة.
سجلات مراجعة الحسابات دون تغيير بالنسبة لإجراءات KYC/AML/pin ؛ التخزين وفقا للمواعيد النهائية التنظيمية.
واجهات برمجة التطبيقات الشريكة: «نطاقات» عقد mTLS + على الطرق، مرشحات geo/ASN على المحيط.
16) الاختبار والتحقق
المصفوفة السلبية: قائمة الحالات «المحظورة» الصريحة وإصلاحها بالاختبارات.
إذن Fuzz: استبدال «مستأجر _ معرف»، «مالك _ معرف»، تجاوز المرشحات عند التثبيت/الفرز.
اختبار حمل PDP: تحقق من زمن انتقال وسلوك المخابئ في p95/p99.
إصدار السياسة: الجاف + الكناري + الاختبار التلقائي مع الرفض/السماح المتوقع.
الحوادث: طلبات إعادة التشغيل على المنصة مع نسخة دقيقة من السياسات.
17) أنتيباترن
اعتمد فقط على «النطاق» دون فحص الكائن (BOLA).
امزج منطق العمل وفحوصات الحقوق في كل معالج بدون نموذج مركزي.
أدوار الرمز الصلب في واجهة المستخدم وحلول الثقة للعملاء.
عدم وجود مرشحات «مستأجر »/« مالك» في الطلبات المقدمة إلى قاعدة البيانات (قراءات متسربة).
لا يوجد حل مخبأ للإعاقة عند تغيير الأدوار/العلاقات.
JWTs طويلة العمر دون استدعاء/تناوب.
18) قائمة التحقق من الاستعداد
- يتم تحديد الموارد/الأنشطة والتسلسلات الهرمية وتعدد الحيازات.
- مصفوفة RBAC الأساسية + محددات ABAC، عند الحاجة - ReBAC.
- تم تصميم PDP/PEP ؛ وهناك مخبأ محلي للحلول وإعاقته.
- السياسات محفوظة، اختبارات السيناريو السلبية في CI.
- يتحقق BOLA في كل كتابة/قراءة إلى «مورد _ معرف» محدد.
- JWT مع الحد الأدنى من الطوابع، قصير 'exp' ؛ مراجعة الحسابات/الاستدعاء على 'jti'.
- المقاييس/سجلات القرار، لوحات القيادة، التنبيهات عن طريق الرفض/الكمون.
- الإخفاق في الكتابة النقدية ؛ تم توثيق الوضع الاحتياطي.
- وثائق العملاء: 'النطاقات'، رموز الخطأ (401/403/404/409)، أمثلة.
19) TL ؛ د
بناء تصريح BOLA-first: مخبأ حل PDP + المركزي، RBAC كأساس، ABAC للسياق، ReBAC للعلاقات. وتندرج جميع الطلبات في سياق «المستأجر» و «المورد - الهوية» ؛ إنكار افتراضي، قصير JWT، مرشحات كائن في قاعدة البيانات. سياسات الإصدار والاختبار، قياس زمن الوصول/الرفض، حوادث إعادة التشغيل. بالنسبة إلى iGaming - الأدوار الفردية (KYC/AML/السجل النقدي)، ومحددات ABAC الصعبة والتدقيق غير القابل للتغيير.