Подрядчику нужен один веб-сервис, а мы выдаём ему всю сеть.
Или почему мы сделали BusinessProxy
Это первая из двух статей. Здесь - про проблему и подход: почему сетевой доступ - неправильная единица доступа для подрядчика, которому нужно одно веб-приложение. Технический разбор - как это устроено, что мы видим на пути трафика, как сделана идентичность и какая модель угроз у коннектора - в сопроводительной статье «BusinessProxy: архитектура, идентичность и модель угроз» (опубликую следующей).
За 20 лет в ИТ и управлении доступом я видел один и тот же сценарий в десятках компаний. Приходит подрядчик на три недели - настроить отчёты в CRM. Заявки и согласования, конечно, будут. Но на выходе ему всё равно выдают VPN: это стандартный, уже готовый способ пустить внешнего человека к внутренним системам. Сделать узко, в принципе, можно - пробросить порт на периметре, выстроить цепочку SSH-туннелей через хост-бастион (а если входящий трафик закрыт - поднять обратный туннель на внешний хост), опубликовать приложение за обратным прокси с HTTP-аутентификацией. Но каждый такой вариант либо открывает наружу входящий порт, либо держится на хрупком туннеле, который никто не задокументировал, рвётся после перезагрузки и который потом некому аккуратно погасить - ни журнала, ни внятного отзыва. Нормального отдельного механизма «выдать доступ именно к этому приложению» обычно просто нет, поэтому берут то, что под рукой. И человек, которому нужно одно веб-приложение, оказывается внутри сети - с маршрутом к файловым ресурсам, серверам, SSH, тестовым стендам и всему, что достижимо из того же сегмента.
Это стало нормой по умолчанию. На мой взгляд - зря.
Ниже разберу, почему это структурная проблема, а не вопрос «плохо настроили VPN». Подход, который мы выбрали, не новый, и я не выдаю индустриальный паттерн за изобретение - наоборот, покажу, где мы стоим в ландшафте и чего не обещаем.
TL;DR. Проблема не в шифровании и не в том, что «VPN плохой». Проблема в единице доступа: VPN - это модель сетевого доступа, а подрядчику часто нужен доступ к одному приложению. Сетевую модель можно настроить безопасно, но тогда безопасность живёт в конфигурации маршрутов, ACL, правил межсетевого экрана и исключений, которые нужно постоянно поддерживать и не забывать закрывать. BusinessProxy делает единицей доступа управляемую браузерную сессию к приложению. Это не новая категория: по духу это обратный прокси с проверкой пользователя, как Cloudflare Access, Google IAP, Pomerium, Teleport. Наша ставка - не архитектурная новизна, а узкий фокус: внешний/BYOD-доступ к веб-приложениям и админкам без выдачи сетевого VPN-доступа.
1. Настоящая проблема - единица доступа, а не туннель
VPN решает свою задачу честно: он расширяет сеть до удалённого устройства. Клиент получает адрес, маршруты и сетевую достижимость. В этом нет ничего плохого, если человеку действительно нужен сетевой доступ. Но «удалённый доступ к приложению» и «подключение устройства к сети» - разные задачи, которые исторически часто решались одним инструментом. Подрядчику не нужно «быть в сети». Ему нужно «работать в одном приложении».
Когда единицей доступа становится сеть, вы платите за это тремя вещами: 1. избыточной достижимостью; 2. конфигурацией, которую нужно поддерживать корректной; 3. доступом, который трудно полностью вычистить после завершения работ.
Эта рамка перекликается с NIST SP 800-207: защита смещается от статических сетевых периметров к пользователям, устройствам и конкретным ресурсам, а доступ к корпоративному ресурсу должен выдаваться на уровне сессии и с минимально необходимыми правами.
