一、为什么"身份鉴别"总是等保测评里最先被扣分的地方
做过等保测评的团队基本都有一个共识：安全物理环境、安全通信网络几项相对好过，真正卡脖子的是安全计算环境里的身份鉴别。原因不在于技术难度，而在于它牵扯的面太广——它不是某一台设备上的某个开关，而是横跨服务器、网络设备、堡垒机、业务系统、数据库的一整片配置状态。
更麻烦的是，很多单位的身份鉴别是"碎片化"的：Windows 服务器靠域控组策略配口令策略，Linux 服务器各自配本地策略，网络设备配本地账号，业务系统用自己的账号表。结果就是有的地方配了、有的地方没配，有的地方配了但和制度文件里写的不一致。测评老师随机抽查几台，总能找到没配的那台。
不少负责人在百度搜索"等保2.0身份鉴别整改方案"时，真正想确认的其实是三件事：条款到底要求什么、我用什么技术手段去满足、测评当天我拿什么材料证明我满足了。本文就按这三件事来组织，把标准语言翻译成工程语言。
顺带说明一下标准依据：等保2.0的核心标准是 GB/T 22239《信息安全技术 网络安全等级保护基本要求》，身份鉴别属于"安全计算环境"这一大类下的控制点，二级与三级条款编号分别为 8.1.3.1 与 8.1.4.1。本文讨论的内容以三级为主，同时标出二级的差异。
二、条款逐条拆解：从标准语言到工程语言
三级"身份鉴别"控制点包含四项要求，我们逐条拆开。
2.1 应对登录的用户进行身份标识和鉴别，身份标识具有唯一性
这一条拆成两个动作：先标识、后鉴别，以及标识必须唯一。
"身份标识"是声明你是谁（输入账号），"身份鉴别"是证明你确实是这个人（输入口令、令牌、指纹）。工程上对应的要求是：任何访问入口都必须先过认证，不能存在"不登录就能看到数据"的旁路；不能存在匿名访问、空口令账号、默认账号；不能使用操作系统或应用系统内置的默认管理员账号而不做处理。
"唯一性"要求一个身份标识只能对应一个自然人，一个自然人原则上也只应有一个主身份标识。常见的违规形态包括：多人共用一个账号（共享账号）、同一人在不同系统用不同账号且无法关联、历史遗留的同名账号（比如两个"zhangwei"分属不同部门）。
落地措施：建立统一的人员主账号体系，账号命名规则全局唯一（建议用工号或与人力资源系统关联的唯一标识）；清理默认账号，管理员账号必须重命名且禁止日常使用；对确因业务原因保留的共享账号，必须做到"使用必留痕、凭据不落地、权限可回收"，通过凭据托管系统实现具体到人的操作审计。
2.2 身份鉴别信息具有复杂度要求并定期更换
这一条是最容易配、也最容易配错的一条。它要求口令满足复杂度策略，并且有强制更换周期。
复杂度怎么配才站得住：
| 策略项 | 建议值 | 说明 |
|---|---|---|
| 最小长度 | 10 位（高敏系统 12 位） | 8 位是底线，但已不足以对抗离线破解 |
| 字符类别 | 至少包含大写、小写、数字、特殊字符中的三类 | 四类全要求会催生"贴纸条"行为，需权衡 |
| 不得包含账号名 | 启用 | 防止"账号与口令相同"这类弱口令 |
| 不得与最近 N 次重复 | N = 5 | 防止轮换时来回改两个口令 |
| 弱口令字典检查 | 启用 | 拦截常见弱口令与行业特征口令 |
| 最短使用期限 | 1 天 | 防止连续修改 5 次绕回原口令 |
| 最长使用期限（定期更换） | 90 天 | 高敏系统建议 60 天 |
| 到期提醒 | 提前 14 天开始 | 减少到期后集中锁定带来的工单压力 |
定期更换的例外情况必须提前想清楚，否则测评时会被追问：
- 服务账号、应用间调用账号无法按人工周期交互改密，应改为由凭据管理系统自动轮换，轮换周期可短于 90 天（比如 30 天或按事件触发），并将自动轮换记录作为证据；
- 密钥、证书、令牌种子这类非口令型鉴别凭据，不适用"定期更换口令"的简单要求，应按密钥生命周期管理（生成、激活、更新、归档、销毁）；
- 启用双因素后，口令的更换周期可以适当放宽，但这属于风险管理决策，需要在制度文件里写明白，不能默认默认。
这里有个很现实的经验：单纯提高复杂度和缩短更换周期，会直接推高弱口令被写在便签上的概率。所以复杂度策略一定要和双因素、凭据托管配套推行，而不是单兵突进。
2.3 应具有登录失败处理功能
条款原文要求"应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施"。这里其实包含三件事，我们拆成 2.3 和 2.4 两节讲。
登录失败处理的配置要点：
- 失败锁定阈值：连续失败 5 次锁定，是测评中最容易被接受的数值；设成 3 次会误伤正常用户，设成 20 次以上基本等于没设。
- 锁定时长：15 到 30 分钟自动解锁，或者必须由管理员解锁。高敏系统建议采用管理员解锁 + 身份核验。
- 计数窗口：失败计数应有时间窗口（比如 10 分钟内的累计失败），避免历史失败数长期累加导致账号莫名其妙被锁。
- 解锁审计：解锁动作必须记录操作人、时间、被解锁账号，并纳入日志归集。
- 防账号枚举：认证失败时的提示信息要统一（不要区分"用户不存在"和"口令错误"），否则等于给攻击者一份账号名单。
- 防口令喷洒：除了单账号锁定，还要对同一源地址在短时间内的跨账号失败做限速与告警。注意不要把源地址锁定做成全局封禁，否则会被用于制造拒绝服务；正确做法是单账号锁定为主，源地址侧做限速与告警。
- 日志留存：失败事件日志至少要包含时间、账号、源地址、目标系统、失败原因，留存时间满足等保审计要求（一般不少于 6 个月）。
2.4 结束会话与登录连接超时自动退出
- 空闲超时：会话空闲超过 10 到 15 分钟自动登出。生产网段内的运维会话、涉及敏感数据的业务系统建议取 10 分钟。
- 绝对超时：无论是否活跃，会话最长持续时间建议不超过 8 小时（与一个工作班次对齐）。
- 服务端会话销毁：用户点击登出或会话超时后，服务端必须立即销毁会话令牌，不能只做前端跳转。
- 并发与异地会话：高敏系统可配置单账号并发会话数限制与异地登录踢出策略。
- 令牌安全：会话令牌必须随机不可预测、有有效期、支持单点登出、绑定必要的客户端属性，并具备重放防护。
2.5 远程管理时防止鉴别信息在网络传输过程中被窃听
这条针对的是"远程管理"场景，也就是管理员不在机房、通过网络登录设备进行管理的情形。
技术要求：管理通道必须是加密通道，不能以明文方式传输口令。具体检查点包括：
- Web 管理后台必须使用加密传输协议，禁用明文传输协议与弱加密套件；
- 远程运维（远程接入、远程桌面、远程命令行）必须走加密隧道，且隧道启用强认证；
- 目录服务（LDAP）应启用加密通道版本，不要用明文端口同步口令；
- 网络设备远程管理优先使用 SSH 而非 Telnet，且认证走集中认证服务器，口令字段在传输过程中受保护；
- RADIUS 认证场景下，若内部采用口令明文承载的认证方式，必须通过隧道协议或在专用管理网内配合链路层加密来避免口令被窃听；更优的做法是采用基于证书的双向认证。
存储侧的保密性同样属于身份鉴别信息保护的范畴：口令不得以明文或可逆加密方式存储，应采用加盐的不可逆哈希，算法选择国密摘要算法或国际公认的抗破解算法，禁止使用已被攻破的摘要算法直接存储。这里要注意，很多自研业务系统仍然在用不安全的旧方式存口令，这是测评的高频扣分项。
2.6 应采用两种或两种以上组合的鉴别技术，且其中一种至少应使用密码技术
这是三级相对二级最关键的一条增量，也是最多单位栽跟头的一条。它有两层含义：
不少甲方在百度搜索"等保三级双因素认证要求"时，真正想确认的其实就一个问题：我上了短信验证码到底算不算过。而这个问题的答案，恰恰是这一条里最容易失分的地方。
第一层：组合。要在"你知道的（口令、PIN）"“你拥有的（动态口令令牌、USBKey、手机）”"你固有的（指纹、人脸、掌纹）"这三类里选至少两类组合，不能是同类的两个（比如两个口令不算双因素）。
第二层：密码技术。这是最容易踩的坑——条款要求组合中至少有一种鉴别技术是用密码技术实现的。短信验证码虽然属于"你拥有的"，但它不基于密码技术实现，且存在号码转移、短信拦截、伪基站等风险，在严格测评中往往不被认可为满足该条款的因子。稳妥的选型是：
- 基于密码技术的动态口令：以国密摘要算法为伪随机函数基础的动态口令，30 秒或 60 秒更新一次，密钥种子安全存储；
- 基于密码技术的硬件密钥：内置国密算法的安全芯片钥匙，通过挑战-响应或签名验签完成认证，私钥不可导出；
- 基于证书的设备认证：客户端证书配合私钥签名，天然基于密码技术，适合服务账号与设备认证场景。
生物特征（指纹、人脸）属于"你固有的"，可以作为第二因子，但要注意生物特征模板本身的安全存储与活体检测要求，且生物特征不可更换，不能作为唯一因子。
三、三级与二级的差异
一张表看清楚差别，避免"按二级配了却要过三级"或者"按三级配了但只是二级系统造成过度投入"。
| 要求项 | 二级 | 三级 | 差异影响 |
|---|---|---|---|
| 身份标识和鉴别、唯一性 | 要求 | 要求 | 无差异 |
| 复杂度要求并定期更换 | 要求 | 要求 | 无差异，但三级执行力度检查更严 |
| 登录失败处理、结束会话、超时退出 | 要求 | 要求 | 无差异 |
| 远程管理防窃听 | 要求 | 要求 | 无差异 |
| 两种或两种以上组合鉴别技术 | 不强制 | 强制 | 三级的核心增量 |
| 其中一种使用密码技术 | 不强制 | 强制 | 决定了因子选型，短信验证码可能不被认可 |
| 测评强度 | 抽查 | 抽查比例更高、覆盖更全 | 三级更强调覆盖率与证据链 |
实务上还有一个经验：即使被测系统定级为二级，如果它承载重要数据或对外暴露，提前按三级配置双因素通常比事后补改造更省钱。身份认证体系的改造成本主要集中在"把系统接进来"这个动作上，第一次接入和后来追加接入，工作量差不多。
四、条款到能力的映射表
把上面的条款落成一张能力映射表，方便做差距分析时逐项核对。
| 等保条款要点 | 技术措施 | 对应能力模块 | 测评证据 |
|---|---|---|---|
| 身份标识与鉴别 | 全接入点强制认证，无匿名旁路，默认账号清理 | 统一认证网关 SSO | 系统账号清单、匿名访问排查记录 |
| 标识唯一性 | 主账号与人力资源系统关联，命名全局唯一，共享账号纳入托管审计 | 身份治理、SYP 凭据托管 | 账号清单（含唯一标识字段）、共享账号治理说明 |
| 复杂度要求 | 长度、字符类别、历史、弱口令字典策略统一配置 | 统一认证口令策略中心 | 策略配置截图、弱口令扫描报告 |
| 定期更换 | 最长使用期限 90 天，到期提醒，服务账号自动轮换 | 口令策略中心、SMS 凭据管理 | 账号清单含"上次修改时间"、自动轮换日志 |
| 登录失败处理 | 失败 5 次锁定、锁定时长、计数窗口、防枚举、限速告警 | 统一认证风控与锁定策略 | 锁定策略截图、失败日志样例 |
| 结束会话与超时退出 | 空闲 10–15 分钟自动登出，服务端会话销毁 | 会话管理 | 超时配置截图、会话日志 |
| 传输防窃听 | 管理通道加密、远程运维加密隧道、目录服务加密、SSH 替代明文协议 | 加密通道、RADIUS 认证 | 通道配置截图、协议说明、禁用明文协议的配置 |
| 存储保密性 | 加盐不可逆哈希，禁用不安全算法 | 认证凭据存储机制 | 存储方式说明、厂商文档 |
| 双因素（含密码技术） | 口令 + 动态口令（国密摘要）或口令 + 硬件密钥（国密签名） | MFA、OTP、UKey | 双因素覆盖率统计、绑定明细、认证日志 |
五、落地步骤：分批纳管路线图
身份鉴别改造最忌讳"一次全铺"。建议按下面五个阶段推进，每个阶段都有可交付的产出物。
阶段零：资产与账号盘点（2–3 周）
产出《应纳管系统清单》和《账号现状台账》。清单字段至少包括：系统名称、责任部门、定级、认证方式现状、账号数量、是否暴露互联网、是否含共享账号、是否可改造、改造方式（标准协议/代填/无法改造）。
这一步最容易低估工作量。很多单位以为自己有 20 套系统，盘完发现连影子资产、测试环境、外包临时系统加起来有 60 多套。
阶段一：补齐"零成本"合规项（2–4 周）
优先做不需要采购、不需要改造就能见效的项目：
- 域控与服务器统一口令策略、锁定策略、超时策略；
- 清理默认账号、空口令账号、长期未登录账号；
- 管理员账号重命名，日常账号与特权账号分离；
- 远程管理通道强制加密，禁用明文协议；
- 开启认证日志集中归集。
这一阶段能把 2.1 到 2.5 的大部分条款补上，也是测评前最值得先做的事。
阶段二：双因素分批纳管（4–8 周）
按风险优先级排序，而不是按系统重要性排序：
| 批次 | 系统类型 | 排序理由 | 典型改造方式 |
|---|---|---|---|
| 第一批 | 互联网暴露系统、远程接入入口、邮件系统 | 暴露面最大，撞库与钓鱼高发 | 标准协议对接或认证网关代理 |
| 第二批 | 堡垒机、服务器本机、网络设备 | 权限最高，横向移动的跳板 | RADIUS 对接、操作系统登录代理 |
| 第三批 | 核心业务系统（ERP、财务、OA、人力） | 数据价值最高 | 单点登录协议对接或表单代填 |
| 第四批 | 一般办公与边缘系统 | 风险相对可控 | 网关代理或凭据托管 |
每批上线前先选 1 到 2 套试点，跑通登录、登出、超时、锁定、令牌丢失应急这五个场景，再批量推广。试点阶段一定要把"逃生通道"设计好：管理员应急码、令牌补发流程、离线应急口令，这三件事没准备好就全量推，很容易在第一天就被工单淹没。
阶段三：账号生命周期与共享账号治理（4–6 周）
把身份体系和人力资源系统打通，实现入职自动开通、调岗自动变更、离职自动回收。对确需保留的共享账号，用凭据托管系统集中管理，做到使用时按需获取、凭据不落地、操作全程留痕、可随时回收。
这一步解决的正是 2.1 里"唯一性"的历史欠账。
阶段四：审计与持续运营（长期）
认证事件统一上报到日志平台或安全运营平台，配置告警规则（异地登录、短时间大量失败、特权账号异常时段登录、双因素被绕过的应急码使用）。每季度复核一次账号台账与双因素覆盖率，每年配合等保复测做一次完整自查。
六、配置示例：一份可直接讨论的参数基线
下面给出一套适合三级系统的参数基线，实施时按本单位情况微调。
口令策略基线
最小长度 10 位（高敏系统 12 位） 字符类别 大写/小写/数字/特殊字符 至少三类 不得包含账号名 启用 历史不得重复 最近 5 次 弱口令字典检查 启用 最短使用期限 1 天 最长使用期限 90 天（高敏 60 天） 到期提醒 提前 14 天 口令存储 加盐不可逆哈希，国密摘要或国际公认抗破解算法登录失败与会话策略基线
连续失败锁定阈值 5 次 锁定时长 30 分钟自动解锁，或管理员核验后解锁 失败计数窗口 10 分钟 失败 10 次 触发安全告警并通知责任人 失败提示 统一提示，不区分账号是否存在 源地址限速 同地址 5 分钟内跨账号失败 20 次触发限速与告警 空闲超时 15 分钟（高敏系统 10 分钟） 会话绝对时长 8 小时 登出行为 服务端立即销毁会话令牌 并发会话限制 高敏系统限制单账号并发会话数双因素策略基线
主因子 口令（第一类：你知道的） 第二因子 动态口令（30 秒更新、6 位、国密摘要算法） 或 硬件密钥（国密签名，挑战-响应，私钥不可导出） 或 生物特征（指纹/人脸，需活体检测） 覆盖范围 全部管理员账号、全部远程接入账号、全部特权账号 豁免场景 服务账号改用客户端证书或设备指纹 + 收紧权限 + 审计 离线终端使用本地硬件密钥或离线动态口令 应急场景使用一次性应急码，使用即告警并需补审批豁免清单是测评必查项。任何不启用双因素的账号，都要在清单里写清楚：账号名、用途、不启用原因、补偿措施、审批人、有效期。没有清单的豁免，在测评时会被直接认定为"未覆盖"。
以安当ASP为例，上述条款对应的能力可以落在同一套平台里完成：SSO 模块解决统一认证收口与会话管理，MFA 与 OTP 模块提供基于国密摘要算法的第二因子，RADIUS 模块把网络设备与远程接入入口纳入统一策略，SLA 模块覆盖服务器本机登录，SYP 模块治理共享账号，口令策略与锁定策略在统一后台集中配置并对所有纳管系统生效。这样在测评时，策略只需出示一处配置，而不是挨个系统截图。
七、测评常见扣分点与整改证据
7.1 高频扣分项
很多单位在百度搜索"等保测评常见扣分点"时，真正想确认的是自己会不会踩进同一批坑。下面这份清单来自一线整改复盘，建议在测评前逐条自查一遍。
- 存在共享账号或默认账号：与"唯一性"直接冲突，是出现频率最高的扣分项；
- 口令策略不统一：域控配了，但 Linux 服务器、网络设备、业务系统没配，或者配的位数不足；
- 未启用登录失败锁定，或阈值设置形同虚设（比如设成 50 次）；
- 没有定期更换：账号清单里大量账号的"上次修改时间"是三年前；
- 远程管理走明文协议：还有设备开着明文远程管理方式；
- 只有单一口令，没有双因素（三级系统的硬性缺口）；
- 双因素用了短信验证码，被认定不满足"其中一种使用密码技术"；
- 双因素覆盖率不足：只覆盖了办公系统，堡垒机、服务器、网络设备没覆盖；
- 超时退出未配置或时间过长（配置成 480 分钟基本等于没配）；
- 查不到日志：无法提供登录失败记录，审计要求连带扣分；
- 业务系统自身账号体系不在任何集中策略覆盖范围内，且系统已无人维护无法改造。
第 11 项是最棘手的。技术上可以通过认证网关前置代理或者表单代填的方式，在不改造老系统的前提下把强认证套在外面，这比"等着系统厂商改造"现实得多。
7.2 整改证据清单
测评当天要能立刻拿出来的材料，建议提前按下面这份清单准备成册：
- 策略配置截图：口令复杂度策略、最长使用期限、锁定阈值与时长、会话空闲超时，每个纳管系统或统一平台各一份；
- 账号清单导出：包含账号名、所属人员、创建时间、上次登录时间、上次修改口令时间、状态（启用/禁用）、双因素绑定状态；
- 双因素覆盖率统计表：应纳管账号数、已启用数、覆盖率、未启用清单及豁免审批；
- 认证日志样例：成功登录、失败登录、账号锁定、管理员解锁各取若干条，字段包含时间、账号、源地址、目标系统、结果；
- 传输加密证明：管理通道的协议与加密套件配置截图、明文协议禁用的配置记录；
- 口令存储说明：哈希算法、盐长度、迭代次数的说明文档或厂商盖章材料；
- 制度文件：账号管理办法、口令管理规定、特权账号审批流程、双因素豁免审批单；
- 自查报告：差距分析表、整改计划、整改完成确认单。
证据准备的诀窍是"让测评老师自己能查到"。把所有材料按条款编号归档，标注对应的条款项，比现场翻配置要高效得多，也能明显改善测评体验。
八、常见问题 FAQ
Q1：短信验证码到底算不算双因素？
算"两种因素"里的第二种（你拥有的），但不一定满足三级"其中一种鉴别技术至少应使用密码技术"的要求，因为它不基于密码技术实现，且存在号码转移与短信拦截风险。建议把短信作为兜底或低风险场景使用，主因子组合优先选基于国密算法的动态口令或硬件密钥。
Q2：服务账号没法输动态口令，怎么办？
不能因为没法交互就不做。可行方案有三种：改用客户端证书双向认证（天然基于密码技术）、改用设备指纹加源地址白名单并大幅收紧权限、或者由凭据管理系统托管并按事件自动轮换超长随机口令。无论哪种，都要配合高频审计，并列入豁免清单审批。
Q3：口令定期更换到底是 90 天还是 180 天？
条款只要求"定期更换"，没有硬性天数。测评时常见被接受的是 90 天，180 天也见过通过但风险更高。更重要的是"确实在换"——账号清单里的上次修改时间是最直观的证据。如果启用了强双因素且有异常登录检测，可以在制度里论证放宽周期，但需要留下风险管理决策记录。
Q4：已经是三级系统，但业务系统太老改不动，怎么过？
用认证网关前置代理或者表单代填。原理是在老系统前面加一层统一认证入口，用户先过网关的强认证，再由网关以受控方式完成到老系统的登录，老系统本身零改造。这是等保整改里最常用也最务实的路径。
Q5：指纹和人脸能作为单独的第二因子吗？
可以，但要注意三点：必须做活体检测防照片与模具攻击；生物特征模板要安全存储（终端安全区域或加密存储）；生物特征不可更换，一旦泄露无法补救，所以不要作为唯一因子，也不要替代口令以外的所有因子。
Q6：二级系统要不要上双因素？
条款不强制，但从投入产出比看，如果系统对外暴露或承载重要数据，建议提前上。身份认证改造的成本主要在"接入"这个动作，一次性做到位比日后追加更省钱。
Q7：AD 域已经很完善了，还需要统一认证平台吗？
域控能覆盖 Windows 生态内的服务器与终端，但面对 Web 业务系统、国产操作系统、移动端、网络设备、国密算法要求时往往力不从心。常见做法是域控继续管终端与服务器，上层叠加统一认证平台作为身份中枢，纳管网域并把强认证能力延伸到域控覆盖不到的系统。
Q8：双因素上线后，令牌丢了会不会影响业务？
会，所以必须提前设计应急体系：一次性应急码（离线保存、使用即告警）、管理员代客重置流程（需身份核验与审批）、硬件令牌备用库存。这三件事没准备好就全量推广，第一天就会被工单淹没。
Q9：等保测评会现场测弱口令吗？
会。测评通常包含渗透测试环节，弱口令、账号枚举、口令喷洒基本都会尝试。所以复杂度策略不能只写在制度里，必须实际生效，并且提前自己做一次弱口令扫描。
Q10：整改周期一般要多久？
取决于系统数量与可改造程度。系统数量在 20 套以内、可改造性较好的单位，按本文五阶段推进，8 到 12 周可以完成主体整改；系统数量多、老系统占比高的单位，通常需要 3 到 6 个月，且建议分批验收而不是等全部完成。
九、容易忽略的几个细节
最后补充几个实战中反复踩到的细节，篇幅不大但影响结果。
一是"策略生效范围"和"策略配置"是两件事。很多人配完域控组策略就以为完事了，但目标服务器可能因为组织单元归属错误、组策略未刷新、本地策略覆盖等原因根本没生效。配置完一定要抽样验证：找一台服务器，故意连错五次口令，看是否真的锁定。
二是时钟同步。动态口令依赖时间同步，域内服务器时间偏差超过一个时间窗口就会导致认证失败。务必确认所有纳管系统与认证服务器都配置了统一的时间源，并把时间偏差纳入监控。
三是"管理员账号"要单独定义。很多单位把日常办公账号和系统管理员账号混在一起，管理员用办公账号登服务器，导致权限没法收敛。正确做法是分离：日常账号用于办公，特权账号仅用于管理操作，且特权账号的认证强度更高。
四是测评前做一次自查演练。按测评的抽查方式，自己随机抽 5 台服务器、3 套业务系统、2 台网络设备，逐项按条款检查一遍。这一步能发现 70% 以上的问题，比临时抱佛脚有效得多。
五是别忽略外包与临时人员。大量身份鉴别的漏洞出在这类账号上：项目结束没回收、多人共用一个临时账号、外包人员离职后账号仍在。账号台账要覆盖这部分，并且和合同周期挂钩自动触发回收。
方案参考
安当ASP是上海安当技术推出的企业级统一身份认证平台，可作为等保2.0身份鉴别条款整改的一体化参考方案。其与本文条款的对应关系如下：
- 统一收口与单点登录：支持 SAML 2.0、OAuth 2.0、OIDC 等标准协议，将分散在各业务系统的认证收口到统一入口，解决 2.1 的"是否存在未受保护访问入口"问题，并为会话超时与结束会话提供集中的会话管理。
- 多因素与动态口令：MFA 模块支持动态口令、硬件密钥、生物特征等多种第二因子组合，动态口令可基于国密摘要算法实现，直接对应 2.6 中"两种以上组合且含密码技术"的要求，避免短信验证码被判定不满足条款的风险。
- RADIUS 与远程接入：可作为 RADIUS 服务端纳管网络设备与远程接入入口的认证，配合加密隧道满足 2.5 的传输防窃听要求。
- SLA 操作系统登录：把服务器与终端本机登录纳入统一强认证，覆盖域控策略难以触达的国产操作系统场景。
- SYP 凭据托管：治理共享账号与特权账号，实现凭据不落地、使用必留痕、权限可回收，为 2.1 的"唯一性"提供补偿性证据。
- 口令策略与风控：复杂度、定期更换、失败锁定、超时退出等策略在统一后台集中配置并对所有纳管系统生效，测评时只需出示一处配置，避免逐系统截图的被动局面。
- 国密与信创：原生支持国密 SM2、SM3 算法，并完成麒麟、统信、鲲鹏、龙芯等国产操作系统与 CPU 的适配，可同步支撑密码应用安全性评估与信创改造要求。
需要提醒的是，平台只是工具，条款能否通过取决于覆盖率与证据链。建议按本文第四节的映射表做一次差距分析，用第七节的证据清单提前归档材料，再按第五节的五阶段路线图分批推进，先补齐零成本项，再集中攻克双因素纳管这一核心增量。
)
