آیا اگر از Identity-Aware Proxy استفاده می‌کنید، هنوز به VPN نیاز دارید؟

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

دو دروازه چیزهای مختلفی را مجاز می‌کنند

دروازه برنامه تصمیم می‌گیرد که آیا این درخواست، از این هویت، می‌تواند به این منبع محافظت‌شده برسد. مرور کلی Identity-Aware Proxy گوگل دقیقاً همین شکل را توصیف می‌کند: یک لایه مجوزدهی مرکزی جلوی برنامه‌های HTTPS که با نقش IAM اداره می‌شود. مرز همان منبع است و واحد دسترسی همان درخواست. VPN مسیریابی‌شده کاری خشن‌تر و گسترده‌تر می‌کند: کلاینت را به محدوده شبکه تعریف‌شده‌ای راه می‌دهد و پس از آن برنامه هنوز تصمیم می‌گیرد که این کلاینت چه کاری می‌تواند بکند.

هیچ‌یک از دو مدل دیگری را ایجاب نمی‌کند. عبور از دروازه چیزی درباره خواندن یک رکورد خاص نمی‌گوید، و بودن در شبکه چیزی درباره اجازه عمل نمی‌گوید.

چیزی که پروکسی پوشش نمی‌دهد و VPN می‌دهد

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

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

جریان کار کلاینت بیش از نمودار معماری تعیین می‌کند

ورود به مرورگر با یک تغییر مسیر و گاه یک چالش MFA تجربه خوبی برای کسی است که روی یک نشانک کلیک می‌کند. یک کار cron، یک CLI یا یک عامل ساخت مرورگر ندارد و نمی‌تواند به یک پرسش تعاملی پاسخ دهد، پس به یک مسیر غیرتعاملی مستند یا به تونل نیاز دارد. کشف این نیاز معمولاً پس از تأیید طراحی رخ می‌دهد.

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

وضعیت دستگاه ویژگی هیچ‌یک از دو دروازه نیست

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

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

پیش از بازنشسته کردن هر چیزی، مسیرهای جایگزین را پیدا کنید

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

سپس تحویل را بنویسید: ثبت‌نام، به‌روزرسانی‌ها، حذف دسترسی و مسیر بازیابی برای کسی که ساعت 2 بامداد بیرون قفل شده است. حذف یک اعلان یا یک برنامه کلاینت مسئولیت را بین تیم‌ها جابه‌جا می‌کند؛ آن را حذف نمی‌کند.

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