Web of Things (WoT) アーキテクチャ

4.1.1 消費者

消費者空間には、接続によって恩恵を得られる複数の資産がある。部屋の利用状況に基づいて照明とエアコンをオフにできる。気象条件と人の存在に基づいてブラインドを自動的に閉じることができる。エネルギーやその他の資源の利用は、使用パターンと予測に基づいて最適化できる。

この項の消費者のユースケースには、スマートホームのユースケースが含まれる。

図1は、スマートホームの例である。このケースでは、ゲートウェイは、対応するKNX、ECHONET、ZigBee、DECT ULE、Wi-SUNなどのローカルな通信プロトコルにより、センサー、カメラ、家電などのエッジデバイスに接続されている。一つの家に複数のゲートウェイが存在可能で、各ゲートウェイは複数のローカルなプロトコルをサポートできる。

ゲートウェイはインターネット経由でクラウドに接続できるが、クラウドに直接接続できる機器もある。クラウドで実行されているサービスは、エッジデバイスからデータ収集を行い、そのデータを分析し、その後でエッジデバイスやその他のUXデバイスを介してユーザに価値を提供する。

スマートホームは、リモートのアクセスと制御、音声制御、ホームオートメーションなどのメリットを消費者に提供する。スマートホームにより、デバイスの製造者がリモートでデバイスを監視しメンテナンスを行うことも可能となる。スマートホームは、エネルギー管理やセキュリティ監視などの付加価値サービスを実現できる。

4.1.2 産業

この項の産業に関するユースケースは、様々な産業部門に適用できる。
アプリケーションシナリオには重複する性質があるため、異なる業種に似たようなユースケースが存在する。

4.1.2.1 例: スマートファクトリー

図2は、スマートファクトリーの例である。このケースでは、現場レベル、セル、工場ラインの制御装置が、PROFINET、Modbus、OPC UA TSN、EtherCAT、CANなどの産業用通信プロトコルに基づいて、様々な工場設備をオートメーション化している。産業用のエッジデバイスは、様々な制御装置からデータを選択収集して、例えば、ダッシュボードを用いた遠隔監視などのクラウドのバックエンドサービスでデータを利用できるようにしたり、予防保全のためにデータの分析を行う。

スマートファクトリーでは、接続された製造設備と製品の高度な監視が必要である。機械の故障を予測し、異常を早期に発見して、コストのかかるダウンタイムとメンテナンスの労力を防ぐことで恩恵を受けられる。

さらに、有毒ガス、過度な騒音や熱の存在に関して、接続された製造設備と生産設備の環境を監視することにより、労働者の安全性が向上し、事件や事故のリスクが減少する。

生産設備のリアルタイム監視とKPI計算は、生産性の問題を検出し、サプライチェーンを最適化するのに役立つ。

4.1.3 輸送と物流

車両、燃料費、メンテナンスの必要性、割り当ての監視は、業務用車両を最大限活用できるように最適化するのに役立つ。

輸送品の一貫した品質と状態を確保するために、積み荷が配送中であることを追跡できる。これは、倉庫から冷蔵トラック、配達までのコールドチェーンの完全性を言明するのに特に役立つ。

倉庫とヤードでの一元的な在庫の監視と管理により、在庫切れや過剰在庫の状況を防ぐことができる。

4.1.4 公益事業

住宅や商工業 (C&I) のメーターの自動読み取りと請求により、資源の消費と潜在的なボトルネックに関する継続的な洞察が得られる。

分散型再生可能エネルギー生成装置の状態と出力を監視することにより、分散型エネルギー資源の最適化が可能になる。

配電設備の監視と遠隔制御は、配電プロセスの自動化に役立つ。

発電と配電のインフラストラクチャの継続的な監視により、公益事業の現場担当者の安全性が向上している。

4.1.5 オイルとガス

タンクや貯蔵庫における貯蔵量を監視および制御することに加えて、海洋プラットフォームの監視や、パイプラインの漏れを検知および予測することは、環境のために加えて，従業員にとっての労働安全性改善に役立つ。

様々な貯蔵タンクと配送パイプ/トラックを通じた分散型在庫の自動計算により、計画の改善と資源の最適化が可能となる。

4.1.6 保険

連結構造物、業務用車両などの高い価値を持つ資産の予防的資産監視により、事件の予測と早期発見を通して、深刻な損害と高い損失のリスクを軽減する。

利用状況の追跡とカスタマイズされた保険契約を用いて、利用ベースの保険を提供できる。

予測的な気象監視を行い、業務用車両を屋根付き車庫にルート変更させると、ひょう害、樹木の被害による損失を抑えることができる。

4.1.7 土木工事と建設

産業上の安全性を監視することにより、セキュリティ上の危険性のリスクが軽減される。建設現場の資産を監視することで、被害や損失を防止できる。

4.1.8 農業

土壌の状態監視と、散水、施肥の最適な計画の作成、農産物の状態監視により、農産物の品質と生産量が最適化される。

4.1.9 医療

臨床試験データのデータ収集と分析は、新しい領域に関する洞察を得るのに役立つ。

遠隔患者モニタリングは、高齢者や入院後の患者の重篤な状況を見逃すリスクを軽減する。

4.1.10 環境モニタリング

環境モニタリングは通常、測定データを共通のゲートウェイ、エッジデバイス、クラウドサービスに送信する多くの分散型センサーに依存している。

クリティカルな環境状態を検出するために、大気汚染や水質汚染、そして、微粉塵、オゾン、揮発性有機化合物、放射能、温度、湿度などのその他の環境リスク要因を監視することにより、回復不能な健康や環境の被害を防ぐことができる。

4.1.11 スマートシティ

橋梁、ダム、堤防、運河の資材の状態、劣化、振動の監視により、保守修理作業を発見し、重大な被害を防止することができる。幹線道路の監視と適切な標識の提供により、最適な交通の流れが確保される。

スマートパーキングにより、駐車スペースの利用と可用性の最適化と追跡が行われ、課金/予約が自動化される。

存在検知、天気予報などに基づく街灯のスマート制御により、コストが削減される。

ゴミ容器の監視により、廃棄物管理やゴミ収集ルートを最適化できる。

4.1.12 スマートビルディング

ビル全体のエネルギー使用量の監視は、資源消費の最適化と無駄の削減に役立つ。

冷暖房空調設備 (HVAC)、エレベーターなどのビル内の設備を監視し、早期に問題を解決することで、居住者の満足度が向上する。

4.1.13 コネクテッドカー

稼働状況の監視、サービスニーズの予測により、メンテナンスの必要性とコストが最適化される。危機的な道路・交通状況に関する早期警告システムの通知により、ドライバーの安全性が強化される。

4.1.13.1 コネクテッドカーの例

図3は、コネクテッドカーの例である。このケースでは、ゲートウェイはCANを介して車の部品に接続され、独自のインターフェースを介してカーナビゲーションシステムに接続される。クラウドで実行されているサービスは、交通のパターンを判断するために、車の部品からプッシュ配信されるデータを収集し、複数の車からのデータを分析する。このケースでは、ゲートウェイはクラウドサービスを利用して交通データを取得し、カーナビゲーションシステムを通じてドライバーに表示することもできる。

4.2.1 デバイスコントローラー

図4で示しているように、最初のユースケースは、ユーザが操作するリモートコントローラーで制御されるローカルなデバイスである。リモートコントローラーは、ローカルなホームネットワークを介して電子機器に直接アクセスできる。このケースでは、リモートコントローラーはブラウザやネイティブなアプリケーションで実装できる。

このパターンでは、電子機器などの少なくとも一つのデバイスには、他のデバイスからのリクエストを受け入れて応答できるサーバーの役割があり、時として機械的なアクションを開始する。リモートコントローラーのような他のデバイスには、センサー値の読み取りやデバイスの電源投入などの、リクエストに応じてメッセージを送信できるクライアントの役割がある。さらに、デバイスの現在の状態やイベントの通知を送信するために、デバイスは、サーバーの役割を持つ別のデバイスに対してメッセージを送信できるクライアントの役割を持つことができる。

4.2.2 ThingとThing

図5は、直接的なThingとThing (Thing-to-Thing) の相互作用の例を示している。シナリオは次のとおりである。センサーが部屋の状況変化、例えば、温度が基準値を超えていることを検出し、電子機器に対して「オンにする」などの制御メッセージを発信する。センサーユニットは、他のデバイスにトリガーメッセージを発信できる。

このケースでは、サーバーの役割を持つ二つのデバイスが接続されている場合、少なくとも一方のデバイスには、他方に対して作動させたり通知するためにメッセージを発信するクライアントの役割もなければならない。

4.2.3 リモートアクセス

図6で示しているように、このユースケースには、モバイルリモートコントローラー (例えば、スマートフォン) が含まれる。リモートコントローラーは、セルラーネットワークや、Wi-FiやBluetoothなどのプロトコルを用いたホームネットワークなどの様々なネットワーク接続とプロトコルを切り替えることができる。コントローラーがホームネットワークにある場合、それは信頼できるデバイスであり、セキュリティやアクセス制御を追加する必要はない。コントローラが信頼できるネットワークの外にある場合は、アクセス制御やセキュリティのメカニズムを追加適用して、信頼関係を確保しなければならない。このシナリオでは、様々なネットワークアクセスポイントやセルラー基地局間の切り替えにより、ネットワークの接続性が変わりえることに注意すること。

このパターンでは、図4の関連するシナリオと同様に、リモートコントローラーと電子機器は、クライアントとサーバーの役割を持っている。

4.2.4 スマートホームゲートウェイ

図7は、スマートホームゲートウェイを用いたユースケースを示している。このゲートウェイは、ホームネットワークとインターネットの間に位置づけられる。これは、屋内の電子機器を管理し、前述のユースケースのようにスマートフォンからなど、インターネット経由でリモートコントローラーからの命令を受信できるようにする。これは、デバイスの仮想表現でもある。スマートホームゲートウェイは通常、プロキシとファイアウォールの機能を提供する。

このパターンでは、ホームゲートウェイは、クライアントとサーバーの両方の役割を持っている。リモートコントローラーが電子機器を作動させた時に、クライアントの役割の電子機器とサーバーの役割のリモートコントローラーとの接続を可能とする。電子機器がリモートコントローラーにメッセージを送信する際は、ゲートウェイは、電子機器に対するサーバーの役割を果たし、リモートコントローラーに対するクライアントの役割を果たす。

4.2.5 エッジデバイス

エッジデバイスまたはエッジゲートウェイは、スマートホームゲートウェイに類似している。この用語は、エッジゲートウェイによって実行される追加のタスクを示すために用いる。図8のホームゲートウェイは主に公開されているネットワークと信頼できるネットワークの間を橋渡しするだけだが、エッジデバイスにはローカルな計算性能があり、通常は、異なるプロトコル間の橋渡しを行う。エッジデバイスは通常、産業界のソリューションで用いられ、その場合には、接続されたデバイスとセンサーが提供するデータの前処理、フィルタリング、集約を行うことができる。

4.2.6 デジタルツイン

デジタルツインは仮想表現である。つまり、クラウドサーバーやエッジデバイスに存在するデバイスまたはデバイス群のモデルである。これは、継続的にオンライン上に存在するとは限らないデバイスを表すため、または、新しいアプリケーションやサービスを実際のデバイスに展開する前にシミュレーションを実行するために使用される。

デジタルツインは単一のデバイスをモデル化するこもでき、結合されたデバイスの仮想表現に複数のデバイスを集約することもできる。

デジタルツインは、デバイスが既にクラウドに接続されているか、それともクラウドに接続されているゲートウェイに接続されているかに応じて、様々な方法で実現できる。

4.2.6.1 クラウド対応デバイス

図11は、電子機器がクラウドに直接接続されている例を示す。クラウドは機器をミラーリングし、デジタルツインとして機能し、リモートコントローラー (例えば、スマートフォン) から命令を受信する。デジタルツインはグローバルに到達可能であるため、承認されたコントローラーはどこにでも設置できる。

4.2.6.2 旧式デバイス

図12は、旧式の電子機器をクラウドに直接接続できない例を示す。ここでは、接続を中継するためにゲートウェイが必要である。ゲートウェイは次のような機能を果たす。

• 物理的と論理的の両方の観点での様々な旧式の通信プロトコルのインテグレータ
• インターネットに対するファイアウォール
• 実際の画像や音声を置き換え、データをローカルで記録するプライバシーフィルタ
• ネットワーク接続が中断された場合のローカルなエージェント
• 火災警報や同様のイベントが発生したときにローカルで実行される緊急サービス

クラウドは、接続されたすべての機器とゲートウェイをミラーリングし、それらをゲートウェイと連携してクラウド内で管理するデジタルツインとして機能する。さらに、クラウドはどこにでも設置できるリモートコントローラー (例えば、スマートフォン) からの命令を受信することができる。

4.2.7 マルチクラウド

典型的なIoTのデプロイメントは、複数 (数千) のデバイスで構成される。標準的なメカニズムがなければ、特定のクラウドのためのファームウェア更新の管理には、多大な労力が必要であり、IoTの広範な採用の妨げとなる。

デバイスおよびデバイス型を記述するための標準的なメカニズムの主な利点は、デバイスに対してソフトウェアやファームウェアのレベルでカスタマイズを行う必要なく、つまり、クラウド固有のコードをデバイスにインストールする必要なく、デバイスを異なるクラウド環境にデプロイできることである。これは、このソリューションは、複数のIoTクラウド環境のデバイスに対して新規に接続し (on-boarding) 使用することを可能とするような形でデバイスの記述ができるくらいに柔軟なものであることを意味する。

これにより、既存のデバイスをクラウドからクラウドへ移行することが可能になるとともに、既存のデプロイメントにおける新しいデバイスの利用が簡単になるため、Web of Thingsデバイスの採用が促進される。

4.2.8 領域横断型連携

図13は、領域横断型連携の例を示している。この場合、各システムは、スマートファクトリーとスマートシティ、スマートシティとスマートホームのように、他の領域に含まれる他のシステムと関わり合いを持っている。 [IEC-FOTF] で示す通り、この種のシステムは「共生」 (symbiotic) エコシステムと呼ばれる。その中には、直接的連携と間接的連携の二つのモデルがある。直接的連携モデルでは、システムはピアツーピア (peer-to-peer) 方式で互いに情報を直接交換する。間接的連携では、システムは何らかの連携プラットフォームを介して情報を交換する。この連携を維持・継続するために、各システムは自身の能力やインタフェースに関するメタデータを提供し、他のシステムに適応させる。

8.8.1 ネイティブなWoT API

開発者がWoTスクリプティングAPIを用いずに、Servientの実装を選択しうる理由は様々である。メモリやコンピュータ資源が不足しているために、開発者が必要なソフトウェアスタックまたはフル機能のスクリプトエンジンを使用できないことが原因である場合がある。または、開発者が独自のユースケース (例えば、独自の通信プロトコル) をサポートするために、特定のプログラミング環境や言語でしか利用できない特定の機能やライブラリを用いなければならない場合もありえる。

このケースでは、WoTスクリプティングAPIの代わりに別のアプリケーション向けインターフェースを用いて同等の抽象化と機能を公開しつつ、依然としてWoTランタイムを使用できる。後者の場合を除き、§ 8. 抽象的なServientのアーキテクチャのすべての構成要素の説明は図28でも有効である。

8.8.2 既存デバイスのThing Description

既存のIoTデバイスやサービスをW3C Web of Thingsに統合し、これらのデバイスやサービスに関するThing Descriptionを作成することにより、それらをThingとして用いることもできる。このようなTDは、手動でもツールやサービスを用いても作成できる。例えば、TDは、別のエコシステムに依存している機械可読形式で提供されるメタデータの自動翻訳を提供するサービスにより生成できる。しかし、これは、対象とするデバイスがプロトコルバインディングで記述できるプロトコルを用いている場合にのみ行えることである。これに関する要件は§ 6.6 プロトコルバインディングで示される。これまでの議論の多くは、Thingが自身のThing Descriptionを提供することも暗示している。これは便利なパターンだが、必須ではない。特に、既存のデバイスを変更して自身のThing Descriptionを直接提供することはできない場合がある。このケースでは、ディレクトリやその他の外部の別の配信メカニズムなどのサービスを用いてThing Descriptionを別途提供する必要がある。

9.2.1 同じネットワーク上のConsumerとThing

図30で示している最もシンプルな相互接続のトポロジーでは、ConsumerとThingは同じネットワーク上にあり、仲介なしに互いに直接通信を行える。このトポロジーになるユースケースの一つは、Consumerがゲートウェイで実行されているオーケストレーションサービス (orchestration service) やその他のIoTアプリケーションで、Thingがセンサーやアクチュエータに接続しているデバイスである場合である。しかし、クライアント/サーバーの関係は簡単に逆転可能で、クライアントは、ゲートウェイやクラウド上でThingとして実行されているサービスにアクセスするConsumerの役割を持つデバイスになりえる。

Thingがクラウド内にあり、Consumerがローカルネットワーク上にある場合 (スマートホームのユースケースの例については図1を参照) は、実際のネットワークトポロジーはより複雑になる。例えば、NATトラバーサルが必要で、ある種の発見は認められていない場合がある。このようなケースでは、後に論じるより複雑なトポロジーの一つの方が適切である。

9.2.2 Intermediaryを介して接続されたConsumerとThing

Intermediaryは、ネットワーク上でThingとConsumerの両方の役割を担い、WoTランタイム内で公開されたThingと利用されるThingの両方のソフトウェア抽象化をサポートする。Intermediaryは、デバイスとネットワークとの間のプロキシやデジタルツインに使用できる。

9.2.2.1 プロキシとして機能するIntermediary

Intermediaryのシンプルな応用の一つは、Thingに対するプロキシである。Intermediaryがプロキシとして機能する場合、二つの別々のネットワークまたはプロトコルとのインターフェースを持っている。これには、TLSエンドポイントの提供など、付加的なセキュリティのメカニズムの実装が伴う場合がある。一般的に、プロキシによって相互作用が変わることはないため、Intermediaryによって公開されるTDの相互作用は、利用されるTDの相互作用と同じであるが、接続メタデータは変更されている。

このプロキシのパターンを実装するために、Intermediaryは、ThingのTDを取得して利用されるThingを作成する。これにより、同じ相互作用のアフォーダンスを持つソフトウェアの実装としてThingのプロキシオブジェクトが作成される。次に、新しい識別子と、場合によっては新しい通信メタデータ (プロトコルバインディング) および (または) 新しいPublic Security Metadataを備えたプロキシオブジェクトのTDが作成される。最後に、このTDに基づいて公開されたThingが作成され、Intermediaryは、適切な公開メカニズムを介して、他のConsumerやIntermediaryにTDを通知する。

9.2.3 クラウドサービスから制御されるローカルネットワーク内のデバイス

スマートホームのユースケースでは、ホームネットワークに接続されているデバイス (センサーと家電) は監視されることが多く、場合によってはクラウドサービスによる制御も行われている。通常、デバイスが接続されているホームネットワークとクラウドの間にはNATデバイスが存在している。NATデバイスは、IPアドレスを変換するだけでなく、接続を選択的にブロックするファイアウォールのサービスを提供していることが多い。ローカルデバイスとクラウドサービスは、通信がゲートウェイをうまく通過できた場合にのみ相互に通信を行える。

ITU-T勧告Y.4409/Y.2070 [Y.4409-Y.2070] で採用されている典型的な構造を図32で示している。この構造には、ローカルとリモートの両方のIntermediaryがある。ローカルのIntermediaryは、複数のThingの相互作用のアフォーダンスを一つの公開されたThing (の集合) へと集約させ、そのすべてを (すべての相互作用が、共通のベースとなるサーバが持つ一つのURL名前空間にマッピングされていて、一つのポートを用いているHTTPなどの) 共通のプロトコルにマッピングすることができる。これにより、ローカルのIntermediaryがNATデバイスをトラバースできる集約型プロトコルを用いていて、そのサービスをインターネットで公開する (STUN、TURN、DyDNSなどの) 何らかの方法を持っていると仮定すると、NATデバイスの背後にあるすべてのThingにアクセスするためのシンプルな方法がリモートのIntermediaryに提供される。さらに、ローカルのIntermediaryは、Thingのプロキシの機能を果たすことができるため、接続されたThingで、それぞれ (HTTP、MQTT、CoAPなどの) 異なるプロトコルや様々なエコシステムの規定が用いられていたとしても、Thingで用いられている様々なプロトコルをConsumerが意識しなくてもよいように、公開されたThingはそれらを一つのプロトコルに集約することができる。

図32にはリモートのIntermediaryに接続された二つのクライアントがあり、これは、NATの境界の背後にあるサービスを集約しており、付加的なプロトコル変換やセキュリティのサービスを提供できる。特に、ローカルのIntermediaryは容量が限られたネットワーク上にある可能性があり、そのサービスをすべてのユーザが直接利用できるようにすることは現実的ではない。このケースでは、ローカルのIntermediaryへのアクセスはリモートのIntermediaryにのみ提供される。次に、リモートのIntermediaryは、より一般的なアクセス制御メカニズムを実装し、キャッシングやスロットリングを実行して、過剰なトラフィックから消費者を保護することもできる。また、これらの消費者は、(HTTPSなどの) オープンなインターネットに適した一つのプロトコルを用いてIntermediaryと通信すると考えられ、それによってクライアントの開発はよりシンプルになる。

このトポロジーでは、ConsumerとThingの間にNATとファイアウォールの機能があるが、ローカルとリモートのIntermediaryが連携してファイアウォールをトンネリングさせ、すべての通信を通すため、ConsumerとThingはファイアウォールについて何も知っている必要がない。ペアになったIntermediaryは、アクセス制御とトラフィック管理を提供することにより、ホームデバイスの保護も行う。

より困難なケースでは、NATとファイアウォールトラバーサルが示されているとおりに機能しない場合がある。特に、ISPがパブリックにアクセス可能なアドレスをサポートしていなかったり、STUN/TURNおよび (または) DyDNSがサポートされていなかったり利用できない場合がある。このケースでは、Intermediaryは、クライアント/サーバーの役割を逆にして初期接続を設定し (ローカルのIntermediaryが最初にクラウド上のリモートのIntermediaryに接続して)、次に、ペアとなったIntermediaryが (例えば、TLSを用いて接続を保護した安全なWebSocketを用いて) トンネルを確立する。このトンネルは、特注のプロトコルを用いてIntermediaryの間のすべての通信をエンコードするために使うこともできる。このケースでは、通常のブラウザ/ウェブサーバーの相互作用と同様に、ローカルのInermediaryからリモートのIntermediaryへと、標準ポートを用いてHTTPSで初期接続を行うことができる。これにより、ほとんどのホームファイアウォールを通過でき、接続が外向きであるため、ネットワークアドレス変換による問題が発生しない。しかし、特注のトンネリングプロトコルが必要な場合でも、リモートのIntermediaryはこの特注のプロトコルを標準の外部プロトコルに変換することができる。接続されたConsumerとThingは、この変換について知っている必要はない。この例を、ThingとConsumerの両方がNATの境界の両側で接続できるユースケースに拡張することもできる。しかし、そのためには、二つのIntermediaryの間に双方向のトンネルを確立する必要もある。

9.2.4 Thing Directoryを用いた発見

クラウド上のサービスによってローカルデバイス (および場合によってはサービス) を監視または制御できるようになると、その上で様々な付加的なサービスを構築できる。例えば、クラウドアプリケーションは、収集されたデータの分析に基づいてデバイスの動作条件を変更できる。

しかし、リモートのIntermediaryがクライアントアプリケーションにサービスを提供しているクラウドプラットフォームの一部である場合、クライアントは、例えば、接続されているデバイスのディレクトリにアクセスすることにより、デバイス情報を見つけることができる必要がある。下の図では、シンプルにするために、すべてのローカルデバイスがThingとして実装され、すべてのクラウドアプリケーションがConsumerとして実装されていると想定している。Thingとして実装されているローカルデバイスのメタデータをクラウドアプリケーションで利用できるようにするために、そのメタデータをThing Directoryサービスに登録することができる。このメタデータは、具体的には、リモートのIntermediaryによって提供されるPublic Security Metadataと通信メタデータ (プロトコルバインディング) を反映するように変更されたローカルデバイスのTDである。その後で、Thing Directoryに照会することにより、クライアントアプリケーションは、ローカルデバイスと通信するために必要なメタデータを取得し、その機能を実現できるようになる。

上図では示していない、より複雑な状況では、Thingとして機能するクラウドサービスもありえる。この場合も、Thing Directoryに自身を登録することができる。Thing Directoryはウェブサービスであるため、NATやファイアウォールデバイスを介してローカルデバイスから見ることができるべきであり、そのインターフェースを自身のTDにより提供することさえ可能である。そして、Consumerとして動作するローカルデバイスは、Thing Directoryを介してクラウド内のThingを発見し、直接、Thingに接続することができる。あるいは、例えば、プロトコル変換が必要な場合、ローカルにあるIntermediaryを介して、Thingに接続することができる。

9.2.5 複数の領域にまたがるサービス間の接続

それぞれが異なるIoTプラットフォームに基づいている複数のクラウドのエコシステムは、連携してより大きな「システムのシステム」というエコシステムを構築できる。下の図は、前述のクラウドアプリケーションのエコシステムの構造に基づいて、「システムのシステム」を作成するために相互接続された二つのエコシステムを示している。あるエコシステムのクライアント (つまり、下記のConsumer A) が別のエコシステムのサーバー (つまり、下記のThing B) を利用する必要がある場合を考えてみよう。このエコシステムを横断するアプリケーションとデバイスの統合を実現するメカニズムは複数存在する。以下では、これを実現する方法を示すために、二つの方法について、それぞれ図を用いて説明する。

9.2.5.1 Thing Directoryの同期を介した接続

図34では、二つのThing Directoryが情報を同期させており、それによって、Consumer AはThing Directory Aを介してThing Bの情報を取得できる。既に説明したように、リモートのIntermediary BはThing Bの影 (shadow) の実装を維持する。この影のデバイスのTDを取得することにより、Consumer Aは、リモートのIntermediary Bを介してThing Bを使用できる。

翻訳者のメモ

上記説明で用いられている「影 (shadow)」については、「デジタルツイン」とも呼ばれる、デバイスの仮想表現であることを明示的に説明するべき．

9.2.5.2 プロキシの同期を介した接続

図35では、二つのリモートのIntermediaryがデバイス情報を同期させている。Thing Bの影がリモートのIntermediary Bで作成されると同時に、影のTDがリモートのIntermediary Aに同期される。次に、リモートのIntermediary Aは、自分自身の中にThing Bの影を作成し、TDをThing Directory Aに登録する。この方法であれば、Thing Directory間の同期は必要ない。

10.1.1 Thing DescriptionのPrivate Security Dataに関するリスク

TDは、Public Security Metadataのみの利用を目指している。TDの作成者は、TDにPrivate Security DataがTDに含まれないようにしなければならない。Public Security MetadataとPrivate Security Dataは厳密に分離されるべきである。TDにはPublic Security Metadataのみが含まれているべきであり、Consumerが権限を持つ場合にのみ、システムとしてアクセスするために何をする必要があるのかを知らせる。そして、権限付与は別途管理されている非公開情報に基づくべきである。

TDの仕様で定義されているTDセキュリティスキームは、Private Security Dataのエンコーディングを意図的にサポートしていない。しかし、人間が読める記述などのその他のフィールドが誤用されてこの情報のエンコードが行われたり、そのような情報をエンコードする拡張メカニズムにより新しいセキュリティスキームが定義され、展開されるリスクがある。

軽減策:

TDとTDで用いられる拡張機能の作成者は、TDにはPublic Security Metadataのみが保存されるようにしなければならない。

10.1.2 Thing Descriptionの個人識別可能情報に関するリスク

Thing Descriptionには、様々な種類の個人識別可能情報が含まれている可能性がある。明示的ではない場合でも、TDと、それにより特定可能な人物とを関連付けると、その人物に関する情報を推測できるようになる。例えば、携帯デバイスによって公開された、フィンガープリンティング可能なTDとの関連付けによる位置情報の特定は、追跡のリスクになりえる。特定のデバイスのインスタンスを識別できない場合でも、TDで表現されるデバイスの種類が人物に関連付けられていれば、個人情報となる可能性がある。例えば、ユーザに病状があると推測するために、医療機器が利用されるかもしれない。

一般的に、TD内の個人識別可能情報はできる限り制限すべきである。しかし、回避できない場合もありえる。TD中に直接的なPIIと推論可能なPIIの両方が存在している可能性があるということは、TDを別形式のPIIのように扱うべきであることを意味する。それは、安全な方法で保存され送信されるべきであり、承認されたユーザにのみ提供されるべきであり、限られた回数だけキャッシュされるべきであり、リクエストに応じて削除されるべきであり、ユーザの同意を得て提供された目的にのみ用いられるべきであり、そうでない場合は、PIIの使用に関するすべての要件 (法的要件を含む) を満たすべきである。

軽減策:

TDでのPIIの保存はできる限り最小限に抑えるべきである。TDに明示的なPIIがなくても、追跡のリスクや特定のプライバシーリスクが存在する場合がある。このリスクを最小限に抑えるために、一般的にPIIが含まれているかのようにTDを扱い、他のPIIと同じ管理方針に従うべきである。それは、承認された利用者にのみ提供すべきである。特定のユースケースに不要な情報は、できる限りTDで公開すべきではない。例えば、TD内の情報を識別する明示的な型とインスタンスも、ユースケースで必要でない場合には含めるべきではない。ユースケースで必要である場合でも、追跡のリスクを最小限に抑えるために、できる限り、グローバルに一意な識別子ではなく、分散型の限定的な範囲の識別子を用いるべきである。一部のユースケースでは、フィンガープリンティングのリスクを減らすために、人間が読める記述などのその他の形式の情報も削除可能である。

10.1.3 Thing Descriptionのコミュニケーションメタデータに関するリスク

WoTバインディングテンプレートは、そのプラットフォームがWoTでの使用の条件を満たしていると見なされるように、基盤となるIoTプラットフォームで採用されているセキュリティメカニズムを正しくサポートしなければならない。IoTを大規模に展開するために必要なネットワークの相互作用が自動化されているため、オペレーターは、セキュリティ方針に準拠した方法でThingが公開され利用されることを保証する必要がある。

軽減策:

TDの作成者は、できる限り、WoTバインディングテンプレートで提供されている、入念なチェック済みの通信メタデータを用いるべきである。WoTバインディングテンプレートでカバーされていないIoTエコシステム用にTDを生成する場合、IoTプラットフォームのすべてのセキュリティ要件が満たされていることを保証する必要がある。

10.2.1 クロススクリプトのセキュリティとプライバシーに関するリスク

基本的なWoTのセットアップにおいては、WoTランタイム内で実行されるすべてのスクリプトは信頼できると見なしたうえで製造者が配信を行うため、実行する各スクリプトのインスタンス間で厳密な分離を行う必要はない。しかし、デバイスの性能、展開のユースケースシナリオ、リスクレベルによっては、そうすることが望ましい場合がある。例えば、あるスクリプトで機密性の高いプライバシーに関わるPIIデータが扱われていて、十分な監査が行われていれば、同じシステム内の他のスクリプトがランタイム中に侵害された場合にデータが露出するリスクを最小限に抑えるために、そのスクリプトを残りのスクリプトのインスタンスから分離することが望ましいかもしれない。別の例は、一つのWoTデバイス上に異なるテナントが共存している場合である。このケースでは、WoTランタイムのインスタンスでそれぞれ異なるテナントが提供されているため、それらを分離する必要がある。

軽減策:

プライバシーに関わるデータや、その他のクリティカルなセキュリティデータをスクリプトで扱う場合には、WoTランタイムはスクリプトのインスタンスとそのデータを分離すべきである。同様に、WoTランタイムの実装では、あるWoTデバイスに複数のテナントがある場合には、WoTランタイムのインスタンスとそのデータの分離を行うべきである。このような分離は、デバイスで利用できるプラットフォームのセキュリティメカニズムを用いてWoTランタイム内で実行できる。詳細に関しては、WoTセキュリティとプライバシーに関するガイドライン仕様 [WOT-SECURITY] の「WoT Servientシングルテナント」と「WoT Servientマルチテナント」の章を参照のこと。

10.2.2 物理デバイス直接アクセスのセキュリティとプライバシーに関するリスク

直接公開されているネイティブなデバイスのインターフェースをスクリプトで使用できる場合は、スクリプトが侵害されたり誤動作したりすると、基盤となる物理デバイス (および潜在的に周辺環境) が被害を受ける可能性がある。そのようなインターフェースで、入力に対する安全性のチェックが不足していれば、基盤となる物理デバイス (または環境) は安全ではない状態となる可能性がある。

軽減策:

WoTランタイムは、ネイティブなデバイスのインターフェースをスクリプトの開発者に直接公開することを避けるべきである。代わりに、WoTランタイムの実装では、ネイティブなデバイスのインターフェースにアクセスするためのハードウェア抽象化レイヤーを提供すべきである。このようなハードウェア抽象化レイヤーは、デバイス (または環境) を安全でない状態にする可能性のあるコマンドの実行を拒否すべきである。さらに、スクリプトが侵害された場合の物理的なWoTデバイスへの被害を減少させるために、特定のスクリプトに対して公開またはアクセスできるインターフェースの数を、スクリプトの機能に応じて最小限に抑えることが重要である。

10.3.1 プロビジョニングと更新のセキュリティリスク

WoTランタイムの実装で、製造後のプロビジョニングや、WoTランタイム自身、スクリプト、または関連するデータ (セキュリティ証明書を含む) の更新がサポートされている場合、それは主要な攻撃ベクトル (attack vector) になる可能性がある。攻撃者は、更新やプロビジョニングの工程の間に上記の要素を変更しようとしたり、攻撃者のコードとデータのプロビジョニングを直接行ったりすることができる。

軽減策:

製造後のプロビジョニングやスクリプト、WoTランタイム自身、または関連するデータの更新は、安全な方法で行うべきである。安全な更新と製造後のプロビジョニングに関する推奨は、WoTセキュリティとプライバシーに関するガイドライン仕様 [WOT-SECURITY] にある。

10.3.2 セキュリティ証明書保管のセキュリティとプライバシーに関するリスク

通常、WoTランタイムは、ネットワークで動作するために、WoTデバイスにプロビジョニングを行ったセキュリティ証明書を保管する必要がある。攻撃者がこれらの証明書の機密性や完全性を侵害できれば、資産にアクセスできるようになったり、他のWoTモノ、デバイス、またはサービスになりすましたり、DoS (Denial-Of-Service) 攻撃を仕掛けたりすることができる。

軽減策:

WoTランタイムは、プロビジョニング済みのセキュリティ証明書を安全に保管し、完全性と機密性を保証すべきである。一つのWoT対応デバイスに複数のテナントがある場合、WoTランタイムの実装では、各テナントのプロビジョニング済みのセキュリティ証明書の分離を保証すべきである。さらに、プロビジョニング済みのセキュリティ証明書が侵害されるリスクを最小限に抑えるために、WoTランタイムの実装は、プロビジョニング済みのセキュリティ証明書にクエリを実行するスクリプトのAPIを公開すべきではない。そのような証明書 (または、それを利用するけれども公開はしないという、ずっとましな抽象的操作であっても) には、それらを用いるプロトコルバインディングの実装のみがアクセスできるべきである。