Два VPN-шлюзи поспіль: що насправді вирішує кожен
Два етапи VPN поспіль мають означати два окремі рішення про дозвіл. Назвіть, що перевіряє кожен шлюз, потім перевірте, що відхиляє внутрішній.
Зв'язування двох VPN у ланцюг зазвичай продають як додаткове шифрування, хоча це найменш цікаве, що воно робить. Справжній продукт — друге рішення про авторизацію, яке ухвалює інший власник щодо іншого набору ресурсів. Якщо обидва етапи приймають ті самі облікові дані й досягають тих самих призначень, внутрішній шлюз — прикраса з додатковою затримкою. Рішення про те, чи варте це друге рішення своїх операційних витрат, починається з називання того, що кожен шлюз справді перевіряє.
Один тунель, потім друге рішення
Зовнішній шлюз відповідає на широке питання: це схвалений пристрій працівника і чи може він досягти загальної внутрішньої мережі. Внутрішній шлюз відповідає на вужче: чи має ця особа право на обслуговування і чи може вона досягти цих конкретних точок керування. Це різні питання з різними власниками, і жодне не передбачає іншого. Існування шляху через обидва етапи не є повноваженням використовувати те, що стоїть за другим. Досягнення далекого входу доводить, що маршрут працює, і нічого більше.
Принцип старий і досі ігнорується: мережеве розташування саме собою нічого не доводить. Огляд архітектури нульової довіри NIST каже це прямо, відкидаючи неявну довіру, що випливає з того, звідки прийшло з'єднання або кому належить мережа. Застосоване тут, прибуття до внутрішнього входу є передумовою для його ресурсів, але ніколи не дозволом користуватися ними.
Запишіть, що перевіряє кожен шлюз
Для кожного етапу зафіксуйте особу, яку він перевіряє, призначення, які він дозволяє, і умови, за яких його можна пропустити. Зовнішній шлюз може законно дозволяти звичайні внутрішні служби плюс слухача внутрішнього шлюзу, і нічого більше. Внутрішній шлюз може вимагати заявку на роль і дозволяти лише адреси керування, названі в записі про зміну. Застосунок на далекому кінці зберігає останнє слово про те, які операції ця роль може виконувати, тож ланцюг додає шлюз, не замінюючи авторизацію застосунку.
| Gate | Identity it checks | Destinations it permits | How it could be skipped | When it is removed |
|---|---|---|---|---|
| Outer gateway | Employee account plus a managed device posture | General internal services and the inner gateway's listener | Any alternate path to the same destinations, including a public listener | Ordinary work stops and the inner stage becomes unreachable |
| Inner gateway | A maintenance entitlement or role claim on that identity | The named management addresses in the change record | Direct routes from the outer domain to those addresses | Maintenance access ends while general access stays as it was |
Два пропуски тихо ламають проєкт. Якщо зовнішній домен уже прямо досягає кожного чутливого призначення, внутрішній шлюз необов'язковий, а не обов'язковий. Якщо публічний слухач або другий приватний маршрут пропонує той самий доступ, передбачуваний шлях — один варіант із кількох. Призначте власника й кожному набору правил, і нехай їхній контракт називає служби призначення, дозволені вихідні особи, приватний DNS, трансляцію адрес і того, хто відповідає, коли передача не вдається. Адреса, якій довіряють у зовнішній мережі, ніколи не повинна замінювати авторизацію внутрішнього домену.
Перевіряйте випадки відмови, а не щасливий шлях
Успішне з'єднання через обидва шлюзи доводить дуже мало, бо це той випадок, який усі перевіряли під час впровадження. Цікаві випадки — ті, коли один етап проходить, а другий відмовляє. Три з них покривають більшу частину ризику, і кожен має очікуваний результат, який можна перевірити, а не обговорювати.
Коли загальний доступ схвалено, а чутливої ролі немає, звичайна робота має тривати, поки чутливе призначення відхиляється. Схваліть обидва етапи, і досяжний набір має бути точками обслуговування, названими в записі про зміну, і не ширше. Якщо право відкликано посеред сеансу, узгоджена політика сеансу має набути чинності, не руйнуючи не пов'язаний із цим загальний доступ. Чи це відкликання завершує наявний сеанс негайно, чи під час наступної повторної автентифікації — це рішення політики, яке контракт уже має містити. Той, хто писав критерії приймання, не повинен їх тлумачити під час інциденту.
curl --fail --silent --max-time 5 https://maint.corp.internal/health || echo "denied as expected"Порахуйте додані залежності
Кожен додатковий етап додає компонент, який може відмовити, і маршрут, який має правильно вкластися в зовнішній тунель. Під час часткової відмови зовнішній шлях залишається, а внутрішній недосяжний, тож користувач бачить здоровий значок VPN поруч зі службою, яка ніколи не відповідає.
Перевіряйте маршрути й правила блокування під час відмови, а не лише у звичайному випадку. Маршрут за замовчуванням, який просуває зовнішній тунель, може перехопити власну адресу внутрішнього шлюзу, що перетворює другий етап на з'єднання, яке встановлюється і потім падає. Запишіть, що має залишатися заблокованим, поки внутрішнього тунелю немає, бо випадковий обхід навколо нього гірший за чисту перерву. Використовуйте ту саму форму перевірки на обох переходах, щоб кожен вимірювався, а не припускався. Два індикатори підключення не доводять ні вкладеності, ні ізоляції.
Що другий шлюз не може вам купити
Запитайте, чи поділяють два шлюзи облікові дані, центр сертифікації або площину керування. Там, де поділяють, вони поділяють і свої найважливіші режими відмови, а другий етап коштує більше, ніж незалежність, яку він начебто додає. Окремі криптографічні сеанси не створюють окремих адміністративних контролів.
Тримайте внутрішній шлюз, поки він виконує вимогу, яку ви можете сформулювати й перевірити, наприклад роль, яку зовнішній домен ніколи не перевіряє. Приберіть його, коли його єдина робота — повторно автентифікувати ту саму особу щодо тих самих призначень. У будь-якому разі записуйте вимогу, власника й поведінку під час відмови разом, щоб наступний огляд сперечався про вимогу, а не про схему.