اختبار صلاحيات SCCM وConfiguration Manager: الدور والـ Security Scope والـ Collection لازم تنقرأ مع بعض

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

ثلاثة أسئلة بدل سؤال: هل عنده صلاحية؟

أول سؤال هو ماذا يستطيع الحساب أن يفعل: قراءة تطبيق، تعديل محتوى، إنشاء Deployment، أو إدارة Collection. هذا جانب Security Role. الثاني هو أي كائنات يستطيع التعامل معها: تطبيقات أو حزم مرتبطة بـSecurity Scope معين. الثالث هو أي مستخدمين وأجهزة تقع تحت إدارته، وهنا تدخل Collections.

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

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

ليش فصل الأدوار لا يضمن فصل المسار؟

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

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

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

الـ Limiting Collection جزء من حد الجمهور

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

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

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

المحتوى والجمهور والجدولة: ثلاث نقاط أثر

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

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

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

اختبر الحساب الفعلي، لا جلسة المسؤول

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

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

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

RBAViewer يساعدك تفهم، لكنه يحتاج سياقه الصحيح

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

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

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

خمس حالات تجعل مراجعة RBAC أقل عشوائية

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

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

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

أشياء يفترض تفحصها قبل أن يلمس العميل المحتوى

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

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

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

أسماء المواقع الإدارية لا تكفي للعزل

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

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

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

قياس الخطورة بدون تشغيل توزيع واسع

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

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

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

إصلاح يمكن اختباره من جديد

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

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

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

مراجع تبدأ منها، وما الذي تراجعه بعدها؟

القاعدة التي تستحق التذكر: صلاحيات Configuration Manager تُقرأ من العملية والكائن والجمهور والتعيينات مجتمعة. لا تعتمد على اسم دور أو Security Scope وحده. ابدأ قراءة، كوّن حالات محددة، ثم أثبت السلوك بأصغر تجربة مصرح بها على أجهزة المختبر.

أساس نموذج الإدارة هنا: https://learn.microsoft.com/en-us/mem/configmgr/core/understand/fundamentals-of-role-based-administration . تفاصيل التعيينات والتحذير المتعلق بقراءة كائن من نطاق ونشره عبر صلاحية مجموعة هنا: https://learn.microsoft.com/en-us/intune/configmgr/core/servers/deploy/configure/configure-role-based-administration . ودليل أداة المراجعة هنا: https://learn.microsoft.com/en-us/intune/configmgr/core/support/rbaviewer . راجع النسخة الفعلية للبيئة قبل تطبيق تفاصيل الإجراء، ولا تعامل مقالًا تعليميًا كبديل لدليل المنتج أو سياسة المؤسسة.

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