OPC Unified Architecture Specification

 

OPC 统一架构规范

 

 

Part 2  Security Model

(第二部分  安全模型

(Release 1.03)

 

kipway    译

 

 

 

 

 

 

 

 

 

 

 

 

 

email: kipway@outlook.com

 

 

 

 

内容目录

前言

使用协议

版权限制

专利

译者担保和责任免责声明

1.适用范围

2.参考文件

3.术语,定义和缩写

3.1术语和定义

3.1.1应用实例(Application Instance)

3.1.2应用实例证书(Application Instance Certificate)

3.1.3非对称加密学(Asymmetric Cryptography)

3.1.4非对称加密(Asymmetric Encryption)

3.1.5非对称签名(Asymmetric Signature)

3.1.6审计能力(Auditability)

3.1.7审计(Auditing)

3.1.8认证(Authentication)

3.1.9授权(Authorization)

3.1.10可用性(Availability)

3.1.11证书颁发机构(Certificate Authority)

3.1.12证书存储(CertificateStore)

3.1.13保密性(Confidentiality)

3.1.14密码学(Cryptography)

3.1.15网络安全管理系统CSMS

3.1.16数字证书(Digital Certificate)

3.1.17数字签名(Digital Signature)

3.1.18散列函数(Hash Function)

3.1.19散列消息验证码HMAC

3.1.20 完整性(Integrity)

3.1.21密钥交换算法(Key Exchange Algorithm)

3.1.22消息认证码MAC

3.1.23消息签名(Message Signature)

3.1.24不可否认性(Non-Repudiation)

3.1.25随机数(Nonce)

3.1.26OPC UA应用(OPC UA Application)

3.1.27私钥(Private Key)

3.1.28公钥(Public Key)

3.1.29公钥基础设施PKI(Public Key Infrastructure)

3.1.30 RSA算法(Rivest-Shamir-Adleman RSA)

3.1.31安全通道(Secure Channel)

3.1.32对称加密学(Symmetric Cryptography)

3.1.33对称加密(Symmetric Encryption)

3.1.34对称签名(Symmetric Signature)

3.1.35信任列表(TrustList)

3.1.36传输层安全TLS

3.1.37X.509证书

3.2缩写

3.3安全模型数字公约

4.OPC UA安全架构

4.1OPC UA安全环境

4.2安全目标

4.2.1概述

4.2.2认证

4.2.3授权

4.2.4机密性

4.2.5完整性(Integrity)

4.2.6可审计性(Auditability)

4.2.7可用性

4.3 OPC UA系统的安全威胁

4.3.1概述

4.3.2洪泛消息攻击

4.3.3窃听

4.3.4消息欺骗

4.3.5消息更改

4.3.6消息重播

4.3.7格式错误的消息

4.3.8服务器分析

4.3.9会话劫持

4.3.10木马(Rogue)服务器

4.3.11Compromising用户账号

4.4 OPC UA与站点安全性的关系

4.5 OPC UA安全架构

4.6安全策略

4.7安全配置文件

4.8用户授权

4.9用户认证

4.10应用认证

4.11 OPC UA安全相关服务

4.12审计

4.12.1总则

4.12.2单个客户端和服务器

4.12.3聚合服务器

4.12.4通过非审计服务器进行聚合

4.12.5分布式聚合服务器

5.安全威胁对策(Security reconciliation)

5.1OPC UA安全机制对策

5.1.1概述

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.11Compromising用户凭证

5.2目标与OPC UA安全对策

5.2.1概述

5.2.2应用认证

5.2.3用户认证

5.2.4授权

5.2.5保密

5.2.6完整性(Integrity)

5.2.7可审计性

5.2.8可用性

6.实施和部署考虑

6.1概述

6.2适当的超时:

6.3严格的消息处理

6.4随机数生成

6.5特殊和保留的数据包

6.6速率限制和流量控制

6.7管理访问

6.8加密密钥

6.9报警相关指导

6.10程序访问

6.11审计事件管理

7.无担保服务

7.1概述

7.2多播发现

7.3全球发现服务器安全性

7.3.1概述

7.3.2木马GDS

7.3.3对GDS的威胁

7.3.4证书管理威胁

8.证书管理

8.1概述

8.2自签名证书管理

8.3 CA签名证书管理

8.4 GDS证书管理

8.4.1概述

8.4.2开发商证书管理

 

 

前言

此规范是OPC UA应用程序开发人员的规范。该规范是分析和设计过程的结果,用于开发标准接口,以便多个供应商开发无缝集成的应用程序。

Copyright © 2006-2015, OPC Foundation, Inc

 

使用协议

版权限制

任何未经授权使用本规范可能违反版权法,商标法和通讯规定和法规。本文档包含受版权保护的信息。版权所有。图书,电子或机械的任何形式,包括复印,录音,录音或信息存储和检索系统 - 未经版权许可,不得以任何形式或任何方式复制或使用本作品所涵盖的此作品的任何部分。 ---所有者。

禁止OPC基金会成员和非成员复制和重新分发本规范。 所有副本必须单独获得,直接从OPC基金会网站http://www.opcfoundation.org下载。

专利

采用者的注意力在于遵守或采用OPC规范可能需要使用专利权所涵盖的发明的可能性。 OPC不负责识别任何OPC规范可能需要许可的专利,或对引起其注意的专利的法律效力或范围进行法律调查的责任。 OPC规范仅供参考和咨询。 潜在用户负责保护自己免受专利侵权责任。

译者担保和责任免责声明

译者对本文的翻译无法保证准确无误,并可能包含错误。译者对本文不承担任何明示或暗示的担保,包括但不限于任何对所有权的担保,暗示对适销性或适用于特定用途或使用的保证。在任何情况下,译者对于本文所含的错误或直接,间接,偶发,特殊,后果性,依赖性或覆盖面的任何损失,包括任何用户或任何第三方的利润损失,收入,数据或使用,均不承担责任与本材料的使用,性能或使用有关,即使已被告知可能发生此类损害。

本文的英文原版属于OPC Foundation, Inc,翻译后的版本未经译者同意任何个人和组织不得转载。

1.适用范围

本规范描述了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部分中找到。

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

3.术语,定义和缩写

3.1术语和定义

为了本文件的目的,第1部分中给出的术语和定义以及以下适用。

3.1.1应用实例(Application Instance)

单独安装在一台计算机上运行的程序。同一应用程序可以有多个应用程序实例同时在多台计算机上运行,或者可能在同一台计算机上运行。

3.1.2应用实例证书(Application Instance Certificate)

已安装在个人主机中的个人应用程序实例的数字证书。一个软件产品的不同安装将具有不同的应用实例证书。

3.1.3非对称加密学(Asymmetric Cryptography)

使用一对密钥(一个为私钥并保密,另一个为公共密钥)的密码学方法。“非对称密码术”,也称为“公钥密码术”。在实体“A”对发送到实体“B”的数据需要保密性的非对称加密算法中,实体“A”用实体“B”提供的公共密钥加密数据。只有实体“B”具有解密数据所需的匹配私钥。在实体“A”需要消息完整性或为发送到实体“B”的数据提供认证时,在非对称数字签名算法中,实体A使用其私钥对数据进行签名。为了验证签名,实体B使用实体A提供的匹配公钥。在非对称密钥协商算法中,实体A和实体B各自向其他实体发送自己的公钥。然后每个使用自己的私钥和另一个的公钥来计算新的密钥值'根据IS词汇表。

3.1.4非对称加密(Asymmetric Encryption)

非对称密码术用于使用实体的公钥加密数据并用相关联的私钥解密数据的机制。

3.1.5非对称签名(Asymmetric Signature)

非对称密码术用于使用实体的私钥对数据签名并用相关联的公钥验证数据签名的机制。

3.1.6审计能力(Auditability)

确保可以记录系统中的任何动作或活动的安全活动。

3.1.7审计(Auditing)

跟踪系统中的操作和活动,包括可以使用审计记录来审查和验证系统操作的安全相关活动。

3.1.8认证(Authentication)

确保可以验证客户端,服务器或用户等实体的身份的安全目标。

3.1.9授权(Authorization)

授予系统资源访问权限的能力。

3.1.10可用性(Availability)

确保系统正常运行的安全目标。也就是说,没有任何服务受到这种不可用或严重恶化的方式的损害。

3.1.11证书颁发机构(Certificate Authority)

可以发行数字证书的实体,也称为CA。数字证书通过证书的指定主题证明公钥的所有权。这允许其他(依赖方)依赖于通过认证的公钥对应的私钥签名或声明。在这种信任关系模型中,CA是受信任的第三方,由证书的主体(所有者)和依赖证书的一方信任。 CA是许多公钥基础设施(PKI)方案的特征。

3.1.12证书存储(CertificateStore)

存储证书和证书撤销列表(CRL)的持久位置。它可能是一个磁盘驻留文件结构,或者在Windows平台上可能是一个Windows注册表位置。

3.1.13保密性(Confidentiality)

确保保护数据免受非预期方面的阅读的安全目标。

3.1.14密码学(Cryptography)

使用算法和密钥将清晰,有意义的信息转化为加密的,难以理解的形式。

3.1.15网络安全管理系统CSMS

由组织设计的程序,将整个组织的资产的安全性保持在既定的保密性,完整性和可用性水平,无论是在业务方面还是在组织的工业自动化和控制系统方面。

3.1.16数字证书(Digital Certificate)

将身份与诸如用户,产品或应用实例的实体相关联的结构,其中证书具有关联的非对称密钥对,其可以用于认证该实体确实具有私钥。

3.1.17数字签名(Digital Signature)

使用加密算法计算并附加到数据,使得数据的任何接收者可以使用签名来验证数据的来源和完整性。

3.1.18散列函数(Hash Function)

算法如SHA-1,在计算上不可能找到映射到给定哈希结果的数据对象(“单向”属性)或映射到相同散列结果的两个数据对象(“碰撞 - 免费“财产),请参阅IS词汇表。

3.1.19散列消息验证码HMAC

使用迭代哈希函数生成的MAC。

3.1.20 完整性(Integrity)

确保信息没有以未经授权的方式修改或销毁的安全目标,请参见IS词汇表。

3.1.21密钥交换算法(Key Exchange Algorithm)

协议用于在不安全的环境中建立两个实体之间的安全通信路径,由此两个实体应用特定的算法来安全地交换用于保护它们之间的通信的秘密密钥。密钥交换算法的典型示例是SSL / TLS中指定的SSL握手协议。

3.1.22消息认证码MAC

由使用秘密密钥(见对称密码术)的算法产生的短数据片段消息,借此消息的接收者可以通过使用相同的消息和秘密计算产生相同的MAC来检查消息的变化。

3.1.23消息签名(Message Signature)

用于确保在两个实体之间发送的消息完整性的数字签名。有几种方法来生成和验证消息签名,但是它们可以被归类为对称(参见条款3.1.34)和不对称(参见3.1.5)。

3.1.24不可否认性(Non-Repudiation)

强有力的实质性证据表明消息签名人和消息完整性的身份,足以防止一方成功否认原始提交或传递消息及其内容的完整性。

3.1.25随机数(Nonce)

通常通过生成安全密钥的算法使用的随机数。

3.1.26OPC UA应用(OPC UA Application)

调用OPC UA服务的OPC UA客户端或执行这些服务的OPC UA服务器。

3.1.27私钥(Private Key)

用于非对称密码术的一对加密密钥的私密组件。公钥和私钥始终作为一对生成,如果更新另一个,则另一个也必须更新。

3.1.28公钥(Public Key)

用于非对称密码术的一对加密密钥的公开组件,请参见IS词汇表。公钥和私钥始终作为一对生成,如果更新另一个,则另一个也必须更新。

3.1.29公钥基础设施PKI(Public Key Infrastructure)

创建,管理,存储,分发和撤销基于非对称密码术的数字证书所需的一套硬件,软件,人员,策略和程序。核心PKI功能是注册用户并发布其公钥证书,在需要时撤销证书,并归档在较晚时间验证证书所需的数据。密钥对数据机密性可由证书颁发机构(CA)生成;要求私钥所有者生成自己的密钥对是一个好主意,因为它可以提高安全性,因为私钥不会根据IS词汇表传输。有关公钥基础设施的更多详细信息,请参阅PKI和X509 PKI。

3.1.30 RSA算法(Rivest-Shamir-Adleman RSA)

不对称加密算法,由Ron Rivest,Adi Shamir和Leonard Adleman在1977年发明,见IS词汇表。

3.1.31安全通道(Secure Channel)

在OPC UA中,在OPC UA客户端和服务器之间建立的通过使用某些OPC UA服务彼此认证并且已经协商和应用了哪些安全参数的通信路径。

3.1.32对称加密学(Symmetric Cryptography)

涉及使用相同密钥进行算法的两个不同步骤(如加密和解密,签名创建和签名验证)的密码学分支,请参见IS词汇表。

3.1.33对称加密(Symmetric Encryption)

Symmetric Cryptography用于使用两个实体共享的加密密钥加密和解密数据的机制。

3.1.34对称签名(Symmetric Signature)

Symmetric Cryptography用于使用两个实体共享的加密密钥对数据进行签名的机制。然后通过再次生成数据的签名并比较这两个签名来验证签名。如果它们相同,则签名有效,否则密钥或数据与两个实体不同。

3.1.35信任列表(TrustList)

应用程序配置为信任的证书列表。

3.1.36传输层安全TLS

通过基于IP的网络创建安全通道的标准协议。

3.1.37X.509证书

数字证书以X.509 v1,2或3定义的格式之一。X.509证书包含一系列数据项,并按该顺序计算数字签名。

3.2缩写

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可扩展标记语言

3.3安全模型数字公约

本文档中的数字不使用任何特殊约定。在特定图中使用的任何惯例都会在图中说明。

4.OPC UA安全架构

4.1OPC UA安全环境

OPC UA是在多个级别的工业设施的操作中的组件之间使用的协议:从高级企业管理到设备的低级直接过程控制。 OPC UA用于企业管理涉及与客户和供应商的交易。 这可能是工业间谍活动或破坏活动的有吸引力的目标,也可能通过在公共网络上传播的无目标恶意软件(如蠕虫)来暴露威胁。 过程控制中的通信中断可能会导致财务损失,影响员工和公共安全或造成环境破坏。

 

OPC UA将部署在各种各样的操作环境中,对威胁和可访问性以及各种安全策略和执行制度有不同的假设。 因此,OPC UA提供了一套灵活的安全机制。 图1是显示这种环境的组合的复合体。 一些OPC UA客户端和服务器位于同一台主机上,可以方便地防止外部攻击。 一些客户端和服务器位于同一操作网络中的不同主机上,并且可能受到将操作网络与外部连接分离的安全边界保护的保护。 一些OPC UA应用程序在相对开放的环境中运行,用户和应用程序可能难以控制。 其他应用程序嵌入在与外部系统无直接电子连接的控制系统中。

4.2安全目标

4.2.1概述

从根本上说,信息系统的安全性降低了攻击的危害。它通过识别系统的威胁,识别系统对这些威胁的脆弱性,并提供对策来实现。对策直接减少漏洞,抵御威胁,或从成功的攻击中恢复。

工业自动化系统的安全是通过满足一系列目标实现的。这些目标已经通过多年的信息系统安全经验得到改进,尽管系统面临着越来越多的威胁,但它们仍然保持不变。它们在子条款5.1和子条款5.2中进行了描述,将这些目标与OPC UA功能相协调。第6条为客户端和服务器开发人员或部署OPC UA应用程序的用户提供了其他最佳实践指南。

4.2.2认证

客户端,服务器和用户等实体应该证明自己的身份。认证可以根据实体,拥有或知道的内容。

4.2.3授权

读取,写入或执行资源的访问权限应仅限于在系统要求中需要访问的那些实体。授权可以像允许或不允许客户端访问服务器一样粗糙,或者可能会更细微,例如允许特定用户对特定信息项进行特定操作。

4.2.4机密性

保护数据免受被动攻击,例如窃听,数据是否被传输,存储器中或被存储。为了提供机密性,使用特殊密钥数据加密算法来保护数据,并使用身份验证和授权机制访问该密钥。

4.2.5完整性(Integrity)

收件人收到原始发件人发送的相同信息,而传输过程中数据不被更改。

4.2.6可审计性(Auditability)

必须记录系统的操作,以便于向利益相关者提供证据:

4.2.7可用性

当需要运行的软件的执行被关闭或软件通信系统输入处理溢出的时候,可用性受到损害。OPC UA受损的可用性可能会降低订阅性能或无法添加会话。

4.3 OPC UA系统的安全威胁

4.3.1概述

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功能相协调。

4.3.2洪泛消息攻击

攻击者可以发送大量消息或包含大量请求的单个消息,目的是压倒OPC UA服务器或相关组件,如CPU,TCP / IP协议栈,操作系统或文件系统。洪泛攻击可以在多个层进行,包括OPC UA,SOAP,[HTTP]或TCP。

消息洪泛攻击可以使用格式正确和格式错误的消息。在第一种情况下,攻击者可能是使用合法客户端的使用请求来洪泛攻击服务器的恶意人员。存在两种情况,其中一个是客户端没有与服务器的会话,而另一个有会话(Session )。消息洪泛可能会损害建立OPC UA会话的能力或终止现有会话。在第二种情况下,攻击者可能会使用恶意客户端,洪泛化具有格式错误的消息的OPC UA服务器,以耗尽服务器的资源。

一般来说,洪泛消息可能会损害与OPC UA实体进行通信的能力并导致拒绝服务。消息洪泛影响可用性。有关这一威胁的调节见5.1.2。

4.3.3窃听

窃听是未经授权的披露敏感信息可能直接导致严重安全漏洞或用于后续攻击。

如果攻击者已经破坏了底层操作系统或网络基础架构,则攻击者可能能够记录和捕获消息。 可能导致客户端或服务器从受影响的操作系统无法恢复。

窃听影响保密性直接和间接地威胁所有其他安全目标。有关这一威胁的调节见5.1.3。

4.3.4消息欺骗

攻击者可能伪造来自客户端或服务器的消息。欺骗可能发生在协议栈的多个层。

通过来自客户端或服务器的欺骗消息,攻击者可能会执行未经授权的操作,并避免被检测到其操作。

消息欺骗影响完整性和授权。有关这一威胁的调解见5.1.4。

4.3.5消息更改

网络传输层和应用层消息可能被捕获或修改并转发到OPC UA客户端和服务器。 消息更改可能允许非法访问系统。消息更改影响完整性和授权。有关这一威胁的调解见5.1.5。

4.3.6消息重播

网络传输层和有效的应用层消息可以被捕获并在稍后阶段将其重新发送到OPC UA客户端和服务器,而无需修改。攻击者可能会误导用户或发送有效的命令,例如在不正确的时间打开阀门,以致造成损坏或财产损失。消息重播影响授权。有关这一威胁的调解见5.1.6。

4.3.7格式错误的消息

攻击者可以使用无效的消息结构(格式不正确的XML,SOAP,UA二进制等)或数据值生成各种消息,并将其发送到OPC UA客户端或服务器。

通过执行未经授权的操作或处理不必要的信息,OPC UA客户端或服务器可能会错误地处理某些格式错误的消息。 这可能导致服务的拒绝或退化,包括终止应用程序,或者在嵌入式设备的情况下,完全崩溃。 在最坏的情况下,攻击者可以使用格式错误的消息作为多级攻击的前提,以访问OPC UA应用程序的底层系统。

格式错误的消息会影响完整性和可用性。有关这一威胁的调解见5.1.7。

4.3.8服务器分析

攻击者尝试推断服务器或客户端的身份,类型,软件版本或供应商,以便应用有关该产品的特定漏洞的知识来安装更具侵入性或破坏性的攻击。 攻击者可以通过向目标发送有效或无效的格式化消息来配置目标,并通过其正常和错误响应的模式尝试识别目标的类型。

服务器分析会间接影响所有的安全目标。有关此威胁的和解,请参阅5.1.8。

4.3.9会话劫持

攻击者可以使用关于在两个应用程序之间建立的正在运行的会话的信息(通过嗅探通信或通过猜测)来注入操纵的消息(具有有效的会话信息),允许他或她从授权用户接管会话。

攻击者可能未经授权访问数据或执行未经授权的操作。会话劫持影响所有的安全目标。有关这一威胁的调解见5.1.9。

4.3.10木马(Rogue)服务器

攻击者构建恶意的OPC UA服务器或安装未经授权的真实OPC UA服务器实例。

OPC客户端可能会披露必要的信息。木马服务器影响除完整性(Integrity)之外的所有安全目标。有关这一威胁的调解见5.1.10。

4.3.11Compromising用户账号

攻击者通过观察纸张,屏幕或电子通信,或通过猜测或使用自动化工具(如密码破解者)来获得用户名,密码,证书或密钥等用户账号。

未经授权的用户可以启动和访问系统以获取所有信息,并进行控制和数据更改,从而损害工厂操作或信息。 一旦使用了compromised的账号,后续活动可能都是合法的。

compromised用户账号影响授权和保密。有关这一威胁的和解,请参见5.1.11。

4.4 OPC UA与站点安全性的关系

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无法解决。

4.5 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连接)的丢失下生存并且用新的连接恢复,通信层负责重新建立传输层连接而不中断逻辑安全信道。

4.6安全策略

安全策略(SecurityPolicies)指定要使用哪些安全机制,并从安全配置文件导出(有关详细信息,请参阅4.7)。服务器使用安全策略来通知其支持哪些机制,并由客户端选择要与其希望打开的安全通道一起使用的安全策略。 SecurityPolicies包括以下信息:

SecurityPolicy的选择通常由管理员在安装客户端和服务器产品时进行。可用的安全策略在第7部分中指定。管理员以后可以根据情况要求更改或修改SecurityPolicies的选择。

安全策略的公告由第4部分中规定的特殊发现服务处理。有关发现机制和策略公告的更多详细信息,请参见第12部分。

如果服务器服务多个客户端,那么它为每个客户端维护单独的策略选择。这允许新客户端选择独立于其他客户端为其安全渠道选择的策略选项的策略。

由于计算能力每年都在增加,今天被认为是安全的特定算法可能会变得不安全,因此,在OPC UA应用程序中支持不同的安全策略是有意义的,并且能够在可用时采用更多的安全策略。 NIST或其他机构甚至可以预测算法的预期使用寿命(参见NIST 800-57)。支持的安全策略列表将根据NIST发布的建议进行更新。 从部署的角度来看,定期站点审查检查当前选择的安全配置文件列表是否仍然满足所需的安全性目标很重要,如果没有,则选择新的安全配置文件。

还有一种新的安全策略是为了支持提高OPC UA产品安全级别的新算法而组建的。 OPC UA客户端和服务器的应用程序体系结构应该设计成可以对应用程序进行更新或添加附加的加密算法,而不需要更改编码。

第7部分指定了由特定唯一URI标识的几个策略。 为了提高供应商产品之间的互操作性,服务器产品实施这些策略,而不是自己定义。 客户支持相同的策略。

4.7安全配置文件

OPC UA客户端和服务器产品经过第7部分定义的Profiles 认证。某些Profiles指定安全功能,而其他配置文件指定与安全性无关的其他功能。Profiles对认证产品施加要求,但不对产品的使用方式施加要求。各种配置文件需要一致的最低安全级别。但是,不同的配置文件指定了不同的细节,例如哪个OPC UA功能需要哪些加密算法。如果在一个加密算法中出现问题,那么OPC基金会可以定义一个类似的新Profile,但是它指定了一个不具有已知问题的不同加密算法。第7部分是规范性规范。

由于配置文件,策略涉及许多相同的安全选择;但是该策略规定了在会话中使用哪些选择。该策略没有指定产品提供的选择范围,它们在其支持的“配置文件”中进行了描述。

这些策略包含在与OPC UA客户端和服务器相关联的认证测试中。认证测试确保遵循标准,并支持适当的安全算法。

OPC UA中的每个安全机制根据客户端或服务器遵循的配置文件在客户端和服务器产品中提供。然而,在现场,可以可选地部署安全机制。以这种方式,每个单独的站点都具有可用的所有OPC UA安全功能,并且可以选择其中哪些用于满足其安全目标。

4.8用户授权

OPC UA提供了一种交换用户凭据的机制,但不指定应用程序如何使用这些凭据。 客户端和服务器应用程序可以以自己的方式确定哪些数据可访问以及哪些操作被授权。 存在配置文件以指示用户凭据的支持来限制或控制对数据的访问。

4.9用户认证

当客户端通过会话服务(第4部分描述)指定的方式将用户凭据传递给服务器时,实现用户身份验证。 服务器可以使用这些凭据来验证用户。可以使用ActivateSession服务更改会话的所有者(用户),以满足应用程序的需要。

4.10应用认证

OPC UA使用传达应用程序认证的概念来允许打算进行通信的应用程序进行识别。 每个OPC UA应用实例都具有在安全通道建立期间进行交换的数字证书(应用程序实例证书)。 证书的接收方检查信托证书,并根据此检查,它接受或拒绝来自发件人的请求或响应消息。 该信任检查使用TrustLists的概念完成。 TrustLists是由管理员指定的CertificateStore。 管理员在将证书放入TrustList之前,确定证书是否已签署,验证和可信。 TrustLists通常还包括证书撤销列表(CRL)。OPC UA利用其他组织定义的这些行业标准概念。在OPC UA中可以使用HTTPS创建安全通道,但是这些通道不提供应用验证。 如果需要验证,则基于用户凭据。

有关应用程序认证的更多详细信息,请参见第4部分。

4.11 OPC UA安全相关服务

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服务器的秘密信息一起用于派生一组用于保护所有其他消息的加密密钥。此外,所有其他服务消息都使用对称加密和对称签名来保护,而不是不对等体。

服务器将服务响应中的秘密信息发送给客户端,以便客户端可以导出相同的密码密钥集。

由于客户端和服务器具有相同的加密密钥集,它们可以彼此安全地通信。

这些导出的加密密钥被周期性地改变,使得攻击者没有无限的时间和不受限制的消息序列用于确定密钥是什么。

4.12审计

4.12.1总则

客户端和服务器生成成功和不成功的连接尝试的审计记录,安全选项协商的结果,配置更改,系统更改,用户交互和会话拒绝。

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服务器和客户端的行为。

4.12.2单个客户端和服务器

图3说明了客户端与服务器通信的简单情况。

 

在这种情况下,OPC客户端“A”执行一些可审核的操作,包括在服务器“D”中调用OPC UA服务。 它写入自己的审核日志条目,并将该条目的标识符包含在提交给服务器的服务请求中。

服务器接收请求并为其创建自己的审核日志条目。 此条目由其自己的审核ID标识,并包含其自己的审核信息。 它还包括发出服务请求的客户端的名称和请求中接收的客户端审核条目标识。使用此信息,审核员可以检查服务器的日志条目的收集,并将其与相关的客户端条目相关联。

4.12.3聚合服务器

图4说明了客户端从聚合服务器访问服务的情况。 聚合服务器是通过访问被称为低层服务器的其他OPC UA服务器的服务来提供服务的服务器。

在这种情况下,每个服务器都会接收请求并为其创建自己的审核日志条目。 每个条目都由其自己的审计ID标识,并包含自己的审计信息。 它还包括发出服务请求的客户端的名称和请求中接收的客户端审核条目标识。 然后,服务器将其创建的条目的审核ID传递给链中的下一个服务器。

使用此信息,审核员可以检查服务器的日志条目,并将其与相关的客户端条目相关联。

在大多数情况下,服务器将仅生成审核事件,但这些审核事件仍将包含与审核日志记录相同的信息。 在汇总服务器的情况下,还需要服务器从其汇总的服务器订阅审核事件。 以这种方式,服务器“B”将能够向客户端“A”提供所有审核事件,包括服务器“C”和服务器“D”生成的事件。

 

4.12.4通过非审计服务器进行聚合

图5说明了客户端从不支持审核的聚合服务器访问服务的情况。

在这种情况下,每个服务器都会接收请求并为他们创建自己的审核日志条目,但服务器“B”不支持审核。 在这种情况下,服务器“B”将从客户端“A”接收到的审核ID传递到下一个服务器。 这将创建所需的审计链。

服务器“B”未列为支持审计。 在服务器不支持写入审核条目的情况下,整个系统可能被视为不支持审核。

在不支持审计的聚合服务器的情况下,仍然需要服务器从其汇总的服务器订阅审核事件。 以这种方式,服务器“B”将能够向客户端“A”提供所有审计事件,包括由服务器“C”和服务器“D”生成的事件,即使它没有生成审核事件。