5.2 OPC UA 原生安全机制
5.2 OPC UA 原生安全机制
本节摘要：OPC UA 把认证、加密、授权、审计内建于协议，本节沿"证书怎么发、信任怎么建、策略怎么选、连不上怎么查"的落地路径走一遍，把安全特性变成可运维的日常。
从一次连接失败说起
场景：新 UA 服务器上架，客户端一连接就被拒绝，报错信息只有一句"安全检查失败"。检查网络通、端口开、服务进程活着，一切正常但就是连不上。十有八九，问题出在证书上——客户端的应用实例证书不在服务器的信任列表里，或者服务器时间不对导致证书校验失败。这类"安全的代价"在 UA 世界是日常：**协议替你挡住了陌生人，代价是你必须先教会它认识熟人。**本节就把这套"教学流程"完整走一遍。
学习目标
阅读完本节，你应当能够：
- 说明 UA 安全机制的四件套（认证、加密、授权、审计）分别由什么承载；
- 完成应用实例证书的生成、交换与信任列表维护；
- 按场景选择安全策略并说明取舍；
- 按分层路径诊断"连不上"类问题。
一、四件套各自由什么承载
认证由应用实例证书承载：每个 UA 应用（客户端与服务器都是）有自己的证书，身份即证书。握手时双方互相验证对方证书，陌生人无法进入对话。加密由安全策略承载：握手协商出会话密钥，之后报文签名或加密，策略决定强度。授权由用户与角色体系承载：应用证书证明了"是哪台程序在说话"，用户身份则回答"是哪个人让它说话"，权限模型把变量、方法、视图的访问权授予角色。审计由审计日志承载：谁在何时读写或调用了什么，安全事件单独成册——这本册子在追查误操作时是唯一的证据链。
四件套的分工有个容易混淆的点：**证书管机器身份，用户管人的权限，两层都要过。**现场常见误解是"配了证书就万事大吉"，结果任何能登上那台客户端电脑的人都能以合法身份下发命令。正式部署中，涉及写权限的访问必须启用用户认证，两者缺一不可。
二、证书落地：生成、交换、信任
应用证书的生命周期管理是 UA 运维的主体。流程分四步：
第一步，生成。服务器与客户端各自生成证书，证书里写明应用 URI、主机名、有效期。生产环境的证书应由组织内部的证书服务签发，形成统一信任链；小规模部署用自签证书也可，但要更严格地手工维护信任关系。第二步，交换。第一次连接时，对端的证书会出现在彼此的"待审列表"里——UA 的设计贴心又保守：它不自动信任任何人，但把陌生证书收好等你裁决。第三步，裁决与信任。运维核对证书指纹（与对方当面核对或经可信渠道比对）后，将其移入信任列表，从此握手放行。第四步，续期。证书有效期到了要换新，换新后对端信任列表要同步更新——大量"系统突然全断"的事故根源就是没人记得续期日期。
证书巡检卡（文字模板，建议纳入月度运维） 服务器侧 应用证书 有效期至：____ 剩余天数告警线：30天 信任列表条目数：____ 与台账核对：一致 或 差异清单：____ 待审列表积压：应为0 有积压说明有人连过而未裁决 客户端侧 应用证书有效期与服务器同步巡检 信任列表仅含明确列出的一台或多台服务器 时间基准 两端系统时间与标准时源偏差：应小于分钟级 证书校验失败告警出现时 第一步先查时间
巡检卡里"待审列表积压应为零"这条值得解释：待审列表里躺着证书，说明有未预期的程序尝试连接过——可能是新装的客户端，也可能是扫描器。定期清空待审列表（每条都给出裁决），本身就是一次轻量的安全巡检。
图18 安全握手的完整时序与常见卡点
三、策略选择与故障诊断
安全策略是"加密加签名"的不同档位组合。选型口诀：跨网段必加密，厂内至少签名，调试环境才允许不设防。跨组织或跨广域的连接用全套加密策略；厂内信任网络可用签名策略省下加密开销；完全不加密只应存在于开发调试。策略是连接时双方协商的，两端支持集的交集为空也会导致连接失败——这也是"连不上"的候选原因之一。
"连不上"的诊断按分层走，从下往上：网络层 ping 通不通、端口开不开；传输层版本与端点配置匹配不匹配；安全层证书在不在信任列表、过没过期、时钟偏没偏、策略交集有没有；会话层用户名密码对不对、账号锁没锁。九成以上的案例终结在安全层，其中时间不同步与证书过期又是这九成里的多数。把 3.1 的建连三步与此处的分层诊断对照记忆，排障时就有了一张地图。
💡 关键直觉：UA 的安全不是"开启开关"而是"经营信任"。证书的生成、裁决、续期、巡检是持续动作，第一次配通的喜悦只是经营的开始——把信任关系台账化，系统才不会在某个证书到期的深夜集体沉默。
四、证书批量运维：从手工作坊到台账制度
单台服务器的证书管理不难，难的是规模化。一个厂区几十台服务器与工作站，证书各自生成、各自过期，纯手工管理必然漏。三步升级到台账制度。第一步，签发集中化：证书不再由各设备自签，统一由厂内证书服务签发，有效期对齐（比如统一两年、到期前一个月集中换），过期日期从"几十个散点"收敛为"一个日程"。第二步，信任列表模板化：同类设备使用同一份信任列表模板，新设备上线即套模板，待审列表的裁决从逐台处理变成按模板批量放行。第三步，巡检自动化：用脚本定期检查各设备证书剩余天数与待审列表积压，输出例外清单，运维只处理例外——这正是 5.4 清单 P01 条款的机器化形态。
顺带回答一个高频问题：证书要不要上自动轮换？厂内环境建议"半自动"——脚本换发、人工确认，全自动轮换在 OT 网络的风险（脚本出错导致批量失联）大于收益；跨组织的接口证书，则按对端要求执行，通常对齐对方的轮换策略即可。
台账制度再补一块拼图：到期告警要独立于被管系统。把到期日写在被监控的服务器上，服务器一挂，告警跟着哑；到期表放在独立的运维台或日历系统，提前九十天、三十天、七天三级提醒。证书过期的故障最冤——不是能力不够，是记忆失灵，而记忆失灵恰是制度该兜住的风险。顺带盘一遍：网上还挂多少"永不过期"的自签证书？每清一张，台账薄一页，攻击面小一片。另外，证书更换后旧证书要及时从信任列表移出——信任列表只增不减，是证书管理里最常见的隐性风险。
本节要点回顾
- 四件套分工：证书认证机器、用户授权个人、策略定加密、审计留证据，机器与人的身份缺一不可；
- 证书经营四步：生成、交换、裁决、续期，信任列表是核心资产，待审列表积压必须清零；
- 策略选型口诀：跨网段加密、厂内签名、调试才裸奔，两端策略交集为空也是连接失败的原因；
- 诊断按层走：网络、传输、安全、会话逐层排查，时间不同步与证书过期是最高频根因。
防住了人，下一节防意外：断电、宕机之后，系统怎么自己站起来。