آیا وقتی برنامه از mTLS و SSO استفاده می‌کند، هنوز به VPN سایت نیاز دارید؟
کانال‌هایی را که ورود به برنامه هرگز پوشش نمی‌دهد بپیمایید، سپس تصمیم بگیرید که آیا دسترسی به شبکه خصوصی زائد است یا هنوز تنها راه به میزبان است.
با mTLS وارد می‌شوید، داشبورد بارگذاری می‌شود، و این ادعا که VPN سایت اکنون زائد است تقریباً تا زمانی معقول به نظر می‌رسد که ساعت دو بامداد به بازیابی یک پایگاه داده نیاز پیدا کنید. مرز TLS برنامه تنها یک کانال را توصیف می‌کند. میزبان، پایگاه داده، مقصد پشتیبان‌گیری و حساب ابری هر یک مسیر ورود، هویت و تأییدکننده خود را دارند و هیچ‌یک از آن‌ها با یک ورود موفق آزموده نمی‌شود.
از صفحه ورود به سمت بیرون قدم بزنید
مانند یک کاربر عادی وارد شوید و هر گامی را که درخواست لمس می‌کند بنویسید: مرورگر، لبه، شنونده برنامه، مخزن نشست، API پشتیبان. هر گام یک مالک و یک تصمیم احراز هویت دارد. اکنون این مسیر را برای کسی که میزبان را وصله می‌کند و برای کاری که پشتیبان شبانه را می‌نویسد تکرار کنید. این مسیرها معمولاً از همان گام نخست از هم جدا می‌شوند.
همین جدایی پرسشی است که ارزش پاسخ دادن دارد. VPN سایت تنها زمانی زائد است که هر کانال در آن مسیر دوم سیاست ورود و مجوزدهی داشته باشد که خودش به‌تنهایی بایستد.
پنج کانالی که ورود به برنامه هرگز پوشش نمی‌دهد
جدول زیر یک الگوی فهرست برداشت است، نه چک‌لیست استقرار. ستون دوم را با آنچه محیط خودتان امروز واقعاً اعمال می‌کند پر کنید.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
اشتراک یک ارائه‌دهنده هویت این مجوزها را یکی نمی‌کند. کاربری که مجاز است درخواست API بفرستد با این کار مجاز نیست دیسک یک ماشین مجازی را جایگزین کند یا پایگاه داده‌ای را با اعتبارنامه‌های برنامه بازیابی کند. NIST در خلاصه معماری اعتماد صفر دقیقاً به همین دلیل احراز هویت و مجوزدهی منابع را از موقعیت شبکه جدا نگه می‌دارد.
مهندس پشتیبانی که می‌تواند یک تیکت را بخواند با این کار مجاز نیست کنسولی روی میزبان پشت آن باز کند.
یک مسیر تنها زمانی واقعی است که جایگزین بسته بماند
محدود کردن دسترسی به شنونده‌های اداری خصوصی جایگزین مشروعی برای VPN سایت است، به شرط آنکه محدودیت اعمال شود و نه فقط ترسیم. شکست معمول یک شنونده جایگزین است که کسی آن را به یاد نداشته: سرویسی که هنوز به همه رابط‌ها متصل است، قاعده‌ای در گروه امنیتی که برای یک پیمانکار باز شده، درگاه مدیریتی که از اینترنت قابل دسترسی است.
شنونده‌ها را بررسی کنید، نه نمودارها را. روی میزبان با ss -ltnp فهرست کنید چه چیزی واقعاً متصل است و تأیید کنید که درگاه‌های اداری روی یک نشانی خصوصی قرار دارند. در کنسول ابری قواعد ورودی زیرشبکه بار کاری را بخوانید و به دنبال 0.0.0.0/0 روی هر چیز اداری بگردید. سپس اتصال را از بیرون مسیر خصوصی امتحان کنید، چون همان آزمون است که به پرسش پاسخ می‌دهد.
یک قاعده باز به روی همه جهان روی SSH همه استدلال‌های طراحی تونل را باطل می‌کند.
نقشه را پیش از مقایسه طرح‌ها بنویسید
برای هر ردیف فهرست، ثبت کنید چه کسی هویت‌ها را تأیید می‌کند، چه کسی قواعد دسترسی را به‌روز می‌کند، چه کسی هنگام رفتن یک نفر اعتبارنامه‌ها را حذف می‌کند و چه کسی وقتی خود مسیر می‌شکند بازیابی را بر عهده دارد. چهار نام در هر ردیف کافی است تا ردیف‌هایی آشکار شود که پاسخشان یک حساب مشترک و یک صفحه ویکی سه‌ساله است.
سپس برای هر کانال یک اجازه و یک رد را اعتبارسنجی کنید. اجازه ثابت می‌کند که هویت مورد نظر می‌تواند از مسیر مورد نظر به منبع برسد. رد ثابت می‌کند که هویت مشابهی نمی‌تواند، و همان آزمونی است که مردم از آن می‌گذرند، و به همین دلیل شنونده‌های جایگزین از بازرسی‌ها جان سالم به در می‌برند. طرح پیشنهادی را با این نتایج مقایسه کنید، نه با پیکربندی TLS برنامه که هرگز هیچ‌یک از آن‌ها را نیازموده است.
کجا VPN سایت هنوز جای خود را به دست می‌آورد
تونل یا دروازه باریک پاسخ درست است وقتی منبعی احراز هویت مختص خود به‌ازای هر درخواست ندارد: درگاه‌های نگهداری پایگاه داده، مقصدهای پشتیبان‌گیری، کنسول‌های هایپروایزر، مدیریت خارج از باند. آن شنونده‌ها به شبکه اعتماد می‌کنند، پس شبکه باید همان چیزی باشد که فراخوان را احراز هویت می‌کند.
این تنها پاسخ نیست. دروازه‌ای که مجوزدهی هر منبع را پایان می‌دهد می‌تواند از یک تونل سراسری زیرشبکه باریک‌تر باشد و ردپای بازرسی بهتری از یک میزبان پرش مشترک بر جای می‌گذارد.
ترتیب کار: فهرست را کامل کنید، جایگزین‌ها را ببندید، برای هر ردیف یک رد را اعتبارسنجی کنید و تنها پس از آن تونل را بازنشسته کنید. اگر ردیفی نمی‌تواند ردی تولید کند، مسیر خصوصی را نگه دارید تا بتواند.