Microsoft Entra ID Q&A: A Comprehensive Guide to Identity, Access, and Zero Trust

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

هنا يأتي دور Microsoft Entra ID بوصفه العمود الفقري لإدارة الهوية والوصول في منظومة مايكروسوفت السحابية، ومنصة متكاملة تجمع بين المصادقة الموحدة، والتحكم الديناميكي في الوصول، وحماية الهوية من التهديدات، وحوكمة الصلاحيات، وإدارة الامتيازات الحساسة، مع قابلية عالية للأتمتة والتكامل مع الأنظمة المؤسسية. Entra ID لا يركز فقط على “من هو المستخدم”، بل يوسّع قرار الثقة ليشمل السياق كاملًا: الجهاز، الموقع، مستوى المخاطر، حساسية المورد، ونوع العملية المطلوبة.

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

🧭 أساسيات Microsoft Entra ID

🧩 السؤال 1: ما هو Microsoft Entra ID؟

🧠 الإجابة:
Microsoft Entra ID هو نظام إدارة هويات ووصول سحابي (Identity and Access Management – IAM) تقدمه مايكروسوفت، ويُستخدم لإدارة حسابات المستخدمين، المصادقة، والتفويض للوصول إلى التطبيقات والخدمات. يمثل Entra ID تطورًا استراتيجيًا لـ Azure AD ليكون جزءًا من منظومة Entra الأوسع، التي تركز على Zero Trust، الهوية اللامركزية، وحوكمة الوصول.

يوفر Entra ID خدمات أساسية مثل المصادقة الموحدة (SSO)، المصادقة متعددة العوامل (MFA)، إدارة الوصول المشروط، والتكامل مع آلاف التطبيقات السحابية. كما يدعم البيئات الهجينة عبر التكامل مع Active Directory المحلي، مما يجعله عنصرًا محوريًا في التحول الرقمي.

🧪 مثال عملي:
شركة عالمية تستخدم Entra ID لتمكين الموظفين من تسجيل الدخول مرة واحدة للوصول إلى Microsoft 365، Salesforce، وتطبيقات داخلية، مع فرض MFA عند الدخول من خارج الشبكة.

🧩 السؤال 2: ما الفرق بين Azure AD وMicrosoft Entra ID؟

🧠 الإجابة:
Azure AD هو الاسم السابق للخدمة الأساسية لإدارة الهوية، بينما Microsoft Entra ID هو الاسم الجديد الذي يعكس توسيع الرؤية لتشمل مجموعة متكاملة من حلول الهوية. التغيير ليس تقنيًا فقط بل استراتيجيًا، حيث يربط Entra ID بخدمات مثل Entra Permissions Management وEntra Verified ID.

من الناحية الوظيفية، Entra ID يحتفظ بكافة إمكانيات Azure AD، مع تحسينات مستمرة في الأمان، الحوكمة، والتكامل مع نموذج Zero Trust.

🧪 مثال عملي:
مؤسسة قامت بتحديث وثائقها وسياساتها من Azure AD إلى Entra ID دون الحاجة لأي ترحيل تقني، مع الاستفادة من خدمات Entra الإضافية.

🧩 السؤال 3: ما دور Entra ID في نموذج Zero Trust؟

🧠 الإجابة:
Entra ID هو القلب النابض لنموذج Zero Trust، حيث يعتمد النموذج على مبدأ "لا تثق أبدًا، تحقق دائمًا". يطبق Entra ID هذا المبدأ عبر التحقق المستمر من هوية المستخدم، حالة الجهاز، الموقع، وسلوك تسجيل الدخول قبل منح الوصول.

من خلال Conditional Access وIdentity Protection، يتم تقييم المخاطر بشكل ديناميكي، مما يقلل احتمالية الاختراق حتى في حال تسرب بيانات الاعتماد.

🧪 مثال عملي:
فرض سياسة تمنع الوصول إلى تطبيق مالي حساس إلا من أجهزة مُدارة ومتوافقة مع Intune، حتى لو كانت بيانات الدخول صحيحة.

🧩 السؤال 4: ما هي المكونات الرئيسية لـ Entra ID؟

🧠 الإجابة:
يتكون Entra ID من عدة مكونات أساسية تشمل: المستخدمين، المجموعات، التطبيقات، الأدوار، سياسات الوصول المشروط، وإعدادات الأمان. هذه المكونات تعمل معًا لتشكيل نظام متكامل لإدارة الهوية.

كما يشمل تكاملات مع خدمات مثل Microsoft 365، Azure، وتطبيقات SaaS، بالإضافة إلى واجهات برمجة تطبيقات (APIs) للإدارة الآلية.

🧪 مثال عملي:
إنشاء مجموعة ديناميكية تضم جميع موظفي قسم المالية وربطها بتطبيق محاسبي مع سياسة وصول مشروط.

🧩 السؤال 5: ما هو Tenant في Entra ID؟

🧠 الإجابة:
الـ Tenant هو المثيل المنطقي لـ Entra ID الذي يمثل مؤسسة أو بيئة مستقلة. يحتوي على جميع المستخدمين، التطبيقات، السياسات، وإعدادات الأمان الخاصة بالمؤسسة.

يمكن للمؤسسة امتلاك Tenant واحد أو عدة Tenants حسب الهيكل التنظيمي، المتطلبات القانونية، أو الفصل بين البيئات.

🧪 مثال عملي:
شركة متعددة الجنسيات تمتلك Tenant منفصل لكل منطقة جغرافية للامتثال للأنظمة المحلية.

🧩 السؤال 6: ما أنواع الحسابات في Entra ID؟

🧠 الإجابة:
يدعم Entra ID عدة أنواع من الحسابات مثل: حسابات المستخدمين الداخليين، حسابات الضيوف (B2B)، حسابات الخدمة (Service Accounts)، والـ Managed Identities.

كل نوع مصمم لغرض محدد مع سياسات أمان مختلفة، مما يتيح مرونة عالية في إدارة الوصول.

🧪 مثال عملي:
إضافة مورد خارجي كضيف للوصول إلى SharePoint فقط دون منحه صلاحيات داخلية.

🧩 السؤال 7: كيف يدعم Entra ID البيئات الهجينة؟

🧠 الإجابة:
يدعم Entra ID البيئات الهجينة عبر Azure AD Connect (Entra Connect)، الذي يزامن الهويات من Active Directory المحلي إلى السحابة.

هذا يسمح باستخدام نفس بيانات الاعتماد للوصول إلى الموارد المحلية والسحابية، مع دعم SSO وخيارات مصادقة متعددة.

🧪 مثال عملي:
موظف يستخدم نفس كلمة المرور لتسجيل الدخول إلى جهازه المحلي وMicrosoft 365.

🧩 السؤال 8: ما الفرق بين Entra ID وActive Directory المحلي؟

🧠 الإجابة:
Active Directory المحلي يعتمد على بنية تقليدية داخل الشبكة، بينما Entra ID هو خدمة سحابية أصلية مصممة للتطبيقات الحديثة.

Entra ID لا يستخدم Kerberos أو LDAP بنفس الطريقة، بل يعتمد على بروتوكولات حديثة مثل OAuth وOpenID Connect.

🧪 مثال عملي:
تطبيق ويب حديث يستخدم Entra ID للمصادقة بدل LDAP.

🧩 السؤال 9: ما هي حالات الاستخدام الشائعة لـ Entra ID؟

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

كما يُستخدم في أتمتة الهوية، DevOps، وربط التطبيقات المخصصة.

🧪 مثال عملي:
ربط تطبيق داخلي بـ Entra ID لتوحيد المصادقة.

🧩 السؤال 10: لماذا يعتبر Entra ID عنصرًا استراتيجيًا للمؤسسات؟

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

يساعد المؤسسات على تقليل المخاطر، تحسين تجربة المستخدم، والامتثال للمعايير.

🧪 مثال عملي:
اعتماد Entra ID كمنصة IAM موحدة بدلاً من حلول متعددة.

🧭 إدارة المستخدمين والمجموعات في Entra ID

🧩 السؤال 11: كيف تتم إدارة المستخدمين في Microsoft Entra ID؟

🧠 الإجابة:
تعتمد إدارة المستخدمين في Microsoft Entra ID على نموذج مركزي موحد يتيح إنشاء الحسابات، تعديلها، تعطيلها أو حذفها من خلال بوابة Entra أو عبر PowerShell وMicrosoft Graph API. تم تصميم هذا النموذج ليتماشى مع دورة حياة المستخدم داخل المؤسسة، منذ الانضمام (Joiner) مرورًا بالتنقل الوظيفي (Mover) وحتى المغادرة (Leaver).

يدعم Entra ID الإدارة اليدوية والآلية، حيث يمكن ربطه بأنظمة الموارد البشرية لتنفيذ عمليات التزويد التلقائي (Provisioning). كما يسمح بتحديد خصائص الهوية، تعيين الأدوار، وربط الحسابات بالتطبيقات والمجموعات، مع تطبيق سياسات أمان دقيقة على مستوى المستخدم.

🧪 مثال عملي:
عند تعيين موظف جديد، يتم إنشاء حسابه تلقائيًا في Entra ID، وإضافته لمجموعات القسم، ومنحه الوصول إلى Microsoft 365 والتطبيقات الداخلية دون تدخل يدوي.

🧩 السؤال 12: ما أنواع المستخدمين في Entra ID؟

🧠 الإجابة:
يوفر Entra ID نوعين رئيسيين من المستخدمين: المستخدمون الداخليون (Members) الذين ينتمون إلى المؤسسة، والمستخدمون الضيوف (Guests) الذين يتم دعوتهم من خارجها. يتيح هذا التقسيم إدارة دقيقة للصلاحيات وتقليل المخاطر الأمنية.

يمكن التحكم في سياسات الوصول لكل نوع، حيث يُمنح المستخدم الداخلي صلاحيات أوسع، بينما يخضع الضيف لقيود صارمة وفق مبدأ أقل الامتيازات (Least Privilege).

🧪 مثال عملي:
مقاول خارجي يُضاف كضيف للوصول إلى تطبيق مشروع محدد فقط، مع منع الوصول لبقية موارد المؤسسة.

🧩 السؤال 13: ما هي المجموعات (Groups) في Entra ID؟

🧠 الإجابة:
المجموعات في Entra ID هي كيان تنظيمي يُستخدم لتجميع المستخدمين أو الأجهزة بهدف تسهيل إدارة الصلاحيات والسياسات. يمكن ربط المجموعات بالتطبيقات، الأدوار، سياسات Conditional Access، وموارد Azure.

يساعد هذا النهج على تقليل التعقيد الإداري وتحقيق اتساق في تطبيق السياسات، خاصة في البيئات الكبيرة.

🧪 مثال عملي:
إنشاء مجموعة باسم "Finance-Users" وربطها بتطبيق ERP مع سياسات أمان مشددة.

🧩 السؤال 14: ما الفرق بين المجموعات الثابتة والديناميكية؟

🧠 الإجابة:
المجموعات الثابتة تعتمد على الإضافة اليدوية للأعضاء، بينما تعتمد المجموعات الديناميكية على قواعد (Rules) تحدد العضوية تلقائيًا بناءً على خصائص المستخدم مثل القسم أو المسمى الوظيفي.

تُعد المجموعات الديناميكية أداة قوية لأتمتة إدارة الهوية وتقليل الأخطاء البشرية.

🧪 مثال عملي:
مجموعة ديناميكية تضم جميع المستخدمين الذين يحتوي حقل Department لديهم على "IT".

🧩 السؤال 15: ما هو User Lifecycle Management في Entra ID؟

🧠 الإجابة:
إدارة دورة حياة المستخدم تشير إلى التحكم الكامل في هوية المستخدم من الإنشاء وحتى الإزالة. يدعم Entra ID هذا المفهوم عبر التكامل مع أنظمة HR، وأتمتة التزويد وسحب الصلاحيات.

يساعد ذلك في تقليل المخاطر المرتبطة بالحسابات اليتيمة (Orphaned Accounts) وضمان الامتثال.

🧪 مثال عملي:
عند استقالة موظف، يتم تعطيل حسابه تلقائيًا وسحب جميع الصلاحيات خلال دقائق.

🧩 السؤال 16: ما هي الأدوار (Roles) في Entra ID؟

🧠 الإجابة:
الأدوار في Entra ID هي مجموعة من الصلاحيات الإدارية الجاهزة مثل Global Administrator وUser Administrator. تُستخدم لتفويض المهام الإدارية دون منح صلاحيات زائدة.

يعتمد Entra ID على مبدأ الفصل بين المهام (Separation of Duties) لتقليل المخاطر.

🧪 مثال عملي:
منح فريق الدعم دور Helpdesk Administrator لإعادة تعيين كلمات المرور فقط.

🧩 السؤال 17: كيف يساهم مبدأ أقل الامتيازات في Entra ID؟

🧠 الإجابة:
يعتمد Entra ID بشكل أساسي على مبدأ Least Privilege، حيث يتم منح المستخدم أو المسؤول الحد الأدنى من الصلاحيات اللازمة فقط.

هذا يقلل من سطح الهجوم ويحد من تأثير أي اختراق محتمل.

🧪 مثال عملي:
مسؤول تطبيق يُمنح صلاحيات إدارة تطبيق محدد دون الوصول لإعدادات tenant بالكامل.

🧩 السؤال 18: ما هو Privileged Identity Management (PIM)؟

🧠 الإجابة:
PIM هو مكون أمني متقدم في Entra ID يُستخدم لإدارة الصلاحيات الحساسة بشكل مؤقت ومراقَب. يسمح بتفعيل الأدوار عند الحاجة فقط مع تسجيل كامل للأنشطة.

يُعد PIM عنصرًا أساسيًا في تقليل مخاطر إساءة استخدام الصلاحيات الإدارية.

🧪 مثال عملي:
مسؤول يفعّل دور Global Admin لمدة ساعة واحدة بعد موافقة متعددة العوامل.

🧩 السؤال 19: كيف تتم إدارة الحسابات المميزة (Privileged Accounts)؟

🧠 الإجابة:
تتم إدارة الحسابات المميزة عبر PIM، Conditional Access، والمراجعات الدورية. يوصى باستخدام حسابات منفصلة للإدارة وعدم استخدام الحسابات اليومية.

كما يجب فرض MFA ومراقبة تسجيل الدخول باستمرار.

🧪 مثال عملي:
إنشاء حساب إداري منفصل لكل مسؤول مع تسجيل كامل لكل نشاط.

🧩 السؤال 20: ما أفضل الممارسات لإدارة المستخدمين في Entra ID؟

🧠 الإجابة:
تشمل أفضل الممارسات: الأتمتة، استخدام المجموعات الديناميكية، تفعيل MFA، تقليل الأدوار الدائمة، والمراجعة الدورية للصلاحيات.

يساعد الالتزام بهذه الممارسات في تحقيق بيئة آمنة وقابلة للتوسع.

🧪 مثال عملي:
تطبيق مراجعة وصول ربع سنوية لجميع المستخدمين ذوي الصلاحيات العالية.

🧭 المصادقة وSSO وMFA وConditional Access في Entra ID

🧩 السؤال 21: كيف تعمل المصادقة (Authentication) في Microsoft Entra ID؟

🧠 الإجابة:
المصادقة في Microsoft Entra ID هي العملية التي يتحقق عبرها النظام من أن المستخدم هو فعلاً من يدّعي أنه، قبل منحه “رمز” وصول (Token) لاستخدام التطبيقات والخدمات. عمليًا، Entra ID يعمل كمزوّد هوية (Identity Provider – IdP) يصدر رموزًا قياسية مبنية على بروتوكولات حديثة مثل OAuth 2.0 وOpenID Connect وSAML. هذه الرموز لا تثبت فقط هوية المستخدم، بل تحمل كذلك مطالبات (Claims) مثل المجموعات والأدوار وحالة المصادقة، لتُستخدم لاحقًا في التفويض (Authorization).

تتأثر عملية المصادقة بسياق الدخول (Sign-in context) مثل الجهاز، الموقع، الشبكة، ونوع التطبيق. وهنا تظهر قوة Entra ID: المصادقة ليست “حدثًا” منفصلًا، بل جزء من سلسلة قرارات أمنية ديناميكية تُكمّلها سياسات الوصول المشروط، وحماية الهوية، وتقييم المخاطر. هذا يعني أن نفس المستخدم قد يُصادَق عليه بطرق مختلفة حسب مستوى الحساسية والمخاطر في اللحظة ذاتها.

اعتبارًا من منظور تشغيلي، نجاح المصادقة ينتج عنه Token ويليه تسجيل تفصيلي في سجلات الدخول، ما يتيح تتبع الحوادث وتحليل السلوك. أما من منظور أمني، فالمصادقة القوية تُبنى على عدة ركائز: كلمات مرور قوية أو بدون كلمة مرور، MFA، وحماية من هجمات كلمة المرور مثل Password Spray وPhishing عبر المصادقة المقاومة للتصيد.

🧪 مثال عملي:
مستخدم يحاول الدخول إلى Microsoft 365 من جهازه في المكتب: يتم إدخال كلمة المرور ويُمنح Token مباشرة بسبب انخفاض المخاطر. نفس المستخدم يحاول الدخول من شبكة عامة خارج الدولة: يُطلب منه MFA، وقد يُحظر الدخول بالكامل إذا كانت مخاطره مرتفعة وفق Identity Protection.

🧩 السؤال 22: ما هو SSO (تسجيل الدخول الموحّد) وكيف يطبَّق في Entra ID؟

🧠 الإجابة:
SSO أو “تسجيل الدخول الموحّد” يعني أن المستخدم يقوم بالمصادقة مرة واحدة فقط، ثم يستطيع الوصول إلى عدة تطبيقات دون إعادة إدخال بيانات الاعتماد في كل مرة. يحقق Entra ID ذلك عبر إصدار رموز وصول يمكن إعادة استخدامها (ضمن سياق آمن) مع التطبيقات المتكاملة، بحيث تصبح الهوية “مركزية” والتطبيقات “تابعة” لهاويّة واحدة.

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

تشغيليًا، يُطبّق SSO حسب نوع التطبيق: تطبيقات SaaS غالبًا عبر SAML/OIDC، تطبيقات حديثة عبر OIDC/OAuth، وتطبيقات داخلية قد تتطلب Proxy أو تكاملات إضافية. نجاح SSO يتطلب تصميمًا دقيقًا لـ Claims، وتخطيطًا لسياسات Conditional Access، وضبط جلسات الدخول (Session controls) لتوازن بين الراحة والأمان.

🧪 مثال عملي:
موظف يسجل الدخول إلى بوابة Microsoft 365، ثم ينتقل إلى ServiceNow وSalesforce دون إدخال كلمة مرور مجددًا، لأن كل تطبيق موثّق مع Entra ID عبر SAML وتتم مشاركة جلسة المصادقة بشكل آمن.

🧩 السؤال 23: ما الفرق بين المصادقة (Authentication) والتفويض (Authorization) في Entra ID؟

🧠 الإجابة:
المصادقة تُجيب: “من أنت؟”، أما التفويض يُجيب: “ماذا يُسمح لك أن تفعل؟”. في Entra ID، المصادقة تنتج Token يحمل Claims، ثم تأتي مرحلة التفويض في التطبيق أو الخدمة التي تقرأ هذه الـ Claims وتقرر الصلاحيات وفق سياسات داخلية أو أدوار أو مجموعات.

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

في السياقات الحديثة، أصبح التفويض يعتمد أيضًا على سياق المصادقة: إذا تمت المصادقة عبر طريقة ضعيفة أو من جهاز غير ممتثل، قد يتم تقليل الصلاحيات أو حجب الوصول لتطبيقات معينة—وهذا تقاطع عملي بين Entra ID وConditional Access وخصائص التطبيقات.

🧪 مثال عملي:
مستخدم تم التحقق من هويته بنجاح (Authentication) لكنه لا يستطيع تحميل تقارير مالية لأن تطبيق التقارير يتحقق من كونه عضوًا في مجموعة “Finance-Readers” (Authorization).

🧩 السؤال 24: ما هي MFA ولماذا تعد ضرورية في Entra ID؟

🧠 الإجابة:
MFA أو “المصادقة متعددة العوامل” تضيف طبقة تحقق إضافية فوق كلمة المرور، مثل إشعار عبر تطبيق Microsoft Authenticator أو مفتاح أمان FIDO2 أو رسالة نصية (مع أن SMS أقل تفضيلًا من منظور الأمان). أهمية MFA تنبع من حقيقة أن كلمات المرور وحدها لم تعد كافية: التسريبات، التصيد، والهجمات الآلية تجعلها نقطة ضعف مزمنة.

في Entra ID، يمكن تطبيق MFA بطرق متعددة: تفعيل على مستوى المستخدم، أو عبر سياسات Conditional Access (المفضل مؤسسيًا)، أو عبر سياسات Security Defaults للبيئات الصغيرة. كما يمكن فرض MFA فقط في حالات مخاطرة معينة، أو عند الوصول لتطبيقات حساسة، أو عند الدخول من خارج الشبكة.

أمنيًا وتشغيليًا، يجب اختيار طرق MFA مقاومة للتصيد قدر الإمكان (مثل FIDO2 أو Certificate-based auth أو Passkeys عند توافرها)، وتطبيق سياسات تسجيل الأجهزة، وخطط استرداد آمنة (Break-glass accounts) مع مراقبة صارمة.

🧪 مثال عملي:
سياسة Conditional Access تفرض MFA على جميع المستخدمين عند الوصول إلى Exchange Online من خارج عناوين IP الموثوقة، بينما تسمح بالدخول دون MFA داخل الشبكة مع استمرار مراقبة المخاطر.

🧩 السؤال 25: ما المقصود بالمصادقة بدون كلمة مرور (Passwordless) في Entra ID؟

🧠 الإجابة:
Passwordless تعني التخلص من الاعتماد على كلمة المرور كنقطة تحقق أساسية، واستبدالها بطرق تحقق أقوى مثل مفاتيح FIDO2، Windows Hello for Business، أو المصادقة عبر تطبيق الهاتف بأسلوب يعتمد على مفاتيح تشفير (Cryptographic keys). الفكرة الاستراتيجية هنا: تقليل سطح الهجوم بالكامل لأن التصيد وسرقة كلمة المرور تصبح غير مجدية أو أقل تأثيرًا.

في Entra ID، تُدار المصادقة بدون كلمة مرور عبر سياسات طرق المصادقة (Authentication Methods) وربطها بسياسات الوصول المشروط. النجاح الحقيقي لـ Passwordless يتطلب نضجًا في إدارة الأجهزة، لأن الجهاز يصبح جزءًا من عامل الثقة. لذلك غالبًا ما يرتبط التطبيق الناجح بـ Intune وامتثال الأجهزة (Device compliance).

اعتبارات الأمان تشمل: إدارة فقدان الأجهزة، سياسات إعادة التسجيل، حماية الحسابات الإدارية، ووجود حسابات “كسر زجاج” (Break-glass) تستخدم فقط للطوارئ وبضوابط صارمة.

🧪 مثال عملي:
تجهيز موظفي الإدارة العليا بمفاتيح FIDO2، وربط الوصول لتطبيقات حساسة بشرط استخدام FIDO2 فقط، مع حظر المصادقة بكلمة مرور لتلك التطبيقات.

🧩 السؤال 26: ما هو Conditional Access وكيف يعمل كطبقة تحكم استراتيجية؟

🧠 الإجابة:
Conditional Access هو “محرك سياسات” في Entra ID يتخذ قرار منح أو منع الوصول بناءً على شروط (Conditions) وضوابط (Controls). الشروط قد تشمل: هوية المستخدم/المجموعة، التطبيق، الموقع، حالة الجهاز، نوع العميل (Browser/Modern auth)، مستوى المخاطر، وأحيانًا حساسية البيانات. أما الضوابط فتشمل: طلب MFA، فرض جهاز ممتثل، فرض تطبيقات معتمدة، تقييد الجلسة، أو الحظر الكامل.

قيمة Conditional Access ليست فقط في المنع، بل في “التمكين الآمن”: السماح بالوصول لكن بشروط ترفع مستوى الثقة. وهذا يتوافق مباشرة مع Zero Trust. على المستوى التشغيلي، نجاحه يعتمد على تصميم سياسات تدريجي: البدء بسياسات أساسية (MFA للجميع)، ثم سياسات لتطبيقات عالية الحساسية، ثم توسيعها لسلوكيات ومخاطر متقدمة.

اعتبارات التشغيل تشمل اختبار السياسات (What If)، استخدام وضع التقارير (Report-only) قبل الإلزام، وتجنب انقطاع الخدمة عبر حسابات الطوارئ والاستثناءات المدروسة بعناية. أمنيًا، يجب مقاومة “ثقوب الاستثناءات” التي تصبح مع الوقت أبوابًا خلفية.

🧪 مثال عملي:
سياسة تمنح الوصول إلى SharePoint للجميع، لكنها تفرض جهازًا ممتثلًا + MFA عند تنزيل ملفات مصنفة “Confidential”، وتمنع التنزيل تمامًا من أجهزة غير مُدارة عبر Session Controls.

🧩 السؤال 27: ما الفرق بين تفعيل MFA على مستوى المستخدم وبين فرضه عبر Conditional Access؟

🧠 الإجابة:
تفعيل MFA على مستوى المستخدم (Per-user MFA) هو أسلوب قديم نسبيًا: إما أن المستخدم “يجب عليه” استخدام MFA دائمًا أو لا. لا يراعي السياق، ولا يقدم مرونة دقيقة للتطبيقات أو المخاطر. أما فرض MFA عبر Conditional Access فهو الأسلوب المؤسسي الحديث لأنه سياقي (Context-aware) وقابل للتدرج والإدارة المركزية.

عبر Conditional Access يمكنك فرض MFA فقط عند ظروف محددة: خارج الشبكة، عند مخاطرة عالية، عند الوصول لتطبيق محدد، أو عند عدم امتثال الجهاز. كما يمكنك تطبيق استثناءات منظمة ومراجعتها، وتسجيل كل شيء في سجلات السياسات.

من منظور الحوكمة، Conditional Access يسمح بتصميم مصفوفة سياسات واضحة قابلة للتدقيق والامتثال، بينما Per-user MFA قد يخلق تباينات غير مبررة بين المستخدمين ويصعب توثيق سببها.

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

🧩 السؤال 28: كيف تُصمَّم سياسات Conditional Access دون التسبب في انقطاع الخدمة؟

🧠 الإجابة:
تصميم سياسات Conditional Access يحتاج منهجية هندسية دقيقة لتجنب “Lockout” الذي قد يشل المؤسسة. تبدأ المنهجية بتحديد “خط أساس” (Baseline): من هم المستخدمون، ما التطبيقات، ما الأنماط الشائعة للدخول، وما الأجهزة المستخدمة. ثم تُبنى السياسات تدريجيًا: سياسة MFA عامة، ثم سياسات للتطبيقات الحساسة، ثم سياسات للأجهزة غير الممتثلة، ثم سياسات للمخاطر.

تشغيليًا، أدوات مثل Report-only وWhat If تتيح اختبار تأثير السياسة قبل فرضها. كما أن وجود حسابات Break-glass مستثناة من سياسات Conditional Access مع MFA قوي وسجلات مراقبة صارمة يعد شرطًا أساسيًا.

أمنيًا، يجب تجنب الاستثناءات الواسعة (مثل استثناء “كل VPN” دون ضوابط) وإدارة عناوين IP الموثوقة بحذر، وتقييم تأثير السياسات على حسابات الخدمة والتطبيقات القديمة التي لا تدعم Modern Auth.

🧪 مثال عملي:
تفعيل سياسة MFA للجميع في وضع Report-only لمدة أسبوع، وتحليل السجلات لمعرفة التطبيقات التي ستتأثر، ثم معالجة الاستثناءات الفنية فقط، وبعدها تحويل السياسة إلى On.

🧩 السؤال 29: ما هو Legacy Authentication ولماذا يجب حظره؟

🧠 الإجابة:
Legacy Authentication يشير إلى طرق مصادقة قديمة مثل Basic Auth التي تعتمد على إرسال اسم المستخدم وكلمة المرور مباشرة، وغالبًا لا تدعم MFA أو ضوابط Conditional Access الحديثة. هذه الطرق تُعد هدفًا رئيسيًا لهجمات Password Spray وCredential Stuffing لأنها سهلة الاستغلال وآلية.

حظر Legacy Auth يعد من أكثر الخطوات تأثيرًا في رفع الأمان بسرعة، لكنه يتطلب جردًا للتطبيقات والعملاء القديمة التي ما زالت تستخدمها المؤسسة، وخطة انتقال إلى Modern Auth أو OAuth.

تشغيليًا، يتم الحظر عبر Conditional Access (منع “Other clients” أو “Legacy authentication clients”) مع مراقبة السجلات أولًا، ثم التنفيذ التدريجي. أمنيًا، أي استثناءات يجب أن تكون محدودة ومؤقتة مع خطة إغلاق واضحة.

🧪 مثال عملي:
تقرير سجلات الدخول يبين أن بعض الطابعات/الماسحات ترسل بريدًا عبر SMTP Basic Auth؛ يتم نقلها إلى حل حديث مثل SMTP AUTH مع ضوابط أو استخدام Relay داخلي، ثم حظر Basic Auth بالكامل.

🧩 السؤال 30: كيف تُدار جلسات الدخول (Sessions) والتحكم فيها ضمن Conditional Access؟

🧠 الإجابة:
إدارة الجلسات (Session Management) في Entra ID تعني التحكم في مدة وخصائص جلسة المستخدم بعد المصادقة. فحتى لو كانت المصادقة قوية، قد تكون الجلسة طويلة بما يسمح بإساءة الاستخدام في حال اختطافها أو ترك جهاز مفتوح. يوفر Conditional Access ضوابط جلسات مثل: تحديد تكرار تسجيل الدخول (Sign-in frequency)، فرض إعادة المصادقة، تقييد الجلسة عبر Microsoft Defender for Cloud Apps (MCAS) للتحكم في تنزيل البيانات، أو وضع قيود على الوصول من المتصفح.

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

اعتبارات أمنية وتشغيلية تشمل: فهم تأثير Sign-in frequency على تطبيقات الأجهزة المحمولة، توافق السياسات مع تطبيقات الطرف الثالث، وربط التحكم في الجلسة بمستوى حساسية البيانات وتصنيفها.

🧪 مثال عملي:
تطبيق HR يحتوي بيانات حساسة: تُفرض سياسة تُجبر المستخدم على إعادة المصادقة كل 8 ساعات، وتمنع تنزيل الملفات من المتصفح إلا على أجهزة ممتثلة، بينما تطبيق تواصل داخلي يسمح بجلسة أطول دون تعطيل العمل.

🧭 التطبيقات في Entra ID: App Registrations وEnterprise Applications والرموز (Tokens)

🧩 السؤال 31: ما الفرق بين App Registration وEnterprise Application في Entra ID؟

🧠 الإجابة:
يحدث خلط شائع بين مفهومي App Registration وEnterprise Application لأنهما يمثلان وجهين لنفس الكيان من منظورين مختلفين: منظور “تعريف التطبيق” ومنظور “استخدام التطبيق داخل المستأجر”.

App Registration هو تعريف التطبيـق (Application Object) في Entra ID: هنا تُعرّف هوية التطبيق نفسها، وتحدد نوعه (ويب/موبايل/خدمة/Daemon)، عناوين إعادة التوجيه (Redirect URIs)، الأسرار والشهادات، أذونات API (Microsoft Graph أو APIs أخرى)، وإعدادات الرموز (Token configuration) والـ Claims. بمعنى آخر: هذا هو المكان الذي تُنشئ فيه “هوية” للتطبيق كي يتمكن من طلب رموز والوصول للموارد.

أما Enterprise Application فهو تمثيل “النسخة التشغيلية” (Service Principal) داخل Tenant: هنا يتم التحكم في من يستطيع استخدام التطبيق، كيف يتم تعيين المستخدمين/المجموعات، ما نوع SSO المستخدم، وما السياسات الأمنية المطبقة عليه (Conditional Access، MFA، قيود الجلسة، إلخ). حتى تطبيقات SaaS الجاهزة من المعرض (Gallery) تُدار غالبًا من خلال Enterprise Applications، بينما قد يكون لها App Registration مملوك من طرف البائع وليس من طرفك.

تشغيليًا: إذا كنت تبني تطبيقًا داخليًا/مخصصًا، ستبدأ بـ App Registration ثم ستجد تلقائيًا Enterprise Application مرتبطًا به داخل Tenant. أمنيًا: التحكم الحقيقي بمن “يدخل” للتطبيق والقيود المفروضة يتم في Enterprise Application، بينما التحكم بمن “يصدر رموزًا” وكيف تُبنى هوية التطبيق يتم في App Registration.

🧪 مثال عملي:
تطبيق داخلي لإدارة العقود: 1) يقوم فريق التطوير بإنشاء App Registration لتحديد Redirect URI وإضافة شهادة وتحديد أذونات Graph. 2) يقوم فريق الأمن بفتح Enterprise Application لنفس التطبيق، ويعيّن الوصول لمجموعة “Legal-Users”، ويفرض Conditional Access يتطلب جهازًا ممتثلًا + MFA.

🧩 السؤال 32: متى أستخدم تطبيقات المعرض (Gallery) ومتى أحتاج لتطبيق مخصص؟

🧠 الإجابة:
تطبيقات المعرض (Enterprise Apps from Gallery) هي تكاملات جاهزة مع آلاف تطبيقات SaaS (مثل Salesforce وServiceNow وWorkday وغيرها). استخدام المعرض هو الخيار الأفضل عندما يكون التطبيق مدعومًا رسميًا لأنك تحصل على قوالب SSO مُختبرة، إرشادات إعداد قياسية، وأحيانًا تكوين Provisioning مُسبق. هذا يقلل الوقت والمخاطر التشغيلية، ويسهل استكشاف الأعطال لأن السيناريو معروف ومتوثّق.

أما التطبيق المخصص (Custom App) أو App Registration فهو مطلوب عندما: - لديك تطبيق داخلي/مطور داخليًا. - تريد تكامل OIDC/OAuth متقدم غير متوفر في قالب المعرض. - تحتاج إلى تعريف Claims خاصة أو نطاقات (Scopes) مخصصة. - تريد نموذج تفويض خاص (Application permissions/Daemon apps) أو تدفقات OAuth غير نمطية.

أمنيًا، تطبيقات المعرض تمنحك أساسًا قويًا، لكن لا تعفيك من تصميم سياسات الوصول المشروط وإدارة الوصول. التطبيقات المخصصة تعطيك مرونة أكبر لكنها تتطلب حوكمة أدق للـ secrets والشهادات والـ redirect URIs، وإلا تصبح نقطة اختراق سهلة.

🧪 مثال عملي:
- استخدام المعرض لدمج Salesforce عبر SAML خلال ساعات. - إنشاء App Registration لتطبيق داخلي (Web API) يحتاج Scope “contracts.read” و“contracts.write” وتطبيق Mobile Client يستخدم Authorization Code + PKCE.

🧩 السؤال 33: ما هي Service Principal ولماذا تعد محور الحوكمة للتطبيقات؟

🧠 الإجابة:
الـ Service Principal هو الكيان الذي يمثل “وجود التطبيق” داخل Tenant. إذا كان Application Object (App Registration) هو “المخطط/الهوية العامة” للتطبيق، فإن Service Principal هو “التنصيب/المثيل” الذي تستخدمه المؤسسة فعليًا للتحكم في الوصول.

أهمية Service Principal تكمن في أنه مكان تطبيق الحوكمة التشغيلية: تعيين المستخدمين والمجموعات، ضبط SSO، إدارة الموافقات (Consent) داخل Tenant، وربط التطبيق بسياسات Conditional Access. كما أنه يحمل سجلات النشاط والحقوق الفعلية داخل بيئتك.

أمنيًا، Service Principals قد تكون هدفًا خطيرًا لأن اختراقها يعني اختراق هوية تطبيق قد يملك أذونات واسعة (خصوصًا Application permissions). لذلك يجب مراقبة إنشاء Service Principals الجديدة، تطبيق سياسات Consent صارمة، واستخدام تنبيهات عند منح أذونات عالية الحساسية.

🧪 مثال عملي:
تطبيق “Backup Automation” يحصل على Service Principal داخل Tenant مع صلاحية قراءة البريد (Mail.Read). إذا تم تسريب secret الخاص به، يمكن للمهاجم سحب رسائل. الحل: استخدام شهادة بدل secret، تقليل الصلاحيات، وتفعيل تنبيهات على Graph API access.

🧩 السؤال 34: ما هي Identity Tokens وAccess Tokens وRefresh Tokens في Entra ID؟

🧠 الإجابة:
Entra ID يعتمد على الرموز (Tokens) لتفويض الوصول دون إعادة إرسال كلمة المرور. توجد ثلاثة أنواع أساسية:

1) ID Token: يُستخدم لإثبات هوية المستخدم للتطبيق (غالبًا مع OpenID Connect). يحتوي Claims مثل الاسم والبريد ومعرف المستخدم. لا يُستخدم للوصول إلى APIs عادة.

2) Access Token: يُستخدم للوصول إلى مورد/واجهة API (مثل Microsoft Graph أو API داخلي). يحمل نطاقات (Scopes) أو أدوار (Roles) تحدد ماذا يحق للعميل فعله.

3) Refresh Token: يُستخدم للحصول على Access Tokens جديدة دون إعادة إدخال بيانات الاعتماد، ضمن ضوابط أمان ومدة صلاحية محددة.

أمنيًا، Access Token قصير العمر يقلل المخاطر، بينما Refresh Token يمثل قيمة عالية للمهاجم لأنه يتيح استمرار الوصول. لذا تُستخدم سياسات مثل Conditional Access + Token protection + قيود الجلسة لتقليل إساءة الاستخدام.

🧪 مثال عملي:
تطبيق ويب يستخدم Authorization Code Flow: يحصل على ID Token لتسجيل دخول المستخدم، ثم Access Token لاستدعاء Graph لجلب بيانات، ثم يستخدم Refresh Token لتجديد Access Token دون مطالبة المستخدم بكلمة المرور مجددًا.

🧩 السؤال 35: ما المقصود بـ OAuth 2.0 Flows الأكثر شيوعًا في Entra ID؟

🧠 الإجابة:
تدفقات OAuth هي “طرق” قياسية للحصول على Tokens حسب نوع التطبيق. الأكثر شيوعًا في Entra ID: - Authorization Code + PKCE: الأفضل لتطبيقات الويب والموبايل الحديثة لأنه يقلل مخاطر اعتراض الكود. - Client Credentials: لتطبيقات الخدمة/الـ Daemon التي تعمل بدون مستخدم (Machine-to-machine). - On-Behalf-Of (OBO): عندما يستدعي API وسيط API آخر نيابة عن المستخدم مع الحفاظ على هوية المستخدم وسياق التفويض. - Device Code: للأجهزة محدودة الإدخال (مثل أجهزة غرف الاجتماعات).

اختيار التدفق قرار هندسي وأمني: التدفق الخاطئ قد يعرّض secrets للتسرب أو يتسبب في تصميم مصادقة ضعيف. تشغيليًا، يجب توثيق التدفق المستخدم، إدارة secrets والشهادات، وإضافة ضوابط CA تناسب نوع التدفق (مثل فرض جهاز ممتثل لتطبيقات المستخدمين).

🧪 مثال عملي:
- تطبيق موبايل داخلي: Authorization Code + PKCE. - خدمة أرشفة تعمل في الخلفية: Client Credentials مع شهادة في Key Vault بدل secret ثابت.

🧩 السؤال 36: ما الفرق بين Delegated Permissions وApplication Permissions؟

🧠 الإجابة:
Delegated Permissions تعني أن التطبيق يعمل “باسم مستخدم” (User context). صلاحياته مقيدة بما يملك المستخدم نفسه + ما تم منحه للتطبيق. هذا يناسب تطبيقات تفاعلية (Interactive) مثل تطبيقات الويب التي يستخدمها الموظفون.

أما Application Permissions فتعني أن التطبيق يعمل “ككيان مستقل” بدون مستخدم (App-only). هنا قد يحصل التطبيق على صلاحيات واسعة جدًا عبر موافقة مسؤول (Admin consent)، مثل قراءة جميع صناديق البريد أو جميع الملفات. لذلك تعتبر Application Permissions عالية الحساسية وتحتاج حوكمة صارمة.

أمنيًا، التفريق جوهري: delegated يقلل الأثر لأن هناك مستخدمًا وسياقًا، بينما app-only قد يتحول إلى “مفتاح رئيسي” إذا أسيء استخدامه. لذلك يجب تقييد app-only إلى الحد الأدنى، واستخدام شروط إضافية مثل قيود الشبكة، شهادات بدل أسرار، ومراقبة Graph usage.

🧪 مثال عملي:
- تطبيق بوابة موظفين يعرض ملفات المستخدم: Delegated Files.Read. - خدمة امتثال تقوم بفحص جميع ملفات المؤسسة ليلاً: Application Files.Read.All (بعد تقييم مخاطر وحوكمة ومراقبة صارمة).

🧩 السؤال 37: ما هو Consent ولماذا يمثل خطرًا إذا لم يُحكَم؟

🧠 الإجابة:
Consent هو عملية منح تطبيق ما الإذن للوصول إلى موارد المستخدم أو المؤسسة. قد يكون consent من المستخدم (User consent) لصلاحيات منخفضة، أو من المسؤول (Admin consent) لصلاحيات عالية. الخطر يظهر عندما يُسمح للمستخدمين بمنح تطبيقات غير موثوقة أذونات واسعة، ما يفتح الباب لهجمات “Consent Phishing” حيث يقنع المهاجم المستخدم بمنح تطبيق خبيث صلاحيات لقراءة البريد أو الملفات دون سرقة كلمة مرور أصلاً.

حوكمة Consent تتطلب: تحديد سياسات من يحق له منح الأذونات، تفعيل “Admin consent workflow” للموافقات، تقييد التطبيقات المسموح بها عبر Publisher verification وApp consent policies، ومراجعة دورية للتطبيقات الممنوحة أذونات. كما يجب ربط ذلك برصد مستمر (Monitoring) وتنبيهات عند منح أذونات حساسة.

🧪 مثال عملي:
مستخدم يتلقى بريدًا يطلب “تفعيل تطبيق تقارير” ويضغط موافقة على Mail.Read. إذا كانت سياسات المؤسسة تسمح User consent دون قيود، قد تُسرب رسائل. الحل: تعطيل User consent أو تقييده، وتفعيل Admin consent workflow بحيث يُراجع فريق الأمن الطلب قبل الموافقة.

🧩 السؤال 38: كيف تتم إدارة أسرار التطبيقات (Client Secrets) والشهادات بأمان؟

🧠 الإجابة:
أسرار التطبيقات (Client Secrets) هي كلمات مرور للتطبيقات، وهي من أكثر نقاط الضعف شيوعًا لأن كثيرًا من الفرق تخزنها في ملفات إعدادات أو مستودعات كود بالخطأ. أفضل نهج مؤسسي هو التحول إلى الشهادات أو Managed Identities حيثما أمكن، ثم وضع secrets ضمن خزائن أسرار (Secret vault) مثل Azure Key Vault مع سياسات وصول صارمة وتدوير دوري.

منهجية آمنة تشمل: 1) تقليل الاعتماد على secrets واستخدام شهادات قصيرة العمر أو Managed Identities. 2) فرض مدد صلاحية قصيرة + تدوير تلقائي (Automated rotation). 3) تطبيق Least Privilege على من يمكنه قراءة/تحديث secret. 4) مراقبة الاستخدام: أي استدعاء رموز من مواقع غير متوقعة يجب أن يولد تنبيهًا. 5) منع تسربها عبر DLP/Secret scanning في DevOps.

أمنيًا، تسريب secret لتطبيق يملك Application permissions يعني اختراق واسع. لذا يجب وجود إجراءات استجابة: إبطال secrets فورًا، إيقاف Service Principal مؤقتًا، مراجعة سجلات Graph، ثم إعادة الإصدار بأمان.

🧪 مثال عملي:
فريق DevOps ينقل secret الخاص بخدمة أتمتة من ملف appsettings.json إلى Azure Key Vault، ويمنح الخدمة Managed Identity لقراءة secret. يتم تدوير secret شهريًا تلقائيًا، مع تنبيه عند أي استخدام من IP غير معروف.

🧩 السؤال 39: كيف أتحكم في من يستطيع الوصول لتطبيق معين داخل Enterprise Applications؟

🧠 الإجابة:
التحكم في الوصول للتطبيق داخل Enterprise Applications يتم عبر مزيج من: - تعيين المستخدمين والمجموعات (Assignments): لا يتمكن من استخدام التطبيق إلا من تم تعيينه إذا كان خيار “Assignment required” مفعّلًا. - الأدوار داخل التطبيق (App roles): لتقسيم الصلاحيات داخل التطبيق نفسه وربطها بمجموعات. - Conditional Access: لإضافة شروط مثل MFA، جهاز ممتثل، مواقع موثوقة، أو حظر مناطق. - إعدادات SSO: لضمان أن الدخول يمر عبر Entra ID وليس بيانات محلية داخل التطبيق.

تشغيليًا، أفضل نمط هو “Access by group”: ربط التطبيق بمجموعة واحدة أو أكثر بدل تعيين المستخدمين فرديًا، لأن ذلك يسهل الأتمتة والمراجعة. أمنيًا، يجب توثيق سبب منح الوصول، وربط ذلك بمراجعات وصول دورية (Access Reviews) لتقليل تراكم الصلاحيات عبر الزمن.

🧪 مثال عملي:
تطبيق إدارة المشاريع: تفعيل Assignment required، ثم إنشاء مجموعتين “PM-Users” و“PM-Admins”، وربط كل مجموعة بـ App Role مختلف، وفرض MFA + جهاز ممتثل عند الدخول.

🧩 السؤال 40: ما هي أفضل الممارسات لحوكمة التطبيقات في Entra ID؟

🧠 الإجابة:
حوكمة التطبيقات في Entra ID ليست إعدادًا واحدًا بل “منظومة” تشمل السياسة، التشغيل، والمراقبة. أفضل الممارسات تشمل:

1) تقليل عدد التطبيقات والازدواجية عبر كتالوج موحد واعتماد رسمي. 2) تقييد Consent وتفعيل Admin consent workflow، وربط ذلك بالمراجعة الأمنية. 3) اعتماد الوصول عبر مجموعات بدل تعيينات فردية، وتطبيق Access Reviews. 4) حماية Service Principals عبر استخدام شهادات/Managed Identities وتدوير secrets. 5) تقليل Application permissions والتوثيق الرسمي لأي صلاحية عالية الحساسية. 6) فرض Conditional Access للتطبيقات الحساسة وإدارة الجلسات. 7) مراقبة السجلات والإنذارات على منح الأذونات، إنشاء SPNs جديدة، وارتفاعات غير طبيعية في استدعاءات Graph. 8) تصميم “مسار إنهاء” (Decommissioning) لأي تطبيق: إيقافه، إزالة الأذونات، وحذف الكيانات المرتبطة بعد فترة حفظ.

النتيجة المتوقعة هي تقليل مساحة الهجوم، منع الموافقات الخبيثة، وتسهيل الامتثال والتدقيق، مع الحفاظ على مرونة فرق الأعمال.

🧪 مثال عملي:
إنشاء لجنة اعتماد للتطبيقات: أي تطبيق جديد يمر بمراجعة أمنية تشمل نوع OAuth flow، نوع الأذونات، مكان تخزين الأسرار، وسياسات Conditional Access. بعد الموافقة يتم تسجيله في كتالوج داخلي وتحديد مالك (App Owner) ومسؤولية مراجعة فصلية.

🧭 Identity Protection وإدارة المخاطر والتحليل الأمني في Entra ID

🧩 السؤال 41: ما هو Microsoft Entra ID Identity Protection وما الهدف منه؟

🧠 الإجابة:
Microsoft Entra ID Identity Protection هو طبقة أمنية تعتمد على التحليلات والاستخبارات الأمنية (Security intelligence) لاكتشاف مخاطر الهوية المرتبطة بالمستخدمين وجلسات تسجيل الدخول، ثم تمكين المؤسسة من الاستجابة تلقائيًا أو يدويًا قبل أن تتحول المخاطر إلى اختراق فعلي. الفكرة الأساسية أن الهوية لم تعد ثابتة؛ بل تتأثر بسلوك المستخدم والبيئة المحيطة، وبالتالي يجب تقييم “احتمالية أن هذا الدخول غير شرعي” بشكل مستمر.

يوفر Identity Protection ثلاث زوايا تكاملية: 1) اكتشاف المخاطر (Detections) مثل التسريب، التصيد، أو نشاطات غير اعتيادية. 2) تقييم المخاطر على مستوى الدخول (Sign-in risk) وعلى مستوى المستخدم (User risk). 3) الاستجابة عبر سياسات آلية (Risk policies) أو دمج النتائج ضمن Conditional Access لإجبار MFA أو إعادة تعيين كلمة المرور أو الحظر.

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

🧪 مثال عملي:
يتم رصد دخول لموظف من دولة غير معتادة مع نمط Browser مختلف، فيصنف Sign-in risk كـ High. تُطبق سياسة آلية تجبر MFA فورًا، وإذا فشل، يتم حظر الجلسة وإرسال تنبيه إلى فريق SOC لبدء التحقيق.

🧩 السؤال 42: ما الفرق بين Sign-in Risk وUser Risk؟

🧠 الإجابة:
التمييز بين Sign-in Risk وUser Risk ضروري لبناء استجابة دقيقة دون تعطيل المستخدمين.

- Sign-in Risk يشير إلى احتمال أن “محاولة تسجيل دخول معينة” غير شرعية. بمعنى أن الخطر مرتبط بالجلسة الحالية: قد تكون محاولة من موقع غريب، جهاز غير مألوف، أو سلوك يشير لسرقة جلسة. هذا الخطر قد يكون مؤقتًا ويزول بعد انتهاء الجلسة أو التحقق.

- User Risk يشير إلى احتمال أن “حساب المستخدم نفسه” قد تم اختراقه أو تسريب بيانات اعتماده. هذا الخطر أكثر عمقًا واستمرارية لأنه لا يتعلق بمحاولة واحدة فقط، بل بإشارات تراكمية قد تعني أن كلمة المرور سُربت أو أن هناك نشاطًا متكررًا غير طبيعي.

من منظور تشغيل، sign-in risk غالبًا يُعالج بإجبار MFA أو حظر دخول محدد. أما user risk فقد يستدعي إجراءات أكثر صرامة مثل فرض إعادة تعيين كلمة المرور، تعطيل الحساب، أو تطبيق قيود وصول واسعة حتى يتم تأكيد سلامة الحساب. ومن منظور الأمان، الجمع بينهما يمنح صورة أدق: قد يكون sign-in منخفض لكن user risk مرتفع بسبب تسريب سابق—وهنا يجب عدم الاكتفاء بتقييم الدخول الحالي.

🧪 مثال عملي:
محاولة دخول من جهاز معتاد (Sign-in risk منخفض) لكن الحساب مصنف User risk عالي بسبب تسريب كلمة المرور في حادثة سابقة؛ فتقوم السياسة بفرض إعادة تعيين كلمة المرور قبل السماح بالوصول.

🧩 السؤال 43: ما هي أنواع اكتشافات المخاطر (Risk Detections) الشائعة؟

🧠 الإجابة:
Risk Detections هي “إشارات” تستنتجها أنظمة مايكروسوفت من أنماط الهجمات والذكاء الأمني. الأنواع الشائعة تشمل: - Leaked credentials: رصد بيانات اعتماد مسربة في مصادر معروفة (مثل قواعد بيانات مسربة) وربطها بحساباتك. - Atypical travel: تسجيل دخول من موقعين جغرافيين لا يمكن السفر بينهما بالزمن الطبيعي. - Unfamiliar sign-in properties: خصائص دخول غير معتادة (جهاز/متصفح/مزود شبكة) مقارنة بسلوك المستخدم المعتاد. - Anonymous IP address: استخدام شبكات إخفاء مثل Tor أو VPNs ذات سمعة سيئة. - Malware-linked IP address: عنوان IP مرتبط بنشاطات برمجيات خبيثة أو بوتنت. - Password spray / brute force indicators: أنماط محاولات متعددة على حسابات كثيرة أو تكرار فشل مريب.

أهمية هذه الاكتشافات أنها لا تعتمد على “حدث واحد”، بل على تجميع إشارات متعددة وتحليلها. لكن يجب إدراك أن بعضها قد ينتج إيجابيات كاذبة (False positives)، لذا يجب ربطها بسياسات تصعيد متدرجة، ومراعاة طبيعة العمل (مثلاً فرق السفر أو العمل عن بُعد).

🧪 مثال عملي:
موظف في قسم المبيعات يسافر كثيرًا؛ بدل حظر atypical travel مباشرة، تُفرض MFA + Sign-in frequency أقصر عند الدخول من دول جديدة لأول مرة، ثم تُخفف القيود بعد تكرار السلوك الآمن.

🧩 السؤال 44: كيف يتم بناء سياسات المخاطر (Risk Policies) في Identity Protection؟

🧠 الإجابة:
سياسات المخاطر في Identity Protection تهدف لتحويل تقييم المخاطر إلى أفعال قابلة للتنفيذ تلقائيًا. غالبًا هناك سياستان محوريتان: 1) Sign-in risk policy: تحدد ماذا يحدث عند ارتفاع خطر تسجيل دخول معين (مثل طلب MFA أو الحظر). 2) User risk policy: تحدد ماذا يحدث عند ارتفاع خطر المستخدم (مثل فرض تغيير كلمة المرور).

منهجية البناء التشغيلية تبدأ بتحديد: - من تشملهم السياسة؟ (كل المستخدمين، باستثناء حسابات الطوارئ، أو باستثناء حسابات الخدمة) - ما مستوى المخاطر الذي يستدعي الإجراء؟ (Medium/High) - ما الإجراء؟ (Require MFA / Block access / Require password change) ثم تأتي مرحلة الاختبار والمراقبة: تفعيلها تدريجيًا، تحليل تأثيرها، ثم توسيع نطاقها.

اعتبارات الأمان: يجب حماية حسابات Break-glass وعدم وضعها تحت نفس السياسات التي قد تمنع الوصول عند وقوع حادثة واسعة. كما يجب ربط سياسات المخاطر بـ Conditional Access لتطبيق ضوابط إضافية مثل الجهاز الممتثل أو المواقع الموثوقة.

🧪 مثال عملي:
سياسة Sign-in risk: إذا كان High → Block. إذا كان Medium → Require MFA. وسياسة User risk: إذا كان High → Require password change. ثم يتم مراقبة عدد الحالات أسبوعيًا لتقييم الإيجابيات الكاذبة وضبط الحدود.

🧩 السؤال 45: كيف يندمج Identity Protection مع Conditional Access؟

🧠 الإجابة:
التكامل بين Identity Protection وConditional Access هو ما يحول تقييم المخاطر إلى قرار وصول ديناميكي. في Conditional Access يمكن استخدام “User risk” و“Sign-in risk” كشرط (Condition)، ثم فرض ضوابط مثل MFA أو حظر الوصول أو فرض جهاز ممتثل.

القيمة هنا أن المؤسسة لا تضطر إلى بناء كل منطق المخاطر بنفسها؛ بل تستخدم إشارات Microsoft، ثم تدمجها في سياسات وصول موحدة عبر التطبيقات. هذا يجعل الاستجابة “متسقة” عبر Microsoft 365 وAzure والتطبيقات المخصصة.

تشغيليًا، يُنصح بتصميم سياسات على طبقتين: - طبقة أساسية: MFA للجميع + حظر Legacy Auth. - طبقة مخاطر: إذا Medium/High risk → تشديد إضافي (MFA أقوى، حظر، أو إعادة مصادقة متكررة). أمنيًا، يجب مراقبة الحوادث التي تتكرر مع مستخدمين محددين وتحويلها إلى تحقيقات، لأن المخاطر قد تشير إلى جهاز مصاب أو حملة تصيد.

🧪 مثال عملي:
سياسة Conditional Access لتطبيق مالي: إذا كان Sign-in risk Medium أو أعلى → Require phishing-resistant MFA (مثل FIDO2). إذا High → Block. بينما للتطبيقات منخفضة الحساسية يتم الاكتفاء بـ MFA التقليدي عند Medium.

🧩 السؤال 46: ما دور سجلات تسجيل الدخول (Sign-in Logs) في التحقيقات الأمنية؟

🧠 الإجابة:
سجلات تسجيل الدخول في Entra ID هي “صندوق أسود” لكل محاولة وصول: تحتوي على هوية المستخدم، الوقت، التطبيق، نوع العميل، عنوان IP، الموقع التقريبي، حالة الجهاز، نتيجة Conditional Access، وأسباب السماح/المنع. هذه السجلات تمثل الأساس لأي تحقيق أمني لأنها تجيب عمليًا على: من دخل؟ من أين؟ كيف؟ وهل تم تجاوز سياسات؟ وما الذي تغيّر؟

منهجية التحقيق تبدأ عادة بـ: 1) تحديد الحساب/التطبيق المتأثر. 2) استخراج آخر محاولات الدخول، وفرزها حسب النجاح والفشل. 3) مقارنة خصائص الدخول المعتادة مقابل الشاذة (IP، جهاز، عميل، دولة). 4) فحص قرارات Conditional Access لمعرفة هل تم فرض MFA وهل نجحت؟ 5) توسيع البحث إلى سجلات التدقيق (Audit logs) لمعرفة إن حدث تغيير في الأذونات أو إنشاء تطبيق أو منح Consent.

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

🧪 مثال عملي:
عند الاشتباه باختراق، يلاحظ فريق SOC في Sign-in logs دخولًا ناجحًا من IP مجهول لتطبيق Exchange Online بدون MFA (بسبب Legacy Auth). يتم فورًا حظر Legacy Auth، إعادة تعيين كلمة المرور، ومراجعة البريد الصادر للتحقق من وجود رسائل تصيد داخلية.

🧩 السؤال 47: ما الفرق بين Sign-in Logs وAudit Logs؟

🧠 الإجابة:
الفرق جوهري في الهدف: - Sign-in Logs توثّق محاولات تسجيل الدخول والوصول (Authentication events). - Audit Logs توثّق التغييرات الإدارية والتغييرات على الكيانات (Change events) مثل إنشاء مستخدم، تغيير دور، إضافة تطبيق، تعديل سياسة Conditional Access، أو منح Admin consent.

في أي حادثة أمنية، تحتاج الاثنين معًا: قد ترى في Sign-in logs دخولًا مشبوهًا، لكن Audit logs تكشف أن المهاجم بعد دخوله قام بمنح تطبيق خبيث صلاحيات أو أنشأ حسابًا جديدًا أو عدّل سياسة.

تشغيليًا، Audit logs مهمة للامتثال والتدقيق (Who changed what and when)، ولتتبع أخطاء الإعداد. أمنيًا، أي تغيير حساس (مثل تعطيل MFA أو إضافة استثناءات واسعة) يجب أن يولد تنبيهًا، لأن الهجمات الحديثة غالبًا تركز على “تغيير الضوابط” بدلًا من اختراق البيانات مباشرة.

🧪 مثال عملي:
تسجيل دخول ناجح مشبوه يظهر في Sign-in logs. عند فحص Audit logs تجد أنه بعده بدقائق تم إنشاء Enterprise App جديد ومنحه Mail.Read.All عبر Admin consent—هذه إشارة قوية لهجوم Consent أو سيطرة على مسؤول.

🧩 السؤال 48: كيف أتعامل مع الإيجابيات الكاذبة (False Positives) في تقييم المخاطر؟

🧠 الإجابة:
الإيجابيات الكاذبة واردة لأن تقييم المخاطر يعتمد على إشارات قد تتداخل مع سلوك عمل مشروع (مثل السفر، استخدام VPN مؤسسي، أو تبديل الأجهزة). التعامل الاحترافي معها لا يعني تعطيل الحماية، بل بناء نهج معايرة (Tuning) يُحافظ على الأمن ويقلل الانقطاع.

منهجية المعايرة تشمل: 1) جمع الحالات المتكررة وتحليل نمطها (أي المستخدمين/البلدان/التطبيقات). 2) تعديل السياسات لتكون متدرجة: بدل Block عند Medium، اجعلها Require MFA. 3) تحسين “الأصول الموثوقة” مثل Named locations للشبكات المؤسسية أو عناوين IP للـ VPN. 4) زيادة الاعتماد على إشارات الجهاز (Compliance/Hybrid join) بدل الاعتماد على الموقع فقط. 5) تدريب المستخدمين على إجراءات تحقق سلسة بدل فتح استثناءات واسعة.

أمنيًا، أخطر خطأ هو معالجة false positives عبر استثناءات عامة (مثل استثناء دولة كاملة أو تعطيل Risk شرطًا)، لأن ذلك يفتح ثغرة دائمة. الأفضل استثناءات دقيقة جدًا ومؤقتة مع خطة إصلاح.

🧪 مثال عملي:
فريق هندسي يعمل من مواقع متعددة باستخدام VPN: بدل تعطيل “Anonymous IP” للجميع، يتم تعريف IPs الخاصة بالـ VPN كـ Named location موثوق، وتُفرض MFA عند أي IP خارج هذا النطاق، مع استمرار مراقبة أي سلوك غير طبيعي.

🧩 السؤال 49: ما هي الهجمات الشائعة التي يستهدف بها المهاجمون Entra ID وكيف تُواجه؟

🧠 الإجابة:
أكثر الهجمات شيوعًا على Entra ID تتمحور حول سرقة الهوية أو إساءة استخدام التفويض بدل كسر التشفير. أبرزها: - Password spray: تجربة كلمات مرور شائعة على عدد كبير من الحسابات. المواجهة: MFA، Smart lockout، مراقبة الفشل، وحظر Legacy Auth. - Phishing / AiTM: التصيد أو اعتراض الجلسة عبر “Proxy” لسرقة cookies/tokens. المواجهة: MFA مقاومة للتصيد (FIDO2/WHfB)، سياسات جلسات، وDefender. - Consent phishing: خداع المستخدم للموافقة على تطبيق خبيث. المواجهة: تقييد consent وAdmin workflow. - Token theft: سرقة Refresh tokens أو جلسات من جهاز مصاب. المواجهة: جهاز ممتثل، تقليل session lifetime، وتقييم المخاطر. - Privilege escalation: استهداف حسابات إدارية أو PIM. المواجهة: PIM، فصل الحسابات، ومراجعات أدوار.

النهج الاستراتيجي لمواجهتها هو طبقات دفاع: تقوية المصادقة، تقييد التفويض، حماية الأجهزة، ثم مراقبة وتحليلات مع استجابة سريعة. تشغيليًا يجب بناء Runbooks واضحة: ماذا نفعل عند User risk High؟ ماذا نفعل عند اكتشاف تطبيق جديد بأذونات عالية؟

🧪 مثال عملي:
رصد ارتفاع فشل تسجيل الدخول على مئات الحسابات خلال دقائق (Password spray). يتم تفعيل حظر مؤقت من خلال سياسات، وتطبيق MFA الإجباري، ورفع تنبيه إلى SIEM، ثم إلزام تغيير كلمات المرور للحسابات المتأثرة.

🧩 السؤال 50: كيف تُبنى استراتيجية مراقبة (Monitoring) فعّالة لـ Entra ID؟

🧠 الإجابة:
بناء استراتيجية مراقبة فعّالة لـ Entra ID يعني الانتقال من “تجميع السجلات” إلى “قرارات قابلة للتنفيذ” عبر مؤشرات وإنذارات مرتبطة بالمخاطر. الأساس يبدأ بتحديد ما الذي يهم المؤسسة: الحسابات الإدارية، التطبيقات ذات الأذونات العالية، محاولات الدخول من دول غير معتادة، تغييرات Conditional Access، ومنح Admin consent.

منهجية التشغيل تشمل: 1) تجميع البيانات: تصدير Sign-in logs وAudit logs وRisk events إلى SIEM (مثل Microsoft Sentinel). 2) بناء قواعد إنذار: مثل “Admin consent جديد لصلاحية عالية”، “تعطيل MFA/CA policy”، “ارتفاع فشل الدخول”، “تسجيل دخول ناجح بدون MFA لتطبيق حساس”. 3) تحديد خطوط الأساس (Baselines): ما هو السلوك الطبيعي؟ عدد الدخول اليومي؟ الدول المعتادة؟ 4) استجابة آلية: عبر playbooks (Logic Apps) لتعطيل حساب أو إبطال جلسات عند شروط محددة. 5) تحسين مستمر: مراجعة الإنذارات شهريًا لتقليل الضوضاء وتحسين الدقة.

اعتبارات أمنية: يجب مراقبة “القرارات” وليس الأحداث فقط—أي مراقبة نتيجة Conditional Access وIdentity Protection لأنها تعكس المهاجمين الذين يحاولون الالتفاف. كذلك ينبغي تأمين حسابات المراقبة نفسها، وتطبيق فصل للمهام حتى لا يستطيع مهاجم تعطيل السجلات بسهولة.

🧪 مثال عملي:
تكوين Microsoft Sentinel لالتقاط كل Audit event خاص بتغيير سياسات Conditional Access. إذا حدث تعديل يتضمن إضافة استثناء “All users” أو تعطيل شرط MFA، يتم إنشاء Incident تلقائيًا، وإرسال رسالة إلى فريق SOC، وتشغيل Playbook يعيد السياسة لوضعها السابق لحين المراجعة.

🧭 التعاون الخارجي B2B وإدارة الضيوف والشركاء في Entra ID

🧩 السؤال 51: ما هو Entra ID B2B Collaboration ولماذا تحتاجه المؤسسات؟

🧠 الإجابة:
Entra ID B2B Collaboration هو نموذج تعاون يتيح للمؤسسات مشاركة التطبيقات والموارد (مثل Microsoft Teams وSharePoint وتطبيقات SaaS أو التطبيقات الداخلية) مع مستخدمين من خارج المؤسسة—مثل الموردين، الشركاء، المستشارين، أو العملاء المؤسسيين—مع الحفاظ على ضوابط الأمان والحوكمة داخل Tenant الخاص بك. الفكرة الاستراتيجية هي تمكين التعاون دون إنشاء حسابات داخلية كاملة أو التنازل عن السيطرة، بحيث يبقى “قرار الوصول” بيد المؤسسة المضيفة.

يتميّز B2B بأنه يعتمد على “هوية خارجية” غالبًا (External Identity) بينما يتم إنشاء كيان ضيف (Guest) في Tenant المضيف لتطبيق السياسات عليه. هذا يسمح بتطبيق Conditional Access وMFA ومتطلبات الجهاز وإدارة الجلسات حتى لو كان المستخدم ينتمي إلى مؤسسة أخرى. كما يتيح تطبيق مبدأ أقل الامتيازات وفصل الموارد بدقة، بدل مشاركة بيانات حساسة عبر قنوات غير خاضعة للحوكمة.

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

🧪 مثال عملي:
شركة تقنية تتعاون مع شركة استشارات لمدة 6 أشهر. بدل إنشاء حسابات داخلية كاملة، يتم دعوة الاستشاريين كـ Guests، ومنحهم الوصول إلى فريق Teams وموقع SharePoint للمشروع فقط، مع فرض MFA عند كل دخول ومنع التنزيل من أجهزة غير مُدارة.

🧩 السؤال 52: ما الفرق بين Guest وMember في Entra ID وكيف يؤثر على الصلاحيات؟

🧠 الإجابة:
الفرق بين Member وGuest
تشغيليًا، استخدام Guest يسهّل تطبيق سياسات منفصلة: سياسات Conditional Access خاصة بالضيوف، سياسات تسجيل/موافقة أكثر صرامة، ومراجعات وصول مركّزة. أمنيًا، يجب اعتبار الضيف كـ “هوية عالية المخاطر بطبيعتها” لأن المؤسسة لا تملك نفس مستوى التحكم في جهازه وبيئته، لذا يجب تعويض ذلك بضوابط أقوى: MFA، تقييد الجلسة، وحصر الوصول في موارد محددة.

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

🧪 مثال عملي:
مستخدم خارجي كـ Guest يمكنه الوصول لمجلد SharePoint محدد فقط ولا يستطيع استعراض الدليل الداخلي أو رؤية مجموعات المؤسسة، بينما Member داخلي يمكنه العثور على فرق Teams متعددة ورؤية بيانات أكثر في الدليل.

🧩 السؤال 53: كيف تتم دعوة الضيوف (Guest Invitation) وما الخيارات المتاحة؟

🧠 الإجابة:
دعوة الضيوف في Entra ID يمكن أن تتم بعدة طرق: عبر بوابة Entra، عبر Microsoft Teams/SharePoint مباشرة، أو آليًا عبر Microsoft Graph API. عند إرسال الدعوة، يتم إنشاء كيان Guest في Tenant المضيف، ويُرسل للمستخدم رابط دعوة لإكمال القبول وربط الهوية الخارجية بالضيف.

تتيح المؤسسة ضبط إعدادات الدعوة: من يمكنه دعوة الضيوف (المستخدمون، المسؤولون فقط، أو أدوار محددة)، ما هي المجالات المسموح بها (Allow/Block list)، هل يُسمح بإعادة توجيه الدعوات، وكيف يتم التعامل مع ضيوف لديهم Microsoft Account مقابل حسابات عمل (Work accounts).

تشغيليًا، أفضل نهج هو جعل الدعوة “مؤتمتة ومُقيدة” عبر عمليات خدمة (مثل طلب وصول) بدل دعوات فردية عشوائية، بحيث يتم توثيق سبب الدعوة والمالك المسؤول عنها. أمنيًا، يجب منع الدعوات غير المنضبطة لأنها قد تفتح بابًا لتسريب البيانات عبر مشاركة غير مقصودة.

🧪 مثال عملي:
إنشاء نموذج طلب وصول للشركاء: عند الموافقة، يقوم Workflow (Graph API) بدعوة الضيف، إضافته لمجموعة مشروع محددة، وتطبيق سياسة Conditional Access خاصة بالضيوف تلقائيًا.

🧩 السؤال 54: ما هي Cross-tenant access settings ولماذا تعد جوهرية في B2B؟

🧠 الإجابة:
Cross-tenant access settings هي إعدادات متقدمة تتحكم في كيفية التعاون بين Tenants مختلفة ضمن B2B. بدل الاعتماد فقط على إعدادات عامة للضيوف، تسمح هذه الإعدادات بتحديد سياسات منفصلة لكل مؤسسة شريكة (Partner tenant): ما الذي تقبله من Claims وماذا تشترط في المصادقة، وهل تثق بـ MFA من الطرف الآخر، وكيف تتعامل مع الأجهزة الممتثلة في Tenant الشريك.

القيمة الاستراتيجية هنا هي الانتقال من “دعوة أفراد” إلى “علاقة مؤسسة بمؤسسة” (Org-to-Org). يمكنك بناء قواعد: السماح بالتعاون مع Tenant معين فقط، حظر Tenants أخرى، أو فرض شروط إضافية إذا كان Tenant الشريك لا يطبق MFA.

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

🧪 مثال عملي:
شركة “أ” تتعاون دائمًا مع شركة “ب”. يتم إعداد Cross-tenant policy بحيث يُسمح فقط لمستخدمي Tenant “ب” بالدخول كضيوف، مع شرط أن تكون MFA مفعّلة لديهم. أي مستخدم من Tenant آخر يُحظر تلقائيًا.

🧩 السؤال 55: ما مفهوم “Trust settings” مثل MFA Trust وDevice Trust بين المستأجرين؟

🧠 الإجابة:
ضمن Cross-tenant access settings يمكن تحديد “ماذا تثق به” من طرف Tenant الشريك. على سبيل المثال: - MFA trust: هل تقبل أن المستخدم قام بـ MFA في Tenantه الأصلي فتعتبره كافيًا، أم تفرض MFA إضافية في Tenantك؟ - Device trust: هل تقبل إشارات امتثال الجهاز أو Hybrid join من Tenant الشريك؟

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

أمنيًا، Device trust أكثر حساسية لأن امتثال جهاز في Tenant آخر قد لا يتطابق مع معاييرك، لذا يجب وضع ذلك ضمن عقود ومعايير واضحة (مثل التوافق مع CIS أو وجود EDR)، أو الاكتفاء بفرض ضوابط جلسة تمنع التنزيل.

🧪 مثال عملي:
قبول MFA من Tenant شريك كبير لديه سياسات صارمة، لكن عدم قبول Device compliance منه، ثم فرض “منع تنزيل الملفات” للضيوف إلا من أجهزة مُدارة ضمن Tenantك.

🧩 السؤال 56: كيف أؤمّن وصول الضيوف عبر Conditional Access دون تعطيل التعاون؟

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

منهجية عملية: 1) تصنيف التطبيقات والبيانات: منخفضة/متوسطة/عالية الحساسية. 2) سياسات خط أساس للضيوف: فرض MFA، حظر Legacy Auth، تقييد الدخول من دول عالية الخطورة. 3) سياسات للبيانات الحساسة: فرض جهاز ممتثل (إن أمكن) أو تطبيق قيود جلسة تمنع التنزيل والنسخ عبر Defender for Cloud Apps. 4) تدرج في التنفيذ: Report-only ثم إلزام. 5) إدارة الاستثناءات بعناية ومدة محددة.

اعتبارات أمنية: الضيوف غالبًا يستخدمون أجهزة لا تديرها مؤسستك، لذا يجب التعويض بسياسات جلسات تمنع تسريب البيانات، وتطبيق Time-bound access عبر PIM/Access reviews إن أمكن، وربط الوصول بالمجموعات وليس التعيين الفردي.

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

🧩 السؤال 57: ما هي Access Reviews للضيوف وكيف تمنع تراكم الوصول؟

🧠 الإجابة:
Access Reviews هي آلية حوكمة ضمن Entra (Governance) تُستخدم لمراجعة من يملك حق الوصول إلى مجموعات/تطبيقات/موارد خلال فترة زمنية، مع طلب قرار صريح: إبقاء الوصول أو إزالته. للضيوف تحديدًا، Access Reviews تمثل حلًا حاسمًا لأن الضيوف مرتبطون بمشاريع تنتهي، لكن حساباتهم تبقى ما لم تتم مراجعتها.

منهجية التطبيق تشمل تحديد: نطاق المراجعة (مجموعات مشروع، تطبيق معين، Teams)، وتواترها (شهري/ربع سنوي)، ومن يراجع (مالك المورد، مدير المشروع، أو مدير المستخدم). ثم تحديد الإجراء التلقائي: إذا لم يتم الرد، هل يُزال الوصول تلقائيًا؟ غالبًا يُنصح بالإزالة تلقائيًا بعد تذكيرات واضحة لتقليل المخاطر.

أمنيًا، Access Reviews تمنع ظاهرة “الزحف الصلاحي” (Access creep) وتحد من الحسابات اليتيمة. وتشغيليًا، تحسن الامتثال لأنها توفر سجلات تدقيق تثبت أن المؤسسة راجعت الوصول بانتظام.

🧪 مثال عملي:
مراجعة شهرية لمجموعة “Project-X-Guests”: يتم إرسال طلب لمدير المشروع لتأكيد من لا يزال يحتاج الوصول. من لم يعد مطلوبًا تتم إزالته تلقائيًا، ومن لا يرد خلال 7 أيام يتم سحب وصوله كإجراء افتراضي.

🧩 السؤال 58: كيف أتعامل مع الضيوف القدامى (Stale Guests) وتنظيفهم بأمان؟

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

منهجية تنظيف آمنة تشمل: 1) إعداد تقرير دوري للضيوف الذين لم يسجلوا دخولًا خلال 60/90/180 يومًا. 2) التحقق من وجود Assignments أو عضوية مجموعات حساسة. 3) إرسال إشعار للمالك/مدير المورد لتأكيد الحاجة. 4) تعطيل الحساب أولًا (Soft disable) لفترة “حجر” (Quarantine) قبل الحذف النهائي. 5) توثيق القرارات لأغراض الامتثال.

أمنيًا، يُفضّل أتمتة العملية عبر سياسات/Workflows مع استثناءات منظمة للضيوف الاستراتيجيين (شراكات طويلة). وتشغيليًا، يجب تجنب الحذف العشوائي الذي قد يقطع شراكات قائمة دون علم الفرق.

🧪 مثال عملي:
سياسة تنظيف ربع سنوية: أي Guest بلا تسجيل دخول لـ 120 يومًا يُنقل إلى حالة Disabled، وإذا لم تظهر حاجة خلال 30 يومًا إضافية يتم حذفه، مع إرسال قائمة لمالكي المشاريع قبل التنفيذ.

🧩 السؤال 59: ما المخاطر الخاصة بالضيوف وكيف تُخفَّف عمليًا؟

🧠 الإجابة:
مخاطر الضيوف تختلف عن مخاطر المستخدمين الداخليين لأنها ترتبط بعدم التحكم الكامل في بيئتهم. أبرز المخاطر: - أجهزة غير مُدارة قد تكون مصابة أو غير محدثة. - هوية خارجية ضعيفة (Tenant شريك دون MFA) أو حساب شخصي Microsoft Account. - تراكم الوصول بعد انتهاء المشاريع. - سوء مشاركة البيانات (Share oversharing) داخل Teams/SharePoint. - التصيد عبر التعاون باستخدام روابط ومشاركات تبدو شرعية.

التخفيف عمليًا يتم عبر طبقات: 1) تفضيل حسابات عمل من Tenants موثوقة بدل حسابات شخصية. 2) فرض MFA دائمًا للضيوف، ومعالجة AiTM عبر مصادقة مقاومة للتصيد للتطبيقات الحساسة. 3) تقييد الجلسات (منع تنزيل/نسخ) للبيانات الحساسة. 4) تطبيق Access Reviews وتنظيف Stale guests. 5) تدريب المستخدمين الداخليين على مشاركة آمنة وتحديد مالكي الموارد المسؤولين.

أمنيًا، يجب أن تكون هناك “سياسة تعاون” مؤسسية تحدد من يحق له دعوة الضيوف، ما الموارد المسموح مشاركتها، وما متطلبات الأمن، وإلا يتحول التعاون إلى قناة تسريب بيانات.

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

🧩 السؤال 60: ما أفضل الممارسات لبناء نموذج حوكمة متكامل للتعاون الخارجي؟

🧠 الإجابة:
نموذج الحوكمة المتكامل للتعاون الخارجي يجمع بين السياسة والتنفيذ والمراقبة. أفضل الممارسات تشمل:

1) تصنيف الشركاء (موثوق/شبه موثوق/غير موثوق) وربط كل فئة بسياسات Cross-tenant وConditional Access مختلفة. 2) إدارة الدعوات عبر Workflow (طلب/موافقة/تعيين/توثيق) بدل دعوات فردية غير مضبوطة. 3) اعتماد Access by group: لا تمنح وصولًا مباشرًا لمستخدم؛ امنحه عبر مجموعة مشروع لها مالك واضح. 4) فرض MFA وضوابط جلسة للضيوف كخط أساس، مع تشديد إضافي للبيانات الحساسة. 5) مراجعات وصول وتنظيف دوري للضيوف والمجموعات. 6) مراقبة تسجيل الدخول والتغييرات ومنح الأذونات، وربطها بـ SIEM. 7) مساءلة واضحة: تحديد مالكي الموارد ومسؤولية إنهاء الوصول عند نهاية العقد.

النتيجة المتوقعة هي تعاون سريع لكنه “مقيّد بالحوكمة”: يقلل المخاطر، يحسن الامتثال، ويمنع أن يصبح B2B قناة خلفية لتجاوز ضوابط الأمن الداخلية.

🧪 مثال عملي:
تصميم سياسة مؤسسة: أي شريك جديد يجب أن يمر بتقييم أمني. إذا كان Tenant الشريك يطبق MFA وسياسات قوية، يتم تفعيل MFA trust لتقليل الاحتكاك. أما الشركاء المؤقتون، فيتم السماح لهم فقط بالوصول عبر متصفح مع منع التنزيل، وتطبيق Access Reviews أسبوعية أثناء فترة المشروع.

🧭 هوية الأجهزة والتكامل مع Intune والامتثال وتأثيرها على الوصول في Entra ID

🧩 السؤال 61: ما المقصود بـ Device Identity في Entra ID ولماذا أصبحت الأجهزة جزءًا من قرار الثقة؟

🧠 الإجابة:
هوية الجهاز (Device Identity) في Entra ID تعني أن الجهاز نفسه—وليس المستخدم فقط—يمتلك “كيانًا” وهوية مسجلة داخل الدليل، يمكن استخدامها كإشارة ثقة عند اتخاذ قرارات الوصول. تاريخيًا كان الأمن يركز على المستخدم وكلمة المرور، لكن الواقع الحديث أثبت أن اختراق جهاز المستخدم (Malware/Token theft) أو استخدام جهاز غير مُدار يمكن أن يتجاوز حتى MFA في بعض السيناريوهات. لذلك أصبح الجهاز عاملًا أساسيًا ضمن نموذج Zero Trust: لا يكفي أن “المستخدم صحيح”، بل يجب أن يكون “السياق صحيحًا” والجهاز موثوقًا وممتثلًا.

عندما يتم تسجيل جهاز في Entra ID (Azure AD registered/joined أو Hybrid joined)، يصبح بالإمكان تقييم حالته: هل هو مُدار؟ هل يمتثل لسياسات الحماية؟ هل لديه تشفير قرص؟ هل محدث؟ هل يحتوي على EDR؟ ثم تُستخدم هذه الإشارات عبر Conditional Access لتقرير السماح أو فرض قيود على الجلسة أو الحظر.

تشغيليًا، Device Identity تمكّن فرق IT من توحيد التحكم في أجهزة Windows/macOS/iOS/Android، وربط ذلك بتجربة تسجيل دخول متكاملة مثل SSO على الجهاز، وWindows Hello for Business. أمنيًا، دمج الجهاز في القرار يقلل كثيرًا من مخاطر السرقة القائمة على بيانات الاعتماد وحدها، ويجعل الهجمات التي تعتمد على أجهزة “غير معروفة” أقل نجاحًا.

🧪 مثال عملي:
تطبيق مالي حساس لا يسمح بالدخول إلا من أجهزة “ممتثلة” مُدارة عبر Intune. إذا حاول الموظف الدخول من جهازه الشخصي غير المُدار—even مع كلمة مرور صحيحة وMFA—يتم تحويله لنسخة ويب مقيدة تمنع التنزيل، أو يُحظر الوصول بالكامل حسب الحساسية.

🧩 السؤال 62: ما الفرق بين Azure AD Registered وAzure AD Joined وHybrid Azure AD Joined؟

🧠 الإجابة:
هذه المصطلحات تمثل “أنماط الانضمام” للجهاز إلى Entra ID، وكل نمط يحدد مستوى التحكم والسيناريو المستهدف:

1) Azure AD Registered: غالبًا للأجهزة الشخصية (BYOD). المستخدم يسجل الجهاز بهويته ليتمكن من الوصول للموارد مع بعض الإشارات الأساسية. لا يعني بالضرورة أن الجهاز مُدار بالكامل، لكنه يتيح تطبيق بعض سياسات Conditional Access (مثل Require registered device في سيناريوهات محدودة).

2) Azure AD Joined: جهاز مملوك للمؤسسة ومربوط مباشرة بـ Entra ID دون Domain محلي. يُستخدم في البيئات السحابية الأصلية (Cloud-native). يوفر إدارة مركزية قوية، وتجربة SSO أفضل، ويسهل دمجه مع Intune لإدارة كاملة.

3) Hybrid Azure AD Joined: جهاز مرتبط بـ Active Directory المحلي (Domain-joined) وفي الوقت نفسه مسجل في Entra ID. هذا مناسب للبيئات الهجينة التي لا تزال تعتمد على البنية المحلية، مع رغبة في الاستفادة من Conditional Access وSSO للسحابة.

اختيار النمط قرار معماري يعتمد على نضج المؤسسة، اعتمادها على أنظمة محلية، ومتطلبات الإدارة. أمنيًا، Azure AD Joined غالبًا يمنح أبسط نموذج حوكمة للسحابة، بينما Hybrid يوفر انتقالًا تدريجيًا، وRegistered يُستخدم بحذر لأنه أقل تحكمًا.

🧪 مثال عملي:
- موظفون دائمون: أجهزة Windows Azure AD Joined + Intune. - فروع قديمة تعتمد Domain: Hybrid Azure AD Joined. - متعاقدون يستخدمون أجهزتهم: Azure AD Registered مع سياسات جلسات تمنع تنزيل البيانات الحساسة.

🧩 السؤال 63: ما معنى “Device Compliance” وكيف يُستخدم في قرارات Conditional Access؟

🧠 الإجابة:
امتثال الجهاز (Device Compliance) يعني أن الجهاز يحقق مجموعة شروط أمنية وتشغيلية محددة من قبل المؤسسة—وغالبًا يتم تقييمها عبر Microsoft Intune. هذه الشروط قد تشمل: تفعيل تشفير القرص (BitLocker/FileVault)، وجود كلمة مرور قوية/biometrics، تحديثات نظام التشغيل ضمن حد معين، عدم كسر الحماية (Jailbreak/Root)، تفعيل جدار الحماية، أو وجود حل حماية طرفية (EDR).

عندما يكون الجهاز “Compliant”، يقوم Intune بإرسال حالة الامتثال إلى Entra ID، لتصبح إشارة يمكن استخدامها ضمن Conditional Access كشرط “Require device to be marked as compliant”. هذا يرفع مستوى الثقة لأن الوصول لا يُمنح إلا من جهاز يحقق أساسيات الأمن المؤسسي.

تشغيليًا، الامتثال ليس ثابتًا: جهاز قد يكون ممتثلًا اليوم وغير ممتثل غدًا إذا توقف عن التحديث أو تم تعطيل التشفير. لذلك يعمل النظام كنموذج “تحقق مستمر” (Continuous evaluation). أمنيًا، يوصى بتجنب الاعتماد على الامتثال وحده دون MFA وسياسات جلسة، لأن الامتثال يضمن “حدًا أدنى” لكنه لا يمنع كل سيناريوهات السرقة أو إساءة الاستخدام.

🧪 مثال عملي:
سياسة وصول لتطبيق HR: إذا كان الجهاز Compliant + المستخدم أكمل MFA → السماح الكامل. إذا لم يكن الجهاز ممتثلًا → السماح عبر المتصفح فقط مع منع التنزيل، وإرسال تعليمات للمستخدم لإصلاح الامتثال (مثل تحديث النظام أو تفعيل BitLocker).

🧩 السؤال 64: كيف يعمل التكامل بين Entra ID وMicrosoft Intune عمليًا؟

🧠 الإجابة:
التكامل بين Entra ID وIntune يجعل الهوية والإدارة يعملان كمنظومة واحدة: Entra ID يثبت الهوية ويطبق سياسات الوصول، وIntune يدير الجهاز ويقيّم امتثاله ويطبق الإعدادات والتطبيقات. عمليًا، يتم تسجيل الأجهزة في Intune عبر عمليات مثل Autopilot في Windows، أو Enrollment في iOS/Android/macOS. بعد التسجيل، يبدأ Intune في تطبيق سياسات التهيئة (Configuration profiles) وسياسات الامتثال (Compliance policies).

Entra ID يستخدم نتائج Intune كإشارات: حالة الامتثال، نوع الانضمام، ملكية الجهاز (Corporate/Personal)، وإشارات أخرى مرتبطة بالهوية. ثم، Conditional Access يستخدم هذه الإشارات لاتخاذ قرارات الوصول. هذا يخلق حلقة مغلقة: إذا خالف الجهاز سياسة، يصبح غير ممتثل، فيتأثر وصوله فورًا.

تشغيليًا، نجاح التكامل يتطلب: تعريف واضح لفئات الأجهزة، سياسات امتثال واقعية لا تكسر العمل، قنوات دعم للمستخدمين لحل مشاكل الامتثال، ومراقبة تقارير Intune وEntra ID لتحديد العوائق. أمنيًا، من أفضل الممارسات ربط الأجهزة الحساسة بـ Autopilot وفرض حماية قوية، وتطبيق Application Protection Policies (MAM) على الأجهزة الشخصية لتقليل مخاطر التسريب دون فرض إدارة كاملة.

🧪 مثال عملي:
تقوم المؤسسة بإعداد Windows Autopilot: عند تشغيل الجهاز الجديد لأول مرة، يسجل تلقائيًا في Entra ID وينضم كـ Azure AD Joined، ثم يلتحق بـ Intune الذي يثبت تطبيقات العمل ويطبق BitLocker وEDR. بعدها تُفعل سياسة Conditional Access تمنح وصولًا كاملًا للتطبيقات الحساسة فقط من هذه الأجهزة.

🧩 السؤال 65: ما هو Windows Hello for Business وكيف يعزز Passwordless في Entra ID؟

🧠 الإجابة:
Windows Hello for Business (WHfB) هو آلية مصادقة قوية على Windows تعتمد على مفاتيح تشفير مخزنة بشكل آمن داخل الجهاز (TPM) مع عامل محلي مثل PIN أو بصمة/وجه. الفكرة ليست أن PIN “كلمة مرور صغيرة”، بل أنه مرتبط بالجهاز ولا يمكن استخدامه من خارج الجهاز، مما يقلل كثيرًا من مخاطر التصيد وسرقة البيانات.

WHfB يمثل أحد أهم مسارات Passwordless في منظومة Entra ID لأنه يحقق مصادقة قوية ومقاومة للتصيد ضمن سيناريوهات العمل اليومية. عند دمجه مع إدارة الأجهزة عبر Intune وسياسات Conditional Access، يصبح الجهاز + المستخدم وحدة ثقة متكاملة: لا يمكن للمهاجم ببساطة استخدام كلمة مرور مسروقة من جهاز آخر.

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

🧪 مثال عملي:
تفعيل WHfB لموظفي المالية: عند تسجيل الدخول للجهاز يستخدم الموظف بصمة أو PIN. عند فتح تطبيقات Microsoft 365 يتم SSO تلقائيًا. وإذا حاول الدخول من جهاز غير مُدار، يُطلب MFA إضافية أو يُحظر وفق السياسة.

🧩 السؤال 66: ما هو Device-based Conditional Access وكيف يختلف عن السياسات التقليدية؟

🧠 الإجابة:
Device-based Conditional Access يعني أن قرارات الوصول لا تعتمد فقط على المستخدم أو الموقع أو التطبيق، بل تعتمد بشكل رئيسي على خصائص الجهاز: هل هو Joined/Hybrid/Registered؟ هل هو Compliant؟ هل هو جهاز مملوك للشركة؟ هل يستخدم تطبيقات معتمدة؟

السياسات التقليدية قد تفرض MFA أو تمنع دولًا، لكنها قد تفشل عندما يتمكن المهاجم من تجاوزها عبر سرقة جلسة أو استخدام جهاز شخصي. Device-based CA يضيف “حاجزًا” قويًا: حتى لو امتلك المهاجم بيانات اعتماد المستخدم، لن يحصل على وصول كامل ما لم يملك جهازًا موثوقًا أو ممتثلًا.

تشغيليًا، هذا النوع من السياسات يتطلب نضجًا في إدارة الأجهزة، وإلا سيصبح عائقًا كبيرًا. لذلك غالبًا يتم تطبيقه تدريجيًا: السماح بوصول مقيد للأجهزة غير المُدارة، ثم الانتقال للمنع الكامل للتطبيقات الحساسة. أمنيًا، يجب الانتباه إلى أن BYOD يحتاج نهجًا مختلفًا (مثل MAM + Session controls) بدل إجبار إدارة كاملة للجهاز.

🧪 مثال عملي:
تطبيق “Payroll”: سياسة CA تشترط “Require compliant device”. إذا كان المستخدم على جهاز شخصي، يتم منعه. أما تطبيق “Intranet News” فيسمح له حتى من جهاز غير مُدار لكن مع MFA.

🧩 السؤال 67: ما هو MDM وMAM وما الفرق بين إدارة الجهاز وإدارة التطبيقات؟

🧠 الإجابة:
MDM (Mobile Device Management) يعني إدارة الجهاز بالكامل: سياسات أمان، تهيئة النظام، تثبيت/إزالة التطبيقات، التحكم بالتشفير وكلمات المرور، وإمكانية مسح الجهاز عن بعد. هذا مناسب لأجهزة الشركة أو الأجهزة التي توافق المؤسسة على إدارتها بالكامل.

أما MAM (Mobile Application Management) فيركز على إدارة تطبيقات العمل فقط دون التحكم الكامل بالجهاز، وهو مناسب لـ BYOD. في سياق Microsoft، غالبًا يتم عبر Intune App Protection Policies، حيث يتم حماية بيانات العمل داخل تطبيقات معينة (Outlook, Teams, Office) عبر تشفير، منع النسخ/اللصق إلى تطبيقات شخصية، وفرض PIN داخل التطبيق.

الفرق الاستراتيجي أن MDM يعطي أعلى مستوى تحكم لكن أقل مرونة، بينما MAM يعطي توازنًا ممتازًا للتعاون مع أجهزة شخصية دون فرض إدارة كاملة قد يرفضها المستخدمون. أمنيًا، أفضل نهج غالبًا هجين: MDM للأجهزة المؤسسية، وMAM للأجهزة الشخصية، مع Conditional Access يفرض “Approved app” و“App protection policy” على BYOD بدل شرط Compliance.

🧪 مثال عملي:
موظف يستخدم هاتفه الشخصي: لا ترغب المؤسسة في التحكم بالجهاز كله. يتم فرض MAM على Outlook وTeams بحيث لا يمكنه نسخ بيانات البريد إلى WhatsApp، ويُمنع تنزيل المرفقات إلى مساحة شخصية، مع شرط CA يطلب “Approved app + App protection policy”.

🧩 السؤال 68: كيف أتجنب “فشل الامتثال” الذي يعطل المستخدمين؟

🧠 الإجابة:
فشل الامتثال قد يتحول من أداة حماية إلى مصدر تعطيل إذا تم تصميم سياسات Compliance بشكل غير واقعي أو دون فترة انتقالية. لتجنب ذلك، يجب التعامل مع الامتثال كبرنامج تغيير (Change management) وليس إعدادًا تقنيًا فقط.

منهجية عملية: 1) بناء سياسات امتثال “أساسية” أولًا (تشفير، كلمة مرور، تحديثات ضمن حد منطقي). 2) استخدام فترات سماح (Grace periods) لإصلاح المخالفات قبل الحظر. 3) توفير رسائل إرشادية للمستخدم عبر Company Portal توضح سبب عدم الامتثال وخطوات الإصلاح. 4) مراقبة التقارير: ما أكثر أسباب عدم الامتثال؟ ثم تعديل السياسات أو تحسين الإرشادات. 5) فصل السياسات حسب منصات الأجهزة وفئات المستخدمين (Executives, Developers, Kiosks).

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

🧪 مثال عملي:
تم فرض BitLocker على أجهزة Windows. ظهرت حالات كثيرة غير ممتثلة بسبب عدم وجود TPM في أجهزة قديمة. بدل تعطيل السياسة، قامت المؤسسة بتقسيم الأجهزة إلى فئة “Legacy” مع وصول مقيد، وبدأت خطة استبدال تدريجية للأجهزة مع توفير خطوات مساعدة واضحة.

🧩 السؤال 69: كيف يُستخدم “Require approved client app” و“App protection policy” في Conditional Access؟

🧠 الإجابة:
هذان الشرطان يمثلان نمطًا مثاليًا للأجهزة الشخصية: بدل أن تفرض أن الجهاز كله يجب أن يكون Compliant (MDM)، يمكنك فرض أن الوصول يتم فقط عبر تطبيقات معتمدة (Approved client apps) وأن بيانات العمل داخل هذه التطبيقات محمية بسياسات MAM (App protection policy).

“Approved client app” يعني أن المستخدم يجب أن يستخدم تطبيقات Microsoft المدعومة (مثل Outlook وTeams) أو تطبيقات محددة تمت الموافقة عليها، وليس أي عميل بريد أو متصفح غير موثوق. أما “App protection policy” فتضمن أن التطبيق الذي يستخدمه يطبق سياسات حماية بيانات: تشفير، PIN داخل التطبيق، منع النسخ، والتحكم في حفظ الملفات.

تشغيليًا، هذا يقلل الاحتكاك مع BYOD ويمنح حماية عملية لبيانات العمل دون صدام مع خصوصية المستخدم. أمنيًا، هو حل ممتاز لمنع تسرب البيانات عبر تطبيقات شخصية، لكنه لا يغني عن MFA وسياسات الجلسة للتطبيقات الحساسة جدًا.

🧪 مثال عملي:
على هواتف شخصية، تمنع سياسة CA الوصول إلى البريد إلا عبر Outlook مع App protection policy تفرض PIN وتمنع نسخ محتوى البريد إلى تطبيقات غير مُدارة. إذا حاول المستخدم إضافة البريد في تطبيق Mail الافتراضي يتم الحظر.

🧩 السؤال 70: ما أفضل الممارسات لبناء استراتيجية “جهاز موثوق” ضمن Zero Trust باستخدام Entra ID وIntune؟

🧠 الإجابة:
استراتيجية “الجهاز الموثوق” الناجحة تبنى على تدرج واضح وربط كل طبقة بأهداف عمل وأمان. أفضل الممارسات تشمل:

1) تصنيف الأجهزة: شركة/شخصي/مشارك (Shared) وربط كل فئة بنمط إدارة مناسب (MDM/MAM). 2) توحيد الانضمام: اعتماد Autopilot وAzure AD Joined للأجهزة الجديدة حيثما أمكن، وHybrid للأجهزة التي تعتمد على الدومين أثناء الانتقال. 3) خط أساس امتثال: تشفير + تحديثات + حماية طرفية + سياسات كلمة مرور/biometrics. 4) Conditional Access طبقي: - طبقة عامة: MFA للجميع + حظر Legacy Auth. - طبقة جهاز: Require compliant device للتطبيقات الحساسة. - طبقة BYOD: Approved app + App protection policy + قيود جلسة. 5) تقليل الاستثناءات وبناء مسارات بديلة آمنة (مثل وصول مقيد للمتصفح بدل فتح استثناء). 6) مراقبة وتحسين: قياس أسباب عدم الامتثال، تحسين السياسات، وتدريب المستخدمين. 7) دمج الاستجابة للحوادث: عند ارتفاع User/Sign-in risk، يتم تشديد قيود الجهاز/الجلسة تلقائيًا.

النتيجة المتوقعة: وصول آمن محسوب المخاطر، تقليل اختراقات الهوية القائمة على أجهزة غير موثوقة، وتحسين تجربة المستخدم عبر Passwordless وSSO على الأجهزة المُدارة.

🧪 مثال عملي:
المؤسسة تفرض: أي وصول إلى تطبيقات مالية أو بيانات “Confidential” يتطلب جهازًا Compliant مُدارًا عبر Intune + WHfB أو FIDO2. أما الوصول إلى موارد عامة فيسمح به من BYOD عبر تطبيقات معتمدة مع حماية بيانات (MAM) ومنع التنزيل، مع مراجعة شهرية للاستثناءات وتحديث قواعد الامتثال وفق تقارير الأعطال.

🧭 حوكمة الهوية Identity Governance: Access Reviews وEntitlement Management ودورة حياة الوصول

🧩 السؤال 71: ما المقصود بـ Identity Governance في Entra ID ولماذا تُعد ضرورة وليست خيارًا؟

🧠 الإجابة:
حوكمة الهوية (Identity Governance) في Microsoft Entra ID هي مجموعة قدرات وسياسات تهدف إلى ضمان أن “الأشخاص المناسبين” لديهم “الوصول المناسب” إلى “الموارد المناسبة” في “الوقت المناسب” ولـ “السبب المناسب”، مع وجود سجلات تدقيق تثبت ذلك. الفرق بين إدارة الهوية (IAM) والحوكمة هو أن IAM قد ينجح في منح الوصول وتشغيله، لكنه لا يضمن أن الوصول بقي صحيحًا مع تغيّر الأدوار والمشاريع والتنقلات—وهنا تتدخل الحوكمة.

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

تشغيليًا، الحوكمة تُحوّل الوصول إلى عملية: طلب → موافقة → تزويد → انتهاء صلاحية/مراجعة → إزالة. وأمنيًا، تتكامل مع Zero Trust عبر تقليل الامتيازات الدائمة، وتفعيل الوصول المؤقت (Time-bound), وربط القرارات بسياق العمل والمسؤولية.

🧪 مثال عملي:
بدل أن يضيف مسؤول IT موظفًا يدويًا لمجموعة “Finance-Admins” ويبقى فيها سنوات، تُنشئ المؤسسة برنامج حوكمة: الموظف يطلب الوصول، المدير يوافق، يتم منح الوصول لمدة 30 يومًا، ثم تجري مراجعة تلقائية لتجديده أو سحبه، مع سجل تدقيق كامل يثبت من وافق ولماذا.

🧩 السؤال 72: ما هي Access Reviews وكيف تختلف عن المراجعات اليدوية التقليدية؟

🧠 الإجابة:
Access Reviews هي آلية مؤتمتة داخل Entra Identity Governance لإجراء مراجعات دورية لمن يملك الوصول إلى مورد معين (مجموعة، تطبيق، دور، أو موارد Azure)، وطلب قرار صريح: الإبقاء أو الإزالة. ما يميزها عن المراجعات اليدوية أنها ليست ملف Excel يُرسل بالبريد ثم يضيع؛ بل هي عملية مدمجة في النظام، بموعد محدد، مُسندة لمراجعين محددين، مع تذكيرات، وسجل نهائي للقرار، وإمكانية تنفيذ تلقائي لنتائج المراجعة.

هذه المراجعات تقلل عبء فرق الأمن وIT لأنها توزع المسؤولية إلى مالكي الأعمال (Business owners) الذين يعرفون من يحتاج ماذا. كما أنها تقلل التأخير، وتمنع تراكم الوصول الناتج عن “نسيان” إزالة المستخدمين. والأهم: تنتج أدلة امتثال قابلة للتدقيق، وهو ما تحتاجه أطر مثل ISO 27001 وSOC 2 وPCI-DSS وغيرها.

تشغيليًا، قوة Access Reviews تظهر عند تصميمها جيدًا: تحديد نطاق واضح (مثلاً المجموعات الحساسة)، تحديد من يراجع (مدير، مالك تطبيق، أو Self review)، تحديد قرار افتراضي عند عدم الرد (غالبًا إزالة)، وتحديد دورة زمنية تناسب حساسية المورد.

🧪 مثال عملي:
مراجعة ربع سنوية لمجموعة “Azure-Subscription-Owners”: يتم إرسال المراجعة لمدير كل عضو لتأكيد الحاجة. إذا لم يرد خلال 10 أيام، يتم إزالة العضو تلقائيًا، مع إخطار مسبق وتوثيق القرار.

🧩 السؤال 73: ما الذي يمكن مراجعته عبر Access Reviews في Entra ID؟

🧠 الإجابة:
يمكن تطبيق Access Reviews على عدة أنواع من الأصول، ما يجعلها أداة شاملة لمعالجة زحف الصلاحيات عبر المنظومة. أبرز ما يمكن مراجعته: - Membership في مجموعات (خصوصًا مجموعات التحكم بالوصول للتطبيقات أو مجموعات أدوار Azure). - الوصول إلى التطبيقات (Enterprise applications assignments). - أدوار Entra ID الإدارية (عند استخدام PIM يمكن مراجعة الأهلية والأنشطة). - أدوار Azure RBAC عبر تكامل موارد Azure. - الضيوف داخل مجموعات أو فرق مشروع (لمنع Stale guests).

الميزة التشغيلية أن نفس منهجية المراجعة تُطبق على كل هذه الأنواع، مما يبسط الحوكمة ويجعل المؤسسة قادرة على بناء “برنامج مراجعات” وليس مبادرات متفرقة. أمنيًا، التركيز عادة يبدأ بالمجموعات والتطبيقات الحساسة، ثم يتوسع تدريجيًا ليشمل موارد أوسع.

🧪 مثال عملي:
تطبيقات “Payroll” و“ERP” تعتبر عالية الحساسية. يتم إنشاء Access Review شهري لمُعيَّني التطبيق (Assignments) + مراجعة ربع سنوية لمجموعات Azure RBAC التي تمنح “Owner” على اشتراكات الإنتاج.

🧩 السؤال 74: كيف أختار المراجعين (Reviewers) بطريقة تعكس واقع الأعمال؟

🧠 الإجابة:
اختيار المراجع هو أهم قرار في Access Reviews؛ لأنه يحدد جودة النتائج. إذا كان المراجع لا يعرف طبيعة العمل، ستتحول المراجعة إلى “Approve all” أو “Ignore”، فتفشل الحوكمة. لذلك يجب مواءمة المراجعين مع من يفهم سبب الوصول: غالبًا مدير المستخدم (Manager)، مالك التطبيق/المورد (Resource owner)، أو فريق الأمن للحالات شديدة الحساسية.

منهجية عملية: 1) للصلاحيات المرتبطة بالوظيفة (مثل مجموعات القسم): المراجع الأنسب هو المدير المباشر. 2) لتطبيقات الأعمال (ERP/CRM): المراجع الأنسب هو مالك التطبيق/المنتج أو مالك العملية (Process owner). 3) للأدوار الإدارية الحساسة: المراجعة قد تكون مشتركة بين الأمن ومالك النظام، أو تتطلب موافقة متعددة الأطراف. 4) للضيوف: المراجع الأنسب هو مالك المشروع أو مالك المجموعة التي تضم الضيوف.

تشغيليًا، يجب أن يكون هناك “تعيين واضح للمالكين” للتطبيقات والمجموعات؛ لأن غياب المالك يجعل المراجعات معطلة. أمنيًا، يوصى بإعداد قرار افتراضي عند عدم الرد (Remove) للمجموعات الحساسة لتجنب بقاء الوصول بسبب التجاهل.

🧪 مثال عملي:
مجموعة “Finance-Approvers” يراجعها مديرو الأعضاء لأنهم يعرفون من يقوم فعليًا بالموافقات المالية. أما دور “Global Administrator eligible” فيراجعه CISO أو فريق IAM مع موافقة إضافية من مالك البنية التحتية.

🧩 السؤال 75: ما هو Entitlement Management وما المشكلة التي يحلها؟

🧠 الإجابة:
Entitlement Management هو قدرة في Entra Identity Governance تُستخدم لبناء “حزم وصول” (Access Packages) قابلة للطلب، تحتوي على كل ما يحتاجه المستخدم لأداء مهمة أو دور: عضوية مجموعات، تعيينات تطبيقات، أذونات موارد، وأحيانًا سياسات وشروط. المشكلة التي يحلها هي أن الوصول في المؤسسات غالبًا يتوزع على عشرات الأنظمة: مجموعة هنا، تطبيق هناك، دور في Azure، ومجلدات SharePoint—فيصبح منح الوصول يدويًا بطيئًا ومليئًا بالأخطاء.

بدل منح صلاحيات فردية بشكل متكرر، يقوم Entitlement Management بتغليفها في Access Package مع قواعد: من يحق له الطلب؟ من يوافق؟ ما مدة الوصول؟ هل يوجد مبرر مطلوب؟ هل هناك مراجعة دورية؟ هل ينتهي الوصول تلقائيًا؟ هذا يحول الوصول من “عملية فنية” إلى “خدمة” ذات حوكمة واضحة.

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

🧪 مثال عملي:
Access Package باسم “Project-X Contributor”: يضيف المستخدم إلى مجموعة Teams للمشروع، يمنحه الوصول لموقع SharePoint، ويعينه على تطبيق Jira. يتم منح الوصول لمدة 90 يومًا فقط، ويتطلب موافقة مدير المشروع، ثم يتم سحب الوصول تلقائيًا عند انتهاء المدة ما لم يتم تجديده.

🧩 السؤال 76: كيف يتم تصميم Access Packages بشكل يقلل الفوضى ويعكس الأدوار الحقيقية؟

🧠 الإجابة:
التصميم الجيد لحزم الوصول يعتمد على التفكير “بالدور” وليس “بالمورد”. أي بدل إنشاء Access Package لكل تطبيق، قم ببنائها حول سيناريوهات العمل: موظف جديد في المالية، مطور في مشروع، مدقق خارجي، شريك، إلخ. لأن المستخدم لا يريد “تطبيق X”، بل يريد أن يقوم بمهمة محددة تتطلب عدة موارد.

منهجية تصميم عملية: 1) تحديد personas: من هم أنواع المستخدمين (Finance Analyst, Project Manager, Vendor)? 2) تحديد الموارد المطلوبة لكل persona: مجموعات، تطبيقات، أدوار. 3) تقليل العناصر: لا تضف إلا ما هو ضروري (Least privilege). 4) بناء مستويات: Viewer/Contributor/Admin بدل حزمة واحدة ضخمة. 5) تحديد دورة زمنية: وصول دائم للموظفين الداخليين قد يكون عبر انضمام تلقائي للمجموعات، بينما المشاريع/الضيوف يجب أن يكون وقتيًا. 6) توحيد التسمية والمالكين: naming convention + owners واضحون للمراجعة.

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

🧪 مثال عملي:
بدل حزمة “All Dev Tools”، يتم إنشاء ثلاث حزم: - Dev-Viewer (قراءة مستودعات، قراءة لوحات) - Dev-Contributor (كتابة كود، تشغيل Pipelines) - Dev-Privileged (إدارة Secrets/Prod approvals لمدة 7 أيام فقط مع موافقة إضافية)

🧩 السؤال 77: ما هو نموذج Request & Approval وكيف يمنع الوصول غير المبرر؟

🧠 الإجابة:
نموذج Request & Approval في Entitlement Management يضع “حاجز حوكمة” قبل منح الوصول: لا يحصل المستخدم على صلاحية حساسة لمجرد أنه طلبها، بل يجب أن يمر الطلب بموافقة من شخص/أشخاص لديهم سياق عمل ومسؤولية. هذا يقلل من الوصول العرضي، ويمنع حالات “منح الصلاحية لأن الموظف أرسل رسالة” دون توثيق.

التصميم الجيد للموافقات يشمل: تحديد من يوافق (مدير، مالك المورد، فريق الأمن)، هل الموافقة من شخص واحد أم متعددة (Multi-stage approvals)، هل يلزم تقديم مبرر، وهل هناك شروط إضافية (مثل تدريب إلزامي أو قبول سياسات). كما يمكن تقييد الطلبات بفئات معينة: فقط موظفو قسم محدد أو فقط ضيوف من Tenants موثوقة.

أمنيًا، الموافقة ليست ضمانًا إذا كانت شكلية؛ لذلك يجب أن تكون هناك محاسبة (Accountability) وسجلات مراجعة، وأحيانًا “مراجعة لاحقة” (Post-approval review) للصلاحيات الحساسة. وتشغيليًا، يجب الحفاظ على سرعة معقولة؛ لذا تُستخدم موافقات تلقائية للطلبات منخفضة الحساسية، وموافقات صارمة للحساسة.

🧪 مثال عملي:
طلب الوصول لبيانات العملاء: يتطلب موافقة مدير القسم + مالك البيانات (Data owner). يجب إدخال سبب الطلب وربطه برقم تذكرة. عند الموافقة يتم منح الوصول 14 يومًا فقط، ثم يتم سحبه تلقائيًا ما لم يُجدد بسبب جديد.

🧩 السؤال 78: كيف يُطبق الوصول محدود المدة (Time-bound access) ولماذا يقلل المخاطر جذريًا؟

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

في Entra Identity Governance، يتحقق Time-bound access عبر إعدادات Access Packages (مدة، تاريخ انتهاء، تجديد)، وعبر PIM للأدوار الإدارية (تفعيل مؤقت)، وعبر Access Reviews للتجديد. يحقق ذلك مفهوم Zero Standing Privileges: لا توجد امتيازات دائمة إلا للضرورة القصوى.

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

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

🧩 السؤال 79: كيف تدعم Identity Governance الامتثال والتدقيق (Audit/Compliance) بشكل عملي؟

🧠 الإجابة:
الامتثال والتدقيق يتطلبان أمرين: (1) ضوابط عملية تقلل المخاطر، و(2) أدلة تثبت أن الضوابط مطبقة وتعمل. Identity Governance توفر الاثنين: - عبر Access Reviews تثبت أن المؤسسة راجعت الوصول بانتظام واتخذت قرارات واضحة. - عبر Entitlement Management تثبت أن كل وصول حساس مُنح بناءً على طلب وموافقة ومبرر، وأنه ينتهي تلقائيًا أو يُراجع. - عبر سجلات التدقيق يمكن إثبات من وافق، ومتى، ولماذا، وما الذي تم منحه بالضبط.

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

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

🧪 مثال عملي:
خلال تدقيق SOC 2، يطلب المدقق إثبات مراجعة الوصول لتطبيق ERP. يتم تقديم تقرير Access Review يوضح قائمة المستخدمين، قرارات المراجعين، ومن تمت إزالته تلقائيًا بسبب عدم الرد، إضافة إلى سجلات موافقات Access Packages التي منحت الوصول خلال الفترة.

🧩 السؤال 80: ما أفضل الممارسات لإطلاق برنامج Identity Governance ناجح على مستوى المؤسسة؟

🧠 الإجابة:
إطلاق برنامج حوكمة هوية ناجح يتطلب خطة تغيير مؤسسية وليس إعدادات فقط. أفضل الممارسات تشمل:

1) بدء تدريجي عالي الأثر: ابدأ بالمجموعات/التطبيقات الحساسة والحسابات المميزة والضيوف. 2) تحديد مالكي الموارد رسميًا: كل تطبيق/مجموعة يجب أن يكون لها Owner مسؤول عن المراجعات. 3) تصميم قوالب (Templates): قوالب Access Reviews وتواترها، وقوالب Access Packages للأدوار الشائعة. 4) سياسات افتراضية صارمة للمجموعات الحساسة: إذا لم يرد المراجع → Remove. 5) دمج مع ITSM: ربط الطلبات بتذاكر ServiceNow/Jira لتوثيق الأسباب وربطها بعمليات الأعمال. 6) مؤشرات أداء: عدد المراجعات المكتملة، نسبة الإزالة، زمن الموافقة، عدد الضيوف القدامى الذين تم تنظيفهم. 7) تدريب وتواصل: شرح للمراجعين لماذا يراجعون وما معنى الموافقة والمسؤولية القانونية/التشغيلية. 8) تحسين مستمر: تقليل الضوضاء عبر استهداف الموارد الصحيحة، وضبط التواتر والمراجعين.

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

🧪 مثال عملي:
تطلق المؤسسة برنامجًا من 3 مراحل: - المرحلة 1: مراجعات شهرية لمجموعات المدراء والأدوار الحساسة + تنظيف الضيوف. - المرحلة 2: تحويل طلبات الوصول للتطبيقات الحساسة إلى Access Packages بموافقات متعددة. - المرحلة 3: توسيع الحوكمة لتشمل كل تطبيقات SaaS وربطها بـ ITSM، مع لوحة مؤشرات تعرض مستوى “ديون الصلاحيات” وانخفاضها شهريًا.

🧭 الوصول المميز Privileged Access: PIM والحسابات الإدارية وBreak-glass وفصل المهام

🧩 السؤال 81: ما هو Privileged Identity Management (PIM) ولماذا يُعد حجر الأساس في تقليل المخاطر الإدارية؟

🧠 الإجابة:
Privileged Identity Management (PIM) في Microsoft Entra ID هو نظام لإدارة الصلاحيات الإدارية الحساسة وفق مبدأ “الامتيازات عند الحاجة فقط” (Just-In-Time / JIT) و“لا امتيازات دائمة” (Zero Standing Privileges). بدل أن يكون المسؤول Global Admin طوال الوقت—وبالتالي يصبح حسابه هدفًا ذهبيًا—يتيح PIM جعل الصلاحية “مؤهّل لها” (Eligible) وليست “مُفعّلة دائمًا” (Active). وعند الحاجة، يقوم المسؤول بتفعيل الدور لفترة محدودة، مع شروط مثل MFA، مبرر، موافقة، أو تذكرة.

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

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

🧪 مثال عملي:
بدل وجود 6 مسؤولين Global Admin دائمًا، يتم جعلهم Eligible. عند الحاجة لتغيير إعداد حساس، يقوم المسؤول بتفعيل الدور لمدة 1 ساعة مع MFA وسبب مكتوب، ويتم تسجيل الحدث وإرساله إلى SIEM لمراقبة أي تفعيل خارج ساعات العمل.

🧩 السؤال 82: ما الفرق بين Eligible وActive في PIM وكيف يؤثر على التشغيل اليومي؟

🧠 الإجابة:
في PIM، هناك حالتان رئيسيتان للدور:

- Eligible: المستخدم لديه “أهلية” لتفعيل الدور عند الحاجة، لكنه لا يمتلك الصلاحية فعليًا الآن. لا يمكنه تنفيذ أعمال الدور إلا بعد التفعيل. هذا هو الوضع المفضل لمعظم الأدوار الحساسة لأنه يقلل سطح الهجوم.

- Active: المستخدم يمتلك الدور فعليًا خلال فترة محددة (أو دائمًا إذا تم تعيينه دائمًا). خلال هذه الفترة يمكنه تنفيذ إجراءات إدارية كاملة.

التأثير التشغيلي أن الإدارة تصبح حدثًا مقصودًا ومُوثقًا بدل كونها “حالة دائمة”. صحيح أن ذلك يضيف خطوة (تفعيل الدور)، لكنه يقلل الحوادث. لتجنب تعطيل العمل، يجب تصميم أدوار مناسبة لكل فريق بحيث لا يضطر الجميع لتفعيل Global Admin من أجل مهمة صغيرة—بل يتم توزيع المهام عبر أدوار محددة (مثل User Administrator أو Application Administrator).

أمنيًا، Eligible يجب أن يكون الافتراضي، وActive الدائم يجب أن يكون نادرًا ومبررًا للغاية. كما يجب مراقبة تفعيل الأدوار: من فعّل؟ متى؟ ولماذا؟ وهل كانت المدة منطقية؟ لأن المدة الطويلة تعيد المخاطر.

🧪 مثال عملي:
فريق الدعم لديه Eligible لدور Helpdesk Admin. عند تلقي بلاغ لإعادة تعيين كلمة مرور مستخدم، يقوم أحدهم بتفعيل الدور لمدة 30 دقيقة فقط، ثم يتم إيقافه تلقائيًا بعد انتهاء المدة.

🧩 السؤال 83: كيف أُصمم “نموذج أدوار” يقلل الاعتماد على Global Administrator؟

🧠 الإجابة:
الاعتماد المفرط على Global Administrator هو خطأ شائع لأن هذا الدور يملك صلاحيات شاملة تجعل أي خطأ أو اختراق كارثيًا. التصميم الاحترافي يبدأ بمبدأ: “لا يوجد Global Admin إلا للضرورات القصوى”، ثم تفكيك المهام إلى أدوار دقيقة. Entra ID يوفر أدوارًا جاهزة كثيرة تغطي وظائف محددة: إدارة المستخدمين، إدارة التطبيقات، السياسات، الأجهزة، التقارير… إلخ.

منهجية تصميم نموذج الأدوار:
1) جرد المهام الإدارية: ما الذي يقوم به فريق IAM؟ فريق التطبيقات؟ فريق الأمن؟ 2) مطابقة المهام بالأدوار الأدنى: مثل User Admin، Groups Admin، App Admin، Conditional Access Admin… 3) تعيين الأدوار عبر مجموعات (Role-assignable groups) لتبسيط الإدارة وربطها بالمراجعات. 4) جعل الأدوار الحساسة Eligible عبر PIM مع شروط تفعيل صارمة. 5) مراجعة دورية: هل لا يزال هذا الدور مطلوبًا؟

أمنيًا، هذا النموذج يقلل “انفجار الصلاحيات” ويحد أثر الخطأ البشري. وتشغيليًا، يُحسن سرعة الاستجابة: فريق التطبيقات لا ينتظر Global Admin لتعديل SSO لأنه يملك Application Admin بشكل محكوم.

🧪 مثال عملي:
بدل أن يملك فريق التطبيقات Global Admin لإعداد Enterprise Apps، يتم منحه Application Administrator + Cloud Application Administrator (Eligible) مع تفعيل لمدة ساعة عند الحاجة، بينما يبقى Global Admin محصورًا في حسابين للطوارئ وإعدادات الحوكمة العليا فقط.

🧩 السؤال 84: ما هي شروط تفعيل الأدوار في PIM (Activation Requirements) وكيف تُختار؟

🧠 الإجابة:
شروط التفعيل في PIM هي الضوابط التي يجب تحققها قبل أن يصبح الدور Active. هذه الشروط تجعل التفعيل “حدثًا مدروسًا” وتمنع التفعيل العبثي أو الخبيث. أبرز الشروط: - MFA قبل التفعيل. - مطلوب مبرر (Justification). - مطلوب تذكرة (Ticket number) للربط مع ITSM. - موافقة (Approval) قد تكون مرحلة واحدة أو متعددة. - حد أقصى لمدة التفعيل (مثل 1–4 ساعات للأدوار عالية الحساسية).

اختيار الشروط يعتمد على حساسية الدور وتأثيره. الأدوار فائقة الحساسية (Global Admin، Privileged Role Admin) قد تتطلب موافقة + MFA + تذكرة + مدة قصيرة. أدوار أقل (مثل Groups Admin) قد تكتفي بـ MFA + مبرر.

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

🧪 مثال عملي:
تفعيل Role “Privileged Authentication Administrator”: يتطلب MFA + موافقة من قائد فريق الأمن + إدخال رقم تذكرة حادثة + مدة 60 دقيقة. أما “User Administrator” فيتطلب MFA + مبرر فقط لمدة 2 ساعات.

🧩 السؤال 85: ما المقصود بـ Break-glass Accounts وكيف تُدار دون تحويلها إلى ثغرة؟

🧠 الإجابة:
حسابات Break-glass (أو Emergency Access Accounts) هي حسابات طوارئ تُستخدم فقط عندما تفشل آليات المصادقة والسياسات (مثل تعطل MFA، خطأ في Conditional Access تسبب في Lockout، أو حادثة تمنع الوصول الإداري). الفكرة أنها “مقود احتياطي” يمنع فقدان السيطرة على tenant.

لكن الخطر أن حساب Break-glass غالبًا يتم استثناؤه من سياسات كثيرة، ما يجعله هدفًا بالغ القيمة. لذلك يجب إدارته بمنهجية صارمة:
1) حسابان على الأقل لتجنب فشل واحد. 2) كلمات مرور قوية جدًا وطويلة، مخزنة في خزنة آمنة (Password vault) مع وصول محدود ومراجعات. 3) استثناء محدود ومبرر من سياسات CA—فقط ما يلزم لتجنب lockout، مع استمرار ضوابط أخرى إن أمكن. 4) مراقبة وتنبيه فوري لأي استخدام (Sign-in alert). 5) اختبار دوري (شهري/ربع سنوي) لضمان أنه يعمل بالفعل. 6) عدم استخدامه للعمل اليومي إطلاقًا.

أمنيًا، Break-glass ليس “حلًا للتجاوز”، بل “حل للاستمرارية”، ويجب أن يكون استخدامه حدثًا نادرًا جدًا يتطلب تحقيقًا بعديًّا (Post-incident review).

🧪 مثال عملي:
توجد حسابات طوارئ باسم “EA-1” و“EA-2”. عند أي تسجيل دخول لهما، يتم إرسال تنبيه فوري إلى فريق SOC ومدير IAM. يتم اختبار الحسابين كل ربع سنة: تسجيل دخول، تنفيذ إجراء بسيط، ثم تغيير كلمة المرور وتوثيق الاختبار.

🧩 السؤال 86: كيف أطبق الفصل بين المهام (Separation of Duties) للأدوار الإدارية؟

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

تطبيق SoD في Entra ID يتم عبر:
1) تقسيم الأدوار: من يدير المستخدمين ليس هو نفسه من يدير Conditional Access أو PIM. 2) PIM مع موافقات: الأدوار الحساسة تتطلب موافقة من طرف آخر عند التفعيل. 3) حسابات منفصلة: حساب يومي + حساب إداري منفصل. 4) مراجعات وصول: Access Reviews للأدوار الحساسة. 5) تسجيل ومراقبة: إرسال Audit إلى SIEM مع إنذارات للتغييرات الخطيرة.

تشغيليًا، SoD يحتاج تصميمًا يتناسب مع حجم المؤسسة: في الفرق الصغيرة قد لا يتوفر فصل كامل، لكن يمكن تقليل المخاطر عبر موافقات وإشراف، أو مراجعات دورية من جهة مستقلة. أمنيًا، الهدف هو منع “التحكم المطلق” بيد فرد واحد دون أثر رقابي.

🧪 مثال عملي:
فريق IAM يدير المستخدمين والمجموعات، وفريق الأمن يدير Conditional Access وIdentity Protection، وفريق المنصة يدير تكاملات التطبيقات. إذا احتاج IAM تفعيل دور حساس، يتطلب موافقة من الأمن عبر PIM.

🧩 السؤال 87: ما هو مفهوم “Administrative Units” وكيف يساعد على تفويض الإدارة بأمان؟

🧠 الإجابة:
Administrative Units (AUs) هي آلية في Entra ID لتقسيم نطاق الإدارة داخل Tenant بحيث يمكن تفويض مسؤوليات إدارية على جزء محدد من المستخدمين/المجموعات/الأجهزة دون إعطاء صلاحيات على كامل الدليل. هذا مهم في المؤسسات الكبيرة أو متعددة المناطق، حيث تحتاج فروع أو وحدات أعمال لإدارة مستخدميها دون القدرة على العبث بباقي المؤسسة.

تعمل AUs كـ “حدود إدارية”: تمنح دورًا مثل User Administrator لكن مقيدًا داخل AU فقط. هذا يحقق Least privilege على مستوى النطاق (Scope). تشغيليًا، يقلل الاعتماد على فريق مركزي لكل تغيير بسيط، ويعطي فرق المناطق مرونة. أمنيًا، يقلل أثر اختراق حساب مسؤول إقليمي؛ لأنه لا يستطيع العبث بالمؤسسة بالكامل.

لنجاح AUs يجب تصميمها بعناية وفق الهيكل التنظيمي (Regions/Departments) وربطها بعمليات HR، وتوثيق من يمتلك ماذا، ثم تطبيق Access Reviews على الأدوار داخل AUs.

🧪 مثال عملي:
إنشاء AU باسم “KSA-Users” يضم مستخدمي فرع السعودية. يتم منح فريق الدعم المحلي دور User Admin scoped لهذه الوحدة فقط لإدارة كلمات المرور والمستخدمين داخل السعودية دون القدرة على تعديل مستخدمي أوروبا أو أمريكا.

🧩 السؤال 88: كيف يتم تأمين محطات عمل المسؤولين (PAW/SAW) وربطها بـ Entra ID؟

🧠 الإجابة:
محطات عمل المسؤولين (Privileged Access Workstations – PAW) أو (Secure Admin Workstations – SAW) هي أجهزة مخصصة للمهام الإدارية الحساسة، تُعزل قدر الإمكان عن الاستخدام اليومي (البريد، التصفح العام) لتقليل خطر الإصابة بالبرمجيات الخبيثة وسرقة الجلسات. لأن كثيرًا من اختراقات الامتيازات تبدأ بإصابة جهاز مسؤول ثم سرقة رموز أو جلسات.

ربط PAW بـ Entra ID يتم عبر جعلها أجهزة مُدارة (Azure AD Joined/Hybrid Joined) وممتثلة عبر Intune، مع تطبيق سياسات Conditional Access تشترط أن أي تفعيل PIM أو وصول لبوابات الإدارة يتم فقط من أجهزة PAW. يمكن كذلك فرض MFA مقاومة للتصيد (FIDO2/WHfB) على هذه الأجهزة، وتشديد سياسات الجلسة، ومنع الدخول من متصفحات غير مدعومة.

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

🧪 مثال عملي:
سياسة Conditional Access: الوصول لبوابة Entra وAzure Portal وتفعيل PIM مسموح فقط من أجهزة تحمل Tag “PAW” وممتثلة. إذا حاول مسؤول فتح البوابة من جهازه اليومي، يُمنع أو يُسمح بوصول مقيد حسب السياسة.

🧩 السؤال 89: ما هي المراجعات والتقارير الأهم لمراقبة الوصول المميز بشكل مستمر؟

🧠 الإجابة:
مراقبة الوصول المميز يجب أن تكون مستمرة لأنها منطقة عالية الخطورة. أهم ما يجب مراجعته دوريًا:

1) قائمة من هم Eligible/Active للأدوار الحساسة، وهل العدد منطقي؟ 2) سجلات تفعيل PIM: متى يتم التفعيل؟ من يفعّل خارج ساعات العمل؟ هل هناك تفعيل متكرر غير مبرر؟ 3) الأدوار الدائمة: أي دور Active دائمًا يجب أن يكون استثناءً مُبررًا ومراجعًا. 4) تغييرات Conditional Access وMFA: لأن المهاجم قد يغيّر الضوابط لتسهيل السيطرة. 5) استخدام Break-glass: أي استخدام يجب أن يولد Incident وتحقيقًا. 6) إنشاء Service Principals/Consent عالي: لأن امتيازات التطبيقات قد تكون طريقًا بديلًا للامتيازات.

تشغيليًا، الأفضل إرسال هذه البيانات إلى SIEM وبناء لوحات مؤشرات (Dashboards) وتنبيهات. أمنيًا، تعتبر “الانحرافات” هي الأهم: تفعيل مفاجئ لدور حساس، أو تفعيل لمدة طويلة، أو تفعيل من موقع غير معتاد.

🧪 مثال عملي:
تقرير أسبوعي يرسل إلى فريق الأمن: عدد تفعيلات Global Admin، متوسط مدة التفعيل، وأي تفعيل تم من خارج شبكة الشركة. إذا ظهر تفعيل ليلاً من دولة غير معتادة، يتم فتح Incident فورًا وإبطال الجلسات للمستخدم المعني.

🧩 السؤال 90: ما أفضل “حزمة ضوابط” لتأمين الحسابات الإدارية في Entra ID بشكل متكامل؟

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

1) حسابات منفصلة للإدارة (Admin accounts) وعدم استخدام الحساب اليومي للإدارة. 2) PIM لجعل الأدوار الحساسة Eligible مع JIT وتفعيل قصير. 3) MFA مقاومة للتصيد للحسابات الإدارية (FIDO2/WHfB) وفرضها عبر Conditional Access. 4) حظر Legacy Auth ومنع البروتوكولات القديمة. 5) PAW/SAW أو على الأقل شرط “جهاز ممتثل” للوصول إلى بوابات الإدارة. 6) فصل المهام + موافقات للتفعيل للأدوار الحرجة. 7) حسابات Break-glass قليلة ومراقبة ومختبرة. 8) مراقبة SIEM لسجلات الدخول والتغييرات الحساسة والتفعيل. 9) Access Reviews للأدوار الحساسة دوريًا لإزالة الأهلية غير الضرورية. 10) إجراءات استجابة واضحة: إبطال الجلسات، إعادة تعيين كلمات مرور، تعطيل حسابات، ومراجعة التغييرات.

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

🧪 مثال عملي:
المؤسسة تعتمد نموذج: كل مسؤول لديه حساب إداري منفصل + WHfB، جميع الأدوار الحساسة Eligible عبر PIM بمدة 60 دقيقة، تفعيل يتطلب MFA ومبرر، الوصول لبوابات الإدارة من أجهزة PAW فقط، وتنبيه فوري لأي تغيير في Conditional Access أو أي استخدام لـ Break-glass، مع Runbook جاهز لتعطيل الحساب وإبطال الجلسات خلال دقائق.

🧭 التشغيل والتكامل المتقدم: Microsoft Graph والأتمتة والاحتفاظ بالسجلات والهجرة الهجينة والاستمرارية

🧩 السؤال 91: ما هو Microsoft Graph ولماذا يعد الواجهة القياسية لإدارة Entra ID؟

🧠 الإجابة:
Microsoft Graph هو واجهة برمجية موحدة (Unified API) تمثل “الطبقة القياسية” للتعامل مع خدمات مايكروسوفت السحابية، بما في ذلك Entra ID وMicrosoft 365 والموارد المرتبطة. في سياق Entra ID، Graph هو الطريق الأحدث والأكثر استدامة لإدارة المستخدمين، المجموعات، التطبيقات، الأدوار، وسياسات الهوية—بدل الاعتماد على واجهات قديمة أو أدوات منفصلة لكل منتج.

الأهمية الاستراتيجية لـ Graph هي أنه يجعل إدارة الهوية “قابلة للأتمتة” و“قابلة للدمج” في عمليات المؤسسة: DevOps، ITSM، بوابات الخدمة الذاتية، والحوكمة. بدل إدارة الهوية عبر واجهة رسومية فقط، يمكن بناء عمليات قياسية: إنشاء مستخدم، تزويده، تعيينه لمجموعات، إعداد سياسات، إصدار تقارير—كل ذلك عبر API بقدرة تدقيق وقياس.

أمنيًا، Graph هو أيضًا “سطح هجوم” إذا أسيء استخدامه، لأن تطبيقًا مع أذونات واسعة يمكنه استخراج بيانات حساسة أو تعديل إعدادات. لذلك يتطلب حوكمة أذونات صارمة، استخدام Managed identities أو شهادات بدل secrets، مراقبة استدعاءات Graph، وربطها بسياسات الموافقات والمراجعات.

🧪 مثال عملي:
بناء Workflow آلي: عند وصول ملف تعيين موظف جديد من نظام HR، يستدعي النظام Microsoft Graph لإنشاء المستخدم في Entra ID، تعيين مديره، إضافته لمجموعات القسم، ومنحه تراخيص Microsoft 365—ثم يفتح تذكرة ITSM لتسليم الجهاز وتوثيق العملية.

🧩 السؤال 92: كيف أحدد نموذج الأذونات الصحيح عند استخدام Graph (Delegated vs Application)؟

🧠 الإجابة:
اختيار نموذج الأذونات في Graph قرار معماري وأمني في آن واحد. القاعدة الأساسية: - استخدم Delegated permissions عندما يكون هناك مستخدم حاضر (Interactive) ويجب أن تكون صلاحيات التطبيق مقيدة بما يملك المستخدم نفسه، مع إمكانية تطبيق Conditional Access على جلسة المستخدم. هذا مناسب لبوابات الخدمة الذاتية أو أدوات إدارية يستخدمها موظفون. - استخدم Application permissions عندما يعمل التطبيق في الخلفية دون مستخدم (Daemon/Automation). هنا التطبيق يملك صلاحيات مستقلة وقد تكون واسعة؛ لذلك يحتاج Admin consent وحوكمة صارمة.

لتحديد النموذج الصحيح، اسأل: هل يمكن تنفيذ المهمة بوجود المستخدم؟ هل يجب أن يكون القرار مرتبطًا بالمستخدم وسياق دخوله؟ إذا نعم، delegated أفضل. إذا كانت المهمة مجدولة أو تكامل نظامي (مثل HR أو عمليات تدقيق ليلية)، فـ application قد يكون ضروريًا.

أمنيًا، application permissions هي الأكثر خطورة لأنها تمنح “قوة على مستوى المؤسسة” وقد تتجاوز قيود المستخدمين. لذلك يجب تقليلها للحد الأدنى، تقسيم التطبيقات حسب الوظيفة (لا تضع كل شيء في تطبيق واحد)، تفعيل مراقبة صارمة، واستخدام شهادات/Managed identities، وربط منحها بعملية موافقة رسمية وAccess reviews.

🧪 مثال عملي:
بوابة داخلية تسمح للمدير بطلب إضافة موظف إلى مجموعة: تستخدم delegated بحيث لا يستطيع المدير تعديل شيء خارج نطاقه. بينما خدمة “Nightly License Reconciliation” التي تقارن التراخيص في Microsoft 365 تحتاج application permission لقراءة المستخدمين والتراخيص دون تدخل بشري، مع شهادة في Key Vault وتنبيه عند أي استدعاء غير معتاد.

🧩 السؤال 93: ما أفضل ممارسات الأتمتة (Automation) لإدارة الهوية دون خلق مخاطر جديدة؟

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

منهجية عملية:
1) تقسيم الأتمتة إلى خدمات صغيرة: كل خدمة تؤدي وظيفة محددة بأذونات محددة، بدل “سوبر-تطبيق” يملك كل شيء. 2) تقليل الأذونات: اطلب فقط ما يلزم، وراجع الأذونات دوريًا. 3) تفضيل Managed Identity أو الشهادات على secrets الثابتة، وتدوير ما يلزم. 4) ضوابط التغيير: أي تعديل في السكربت/الخدمة يمر عبر مراجعة كود (Code review) وموافقة تغيير. 5) الرصد والتنبيه: مراقبة استدعاءات Graph، وأي طفرات في إنشاء المستخدمين، تعديل المجموعات، أو منح الأذونات. 6) اختبارات وفصل بيئات: Dev/Test/Prod مع مفاتيح وأذونات منفصلة. 7) مسار استجابة: زر إيقاف (Kill switch) لتعطيل Service Principal أو إبطال secrets عند الاشتباه.

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

🧪 مثال عملي:
خدمة أتمتة “Joiner”: تُمنح فقط صلاحيات إنشاء المستخدم وتعيينه لمجموعات محددة (غير حساسة). أما إضافة المستخدم لمجموعة “Finance-Approvers” فتتطلب Access Package وموافقة بشرية. عند الاشتباه بسلوك غير طبيعي، يقوم فريق الأمن بإيقاف Service Principal للخدمة فورًا.

🧩 السؤال 94: ما الفرق بين إدارة Entra ID عبر PowerShell وبين Microsoft Graph PowerShell؟

🧠 الإجابة:
تقليديًا، كانت هناك وحدات PowerShell متعددة لإدارة Azure AD/Entra ID (مثل AzureAD وMSOnline)، لكن الاتجاه الحديث يركز على Microsoft Graph PowerShell لأنه يعتمد على نفس واجهات Graph القياسية ويوفر تغطية أوسع وتحديثات مستمرة وتوافقًا أفضل مع المستقبل.

من منظور تشغيلي، Graph PowerShell يسهّل بناء سكربتات إدارة قابلة للتكرار، ويمكن دمجه مع CI/CD، ويمكن التحكم في الأذونات عبر OAuth scopes. لكنه يتطلب فهمًا جيدًا لنموذج Graph (Endpoints, Permissions) وكيفية التعامل مع الصفحات (Pagination) والحدود (Throttling).

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

🧪 مثال عملي:
بدل استخدام سكربت قديم يعتمد MSOnline لإدارة المستخدمين، يتم تحديثه إلى Microsoft Graph PowerShell مع scopes محددة مثل User.ReadWrite.All وGroup.ReadWrite.All (عند الحاجة) وتقييد التشغيل ليكون من حساب إداري مؤقت عبر PIM مع سجل تذكرة.

🧩 السؤال 95: كيف أتعامل مع تحديات Graph مثل Throttling وPagination في الحلول المؤسسية؟

🧠 الإجابة:
عند استخدام Graph على نطاق مؤسسي (آلاف المستخدمين أو عمليات متكررة)، تظهر تحديات تشغيلية طبيعية:

- Pagination: كثير من استدعاءات Graph تعيد النتائج على صفحات، ويجب أن يقرأ التطبيق الروابط التالية (nextLink) لجلب كل النتائج. تجاهل ذلك يؤدي إلى تقارير ناقصة أو عمليات غير مكتملة. - Throttling: Graph يفرض حدودًا على عدد الطلبات خلال فترة زمنية لحماية الخدمة. عند تجاوزها، يُعاد خطأ مثل 429 مع تلميحات (Retry-After).

حل هذه التحديات يتطلب تصميمًا هندسيًا: 1) بناء طبقة عميل (Client) تدعم pagination تلقائيًا. 2) تطبيق سياسة إعادة المحاولة (Retry) مع Backoff واحترام Retry-After. 3) تقليل الاستدعاءات عبر اختيار حقول محددة (select) وتصفية (filter) وطلبات مجمعة (batch) عند الملاءمة. 4) جدولة العمليات الثقيلة خارج ساعات الذروة. 5) مراقبة معدلات الفشل والاستدعاءات لتعديل التصميم.

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

🧪 مثال عملي:
تطبيق يصدر تقريرًا يوميًا عن عضوية المجموعات: يستخدم $select لتقليل البيانات، ويقرأ nextLink حتى النهاية، وإذا حدث 429 ينتظر حسب Retry-After ثم يعيد المحاولة. إذا فشلت بعض الصفحات، يسجل ذلك ويعيد تنفيذ الجزء الفاشل بدل إعادة التقرير كاملًا.

🧩 السؤال 96: ما المقصود بسياسات الاحتفاظ بالسجلات (Log Retention) ولماذا هي حرجة للتحقيقات؟

🧠 الإجابة:
سياسات الاحتفاظ بالسجلات تعني تحديد المدة التي يتم فيها الاحتفاظ بسجلات مثل Sign-in logs وAudit logs وRisk events قبل حذفها أو أرشفتها. هذه السياسات حرجة لأن كثيرًا من الحوادث لا تُكتشف فورًا؛ قد يظل المهاجم “صامتًا” أسابيع قبل تنفيذ نشاط واضح. إذا كانت السجلات لا تُحتفظ بها مدة كافية، ستفقد المؤسسة القدرة على التحقيق، معرفة نقطة الدخول، أو إثبات ما حدث للجهات التنظيمية.

النهج المؤسسي غالبًا هو تصدير سجلات Entra ID إلى منصة SIEM/SOAR (مثل Microsoft Sentinel) أو تخزين مركزي (Log Analytics / Storage) لتمديد فترة الاحتفاظ وفق متطلبات الامتثال (قد تكون 90 يومًا، 180 يومًا، سنة أو أكثر حسب القطاع). كما يجب ربط ذلك بإدارة التكلفة، لأن الاحتفاظ الطويل قد يزيد التخزين والتحليل.

أمنيًا وتشغيليًا، لا يكفي الاحتفاظ؛ يجب أن تكون السجلات “قابلة للبحث” بسرعة أثناء حادثة. لذلك تُبنى فهارس، وقواعد تنبيه، ومخططات بيانات موحدة، مع حماية السجلات نفسها من العبث (Immutable storage أو صلاحيات مقيدة) لأن المهاجم قد يحاول طمس الأثر.

🧪 مثال عملي:
مؤسسة مالية تحتفظ بسجلات Entra ID لمدة سنة في Sentinel. عند اكتشاف اختراق بعد 4 أشهر، يستطيع فريق SOC الرجوع لسجلات الدخول الأولى التي تضمنت Admin consent مشبوه، وتتبع سلسلة الأحداث كاملة بدل الاعتماد على تخمينات.

🧩 السؤال 97: كيف أُصدّر سجلات Entra ID إلى SIEM مثل Microsoft Sentinel ولماذا يعد ذلك “تصميمًا” لا مجرد إعداد؟

🧠 الإجابة:
تصدير سجلات Entra ID إلى SIEM هو خطوة أساسية لبناء مراقبة واستجابة مؤسسية، لكنه ليس “إعدادًا بسيطًا” لأن جودة البيانات والاستخدام تعتمد على التصميم. يجب تحديد: ما السجلات التي ستُرسل (Sign-in, Audit, Risk, PIM events)، أين ستُخزن، مدة الاحتفاظ، من يملك الوصول، وكيف ستُبنى قواعد الإنذار لتقليل الضوضاء.

التصميم الجيد يشمل:
1) اختيار مصادر البيانات بدقة وربطها بحالات الاستخدام (Use cases) الأمنية. 2) توحيد الهوية عبر ربط سجلات Entra مع سجلات الأجهزة (Intune/Defender) والبريد (M365) للحصول على سياق كامل. 3) بناء قواعد عالية الدقة: مثل تغييرات CA، منح Admin consent، تفعيل أدوار PIM، محاولات Legacy Auth، أو تسجيل دخول من دول نادرة. 4) تحديد إجراءات تلقائية (Playbooks): تعطيل حساب، إبطال جلسات، أو تعليق Service Principal عند مؤشرات معينة. 5) حماية منصة السجلات: لأن SIEM نفسه قد يصبح هدفًا.

أمنيًا، القيمة الحقيقية ليست في “وجود السجلات”، بل في القدرة على اكتشاف الأنماط والارتباطات بسرعة—وهذا يتطلب هندسة بيانات وإدارة إنذارات وتدريب فريق SOC.

🧪 مثال عملي:
تكوين Sentinel لاستقبال Sign-in/Audit logs. بناء Analytic rule: “تغيير Conditional Access يتضمن إضافة استثناء All users” + “تسجيل دخول ناجح لمسؤول من IP جديد” خلال 30 دقيقة. عند تحقق الشرطين، يتم فتح Incident تلقائي وتشغيل Playbook يوقف حساب المسؤول مؤقتًا ويطلب تحققًا عاجلًا.

🧩 السؤال 98: ما أهم اعتبارات تصميم الهوية الهجينة (Hybrid Identity) عند استخدام Entra Connect؟

🧠 الإجابة:
تصميم الهوية الهجينة يعني مزامنة أو دمج Active Directory المحلي مع Entra ID بحيث تعمل المؤسسة بسلاسة عبر موارد محلية وسحابية. Entra Connect (المعروف تاريخيًا بـ Azure AD Connect) هو أداة الربط الأساسية التي تقوم بالمزامنة وإدارة خيارات المصادقة. أهم الاعتبارات المعمارية تشمل:

1) نموذج الهوية المصدرية: هل AD المحلي هو المصدر (Authoritative source) أم Entra؟ غالبًا في الهجرة يكون AD هو المصدر لتجنب ازدواجية. 2) خيار المصادقة: Password Hash Sync (PHS) أو Pass-through Authentication (PTA) أو Federation. اختيارك يؤثر على الاعتمادية، التعقيد، ومتطلبات البنية. 3) توحيد UPN: يجب أن يكون UPN قابلًا للتوجيه وموحدًا لتجربة تسجيل دخول سليمة. 4) نطاق المزامنة: لا تزامن كل شيء بلا حاجة؛ حدد OU/Attributes اللازمة فقط. 5) المرونة والتوفر: خادم Connect يجب أن يكون موثوقًا، مع خطط لاستعادة الخدمة. 6) التحكم بالتغييرات: أي تغيير في قواعد المزامنة قد يؤثر على آلاف الحسابات.

أمنيًا، الهوية الهجينة توسع سطح الهجوم: إذا تم اختراق AD المحلي قد تمتد التأثيرات للسحابة. لذلك يجب تقوية AD المحلي، حماية حسابات Connect، مراقبة التغييرات، وتقليل امتيازات الخدمة. وتشغيليًا، يجب التخطيط لمسارات الانتقال التدريجي نحو Cloud-native عندما يكون ذلك مناسبًا.

🧪 مثال عملي:
مؤسسة تختار PHS لأنه أبسط وأكثر اعتمادية من Federation، وتقوم بتوحيد UPN إلى نطاق قابل للتوجيه، وتزامن فقط OU الخاصة بالموظفين النشطين، مع مراقبة أي تغيير في قواعد المزامنة وإجراء اختبار في بيئة تجريبية قبل الإنتاج.

🧩 السؤال 99: كيف أبني خطة استمرارية وتعافٍ (BC/DR) لطبقة الهوية في Entra ID؟

🧠 الإجابة:
الهوية هي طبقة حرجة: إذا تعطلت، قد تتوقف كل الأنظمة. بناء خطة استمرارية وتعافٍ لطبقة الهوية في Entra ID يعني التفكير في السيناريوهات التي قد تمنع المصادقة أو الإدارة: أخطاء Conditional Access تسبب Lockout، تعطل MFA، انقطاع اتصال هجين يؤثر على PTA، تعطل أنظمة HR التي تغذي التزويد، أو حادثة أمنية تتطلب تعطيل واسع.

مكونات خطة BC/DR تشمل:
1) حسابات Break-glass مختبرة ومراقبة. 2) Runbooks واضحة لحالات مثل: lockout بسبب CA، أو اختراق حساب مسؤول، أو اكتشاف تطبيق خبيث. 3) نسخ إعدادات السياسات (توثيق CA policies, PIM settings, app configs) بحيث يمكن استعادتها بسرعة. 4) تصدير السجلات لاستمرارية التحقيق حتى أثناء الأعطال. 5) مرونة الهوية الهجينة: إذا كنت تستخدم PTA، خطط لتوفر وكلاء PTA؛ وإذا كنت تستخدم Connect، خطط لاستعادة أو خادم Staging. 6) تمارين دورية (Tabletop exercises) لاختبار الخطة.

أمنيًا، أثناء حادثة، قد تحتاج لتعطيل جلسات على نطاق واسع أو تغيير كلمات مرور أو إبطال secrets للتطبيقات. يجب أن تكون هذه الإجراءات محسوبة لتجنب توقف الأعمال بالكامل. وتشغيليًا، توثيق الاعتماديات (ما التطبيقات التي ستتأثر إذا تم تغيير سياسة MFA؟) ضروري لتقليل المفاجآت.

🧪 مثال عملي:
تمرين ربع سنوي: يقوم فريق IAM بمحاكاة “سياسة CA خاطئة تمنع كل الدخول”. يتم استخدام Break-glass للدخول، تعطيل السياسة الخاطئة، ثم مراجعة السبب الجذري، وتحديث إجراءات التغيير بحيث لا تُنشر سياسة جديدة إلا بعد Report-only + موافقة أمنية.

🧩 السؤال 100: ما أهم “مؤشرات النضج” لبرنامج Entra ID على مستوى المؤسسة وكيف أقيس التقدم؟

🧠 الإجابة:
قياس نضج برنامج Entra ID يعني تحويل الهوية من مشروع إعداد إلى برنامج تحكم مستمر. مؤشرات النضج (Maturity indicators) يمكن تقسيمها إلى أمان، حوكمة، وتشغيل:

أولًا: مؤشرات الأمان - نسبة المستخدمين تحت MFA (خصوصًا MFA مقاومة للتصيد للحسابات الحساسة). - نسبة حظر Legacy Auth وتراجع محاولاته. - عدد الحسابات الإدارية الدائمة مقابل Eligible عبر PIM. - زمن الاستجابة لحوادث هوية (إبطال جلسات/تعطيل حساب).

ثانيًا: مؤشرات الحوكمة - نسبة التطبيقات التي لديها مالك محدد + مراجعات وصول منتظمة. - عدد Access Reviews المكتملة ونسبة الإزالة (دليل على تقليل Access creep). - نسبة الوصول الحساس الذي يُمنح عبر Access Packages بدلًا من منح يدوي. - عدد الضيوف القدامى الذين تم تنظيفهم دوريًا.

ثالثًا: مؤشرات التشغيل - نسبة الأتمتة في عمليات Joiner/Mover/Leaver وانخفاض أخطاء التزويد. - مستوى الالتزام بتغييرات السياسات عبر Report-only واختبارات. - جودة المراقبة: عدد الإنذارات المفيدة مقابل الضوضاء (Alert fidelity). - زمن معالجة مشاكل الامتثال للأجهزة وتأثيرها على العمل.

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

🧪 مثال عملي:
لوحة مؤشرات شهرية: - MFA coverage = 98% (الحسابات الإدارية 100% مع FIDO2) - Legacy Auth attempts انخفضت 85% بعد الحظر - Global Admin دائم = 0 (Eligible فقط) - Access Reviews: 12 مراجعة/شهر، نسبة إزالة 9% (تقليل زحف الصلاحيات) - متوسط زمن الموافقة على Access Package = 6 ساعات بدل 3 أيام هذه الأرقام تُستخدم لتحديد أولويات التحسين للشهر التالي (مثل تقليل الاستثناءات أو رفع حماية تطبيقات معينة).

خاتمة

في ختام هذا المقال، يتضح أن Microsoft Entra ID لم يعد مجرد “خدمة تسجيل دخول” أو بديل سحابي لـ Active Directory، بل أصبح منصة هوية مؤسسية شاملة تُدار بمنهجية أمنية وتشغيلية متقدمة، وتشكّل نقطة الارتكاز لأي استراتيجية Zero Trust واقعية. فالقيمة الحقيقية لا تأتي من تفعيل ميزة واحدة—مثل MFA أو SSO—بل من بناء منظومة مترابطة تجمع بين المصادقة القوية، والوصول المشروط، وحماية الهوية وإدارة المخاطر، وحوكمة الوصول، والتحكم في الامتيازات عبر PIM، مع دمج إشارات الأجهزة والامتثال، وربط كل ذلك بالمراقبة والتحليل والاستجابة للحوادث.

وعلى المستوى التنفيذي، يمكّن Entra ID المؤسسة من تحويل الهوية إلى “قدرة أعمال” ترفع الإنتاجية عبر تجربة وصول موحّدة، وتقلل التعطيل عبر الأتمتة، وتُحسن الامتثال عبر المراجعات وسجلات التدقيق، وتحد من المخاطر عبر تقليل الامتيازات الدائمة وإغلاق منافذ الهجمات الشائعة (كالـ Legacy Authentication وConsent Phishing). أما على المستوى الهندسي، فإن النجاح يتطلب تصميمًا تدريجيًا قائمًا على القياس: البدء بخط أساس قوي، ثم التوسع وفق حساسية الموارد، وإدارة الاستثناءات بحزم، وربط السياسات بسيناريوهات عمل حقيقية، وتطوير Runbooks واضحة للطوارئ.

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

تعديل المقال

أقسام الوصول السريع ( مربع البحث )

أسئلة وأجوبة Microsoft Entra ID: دليل شامل لإدارة الهوية والوصول وأمن Zero Trust