（本文基于电力监控系统现场测评经验整理，内容已做脱敏处理，不涉及具体项目与客户信息。）

变电站监控系统（SCADA）的等保测评，和测评一套 OA、一个业务平台完全是两码事。三个特殊之处决定了它难做：

• 不能停机：变电站 7×24 运行，牵一发动全身，主动扫描类测试基本没得做；
• 不能随便装东西：大量嵌入式装置、工业交换机、测控保护设备，装不了 Agent、跑不了扫描器；
• 行业要求叠加：除了等保，还压着《电力监控系统安全防护规定》（发改委 14 号令）的"安全分区、网络专用、横向隔离、纵向认证"十六字方针，两套要求要一起看。

下面按现场工作顺序，整理 7 个最容易翻车的点，每个都给判定思路和取证方法。

坑 1：测评对象边界漏资产——这个坑一踩，整份报告白做

现象：进场后只把"监控后台软件"当成一个应用系统来测，主机层面只覆盖了监控主机。测完发现漏了一大半。

实际上站内属于测评范围的通常包括：

判定依据：GB/T 22239 关于测评对象确定的原则，加上电力监控系统安全防护总体方案对资产的划分口径。

实操建议：进场第一件事做资产核实，把业主台账、拓扑图、屏柜标签三方对照。对不上的当面确认，千万别按图索骥——业主的拓扑图往往几年没更新，设备换过、拆过、加过都不一定体现。

坑中坑：智能变电站的合并单元、智能终端、过程层交换机算不算测评对象，不同地区监管口径有差异。这块别自己拍板，提前和业主、监管方沟通确认，写进测评方案里。

坑 2：分区划错，把生产控制大区当管理信息大区测

现象：整个变电站按一个等保定级来做，或者安全 I 区和 II 区混着测，边界根本没理清。

正确的分区逻辑（十六字方针的第一条）：

• 控制区（安全区 I）：实时监控系统，如变电站监控系统（SCADA）、远动系统；
• 非控制区（安全区 II）：非实时生产系统，如继保信息子站、调度数据网非实时业务；
• 管理信息大区：办公、综合数据网。

常见问题：业主提供的定级报告是集团统一定级的结果，与本站实际部署存在差异——比如某套系统按集团口径定在安全 II 区，但现场实际接在安全 I 区网络上。

现场动作：先画一张物理分区图再干活——哪个机柜、哪台交换机、哪个 VLAN 属于哪个区，全部落到纸面上，然后与定级报告的边界逐条比对。这一步不做，后面"安全区域边界"和"安全通信网络"两章根本没法判。

特别提醒：安全 I 区和 II 区之间也是横向边界，同样需要隔离措施，很多人只盯大区边界，把这条漏了。

坑 3：横向隔离装置"在册不在线"

现象：拓扑图上，生产控制大区与管理信息大区之间清清楚楚标着正/反向隔离装置，实际到现场一看——设备在，但被旁路了、网线被拔了、或者干脆用一台普通防火墙顶着。

怎么查：

1. 登录设备管理口，看运行状态和转发模式；
2. 找替代链路：机柜里、桥架上看有没有私接的网线绕过隔离装置（这是最常见的规避手段）；
3. 查交换机 MAC 地址表，看是否存在跨区直连的通信；
4. 访谈运维人员："上一次通过隔离装置传数据是什么时候？"

判定尺度：这一条没有补偿余地。按规定，生产控制大区与管理信息大区之间必须部署电力专用横向单向安全隔离装置，这是硬性要求，缺项就是不符合。

顺带记一条规则：严格禁止 E-Mail、WEB、Telnet、Rlogin、FTP 等通用网络服务，以及 B/S、C/S 方式的数据库访问穿越横向单向隔离装置，只允许纯数据的单向安全传输。现场发现有人在隔离装置另一侧开 Web 服务，直接就是问题项。

坑 4：纵向加密装置证书过期，没人管

现象：纵向加密认证装置部署了、隧道也在跑，但数字证书早就过期；或者仍在用已经不适用的算法套件。

为什么这是重灾区：运维只管"隧道通不通"，不关心证书有效期。而这一条恰恰是密评的核心密码项——通信传输的机密性、完整性，以及通信主体的身份鉴别，全靠它。证书过期，直接冲击"有效性"维度的判定。

现场核查四件事：

1. 证书有效期（登录装置看在用证书的起止时间）；
2. 算法套件是否为 SM2/SM3/SM4 系列国密算法；
3. 隧道是否真的在用加密模式运行；
4. 是否长期处于旁路模式——旁路是设备故障时的降级方案，默认设计就是"网络直通"。长期旁路等于通信全程无保护，这一条在密评里非常致命，一旦发现基本判不符合。

坑 5：默认口令 + 共用账号——全场最普遍的问题

现象：监控后台、测控装置、工业交换机大量保留出厂默认口令；运维习惯用共用账号（"admin""operator""guest"）登录，一个账号几个人用。

难点在这里：很多嵌入式装置（测控、保护类）确实不支持口令复杂度校验和登录失败锁定，不是运维不做，是设备没这能力。

所以判定要分层次：

• 设备有能力但未开启→ 判不符合，要求整改；
• 设备确实不支持→ 判部分符合，给出补偿措施（管理制度 + 物理访问控制 + 网络层监测），并在报告里说明客观限制。

取证方法：现场访谈 + 抽查登录验证 + 截图后台账号列表。抽账号列表时特别看"创建时间相同、最后登录时间相同"的几个账号——那基本就是共用账号。

一个现实判断：口令复杂度、登录失败处理、会话超时这三条，在电力现场想全达标很难。别为了报告好看硬判符合，一线运维一试用就露馅，报告的可信度反而受损。

坑 6：SCADA 的"日志"不等于安全审计（最容易被厂商打哈哈的地方）

现象：访谈时厂商很自信："我们系统有完整的日志功能，所有操作都能查。"

翻一下就知道——他说的日志是 SOE 事件顺序记录、遥控/置牌/定值操作记录、通信报文、告警记录。这些确实是记录，也确实带时标，但它们服务的是事故分析和运行运维，回答的是"设备发生了什么"，不是"谁通过什么方式访问了系统、是否属于异常行为"。

缺的是这四样：

必须分层核查，不能只看一层：

• 应用层：后台自身的操作日志覆盖范围；
• 操作系统层：`auditd` 是否开启、`auditctl -l` 有没有规则（服务跑着但规则为空＝没审计）、`rsyslog` 有没有配置远程转发；
• 数据库层：是否安装审计插件（很多现场是完全没装）；
• 网络层：交换机、防火墙、安防设备是否上报 syslog。

判定：审计覆盖、审计记录保护、审计进程保护三条分别核查。只靠系统自带日志，通常只能判部分符合或不符合——不能因为"系统有日志功能"就放过去。

坑 7：不能停机、不能扫描，脆弱性测试怎么做

这是实施层面最尖锐的矛盾：等保要求做脆弱性测试，但变电站不能断、不能扫。

处理原则：

1. 书面约定测试范围。测前与业主确认哪些可以做、哪些只能看不能碰，落到测评方案里双方签字；
2. 用配置核查替代主动扫描。版本比对、配置检查、访谈，能覆盖大部分脆弱性判断；
3. 必须扫描的（比如后台服务器），安排在备用系统、检修窗口，或用"离线镜像 + 离线核查"的方式；
4. 报告里写清方法受限的原因。这一点很重要——不写会被质疑"脆弱性测试不到位"，写了才是专业表现。

别做的事：直接拿扫描器怼生产网。一次误伤可能就是一次真实的停电事故，这个责任谁都担不起。

两个附加提醒

外委人员与移动介质管控。现场运维外包很普遍，外委人员带的笔记本、U 盘接调试口（网口/串口）是电力二次安防的重点关注项。核查点：是否使用专用调试笔记本、USB 口是否封堵、调试口权限是否有记录。行业对这一条有明确要求，别漏。

时间同步。站内各设备是否统一 NTP 对时，直接决定跨设备事件能不能排序、能不能做关联分析。另外数据库层如果 `log_timestamps` 设成 UTC，排查时每次都要换算，容易出错——这类小配置在现场很常见，顺手记进问题清单。

三条经验总结

1. 进场先做资产核实，别信拓扑图。文档和现场不一致是常态，资产漏了后面全白做；
2. 分区边界要现场画。坐在办公室看定级报告是画不出真实边界的，得去机柜前站着看线怎么走；
3. 分层取证，别接受口头承诺。厂商说"我们有这个功能"，就让他现场打开给你看——应用层、操作系统层、数据库层、网络层，一层一层过。

变电站监控系统的等保测评，技术难度其实不算高，难的是在现场约束条件下把该看的都看到。把上面这几个坑避开，报告质量和现场效率都会好很多。

（本文为个人工作经验整理，不代表任何机构立场；具体判定请以现行标准原文和主管部门要求为准。）

本文为 独立观点，未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件，请联系 FreeBuf 客服小蜜蜂（微信：freebee1024）