Нужен ли вам ещё VPN, если вы используете Identity-Aware Proxy?

Предпосылка такая: как только прокси, знающий идентичность, встаёт перед внутренними приложениями, VPN — это только украшение, и клиент может уйти. Это верно для одного узкого случая, интерактивного HTTPS-приложения, которым человек пользуется в браузере, и молча ломается везде ещё. Прокси авторизует запрос к ресурсу; VPN допускает клиента в область сети, и эти две границы редко совпадают. Прежде чем отказаться от туннеля, сравните операции, которые ваши люди действительно выполняют, а не названия продуктов на схеме.

Двое ворот авторизуют разные вещи

Ворота приложения решают, может ли этот запрос от этой идентичности достичь этого защищённого ресурса. Обзор Identity-Aware Proxy от Google описывает именно эту форму: центральный слой авторизации перед HTTPS-приложениями, управляемый ролью IAM. Граница — это ресурс, а единица доступа — запрос. Маршрутизируемый VPN делает нечто более грубое и широкое: он допускает клиента в определённую область сети, после чего приложение всё ещё решает, что этот клиент может делать.

Ни одна из моделей не подразумевает другую. Прохождение ворот ничего не говорит о чтении конкретной записи, а присутствие в сети ничего не говорит о разрешении действовать.

Что прокси не покрывает, а VPN покрывает

SSH-сеансы, клиенты баз данных, брокеры сообщений и внутренние имена хостов, которые ни \ один браузер никогда не открывает, не становятся доступными только потому, что есть веб-прокси. Каждый говорит на своём протоколе, и каждому нужен либо собственный аутентифицированный путь, либо сеть, которая его несёт. Это та щель, которую люди обнаруживают в первый день миграции, обычно от дежурного инженера с ноутбуком, который больше не может разрешить имя хоста.

Обратная щель так же реальна. VPN, допускающий клиента в подсеть, не аутентифицирует человека внутри неё, а скомпрометированное устройство в этой подсети наследует всё, что разрешает сеть. Если требование — авторизация на каждый запрос с проверяемой идентичностью, одна маршрутизация его не даст. Большинство организаций в итоге держит оба, и интересный вопрос — какие ресурсы каждому разрешено прикрывать.

Рабочий процесс клиента решает больше, чем схема архитектуры

Вход в браузере с переадресацией и иногда с вызовом MFA — хороший опыт для человека, который нажимает закладку. Задача cron, CLI или агент сборки не имеют браузера и не могут ответить на интерактивный запрос, поэтому им нужен документированный неинтерактивный путь или туннель. Обнаружение этого требования обычно происходит после утверждения дизайна.

Сначала посчитайте клиентов, а уж потом приложения. Один дашборд может обслужить сто человек; один порт базы данных может заблокировать целую команду.

Состояние устройства — не свойство ни одних из ворот

Установка клиента VPN — это не проверка соответствия, и дизайн на основе браузера не становится автоматически неспособным соблюдать политику для управляемых устройств. Оба могут интегрироваться с сигналами состояния, и оба могут быть развёрнуты без них. Спросите, какое принуждение существует, кому принадлежит политика и что происходит с устройством, которое её нарушает, вместо того чтобы выводить это из формы продукта.

Та же осторожность касается и отзыва доступа. Удаление членства в группе в прокси и отозыв сертификата для туннеля — это разные операции с разной задержкой, и одну из них обычно забывают при увольнении.

Найдите альтернативные пути, прежде чем что-то отключать

Незащищённый источник за прокси, второе имя хоста, которое его обходит, или широкий частный маршрут, оставшийся от прежнего дизайна, решат, какие ворота фактически действуют. Проверьте разрешённую и запрещённую операцию через реальный клиент, а не через консоль, и проверьте их с устройства, которое никогда не регистрировалось. Именно случай отказа говорит, делают ли ворота хоть что-то.

Затем напишите передачу: регистрация, обновления, отзыв доступа и путь восстановления для того, кого заперли снаружи в 2 часа ночи. Удаление подсказки или клиентского приложения переносит ответственность между командами; оно не удаляет ответственность.

Если вы решаете на этой неделе, начните со списка операций, а не со списка продуктов, отметьте, что может выполнить браузер, и пусть остальное обосновывает тот сетевой доступ, который сохранится.