من يستطيع فعل ماذا؟ التحكم في الصلاحيات حسب الأدوار وسجلات التدقيق لفريق ينمو

تخيّل صاحبة متجر تجزئة بثلاثة فروع في صباح يوم الاثنين. تفتح تقرير المرتجعات فتجد أن الفرع الثاني نفّذ 41 عملية استرداد يوم الأحد بقيمة إجمالية 2,870 دولارًا. ثمانٍ وثلاثون منها بين 50 و300 دولار، أي في النطاق الذي كان يجب أن يوافق عليه شخص ثانٍ. وكلها صدرت من حساب الكاشير نفسه، ووافق عليها الحساب نفسه.

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

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

كيف تتشتت الصلاحيات مع نمو الفريق

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

• تراكم الصلاحيات. ينتقل الموظف إلى عمل آخر ويحتفظ بصلاحياته القديمة، لأن الإضافة تستغرق دقيقة، أما السحب فلا يقع على عاتق أحد.
• الحسابات المنسوخة. يُعدّ الموظف الجديد «مثل سلمى»، بكل ما مُنحته سلمى لمشروع واحد عام 2024.
• الحسابات المشتركة. حساب واحد للصندوق طوال الوردية يعني أن السجل يذكر «till» بدل اسم شخص.
• صلاحيات يتيمة. حساب موظف سابق، أو مفتاح API أنشأه، ما زال يعمل بعد شهور.

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

الأدوار والأذونات والنطاق: ثلاثة أشياء مختلفة

يبدو التحكم في الوصول القائم على الأدوار مجردًا إلى أن تفصله إلى أجزائه. الإذن فعل واحد على عنصر واحد: refund.issue وrefund.approve وstock.adjust وcustomer.export. الدور حزمة مسمّاة من الأذونات تطابق وظيفة: كاشير، مشرف وردية، محاسب. والنطاق يحدد أين يسري الدور: فرع واحد، أو مستودع واحد، أو كل مكان.

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

أقل صلاحية ممكنة عمليًا

يعني مبدأ أقل صلاحية (least privilege) أن يملك الشخص أصغر مجموعة أذونات تتيح له أداء عمله اليوم. وقد صاغه المعيار NIST SP 800-53 في الضابط AC-6: يفرض النظام أضيق مجموعة حقوق لازمة للمهام المحددة. وفي نظام تجزئة يتحول ذلك إلى ثلاث عادات.

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

فصل المهام: أزواج لا تجتمع

أقل صلاحية تحدّ مما يستطيع الشخص فعله. أما فصل المهام (segregation of duties) فيحدّ مما يستطيع فعله وحده. يصفه NIST AC-5 بأنه توزيع الوظائف على أشخاص مختلفين بحيث يتطلب إساءة استخدام الصلاحية تواطؤًا. والطريقة بسيطة: اكتب قائمة بأزواج المهام التي قد يتسبب جمعها في يد شخص واحد في خسارة أو إخفائها، ثم اجعل النظام يرفض هذا الجمع.

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

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

الإجراءات الحساسة تحتاج إلى بوابة، لا إلى تسجيل دخول فقط

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

يستخدم المخطط التالي حدودًا توضيحية. اختر حدودك بحسب كلفة الخطأ الواحد في نشاطك.

ثلاث تفاصيل في هذا المخطط أهم مما تبدو.

1. فحص الإذن يشمل النطاق. لا يكفي «يملك refund.issue». السؤال هو «هل يملك refund.issue في الفرع الثاني».
2. يُقارَن المعتمِد بالطالب ولا يكفي فحص الإذن وحده. لا يستطيع مشرف الوردية اعتماد استرداد أصدره بنفسه.
3. الرفض يُسجَّل. كاشير حاول استرداد 400 دولار ورُفض أربع مرات في أسبوع، هذه معلومة. وإن سجّلت النجاحات فقط ضاعت.

وللمستوى الأعلى، وهو هنا ما فوق 300 دولار، اشترط معتمِدَين، مثل مدير الفرع وشخص من المالية. أبقِ المستويات قليلة. ثلاثة مستويات يسهل شرحها عند الصندوق، وسبعة يتحايل عليها الناس.

قالب أدوار لتاجر تجزئة بثلاثة فروع

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

الإذن	كاشير	مشرف وردية	مدير فرع	أمين مخزن	محاسب	المالك
البيع عند الصندوق	فرعه	فرعه	فرعه	لا	لا	الكل
إصدار استرداد حتى 50 دولارًا	فرعه	فرعه	فرعه	لا	لا	الكل
اعتماد استرداد من 50 إلى 300 دولار	لا	فرعه	فرعه	لا	لا	الكل
اعتماد استرداد فوق 300 دولار	لا	لا	فرعه (الأول من اثنين)	لا	المعتمِد الثاني	الكل
تجاوز السعر	لا	طلب	فرعه، ضمن نسبة محددة	لا	لا	الكل
تسوية المخزون	لا	لا	لا	فرعه	لا	الكل
اعتماد الجرد	لا	لا	فرعه	لا	نعم	الكل
إنشاء مورّد	لا	لا	لا	لا	لا	الكل
الدفع للمورّد	لا	لا	لا	لا	نعم	لا
تصدير قائمة العملاء	لا	لا	لا	لا	لا	الكل
إدارة المستخدمين والأدوار	لا	لا	لا	لا	لا	الكل، بموافقة مالك ثانٍ

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

ما الذي يجب أن يحتويه سجل التدقيق

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

الحقل	قيمة مثال	سبب وجوده
معرّف السجل والوقت	R-20931، 09:41:07 UTC	للترتيب والبحث. خزّن بتوقيت UTC واعرض بالمحلي.
المنفِّذ	cashier-07 (مستخدم باسمه، وليس «till» أبدًا)	المساءلة
الإجراء والهدف	refund.issue على الطلب 48211	أي سجل تغيّر
المكان	الفرع 2، الصندوق 3، الجهاز وعنوان IP	النطاق وكشف المواقع غير المعتادة
المبلغ والسبب	$184.00، رمز السبب "damaged"	تحليل الأنماط بحسب السبب
قبل وبعد	دفعة محصّلة ثم مستردة؛ المخزون +1 في صندوق المرتجعات	إثبات الأثر
القاعدة المطبّقة	«استرداد 50 إلى 300 دولار: معتمِد واحد»	تُظهر السياسة السارية وقتها
المعتمِد والوقت	lead-02، 09:42:31 UTC	تثبت وجود شخص ثانٍ
النتيجة	مكتمل	نجاح أو رفض أو إلغاء
البصمة السابقة والحالية	7f3a…c91e	كشف العبث

كشف العبث والاحتفاظ والمراجعة

سجل يستطيع المدير تعديله لا يصلح دليلًا يُعتدّ به. وهناك إجراءان رخيصان يفيدان. الأول أن تجعل الجدول للإضافة فقط (append-only) بالنسبة للتطبيق: لا إذن بالتحديث أو الحذف، وتُكتب التصحيحات كأسطر جديدة. والثاني ربط السجلات بسلسلة. يخزّن كل سطر بصمة SHA-256 لمحتواه مضافًا إليها بصمة السطر السابق، فيؤدي تغيير سطر قديم إلى كسر كل البصمات بعده. وانسخ السجل كل ليلة إلى مساحة تخزين لا يستطيع التطبيق الكتابة عليها.

مدة الاحتفاظ تتوقف على القواعد المطبّقة عليك. كنقطة مرجعية، يطلب البند 10.5.1 من PCI DSS v4.0.1 الاحتفاظ بتاريخ سجلات التدقيق 12 شهرًا على الأقل، على أن تكون الأشهر الثلاثة الأخيرة متاحة فورًا للتحليل. راجع ما تفرضه قواعد الضرائب والرواتب والخصوصية فوق ذلك، ودوّن المدة.

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

الموظفون الجدد والمنتقلون والمغادرون

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

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

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

مراجعة الصلاحيات الربع سنوية خطوة بخطوة

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

1. صدّر كل التعيينات: المستخدم، الدور، النطاق، تاريخ البدء، تاريخ الانتهاء، آخر تسجيل دخول.
2. أرسل إلى كل مدير فرع قائمة فرعه واطلب نعم أو لا لكل سطر.
3. احذف الحسابات التي لم تسجّل دخولًا منذ 60 يومًا، وكل من لم يعد موظفًا.
4. ضع علامة على كل مستخدم يجمع نصفَي أي زوج ممنوع في المصفوفة أعلاه.
5. اذكر كل نطاق «كل الفروع» واطلب من المالك إعادة اعتماده باسم صاحبه.
6. سجّل من راجع ومتى وما الذي تغيّر. المراجعة نفسها سجل تدقيق.

ماذا تقيس

بضعة أرقام تُظهر هل الضوابط تعمل، ولا يحتاج أي منها إلى مشروع لوحات متابعة.

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

العودة إلى صباح الاثنين

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

لن تقع عمليات الاسترداد الـ41 كما وقعت. وإن بقي بعضها مشبوهًا، تجده المالكة في مراجعة أسبوعية من عشر دقائق، لأن لكل منها مستخدمًا وقاعدة ومعتمِدًا وبصمة. تقرأ تقريرًا بدل أن تكتشف خسارة.

الخلاصة

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

Anichur Rahaman مهندس برمجيات معماري ومؤسس StoreConsole، يصمّم أنظمة التجارة وERP للشركات النامية، ويهتم خصوصًا بالبنية القائمة على الأحداث وسلامة البيانات وتشغيل الأنظمة على خوادم الشركة نفسها.