多因素认证（MFA）— IAM 安全核心：TOTP、FIDO2、WebAuthn 与自适应认证 | IDaaS Book
11.1 密码已死？
“密码就像是蟑螂——你灭不掉它，但你可以让它不再那么讨厌。”
现实情况是：
- 大量数据泄露涉及凭证窃取与滥用（Verizon DBIR 多年报告持续将凭证滥用列为最主要攻击途径之一）
- 用户平均有 100+ 个在线账户，但只使用约 5 个不同的密码
- 即使是最强的密码策略，用户也会想方设法绕过（如 Password123!）
MFA（Multi-Factor Authentication）不是可选项，是必需品——在 IAM 安全体系中，它是防止凭证泄露导致横向移动的最后一道防线。
11.2 认证因素分类
三种基础因素：
| 因素类型 | 说明 | 示例 | 安全性 | 便利性 |
|---|---|---|---|---|
| 知识 | 你知道什么 | 密码、PIN、安全问题 | ★★ | ★★★★★ |
| 持有 | 你拥有什么 | 手机、YubiKey、Token | ★★★★ | ★★★★ |
| 固有 | 你是什么 | 指纹、面部、虹膜 | ★★★★★ | ★★★★ |
| 行为 | 你怎么做 | 击键模式、步态 | ★★★ | ★★★★★ |
什么叫"多因素"？
关键理解：两个密码不是 MFA，密码+短信验证码才是 MFA。
MFA 要求使用至少两个不同类型的因素。密码 + 确认密码 = 单因素。密码 + TOTP = 双因素。
11.3 常用 MFA 方案深度对比
TOTP（Time-based One-Time Password）
基于时间的动态口令，每 30 秒生成一个新的 6 位数字。
工作原理：
- 用户注册时，服务器生成一个密钥（secret）
- 用户将密钥导入 Authenticator App（通过扫描二维码）
- 登录时，App 根据密钥 + 当前时间生成验证码
- 服务器用相同的密钥 + 当前时间验证
优点：
- 免费，不需额外硬件
- 离线可用（不依赖网络）
- 算法公开，多种 App 可选
缺点：
- 时间漂移导致验证失败
- 手机丢失可能导致无法登录（需要恢复码）
- 仍然可以被钓鱼（攻击者诱导用户输入验证码）
推送通知
登录时向用户注册的设备发送推送通知，用户点击"批准"或"拒绝"。
优点：
- 用户体验极好（一键批准）
- 可以看到登录的上下文（位置、设备、时间）
- 可以检测异常并提醒用户
缺点：
- 需要网络连接
- MFA 疲劳攻击（攻击者反复发送通知直到用户误点批准）
- 依赖厂商 App
FIDO2 / WebAuthn
新一代无密码/二因素认证标准。
核心原理：使用公私钥对。私钥由认证器在本地生成与保护，默认不发送给服务器（服务器只存公钥）。根据认证器类型，凭据分为两类：设备绑定凭据（device-bound credential，如多数硬件安全密钥的本地凭据）的私钥不离开设备；而 Passkey（可同步凭据 / multi-device credential） 会经平台 sync fabric（Apple iCloud Keychain、Google Password Manager 等）在用户自有设备间端到端加密同步——但绝不会发送给依赖方（RP）。
注册流程：
- 网站请求注册
- 用户进行本地验证（指纹/PIN/Windows Hello）
- 设备生成公私钥对，私钥安全存储
- 公钥发送给网站存储
认证流程：
- 网站请求认证，发送 challenge
- 用户本地验证
- 设备用私钥对 challenge 签名
- 网站用存储的公钥验证签名
为什么 FIDO2 更强：
- 防钓鱼（Phishing-Resistant）：凭据与 Relying Party ID（rpId，依赖方域名 eTLD+1）绑定，浏览器只允许在匹配 rpId 的站点调用认证器，签名数据包含 origin 与 rpId，服务器端必须严格校验二者，攻击者无法在假冒网站上完成认证
- 无共享密钥：服务器只存公钥，数据泄露也不影响认证安全
- 跨设备：Passkey（可同步凭据）的私钥可通过平台（Apple/Google/Microsoft）在用户自有设备间端到端加密同步
实现方式：
- Platform Authenticator：设备内置（Windows Hello、Apple Touch ID/Face ID、Android 生物识别）
- Cross-Platform Authenticator：外部硬件（YubiKey、Feitian ePass）
硬件安全密钥
物理 USB/NFC/蓝牙设备，如 YubiKey 系列。是最安全的 MFA 方式之一。
适用场景：高价值用户（管理员、财务、高管）、高安全合规场景（如 FedRAMP High、PCI DSS 对持卡人数据环境访问的 MFA 强制要求——合规要求的是 MFA，硬件密钥是其中最强的因素之一，而非合规强制使用硬件密钥）。
短信/邮件验证码
安全性最低的 MFA 方式，应尽量避免。
风险：
- SIM 卡交换攻击（SIM Swapping）
- SS7 协议拦截
- 邮箱密码与账户密码相同（形成单因素）
- 信号不好时接收不到
但在低风险应用或作为"备选"方案时仍有其价值。
11.4 自适应认证（Adaptive Authentication）
MFA 不是"全有或全无"。自适应认证根据风险动态调整认证强度：
风险评分计算：
├── 用户属性：角色、权限级别、历史行为
├── 设备信息：是否受信任设备、是否新设备
├── 地理位置：是否在常用地点、国家
├── 网络信息：IP 信誉、是否匿名网络
├── 时间因素：是否在正常工作时间
├── 行为特征：登录速度、鼠标移动模式
└── 资源敏感度：访问的资源的敏感级别
风险 = 低 → 密码即可
风险 = 中 → 密码 + TOTP
风险 = 高 → 密码 + 硬件密钥 + 管理审批
风险 = 极高 → 拒绝访问实现架构
用户登录请求
│
▼
认证服务
│
├──→ 风险引擎（计算风险分数）
│ ├── 设备指纹
│ ├── 地理位置
│ ├── IP 信誉
│ ├── 行为分析
│ └── 用户画像
│
├──→ 策略引擎（根据风险分数 + 策略决定）
│ ├── 风险 0-30：放行
│ ├── 风险 31-60：要求 MFA
│ ├── 风险 61-80：要求 FIDO2
│ └── 风险 81-100：拒绝 + 告警
│
└──→ 认证结果11.5 MFA 策略设计
推荐配置
| 用户角色 | 登录方式 | MFA 方式 |
|---|---|---|
| 普通用户 | 密码 | TOTP（可选但有推荐） |
| 重要用户 | 密码 | TOTP 或推送通知（必须） |
| 管理员 | 密码 | FIDO2 或硬件密钥（必须） |
| API 服务 | 客户端凭证 | 证书认证 |
恢复机制
MFA 失效后的恢复是常被忽视的关键设计：
- 恢复码（Recovery Codes）：一次性使用的备用码（如 10 个 8 位数字）
- 管理员重置：Help Desk 通过身份验证后重置 MFA
- 备用 MFA 方式：注册多个 MFA 设备
- 信任的朋友：通过已信任的联系人验证
恢复流程的风险必须与"真正的密码重置流程"同等重视，因为攻击者经常瞄准这个"后门"。
11.6 无密码认证（Passwordless）
MFA 的终点是无密码。当前主要趋势：
Passkey（通行密钥）
FIDO2 的消费者友好名称。Apple、Google、Microsoft 联合推动，并自 2022 年起在各自平台原生支持、规模化普及。用户用指纹或面部在注册的设备上完成认证，Passkey 通过平台账户（iCloud Keychain、Google Password Manager、Microsoft 账户）端到端加密跨设备同步；FIDO 联盟也已推出跨平台凭证导出/导入标准，逐步打通不同生态间的 Passkey 迁移。
实现策略
不是一下子全部无密码，而是渐进式：
- 密码 + MFA → （当前状态）
- 密码 + FIDO2 → （增强安全性）
- 无密码登录选项 + 密码作为备用 → （过渡期）
- 完全无密码 → （最终目标）
对于希望直接从第 3 阶段起步的项目， Hanko 是一个 Passkey-first 的开源认证方案：支持直接禁用密码、用 Web Component 一行嵌入登录页。它在面向消费者的 SaaS 场景中特别实用——不需要从密码体系逐步过渡，而是直接面向 Passkey 设计。
11.7 Keycloak 中的 MFA 实现
参考现有文档：/docs/keycloak/security-features/mfa/
关键配置点：
- Browser Flow 中 OTP 的条件配置
- Required Action 的设置
- 自定义 SPI 实现短信验证码
- 基于角色的条件认证（管理员 vs 普通用户有不同的 Flow）
完整的条件认证（按角色/IP/场景分级）和 Step-Up 二次认证配置步骤，见 Keycloak 条件认证与 Step-Up 实战——涵盖三种常用模式：基于角色的条件 OTP、基于 IP 位置的条件 MFA、敏感操作 Step-Up 认证。Passkey/WebAuthn/FIDO2 从协议到 Keycloak 配置的完整指南（含 Mermaid 流程图、企业部署策略和常见错误排错），参见 Passkey / WebAuthn / FIDO2 IAM 企业落地指南。
11.8 小结
MFA 是 IAM 安全的基石——在身份与访问管理体系中，它是认证安全性的最后一道防线。从 TOTP 入门到 FIDO2 高级实现，选择正确的 MFA 方案需要平衡安全性、用户体验和运维成本。自适应认证已成为 IAM 主流实践——不是对所有人都要求最强 MFA，而是根据实际风险动态调整。最终目标是无密码认证，但这条路需要每一步都走稳。
11.9 IAM 多因素认证 FAQ
Q: IAM 体系中 MFA 部署优先级怎么排？ A: 先覆盖高权限账号（管理员、运维、财务），再覆盖普通员工，最后考虑 C 端用户。攻击者要的不是普通员工账号，是有权限改配置、看数据、转钱的那个。把最强的 MFA（FIDO2/硬件密钥）留给这些账号，ROI 最高。
Q: IAM 的 MFA 和应用的 MFA 有什么区别？ A: 应用的 MFA 是每个应用自己实现一套（密码 + 短信），各个应用不互通。IAM 的 MFA 是在身份层统一实现一次，所有接入的应用都受益。在 IAM 中配一次 FIDO2，所有通过 OIDC/SAML 接入的应用都不需要再配一遍。
Q: 企业 IAM 部署 MFA 最大的坑是什么？ A: 恢复机制没设计好。用户换手机、丢 YubiKey、出差没带硬件密钥——这些场景天天发生。如果 Help Desk 的 MFA 重置流程是「给 IT 打个电话就能绕过」，那攻击者会把 Help Desk 作为突破口。设计恢复流程时要把它当作和主认证同等安全等级来审计。