در قسمت قبل در مورد مدل DFW Object Grouping و روش‌های متداول برای ساخت مجموعه قواعد امنیتی در چارچوب NSX DFW صحبت کردیم حال به ادامه موضوع خواهیم پرداخت. دو شیوه برای مصرف عملکردهای DFW وجود دارد که عبارت‌اند از Service Composer و جدول قواعد فایروال. هردوی این ابزارها از طریق Management Plane REST API نیز قابل پیکربندی هستند:
استفاده از Service Composer
باید روی Network & Security و سپس Service Composer کلیک شود تا دسترسی به جدول پالیسی امنیتی ایجاد گردد:
در این منو، باید یک پالیسی امنیتی یا SP ساخته شود. درون این SP، می‌توان قواعد پالیسی DFW را تعریف کرده و سپس آن‌ها را به یک گروه امنیتی اعمال کرد که حاوی VMهای مقصود هستند. در شکل زیر مثالی از گروه امنیت وب و پالیسی را مشاهده می کنید.
استفاده از جدول قواعد فایروال
باید روی Network & Security و سپس Firewall کلیک شود تا دسترسی به جدول قواعد فایروال ایجاد گردد.
در این منو، ادمین قاعده‌ی پالیسی امنیتی را به همان شکلی که در طرح قاعده‌ی استاندارد مورد نیاز است، وارد می‌کند:
نام قاعده / منبع / مقصد / سرویس / اقدام. جدول زیر جدول قاعده‌ی DFW را نشان می دهد.
| نام | ID قاعده | مبدأ | مقصد | سرویس | اقدام | اعمال شده به |
| APP Access | 1004 | همه | SG-APP-ALL | APP-SVG-ALL | اجازه | SG-APP-ALL |
در جدول زیر مقایسه‌ای بین دو روش انجام شده است.
| استفاده از Service Composer | استفاده از جدول قواعد فایروال | |
| قابلیت دید در جدول قواعد فایروال | ● | ● |
| قابلیت دید جدول قواعد فایروال روی یک VM | ● | ● |
| قابلیت دید جریان مسدودشده در مانیتورینگ جریان | ● | |
| اصلاح مستقیم قواعد فایروال | ● | |
| قابلیت استفاده‌ی مجدد از قاعده‌ی فایروال | ● | |
| درج سرویس | ● | |
| بررسی Guest | ● |
پیکربندی قاعده‌ی پالیسی DFW
استفاده از Service Composer: باید روی Networking & Security و سپس Service Composer کلیک شود تا بتوان به پالیسی امنیتی دسترسی پیدا کرد:
این پنجره تمام پالیسی‌های امنیتی یا SPها را نشان میدهد که تحت عنوان NSX تعریف شده‌اند. انتخاب یک پالیسی امنیتی به‌خصوص پنجره‌ای را باز می‌کند که محتویات SP را به شکل زیر نمایش میدهد:
در شکل بالا Service Composer، ساخت پالیسی امنیتی را مشاهده می کنید. برای ایجاد یک قاعده‌ی پالیسی جدید، باید روی کلید + که در شکل بالا نمایش داده شده است، کلیک نمود. سپس پنجره‌ی زیر نمایش داده می‌شود:
ادمین بخش‌های زیر را پر می‌کند:
- Name: نام قاعده‌ی فایروال
- Description: توصیف قاعده‌ی فایروال
- Action: اجازه دادن یا مسدود کردن
- Source / Destination: می‌تواند هر کدام از موارد جدول زیر را داشته باشد
در جدول زیر Service Composer – Source / Destination توضیح داده شده است.
| مورد | توصیف |
| گروه امنیتی پالیسی | در هنگام اعمال کردن پالیسی امنیتی به یک یا چند گروه امنیتی یا SG، این بخش جای خود را به SG یا SGهای اعمال‌شده خواهد داد. |
| هر کدام (Any) | هر کدام (Any) |
| انتخاب گروه‌های امنیتی | کاربران می‌توانند یک یا چند گروه امنیتی را انتخاب کنند (NSX تمام SGهای قابل‌دسترسی در سیستم را برای انتخاب فهرست می‌کند). |
تصویر زیر پنجره‌ی انتخاب Source / Destication را نشان میدهد:
| مورد | توصیف |
| هر کدام (Any) | هر سرویس (Any Service) |
| انتخاب سرویس‌ها و گروه‌های سرویس | سرویس‌ها و گروه‌های سرویس از پیش تعریف شده. |
در شکل زیر Service Composer، انتخاب سرویس و گروه‌های سرویس را نشان می دهد.
فرض می‌کنیم که سه مجموعه‌ی مختلف از قواعد برای WEB، APP و DB VMها داریم.
اولین قدم، تعریفِ گروه‌های امنیتی یا SGهای مناسب است. در جدول زیر، Service Composer گروه‌های امنیتی برنامه کاربردی 3 لایه را نمایش میدهد.
| نام SG | تعریف SG |
| SG-WEB | شمول ایستا: Web LS |
| SG-APP | شمول ایستا: App LS |
| SG-DB | شمول ایستا: DB LS |
فرض بر این است که می‌خواهیم قواعد DFW را برای تمام برنامه‌های کاربردی بسازیم تا:
- Web VMها فقط با استفاده از یک Enterprise Bus Service بتوانند با App VMها صحبت کنند.
- Web VMها نتوانند با DB VMها صحبت کنند.
- APP VMها فقط بتوانند از طریق SQL Service با DB VMها صحبت کنند.
بیشتر بخوانید: شرح و معرفی VMware NSX Distributed Firewall یا DFW و بررسی قواعد پالیسی امنیتی آن – قسمت اول
جدول زیر Service Composer، قواعد فایروال پالیسی امنیتی برنامه کاربردی 3 لایه را نشان می دهد.
| نام | مبدأ | مقصد | سرویس | اقدام |
| وب به APP | SG-WEB | گروه امنیتی پالیسی | <Enterprise Service Bus> | اجازه دادن |
| APP به DB | گروه امنیتی پالیسی | SG-DB | SQL | اجازه دادن |
| پیش‌فرض | هر کدام | هر کدام | هر کدام | مسدود کردن |
Production Zone درمقابل DevTest Zone
اگر برخی از VMها، VMهای تولیدی و برخی از آن‌ها VMهای DevTest باشند، فرض می‌کنیم که تمام VMهایی که با 01 شروع می‌شوند، VMهای تولیدی هستند هدف ما این است که قواعد بیشتری را اعمال کنیم، مثلاً اینکه هیچ VM تولیدی نباید با VMهای DevTest صحبت کند، در راهکار بالا، SGها و SPهای بیشتری ساخته خواهد شد. در جدول زیر، Service Composer، نمای گروه امنیتی نمایش داده شده است.
| نام SG | تعریف SG |
| SG-Prod | شمول پویا: تمام نام‌های VM که با «01» شروع می‌شوند |
| SG-WEB | شمول ایستا: Web LS استثنای ایستا: SG-Prod |
| SG-APP | شمول ایستا: App LS استثنای ایستا: SG-Prod |
| SG-DB | شمول ایستا: DB LS استثنای ایستا: SG-Prod |
| SG-DevTest | شمول ایستا: SG-WEB، SG-APP، SG-DB |
باید یک SP (SP-RESTRICT-PROD) ساخته شود تا دسترسی VMهای DevTest به تولید کاهش یابد. SP حاوی قاعده‌ای مثل قاعده‌ی زیر است: جدول زیر Service Composer، DevTest/ قواعد فایروال پالیسی امنیتی تولیدی نمایش داده شده اشت.
| نام | مبدأ | مقصد | سرویس | اقدام |
| تولید به DevTest | SG-Prod | گروه امنیتی پالیسی | هر نوع | بلاک |
| DevTest به | گروه | SG-Prod | هر نوع | بلاک |
ازآنجایی‌که SG-DevTest از SG-APP، SG-WEB، SG-DB تشکیل شده است، این پالیسی به دلیل وراثت پالیسی SG-DevTest، به‌طور خودکار به این SGها اعمال می‌شود. درنتیجه هیچکدام از VMها در آن گروه‌های امنیتی با VMهای تولیدی ارتباط برقرار نخواهند کرد. باید SP برای APP، همانطور که بالا نمایش داده شده ساخته شود. سپس باید به SG-APP اعمال گردد. اکنون SG-APP حاوی دو پالیسی خواهد بود – SP-RESTRICT-PROD و SP-APP.
استفاده از جدول قواعد فایروال
باید روی Networking & Security و سپس Firewall کلیک نمود تا دسترسی به جدول قواعد پالیسی DFW ایجاد گردد:
این پنجره نمایش میدهد که قواعد پالیسی که برای DFW و جستجوی Packet پیکربندی شده‌اند از بالا تا پایین اجرا می‌گردند. Packetهایی که با قاعده‌ی به‌خصوصی همخوانی نداشته باشند با قاعده‌ی پیش‌فرض اعمال می‌گردند که همیشه آخرین قاعده در جدول است. NSX دارای یک مجموعه قاعده‌ی پیش‌فرض است که اجازه‌ی اقدام را میدهد. کاربر اگر بخواهد، می‌تواند این قاعده را تغییر دهد تا اقدام به مسدود کردن کند. پیشنهاد VMware این است که از DFW با مجموعه قواعد پیشفرضی استفاده شود که روی مسدود کردن تنظیم شده است و بعد قواعد مشخصی را برای ترافیک مجاز ایجاد کند.
وقتی که از Objectهای vCenter در بخش مبدأ و مقصد استفاده شود، ضروری است که VMtools روی Guest VM نصب شده باشند. VMtools به DFW این توانایی را میدهد که آدرس‌های IP متعلق به Guest VM را بازیابی کنند تا قاعده‌ی امنیتی مناسبی را اعمال نمایند. اگر نتوان VMtools را روی یک Guest VM نصب کرد، باید در بخش مبدأ و مقصد از یک آدرس IP مشخص استفاده گردد تا ترافیک برای این VM ایمن گردد.
جدول زیر مقادیر مبدأ vCenter گروه امنیتی و تمام احتمالات را فهرست می‌کند:
| Object | شرح |
| کلاستر | تمام VM و vNICها در این کلاستر ESXi انتخاب می‌شوند. |
| دیتاسنتر | تمام VM و vNICها در این کلاستر دیتاسنتر انتخاب می‌شوند. |
| گروه پورت توزیعی | تمام VM و vNICهای متصل به این گروه پورت DVS انتخاب می‌شوند. |
| مجموعه‌های IP | Container مجموعه‌های IP مورداستفاده قرار می‌گیرند. مجموعه‌های IP حاوی آدرس‌های IP مجزا یا IP Subney یا Range یا چندین آدرس IP هستند. |
| گروه پورت قدیمی | تمام VM و vNICهای متصل به این گروه پورت VSS انتخاب می‌شوند. |
| سوئیچ منطقی | تمام VM و vNICهای متصل به این بخش سوئیچ منطقی (یا VXLAN) انتخاب می‌شوند. |
| Resource Pool | تمام VM و vNICهای تعریف شده در Resource Pool انتخاب می‌شوند. |
| تمام VM و vNICهای تعریف شده در گروه امنیتی انتخاب می‌شوند. | |
| vAPP | تمام VM و vNICهای تعریف شده در vAPP انتخاب می‌شوند. |
| ماشین مجازی | تمام VM و vNICها انتخاب می‌شوند. |
| vNIC | این Instance به‌خصوص از vNIC انتخاب می‌شود. |
سرویس: پروتکل‌های (TCP، UDP و غیره) یا خدمات از پیش تعریف‌شده یا گروه خدمات از پیش تعریف‌شده را می‌توان انتخاب کرد.
شکل 17 – مبدأ/مقصد: پروتکل‌ها
در هنگام انتخاب پروتکل‌هایی مثل TCP یا UDP، می‌توان تعداد پورت‌های مجزایی را تعریف کرد (حداکثر 15 مورد). کاربر می‌تواند پروتکل‌های دیگری مثل FTP، ICMP و ORACLE_TNS را انتخاب کند.
