NSX Distributed Firewall یا DFW قابلیت اعمال عملکرد فایروال را به‌طور مستقیم در لایه‌ی vNIC از یک ماشین مجازی یا VM فراهم می‌کند. DFW جزء اصلیِ مدل امنیت ریزبخش‌بندی است که در آن می‌توان ترافیک East-West را دید، بررسی کرد و نزدیک به نرخ خط Line Rate اعمال نمود و این امر به پیشگیری از انواع حملات جانبی کمک می‌کند.
در این مقاله جزئیاتی را در مورد نحوه‌ی پیکربندی و ایجاد و استفاده از قواعد DFW ارائه می‌دهد. در بخش اول در مورد ایجاد قواعد با استفاده از ابزاری مثل DFW Rule Table و Service Composer، قابلیت‌های گسترده‌ی آگاهی از ساختار Layer 7 صحبت می‌شود و در نهایت به قابلیت‌های پیشنهاد خودکارسازی‌شده در NSX 6.4 با Application Rule Manager پرداخته خواهد شد.
اکنون Distributed Firewall قابلیت‌های گسترده‌ی آگاهی از ساختار Layer 7 را ارائه می‌دهد که برای ادمین‌ها توانایی کنترل کردن پالیسی‌های امنیتی را برای ارتباط East-West در دیتاسنتر با استفاده از ساختاری فراتر از روش‌های Layer2-4 فراهم می‌نماید. Application Rule Manager به ادمین‌ها توانایی پیشنهاداتی را برای مجموعه قواعد ریزپیکربندی براساس جریان‌های ترافیکی می‌دهد که در طول مانیتورینگ مشاهده شده‌اند و بیش‌ازپیش عملیات Day 2 را با NSX تسهیل می‌کنند. در اینجا فرض بر این است که فرد مطالعه‌کننده اطلاعاتی در مورد اهداف NSX، DFW و Service Composer دارد.
مدل DFW Object Grouping
مهم است روش‌هایی که می‌توان برای ساخت پالیسی‌های NSX DFW مورداستفاده قرار داد، درک شوند. تمام پالیسی‌ها برای وضعیت یا پیکربندی یکسانی از برنامه‌های کاربردی، زیرساخت یا شبکه‌ی سازمان مورداستفاده قرار نمی‌گیرند. در بخش زیر هر یک از این روش‌ها بررسی شده و کاربرد مناسب آن‌ها موردتوجه قرار می‌گیرد.
روش‌های متداول برای ساخت مجموعه قواعد امنیتی در چارچوب NSX DFW
برنامه کاربردی
در این رویکرد، گروه‌بندی براساس نوع برنامه کاربردی مثلاً VMهایی که به‌عنوان Web_Servers، Tagشده‌اند، محیط برنامه کاربردی، مثلاً تمام منابعی که به‌عنوان Production_Zone، Tagشده‌اند و وضعیت امنیتی برنامه کاربردی است. مزیت این رویکرد این است که وضعیت امنیتی برنامه‌ی کاربردی به ساختار یا زیرساخت شبکه وابسته نیست. پالیسی‌های امنیتی فارغ از محدوده‌های شبکه یا زیرساخت، با برنامه‌های کاربردی قابل جابه‌جایی هستند. می‌توان برای پالیسی‌ها Template ساخت و روی Instanceهایی از نوع‌های یکسان برنامه‌های کاربردی و بارهای کاری، از آن‌ها استفاده‌ی مجدد نمود. می‌توان از انواعی از مکانیزم‌ها برای گروه‌بندی استفاده نمود. تیم امنیتی تنها باید از برنامه کاربردی آگاهی داشته باشد که بر اساس پالیسی‌ها ایمن‌سازی شود. پالیسی‌های امنیتی چرخه‌ی عمر برنامه کاربردی را دنبال می‌کنند، یعنی وقتی برنامه‌ی کاربردی پیاده‌سازی می‌شود، فعال می‌گردند و وقتی که برنامه‌ی کاربرد از دسترس خارج می‌شود، غیرفعال می‌گردد.
زمانی که نباید از این رویکرد استفاده کرد: اگر محیط ایستا و بدون حرکت باشد و عملکردهای زیرساخت به‌خوبی محدود شده باشند. در این صورت نیاز به استفاده از پالیسی‌های مبتنی بر برنامه کاربردی نیست.
رویکرد پالیسی مبتنی بر برنامه کاربردی کمک بزرگی به حرکت به سمت مدل Self-Service IT می‌کند. تیم امنیتی فقط باید آگاه باشد که چطور یک برنامه‌ی کاربردی را ایمن کند، بدون اینکه توپولوژی زیرین را بشناسد. قواعد امنیتی دقیق و با قابلیت استفاده‌ی مجدد نیازمند آگاهی از برنامه کاربردی خواهد بود. درنتیجه یک وضعیت امنیتی مناسب را می‌توان از طریق پالیسی‌های مبتنی بر برنامه کاربردی توسعه داد.
زیرساخت
در این رویکرد، گروه‌بندی براساس زیرساخت‌هایی مثل کلاسترهای vCenter، سوئیچ‌های منطقی، گروه‌های پورت توزیعی و غیره. مثالی از این موضوع این است که کلاسترهای 1 تا شماره4 برای برنامه‌های کاربردی PCI تعیین می‌شوند. در چنین موردی، گروه‌بندی را می‌توان براساس نام‌ها انجام داد و قواعد کلاستر را می‌توان براساس این گروه‌ها اعمال نمود. مثال دیگری از این موضوع، می‌تواند این باشد که کاربر بداند کدام سوئیچ‌های منطقی در محیط به کدام برنامه‌های کاربردی متصل هستند. مثلاً سوئیچ منطقی App Tier حاوی تمام VMهایی باشد که به برنامه کاربردی X وابسته هستند. تیم امنیتی باید همکاری نزدیکی با تیم مدیریتی vCenter داشته باشد تا محدودیت‌های منطقی و فیزیکی را درک کند.
زمانی که نباید از این رویکرد استفاده کرد: اگر هیچ محدودیت فیزیکی یا منطقی در محیط وجود نداشته باشد، این رویکرد مناسب نیست. همچنین باید بسیار مراقب بود که در کجا می‌توان برنامه‌های کاربردی خود را پیاده‌سازی کرد. مثلاً اگر فردی بخواهد یک بار کاری PCI را به هر کلاستری که دارای منابع رایانشی کافی باشد پیاده‌سازی کند، وضعیت امنیتی نمی‌تواند به یک کلاستر وابسته باشد، بلکه باید با برنامه کاربردی جابه‌جا شود.
شبکه
این رویکرد قدیمی به گروه‌بندی براساس عناصر L2 و L3 است. گروه‌بندی می‌تواند براساس آدرس‌های MAC یا IP یا ترکیبی از هر دو باشد. NSX از این رویکرد برای گروه‌بندی Objectها پشتیبانی می‌کند. تیم امنیتی باید از زیرساخت شبکه آگاه باشد تا پالیسی‌های مبتنی بر شبکه را پیاده‌سازی کند. احتمال زیادی وجود دارد که قواعد امنیتی پراکنده شوند، زیرا گروه‌بندی براساس ویژگی‌های پویا مورداستفاده قرار نمی‌گیرد. این روش گروه‌بندی عالی جواب می‌دهد، اگر فرد قواعد موجود را از فایروال یک Vendor متفاوت انتقال دهد.
زمانی که نباید از این رویکرد استفاده کرد: در محیط‌های پویا، مثلاً Self-Service IT؛ پیاده‌سازی‌های خودکارسازی‌شده‌ی Cloud که در آن‌ها VMها را اضافه یا حذف می‌کنید و توپولوژی‌های برنامه‌ی کاربردی با سرعت بالا، شاید رویکرد گروه‌بندی مبتنی بر آدرس MAC مناسب نباشد، زیرا بین آماده‌سازی یک VM و اضافه کردن آدرس‌های MAC به گروه تأخیری رخ می‌دهد. اگر محیطی با تحرک‌پذیری بالا، مثل vMotion و HA وجود داشته باشد، رویکردهای گروه‌بندی مبتنی بر L3/IP نیز ممکن است کافی نباشند.
مدل مصرف امنیت NSX
مدل مصرف NSX آماده‌سازی، ممیزی و عیب‌یابی امنیت را تسهیل می‌کند. پالیسی‌های امنیتی به بار کاری وابسته‌اند نه به زیرساخت. اکنون می‌توان عیب‌یابی را از بار کاری شروع کرد، نه از اجزای زیرساخت. کاربران نهایی و ادمین‌های Cloud، اکنون می‌توانند یک بار یک پالیسی امنیتی را تعریف کنند و آن را به گروهی از بارهای کاری، یعنی گروه‌های امنیتی اعمال نمایند.
گروه‌های امنیتی
گروه‌های امنیتی مفهوم بسیار مهمی هستند. این گروه‌ها امکان جداسازی گروه‌بندی بارهای کاری را از توپولوژی زیرساخت زیرین فراهم می‌کنند. این امر باعث می‌شود که بتوان یک پالیسی امنیتی را برای یک بار کاری یا یک Zone مثل PCI Zone، DMZ یا Zone تولیدی نوشت. قواعد DFW جزئی و دقیق که بسیار قدرتمند هستند را می‌توان نوشت یا با کنترل‌های امنیتی دیگر مثل پیشگیری از نفوذ یا IPS، فایروال نسل جدید یا NGDW، اسکنر آسیب‌پذیری و آنتی‌ویروس ترکیب کرد.
گروه امنیتی یک سازه‌ی منطقی است که امکان گروه‌بندی را درون یک Container متداول با عناصر زیر فراهم می‌نماید:
- معیارهای ایستا (Static) – Objectهای vCenter/NSX
- معیارهای پویا (Dynamic) – ویژگی‌های VM
یک گروه امنیتی گروه‌بندی منطقی VMها را براساس این محاسبات ایجاد می‌کند:
در ادامه معیارهای منتخب گروه‌های امنیتی مطرح می‌گردند: در جدول زیر Objectهای vCenter که برای گروه‌های امنیتی مورداستفاده قرار می‌گیرند
| vCenter/NSX Object | شرح |
| کلاستر | تمام VM/vNICها درون کلاستر ESXi انتخاب می‌شوند. |
| دیتاسنتر | تمام VM/vNICها درون این دیتاسنتر انتخاب می‌شوند. |
| گروه پورت توزیعی | تمام VM/vNICهای متصل به این گروه پورت DVS انتخاب می‌شوند. |
| مجموعه IPها | Container مربوط به مجموعه IPهای انتخابی مورداستفاده قرار می‌گیرند. مجموعه IPها حاوی آدرس IP مجزا یا IP Subnet یا Range یا آدرس‌های IP می‌باشد. |
| گروه پورت قدیمی | تمام VM/vNICهای متصل به این گروه پورت VSS انتخاب می‌شوند. |
| سوئیچ منطقی | تمام VM/vNICهای متصل به این بخش سوئیچ منطقی یا VXLAN انتخاب می‌شوند. |
| Pool منبع | تمام VM/vNICهای تعریف‌شده در چارچوب Pool منبع انتخاب می‌شوند. |
| گروه امنیتی | تمام VM/vNICهای تعریف‌شده در چارچوب گروه امنیتی انتخاب می‌شوند. |
| vApp | تمام VM/vNICهای تعریف‌شده در چارچوب vApp انتخاب می‌شوند. |
| ماشین مجازی | تمام VM/vNICها انتخاب می‌شوند. |
| vNIC | این Instance به‌خصوص از vNIC انتخاب می‌گردد. |
| مجموعه‌های MAC | Container انتخابی مجموعه‌های MAC مورداستفاده قرار می‌گیرند. مجموعه‌های MAC حاوی فهرستی از آدرس‌های MAC مجزا هستند. |
| گروه Active Directory | گروه AD. |
در جدول زیر ویژگی‌های VM مورداستفاده برای گروه‌های امنیتی را نشان می دهد.
| vCenter/NSX Object | شرح |
| نام VM | تمام VMهایی که حاوی رشته به‌عنوان بخشی از نام خود هستند. |
| Tagهای امنیتی | تمام VMهایی که با Tagهای امنیتی NSX به‌خصوصی اعمال می‌شوند. |
| نام رایانه | تمام VMهایی که حاوی رشته به‌عنوان بخشی از نام رایانه‌ی خود هستند. |
| سیستم‌عامل رایانه | تمام VMهایی که یک سیستم‌عامل به‌خصوص از VM را اجرا می‌کنند. |
| نهاد | تمام VMهایی که به یکی از Objectهای vCenter که در جدول بالا فهرست شده‌اند تعلق دارند. |
نکته ای که باید توجه کرد این است که Regex محدود روی تمام ویژگی‌های VM برای ساخت گروه‌های امنیتی قابل‌دسترسی است. می‌توان گروه‌های امنیتی را با استفاده از Expression Statementهای معیارهای انتخابی پیچیده‌تری نوشت که از معیارهای زیر استفاده می‌کنند. یک گروه امنیتی می‌تواند از چندین گروه امنیتی تشکیل شده باشد. به‌علاوه، یک VM می‌تواند بخشی از چندین گروه امنیتی باشد. در شکل زیر گروه‌های امنیتی تعریف شده است.
مثال‌هایی از گروه‌های امنیتی به‌عنوان Expressionها:
- معیارهای پویا می‌توانند بیان کنند که تمام VMهایی که نام‌شان با WEB-VM شروع می‌شود در یک گروه امنیتی به نام SG-ALL-WEB-VM مشمول گردند.
- معیارهای پویا می‌توانند بیان کنند که تمام VMهایی که حاوی نام با APP-VM هستند و دارای Tag امنیتی «PCI Zone» می‌باشند در یک گروه امنیتی به نام SG-ALL-PCI-APP-VM مشمول گردند.
- معیارهایی می‌توانند بیان کنند که تمام VMهایی که به یک سوئیچ منطقی DB-Tier-LS متصل می‌شوند، در یک گروه امنیتی به نام SG-ALL-DB-Tier-LS شامل گردند.
- ترکیبی از معیارها می‌تواند این باشد که تمام VMهایی که در سوئیچ‌های منطقی DB-Tier و APP-Tier شامل شده‌اند و Tag امنیتی Production را دریافت کرده‌اند انتخاب شوند، اما تمام APP-VMها در PCI Zone یا SG-ALL-PCI-APP-VM مستثنا گردند.
پالیسی امنیتی
قواعد امنیتی در یک پالیسی امنیتی نوشته می‌شوند. یک پالیسی امنیتی می‌تواند حاوی چندین قاعده‌ی امنیتی برای کنترل‌های مختلف باشد. کنترل‌های امنیتی به‌طورکلی به سه بخش تقسیم می‌شوند.
- خدمات بررسی Guest مثل AV، اسکن آسیب‌پذیری، DLP، مانیتورینگ یکپارچگی فایل
- قواعد فایروال توزیعی
- خدمات بررسی شبکه مثل NGFW یا IPS
Inheritance و تقدم Precedence در پالیسی‌های امنیتی
ممکن است برخی از پالیسی‌های زودتر از موارد دیگر فعال شوند. همچنین ممکن است برخی از پالیسی‌ها درون پالیسی‌های دیگر گنجانده شوند تا یک ترتیب وراثت برقرار گردد. درک این وضعیت در هنگام استفاده از Service Composer حیاتی است.
تقدم نسبت به یک پالیسی
تقدم یا وزن پالیسی را می‌توان به یک پالیسی امنیتی اختصاص داد. اگر یک گروه امنیتی حاوی چندین پالیسی امنیتی اعمال شده باشد، پالیسی امنیتی که بیشترین وزن را داشته باشد، اول از همه اعمال می‌گردد. اگر وزن تمام پالیسی‌ها یکسان باشد، ترتیب‌دهی مجدد پالیسی‌ها برای یک گروه امنیتی به فرد این توانایی را می‌دهد که تصمیم بگیرد، کدام پالیسی تقدم داشته باشد.
مدل قاعده‌ی امنیتی
در هنگام ساخت یک مدل امنیتی از نوع Least Privilege در شبکه، ترتیب و دسته‌بندی قواعد امنیتی بسیار مهم هستند. مدل زیر نشان‌دهنده‌ی نمایی کلی از دسته‌بندی‌های مختلف قواعد امنیتی هستند که می‌توان آن‌ها را یا از طریق قاعده‌ی فایروال و یا از طریق یک پالیسی امنیتی با Service Composer، در NSX DFW قرار داد.
