به کاربران VPN دسترسی به یک سرویس بدهید، نه به زیرشبکه
یک مسیر باریک سیاست مجوزدهی نیست. تصمیم بگیرید اعمال محدودیت کجا زندگی میکند، سرویس چه منبعی میبیند و نقشهای برنامه چگونه جدا میمانند.
یک پیمانکار به یک برنامه وب داخلی نیاز دارد و نه چیز دیگری، و پاسخ آسان این است که به او یک تونل به زیرشبکه سرور بدهید. این تا روزی کار میکند که آن را اسکن کند. طراحی باریکتر تفکر بیشتری میخواهد، زیرا دسترسپذیری، مسیریابی و مجوز برنامه سه کنترل جداگانهاند که باید با هم هماهنگ باشند.
نیاز را بهصورت سرویس بنویسید، نه زیرشبکه
با میزبان مقصد، پروتکل و پورت شروع کنید، سپس گروه کاربر یا دستگاهی را که باید به آن برسد اضافه کنید. ناحیه DNS خصوصی را فقط اگر برنامه نامی را حل میکند وارد کنید، و ارائهدهنده هویت را فقط اگر جریان ورود به آن نیاز دارد وارد کنید. هر چیز دیگری وابستگیای است که هنوز آن را توجیه نکردهاید.
زیرشبکه یک جزئیات پیادهسازی تیم شبکه است، در حالی که سرویس همان چیزی است که کسبوکار خواسته و واحدی که میتوان بازبینی و بازنشستهاش کرد.
اگر فهرست وابستگیها از سه مورد فراتر رفت، برنامه احتمالاً به گفتوگوی طراحی خودش نیاز دارد.
مسیر را باریک کنید، اما اعمال را جای دیگری انجام دهید
یک مسیر یا انتخابگر باریک به تونل میگوید کدام بستهها را حمل کند؛ این سیاست مجوزدهی نیست. فیلتر دروازه، دیوار آتش میزبان مقصد و مدل مجوز خود برنامه جاهایی هستند که دسترسی در آنها تعیین میشود. مسیری که یک نشانی را پوشش میدهد شروع خوبی است، و آن کنترلی نیست که کاربر مصمم را متوقف کند. همین جداسازی به شما اجازه میدهد فیلتر را بدون بازطراحی تونل تغییر دهید.
در مقابل، مسیر گسترده با فیلتر سختگیرانه میتواند مشروع باشد، اما فقط اگر همه افراد درگیر بدانند کدام یک اعمال را انجام میدهد.
نقطه اعمال را صریح مستند کنید، وگرنه تغییر بعدی آن را تصادفی جابهجا میکند.
منبعی را که سرویس واقعاً میبیند بررسی کنید
مقصد یا نشانی استخر کارخواه را میبیند یا نشانی دروازه را، بسته به اینکه ترجمه میکنید یا نه. قواعد دیوار آتش میزبان و گزارشها باید با منبع واقعی مطابقت داشته باشند. اگر چند کاربر یک منبع ترجمهشده را به اشتراک بگذارند، هیچ قاعدهای برای هر کاربر روی آن میزبان نمیتواند آنها را از هم تشخیص دهد، و این یک محدودیت طراحی است نه یک اشکال.
ترجمه را آگاهانه انتخاب کنید: مسیریابی را ساده میکند و هویت منبع را از بین میبرد، که برای حسابرسی و قواعد هر کاربر مهم است.
بنویسید کدام یک از دو را انتخاب کردید، کنار قاعدهای که به آن وابسته است.
مجوز برنامه اختیاری نیست
رسیدن به یک پورت نقش نمیدهد. برنامه هنوز به ورود و مجوزهای خودش نیاز دارد، زیرا لایه شبکه نمیتواند بیان کند کاربر کدام رکوردها را میتواند ویرایش کند. سرویسی که به هر درخواست از زیرشبکه داخلی اعتماد کند، تونل باریک را برای یک اعتبارنامه بهخطرافتاده به دسترسی کامل تبدیل میکند. تونل تعیین میکند چه کسی میتواند سوکت را باز کند، و برنامه تعیین میکند با آن چه میتواند بکند.
اینجاست که طراحی باریک دو بار سود میدهد، چون میزبانهای دسترسپذیر کمتر یعنی جاهای کمتری که یک خطای سطح برنامه در آن قابل سوءاستفاده است.
قاعده شبکه و نقش برنامه را در سامانههای جدا نگه دارید و آنها را جدا بازنشسته کنید.
هم مسیر مجاز و هم مسیر ردشده را اثبات کنید
بهعنوان کاربر مجاز وصل شوید و یک عملیات بیخطر نماینده انجام دهید، سپس مقصدی را امتحان کنید که باید غیرقابلدسترس باشد. طراحیای که فقط نیمه اول را میآزماید آزمایش نشده است، و آزمون رد همان چیزی است که طراحی را اثبات میکند. پس از هر تغییر قاعده یک نشست تازه بیازمایید، و اگر درخواستها میرسند اما پاسخها نه، مسیر بازگشت را ببینید.
فیلترهای ارسال را غیرفعال نکنید تا آزمون پذیرش قبول شود، چون این چیز آزمونشده را تغییر میدهد.
وقتی کاربر دیگر به سرویس نیاز ندارد، هویت راهدور و نقش برنامه را در سامانههای مربوط خودشان بازنشسته کنید و هر دو را ثبت کنید. راهنمای ارسال strongSwan سمت دروازه مسیر را پوشش میدهد.