نحوه اعتبارسنجی سیاست‌های تقسیم‌بندی خرد قبل از اجرا

تعریف میکروسگمنتیشن آسان و پیاده سازی آن دشوار است.

روی کاغذ، هدف مشخص است:

• دسترسی را فقط به موارد مورد نیاز محدود کنید
• حرکت جانبی غیر ضروری را حذف کنید
• کمترین امتیاز را برای حجم کاری اعمال کنید

با این حال، عدم رعایت بهداشت سیاست به این معنی است که قوانین ممکن است واقعیت را منعکس نکنند.

در واقع، بیشتر محیط ها عبارتند از:

• ساخته شده در طی سالها تغییرات تدریجی
• پر از وابستگی های غیرمستند
• یک شبکه شکننده و به هم پیوسته که در آن یک تغییر می تواند کل تجارت را مختل کند

به همین دلیل است که بسیاری از پروژه های تقسیم بندی متوقف می شوند یا به طور کلی شکست می خورند.

نه به این دلیل که مدل اشتباه است. زیرا این خط مشی قبل از تأیید اعتبار اعمال می شود.

این پست نشان می‌دهد که چگونه می‌توان سیاست‌های تقسیم‌بندی خرد را قبل از اجرا تأیید کرد تا بتوانید ریسک را بدون ایجاد اختلال در تولید کاهش دهید.

مشکل اصلی: پیاده سازی بدون اعتبار سنجی

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

1. هدف تقسیم بندی را تعریف کنید

2. نیت را به قوانین تبدیل کنید

3. استقرار اجرا

4. عیب یابی آنچه در حال خراب شدن است

مشکل مرحله 4 است.

وقتی تقسیم بندی بدون اعتبارسنجی اعمال می شود:

• ترافیک قانونی مسدود شده است
• اعتیادهای پنهان ظاهر می شوند
• تیم ها تحت فشار تغییرات را خنثی می کنند

نتیجه قابل پیش بینی است – تقسیم بندی به جای عملیاتی، نظری می شود.

معنای واقعی “تأیید” چیست.

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

اگر این خط مشی تقسیم بندی را اجرا کنیم، چه ترافیکی همچنان کار می کند و چه چیزی خراب می شود؟

برای این کار باید شبیه سازی کنید:

• مسیرهای دسترسی واقعی
• تعامل بین دستگاه ها ایجاد کنید
• وابستگی بین سیستم ها

مرحله 1: یک مدل دسترسی فعلی بسازید

قبل از تعریف تقسیم بندی، باید بدانید که امروزه چه چیزی واقعا مجاز است.

این به چیزی بیش از یک بررسی پیکربندی نیاز دارد.

شما نیاز به یک مدل ساخته شده از:

• قوانین دیوار آتش متقابل فروشنده
• توپولوژی و مسیریابی شبکه
• گروه های شی و نقشه آدرس
• رفتار ترافیکی در صورت وجود

خارج شوید

طیف وسیعی از مسیرهای دسترسی موثر:

App_Server → DB_Server (1433)
App_Server → Logging_Service (514)
App_Server → Backup_System (445)

این می شود پایه شما.

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

بیشتر محیط های متروکه شامل:

• قوانین گسترده “اجازه هر”
• استثناهای موقتی که دائمی شده اند
• گروه های همپوشانی از اشیاء
• مسیرهای دسترسی اضافی

تقسیم بندی با شناسایی شروع می شود:

چه دسترسی وجود دارد که نباید وجود داشته باشد

یک مثال

App_Server → DB_Server (1433) ← مورد نیاز است
App_Server → Backup_System (445) ← غیر ضروری
App_Server → Reporting_DB (1433) ← غیرمنتظره

این هدف کاهش شما را تعیین می کند.

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

سیاست های تقسیم بندی باید به صورت زیر تعریف شوند:

• پخش جریانی به صراحت مجاز است
• ژست پیش فرض را لغو کنید
• محدودیت های خاص محیطی

نیت نمونه

اجازه می دهد:
App_Server → DB_Server (1433)

سلب مسئولیت:
App_Server → همه سیستم های داخلی دیگر

این حالت مورد نظر شماست.

مرحله 4: قصد را به تغییرات خط مشی تبدیل کنید

نیت باید به این صورت ترجمه شود:

• قوانین فایروال
• به روز رسانی گروه امنیتی
• سیاست های پلتفرم ریزبخشی

این یک حالت سیاست پیشنهادی ایجاد می کند.

در این مرحله، اکثر تیم ها مستقر می شوند.

در عوض باید اعتبارسنجی انجام شود.

مرحله 5: سیاست تقسیم بندی را شبیه سازی کنید

قوانین تقسیم بندی پیشنهادی بدون تحمیل در یک مدل محیطی اعمال می شود.

این شبیه سازی:

• همه مسیرهای دسترسی را دوباره محاسبه می کند
• نظم و اولویت را در قوانین اعمال می کند
• تعامل بین دستگاه ها و لایه ها را ارزیابی می کند

سیستم پاسخ می دهد:

اگر این تقسیم بندی اجرا شود، چه اتصالی باقی می ماند؟

مرحله 6: شکستگی ها و شکاف ها را شناسایی کنید

اعتبارسنجی دو مقوله حیاتی را پوشش می‌دهد:

1. قطع جریان های مشروع

اینها لینک های ضروری هستند که مسدود خواهند شد.

یک مثال

App_Server → Logging_Service (514) ← لازم است اما شامل نمی شود

آنها نمایندگی می کنند:

• عدم تعاریف قوانین
• وابستگی های پنهان

2. دسترسی ناخواسته باقی مانده

اینها جریانهایی هستند که علیرغم قصد تقسیم باز باقی می مانند.

یک مثال

App_Server → Backup_System (445) ← هنوز از طریق مسیر جایگزین مجاز است

آنها نمایندگی می کنند:

• عملکرد ناقص
• نوردهی چند طرفه در دستگاه های مختلف

مرحله 7: سیاست را قبل از اجرا اصلاح کنید

بر اساس نتایج شبیه سازی:

• قوانین فعالسازی اجباری را اضافه کنید
• مسیرهای دسترسی ناخواسته را حذف کنید
• محدوده و ترتیب قوانین را تنظیم کنید

این روند تا زمانی که:

دسترسی واقعی با دسترسی مورد نظر مطابقت دارد

مرحله 8: در Apply Layers اعتبار سنجی کنید

در محیط های هیبریدی، تقسیم بندی شامل موارد زیر است:

• فایروال های شبکه
• گروه های امنیتی ابری
• ریزبخش بندی مبتنی بر میزبان

اعتبارسنجی باید تأیید کند:

• ثبات خط مشی در سراسر لایه ها
• هیچ شکافی بین نقاط کاربردی وجود ندارد
• هیچ قانون متناقضی در سیستم ها وجود ندارد

مرحله 9: با اطمینان اجرا کنید

فقط پس از تأیید اعتبار باید اجرا شود.

در این مرحله:

• دسترسی مورد انتظار مشخص است
• شکستگی رفع شده است
• خطر به حداقل می رسد

پیاده سازی به اجرا تبدیل می شود نه آزمایش.

این در عمل چگونه به نظر می رسد؟

بدون تایید:

• تقسیم بندی مورد نیاز است
• برنامه ها شکست خوردند
• تیم ها برای شناسایی قوانین گمشده تلاش می کنند

با اعتبارسنجی:

• تقسیم بندی شبیه سازی شده است
• شکاف ها زود شناسایی می شوند
• اعدام بدون وقفه انجام می شود

چرا این موضوع برای اعتماد صفر اهمیت دارد

اعتماد صفر بستگی به این دارد:

• تقسیم بندی دقیق
• عملکرد مستمر
• حداقل دسترسی در هر پروژه

اما Zero Trust زمانی شکست می خورد که:

• هدف سیاست با اجرای واقعی همسو نیست
• وابستگی ها به طور کامل درک نشده اند
• تغییرات باعث دسترسی ناخواسته می شود

اعتبار سنجی تضمین می کند که آنچه طراحی می کنید همان چیزی است که در واقع اجرا می شود.

نقش FireMon

FireMon این تأیید را توسط:

• مدل سازی خط مشی در فایروال ها و محیط ها
• شبیه سازی تغییرات بخش بندی قبل از اجرا
• دسترسی ناخواسته و وابستگی های شکسته را شناسایی کنید
• اعتبارسنجی سازگاری بین لایه های برنامه

به عنوان یک لایه مدیریتی بین هدف تقسیم بندی و سیستم های اجرایی عمل می کند.

حرف آخر

اکثر پروژه های تقسیم بندی شکست نمی خورند زیرا استراتژی اشتباه است.

آنها شکست می خورند زیرا اجرا قبل از درک اتفاق می افتد.

اعتبار سنجی، تقسیم بندی خرد را از یک ریسک به یک فرآیند کنترل شده تبدیل می کند.