予兆保全システムをOTネットワークへ接続するには？分離・通信制御・Gateway設計の基本

産業インサイト・課題解決///

製造設備の予兆保全では、振動・温度・電流などの設備データを取得するために、センサーやIoT Gatewayを追加し、クラウド上の分析環境へデータを送信する構成が検討されます。

こうした構成は設備状態を継続的に把握するうえで有用ですが、OT（Operational Technology：制御・運用技術）の観点では、新しい機器と通信経路を既存環境へ追加することでもあります。

そのため、「設備データをクラウドへ送れること」と「OT環境へ安全に接続できること」は別に確認する必要があります。

本記事では、センサーやPLCからIoT Gatewayを経由してクラウドへ設備データを送信する仮想構成を例に、資産把握、データフロー、ネットワーク分割、通信制御、Gateway管理、本番運用までの基本的な考え方を整理します。

予兆保全IoTを追加するとOTの攻撃面はどう変わるか

予兆保全用の機器を追加すると、取得できるデータが増える一方で、管理する対象も増えます。

  • 振動・温度等のセンサー
  • IoT Gateway
  • 新しいネットワークインターフェース
  • クラウドとの通信経路
  • Gatewayの管理画面や保守機能
  • アカウント、証明書等の認証情報

機器が増えたこと自体が直ちに危険を意味するわけではありません。しかし、新しい資産、接続点、管理インターフェースが追加されれば、それぞれについて設定、認証、更新、ログ、責任者等を管理する必要があります。

NIST SP 800-82 Rev.3では、OTのセキュリティを考える際に、一般的な情報セキュリティだけではなく、設備の性能、信頼性、安全性等のOT固有の要件を考慮する必要があるとしています（Stouffer et al., 2023）。

予兆保全によって得られる機能と、追加で管理する対象を同時に確認する
BEFORE 既存の制御・監視環境
PLC・制御機器
HMI
OTネットワーク
既存設備通信
AFTER 予兆保全導入後に増える可能性がある対象
センサー
IoT Gateway
クラウド通信
管理インターフェース
認証情報
更新・保守経路
新しい機能だけでなく、新しく管理対象になる資産・通信・認証情報も設計範囲に含めます。

まず機器ではなく「データフロー」を整理する

OTセキュリティを検討するとき、最初からFirewallやセキュリティ製品を選ぶのではなく、まず必要なデータフローを整理します。

最低限、次の項目を明確にします。

  • 送信元：どの機器から通信するのか
  • 宛先：どの機器・サービスへ通信するのか
  • 方向：どちら側から通信を開始するのか
  • プロトコル・ポート：どの通信が必要なのか
  • 目的：監視、分析、管理、保守等の何に使うのか
  • 頻度：常時通信か、定期送信か

NIST SP 800-82 Rev.3では、ネットワークを分割・分離する際、必要な通信を把握するためにデータフローを利用し、GatewayやFirewall等で明示的に許可された通信だけを通す考え方が示されています（Stouffer et al., 2023）。

例えば「Gatewayはインターネットへ接続可能」とだけ定義するのではなく、「Gatewayが予兆保全クラウドの指定された宛先へ、分析用データを送信するために必要な通信を行う」という粒度まで整理します。

センサーGatewayからクラウドへ送信する構成を考える

説明用の仮想例として、振動センサー、温度センサー、PLCから必要な設備データをIoT Gatewayへ集約し、クラウドの分析環境へ送信する構成を考えます。

送信元宛先目的方向扱い
センサーGateway設備データ取得OT内部必要
PLCGateway分析に必要な設備値取得OT内部要件確認
Gatewayクラウド予兆保全用データ送信外向き必要
クラウドPLC制御指令外部からOT本仮想例では不要
Gateway任意の外部宛先目的不明外向き不要なら許可しない

本例の目的は設備状態の分析であり、クラウド側からPLCを直接制御する要件はありません。そのため、クラウドからOT側へ新しい接続を開始できる構成を当然の前提にはしません。

ただし、これはすべてのOTシステムで外部からの通信を禁止すべきという意味ではありません。リモート保守、設定配布、指令連携等が業務上必要な場合には、その必要性とリスクを別途評価します。

予兆保全用Gatewayを制御系からどう分離するか

次に、PLC等の制御機器と予兆保全用Gatewayを同じセキュリティ上の領域として扱うべきかを検討します。

IEC 62443-3-2:2020では、産業用オートメーション・制御システムをZone（ゾーン）とConduit（コンジット）へ分割し、ZoneおよびConduit単位でリスクを評価する考え方が示されています（IEC, 2020）。

Zoneは、同じようなセキュリティ要求を持つ資産をまとめる考え方です。ConduitはZone間の通信経路を表します。

予兆保全の仮想構成では、例えば「PLC等の制御系」「予兆保全・データ取得系」「IT・クラウド接続側」を分けて検討できます。ただし、単にVLANを三つ作ればIEC 62443へ準拠できるという意味ではありません。

異なる役割の資産をZoneとして整理し、境界を越える通信を管理する
ZONE 01 制御・設備 PLC、HMI、既存制御機器など
境界制御
必要通信のみ
ZONE 02 予兆保全・データ取得 センサー、IoT Gateway、データ収集機能など
境界制御
宛先・用途を限定
ZONE 03 IT・クラウド接続 IT側サービス、クラウド分析環境など
概念図であり、この構成だけでIEC 62443等への準拠を意味するものではありません。

VLANによる論理分割

VLANは、同じ物理ネットワーク機器を利用しながら論理的にネットワークを分割する方法の一つです。

NIST SP 800-82 Rev.3でもVLANはOTネットワークの分割方法の一つとして示されています。一方で、安全系等の高重要度機器については、物理的に異なるSwitchを利用した分割も検討事項とされています（Stouffer et al., 2023）。

つまり、「VLANは意味がない」「VLANだけで十分」と一律に考えるのではなく、設備の重要度や要求される分離レベルに応じて判断します。

OT・IT間の通信をFirewall・DMZで制御する

Zoneを分けた後は、Zone間で必要な通信だけを許可します。

Firewallは異なるネットワーク間の通信を制御する代表的な手段です。NIST SP 800-82 Rev.3では、可能な場合には「原則拒否し、明示的に必要な通信だけを許可する」方針が推奨されています（Stouffer et al., 2023）。

CISAも、ITとOTの境界を分割し、FirewallやDMZ（非武装地帯）等を用いて必要な通信経路を管理することを推奨しています（CISA, 2022）。

DMZは単にサーバーを置く場所ではありません。OTとIT・外部サービスの間で直接通信を増やさず、中継やデータ受け渡しを行うための境界領域として設計します。

ただし、すべての小規模な予兆保全構成で必ずDMZを新設する必要があるという意味ではありません。既存の工場ネットワーク構成、接続先、設備重要度、社内基準等から必要性を判断します。

クラウドからOTへの通信は本当に必要か

予兆保全の目的が設備データの収集・分析であれば、Gateway側からクラウドへデータを送信するだけで要件を満たせるケースがあります。

その場合、クラウド側からOT環境へ新しい接続を開始できる必要があるのかを確認します。不要であれば、安易にInbound通信を許可しないことが基本的な検討事項になります。

ただし、「クラウドから新規セッションを開始させない構成」と「物理的に一方向の通信」は別です。

通常のEthernet/IP通信では、アプリケーション上はデータを外へ送るだけでも、通信セッションとしては応答パケット等が存在します。物理的な一方向性が必要な環境では、一方向GatewayやData Diode等の仕組みが検討されることがあります（Stouffer et al., 2023）。

予兆保全だから一方向Gatewayが必要という意味ではありません。必要なセキュリティ水準、設備重要度、可用性要件等から選択します。

Gateway自体に必要なセキュリティ対策

ネットワーク境界だけでなく、IoT Gatewayそのものも管理対象となるOT・IoT資産として扱います。

  • 初期アカウント・初期パスワードをそのまま使用しない
  • 不要なアカウント・サービス・管理機能を停止する
  • 認証情報や証明書の所有者・更新方法を決める
  • OS・Firmwareの更新方針を決める
  • 管理画面へ接続できる端末・Networkを制限する
  • 構成変更やログイン等のログを取得する
  • 設定バックアップと復旧方法を確認する
  • 機器廃止時にCredentialや証明書を無効化する

更新についても、「最新Firmwareが公開されたら直ちに適用する」と単純化するのではなく、設備停止の必要性、ベンダー検証、互換性、安全性等を確認しながら進めます。

また、TLS等による通信暗号化は重要ですが、暗号化されていることと、通信相手・宛先・用途が適切に制限されていることは別の論点です。

リモート保守経路をデータ送信と分けて考える

Gatewayからクラウドへのデータ送信と、ベンダー等によるリモート保守接続は分けて整理します。

リモート保守では、外部からOT側の機器へ操作可能な経路が必要になる場合があります。そのため、単なる分析データ送信とは異なるアクセス権限、認証、接続時間、ログ、承認手順等の検討が必要です。

「クラウドサービスを利用するからリモート管理も常時許可する」とまとめず、データ送信と管理・保守を別のデータフローとして可視化します。

PoCから本番導入するときに確認したい項目

予兆保全では、PoCと本番環境でネットワーク条件が大きく異なることがあります。

PoCでは独立したモバイル回線や一時的なネットワークを使えたとしても、本番では既存OT、社内IT、クラウド、運用監視等との接続が必要になる場合があります。

そのため、本番移行前に少なくとも次を確認します。

  • 本番で追加される機器・ソフトウェアを把握したか
  • 各通信の送信元・宛先・目的が明確か
  • 必要なProtocol・Portを整理したか
  • 不要な外部起点通信がないか
  • OT・IT間の境界が明確か
  • Gatewayの管理責任者が決まっているか
  • Firmware・Credentialの管理方法が決まっているか
  • リモート保守経路を別途評価したか
  • ログを取得・確認できるか
  • 構成変更時のレビュー方法が決まっているか

予兆保全用のIoT機器を本番環境へ追加するときは、センサーやAIだけでなく、追加される資産と通信経路を整理します。Gatewayがどの設備から何を取得し、どの宛先へ何の通信を行うのかを明確にしたうえで、既存OTへの影響と必要な境界制御を検討します。

OT担当と情シスの責任分担をどう整理するか

予兆保全のIoT構成は、OT担当だけでも情シスだけでも完結しない場合があります。

対象主に整理する内容
OT・設備担当対象設備、取得データ、設備影響、停止条件、現場保全
情報システム・セキュリティNetwork境界、外部接続、Firewall、認証、ログ、社内基準
分析・予兆保全担当必要データ、取得頻度、Cloud宛先、分析要件
機器・サービスベンダーGateway仕様、更新方法、必要通信、保守方法

重要なのは、どの部門が「全部を見るか」ではなく、資産、通信、Credential、更新、障害対応等についてOwnerを明確にすることです。

予兆保全システム接続前のセキュリティチェックリスト

観点確認項目
資産追加するSensor・Gateway等を一覧化したか
機器のOwnerを決めたか
管理インターフェースを把握したか
データフロー送信元・宛先を把握したか
Protocol・Portを把握したか
通信目的を説明できるか
不要な通信を識別したか
NetworkZone・境界を整理したか
Zone間通信を制御しているか
外部からOTへの接続要件を確認したか
GatewayCredential管理者が決まっているか
Firmware・OS更新方法が決まっているか
管理アクセスを制限しているか
ログ取得方法が決まっているか
運用リモート保守を別途評価したか
変更管理方法が決まっているか
障害・インシデント時の担当を決めたか

このチェックリストの該当数だけで、OTネットワークの安全性を判定するものではありません。

対象設備の重要度、既存Network、安全要求、運用方法、社内基準等に応じて、必要な対策を組み合わせます。

まとめ

予兆保全のためにSensorやIoT GatewayをOTネットワークへ追加すると、取得できる設備データが増える一方で、管理する資産や通信経路も増える可能性があります。

そのため、最初からFirewallやセキュリティ製品を選ぶのではなく、「何のデータを、どこから、どこへ、何の目的で送るのか」というデータフローを整理することが重要です。

そのうえで、制御系、予兆保全・データ取得系、IT・クラウド接続側の役割を整理し、必要な通信だけを境界で許可します。VLAN、Firewall、DMZ、物理分割等は目的ではなく、必要な分離・通信制御を実現するための選択肢として検討します。

また、Gateway自体のCredential、Firmware、管理アクセス、ログ、リモート保守まで含めて管理し、PoC時の一時構成ではなく、本番で継続運用できる構成へ落とし込む必要があります。

SCI総合研究所株式会社のMIRASENTでは、「設備データをクラウドへ送りたいがOTネットワークへの接続方法を整理できていない」「PoCでは動いたが、本番化に向けて情シス・セキュリティ部門との調整が必要」「センサー・Gateway・データ分析を含めた全体構成を検討したい」といった段階から、対象設備、取得データ、通信要件、既存ネットワーク、保全運用等を整理しながら予兆保全の構成を検討します。

AIモデルだけでなく、設備データを継続して安全に取得・活用するための構成も含めて整理します。

MIRASENT｜設備保全・予兆診断について詳しく見る

参考文献

  • Stouffer et al. 2023. Guide to Operational Technology (OT) Security. National Institute of Standards and Technology. NIST Special Publication 800-82 Rev. 3. https://doi.org/10.6028/NIST.SP.800-82r3
  • International Electrotechnical Commission. 2020. Security for industrial automation and control systems — Part 3-2: Security risk assessment for system design. IEC 62443-3-2:2020. https://webstore.iec.ch/en/publication/30727
  • Cybersecurity and Infrastructure Security Agency. 2022. Layering Network Security Through Segmentation. CISA. https://www.cisa.gov/sites/default/files/2023-01/layering-network-security-segmentation_infographic_508_0.pdf