1加固项目清单
1.1 MongoDB 数据库加固项目实施内容状态TLS/SSL 双向认证生成 CA、服务器证书、客户端证书，配置 tlsMode=requireTLS✅ 完成证书配置/data/project/config/mongo-tls/ 目录，有效期至 2028-08-29✅ 完成应用连接串更新添加 tls=true 参数✅ 完成
1.2 PostgreSQL 数据库加固项目实施内容状态TLS/SSL 配置生成证书，配置 ssl=on✅ 完成pg_hba.conf改为 hostssl 强制 TLS 连接✅ 完成审计日志logging_collector=on, log_statement=ddl, log_connections=on✅ 完成日志目录挂载/data/project/logs/postgres/ 持久化存储✅ 完成。
1.3MySQL 数据库检查项目实施内容状态。
1.4 Linux 操作系统加固项目实施内容状态密码复杂度策略pam_pwquality.so：minlen=8, 大小写+数字+特殊字符各至少1个✅ 完成登录失败锁定pam_faillock.so：5次失败锁定300秒✅ 完成登录超时/etc/profile 添加 TMOUT=900✅ 完成禁止 root 远程登录PermitRootLogin no✅ 完成三权分立创建 sysop（业务操作员）、auditor（安全审计员）✅ 完成AppArmor 强制访问控制为 sshd、rsyslogd 等启用 enforce 模式✅ 完成完整性监控AIDE 安装，监控引导程序、系统程序、配置、应用✅ 完成
2故障分析：SSH 连接失败
故障现象能 ping 通 10.102.53.251SSH 连接在认证前被拒绝：Connection closed before authentication不提示输入密码，直接断开。
根本原因
AppArmor 的 sshd 策略配置过于严格。
我们创建的 /etc/apparmor.d/usr.sbin.sshd 策略文件限制了 sshd 只能访问特定路径，但：
1.缺少对 /lib/x86_64-linux-gnu/security/（PAM 模块目录）的访问权限。
2.缺少对 /var/log/auth.log 等日志文件的写权限。
3.缺少对 /run/systemd/ 等系统目录的访问。
当 sshd 尝试加载 PAM 模块或写入日志时，被 AppArmor 拒绝，导致进程异常退出，连接在认证阶段前断开。
次要因素pam_faillock 的 preauth 阶段如果与 AppArmor 冲突，会加剧问题。
3风险分析
高风险项风险说明缓解措施AppArmor 策略过严导致服务不可用已发生需完善策略文件，添加必要的系统路径PAM 配置错误导致无法登录可能修改 PAM 前备份，保留 root 控制台访问证书过期MongoDB/PostgreSQL 证书 2028-08-29 过期设置日历提醒，提前 3 个月续期
中风险项风险说明缓解措施TLS 证书链配置客户端需正确配置 CA 证书文档化证书分发流程AIDE 误报正常更新会被标记为异常建立基线更新流程三权分立账户密码管理sysop/auditor 密码需安全分发使用密码管理工具
低风险项TMOUT=900 可能导致长时间操作中断PermitRootLogin no 影响紧急 root 登录
4经验教训
4.1 配置管理原则
问题： AppArmor 策略直接 enforce 模式，未经过 complain 模式测试
正确做法：
1. 先以 complain 模式测试
aa-complain /etc/apparmor.d/usr.sbin.sshd
2. 观察日志，确认无拒绝
tail -f /var/log/syslog | grep audit
3. 无问题后再 enforce
aa-enforce /etc/apparmor.d/usr.sbin.sshd
4.2 关键服务保护
问题： SSH 是生命线，修改其配置必须有备用访问通道
正确做法：修改前开启多个 SSH 会话，保持连接准备带外管理（iLO/iDRAC）作为兜底修改后测试新连接，确认无误再断开旧连接
4.3 PAM 配置顺序
问题： pam_faillock 的 preauth 放在 pam_unix 之前，可能阻断所有认证
正确做法：
推荐顺序
auth required pam_faillock.so preauth silent # 静默记录，不阻断
auth sufficient pam_unix.so ...
auth required pam_faillock.so authfail # 失败时阻断
4.4变更管理
问题： 一天内做了太多变更，无法快速定位故障点
正确做法：每次变更后验证服务可用性使用 etckeeper 或 git 跟踪配置文件变更准备快速回滚脚本
4.5 备份策略
缺失： 未对关键配置文件做备份
应补充：
修改前自动备份
cp /etc/pam.d/common-auth{,.bak.KaTeX parse error: Expected '}', got 'EOF' at end of input: ...d_config{,.bak.(date +%Y%m%d%H%M%S)}
5恢复建议：
当前服务器 SSH 不可用，需要：
1.通过带外管理/物理控制台登录
2.禁用 AppArmor sshd 策略：
apparmor_parser -R /etc/apparmor.d/usr.sbin.sshd
3.重启 sshd：
systemctl restart sshd
4.测试 SSH 连接5.修复 AppArmor 策略后重新加载
5.修复 AppArmor 策略后重新加载
6后续优化建议
6.1完善 AppArmor 策略 --- 使用 aa-genprof 工具生成更准确的策略。
6.2配置日志集中 --- 将 AIDE 告警通过 rsyslog 发送到安全管理中心。
6.3定期演练 --- 每季度验证备份账户、带外管理可用性。
6.4文档化 --- 编写《等保加固操作手册》，包含回滚步骤。
总结： 本次加固覆盖了等保要求的大部分技术点，但在实施过程中违反了"变更管理"和"测试验证"原则，导致服务中断。核心教训是：生产环境的任何安全加固都必须有回退方案，且不能一次性实施过多变更。