(57)【要約】  本技術は、効率的に十分なセキュリティ保護を行うことができるようにする情報処理装置および方法、並びにプログラムに関する。情報処理装置は、自身のセキュリティに関する情報を送信し、セキュリティに関する情報の送信に応じて送信されてきた、セキュリティ保護のために実行すべき処理を示す指定情報を受信する通信部と、所定の機器に対してデータを送信するか、または機器から送信されたデータを受信する場合に、指定情報に基づいてセキュリティ保護のための処理を行う制御部とを備える。本技術はヘルスケアIoTシステムに適用することができる。
2018135309.tif 000002
【特許請求の範囲】
【請求項１】
自身のセキュリティに関する情報を送信し、前記セキュリティに関する情報の送信に応じて送信されてきた、セキュリティ保護のために実行すべき処理を示す指定情報を受信する通信部と、
所定の機器に対してデータを送信するか、または前記機器から送信されたデータを受信する場合に、前記指定情報に基づいてセキュリティ保護のための処理を行う制御部と
を備える情報処理装置。
【請求項２】
前記セキュリティに関する情報には、前記情報処理装置が実行可能な前記セキュリティ保護のための処理を示す情報が含まれている
請求項１に記載の情報処理装置。
【請求項３】
前記セキュリティ保護のための処理は暗号化、データ完全性チェック、または認証である
請求項１に記載の情報処理装置。
【請求項４】
前記セキュリティに関する情報には、前記情報処理装置がデータに対して実行可能な処理を示す情報が含まれている
請求項１に記載の情報処理装置。
【請求項５】
前記情報処理装置がデータに対して実行可能な処理は、データに対する個人識別情報の付加、またはデータに対する変換処理である
請求項４に記載の情報処理装置。
【請求項６】
前記セキュリティに関する情報には、セキュリティに関する前記情報処理装置と前記機器との間のセグメントの状態を示す情報が含まれている
請求項１に記載の情報処理装置。
【請求項７】
前記通信部は、前記セキュリティに関する情報の送信要求を受信した場合、前記送信要求を前記機器に送信するとともに、前記送信要求に応じて自身の前記セキュリティに関する情報を送信する
請求項１に記載の情報処理装置。
【請求項８】
前記通信部は、前記機器から前記送信要求に対する応答がなかった場合、前記セキュリティに関する情報のレポート能力を有していない前記機器が存在する旨の情報を送信する
請求項７に記載の情報処理装置。
【請求項９】
前記制御部は、前記レポート能力を有していない前記機器との接続拒否を要求する接続拒否要求が前記通信部により受信されたとき、前記レポート能力を有していない前記機器とのデータの授受を行わないように制御する
請求項８に記載の情報処理装置。
【請求項１０】
前記通信部は、前記機器から前記送信要求に対する応答がなかった場合、前記機器とのデータの授受により前記機器の前記セキュリティに関する情報が特定されたとき、特定された前記機器の前記セキュリティに関する情報を送信する
請求項７に記載の情報処理装置。
【請求項１１】
前記セキュリティに関する情報には、前記情報処理装置と前記機器との間のセグメントにおけるデータのトラフィック量に関する情報が含まれている
請求項１に記載の情報処理装置。
【請求項１２】
前記制御部は、前記情報処理装置と前記機器との間のセグメントについて、互いに異なる複数の装置から前記指定情報を受信した場合、受信された複数の前記指定情報のなかから１つの前記指定情報を選択し、選択した前記指定情報に基づいて前記セキュリティ保護のための処理を行う
請求項１に記載の情報処理装置。
【請求項１３】
前記通信部は、前記指定情報の選択結果を示す情報を前記複数の装置に送信する
請求項１２に記載の情報処理装置。
【請求項１４】
前記通信部は、前記指定情報の選択基準を示す選択基準情報をさらに受信し、
前記制御部は、前記選択基準情報に基づいて前記指定情報を選択する
請求項１２に記載の情報処理装置。
【請求項１５】
情報処理装置の情報処理方法であって、
自身のセキュリティに関する情報を送信し、前記セキュリティに関する情報の送信に応じて送信されてきた、セキュリティ保護のために実行すべき処理を示す指定情報を受信し、
所定の機器に対してデータを送信するか、または前記機器から送信されたデータを受信する場合に、前記指定情報に基づいてセキュリティ保護のための処理を行う
ステップを含む情報処理方法。
【請求項１６】
情報処理装置を制御するコンピュータに、
自身のセキュリティに関する情報を送信し、前記セキュリティに関する情報の送信に応じて送信されてきた、セキュリティ保護のために実行すべき処理を示す指定情報を受信し、
所定の機器に対してデータを送信するか、または前記機器から送信されたデータを受信する場合に、前記指定情報に基づいてセキュリティ保護のための処理を行う
ステップを含む処理を実行させるプログラム。
【請求項１７】
所定の機器のセキュリティに関する情報を受信し、前記機器においてセキュリティ保護のために実行すべき処理を示す指定情報を送信する通信部と、
前記セキュリティに関する情報に基づいて前記指定情報を生成する制御部と
を備える情報処理装置。
【請求項１８】
前記セキュリティに関する情報には、前記機器が実行可能な前記セキュリティ保護のための処理を示す情報が含まれている
請求項１７に記載の情報処理装置。
【請求項１９】
前記セキュリティ保護のための処理は暗号化、データ完全性チェック、または認証である
請求項１７に記載の情報処理装置。
【請求項２０】
前記セキュリティに関する情報には、前記機器がデータに対して実行可能な処理を示す情報が含まれている
請求項１７に記載の情報処理装置。
【請求項２１】
前記機器がデータに対して実行可能な処理は、データに対する個人識別情報の付加、またはデータに対する変換処理である
請求項２０に記載の情報処理装置。
【請求項２２】
前記セキュリティに関する情報には、セキュリティに関する前記機器と他の機器との間のセグメントの状態を示す情報が含まれている
請求項１７に記載の情報処理装置。
【請求項２３】
前記制御部は、前記通信部により前記セキュリティに関する情報のレポート能力を有していない他の機器が存在する旨の情報を前記機器から受信した場合、前記セキュリティに関する情報、および前記レポート能力を有していない前記他の機器が存在する旨の情報に基づいて前記指定情報を生成する
請求項１７に記載の情報処理装置。
【請求項２４】
前記制御部は、前記レポート能力を有していない前記他の機器が存在する旨の情報の受信後、前記機器により特定された前記他の機器の前記セキュリティに関する情報が前記通信部により受信された場合、前記他の機器の前記セキュリティに関する情報に基づいて、前記他の機器に接続された、前記機器とは異なる機器の前記指定情報を生成する
請求項２３に記載の情報処理装置。
【請求項２５】
前記通信部は、前記レポート能力を有していない前記他の機器との接続拒否を要求する接続拒否要求を前記機器に送信する
請求項２３に記載の情報処理装置。
【請求項２６】
前記セキュリティに関する情報には、前記機器と他の機器との間のセグメントにおけるデータのトラフィック量に関する情報が含まれている
請求項１７に記載の情報処理装置。
【請求項２７】
前記通信部は、ローカルネットワークを構成する前記機器に前記指定情報を送信し、前記ローカルネットワークを含むネットワークのセキュリティ管理を行う装置に対して、前記ローカルネットワークにおけるセキュリティの管理状況を示す情報を送信する
請求項１７に記載の情報処理装置。
【請求項２８】
前記制御部は、前記機器と他の機器との間のセグメントについて、前記セキュリティに関する情報に基づいて前記機器においてセキュリティ保護のために実行すべき処理を決定し、その決定結果と、前記機器においてセキュリティ保護のために実行すべき処理の前記情報処理装置とは異なる他の情報処理装置による決定結果とに基づいて前記指定情報を生成する
請求項１７に記載の情報処理装置。
【請求項２９】
前記通信部は、
前記指定情報の選択基準を示す選択基準情報を前記機器に送信し、
前記機器と他の機器との間のセグメントについて、前記機器において前記情報処理装置を含む複数の装置から受信した複数の前記指定情報のなかから選択された１つの前記指定情報を示す情報を前記機器から受信する
請求項１７に記載の情報処理装置。
【請求項３０】
所定の機器のセキュリティに関する情報を受信し、
前記セキュリティに関する情報に基づいて、前記機器においてセキュリティ保護のために実行すべき処理を示す指定情報を生成し、
前記指定情報を送信する
ステップを含む情報処理方法。
【請求項３１】
所定の機器のセキュリティに関する情報を受信し、
前記セキュリティに関する情報に基づいて、前記機器においてセキュリティ保護のために実行すべき処理を示す指定情報を生成し、
前記指定情報を送信する
ステップを含む処理をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は情報処理装置および方法、並びにプログラムに関し、特に、効率的に十分なセキュリティ保護を行うことができるようにした情報処理装置および方法、並びにプログラムに関する。
【背景技術】
【０００２】
近年、例えば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機器，  ７３  セキュリティマネジメントエンティティ，  １０１  通信部，  １０３  制御部，  １１１  データ処理部，  １１２  セキュリティ処理部，  １４１  通信部，  １４３  制御部，  １５１  セキュリティポリシー決定部，  １８１  ローカルセキュリティマネジメントエンティティ，  ２１１  通信部，  ２１３  制御部，  ２２１  セキュリティポリシー決定部，  ２２２  データ処理部，  ２２３  セキュリティ処理部
【図１】
2018135309.tif 000003
【図２】
2018135309.tif 000004
【図３】
2018135309.tif 000005
【図４】
2018135309.tif 000006
【図５】
2018135309.tif 000007
【図６】
2018135309.tif 000008
【図７】
2018135309.tif 000009
【図８】
2018135309.tif 000010
【図９】
2018135309.tif 000011
【図１０】
2018135309.tif 000012
【図１１】
2018135309.tif 000013
【図１２】
2018135309.tif 000014
【図１３】
2018135309.tif 000015
【図１４】
2018135309.tif 000016
【図１５】
2018135309.tif 000017
【図１６】
2018135309.tif 000018
【図１７】
2018135309.tif 000019
【図１８】
2018135309.tif 000020
【図１９】
2018135309.tif 000021
【図２０】
2018135309.tif 000022
【図２１】
2018135309.tif 000023
【図２２】
2018135309.tif 000024
【図２３】
2018135309.tif 000025
【図２４】
2018135309.tif 000026
【図２５】
2018135309.tif 000027
【図２６】
2018135309.tif 000028
【図２７】
2018135309.tif 000029
【図２８】
2018135309.tif 000030
【図２９】
2018135309.tif 000031
【図３０】
2018135309.tif 000032
【図３１】
2018135309.tif 000033
【図３２】
2018135309.tif 000034
【図３３】
2018135309.tif 000035
【図３４】
2018135309.tif 000036
【図３５】
2018135309.tif 000037
【図３６】
2018135309.tif 000038
【図３７】
2018135309.tif 000039
【図３８】
2018135309.tif 000040
【図３９】
2018135309.tif 000041
【図４０】
2018135309.tif 000042
【国際調査報告】
2018135309.tif 000043
2018135309.tif 000044
2018135309.tif 000045
2018135309.tif 000046