إدارة المستخدمين والأدوار والصلاحيات RBAC

ما هو RBAC ببساطة

التحكم في الوصول القائم على الأدوار (RBAC) نموذج بسيط في فكرته، عميق في أثره: بدلًا من منح كل موظف صلاحياته يدويًا، تُعرّف أدوارًا — مثل «مقدّم طلب»، «معتمد مالي»، «مدقق» — وتُلحق بكل دور حزمة صلاحيات محددة. ثم تربط الموظف بدوره، فيرث صلاحياته تلقائيًا.

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

المشكلة التي يحلّها فعلًا

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

النتائج المتكررة حين تُدار الصلاحيات فرديًا وبلا مراجعة:

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

الحد الأدنى من الصلاحية وفصل المهام

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

فصل المهام تحديدًا يحمي من أخطر المخاطر المالية. حين يطلب موظف صرف 200,000 ريال، يجب أن يعتمده شخص آخر، ويصرفه ثالث. النظام يفرض هذا الفصل بقاعدة لا باجتهاد. وحين يقترن بمصفوفة صلاحيات واضحة، يصبح لكل مبلغ معتمِده الصحيح؛ راجع مصفوفة الصلاحيات.

تصميم الأدوار عمليًا

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

خطوات عملية لبناء الأدوار

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

تصميم الأدوار ليس مشروعًا لمرة واحدة؛ فهو يحتاج مراجعة كلما تغيّر الهيكل. لكن الأساس السليم يجعل كل تغيير لاحق تعديلًا صغيرًا لا إعادة بناء.

الأدوار مقابل الصلاحيات الفردية

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

التفويض والنيابة

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

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

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

دورة حياة المستخدم: التحاق، تنقّل، مغادرة

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

الالتحاق (Joiner)

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

التنقّل (Mover)

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

المغادرة (Leaver)

يُوقف الوصول فورًا يوم المغادرة، لا بعد أسابيع. الربط بمزوّد الهوية المركزي عبر الدخول الموحّد يجعل هذا لحظيًا؛ راجع الربط مع Active Directory. ويظل كل ما فعله الموظف محفوظًا في سجل التدقيق غير القابل للتعديل.

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

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

مثال تطبيقي — منح صلاحية مالية

لنطبّق ما سبق على موقف حقيقي في جهة حكومية: التحق موظف جديد بالإدارة المالية، ويحتاج صلاحية اعتماد صرفيات حتى 50,000 ريال. في المنشأة الفوضوية يُمنح الوصول برسالة سريعة من المدير. في النظام يمر عبر مسار منضبط يطبّق فصل المهام والمراجعة:

لاحظ ثلاث نقاط. أولًا، الموارد البشرية تؤكد الدور الوظيفي قبل منح أي صلاحية، فلا صلاحية بلا وظيفة مبررة. ثانيًا، أمن المعلومات يراجع فصل المهام ليتأكد أن الموظف لا يجمع صلاحية الطلب والاعتماد معًا. ثالثًا، الصلاحية تُراجَع بعد 90 يومًا تلقائيًا، فلا تتحول إلى تراكم صامت.

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