فرض کنید در یک سازمان چند ده سرور Linux دارید: بخشی روی RHEL، بخشی Ubuntu، چند ماشین Debian و تعدادی Rocky Linux یا Amazon Linux. تیم امنیت CVEهای مهم را پیگیری می‌کند، اما تیم عملیات نگران است که نصب یک Kernel Update یا Package جدید، سرویس را از دسترس خارج کند. در نتیجه Patchها عقب می‌افتند، استثناها زیاد می‌شوند و بعد از چند ماه دیگر کسی تصویر دقیقی از وضعیت Patch Compliance ندارد.

Linux Patch Management با Patch Manager Plus برای حل همین تعارض طراحی می‌شود: Patchها باید سریع اعمال شوند، اما نه بدون Pilot، Maintenance Window، کنترل Reboot و گزارش‌گیری. هدف فقط «آپدیت‌کردن Linux» نیست؛ هدف ساختن یک فرآیند Patch Management قابل‌کنترل برای سرور و Endpointهای Linux است.

Linux Patching چرا در محیط سازمانی دشوار می‌شود؟

در یک سرور منفرد، اجرای apt، yum یا dnf کار ساده‌ای است. مسئله وقتی سخت می‌شود که صدها یا هزاران Endpoint، چند Distribution، چند Site و چند سطح Criticality وجود داشته باشد.

Patch Manager Plus در Linux چه کاری انجام می‌دهد؟

طبق مستندات رسمی ManageEngine، فرآیند Linux Patching در Patch Manager Plus شامل Scan برای Missing Patch، دریافت Patch از Vendor، Deploy روی سیستم‌های هدف و Reporting وضعیت است. قابلیت Automate Patch Deployment یا APD می‌تواند این چرخه را از شناسایی تا استقرار خودکار کند.

این مدل برای تیم‌هایی مهم است که نمی‌خواهند Patch Management وابسته به ورود دستی Admin به هر سرور باشد.

چه Distributionهایی پشتیبانی می‌شوند؟

فهرست پشتیبانی ManageEngine به‌روزرسانی می‌شود و باید قبل از طراحی نهایی Architecture بررسی شود. در مستندات فعلی Patch Manager Plus، خانواده‌های زیر برای Linux Patch Management دیده می‌شوند:

• Red Hat Enterprise Linux؛
• Ubuntu؛
• Debian GNU/Linux؛
• SUSE Linux Enterprise؛
• CentOS Stream؛
• Oracle Linux؛
• Rocky Linux؛
• Amazon Linux؛
• و در فهرست Supported Applications نسخه‌های جدیدتر برخی Distributionها مانند AlmaLinux نیز درج شده‌اند.

برای نمونه، مستند جاری ManageEngine در سپتامبر ۲۰۲۶ نسخه‌هایی مانند RHEL 8 و 9، Ubuntu 20 به بعد، Debian 11 و 12، CentOS 9 Stream، Rocky Linux 8 و 9 و Amazon Linux 2 و 2023 را در راهنمای Linux Patch Management ذکر می‌کند. با توجه به تغییر مداوم چرخه پشتیبانی Distributionها، Sizing و Compatibility باید پیش از خرید با نسخه رسمی همان روز تطبیق داده شود.

Security Patch و Non-security Update را جدا ببینید

همه Updateها اولویت یکسان ندارند. در Patch Governance بهتر است حداقل سه کلاس داشته باشید:

1. Critical Security: با SLA کوتاه و Pilot سریع؛
2. Important/Security: در چرخه منظم Patch؛
3. Non-security/Feature: با Maintenance Window و Change Review دقیق‌تر.

ManageEngine امکان Filter و انتخاب Patchها بر اساس Severity و نوع Update را در فرآیند Deployment ارائه می‌کند.

APD چیست و چرا برای Linux مهم است؟

Automate Patch Deployment چرخه Patch را به Task قابل‌تکرار تبدیل می‌کند. به‌جای اینکه Admin هر هفته لیست Missing Patch را دستی بررسی کند، می‌توان Rule تعریف کرد که Patchهای مشخص پس از Scan، Approval و زمان‌بندی مناسب Deploy شوند.

در مستند رسمی ManageEngine، APD برای Linux به چهار بخش اصلی تقسیم می‌شود:

1. انتخاب Application و Severity؛
2. انتخاب Deployment Policy؛
3. تعریف Target مانند Domain یا Remote Office؛
4. تنظیم Notification.

در عمل بهتر است این Automation را با Ring Deployment ترکیب کنید و Production را Target اول قرار ندهید.

مدل Ring Deployment برای Linux

ManageEngine نیز در راهنمای Linux Patching توصیه می‌کند Patchها ابتدا روی Pilot Group تست شوند و سپس مرحله‌ای به Production برسند. این موضوع به‌خصوص برای Kernel، Driver و Packageهایی که Dependency حساس دارند اهمیت دارد.

Kernel Update؛ Patch نصب شد اما کار تمام نشده است

در Linux، نصب Kernel جدید همیشه به معنی فعال‌شدن همان Kernel نیست. ممکن است Reboot لازم باشد تا نسخه جدید Load شود. بنابراین Patch Compliance باید دو سؤال جدا داشته باشد:

• آیا Package یا Kernel Patch نصب شده است؟
• آیا سیستم با نسخه جدید Boot شده است؟

اگر سازمان فقط Install Status را ببیند اما Pending Reboot را مدیریت نکند، ممکن است Server از نظر Console Patch‌شده باشد ولی Runtime هنوز نسخه آسیب‌پذیر قبلی را استفاده کند.

Reboot Policy را بر اساس Criticality تعریف کنید

یک Policy واحد برای همه Linux Serverها منطقی نیست. Database Cluster، Web Server، Jump Host و Developer Workstation نیازهای متفاوتی دارند.

Patch Manager Plus Deployment Policy امکان سفارشی‌سازی زمان استقرار و Reboot را فراهم می‌کند؛ اما معماری HA و ترتیب Restart باید با Application Owner هماهنگ شود.

RHEL؛ Subscription و Repository را فراموش نکنید

در راهنمای رسمی Red Hat Patching، ManageEngine تأکید می‌کند که Endpointهای RHEL باید Subscription معتبر داشته باشند و دسترسی Repository/CDN به‌درستی برقرار باشد. در مستند به‌روز ۶ اوت ۲۰۲۶، برای RHEL توصیه شده سیستم Managed دارای Subscription استاندارد باشد و دسترسی به cdn.redhat.com از طریق YUM/Proxy امکان‌پذیر باشد.

این نکته مهم است: اگر Repository یا Subscription مشکل داشته باشد، Patch Manager نمی‌تواند محدودیت Vendor را جادویی دور بزند. Repository Health بخشی از Patch Architecture است.

Ubuntu و Debian؛ تفاوت Package Management با Governance

در Ubuntu و Debian، تیم فنی معمولاً با apt-get update و apt-get upgrade آشناست. ارزش ابزار متمرکز در جایگزینی Command Line نیست؛ در Governance است: چه Patchی Missing است، چه Serverی Failure دارد، کدام Deployment مجاز بوده و وضعیت Compliance کل سازمان چیست.

یعنی ابزار Patch Management باید دانش عملیاتی Linux Admin را تکمیل کند، نه اینکه آن را حذف کند.

Patch Failure را به صف عملیاتی تبدیل کنید

گزارش «Failed» به‌تنهایی کافی نیست. Failureها باید دسته‌بندی شوند:

• Repository unavailable؛
• Dependency conflict؛
• Disk space ناکافی؛
• Endpoint offline؛
• Agent/Communication issue؛
• Reboot Pending؛
• Package held یا Policy Exception.

برای هر دسته Runbook تعریف کنید تا Failure هر هفته دوباره ظاهر نشود.

Patch Compliance را چگونه اندازه‌گیری کنیم؟

چند KPI مفید:

• درصد Endpointهای Fully Patched؛
• تعداد Critical Patchهای بیشتر از SLA؛
• Mean Time to Patch برای Critical Vulnerability؛
• نرخ Failure استقرار؛
• تعداد Pending Reboot؛
• درصد Serverهای خارج از Maintenance Window؛
• تعداد Exceptionهای فعال و تاریخ انقضای آن‌ها.

Patch Manager Plus و Vulnerability Manager Plus چه تفاوتی دارند؟

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

همچنین برای مدیریت Patch نرم‌افزارهای Third-party در Windows/macOS/Linux، مقاله مدیریت پچ نرم‌افزارهای ثالث با Patch Manager Plus مکمل همین راهنماست.

Bandwidth در شعب و Remote Office

دانلود تکراری Packageها در چندین Endpoint می‌تواند WAN را تحت فشار قرار دهد. ManageEngine در راهنمای Linux Patch Management به مدل Bandwidth-efficient اشاره می‌کند که Patch یک‌بار دریافت و در شبکه توزیع می‌شود. در معماری چندسایتی، Repository و Distribution Design باید قبل از Rollout در نظر گرفته شود.

سناریوی عملی: Patch کردن ۱۲۰ سرور Linux

فرض کنید سازمان ۱۲۰ سرور دارد:

• ۴۰ RHEL؛
• ۴۵ Ubuntu؛
• ۲۰ Rocky Linux؛
• ۱۵ Debian.

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

1. Inventory و Owner هر Server تکمیل شود.
2. Criticality و Maintenance Window تعریف شود.
3. Repository/Subscription بررسی شود.
4. Missing Patch Scan اجرا شود.
5. Critical Security Updateها در Ring 0 Deploy شوند.
6. پس از Observation به Ring 1 و 2 منتقل شوند.
7. Critical Production پس از Approval Patch شود.
8. Pending Reboot جداگانه بررسی شود.
9. Failureها Triage شوند.
10. Compliance Report برای Security و Operations منتشر شود.

Integration با Change Management

برای Serverهای حیاتی، Patch Deployment باید به Change Management متصل باشد. Patch Window، Backup Status، Rollback Plan و Service Owner باید قبل از اجرا مشخص باشند.

اگر سازمان از ServiceDesk Plus استفاده می‌کند، Change Request می‌تواند مرجع رسمی Approval و Evidence باشد و تیم Patch Execution را به فرآیند ITSM وصل کند. منابع عملی Change Management در Service Desk مدانت قابل استفاده است.

چه زمانی Manual Deployment بهتر از APD است؟

Automation همیشه انتخاب درست نیست. برای موارد زیر Manual یا Approval-based Deployment می‌تواند مناسب‌تر باشد:

• Kernel Update روی Server تک‌نقطه‌ای؛
• Database Cluster حساس؛
• Patch با Known Issue؛
• Server دارای Application Legacy؛
• Emergency Remediation با ترتیب خاص.

برای Endpointهای استاندارد و Patchهای تکرارشونده، APD ارزش بیشتری دارد.

چک‌لیست استقرار Patch Manager Plus برای Linux

• فهرست Distribution و Versionها تکمیل شده است.
• Support Matrix رسمی بررسی شده است.
• RHEL/SUSE Subscription و Repository معتبر است.
• Pilot Group تعریف شده است.
• Ring Deployment وجود دارد.
• Maintenance Window برای Serverهای حیاتی ثبت شده است.
• Reboot Policy جداگانه تعریف شده است.
• Patch Exception دارای Owner و Expiry است.
• Failure Runbook نوشته شده است.
• Compliance KPI به Security و Operations گزارش می‌شود.

نکات کلیدی

• Linux Patching در مقیاس سازمانی مسئله Governance است، نه فقط اجرای apt یا yum.
• Patch Manager Plus می‌تواند Scan، Deployment، APD و Reporting را متمرکز کند.
• Pilot و Ring Deployment ریسک Patch را کاهش می‌دهد.
• Kernel Update بدون مدیریت Reboot ممکن است Protection مورد انتظار را فعال نکند.
• Repository و Subscription بخشی از معماری Patch هستند.
• Patch Compliance باید Failure، Pending Reboot و SLA را نیز ببیند.

منابع

• ManageEngine — Linux Patch Management
• ManageEngine — Red Hat Linux Patching
• ManageEngine — RHEL Patch Management Settings
• ManageEngine — Patch Manager Plus

سخن پایانی

Linux Patch Management زمانی قابل اتکا می‌شود که سرعت Remediation با کنترل Change و Availability متعادل باشد. Patch Manager Plus می‌تواند این چرخه را از Missing Patch Scan تا Pilot، APD، Deployment، Reboot و Compliance Reporting در یک کنسول متمرکز کند؛ اما کیفیت نتیجه همچنان به معماری Ring، Maintenance Window و Runbook تیم شما وابسته است.

مدانت خدمات استعلام و خرید لایسنس Patch Manager Plus، طراحی Patch Architecture، نصب و استقرار، تعریف APD و Pilot Group، Patch Compliance، اتصال به Change Management، آموزش و پشتیبانی ارائه می‌کند. برای استعلام قیمت و Edition مناسب به صفحه خرید لایسنس ManageEngine مدانت مراجعه کنید یا برای طراحی و پیاده‌سازی از مشاوره مدانت استفاده کنید.