Почему мы сделали BusinessProxy (часть 2)
Этот пост является продолжением предыдущего Подрядчику нужен один веб-сервис, а мы выдаём ему всю сеть. Почему мы сделали BusinessProxy.
BusinessProxy не является полной реализацией Zero Trust Architecture по NIST. Под эту рамку попадают и ZTNA с агентом, и зрелый сегментированный VPN с проверкой устройства, и корпоративные платформы с IdP, состоянием устройства, SIEM и непрерывной оценкой. Мы реализуем более узкий практический паттерн: ограниченную приложением короткоживущую браузерную сессию для внешних пользователей, которым не нужно выдавать маршрут во внутреннюю сеть.
Механически это устроено просто: трафик нужного приложения направляется в шлюз через браузерное расширение (а где расширение поставить нельзя - через безагентный веб-доступ), а остальная система пользователя остаётся нетронутой. Никакого VPN-клиента и системного агента. Как именно это работает на уровне устройства, что мы видим на пути трафика и где терминируется TLS - разбираю в технической статье.
2. «Но хорошо настроенный VPN можно сегментировать» - да, и вот его цена Это первое и самое очевидное возражение, поэтому разберём его сразу. Да, сегментированный VPN способен изолировать подрядчика. Можно нарезать подсети, прописать ACL, развести VPN-зоны и правила межсетевого экрана так, что человек увидит только нужный сервис. Технически это возможно. Вопрос не в том, возможно ли. Вопрос в том, где живёт безопасность - и сколько усилий нужно, чтобы она оставалась корректной.
В сетевой модели безопасность - это свойство конфигурации: маршруты, ACL, политики межсетевого экрана, сегментация, исключения. Каждый новый внешний пользователь и каждое новое приложение добавляют отношения вида:
кто -> к чему -> откуда -> на какой срок -> с какими исключениями
Количество таких отношений растёт пропорционально произведению пользователей, приложений и сегментов. Это не экспонента и не страшилка вида 2^n. Но даже роста вида пользователи × приложения × сегменты достаточно, чтобы конфигурация стала местом, где накапливаются ошибки. При этом сессионная модель тоже требует конфигурации. У нас тоже есть список «пользователь → приложение → условия», и он тоже растёт с числом людей и приложений. Управленческое состояние никуда не исчезает.
Разница в другом: 1. Конфигурация привязана к бизнес-объекту, а не к сетевому слою. Не «маршрут в подсеть X с ACL Y», а «группа подрядчиков → CRM → только отчёты». 2. Сами сессии к приложению короткоживущие. Сетевые ACL и маршруты не исчезают сами - их кто-то должен снять. Сессия к приложению изначально создаётся с ограниченным TTL и отзывается как объект. 3. Проектный срок отделён от TTL сессии. Если подрядчику нужен доступ на три недели, это не значит, что одна сессия живёт 21 день. Сессии живут минуты или часы; проектный срок обеспечивается группой в IdP, правилом доступа, заявкой, процессом отзыва или автоматикой, которая убирает пользователя из доступа по завершении работ.
То есть дело не в том, что «у нас нет конфигурации» - она есть. Дело в том, что мы переносим конфигурацию ближе к бизнес-задаче и уменьшаем риск забытых сетевых хвостов.
Контраргумент «у зрелых команд это политики как код, Terraform и централизованное управление межсетевыми экранами» - справедлив. Автоматизация упрощает управление правилами, но не меняет единицу доступа: применение политики по-прежнему живёт на сетевом слое.
Политики как код - это лучше управляемая сетевая модель, а не другая модель доступа.
