3. 配置基线标准设计
配置基线不是“把一台设备当前 running-config 存下来”，而是把经过评审、可复现、可审计的一组配置状态固化为标准。它要回答三个问题：哪些配置必须进基线（最小安全集）、这些配置按什么维度组织（管理平面/控制平面/数据平面）、以及如何标识和追溯（命名、注释、版本）。本节围绕这三点给出可直接落地的设计方法。
一、最小安全集：基线不可省略的“底线配置”
最小安全集指无论设备角色如何，都必须存在于基线中的配置项。它不追求功能完整，而是保证设备“可管理、可认证、可审计、可恢复”。建议至少覆盖以下六类：
- 身份与认证：本地特权用户、enable secret（使用强哈希）、AAA 认证授权记账指向。
- 远程访问：SSHv2 启用、Telnet 关闭、VTY 仅允许 SSH 并绑定 ACL、exec-timeout。
- 管理面保护：管理 VLAN/SVI 或 Loopback 作为源接口，管理 ACL 限制源网段。
- 日志与时间：logging host、logging trap 级别、NTP 服务器与 clock timezone。
- 基础可用性：hostname、domain name、banner、service password-encryption、no ip http server。
- 恢复能力：archive 配置归档、boot system 指定镜像、配置回滚路径。
下面是一段可直接作为模板的最小安全集片段（示例参数，需按实际环境替换）：
hostname SW-ACC-01
enable secret 9 $9$xxxxx...
aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
ip domain-name corp.example.com
crypto key generate rsa modulus 2048
ip ssh version 2
no ip http server
no ip http secure-server
line vty 0 15
transport input ssh
exec-timeout 10 0
logging synchronous
ntp server 10.10.10.20
clock timezone CST 8
logging host 10.10.10.30
logging trap informational
archive
log config
hidekeys
path flash:archive
maximum 10
二、三平面参数：把基线按职责分层
把配置按管理平面、控制平面、数据平面分层，能让评审者快速判断“这条配置属于谁、影响范围多大”。管理平面关注“谁能管设备”，控制平面关注“设备如何学习与决策”，数据平面关注“流量如何转发”。
| 平面 | 典型参数 | 基线关注点 |
|---|---|---|
| 管理平面 | VTY/SSH、AAA、SNMPv3、NTP、Syslog、管理 ACL | 访问源限制、认证强度、审计完整性 |
| 控制平面 | STP 模式与优先级、OSPF/BGP 邻居与认证、HSRP/VRRP、CoPP | 邻居稳定性、路由收敛、控制面限速 |
| 数据平面 | VLAN、Trunk 允许列表、端口安全、DHCP Snooping、DAI、QoS 分类 | 转发路径明确、二层安全、流量标记一致 |
分层后，基线评审可以按平面逐项确认。例如控制平面中 OSPF 必须启用 MD5/SHA 认证，数据平面中所有用户端口必须启用 portfast 与 bpduguard，管理平面中 SNMP 必须使用 v3 authPriv。这样“最小安全集”与“三平面参数”形成互补：前者是底线，后者是组织框架。
三、命名规范：让对象名自带语义
命名规范的目标是“看到名字就知道角色、位置、序号”。建议采用“站点-角色-序号”结构，全部小写，用连字符分隔，避免空格与特殊字符。例如：
- 设备主机名：
sw-acc-bj01-01（交换机-接入-北京01机房-第1台）。 - VLAN 名称：
vlan-usr-bj01、vlan-srv-bj01，避免使用 VLAN 默认名。 - 接口描述：
to-sw-core-bj01-gi1/0/1，明确对端设备与端口。 - ACL 名称：
acl-mgmt-in-bj01，体现方向与用途。 - 路由协议进程/区域：
ospf-area0-core，与拓扑角色对应。
命名一旦确定，应写入基线模板并纳入变更评审。任何新增对象若不符合命名规则，应在提交前修正，而不是在设备上“先建后改”。
四、注释规范：让配置可读、可审计
注释不是装饰，而是审计线索。Cisco IOS 支持以 ! 开头的注释行，建议在基线中固定使用以下注释块：
! ============================================
! Baseline: BL-SW-ACC-v1.2.0
! Device Role: Access Switch
! Site: BJ01
! Owner: netops@example.com
! Last Change: 2025-06-01 by zhang
! Change Ticket: CHG-2025-0601-001
! ============================================
注释应包含：基线标识、设备角色、站点、责任人、最后变更时间、变更单号。对于关键安全配置，还应在行尾或上方注明“为何这样配”，例如 ! VTY 仅允许管理网段，来源：安全基线 SEC-03。这样在审计或故障复盘时，能快速判断配置意图，而不是靠猜测。
五、版本标识规则：让基线可追溯、可回滚
版本标识建议采用语义化版本：BL-<角色>-v<主>.<次>.<修订>。主版本表示不兼容的结构调整（如三平面分层重构），次版本表示新增功能或参数，修订表示修正错误或注释。例如：
| 版本 | 含义 | 示例变更 |
|---|---|---|
| BL-SW-ACC-v1.0.0 | 首个正式接入交换机基线 | 最小安全集 + 基础三平面参数 |
| BL-SW-ACC-v1.1.0 | 新增控制面 CoPP 策略 | 增加 CoPP 限速模板 |
| BL-SW-ACC-v1.1.1 | 修正 NTP 服务器地址 | 仅参数修正，无结构变化 |
| BL-SW-ACC-v2.0.0 | 三平面分层重构 | 管理面 ACL 与数据面端口安全重新组织 |
每次基线发布，应同时生成三样东西：基线配置文件、版本说明（变更点、影响范围、回滚方法）、以及归档记录。归档建议使用 archive 功能或外部 Git 仓库，文件名包含版本与日期，例如 BL-SW-ACC-v1.2.0_20250601.cfg。回滚时，先对比当前 running-config 与目标基线，确认差异仅来自本次变更，再执行 configure replace 或逐段回退，避免把无关配置一并覆盖。
落地时，建议先用一张基线检查表逐项确认：管理平面是否关闭 Telnet、是否启用 SSHv2 与 AAA；控制平面是否启用邻居认证与 CoPP；数据平面是否启用端口安全与 DHCP Snooping；命名是否符合规范；注释是否包含变更单号；版本是否可追溯。全部通过后，再将这份配置固化为正式基线，并纳入后续变更治理流程。