لتحديد صلاحيات نظام داخلي، لا تبدأ بقائمة «مدير، موظف، مشرف» وحدها. اكتب من يستطيع تنفيذ أي إجراء، على أي سجل، وفي أي حالة، وتحت أي شرط. ثم حدد ما يحدث عند الرفض والتعديل وغياب المعتمد. بهذه الطريقة يصبح مسار الموافقة قراراً تشغيلياً يمكن اختباره، بدلاً من مجموعة أزرار تبدو مناسبة في العرض التجريبي.
المقصود هنا بوابة لإجراء عمل متفق عليه، وليس نظاماً شاملاً لكل الموارد أو شهادة أمان. يمكن أن يغطي نطاق أنظمة إدارة العمليات الداخلية طلبات محددة وأدوارها وبياناتها، مع استثناءات معلنة لما يبقى خارج النظام.
افصل بين الدور وحدود السجل
قد يستطيع مشرفان اعتماد النوع نفسه من الطلبات، لكن كل واحد مسؤول عن فرع مختلف. وقد يراجع الموظف طلباته دون أن يراجع طلبات زملائه. لذلك تحتاج مصفوفة تجمع الدور والإجراء ونطاق البيانات، لا جدولاً يضع علامة صح أمام «عرض» و«تعديل» فقط.
فرّق كذلك بين دخول المستخدم للنظام وبين السماح له بالتصرف. توصي إرشادات التفويض لدى OWASP بالمنع الافتراضي والتحقق من الصلاحيات في كل طلب. عملياً، إخفاء زر الاعتماد لا يكفي إذا ظل الإجراء ممكناً عبر رابط مباشر أو واجهة برمجية. هذه نقطة قبول وظيفية وأمنية محددة، وليست بديلاً عن مراجعة أمنية متخصصة عند الحاجة.
اكتب قواعد القراءة والتصدير والمرفقات أيضاً. قد تمنع الشاشة تعديل طلب خارج الفرع، ثم تسمح بتنزيل تقرير يحتوي بيانات الفروع كلها. يجب أن تتبع مخرجات النظام حدوداً متسقة مع سياسة العمل المعتمدة.
ارسم الحالات قبل رسم الشاشات
استخدم أسماء حالات لا تحتمل تفسيرين: مسودة، مقدم، يحتاج استكمالاً، معتمد، مرفوض، ملغى. لكل انتقال حدد الفاعل والمدخلات المطلوبة والنتيجة ومن يتلقى إشعاراً. «قيد المعالجة» وحدها قد تخفي خمس مسؤوليات مختلفة، فلا تعرف من يؤخر الطلب.
اسأل عما يحدث بعد تعديل قيمة مؤثرة. هل يبقى الاعتماد السابق سارياً إذا تغيرت الكمية أو الجهة المستفيدة؟ وإذا أُعيد الطلب للاستكمال، هل يرجع إلى المراجع نفسه أم يبدأ المسار من جديد؟ هذه قواعد عمل تحتاج قرار صاحب العملية، ولا ينبغي للمطور اختيارها بناء على الأسهل تقنياً.
من المفيد أن يسجل اكتشاف المنتج وتوثيق المتطلبات القاعدة ومثالها وحالة مضادة لها. عبارة «المشرف يعتمد الطلب» أقل دقة من «المشرف الحالي للفرع يعتمد طلباً مقدماً من شخص آخر، ضمن الحد المعتمد له، بعد اكتمال الحقول المطلوبة».
مثال افتراضي: طلب مواد لفرع
لنفترض أن منشأة تريد تنظيم طلبات مواد تشغيلية. يجهّز الموظف الطلب، ويراجعه منسق الفرع، ثم يعتمد المشرف طلباً حتى قيمة افتراضية مقدارها 5,000 ريال، وما يزيد عنها يحال إلى مسؤول آخر. هذا حد تعليمي يختاره المثال، وليس توصية مالية أو سياسة مناسبة لكل منشأة.
يقدم موظف طلباً بقيمة 4,800 ريال. يتحقق المنسق من البيانات دون أن يمنح اعتماداً نهائياً. يعتمد المشرف الطلب، ثم يرفع الموظف الكمية فتصل القيمة إلى 5,400 ريال. في القاعدة المقترحة لهذا المثال، يتوقف الاعتماد السابق ويعاد الطلب إلى المسار الأعلى، ولا يتعامل النظام مع التعديل كتصحيح شكلي.
خلال إجازة المشرف، يعيّن صاحب الصلاحية بديلاً لمدة محددة ولمجال الفرع فقط. لا تُشارك كلمة مرور المشرف، ولا يحصل البديل تلقائياً على صلاحية تغيير حدود الاعتماد. يسجل النظام منفذ القرار وصفته وقت التنفيذ وتاريخه وسببه عند الاستثناء. وتبقى الموافقة المؤثرة قابلة للمراجعة بعد انتهاء التفويض.
اختبر الرفض بقدر اختبار النجاح
اطلب من فريق اختبار وضمان جودة البرمجيات حالات تثبت أن المستخدم الصحيح يستطيع إكمال العمل، وحالات تثبت أن مستخدماً آخر لا يستطيع تجاوز الحدود. تشمل قائمة القبول:
- الموظف لا يعتمد طلبه بنفسه عندما تمنع السياسة ذلك.
- المشرف لا يقرأ طلب فرع آخر أو يصدر تفاصيله.
- تغيير البيانات المؤثرة يلغي الاعتماد وفق القاعدة المتفق عليها.
- انتهاء التفويض يمنع قرارات جديدة ولا يمحو تاريخ القرارات السابقة.
- المحاولة المتزامنة من معتمدين لا تنتج نتيجتين متناقضتين.
- الرفض يوضح الخطوة التالية دون كشف تفاصيل غير مسموحة.
عند وجود ربط خارجي، يشمل تطوير وربط واجهات برمجة التطبيقات صلاحيات حساب الخدمة وحدود الحالات التي يحق له تغييرها. لا تجعل التكامل يتصرف كمدير شامل لمجرد أن ذلك يسهل الاختبار الأول.
الاستثناءات التي يجب ألا تتحول إلى باب خلفي
قد تحتاج العملية تصحيح قرار أو معالجة طلب عاجل. اكتب من يطلب الاستثناء ومن يوافق عليه وما البيانات التي لا يمكن تغييرها بعد التنفيذ. لا تضف «صلاحية شاملة مؤقتة» بلا نهاية أو سجل، ولا تستخدم حساباً مشتركاً لإخفاء تعقيد الأدوار.
قبل التشغيل، جرّب السيناريو مع أصحاب الأدوار الفعليين ببيانات اختبار مأذون بها. اطلب من كل شخص تفسير سبب ظهور طلب لديه وسبب غياب إجراء آخر. إذا كان الشرح يحتاج تدخلاً تقنياً دائماً، فربما لا تزال القاعدة أو الواجهة غير واضحة. عيّن أيضاً مسؤولاً لمراجعة الصلاحيات عندما ينتقل موظف أو تتغير مسؤولية فرع.
أسئلة شائعة
هل يمكن أن يجمع شخص أكثر من دور؟
نعم إذا أجازت السياسة ذلك، لكن اختبر التعارض بين الدورين. لا يعني الجمع السماح باعتماد الطلب الشخصي أو تجاوز الفصل المطلوب بين المراجعة والاعتماد.
هل الصلاحيات على مستوى الشاشة كافية؟
غالباً تحتاج قيوداً على السجل والإجراء والتصدير أيضاً. حدّد النطاق المطلوب من واقع البيانات، ثم تحقق من تطبيقه خارج الواجهة المرئية.
ماذا لو غاب جميع المعتمدين؟
يجب وجود مسار تصعيد أو بديل معتمد مسبقاً. غياب صاحب القرار لا يمنح النظام إذناً بالموافقة تلقائياً أو للفريق التقني باختيار البديل.
هل سجل الموافقات يثبت امتثالاً قانونياً؟
هو دليل تشغيلي ضمن نطاقه، وليس شهادة امتثال. المتطلبات القانونية أو التنظيمية الخاصة تحتاج مراجعة مؤهلة وتحديداً مستقلاً للأدلة والاحتفاظ بها.
ابدأ بمسار موافقة واحد، ودوّن الحالات والحدود والاستثناءات قبل طلب بناء الشاشات. هذا يجعل عرض العمل والاختبار واستلام النظام أوضح لجميع الأطراف.
المرجع الفني
- OWASP: إرشادات التفويض والصلاحيات، روجعت في 26 أكتوبر 2026. حدود الاعتماد والتفويض في المثال افتراضية.