3. 配置合规基线的定义方法
配置合规基线不是一份“最佳实践清单”的简单堆砌，而是把业务需求、安全策略和行业标准翻译成一组可采集、可比较、可判定的 Arista 设备配置期望值。它的核心价值在于：当设备配置发生漂移时，系统能够自动识别“哪些行偏离了基线、偏离属于哪一类风险、应该由谁在什么时限内修复”。因此，定义基线的过程本质上是一次“需求→控制项→配置断言→判定规则”的逐层落地。
一、从三类输入推导控制项
制定基线前，先明确三类输入各自贡献什么。业务需求决定“哪些能力必须可用”，例如核心交换机必须支持双上行、必须保留特定 VLAN 承载生产流量；安全策略决定“哪些行为必须被禁止或限制”，例如禁止 Telnet、禁止未授权 SNMP 团体字、管理面必须限制源地址；行业标准则提供“必须覆盖哪些控制域”，例如 PCI DSS 要求对持卡人数据环境中的网络设备实施严格访问控制与变更管理，等保 2.0 在“安全通信网络”“安全区域边界”“安全计算环境”中要求身份鉴别、访问控制、安全审计与入侵防范。
把这三类输入对齐后，可以归纳出 Arista 设备上最常纳入基线的关键模块：接口（Interface）、路由（Routing）、ACL、AAA、管理面（Management Plane）、日志与审计（Logging/Audit）。每个模块下再拆成若干“控制项”，每个控制项最终对应一条或一组可判定的配置断言。
二、把控制项写成可判定的配置断言
基线能否自动化，取决于断言是否足够具体。以“禁止明文远程管理”为例，模糊表述是“应使用加密管理协议”，可判定断言应写成：management api http-commands 必须启用且仅允许 HTTPS；management ssh 必须启用；no telnet 或等价配置必须存在。再如“管理面访问控制”，断言可写成：管理接口必须绑定到带外管理 VRF，且必须存在仅允许运维网段访问的 ACL。
下面给出一份可直接参考的基线控制项示例表，字段包括模块、控制项、配置断言与判定方式。示例中的网段、VLAN、团体字均为教学假设值，实际部署时需替换为真实环境参数。
| 模块 | 控制项 | 配置断言（示例） | 判定方式 |
|---|---|---|---|
| 接口 | 未使用端口关闭 | 所有未描述用途的接口应处于 shutdown 状态 | 遍历接口，检查 description 为空且无 shutdown 的端口 |
| 接口 | 接入端口 VLAN 明确 | 接入端口必须显式配置 switchport access vlan，禁止默认 VLAN 1 | 检查 switchport mode access 端口的 access vlan 值 |
| 路由 | 动态路由认证 | OSPF 邻居必须启用 MD5/SHA 认证 | 检查接口下 ip ospf authentication message-digest |
| ACL | 管理面源限制 | 管理 ACL 仅允许 10.10.0.0/24 与 10.20.0.0/24 访问 SSH/HTTPS | 解析 ACL 条目，比对允许源与端口 |
| AAA | 集中认证 | 必须配置 TACACS+ 服务器组并用于 login 与 enable | 检查 aaa authentication login default group tacacs+ local |
| AAA | 本地回退 | 必须保留 local 作为回退，且本地账号密码为加密存储 | 检查 aaa authentication 末尾含 local，username secret 存在 |
| 日志 | 审计外发 | 必须配置 syslog host 指向日志服务器，级别不高于 informational | 检查 logging host 与 logging trap 配置 |
三、基线定义的数据流与判定逻辑
基线定义完成后，实际运行时的判定链路是：从设备采集运行配置（running-config）→ 解析为结构化配置树 → 与基线断言逐条比对 → 输出合规/不合规/无法判定三类结果 → 对不合规项按风险等级排序。下图展示了这一数据流以及各模块在其中的位置，帮助理解“基线定义”与“合规检查”之间的衔接关系。
四、基线定义中的参数化与例外管理
真实网络中，不同角色设备的基线不可能完全一致。核心交换机、接入交换机、边界路由器、管理交换机的接口数量、路由协议、ACL 复杂度差异很大。因此基线定义必须支持参数化：把“管理网段”“TACACS+ 服务器地址”“syslog 服务器地址”“NTP 服务器地址”等作为变量，按设备角色套用不同模板。例如接入交换机模板中，管理 ACL 只允许运维网段访问；边界路由器模板中，还需额外要求启用 uRPF 或 ACL 过滤。
同时要建立例外管理机制。某些端口因业务需要必须保持默认 VLAN，某些旧设备暂时无法启用 TACACS+，这些情况不能简单判为“不合规”后长期挂起，而应登记为例外：记录例外对象、原因、批准人、到期时间。合规检查时，命中有效例外的项标记为“已批准例外”，到期后自动恢复为不合规。这样基线才不会被大量“历史遗留”噪声淹没。
五、一个可执行的基线定义片段
下面给出 Arista EOS 上“AAA 与日志”模块的基线断言示例，可直接作为检查脚本的输入。示例中的 IP 与团体字为教学假设值。
# 基线断言：AAA 与日志（示例）
aaa_assertions:
- id: AAA-001
desc: "必须使用 TACACS+ 集中认证"
expect: "aaa authentication login default group tacacs+ local"
- id: AAA-002
desc: "enable 认证必须走 TACACS+ 并保留 local 回退"
expect: "aaa authentication enable default group tacacs+ local"
- id: AAA-003
desc: "本地账号密码必须加密存储"
expect_regex: "^username \\S+ privilege \\d+ secret sha512 .+"
- id: LOG-001
desc: "必须外发 syslog 至日志服务器"
expect: "logging host 10.30.0.20"
- id: LOG-002
desc: "日志级别不高于 informational"
expect: "logging trap informational"
- id: LOG-003
desc: "必须记录配置变更"
expect: "logging level config informational"定义完成后，建议先用一台已合规的“金标准设备”导出配置，反向验证断言是否全部通过；再用一台存在已知偏差的设备验证断言能否准确报出偏差。只有断言本身经过验证，基线才具备可信度。基线不是一次写死的文档，而应随业务变更、标准更新和例外到期持续修订，通常每季度或每次重大变更后复核一次。