等保2.0标准实施以来，越来越多的企业需要在规定时间内完成云服务器的安全整改。在测评机构出具的整改通知中，身份鉴别和访问控制相关的问题出现频率最高，比如登录未启用双因素认证、口令策略过于宽松、账户权限分配混乱等。这些问题看似简单，实际整改时却涉及系统配置、认证架构、审计联动等多个层面。本文将以Linux和Windows两类主流云服务器为例，详细讲解这两大控制点的落地方法。
一、身份鉴别措施的具体落地
1. 启用双因素认证
等保2.0要求对登录用户进行身份标识和鉴别，身份鉴别信息具有复杂度要求并定期更换，同时对重要系统建议采用两种或两种以上组合的鉴别技术。单一口令鉴别是最容易被扣分的地方。在云环境中，常见的双因素方案有：口令加动态令牌（如阿里云的MFA、腾讯云的虚拟MFA设备）、口令加密钥登录（SSH Key加口令）、口令加短信验证等。
以SSH双因素为例，可以部署Google Authenticator配合PAM模块实现。安装libpam-google-authenticator后，在sshd配置文件中启用ChallengeResponseAuthentication，同时在/etc/pam.d/sshd文件开头添加auth required pam_google_authenticator.so，每个用户执行google-authenticator命令生成动态码绑定手机即可。这样每次SSH登录既需要输入口令，又需要输入手机上的六位动态验证码。
2. 配置口令复杂度与有效期策略
Linux系统下主要通过PAM模块设置。编辑/etc/pam.d/system-auth或/etc/pam.d/common-password，添加或确认类似这样的配置行：password requisite pam_pwquality.so try_first_pass local_users_only retry=3 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 minlen=8。其中dcredit、ucredit、lcredit、ocredit分别代表数字、大写字母、小写字母、特殊字符的最少数量，minlen是口令最小长度，等保要求一般不低于8位且包含至少三类字符。
口令有效期在/etc/login.defs文件中设置PASS_MAX_DAYS 90、PASS_MIN_DAYS 1、PASS_MIN_LEN 8，表示口令最长90天必须更换，两次修改间隔至少1天。Windows系统则通过本地安全策略中的账户策略来设置，路径为安全设置、账户策略、密码策略，勾选密码必须符合复杂性要求，设置密码最长使用期限为90天，最短使用期限为1天，密码长度最小值为8个字符。
3. 登录失败处理与连接超时
等保要求应具有登录失败处理功能，配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施。Linux下编辑/etc/pam.d/sshd或/etc/pam.d/login，添加auth required pam_tally2.so deny=5 unlock_time=300 even_deny_root root_unlock_time=300，表示连续失败5次锁定账户300秒。注意不同发行版可能使用pam_faillock模块替代pam_tally2，配置语法略有差异，CentOS 8以上版本需要用pam_faillock的deny和fail_interval参数实现同样效果。
连接超时通过在/etc/profile中添加export TMOUT=600实现，空闲10分钟自动退出会话。Windows对应配置在本地安全策略的账户锁定策略中，设置账户锁定阈值为5次无效登录，锁定持续时间为30分钟，重置账户锁定计数器为30分钟之后。远程桌面会话超时可以在组策略的会话时间限制中设置空闲会话限制。
二、访问控制措施的具体落地
1. 账户清理与默认账户管理
测评时经常发现服务器上存在大量无用账户和测试账户，这是访问控制的典型扣分项。整改时应逐一核查/etc/passwd中的账户列表，删除或禁用与运行无关的账户，比如games、ftp等系统自带但实际不使用的账户可以使用usermod -L锁定或直接userdel删除。对于root账户，建议禁止其直接远程登录，在/etc/ssh/sshd_config中设置PermitRootLogin no，日常运维使用普通账户加sudo提权的方式。
Windows系统要重点检查Guest账户是否禁用，重命名默认Administrator账户也能增加攻击者猜测成本，可在本地安全策略的本地策略、安全选项中设置重命名系统管理员账户。同时清理IIS、SQL Server等应用创建的冗余账户，确保每个账户都能追溯到具体责任人。
2. 最小权限原则与sudo授权
访问控制的核心是按最小权限原则分配账户权限。不要让所有运维人员共用root或Administrator账户，而是通过sudoers文件精细授权。使用visudo命令编辑/etc/sudoers，或者更好的做法是在/etc/sudoers.d/目录下按人员创建独立文件，例如为张三创建文件zhangsan，内容为zhangsan ALL=(ALL) /usr/sbin/service, /usr/bin/systemctl，表示张三只能执行服务管理相关的命令，无法执行其他高危操作。授权时遵循需要什么给什么的原则，避免直接给ALL权限。
对文件和目录权限也要逐一核查，使用find / -perm -0007 -type f排查全局可写的文件，敏感配置文件如/etc/shadow的权限应控制在400或600。云平台层面还应结合安全组策略收紧端口访问范围，比如SSH端口的入站规则只允许运维办公网IP访问，数据库端口不对公网开放，从网络层实现第一道访问控制。
3. 权限分离与安全组策略
等保要求由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则。实际操作中建议建立三权分立的账户体系：系统管理员负责日常运维、安全管理员负责策略配置与审计、审计管理员负责日志审查，三个角色使用不同账户并分配不同权限。虽然中小企业未必能配齐专人，但至少在账户层面做到角色分离，测评时能提供清晰的账户权限对照表。
三、整改中的常见问题与应对
很多单位整改时只改配置不做验证，测评现场一测就露馅。建议每完成一项配置，立即使用其他账户或错误口令登录测试，确认锁定策略、复杂度策略真实生效。特别是pam模块的配置顺序错误会导致策略失效甚至无法登录，修改前务必对相关文件做备份，条件允许时先在测试机验证再推送到生产环境。
另一个常见问题是整改后业务受影响。比如开启口令90天有效期后，所有用户被强制改密可能引起运维混乱，建议提前通知并分批执行。修改SSH端口、禁止root登录等操作要确认自动化脚本和定时任务中是否硬编码了旧的登录方式。所有整改动作都要保留操作记录和配置截图，这些既是测评佐证材料，也方便出现问题时回溯。
四、整改核查清单
为方便自查，整理以下核查要点：
| 检查项 | Linux位置 | Windows位置 |
|---|---|---|
| 双因素认证 | PAM加Google Authenticator | 云平台MFA或第三方方案 |
| 口令复杂度 | /etc/pam.d/system-auth | 本地安全策略密码策略 |
| 口令有效期 | /etc/login.defs | 密码最长使用期限 |
| 登录失败锁定 | pam_faillock或pam_tally2 | 账户锁定策略 |
| 会话超时 | TMOUT变量 | 组策略会话时间限制 |
| 默认账户管理 | PermitRootLogin no | 禁用Guest、重命名管理员 |
等保整改不是应付测评的表面工作，身份鉴别和访问控制的强化确实能显著提升服务器的安全基线。按照上述步骤逐项落地并留好佐证材料，测评通过只是水到渠成的结果。