صلاحيات الطالب والمدرس والإداري في edtech (RBAC)

ماذا ستخرج به من هذا المقال؟

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

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

التحكم بالوصول القائم على الأدوار (Role-Based Access Control) هو الإجابة القياسية لهذه المشكلة: بدل إسناد الصلاحيات لكل مستخدم على حدة، تُسنَد الصلاحيات إلى أدوار ويُمنح المستخدم دوراً واحداً أو أكثر. في هذا المقال نشرح نموذجاً آمناً بثلاثة أدوار أساسية، ونطاقات تحصر كل إجراء ضمن حدود واضحة، وسجلاً للأثر يكشف كل تعديل حساس، مع أمثلة عملية تُنفَّذ مباشرة في نظامك.

لماذا الصلاحيات الفوضوية خطيرة؟

«الفوضوية» هنا لا تعني غياب نظام الصلاحيات فقط، بل أي توزيع عشوائي للصلاحيات دون قاعدة موحدة: كل موظف يحصل على صلاحيات أكبر بصمت أمام طلب عاجل «جرب وأنت في الطريق»، والصلاحيات تتراكم بلا مراجعة. النتيجة أعراض متشابهة في كل منصة، ولكل عرض ثمنه:

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


• مدرس يعدّل مقرراً لا يدرّسه: صلاحية العامة في التعديل تسمح لأي مدرس مساعد أن يعبث بمحتوى زميله، وتتحول العلاقة المهنية إلى نزاع لا يمكن للنظام فضّه.


• إداري يعدّل سجلات بلا أثر: صلاحية كاملة بدون سجل تجعل تعديلاً واحداً حرباً بين الإدارات؛ «من غيّر هذه الدرجة؟» سؤال يبقى بلا إجابة.


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

المفاهيم الأساسية

• الدور (Role): مجموعة صلاحيات تُمنح كوحدة واحدة: طالب، مدرس، إداري، وقد تُضاف أدوار مساعدة لاحقاً عند ثبوت الحاجة.


• الصلاحية (Permission): إجراء محدد مقابل مورد محدد: «قراءة درجة»، «تعديل مقرر»، «إنشاء مستخدم»، وليست عنواناً فضفاضاً يصعب تدقيقه.


• المورد (Resource): الشيء الذي تُطبَّق عليه الصلاحية: صفحة، مقرر، سجل طالب، تقرير مالي؛ فبدون تعريف المورد تصبح الصلاحية بلا حدود.


• النطاق (Scope): الحدود التي تُقيّد الصلاحية: هل تنطبق على صفّي أنا فقط أم كل الصفوف؟ النطاق هو ما يفصل RBAC السليم عن وهمه، وأغلب الحوادث تأتي من تغاضيه.


• التوريث (Inheritance): دور فرعي يرث صلاحيات الدور الأب ويضيف عليها أو يقيّدها، بدل نسخ الصلاحيات يدوياً في كل دور جديد فيختل التوازن.


• الأثر (Audit): سجل لكل فعل حساس: من فعل، ماذا، على أي مورد، ومتى؛ يُكتب ولا يُعدَّل ولا يُحذف، ويكون مرجعاً عند أي نزاع أو فحص امتثال.

رحلة الصلاحية

رحلة كل طلب وصول في النظام سلسلة قرارات قصيرة لا فحصاً واحداً، وكل قرار فيها يمثل نقطة تحقق مستقلة:

مستخدم -> له دور -> يمنح صلاحيات -> تقيد بنطاق -> كل فعل يُسجَّل.

الفكرة أن الاختبار لا يتوقف عند «هل يملك الصلاحية؟»، بل يتجاوزها إلى «هل النطاق يسمح بهذا المورد بعينه؟»، ثم يُدوَّن قرار النظام في السجل ليصبح قابلاً للتدقيق في أي وقت.

خطوة بخطوة: نموذج آمن

الخطوة 1: حدّد الأدوار الثلاثة بوضوح

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

student, instructor, admin

النتيجة: فهم بسيط لمن ماذا يفعل، وصيانة أسهل للصلاحيات لاحقاً.

الخطوة 2: عرّف الصلاحيات على الموارد

لا توجد صلاحية عامة مبهمة؛ كل صلاحية تصف إجراءً ومورداً معاً. view_own_grade تعني «قراءة درجتك أنت»، وedit_own_course تعني «تعديل مقرر أدرّسه أنا»، وmanage_users تعني «إدارة حسابات المستخدمين». عرّف الصلاحيات بأزواج (فعل، مورد) بأسماء مستقرة، فتصبح القائمة قابلة للفحص والمراجعة عند أي تهديد.

view_own_grade, edit_own_course, manage_users

النتيجة: لا صلاحية عامة مبهمة يصعب تدقيقها أو إثبات أثرها.

الخطوة 3: قيّد بالنطاق

النطاق هو الفرق بين وهم الأمان والأمان الفعلي؛ فالطالب يملك صلاحية «قراءة درجة» لكن ضمن نطاق «سجلي أنا»، والمدرس يملكها ضمن نطاق «المقررات التي أدرّسها أنا»، والإداري ضمن نطاق المؤسسة كلها. تنفيذياً النطاق جملة تصفية على المورد تُدمج في الاستعلام ذاته لا في طبقة واجهة يسهل تجاوزها:

instructor: view_grade WHERE course.instructor_id = me

النتيجة: لا رؤية لدرجات الغير حتى لو امتلك شخص صلاحية القراءة نفسها.

الخطوة 4: افصل إدارة المستخدمين

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

admin: manage_users, view_all

النتيجة: توازن صلاحيات واضح ورصد لمن فعل ماذا في حسابات الآخرين.

الخطوة 5: سجّل كل فعل حساس

صلاحية كاملة بلا سجل أثر أزمة معلنة لا حادثة محتملة. سجل الأثر يلتقط أربع حقائق على الأقل: الفاعل، الفعل، المورد، والتوقيت، ويُكتب قبل تنفيذ العملية أو معها. يُكتب الأثر ولا يقبل التعديل، ويُدقَّق عند أي نزاع أو فحص جودة أو طلب امتثال؛ الفعل الصحيح يُثبت، والفعل الخاطئ يُكتشف بوضوح.

audit: who, action, resource, at

النتيجة: حل نزاع سهل والتحقق من الفعل الخاطئ دون انتظار اعتراف أو تخمين.

الخطوة 6: اربط الصلاحية بحالة الحساب

الحساب المعطّل يجب أن يحمل صلاحياته إلى الصفر فوراً؛ وقاعدة «إذا كانت حالة الحساب معطلة فكل الصلاحيات غير فعّالة» تُنفَّذ في طبقة التحقق نفسها لا بالحذف اليدوي من قاعدة البيانات. أوقف أيضاً مفاتيح API والجلسات النشطة عند التعطيل، فقد تحمل الجلسة صلاحية صدرت قبل لحظات من قرار الإيقاف.

disabled user -> all permissions inactive

النتيجة: لا صلاحية معلّقة لمغادر، ولا جلسة مستمرة لحساب ملغى.

مثال عملي كامل: تسريب درجات

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

الحل الذي أوقف التسريب: فصل الأدوار الثلاثة بوضوح، وتحويل «عرض الدرجات» إلى صلاحية مقيدة بالنطاق (المدرس لكورساته فقط، الطالب لسجله فقط)، مع تفعيل سجل أثر لكل مشاهدة من المشاهدات الحساسة. النتيجة أن التسريب انتهى بالكامل؛ وتعثرت محاولة إعادة إنتاجه في أول طلب، إذ رُفض وصول الطالب إلى مورد لا يقع ضمن نطاقه وسُجّل الرفض في الأثر.

مقارنة: صلاحيات عامة مقابل RBAC

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

أخطاء شائعة

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

قائمة تحقق سريعة

• هل حُددت الأدوار الثلاثة بوضوح ووافق عليها الجميع؟


• هل كل صلاحية مقترنة بمورد محدد ونطاق واضح؟


• هل نطاق المدرس «كورساتي» والطالب «سجلي»؟


• هل إدارة المستخدمين حصرية على الإداري؟


• هل سجل الأثر يُكتب ولا يقبل التعديل؟


• هل تعطيل الحساب يُلغي الصلاحيات والجلسات ومفاتيح API؟


• هل اختُبر سيناريو «طالب يصل إلى مورد مدرس» وكانت النتيجة رفضاً؟


• هل روجعت الأدوار المخصصة القديمة وحُذف ما لم يثبت تكراره؟


• هل وُثّقت خطة استعادة صلاحية لموظف عاد بعد فترة؟


• هل الاختبارات تُعاد مع كل تغيير في الأدوار أو النطاقات؟

الأسئلة الشائعة

كم دوراً أحتاج؟

ثلاثة أدوار أساسية تكفي لمعظم المنصات التعليمية: طالب ومدرس وإداري؛ وهو العدد الذي يغطي 90% من السلوكيات. أضف دوراً رابعاً أو خامساً فقط حين يثبت تكرر نمط معين، مثل «مدرس مساعد» أو «مسجل». كلما قلَّت الأدوار، قلَّت تركيبات الصلاحيات التي يجب اختبارها وصيانتها، وسهّل نموذجك تدقيقه.

ماذا إن احتاج استثناء؟

السؤال الحقيقي ليس «هل أمنحه أكثر؟» بل «هل المشكلة في صلاحية تفتقدها الدور، أم في نطاق ضيق جداً؟». أجب عنه عبر نطاق محدود يحصر المنحة ضمن شروط، لا عبر منح صلاحية كلية لشخص واحد. الاستثناء الذي يُمرَّر على قاعدة «دعه يصل لكل شيء» يصبح ثغرة دائمة لا سابقة ذكية.

كيف أختبر النموذج؟

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

الخلاصة

الخطوة التالية

النموذج جاهز والطلاب محميون بصلاحيات واضحة قابلة للتدقيق. لإدارة الحضور والامتحانات والدفع، راجع "الحضور والامتحانات والدفعات التعليمية".

كيف تستخدم هذا المقال في عمل حقيقي؟

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

flowchart LR

    A["هدف تعليمي"]

    B["خطة الدروس"]

    C["شرح وتطبيق"]

    D["تقييم وتغذية راجعة"]

    E["تحسين المنهج"]

    A --> B

    B --> C

    C --> D

    D --> E