إدارة الهوية في Security+: موظف نقل قسمه، وش يصير بصلاحياته القديمة؟

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

المشكلة في دورة الحساب، مو قوة كلمة المرور

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

ارسم ثلاث لحظات في حياة الهوية

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

من يقرر أن الصلاحية ما زالت مطلوبة؟

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

تمرين صغير يربطها بالاكتف دايركتوري

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

وش تكتب لو اكتشفت الخلل؟

اشرح أن الصلاحيات لا تتبع تغير الدور، وبيّن موردًا تدريبيًا يوضح الأثر، ثم اقترح مراجعة مرتبطة بالنقل مع مسؤول واضح. توصية «فعّل MFA» وحدها ما تعالج تراكم الصلاحيات.
المفهوم يفيد في مذاكرة Security+ وفي مراجعة بيئات AD، حتى لو اختلف المنتج المستخدم لتنفيذه.
شرح Microsoft لدورة الهوية والوصول:
https://learn.microsoft.com/en-us/entra/id-governance/identity-governance-overview