Почему мы сделали BusinessProxy (часть 3)
Этот пост является продолжением предыдущего Почему мы сделали BusinessProxy (часть 2)
3. Модель угроз: радиус поражения Сетевая достижимость - это не только удобство. Это поверхность атаки после компрометации.
Если устройство или учётка подрядчика скомпрометированы в VPN-модели, атакующий получает то же, что и легитимный пользователь: сетевую видимость сегмента. Можно сканировать соседние хосты, искать сервисы, проверять открытые порты, пробовать горизонтальное перемещение. В сессионной модели внешний пользователь не находится «в сети». Он работает с приложением через посредник доступа. Сетевого маршрута для горизонтального перемещения с устройства пользователя нет - именно это мы и убираем.
Но «доступ к одному приложению» не означает автоматически «маленький радиус поражения». Само приложение может вести к файлам, интеграциям, админским API, вебхукам, экспортам, сервисным токенам. Если у подрядчика в CRM широкие права, радиус внутри CRM может быть большим - независимо от того, пришёл он туда через VPN, ZTNA или BusinessProxy.
Мы убираем сетевое горизонтальное перемещение со стороны внешнего устройства. Радиус внутри приложения определяется его правами, ролями, интеграциями и данными. Это зона ответственности владельца приложения и его IAM/RBAC-модели, а не только транспорта.
4. Почему это особенно болит на офбординге Спросите себя про последнего подрядчика, которому открывали доступ: сколько заняла настройка - и были ли вы потом до конца уверены, что доступ полностью закрыт?
В сетевой модели «полностью закрыть» - это вспомнить все правила, маршруты, исключения и учётки, заведённые под этого человека за время проекта, и аккуратно их снять. На практике что-то остаётся: правило, про которое забыли; учётка «потом удалим»; временное исключение, ставшее постоянным.
Сессия снимает транспортный/периметровый доступ архитектурно: это объект с владельцем, областью и коротким TTL. Он истекает сам или отзывается одним действием.
Но короткий TTL сессии - это не то же самое, что завершение проектного доступа. Если пользователь остаётся в разрешённой группе, правиле доступа или IdP-группе, он сможет запустить новую короткую сессию. Для завершения проекта нужно убрать его из группы, правила доступа или IdP-процесса и, если нужно, отозвать активные сессии.
Ещё одна важная граница: это не всегда закрывает учётную запись внутри самого приложения. Если подрядчику завели пользователя в CRM, сессия BusinessProxy истекла - а CRM-аккаунт остался. Для этого у нас уже есть нормальная основа идентичности - внешние идентичности через OIDC, группы, привязка доступа к IdP-группам (детали - в технической статье). Но полный жизненный цикл в стиле «пользователь исчез из IdP → закрыты все доступы и учётки во всех приложениях» требует поддержки SCIM для синхронизации учёток и интеграции с самими приложениями. Это отдельный слой, и его нельзя подменять короткоживущей сессией.
Проще: BusinessProxy закрывает доступ к приложению и даёт управляемую идентичность на уровне посредника доступа. Но учётками внутри приложения должен управлять IdP, само приложение или процесс заказчика.
5. Это не новая категория. И да - «почему не Cloudflare Access?»
Ну во-первых мы живем в России…
Управляемый браузерный доступ к приложению через посредник с исходящим коннектором - это известный паттерн обратного прокси с проверкой пользователя и сессионным контролем. Его в разных формах реализуют Cloudflare Access, Google IAP, Zscaler ZPA Browser Access, Pomerium, Teleport, oauth2-proxy и другие решения.
Поэтому правильный вопрос ИБ-специалиста звучит так: Если Cloudflare Access, Google IAP, Zscaler и обратные прокси с открытым кодом уже существуют, зачем ещё один продукт?
Ответ: мы не пытаемся конкурировать с крупными ZTNA/SSE-платформами по ширине корпоративного стека. Наш фокус уже: быстрый ограниченный приложением доступ для внешних и BYOD-пользователей к конкретным веб-приложениям и админкам там, где полноценный ZTNA/SASE-проект избыточен организационно или экономически.
