Defend against frontier cyber models: Cloudflare's architecture as customer zero

防御前沿网络攻击模型：Cloudflare 架构作为零号客户

2026-06-09

• Rohit Chenna Reddy

• Chase Catelli

• Dan Jones

8 分钟阅读

几周前，我们写了一篇关于 Project Glasswing 的文章，并描述了当我们用前沿网络攻击模型来分析我们自己的代码时所观察到的情况。从那时起，我们发现文章中引起最深共鸣的部分是关于漏洞周围架构的重要性，这比补丁的速度更为关键。

在之后与首席信息安全官（CISO）和安全团队的交流中，提出的问题一直很一致：我们的架构实际上是什么样子？我们应该监控什么？从哪里开始？Cloudflare 又能如何帮助？

在进入细节之前：下面的架构几乎完全由 Cloudflare 自己的产品构建，因为 Cloudflare 安全是我们在构建安全产品时的零号客户。Cloudflare 的技术栈已经部署在我们的代码、员工和面向客户的应用程序之前。如果你是 Cloudflare 的客户，那么今天你就可以使用下面的每一层。如果你不是，这些原则仍然适用于你所构建的任何技术栈。

前沿网络攻击模型实际上改变了什么

在之前的帖子中，我们展示了像 Mythos 这样的前沿网络攻击模型如何改变攻击者的攻击时间线。它能够发现漏洞、推导出利用链，并比早期模型更快地生成可运行的攻击证明。虽然像 Mythos 这样的模型不会改变入侵的结构（侦察、初始访问、横向移动、持久性和数据外泄仍然需要发生），但区别在于速度和规模。当模型被指向开放网络时，它可以快速发现并攻击低垂的果实。针对一个加固的目标，它仍然需要探测、适应，通常会比一个谨慎的人类操作员产生更多的噪音。

过去，发现漏洞、构建利用链和生成概念验证是执行一次有效攻击的瓶颈。而前沿模型可以在极短的时间内处理这三个步骤。过去缓慢而有条理的工作现在变得快速而无差别。

虽然人工智能正在加快 Cloudflare 和许多其他公司开发团队发布代码的速度，但安全团队的工作并没有以同样的方式压缩。攻击者只需要一个入口点就能进入，而安全团队则需要找到并关闭所有入口点。编写修复、回归测试并发布修复而不破坏周围代码的过程，有一些人工智能无法消除的限制。我们在之前帖子的最后部分描述了当允许人工智能代码助手针对我们自己的漏洞编写自己的补丁时，我们以一种艰难的方式学到了这一点。其中一些补丁虽然修复了原始漏洞，但悄悄地破坏了代码所依赖的其他部分。

随着这些模型变得更加胜任和强大，从威胁角度来看，我们的主要关注点归结为以下三点。每一点都塑造了我们在本文其余部分中所探讨的架构。

• 第一个因素是发现速度。前沿模型使得在大量公开代码中进行搜索变得更加容易，这些代码包括许多公司依赖的开源库。但这并不意味着库中的每个漏洞都可以被利用，也不意味着库中的漏洞是大多数漏洞的来源。是否可以被利用仍然取决于代码的使用方式、攻击者控制的输入是否能够到达漏洞路径，以及围绕它的防护措施。然而，广泛使用的开源库和框架为攻击者提供了一个可以大规模研究的共享表面。当一个真实且可到达的漏洞存在于其中时，模型可以帮助发现它，推理可能的利用路径，并生成概念验证的变种，速度比维护者和防御者逐一审查所有下游使用情况要快得多。我们最担心的是攻击者发现漏洞与防御者得知漏洞存在之间的时间差距。如果你没有将这些模型应用于自己的代码，那么可以安全地假设其他人正在这么做。

• 第二个因素是攻击规模和适应能力。一个模型可以生成数千种单一攻击的变种，并在同一规模上进行侦察。所有这些攻击量都为攻击者提供了优势，但它不一定能绕过基于签名的检测。这些迭代中的许多都具有相同的底层签名，因此能够捕获第一个攻击的规则也将捕获其余的攻击。适应能力是他们绕过基于签名检测的方法。如果你让模型展示一个SQL注入攻击，它将返回一个教科书式的例子。如果你告诉它存在一个WAF（Web应用防火墙），它将开始探测，学习哪些内容被阻止，并不断重写负载，直到能够绕过阻止它的规则。

• 第三个因素是漏洞被不可避免地利用时的影响。没有任何架构能够捕捉到所有漏洞。漏洞被利用后，我们问自己的问题是：在其他东西阻止攻击者之前，攻击者凭借一个身份、一条路径或一个凭证能够到达哪里？如果答案是“他们想去的任何地方”，那么漏洞本身从来就不是问题所在，问题出在漏洞周围的架构上。

Cloudflare 的超能力：可见性

我们看到了全球约五分之一的网络流量，这些流量实时告诉我们哪些负载正在发生变化、哪些模式正在兴起，以及攻击者工具下一步将向哪里发展。两个团队将这种可见性转化为防御能力。

第一个是 Cloudforce One，我们的威胁情报、研究和运营团队，该团队隶属于 Cloudflare 安全组织。他们将我们在网络上看到的内容转化为整个系统可以采取行动的洞察：被追踪的对手、新兴的攻击活动以及入侵指标（IOCs）。这项工作的困难之处从来不是识别恶意内容，而是在缓解上的延迟。通常，对新威胁的认知需要从威胁报告中传递到数据源，再传递到公司防御系统，才能用于阻止任何攻击。攻击者已经学会了比这个过程更快地行动。我们的网络弥补了这一差距：Cloudflare 客户现在可以在 WAF 中直接使用 Cloudforce One 的威胁情报来阻止高风险流量。

第二支团队是负责 WAF 引擎的团队，该引擎负责实际的检测工作：包括在我们自己的属性前面运行的托管规则集，这些规则集可供所有 Cloudflare 客户使用；WAF 攻击评分背后的人工智能；以及有时让我们在 CVE 公开披露之前就发布规则的关系。该团队在全球分布，行动迅速，能够在攻击概念验证被公开后的数小时内发布规则。一旦检测功能部署完成，它将在 30 秒内传播到我们的整个网络，以及所有 Cloudflare 客户。React2Shell 就是一个近期的例子：在官方公告发布前数小时，托管的 WAF 规则已经保护了我们自己的属性，以及 Cloudflare 上所有其他客户的资源。

评分层、我们在应用程序前面设置的防御措施，以及围绕漏洞的隔离措施，都建立在这两支团队所看到的内容之上。

评分优于特征匹配

基于特征的防御机制是为一个新型攻击稀缺、变化需要数周的世界而设计的。Cloudflare 传统的从新概念验证到实际部署规则的 SLA（服务等级协议）是 12 小时。随着前沿模型的出现，这种速度已经不再足够。检测必须在 CVE 被发现之前就部署到位。这就是为什么我们在传统基于特征的 WAF 前面增加了基于机器学习的检测。

该模型是基于大量历史攻击流量进行训练的，能够在漏洞公开之前就检测出新的变种。一个新颖的 SQL 注入或远程代码执行链几乎总是对模型之前见过的攻击模式的重新排列，即使具体的攻击手段是全新的。我们对每个请求运行该模型，并根据请求与这些基础模式的相似程度，而不是基于已知恶意特征列表，分配一个 1 到 99 之间的 WAF 攻击评分。评分越低，我们就越激进地处理该请求。这个评分决定了请求是否被允许通过。我们对 AI 提示也采用了类似的评分方法，通过 AI 安全防护应用功能：我们不是将每个提示与已知恶意提示列表进行比对，而是根据提示与实际攻击的相似程度进行评分。

漏洞周围的架构

这些能力只有在部署到应用程序之前才具有意义，而我们纵深防御的第一层是 WAF。任何匹配已知恶意模式的请求都会在到达应用程序之前被丢弃，这清除了大部分明显的流量，使下面更专业的层可以专注于剩下的内容。在 API 接口方面，我们通过 API Shield 运行一个正向安全模型。我们不试图预测每一个恶意请求，而是描述每个 API 的有效请求应该是什么样子，这可以来自 API 自身的定义，也可以从我们实际的流量中学习。任何不符合描述的请求都无法通过。这种方法消除了前沿 AI 模型的优势：因为我们只允许验证过的流量，生成数千种新的攻击变种也无法绕过系统。

Cloudflare 的分层架构

Bot Management 在前沿模型能够构建地图之前就捕获了探测流量。它根据请求是否可能是自动化的可能性对每个请求进行评分，使用我们整个网络中的一致信号：客户端的行为、是否看起来像一个真正的浏览器，以及连接是否匹配已知的恶意模式。只有当攻击找到一个薄弱点时，攻击才会成功。

零信任网络访问用于每一个内部应用程序。网络内部的隐式信任被替换为每个员工访问每个工具时的显式请求身份和策略。这一点的价值在我们的一位工程师部署了一个配置错误的工具时变得显而易见。在一个扁平网络中，所有在同一网段的资源都会暴露，但在我们的部署中，暴露仅限于工具本身。之后我们构建了 Require Access Protection，以确保新部署或配置错误的应用程序在访问策略到位之前无法被访问。

通过 IdP 联邦，使这种默认安全的态势更容易在每个 Cloudflare 账户之间保持一致，这在更多人快速部署内部工具时变得尤为重要。我们不再需要让每个团队分别设置 SSO，而是只需配置一次我们的身份提供商（IdP），然后在整个组织中共享。新账户会自动获得 SSO，接收方的 IdP 连接是只读的，每个账户中的访问策略仍然会在正常的请求流程中评估由此产生的身份。

MCP 服务器门户为团队提供了一种受控的方式，将 AI 代理连接到企业系统。代理通过一个统一的门户访问集中管理的 MCP 服务器，所有操作都会被记录。这样，当代理代表某人执行操作时，我们知道它做了什么、接触了什么，以及是否应该被允许这么做。我们关于企业 MCP 构建的完整情况，请参见我们的文章《企业 MCP》。

AI 网关以与 AI 安全（用于面向客户的人工智能功能）相同的方式运行在我们内部 AI 工具的前面，使用相同的评分机制和相同的可见性。在公司内部，可见性部分比阻止攻击更实用，因为我们需要先了解工程师实际构建了什么，才能制定出有意义的策略。

团队可以从哪里开始

前沿模型可以帮助攻击者发现漏洞、调整有效载荷并加快攻击速度，但它们仍然需要通过你在应用程序前面部署的多层防御。团队应该从以下方面开始：

• 在面向公众的应用程序前面设置检查。
• 定义有效的 API 流量是什么样子。
• 使用机器人检测来限制自动化探测。
• 在任何内部工具可访问之前，要求身份和访问策略。

对于 AI 和代理系统：

• 将模型流量路由到网关。
• 通过批准的 MCP 服务器保持代理连接。
• 记录它们的操作。

目标是确保当某一层防御失效时，下一层防御能够限制攻击者能看到、接触到或更改的内容。

这就是围绕漏洞的架构设计的要点：限制攻击的范围。漏洞可能是攻击的起点，但架构决定了攻击能走多远。

我们如何知道这种方法有效？

许多安全架构在白板上看起来坚不可摧，但在实际中却可能崩溃。这就是为什么我们持续测试我们的架构，既在边界处测试，也在我们内部环境中测试，而且我们的红队参与了所有测试。

在边界处，前沿模型是我们作为适应性攻击者测试应用安全堆栈的一种工具。这些模型与我们的红队和检测工作流程并行运行，包括：手动测试、威胁情报、观察到的流量模式、概念验证分析以及我们自身网络中的信号。这些输入共同帮助我们决定测试的重点：新推出的产品、最近更改的界面，以及攻击者最可能首先探测的路径。最重要的部分是随后的过程。当某些内容成功突破时，我们会识别出漏洞，使用合适的工具组合来理解它，编写规则或缓解措施，发布更新，并再次测试以确保漏洞已被关闭。

在环境中，我们的红队基于边界已经失败这一假设开展工作。他们查看发生了哪些变化，敏感系统是否存在风险，以及一个被攻破的身份、路径或凭证是否能够扩展到不应到达的范围。当我们根据他们的发现更改架构时，他们会再次针对新版本运行该场景，以确认漏洞确实已被关闭。

我们通过在故障期间持续测试其行为来确认这种架构是否有效，而不是依赖于各层的完美性。

如果你的团队正在处理相同的问题并希望交流经验，请通过 [email protected] 与我们联系。

[if astro]>server-island-start<![endif]

安全

人工智能

威胁情报

风险管理

客户零

WAF

零信任

Cloudforce One

机器人管理