اختبار اختراق Intune: من حساب دعم محدود إلى خريطة صلاحيات الأجهزة والتطبيقات

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

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

إنتيون ليس مجرد لوحة تعرض الجرد

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

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

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

حدد ماذا تختبر قبل أن تستكشف

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

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

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

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

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

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

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

افصل صلاحية الإجراء عن نطاق الهدف

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

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

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

الواجهة نقطة بداية، وليست كل حدود الخدمة

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

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

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

الجهاز المُدار والجهاز المطابق ليسا معنى واحدًا

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

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

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

اختبر النشر بعنصر حميد له أثر قابل للقياس

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

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

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

لا تنس من يملك المجموعة المستهدفة

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

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

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

التكاملات تضيف هويات ومسارات جديدة

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

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

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

صنف نتائجك حسب ما ثبت فعلًا

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

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

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

كيف تجمع دليلًا يفيد الفريق

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

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

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

أخطاء تختصر وقتك لكنها تضعف الاختبار

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

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

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

أعد الاختبار بعد التصحيح بنفس السؤال

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

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

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

المراجع التي تراجع منها تفاصيل المنتج

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

Microsoft Intune architecture
https://learn.microsoft.com/en-us/intune/fundamentals/architecture

Microsoft Intune core concepts
https://learn.microsoft.com/en-us/intune/fundamentals/core-concepts

List managedDevices — Microsoft Graph
https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-list?view=graph-rest-1.0