Hotdry.

Article

Google Cloud Fraud Defence 与 WEI 技术架构对比:工程视角的选型参数

从工程实现角度拆解 Google Cloud Fraud Defence 与 WEI(Web Environment Integrity)的技术差异,提供防欺诈方案的选型决策框架。

2026-05-09security

当 Google 在 2025 年推出 Google Cloud Fraud Defence 时,社区中立刻出现了「这不过是 WEI 换皮」的质疑声。WEI(Web Environment Integrity)是 Google 曾在 2023 年提出的网页端设备认证方案,因隐私争议而一度被搁置。如今 Fraud Defence 以防欺诈产品的形态重新出现,两者之间究竟是技术演进还是营销包装?本文从工程实现角度出发,拆解两者的核心架构差异,并为防欺诈方案选型提供可落地的参数清单。

核心定位:从挑战到决策引擎

从产品定位来看,WEI 从一开始就是一个设备认证层,旨在向网站证明「请求来自于一个可信的运行环境」。它试图解决的问题是:如何在不展示传统验证码的前提下,区分人类用户与自动化脚本。其设计思路接近于苹果的 Private Access Tokens—— 通过设备端的信任声明来替代交互式挑战。

Google Cloud Fraud Defence 则走得更远。它被定位为 WAAP(Web Application and API Protection)生态的一部分,不仅仅是验证码的替代品,而是一个覆盖用户注册、登录、支付全生命周期的风险决策引擎。根据 Google 官方博客的描述,Fraud Defence 包含以下几个核心组件:基于代理的策略引擎(Agentic Policy Engine),能够根据风险评分、自动化类型和代理身份在用户旅程的不同阶段执行放行或阻断决策;AI 抗性挑战(AI-resistant Challenges),例如基于二维码的人机验证,用以在检测到可疑行为时要求人类介入;以及全局信任信号层,利用 Google 生态的安全信号进行风险评估。

从架构视图来看,WEI 更接近一个单向的认证协议—— 客户端向服务器声明「我运行在可信环境中」,服务器据此决定是否放行。而 Fraud Defence 是一个闭环的决策系统,它不仅接收来自客户端的信号,还聚合了 Google 的全局威胁情报、与 Cloud Armor(Web 应用防火墙)和 Apigee(API 网关)深度集成,形成一个多层次的防御纵深。

设备认证机制:Attestation 的实现路径

两者最核心的技术差异体现在设备认证的实现方式上。WEI 的设计哲学是基于环境完整性证明(Attestation),即设备向验证方提供加密签名,证明其硬件和软件环境未被篡改。这一机制与 ARM TrustZone 或 TPM(可信平台模块)的理念一脉相承。但在实际落地时,Google 面临两个难题:一是如何在不做强绑定的前提下保证隐私;二是传统浏览器环境下很难获取硬件级信任信号。

Fraud Defence 在这方面采用了更为务实的路径。它并不直接依赖 WEI 式的网页端认证,而是通过 Play Integrity API(针对 Android 应用)和浏览器行为分析相结合的方式来实现设备可信度评估。Play Integrity API 会返回设备完整性 verdict( verdict 包含 appIntegrity、deviceIntegrity、licenseStatus 三个维度),但这些 verdict 仅作为 Fraud Defence 风险评分模型的输入特征之一,而非直接的「通过 / 拒绝」判据。这意味着即使一台设备通过了 Play Integrity 检查,如果其行为模式符合自动化特征,仍然会被拦截。

从工程实现角度看,WEI 在其最原始的设计中追求的是「无摩擦」—— 用户无需任何交互即可获得信任凭证。但这恰恰也是其被批评最多的地方:无摩擦意味着无感知,而无感知就意味着用户对自己被追踪一事毫不知情。Fraud Defence 则引入了渐进式验证机制,在低风险场景下保持无摩擦体验,仅在风险评分超过阈值时才触发挑战(如二维码验证)。这种设计在安全与可用性之间取得了一个更可控的平衡点。

风险评分模型:信号来源与权重策略

在风险评分层面,两者的差异更为明显。WEI 的信号来源相对单一,主要依赖于设备层面的认证结果 —— 如果设备通过了完整性检查,则认为请求可信;如果未通过,则认为存在风险。这种二元判断在面对高级自动化攻击(如模拟真实用户行为的无头浏览器)时显得力不从心。

Fraud Defence 则构建了一个多维度的风险评分体系。根据 Google 公开的技术文档,其风险信号来源包括:设备完整性信号(来自 Play Integrity API)、浏览器指纹特征、行为生物特征(如鼠标移动轨迹、输入节奏)、会话上下文(IP 声誉、地理位置异常)、以及 Google 全局的威胁情报数据。这些信号并非简单叠加,而是通过机器学习模型进行加权融合,输出一个连续的风险分数。

具体到工程实践中,Fraud Defence 的策略引擎允许客户配置分阶段的决策规则。例如:在用户注册阶段,如果风险分数超过 0.7 则触发强身份验证;在登录阶段,如果检测到异常 IP 或设备指纹变化则触发多因素挑战;在支付阶段,任何超过 0.5 的风险分数都需要人工审核或额外验证。这种精细化的控制粒度是 WEI 架构所不具备的。

从实际效果来看,Fraud Defence 的风险模型面临的最大挑战并非技术本身,而是标签数据的质量和时效性。自动化攻击工具在不断进化,去年的正常行为特征可能在今年就成为攻击者的标配。因此,工程团队在选型时需要特别关注供应商的模型迭代能力和信号更新频率。根据公开信息,Google 声称其风险模型会定期从全球流量中学习新模式,但具体的更新周期并未透明披露。

集成复杂度:与现有安全栈的对接

对于已经在使用 Google Cloud 安全产品的企业来说,Fraud Defence 的一个显著优势在于其与现有 WAAP 栈的无缝集成。Fraud Defence 可以与 Cloud Armor(提供 DDoS 防护和 WAF 规则)以及 Apigee(API 网关)联动,实现从网络层到应用层的统一策略管理。这意味着安全团队可以在单一控制面上定义一条完整的流量处理流水线:先经过 Cloud Armor 的基础过滤,再由 Apigee 进行 API 级别的访问控制,最后由 Fraud Defence 执行业务级别的风险决策。

相比之下,WEI 如果要在生产环境中部署,需要企业自行构建完整的信号采集、验证和决策流程。由于 WEI 本身仅提供设备认证结果(通过 / 不通过),企业需要额外集成风控规则引擎、用户行为分析系统、以及与自身业务逻辑对接的 webhook 机制。这大大增加了实施复杂度和运维成本。

对于采用多云或混合架构的企业,还有一个关键考量:Fraud Defence 目前绑定了 Google Cloud 的生态系统。如果企业的主要工作负载不在 Google Cloud 上,部署 Fraud Defence 需要额外的数据流转和网络配置。而 WEI 的设计原本是浏览器层面的协议,理论上不依赖于特定云厂商,更容易跨平台移植。

选型决策参数:一份可执行的清单

基于以上技术分析,以下提供一个面向工程团队的选型决策框架。以下几个维度应当纳入评估:

业务风险场景适配度。如果你的主要防欺诈需求集中在支付保护和账户滥用防护,且业务部署在 Google Cloud 生态内,Fraud Defence 的一体化方案能显著降低集成成本。如果你的业务更侧重于开放互联网环境下的通用反爬虫,WEI 的设备认证思路可能更直接。

隐私合规要求。Fraud Defence 依赖 Play Integrity API,这意味着 Google 会收集设备层面的完整性数据。根据 GDPR 和中国个人信息保护法的要求,企业需要评估这种数据收集是否在用户隐私政策的覆盖范围内,并确保获取有效的用户同意。WEI 在设计上试图通过「不传输硬件标识符」来规避这一问题,但实际效果取决于具体实现。

对抗预算与攻击者画像。根据 Hacker News 讨论中提到的数据,构建一个能够绑过 WEI 类认证的设备农场的成本已经降至约 30 美元每台设备。这意味着面对有组织的高级攻击时,任何基于设备认证的方案都不是银弹。Fraud Defence 的优势在于其多维度检测能力 —— 即使设备认证被绑过,异常行为分析仍可能捕获攻击。

运维与扩展性。Fraud Defence 的策略引擎提供了可视化的规则配置界面,降低了安全团队的运维门槛。但与此同时,其定价模型基于请求量,企业需要评估高峰流量的成本影响。WEI 类方案的运维成本更多体现在自行构建规则引擎和模型调优上,但对于有自研能力的团队来说,灵活性更高。

长期技术路线。需要关注 Google 对这两个产品的持续投入力度。WEI 在 2023 年后经历了战略调整,从一个通用的网页认证协议收敛到了 Android 特定的 Play Integrity API。Fraud Defence 作为当前主推产品,其 roadmap 更为清晰。企业不应仅基于当前功能做决策,还需评估供应商的产品承诺稳定性。

小结

Google Cloud Fraud Defence 与 WEI 的关系,并非简单的「换皮」所能概括。两者在技术架构上存在本质差异:WEI 是一个设备认证协议,侧重于环境完整性证明;Fraud Defence 是一个完整的风险决策系统,融合了设备信号、行为分析和全局情报。在选型时,企业应当根据自身的业务场景、合规约束和技术能力进行综合评估,而非简单地将其视为「更贵的 reCAPTCHA」。在当前自动化攻击手段持续进化的环境下,多层次的防御策略仍然是不可替代的工程实践。


参考资料

  • Google Cloud 官方博客:Introducing Google Cloud Fraud Defense, the next evolution of reCAPTCHA
  • Android 开发者文档:Play Integrity API 概述
  • The Register 报道:Google abandons Web Environment Integrity API proposal(2023 年 11 月)
  • Hacker News 讨论:Google Cloud Fraud Defence is just WEI repackaged(2025 年 5 月)

security

内容声明:本文无广告投放、无付费植入。

如有事实性问题,欢迎发送勘误至 i@hotdrydog.com