为什么您应该切换到 Connext DDS Secure

“安全应该是内置的，而不是固定的。”真的。你听说过。我也听说过。事实上，随着 IIoT 迅速成为现实，这句话被重复了很多次，我担心它会成为陈词滥调，会产生一种没有真正效力的紧迫感。但是，为什么安全性通常一开始就被固定住了呢？了解原因是否有助于我们避免它？但愿如此。有很多原因，从经济原因到监管、教育和技术原因，我无法在这篇博文中详细介绍（有关更多详细信息，请参阅 IISF）。

在某些情况下，在系统架构的开发过程中并未充分考虑威胁形势、相关风险和安全考虑因素。在其他情况下，现有系统被重新用于在完全不同的条件下运行，威胁完全不同。安全分析师通常对这种努力不屑一顾，这是可以理解的。然而，更高级别的管理通常会受市场力量的驱使做出决策，将效率和高性能功能置于更高的优先级。也许安全性是一种开销，一旦您启动了基本系统，您就可以担心。或者您可能认为您的系统将是“气隙式的”。但由于重新构建系统的成本，此时考虑安全性可能为时已晚。因此，在基本系统运行之后，人们会尝试通过添加安全性来尽力而为。在许多情况下，后来如何添加安全性的过程没有明确定义，或者在已知最佳实践的情况下，没有正确遵循。那么，我们为什么要对 IIoT 中令人失望的安全状况感到惊讶？

安全工程的部分挑战在于设计架构，以提供可接受的保护，防止源自错误、意外或恶意的安全威胁，同时将业务功能和系统性能的开销降至最低。这听起来很容易，但在实践中却很难实现——尤其是当系统变得更加复杂和相互依赖，以及随着更大、更多样化的人群努力实现它们时。特别是对于 IIoT 系统，在安全威胁和相关风险变化非常迅速的环境中，应在互操作性、性能、可扩展性、弹性、安全性和合规性等更广泛的限制范围内考虑安全措施。在 DDS 安全规范和 RTI 的 Connext® DDS Secure 的开发过程中，这些考虑因素都得到了热烈的讨论和考虑。

如果您已经是 DDS 用户或正在评估 DDS 以使其成为一名用户，那么您绝对应该考虑 RTI Connext DDS Secure。在下文中，我将讨论 Connext DDS Secure 如何允许安全配置允许架构师和工程师根据安全风险和性能要求找到安全和性能的正确平衡。我还将提供一个研究项目的示例，该项目旨在安全地整合临床环境以显着改善患者的治疗效果。

DDS 安全是否适合您的用例？

RTI 工程师通常使用经验法则来判断基于 DDS 构建客户系统是否真的有意义，或者他们是否最好使用其他连接框架（有关该主题的详细技术讨论，请参阅 IICF）。一般来说，如果以下五个问题中至少三个的答案是“是”，那么在其他现有连接框架中，DDS 将是最适合该系统的框架：

1. 如果您的系统在短时间内停止工作，这是否是一个大问题？
2. 在过去两周内，您是否说过“毫秒”或“微秒”？
3. 你有超过 10 名软件工程师吗？
4. 您是否将数据发送到多个地方，而不是一个地方（例如，发送到云或数据库）？
5. 您是否正在实施新的 IIoT 架构？

如果您对问题 1 的回答是肯定的，则您有严格的可用性和容错要求。 DDS 已经提供了极大地帮助满足这些要求的功能，包括完全对等操作（因此没有任何单点故障），以及几个相关参数，包括所有权、持久性、活跃度和期限 QoS 策略。此外，DDS 安全允许 DDS 域的隔离、DDS 参与者的身份验证、授权他们发布或订阅 DDS 主题以及在数据从中间件传递到更高级别应用程序之前对 DDS 消息进行身份验证。这些功能允许预防和/或显着减轻某些类别的拒绝服务 (DOS) 攻击的影响。这些功能与网络、操作系统和应用程序级别的适当访问控制措施相结合，将为基于 DDS 的系统中的潜在 DoS 攻击提供更好的保护。

如果您对问题 2 的回答是肯定的，那么您可能有重要的实时需求。对于此类情况，您可能希望根据风险和性能要求微调 DDS 系统的安全性。例如，您可能不关心来自公共空间传感器的温度读数是否经过加密和保密传输，但您可能关心这些读数的真实性。 DDS 安全允许您定义和强制执行此类配置，而无需对您的应用程序代码进行任何更改。

对问题 3 的肯定回答可能意味着您希望最小化软件开发团队之间的互操作性成本，每个团队都致力于一个相当大的软件项目的不同方面。 DDS 以数据为中心的设计允许软件团队就应该分发哪些数据（即类型和主题）以及如何分发（即使用什么 QoS 设置）达成一致，而无需公开数据处理 API。同样，内置插件（例如域治理和参与者权限文件）的 DDS 安全配置允许定义数据分发的安全策略。这些明确的策略是根据您的数据模型以及您希望如何保护 DDS 域创建的。这些策略可以由安全工程师和系统架构师独立审查，并根据风险分析和性能要求进行重新调整，而不会对应用程序代码进行更改。

对问题 4 的肯定回答可能意味着您希望充分利用多播来实现更高效的数据传输。与 TLS/DTLS 等无法利用多播优势的流行传输级解决方案不同，DDS 安全内置多播支持，可实现更优化的数据传输性能。

如果您对问题 5 的回答是肯定的，那么您就有机会构建安全性，而不必过多担心必须处理遗留代码。同时，您可能拥有可扩展性、互操作性并避免供应商锁定您的需求列表。 DDS 是 IIoT 的核心连接技术之一（有关更多详细信息，请参阅 IICF）并基于一组公开可用的规范。此外，DDS 安全利用具有标准化 API 的可插拔架构，用于身份验证、授权、加密、数据标记和日志记录。这些功能加上支持明确和细粒度的数据分发安全策略，使 DDS 成为下一代 IIoT 系统的有力候选者，允许在您的系统架构中设计安全性，而不是将其固定在系统架构上。

这一切听起来很有趣，但是有人在使用 DDS Security 吗？答案是肯定的。 RTI Connext DDS Secure 已经被我们的许多商业和政府客户评估和使用。我们将从这些早期采用者那里收到的反馈反映到我们的产品线中。如果需要对 DDS 安全规范进行进一步澄清或更新，我们会向 DDS 社区提出问题以进一步改进标准。

示例：用于安全医疗设备互操作性的 DDS 安全

一个有趣的例子展示了 DDS 和 DDS 安全的好处，它出现在集成临床环境 (ICE) 的背景下。由 ASTM F2761-09 标准定义的 ICE 框架提供了一种集成异构医疗设备并协调其活动以实现临床工作流程自动化的方法。从高层次的角度来看，ICE 背后的想法是允许符合 ICE 标准的医疗设备，无论是原生的还是使用售后市场适配器，都可以与其他符合 ICE 标准的设备进行互操作，而不管制造商是谁。如果操作正确，这种方法有望显着改善患者安全。已知示例包括将患者从手术室 (OR) 转移到重症监护室 (ICU) 或减少患者自控镇痛 (PCA) 系统中的误报。在这两个示例中，跨供应商设备间通信显着减少了可预防的医疗错误。 OpenICE 是 ICE 平台的开源参考实现，使用 DDS 作为其底层连接机制。

OpenICE – 由 MD PnP 实验室开发，可实现各类医疗设备之间的连接。

如果没有部署明确的安全措施，ICE 等医疗 IIoT 平台很容易受到可能危及患者安全和隐私的安全攻击。可以在以下视频中查看攻击的示例，其中攻击者充当中间人。她掩盖了实际血氧仪设备的读数，并捏造虚假血氧仪读数，恶意将患者潜在的危急情况隐藏在护理站之外。

传输级别的安全性是否足以保护 ICE 中的连接？

如本文中更详细的攻击场景所述，即使所有通信都使用传输级安全性（例如 TLS/DTLS）进行加密和身份验证，被入侵的内部设备仍然会造成系统范围的损坏，仅仅因为它可以如果没有细粒度的访问控制，或无法发布是不可强制执行的。 DDS Security 允许对每台设备进行细粒度的访问控制，从而在很大程度上减轻这种重大内部攻击的影响。

此外，能够根据风险微调安全措施对于资源受限的设备或具有带宽或延迟敏感应用的大规模 ICE 或医疗物联网系统尤为重要。此外，理想情况下，这种微调应该在对代码库进行最少更改（如果有的话）的情况下发生，因为代码可能无法修改或修改成本太高。如上所述，缺乏多播支持（已证明对于高效和可扩展的发现和信息交换非常有用）是这些缺点的补充。

当然，这并不是说根本不应该使用基于 TLS/DTLS 的解决方案。 RTI 已经有客户将我们的定制 TLS 或 DTLS 传输与 DDS 一起使用，因为它们更适合他们的特定用例。在 RTI，我们很乐意帮助您在我们的架构研究期间根据风险和性能要求做出明智的决定。

结论和参考文献

我们强烈建议您考虑 RTI Connext DDS Secure 及其所基于的标准 OMG DDS Security，尤其是在您为关键基础设施开发应用程序时。您可能会发现以下参考资料很有用：

[1] OMG DDS 安全规范可以在这里找到。[2]可在此处找到最新版本的工业互联网参考架构 (IIRA)。 [3]可在此处找到工业互联网连接框架 (IICF)。 [4]可以在此处找到工业互联网安全框架 (IISF)。 [5]可以在本文中找到有关保护集成临床环境 (ICE) 的信息。