金融机构的双因素认证（八）：合规倒推方案

TL;DR

这是《金融机构的双因素认证》系列的第八篇，也是收尾篇。前七篇按认证方案逐一展开：短信验证码、硬件动态口令、手机动态口令、数字证书与硬件密钥、生物识别、专线场景特有方案，每篇都用第 1 篇立的强度分级尺给自己定了位。

这一篇不再讲新的方案原理，只做一件事：把这些定位汇总成一张表，给出一条从「系统的合规定级」倒推到「该配什么方案组合」的判断路径。

1. 强度分级汇总表

先把前七篇的定位并排放在一起：

方案	强度等级	关键约束	详见
短信验证码	L1	强度上限被电信运营商的核实流程钳制，机构自身管控措施无法提升	第2篇
手机 App 动态口令（BYOD）	L1–L2 之间	强度取决于机构对用户手机的管控力，管控力弱则接近 L1	第4篇
生物识别（服务端匹配，作为第二因素）	L1–L2 之间	模板集中存储带来系统性泄露风险；不可撤销、不可更换	第6篇
硬件动态口令（HOTP/TOTP 令牌）	L2	密钥不接触用户个人设备，弱点集中在种子分发供应链	第3篇
手机 App 动态口令（机构统一管控+MDM）	L2	接近硬件令牌，但攻击面仍略宽	第4篇
生物识别（本地匹配，作为第二因素）	L2	模板存储在设备本地安全区域，风险敞口限于单台设备	第6篇
USB Key / 智能卡 + PIN	L3	私钥不出硬件，持有硬件+知道PIN构成真正双因素	第5篇
证书 + HSM 托管私钥	L3	机构侧批量密钥的私钥不出硬件方案	第5篇

口令卡（第3篇提到的更朴素形态）没有单独列入此表，它的强度低于 HOTP/TOTP 硬件令牌，更适合作为备用手段而非主力方案，不建议作为新建系统的首选。

专线场景的分层组合（第7篇：IP白名单 + 证书 + 会话级认证）不在这张表里单独列一行，因为它不是一个独立的「因素」，而是一套围绕上表任一方案的补充设计，它能降低链路层面的攻击可行性，但不改变上表里任何方案本身的强度等级。

2. 决策路径：三步倒推

选型不应该从「我喜欢哪个方案」出发，而应该从系统本身的定级要求倒推。三步走：

图1：从定级到方案组合的倒推路径

第一步：确定定级。按第1篇引用的 GB/T 22239-2019（等保2.0）第三级身份鉴别条文，多数金融机构的核心业务系统至少落在第二级，对应的底线要求是「两种或两种以上组合的鉴别技术，且其中一种至少使用密码技术」。这条底线排除了纯短信验证码、纯生物识别单独使用的组合，对应到上表大约是 L2 及以上的方案才能满足。具体系统的定级需要按机构自身适用的规范核实，不能一概而论。

第二步：确定场景类型。内部落地系统和专线托管端系统在同一强度等级下，落地方式不同，这是本系列反复强调的差异点。回顾一下两类场景各自的关键约束：

内部落地系统：信任边界完全在机构自己手里，终端可管控、种子/私钥的分发链路可以完全走内部渠道。这类场景选方案时，约束更多来自机构自身的运维能力和预算，而不是外部信任主体的配合程度。
专线托管端系统：信任边界横跨机构和托管方两个主体，谁来发放硬件、谁来管理证书体系、谁承担审计责任，都需要在协议里划清楚。这类场景选方案时，还要考虑托管方自身的技术能力和意愿。机构想要的方案，托管方未必能配合到位。

第三步：结合可用性与成本。满足最低强度要求只是门槛，不是终点。同样达到 L2 的方案里，硬件令牌和手机 App（机构管控设备）的运维成本和用户体验不同；同样达到 L3 的方案里，USB Key 和 HSM+证书体系的实施复杂度也不同。这一步没有标准答案，需要结合机构自身的用户规模、预算、现有基础设施来判断。

3. 一张简化的场景 × 方案参考表

把前面的判断路径落成一张更具体的参考表（注意：这是简化的参考起点，不是可以直接套用的最终结论）：

场景	典型定级诉求	建议起点	备注
内部落地系统，核心交易/风控类	满足等保三级底线，通常需要更高	USB Key/智能卡 + PIN（L3）	用户规模可控，硬件发放和运维走内部渠道成本可接受
内部落地系统，一般管理/办公类	满足等保二级底线	硬件 OTP 令牌或机构管控设备上的手机 App（L2）	在满足底线的前提下，优先选运维成本更低的方案
专线托管端系统，交易/清算类	通常需要更高强度，且信任链跨机构	证书 + HSM（L3）+ IP白名单/会话级认证（第7篇分层组合）	谁发放证书、谁管理HSM，需在协议中明确
专线托管端系统，一般对接类	满足底线	硬件 OTP 令牌（L2）+ IP白名单	托管方通常统一管理令牌，机构侧主要通过协议和审计约束风险

这张表是简化的起点，不能替代针对具体系统的完整风险评估。实际选型还需要结合系统承载的业务重要性、监管适用范围、托管方的技术能力等具体因素，不能照抄表格结论。

4. 系列回顾

这个系列从一个前提反转开始：互联网 2FA 的默认假设（终端不可控、网络不可信、体验优先）在金融机构的内部落地系统和专线托管端系统里大多不成立，评估标准需要跟着换。

七篇方案文章沿着同一条结构走：原理→内部落地系统怎么用→专线托管端怎么用→已知弱点→强度尺定位。走完一遍会发现，方案强度的本质差异，几乎都能归结到同一个问题：认证过程中最关键的那个秘密（验证码、密钥、私钥、生物特征模板），它的信任边界由谁控制。短信验证码交给了电信运营商，手机 App 交给了用户个人设备的健康状况，硬件令牌和 USB Key 把这个边界收回到了机构自己（或者从设计上让秘密从不离开硬件）。

这条线索，比记住每种方案的名字更值得带走。

系列完整目录：

评论