【身份与访问控制工程】风险感知认证：设备信任、异常登录与挑战升级

前两篇讨论了 MFA 和 Passkey——它们是固定的安全策略。用户开启 MFA 后，每次登录都要输入额外的验证码，即使在可信设备上、在常用网络下、在正常工作时间。

风险感知认证（Adaptive Authentication，也叫 Risk-based Authentication）让系统根据风险评估结果动态决定认证强度。核心思想很简单：如果一切正常（已知设备、已知 IP、已知时间），密码就够了；如果出现了异常信号，要求 MFA；如果高度可疑，直接拒绝并要求人工介入。

一、风险引擎的信号模型

风险引擎接收一系列信号，输出一个风险分数。分数高于阈值触发挑战升级，分数极高触发强制拒绝。

现代风险引擎使用的典型信号：

信号类别	示例信号	可获得性	信号噪声
设备指纹	浏览器指纹、Cookie、device_id	高（前端 JS + Cookie）	低（可信设备判断准确率高）
网络	IP 地址、ASN、GeoIP、Tor exit node	高（服务端从连接中提取）	中（企业 VPN 出口 IP 可能被误判为异常）
地理位置	GPS（移动端）、GeoIP（Web）	中（需要用户授权）	高（VPN 掩盖、IP 库不精确）
行为	键入节奏、鼠标移动、屏幕触摸模式	低（需要大量基线数据）	高（仅头部安全厂商产品化较好）
时间	登录时间、距上次登录的时间差	极高	低
账号活动	近期登录失败次数、近期密码修改、近期权限变更	高（IdP 自身数据）	低

1.1 设备指纹

设备识别是风险引擎中最可靠也最复杂的信号源。不同的识别方法有不同的持久性和覆盖范围：

方法	持久性	跨浏览器	准确率
持久 Cookie（`trusted_device_id`）	中（用户清除后失效）	否（同浏览器内）	高
LocalStorage / IndexedDB marker	中	否	高
浏览器指纹（Canvas、WebGL、字体列表、User Agent）	高（相对稳定）	否（每个浏览器指纹不同）	中-高（可区分 90%+ 设备）
证书（mTLS 客户端证书、设备管理证书）	极高（除非重新安装 OS）	是（系统级别）	极高
原生 App 的设备 ID（Android `ANDROID_ID`、iOS `identifierForVendor`）	高	N/A（App 内）	极高

工程陷阱 1：浏览器指纹在隐私法规（GDPR、CCPA）下的合规性问题。指纹收集通常需要用户同意，因为它跨越多个浏览会话追踪用户。如果你做面向欧盟用户的 B2C SaaS，优先使用”用户显式信任的设备”（Cookie + trusted_device_id）而非隐藏指纹收集。

1.2 网络与地理位置

IP 地址是最容易获取的信号，但也最容易误判：

企业 VPN 出口 IP：Google Workspace 的企业用户可能全部从 199.36.153.x 登录——这对 GeoIP 库意味着”来自美国”，但 IT 部门的 VPN 出口 IP 是固定的。风险引擎应支持 IP 白名单。
移动网络的 IP 复用：运营商 NAT 下，同一 IP 可能同时服务多个用户。
GeoIP 的精度：城市级别的精确率约 80%（MaxMind GeoIP2 City）。把 IP 变化 100 公里当成”不可能旅行”会误判合法用户。

二、风险分数计算与策略决策

2.1 评分模型

简单的评分模型是加权求和：

\[R = w_1 \cdot s_{device} + w_2 \cdot s_{network} + w_3 \cdot s_{geo} + w_4 \cdot s_{behavior} + w_5 \cdot s_{time}\]

每个 \(s_i\) 是 0-1 的归一化分数，权重取决于场景。

风险等级	分数范围	响应策略
低风险	0-0.3	允许密码登录，不要求 MFA
中等风险	0.3-0.6	要求 MFA（TOTP 或推送通知）
高风险	0.6-0.9	要求 WebAuthn/Passkey + 强制通知用户（邮件/SMS）
严重风险	0.9-1.0	拒绝登录，触发安全事件工单

2.2 策略引擎的执行点

风险策略在 OAuth/OIDC 流程中的执行点：

sequenceDiagram
    participant User as 用户
    participant RP as 应用
    participant OP as IdP

    User->>RP: 1. 访问受保护资源
    RP->>User: 2. 重定向到 OP
    User->>OP: 3. GET /authorize (风险引擎在这里介入)

    Note over OP: 4. 收集信号<br/>设备指纹 Cookie<br/>IP + GeoIP<br/>登录历史
    Note over OP: 5. 计算风险分数

    alt 低风险
        OP->>User: 6a. 直接密码认证
    else 中等风险
        OP->>User: 6b. 密码 + TOTP
    else 高风险
        OP->>User: 6c. 密码 + WebAuthn + 邮件通知
    end

    OP->>User: 7. 302 回调 RP

三、挑战升级（Step-up Authentication）

风险感知认证不只作用于登录时刻——它也作用于会话中间。“Step-up Auth”是指用户在已经登录的状态下，尝试执行敏感操作（修改密码、转账、查看敏感数据），系统要求重新认证。

在 OIDC 中实现 Step-up 的方式是通过 acr_values（Authentication Context Class Reference）参数：

GET /authorize?response_type=code&...&acr_values=urn:mace:incommon:iap:silver

OP 检查用户当前的会话认证等级是否满足 acr_values 的要求。如果不满足，强制重新认证（如要求 WebAuthn）。

工程陷阱 2：Step-up Auth 不能只在前端做。如果你只在前端弹一个 re-auth 模态框，攻击者可以通过绕过 JavaScript（如直接调用 API）来跳过 Step-up。Step-up 的强制性必须在后端——资源服务器在收到敏感操作请求时，独立验证 token 中的 acr claim。

四、持续会话风险评估

登录时刻的风险评估在接下来的几小时到几天内可能过时。一个在”可信设备 + 可信网络”下登录的会话，可能在网络变化后变得不可信。

持续风险评估的三种探测方式：

网络切换事件：用户从办公室 Wi-Fi 切换到公共 Wi-Fi。浏览器/App 检测到网络变化后通知服务端。
基于 IP 的周期性检查：服务端每 N 分钟检查客户端的源 IP 变化。如果 IP 变化幅度超过阈值（如从东京跳到纽约），触发 Step-up。
行为异常检测：正常的用户看文档，攻击者用偷来的会话批量下载敏感数据。API Gateway 层的速率异常可以触发会话冻结。

五、小结

风险感知认证不是在 MFA 上”加点规则”——它是对认证过程的重新建模：认证不再是单次事件，而是信号收集→风险评估→挑战决策→持续监控的连续过程。

工程落地建议： 1. 从最简单的信号开始（设备信任 + IP + 登录历史），先建立评分骨架，逐步丰富信号。 2. 设备信任是最高杠杆的信号——一个可信设备 Cookie 就能消除大部分用户的 MFA 摩擦。 3. 做 Step-up 时，敏感操作的后端必须有独立的验证（不能只依赖前端的弹窗）。 4. 记录和可视化风险引擎的决策——安全团队需要能查到”为什么这个用户的 MFA 被跳过了”。

上一篇：MFA、TOTP、WebAuthn、Passkey 工程实践 下一篇：服务身份：mTLS、SPIFFE/SPIRE 与 Workload Identity

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-06-12 · architecture / security

【身份与访问控制工程】风险感知认证：设备信任、异常登录与挑战升级

文章导航

目录