Scope Tags في Intune: ليش دور القراءة قد يطلع أوسع من المتوقع عند جمع الأدوار؟

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

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

ثلاثة أسئلة وراء تعيين واحد

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

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

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

انتبه للسلوك المفعّل وقت الاختبار

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

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

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

جهز تجربة لا تؤثر على نشر التطبيقات

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

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

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

اكتب المصفوفة قبل أن تسجل الدخول

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

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

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

ابدأ بهوية لها تعيين واحد

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

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

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

حفظ الوصف يثبت التحديث، لكنه لا يثبت كل شيء

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

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

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

تعيين المستلمين سؤال مستقل

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

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

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

ما الذي تخبرك به صفحة الصلاحيات؟

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

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

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

لا تختبر العزل بحساب إدارة شامل

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

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

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

الموارد التي لا تتصرف مثل بعضها

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

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

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

اقرأ تقرير تقييم الأذونات بدون استعجال

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

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

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

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

صياغة الملاحظة التي يفهمها المسؤول

عنوان جيد للنتيجة: «جمع تعيينين منح حساب التطبيقات تحديثًا على نطاق صُمم للقراءة». في الوصف، اذكر التعيينين والوسمين ونوع المورد، ثم وقت المحاولة ومعرف العنصر التدريبي والتعديل الذي نجح.

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

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

تمرين إضافي يبين لك مصدر الوصول

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

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

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

مصادر الشرح

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

Use RBAC and scope tags for distributed IT
https://learn.microsoft.com/en-us/intune/fundamentals/role-based-access-control/scope-tags

Role-based access control with Microsoft Intune
https://learn.microsoft.com/en-us/intune/fundamentals/role-based-access-control/overview

ولبناء نطاق اختبار صغير قبل هذه التجربة، اقرأ المقال السابق في المجتمع:
https://courses.cyberpts.com/community/144/akhtbar-akhtraq-intune-mn-hsab-dam-mhdwd-ala-khryth-slahyat-alajhzh-walttbyqat