اختبار Conditional Access في Entra: ليش الدخول ينجح والسياسة تقول Failure؟ افهم Report-only والاستثناءات

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

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

اكتب الوعد الأمني بجملة يمكن اختبارها

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

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

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

حالة السياسة أول شيء تقرأه

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

Report-only
On
Off

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

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

Success لا تعني أن كل السياسات سمحت

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

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

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

Not applied سؤال عن الشروط، مو شهادة أمان

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

Not applied

ابدأ بالتعيين ثم الاستثناءات ثم الشروط المرتبطة بالطلب. قارن ما أدخلته في تجربة اللاب بما سجله النظام فعلًا. جهاز تظنه معروفًا قد يظهر بسياق مختلف، وتطبيق تفتحه بالاسم قد يطلب موردًا آخر. حل هذا الاختلاف قبل أن تزيد عدد التجارب.

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

User action required تحتاج قراءة هادئة

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

Report-only: User action required

في ورقة العمل، افصل «ما شاهد المستخدم» عن «ما توقع تقييم السياسة». هذه المقارنة مفيدة لتخطيط النشر، لكنها ليست اختبارًا ناجحًا لرفض الوصول. إذا كانت المهمة تستهدف الإنفاذ، تحتاج حالة يجهزها المسؤول تحت سياسة مفعلة في اللاب، مع بقاء خيارات الاسترداد المعتمدة.

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

اسم العميل يختلف عن المورد المحمي

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

Client Application
Target Resource
Audience

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

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

راجع الاستثناء كمسؤولية لها صاحب وتاريخ

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

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

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

What If يساعدك تسأل، لكنه مو بديل لكل تجربة

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

What If

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

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

مصفوفة صغيرة أفضل من تجارب عشوائية

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

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

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

الجلسة القائمة غير طلب جديد

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

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

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

كيف تجمع الحدث الصحيح؟

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

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

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

صياغة الملاحظة: الغطاء ناقص أم الإعداد مقصود؟

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

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

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

إعادة الاختبار تبدأ من نفس الحالة

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

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

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

المراجع الرسمية وما تقرأ بعده

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

Report-only policy impact
https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-report-only

What If tool
https://learn.microsoft.com/en-us/entra/identity/conditional-access/what-if-tool

Troubleshoot Conditional Access
https://learn.microsoft.com/en-us/entra/identity/conditional-access/troubleshoot-conditional-access

Target resources
https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-cloud-apps

ولفهم الفرق بين حالة امتثال الجهاز وقرار السماح، هذا المقال في المجتمع يكمل زاوية الاختبار:
https://courses.cyberpts.com/community/147/aljhaz-ghyr-mtabq-waldkhwl-ynjh-akhtbar-intune-compliance-ma-alwswl-almshrwt-kht

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