4、OPC UA消息安全模式：无安全、签名、签名与加密深度对比

好，咱们今天聊一个非常核心的话题——OPC UA的三种消息安全模式。说实话，很多刚接触OPC UA的朋友，甚至一些老工程师，对这三种模式的理解都停留在表面。我见过不少项目，明明现场环境很恶劣，结果配置了个“无安全”模式，数据在网络上裸奔，想想都后怕。

这三种模式分别是：无安全（None）、签名（Sign）、签名与加密（SignAndEncrypt）。它们决定了OPC UA消息在传输过程中，到底有没有“上锁”，上了几把锁。

4.1 无安全模式（None）—— 裸奔的数据

无安全模式，说白了就是“不设防”。消息以明文形式发送，没有任何保护措施。

为什么这么说？你想想看，在这种模式下：

• 消息内容完全透明：任何能抓到网络包的人，都能直接看到你发送的PLC指令、传感器数值、甚至控制参数。我曾经在客户现场抓包分析，发现他们用无安全模式传输着整个产线的配方数据，那感觉就像看到自家大门敞开着。
• 消息可以被篡改：攻击者可以轻松修改数据包内容，比如把“停止”指令改成“启动”，或者把温度阈值从100度改成1000度。
• 消息可以被重放：攻击者记录下你发送的合法指令，然后在关键时刻重新发送一遍，造成设备误动作。

嗯，这里要注意，OPC UA规范里其实允许无安全模式，但它的定位是“可选”的，不是“推荐”的。我记得有一次，一个供应商坚持说他们的设备只支持无安全模式，我直接让他们回去升级固件了——这年头，不支持签名的OPC UA设备，基本等于不合格。

4.2 签名模式（Sign）—— 防伪但不保密

签名模式，就是给消息加上一个“数字签名”。它解决的核心问题是：消息是谁发的？有没有被篡改？

它的工作原理是这样的：

1. 发送方用自己的私钥对消息内容进行签名计算。
2. 接收方用发送方的公钥验证这个签名。
3. 如果签名验证通过，说明消息确实来自声称的发送方，并且在传输过程中没有被改动过。

但是，消息本身仍然是明文的。也就是说，虽然别人改不了你的消息，但他们可以看到你的消息内容。

我在项目中遇到过这样一个场景：某工厂的MES系统需要从OPC UA服务器读取生产数据，用于统计分析。这些数据本身不敏感（比如产量、良率），但必须确保数据没有被中间人篡改。这种情况下，签名模式就够用了。因为即使数据被看到，也不会造成什么损失，但数据一旦被改，就会导致统计报表出错，影响决策。

签名模式的开销比无安全模式大一些，因为需要做非对称密码运算。但说实话，现代CPU处理这点计算量，基本感觉不到延迟。我测试过，在普通的工控机上，签名验证的耗时通常在毫秒级别，完全不影响实时性。

4.3 签名与加密模式（SignAndEncrypt）—— 全副武装

这才是OPC UA安全机制的“完全体”。它同时做了两件事：

• 签名：保证消息的真实性和完整性。
• 加密：保证消息的机密性，防止被窃听。

说白了，就是既不让别人看，也不让别人改。这是工业控制场景下最推荐的安全模式，尤其是当你的数据涉及核心工艺参数、配方、或者直接控制指令时。

它的工作流程稍微复杂一点：

1. 发送方先对消息内容进行加密（通常使用对称加密算法，如AES）。
2. 然后对加密后的消息（或消息摘要）进行签名。
3. 接收方先验证签名，确认消息未被篡改且来源可信。
4. 验证通过后，再用密钥解密，得到原始消息。

加密模式的开销是最大的，因为既要签名又要加密。但考虑到安全性，这点性能代价是值得的。我个人的习惯是：只要网络环境不是完全物理隔离，一律使用SignAndEncrypt。哪怕只是读一个温度值，我也建议加密——因为你永远不知道，网络上的哪个角落有人在监听。

4.4 三种模式的对比总结

为了让你看得更清楚，我整理了一个表格：

4.5 如何选择？我的建议

你可能会问：那我到底该用哪种？

我的建议很简单，就三条：

1. 默认选SignAndEncrypt。除非你有非常明确的理由不这么做，否则这就是你的默认配置。安全不是功能，是底线。
2. 如果性能是瓶颈，考虑Sign。比如你有一个非常老的PLC，CPU算力有限，或者你的网络带宽极低。但即便如此，也要确保数据本身不敏感。
3. 永远不要用None。真的，别用。我见过太多因为图省事用None，结果出事后追悔莫及的案例。有一次，一个客户的生产线被勒索软件攻击，就是因为OPC UA通信没有加密，攻击者直接注入了恶意指令。

嗯，最后再啰嗦一句：安全配置不是一劳永逸的。随着网络威胁的演变，你可能需要定期审视你的安全策略。比如，几年前大家觉得签名就够了，但现在，随着工业互联网的普及，加密已经成了基本要求。

好了，这一章就到这里。下一章我们会深入聊聊OPC UA的证书管理——毕竟，没有证书，签名和加密都是空中楼阁。