لماذا تظهر رسالة «قامت Windows بحماية جهاز الكمبيوتر الخاص بك»

نرتّب SmartScreen وتوقيع الشيفرة وشهادات EV/OV وتوزيع MSIX/Store من منظور عمليّ

عند إنشاء تطبيق Windows وتوزيعه، أوّل عائق يصطدم به الكثيرون هو هذا التحذير.

قامت Windows بحماية جهاز الكمبيوتر الخاص بك
منع Microsoft Defender SmartScreen بدء تشغيل تطبيق غير معروف.

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

يرتّب هذا المقال تحذير SmartScreen عند توزيع تطبيقات Windows من زوايا توقيع الشيفرة وشهادات EV/OV و MSIX و Microsoft Store و ClickOnce والتوزيع الداخليّ.

1. هذا المقال في جملة واحدة

في توزيع تطبيقات Windows توقيع الشيفرة لازم.
لكن توقيع الشيفرة ليس سحراً يمحو تحذير SmartScreen حتماً.

المهمّ الفصل بين ثلاث زوايا.

معيار الحكم التقريبيّ كالتالي.

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

2. SmartScreen ليس «حكماً بوجود فيروس» وحده

حين يظهر تحذير SmartScreen يشعر المستخدم أنّ «التطبيق خطر».

لكن SmartScreen لا ينظر ببساطة إلى «هل هو فيروس» فقط. وفق شرح Microsoft ينظر أساساً إلى معلومات سمعة كهذه عن الملفّ المُنزَّل.

المهمّ هنا أنّ الملفّ المُنشَأ حديثاً ما زال بلا سمعة.

حتّى إن كان تطبيقاً صحيحاً من جهتكم، فمن منظور Windows هو «ملفّ يُرى للمرّة الأولى». حتّى مع التوقيع قد يظهر تحذير SmartScreen طالما لم تكفِ سمعة تجزئة الملفّ أو الناشر.

أي يسهل فهم تحذير SmartScreen كالتالي.

ليس معنى أنّه حُكم عليه بأنّه برمجيّة خبيثة.
لكنّه يعني أنّ Windows لم يحكم بعد بأنّه موثوق بما فيه الكفاية.

إن لم يُفهم هذا الفرق نشأ سوء فهم من نوع «وقّعنا فلا يُصلَح» أو «اشترينا شهادة EV فلم يتغيّر شيء».

3. ماذا يضمن توقيع الشيفرة

ما يضمنه توقيع الشيفرة أساساً أمران.

1. أنّ ذلك الملفّ وُقِّع من الناشر المعروض
2. أنّه لم يُعبَث بالملفّ بعد التوقيع

وبالعكس، هذا لا يُضمَن مباشرة.

• أنّ التطبيق آمن قطعاً
• أنّ التطبيق بلا أخطاء
• أنّ تحذير SmartScreen لن يظهر حتماً
• أنّ سياسة الشركة ستسمح به حتماً

ومع ذلك توقيع الشيفرة قريب من كونه ضرورة.

بلا توقيع لا يظهر الناشر للمستخدم. في بيئة الشركات قد يُوقَف ملفّ بلا توقيع عبر App Control أو EDR أو Defender أو الوكيل أو بوّابة البريد. وعند صنع تحديث تلقائيّ أيضاً يصير التوقيع مهمّاً للتحقّق ممّا إذا كان ملفّ التحديث أصليّاً.

أي إنّ توقيع الشيفرة ليس «لمحو التحذير» فقط، بل أساس التوزيع والتحديث والتدقيق والاعتماد المؤسّسيّ.

4. «شهادة EV تمحو التحذير من المرّة الأولى» فهم قديم

سابقاً كان شائعاً فهم أنّ استخدام شهادة توقيع شيفرة EV يعامل معاملة مؤاتية في SmartScreen.

أمّا الآن فالحكم بشراء شهادة EV لغرض تجنّب SmartScreen وحده على الأقلّ خطر. في وثائق Microsoft للمطوّرين SmartScreen reputation for Windows app developers مصرَّح بأنّ «شهادات EV لم تعد تتجاوز SmartScreen» وبأنّ «دفع علاوة EV لمجرّد تجنّب تحذير SmartScreen لم يعد مبرَّراً». وفي جدول أنواع الشهادات في الصفحة نفسها جُمع OV و EV في صفّ واحد «شهادة صالحة (OV/EV)»، وسلوك أوّل تنزيل مكتوب فيه «تحذير حتّى تتراكم السمعة». ينبغي التفكير في الملفّات الموقَّعة بـ EV أيضاً على أساس تراكم السمعة كما في شهادة OV.

هذا لا يعني أنّ شهادة EV بلا معنى إطلاقاً.

• في الشراء المؤسّسيّ يُقدَّر تحقّق أشدّ من الهويّة
• تُطلَب EV في مراجعة أمنيّة من جهة العميل
• الشهادة EV موجودة أصلاً فيُواصَل استخدامها

إن وُجدت هذه الأسباب فلا بأس بالاستخدام.

لكن شراء شهادة EV لهذا الغرض وحده غير مستحسن.

نشتري شهادة EV لأنّنا نريد محو تحذير SmartScreen من المرّة الأولى

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

5. خيارات طريقة التوقيع

نرتّب خيارات التوقيع والتوزيع الشائعة في توزيع تطبيقات Windows.

Microsoft Store / MSIX

للتوزيع على مستخدمين عامّين أوّل ما يُراد التفكير فيه Microsoft Store.

خصوصاً الجمع بين MSIX وتوزيع Store مؤاتٍ من ناحية إدارة الشهادات وتحذير SmartScreen. حزمة MSIX المقدَّمة إلى Store تُعاد توقيعها من جهة Microsoft، فينخفض أيضاً عبء شراء المطوّر للشهادة وتجديدها فرديّاً.

غير أنّ ليس كلّ تطبيق Windows مناسباً لـ MSIX.

• استخدام عميق لخدمات Windows
• يلزم برنامج تشغيل
• يوجد shell extension
• أصول تسجيل COM قديمة أو ActiveX
• يلزم تغيير معقّد لنظام التشغيل عند التثبيت

في هذه الحالات قد يكون MSI أو مثبِّت تقليديّ أطبيعيّ من MSIX.

Azure Artifact Signing

Azure Artifact Signing خدمة توقيع شيفرة سحابيّة تقدّمها Microsoft. كان الاسم سابقاً Trusted Signing، والاسم الرسميّ الحاليّ Azure Artifact Signing (Artifact Signing). صفحة المنتج لدى Microsoft أيضاً مكتوب فيها «Artifact Signing (formerly Trusted Signing)». المقالات والموادّ الداخليّة بالاسم القديم كثيرة، فعند البحث اضرب بالاسمين. الوثائق الرسميّة Microsoft Learn: What is Artifact Signing? و Azure: Artifact Signing (formerly Trusted Signing).

جاذبيّتها إمكان الإدماج في CI/CD دون رمز USB ماديّ. خيار قويّ كأسلوب توقيع للتوزيع خارج Store، لكن توجد مناطق حساب وشروط حساب.

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

كذلك التوقيع بـ Azure Artifact Signing لا يمنح ثقة SmartScreen فوراً. كالشهادة OV، تتراكم السمعة وفق سجلّ التوزيع.

شهادة توقيع شيفرة OV

حين يوزّع مطوّر أو شخص اعتباريّ في اليابان تطبيق Windows خارج Store، ما زالت شهادة توقيع الشيفرة OV خياراً واقعيّاً.

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

ما يُراد الوعي به عند استخدام شهادة OV هو التالي.

• مواصلة استخدام اسم الناشر
• التوقيع في كلّ مرّة بوصفه الناشر نفسه
• عدم تغيير الملفّ بعد التوقيع
• إلحاق ختم زمنيّ
• التحقّق لا من EXE وحده بل من DLL و MSI و updater أيضاً
• إعداد خطّة انتقال عند تجديد الشهادة

الشهادة الموقَّعة ذاتيّاً

الشهادة الموقَّعة ذاتيّاً مريحة للتطوير والتحقّق.

لكنّها في التوزيع العلنيّ غير صالحة أساساً. من منظور Windows لدى المستخدم تلك الشهادة غير موثوقة.

حيث تصلح الشهادة الموقَّعة ذاتيّاً بيئات كهذه.

• جهاز المطوّر المحلّيّ
• بيئة تحقّق المختبِر
• أجهزة داخليّة يمكن فيها توزيع شهادة موثوقة عبر Intune أو GPO
• بيئة مغلقة تُدار فيها تكوينات الأجهزة تماماً

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

6. في الميدان على ماذا ينبغي التوقيع

ليس «وقّعنا EXE فانتهى».

في توزيع تطبيقات Windows راجع أهداف التوقيع جملة.

عند استخدام SignTool في Windows SDK الحاليّ تحديد /fd و /td مهمّ. نموذجيّاً يُحدَّد SHA256.

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /a .\MyApp.exe
signtool verify /pa /v .\MyApp.exe

معنى كلّ خيار كالتالي.

عنوان خادم الختم الزمنيّ استخدم ما يرشد إليه مصدر إصدار الشهادة. في مثال وثائق SignTool لدى Microsoft يُستخدَم http://timestamp.digicert.com، وفي إجراءات التوقيع لـ Artifact Signing https://timestamp.acs.microsoft.com. بإلحاق ختم زمنيّ يُسجَّل أنّ الشهادة كانت صالحة لحظة التوقيع، فيمكن مواصلة استخدام التوقيع بعد انتهاء صلاحية الشهادة.

طريقة تحديد الشهادة تُختار حسب البيئة.

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

هل نجح التوقيع يُؤكَّد بالنقاط الثلاث التالية.

• نجاح signtool verify /pa /v .\MyApp.exe
• أن يكون رمز إنهاء ذلك الأمر 0 (في PowerShell انظر $LASTEXITCODE فور بعده)
• فتح خصائص الملفّ في المستكشف وظهور الناشر والختم الزمنيّ في علامة التبويب «التوقيعات الرقميّة»

النقطة هي التوقيع على الناتج النهائيّ.

إن أُعيدت كتابة EXE بعد التوقيع، أو استُبدل ملفّ داخل ZIP، أو غُيِّر ملفّ مضمَّن بعد صنع المثبِّت، قد ينكسر التوقيع أو تختلف نتيجة التحقّق عن المتوقّع.

في مسار البناء ثبّت هذا الترتيب.

البناء
  ↓
جمع الملفّات التابعة
  ↓
صنع المثبِّت / الحزمة
  ↓
التوقيع
  ↓
التحقّق من التوقيع
  ↓
تسجيل التجزئة
  ↓
التوزيع

7. التفكير حسب أسلوب التوزيع

مثبِّت MSI / EXE

عند التوزيع بمثبِّت MSI أو EXE وقِّع حتماً الملفّ الذي يشغّله المستخدم أوّلاً.

إضافة إلى ذلك راجع أيضاً EXE و DLL الموضوعة بعد التثبيت كأهداف توقيع. حتّى إن وُقِّع المثبِّت وحده، إن بقي updater أو helper بعد الوضع بلا توقيع قد يُوقَف في بيئة الشركات.

ما يُفكَّر فيه محدَّد تقريباً.

• وقِّع جسم المثبِّت
• وقِّع أيضاً EXE/DLL الداخلة فيه
• افصل المعالجة التي تحتاج رفع UAC
• دقِّق updater و service helper معاملة منفصلة
• ثبّت عنوان صفحة التنزيل
• أرشد المستخدمين الأوّل إلى اسم الناشر

MSIX

MSIX أسلوب اتّساقه كحزمة قويّ.

إن أمكن التوزيع عبر Store صار التعامل أسهل بكثير من ناحية تحذير SmartScreen وإدارة الشهادات. في المقابل، في التحميل الجانبيّ الداخليّ أو التوزيع خارج Store يلزم تصميم توقيع حزمة MSIX وثقة الشهادة بعناية.

نذكر تنبيهات.

• التطوير والتحقّق يجوز فيهما التوقيع الذاتيّ
• في توزيع الإنتاج استخدم أسلوب توقيع موثوقاً علناً
• طابق Publisher في appxmanifest مع Subject في الشهادة
• في التوزيع خارج Store افترض احتمال ظهور تحذير SmartScreen
• تأكّد مسبقاً ممّا إذا كان هناك تكامل نظام تشغيل غير مناسب لـ MSIX

ClickOnce

ClickOnce مريح لتوزيع تطبيقات عمل .NET مثل WinForms/WPF على مستخدم قياسيّ.

غير أنّ ClickOnce لا يمحو مشكلة SmartScreen. يتداخل مسار تنزيل المستخدم وتشغيله، وتوقيع البيان، ومصدر التوزيع، وتغيير الملفّات عند التحديث.

ما يُراجَع في ClickOnce هو التالي.

• توقيع بيان التطبيق وبيان النشر
• إدارة عنوان التوزيع أو المجلّد المشترك
• معاملة تغيير الشهادة عند التحديث
• ألا يتوقّف عبر وكيل داخليّ أو Defender
• إرشاد المستخدم عند التثبيت الأوّل

قوّة ClickOnce «سهولة التوزيع»، لكن إن لم يُصمَّم ليشمل ثقة الناشر ومسار التوزيع توقّف في الميدان.

توزيع xcopy / ZIP

توزيع «وضع المجلّد فقط» أو «فكّ ZIP فقط» بسيط.

قد ينفع في شبكة مغلقة أو أداة داخليّة. لكن في توزيع ويب موجَّه إلى مستخدمين عامّين هو أيضاً الأسلوب الأكثر تعرّضاً لأثر SmartScreen و Defender و Mark of the Web.

Mark of the Web (MOTW) الذي ظهر هنا تدفق بيانات بديل اسمه Zone.Identifier يضعه المتصفّح أو عميل البريد على ملفّ مُنزَّل. علامة «هذا الملفّ قادم من الإنترنت»، وتُستخدَم في تأكيد SmartScreen وحظر وحدات Office وحكم سياسة تنفيذ PowerShell (RemoteSigned) وغيرها. تُزال بفتح خصائص الملفّ في المستكشف وتحديد «السماح» في خانة «الأمان»، أو بـ Unblock-File في PowerShell. هل تنتقل العلامة إلى الملفّات الداخليّة عند فكّ ZIP يختلف حسب الأداة المستخدَمة في الفكّ. التفاصيل في فصل «Zone.Identifier (Mark of the Web) و Unblock-File» من سياسة تنفيذ PowerShell وتوقيع السكربتات.

إن استخدمت توزيع xcopy فهذه مواضع يُراد حفظها.

• وقِّع EXE/DLL
• لا تعتمد على ZIP وحده، تحقّق من الملفّات الداخليّة
• ثبّت مصدر التوزيع
• صرِّح بالإصدار والتجزئة وسجلّ التحديث
• إن أُضيف تحديث تلقائيّ لاحقاً فأدخل التحقّق من التوقيع

لا تفكِّر «سهل لأنّنا لا نصنع مثبِّتاً» بل «نتحمّل بأنفسنا المسؤوليّة التي يحملها المثبِّت».

updater خاصّ

updater الخاصّ مريح، لكنّه حدود الأمان نفسها.

يجلب updater ملفّاً جديداً ويستبدل الملفّ القائم. وقد يعمل بامتيازات مدير. إن انكسر هنا فهو أخطر من جسم التطبيق.

على الأقلّ راجع هذا.

• وقِّع metadata التحديث
• أدخل في metadata الحقول version و hash و size و channel و expiry
• بعد التنزيل تحقّق من hash والتوقيع
• عند فشل التحقّق قف بأسلوب fail-closed
• أعدّ إجراءات التراجع
• احسم طريقة تحديث updater نفسه
• افصل مفتاح توقيع الإنتاج عن بيئة التطوير

يسهل فهم هذا الموضوع مجموعة مع المقال القائم «تصميم أمان التحديث التلقائيّ».

8. في التوزيع الداخليّ النظر إلى SmartScreen وحده لا يكفي

في التطبيقات الداخليّة سوء فهم شائع.

نستخدمه داخليّاً فقط فلا حاجة للتوقيع

هذا خطر.

في البيئة الداخليّة لا يتداخل SmartScreen وحده بل آليّات عدّة.

خصوصاً في بيئة تستخدم App Control for Business لا يكفي «هل هو موقَّع»، بل يصير السؤال «هل ذلك الناشر مسموح» و«هل عبر managed installer» و«هل التجزئة أو المسار مسموح».

حتّى في دليل النشر لدى Microsoft مبيَّن تفكير توسيع تغيير سياسة App Control أوّلاً بوضع التدقيق، وتأكيد أنّ أحداث الحظر كما هو متوقّع، ثمّ الانتقال إلى الوضع الإلزاميّ.

في التوزيع الداخليّ تصميم بهذا الترتيب واقعيّ.

1. افصل الأجهزة المستهدفة
   - المطوّرون
   - المختبِرون
   - قسم جزئيّ
   - الشركة كلّها

2. احسم مسار التوزيع
   - Intune
   - GPO + مشاركة ملفّات
   - بوّابة داخليّة
   - VDI / RemoteApp
   - توزيع يدويّ في شبكة مغلقة

3. احسم قواعد الثقة
   - قاعدة الناشر
   - توزيع الشهادات
   - managed installer
   - السماح بالتجزئة
   - السماح بالمسار

4. أكِّد في وضع التدقيق
   - ما الذي يُحظَر
   - أيّ DLL أو helper تسرّب
   - ألا يُعامَل عند التحديث كملفّ آخر

5. انشر مرحليّاً
   - وزِّع صغيراً
   - انظر إلى السجلّات
   - اضبط قواعد السماح
   - وسِّع

نقطة التوزيع الداخليّ ليست تجنّب SmartScreen، بل جعل مسار التوزيع قابلاً للشرح لـ Windows.

9. سوء فهم شائع والتفكير الصحيح

10. كيف تشرح للمستخدمين عند الإصدار الأوّل

في تطبيق جديد قد يظهر تحذير SmartScreen في الأسابيع الأولى أو لدى المستخدمين الأوّل.

في هذه الحالة إرشاد المستخدم بمجرّد «حتّى إن ظهر التحذير فشغِّل» غير مستحسن. الشرح الآمن يتضمّن معلومات ينبغي التحقّق منها.

نذكر بنوداً ينبغي إدخالها في الإرشاد.

• عنوان التنزيل الرسميّ
• اسم الناشر الذي يظهر
• اسم الملفّ
• رقم الإصدار
• تاريخ الإصدار
• تجزئة SHA-256 عند الحاجة
• كيفيّة التحقّق من أنّه موقَّع
• عدم تشغيل ملفّ حصل عليه من مسار مجهول

مثلاً للتوزيع الداخليّ إرشاد كهذا آمن.

يُوزَّع هذا التطبيق فقط من الصفحة التالية في البوّابة الداخليّة.
تحقّق من أنّ اسم الناشر الظاهر هو «شركة ○○».
لا تشغِّل ملفّ EXE أُرسل كمرفق بريد أو عبر الدردشة.
إن ظهر تحذير SmartScreen فشارك الشاشة مع قسم نظم المعلومات.

للمستخدمين العامّين إمّا أولويّة توزيع Microsoft Store، أو وضع شرح تأكيد الناشر في صفحة التنزيل.

ما يشغّله المستخدم في شاشة التحذير

في موادّ الإرشاد اكتب أيضاً أين يضغط المستخدم فعليّاً. في حوار تحذير SmartScreen الزرّ القابل للضغط في الحالة الأوّليّة «عدم التشغيل» فقط. للتشغيل يكون الترتيب التالي.

حوار «قامت Windows بحماية جهاز الكمبيوتر الخاص بك»
  → اختر «مزيد من المعلومات»
  → يظهر اسم التطبيق (اسم الملفّ) والناشر
  → اضغط زر «تشغيل»

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

علماً بأنّ إعداد سياسة الشركة قد يعطِّل «تشغيل» نفسه فلا يمكن التقدّم. في الإرشاد الداخليّ أرفق أيضاً جهة الاتّصال في تلك الحالة.

تقدير إلى أن يختفي التحذير

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

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

أي إنّ الواقعيّ إعداد الإرشاد في الإصدار الأوّل على أساس «التحذير سيظهر لفترة»، ومواصلة التوزيع دون تغيير الشهادة واسم الناشر.

11. مسار الحكم

عند حسم أسلوب التوزيع يقلّ التردّد بهذا الترتيب.

flowchart TD
    A[توزيع تطبيق Windows] --> B{هل هو موجَّه إلى مستخدمين عامّين}
    B -->|نعم| C{هل يمكن الطرح على Microsoft Store}
    C -->|نعم| D[أولويّة Store / MSIX]
    C -->|لا| E[التوقيع بشهادة OV أو Artifact Signing]
    B -->|لا، داخليّ| F{هل توجد إدارة للأجهزة}
    F -->|يوجد Intune/GPO| G[توقيع + توزيع الشهادات + تدقيق App Control]
    F -->|بلا إدارة| H[تثبيت مصدر التوزيع + توقيع + إرشاد المستخدم]
    E --> I[افتراض تحذير SmartScreen أوّليّ]
    G --> J[نشر مرحليّ من وضع التدقيق]
    H --> J

المرشّح الأوّل ميدانيّاً يُرتَّب كالتالي.

12. قائمة التحقّق الأدنى

بنود التحقّق قبل نشر تطبيق Windows وتوزيعه.

التوقيع

• EXE موقَّع
• DLL موقَّع
• MSI أو EXE المثبِّت موقَّع
• updater موقَّع
• أُلحِق ختم زمنيّ
• لم تُعاد كتابة الملفّ بعد التوقيع
• جرى التحقّق بـ signtool verify

التوزيع

• حُسم عنوان التوزيع الرسميّ
• يظهر اسم الناشر في صفحة التنزيل
• يظهر رقم الإصدار وتاريخ الإصدار
• افتُرض احتمال ظهور تحذير SmartScreen أوّليّ
• نُظر في إمكان الطرح على Microsoft Store
• في التوزيع خارج Store نُظر في شهادة OV أو Artifact Signing

التحديث

• ملفّ التحديث أيضاً موقَّع
• في updater خاصّ metadata موقَّعة
• يُتحقَّق من hash و size و version
• عند الفشل يتوقّف بأسلوب fail-closed
• توجد إجراءات تراجع

التوزيع الداخليّ

• رُوجع وجود Intune / GPO / App Control
• حُسمت طريقة توزيع الشهادات
• نُظرت أحداث الحظر في وضع التدقيق
• يُنشَر مرحليّاً بفصل الأقسام المستهدفة
• تُؤكَّد عدم إعادة الحظر عند التحديث

13. الخلاصة

تطبيق Windows لا ينتهي بصنعه، بل يلزم أن يصير الملفّ الموزَّع «شكلاً موثوقاً» من منظور Windows والمستخدم وسياسة الشركة.

ما يُراد ضبطه هو التالي.

• SmartScreen ينظر إلى سمعة الملفّ والناشر
• توقيع الشيفرة لازم لكنّه لا يضمن انعدام التحذير
• شهادة EV لا تُختار لغرض تجنّب SmartScreen فوراً
• في التوزيع العامّ فكِّر بأولويّة في Microsoft Store / MSIX
• في التوزيع خارج Store استخدم شهادة OV أو Artifact Signing وافترض تحذيراً أوّليّاً
• في التوزيع الداخليّ انظر لا إلى SmartScreen وحده بل إلى Intune و GPO و App Control أيضاً
• صمِّم updater لا كوظيفة توزيع بل كحدود أمان للمنتج

في جملة واحدة كالتالي.

توزيع تطبيق Windows ليس تصميم «كيف يُوضَع» بل تصميم «كيف يثق به Windows».

اقرأ أيضاً

• كيف تختار أسلوب توزيع تطبيق Windows - MSI وMSIX وClickOnce وxcopy والتحديث الخاص
• ما هو ClickOnce - كيف يعمل، وكيف تعمل التحديثات، ومتى يلائم العمل الفعليّ ومتى لا يلائمه
• تصميم أمن التحديث التلقائي - لماذا لا يكفي HTTPS
• قائمة التحقّق الدنيا لأمان تطبيقات Windows
• متى يصبح Windows admin privilege ضرورياً
• توزيع تطبيق Windows في ملفّ واحد - حدود الملفّ التنفيذي الواحد واعتماد نظام التشغيل

روابط مرجعيّة

• Microsoft Learn: SmartScreen reputation for Windows app developers
• Microsoft Learn: Code signing options for Windows app developers
• Microsoft Learn: What is Artifact Signing? - نظرة عامّة على Azure Artifact Signing (Trusted Signing سابقاً) والاسم الرسميّ الحاليّ.
• Microsoft Learn: Sign your MSIX package - end-to-end guide
• Microsoft Learn: SignTool.exe
• Microsoft Learn: Deploying App Control for Business policies
• Microsoft Learn: Manage approved apps for Windows devices with App Control for Business policy and Managed Installers in Microsoft Intune

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

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

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

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

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

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

لماذا تظهر رسالة تحذير «قامت Windows بحماية جهاز الكمبيوتر الخاص بك»؟

لأنّ Microsoft Defender SmartScreen لم يحكم بعد بأنّ الملفّ موثوق بما فيه الكفاية. لا يقتصر عمل SmartScreen على تقييم بسيط لوجود فيروس، بل ينظر إلى سمعة الناشر وسمعة تجزئة الملفّ (file hash) ووجود التوقيع من عدمه ومسار التوزيع. الملفّ المُنشَأ حديثاً هو من منظور Windows «ملفّ يُرى للمرّة الأولى»، فحتّى لو كان موقَّعاً قد يظهر التحذير حتّى تتراكم السمعة. هذا لا يعني أنّه حُكم عليه بأنّه برمجيّة خبيثة، لكنّه يعني أنّ Windows لم يحكم بعد بأنّه موثوق بما فيه الكفاية.

هل يختفي تحذير SmartScreen بمجرّد توقيع الشيفرة؟

لا يختفي بالضرورة. ما يضمنه توقيع الشيفرة أمران فقط: أنّ الملفّ وُقِّع من الناشر المعروض، وأنّه لم يُعبَث به بعد التوقيع، وهو لا يضمن انعدام التحذيرات تماماً. حتّى لو كان الملفّ موقَّعاً قد يظهر التحذير طالما لم تكفِ سمعة الملفّ أو الناشر بعد. ومع ذلك يظلّ توقيع الشيفرة قريباً من كونه ضرورة كأساس للتوزيع والتحديث والتدقيق والاعتماد المؤسّسيّ. فبدون توقيع قد يُمنَع الملفّ في بيئات الشركات عبر App Control أو EDR أو Defender وما شابه.

هل يمنع شراء شهادة EV ظهور تحذير SmartScreen من المرّة الأولى؟

هذا فهم قديم. وفق الشرح الحاليّ من Microsoft لم يعد سلوك تجنّب تحذير SmartScreen تلقائيّاً عند أوّل تنزيل موجوداً لشهادات EV، ويجب التعامل مع الملفّات الموقَّعة بشهادة EV أيضاً على أساس أنّ السمعة تتراكم تدريجيّاً كما هو الحال مع شهادة OV. توجد فائدة من استخدام EV عندما تُطلَب في متطلّبات الشراء المؤسّسيّة أو في مراجعة أمنيّة من جهة العميل، لكن لا يُنصَح بشراء شهادة EV لمجرّد تجنّب SmartScreen فقط. لهذا الغرض ينبغي أوّلاً مراجعة مسار التوزيع وطريقة التوقيع وإمكانيّة التوزيع عبر Store.

كيف ينبغي التوزيع لتقليل تحذيرات SmartScreen؟

للتوزيع الواسع على المستخدمين العامّين فكِّر أوّلاً في Microsoft Store / MSIX. حزمة MSIX المقدَّمة إلى Store تُعاد توقيعها من جهة Microsoft، ما يجعله المسار الأكثر استقراراً من ناحية SmartScreen. إذا تعذّر الطرح على Store وقِّع عبر شهادة OV أو Azure Artifact Signing، وافترض احتمال ظهور تحذيرات في المرحلة الأولى، وأرشد المستخدمين إلى رابط التنزيل الرسميّ واسم الناشر والإصدار والتجزئة (hash) وما شابه. أمّا في التوزيع الداخليّ فيلزم إلى جانب التوقيع تصميم مسار توزيع يشمل Intune / GPO / App Control.

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

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

غو كومورا

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

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