أداة PowerShell موقعة ومع ذلك ما اشتغلت؟ افهم WDAC وApp Control وConstrainedLanguage

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

التوقيع يجيب عن سؤال مختلف عن الصلاحية

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

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

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

اسم WDAC والاسم الحالي App Control for Business

تلقى كثيرًا من الشروحات تستخدم Windows Defender Application Control أو WDAC، بينما الوثائق الحالية تستخدم App Control for Business. عند مراجعة سيناريو PowerShell، ابحث عن دليل النسخة والسلوك الحالي، ولا تفترض أن شرحًا قديمًا يطابق كل نظام Windows أو كل محرك PowerShell.

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

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

ConstrainedLanguage وصف قدرات، وليس هوية مستخدم

وضع ConstrainedLanguage يقيد جوانب من لغة PowerShell وتفاعلاتها مع أنواع وطرق معينة. لا يعني أن الحساب صار مستخدمًا مختلفًا أو أن كل Cmdlet قراءة مُنع. كما أن FullLanguage لا يعطي الحساب حق تعديل كائن لا يملك تفويضًا عليه. اللغة والتفويض مستويان مختلفان.

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

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

ابدأ فحص الملف دون تشغيله

في Windows تقدر تقرأ التوقيع بأمر مثل Get-AuthenticodeSignature -FilePath 'C:\Lab\ApprovedTool.ps1'، حيث المسار لنسخة أداة موجودة وموافق عليها في مختبرك. راجع Status وStatusMessage وبيانات الشهادة التي تحتاجها للمطابقة. لا تنقل مخرجات شهادة أو مسار مؤسسة كاملة إلى مقال عام.

اقرأ التجزئة باستخدام Get-FileHash -Path 'C:\Lab\ApprovedTool.ps1' -Algorithm SHA256، وقارنها بقيمة موثوقة وفرها المشروع أو إجراء اعتماد المختبر. تجزئة حسبتها بنفسك دون مرجع تفيد لتحديد النسخة، لكنها لا تثبت أصلًا رسميًا. وحتى التطابق مع مرجع لا يثبت أن الوظيفة مناسبة لنطاقك أو أن النظام يسمح بتنفيذها.

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

فرق بين سلامة التوقيع وسلامة المصدر

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

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

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

Audit وEnforce يحتاجان قراءة أدق من الاسم

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

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

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

قارن حالات صغيرة بدل تشغيل أداة كاملة كل مرة

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

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

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

الوحدات والتبعيات جزء من سلسلة الثقة

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

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

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

التوقيع لا يعوض التحقق من المدخلات

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

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

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

وش ترسل لفريق المنصة إذا احتجت اعتمادًا؟

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

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

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

أخطاء تختصر عليك يومًا من التشخيص

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

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

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

المراجع والخلاصة العملية

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

مرجع السلوك الحالي وفروق الإصدارات: https://learn.microsoft.com/en-us/powershell/scripting/security/app-control/how-app-control-works . مرجع توقيع الملف: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-authenticodesignature . مرجع التجزئة: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash . وحدود اللغة: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_language_modes .

لنكمل الفكرة في المقال التالي عن JEA: هناك يمكن أن يُسمح لك بأوامر محددة داخل Endpoint إداري، مع اختلاف بين ما تراه أنت وما تنفذه الوظيفة خلف الواجهة. فهم App Control يساعدك، لكن لا تنقل افتراضاته إلى JEA مباشرة. لكل طبقة سؤال تفويض مختلف، والهدف أن تعرف بالضبط أي قدرة يتيحها سياقك قبل استخدام أي أداة.