智能变电站数据安全怎么保障?IEC61850协议防护与调度数据网隔离
智能变电站数据安全怎么保障?IEC61850协议防护与调度数据网隔离
某数字化变电站做等保测评时,测评方在站控层交换机上做了一个镜像口,抓了 30 秒过程层网络流量。把抓包文件拖进分析工具之后,现场安静了几秒——过程层网络上的 GOOSE 报文全部是明文,报文的源 MAC、目的组播地址、数据集名称、跳闸位置状态一目了然。测评方随即用工具把某一条 GOOSE 报文原样重放了一次,接收侧的保护装置照常接收了这条报文。
结论很直接:站内网络里任何一个能接入过程层网口的位置,都具备了伪造跳闸指令的条件。 而这恰恰是智能变电站相对于常规变电站新增的风险面——数字化带来的不只是更快的通信,还有一条谁能接入谁就能说话的共享总线。
全文结构:
- 一、先看清智能变电站的"三层两网"与数据流走向
- 二、站内过程层:SV 与 GOOSE 报文的防护
- 三、站内站控层:MMS 通信的保护
- 四、站间广域:R-GOOSE 与纵向认证的适用边界
- 五、主站与集控侧:数据落地与运维
- 六、密钥怎么发:IED 密钥注入与全生命周期
- 七、调度数据网隔离的落点
- 八、验收清单
一、先看清智能变电站的"三层两网"与数据流走向
智能变电站与传统变电站最大的结构差异,是多了"过程层网络"这一张网。理解数据安全,要先理解数据在哪张网上跑、跑的是什么报文。
1.1 三层结构
| 层次 | 主要设备 | 承担什么 | 数据特征 |
|---|---|---|---|
| 站控层 | 监控主机、工作站、远动装置 | 监视、控制、告警、与调度通信 | 数据量大、时延要求相对宽松 |
| 间隔层 | 保护装置、测控装置 | 保护逻辑、测量与控制执行 | 兼具实时性与业务逻辑 |
| 过程层 | 合并单元、智能终端、电子式互感器 | 采样值采集、开关量采集与执行 | 数据量大、时延要求极紧 |
1.2 两张网
| 网络 | 承载的报文 | 传输层形态 | 典型时延要求 |
|---|---|---|---|
| 站控层网络 | MMS 报文 | 基于 TCP/IP 的客户端-服务端 | 百毫秒量级 |
| 过程层网络 | SV 采样值、GOOSE 开关量 | 原始二层以太网组播 | 毫秒量级 |
"两网"的划分方式,直接决定了两张网的防护手段必须不同。 站控层网络跑的是 TCP/IP,可以直接用成熟的传输层安全机制解决;过程层网络跑的是二层组播,没有 IP 层可以依托,防护只能在网络架构与链路层做文章。
1.3 数据流走向决定了防护要分几段
把数据流按走向切一遍,会得到四个天然的防护段落:
①过程层网络(站内)→ ②站控层网络(站内)→ ③站间广域通道 → ④主站/集控侧
GOOSE/SV MMS/文件 调度数据网 数据落地与运维
这四段的威胁模型不一样,防护手段也不一样。 很多现场的问题出在"只用了一段的手段去覆盖四段"——比如把纵向加密认证装置配得很齐(第三段),但站内过程层网络完全没有隔离管控(第一段),而后者恰恰是攻击者最容易接触到的一段。
二、站内过程层:SV 与 GOOSE 报文的防护
这是智能变电站数据安全最核心、也最难处理的一段。
2.1 先理解约束:3 毫秒预算
IEC 61850-5 对保护类报文规定了严格的传输时间要求,GOOSE 与 SV 报文需要在 3 毫秒量级内完成"产生—传输—接收—处理"的全过程。
这个约束的实际含义是:这 3 毫秒不是留给网络的,是留给发送侧处理、网络传输、接收侧处理三部分的共同预算。
| 预算环节 | 包含什么 | 压缩空间 |
|---|---|---|
| 发送侧处理 | 数据组织、报文构造、(若加密)密码运算 | 密码运算的耗时直接吃掉预算 |
| 网络传输 | 交换机转发、链路时延、排队 | 取决于交换机与拓扑,可优化但有限 |
| 接收侧处理 | 报文解析、完整性校验、逻辑判断 | 校验运算同样吃掉预算 |
这就解释了为什么不能直接给 GOOSE 报文套一层非对称加密。 RSA 或 SM2 这类非对称算法的单次签名运算耗时在毫秒量级,仅这一项就可能把整个 3 毫秒预算占满甚至超出,导致保护动作延迟,这在继电保护场景里是不可接受的。
2.2 站内过程层的三层防护
在时延约束下,站内过程层的防护通常按三层组织。
第一层:网络架构管控——这是性价比最高的一层。
因为 GOOSE 与 SV 是二层组播报文、不可路由,它们天然被限制在同一个广播域内。这一特性既是风险(同域内谁都能发),也是可用之处(只要把广播域管好,就能限制谁能发)。
# 自查思路:把过程层网络的"谁能发、发给谁"固定下来
# 目标产出:一份过程层网络的组播成员关系与控制清单
# 1) 梳理交换机 VLAN 划分,确认过程层网络与站控层网络物理/逻辑分离
# 以实际交换机命令为准,此处为思路示例
show vlan brief
show vlan id $PROCESS_VLAN
# → 确认过程层 VLAN 内不存在站控层设备端口
# 2) 梳理组播成员关系,确认 GOOSE 发布者与订阅者一一对应
# GOOSE 使用以太网组播,目的 MAC 由配置决定
# → 核对每一条 GOOSE 控制块的发布端口与订阅端口是否符合设计
# 3) 配置静态组播过滤,禁止未登记的组播流量转发
# 这一条的价值:即使有设备接入了交换机,它的伪造报文也传不到订阅者
# → 具体命令以交换机厂商文档为准
# 4) 端口安全:未使用端口关闭、接入端口绑定 MAC
# → 防止通过空闲端口接入
第二层:接口与准入管控。
- 过程层交换机的空闲端口全部关闭;
- 已使用端口做 MAC 地址绑定,未登记的设备接入即阻断;
- 交换机管理口与管理网络隔离,管理口令独立设置;
- 站内网线、光模块、调试笔记本纳入介质与设备管理。
第三层:若必须对 GOOSE/SV 报文本身加保护,先做时延预算评估。
这一层的原则是:不超过时延预算为前提。 可行的方向包括:
- 使用对称算法 + 硬件加速的方式,把密码运算下沉到具备线速处理能力的硬件上(如具备并行处理能力的现场可编程门阵列),使附加时延控制在微秒量级;
- 采用认证优先策略:优先保证报文来源可鉴别与完整性可校验,机密性在站内闭合网络中相对次要(报文不出站,被窃听的风险低于被伪造的风险);
- 在改造前先压测:用真实报文规模在测试环境测量引入保护后的端到端时延分布,而不是引用标称值。
这里要明确一点:直接给站内 GOOSE 报文做完整国密加密,目前在工程上需要谨慎评估时延预算,不建议未经测试直接部署。国密算法在智能变电站的落点,更多集中在站控层通信、设备身份、站控层数据存储与调度侧通信上,这一点在后面的章节展开。
2.3 一个必须做的验证:报文重放测试
回到开篇那个现场。测评方之所以能靠"重放一条报文"演示风险,是因为系统缺少最基本的报文新鲜性校验。
# 验证思路:用抓包工具确认站内实时报文是否明文,以及是否可被重放接收
# 注意:该测试必须在测试环境或有明确授权的范围内进行,生产环境操作有风险
# 1) 在站控层交换机镜像口采集过程层网络流量
# 关注点:GOOSE 报文的 goID / datSet / stNum / sqNum 是否明文可见
tshark -i $MIRROR_IF -f "ether proto 0x88b8" -a duration:30 -w /tmp/goose.pcap
# → GOOSE 的 EtherType 为 0x88b8;若报文内容可读,说明为明文
# 2) 观察 GOOSE 的重传与计数逻辑
tshark -r /tmp/goose.pcap -Y "goose" -T fields -e goose.stNum -e goose.sqNum -e goose.timeAllowedtoLive
# → stNum 变化表示状态变化,sqNum 递增表示心跳重传
# → 若接收侧不校验来源与新鲜性,旧报文即可被重放
# 3) 检查接收侧装置的报文来源校验配置
# 关注点:是否校验源 MAC、是否校验 stNum/sqNum 单调性、是否有超时闭锁
# → 具体查看方式以装置厂商文档为准,不要凭印象手写指令
这项验证的价值在于:它把一个抽象的"协议不安全"变成了一个现场能演示、能留档的具体动作。 自查阶段先做一遍,能提前发现"装置侧根本不做来源校验"这类问题。
三、站内站控层:MMS 通信的保护
站控层网络跑的是 MMS 报文,基于 TCP/IP,时延要求在百毫秒量级。时延预算宽松得多,意味着这一段可以用成熟的密码手段做完整的保护。
3.1 MMS 通信保护的两种做法
| 做法 | 原理 | 适用情形 | 注意点 |
|---|---|---|---|
| 传输层保护 | 在 MMS 之上使用 TLS,对通道整体加密与认证 | 站控层主机与装置之间支持 TLS | 需确认装置的 TLS 实现与算法套件;证书要能统一管理 |
| 应用层保护 | 对关键操作报文做签名与验签 | 装置不支持 TLS,或只需保护关键控制操作 | 签名对象要覆盖业务语义,不能只签报文头 |
实践中的组合通常是:对"读"类通信(遥测、遥信上送)用传输层保护即可;对"写"类通信(遥控、定值修改、参数下装)在上层再加一层签名验签,确保关键操作有不可否认的凭证。
3.2 站控层还有两件容易被忽略的事
其一,站内主机的数据落盘。 监控主机、工程师站、数据服务器上会存放历史数据、配置参数、事件记录。这些数据在磁盘上的形态同样要覆盖到,不能因为"数据不出站"就默认安全。磁盘、备份、归档文件、虚拟机快照,都要纳入范围。
其二,站内运维通道。 运维人员通过跳板机或运维终端访问站内设备,这条通道往往是最薄弱的一环:
- 运维终端是否纳管、是否有身份鉴别;
- 运维账号是否按角色划分,运维账号能否看到业务数据明文;
- 运维操作是否留痕、日志是否外送。
现场常见的失分点是"运维账号能看到所有数据的明文"——这属于访问控制与脱敏的问题,需要通过权限分级(业务账号读写明文、运维账号仅见密文或脱敏)解决。
四、站间广域:R-GOOSE 与纵向认证的适用边界
数据从站内出来,进入站间广域通道,威胁模型又变了:这一段是相对开放的长距离链路,窃听与篡改的风险高于站内,但时延预算比站内宽松。
4.1 R-GOOSE / R-SV 是什么,什么时候用
IEC 61850 的原始 GOOSE 与 SV 是二层组播、不可路由,只能在站内跑。当业务需要把 GOOSE 或 SV 类数据跨站传输时(典型场景是广域相量测量、跨站保护配合),就需要可路由的版本——这就是 IEC 61850-90-5 定义的 R-GOOSE 与 R-SV。
IEC 61850-90-5 的一个关键贡献是在协议里定义了加密与认证机制:数据加密可采用 AES-GCM 类算法,报文认证可采用 HMAC 类算法。
适用边界要分清楚:
| 场景 | 适用技术 | 原因 |
|---|---|---|
| 站内过程层 GOOSE/SV | 不做完整加密,以网络管控 + 认证优先为主 | 时延预算极紧(毫秒量级) |
| 跨站广域传输 | R-GOOSE / R-SV,可用加密 + 认证 | 时延预算宽松(几十到几百毫秒量级) |
| 站间调度通信 | 纵向加密认证装置 | 属于调度数据网范畴,按行业要求执行 |
一个常见的认知偏差:以为"上了 R-GOOSE 就能把站内 GOOSE 也加密"。这两件事的时延预算差了两个数量级,不能互相套用。
4.2 纵向认证与站内协议防护是叠加关系
纵向加密认证装置解决的是广域网链路上的通信加密与认证,它保护的是通道。站内过程层网络没有隔离管控、站控层数据明文落盘、主机账号共享——这三个问题,纵向加密认证装置一个都解决不了。
两者是叠加关系,不是替代关系。 这一点在前面已经反复出现,这里再强调一次,是因为现场"边界配得很齐、站内一片透明"的情形实在太多。
4.3 时间同步链路也要纳入范围
智能变电站的 SV 与 GOOSE 报文带时标,站内需要精确的时间同步(采用精确时间同步协议可达亚微秒量级,早期方案用 IRIG-B 或简单网络时间协议)。
时间同步链路本身是一条安全链路:如果攻击者能篡改或欺骗时间源,就能影响带时标数据的含义、影响事件顺序判断。所以时间源设备的管理面、同步链路的物理防护、时间源本身的准入,都要一并纳入。这一条在现场常被漏掉。
五、主站与集控侧:数据落地与运维
数据走出站界到达主站或区域集控中心之后,落地形态会发生变化。这一段的核心问题是"跨了边界之后,保护还在不在"。
5.1 落地形态要逐段确认
| 落地节点 | 典型数据形态 | 需要确认什么 |
|---|---|---|
| 隔离装置两侧 | 生产区侧与信息区侧 | 通过隔离装置后数据是否仍受保护,两侧形态分别是什么 |
| 主站实时库 | 内存与磁盘 | 磁盘上的数据是明文还是密文 |
| 主站历史库 | 长期存储 | 历史归档是否加密,归档文件如何保管 |
| 分析/报表库 | 供多方查询使用 | 敏感字段是否脱敏,脱敏策略是否覆盖所有出口 |
| 备份与灾备 | 离线与异地副本 | 备份是否加密,灾备侧密钥是否独立 |
判断方法是沿着数据的实际流动路径走一遍,在每个落地节点检查数据形态,而不是只看链路的某一端。
5.2 运维侧的两件事
其一,运维数据本身也需要脱敏。 主站与集控侧的历史库、工单表、人员表中往往有姓名、工号、联系方式等信息。这些数据在内部运维查询和对外报送两个场景下的可见范围不同,需要按调用方身份区分策略。
其二,多方运维下的密钥归属。 集控中心的运维往往涉及自有运维人员、集团运维、设备厂商远程支持、外委服务商。只要有一方能直接接触到数据文件或备份介质,加密密钥的归属就必须明确。 判断标准很简单:拿到那台服务器的完全控制权,能不能自己解密出数据?能,就说明密钥管理没做到位。
六、密钥怎么发:IED 密钥注入与全生命周期
前面所有环节的保护最终都依赖密钥。智能变电站的密钥管理有一个通用 IT 场景里不存在的难题:设备数量多、点位分散、多数无人值守。
6.1 IED 与终端的密钥注入流程
| 步骤 | 做什么 | 控制要点 |
|---|---|---|
| 1 | 密钥在受保护环境中产生 | 在密码设备或密钥管理系统内产生,不在外部环境生成后搬运 |
| 2 | 注入过程受控 | 使用专用注入工具,注入过程有操作记录 |
| 3 | 注入后不可导出 | 密钥写入设备的安全存储区后无法读出 |
| 4 | 一机一密绑定 | 通过设备唯一标识建立绑定关系,避免全网共用同一密钥 |
| 5 | 记录与台账对应 | 注入时间、操作人、设备标识记录在案,与设备台账一致 |
第 3、5 步是最容易失守的两步。 常见情形是"整批设备用同一个密钥"(一处泄露即全网泄露),以及"注入记录与设备台账脱节"(后期某台设备需要换密钥时找不到当初用的是什么)。
6.2 密钥的分层与归属
合理的分层是三层:
- 根密钥:由硬件密码模块保护,在设备内产生、不可导出,负责保护下一层密钥;
- 主密钥:由密钥管理系统统一纳管,负责保护数据密钥,轮换频率低;
- 数据密钥 / 会话密钥:实际执行加解密,按业务或按设备派生,支持按周期轮换,会话密钥单次使用后即销毁。
这样分层带来的三个收益,前面已经展开:泄露影响面可控、轮换成本低、过程可举证。
在电力这一侧还有一个特殊要求:密钥管理系统需要按相应的密码设备管理标准做认证。对称密钥管理类产品的认证依据是 GM/T 0051《密码设备管理 对称密钥管理技术规范》。现场核查时,密钥管理系统的认证依据与密钥分层的实际实现,通常是连在一起问的。
6.3 工程落点
把上面几段收成工程能力,通常是这样组织的:网络侧把站内过程层与站控层网络的组播成员关系、VLAN 划分、端口准入固定成可核查的清单,让"谁能接入、谁能发报文"这件事有据可查;通信侧在站控层用传输层保护加上关键操作的签名验签,装置与主站之间用证书完成双向身份认证;数据侧在存储层完成落盘加密,覆盖主库、备库、备份、归档与快照,使"停库直读数据文件能否检索到明文"这件事可以用可复现的方式验证;密钥侧以分层密钥体系承接,根密钥由硬件密码模块保护且不可导出,设备密钥在受控流程中注入并做到一机一密,密钥全生命周期操作留痕。安当在智能变电站这类场景的加固中,通常把这四块能力与站内"两网"的实际结构一起设计,而不是先上设备再想办法适配结构。
七、调度数据网隔离的落点
站内数据要走出去,就要跨过若干条边界。这部分不展开边界装置的型号选型(那属于另一条技术线的深度),只讲与本节数据流直接相关的三个落点,以及一个高频的落地错误。
7.1 落点一:站内网络分区
过程层网络与站控层网络不能混在同一个广播域。这一条的判定方式很具体:
# 自查思路:确认过程层网络与站控层网络在二层是分开的
# 以实际交换机命令为准,此处为思路示例
# 1) 列出各 VLAN 及其成员端口
show vlan brief
# → 逐个 VLAN 核对:过程层 VLAN 内是否出现了站控层设备所在端口
# 2) 核对交换机之间的级联口,确认允许通过的 VLAN 列表
# 关注点:级联口是否把过程层 VLAN 透传到了站控层设备的可接入范围
show interfaces trunk
# → 允许列表过宽是常见问题
# 3) 核对是否存在旁路通路
# 例如临时调试用的直连网线、备用的双归属连接
# → 这类通路在拓扑图上通常不会体现,只能现场核
第 3 条最容易漏。 拓扑图上画得很清楚的两个独立网络,现场可能因为一次调试留下了一根直连网线,事后谁也想不起来。这一类问题的检查方式不是看图纸,是看实物。
7.2 落点二:隔离强度与数据流向要匹配
跨区数据流动的一个基本原则是:隔离强度要匹配数据的敏感度和流动方向。
| 数据流向 | 需要的隔离强度 | 常见错误做法 |
|---|---|---|
| 生产控制大区 → 管理信息大区 | 强度较高的单向隔离措施 | 用普通防火墙做双向转发 |
| 生产控制大区内部安全区之间 | 协议层的访问控制与规约检查 | 只做 IP 层访问控制,不做协议内容检查 |
| 管理信息大区 → 外部网络 | 逻辑隔离加应用级检查 | 与内部区域共用同一套策略 |
"强度匹配"这个说法听起来抽象,落到现场就是一句话:把数据流的方向列出来,逐个问"这条流向用的是哪种强度的措施"。答不出来或者答错了,就是不符合项。
7.3 落点三:安全接入区
当生产控制大区内有个别业务系统或功能模块需要使用公用通信网络、无线通信网络,或者通过处于非可控状态的设备与终端通信时,它的防护水平会低于生产控制大区内的其他系统。这种情况需要单独设立安全接入区,而不是把这类终端直接接进生产控制大区。
典型的适用业务包括:配电网自动化系统的前置采集模块(终端)、负荷控制管理系统、部分分布式电源控制系统。
智能变电站场景里这一条的落点:站内如果存在通过无线或公网回传的辅助监测终端(环境监测、在线监测、视频等),这些终端要么纳入对应的安全接入区,要么与生产控制业务严格分离。常见的错误是把这类终端直接接入过程层或站控层网络,只靠 VLAN 隔一下。
7.4 一个高频的落地错误:把数据"隔离"当成数据"保护"
这是本节最想强调的一点。隔离措施解决的是"数据能不能流过去",它不解决"数据流过去之后是什么形态"。
具体表现是:现场把跨区边界做得非常严格——单向传输、协议白名单、流量审计都做了,但数据送到目标侧之后是明文落盘。这时候边界做得越好,反而越容易让人误以为整体是安全的。
# 验证思路:沿着数据实际流动的路径走一遍,在每个落地节点检查形态
# 关键:不要只看链路的某一端,要看每一个数据落地的地方
# 1) 在生产区侧确认数据形态(应为密文)
file /data/export/*.dat
# → 确认导出文件是否为密文格式,而非可读文本
# 2) 在目标侧确认落地后的形态
grep -c "PROBE_MARK_0916" /data/import/*.dat 2>/dev/null
# → 检索到明文标记,说明隔离装置之后的数据未受保护
# 3) 在归档与备份节点重复第 2 步
# 归档目录、备份目录、灾备副本都要单独确认
判断标准可以收成一句话:隔离管通道,加密管数据,两者不能互相顶替。 一条严格隔离但落地明文的链路,和一条不隔离但落地密文的链路,风险性质完全不同——正确做法是两者都做。
7.5 三条技术线的边界
智能变电站的数据安全有三块相关但不同的工作,深度不同:
- 站内协议与网络结构(本文重点):三层两网、报文防护、组播与 VLAN 管控、密钥注入;
- 边界装置与认证机制:横向隔离装置、纵向加密认证装置、分级调度认证机制的选型与部署;
- 数据存储加密与运维脱敏:存储层加密路径、脱敏范围与方法、现场自证动作。
三块之间的关系是叠加:站内结构决定攻击面有多大,边界措施决定跨站风险有多高,数据加密决定数据被拿走后还剩下什么价值。 任何一块缺失,另外两块的效果都会被削弱。
八、验收清单
智能变电站数据安全自查用。每条给出可验证判据。
| # | 验收项 | 达标判据 |
|---|---|---|
| 1 | 两网分离 | 过程层网络与站控层网络在 VLAN 或物理上分离,无混接端口 |
| 2 | 组播关系清晰 | 每条 GOOSE/SV 控制块的发布与订阅端口已登记,与设计一致 |
| 3 | 静态组播过滤 | 未登记的组播流量不被转发,实测验证 |
| 4 | 空闲端口封闭 | 过程层交换机未使用端口全部关闭 |
| 5 | 接入绑定 | 已使用端口绑定设备 MAC,未登记设备接入即阻断 |
| 6 | 管理面隔离 | 交换机管理口与管理网络隔离,口令独立于业务口令 |
| 7 | 报文非明文验证 | 抓包确认站内实时报文的可见内容,并留档说明设计取舍 |
| 8 | 重放防护 | 接收侧对报文来源与新鲜性有校验,重放测试不能通过 |
| 9 | 时延预算可证 | 若对实时报文加保护,有测试环境的端到端时延实测记录 |
| 10 | MMS 通道保护 | 站控层通信有传输层保护或关键操作签名验签 |
| 11 | 关键操作不可否认 | 遥控、定值修改等写操作有签名验签,签名覆盖业务语义 |
| 12 | 站内数据落盘加密 | 停库或停服务直读数据文件,检索不到敏感数据明文 |
| 13 | 加密覆盖完整 | 主库、备库、备份、归档、快照均已覆盖 |
| 14 | 运维通道受控 | 运维终端纳管,运维账号按角色划分 |
| 15 | 运维不见明文 | 运维账号读取业务数据时只能获得密文或脱敏结果 |
| 16 | 日志外送留存 | 关键操作日志实时外送,本地删除不影响留存副本 |
| 17 | 日志完整性 | 日志具备完整性保护,本地篡改可被发现 |
| 18 | 时间同步链路受控 | 时间源设备管理面受控,同步链路物理防护到位 |
| 19 | 广域传输保护 | 跨站传输使用可路由的安全报文机制或纵向加密认证通道 |
| 20 | R-GOOSE 边界清楚 | 未将广域保护机制直接套用到站内实时报文 |
| 21 | 落地形态逐点确认 | 隔离装置两侧及各级落地节点的数据形态已逐一确认 |
| 22 | 设备证书统一管理 | 装置证书的签发、更新、吊销有统一流程与记录 |
| 23 | 密钥注入受控 | 设备密钥在受控流程中注入,过程有记录 |
| 24 | 一机一密 | 不存在整批设备共用同一密钥的情形 |
| 25 | 注入台账一致 | 密钥注入记录与设备台账一一对应,可回溯 |
| 26 | 密钥分层与硬件保护 | 根密钥由硬件密码模块保护且不可导出 |
| 27 | 密钥与数据分离 | 拿到数据所在环境的完整控制权,无法自行解密 |
| 28 | 密钥取用留痕 | 每次密钥取用产生审计记录且不可本地篡改 |
| 29 | 密钥轮换可行 | 有轮换周期与执行记录,轮换不影响历史数据解密 |
| 30 | 现场可复现 | 上述关键项均可在测评现场复现,非仅文档声明 |
智能变电站的数据安全,最容易走的两条弯路是:把"数字化"当成"更安全"(数据上了网、通了协议,却没意识到二层组播是共享总线,谁能接入谁就能说话),和把"边界装置"当成"全部防护"(跨站通道加密认证做得很扎实,站内过程层网络毫无管控、站内数据明文落盘)。
稳妥的思路是把防护按数据流的四段分开设计:站内过程层管住"谁能接入、谁能发报文",站内站控层管住"通信是否受保护、数据是否明文落盘",站间广域管住"通道是否加密认证",主站与集控侧管住"落地之后形态是否还受保护、密钥在谁手里"。 四段各管一段,任何一段都不能用另一段的手段替代。这样组织下来,"站内一条报文就能被重放"这类问题,就不再需要等到测评方的抓包工具摆在面前才发现。
你们的智能变电站现在做到哪一段——过程层网络做了 VLAN 与组播管控,还是仍在一个大广播域里?站控层的数据在磁盘上是密文还是明文?评论区聊聊,一起看看还差哪一段。
文章作者:安当加密技术负责人
DAMO开发者矩阵,由阿里巴巴达摩院和中国互联网协会联合发起,致力于探讨最前沿的技术趋势与应用成果,搭建高质量的交流与分享平台,推动技术创新与产业应用链接,围绕“人工智能与新型计算”构建开放共享的开发者生态。
更多推荐



所有评论(0)