فرض کنید در یک ممیزی امنیتی مشخص می‌شود روی بخشی از سوئیچ‌ها و فایروال‌های سازمان هنوز تنظیماتی وجود دارد که با Baseline امنیتی شما هم‌خوان نیست: یک SNMP Community قدیمی، یک Interface بلااستفاده که هنوز فعال است، یک Rule یا Command که نباید روی Deviceهای Production باقی می‌ماند یا Configهایی که در چند شعبه به‌مرور از استاندارد اصلی فاصله گرفته‌اند.

مشکل فقط پیدا کردن این موارد نیست. مسئله واقعی این است که تیم شبکه باید بتواند تفاوت بین «عدم انطباق» و «تغییر پرریسک» را مدیریت کند. اگر Compliance صرفاً یک گزارش باشد، اصلاح‌ها عقب می‌افتند؛ اگر Remediation بدون کنترل اجرا شود، خود ابزار Compliance می‌تواند منبع اختلال شود.

ComplianceIQ در ManageEngine Network Configuration Manager برای همین نقطه طراحی شده است: تعریف Ruleهای چندمرحله‌ای، بررسی Configuration یا Command Output، تشخیص Violation و در صورت نیاز اجرای Remediation با Configlet. این قابلیت از ژانویه ۲۰۲۶ در خانواده NCM توسعه جدی‌تری پیدا کرده و به تیم شبکه اجازه می‌دهد سیاست‌های CIS و Baselineهای اختصاصی سازمان را از یک Checklist دستی به یک Workflow اجرایی تبدیل کند.

در این راهنما، ComplianceIQ را از دید عملی بررسی می‌کنیم: چطور Rule بسازیم، چه زمانی Auto-Remediation را فعال کنیم، چگونه Change Control را کنار Compliance نگه داریم و چه معماری‌ای برای استفاده امن در محیط Production مناسب‌تر است.

چرا Compliance شبکه فقط یک موضوع Audit نیست؟

پیکربندی تجهیزات شبکه به‌مرور تغییر می‌کند. بخشی از این تغییرها برنامه‌ریزی‌شده‌اند، بخشی در Incidentها انجام می‌شوند و بعضی هم به‌صورت Temporary Change باقی می‌مانند. اگر Baseline تعریف‌شده‌ای وجود نداشته باشد، چند ماه بعد دقیقاً نمی‌دانیم کدام تنظیم «استاندارد» و کدام تنظیم «انحراف» است.

این همان جایی است که Configuration Compliance به عملیات روزمره شبکه وصل می‌شود. یک Policy مناسب می‌تواند به‌صورت خودکار بررسی کند که Config دستگاه باید چه چیزی داشته باشد یا نداشته باشد و در صورت Violation، Severity و مسیر اصلاح را مشخص کند.

اگر هنوز با منطق Benchmarkها آشنا نیستید، مقاله کنترل‌های امنیتی CIS چیست؟ در مدانت نقطه شروع مناسبی است. هدف در NCM این نیست که CIS را صرفاً بخوانیم؛ هدف این است که Rule قابل‌اجرا بسازیم و نتیجه را روی Deviceهای واقعی ببینیم.

ComplianceIQ چیست و چه تفاوتی با Rule ساده دارد؟

در مدل سنتی Compliance، Rule معمولاً یک سؤال ساده بود: آیا یک عبارت در Configuration وجود دارد یا نه؟ این روش برای کنترل‌های ساده همچنان مفید است، اما محیط واقعی همیشه خطی نیست.

ComplianceIQ در Network Configuration Manager اجازه می‌دهد Rule به شکل Flow طراحی شود؛ یعنی بتوانیم Condition، Loop، Process و مسیرهای متفاوت را کنار هم قرار دهیم. نتیجه می‌تواند یکی از حالت‌های Compliant، Violation یا Not Required باشد.

طبق مستندات فعلی ManageEngine، یک Violation می‌تواند علاوه بر Severity و پیام، شامل Remediation Procedure و Remediation Configlet هم باشد. در صورت نیاز حتی می‌توان اجرای خودکار Configlet را فعال کرد؛ اما این بخش همان جایی است که Governance اهمیت پیدا می‌کند.

چه چیزی در ۲۰۲۶ به ComplianceIQ اضافه شد؟

ManageEngine در Build 12.8.665 که در ۹ ژانویه ۲۰۲۶ منتشر شد، ComplianceIQ را به‌عنوان ماژول بازطراحی‌شده Compliance معرفی کرد. در همین نسل، Ruleها می‌توانند از شرط‌های if/else پیچیده، Loop Chain، Dynamic Variable و حتی Command Output برای ارزیابی Compliance استفاده کنند.

در ادامه سال ۲۰۲۶ نیز تغییرها فقط ظاهری نبودند. در Buildهای بعدی، Bulk Remediation، نمایش محتوای Configlet قبل از اصلاح، معیارهای بیشتر برای انتخاب Device و Policy، خروجی‌های غنی‌تر Compliance و Policyهای جدید CIS اضافه شدند. در به‌روزرسانی اوت ۲۰۲۶ نیز ستون IP Address به گزارش CSV Compliance اضافه شد.

این روند نشان می‌دهد Compliance در NCM از یک Report ثابت به سمت یک چرخه تشخیص، تصمیم و اصلاح حرکت کرده است.

سناریو: Interface بلااستفاده روی سوئیچ Production

یک مثال ساده را در نظر بگیرید. استاندارد داخلی سازمان می‌گوید Interfaceهایی که استفاده نمی‌شوند باید Disable باشند.

در یک شبکه کوچک شاید این مورد را دستی بررسی کنید. اما وقتی ده‌ها یا صدها Switch دارید، بررسی دستی هم زمان‌بر است و هم قابل اتکا نیست.

در ComplianceIQ می‌توان Rule را طوری طراحی کرد که:

1. Block مربوط به Interfaceها را پیدا کند.
2. شرط‌های موردنیاز برای تشخیص Interface بلااستفاده را بررسی کند.
3. اگر شرط نقض شد، Violation با Severity مناسب ایجاد کند.
4. پیام Violation را با Variableهایی مثل نام Interface قابل‌فهم‌تر کند.
5. Remediation Procedure را نمایش دهد.
6. در صورت تأیید سازمان، Configlet اصلاح را آماده اجرا کند.

مزیت این رویکرد این است که Rule دیگر فقط نمی‌گوید «غیرمنطبق است»؛ می‌تواند Context و Action هم بدهد.

جدول طراحی یک Rule استاندارد

چه Policyهایی را بهتر است اول وارد NCM کنیم؟

شروع از تمام Benchmarkها در روز اول معمولاً تصمیم خوبی نیست. بهتر است Policyهایی را انتخاب کنید که هم Risk بالایی دارند و هم Remediation آن‌ها قابل کنترل است.

۱. مدیریت SNMP و Communityهای ناامن

وجود Communityهای پیش‌فرض یا تنظیمات ضعیف SNMP یکی از مواردی است که می‌تواند در Baseline سازمان قرار بگیرد. Rule باید بر اساس Vendor و نسخه طراحی شود، نه اینکه یک Command را روی همه Deviceها تعمیم دهیم.

۲. غیرفعال‌سازی Interfaceهای بلااستفاده

برای Switchها یک کنترل مناسب است، به‌خصوص زمانی که Port Management و Physical Security بخشی از استاندارد داخلی سازمان باشند.

۳. کنترل Protocolها و Serviceهای غیرضروری

اگر سازمان تصمیم گرفته یک Protocol قدیمی یا Service مشخص روی تجهیزات Production مجاز نباشد، Compliance Policy می‌تواند Presence آن را بررسی کند.

۴. کنترل Logging و Syslog

یکی از ارزشمندترین Baselineها اطمینان از ارسال Log به مقصدهای مورد انتظار است. در این حالت Compliance مستقیماً به Visibility امنیتی و Incident Investigation کمک می‌کند.

۵. Baselineهای اختصاصی شعب و Data Center

همه Deviceها نباید Policy یکسان داشته باشند. Router شعبه، Core Switch و Firewall مرزی Risk Profile متفاوتی دارند. Scope دقیق Rule از تعداد False Positiveها کم می‌کند.

چرا Auto-Remediation را نباید از روز اول روشن کرد؟

قابلیت Remediate Automatically جذاب است، اما فعال کردن آن روی همه Ruleها معمولاً خطرناک است. یک Configuration که از دید Benchmark نامطلوب است، ممکن است در یک سناریوی خاص دلیل عملیاتی داشته باشد.

برای مثال، یک Interface ممکن است عمداً برای Failover خاصی Up مانده باشد. اگر Rule بدون Context آن را Shutdown کند، Compliance از کنترل امنیتی به Incident Generator تبدیل می‌شود.

مدل امن‌تر این است:

1. ابتدا Rule فقط Detection انجام دهد.
2. چند چرخه گزارش و False Positive بررسی شود.
3. Scope Deviceها محدود شود.
4. Remediation Procedure مستند شود.
5. Configlet در محیط Lab یا Pilot تست شود.
6. Change Approval تعریف شود.
7. بعد از بلوغ Rule، فقط موارد کم‌ریسک Auto-Remediate شوند.

در واقع بهترین Auto-Remediation آن چیزی نیست که سریع‌تر اجرا می‌شود؛ چیزی است که قابل پیش‌بینی، قابل Rollback و قابل Audit باشد.

Configlet چه نقشی در Remediation دارد؟

Configlet در NCM یک Template قابل استفاده مجدد برای اجرای Commandهای شبکه است. به‌جای اینکه کارشناس هر بار Commandها را دستی وارد کند، می‌توان یک Template استاندارد ساخت و Variableهای لازم را هنگام اجرا دریافت کرد.

در ComplianceIQ، Configlet می‌تواند به Violation متصل شود و مقادیر Dynamic Rule Variableها را هم در Remediation استفاده کند. این قابلیت برای اصلاح تکرارشونده بسیار ارزشمند است، اما باید با کنترل Permission و Change Review همراه باشد.

Backup قبل از Remediation باید اجباری باشد

اگر قرار است Compliance به Configuration Change منجر شود، Backup بخشی از Design است نه یک گزینه جانبی.

Network Configuration Manager سه مسیر اصلی برای Backup دارد: Scheduled Backup، Backup ناشی از Real-time Change Detection و Backup دستی یا Bulk. در سناریوی Remediation بهتر است حداقل یک Version قابل اعتماد از Running/Startup Configuration قبل از تغییر وجود داشته باشد.

این کار دو مزیت دارد:

• اگر Change مشکل ایجاد کرد، Diff دقیق قبل/بعد داریم.
• Rollback به Known-Good Configuration سریع‌تر انجام می‌شود.

در محیط‌های حساس، می‌توانید قبل از Changeهای مهم یک Backup دستی یا Scheduled نزدیک به Window اجرا کنید تا Snapshot معتبرتری داشته باشید.

Real-time Change Detection؛ حلقه‌ای که Compliance را کامل می‌کند

Compliance فقط می‌گوید Configuration در لحظه بررسی با Policy هم‌خوان است یا نه. اما بعد از آن چه؟

NCM می‌تواند با استفاده از Syslog تغییر Configuration را در لحظه تشخیص دهد. طبق مستندات ManageEngine، این مکانیزم امکان ثبت Change، گرفتن Backup فوری، Notification و در بعضی سناریوها Rollback را فراهم می‌کند.

برای تیم NOC یا Network Operations این یعنی:

1. Config قبل از Change موجود است.
2. Change در لحظه شناسایی می‌شود.
3. Version جدید ذخیره می‌شود.
4. Diff قابل مشاهده است.
5. Compliance دوباره قابل ارزیابی است.
6. در صورت مشکل، Rollback سریع‌تر می‌شود.

برای آشنایی با بخش مانیتورینگ و تحلیل رخداد شبکه، مقاله Root Cause Analysis در OpManager هم می‌تواند مکمل این معماری باشد.

Compliance Check را چه زمانی اجرا کنیم؟

سه مدل رایج وجود دارد:

پس از Backup

برای بسیاری از Ruleها منطقی است، چون Configuration تازه دریافت شده و می‌توان همان Version را بررسی کرد. ManageEngine در Buildهای جدیدتر حتی Compliance Check هنگام Backup را به حالتی بهینه کرده که در صورت تغییر Configuration اجرا شود.

Schedule دوره‌ای

برای Policyهای Audit و Governance می‌توانید بررسی را روزانه، هفتگی یا ماهانه برنامه‌ریزی کنید. Frequency باید با Criticality Device هماهنگ باشد.

Ad-hoc قبل یا بعد از Change

قبل از Change بزرگ برای Baseline و بعد از Change برای Verification بسیار مفید است.

CIS را Copy-Paste نکنید؛ آن را به Context سازمان وصل کنید

یکی از اشتباهات رایج این است که Benchmark را بدون بررسی Context وارد Production کنیم. CIS و سایر Baselineها نقطه شروع بسیار خوبی هستند، اما Implementation نهایی باید با Vendor، Version، Topology و Business Requirement سازمان هماهنگ شود.

مثلاً ممکن است یک Recommendation روی یک مدل Device یا Firmware رفتار متفاوتی داشته باشد. بنابراین Policy آماده باید قبل از Rollout روی Scope کوچک تست شود.

ComplianceIQ و Change Management باید کنار هم باشند

هر Remediation که Configuration Production را تغییر می‌دهد، از نظر عملیاتی یک Change است؛ حتی اگر Tool آن را خودکار اجرا کند.

پس برای Ruleهای مهم بهتر است این اطلاعات مشخص باشند:

• Owner Rule کیست؟
• چه کسی Scope را تأیید می‌کند؟
• چه کسی Configlet را Approve می‌کند؟
• Rollback Plan چیست؟
• Maintenance Window لازم است یا نه؟
• Evidence بعد از اجرا کجا نگهداری می‌شود؟

در نسخه‌های ۲۰۲۶ NCM حتی امکان ثبت Change Request Detail در Compliance Remediation توسعه داده شده است؛ این جهت‌گیری دقیقاً نشان می‌دهد که Compliance و Change Governance باید از هم جدا نباشند.

چه KPIهایی برای Compliance شبکه مفیدند؟

اگر فقط Compliance Rate را اندازه بگیرید، ممکن است تیم برای بالا بردن عدد، Exception زیاد تعریف کند. KPIها باید همزمان کیفیت Policy و کیفیت Remediation را نشان دهند.

معماری پیشنهادی برای Rollout در سازمان

یک مسیر کم‌ریسک می‌تواند این باشد:

1. Inventory: Deviceهای هدف و Vendor/OS Version را مشخص کنید.
2. Baseline: چند کنترل محدود و مهم انتخاب کنید.
3. Detection Only: Ruleها را بدون Remediation اجرا کنید.
4. False Positive Review: Exceptionها و Scopeها را اصلاح کنید.
5. Backup Discipline: Backup و Versioning را تثبیت کنید.
6. Manual Remediation: Configletها با Approval اجرا شوند.
7. Pilot Auto-Remediation: فقط Ruleهای کم‌ریسک خودکار شوند.
8. Scale: بعد از پایدار شدن، Policyهای بیشتری اضافه شوند.

Network Configuration Manager در معماری ITOM کجا قرار می‌گیرد؟

OpManager وضعیت Availability و Performance شبکه را می‌بیند؛ Network Configuration Manager روی Configuration، Change و Compliance تمرکز می‌کند. این دو دید مکمل هستند.

ممکن است Monitoring بگوید Interface Down شده است، اما NCM نشان دهد چند دقیقه قبل چه Configuration Changeای رخ داده، چه کسی آن را انجام داده و Version قبلی چه بوده است.

اگر سازمان از OpManager Plus استفاده می‌کند، بررسی جایگاه NCM در همان معماری ارزش دارد؛ چون Change Context می‌تواند زمان Troubleshooting را کوتاه کند و Audit تغییرات را دقیق‌تر کند.

مدل لایسنس NCM را قبل از Rollout بدانید

Network Configuration Manager مدل لایسنس Device-based دارد. طبق صفحه فعلی Editionهای ManageEngine، Free Edition دو Device را مدیریت می‌کند، Professional برای محیط‌های بزرگ Single-site طراحی شده و Enterprise برای Distributed/Multi-site با Central و Probe مناسب‌تر است.

در انتخاب Edition فقط تعداد Device را نبینید. اگر چند Data Center یا شعبه مستقل دارید، معماری Central/Probe می‌تواند عامل اصلی انتخاب Enterprise باشد.

برای برآورد واقعی تعداد Device، Edition، Subscription یا Perpetual و هزینه تمدید، می‌توانید از صفحه استعلام لایسنس محصولات ManageEngine مدانت استفاده کنید. بهتر است قبل از Quote، تعداد Switch/Router/Firewall، تعداد Site و نیاز به Multi-site Management مشخص باشد.

Checklist قبل از فعال کردن Auto-Remediation

• Rule روی Vendor و Version درست تست شده باشد.
• Scope Deviceها دقیق باشد.
• حداقل یک Backup معتبر قبل از تغییر وجود داشته باشد.
• Configlet در Lab یا Pilot اجرا شده باشد.
• Rollback Plan مشخص باشد.
• Permission اجرای Configlet محدود باشد.
• Exceptionهای Business مستند باشند.
• Maintenance Window در صورت نیاز تعریف شده باشد.
• Verification بعد از Change خودکار یا دستی اجرا شود.
• Audit Trail و گزارش Compliance نگهداری شود.

نکات کلیدی

ComplianceIQ ارزشش در ساخت Rule قابل‌اجراست، نه صرفاً تولید Report.

Auto-Remediation بدون Backup، Scope و Approval می‌تواند Risk ایجاد کند.

Compliance باید با Real-time Change Detection، Versioning و Rollback ترکیب شود.

Policyهای CIS نقطه شروع‌اند؛ Implementation نهایی باید با Context شبکه سازمان هماهنگ شود.

برای محیط Multi-site، معماری Edition و Probe/Central را قبل از خرید بررسی کنید.

سخن پایانی

پیکربندی شبکه یکی از آن حوزه‌هایی است که انحراف کوچک امروز می‌تواند Incident بزرگ فردا شود. مسئله فقط داشتن Backup یا داشتن یک فایل PDF از Benchmark نیست؛ باید بتوانیم وضعیت واقعی Deviceها را با Baseline مقایسه کنیم، Violation را با Context ببینیم و اصلاح را بدون ایجاد اختلال اجرا کنیم.

ComplianceIQ در Network Configuration Manager این مسیر را از Detection تا Remediation کوتاه می‌کند، اما بهترین نتیجه زمانی به دست می‌آید که Automation جای Change Governance را نگیرد. Rule خوب باید دقیق باشد، Configlet باید تست شده باشد و Rollback باید قبل از اجرای Change آماده باشد.

اگر برای طراحی Baseline شبکه، انتخاب Edition، استقرار Network Configuration Manager یا یکپارچه‌سازی آن با OpManager به بررسی فنی نیاز دارید، مدانت می‌تواند معماری، لایسنس، پیاده‌سازی و پشتیبانی را متناسب با تعداد Device و ساختار Siteهای سازمان ارزیابی کند. برای سرویس‌های در حال بهره‌برداری نیز برنامه‌های پشتیبانی مدانت در دسترس است.

منابع

• ManageEngine Network Configuration Manager - ComplianceIQ
• ManageEngine NCM Release Notes
• Configuration Backup in Network Configuration Manager
• Real-time Configuration Change Detection
• Network Configuration Manager Editions