RBAC مقابل ABAC للأدوات الداخلية: اختيار صلاحيات قابلة للتوسع

لماذا تصبح الصلاحيات فوضوية في الأدوات الداخلية

الأدوات الداخلية تكون قريبة من أكثر أجزاء العمل حساسية: سجلات العملاء، ردود الأموال، الفواتير، ملاحظات الرواتب، قيم الصفقات، والتعليقات الداخلية الخاصة. ليس كل شخص يجب أن يرى كل شيء، وقليلون فقط يجب أن يحرروا هذه البيانات.

عادةً ما تبدأ الصلاحيات بسيطة: "الدعم يمكنه عرض التذاكر"، "المالية يمكنها الموافقة على ردود الأموال"، "المديرون يمكنهم رؤية أداء الفريق." ثم يكبر التنظيم، تتغير العمليات، وتتحوّل الأداة إلى رقعة من الاستثناءات.

نمط "ينفجر لاحقًا" هذا شائع:

• انتشار الأدوار: تضيف Support، ثم Support - Senior، ثم Support - EU، ثم Support - EU - Night Shift، حتى لا يتذكر أحد ما الذي يتضمنه كل دور.
• تسرب الاستثناءات: بعض الأشخاص يحتاجون "إذنًا إضافيًا واحدًا"، فتتكدس مؤشرات تبديل لمرة واحدة.
• تعرض عرضي: يمكن لشخص ما رؤية ملاحظات الرواتب، بيانات التعريف الشخصية للعميل، أو تقارير الإيرادات لأن شاشة أعيد استخدامها دون إعادة التحقق من الوصول.
• تكسّرات في سير العمل: يمكن للمستخدم رؤية سجل لكن لا يستطيع اتخاذ الخطوة التالية (أو، الأسوأ، يمكنه اتخاذها بدون رؤية السياق).
• تدقيق مؤلم: يصعب الإجابة على "من يمكنه الموافقة على ردود الأموال فوق 1,000؟" بدون بحث يدوي.

الهدف من اختيار RBAC أو ABAC مبكرًا ليس فقط قفل الشاشات. الهدف أن تبقى القواعد مفهومة عندما تظهر فرق جديدة، مناطق جديدة، وسياسات متغيرة.

نموذج صلاحيات يتحمل التغيّر يتميز بأربع صفات: سهل الشرح، سهل المراجعة، صعب إساءة الاستخدام، وسريع التغيير.

RBAC بمصطلحات بسيطة (الأدوار وما تفتحه)

RBAC (التحكم في الوصول بحسب الدور) هو نهج "المسمى الوظيفي". يحصل المستخدم على دور واحد أو أكثر (Support Agent, Admin). كل دور يأتي مع مجموعة ثابتة من الأشياء التي يمكن لهذا الدور رؤيتها وفعلها. إذا شارك شخصان نفس الدور، يحصلان على نفس الوصول.

يعمل RBAC جيدًا عندما تعمل الفرق بنفس الطريقة يوميًا والأسئلة الأساسية تكون على مستوى الميزة: "هل يمكنهم استخدام هذه الشاشة؟" أو "هل يمكنهم القيام بهذا الإجراء؟"

أمثلة عن أدوار في وحدة دعم:

• Support Agent: عرض التذاكر، الرد على العملاء، إضافة ملاحظات داخلية
• Support Lead: كل ما يفعله الوكيل، بالإضافة إلى إعادة تعيين التذاكر وعرض مؤشرات الفريق
• Admin: إدارة المستخدمين، تغيير إعدادات النظام، تعديل قواعد الصلاحيات

الفكرة الأساسية أن الأدوار تُطابق المسؤوليات، ليست الأشخاص. عندما تكون المسؤوليات مستقرة، تبقى الأدوار مستقرة ويظل النموذج سهل الشرح.

RBAC مناسب عندما:

• هيكل المؤسسة واضح (فرق، قادة، مسؤولون)
• معظم قرارات الوصول هي "هل يمكنهم استخدام هذه الميزة؟"
• الحاجة إلى توظيف سريعة قابلة للتنبؤ (عيّن الدور X وأنتهي)
• المراجعات مهمة (من السهل سرد ما يمكن أن يفعله دور ما)

أين يبدأ RBAC بالتسبب بالمشاكل هو عندما تصبح الواقع فوضويًا. تجمع الأدوات الداخلية استثناءات: وكيل دعم يمكنه رد الأموال، مستخدم مالي يجب أن يرى منطقة واحدة فقط، متعاقد يمكنه رؤية التذاكر لكن ليس البيانات الحساسة للعميل. إذا حللت كل استثناء بإنشاء دور جديد، تحصل على انفجار الأدوار.

إشارة عملية أن RBAC وحده يفشل: تبدأ في إضافة "أدوار خاصة" كل أسبوع.

ABAC بمصطلحات بسيطة (قواعد مبنية على السمات)

ABAC (التحكم في الوصول بحسب السمات) يقرر الوصول باستخدام قواعد، ليس فقط الألقاب الوظيفية. بدلًا من السؤال "ماذا يمكن لدور Finance فعله؟" يسأل ABAC: "معطى من هذا الشخص، وما هذا السجل، وما الذي يحدث الآن، هل نسمح؟"

السمات هي حقائق تسجلها بالفعل. قد تقول قاعدة:

• "عملاء الدعم يمكنهم عرض التذاكر في منطقتهم."
• "المديرون يمكنهم الموافقة على نفقات تحت 5,000 خلال ساعات العمل."

تعتمد معظم أنظمة ABAC على فئات سمات قليلة:

• سمات المستخدم: القسم، المنطقة، حالة المدير
• سمات البيانات: مالك السجل، أولوية التذكرة، حالة الفاتورة
• سمات السياق: وقت اليوم، نوع الجهاز، موقع الشبكة
• سمات الإجراء: عرض مقابل تحرير مقابل تصدير

مثال ملموس: يمكن لوكيل الدعم تحرير تذكرة فقط إذا (أ) أولوية التذكرة ليست حرجة، (ب) التذكرة مخصصة له، و(ج) منطقة العميل تطابق منطقته. تتجنب هنا إنشاء أدوار منفصلة مثل Support - EU - Noncritical و Support - US - Noncritical.

المقايضة هي أن ABAC يمكن أن يصبح صعب الفهم إذا استمرت الحالات الخاصة في التراكم. بعد بضعة أشهر، يتوقف الناس عن القدرة على الإجابة على أسئلة أساسية مثل "من يمكنه تصدير الفواتير؟" دون قراءة سلسلة طويلة من الشروط.

عادةً ما تكون عادة جيدة في ABAC هي الحفاظ على قواعد قليلة، متناسقة، ومُسماة بلغة طبيعية.

الوصول على مستوى السجل: حيث تحدث معظم الأخطاء

تتعامل الكثير من الفرق مع الصلاحيات باعتبارها "هل يمكنك فتح هذه الشاشة؟" هذه مجرد الطبقة الأولى. الوصول على مستوى السجل يجيب سؤالًا مختلفًا: حتى لو يمكنك فتح الشاشة، أي الصفوف مسموح لك برؤيتها أو تغييرها؟

قد يصل وكيل دعم ومحلل مالي إلى صفحة العملاء. إذا توقفت عند مستوى الشاشة، فأنت تخاطر بإظهار كل شيء للجميع. تضيق قواعد على مستوى السجل ما البيانات التي تُحمّل داخل تلك الصفحة.

قواعد شائعة على مستوى السجل تشمل:

• فقط عملائكَ (assigned_owner_id = current_user.id)
• فقط منطقتك (customer.region IN current_user.allowed_regions)
• فقط مركز التكلفة الخاص بك (invoice.cost_center_id IN current_user.cost_centers)
• فقط تذاكر فريقك (ticket.team_id = current_user.team_id)
• فقط السجلات التي أنشأتها (created_by = current_user.id)

يجب فرض الوصول على مستوى السجل حيث تُسترجع البيانات وتُغيّر، ليس فقط في واجهة المستخدم. في الممارسة، يعني ذلك طبقة الاستعلام، ونقاط نهاية الـ API، ومنطق الأعمال.

نمط فشل نموذجي هو "صفحة مقفلة، API مفتوح." يتم إخفاء زر لغير المديرين، لكن نقطة النهاية لا تزال تُرجع كل السجلات. أي شخص لديه وصول للتطبيق قد يعيد استخدام الطلب أو يغيّر فلتر ليشغّل هذه المكالمة.

تحقق من سليم نموذجك عبر بعض الأسئلة:

• إذا استدعى المستخدم النقطة النهاية مباشرة، هل لا يزال يحصل على السجلات المسموح بها فقط؟
• هل تطبّق قواعد واحدة لقوائم النتائج، التفاصيل، التصدير، والعدّ؟
• هل تُفحص عمليات الإنشاء والتحديث والحذف بشكل منفصل (ليس القراءة فقط)؟
• هل يتجاوز المديرون القواعد عن قصد، أم عن طريق الخطأ؟

أذونات الشاشة تقرر من يدخل الغرفة. الوصول على مستوى السجل يقرر أي الأدراج يمكنهم فتحها بعد دخولهم.

أمثلة واقعية: الدعم، المالية، والمديرون

الهدف ليس "أمان مثالي". الهدف صلاحيات يمكن للناس فهمها اليوم، ويمكنك تغييرها لاحقًا دون كسر سير العمل.

فريق الدعم

عادةً ما يحتاج الدعم إلى قواعد على مستوى السجل، لأن "كل التذاكر" نادرًا ما تكون صحيحة.

نموذج بسيط: يمكن للوكلاء فتح وتحديث التذاكر المخصصة لهم، بالإضافة إلى أي شيء في طابورهم. يمكن لقادة الفريق إعادة تعيين التذاكر والتدخل في التصعيدات. غالبًا ما يحتاج المديرون إلى لوحات مراقبة بدون القدرة على تحرير كل تذكرة.

الإجراءات الجماعية والتصدير هي التحوير الشائع. تسمح فرق كثيرة بالإغلاق الجماعي مع تقييد إعادة التعيين الجماعي وتقصر التصديرات على القادة والمديرين مع تسجيل النشاط.

فريق المالية

وصول المالية يدور حول خطوات الموافقة ومسار تدقيق واضح.

إعداد شائع: موظف الحسابات الدائنة يمكنه إنشاء الفواتير وحفظ المسودات، لكن لا يمكنه الموافقة أو الدفع. يمكن للمدقق المالي الموافقة وإصدار المدفوعات. يجب أن يكون المراجعون للقراءة فقط، بما في ذلك المرفقات، دون القدرة على تغيير بيانات المورد.

قاعدة واقعية: "يمكن لموظفي الحسابات تعديل المسودات التي أنشأوها؛ بمجرد الإرسال، لا يمكن إلا للمراقبين تغييرها." هذه صلاحية على مستوى السجل (حالة + مالك) وغالبًا ما تناسب ABAC أفضل من إنشاء المزيد من الأدوار.

المديرون

معظم المديرين يحتاجون رؤية واسعة لكن صلاحية تعديل محدودة.

نمط عملي: يمكن للمديرين عرض معظم البيانات التشغيلية، لكن يمكنهم تعديل السجلات المملوكة لفريقهم أو المرتبطة بتقاريرهم المباشرة فقط (طلبات إجازة، أهداف، ملاحظات أداء). سمات مثل team_id وmanager_id وحالة التوظيف أوضح من إنشاء دور منفصل لكل قسم.

عبر هذه المجموعات، عادةً ما تحتاج إلى:

• الدعم: رؤية حسب التعيين/الطابور، تصدير محدود بعناية، إعادة تعيين محكومة
• المالية: قواعد مبنية على الحالة (مسودة مقابل مُرسلة مقابل معتمدة)، موافقات صارمة، وصول للقراءة آمن للتدقيق
• المديرون: مشاهدة واسعة، تحرير ضيق (سجلات فريقهم أو تقاريرهم المباشرة)

مصفوفة القرار: الأدوار مقابل السمات مقابل قواعد مستوى السجل

بدلًا من الجدل "أيهما أفضل"، اسأل أي أجزاء من مشكلة الوصول تناسب كل نموذج. تنتهي معظم الفرق بنهج هجين: أدوار للعرض العام، وسمات للحالات الاستثنائية، ومرشحات على مستوى السجل لـ "أشيائي فقط."

عامل منطق الصلاحيات كفاتورة شهرية. كل دور أو قاعدة أو استثناء إضافي يكلف وقتًا للاختبار والشرح وتصحيح الأخطاء. أنفق أقل قدر يغطي السيناريوهات الواقعية اليوم.

افتراض عملي:

• ابدأ بـ RBAC للمسارات العامة (Support, Finance, Manager).
• أضف ABAC للحالات المتكررة (المنطقة، الأقدمية، تصنيف العميل).
• أضف قواعد على مستوى السجل عندما يجب أن يرى المستخدم "عناصره" فقط، وليس الجدول بأكمله.

خطوة بخطوة: صمم الصلاحيات قبل بناء الشاشات

إن قررت الصلاحيات بعد إنجاز واجهة المستخدم، عادةً ما تنتهي بعدد كبير من الأدوار أو كومة من الاستثناءات. خطة بسيطة تمنع إعادة البناء المستمرة.

1) ابدأ بالأفعال، لا بالشاشات

اكتب ما يفعله الناس فعليًا في كل سير عمل:

• عرض (قراءة)
• إنشاء
• تحرير
• موافقة
• تصدير
• حذف

في مسار ردود الأموال، الموافقة ليست نفس فعل التحرير. هذا التمييز الواحد غالبًا ما يقرر هل تحتاج قاعدة صارمة أم مجرد دور.

2) عرّف أدوارًا تطابق المسميات الوظيفية

اختر أدوارًا يفهمها الناس دون اجتماع: Support Agent, Support Lead, Finance Analyst, Finance Manager, Auditor, Admin. تجنّب أدوار مثل "Support Agent - Can edit VIP notes." تلك تتكاثر سريعًا.

3) أدرج السمات التي تخلق استثناءات حقيقية

أضف ABAC فقط حيث يبرر نفسه. السمات النموذجية: المنطقة، الفريق، تصنيف العميل، الملكية، والمبلغ.

إن حدث استثناء أقل من مرة في الشهر، فكّر في خطوة موافقة يدوية بدلاً من قاعدة إذن دائمة.

4) اكتب قواعد مستوى السجل كسياسات من جملة واحدة

الوصول على مستوى السجل هو المكان الذي تنهار فيه أغلب الأدوات الداخلية. اكتب قواعد يمكن أن تُعرض لمدير غير تقني:

"يمكن لوكلاء الدعم عرض التذاكر في منطقتهم."

"يمكن لمحللي المالية تعديل الفواتير التي أنشأوها حتى تُعتمد."

"يمكن للمديرين الموافقة على ردود الأموال فوق 500 فقط لفريقهم."

إن لم تستطع التعبير عن قاعدة بجملة واحدة، فربما تحتاج العملية إلى توضيح.

5) اختبر مع خمسة أشخاص حقيقيين قبل البناء

مرّ عبر سيناريوهات حقيقية:

• وكيل دعم يتعامل مع عميل VIP
• محلل مالي يصحح فاتورة
• مدير يوافق على رد كبير
• مسؤول نظام يقوم بصيانة
• مدقّق يحتاج رؤية التاريخ دون تغيير

صلّح الالتباس هنا، قبل أن يتحول إلى متاهة صلاحيات.

الفخاخ الشائعة (وكيف تتجنبها)

معظم فشل الصلاحيات لا يسببه اختيار RBAC أو ABAC. يحدث عندما تتكدس الاستثناءات الصغيرة حتى لا يستطيع أحد شرح من يمكنه فعل ماذا ولماذا.

انفجار الأدوار يبدأ عادة بـ "قائد الدعم يحتاج زرًا إضافيًا"، ثم يكبر إلى 25 دورًا تختلف بإذن واحد. أبقِ الأدوار عريضة (مطابقة للوظائف) واستخدم عددًا قليلًا من الاستثناءات القائمة على القواعد للحالات المتكررة.

منطق السمات غير القابل للقراءة هو نسخة ABAC من نفس المشكلة. إن كانت لديك شروط مثل "department == X AND region != Y" مبعثرة في كل مكان، تتحول المراجعات إلى عمل تخميني. استخدم سياسات مسماة حتى يمكنك القول "سياسة الموافقة على الرد" بدلًا من فك معادلة.

التصديرات، والتقارير، والإجراءات الجماعية هي الأماكن التي تحدث فيها التسريبات. تُقفل عروض السجل، ثم تُنسى أن Export CSV أو التحديث الجماعي يتجاوزان نفس الفحوص. عامل كل مسار غير-شاشي كإجراء أولي وله فحص صلاحياته الخاص.

فخاخ تستحق المراقبة:

• دور جديد لكل استثناء
• قواعد سمات يصعب قراءتها أو غير مسماة
• التصديرات وتقارير المقرر والتحديثات الجماعية تتخطى الفحوص
• أدوات مختلفة تجيب عن نفس سؤال الوصول بشكل مختلف
• قواعد مستوى السجل مطبّقة في مكان وغير مطبّقة في آخر

الإصلاح الأكثر أمانًا هو مصدر واحد للحقيقة للأدوار والسمات وقواعد مستوى السجل، مطبّق باستمرار في منطق الـ backend.

قائمة تحقق سريعة قبل الإصدار

إذا كان نموذجك صعب الشرح، فسيكون أصعب عند التصحيح عندما يقول أحدهم: "يجب أن أستطيع رؤية هذا العميل" أو "لماذا يمكنهم تصدير هذه القائمة؟"

خمس فحوصات تلتقط معظم المفاجآت:

• هل يستطيع مستخدم حقيقي وصف وصوله في جملة واحدة (مثال: "أنا Support، المنطقة = EU، أستطيع عرض تذاكر من منطقتي لكن لا أستطيع التصدير")؟ إن لم يكن، فالقواعد مشتتة على الأرجح.
• هل لديك إجابة صريحة عن "من يمكنه التصدير؟" و"من يمكنه الموافقة؟" عامل التصدير والموافقة كأفعال عالية المخاطر.
• هل تُطبّق قواعد مستوى السجل في كل مكان تُسترجع فيه البيانات (نقاط نهاية الـ API، التقارير، مهام الخلفية)، وليس فقط عبر إخفاء الأزرار؟
• هل الافتراض الافتراضي آمن للأفعال الحساسة (المنع بالافتراض)؟ لا يجب أن ترث الأدوار والسمات والشاشات الجديدة صلاحيات قوية بالخطأ.
• هل يمكنك الإجابة على "من يمكنه رؤية هذا السجل ولماذا؟" في أقل من دقيقة باستخدام مصدر واحد للحقيقة (الدور، السمات، وحقول الملكية/الحالة)؟

مثال: قد تطالع المالية كل الفواتير، لكن فقط الموافقون يستطيعون الموافقة، وفقط المديرون يمكنهم تصدير قائمة الموردين كاملة. يمكن للدعم عرض التذاكر، لكن فقط فريق مالك التذكرة يمكنه رؤية الملاحظات الداخلية.

إجراء تغييرات في الصلاحيات دون كسر كل شيء

تتغير الصلاحيات لأسباب مملة: مدير جديد يبدأ، المالية تنقسم إلى AP وAR، أو تستحوذ الشركة على فريق آخر. خطّط للتغيير بحيث تكون التحديثات صغيرة، قابلة للعكس، وسهلة المراجعة.

تجنّب ربط الوصول بدور "سوبر" واحد كبير. أضف وصولًا جديدًا كدور جديد، سمة جديدة، أو قاعدة سجل ضيقة، ثم اختبرها مقابل المهام الحقيقية.

أضف الوصول دون إعادة تصميم كل شيء

عندما يظهر قسم جديد، احتفظ بالأدوار الأساسية مستقرة وأضف طبقات حولها.

• احتفظ بالأدوار الأساسية قليلة (Support, Finance, Manager)، ثم أضف امتدادات صغيرة (Refunds, Export, Approvals).
• فضّل السمات لتغييرات التنظيم (team, region, cost center) حتى لا تتطلب المجموعات الجديدة أدوارًا جديدة.
• استخدم قواعد مستوى السجل للملكية والتعيين (ticket.assignee_id, invoice.cost_center).
• أضف خطوة موافقة للإجراءات الحساسة (مدفوعات، شطب).
• عامل التصدير كإذن مستقل في كل مكان تقريبًا.

لا ينبغي أن يتطلب الوصول المؤقت تغيير دور دائم. للتغطية أو الاستجابة للحوادث، استخدم منحًا محددة بالوقت: "موافق مالي لـ 48 ساعة"، مع تاريخ انتهاء وسبب مطلوب.

إيقاع التدقيق وسجلات جاهزة للتحقيق

استخدم وتيرة مراجعة بسيطة: شهريًا للصلاحيات عالية المخاطر (المال، التصدير)، ربع سنوي للبقية، وبعد أي إعادة تنظيم أو دمج.

سجّل ما يكفي للإجابة على من فعل ماذا ولأي سجل ولماذا سُمح به:

• من عرض أو حرر أو وافق أو صدّر
• متى حدث (ومن أين إن التقطت هذه المعلومة)
• أي سجل تم لمسـه (المعرفات، النوع، قبل/بعد للتعديلات)
• لماذا سُمح (الدور، السمات، قاعدة السجل، منحة مؤقتة)
• من منح الوصول (ومتى ينتهي)

الخطوات التالية: نفّذ نموذج يمكنك الحفاظ عليه

ابدأ بنموذج صلاحيات صغير وممل. هذا ما يصمد بعد ستة أشهر من التغيير.

افتراض جيد افتراضي هو RBAC بسيط: مجموعة من الأدوار تطابق الوظائف الحقيقية (Support Agent, Support Lead, Finance, Manager, Admin). استخدم هذه الأدوار للتحكم بالأبواب الكبيرة مثل الشاشات المتاحة، الأفعال المتاحة، وسير العمل الذي يمكن بدءه.

ثم أضف ABAC فقط عندما تستمر في رؤية نفس الاستثناءات الحقيقية. إن كان السبب الوحيد لرغبتك في ABAC هو "قد يكون مفيدًا لاحقًا" فانتظر. يتألق ABAC عندما تكون الشروط مهمة (حدود المبالغ، قيود المنطقة، الملكية، الحالة)، لكنه يحتاج اختبارًا دقيقًا وملكية واضحة.

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

إذا أردت طريقة سريعة لتجريب هذا في أداة داخلية حقيقية، منصة no-code مثل AppMaster (appmaster.io) يمكن أن تساعدك على نمذجة الأدوار وحقول البيانات مثل owner/team/status، وتطبيق سير أعمال محفوظة في الـ backend مبكرًا، قبل أن تُحكم قرارات واجهة المستخدم افتراضات خطرة.