مخطط انسيابي لتزويد المستخدمين بالصلاحيات (التحاق، انتقال، مغادرة)
مخطط انسيابي لعملية تزويد المستخدمين بالصلاحيات: حدث الموارد البشرية، وإنشاء الهوية في الدليل، وبيانات الاعتماد وMFA، وحزمة صلاحيات الدور، واعتماد المالك للوصول المميّز، والأنظمة التابعة، والتحقق وإعادة الاعتماد.
ما هي مخطط انسيابي لتزويد المستخدمين بالصلاحيات (التحاق، انتقال، مغادرة)؟
يفشل تزويد المستخدمين بالصلاحيات بصمت، ولهذا يُصلَح عادةً بعد تدقيق لا قبله. النصف الظاهر منه هو الالتحاق: الموظف الجديد الذي لا صندوق بريد له يشتكي في يومه الأول فيتولّى أحدهم الأمر. وما عدا ذلك غير مرئي. تُنسخ الصلاحيات ممن شغل المقعد قبله، فيصير حساب واحد زائد التزويد هو خط الأساس للإدارة كلها. ويصل المتعاقدون بلا قيد في الموارد البشرية وبلا تاريخ انتهاء وبراعٍ غادر المؤسسة منذ حين. ونصف الأنظمة قابع خلف الدخول الموحّد ويُزوَّد آلياً، بينما النصف الآخر (نظام المحاسبة، والأداة التي اشتراها فريق ببطاقة، وبوابة المورّد) قائمة انتظار يدوية لا يقيسها أحد. والانتقال الداخلي يضيف دون أن يطرح أبداً، لأن لا شيء في أي مكان يبلّغ عن صلاحية صارت غير لازمة فحسب. ولا ينتج عن ذلك كله حادثة، بل تراكم بطيء يظهر بعد سنوات في صورة ملاحظة في مراجعة صلاحيات، أو اختبار ضابط فاشل، أو حساب موظف سابق ما زال يجتاز المصادقة.
هذا المخطط هو آلية الهوية والحسابات، لا نموذج الطلب ولا سلسلة الاعتماد. فالشخص الموجود في وظيفته أصلاً ويطلب صلاحية واحدة إضافية، بما حولها من اعتمادات ودورة إعادة اعتماد، تخصّه عملية طلب صلاحيات الوصول على /ar/templates/عملية-طلب-صلاحيات-الوصول، والطلب نفسه حين يُطلقه حدث التحاق أو انتقال من الموارد البشرية ويحدّد نطاقَه ملفُّ دور موجود على /ar/templates/عملية-طلب-صلاحيات-الموظفين. أما الوصول إلى مجموعة بيانات، حيث يقرّر مالك البيانات بناءً على التصنيف والغرض لا على الدور الوظيفي، فعلى /ar/templates/عملية-طلب-الوصول-إلى-البيانات. ومسار المغادرة هنا قصير عن قصد ثم يسلّم: فتدفّق إلغاء التزويد الكامل، بالحسابات المشتركة وحسابات الخدمة، والتعطيل مقابل الحذف، وحفظ الأدلة، موجود على /ar/templates/عملية-إلغاء-صلاحيات-المستخدمين. والعقود والتحقّق من الخلفيات والتجهيزات واليوم الأول تخصّ /ar/templates/عملية-تأهيل-الموظفين-الجدد. ويبقى بعد ذلك كل ما بين الحدث ومجموعة حسابات عاملة ومتحقَّق منها ومسجّلة (الهوية، وبيانات الاعتماد، وحزمة الصلاحيات، والأنظمة التابعة) إضافةً إلى الفئة الوحيدة التي لا تحملها أيٌّ من تلك الصفحات: غير الموظف الذي يصل بلا أي قيد في الموارد البشرية. وبلغة الضوابط، هذا هو نصف الهوية من الملحق أ في ISO/IEC 27001:2022 (الضابط A.5.16 لإدارة الهوية الذي يحكم حياة الهوية كلها، والضابط A.5.17 لمعلومات المصادقة الذي يحكم بيانات الاعتماد الصادرة مقابلها) لا A.5.15 وA.5.18 اللذين يحكمان ما يُسمح لتلك الهوية ببلوغه.
وثلاثة قرارات مرسومة هنا تتركها معظم إجراءات التزويد ضمنية. «موظف أم غير موظف؟» يأتي قبل وجود الهوية، لأن المتعاقد يحتاج راعياً مُسمّى وتاريخ انتهاء لن توفّرهما تغذية الموارد البشرية أبداً، والهوية التي تُنشأ بدونهما هي اليتيمة التي تجدها مراجعة الصلاحيات بعد سنتين. و«ضمن الحزمة القياسية؟» يشطر التدفّق شطرين: كل ما في حزمة الدور يُزوَّد آلياً بلا أحد في المسار، ولا يذهب إلى المالك إلا الصلاحيات المميّزة أو الخارجة عن الحزمة، وهذا ما يمنع الاعتماد من التحوّل إلى ختم شكلي يُوضع على صناديق بريد. و«هل يطابق الوصول المُزوَّد الطلب؟» بوابة لا إجراء ختامي، لأنه يقرأ ما تمنحه الأنظمة المستهدفة فعلاً ويقارنه بما طُلب؛ فالصلاحيات التي وصلت بلا اعتماد لا يبلّغ عنها من حصل عليها أبداً. ويضيف فرع الانتقال قراراً رابعاً هو «صلاحيات قديمة خارج الحزمة الجديدة؟»، وتضيف إعادة الاعتماد خامساً هو «هل ما زالت الصلاحيات تطابق الدور؟»، وكلاهما يصبّ في خطوة السحب نفسها، فيكون للخروج من صلاحية طريق واحد مهما كان سبيل اكتشاف الحاجة إلى إزالتها.
ما الذي يغطيه هذا المخطط
في هذا القالب
- ست مراحل (المُطلِق، والهوية، والصلاحيات، والتزويد، والتحقق، والتغيير والمراجعة) موزّعة على خمسة مسارات: الموارد البشرية أو الراعي، وفريق الهوية، والمدير المباشر، ومالك الصلاحية، والأمن
- مدخل واحد لخمسة أحداث. «أي حدث هوية؟» يوجّه الالتحاق والانتقال والمغادرة وطلب الوصول الطارئ وإعادة الاعتماد المجدولة عبر المخطط نفسه، فتكون الآلية مشتركة بدل إعادة اختراعها لكل حالة
- مرحلة الهوية كاملةً: «موظف أم غير موظف؟» يوجّه المتعاقدين وموظفي شركات التوظيف وشركاء الخدمة إلى «تسجيل الراعي وتاريخ الانتهاء» (الخطوة الوحيدة التي تمنحهم مالكاً يُساءل عنهم وتاريخ نهاية) قبل أن يلتقي المساران عند «إنشاء الهوية في الدليل» ثم «إصدار بيانات الاعتماد وتفعيل MFA»
- «ضمن الحزمة القياسية؟»: المسار القياسي يمضي مباشرةً إلى «تزويد الحزمة القياسية آلياً» بلا معتمِد في الطريق، بينما تذهب الصلاحيات المميّزة والخارجة عن الحزمة إلى «هل يعتمد مالك الصلاحية؟»، وفرعها المرفوض ينتهي عند «رفض الصلاحية وإغلاق الطلب»
- التزويد بالترتيب الذي يجريه به المخطط: «تزويد الحزمة القياسية آلياً»، ثم «إنشاء الحسابات في الأنظمة التابعة» عبر الأنظمة الآلية واليدوية على حد سواء، ثم «هل يطابق الوصول المُزوَّد الطلب؟»، وفرع عدم المطابقة يمرّ عبر «تصحيح الزيادة أو النقص في المنح» ويعيد الفحص بدل إغلاق التذكرة
- نصف التغيير: يُسأل الانتقال «صلاحيات قديمة خارج الحزمة الجديدة؟» وكل ما يُوجَد يذهب إلى «سحب الصلاحيات المُستبدَلة» قبل العودة إلى «ضمن الحزمة القياسية؟»؛ وتبلغ المغادرة «التسليم إلى عملية إلغاء الصلاحيات»؛ و«هل ما زالت الصلاحيات تطابق الدور؟» يرسل الجواب المنحرف إلى خطوة السحب نفسها
متى تستخدم هذا القالب
- تكتب قسم الهوية وضبط الوصول في دليل عمليات تقنية المعلومات وتحتاج صورة واحدة لما يجري بين حدث في الموارد البشرية ومجموعة حسابات عاملة
- توشك على شراء أداة حوكمة هوية أو إعدادها، وتريد حسم التفرّعات (ما الذي يُزوَّد آلياً، وما الذي يحتاج مالكاً، وما الذي يبقى قائمة انتظار يدوية) قبل أن يحسمها سير العمل الافتراضي لدى المورّد نيابةً عنك
- تُظهر مراجعات الصلاحيات باستمرار صلاحيات من وظائف تركها أصحابها منذ سنوات، وتحتاج خطوة السحب عند الانتقال مرسومةً بمالك وموعد نهائي
- بيئتك مليئة بغير الموظفين (متعاقدون، وموظفو شركات توظيف، ومدقّقون، وشركاء، وحسابات خدمة) ولا يأتي أيٌّ منهم من تغذية الموارد البشرية التي تعتمد عليها بقية العملية
- سألك مدقّق أو استبيان أمني لعميل أو مراجع ISO 27001 كيف تُنشأ الهويات، وكيف تُمنح الصلاحيات، وكيف تعرف أن الوصول القائم هو الوصول المعتمد
كيف تعمل
أعد تسمية المسارات لتطابق أدوارك
استبدل الموارد البشرية أو الراعي، وفريق الهوية، والمدير المباشر، ومالك الصلاحية، والأمن بالأدوار الموجودة لديك فعلاً. وأبقِ الموارد البشرية والراعي في مسار واحد عن قصد: فهما الوظيفة نفسها تُؤدّى لفئتين مختلفتين، وفصلهما هو ما ينتهي بغير الموظفين بلا أحد يُساءل عنهم. ومسار مالك الصلاحية هو المسار الذي تكتشف معظم المؤسسات أنها لم تملأه. فإن لم تستطع تسمية مالك لصلاحياتك المميّزة اليوم، فتلك ثغرة لا مشكلة صياغة، وينبغي أن يبقى المسار في المخطط فارغاً بشكل ظاهر حتى تُغلق.
أعلن مصدرك المرجعي، وما ليس فيه
يفترض المخطط وجود تغذية موثوقة بحالات الالتحاق والانتقال والمغادرة. اكتب أي نظام هو، وأي حقول يحملها (المسمّى الوظيفي، والمدير، وتاريخ المباشرة، وتاريخ نفاذ التغيير، وآخر يوم عمل) وكم يستغرق ظهور التغيير فيه. ثم اكتب من ليس فيه. فالمتعاقدون وأعضاء مجلس الإدارة وموظفو شركات التوظيف والمتدربون وهويات الأنظمة غالباً ليسوا فيه، وكل فئة منهم تحتاج سجلاً وراعياً خاصين بها قبل أن تستطيع بقية العملية العمل.
اكتب حزم الصلاحيات قبل النشر
«اشتقاق حزمة صلاحيات الدور» خطوة خاملة ما لم تكن الحزم موجودة. ابدأ بالأدوار العشرة التي توظّف فيها أكثر من غيرها، واكتب ما يحتاجه كل دور منها فعلاً في يومه الأول. وحيث تتوفر بيانات تسجيل الدخول أو آخر استخدام، ابنِ على ما يستخدمه شاغلو الدور حالياً لا على ما يحملونه؛ فالفجوة بين الاثنين واسعة عادةً، وهي وحدها سبب جدوى كتابة الحزمة. واجعل كل حزمة حدّاً أدنى لا سقفاً، ليبقى ما خارجها ظاهراً بما يكفي ليستحق أن يُطلب.
اضبط عتبة اعتماد المالك
«ضمن الحزمة القياسية؟» لا يعمل إلا إذا وُضعت المعايير بجانبه. والمُحفِّزات المعتادة لفرع الاعتماد هي صلاحيات المسؤول والجذر، والوصول إلى بيئة الإنتاج، وأنظمة المدفوعات والرواتب، والبيانات الشخصية والصحية، وكل ما يمكنه تغيير صلاحيات شخص آخر. اختبر تلك القائمة على منوح الربع الماضي قبل نشرها: فالمعيار الذي يلتقط معظمها ليس معياراً. وإن ذهب كل شيء إلى مالك صلاحية، وصلت الاعتمادات أسرع مما يستطيع أحد قراءته وصار الضابط قائمة انتظار يتعلّم الناس النقر خلالها.
اجعل السحب عند الانتقال التزاماً متتبَّعاً
«سحب الصلاحيات المُستبدَلة» هي الخطوة التي تقرّر هل تتراكم الصلاحيات في مؤسستك. امنحها التذكرة نفسها والمالك نفسه والموعد النهائي نفسه الذي للمنح، ولا تغلق حدث الانتقال إلا حين يتمّ نصفاه معاً؛ فالتذكرة التي تُغلق على نصف الالتحاق هي الآلية التي لا يحدث بها السحب أبداً. ويضع المخطط المقارنة عند المدير المباشر لا عند فريق الهوية عن قصد: فالفريق يستطيع إنتاج قائمة الفروق، لكن المدير وحده يعرف هل الصلاحية مُستبدَلة فعلاً أم ما زالت لازمة لتسليم مهام.
استعرضه مع من يشغّلونه، ثم انشر إصداراً
احسم الفرعين اللذين لا مالك لهما افتراضياً قبل النشر. قرّر من يحقّ له استدعاء الوصول الطارئ خارج ساعات العمل ومن يقرأ سجل الجلسة بعدها، وقرّر من يتصرّف حيال جواب «انحرفت» عند إعادة الاعتماد وفي أي مهلة، فالمراجعة التي تُنتج قائمة لا يسحب أحد منها شيئاً أسوأ من لا مراجعة إطلاقاً. ثم خذ المخطط إلى مهندس في مكتب الخدمة، ومدير مباشر وظّف حديثاً، ومن أجرى آخر مراجعة صلاحيات، وصحّحه ليطابق ما يحدث فعلاً. وانشر النسخة المصحّحة، وأبقِ سابقاتها قابلة للقراءة، واستشهد بها في سياسة ضبط الوصول لديك.
الأسئلة الشائعة
ما خطوات عملية تزويد المستخدمين بالصلاحيات؟
خذ حدث التحاق أو انتقال أو مغادرة من المصدر المرجعي؛ وقرّر هل الشخص موظف أم غير موظف، وامنح غير الموظفين راعياً وتاريخ انتهاء؛ وأنشئ هوية في الدليل أو طابِقها بهوية قائمة، بمعرّف لا يُعاد استخدامه أبداً؛ وأصدر بيانات اعتماد وسجّل المصادقة متعددة العوامل مقابل تلك الهوية؛ واشتقّ حزمة الصلاحيات للمسمّى الوظيفي؛ وزوّد آلياً كل ما داخل الحزمة ووجّه الصلاحيات المميّزة أو الخارجة عنها إلى مالك الصلاحية للاعتماد؛ وأنشئ الحسابات في الأنظمة التابعة، الآلية منها واليدوية على حد سواء؛ وتحقّق من أن ما تمنحه الأنظمة فعلاً يطابق ما طُلب؛ واطلب من المدير المباشر تأكيده؛ وسجّل الصلاحيات مقابل الهوية. وبعد ذلك تستمر العملية: الانتقال يعيد اشتقاق الحزمة ويسحب ما لم يعد الدور القديم يبرّره، والمغادر تُعطَّل هويته ويُسلَّم إلى عملية الإلغاء، وإعادة الاعتماد تفحص دورياً بقاء التطابق بين الصلاحيات والدور.
ما حزمة الصلاحيات الأصلية القائمة على الدور؟
هي مجموعة الصلاحيات التي يحتاجها العمل في يومه الأول، مرتبطةً بالدور لا بالشخص: البريد والتقويم، والشبكة الداخلية، وأنظمة العمل الأساسية لتلك الوظيفة، والأقراص المشتركة لذلك الفريق. ولأنها مشتقّة من المسمّى الوظيفي، يمكن منحها بلا معتمِد في المسار، وهذا هو المقصود منها: فهي تُخرج المنوح الاعتيادية من قائمة الاعتماد لتُقرأ الاستثناءات كما ينبغي. وقاعدتان تُبقيان الحزم نزيهة. ابنِها مما تتطلّبه الوظيفة، لا بتصدير صلاحيات آخر من شغلها، فذلك ينسخ كل زائد متراكم مع الضروري. وامنح كل حزمة مالكاً مُسمّى وتاريخ مراجعة، لأن الحزمة بلا مالك لا تفعل إلا أن تكبر: يُضاف إليها كل طلب تعذّر رفضه، فتصير خلال سنتين تمنح أضعاف ما تحتاجه أي وظيفة بمفردها.
بم يختلف تزويد المستخدمين بالصلاحيات عن عملية طلب صلاحيات الوصول؟
الاثنتان تلتقيان في المنتصف وتملك كل واحدة نصفاً مختلفاً. عملية طلب صلاحيات الوصول على /ar/templates/عملية-طلب-صلاحيات-الوصول تبدأ بشخص موجود في وظيفته أصلاً ويحتاج نظاماً إضافياً واحداً: يرفع طلباً، ويعتمده المدير المباشر ومالك النظام، ثم يُزوَّد ويُعاد اعتماده لاحقاً. وعملية طلب صلاحيات الموظفين على /ar/templates/عملية-طلب-صلاحيات-الموظفين تغطّي الطلب نفسه حين يُطلقه حدث التحاق أو انتقال من الموارد البشرية ويحدّد نطاقَه ملفُّ دور. وكلتاهما عن القرار. أما هذه الصفحة فعن التنفيذ: إنشاء الهوية، وإصدار بيانات الاعتماد وتسجيل المصادقة متعددة العوامل، واشتقاق الحزمة، وإنشاء الحسابات في كل نظام تابع، وقراءة الصلاحيات من الأنظمة المستهدفة للتأكد أنها هي المعتمدة. فإن كنت تصمّم نموذج طلب أو سلسلة اعتماد فاستخدم تلك الصفحتين، وإن كنت تبني آلية التزويد خلفهما أو توثّقها، بما فيها هويات المتعاقدين ونصف السحب في الانتقال الداخلي، فاستخدم هذه. وإن كان السؤال عن الوصول إلى مجموعة بيانات لا إلى نظام، فانظر /ar/templates/عملية-طلب-الوصول-إلى-البيانات.
كم يمكن فعلاً أتمتة تزويد المستخدمين بالصلاحيات؟
أكثر مما أتمتته معظم المؤسسات، ولن يكون كله أبداً. فالأنظمة الواقعة خلف الدخول الموحّد يمكن أن تعمل بلا تذكرة: تُنشأ هوية الدليل من قيد الموارد البشرية، وتُطبَّق حزمة الدور، وتتبعها عضوية المجموعات. والذي يهزم التغطية الكاملة هو الأنظمة التي لم يخطّط لها أحد: نظام الرواتب بلا واجهة برمجية، وجهاز المختبر الذي يحتفظ بقائمة مستخدميه المحلية، وبوابة الشريك حيث يُنشأ الحساب بالردّ على رسالة بريد. وهذه تحتاج قائمة انتظار لها مالك مُسمّى ومدة مستهدفة، وتحتاج أن تكون مسرودة، لأن النظام اليدوي غير المدرج يُزوَّد متأخراً للملتحق ويُغفَل تماماً للمغادر. احتفظ بسجل للأنظمة الموصولة وغير الموصولة، وراجعه كلما اشتُري شيء جديد، واعتبر تقصير القائمة اليدوية هو برنامج العمل الحقيقي. وأتمتة المنح دون أتمتة القراءة المرتدة فخّ قائم بذاته: فالموصّلات تفشل بصمت، ولهذا تقرأ خطوة التحقق الصلاحيات من النظام المستهدف لا من التذكرة.
كيف تُزوَّد صلاحيات المتعاقدين وغيرهم من غير الموظفين؟
بالطريقة نفسها التي للموظفين، إلا أن لا شيء أعلى المسار يخبرك بوجودهم. فالمتعاقدون وموظفو شركات التوظيف والمدقّقون ومهندسو الشركاء والمتدربون وهويات الأنظمة نادراً ما يظهرون في نظام الموارد البشرية، ولهذا يجب التقاط السمتين اللتين تجعلان الهوية قابلة للإدارة عن قصد: راعٍ داخلي مُسمّى يُساءل عنها، وتاريخ انتهاء مأخوذ من العقد أو من مدة التكليف لا متروك مفتوحاً. واجعل الانتهاء تلقائياً: يتعطّل الحساب من تلقاء نفسه في ذلك التاريخ، ويكون التجديد فعلاً صريحاً من الراعي بتاريخ نهاية جديد. وأعد إسناد الرعاية حين يغادر راعٍ، لأن الهوية التي ذهب راعيها هي بالضبط الحساب الذي لا يراجعه أحد. وغير الموظفين يستحقون عادةً حزماً أضيق وفترة إعادة اعتماد أقصر من الموظفين، لأن عملهم أضيق ودورانهم أسرع. ومعظم الحسابات اليتيمة التي تكشفها مراجعة الصلاحيات تعود إلى أشخاص لم توظّفهم المؤسسة قط.
أين تندرج هذه العملية
في معظم المؤسسات تأتي هذه العملية بعد مخطط عملية اعتماد مؤهلات مقدمي الرعاية وتسلّم إلى مخطط انسيابي لعملية إلغاء صلاحيات المستخدمين (إلغاء التزويد).
وهي خطوة واحدة ضمن حوكمة الوصول.
الخطوة 1: مخطط انسيابي لتزويد المستخدمين بالصلاحيات (التحاق، انتقال، مغادرة) أنت هنا
مخطط انسيابي لعملية تزويد المستخدمين بالصلاحيات: حدث الموارد البشرية، وإنشاء الهوية في الدليل، وبيانات الاعتماد وMFA، وحزمة صلاحيات الدور، واعتماد المالك للوصول المميّز، والأنظمة التابعة، والتحقق وإعادة الاعتماد.
الخطوة 2: مخطط انسيابي لعملية طلب صلاحيات الوصول
مخطط انسيابي لعملية طلب صلاحيات الوصول: طلب قائم على الأدوار، واعتماد المدير المباشر ومالك النظام، وفحص فصل المهام، ثم التزويد وإعادة الاعتماد الدورية.
الخطوة 3: مخطط انسيابي لعملية طلب صلاحيات الموظفين (الالتحاق والنقل)
الخطوة 4: مخطط انسيابي لعملية إلغاء صلاحيات المستخدمين (إلغاء التزويد)