صلاحيات المستخدمين وسجل التدقيق: أساس الثقة في أي نظام إداري

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

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

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

الأدوار أولاً، ثم أقل صلاحية لازمة

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

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

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

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

نطاق البيانات: الفرع والمستودع

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

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

فصل المهام والعمليات الحساسة

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

• من يُنشئ أمر الشراء لا يعتمده، ومن يعتمده لا يستلم البضاعة.
• من يسجّل فاتورة المورّد لا يصرف دفعتها.
• من يضيف المستخدمين لا يمنح نفسه صلاحيات إضافية.

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

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

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

سجل التدقيق: من فعل ماذا، ومتى

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

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

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

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

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

الثقة في أرقام النظام لا تأتي من منع كل خطأ، بل من القدرة على معرفة أين وقع وكيف صُحّح.

مراجعة الصلاحيات حين يتغير الناس

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

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

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

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

قائمة تحقق قبل الإطلاق

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

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

إذا كان نظامك الحالي يمنح الجميع كل شيء، أو كنت تخطط لنظام جديد، يمكنك أن تناقش حالتك مع فريق ITS لنحدد معاً الأدوار والعمليات الحساسة قبل كتابة الكود.