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

«على حاسوب جديد لا يعمل السكربت مع رسالة “このシステムではスクリプトの実行が無効になっているため…”» أو «أضفتُ -ExecutionPolicy Bypass مؤقّتاً فعمل، فكُتب ذلك على كلّ المهام» أو «ملفّ .ps1 الموضوع في مجلّد مشترك يظهر خطأ توقيع على جهاز شخص واحد فقط» ── سياسة تنفيذ PowerShell جدار تصطدم به حتماً تقريباً عند المضيّ في الأتمتة داخل الشركة. وفي كثير من المواقع تتراكم معالجات «السدّ بـ Bypass» دون فهم الآليّة.

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

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

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

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

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 18، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

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

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

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

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

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

3. النطاقات والأولويّة ── هويّة «ضبطتُ لكنّه لا يتغيّر»

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

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

# 実効ポリシーだけでなく、どのスコープが効いているかを必ず確認する
Get-ExecutionPolicy -List

# 例: LocalMachineをAllSignedにしていても、CurrentUserのRemoteSignedが勝つ
#         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 Components\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 الدالّة على منطقة الإنترنت. ما يُدعى Mark of the Web.⁴

تيّار البيانات البديل (Alternate Data Streams) ميّزة NTFS. في NTFS يمكن لملفّ واحد أن يحمل عدّة تيّارات بيانات، و«محتوى الملفّ» الذي نراه دائماً يدخل في التيّار الافتراضيّ بلا اسم. بمعزل عن ذلك، يمكن إلحاق تيّار مسمّى بالكتابة اسم الملفّ:اسم التيّار.⁹ Zone.Identifier أحد تلك التيّارات المسمّاة، لذا لا يتغيّر متن السكربت بايت واحد ومع ذلك تتغيّر قابليّة التنفيذ فقط. لهذا يعمل المحتوى نفسه أو لا يعمل حسب الجهاز، وبالمقابل إن مرّ عبر نظام ملفّات غير NTFS (مثل FAT32 في ذاكرة USB) يسقط التيّار بأكمله، فقد تختفي العلامة ويبدأ العمل.

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

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

آليّة SmartScreen التي تُحدث أعراضاً مشابهة في جانب الملفّات التنفيذيّة المنزَّلة (.exe) تناولناها في «سبب ظهور «حمت Windows جهاز الكمبيوتر» في Windows».

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

للمضيّ في تشغيل AllSigned، أو توقيع المواد الموزَّعة في بيئة RemoteSigned، تلزم شهادة توقيع شيفرة. مسارات الحصول ثلاثة.⁵

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

عند الإصدار من مرجع داخليّ، ماذا بعد ذلك؟

إن انتهى الحديث عند «المرجع الداخليّ واقعيّ» يتعذّر اتخاذ الخطوة التالية، فنكتب الترتيب. AD CS دور Windows Server يوفّر بنية مفاتيح عامّة (PKI)، ويتكوّن من خدمات أدوار مثل مرجع المصادقة (CA) والتسجيل عبر الويب والمستجيب عبر الإنترنت (OCSP).¹⁰

1. تحقّق ممّا إذا كان هناك مرجع داخليّ. أوّلاً يتحقّق جانب نظم المعلومات ممّا إذا كان في الشركة مرجع مؤسّسي لـ AD CS. إن لم يوجد، إنشاء مرجع لأجل توقيع الشيفرة وحده قرار ثقيل. وازن تكلفة شراء شهادة واحدة مع عبء التشغيل مثل بناء المرجع والنسخ الاحتياطيّ ونشر قائمة الإلغاء (CRL) وحماية المفاتيح، وقارنها بشراء مرجع تجاريّ.
2. اطلب تجهيز قالب شهادة لتوقيع الشيفرة. عمل جانب المرجع. انسخ قالب «توقيع الشيفرة» الافتراضيّ، واضبط على النسخة المدّة وطول المفتاح ومجموعة الأمان التي يمكنها الطلب (ضيِّقها على مسؤولي التوقيع فقط)، واطلب إضافته إلى قوالب جهة الإصدار في وحدة تحكّم «مرجع المصادقة». عدم تحرير القالب الافتراضيّ مباشرة لأنّ التأثير يمتدّ إلى النطاق بأكمله ويصعب الرجوع.

3. يطلب مسؤول التوقيع الشهادة. على الجهاز الذي يوقّع، اطلب بتعيين اسم القالب لأمر Get-Certificate. إن صدرت تدخل مخزن الأفراد كما هي (المخزن الذي يمكن لهذا الأمر تخزين الشهادة فيه هو مخزن My فقط).¹¹

   # 社内のエンタープライズCAへ、テンプレート名を指定して要求する(Windows統合認証)
   # 'CodeSigning' の部分は、CA管理者が発行対象として公開したテンプレート名に置き換える
   $result = Get-Certificate -Template 'CodeSigning' -Url ldap: `
       -CertStoreLocation Cert:\CurrentUser\My
   $result.Status        # Issued なら発行済み、Pending なら承認待ち
   

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

عمل جانب المرجع (الخطوة 2) كثيراً ما لا يكتمل بنظم المعلومات وحدها، لذا حدِّد أوّلاً تأكيد الخطوة 1 وسياسة توزيع الخطوة 4 ثمّ استشر مسؤول المرجع فيتقدّم الحديث بسرعة.

ماذا في بيئة غير منضمّة إلى نطاق (مجموعة عمل)؟

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

• اضبط سياسة التنفيذ لكلّ جهاز، وتحقّق من اتّساقها. أدخل Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser (LocalMachine بامتيازات مدير إن أردتَ التأثير على كلّ المستخدمين) في دليل التجهيز.³ بما أنّه لا يوجد فرض بـ GPO، يبقى مجال التغيير العشوائيّ لكلّ جهاز، فاجعله مع تشغيل التحقّق من نتيجة Get-ExecutionPolicy -List عند الجرد.
• اجعل أصل السكربت موضعاً واحداً وضيِّق الكتابة. حدِّد موضعاً واحداً في مجلّد مشترك أصلاً، واجعل إذن الكتابة للمسؤولين فقط. ما تمنعه سياسة التنفيذ هو «غير المقصود» فقط، فمنع التعديل عمل أذونات وصول NTFS.
• إن طلبتَ حتى التوقيع، قارن بالتكلفة توزيع شهادة موقَّعة ذاتياً أو شراء مرجع تجاريّ. الوثائق الرسميّة تعدّ «السكربت الموقَّع بشهادة موقَّعة ذاتياً لا يُنفَّذ على حواسيب أخرى» و«غير مناسب للسكربتات المراد مشاركتها».⁵ غير أنّ هذا وصف للحالة الافتراضيّة، بمعنى أنّ الأجهزة الأخرى لا تثق بتلك الشهادة فلا يعمل. بالمقابل، إن وُزِّعت الثقة يعمل. نرتّب الفصل في الفقرة التالية.
• اكتب التعامل مع Mark of the Web في الدليل. قد تحمل .ps1 المستلَمة عبر البريد أو مشاركة خارجيّة علامة، فنصّ حتى «راجع المحتوى ثمّ Unblock-File» كإجراء (الفصل 4).⁴

إن استخدمتَ شهادة موقَّعة ذاتياً في مجموعة عمل

التوقّف عند «الموقَّعة ذاتياً لا تُستخدَم إلا على الجهاز الذي وقّع» يفرض شراء مرجع تجاريّ على شركة ذات 10 أو 20 جهازاً. في الواقع، إن وُزِّئ الجزء العامّ من الشهادة إلى كلّ جهاز يمرّ AllSigned. الفرق فقط التوزيع يدوياً أو بمثبِّت أو بـ MDM (Intune ونحوه) بدل GPO.

ما يُوزَّع هو الجزء العامّ فقط، والمفتاح الخاصّ لا يخرج من الجهاز الذي يوقّع.

# 【署名する端末で1回】公開部分だけをエクスポートする(-Certは秘密鍵を含まない)
$cert = Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert |
        Where-Object Subject -eq 'CN=KomuraSoft Code Signing (Test)'
Export-Certificate -Cert $cert -FilePath .\KomuraSoftCodeSigning.cer

# 【各端末で1回・要管理者権限】ルートと発行元の両方へ入れる。
# ルートに入れないと署名の検証自体が通らず(自己署名なので自分がルート)、
# 発行元に入れないとAllSignedのプロンプトが出続ける
Import-Certificate -FilePath .\KomuraSoftCodeSigning.cer `
    -CertStoreLocation Cert:\LocalMachine\Root
Import-Certificate -FilePath .\KomuraSoftCodeSigning.cer `
    -CertStoreLocation Cert:\LocalMachine\TrustedPublisher

بعد ذلك، انظر أوّلاً إلى التكلفة التي تتحمّلها. فرق المرجع التجاريّ يظهر هنا.

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

مخزن الشهادات ومحرّك Cert:

قبل الدخول في شيفرة التوقيع كلمة عن Cert:. Cert: محرّك افتراضيّ يوفّره موفِّر شهادات PowerShell، يمكن به تتبّع مخزن الشهادات كمسار كما في نظام الملفّات.¹³ البنية طبقتان Cert:\<مكان المخزن>\<اسم المخزن>، ومكان المخزن اثنان CurrentUser (للمستخدم المسجَّل الدخول) وLocalMachine (للحاسوب بأكمله)، وأسماء المخازن مثل My (أفراد) وRoot (مرجع المصادقة الجذر الموثوق) وTrustedPublisher (الناشرون الموثوقون). تُعرَّف كلّ شهادة ببصمة (Thumbprint)، ويمكن سردها بـ Get-ChildItem.¹³

أي أنّ Cert:\CurrentUser\My هو «مخزن أفراد المستخدم الحاليّ»، وGet-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert التالي يعني «أخرج كلّ شهادات توقيع الشيفرة هناك». -CodeSigningCert معامل خاصّ بموفِّر الشهادات لتضييق الشهادات ذات استخدام مفتاح موسَّع (EKU) لتوقيع الشيفرة.¹³

أوّلاً أكِّد التدفّق بشهادة موقَّعة ذاتياً للاختبار.

# テスト用のコード署名証明書を作る(自己署名 ── この端末でしか信頼されない)
$params = @{
    Subject           = 'CN=KomuraSoft Code Signing (Test)'
    Type              = 'CodeSigningCert'
    CertStoreLocation = 'Cert:\CurrentUser\My'
    HashAlgorithm     = 'sha256'
}
$cert = New-SelfSignedCertificate @params

New-SelfSignedCertificate أمر ينشئ شهادة موقَّعة ذاتياً لغرض الاختبار، وبتعيين -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 بعد التجديد مثلاً فاختر الأبعد أجلاً واحدة

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

# يمكن التحقّق من حالة التوقيع بـ Get-AuthenticodeSignature (Valid/NotSigned/HashMismatch وغيرها)
# إن لم يكن TimeStamperCertificate فارغاً فالختم الزمنيّ مرفق
Get-AuthenticodeSignature -FilePath .\Invoke-NightlyBatch.ps1 |
    Format-List -Property Status, SignerCertificate, TimeStamperCertificate

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

• يُضمَّن التوقيع ككتلة تعليق # SIG # في نهاية الملفّ. إن وُجد توقيع قائم يُستبدَل. أي أنّ تعديل حرف واحد في السكربت بعد التوقيع يُبطل التوقيع. هذا يعمل ككشف للتعديل.
• تعيين -TimestampServer يجعل السكربت لا يفشل حتى بعد انتهاء أجل الشهادة. صلاحيّة التوقيع «ما دامت شهادة التوقيع سارية» أو «ما أمكن لخادم الختم الزمنيّ التحقّق من أنّ التوقيع تمّ بينما كانت الشهادة سارية»، ومعظم شهادات توقيع الشيفرة مدّتها سنة، فالختم الزمنيّ شريان التشغيل الطويل.⁶⁵ لا تعيِّن قيمة وهميّة للعنوان، بل خدمة قائمة متوافقة مع RFC 3161. المرشّح الأوّل العنوان الذي يرشده مصدر إصدار الشهادة (المرجع الذي اشتريتَ منه)، فمثلاً تنشر DigiCert http://timestamp.digicert.com.¹⁴ لاحظ أنّ خدمات أدوار AD CS لا تتضمّن ما لاستجابة الختم الزمنيّ¹⁰، لذا حتى عند التوقيع بشهادة صادرة عن مرجع داخليّ، يصير تكوين جهة الحصول على الختم الزمنيّ خدمة خارجيّة عادة. هذا يسهل إغفاله عند النظر في إدخال مرجع داخليّ، فتحقّق حتى من إمكان الوصول الشبكيّ إلى ذلك العنوان (السماح في الوكيل وجدار الحماية). بعد التوقيع، إن لم يكن TimeStamperCertificate في Get-AuthenticodeSignature فارغاً، يمكن التحقّق من أنّ الختم الزمنيّ أُضيف فعلاً.
• السكربتات التي تُوقَّع في Windows PowerShell 5.1 أو ما قبل PowerShell 7.2 كانت تحتاج الحفظ بـ ASCII أو UTF8NoBOM. من PowerShell 7.2 يُدعم السكربت الموقَّع بأيّ ترميز.⁵ في المواقع التي يبقى فيها 5.1، يسهل وقوع حادث انكسار التحقّق من التوقيع بترميز سكربت يتضمّن تعليقات يابانية، فانتبه. الفروق العامّة بين 5.1 و7 راجع «الفروق بين Windows PowerShell 5.1 وPowerShell 7 والترحيل».

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

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

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

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

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

Bypass نفسه إعداد جُهِّز لتكوين تضبط فيه تطبيق مضمَّن لـ PowerShell بنموذج أمان خاصّ.¹ اعتبره ليس ممّا يُستخدَم دائماً في خيارات تشغيل سكربتات التشغيل التي يكتبها إنسان. بناء التنفيذ الدوريّ الآمن في جدولة المهام تناولناه بالتفصيل في «مهمة جدولة المهام لا تُنفَّذ أو تنتهي بـ 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
• مهمة جدولة المهام لا تُنفَّذ أو تنتهي بـ 0x1 ── فرز السبب وتصميم تشغيل آمن
• معالجة الأخطاء وتصميم إعادة التنفيذ (إعادة المحاولة) في سكربتات PowerShell
• الفروق بين Windows PowerShell 5.1 وPowerShell 7 والترحيل
• قرار الترحيل من ملفّات الدفعة إلى PowerShell

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

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

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

روابط مرجعية

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

غو كومورا

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

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