Cloudflare разрешила запускать свой код прямо внутри шлюза безопасности, а не рядом с ним

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

Публичные API, провайдеры Terraform, вебхуки и алертинг есть у многих, но этого недостаточно. Настоящая программируемость — это запуск собственного кода, написанного под конкретную среду, прямо в цепочке оценки политик, в тот самый момент, когда принимается решение о безопасности. Теперь компания объявила, что приносит такую программируемость в Cloudflare Gateway и Data Loss Prevention, интегрируя их со всей своей edge-вычислительной платформой.

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

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

Одна команда безопасности, перенося контроль доступа для критичного внутреннего приложения, хочет добавлять HTTP-заголовки на основе утверждений из JSON Web Token своего провайдера идентификации. Данные есть в контексте запроса, но Gateway не умеет читать JWT и записывать заголовок. В итоге команда поднимает пул NGINX-прокси исключительно ради этой трансформации — и теперь эту инфраструктуру нужно бесконечно патчить, мониторить и защищать.

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

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

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

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

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

Действие Forward уже доступно в публичной бете, а пользовательские функции появятся до конца года. Forward позволяет настраивать поведение HTTP-трафика, направляя подошедший под правило запрос в Worker как через прокси. Политики с действием Forward оцениваются для трафика, уже разрешённого HTTP-правилами.

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

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

Custom Function, в свою очередь, вызывает Worker прямо в процессе оценки политики Gateway и возвращает значение. Функция затем отображается как селектор в конструкторе политик, и этот селектор оценивается по его значениям. Его можно использовать в условии любого сетевого или HTTP-правила Gateway точно так же, как работают встроенные селекторы вроде Source IP или Content Category.