(ج) فاسيا لوزكين.
لسوء الحظ ، في عمل مسؤول النظام ، لا ، لا ، وعليك السماح للمستخدمين بتشغيل أي برنامج مع حقوق المسؤول. في معظم الأحيان ، هذه هي بعض البرامج الصينية الغريبة للعمل مع المعدات. ولكن هناك حالات أخرى مثل bnk.exe سيئة السمعة.
إن منح حقوق المسؤول للمستخدم لحل المشكلة بسرعة وسهولة يتعارض مع معايير أمان المعلومات. يمكنك بالطبع منحه جهاز كمبيوتر منفصل ووضعه على شبكة معزولة ، لكنه مكلف وعموما ...
دعونا نحاول اتخاذ القرارات التي تسمح بتشغيل البرنامج ، وليس إزعاج ضابط الأمن مع الممول.
حسنا ، لماذا أنت على حق؟
يمكن للبرنامج أن يطلب حقوق المسؤول بشروط في حالتين:
- عندما يريد الوصول إلى حيث لا يستطيع "مجرد بشر": على سبيل المثال ، إنشاء ملفات في دلائل النظام.
- عندما تم تجميع البرنامج مع العلم الخاص "يتطلب حقوق المسؤول".
في الحالة الأولى ، كل شيء واضح: نحن نأخذ في أيدينا البرنامج الرائع لبرنامج Mark Russinovich Process Monitor ، وننظر إلى ما يحدث وأين يحاول البرنامج الدخول إلى:
أين يذهب هذا 7Zip؟
ووفقًا لنتائج الدراسة ، نمنح حقوق المستخدم للدليل أو فرع التسجيل المرغوب.
سيكون الأمر أكثر صعوبة إذا كانت الحالة إكلينيكية ، وليس من السهل إعطاء الحقوق: على سبيل المثال ، يتطلب البرنامج تدخلًا قويًا في تشغيل النظام ، مثل تثبيت برامج التشغيل. ثم عليك أن تأتي مع كل مزرعة جماعية ، والتي سيتم مناقشتها في القسم الأخير من المقالة. في الوقت الحالي ، سأغطي الحالة الثانية بمزيد من التفاصيل - عند تحديد مربع الاختيار.
لتبسيط الكثير ، ثم في بيان خاص للبرنامج (بالمناسبة ، المثبتون هم أيضًا برامج) يمكن أن يكون هناك ثلاثة خيارات إطلاق:
- asInvoker . يبدأ البرنامج بنفس حقوق العملية التي تم إنشاؤها (كقاعدة عامة ، هذا هو explorer.exe مع حقوق المستخدم) ؛
- أعلى التوفر . سيطلب البرنامج الحد الأقصى للأذونات المتاحة للمستخدم (سيرى المسؤول نافذة يطلب فيها زيادة UAC ، لن يقوم المستخدم بذلك) ؛
- مطلوبالمسؤول سيتطلب البرنامج حقوق المسؤول في أي حال.
إذا قرر المطور بحزم المطالبة بحقوق المسؤول ، حتى إذا لم تكن هناك حاجة إليها ، فيمكنك الالتفاف على ذلك بقليل من الدم.
لا ، لن تكون على حق
في نظام Windows ، بدءًا من نظام التشغيل Vista ، ظهرت خدمة UAC ، والتي ، من بين أشياء أخرى ، مسؤولة عن طلب برامج الارتفاع. ليس كل البرامج "هضم" العمل مع هذه الخدمة. لذلك ، تم تحسين آلية توافق التطبيقات مع النظام ، مما يسمح لك بضبط سلوك البرنامج مباشرة - لطلب الحقوق أم لا.
أسهل طريقة للعمل مع هذه الآلية هي استخدام متغيرات البيئة.
النظر في مثال محرر التسجيل. في الواقع ، عند تشغيل regedit.exe تحت المسؤول ، نحصل على طلب لرفع الحقوق:
طلب الارتفاع.
إذا بدأنا محرر التسجيل من وحدة التحكم ، بعد تغيير قيمة متغير البيئة __COMPAT_LAYER إلى:
set __COMPAT_LAYER=RUNASINVOKER
ثم لن يكون هناك طلب UAC ، وكذلك حقوق إدارية للتطبيق:
محرر التسجيل المحرومين.
يمكن استخدام ذلك عن طريق تشغيل البرامج مع الملفات الدفعية أو عن طريق إضافة قائمة سياق من خلال التسجيل. قراءة المزيد في كيفية تشغيل البرنامج دون امتيازات المسؤول وتجاوز موجه UAC؟
يمكن مواجهة مثال ملموس لمثل هذا البرنامج غير السار عند تنزيل مصنفات البنوك من 1C من موقع RBC على http://cbrates.rbc.ru/bnk/bnk.exe . إذا تم ترك تحديث المصنفات للمستخدمين أنفسهم ولا توجد طريقة لتغيير التنزيل إلى bnk.zip (ويدعم 1C الحديث هذا) ، فعليك الخروج بعكازات. بعد كل شيء ، bnk.exe هو أرشيف استخراج ذاتي فيه لسبب ما يقول "تتطلب حقوق المسؤول".
نظرًا لأن الاختصارات لن تعمل هنا ، لأن 1C نفسها تقوم بتنزيل الملف وتشغيله ، سيتعين عليك استخدام المدفعية الثقيلة - مجموعة أدوات توافق التطبيقات لـ Microsoft.
وثائق البرنامج ، كالعادة ، متاحة على الموقع الرسمي ، يمكنك تنزيله كجزء من Windows Evaluation and Deployment Kit . عملية حل المشكلة بسيطة.
تحتاج إلى تثبيت الأداة المساعدة وتشغيل "مسؤول التوافق" وإنشاء تطبيق إصلاح في قاعدة بيانات جديدة أو موجودة:
إنشاء إصلاح التطبيق.
الاسم والناشر لا يهم. فقط موقع الملف مهم - هنا تحتاج إلى تحديد المشكلة الحقيقية bnk.exe (حيث سيكون في الواقع تكمن - لا يهم).
بعد ذلك ، حدد RunAsInvoker من قائمة الإصلاحات.
حدد الإصلاح المطلوب.
نترك الباقي بشكل افتراضي ، احفظ قاعدة البيانات. يجب أن يبدو شيء مثل هذا:
تم إنشاء الإصلاح لـ bnk.exe.
بعد ذلك ، سيكون يكفي تثبيت قاعدة البيانات عن طريق النقر بزر الماوس الأيمن عليها واختيار تثبيت. الآن سيتمكن المستخدمون من تحميل مصنفات البنوك بأنفسهم.
يزداد الأمر سوءًا إذا كان التطبيق يحتاج حقًا إلى حقوق المسؤول. ثم لا تساعد إضافة حقوق إلى كائنات النظام والتصحيحات.
حسنًا ، احتفظ بها بشكل صحيح
يبدو أن الحل الأكثر وضوحا لإطلاق برنامجنا الغريب هو استخدام الأداة المساعدة Runas المدمجة. الوثائق متاحة على موقع مايكروسوفت .
حسنا ، دعنا نرى ما يحدث.
فريق:
runas /savecred /user: "C:\Program Files\7-Zip\7zFM.exe"
في الواقع ، ستعمل RunAs على تشغيل 7zip بامتيازات المسؤول ، وطلب كلمة مرور ، وتذكرها. بعد ذلك ، سيتم تشغيل اختصار باسم خط الإطلاق 7zip تحت "المسؤول" دون سؤال.
)
أدخل كلمة المرور
يوجد عيب واحد هام: تذكر كلمة المرور على مستوى النظام ، والآن ، باستخدام الأمر Runas ، يمكنك بدء أي برنامج على الإطلاق. هذا لا يختلف عن منح حقوق المسؤول مباشرة للموظفين ، لذلك يجب ألا تستخدم هذا الحل.
لكن runas يمكن أن تكون مفيدة عندما يعرف الموظف كلمة مرور المسؤول ، ولكن يعمل تحت حساب محدود (من حيث المبدأ ، يجب على كل مسؤول النظام القيام بذلك).
إذا بدأنا بأوامر وحدة التحكم ، فسننتقل إلى البرامج النصية ذات المستوى الأعلى. تم اقتراح حل مثير للاهتمام في مقال " Plankton Windows " ، حيث كان برنامج Runas المذكور أعلاه مرتبطًا بخط سينمائي وتم تمريره عبر أداة تشويش. الحل لديه ناقص واضح - يمكن فك تشفير البرنامج النصي.
هناك طريقة أكثر إثارة للاهتمام في 2k20 وهي ميزات PowerShell وعملها مع كلمات المرور. يمكنك قراءة المزيد في مقالة " حماية كلمة المرور والتشفير في البرامج النصية PowerShell ".
باختصار: في PS ، يتم العمل مع كلمات المرور من خلال نوع بيانات SecureString الخاص وكائن PSCredential. على سبيل المثال ، يمكنك إدخال كلمة المرور بشكل تفاعلي:
$Cred = Get-Credential
ثم احفظ كلمة المرور في نموذج مشفر إلى ملف:
$Cred.Password | ConvertFrom-SecureString | Set-Content c:\pass.txt
والآن استخدم هذا الملف للعمل غير التفاعلي:
$username = "Domain\" $pass = Get-Content C:\pass.txt | ConvertTo-SecureString $creds = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username, $pass
لسوء الحظ ، لا يمكن استخدام هذا الملف إلا على جهاز الكمبيوتر الذي تم إنشاؤه عليه. لتجنب ذلك ، يمكنك إنشاء مفتاح تشفير منفصل. على سبيل المثال ، مثل هذا:
$AESKey = New-Object Byte[] 32 [Security.Cryptography.RNGCryptoServiceProvider]::Create().GetBytes($AESKey) $AESKey | out-file C:\password_aes.key
الآن ، باستخدام هذا المفتاح ، يمكن تشفير كلمة المرور:
$Cred.Password| ConvertFrom-SecureString -Key (get-content C:\password_aes.key )| Set-Content C:\pass.txt
وفك تشفير:
$pass = Get-Content C:\pass.txt | ConvertTo-SecureString -Key (get-content C:\password_aes.key)
لسوء الحظ ، فإن الأمور حزينة بنفس القدر من الأمان: ليس من الصعب إزالة كلمة المرور إذا كان لديك حق الوصول إلى ملف به مفتاح تشفير وكلمة مرور مشفرة. نعم ، يمكنك إضافة التشويش وتجميع البرنامج النصي في .exe مع الملفات الضرورية. ولكن عليك أن تفهم أن هذه التدابير نصف.
في وقت واحد ، استخدمت AutoIt المفضلة لحل مثل هذه المشكلات ، حيث قمت بتجميع نص برمجي مع فريق RunAs وابتهج ... حتى اكتشفت أن برنامج AutoIt (خاصة الإصدارات الأقدم) يتم إلغاء ترجمته مرة أو مرتين.
قد يكون الخيار المهم الآخر هو استخدام المهام المعينة - إذا قمت بإنشاء مهمة مجدولة من حساب المسؤول ، فلن يحتاج المستخدم إلا لبدء تشغيلها. لسوء الحظ ، هذا الحل غير مناسب للعمل التفاعلي مع التطبيق.
في العالم ، هناك العديد من حلول الجهات الخارجية المصممة لحل المشكلة. سوف أسكن على اثنين منهم.
ولعل واحدة من أشهر المرافق هي AdmiLink ، التي طورها أليكسي كورياكين لاحتياجات الفيزياء النووية. يتم وصف برنامج ومبادئ عملها على الموقع الرسمي . كالمعتاد ، اسمح لنفسي بوصف مختصر.
يتكون البرنامج من ثلاث وحدات. AdmiLink هي نافذة رسومية حيث يمكنك إنشاء اختصار للتطبيق المطلوب (من حيث المبدأ ، يكفي في بعض الحالات فقط).
النافذة الرئيسية للبرنامج.
بالإضافة إلى إنشاء اختصار مباشرة (ونعم ، يمكن أيضًا إلغاء طلب UAC) ، هناك وظائف إضافية مثل الآلة الحاسبة والمحطة وإعدادات ملائمة لسياسات الأمان. مع كل ميزات البرنامج ، تتم دعوة القارئ للتعرف عليه بنفسه.
الوحدة الثانية تسمى AdmiRun وهي أداة مساعدة وحدة التحكم. إنها تعرف كيفية تشغيل التطبيقات نيابة عن المسؤول ، وتتلقى كإحدى المعلمات سلسلة تم إنشاؤها من خلال AdmiLink. يتم تشفير اسم المستخدم وكلمة المرور في السطر ، ويشارك أيضًا المسار إلى البرنامج.
للوهلة الأولى ، يبدو كل شيء آمناً ، لكن لسوء الحظ ، تم إغلاق رمز البرنامج ، ومدى ثقتك في المطور هو سؤال.
الوحدة الثالثة - AdmiLaunch - هي المسؤولة عن إطلاق النوافذ في أوضاع مختلفة ، ويتم استخدامها لتشغيل AdmiRun إذا قمت بإنشاء اختصار من خلال AdmiLink.
بشكل عام ، تم اختبار الحل على مر السنين والأجيال من مسؤولي النظام المحلي. لكنني سأضيف بديلاً من الخارج.
RunAsRob هو برنامج مثير للاهتمام تأليفه المطور الألماني أوليفر هيسينج. على عكس AdmiLink ، يتم تثبيت البرنامج كخدمة تعمل تحت حساب متميز (مسؤول أو نظام). نتيجة لذلك ، يشير الاختصار المحضّر إلى الخدمة ، التي تقوم بدورها بتشغيل البرنامج المحدد بالفعل.
من ميزات البرنامج أنه من الممكن تخويل ليس فقط البرامج ، ولكن أيضًا المجلدات (بما في ذلك مجلدات الشبكة). أتاح تخزين الإعدادات في السجل إمكانية إضافة قوالب نهج المجموعة ، كما كتبنا في المقالة " الغوص في القوالب و Taming Windows GPO ". بفضل هذا ، إذا لزم الأمر ، يمكن تطبيق الإعدادات مباشرة من Active Directory.
النافذة الرئيسية للبرنامج.
البرنامج موثق بثراء على الموقع الرسمي .
يحتوي هذا المؤلف أيضًا على برنامج RunAsSpc الذي يسمح لك بتشغيل الملفات القابلة للتنفيذ بموجب حقوق مستخدم آخر ، ونقل بيانات الاعتماد من خلال ملف مشفر.
لا يمكنني إلا أن أضيف أن هذا البرنامج مجاني للاستخدام الشخصي فقط.
لكن ضع في اعتبارك أنه من خلال برنامج يعمل بموجب حقوق إدارية ، يمكنك القيام بالأذى. على سبيل المثال ، قم بتشغيل وحدة تحكم أمر مميزة من خلال مربع الحوار File - Open.
تشغيل cmd.exe مباشرة من محرر التسجيل.
إن السياسات التي تحظر قائمة السياق ومديري المهام الآخرين ، والتي يمكن لبعضها تكوين AdmiLink ، ستساعد على حماية أنفسهم قليلاً. ولكن على أي حال ، يجب أن تكون حذرا.
هل سبق لك أن صنعت عكازات غريبة؟ أقترح مشاركة القصص في التعليقات.