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

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

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

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

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

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

1. هذا المقال بكلمة واحدة

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

المهمّ هو التفكير بفصل ثلاث زوايا.

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

2. SmartScreen ليس مجرّد «تقييم فيروسات»

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

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

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

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

بعبارة أخرى، من الأسهل فهم تحذير SmartScreen على النحو التالي.

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

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

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

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

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

وبالمقابل، لا يضمن هذه الأمور مباشرةً.

• أنّ التطبيق آمن تماماً
• أنّ التطبيق خالٍ من الأخطاء (bugs)
• أنّ تحذير SmartScreen لن يظهر أبداً
• أنّه سيُسمَح به حتماً بموجب سياسة الشركة

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

في حال عدم وجود توقيع، لا يعرف المستخدم من هو الناشر. وفي بيئات الشركات، قد تُمنَع الملفّات غير الموقَّعة عبر App Control أو EDR أو Defender أو الوكيل (proxy) أو بوّابة البريد الإلكترونيّ. وعند بناء تحديث تلقائيّ أيضاً، يصبح التوقيع مهمّاً للتحقّق من أصالة ملفّ التحديث.

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

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

في السابق، كان الفهم الشائع هو أنّ استخدام شهادة توقيع شيفرة EV يُعامَل بشكل أفضل من جهة SmartScreen.

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

هذا لا يعني أنّ شهادة EV عديمة الفائدة تماماً.

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

إذا وُجدت مثل هذه الأسباب، فيجوز استخدامها.

لكن لا يُنصَح بشراء شهادة EV لهذا الغرض وحده.

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

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

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

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

Microsoft Store / MSIX

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

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

لكن ليست كلّ تطبيقات Windows مناسبة لـ MSIX.

• استخدام مكثّف لخدمات Windows
• الحاجة إلى تعريف (driver)
• وجود امتداد للقشرة (shell extension)
• وجود تسجيل COM قديم أو أصول ActiveX
• الحاجة إلى تغييرات معقّدة في نظام التشغيل أثناء التثبيت

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

Azure Artifact Signing

Azure Artifact Signing خدمة توقيع شيفرة سحابيّة تقدّمها Microsoft. كانت تُسمّى سابقاً Trusted Signing.

ميزتها أنّها لا تستخدم رمز USB ماديّاً (token)، ويسهل دمجها في CI/CD. وهي طريقة توقيع قويّة للتوزيع خارج Store، لكن توجد مناطق وشروط حساب مُتاحة يُقيَّد بها استخدامها.

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

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

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

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

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

عند استخدام شهادة OV، هذه هي النقاط التي ينبغي مراعاتها.

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

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

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

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

يمكن استخدام الشهادة الموقَّعة ذاتيّاً في مثل هذه البيئات.

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

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

6. ما الذي ينبغي توقيعه في العمل الفعليّ

الأمر لا ينتهي بـ«توقيع EXE فقط».

في توزيع تطبيقات Windows، تحقّق من كامل نطاق أهداف التوقيع.

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

signtool sign /fd SHA256 /tr <timestamp-server-url> /td SHA256 /a .\MyApp.exe
signtool verify /pa /v .\MyApp.exe

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

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

في خطّ أنابيب البناء (build pipeline)، ثبِّت هذا الترتيب.

البناء (Build)
  ↓
جمع الملفّات المُعتمَد عليها
  ↓
إنشاء المثبّت / الحزمة
  ↓
التوقيع
  ↓
التحقّق من التوقيع
  ↓
تسجيل التجزئات (hashes)
  ↓
التوزيع

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

مثبّت MSI / EXE

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

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

الأمور التي يجب مراعاتها محدَّدة تقريباً.

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

MSIX

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

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

لنذكر نقاط الانتباه.

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

ClickOnce

ClickOnce مفيد عند توزيع تطبيقات .NET المؤسّسيّة كـ WinForms/WPF على مستخدمين قياسيّين.

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

هذه هي النقاط التي تُتحقَّق منها في ClickOnce.

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

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

توزيع xcopy / ZIP

التوزيع الذي يقتصر على وضع مجلّد أو فكّ ضغط ZIP بسيط.

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

إذا استخدمتَ توزيع xcopy، فهذه هي النقاط التي ينبغي الالتزام بها.

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

لا ينبغي اعتباره «سهلاً لأنّنا لا ننشئ مثبّتاً»، بل «نتحمّل بأنفسنا المسؤوليّة التي يحملها المثبّت».

Updater خاصّ

الـ updater الخاصّ مفيد، لكنّه في حدّ ذاته حدّ أمنيّ (security boundary).

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

تحقّق من هذا الحدّ الأدنى على الأقلّ.

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

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

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

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

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

هذا خطير.

في البيئة الداخليّة، لا يتعلّق الأمر بـ SmartScreen وحده، بل بعدّة آليّات.

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

حتّى دليل النشر الخاصّ بـ Microsoft يبيّن فكرة نشر تغييرات سياسة App Control أوّلاً في وضع التدقيق (audit mode)، والتحقّق من أنّ أحداث الحظر كما هو متوقَّع، ثمّ التوسّع إلى وضع الفرض (enforced mode).

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

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

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

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

4. التحقّق في وضع التدقيق (audit mode)
   - ما الذي يُحظَر
   - أيّ DLL أو helper فاتنا
   - هل تُعامَل التحديثات كملفّات مختلفة

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

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

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

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

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

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

لنذكر البنود التي يجب إدراجها في الإرشاد.

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

على سبيل المثال، للاستخدام الداخليّ، هذا الإرشاد آمن.

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

للمستخدمين العامّين، أعطِ الأولويّة للتوزيع عبر Microsoft Store، أو ضع في صفحة التنزيل شرحاً للتحقّق من الناشر.

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
• أرفقتُ طابعاً زمنيّاً (timestamp)
• لم أُعِد كتابة الملفّ بعد التوقيع
• تحقّقتُ عبر signtool verify

التوزيع

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

التحديث

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

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

• تحقّقتُ من وجود 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
• مدخل إلى ClickOnce: التوزيع والتحديث ومعايير الاختيار
• تصميم أمان التحديث التلقائيّ
• قائمة فحص للحدّ الأدنى من الأمان في تطوير تطبيقات Windows
• حدود الحاجة إلى صلاحيّة مسؤول Windows
• حدود توحيد تطبيق Windows في ملفّ ثنائيّ واحد والتطبيق العمليّ

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

• Microsoft Learn: SmartScreen reputation for Windows app developers
• Microsoft Learn: Code signing options for Windows app developers
• 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 «ملفّ يُرى للمرّة الأولى»، فحتّى لو كان موقَّعاً، قد يظهر التحذير حتّى تتراكم السمعة. هذا لا يعني أنّه حُكم عليه بأنّه برمجيّة خبيثة (malware)، لكنّه يعني أنّ 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.

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

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

غو كومورا

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

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