متى يصبح Windows admin privilege ضرورياً - UAC والمناطق المحميّة وكيفيّة التمييز على مستوى التصميم

في الاستشارات المتعلّقة بـ Windows، توجد مواضيع تختلط ببعضها كثيراً.

• متى يصبح «التنفيذ كمسؤول» ضروريّاً
• لماذا لا يزال UAC يظهر رغم أنّ الحساب admin
• هل التثبيت يتطلّب admin دائماً
• نريد الوضع في Program Files، لكن هل سيُطلَب elevation حتى وقت التنفيذ
• ما الفرق بين HKCU وHKLM في الممارسة الفعليّة
• كيف نبني تطبيقاً يحتاج إلى admin privilege لـ «بعض المنطق فقط»

لا يتقرّر هذا الأمر فقط بناءً على «هل المستخدم admin أم لا».
في الواقع، يتقرّر إلى حدّ بعيد بناءً على أين تكتب، ومن يتأثّر بالتغيير، وأيّ هدف محميّ في OS تلمس.

في هذه المقالة، نرتّب المواضع التي يصبح فيها admin privilege ضروريّاً على Windows بدءاً من فرضيّات UAC، ونلخّص بشكل عمليّ حتّى أين يكفي حقّ المستخدم القياسيّ، ومن أين يبدأ نقاش elevation.
يستند المحتوى إلى المعلومات الرسميّة من Microsoft التي يمكن التحقّق منها حتى مارس 2026.¹²³⁴⁵

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

لو وضعنا الخلاصات فقط، فإنّ الوضع العمليّ تقريباً كالآتي.

• على Windows، يتقرّر هل admin privilege ضروريّاً ليس بـ «هل المنطق متقدّم» بقدر ما يتقرّر بـ «هل يؤثّر على OS أو الجهاز ككلّ».¹⁴
• المنطق المغلق ضمن بروفايل المستخدم نفسه فقط، مثل المنطق الذي يستخدم %AppData% و%LocalAppData% وHKCU وDocuments، يكتمل عادةً دون admin privilege.⁶⁷
• على العكس، المنطق الذي يلمس الجهاز ككلّ، أو جميع المستخدمين، أو المناطق المحميّة، مثل الإعدادات machine-wide في Program Files وWindows وSystem32 وHKLM وHKCR، أو Windows Service، أو kernel driver، أو firewall، أو scheduled task بأعلى الصلاحيّات، يحتاج عادةً إلى admin privilege.⁴⁶⁸⁹¹⁰
• المهمّ هنا هو أنّ انتماء المستخدم إلى مجموعة Administrators وكون التطبيق يعمل الآن بـ admin access token أمران مختلفان. عند تفعيل UAC، حتّى مستخدم admin تعمل عمليّاته العاديّة بصلاحيّات تعادل المستخدم القياسيّ، ويحدث elevation عند الحاجة فقط.²⁶
• التثبيت = admin دائماً ليس صحيحاً. يوجد تصميم per-user installation حيث يُوضَع التطبيق تحت %LocalAppData%، فيمكن توزيعه وتحديثه دون admin privilege.¹¹¹²
• التطبيقات «التي تحتاج admin privilege في كلّ مرّة لسبب ما» في الغالب تكتب بيانات وقت التشغيل في منطقة محميّة أو تعلن عن requireAdministrator / highestAvailable في manifest.⁴¹³
• من حيث الاتّجاه المستقبليّ أيضاً، يتجّه Windows نحو elevation صريح في اللحظة المطلوبة فقط. تُظهر ميزة Administrator protection (preview) في Windows 11 هذا الاتّجاه بوضوح كبير.⁵

باختصار، فإنّ النظرة الأكثر عمليّة هي أنّ «هل admin privilege ضروريّ» يتقرّر بالحدّ الذي يلمسه التطبيق، لا بصفة المستخدم.

2. ما معنى «admin privilege ضروريّ» أصلاً

أوّل ما نريد ترتيبه في هذا النقاش هو فصل المستخدم عن العمليّة عند التفكير.

UAC في Windows هو ميزة أمنيّة لمنع التغييرات غير المشروعة على OS. تشرح Microsoft Learn أيضاً أنّ UAC يُخطر عند إجراء تغييرات تتطلّب أذونات وصول بمستوى admin.¹

كذلك يُذكر في الشرح الرسميّ لـ UAC أنّ التطبيقات التي تحتاج إلى admin access token تطلب موافقة المستخدم النهائيّ، وأنّ العمليّات الفرعيّة ترث access token من العمليّة الأمّ، وأنّ الأمّ والابن يعملان بنفس integrity level.²

من هنا نستنتج أمرين.

2.1 «مستخدم admin» لا يعمل دائماً كـ admin طوال الوقت

تشرح Microsoft Learn أنّه عند تفعيل UAC، حتّى العمليّات التي يطلقها أعضاء مجموعة Administrators تعمل بصلاحيّات المستخدم القياسيّ ما لم يتمّ elevation خاصّ.⁶

أيّ أنّ:

• حساب Windows الخاصّ بك هو admin
• لكنّ التطبيق الذي أطلقته للتوّ بنقرة مزدوجة غير مرفوع
• لذلك يظهر UAC فقط في لحظة العمليّة التي تتطلّب admin privilege

هذا أمر عاديّ.

«أنا admin، فلماذا لا تزال الصلاحيّات غير كافية» سلوك طبيعيّ تماماً على Windows.

2.2 لا يمكن جعل «هذا المنطق فقط فجأة admin» داخل نفس العمليّة

UAC ليس سحراً على مستوى الدالّة، بل هو نقاش حول ما هو access token الذي تعمل به العمليّة.
العمليّات الأمّ والفرعيّة ترث access token، لذلك لا يمكن تصميم منظومة ترفع بعض الميثودات داخل نفس العمليّة فقط في لحظة الضغط على زرّ ما، داخل عمليّة UI غير مرفوعة.²

عند الحاجة إلى ذلك، يجب استخدام وحدة تنفيذ منفصلة مثل:

• فصل المنطق إلى EXE منفصل
• استخدام service
• استخدام scheduled task بأعلى الصلاحيّات
• استخدام elevated COM

هذه الفرضيّة ضروريّة.¹⁴

دون معرفة هذه الفرضيّة عند التصميم، تتحوّل الاستشارة عادةً إلى السؤال المؤلم نوعاً ما: «أريد تنفيذ هذا الزرّ فقط كـ admin».

3. ماذا يحدّد ذلك - أوّلاً، طريقة التمييز

أبسط طريقة للتمييز هي الأمور الثلاثة التالية.

1. أين تكتب
2. من يتأثّر بالتغيير
3. هل تلمس هدفاً محميّاً في OS

لو وضعناه في جدول حكم مختصر، فإنّه يبدو هكذا.

أيّ أنّه باختصار شديد، الوضع كالآتي.

• التغييرات لأجلك أنت تكتمل بسهولة بالمستخدم القياسيّ
• التغييرات لأجل الجميع تتداخل عادةً مع admin
• لمس الحدّ الآمن لـ OS يحتاج إلى admin

النظر إلى هذه الثلاثة أوّلاً يجعل تفسير «لماذا يظهر UAC» أسهل بكثير.

4. أمثلة نموذجيّة يصبح فيها admin privilege ضروريّاً

4.1 التثبيت والتحديث وإلغاء التثبيت لجميع المستخدمين

في شرح UAC architecture على Microsoft Learn، يُذكر أنّ كثيراً من المثبّتات تكتب في system directories أو registry keys، وأنّ المستخدم القياسيّ لا يملك أذونات وصول كافية، وأنّ Windows يكتشف برامج التثبيت ويطلب elevation.³

النقطة المهمّة هنا هي أنّ المثبّت ليس «عظيماً لأنّه مثبّت»، بل elevation ضروريّ لأنّ الكتابة موجّهة إلى منطقة محميّة.

على سبيل المثال الحالات التالية.

• الوضع في Program Files
• كتابة معلومات machine-wide في HKLM
• تسجيل COM أو دمج لجميع المستخدمين
• إدخال service أو driver
• امتلاك مسار تحديث على مستوى الجهاز

في هذه المواضع، يصبح admin privilege ضروريّاً عادةً.³⁸

4.2 كتابة بيانات وقت التشغيل في Program Files أو HKLM

هذا أيضاً منتشر جدّاً.
تشرح UAC design guide من Microsoft أنّه ينبغي إزالة elevation غير الضروريّ، وأنّ كثيراً من البرامج القديمة تتطلّب admin privilege دون داعٍ لأنّها تكتب في HKLM / HKCR أو Program Files / Windows System folders.⁴

كذلك في الشرح المتعلّق بالمستخدم القياسيّ، يُذكر صراحةً أنّ الكتابة في مجلّد Program Files أو HKEY_LOCAL_MACHINE غير ممكنة، ولا يمكن إجراء عمليّات تغيّر النظام.⁶

أيّ أنّ:

• ملفّات الإعدادات
• ملفّات الـ logs
• الـ cache
• الحالة لكلّ مستخدم
• سجلّ الاستخدام الأخير

لو وضعت بيانات وقت التشغيل هذه في مجلّد التثبيت أو في HKLM، فإنّ ذلك وحده يجعل التطبيق يقع بسهولة في فئة «لا يعمل ما لم يُطلق كـ admin».

والكثير من هذه الحالات لا تنشأ لأنّ التطبيق فعلاً موجَّه للمسؤولين، بل لأنّ اختيار موقع الحفظ سيّئ فقط.

4.3 تسجيل أو تغيير تكوين Windows Service

الـ services تخضع لإدارة OS، فلا يمكن لمسها بسهولة بالطبع.

في الوثائق الرسميّة لأذونات وصول Service Control Manager، يُذكر أنّ استدعاء CreateService يحتاج إلى SC_MANAGER_CREATE_SERVICE، وأنّ العمليّات التي يمكنها فتح handle قابل لـ CreateService هي فقط العمليّات التي تملك Administrator privileges.⁸

كذلك يُذكر أنّ SERVICE_CHANGE_CONFIG المطلوب لـ ChangeServiceConfig / ChangeServiceConfig2 يمكن أن يغيّر الـ EXE الذي ينفّذه النظام، ولذلك ينبغي منحه للمسؤولين فقط.⁸

لذلك:

• تسجيل service
• تغيير الملفّ التنفيذيّ أو نوع تشغيل service
• حذف service
• تغيير security descriptor لـ service

هذه العمليّات تحتاج عادةً إلى admin privilege.

4.4 تثبيت kernel driver

تشرح Microsoft Learn أنّ المستخدم القياسيّ لا يمكنه تنفيذ مهامّ تغيّر النظام مثل تثبيت kernel-mode driver.⁶

هذا حدّ واضح جدّاً.
الـ driver يعمل على جانب kernel، فلا يمكن التعامل معه بنفس مستوى «حفظ إعدادات تطبيق المستخدم العاديّ».

• تثبيت device driver
• إدخال virtual driver أو filter driver
• تغيير المكوّنات المتعلّقة بـ boot أو I/O

هذه العمليّات يمكن اعتبارها تتطلّب admin privilege.

4.5 تكوين firewall أو scheduled task بصلاحيّات عالية

الـ firewall أيضاً جزء من حدود أمن OS.
تذكر إجراءات تكوين firewall في Microsoft Learn صراحةً أنّ تشغيل Windows Firewall with Advanced Security على جهاز واحد يحتاج إلى administrative rights على ذلك الجهاز.⁹

كذلك بالنسبة لـ Task Scheduler، يُعرَّف أنّ TASK_RUNLEVEL_LUA بأقلّ صلاحيّات وTASK_RUNLEVEL_HIGHEST بأعلى صلاحيّات، وفي وثائق schtasks أيضاً يُذكر أنّ schedule / view / change لجميع المهامّ على الكمبيوتر المحلّيّ يتطلّب أن يكون المستخدم عضواً في مجموعة Administrators.¹⁰

أيّ أنّ:

• إضافة أو تغيير قواعد Windows Firewall
• تسجيل منطق معيّن كـ scheduled task بأعلى صلاحيّات
• تشغيل job بمستخدم آخر أو بـ SYSTEM

هذه التكوينات تقع في الجانب الذي يتطلّب admin privilege.

5. أمثلة نموذجيّة قد لا تحتاج فعلاً إلى admin privilege

قد يبدو أنّ «Windows يطلب admin بسرعة»، لكنّ في الواقع يوجد أجزاء كثيرة يمكن تصميمها بدون الحاجة إلى admin privilege.

5.1 الإعدادات والـ cache والـ logs الخاصّة بك

تشرح Microsoft Learn أنّه لا ينبغي الاعتماد على virtualization من أجل التوافق، وأنّ التطبيق ينبغي أن يحفظ في per-user location أو في computer location داخل %alluserprofile% بـ ACL مضبوط بشكل صحيح.⁷

من الناحية العمليّة، فإنّ التقسيم التالي مفيد للترتيب.

• خاصّ بالمستخدم: %AppData%، %LocalAppData%، HKCU
• مشترك ولكن يُحدَّث وقت التشغيل: %ProgramData% + تصميم ACL
• الملفّ التنفيذيّ نفسه: المناطق المحميّة مثل Program Files

مع هذا الفصل، يمكن جعل تثبيت التطبيق بـ admin، لكنّ الاستخدام اليوميّ بدون admin.

5.2 التثبيت والتحديث per-user

في الوثائق الرسميّة من Microsoft، أمثلة الوضع per-user تظهر بشكل اعتياديّ.

على سبيل المثال، تشرح وثائق Remote Desktop client أنّ التثبيت per-user يضع التطبيق تحت LocalAppData لكلّ بروفايل مستخدم، ويسمح للمستخدم بالتحديث دون admin privilege.¹¹

كذلك في وثائق OneDrive، يُذكر أنّ الافتراضيّ هو تثبيت per-user، وأنّ التثبيت per-machine يُنفَّذ بإضافة /allusers للأمر، وينتج عن ذلك ظهور UAC prompt. كذلك per-user يدخل تحت %localappdata%، وper-machine يدخل تحت Program Files.¹²

ما نستنتجه من هذا هو أنّ مجرّد كلمة «التثبيت» لا تحدّد ما إذا كان admin privilege ضروريّاً.

• إذا كان كلّ مستخدم يضع التطبيق في منطقته الخاصّة، فقد يكتفي بدون admin
• إذا كان الوضع في منطقة مشتركة بين جميع المستخدمين، فيحتاج عادةً إلى admin

المهمّ هو تحديد per-user أم per-machine أوّلاً.

5.3 عمليّات UI العاديّة ومنطق العمل

على العكس، فإنّ المنطق التالي لا يحتاج بحدّ ذاته إلى admin privilege.

• فتح مستندات أو صور
• تحرير ملفّات تحت بروفايل المستخدم
• إجراء اتّصالات HTTP أو DB
• تنفيذ منطق العمل
• عرض النتائج على الشاشة
• قراءة وكتابة الإعدادات الخاصّة بالمستخدم

ومع ذلك، إذا كان «تشغيل التطبيق ككلّ كـ admin» ضروريّاً، فإنّ السبب ليس الوظائف الأساسيّة للتطبيق، بل في الغالب أنّ بعض المنطق المحيط يلمس منطقة محميّة.

6. لماذا يُقال «هذا التطبيق كـ admin»

6.1 يُعلن عن requireAdministrator في manifest

في application manifest، يمكن الإعلان عن مستوى الصلاحيّات المطلوب عبر requestedExecutionLevel. تعرّف Microsoft Learn الأنواع الثلاثة التالية.¹³

• asInvoker: يعمل بنفس صلاحيّات العمليّة المُطلِقة
• highestAvailable: يعمل بأعلى صلاحيّات ممكنة
• requireAdministrator: يعمل بصلاحيّات admin

إذا كان التطبيق requireAdministrator، فإنّ elevation مفترض في كلّ إطلاق.
حتّى مع highestAvailable، يتداخل elevation حسب البيئة.¹³

لذلك، فإنّ أبسط إجابة على «لماذا يظهر UAC في كلّ مرّة» هي لأنّ التطبيق نفسه يعلن ذلك.

6.2 يقع في installer detection لـ Windows

في شرح UAC architecture، يُذكر أنّ Windows يملك installer detection technology، وأنّ كثيراً من برامج التثبيت تكتب في protected system locations، فيصبح elevation ضروريّاً.³

وأكثر من ذلك، فإنّ هذا ليس مجرّد كون الاسم setup.exe، بل Windows يحدّد بشكل heuristic إلى حدّ ما أنّ هذا «يبدو كمثبّت». في الوثيقة الرسميّة، الشروط التالية مذكورة.³

• ملفّ تنفيذيّ 32-bit
• لا توجد سمة requestedExecutionLevel
• عمليّة تفاعليّة من مستخدم قياسيّ مع UAC مفعَّل
• يتضمّن اسم الملفّ كلمات مثل install، setup، update، إلخ

لذلك، فإنّ طلب SetupLauncher.exe أو Updater.exe للـ elevation فجأة ليس غريباً من تصميم Windows.

6.3 التطبيقات القديمة كانت «تعمل بالصدفة» بسبب virtualization

هذه نقطة يساء فهمها كثيراً.

تشرح Microsoft Learn أنّ UAC يوفّر virtualization للملفّات والـ registry للتطبيقات غير المتوافقة التي تحاول الكتابة في منطقة محميّة.
في الوقت نفسه، يُذكر صراحةً أنّ هذا إجراء توافق قصير الأجل، وليس حلّاً طويل الأجل.³⁷

كذلك، فإنّ virtualization له قيود.

• لا يُطبَّق على التطبيقات التي مرّ عليها elevation
• يُطبَّق على تطبيقات 32-bit فقط
• يصبح غير فعّال إذا وُجد manifest يتضمّن requestedExecutionLevel
• التطبيقات ينبغي أن تُصلَح أصلاً للكتابة في الموقع الصحيح

هذه هي الشروط.³⁷

أيّ أنّ تطبيقات 32-bit القديمة قد تبدو كأنّها «كانت قادرة على الكتابة في Program Files دون admin»، لكنّ ذلك ربّما لم يكن كتابة صحيحة، بل تهريباً إلى VirtualStore فقط.

لذلك:

• بعد التحوّل إلى 64-bit
• بعد إضافة manifest
• بعد تغيير طريقة البناء
• بعد التقدّم في الالتزام بـ UAC

في هذه التوقيتات، تظهر فجأة «أخطاء تصميم موقع الحفظ» التي لم تكن ظاهرة من قبل.

6.4 المواقع التي يلمسها وقت التشغيل ليست جيّدة أصلاً

في الممارسة، هذا في النهاية الأكثر شيوعاً.

• حفظ الإعدادات بجانب EXE
• تفريغ الـ logs في مجلّد التثبيت
• إنشاء ملفّات مؤقّتة تحت Program Files
• كتابة الحالة لكلّ مستخدم في HKLM

مع هذا التكوين، يصبح الشكل صعب التعامل: التطبيق نفسه واجهة عاديّة، ولكنّ إطلاقه يحتاج إلى admin privilege.⁴⁶

الحالات التي تكون «admin بسبب موقع الحفظ السيّئ» وليس «admin لأنّ المنطق متقدّم» كثيرة جدّاً فعلاً.

7. كيف نصمّم لتقليل elevation غير الضروريّ

7.1 الأساس هو asInvoker

ما لم يكن التطبيق ككلّ أداة إدارة نظام فعلاً، فإنّ الخطّ الأساسيّ هو تشغيل تطبيق UI عاديّ بدون elevation.
من حيث معنى manifest أيضاً، asInvoker هو إعلان «العمل بنفس صلاحيّات العمليّة المُطلِقة».¹³

إذا تمّ تشغيل العمليّات اليوميّة على الشاشة ومنطق العمل وحفظ الإعدادات الخاصّة بكلّ مستخدم كلّها كـ admin، تزداد المشاكل التالية.

• يتّسع سطح الهجوم
• يصعب شرح التشغيل
• يظهر UAC في كلّ مرّة
• لا يعود واضحاً «أيّ منطق يحتاج فعلاً إلى admin»

تشرح UAC design guide من Microsoft أيضاً أنّه ينبغي إزالة elevation غير الضروريّ، وحصر admin privilege في المهامّ التي تحتاج إليه فعلاً.⁴

7.2 فصل المنطق الذي يحتاج إلى admin إلى وحدة تنفيذ منفصلة

تذكر Microsoft Learn صراحةً نموذجاً لتطبيق يحتوي على منطق يحتاج إلى admin privilege، يعمل كتطبيق مستخدم قياسيّ مع فصل الجزء الضروريّ فقط.¹⁴

النماذج الرئيسيّة الأربعة كالآتي.

• Administrator Broker Model
  تطبيق UI للمستخدم القياسيّ + helper EXE بصلاحيّات admin
• Operating System Service Model
  UI للمستخدم القياسيّ + service مقيم
• Elevated Task Model
  UI للمستخدم القياسيّ + scheduled task بأعلى صلاحيّات
• Administrator COM Object Model
  UI للمستخدم القياسيّ + elevated COM

التمييز التقريبيّ في الاستخدام كالآتي.

• عمليّات admin من حين لآخر فقط → helper EXE
• دائم وغير مراقب ومتكرّر → service
• job قصير ومتكرّر بنمط ثابت → highest task
• افتراض COM موجود → elevated COM

النقاش حول تجسيد هذا التصميم في تطبيق Windows مغطّى بالتفصيل أيضاً في مقالة منفصلة:
طريقة كتابة محدّدة لفصل «المنطق الذي يحتاج إلى admin privilege فقط» في تطبيق Windows

7.3 تصحيح موقع وضع بيانات وقت التشغيل

مبدأ موقع الحفظ بسيط جدّاً.

• البيانات الخاصّة بالمستخدم → HKCU أو %AppData%
• cache محلّيّ خالص → %LocalAppData%
• بيانات مشتركة ولكن تتغيّر وقت التشغيل → %ProgramData% + ACL
• الملفّ التنفيذيّ نفسه → Program Files

تشرح Microsoft Learn أيضاً أنّ التطبيق ينبغي أن يحفظ في per-user location أو في %alluserprofile% (الذي هو فعليّاً ProgramData) بـ ACL مضبوط بشكل صحيح.⁷

مع هذا الترتيب، يصبح من الأسهل جعل المثبّت فقط يُرفَع، والتطبيق أثناء التشغيل غير مرفوع.

7.4 تحديد per-user و per-machine أوّلاً

من السهل التغافل عن هذه النقطة بشكل غير متوقّع.

• هل ينبغي أن يكون التطبيق قابلاً للتثبيت من قبل كلّ مستخدم بنفسه
• هل ينبغي وضعه في موقع واحد مشترك بين جميع المستخدمين
• من المسؤول عن التحديث
• هل من المسموح تشغيل الملفّ التنفيذيّ من بروفايل المستخدم

إذا كان هذا القرار غامضاً، فإنّ النتيجة لاحقاً تصبح فوضويّة بسهولة:

• التثبيت بـ admin فقط
• التشغيل أيضاً بـ admin
• التحديث أيضاً بـ admin
• جزء فقط بـ user context

الفرق بين per-user و per-machine ليس مجرّد نقاش حول طريقة التوزيع، بل هو تصميم الصلاحيّات نفسه.

8. إلى أين يتّجه Windows في المستقبل

اعتباراً من مارس 2026، يحتوي Windows 11 على ميزة تُسمّى Administrator protection (preview). تشرحها Microsoft Learn بأنّها ميزة تحافظ على deprivileged state في الأوقات العاديّة، وتمنح admin rights بشكل just-in-time عند الحاجة فقط.⁵

كذلك تشرح Microsoft أنّها تطلب مصادقة صريحة قبل العمليّات التي تتطلّب admin privilege مثل تثبيت البرامج، وتغيير إعدادات النظام مثل الوقت أو الـ registry، والوصول إلى البيانات الحسّاسة.⁵

الميزة نفسها لا تزال preview، والتعميم العامّ يتمّ تدريجيّاً.⁵
لكنّ الاتّجاه واضح جدّاً.

• عدم الاحتفاظ بـ admin token طوال الوقت
• elevation فقط في اللحظة المطلوبة
• فصل sessions التي خضعت لـ elevation
• توضيح «متى وأيّ تطبيق ولماذا أصبح admin» بشكل أكبر

أيّ أنّه يمكن اعتبار أنّ التصميم القائل «نشغّل كلّ شيء كـ admin مؤقّتاً» سيتعارض أكثر فأكثر مع Windows في المستقبل.

9. سوء الفهم الشائع

9.1 «أنا مستخدم admin، لذلك يجب ألّا يظهر UAC»

يظهر.
عند تفعيل UAC، حتّى أعضاء مجموعة Administrators تعمل عمليّاتهم العاديّة بدون elevation، ويحدث elevation فقط عند الحاجة.⁶²

9.2 «إذا كان تثبيتاً، فهو يحتاج إلى admin بالتأكيد»

ليس بالتأكيد.
يوجد تصميم يمكن التوزيع فيه دون admin privilege، مثل التثبيت per-user في %LocalAppData%.¹¹¹²

9.3 «بما أنّنا نضع في Program Files، فلا بأس بحفظ الإعدادات هناك أيضاً»

لا بأس، بل يجب الفصل.
ينبغي فصل موقع وضع الملفّ التنفيذيّ عن موقع حفظ البيانات التي تتغيّر وقت التشغيل. تذكر Microsoft أيضاً أنّ الكتابة وقت التشغيل في Program Files أو HKLM مثال نموذجيّ على elevation غير الضروريّ.⁴⁷

9.4 «إذا شغّلنا كـ admin، تُحلّ كلّ مشاكل التصميم»

لا تُحلّ.
قد يعمل مؤقّتاً، لكنّ سطح الهجوم وقابليّة التشغيل والتوزيع وسهولة الدعم تتدهور بسهولة. كذلك لا يمكن رفع جزء واحد فقط داخل نفس العمليّة بشكل مريح.²¹⁴

9.5 «كان يعمل في الماضي، فهو صحيح الآن أيضاً»

ليس بالضرورة.
إذا كانت تطبيقات 32-bit القديمة «تعمل بالصدفة» بسبب virtualization، فإنّ المشاكل تطفو إلى السطح عند التحوّل إلى 64-bit أو إضافة manifest. الـ virtualization تدبير مؤقّت من أجل التوافق، وليس حلّاً طويل الأجل.³⁷

10. الخلاصة

ما إذا كان admin privilege ضروريّاً على Windows يتقرّر، باختصار، بـ «أين نذهب لتغيير ماذا».

• التغييرات لأجلك تكتمل بسهولة بالمستخدم القياسيّ
• التغييرات لجميع المستخدمين أو الجهاز ككلّ تحتاج عادةً إلى admin
• لمس المناطق المحميّة لـ OS أو حدود الأمن يتطلّب admin privilege

والمهمّ فعلاً في الممارسة هو الفصل بين المنطق الذي يحتاج فعلاً إلى admin privilege والمنطق الذي يحتاج إلى admin بسبب ظروف موقع الحفظ فقط.

خصوصاً في تطوير تطبيقات Windows، فإنّ الخطوط التالية فعّالة جدّاً.

• جعل UI بدون elevation أساساً
• فصل منطق admin إلى EXE / service / task منفصل
• توجيه بيانات وقت التشغيل نحو AppData / HKCU / ProgramData
• تحديد per-user / per-machine أوّلاً

«هل admin privilege ضروريّ» ليس نقاشاً حول مدى عظمة التطبيق.
إنّه نقاش حول أيّ حدّ من حدود OS تلمس.

عند امتلاك هذا المنظور أوّلاً، يصبح من الأسهل بكثير ترتيب سلوك UAC واختيار طريقة التثبيت وتصميم التطبيق.

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

• طريقة كتابة محدّدة لفصل «المنطق الذي يحتاج إلى admin privilege فقط» في تطبيق Windows
• قائمة تحقّق للحفاظ على الحدّ الأدنى من الأمن في تطوير تطبيقات Windows
• كيف نختار طريقة توزيع تطبيق Windows - جدول حكم بين MSI / MSIX / ClickOnce / xcopy / updater مخصّص

12. المراجع

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

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

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

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

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

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

غو كومورا

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

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