栏目建议：工业网络与安全 / 远程运维

过去几年，远程运维几乎成了 OT（运营技术）现场的“标配”：设备厂商要远程调试，系统集成商要远程运维，业主工厂也希望总部能随时“看得见、调得了”。但连接一旦穿过 Internet，安全问题就摆在桌面上——特别是传统 VPN 模式，既是“生命线”，也是潜在的攻击入口。

Control.com 最近一篇《Remote Networking: Explaining VPNs for Control Engineers》把 VPN 在工业现场的工作原理讲得很清楚；而 Control Engineering 的 2025“年度产品奖”中，又出现了三菱电机与 Dispel 联合推出的 Dispel Zero Trust Remote Access，代表一种面向 OT 的零信任远程访问新路线。这两条线索放在一起，非常适合给工控圈做一次“从 VPN 到零信任”的系统梳理。

一、从串口线到 VPN：OT 远程运维的演进

在很多老工程师的记忆里，早年的远程维护很简单：

• 带一根串口线/编程电缆，上门接在 PLC 或触摸屏上；
• 后来出现工业调制解调器，用电话线拨号远程连；
• 再往后是现场网关 + 以太网，工程师通过厂内办公网访问；
• 再到今天，几乎所有 PLC / HMI / 机器人都支持以太网，甚至 Wi-Fi、4G/5G。

连接方式越来越灵活，但安全风险也随之增加：

• 硬线连接：原则上只在内网，物理安全较高，但一旦办公网/控制网被桥接，入侵者也可能“顺藤摸瓜”进到控制系统。
• 无线连接：Wi-Fi / 蓝牙给调试带来极大便利，也引入嗅探、弱密码、未授权接入等新问题。
• 远程接入：一旦通过互联网远程操控 PLC / SCADA，攻击面从厂区扩展到全球。

在这样的背景下，VPN 成为近十多年来 OT 远程运维的“标准答案”——先解决“安全通道”的问题，再谈后面的访问控制与运维规范。

二、控制工程师眼里的 VPN：它到底做了什么？

Control.com 的文章用一个很直观的比喻：VPN 就是一条建立在公共 Internet 上的“加密隧道”，让远程工程师的电脑仿佛“插”在工厂内网里一样。其关键作用有三点：

1. 构建虚拟专用网络：在公共网络上搭出一个“私有”网络，外人只能看到加密的流量，看不到内部地址与协议细节。
2. 流量加密：采用 AES 等算法，对传输数据进行端到端加密，防止窃听与篡改。
3. 身份认证：通过账号密码、证书甚至多因子认证来校验 VPN 用户身份。

在工业现场，VPN 常被用于：

• 远程编程与维护：对 PLC、驱动器、机器人控制器等进行程序下载、在线监控、故障诊断；
• SCADA / HMI 访问：在远端查看工艺画面、报警和历史数据；
• 远程 I/O 与边缘网关：采集现场数据后转发到云端或总部；
• 多厂区互联：用 VPN 把多个站点“拉到一个大局域网”里。

对很多工厂来说，只要 VPN 搭起来、延迟还可以、维护成本可控，就已经是“够用”的解决方案。但随着勒索软件、供应链攻击频发，只“有隧道”已经远远不够。

三、“只有 VPN”哪里不足？OT 场景的典型痛点

从安全架构角度看，传统 VPN 在 OT 远程运维中的主要问题集中在几类：

1. 一旦连上，就是“大内网通行证”

很多 OT 环境的 VPN 仍然是“网络级接入”：连接成功后，工程师几乎获得一个内网 IP，可以在授权网段里随意扫网段、连设备。如果账号被盗用、终端被木马控制，攻击者也获得了这张“通行证”。

2. 访问粒度太粗

• 难以做到“只允许访问 A 产线某台 PLC 的某个端口”；
• 对第三方厂商、短期驻场工程师，往往只能开一个统一的访问策略，事后也难以回溯“谁做了什么”。

3. 审计与责任难以界定

• 多个工程师共用一个 VPN 账号、或通过跳板机再层层转发，日志很难追溯到“具体人”；
• 许多厂站仍缺乏会话录屏、命令审计，出了事故只能“推测”。

4. OT 特有的可靠性与安全要求

在 OT 环境，安全不只是“机密性”，还包括可用性与安全生产：

• VPN 故障可能直接导致远程维护中断，影响抢修效率；
• 错误操作、恶意操作可能直接影响人身安全与设备安全；
• 许多设备协议（如 Modbus/TCP、各厂家专有编程端口）本身缺乏认证和加密，一旦 VPN 打通，协议本身就是“裸奔”。

这也是为什么越来越多标准与最佳实践（如 NIST SP 800-82、IEC 62443）开始强调：在 OT 领域，远程访问必须纳入统一安全架构，不能只是“加一条 VPN 就完事”。

四、零信任：OT 远程运维的新“地基”

零信任（Zero Trust）的核心原则可以概括为一句话：“从不默认信任，持续验证，再最小授权。” 它并不是简单“替代 VPN 的新玩具”，而是一整套方法论：

• 身份优先，而不是网络优先：先确认“谁”（人或设备）、“从哪儿来”（地理位置、设备健康状况）、“要干什么”，再决定是否放行。
• 最小权限（Least Privilege）：只给用户完成当前任务所必须的最小权限，任务完成后自动收回。
• 微分段（Micro-segmentation）：不再给用户一个“大内网”，而是按应用、设备、工段、风险等级做细颗粒度分区。
• 持续验证与监测：不是“连上一次就一劳永逸”，而是对会话持续监控，一旦行为异常立即阻断。

对 OT 远程运维来说，这意味着一种新的使用体验：

• 工程师登录的是“远程维护门户”，在浏览器或客户端里看到的是一个个具体的“资产入口”，而不是某个网段；
• 点击某台 PLC，平台在后台为当前会话动态建立到该 PLC 的安全通道，并记录所有操作；
• 高风险操作（如安全参数修改、固件升级）可以强制要求双人审批或现场值班人员“协同确认”。

五、案例：三菱电机 × Dispel 的 OT 零信任远程访问

在 Control Engineering 2025 年的“产品奖”电子书中，一款名为 Dispel Zero Trust Remote Access 的解决方案获得了“安全与网络安全”类别的提名/奖项。它由三菱电机自动化与专注 OT 安全的 Dispel 联合推出：

• 深度集成三菱电机 FA 设备：通过带有 Dispel 功能的 iQ-R 系列 WinCPU R102WCPU-W 或 RD55UP12-V C 智能功能模块，实现对控制系统的安全远程访问。
• 按 IEC 62443 / NIST 等标准设计：设计上对齐 IEC 62443 以及 NIST 800-53、NERC CIP 等安全控制要求，提供集中化的安全策略管理和审计能力。
• 零信任访问控制：通过 Dispel 的 Zero Trust Engine，对每一次远程会话做强认证、设备检查、策略判断，并支持会话录屏、密码保管库、端点隔离等功能。
• 面向多行业的 OT 场景：目标行业包括食品饮料、包装、汽车、电子、医疗、物流、电力与水务等典型离散和过程制造领域。

这个案例有两个值得工控从业者关注的信号：

1. OT 远程访问正在从“自建 VPN + 远程桌面”转向专用 SRA（Secure Remote Access）平台，并且与 PLC / PAC 等控制设备更紧耦合；
2. 国际大厂开始用 IEC 62443 等标准来“包装”远程运维能力，这是供应商与业主在招投标、安全评估中可以共用的“语言”。

六、从 VPN 走向零信任：OT 远程运维的落地路径

对大多数工厂来说，完全抛弃现有 VPN 一步到位切换到零信任并不现实。更可行的做法是走一条“增强 VPN → 引入零信任平台 → 渐进迁移”的路线。

1. 梳理业务场景与资产清单

• 列出所有需要远程访问的资产：PLC、HMI、机器人、驱动器、SCADA 服务器、历史数据库、工程师站等；
• 按访问主体划分：内部工程师、设备供应商、系统集成商、IT 运维、管理层；
• 按业务紧急程度分级：必须 7×24 可远程访问的（故障抢修）、计划性维护、纯监控浏览。

2. 重做网络分区：给远程访问一个“专用安全区”

参考 IEC 62443 / NIST SP 800-82 的做法，在 OT 与 IT 之间引入 DMZ（隔离区），并将外部远程访问终结在 DMZ 中，再通过受控通道进入控制网：

• VPN 终端或零信任网关部署在 DMZ，而不是直接入 OT 网段；
• DMZ 内通过跳板机、协议代理或应用网关访问 OT 资产；
• 对关键控制网段（如 SIS、安全 PLC）进一步做网络与权限隔离。

3. 先把“旧 VPN”加固到不那么危险

在零信任平台上线之前，可以先对现有 VPN 做几件“立竿见影”的事情：

• 启用多因子认证（MFA）：禁止仅靠账户密码；
• 限制访问范围：按用户/角色划定可访问的网段和端口，禁止“全网通”；
• 关闭分流（Split Tunneling）：防止用户一边连公司 VPN，一边上公网；
• 集中日志与告警：把 VPN 日志汇聚到 SIEM / 日志平台，拉起异常登录告警机制；
• 规范账户管理：个人账号个人用，供应商账号独立、到期自动禁用。

4. 引入 OT 场景的零信任远程访问平台

选型与落地时，可以关注几个关键能力：

• 应用/资产级访问控制：不是“连网段”，而是“连某台设备、某个服务（例如 SCADA Web、工程师站 RDP）”；
• 细粒度策略：按人员身份、设备状态（是否打补丁、是否装安全代理）、时间、地点等条件动态授权；:contentReference[oaicite:6]{index=6}
• 强审计：会话录屏、操作命令记录、变更记录，方便事后追溯与合规审计；:contentReference[oaicite:7]{index=7}
• OT 协议友好：支持 Modbus/TCP、OPC UA、各家 PLC 编程工具常用端口的代理与控制；
• 与现有身份体系集成：可对接 AD / LDAP / IAM 平台，避免重复建库；
• 适应弱网络环境：考虑远程站点网络质量差、设备算力有限的实际情况。

5. 建立“人、流程、技术”三位一体的远程运维制度

技术平台只是基础，更关键的是围绕它建立起远程运维的制度：

• 明确哪些操作必须现场值班人员“陪同”或复核；
• 重要变更（如安全参数调整、固件升级）必须走工单流程和变更审批；
• 对第三方厂商设定“账号 + 合同 + 日志”三重约束：账号独立、合同写明责任边界、操作全过程留痕；
• 定期复盘远程运维事件，修正策略与流程。

七、给业主工厂与集成商的“自查清单”

最后，可以用一份简化清单来判断自己的 OT 远程运维处于什么阶段：

1. 目前远程访问是否全部走加密通道（VPN / ZTNA / 专用 SRA）？
2. 远程访问是否全部终结在 DMZ，而不是直接打进控制网？
3. 是否对不同角色（内部工程师、供应商、IT 运维）按最小权限划分访问范围？
4. 是否启用了MFA、多因素认证？是否禁止账号共用？
5. 能否清晰回答：某个时间点，某个供应商工程师在某台设备上做了哪些操作？
6. 是否有对远程运维的书面流程（开窗、审批、现场确认、回退方案）？
7. 是否规划了从传统 VPN 逐步过渡到零信任访问架构的路线（试点厂、试点产线）？

如果上述问题有一半以上的答案是“否”或“不确定”，就意味着你的远程运维架构仍停留在“只要能连上就行”的阶段，已经难以匹配现在的威胁环境。

结语：从“能连上”到“敢连上”

VPN 帮助控制工程师跨越了物理距离，让远程维护成为日常工作的一部分；而零信任则是在这个基础上，给 OT 远程运维加上了身份、上下文和策略的“安全骨骼”。

对明扬资讯的读者——无论你是设备厂商、系统集成商还是业主工厂——现在都到了认真思考一个问题的时候：

我们不光要“能连上工厂”，更要“敢放心让别人连进来”。

从梳理资产与场景、加固现有 VPN 开始，再通过试点将零信任远程访问逐步引入到关键产线，才是 OT 远程运维真正可持续、可规模复制的落地路径。

原文参考：Control.com《Remote Networking: Explaining VPNs for Control Engineers》、Control Engineering《Control Engineering 2025 Product of the Year – Safety & Cybersecurity》中的 Dispel Zero Trust Remote Access 条目、三菱电机与 Dispel 的新闻稿，以及部分 OT 远程访问 / 零信任最佳实践与标准解读文章。([Control.com][1]) [1]: https://control.com/technical-articles/remote-networking-explaining-vpns-for-control-engineers/ "Remote Networking: Explaining VPNs for Control Engineers - Technical Articles"

推荐阅读：

IoT + 边缘计算 + 数字孪生：撑起过程工厂的实时安全监控

工业网络与安全｜Control.com & Control Engineering：从 VPN 到零信任，OT 远程运维怎么做才安全？

IO-Link Safety 通过 TÜV SÜD 认证：现场安全 I/O 的关键里程碑

工业网络专题｜OPC UA Field eXchange（UAFX）现状与落地路径

工业网络边缘·最新实例｜Thames Freeport（英国泰晤士自贸港）多园区“私有5G + 工业边缘”落地

工业网络与边缘｜Ethernet-APL + PROFINET 现场总线升级与边缘分析