ناحیه مدیریت SaaS پشت VPN: به کدام نشانی اعتماد کنیم؟

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

آنچه مبدأ پس از تونل واقعاً دریافت می‌کند

وقتی مرورگر از طریق VPNی که ترافیک اینترنت را هم حمل می‌کند به سایت عمومی می‌رسد، درگاه اتصال را پیش از خروج ترجمه می‌کند. SaaS نشانی خروجی عمومی درگاه را می‌بیند، معمولاً یک نشانی یا یک بازه کوچک، و هرگز نشانی تونل لپ‌تاپ را نمی‌بیند. به همین دلیل افزودن 10.90.0.42 به فهرست مجاز شکست می‌خورد، و به همین دلیل افزودن تمام RFC 1918 بلندتر شکست می‌خورد: دومی هر شبکه خصوصی‌ای را که بتواند به شما برسد می‌پذیرد. تنها نشانی‌ای که ارزش شرط گذاشتن دارد همانی است که سازمان شما واقعاً در خروجی مالک آن است.

curl -s https://ifconfig.me
dig +short admin.example.com

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

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

فقط به پروکسی‌ای اعتماد کنید که نشانی را بازنویسی می‌کند

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

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

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

شرط را به هر عملیات محافظت‌شده پیوند دهید

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

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

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

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

دور زدن‌هایی را که همین حالا بستید آزمایش کنید

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

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

هر درخواست باید وضعیتی را بازگرداند که سیاست وعده می‌دهد، و گزارش باید ثبت کند که از کدام شواهد نشانی استفاده شده است. IPv6 را جداگانه پوشش دهید، چون مبدأ دوپشته ممکن است خانواده مبدأ متفاوتی از آنچه آزمایش کردید ببیند. عملیات عادی مشتریان را بیرون از VPN فعال نگه دارید، وگرنه تغییر در نخستین شکایت مشتری برگردانده می‌شود. نتیجه مورد انتظار هر ردیف را پیش از اجرا بنویسید تا یک قبولی غافلگیرکننده قابل مشاهده باشد.

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