0

راهنمای عملی اتصال DDI Central به Endpoint Central؛ از DHCP Lease و Device Context تا Patch، Vulnerability، Cluster Permission و ساخت Risk-aware IPAM.

شرکت مدانت
شرکت مدانت
[ مجری تخصصی پیاده‌سازی چارچوب ITIL و تحول دیجیتال ]
یکپارچه‌سازی DDI Central و Endpoint Central؛ از DHCP Lease تا Risk-aware IPAM

فرض کنید تیم شبکه یک IP مشکوک با آدرس 10.20.30.55 می‌بیند. در DHCP مشخص است این آدرس به چه MAC Addressی Lease شده، اما برای پاسخ به سؤال‌های بعدی باید بین چند ابزار جابه‌جا شد: این دستگاه دقیقاً چیست؟ چه سیستم‌عاملی دارد؟ آخرین بار چه زمانی Boot شده؟ Patchهای مهم آن نصب هستند؟ آسیب‌پذیری شناخته‌شده دارد؟ و اصلاً هنوز همان Endpointی است که تیم امنیت تصور می‌کند؟

در شبکه‌های بزرگ، مشکل فقط کمبود داده نیست؛ پراکنده بودن Context است. DNS و DHCP درباره Name و Address می‌دانند، IPAM درباره فضای آدرس، Subnet و Lease دید دارد و Endpoint Management درباره وضعیت سیستم‌عامل، Patch و Vulnerability. وقتی این اطلاعات کنار هم قرار نگیرند، یک Incident ساده می‌تواند به چند تماس، چند پنل و چند فرضیه تبدیل شود.

یکپارچه‌سازی ManageEngine DDI Central و Endpoint Central برای حل همین شکاف طراحی شده است. DDI Central می‌تواند اطلاعات Lease و IP را با Context واقعی Endpoint همبسته کند تا IPAM از یک فهرست آدرس به یک ابزار عملیاتی و امنیتی تبدیل شود؛ مدلی که ManageEngine از آن با عنوان Risk-aware IPAM یاد می‌کند.

اگر با مفهوم DDI آشنایی اولیه ندارید، ابتدا مقاله DDI چیست؟ را بخوانید. برای معرفی خود محصول نیز صفحه ManageEngine DDI Central در مدانت نقطه شروع مناسبی است.

Risk-aware IPAM یعنی چه؟

در IPAM سنتی معمولاً می‌دانیم یک IP در چه Subnetی قرار دارد، Free است یا Used، از DHCP آمده یا Static است و چه Lease Historyای داشته است. این اطلاعات برای عملیات شبکه ضروری‌اند، اما به‌تنهایی پاسخ نمی‌دهند که Endpoint پشت این IP از نظر امنیت و سلامت چه وضعیتی دارد.

Risk-aware IPAM یک لایه Context به IP Address Management اضافه می‌کند. یعنی وقتی یک Lease را می‌بینیم، بتوانیم آن را به اطلاعات Endpoint مرتبط کنیم و در تصمیم‌گیری از داده‌هایی مثل OS، Device Identity، Patch Status و Vulnerability Context هم استفاده کنیم.

سؤال عملیاتی IPAM بدون Endpoint Context DDI Central + Endpoint Central
این IP متعلق به چه دستگاهی است؟ معمولاً MAC/Lease/Hostname Device Context کامل‌تر شامل OS، IP، MAC و Last Boot
دستگاه از نظر Patch چه وضعیتی دارد؟ نیاز به ابزار جداگانه Patch Context در کنار Endpoint قابل مشاهده است
این Endpoint آسیب‌پذیر است؟ نامشخص Vulnerability Context برای تصمیم سریع‌تر
برای Incident باید کجا برویم؟ چند Console Correlation از Lease به Endpoint
آیا باید این Lease را جدی‌تر بررسی کنیم؟ بر اساس IP و رفتار شبکه بر اساس IP + وضعیت Endpoint

این مدل قرار نیست SIEM، EDR یا NAC را حذف کند. ارزشش این است که تیم شبکه هنگام مشاهده IP، Lease یا Subnet، Context امنیتی و سیستمی بیشتری داشته باشد و سریع‌تر تشخیص دهد کدام مورد نیاز به بررسی جدی دارد.

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

DDI Central سه سرویس اصلی شبکه یعنی DNS، DHCP و IPAM را در یک Console یکپارچه می‌کند. این محصول می‌تواند به‌صورت Overlay روی DNS/DHCP موجود قرار گیرد یا در سناریوهای مشخص، سرویس‌های DNS و DHCP را از طریق خود پلتفرم مدیریت کند. در محیط‌های Microsoft و Linux، مدل Discovery و مدیریت بسته به معماری سازمان قابل انتخاب است.

در بخش IPAM، DDI Central روی Visibility فضای آدرس، Subnet، Lease، Allocation و Relation میان DNS/DHCP/IP تمرکز دارد. در نسخه‌های جدید، IPAM Tower نیز برای نمایش Site، Cluster، Supernet، Subnet و VLAN توسعه یافته است؛ قابلیتی که برای سازمان‌های چندسایتی و IP Estateهای بزرگ اهمیت زیادی دارد.

اما DDI به‌تنهایی نمی‌داند Endpoint پشت یک Lease چه Patchهایی کم دارد یا از نظر Endpoint Security در چه وضعیتی است. اینجاست که Endpoint Central وارد معماری می‌شود.

Endpoint Central چه Contextی به DDI اضافه می‌کند؟

Endpoint Central یک پلتفرم Unified Endpoint Management and Security است و اطلاعاتی درباره Device، سیستم‌عامل، Patch، Vulnerability و وضعیت Endpointها نگهداری می‌کند. در Integration رسمی، DDI Central می‌تواند بخشی از این Context را در کنار داده‌های Lease و IP نمایش دهد.

طبق مستند فعلی ManageEngine، بعد از اتصال Endpoint Central، در بخش Devices می‌توان اطلاعاتی مانند OS، IP Address، MAC Address و Last Boot Time را مشاهده کرد. همچنین در صفحه DHCP Lease، برای Endpointهایی که داده آن‌ها از Endpoint Central دریافت شده، علامت Monitor نمایش داده می‌شود تا Administrator بفهمد Lease موردنظر Endpoint Context دارد.

در Overview رسمی Integration نیز ManageEngine به مشاهده Device Health، Vulnerability و Patch Status در کنار اطلاعات شبکه اشاره می‌کند. این یعنی Investigation از «این IP چیست؟» به «این IP مربوط به چه Endpointی است و وضعیت آن چطور است؟» ارتقا پیدا می‌کند.

سناریو ۱: یک IP مشکوک در شبکه پیدا شده است

فرض کنید SOC یا NOC گزارش می‌دهد یک IP داخلی حجم غیرعادی DNS Query ایجاد کرده است. بدون Integration، مسیر بررسی ممکن است این‌طور باشد:

  1. پیدا کردن Lease در DHCP.
  2. بررسی MAC Address.
  3. پیدا کردن Device در Asset Inventory.
  4. ورود به Endpoint Management.
  5. بررسی OS و Patchها.
  6. بررسی Vulnerability یا Incidentهای مرتبط.

در معماری یکپارچه، Lease نقطه شروع Investigation است. Network Admin می‌تواند سریع‌تر Device Context را ببیند و تشخیص دهد آیا این Endpoint یک سیستم شناخته‌شده و سالم است یا دستگاهی با Patch Gap و Vulnerability Context که باید اولویت بالاتری بگیرد.

نکته مهم این است که IP به‌تنهایی Identity پایدار نیست. DHCP Lease تغییر می‌کند، Device جابه‌جا می‌شود و در شبکه‌های Dynamic یک آدرس ممکن است در زمان‌های مختلف به چند Endpoint تخصیص یابد. ترکیب Lease History با Device Context احتمال تصمیم‌گیری اشتباه را کمتر می‌کند.

سناریو ۲: CVE مهم منتشر شده و باید بدانیم کدام Endpoint فعال است

فرض کنید تیم امنیت فهرستی از Endpointهای آسیب‌پذیر دارد. اما برای عملیات شبکه یک سؤال دیگر مهم است: کدام‌یک از این سیستم‌ها همین حالا روی Subnetهای حساس Lease فعال دارند؟

Integration بین DDI Central و Endpoint Central می‌تواند Patch/Vulnerability Context را به Lease View نزدیک کند. این موضوع برای اولویت‌بندی Remediation مفید است، چون یک Endpoint آسیب‌پذیر که در یک Segment حساس فعال است، ممکن است از نظر عملیاتی مهم‌تر از سیستمی باشد که خاموش یا خارج از Scope شبکه Production است.

برای طراحی مدل اولویت‌بندی آسیب‌پذیری، مقاله Risk-Based Vulnerability Management در Vulnerability Manager Plus را هم ببینید؛ آن مقاله روی CVSS، KEV، Exploitability و Remediation Priority تمرکز دارد. DDI Context می‌تواند یک لایه شبکه‌ای به همین تصمیم اضافه کند.

سناریو ۳: یک Endpoint ناشناخته به DHCP وصل شده است

یکی از موارد رایج در شبکه‌های بزرگ، Endpointهایی هستند که Lease دارند اما در Inventory سازمانی Context کافی برایشان وجود ندارد. این اختلاف می‌تواند دلایل بی‌خطر یا مهم داشته باشد:

  • سیستم جدید هنوز در Endpoint Central Onboard نشده است.
  • BYOD یا دستگاه مهمان وارد شبکه شده است.
  • Asset Record قدیمی یا ناقص است.
  • Agent حذف شده یا دستگاه Reimage شده است.
  • یک Device غیرمجاز واقعاً به Segment سازمانی متصل شده است.

وقتی DDI Lease با Endpoint Database Correlate می‌شود، همین «نبودن Context» خودش یک Signal عملیاتی می‌شود. هدف این نیست که هر Device ناشناخته را Threat بدانیم؛ هدف این است که Unknown Endpoint سریع‌تر قابل شناسایی و بررسی باشد.

سناریو ۴: عیب‌یابی Branch یا Site دورافتاده

در شعب، مشکل ارتباطی ممکن است میان DNS، DHCP، Endpoint یا خود Network Path باشد. Administrator اگر فقط DHCP را ببیند، شاید Lease سالم به نظر برسد اما Endpoint به دلیل Patch، OS یا Boot State مشکل داشته باشد. برعکس، Endpoint ممکن است سالم باشد اما Scope به آستانه Exhaustion رسیده باشد.

DDI Central برای Site، Cluster، Subnet و Supernet Visibility طراحی شده و Integration با Endpoint Central کمک می‌کند تیم شبکه در همان Context شعبه، وضعیت Deviceها را هم بررسی کند. این ترکیب برای سازمان‌هایی با شعب زیاد، فروشگاه‌های زنجیره‌ای، مراکز آموزشی یا شبکه‌های توزیع‌شده ارزش بیشتری دارد.

این Integration چه داده‌هایی را نشان می‌دهد؟

مستند فعلی ManageEngine حداقل این اطلاعات Device را در Integration ذکر می‌کند:

  • Operating System
  • IP Address
  • MAC Address
  • Last Boot Time
  • Endpoint Health Context
  • Vulnerability Information
  • Patch Status

در Overview رسمی همچنین امکان مشاهده اطلاعات Missing Patch بر اساس Severity و جزئیات Vulnerability برای تصمیم‌گیری سریع‌تر مطرح شده است. Scope دقیق داده و Actionها ممکن است با Build و Edition تغییر کند؛ بنابراین قبل از طراحی Runbook سازمانی، Build واقعی DDI Central و Endpoint Central را با مستندات همان نسخه تطبیق دهید.

Integration چگونه پیکربندی می‌شود؟

فرآیند کلی در DDI Central از بخش Settings و تنظیم Endpoint Central انجام می‌شود. نوع Credential به مدل Deployment بستگی دارد:

Endpoint Central روش اتصال نکته
On-Premises Username / Password و URL دسترسی Service Account را حداقلی نگه دارید
Cloud Client ID / Client Secret و URL Zoho API Console باید Region صحیح را داشته باشد

بعد از تعریف Connection، DDI Central اجازه می‌دهد Scope نمایش داده‌ها را با Cluster Permissions محدود کنید. می‌توان همه Subnetها یا فقط Subnetهای مشخص را انتخاب کرد. این قابلیت برای Least Privilege مهم است؛ یک تیم شعبه لزوماً نباید Endpoint Context تمام شبکه را ببیند.

Cluster Permission را جدی بگیرید

Integration خوب فقط درباره «داده بیشتر» نیست؛ درباره دسترسی درست به داده هم هست. وقتی IPAM و Endpoint Security Context کنار هم قرار می‌گیرند، اطلاعات حساس‌تری در Console شبکه دیده می‌شود. بنابراین Scope باید بر اساس نقش و مسئولیت تعریف شود.

یک مدل پیشنهادی:

نقش Scope پیشنهادی
Network Operations مرکزی تمام Clusterهای تحت مسئولیت
Branch IT فقط Subnetهای همان Site
SOC Analyst Read-only Context موردنیاز Investigation
Help Desk داده محدود برای Troubleshooting Endpoint
Vendor حداقل Scope موقت و قابل Audit

اصل ساده است: Integration نباید بهانه‌ای برای ساخت یک Super Admin جدید باشد.

آیا DDI Central جای NAC را می‌گیرد؟

خیر. این یکی از مرزهایی است که باید شفاف باشد.

NAC معمولاً روی Authentication، Admission Control، Network Access Policy و Enforcement تمرکز دارد. DDI Central روی DNS، DHCP و IPAM متمرکز است و Integration با Endpoint Central به آن Context بیشتری برای Visibility و تصمیم‌گیری می‌دهد.

ManageEngine در معرفی Integration توضیح می‌دهد که Administrator می‌تواند Endpointهای پرریسک یا Unpatched را سریع‌تر شناسایی کند و از اطلاعات Lease برای Containment Decision استفاده کند. اقداماتی مثل Revoke کردن Lease یا اعمال کنترل DNS باید در چارچوب Policy و Runbook سازمان اجرا شوند؛ Integration را نباید به‌اشتباه یک NAC کامل یا EDR Enforcement Engine تصور کرد.

آیا DDI Central جای SIEM را می‌گیرد؟

خیر. SIEM برای جمع‌آوری Log، Correlation، Detection و Incident Investigation در سطح وسیع‌تر طراحی شده است. DDI Context می‌تواند برای SOC بسیار مفید باشد، اما معماری درست معمولاً این‌طور است:

SIEM تشخیص می‌دهد → DDI هویت و Lease Context شبکه را روشن می‌کند → Endpoint Central وضعیت Endpoint را نشان می‌دهد → تیم عملیات یا امنیت Action مناسب را اجرا می‌کند.

ارزش Integration در کوتاه کردن همین زنجیره است، نه حذف ابزارهای تخصصی.

Risk-aware IPAM چه کمکی به Incident Response می‌کند؟

در Incident Response، زمان زیادی صرف پیدا کردن پاسخ سؤال‌های پایه می‌شود:

  • این IP الان متعلق به چه Endpointی است؟
  • در زمان Incident چه Leaseای داشته؟
  • سیستم‌عامل آن چیست؟
  • آیا Patch مهمی کم دارد؟
  • آیا Endpoint در Inventory سازمان شناخته شده است؟
  • این دستگاه در کدام Site و Subnet است؟

هرچه این Context سریع‌تر فراهم شود، MTTA و زمان اولیه Investigation کمتر می‌شود. DDI Central با Lease History و IP Context و Endpoint Central با Device/Patch/Vulnerability Context دو بخش مکمل این تصویر هستند.

Use Case مهم: اختلاف میان DHCP Lease و Endpoint Inventory

یکی از KPIهای مفید بعد از راه‌اندازی Integration، درصد Leaseهایی است که Endpoint Context معتبر دارند.

مثلاً:

  • کل Lease فعال: ۱۲٬۰۰۰
  • Lease دارای Endpoint Context: ۱۰٬۸۰۰
  • Lease بدون Endpoint Context: ۱٬۲۰۰

این ۱۲۰۰ مورد الزاماً Incident نیستند، اما یک Backlog ارزشمند برای Asset Hygiene ایجاد می‌کنند. بخشی ممکن است Printer، IoT یا BYOD باشد و بخشی Endpointهایی که باید در UEM Onboard شوند.

چطور Rollout را بدون ایجاد پیچیدگی شروع کنیم؟

برای سازمان بزرگ، یکپارچه‌سازی کل IP Estate در مرحله اول توصیه نمی‌شود. بهتر است یک Scope واقعی و قابل اندازه‌گیری انتخاب شود.

مرحله اول: یک Site یا VLAN مهم

مثلاً VLAN کاربران واحد مالی یا یک شعبه با ۲۰۰ Endpoint.

مرحله دوم: Correlation Quality را اندازه بگیرید

بررسی کنید چند درصد Leaseها به Endpoint معتبر Match می‌شوند و علت Unmatchedها چیست.

مرحله سوم: یک Runbook واقعی تعریف کنید

مثلاً: «اگر Endpoint دارای High-risk Vulnerability و Lease فعال در VLAN حساس بود، Ticket امنیتی ایجاد و Owner مطلع شود.»

مرحله چهارم: Scope Permission را محدود کنید

فقط تیم‌های لازم به همان Cluster/Subnet دسترسی داشته باشند.

مرحله پنجم: بعد از Pilot گسترش دهید

وقتی Mapping و Workflow پایدار شد، Siteهای بعدی اضافه شوند.

KPIهای پیشنهادی برای سنجش نتیجه

KPI هدف
Lease-to-Endpoint Correlation Rate درصد Leaseهایی که Device Context معتبر دارند
Unknown Active Lease Count کاهش Deviceهای بدون Inventory Context
High-risk Endpoint with Active Lease اولویت‌بندی Remediation روی سیستم‌های واقعاً فعال
Mean Time to Identify Device کاهش زمان پیدا کردن Endpoint پشت IP
Investigation Console Hops کاهش جابه‌جایی بین ابزارها
Stale Lease / Inventory Mismatch بهبود Data Hygiene

اگر فقط تعداد Integrationها را اندازه بگیرید، موفقیت واقعی را نمی‌بینید. معیار بهتر این است که Investigation و Asset Hygiene چقدر بهتر شده است.

DDI Central 2026 چه تغییر مهمی داشته است؟

DDI Central در ۲۰۲۶ چند تغییر مهم داشته است. در Build 6100 مورخ ۱۰ مارس ۲۰۲۶، IPAM Tower برای Visibility عمیق‌تر Site، Cluster، Supernet و Subnet توسعه یافت و قابلیت‌های VLAN و Import گسترده IP Estate اضافه شد. این تغییرات برای سازمان‌هایی که می‌خواهند DDI را در مقیاس چندسایتی استفاده کنند مهم‌اند.

از نظر امنیت نیز Release Notes رسمی Build 6301 در ۴ اوت ۲۰۲۶ چند اصلاح مهم Authentication، Authorization و Input Validation را ثبت کرده است. اگر Build محیط شما قدیمی‌تر است، قبل از توسعه Integration یا افزایش Scope، Release Notes و Upgrade Path را بررسی کنید. خود پلتفرم DDI بخشی از زیرساخت حیاتی شبکه است و Patch Management آن نباید عقب بیفتد.

DDI Central و Endpoint Central در معماری بزرگ‌تر مدانت

این Integration زمانی بیشترین ارزش را دارد که به‌عنوان بخشی از یک Architecture دیده شود:

  • DDI Central: DNS، DHCP، IPAM و Network Address Context
  • Endpoint Central: Device Management، Patch، Vulnerability و Endpoint Context
  • Vulnerability Manager Plus: Risk-based Vulnerability Remediation
  • OpManager: Availability و Network Performance Context
  • SIEM/Log360: Event Correlation و Security Analytics
  • Service Desk: Incident، Change و Workflow

DDI Central در قابلیت‌های فعلی خود Integration با Endpoint Central و OpManager را ارائه می‌کند. در نتیجه می‌توان از یک DHCP Lease به Endpoint Health یا Network Monitoring Context نزدیک شد؛ مدلی که Troubleshooting را از یک مسیر خطی و دستی به Context Correlation تبدیل می‌کند.

قبل از خرید یا پیاده‌سازی چه چیزهایی را مشخص کنیم؟

برای برآورد درست Scope، فقط تعداد DNS Serverها را نپرسید. این موارد را هم مشخص کنید:

  • چند DNS/DHCP Cluster دارید؟
  • چند Site و Branch باید مدیریت شوند؟
  • Windows، Linux یا هر دو در Scope هستند؟
  • چند Subnet و Supernet دارید؟
  • آیا IPv6 در برنامه است؟
  • Endpoint Central Cloud است یا On-Premises؟
  • کدام تیم‌ها باید Endpoint Context را ببینند؟
  • آیا Integration با OpManager هم لازم است؟
  • هدف اصلی Visibility است، Security Response است یا IPAM Governance؟

این پاسخ‌ها روی Edition، معماری Deployment، Permission Model و حجم پروژه اثر می‌گذارند. برای برآورد لایسنس و انتخاب Scope می‌توانید از صفحه استعلام قیمت لایسنس محصولات ManageEngine استفاده کنید.

Checklist پیشنهادی پیاده‌سازی

  • DNS/DHCP/IPAM Inventory موجود را مستند کنید.
  • Site، Cluster، Subnet و Supernetها را پاک‌سازی کنید.
  • Endpoint Central Inventory را از نظر Duplicate/Stale Device بررسی کنید.
  • یک Pilot Scope کوچک انتخاب کنید.
  • نوع اتصال Cloud/On-Premises را مشخص کنید.
  • Cluster Permission را بر اساس Least Privilege تنظیم کنید.
  • Lease-to-Endpoint Mapping را نمونه‌برداری و اعتبارسنجی کنید.
  • Unknown Endpointها را طبقه‌بندی کنید.
  • Runbook برای High-risk Active Endpoint تعریف کنید.
  • Build و Security Patchهای DDI Central را بررسی کنید.
  • KPI قبل و بعد از Integration را ثبت کنید.
  • بعد از Pilot، Scope را مرحله‌ای گسترش دهید.

نکات کلیدی

  • DDI Central آدرس و Lease را می‌بیند؛ Endpoint Central وضعیت Device، Patch و Vulnerability را به این Context اضافه می‌کند.
  • Risk-aware IPAM یعنی تصمیم‌گیری درباره IP فقط بر اساس Address انجام نشود و Endpoint Risk هم وارد Context شود.
  • Integration از Endpoint Central Cloud و On-Premises پشتیبانی می‌کند، اما روش Credential و API متفاوت است.
  • Cluster Permission برای محدود کردن Scope نمایش Endpoint Data اهمیت زیادی دارد.
  • این Integration جای NAC، SIEM یا EDR را نمی‌گیرد؛ Context میان Network و Endpoint را غنی می‌کند.
  • Build 6301 در ۴ اوت ۲۰۲۶ اصلاحات امنیتی مهمی برای DDI Central داشته است؛ نسخه محیط را قبل از Rollout بررسی کنید.

سخن پایانی

در شبکه مدرن، دانستن اینکه «این IP استفاده شده است» دیگر کافی نیست. تیم عملیات باید بداند چه دستگاهی پشت IP قرار دارد، در چه Site و Subnetی است، چه وضعیتی دارد و آیا از نظر Patch یا Vulnerability نیاز به اقدام سریع دارد.

یکپارچه‌سازی DDI Central و Endpoint Central همین شکاف را هدف می‌گیرد: DDI Context را از DNS/DHCP/IPAM می‌آورد و Endpoint Central Device/Risk Context را اضافه می‌کند. نتیجه می‌تواند Investigation سریع‌تر، Inventory دقیق‌تر و اولویت‌بندی بهتر Endpointهای فعال و پرریسک باشد.

اگر می‌خواهید Scope مناسب DDI Central، نحوه اتصال به Endpoint Central و معماری چندسایتی سازمانتان را ارزیابی کنید، مدانت خدمات مشاوره، لایسنس، پیاده‌سازی، آموزش و پشتیبانی ارائه می‌کند. برای بررسی سناریوی واقعی می‌توانید از درخواست جلسه و پروپوزال مدانت استفاده کنید یا برای نگهداری پس از استقرار، برنامه‌های پشتیبانی مدانت را ببینید.

منابع

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

دیدگاه شما

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