راهنمای اجرایی نصب و تأیید Agent در Log360 Cloud؛ Download، Pending Registration، Approval، Sync، Access Key، Rollout و Troubleshooting.

شرکت مدانت

وقتی قرار است لاگ یک سرور یا Endpoint خارج از مسیر ساده جمع‌آوری Agentless به Log360 Cloud برسد، نصب Agent فقط «اجرای یک فایل EXE» نیست. ادمین باید بداند Agent از کجا دانلود می‌شود، چه زمانی هنوز Pending است، چه زمانی واقعاً Sync شده، چه پورت‌هایی برای ارتباط لازم‌اند و اگر Access Key عوض شد چه چیزی باید به‌روزرسانی شود. این راهنما بر اساس مستند رسمی ManageEngine برای Log360 Cloud نوشته شده و مسیر اجرایی را از نصب تا Verify و Troubleshooting پوشش می‌دهد.

سناریوی واقعی

فرض کنید سازمان چند Windows Server در دیتاسنتر و چند Endpoint در شعب دارد و می‌خواهد لاگ‌ها را به Log360 Cloud بفرستد. بخشی از سرورها پشت Firewall هستند و دسترسی Inbound از Cloud به آن‌ها مجاز نیست. در چنین معماری‌ای Agent روی سیستم نصب می‌شود، داده را جمع می‌کند و ارتباط را به سمت سرویس Cloud برقرار می‌کند. در این سناریو مهم‌ترین کنترل این است که نصب Agent با «دیده شدن در کنسول» اشتباه گرفته نشود؛ Agent تا زمانی که Approve و Sync نشود، آماده جمع‌آوری عملیاتی نیست.

پیش‌نیازهای عملی

مورد چرا لازم است؟
دسترسی Admin روی سیستم مقصد برای نصب Agent و اجرای ابزارهای مدیریتی آن
دسترسی به Log360 Cloud برای Download، Approve و مشاهده Sync Status
خروجی HTTPS/HTTP طبق مستند رسمی، ارتباط Agent به پورت‌های 443 و 80 نیاز دارد
Access Key معتبر Agent با کلید فعلی محیط Cloud ثبت و همگام می‌شود
فضای موقت Agent داده Sync را پیش از ارسال در محل موقت نگهداری می‌کند

قبل از Rollout انبوه، روی یک سیستم آزمایشی مسیر خروجی، Proxy و Policy فایروال را بررسی کنید. اگر محیط شما فقط HTTPS را مجاز می‌کند، این سیاست باید با نیازهای واقعی نسخه و معماری Log360 شما تطبیق داده شود؛ پورت یا مسیر اضافه‌ای را صرفاً از روی حدس باز نکنید.

مرحله ۱: Agent را از خود کنسول دانلود کنید

در Log360 Cloud وارد Settings شوید و مسیر Admin > Management > Manage Agents را باز کنید. روی Download Agent کلیک کنید. فایل Log360CloudAgent.exe برای همان محیط دانلود می‌شود.

این نکته مهم است: اگر Access Key محیط بعداً Regenerate شده باشد، فایل Agent قدیمی ممکن است کلید قدیمی را در خود داشته باشد. برای Rollout جدید همیشه Installer تازه را از کنسول فعلی دانلود کنید.

مرحله ۲: Agent را روی سیستم مقصد نصب کنید

فایل Log360CloudAgent.exe را روی سیستم مقصد با دسترسی مناسب اجرا کنید و Wizard نصب را کامل کنید. پس از پایان نصب، Agent به‌صورت خودکار توسط Log360 Cloud شناسایی می‌شود؛ اما مستند رسمی صریحاً می‌گوید این شناسایی به معنی برقراری ارتباط کامل نیست.

در این مرحله انتظار صحیح این است که Endpoint در صف ثبت Agent دیده شود، نه اینکه فوراً همه Logها در Dashboard ظاهر شوند.

مرحله ۳: ثبت Agent را Approve کنید

به Settings > Admin > Manage Agents > Pending Agent Registrations بروید. Agent نصب‌شده را پیدا کنید و آن را Approve کنید. برای تعداد زیاد Agent می‌توانید از انتخاب گروهی یا Filter استفاده کنید.

تا قبل از Approve، Agent نصب شده است اما با Log360 Cloud ارتباط عملیاتی برقرار نمی‌کند. این مرحله از نظر امنیتی مهم است چون اجازه نمی‌دهد هر Agent نصب‌شده بدون تأیید ادمین وارد محیط شود.

مرحله ۴: وضعیت Sync را Verify کنید

بعد از Approve، وضعیت Agent را در Manage Agents بررسی کنید. هدف این است که Agent از Pending خارج شود و Sync موفق داشته باشد. اگر وضعیت Sync failed دیده شد، نصب را «موفق» اعلام نکنید. ابتدا Connectivity، Access Key و دسترسی خروجی را بررسی کنید.

چه چیزی را بعد از Sync تست کنیم؟

  • Agent در فهرست Manage Agents با وضعیت سالم دیده شود.
  • داده جدید از همان سیستم در بازه زمانی مورد انتظار وارد شود.
  • Timestamp لاگ با زمان واقعی سیستم و Time Zone سازمان سازگار باشد.
  • در صورت اعمال Filter یا Source Configuration، همان Source مورد انتظار داده تولید کند.

مرحله ۵: اگر Access Key تغییر کرد چه کنیم؟

ManageEngine برای این سناریو ابزار مشخصی ارائه کرده است. روی سیستم Agent به مسیر C:\Program Files(x86)\ManageEngine\Log360Cloud_Agent\bin بروید و UpdateAccessKey.exe را با دسترسی Administrator اجرا کنید. در Wizard، Access Key جدید را وارد و تأیید کنید.

همچنین اگر قصد نصب Agent جدید دارید، Installer قدیمی را دوباره استفاده نکنید؛ فایل تازه را از کنسول دانلود کنید تا کلید فعلی را داشته باشد.

مرحله ۶: Rollout انبوه را بعد از Pilot انجام دهید

مستند رسمی چند روش Deploy ارائه می‌کند: GPO، SCCM یا ابزار مشابه، Endpoint Central و نصب دستی. انتخاب روش باید بر اساس اندازه محیط و ابزار مدیریتی موجود باشد.

Deploy با Endpoint Central

در Endpoint Central وارد Software Deployment شوید، از بخش Packages یک Package ویندوزی بسازید و نوع مناسب EXE را انتخاب کنید. برای Silent Install، ManageEngine دستور زیر را مستند کرده است:

Log360Agent.exe SILENT_INSTALL /hide_progress /hide_splash

بعد از ساخت Package، از Software Deployment > Deployment > Install/Uninstall Software آن را روی Targetهای مشخص Deploy کنید و وضعیت را در View Configurations دنبال کنید.

Deploy با GPO

در روش GPO، فایل Script رسمی InstallLog360Agent.vbs و Installer باید در Share قابل دسترس قرار گیرند. سپس Script به Startup Computer Policy اضافه می‌شود. این روش برای Domainهایی مناسب است که Endpoint Central یا SCCM ندارند، ولی قبل از Rollout باید Permission روی Share و دسترسی سیستم‌ها به مسیر UNC تست شود.

مرحله ۷: Failure را از سه زاویه عیب‌یابی کنید

نشانه اولین بررسی اقدام بعدی
Agent در Pending ظاهر نمی‌شود نصب و Service محلی Installer و دسترسی Admin را بازبینی کنید
Agent Approve شده ولی Sync failed است خروجی شبکه و Access Key Firewall/Proxy و کلید را بررسی کنید
Agent Sync است ولی داده نمی‌آید Source/Collector Configuration نوع لاگ و تنظیم جمع‌آوری را بررسی کنید
بعد از Regenerate Key ارتباط قطع شد کلید Agent UpdateAccessKey.exe یا Installer جدید
Storage Cloud پر شده Storage Limit طبق مستند، Sync متوقف می‌شود و داده موقت محلی نگهداری می‌شود

نکات امنیتی و عملیاتی

Agent را فقط از کنسول رسمی همان Tenant دانلود کنید و Installer را مانند یک فایل مدیریتی حساس نگهداری کنید؛ چون به اطلاعات ثبت محیط وابسته است. دسترسی به Manage Agents و Approve کردن Agentها را نیز به Roleهای محدود واگذار کنید.

برای محیط‌های بزرگ، بهتر است ابتدا یک Pilot کوچک از سرورهای کم‌ریسک انتخاب شود، وضعیت Sync و حجم داده بررسی شود و سپس Rollout مرحله‌ای انجام شود. این کار هم خطای شبکه را زودتر آشکار می‌کند و هم اثر واقعی Log Volume بر ظرفیت Cloud را نشان می‌دهد.

ارتباط با طراحی SIEM

نصب Agent فقط بخش Transport است. اگر Log Sourceها، Retention، Use Case و Alert Ruleها از قبل طراحی نشده باشند، زیاد شدن Agentها لزوماً Visibility بهتر ایجاد نمی‌کند. برای دیدن کاربرد داده جمع‌آوری‌شده در تحلیل رفتار، مقاله تشخیص Insider Threat با Log360 UEBA و برای محاسبه Scope لایسنس، راهنمای لایسنس Log360 مکمل این آموزش هستند.

در پروژه‌هایی که قرار است صدها Agent بین شعب، دیتاسنتر و Cloud توزیع شوند، تصمیم درباره Access Gateway، مسیرهای خروجی، حجم لاگ و Retention باید قبل از Rollout نهایی شود. در این نقطه طراحی و ارزیابی معماری Log360 با مدانت می‌تواند از نصب پراکنده Agent بدون مدل جمع‌آوری جلوگیری کند.

چک‌لیست نهایی

  • Installer از Tenant فعلی دانلود شده است.
  • Agent با دسترسی Admin نصب شده است.
  • Agent در Pending Agent Registrations دیده شده است.
  • ثبت Agent Approve شده است.
  • وضعیت Sync سالم است.
  • پورت‌های خروجی موردنیاز بررسی شده‌اند.
  • یک Log واقعی از Source هدف دریافت شده است.
  • در صورت تغییر Access Key، Agent به کلید جدید به‌روزرسانی شده است.
  • قبل از Rollout انبوه Pilot انجام شده است.

سخن پایانی

Agent سالم در Log360 Cloud یعنی «نصب شده، تأیید شده، Sync شده و داده واقعی می‌فرستد». اگر این چهار مرحله جداگانه Verify شوند، بسیاری از خطاهای رایج Rollout قبل از گسترش به صدها سیستم پیدا می‌شوند و تیم SOC به‌جای حدس‌زدن علت شکاف لاگ، یک مسیر مشخص برای عیب‌یابی دارد.

منابع


دیدگاه شما

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