Cloudflare объявила о появлении опции в один клик, защищающей внутренние приложения на Workers с помощью своего продукта Zero Trust Access — ответ на проблему безопасности, которая обострилась вместе с ростом AI-ассистированной разработки.
Проблема, на которую нацелилась Cloudflare, вполне конкретна: AI-ассистенты для написания кода сделали создание небольших внутренних приложений быстрым и лёгким делом даже для сотрудников без технической специализации — такие инструменты часто называют "vibe-coded", то есть собранными через диалоговые подсказки, а не через продуманную архитектуру. Многие из них выходили в свет вообще без слоя аутентификации. Worker, развёрнутый для внутренней задачи — например, дашборд маршрутизации лидов или поиск по тикетам поддержки — доступен любому, кто знает или подберёт URL, если разработчик явно не добавил шаг логина. В командах без выделенной функции безопасности этот шаг часто пропускается — не по небрежности, а потому что само создание приложения уже казалось финишной чертой.
Решение Cloudflare оборачивает развёрнутые Workers существующим слоем Zero Trust Access одним действием, требуя от пользователей аутентификации через корпоративных провайдеров identity (Google Workspace, Microsoft Entra, Okta и аналогичные) прежде, чем они доберутся до приложения. От того, кто создавал исходное приложение, не требуется ни изменений кода, ни middleware, ни отдельной проверки безопасности. Функция целится именно в тот пласт внутренних инструментов, который раньше существовал в зазоре: слишком мелкие или неформальные, чтобы проходить полноценную проверку безопасности, но при этом доступные из открытого интернета точно так же, как публичные сервисы.
Для B2B-компании из 10-200 человек это закрывает класс риска, который стал более распространённым именно потому, что создавать софт стало легче. Руководитель отдела продаж, который с помощью AI-инструмента быстро написал скрипт обогащения CRM-данных, или менеджер поддержки, поднявший дашборд с данными из API хелпдеска, могут просто не задуматься над вопросом "а нужен ли здесь экран логина?" — и раньше у них не было для этого повода, поскольку настройка аутентификации обычно требовала достаточно много дополнительной инженерной работы, чтобы вынудить обратиться к кому-то более старшему. Когда порог для добавления экрана логина падает до одного клика, исчезает и оправдание для того, чтобы его пропустить.
Практический вывод для операционных руководителей — это аудит, а не переделка. Любое внутреннее приложение на Workers, созданное за последний год, особенно быстро собранное с помощью AI-ассистентов, стоит проверить на предмет того, стоит ли оно за Access или любой другой аутентификацией. Там, где это не так, включение защиты в один клик — недорогое исправление. Для команд, которые решают, какие внутренние инструменты строить дальше, это также ослабляет аргумент против быстрой разработки: если обёртка безопасности теперь превратилась в галочку, а не в отдельный проект, довод в пользу создания внутренних AI-ассистированных инструментов без оглядки на безопасность становится сильнее, а не слабее. Изменение не решает проблему аутентификации на других платформах — описанный риск специфичен именно для развёртываний на Cloudflare Workers и не распространяется на внутренние инструменты, размещённые в другом месте, для которых по-прежнему нужны собственные средства контроля доступа этой платформы.