0

مدیریت دارایی سایبری چیست و چطور Inventory را به کنترل ریسک تبدیل کنیم؟ راهنمای عملی Discovery، Owner، Asset Criticality، دارایی‌های ناشناخته و اتصال AssetExplorer به Endpoint و Vulnerability Management.

شرکت مدانت
شرکت مدانت
[ مجری تخصصی پیاده‌سازی چارچوب ITIL و تحول دیجیتال ]
مدیریت دارایی سایبری چیست؟ از Inventory تا کاهش سطح حمله با AssetExplorer

فرض کنید تیم امنیت یک هشدار درباره یک IP داخلی دریافت کرده است. در SIEM می‌بینید این سیستم به یک مقصد مشکوک متصل شده، اما چند سؤال ساده هنوز بی‌پاسخ است: این دستگاه مال کدام واحد است؟ چه کسی مالک آن است؟ سیستم‌عامل و نرم‌افزارهایش چیست؟ آیا سازمان اصلاً آن را مجاز می‌داند؟ آخرین بار چه زمانی Inventory شده و آیا هنوز تحت مدیریت IT قرار دارد؟

در چنین لحظه‌ای، مشکل فقط «نداشتن ابزار امنیتی» نیست؛ مشکل این است که سازمان تصویر قابل اعتمادی از دارایی‌های دیجیتال خودش ندارد. مدیریت دارایی سایبری یا Cyber Asset Management تلاش می‌کند همین خلأ را پر کند: بدانیم چه دارایی‌هایی داریم، کجا هستند، چه کسی مسئول آن‌هاست، چه ارزشی برای کسب‌وکار دارند و کدام‌یک می‌توانند سطح حمله سازمان را افزایش دهند.

برای بسیاری از سازمان‌ها، نقطه شروع این مسیر همان IT Asset Management است. ابزارهایی مانند ManageEngine AssetExplorer می‌توانند پایه Inventory و چرخه عمر دارایی را بسازند؛ سپس این داده با مدیریت Endpoint، Vulnerability Management، CMDB و فرآیندهای امنیتی ترکیب می‌شود تا از یک «فهرست تجهیزات» به یک نمای عملیاتی از ریسک برسیم.

مدیریت دارایی سایبری دقیقاً چیست؟

مدیریت دارایی سایبری یعنی ایجاد و نگهداری یک نمای مستمر و قابل اعتماد از دارایی‌های فناوری که می‌توانند روی امنیت سازمان اثر بگذارند. این دارایی‌ها فقط لپ‌تاپ و سرور نیستند؛ تجهیزات شبکه، ماشین‌های مجازی، نرم‌افزارها، سرویس‌ها، دارایی‌های راه دور، تجهیزات IoT و هر جزء دیگری که داده را پردازش یا دسترسی سازمانی ایجاد می‌کند باید در Scope مناسب دیده شود.

نکته مهم این است که Cyber Asset Management با «ثبت دارایی در Excel» فرق دارد. Inventory باید زنده باشد. دستگاهی که سه ماه پیش وجود داشته ولی امروز Retire شده نباید همان وزن یک Server فعال را داشته باشد؛ در مقابل، یک VM تازه‌ساخته‌شده یا لپ‌تاپ پیمانکار نباید تا Audit بعدی از دید سازمان پنهان بماند.

در CIS Controls v8.1، کنترل شماره ۱ مستقیماً روی Inventory و کنترل Enterprise Assetها تمرکز دارد و تأکید می‌کند سازمان باید دارایی‌های فیزیکی، مجازی، Remote و Cloud را بشناسد و دارایی‌های Unauthorized یا Unmanaged را شناسایی و اصلاح کند. همین منطق در NIST Cybersecurity Framework 2.0 نیز در دسته Asset Management یا ID.AM دیده می‌شود.

چرا Asset Inventory یک موضوع امنیتی است، نه فقط مالی؟

در نگاه سنتی، Asset Management بیشتر با خرید، تحویل، استهلاک، قرارداد، Warranty و License Compliance شناخته می‌شود. این‌ها همچنان مهم‌اند، اما امنیت یک سؤال بنیادی‌تر دارد:

اگر چیزی را نمی‌شناسیم، چطور می‌خواهیم Patch، Hardening، Monitoring یا Incident Response را روی آن انجام دهیم؟

یک Asset ناشناخته می‌تواند سیستم آزمایشی فراموش‌شده، لپ‌تاپ خارج از مدیریت، Server با سیستم‌عامل قدیمی، تجهیز شبکه‌ای بدون Owner، یا VMای باشد که برای یک پروژه کوتاه ساخته شده ولی بعد از پایان پروژه روشن مانده است. هرکدام از این موارد می‌توانند به Blind Spot تبدیل شوند.

به همین دلیل Inventory نقطه اتصال چند حوزه است: ITAM می‌گوید چه چیزی وجود دارد؛ Endpoint Management می‌گوید چطور آن را کنترل کنیم؛ Vulnerability Management می‌گوید چه ضعف‌هایی دارد؛ CMDB می‌گوید به چه سرویس‌هایی وابسته است؛ و SIEM می‌گوید چه رفتار امنیتی از آن مشاهده شده است.

تفاوت ITAM، Cyber Asset Management و Vulnerability Management

حوزه سؤال اصلی خروجی مورد انتظار
IT Asset Management چه دارایی‌هایی داریم و چرخه عمرشان چیست؟ Inventory، Owner، Contract، License، Lifecycle، Cost
Cyber Asset Management کدام دارایی‌ها از دید امنیتی قابل اعتماد، ناشناخته یا پرریسک‌اند؟ Visibility، Authorized/Unauthorized، Security Context، Exposure
Vulnerability Management کدام ضعف‌ها باید زودتر Remediate شوند؟ Vulnerability، Risk Score، Exploitability، Patch/Remediation
CMDB این CI چه نقشی در سرویس و Dependencyها دارد؟ Relationship، Business Context، Impact

این حوزه‌ها جای یکدیگر را نمی‌گیرند. سازمانی که فقط Vulnerability Scanner دارد ممکن است هزاران CVE ببیند اما Owner یک Asset را نداند. سازمانی که فقط ITAM دارد ممکن است Serial Number و قرارداد را بداند، اما Priority امنیتی یک سیستم را نفهمد. بلوغ زمانی ایجاد می‌شود که این داده‌ها به یکدیگر متصل شوند.

AssetExplorer در این معماری چه نقشی دارد؟

AssetExplorer برای Discovery، Inventory و مدیریت چرخه عمر دارایی‌های IT طراحی شده است. Unified Agent می‌تواند سیستم‌های Windows، Linux و macOS را Inventory کند و Network/Range Scan نیز برای کشف تجهیزات IP مانند Router، Switch و Printer کاربرد دارد. ورود دستی و CSV Import هم برای دارایی‌هایی که از مسیر Scan وارد نمی‌شوند قابل استفاده است.

این داده برای Cyber Asset Management بسیار مهم است، چون یک Asset Record قابل استفاده باید حداقل بتواند هویت و وضعیت دارایی را به اطلاعات عملیاتی وصل کند. در عمل بهتر است برای هر Asset تا حد امکان این اطلاعات وجود داشته باشد:

  • Hostname و IP/MAC
  • نوع دارایی و سیستم‌عامل
  • Owner و Department
  • Location و Environment مانند Production/Test
  • Software Inventory
  • وضعیت Lifecycle
  • آخرین Scan یا آخرین مشاهده
  • وضعیت Managed/Unmanaged
  • Business Criticality یا ارتباط با Service

مقاله Software Asset Management در AssetExplorer جزئیات بیشتری درباره License Compliance، نرم‌افزارهای غیرمجاز و کنترل هزینه ارائه می‌دهد. در این مطلب تمرکز ما روی تبدیل همان Inventory به یک لایه امنیتی قابل استفاده است.

مرحله اول: Discovery را به یک فرآیند مستمر تبدیل کنید

Inventory سالانه برای امنیت کافی نیست. دارایی‌ها دائماً تغییر می‌کنند: لپ‌تاپ جدید وارد سازمان می‌شود، VM ساخته می‌شود، Device از شبکه خارج می‌شود، سیستم‌عامل Upgrade می‌شود و Software نصب یا حذف می‌شود.

در طراحی عملی، Discovery باید چند منبع داشته باشد. Endpoint Agent برای سیستم‌های مدیریت‌شده، Network Scan برای تجهیزات IP، Import برای موجودی‌های خارجی، و در صورت نیاز Integration با سایر ابزارهای مدیریت Endpoint یا Service Management می‌توانند تصویر کامل‌تری بسازند.

هدف این نیست که هر روز فقط «تعداد Asset» بیشتر شود. هدف این است که تفاوت بین Inventory مورد انتظار و چیزی که واقعاً روی شبکه دیده می‌شود مشخص شود.

مرحله دوم: دارایی Authorized و Unauthorized را از هم جدا کنید

یکی از مهم‌ترین خروجی‌های Cyber Asset Management این است که سازمان بداند کدام Asset مجاز است.

فرض کنید Network Scan یک سیستم جدید پیدا می‌کند. صرف وجود آن در Inventory به معنی مجاز بودنش نیست. باید بتوانیم مشخص کنیم:

  • این Asset متعلق به سازمان است یا شخصی؟
  • Owner مشخص دارد یا خیر؟
  • در فرآیند Onboarding دارایی ثبت شده است؟
  • Agent مدیریتی یا Security Control لازم روی آن نصب است؟
  • اگر موقت است، Expiry Date دارد؟

CIS Control 1 دقیقاً روی همین موضوع تأکید دارد: Inventory فقط برای دانستن تعداد دستگاه‌ها نیست؛ باید Assetهای Unauthorized شناسایی شوند تا حذف، محدود یا وارد چرخه مدیریت شوند.

مرحله سوم: Owner را اجباری کنید

Asset بدون Owner در Incident Response دردسرساز است. وقتی تیم امنیت یک هشدار دریافت می‌کند، اولین سؤال عملی این است که چه کسی درباره این سیستم تصمیم می‌گیرد.

Owner می‌تواند Technical Owner، Business Owner یا هر دو باشد. برای یک Database Production، DBA ممکن است Technical Owner باشد و واحد مالی Business Owner. این تفکیک کمک می‌کند تصمیم‌هایی مانند Patch اضطراری، Downtime یا Isolation سریع‌تر انجام شوند.

یک KPI ساده اما ارزشمند می‌تواند درصد Assetهای فعال بدون Owner باشد. این عدد باید روند نزولی داشته باشد.

مرحله چهارم: Inventory نرم‌افزار را وارد تحلیل ریسک کنید

دارایی سخت‌افزاری بدون Software Context برای امنیت کافی نیست. باید بدانیم چه نرم‌افزارهایی روی سیستم نصب شده‌اند، کدام نسخه‌اند و آیا Software غیرمجاز یا منسوخ وجود دارد.

این همان نقطه‌ای است که ITAM به Security نزدیک می‌شود. اگر Inventory نشان دهد یک Application قدیمی هنوز روی ۷۰ Endpoint نصب است، تیم امنیت می‌تواند آن را با Vulnerability Data و Patch Status تطبیق دهد.

AssetExplorer می‌تواند Software Inventory را در لایه ITAM فراهم کند؛ برای Prioritization امنیتی و Remediation باید این داده با ابزارهای تخصصی Vulnerability و Endpoint Management تکمیل شود.

مرحله پنجم: Asset Criticality را به Vulnerability Context وصل کنید

دو Server ممکن است Vulnerability یکسان داشته باشند، اما ریسک آن‌ها یکسان نباشد. یکی Server آزمایشگاهی است و دیگری Authentication Server حیاتی.

در مستندات فعلی Vulnerability Manager Plus که در ۱۶ ژوئیه ۲۰۲۶ به‌روزرسانی شده‌اند، Prioritization فقط به CVSS محدود نیست و می‌تواند Risk Score، Exploitability، Threat Intelligence، EPSS، Patch Availability، تعداد سیستم‌های متاثر و Timeline آسیب‌پذیری را در تصمیم‌گیری وارد کند.

برای اینکه این اولویت‌بندی واقعاً کسب‌وکاری شود، Asset Context هم لازم است. سیستم Payroll، Domain Controller و لپ‌تاپ آزمایشگاهی نباید صرفاً به خاطر CVSS مشابه، در یک صف یکسان قرار بگیرند.

در مقاله Risk-Based Vulnerability Management در Vulnerability Manager Plus این لایه Remediation و اولویت‌بندی را عمیق‌تر بررسی کرده‌ایم.

مرحله ششم: Endpoint Management را به Inventory وصل کنید

شناخت Asset کافی نیست؛ Asset باید قابل مدیریت هم باشد. Endpoint Central می‌تواند در لایه Endpoint Management برای Patch، Configuration، Software Deployment و کنترل Endpointها استفاده شود.

یک الگوی عملی این است که Assetهای کشف‌شده را به چند وضعیت تقسیم کنید:

وضعیت Asset اقدام پیشنهادی
شناخته‌شده و Managed پایش مستمر، Patch و Policy Compliance
شناخته‌شده ولی Unmanaged ورود به چرخه مدیریت یا ثبت Exception
ناشناخته ولی مشاهده‌شده روی شبکه Investigation و تعیین Owner
Retired ولی هنوز Online بررسی فوری Lifecycle و Disconnect
Critical با Exposure بالا اولویت Remediation و Monitoring بیشتر

این Classification ساده می‌تواند Dashboard مشترک IT و Security را بسیار کاربردی‌تر کند.

مرحله هفتم: CMDB و Business Service را وارد کنید

Cyber Asset Management وقتی فقط در سطح Device بماند، نمی‌تواند Impact واقعی را نشان دهد. باید بدانیم یک Asset به چه Service یا Applicationی مرتبط است.

برای مثال، یک Linux Server شاید از نظر قیمت دارایی کم‌اهمیت باشد، اما اگر بخشی از Payment Service باشد، Business Impact آن بسیار بالا است. اتصال ITAM به CMDB و Relationshipها کمک می‌کند Asset Criticality واقعی‌تر تعیین شود.

برای معماری ITAM و CMDB در Service Management، راهنمای IT Asset Management در ServiceDesk Plus می‌تواند مسیر تکمیلی مناسبی باشد.

مدیریت دارایی سایبری با CAASM یکی نیست

گاهی اصطلاح Cyber Asset Management با CAASM یا Cyber Asset Attack Surface Management یکی فرض می‌شود. بهتر است این دو را دقیق‌تر تفکیک کنیم.

CAASM معمولاً به رویکردی اشاره می‌کند که داده Asset را از چندین منبع Security و IT جمع می‌کند، Identity و Coverage آن‌ها را تطبیق می‌دهد و Blind Spotها را در مقیاس بزرگ آشکار می‌کند. اما هر ITAM Tool الزاماً CAASM نیست و نباید AssetExplorer را صرفاً به دلیل داشتن Discovery به‌عنوان CAASM معرفی کرد.

در معماری ManageEngine، می‌توان از چند ابزار تخصصی برای پوشش لایه‌های مختلف استفاده کرد: AssetExplorer برای Inventory و Lifecycle، Endpoint Central برای Endpoint Control، Vulnerability Manager Plus برای Exposure و Remediation، و ServiceDesk Plus/CMDB برای Business Context. ارزش اصلی در Integration و Data Governance بین این لایه‌هاست.

مدل داده پیشنهادی برای Asset امنیتی

اگر می‌خواهید Inventory واقعاً در امنیت استفاده شود، Asset Record باید بیش از Serial Number داشته باشد. یک مدل ساده می‌تواند شامل این فیلدها باشد:

فیلد چرا مهم است؟
Asset ID شناسه یکتا برای Correlation بین ابزارها
Owner مسئول تصمیم‌گیری و پاسخگویی
Business Service درک Impact کسب‌وکار
Environment تفکیک Production، Test و Development
Criticality اولویت Security و Change
Last Seen / Last Scan تشخیص Stale Asset
Management Status Managed یا Unmanaged
OS / Software زمینه Vulnerability و EOL/EOS
Patch / Exposure Status ریسک فنی جاری
Lifecycle Status Active، Spare، Retired، Disposed

Stale Asset را جدی بگیرید

یکی از خطرناک‌ترین حالت‌ها Assetای است که هنوز در Inventory وجود دارد اما کسی نمی‌داند واقعاً فعال است یا نه. این رکوردها باعث می‌شوند Dashboard ظاهراً کامل باشد ولی Ground Truth ناقص بماند.

برای Staleness باید Policy داشته باشید. مثلاً اگر Endpoint برای مدت مشخصی دیده نشده، بررسی شود که آیا خارج از شبکه است، Retire شده، Agent مشکل دارد یا Asset گم شده است. Threshold زمانی به ماهیت Asset بستگی دارد و نباید برای همه تجهیزات یکسان باشد.

EOL و EOS را به Risk Register وصل کنید

End of Life و End of Support فقط موضوع Procurement نیستند. سیستم‌عامل یا نرم‌افزاری که دیگر Patch امنیتی دریافت نمی‌کند می‌تواند Risk ساختاری ایجاد کند.

بهتر است Assetهای EOL/EOS از Inventory استخراج و به برنامه Migration یا Risk Acceptance متصل شوند. اگر تعویض فوری ممکن نیست، Compensating Control مانند Segmentation، محدودسازی دسترسی یا Monitoring بیشتر باید تعریف شود.

یک سناریوی عملی: لپ‌تاپ ناشناخته در شبکه

فرض کنید Network Scan دستگاهی با IP جدید پیدا می‌کند.

  1. Asset در Inventory مرکزی ثبت می‌شود.
  2. Owner و Department از روی داده موجود یا فرآیند سازمانی تعیین می‌شوند.
  3. بررسی می‌شود آیا Endpoint Agent و Security Control لازم نصب است.
  4. Software Inventory استخراج می‌شود.
  5. اگر Asset مجاز نیست، Incident یا Exception Workflow آغاز می‌شود.
  6. اگر مجاز ولی Unmanaged است، به Endpoint Management وارد می‌شود.
  7. Vulnerability و Patch Status ارزیابی می‌شود.
  8. در صورت ارتباط با Business Service، Criticality تنظیم می‌شود.

در این سناریو، هیچ ابزار واحدی همه کارها را انجام نمی‌دهد؛ ارزش در زنجیره Discovery تا Remediation است.

یک سناریوی عملی دیگر: Server قدیمی اما حیاتی

Inventory نشان می‌دهد یک Server قدیمی هنوز برای یک Application مالی استفاده می‌شود. سیستم‌عامل نزدیک EOL است و تیم Security چند Vulnerability مهم روی آن می‌بیند.

اگر فقط Vulnerability را ببینیم، ممکن است Patch یا Reboot فوری پیشنهاد شود. اگر فقط Business Criticality را ببینیم، ممکن است تغییر برای همیشه عقب بیفتد. مدیریت دارایی سایبری باید هر دو Context را کنار هم بگذارد:

  • Criticality سرویس
  • Exposure واقعی
  • Patch Availability
  • Dependency
  • Maintenance Window
  • Migration Plan
  • Risk Acceptance در صورت عدم امکان اصلاح فوری

این دقیقاً نقطه‌ای است که ITAM، Security و Change Management باید یک زبان مشترک پیدا کنند.

KPIهای مفید برای مدیریت دارایی سایبری

KPI هدف
Inventory Coverage درصد دارایی‌های مورد انتظار که در Inventory دیده می‌شوند
Unauthorized Asset Count کاهش دارایی‌های بدون مجوز
Owner Completeness کاهش Assetهای بدون Owner
Unmanaged Asset Ratio کاهش Assetهای شناخته‌شده ولی خارج از مدیریت
Stale Asset Ratio کاهش رکوردهای قدیمی و بدون مشاهده اخیر
Critical Asset Exposure تعداد Assetهای حیاتی با ریسک بالا
EOL/EOS Exposure تعداد دارایی‌های فعال خارج از پشتیبانی
Mean Time to Identify Owner سرعت تعیین مسئول Asset هنگام Incident

تعداد کل Asset به‌تنهایی KPI بلوغ نیست. ممکن است سازمان ۱۰ هزار رکورد داشته باشد ولی ۳۰ درصد آن‌ها Owner نداشته باشند. کیفیت داده مهم‌تر از حجم داده است.

چه اشتباه‌هایی پروژه Cyber Asset Management را خراب می‌کنند؟

۱. شروع با Excel و پایان دادن در Excel

Spreadsheet برای Import اولیه مناسب است، اما Discovery مستمر و Correlation را جایگزین نمی‌کند.

۲. تمرکز فقط روی Hardware

Software، Service، VM و Assetهای Remote هم بخشی از Attack Surface هستند.

۳. نداشتن Owner

Asset بدون Owner در زمان Incident و Change تصمیم‌گیری را کند می‌کند.

۴. یکی دانستن Inventory با Security

داشتن Asset List به‌تنهایی Vulnerability را Remediate یا Policy را Enforce نمی‌کند. باید لایه‌های Endpoint و Vulnerability Management متصل شوند.

۵. نگه داشتن Assetهای Retired در وضعیت Active

Lifecycle ضعیف باعث می‌شود Inventory به‌تدریج اعتمادپذیری خود را از دست بدهد.

۶. یکسان دیدن همه دارایی‌ها

Asset Criticality باید در Priority Security و Maintenance اثر داشته باشد.

نقشه راه ۳۰ روزه برای شروع

بازه اقدام
روز ۱ تا ۵ تعریف Scope، Asset Typeها، Owner Model و Sourceهای Discovery
روز ۶ تا ۱۰ فعال‌سازی Discovery و پاک‌سازی Duplicateها
روز ۱۱ تا ۱۵ تعیین Authorized/Unauthorized و Managed/Unmanaged
روز ۱۶ تا ۲۰ اتصال Software Inventory، Lifecycle و Criticality
روز ۲۱ تا ۲۵ اتصال Vulnerability/Patch Context برای Assetهای حساس
روز ۲۶ تا ۳۰ ساخت KPI Dashboard، Exception Workflow و Review دوره‌ای

در سازمان بزرگ بهتر است این برنامه ابتدا روی یک Business Unit یا Service حیاتی Pilot شود و بعد Scope گسترش پیدا کند.

AssetExplorer را کجا قرار دهیم؟

اگر مسئله اصلی شما این است که Inventory قابل اعتماد، Software/Hardware Visibility، مالکیت و چرخه عمر Asset ندارید، AssetExplorer می‌تواند نقطه شروع مناسبی باشد. اگر مسئله اصلی Patch و Configuration Endpointهاست، Endpoint Management باید به این لایه اضافه شود. اگر مسئله Exposure و اولویت Remediation است، Vulnerability Management لازم است.

به زبان ساده:

  • AssetExplorer: چه چیزی داریم و وضعیت Asset چیست؟
  • Endpoint Central: چطور Endpoint را مدیریت و کنترل کنیم؟
  • Vulnerability Manager Plus: کدام Exposure مهم‌تر است و چطور Remediate شود؟
  • ServiceDesk Plus / CMDB: Asset چه نقشی در Service و Impact دارد؟

این تفکیک جلوی خرید ابزار اشتباه یا انتظار غیرواقعی از یک محصول را می‌گیرد.

نکات کلیدی

  • مدیریت دارایی سایبری از Inventory شروع می‌شود اما به Inventory ختم نمی‌شود.
  • دارایی Unknown یا Unmanaged باید یک Exception قابل پیگیری باشد، نه یک رکورد عادی.
  • Owner و Business Criticality برای اولویت‌بندی امنیتی ضروری‌اند.
  • ITAM، Endpoint Management، Vulnerability Management و CMDB مکمل یکدیگرند.
  • CIS Controls v8.1 و NIST CSF 2.0 هر دو Asset Visibility و Inventory را بخشی از پایه مدیریت ریسک سایبری می‌دانند.
  • AssetExplorer را باید به‌عنوان پایه ITAM و Discovery استفاده کرد، نه اینکه آن را به‌تنهایی جایگزین Vulnerability Management یا CAASM فرض کنیم.

سخن پایانی

بسیاری از پروژه‌های امنیتی از Firewall، SIEM یا Vulnerability Scanner شروع می‌شوند، در حالی که یک سؤال ساده هنوز جواب دقیقی ندارد: «دقیقاً چه چیزهایی باید محافظت شوند؟»

مدیریت دارایی سایبری این سؤال را به یک فرآیند عملی تبدیل می‌کند. Discovery مستمر، Inventory قابل اعتماد، Owner، Lifecycle، Software Context، Business Criticality و Exposure باید کنار هم قرار بگیرند تا Blind Spotها کمتر شوند.

اگر سازمان شما هنوز بین چند Inventory، فایل Excel، کنسول Endpoint و فهرست‌های جداگانه Security در رفت‌وآمد است، می‌توان معماری را مرحله‌ای یکپارچه کرد. مدانت برای AssetExplorer، Endpoint Central و راهکارهای مدیریت آسیب‌پذیری ManageEngine خدمات مشاوره، لایسنس، پیاده‌سازی، آموزش و پشتیبانی ارائه می‌کند. برای برآورد Edition و لایسنس نیز می‌توانید از استعلام قیمت محصولات ManageEngine استفاده کنید.

منابع

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

11

دیدگاه شما

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