工业4.0中的安全数据桥接：一种基于OPC UA聚合技术的方案，用于整合不安全的传统系统

《IEEE Access》：Secure Data Bridging in Industry 4.0: An OPC UA Aggregation Approach for Including Insecure Legacy Systems

　　摘要：工业网络连接性的增强导致了网络攻击的激增，这凸显了需要根据工业系统的特定需求制定网络安全措施的重要性。现代工业4.0技术，如OPC UA，提供了更强的抵御这些威胁的能力。然而，由于安装时间较长、技术专有性、灵活性受限以及正式流程要求（例如安全认证）的存在，这些技术的广泛应用仍然受到限制。因此，许多系统尚未实施这些技术，或者仅部分实施。这就带来了处理所谓“棕地系统”（brownfield systems）的挑战，这些系统通常被置于隔离的安全区域内以降低风险。然而，安全区域与不安全区域之间的数据交换需求依然存在。本文通过分析现有解决方案的方法、优势和局限性来回顾这些挑战。基于这些见解，我们确定了三个关键概念，评估了它们的适用性和兼容性，并最终介绍了SigmaServer这一新型的TCP级聚合方法。在操作技术（OT）测试平台上对开发的原理验证实现进行了评估，证明了其在连接安全区域和不安全区域方面的可行性和有效性。CCBY - IEEE并非该材料的版权所有者。请通过https://creativecommons.org/licenses/by/4.0/遵循指示以获取全文文章和API文档中的规定。

第一部分 引言
A. 动机
通过应用工业4.0的设计原则，现代工业工厂正在发展成为高度互联的操作技术（OT）系统，这些系统通常也连接到全球互联网。虽然这带来了更高的效率和更大的灵活性等好处，但互联性也增加了整体攻击面，从而增加了网络安全风险[1]、[2]。
为了解决这些风险，像IEC 62443[3]这样的倡议重点关注OT的网络安全，提出使用区域和通道来加强工业网络的安全性。因此，网络被划分为具有不同安全要求的多个区域，遵循纵深防御的概念。区域通过通道连接，这些通道通常是防火墙或单向网关（数据二极管），以限制未经授权的流量。
然而，一个剩余的挑战是OT设备的长期运行寿命。虽然像桌面和服务器系统这样的IT组件通常使用3-5年，但生产机器代表了更大的投资，通常使用10-15年甚至更长时间[4]。这些机器中嵌入的硬件和软件难以保持更新，因此在它们的使用寿命的某个阶段不再支持最新的安全标准（如安全的OPC UA通信）。它们变成了遗留设备，仅提供有限或没有安全措施。因此，它们对整个工业网络构成了风险，显著削弱了整体安全性。此外，某些协议在行业中仍然流行，但并未提供任何或足够的安全措施。例如，工业协议Modbus缺乏内置的安全功能，这导致了2024年的FrostyGoop事件[5]，攻击者利用了未经认证的Modbus命令。
在本文中，我们使用“遗留设备”一词来指那些无法满足现代工业网络安全要求的设备——也包括像Modbus这样的不安全协议。
为了降低遗留设备的风险，可以将它们放置在完全隔离的区域中。隔离可以防止攻击，但同时也剥夺了连接性的好处，如精确同步和过程优化。因此，在一定程度上，遗留设备仍然必须能够与其隔离区域之外的系统进行通信，例如与监控控制和数据采集（SCADA）系统通信。
这可以通过中间件解决方案来实现，这些解决方案可以桥接包含遗留设备的隔离区域和支持现代安全功能的区域。这样的解决方案不仅必须能够在不同协议之间进行转换，还必须能够在隔离区域之外以最新的安全功能表示遗留设备。特别是后一个要求目前尚未被现有解决方案很好地解决，因为主要关注的是协议之间的工作、快速和可靠的转换。因此，在接下来的工作中，我们的重点是如何将遗留的棕地系统安全地集成到现代安全工业网络中。
B. 贡献
我们通过聚合在现代生产环境中保护工业遗留系统的贡献有三个方面：我们提供了已发布的中间件聚合解决方案的结构化回顾，并从安全能力的角度对其进行了分析。
由于没有已发布的解决方案专注于安全性，我们定义了一个共同的威胁模型，并引入了三个通用架构概念，以便将不安全的遗留系统嵌入到符合Purdue模型[6]的现代安全工业网络中。
我们实现了这些概念中最实用的一个，称为SigmaServer，并评估了其性能特性，如延迟和系统负载，证明了可以通过可接受的技术努力和低系统开销来实现改造。
所提出的方法引入了一种新颖的安全意识设计和TCP级命名空间分离的组合，这在之前的工作中尚未被解决。现有的OPC UA聚合服务器将多个设备的地址空间合并到一个共享的命名空间中，我们将其称为命名空间污染。此外，没有一个评估的聚合解决方案将安全性作为主要设计考虑因素。SigmaServer通过在TCP层为每个遗留设备实例化一个专用的OPC UA服务器来解决这个问题。每个服务器监听一个独特的端口，从而完全保留了原始的命名空间结构并消除了污染。安全侧的通信通过OPC UA安全策略强制执行，确保在安全端点上进行身份验证和加密通信。SigmaServer还引入了在同一部署中同时管理运行不同协议的异构遗留设备的能力，将每个设备安全地作为单独的OPC UA端点暴露出来。
评估显示，我们提出的SigmaServer实现了端到端延迟低于2.6毫秒，而其内部处理延迟保持在低微秒范围内，平均为21.15微秒。与Open Platform Communications (OPC) Foundation Console Aggregation Server1（105-115 MiB）相比，SigmaServer所需的RAM使用量显著减少（6-19 MiB）。尽管CPU使用量略高，但仍保持在个位数范围内，为0.75-3.16%。为了可重复性和进一步研究，我们的实现也在GitHub上公开提供。

第二部分 工业网络和区域的背景信息
A. 工业网络
工业网络构成了现代自动化环境的技术支柱。它们使传感器、执行器、控制器和监控系统之间的交互成为可能。
这些网络的核心是可编程逻辑控制器（PLCs），它们位于现场级别，并在严格的时限约束下执行确定性控制任务。这种实时操作确保了从生产线到能源网格的各种工业过程能够确定性和可靠地运行[7]。
与传统的信息技术（IT）基础设施不同，PLC通常依赖于超出TCP/IP的专用工业通信技术。它们还经常使用现场总线或基于工业以太网的技术（例如POWERLINK、PROFINET、EtherCAT），这些技术更好地满足了过程控制所需的实时性和可靠性要求。
其中一种协议是Modbus，它在工业领域是开放和广泛采用的[8]。这种广泛采用可以归因于其固有的简单性，允许设备之间的互操作性。最初，Modbus是通过Modbus RTU和Modbus ASCII进行串行通信开发的。此后，Modbus协议通过IEC 61158[9]演进为包括基于以太网的通信，从而适应了广泛的工业应用和用例。考虑到工业控制系统的典型延长使用寿命，直到2018年才引入了包含基于TLS的安全功能的Modbus/TCP，因此其采用仍然有限。此外，Modbus/TCP Security仅由Modbus组织定义——它不是IEC 61158的一部分。
在设备控制（PLCs、执行器和传感器）之上，SCADA系统提供了可视化、数据记录和对分布在多个站点的过程的高级管理。SCADA系统与PLC、远程终端单元（RTUs）和人机界面（HMIs）集成，为操作员提供了系统性能和状态的全面视图。这些组件共同创建了一个分层架构，其中本地的时间关键控制功能与集中监控和决策并行运行[7]。
B. 工业4.0和OPC UA
工业4.0这一术语，即第四次工业革命，其特征是物理工业系统与传统IT系统的融合。目标是创建能够自我优化和自主决策的生产系统[10]。
为此，必须满足灵活性、适应性、透明度和跨异构系统的互操作性[11]。Schleipen等人[11]提到，这样的合规系统必须能够通过开放的、标准化的IT网络进行通信，能够自我描述并保护自己的信息，还能够自我配置和优化。通过所谓的RAMI 4.0模型[12]，开发了一个工业4.0系统的参考架构，该模型指定了所需的语义技术。
此外，德国联邦政府的一份战略文件[13]将Open Platform Communications Unified Architecture (OPC UA)确定为工业4.0的基础技术。ZVEI[14]在讨论工业4.0标准的报告中也加强了这一点。OPC UA支持访问控制等安全功能，并通过其信息模型和与数据库模型的解耦提供了平台独立性，使其成为工业通信的合适解决方案[11]。
作为OPC标准的继任者，OPC UA已成为广泛采用的工业通信标准。它在IEC 62541中得到标准化，并由OPC基金会维护。这种平台独立、设计安全和服务导向的架构使得工业系统能够进行通信[15]，无论是采用客户端-服务器方式还是发布-订阅模式。
OPC UA不仅定义了一种通信协议，还引入了信息模型来结构化变量、方法和事件[16]。信息模型由节点（对象、变量、方法、事件等）及其之间的引用组成，这些都在OPC UA服务器的地址空间内组织。配置在终端点的OPC UA服务器允许读取或写入信息模型的变量，并调用其方法。每个OPC UA节点可以使用其统一资源标识符（URI）和唯一标识符进行寻址[15]。
关于安全性，规范定义了一组安全特性，有助于构建设计安全的架构。这些特性包括安全会话管理、传输安全、用户认证和访问控制。
OPC UA聚合服务器连接多个OPC UA服务器，并提供一个单一的、集中化的聚合地址空间。Gro?mann等人[17]提出了这样一个服务器的参考架构，其中包含提供聚合地址空间、获取底层数据、发现和访问控制安全管理的组件。
图1展示了OPC UA聚合服务器的各种部署场景，显示了聚合服务器在工业网络中的不同位置。它展示了一个受Purdue模型[6]和IEC 62443[3]建议启发的工业网络架构。该网络被划分为三个区域，这些区域通过防火墙连接：(i) 车间级别代表现场级别（见第二部分A），包含PLCs；(ii) 操作级别包含通过SCADA系统和HMI进行的过程监控和高级控制，用于用户交互；(iii) 最高级别，企业区域，包含财务和企业管理系统等企业系统。图1中突出显示了三种可能的部署场景，聚合服务器可以位于车间级别或更高级别之一，具体取决于具体用例。它们的定位取决于具体的使用场景，即聚合服务器应该服务哪些客户端。例如，如果需要服务来自企业区或互联网的外部客户端，则聚合服务器应该部署在操作层面。图1展示了提供单一聚合地址空间的OPC UA聚合服务器的部署场景[17]、[18]。在三种场景中部署聚合服务器的主要优势在于，它们作为外部网络的集中式平台，提供了对从内部OPC UA节点收集的信息的访问。当考虑到许多客户端访问多个（通常是相同的）服务器的情况时，这一优势尤为明显：管理具有不同权限的多个连接和用户需要执行各自的安全规则，这会消耗大量资源[17]。通过使用聚合服务器，每个客户端的连接数和用户数也减少到只有一个，从而简化了安全管理。对于资源受限的设备（如PLC），这尤其有益，因为这些设备可能只能处理有限数量的并发连接。

C. 工业系统的参考架构
本节介绍了一个参考架构，用于分析和演示一种强化安全性的聚合服务，该服务可将传统设备连接到OT网络。图2所示的工业参考架构基于Josef Ressel Centre (JRC)的智能和安全工业自动化(ISIA)测试平台，这是一个用于工业研究的测试平台，在该平台上所有OT设备都使用OPC UA协议。该测试平台按照最新技术标准进行构建，遵循IEC 62443 [3]和Purdue参考架构[6]。它由四个安全区域组成，每个区域通过防火墙通过单一通道相互连接：企业区、工业DMZ区、车间区和传统设备区。图2显示了JRC ISIA测试平台的网络设置，将系统划分为四个区域：企业区、工业非军事区(DMZ)、传统设备区和车间区。该设置进一步用于评估所提出的SigmaServer。

该测试平台反映的过程是使用注塑机生产塑料零件。三个注塑机分别由车间区的PLC1-3和操作区的SCADA HMI控制。所有OT设备都通过OPC UA协议进行通信。三台工业计算机(KUKA1–3)各自控制一个机械臂，将成品零件从注塑机移放到传送带上；第四个机械臂(KUKA4)将零件放置在生产线末端的托盘上。尽管注塑机和机械臂是模拟的，但控制逻辑与实际部署完全相同。企业区包含一个资源规划工具和一个智能助手（属于智能自动化研究的另一部分），而传统设备区是本研究的重点，它通过防火墙连接，并托管所提出的SigmaServer服务器、一台PLC（PLC4）以及一个模拟不安全Modbus温度控制器的Raspberry Pi（PLC5）。

总体而言，该测试平台使用最先进的协议（OPC UA）来模拟现代工业制造过程，以推进网络安全和人工智能驱动的自动化及异常检测的研究。

第三节 方法论
用于研究传统系统安全集成方法的方法论基于两个研究问题：存在哪些安全和架构解决方案可以将传统系统集成到基于OPC UA的工业自动化网络中？哪些集成方法能够在遵循Purdue模型的工业网络中实现传统系统的最佳安全性和操作可行性平衡？以及如何实现这种方法？
为了解决RQ.1，进行了结构化的文献回顾，旨在确定已发布的中间件聚合解决方案的最新技术水平。回顾旨在提供当前研究中关于聚合或改造执行器、传感器和PLC的方法的全面概述。为此使用了以下搜索词：opc ua、security、aggregation、aggregating、server、brownfield、retrofit。搜索通过Google Scholar进行，以尽量减少对任何单一出版物的偏见[19]。随后，根据与安全和架构相关的特征对识别出的出版物进行分类，具体细节见第四节。

在确定了最新技术水平后，RQ.2重点关注将传统系统集成到现代工业网络中的基础架构概念。基于一个推导出的威胁模型，对三种将不安全传统系统集成到安全且符合Purdue标准的网络中的架构概念进行了安全性和操作可行性的定性评估（见表1）。

表1 评估OPC UA聚合概念的标准。这些标准涵盖了从安全属性到操作可行性等多个方面，以评估这些概念在工业网络中的适用性。

在确定了最合适的概念后，需要在工业测试平台上实现一个原理验证。然后使用延迟和系统负载等指标来评估该原理验证，以了解安全性和操作开销之间的权衡。

第四节 最新技术水平
OPC UA聚合服务器和改造传统系统这两个主题已经在之前的研究中进行了深入讨论，并在以下部分（第四节A和第四节B）中进行了介绍。第四节C的文献总结显示，当结合这两个领域时，没有找到评估聚合服务器作为改造解决方案的研究出版物。

本综述的范围仅限于经过同行评审的研究出版物，因为主要目标是评估科学知识的状态并识别开放的研究空白。商业产品不在本综述的范围内，因为它们的内部安全架构和设计通常不会以允许科学评估和可重复比较的形式公开。表2总结了截至2026年1月通过文献回顾发现的最新技术水平。评估的特征表明某个解决方案是否专注于该主题（?）、考虑了该主题（○）或未涉及该主题（?）。此外，对于那些提到了安全性但没有重点讨论或考虑安全性的工作，使用符号?。例如，当安全性仅被提及为未来工作时，使用符号?。

为了明确现有工作的安全视角，分析分为两个小节。第四节A探讨了现有OPC UA聚合服务器解决方案中的安全处理方式。第四节B回顾了所有已识别的改造传统系统方法中的安全方面，其中不安全的协议和过时的系统带来了不同的挑战。

A. OPC UA聚合服务器中的安全性
我们确定了16篇关于OPC UA聚合服务的比较出版物，这些出版物列在表2中。Gro?mann等人[17]提出了OPC UA聚合服务器的基本概念，并为其提供了一个参考架构。他们开发了两个信息模型扩展（用于聚合服务器和聚合数据），并实现了一个原型。除了访问控制的安全管理器外，没有进一步讨论其他安全方面。Banerjee和Gro?mann[22]使用了与[17]相同的原型，并将其作为聚合层来统一来自不同信息模型的底层异构数据。这篇出版物没有讨论安全性问题。Crespí等人[16]使用聚合服务器作为云服务和车间层（边缘设备）之间的桥梁，并提供了一个统一的信息模型。他们详细介绍了聚合地址空间的构建方式，并提到了未来工作中安全机制的实现。

在Weskamp和Tikekar[30] 2021年的研究论文中，介绍了一个符合Industry 4.0标准的OPC UA聚合服务器。他们使用与[17]相同的架构作为基础，并将底层信息模型映射到Industry 4.0资产管理壳(I4AAS)配套规范的元模型。这篇出版物没有讨论安全性问题。OPC UA规范1.0版本用于符合I4AAS的要求，定义在OPC 30270[41]中，并于同年（2021年）发布。Pe?a等人[27]提出了一种基于Raspberry Pi实现的Modbus到OPC UA的网关解决方案。该网关使得基于Modbus的传统设备能够与现代OPC UA客户端通信，但与我们的工作不同，因为它侧重于协议转换而不是安全地桥接隔离的网络区域。

其他研究，如[21]、[23]、[24]、[28]或[31]也使用了聚合服务器，但没有进一步讨论安全性问题。OPC基金会的GitHub项目[42]提供了符合标准的开源OPC UA应用程序代码。特别是，它包括了一个OPC UA聚合服务器的实现，我们将其作为实验比较的基准（见第八节）。作为商业解决方案的例子，Unified Automation[43]提供了UaGateway，它实现了使用传统OPC协议和OPC UA协议的设备之间的安全通信。

这两种解决方案，即OPC基金会的样本聚合服务器解决方案和商业UaGateway，与我们在C.3中提出的聚合服务器解决方案不同（见第五节D），因为我们还考虑了其他非OPC和非OPC UA的协议。此外，所提出的SigmaServer为每个设备提供了单独的安全OPC UA服务器实例。

B. 改造解决方案中的安全性
在回顾中确定了七篇关于使用OPC UA改造传统系统的相关出版物。Rupprecht等人[36]评估了多种将传统PLC集成到现代符合Industry 4.0标准环境中的改造概念，并将其数据提供给更高级的系统。其中一种方法在现场层放置了一个额外的硬件网关，该网关通过其专有协议连接到PLC，并通过OPC UA连接到内网。这篇出版物没有讨论安全性问题。Etz等人[34]实现了类似的解决方案：一个OPC UA网关，它将传统设备的Telnet连接桥接到OPC UA域。实现使用了制造商提供的信息模型和python-opcua库。这篇出版物没有讨论安全性问题。Majumder等人[37]使用PLC4X作为中间件，将具有不同专有协议的传统系统集成到使用现代标准化协议（如OPC UA、消息队列遥测传输(MQTT)、超文本传输协议安全(HTTPS)等）的Industry 4.0环境中。然而，他们得出结论，该工具无法处理底层设备的数据语义和数据异构性，因此不适合作为独立工具使用。Tran等人[38]回顾了之前关于改造传统系统的工作，其中提到了典型的挑战，包括安全性问题。他们指出了传统机器的问题、有限的安全功能和安全威胁及其可能的解决方案，并指出很少有研究包含安全性方面。考虑到传统系统的使用仍然非常普遍，他们指出安全性对于未来越来越重要。

与其他解决方案不同，Lackorzynski等人[35]使用修改后的MACsec协议来保护第2层的通信。这样做的优点是可以保护基于以太网的工业协议在ISO/OSI第2层的安全性。然而，使用基于以太网的安全机制并不能解决工业网络中继续使用传统协议的问题。此外，它还需要非标准化的MACsec以太网帧使用方式。Busboom[32]回顾了自动生成OPC UA信息模型的工作。该出版物包括关于聚合多个OPC UA信息模型、命名空间索引、合并类型等方面的信息。

[39]中，作者使用三层架构将各种传统设备集成到Industry 4.0中。本出版物重点关注安全方面，但与本研究中提出的解决方案有所不同。Pe?a等人[27]展示了一个用于能源回收系统的OPC UA/Modbus网关，但未解决其他专有协议的安全集成问题。Holmes等人[40]提出了一个基于分层的RAMI 4.0架构的通用数字改造框架，使用OPC UA作为跨异构传统机器的模块化和分布式通信的标准。Knobloch等人[33]提出了一种基于哈希的类型聚合方法和一种使用引用注入的实例聚合方法。尽管他们在机器人装配站验证了这种映射数据库设计，但他们的重点仍然在于安全网络内的垂直集成。

**C. 总结**
在回顾的23篇出版物中，只有三篇专门讨论了安全问题，一篇在某种程度上考虑了安全问题，六篇指出未来需要进一步的安全措施。从特征代码（见表2）可以看出，没有一篇出版物将其实现开源，从而限制了可重复性。此外，我们可以总结我们的发现如下：
- OPC UA聚合服务器为将多个底层OPC UA服务器集成到一个统一的聚合地址空间提供了有效的解决方案。
- 使用OPC UA网关改造旧系统是一种常见的方法，用于弥合传统系统与现代工业4.0兼容基础设施之间的差距。
- 在改造旧系统时，安全性通常是一个次要问题，受到的关注有限。
- 没有哪项提出的工作发布了原理验证，这阻碍了研究社区有效评估这些解决方案或在此基础上进行开发的能力。

**D. 在安全意识方法中的定位**
在回顾的23篇出版物中，大多数根本没有讨论安全问题，只有四篇工作关注或考虑了安全问题，即[17]、[35]、[38]和[39]。这些是唯一允许与SigmaServer的安全特性进行更详细比较的出版物。表3总结了相关工作的比较结果。

**表3 相关工作在OPC UA聚合和旧系统集成中的安全性对比（针对SigmaServer）**
Tran等人[38]对旧系统改造中的安全挑战进行了全面回顾。由于这项工作是综述而非聚合或旧系统解决方案的实现，因此在表3中没有进一步详细讨论。
Gro?mann等人[17]引入了OPC UA聚合服务器的概念，并提出了一个专门的安全管理器用于访问控制。然而，他们的架构将所有设备命名空间合并到一个聚合地址空间中，导致命名空间污染问题。在安全方面，没有定义明确的威胁模型，安全性仅限于聚合服务器本身的访问管理。此外，他们的概念不支持任何传统或不安全的现场总线协议，如Modbus/TCP。
Lackorzynski等人[35]提出了对MACsec协议的修改，以在传统工业以太网环境中实现数据链路层认证和加密。虽然他们的工作直接涉及安全问题，但它仅在ISO/OSI第2层操作，没有涉及传输层或应用层协议的安全性、命名空间完整性或威胁建模。因此，它针对的是网络堆栈的不同层次，作为SigmaServer实现的OPC UA桥接方法的补充安全措施。
Sujith等人[39]提出了一种三层架构，使用OPC UA封装器和适配器将传统协议桥接到中央OPC UA服务器，并在安全侧应用加密和认证。在这三项工作中，这是与SigmaServer在架构上最相似的，也是唯一提供传输安全性和多协议支持的。然而，它使用一个中央化的OPC UA服务器将所有设备数据聚合到一个共享地址空间中，从而继承了命名空间污染的问题。这项工作也没有定义威胁模型来支持其安全设计。
相比之下，SigmaServer解决了所有这些标准：它结合了严格的安全机制、每个设备的安全OPC UA端点、命名空间完整性、多协议支持以及基于STRIDE的三级威胁模型。这些特性表明，在回顾的文献中，没有先前的工作以类似全面的方式解决了不安全传统系统的安全桥接问题。

**第五节 集成传统系统的概念**
一般来说，聚合服务器旨在提供一个集中节点，用于管理来自外部客户的访问[44]。传统设备的集成通常不在聚合服务器的常规范围内，通常通过连接到车间的网关来实现，例如[34]。为了分析工业网络中基于OPC UA的聚合的不同概念，我们首先讨论所考虑的威胁模型（第五节A）。之后，我们在第五节B至D中讨论了识别的聚合概念（C.1-3）。表4总结了第五节B至D中介绍的每个概念的定性评估结果。

**表4 架构概念（C.1 - C.3）的决策矩阵**
**C.3**通过同时解决命名空间完整性问题并需要较低的集成工作量而表现最佳。

**A. 威胁模型**
随着OT领域事件数量的增加[45]、[46]，攻击变得越来越复杂。因此，我们假设存在一个技术娴熟的对手。在第一阶段，攻击者试图通过互联网远程渗透网络。接下来，攻击者在工业DMZ中获得立足点，最后，攻击者破坏了一个传统系统。图3展示了一个受Purdue模型启发的工业自动化网络以及攻击者的位置，用（1）–（3）标出。工业DMZ和传统区域之间的黑框是第五节B至D中介绍的三个聚合概念的占位符。

**图3. 威胁模型，展示了在启用基本安全控制的情况下三种不同的攻击者级别**
- **攻击者级别1**：攻击者位于组织外部，可以执行拒绝服务（DoS）或权限提升攻击。例如，攻击者可能利用应用程序中的漏洞进一步进入系统（攻击级别2）。
- **攻击者级别2**：攻击者获得了位于工业DMZ中的系统的访问权限，可以对该传统区域执行DoS和权限提升攻击。这种情况可以分为两种情况：（i）攻击者通过社会工程手段（例如伪装成工程师或服务人员）获得对网络的物理访问权限并破坏设备，或（ii）攻击者利用防火墙漏洞获得网络访问权限。在这两种情况下，攻击者不仅可以执行DoS和权限提升攻击，还可以对传统区域进行欺骗、篡改、否认服务和信息泄露攻击。
- **攻击者级别3**：通过社会工程或其他手段（如Stuxnet [47]所示的USB闪存驱动器感染），攻击者能够访问传统区域，因此可以执行与所有六种STRIDE威胁相关的攻击。

**B. 通往传统区域的通道（C.1）**
在将传统区域集成到工业网络的背景下，一种常见的方法是使用通道（如防火墙或单向网关（数据二极管）来管理和保护对传统设备的访问。通过使用防火墙或数据单向网关作为通道，可以监控、过滤并根据预定义的安全策略限制传统区域与其他网络段之间的所有数据交换。这种配置最小化了未经授权的访问或恶意软件从传统设备传播到更广泛网络的风险。防火墙可以执行规则，例如只允许特定协议、限制与关键系统的通信，或实施入侵检测和预防机制。从性能角度来看，这种概念相对高效，因为通道仅根据其规则转发或阻止流量，而不需要额外的处理。
然而，这些方法有一些显著的缺点。“安全”区域的客户端可能仍需要使用与传统设备兼容的过时和不安全的协议进行通信，这使它们面临潜在风险。特别是，一旦攻击者在工业DMZ中获得立足点，他们可以利用允许的不安全协议进行欺骗、篡改和信息泄露攻击。因此，需要深度包检测（DPI）通过彻底分析数据流量中的恶意内容来增强安全性，这需要更多资源。由于数据二极管只允许单向通信，它们还限制了依赖双向交互的应用程序的功能，如远程控制、配置更改或确认。此外，信息泄露攻击仍未得到解决，因为数据二极管不提供任何加密保护。

**C. 应用层聚合服务器（C.2）**
将传统区域连接到工业网络的第二个概念涉及应用层的聚合，通常使用网关/代理或专门的解决方案（如OPC UA聚合服务器）来实现。这些聚合服务器专门设计用于外部实体需要读取和写入工业自动化网络中的OPC UA节点的场景。这种方法不仅简化了管理和监控，还通过以标准化格式呈现数据来提高互操作性，减少了与不安全传统协议的直接交互需求。因此，只有安全区域（例如工业DMZ）内暴露了安全协议，从而提高了整个网络的安全性。尽管有这些好处，但这种方案的有效性取决于聚合逻辑的能力和设备特定数据映射的完整性。此外，聚合服务器既不是为了处理网络内的传统系统访问而设计的，也不是作为安全解决方案设计的。
这种方法的挑战是命名空间污染，因为命名空间不再仅属于单个设备。相反，它变成了一个共享空间，可能导致冲突、歧义或难以管理和区分来自不同设备的数据。Graube等人[23]进一步详细说明了一些缺点。一个值得注意的问题是，工业自动化软件通常设计有静态、固定的命名空间，这依赖于恒定的节点ID进行访问。这些节点ID的持久性也可能构成挑战，因为对合并信息模型的更改可能会影响聚合服务器在运行时表示的节点顺序。实际上，这也增加了集成工作量，因为PLC项目必须适应修改后的聚合命名空间才能通过聚合服务器访问底层设备。
另一个需要考虑的挑战是应用层聚合服务器可能会引入时间问题。特别是在PLC需要实时相互通信的情况下，可能会影响工业系统的整体性能和响应能力，而这通常依赖于精确和同步的操作。

**D. TCP层聚合服务器（C.3）**
通过在传输层（例如TCP）而不是应用层分配每个传统区域内的设备命名空间，可以维护每个设备的单独命名空间，这与OPC UA聚合服务器（C.2）的做法不同。这种解决方案需要在聚合服务器上运行多个OPC UA服务器，允许通过各自的TCP端口区分设备。C.3类似于一个协议网关，它在专用TCP端口上暴露单个设备端点（例如[48]），关键区别在于C.3支持超出单一协议家族（如Modbus）的异构传统协议，通过在每个安全OPC UA端点后加入特定于协议的客户端逻辑。
仍然需要考虑时间限制，因为这种解决方案没有消除C.2中提到的所有缺点。然而，它有效地解决了命名空间污染和工业自动化软件对静态、固定命名空间的依赖问题。
多个OPC UA服务器的动态部署带来了挑战。其中一个挑战是需要使用静态映射将TCP端口映射到传统区域中的设备。这些静态映射是必要的，以避免在传统区域发生更改时重新配置PLC。一旦端口配置完成，PLC就不需要进一步调整。因此，集成工作量低于C.1和C.2。
另一个挑战是每个传统设备使用单独的TCP端口。具体来说，集成新的PLC（尤其是大量PLC）可能比使用C.2时更耗时，并且可能需要对防火墙进行更多调整，因为在C.2中只使用了一个TCP端口。同时，为每个传统设备托管专用的OPC UA服务器实例可以提高对来自安全区域的攻击的抵御能力，因为这些OPC UA服务器实例是隔离的，每个实例都运行自己的OPC UA堆栈。对于我们用例中提出的任何其他概念，TCP级别的聚合服务器必须反映需要通过传统协议进行通信的传统设备的当前状态。由于访问代表传统设备的OPC UA服务器的时间延迟较高，因此监控这些设备的运行状态至关重要。

E. 额外的安全措施
无论讨论了哪些概念，OPC UA在生产环境中使用时都必须遵循最先进的安全措施。此外，作为不安全网络的传统区域必须得到额外的保护。在传统区域内可能需要使用网络过滤器和深度数据包检查，特别是在考虑威胁模型中的攻击者级别3时（见第V-A节）。保护易受攻击的传统区域的额外措施包括部署蜜罐。例如，面对安全区域的网络过滤器可以将可疑流量重定向到沙箱化的蜜罐[49]。部署蜜罐的优势在于它可以立即检测、记录并从攻击者的行为中学习。

第六节 SigmaServer
SigmaServer的架构基于TCP级别的聚合服务器设计（C.3），其特性在表4中进行了总结。C.3在第V-D节中有详细说明。它减轻了命名空间污染，并最小化了对依赖固定命名空间的现有工业软件的修改[23]。

A. 架构
SigmaServer展示了一个原理验证实现，并使用open625413（v.1.4.8）库实现。其模块化设计基于三个主要组件：多个不安全客户端（InsecClients）、一个中央线程安全的数据存储和多个安全服务器（SecServers）。整体架构如图4所示。
图4. 提出的SigmaServer架构，展示了不安全客户端接口和多个安全OPC UA端点的分离。

每个InsecClient负责一个传统设备，例如PLC或依赖不安全或过时通信协议的其他系统。InsecClients在单独的线程中运行，并与分配的传统端点建立连接。它们检索结构信息和实时数据值，这些数据值存储在中央线程安全的数据存储中。当前版本的SigmaServer支持OPC UA和Modbus/TCP协议。然而，通过向公开可用的开源代码库中添加更多的InsecClient变体，该架构允许集成其他不安全的通信协议，如CAN或PROFINET。
共享存储作为系统的中央数据缓冲区，维护两个同步的线程安全映射：一个用于静态节点结构，另一个用于当前数据值。这种设计实现了不安全区域和安全区域之间的严格分离。所有结构和数据都被镜像到config//namespace.json下的JSON文件中，以便独立检查运行中的系统。

SecServers为每个传统设备托管一个安全的OPC UA服务器实例。每个SecServer运行在专用的TCP端口上（例如4841），并提供一个唯一的OPC UA端点来代表不安全网络中的单个设备。这种方法保证了完全的命名空间分离，从而消除了命名空间污染的问题，并确保了传统设备与其安全OPC UA表示之间的一对一映射。因此，安全区域中的主机只需重新配置用于通信的TCP端口即可访问传统设备。安全区域中的客户端与SigmaServer之间的通信使用OPC UA SecurityPolicy Basic256Sha256进行加密和认证，支持基于证书和用户名/密码的认证。由于实现基于open62541，可以通过修改源代码来应用库支持的任何其他安全配置文件。

系统启动时，SigmaServer加载两个配置文件：客户端配置定义了所有不安全端点、节点ID和要查询的Modbus寄存器。服务器配置指定了要启动的安全服务器及其相应的别名和TCP端口。初始化后，每个InsecClient从其源设备检索节点结构并将值填充到共享存储中。然后SecServers将这些结构注册到它们的本地OPC UA地址空间中，并开始向SCADA等主机系统提供实时值。
图5显示了作为安全区域和不安全网络区域之间桥梁的TCP级别聚合服务器的位置。

B. 运行原理
当SigmaServer启动时，主进程加载配置文件并为设置中定义的每个客户端和服务器创建一个单独的线程。每个InsecClient线程连接到其分配的设备。对于OPC UA设备，客户端首先读取NamespaceArray（标准节点i=2255）以将每个命名空间索引映射到其URI。这些信息存储在内存中，稍后由安全服务器用来重建原始的命名空间表。客户端随后读取配置的节点属性，如DisplayName、Description、DataType和BrowseName。这些属性使用open62541读取服务进行查询，并与节点的数字标识符（NamespaceIndex、NodeId）一起保存。通过递归遍历父子关系构建完整的浏览路径，直到根文件夹。每个路径都以设备别名（例如Objects/PLC21/...）为前缀，以便每个设备在全球结构中都有自己的子树。
这种结构存储在一个线程安全的映射中，并也写入config//namespace.json下的JSON文件中。这些文件包含给定命名空间的所有节点标识符的最小列表，并允许动态调整当前需要的节点。读取节点结构完成后，客户端进入循环读取模式。它连续读取所有配置节点的值，或者在Modbus设备的情况下，读取定义的寄存器值。值被规范化为基本的OPC UA类型：Boolean、Int16/32/64、Float、Double、String或DateTime。对于时间戳，根据来源不同，当前系统时间存储为OPC UA DateTime值或Unix时间。Modbus寄存器根据配置进行转换，例如将原始整数乘以0.1来表示温度值。结果数据原子地写入全局值映射，替换之前的条目。每个条目都由形式为::的确定性键标识。
共享存储作为不安全客户端和安全服务器之间唯一的通信接口。它实现为一个受内部互斥锁保护的线程安全键值映射。这确保了即使在多个线程同时写入时也能保持一致的访问。客户端只写入新值，而安全服务器只读取它们。这两个域之间没有直接的网络通信，从而确保了不安全区域和安全区域之间的完全隔离。当前实现仅关注从不安全设备到安全客户的读取操作。

在安全端，每个SecServer线程在结构数据可用时启动。在其初始化期间，它读取为其分配的别名存储的所有命名空间，并将它们添加到自己的OPC UA服务器配置中。每个变量节点都使用从原始设备读取的相同数字NodeId(ns, id)创建。文件夹层次结构从存储的浏览路径重新创建。为每个变量注册一个读取回调。当安全的OPC UA客户端请求一个值时，回调从共享数据映射中检索相应的JSON对象，根据保存的DataTypeId将存储的值转换为正确的数据类型，并以UA_Variant的形式返回。这种转换支持所有常见的标量类型，并确保数据完全按照从原始设备读取的方式呈现。服务器的命名空间表从存储的URI重建，且不镜像OPC Foundation标准命名空间（http://opcfoundation.org/UA/），以避免冲突。
每个客户端和服务器都在自己的线程中运行，并设计有可停止的控制机制，以实现正确的关闭。在连接丢失或设备故障的情况下，受影响的客户端会不断尝试与其分配的端点重新建立通信。重新连接机制在常规轮询循环中处理，不需要手动操作。
除了传统的客户端-服务器模式外，该实现还支持发布-订阅模式。在这种配置中，安全的OPC UA服务器充当发布者，定期向安全区域内的一个或多个订阅者传输聚合数据。可以通过服务器配置文件server_configuration.json直接在这两种模式之间切换操作模式。
实现的SigmaServer完全独立于平台，这是通过使用Docker进行容器化实现的。这种方法允许在整个架构上部署在Windows和Linux主机上，而无需任何代码修改。

C. 配置
SigmaServer可以通过两个JSON文件进行配置。客户端配置文件（client_configuration.json）定义了所有不安全的传统端点，服务器配置文件（server_configuration.json）指定了安全的OPC UA服务器实例。
客户端配置为每个传统设备声明一个条目，其结构取决于底层协议。对于OPC UA设备，每个条目指定设备别名和形式为opc.tcp://:的主要端点URL。可以提供一个可选的备用端点，在连接丢失时使用。pollIntervalSec值定义了循环读取间隔，而由namespaceIndex和NodeId标识的节点列表指定了要轮询的OPC UA节点。对于Modbus/TCP设备，条目提供了Modbus服务器的IP地址和端口以及轮询间隔。寄存器列表定义了要读取的寄存器，每个寄存器指定其地址、描述性名称和数据类型。
服务器配置为每个安全的OPC UA端点声明一个条目。每个条目指定SecServer将监听的端口号、引用相应客户端条目的plcAlias以及操作模式。模式可以设置为客户端-服务器（CS）或发布-订阅（PubSub）。客户端条目与其服务器条目之间的一对一映射实现了第V-D节中描述的TCP级别分离。每个传统设备都在自己的专用端口上暴露，从不与其他设备共享命名空间。
通过这种配置，安全的OPC UA客户端可以连接到特定的端口（例如4841），专门访问不安全的OPC UA PLC，而另一个端口（例如4842）仅映射到Modbus冷却系统。除了更新目标TCP端口外，不需要对安全的OPC UA主机进行进一步重新配置，这展示了SigmaServer如何以最小的操作开销集成到现有的工业基础设施中。项目仓库的CONFIG.md文件提供了所有配置参数的完整参考，包括Docker部署、延迟测试工具和示例配置等高级选项。

第四节 实验设置
A. 测试环境
为了评估SigmaServer的操作行为和性能，使用了JRC ISIA测试平台中实现的传统区域（见第II-C节）。该设置反映了一个真实的可复制的工业环境，允许在受控条件下评估数据流、延迟和潜在的攻击向量。实验的重点是安全网络区域与传统区域之间的连接，这两个区域通过SigmaServer相连。物理设置如图6所示。
图6. 部署的测试平台设置分为四个区域，不安全的传统区域通过提出的SigmaServer集成到DMZ中。
SigmaServer部署在运行Windows 10 IoT Enterprise的Sigmatek IPC 511上。该IPC配备了Intel Celeron G1820 CPU、8 GB RAM和两个以太网接口。这些接口分别配置为连接到安全网络和传统网络。选择这种硬件是为了反映典型的工业生产环境。
在传统区域中使用了两种类型的传统设备。一种是B&R X20CP1686X PLC，用作IMM。对于这个实验，该PLC配置了一个不安全的OPC UA接口并可以访问多个节点。PLC 由 InsecClient 进行轮询，首先获取命名空间数组和节点属性，然后定期读取配置的值。另一个传统设备是作为 Modbus/TCP 服务器的 Raspberry Pi 4，代表一个冷却系统。Modbus 服务器使用 pymodbus 库实现，提供两个保持寄存器：来自 DS18B20 传感器的温度（以摄氏度为单位）和风扇转速（以每分钟转数为单位）。SigmaServer 的 Modbus InsecClient 以可配置的间隔轮询这些寄存器，并将标准化值写入中央线程安全数据存储中。

在安全方面，两个 SecServer 实例镜像收集的数据，并通过安全的 OPC UA 端点（TCP 端口 4841 和 4842）进行展示。在这个实验中，主机系统 UaExpert 使用基于证书的身份验证的安全策略 Basic256Sha256 连接到这些端点。

网络拓扑使用一个非管理型交换机在传统区域中实现，将 OPC UA 非安全端点和 Modbus 服务器连接到 SigmaServer。Barracuda F183R 防火墙用于在区域之间强制执行严格的 TCP 路由。因此，只允许所需的端口（即 TCP 端口 4841-4842）。

在第 VII-C 节中描述的评估中，使用了一个外部测试客户端，运行在 HP Z2 Tower G9 工作站（Intel Core i7-12700，32GB RAM）上。客户端运行在具有通用内核（6.14.0-generic）的 Linux 系统上。

需要注意的是，SigmaServer Windows 10 IoT PC 和测试客户端都没有使用硬实时操作系统内核。这种设置是为了代表典型的工业监控场景，其中服务器和客户端在典型的 IT 基础设施上运行。

**B. 攻击场景**

根据第 V-A 节中介绍的威胁模型，以下攻击场景展示了 SigmaServer 当前的安全态势。所实现的架构有效地缓解了与攻击者级别 1 和级别 2 对手相关的攻击。外部攻击者或工业 DMZ 内部的受损系统无法执行欺骗、篡改、抵赖或信息泄露攻击。尽管 SigmaServer 通过严格的网络分割以及经过身份验证和加密的通信提供了强大的隔离，但它无法完全防止 DoS 或权限提升尝试。其多端口设计本质上将处理负载分布在独立的安全服务器实例之间，将针对特定端点的 DoS 攻击的潜在影响限制在单个端点，而不是整个系统。针对此类攻击的全面防御仍然需要额外的保护措施。

级别 3 的攻击者如果能够访问传统区域本身，仍然是一个现实且关键的威胁。在考虑的攻击场景中，对手通过冒充维护技术人员进行社会工程学渗透到生产网络中。通过将像 Raspberry Pi Zero 这样的计算设备连接到连接关键生产系统的交换机的未使用以太网端口来获取网络访问权限。传统区域包括一个运行在 PLC 上的不安全 OPC UA 服务器（代表 IMM），以及第 VII-A 节中描述的 Modbus/TCP 冷却系统。随后，攻击集中在 Modbus 协议上。利用这一位置，攻击者执行欺骗攻击，更具体地说，是对聚合服务器和 Modbus 服务器之间不安全通信通道的针对性 ARP 毒害攻击。这种攻击使对手能够操纵从 Modbus 服务器传输到聚合服务器的数据。通过使用 Ettercap 和自定义 Etterfilter 规则，在传输过程中不断修改 Modbus 响应的 TCP 效载荷，导致聚合服务器向用户提供虚假数据。例如，攻击者可以向操作员展示来自冷却系统的稳定且无风险的温度读数，而实际上由于热管理不足，设备正在过热。结果，工作人员对严重情况毫不知情，可能导致严重损坏。在现实的生产环境中，这可能导致设备故障、生产停机，从而造成重大财务损失。

除了展示的 ARP 欺骗攻击外，分析还指出不安全现场总线协议的攻击面是多样的。重放攻击、对 Modbus 端口的拒绝服务尝试或部署恶意 Modbus 服务器代表了进一步的现实威胁场景。在工业环境中，这不仅构成安全风险，还直接影响安全性，因为被操纵的过程值可能导致设备损坏、生产线中断，并危及人类生命。

SigmaServer 的原理验证本身无法缓解这些弱点，必须通过入侵检测系统（IDS）等额外机制来补充。虽然此类对策的设计和评估超出了本文的范围，但它们代表了未来研究的一个有前景的方向。

**C. 评估指标**

为了评估 SigmaServer 的运行效率，进行了三项实验，重点关注（i）在现实操作条件下不安全接口和安全接口之间的端到端延迟，（ii）SigmaServer 内部软件在 InsecClient 和 SecServer 之间的延迟，以及（iii）与 OPC Foundation Console 聚合服务器相比的平均 CPU 和 RAM 使用情况。

**端到端 SigmaServer 延迟**。第一个实验使用图 7 中显示的测试设置来评估 SigmaServer 的端到端延迟。该测量包括 SigmaServer 的内部处理时间和参与系统之间的网络延迟。如算法 1 所示，外部延迟测试客户端在每次被 SigmaServer 的 InsecClient 轮询时生成一个随机值。在该值返回后立即，SecTestClient 从 SigmaServer 的安全 OPC UA 端点读取相应的值。延迟定义为在 InsecTestServer 生成值和从 SecServer 成功检索到相同值之间的时间差。这反映了来自不安全传统 PLC 的数据通过 SigmaServer 流向安全 OPC UA 客户端的现实场景。

**算法 1 端到端延迟测量**

参与者：InsecTestServer、SecTestClient、InsecClient、SecServer

注意：InsecTestServer 和 SecTestClient 驻留在同一个外部测试设备上

InsecTestServer 生成随机值
returnedValue ← InsecTestServer.getGeneratedValue()
ts ← current_time()
receivedValue ← SecTestClient.readFromSecServer()
latency ← current_time() ? ts
if returnedValue = receivedValue then
match ← true
else
match ← false
end
if
save(latency, match, returnedValue, receivedValue)

为了验证值是否匹配，测试将来自安全接口的接收值与来自不安全接口的返回值进行比较。如果两个值匹配，则结果标记为 true，否则标记为 false。这种真/假验证确保只有匹配的值被考虑在评估中，同时也显示测试客户端是否足够快以进行适当的验证。

端到端延迟的时间测量使用 Python 的 time.monotonic() 进行，该函数利用底层的 Linux CLOCK_MONOTONIC 确保高分辨率的单调时间戳。

**SigmaServer 内部软件延迟**。第二个实验关注 SigmaServer 的内部软件延迟。为此，实现提供了围绕共享数据存储的内置软件延迟测量。记录了两个时间戳：Δt1 测量新值到达 InsecClient 与完成写入线程安全数据存储之间的时间。Δt2 测量 SecServer 收到来自安全 OPC UA 客户端的读取请求与从数据存储中获取请求值并在 SecServer 上可用进行传输之间的时间。因此，Tproc 被定义为总体内部软件延迟，Δt1+Δt2。

这些测量捕获了 SigmaServer 在不安全侧和安全侧之间的内部处理行为，同时明确排除了任何轮询间隔以及任何网络延迟。内部软件延迟 Tproc 使用 C++ std::chrono::high_resolution_clock 进行测量，配置为以微秒分辨率记录时间戳。安全 OPC UA 通信所需的加密操作不包括在内部软件延迟测量中。

**服务器资源使用**。第三个实验评估 SigmaServer 的运行效率，并将其与 OPC Foundation Console 聚合服务器进行比较。为了分析不同工作负载下的可扩展性和资源行为，进行了四种测试场景，范围从单个活动的 OPC UA 服务器到多个并发的 OPC UA 服务器。具体来说，测量包括配置有一个、两个和三个同时运行的 OPC UA 服务器，以及第四种组合三个 OPC UA 服务器和一个 Modbus 客户端的设置，以评估 SigmaServer 的混合协议性能。由于第四种设置需要处理 Modbus，因此只能在 SigmaServer 上运行。

所有实验都在 JRC ISIA 测试平台上进行（见第 II-C 节），使用第 VII-A 节中描述的配置。

**第八节. 结果和讨论**

根据第 VII-C 节中定义的方法论对 SigmaServer 的性能进行了评估。所有数据都在相同条件下记录。

**A. SigmaServer 端到端延迟**

该实验共记录了 14,287 个样本，每个样本都显示在不安全接口生成的值和安全 OPC UA 端点读取的值之间有真正的匹配。测量的延迟值范围从最小 2.6 毫秒到最大 24.7 毫秒，标准差为 3.0 毫秒。由于没有发生不匹配，结果表明 SigmaServer 处理和转发值的速度始终快于外部延迟测试客户端可以解析的速度。尽管由于测试客户端的测量限制，无法确定 SigmaServer 的确切最小延迟，但结果显示包括网络传输在内的完整数据路径小于 2.6 毫秒。图 8 显示了该实验的延迟分布。

**B. SigmaServer 内部软件延迟**

共收集了 1,788 个样本以确定 SigmaServer 的内部软件延迟。测量的延迟范围从最小 14.80 微秒到最大 42.90 微秒，标准差为 3.11 微秒。总体内部软件延迟 Tproc 测量为 21.15 微秒。图 9 总结了延迟分布，并显示了相应的 95% 置信区间。由于此测量排除了轮询间隔、网络延迟和加密操作，因此它隔离了线程安全数据存储和 InsecClient 与 SecServer 之间的纯计算开销。

**C. 服务器资源使用**

使用 docker stats 监控工具记录了一小时内的 CPU 和 RAM 使用情况，采样间隔为一秒。InsecClient 的轮询间隔配置为 100 毫秒。SigmaServer 的平均 CPU 负载几乎与同时运行的服务器实例数量成线性增加，从单个 OPC UA 服务器的 0.75% 增加到三个 OPC UA 服务器和一个 Modbus 客户端活动时的 3.16%。RAM 使用情况表现出类似的可预测行为，从最低的 6.12 MiB 增加到最高的 18.79 MiB。

图 10 显示了所有场景的平均 CPU 使用情况，而图 11 将 SigmaServer 的 RAM 使用情况与 OPC Foundation Console 聚合服务器进行了比较。两种实现都配置了相同的 OPC UA 地址空间，以确保公平比较。如前所述，混合协议场景（OPC UA 和 Modbus）仅适用于 SigmaServer，因此图 10 仅包括我们解决方案的结果。

**D. 讨论**

评估表明，SigmaServer 在所有检查的场景中只需要最少的计算资源，同时保持稳定和可预测的行为。总体内部软件延迟在低微秒范围内，确认了线程安全数据存储和模块化客户端-服务器设计的高效运行，没有出现显著延迟。时间复杂度由共享数据存储上的操作决定：Δt1 和 Δt2 都包括在 std::unordered_map 上的单次键查找和更新，设计上提供了 O(1) 的访问时间。由于映射在初始化期间已完全填充，之后没有结构变化，因此在运行时完全避免了重新哈希。因此，每次操作的复杂度实际上严格为 O(1)。

资源使用结果突出了与 OPC Foundation Console 聚合服务器相比的明显架构差异。SigmaServer 使用多个独立的 OPC UA 服务器实例，并具有 TCP 级别的分离，而 OPC Foundation Console 聚合服务器提供了一个单一的、集中聚合的地址空间。因此，SigmaServer的CPU使用率略有上升，但仍保持在较低且可预测的个位数范围内，并且随着聚合设备数量的增加而线性扩展。同时，SigmaServer所需的RAM显著减少，CPU和RAM使用率的波动也明显降低。这种观察到的线性扩展与系统的O(n?m)时间复杂度一致，其中n是同时活跃的InsecClient-SecServer对的数量，m是每个设备的节点数。每对InsecClient都在自己的专用线程中运行，每个InsecClient对其分配的m个节点执行独立的轮询循环。在评估的配置中，m在所有场景中保持不变，O(n?m)简化为观察到的线性扩展O(n)。总体而言，结果证实SigmaServer提供了一种可靠且资源高效的机制，用于将不安全的现场设备与安全的OPC UA基础设施连接起来，同时将软件开销降至最低，并确保消除了命名空间污染。结合可预测的性能特性，这些结果证实SigmaServer满足了棕场集成（brownfield integration）的实际需求，提供了低开销的安全OPC UA端点。尽管进行的延迟测量显示SigmaServer仅引入了最小的额外延迟，但我们还需要考虑典型的部署场景。在这些场景中，最终的延迟仍然可能相当大，但这主要取决于客户端使用的轮询或发布-订阅（publish-subscribe）机制的时机。为了更详细地说明这种行为，我们讨论了当SigmaServer客户端和安全客户端都使用轮询来检索数据更新时可能出现的转发延迟。图12展示了这种场景的时序图。对于此分析，我们假设两个参与者都有相同的轮询间隔T。每个参与者的处理时间被忽略，因为它至少比轮询间隔T小一个数量级。同样，不安全服务器上的任何内部数据采样也被忽略，因为无论SigmaServer是否存在，这些采样都会发生。通过SigmaServer传递的新数据的预期额外转发延迟取决于两次轮询活动之间的时间差ts。如图12所示，这个延迟位于区间td∈[tt,tt+T)内，其中下限代表最佳情况，上限（不包括）对应于最坏情况。图12. 时序图展示了SigmaServer引入的实际转发延迟td。假设一个共同的轮询间隔T，每次轮询操作需要2tt。轮询活动之间有ts的时间差，导致转发延迟td∈[tt,tt+T)。

在考虑整体数据年龄时，如果客户端直接以间隔T轮询不安全服务器，这将导致最大数据年龄为tt+T，即传输时间和轮询间隔的总和。引入SigmaServer后，如果轮询率相同，则最佳数据年龄为2?tt+T，最坏数据年龄为2?(tt+T)。

第九节 安全考虑
SigmaServer的设计将安全性作为主要关注点，这与我们文献回顾中识别的大多数现有聚合和改造解决方案形成对比（见第四节），在这些解决方案中，安全性要么缺失，要么仅被提及为未来的工作。SigmaServer的核心安全特性源于不安全旧有区域（insecure legacy zone）与安全工业网络（secure industrial network）之间的严格分离。两个区域之间不存在直接的网络路径：不安全的客户端（InsecClients）写入线程安全的数据存储（thread-safe data store），而安全服务器（SecServers）仅从中读取数据，从而在软件层面确保了完全的网络隔离。所有暴露给安全区域的通信都使用OPC UA SecurityPolicy Basic256Sha256进行加密和认证，支持基于证书和用户名/密码的认证方式。这意味着在工业DMZ或车间操作的客户端永远不会接触到不安全的旧有协议，如Modbus/TCP，这些协议不提供任何认证或完整性保护。

关于威胁模型（第五节A），该架构有效缓解了与攻击者级别1和2相关的攻击。具体来说，已经在工业DMZ中获得立足点的外部攻击者无法对旧有区域进行欺骗、篡改、否认或信息泄露攻击。多端口TCP级设计（TCP-level aggregation）进一步限制了DoS攻击对单个端点的影响，因为每个旧有设备都由一个独立的SecServer实例表示，从而限制了潜在中断的影响。TCP级聚合概念（C.3）引入的一对一设备映射带来了额外的安全优势。通过为每个旧有设备分配一个专用的TCP端口和命名空间，该架构避免了应用程序级聚合服务器（C.2）中固有的命名空间污染问题，后者可能会在访问控制中引入歧义并使每设备的安全策略执行变得复杂。

A. 剩余漏洞
尽管有上述保证，SigmaServer仍无法完全保护旧有区域免受攻击者级别3的对手的攻击，这些对手已经直接访问了不安全网络。如第七节B所示，连接到旧有区域的对手可以对聚合服务器和旧有设备之间的不安全Modbus/TCP通道进行有针对性的ARP欺骗攻击。利用现成的库，攻击者可以持续操纵Modbus响应的TCP有效载荷，导致SigmaServer转发伪造的过程值，例如，即使设备过热也显示为稳定的温度读数。这一限制是不安全协议固有安全性的直接后果。例如，Modbus/TCP不提供认证、完整性保护或重放防止机制。由于所提出的解决方案转发从不安全网络接收的数据，它无法区分不安全端的合法值和被操纵的值（所有其他概念也是如此）。除了展示的ARP欺骗之外，不安全协议的攻击面很广：重放攻击、针对协议端口的DoS尝试以及部署恶意Modbus服务器都是在旧有区域内现实的威胁向量[50]。

当前实现的SigmaServer仅专注于从旧有设备读取操作。任何支持写入访问和方法调用的未来扩展都需要仔细的安全分析，因为从安全区域向不安全旧有设备转发写入请求会引入额外的攻击向量，例如恶意命令传播到安全关键的过程控制系统的风险。然而，OPC UA已经提供了细粒度的访问控制，借助SigmaServer甚至可以完全隐藏不需要的节点，否则这些节点可能会构成安全风险。另一个限制涉及中央数据存储，它是当前实现中的单点故障。虽然其线程安全设计确保了在并发负载下的一致访问，但崩溃或损坏将导致所有SecServers无法提供最新值，从而实际上中断整个桥接功能。可能的缓解措施，如故障时的自动过程重启或冗余备用实例，尚未实现，但代表了未来工作的可能扩展。

B. 补充安全机制
全面保护旧有区域需要超出SigmaServer本身范围的补充安全措施。特别是，以下措施被认为是必要的扩展：
入侵检测系统（IDSs）：监控不安全网络中的异常网络流量模式，例如，意外的寄存器写入（Modbus）、异常的轮询频率或ARP表不一致性，可以及时检测到级别3的攻击。
蜜罐部署：面向安全区域的网络过滤器可以将可疑流量重定向到沙箱化的蜜罐[49]。这允许立即记录和分析攻击行为，而不会暴露关键的旧有设备。
深度包检测（DPI）：在不安全区域和安全区域边界具有DPI能力的网络过滤器[51]可以用来分析旧有协议流量中的恶意内容，补充SigmaServer执行的区域隔离。此外，可以阻止命令（即写入访问和方法调用）以防止对旧有设备的操纵。

第十节 结论
在这项工作中，我们解决了将不安全的旧有设备安全集成到基于OPC UA的工业自动化网络中的挑战。尽管在之前的工作中已经广泛讨论了OPC UA聚合服务器和棕场改造解决方案，但很少考虑安全方面。为了填补这一空白，我们从安全角度分析了现有的聚合和改造方法。此外，我们为典型的工业网络设置开发了一个威胁模型，以识别潜在的攻击向量。基于这些分析，我们推导并评估了三种用于连接安全和不安全网络区域的架构概念，并根据威胁缓解、命名空间完整性、实时影响、集成工作量和区域兼容性标准进行了评估。我们确定TCP级聚合是最适合安全集成旧有系统的概念。它防止了命名空间污染，并在旧有设备及其安全表示之间建立了明确的一对一映射，最小化了所需的集成工作量。基于这一概念，我们引入了SigmaServer作为概念验证实现。其架构通过使用中央线程安全数据存储和多个监听不同端口的安全服务器，强制实现了不安全客户端接口和安全OPC UA端点之间的严格分离。

实验在工业测试床上证明，SigmaServer引入的开销可以忽略不计。端到端延迟保持在2.6毫秒以下，平均内部处理延迟为21.15微秒。资源利用率与专注于OPC UA的OPC Foundation Console Aggregation Server的性能进行了比较。相比之下，SigmaServer不仅支持OPC UA，还支持连接不安全旧有协议（如Modbus）的桥接。比较还显示，SigmaServer消耗的RAM少于OPC Foundation Console Aggregation Server，同时保持了可预测的CPU使用率。这些发现证实，可以在不牺牲性能的情况下，以最小的技术复杂性实现安全旧有系统的集成，而不会导致命名空间污染。安全分析表明，SigmaServer有效缓解了攻击者级别1和2的欺骗、篡改、否认和信息泄露攻击。由于旧有协议的不安全性，SigmaServer本身无法完全应对来自旧有区域的攻击（级别3），因此需要额外的对策，如IDSs、DPIs或蜜罐。

总体而言，SigmaServer提供了一种实用且以安全为中心的解决方案，用于将不安全的旧有设备桥接到现代安全工业网络中。通过启用安全的OPC UA通信和高效的运行时性能，它证明了TCP级聚合的有效实现。

A. 未来工作
虽然所展示的SigmaServer已经为安全数据桥接提供了坚实的基础，但未来工作还计划了几项扩展。保护旧有区域本身仍然是一个未解决的挑战。如第七节B所示，聚合服务器无法防止来自不安全网络的攻击。因此，未来的工作将专注于额外的安全机制，如IDS和蜜罐的集成。这些措施旨在检测和分析恶意活动，并将可疑流量引导远离关键的旧有设备（沙箱化）。此外，当前的实现仅关注对旧有设备的读取访问。SigmaServer的扩展可以包括支持写入访问和方法调用。这包括从安全客户端到旧有系统的OPC UA写入请求和安全方法的转发。最后，未来的工作将进一步关注图12中讨论的行为，该图突出了不安全接口之间异步轮询引入的转发延迟。虽然SigmaServer的内部处理延迟可以忽略不计，但有效延迟很大程度上取决于轮询活动之间的交互。然而，当在安全端使用发布-订阅模式并将发布活动与不安全端的轮询活动同步时，可以最小化这种延迟。

致谢
作者感谢Barracuda Networks提供免费的防火墙许可证，这些许可证支持了本研究中使用的实验基础设施。