کاربر واحد مالی برای اجرای یک ابزار امضای دیجیتال، کارشناس شبکه برای بازکردن یک ابزار مدیریتی و توسعهدهنده برای نصب یک Component مشخص به دسترسی Administrator نیاز دارند. سادهترین پاسخ این است که همه آنها Local Admin باشند؛ اما همین میانبر، سطح حمله را بالا میبرد و کنترل اینکه «چه برنامهای با چه سطح دسترسی اجرا شده است» را از تیم امنیت میگیرد.
راه امنتر این است که دسترسی مدیریتی را از حساب روزمره کاربر حذف کنیم و فقط برنامه یا Task موردنیاز را در شرایط مشخص Elevate کنیم. Least Privilege با Application Control Plus و قابلیتهای Endpoint Privilege Management در اکوسیستم Endpoint Central همین الگو را ممکن میکنند: اجرای برنامه کنترل میشود، Privilege فقط هنگام نیاز بالا میرود و دسترسی موقت میتواند بعد از پایان Policy بهصورت خودکار جمع شود.
Least Privilege در Endpoint دقیقاً یعنی چه؟
اصل Least Privilege میگوید هر کاربر، Process یا Service فقط به حداقل سطح دسترسی لازم برای انجام وظیفه خود دسترسی داشته باشد. در Endpointها، مسئله اصلی معمولاً Local Administrator است. اگر کاربر همیشه Admin باشد، هر برنامهای که با Context او اجرا میشود میتواند دامنه بسیار بزرگتری از تغییرات را روی سیستم اعمال کند.
هدف EPM این نیست که همه عملیات مدیریتی را ممنوع کند؛ هدف این است که Privilege را از «هویت کاربر» جدا و به «برنامه، Task، زمان و Policy» متصل کند.
Application Control و Endpoint Privilege Management چه تفاوتی دارند؟
| کنترل | سؤال اصلی | نمونه تصمیم | ریسک هدف |
|---|---|---|---|
| Application Control | چه برنامهای اجازه اجرا دارد؟ | ابزار ناشناس Block شود | Shadow IT و اجرای نرمافزار غیرمجاز |
| Privilege Management | برنامه با چه سطح دسترسی اجرا شود؟ | فقط ابزار حسابداری Elevate شود | Local Admin دائمی و Privilege Escalation |
| Just-in-Time Access | این مجوز تا چه زمانی معتبر باشد؟ | دسترسی پس از بازه مشخص لغو شود | Privilege Creep |
| Audit | چه چیزی اجرا یا Elevate شد؟ | ثبت Rule و رویدادهای Block/Elevation | فقدان Traceability |
این دو لایه مکملاند. Allowlisting بدون Privilege Management میتواند اجرای برنامه را کنترل کند اما همچنان کاربر را Admin نگه دارد. Privilege Management بدون Application Control نیز ممکن است دامنه Applicationهای قابل اجرا را بیش از حد باز بگذارد.
نکته مهم درباره بستهبندی قابلیتها
در صفحه رسمی ManageEngine Application Control Plus، کنترل Application، Audit و قابلیتهای Privilege بهعنوان بخشی از راهکار معرفی میشوند؛ با این حال ManageEngine صراحتاً اعلام میکند قابلیتهای جدید Just-in-Time application access و Endpoint Privilege Management در Endpoint Central همراه با Add-on مربوط به Application Control و Endpoint Privilege Management ارائه میشوند. بنابراین قبل از خرید یا ارتقا، باید Edition و Add-on دقیق با سناریوی سازمان تطبیق داده شود.
برای بررسی محصول UEM اصلی میتوانید صفحه Endpoint Central در مدانت را ببینید و برای استعلام Edition/Metric از صفحه برآورد لایسنس ManageEngine استفاده کنید.
سناریوی اول: حذف Local Admin از کاربر مالی
فرض کنید یک نرمافزار قدیمی امضای دیجیتال فقط در حالت Administrator بهدرستی کار میکند. دادن Local Admin دائمی به تمام کاربران مالی یک کنترل پرریسک است. مسیر بهتر:
- Application را با Publisher، Product، Path یا معیار قابل اتکای دیگر شناسایی کنید.
- ابتدا رفتار آن را در Audit مشاهده کنید.
- فقط همان Executable مورد اعتماد را برای Elevation مجاز کنید.
- Child Processهای تولیدشده توسط برنامه را بررسی کنید.
- کاربر را از Local Administrators خارج کنید.
- پس از Rollout، رخدادهای Block و Elevation را بازبینی کنید.
در این مدل کاربر همچنان کارش را انجام میدهد، اما Credential ادمین در اختیار او نیست و همه Applicationها نیز Elevated نمیشوند.
سناریوی دوم: دسترسی موقت برای کارشناس IT
بعضی کارها دائمی نیستند: نصب Driver خاص، اجرای Diagnostic یا تغییر یک Component. اگر برای یک Task کوتاه دسترسی Admin دائمی ایجاد شود، همان Exception ممکن است ماهها باقی بماند.
Just-in-Time Access برای همین سناریو مناسب است. دسترسی موقت داده میشود و بعد از پایان بازه یا Policy لغو میشود. این طراحی باید همراه با Owner، دلیل، زمان انقضا و Audit باشد.
Self-Elevation بدون پخش Password ادمین
یکی از بدترین الگوها در Help Desk این است که Technician برای انجام کار، Password ادمین مشترک را برای کاربر ارسال کند. این کار Credential Sharing ایجاد میکند و بعداً مشخص نیست چه کسی از آن استفاده کرده است.
در مدل Self-Elevation یا Request-based Elevation، کاربر برای برنامه مشخص درخواست میدهد و مسیر Approval/Policy تصمیم میگیرد آیا Elevation مجاز است یا نه. نتیجه قابل ثبت است و Password مدیریتی افشا نمیشود.
Child Process Control؛ نقطهای که نباید فراموش شود
یک برنامه Elevateشده ممکن است Process فرزند بسازد. اگر Rule فقط Parent را ببیند اما Child Processها بدون کنترل Privilege بالاتر را به ارث ببرند، یک شکاف ایجاد میشود. برای برنامههای دارای Shell، Script Engine، Plugin یا قابلیت Launch کردن ابزار دیگر، Child Process باید در Pilot بررسی شود.
| Application | ریسک Child Process | کنترل پیشنهادی |
|---|---|---|
| Installer | اجرای Script یا CMD جانبی | محدودکردن Child Processهای مجاز |
| IDE/Developer Tool | اجرای Shell یا Package Manager | Rule محدود به Use Case مشخص |
| Admin Console | Launch ابزارهای مدیریتی دیگر | Audit و Allowlist دقیق |
| Legacy App | فراخوانی Helper Executable | شناسایی Chain واقعی قبل از Enforcement |
Rollout کمریسک: از Audit تا Enforcement
مرحله ۱: Local Admin Inventory
اول مشخص کنید چه حسابهایی عضو Local Administrators هستند و چرا. هر مورد باید Owner و دلیل کسبوکاری داشته باشد.
مرحله ۲: Application Discovery
برای هر گروه کاربری فهرست Applicationهایی را که واقعاً به Elevation نیاز دارند استخراج کنید. عبارت «کاربر Admin لازم دارد» Requirement قابل قبول نیست.
مرحله ۳: Audit Mode
ManageEngine برای Application Control امکان Audit را ارائه میدهد تا قبل از Block بتوانید ببینید چه چیزهایی تحت تأثیر Policy قرار میگیرند. این مرحله برای جلوگیری از اختلال ضروری است.
مرحله ۴: Pilot
Pilot را روی چند کاربر واقعی از واحدهای مختلف اجرا کنید. کاربران IT تنها نمونه مناسبی نیستند، چون الگوی نرمافزاری آنها با مالی، منابع انسانی یا طراحی متفاوت است.
مرحله ۵: Enforcement مرحلهای
ابتدا گروههای کمریسک، سپس واحدهای دارای Applicationهای Legacy و در نهایت کاربران حساس را منتقل کنید. Rollback Policy باید از قبل مشخص باشد.
چه زمانی Policy بیش از حد باز است؟
- هر فایل EXE از یک Folder مشترک Elevate میشود.
- همه نرمافزارهای یک Vendor بدون محدودیت Product مجاز هستند.
- Exception تاریخ انقضا ندارد.
- کاربر هم Local Admin است و هم EPM فعال دارد.
- Child Processها بررسی نشدهاند.
- Rule به Hash ثابت یک برنامه با Update مکرر وابسته است و فرآیند نگهداری ندارد.
KPIهای واقعی برای سنجش موفقیت
| KPI | چرا مهم است؟ |
|---|---|
| Standing Local Admin Count | نشان میدهد Privilege دائمی واقعاً کاهش یافته یا نه |
| JIT vs Permanent Exceptions | میزان تبدیل دسترسی موقت به Policy کنترلشده را نشان میدهد |
| Elevation Requests | نیازهای واقعی کاربران را آشکار میکند |
| Denied/Blocked Events | Policy نامناسب یا Shadow IT را پیدا میکند |
| Exception Age | دسترسیهای فراموششده را نشان میدهد |
| Help Desk Tickets after Enforcement | کیفیت Pilot و Rollout را میسنجد |
ارتباط با Application Allowlisting
برای اینکه EPM به مجوزی برای اجرای هر برنامه تبدیل نشود، بهتر است ابتدا Applicationهای مجاز و غیرمجاز را طبقهبندی کنید. مقاله Application Allowlisting در Application Control Plus طراحی Audit Mode، Rule و Rollout را توضیح میدهد. این دو کنترل کنار هم معماری Zero Trust Endpoint را عملیتر میکنند.
ارتباط با ITSM و مدیریت درخواست
درخواست Elevation برای برنامههای نادر بهتر است به یک Workflow قابل ردیابی وصل شود. اگر سازمان ServiceDesk Plus دارد، درخواست میتواند Owner، Approval، زمان انقضا و Evidence داشته باشد. برای طراحی Request Flow میتوانید از مفاهیم Service Request Management استفاده کنید.
چکلیست اجرایی
- Local Adminهای فعلی را Inventory کنید.
- Applicationهای نیازمند Elevation را شناسایی کنید.
- Application Group و Ruleهای قابل نگهداری بسازید.
- Audit Mode اجرا کنید.
- Child Processها را بررسی کنید.
- Pilot واقعی انجام دهید.
- JIT/Request-based Elevation را برای Exceptionها تعریف کنید.
- کاربران Pilot را از Local Admin خارج کنید.
- KPI و Ticketها را حداقل چند چرخه کاری بررسی کنید.
- Rollout را مرحلهای گسترش دهید.
نکات کلیدی
- Least Privilege یعنی Elevate کردن Task لازم، نه Admin کردن کاربر.
- Application Control و EPM دو کنترل مکمل هستند.
- Audit قبل از Enforcement ریسک اختلال را کم میکند.
- JIT Access از Privilege Creep جلوگیری میکند.
- Child Process باید جزئی از Policy باشد.
- Edition و Add-on دقیق باید قبل از خرید بررسی شود.
منابع رسمی
- ManageEngine Application Control Plus
- ManageEngine Endpoint Privilege Management
- ManageEngine Application Groups
سخن پایانی
حذف Local Admin نباید به معنی متوقفکردن کاربر باشد. طراحی درست این است که Application مورد اعتماد در زمان لازم با Privilege لازم اجرا شود و بقیه سطح دسترسی بسته بماند. Application Control Plus و قابلیتهای EPM در Endpoint Central ابزارهای لازم برای پیادهسازی این مدل را فراهم میکنند، اما نتیجه موفق به Audit، Pilot، Scope دقیق و مدیریت Exception وابسته است.
مدانت خدمات خرید و تمدید لایسنس ManageEngine، انتخاب Edition و Add-on، طراحی Least Privilege، استقرار، آموزش و پشتیبانی را ارائه میدهد. برای بررسی Metric و مدل لایسنس از استعلام لایسنس ManageEngine و برای طراحی سناریوی اجرایی از جلسه فنی و پروپوزال مدانت استفاده کنید.
