سياسة تنفيذ PowerShell وتوقيع السكربتات ── دليل عمليّ للتخلّص من تشغيل «السدّ بـ Bypass»

«لا يعمل السكربت على جهاز جديد وتظهر رسالة (تعذّر تنفيذ هذا السكربت على هذا النظام لأنّ تنفيذ السكربتات معطَّل…)» أو «أضفتُ -ExecutionPolicy Bypass مؤقّتاً فعمل، فصار مكتوباً في كلّ المهام هكذا» أو «ملفّ .ps1 الموضوع في مجلّد مُشارَك يعطي خطأ توقيع على جهاز شخص واحد فقط» ── سياسة تنفيذ PowerShell عائق يكاد يكون مؤكَّداً الاصطدام به عند التوسّع في الأتمتة داخل الشركة. وفي كثير من مواقع العمل، تتراكم معالجة «السدّ بـ Bypass» دون فهم الآليّة.

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

في هذا المقال، وباستهداف مسؤولي أنظمة المعلومات في الشركات الصغيرة والمتوسّطة، ومَن يُؤتمِتون الأعمال الروتينيّة داخل الشركة عبر PowerShell، نرتّب - بالاستناد إلى الوثائق الرسميّة - حقيقة سياسة التنفيذ، وأولويّة النطاقات (scopes)، وعلاقتها بـ Zone.Identifier (المعروف بـ Mark of the Web)، وصولاً إلى تشغيل التوزيع عبر توقيع السكربتات.

1. الخلاصة أوّلاً

• سياسة التنفيذ جهاز أمان لا حدّ أمنيّ (security boundary). تنصّ الوثائق الرسميّة صراحةً على أنّها «ليست نظام أمان يقيِّد تصرّفات المستخدم» وأنّه «يمكن التحايل عليها بسهولة بإدخال محتوى السكربت في سطر الأوامر». الغرض منها وضع قاعدة أساسيّة ومنع التنفيذ غير المقصود (الحوادث العرَضيّة).¹
• ما تؤثِّر فيه سياسة التنفيذ هو تشغيل السكربتات فقط، أمّا تنفيذ الأوامر التفاعليّ فمتاح دائماً. الإعداد الافتراضيّ في Windows PowerShell 5.1 هو Restricted (لا يمكن تشغيل السكربتات) في أنظمة تشغيل العميل، وRemoteSigned في Windows Server. أمّا PowerShell 7 فإعداده الافتراضيّ RemoteSigned.²¹
• توجد للسياسة خمسة نطاقات (scopes)، والأولويّة هي MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine. نطاقا MachinePolicy وUserPolicy مخصَّصان لسياسة المجموعة فقط، ولا يمكن تغييرهما عبر Set-ExecutionPolicy، ولا يمكن تجاوزهما حتّى بتحديد في سطر الأوامر.¹³
• ما يطلب RemoteSigned توقيعاً له هو السكربتات «القادمة من الإنترنت» فقط. يُحدَّد المصدر عبر تيّار البيانات البديل Zone.Identifier (المعروف بـ Mark of the Web) المُلحَق بالملفّ، وبعد مراجعة المحتوى، يمكن إزالته عبر Unblock-File والتشغيل دون تغيير السياسة.¹⁴
• يطلب AllSigned توقيعاً من ناشر موثوق لجميع السكربتات، بما فيها المُنشأة محلّيّاً. يُضاف التوقيع عبر Set-AuthenticodeSignature، ويُضمَّن في نهاية الملفّ ككتلة تعليق # SIG #.¹⁵
• أضِف الطابع الزمنيّ (-TimestampServer) دائماً عند التوقيع. فمع وجوده تبقى صلاحيّة السكربت مستمرّة حتّى بعد انتهاء صلاحيّة شهادة التوقيع. ومعظم شهادات توقيع الشيفرة صالحة لمدّة سنة، فإغفال هذا يصبح قنبلة موقوتة سنويّاً.⁶⁵
• الشهادة الموقَّعة ذاتيّاً مقصورة على الاستخدام الاختباريّ. لا يمكن تشغيل سكربت موقَّع بشهادة موقَّعة ذاتيّاً على حاسوب آخر. استخدم لتوزيع المؤسّسة شهادة توقيع شيفرة صادرة عن مرجع مصادقة (سواء مرجع داخليّ أو تجاريّ).⁵⁷
• إن أردتَ الضبط على مستوى المؤسّسة، فأدِرها مركزيّاً عبر إعداد «تفعيل تنفيذ السكربتات» في سياسة المجموعة. يتقدَّم هذا الإعداد على جميع إعدادات النطاقات في جانب PowerShell.¹

2. حقيقة سياسة التنفيذ ── «جهاز أمان» لا «حدّ أمنيّ»

أوّلاً، لنؤكِّد الفرضيّة الأساسيّة. صياغة الوثائق الرسميّة (about_Execution_Policies) صريحة. سياسة التنفيذ هي «ميزة أمان (safety feature)» تتحكّم في الشروط التي بموجبها يقرأ PowerShell ملفّات الإعداد وينفِّذ السكربتات، وهي «ليست نظام أمان يقيِّد تصرّفات المستخدم». فحتّى المستخدم الذي لا يستطيع تشغيل السكربتات يمكنه تنفيذ المعالجة نفسها بلصق محتوى السكربت في سطر الأوامر. ومُدوَّن صراحةً أنّ دور سياسة التنفيذ هو ضبط قاعدة أساسيّة ومنع مخالفتها دون قصد.¹ وتتكرّر الوثائق التمهيديّة أيضاً في تأكيد أنّها «ليست حدّاً أمنيّاً؛ لا يمكنها إيقاف مستخدم يحاول تشغيل سكربت عمداً».²

بضبط هذا الموقع، يتحدَّد اتّجاه تصميم التشغيل. فكلٌّ من «شدَّدتُ سياسة التنفيذ فأصبح الهجوم مستحيلاً» و«لا فائدة منها لأنّها قابلة للتحايل على أيّ حال» خطأ. مقاومة الهجمات مهمّة طبقة أخرى (التحكّم في التطبيقات، وتقليل الصلاحيّات، وسجلّات التدقيق)، وسياسة التنفيذ مهمّتها منع الحوادث.⁸

لنرتّب الفروق بين السياسات الرئيسيّة.¹

غالباً ما يُغفَل أنّ Restricted لا يوقف سكربتات الأعمال فقط، بل يوقف أيضاً قراءة الملفّات الشخصيّة (profiles، .ps1) والوحدات (modules، .psm1) وملفّات إعداد التنسيق (.ps1xml).¹ و«عدم تحميل الملفّ الشخصيّ (profile) في جهاز جديد» بسبب سياسة التنفيذ استفسار كلاسيكيّ متكرِّر.

3. النطاقات (scopes) والأولويّة ── حقيقة «ضبطتُ الإعداد لكنّه لم يتغيّر»

سياسة التنفيذ ليست قيمة واحدة، بل يمكن ضبطها لكلّ نطاق (scope) من النطاقات الخمسة، وتصبح القيمة الفعليّة هي ذات الأولويّة الأعلى.¹

القاعدة الثابتة لتفكيك مشكلة «ضبطتُ الإعداد لكنّه لم يتغيّر» هي النظر إلى القائمة الكاملة، لا القيمة الفعليّة فقط.

# لا تكتفِ بالقيمة الفعليّة، بل تحقَّق دائماً من أيّ نطاق هو الفعّال
Get-ExecutionPolicy -List

# مثال: حتّى لو ضُبِط LocalMachine على AllSigned، يفوز RemoteSigned الخاصّ بـ CurrentUser
#         Scope ExecutionPolicy
#         ----- ---------------
# MachinePolicy       Undefined
#    UserPolicy       Undefined
#       Process       Undefined
#   CurrentUser    RemoteSigned
#  LocalMachine       AllSigned

# إن أردتَ تغيير بيئتك الخاصّة فقط، فنطاق CurrentUser الذي لا يتطلّب صلاحيّات المسؤول هو الأسهل
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

بما أنّ CurrentUser له أولويّة على LocalMachine، فإنّ السياسة الفعليّة في المثال أعلاه هي RemoteSigned.¹ يكتب Set-ExecutionPolicy افتراضيّاً في نطاق LocalMachine، لذا يتطلّب صلاحيّات المسؤول، لكن يمكن للمستخدم العاديّ تغييره في نطاق CurrentUser.³

والأداة الرئيسيّة لإدارة المؤسّسة هي سياسة المجموعة. تتقدَّم سياسة «تفعيل تنفيذ السكربتات (Turn on Script Execution)» على جميع النطاقات المضبوطة في جانب PowerShell. عند تعطيلها يكون الأثر مساوياً لِـ Restricted، وعند تفعيلها يمكن الاختيار من بين «السماح بجميع السكربتات (Unrestricted)»، و«السماح بالسكربتات المحلّيّة والسكربتات البعيدة الموقَّعة (RemoteSigned)»، و«السماح بالسكربتات الموقَّعة فقط (AllSigned)»، وتوجد ضمن قالب الإدارة تحت مكوّنات Windows\Windows PowerShell. ويتقدَّم تكوين الحاسوب على تكوين المستخدم.¹ وفي البيئات المُدارة عبر GPO، يحفظ Set-ExecutionPolicy الإعداد لكن دون أن يكون فعّالاً، وتظهر رسالة توضِّح التعارض.³

وثمّة نتيجة مهمّة هنا. إذا كانت الإدارة عبر GPO، فإنّ -ExecutionPolicy Bypass المكتوب في المهام أو الاختصارات لا يعمل. فتحديد نطاق Process يتفوّق على تكوين LocalMachine/CurrentUser، لكن مُدوَّن صراحةً أنّه لا يتفوّق على سياسة المجموعة.¹ وبعبارة أخرى، فإنّ «كتابة Bypass تحلّ المشكلة» لا يصحّ إلّا في البيئات التي لا تُدير فيها المؤسّسة سياسة التنفيذ أصلاً.

4. Zone.Identifier (المعروف بـ Mark of the Web) وUnblock-File

«البُعد (القدوم من الإنترنت)» في RemoteSigned يُحدَّد بـعلامة، لا بمكان تخزين الملفّ. تضيف برامج مثل المتصفّح تيّار بيانات بديلاً إلى الملفّات المُنزَّلة، فتُعلَّم بأنّها «ملفّات قادمة من الإنترنت».¹ هذا التيّار هو Zone.Identifier، وتحمل قيمته 3 التي تدلّ على منطقة الإنترنت (internet zone). وهذا هو ما يُعرَف بـ Mark of the Web.⁴

عند محاولة تشغيل سكربت غير موقَّع يحمل هذه العلامة في بيئة RemoteSigned، يُحظَر التنفيذ برسالة خطأ «غير موقَّع رقميّاً». المعالجة على مرحلتين.

# 1) تحقَّق أوّلاً من الملفّات المحظورة (عمليّة قراءة فقط، آمنة)
Get-Item -Path C:\Tools\*.ps1 -Stream Zone.Identifier -ErrorAction SilentlyContinue

# 2) راجع المحتوى، وأزِل الحظر فقط عمّا حُكِم بأنّه آمن
#    (يزيل Unblock-File تيّار Zone.Identifier فقط. سياسة التنفيذ نفسها لا تتغيّر)
Unblock-File -Path C:\Tools\Get-InventoryReport.ps1

Unblock-File أمر (cmdlet) يزيل تيّار البيانات البديل Zone.Identifier، وهو نفس عمل زرّ «السماح (Unblock)» في خصائص مستكشف الملفّات. النقطة الجوهريّة هي إمكانيّة تمرير الملفّات المؤكَّدة فقط دون تخفيف سياسة التنفيذ.⁴ وتجعل الوثائق الرسميّة أيضاً «مراجعة الملفّ ومصدره والتحقّق من أمانه قبل الاستخدام» خطوة إلزاميّة.⁴³

يستحقّ الأمر معرفة فخّ في الاتّجاه المعاكس أيضاً. لا تضع كلّ طرق الحصول على الملفّ Mark of the Web. مُدوَّن صراحةً أنّ الملفّات المُنزَّلة عبر curl.exe أو Invoke-WebRequest أو Invoke-RestMethod قد لا تحمل علامة منطقة الإنترنت.¹ بمعنى آخر، فإنّ RemoteSigned ليس ضماناً لـ«إيقاف كلّ الملفّات الخطِرة المُنزَّلة» (وهذا بالضبط سبب كونه جهاز أمان لا حدّاً أمنيّاً). وتوجد أيضاً ملاحظة تحذيريّة بأنّه في الأنظمة المُهيَّأة بحيث لا تفرِّق بين مسار UNC ومسار الإنترنت، قد تُرفَض سكربتات في مجلّد مُشارَك بواسطة RemoteSigned.¹ عندما يتوقَّف ملفّ .ps1 موضوع في مجلّد مُشارَك على بعض الأجهزة فقط، اشتبِه في إعدادات المنطقة (zone) ووجود Zone.Identifier من عدمه.

بالمناسبة، آليّة SmartScreen التي تسبِّب ظاهرة مشابهة في جانب الملفّات التنفيذيّة (.exe) المُنزَّلة مشروحة في «لماذا تظهر عبارة (حمى Windows جهاز الكمبيوتر الخاصّ بك) في Windows».

5. الممارسة العمليّة لتوقيع السكربتات ── Set-AuthenticodeSignature والطابع الزمنيّ

للانتقال إلى تشغيل AllSigned، أو تشغيل توقيع المُوزَّعات في بيئة RemoteSigned، يلزم وجود شهادة توقيع شيفرة. يمكن تصنيف طرق الحصول عليها في ثلاثة.⁵

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

لنتحقّق أوّلاً من سير العمل باستخدام شهادة موقَّعة ذاتيّاً لأغراض الاختبار.

# إنشاء شهادة توقيع شيفرة لأغراض الاختبار (موقَّعة ذاتيّاً ── موثوقة على هذا الجهاز فقط)
$params = @{
    Subject           = 'CN=KomuraSoft Code Signing (Test)'
    Type              = 'CodeSigningCert'
    CertStoreLocation = 'Cert:\CurrentUser\My'
    HashAlgorithm     = 'sha256'
}
$cert = New-SelfSignedCertificate @params

New-SelfSignedCertificate أمر (cmdlet) لإنشاء شهادة موقَّعة ذاتيّاً لأغراض الاختبار، وعند تحديد -Type CodeSigningCert يُدرَج امتداد مخصَّص لتوقيع الشيفرة. مدّة الصلاحيّة الافتراضيّة سنة واحدة.⁷ عند استخدام شهادة موقَّعة ذاتيّاً لاختبار بيئة AllSigned، يلزم تسجيلها في مخزن مرجع المصادقة الجذريّ الموثوق لذلك الجهاز.⁵

توقيع الإنتاج الفعليّ هو هذا السطر الواحد.

# الحصول على شهادة توقيع الشيفرة من مخزن الشهادات والتوقيع بها
# -CodeSigningCert يقتصر فقط على "الشهادات القابلة للاستخدام لتوقيع الشيفرة"،
# لذا قيِّدها بما هو ساري المفعول ويملك مفتاحاً خاصّاً، وفي البيئات التي بها أكثر من شهادة حدِّدها بـ Subject أو Thumbprint
$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert |
    Where-Object { $_.HasPrivateKey -and $_.NotAfter -gt (Get-Date) -and
                   $_.Subject -eq 'CN=KomuraSoft Code Signing (Test)' } |
    Sort-Object NotAfter -Descending |
    Select-Object -First 1   # عند وجود أكثر من شهادة بنفس Subject (كحالة التجديد)، اقتصر على الأبعد صلاحيّةً

# الطابع الزمنيّ إلزاميّ. يبقى التوقيع صالحاً حتّى بعد انتهاء صلاحيّة الشهادة
# استبدل الرابط بخدمة الطابع الزمنيّ التي يوجِّه إليها مُصدِر الشهادة (المرجع الداخليّ/جهة الشراء)
Set-AuthenticodeSignature -FilePath .\Invoke-NightlyBatch.ps1 -Certificate $cert `
    -HashAlgorithm SHA256 -TimestampServer 'http://timestamp.example.com'

# يمكن التحقّق من حالة التوقيع عبر Get-AuthenticodeSignature (Valid/NotSigned/HashMismatch وما شابه)
Get-AuthenticodeSignature -FilePath .\Invoke-NightlyBatch.ps1

توجد ثلاث مواصفات ينبغي ضبطها.⁶⁵

• يُضمَّن التوقيع ككتلة تعليق # SIG # في نهاية الملفّ. إن وُجِد توقيع سابق يُستبدَل. أي إنّ تعديل السكربت ولو بحرف واحد بعد التوقيع يُبطِل التوقيع. وهذا ما يعمل كوسيلة لكشف التعديل.
• تحديد -TimestampServer يمنع فشل السكربت حتّى بعد انتهاء صلاحيّة الشهادة. صلاحيّة التوقيع هي «طوال سريان شهادة التوقيع» أو «طالما يستطيع خادم الطابع الزمنيّ التحقّق من أنّ التوقيع تمّ بينما كانت الشهادة سارية»، ومعظم شهادات توقيع الشيفرة صالحة لمدّة سنة، فالطابع الزمنيّ هو شريان الحياة للتشغيل طويل الأمد.⁶⁵ اتّبع إرشادات مُصدِر الشهادة (مرجع المصادقة) بخصوص رابط خدمة الطابع الزمنيّ المستخدَمة.
• السكربتات المُوقَّعة في Windows PowerShell 5.1 أو ما قبل PowerShell 7.2 كان يلزم حفظها بترميز ASCII أو UTF8NoBOM. أمّا PowerShell 7.2 فما بعده فيدعم السكربتات الموقَّعة بأيّ ترميز.⁵ في مواقع العمل التي لا تزال تستخدم 5.1، احذر من أنّ ترميز السكربتات ذات التعليقات باللغة اليابانيّة قد يُفسِد التحقّق من التوقيع بسهولة. راجع «الفرق بين Windows PowerShell 5.1 وPowerShell 7 والترحيل بينهما» بخصوص الفروق العامّة بين 5.1 و7.

في بيئة AllSigned، إذا كان السكربت موقَّعاً لكن لم يُصنَّف الناشر بعد كـ«موثوق/مرفوض»، تظهر عند التنفيذ مطالبة «هل تريد تشغيل برمجيّة من هذا الناشر غير الموثوق؟». إذا اختيرت «التشغيل دائماً» لن يُطلَب التأكيد لهذا الناشر بعد ذلك.¹⁵ وفي تشغيل مرجع المصادقة الداخليّ، إذا وُزِّعت شهادة الناشر أيضاً إلى «الناشرون الموثوقون» على كلّ جهاز، يمكن إزالة هذا التأكيد من التشغيل تماماً.

6. القواعد الثابتة في العمل الفعليّ (جدول القرار) ── من «السدّ بـ Bypass» إلى تشغيل التوقيع

القاعدة الثابتة للتفكير في ضبط توزيع سكربتات الشركة وتشغيلها هي جدول القرار التالي.

لنكمِّل السطر الأخير بتوضيح. مشكلة تشغيل «السدّ بـ ExecutionPolicy Bypass» ليست فتح ثغرة أمنيّة بحدّ ذاتها (فسياسة التنفيذ ليست حدّاً أمنيّاً من الأساس). المشكلة في النقاط الثلاث التالية.

• التخلّي عن جهاز الأمان ── تُزال بشكل دائم الشبكة الأخيرة التي تمنع حادثة تشغيل سكربت آخر عن غير قصد، أو تشغيل سكربت مُعدَّل دون الانتباه إليه.
• الانفصال عن الضبط المؤسّسيّ ── في اللحظة التي تبدأ فيها إدارة سياسة التنفيذ عبر GPO، يتوقّف تحديد Bypass عن العمل، وتفشل جميع المهامّ التي كانت «مسدودة» به دفعة واحدة.¹ وهذا دَين تقنيّ سببه أنّ «سبب عمل الأمر» كان ثغرة خارج نطاق الضبط.
• إرباك تحقيق الأسباب ── عندما ينتشر Bypass، يصبح من المستحيل استنتاج السلوك من السياسة الفعليّة للبيئة، ويصعب تحقيق الفروق بين الأجهزة (لماذا يفشل هذا الجهاز فقط).

Bypass نفسه إعداد أُعِدَّ للتركيبات التي تضبطها تطبيقات مُدمِجة PowerShell بنموذج أمان خاصّ بها.¹ افصل الأمر بوضوح بأنّه ليس شيئاً يُستخدَم دائماً في خيارات تشغيل سكربتات التشغيل التي كتبها بشر. بناء تشغيل دوريّ آمن عبر Task Scheduler مشروح بالتفصيل في «مهمّة Task Scheduler لا تُنفَّذ أو تنتهي بـ 0x1 ── تفكيك الأسباب وتصميم تشغيل آمن».

7. الخلاصة

• سياسة التنفيذ جهاز أمان لا حدّ أمنيّ. نفِّذ مقاومة الهجمات في طبقة أخرى، واترك لسياسة التنفيذ مهمّة «منع الحوادث غير المقصودة».
• تملك السياسة خمسة نطاقات، وترتيب الأولويّة هو MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine. ابدأ التفكيك من Get-ExecutionPolicy -List.
• ما يراقبه RemoteSigned هو Zone.Identifier (المعروف بـ Mark of the Web). مرِّر الملفّات المؤكَّدة عبر Unblock-File دون تخفيف السياسة.
• نفِّذ التوقيع عبر Set-AuthenticodeSignature، وحدِّد -TimestampServer دائماً. للتوزيع الداخليّ استخدم شهادة صادرة عن مرجع مصادقة داخليّ، والشهادة الموقَّعة ذاتيّاً للاختبار فقط.
• ركِّز ضبط المؤسّسة عبر إعداد «تفعيل تنفيذ السكربتات» في سياسة المجموعة. يتقدَّم هذا الإعداد على جميع النطاقات وتحديد -ExecutionPolicy.
• الاستخدام الدائم لـ -ExecutionPolicy Bypass تخلٍّ عن جهاز الأمان، ولا يعمل تحت إدارة GPO. الطريق السليم هو الاستغناء عن «السدّ» عبر تجهيز سياسة البيئة وتشغيل التوقيع.

مقالات ذات صلة

• أساسيّات أوامر PowerShell ── العمليّات الأولى الواجب تعلّمها والاستخدام الآمن
• لماذا تظهر عبارة (حمى Windows جهاز الكمبيوتر الخاصّ بك) في Windows
• مهمّة Task Scheduler لا تُنفَّذ أو تنتهي بـ 0x1 ── تفكيك الأسباب وتصميم تشغيل آمن
• معالجة الأخطاء وتصميم إعادة التنفيذ (retry) في سكربتات PowerShell
• الفرق بين Windows PowerShell 5.1 وPowerShell 7 والترحيل بينهما
• قرار الترحيل من ملفّات Batch إلى PowerShell

مجالات الاستشارة ذات الصلة

تتعامل شركة Komura Soft LLC مع تصميم سياسة تنفيذ سكربتات PowerShell الداخليّة وتشغيل التوقيع، ودراسة النشر عبر سياسة المجموعة، وتحقيق فروق البيئة من نوع «لا يعمل السكربت إلّا على جهاز معيّن». كما يمكننا دعم نقل أصول الدُفعات (batch) والسكربتات القائمة إلى تشغيل آمن.

• الاستشارة التقنيّة ومراجعة التصميم
• تحقيق الأعطال وتحليل الأسباب
• تحديث تطبيقات Windows وصيانتها
• التواصل معنا

المراجع

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل سياسة تنفيذ PowerShell ميزة أمنيّة؟

تنصّ الوثائق الرسميّة صراحةً على أنّ «سياسة التنفيذ ليست نظام أمان يقيِّد تصرّفات المستخدم». فيمكن التحايل عليها بسهولة بلصق محتوى السكربت في سطر الأوامر. الغرض من سياسة التنفيذ هو وضع قاعدة أساسيّة، وهو جهاز أمان يمنع حادثة «تنفيذ سكربت غير مقصود عن غير قصد»، ولا ينبغي بناء التصميم عليها كحدّ أمنيّ (security boundary) يوقف المهاجمين. تُنفَّذ مقاومة الهجمات في طبقة أخرى (كالتحكّم في التطبيقات، وتقليل الصلاحيّات إلى الحدّ الأدنى).

ما الفرق بين RemoteSigned وAllSigned؟

يطلب RemoteSigned توقيعاً من ناشر موثوق فقط للسكربتات القادمة من الإنترنت (التي تحمل Mark of the Web)، ويمكن تشغيل السكربتات المُنشأة محلّيّاً دون توقيع. أمّا AllSigned فيطلب توقيعاً لكلّ السكربتات وملفّات الإعداد، بما فيها المُنشأة محلّيّاً، ويطلب تأكيداً قبل التنفيذ للسكربتات من ناشرين غير مصنَّفين. إذا استطاعت الشركة تجهيز تشغيل التوقيع (توزيع شهادة توقيع الشيفرة وإجراءات التوقيع)، فـ AllSigned هو الخيار المناسب، وإن لم يتوفّر هذا النظام فإنّ RemoteSigned خيار واقعيّ.

لماذا يتعذّر تنفيذ سكربت مُنزَّل من الإنترنت مع ظهور رسالة «غير موقَّع رقميّاً»؟

لأنّ الملفّات المُنزَّلة عبر المتصفّح ونحوه يُضاف إليها تيّار بيانات بديل (alternate data stream) اسمه Zone.Identifier، فتُعامَل كـ«ملفّ قادم من الإنترنت». عندما تكون سياسة التنفيذ هي RemoteSigned، يُحظَر تشغيل السكربت غير الموقَّع الحامل لهذه العلامة. فإن راجعتَ المحتوى وحكمتَ بأنّه آمن، يمكن إزالة Zone.Identifier عبر أمر (cmdlet) باسم Unblock-File أو زرّ «السماح» في خصائص الملفّ من مستكشف الملفّات، فيصبح قابلاً للتشغيل دون تغيير سياسة التنفيذ.

ما الأسلوب الواقعيّ لتشغيل سكربتات PowerShell المُوزَّعة داخل الشركة؟

يوجد خياران رئيسيّان. الأوّل هو RemoteSigned مع الوضع في خادم ملفّات، ويمكن البدء به دون بناء آليّة توقيع، لكن قد يتعطَّل التشغيل بسبب لصق Mark of the Web حسب مسار التوزيع، ولا يمكنه كشف تعديل السكربت. الثاني هو AllSigned مع تشغيل التوقيع، حيث يُوقَّع عبر Set-AuthenticodeSignature باستخدام شهادة توقيع شيفرة (يكون إصدارها من مرجع مصادقة داخل الشركة واقعيّاً)، وتُدار السياسة مركزيّاً عبر سياسة المجموعة (Group Policy). ومقابل فعاليّة ضبط سياسة التنفيذ وكشف التعديل، تترتّب تكلفة تشغيليّة لتوزيع الشهادات وتجديدها.

هل يجوز الاستمرار في تحديد -ExecutionPolicy Bypass في Task Scheduler؟

يعمل، لكن لا يُنصَح به. أوّلاً، في البيئات التي تُدار فيها سياسة التنفيذ عبر سياسة المجموعة، لا يفوز تحديد ExecutionPolicy في سطر الأوامر على سياسة المجموعة، فلا يعمل من الأساس. كما أنّ الاستخدام الدائم لـ Bypass هو تشغيل يزيل بنفسه جهاز الأمان الذي «يمنع التنفيذ عن غير قصد»، ويصبح سبباً لتباعد سياسة المؤسّسة عن واقع الميدان. إن أردتَ تشغيلاً دائماً، فالمنطق السليم هو ضبط سياسة البيئة بشكل مناسب عبر سياسة المجموعة أو Set-ExecutionPolicy من قِبل المسؤول، وإظهار الثقة من جانب السكربت عبر التوقيع.

لماذا تلزم الطابع الزمنيّ (-TimestampServer) في توقيع السكربتات؟

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

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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