在安全与通讯方面的比较外文翻译资料

 2022-08-09 20:20:05

英语原文共 10 页,剩余内容已隐藏,支付完成后下载完整资料


在安全与通讯方面的比较

在自动化的世界中,安全性已成为讨论的主要来源和大多数系统的重要组成部分。OPC基金会长期以来一直支持由多个供应商制造的系统之间的安全互操作性,最初是OPC DA,OPC A&E,OPC HAD和OPC安全接口(现在统称为OPC Classic),现在则是OPC统一体系结构(UA)。这两个标准提供了通用功能,但是OPC UA统一并增强了OPC Classic接口提供的功能。从安全性角度考虑,这两个标准提供了一些不同的安全视图和这些视图不同的实现方式。在本文中,我将讨论安全性的各个方面,以及如何用这两种标准来满足安全性,并着重强调这些差异。

本文将重点讨论安全性,因为它与供应商提供的系统之间的通信有关。安全性还有许多其他方面,在部署系统时也应考虑这些方面,但是本文仅关注与通信相关的方面。

本文将尝试解决安全性中一些最常见的方面。安全方面包括在两个系统之间传输数据的加密和签名、应用程序(服务器或客户端)的标识、客户端应用程序用户身份的验证和授权、经过防火墙的数据传输和审核。考虑安全性时,还必须考虑应用程序在其中执行的环境。

应用程序可以在Windows域、Windows用户组、独立计算机或混合的操作系统环境(即不只是Windows)中运行。我将尝试讨论上述每一个,以及它们与OPC Classic和OPC UA之间的关系。

OPC Classic和OPC UA安全性概述

让我们讨论一下OPC Classic的一般安全性。作为一系列规范集合的OPC Classic并未将安全定义为任何接口规范的一部分。OPC Classic建立在COM / DCOM传输之上,COM / DCOM传输是基于Microsoft的通信协议,并具有安全功能(请参见图2-OPC Classic Communication)。

OPC 基金会定义了有关如何通过OPC安全规范为COM / DCOM层配置安全性的议案。 文件已经生成了描述Windows / DCOM提供的安全性以及如何在OPC Classic领域中应用它(有关文件列表,请参阅本文的结尾)。某些重要的配置问题是将DCOM限制为TCP以及限制它的访问。DCOM / Windows安全性的关键方面是它基于用户以及用户(应用程序正在执行的用户)被授予的权限。简而言之,OPC Classic依赖于被底层通信协议和Windows操作系统族所提供的安全性。对于存在多个操作系统的使用用例中,OPC Classic很难实施,因为它要求COM / DCOM在备用操作系统上可用。有一些第三方版本的DCOM可用于某些非Windows平台,但通常OPC Classic在非Windows平台上很少被使用。

现在我们讨论一下OPC UA的一般安全性。OPC UA有一个规范(第2部分),描述了有关安全威胁和攻击以及如何设计OPC UA标准来减轻这些威胁和攻击。OPC UA在整个13章的规范中都包含与安全相关的功能。作为一个标准,OPC UA并未锁定到单一的通信传输或操作系统,因此它在传输层上方的一层定义了安全性。这确保了在添加新的传输时也将保证安全性。图3说明了TCP的传输。其他传输可能会在TCP和OPC UA之间添加一个附加层。OPC UA的这个安全功能可随安全标准的提高而轻松增强,而无需更改应用程序。人们还对它进行了建模,并用于当前的最佳安全实践(例如银行业务)。

通常,OPC Classic和OPC UA都具有安全的能力。

系统之间数据流的加密和签名

数据流(消息)的签名确保没有人可以更改发送和接收的内容。它要求生成可以由消息的接收者轻松重新生成的加密签名。如果发生任何更改,接收方将不会获得相同的签名,并且可以提示消息已被更改。加密使签名更上一层楼,除了收件人之外,其他任何人都无法读取邮件中的内容。它使用消息中的密码学翻译,所有只有接收者才拥有解密消息所需的所有信息。

可以配置DCOM以提供数据签名和加密。在DCOM世界中,通常将其讨论为确保数据是可验证的并且是私有的。它的设置和配置因Windows版本和部署计算机的环境而异。在Windows域中,它需要相当简单的配置(识别DCOM客户端和服务器,并选中需要专用通信的复选框)。关键是在默认情况下,DCOM没有启用此功能,但是为了安全通信,应该对其进行配置。在非域环境中,它需要在每台客户端和服务器计算机上进行设置,但这可以作为DCOM所需配置的一部分来完成。

对于OPC UA,默认传输选项已启用“签名和加密”。服务器配置可以选择客户端可用于连接的通信选项(即最终用户可以选择“无”以禁用加密和签名,或者可以选择“仅允许签名”或“仅签名并加密”)。所有经过认证的服务器和客户端都必须支持此方面的安全性,并且它是由用于构建应用程序的堆栈和工具包提供的。只需在服务器上执行配置,客户端只需选择要使用的可用通信选项中的哪个即可。由于OPC UA是为多个平台设计的,因此此功能对于基于域,工作组或基于多平台的应用程序不会不同。

识别和保护应用程序

此功能可确保一个应用程序仅与适当的其他应用程序通信,即,中间或恶意服务器或客户端中没有其他程序。给定客户端仅与授权服务器通信,并且服务器仅响应授权客户端。 这超出了限制用户操作的范围,因为它限制了允许哪个应用程序实例与哪个其他应用程序进行通信。

在DCOM中,可以对其进行配置,但是由于需要配置DCOM以外的其他项(例如防火墙和RPC),因此需要做大量的工作。并非所有的OPC Classic服务器和客户端都可以支持这种类型的限制,因此需要进行测试。通常,我们并不需要配置这种类型的限制,而是仅配置用户访问权限(请参阅用户访问权限)。

在OPC UA中,配置这是必需的,默认情况下也是选中的。所以需要所有应用程序来支持此认证。当然,可以使用不同的访问权限来配置安装在两台不同计算机上的同一应用程序。 访问权限适用于客户端和服务器,因此安装在两台不同计算机上的同一客户端可以具有被允许连接访问的不同服务端。例如,安装在两个操作站上(对于工厂中两个不同区域)的标准客户端将有允许其连接的不同服务器列表。在OPC UA中,这一点是通过使用证书来完成的。所有应用程序都有分配给它们的唯一证书和信任列表,该列表指示哪些其他证书(应用程序)将被信任(允许)。OPC 基金会提供了用于配置证书的工具(供应商),并且证书颁发机构(CA)允许相对容易地进行配置,特别是针对具有IT经验的人。OPC UA已经宣布了全球发现服务功能(第12部分),该功能使非IT人员更容易部署证书。此功能在可用时将允许通过简单的菜单选择来管理应用程序(例如域)中的所有证书。

用户访问权限

这是对服务器中哪些项目可以访问以及给定用户可以以哪种方式访问(读取/写入/浏览)的限制。例如:是否允许用户读取值,写入值,浏览地址空间等。这种访问授权意味着用户已被识别并认证。客户端必须向服务器提供凭据,以标识正在执行应用程序的用户。用户访问限制可能非常广泛,就像适用于整个服务器一样,也可以指定为服务器中的单个项目。用户访问也可以被忽略,因为可以将其配置为匿名访问。

DCOM通常将其安全性基于这种服务器范围的访问。在域环境中,我们可以轻松配置它,但默认情况下其不受限制。域将需要标识所有OPC Classic服务器,并为与将要连接的客户端关联的用户组(角色)分配适当的访问权限。 可以将该配置从域推送到每个服务器。 由于域中的所有帐户都可以通过中央控制器进行管理,因此这很容易做到,为了确保连接性我们也必须这样做。在非域环境中,可以对其进行配置,但是需要其他工作或技巧来识别和确保用户(所有计算机上的公共帐户,公共用户组(角色)等)。对于两个或多个不受信任域的特定情况,我们无法配置用户安全性,所幸这种配置类型很少发生。这通常仅由两家公司必须共享数据时才产生。与一般的DCOM读写访问权限相比,OPC Classic应用程序可以为给定项目提供单独的访问限制,但实际上很少有应用程序包括这种类型的限制。通常,它具有广泛的访问权限,因为允许给定用户访问服务器以进行读取或读取/写入。由于有时应用程序使用服务帐户(例如控制台)运行并且需要实际的操作员登录,因此可能会增加其他复杂性。通常,控制台应用程序具备处理这些检查所需的模拟功能,但并非所有应用程序都将提供此类功能。

在OPC UA中,有用于标识用户的三个选项:用户帐户和密码,Kerberos令牌、证书。要求所有应用程序都支持用户名/密码,这是最简单的实现,但配置起来可能会更加繁琐,因为必须在每个应用程序上对其进行配置。Kerberos是交换用户身份而不交换密码的标准方式。Windows域支持它,并且可以在具有Kerberos令牌服务器的环境中轻松实现。证书是OPC UA的简单扩展,因为已经需要证书处理来识别应用程序(请参见2)。选择哪种标识用户的方式是特定于应用程序的。一旦识别并验证了用户,应用程序就可以限制给定用户的读、写、浏览等访问权限。这就像在DCOM中一样,它取决于应用程序,而大多数应用程序实际上并不提供单独的安全性,他们通常将用户分组(工程师,操作员等),并在服务器范围内通过这些组产生限制。OPC UA用户标识以类似的方式在域、跨域、多个平台和工作组环境中工作。

防火墙

防火墙用于系统中以保护计算机和访问点免受入侵。它们通过限制允许的连接类型、允许连接的端口和允许的通信协议来起作用。 在大多数系统中,它们是强制性的以确保安全性。

OPC Classic使用DCOM(内部使用RPC)。默认情况下,RPC使用动态端口分配。由于需要打开大量端口,因此这使得配置防火墙非常困难。此外,在OPC Classic中,服务器需要能够启动与客户端的通信,以获取从服务器连接客户端的回调请求。此功能要求所有客户端计算机也都被配置的就好像服务器一样,并且所有服务器计算机也都必须被配置的好像它们是客户端一样,即,以相反的方向打开防火墙。还可以将RPC配置为或者限制使用的端口范围,或者可以将固定端口静态分配给给定的OPC Classic服务器。固定端口分配可能不适用于所有OPC Classic产品,因此应测试给定的供应商产品,以确保允许使用静态端口。

OPC UA为通信管道定义一个或多个固定端口。实际端口由服务器公开的端点和协议确定。HTTP协议可以在默认端口80上运行,该端口很少被阻塞。客户发起所有通信,因此没有外向通信。 固定端口和客户端启动的通信可以非常轻松地配置防火墙。只需按一下按钮,OPC 基金会配置工具(取决于所使用的防火墙)即可执行此配置。

审核

审核是跟踪系统中所有与安全相关的消息的生成。它包括所有连接到系统的失败尝试、成功连接到系统的尝试、更改系统的任何操作、发生的任何错误或违反安全性的行为。审核记录的目的是允许在检测到某些问题之后对系统中的操作进行分析,并且这些分析用以发现问题。

默认情况下,DCOM / COM不会生成任何级别的日志,但是用户可以启用DCOM连接请求、系统对象访问和SMB登录日志记录。通过启用这些功能,操作系统会生成可用于跟踪活动的事件。但这仍然没有提供有关活动是什么的详细信息,仅提供了“连接者”。经典应用程序内置了需要额外审核功能的内容。这种审核类型未定义为任何OPC Classic规范的一部分。

OPC UA定义了审核消息以及何时审核消息被需要。支持审核配置文件的OPC UA服务器可以为所有与连接和安全相关的操作生成审核事件。此外,它为所有更改服务器上地址空间的用户操作生成审核事件。OPC UA提供的审核还支持将审核事件从客户端连接到服务器,从而可以更轻松地查看来自多个设备的审核日志。

总结

可以配置OPC Classic以提供相当多的安全性,但是所有安全性实际上是由Windows和DCOM / COM中的功能提供的。这确实需要大量的配置和专业知识。某些环境不支持安全配置,某些应用程序无法支持所有安全配置。

OPC UA在设计时就考虑了安全性,因此在整个规范集中集成了安全性。要获得认证,应用程序必须支持所有的基本安全功能。OPC UA旨在多种环境和多种平台上工作,因此,它并不局限于一个平台,也没有内置于平台中的安全性。

剩余内容已隐藏,支付完成后下载完整资料


资料编号:[238641],资料为PDF文档或Word文档,PDF文档可免费转换为Word

原文和译文剩余内容已隐藏,您需要先支付 30元 才能查看原文和译文全部内容!立即支付

以上是毕业论文外文翻译,课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。