HTTPSおよびAPI の呼び出しが、一方向データダイオードを介してどのように機能するか

現代の運用技術（OT）環境では、エンタープライズIT、クラウドプラットフォーム、セキュリティ監視システム、および分析アプリケーションへデータを送信する必要性がますます高まっています。そのデータには、テレメトリ、ログ、アラート、運用測定値、およびHTTP、HTTPS、またはAPIを通じて配信されるアプリケーションデータなどが含まれる場合があります。

しかし、ネットワークの観点から根本的な課題があります。HTTPやHTTPSは本来、双方向通信を想定して設計されていますが、データダイオードはデータが一方方向にのみ流れるように設計されているからです。

では、組織は、保護されたOTネットワークへの逆方向の経路を作ることなく、HTTPSやAPI に基づく統合を安全に利用するにはどうすればよいのでしょうか？

その答えは、アプリケーションレベルのデータ転送とネットワークレベルの通信の違いを理解することにある。

MetaDefender™Optical Diode および MetaDefender™Optical Diode Fend は、ハードウェアによって強制される一方向のデータフローと、プロトコルを意識した転送メカニズムを採用しており、従来の双方向ネットワーク接続を確立することなく、セキュリティ境界を越えてデータを転送することを可能にします。

HTTPSとは、TLS上で動作するHTTPのことです。通常のHTTPS接続では、クライアントがサーバーにリクエストを送信し、サーバーがレスポンスを返します。

ネットワークレベルでは、これには双方向の通信が必要となります。TCP自体、ハンドシェイクや双方向での継続的な制御トラフィックを必要とします。したがって、従来のHTTPSセッションは、あたかもそのダイオードが従来のファイアウォールやルーターであるかのように、物理的に一方向のデータダイオードを経由して単純にルーティングすることはできません。

これにより、重要な違いが生じます：

データダイオードは、通常の「双方向」HTTPS接続を「単方向」に変えるものではありません。むしろ、従来のエンドツーエンド通信モデルを打破することで、HTTPSベースのデータ転送を可能にするものです。

このプロトコル違反は、データダイオードアーキテクチャの根本的な特徴です。このアーキテクチャでは、ルーティング可能なネットワーク接続をあるセキュリティゾーンから別のセキュリティゾーンへと拡張するのではなく、対象となるデータを境界を越えて転送し、宛先側で適切な通信を再構築します。

OTからITへの移行に関する簡単なユースケースを考えてみましょう。

ある産業用アプリケーションが温度測定値を生成し、HTTPSを使用してそれをクラウド分析プラットフォームに送信する必要があります。API ：OTアプリケーション → HTTPS/API → クラウドプラットフォーム

従来のネットワークでは、OTアプリケーションは宛先とのネットワーク接続を確立し、HTTPリクエストを送信し、HTTPレスポンスを受信します。

データダイオードの場合、アーキテクチャが異なります。

典型的な一方向の実装は、概念的には次のように捉えることができます：OTアプリケーション → 送信側コネクタ／プロキシ → 一方向の光伝送 → 受信側コネクタ → IT／クラウドアプリケーション

重要な点は、これら2つのネットワークが、従来の双方向接続を共有していないということです。

ソース側のコンポーネントは、OT環境からデータを受信します。その後、そのデータは、ハードウェアによって強制される一方向の境界を越えて転送されます。宛先側では、受信側のコンポーネントがデータを再構築するか、または対象のアプリケーションに向けて転送します。

このアプローチにより、組織はアプリケーションデータの転送における意味論を維持しつつ、戻りのネットワーク経路を排除することができます。

例えば、こうだ：

1. OTシステムはテレメトリデータを生成します。
2. ソース側のサービスがテレメトリを受信します。
3. 関連するデータペイロードは、一方向転送用に準備されています。
4. ペイロードが光絶縁境界を越えます。
5. 転送されたデータは、宛先側のサービスによって受信されます。
6. 宛先側は、そのデータを企業システム、監視システム、分析システム、またはクラウドアプリケーションに配信します。

有用な情報がネットワーク間でやり取りできるにもかかわらず、ネットワーク間の分離状態は維持されている。

これは、2つのネットワーク間のHTTPSトラフィックを許可するファイアウォールルールを設定することとは根本的に異なります。ファイアウォールは、ポリシーで許可されている場合、双方向のTCP通信を許可することができます。一方、データダイオードは、ハードウェアレベルでその逆方向の通信経路を阻止するように特別に設計されています。

はい、 MetaDefender 、Optical Diode 、およびFend 50シリーズモデルは、産業用およびITプロトコルに加え、HTTPおよびHTTPSにも対応しています。

これを行うには、ダイオードの各側に、それぞれ送信元および宛先とのスタンドアロンTLS接続を終了および開始するために必要な証明書と鍵を用意する必要があります。

REST APIは通常、HTTPまたはHTTPSを介して実装され、OTデータを以下のものと統合するためにますます活用されています：

• Cloud 分析プラットフォーム
• SIEMおよびセキュリティ監視プラットフォーム
• エンタープライズ向けダッシュボード
• データ履歴管理システム
• 予知保全アプリケーション
• 一元化されたログ記録システム
• 発券・ワークフローシステム

一般的なRESTAPI でのやり取りは、通常次のような流れになります。クライアント → HTTP/S POST または PUT →API サーバー → HTTP レスポンス

このような状況では、アプリケーション層での応答は、通常のアプリケーション間のやり取りの一部となります。クライアントは、HTTP 200 ステータスコードと、場合によってはレスポンス本文に含まれるカスタムメッセージを期待します。

一方向アーキテクチャでは、ダイオードの入力側が、あたかも最終的な宛先からのものかのように、このレスポンスをプロキシすることができます。PUT/POSTの成功時に返されるカスタムレスポンス本文が既知で、再現可能である場合は、それもプロキシすることができます。

たとえば、OT監視システムでは、次のような情報を送信する必要がある場合があります：

POST /api/v1/telemetry

以下のペイロードを含む：

{"temperature":72,"pressure":101.3,"status":"normal"}

このアーキテクチャの目的は、OTとITの間に恒久的な双方向のAPI セッションを確立することではありません。その代わりに、データはダイオードを介して外部へ転送され、宛先側のアプリケーションに届けられます。

POSTリクエストを受信したダイオードの入力側は、クライアントに200 OKステータスを返した後、光絶縁を介してペイロードを転送し、続いて宛先サーバーに接続して、別のPOST /api/v1/telemetryリクエストでメッセージを配信します。

このため、一方向アーキテクチャは、データの外部への公開が主なビジネス要件となるテレメトリ、イベント、ログ、およびモニタリングAPIにおいて、特に有用となります。

暗号化は、転送中のデータの機密性を維持するのに役立ちますが、悪意のあるデータの送受信を防ぐことはできません。データダイオードは、これとは別の問題、すなわち通信の方向性という課題に対処するものです。

企業やクラウド環境が侵害された場合、ネットワークのアーキテクチャやセキュリティ対策によっては、従来の双方向接続が攻撃者にOT環境への侵入経路を提供してしまう可能性があります。

ハードウェアで実装されたデータダイオードにより、その復路が遮断されます。したがって、OTデータは、外部システムがトラフィックを保護対象ネットワークに逆送するためのルーティング可能な経路を生成することなく、保護対象ネットワークから送信されることになります。

重要インフラにおいては、この区別が極めて重要となる場合があります。データダイオードは、物理的なネットワークの分離を維持しつつ、運用情報を監視システムやエンタープライズシステムへ転送するために使用されます。

OTネットワークのセキュリティを強化したいとお考えですか？

OPSWATの「MetaDefender 」Optical Diode および「Fend」ソリューションが、重要なネットワーク境界を越えて、ハードウェアによって強制される安全な一方向のデータ転送をどのように実現するかをご覧ください。当社の専門家にご相談いただき、お客様のOTアーキテクチャやデータ転送の要件についてご検討ください。

OTからITへのアーキテクチャを設計する際には、アプリケーションプロトコルではなく、実際の通信要件から着手することが重要です。

次の3つの質問をしてみてください：

1. OT環境からどのようなデータを送信する必要があるか？

ITシステム、クラウドシステム、または監視システムに送信する必要があるテレメトリ、ログ、アラート、ファイル、プロセスデータ、その他の情報を特定します。

2. 宛先側は実際にデータを返信する必要があるのでしょうか？

多くの連携機能について、「接続性」が必要であると説明されていますが、その根底にあるビジネス要件は単に情報を外部に公開することだけである場合があります。返されるデータが単なる受信確認や成功通知である場合、一方向のアーキテクチャを採用することで、これらの応答を代理処理し、不要なネットワーク経路を排除することができます。

3. プロトコルの境界はどこに設定すべきか？

TCP、HTTPS、REST API などのプロトコルは、特定の双方向の挙動を前提としています。したがって、データダイオードアーキテクチャでは、セッションがどこで終了するか、境界を越えてデータがどのように転送されるか、そして宛先側のアプリケーションがそれをどのように受信するかを定義する必要があります。

このアプリケーションを意識したアプローチにより、組織は、ネットワークの分離とアプリケーションの統合を相互に排他的な要件と見なすことなく、OT接続の近代化を進めることができます。

1. データダイオードはHTTPSトラフィックを転送できますか？
   はい。MetaDefender Optical Diode およびMetaDefender FendはHTTP/HTTPSベースのデータ転送をサポートしていますが、HTTPSは物理的に一方向の境界を跨ぐ従来型の双方向エンドツーエンドセッションとして動作することはできません。データダイオードは、ダイオードの両側でそれぞれ暗号化されたセッションを終了させた後、新たなセッションを開始するため、これらのセッションを処理するための鍵と証明書が提供されている必要があります。
2. APIはデータダイオードを介して動作するのでしょうか？
   はい。API に基づくデータ転送は、アーキテクチャが PUT/POST による一方向通信を前提に設計されていれば、データダイオードを介して動作可能です。重要なのは、ダイオードを跨ぐ双方向のAPI セッションを必要とせず、代わりに送信側と受信側のメカニズムを利用して必要なアプリケーションデータを転送することです。
3. データダイオードはHTTPSの暗号化に代わるものですか？
   いいえ。これらはそれぞれ異なるセキュリティ上の問題を解決するものです。HTTPSはアプリケーショントラフィックに対して暗号化と認証を提供するのに対し、データダイオードはネットワーク通信の方向性をハードウェアによって制御します。
4. ファイアウォールとデータダイオードの違いは何ですか？
   ファイアウォールは、ソフトウェアで定義されたセキュリティルールを使用してトラフィックを制御し、双方向の通信を許可することができます。一方、データダイオードは物理的に一方向の通信を強制し、設計上、ネットワーク上の逆方向の経路を遮断します。
5. OTとIT間の通信にデータダイオードを使用する理由は？
   データダイオードを使用することで、組織は運用データ、テレメトリ、ログ、その他の情報をエンタープライズシステムやクラウドシステムと共有しつつ、それらのネットワークとの物理的な分離を維持することができます。これにより、双方向接続に伴う攻撃対象領域を縮小することができます。
6. MetaDefender Optical Diode とは？
   MetaDefender Optical Diode は、ネットワーク間の安全な一方向データ転送を実現するために設計された、ハードウェアで実装された光データダイオードです。HTTP や HTTPS などの IT プロトコルをはじめ、その他の対応プロトコルやユースケースにも対応しています。
7. MetaDefender Optical Diode Fendとは何ですか？
   MetaDefender Optical Diode Fendは、IT環境とOT環境間での安全な一方向データ転送を目的として設計されたデータダイオードソリューションです。モデルや導入形態に応じて、ITプロトコルおよび産業用プロトコルに対応しており、隔離されたOTネットワークと、運用データへのアクセスを必要とするシステムとの接続を支援します。