الأمان والتفويض في Temenos: Entitlements وفصل الصلاحيات

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

التفويض في نظام مصرفي ليس قائمة شاشات مخفية، بل إجابة موثّقة لسؤال واحد: من يستطيع فعل ماذا، تحت أيّ شرط، ومن يوافق؟ يمشي هذا المقال على الطبقات الثلاث التي يقوم عليها هذا الجواب داخل Temenos، ثم ينتقل إلى الجانب الذي يتعثّر فيه معظم البيئات العملية وهو فصل مهام العمليات (Segregation of Duties)، وينتهي عند الحدّ الذي يجب أن ترسمه قبل أن يدخل نظام خارجي إلى بيئتك، لأن الحساب التقني الذي يستدعي واجهة بالنيابة عن عميل يرث في الغالب صلاحيات أوسع مما قصده من أنشأه.

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

ثلاث طبقات يجب ألّا تُدمج

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

• الهوية (Identity): من هذا المستخدم؟ الحساب وحالته (نشط، موقوف، مغلق)، ومسار التحقق من هويته عند الدخول. الهوية نقطة ربط فقط ولا تحمل في ذاتها أي صلاحية.


• الملف (Profile / Access Class): ما الذي يُسمح له بفتح؟ التطبيق، والإصدار (Version) الذي يدخل منه، ومستوى الأمان المسموح. هذا هو الكائن الأكثر إساءة استخدام في البنوك، لأن أسماء الملفات المتطابقة تُنسخ وتُورَث وتكبر بلا سقف.


• المصفوفة التشغيلية (Authorisation arrangement): كم يُسمح، وبأيّ شرط، ومن يوافق؟ هنا تعيش حدود المبالغ، وشرط الاعتماد المزدوج، وقواعد الإحلال (Substitution)، والشروط المرتبطة بالمنتج نفسه.

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

المستخدمون والفرق: نموذج حيّ لا مُدرّج محفوظ

نموذج المستخدمين في Temenos لا يُبنى مرة واحدة؛ يُدار على ثلاث حلقات: التحقّق (Joiner)، والتغيير (Mover)، والإنهاء (Leaver). البيئة التي لا تملك لكل حلقة مساراً موثّقاً بنت في يوم من الأيام حساباً يتيماً يحمل صلاحيات مصرفية كاملة. المسار اليدوي البطيء أفضل من لا شيء، بشرط أن يُسجَّل ويمرّ على نفس رقابة التغيير التي يمرّ بها أي تعديل إنتاجي آخر.

ثلاثة قرارات تسبق أي اسم مستخدم جديد:

• الاسم يمثل الدور لا الشخص: سمّ الملف أو الفريق بالمهمة («فريق إدخال التحويلات — فرع الشمال») لا باسم صاحب العمل. الملف المرتبط بشخص يموت بذهابه أو بوظيفته.


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


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

ثم يبقى السؤال الأهم: من يقرّر أن الدور تغيّر فعلاً؟ في البيئات الناضجة تكون المراجعة الدورية المؤكَّدة (Attestation) مهمة مالك العملية، لا الفريق التقني وحده. والمراجعة التي يوقّع عليها صاحب الصلاحية نفسه ليست مراجعة.

من التطبيق إلى العملية: ثلاثة مستويات لا مستويين

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

المستوى الأول: الوصول إلى التطبيق

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

المستوى الثاني: الوصول إلى الوظيفة

دخول التطبيق لا يعني تشغيل كل عملياته. هنا تُوضع حدود على مستوى الوظيفة (Secured Function) ومستوى الأمان: مستخدم يقرأ سجل العميل، وآخر يعدّله، وثالث يقرّر. هذه الطبقة هي ما يقلّص أثر تسريب حساب واحد؛ فبدونها يصبح اختراق حساب等于 تسوية مالية كاملة، لأنها تسوية كاملة فعلاً.

المستوى الثالث: الشرط التشغيلي

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

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

{

  "role": "PAY-INITIATOR-BRANCH-NORTH",

  "application": "FT",

  "version": "V11",

  "secured_functions": ["FT.ENT.NEW", "FT.ENT.AMEND"],

  "authorisation": {

    "max_amount_single": 250000,

    "max_amount_daily": 1000000,

    "dual_control_above": 50000,

    "approver_role": "PAY-APPROVER-REGION",

    "substitution_allowed": false

  },

  "expires_at": null

}

فصل مهام العمليات: من يُدخل لا يوقّع

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

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

فصل ثابت وفصل ديناميكي

• فصل ثابت (Static SoD): اجتماع الدورين خطأ حتى لو لم يُستخدما معاً. يُمنع عند التعيين أو عند منح الدور، ويمسكه النظام لا 사람은.


• فصل ديناميكي (Dynamic SoD): اجتماع الدورين مسموح عموماً، لكن لا يجتمعان في العملية نفسها. يُفرض بالاعتماد المزدوج ومسار المصادقة، لا بالمنع.

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

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

-- تعارضات فصل المهام القائمة فعلياً (نموذج مبسّط)

SELECT u.user_id,

       u.branch,

       r1.role_code  AS role_a,

       r2.role_code  AS role_b,

       g.granted_at,

       g.granted_by,

       DATEDIFF('day', g.granted_at, CURRENT_DATE) AS age_days

FROM   entitlements e1

JOIN   entitlements e2

  ON   e1.user_id = e2.user_id

 AND   e1.role_code < e2.role_code

JOIN   sod_conflicts c

  ON   c.role_a = e1.role_code

 AND   c.role_b = e2.role_code

JOIN   users u

  ON   u.user_id = e1.user_id

JOIN   role_grants g

  ON   g.user_id = e1.user_id

WHERE  c.severity IN ('HIGH','CRITICAL')

ORDER BY c.severity, age_days DESC;

خطّ الدفاع عند دخول نظام خارجي

واجهة التكامل لا تُعامَل كمستخدم عادي ولا كمستخدم موثوق؛ تُعامَل كطرف ثالث له حدّ م写在 مقاله. ثلاثة حدود تُرسم قبل كتابة أول سطر في عقد الواجهة:

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


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


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

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

أخطاء شائعة

قائمة تحقق

• كل دور مكتوب باسم مهمة لا باسم شخص، ولكل ملف مهمة مكتوب قائمة وظائفه ومصدر كل صلاحية فيه.


• مصفوفة فصل المهام مبنية على العمليات المالية المدرجة، وملف التعارضات مملوك ومحدّث مع كل تغيير عملية.


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


• كل صلاحية مؤقتة أو استثنائية لها تاريخ انتهاء مراقب، والاستثناء العاجل يُلغى ويُراجَع بعدenggInstance لا بعد لاحقة.


• تقرير التعارضات يعمل دورياً، وله مسار تصعيد، ولا يُغلق أي تعارض إلا بإزالة دور أو إقرار مخاطرة.


• تسجيل التدقيق يربط كل عملية بمستخدم حقيقي ومعرّف ارتباط (correlation id) واحد في كل مسار تكامل.

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

هل أعطي كل قسم ملفاً واحداً مشتركاً؟

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

لماذا لا يكفي الاعتماد المزدوج وحده؟

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

كيف أتعامل مع الصلاحيات العاجلة (Break-glass)؟

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

الخلاصة

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

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

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

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

flowchart LR

    A["نظام خارجي"]

    B["طلب OFS أو API"]

    C["فحوص Temenos"]

    D["المعالجة والموافقة"]

    E["حالة المعاملة"]

    A --> B

    B --> C

    C --> D

    D --> E