Каждый безопасный веб-шлюз на рынке работает одинаково: трафик соответствует определенному условию, после чего выполняется конечное действие. Разрешить, заблокировать, изолировать, записать в журнал. Эта модель является основой сетевой безопасности уже почти 30 лет, и она хорошо справляется с типичными задачами. Однако у нее есть предел, и клиенты со сложными средами регулярно с ним сталкиваются.
Ранее в этом году мы поделились своим видением создания по-настоящему программируемой SASE-платформы. Мы также отметили, как термин «программируемость» был обесценен индустрией безопасности. Большинство вендоров заявляют о программируемости, потому что у них есть публичные API, провайдеры Terraform, вебхуки и системы оповещения. Cloudflare также предлагает все это, но этого недостаточно. Истинная программируемость означает выполнение вашего собственного кода — произвольной логики, написанной вами для вашей конкретной среды — непосредственно в процессе оценки политики, в тот самый момент, когда принимается решение по безопасности.
Сегодня мы рады объявить, что Cloudflare привносит истинную программируемость в Cloudflare Gateway и DLP (предотвращение утечек данных), интегрируя их со всей нашей платформой граничных вычислений. Мы выпускаем новый тип действия шлюза — Forward (Пересылка) — и функции пользовательской проверки, доступные во всех планах Zero Trust. Эти возможности позволяют использовать Cloudflare Worker для преобразования и обработки трафика или для использования собственных данных при оценке политик.
Компромисс, с которым сталкивается каждая команда безопасности
С момента появления межсетевых экранов бизнес сталкивается с бинарным выбором. Вы можете поддерживать собственный механизм обнаружения угроз — свой межсетевой экран, свою прокси-инфраструктуру — с высокими затратами на обслуживание и низкой переносимостью, в обмен на максимальную кастомизацию. Либо вы можете принять ограничения вендора, переложив значительные расходы на обслуживание, но пожертвовав гибкостью в решении задач, специфичных для вашей среды.
За шесть лет создания Cloudflare Gateway мы услышали от тысяч клиентов, которые борются с этим компромиссом. Команде безопасности, мигрирующей средства контроля доступа для критически важного внутреннего приложения, необходимо внедрять HTTP-заголовки на основе утверждений JSON Web Token (JWT) от своего поставщика идентификационных данных. Данные существуют в контексте запроса, но Gateway не может прочитать JWT и записать заголовок. Поэтому команда разворачивает пул прокси-серверов NGINX исключительно для выполнения этого преобразования. Эту инфраструктуру теперь нужно патчить, отслеживать и защищать... бесконечно.
Другая команда хочет получать уведомление в Slack в тот момент, когда сотрудник регистрируется в новом SaaS-сервисе. Механизм политик может обнаружить событие регистрации, но он может только разрешить или заблокировать его. Поэтому команда создает конвейер Logpush-to-SIEM-to-Slack с задержкой от 5 до 15 минут и без гарантии доставки. И при этом добавляет еще один элемент инфраструктуры.
Десятки корпоративных клиентов просили создать страницы предупреждений, которые запрашивают у пользователей обоснование перед предоставлением доступа к конфиденциальным ресурсам. Большинство затем хотят настроить последующее поведение на основе дополнительного контекста о том, кто является пользователем и какой уровень доступа запрашивается. Но предоставление кастомизированных динамических ответов из механизма политик — крайне сложная задача.
На протяжении многих лет мы предлагали клиентам множество точек расширения. Но, как и у любого другого вендора межсетевых экранов, невозможно создавать функции для покрытия векторов угроз так же быстро, как они появляются. Тем не менее, мы также признаем, что лучшие решения — это те, которые бесконечно расширяемы для вашей среды.
Почему только Cloudflare может решить эту проблему
Cloudflare — это не просто межсетевой экран, безопасный веб-шлюз, сеть доставки контента или граничный сервис. Cloudflare — это компонуемая вычислительная платформа. Cloudflare Workers уже позволяет клиентам запускать сложную логику на границе нашей сети из любой из наших более чем 330 точек по всему миру. Cloudflare Gateway уже оценивает и применяет политику безопасности к пользовательскому трафику в тех же местах, на тех же машинах, в тех же центрах обработки данных.
Только Cloudflare запускает как распределенные вычисления клиентов, так и полнофункциональный безопасный веб-шлюз и межсетевой экран в одной и той же глобально распределенной сети. У нас есть уникальная возможность и способность объединить эти функции в первую в отрасли полностью программируемую и настраиваемую SASE-платформу.
Gateway и Workers с самого начала были построены на одной инфраструктуре. Когда Gateway пересылает трафик в Worker, эта диспетчеризация является локальным вызовом функции. Здесь нет «hairpinning» (возвратного трафика). Нет дополнительной задержки от пересечения сетевой границы. Это первый случай, когда клиенты получат абсолютный контроль над тем, как обрабатывается их проксируемый трафик, без компромиссов, используя код, который они могут писать и выполнять, не поддерживая никакой инфраструктуры.
Автономные SASE-провайдеры без собственной вычислительной платформы требуют от вас развертывания автоматизации в отдельном облаке, ручной настройки вебхуков и принятия задержек при передаче данных туда и обратно, а также управленческих накладных расходов на связывание разрозненных систем. Ни у одного другого вендора в этой области нет программируемой платформы граничных вычислений, расположенной совместно с их шлюзом безопасности. Поскольку угрозы развиваются со скоростью ИИ, это обеспечит столь необходимую гибкость и маневренность для организаций, занимающихся безопасностью.
Две точки входа в Gateway: действие Forward и пользовательские функции
Новый тип действия Gateway под названием Forward и новый ресурс политики под названием Custom Function — это два разных способа вызова Worker из политики Gateway. Действие Forward доступно в публичной бета-версии уже сегодня, а пользовательские функции станут доступны до конца года.
Действие Forward: преобразование трафика и проксирование
Вы можете настроить поведение HTTP-трафика с помощью нового действия политики под названием Forward, которое направляет соответствующий HTTP-запрос в Worker в качестве прокси. Политики с действием Forward оцениваются для трафика, разрешенного HTTP-политиками. Первое соответствующее правило Forward будет применено к вашему трафику, и трафик будет отправлен на привязанный к нему Cloudflare Worker. Worker действует как встроенное промежуточное ПО: он получает полные заголовки и тело запроса. Ваша логика может затем выбрать изменение любого из них (или выполнить другое асинхронное действие), переслать запрос к источнику, получить ответ, также изменить его и вернуть окончательный ответ пользователю.
Gateway обрабатывает TCP-соединения, завершение и повторное шифрование TLS, управление сертификатами и согласование версий HTTP. Worker отвечает только за логику преобразования. Вы получаете настраиваемую точку расширения, подобную прокси, для вашего существующего стека безопасности, без каких-либо эксплуатационных затрат на хостинг традиционного HTTP-прокси.
Вашим Workers также не обязательно преобразовывать запрос. Единственной целью правила может быть проксирование запроса к Worker, который асинхронно получает полный контекст соответствующего запроса: отправить сообщение в Slack, записать в R2, отправить в журнал внешнего конвейера, вызвать вебхук, обновить хранилище KV. Трафик может продолжать движение к месту назначения без помех.
Пользовательские функции: встроенная оценка политики
Пользовательская функция вызывает Worker в процессе оценки политики Gateway и возвращает значение. Затем функция становится доступна в качестве селектора в конструкторе политик Gateway, и этот селектор оценивается на основе своих значений. Селектор можно использовать в условии любого сетевого или HTTP-правила Gateway, точно так же, как сегодня работают встроенные селекторы, такие как «Исходный IP» или «Категория контента».
Worker получает контекст запроса: исходный IP-адрес, пункт назначения, идентификационные данные пользователя, состояние устройства, HTTP-заголовки и многое другое, в зависимости от этапа политики. Worker возвращает типизированное значение (строку, число или логическое значение), которое Gateway использует в условиях правил. Контракт прост: данные на входе, значение на выходе.
Вот пример пользовательской функции, которая анализирует заголовок авторизации JWT и возвращает роль пользователя:
После развертывания этой функции администратор может создать правило HTTP-политики: Пользовательская функция «Роль JWT» содержит «finance_contractor» с действием «Разрешить». Пользовательская функция становится частью условия правила и оценивается наряду со всеми остальными селекторами.
Пользовательские функции не ограничиваются только HTTP-трафиком. Поскольку они получают идентификационные данные, состояние устройства и метаданные соединения вместо полного HTTP-запроса, их можно использовать в конструкторе сетевых политик Gateway для любого трафика на уровне 4 (L4) по портам и протоколам.
Сам Worker может делать все, что уже умеет делать Worker — вызывать внешние API, считывать данные из KV или D1, или вызывать Workers AI. Но с точки зрения Gateway функция детерминирована: данные на входе, значение на выходе.
Когда использовать пользовательскую функцию или действие Forward
Пользовательские функции предназначены для быстрой, ограниченной и не сохраняющей состояние оценки данных, которые могут возвращать сформированный ответ. Их использование следует рассматривать аналогично данным, которые уже могут оцениваться в селекторах Gateway; то есть вычислениям на основе данных, существующих в рамках набора критериев, например: «Порты в этом диапазоне» или «URL-пути, соответствующие этому регулярному выражению». Сила этого подхода заключается в возможности расширить ваши структурированные оценки произвольными или внутренними источниками данных, примеры которых вы увидите ниже.
Действие Forward требует немного больше планирования и подготовки. Его можно использовать для мощных преобразований в режиме реального времени непосредственно в запросах пользователей, а также для сложного манипулирования ими как на выходе, так и при возврате к исходному сервису. Их следует рассматривать как функции преобразования — концепция, которую сегодня используют лишь немногие корпоративные прокси-серверы безопасности. Workers, использующие действие Forward, должны быть целенаправленными и тщательно спроектированными, чтобы избежать негативного влияния на общий пользовательский опыт.
Что вы можете создать
Обоснование цели и промежуточные страницы
Worker перехватывает запрос к конфиденциальному ресурсу и возвращает промежуточную страницу, требующую от конечного пользователя предоставить письменное обоснование доступа. Worker вызывает Cloudflare KV, чтобы записать сессию с TTL, поэтому пользователю предлагается сделать это только один раз за настроенный период. Он записывает идентификационные данные пользователя и его обоснование в Cloudflare D1, создавая контрольный журнал. Или вы можете использовать Hyperdrive, чтобы записать эту запись в любую внутреннюю базу данных, которую вы уже используете.
Это была одна из наших самых востребованных функций на протяжении более четырех лет. Благодаря тому, что Worker может обрабатывать и изменять HTTP-трафик, легко создавать решения в соответствии с вашими собственными стандартами.
Динамическая вставка HTTP-заголовков
Пользовательская функция анализирует JWT из заголовка Authorization запроса, извлекает роль пользователя или его принадлежность к группе и возвращает это как значение селектора. Правило Gateway сопоставляет это значение и устанавливает заголовок X-App-Role в восходящем запросе. Никаких пулов прокси-серверов NGINX. Никакой дополнительной инфраструктуры для обслуживания.
Проверка файлов и ведение журнала
Когда загрузка файла соответствует определенным критериям, Worker может отправить файл в сторонний сервис «песочницы» для детонации и анализа. Или он может записать файл целиком в в качестве постоянной записи для последующей проверки, при этом файл никогда не покинет сеть Cloudflare.
Оповещение в реальном времени о совпадении с политикой
Worker, привязанный к политике Forward, получает трафик всякий раз, когда срабатывает профиль предотвращения потери данных (DLP). Worker отправляет сообщение в канал Slack или на конечную точку PagerDuty с адресом электронной почты пользователя, сработавшим правилом и целевым URL-адресом.
Сложная логика оценки
Традиционные конструкторы выражений для брандмауэров не предназначены для тех вычислений, которые требуются некоторым организациям во время оценки. Если вы поддерживаете внутренние системы оценки рисков, которые выполняют поведенческий анализ по нескольким источникам данных, или если у вас есть сложные карты пользователей, групп и условных членств, где несколько критериев должны быть истинными независимо друг от друга, вы можете использовать пользовательскую функцию в качестве вычислительного расширения, которое оценивает всю эту логику и возвращает единое значение в Gateway.
Производительность и надежность
Поскольку сервисы Gateway и Workers работают на одних и тех же машинах в сети Cloudflare, отправка запроса в Worker не создает дополнительного сетевого перехода. Влияние на производительность ограничивается временем выполнения кода вашего Worker.
Когда пользовательская функция дает сбой — выдает исключение, превышает время ожидания или возвращает неожиданное значение — вы настраиваете поведение при сбое для каждой функции. В контракте пользовательской функции требуются значения по умолчанию, чтобы было легко определить поведение.
Доступность и ценообразование
Действие Forward и его интеграция с Workers доступны в публичной бета-версии с сегодняшнего дня, а пользовательские функции ожидаются до конца года. После общего выпуска обе функции будут доступны всем клиентам на всех типах планов.
Трафик, отправляемый в ваши Workers, тарифицируется как стандартные запросы Worker. Функция работает с Workers Free, Workers Paid и Workers for Enterprise без ограничений по функциональности. У Workers Free есть ограничения по времени выполнения и количеству запросов в день, что стоит учитывать при масштабировании объема трафика Gateway, который вы отправляете в свои Workers.
Пользовательские функции DLP для проверки обнаружения в режиме реального времени
Полностью программируемая платформа SASE выходит за рамки простого Gateway. Наше предложение DLP, уже интегрированное в Gateway, AI Gateway, Email Security и другие продукты, теперь также поддерживает пользовательские результаты благодаря интеграции с нашей вычислительной платформой.
Большинство продуктов для обеспечения безопасности данных работают путем поиска данных, соответствующих известным шаблонам. Клиенты обычно могут определять регулярные выражения, списки слов или аналогичные инструменты для выполнения этих обнаружений. Они также могут повысить уверенность в совпадении за счет использования ключевых слов или контекстного анализа тела запроса. Но у этих методов есть основной недостаток: такие типы обнаружения могут сказать вам только тогда, когда что-то соответствует шаблону данных, имеющему отношение к вашей организации, но не то, указывает ли этот конкретный экземпляр данных на утечку или неправомерное использование.
Поскольку злоумышленники становятся все более изощренными, а агенты могут использоваться для безжалостной эксплуатации систем, простого улучшения нашей способности точно обнаруживать закономерности уже недостаточно. Чтобы повысить точность обработки важных данных, вам необходимо знать, имеют ли рассматриваемые данные активное отношение к вашей организации.
Для решения этой проблемы большинство решений используют точное сопоставление данных (Exact Data Match), но у этого подхода есть свои недостатки. Клиенты должны подготавливать, поддерживать и передавать эталонные наборы данных, а затем решать, насколько они готовы доверить поставщику управление данными из своих наиболее конфиденциальных систем.
Пользовательские функции проверки для DLP устраняют этот разрыв, и они доступны уже сегодня. Эти пользовательские функции позволяют клиентам определять собственную логику проверки, используя свой собственный источник достоверных данных непосредственно внутри Cloudflare Worker… и применять ее везде, где они используют DLP для защиты своих конфиденциальных данных.
Проверка учетных данных и секретов
Когда запись обнаружения DLP совпадает, может быть запущен исходящий Worker для выполнения логики проверки перед принятием решения о применении политики. Если у вас есть профили для обнаружения использования секретов GitHub, но вас интересуют только активные секреты, вы можете использовать Worker, чтобы сначала проверить статус обнаруженного ключа, получить ответ от соответствующей конечной точки GitHub, а затем решить, должен ли профиль DLP соответствовать трафику.
Что дальше
Это только начало полностью программируемой платформы SASE. Мы активно работаем над увеличением количества точек входа, из которых вы можете отправлять пользовательские функции во весь пакет Cloudflare One, причем Email Security будет следующим. Это не значит, что мы закончили разработку: эта новая архитектура упростит нам создание собственных функций для всех сервисов Cloudflare One — быстрее, гибче и с улучшенным опытом для разработчиков.
Также с каждым днем становится все проще защищать ваши Workers, агенты и их трафик с помощью Cloudflare One. Если вы являетесь корпоративным клиентом и хотите провести стратегическую сессию по внедрению, получить предварительный просмотр будущих функций или узнать о бета-версии пользовательских функций, пожалуйста, свяжитесь с вашей командой по работе с клиентами.
Безопасность вашей организации теперь может делать все, что может делать Cloudflare Worker. Мы с нетерпением ждем того, что вы создадите.
