Два 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 рядом со службой, которая никогда не отвечает.
Проверяйте маршруты и правила блокировки при отказе, а не только в обычном случае. Маршрут по умолчанию, продвигаемый внешним туннелем, может перехватить собственный адрес внутреннего шлюза, что превращает второй этап в соединение, которое устанавливается и затем падает. Запишите, что должно оставаться заблокированным, пока внутреннего туннеля нет, потому что случайный обход вокруг него хуже чистого перерыва. Используйте одинаковую форму проверки на обоих переходах, чтобы каждый измерялся, а не предполагался. Два индикатора подключения не доказывают ни вложенности, ни изоляции.
Что второй шлюз не может вам купить
Спросите, разделяют ли два шлюза учётные данные, удостоверяющий центр или плоскость управления. Там, где разделяют, они разделяют и свои важнейшие режимы отказа, и второй этап стоит больше, чем независимость, которую он как будто добавляет. Отдельные криптографические сеансы не создают отдельных административных контролей.
Держите внутренний шлюз, пока он обеспечивает требование, которое вы можете сформулировать и проверить, например роль, которую внешний домен никогда не проверяет. Уберите его, когда его единственная задача — повторно аутентифицировать ту же личность в отношении тех же назначений. В любом случае записывайте требование, владельца и поведение при отказе вместе, чтобы следующий обзор спорил о требовании, а не о схеме.