企业官网建设流程全解析

前阵子去某单位做等保三级复测，刚好撞上他们应用服务器的整改收尾。运维负责人跟我聊起来还挺委屈：身份鉴别这一项，明明密码策略也调严了，该开的开关都开了，怎么测评师当场演示几下还是判了不符合？我在测评现场跟着看了一轮，问题其实不在你“改了没有”，而在你“改没改到位、策略有没有真正生效、有没有能证明它生效的痕迹”。如果你也在准备应用服务器的等保三级整改，我建议先把身份鉴别这个控制项搞透，它是所有安全控制里的头一道门，也是每次测评必查、翻车率最高的地方。这篇就从测评视角到操作落地，把四个测试子项逐一拆开讲。

1. 测评现场的真实检查逻辑：身份鉴别不是“配好了”就终结

很多项目组容易误解等保测评，觉得测评就是看配置截图，我把密码策略截图发给测评机构就行了。实际上，测评师对应用服务器身份鉴别项的检查是访谈、配置核查、验证测试三件事一起做的，三件事对不上，照样扣分。

1.1 测评师访谈环节问什么

访谈阶段，测评师一般会问三类问题：

• 服务器的管理员账号有哪些，分别归属谁使用，有没有共管账号？
• 密码策略是怎么定的，多长时间改一次，复杂度要求是什么？
• 账号锁定、登录超时、远程管理加密这些机制，配置在哪个层面，应用系统和操作系统是否都覆盖？

这些问题对应的就是等保2.0里身份鉴别控制项的那四个子要求，表面上是在了解情况，实际是在判断你单位的安全管理制度有没有下沉到技术实现层。比如你只能说“我们要求员工自己设密码”，但说不出系统侧的强制策略在哪里配置，测评师基本就知道这条是失分了。

1.2 配置核查和验证阶段最容易丢分的三个细节

配置核查阶段，测评师会登录服务器看实际配置。这一步有三个细节是项目组最容易丢分的：

第一个细节是“策略生效范围”问题。很多单位只在某台服务器的本地策略里改了密码复杂度，但服务器实际加入了域环境，域策略优先级更高，本地策略根本不生效。测评师打开命令行敲一句查询命令确认当前生效值，就会发现问题。

第二个细节是“配置项和测评项对不上号”。比如测评要求登录连接超时自动退出，你在应用系统的web.xml或者配置文件里配了会话超时，但操作系统本地桌面的会话超时没配，测评师认为这不算完整覆盖，因为本地登录同样属于登录方式。

第三个细节是“过往痕迹缺失”。测评师不光看当前配置，还会翻系统日志、查看关键配置文件的修改时间。像Linux下/etc/pam.d/system-auth这种认证相关文件，修改时间如果显示是测评前几小时才临时改的，测评师大概率会加大现场验证的力度，反复演示各种异常场景。

理解了这套检查逻辑，下面四个子项的整改就不会白费功夫。等保2.0关于应用服务器身份鉴别的测评项，核心是下面四句话，我按实际整改难度排个序，其实难度是递增的：口令复杂度与更换策略最基础，登录失败处理是中层，传输加密是运维改造重点，双因素认证是最大硬骨头。

2. 控制项a落地：唯一标识、口令复杂度与90天更换周期怎么配置

这条原文要求可以概括为：登录用户必须有唯一身份标识，鉴别信息要有复杂度要求并定期更换。测评师的检查点是“有没有”和“是不是强制生效”，不是“你们公司制度里写没写”。

2.1 Windows密码策略：对应关系与生效条件

如果应用服务器是Windows Server，典型配置路径是secpol.msc → 账户策略 → 密码策略。需要重点确认的项和测评要求的对应关系如下表：

我推荐稳态配置是8位以上、每90天更换、保留5个历史密码，这套组合在满足三级要求的同时，对业务影响相对可控。如果你一口咬定要上“12位+大写+小写+数字+特殊字符+30天更换”，运维团队大概率会造反，密码策略不是越严格越好，要在合规和可用性之间找平衡。

还有一个极易踩坑的点：密码最短使用期限如果设成0，用户可以在一天之内连续改5次密码把历史记录“洗掉”，下次直接改回原密码，强制密码历史就形同虚设。所以这里必须设成至少1天。测评师对这类组合漏洞非常敏感，现场一旦演示“改回旧密码成功”就直接判不符合。

2.2 Linux密码策略：login.defs与PAM模块的配合

Linux服务器下，改密码期限看/etc/login.defs，一致性目前推荐这几项：

PASS_MAX_DAYS 90 PASS_MIN_DAYS 1 PASS_MIN_LEN 8 PASS_WARN_AGE 7

复杂度靠PAM模块里的pam_pwquality来强制。在/etc/pam.d/system-auth的password段落加一行：

password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=

对应的复杂度参数写在/etc/security/pwquality.conf里：

minlen = 8 dcredit = -1 ucredit = -1 lcredit = -1 ocredit = -1

这组参数的含义是：最小长度8位，新密码里必须至少包含1个数字、1个大写字母、1个小写字母、1个特殊字符，如果缺类会直接拒绝修改。

同步的操作是把修改操作验证一遍，用普通用户执行passwd命令尝试设置弱密码，确认系统拒绝之后，再去服务器上摸一下/etc/shadow里的字段状态，这样测评师检查时你能直接拿出验证过的证据。

2.3 应用系统账号：唯一性清理与三员分立

操作系统层面合规不等于应用系统层面合规。测评师同样会检查应用系统的账号体系，很多业务系统的账号就存在两个典型问题：

一是系统运行多年积累了成百上千个账号，一堆离职人员的账号还在，甚至还在正常登录权限组里，这类“幽灵账号”是身份鉴别控制项里的大忌。整改时要把账号清单导出来，跟人事名单、岗位名单做交叉比对，确认每个人只有一个可用账号，再按流程禁用或删除僵尸账号。

二是管理员权限拆分不满足三员分立。等保三级对管理用户的要求是系统管理员、安全管理员、审计管理员角色分离，你不能用一个超级账号干所有事。如果应用系统只有admin一个内置账号，哪怕你改了密码策略，测评师也会因为“身份标识缺少权限隔离”提出整改建议。

这个阶段我强烈建议做一个账号台账，字段至少包括：账号名、归属人、角色、启用日期、最后登录日期、是否启用双因素。台账既是整改依据，也是测评时给测评师看的直接证据，比到现场临时翻系统清楚得多。

3. 控制项b落地：登录失败锁定和会话超时，策略冲突是重灾区

控制项b的要求是：应具备登录失败处理功能，配置并启用结束会话、限制非法登录次数和登录连接超时自动退出。这条在测评中的检查逻辑是“是否配置并启用”——配置了但没启用，等于没有。

3.1 操作系统层：Windows锁定策略与Linux pam_faillock

Windows Server的账户锁定策略同样在secpol.msc里，推荐配置是：

• 账户锁定阈值：5次无效登录
• 账户锁定时间：30分钟
• 重置账户锁定计数器：30分钟之后

这里提醒一句：锁定时长如果设成“永久”，一旦运维人员忘了密码连续输错几次，管理员账号可能直接锁定，又得进控制台解锁，业务停机风险很高。30分钟是比较常见的选择，既起到了阻断暴力破解的作用，又不至于把运维堵死。

Linux端推荐使用pam_faillock模块。在/etc/pam.d/system-auth的auth段和account段分别加上：

auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900 auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900 account required pam_faillock.so

这里的deny=5表示累计失败5次后锁定，unlock_time=900表示锁定时长15分钟。请注意：pam_faillock的配置在RHEL/CentOS系和Debian/Ubuntu系里差别很大，Ubuntu默认用的是pam_faillock还是pam_tally2要看系统版本，迁移策略文件前先确认发行版，别拿CentOS的配置直接往Ubuntu上套。

3.2 应用层会话超时与失败次数限制

操作系统配好之后，业务应用的登录失败处理常见两个问题：一是应用自己不带失败锁定功能，二是带了但没开启。测评师会要求你现场演示：输入错误密码几次，系统是否拒绝继续尝试、是否提示锁定时长、锁定后是否还能用新会话绕过。

如果你在改造成型阶段自己选型，优先选择带失败次数限制、验证码、锁定策略的产品或开发框架。如果应用是自研的，也要要求开发至少做这几点：同一账号连续失败5次锁定15分钟，失败逻辑按账号维度而非IP维度，响应头不能把具体是“账号错”还是“密码错”这种细节暴露出来，锁定状态要有提示页面而不是直接返回500。

应用层会话超时同样重要，Web应用通常建议空闲超时控制在15分钟以内。Tomcat这类中间件配置session-timeout比较直接，但要注意：只配session-timeout还不够，还要确保登录页面、接口请求都强制走认证过滤器，否则存在“老会话未被注销”的绕过路径。

3.3 本地会话和远程会话的空闲处理

SSH远程登录的超时设置在sshd_config里，推荐配置：

ClientAliveInterval 300 ClientAliveCountMax 0

意思是每300秒探测一次客户端，连续探测无响应次数为0时就断开连接。写完之后一定要重启sshd服务让配置生效，测评师会主动问“这个配置是什么时候生效的”，你答不上来或答错，印象分会受很大影响。

Windows的RDP远程桌面会话超时则通过组策略配置，位于计算机配置 → 管理模板 → Windows组件 → 远程桌面服务 → 远程桌面会话主机 → 会话时间限制，把“设置活动但空闲的远程桌面服务会话的时间限制”和“ reached 会话限制时终止会话”都打开。这里的坑在于策略名容易找错，很多配置项同名但语义不同，实际操作时按路径走，不要靠搜索关键词想当然。

4. 控制项c落地：RDP/SSH/HTTPS三条链路的加密整改

控制项c的要求是：远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听。这条本质上是链路层加密问题，测评师会关注所有能远程登录这台服务器的通道。

4.1 RDP：NLA与加密级别

Windows服务器的RDP服务默认可能允许不安全的连接方式。整改时重点做两件事：

第一，强制启用网络级别认证。在运行里输入gpedit.msc，路径是计算机配置 → 管理模板 → Windows组件 → 远程桌面服务 → 远程桌面会话主机 → 安全，把“要求使用网络级别的身份验证对远程桌面连接用户进行身份验证”设为已启用。NLA意味着用户在建立完整RDP会话之前就必须完成身份验证，期间传输的鉴别信息是经过加密协商的，比旧版RDP的安全模型好很多。

第二，把RDP加密级别设为“高”或者“符合FIPS标准”。在同样的策略路径下找到“设置客户端连接加密级别”，值设为“高”。同时还要确认服务器证书没有使用过期的自签名证书，如果单位有PKI体系，给RDP导入有效证书会更稳。

这个环节还得顺手检查一下远程桌面默认端口，不是强制项，但一般建议把3389改成其他高位端口，减少大规模扫描命中率。测评不会直接因为端口问题判不符合，但是可以在访谈里作为你做的额外加固措施讲出来，对整体印象有帮助。

4.2 SSH：从协议到认证方式的一次性加固

Linux服务器的SSH整改，推荐配置做成下面这样：

Protocol 2 PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes PermitEmptyPasswords no

Protocol 2是指SSH协议版本；PermitRootLogin no禁止root直接远程登录；PasswordAuthentication no表示禁止密码登录，只允许密钥登录。改了之后用密钥登录验证一次，再检查/etc/ssh/sshd_config里有没有被后续配置覆盖回去。

这里有一个非常现实的运维风险：一旦关闭密码登录而密钥又没有妥善备份，某台机器密钥丢失后你就只能通过物理控制台或者带外管理系统进去，运维通道直接断了。我当时做整改的习惯是：先把所有需要远程登录的管理员公钥都收集并加到authorized_keys里，确认每个人都能用密钥登录，再关密码登录，最后留一个控制台方式的应急通道说明。

顺带提醒，服务器上如果还开着telnet、rlogin之类的明文远程协议，这道题基本不用挣扎，直接不符合。检查方法是netstat -anp看几台机器上有没有监听23端口，有的话第一时间禁掉。

4.3 HTTPS：应用系统传输加密改造的常见坑

应用系统层面，Web登录页必须走HTTPS。整改时很多单位把证书装上就以为结束了，实际上有三个隐性坑。

第一个坑是证书安装后没有强制跳转，用户仍能通过http://直接访问登录页，密码照样明文传输。整改时要配置HTTP到HTTPS的301跳转，并且建议开启HSTS，让浏览器自动升级到HTTPS。

第二个坑是TLS协议版本没收紧。证书装上不代表协议安全，要禁用TLS 1.0和TLS 1.1，至少保留TLS 1.2，有条件上TLS 1.3。旧版本TLS已经被证实存在多处可利用漏洞，测评师的核查清单里通常包含协议版本检查。

第三个坑是证书链不完整。有的单位从证书服务商拿到证书后只部署了服务器证书，中间证书链没配全，PC浏览器访问有告警，手机上甚至直接访问失败。测评现场演示时出现这种告警，对整体评价很不利。部署完后建议用浏览器无痕窗口、移动网络两种方式分别验证一下证书链状态。

5. 控制项d落地：双因素认证的三种路线与“密码技术”条款理解

控制项d是整个身份鉴别里通过率最低的一条。原文要求是：应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。很多单位看到“两种以上组合”就去上指纹机，结果测评没过，因为他们忽略了“其中一种鉴别技术至少应使用密码技术”这个附加条件。

5.1 为什么“口令+指纹”不一定过得了这一条

组合鉴别里的“两种因素”必须是不同类别的因素：你知道的东西（口令）、你拥有的东西（令牌/手机）、你是什么（指纹/人脸）。口令+指纹看起来是两类，但指纹属于生物特征，它本身不算密码技术。如果整个鉴别体系里只有口令和指纹，没有密码技术成分参与，就不满足“至少一种鉴别技术使用密码技术”的硬性要求。

密码技术具体指什么？动态口令（OTP/TOTP）、数字证书、基于挑战应答的认证、USB-Key这一类都属于。所以合规的组合可以是：口令+手机动态口令、口令+USB-Key、口令+数字证书，这些才是测评中比较稳的方案。

5.2 路线一：接入堡垒机或统一认证平台

运维场景里最省事的做法是引入运维审计系统，也就是常说的堡垒机。堡垒机本身就把双因素认证内置了，常见组合是用户口令+动态令牌，管理员登录堡垒机先过一次双因素，再从堡垒机跳转到各应用服务器。这样做的好处主要有两个：一是身份鉴别的双因素落在统一入口上，不需要每台服务器单独折腾；二是堡垒机会把运维操作全程录下来，顺带满足了安全审计这条测评项的很大一部分要求。

如果你所在单位已经有统一身份认证平台或零信任产品，优先走这个路线，把应用服务器的管理账号接入平台，双因素由平台统一发放。这种模式在测评时解释起来也比较顺，因为平台侧就可以直接查看认证策略、多因素规则和登录日志。

5.3 路线二：叠加OTP动态口令

自研系统或者不想引入大平台的单位，最常见的是叠加OTP动态口令。业务流程是：用户输入账号密码后，系统要求输入手机上生成的6位动态验证码，验证码基于时间同步算法每30秒变化一次。

落地方式可以考虑使用开源的TOTP服务端库，给应用系统加一个认证步骤就够了。移动端使用支持TOTP的通用认证器应用即可。这样做的好处是开发量相对可控、不需要采购额外硬件，风险是种子密钥的分发、绑定和丢失恢复流程必须在项目中一并考虑好，否则用户换机了就登录不进去，运维电话会被打爆。

5.4 路线三：数字证书与USB-Key

对内部要求高的系统，可以走数字证书/智能卡路线。管理员登录时插入USB-Key，通过证书认证完成第二因素。这种方案的优点是安全级别高、合规方面解释空间最大，缺点是从证书签发、介质管理到客户端环境适配都要投入，成本明显比OTP高。

测评时如果你走证书路线，要把证书签发、证书吊销、介质丢失补发这几个管理流程讲清楚。技术上双因素是成立的，管理流程如果一塌糊涂，测评师会有理由认为这条不可用。

5.5 整改覆盖面的取舍建议

双因素整改的成本高，你不能一上来就想“全系统所有用户全部上双因素”，要给业务留余地。我的建议是按角色分层：

• 服务器本地管理员、拥有业务高权限的账号：必须双因素；
• 普通业务用户：至少保证密码复杂度和登录失败处理合规，有条件的逐步推进双因素；
• 外包、第三方运维账号：除了双因素，还要额外走审批流程并定期复核权限。

这个优先级既能让整改动作迅速收敛，也能在测评访谈里体现风险分级的思想。测评师不会因为你普通用户还没上双因素就一定判不符合，他会看整体风险是否可控，但管理员账号没有双因素是绝对的减分项。

6. 整改中的几次翻车现场与我的避坑清单

前面讲的是“应该怎么做”，最后一个部分想分享几次实战中发生的翻车，都是我见过或者亲手处理过的真实情况，每一条都值得整改负责人提前预防。

6.1 教训一：锁定策略先于业务验证，酿成连锁故障

某次给一台跑核心业务的应用服务器开启账户锁定策略，设了“3次失败锁定10分钟”。结果第二天业务系统里有个服务账号因为密码轮换脚本出了问题，连续尝试连接数据库失败，超过3次后被锁定，整个业务链路全部中断。等保整改不是改完配置就算完事，起码要在停了业务的维护窗口里做一轮完整的登录验证，特别是服务账号、计划任务账号不能被锁定策略误伤。建议把需要独立密码的服务账号加入锁定豁免名单，或者对这类非交互账号单独走密钥/托管凭证方案。

6.2 教训二：密码策略调整没有评估存量用户

还有个常见场面是密码期限从180天改成90天后，没提前通知存量用户，结果当月大批用户到期限需要同时改密。企业里如果是几千个业务系统用户，改密高峰会把验证码通道打爆，还会出现大量用户因为改密失败去找管理员重置，给身份管理造成连锁压力。整改之前建议先做用户清单分析，统计30天内到期的账号数量，设置分批次到期策略，并在应用系统内做一个提前提醒页面，而不是等到测评前集中改配置。

6.3 教训三：SSH改配置忽略控制台通道

改SSH配置导致远程登录回不来，这一点即使有经验的人也容易翻车。之前处理过一次，管理员在/etc/ssh/sshd_config里同时改了端口和禁用密码登录，重载服务之后自己新开的连接没能保持住，退出来之后就再也登不上了，最后只能联系机房做控制台登录。所有对SSH的修改，我都推荐按这个顺序做：先备份原配置文件、开一个常驻终端会话不要关、修改后先用当前连接验证新配置能正常建连、确认没问题再退出当前会话。如果实在没有控制台条件，至少确保有另一个管理员从另一条网络路径同时在线，防止“改完就失联”。

6.4 我的推荐整改顺序与自查清单

按照依赖关系，推荐整改顺序是：先清理账号和角色权限，再调密码策略和口令管理流程，然后处理登录失败锁定与会话超时，接着做远程管理加密改造，最后上双因素认证。

自查清单可以做成表格，逐项打勾：

最后再分享一个做整改台账的个人习惯：每一项整改做完，除了截图配置界面，还要把命令行查询出来的生效参数结果一起存档。比如Linux下grep出来的sshd_config有效配置、Windows下gpresult导出的策略结果，这些比界面截图更能说明问题，测评时也更容易获得认可。身份鉴别是整个等保三级改造链条的第一环，这一步如果做扎实，后面访问控制、安全审计这些控制项的整改就有了一个干净可控的基础。