Проблема «Удаленного доступа»
Чтобы дать подрядчику доступ к одному приложению, не нужно пускать его во всю остальную сеть. Но слишком часто так всё ещё и происходит.
Мы привыкли к этому. А зря.
Трёхнедельный проект в вашей CRM не требует доступа к файловым ресурсам, серверам, SSH и всему остальному, что достижимо из того же сегмента сети. Но во многих компаниях так до сих пор и устроено по умолчанию — потому что инструменты создавались, чтобы «подключить устройство к сети», а не чтобы «дать конкретному человеку работать в конкретном приложении».
Хорошо сегментированный VPN способен это изолировать. Но тогда безопасность начинает зависеть от средств сетевого уровня — маршрутов, ACL, правил межсетевого экрана и сегментации, — которые должны оставаться корректными по мере того, как растёт число подрядчиков, приложений и исключений.
Проблема никогда не была в шифровании. Проблема — в единице доступа.
Для многих SaaS-сервисов и внутренних веб-приложений рабочим периметром сегодня стал браузер. Единицей доступа должна быть сессия к приложению — ограниченная, журналируемая, отзываемая, — а не туннель на уровне сети.
Ради решения этой проблемы мы и создали BusinessProxy.
Вспомните последнего подрядчика, которому вы открывали доступ к одному внутреннему приложению: сколько времени заняла настройка — и были ли вы потом до конца уверены, что его доступ полностью закрыт?
Полная версия статьи Подрядчику нужен один веб-сервис, а мы выдаём ему всю сеть. Или почему мы сделали BusinessProxy
