Полностью программируемый защищённый веб-шлюз15.10.2026 20:11

Все представленные на рынке защищённые веб-шлюзы работают одинаково: трафик соответствует условию. Срабатывает завершающее действие: разрешить, заблокировать, изолировать, зарегистрировать. Эта модель лежит в основе сетевой безопасности почти 30 лет и хорошо справляется с типичными задачами. Но у неё есть предел, и клиенты со сложной инфраструктурой регулярно в него упираются.

Ранее в этом году мы рассказали о своём видении по-настоящему программируемой платформы SASE. Мы также объяснили, как индустрия безопасности размыла смысл термина программируемость. Большинство поставщиков заявляют о программируемости, потому что у них есть общедоступные API, провайдеры Terraform, вебхуки и оповещения. Cloudflare предлагает всё это, но этого недостаточно. Настоящая программируемость означает возможность запускать собственный код — произвольную логику, написанную для конкретной среды, — непосредственно в процессе оценки политик, в тот момент, когда принимается решение о безопасности.

Сегодня мы рады сообщить, что Cloudflare внедряет настоящую программируемость в Cloudflare Gateway и DLP (защиту от потери данных), интегрируя их со всей нашей платформой периферийных вычислений. Мы выпускаем новый тип действия Gateway — Forward, а также пользовательские функции проверки, доступные на всех тарифах Zero Trust. Эти возможности позволяют использовать Cloudflare Worker для преобразования и обработки трафика или передавать собственные данные для оценки политик.

Компромисс, перед которым стоит каждая команда по безопасности

С момента появления межсетевых экранов компании вынуждены выбирать из двух вариантов. Можно поддерживать собственный механизм обнаружения угроз — свой межсетевой экран и собственную прокси-инфраструктуру, — получая максимальные возможности настройки ценой высоких затрат на обслуживание и низкой переносимости. Или можно принять ограничения поставщика и переложить на него значительные расходы на обслуживание, пожертвовав гибкостью при решении задач, характерных для вашей среды.

За шесть лет работы над Cloudflare Gateway мы услышали от тысяч клиентов о трудностях, связанных с этим компромиссом. Команда безопасности, переносящая механизмы контроля доступа для критически важного внутреннего приложения, должна добавлять HTTP-заголовки на основе утверждений JSON Web Token (JWT) от поставщика удостоверений. Данные есть в контексте запроса, но Gateway не может прочитать JWT и добавить заголовок. Поэтому команда разворачивает пул прокси-серверов NGINX исключительно для выполнения этого преобразования. Теперь эту инфраструктуру нужно обновлять, отслеживать и защищать… бесконечно.

Другая команда хочет получать уведомление в Slack сразу после того, как сотрудник зарегистрируется в новом SaaS-сервисе. Механизм политик может обнаружить событие регистрации, но способен лишь разрешить или заблокировать запрос. Поэтому команда строит цепочку Logpush — SIEM — Slack, где задержка составляет от 5 до 15 минут и нет гарантии доставки. И добавляет в инфраструктуру ещё один компонент.

Десятки корпоративных клиентов просили добавить страницы-предупреждения, на которых перед предоставлением доступа к конфиденциальным ресурсам пользователи должны обосновать свой запрос. Большинство из них затем хотят настраивать дальнейшее поведение с учётом дополнительных сведений о пользователе и запрашиваемом уровне доступа. Однако выдавать динамические ответы с индивидуальными настройками из механизма политик крайне сложно.

На протяжении многих лет мы предлагали клиентам различные точки расширения. Но, как и любому другому поставщику межсетевых экранов, нам невозможно разрабатывать функции для всех векторов угроз так же быстро, как они появляются. В то же время мы понимаем: лучшие решения — те, которые можно безгранично адаптировать к вашей среде.

Почему решить эту задачу под силу только Cloudflare

Cloudflare — это не просто межсетевой экран, защищённый веб-шлюз, сеть доставки контента или периферийный сервис. Cloudflare — это комбинируемая вычислительная платформа. Cloudflare Workers уже позволяет клиентам запускать сложную логику на периферии нашей сети более чем в 330 точках по всему миру. Cloudflare Gateway уже оценивает и применяет политики безопасности к пользовательскому трафику в тех же точках, на тех же машинах и в тех же центрах обработки данных.

Только Cloudflare одновременно предоставляет распределённые вычислительные ресурсы для клиентов, полнофункциональный защищённый веб-шлюз и межсетевой экран в одной глобально распределённой сети. У нас есть уникальная возможность объединить эти функции и создать первую в отрасли полностью программируемую и настраиваемую платформу SASE.

Gateway и Workers с самого начала создавались на одной инфраструктуре. Когда Gateway перенаправляет трафик в Worker, это локальный вызов функции. Трафик не проходит по петле через сеть. Пересечение сетевой границы не добавляет задержек. Впервые клиенты получат полный контроль над обработкой проксируемого трафика без компромиссов — с помощью кода, который можно написать и запустить, не обслуживая никакую инфраструктуру.

Поставщики SASE без собственной вычислительной платформы требуют развёртывать автоматизацию в отдельном облаке, вручную настраивать вебхуки и мириться с задержкой кругового обмена данными и расходами на управление разрозненными системами. Ни у одного другого поставщика в этой области нет программируемой периферийной вычислительной платформы, размещённой вместе с защищённым шлюзом. По мере того как угрозы развиваются со скоростью искусственного интеллекта, это обеспечит организациям по безопасности столь необходимую гибкость и оперативность.

Два способа подключения Gateway: действие Forward и пользовательские функции

Новый тип действия Gateway под названием Forward и новый ресурс политики — пользовательская функция — представляют собой два разных способа вызвать Worker из политики Gateway. Действие Forward доступно в публичной бета-версии уже сегодня, а пользовательские функции появятся до конца года.

Действие Forward: преобразование трафика и проксирование

Настроить обработку HTTP-трафика можно с помощью нового действия политики под названием Forward, которое направляет соответствующий HTTP-запрос в Worker, работающий в качестве прокси. Политики с действием Forward применяются к трафику, разрешённому HTTP-политиками. Затем к трафику применяется первое подходящее правило Forward, и он отправляется в связанный с правилом Cloudflare Worker. Worker действует как промежуточное ПО: он получает все заголовки и тело запроса. Затем ваша логика может изменить их, выполнить какое-либо асинхронное действие, перенаправить запрос к исходному серверу, получить ответ, изменить и его, а затем вернуть пользователю окончательный ответ.

import { WorkerEntrypoint } from "cloudflare:workers";
import type {
  GatewayMiddlewareContext,
  GatewayMiddlewareNext,
} from "@cloudflare/zt-types";

export class GatewayMiddleware extends WorkerEntrypoint {
  async handle(
    request: Request,
    context: GatewayMiddlewareContext,
    next: GatewayMiddlewareNext,
  ): Promise<Response> {
    // Read a value from the Gateway context
    const clientIP = context.srcIp;

    // Add headers before the request reaches the origin
    request.headers.set("X-Gateway-Client-IP", clientIP);

    // Forward upstream and get the response
    const response = await next(request);

    // Modify the response before it reaches the user
    response.headers.set("X-Processed-By", "gateway-middleware");

    return response;
  }
}

Gateway обрабатывает TCP-соединения, завершает TLS и шифрует трафик заново, управляет сертификатами и согласованием версии HTTP. Worker отвечает только за логику преобразования. Вы получаете настраиваемую точку расширения, похожую на прокси, для существующего стека безопасности — без эксплуатационных расходов на размещение традиционного HTTP-прокси.

Ваши Workers не обязательно должны преобразовывать запрос. Единственная задача правила может заключаться в том, чтобы проксировать запрос в Worker, который асинхронно получает весь контекст соответствующего запроса: отправлять сообщения в Slack, записывать данные в R2, вести журнал во внешнем конвейере, вызывать вебхук, обновлять хранилище KV. При этом трафик может беспрепятственно продолжить путь к месту назначения.

Пользовательские функции: оценка политик в режиме реального времени

Во время оценки политики Gateway пользовательская функция обращается к Worker и возвращает значение. Затем функция становится доступна в конструкторе политик Gateway как селектор, который оценивается по возвращаемым значениям. Этот селектор можно использовать в условии любого сетевого правила Gateway или правила HTTP — так же, как сегодня работают встроенные селекторы, например Source IP или Content Category.

Worker получает сведения о запросе: IP-адрес источника, назначение, личность пользователя, состояние устройства, HTTP-заголовки и многое другое — в зависимости от этапа обработки политики. Worker возвращает типизированное значение (строку, число или логическое значение), которое Gateway использует в условиях правила. Принцип прост: данные на входе, значение на выходе.

Вот пример пользовательской функции, которая анализирует заголовок JWT Authorization и возвращает роль пользователя:

export class GatewayCustomSelector extends WorkerEntrypoint {
  async compute(ctx: GatewayContext): Promise<string> {
    const authHeader = ctx.request.headers.get("Authorization");
    if (!authHeader) return "anonymous";

    const token = authHeader.replace("Bearer ", "");
    const payload = JSON.parse(atob(token.split(".")[1]));
    return payload.groups?.[0] ?? "unknown";
  }
}

После развёртывания этой функции администратор может создать правило HTTP-политики: пользовательская функция «Роль JWT» содержит «finance_contractor» с действием «Разрешить». Пользовательская функция становится частью условия правила и оценивается вместе со всеми остальными селекторами.

Пользовательские функции не ограничиваются HTTP-трафиком. Поскольку вместо полного HTTP-запроса они получают данные о личности пользователя, состоянии устройства и соединении, их также можно использовать в конструкторе сетевых политик Gateway для произвольного трафика на уровне 4 модели OSI — с любыми портами и протоколами.

Сам 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 R2 для последующей проверки — файл при этом ни разу не покинет сеть Cloudflare.

Оповещения в реальном времени при срабатывании политики

Worker, связанный с политикой Forward, получает трафик при каждом срабатывании профиля защиты от потери данных (DLP). Worker отправляет сообщение в канал Slack или на адрес PagerDuty, указывая электронную почту пользователя, сработавшее правило и URL назначения.

export default {
  async invoke(ctx: GatewayContext, env: Env): Promise<void> {
    await fetch(env.SLACK_WEBHOOK_URL, {
      method: "POST",
      body: JSON.stringify({
        text: `DLP alert: ${ctx.identity.email} triggered "${ctx.rule.name}" accessing ${ctx.request.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 и другими сервисами, теперь также поддерживает пользовательские сценарии обработки благодаря интеграции с платформой Compute.

Большинство продуктов для защиты данных ищут данные, соответствующие известным шаблонам. Как правило, клиенты могут задавать для обнаружения регулярные выражения, списки слов и другие подобные критерии. Уверенность в результатах также можно повысить с помощью ключевых слов или анализа контекста тела запроса. Однако у этих методов есть принципиальный недостаток: такие механизмы обнаружения могут лишь определить, соответствует ли информация шаблону данных, представляющих интерес для организации, но не то, указывает ли конкретный набор данных на утечку или неправомерное использование.

По мере того как злоумышленники становятся всё изощрённее, а агенты позволяют безжалостно эксплуатировать системы, одной лишь способности точнее обнаруживать шаблоны уже недостаточно. Чтобы точнее выявлять действительно важные данные, нужно знать, имеют ли они непосредственное отношение к вашей организации.

Для решения этой задачи большинство продуктов используют точное сопоставление данных, однако и у этого подхода есть свои компромиссы. Клиентам приходится готовить, поддерживать и передавать справочные наборы данных, а затем решать, насколько они готовы доверить поставщику управление данными из своих наиболее конфиденциальных систем.

Пользовательские функции проверки для DLP устраняют этот разрыв и доступны уже сегодня. С их помощью клиенты могут задавать собственную логику проверки, используя свои источники достоверных данных, непосредственно в Cloudflare Worker…, а затем применять её везде, где DLP защищает конфиденциальные данные.

Проверка учётных данных и секретов

При обнаружении записи DLP для выполнения проверки до принятия решения о применении политики может вызываться Worker, обрабатывающий исходящие запросы. Если у вас есть профили для обнаружения секретов GitHub, но вас интересуют только действующие секреты, Worker может сначала проверить статус обнаруженного ключа, получить ответ от соответствующей конечной точки GitHub, а затем определить, должен ли профиль DLP применяться к этому трафику.

import {
  DlpValidation,
  type DlpValidationInput,
  type DlpValidationResult,
} from "@cloudflare/zt-types";

export class DlpValidationEntrypoint extends DlpValidation {
  async validate({ excerpt, start, end }: DlpValidationInput): Promise<DlpValidationResult> {
    const bytes = Uint8Array.from(atob(excerpt), (c) => c.charCodeAt(0));
    const token = new TextDecoder().decode(bytes.slice(start, end));

    const res = await fetch("https://api.GitHub.com/user", {
      headers: {
        Authorization: `Bearer ${token}`,
        "User-Agent": "dlp-GitHub-validator",
        Accept: "application/vnd.GitHub+json",
      },
    });

    if (res.ok) return { score: 1.0 }; // token is valid and active
    if (res.status === 401) return { score: "veto" }; // token is invalid, discard
    return { score: 0 };
  }
}

Что дальше

Это только начало создания полностью программируемой платформы SASE. Мы активно работаем над тем, чтобы расширить возможности вызова пользовательских функций во всём наборе сервисов Cloudflare One. Следующей станет Email Security. Но это не значит, что работа над платформой завершена: новая архитектура позволит нам быстрее и гибче добавлять собственные функции во все сервисы Cloudflare One и улучшать опыт разработчиков.

С каждым днём становится проще защищать свои Workers, агентов и их трафик с помощью Cloudflare One. Если вы корпоративный клиент и хотите обсудить стратегию внедрения, получить предварительный доступ к готовящимся функциям или узнать о выходе бета-версии пользовательских функций, свяжитесь со своей командой по работе с клиентами.

Теперь ваша организация может использовать все возможности Cloudflare Worker для обеспечения безопасности. Нам не терпится увидеть, что вы создадите.

© Cloudflare Blog