فرض کنید EventLog Analyzer را در دیتاسنتر اصلی نصب کرده‌اید و قرار است لاگ ۳۰۰ سرور ویندوزی، چند شعبه، تعدادی سیستم در DMZ و چند سرور پشت لینک WAN را جمع‌آوری کنید. در تست اولیه همه‌چیز خوب پیش می‌رود، اما وقتی Scope واقعی وارد می‌شود، تیم امنیت با چند سؤال جدی روبه‌رو می‌شود: آیا برای همه سرورها Agent نصب کنیم؟ آیا WMI و DCOM را از شبکه‌های مختلف باز کنیم؟ اگر لینک شعبه قطع شد، لاگ‌ها از دست می‌روند؟ اگر حجم Eventها بالا رفت، بار جمع‌آوری روی سرور مرکزی چه می‌شود؟

پاسخ درست معمولاً «همه Agentless» یا «همه Agent-based» نیست. معماری مناسب باید بر اساس Zone شبکه، کیفیت ارتباط، سیاست Firewall، سطح حساسیت، ظرفیت EPS و مدل عملیاتی سازمان انتخاب شود.

ManageEngine EventLog Analyzer هر دو روش Agentless و Agent-based را برای جمع‌آوری لاگ‌های ویندوز پشتیبانی می‌کند. در مستندات فعلی ManageEngine، Agentless روش پیش‌فرض است؛ در مقابل Agent برای محیط‌هایی مثل WAN، شبکه‌های محدودشده، DMZ یا جاهایی که باز کردن ارتباط‌های WMI مناسب نیست، کاربرد بیشتری دارد. هدف این نوشتار این است که این انتخاب را از یک تصمیم سلیقه‌ای به یک طراحی معماری قابل دفاع تبدیل کند.

برای آشنایی کلی با محصول، پیش‌نیازها و ساختار آن می‌توانید ابتدا صفحه نرم‌افزار EventLog Analyzer در مدانت را ببینید.

Agentless در EventLog Analyzer دقیقاً یعنی چه؟

در حالت Agentless، روی هر Windows Server یا Endpoint نرم‌افزار جداگانه‌ای برای جمع‌آوری لاگ نصب نمی‌شود. خود EventLog Analyzer از سمت سرور مرکزی به سیستم‌های ویندوزی متصل می‌شود و Event Logها را دریافت می‌کند.

در معماری فعلی ManageEngine، این روش برای Windows Log Collection به ارتباط‌های Remote Management متکی است و در مستندات محصول به WMI، DCOM و RPC اشاره شده است. بنابراین Agentless از نظر نصب ساده‌تر است، اما به این معنی نیست که هیچ پیش‌نیاز شبکه‌ای ندارد.

برای موفق بودن این معماری باید حداقل این موارد درست طراحی شده باشند:

• Service Account مناسب برای دسترسی به Event Logها وجود داشته باشد.
• مسیر شبکه بین EventLog Analyzer و Sourceها برقرار باشد.
• Firewall اجازه ارتباط‌های لازم برای WMI/DCOM/RPC را بدهد.
• Name Resolution و DNS قابل اتکا باشد.
• سرور مرکزی ظرفیت Poll و دریافت Event از Sourceهای تعریف‌شده را داشته باشد.

مزیت اصلی این روش، کاهش هزینه عملیاتی Agent Management است. شما برای Patch، Upgrade و Health Check صدها Agent درگیر نمی‌شوید و Onboarding اولیه بسیاری از سرورها سریع‌تر انجام می‌شود.

Agent-based چه مسئله‌ای را حل می‌کند؟

Agent-based زمانی اهمیت پیدا می‌کند که معماری شبکه اجازه اتصال مستقیم و پایدار از EventLog Analyzer به Source را نمی‌دهد یا سیاست امنیتی سازمان نمی‌خواهد WMI/DCOM بین Zoneها باز باشد.

ManageEngine استفاده از Agent را برای سناریوهایی مانند ارتباط از طریق WAN، عبور از Firewall، شبکه‌های Restricted و محیط‌هایی با ارتباط ناپایدار توصیه می‌کند. در این مدل، Agent در سمت Source یا نزدیک Source قرار می‌گیرد و لاگ‌ها را جمع‌آوری و به EventLog Analyzer منتقل می‌کند.

این تفاوت از نظر معماری مهم است. در Agentless، سرور مرکزی باید به Source برسد. در Agent-based، Source یا Collector نزدیک آن، جریان Log را به سمت سامانه مرکزی هدایت می‌کند. همین موضوع می‌تواند طراحی Ruleهای Firewall، Availability و مدیریت لینک‌های بین شعب را ساده‌تر کند.

مقایسه Agentless و Agent-based در یک نگاه

سناریوی اول: یک دیتاسنتر با شبکه LAN پایدار

اگر تمام Windows Serverها در یک شبکه سازمانی قابل مدیریت هستند، Latency پایین است و تیم Security با Ruleهای WMI/DCOM مشکل ندارد، Agentless معمولاً نقطه شروع خوبی است.

فرض کنید ۱۰۰ سرور در همان دیتاسنتر EventLog Analyzer قرار دارند. همه Member یک Domain هستند، DNS درست کار می‌کند و Firewall داخلی بین Zone مدیریت و Serverها اجازه دسترسی موردنیاز را می‌دهد. در چنین محیطی نصب ۱۰۰ Agent ممکن است هزینه عملیاتی اضافه‌ای ایجاد کند بدون اینکه مزیت قابل توجهی نسبت به Collection مستقیم داشته باشد.

اما حتی در همین سناریو، بهتر است Agentless را «بدون محدودیت» تصور نکنید. اگر تعداد Log Source و Event Volume بالا برود، ظرفیت CPU، RAM، IOPS و Search Storage سرور مرکزی تعیین‌کننده می‌شود.

سناریوی دوم: شعب متعدد روی WAN

تصور کنید سازمان ۲۰ شعبه دارد و در هر شعبه ۱۵ Windows Server و چند سرویس حساس قرار گرفته‌اند. ارتباط شعب با دیتاسنتر مرکزی از MPLS، SD-WAN یا VPN برقرار است و بعضی لینک‌ها در ساعات شلوغی Latency یا Packet Loss بیشتری دارند.

در اینجا Agentless می‌تواند از نظر Firewall و Sessionهای Remote Management پیچیده شود. علاوه بر آن، اگر Collection کاملاً وابسته به ارتباط لحظه‌ای سرور مرکزی با Source باشد، اختلال WAN مستقیماً روی فرآیند جمع‌آوری اثر می‌گذارد.

Agent-based در چنین سناریویی معمولاً قابل دفاع‌تر است؛ به‌ویژه وقتی می‌خواهید ترافیک Collection را کنترل کنید، Zoneهای شبکه را مستقل نگه دارید یا مدیریت لاگ شعبه را از ارتباط‌های متعدد Remote RPC جدا کنید.

برای سازمان‌های بسیار گسترده، موضوع فقط Agent نیست. EventLog Analyzer نسخه Distributed نیز دارد و ManageEngine آن را برای سازمان‌های چندمکانه و MSSPها معرفی می‌کند. بنابراین اگر معماری شما ده‌ها Location و حجم زیاد Log دارد، بهتر است مسئله را در سطح Distributed Architecture بررسی کنید، نه اینکه صرفاً تعداد Agentها را زیاد کنید.

سناریوی سوم: سرورهای DMZ

DMZ یکی از جاهایی است که انتخاب Collection Method اهمیت امنیتی بیشتری پیدا می‌کند.

در طراحی شبکه خوب، ارتباط از شبکه داخلی به DMZ و برعکس بر اساس Least Privilege محدود می‌شود. اگر Agentless انتخاب شود، باید دقیقاً مشخص باشد EventLog Analyzer از چه Source IP، روی چه Port و با چه Credentialی به Windows Serverهای DMZ متصل می‌شود.

اگر برای فعال کردن Agentless مجبور شوید Range وسیعی از پورت‌ها و Remote Management را بین Zoneها باز کنید، ممکن است هزینه امنیتی این تصمیم از راحتی Agentless بیشتر شود. در چنین شرایطی Agent-based می‌تواند معماری تمیزتری بسازد؛ چون Rule ارتباطی را می‌توان به مسیر مشخص Forwarding محدود کرد.

البته نصب Agent به خودی خود امنیت ایجاد نمی‌کند. Agent باید Patch شود، ارتباط آن امن باشد، Service Account آن کنترل شود و مسیر ارسال Log نیز تحت Monitoring قرار بگیرد. تصمیم درست باید بر اساس Threat Model واقعی سازمان گرفته شود.

Agentless و مسئله Credential

یکی از موضوعاتی که در طراحی Collection گاهی دست‌کم گرفته می‌شود، Credential است. Agentless معمولاً نیاز دارد EventLog Analyzer با سطح دسترسی لازم به Remote Windows Host متصل شود.

اگر برای سادگی از یک Account بسیار Privileged روی صدها سرور استفاده شود، عملاً یک Credential با Blast Radius بزرگ ساخته‌ایم. بهتر است Service Account مخصوص Log Collection تعریف شود و Permission آن فقط در حد نیاز باشد.

چند اصل عملی:

• برای Log Collection از Domain Admin به‌عنوان راه‌حل دائمی استفاده نکنید.
• Service Account را از حساب‌های روزمره Administrator جدا کنید.
• Password Rotation و Audit روی Account فعال باشد.
• Logon آن Account خارج از سرورهای مجاز محدود شود.
• استفاده از Credential در EventLog Analyzer و Windows Security Logs قابل ردیابی باشد.

اگر سیاست Identity Security سازمان اجازه Remote Administrative Credential بین Zoneها را نمی‌دهد، این خودش می‌تواند دلیل مهمی برای حرکت برخی Sourceها به مدل Agent-based باشد.

Agent-based و هزینه‌ای که نباید فراموش شود

Agent مزایای فنی دارد، اما رایگان از نظر عملیات نیست. هر Agent یک Software Component جدید است که Lifecycle خودش را دارد.

تیم زیرساخت باید بتواند پاسخ دهد:

• Agentها چطور نصب می‌شوند؟
• Upgrade آن‌ها چگونه انجام می‌شود؟
• اگر Agent Stop شد چه Alertی تولید می‌شود؟
• اگر Versionها با Server مرکزی ناسازگار شوند چه می‌شود؟
• چه کسی مسئول Agent Health است؛ SOC یا Infrastructure؟

به همین دلیل نصب Agent روی همه Sourceها فقط به این دلیل که «مطمئن‌تر به نظر می‌رسد» لزوماً تصمیم خوبی نیست. Agent باید جایی استفاده شود که یک Problem واقعی را حل کند.

Hybrid Collection؛ معماری‌ای که در عمل منطقی‌تر است

در بسیاری از سازمان‌ها بهترین طراحی ترکیبی است.

مثلاً:

• سرورهای دیتاسنتر اصلی: Agentless
• سرورهای شعب: Agent-based
• سیستم‌های DMZ: Agent-based
• Network Deviceها: Syslog
• Firewall و IDS/IPS: Syslog یا فرمت پشتیبانی‌شده
• Application Logها: روش Native همان Source یا Import/Forwarding مناسب

این مدل اجازه می‌دهد به‌جای تحمیل یک استاندارد واحد به همه Sourceها، Collection بر اساس Zone و نوع Log Source طراحی شود.

CISA نیز در راهنمای Logging تأکید می‌کند که سازمان باید Logging را روی Server، Firewall، Endpoint و Cloud Service فعال و Logها را در یک سامانه مرکزی تجمیع کند. اصل مهم «Centralization» است؛ روش رسیدن Log به مرکز می‌تواند بر اساس معماری هر Zone متفاوت باشد.

EPS فقط یک عدد فنی نیست

در پروژه SIEM و Log Management، خیلی وقت‌ها تعداد Device ملاک خرید یا Sizing قرار می‌گیرد، در حالی که دو سازمان با ۵۰۰ Device می‌توانند حجم Log کاملاً متفاوتی داشته باشند.

یک Domain Controller پرکار، یک Firewall اینترنتی و یک File Server با Audit کامل ممکن است چند برابر ده‌ها Server کم‌فعال Event تولید کنند. بنابراین Collection Architecture باید با Event Volume و EPS هم سنجیده شود.

در مستندات فعلی System Requirements، ManageEngine برای یک Single Node از EventLog Analyzer سقف معماری تا حدود ۲۵۰ گیگابایت Log Flow در روز یا حدود ۲ ترابایت Search Data را ذکر می‌کند؛ برای حجم بالاتر، Scalability Architecture پیشنهاد شده است. همچنین برای سرور، حداقل ۱۲ Core، ۳۲ گیگابایت RAM و ۱.۲ ترابایت SSD ذکر شده و مقادیر پیشنهادی بالاتر هستند.

این اعداد را نباید جای Sizing واقعی گذاشت. Retention، نوع Source، Average Event Size، Peak EPS، Search Load و تعداد Concurrent Userها روی نیاز نهایی اثر دارند.

چطور Collection را قبل از Production تست کنیم؟

بهترین روش این نیست که ۵۰۰ Source را یک‌باره Add کنید و بعد ببینید چه اتفاقی می‌افتد.

یک Pilot قابل اندازه‌گیری بسازید.

مرحله ۱: Sourceها را به Class تقسیم کنید

• Domain Controller
• Application Server
• Database Server
• File Server
• Branch Server
• DMZ Server
• Network/Security Device

مرحله ۲: از هر Class چند نمونه انتخاب کنید

مثلاً ۲۰ Source را وارد Pilot کنید؛ نه فقط Serverهای کم‌فعال، بلکه Sourceهای پرترافیک هم داخل نمونه باشند.

مرحله ۳: پنج شاخص را اندازه بگیرید

مرحله ۴: Failure Test انجام دهید

لینک WAN را شبیه‌سازی کنید، Firewall Rule را موقت ببندید، Agent را Stop کنید و ببینید تیم از کجا متوجه Failure می‌شود. معماری Logging که فقط در حالت عادی تست شده باشد، برای Incident واقعی آماده نیست.

Monitoring خودِ Log Pipeline را فراموش نکنید

یکی از خطرناک‌ترین وضعیت‌ها این است که SOC تصور کند «هیچ رخداد مشکوکی وجود ندارد»، در حالی که واقعیت این است که Log Source از دو ساعت قبل دیگر Event نفرستاده است.

بنابراین Health Monitoring باید بخشی از طراحی باشد.

برای Sourceهای حساس حداقل این موارد را بررسی کنید:

• آخرین زمان دریافت Log
• کاهش ناگهانی EPS
• افزایش غیرعادی EPS
• قطع Agent یا Collector
• Authentication Failure هنگام Collection
• Storage Pressure در EventLog Analyzer
• Queue یا Backlog غیرعادی

هدف این است که «از کار افتادن Logging» خودش یک Event امنیتی یا عملیاتی قابل مشاهده باشد.

چه Eventهایی را جمع کنیم؟

انتخاب Agentless یا Agent-based فقط نحوه انتقال را مشخص می‌کند؛ سؤال مهم‌تر این است که چه چیزی اصلاً باید Log شود.

CISA توصیه می‌کند Logging برای User Activity، Admin Actions، Application Login، Network Activity و System Eventها فعال شود و سازمان Logها را برای Detection و Incident Response به‌صورت مرکزی نگهداری کند.

در Windows Environment معمولاً این دسته‌ها اهمیت زیادی دارند:

• Authentication Success/Failure
• Account Lockout
• User/Group Management
• Privilege Assignment و Privileged Logon
• Process Creation در Scopeهای حساس
• Service Installation و تغییر Service
• Policy Change
• Object Access در File Serverهای حساس
• PowerShell و Script Activity در صورت نیاز امنیتی

اما فعال کردن حداکثری همه Audit Categoryها بدون Capacity Planning می‌تواند Event Volume را شدیداً افزایش دهد. Logging Policy باید هم‌زمان توسط Security و Infrastructure طراحی شود.

EventLog Analyzer یا Log360؟

اگر نیاز اصلی سازمان Log Collection، Search، Alerting، Compliance و Forensics باشد، EventLog Analyzer می‌تواند نقطه ورود مناسبی باشد. اما اگر Scope به UEBA، تحلیل رفتاری، SIEM گسترده‌تر و Integrationهای امنیتی بیشتر برسد، بررسی Log360 منطقی است.

مدانت قبلاً در مطلب مقایسه EventLog Analyzer و Log360 این دو محصول را از نظر Scope بررسی کرده است. همچنین برای آشنایی با یک Use Case تشخیص تهدید می‌توانید مقاله MITRE ATT&CK در Log360 را بخوانید.

نکته مهم این است که Collection Architecture خوب در هر دو حالت ارزش دارد. SIEM پیشرفته روی Log ناقص یا Pipeline ناپایدار نمی‌تواند Detection قابل اعتمادی بسازد.

یک ماتریس تصمیم برای انتخاب روش Collection

این جدول نقطه شروع است، نه قانون مطلق. در Pilot ممکن است نتیجه متفاوتی برای محیط خاص شما به دست بیاید.

اشتباه‌های رایج در طراحی Log Collection

باز کردن بیش از حد Firewall برای Agentless

اگر برای راحتی Collection، Ruleهای گسترده Any-to-Any بین شبکه مدیریت و Serverها ایجاد شود، معماری Logging خودش می‌تواند سطح حمله را افزایش دهد.

نصب Agent روی همه‌چیز بدون Ownership

وقتی صدها Agent نصب می‌شوند ولی مسئول Upgrade و Health آن‌ها مشخص نیست، چند ماه بعد Version Drift و Agent Failure تبدیل به مسئله عملیاتی می‌شود.

نادیده گرفتن Peak EPS

Average EPS معمولاً گمراه‌کننده است. Incident، Password Spray، Vulnerability Scan یا Batch Process می‌تواند Event Volume را ناگهان چند برابر کند.

Retention بدون محاسبه Storage

نگهداری ۹۰ روز Searchable Data با نگهداری ۹۰ روز Archive یکسان نیست. قبل از خرید Storage باید Hot/Search Retention و Archive Retention جداگانه تعریف شوند.

نداشتن Test برای قطع ارتباط

اگر هیچ‌کس نمی‌داند بعد از قطع WAN یا Stop شدن Agent چه رخ می‌دهد، Logging Pipeline هنوز Production-ready نیست.

Checklist پیشنهادی قبل از Rollout

• Zoneهای شبکه و Trust Boundaryها مشخص شده باشند.
• Sourceهای LAN، WAN و DMZ جدا دسته‌بندی شوند.
• برای Agentless پورت‌ها و Service Accountها مستند شوند.
• برای Agent-based مالک Lifecycle و Health Agent مشخص باشد.
• Peak EPS و Daily Log Volume اندازه‌گیری شود.
• Retention Search و Archive جداگانه محاسبه شوند.
• Collection Delay برای Sourceهای حساس Baseline شود.
• Failure Scenario برای WAN، Firewall و Agent تست شود.
• Alert برای Source Silence تعریف شود.
• Security Team مشخص کند چه Audit Eventهایی واقعاً لازم‌اند.
• در Scopeهای بزرگ، Distributed یا Scalable Architecture بررسی شود.
• قبل از Production حداقل یک Pilot نماینده از هر نوع Source اجرا شود.

نکات کلیدی

• Agentless روش پیش‌فرض EventLog Analyzer برای Windows Collection است و برای LANهای پایدار معمولاً Deploy ساده‌تری دارد.
• Agent-based برای WAN، DMZ، شبکه‌های Restricted و محیط‌هایی که WMI/DCOM مناسب نیستند، انتخاب جدی‌تری است.
• بهترین معماری در بسیاری از سازمان‌ها Hybrid است؛ لازم نیست همه Sourceها یک روش داشته باشند.
• تعداد Device به‌تنهایی برای Sizing کافی نیست؛ EPS، Daily Log Flow، Retention و Search Load باید اندازه‌گیری شوند.
• Health خود Pipeline باید Monitoring شود؛ قطع Logging نباید بی‌صدا بماند.
• اگر حجم و تعداد Location بالا است، معماری Distributed/Scalable را بررسی کنید و مسئله را فقط با افزودن Agent حل نکنید.

سخن پایانی

انتخاب بین Agentless و Agent-based در EventLog Analyzer یک تنظیم ساده در Wizard نیست؛ بخشی از معماری امنیت و عملیات سازمان است.

اگر Sourceها در یک LAN پایدار و قابل مدیریت هستند، Agentless می‌تواند با کمترین سربار عملیاتی شروع خوبی باشد. اگر پای WAN، DMZ، Firewallهای محدود، شبکه‌های ناپایدار یا Policyهای سخت‌گیرانه وسط است، Agent-based معمولاً انعطاف بیشتری می‌دهد. در محیط‌های واقعی، ترکیب این دو روش اغلب منطقی‌تر از انتخاب یک مدل واحد برای همه Sourceهاست.

پیش از Rollout گسترده، Collection را روی نمونه‌ای واقعی از Sourceها Pilot کنید، Peak EPS و Delay را اندازه بگیرید، Failure Scenario را تست کنید و بعد معماری نهایی را تثبیت کنید. کیفیت Detection در SOC از جایی شروع می‌شود که مطمئن باشیم Log درست، کامل و به‌موقع به سامانه مرکزی می‌رسد.

اگر برای انتخاب معماری، Sizing، لایسنس یا پیاده‌سازی EventLog Analyzer نیاز به بررسی فنی دارید، مدانت خدمات مشاوره، استقرار، آموزش و پشتیبانی محصولات ManageEngine را ارائه می‌کند. برای برآورد لایسنس می‌توانید از استعلام قیمت محصولات ManageEngine استفاده کنید و برای نگهداری و پشتیبانی پس از استقرار، برنامه‌های پشتیبانی مدانت را ببینید.

منابع

• ManageEngine – Windows Log Collection Overview
• ManageEngine – Agent-based Log Collection
• ManageEngine – Agentless Log Collection
• ManageEngine – EventLog Analyzer System Requirements
• CISA – Use Logging on Business Systems