1. 课程导入与安全基线全景

在数据中心网络里谈“安全”，最容易出现的误区是把安全等同于“加一台防火墙”或“在边界上做ACL”。Arista数据中心的安全基线并不是某一台设备的某个功能，而是一组可验证、可重复、可审计的配置与运行状态集合：它规定了交换机在出厂交付、上线投产、日常运维三个阶段分别应当处于什么状态，哪些能力必须开启，哪些默认行为必须收敛，以及访问控制在其中扮演什么角色。理解这条基线，是后续所有ACL、控制平面保护、AAA、TACACS+、SSH加固、日志审计等具体操作的共同前提。

一、安全基线的定义与边界

安全基线（Security Baseline）可以定义为：针对特定设备角色与软件版本，为达成最低可接受安全水平而必须满足的一组配置项、运行状态与验证方法的总和。它有三个关键限定词。

• 针对设备角色：Spine、Leaf、Border Leaf、管理交换机承担的功能不同，基线也不同。例如Border Leaf需要更严格的对外ACL与路由过滤，而纯管理交换机更关注管理面隔离。
• 针对软件版本：EOS不同大版本在默认行为、可用命令、推荐实践上存在差异，基线必须绑定版本，否则“合规”无从谈起。
• 最低可接受：基线不是安全上限，而是下限。它保证设备不会因为“忘了改默认口令”“管理面暴露在业务网段”这类低级问题成为攻击跳板。

需要明确的是，基线不等于加固手册的全部内容。基线回答的是“必须做到什么”，而加固手册往往还包含“建议做到什么”。在工程实践中，把二者混在一起会导致基线过于庞大、无法自动化校验，最终形同虚设。

二、目标：从“能通”到“可控、可查、可收敛”

数据中心网络的传统目标是连通性与性能，安全基线要在此基础上叠加三个目标。

可控：任何对设备的访问都必须经过身份认证与授权，且权限与角色匹配。管理访问不能依赖“知道密码就能进”，而应通过AAA与TACACS+实现集中认证、命令级授权和操作审计。控制平面协议（如OSPF、BGP、MLAG、STP）也必须受到保护，避免伪造邻居、注入路由等攻击。

可查：设备必须留下足够且可信的痕迹。日志要能回答“谁、在什么时间、从哪个源IP、执行了什么命令、结果如何”。这要求日志时间同步（NTP）、日志外送（Syslog/流式遥测）、以及关键事件的告警联动。

可收敛：当出现异常配置漂移或安全事件时，能够快速定位并恢复到基线状态。这依赖配置备份、版本对比、以及基于意图的自动化校验。没有收敛能力的基线，只是一次性的检查表。

三、合规驱动因素：为什么现在必须做

推动Arista数据中心安全基线落地的因素通常来自四个方向。

• 等保与行业监管：国内金融、运营商、政企客户普遍要求网络设备满足身份鉴别、访问控制、安全审计、入侵防范等控制项，基线是这些控制项在设备层面的具体映射。
• 供应链与交付要求：越来越多项目在验收阶段要求提供设备安全配置核查报告，基线成为交付物的一部分。
• 内部风险治理：数据中心内部东西向流量巨大，一旦某台Leaf被攻陷，攻击者可能横向移动。基线通过管理面隔离、控制平面保护、最小权限访问来压缩横向移动空间。
• 自动化运维需求：只有把安全要求写成可校验的基线，才能用脚本或工具批量检查数百台交换机，否则人工核查无法持续。

四、访问控制在基线中的定位

访问控制是安全基线中最基础、也最容易被低估的一层。它并不只是“在接口上放一条ACL”，而是贯穿管理面、控制面、数据面三个平面的访问关系定义。

在管理面，访问控制决定谁能通过SSH、eAPI、SNMP访问设备，以及能执行哪些命令。典型做法是：管理接口放入独立管理VRF，仅允许运维网段访问，配合TACACS+做命令授权。在控制面，访问控制通过CoPP（Control Plane Policing）和协议认证，限制发往CPU的流量速率与来源，防止路由协议被伪造报文干扰。在数据面，访问控制通过ACL、VLAN划分、VRF隔离，限制服务器之间、租户之间的非必要通信。

把访问控制放在基线全景中看，它承担的是“入口收敛”和“路径约束”两个职责：入口收敛让攻击面从“全网可达”缩小到“少数受控入口”；路径约束让即使某个入口被突破，攻击者也无法自由横向移动。后续章节中的ACL语法、方向选择、隐式拒绝、日志命中、以及基于角色的访问控制，都是在这一定位下展开的具体手段。

五、一个可落地的基线检查示例

为了让“基线”不停留在概念层面，下面给出一个针对Leaf交换机的管理面基线检查片段。它可以直接作为人工核查或自动化脚本的输入。示例中的参数属于教学假设，实际项目应根据管理网段规划替换。

# 管理面基线检查（示例，假设管理网段为 10.10.0.0/24）
# 1. 管理接口是否位于独立VRF
show vrf | include MGMT

# 2. 是否仅允许运维网段SSH访问
show ip access-lists MGMT-IN
# 期望：permit tcp 10.10.0.0/24 any eq 22
#       隐含拒绝其余

# 3. AAA与TACACS+是否生效
show aaa authentication
show tacacs

# 4. 是否禁用Telnet与未用服务
show management api http-commands
show running-config | include telnet

# 5. 日志与时间同步
show ntp status
show logging | include host

判断依据很直接：如果第2项中出现了permit ip any any，或第4项中Telnet仍处于启用状态，则管理面基线不通过。这类检查项应当被固化为脚本，在每次变更后自动执行，而不是依赖人工记忆。

六、基线落地的常见误区

第一个误区是“一次性配置”。很多团队在设备上线时做了一次加固，之后不再复核，配置漂移无人发现。第二个误区是“只做管理面”。管理面加固能挡住外部扫描，但挡不住已进入业务网段的攻击者，控制面与数据面的访问控制同样必要。第三个误区是“基线越全越好”。把大量建议项塞进基线，会导致校验脚本复杂、误报率高，最终被运维团队绕过。合理的做法是区分“必须项”与“建议项”，必须项进入自动化校验，建议项进入评审清单。