فرض کنید تیم امنیت تصمیم گرفته اجرای نرمافزارهای ناشناس روی Endpointهای سازمان را متوقف کند. در جلسه اول همه با اصل موضوع موافقاند: فقط نرمافزارهای تأییدشده باید اجرا شوند. اما چند ساعت بعد سؤالهای عملی شروع میشود؛ اگر یک ابزار داخلی فراموش شده باشد چه؟ اگر مسیر فایل یک نرمافزار بعد از Update تغییر کند چه؟ اگر PowerShell برای تیم زیرساخت لازم باشد ولی برای کاربران عادی نه؟ و مهمتر از همه، چطور میتوان از مدل «هر چیزی که ممنوع نشده مجاز است» به مدل «فقط موارد تأییدشده اجرا شوند» مهاجرت کرد، بدون اینکه کسبوکار متوقف شود؟
اینجاست که Application Allowlisting از یک مفهوم امنیتی ساده به یک پروژه اجرایی تبدیل میشود. ManageEngine Application Control Plus برای همین سناریو طراحی شده است: کشف برنامههای موجود، ساخت Allowlist و Blocklist مبتنی بر Rule، اجرای Audit Mode قبل از Enforcement، تعریف Policy برای گروههای مختلف کاربران و Endpointها و سپس حرکت مرحلهای به سمت Strict Mode.
در این راهنما، هدف این نیست که صرفاً فهرستی از قابلیتهای محصول ارائه شود. تمرکز روی این است که چطور Application Control را در یک سازمان واقعی پیاده کنیم تا هم سطح حمله کاهش پیدا کند و هم تیمهای عملیاتی با اختلال گسترده مواجه نشوند.
Application Allowlisting دقیقاً چه مشکلی را حل میکند؟
در مدل کلاسیک Endpoint Security معمولاً ابزارهای امنیتی تلاش میکنند «بدافزار شناختهشده» یا «رفتار مشکوک» را شناسایی کنند. Application Allowlisting زاویه را معکوس میکند: بهجای اینکه فقط موارد بد را پیدا کند، تعریف میکند چه چیزهایی مجاز به اجرا هستند.
NIST در راهنمای SP 800-167، Application Whitelisting را بهعنوان روشی برای کنترل اجرای Applicationها و Componentهای مجاز روی Host معرفی میکند. این مدل میتواند اجرای Malware، نرمافزارهای بدون مجوز و برنامههای غیرمجاز را محدود کند. CISA نیز در راهنماهای دفاعی خود استفاده از Allowlisting را برای محدود کردن اجرای نرمافزار و کاهش سطح حمله توصیه کرده است.
اما در عمل اگر Allowlist بدون مرحله شناخت محیط و بدون Pilot فعال شود، میتواند همان اندازه که امنیت ایجاد میکند، عملیات را هم مختل کند. تفاوت پروژه موفق و ناموفق در طراحی Rollout است.
Application Control Plus چه اجزایی را وارد این مدل میکند؟
نسخه فعلی Application Control Plus چند لایه اصلی را کنار هم قرار میدهد:
- کشف Applicationها و Executableهای موجود روی Endpointها
- ساخت Application Group بهصورت Allowlist یا Blocklist
- تعریف Rule بر اساس Vendor، Product Name، File Hash، Folder Path و معیارهای سفارشی
- اعمال Policy بر اساس گروههای کاربری یا Device Group
- Audit Mode برای مشاهده اثر Policy قبل از Enforcement
- Strict Mode برای جلوگیری از اجرای Applicationهای Unmanaged
- مدیریت درخواست دسترسی به برنامههای موردنیاز کسبوکار
- گزارش و بررسی Applicationهای Unmanaged
این معماری کمک میکند Allowlisting از یک فهرست دستی و شکننده به یک فرآیند قابل مدیریت تبدیل شود.
Allowlist و Blocklist چه تفاوتی دارند؟
| مدل | منطق اجرا | مزیت اصلی | ریسک اصلی |
|---|---|---|---|
| Blocklist | همه چیز مجاز است مگر موارد ممنوع | راهاندازی سریعتر | برنامه ناشناخته میتواند اجرا شود |
| Allowlist | فقط موارد تأییدشده مجاز هستند | کاهش شدید سطح اجرای کد ناشناس | اگر Baseline ناقص باشد، اختلال عملیاتی ایجاد میشود |
| Audit Mode | Policy ارزیابی میشود ولی اجرا محدود نمیشود | کشف Gap بدون توقف سرویس | در این مرحله Enforcement کامل ندارید |
| Strict Mode | Unmanaged Application اجرا نمیشود | مدل Zero Trust واقعیتر | نیازمند آمادگی Policy و فرآیند Exception |
برای بیشتر سازمانها مسیر درست این است که از Audit Mode شروع کنند، Unmanaged Applicationها را شناسایی کنند، Exceptionهای واقعی را حل کنند و سپس Scopeهای آماده را به Strict Mode ببرند.
چرا Audit Mode مهمترین مرحله Rollout است؟
ManageEngine در راهنمای فعلی Application Control Plus توصیه میکند ابتدا Policyها در Audit Mode اجرا شوند. در این حالت Applicationهای Allowlisted و Unmanaged همچنان اجرا میشوند، اما Log و Visibility لازم برای تصمیمگیری ایجاد میشود.
این مرحله به چند سؤال حیاتی پاسخ میدهد:
- کدام نرمافزارها واقعاً در هر Department استفاده میشوند؟
- کدام ابزارها Portable هستند و در Inventory کلاسیک دیده نمیشوند؟
- کدام Executableها از مسیرهای Dynamic اجرا میشوند؟
- چه Applicationهایی فقط در پایان ماه یا هنگام Maintenance استفاده میشوند؟
- کدام نرمافزارهای داخلی Signature معتبر ندارند؟
- چه ابزارهایی توسط تیم فنی لازماند اما نباید برای کاربران عمومی مجاز باشند؟
اگر این سؤالات قبل از Strict Mode جواب داده نشوند، Help Desk ناگهان با موجی از Ticketهای «برنامه اجرا نمیشود» مواجه میشود.
گام اول: Endpointها را بر اساس نقش گروهبندی کنید
یک Allowlist سراسری برای کل سازمان معمولاً ایده خوبی نیست. کاربر مالی، Developer، کارشناس NOC و مسئول منابع انسانی نیازهای نرمافزاری متفاوتی دارند.
در Application Control Plus میتوان Custom Groupها را بر اساس Role، Department، Location یا هر ساختار عملیاتی دیگری ایجاد کرد و Policy را به همان Scope نسبت داد. این کار دو مزیت دارد: Ruleها کوچکتر و قابل فهمتر میشوند و Exceptionها نیز به همان گروه محدود میمانند.
برای مثال:
| گروه | Allowlist نمونه | Blocklist نمونه |
|---|---|---|
| Finance | ERP Client، Office، Browser، PDF Reader | Remote Admin Tools، Developer Tools |
| NOC | SSH Client، Monitoring Tools، Browser، PowerShell | Game/Chat غیرسازمانی |
| Developer | IDE، Git، SDK، Container Tools | ابزارهای ناشناس خارج از Repository سازمان |
| Kiosk | Browser و Agentهای امنیتی | تقریباً همه Applicationهای دیگر |
گام دوم: Application Inventory را به Policy تبدیل کنید
Agentهای Application Control Plus برنامههای نصبشده و Executableهای مرتبط را کشف میکنند. اما Inventory صرفاً برای گزارشگیری نیست؛ همین داده مبنای ساخت Application Group میشود.
Ruleها را میتوان بر اساس معیارهای مختلف ساخت:
Vendor Rule
زمانی مناسب است که به یک Vendor معتبر اعتماد دارید و چند Product از همان Vendor در سازمان استفاده میشود. مزیت آن کاهش Maintenance Ruleهاست.
Product Name Rule
اگر میخواهید فقط یک یا چند محصول مشخص از یک Vendor مجاز باشند، Product-based Rule کنترل دقیقتری میدهد.
File Hash
Hash سختگیرانهترین مدل است. کوچکترین تغییر در فایل میتواند Hash را تغییر دهد، بنابراین برای Executableهای بسیار حساس مناسب است، اما برای نرمافزارهایی که مرتب Update میشوند هزینه نگهداری بیشتری دارد.
Folder Path
برای بعضی Applicationها ساده و کاربردی است، ولی برای نرمافزارهایی با مسیر Dynamic یا قابل تغییر باید با احتیاط استفاده شود.
Verified Executable و Custom Rule
برای سناریوهایی که برنامه مسیر متغیر دارد یا در Inventory عادی بهخوبی دیده نمیشود، Ruleهای سفارشی بر اساس Vendor، Product، Executable و Signature میتوانند انعطاف بیشتری ایجاد کنند.
گام سوم: از Blocklist برای مهار سریع استفاده کنید
Allowlisting مقصد نهایی مناسبی برای محیطهای حساس است، اما همیشه لازم نیست برای هر تهدید منتظر تکمیل پروژه Allowlist بمانید.
فرض کنید یک Remote Access Tool غیرمجاز در شبکه دیده شده یا یک Application دارای آسیبپذیری بحرانی هنوز Patch ندارد. در این شرایط Blocklist میتواند یک کنترل جبرانی سریع باشد تا اجرای نرمافزار تا زمان رفع ریسک متوقف شود.
CISA در چند راهنمای امنیتی خود روی Application Control و Allowlisting برای محدود کردن اجرای ابزارهای Remote Access غیرمجاز و نرمافزارهای ناخواسته تأکید کرده است. این کاربرد خصوصاً در برابر Portable Executableهایی مهم است که ممکن است بدون Install کلاسیک اجرا شوند.
چطور PowerShell و Command Prompt را مدیریت کنیم؟
یکی از اشتباههای رایج این است که ابزارهای مدیریتی قدرتمند را برای همه کاربران بهصورت یکسان مجاز یا ممنوع کنیم.
در مستندات Application Control Plus توضیح داده شده که Windows Componentهایی مانند PowerShell یا Command Prompt ممکن است مثل Applicationهای معمولی در Inventory دیده نشوند، اما میتوان آنها را با Ruleهایی مانند Folder Path یا File Hash کنترل کرد.
مدل بهتر Role-based است:
- برای کاربران عمومی، اجرای این ابزارها محدود شود.
- برای تیم زیرساخت، فقط روی Endpointهای مدیریتی و Scope مشخص مجاز باشد.
- Scriptهای حساس از Repository و مسیرهای کنترلشده اجرا شوند.
- استفاده از ابزارهای مدیریتی با Logging و SIEM ترکیب شود.
این طراحی بهجای Block کورکورانه، سطح دسترسی را با وظیفه واقعی هماهنگ میکند.
Application Control و Zero Trust چه ارتباطی دارند؟
Zero Trust فقط درباره User Identity نیست. یکی از سؤالهای مهم در Endpoint Security این است که چه کدی اجازه اجرا دارد؟
در Strict Mode، Application Control Plus میتواند فقط Applicationهای Allowlisted را مجاز بداند و Unmanaged Applicationها را متوقف کند. این منطق با اصل «اعتماد پیشفرض وجود ندارد» همراستا است.
اما Zero Trust در اینجا به معنی «هیچ Exceptionی نداریم» نیست. سازمان باید فرآیند کنترلشدهای برای درخواست نرمافزار جدید، بررسی Owner، ارزیابی ریسک، تأیید و اضافه شدن به Allowlist داشته باشد.
فرآیند Exception را قبل از Strict Mode طراحی کنید
اگر Strict Mode فعال شود اما کاربر نداند برای یک Application ضروری چه مسیری را طی کند، تیم امنیت خیلی زود مجبور میشود Policy را عقب بکشد.
یک Workflow ساده میتواند شامل این مراحل باشد:
- User یا Owner درخواست اجرای Application را ثبت میکند.
- Business Justification مشخص میشود.
- تیم Security فایل، Vendor، Signature و Reputation را بررسی میکند.
- در صورت تأیید، Rule مناسب به گروه مربوطه اضافه میشود.
- Policy فقط روی Scope لازم اعمال میشود.
- Expiration یا Review Date برای Exception تعیین میشود.
در سازمانهایی که از ITSM استفاده میکنند، این Workflow بهتر است به Service Request یا Change متصل شود تا Audit Trail کامل باقی بماند.
Application Control Plus یا Endpoint Central؟
این دو ابزار در بخشی از قابلیتها همپوشانی دارند، اما تصمیم باید بر اساس Architecture و License فعلی سازمان گرفته شود. Endpoint Central در Security Edition قابلیت Application Control را نیز ارائه میکند، در حالی که Application Control Plus محصول تخصصی مستقلی برای سازمانهایی است که تمرکز اصلیشان روی کنترل اجرای نرمافزار و Least Privilege در Endpoint است.
اگر سازمان شما در حال حاضر از Endpoint Central استفاده میکند، قبل از خرید محصول جداگانه باید Edition و Add-onهای موجود بررسی شوند. اگر هدف یک پروژه مستقل Application Control با Scope مشخص است، Application Control Plus میتواند مسیر سادهتری برای طراحی Policy و Enforcement باشد.
Application Control را با Patch Management ترکیب کنید
Allowlisting جای Patch Management را نمیگیرد. یک Application ممکن است کاملاً مجاز باشد ولی نسخه نصبشده آن آسیبپذیر باشد.
مدل کاملتر این است:
- Application Control مشخص کند چه نرمافزاری اجازه اجرا دارد.
- Patch Management مطمئن شود نسخه مجاز، بهروز و امن است.
- Vulnerability Management ریسک و Exposure را اولویتبندی کند.
- SIEM رفتار غیرعادی و تلاش برای اجرای فایل Blocked را تحلیل کند.
برای بخش Patch میتوانید مقاله مدیریت پچ نرمافزارهای ثالث با Patch Manager Plus را نیز ببینید. ترکیب این دو کنترل، فاصله بین «نرمافزار مجاز» و «نرمافزار امن و بهروز» را کمتر میکند.
یک برنامه Rollout چهارمرحلهای برای سازمان
فاز ۱: Discovery
Endpointها را گروهبندی کنید، Application Inventory بگیرید و Owner هر نرمافزار کلیدی را مشخص کنید.
فاز ۲: Audit
Allowlist اولیه را بسازید و Policy را در Audit Mode اجرا کنید. Unmanaged Applicationها را حداقل در یک چرخه کاری واقعی بررسی کنید؛ برای بعضی واحدها این چرخه ممکن است شامل پایان ماه، Maintenance Window یا پردازشهای فصلی باشد.
فاز ۳: Pilot Strict
یک گروه کمریسک و کنترلشده را به Strict Mode ببرید. تعداد Block Event، Ticket و Exception را اندازه بگیرید.
فاز ۴: Progressive Enforcement
Scope را مرحلهای افزایش دهید و هر بار دادههای واقعی Pilot قبلی را وارد Ruleها کنید. Endpointهای حساس مثل Kiosk، Jump Server یا سیستمهای Fixed-function معمولاً کاندیداهای خوبی برای Enforcement سختگیرانهتر هستند.
KPIهای مناسب برای Application Control
| KPI | هدف |
|---|---|
| Unmanaged Application Count | کاهش Applicationهای بدون Owner و Policy |
| Blocked Execution Events | مشاهده تلاشهای واقعی برای اجرای برنامه ممنوع |
| False Block Rate | کاهش Block اشتباه نرمافزارهای کسبوکار |
| Exception Aging | جلوگیری از دائمی شدن Exception موقت |
| Policy Coverage | درصد Endpointهای تحت Policy واقعی |
| Audit-to-Strict Conversion | سرعت تبدیل Scopeهای آماده به Enforcement |
| Mean Time to Approve | زمان رسیدگی به درخواست Application جدید |
CISA در الزامات فنی Continuous Diagnostics and Mitigation برای کنترل اجرای Application حتی روی نرخ False Allow/False Deny نیز تأکید دارد؛ پیام عملی برای سازمان این است که کیفیت Enforcement باید اندازهگیری شود، نه اینکه فقط تعداد Blockها گزارش شود.
اشتباههای رایج در اجرای Allowlisting
- فعال کردن Strict Mode از روز اول: نتیجه معمولاً اختلال و عقبنشینی Policy است.
- یک Allowlist برای همه: نیازهای Roleها متفاوت است.
- اعتماد بیش از حد به Folder Path: مسیر میتواند تغییر کند یا قابل سوءاستفاده باشد.
- نداشتن Owner برای Application: هر نرمافزار مجاز باید مسئول کسبوکاری یا فنی داشته باشد.
- Exception بدون Expiry: استثنای موقت خیلی زود دائمی میشود.
- نادیده گرفتن Portable App: بسیاری از ابزارها بدون Install اجرا میشوند.
- جدا کردن Application Control از Patch/Vulnerability Management: «مجاز» بودن با «امن» بودن یکی نیست.
نکات کلیدی
- Application Allowlisting باید با Discovery و Audit Mode شروع شود، نه با Block گسترده.
- Policyها را بر اساس Role و Device Group طراحی کنید.
- برای نرمافزارهای Dynamic از Rule مناسب مثل Vendor، Product یا Verified Executable استفاده کنید.
- Strict Mode را مرحلهای و بر اساس داده واقعی فعال کنید.
- Exception Workflow، Owner و Expiration بخشی از معماری امنیتی هستند.
- Application Control باید در کنار Patch Management، Vulnerability Management و SIEM قرار بگیرد.
- برای سازمانی که Endpoint Central دارد، Edition و قابلیت Application Control موجود را قبل از خرید مستقل بررسی کنید.
منابع
- ManageEngine – Configure Application Groups، بهروزرسانی ۲۷ ژوئیه ۲۰۲۶
- ManageEngine – Application Control Policy Deployment، بهروزرسانی ۱۷ اوت ۲۰۲۶
- ManageEngine – Application Control Best Practices
- NIST SP 800-167 – Guide to Application Whitelisting
- CISA – Application Allowlisting Guidance in Ransomware Defense
سخن پایانی
Application Allowlisting زمانی موفق است که امنیت را از یک «Block List بزرگ» به یک مدل تصمیمگیری قابل کنترل تبدیل کند. اگر سازمان بتواند بداند چه Applicationهایی واقعاً لازماند، چه کسی Owner آنهاست، روی چه Endpointهایی باید اجرا شوند و Exceptionها چطور Review میشوند، حرکت به سمت Strict Mode دیگر یک ریسک ناگهانی نیست؛ یک مسیر مرحلهای و قابل اندازهگیری است.
برای سازمانهایی که میخواهند Application Control Plus یا قابلیت Application Control در Endpoint Central را از نظر معماری، License، Pilot و Integration با Patch/Vulnerability Management بررسی کنند، مدانت خدمات مشاوره، استقرار و پشتیبانی ارائه میدهد. برای بررسی سبد و استعلام لایسنس میتوانید صفحه لایسنس محصولات ManageEngine را ببینید یا از طریق درخواست دمو و مشاوره مدانت سناریوی Endpoint Security سازمانتان را بررسی کنید.
