Cloudflare 为 Gateway 和 DLP 推出可编程能力:Forward 动作与自定义函数
A fully programmable secure web gateway
市面上每一款安全 Web 网关的工作方式都相同:流量匹配某个条件,随即触发一个终端动作——允许、阻止、隔离、记录。这一模型作为网络安全的基础已近 30 年,并且能很好地处理常见场景。但它存在上限,而拥有复杂环境的客户会经常触碰到这个上限。
今年早些时候,我们分享了构建真正可编程的 SASE 平台的愿景。我们还阐述了可编程性一词如何被安全行业稀释。大多数厂商声称自己具备可编程性,理由是他们提供公开 API、Terraform provider、webhook 和告警功能。Cloudflare 也提供所有这些能力,但这还不够。真正的可编程性意味着在策略评估路径中、在做出安全决策的那一刻,内联运行你自己的代码——即你为自身特定环境编写的任意逻辑。
今天,我们很高兴地宣布,Cloudflare 通过将 Cloudflare Gateway 和 DLP(数据丢失防护)与我们整个边缘计算平台集成,为它们带来了真正的可编程性。我们推出一种新的 Gateway 动作——Forward,以及自定义校验函数,面向所有 Zero Trust 套餐开放。这些能力让你可以使用 Cloudflare Worker 转换和操纵流量,或将你自己的数据引入策略评估。
每个安全团队都面临的权衡
自防火墙诞生以来,企业就一直面临一个二元选择。你可以维护自己的安全检测引擎——自己的防火墙、自己的代理基础设施——以高昂的维护开销和低可移植性为代价,换取最大程度的定制化。或者,你可以接受厂商的约束,将可观的维护成本转嫁出去,代价是失去解决自身环境特有问题的灵活性。
在构建 Cloudflare Gateway 的六年里,我们听到数千名客户在这一权衡中挣扎。一个正在为关键内部应用迁移访问控制的安全团队,需要根据其身份提供商提供的 JSON Web Token(JWT)声明注入 HTTP 头。数据存在于请求上下文中,但 Gateway 无法读取 JWT 并写入该头。于是该团队搭建了一组 NGINX 代理,仅仅为了执行这一转换。这些基础设施现在必须被修补、监控和保护……而且是无期限的。
另一个团队希望在员工注册新的 SaaS 服务的那一刻收到 Slack 通知。策略引擎能够检测到注册事件,但只能执行允许或阻止。于是该团队构建了一条从 Logpush 到 SIEM 再到 Slack 的流水线,延迟 5 到 15 分钟,且不保证送达。这又叠加了又一层基础设施。
数十家企业客户要求提供警告页面,在允许访问敏感目标之前提示用户填写理由。其中大多数随后还希望根据关于用户身份和所请求访问级别的更多上下文,定制后续行为。但从策略引擎提供定制的动态响应极其困难。
多年来,我们为客户提供了许多扩展点。但与其他所有防火墙厂商一样,我们不可能以威胁向量出现的速度来构建覆盖它们的特性。不过,我们也认识到,最好的解决方案是那些能够无限扩展以适应你自身环境的方案。
为什么只有 Cloudflare 能解决这个问题
Cloudflare 不仅仅是一个防火墙,或安全 Web 网关、内容分发网络、边缘服务。Cloudflare 是一个可组合的计算平台。Cloudflare Workers 已经允许客户在我们全球 330 多个位置中的任意一个网络边缘上运行复杂逻辑。Cloudflare Gateway 已经在这些相同的位置、相同的机器、相同的数据中心上,对用户流量评估并执行安全策略。
只有 Cloudflare 在同一个全球分布式网络中同时运行分布式客户计算和功能完备的安全 Web 网关与防火墙。我们拥有独特的机会和能力,将这些功能整合为业界首个完全可编程、可定制的 SASE 平台。
Gateway 和 Workers 从一开始就构建在相同的基础设施之上。当 Gateway 将流量转发给 Worker 时,该调度是一次本地函数调用。不存在发夹回环。不会因跨越网络边界而产生额外延迟。这是客户首次能够绝对控制其代理流量的处理方式,无需妥协,使用他们可以编写和执行的代码,而无需维护任何类型的基础设施。
没有自有计算平台的独立 SASE 提供商要求你在单独的云中部署自动化、手动配置 webhook,并承受拼接互不相连系统所带来的往返延迟和管理开销。该领域没有其他厂商拥有与其安全网关同址部署的可编程边缘计算平台。随着威胁以 AI 驱动的速度演进,这将为安全组织提供亟需的灵活性和敏捷性。
两个 Gateway 入口点:Forward 操作和 Custom Functions
一种名为 Forward 的新 Gateway 操作类型和一种名为 Custom Function 的新策略资源,是从 Gateway 策略调用 Worker 的两种不同方式。Forward 操作目前处于公开测试阶段,Custom Functions 将在今年年底前推出。
Forward 操作:流量转换与代理
你可以通过一种名为 Forward 的新 策略操作 自定义 HTTP 流量行为,该操作会将匹配的 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,该 Worker 会异步接收所匹配请求的完整上下文:发送 Slack 消息、写入 R2、记录到外部管道、调用 webhook、更新 KV 存储。流量可以不受打扰地继续前往其目的地。
自定义函数:内联策略评估
自定义函数会在 Gateway 策略评估期间内联调用一个 Worker 并返回一个值。随后,该函数会作为选择器暴露在 Gateway 策略构建器中,并会针对其值进行评估。该选择器可用于任何网络或 HTTP Gateway 规则的条件中,就像如今内置选择器 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 Role”包含“finance_contractor” ,操作为允许。该自定义函数会成为规则条件的一部分,并与其他所有选择器一起被评估。
自定义函数并不限于 HTTP 流量。由于它们接收的是身份、设备状态和连接元数据,而不是完整的 HTTP 请求,因此你也可以在 Gateway 网络策略规则构建器中,将其用于任意第 4 层端口和协议流量。
Worker 本身可以执行 Worker 已经能够执行的任何操作——调用外部 API、从 KV 或 D1 读取数据,或调用 Workers AI。但从 Gateway 的角度来看,该函数是确定性的:输入数据,输出值。
何时使用自定义函数或 Forward 操作
自定义函数旨在对数据执行快速、有界、无状态的评估,并可返回结构化响应。你应将其用途类比为 Gateway 选择器中已经可以评估的数据;也就是说,对一组条件内已有数据进行计算,例如“此范围内的端口”或“匹配此正则表达式的 URL 路径”。其强大之处在于,能够用任意或内部数据源扩展你的结构化评估,下面你会看到一些示例。
Forward 操作需要更多规划和准备。它可用于对用户的实时请求进行强大的内联转换,并可在出站以及返回源服务的过程中以复杂方式操纵这些请求。这些应被视为转换函数,如今很少有企业安全代理甚至能构想出这种能力。使用 Forward 操作的 Workers 应被有针对性地、谨慎地设计,以避免对最终用户的整体体验产生不利影响。
你可以构建什么
用途说明和插页页面
Worker 会拦截发往敏感目标的请求,并返回一个插页页面,要求最终用户提供访问的书面理由。Worker 调用 Cloudflare KV 写入一个带 TTL 的会话,因此用户在每个配置周期内只会被提示一次。它将用户身份及其陈述的理由写入 Cloudflare D1,从而创建审计追踪。或者,你可以使用 Hyperdrive 将该记录写入你已在运营的任何内部数据库。
四年多来,这一直是我们最受期待的功能之一。借助能够处理和操纵 HTTP 流量的 Worker,你可以轻松按照自己的标准进行构建。
动态 HTTP 头注入
自定义函数从请求的 Authorization 头中解析 JWT,提取用户的角色或组成员身份,并将其作为选择器值返回。Gateway 规则匹配该值,并在上游请求上设置 X-App-Role 头。无需 NGINX 代理池。无需维护额外的基础设施。
文件检查与日志记录
当文件下载符合特定条件时,Worker 可以将文件发送到第三方沙箱服务进行引爆和分析。或者,它可以将文件完整写入 Cloudflare R2 作为永久记录以供后续检查,而文件始终不会离开 Cloudflare 网络。
策略匹配的实时告警
绑定到 Forward 策略的 Worker 会在特定选择器匹配时接收流量。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 确实有执行时间限制和每日请求限制,随着你扩大发送到 Workers 的 Gateway 流量规模,这一点值得考虑。
用于内联检测验证的 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 服务中。
如今,使用 Cloudflare One 保护你的 Workers、智能体及其流量 也正变得日益容易。如果你是希望进行实施策略会议、预览即将推出的功能,或希望获得自定义函数测试版通知的企业客户,请联系你的客户团队。
你的组织安全现在可以做到 Cloudflare Worker 能做的任何事情。我们迫不及待想看到你构建的成果。
来源:Cloudflare Blog · blog.cloudflare.com