1. OPC UA 安全模型总览：理解核心三要素与TLS的关系
各位工程师，咱们直接进入正题。OPC UA 的安全模型，说白了就是解决三个问题：你是谁？你能干什么？你的数据在路上会不会被偷看或篡改？ 这三个问题对应着三个核心要素：身份验证、授权、加密。
我最早接触 OPC UA 时，觉得这玩意儿不就是个通信协议嘛，安全层加得有点多余。直到有一次在产线上，一个第三方系统因为证书配置错误，直接导致整个控制网络瘫痪……嗯，从那以后，我再也不敢轻视安全模型了。
1.1 安全三要素：一个都不能少
咱们先拆开来看。这三个要素不是可选项，是必选项。你想想看，如果只加密不验证，那跟把家门钥匙给陌生人有什么区别？
| 要素 | 解决什么问题 | 通俗理解 |
|---|---|---|
| 身份验证 | 确认通信双方的身份 | 你出示工牌，我确认你是本人 |
| 授权 | 控制你能访问哪些资源 | 你只能进车间，不能进财务室 |
| 加密 | 保护数据传输的机密性和完整性 | 你俩说话，别人听不见也改不了 |
核心原则：OPC UA 的安全模型要求这三个要素协同工作。缺了任何一个，整个安全链条就断了。我在项目中见过不少只配了加密、没配证书验证的案例——说白了，那跟裸奔差不多。
1.2 身份验证：你到底是谁？
OPC UA 支持多种身份验证方式。我个人习惯把它们分成两类：基于证书的和基于用户凭证的。
- X.509 证书验证：这是最常用的方式。每个 OPC UA 应用都有一个数字证书，相当于它的身份证。握手时双方交换证书，验证签名链。
- 用户名/密码：简单直接，但安全性依赖传输加密。我建议只在内部网络且配合 TLS 时使用。
- 令牌验证：比如 OAuth2、Kerberos，适合企业级集成场景。
我的经验：工业现场我优先推荐证书验证。用户名密码容易被泄露，而且管理起来麻烦。证书虽然前期配置麻烦点，但一旦跑起来，省心很多。
1.3 授权：你能碰什么？
身份验证通过后，接下来就是授权。OPC UA 的授权模型基于角色和权限。说白了，就是定义谁可以读、谁可以写、谁可以执行。
我记得有个项目，客户把所有操作员都设成了管理员权限。结果一个误操作，把产线配方给改了……嗯，授权粒度一定要细。OPC UA 支持三种授权模式：
- 基于角色的访问控制（RBAC）：最常用。定义角色（操作员、工程师、管理员），再给角色分配权限。
- 基于属性的访问控制（ABAC）：更灵活。根据用户属性（部门、班次、位置）动态判断权限。
- 访问控制列表（ACL）：直接针对每个节点设置允许/拒绝规则。
避坑指南：我曾经见过一个系统，授权规则写了 200 多条，结果性能严重下降。授权不是越多越好，够用就行。建议先按角色粗分，再针对关键节点做细粒度控制。
1.4 加密：数据在路上安全吗？
加密分两块：传输加密和签名。传输加密保证数据别人看不懂，签名保证数据没被改过。
OPC UA 的加密通过 SecurityPolicy 来定义。每个 SecurityPolicy 指定了：
- 对称加密算法（如 AES）
- 非对称加密算法（如 RSA）
- 签名算法（如 SHA-256）
- 密钥长度
| SecurityPolicy | 加密算法 | 签名算法 | 安全等级 |
|---|---|---|---|
| Basic128Rsa15 | AES-128 | RSA-SHA1 | 低（不推荐） |
| Basic256 | AES-256 | RSA-SHA1 | 中 |
| Basic256Sha256 | AES-256 | RSA-SHA256 | 高（推荐） |
| Aes128Sha256RsaOaep | AES-128 | RSA-OAEP | 高（新标准） |
| Aes256Sha256RsaPss | AES-256 | RSA-PSS | 最高（推荐） |
我的建议：新项目直接上 Aes256Sha256RsaPss。别再用 Basic128Rsa15 了，SHA1 已经不安全了。我去年审计过一个老项目，还在用 Basic128Rsa15，吓得我赶紧让他们升级。
1.5 SecurityPolicy 与 TLS 的关系
这里有个容易混淆的点。很多人问：SecurityPolicy 和 TLS 到底什么关系？ 我打个比方你就明白了。
- TLS 是传输层的安全通道。它负责在 TCP 连接上建立加密隧道。相当于你俩在一条安全的地道里说话。
- SecurityPolicy 是应用层的安全策略。它在 TLS 隧道之上，对 OPC UA 的报文再做一层加密和签名。相当于在地道里，你俩还用暗号说话。
说白了，TLS 保护的是通道，SecurityPolicy 保护的是消息。两者可以独立使用，也可以叠加使用。
实际场景：我一般建议：
- 跨网络通信（比如从车间到 IT 层）：TLS + SecurityPolicy 双重保险
- 同一网段内部通信：至少用 SecurityPolicy 的 SignAndEncrypt 模式
- 测试环境：可以用 None，但千万别上生产
1.6 安全模型全景图
说了这么多，咱们用一张图把整个安全模型串起来。这张图我每次培训都会画，你仔细看：
这张图你看懂了吗？从上到下，先是 TCP 连接，然后可选的 TLS 加密通道，再是三个核心要素并行工作，最后 SecurityPolicy 在应用层兜底。每一层都有自己的职责，互不替代。
1.7 安全模式：你选哪种？
OPC UA 定义了三种安全模式，对应不同的 SecurityPolicy 使用方式：
| 安全模式 | 签名 | 加密 | 适用场景 |
|---|---|---|---|
| None | 无 | 无 | 仅测试或内部安全网络 |
| Sign | 有 | 无 | 需要防篡改，不关心窃听 |
| SignAndEncrypt | 有 | 有 | 生产环境，推荐使用 |
注意：None 模式在生产环境绝对不要用。我见过有人图省事，把 SecurityPolicy 设成 None，结果被中间人攻击，数据被篡改了都不知道。安全这东西，省事就是省命。
1.8 证书管理：容易被忽视的环节
最后聊一个实操中经常踩坑的地方——证书管理。OPC UA 的证书有生命周期：
- 生成：每个应用实例生成自己的证书
- 信任：双方交换证书，加入信任列表
- 验证：每次连接时验证证书链
- 吊销：证书泄露或过期后吊销
- 更新：证书到期前更新
我遇到过最典型的问题：证书过期了没人管，系统突然连不上。嗯，证书监控一定要自动化，别等人报故障了才去查。
我的习惯：证书有效期设 3-5 年，提前 3 个月设置告警。用脚本定期检查证书剩余有效期，到期前自动触发更新流程。别问我为什么这么熟练——都是踩坑踩出来的。
好了，这一章的内容就到这里。安全模型是 OPC UA 的基石，后面的所有调优都建立在这个基础上。你先把三要素和 SecurityPolicy 的关系理清楚，后面咱们再深入细节。