2、OPC UA协议安全基础：协议栈架构、安全模型与通信模式
聊OPC UA安全，不能一上来就谈加密算法。你得先搞清楚它到底长什么样，怎么工作的。我最早接触OPC UA时，也犯过这个错——直接跳到证书配置，结果连握手都失败。后来才明白，不理解协议栈架构和安全模型，你根本不知道问题出在哪一层。
这一节，我们就从底层往上捋一遍。把协议栈、安全模型、通信模式这三个核心概念讲透。
2.1 OPC UA协议栈架构
OPC UA的协议栈，说白了就是一套分层的通信骨架。它不像传统工业协议那样把东西都揉在一起，而是拆成了清晰的层级。我个人习惯把它看成三块：底层传输、中间编码、上层服务。
核心要点：OPC UA协议栈是“传输层无关”的。它可以在TCP、HTTPS、甚至UDP上跑。安全机制在每一层都有嵌入，但最关键的还是在会话层。
下面这张图，是我每次培训都会画的。它把OPC UA协议栈的核心分层和安全边界标了出来。
你看，安全层并不是单独挂在那里的。它横跨了会话层和编码层之间。这意味着什么？意味着你的身份认证、加密、签名，是在会话建立时就协商好的，而不是事后补上去的。
我记得有一次，一个客户在部署OPC UA时，发现客户端连不上服务器。查了半天，发现是传输层用了HTTPS，但安全层配置的是None。嗯，这里要注意：传输层协议和安全策略必须匹配。你用HTTPS，安全策略就不能是None，否则握手阶段就报错。
2.2 安全模型：客户端/服务器
OPC UA的安全模型，核心就是客户端和服务器之间的信任关系。你想想看，一个PLC作为服务器，一个上位机作为客户端，它们之间怎么确认对方是可信的？
答案就是：证书 + 策略。
我的经验：很多工程师把OPC UA安全等同于“配证书”。其实证书只是载体，真正的核心是“安全策略”的协商。证书是身份，策略是行为。两者缺一不可。
OPC UA定义了三种安全模型，我列个表，你一看就明白：
| 安全模型 | 认证方式 | 加密 | 适用场景 |
|---|---|---|---|
| None | 无认证 | 无 | 测试环境、内部只读网络 |
| Sign | 证书签名 | 无 | 数据完整性要求高，但性能敏感 |
| SignAndEncrypt | 证书签名 | AES-256 | 生产环境、跨网段、互联网 |
我建议，只要不是纯实验室环境，至少用Sign。为什么？因为None模式下，攻击者可以伪造数据包。我在一个汽车焊装车间见过一次事故——有人把None模式的OPC UA暴露在了办公网，结果一个误操作导致机器人急停。虽然不一定是恶意攻击，但风险太大了。
2.3 安全通信模式
OPC UA的通信模式，不是简单的“发一条收一条”。它有一套完整的握手流程。我把它拆成三步：
- 发现阶段：客户端先找服务器，获取服务器支持的端点列表。每个端点都包含安全策略和传输协议信息。
- 握手阶段：客户端选择一个端点，发起OpenSecureChannel请求。双方交换证书，协商密钥。
- 会话阶段：安全通道建立后，创建会话。后续所有数据都在这个加密通道里传输。
避坑指南：我曾经遇到一个案例，客户端总是握手失败。查日志发现，服务器端点的安全策略列表里，只有Basic256Sha256，但客户端只支持Basic128Rsa15。两边没交集，自然连不上。所以，部署前一定要确认两端的安全策略是匹配的。
这里有一个关键点：安全通道（SecureChannel）和会话（Session）是分开的。安全通道负责传输加密，会话负责应用层状态。通道可以复用，会话可以独立管理。这种设计的好处是，你可以在不中断会话的情况下，重新协商通道密钥。
下面这个流程图，展示了完整的通信建立过程：
这个流程看起来简单，但实际部署时坑不少。比如，证书过期、证书链不完整、主机名不匹配，都会导致握手失败。我建议你在测试阶段，先用OPC UA的测试客户端（比如UaExpert）走一遍流程，确认所有环节都通了，再集成到正式系统里。
2.4 安全策略与加密套件
OPC UA定义了几种标准安全策略。说白了，就是一组加密算法的组合。我常用的就两种：
- Basic128Rsa15：对称加密用AES-128，签名用RSA-15。性能好，适合资源受限设备。
- Basic256Sha256：对称加密用AES-256，签名用RSA-SHA256。安全性更高，适合关键系统。
我的建议：新项目直接上Basic256Sha256。Basic128Rsa15虽然快，但RSA-15的签名算法已经有些年头了。安全这东西，别省那点性能。
嗯，这里还要提一句：安全策略是协商出来的，不是单方面决定的。客户端发起请求时，会带上它支持的所有策略。服务器从中选一个它也能支持的。如果没交集，连接就失败。所以，部署前一定要确认两端的安全策略列表有重叠。