Потолок классической модели
Secure web gateway — это инструмент, который применяет политики к веб-трафику на основе условий: совпал IP, категория сайта, тип файла — сработало действие. Эта логика «условие → терминальное действие» (Allow, Block, Isolate, Log) была основой сетевой безопасности почти три десятилетия, и для массового трафика она отлично работает. Проблема начинается там, где организации нужно не просто заблокировать или пропустить запрос, а что-то с ним сделать: дописать заголовок на основе данных из токена, показать пользователю динамическую страницу с запросом обоснования доступа, или мгновенно уведомить команду безопасности о подозрительном событии вместо того, чтобы ждать, пока лог дойдёт до SIEM. Классический gateway для этого не предназначен — он проверяет условия, а не исполняет бизнес-логику.
Отсюда и возникают те самые «инфраструктурные хвосты», которые знакомы любой крупной команде безопасности: отдельный пул NGINX-прокси только для того, чтобы прочитать JWT и подставить заголовок, или цепочка Logpush → SIEM → Slack с задержкой в несколько минут и без гарантии доставки. Это рабочие решения, но они означают добавление ещё одной системы, которую нужно патчить, мониторить и защищать — причём бессрочно.
Что на самом деле значит слово «программируемость»
В индустрии безопасности слово «programmability» давно девальвировалось. Публичный API, провайдер Terraform, вебхуки и алертинг — всё это у большинства вендоров уже есть, и всё это называют «программируемостью». Но между «дёрнуть внешний API после события» и «выполнить собственный код внутри пути принятия решения, в момент оценки политики» — принципиальная разница. Первое — это интеграция снаружи: политика остаётся черным ящиком с условиями и действиями, а код живёт в отдельной системе и реагирует постфактум. Второе — это встраивание логики прямо в контур решения: Worker становится частью того, как Gateway решает, что делать с конкретным пакетом или запросом прямо сейчас, а не через пять минут.
Это не значит, что API, вебхуки и Terraform-провайдеры бесполезны — для большинства интеграционных задач их вполне достаточно, и не любая команда обязана переносить логику в policy path просто потому, что такая возможность появилась. Разница скорее в классе задач: одно дело — асинхронно уведомить внешнюю систему, другое — повлиять на само решение allow/block в реальном времени.
Forward action и custom functions — два разных инструмента
Cloudflare вводит не один механизм, а два, и путать их не стоит, потому что это разные классы риска. Forward action перенаправляет совпавший HTTP-трафик на Worker, который действует как inline-посредник: может читать и менять заголовки и тело запроса, дожидаться ответа от origin-сервера, модифицировать и его тоже, и только после этого вернуть финальный ответ пользователю. Это, по сути, программируемый прокси без необходимости держать собственную прокси-инфраструктуру — но и ответственность за корректность этой логики ложится на команду, которая её написала: плохо спроектированный Worker в этой точке может заметно повлиять на пользовательский опыт, потому что он стоит буквально на пути каждого запроса.
Custom functions устроены иначе — это вызов Worker для короткой, ограниченной по времени, stateless-проверки, которая возвращает одно типизированное значение (строку, число или булево), используемое дальше как обычный селектор в условии правила. Концептуально это ближе к тому, как сегодня работает проверка по регулярному выражению или диапазону портов — просто вычисление вынесено во внешнюю, но при этом локальную, логику.
Чтобы не путать сценарии, имеет смысл свести их в одну таблицу:
| Задача | Подходящий механизм | Почему | Основной риск |
|---|---|---|---|
| Разбор JWT и извлечение роли пользователя | Custom function | Быстрая, детерминированная проверка: данные на входе — значение на выходе | Неверный fallback при сбое функции |
| Подстановка заголовка на основе контекста запроса | Forward action | Нужно изменить сам HTTP-трафик, а не просто условие | Задержка и усложнение отладки inline-пути |
| Уведомление в Slack/PagerDuty при срабатывании DLP | Forward action (асинхронно) | Трафик продолжает идти к адресату, Worker работает параллельно | Зависимость от внешнего сервиса-получателя |
| Проверка валидности найденного секрета (например, GitHub-токена) | DLP custom validation | Нужен внешний источник истины, а не только совпадение по паттерну | Дополнительный сетевой вызов при каждом срабатывании |
| Интеграция с внутренней SIEM без влияния на сам трафик | Обычный API/webhook вне policy path | Простая интеграция не требует исполнения кода в контуре решения | Задержка доставки, не критична для мгновенного решения |
Главный вывод из этой таблицы не в том, что Forward action «мощнее», а custom function «проще» — а в том, что они решают структурно разные проблемы, и смешивать их — источник будущих инцидентов.
Где именно выполняется код
Полезно наглядно представить, что происходит с запросом, когда он проходит через политику с вызовом Worker — потому что именно здесь кроется ключевое архитектурное отличие от классических схем интеграции через внешний webhook или отдельный прокси.
flowchart TD A[Запрос попадает в Gateway] --> B[Политика проверяет условие] B --> C[Локальный вызов Worker] C --> D[Worker вычисляет значение или меняет трафик] D --> E[Gateway получает результат] E --> F[Решение: allow / block / forward]
Cloudflare утверждает, что поскольку Gateway и Workers работают на одной и той же распределённой сети, этот вызов — не сетевой переход, а локальный вызов функции, без hairpinning и без дополнительной задержки на пересечение сетевой границы. Это разумное инженерное обоснование: если прокси и compute-платформа физически находятся на одних машинах в одних дата-центрах, лишний сетевой скачок действительно не требуется. Но важно отделить архитектурный аргумент от гарантии результата — само выполнение кода Worker всё равно занимает время, и его длительность целиком зависит от того, что вы в этот код написали. Отсутствие сетевого хопа не отменяет задержки от собственно вычислений, внешних fetch-запросов внутри Worker или медленной логики.
DLP: от совпадения по паттерну к проверке источника истины
Отдельного разбора заслуживает то, что Cloudflare делает с DLP. Классический подход к обнаружению утечек данных — это сопоставление с паттернами: регулярные выражения, словари, эвристики по контексту. Проблема в том, что такой детектор отвечает только на вопрос «похоже ли это на чувствительные данные вообще», но не на вопрос «актуальны ли именно эти данные прямо сейчас для вашей организации».
Насколько хрупким может быть чистый паттерн-матчинг, хорошо видно на примере сторонних инструментов для настройки DLP-правил в Cloudflare: встроенный детектор номеров банковских карт ожидает канонически сгруппированные цифры, и номер с нестандартными разделителями его просто не замечает, из-за чего авторам таких инструментов приходится отдельно писать более широкое регулярное выражение и уже поверх него накладывать проверку по алгоритму Луна. Это иллюстрация общей проблемы: регулярка может поймать больше ложных срабатываний или, наоборот, пропустить нестандартный случай, и чем точнее вы хотите настроить детекцию, тем сложнее становится сама регулярка.
Custom validation для DLP предлагает другой путь: когда профиль обнаруживает совпадение, Worker может обратиться к собственному источнику истины — например, проверить у провайдера, активен ли найденный токен доступа, — и уже на основании этого ответа решить, засчитывать ли срабатывание. Это принципиальный сдвиг от «совпало по шаблону» к «совпало и подтверждено». Но было бы преувеличением сказать, что это закрывает проблему ложных срабатываний целиком: валидация переносит точку проверки на более надёжный источник, однако сама логика валидации — это снова код, который нужно написать, протестировать и поддерживать, и ошибки в нём создают новый класс ложных отрицательных и положительных срабатываний, просто в другом месте.
Цена гибкости
Здесь стоит честно взглянуть на формулировку Cloudflare о том, что только она способна совместить распределённый compute и полнофункциональный gateway в одной сети. Это описание реального архитектурного преимущества — co-located инфраструктура действительно убирает необходимость городить отдельный прокси или терпеть round-trip до внешнего облака. Но это одновременно и маркетинговое позиционирование компании о своей уникальности, которое стоит воспринимать как заявление поставщика, а не как не подлежащий сомнению факт индустрии: конкуренты могут предложить иные архитектуры co-located вычислений, а для части задач отдельная инфраструктура остаётся осознанным и разумным выбором, а не компромиссом по незнанию.
Главная плата за программируемость — не деньги за вызовы Worker, хотя и это стоит учитывать при росте объёма трафика, особенно на бесплатном тарифе с ограничениями по времени выполнения. Плата — это то, что раньше было скрыто в отдельной, явно выделенной инфраструктуре (прокси, SIEM-пайплайн, кастомный сервис валидации), теперь встраивается прямо в путь принятия решения о безопасности. Ошибка в коде Worker, вызываемого из Gateway, — это уже не сбой вспомогательного сервиса, а потенциальный сбой самого механизма allow/block. Отладка такой логики сложнее, чем отладка обычного правила с условием: нужно воспроизводить не только сетевой трафик, но и поведение кода в конкретный момент оценки политики. А зависимость от платформы становится глубже — чем больше бизнес-логики безопасности живёт как Worker внутри экосистемы одного вендора, тем дороже и сложнее её когда-либо оттуда перенести.
Что в итоге меняется
Новизна анонса не в том, что в Gateway добавили ещё одну кнопку-действие. Она в том, что Cloudflare предлагает переосмыслить сам gateway как программируемую платформу, где политика перестаёт быть статичным набором условий и становится точкой, где можно исполнить произвольную логику. Для команд, которые годами городили NGINX-прокси ради одной трансформации заголовка или терпели пятиминутные задержки в пайплайне уведомлений, это реальное упрощение. Но программируемость — это не бесплатная опция: она требует от команды безопасности дисциплины разработки, тестирования и эксплуатации кода, которой раньше можно было избежать, просто не трогая правила дальше «разрешить/заблокировать». Будет ли эта модель оправдывать себя в крупных реальных внедрениях за пределами демонстрационных сценариев — вопрос, на который пока отвечает только сам вендор, а не независимая практика.
