📚 课程目录第3章配置合规标准与策略设计

3. 配置合规标准与策略设计

合规基线不是一份“看起来正确”的配置备份，而是一组可被设备逐条验证的明确断言。设计基线的核心工作，是把安全策略、接口规范、路由策略、日志配置等运维意图，翻译成 Junos 能够用 show configuration、show configuration | display set 或 show configuration | compare 等命令稳定判定的规则。规则写得好不好，直接决定后续合规检查是“能定位到具体行”还是“只能给出一个模糊的通过/不通过”。

一、基线的分层结构

建议把基线拆成四层，每层承担不同职责，避免把“必须存在的配置”和“禁止出现的配置”混在一起：

强制存在项：设备上必须出现的配置，例如管理接口必须启用 SSH、必须配置 NTP 与 syslog、必须存在默认拒绝的安全策略。
禁止出现项：设备上不允许出现的配置，例如明文 telnet、snmp community public、未加密的 radius-server 密钥。
取值约束项：配置存在但取值必须落在允许范围内，例如 set system services ssh protocol-version v2、set protocols bgp group EBGP peer-as 65001 中的 AS 号必须与对端匹配。
关系约束项：多条配置之间必须满足的逻辑关系，例如“若接口 ge-0/0/1 配置了 unit 0 family inet address，则必须同时存在对应的 security zone 绑定”。

这四类规则在检查时的判定方式不同：前两类是存在性判断，第三类需要解析值，第四类需要跨层级关联。把它们分开管理，后续写检查脚本或使用 Junos PyEZ、Ansible 等工具时，才能按类型选择不同的匹配策略。

二、从运维意图到可检查规则

以“所有管理访问必须加密”为例，这条意图至少可以拆成三条可检查规则：

# 规则 M-01：禁止明文 telnet
set system services telnet   → 必须不存在

# 规则 M-02：SSH 必须启用且仅允许 v2
set system services ssh protocol-version v2  → 必须存在

# 规则 M-03：管理接口必须限制源地址
set interfaces ge-0/0/0 unit 0 family inet filter input MGMT-ACL
→ 必须存在，且 MGMT-ACL 中必须包含允许管理网段的 term

每条规则都要明确三件事：检查对象（哪条配置层级）、期望状态（存在/不存在/等于某值/满足某关系）、判定依据（用哪条命令或哪个 API 取数）。缺少任何一项，规则就无法被稳定执行。

规则命名建议采用“域-序号-类型”格式，例如 SEC-01-MUST、IF-03-FORBID、RT-07-VALUE。这样在合规报告中可以直接按前缀聚合，快速看出哪个域的问题最多。

三、四类典型基线的规则设计

安全策略基线主要检查 zone 之间的策略是否完整、是否存在 any-any 放通、策略动作是否与业务匹配。例如要求“从 untrust 到 trust 必须存在显式策略，且默认策略为 deny”。可检查规则可以写成：show security policies from-zone untrust to-zone trust 的输出中，必须存在至少一条 permit 策略，且不得存在 source-address any 与 destination-address any 同时出现的 permit 策略。

接口规范基线关注接口描述、MTU、双工、未使用接口的关闭状态。例如要求“所有物理接口必须配置 description，未使用接口必须 disable”。检查时遍历 show interfaces terse 与 show configuration interfaces，对每个 ge-、xe- 接口判断是否存在 description 节点，以及是否被 disable 标记。

路由策略基线关注 BGP 邻居的认证、路由过滤、最大前缀数。例如要求“所有 EBGP 邻居必须配置 authentication-key 与 import 策略”。检查时按 protocols bgp group 逐组展开，确认每个 neighbor 下都有 authentication-key，且 import 引用的策略名称在 policy-options policy-statement 中存在。

日志配置基线关注 syslog host、facility、severity、日志文件大小与轮转。例如要求“必须配置至少一个远程 syslog host，且 severity 不高于 warning”。检查 system syslog host 节点，确认存在 host 且 any 或 security facility 的 severity 为 warning 或更严格级别。

四、把规则写成可执行的检查逻辑

规则设计完成后，需要落到具体的取数与比对方式。以接口规范为例，假设要求“所有 ge- 接口必须配置 description，且 description 中必须包含所属区域标识（如 ZONE-CORE）”。检查逻辑可以写成：

# 取数
show configuration interfaces | display set | match "ge-"

# 期望输出片段（示例）
set interfaces ge-0/0/0 description "ZONE-CORE uplink to core-sw"
set interfaces ge-0/0/1 description "ZONE-EDGE uplink to edge-fw"

# 判定
对每个 ge- 接口：
  若不存在 description 节点 → FAIL（缺失）
  若 description 中不包含 ZONE- 前缀 → FAIL（值不符）
  否则 → PASS

这里的关键是“逐接口展开”而不是“整体匹配”。整体匹配只能告诉你“配置里有没有 description”，无法告诉你“哪个接口缺了”。合规检查的价值在于定位到具体对象，因此规则设计时必须保留对象粒度。

五、基线版本与例外管理

基线不是一次性文档，而是需要版本化的资产。每次基线变更都应记录：变更原因、影响范围、生效时间、审批人。对于确实无法满足基线的设备（例如旧型号不支持 SSH v2 的某些算法），应建立例外清单，明确例外对象、例外规则、到期时间与补偿措施。例外清单本身也要纳入合规检查，避免“例外”变成永久豁免。

不要把“当前配置”直接当作基线。基线是“应该是什么”，当前配置是“实际是什么”。两者之间的差异才是合规检查要输出的内容。若直接用当前配置生成基线，检查结果永远为 PASS，失去治理意义。

六、规则设计检查清单

检查项	合格标准	常见问题
规则是否可定位到对象	能输出具体接口、邻居、策略名	只输出“接口配置不合规”
是否区分存在性与取值	MUST/FORBID 与 VALUE 分开	把“必须存在”和“值必须为 X”混写
是否有明确取数命令	每条规则对应至少一条 show 命令	规则描述模糊，无法自动化
是否覆盖四类基线域	安全、接口、路由、日志均有规则	只检查安全策略，忽略日志与路由
是否有例外与到期机制	例外清单含对象、规则、到期时间	例外无期限，长期绕过检查

完成上述设计后，基线就从“一份文档”变成了“一组可执行断言”。下一阶段的工作，是把这些断言接入自动化检查流程，按设备、按域、按规则 ID 输出合规报告，并对 FAIL 项生成变更工单。规则设计得越具体，后续的变更治理就越容易闭环。