معماری Zero Trust چیست؟ این معماری یک مدل امنیتی مدیریت و کنترل شبکه است. در این مدل امنیتی بصورت پیش فرض به هیچ ماشین، سرویس و یا شخصی اعتماد نمی‌شود و در تمام مراحل و از هر جایی کاربران و دستگاه‌ها باید احراز و تایید هویت شوند و دسترسی آن‌ها بصورت حداقل سطح دسترسی به منبع خاص مورد نیاز، تعریف می‌شود.
اهمیت این معماری به میزانی است که بعد از حملات عظیم سایبری روسیه به سازمان‌های آمریکایی در دسامبر ۲۰۲۰، مدیرعامل کلادفلر که یکی از بزرگترین شرکت‌های تامین کننده زیرساخت و امنیت برای وب سایت‌ها است، گفته که تنها راه پیش روی سازمان‌ها برای در امان ماندن از این حملات سنگین دولتی، استفاده از راهکار Zero Trust است.
فهرست مطالب
بیشتر بدانید:
- SDN چیست؟
- قابلیت جدید امنیتی در Google Cloud
- همکاری کلاودفلر و اپل در ساخت یک پروتکل جدید برای افزایش حریم خصوصی
NSX چیست؟
فرض کنید شما در داخل مرکز داده، چندین سرور ESXi دارید که ماشین‌های داخل آن‌ها دائماً با هم در ارتباط هستند. ترافیک بین آن‌ها از طریق پورت‌های Uplink بین سوئیچ‌های فیزیکی منتقل می‌گردد. حال ممکن است چندین مرکز داده داشته باشید در سرتاسر دنیا که در نتیجه ترافیک باید از روترها و فایروال‌های مختلف نیز عبور کند. NSX حرکتی از سوی شرکت VMware برای مجازی سازی شبکههای فیزیکی است که در واقع SDN شرکت VMware برای ورود به این عرصه است. استفاده از این محصول قابلیت‌های بسیار زیادی را ارائه می‌دهد که در اینجا به‌طور مفصل در رابطه با آن‌ها صحبت خواهد شد.
تامین امنیت با VMware NSX
برای اینکه با کاربردهای NSX و قابلیت zero trust در آن بیشتر آشنا شوید، مقدمه‌ای از چند بدافزار مشهور را بیان می‌کنیم تا بیشتر با مشکلاتی که در تامین امنیت در شبکههای سنتی وجود دارد، آشنا شوید.
بدافزاری که دنیا را در شوک فرو برد
شرکت مرسک (Maersk)، بزرگترین شرکت حمل و نقل دنیا، در ۶ تیر ۱۳۹۶ هدف یک malware قرار گرفت که بسیاری از سیستم‌های آی تی آن‌ها را از کار انداخت. در هر ۱۵ دقیقه چیزی بین ۱۰۰۰۰ تا ۲۰۰۰۰ کانتینر در یک اسکله تخلیه می‌شود و شرکت مرسک بیش از ۶۰۰ سایت در ۱۳۰ کشور دنیا در اختیار دارد. حالا تا حدودی می‌توانید پیچیدگی منطق سیستم نرم افزاری که این مراحل را در سرتاسر دنیا پردازش می‌کند، تصور کنید. آن‌ها چندین نرم افزار با نیازمندی‌های مختلف در چندین مرکز داده در سرتاسر دنیا دارند. عملیات sync بین این سیستم‌ها و اطمینان حاصل کردن از اینکه تنها کاربران معتمد می‌توانند وارد سیستم شوند، امری پیچیده است و نیاز به ماه‌ها وقت برای تنظیم دقیق مسائل امنیتی و تمرین‌های مختلف دارد، که تمامی آن‌ها در این شرکت انجام شده بود. پس مشکل از کجا بود؟
داستان از اینجا شروع شد که سیستم‌های مرسک در سرتاسر دنیا مبتلا به یک باج افزار (Ransomware) بنام NotPetya شدند. این باج افزار که سیستم عامل ویندوز را هدف قرار داده بود، از طرق مختلف مانند ایمیل و یا هر روشی که کاربر را وسوسه می‌کرد بر روی یک لینک کلیک کند، وارد سیستم شده و MBR سیستم را آلوده می‌کرد و با اجرای یک کد، کل هارد را رمزنگاری کرده و مانع بوت شدن سیستم می‌شد. متوقف کردن این نوع از حمله کار بسیار مشکلی است. تنها در شرکت مرسک بیش از ۵۰ هزار سیستم که شامل ۴۰۰۰ سرور بود به این باج افزار آلوده شدند که نتیجه آن ۳۰۰ میلیون دلار زیان بود.
باج افزار SamSam
این باج افزار نیز به مانند Notpetya از آسیب‌پذیری پورت‌ها استفاده می‌کرد و بیش از میلیون‌ها خسارت به چندین سازمان وارد کرد. این باج افزار پورت ۳۳۸۹ یعنی RDP را مورد هدف قرار می‌دهد، بدین صورت که با نرم افزارهای رایگان مختلفی که در این زمینه وجود دارد اقدام به اسکن سیستم‌های آسیب پذیر می‌کنند. بعد از یافتن آن‌ها، با استفاده از نرم افزارهایی مانند John the ripper یا Cain and abel اقدام به brute force password کرده و با دریافت مجوز نصب نرم افزار می‌توانستند اقدام به نصب ransomware کرده و یا از آن سیستم برای حملات DDoS به جاهای دیگر استفاده کنند.
نکتهای که وجود دارد اینست که برای این نوع از حملات نیازی به دانش خیلی بالا نیست برای مثال از سایت shodan.io می‌توان بسیاری از این آسیب پذیری‌ها را کشف کرد.
استفاده از دیوار قلعه (Castle wall) نیز به تنهایی نمی‌تواند مشکل را حل کنید، زیرا همچنان دروازه‌های این دیوار که همان پورت‌های باز لازم هستند و یا اتفاقی مشابه داستان Trojan horse که از طریق ارسال یک کادو به داخل، نفوذ انجام شد، می‌توانند آسیب پذیری‌های جدی برای ما ایجاد کنند.
ایران در رتبه اول بدافزارها
شرکت کسپرسکی در سال ۲۰۲۱ گزارشی از میزان حملات بدافزارها و باج افزارها در سطح دنیا ارائه نمود. بیشتر این حملات بر روی گوشی‌های موبایل انجام شده است. در کمال تعجب همانطور که در جدول زیر مشاهده می‌نمایید، ایران در رتبه اول از نظر میزان حملات قرار گرفته است. این به دلیل بستر ضعیف در داخل کشور است که باعث آسیب پذیری بالای آن می‌شود.
در زیر مراحل مختلفی که در این دسته از حملات وجود دارد را بیشتر مورد بررسی قرار می‌دهیم:
مرحله شناسایی (Reconnaissance)
هدف اصلی از این مرحله همانطور که از نام آن مشخص است، تعیین هدف حمله است که می‌تواند یک سازمان یا یک شخص خاص باشد.
اسکن کردن پورت‌ها و گرفتن دسترسی
بعد از شناسایی هدف، باید به دنبال ابزارهایی باشیم که عملیات اسکن کردن پورت‌های آسیب پذیر را انجام می‌دهند و از طریق آن‌ها وارد شبکه مورد نظر شویم. قبل از انجام این‌کار باید با استفاده از روش‌های مختلفی مانند Social engineering یا ایمیل، قربانی را وادار کنیم که بر روی لینک مورد نظر ما کلیک کرده تا کدهای لازم از طریق یک بدافزار در سیستم هدف نصب گردند. سازمان‌هایی که فرهنگ security-first دارند، ابزارهای مختلفی برای کشف این تهدیدها و ممانعت از آن‌ها دارند اما همچنان این حملات در سرتاسر دنیا انجام می‌شوند زیرا آموزش تهدیدات امنیتی به تمام پرسنل کاری بسیار دشوار است.
مدل معماری Perimeter Defense
این مدل معماری برای سالیان زیادی مورد استفاده قرار گرفته است و مفهوم آن بر اساس رویکرد Castle wall است. در این معماری یک خط دفاعی به نام فایروال قرار می‌دهیم و هر پکتی که وارد مرکز داده می‌شود ابتدا از آن فایروال عبور می‌کند. فایروال نیز می‌تواند بر اساس لایه ۴ یا ۷ کار کند که هر کدام مزیت‌ها و معایب مربوط به خود را دارد.
در روش سنتی زون‌های امنیتی مختلفی را بر اساس سطح تهدیدات و میزان حساسیت اطلاعات ایجاد می‌کنیم که از طریق آن سیستم‌ها را از یکدیگر جدا کرده کنترل بیشتری را بر روی آن‌ها اعمال می‌کنیم و مانع این می‌شویم که یک حمله به راحتی در تمام شبکه پخش شود.
در این معماری در سطوح بزرگ از فایروال‌های سخت افزاری مانند سیسکو استفاده می‌کنند. هر چند که نسخه‌های نرم افزاری آن نیز وجود دارد. امروزه سیستم‌های IDS/IPS نیز در فایروال‌ها ادغام شده‌اند که میزان امنیت آن‌ها را بسیار بالاتر برده است. در این روش پورت‌های آسیب پذیر برای کل مرکز داده بلاک می‌شوند که به مانند این است که کل یک پل که مسیر ورودی به شهر می‌باشد را ببندیم.
مکانیسم فیلترینگ در فایروال مبتنی بر IP است که با توجه به اینکه نیازی به هیچ بازرسی عمیقی از داخل پکت نیست، این رویکرد بسیار سریع و راحت است. اما با توجه به سطح تهدیدات جدیدی که وجود دارد نیاز به بازرسی‌های عمیق‌تر در لایه‌های ۴ و ۷ است که این امر توسط IDS/IPS انجام می‌شود.
استفاده از این معماری مزایای زیادی دارد که می‌تواند هر نوع حمله‌ای حتی حملاتی که روزانه پدیدار می‌شوند را تشخیص و خنثی سازند. معایب اصلی این روش نیز اخیراً و با توسعه معماری نرم افزارهای جدید، خود را نمایان ساخته است. آسیب پذیری‌های جدیدی ایجاد شده‌اند که سیستم موجود قادر به حل آن‌ها نیست.
یکی از مشکلات این روش برقرار بودن single point of failure است. یعنی اگر به هر شکل، قسمتی از این دیوار شکسته شود، کل مکانیزم دفاعی شهر فرو می‌ریزد و یا تصور کنیم مهاجم بتواند کنترل فایروال را در اختیار خود بگیرد. او به راحتی قادر خواهد بود قوانین را تغییر دهد و یا قوانین جدید ایجاد نماید. قرار دادن یک لایه امنیتی جدید مانند آنتی ویروس یا فایروال در سمت سرور که host-based firewall نامیده می‌شود نیز نمی‌تواند مشکلی را حل کند زیرا اگر یک پورت در فایروال باز یا بسته باشد، باید در سمت سرور نیز همان کار را انجام دهیم و آن‌ها قادر نیستند به سراغ فایروال رفته و سوال کنند که آیا واقعا آن پورت بسته است یا نه؟
تمرکز فایروال در این معماری بر روی ترافیک North-South است در حالی که بر اساس بررسی‌های انجام شده، نزدیک به ۷۷ درصد ترافیک بصورت East-West است که فایروال کنترل بسیار کمی بر روی آن دارد. همچنین با توسعه معماری میکروسرویس و طراحی جریان CI/CD اهمیت کنترل این نوع از ترافیک‌ها بسیار بیشتر شده است. در این حالت اگر مهاجم بتواند وارد شبکه شود ترافیک عبوری او دیگر east-west است که فایروال نمی‌تواند کنترلی بر روی آن داشته باشد. به همین دلیل اهمیت این دو نوع ترافیک با یکدیگر برابر است و باید به هر دو اهمیت داد.
اما معماری میکروسرویس چیست؟ در معماری سنتی (Monolithic) همه چیز حول یک نرم افزار است که بر روی یک سرور نصب می‌شود. در صورت نیاز به توسعه نیز، اقدام به افزایش منابع آن سرور می‌کنیم مانند اضافه کردن cpu یا RAM. اگر به هر دلیلی مشکلی در یک قسمت از سرور ایجاد شود، کل سرویس مورد نظر از کار می‌افتد. در صورتی که بخواهیم این سرویس را از حالت single point of failure خارج کنیم باید یک کپی دیگر از آن را در یک سرور دیگر قرار دهیم. اما مشکل این معماری همچنان پابرجاست، معماری رقیب که به عنوان یک جایگزین روش سنتی پدیدار شد با فرض اینکه قطعی سیستم یک مساله نرمال است پا به عرصه نرم افزار گذاشت. معماری میکروسرویس ساختار یک نرم افزار را به سرویس‌های کوچک تقسیم می‌کند و این سرویس‌ها از طریق یک رابط کاربری REST/RPC با یکدیگر ارتباط برقرار می‌کنند. در نتیجه این مساله انفجاری در ترافیک داخلی شبکه ایجاد می‌گردد که بدان معنی است که باید فیلترینگ این نوع از ترافیک در اولویت قرار گیرد.
استفاده از Cloud
امروزه استفاده از ابر عمومی یا خصوصی می‌تواند برای غلبه بر چالش‌های موجود بسیار موثر باشد. این ابرها دارای security group هستند که امکان فیلترینگ ترافیک را در سطح vNIC فراهم می‌کند. در مباحث آتی بیشتر به این موضوع خواهیم پرداخت که چگونه با استفاده از vmware می توان zero trust security را در cloud فراهم کرد. فرآیند اتوماتیک سازی ساخت تمامی زیرساخت‌ها در Cloud قابلیتی بسیار شگفت انگیز است. ساخت security group و policyها نیز جزئی از این فرآیند است. همچنین انتقال این policyها همراه با انتقال ماشین‌های مربوطه از یک مکان به مکان دیگر نیز امکان پذیر است.
Microsegmentation and Zero Trust
زمانی که این قابلیت را پیاده‌سازی می‌کنید تمامی ترافیک‌های ورودی و خروجی (ingress/egress) از vNIC با یک لیست policy در فایروال مقایسه می‌شوند. اگر با هیچ قانونی match نشوند drop می‌شوند زیرا یک default deny rule در انتهای این لیست قرار دارد. از دید امنیتی به این روش whitelisting می‌گویند.
اگر بخواهیم معماری zero trust را در پیکربندی سنتی perimeter-based پیاده‌سازی کنیم نیاز به زمان و کار بسیار زیادی داریم. حتی اگر بخواهیم از روش رایج ایجاد زون‌های مختلف و تعریف policy برای هر زون استفاده نماییم، باز با مشکل ارتباط باز بین سرورهای یک زون با یکدیگر مواجه خواهیم بود (رفتار پیش فرض) که ریسک بالایی دارد. در این سناریو هیچ راهی برای متوقف کردن دسترسی به پورت‌های باز یک سرور از طریق سایر سرورهای موجود در همان زون وجود ندارد. پس مشاهده می‌نمایید که چگونه وجود اعتماد حتی بین سرورهای موجود در یک زون، می‌تواند منجر به ایجاد یک فاجعه گردد.
در اینجا zero-trust قادر است تمامی این نگرانی‌ها را از بین ببرد. یکی از مزایای آن log شدن تمامی ترافیک است که کار را برای audit کردن بسیار راحت می‌کند. استفاده از نرم افزارهای مدرنی که قادرند گزارش‌های مفهومی ارائه دهند در این قسمت بسیار مهم است مانند نرم افزار VMware Log Insight که ابزاریست بسیار قدرتمند که قادر به تجزیه و تحلیل گزارش‌ها است و زندگی را برای شما راحت‌تر می‌کند.
رویکرد zero trust را بهتر است در یک محیط مجازی سازی شده استفاده کرد زیرا مزیت‌های زیادی در این حالت ارائه می‌دهد که در ادامه با آن‌ها آشنا خواهید شد. در این رویکرد یک مدیر شبکه می‌بایست نسبت به نرم افزارهای استفاده شده در سازمان و رفتارهای مختلفی که از خود نشان می‌دهند، دانش کافی داشته باشد. برای مثال آیا نرم افزار الف نیاز به نرم افزار ب دارد؟ آیا اگر هر دو نرم افزار در یک VLAN قرار دارند نیاز به ارتباط لایه ۲ نیز با هم دارند؟ این سوالات باید در مرحله طراحی پرسیده شوند و تنها زمانی که به تمام این سوالات پاسخ داده شد می‌بایست به مرحله بعد رفت زیرا بدلیل وجود deny rule در انتهای لیست اگر به این مرحله دقت نشود مشکلات بسیاری در آینده پیش می‌آید.
حتی زمانی که از این رویکرد استفاده می‌کنیم نیز نباید اقدام به حذف perimeter firewall کنیم. به عبارت دیگر حتی زمانی که به اندازه کافی قفل درها را محکم کرده‌اید باز نباید دیوار قلعه را تخریب کنید. گزینه‌های مختلفی در این حالت وجود دارد مانند استفاده از یک فایروال مجازی به عنوان یک VM و یا در صورت بالا بودن ترافیک ورودی و خروجی، استفاده از یک hardware appliance برای فایروال.
افزودن یک نرم افزار جدید به زیرساخت
این پروسه باید ساده، سرراست و اتوماتیک انجام شود. اگر قرار بر دستی انجام دادن امور امنیتی مربوط به نرم افزار جدید باشد، با یک حجم زیادی از مراحل کاری روبرو خواهیم شد که ما را در آینده با مشکل مواجه خواهد کرد. VMware این مشکل را با استفاده از تگ‌ها حل کرده است. نحوه عملکرد آن بدین صورت است که تمامی ماشین‌هایی که عضو یک tag مخصوص هستند یک مجموعه‌ای از optionها در یک security group به آن‌ها اعمال می‌شود. سپس آن مجموعه قوانین تعریف شده در تگ مربوطه، به vNIC اعمال می‌شود.
همچنین همانطور که می‌دانید امکان جابجایی ماشین‌های مجازی از یک مرکز داده به مرکز داده دوم در صورت استفاده از پیاده سازی دیتاسنتر Active/Active وجود دارد. در چنین طراحی وقتی پردازش یک ماشین به مرکز داده دوم منتقل می‌گردد، تمامی قوانینی که به vNIC آن اختصاص داده شده نیز منتقل می گردد. VMware از قابلیتی بنام distributed firewall rule برای انجام این‌کار استفاده می‌نماید.
VMware NSX
در حال حاضر Software-defined networking در حال تبدیل شدن به یک استاندارد است. این رویکرد با استفاده از رابط‌های API، قادر به جدا کردن سطح control plane از data plane است که این امکان را فراهم می‌کند که پیکربندی و اتوماتیک‌سازی زیرساخت شبکه بهتر انجام شود. در شبکههای سنتی دو سطح control و data در یک سوئیچ سخت افزاری مانند سیسکو ترکیب می‌شوند که این روش برای سال‌ها پاسخگوی زیرساخت بود اما با توسعه مجازی سازی دیگر جوابگوی ما نمی‌باشد.
VMware با استفاده از SDN stack قادر است اجزای زیرساخت مانند فایروال، روتر، load balancer و VPN را بصورت مجازی ارائه دهد.
Overlay Networking (SDN Overlay)
روشی است که در آن لایه‌هایی انتزاعی بر روی لایه physical network ایجاد می‌نماید. پروتکل‌های overlay نوعی پروتکل tunneling هستند که دارای آدرس آی پی مبدا و مقصد می‌باشد. رایج‌ترین پروتکل در این زمینه VXLAN است که شبکه‌ای مجازی از سوئیچ‌ها، روتر، فایروال‌ها و غیره را فراهم می‌نماید و به عنوان یک overlay network در VMware NSX مورد استفاده قرار می‌گیرد. به عبارت دیگر VXLAN یک پروتکل tunneling است که فریم‌های لایه ۲ را در پکت‌های UDP لایه سه encapsulate می‌کند. واحدی که کار encapsulate و decapsulate پکت را انجام می‌دهد VTEP (VXLAN tunnel endpoint) نامیده می‌شود که در هر هایپروایزر مستقر است. همچنین هر subnet لایه ۲ در VXLAN دارای یک شماره منحصر به فرد است که VNI (VXLAN network identifier) نامیده می شود که مانند همان VLAN ID می‌باشد. یکی از مزایای VXLAN این است که دیگر محدودیت ساخت VLAN را که ۴۰۹۶ می‌باشد را ندارد.
در مثال بالا وقتی VTEP1 یک اترنت فریم از VM1 که به VM3 آدرس‌دهی شده است، دریافت می‌کند، با استفاده از آدرس‌های VNI و آدرس MAC مقصد در forwarding table خود جستجو کرده تا VTEP مقصد را بیابد. سپس VTEP1 یک هدر VXLAN که شامل VNI می‌باشد را اضافه کرده و فریم را در یک پکت لایه سه encapsulate کرده و به سمت VTEP2 ارسال می‌کند. سپس VTEP2 فریم اصلی را decapsulate کرده و به VM3 تحویل می‌دهد. لازم به ذکر است که VM1 و VM3 هر دو از VXLAN Tunnel و حتی از پکت لایه ۳ بی‌اطلاع هستند.
VXLAN Headers
همانطور که در شکل زیر مشاهده می‌نمایید مهم‌ترین قسمت هدر VXLAN همان VNI است که ۲۴ بیت است که همانند VLAN tag (12بیت) عمل می‌نماید.
همانطور که در مثال زیر مشاهده می‌نمایید در این شبکه سه VXLAN با مشخصه‌های VNI1000، VNI2000 و VNI3000 وجود دارند که هر کدام به ماشین‌های مربوطه اختصاص داده شده‌اند. اگر نیاز باشد که یک پکت از یک VNI به یک VNI دیگر ارسال شود باید در هایپروایزری که پکت ایجاد شده، عملیات routing انجام گردد. DLR وظیفه مسیریابی را برعهده دارد.
Distributed Logical Router (DLR)
قابلیتی است در NSX که میزان routing traffic را در داخل مرکز داده کاهش می‌دهد زیرا به عنوان یک روتر مجازی عمل می‌کند. DLR به شکل یک ماژول کرنل در ESXi قرار گرفته است و مانع این می‌شود که یک پکت برای routing به فیزیکال روتر ارسال شود.
DLR دارای دو جزء می باشد:
DLR Kernel Module
این ماژول به عنوان data plane عمل می‌کند.
DLR Control VM
این ماشین مجازی نقش control plane را در DLR دارد و با استفاده از پروتکل‌های dynamic routing با NSX edges ارتباط برقرار می‌کند. در هنگام ساخت DLR این امکان را دارید که از control VM استفاده کنید یا خیر. Control VM دو قابلیت Dynamic Routing و L2 Bridging را فراهم می‌کند و اگر نیازی به استفاده از این ویژگی‌ها نمی‌بینید و می‌خواهید از static route استفاده نمایید، دیگر نیازی به Control VM ندارید.
اگر در ابتدا DLR خود را بدون Control VM ایجاد کرده‌اید و بعد از مدتی و با توسعه شبکه نیاز به نصب آن دارید، دیگر نمی‌توانید آنرا به DLR موجود اضافه نمایید و می‌بایست یا یک DLR جدید ساخته و سپس همه چیز را به آن migrate کنید و یا DLR موجود را پاک کرده و مجدد آن را ایجاد نمایید.
VMware NSX Distributed firewall (DFW)
DFW یک فایروال مبتنی بر کرنل است که در کرنل ESXi قرار می‌گیرد و به‌صورت stateful firewall عمل می‌کند. یعنی وضعیت sessionهای موجود که از طریق فایروال برقرار شده است را به خاطر می‌سپارد. قوانین آن به‌ازای هر vNIC اعمال می‌شود و هر پکت قبل از اینکه در DLR مسیریابی شود باید از این فایروال عبور نماید.
همچنین می‌توان فایروال‌های third-party را نیز با NSX ترکیب کرد مانند فایروال‌های IDS/IPS. محصولاتی مانند فایروال Palo Alto و Trend Micro این قابلیت را دارند.
DFW دارای دو table با نام‌های rule table و flow table است. تمامی قوانین در rule table قرار می‌گیرند که در انتهای آن نیز یک deny rule کلی به‌صورت پیش فرض قرار می‌گیرد که در واقع رویکرد zero trust را برای ما فراهم می‌نماید. در ادامه هر جریانی که permit می‌شود نیز در flow table کش شده که باعث می‌شود به پکت‌های برگشتی نیز اعمال شود. به‌دلیل اینکه این فایروال برای هر vNIC اعمال می‌شود در نتیجه ارتباط بین ماشین‌هایی که در یک VXLAN قرار دارند نیز می‌بایست از فایروال عبور کنند. در نتیجه این رویکرد، دیگر بدافزارهایی مثل Notpetya نمی‌توانند در داخل شبکه پخش شوند.
NSX Manager
اولین قدم در پیکربندی NSX نصب این پکیج است که بصورت یک قالب OVA ارائه شده است و مستقیماً در محیط VMware vSphere وارد می‌شود. در پیاده‌سازی‌های حرفه‌ای باتوجه به اینکه این پکیج در نقش سرویس مدیریت مرکزی SDN است، همواره توصیه شده است که از قابلیت HA و DRS نیز در محیط vSphere و در کنار NSX استفاده گردد. رابطه NSX با vCenter بصورت ۱:۱ است که یعنی تنها یک NSX Manager می‌تواند به یک vCenter پیوست شود و نه بیشتر. یک قالب NSX دارای یک UUID منحصر به فرد است که اگر دوباره همان قالب را import کنید مجدد همان UUID را می‌گیرد که در نتیجه دچار مشکل خواهیم شد.
در زیر پورت‌هایی را که NSX Manager استفاده می‌کند و باید قبل از نصب باز شوند را مشاهده می‌نمایید.
بعد از نصب می‌توانید به راحتی به رابط کاربری تحت وب آن متصل شوید. در صفحه اول می‌توانید وضعیت استفاده CPU/RAM را ببینید و همچنین سرویس‌های PostgreSQL (دیتابیس NSX) و (RabbitMQ (Massage broker را stop/start نمایید. گزینه‌های زیادی برای پیکربندی در داشبورد آن وجود دارد اما اولین قدم ادغام آن با VMware vSphere است. در تب Manage به راحتی با وارد کردن اطلاعات vCenter و نام کاربری تعریف شده در آن می‌توانید این دو را با هم integrate نمایید. اگر همه چیز درست باشد می‌توانید مشاهده نمایید گزینه NSX Manager در داشبورد vCenter سبز شده است و یک قسمت جدید بنام Networking and security نیز در vCenter اضافه می‌گردد.
پرسش و پاسخ
معماری Zero Trust چیست؟
این معماری یک روش سختگیرانه در شبکههای مجازی است که سطح امنیت را بسیار بالا میبرد. در این معماری هیچ سروری حتی در داخل یک شبکه، قابل اعتماد نیست و همه چیز باید بررسی شود.
آیا NSX مدلی از معماری Zero Trust است؟
بله، نرم افزار NSX یکی از بهترین راهکارهای شرکت VMware است که برای راه‌اندازی مدل Zero Trust ارائه شده است.
خرداد ۹۹
