Нужен ли ещё VPN сайта, если приложение использует mTLS и SSO?
Пройдите каналы, которые вход в приложение никогда не покрывает, и решите, избыточен ли доступ к частной сети или по-прежнему остаётся единственным путём к хосту.
Вы входите по mTLS, панель загружается, и утверждение, что VPN сайта теперь избыточен, звучит разумно примерно до тех пор, пока в два часа ночи не потребуется восстановить базу данных. Граница TLS приложения описывает только один канал. Хост, база данных, цель резервных копий и облачная учётная запись имеют каждый свой путь входа, свою идентичность и своего утверждающего, и ни один из них не проверяется успешным входом.
Идите наружу от экрана входа
Войдите как обычный пользователь и запишите каждый шаг, которого касается запрос: браузер, край, слушатель приложения, хранилище сессий, backend 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 сайта всё ещё заслуживает своё место
Туннель или узкий шлюз — правильный ответ, когда у ресурса нет собственной аутентификации на каждый запрос: порты обслуживания баз данных, цели резервных копий, консоли гипервизора, управление вне полосы. Эти слушатели доверяют сети, поэтому именно сеть должна аутентифицировать вызывающего.
Это не единственный ответ. Шлюз, который завершает авторизацию для каждого ресурса, может быть уже туннеля на всю подсеть и оставляет лучший след аудита, чем общий промежуточный хост.
Порядок работы: завершите инвентаризацию, закройте альтернативы, проверьте один отказ на строку и только потом откажитесь от туннеля. Если строка не может дать отказ, держите частный путь, пока не сможет.