加密方案的基本原理
传统 Modbus 既没有认证也没有加密，加密方案的做法是在传输层给它套上标准的安全传输协议：双方用证书互相验证身份，之后所有报文加密传输，而功能码、寄存器与线圈的数据模型完全不变，因此上层应用逻辑无需重写。为避免与传统端口混淆，业界约定了独立的端口。部署的前提是两端都支持该能力；大量在役设备并不支持，这时需要在网络边界用网关终结，把有保护的一段延伸到网关，再在网关外侧维持原有方式，并接受这段仍不受保护的事实。
基本信息
| 保护内容 | 传输加密与双向身份验证 |
|---|---|
| 数据模型 | 功能码与寄存器模型不变 |
| 端口约定 | 使用独立端口以示区别，具体以官方规范为准 |
| 兼容前提 | 两端都支持；老设备需经网关终结 |
| 证书管理 | 需要分发、信任、轮换与吊销机制 |
| 时间同步 | 证书有效性判断依赖正确的系统时间 |
| 性能开销 | 握手与加解密带来额外延迟，高频轮询需实测 |
| 访问控制 | 部分实现在加密之上增加基于角色的权限控制 |
典型使用场景
- 跨网段或跨厂区采集：链路经过不可信网络
- 合规要求：审计要求加密与身份验证的场合
- 云端接入：经网关加密后上行
- 老设备改造：设备侧无法支持，只在边界外侧加密
- 证书轮换：提前规划有效期与更新流程
- 故障排查：加密后无法直接抓包看内容，需要调整排错方法
部署要素
| 要素 | 要点 | 风险 |
|---|---|---|
| 端侧支持 | 确认两端能力与版本 | 一端不支持则方案不成立 |
| 证书管理 | 分发、信任、轮换、吊销 | 过期导致批量中断 |
| 时间同步 | 保证系统时钟正确 | 时钟偏差导致握手失败 |
| 性能 | 实测握手与加解密开销 | 高频轮询周期被拖长 |
| 访问控制 | 是否支持角色与权限区分 | 只加密不授权仍属共享权限 |
| 备份与端口 | 配置备份并关闭无保护端口 | 双端口并存使防护失效 |
落地步骤
落地步骤
# 1 确认两端支持能力，不支持的链段规划网关终结方案
# 2 规划证书体系：签发、分发、信任列表、轮换周期与吊销方式
# 3 统一时间源：证书校验依赖正确时间，避免因时钟偏差握手失败
# 4 实测性能：比较启用前后的轮询周期，必要时调整轮询策略
# 5 关闭无保护端口：只保留加密端口，避免形成绕过路径
# 6 更新排错方法：加密后无法直接读报文内容，需依赖设备与网关日志加密只解决链路问题，不解决权限问题：多台设备共用同一证书与身份的部署方式，等同于所有人都拥有相同权限。
启用加密却同时保留原有无保护端口，等于给攻击者留了一条旁路，改造完成后必须确认旧端口已关闭。