انتقال یک اپلیکیشن وب شرکتی به پشت VPN: راهنمای تغییر مسیر

تغییر را از سمت کاربر تصور کنید. کسی روی یک نشانک کلیک می‌کند، صفحه ورود آشنا را انتظار دارد و در عوض خطای اتصال می‌گیرد، چون نام میزبان اکنون فقط داخل تونل پاسخ می‌دهد. همان یک لحظه همه چیزهایی را در خود دارد که برنامه مهاجرت باید درست انجام دهد: نام، مسیر، گواهی، حساب و عملیاتی که پشت آن است. مراحل زیر را به همین ترتیب انجام دهید تا تغییر دیگر یک جهش نباشد.

مرحله 1: بنویسید کاربران امروز چه می‌کنند

با نام میزبان در نوار نشانی، درگاه، عملیاتی که افراد انجام می‌دهند و حساب‌هایی که استفاده می‌کنند شروع کنید. اگر نمی‌توانید سه عملیات اصلی را نام ببرید، آماده بستن ورودی عمومی نیستید، چون در زمان پذیرش یک عملیات خراب را تشخیص نخواهید داد.

سپس تصمیم بگیرید مخاطب خصوصی چه کسانی هستند. کارمندان روی VPN شرکتی یک شروع است، نه پاسخ. پیمانکاران، کارکنان پشتیبانی و تیم مالی ممکن است همه به برنامه نیاز داشته باشند و ممکن است همه پشت یک دروازه نباشند.

مرحله 2: تونل را از ورود جدا کنید

وقتی کاربر از طریق VPN به برنامه می‌رسد، مرورگر همچنان یک اتصال TLS به نقطه پایانی خود برنامه باز می‌کند. گواهی باید با آن نام مطابقت داشته باشد و برنامه همچنان حساب را احراز هویت می‌کند. هیچ چیز در تونل جای هیچ‌یک از این دو را نمی‌گیرد.

اینجاست که مهاجرت‌ها بی‌صدا اشتباه می‌شوند. کسی تصمیم می‌گیرد آدرس خصوصی دیگر به گواهی معتبر نیاز ندارد، کاربران یاد می‌گیرند از یک هشدار رد شوند و سازمان یک افشای عمومی را با یک برنامه آموزشی در نادیده گرفتن هشدارهای امنیتی معاوضه کرده است. اگر برنامه واقعاً به گواهی داخلی نیاز دارد، یکی از مرجع داخلی صادر کنید و اعتماد را درست توزیع کنید. این یک تغییر کنترل‌شده است؛ صفحه هشدار نیست.

مجوزدهی را همان‌جا که هست نگه دارید. خلاصه معماری اعتماد صفر NIST نکته را مستقیم بیان می‌کند: موقعیت شبکه دلیلی برای اعطای یک عملیات حساس نیست. بودن داخل تونل نباید یک حساب فقط‌خواندنی را به مدیر تبدیل کند.

مرحله 3: فراخوان‌هایی را پیدا کنید که کارمند نیستند

پیکربندی برنامه را باز کنید و هر چیزی را که با آن صحبت می‌کند فهرست کنید: نشانی بازگشت ارائه‌دهنده هویت، وبهوک ارائه‌دهنده پرداخت، درون‌ریزی زمان‌بندی‌شده، یک کاوشگر پایش، کلاینت API یک شریک. هر یک وابستگی با یک مالک است و هر یک در لحظه‌ای متفاوت می‌شکند.

برای هر یک که باید بماند یک مسیر پشتیبانی‌شده تعیین کنید. ارائه‌دهنده وبهوک نمی‌تواند به VPN کارمندان شما بپیوندد، پس یا یک نقطه پایانی یکپارچه‌سازی با دامنه باریک و احراز هویت خودش افشا کنید، یا مدل یکپارچه‌سازی را تغییر دهید. عمومی گذاشتن کل برنامه چون یک بازگشت وجود دارد یک انتخاب است و معمولاً انتخاب اشتباه.

هر استثنا را با مقصد، عملیات مجاز، احراز هویت و مالک بنویسید. یک حساب VPN عمومی که به یک یکپارچه‌سازی داده شود همان راهی است که یک استثنا دائمی می‌شود. فهرست را در بازبینی دسترسی بعدی مرور کنید، چون یکپارچه‌سازی‌ها از پروژه‌هایی که آن‌ها را اضافه کردند بیشتر عمر می‌کنند. استثنا بدون تاریخ انقضا یک تصمیم طراحی دائمی است که هیچ‌کس نگرفته است.

مرحله 4: مسیر عمومی را بازنشسته کنید، نه فقط رکورد DNS را

زنجیره انتشار را بپیمایید: DNS، شنونده‌های متعادل‌کننده بار، قواعد پراکسی معکوس، فایروال میزبان و هر نام جایگزینی که هنوز به آدرس قدیمی اشاره می‌کند. هر دو خانواده نشانی را بررسی کنید. تغییر رکورد A اصلی تقریباً هیچ چیز را اثبات نمی‌کند اگر یک CNAME قدیمی‌تر یا یک شنونده IPv6 هنوز برنامه را سرویس دهد.

به‌طور موازی تأیید کنید که نام خصوصی داخل تونل حل می‌شود و گواهی نامی را که کاربران تایپ می‌کنند پوشش می‌دهد. کاربری که مجبور است یک آدرس عددی را جای‌گذاری کند نشانه‌ای پیدا کرده است، نه راه‌حل.

مخاطب VPN را به مسیر برنامه محدود کنید. دسترسی گسترده به شبکه اداری یک تصمیم افشا را با تصمیمی بزرگ‌تر عوض می‌کند و رابط‌های مدیریتی به منابع مجاز خودشان نیاز دارند نه وراثت قاعده کاربر.

مرحله 5: پذیرش را خودتان بپیمایید

به‌عنوان یک کاربر تأییدشده متصل شوید، نشانک را باز کنید، گواهی را بررسی کنید، وارد شوید و یک عملیات واقعی انجام دهید. سپس حسابی را امتحان کنید که نباید آن عملیات را داشته باشد و تأیید کنید که رد می‌شود. سپس از دستگاهی بیرون از VPN امتحان کنید و تأیید کنید که برنامه در دسترس نیست.

برای هر یکپارچه‌سازی حفظ‌شده تکرار کنید و گزارش تحویل ارائه‌دهنده را بخوانید، به‌جای اینکه فرض کنید 200 از ابزار آزمایش خودتان همان چیز است. ورود موفق به VPN برای هیچ‌یک از این نتایج مدرک نیست.

مرحله 6: روز بد را تمرین کنید

تصمیم بگیرید در قطع تونل چه اتفاقی می‌افتد: کار متوقف می‌شود، یا روش دسترسی تأییدشده دیگری آن را برمی‌گیرد. هر چه انتخاب کنید، آن را بنویسید و یک بار آزمایش کنید، چون بازگشایی عمومی اضطراری به‌عنوان مکانیزم بازیابی مستندنشده در نهایت توسط کسی تحت فشار اجرا خواهد شد.

دسترسی بازیابی را برای مدیرانی که دروازه و برنامه را نگه می‌دارند، با مالک و تاریخ حذف نگه دارید. تغییر و شرایط بازگرداندن آن را در همان جا ثبت کنید تا یک مهاجرت ناموفق افرادی را که آن را درست می‌کنند قفل نکند.

پس از تغییر، وصله‌کردن، چرخه عمر حساب، مجوزدهی برنامه و حسابرسی هنوز کار شماست. تونل ورودی را باریک کرد؛ هیچ‌یک از این کارها را بر عهده نگرفت.