JP7014184B2 - 情報処理装置および方法、並びにプログラム - Google Patents

Description

本技術は情報処理装置および方法、並びにプログラムに関し、特に、効率的に十分なセキュリティ保護を行うことができるようにした情報処理装置および方法、並びにプログラムに関する。

近年、例えばIoT（Internet of Things）のように機器同士が直接通信を行う通信システムを利用して、様々なサービスをユーザに提供するための技術が提案されている。

また、例えばネットワークに関する技術として、機器の通信状況に応じて通信トラフィックを最適化するものも提案されている（例えば、特許文献１参照）。

特表２００７－５０２５８４号公報

ところで、通信システムを利用したサービスの提供時には、ユーザに関するデータなど、セキュリティ上の重要度の高いデータもネットワークを介して授受される場合も多い。そのため、ネットワーク上の各機器間で十分なセキュリティ確保を行う必要があるが、機器間で授受されるデータ等によってセキュリティ上の重要度は変化することから、効率的に十分なセキュリティ保護を行うことができるようにする技術が望まれている。

本技術は、このような状況に鑑みてなされたものであり、効率的に十分なセキュリティ保護を行うことができるようにするものである。

本技術の第１の側面の情報処理装置は、自身のセキュリティに関する情報を送信し、前記セキュリティに関する情報の送信に応じて送信されてきた、セキュリティ保護のために実行すべき処理を示す指定情報を受信する通信部と、所定の機器に対してデータを送信するか、または前記機器から送信されたデータを受信する場合に、前記指定情報に基づいてセキュリティ保護のための処理を行う制御部とを備え、前記セキュリティに関する情報には、セキュリティに関する自身と前記機器との間のセグメントの状態を示す情報が含まれている。

前記セキュリティに関する情報には、前記情報処理装置が実行可能な前記セキュリティ保護のための処理を示す情報が含まれているようにすることができる。

前記セキュリティ保護のための処理を暗号化、データ完全性チェック、または認証とすることができる。

前記セキュリティに関する情報には、前記情報処理装置がデータに対して実行可能な処理を示す情報が含まれているようにすることができる。

前記情報処理装置がデータに対して実行可能な処理を、データに対する個人識別情報の付加、またはデータに対する変換処理とすることができる。

前記通信部には、前記セキュリティに関する情報の送信要求を受信した場合、前記送信要求を前記機器に送信させるとともに、前記送信要求に応じて自身の前記セキュリティに関する情報を送信させることができる。

前記通信部には、前記機器から前記送信要求に対する応答がなかった場合、前記セキュリティに関する情報のレポート能力を有していない前記機器が存在する旨の情報を送信させることができる。

前記制御部には、前記レポート能力を有していない前記機器との接続拒否を要求する接続拒否要求が前記通信部により受信されたとき、前記レポート能力を有していない前記機器とのデータの授受を行わないように制御させることができる。

前記通信部には、前記機器から前記送信要求に対する応答がなかった場合、前記機器とのデータの授受により前記機器の前記セキュリティに関する情報が特定されたとき、特定された前記機器の前記セキュリティに関する情報を送信させることができる。

前記セキュリティに関する情報には、前記情報処理装置と前記機器との間のセグメントにおけるデータのトラフィック量に関する情報が含まれているようにすることができる。

前記制御部には、前記情報処理装置と前記機器との間のセグメントについて、互いに異なる複数の装置から前記指定情報を受信した場合、受信された複数の前記指定情報のなかから１つの前記指定情報を選択させ、選択した前記指定情報に基づいて前記セキュリティ保護のための処理を行わせることができる。

前記通信部には、前記指定情報の選択結果を示す情報を前記複数の装置に送信させることができる。

前記通信部には、前記指定情報の選択基準を示す選択基準情報をさらに受信させ、前記制御部は、前記選択基準情報に基づいて前記指定情報を選択させることができる。

本技術の第１の側面の情報処理方法またはプログラムは、自身のセキュリティに関する情報を送信し、前記セキュリティに関する情報の送信に応じて送信されてきた、セキュリティ保護のために実行すべき処理を示す指定情報を受信し、所定の機器に対してデータを送信するか、または前記機器から送信されたデータを受信する場合に、前記指定情報に基づいてセキュリティ保護のための処理を行うステップを含み、前記セキュリティに関する情報には、セキュリティに関する自身と前記機器との間のセグメントの状態を示す情報が含まれている。

本技術の第１の側面においては、自身のセキュリティに関する情報が送信され、前記セキュリティに関する情報の送信に応じて送信されてきた、セキュリティ保護のために実行すべき処理を示す指定情報が受信され、所定の機器に対してデータを送信するか、または前記機器から送信されたデータを受信する場合に、前記指定情報に基づいてセキュリティ保護のための処理が行われる。また、前記セキュリティに関する情報には、セキュリティに関する自身と前記機器との間のセグメントの状態を示す情報が含まれている。

本技術の第２の側面の情報処理装置は、所定の機器のセキュリティに関する情報を受信し、前記機器においてセキュリティ保護のために実行すべき処理を示す指定情報を送信する通信部と、前記セキュリティに関する情報に基づいて前記指定情報を生成する制御部とを備え、前記セキュリティに関する情報には、セキュリティに関する前記機器と他の機器との間のセグメントの状態を示す情報が含まれている。

前記セキュリティに関する情報には、前記機器が実行可能な前記セキュリティ保護のための処理を示す情報が含まれているようにすることができる。

前記セキュリティ保護のための処理を暗号化、データ完全性チェック、または認証とすることができる。

前記セキュリティに関する情報には、前記機器がデータに対して実行可能な処理を示す情報が含まれているようにすることができる。

前記機器がデータに対して実行可能な処理を、データに対する個人識別情報の付加、またはデータに対する変換処理とすることができる。

前記制御部には、前記通信部により前記セキュリティに関する情報のレポート能力を有していない他の機器が存在する旨の情報を前記機器から受信した場合、前記セキュリティに関する情報、および前記レポート能力を有していない前記他の機器が存在する旨の情報に基づいて前記指定情報を生成させることができる。

前記制御部には、前記レポート能力を有していない前記他の機器が存在する旨の情報の受信後、前記機器により特定された前記レポート能力を有していない前記他の機器の前記セキュリティに関する情報が前記通信部により受信された場合、前記レポート能力を有していない前記他の機器の前記セキュリティに関する情報に基づいて、前記レポート能力を有していない前記他の機器に接続された、前記機器とは異なる機器の前記指定情報を生成させることができる。

前記通信部には、前記レポート能力を有していない前記他の機器との接続拒否を要求する接続拒否要求を前記機器に送信させることができる。

前記セキュリティに関する情報には、前記機器と他の機器との間のセグメントにおけるデータのトラフィック量に関する情報が含まれているようにすることができる。

前記通信部には、ローカルネットワークを構成する前記機器に前記指定情報を送信させ、前記ローカルネットワークを含むネットワークのセキュリティ管理を行う装置に対して、前記ローカルネットワークにおけるセキュリティの管理状況を示す情報を送信させることができる。

前記制御部には、前記機器と他の機器との間のセグメントについて、前記セキュリティに関する情報に基づいて前記機器においてセキュリティ保護のために実行すべき処理を決定させ、その決定結果と、前記機器においてセキュリティ保護のために実行すべき処理の前記情報処理装置とは異なる他の情報処理装置による決定結果とに基づいて前記指定情報を生成させることができる。

前記通信部には、前記指定情報の選択基準を示す選択基準情報を前記機器に送信させ、前記機器と他の機器との間のセグメントについて、前記機器において前記情報処理装置を含む複数の装置から受信した複数の前記指定情報のなかから選択された１つの前記指定情報を示す情報を前記機器から受信させることができる。

本技術の第２の側面の情報処理方法またはプログラムは、所定の機器のセキュリティに関する情報を受信し、前記セキュリティに関する情報に基づいて、前記機器においてセキュリティ保護のために実行すべき処理を示す指定情報を生成し、前記指定情報を送信するステップを含み、前記セキュリティに関する情報には、セキュリティに関する前記機器と他の機器との間のセグメントの状態を示す情報が含まれている。

本技術の第２の側面においては、所定の機器のセキュリティに関する情報が受信され、前記セキュリティに関する情報に基づいて、前記機器においてセキュリティ保護のために実行すべき処理を示す指定情報が生成され、前記指定情報が送信される。また、前記セキュリティに関する情報には、セキュリティに関する前記機器と他の機器との間のセグメントの状態を示す情報が含まれている。

本技術の第１の側面および第２の側面によれば、効率的に十分なセキュリティ保護を行うことができる。

なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載された何れかの効果であってもよい。

ヘルスケアIoTシステムの概要について説明する図である。 ヘルスケアIoTのデータ経路について説明する図である。 ヘルスケアIoTのデータ経路について説明する図である。 ヘルスケアIoTのデータ経路について説明する図である。 ヘルスケアIoTのデータ経路について説明する図である。 通信プラットフォームから見たデータの経路について説明する図である。 セキュリティ上の重要度が高いデータ例について説明する図である。 セキュリティ上の重要度が低いデータ例について説明する図である。 セキュリティ上の重要度が変化する例について説明する図である。 セキュリティ手段について説明する図である。 ヘルスケアIoTシステムの構成例を示す図である。 セキュリティ管理について説明する図である。 セキュリティケーパビリティレポートの例を示す図である。 セキュリティポリシーについて説明する図である。 セキュリティ手段の適用例について説明する図である。 IoT機器の構成例を示す図である。 セキュリティマネジメントエンティティの構成例を示す図である。 配布処理および受信処理を説明するフローチャートである。 セグメントセキュリティレポートについて説明する図である。 配布処理および受信処理を説明するフローチャートである。 セキュリティ管理について説明する図である。 セキュリティ管理について説明する図である。 配布処理を説明するフローチャートである。 受信処理を説明するフローチャートである。 配布処理を説明するフローチャートである。 受信処理を説明するフローチャートである。 セキュリティ管理について説明する図である。 配布処理および受信処理を説明するフローチャートである。 ヘルスケアIoTシステムの構成例を示す図である。 セキュリティ管理について説明する図である。 ローカルセキュリティマネジメントエンティティの構成例を示す図である。 ローカルセキュリティポリシー配布処理、受信処理、およびセキュリティポリシー配布処理を説明するフローチャートである。 ヘルスケアIoTシステムの構成例を示す図である。 セキュリティ管理について説明する図である。 配布処理を説明するフローチャートである。 受信処理を説明するフローチャートである。 セキュリティ管理について説明する図である。 配布処理を説明するフローチャートである。 受信処理を説明するフローチャートである。 コンピュータの構成例を示す図である。

以下、図面を参照して、本技術を適用した実施の形態について説明する。

〈第１の実施の形態〉
〈IoTについて〉
本技術の具体的な実施の形態を説明する前に、まずIoTについて説明する。

IoTは物のインターネットであり、人の手を介す通信と異なり、ものとものが直接通信を行う通信システムである。例えばMTC（Machine Type Communication）やM2M（Machine to Machine）もIoTを実現するための通信トポロジを表した言葉であり、これらは機械と機械が通信する通信形態を表している。

IoTの１つの特徴として、通信をするデバイスの数が多いということが挙げられる。１人の人間にかかわる機会が10倍から100倍くらいあると想定すると、通信をする機械（機器）については、人間対人間の通信に使用される電話等よりも10倍から100倍の数の通信機器があらゆる場所に配置される。

通信には、無線通信と有線通信があるが、IoTの場合には無線通信が向いている。それは、機器を配置する場所の制約が少ないからである。

〈ヘルスケアIoTについて〉
ヘルスケアIoTには、以下のような特徴がある。すなわち、ヘルスケアIoTには、プレーヤの多様性、データ経路の多様性、およびデータの種類の多様性がある。

ここで、図１にヘルスケアIoTシステムの概要を示す。

図１に示す例では、ヘルスケアIoTシステムはヘルスケアIoTシステムの利用者であるクライアント１１－１乃至クライアント１１－Ｚ、測定センサ１２、スマートホン１３、環境センサ１４、およびサーバ１５－１乃至サーバ１５－３からなる。

なお、以下、クライアント１１－１乃至クライアント１１－Ｚを特に区別する必要のない場合、単にクライアント１１とも称する。また、以下、サーバ１５－１乃至サーバ１５－３を特に区別する必要のない場合、単にサーバ１５とも称する。

ヘルスケアIoTシステムでは、測定センサ１２乃至サーバ１５がネットワークにより接続されている。

測定センサ１２は、例えばクライアント１１－１の体温を測定する体温計等のセンサなどからなり、スマートホン１３はクライアント１１が所持する端末装置である。また、環境センサ１４は、例えばクライアント１１の周囲の環境を撮影するカメラなどからなる。さらにサーバ１５は、例えば各種のサービスを提供する事業者等により管理されるサーバなどとされる。

なお、図１ではハッチが施された丸印が描かれている機器（デバイス）は、その機器においてデータに対してユーザに関する個人ＩＤ等が付与されるＩＤ付与ポイントであることを示しており、この例ではスマートホン１３およびサーバ１５－１がＩＤ付与ポイントとなっている。また、ハッチが施されていない丸印が描かれている機器は、その機器において生データが解析後のデータ等に変換される変換ポイントであることを示しており、この例ではスマートホン１３およびサーバ１５－１が変換ポイントとなっている。

（１）プレーヤの多様性
ヘルスケアIoTの特徴の１つとしてプレーヤ（Player）の多様性がある。

ヘルスケアIoTのプレーヤとして、例えば多数のクライアント、測定センサ、環境センサ、１次事業者、２次事業者が存在し、さらにサービス事業者、デバイスベンダ、通信サービスオペレータも存在する。したがって、Focus Areaには非常に多くのプレーヤがいるという特徴がある。

以下にヘルスケアIoTのプレーヤを示す。

（クライアント）
ヘルスケアIoTシステムにおいては、クライアントはデータ収集ターゲットである。また、クライアントは、ヘルスケア解析データの使用者である。クライアントは、最も重要なプレーヤである。セキュリティの保護はクライアントのためといっても過言ではない。

（センサ）
クライアントの近傍には、体温計等のクライアントの状態を測定するセンサデバイスが配置されるだろう。さらに、クライアントの近隣ではあるが、クライアントとは離れた場所に設置される環境センサ（例えばカメラによるモニタ）もあるだろう。これらのセンサを提供するデバイスベンダも様々であるだろう。

（スマートホン）
センサは、スマートホンに内蔵される場合もあるが、センサがスマートホンの外に配置される場合もあるだろう。スマートホンは、様々なセンサのゲートウェイ的な役割を持つであろう。

（Mobile Network Operator）
データのアップロードやダウンロードには、MNO（Mobile Network Operator）のサービスが必要となるだろう。現在では、LTE（Long Term Evolution）ネットワークがセルラー網として広く普及している。ヘルスケアIoTシステムは、単一のMNOの網では不十分であり、様々なMNOの網を使用して構築されるだろう。

（サーバ）
ネットワーク側には、データを収集するサーバがあり、それは最初にクライアントからデータを受け取る一次事業者と、そのような一次事業者からデータを譲り受ける二次事業者があるだろう。これらのヘルスケア事業者は、データを管理する事業者やサービスを提供する事業者等、様々な事業者があるだろう。さらに、それらの事業者は世界中に分散して配置されると予想される。

また、事業者主体が異なれば、セキュリティに対する信頼性は異なるだろう。さらにデバイスに関しても、異なるベンダから提供されるこれらのデバイスは、システムとしてセキュリティを保証しないとクライアントの個人情報を保護することはできないだろう。単一事業者が管理したシステムとデバイスを用いて提供するサービスでは、セキュリティ保護は提供しやすい。しかし、ヘルスケアIoTシステムは、様々な事業者、様々なデバイスベンダが提供するデバイス、様々なアプリケーションが同時に動くシステムであり、セキュリティ保護にかかる負担は増大するだろう。

（２）データ経路の多様性
ヘルスケアIoTの他の特徴の１つとしてデータ経路の多様性がある。すなわち、ヘルスケアIoTシステムでは、様々な信号の向き、宛先、経由ポイントが存在する。

ここで、図２乃至図５を参照して、アプリケーションレベルでのデータ経路の例について説明する。なお、図２乃至図５において、図１における場合と対応する部分には同一の符号を付してあり、その説明は適宜省略する。

まず、例えば図２に示すようにクライアント１１が自分の測定データをサーバ１５に送り、サーバ１５では、その測定データに基づく分析結果をクライアント１１にフィードバックするという基本的なデータ経路がある。

また、例えば図３はクライアント１１の周囲のカメラ、録音機等の環境を測定するセンサがクライアント１１の状態や、クライアント１１の周りの騒音状態等、そのクライアント１１に関係する情報を収集して、それをサーバ１５にレポートするモデルを示している。

クライアント１１に関係する環境情報は、クライアント１１を特定するための個人ＩＤとともにレポートされるケースがあるだろう。また、環境情報は後でクライアント１１と関連付けを行うための個人ＩＤとともに送られる場合もあるだろう。さらに最終的にもクライアント１１と関連付けを行わない場合もあるだろう。

図４は、サーバ１５が複数のクライアント１１からの情報を解析して、そのレポートをクライアント１１に返すのではなく、公共機関等にレポートするモデルを示している。複数のクライアント１１の体温を収集して、デパートの空調を調整するようなケースがこのモデルに含まれる。

図５は、サーバ１５－１に蓄えられたクライアントデータが、さらに別の業者に貸し出されるモデルを示している。この例では、サーバ１５－１に供給されたクライアントデータがサーバ１５－１からサーバ１５－２に提供されている。

ある事業者は、複数の事業者からデータを集めて、そのデータを解析した上で公開する場合もあるだろう。次々とデータが別の事業者に貸し出されるような事態は、データが独り歩きを始める危険性があり、セキュリティ上望ましくない。データを取り戻そうとしても容易ではないからである。

図６は、通信プラットフォームから見たデータの経路を表している。

この例では、センサ４１から、端末側通信インターフェース４２およびネットワーク側通信インターフェース４３を介してサーバ４４へとデータが供給される経路がある。また、サーバ４４からネットワーク側通信インターフェース４３および端末側通信インターフェース４２を介してセンサ４１へとデータが供給される経路もある。

この場合、例えば端末側通信インターフェース４２において、データに対して、SIM（Subscriber Identity Module）のＩＤやアプリケーションレベルのＩＤなど、個人を特定可能なＩＤが付与されることもある。

複数のデータの経路について、各経路上で求められるセキュリティ上の重要度や役割は異なると考えられる。センサ４１から送られてきた情報のセキュリティイ上の重要度は低くても、それが個人ＩＤと結びついたデータとなると、セキュリティの重要度が向上するだろう。サーバ４４で個人情報を収集した後に統計情報として情報を作り出した場合には、その統計情報は個人の情報が薄められているので、セキュリティ上の重要度が低下すると考えられる。

（３）データの種類の多様性
さらにヘルスケアIoTの他の特徴の１つとしてデータの種類の多様性がある。

ヘルスケアIoTでは、未加工のデータである生データ、解析後のデータ、クライアントの個人ＩＤが付与されたデータなど様々なデータが存在する。

ヘルスケアIoTではアプリケーションが多岐に渡るため、保護すべきデータの種類も様々である。セキュリティ上の重要度が高いデータもあれば、セキュリティ上の重要度が低いデータもある。

ここで、図７乃至図９を参照して、データのセキュリティ上の重要度について説明する。すなわち、図７にはセキュリティ上の重要度が高いデータの例が示されており、図８にはセキュリティ上の重要度が低いデータの例が示されている。

また、データの重要度は変化するケースがあり、図９にはセキュリティ上の重要度が変化するケースが示されている。すなわち、図９では、ある機器（デバイス）やサーバの処理の前後でデータのセキュリティ上の重要度が変化するケースについて示されている。

まず、図７には、セキュリティ上の重要度が高いデータの例が示されている。

すなわち、図７では、セキュリティ上の重要度が高いデータ（情報）の例として、個人に特化した情報、個人に対する重大な判断に影響を与える情報、および装着された機器の制御に用いられるコントロールデータが示されている。

個人の趣味嗜好、個人の居所等の場所、病気等の身体の状態等に関する個人に特化した情報はプライバシの観点から保護されるべきである。例えば個人の映像を取得したデータはストリーミングであるが強く保護されるべきである。

また、個人に対する重大な判断に影響を与える情報、すなわち、その情報をもとに重大な判断を医師等が行う可能性があるような情報は、データの改ざんにより重大な判断に影響を与えるため強い保護が求められる。

さらに、装着された機器の制御に用いられるコントロールデータ、すなわち、例えば高信頼性が求められる機器の制御に用いられる制御データは、改ざんされることにより重大な事故を招くことがあるので、データの改ざん等の攻撃から保護する必要がある。

次に、図８にはセキュリティ上の重要度が低いデータの例が示されている。

例えば個人IDと関連付けされずに収集されたデータなどの個人が特定できないデータや、1000万人分の統計分析が加えられたデータなどの個人データから加工されて、もはや個人が特定できないデータなどのセキュリティ上の重要度は低いと考えられる。

また、リアルタイムに個人の血圧の情報が漏れると重大なセキュリティ事故になるが、20年前のデータなどの十分に古いデータであれば問題ない場合もある。その他、例えば人の周りの騒音レベルや、温度、湿度などの個人の周囲の環境データのセキュリティの重要度は若干低いと考えられる。

さらに、図９には、データの重要度が変化するケースについて示されている。

ここでは、例えば生データと解析後データ、および個人ＩＤの関連付け前後のデータが例として示されている。

すなわち、例えばセンサによる測定により得られたデータは、解析が行われる前の生データである。生データは所定の機器（デバイス）またはサーバにより解析されて、解析後データに変換されるが、これらの生データと解析後データとではセキュリティ上の重要度が異なる。

同様に、センサによる測定では、測定対象が何者であるかが分からずに測定が行われる場合もある。そのような場合、測定で得られたデータはクライアントを特定する個人ＩＤと関連付けされる前のデータである。その後、所定の機器（デバイス）またはサーバにより、そのような個人ＩＤと関連付けされていないデータが、個人ＩＤと結び付けられるとデータの質、つまりセキュリティ上の重要度が変化する場合がある。

また、様々な統計処理でもデータのセキュリティ上の重要度は変化する。例えば解析も１回目の解析データをもとに、さらに別の上位概念の解析が２回目にされる場合がある。そのような場合、解析を繰り返すことによってセキュリティ上のデータの重要度は変化していく。

さらに、ヘルスケア機器を制御する制御信号は、制御する前まではセキュリティ上の重要度は高い。これは誤った制御を行うと重大事故を招く可能性があるからである。しかし、制御を実施した後は、どのように制御したかという情報に変化するので制御信号のセキュリティ上の重要度は低下すると考えられる。

医師が診断のために用いたデータは、医師が診断を行って、それに基づく指示をクライアントに出した後は、そのセキュリティ上の重要度は若干下がると考えられる。但し履歴としての重要度はある。

〈低コストで実現するセキュリティの重要性〉
IoT機器は非常に数が多い。したがってセキュリティ耐性を向上させるために、そのような膨大な数のIoT機器に対する暗号化鍵を適切に保管および転送することは非常に難易度が高いと考えられる。

例えば、郵送で鍵を届ける方法は、非常に数の多いIoT機器には非現実的な方法となる。IoT機器は、低コストに作られることが求められる。さらに、ヘルスケアIoTでは、高い通信頻度が求められるユースケースが散見されることから、全てのデータに対して強力にセキュリティ保護を行うことは困難な場合がある。

ヘルスケアIoTには、低コスト、すなわち低デバイスコスト、低計算コスト、低トランザクションコスト、低オペレーションコストで実現するセキュリティシステムが求められるであろう。

〈ヘルスケアIoTに求められるセキュリティ〉
例えばセキュリティ技術の技術範囲を考える上で、以下のような方向性が考えられる。

方向性（１）
厳密にデータ保護を行うための強力なセキュリティ技術を提案する

方向性（２）
データの種類が様々あり、それらのデータの種類は変化するというヘルスケアIoTの特徴を捉えてセキュリティを担保する労力を低減した効率的なセキュリティ技術を提案する

方向性（３）
データがユーザの意図に反して拡散していってしまうというヘルスケアIoTの特徴を捉えて効率的なセキュリティ技術を提案する

ここで、少なくとも方向性（１）、つまり強力なセキュリティ技術を提案するという方向性は望ましくないと考えられる。そして、方向性（２）および方向性（３）で技術を創出することが重要であると考えられる。

また、セキュリティを考える時には以下の３つを考えることが重要である。すなわち、セキュリティ耐性を向上させるための手段（処理）として、図１０に示すセキュリティ手段がある。

図１０では、セキュリティ耐性を向上させるためのセキュリティ手段として、つまりセキュリティ保護のための処理としてAuthentication（認証）、Ciphering（暗号）、およびIntegrity Check（データ完全性チェック）が示されている。

認証、つまり認証処理とは、通信相手が信頼できる通信相手であるか否かを判断する機能であり、例えば通信相手のＩＤの正当性を判定することにより認証が行われる。

このような認証はアクセスセキュリティとも呼ばれており、適切ではない相手に重要なデータを送信することを未然に防止するための機能である。

認証は特になりすましに有効であり、この認証機能が最も基本となるセキュリティ手段である。通常、認証は以下の２つのセキュリティ手段を使用する前に実施される。

暗号、つまり暗号化および復号による暗号機能は通信のデータの内容を他人から分からなくするためのものであり、特に盗聴に有効である。

データ完全性チェックは、通信のデータの内容が改ざんされていないことを確認するための機能であり、改ざんに有効である。特に改ざんされると重大な事故につながるデータに対しては、データ完全性チェックが行われるべきである。

以上の認証、暗号、およびデータ完全性チェックという３つのセキュリティ手段には、鍵が必要となる。それらのセキュリティ手段で共通の同じ鍵を使ってもよいが別々の鍵を用意する方が望ましい。例えば認証の鍵から他の２つのセキュリティ手段のための鍵を生成する場合もある。

また、これらのセキュリティ手段を実施するには、通信のコストやデバイスの計算コストが必要となる。そのため、認証、暗号、およびデータ完全性チェックのうち、どのセキュリティ手段を省略して、どのセキュリティ手段を実施すべきかをシステムのなかの各通信経路ごとに変えることが重要になってくる。

〈ヘルスケアIoTシステムの構成例〉
ところで、世界に統一された１つのヘルスケアIoTのシステムができる場合であれば、データが他のデータに変換される等の変換ポイントを定義して、その変換ポイントの場所も明確に把握することができる。例えば、データがスマートホンを経由すると、そのデータに対して個人ＩＤが必ず付与されることが技術標準として定義される場合である。

しかし、ヘルスケアIoTシステムでは様々なプレーヤが存在して、様々な機器を利用してシステムを組み上げるため、事業者が提供するヘルスケアIoTシステムは事業者ごとに異なる。また、単一の事業者が提供するシステム内であっても、アプリケーションごとに個人ＩＤを付与する場所や、生データが解析後データに変換される場所が様々である。

したがって、事業者が変換ポイントの前後で、セキュリティを最適化しようとしても、その変換ポイントの状況を把握することが容易ではなかった。そのため、システムのフレキシビリティを担保しつつ変換ポイントの前後で、効率的なセキュリティ手段を提供することが求められている。

そこで、本技術では各IoT機器間でのセキュリティ手段を決定してセキュリティ管理（セキュリティマネジメント）を行うセキュリティマネジメントエンティティを設け、ネットワーク構成に対して柔軟に適応可能なセキュリティマネジメントシステムを実現できるようにした。

図１１は、本技術を適用したヘルスケアIoTシステムの一実施の形態の構成例を示す図である。

図１１に示す例では、ヘルスケアIoTシステムはヘルスケアIoTシステムの利用者であるクライアント７１－１乃至クライアント７１－Ｚ、IoT機器７２－１乃至IoT機器７２－６、およびセキュリティマネジメントエンティティ７３を有している。

なお、ここでは説明を簡単にするため、クライアント７１－１についてのみIoT機器が図示されている。以下、クライアント７１－１乃至クライアント７１－Ｚを特に区別する必要のない場合、単にクライアント７１とも称することとする。

IoT機器７２－１乃至IoT機器７２－６は、クライアント７１に所定のサービスを提供するための情報処理装置である。

IoT機器７２－１は、例えばクライアント７１の体温を測定する体温計等のセンサなどからなり、体温などのクライアント７１に関する情報（データ）を、クライアント７１から直接測定し、測定により得られた未加工の生データをIoT機器７２－２に供給する。

IoT機器７２－２は、例えばスマートホンからなる。なお、IoT機器７２－２は、スマートホンに限らずタブレット型端末装置やパーソナルコンピュータなどのクライアント７１が所有する端末装置とされてもよい。

例えばIoT機器７２－２は、IoT機器７２－１から供給された生データに対してクライアント７１を識別する個人ＩＤを付与（付加）したり、IoT機器７２－１から供給された生データに対する解析等を行って解析後データ等の他のデータへの変換を行ったりする。さらに、IoT機器７２－２は、IoT機器７２－１から供給された生データや、その生データに対する変換等により得られたデータなどをIoT機器７２－４やIoT機器７２－５に送信したり、IoT機器７２－４やIoT機器７２－５から提供されるサービスに関するデータを受信して表示したりする。

IoT機器７２－３は、例えばクライアント７１の周囲の環境を撮影するカメラなどの環境センサからなり、クライアント７１を撮影するなどして得られた生データをIoT機器７２－４に送信する。

IoT機器７２－４やIoT機器７２－５は、例えばサービスを提供する一次事業者等により管理されるサーバからなる。例えばIoT機器７２－４は、IoT機器７２－２やIoT機器７２－３から供給されたデータに対する解析等を行って解析後データ等の他のデータへの変換を行ったり、変換により得られたデータにクライアント７１の個人ＩＤを付加したりする。また、例えばIoT機器７２－４やIoT機器７２－５は、クライアント７１に関するデータをIoT機器７２－６に送信する。

IoT機器７２－６は、例えばサービスを提供する二次事業者等により管理されるサーバからなり、IoT機器７２－４やIoT機器７２－５から受信したデータを加工したり、加工により得られたデータをIoT機器７２－４やIoT機器７２－５に送信したりする。

なお、以下、IoT機器７２－１乃至IoT機器７２－６を特に区別する必要のない場合、単にIoT機器７２とも称する。

なお、図１１においては、ハッチが施された丸印が描かれているIoT機器７２は、そのIoT機器７２においてデータに対して個人ＩＤ等のＩＤが付与されるＩＤ付与ポイントであることを示している。この例ではIoT機器７２－２とIoT機器７２－４がＩＤ付与ポイントとなっている。

また、ハッチが施されていない丸印が描かれているIoT機器７２は、そのIoT機器７２において生データが他の解析後データ等に変換されるなどのデータ変換（加工）が行われる変換ポイントであることを示している。この例ではIoT機器７２－２とIoT機器７２－４が変換ポイントとなっている。

ＩＤ付与ポイントや変換ポイントは、IoT機器７２に入力されるデータと、IoT機器７２から出力されるデータとでセキュリティ上の重要度が異なるポイント、つまりデータのセキュリティ上の重要度が変化するポイント（位置）である。

セキュリティマネジメントエンティティ７３は、ヘルスケアIoTシステムにおけるセキュリティを管理する情報処理装置である。セキュリティマネジメントエンティティ７３は、各IoT機器７２間でのデータの授受が行われるときに、どのようにしてセキュリティを確保するか、つまりどのようなセキュリティ手段を適用するかを示すセキュリティポリシーを決定し、そのセキュリティポリシーを示すセキュリティポリシーコンフィギュレーションを各IoT機器７２に配布する。

〈セキュリティ管理について〉
ここで、セキュリティマネジメントエンティティ７３によるセキュリティ管理について説明する。

例えば図１２に示すように、セキュリティマネジメントエンティティ７３は、IoT機器７２から直接または他のIoT機器７２を介して、IoT機器７２がセキュリティに関して有する能力であるセキュリティケーパビリティを示すセキュリティケーパビリティレポートを各IoT機器７２から収集する。このセキュリティケーパビリティレポートは、IoT機器７２自身のセキュリティに関する情報である。

具体的には、例えば矢印Ｑ１１に示すように、セキュリティマネジメントエンティティ７３は、セキュリティケーパビリティレポートの送信を要求する送信要求であるセキュリティケーパビリティリクエストをIoT機器７２に送信し、IoT機器７２はそのセキュリティケーパビリティリクエストを受信する。

そして、IoT機器７２は矢印Ｑ１２に示すように、セキュリティケーパビリティリクエストに応じて、自身のセキュリティケーパビリティを示すセキュリティケーパビリティレポートをセキュリティマネジメントエンティティ７３に送信する。

セキュリティマネジメントエンティティ７３は、IoT機器７２から送信されてきたセキュリティケーパビリティレポートを受信すると、矢印Ｑ１３に示すようにセキュリティケーパビリティレポートを受信した旨のAcknowledgeをIoT機器７２に送信する。

ここでセキュリティケーパビリティは、例えば生データを解析後データに変換する能力、つまりデータの変換能力やデータに対して個人ＩＤを付与（付加）する能力、認証等のセキュリティ保護（確保）のための処理の実行能力など、セキュリティに関する能力である。

例えばIoT機器７２は、図１３に示すようにセキュリティケーパビリティを示すCapability IDを含むセキュリティケーパビリティレポートを送信することで、セキュリティマネジメントエンティティ７３に対して自身が有するセキュリティケーパビリティを報告する。

図１３に示す例では、セキュリティケーパビリティレポートには、Capability ID「１」乃至「５」が含まれており、IoT機器７２がそれらのCapability IDにより示されるセキュリティケーパビリティを有していることが分かる。

ここでCapability ID「１」は、認証（認証処理）を行う能力を示しており、Capability ID「２」は暗号化を行う能力を示しており、Capability ID「３」は、データ完全性チェックを行う能力を示している。

これらのCapability ID「１」乃至「３」に示される能力は、IoT機器７２がセキュリティ保護、つまりセキュリティ確保のために実行可能な処理を示している。換言すれば、Capability ID「１」乃至「３」に示される能力は、セキュリティ確保のために実行可能なセキュリティ手段を示している。

また、Capability ID「４」は、個人ＩＤ、すなわちクライアント７１を識別する個人識別情報を付加（付与）する能力を示しており、Capability ID「５」は生データを解析後データに変換する能力、つまりデータ変換処理を行う能力を示している。

これらのCapability ID「４」および「５」に示される能力は、ヘルスケアIoTシステムで取り扱われるクライアント７１に関するデータに対して行われる処理であって、特に処理の前後でデータのセキュリティ上の重要度が変化する処理の実行能力を示している。すなわち、これらのCapability ID「４」や「５」は、IoT機器７２自身がIoT機器７２間で授受されるデータに対して実行可能な処理を示す情報である。

したがって、Capability ID「４」に示される能力を有するIoT機器７２は、ＩＤ付与ポイントとなることが分かり、Capability ID「５」に示される能力を有するIoT機器７２は、変換ポイントとなることが分かる。

このように、セキュリティケーパビリティレポートにより、IoT機器７２が有しているセキュリティ手段だけでなく、セキュリティ上の重要度の変化に関わる処理を行う能力についても報告（レポート）を行うのは、個人ＩＤ付与や解析後データへの変換は、セキュリティポリシー決定に重大な影響を与える情報だからである。

図１２の説明に戻り、セキュリティマネジメントエンティティ７３は、各IoT機器７２からセキュリティケーパビリティレポートを収集して、各IoT機器７２が有するセキュリティケーパビリティを把握するとともに、各IoT機器７２の接続関係、つまりヘルスケアIoTシステムのネットワークトポロジを把握する。

そして、セキュリティマネジメントエンティティ７３は、把握した各IoT機器７２のセキュリティケーパビリティとネットワークトポロジに基づいて、セキュリティポリシーを決定する。

ここで、セキュリティポリシーとは、IoT機器７２間でデータを授受するにあたり、どのようにしてセキュリティを確保するか、つまり授受されるデータに対してどのようなセキュリティ手段を適用し、セキュリティ保護を行うかを示すものである。

ヘルスケアIoTシステムでは、各IoT機器７２について、通信相手となる他のIoT機器７２ごとに、つまりIoT機器７２と他のIoT機器７２との間の通信経路であるセグメントごとに適用すべきセキュリティ手段が決定される。

セキュリティマネジメントエンティティ７３は、このようにして各IoT機器７２のセグメントごとに適用すべきセキュリティ手段、すなわちセキュリティポリシーを決定すると、矢印Ｑ１４に示すように、その決定結果を示すセキュリティポリシーコンフィギュレーションをIoT機器７２に対して送信する。

このセキュリティポリシーコンフィギュレーションは、所定のIoT機器７２が他のIoT機器７２に対してデータを送信するか、または他のIoT機器７２から送信されたデータを受信する場合に、セキュリティ保護のために実行すべき処理を示す情報である。換言すれば、セキュリティポリシーコンフィギュレーションは、他のIoT機器７２とのデータ授受の際に、IoT機器７２が実行すべきセキュリティ保護のための処理を指定する指定情報である。

また、IoT機器７２は、セキュリティマネジメントエンティティ７３からセキュリティポリシーコンフィギュレーションを受信すると、矢印Ｑ１５に示すように、セキュリティポリシーコンフィギュレーションを受信した旨のAcknowledgeをセキュリティマネジメントエンティティ７３に送信する。

セキュリティポリシーコンフィギュレーションには、例えば図１４に示すようにセキュリティポリシーを示すConfiguration IDが含まれている。

この例では、Configuration ID「１」はセキュリティ保護のために暗号化のみを行うことを示しており、Configuration ID「２」はキュリティ保護のために暗号化とデータ完全性チェックを行うことを示している。また、Configuration ID「３」はキュリティ保護のために認証と暗号化を行うことを示しており、Configuration ID「４」はキュリティ保護のために認証と暗号化とデータ完全性チェックを行うことを示している。

セキュリティポリシーの決定（選択）の一例として、例えばCapability ID「５」に示される能力を有さないIoT機器７２については、そのIoT機器７２がデータの送信側となるセグメントもIoT機器７２がデータの受信側となるセグメントもConfiguration ID「１」に示されるセキュリティポリシーに従ったセキュリティ保護が行われるようになされる。

また、例えばCapability ID「１」に示される能力を有さないIoT機器７２については、そのIoT機器７２に関するセグメントに対してConfiguration ID「１」または「２」に示されるセキュリティポリシーが選択される。

さらに、例えばCapability ID「４」に示される能力を有するIoT機器７２については、そのIoT機器７２がデータの送信側となるセグメントではConfiguration ID「４」に示されるセキュリティポリシーが選択され、そのIoT機器７２がデータの受信側となるセグメントではConfiguration ID「１」に示されるセキュリティポリシーが選択される。

セキュリティポリシーは、ヘルスケアIoTシステムごとに適切に定められればよく、どのようにして決定するようにしてもよい。

以上のようにして各IoT機器７２にセキュリティポリシーコンフィギュレーションが配布されると、各IoT機器７２は、セキュリティポリシーコンフィギュレーションにより示されるセキュリティポリシーに従って、他のIoT機器７２とのデータの授受を行う。

これにより、例えば図１５に示すようにセキュリティ手段が適用される。なお、図１５において図１１における場合と対応する部分には同一の符号を付してあり、その説明は適宜省略する。

図１５に示す例では、IoT機器７２同士を結ぶ矢印が通信経路、つまりセグメントを表している。

特に、実線で描かれたセグメントは、そのセグメントの両端にあるIoT機器７２間でセキュリティ手段として暗号化が行われることを示している。また、点線で描かれたセグメントは、そのセグメントの両端にあるIoT機器７２間でセキュリティ手段として認証と暗号化とデータ完全性チェックが行われることを示している。さらに、一点鎖線で描かれたセグメントは、そのセグメントの両端にあるIoT機器７２間でセキュリティ手段として暗号化とデータ完全性チェックが行われることを示している。

したがって、例えばIoT機器７２－２とIoT機器７２－５との間でデータの授受が行われるときには、セキュリティ保護のための処理としてデータに対して暗号化処理が行われる。すなわち、IoT機器７２－２とIoT機器７２－５との間では、暗号化処理が施されたデータが授受される。

また、例えばIoT機器７２－２とIoT機器７２－４との間では、データの授受が行われるときにはセキュリティ保護のための処理として、認証と暗号化とデータ完全性チェックが行われる。

なお、ここではセキュリティマネジメントエンティティ７３とIoT機器７２は異なる情報処理装置である例について説明するが、IoT機器７２がIoT機器としてだけでなく、セキュリティマネジメントエンティティ７３としても機能するようにしてもよい。

〈IoT機器の構成例〉
続いて、図１１に示したIoT機器７２とセキュリティマネジメントエンティティ７３の具体的な構成例について説明する。

まず、IoT機器７２の構成例について説明する。図１６は、IoT機器７２の構成例を示す図である。

図１６に示すIoT機器７２は、通信部１０１、記録部１０２、および制御部１０３を有している。

通信部１０１は、ネットワークを介して他のIoT機器７２やセキュリティマネジメントエンティティ７３と通信し、送信されてきた各種のデータ（情報）を受信して制御部１０３に供給したり、制御部１０３から供給されたデータを送信したりする。記録部１０２は、制御部１０３から供給されたデータを記録したり、記録しているデータを制御部１０３に供給したりする。

制御部１０３は、IoT機器７２全体の動作を制御する。制御部１０３は、データ処理部１１１およびセキュリティ処理部１１２を有している。

データ処理部１１１は、IoT機器７２間で授受されるデータに対して適宜、加工等の処理を施す。例えばデータ処理部１１１は、生データに対して解析処理を行い、生データを解析後データに変換したり、生データや解析後データに対して個人ＩＤを付加したりする。

セキュリティ処理部１１２は、セキュリティマネジメントエンティティ７３から供給されたセキュリティポリシーコンフィギュレーションにより示されるセキュリティポリシーに従ってセキュリティ保護のための処理を行う。例えばセキュリティ保護のための処理として、IoT機器７２間で授受されるデータに対する暗号化処理や、暗号化されたデータの復号処理、データ完全性チェックのための処理、通信相手であるIoT機器７２または自身の認証を行うための認証に関する処理などが行われる。

〈セキュリティマネジメントエンティティの構成例〉
次に、セキュリティマネジメントエンティティ７３の構成例について説明する。図１７は、セキュリティマネジメントエンティティ７３の構成例を示す図である。

図１７に示すセキュリティマネジメントエンティティ７３は、通信部１４１、記録部１４２、および制御部１４３を有している。

通信部１４１は、ネットワークを介してIoT機器７２と通信し、送信されてきた各種のデータ（情報）を受信して制御部１４３に供給したり、制御部１４３から供給されたデータを送信したりする。記録部１４２は、制御部１４３から供給されたデータを記録したり、記録しているデータを制御部１４３に供給したりする。

制御部１４３は、セキュリティマネジメントエンティティ７３全体の動作を制御する。制御部１４３は、セキュリティポリシー決定部１５１を有している。

セキュリティポリシー決定部１５１は、各IoT機器７２から収集されたセキュリティケーパビリティレポートに基づいて、各IoT機器７２に対してセグメントごとにセキュリティポリシーを決定（選択）する。

〈配布処理および受信処理の説明〉
ここで、IoT機器７２とセキュリティマネジメントエンティティ７３との間で行われる処理について説明する。

すなわち、以下、図１８のフローチャートを参照して、セキュリティマネジメントエンティティ７３により行われる配布処理と、IoT機器７２により行われる受信処理について説明する。

ステップＳ１１において、セキュリティマネジメントエンティティ７３の通信部１４１は、セキュリティケーパビリティリクエストを送信する。

すなわち、制御部１４３は、セキュリティケーパビリティリクエストを生成し、通信部１４１に供給する。すると通信部１４１は、制御部１４３から供給されたセキュリティケーパビリティリクエストをIoT機器７２に送信する。なお、セキュリティケーパビリティリクエストは、セキュリティマネジメントエンティティ７３が接続（通信）可能な全てのIoT機器７２に対して送信される。

セキュリティケーパビリティリクエストが送信されると、ステップＳ２１において、IoT機器７２の通信部１０１は、セキュリティマネジメントエンティティ７３から送信されてきたセキュリティケーパビリティリクエストを受信して制御部１０３に供給する。

制御部１０３は、通信部１０１から供給されたセキュリティケーパビリティリクエストに応じて、IoT機器７２が有する能力を示すセキュリティケーパビリティレポートを生成し、通信部１０１に供給する。これにより、例えば図１３に示したセキュリティケーパビリティレポートが生成される。

ステップＳ２２において、通信部１０１は、制御部１０３から供給されたセキュリティケーパビリティレポートをセキュリティマネジメントエンティティ７３に送信する。

すると、ステップＳ１２において、セキュリティマネジメントエンティティ７３の通信部１４１は、IoT機器７２から送信されてきたセキュリティケーパビリティレポートを受信して制御部１４３に供給する。なお、より詳細には、セキュリティケーパビリティレポートが受信されると、図１２を参照して説明したようにAcknowledgeが送信される。

ステップＳ１３において、セキュリティポリシー決定部１５１は、通信部１４１から供給されたセキュリティケーパビリティレポートに基づいて、IoT機器７２に対してセグメントごとにセキュリティポリシーを決定する。

このとき、セキュリティポリシー決定部１５１は、必要に応じて他のIoT機器７２から受信したセキュリティケーパビリティレポートも参照して各IoT機器７２が有するセキュリティケーパビリティやネットワークトポロジを把握し、例えば図１４を参照して説明したようにセキュリティポリシーを決定する。

セキュリティポリシー決定部１５１は、セキュリティポリシーを決定すると、その決定結果に基づいてセキュリティポリシーコンフィギュレーションを生成し、通信部１４１に供給する。

例えばセキュリティポリシー決定部１５１は、決定されたセキュリティポリシーを示す、図１４に示したConfiguration IDが含まれるセキュリティポリシーコンフィギュレーションを、IoT機器７２のセグメントごとに生成する。

ステップＳ１４において、通信部１４１は、セキュリティポリシー決定部１５１から供給されたセキュリティポリシーコンフィギュレーションをIoT機器７２に送信し、配布処理は終了する。

また、ステップＳ２３において、IoT機器７２の通信部１０１は、セキュリティマネジメントエンティティ７３から送信されてきたセキュリティポリシーコンフィギュレーションを受信して制御部１０３に供給する。

また、セキュリティポリシーコンフィギュレーションが受信されると、通信部１０１は制御部１０３の制御に従って、セキュリティポリシーコンフィギュレーションを受信した旨のAcknowledgeをセキュリティマネジメントエンティティ７３に送信する。

ステップＳ２４において、制御部１０３は、ステップＳ２３で受信されたセキュリティポリシーコンフィギュレーションにより示されるセキュリティポリシーに従った動作を行い、受信処理は終了する。

具体的には、例えばデータ処理部１１１は、他のIoT機器７２に対して送信する生データに対してクライアント７１の個人ＩＤを付加したり、生データに対する解析処理を行って、生データを他のIoT機器７２に対して送信する解析後データに変換したりする。

また、例えばセキュリティ処理部１１２はセキュリティポリシーに従って、個人ＩＤが付加された生データや解析後データの送信前に他のIoT機器７２に対して認証に必要なデータの送信を要求し、他のIoT機器７２の認証を行う。その他、例えばセキュリティ処理部１１２は、送信する生データや解析後データに対して暗号化処理を行ったり、送信する生データや解析後データに対してデータ完全性チェックのためのデジタル署名等を施したりする。

そして、通信部１０１は、必要に応じて認証処理が行われた後、セキュリティポリシーに従って暗号化処理やデジタル署名等が施された、個人ＩＤが付加された生データや解析後データを、通信相手である他のIoT機器７２に送信する。

さらに、例えばIoT機器７２がデータの受信側である場合には、セキュリティ処理部１１２は、データの受信前に通信相手である他のIoT機器７２に対して認証に必要なデータを送信し、認証を受ける。また、セキュリティ処理部１１２は、他のIoT機器７２から受信した、暗号化されたデータに対する復号やデータ完全性チェックなどの処理を行う。

なお、他のIoT機器７２へのデータの送信時、または他のIoT機器７２から送信されたデータの受信時に行われる、データのセキュリティ保護のための処理は、認証や暗号化、データ完全性チェックなどに限らず、他のどのような処理が行われてもよい。

以上のようにして、セキュリティマネジメントエンティティ７３は、IoT機器７２からセキュリティケーパビリティレポートを受信してセキュリティポリシーを決定し、その決定結果を示すセキュリティポリシーコンフィギュレーションをIoT機器７２に送信する。

また、IoT機器７２は、セキュリティマネジメントエンティティ７３からの要求に応じてセキュリティケーパビリティレポートを送信するとともに、セキュリティポリシーコンフィギュレーションを受信し、指定されたセキュリティポリシーに従った動作を行う。

このようにすることで、ヘルスケアIoTシステムのネットワーク構成に対して、各IoT機器７２のセグメントごとに柔軟かつ適切にセキュリティポリシーを決定し、十分なセキュリティ保護を行うことができる。すなわち、効率的に十分なセキュリティ耐性を得ることができる。

〈第２の実施の形態〉
〈セキュリティポリシーの決定について〉
ところで、ＩＤ付与ポイントや変換ポイントとなるIoT機器７２の前後の通信経路の状態、つまりIoT機器７２間のセグメントの状態によって、セグメントのセキュリティ耐性は異なる。

すなわち、例えばセグメントでの通信が無線通信であるのか、または有線通信であるのかによってセキュリティ耐性は異なる。

また、無線通信であっても3G networkであるのか、GSM（登録商標）（Global System for Mobile Communications）であるのか、4G networkであるのか、または無線LAN（Local Area Network）であるのかによってもセキュリティ耐性は異なる。さらに、有線通信であってもADSL（Asymmetric Digital Subscriber Line）であるのか、光ファイバ通信であるのか、またそこにIP Secが適用されているかによってもセキュリティ耐性が異なる。

このように各IoT機器７２間のセグメントの状態によって、セグメントごとに許容されるセキュリティは異なる。そこで、セグメントのセキュリティに関する状態に応じてセキュリティポリシーを決定するようにしてもよい。

そのような場合、セキュリティマネジメントエンティティ７３は、IoT機器７２のセグメントごとに、特にＩＤ付与ポイントや変換ポイントの前後のセグメントについて、セグメントのセキュリティの観点から見た危険度に関する報告（レポート）を各IoT機器７２に対して要求する。すなわち、セキュリティポリシーを決定するために用いるセキュリティに関する情報として、セキュリティに関するIoT機器７２間のセグメントの状態であるセグメントセキュリティ状態に関する報告が要求される。

セキュリティマネジメントエンティティ７３からの要求を受けたIoT機器７２は、自身と他のIoT機器７２との間のセグメントごとにセグメントセキュリティ状態を示すセグメントセキュリティレポートを生成し、セキュリティマネジメントエンティティ７３に送信する。

例えばセグメントセキュリティレポートは、図１９に示すようにセグメントのセキュリティに関する構成要素「１」乃至構成要素「４」ごとのフラグを含む情報となっている。

図１９に示す例では、構成要素「１」のフラグは、IoT機器７２から見てセグメントがアップリンク（Up Link）であるか、またはダウンリンク（Down Link）であるかを示している。具体的には、構成要素「１」のフラグの値が「０」であれば、セグメントはアップリンクであることを示しており、構成要素「１」のフラグの値が「１」であれば、セグメントはダウンリンクであることを示している。

また、構成要素「２」のフラグは、セグメントでの通信が有線通信であるか、または無線通信であるかを示している。具体的には、構成要素「２」のフラグの値が「０」であれば有線通信であることを示しており、構成要素「２」のフラグの値が「１」であれば無線通信であることを示している。

構成要素「３」のフラグは、セグメントを介して送受信されるデータが生データであるか、または解析後データであるか、すなわち生データまたは解析後データの何れのデータが伝送されるセグメントであるかを示している。具体的には、構成要素「３」のフラグの値が「０」であれば生データが送受信されるセグメントであることを示しており、構成要素「３」のフラグの値が「１」であれば解析後データが送受信されるセグメントであることを示している。

構成要素「４」のフラグは、セグメントを介して送受信（伝送）されるデータが個人ＩＤの付加されたデータであるか否か、すなわち個人ＩＤが付加されたデータまたは個人ＩＤが付加されていないデータの何れのデータが伝送されるセグメントであるかを示している。具体的には、構成要素「４」のフラグの値が「０」であれば個人ＩＤが付加されていないデータが送受信されるセグメントであることを示しており、構成要素「４」のフラグの値が「１」であれば個人ＩＤが付加されたデータが送受信されるセグメントであることを示している。

セキュリティマネジメントエンティティ７３は、各IoT機器７２のセグメントごとにセグメントセキュリティレポートを受信すると、そのセグメントセキュリティレポートにより示されるセグメントセキュリティ状態に基づいて、セキュリティポリシーを決定する。

具体的には、例えば構成要素「４」のフラグや構成要素「５」のフラグの値が「１」であり、セキュリティ上の重要度が高いデータが送受信されるセグメントに対しては、図１４に示したConfiguration ID「３」や「４」に示されるセキュリティポリシーが選択されるなどとすればよい。

第１の実施の形態ではセキュリティケーパビリティレポートに基づいてセキュリティポリシーが決定されていたのに対して、この例ではセグメントセキュリティレポートに基づいてセキュリティポリシーが決定される。すなわち、この実施の形態では、IoT機器７２に隣接するセグメントにおいて、セキュリティの観点で、どのような状態で通信が行われるかに基づいてセキュリティポリシーが決定される。

〈配布処理および受信処理の説明〉
ここで、セグメントセキュリティレポートに基づいてセキュリティポリシーを決定する場合にIoT機器７２とセキュリティマネジメントエンティティ７３との間で行われる処理について説明する。

すなわち、以下、図２０のフローチャートを参照して、セキュリティマネジメントエンティティ７３により行われる配布処理と、IoT機器７２により行われる受信処理について説明する。

ステップＳ５１において、セキュリティマネジメントエンティティ７３の通信部１４１は、セグメントセキュリティレポートの送信を要求するセグメントセキュリティリクエストを送信する。

すなわち、制御部１４３は、セグメントセキュリティリクエストを生成し、通信部１４１に供給する。すると通信部１４１は、制御部１４３から供給されたセグメントセキュリティリクエストをIoT機器７２に送信する。なお、セグメントセキュリティリクエストは、セキュリティマネジメントエンティティ７３が接続（通信）可能な全てのIoT機器７２に対して送信される。

セグメントセキュリティリクエストが送信されると、ステップＳ６１において、IoT機器７２の通信部１０１は、セキュリティマネジメントエンティティ７３から送信されてきたセグメントセキュリティリクエストを受信して制御部１０３に供給する。

制御部１０３は、通信部１０１から供給されたセグメントセキュリティリクエストに応じて、IoT機器７２に接続されたセグメント、つまりIoT機器７２に隣接するセグメントのセグメントセキュリティ状態を示すセグメントセキュリティレポートを生成し、通信部１０１に供給する。これにより、例えば図１９に示した各構成要素のフラグが含まれるセグメントセキュリティレポートが生成される。

ステップＳ６２において、通信部１０１は、制御部１０３から供給されたセグメントセキュリティレポートをセキュリティマネジメントエンティティ７３に送信する。

すると、ステップＳ５２において、セキュリティマネジメントエンティティ７３の通信部１４１は、IoT機器７２から送信されてきたセグメントセキュリティレポートを受信して制御部１４３に供給する。

ステップＳ５３において、セキュリティポリシー決定部１５１は、通信部１４１から供給されたセグメントセキュリティレポートに基づいて、IoT機器７２に対してセグメントごとにセキュリティポリシーを決定する。

なお、セキュリティポリシーの決定にあたっては、セグメントセキュリティレポートだけでなく、セキュリティケーパビリティレポートも参照するようにしてもよい。この場合、セキュリティマネジメントエンティティ７３は、IoT機器７２からセグメントセキュリティレポートとセキュリティケーパビリティレポートを受信する。

セキュリティポリシー決定部１５１は、セキュリティポリシーを決定すると、その決定結果に基づいてセキュリティポリシーコンフィギュレーションを生成し、通信部１４１に供給する。

そして、その後、ステップＳ５４の処理が行われてセキュリティポリシーコンフィギュレーションが送信され、配布処理は終了するが、ステップＳ５４の処理は図１８のステップＳ１４の処理と同様であるので、その説明は省略する。

また、セキュリティポリシーコンフィギュレーションが送信されると、IoT機器７２ではステップＳ６３およびステップＳ６４の処理が行われて受信処理は終了するが、これらの処理は図１８のステップＳ２３およびステップＳ２４の処理と同様であるので、その説明は省略する。

以上のようにしてセキュリティマネジメントエンティティ７３は、IoT機器７２からセグメントセキュリティレポートを受信してセキュリティポリシーを決定し、その決定結果を示すセキュリティポリシーコンフィギュレーションをIoT機器７２に送信する。

また、IoT機器７２は、セキュリティマネジメントエンティティ７３からの要求に応じてセグメントセキュリティレポートを送信するとともに、セキュリティポリシーコンフィギュレーションを受信し、指定されたセキュリティポリシーに従った動作を行う。

このようにすることで、各IoT機器７２のセグメントごとに、セグメントのセキュリティ状態に応じて柔軟かつ適切にセキュリティポリシーを決定し、十分なセキュリティ保護を行うことができる。すなわち、効率的に十分なセキュリティ耐性を得ることができる。

〈第３の実施の形態〉
〈セキュリティポリシーの決定について〉
以上において説明した実施の形態では、セキュリティマネジメントエンティティ７３は、各IoT機器７２から受信したセキュリティケーパビリティレポートやセグメントセキュリティレポートに基づいて、セキュリティポリシーを決定している。

例えばヘルスケアIoTシステムのなかには、全くセキュリティ手段を有さないデバイスやセンサがIoT機器７２として含まれていることもある。

また、セキュリティマネジメントエンティティ７３がセキュリティケーパビリティレポートやセグメントセキュリティレポートを収集しようとしても、そもそもIoT機器７２がレポート能力を有していない場合もある。つまり、要求された情報を相手に対して送信するという、要求に応答する能力を有していない場合もある。

そのような場合、セキュリティマネジメントエンティティ７３は、どのようにしてヘルスケアIoTシステムを設計すればよいか分からなくなってしまう。すなわち、IoT機器７２のセグメントについて適切なセキュリティポリシーを決定することが困難となる。

そこで、例えばレポート能力を有するIoT機器７２が、そのIoT機器７２に隣接する他のIoT機器７２に対して、セキュリティケーパビリティリクエストやセグメントセキュリティリクエストを送信するようにしてもよい。

この場合、IoT機器７２は、他のIoT機器７２からセキュリティケーパビリティリクエストやセグメントセキュリティリクエストの送信に対する応答がない場合には、他のIoT機器７２にはレポート能力がない旨のレポートをセキュリティマネジメントエンティティ７３に送信する。すなわち、レポート能力のないIoT機器７２が存在する旨のレポート（情報）が送信される。

これにより、セキュリティマネジメントエンティティ７３は、IoT機器７２に対して、レポート能力のない他のIoT機器７２が接続されていることを把握することができるので、セキュリティポリシー決定時に他のIoT機器７２についてのレポートも考慮することができる。

このようにセキュリティマネジメントエンティティ７３がIoT機器７２の補助を受けてセキュリティポリシーを決定する場合、セキュリティマネジメントエンティティ７３とIoT機器７２の間では、例えば図２１に示す通信が行われる。

すなわち、まず矢印Ｑ２１に示すように、セキュリティマネジメントエンティティ７３はセキュリティケーパビリティリクエストをIoT機器７２に送信し、IoT機器７２はそのセキュリティケーパビリティリクエストを受信する。

なお、IoT機器７２に対してセグメントセキュリティリクエストが送信されるようにしてもよいし、セキュリティケーパビリティリクエストとセグメントセキュリティリクエストの両方が送信されるようにしてもよい。

IoT機器７２は、セキュリティケーパビリティリクエストを受信すると、矢印Ｑ２２に示すように、そのセキュリティケーパビリティリクエストを自身に隣接する他のIoT機器７２に送信する。また、IoT機器７２は、セキュリティケーパビリティリクエストに応じて、自身についてのセキュリティケーパビリティレポートをセキュリティマネジメントエンティティ７３に送信する。

その後、IoT機器７２は、隣接する他のIoT機器７２から応答があり、セキュリティケーパビリティレポートが送信されてきたときには、そのセキュリティケーパビリティレポートを受信してセキュリティマネジメントエンティティ７３に送信する。以下、IoT機器７２に隣接する他のIoT機器７２を特に隣接IoT機器とも称することとする。

なお、この場合、隣接IoT機器がIoT機器７２に対して応答するが、セキュリティケーパビリティレポートについては、隣接IoT機器から直接、セキュリティマネジメントエンティティ７３に送信されるようにしてもよい。

一方、セキュリティケーパビリティリクエストの送信に対して、一定期間、隣接IoT機器からの応答がない場合には、IoT機器７２は隣接IoT機器がレポート能力を有していないとする。

そして、IoT機器７２は、矢印Ｑ２３に示すように、IoT機器７２に隣接する機器としてレポート能力を有していない隣接IoT機器が存在する旨のレポート（情報）、換言すれば隣接IoT機器がレポート能力を有していない旨のレポートをセキュリティマネジメントエンティティ７３に送信する。セキュリティマネジメントエンティティ７３は、IoT機器７２から、レポート能力を有していない隣接IoT機器が存在する旨のレポートを受信する。

セキュリティマネジメントエンティティ７３は、IoT機器７２のセキュリティケーパビリティレポートと、レポート能力を有していない隣接IoT機器が存在する旨のレポートとに基づいてセキュリティポリシーを決定し、セキュリティポリシーコンフィギュレーションを生成する。

この場合、例えばIoT機器７２と、レポート能力を有していない隣接IoT機器との間のセグメントについては、特にセキュリティポリシーが決定されず、IoT機器７２と隣接IoT機器との間で予め定められたセキュリティ手段が適用されるようになされる。換言すれば、IoT機器７２と隣接IoT機器との間で予め定められたセキュリティ保護のための処理を行う旨のセキュリティポリシーが決定される。

セキュリティマネジメントエンティティ７３は、矢印Ｑ２４に示すように、生成したセキュリティポリシーコンフィギュレーションをIoT機器７２に対して送信する。

また、IoT機器７２は、セキュリティマネジメントエンティティ７３からセキュリティポリシーコンフィギュレーションを受信すると、矢印Ｑ２５に示すように、セキュリティポリシーコンフィギュレーションを受信した旨のAcknowledgeをセキュリティマネジメントエンティティ７３に送信する。

また、IoT機器７２がセキュリティポリシーコンフィギュレーションを受信して、通常の動作を開始した後に、IoT機器７２が隣接IoT機器とのデータの授受から、隣接IoT機器のセキュリティケーパビリティを知ることができる場合がある。

これは、IoT機器７２が隣接IoT機器とデータの授受を行う際に、適宜、認証や暗号化などのセキュリティ保護のための処理を行うことがあるからである。

すなわち、IoT機器７２と、レポート能力を有さない隣接IoT機器との間では、セキュリティ保護のための処理として、それらの機器間で予め定められた処理が行われる。そのため、IoT機器７２は隣接IoT機器とのデータの授受から、隣接IoT機器が有する少なくとも一部のセキュリティケーパビリティを特定することができる。

これにより、IoT機器７２は隣接IoT機器が有する、例えば図１３を参照して説明したCapability IDにより示されるセキュリティケーパビリティを把握することが可能である。

このように隣接IoT機器がレポート能力を有していないが、IoT機器７２が隣接IoT機器とのデータの授受を開始した後に、隣接IoT機器が有するセキュリティケーパビリティを把握（特定）することができたときには、その隣接IoT機器のセキュリティケーパビリティをセキュリティマネジメントエンティティ７３にレポートするようにしてもよい。

この場合、セキュリティマネジメントエンティティ７３とIoT機器７２の間では、例えば図２２に示す通信が行われる。

なお、図２２において、矢印Ｑ３１乃至矢印Ｑ３５により示される処理は、図２１の矢印Ｑ２１乃至矢印Ｑ２５により示される処理と同様であるため、その説明は省略する。

IoT機器７２は、セキュリティマネジメントエンティティ７３からセキュリティポリシーコンフィギュレーションを受信すると、矢印Ｑ３６に示すように、隣接IoT機器との間でセキュリティポリシーコンフィギュレーションにより示されるセキュリティポリシーに従ってデータの授受を行う。特に、この例では隣接IoT機器はレポート能力を有していないので、IoT機器７２と隣接IoT機器との間で予め定められた処理が、セキュリティポリシーにより示される処理として行われることになる。

そして、このようなデータの授受により、隣接IoT機器が有しているセキュリティケーパビリティの少なくとも一部を、IoT機器７２が特定したとする。この場合、矢印Ｑ３７に示すようにIoT機器７２は、特定されたセキュリティケーパビリティを示す隣接IoT機器のセキュリティケーパビリティレポートをセキュリティマネジメントエンティティ７３に送信する。

セキュリティマネジメントエンティティ７３は、隣接IoT機器のセキュリティケーパビリティレポートに基づいてセキュリティポリシーを決定する。

この場合、例えばセキュリティマネジメントエンティティ７３は、隣接IoT機器に接続された他のIoT機器７２の隣接IoT機器との間のセキュリティポリシーを決定するが、必要に応じてIoT機器７２のセキュリティポリシーも決定し直すようにしてもよい。

セキュリティポリシーが決定されると、セキュリティマネジメントエンティティ７３は、その決定結果に応じてセキュリティポリシーコンフィギュレーションを他のIoT機器７２に送信する。

〈配布処理の説明〉
ここで、図２１や図２２に示した動作が行われる場合にIoT機器７２とセキュリティマネジメントエンティティ７３により行われる処理について説明する。

まず、図２３のフローチャートを参照して、セキュリティマネジメントエンティティ７３により行われる配布処理について説明する。

配布処理が開始されると、ステップＳ９１の処理が行われてセキュリティケーパビリティリクエストが送信されるが、ステップＳ９１の処理は図１８のステップＳ１１の処理と同様であるので、その説明は省略する。但し、この場合、セキュリティケーパビリティリクエストは、さらにIoT機器７２から隣接IoT機器へも送信（転送）される。

すると、IoT機器７２からは、IoT機器７２のセキュリティケーパビリティレポートが送信されてくるので、ステップＳ９２において通信部１４１は、IoT機器７２から送信されてきたセキュリティケーパビリティレポートを受信して制御部１４３に供給する。

より詳細には、ステップＳ９２では、隣接IoT機器がレポート能力を有している場合には、IoT機器７２自身のセキュリティケーパビリティレポートと、隣接IoT機器のセキュリティケーパビリティレポートとがIoT機器７２から送信されてくる。この場合には、通信部１４１は、それらのセキュリティケーパビリティレポートを受信して制御部１４３に供給する。

また、隣接IoT機器がセキュリティケーパビリティのレポート能力を有していない場合には、ステップＳ９２では、IoT機器７２のセキュリティケーパビリティレポートと、隣接IoT機器についてのレポート、すなわちレポート能力を有していない隣接IoT機器が存在する旨のレポートとがIoT機器７２から送信されてくる。この場合には、通信部１４１は、セキュリティケーパビリティレポートと、レポート能力を有していない隣接IoT機器が存在する旨のレポートとを受信して制御部１４３に供給する。

ステップＳ９３において、セキュリティポリシー決定部１５１は、ステップＳ９２で受信されたセキュリティケーパビリティレポートに基づいて、セキュリティポリシーを決定する。この場合、IoT機器７２のセキュリティケーパビリティレポートと、隣接IoT機器のセキュリティケーパビリティレポート、またはレポート能力を有していない隣接IoT機器が存在する旨のレポートとに基づいて、IoT機器７２や隣接IoT機器についてセグメントごとにセキュリティポリシーが決定される。

例えば、隣接IoT機器がレポート能力を有していない場合には、隣接IoT機器とIoT機器７２との間ではセキュリティ保護のための処理として、それらの機器間で予め定められた処理が行われる。

セキュリティポリシーが決定されると、セキュリティポリシー決定部１５１は、その決定結果に応じたセキュリティポリシーコンフィギュレーションを生成し、通信部１４１に供給する。

ステップＳ９４において、通信部１４１は、セキュリティポリシー決定部１５１から供給されたセキュリティポリシーコンフィギュレーションをIoT機器７２に送信する。

また、ステップＳ９２でレポート能力を有していない隣接IoT機器が存在する旨のレポートが受信された場合、IoT機器７２と隣接IoT機器の間でのデータの授受の開始後に、隣接IoT機器のセキュリティケーパビリティレポートがIoT機器７２から送信されてくることがある。これは、上述したようにIoT機器７２により隣接IoT機器のセキュリティケーパビリティが特定されることがあるからである。

ステップＳ９５において、セキュリティポリシー決定部１５１は、IoT機器７２から隣接IoT機器のセキュリティケーパビリティレポートが送信されてきたか否かを判定する。

ステップＳ９５において、送信されてこなかったと判定された場合、ステップＳ９６乃至ステップＳ９８の処理は行われず、配布処理は終了する。

これに対して、ステップＳ９５において送信されてきたと判定された場合、ステップＳ９６において、通信部１４１はIoT機器７２から送信されてきた隣接IoT機器のセキュリティケーパビリティレポートを受信して制御部１４３に供給する。

ステップＳ９７において、セキュリティポリシー決定部１５１は、ステップＳ９６において受信したセキュリティケーパビリティレポートに基づいて、隣接IoT機器に接続された、IoT機器７２とは異なる他のIoT機器７２のセキュリティポリシーを決定する。

このとき、セキュリティポリシー決定部１５１は、他のIoT機器７２から受信したセキュリティケーパビリティレポートがある場合には、そのセキュリティケーパビリティレポートも用いてセキュリティポリシーを決定する。なお、IoT機器７２や隣接IoT機器のセキュリティポリシーが再決定（更新）されるようにしてもよい。

また、セキュリティポリシー決定部１５１は、決定したセキュリティポリシーを示す他のIoT機器７２のセキュリティポリシーコンフィギュレーションを生成し、通信部１４１に供給する。

ステップＳ９８において、通信部１４１は、セキュリティポリシー決定部１５１から供給されたセキュリティポリシーコンフィギュレーションを他のIoT機器７２に送信し、配布処理は終了する。これにより、他のIoT機器７２では、隣接IoT機器のセキュリティケーパビリティが考慮されたセキュリティポリシーに従って、他のIoT機器７２と隣接IoT機器との間のデータ授受を行うことができるようになる。

以上のようにして、セキュリティマネジメントエンティティ７３は、IoT機器７２だけでなく隣接IoT機器についてのレポートも受信してセキュリティポリシーを決定する。このようにすることで、各IoT機器７２のセグメントごとに柔軟かつ適切にセキュリティポリシーを決定し、十分なセキュリティ保護を行うことができる。すなわち、効率的に十分なセキュリティ耐性を得ることができる。

〈受信処理の説明〉
次に、図２３を参照して説明した配布処理が行われるときに、IoT機器７２により行われる受信処理について説明する。すなわち、以下、図２４のフローチャートを参照して、IoT機器７２により行われる受信処理について説明する。

ステップＳ１２１において、通信部１０１は、セキュリティマネジメントエンティティ７３から送信されてきたセキュリティケーパビリティリクエストを受信して制御部１０３に供給する。ここでは、図２３のステップＳ９１の処理により送信されたセキュリティケーパビリティリクエストが受信される。

また、制御部１０３は、受信されたセキュリティケーパビリティリクエストを通信部１０１に供給し、隣接IoT機器への送信を制御する。すなわち、ステップＳ１２２において、通信部１０１は、制御部１０３から供給されたセキュリティケーパビリティリクエストを隣接IoT機器に送信する。

この場合、隣接IoT機器がセキュリティケーパビリティのレポート能力を有しているときには、隣接IoT機器からIoT機器７２に対して、セキュリティケーパビリティリクエストに応じてセキュリティケーパビリティレポートが送信されてくる。これに対して隣接IoT機器がレポート能力を有していない場合には、例えばIoT機器７２に対する応答は特になされない。

ステップＳ１２３において、制御部１０３は、隣接IoT機器からセキュリティケーパビリティレポートが送信されてきたか否かを判定する。

ステップＳ１２３において送信されてきたと判定された場合、ステップＳ１２４において、通信部１０１は隣接IoT機器から送信されてきたセキュリティケーパビリティレポートを受信して制御部１０３に供給する。

また、制御部１０３は、IoT機器７２自身についてのセキュリティケーパビリティレポートを生成する。制御部１０３は、生成されたIoT機器７２自身のセキュリティケーパビリティレポートと、隣接IoT機器から受信した、隣接IoT機器のセキュリティケーパビリティレポートとを通信部１０１に供給する。

ステップＳ１２５において、通信部１０１は、制御部１０３から供給された、IoT機器７２自身のセキュリティケーパビリティレポートと、隣接IoT機器のセキュリティケーパビリティレポートとをセキュリティマネジメントエンティティ７３に送信する。

これにより、図２３のステップＳ９２では、IoT機器７２と隣接IoT機器のセキュリティケーパビリティレポートが受信され、図２３のステップＳ９４の処理により、IoT機器７２と隣接IoT機器のそれぞれについてのセグメントごとのセキュリティポリシーコンフィギュレーションが送信されてくる。

ステップＳ１２６において、通信部１０１は、セキュリティマネジメントエンティティ７３からセキュリティポリシーコンフィギュレーションを受信して制御部１０３に供給する。また制御部１０３は、受信したセキュリティポリシーコンフィギュレーションのうち、隣接IoT機器のものを通信部１０１に供給する。また、より詳細には、セキュリティポリシーコンフィギュレーションが受信されると、図２１や図２２を参照して説明したようにAcknowledgeが送信される。

ステップＳ１２７において、通信部１０１は、制御部１０３から供給された隣接IoT機器のセキュリティポリシーコンフィギュレーションを、隣接IoT機器に送信する。

このようにしてセキュリティポリシーコンフィギュレーションが得られると、その後、処理はステップＳ１３０へと進む。

一方、ステップＳ１２３において、隣接IoT機器からセキュリティケーパビリティレポートが送信されてこなかったと判定された場合、すなわち一定期間、隣接IoT機器から応答がなかった場合、処理はステップＳ１２８へと進む。

この場合、制御部１０３は、レポート能力を有していない隣接IoT機器が存在する旨のレポートを生成して通信部１０１に供給するとともに、セキュリティケーパビリティリクエストに応じて生成されたIoT機器７２のセキュリティケーパビリティレポートを通信部１０１に供給する。

ステップＳ１２８において、通信部１０１は、制御部１０３から供給されたIoT機器７２自身のセキュリティケーパビリティレポートと、レポート能力を有していない隣接IoT機器が存在する旨のレポートをセキュリティマネジメントエンティティ７３に送信する。

これらのレポートは、図２３のステップＳ９２において受信され、図２３のステップＳ９４の処理により、IoT機器７２のセキュリティポリシーコンフィギュレーションが送信されてくる。

ステップＳ１２９において、通信部１０１は、セキュリティマネジメントエンティティ７３から送信されてきた、IoT機器７２のセキュリティポリシーコンフィギュレーションを受信して制御部１０３に供給し、その後、処理はステップＳ１３０に進む。

ステップＳ１２９の処理が行われたか、またはステップＳ１２７の処理が行われると、ステップＳ１３０の処理が行われる。

ステップＳ１３０において、制御部１０３は、ステップＳ１２６またはステップＳ１２９で受信されたIoT機器７２のセキュリティポリシーコンフィギュレーションにより示されるセキュリティポリシーに従った動作を行う。なお、ステップＳ１３０では、図１８のステップＳ２４と同様の処理が行われる。

ステップＳ１３１において、制御部１０３は、隣接IoT機器についてセキュリティケーパビリティのレポートを行うか否かを判定する。

例えば、ステップＳ１３０の処理として、隣接IoT機器とのデータの授受を行うと、隣接IoT機器が有しているセキュリティケーパビリティを把握（特定）できる場合がある。

例えばステップＳ１３１では、ステップＳ１２３で隣接IoT機器のセキュリティケーパビリティレポートが送信されてこなかったと判定され、かつステップＳ１３０の処理によって隣接IoT機器のセキュリティケーパビリティの少なくとも一部が特定された場合、レポートを行うと判定される。

ステップＳ１３１においてレポートを行わないと判定された場合、ステップＳ１３２の処理は行われず、受信処理は終了する。

これに対して、ステップＳ１３１においてレポートを行うと判定された場合、制御部１０３は、特定された隣接IoT機器のセキュリティケーパビリティを示すセキュリティケーパビリティレポートを生成して通信部１０１に供給し、処理はステップＳ１３２に進む。

ステップＳ１３２において、通信部１０１は、制御部１０３から供給された隣接IoT機器のセキュリティケーパビリティレポートを、セキュリティマネジメントエンティティ７３に送信し、受信処理は終了する。この場合、ステップＳ１３２で送信されたセキュリティケーパビリティレポートは、図２３のステップＳ９６において受信される。

以上のようにして、IoT機器７２は、セキュリティマネジメントエンティティ７３からの要求に応じて隣接IoT機器にもセキュリティケーパビリティリクエストを送信し、適宜、隣接IoT機器のセキュリティケーパビリティレポートを送信する。このようにすることで、セキュリティマネジメントエンティティ７３では、各IoT機器７２のセグメントごとに柔軟かつ適切にセキュリティポリシーを決定することができるようになり、十分なセキュリティ保護を行うことができる。すなわち、効率的に十分なセキュリティ耐性を得ることができる。

なお、ここではセキュリティに関する情報として、IoT機器７２とセキュリティマネジメントエンティティ７３との間で、セキュリティケーパビリティレポートを授受する例について説明した。しかし、上述したようにセキュリティに関する情報として、セキュリティケーパビリティレポートとセグメントセキュリティレポートのうちの少なくとも何れか一方が授受されてセキュリティポリシーが決定されるようにしてもよい。

〈第３の実施の形態の変形例１〉
〈配布処理の説明〉
また、セキュリティケーパビリティやセグメントセキュリティ状態のレポート能力を有していないIoT機器７２については、ヘルスケアIoTシステムのネットワークに接続できないようにして、セキュリティ耐性を向上させるようにしてもよい。

以下、そのような場合にセキュリティマネジメントエンティティ７３とIoT機器７２により行われる処理について説明する。

まず、図２５のフローチャートを参照して、セキュリティマネジメントエンティティ７３による配布処理について説明する。なお、ステップＳ１６１乃至ステップＳ１６３の処理は、図２３のステップＳ９１乃至ステップＳ９３の処理と同様であるので、その説明は省略する。なお、ステップＳ１６２では、隣接IoT機器がレポート能力を有しているか否かに応じて、隣接IoT機器についてセキュリティケーパビリティレポートまたはレポート能力を有していない隣接IoT機器が存在する旨のレポートの何れかが受信される。

ステップＳ１６４において、セキュリティポリシー決定部１５１は、レポート能力のない隣接IoT機器があるか否かを判定する。

例えばステップＳ１６４では、ステップＳ１６２においてレポート能力を有していない隣接IoT機器が存在する旨のレポートが受信された場合、レポート能力のない隣接IoT機器があると判定される。

ステップＳ１６４において、レポート能力のない隣接IoT機器があると判定された場合、処理はステップＳ１６５へと進む。

この場合、セキュリティポリシー決定部１５１は、IoT機器７２についてのセキュリティポリシーコンフィギュレーションを生成して通信部１４１に供給するとともに、IoT機器７２に対して隣接IoT機器との接続拒否を要求する接続拒否要求を生成し、通信部１４１に供給する。換言すれば、レポート能力を有していない隣接IoT機器との通信の拒否、つまりデータの授受の拒否を要求する接続拒否要求が生成される。

ステップＳ１６５において、通信部１４１は、セキュリティポリシー決定部１５１から供給されたセキュリティポリシーコンフィギュレーションおよび接続拒否要求をIoT機器７２に送信し、配布処理は終了する。この場合、レポート能力を有している隣接IoT機器との間のセグメントについてのセキュリティポリシーコンフィギュレーションが送信される。

これに対して、ステップＳ１６４においてレポート能力のない隣接IoT機器がないと判定された場合、処理はステップＳ１６６へと進む。

この場合、セキュリティポリシー決定部１５１は、IoT機器７２と隣接IoT機器について、それぞれセキュリティポリシーコンフィギュレーションを生成して通信部１４１に供給する。

ステップＳ１６６において、通信部１４１は、セキュリティポリシー決定部１５１から供給されたセキュリティポリシーコンフィギュレーションをIoT機器７２に送信し、配布処理は終了する。

以上のようにして、セキュリティマネジメントエンティティ７３は、レポート能力のない隣接IoT機器については接続拒否要求を生成し、IoT機器７２に隣接IoT機器との接続の拒否を要求する。これにより、不適切な隣接IoT機器との接続を排除し、セキュリティ耐性を向上させることができる。

〈受信処理の説明〉
また、図２５に示した配布処理が行われると、IoT機器７２では図２６に示す受信処理が行われる。以下、図２６のフローチャートを参照して、IoT機器７２による受信処理について説明する。

なお、ステップＳ１９１乃至ステップＳ１９８の処理は、図２４のステップＳ１２１乃至ステップＳ１２７およびステップＳ１３０の処理と同様であるので、その説明は省略する。ステップＳ１９８の処理が行われると受信処理は終了する。

また、ステップＳ１９３において、隣接IoT機器のセキュリティケーパビリティレポートが送信されてこなかったと判定された場合、つまり隣接IoT機器がレポート能力を有していない場合、処理はステップＳ１９９へと進む。

ステップＳ１９９において、通信部１０１は、IoT機器７２自身のセキュリティケーパビリティレポートと、レポート能力を有していない隣接IoT機器が存在する旨のレポートをセキュリティマネジメントエンティティ７３に送信する。なお、ステップＳ１９９では、図２４のステップＳ１２８と同様の処理が行われる。

セキュリティマネジメントエンティティ７３にIoT機器７２のセキュリティケーパビリティレポートと、レポート能力を有していない隣接IoT機器が存在する旨のレポートが送信されると、図２５のステップＳ１６５の処理が行われる。

これにより、セキュリティマネジメントエンティティ７３からIoT機器７２には、IoT機器７２のセキュリティポリシーコンフィギュレーションと、隣接IoT機器についての接続拒否要求が送信されてくる。

ステップＳ２００において、通信部１０１は、セキュリティマネジメントエンティティ７３から送信されてきたセキュリティポリシーコンフィギュレーションおよび接続拒否要求を受信して、制御部１０３に供給する。

ステップＳ２０１において、制御部１０３は、ステップＳ２００において受信されたセキュリティポリシーコンフィギュレーションおよび接続拒否要求に従った動作を行い、受信処理は終了する。

この場合、例えば制御部１０３は、接続拒否要求に従って、レポート能力を有さない隣接IoT機器との間のデータの授受が行われないように制御する。これに対して、レポート能力を有する隣接IoT機器との間では、セキュリティポリシーコンフィギュレーションにより示されるセキュリティポリシーに従って動作が行われる。

以上のようにしてIoT機器７２は、セキュリティマネジメントエンティティ７３から隣接IoT機器についてのセキュリティポリシーコンフィギュレーションまたは接続拒否要求を受信し、受信したセキュリティポリシーコンフィギュレーションまたは接続拒否要求に従って動作を行う。これにより、不適切な隣接IoT機器との接続を排除し、セキュリティ耐性を向上させることができる。

なお、ここではセキュリティケーパビリティのレポート能力のない隣接IoT機器との接続を行わない場合を例として説明したが、同様にしてセグメントセキュリティ状態のレポート能力のない隣接IoT機器との接続を行わないようにしてもよい。

〈第４の実施の形態〉
〈セキュリティポリシーの決定について〉
また、以上においては、セキュリティマネジメントエンティティ７３においてセキュリティケーパビリティやセグメントセキュリティ状態に基づいて、セキュリティポリシーを決定する例について説明した。

しかし、それらの情報から単純にＩＤ付与ポイントや変換ポイントの前後のセグメント等についてセキュリティポリシーを決定しようとしても、適切なセキュリティポリシーを決定することができないこともある。

例えば生データが解析後データへと変換される変換ポイントの前、つまり変換ポイントとなる、生データを受信するIoT機器７２と、そのIoT機器７２に生データを送信する他のIoT機器７２との間のセグメントでは、生データが頻繁に送信されることが予想される。しかし、このセグメントを介して授受される生データは解析前のデータであるので、生データ自体のセキュリティ上の重要度は低いと判断することができる。

そのため、例えばそのような生データに対してはデータ完全性チェックが省かれたセキュリティポリシーを適用することができた。しかし、生データのトラフィック量（通信量）、つまり送受信される生データのデータ量を考慮すると、データ完全性チェックが省かれたセキュリティポリシーを適用することが最適であるとはいえない。

そこで、セキュリティマネジメントエンティティ７３において、セキュリティに関する情報として得られるセグメントにおけるトラフィック量に関する情報に基づいてセキュリティポリシーを決定することで、より適切なセキュリティポリシーを適用することができるようにしてもよい。

なお、セキュリティポリシーの決定にあたっては、セグメントのトラフィック量だけでなくセキュリティケーパビリティやセグメントセキュリティ状態も考慮することも勿論可能である。すなわち、セキュリティケーパビリティおよびセグメントセキュリティ状態の少なくとも何れか一方と、トラフィック量とに基づいてセキュリティポリシーを決定するようにしてもよい。しかし、ここでは説明を簡単にするためセキュリティケーパビリティとトラフィック量が考慮されるものとして説明を続ける。

そのような場合、セキュリティマネジメントエンティティ７３とIoT機器７２の間では、例えば図２７に示す通信が行われる。

なお、図２７において、矢印Ｑ４１と矢印Ｑ４２により示される処理は、図１２の矢印Ｑ１１および矢印Ｑ１２により示される処理と同様であるため、その説明は省略する。これらの処理では、セキュリティケーパビリティリクエストに応じて、セキュリティケーパビリティレポートが送信される。

また、IoT機器７２は、セキュリティケーパビリティリクエストを受信すると、IoT機器７２自身が接続されるセグメントごとに、そのセグメントを介して他のIoT機器７２との間で授受されるデータのトラフィック量の予測値である予測トラフィック量を示す予測トラフィック量レポートを生成する。

そして、IoT機器７２は、矢印Ｑ４３に示すように、生成した予測トラフィック量レポートをセキュリティマネジメントエンティティ７３に送信する。

ここで、予測トラフィック量は、例えばデータの過去のトラフィック量等に基づいて決定されてもよいし、授受されるデータの種別等に対して予め定められていてもよい。

セキュリティマネジメントエンティティ７３は、IoT機器７２からセキュリティケーパビリティレポートと予測トラフィック量レポートを受信すると、矢印Ｑ４４に示すように、それらのレポートを受信した旨のAcknowledgeをIoT機器７２に送信する。

また、セキュリティマネジメントエンティティ７３は、受信したセキュリティケーパビリティレポートと予測トラフィック量レポートに基づいて、IoT機器７２のセグメントごとにセキュリティポリシーを決定してセキュリティポリシーコンフィギュレーションを生成する。

この場合、例えば予測トラフィック量が多いときには、セキュリティケーパビリティのみを考慮したときに選択（決定）されるセキュリティポリシーよりも、よりセキュリティ耐性（強度）が強いセキュリティポリシーが選択されるようになされる。

さらに、矢印Ｑ４５に示すように、セキュリティマネジメントエンティティ７３は、生成したセキュリティポリシーコンフィギュレーションをIoT機器７２に対して送信する。

IoT機器７２は、セキュリティマネジメントエンティティ７３からセキュリティポリシーコンフィギュレーションを受信すると、矢印Ｑ４６に示すように、セキュリティポリシーコンフィギュレーションを受信した旨のAcknowledgeをセキュリティマネジメントエンティティ７３に送信する。

そして、その後、IoT機器７２は、受信したセキュリティポリシーコンフィギュレーションにより示されるセキュリティポリシーに従って、他のIoT機器７２との間でデータの授受を行う。

その結果、IoT機器７２では、各セグメントについて実際のデータのトラフィック量が分かるので、IoT機器７２は、矢印Ｑ４７に示すように、実際のトラフィック量を示すトラフィック量レポートを生成し、セキュリティマネジメントエンティティ７３に送信する。

すると、セキュリティマネジメントエンティティ７３は、IoT機器７２から新たに受信したトラフィック量レポートと、矢印Ｑ４２に示すタイミングで受信されたセキュリティケーパビリティレポートとに基づいて、セキュリティポリシーを再決定する。すなわち、セキュリティポリシーコンフィギュレーションが更新（アップデート）される。

セキュリティマネジメントエンティティ７３は、矢印Ｑ４８に示すように、更新後のセキュリティポリシーコンフィギュレーションをIoT機器７２に送信する。

また、IoT機器７２は、更新後のセキュリティポリシーコンフィギュレーションを受信すると、矢印Ｑ４９に示すように、セキュリティポリシーコンフィギュレーションを受信した旨のAcknowledgeをセキュリティマネジメントエンティティ７３に送信する。そして、その後、IoT機器７２は更新後のセキュリティポリシーコンフィギュレーションにより示されるセキュリティポリシーに従って、他のIoT機器７２との間でデータの授受を行う。

このように、予測トラフィック量や実際のトラフィック量を用いることで、より適切にセキュリティポリシーを決定することができる。

〈配布処理および受信処理の説明〉
ここで、セキュリティポリシーの決定に予測トラフィック量や実際のトラフィック量を用いる場合におけるIoT機器７２とセキュリティマネジメントエンティティ７３により行われる処理について説明する。

すなわち、以下、図２８のフローチャートを参照して、セキュリティマネジメントエンティティ７３により行われる配布処理と、IoT機器７２により行われる受信処理について説明する。なお、ステップＳ２３１およびステップＳ２５１の処理は、図１８のステップＳ１１およびステップＳ２１の処理と同様であるので、その説明は省略する。

ステップＳ２５１の処理が行われると、IoT機器７２の制御部１０３は、受信されたセキュリティケーパビリティリクエストに応じて、セキュリティケーパビリティレポートおよび予測トラフィック量レポートを生成し、通信部１０１に供給する。

そして、ステップＳ２５２において、通信部１０１は、制御部１０３から供給されたセキュリティケーパビリティレポートおよび予測トラフィック量レポートをセキュリティマネジメントエンティティ７３に送信する。

なお、セキュリティケーパビリティレポートと予測トラフィック量レポートは、同時に送信されてもよいし、別々に送信されてもよい。

ステップＳ２５２の処理が行われると、ステップＳ２３２において、セキュリティマネジメントエンティティ７３の通信部１４１は、IoT機器７２から送信されてきたセキュリティケーパビリティレポートおよび予測トラフィック量レポートを受信して制御部１４３に供給する。また、セキュリティケーパビリティレポートおよび予測トラフィック量レポートが受信されると、図２７を参照して説明したようにAcknowledgeが送信される。

ステップＳ２３３において、セキュリティポリシー決定部１５１は、通信部１４１から供給されたセキュリティケーパビリティレポートおよび予測トラフィック量レポートに基づいて、IoT機器７２のセグメントごとにセキュリティポリシーを決定する。そして、セキュリティポリシー決定部１５１は、決定したセキュリティポリシーを示すセキュリティポリシーコンフィギュレーションを生成し、通信部１４１に供給する。

セキュリティポリシーコンフィギュレーションが生成されると、その後、ステップＳ２３４の処理が行われてセキュリティポリシーコンフィギュレーションが送信される。なお、ステップＳ２３４では、図１８のステップＳ１４と同様の処理が行われる。

また、セキュリティポリシーコンフィギュレーションが送信されると、IoT機器７２ではステップＳ２５３およびステップＳ２５４の処理が行われるが、これらの処理は図１８のステップＳ２３およびステップＳ２４の処理と同様であるので、その説明は省略する。

さらに、セキュリティポリシーに従って他のIoT機器７２との間でデータの授受が行われると、IoT機器７２自身と他のIoT機器７２との間のセグメントにおける実際のトラフィック量が分かる。そこで、制御部１０３は、実際のトラフィック量を示すトラフィック量レポートを生成し、通信部１０１に供給する。

ステップＳ２５５において、通信部１０１は、制御部１０３から供給されたトラフィック量レポートをセキュリティマネジメントエンティティ７３に送信する。

すると、ステップＳ２３５において、セキュリティマネジメントエンティティ７３の通信部１４１は、IoT機器７２から送信されてきたトラフィック量レポートを受信して制御部１４３に供給する。

ステップＳ２３６において、制御部１４３のセキュリティポリシー決定部１５１は、通信部１４１から供給されたトラフィック量レポートと、ステップＳ２３２で受信されたセキュリティケーパビリティレポートとに基づいて、セキュリティポリシーを更新する。

すなわち、セキュリティポリシーの再決定が行われ、これによりステップＳ２３３で決定されたIoT機器７２のセグメントごとのセキュリティポリシーが更新される。

セキュリティポリシー決定部１５１は、更新後のセキュリティポリシーを示すセキュリティポリシーコンフィギュレーションを生成し、通信部１４１に供給する。

ステップＳ２３７において、通信部１４１は、セキュリティポリシー決定部１５１から供給されたセキュリティポリシーコンフィギュレーションをIoT機器７２に送信し、配布処理は終了する。

また、ステップＳ２５６において、IoT機器７２の通信部１０１は、セキュリティマネジメントエンティティ７３から送信されてきたセキュリティポリシーコンフィギュレーションを受信して制御部１０３に供給する。さらに、このとき図２７を参照して説明したようにAcknowledgeが送信される。

そして制御部１０３は、通信部１０１から供給されたセキュリティポリシーコンフィギュレーションを更新後のセキュリティポリシーコンフィギュレーションとして用いる。すなわち、セキュリティ処理部１１２は、他のIoT機器７２とのデータの授受を行うにあたり、更新後のセキュリティポリシーコンフィギュレーションにより示されるセキュリティポリシーに従ってセキュリティ保護のための処理を行う。

このようにしてIoT機器７２側でセキュリティポリシーが更新されると、受信処理は終了する。

以上のようにして、IoT機器７２は、セキュリティマネジメントエンティティ７３に対して予測トラフィック量レポートやトラフィック量レポートを送信する。また、セキュリティマネジメントエンティティ７３は、受信した予測トラフィック量レポートやトラフィック量レポートを考慮してセキュリティポリシーを決定したり更新したりする。

このようにすることで、セグメントのトラフィック量も考慮して、セグメントごとに、より柔軟かつ適切にセキュリティポリシーを決定し、十分なセキュリティ保護を行うことができる。すなわち、効率的に十分なセキュリティ耐性を得ることができる。

〈第５の実施の形態〉
〈セキュリティポリシーの決定について〉
ところで、以上においてはヘルスケアIoTシステム全体に対して、１つのセキュリティマネジメントエンティティ７３が設けられ、そのセキュリティマネジメントエンティティ７３によって各IoT機器７２についてセグメントごとにセキュリティポリシーが決定されていた。すなわち、セキュリティマネジメントエンティティ７３による中央制御に基づいて、セキュリティ管理が行われていた。

しかし、ヘルスケアIoTシステムでは、システムが煩雑に入り組んでいることもあり、セキュリティ管理全てを中央制御により行おうとすると、サポートしきれない部分が生じてしまうユースケースがある。

具体的には、例えばIoT機器７２としてのセンサである温度計と、他のIoT機器７２としてのスマートホンとの間でクライアント７１（ユーザ）の体温の測定結果等のデータのやり取りがあり、スマートホンに温度計からのデータが蓄積されるが、そのデータの送り先が１ヶ月後まで決まらないような場合などである。例えば、このようなユースケースは、とりあえずスマートホンにデータを蓄積しておき、データの解析を依頼する業者を後で選択するなどというときに生じ得るが、このような場合、温度計とスマートホンとの間のセキュリティを管理する中央制御型のセキュリティマネジメントエンティティが存在しない。

そこで、ローカルなセキュリティマネジメントエンティティを定め、そのローカルなセキュリティマネジメントエンティティにより、ヘルスケアIoTシステムの一部のIoT機器７２間のセキュリティ管理を行うようにすることができる。これにより、より効率的に十分なセキュリティ保護を行うことができる。

この場合、例えばIoT機器７２のなかに、セキュリティのシステムマネジメント用のソフトウェアをインストールできるIoT機器７２があれば、そのIoT機器７２にソフトウェアをインストールしておく。これにより、IoT機器７２は、ローカルなセキュリティマネジメントエンティティ（以下、ローカルセキュリティマネジメントエンティティとも称する）として機能することができるようになる。

セキュリティのシステムマネジメント用のソフトウェアがインストールされたIoT機器７２は、互いに近隣にある他のIoT機器７２と通信して交渉を行い、どのIoT機器７２をローカルセキュリティマネジメントエンティティとして機能させるかを決定する。

そして、ローカルセキュリティマネジメントエンティティとなるIoT機器７２は、ローカルなネットワーク内の各IoT機器７２について、セグメント（通信経路）の状態、ＩＤ付与ポイントや変換ポイントの有無、ネットワークトポロジを把握したうえで、ローカルなネットワーク中でのセキュリティポリシーを決定する。

さらに、ローカルセキュリティマネジメントエンティティは、各IoT機器７２に決定したセキュリティポリシー（以下、特にローカルセキュリティポリシーとも称する）を配布し、各IoT機器７２はローカルセキュリティポリシーに従って動作する。なお、より詳細には、各IoT機器７２には、ローカルセキュリティポリシーを示すローカルセキュリティポリシーコンフィギュレーションが配布される。

その後、例えば１ヶ月後にローカルなネットワーク内のIoT機器７２が、ローカルなネットワーク外のIoT機器７２にデータを送信するなどのタイミングで、ローカルセキュリティマネジメントエンティティが中央のセキュリティマネジメントエンティティ７３に接続するとする。

この場合、ローカルセキュリティマネジメントエンティティは、セキュリティマネジメントエンティティ７３に対して、ローカルなネットワークにおいて、どのようなローカルセキュリティポリシーを配布および運用して、データを取得していたかをレポートする。セキュリティマネジメントエンティティ７３は、ローカルセキュリティマネジメントエンティティからのレポートに基づいて、ローカルなネットワーク内のIoT機器７２と、ローカルなネットワーク外のIoT機器７２との間でデータを授受する際のセキュリティポリシーを決定する。

このような場合、ヘルスケアIoTシステムは、例えば図２９に示すように構成される。なお、図２９において図１１における場合と対応する部分には同一の符号を付してあり、その説明は適宜省略する。

図２９に示すヘルスケアIoTシステムは、クライアント７１、IoT機器７２、セキュリティマネジメントエンティティ７３、およびローカルセキュリティマネジメントエンティティ１８１を有している。すなわち、図２９に示すヘルスケアIoTシステムは、図１１に示したヘルスケアIoTシステムに対して、新たにローカルセキュリティマネジメントエンティティ１８１が加えられている。

この例では、例えばIoT機器７２－１乃至IoT機器７２－３、およびローカルセキュリティマネジメントエンティティ１８１によりローカルなネットワークが構成されている。

ローカルセキュリティマネジメントエンティティ１８１は、IoT機器７２としても機能し、自身を含むローカルなネットワーク内のIoT機器７２についてローカルセキュリティポリシーを決定し、ローカルなネットワークのキュリティ管理を行う。

以下では、ローカルセキュリティマネジメントエンティティ１８１が属すローカルなネットワークをローカルネットワークとも称し、そのローカルネットワークに属すIoT機器７２をローカルIoT機器７２とも称することとする。

また、セキュリティマネジメントエンティティ７３は、ローカルセキュリティマネジメントエンティティ１８１等により構成されるローカルネットワークを含む、より大きいネットワークのセキュリティ管理を行う。

さらに、ローカルセキュリティマネジメントエンティティ１８１は、所定のタイミングでセキュリティマネジメントエンティティ７３に対して、ローカルセキュリティポリシーの配布や運用状況等をローカルセキュリティマネジメントレポートとして送信する。このローカルセキュリティマネジメントレポートは、ローカルネットワークにおけるセキュリティの管理状況を示す情報である。

このような場合、例えば図３０に示すように、ローカルセキュリティマネジメントエンティティ１８１は、図１２を参照して説明したセキュリティマネジメントエンティティ７３における場合と同様にしてローカルセキュリティポリシーを配布する。

すなわち、ローカルセキュリティマネジメントエンティティ１８１は、矢印Ｑ６１に示すようにセキュリティケーパビリティリクエストをローカルIoT機器７２に送信する。

そして、ローカルIoT機器７２は、セキュリティケーパビリティリクエストを受信すると、それに応じて、矢印Ｑ６２に示すようにセキュリティケーパビリティレポートをローカルセキュリティマネジメントエンティティ１８１に送信する。

また、ローカルセキュリティマネジメントエンティティ１８１は、セキュリティケーパビリティレポートを受信すると、矢印Ｑ６３に示すようにセキュリティケーパビリティレポートを受信した旨のAcknowledgeをローカルIoT機器７２に送信する。

その後、ローカルセキュリティマネジメントエンティティ１８１は、セキュリティケーパビリティレポートに基づいてローカルセキュリティポリシーを決定し、矢印Ｑ６４に示すように、その決定結果を示すローカルセキュリティポリシーコンフィギュレーションを送信する。

また、ローカルIoT機器７２は、矢印Ｑ６５を示すようにローカルセキュリティポリシーコンフィギュレーションを受信した旨のAcknowledgeをローカルセキュリティマネジメントエンティティ１８１に送信する。

そして、ローカルIoT機器７２とローカルセキュリティマネジメントエンティティ１８１は、矢印Ｑ６６に示すようにローカルセキュリティポリシーに従ってデータの授受を行う。また、ローカルIoT機器７２と他のローカルIoT機器７２もローカルセキュリティポリシーに従ってデータの授受を行う。

このようなデータの授受を行いながら、例えばローカルセキュリティマネジメントエンティティ１８１が、ローカルIoT機器７２から受信したデータに対する解析等を適宜行い、その結果得られたデータ（以下、蓄積データとも称する）を蓄積するものとする。

そして、例えば１ヶ月後などのタイミングで、ローカルセキュリティマネジメントエンティティ１８１は、矢印Ｑ６７に示すように、ローカルセキュリティマネジメントレポートをセキュリティマネジメントエンティティ７３に送信する。

また、ローカルセキュリティマネジメントエンティティ１８１は、セキュリティマネジメントエンティティ７３により決定されたセキュリティポリシーに従って、蓄積データをローカルネットワーク外のIoT機器７２に送信する。

〈ローカルセキュリティマネジメントエンティティの構成例〉
次に、図２９に示したローカルセキュリティマネジメントエンティティ１８１の構成例について説明する。

例えばローカルセキュリティマネジメントエンティティ１８１は、図３１に示すように構成される。

ローカルセキュリティマネジメントエンティティ１８１は、通信部２１１、記録部２１２、および制御部２１３を有している。

通信部２１１は、ネットワークを介してIoT機器７２やセキュリティマネジメントエンティティ７３と通信し、送信されてきた各種のデータ（情報）を受信して制御部２１３に供給したり、制御部２１３から供給されたデータを送信したりする。記録部２１２は、制御部２１３から供給されたデータを記録したり、記録しているデータを制御部２１３に供給したりする。

制御部２１３は、ローカルセキュリティマネジメントエンティティ１８１全体の動作を制御する。制御部２１３は、セキュリティポリシー決定部２２１、データ処理部２２２、およびセキュリティ処理部２２３を有している。

セキュリティポリシー決定部２２１は、自身を含むローカルネットワーク内のローカルIoT機器７２について、セグメントごとにローカルセキュリティポリシーを決定する。また、データ処理部２２２およびセキュリティ処理部２２３は、IoT機器７２のデータ処理部１１１およびセキュリティ処理部１１２に対応し、それらのデータ処理部１１１およびセキュリティ処理部１１２と同様の動作を行う。

〈ヘルスケアIoTシステムの動作の説明〉
続いて、ローカルセキュリティマネジメントエンティティ１８１、ローカルIoT機器７２、およびセキュリティマネジメントエンティティ７３の動作について説明する。

すなわち、以下、図３２のフローチャートを参照して、ローカルセキュリティマネジメントエンティティ１８１によるローカルセキュリティポリシー配布処理、ローカルIoT機器７２による受信処理、およびセキュリティマネジメントエンティティ７３によるセキュリティポリシー配布処理について説明する。

ローカルセキュリティポリシー配布処理が開始されると、ローカルセキュリティマネジメントエンティティ１８１によりステップＳ２８１乃至ステップＳ２８３の処理が行われるとともに、ローカルIoT機器７２によりステップＳ３０１およびステップＳ３０２の処理が行われる。

なお、ステップＳ２８１乃至ステップＳ２８３の処理は、図１８のステップＳ１１乃至ステップＳ１３の処理と同様であり、ステップＳ３０１およびステップＳ３０２の処理は図１８のステップＳ２１およびステップＳ２２の処理と同様であるので、その説明は、適宜、省略する。

ここでは、ステップＳ２８１では通信部２１１によりセキュリティケーパビリティリクエストがローカルIoT機器７２に送信され、これに応じて送信されてきたセキュリティケーパビリティレポートがステップＳ２８２で通信部２１１により受信される。

そして、ステップＳ２８３では、受信されたローカルIoT機器７２のセキュリティケーパビリティレポートに基づいてセキュリティポリシー決定部２２１によりローカルセキュリティポリシーが決定される。セキュリティポリシー決定部２２１は、決定したローカルセキュリティポリシーを示すローカルセキュリティポリシーコンフィギュレーションを生成し、通信部２１１に供給する。

ステップＳ２８４において、通信部２１１は、セキュリティポリシー決定部２２１から供給されたローカルセキュリティポリシーコンフィギュレーションをローカルIoT機器７２に送信する。

すると、ステップＳ３０３において、ローカルIoT機器７２の通信部１０１は、ローカルセキュリティマネジメントエンティティ１８１から送信されてきたローカルセキュリティポリシーコンフィギュレーションを受信して制御部１０３に供給する。

そして、ステップＳ３０４において、制御部１０３は、ステップＳ３０３で受信されたローカルセキュリティポリシーコンフィギュレーションにより示されるローカルセキュリティポリシーに従った動作を行い、受信処理は終了する。なお、ステップＳ３０４では、図１８のステップＳ２４と同様の処理が行われ、ローカルセキュリティマネジメントエンティティ１８１や他のローカルIoT機器７２との間でデータの授受が行われる。

また、ローカルセキュリティマネジメントエンティティ１８１では、ステップＳ２８５において、制御部２１３は、ステップＳ２８３で決定されたローカルセキュリティポリシーに従った動作を行う。ステップＳ２８５では、例えばステップＳ３０４と同様の処理が行われ、ローカルIoT機器７２との間でデータの授受が行われる。

なお、ここではステップＳ２８５の処理の結果として蓄積データが得られるとし、その蓄積データは、所定のタイミングでローカルネットワーク外のIoT機器７２（以下、外部IoT機器７２とも称することとする）に送信されるものとする。

さらに、例えば所定期間後に蓄積データを外部IoT機器７２に送信するなど、ローカルネットワーク内のローカルセキュリティマネジメントエンティティ１８１やローカルIoT機器７２が、ローカルネットワーク外のIoT機器７２との間でデータの授受を行うタイミングとなったとする。

この場合、制御部２１３は、ステップＳ２８３で決定された各ローカルIoT機器７２やローカルセキュリティマネジメントエンティティ１８１のローカルセキュリティポリシー等に基づいて、ローカルセキュリティマネジメントレポートを生成し、通信部２１１に供給する。

ステップＳ２８６において、通信部２１１は、制御部２１３から供給されたローカルセキュリティマネジメントレポートをセキュリティマネジメントエンティティ７３に送信する。

すると、ステップＳ３２１において、セキュリティマネジメントエンティティ７３の通信部１４１は、ローカルセキュリティマネジメントエンティティ１８１から送信されてきたローカルセキュリティマネジメントレポートを受信して制御部１４３に供給する。

ステップＳ３２２において、制御部１４３は、ローカルネットワーク外の外部IoT機器７２からセキュリティケーパビリティレポートを取得する。すなわち、ステップＳ３２２では図１８のステップＳ１１およびステップＳ１２の処理と同様の処理が行われてセキュリティケーパビリティレポートが取得される。このとき、必要に応じてローカルネットワーク内のローカルセキュリティマネジメントエンティティ１８１やローカルIoT機器７２からもセキュリティケーパビリティレポートが取得されるようにしてもよい。

ステップＳ３２３において、セキュリティポリシー決定部１５１は、ステップＳ３２１で受信されたローカルセキュリティマネジメントレポートと、ステップＳ３２２で取得されたセキュリティケーパビリティレポートとに基づいて、セキュリティポリシーを決定する。ここでは、例えば外部IoT機器７２やローカルセキュリティマネジメントエンティティ１８１のセグメントごとにセキュリティポリシーが決定される。

そして、セキュリティポリシー決定部１５１は、決定されたセキュリティポリシーを示すセキュリティポリシーコンフィギュレーションを生成し、通信部１４１に供給する。

ステップＳ３２４において、通信部１４１は、セキュリティポリシー決定部１５１から供給されたセキュリティポリシーコンフィギュレーションをローカルセキュリティマネジメントエンティティ１８１に送信し、セキュリティポリシー配布処理は終了する。なお、ステップＳ３２４では、外部IoT機器７２等にもセキュリティポリシーコンフィギュレーションが送信される。

ステップＳ２８７において、ローカルセキュリティマネジメントエンティティ１８１の通信部２１１は、セキュリティマネジメントエンティティ７３から送信されてきたセキュリティポリシーコンフィギュレーションを受信して制御部２１３に供給する。

そして、ステップＳ２８８において、制御部２１３は、通信部２１１から供給されたセキュリティポリシーコンフィギュレーションにより示されるセキュリティポリシーに従った動作を行い、ローカルセキュリティポリシー配布処理は終了する。例えばステップＳ２８８では、ローカルセキュリティマネジメントエンティティ１８１と外部IoT機器７２との間で、セキュリティポリシーに従って蓄積データの授受が行われる。

以上のようにしてローカルIoT機器７２とローカルセキュリティマネジメントエンティティ１８１は、ローカルセキュリティポリシーに従って動作し、その後、ローカルセキュリティマネジメントエンティティ１８１は、ローカルセキュリティマネジメントレポートをセキュリティマネジメントエンティティ７３に送信する。

このようにすることで、必要に応じてローカルネットワーク単位でもセキュリティ管理を行い、より柔軟かつ適切に十分なセキュリティ保護を行うことができる。すなわち、効率的に十分なセキュリティ耐性を得ることができる。

〈第６の実施の形態〉
〈セキュリティポリシーの決定について〉
なお、第１の実施の形態乃至第４の実施の形態においては、セキュリティマネジメントエンティティ７３による中央制御型のセキュリティ管理を行う場合に、サービスを提供するヘルスケアサービス事業者が１事業者であることが想定されていた。

しかし、例えばIoT機器７２としての１つの温度センサで得られたデータが、複数のヘルスケアサービス事業者に同時に提供されるべきデータであるときには、中央制御型のセキュリティマネジメントを行うセキュリティマネジメントエンティティが複数存在することもある。

ところが、そのような場合、温度センサに複数のセキュリティマネジメントエンティティのそれぞれからセキュリティポリシーコンフィギュレーションが供給されたときには、温度センサは、どのセキュリティポリシーに従って動作すればよいのかが分からなくなる。

例えば、単純に全く別のシステムが複数存在すると仮定して、温度センサがセキュリティマネジメントエンティティごとのセキュリティポリシーに従ってデータを送信すると、全く同じデータがセキュリティマネジメントエンティティの数の分だけ送信されることになる。そうすると、セキュリティの観点からは、データの送信回数が増える分だけ漏洩や改ざんの機会が増えることになり、セキュリティ耐性が低下してしまう。

そこで、複数のセキュリティマネジメントエンティティ同士がコーディネーションを行ったうえで、統一的なセキュリティポリシーを決定することで重複するデータの送信を防止し、漏洩や改ざんの機会を低減させるようにしてもよい。

そのような場合、ヘルスケアIoTシステムは、例えば図３３に示すように構成される。なお、図３３において図１１における場合と対応する部分には同一の符号を付してあり、その説明は適宜省略する。

図３３に示すヘルスケアIoTシステムは、クライアント７１、IoT機器７２、セキュリティマネジメントエンティティ７３、およびセキュリティマネジメントエンティティ２５１を有している。すなわち、図３３に示すヘルスケアIoTシステムは、図１１に示したヘルスケアIoTシステムに対して、新たにセキュリティマネジメントエンティティ２５１が加えられた構成となっている。

ここでは、セキュリティマネジメントエンティティ２５１は、セキュリティマネジメントエンティティ７３を管理するヘルスケアサービス事業者とは異なるヘルスケアサービス事業者により管理されるものとなっている。

このセキュリティマネジメントエンティティ２５１は、セキュリティマネジメントエンティティ７３と同様の処理を行う。

また、IoT機器７２のなかには、セキュリティマネジメントエンティティ２５１により管理されるネットワークに属すだけでなく、セキュリティマネジメントエンティティ７３により管理されるネットワークにも属すものもあるとする。

以下では、例えばIoT機器７２－２からIoT機器７２－４へと送信されるデータが、セキュリティマネジメントエンティティ２５１を管理するヘルスケアサービス事業者により提供されるサービスだけでなく、セキュリティマネジメントエンティティ７３を管理するヘルスケアサービス事業者により提供されるサービスにも用いられるものとする。

換言すれば、IoT機器７２－２とIoT機器７２－４との間のセグメントは、セキュリティマネジメントエンティティ２５１により管理されるネットワークと、セキュリティマネジメントエンティティ７３により管理されるネットワークとの共通するセグメント部分となる。以下では、このような複数のネットワークの共通するセグメントを共通セグメントとも称することとする。また、この例におけるIoT機器７２－２とIoT機器７２－４のように共通セグメントに接続されている、つまり共通セグメントの端に位置するIoT機器７２を、共通IoT機器７２とも称することとする。この例では共通IoT機器７２は、セキュリティマネジメントエンティティ２５１にもセキュリティマネジメントエンティティ７３にも管理されることになる。

このような場合、例えば図３４に示すようにして、共通セグメントのセキュリティポリシーが決定される。

すなわち、まず矢印Ｑ７１に示すようにセキュリティマネジメントエンティティ７３から共通IoT機器７２に対してセキュリティケーパビリティリクエストが送信され、これに応じて、矢印Ｑ７２に示すように共通IoT機器７２からセキュリティマネジメントエンティティ７３にセキュリティケーパビリティレポートが送信される。

そして、セキュリティマネジメントエンティティ７３は、受信したセキュリティケーパビリティレポートに基づいて、共通IoT機器７２の各セグメントについてセキュリティポリシーを決定する。なお、ここでは共通IoT機器７２はIoT機器７２－２であるものとし、IoT機器７２－２が接続されるセグメントはIoT機器７２－４との間の共通セグメントのみであるとする。

また、セキュリティマネジメントエンティティ２５１もセキュリティマネジメントエンティティ７３と同様にして、共通IoT機器７２の共通セグメントのセキュリティポリシーを決定する。

すなわち、セキュリティマネジメントエンティティ２５１は、矢印Ｑ７３に示すように共通IoT機器７２にセキュリティケーパビリティリクエストを送信し、矢印Ｑ７４に示すように共通IoT機器７２からセキュリティケーパビリティレポートを受信する。そして、セキュリティマネジメントエンティティ２５１は、受信したセキュリティケーパビリティレポートに基づいて、共通IoT機器７２の共通セグメントのセキュリティポリシーを決定する。

その後、矢印Ｑ７５に示すように、セキュリティマネジメントエンティティ７３とセキュリティマネジメントエンティティ２５１とが互いに通信してコーディネーションを行い、共通IoT機器７２の共通セグメントについて最終的な、つまり統一的な１つのセキュリティポリシーを決定する。

具体的には、例えばセキュリティマネジメントエンティティ７３で決定されたセキュリティポリシーと、セキュリティマネジメントエンティティ２５１で決定されたセキュリティポリシーとのうち、よりセキュリティ耐性が強い方が最終的なセキュリティポリシーとして選択される。

その他、例えばセキュリティマネジメントエンティティ７３で決定されたセキュリティポリシーにより示されるセキュリティ保護のための処理と、セキュリティマネジメントエンティティ２５１で決定されたセキュリティポリシーにより示されるセキュリティ保護のための処理とが全て行われるセキュリティポリシーが最終的なセキュリティポリシーとされてもよい。

このようにして決定された最終的なセキュリティポリシーは、セキュリティマネジメントエンティティ７３によるセキュリティ管理と、セキュリティマネジメントエンティティ２５１によるセキュリティ管理で共通して用いられる。以下では、このようなコーディネーションにより決定された最終的なセキュリティポリシーを共通セキュリティポリシーとも称することとする。

共通セキュリティポリシーが決定されると、セキュリティマネジメントエンティティ７３は、矢印Ｑ７６に示すように、セキュリティケーパビリティレポートを受信した旨のAcknowledgeを共通IoT機器７２に対して送信する。

その後、セキュリティマネジメントエンティティ７３は、矢印Ｑ７７に示すように、共通セキュリティポリシーを示すセキュリティポリシーコンフィギュレーションを共通IoT機器７２に送信する。また、これに応じて矢印Ｑ７８に示すように共通IoT機器７２からセキュリティマネジメントエンティティ７３へとセキュリティポリシーコンフィギュレーションを受信した旨のAcknowledgeが送信される。

そして、共通IoT機器７２は、矢印Ｑ７９に示すように、セキュリティマネジメントエンティティ７３から受信したセキュリティポリシーコンフィギュレーションにより示される共通セキュリティポリシーに従って、他の共通IoT機器７２とデータの授受を行う。この場合、例えばIoT機器７２－２とIoT機器７２－４との間でデータの授受が行われる。

このように共通のセキュリティポリシーを用いることで、IoT機器７２－２とIoT機器７２－４との間でのデータの授受を削減することができる。すなわち、複数のセキュリティポリシーごとに、それらのセキュリティポリシーに従ってデータを授受する必要がなくなり、１つの共通セキュリティポリシーに従って、１度のデータ授受を行うだけでよい。

なお、ここではセキュリティポリシーを決定するのにセキュリティケーパビリティが用いられる例について説明するが、その他、セグメントセキュリティ状態やトラフィック量などが用いられるようにしてもよいし、それらを組み合わせて用いるようにしてもよい。

〈配布処理の説明〉
ここで、セキュリティマネジメントエンティティ７３がコーディネーションを行って共通セキュリティポリシーを決定する場合にセキュリティマネジメントエンティティ７３と共通IoT機器７２により行われる処理について説明する。

まず、図３５のフローチャートを参照して、セキュリティマネジメントエンティティ７３による配布処理について説明する。なお、ステップＳ３５１乃至ステップＳ３５３の処理は、図１８のステップＳ１１乃至ステップＳ１３の処理と同様であるので、その説明は省略する。ステップＳ３５３が行われると、共通IoT機器７２の共通セグメントについて、セキュリティポリシーが決定される。

ステップＳ３５４において、通信部１４１は、セキュリティマネジメントエンティティ２５１から送信されてくるセキュリティポリシーに関する情報を受信して、制御部１４３に供給する。

ここでは、例えばセキュリティポリシーに関する情報として、セキュリティマネジメントエンティティ２５１で決定された共通IoT機器７２の共通セグメントについてのセキュリティポリシーを示す情報が受信される。なお、ステップＳ３５４において、コーディネーションのため、セキュリティマネジメントエンティティ７３で決定された共通IoT機器７２の共通セグメントのセキュリティポリシーに関する情報がセキュリティマネジメントエンティティ２５１に送信されてもよい。

ステップＳ３５５において、セキュリティポリシー決定部１５１は、ステップＳ３５３で決定されたセキュリティポリシーと、ステップＳ３５４で受信されたセキュリティポリシーに関する情報とに基づいて、共通セキュリティポリシーを決定する。すなわち、互いに異なる装置で得られたセキュリティポリシーの決定結果に基づいて、共通セキュリティポリシーが決定される。

セキュリティマネジメントエンティティ７３とセキュリティマネジメントエンティティ２５１との間では、ステップＳ３５４およびステップＳ３５５の処理がコーディネーションとして行われる。より詳細には、共通セキュリティポリシーが決定されると、例えば図３４の矢印Ｑ７６に示したようにAcknowledgeが送信される。

また、セキュリティポリシー決定部１５１は、決定された共通セキュリティポリシーを示すセキュリティポリシーコンフィギュレーションを生成し、通信部１４１に供給する。

ステップＳ３５６において、通信部１４１は、セキュリティポリシー決定部１５１から供給されたセキュリティポリシーコンフィギュレーションを共通IoT機器７２に送信し、配布処理は終了する。

以上のようにしてセキュリティマネジメントエンティティ７３は、セキュリティマネジメントエンティティ２５１との間でコーディネーションを行い、共通セキュリティポリシーを決定する。これにより、同じデータが重複して授受されることを防止することができるようになり、効率的に十分なセキュリティ耐性を得ることができる。

〈受信処理の説明〉
次に、図３５を参照して説明した配布処理が行われるときに共通IoT機器７２により行われる処理について説明する。すなわち、以下、図３６のフローチャートを参照して、共通IoT機器７２による受信処理について説明する。

受信処理が開始されると、ステップＳ３８１およびステップＳ３８２の処理が行われてセキュリティケーパビリティリクエストの受信、およびセキュリティケーパビリティレポートの送信が行われる。

なお、これらのステップＳ３８１およびステップＳ３８２の処理は、図１８のステップＳ２１およびステップＳ２２の処理と同様であるので、その説明は省略する。

但し、この例では、セキュリティマネジメントエンティティ７３と、セキュリティマネジメントエンティティ２５１のそれぞれについて、ステップＳ３８１およびステップＳ３８２の処理が行われる。例えばセキュリティマネジメントエンティティ７３については、図３５のステップＳ３５１の処理に応じてステップＳ３８１の処理が行われ、ステップＳ３８２の処理に応じて、図３５のステップＳ３５２の処理が行われる。

ステップＳ３８３において、通信部１０１は、図３５のステップＳ３５６の処理によりセキュリティマネジメントエンティティ７３から送信されてきた共通セキュリティポリシーを示すセキュリティポリシーコンフィギュレーションを受信し、制御部１０３に供給する。

セキュリティポリシーコンフィギュレーションが受信されると、その後、ステップＳ３８４の処理が行われて受信処理は終了するが、ステップＳ３８４の処理は図１８のステップＳ２４の処理と同様であるので、その説明は省略する。

例えばステップＳ３８４では、共通IoT機器７２と他の共通IoT機器７２との間で、共通セグメントを介して、複数の異なるサービスで共通して用いられるデータが、共通セキュリティポリシーに従った動作により授受される。

以上のようにして、共通IoT機器７２は共通セキュリティポリシーを示すセキュリティポリシーコンフィギュレーションを受信し、共通セキュリティポリシーに従った動作を行う。これにより、同じデータが重複して授受されることを防止し、効率的に十分なセキュリティ耐性を得ることができる。

〈第６の実施の形態の変形例１〉
〈セキュリティポリシーの決定について〉
なお、第６の実施の形態では、セキュリティマネジメントエンティティ７３と、セキュリティマネジメントエンティティ２５１との間でコーディネーションを行って共通セキュリティポリシーを決定する例について説明した。しかし、これに限らず、共通IoT機器７２側で共通セキュリティポリシーを決定するようにしてもよい。

そのような場合、共通IoT機器７２は、セキュリティマネジメントエンティティ７３やセキュリティマネジメントエンティティ２５１から、それぞれセキュリティポリシーコンフィギュレーションを受信し、それらのセキュリティポリシーコンフィギュレーションにより示されるセキュリティポリシーのなかの１つを共通セキュリティポリシーとする。

具体的には、例えば図３７の矢印Ｑ９１に示すように、セキュリティマネジメントエンティティ７３は、共通IoT機器７２に対してセキュリティポリシーの選択基準を示す選択基準情報を送信する。

ここで、選択基準情報は、複数のセキュリティポリシーのなかから、どのセキュリティポリシーを共通セキュリティポリシーとして選択するかを示す情報である。具体的には、例えば選択基準情報は、図１４を参照して説明した各Configuration IDにより示されるセキュリティポリシーの優先度を示す情報、つまり各Configuration IDにより示されるセキュリティポリシーの優先度の一覧情報などとされる。

この場合、例えば、よりセキュリティ耐性が強いセキュリティポリシーほど優先度が高くなるようになされており、複数のセキュリティポリシーのうち、最も優先度の高いものが共通セキュリティポリシーとして選択される。

このような選択基準情報は、全ての共通IoT機器７２に対して配布される。なお、選択基準情報は共通IoT機器７２に予め記録されているようにしてもよい。

選択基準情報が配布されると、その後、矢印Ｑ９２に示すようにセキュリティマネジメントエンティティ７３から共通IoT機器７２に対してセキュリティケーパビリティリクエストが送信され、これに応じて、矢印Ｑ９３に示すように共通IoT機器７２からセキュリティマネジメントエンティティ７３にセキュリティケーパビリティレポートが送信される。

そして、矢印Ｑ９４に示すようにセキュリティケーパビリティレポートを受信した旨のAcknowledgeがセキュリティマネジメントエンティティ７３から共通IoT機器７２に送信される。

その後、セキュリティマネジメントエンティティ７３は、矢印Ｑ９５に示すように共通IoT機器７２にセキュリティポリシーコンフィギュレーションを送信し、これに応じて矢印Ｑ９６に示すように共通IoT機器７２からAcknowledgeを受信する。

また、セキュリティマネジメントエンティティ２５１もセキュリティマネジメントエンティティ７３と同様にして、セキュリティポリシーコンフィギュレーションを送信する。

すなわち、セキュリティマネジメントエンティティ２５１は、矢印Ｑ９７に示すように共通IoT機器７２にセキュリティケーパビリティリクエストを送信し、矢印Ｑ９８に示すように共通IoT機器７２からセキュリティケーパビリティレポートを受信する。

そして、セキュリティマネジメントエンティティ２５１は、矢印Ｑ９９に示すように共通IoT機器７２にAcknowledgeを送信し、矢印Ｑ１００に示すように共通IoT機器７２にセキュリティポリシーコンフィギュレーションを送信する。さらにセキュリティマネジメントエンティティ２５１は、矢印Ｑ１０１に示すように共通IoT機器７２からAcknowledgeを受信する。

これにより、共通IoT機器７２は、１つの共通セグメントについて、セキュリティマネジメントエンティティ７３と、セキュリティマネジメントエンティティ２５１という互いに異なる複数の装置から、それぞれセキュリティポリシーコンフィギュレーションを受信したことになる。

共通IoT機器７２は、選択基準情報に基づいて、これらのセキュリティポリシーコンフィギュレーションにより示されるセキュリティポリシーの何れか一方を共通セキュリティポリシーとして選択する。

そして、共通IoT機器７２は、矢印Ｑ１０２に示すように共通セキュリティポリシーの選択結果をセキュリティマネジメントエンティティ７３にレポートするとともに、矢印Ｑ１０３に示すように共通セキュリティポリシーの選択結果をセキュリティマネジメントエンティティ２５１にもレポートする。これにより、セキュリティマネジメントエンティティ７３やセキュリティマネジメントエンティティ２５１は、どのセキュリティポリシーが共通セキュリティポリシーとされたかを把握することができる。

共通IoT機器７２は、このようにして選択された共通セキュリティポリシーに従って、他の共通IoT機器７２との間でデータの授受を行う。

なお、ここでは共通IoT機器７２が選択基準情報に基づいて、複数のセキュリティポリシーのなかの１つを共通セキュリティポリシーとして選択する例について説明した。しかし、複数のセキュリティポリシーのそれぞれにより示されるセキュリティ保護のための処理全てが行われるセキュリティポリシーが共通セキュリティポリシーとされるなど、共通IoT機器７２が選択基準情報に基づいて共通セキュリティポリシーを決定してもよい。

また、この実施の形態においてもセキュリティケーパビリティレポートに限らず、セグメントセキュリティ状態やトラフィック量も考慮されてセキュリティポリシーが決定されるようにしてもよい。

〈配布処理の説明〉
ここで、共通IoT機器７２が共通セキュリティポリシーを決定（選択）する場合に、セキュリティマネジメントエンティティ７３と共通IoT機器７２により行われる処理について説明する。

まず、図３８のフローチャートを参照して、セキュリティマネジメントエンティティ７３による配布処理について説明する。

ステップＳ４１１において、通信部１４１は、選択基準情報を共通IoT機器７２に送信する。

すなわち、例えば制御部１４３は、記録部１４２から予め用意された選択基準情報を読み出して通信部１４１に供給する。そして、通信部１４１は、制御部１４３から供給された選択基準情報を共通IoT機器７２に送信する。

ステップＳ４１１の処理が行われると、その後、ステップＳ４１２乃至ステップＳ４１５の処理が行われて、セキュリティポリシーコンフィギュレーションが共通IoT機器７２に送信される。なお、これらのステップＳ４１２乃至ステップＳ４１５の処理は、図１８のステップＳ１１乃至ステップＳ１４の処理と同様であるので、その説明は省略する。

共通IoT機器７２にセキュリティポリシーコンフィギュレーションが送信されると、その後、共通IoT機器７２からセキュリティマネジメントエンティティ７３には、共通セキュリティポリシーの選択結果を示す選択結果情報が送信されてくる。

ステップＳ４１６において、通信部１４１は、共通IoT機器７２から送信されてきた共通セキュリティポリシーの選択結果情報を受信して制御部１４３に供給し、配布処理は終了する。これにより、制御部１４３は、共通セグメントについて、どのセキュリティポリシーが共通セキュリティポリシーとして選択されたかを把握することができる。

以上のようにしてセキュリティマネジメントエンティティ７３は、選択基準情報とセキュリティポリシーコンフィギュレーションを共通IoT機器７２に送信する。これにより、共通IoT機器７２において、適切な共通セキュリティポリシーを選択することができ、効率的に十分なセキュリティ耐性を得ることができる。

〈受信処理の説明〉
次に、図３８を参照して説明した配布処理が行われるときに共通IoT機器７２により行われる処理について説明する。すなわち、以下、図３９のフローチャートを参照して、共通IoT機器７２による受信処理について説明する。

ステップＳ４４１において、通信部１０１は、セキュリティマネジメントエンティティ７３から送信されてきた選択基準情報を受信して制御部１０３に供給する。

選択基準情報が受信されると、その後、ステップＳ４４２乃至ステップＳ４４４の処理が行われて、セキュリティポリシーコンフィギュレーションが受信される。

なお、これらのステップＳ４４２乃至ステップＳ４４４の処理は、図１８のステップＳ２１乃至ステップＳ２３の処理と同様であるのでその説明は省略する。

但し、この例では、セキュリティマネジメントエンティティ７３と、セキュリティマネジメントエンティティ２５１のそれぞれについて、ステップＳ４４２乃至ステップＳ４４４の処理が行われる。例えばセキュリティマネジメントエンティティ７３については、図３８のステップＳ４１２の処理に応じてステップＳ４４２の処理が行われ、ステップＳ４４３の処理に応じて、図３８のステップＳ４１３の処理が行われる。また、例えば図３８のステップＳ４１５の処理に応じてステップＳ４４４の処理が行われる。

ステップＳ４４５において、制御部１０３は、ステップＳ４４１で受信した選択基準情報に基づいて、ステップＳ４４４の処理で受信した複数のセキュリティポリシーコンフィギュレーションのそれぞれにより示されるセキュリティポリシーのなかから、１つのセキュリティポリシーを選択し、共通セキュリティポリシーとする。

また、制御部１０３は、共通セキュリティポリシーの選択結果を示す選択結果情報を生成し、通信部１０１に供給する。

ステップＳ４４６において、通信部１０１は、制御部１０３から供給された選択結果情報をセキュリティマネジメントエンティティ７３およびセキュリティマネジメントエンティティ２５１に送信する。これにより、例えば図３８のステップＳ４１６の処理が行われることになる。

ステップＳ４４７において、制御部１０３はステップＳ４４５で選択した共通セキュリティポリシーに従った動作を行い、受信処理は終了する。なお、ステップＳ４４７では、図３６のステップＳ３８４と同様の処理が行われる。

以上のようにして共通IoT機器７２は、選択基準情報と、複数のセキュリティポリシーコンフィギュレーションとを受信して、共通セキュリティポリシーを選択（決定）し、選択された共通セキュリティポリシーに応じた動作を行う。このようにすることで、適切な共通セキュリティポリシーを選択して同じデータが重複して授受されることを防止し、効率的に十分なセキュリティ耐性を得ることができる。

なお、以上において説明した各実施の形態を適宜組み合わせるようにしてもよい。

〈コンピュータの構成例〉
ところで、上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のコンピュータなどが含まれる。

図４０は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。

コンピュータにおいて、ＣＰＵ（Central Processing Unit）５０１，ＲＯＭ（Read Only Memory）５０２，ＲＡＭ（Random Access Memory）５０３は、バス５０４により相互に接続されている。

バス５０４には、さらに、入出力インターフェース５０５が接続されている。入出力インターフェース５０５には、入力部５０６、出力部５０７、記録部５０８、通信部５０９、及びドライブ５１０が接続されている。

入力部５０６は、キーボード、マウス、マイクロホン、撮像素子などよりなる。出力部５０７は、ディスプレイ、スピーカなどよりなる。記録部５０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部５０９は、ネットワークインターフェースなどよりなる。ドライブ５１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体５１１を駆動する。

以上のように構成されるコンピュータでは、ＣＰＵ５０１が、例えば、記録部５０８に記録されているプログラムを、入出力インターフェース５０５及びバス５０４を介して、ＲＡＭ５０３にロードして実行することにより、上述した一連の処理が行われる。

コンピュータ（ＣＰＵ５０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体５１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。

コンピュータでは、プログラムは、リムーバブル記録媒体５１１をドライブ５１０に装着することにより、入出力インターフェース５０５を介して、記録部５０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部５０９で受信し、記録部５０８にインストールすることができる。その他、プログラムは、ＲＯＭ５０２や記録部５０８に、あらかじめインストールしておくことができる。

なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。

また、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

例えば、本技術は、１つの機能をネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。

また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。

さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。

また、本明細書中に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。

さらに、本技術は、以下の構成とすることも可能である。

（１）
自身のセキュリティに関する情報を送信し、前記セキュリティに関する情報の送信に応じて送信されてきた、セキュリティ保護のために実行すべき処理を示す指定情報を受信する通信部と、
所定の機器に対してデータを送信するか、または前記機器から送信されたデータを受信する場合に、前記指定情報に基づいてセキュリティ保護のための処理を行う制御部と
を備える情報処理装置。
（２）
前記セキュリティに関する情報には、前記情報処理装置が実行可能な前記セキュリティ保護のための処理を示す情報が含まれている
（１）に記載の情報処理装置。
（３）
前記セキュリティ保護のための処理は暗号化、データ完全性チェック、または認証である
（１）または（２）に記載の情報処理装置。
（４）
前記セキュリティに関する情報には、前記情報処理装置がデータに対して実行可能な処理を示す情報が含まれている
（１）乃至（３）の何れか一項に記載の情報処理装置。
（５）
前記情報処理装置がデータに対して実行可能な処理は、データに対する個人識別情報の付加、またはデータに対する変換処理である
（４）に記載の情報処理装置。
（６）
前記セキュリティに関する情報には、セキュリティに関する前記情報処理装置と前記機器との間のセグメントの状態を示す情報が含まれている
（１）乃至（５）の何れか一項に記載の情報処理装置。
（７）
前記通信部は、前記セキュリティに関する情報の送信要求を受信した場合、前記送信要求を前記機器に送信するとともに、前記送信要求に応じて自身の前記セキュリティに関する情報を送信する
（１）乃至（６）の何れか一項に記載の情報処理装置。
（８）
前記通信部は、前記機器から前記送信要求に対する応答がなかった場合、前記セキュリティに関する情報のレポート能力を有していない前記機器が存在する旨の情報を送信する
（７）に記載の情報処理装置。
（９）
前記制御部は、前記レポート能力を有していない前記機器との接続拒否を要求する接続拒否要求が前記通信部により受信されたとき、前記レポート能力を有していない前記機器とのデータの授受を行わないように制御する
（８）に記載の情報処理装置。
（１０）
前記通信部は、前記機器から前記送信要求に対する応答がなかった場合、前記機器とのデータの授受により前記機器の前記セキュリティに関する情報が特定されたとき、特定された前記機器の前記セキュリティに関する情報を送信する
（７）または（８）に記載の情報処理装置。
（１１）
前記セキュリティに関する情報には、前記情報処理装置と前記機器との間のセグメントにおけるデータのトラフィック量に関する情報が含まれている
（１）乃至（１０）の何れか一項に記載の情報処理装置。
（１２）
前記制御部は、前記情報処理装置と前記機器との間のセグメントについて、互いに異なる複数の装置から前記指定情報を受信した場合、受信された複数の前記指定情報のなかから１つの前記指定情報を選択し、選択した前記指定情報に基づいて前記セキュリティ保護のための処理を行う
（１）乃至（１１）の何れか一項に記載の情報処理装置。
（１３）
前記通信部は、前記指定情報の選択結果を示す情報を前記複数の装置に送信する
（１２）に記載の情報処理装置。
（１４）
前記通信部は、前記指定情報の選択基準を示す選択基準情報をさらに受信し、
前記制御部は、前記選択基準情報に基づいて前記指定情報を選択する
（１２）または（１３）に記載の情報処理装置。
（１５）
情報処理装置の情報処理方法であって、
自身のセキュリティに関する情報を送信し、前記セキュリティに関する情報の送信に応じて送信されてきた、セキュリティ保護のために実行すべき処理を示す指定情報を受信し、
所定の機器に対してデータを送信するか、または前記機器から送信されたデータを受信する場合に、前記指定情報に基づいてセキュリティ保護のための処理を行う
ステップを含む情報処理方法。
（１６）
情報処理装置を制御するコンピュータに、
自身のセキュリティに関する情報を送信し、前記セキュリティに関する情報の送信に応じて送信されてきた、セキュリティ保護のために実行すべき処理を示す指定情報を受信し、
所定の機器に対してデータを送信するか、または前記機器から送信されたデータを受信する場合に、前記指定情報に基づいてセキュリティ保護のための処理を行う
ステップを含む処理を実行させるプログラム。
（１７）
所定の機器のセキュリティに関する情報を受信し、前記機器においてセキュリティ保護のために実行すべき処理を示す指定情報を送信する通信部と、
前記セキュリティに関する情報に基づいて前記指定情報を生成する制御部と
を備える情報処理装置。
（１８）
前記セキュリティに関する情報には、前記機器が実行可能な前記セキュリティ保護のための処理を示す情報が含まれている
（１７）に記載の情報処理装置。
（１９）
前記セキュリティ保護のための処理は暗号化、データ完全性チェック、または認証である
（１７）または（１８）に記載の情報処理装置。
（２０）
前記セキュリティに関する情報には、前記機器がデータに対して実行可能な処理を示す情報が含まれている
（１７）乃至（１９）の何れか一項に記載の情報処理装置。
（２１）
前記機器がデータに対して実行可能な処理は、データに対する個人識別情報の付加、またはデータに対する変換処理である
（２０）に記載の情報処理装置。
（２２）
前記セキュリティに関する情報には、セキュリティに関する前記機器と他の機器との間のセグメントの状態を示す情報が含まれている
（１７）乃至（２１）の何れか一項に記載の情報処理装置。
（２３）
前記制御部は、前記通信部により前記セキュリティに関する情報のレポート能力を有していない他の機器が存在する旨の情報を前記機器から受信した場合、前記セキュリティに関する情報、および前記レポート能力を有していない前記他の機器が存在する旨の情報に基づいて前記指定情報を生成する
（１７）乃至（２２）の何れか一項に記載の情報処理装置。
（２４）
前記制御部は、前記レポート能力を有していない前記他の機器が存在する旨の情報の受信後、前記機器により特定された前記他の機器の前記セキュリティに関する情報が前記通信部により受信された場合、前記他の機器の前記セキュリティに関する情報に基づいて、前記他の機器に接続された、前記機器とは異なる機器の前記指定情報を生成する
（２３）に記載の情報処理装置。
（２５）
前記通信部は、前記レポート能力を有していない前記他の機器との接続拒否を要求する接続拒否要求を前記機器に送信する
（２３）に記載の情報処理装置。
（２６）
前記セキュリティに関する情報には、前記機器と他の機器との間のセグメントにおけるデータのトラフィック量に関する情報が含まれている
（１７）乃至（２５）の何れか一項に記載の情報処理装置。
（２７）
前記通信部は、ローカルネットワークを構成する前記機器に前記指定情報を送信し、前記ローカルネットワークを含むネットワークのセキュリティ管理を行う装置に対して、前記ローカルネットワークにおけるセキュリティの管理状況を示す情報を送信する
（１７）乃至（２６）の何れか一項に記載の情報処理装置。
（２８）
前記制御部は、前記機器と他の機器との間のセグメントについて、前記セキュリティに関する情報に基づいて前記機器においてセキュリティ保護のために実行すべき処理を決定し、その決定結果と、前記機器においてセキュリティ保護のために実行すべき処理の前記情報処理装置とは異なる他の情報処理装置による決定結果とに基づいて前記指定情報を生成する
（１７）乃至（２６）の何れか一項に記載の情報処理装置。
（２９）
前記通信部は、
前記指定情報の選択基準を示す選択基準情報を前記機器に送信し、
前記機器と他の機器との間のセグメントについて、前記機器において前記情報処理装置を含む複数の装置から受信した複数の前記指定情報のなかから選択された１つの前記指定情報を示す情報を前記機器から受信する
（１７）乃至（２６）の何れか一項に記載の情報処理装置。
（３０）
所定の機器のセキュリティに関する情報を受信し、
前記セキュリティに関する情報に基づいて、前記機器においてセキュリティ保護のために実行すべき処理を示す指定情報を生成し、
前記指定情報を送信する
ステップを含む情報処理方法。
（３１）
所定の機器のセキュリティに関する情報を受信し、
前記セキュリティに関する情報に基づいて、前記機器においてセキュリティ保護のために実行すべき処理を示す指定情報を生成し、
前記指定情報を送信する
ステップを含む処理をコンピュータに実行させるプログラム。

７２－１乃至７２－６，７２ IoT機器， ７３ セキュリティマネジメントエンティティ， １０１ 通信部， １０３ 制御部， １１１ データ処理部， １１２ セキュリティ処理部， １４１ 通信部， １４３ 制御部， １５１ セキュリティポリシー決定部， １８１ ローカルセキュリティマネジメントエンティティ， ２１１ 通信部， ２１３ 制御部， ２２１ セキュリティポリシー決定部， ２２２ データ処理部， ２２３ セキュリティ処理部

Claims (29)

1. 自身のセキュリティに関する情報を送信し、前記セキュリティに関する情報の送信に応じて送信されてきた、セキュリティ保護のために実行すべき処理を示す指定情報を受信する通信部と、
   所定の機器に対してデータを送信するか、または前記機器から送信されたデータを受信する場合に、前記指定情報に基づいてセキュリティ保護のための処理を行う制御部と
   を備え、
   前記セキュリティに関する情報には、セキュリティに関する自身と前記機器との間のセグメントの状態を示す情報が含まれている
   情報処理装置。
2. 前記セキュリティに関する情報には、前記情報処理装置が実行可能な前記セキュリティ保護のための処理を示す情報が含まれている
   請求項１に記載の情報処理装置。
3. 前記セキュリティ保護のための処理は暗号化、データ完全性チェック、または認証である
   請求項１に記載の情報処理装置。
4. 前記セキュリティに関する情報には、前記情報処理装置がデータに対して実行可能な処理を示す情報が含まれている
   請求項１に記載の情報処理装置。
5. 前記情報処理装置がデータに対して実行可能な処理は、データに対する個人識別情報の付加、またはデータに対する変換処理である
   請求項４に記載の情報処理装置。
6. 前記通信部は、前記セキュリティに関する情報の送信要求を受信した場合、前記送信要求を前記機器に送信するとともに、前記送信要求に応じて自身の前記セキュリティに関する情報を送信する
   請求項１に記載の情報処理装置。
7. 前記通信部は、前記機器から前記送信要求に対する応答がなかった場合、前記セキュリティに関する情報のレポート能力を有していない前記機器が存在する旨の情報を送信する
   請求項６に記載の情報処理装置。
8. 前記制御部は、前記レポート能力を有していない前記機器との接続拒否を要求する接続拒否要求が前記通信部により受信されたとき、前記レポート能力を有していない前記機器とのデータの授受を行わないように制御する
   請求項７に記載の情報処理装置。
9. 前記通信部は、前記機器から前記送信要求に対する応答がなかった場合、前記機器とのデータの授受により前記機器の前記セキュリティに関する情報が特定されたとき、特定された前記機器の前記セキュリティに関する情報を送信する
   請求項６に記載の情報処理装置。
10. 前記セキュリティに関する情報には、前記情報処理装置と前記機器との間のセグメントにおけるデータのトラフィック量に関する情報が含まれている
    請求項１に記載の情報処理装置。
11. 前記制御部は、前記情報処理装置と前記機器との間のセグメントについて、互いに異なる複数の装置から前記指定情報を受信した場合、受信された複数の前記指定情報のなかから１つの前記指定情報を選択し、選択した前記指定情報に基づいて前記セキュリティ保護のための処理を行う
    請求項１に記載の情報処理装置。
12. 前記通信部は、前記指定情報の選択結果を示す情報を前記複数の装置に送信する
    請求項１１に記載の情報処理装置。
13. 前記通信部は、前記指定情報の選択基準を示す選択基準情報をさらに受信し、
    前記制御部は、前記選択基準情報に基づいて前記指定情報を選択する
    請求項１１に記載の情報処理装置。
14. 情報処理装置の情報処理方法であって、
    自身のセキュリティに関する情報を送信し、前記セキュリティに関する情報の送信に応じて送信されてきた、セキュリティ保護のために実行すべき処理を示す指定情報を受信し、
    所定の機器に対してデータを送信するか、または前記機器から送信されたデータを受信する場合に、前記指定情報に基づいてセキュリティ保護のための処理を行う
    ステップを含み、
    前記セキュリティに関する情報には、セキュリティに関する自身と前記機器との間のセグメントの状態を示す情報が含まれている
    情報処理方法。
15. 情報処理装置を制御するコンピュータに、
    自身のセキュリティに関する情報を送信し、前記セキュリティに関する情報の送信に応じて送信されてきた、セキュリティ保護のために実行すべき処理を示す指定情報を受信し、
    所定の機器に対してデータを送信するか、または前記機器から送信されたデータを受信する場合に、前記指定情報に基づいてセキュリティ保護のための処理を行う
    ステップを含む処理を実行させ、
    前記セキュリティに関する情報には、セキュリティに関する自身と前記機器との間のセグメントの状態を示す情報が含まれている
    プログラム。
16. 所定の機器のセキュリティに関する情報を受信し、前記機器においてセキュリティ保護のために実行すべき処理を示す指定情報を送信する通信部と、
    前記セキュリティに関する情報に基づいて前記指定情報を生成する制御部と
    を備え、
    前記セキュリティに関する情報には、セキュリティに関する前記機器と他の機器との間のセグメントの状態を示す情報が含まれている
    情報処理装置。
17. 前記セキュリティに関する情報には、前記機器が実行可能な前記セキュリティ保護のための処理を示す情報が含まれている
    請求項１６に記載の情報処理装置。
18. 前記セキュリティ保護のための処理は暗号化、データ完全性チェック、または認証である
    請求項１７に記載の情報処理装置。
19. 前記セキュリティに関する情報には、前記機器がデータに対して実行可能な処理を示す情報が含まれている
    請求項１６に記載の情報処理装置。
20. 前記機器がデータに対して実行可能な処理は、データに対する個人識別情報の付加、またはデータに対する変換処理である
    請求項１９に記載の情報処理装置。
21. 前記制御部は、前記通信部により前記セキュリティに関する情報のレポート能力を有していない他の機器が存在する旨の情報を前記機器から受信した場合、前記セキュリティに関する情報、および前記レポート能力を有していない前記他の機器が存在する旨の情報に基づいて前記指定情報を生成する
    請求項１６に記載の情報処理装置。
22. 前記制御部は、前記レポート能力を有していない前記他の機器が存在する旨の情報の受信後、前記機器により特定された前記レポート能力を有していない前記他の機器の前記セキュリティに関する情報が前記通信部により受信された場合、前記レポート能力を有していない前記他の機器の前記セキュリティに関する情報に基づいて、前記レポート能力を有していない前記他の機器に接続された、前記機器とは異なる機器の前記指定情報を生成する
    請求項２１に記載の情報処理装置。
23. 前記通信部は、前記レポート能力を有していない前記他の機器との接続拒否を要求する接続拒否要求を前記機器に送信する
    請求項２１に記載の情報処理装置。
24. 前記セキュリティに関する情報には、前記機器と他の機器との間のセグメントにおけるデータのトラフィック量に関する情報が含まれている
    請求項１６に記載の情報処理装置。
25. 前記通信部は、ローカルネットワークを構成する前記機器に前記指定情報を送信し、前記ローカルネットワークを含むネットワークのセキュリティ管理を行う装置に対して、前記ローカルネットワークにおけるセキュリティの管理状況を示す情報を送信する
    請求項１６に記載の情報処理装置。
26. 前記制御部は、前記機器と他の機器との間のセグメントについて、前記セキュリティに関する情報に基づいて前記機器においてセキュリティ保護のために実行すべき処理を決定し、その決定結果と、前記機器においてセキュリティ保護のために実行すべき処理の前記情報処理装置とは異なる他の情報処理装置による決定結果とに基づいて前記指定情報を生成する
    請求項１６に記載の情報処理装置。
27. 前記通信部は、
    前記指定情報の選択基準を示す選択基準情報を前記機器に送信し、
    前記機器と他の機器との間のセグメントについて、前記機器において前記情報処理装置を含む複数の装置から受信した複数の前記指定情報のなかから選択された１つの前記指定情報を示す情報を前記機器から受信する
    請求項１６に記載の情報処理装置。
28. 所定の機器のセキュリティに関する情報を受信し、
    前記セキュリティに関する情報に基づいて、前記機器においてセキュリティ保護のために実行すべき処理を示す指定情報を生成し、
    前記指定情報を送信する
    ステップを含み、
    前記セキュリティに関する情報には、セキュリティに関する前記機器と他の機器との間のセグメントの状態を示す情報が含まれている
    情報処理方法。
29. 所定の機器のセキュリティに関する情報を受信し、
    前記セキュリティに関する情報に基づいて、前記機器においてセキュリティ保護のために実行すべき処理を示す指定情報を生成し、
    前記指定情報を送信する
    ステップを含む処理をコンピュータに実行させ、
    前記セキュリティに関する情報には、セキュリティに関する前記機器と他の機器との間のセグメントの状態を示す情報が含まれている
    プログラム。

Images