一、为什么身份鉴别总是等保测评里最先被扣分的地方做过等保测评的团队基本都有一个共识安全物理环境、安全通信网络几项相对好过真正卡脖子的是安全计算环境里的身份鉴别。原因不在于技术难度而在于它牵扯的面太广——它不是某一台设备上的某个开关而是横跨服务器、网络设备、堡垒机、业务系统、数据库的一整片配置状态。更麻烦的是很多单位的身份鉴别是碎片化的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 整改证据清单测评当天要能立刻拿出来的材料建议提前按下面这份清单准备成册策略配置截图口令复杂度策略、最长使用期限、锁定阈值与时长、会话空闲超时每个纳管系统或统一平台各一份账号清单导出包含账号名、所属人员、创建时间、上次登录时间、上次修改口令时间、状态启用/禁用、双因素绑定状态双因素覆盖率统计表应纳管账号数、已启用数、覆盖率、未启用清单及豁免审批认证日志样例成功登录、失败登录、账号锁定、管理员解锁各取若干条字段包含时间、账号、源地址、目标系统、结果传输加密证明管理通道的协议与加密套件配置截图、明文协议禁用的配置记录口令存储说明哈希算法、盐长度、迭代次数的说明文档或厂商盖章材料制度文件账号管理办法、口令管理规定、特权账号审批流程、双因素豁免审批单自查报告差距分析表、整改计划、整改完成确认单。证据准备的诀窍是让测评老师自己能查到。把所有材料按条款编号归档标注对应的条款项比现场翻配置要高效得多也能明显改善测评体验。八、常见问题 FAQQ1短信验证码到底算不算双因素算两种因素里的第二种你拥有的但不一定满足三级其中一种鉴别技术至少应使用密码技术的要求因为它不基于密码技术实现且存在号码转移与短信拦截风险。建议把短信作为兜底或低风险场景使用主因子组合优先选基于国密算法的动态口令或硬件密钥。Q2服务账号没法输动态口令怎么办不能因为没法交互就不做。可行方案有三种改用客户端证书双向认证天然基于密码技术、改用设备指纹加源地址白名单并大幅收紧权限、或者由凭据管理系统托管并按事件自动轮换超长随机口令。无论哪种都要配合高频审计并列入豁免清单审批。Q3口令定期更换到底是 90 天还是 180 天条款只要求定期更换没有硬性天数。测评时常见被接受的是 90 天180 天也见过通过但风险更高。更重要的是确实在换——账号清单里的上次修改时间是最直观的证据。如果启用了强双因素且有异常登录检测可以在制度里论证放宽周期但需要留下风险管理决策记录。Q4已经是三级系统但业务系统太老改不动怎么过用认证网关前置代理或者表单代填。原理是在老系统前面加一层统一认证入口用户先过网关的强认证再由网关以受控方式完成到老系统的登录老系统本身零改造。这是等保整改里最常用也最务实的路径。Q5指纹和人脸能作为单独的第二因子吗可以但要注意三点必须做活体检测防照片与模具攻击生物特征模板要安全存储终端安全区域或加密存储生物特征不可更换一旦泄露无法补救所以不要作为唯一因子也不要替代口令以外的所有因子。Q6二级系统要不要上双因素条款不强制但从投入产出比看如果系统对外暴露或承载重要数据建议提前上。身份认证改造的成本主要在接入这个动作一次性做到位比日后追加更省钱。Q7AD 域已经很完善了还需要统一认证平台吗域控能覆盖 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 的适配可同步支撑密码应用安全性评估与信创改造要求。需要提醒的是平台只是工具条款能否通过取决于覆盖率与证据链。建议按本文第四节的映射表做一次差距分析用第七节的证据清单提前归档材料再按第五节的五阶段路线图分批推进先补齐零成本项再集中攻克双因素纳管这一核心增量。