نمذج الصلاحيات حول الأفعال

ينجح RBAC المؤسسي عندما تصف الصلاحيات أفعال عمل مستقرة، وتكون الأدوار مجرد حزم لهذه الصلاحيات. إذا كان الكود يسأل في كل مكان «هل المستخدم Admin؟» تتحول الأدوار إلى سياسة Hard-coded ويحتاج كل دور خاص بعميل إلى تعديل برمجي.

الدور حزمة صلاحيات وليس منطق سياسة

  • استخدم صلاحيات مثل invoice.read وinvoice.create وinvoice.approve بدل أسماء أدوار عامة داخل فحوص التفويض.
  • قيّد إسناد الأدوار بالمستأجر، وعند الحاجة بالقسم أو المورد.
  • افصل قدرات Maker وApprover عندما تتطلب العملية فصل المهام.
  • وصول Super Admin أو الدعم يجب أن يكون صريحًا ومؤقتًا قدر الإمكان ومدققًا بالكامل.
  • الافتراضي هو المنع؛ أي Permission أو Scope غير معروف يفشل مغلقًا.

مسار قرار التفويض

يُقبل الطلب بعد تقييم الصلاحية ونطاق المستأجر ونطاق المورد وقيود العملية قبل تنفيذ التغيير.

Diagram

قرار التفويض بدل التفرع على اسم الدور

يُقبل الطلب بعد تقييم الصلاحية ونطاق المستأجر ونطاق المورد وقيود العملية قبل تنفيذ التغيير.

إضافة معتمد مالي بأمان

فوّض القدرة لا اسم الدور

التطبيق يطلب قدرة عمل محددة وتتكفل طبقة السياسات بتقييم المستأجر والمورد.

authorize.tstypescript
await authorize(user, {
  permission: 'refund.approve',
  tenantId: refund.tenantId,
  resource: refund
});

أنماط RBAC الخاطئة

قائمة تصميم التفويض

  • أنشئ Permission Catalog بأفعال وموارد واضحة.
  • اجعل تعريف الأدوار قابلًا للتهيئة لكل مستأجر.
  • قيّم Scope وقواعد العملية بعد فحص الصلاحية.
  • سجل قرارات التفويض الحساسة.
  • اختبر مسارات المنع وقواعد Maker-Checker وتغيير الأدوار.