Connext DDSSecureに切り替える必要がある理由

「セキュリティは、ボルトで固定するのではなく、組み込む必要があります。」本当です。あなたはそれを聞いたことがあります。私も聞いたことがあります。実際、IIoTが急速に現実化する中、このフレーズは何度も繰り返されているため、本当の力がなくても切迫感を生み出す決まり文句になるのではないかと心配しています。しかし、そもそもなぜセキュリティが強化されることが多いのでしょうか。理由を理解することは私たちがそれを避けるのに役立ちますか？そうだといい。経済的な理由から規制、教育、技術的な理由まで、このブログ投稿では詳しく説明できない多くの理由があります（詳細についてはIISFを参照してください）。

場合によっては、システムアーキテクチャの開発中に、脅威の状況、関連するリスク、およびセキュリティに関する考慮事項が十分に考慮されていません。その他の場合、既存のシステムは、まったく異なる脅威を伴うまったく異なる条件下で動作するように再利用されます。証券アナリストはしばしばそのような努力を否定し、当然のことながらそうです。ただし、より高いレベルの管理は、通常、市場の力によって意思決定を行うように推進され、効率と高性能の機能をより優先します。おそらく、セキュリティは、基本的なシステムを稼働させた後で心配できるオーバーヘッドです。あるいは、システムが「エアギャップ」になると思うかもしれません。ただし、システムの再構築にはコストがかかるため、その時点でセキュリティを検討するには遅すぎる可能性があります。したがって、基本的なシステムを実行した後、後でセキュリティを追加することによって最善を尽くそうとします。多くの場合、後でセキュリティを追加する方法が明確に定義されていないか、既知のベストプラクティスがある場合は、適切に実行されていません。では、なぜIIoTのセキュリティの残念な状況に驚かされる必要があるのでしょうか。

セキュリティエンジニアリングの課題の一部は、システムのビジネス機能とパフォーマンスのオーバーヘッドを最小限に抑えながら、エラー、ミスチャンス、または悪意から生じるセキュリティの脅威に対して許容可能な保護を提供するアーキテクチャを考案することです。これは簡単に聞こえますが、実際に実現するのは非常に困難です。特に、システムがより複雑で相互依存し、より大きく、より多様な人々のグループがそれらの実現に取り組んでいるためです。特にIIoTシステムの場合、セキュリティの脅威とそれに関連するリスクが急速に変化する環境では、相互運用性、パフォーマンス、スケーラビリティ、復元力、安全性、コンプライアンスという幅広い制約の中でセキュリティ対策を検討する必要があります。これらの考慮事項は、DDSセキュリティ仕様およびRTIのConnext®DDSSecureの開発において活発に議論および検討されてきました。

すでにDDSユーザーであるか、DDSが1つになることを評価している場合は、RTI Connext DDSSecureを検討する必要があります。以下では、Connext DDS Secureが、アーキテクトとエンジニアがセキュリティリスクとパフォーマンス要件に基づいてセキュリティとパフォーマンスの適切なバランスを見つけることを可能にするセキュリティ構成をどのように可能にするかについて説明します。また、臨床環境を安全に統合して患者の転帰を大幅に改善することを目的とした研究プロジェクトの例も提供します。

DDSセキュリティはユースケースに適していますか？

RTIエンジニアは通常、経験則を使用して、DDSに基づいて顧客のシステムを設計することが本当に意味があるかどうか、または別の接続フレームワークを使用する方がよいかどうかを確認します（この主題に関する詳細な技術的議論については、IICFを参照してください）。一般に、次の5つの質問のうち少なくとも3つに対する答えが「はい」の場合、DDSは、他の既存の接続フレームワークの中でシステムに最も適したフレームワークになります。

1. システムが短時間機能しなくなった場合、それは大きな問題ですか？
2. 過去2週間に「ミリ秒」または「マイクロ秒」と言ったことはありますか？
3. 10人以上のソフトウェアエンジニアがいますか？
4. 1つだけではなく、多くの場所にデータを送信していますか（たとえば、クラウドやデータベース）？
5. 新しいIIoTアーキテクチャを実装していますか？

質問1に対する答えが「はい」の場合、可用性とフォールトトレランスの要件は厳しくなります。 DDSは、完全なピアツーピア操作（したがって、単一障害点がない）や、所有権、耐久性、活気、期限QoSポリシーなど、いくつかの関連パラメーターを含む、これらの要件に大いに役立つ機能をすでに提供しています。さらに、DDSセキュリティでは、DDSドメインの分離、DDS参加者の認証、DDSトピックの公開またはサブスクライブの許可、およびデータがミドルウェアから上位レベルのアプリケーションに渡される前のDDSメッセージの認証が可能です。これらの機能により、一部のクラスのサービス拒否（DOS）攻撃の影響を防止および/または大幅に軽減できます。これらの機能は、ネットワーク、OS、およびアプリケーションレベルでの適切なアクセス制御手段と組み合わせることで、DDSベースのシステムで発生する可能性のあるDoS攻撃に対する保護を強化します。

質問2に対する答えが「はい」の場合、リアルタイムの要件がかなりある可能性があります。このような場合、リスクとパフォーマンスの両方の要件に基づいて、DDSシステムのセキュリティを微調整する必要があります。たとえば、公共の場にあるセンサーからの温度測定値が暗号化されて機密情報として送信されることを気にしないかもしれませんが、それらの測定値の信頼性は気にする可能性があります。 DDSセキュリティを使用すると、アプリケーションコードに変更を加えることなく、このような構成を定義して適用できます。

質問3に対する肯定的な答えは、かなり大規模なソフトウェアプロジェクトのさまざまな側面に取り組んでいるソフトウェア開発チーム間の相互運用性のコストを最小限に抑えたいことを意味している可能性があります。 DDSのデータ中心の設計により、ソフトウェアチームは、データ処理APIを必ずしも公開する必要なしに、どのデータ（つまり、タイプとトピック）を配布する必要があり、どのように（つまり、どのQoS設定で）配布するかについて合意できます。同様に、組み込みプラグイン（ドメインガバナンスや参加者権限ファイルなど）のDDSセキュリティ構成では、データ配布のセキュリティポリシーを定義できます。これらの明示的なポリシーは、データモデルとDDSドメインを保護する方法に基づいて作成されます。これらのポリシーは、セキュリティエンジニアとシステムアーキテクトが個別にレビューでき、アプリケーションコードに変更を加えることなく、リスク分析とパフォーマンス要件に基づいて再調整できます。

質問4に対する肯定的な答えは、マルチキャストを最大限に活用して、はるかに効率的なデータ配信を実現したいということを意味している可能性があります。マルチキャストの利点を利用できないTLS / DTLSなどの一般的なトランスポートレベルのソリューションとは異なり、DDSセキュリティにはマルチキャストサポートが組み込まれているため、より最適化されたデータ配信パフォーマンスが可能になります。

質問5に対する答えが正しければ、レガシーコードを処理する必要性についてあまり心配することなく、セキュリティを組み込むことができます。同時に、スケーラビリティ、相互運用性があり、要件のリストにベンダーロックインを回避できる可能性があります。 DDSは、IIoTのコア接続テクノロジの1つであり（詳細についてはIICFを参照）、公開されている一連の仕様に基づいています。さらに、DDS Securityは、認証、承認、暗号化、データのタグ付け、およびロギングに標準化されたAPIを備えたプラグ可能なアーキテクチャを利用しています。これらの機能は、データ配信のための明示的で詳細なセキュリティポリシーをサポートするとともに、DDSを次世代IIoTシステムの有力な候補にし、システムアーキテクチャにセキュリティを固定するのではなく、セキュリティを設計できるようにします。

これはすべて面白そうに聞こえますが、DDSセキュリティを使用している人はいますか？答えは強いはいです。 RTI Connext DDS Secureは、すでに多くの商用および政府機関のお客様によって評価され、使用されています。これらのアーリーアダプターから受け取ったフィードバックを製品ラインに反映しました。 DDSセキュリティ仕様をさらに明確化または更新する必要がある場合は、標準をさらに改善するためにDDSコミュニティに問題を提起しました。

例：安全な医療機器の相互運用性のためのDDSセキュリティ

DDSとDDSセキュリティの利点を示す興味深い例は、統合臨床環境（ICE）のコンテキストで表示されます。 ASTM F2761-09規格で定義されているICEフレームワークは、異種医療機器を統合し、それらの活動を調整して臨床ワークフローを自動化するためのアプローチを提供します。高レベルの観点から、ICEの背後にある考え方は、ICE標準に準拠する医療機器を、ネイティブまたはアフターマーケットアダプターを使用して、メーカーに関係なく他のICE準拠デバイスと相互運用できるようにすることです。正しく行われた場合、このアプローチは患者の安全性を劇的に改善する可能性があります。既知の例としては、手術室（OR）から集中治療室（ICU）への患者の移動や、Patient-Controlled Analgesia（PCA）システムでの誤警報の低減などがあります。これらの例の両方で、ベンダー間のデバイス間通信により、予防可能な医療ミスが大幅に減少します。 OpenICEは、基盤となる接続メカニズムとしてDDSを使用するICEプラットフォームのオープンソースリファレンス実装です。

OpenICE – MD PnP Labによって開発され、さまざまなタイプの医療機器間の接続を可能にします。

明示的なセキュリティ対策を導入しないと、ICEなどの医療IIoTプラットフォームは、患者の安全とプライバシーを危険にさらす可能性のあるセキュリティ攻撃の影響を受けやすくなります。攻撃の例は、攻撃者が中間者として行動する次のビデオで見ることができます。彼女は実際のオキシメータデバイスからの読み取り値をマスクし、患者の潜在的に重大な状態を看護ステーションから隠すという悪意を持って、誤ったオキシメータの読み取り値を作成します。

ICEの接続を保護するには、トランスポートレベルのセキュリティで十分ですか？

このホワイトペーパーのより詳細な攻撃シナリオで説明されているように、すべての通信がトランスポートレベルのセキュリティ（TLS / DTLSなど）で暗号化および認証されている場合でも、侵害されたインサイダーデバイスは、システム全体に損害を与える可能性があります。または公開できないことは、きめ細かいアクセス制御なしでは強制できません。 DDSセキュリティは、デバイスごとのきめ細かいアクセス制御を可能にし、この重要なタイプのインサイダー攻撃の影響を大幅に軽減します。

さらに、リスクに基づいてセキュリティ対策を微調整できることは、リソースに制約のあるデバイスや、帯域幅や遅延に敏感なアプリケーションを備えた大規模なICEまたは医療用IoTシステムにとって特に重要です。さらに、このような微調整は、コードベースの変更があったとしても最小限で行うのが理想的です。コードは変更できないか、変更にコストがかかりすぎる可能性があるためです。上記のように、効率的でスケーラブルな検出と情報交換に非常に役立つことが証明されているマルチキャストサポートの欠如は、これらの欠点に追加されます。

もちろん、これはTLS / DTLSベースのソリューションをまったく使用すべきではないということではありません。 RTIには、特定のユースケースにより適しているため、カスタマイズされたTLSまたはDTLSトランスポートをDDSで使用するお客様がすでにいます。 RTIでは、アーキテクチャ調査中にリスクとパフォーマンスの要件に基づいてそのような選択を行うことについて、情報に基づいた決定を下すお手伝いをさせていただきます。

結論と参考資料

特に重要なインフラストラクチャ用のアプリケーションを開発している場合は、RTI Connext DDSSecureとそれに基づく標準であるOMGDDSSecurityを検討することを強くお勧めします。次の参考資料が役立つ場合があります。

[1] OMGDDSセキュリティ仕様はここにあります。[2]インダストリアルインターネットリファレンスアーキテクチャ（IIRA）の最新バージョンは、ここにあります。[3]産業用インターネット接続フレームワーク（IICF）はここにあります。[4]産業用インターネットセキュリティフレームワーク（IISF）はここにあります。[5]統合臨床環境（ICE）の保護に関する情報は、このペーパーに記載されています。