变电站工控安全防护与等保三级合规：自动化安全测评与防护怎么做
某 220kV 变电站的自动化系统上线三年，安全措施清单看起来齐全：分区隔离做了、防火墙配了、主机加固做了、日志留存也做了。等到等保三级测评进场，测评方在自动化专机上做了一组操作------拔掉网线、改掉系统时间、用一个普通运维账号尝试访问监控后台的数据文件 。三个动作下来，出现了三个不符合项：核心控制软件的版本没有签名校验、系统日志可以被本地管理员直接删除、监控数据库的数据文件在磁盘上是明文。
这三项的共同点是：它们都不在"配置清单"上，只在"实际状态"里。 这就是为什么工控系统的等保三级，靠翻配置截图是做不过去的。
全文结构：
- 一、先对齐三套要求：等保三级、电力防护导则、密评
- 二、定级与测评对象如何界定
- 三、技术维度：四个层面的防护与取证
- 四、应急备用维度：不停机也要能兜住
- 五、安全管理维度：容易被忽略的另一半
- 六、密码支撑：国密算法落到哪些环节
- 七、自动化安全测评怎么组织：四个阶段
- 八、九类高频不符合项
- 九、验收清单
一、先对齐三套要求：等保三级、电力防护导则、密评
变电站自动化系统的合规，要同时满足三套要求，它们问的问题不一样，但最终都会落到同一套设备上。
| 要求体系 | 核心文件 | 它在问什么 | 与另外两套的关系 |
|---|---|---|---|
| 等级保护 2.0 | GB／T 22239-2019《信息安全技术 网络安全等级保护基本要求》、GB／T 28448-2019《信息安全技术 网络安全等级保护测评要求》 | 系统整体有没有达到三级强度 | 覆盖技术与管理全项，是基础框架 |
| 电力监控系统防护 | GB／T 36572-2018《电力监控系统网络安全防护导则》 | 电力行业特有的防护结构是否成立 | 行业专用，细化分区、隔离、纵向认证等要求 |
| 密评 | GB／T 39786-2021《信息安全技术 信息系统密码应用基本要求》、GB／T 43206-2023《信息安全技术 信息系统密码应用测评要求》 | 密码有没有真正用起来、用得合规 | 聚焦密码这条技术线，是等保的深化 |
三套要求的关系可以这样理解：等保三级问"整体够不够强"，电力防护导则问"结构对不对"，密评问"密码真不真"。 三者不互相替代，也不互相免除。
还需要提到一份工业控制领域的通用参考：GB／Z 41288-2022《信息安全技术 重要工业控制系统网络安全防护导则》，它把电力行业形成的防护框架思路推广到了其他重要工控领域。如果你是发电、化工、水务等其他工控场景的读者，这份文件的框架思路可以直接借用，只是具体条款要回到本行业的要求上。
1.1 为什么"自动化安全测评"这个词值得单独说
变电站的测评有两个特点，决定了它和一般信息系统的测评很不一样：
- 不能靠停机做全量验证。 变电站监控系统的可用性要求高，测评方不会为了验证一个加密措施就把生产系统停掉。所以大部分验证必须在运行态下完成，这倒过来要求防护措施本身要能"边运行边自证"。
- 验证动作自动化程度高。 测评方会用一批脚本化的手段做基线核查：端口扫描、弱口令探测、配置基线比对、日志完整性校验、数据形态检索。既然对方是自动化查，自查就不能是人工看。
这一条带来一个很实际的建议：自查阶段就把测评方的自动化动作自己先跑一遍。 本节第七部分会给出组织方式。
二、定级与测评对象如何界定
定级定错了，后面所有工作量都会错位。
2.1 变电站监控系统按整体定级
按电力行业的通行做法，变电站监控系统中的现场采集/执行、现场控制、过程控制等要素应作为一个整体对象定级，各要素不单独定级。生产管理类要素（管理信息大区）宜单独定级。
这个规则的实际影响是：不能把"监控后台"单独拿出来定级、把"测控装置"甩在范围外。测控装置所在的网络、装置本身的身份鉴别、装置与后台之间的通信，都在同一个测评对象的范围里。
2.2 测评对象的边界要怎么划
实际操作中，边界划分通常按"安全区 + 业务功能"两个维度落。
| 维度 | 划分方式 | 划错的后果 |
|---|---|---|
| 安全区 | 按控制区（安全区Ⅰ）、非控制区（安全区Ⅱ）、管理信息区分别界定 | 边界过宽会把大量无关资产纳入，工作量失控；边界过窄会漏掉关键环节 |
| 业务功能 | 按"数据采集---控制执行---监视告警---数据存储"的功能链条界定 | 只按资产清单划，容易漏掉跨系统调用的链路 |
一个高发问题 ：新能源场站（风电、光伏）里，安全区Ⅰ与安全区Ⅱ经常通过一台部署在安全区Ⅰ的通信服务器与集控中心或调度通信。这台服务器同时跨了两个安全区的业务，如果边界划分时没有把它和两个区之间的关系讲清楚，测评时会被直接判定为"区域间隔离措施不明确"。
三、技术维度：四个层面的防护与取证
GB／T 36572-2018 把安全防护技术拆成四个部分：基础设施安全、体系结构安全、监控系统本体安全、可信安全免疫。下面按这个框架展开，每部分给出"要求---典型差距---防护动作---取证材料"四段。
3.1 基础设施安全
要求：机房与设备部署要符合分区原则，密码基础设施要通过行业检测认证。
典型差距：
- 生产控制大区与管理信息大区的机房没有独立设置；
- 设备物理位置与它所属的安全区不一致（比如本该在生产区的装置被放在了普通机房）；
- 密码基础设施只做了通用商用密码产品认证，没做电力行业的检测认证。
防护动作：
- 按安全区把设备位置梳理一遍，逐台核对"设备所属安全区"与"机房所属安全区"是否一致；
- 对物理出入控制，按机房等级分别设置门禁强度，等级较高的区域增加一道门禁；
- 密码基础设施补做行业检测认证，认证依据要能对上。
取证材料：机房平面图与安全区标注对照表、设备位置台账、门禁记录、密码设备的检测认证证书。
3.2 体系结构安全
这是电力行业特色最集中的一层，核心是"安全分区、网络专用、横向隔离、纵向认证"十六字结构的落实。
要求：分区正确、网络专用、横向有隔离、纵向有认证。
典型差距：
| 差距类型 | 具体表现 |
|---|---|
| 分区交叉 | 不同安全区之间存在直连，或共用网络设备 |
| 逻辑隔离缺失 | 生产控制大区内部安全区之间，没有工控协议层的访问控制与规约检查 |
| 单向隔离强度不足 | 生产控制大区与管理信息大区之间用了普通防火墙做双向转发 |
| 纵向策略过粗 | 纵向加密认证装置的隧道策略没有细化到业务 IP 与端口 |
| 协议措施缺失 | 存在默认路由、未按业务划分 VLAN、边界路由功能未关闭 |
防护动作：
bash
# 自查思路：先把"网络到底怎么连的"用可复现的方式固定下来
# 目的不是配置，而是拿到一份能在现场摆出来的连接关系图
# 1) 梳理网络设备的接口与 VLAN 划分（以实际设备命令为准，此处为思路示例）
# 输出：接口 → VLAN → 所属安全区 的对应关系
show vlan brief
show running-config interface
# → 逐条核对是否存在跨安全区共用 VLAN
# 2) 核对路由配置，确认没有默认路由、边界路由功能已关闭
show ip route
# → 若存在 0.0.0.0/0 默认路由，需说明业务必要性与替代方案
# 3) 核对纵向加密认证装置的隧道与策略配置
# 关注点：隧道是否为密通状态、策略是否细化至业务 IP 与端口
# → 具体查看命令以装置厂商文档为准，不要凭印象手写指令
# 4) 采集边界流量，验证隔离装置的实际作用
# 关注点：隔离装置两侧是否存在穿透性通信
tcpdump -i eth0 -w /tmp/boundary_$(date +%Y%m%d).pcap host $PEER_IP
# → 分析与隔离策略是否一致，作为现场举证材料留存取证材料：网络拓扑与安全区对应图、VLAN 与接口台账、路由配置导出、隔离装置与纵向加密认证装置的策略导出、边界流量采集记录。
3.3 监控系统本体安全
要求：系统软件、操作系统与基础软件、计算机与网络设备、电力专用监控设备、核心处理器芯片，应采用安全可控可靠的产品并通过检测认证；运行中要合理配置身份鉴别、访问控制、安全审计。
典型差距：
- 身份鉴别停留在账号口令：操作站、后台机、工程师站大量使用共享账号或弱口令；
- 访问控制粗放：一个运维账号能访问所有业务数据；
- 审计形同虚设：日志本地存放、可被本地管理员删除、无完整性保护；
- 端口与介质未管控：空闲网络端口未封闭，移动存储接口未管理；
- 补丁管理不合规：通过互联网在线更新或从不更新。
防护动作：
- 身份鉴别升级为双因素：操作系统登录与业务系统登录都要有"口令 + 硬件凭证"两层，硬件凭证的私钥不可导出，拔除即断开会话；
- 访问控制按角色重构：把账号按业务角色重新划分，运维账号与业务账号分离，运维账号默认看不到业务数据明文；
- 审计日志外送：日志实时送到独立日志服务器，本地删除不影响留存副本；
- 端口与介质管控：封闭空闲网络端口，保留必要 USB 端口并做接口管控；
- 补丁离线更新：建立离线补丁测试与分发流程，禁止通过互联网在线更新。
取证材料：账号清单与权限矩阵、双因素认证的实测记录、日志服务器留存记录、端口封闭与介质管控的现场照片或配置导出、补丁更新记录。
3.4 可信安全免疫
要求：关键控制软件应采用数字证书签名并送检，生产控制大区禁止未包含厂商与检测机构签名版本的可执行代码启动；有条件时推广以密码硬件为核心的可信计算技术，实现静态与动态安全免疫。
典型差距：这一层是四个层面里落地最薄的一层。常见情况是：
- 控制软件的更新包没有签名校验机制，靠人工比对文件哈希；
- 厂商远程升级时直接拷贝可执行文件到现场，没有验签环节；
- 系统的静态度量与动态度量都没有部署。
防护动作：
bash
# 自查思路：确认"当前运行的程序是不是可信版本"
# 关键是把"版本管理"做成可验证的机制，而不是靠人记事
# 1) 建立关键控制软件的可执行文件基线（在可信状态下采集一次）
find /opt/control/ /opt/hmi/ -type f -executable -print0 \
| xargs -0 sha256sum > /etc/baseline/exec_sig_baseline_$(date +%Y%m%d).txt
# → 基线文件本身要做完整性保护，并离线留存一份
# 2) 日常核验：与基线比对，找出被替换或新增的可执行文件
sha256sum -c /etc/baseline/exec_sig_baseline_20260901.txt 2>&1 | grep -v ": OK"
# → 输出中出现的文件即为与基线不一致的项，需逐个核实来源
# 3) 升级包验签：以厂商提供的签名校验工具为准
# 验签不通过的升级包，禁止在生产控制大区执行
$VERIFY_TOOL verify --package ./upgrade_pkg.bin --pubkey ./vendor_pub.pem
# → 具体命令以厂商文档为准；核心是"未经签名的可执行代码不得启动"取证材料：可执行文件基线文件、日常核验记录、升级包验签记录、厂商与检测机构的签名材料。
3.5 四个层面的自查顺序建议
| 顺序 | 层面 | 为什么这个顺序 |
|---|---|---|
| 1 | 体系结构安全 | 网络结构不改对，后面所有措施都可能白做 |
| 2 | 基础设施安全 | 与结构强相关，可同步梳理 |
| 3 | 本体安全 | 工作量最大，可在结构确定后批量推进 |
| 4 | 可信安全免疫 | 依赖前三个层面的资产台账，放最后做效率更高 |
四、应急备用维度：不停机也要能兜住
GB／T 36572-2018 的第二维是应急备用措施，包含冗余备用、应急响应、多道防线。这一维在工控场景里的特殊意义是：技术防护一定会被突破，关键是被突破之后系统还能不能转。
4.1 冗余备用要回答三个问题
- 备得起来吗：关键节点（通信服务器、监控后台、关键装置）是否有冗余，切换是自动还是手动；
- 备的是不是同一份风险：主备设备是否共用同一套配置源、同一个电源、同一条通道------共用的话，一次事件会同时打掉主备；
- 切换可验证吗：有没有定期切换演练记录，切换耗时是多少。
4.2 应急响应要落到"有预案、有演练、有记录"
预案的关键内容不是流程描述，而是恢复目标：
| 要素 | 要明确的内容 |
|---|---|
| 恢复时间目标 | 关键业务在多长时间内必须恢复 |
| 恢复点目标 | 最多允许丢失多长时间的数据 |
| 处置权限 | 谁有权在应急状态下执行隔离、下线、切换操作 |
| 外部协同 | 与调度、厂商、监管的通报与协同路径 |
| 演练记录 | 每次演练的时间、场景、结果、改进项 |
4.3 多道防线要能"独立起作用"
多道防线的常见问题是"看起来很多道，实际上是一道"。比如：
- 边界防火墙与内部访问控制使用同一套规则库 → 规则出错时两道同时失效；
- 数据加密与备份使用同一套密钥 → 密钥丢失时数据和解密能力同时失去；
- 身份认证与权限管理共用同一套账号体系 → 账号泄露一次穿透全部。
判定方法：逐道防线问"如果它失效了，下一道能不能独立拦下来"。答"不能"的，就不是独立的多道防线。
五、安全管理维度：容易被忽略的另一半
第三个维度是全面安全管理。它容易被当成"写材料"，但测评现场的核查方式其实是拿制度去对实际。
| 管理方向 | 要求 | 现场核查方式 | 典型失分点 |
|---|---|---|---|
| 融入安全生产管理体系 | 网络安全要求纳入既有电力安全生产体系 | 查是否有正式发布的管理文件、职责是否到岗到人 | 只在安全部门内部执行，生产部门不知情 |
| 全体人员安全管理 | 覆盖全员，含外委与厂商人员 | 查培训记录、保密与授权记录、外来人员管理记录 | 外包运维人员无授权记录 |
| 全部设备及系统的安全管理 | 台账完整，含装置、终端、介质 | 抽查台账与实物是否一一对应 | 台账与实物对不上，报废设备未销账 |
| 全生命周期安全管理 | 覆盖规划、开发、建设、调试、改造、运行、退役 | 抽一个环节查过程记录 | 退役环节基本无记录，旧设备与介质直接弃置 |
这四个方向里，最容易被低估的是"全部设备及系统"。 变电站的设备台账往往由不同专业分别维护，自动化专业有一份、通信专业有一份，两份对不上是常态。而测评方抽查的方式恰恰是随机抽几台实物，去台账里找------找不到就是不符合项。
六、密码支撑：国密算法落到哪些环节
等保三级有密码相关的技术要求，密评则把这个要求展开成完整的测评体系。落到变电站的具体环节，通常是这几个落点：
| 环节 | 密码技术 | 国密算法 | 要解决的问题 |
|---|---|---|---|
| 人员登录 | 身份鉴别 | SM2 数字签名 / SM3 摘要 | 操作者身份真实、不可否认 |
| 设备身份 | 双向认证 | SM2 证书体系 | 装置与后台互相确认身份 |
| 通信保护 | 加密与完整性 | SM4 加密 + SM3 完整性 | 传输途中不被窃听篡改 |
| 数据存储 | 存储加密 | SM4 加密 | 数据文件被拿走也读不出明文 |
| 审计记录 | 完整性保护 | SM3 或带密钥的完整性校验 | 日志被本地篡改可被发现 |
| 程序与升级包 | 签名验签 | SM2 签名 | 未授权代码不得启动 |
| 密钥管理 | 分层密钥体系 | ------ | 密钥在谁手里、怎么轮换、如何留痕 |
6.1 三个容易做浅的地方
其一，只有"加密功能"，没有"密钥管理"。 很多现场部署了加密能力，但密钥存放在应用配置文件中、由应用账号可读、从不轮换。这等于把钥匙贴在锁上。
其二，只保护传输，不保护存储。 纵向加密认证装置保护的是通道。数据从主站同步到站内本地库、从实时库落到磁盘、从生产区备份到管理区，这些环节的数据形态都要单独覆盖。
其三，只做功能部署，不留过程记录。 密码相关的操作（密钥产生、分发、轮换、销毁，签名与验签）如果没有记录，或者记录本身没有完整性保护，在密码管理单元的现场核查里是拿不出证据的。
6.2 工程落点
把上面七个环节收成工程能力，通常是这样组织的：身份方面 以硬件凭证承载签名密钥，密钥不可导出，配合操作系统与业务系统的双因素登录，让"谁在操作"这件事在自动化专机与后台机上都能举证；通信方面 以证书体系完成装置与主站之间的双向认证，传输过程用国密算法加密并做完整性校验；数据方面 在存储层完成数据落盘加密，业务应用与历史数据查询工具无需改造，使"数据是不是明文落盘"这一项可以用可复现的方式现场验证；密钥方面以分层密钥体系承接，根密钥由硬件密码模块保护且不可导出，工作密钥按业务派生并支持轮换，密钥全生命周期操作留痕。安当在变电站这类工控场景的合规改造中，通常把这四块能力与电力行业的分区约束一起设计，避免出现"边界装置齐备、数据仍是明文"这种结构性缺口。
七、自动化安全测评怎么组织：四个阶段
工控场景的测评组织，建议按四个阶段推进。这个节奏的价值在于：把"被查出问题"变成"自己先发现并改完"。
7.1 阶段一：资产与结构梳理（自查）
这一阶段的目标产出是三份东西：
- 资产清单：装置、终端、服务器、网络设备、安全设备，逐台标注所属安全区与责任专业；
- 连接关系图：谁能访问谁，跨区访问的路径是什么，路径上有哪些控制点；
- 数据流清单：数据从哪产生、流向哪、在哪落地、落地形态是什么。
这三份东西是后面所有工作的基础。 缺了它们，测评要么范围失控，要么遗漏关键路径。
7.2 阶段二：基线核查（自查）
把测评方会做的自动化动作自己先做一遍：
bash
# 基线核查的常见动作（在测试环境或授权范围内执行）
# 1) 端口与服务核查：找出非必要开放的服务
ss -tulnp
# → 与业务无关的监听端口即为整改项
# 2) 账号与口令强度核查：找出共享账号、空口令、长期未更换口令
awk -F: '($3>=1000 && $3<65534){print $1}' /etc/passwd
# → 逐个人工确认用途与责任人
# 3) 日志完整性核查：确认本地日志可被篡改的范围
ls -la /var/log/ | grep -iE "control|scada"
# → 若日志文件权限允许普通账号修改，即为整改项
# 4) 数据落盘形态核查：直接读数据文件检索明文
grep -c "PROBE_MARK_0916" /var/lib/db/control_data.dbf
# → 检索到明文即为存储加密缺失
# 5) 可执行文件基线核查：与基线比对
sha256sum -c /etc/baseline/exec_sig_baseline_20260901.txt 2>&1 | grep -v ": OK"
# → 输出项需逐个核实来源每一项的输出都要留档。 留档有两个用途：一是整改依据，二是现场举证材料------"我们自己查过并且改完了"比"我们配置了"更有说服力。
7.3 阶段三：整改与回归
整改要按"影响面"排序，而不是按"发现顺序"。
| 优先级 | 整改类型 | 原因 |
|---|---|---|
| 高 | 结构性问题（分区交叉、隔离强度不足） | 不改则后续措施可能全部失效 |
| 高 | 密码措施缺失（存储未加密、身份鉴别单因素） | 是密评与等保共同的硬项 |
| 中 | 基线类问题（端口、账号、日志权限） | 工作量可控，可批量处理 |
| 中 | 管理类问题（台账、记录、预案） | 依赖流程，需时间沉淀 |
| 低 | 优化类问题（策略细化、冗余路径梳理） | 可在不影响达标的前提下分批推进 |
回归验证是这一步的关键。 每改完一类问题，用阶段二的同一套动作复测一次，把"改前---改后"的对比记录留档。这份对比记录在正式测评时很有用------它证明整改是真实发生的，而不是临时应付。
7.4 阶段四：正式测评准备
正式测评进场前的准备，主要是三件事：
- 材料归集：按测评单元把举证材料整理成索引，现场能快速定位；
- 演示路径确认：哪些关键项现场可以当场复现，提前确认业务侧允许的操作窗口；
- 配合人员明确：自动化、通信、安全各专业的对接人明确，避免现场互相等。
八、九类高频不符合项
按出现频率排列，这九类问题在变电站工控场景的测评中反复出现。
| # | 不符合项 | 通常出现在哪个层面 | 根因 |
|---|---|---|---|
| 1 | 数据文件明文落盘 | 本体安全 / 密码应用 | 把边界装置当成数据加密 |
| 2 | 审计日志可被本地篡改或删除 | 本体安全 | 日志本地存放、无完整性保护 |
| 3 | 操作站存在共享账号或单因素登录 | 本体安全 | 为运维便利牺牲了身份鉴别强度 |
| 4 | 安全区之间隔离措施不明确或强度不足 | 体系结构安全 | 分区划分与设备部署未逐台核对 |
| 5 | 纵向加密认证装置策略过粗 | 体系结构安全 | 策略未细化到业务 IP 与端口 |
| 6 | 关键控制软件无可执行文件签名校验 | 可信安全免疫 | 版本更新靠人工比对，无验签机制 |
| 7 | 密钥由应用账号可读、从不轮换 | 密码应用 | 只有加密功能，没有密钥管理 |
| 8 | 设备台账与实物对不上 | 安全管理 | 多专业分散维护，无统一核对周期 |
| 9 | 应急处置预案无演练记录 | 应急备用 | 预案停留在文件，未形成演练闭环 |
这九项里，第 1、2、6、7 四项的共同特征是"配置看不出来、只有实测才发现"。 它们也是现场被一次性否决概率最高的项。
九、验收清单
变电站工控安全自查与测评准备用。每条给出可验证判据。
| # | 验收项 | 达标判据 |
|---|---|---|
| 1 | 定级正确 | 现场采集/执行、现场控制、过程控制要素作为整体定级，未拆分 |
| 2 | 测评边界清晰 | 安全区边界与业务功能边界均已书面界定，无模糊地带 |
| 3 | 设备位置合规 | 逐台核对设备所属安全区与机房所属安全区一致 |
| 4 | 分区无交叉 | 网络拓扑中不存在不同安全区的直连或共用网络设备 |
| 5 | 逻辑隔离到位 | 生产控制大区内部安全区之间具备协议层访问控制与规约检查 |
| 6 | 单向隔离合规 | 生产控制大区与管理信息大区之间使用符合要求的单向隔离措施 |
| 7 | 纵向策略细化 | 隧道为密通状态，策略细化至业务 IP 与通信端口 |
| 8 | 协议措施落实 | 无默认路由，按业务划分 VLAN，边界路由功能已关闭 |
| 9 | 边界可举证 | 有边界流量采集记录，与隔离策略一致 |
| 10 | 身份双因素 | 操作系统与业务系统登录均为双因素，凭证私钥不可导出、拔除断开会话 |
| 11 | 访问控制按角色 | 运维账号与业务账号分离，运维默认不见业务数据明文 |
| 12 | 日志外送留存 | 日志实时外送独立服务器，本地删除不影响留存副本 |
| 13 | 日志完整性 | 日志具备完整性保护，本地篡改可被发现 |
| 14 | 数据加密覆盖 | 存储层加密覆盖主库、备库、备份、归档与快照 |
| 15 | 数据形态可验证 | 停库直读数据文件检索不到敏感数据明文，有验证留档 |
| 16 | 密钥分层与保护 | 根密钥由硬件密码模块保护且不可导出，工作密钥可轮换 |
| 17 | 密钥与数据分离 | 拿到数据所在环境的完整控制权，无法自行解密 |
| 18 | 密钥取用留痕 | 每次密钥取用产生审计记录且不可本地篡改 |
| 19 | 程序签名校验 | 关键控制软件有可执行文件基线与升级包验签机制 |
| 20 | 端口与介质管控 | 空闲网络端口封闭，移动存储接口受控 |
| 21 | 补丁离线更新 | 有离线补丁测试与分发流程，无互联网在线更新 |
| 22 | 密码基础设施认证 | 密码设备的检测认证包含行业要求，依据可核对 |
| 23 | 冗余独立有效 | 主备设备不共用配置源、电源与通道，有切换演练记录 |
| 24 | 多道防线独立 | 逐道验证：上一道失效时下一道能独立拦下 |
| 25 | 应急恢复目标明确 | 恢复时间目标与恢复点目标已量化并经过验证 |
| 26 | 应急演练闭环 | 有演练记录与改进项闭环记录 |
| 27 | 设备台账一致 | 随机抽查实物与台账一一对应，含介质与报废设备 |
| 28 | 全生命周期留痕 | 规划到退役各环节均有过程记录，退役环节不缺失 |
| 29 | 全员覆盖 | 含外委与厂商人员的培训、授权、记录齐备 |
| 30 | 现场可复现 | 关键项均可现场复现，非仅文档声明 |
变电站工控安全的合规，最容易走的两条弯路是：把"配置齐全"当成"状态达标" （清单上每一项都有，实测才发现数据是明文、日志能删、程序没验签），和把"三套要求"当成"三遍重复劳动"（等保、电力防护导则、密评各做一套材料，互相不对应）。
省力的做法是把三套要求叠在同一套资产与结构上对齐：用体系结构层面确定"边界与结构"，用本体与可信层面确定"设备与数据的状态"，用密码这条线把身份、通信、存储、程序四类保护串起来，最后用管理层面把前面所有的动作沉淀成记录。 这样一份投入同时支撑三套要求，也才能在自动化测评进场时，把"我们做了什么"直接变成"现场能跑一遍"。
你们的变电站自动化系统自查时，最先暴露的是哪一类------数据形态、日志完整性，还是程序签名？测评现场被追问最多的是体系结构还是本体安全？评论区聊聊，一起排排雷。
文章作者：安当加密技术负责人