一、为什么"用户名+口令"这两年在测评现场越来越难过关

如果你所在的企业正在准备等保测评或者商用密码应用安全性评估（下文简称"密评"），大概率会遇到这样一个场景：测评师打开你的服务器登录界面，输入账号密码就能进入系统，然后在测评记录表里写下"身份鉴别未采用两种或两种以上组合的鉴别技术"，判定为不符合项。

这一条之所以高频被查，原因并不复杂。等保2.0把"身份鉴别"放在安全计算环境的第一条，是所有控制项里最基础、也最容易被抽样验证的一条——它不像"应启用安全审计"那样需要看日志留存周期，也不像"数据完整性"那样需要抓包分析，测评师只要在登录环节亲手试一次就能定性。

而密评这条线更严格。密评关注的不是"你有没有做认证"，而是"你的认证用的是什么密码技术、密码产品有没有合规资质、密钥在哪儿产生、私钥会不会被导出"。所以很多企业会出现一个尴尬的局面：等保那边双因素已经过了，密评这边还是被判"身份鉴别未使用合规密码技术"，因为他们的双因素用的是短信验证码或者基于国际算法的软件令牌，压根没有密码产品参与。

很多团队在百度搜索"等保2.0双因素认证方案"时，真正想确认的其实不是"要不要上双因素"，而是三个更具体的问题：第一，双因素要用什么形态才能同时满足等保和密评；第二，用了国密USBKey之后，SM2、SM3、SM4分别在哪个环节起作用，测评师问起来怎么答；第三，二级系统的密评到底要准备哪些证据材料。本文就围绕这三个问题展开。

二、先厘清两条线：等保2.0和密评不是一回事

工程上最常见的误区，是把等保2.0和密评混为一谈。它们确实有交叉，但法律依据、测评依据、关注点和产出物都不同。

等保2.0（网络安全等级保护） 依据的是《网络安全法》确立的等级保护制度，测评依据是GB/T 22239系列标准。它覆盖"安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理制度"等层面，身份鉴别只是安全计算环境里的一个控制点。等保的结论是"优/良/中/差"四个等级。

密评（商用密码应用安全性评估） 依据的是《密码法》第二十七条，测评依据是GM/T 0054《信息系统密码应用基本要求》和相关行业指导文件。它只关注一件事：系统到底有没有"用对、用全、用合规"密码。密评的测评框架是"四个技术+四个管理"：

• 四个技术层面：身份鉴别、访问控制（含权限）、数据传输保护、数据存储保护，此外还有"不可否认性"（三级系统要求）；
• 四个管理层面：管理制度、人员管理、建设运行、应急处置。

密评的结论分三档：符合、基本符合、不符合。

两条线的关系可以这么理解：等保2.0问的是"你做没做安全措施"，密评问的是"你的密码用得对不对"。等保2.0三级明确要求"应采用两种或两种以上组合的鉴别技术"，但并没有强制要求用密码技术；而密评则明确要求身份鉴别环节"应使用密码技术"，并且所用的密码产品需具备相应资质。

这就是为什么一个只靠"口令+短信验证码"的方案，等保可能勉强过（短信验证码算第二种鉴别技术），但密评一定过不了——短信通道本身没有密码技术参与，验证码在服务端是明文生成和比对的。

很多企业在百度搜索"密评二级需要准备什么材料"时，其实已经把两个概念混在了一起：密评的结论是"符合/基本符合/不符合"，并不分一级二级；所谓"二级"指的是被测系统的网络安全保护等级。等级不同，GM/T 0054 里对应的条款强度就不同——二级系统里大量条款的表述是"宜"，三级系统则升级为"应"。所以准备材料前，先确认自己系统的定级备案结论，再按对应档次的条款逐条对照，能少走很多弯路。

还有一点必须提前说清楚：密评不是"三级系统才做"。按《密码法》要求，关键信息基础设施和等保三级及以上系统应当开展密评；等保二级系统在实际监管中越来越多地被要求同步做密码应用梳理，尤其是政务、金融、能源、交通、医疗等行业的主管单位会自行提出要求。所以本文后面给出的证据材料清单，按二级系统的常见要求来组织，三级系统在同样的框架上把"宜"改成"应"、把强度指标提高即可。

三、条款逐条拆解：身份鉴别到底被要求了什么

3.1 等保2.0的身份鉴别条款

等保2.0在"安全计算环境—身份鉴别"这一控制点下，通常包含以下几条要求（三级系统的表述，二级系统强度略降）：

1. 应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换。
   这一条拆开是四个子项：唯一身份标识（不能共用账号）、复杂度（口令长度与字符组合）、定期更换（口令生命周期）、以及"鉴别"本身。

2. 应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施。
   也就是失败锁定、会话超时、连接超时退出。

3. 当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听。
   这一条直指明文传输。Telnet、FTP、HTTP Basic这类明文协议在测评现场是必被记录的。

4. 应采用两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。

第4条的"其中一种鉴别技术至少应使用密码技术来实现"是关键限定语。它把"双因素"从"任意两个因子"收窄成了"至少一个因子必须是密码技术"。短信验证码、邮箱验证码、图形验证码、扫码确认这四类，本质上都是"你知道的"或"服务端推送的一次性凭据"，不构成密码技术；而基于挑战-响应、数字签名、SM2签名验签的机制，才是条款认可的密码技术。

3.2 密评的身份鉴别条款

密评在"身份鉴别"这个技术层面，核心要求可以归纳成三句话：

• 应使用密码技术对登录用户进行身份标识和鉴别；
• 身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换（与等保共用）；
• 宜采用动态口令、数字签名、生物特征等两种或两种以上组合的鉴别技术，且其中一种应基于密码技术实现。

同时，密评会把身份鉴别和另外两个技术层面串起来一起看：

• 数据传输保护：身份鉴别过程中传输的鉴别信息（口令、挑战值、签名值、令牌）必须做机密性和完整性保护；
• 不可否认性：三级系统要求对关键操作（如登录、审批、指令下发）提供基于数字签名的抗抵赖能力。

换句话说，密评不是单点检查，而是考察"身份鉴别这条链路上，密码技术应用是否连贯"。如果认证客户端和服务端之间是明文HTTP，即便内部用了SM2签名，测评师也会在"数据传输保护"层面判不符合，进而影响整体结论。

3.3 一个容易忽略的点：密码产品资质

密评还有一个"一票否决"性质的检查项：所使用的密码产品、密码服务应当经商用密码检测认证合格。也就是说，你不能用一个自己写的SM2库、或者一个开源密码库来充当"密码技术应用"，必须采用具备《商用密码产品认证证书》的硬件或软件模块，并且算法实现要符合GM/T相关标准。

这就是为什么"我们自己实现了SM2签名"在测评现场通常不被采信——缺少密码产品资质这一环。国密USBKey之所以在这类场景里被广泛采用，正是因为它是一个具备资质的独立密码产品：密钥在硬件内生成、私钥不可导出、签名运算在芯片内完成。

四、为什么"用户名+口令"从原理上就不满足

我们把口令认证的攻击面完整列一遍，就能理解为什么它被条款否定。

第一，口令是单一因子，属于"你知道的"。 它被窃取的方式包括：撞库（其他站点泄露的口令复用）、钓鱼（伪造登录页）、暴力破解与字典攻击、键盘记录、肩窥、社会工程学。行业统计里有一个被反复引用的数字：约81%的数据泄露与弱口令或凭证盗用相关。口令一旦泄露，攻击者就是一个"合法用户"，所有基于身份的访问控制全部失效。

第二，口令在服务端是可被验证的，这本身就是风险。 服务端必须持有口令的某种可验证形式（口令本身或哈希值），因此在传输环节必须做保护，在存储环节必须做加盐哈希、且不能用MD5/SHA1这类已被认定不安全的算法。

第三，口令无法提供抗抵赖。 两个人知道同一个口令，系统无法区分是谁登录的。这直接导致审计日志失去法律意义上的证据价值——在安全事件复盘和责任认定时，"这个账号的操作是谁做的"成了无解问题。

第四，口令无法解决账号共享。 这一点在服务器运维场景尤其致命。一台Linux服务器上的root账号、一个Windows的本地管理员账号，往往被整个班组共用。口令一旦共享，唯一身份标识这一条就已经不成立了。

第五，口令在传输环节的明文风险。 很多老旧系统、工控终端、网络设备的管理口仍是明文协议，抓包即可还原口令。等保条款里"当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听"就是针对这一条。

把这几条对应到条款上，结论很清楚：口令可以通过"复杂度+定期更换+失败锁定"满足第1、2条，但无法满足"两种或两种以上组合的鉴别技术，其中一种应基于密码技术"这一条，也无法提供不可否认性。

五、国密USBKey的双因子机制与"私钥不出硬件"

5.1 双因子是怎么构成的

国密USBKey在登录场景里提供的第二个因子，是"你拥有的（硬件密钥）+ 你知道的（Key的保护口令/PIN）"的组合。落到等保条款上：

• 第一因子：你知道的 —— 操作系统账号口令（Windows登录密码、Linux用户口令）；
• 第二因子：你拥有的 + 基于密码技术的 —— USBKey硬件内的SM2私钥签名。

注意第二因子本身内嵌了密码技术，因此天然满足"其中一种鉴别技术至少应使用密码技术来实现"这一限定。

5.2 挑战-响应与签名验签的完整流程

这里把一次完整的认证流程拆开讲，这是测评师最爱问的环节：

┌──────────────┐                              ┌──────────────────┐
│  终端侧       │                              │  认证服务端        │
│ (SLA Agent)  │                              │  (ASP / 本地策略) │
└──────┬───────┘                              └────────┬─────────┘
       │                                                │
       │ 1. 插入USBKey，输入PIN解锁                      │
       │    (PIN校验在Key内完成，错误计数在硬件内)        │
       │                                                │
       │ 2. 提交用户名 + KeyID ────────────────────────>│
       │                                                │
       │                                3. 服务端查KeyID绑定的用户
       │                                   生成随机数R(挑战值)
       │                                                │
       │ <────────── 4. 下发挑战值R + 会话标识 ─────────│
       │                                                │
       │ 5. 调用Key内SM2私钥对 (R || 用户信息 || 时间戳)
       │    做数字签名 sig = SM2_Sign(SM3(R||...), 私钥)
       │    ★ 私钥全程不出USBKey安全芯片边界              │
       │                                                │
       │ 6. 上传 sig + Key证书/公钥标识 ───────────────>│
       │                                                │
       │                                7. 用SM2公钥验签
       │                                   校验R是否为本会话下发
       │                                   校验时间戳防重放
       │                                                │
       │ <────────── 8. 认证通过，放行操作系统登录 ──────│
       │                                                │
       │ 9. 后续会话密钥用SM4保护，报文带SM3-HMAC完整性校验│

几个必须讲清的设计细节：

• 挑战值R由服务端随机生成且一次性使用。客户端不能自己造挑战值，否则重放攻击成立。服务端要校验R是否为本次会话下发、是否已被使用过。
• 签名数据里必须带时间戳或会话标识，否则攻击者截获一次签名后可以无限次重放。
• PIN校验在Key内完成，错误计数也在硬件内。这意味着离线暴力猜PIN会被硬件锁死（常见实现是连续错误若干次后锁死，需管理员解锁或PUK解锁），不会被软件绕过。

5.3 私钥不出硬件为什么是条款的关键

"私钥不出硬件"这句话在密评里有明确的对应关系：

1. 密钥管理层面：密钥在密码产品内部产生并存储，私钥不以任何形式导出到产品边界之外。这满足密评对"密钥生成、存储、使用"环节的要求——密钥生成应在合规密码产品内完成，不能以明文形式出现在产品外部。
2. 密码运算层面：签名运算在密码产品内部完成。即便终端主机已被植入木马、内存被dump，攻击者拿到的也只有签名结果，拿不到私钥，无法伪造签名。
3. 责任认定层面：因为签名只能由持有该Key的人产生，一次签名就是一次不可否认的行为。这为三级系统的"不可否认性"要求提供了技术基础。

反过来看，如果第二个因子是软件实现的（比如把密钥文件存在磁盘上、用代码读私钥做运算），那么在密评现场，测评师会追问"密钥在何处产生、以何种形式存储、能否被导出"，一旦回答是"存在文件里、可以被导出"，这一项就很难判符合。

5.4 私钥不可导出 ≠ 不可备份

工程上还要解决一个现实问题：Key丢了怎么办。常见做法是建设一套密钥管理基础设施，在密钥生成阶段采用"双证书"或"密钥备份"机制——密钥对在密码产品内生成时，通过安全通道把私钥的加密副本托管到密钥管理系统中，需要补发时再通过安全流程恢复到一张新的Key里。这样既保证了"使用环节私钥不出硬件"，又保留了业务连续性。

六、SM2 / SM3 / SM4 在身份鉴别与传输保护中的分工

这是测评现场被问得最多的问题。三个算法各司其职，不能互相替代。

算法	类型	在身份鉴别中的位置	在传输保护中的位置	常见误用
SM2	非对称（椭圆曲线）	私钥签名实现挑战-响应认证；公钥验签；用户证书/Key证书载体	会话密钥协商（SM2密钥交换协议）或加密会话密钥	用SM2直接加密长数据（算法不适合，应做信封加密）
SM3	杂凑（哈希）	对挑战值+用户信息做摘要后再签名；口令派生与存储	HMAC-SM3做报文完整性校验	把SM3当加密用；用SM3裸哈希存口令而不加盐
SM4	对称分组	保护本地凭据保险箱、配置文件中的鉴别信息	鉴别报文与业务数据的机密性加密（CBC/GCM等模式）	IV复用、ECB模式、密钥硬编码

具体落到操作系统登录这个场景，链路是这样的：

• 认证阶段：服务端下发随机挑战值 → 终端侧用SM3对（挑战值||用户标识||时间戳）做摘要 → 用USBKey内SM2私钥对摘要做签名 → 服务端用SM2公钥验签。这里SM3的作用是"把任意长度数据压缩成固定长度摘要"，SM2的作用是"提供只有私钥持有者才能产生的、可公开验证的签名"。
• 会话阶段：认证通过后，双方通过SM2密钥交换协商出会话密钥，后续所有鉴别相关信息与审计上报通道用SM4加密，每条报文附加SM3-HMAC做完整性校验。
• 存储阶段：本地的策略文件、凭据保险箱、离线应急口令的种子数据，用SM4加密存储，主密钥由服务端下发并由硬件保护。

有一个细节值得单列：SM2签名前要先用SM3做摘要。这不是可选项，而是SM2算法规范本身的规定——SM2的数字签名算法输入是待签消息的摘要值。所以"SM2签名"这个动作天然包含了一次SM3运算，在给测评师讲解时要说清楚这一点，避免被误解为"只用了SM2没用SM3"。

另外，若环境中仍保留口令因子，口令不应以明文或裸哈希形式存储，正确做法是加盐后用SM3做多次迭代派生（类似PBKDF2-SM3的思路），并把迭代次数、盐值作为可配置项留存，测评时可直接出示配置截图作为证据。

七、密评二级：证据材料清单

二级系统的密评，重点不在于"用了多少高级技术"，而在于"能不能拿出完整、自洽、可核验的证据链"。按密评"四个技术+四个管理"的框架，把材料清单列出来（三级系统在同样框架上提高强度要求，并增加不可否认性材料）。

7.1 管理制度类

1. 密码应用管理制度（正式发布、有版本号、有发布日期）；
2. 密码产品采购与使用管理规范；
3. 密钥生命周期管理规范（生成、存储、分发、使用、更新、归档、销毁）；
4. 密码应用应急处置预案，以及至少一次演练记录；
5. 密码管理人员岗位职责与人员登记表（含保密协议）。

7.2 建设运行类

1. 密码应用方案（或改造方案）：这是密评的"总纲"，要写清系统边界、密码应用需求、技术路线、密码产品清单；
2. 密码应用方案评审意见：方案需经评审，评审意见要留存；
3. 密码产品清单及资质：每张USBKey型号对应的《商用密码产品认证证书》复印件、认证范围页、型号核对表；
4. 密码服务/中间件清单及资质（若使用密钥管理系统、签名验签服务器等，同样要提供资质）；
5. 实施记录：部署记录、密钥灌装/发行记录、Key发放登记表（领用人签字）、回收与销毁记录；
6. 联调与验收报告：认证功能测试报告、性能与稳定性测试记录。

7.3 技术验证类（测评现场实测）

1. 身份鉴别实测演示：现场插Key、输PIN、挑战-响应登录的完整过程录屏；
2. 传输保护抓包证据：抓取认证过程报文，证明鉴别信息、挑战值、签名值均在SM4加密通道内传输，且带SM3-HMAC完整性校验；
3. 算法合规性验证：使用合规密码产品产生的签名值/密文，配合标准检测工具验证算法正确性；
4. 随机数检测：若系统内有自研随机源，需提供随机性检测报告；使用合规密码产品内部随机源则可引用产品检测报告；
5. 密钥管理实证：演示私钥不可导出（尝试导出失败）、密钥在硬件内产生、PIN错误锁定机制；
6. 日志与审计记录：认证成功/失败日志、Key发放与回收日志、管理员操作日志，以及日志完整性保护方式说明。

7.4 应急处置类

1. 应急场景清单：Key丢失、Key损坏、PIN锁死、服务端故障、批量补发；
2. 对应的处置流程与责任人；
3. 演练记录（含时间、参与人、处置耗时、改进项）。

7.5 一份容易被忽略的材料：证据的"自洽性"

很多企业材料准备得很全，但被判"部分符合"，原因是证据之间对不上。举几个真实高频的坑：

• 方案里写"采用SM2算法"，但密码产品证书上的算法列表只有SM1/SM4，没有SM2——型号没核对；
• 方案里写"服务器操作系统纳入认证范围"，但实际只部署了20台，另外80台没装——部署记录与方案范围不一致；
• 密钥管理规范写"私钥不可导出"，但实施记录里有"导出私钥用于测试"的操作记录——制度与执行冲突；
• 应急处置预案里有"Key丢失补发流程"，但没有演练记录——管理层面判不符合。

所以准备材料的核心原则是：方案写什么，实施记录就要有什么，现场就要能演示什么。三者必须对得上。

八、测评常见整改项与落地路径

根据一线项目经验，把操作系统登录双因素这个场景的高频不符合项归纳成六类，并给出对应的落地路径。

不少运维负责人在百度搜索"操作系统双因素认证怎么部署"时，最担心的其实不是技术本身，而是终端种类太杂——Windows 与 Linux 混装、国产操作系统版本各异、还有一批无法联网的外场设备。事实上测评判定看的是"纳入范围的资产是否全覆盖"，而不是"技术是否统一"，因此资产盘点的优先级高于技术选型。

8.1 整改项一：双因子只覆盖部分终端

问题描述：只给服务器装了Agent，办公PC没装；或者只装了Windows，国产操作系统没装。测评师抽样时抽到没装的机器，直接判不符合。

落地路径：先在资产台账里明确"纳入等级保护对象的终端范围"，再按范围做全覆盖部署。选型时要确认Agent对Windows 7/10/11、Windows Server、CentOS、Ubuntu、麒麟V10、统信UOS的支持矩阵，尤其是国产操作系统要提前做小批量兼容性验证（登录界面钩子、PAM模块在国产发行版上的版本差异较大）。

8.2 整改项二：离线环境用不了，被临时下策略绕过

问题描述：工控终端、外场设备、车载设备处于离线或弱网环境，认证服务连不上，运维人员为了干活直接把双因素策略关掉，留下一个永久后门。

落地路径：选用支持单机离线模式的方案——本地保存策略与用户凭据的加密副本，认证在终端本地完成，联网后再异步上报审计日志。同时配置离线应急口令：管理员在平台侧生成一次性应急码（带有效期与使用次数限制），用于Key丢失或硬件故障时的紧急登录，应急码的使用要单独审计。轨交外场、军用指挥车这类场景，必须把离线能力作为选型的硬指标。

8.3 整改项三：共享账号未收敛

问题描述：班组共用一个操作系统账号，即便加了双因素，一张Key还是被多个人轮流用，"身份标识唯一性"这一条依然不成立。

落地路径：两条腿走路。一是一人一Key，把Key和人绑定（发放登记表签字确认），并通过"拔Key自动锁屏"强制形成使用习惯——人离开工位拔Key，屏幕即锁，别人拿不到已登录的会话。二是对确需共用的特权账号，接入共享账号治理机制（凭据托管+代填+审计），把"谁在什么时候用了哪个账号"记录清楚。

8.4 整改项四：认证通道未加密

问题描述：Agent与服务端之间是明文HTTP，或者用了TLS但仍是国际算法套件、证书自签。

落地路径：认证通道改为国密套件保护，鉴别报文用SM4加密、SM3-HMAC做完整性校验，会话密钥协商走SM2。若环境里已有国密网关或国密SSL模块，优先复用基础设施，避免在Agent侧重复实现密码逻辑。

8.5 整改项五：密码产品资质缺失或型号不符

问题描述：采购的USBKey没有商用密码产品认证证书，或者证书上的型号与实际采购型号不一致。

落地路径：采购阶段就把"提供《商用密码产品认证证书》且型号一致"写进招标文件与合同，到货后逐批核对型号与证书编号，并留存核对表作为测评证据。

8.6 整改项六：审计日志不完整或未保护

问题描述：只有认证成功日志，没有失败日志；日志留存不足6个月；日志文件可被本地管理员直接篡改。

落地路径：认证成功、失败、锁屏、解锁、应急码使用、Key插拔等事件全部记录，日志实时上报到中心平台，本地只保留短期缓存；中心侧日志做完整性保护（链式哈希或签名），留存周期按等保要求（不少于6个月）。等保与密评都要求"审计记录应受到保护，防止删除、修改或覆盖"，这一条通常在日志集中后才能真正满足。

8.7 落地路径：五步走

第1步 定范围 ──> 明确纳入测评的终端/服务器清单与操作系统矩阵
                 (含国产OS，提前做兼容性验证)
       │
       ▼
第2步 选密码产品 ──> 选具备商用密码产品认证资质的国密USBKey
                     核对型号、算法列表(SM1/SM2/SM3/SM4)
       │
       ▼
第3步 小批量试点 ──> 选10~20台覆盖各操作系统版本
                     验证: 登录流程/离线模式/拔Key锁屏/应急码
       │
       ▼
第4步 全量推广 ──> 按部门分批; 同步做Key发放登记与用户培训
                     保留逃生通道(应急码+管理员解锁)
       │
       ▼
第5步 证据固化 ──> 录制演示视频/抓包留证/导出日志样本
                     整理方案+实施记录+资质, 三者对齐

九、不同认证因子的合规对照

为了便于选型，把常见第二因子放在"等保2.0"和"密评"两条标尺下横向对比：

第二因子形态	是否构成双因素	是否基于密码技术	等保2.0三级	密评身份鉴别	典型适用
短信验证码	是（你拥有的手机）	否	可通过（有SIM劫持争议）	不符合	低频互联网业务
邮箱验证码	是（弱）	否	一般不推荐	不符合	不推荐
TOTP动态口令（软件令牌）	是	是（HMAC-SM3/SHA）	可通过	取决于种子密钥是否存于合规载体	办公系统、堡垒机
OTP硬件令牌	是	是	可通过	可通过（需产品资质，种子不可导出）	金融、无智能手机场景
指纹/掌纹生物识别	是（你本身的）	否（生物特征本身非密码技术）	可通过	单独使用不符合，需与密码技术组合	车间、产线（便捷性优先）
国密USBKey（SM2签名）	是	是（合规密码产品内运算）	可通过	可通过	政务、能源、交通、工控
智能密码钥匙证书认证	是	是	可通过	可通过，并可支撑不可否认性	高安全要求场景

这张表里最关键的一行差异：生物识别解决的是"便捷性"和"不可转借"，但并不天然构成密码技术。指纹、掌纹本身是生物特征的比对，属于模式识别而非密码运算。所以在密评口径下，单纯"口令+指纹"通常仍需在链路的某一环引入合规密码技术——例如把生物特征模板的存储和比对结果用SM4加密保护、把认证结果的确认报文用SM2签名。反过来，USBKey提供的是合规密码技术底座，两者并非互斥，而是可以根据场景叠加。

以安当SLA为例，它的四个因子（国密USBKey、OTP动态口令、指纹、掌纹）正是按"合规强度"和"操作便捷"两个维度组合设计的：车间产线戴手套作业的场景优先指纹或掌纹（实测识别成功率约99.7%、响应小于0.3秒），外场离线与高合规场景优先国密USBKey，两种模式可以共存于同一套策略体系中。

十、操作系统登录双因素的实施配置要点

这一节给一些可落地的配置建议，不针对具体产品版本，讲通用原则。

1. 认证链路的接入方式。 Windows侧通常通过凭据提供程序（Credential Provider）或登录过滤器接入，Linux/国产OS侧通过PAM模块接入。选型时要确认厂商是否提供了对应发行版的PAM模块，以及是否支持在登录前阶段（pre-auth）完成第二因子校验——有些方案是"先放行登录再弹窗二次校验"，这种实现在测评现场会被质疑，因为操作系统会话已经建立。

2. 策略的分层下发。 建议按"组织—部门—终端组"三级下发策略：不同部门可以有不同的因子组合（财务强制USBKey，产线允许指纹），同一个终端组可以有不同的锁屏超时与失败锁定阈值。策略下发要有版本号，便于回溯"某台机器在测评当天生效的是哪版策略"。

3. 拔Key即锁屏。 这是一个性价比极高的配置项，同时解决三件事：防止人离开后会话被冒用、强制形成"Key随人走"的使用习惯、为"一人一Key"提供物理约束。实现上依赖USB设备插拔事件监听，要在锁屏时同时触发会话锁定而非仅锁屏界面。

4. 离线应急码的设计。 应急码必须满足四个约束：一次性、有有效期、有使用次数上限、可追溯到申请人。生成时需要管理员双人在场或走审批流，使用时单独触发告警并记入审计。切忌设置"通用应急码"或"长期有效的后门口令"，这类东西一旦泄露，整个双因素体系就形同虚设。

5. 与上层身份平台的联动。 单机部署能快速解决合规问题，但长期看应当能平滑扩展到联网模式：终端侧的认证事件上报到中心平台，与统一身份认证平台的账号体系打通，实现"一次发放、全局生效、集中审计"。选型时建议优先选择支持"单机起步、联网扩展"演进路径的方案，避免二次采购。

6. 远程管理通道的处理。 等保条款特别点名"当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听"。涉及服务器远程运维的场景，要确保运维通道（无论是堡垒机跳转还是远程桌面）的前置认证也纳入双因素，且通道本身是加密的。这里有一个常见疏漏：只加固了本地登录，运维人员实际是通过远程接入通道登录的，双因素被完全绕过。

十一、检查清单（测评前自查用）

把前面讲的内容压缩成一张可直接打印的自查表，逐项打勾：

身份鉴别

• 所有纳入范围的终端/服务器均已安装认证模块，无遗漏抽样风险
• 登录环节实测需要两个因子，缺一不可放行
• 第二因子基于合规密码技术实现，且密码产品具备商用密码产品认证证书
• 密码产品证书型号与实际采购型号一致，算法列表覆盖所声称的算法
• 账号与人员一一对应，无班组共用账号（或共用账号已纳入托管审计）
• 口令复杂度策略已启用，且有定期更换记录
• 登录失败锁定、会话超时、连接超时退出已配置并实测有效
• 拔Key自动锁屏已启用并实测
• 私钥不可导出已实证（现场演示导出失败）
• PIN错误锁定机制已实测，锁定后需管理员或PUK解锁

传输与存储

• 认证通道已加密，抓包无法获取明文鉴别信息
• 完整性校验已启用（SM3-HMAC或等效机制）
• 挑战值由服务端随机生成且一次性使用，重放攻击已验证无效
• 本地策略文件与凭据保险箱加密存储
• 口令加盐迭代派生存储，未使用MD5/SHA1裸哈希

密钥管理

• 密钥在合规密码产品内生成
• 密钥发放、回收、销毁有完整登记记录，有领用人签字
• 密钥备份/补发机制有制度与实施记录

审计

• 成功、失败、锁屏、应急码使用等事件全部记录
• 日志实时上报中心平台，本地不再是可篡改的唯一副本
• 日志留存周期满足要求（不少于6个月）
• 日志本身有完整性保护

管理与应急

• 密码应用方案已编制并通过评审，评审意见留存
• 密钥生命周期管理制度已发布
• 应急处置预案覆盖Key丢失/损坏/PIN锁死/服务端故障
• 至少完成一次应急演练并留存记录
• 密码管理人员岗位职责明确，签署保密协议

十二、FAQ

Q1：二级系统真的需要做密评吗？
从《密码法》的强制范围看，关键信息基础设施和等保三级及以上系统是明确应当开展密评的。但二级系统在两个情况下常被要求做：一是行业主管单位有专门要求（政务、金融、能源、交通、医疗较常见）；二是系统处理重要数据或大量个人信息，监管会参照密码应用基本要求进行核查。建议提前向属地公安机关和行业主管单位确认口径，不要等到整改通知下来才准备。

Q2：指纹登录算不算密码技术？
生物特征识别本身不属于密码技术，它解决的是"人本身"这一因子。密评口径下，生物识别可以作为多因子之一，但整条认证链路仍需在某一环引入合规密码技术（如模板加密存储、认证结果签名、会话密钥用SM2协商）。所以"口令+指纹"在等保上通常可通过，在密评上需要与密码技术组合使用。

Q3：已经用了动态口令（OTP），还需要换成国密USBKey吗？
取决于OTP的种子密钥存放位置。如果是手机App软令牌，种子存在手机里、运算在手机里，密评时会被追问种子密钥的保护方式；如果是具备资质的硬件令牌、种子在硬件内且不可导出，通常可以认定。对合规压力较大的行业（政务、能源、交通），国密USBKey因为具备完整的密码产品资质和SM2签名能力，是最稳妥的选择，同时还能支撑三级系统的不可否认性要求。

Q4：国密USBKey成本高不高，员工接受度如何？
成本上，硬件Key的单价确实高于软令牌，但摊到三到五年的证书有效期和合规收益上，通常是可以接受的。接受度方面，关键是配套机制：拔Key锁屏要配置好（否则员工会觉得"插着麻烦"），应急码流程要简单（否则Key丢了就完全无法工作），培训要覆盖"Key不能借人、不能和工牌挂一起"这类实操细节。行业内有统计认为双因素可降低账户被盗风险约99.2%，这类数据在与业务部门沟通时很有说服力。

Q5：离线环境的双因素怎么过测评？
关键是证明离线状态下第二因子依然生效。现场演示时，断开网络，插入Key、输入PIN，认证应当正常通过；同时要演示网恢复后审计日志能补传。还要注意，离线模式下本地保存的策略与凭据必须是加密的，且不能因为断网就降级为单因子——这一点是测评师重点核查项。

Q6：操作系统登录加了双因素，会影响远程运维吗？
取决于远程接入方式与本地认证模块的耦合关系。如果运维是通过堡垒机跳转，那么堡垒机侧也需要接入第二因子；如果是直接远程桌面到服务器，本地认证模块会拦截该登录路径。规划时要先梳理"这台机器有几种登录入口"（本地控制台、远程桌面、SSH、带外管理口、单用户模式），确保每种入口都覆盖了第二因子，否则会出现"绕过去"的口子。

Q7：SM2、SM3、SM4是不是必须三个都用？
身份鉴别环节，SM2（签名/验签）是核心，SM3作为SM2签名的摘要算法是天然伴随的。SM4主要用于传输与存储环节的机密性保护，如果身份鉴别链路本身已经由国密传输套件保护（其中包含对称加密），那么SM4是通过套件间接使用的。测评时不必机械追求"三个算法都自己调一遍"，但要在方案里讲清每个算法在哪个环节起作用。

Q8：怎么证明私钥确实不可导出？
实证方法有两种：一是用厂商提供的管理工具尝试执行导出操作，演示其被拒绝；二是引用密码产品的检测报告，报告中对密钥保护机制有明确结论。此外，用标准检测工具验证"同一挑战值在两张不同Key上产生的签名不同"也是侧证。测评现场建议准备录屏，避免临时操作失误。

方案参考

安当SLA是上海安当技术面向操作系统登录环节的双因素认证产品，可作为等保2.0与密评场景下身份鉴别条款的参考实现方式：

• 四因子组合：国密USBKey（SM2签名，私钥不出硬件）、OTP动态口令、指纹识别、掌纹识别，可按部门与场景配置不同因子策略，并与安当ASP统一身份认证平台对接。
• 三种部署形态：单机离线模式（适合轨交外场、工控终端、车载设备等弱网与断网环境）、联网模式（策略集中下发、审计集中上报）、以及平台化扩展，支持从单机起步平滑演进到统一身份体系。
• 操作系统覆盖：Windows 7/10/11与Windows Server、CentOS、Ubuntu、麒麟V10、统信UOS，覆盖主流与国产化环境。
• 合规相关能力：基于国密算法的挑战-响应认证；拔Key自动锁屏；离线应急口令（带有效期与使用次数限制）；全链路审计日志上报。
• 典型场景：车间产线的指纹与掌纹登录（戴手套可用，实测识别成功率约99.7%、响应小于0.3秒，已用于制造企业的供应链安全审核场景）；轨交外场的离线USBKey认证；高安全要求场景下的一人一钥。

如需进一步评估，建议先按第十一节的检查清单完成一轮自查，明确当前在"身份鉴别、传输保护、密钥管理、审计"四个层面的缺口，再结合第七节的证据材料清单倒排准备周期。