OPC Unified Architecture Specification
OPC 统一架构规范
Part 2 Security Model
（第二部分 安全模型）
(Release 1.03)
kipway 译
http://www.kipway.com
此规范是OPC UA应用程序开发人员的规范。该规范是分析和设计过程的结果，用于开发标准接口，以便多个供应商开发无缝集成的应用程序。
Copyright © 2006-2015, OPC Foundation, Inc
任何未经授权使用本规范可能违反版权法，商标法和通讯规定和法规。本文档包含受版权保护的信息。版权所有。图书，电子或机械的任何形式，包括复印，录音，录音或信息存储和检索系统 - 未经版权许可，不得以任何形式或任何方式复制或使用本作品所涵盖的此作品的任何部分。 ---所有者。
禁止OPC基金会成员和非成员复制和重新分发本规范。 所有副本必须单独获得，直接从OPC基金会网站http://www.opcfoundation.org下载。
采用者的注意力在于遵守或采用OPC规范可能需要使用专利权所涵盖的发明的可能性。 OPC不负责识别任何OPC规范可能需要许可的专利，或对引起其注意的专利的法律效力或范围进行法律调查的责任。 OPC规范仅供参考和咨询。 潜在用户负责保护自己免受专利侵权责任。
译者对本文的翻译无法保证准确无误，并可能包含错误。译者对本文不承担任何明示或暗示的担保，包括但不限于任何对所有权的担保，暗示对适销性或适用于特定用途或使用的保证。在任何情况下，译者对于本文所含的错误或直接，间接，偶发，特殊，后果性，依赖性或覆盖面的任何损失，包括任何用户或任何第三方的利润损失，收入，数据或使用，均不承担责任与本材料的使用，性能或使用有关，即使已被告知可能发生此类损害。
本文的英文原版属于OPC Foundation, Inc，翻译后的版本未经译者同意任何个人和组织不得转载。
本规范描述了OPC统一架构（OPC UA）安全模型。 它描述了预期运行OPC UA的物理，硬件和软件环境的安全威胁。 以及OPC UA如何依赖于其他安全标准。提供了在OPC UA规范的这一部分和其他部分中使用的通用安全术语的定义。概述了OPC UA规范的其他部分中指定的安全功能。 引用了在多部分规范的其他部分规范地规定的服务，映射和配置文件。提供了实施安全性的建议或最佳做法准则。规范的这一部分是有益的而不是规范性的。本部分与规范性内容之间的任何看似混乱并不能消除或减少规范部分规定的要求。
请注意，开发应用程序时必须解决安全性的许多不同方面。但是由于OPC UA指定了通信协议，所以重点是保护应用程序之间交换的数据。这并不意味着应用程序开发人员可以忽略安全性的其他方面，例如保护持久性数据免受篡改。重要的是，开发人员会查看安全性的各个方面，并决定如何在应用程序中解决这些问题。
本部分针对将开发OPC UA客户端或服务器应用程序或实施OPC UA服务层的读者。也希望了解OPC UA提供的各种安全功能和功能的最终用户。它还提供了一些在部署系统时可以应用的建议。这些建议本质上是通用的，因为细节将取决于OPC UA应用程序的实际实现以及为站点安全性所做的选择。
假设读者熟悉Web服务和XML / SOAP。有关这些技术的信息可以在SOAP第1部分和SOAP第2部分中找到。
以下文件全部或部分在本文档中规范引用，对于其应用是不可或缺的。 对于注日期的引用文件，只有引用的版本适用。 对于未注明日期的引用文件，适用最新版本的引用文件（包括任何修订）。
第1部分：OPC UA规范：第2部分 - 安全模型
http://www.opcfoundation.org/UA/Part1/
第4部分：OPC UA规范：第4部分 - 服务
http://www.opcfoundation.org/UA/Part4/
第5部分：OPC UA规范：第5部分 - 信息模型
http://www.opcfoundation.org/UA/Part5/
第6部分：OPC UA规范：第6部分 - 映射
http://www.opcfoundation.org/UA/Part6/
第7部分：OPC UA规范：第7部分 - 配置文件
http://www.opcfoundation.org/UA/Part7/
第12部分：OPC UA规范：第12部分 - 发现
http://www.opcfoundation.org/UA/Part12/
SOAP第1部分：SOAP版本1.2第1部分：消息传递框架
http://www.w3.org/TR/soap12-part1/
SOAP第2部分：SOAP版本1.2第2部分：辅助
http://www.w3.org/TR/soap12-part2/
XML加密：XML加密语法和处理
http://www.w3.org/TR/xmlenc-core/
XML签名：XML签名语法和处理
http://www.w3.org/TR/xmldsig-core/
WS Security：SOAP Message Security 1.1
http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
WS寻址：Web服务寻址（WS-Addressing）
http://www.w3.org/Submission/ws-addressing/
WS信任：Web服务信任语言（WS-Trust）
http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf
WS安全对话：Web服务安全对话语言（WS-SecureConversation）
http://specs.xmlsoap.org/ws/2005/02/sc/WS-SecureConversation.pdf
SSL / TLS：RFC 2246：TLS协议版本1.0
http://www.ietf.org/rfc/rfc2246.txt
X509：X.509公钥证书基础设施
http://www.itu.int/rec/T-REC-X.509-200003-I/e
HTTP：RFC 2616：超文本传输协议 - HTTP / 1.1
http://www.ietf.org/rfc/rfc2616.txt
HTTPS：RFC 2818：TLS over TLS
http://www.ietf.org/rfc/rfc2818.txt
IS词汇表：Internet Security术语表
http://www.ietf.org/rfc/rfc2828.txt
NIST 800-12：计算机安全简介
http://csrc.nist.gov/publications/nistpubs/800-12/
NIST 800-57：第3部分：应用程序特定的密钥管理指导
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_PART3_key-management_Dec2009.pdf
NERC CIP：CIP 002-1至CIP 009-1，由北美电气可靠性委员会负责
http://www.nerc.com/page.php?cid=2|20
IEC 62351：数据和通信安全
http://www.iec.ch/heb/d_mdoc-e050507.htm
SPP-ICS：系统保护简介 - 工业控制系统，由过程控制安全要求论坛（PCSRF）
http://www.isd.mel.nist.gov/projects/processcontrol/SPP-ICSv1.0.pdf
SHA-1：安全散列算法RFC
http://tools.ietf.org/html/rfc3174
PKI：Wikipedia中的公钥基础设施文章
http://en.wikipedia.org/wiki/Public_key_infrastructure
X509 PKI：互联网X.509公钥基础设施
http://www.ietf.org/rfc/rfc3280.txt
RFC 5958：不对称密钥包
http://tools.ietf.org/search/rfc5208
PKCS＃10：认证请求语法规范
http://tools.ietf.org/html/rfc2986
为了本文件的目的，第1部分中给出的术语和定义以及以下适用。
单独安装在一台计算机上运行的程序。同一应用程序可以有多个应用程序实例同时在多台计算机上运行，或者可能在同一台计算机上运行。
已安装在个人主机中的个人应用程序实例的数字证书。一个软件产品的不同安装将具有不同的应用实例证书。
使用一对密钥(一个为私钥并保密，另一个为公共密钥)的密码学方法。“非对称密码术”，也称为“公钥密码术”。在实体“A”对发送到实体“B”的数据需要保密性的非对称加密算法中，实体“A”用实体“B”提供的公共密钥加密数据。只有实体“B”具有解密数据所需的匹配私钥。在实体“A”需要消息完整性或为发送到实体“B”的数据提供认证时，在非对称数字签名算法中，实体A使用其私钥对数据进行签名。为了验证签名，实体B使用实体A提供的匹配公钥。在非对称密钥协商算法中，实体A和实体B各自向其他实体发送自己的公钥。然后每个使用自己的私钥和另一个的公钥来计算新的密钥值'根据IS词汇表。
非对称密码术用于使用实体的公钥加密数据并用相关联的私钥解密数据的机制。
非对称密码术用于使用实体的私钥对数据签名并用相关联的公钥验证数据签名的机制。
确保可以记录系统中的任何动作或活动的安全活动。
跟踪系统中的操作和活动，包括可以使用审计记录来审查和验证系统操作的安全相关活动。
确保可以验证客户端，服务器或用户等实体的身份的安全目标。
授予系统资源访问权限的能力。
确保系统正常运行的安全目标。也就是说，没有任何服务受到这种不可用或严重恶化的方式的损害。
可以发行数字证书的实体，也称为CA。数字证书通过证书的指定主题证明公钥的所有权。这允许其他（依赖方）依赖于通过认证的公钥对应的私钥签名或声明。在这种信任关系模型中，CA是受信任的第三方，由证书的主体（所有者）和依赖证书的一方信任。 CA是许多公钥基础设施（PKI）方案的特征。
存储证书和证书撤销列表（CRL）的持久位置。它可能是一个磁盘驻留文件结构，或者在Windows平台上可能是一个Windows注册表位置。
确保保护数据免受非预期方面的阅读的安全目标。
使用算法和密钥将清晰，有意义的信息转化为加密的，难以理解的形式。
由组织设计的程序，将整个组织的资产的安全性保持在既定的保密性，完整性和可用性水平，无论是在业务方面还是在组织的工业自动化和控制系统方面。
将身份与诸如用户，产品或应用实例的实体相关联的结构，其中证书具有关联的非对称密钥对，其可以用于认证该实体确实具有私钥。
使用加密算法计算并附加到数据，使得数据的任何接收者可以使用签名来验证数据的来源和完整性。
算法如SHA-1，在计算上不可能找到映射到给定哈希结果的数据对象（“单向”属性）或映射到相同散列结果的两个数据对象（“碰撞 - 免费“财产），请参阅IS词汇表。
使用迭代哈希函数生成的MAC。
确保信息没有以未经授权的方式修改或销毁的安全目标，请参见IS词汇表。
协议用于在不安全的环境中建立两个实体之间的安全通信路径，由此两个实体应用特定的算法来安全地交换用于保护它们之间的通信的秘密密钥。密钥交换算法的典型示例是SSL / TLS中指定的SSL握手协议。
由使用秘密密钥（见对称密码术）的算法产生的短数据片段消息，借此消息的接收者可以通过使用相同的消息和秘密计算产生相同的MAC来检查消息的变化。
用于确保在两个实体之间发送的消息完整性的数字签名。有几种方法来生成和验证消息签名，但是它们可以被归类为对称（参见条款3.1.34）和不对称（参见3.1.5）。
强有力的实质性证据表明消息签名人和消息完整性的身份，足以防止一方成功否认原始提交或传递消息及其内容的完整性。
通常通过生成安全密钥的算法使用的随机数。
调用OPC UA服务的OPC UA客户端或执行这些服务的OPC UA服务器。
用于非对称密码术的一对加密密钥的私密组件。公钥和私钥始终作为一对生成，如果更新另一个，则另一个也必须更新。
用于非对称密码术的一对加密密钥的公开组件，请参见IS词汇表。公钥和私钥始终作为一对生成，如果更新另一个，则另一个也必须更新。
创建，管理，存储，分发和撤销基于非对称密码术的数字证书所需的一套硬件，软件，人员，策略和程序。核心PKI功能是注册用户并发布其公钥证书，在需要时撤销证书，并归档在较晚时间验证证书所需的数据。密钥对数据机密性可由证书颁发机构（CA）生成;要求私钥所有者生成自己的密钥对是一个好主意，因为它可以提高安全性，因为私钥不会根据IS词汇表传输。有关公钥基础设施的更多详细信息，请参阅PKI和X509 PKI。
不对称加密算法，由Ron Rivest,Adi Shamir和Leonard Adleman在1977年发明，见IS词汇表。
在OPC UA中，在OPC UA客户端和服务器之间建立的通过使用某些OPC UA服务彼此认证并且已经协商和应用了哪些安全参数的通信路径。
涉及使用相同密钥进行算法的两个不同步骤（如加密和解密，签名创建和签名验证）的密码学分支，请参见IS词汇表。
Symmetric Cryptography用于使用两个实体共享的加密密钥加密和解密数据的机制。
Symmetric Cryptography用于使用两个实体共享的加密密钥对数据进行签名的机制。然后通过再次生成数据的签名并比较这两个签名来验证签名。如果它们相同，则签名有效，否则密钥或数据与两个实体不同。
应用程序配置为信任的证书列表。
通过基于IP的网络创建安全通道的标准协议。
数字证书以X.509 v1,2或3定义的格式之一。X.509证书包含一系列数据项，并按该顺序计算数字签名。
AES高级加密标准
CA证书颁发机构
CRL证书撤销清单
CSMS网络安全管理系统
DNS域名系统
DSA数字签名算法
ECDH椭圆曲线Diffie-Hellman
ECDSA椭圆曲线数字签名算法
HMAC基于哈希的消息认证码
NIST国家标准技术研究所
PKI公钥基础设施
RSA公钥签名或加密算法，Rivest，Shamir，Adleman
SHA安全散列算法（多个版本存在SHA1，SHA256，...）
SOAP简单对象访问协议
SSL安全套接字层
TLS传输层安全性
UA统一架构
URI统一资源标识符
XML可扩展标记语言
本文档中的数字不使用任何特殊约定。在特定图中使用的任何惯例都会在图中说明。
OPC UA是在多个级别的工业设施的操作中的组件之间使用的协议：从高级企业管理到设备的低级直接过程控制。 OPC UA用于企业管理涉及与客户和供应商的交易。 这可能是工业间谍活动或破坏活动的有吸引力的目标，也可能通过在公共网络上传播的无目标恶意软件（如蠕虫）来暴露威胁。 过程控制中的通信中断可能会导致财务损失，影响员工和公共安全或造成环境破坏。
OPC UA将部署在各种各样的操作环境中，对威胁和可访问性以及各种安全策略和执行制度有不同的假设。 因此，OPC UA提供了一套灵活的安全机制。 图1是显示这种环境的组合的复合体。 一些OPC UA客户端和服务器位于同一台主机上，可以方便地防止外部攻击。 一些客户端和服务器位于同一操作网络中的不同主机上，并且可能受到将操作网络与外部连接分离的安全边界保护的保护。 一些OPC UA应用程序在相对开放的环境中运行，用户和应用程序可能难以控制。 其他应用程序嵌入在与外部系统无直接电子连接的控制系统中。
从根本上说，信息系统的安全性降低了攻击的危害。它通过识别系统的威胁，识别系统对这些威胁的脆弱性，并提供对策来实现。对策直接减少漏洞，抵御威胁，或从成功的攻击中恢复。
工业自动化系统的安全是通过满足一系列目标实现的。这些目标已经通过多年的信息系统安全经验得到改进，尽管系统面临着越来越多的威胁，但它们仍然保持不变。它们在子条款5.1和子条款5.2中进行了描述，将这些目标与OPC UA功能相协调。第6条为客户端和服务器开发人员或部署OPC UA应用程序的用户提供了其他最佳实践指南。
客户端，服务器和用户等实体应该证明自己的身份。认证可以根据实体，拥有或知道的内容。
读取，写入或执行资源的访问权限应仅限于在系统要求中需要访问的那些实体。授权可以像允许或不允许客户端访问服务器一样粗糙，或者可能会更细微，例如允许特定用户对特定信息项进行特定操作。
保护数据免受被动攻击，例如窃听，数据是否被传输，存储器中或被存储。为了提供机密性，使用特殊密钥数据加密算法来保护数据，并使用身份验证和授权机制访问该密钥。
收件人收到原始发件人发送的相同信息，而传输过程中数据不被更改。
必须记录系统的操作，以便于向利益相关者提供证据：
•该系统按预期工作（成功的操作被跟踪）。
•识别某些操作的发起者（跟踪用户活动）。
•企图破坏系统被拒绝（跟踪不成功的行为）。
当需要运行的软件的执行被关闭或软件通信系统输入处理溢出的时候，可用性受到损害。OPC UA受损的可用性可能会降低订阅性能或无法添加会话。
OPC UA提供对策，以抵御所传输信息受到安全性的威胁。 子条款4.3.2, 4.3.3, 4.4.4, 4.3.5, 4.3.6, 4.3.7, 4.3.8, 4.3.9, 43.10和4.3.11列出了当前已知的对环境的威胁 其中将部署OPC UA，并且子条款5.1将这些威胁与OPC UA功能相协调。
攻击者可以发送大量消息或包含大量请求的单个消息，目的是压倒OPC UA服务器或相关组件，如CPU，TCP / IP协议栈，操作系统或文件系统。洪泛攻击可以在多个层进行，包括OPC UA，SOAP，[HTTP]或TCP。
消息洪泛攻击可以使用格式正确和格式错误的消息。在第一种情况下，攻击者可能是使用合法客户端的使用请求来洪泛攻击服务器的恶意人员。存在两种情况，其中一个是客户端没有与服务器的会话，而另一个有会话(Session )。消息洪泛可能会损害建立OPC UA会话的能力或终止现有会话。在第二种情况下，攻击者可能会使用恶意客户端，洪泛化具有格式错误的消息的OPC UA服务器，以耗尽服务器的资源。
一般来说，洪泛消息可能会损害与OPC UA实体进行通信的能力并导致拒绝服务。消息洪泛影响可用性。有关这一威胁的调节见5.1.2。
窃听是未经授权的披露敏感信息可能直接导致严重安全漏洞或用于后续攻击。
如果攻击者已经破坏了底层操作系统或网络基础架构，则攻击者可能能够记录和捕获消息。 可能导致客户端或服务器从受影响的操作系统无法恢复。
窃听影响保密性直接和间接地威胁所有其他安全目标。有关这一威胁的调节见5.1.3。
攻击者可能伪造来自客户端或服务器的消息。欺骗可能发生在协议栈的多个层。
通过来自客户端或服务器的欺骗消息，攻击者可能会执行未经授权的操作，并避免被检测到其操作。
消息欺骗影响完整性和授权。有关这一威胁的调解见5.1.4。
网络传输层和应用层消息可能被捕获或修改并转发到OPC UA客户端和服务器。 消息更改可能允许非法访问系统。消息更改影响完整性和授权。有关这一威胁的调解见5.1.5。
网络传输层和有效的应用层消息可以被捕获并在稍后阶段将其重新发送到OPC UA客户端和服务器，而无需修改。攻击者可能会误导用户或发送有效的命令，例如在不正确的时间打开阀门，以致造成损坏或财产损失。消息重播影响授权。有关这一威胁的调解见5.1.6。
攻击者可以使用无效的消息结构（格式不正确的XML，SOAP，UA二进制等）或数据值生成各种消息，并将其发送到OPC UA客户端或服务器。
通过执行未经授权的操作或处理不必要的信息，OPC UA客户端或服务器可能会错误地处理某些格式错误的消息。 这可能导致服务的拒绝或退化，包括终止应用程序，或者在嵌入式设备的情况下，完全崩溃。 在最坏的情况下，攻击者可以使用格式错误的消息作为多级攻击的前提，以访问OPC UA应用程序的底层系统。
格式错误的消息会影响完整性和可用性。有关这一威胁的调解见5.1.7。
攻击者尝试推断服务器或客户端的身份，类型，软件版本或供应商，以便应用有关该产品的特定漏洞的知识来安装更具侵入性或破坏性的攻击。 攻击者可以通过向目标发送有效或无效的格式化消息来配置目标，并通过其正常和错误响应的模式尝试识别目标的类型。
服务器分析会间接影响所有的安全目标。有关此威胁的和解，请参阅5.1.8。
攻击者可以使用关于在两个应用程序之间建立的正在运行的会话的信息（通过嗅探通信或通过猜测）来注入操纵的消息（具有有效的会话信息），允许他或她从授权用户接管会话。
攻击者可能未经授权访问数据或执行未经授权的操作。会话劫持影响所有的安全目标。有关这一威胁的调解见5.1.9。
攻击者构建恶意的OPC UA服务器或安装未经授权的真实OPC UA服务器实例。
OPC客户端可能会披露必要的信息。木马服务器影响除完整性(Integrity)之外的所有安全目标。有关这一威胁的调解见5.1.10。
攻击者通过观察纸张，屏幕或电子通信，或通过猜测或使用自动化工具（如密码破解者）来获得用户名，密码，证书或密钥等用户账号。
未经授权的用户可以启动和访问系统以获取所有信息，并进行控制和数据更改，从而损害工厂操作或信息。 一旦使用了compromised的账号，后续活动可能都是合法的。
compromised用户账号影响授权和保密。有关这一威胁的和解，请参见5.1.11。
OPC UA安全工程工作在网站的整体网络安全管理系统（CSMS）中。站点通常有一个CSMS来解决安全策略和过程，人员，责任，审计和物理安全。 CSMS通常解决包括4.3中描述的那些威胁。他们还分析安全风险，并确定网站需要的安全控制。
最终的安全控制通常实施“深度防御”策略，提供多层保护，并认识到没有一个层可以防止所有攻击。边界保护（如图1中的抽象示例所示）可能包括防火墙，入侵检测和预防系统，拨号连接控制，以及进入系统的媒体和计算机上的控制。系统组件的保护可能包括操作系统的硬件配置，安全补丁管理，防病毒程序，以及不允许控制网络中的电子邮件。站点可能遵循的标准包括第2条中引用的[NERC CIP]和[IEC 62351]。
站点CSMS的安全要求适用于其OPC UA接口。也就是说，部署在站点的OPC UA接口的安全要求由站点指定，而不是OPC UA规范。 OPC UA指定旨在使一致的客户端和服务器产品能够满足预期由其部署的站点进行的安全性要求的功能。负责现场安全的人员应确定如何使用OPC UA一致的产品来满足现场要求。
安装OPC UA客户端或服务器的系统所有者应分析其安全风险，并提供适当的机制来减轻这些风险，以达到可接受的安全级别。 OPC UA满足了个别分析可能产生的各种安全需求。 OPC UA客户端和服务器需要使用某些可用于系统所有者可选用途的安全功能来实现。 每个系统所有者应该能够使用OPC UA规范中可用的机制和OPC UA外部的组合来定制满足其安全性和经济需求的安全解决方案。
对站点上部署的OPC UA客户端和服务器的安全性要求由站点CSMS指定，而不是OPC UA规范。 然而，OPC UA安全规范是对OPC UA客户端和服务器产品的要求，以及如何在现场部署OPC UA以满足预期在现场指定的安全要求的建议。
OPC UA解决了4.3中所述的一些威胁。 OPC基金会建议客户端和服务器开发人员解决其他威胁，如第6章所述。对于可能导致客户端和服务器操作系统的危害的基础架构组件的威胁，OPC UA无法解决。
OPC UA安全架构是一种通用解决方案，允许在OPC UA应用程序架构的各个地方实现所需的安全功能。 根据第6部分描述的不同映射，安全目标在不同层次上得到解决。 OPC UA安全架构在传输层顶部的应用层和通信层中构成，如图2所示。
客户端应用程序和服务器应用程序传输信息，设置和命令的日常工作在应用层中的会话中完成。 应用层还管理用户认证和用户授权的安全目标。 由应用层管理的安全目标由第4部分中指定的会话服务来解决。应用层中的会话通过在通信层中创建的安全通道进行通信，并依靠它进行安全通信。 所有会话数据都传递给通信层进行进一步处理。
虽然会话通过安全通道进行通信，并且必须在使用之前激活，但是用户，会话和安全通道的绑定是灵活的。
规则允许用户拥有现有会话(Session )的所有权。
如果安全通道中断，会话将保持有效期一段时间，允许客户端通过新的安全通道重新建立与会话的连接。 否则，会话在其生命周期终止后关闭。
通信层提供了安全机制，以保密性，完整性和应用认证为安全目标。
满足上述安全目标的一个重要机制是建立一个安全通道（见4.11），用于保护客户端与服务器之间的通信。安全通道提供加密以维护保密性，消息签名来维护完整性，数字证书提供应用程序来自应用层的数据的认证，并将“安全”数据传递给传输层。由通信层管理的安全机制由第4部分中指定的安全通道服务提供。
由安全通道服务提供的安全机制由为执行选择的协议栈实现。在第6部分中规定了某些协议栈选项的服务映射，定义了如何使用协议栈中的功能来满足OPC UA安全目标。
通信层可以表示OPC UA协议栈。 OPC UA指定可用作通信层的替代堆栈映射。这些映射在第6部分中描述。
如果使用OPC UA本地映射，则保密性，完整性，应用程序验证和安全通道的功能与SSL / TLS规范类似，如第6部分所述。
如果使用Web服务映射，则使用WS Security，WS安全对话和XML加密以及XML签名来实现机密性，完整性，应用程序验证以及实施安全通道的机制。有关更多具体信息，请参阅第6部分。
传输层处理由通信层提供的数据的传输，接收和传输。为了在传输层连接（例如TCP连接）的丢失下生存并且用新的连接恢复，通信层负责重新建立传输层连接而不中断逻辑安全信道。
安全策略(SecurityPolicies)指定要使用哪些安全机制，并从安全配置文件导出（有关详细信息，请参阅4.7）。服务器使用安全策略来通知其支持哪些机制，并由客户端选择要与其希望打开的安全通道一起使用的安全策略。 SecurityPolicies包括以下信息：
•签名和加密算法
•密钥生成算法
SecurityPolicy的选择通常由管理员在安装客户端和服务器产品时进行。可用的安全策略在第7部分中指定。管理员以后可以根据情况要求更改或修改SecurityPolicies的选择。
安全策略的公告由第4部分中规定的特殊发现服务处理。有关发现机制和策略公告的更多详细信息，请参见第12部分。
如果服务器服务多个客户端，那么它为每个客户端维护单独的策略选择。这允许新客户端选择独立于其他客户端为其安全渠道选择的策略选项的策略。
由于计算能力每年都在增加，今天被认为是安全的特定算法可能会变得不安全，因此，在OPC UA应用程序中支持不同的安全策略是有意义的，并且能够在可用时采用更多的安全策略。 NIST或其他机构甚至可以预测算法的预期使用寿命(参见NIST 800-57)。支持的安全策略列表将根据NIST发布的建议进行更新。 从部署的角度来看，定期站点审查检查当前选择的安全配置文件列表是否仍然满足所需的安全性目标很重要，如果没有，则选择新的安全配置文件。
还有一种新的安全策略是为了支持提高OPC UA产品安全级别的新算法而组建的。 OPC UA客户端和服务器的应用程序体系结构应该设计成可以对应用程序进行更新或添加附加的加密算法，而不需要更改编码。
第7部分指定了由特定唯一URI标识的几个策略。 为了提高供应商产品之间的互操作性，服务器产品实施这些策略，而不是自己定义。 客户支持相同的策略。
OPC UA客户端和服务器产品经过第7部分定义的Profiles 认证。某些Profiles指定安全功能，而其他配置文件指定与安全性无关的其他功能。Profiles对认证产品施加要求，但不对产品的使用方式施加要求。各种配置文件需要一致的最低安全级别。但是，不同的配置文件指定了不同的细节，例如哪个OPC UA功能需要哪些加密算法。如果在一个加密算法中出现问题，那么OPC基金会可以定义一个类似的新Profile，但是它指定了一个不具有已知问题的不同加密算法。第7部分是规范性规范。
由于配置文件，策略涉及许多相同的安全选择;但是该策略规定了在会话中使用哪些选择。该策略没有指定产品提供的选择范围，它们在其支持的“配置文件”中进行了描述。
这些策略包含在与OPC UA客户端和服务器相关联的认证测试中。认证测试确保遵循标准，并支持适当的安全算法。
OPC UA中的每个安全机制根据客户端或服务器遵循的配置文件在客户端和服务器产品中提供。然而，在现场，可以可选地部署安全机制。以这种方式，每个单独的站点都具有可用的所有OPC UA安全功能，并且可以选择其中哪些用于满足其安全目标。
OPC UA提供了一种交换用户凭据的机制，但不指定应用程序如何使用这些凭据。 客户端和服务器应用程序可以以自己的方式确定哪些数据可访问以及哪些操作被授权。 存在配置文件以指示用户凭据的支持来限制或控制对数据的访问。
当客户端通过会话服务（第4部分描述）指定的方式将用户凭据传递给服务器时，实现用户身份验证。 服务器可以使用这些凭据来验证用户。可以使用ActivateSession服务更改会话的所有者（用户），以满足应用程序的需要。
OPC UA使用传达应用程序认证的概念来允许打算进行通信的应用程序进行识别。 每个OPC UA应用实例都具有在安全通道建立期间进行交换的数字证书（应用程序实例证书）。 证书的接收方检查信托证书，并根据此检查，它接受或拒绝来自发件人的请求或响应消息。 该信任检查使用TrustLists的概念完成。 TrustLists是由管理员指定的CertificateStore。 管理员在将证书放入TrustList之前，确定证书是否已签署，验证和可信。 TrustLists通常还包括证书撤销列表（CRL）。OPC UA利用其他组织定义的这些行业标准概念。在OPC UA中可以使用HTTPS创建安全通道，但是这些通道不提供应用验证。 如果需要验证，则基于用户凭据。
有关应用程序认证的更多详细信息，请参见第4部分。
OPC UA安全服务是第4部分中规定的一组抽象服务定义，用于将各种安全机制应用于OPC UA客户端和服务器之间的通信。
发现服务集（在第4部分中指定）定义OPC UA客户端使用的服务，以获取有关安全策略（见4.6）和特定OPC UA服务器的数字证书的信息。
安全通道服务集（第4部分中指定）的服务用于建立安全通道，该通道负责保护客户端和服务器之间发送的消息。安全渠道建立的挑战在于，它要求客户端和服务器在不安全的环境中安全地交换密码密钥和秘密信息，因此特定的密钥交换算法（类似于SSL / TLS中定义的SSL握手协议）被应用于沟通参与者。
OPC UA客户端通过上述发现服务检索OPC UA服务器的安全策略和数字证书。这些数字证书包含OPC UA服务器的公共密钥。
OPC UA客户端通过OpenSecureChannel服务消息发送其数字证书中的公钥和秘密信息到服务器，这些信息通过使用服务器的公钥非对称加密，并通过使用客户端的私钥生成非对称签名来保护此消息。然而，数字证书未加密发送，以便接收方可以使用它来验证非对称签名。
服务器使用其私钥解密消息，并使用客户端的公钥验证不对称签名。 OPC UA客户端的秘密信息连同OPC UA服务器的秘密信息一起用于派生一组用于保护所有其他消息的加密密钥。此外，所有其他服务消息都使用对称加密和对称签名来保护，而不是不对等体。
服务器将服务响应中的秘密信息发送给客户端，以便客户端可以导出相同的密码密钥集。
由于客户端和服务器具有相同的加密密钥集，它们可以彼此安全地通信。
这些导出的加密密钥被周期性地改变，使得攻击者没有无限的时间和不受限制的消息序列用于确定密钥是什么。
客户端和服务器生成成功和不成功的连接尝试的审计记录，安全选项协商的结果，配置更改，系统更改，用户交互和会话拒绝。
OPC UA通过两种机制提供对安全审计跟踪的支持。首先，它提供了客户端和服务器审核日志之间的可追溯性。客户端生成包含请求的操作的审核日志条目。当客户端发出服务请求时，它会生成审核日志条目，并在发送到服务器的请求中包含日志条目的本地标识。服务器会记录它收到的请求，并在其审核日志条目中包含客户端的条目ID。以这种方式，如果在服务器上检测到与安全相关的问题，则可以找到并检查关联的客户端审核日志条目。 OPC UA不要求将审核条目写入磁盘，但它要求它们可用。 OPC UA提供了服务器生成事件通知的功能，该事件通知可将可审核事件报告给能够处理和记录的客户端。有关OPC UA中的服务如何审核的详细信息，请参阅第4部分。
第二，OPC UA定义审计参数，以包含在审计记录中。这提高了审计日志和审计事件之间的一致性。第5部分定义了这些参数的数据类型。其他信息模型可能会扩展审计定义。第7部分定义配置文件，其中包括生成审核事件并使用这些参数的能力,包括客户端审核记录ID。
由于审核日志用于证明系统安全运行，审核日志本身也可以防止未经授权的篡改。如果未经授权的人员能够更改或删除日志记录，则可能会隐藏实际或尝试的安全漏洞。因为生成和存储审计日志（例如文件或数据库）有许多不同的方法，所以安全审核日志的机制不属于本规范的范围。
此外，审核记录中的信息可能包含敏感或私人信息，因此订阅审核事件的能力仅限于适当的用户和/或应用程序。作为替代方案，具有敏感或私人信息的字段可以包含错误代码，指示对没有适当权限的用户拒绝的访问。4.12.2，4.12.3，4.12.4和4.12.5中的条款说明了支持审计的OPC UA服务器和客户端的行为。
图3说明了客户端与服务器通信的简单情况。
在这种情况下，OPC客户端“A”执行一些可审核的操作，包括在服务器“D”中调用OPC UA服务。 它写入自己的审核日志条目，并将该条目的标识符包含在提交给服务器的服务请求中。
服务器接收请求并为其创建自己的审核日志条目。 此条目由其自己的审核ID标识，并包含其自己的审核信息。 它还包括发出服务请求的客户端的名称和请求中接收的客户端审核条目标识。使用此信息，审核员可以检查服务器的日志条目的收集，并将其与相关的客户端条目相关联。
图4说明了客户端从聚合服务器访问服务的情况。 聚合服务器是通过访问被称为低层服务器的其他OPC UA服务器的服务来提供服务的服务器。
在这种情况下，每个服务器都会接收请求并为其创建自己的审核日志条目。 每个条目都由其自己的审计ID标识，并包含自己的审计信息。 它还包括发出服务请求的客户端的名称和请求中接收的客户端审核条目标识。 然后，服务器将其创建的条目的审核ID传递给链中的下一个服务器。
使用此信息，审核员可以检查服务器的日志条目，并将其与相关的客户端条目相关联。
在大多数情况下，服务器将仅生成审核事件，但这些审核事件仍将包含与审核日志记录相同的信息。 在汇总服务器的情况下，还需要服务器从其汇总的服务器订阅审核事件。 以这种方式，服务器“B”将能够向客户端“A”提供所有审核事件，包括服务器“C”和服务器“D”生成的事件。
图5说明了客户端从不支持审核的聚合服务器访问服务的情况。
在这种情况下，每个服务器都会接收请求并为他们创建自己的审核日志条目，但服务器“B”不支持审核。 在这种情况下，服务器“B”将从客户端“A”接收到的审核ID传递到下一个服务器。 这将创建所需的审计链。
服务器“B”未列为支持审计。 在服务器不支持写入审核条目的情况下，整个系统可能被视为不支持审核。
在不支持审计的聚合服务器的情况下，仍然需要服务器从其汇总的服务器订阅审核事件。 以这种方式，服务器“B”将能够向客户端“A”提供所有审计事件，包括由服务器“C”和服务器“D”生成的事件，即使它没有生成审核事件。
图6示出了向聚合服务器提交服务请求的客户端的情况，并且聚合服务通过向其底层服务器提交多个服务请求来支持该服务。
在聚合服务器的情况下，将需要服务器从其汇总的服务器订阅审核事件。 以这种方式，服务器“B”将能够向客户端“A”提供所有审核事件，包括服务器“C”和服务器“D”生成的事件。
子条款5.1.2,5.1.3,5.1.4,5.1.5,5.1.6,5.1.7,5.1.8,5.1.9,5.1.10和5.1.11解决了在4.3中针对OPC UA功能所描述的威胁。 与5.2中将提供的目标的实现方案相比，这是一个更具体的实现方案，将OPC UA安全功能与特定威胁相关联。
有关此威胁的说明，请参阅4.3.2。
OPC UA通过最小化消息验证之前消息的处理量来最大限度地减少由消息洪泛引起的可用性损失。这样可以防止攻击者利用少量的努力来使合法的OPC UA应用程序花费大量的时间来响应，从而将处理资源从合法活动中移除。
GetEndpoints（在第4部分中指定）和OpenSecureChannel（在第4部分中指定）是服务器在客户端进行身份验证之前处理的唯一服务。对GetEndpoints的响应只是一组静态信息，所以Server不需要做很多处理。由于签名和加密处理，对OpenSecureChannel的响应会消耗重要的服务器资源。 OPC UA已经最小化了这个处理，但不能消除。
Server实现可以通过两种方式保护自己免受OpenSecureChannel消息的洪泛。
首先，一旦接收到超过一些最低数量的不良OpenSecureChannel请求，服务器可能有意延迟对OpenSecureChannel请求的处理。它还应该发出警报，警告工厂人员正在进行的攻击，可能会阻止新的合法OpenSecureChannel调用。
其次，当OpenSecureChannel请求尝试超出服务器指定的并发通道的最大数量时，服务器将回复错误响应，而不执行签名和加密处理。认证的OPC UA服务器需要根据第7部分的规定在其产品文档中指定其最大并发通道数。
OPC UA用户和客户端身份验证可降低合法客户端用于装载洪泛攻击的风险。请参阅5.2.3中的验证对帐。
OPC UA审核功能为网站提供了证据，可以帮助网站发现洪水攻击正在挂载，并设法防止类似的未来攻击（见4.12）。作为最佳做法，应监视审计事件的过多连接请求。
OPC UA依靠站点CSMS来防止在支持OPC UA的协议层和系统上的信息泛滥等攻击。
有关此威胁的说明，请参阅4.3.3。
OPC UA提供加密以防止窃听，如5.2.5所述。
有关此威胁的说明，请参阅4.3.4。
如第4部分和第6部分所述，OPC UA通过提供签署消息的能力来计数消息欺骗威胁。 此外，消息将始终包含有效的会话ID，安全通道ID，请求ID，时间戳以及正确的序列号。
有关此威胁的说明，请参阅4.3.5。
OPC UA计数器通过签名第4部分中指定的消息进行消息更改。如果消息更改，检查签名将显示任何更改，并允许收件人放弃该消息。 此检查还可以防止由于通信传输错误引起的无意的消息更改。
有关此威胁的说明，请参阅4.3.6。
OPC UA为每个请求和响应消息使用会话ID，安全通道ID，时间戳，序列号和请求ID。消息是签名的，不能被检测而无法更改，因此重播消息将非常困难，使得消息将具有有效的会话ID，安全信道ID，时间戳，序列号和请求ID。 （所有这些在第4部分和第6部分中规定）。
有关此威胁的说明，请参阅4.3.7。
OPC UA客户端和服务器产品的实施通过检查消息具有正确的形式以及消息的参数是否在其合法范围内来防范格式错误的消息的威胁。无效的邮件被丢弃。这在第4部分和第6部分中有规定。
有关此威胁的说明，请参阅4.3.8。
OPC UA限制了服务器向尚未确定的客户端提供的信息量。此信息是对第4部分中指定的GetEndpoints服务的响应。
有关此威胁的说明，请参阅4.3.9。
OPC UA计数器通过为第4部分中的CreateSession服务中指定的每个会话分配安全上下文（即安全通道）来进行会话劫持。因此，劫持会话将首先要求获取安全上下文。
有关此威胁的说明，请参阅4.3.10。
OPC UA客户端应用程序通过验证服务器应用程序实例证书来计算使用流氓服务器。仍然存在流氓服务器从认证的OPC UA服务器提供证书的可能性，但是由于它不具有适当的私钥（因为这将永远不会被分发）来解密和验证使用正确的公钥保护的消息流氓服务器永远无法读取和误用客户端发送的安全数据。
有关此威胁的说明，请参阅4.3.11。
OPC UA保护通过网络发送的用户凭据，如5.2.5所述。
OPC UA取决于站点CSMS以防止其他攻击获得用户凭据，如密码猜测或社会工程。
子条款5.2.2,5.2.3,5.2.4,5.2.5,5.2.6,5.2.7和5.2.8解决了4.2中描述的OPC UA功能。 与5.1的reconciliation威胁相比，这种方案证明了OPC UA安全架构的完整性。
OPC UA应用程序支持与他们进行通信的实体的身份验证。如第4部分中的GetEndpoints和OpenSecureChannel服务中指定的，OPC UA客户端和服务器应用程序使用X.509证书来标识和验证自己（参见[X509]）。通信堆栈的一些选择需要这些证书来表示机器或用户，而不是应用程序。
OPC UA应用程序通过向其他实体提供必要的身份验证凭据来支持用户身份验证。如第4部分中的OpenSecureChannel服务所述，OPC UA客户端从用户接受UserIdentityToken，并将其传递给OPC UA服务器。 OPC UA服务器验证用户令牌。 OPC UA应用程序接受以下三种形式的令牌：username / password，X.509v3证书（参见[X509]）或WS-SecurityToken。
如第4部分中的CreateSession和ActivateSession Services中所述，如果UserIdentityToken是数字证书，则此令牌将通过质询 - 响应过程进行验证。服务器在其CreateSession响应中提供了一个随机数和签名算法作为挑战。客户端通过签署服务器的随机数并在随后的ActivateSession调用中将其提供为参数来应对挑战。
OPC UA不指定如何提供用户或客户端授权。 OPC UA作为较大型工业自动化产品的一部分的应用程序可以管理与该产品的授权管理一致的授权。在OPC UA中指定用户的身份和身份验证，以便客户端和服务器应用程序可以识别用户以确定用户的授权级别。
OPC UA服务器使用Bad_UserAccessDenied错误代码进行响应，以指示第4部分中定义的状态代码中指定的授权或验证错误。
OPC UA使用对称和非对称加密来保护机密作为安全目标。因此，非对称加密用于密钥协商和对称加密，用于保护OPC UA应用程序之间发送的所有其他消息。加密机制在第6部分中规定。
OPC UA依靠CSMS站点保护网络和系统基础设施上的保密性。 OPC UA依靠PKI来管理用于对称和非对称加密的密钥。
OPC UA使用对称和非对称签名来将Integrity作为安全目标。在安全通道建立期间，非对称签名用于密钥协商阶段。对称签名应用于所有其他消息。
OPC UA依靠站点CSMS来保护网络和系统基础架构上的Integrity。 OPC UA依靠PKI来管理用于对称和非对称签名的密钥。
根据第4部分的UA审核说明中的说明，OPC UA通过启动，转发和处理活动的多个客户端和服务器的日志条目提供活动的可跟踪性来支持审核日志记录。 OPC UA取决于OPC UA应用程序产品，以提供有效的审计记录方案或收集所有节点的审核事件的有效方式。该方案可能是OPC UA应用程序的更大的工业自动化产品的一部分。
OPC UA可以最大限度地减少5.1.2中描述的消息洪泛的影响。
对可用性的一些攻击包括打开比服务器可以处理的更多的会话，从而导致服务器失败或操作不良。 服务器拒绝超出其指定最大数量的会话。 OPC UA的其他方面，如OPC UA安全对话或WS安全对话也可能影响可用性，并在第6部分中讨论。
条款6为实施OPC UA应用程序的供应商提供指导。由于解决上述威胁所需的许多对策都不属于OPC UA规范的范围，因此第6条中的建议表明应该如何提供其中的一些对策。
对于以下每个领域，第6条定义问题空间，如果没有实施适当的对策，则确定后果，并建议最佳做法。
超时，实现等待的时间（通常是诸如消息到达之类的事件）在影响实现的安全性方面发挥非常重要的作用。潜在的后果包括
•拒绝服务：如果超时超时，客户端不会重置会话，则可能会存在拒绝服务条件。
•资源消耗：当客户端长时间闲置时，服务器会保留客户端缓存的消息或该时段的信息，从而导致资源耗尽。
实施者应在每个连接阶段使用合理的超时。
规范通常指定正确消息的格式，并且对于偏离规范的消息，实现应该做什么。通常，这些实现继续解析这些数据包，导致漏洞。
实施者应对消息格式进行严格检查，并应丢弃数据包或发送错误消息，如下所述。
•错误处理使用第4部分中定义的错误代码，它最符合条件，只有在返回错误代码时才适用。错误代码可以用作攻击向量，因此它们的用途应该如第4部分所述那样受到限制。第4部分描述了在建立安全通道之前和期间返回单个通用错误。一旦建立了安全通道，则返回适当的特定错误代码。
•可以使用的另一个攻击向量是时序变化;这通过第4部分中的描述被最小化，需要在建立安全通道时关闭插座以用于任何错误。供应商在其实现中应该小心，以确保导致关闭套接字的所有路径不提供指示遇到哪个失败路径的时间提示。这可以通过在关闭套接字之前或返回一般错误代码之前具有随机延迟来实现。
应严格执行和处理所有数组长度，字符串长度和递归深度。
满足安全需求的随机数可以由加密库提供的适当功能生成。 通常的随机函数如使用由“C”标准库提供的rand()不会产生足够的熵。 作为替代方案，实现者可以使用由Microsoft Windows Crypto库（WinCrypt库）或OpenSSL提供的随机数生成器。 即使加密库中提供的随机函数也需要初始化熵源，并且嵌入式设备上并不总是可以使用所需的熵。PC可以使用几个单独的信息（像CPU，Mac，地址，USB设备，屏幕分辨率 ，安装软件...）来生成熵，但嵌入式设备完全相同。 通常只有时间，也可能是一个MAC地址为熵。 这些熵的来源可以被猜测或发现。 这使得嵌入式设备非常脆弱。
常见的错误是在第一次启动期间生成加密密钥。因此，即使时间信息是可预测的（创建时间例如存储在证书中）。供应商可能会考虑的一些替代解决方案：
•在设计嵌入式设备时添加特定的熵产生器硬件。
•不要在嵌入式设备上生成证书。使用外部工具或GDS生成证书并将其加载到设备上。对称密钥可能仍然存在问题，因为通常不会在引导阶段直接创建对称密钥。而是当客户端连接时创建它们。
•等待足够长的时间，直到有足够的熵信息可用。有些操作系统在达到这一点时会提供提示。
•对于没有良好熵源的嵌入式系统，可能有助于存储加密伪随机数生成器（CPRNG）状态，以便每次启动后不会产生相同的随机数。
供应商应确保使用合适的熵来初始化其使用的加密功能，并且生成的证书不会以可预测的方式创建。
实现理解并正确解释保留为特殊的任何消息类型（如IP规范中的广播和组播地址）。没有理解和解释这些特殊的数据包可能会导致漏洞。
OPC UA不提供速率控制机制，但是实现可以包括速率控制。
OPC UA描述了某些功能，例如CertificateStores的管理，应该仅限于管理员。此多部分标准不描述与管理访问相关的详细信息。管理权限的性质因平台而异。一些平台只有一个管理员。其他平台提供多级管理访问，例如备份管理员，网络管理员，配置管理员等。部署站点应对管理员访问进行适当选择，实施者应允许配置适当的管理员帐户访问。
第7部分中定义的安全性配置文件描述了所需的算法和所需的密钥长度。密钥长度要求可以指定为范围，即1024-2048。一个应用程序支持其应用程序实例证书的整个范围非常重要。这允许最终用户生成满足其安全要求的密钥（应用实例证书）。这可能会延长给定安全性配置文件可以使用的时间段。例如，长度小于2048的密钥长度已经被认为是不安全的，但是如果最终用户为范围的高端生成证书（2048），那么应用程序可能仍然被视为安全的（取决于其他算法）。
OPC UA支持强大的报警和条件信息模型，其中包括禁用报警，搁置报警和通常管理报警的功能。报警处理和管理是维持厂房有效控制的重要环节。从安全角度看，这条道路必须得到充分的保护，以确保流氓代理人不会造成危险或财务状况。 OPC UA提供了此保护所需的工具，但实施者需要确保正确运行。所有允许更改运行环境的功能都可以生成审核事件，并且仅限于适当的用户。
禁用警报是一个这样的功能，应该限于具有适当访问权限的人员。此外，无论是由人员还是某些自动化系统启动，任何禁用警报的操作都应生成一个指示该操作的审核事件。
报警器的搁置应遵循与访问和审计相关的警报禁用相似的指导原则，尽管它可能适用于更广泛的用户（操作人员，工程师）。此外，实施者应确保为报警搁置配置适当的超时。这些超时应确保警报不能被搁置一段时间，这可能会导致安全问题。
对话活动也可用于重载客户端。对于支持对话框的服务器来说，限制可能处于活动状态的并发对话框数量将是最佳做法。此外，对话框应包括一些超时期限，以确保它们不被用于创建DOS。客户端实现者还应确保任何对话处理不能用于压制操作员。应限制打开对话框的最大数量，并且对话框应该被忽略（即其他处理仍然可用）。
OPC UA描述了允许程序作为OPC UA服务器一部分执行的功能。这些程序可用于执行高级控制算法或其他操作。这些行为的使用应限于具有适当访问权限的人员。此外，应仔细监测“方案”的定义。建议除了执行频率之外，还要保留有关定义程序数量的统计数据。此信息可供管理人员使用。在任何情况下，不应允许无限数量的程序执行。
OPC UA规范描述了要生成的审计事件以及这些审计事件至少包含的信息，但是规范没有描述这些审计事件在生成后如何处理。审计事件可以由多个审计跟踪系统或日志记录系统订阅。 OPC UA规范不描述这些系统。假设任何数量的供应商提供的系统都可以提供此功能。作为用于存储和管理的任何系统的最佳做法，审核事件应确保以下内容：
•审核事件收到后不会被篡改。
•审核活动订阅应通过安全渠道，以确保在转换期间不会被篡改。
•记录审核事件的客户端;建议记录的审核事件以这样的方式保持，即可以对审核事件进行身份验证并链接到原始事务。
审计事件管理系统可以根据站点CSMS有其他要求。
OPC UA提供了一些不需要访问安全性的服务。从安全角度来看，这些服务需要特别考虑。这些服务提供了允许客户端发现服务器并连接到它们的功能。发现服务可作为本地服务或全球服务提供，可以进行组播。
OPC UA可以配置为以多种方式支持发现。其中一个选择是多播发现。在这种类型的发现中，服务器在子网启动时会自动发布。应用程序机器或实际应用程序可以监听并构建可用服务器的列表。
组播DNS操作由于其性质而不安全;它们允许流氓服务器广播其存在或冒充其他主机或服务器。如果启用了OPC UA安全性，并且所有应用程序都使用证书信任列表来控制访问，则可以最小化Rogue服务器的风险。另外客户端应该缓存连接信息，最小化服务器信息的查找。但是，即使您使用UA安全，也可以在攻击者轻松访问网络的环境中禁用多播DNS。
构建应用程序（或发现服务器）以确保它们不能由多播发现通道上的高广播速率或服务器应用程序列表过大或过高。
全球发现服务器（GDS）是一种特殊的OPC UA服务器，为工厂或整个系统提供发现服务。 此外，它还可以提供证书管理功能（参见第12部分）
访问GDS有多种方法：
1）服务器可以向发现服务器注册
2）客户端可以查询可用服务器的GDS
3）客户可以从GDS提取证书
4）服务器可以从GDS提取证书
5）GDS可以将证书推送到服务器
6）GDS可以访问其他发现服务器来构建可用服务器的列表。
关于可用的访问方法，需要讨论几种类型的威胁：
•恶意GDS在系统中的威胁。
•针对GDS的威胁，包括流氓客户端或服务器的存在
•威胁GDS提供的证书管理功能。
在处理GDS时，以下准则很重要：
•服务器注册到配置为注册的发现服务器，并且服务器不会盲目注册尚未配置为注册的GDS，这一点非常重要。服务器必须意识到发现服务器可能是流氓服务器。
•服务器注册其提供的所有端点，确保发现服务器和服务器提供的列表匹配。这确保客户端可以确定发现服务器是否提供有效信息。
•客户端应该知道可能导致他们流氓服务器的流氓发现服务器。客户端可以使用SSL / TLS服务器证书（如果可用）来验证发现服务器是否是他们信任的服务器和/或确保它们信任发现服务器提供的任何服务器。
•如第4部分所述，客户端始终验证它们是否信任服务器证书，并且在创建与服务器的会话之前，EndpointUrl与证书中指定的主机名匹配。在创建一个会话之后，它会查看服务器返回的EndpointDescriptions，并验证其使用的是最佳安全性，并且服务器的证书与客户端用于连接的证书相匹配。服务器提供的端点描述包括一个相对的SecurityLevel，用于确定是否使用最安全的端点。
如第4部分所述，FindServersOnNetwork服务可以在没有安全性的情况下使用，因此容易受到拒绝服务（DOS）攻击。发现服务器应最小化发送此服务的响应所需的处理量。这可以通过预先准备结果来实现。
GDS仅接受来自受信任或具有适当管理访问权限的服务器的服务器注册。这将有助于确保流氓服务器不会注册到GDS。
还提供证书管理的GDS，支持第12部分中描述的用户访问安全性。这包括将所有证书管理功能限制为管理员。此外，允许访问管理功能的客户端列表可能会受到限制。
证书管理包括配置阶段和运行时间阶段。配置阶段是当GDS向正在进入系统的客户端或服务器提供初始证书时。运行阶段是系统的日常操作，包括提供更新的CRL，证书更新和更新的信任列表。
系统的配置固有地不安全，但在提供复杂系统的大大简化部署方面可能非常有用。默认情况下不启用GDS中的配置，但需要启用管理操作。还建议配置功能启用时，只能在有限的时间内保持启用状态。
GDS证书操作的运行阶段可以以非常安全的方式执行，因为所有服务器和客户端都已经有证书来确保安全连接。对于证书管理的推送模型，GDS使用目标服务器中可用的最高安全级别建立安全通道。它不通过具有比安全级别更新的安全级别更低的端点来提供更新的CRL，证书或信任列表。例如，如果要更新4096证书，则无法使用2048通道更新证书，但可以使用4096通道更新2048证书。如果需要部署新的更高级别的证书，则以与提供新服务器相同的方式进行处理。
OPC UA应用程序通常具有应用程序实例证书以提供应用程序级别的安全性。它们用于使用非对称密码学建立安全连接。这些应用实例证书是X.509证书的数字证书，并包含第4部分中定义并在第6部分中完整描述的数据项目列表。这些数据项描述了数字证书分配给的应用程序实例。
数字证书包括证书签发者的数字签名。该数字签名可以是自签名的（签名是由与应用实例证书的X.509证书相关联的私钥生成的），或者可以由证书颁发机构签名（签名是由与私有密钥相关联的X生成的.509 CA证书）。这两种类型的证书提供了相同的安全级别，可用于非对称密码术。可以使用各种算法生成签名，其中算法提供不同级别的安全性（128位，256位，512位...）。签署证书所需的算法是安全策略的一部分。服务器和客户端应该能够支持多个证书，因为根据正在支持的安全配置文件，可能需要多个证书。
非对称密码术使用两个密钥 - 私钥和公钥。 应用程序将具有表示其信任的应用程序的可信公用密钥列表。 可信公用密钥列表存储在Windows注册表或文件夹中。 它还将具有与其应用程序实例证书相对应的私钥。 应用程序可以使用其列表中的公钥来验证所接收的连接请求上的签名是否由相应的私钥生成。 应用程序还可以使用目标应用程序的公钥来加密数据，只能使用目标应用程序的私钥进行解密。
CA签名和自我签署的数字证书之间的主要区别是部署和维护数字证书所需的努力。 选择何时使用CA颁发的数字证书与自签名数字证书取决于安装和现场要求。
图7说明了维护自定义数字证书的信任列表所需的工作。
管理员需要将与所有客户端应用程序相关联的公共密钥复制到他们可能需要进行通信的所有服务器应用程序。此外，管理员将需要将与所有服务器应用程序相关联的公共密钥复制到可能需要与其通信的所有客户端应用程序。随着服务器和客户端数量的增长，管理工作可能变得太重了。此外，数字证书有一生，需要在某个时间点更换数字证书。这将需要生成新的私钥和公钥，并重新复制所有公钥。在非常小的安装中，通过在服务器的受信任的证书存储区中安装客户端应用程序实例证书的公共密钥来明确列出服务器信任的客户端可能是可以接受的。
在具有多个服务器和客户机的系统中，信任列表中的公钥安装很快就会变得麻烦。在这些情况下，使用公司特定的CA可以大大简化安装/配置问题。 CA还可以提供额外的好处，如管理数字证书到期和证书撤销列表（CRL）。图8提供了该活动的说明。
管理员将需要为系统中安装的所有客户端和服务器生成CA签名的应用程序实例证书，但他只需要在所有计算机上安装CA公钥。当数字证书过期并被替换时，管理员将只需要更换过期的数字证书（公用密钥和私钥），则不需要将公钥复制到任何位置。
公司特定的CA允许公司控制数字证书的颁发。在大多数情况下，不推荐使用商业CA（如VeriSign）。 OPC UA应用程序通常被配置为仅将本公司确定的其他应用程序信任为可信任。如果商业CA发行的所有数字证书都被信任，那么商业CA将控制哪些应用程序被信任，而不是公司。
所有应用程序开发人员都需要解决证书管理。一些应用程序可能会使用作为系统基础架构一部分提供的证书管理，其他应用程序将生成自签名数字证书作为安装的一部分。有关证书管理的系统基础架构的更多详细信息，请参见第12部分。
在某些系统中，可以部署具有证书管理的GlobalDiscoveryServer。 GlobalDiscoverServer将推送证书到客户端和服务器或允许服务器和客户端提取证书。 GlobalDiscoveryServer证书管理可以管理所有证书部署; 这包括TrustLists，CA和CRL。
从开发人员的角度来看，如果您的应用程序支持证书，则它将自动提供安装时的自签名应用程序实例证书。此外，应用程序可以轻松地使用已发布的CA替换自定义的应用程序实例证书
申请实例证书或由CA签署的自签名证书。信任列表的配置也应该很容易实现。通常，将应用程序实例的公钥的信任列表保存在与CA相同的列表中。应用程序也应该能够处理证书撤销列表（CRL）。这些是与已经被撤销的给定CA相关联的公共密钥列表。这允许CA从流通签名中删除数字证书。 CRL由CA提供，通常以一些自动方式分发;详见第12部分。
从安全的角度来看，用于存储私钥的证书存储必须受保护和保护，只允许适当的管理员和/或应用程序进行读/写访问。信任列表，CRL和受信任的CA列表是受保护的，只允许适当的管理员进行写访问，以及应用程序的拉配置情况。读访问可以授予其他有效的用户，但允许读访问的用户列表将是站点决定。
从安装的角度来看，提供了生成应用程序实例证书的标准工具的最佳做法。该工具可以由OPC UA SDK供应商或OPC基金会提供。标准工具确保生成的应用程序实例证书包括所有必需的字段和设置。特定的OPC UA应用程序应能够接受和安装由外部工具生成的任何有效的应用程序实例证书。实际工具的选择是具体的网站。图9提供了证书处理的一些要点的概述。
以下是部署基于CA的安全需求系统时的这些要点的总结：
应用程序实例(Application Instance) - 安装在单个机器上的OPC UA应用程序称为应用程序实例。 每个实例都有自己的应用程序实例证书，它用于在连接到其他应用程序（公钥和私钥）时识别自身。 每个应用程序实例都有一个全局唯一的URI来标识它。 该应用程序还将检查信任列表和CRL以确定是否应授予访问权限。 应用程序将使用使用非对称加密技术与其他应用程序建立的安全通道进行通信。
管理员(Administrator) - 管理与UA系统相关联的证书处理并管理应用程序实例的安全设置的人员。 这包括设置信任列表的内容和管理CA执行的任何活动。
运营商(Operator) - 运营商是使用应用实例的人员。任何给定的应用程序可能存在多个操作员。运营商可能拥有用户凭据，用于确定访问权限并跟踪应用程序实例中的活动。
用户证书(User Credential) - 用户证书是用于识别操作员/用户的电子ID的通用术语。应用程序实例证书用于创建安全通道后，可能会将其传递给服务器。它可用于确定访问权限并跟踪活动（审核）。
证书颁发机构Certificate Authority（CA） - 证书颁发机构（CA）是负责创建和管理证书的管理员或组织（通常是部分自动化的软件产品）。证书颁发机构验证应用程序实例证书中放置的信息是否正确，并将数字签名添加到用于验证信息未更改的证书。每个CA都有自己的数字证书，用于创建数字签名。 CA还负责维护CRL。在大多数情况下，通常当软件包生成警报或需要某些审核操作的通知时，管理员会定期检查或访问软件包。
证书(Certificate) - 证书是可由应用程序持有的电子ID。 ID包括识别持有者，发行者和用于创建和验证数字签名的唯一密钥的信息。这些证书的语法符合X509规范，因此这些证书也称为“X509证书”。证书还具有与其相关联的私钥。
自签证书(Self-Signed Certificate) - 自签证书是一个没有认证机构的数字证书。这些证书可以由任何人创建，并且可以在UA应用程序的管理员能够通过查看内容本身来验证声明的情况下使用。仅使用自签名证书的系统将不具有CA或CRL。
私钥(Private Key) - 私钥是只有数字证书持有者才知道的秘密号码。该秘密允许持有人创建数字签名和解密数据。如果这个秘密被透露给未经授权的用户，那么相关的数字证书就不再被信任或使用了。它被替换，或者在CA生成的证书的情况下被撤销。
信任列表(Trust List) - 信任列表是由应用程序实例信任的证书列表。当启用安全性时，UA应用程序拒绝来自证书不在受信任列表中的对等体的连接，或者证书是否由不在“信任列表”中的CA颁发。
证书商店(Certificate Store) - 证书商店是证书和私钥可以存储在文件系统上的地方。所有Windows系统都提供一个名为Windows Certificate Store的注册表型商店。所有UA系统还可以支持包含存储在文件中也被称为OpenSSL证书存储的证书的目录。
撤销列表(Revocation List) - 撤销列表是由CA撤销而不被应用程序实例接受的证书列表。