5.4 协议安全加固清单
5.4 协议安全加固清单
本节摘要：把 5.1 到 5.3 的措施收敛成一张条款化、可打勾、可审计的加固清单——按上线、周期、事件三类时机组织，每条注明检查方法与通过标准。清单的价值不在全面，而在每一条都真的被执行。
交底会上的那张纸
场景：新项目安全交底会，你把 5.1 的五层纵深、5.2 的证书巡检、5.3 的演练计划讲了一遍，与会各方纷纷点头。三个月后复检，分区规则被一条临时链路凿穿、证书待审列表积压、演练从未进行。点头的人没有恶意，他们只是需要一个把共识变成动作的载体——这就是清单的作用。安全工程与可靠性工程的经验一致：措施失败很少因为不知道，几乎都因为没有变成定期执行的动作。
本节先给清单本体，再讲清单的使用制度——后者决定前者是不是废纸。
学习目标
阅读完本节，你应当能够：
- 用三类时机（上线、周期、事件）组织本项目的加固清单；
- 为每条清单项定义可机器或可肉眼复核的通过标准；
- 建立清单的执行、留痕与追责制度；
- 按风险等级裁剪清单，适配不同规模的项目。
一、清单本体
按执行时机分三类，共三十一条，条目后括注检查方法。规模小的项目可按文末的裁剪规则取子集。
上线类（一次，交付前）
| 编号 | 条款 | 通过标准 |
|---|---|---|
| L01 | 控制网与办公网隔离成文，例外走评审 | 网络拓扑图与规则文档版本化 |
| L02 | 防火墙最小放行规则，默认拒绝 | 规则清单逐条对应业务需求 |
| L03 | 网关客户端白名单配置 | 白名单与台账一致，多余人清零 |
| L04 | 点表读写分区，写白名单最小化 | 可写寄存器清单经工艺确认签字 |
| L05 | UA 证书由可信来源签发，指纹当面核验 | 证书台账含指纹与有效期 |
| L06 | UA 服务器与客户端时钟对时配置 | 与标准时源偏差小于分钟级 |
| L07 | UA 安全策略按 5.2 口诀选定 | 跨网段加密、厂内签名有记录 |
| L08 | 用户与角色体系启用，写权限双因子 | 角色矩阵评审通过 |
| L09 | 质量戳传递功能验证 | 拔从站数秒内 UA 侧置坏 |
| L10 | 主备切换四步演练通过 | 演练报告含各步实测时间线 |
| L11 | 落盘与续传参数按最坏恢复时长核定 | 断电测试后数据无缺口 |
| L12 | 调试口与多余服务默认关闭 | 端口扫描结果与台账一致 |
周期类（月度或半年度）
| 编号 | 条款 | 频次 | 通过标准 |
|---|---|---|---|
| P01 | 证书有效期与待审列表巡检 | 月 | 剩余天数低于告警线即换期 |
| P02 | 防火墙与白名单规则比对台账 | 月 | 零差异或差异经审批 |
| P03 | 行为监控基线复核 | 季 | 新增设备已入基线 |
| P04 | 主备切换演练 | 半年 | 指标不劣于上次报告 |
| P05 | 点位抽检与就地显示比对 | 周 | 抽检记录留痕且全通过 |
| P06 | 日志与审计空间与转储检查 | 月 | 无写满、转储可回放 |
| P07 | 固件版本台账更新与变更影响评估 | 事件触发后 | 手册点表同步核对 |
| P08 | 账号清理与权限复核 | 季 | 离场人员零残留 |
事件类（触发即执行）
| 编号 | 触发事件 | 动作 |
|---|---|---|
| E01 | 出现基线外主站或异常写 | 五分钟响应路径启动，取证后阻断 |
| E02 | 证书校验失败告警 | 先查时钟，再查信任列表与有效期 |
| E03 | 主备切换真实发生 | 复盘角色协商与数据连续性 |
| E04 | 设备固件升级 | 映射表重跑抽检，字典比对差异 |
| E05 | 拓扑变更或临时链路 | 评审后入台账，限期拆除或转正 |
| E06 | 断电或雷击后恢复 | 按 5.3 四步复演并核对落盘完整 |
图20 加固清单的三类时机与闭环
二、清单的使用制度
三件套让清单活起来。责任到人：每条清单项有执行人与复核人，复核不能是同一人——这不是不信任谁，而是防"顺手打个勾"的人性设计。留痕强制：打勾必须附证据，规则比对附截图、演练附报告编号、抽检附记录单；无证据的勾视同未执行。复检追责：周期类项目由独立复检抽验，抽验发现未执行而清单上已打勾的，进入运维质量考核。制度听起来严苛，实际执行成本很低——三十一条里需要人工动手的不过十几条，多数是"看一眼、记一笔"。
三、按项目裁剪
清单不是越大越好，小项目塞进全部条款会导致形式主义。裁剪原则按风险定深度：关键基础设施（供水供电供气）全量执行；一般工业产线上线类全量、周期类保留 P01、P02、P04、P05、P08，事件类全保留；实验或演示环境上线类保留 L01、L03、L06、L12，周期类保留 P01，事件类保留 E02。裁剪结果写进项目安全方案并说明理由——裁剪本身也要留痕，防止"图省事的裁剪"伪装成"风险接受的裁剪"。
⚠️ 常见坑：把清单当一次性的交付文档。清单是活文档，架构变更、新设备接入、事故复盘都会新增或修改条款；每季度把清单与实际系统对一遍，删掉失效条款、补上新风险，清单才会跟着系统一起长大。
四、清单失效的两种真实形态
收官前看清单制度在实践中最常见的两种死法，防患于未然。形态一，"验收型清单"：清单在交付验收时全绿，之后无人再打开——周期类条款没有进任何人的日历，事件类条款没有接进告警系统，清单从"运行手册"退化为"验收材料"。解法是把周期类条款录入运维排班系统（与巡检、保养同一套调度），事件类条款逐条挂到对应的告警规则里，让清单条款长在系统里而不是文件里。形态二，"膨胀型清单"：每次事故复盘都往清单里加条款，三年后清单两百条，没人读得完，执行率崩塌。解法是给清单设"退休机制"：每季度复检时，把连续一年未拦截过任何问题、且对应风险已被架构升级消解的条款降级为"抽查项"乃至移除，清单的总条数应当围绕五六十条波动而非单调增长。
两种死法的共同解药是同一句话：清单是系统的一部分，要像维护系统一样维护清单——有上线、有运行、有迭代、有退役。
五、清单与自动化的握手
清单走到成熟期会撞上同一个问题：条目越攒越多，人工核表开始漏项。正确方向不是精简清单，而是把可机器核对的条目交给脚本：端口开关、白名单规则、证书有效期、安全策略配置，都能从设备与网关导出成结构化数据，比对脚本跑一遍，差异自动浮出。人工保留两类条目：需要上下文判断的（该不该开写权限），与需要演练验证的（越权是否真被拒）。
人机分工划清后，清单的执行成本大降、覆盖面反升。脚本输出同样进台账：每次跑完留档，季度巡检看差异曲线——防线漂移的趋势比单次差异更能说明问题。脚本本身也要进 6.1 的版本管理，别让核表工具变成新的黑盒。若团队暂时没有脚本能力，退一档也有招：把清单按"机器可查与人工判断"分成两栏，机器可查栏设计成固定格式的导出对照表，比对工作量立减一半。这条演进路与 6.3 的故障手册、6.1 的工具清单是同一条：制度先立、自动化跟进，最后人只处理例外。
本节要点回顾
- 三类时机组织：上线一次、周期滚动、事件触发，时机分清清单才可执行；
- 通过标准先行：每条条款先定"怎么算过"，打勾才有意义，留痕才有依据；
- 制度比条款重要：责任到人、复核分离、留痕强制、复检追责，四要素缺一清单必废；
- 裁剪要有理由：按风险定深度，裁剪结果进安全方案，防止省事型裁剪。
安全与可靠性布防完毕，下一章回到工程师的日常：工具、部署与速查。