几周前，我们撰文介绍了 Project Glasswing，以及我们把网络安全前沿模型对准自家代码时的发现。此后我们发现，那篇文章中引起最多共鸣的观点是：漏洞周围的架构，比补丁的速度更重要。
此后在与 CISO 和安全团队的交流中，大家的问题始终一致：我们的架构实际上应该是什么样子，应该监控什么，从哪里入手，Cloudflare 又能如何提供帮助？
在展开细节之前先说明：下面的架构几乎完全由 Cloudflare 自家产品构成，因为 Cloudflare 安全团队是我们所构建安全产品的零号客户。Cloudflare 技术栈本来就部署在我们的代码、员工和面向客户的应用之前。如果你是 Cloudflare 客户，下面的每一层你今天都可以使用。如果不是，这些原则同样适用于你已搭建的任何技术栈。
网络安全前沿模型究竟改变了什么
在上一篇文章中，我们展示了像 Mythos 这样的网络安全前沿模型如何改变攻击者的时间线。它能比早期模型更快地发现漏洞、推理利用链并生成可用的概念验证。像 Mythos 这样的模型并不改变入侵的形态：侦察、初始访问、横向移动、持久化和数据窃取仍然必须发生，区别在于速度和规模。当对准开放网络时，模型可以快速找到并攻击唾手可得的目标。面对加固过的目标，它仍然必须试探和调整，而且往往比谨慎的人类操作者制造更多噪声。
发现漏洞、构造利用链和生成概念验证，过去是制约攻击得手的瓶颈。前沿模型只需一小部分时间就能完成这三件事。过去缓慢而有条不紊的工作，如今变得快速而不加区分。
AI 正在加快 Cloudflare 和许多其他公司的开发团队交付代码的速度，但安全团队的工作并没有以同样方式被压缩。攻击者只需要一个突破口就能进入，而安全团队需要找出并堵上所有突破口。编写修复、回归测试并在不破坏周边代码的情况下发布，这些约束是 AI 消除不了的。正如我们在上一篇文章结尾所述，当我们让 AI 编码助手针对我们自己的缺陷编写补丁时，吃过这方面的苦头：其中一些补丁修复了原来的缺陷，却悄悄破坏了代码所依赖的其他东西。
随着这些模型越来越强大、越来越有能力，从威胁角度看，我们的主要关注点归结为三件事。每一件都影响着本文后面要讲的架构。
- 第一是发现速度。前沿模型让搜索大量公开代码变得更容易，其中包括许多公司所依赖的开源库。这并不意味着库中的每个缺陷都可被利用，也不意味着大多数漏洞都出在库里。可利用性仍然取决于代码的使用方式、攻击者可控的输入能否到达存在漏洞的路径，以及周围的防护措施。但被广泛使用的开源库和框架，为攻击者提供了可以大规模研究的共同攻击面。当那里存在真实、可到达的漏洞时，模型可以帮助找到它、推理可能的利用路径，并生成概念验证变体，速度快于维护者和防御者审查每一处下游用法。攻击者发现漏洞与防御者得知漏洞存在之间的时间差，是我们最担心的。如果你没有对自己的代码运行这些模型，完全可以假定别人正在这样做。
- 第二是利用的数量与适应能力。模型可以为单个漏洞利用生成成千上万种变体，并以同样的规模进行侦察。这些数量给了攻击者优势，但未必能让他们绕过基于特征签名的检测。其中许多迭代具有相同的底层特征，所以能拦住第一个的规则也能拦住其余的。适应能力才是他们绕过基于特征签名检测的方式。让模型演示一个 SQL 注入，它会给出教科书式的例子。告诉它中间有一道 WAF，它就会开始试探，了解什么会被拦截，并改写载荷，直到能够绕过拦截它的规则。
- 第三是漏洞不可避免被利用时的影响。没有任何架构能拦住一切。漏洞被利用之后，我们问自己的问题是：在其他防线拦住攻击者之前，他们凭一个身份、一条路径或一个凭据能到达哪里？如果答案是“想去哪就去哪”，那问题从来就不在漏洞，而在漏洞周围的架构。
Cloudflare 的超能力：可见性
我们能看到大约五分之一的网络流量，这让我们实时了解哪些载荷在变异、哪些模式在抬头，以及攻击者工具的下一步动向。有两个团队把这种可见性转化为防御。
首先是 Cloudforce One，我们的威胁情报、研究和运营团队，隶属于 Cloudflare 安全组织。他们把我们在整个网络中看到的东西转化为技术栈其余部分可以据以行动的洞察：被追踪的对手、新兴的攻击行动，以及入侵指标（IOC）。这项工作的难点从来不是知道什么是恶意的，而是缓解的延迟。关于新威胁的信息通常要从威胁报告流入情报源，再流入公司的防御体系，之后才能用来拦截任何东西。攻击者已学会比这更快地行动。我们的网络弥合了这一差距：Cloudflare 客户现在可以直接在 WAF 中使用 Cloudforce One 威胁情报来拦截高风险流量。
其次是负责 WAF 引擎的团队，实际的检测由它完成：包括运行在我们自家资产前面、并向每个 Cloudflare 客户开放的托管规则集，WAF Attack Score 背后的机器学习，以及有时能让我们在 CVE 公开披露之前就发布规则的合作关系。该团队分布在全球各地，行动迅速，在某次攻击的概念验证公开后数小时内就能发布规则。检测一旦部署，不到 30 秒就能覆盖我们整个网络以及每一个 Cloudflare 客户。React2Shell 就是最近的一个例子：在官方公告发布前数小时，一条托管 WAF 规则就已在保护我们自己的资产，以及 Cloudflare 上所有其他人的资产。
评分层、我们部署在应用前面的防御，以及围绕漏洞的遏制措施，都建立在这两个团队所看到的情况之上。
以评分取代特征签名
基于特征签名的防御是为这样的世界而建的：新颖的漏洞利用稀少，变体需要数周才会出现。Cloudflare 传统的 SLA 是从拿到全新概念验证到规则上线部署需要 12 小时。随着前沿模型的出现，这已经不够好了。检测必须在 CVE 被发现之前就位。这就是我们在传统的基于特征签名的 WAF 前面叠加基于机器学习的检测的原因。
该模型在大量过往攻击流量上训练，能在新的漏洞变体公开之前就捕获它们。新颖的 SQL 注入或远程代码执行链，几乎总是模型见过的攻击形态的重新排列，即使具体的利用方式是全新的。我们对每个请求运行该模型，并根据请求与这些底层形态的相似程度，而不是对照已知恶意特征列表，给出 1 到 99 之间的 WAF Attack Score。分数越低，我们处理该请求就越严格。该分数决定我们是否放行请求。对于 AI 提示词，我们用 AI Security for Apps 采用了类似的评分方法：不是将每条提示词与已知恶意提示词列表比对，而是为提示词与真实攻击的相似程度打分。
漏洞周围的架构
这些能力只有叠加部署在应用前面才有意义，而我们纵深防御的第一层是 WAF。任何匹配已知恶意特征的流量，都会在到达应用之前被丢弃，这样既清除了大部分显而易见的流量，也让下面更专业的各层能专注处理剩下的部分。
在 API 层面，我们通过 API Shield 采用正向安全模型。我们不去试图预判每一种恶意请求，而是描述对每个 API 而言什么样的请求才是合法的（依据 API 自身的定义，或从真实流量中学习得出），凡是不符合的请求一律放不过去。这抵消了前沿 AI 模型的优势：由于我们只放行经过验证的流量，即便生成成千上万种新的攻击变体，也无法绕过系统。
Cloudflare 的分层架构
Bot Management 能在前沿模型绘制出“地图”之前，就在我们的网络上截获探测流量。它会对每个请求打分，评估其为自动化流量的可能性，并在我们整个网络中使用同一套信号：客户端的行为方式、看起来是否像真实浏览器，以及连接是否符合已知的恶意特征。攻击只有找到薄弱点才能得手。
Zero Trust Network Access 用于每一个内部应用。身处内网就被默认信任的做法，被替换成对每位员工访问每个工具时逐个请求的显式身份验证和策略校验。这一点的价值在一次事件中显而易见：我们的一位工程师上线了一个配置有误的工具。若是扁平网络，同一网段上的所有东西都会暴露，但在我们的部署中，暴露范围止步于该工具本身。事后我们构建了 Require Access Protection，使新部署或配置有误的应用在访问策略就位之前无法被访问。
IdP Federation 让这种默认安全的姿态更容易在 Cloudflare 的所有账户中保持一致，而当越来越多的人快速上线内部工具时，这一点就更加必要。我们不要求每个团队各自单独接入 SSO，而是只配置一次身份提供商（IdP），然后在整个组织内共享。新账户会自动获得 SSO，接收方的 IdP 连接是只读的，而各账户中的 Access 策略仍会在正常的请求流程中对生成的身份进行评估。
MCP Server Portal 为团队提供了一种受控的方式，将 AI 智能体连接到企业系统。智能体访问的 MCP 服务器通过单一门户集中管理，每一项操作都有日志记录。这样，当智能体代表某人行事时，我们就知道它做了什么、触及了什么，以及它是否应该被允许这样做。我们构建它的完整过程见关于企业级 MCP 的文章。
AI Gateway 部署在我们内部 AI 工具的前面，其方式与 AI Security for Apps 部署在面向客户的 AI 功能前面相同，使用同样的评分和同样的可见性。在公司内部，可见性比拦截更有用，因为我们需要先看清工程师实际在构建什么，才能围绕它制定有意义的策略。
你的团队可以从哪里入手
前沿模型可以帮助攻击者发现漏洞、调整攻击载荷并加快行动速度，但它们仍然必须穿过你部署在应用前面的分层防御。团队应当从以下几点入手：
- 在公开应用前面部署检测。
- 定义什么样的 API 流量才是合法的。
- 使用 bot 检测来限制自动化探测。
- 在任何内部工具可被访问之前，先要求身份验证和访问策略。
对于 AI 和智能体系统：
- 让模型流量经过网关。
- 让智能体通过获批的 MCP 服务器保持连接。
- 记录它们的所作所为。
目标是确保当某一层失手时，下一层能够限制攻击者所能看到、触及或更改的内容。
这正是围绕漏洞构建架构的意义所在：限制攻击的范围。漏洞或许是攻击的起点，但攻击能走多远，取决于架构。
我们如何知道这种方法有效？
许多安全体系在白板上看起来无懈可击，实践中却不堪一击。因此，我们在边界处和内部环境中都持续对自己的体系进行测试，红队同时参与这两方面。
在边界处，前沿模型是我们用来以自适应攻击者的身份测试应用安全体系的工具之一。这些模型与红队的其他工作和检测流程并行使用，包括：人工测试、威胁情报、观察到的流量模式、概念验证分析，以及来自我们自身网络的信号。这些输入共同帮助我们决定测试的重点：新发布的产品、近期有变动的面，以及攻击者最可能最先探测的路径。最重要的是随后的流程。当有攻击得手时，我们会找出缺口，用合适的工具组合来理解它，编写规则或缓解措施，发布更新，然后再次测试，确保缺口已被堵上。
在内部环境中，我们的红队从边界已经失守的假设出发。他们查看有哪些变化、敏感系统在哪些地方存在风险，以及某一个被攻陷的身份、路径或凭证能否抵达超出应有范围的地方。当我们根据他们的发现修改架构后，他们会针对新版本再次运行该场景，确认缺口确实已被堵上。
我们确认这一架构有效的方式，是持续测试它在故障期间的表现，而不是依赖各个单独层级的完美无缺。
如果你的团队也在处理同样的问题，并希望交流心得，欢迎通过 security-ai-research@cloudflare.com 联系我们。