Google Cloud Fraud Defense：reCAPTCHA 的接班人，从验证码走向全链路反欺诈

预计阅读时间：11 分钟

reCAPTCHA 曾经是 Web 反机器人的标配——那个"我不是机器人"的复选框几乎出现在每一个登录页上。但验证码的思路本质上是"在门口查身份证"，一旦攻击者绕过门口，整条业务链就裸奔了。在 Next '26 大会上，Google 正式推出 Google Cloud Fraud Defense，不再只盯着"你是不是人"，而是覆盖登录、注册、支付全流程的欺诈行为检测。这是 reCAPTCHA 的继任者，也是思路的一次升级。

从"门口查人"到"全程盯行为"

reCAPTCHA 的核心能力是区分人和机器人。它靠浏览器指纹、鼠标轨迹、挑战响应来做判断，输出一个 0–1 的分数，开发者据此决定放行还是拦截。问题在于：

只守入口：注册页过了 reCAPTCHA，后续开卡、转账、批量下单没有任何防护。
对抗升级：验证码破解服务（2Captcha、Anti-Captcha 等）已经把 reCAPTCHA v3 的通过率做到 90% 以上，纯靠"你是不是人"越来越不靠谱。
用户体验差：音频挑战、图片选择对真实用户也是负担，无障碍合规风险不小。

Cloud Fraud Defense 的思路变了：不再只问"你是不是人"，而是问"你这一系列行为是不是正常"。平台覆盖三条关键业务链路：

业务链路	典型欺诈场景
登录	凭证填充、撞库、账号接管
注册	批量创建虚假账号、薅羊毛
支付	盗刷信用卡、合成身份交易欺诈

每条链路不是孤立判断，而是把设备指纹、行为序列、风险信号串起来做综合评估。

技术架构的关键变化

从公开信息看，Cloud Fraud Defense 相比 reCAPTCHA 有几个结构性差异：

1. 信号维度扩展

reCAPTCHA 主要依赖浏览器端信号（JS 执行环境、Canvas 指纹、鼠标轨迹）。Fraud Defense 在此基础上叠加了：

账号维度的历史行为画像（登录频率、设备切换模式）
交易维度的模式识别（支付金额分布、收货地址关联）
跨租户的联合风险情报（Google 云上大量客户的行为数据做联邦建模）

这意味着判断不再只依赖单次请求，而是看"这个账号过去 30 天做了什么"。

2. 决策粒度细化

reCAPTCHA 给你一个 score，你自己写逻辑决定 0.7 是放行还是拦截。Fraud Defense 提供结构化的风险标签和推荐动作：

风险类型标签：credential_stuffing、fake_account、transaction_fraud
推荐动作：allow、challenge、block、review
罚信度等级和证据链（哪些信号触发了判断）

开发者不再需要自己调阈值，而是直接消费平台的风险决策。

3. API 集成点增多

reCAPTCHA 只在页面加载时调用一次。Fraud Defense 在登录、注册、支付三个节点各有专用 API，可以独立调用，也可以串联调用形成全链路风控。

实战集成：一个登录 + 注册的风控接入示例

下面是一个基于 Google Cloud REST API 风格的集成示例。Cloud Fraud Defense 是刚发布的产品，官方 API 文档细节尚未完全公开，以下示例基于 Google Cloud API 的通用模式（API Key 认证、JSON 请求体、结构化响应）编写，字段名和端点路径为合理推断，实际上线前需对照官方文档调整。

后端风险评估调用

import httpx
import os

FRAUD_DEFENSE_ENDPOINT = "https://frauddefense.googleapis.com/v1/projects/{project}/assessments"
API_KEY = os.environ["GOOGLE_FRAUD_DEFENSE_API_KEY"]
PROJECT_ID = os.environ["GOOGLE_CLOUD_PROJECT"]

async def assess_risk(event_type: str, user_id: str, session_token: str, extra: dict = None):
    """
    调用 Cloud Fraud Defense 进行风险评估。

    event_type: "login" | "signup" | "payment"
    session_token: 前端 SDK 生成的设备/会话令牌
    extra: 业务上下文（支付金额、IP 等）
    """
    payload = {
        "event_type": event_type,
        "user_id": user_id,
        "session_token": session_token,
        "context": extra or {},
    }

    url = FRAUD_DEFENSE_ENDPOINT.format(project=PROJECT_ID)
    resp = await httpx.post(
        url,
        json=payload,
        params={"key": API_KEY},
        timeout=5.0,
    )
    resp.raise_for_status()
    return resp.json()


# ---- 登录流程中的调用 ----
async def handle_login(username: str, password: str, session_token: str):
    # 先做基础认证校验（密码哈希比对等）
    user = await authenticate_user(username, password)
    if not user:
        return {"error": "invalid_credentials"}

    # 调用 Fraud Defense 评估登录风险
    assessment = await assess_risk(
        event_type="login",
        user_id=user.id,
        session_token=session_token,
        extra={"ip": request.client_ip, "device_type": request.headers.get("user-agent")},
    )

    # 根据返回的推荐动作做分流
    action = assessment.get("recommended_action", "allow")
    risk_labels = assessment.get("risk_labels", [])

    if action == "block":
        return {"error": "account_locked", "reason": risk_labels}
    elif action == "challenge":
        # 触发二次验证（短信 OTP、邮箱验证等）
        return {"status": "challenge_required", "challenge_type": "otp"}
    else:
        return {"status": "authenticated", "user": user}

前端 SDK 初始化（伪代码，对照实际 SDK 文档替换）

<!-- 在页面 <head> 中加载 Fraud Defense 前端 SDK -->
<script src="https://frauddefense.googleapis.com/v1/js/sdk.js"
        data-site-key="YOUR_SITE_KEY"
        data-action="login"
        async>
</script>

<script>
// SDK 加载后自动采集设备指纹，调用时获取 session token
function onSubmit() {
    gfrauddefense.getToken(function(token) {
        // 把 token 随表单提交到后端
        document.getElementById('fraud_token').value = token;
        document.getElementById('login_form').submit();
    });
}
</script>

上线前需要调整的地方：

FRAUD_DEFENSE_ENDPOINT 路径和请求体字段需对照正式 API 文档。
前端 SDK 的加载 URL 和初始化参数以官方发布为准。
API_KEY 仅用于低价值评估场景；生产环境建议用服务账号 + IAM 权限控制。

从 reCAPTCHA 迁移的考量

如果你现有系统已经接入 reCAPTCHA，迁移时需要想清楚几件事：

渐进替换，不是一刀切

reCAPTCHA 的前端 SDK 和 Fraud Defense 的前端 SDK 不冲突。可以先在新用户注册流程接入 Fraud Defense，登录流程继续用 reCAPTCHA，逐步替换。两条链路并行期间，风险信号可以互相补充——注册阶段 Fraud Defense 标记的虚假账号，登录阶段可以直接拉黑。

阈值策略的交接

reCAPTCHA 时代你自己维护阈值（比如 score < 0.5 就拦截）。Fraud Defense 给你推荐动作，但业务方仍然需要决定：challenge 动作在你的场景下是发短信 OTP 还是弹图形验证？review 动作是进人工审核队列还是自动放行后标记观察？这些决策逻辑不会自动迁移，需要重新设计。

成本结构变化

reCAPTCHA 的定价是按调用次数，简单透明。Fraud Defense 覆盖更多链路、更多信号，定价模型大概率更复杂（按评估次数 + 按风险情报订阅）。迁移前要算清楚：你当前每月多少次 reCAPTCHA 调用？迁移后三条链路各多少次？成本是上升还是下降？

数据合规

Fraud Defense 的跨租户联合建模意味着你的用户行为数据会参与联邦风险模型。虽然 Google 声称数据隔离，但如果你在欧盟或金融行业运营，需要评估 GDPR 和行业监管对数据外传的要求。

检查清单：是否该迁移到 Fraud Defense？

问题	如果答案是"是"
你的业务只有登录页需要防机器人？	reCAPTCHA 可能够用，暂不急迁移
你有注册薅羊毛、支付盗刷等链路欺诈问题？	Fraud Defense 的多链路覆盖直接对症
你的风控团队在手动调 reCAPTCHA 阈值、写规则？	Fraud Defense 的结构化风险标签能减少这部分人力
你已经在用 Google Cloud 的其他安全产品（Cloud Armor、Security Command Center）？	Fraud Defense 和这些产品有集成通道，信号打通成本低
你的用户群体对验证码体验抱怨很多？	Fraud Defense 的行为评估模式减少了显式挑战的频率

一句话总结：如果你的问题只是"登录页防机器人"，reCAPTCHA 还能撑；如果你的问题延伸到"注册防假号、支付防盗刷、全链路防欺诈"，Cloud Fraud Defense 是更对口的工具。但迁移不是换个 SDK 就完事——风控策略、成本模型、合规边界都需要重新梳理。