0

راهنمای عملی مدیریت Patch نرم‌افزارهای Third-party با Patch Manager Plus؛ از کاتالوگ 1100+ اپلیکیشن و APD تا Pilot، Approval، WAN، KPI و انتخاب Edition.

شرکت مدانت
شرکت مدانت
[ مجری تخصصی پیاده‌سازی چارچوب ITIL و تحول دیجیتال ]
مدیریت پچ نرم‌افزارهای ثالث با Patch Manager Plus؛ از 1100+ اپلیکیشن تا استقرار امن

ساعت ۹ صبح است و تیم زیرساخت مطمئن است Windows Update روی بیشتر سیستم‌ها اجرا شده. اما مرورگرها، Java، Adobe Reader، 7-Zip، ابزارهای توسعه، کلاینت‌های ارتباطی و ده‌ها نرم‌افزار دیگری که کاربران هر روز با آن‌ها کار می‌کنند چه؟

در بسیاری از شبکه‌ها، مدیریت Patch عملاً معادل «آپدیت ویندوز» شده است. این نگاه یک شکاف جدی ایجاد می‌کند: سیستم‌عامل ممکن است به‌روز باشد، اما یک نرم‌افزار Third-party قدیمی همچنان مسیر حمله، اختلال یا عدم انطباق باشد.

ManageEngine Patch Manager Plus برای مدیریت متمرکز Patch در Windows، macOS و Linux طراحی شده و طبق فهرست فعلی رسمی ManageEngine از بیش از ۱۱۰۰ نرم‌افزار Third-party پشتیبانی می‌کند. ارزش اصلی این قابلیت فقط تعداد Applicationها نیست؛ مهم‌تر این است که Discovery، دریافت Update، Test، Approval، Deployment و Reporting از یک فرآیند پراکنده به یک چرخه قابل‌کنترل تبدیل می‌شود.

اگر در سازمان هنوز هر Vendor با روش جداگانه Patch می‌شود، این راهنما کمک می‌کند معماری Third-party Patching را از مرحله Inventory تا Rollout و Rollback طراحی کنید.

چرا Third-party Patching معمولاً از Windows Update عقب می‌ماند؟

برای Windows یک مسیر نسبتاً شناخته‌شده وجود دارد. اما نرم‌افزارهای Third-party هرکدام Release Cycle، Installer، Silent Switch، Restart Behavior و Dependency مخصوص خودشان را دارند. همین تفاوت باعث می‌شود تیم IT برای هر Application یک روش جداگانه بسازد.

در عمل چند مشکل تکرار می‌شود:

  • کاربر Update Prompt را می‌بندد.
  • نسخه‌های مختلف یک Application روی سیستم‌ها باقی می‌ماند.
  • بعضی نرم‌افزارها Auto Update دارند و بعضی ندارند.
  • Proxy یا Firewall مانع دانلود مستقیم از Vendor می‌شود.
  • Patch روی گروهی از سیستم‌ها نیازمند Restart است.
  • نسخه قدیمی به‌خاطر Dependency یک نرم‌افزار حیاتی عمداً نگه داشته شده است.
  • تیم امنیت CVE را می‌بیند، اما تیم عملیات هنوز Package قابل‌استقرار آماده ندارد.

بنابراین Third-party Patching فقط «دانلود آخرین نسخه» نیست؛ یک مسئله Lifecycle، Change Control و Risk Management است.

Patch Manager Plus چه چیزی را در این چرخه متمرکز می‌کند؟

Patch Manager Plus چرخه Patch را از Detection تا Deployment و Reporting در یک Console مدیریت می‌کند. در حوزه Third-party، ManageEngine Packageهای آماده و تست‌شده برای Applicationهای پشتیبانی‌شده ارائه می‌کند و دریافت Updateها از Vendor را تا حد زیادی از فرآیند دستی جدا می‌سازد.

طبق صفحه رسمی Supported Applications، محصول در حال حاضر Windows، macOS و Linux را پوشش می‌دهد و کاتالوگ Third-party آن از ۱۱۰۰ Application عبور کرده است. این فهرست شامل گروه بزرگی از Browserها، ابزارهای Runtime، Utilities، Collaboration Tools و Applicationهای رایج سازمانی است.

برای سازمان، نتیجه عملی این است که به‌جای داشتن چند Script، چند ابزار Vendor-specific و چند Spreadsheet، یک Control Plane برای Patch Compliance ایجاد می‌شود.

اولین قدم: Inventory را قبل از Patch Policy درست کنید

یکی از اشتباهات رایج این است که تیم IT ابتدا Policy استقرار می‌سازد و بعد می‌پرسد چه نرم‌افزارهایی واقعاً در سازمان وجود دارند.

مسیر بهتر این است:

  1. Applicationهای نصب‌شده را شناسایی کنید.
  2. نسخه‌های رایج و Outlierها را مشخص کنید.
  3. نرم‌افزارهای Unsupported یا EOL را جدا کنید.
  4. Application Owner را برای نرم‌افزارهای حیاتی تعیین کنید.
  5. گروه‌های Pilot را براساس Workload بسازید.
  6. بعد Patch Policy را تعریف کنید.

برای مثال، اگر یک نسخه قدیمی Java فقط روی سه سیستم مربوط به یک نرم‌افزار مالی Legacy وجود دارد، نباید همان Policy عمومی Browserها روی آن اعمال شود. Inventory بدون Context می‌تواند Automation خطرناک بسازد.

همه Patchها را با یک سرعت منتشر نکنید

در Patch Management بالغ، سرعت استقرار به Risk و Criticality بستگی دارد. یک Update برای Browser اینترنتی با یک Update برای ابزار کم‌استفاده داخلی ارزش زمانی یکسانی ندارد.

یک مدل عملی می‌تواند این باشد:

نوع Patch نمونه رویکرد پیشنهادی
آسیب‌پذیری Exploited Browser یا Runtime دارای سوءاستفاده فعال Fast-track پس از تست کوتاه
Critical Security RCE یا Privilege Escalation مهم Pilot سریع و Rollout مرحله‌ای
High/Medium Security Patchهای معمول امنیتی چرخه استاندارد
Bug Fix غیرامنیتی رفع Crash یا ناسازگاری بر اساس نیاز Business
Feature Update نسخه Major جدید Change جداگانه و تست گسترده‌تر

برای Prioritization امنیتی، استفاده از CISA Known Exploited Vulnerabilities Catalog در کنار Severity و Criticality دارایی مفید است. خود CISA توصیه می‌کند KEV به‌عنوان ورودی Framework اولویت‌بندی Vulnerability Management استفاده شود.

Automated Patch Deployment یا APD را چطور طراحی کنیم؟

Patch Manager Plus امکان Automated Patch Deployment را دارد. اما Automation خوب یعنی Rule روشن، نه صرفاً فعال کردن یک Schedule.

برای هر APD Task بهتر است حداقل این موارد مشخص باشد:

  • کدام Productها و Vendorها وارد Scope هستند؟
  • چه Severityهایی مجازند؟
  • Patchهای Newly Released چند روز Hold شوند؟
  • Deployment Window چه زمانی است؟
  • Restart چگونه مدیریت می‌شود؟
  • کاربر چقدر امکان Postpone دارد؟
  • Remote Officeها چه محدودیت Bandwidth دارند؟
  • Failure بعد از چند Attempt Escalate می‌شود؟

FAQ رسمی Patch Manager Plus که در ۵ اوت ۲۰۲۶ به‌روزرسانی شده، توصیه می‌کند APD به‌صورت منظم اجرا شود تا Endpointها به‌روز بمانند. همان مستند توضیح می‌دهد که APD برای Patchهای Missing دوباره تلاش می‌کند و رفتار Retry بسته به نوع Failure می‌تواند متفاوت باشد.

Third-party Patch را مستقیم روی Production نفرستید

حتی اگر Package رسمی باشد، Application Context سازمان شما منحصربه‌فرد است. Pluginها، Add-onها، Integrationها و نرم‌افزارهای Legacy ممکن است به Version خاصی وابسته باشند.

برای همین بهتر است Deployment Ring داشته باشید:

Ring ترکیب پیشنهادی هدف
Pilot IT و چند کاربر داوطلب کشف Failure و ناسازگاری اولیه
Early Production ۵ تا ۱۵ درصد Endpointها اعتبارسنجی در Workload واقعی
General بخش عمده کاربران Rollout اصلی
Critical/Exception سیستم‌های حساس یا Legacy استقرار با Window و Approval جداگانه

Patch Manager Plus در Enterprise Edition قابلیت Test & Approve دارد. FAQ رسمی محصول می‌گوید می‌توانید Test Group تعریف کنید و Patchها پس از دوره مشخص، در صورت نبود Failure، خودکار Approve شوند یا Approval را دستی نگه دارید.

مدانت یک ورکشاپ تخصصی Patch Manager Plus نیز دارد که برای تیم‌هایی که می‌خواهند این Workflowها را در محیط واقعی طراحی کنند، مسیر آموزشی مستقیمی فراهم می‌کند.

فرق Test با Approval چیست؟

Test یعنی بررسی رفتار Patch روی یک Scope محدود. Approval یعنی تصمیم رسمی برای ورود Patch به Deployment عمومی.

این دو را نباید یکی دانست. ممکن است نصب Patch روی Pilot موفق باشد، اما Business Owner به‌دلیل یک Change مهم در همان هفته، Rollout را چند روز عقب بیندازد. از طرف دیگر یک Patch امنیتی Exploited ممکن است با Window کوتاه‌تری وارد Approval شود.

پس بهتر است Technical Success و Business Approval دو Signal جدا باشند.

Patchهای Third-party چه زمانی باید Decline شوند؟

گاهی یک Vendor یا Application توسط ابزار دیگری مدیریت می‌شود. در این حالت دو Patch Engine هم‌زمان روی یک Application می‌توانند رفتار غیرقابل‌پیش‌بینی ایجاد کنند.

FAQ فعلی Patch Manager Plus امکان Decline کردن Patchهای یک Vendor یا Application را توضیح می‌دهد. Patch Declined دیگر در محاسبه Missing و Health Status وارد نمی‌شود و از APD هم استقرار پیدا نمی‌کند.

این قابلیت برای جلوگیری از Tool Conflict مهم است، اما Decline باید مستند باشد. هر Exception بهتر است Owner، دلیل و Expiry Date داشته باشد؛ وگرنه «استثنای موقت» به بدهی دائمی تبدیل می‌شود.

Restart Management را بخشی از Patch Design بدانید

یکی از دلایل شکست Patch Program این است که تیم فقط Installation Success را می‌بیند. بعضی Patchها تا Restart کامل نمی‌شوند. اگر کاربر ماه‌ها سیستم را Restart نکند، Dashboard ممکن است وضعیت پیچیده‌ای نشان دهد.

در طراحی Policy مشخص کنید:

  • کدام Patchها Restart اجباری دارند؟
  • کاربر چند بار امکان Postpone دارد؟
  • برای Serverها Maintenance Window چیست؟
  • پس از Restart چه Health Checkی اجرا می‌شود؟
  • چه سیستم‌هایی نباید خودکار Restart شوند؟

برای Serverهای حیاتی، Restart بخشی از Change است نه فقط یک Setting در Patch Tool.

LAN و WAN یک Policy مشترک نمی‌خواهند

وقتی Endpointها در چند شعبه یا WAN توزیع شده‌اند، دانلود هم‌زمان Packageهای Third-party می‌تواند Link را اشباع کند. در Edition Comparison فعلی ManageEngine، Professional بیشتر برای LAN و Enterprise برای سناریوهای WAN و معماری توزیع‌شده‌تر معرفی شده است. Enterprise همچنین قابلیت‌های Bandwidth Optimization و Distribution Server را در اختیار می‌گذارد.

اگر چند سایت دارید، قبل از خرید فقط تعداد Endpoint را نشمارید؛ Topology شبکه، تعداد Remote Office، لینک‌ها و Maintenance Window هر سایت را هم وارد Sizing کنید.

Professional یا Enterprise؛ برای Third-party Patching کدام مناسب‌تر است؟

هر دو Edition اصلی Third-party Patch Management را پوشش می‌دهند، اما Enterprise برای کنترل Rollout در محیط‌های پیچیده‌تر قابلیت‌های بیشتری دارد.

نیاز Professional Enterprise
Windows/macOS/Linux Patching بله بله
Third-party Patch Management بله بله
Patch Reports بله بله
Test & Approve خودکار محدودتر بله
Distribution Server / WAN برای LAN مناسب‌تر مناسب‌تر برای WAN
Driver/BIOS/AV Updates خیر یا محدود بله طبق ماتریس فعلی
Bandwidth Optimization پایه پیشرفته‌تر

در زمان نگارش این مطلب، صفحه رسمی Edition Comparison برای Subscription سالانه On-Premises با ۵۰ Computer و یک Technician، قیمت پایه ۲۴۵ دلار برای Professional و ۳۴۵ دلار برای Enterprise را نمایش می‌دهد. قیمت منطقه‌ای، مالیات، Add-on، تعداد Endpoint و شرایط قرارداد می‌تواند Quote نهایی را تغییر دهد؛ برای برآورد واقعی می‌توانید از استعلام قیمت لایسنس ManageEngine مدانت استفاده کنید.

Patch Manager Plus یا Endpoint Central؟

اگر نیاز اصلی سازمان Patch Management است، Patch Manager Plus ابزار متمرکز و اقتصادی‌تری برای همین Scope است.

اگر علاوه بر Patch به Software Deployment، Remote Troubleshooting، Asset Management، Device Control، UEM و سایر قابلیت‌های Endpoint Management نیاز دارید، Endpoint Central می‌تواند انتخاب گسترده‌تری باشد.

بهتر است ابزار را بر اساس Capability Map انتخاب کنید، نه بر اساس اینکه «هرچه امکانات بیشتر باشد بهتر است». اگر ۸۰ درصد قابلیت‌های UEM استفاده نمی‌شود، ممکن است Patch Manager Plus پاسخ دقیق‌تری به نیاز فعلی باشد.

Patch Management با Vulnerability Management یکی نیست

Patch Manager Plus پاسخ می‌دهد: چه Patchهایی موجود و Missing هستند و چگونه آن‌ها را تست، Approve و Deploy کنیم؟

Vulnerability Management سؤال گسترده‌تری دارد: کدام Vulnerability واقعاً Risk بیشتری دارد، چه Misconfigurationهایی وجود دارد، چه Zero-dayهایی باید Mitigate شوند و اولویت Remediation چیست؟

اگر این دو Scope را با هم اشتباه بگیریم، ممکن است تصور کنیم نصب همه Patchها مساوی مدیریت کامل Vulnerability است. برای مقایسه نگاه Risk-based می‌توانید مقاله Risk-Based Vulnerability Management در Vulnerability Manager Plus را بخوانید.

Compliance را با «تعداد Patch نصب‌شده» نسنجید

یک Dashboard که ۹۸ درصد Patch Compliance نشان می‌دهد خوب است، اما باید بدانید آن دو درصد باقی‌مانده چیست.

دو Endpoint اینترنتی دارای Vulnerability Exploited می‌توانند مهم‌تر از ۲۰۰ Laptop با یک Update کم‌اهمیت باشند.

برای همین گزارش مدیریتی بهتر است حداقل این Dimensionها را داشته باشد:

  • Compliance کلی
  • Critical/High Missing Patches
  • Known Exploited Vulnerabilities در Scope سازمان
  • Patch Age
  • Endpoint Criticality
  • Failure Rate
  • Mean Time to Patch
  • Exception Count
  • Restart Pending

یک Runbook پیشنهادی برای Third-party Patching

می‌توانید چرخه عملیاتی را به این شکل طراحی کنید:

  1. روزانه: Sync کاتالوگ، Scan Missing Patch و بررسی Vulnerabilityهای فعال.
  2. روزانه: Fast-track برای Patchهای دارای Exploitation فعال یا ریسک بالا.
  3. هفتگی: Deploy Patchهای Standard در Pilot Group.
  4. پس از Validation: Approval و Rollout روی Early Production.
  5. پس از Window: Rollout عمومی.
  6. پس از Deployment: بررسی Failure، Restart Pending و Health.
  7. ماهانه: بازبینی Declineها، Exceptionها و Applicationهای EOL.
  8. فصلی: بازبینی Edition، Endpoint Count، WAN Architecture و License Sizing.

این Runbook باید با Change Calendar، Maintenance Window و Business Criticality خود سازمان تنظیم شود.

چه KPIهایی برای Patch Program ارزش مدیریتی دارند؟

KPI معنا
Patch Compliance درصد Endpointهای منطبق با Baseline
Mean Time to Patch زمان متوسط از Release تا Deployment موفق
Critical Patch SLA درصد Patchهای Critical نصب‌شده در SLA
Deployment Failure Rate نرخ Installation Failure
Rollback Rate درصد Patchهایی که نیاز به بازگشت داشته‌اند
Exception Age سن استثناهای باز
Third-party Coverage درصد Applicationهای Third-party تحت مدیریت مرکزی
Restart Pending تعداد Endpointهایی که Patch هنوز کامل نشده است

هدف KPI این نیست که Dashboard سبز شود؛ هدف این است که تیم بفهمد Risk کجا باقی مانده و چرا.

چه زمانی Automation را متوقف کنیم؟

Automation باید Default باشد، اما Exceptionهای واقعی وجود دارند.

برای این موارد بهتر است Deployment خودکار متوقف و Change کنترل‌شده اجرا شود:

  • Applicationهای حیاتی Legacy
  • Major Version Upgrade
  • Patch با سابقه Known Issue
  • Serverهای حساس با RTO پایین
  • سیستم‌های OT یا تجهیزات خاص
  • Applicationهایی که Vendor شرط Version Lock دارد

در این شرایط، نداشتن Patch ممکن است موقتاً پذیرفته شود، اما باید Compensating Control، Owner و Expiry مشخص باشد.

نقش مدانت در طراحی Patch Management

خرید License فقط شروع کار است. ارزش Patch Manager Plus زمانی ایجاد می‌شود که Scope، Pilot، Approval، Deployment Policy، WAN Design، Reporting و Exception Management متناسب با محیط سازمان تنظیم شده باشند.

مدانت برای محصولات ManageEngine خدمات پشتیبانی، آموزش، استقرار و مشاوره ارائه می‌کند. اگر بین Patch Manager Plus، Endpoint Central و Vulnerability Manager Plus مردد هستید، بهتر است ابتدا Capability و تعداد Endpoint، نوع OS، Remote Officeها و سطح امنیت موردنیاز را مشخص کنید.

برای بررسی معماری و انتخاب Edition می‌توانید از درخواست جلسه و پروپوزال مدانت استفاده کنید و برای آموزش اجرایی نیز ورکشاپ تخصصی Patch Manager Plus در دسترس است.

نکات کلیدی

  • Third-party Patching را از Inventory شروع کنید، نه از Schedule.
  • Patch Manager Plus در فهرست فعلی رسمی بیش از ۱۱۰۰ Application ثالث را پشتیبانی می‌کند.
  • Patchهای Exploited و Critical باید مسیر Fast-track داشته باشند.
  • Pilot و Approval را از Rollout عمومی جدا کنید.
  • Decline و Exception باید Owner و Expiry داشته باشند.
  • برای WAN، Bandwidth و Distribution Architecture بخشی از Sizing است.
  • Professional و Enterprise هر دو Third-party Patching دارند، اما Enterprise برای Test & Approve و محیط‌های WAN قابلیت‌های بیشتری دارد.
  • Patch Compliance به‌تنهایی Risk را نشان نمی‌دهد؛ Criticality و Exploitability هم باید وارد گزارش شوند.

سخن پایانی

وقتی مدیریت Patch فقط Windows Update باشد، بخش بزرگی از Software Surface سازمان بیرون از کنترل باقی می‌ماند. Browserها، Runtimeها، Utilities و Applicationهای Third-party همان اندازه‌ای که برای کاربر مفیدند، می‌توانند Lifecycle و Risk مستقل خودشان را داشته باشند.

Patch Manager Plus این پراکندگی را به یک چرخه متمرکز تبدیل می‌کند: Discover، Test، Approve، Deploy و Report. اما موفقیت واقعی از خود Tool شروع نمی‌شود؛ از Policy درست، Pilot واقعی، اولویت‌بندی بر اساس Risk و Exception Management منظم شروع می‌شود.

اگر می‌خواهید بدانید برای تعداد Endpointها، شعب، OSها و نرم‌افزارهای فعلی سازمان شما Professional مناسب‌تر است یا Enterprise، از صفحه استعلام لایسنس ManageEngine یا درخواست مشاوره و پروپوزال مدانت استفاده کنید.

منابع

مطالب مرتبط جهت افزایش سطح دانش شما:

دیدگاه شما

دیدگاه مرتبط و محترمانه بنویسید.