الجهاز غير مطابق والدخول ينجح؟ اختبار Intune Compliance مع الوصول المشروط خطوة بخطوة

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

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

اكتب المطلوب بجملة تقبل الاختبار

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

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

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

المطابقة إعداد وحالة، والوصول قرار

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

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

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

جهز حالات متقابلة لها مرجع واضح

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

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

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

عامل الوقت كحقل في الدليل

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

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

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

وضع التقييم لا يفرض المنع

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

Report-only

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

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

راجع الاستثناء كمسار مستقل

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

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

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

كل الشروط أم واحد منها؟

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

Require all selected controls
Require one selected control

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

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

معرف الجهاز أهم من الاسم الذي تتذكره

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

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

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

الجلسة القائمة تختلف عن دخول جديد

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

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

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

المهلة تحتاج قراءة الأثر لا اتهام المنتج

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

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

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

اقرأ حدث الدخول من جهة كل سياسة

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

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

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

نجاح الدخول لا يعطيك صلاحية داخل التطبيق

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

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

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

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

نتيجة واضحة بدل عبارة «تجاوزنا المطابقة»

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

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

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

مصادر التفاصيل

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

Conditional Access: Grant
https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-grant

Monitor device compliance policies
https://learn.microsoft.com/en-us/intune/device-security/compliance/monitor-policy

Create device compliance policies
https://learn.microsoft.com/en-us/intune/device-security/compliance/create-policy

Conditional Access report-only mode
https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-report-only