4. OPC UA安全模型总览
OPC UA 的安全模型不是单一加密机制，而是一套分层、可组合、可审计的端到端安全框架。它从传输层开始，逐层向上构建：先建立安全通道，再建立会话，然后完成用户认证，最后通过授权决定“能做什么”，并由审计记录“做了什么”。理解这个整体框架，是正确配置 OPC UA 安全策略、排查认证失败和设计权限模型的基础。
一、核心原理：五层安全职责
OPC UA 安全模型可以概括为五个层次，每一层解决不同的问题，且下层为上层提供安全基础：
- 安全通道（Secure Channel）：解决传输机密性、完整性和服务器身份真实性。通过 TLS/HTTPS 或 UA 原生安全通道实现，使用服务器证书验证服务端身份，并协商对称密钥保护报文。
- 会话（Session）：解决客户端与服务器之间的逻辑连接状态。会话建立在安全通道之上，承载节点读写、订阅、方法调用等操作，并绑定超时、续期和激活状态。
- 用户认证（User Authentication）：解决“你是谁”。支持匿名、用户名密码、X.509 用户证书、Kerberos 令牌等方式，在会话激活时完成身份确认。
- 授权（Authorization）：解决“你能做什么”。服务器根据用户身份、角色和访问控制策略，决定节点读写、方法调用、订阅等操作是否允许。
- 审计（Audit）：解决“发生了什么”。通过审计事件记录安全通道建立、会话激活、用户认证成功/失败、权限拒绝等关键行为，用于追溯和合规。
安全通道保护“管道”，会话维护“连接状态”，用户认证确认“身份”，授权控制“权限”，审计记录“行为”。五者缺一不可，但职责边界清晰。
二、整体框架与数据流
下图展示了 OPC UA 安全模型中各层之间的顺序关系与数据流。客户端先与服务器建立安全通道，再创建并激活会话，在激活过程中提交用户身份令牌，服务器完成认证后加载授权策略，最终所有关键操作写入审计日志。
三、方法流程：一次安全会话的建立过程
以“用户名密码 + Basic256Sha256 安全策略”为例，客户端与服务器的交互顺序如下：
- 获取端点：客户端调用 GetEndpoints，服务器返回支持的端点列表，包括安全策略 URI、消息安全模式和安全级别。
- 选择安全策略：客户端选择 Basic256Sha256 与 SignAndEncrypt 模式，准备建立安全通道。
- 建立安全通道：客户端验证服务器证书是否在信任列表中且未被吊销，协商对称密钥，完成 OpenSecureChannel。
- 创建会话：客户端发送 CreateSession，服务器返回会话 ID 和认证令牌。
- 激活会话并认证：客户端在 ActivateSession 中提交用户名密码令牌，服务器校验身份。
- 授权判定：服务器根据用户身份映射角色，加载节点访问权限，后续读写请求逐条判定。
- 审计记录：通道建立、会话激活、认证成功或失败、权限拒绝均生成审计事件。
# 典型安全策略 URI 与安全级别
http://opcfoundation.org/UA/SecurityPolicy#None 安全级别 0
http://opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15 安全级别 1
http://opcfoundation.org/UA/SecurityPolicy#Basic256 安全级别 2
http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256 安全级别 3
http://opcfoundation.org/UA/SecurityPolicy#Aes128_Sha256_RsaOaep 安全级别 4
http://opcfoundation.org/UA/SecurityPolicy#Aes256_Sha256_RsaPss 安全级别 5
# 消息安全模式
None 仅签名不加密（不推荐）
Sign 签名，保证完整性
SignAndEncrypt 签名并加密，保证机密性与完整性四、安全策略与认证方式对照
| 安全策略 | 通道加密 | 服务器身份验证 | 适用场景 |
|---|---|---|---|
| None | 无 | 无 | 仅限隔离调试环境 |
| Basic128Rsa15 | 弱 | 证书 | 旧系统兼容，逐步淘汰 |
| Basic256 | 中等 | 证书 | 一般工业现场 |
| Basic256Sha256 | 强 | 证书 | 推荐默认策略 |
| Aes256_Sha256_RsaPss | 很强 | 证书 | 高安全等级场景 |
五、案例场景：权限拒绝的排查
某产线 OPC UA 客户端使用用户名密码认证，安全通道建立成功，但读取某个工艺参数节点时返回 BadUserAccessDenied。排查思路如下：
- 确认安全通道已建立且证书有效，排除传输层问题。
- 确认会话已激活，用户认证返回 Good，排除身份认证失败。
- 检查服务器端该用户的角色映射，确认是否具备该节点的读取权限。
- 检查节点 AccessLevel 与 UserAccessLevel 属性，确认是否被显式拒绝。
- 查看审计日志中是否有权限拒绝事件，定位具体节点和用户。
安全通道失败通常表现为证书验证错误或连接中断；用户认证失败表现为 BadUserAccessDenied 或 BadIdentityTokenInvalid；授权失败则表现为 BadUserAccessDenied 但认证已通过。区分这三类错误是排障的关键。
六、常见误区与复盘
- 误区一：认为安全通道加密就等于用户认证。安全通道只保证传输安全和服务器身份，用户身份仍需单独认证。
- 误区二：忽略授权配置。认证通过不代表有权限，服务器仍需按角色和节点策略逐条判定。
- 误区三：不启用审计。没有审计日志，认证失败和权限拒绝难以追溯，合规性也无法满足。
- 误区四：使用 None 策略上线。None 策略无加密无签名，任何网络嗅探都可读取明文，生产环境必须禁用。
安全策略、用户认证和授权是三个独立配置项。只配置其中一项，无法构成完整的 OPC UA 安全模型。建议按“安全通道 → 会话 → 用户认证 → 授权 → 审计”的顺序逐层验证。
综上，OPC UA 安全模型以安全通道为传输基础，以会话为交互载体，以用户认证确认身份，以授权控制权限，以审计记录行为。五层协同工作，才能实现从连接建立到操作执行的全链路安全。理解这一整体框架，有助于在配置、排障和审计中快速定位问题层次，避免将认证失败、授权拒绝和通道错误混为一谈。