基线漂移检查
系统上线时满足基线要求，不等于长期保持：运行过程中配置会因应急变更、临时放行与未回滚的调整而偏离基线，形成漂移。检查按三步进行：先确定基线版本（加固清单或厂商安全指南），再抽样导出当前配置与基线做对比，最后结合变更单对差异项做归因。漂移最常见来源是应急变更未回滚，因此这项检查必须与变更管理流程配套，否则每次整改后仍会重新出现同类问题。
基本信息
| 方法 | 基线确定、配置对比、差异归因三步 |
|---|---|
| 检查对象 | 安全加固项、账号策略、服务与端口配置 |
| 产出物 | 漂移项清单、归因说明与整改建议 |
| 配套要求 | 与变更管理流程联动，避免反复漂移 |
典型使用场景
- 例行巡检：定期抽样核对关键系统配置与基线的一致性
- 重大变更后复查：变更窗口结束后确认配置是否正确回滚
- 合规检查：证明系统持续满足基线与内控要求
- 故障复盘：分析事故是否与某次临时调整相关
- 多环境一致性：测试与生产环境的差异是否有意为之
检查思路
检查思路
1. 选定基线版本：加固清单或厂商安全指南，并注明版本与日期
2. 抽样系统导出当前配置 # 覆盖不同角色与不同批次上线的系统
3. 对比标注漂移项：新增开放端口、策略放宽、服务被启用
4. 结合变更单做归因：有审批的变更与无记录的调整分开统计
5. 输出整改项与流程建议，例如把回滚确认加入变更检查项漂移类型与来源
| 漂移类型 | 典型来源 | 处置方向 |
|---|---|---|
| 服务与端口 | 排障时临时开启未关闭 | 按变更单核对并回收 |
| 账号与策略 | 临时提权后未回收 | 纳入定期复核清单 |
| 配置放宽 | 应急调整未回滚 | 把回滚确认写入变更流程 |
| 版本回退 | 补丁未同步或重装系统 | 建立装机即应用基线的机制 |
基线本身也需要维护：版本长期不更新会让检查失去意义，建议随厂商公告与业务变化定期评审基线的适用性。