等保三级测评里身份鉴别永远是“第一个被翻牌子”的项目。无论是应用服务器、中间件还是业务系统测评师拿过检查表第一项就是看你身份认证做得到不到位。我刚入行那年接的某信息系统整改项目就栽在“身份鉴别”这个看似简单的环节上——默认口令、明文传输、无锁定策略三个典型问题一次全占整改意见书下来脸都绿了。那之后我陆续参与过几个等保三级改造项目改的对象既有Tomcat中间件也有Java业务系统还有政务类门户后台。身份鉴别这块的门道绝对不止“改个强密码”那么浅。这篇就把应用服务器身份鉴别整改从头到尾捋一遍从测评标准解读、差距分析、具体配置到现场答疑和常见翻车点一次讲透。1. 等保三级身份鉴别到底考什么四个测评点的真实含义先看国标GB/T 22239-2019里安全计算环境中对应用服务器“身份鉴别”给出的控制项拆开看其实就四句话对登录用户进行身份标识和身份鉴别标识唯一鉴别信息有复杂度要求并定期更换有登录失败处理功能能结束会话、限制非法登录次数、超时自动退出远程管理时鉴别信息在传输过程中不能被窃听采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术且其中一种是密码技术实现的。这四条看着不长但每一句背后都有测评动作不是写进制度就完事的。1.1 标识与鉴别唯一性背后是账号管理审计能力“身份标识具有唯一性”这句话很多整改人员扫一眼就跳过了实际上这是第一个高频扣分点。测评师会通过核查用户列表、用户属性配置来确认同一个应用服务器上是不是存在相同用户名、是否是多人共用一个管理账号、是否存在测试账号未删除等。我给你举个例子。某系统Tomcat默认安装后conf/tomcat-users.xml里有一堆注释示例有的运维图省事直接创建了tomcat/tomcat密码甚至role权限给了manager-gui。测评师抽查到这个账号问“谁在用、密码多久换一次、有没有审计记录”现场直接失分。身份标识的唯一性本质上是问责基础——账号一旦不唯一出安全问题你根本定位不到具体操作者。1.2 口令复杂度与定期更换这里的“定期更换”怎么落地口令复杂度相对直观长度、字符类型、弱口令禁止、和历史口令不重复。但“定期更换”这一条在不同测评机构手里的把握尺度不太一样有的认90天断开现有会话强制重设有的允许“密码到期强提醒首次登录必须改密”。重点是必须有技术机制在支撑光有制度写着“密码应每90天更换一次”测评师会追问“从哪能看出来执行了呢有登录时的到期提示吗有过期后的强制修改逻辑吗”绕开强制逻辑的做法也有比如把密码策略下沉到统一身份认证平台、LDAP或应用系统自身的用户模块中间件管理后台对接企业统一认证这样密码策略由上游统一下发运维本地不仅省事测评时还能拿出认证平台的策略配置作为证据逻辑链比一张模糊的截图强得多。1.3 登录失败处理不是简单的密码错误锁定登录失败处理包括登录失败后的锁定策略、会话超时退出、结束会话机制。测评师主要看三件事错误输错锁定几次、锁定多长时间、锁定后是否需要管理员介入解锁。很多系统只做了“输错5次锁10分钟”没有会话超时没有主动结束会话这样测评只能算部分满足。会话超时这块特别容易被忽略。业务系统页面上明明有超时配置但中间件管理控制台没有或者应用服务器层面的会话超时配了但前端没有自动跳转。整改时建议统一考虑管理控制台空闲超时比如10分钟自动退出、业务系统会话超时一般15到30分钟、以及前端的超时提示和跳转三层都要覆盖测评时链路才是完整的。1.4 远程管理防窃听与双因素认证容易被忽视的加分项/否决项远程管理时鉴别信息防窃听说人话就是远程登录管理后台时不能用明文HTTP。至少要做Web管理控制台启用HTTPSSSH等远程登录方式禁用明文口令改为密钥或加密通道如果中间件支持加密配置文件比如Tomcat的keystore密码保护也要把密码从明文配置里挪走。双因素认证是当前测评里越来越“硬”的要求。条款要求“两种或两种以上组合的鉴别技术且其中一种至少使用密码技术来实现”也就是说口令动态令牌OTP、口令数字证书、口令短信验证码都可以但如果只是口令密保问题前者不是密码技术这个是判不满足的需要特别注意。2. 整改前必做现状盘点与差距分析别急着动手改配置。等保整改最忌讳“拍脑袋改配置”——改了A项带崩B项改完说不清楚为什么这么改。正确顺序是先盘点、再对照、后整改、补证据。2.1 摸清应用服务器资产清单把网络里所有承载业务的应用服务器捞出来不光指中间件还包括管理端口暴露情况、Web管理后台地址、业务系统登录入口。我习惯用一张资产表记系统名称、中间件类型及版本、管理后台URL、远程运维方式SSH/RDP/堡垒机、当前认证方式口令/证书/OTP、会话超时配置现状、是否有HTTPS。为什么版本和中间件类型要单独列因为不同中间件的整改手法差别很大。Tomcat改server.xml和web.xml就可以了WebLogic还涉及安全领域和审计域的配置Nginx只做反代的话身份鉴别全在业务层。版本影响更直接Tomcat 7和Tomcat 9的连接器配置语法、SSL实现方式都不一样照着老教程抄很可能改出一个启动失败的节点。2.2 逐条对照差距表把四个测评点展开成一张整改差距表每一行控制项、现状描述、差距说明、整改措施、责任方。别嫌麻烦这张表后面就是你的整改计划、验收清单也是测评时给专家看的“管理证明”。我一直觉得等保整改里最值钱的就是这张差距表的颗粒度——写到“建议为Tomcat配置HTTPS”这种程度只能算初稿真正能指导施工的写法是“在Tomcat 9.0.x上为8005和8443端口分别配置TLS1.2以上的连接器并禁用3DES等弱加密套件”。2.3 测评证据链设计从配置截图到制度表单等保测评三要素访谈、配置核查、测试验证。身份鉴别项目的证据链至少要有用户列表截图证明标识唯一、无共享账号、默认账号已禁用密码策略配置复杂度、更换周期、历史口令登录失败锁定策略配置截图和现场演示会话超时配置截图含应用和中间件两层HTTPS证书页面截图和TLS协议扫描结果双因素认证的后台配置、用户绑定界面截图配套管理制度账号管理制度、密码策略、安全责任问责制度这套证据链最好在整改时就按“测评师视角”整理成册而不是最后两天翻系统现找。我自己有个习惯每一项整改落地后立刻截图存档页面地址、操作人、时间都写上后面验收时就能少折腾一轮。3. 应用服务器身份鉴别整改实操以Tomcat为例实操部分我用最常见的Tomcat应用服务器来拆。业务系统是自研的场景账号、密码、锁定、超时逻辑都在应用里思路同源把关键配置换成对应的代码实现就行。3.1 身份标识唯一性整改账号清理与矩阵建模第一步清账号。取消所有共享管理账号逐个应用系统确认最小授权账号列表。具体到Tomcat就是打开conf/tomcat-users.xml删掉不需要的user对保留的账号逐条确认role权限role rolenamemanager-gui/ role rolenameadmin-gui/ user usernameops_wang password加密后的口令 rolesmanager-gui/注意这里的password字段不要直接写明文Tomcat支持通过digest属性用MD5或SHA-256存储口令摘要user usernameops_wang password8c6f7...SHA-256摘要 rolesmanager-gui/对应的server.xml里要配置CredentialHandlerCredentialHandler classNameorg.apache.catalina.realm.MessageDigestCredentialHandler algorithmSHA-256/第二步建账号矩阵。每个账号对应唯一自然人标注岗位、权限范围和启用状态。这个矩阵既是整改成果也会成为“账号唯一性”的纸面证据。别小看这一步很多项目整改后依然有“幽灵账号”测评师一抽查Tomcat用户列表发现人都离职了账号还在前面做的全白费。3.2 口令复杂度与定期更换三层联动方案Tomcat默认不做口令复杂度校验这是个天然短板。三层联动是我验证过比较稳的做法第一层中间件管理后台信任域对接统一认证比如通过JAAS Realm接入内部LDAP让密码策略由LDAP统一强制第二层如果没有LDAP环境就在应用层自己实现密码强度校验至少要满足长度不低于8位、包含大小写字母数字特殊字符三类以上、禁止包含用户名或连续数字、新口令不与历史5次重复第三层定期更换机制通过“密码到期倒计时提醒到期强制改密”实现。给一个应用层口令校验的正则参考你在自己系统里可以按下图强度实现// 至少8位包含大写、小写、数字、特殊字符中三类 String pattern ^(?.*[a-z])(?.*[A-Z])(?.*\\d)(?.*[^a-zA-Z0-9]).{8,}$;SysAdmin再省事也要保留“90天强制更换”这个底线。如果实在不想动业务代码用统一身份认证网关把登录入口收口密码策略统一在网关上配身份鉴别这一项的业务层整改能省掉一大半工作量。3.3 登录失败锁定与会话超时关键配置详解登录失败锁定在Tomcat上最干净的做法是用LockoutRealm和已有的UserRealm或DataSourceRealm配合Realm classNameorg.apache.catalina.realm.LockOutRealm lockOutTime600000 failureCount5 Realm classNameorg.apache.catalina.realm.DataSourceRealm dataSourceNamejdbc/users userTablesys_user userNameCollogin_name userCredColpassword userRoleTablesys_user_role roleNameColrole_name/ /Realm参数含义failureCount是5次错误后锁定lockOutTime是锁定时间单位毫秒600000即10分钟。这个配置的作用范围是Tomcat自身的Realm认证链路比如管理控制台登录、BASIC认证下的资源配置访问。业务系统自己实现的登录锁定策略要落在代码逻辑里。我建议用Redis做计数防横向绕过——按用户名计数、按IP计数两个维度同时做避免攻击者只换账号不换IP持续爆破或者只换IP不换账号绕过限速。// 伪代码Redis原子递增5次失败锁定10分钟 if (redis.incr(login:fail: username) 5) { redis.expire(login:lock: username, 600); throw new LoginLockedException(账号已锁定请10分钟后重试); }会话超时配置在Tomcat里分两层。管理后台的session超时在conf/web.xml的session-config段session-config session-timeout10/session-timeout cookie-config http-onlytrue/http-only securetrue/secure /cookie-config /session-configsession-timeout单位是分钟10分钟是管理后台我比较推荐的上限。cookie-config里的HttpOnly和Secure两个属性一个防脚本读取会话ID、一个保证Cookie只在HTTPS下传输都是顺手就位的小加固测评时也能体现细节。业务系统层的会话超时一般通过应用框架配置比如Spring Session的maxInactiveIntervalInSeconds30分钟以内比较稳妥。还要注意超时不只是session失效前端要要有明确提示并跳回登录页“无感知超时”在测评师那里会认为配置未生效。3.4 远程管理加密改造Tomcat启用HTTPS完整步骤Tomcat启用HTTPS如果线上已有数字证书直接用Java的keystore即可。这里给一套基于OpenSSL自签证书也能跑通的步骤适合内网测评环境先验证# 1. 生成CA私钥和自签证书生产环境请使用合规CA签发的证书 openssl req -x509 -newkey rsa:2048 -sha256 -nodes \ -keyout server.key -out server.crt -days 365 # 2. 导入到Java keystorePKCS12格式 openssl pkcs12 -export -in server.crt -inkey server.key \ -out server.p12 -name tomcat # 3. 导入本地keystore keytool -importkeystore -srckeystore server.p12 \ -srcstoretype PKCS12 -destkeystore tomcat.jks \ -deststoretype JKS然后把生成的tomcat.jks放到Tomcat的conf目录修改server.xml在默认HTTP连接器后面新增HTTPS连接器Connector port8443 protocolorg.apache.coyote.http11.Http11NioProtocol maxThreads200 SSLEnabledtrue schemehttps securetrue SSLHostConfig Certificate certificateKeystoreFileconf/tomcat.jks certificateKeystorePassword你的存储口令 certificateKeystoreTypeJKS typeRSA/ /SSLHostConfig /Connector关键点原来的HTTP 8080端口管理后台就不要继续对外开放了。可以利用防火墙策略只允许内网特定网段访问8080或者直接将Connector的address绑定内网IP不绑全网段Connector port8080 protocolHTTP/1.1 address192.168.10.10 .../还有一层容易被忽略Tomcat默认的8005关闭端口是明文口令远程可以发送SHUTDOWN指令关停服务。整改时建议把8005端口的关闭指令置空或绑定内网地址实测下来能挡掉很多内网滥用Server port8005 shutdownSHUTDOWN_TO_BE_CHANGED端口能被外部访问到意味着Tomcat的远程管理场景HTTPS不能只配8443就算完。你要确认测评师能从外部访问到的路径里不存在明文HTTP管理入口尤其是8080带着manager路径暴露的情况。3.5 双因素认证接入从OTP到数字证书的选型双因素认证是身份鉴别这个控制域的“加分重头”。当前实际项目里最常见和成本最低的是TOTP动态口令接入也就是类似一次性令牌客户端如Google Authenticator、FreeOTP、Authenticator Pro等生成6位动态码。TOTP核心算法是RFC 6238简单说就是“时间窗口共享密钥HOTP计算”。Java后端可用如下方式验证动态口令。// 引入你项目里已有的基于RFC 6238的TOTP实现 long currentCode totp.getCode(secretKey, Instant.now()); if (!currentCode.equals(userInputCode)) { throw new AuthenticationException(动态口令校验失败); }接入流程大致三步用户绑定时生成一个base32编码的secret以二维码形式展示给用户用户添加到动态口令客户端服务端保存这个secret与用户账号绑定登录时第一步校验静态口令第二步校验当前动态口令验证后还需要做“防重放”处理——记录当前时间窗口已使用的code同一个动态码一分钟内不能重复使用。如果预算允许更稳妥的是数字证书模式应用服务器配置双向TLS客户端证书由内部CA签发登录时完成证书口令双重校验。这种方式对运营人员的要求高一些证书的签发、吊销、续期都要有人管但测评印象分很高尤其是涉及外部监管类信息系统。4. 现场测评与常见问题排查实录整改做完只是上半场现场测评应对不好照样拿不到满意结论。身份鉴别这个域测评师常用的方法就三招查配置、发访谈、做验证。你要做的就是提前把“戏”排好。4.1 测评时必问的几个问题测评师走进来多半会直接问这几句别等临时组织语言现在就可以把“标准答案”备好“这个系统的管理员账号有哪些如何保证账号唯一” 回答要点展示账号矩阵表、管理员账号对应到唯一自然人、离职人员账号已冻结、有季度复核记录。切忌现场才去翻用户列表。“密码策略是怎么配的能演示一下口令修改界面吗” 现场演示时测评师很可能故意输一个弱口令比如“12345678”看系统是否拦截。应用层如果做了强度校验直接现场秀出来。“登录失败几次会锁定锁定多久” 测评师不一定只听回答有的会当场打错几次密码试给你看。如果策略配了但没生效这个翻车现场非常尴尬。所以整改后一定要自己先暴力尝试一遍确认锁定策略真能触发、锁定后有明确的提示文案。“远程管理用的什么协议抓包能看到密码吗” 这个问题背后是测评师会用抓包工具验证所以HTTPS必须真实可用证书过期这种低级错误绝不能有。4.2 常见扣分现场和对应整改第一类扣分现场中间件用户列表存在注释示例、模板账号未删干净。补救方案就是巡检一次性清理并把检查项固化到月度运维清单而不是测评前临时删几个用户。第二类扣分现场密码复杂度策略只在“注册”流程校验了而管理员重置密码的流程没有校验。整改时所有改密入口用户自助改密、管理员重置、首次登录强制改密必须复用同一套校验逻辑不能让管理后台成为弱口令后门。第三类扣分现场锁定策略只锁了业务系统的Web登录但中间件管理后台的认证还是只有单一口令既没有失败锁定也没有双因素。整改时最容易遗漏的是这条线因为管理员日常走堡垒机不会直接访问Tomcat控制台但测评师要求“所有登录入口”都要满足控制项。4.3 整改过程中的五个深坑从多次实战里总结几个容易踩坑的环节深坑一HTTPS证书链不完整。有的运维图省事只把服务器证书导入了keystore缺了中间证书链浏览器访问报错一大片然后连管理后台串都串不进去。自查办法是用openssl s_client看证书链是否完整别只看浏览器是否显示了小锁。深坑二会话超时配置时间写错单位。Tomcat的session-timeout单位是分钟但很多配置中心或代码框架里单位是秒混用之后要么形同虚设要么刚登录就被踢。整改完逐条目测一遍别只截图。深坑三LockOutRealm配置位置错误。LockOutRealm作为外层包裹内层Realm配置需要写在server.xml里的Engine或Host下如果写到Context下可能导致认证链路不生效登录失败锁定形同虚设。深坑四双因素密钥存储不当。TOTP的secret在数据库如果明文保存会成为一个新的安全弱点至少要做应用层加密存储。同时密钥的初始化接口必须有权限控制别让任何人都能扫码绑定。深坑五证据截图看得见策略配置但看不出“生效”。测评师最烦“空截图”。比如光截一个密码策略参数页没有对应的日志、没有测试记录、没有流程说明。所以每张截图最好附上对应的测试时间、测试账号、测试结果形成一个“策略配置→实际操作→记录日志”的完整闭环。4.4 证据准备清单配置截图、访谈记录、制度文件我整理了一份整改验收时随手用的证据准备清单供你照着勾选应用服务器中间件用户列表截图标注账号用途权限分配表或账号矩阵说明每个账号的具体角色和授权范围密码复杂度策略配置截图如果通过统一认证平台实现截图平台策略页口令定期更换机制截图包括到期提醒和强制改密逻辑登录失败锁定策略截图及锁定/解锁记录会话超时配置截图中间件和应用系统两层HTTPS访问管理后台的证书详情截图TLS协议检查结果可以用市场上常用的TLS扫描工具生成一份报告双因素认证的用户绑定流程截图和登录验证界面规章制度电子版账号管理制度、密码安全策略、安全责任书、账号复核记录把这些整理成一个“身份鉴别-整改证据”目录分门别类命名好文件测评专家要看哪块3分钟就能翻出来。5. 写在最后的实操心得等保三级改造的身份鉴别是我觉得整个安全计算环境里“性价比”最高的一个控制项整改量不算大条款边界清楚但只要认真做测评通过率提升非常明显。反过来它也是现场最容易出丑的一个环节——因为测评师总是从这一项开始提问你的第一印象就从这里建立。我自己的经验是先不要急着动中间件配置先把账号清单、责任人、远程管理入口摸清楚把“谁在用、从哪里登、登录后干什么”这三件事搞明白再做技术加固。很多项目的身份鉴别改不动其实不是技术问题而是账号管理先天混乱上线了这么多年根本不知道后台里都有谁。等保整改恰好是理清这笔账的最佳时机——技术配置的改动只是一天的事账号资产的梳理和纳管才是真正让测评师点头的东西。再分享一个小技巧整改完成之后用你平时最顺手的密码尝试工具对着所有登录入口跑一遍弱口令测试。不要只测业务系统首页中间件管理后台、API认证接口、运维跳板机的登录入口全部测一遍。这一步能提前暴露80%会被测评师当场“演示”出来的问题省得现场开盲盒。
