0

راهنمای عملی محاسبه لایسنس Log360؛ از تعداد Log Source، Domain Controller و File Server تا Endpoint، Cloud Account، Cloud/On-Premises و جلوگیری از Over-Licensing.

شرکت مدانت
شرکت مدانت
[ مجری تخصصی پیاده‌سازی چارچوب ITIL و تحول دیجیتال ]
لایسنس Log360؛ چطور Log Source، DC، Endpoint و Cloud Account را محاسبه کنیم؟

فرض کنید برای یک سازمان متوسط قرار است SIEM راه‌اندازی کنید. تیم امنیت می‌گوید ۴۰۰ کاربر داریم، تیم شبکه از ۷۰ تجهیز حرف می‌زند، زیرساخت می‌گوید ۳۰ سرور داریم و مدیر مالی فقط یک سؤال دارد: «بالاخره چند لایسنس Log360 لازم است؟»

اگر پاسخ را با تعداد کاربر، حجم روزانه لاگ یا EPS حدس بزنید، ممکن است از همان ابتدا Sizing اشتباه شود. مدل فعلی ManageEngine Log360 برای نسخه On-Premises بر چند شمارنده زیرساختی مستقل بنا شده است: Domain Controller، Log Source، File Server، Endpoint و Cloud Account. در نسخه Cloud نیز همین نگاه زیرساخت‌محور وجود دارد، اما Edition، Storage و بعضی جزئیات Subscription متفاوت هستند.

در این راهنما، هدف این نیست که یک جدول قیمت را بازنشر کنیم. هدف این است که قبل از درخواست Quote بدانید دقیقاً چه چیزهایی را باید بشمارید، چه چیزهایی را نباید دوبار حساب کنید و چه زمانی Cloud، On-Premises یا MSSP برای سازمان منطقی‌تر است.

لایسنس Log360 بر چه اساسی محاسبه می‌شود؟

طبق مستند فعلی ManageEngine، Log360 On-Premises یک Edition اصلی با نام Professional دارد و Licensing آن براساس تعداد منابعی است که واقعاً می‌خواهید مانیتور یا Audit کنید. پنج جزء اصلی عبارت‌اند از:

جزء لایسنس چه چیزی شمرده می‌شود؟ نمونه
Domain Controllers کنترلرهای دامنه‌ای که AD Auditing روی آن‌ها انجام می‌شود DC01، DC02، RODC شعبه
Log Sources سرورها، تجهیزات شبکه، امنیت، دیتابیس و Applicationهایی که Log می‌فرستند Linux، Firewall، Router، MSSQL، IIS
File Servers Windows File Server و NASهایی که File Audit می‌شوند File Server، NAS
Endpoints Workstationهای Windows و Mac که در Scope هستند PC و Laptop کاربران
Cloud Accounts حساب‌ها یا Tenantهای Cloud تحت مانیتورینگ AWS Account، Microsoft 365 Tenant

مزیت این مدل این است که لازم نیست برای بخشی که استفاده نمی‌کنید هزینه بدهید. ManageEngine در راهنمای رسمی Licensing این رویکرد را با عبارت «pay only for what you use» توضیح می‌دهد؛ یعنی می‌توانید فقط Componentهایی را بخرید که در Scope واقعی پروژه هستند.

آیا Log360 هنوز EPS-based است؟

یکی از اشتباه‌های رایج در RFPها این است که Log360 مانند بعضی SIEMها فقط با EPS یا GB/day قیمت‌گذاری شود. در مدل فعلی On-Premises، معیار اصلی خرید تعداد Asset/Source در Componentهای تعریف‌شده است، نه اینکه صرفاً بگوییم ۵۰۰۰ EPS داریم.

البته EPS و حجم Log برای Sizing زیرساخت، CPU، RAM، Storage، Retention و معماری Distributed بسیار مهم هستند؛ اما این موضوع را نباید با Metric اصلی Licensing یکی دانست.

نکته زمانی مهم هم این است که ManageEngine در Release Notes رسمی Log360، در Build 13025 منتشرشده در ۳۰ مارس ۲۰۲۶، از معرفی یک مدل جدید License Management خبر داده است. در همین تغییر، وقتی Limit لایسنس پر شود، Deviceهای بیشتر می‌توانند محدود یا غیرفعال شوند تا ظرفیت مجاز رعایت شود. بنابراین در پروژه‌های جدید بهتر است به Documentation و Build فعلی استناد کنید، نه فایل‌های قدیمی Proposal.

Log Source دقیقاً چیست؟

در Quote رسمی ManageEngine، Log Source می‌تواند یکی از این موارد باشد:

  • Windows Server
  • Linux/Unix Server
  • Firewall
  • Router و Switch
  • IDS/IPS
  • AS400
  • Microsoft SQL Server
  • IIS Site یا Application
  • سایر Deviceها و Applicationهایی که Log به Log360 ارسال می‌کنند

پس اگر ۱۰ Firewall، ۲۰ Linux Server، ۵ Router و ۱۵ Application مستقل در Scope دارید، نقطه شروع شما برای این بخش ۵۰ Log Source است؛ البته باید Mapping نهایی با Matrix رسمی محصول و معماری واقعی Collection تأیید شود.

در پروژه‌های بزرگ، قبل از خرید بهتر است یک Inventory واقعی از Sourceها بسازید. عبارت‌هایی مثل «حدود ۱۰۰ سرور» یا «تقریباً ۳۰ فایروال و سوئیچ» برای Quote دقیق کافی نیستند.

Domain Controller را جدا از Log Source حساب کنیم؟

بله، در مدل قیمت‌گذاری فعلی Log360، Domain Controller یک Component مستقل است. اگر هدف شما استفاده از قابلیت‌های Active Directory Auditing، Logon Audit، تغییر Group Policy، تغییر Membership گروه‌های حساس و سایر Auditهای AD باشد، تعداد DCهای تحت مانیتورینگ باید مشخص شود.

برای مثال، سازمانی با یک Forest و سه Domain ممکن است این ساختار را داشته باشد:

  • دو DC در Domain اصلی
  • دو DC در Domain دوم
  • یک RODC در شعبه

اگر هر پنج مورد در Scope Audit باشند، باید ظرفیت پنج Domain Controller در نظر گرفته شود. اشتباه رایج این است که فقط تعداد Domainها شمرده شود؛ در حالی که License Metric روی DCهای مورد مانیتورینگ تمرکز دارد.

File Server چه زمانی وارد لایسنس می‌شود؟

اگر فقط Syslog یا Event عمومی یک Server را جمع می‌کنید، نگاه شما با حالتی که File Audit و تغییرات فایل/Folder را بررسی می‌کنید یکسان نیست. در Log360، Windows File Server و NAS برای قابلیت‌های File Auditing می‌توانند Component مستقل لایسنس باشند.

این بخش برای سازمان‌هایی مهم است که می‌خواهند روی داده حساس، تغییر Permission، حذف فایل، Rename، Access و فعالیت‌های مشکوک فایل نظارت داشته باشند. مقاله File Integrity Monitoring در EventLog Analyzer نمونه‌ای از تفاوت میان «داشتن لاگ» و «پایش تغییرات حساس فایل» را توضیح می‌دهد.

Endpoint در Log360 یعنی چه؟

در فرم رسمی Evaluation License، Endpoint برای Windows Workstation و Mac در نظر گرفته شده است. بنابراین اگر SOC فقط روی Server و تجهیزات شبکه تمرکز دارد، لزوماً همه ۲۰۰۰ کاربر سازمان به معنی ۲۰۰۰ Endpoint License نیستند؛ Scope باید مشخص کند چه Workstationهایی واقعاً قرار است تحت پوشش قابلیت‌های مربوطه باشند.

از طرف دیگر، اگر قرار است Endpoint Telemetry یا Audit روی همه سیستم‌های کاربران انجام شود، تعداد Workstationهای واقعی مهم است، نه تعداد User Accountهای Active Directory.

این تفاوت ساده می‌تواند در پروژه‌های چند هزار کاربره تأثیر زیادی بر Budget داشته باشد.

Cloud Account چگونه شمرده می‌شود؟

ManageEngine در فرم Quote فعلی، AWS Account و Microsoft 365 Tenant را به‌عنوان نمونه Cloud Account ذکر می‌کند. بنابراین برای محیط Hybrid باید Cloud Scope را جداگانه Inventory کنید.

مثلاً یک سازمان ممکن است:

  • یک Microsoft 365 Tenant اصلی داشته باشد؛
  • سه AWS Account برای Production، Development و Security داشته باشد؛
  • و در عین حال منابع On-Premises نیز مانیتور شوند.

در چنین معماری‌ای، Quote باید Hybrid باشد و صرفاً تعداد Serverهای داخل دیتاسنتر تصویر کامل هزینه را نشان نمی‌دهد.

نمونه قیمت عمومی Log360 On-Premises در ۲۰۲۶

صفحه Pricing رسمی ManageEngine در زمان نگارش این مقاله، نمونه‌های عمومی زیر را برای Subscription سالانه نشان می‌دهد. این اعداد Quote نهایی مدانت نیستند و ممکن است براساس Region، قرارداد، مالیات، Currency، تخفیف و Scope تغییر کنند.

Component ظرفیت نمونه Subscription سالانه عمومی
Domain Controllers 2 DC 945 دلار
File Servers 2 File Server 495 دلار
Log Sources 10 Source 795 دلار
Cloud Accounts 1 Account 995 دلار
Endpoints 100 Endpoint 245 دلار

ManageEngine همچنین Perpetual Model را برای On-Premises ارائه می‌کند و در Store رسمی تأکید دارد که مشتری محدود به Slabهای از پیش تعریف‌شده نیست و برای تعدادهای متفاوت می‌تواند Custom Quote بگیرد.

برای برآورد نهایی در ایران، به‌جای تبدیل مستقیم جدول دلار به تومان، بهتر است از استعلام قیمت لایسنس ManageEngine مدانت استفاده کنید؛ چون نوع قرارداد، AMS، مدت اعتبار و خدمات استقرار هم روی پیشنهاد تجاری اثر دارند.

Subscription یا Perpetual؛ کدام برای Log360 مناسب‌تر است؟

معیار Subscription Perpetual
هزینه اولیه کمتر بیشتر
حق استفاده تا زمان Subscription فعال حق استفاده دائمی از نسخه خریداری‌شده
Upgrade/Support در دوره معتبر قرارداد وابسته به AMS معتبر
مناسب برای OPEX و انعطاف بودجه CAPEX و مالکیت بلندمدت

اگر Perpetual می‌خرید، هزینه AMS را در TCO چندساله نادیده نگیرید. مقاله انقضای AMS ManageEngine توضیح می‌دهد که پایان AMS چه اثری روی Support و Upgrade دارد.

Log360 Cloud چه تفاوتی در Licensing دارد؟

Log360 Cloud هم از مدل Infrastructure-based استفاده می‌کند، اما ساختار Plan آن با On-Premises یکسان نیست. در مستندات فعلی Cloud، Componentها مستقل انتخاب می‌شوند و Storage نیز قابل افزایش است. Cloud دو Edition اصلی Professional و Enterprise دارد.

در Pricing عمومی فعلی، برای نمونه ۱۰ Log Source حدود ۱,۰۹۵ دلار در سال در Professional و ۱,۳۹۵ دلار در Enterprise نمایش داده می‌شود. برای ۲۵، ۵۰، ۱۰۰ و ۲۵۰ Log Source نیز Tierهای بالاتر وجود دارد.

Cloud همچنین Search Storage و Archival Storage دارد؛ بنابراین هنگام مقایسه TCO، فقط تعداد Source را نبینید. Retention، Searchable Data، Archive و رشد Log Volume روی هزینه و معماری Cloud اثر دارند.

Log360 Cloud یا On-Premises؟

معیار On-Premises Cloud
زیرساخت SIEM در دیتاسنتر سازمان سرویس Cloud
مدل اصلی خرید Component-based Infrastructure-based + Storage
Edition Professional Professional / Enterprise
Perpetual دارد Subscription محور
کنترل زیرساخت بیشتر نیاز عملیاتی کمتر
مناسب برای Data Locality، شبکه محدود، کنترل کامل Scale سریع، کاهش نگهداری زیرساخت SIEM

انتخاب درست فقط مالی نیست. Data Residency، Connectivity، Retention، الزامات Compliance، ظرفیت تیم SOC و سیاست Cloud سازمان باید کنار قیمت دیده شوند.

MSSP چه زمانی مطرح می‌شود؟

اگر یک شرکت امنیتی چند مشتری مستقل را از یک Portal مدیریت می‌کند، Log360 MSSP سناریوی جداگانه‌ای است. در Cloud MSSP، هر Tenant می‌تواند Licensing و Storage Allocation مستقل داشته باشد و Billing ماهانه یا سالانه در دسترس است.

برای یک سازمان عادی با یک Tenant داخلی، خرید MSSP معمولاً مسئله اصلی نیست. اما برای Providerهایی که SOC as a Service ارائه می‌کنند، Multi-tenancy، Customer Isolation، License Allocation و Billing به بخشی از معماری خرید تبدیل می‌شوند.

آیا UEBA، SOAR و MITRE ATT&CK لایسنس جدا می‌خواهند؟

پاسخ دقیق باید براساس Build، Plan و Quote فعلی بررسی شود، چون Bundleها و Add-onها ممکن است تغییر کنند. چیزی که نباید انجام دهید این است که صرفاً از روی نام Feature نتیجه بگیرید «همه چیز حتماً در Base License است» یا «هر Feature حتماً Add-on جدا دارد».

برای طراحی Scope فنی، بهتر است ابتدا Capabilityهای موردنیاز را فهرست کنید: UEBA، SOAR، Threat Detection، DLP، CASB، Compliance، AD Audit و Log Management. سپس آن را با Bill of Materials لایسنس تطبیق دهید.

برای درک کاربرد عملی UEBA می‌توانید مقاله Peer Grouping در Log360 UEBA را بخوانید. برای Detection Engineering نیز مقاله MITRE ATT&CK در Log360 مکمل مناسبی است.

سناریوی اول: سازمان متوسط با ۵۰۰ کاربر

فرض کنید Scope اولیه چنین است:

  • 4 Domain Controller
  • 35 Log Source شامل Server، Firewall و Network Device
  • 3 File Server
  • 250 Endpoint
  • 1 Microsoft 365 Tenant

اشتباه این است که بگوییم «۵۰۰ کاربر داریم، پس ۵۰۰ لایسنس لازم است.» در Log360 باید هر Component جداگانه Size شود. ممکن است تعداد User صرفاً برای Business Context مهم باشد، اما License Quantity از پنج شمارنده بالا ساخته شود.

بعد از این Inventory، باید Data Volume و Retention هم برای Hardware/Storage Sizing محاسبه شوند.

سناریوی دوم: دیتاسنتر با Log Source زیاد اما Endpoint کم

فرض کنید یک شرکت Hosting یا زیرساختی ۱۵۰ Server، ۳۰ Firewall/Router و فقط ۵۰ Endpoint اداری دارد.

در این محیط، Cost Driver اصلی احتمالاً Log Source است، نه Endpoint. اگر از فرمول «تعداد کاربر × قیمت» استفاده شود، Budget Planning کاملاً منحرف می‌شود.

در معماری Collection نیز باید مشخص شود کدام Sourceها Agentless و کدام Agent-based هستند. راهنمای Agentless یا Agent-based در EventLog Analyzer برای طراحی LAN، WAN و DMZ می‌تواند به همین مرحله کمک کند.

سناریوی سوم: سازمان Hybrid با Cloud Account زیاد

سازمانی را در نظر بگیرید که بخش زیادی از Workload را به AWS و Microsoft 365 منتقل کرده، اما Active Directory و بعضی Serverها هنوز On-Premises هستند.

در این حالت، خرید Log360 صرفاً با شمارش Serverهای داخلی، Coverage Gap ایجاد می‌کند. باید Cloud Accountها، Tenantها، Log Sourceهای داخل Cloud و Retention موردنیاز هم در Scope بیایند.

در POC، بهتر است حداقل یک Use Case واقعی از هر محیط اجرا شود: AD، Firewall، Server، Cloud و Endpoint. هدف Trial فقط دیدن Dashboard نیست؛ هدف Verify کردن Source Count، Quality of Logs، Detection Coverage و Storage Growth است.

چطور قبل از خرید، Bill of Materials بسازیم؟

یک Sheet ساده با ستون‌های زیر ایجاد کنید:

ستون مثال
Asset Name FW-HQ-01
Asset Type Firewall
License Component Log Source
Environment Production
Location HQ
Daily Log Volume 3.2 GB
Retention 180 Days
Criticality High
In Scope? Yes

بعد Pivot بگیرید و پنج Component اصلی را جمع کنید. این Sheet بعداً برای Capacity Planning و تغییرات Renewal هم کاربرد دارد.

۱۰ خطای رایج در خرید لایسنس Log360

  1. محاسبه لایسنس فقط براساس تعداد User.
  2. اشتباه گرفتن EPS با License Metric اصلی.
  3. فراموش کردن Domain Controllerهای شعب و RODCها.
  4. شمردن تقریبی Log Sourceها به‌جای Inventory واقعی.
  5. نادیده گرفتن File Server و NAS در File Audit.
  6. فراموش کردن Microsoft 365 Tenant و AWS Account.
  7. خرید ظرفیت دقیق امروز بدون Growth Margin.
  8. مقایسه Cloud و On-Prem فقط با قیمت اولیه.
  9. نادیده گرفتن Retention و Storage.
  10. خرید Perpetual بدون محاسبه AMS در TCO.

چقدر Growth Margin در نظر بگیریم؟

اگر سازمان شما ثابت نیست، خرید دقیقاً برابر با Inventory امروز می‌تواند چند ماه بعد مشکل ایجاد کند. Growth Margin باید براساس Roadmap واقعی تعیین شود.

مثلاً اگر قرار است در ۱۲ ماه آینده دو شعبه، ۲۰ Server و یک Tenant جدید اضافه شود، بهتر است از ابتدا سناریوی رشد در Quote دیده شود. اما Oversizing شدید هم سرمایه را بلااستفاده می‌کند.

مدل بهتر این است که سه سناریو بسازید:

  • Current Scope
  • 12-Month Expected Scope
  • Peak/Expansion Scenario

بعد هزینه Increment هر مرحله را از فروشنده بگیرید.

چه زمانی باید License را دوباره Size کنیم؟

Sizing یک کار یک‌بار برای همیشه نیست. حداقل در این Triggerها باید بازبینی شود:

  • اضافه شدن Branch یا Data Center
  • Cloud Migration
  • خرید Firewall یا Server جدید
  • M&A و اضافه شدن Domain جدید
  • افزایش Coverage Endpoint
  • تغییر Retention Policy
  • فعال‌سازی Use Caseهای جدید SOC
  • Renewal سالانه یا AMS

در Buildهای جدید Log360، License Management نسبت به عبور از Limit کنترل سخت‌گیرانه‌تری دارد؛ بنابراین Monitoring Usage قبل از رسیدن به سقف اهمیت بیشتری پیدا کرده است.

نسخه فعلی Log360 را قبل از خرید یا Renewal چک کنید

در زمان نگارش این مقاله، شاخه Log360 13.0 فعال است و Read Me رسمی ManageEngine، Build 13071 را با تاریخ انتشار ۲۵ اوت ۲۰۲۶ ثبت کرده است. در همین Build، PostgreSQL و Apache Tomcat داخلی برای رفع مسائل امنیتی ارتقا یافته‌اند.

این نکته برای Renewal مهم است: Licensing، Feature Matrix و Security Baseline را براساس Build واقعی محیط خود بررسی کنید. Proposal قدیمی مربوط به دو سال قبل نباید مبنای قطعی طراحی ۲۰۲۶ باشد.

چطور POC را به خرید درست تبدیل کنیم؟

در POC این پنج عدد را حتماً ثبت کنید:

  1. تعداد Sourceهایی که واقعاً Onboard شدند.
  2. تعداد DC و File Serverهای تحت Audit.
  3. تعداد Endpointهای موردنیاز.
  4. تعداد Cloud Account/Tenant.
  5. حجم روزانه Log و Retention واقعی.

سپس Detection Use Caseها را هم ثبت کنید. ممکن است یک Source حجم Log بالایی داشته باشد ولی ارزش امنیتی پایین؛ یا برعکس، یک Domain Controller حجم متوسطی داشته باشد اما برای Identity Detection حیاتی باشد.

Checklist استعلام قیمت Log360

  • تعداد Domain Controllerها مشخص است.
  • Log Sourceها بر اساس نوع Asset تفکیک شده‌اند.
  • File Server و NAS جداگانه مشخص شده‌اند.
  • Endpointهای واقعی Scope شده‌اند.
  • Cloud Accountها و Tenantها شمرده شده‌اند.
  • Cloud یا On-Premises انتخاب اولیه دارد.
  • Subscription یا Perpetual بررسی شده است.
  • Retention و Daily Log Volume اندازه‌گیری شده‌اند.
  • Growth 12 ماهه پیش‌بینی شده است.
  • نیاز به MSSP مشخص است.
  • Use Caseهای UEBA/SOAR/DLP/Compliance فهرست شده‌اند.
  • AMS، Support و Upgrade در TCO آمده‌اند.

سخن پایانی

لایسنس Log360 را نباید با یک عدد واحد مثل «تعداد کاربر» یا «EPS» ساده کرد. مدل فعلی محصول بر Scope واقعی زیرساخت بنا شده است: چند Domain Controller، چند Log Source، چند File Server، چند Endpoint و چند Cloud Account قرار است واقعاً تحت پوشش قرار بگیرند.

اگر این پنج عدد درست Inventory شوند و بعد حجم Log، Retention، Growth و Use Caseهای SOC به آن اضافه شوند، هم ریسک Over-Licensing کم می‌شود و هم احتمال اینکه چند ماه بعد با کمبود Capacity یا Coverage روبه‌رو شوید پایین می‌آید.

برای طراحی Scope می‌توانید ابتدا صفحه Log360 مدانت را ببینید و برای دریافت پیشنهاد متناسب با معماری سازمان از درخواست دمو و جلسه فنی استفاده کنید. برای Quote نهایی نیز استعلام قیمت لایسنس ManageEngine در دسترس است. اگر محصول در محیط Production فعال است، خدمات پشتیبانی مدانت نیز می‌تواند در Upgrade، Health Check، Tuning و Renewal لحاظ شود.

منابع

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

33

دیدگاه شما

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