(57)【要約】  本発明によれば、複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて一元的なアクセス管理を実現することができるアクセス管理装置を提供する。  本発明のアクセス管理装置は、アクセス元（ＡＳ）と複数の処理系（ＰＳ）との間に接続され、アクセス元（ＡＳ）からのアクセス要求を受信し、設定されたアクセス管理ポリシーに基づいて、アクセス要求の制御を行なうアクセス管理機能部（２２）を有するゲートウェイ（１１）とを具備する。
2019059034.tif 000002
【特許請求の範囲】
【請求項１】
アクセス元と、前記アクセス元からのアクセス要求に対する処理を行なう複数の処理系との間に接続され、前記アクセス元からのアクセス要求を受信し、前記複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なうアクセス管理機能部を有するゲートウェイを具備するアクセス管理装置。
【請求項２】
前記ゲートウェイは、
前記アクセス元のＩＰアドレスに基づいて、前記アクセス元の識別情報を取得し、前記取得したアクセス元の識別情報を前記アクセス管理機能部に送信するアクセス元識別機能部をさらに具備する、請求項１記載のアクセス管理装置。
【請求項３】
前記アクセス管理ポリシーは、前記ゲートウェイのキャッシュメモリ上に記憶される、請求項１記載のアクセス管理装置。
【請求項４】
前記ゲートウェイは、前記アクセス管理機能部によってアクセス要求が認められた場合、前記複数の処理系と前記アクセス元との間のプロトコル変換を行なうプロトコル中継機能部をさらに具備する、請求項１記載のアクセス管理装置。
【請求項５】
前記アクセス管理ポリシーは、
前記アクセス元と、前記アクセス元のアクセス先と、前記アクセス元の前記アクセス先への可能な操作とが関連付けられたアクセス制御ポリシーを有する、請求項１記載のアクセス管理装置。
【請求項６】
前記アクセス管理ポリシーは、
前記アクセス元のアクセス先と、前記アクセス元と、前記アクセス元の前記アクセス先への同時アクセス数情報とが関連付けられた同時アクセス数制限ポリシーを有する、請求項１記載のアクセス管理装置。
【請求項７】
前記アクセス管理ポリシーは、
前記アクセス元と、前記アクセス元の前記優先度とが関連付けられた優先制御ポリシーを有する、請求項１記載のアクセス管理装置。
【請求項８】
アクセス元と、前記アクセス元からのアクセス要求に対する処理を行なう複数の処理系との間に接続され、前記アクセス元からのアクセス要求を受信し、
前記複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なうアクセス管理機能部を有するゲートウェイを具備するアクセス管理装置におけるアクセス管理方法において、
前記アクセス管理機能部は、
前記アクセス元からのアクセス要求を受信し、
前記記憶部に記憶されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なう、アクセス管理方法。
【請求項９】
前記アクセス元のＩＰアドレスに基づいて、前記アクセス元の識別情報を取得し、前記取得したアクセス元の識別情報を前記アクセス管理機能部に送信する処理を、さらに行う、請求項８記載のアクセス管理方法。
【請求項１０】
前記ゲートウェイのキャッシュメモリ上に前記アクセス管理ポリシーを記憶する処理を、さらに行う、請求項８記載のアクセス管理方法。
【請求項１１】
前記アクセス管理機能部によってアクセス要求が認められた場合、前記複数の処理系と、前記アクセス元との間のプロトコル変換を、さらに行なう、請求項８記載のアクセス管理方法。
【請求項１２】
前記アクセス管理ポリシーは、
前記アクセス元と、前記アクセス元のアクセス先と、前記アクセス元の前記アクセス先への可能な操作とが関連付けられたアクセス制御ポリシーを有する、請求項８記載のアクセス管理方法。
【請求項１３】
前記アクセス管理ポリシーは、
前記アクセス元のアクセス先と、前記アクセス元と、前記アクセス元の前記アクセス先への同時アクセス数情報とが関連付けられた同時アクセス数制限ポリシーを有する、請求項８記載のアクセス管理方法。
【請求項１４】
前記アクセス管理ポリシーは、
前記アクセス元と、前記アクセス元の前記優先度とが関連付けられた優先制御ポリシーを有する、請求項８記載のアクセス管理方法。
【請求項１５】
アクセス元と、前記アクセス元からのアクセス要求に対する処理を行なう複数の処理系との間に接続されたアクセス管理機能部を有するゲートウェイを具備するアクセス管理装置におけるアクセス管理方法を実行するプログラムにおいて、
前記プログラムは、前記アクセス機能管理部に、
前記アクセス元からのアクセス要求を受信させ、
前記複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なわせる、
プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アクセス管理装置及びアクセス管理方法に関する。
【背景技術】
【０００２】
ＩｏＴ（Internet of Things）サービスを容易に構築可能とする基盤（ＩｏＴ基盤）が注目を集めている。ＩｏＴ基盤においては、多様なサービスを実現するため、異種の処理系（データ管理、データ配信等）を備え、また、これら処理系に適した異種のプロトコル（Hypertext Transfer Protocol（ＨＴＴＰ）、Message Queueing Telemetry Transport（ＭＱＴＴ）等）に対応することが想定されている。【０００３】
従って、これら処理系に入出力されるデータを管理するニーズが存在する。ここで、「管理」とは、アクセス制御、同時アクセス制限、優先制御などを含む。また、処理系に入出力されるデータには、機微なデータが含まれ得る。機微なデータとしては、例えば、製造業における生産工程に関するデータ、個人のバイタルデータなどである。【０００４】
従来、ＩｏＴ基盤では、各処理系がそれぞれ、アプリケーションプログラム（以下、「アプリ」という。）やデバイスに対応するインターフェイスを備えている。このため、これらインターフェイス毎に、個別にアクセス管理機構を実装する（＝個別対応）ことで、アクセス管理を実現することが可能である。図７は、従来のＩｏＴ基盤Ｓのアクセス管理装置の概要を示す図である。同図に示すように、アクセス元ＡＳ−１〜ＡＳ−Ｎに対応するＩｏＴ基盤Ｓの各処理系ＰＳ−１〜ＰＳ−Ｎは、アクセス管理機構を有している。【０００５】
図５は、アクセス元であるアプリＡＰ−１〜ＡＰ−３及びデバイスＤＢ−１〜ＤＢ−５と各処理系ＰＳ−１〜ＰＳ−４との関係を示す図である。【０００６】
同図において、アクセス元であるアプリＡＰ−１〜ＡＰ−３及びデバイスＤＢ−１〜ＤＢ−５は、ＩｏＴ基盤Ｓのデータ処理系ＰＳ−１〜ＰＳ−４にアクセス可能である。各データ処理系ＰＳ−１〜ＰＳ−４は、アクセス元であるアプリＡＰ−１〜ＡＰ−３及びデバイスＤＢ−１〜ＤＢ−５に対応するインターフェイスを備えており、各インターフェイス毎にアクセス管理機構を実装している。【０００７】
ここで、データ処理系ＰＳ−１はデータ管理に関する処理、データ処理系ＰＳ−２はデータ配信に関する処理、データ処理系ＰＳ−３はデータ分析に関する処理、データ処理系ＰＳ−４はデバイス制御に関する処理を行なう。また、デバイスＤＢ−１は車、デバイスＤＢ−２、デバイスＤＢ−３はスマートフォン、デバイスＤＢ−４はオシロスコープ、デバイスＤＢ−５はアクチュエータを示す。【０００８】
プロトコルと処理系の組み合わせ毎にアクセス管理機構を用意するものとして、例えば、非特許文献１には、ＲＥＳＴ  ＡＰＩに関する市中のアクセス制御技術が開示されており、非特許文献２には、ＭＱＴＴブローカに関する市中のアクセス制御技術が開示されている。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】"Ｗｈａｔ  ｉｓ  Ｋｏｎｇ"  、［ｏｎｌｉｎｅ］、Ｋｏｎｇ−Ｏｐｅｎ−ｓｏｕｒｃｅ  ＡＰＩ  Ｍｎａｇｅｍｅｎｔ  ａｎｄ  Ｍｉｃｒｏｓｅｒｖｉｃｅ  Ｍａｎａｇｅｍｅｎｔ、［平成２９年５月１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐｓ：／／ｇｅｔｋｏｎｇ．ｏｒｇ／ａｂｏｕｔ／＞
【非特許文献２】”ｍｏｓｑｕｉｔｔｏ．ｃｏｎｆ−ｔｈｅ  ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｆｉｌｅ  ｆｏｒ  ｍｏｓｑｕｉｔｔｏ”、［平成２９年５月１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｍｏｓｑｕｉｔｔｏ．ｏｒｇ／ｍａｎ／ｍｏｓｑｕｉｔｔｏ−ｃｏｎｆ−５．ｈｔｍｌ＞
【発明の概要】
【００１０】
しかしながら、従来のアクセス管理機構では、アクセス管理機構毎に設定管理が必要となり、運用コストが大きくなってしまうという問題がある。また、アプリ側でアクセス管理機構毎の対応が必要となり、アプリ開発の負担が大きい。さらに、アクセス管理機構間の管理ポリシー（アクセス制御ルール等）の不整合などのリスクも増大する。
【００１１】
さらに、上述のように、アクセス管理機構は、機微なデータを取り扱うため、アプリやデバイスから各処理系へのアクセスに対し、ＩｏＴ基盤を導入するユーザ（例えば、製造業では、工場管理者）のセキュリティポリシーに基づいて、アクセスの可否等を制御する必要がある。
【００１２】
本発明は、上記実情に鑑みてなされたものであり、アクセス管理機構を処理系やプロトコルから独立したゲートウェイとして構成できるようにし、設定されたアクセス管理ポリシーに基づいて一元的なアクセス管理を実現することができるアクセス管理装置及びアクセス管理方法を提供することを目的とする。
【００１３】
本発明の第１態様は、アクセス管理装置が、アクセス元と、前記アクセス元からのアクセス要求に対する処理を行なう複数の処理系との間に接続され、前記アクセス元からのアクセス要求を受信し、前記複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なうアクセス管理機能部を有するゲートウェイを具備するようにしたものである。
【００１４】
本発明の第２態様は、前記ゲートウェイが、前記アクセス元のＩＰアドレスに基づいて、前記アクセス元の識別情報を取得し、前記取得したアクセス元の識別情報を前記アクセス管理機能部に送信するアクセス元識別機能部をさらに具備するようにしたものである。
【００１５】
本発明の第３態様は、前記アクセス管理ポリシーを、前記ゲートウェイのキャッシュメモリ上に記憶するようにしたものである。
【００１６】
本発明の第４態様は、前記ゲートウェイは、前記アクセス管理機能部によってアクセス要求が認められた場合、前記複数の処理系と前記アクセス元との間のプロトコル変換を行なうプロトコル中継機能部をさらに具備するようにしたものである。
【００１７】
この発明の第１の態様によれば、複数の処理系に対して、ゲートウェイによりアクセス管理を一元的に管理することにより、運用コストを低減することができるとともに、アクセス管理ポリシーの不整合リスクを防ぐことができる。
【００１８】
この発明の第２の態様によれば、低レイヤプロトコル情報（ＩＰアドレス）を用いてアクセス元ＩＤを取得することで、上位レイヤプロトコルに依存しないアクセス元識別情報を実現することができる。
【００１９】
この発明の第３の態様によれば、アクセス管理ポリシーをオンメモリでキャッシュするため、高速なアクセス管理処理を実現することができる。
【００２０】
この発明の第４の態様によれば、プロトコル中継機能部は、アクセス管理機能部とは別に設けられているので、アクセス管理のみを一元的に管理することができる。
【００２１】
本発明の各態様によれば、アクセス管理機構を処理系やプロトコルから独立したゲートウェイとして構成することができ、設定されたアクセス管理ポリシーに基づいて一元的なアクセス管理を実現することができるアクセス管理装置及びアクセス管理方法を提供できる。
【図面の簡単な説明】
【００２２】
【図１】本発明の実施形態のＩｏＴ基盤Ｓの構成を説明するための図である。
【図２】アクセス管理ポリシーＤＢ３１に格納されるアクセス管理ポリシーの一例を示す図である。
【図３】実施形態に係るＩｏＴ基盤Ｓのアクセス管理の第１動作について説明するためのタイミングチャートである。
【図４】実施形態に係るＩｏＴ基盤Ｓのアクセス管理の第２動作について説明するためのタイミングチャートである。
【図５】アクセス元であるアプリＡＰ−１〜ＡＰ−３及びデバイスＤＢ−１〜ＤＢ−５と各処理系ＰＳ−１〜ＰＳ−４との関係を示す図である。
【図６】実施形態に係るＩｏＴ基盤Ｓのアクセス管理装置の概要を示す図である。
【図７】従来のＩｏＴ基盤Ｓのアクセス管理装置の概要を示す図である。
【図８】従来の個別対応のアクセス管理と、本発明の一元管理のアクセス管理との効果を説明するための図である。
【発明を実施するための形態】
【００２３】
以下、図面を参照して、本発明の実施形態について説明する。なお、実施形態において、構成要素を区別して説明する必要がない場合には、ハイフンを省略して説明する。例えば、アクセス元ＡＳ−１、ＡＳ−２、…、ＡＳ−ｎを区別して説明する必要がない場合には、ハイフンを省略して「ＡＳ」として説明する。他の構成要素についても同様に説明する。
【００２４】
図１は、本発明の実施形態のＩｏＴ基盤Ｓの構成を説明するための図である。同図に示すように、ＩｏＴ基盤Ｓは、複数の処理系ＰＳ−１〜ＰＳ−Ｎ、複数の処理系ＰＳ−１〜ＰＳ−Ｎに対応して設けられたプロトコルインターフェイスＩＦ−１〜ＩＦ−Ｎ、アクセス管理ゲートウェイ１１、アクセス管理ポリシーＤＢ３１を有する。
【００２５】
アクセス管理ゲートウェイ１１は、アプリやデバイスなどの複数のアクセス元ＡＳ−１〜ＡＳ−Ｎと、複数の処理系ＰＳ−１〜ＰＳ−Ｎとの間に配置され、プロトコル中継機能部２１、アクセス管理機能部２２、キャッシュ部２３及びアクセス元識別機能部２４を有する。
【００２６】
プロトコル中継機能部２１は、処理系ＰＳ−１〜ＰＳ−Ｎと、プロトコルの組み合わせ毎に存在する。アプリやデバイスからのアクセスを処理系ＰＳ−１〜ＰＳ−Ｎに中継する。
【００２７】
アクセス管理機能部２２は、アクセス管理機能毎に存在する。アクセス管理機能部２２は、プロトコル中継機能部２１に対し、中継時に挿入するアクセス管理処理を提供する機能である。例えば、アクセス制御の場合、プロトコル中継機能部２１はアクセスの中継可否をアクセス管理機能部２２に問い合わせてから中継を行なう。
【００２８】
キャッシュ部２３は、アクセス管理ポリシーＤＢ３１の情報をメモリ上にキャッシュする機能である。
【００２９】
アクセス元識別機能部２４は、低レイヤプロトコル情報（ＩＰアドレス、ＭＡＣアドレス等）を用いて、アクセス元ＡＳ−１〜ＡＳ−Ｎの識別子（アプリＩＤ、デバイスＩＤ）を取得する機能である。
【００３０】
アクセス管理ポリシーＤＢ３１は、アクセス制御のルールなどのアクセス管理ポリシーを格納するデータベースである。アクセス管理ポリシーは、システム運用者のコンピュータ４１から設定される。
【００３１】
図２は、アクセス管理ポリシーＤＢ３１に格納されるアクセス管理ポリシーの一例を示す図である。
【００３２】
同図に示すように、「アクセス制御のポリシー」としては、アクセス元、アクセス先及び可能な操作の種類が関連付けて記憶されている。例えば、アクセス元がアプリＡＰ−１、アクセス先が処理系ＰＳ−１のデータＸである場合、可能な操作は参照、更新の操作のみが許可される。また、アクセス元がアプリＡＰ−１、アクセス先が処理系ＰＳ−１のデータＹである場合、可能な操作は参照の操作のみが許可される。アクセス元がアプリＡＰ−１、アクセス先が処理系ＰＳ−２のデータＺである場合、可能な操作は参照、更新、削除の操作が許可される。
【００３３】
「同時アクセス数制限のポリシー」としては、アクセス先、アクセス元及び同時アクセス数上限が関連付けて記憶されている。例えば、アクセス先が処理系ＰＳ−１、アクセス元がアプリＡＰ−１、アプリＡＰ−２である場合、同時アクセス上限は５リクエスト／秒である。アクセス先が処理系ＰＳ−１、アクセス元がデバイスＤＢ−３である場合、同時アクセス上限は１０リクエスト／秒である。アクセス先が処理系ＰＳ−１、アクセス元がアプリＡＰ−４、ＡＰ−５である場合、同時アクセス上限は１５リクエスト／秒である。
【００３４】
「優先制御のポリシー」としては、アクセス元及び優先度が関連付けて記憶されている。例えば、アクセス元がアプリＡＰ−１の場合、優先度は「高」であり、アクセス元がアプリＡＰ−２の場合、優先度は「中」である。
【００３５】
次に、実施形態に係るＩｏＴ基盤Ｓのアクセス管理の第１動作について、図３のタイミングチャートを参照して説明する。なお、アクセス管理の動作の説明に際し、以下の環境を想定する。
【００３６】
・  アプリＡＰやデバイスＤＢとアクセス管理ゲートウェイ１１がそれぞれＤｏｃｋｅｒコンテナであり、同一のＤｏｃｋｅｒ定義ネットワーク上に配置されている。
【００３７】
・  各アプリやデバイスを一意に表わすＩＤが、各アプリやデバイスのコンテナ名として設定されている。
【００３８】
・  この時、アクセス管理ゲートウェイ１１は、アプリＡＰやデバイスＤＢからのアクセスを受信時、それらアクセス元のＩＰアドレスをＤＮＳ逆引きすることでコンテナ名（＝アクセス元ＩＤ）を取得することが可能である。
【００３９】
このような想定のもと、あるアプリＡＰがＲＥＳＴ  ＡＰＩサーバに対してアクセスする際の、アクセス制御のシーケンスを説明する。なお、図３においては、アプリＡＰからＡＰＩリクエストをする場合について示しているが、デバイスＤＢの場合であっても、同様のシーケンスとなる。
【００４０】
まず、システム管理者のコンピュータ４１からアクセス管理ポリシーＤＢ３１に、図２に示したアクセス管理ポリシーが投入される（Ｔ１）。なお、アクセス管理ポリシーには、図２に示したアクセス制御ポリシー、同時アクセス数制限のポリシー、優先制御のポリシーなどが含まれる。アクセス管理ポリシーは、アクセス管理ポリシーＤＢ３１に記憶される。
【００４１】
アクセス管理ポリシーＤＢ３１に記憶されたアクセス管理ポリシーは、キャッシュ部２３に読み込まれ（Ｔ２）、読み込まれたアクセス管理ポリシーはキャッシュ部２３のメモリに記憶される（Ｔ３）。
【００４２】
次に、アプリＡＰから処理系ＰＳへのＡＰＩリクエストがプロトコル中継機能部２１に送信される（Ｔ１１）。このＡＰＩリクエストは、例えば、ＨＴＴＰのＰＯＳＴメソッドによるデータ送信である。
【００４３】
プロトコル中継機能部２１は、ＡＰＩリクエストを受け付けると、アプリＡＰのアクセス権の問い合わせをアクセス管理機能部２２に問い合わせる（Ｔ１２）。このアクセス権の問い合わせの際には、アクセス元のＩＰアドレスと、アクセス先のＵＲＬとを伝える。
【００４４】
アクセス管理機能部２２は、プロトコル中継機能部２１からアクセス権の問い合わせを受信すると、アクセス元ＩＤ取得要求をアクセス元識別機能部２４に出力する（Ｔ１３）。
【００４５】
アクセス元識別機能部２４は、アクセス元のＩＰアドレスを使用して、ＤＮＳサーバ５１にホスト名の問い合わせを行ない（Ｔ１４）、ホスト名をＤＮＳサーバ５１から取得し（Ｔ１５）、ホスト名からアクセス元ＩＤを取得する（Ｔ１６）。
【００４６】
このようなＤＮＳサーバ５１によるアクセス元の特定は、ＩＰアドレスとアクセス元ＩＤとが１対１の関係であるような環境でのみ実施可能である。実施形態では、アプリＡＰとアクセス管理ゲートウェイ１１とが同一のＤｏｃｋｅｒ定義ネットワークに属するコンテナである、という前提であるため、このようなアクセス元の特定が可能となる。
【００４７】
次に、アクセス元識別機能部２４は、取得したアクセス元ＩＤをアクセス管理機能部２２に送信する（Ｔ１７）。アクセス管理機能部２２は、アクセス元識別機能部２４から取得したアクセス元ＩＤに基づいて、当該アクセス元ＩＤのアクセス管理ポリシーの取得要求をキャッシュ部２３に送信する（Ｔ１８）。
【００４８】
キャッシュ部２３は、アクセス管理ポリシーＤＢ３１から読み込まれたアクセス管理ポリシーのうち、当該アクセス元ＩＤのアクセス管理ポリシーをアクセス管理機能部２２に送信する（Ｔ１９）。
【００４９】
アクセス管理機能部２２は、受信した当該アクセス元ＩＤのアクセス管理ポリシーに基づいて、アクセス権限のチェックを行なう（Ｔ２０）。そして、アクセス権限の有無をプロトコル中継機能部２１に送信する（Ｔ２１）。
【００５０】
アクセス権限がある場合、プロトコル中継機能部２１はＡＰＩリクエストを送信先の処理系ＰＳに転送し（Ｔ３１）、ＡＰＩリクエストに対するＡＰＩレスポンスを受信する（Ｔ３２）。そして、プロトコル中継機能部２１は受信したＡＰＩレスポンスをアクセス元のアプリＡＰに転送する（Ｔ３３）。アクセス権限がない場合、プロトコル中継機能部２１はアクセス不可であることをアクセス元のアプリＡＰに転送する（Ｔ４１）。
【００５１】
次に、実施形態に係るＩｏＴ基盤Ｓのアクセス管理の第２動作について、図４のタイミングチャートを参照して説明する。第２動作は、第１動作と異なり、低レイヤプロトコル情報を用いてアクセス元ＩＤを取得しない場合のアクセス管理の動作を示すものである。
【００５２】
まず、システム管理者のコンピュータ４１からアクセス管理ポリシーＤＢ３１に、図２に示したアクセス管理ポリシーが投入される（Ｔ１）。なお、アクセス管理ポリシーには、図２に示したアクセス制御ポリシー、同時アクセス数制限のポリシー、優先制御のポリシーなどが含まれる。アクセス管理ポリシーは、アクセス管理ポリシーＤＢ３１に記憶される。
【００５３】
アクセス管理ポリシーＤＢ３１に記憶されたアクセス管理ポリシーは、キャッシュ部２３に読み込まれ（Ｔ２）、読み込まれたアクセス管理ポリシーはキャッシュ部２３のメモリに記憶される（Ｔ３）。
【００５４】
次に、アプリＡＰから処理系ＰＳへのＡＰＩリクエストがプロトコル中継機能部２１に送信される（Ｔ５１）。このＡＰＩリクエストは、例えば、ＨＴＴＰのＰＯＳＴメソッドによるデータ送信である。
【００５５】
プロトコル中継機能部２１は、ＡＰＩリクエストを受け付けると、アプリＡＰのアクセス権の問い合わせをアクセス管理機能部２２に問い合わせる（Ｔ５２）。このアクセス権の問い合わせの際には、アクセス元のＩＰアドレスと、アクセス先のＵＲＬとを伝える。
【００５６】
アクセス管理機能部２２は、プロトコル中継機能部２１からアクセス権の問い合わせを受信すると、アクセス元ＩＤの抽出を行なう（Ｓ５３）。この抽出は、例えば、ＨＴＴＰのヘッダにアクセス元ＩＤを記載しておき、アクセス管理機能部２２がそれを取得する。このように、低レイヤプロトコル情報を用いてアクセス元ＩＤを取得しない場合、プロトコル毎に、アクセス元ＩＤを通信内容のどこに記載するかを設計する必要がある。
【００５７】
アクセス管理機能部２２は、抽出したアクセス元ＩＤに基づいて、当該アクセス元ＩＤのアクセス管理ポリシーの取得要求をキャッシュ部２３に送信する（Ｔ５４）。
【００５８】
キャッシュ部２３は、アクセス管理ポリシーＤＢ３１から読み込まれたアクセス管理ポリシーのうち、当該アクセス元ＩＤのアクセス管理ポリシーをアクセス管理機能部２２に送信する（Ｔ５５）。
【００５９】
アクセス管理機能部２２は、受信した当該アクセス元ＩＤのアクセス管理ポリシーに基づいて、アクセス権限のチェックを行なう（Ｔ５６）。そして、アクセス権限の有無をプロトコル中継機能部２１に送信する（Ｔ５７）。
【００６０】
アクセス権限がある場合、プロトコル中継機能部２１はＡＰＩリクエストを送信先の処理系ＰＳに転送し（Ｔ３１）、ＡＰＩリクエストに対するＡＰＩレスポンスを受信する（Ｔ３２）。そして、プロトコル中継機能部２１は受信したＡＰＩレスポンスをアクセス元のアプリＡＰに転送する（Ｔ３３）。アクセス権限がない場合、プロトコル中継機能部２１はアクセス不可であることをアクセス元のアプリＡＰに転送する（Ｔ４１）。
【００６１】
従って、実施形態に係るＩｏＴ基盤Ｓのアクセス管理装置によれば、図６に示すように各種機能へのアクセスを一元的に中継するゲートウェイ１１を配し、アクセス管理を行なうので、図７に示すように従来の機能毎に個別にアクセス管理を行なう場合と比較して、省リソース、低運用コストでアクセス管理を実現することができる。
【００６２】
図８は、従来の個別対応のアクセス管理と、本発明の一元管理のアクセス管理との効果を説明するための図である。
【００６３】
同図に示すように、実施形態によれば、個別対応のアクセス管理に比して、アクセス管理の運用コストを低減することができる。ポリシーを個別のアクセス管理機構に投入する必要がなく、一元的に追加、更新、削除等をすることができるからである。従って、ポリシーの不整合リスクは、実施形態のアクセス管理では存在しない。
【００６４】
また、メモリなどの消費リソースを低減することができる。複数の処理系ＰＳやプロトコルに対し、アクセス管理に用いるリソースを共通化するためである。
【００６５】
さらに、アプリＡＰやデバイスＤＢの開発負担を軽減することができる。統一的な方式でアクセス管理が行なわれるため、アプリＡＰやデバイスＤＢの開発者の学習コストが低減されるからである。
【００６６】
さらに、処理系ＰＳやプロトコルの追加が容易になる。個別のアクセス管理機構を用意する必要がなく、アクセス管理機能部２２は共通化されているため、プロトコル中継機能部２１だけ用意すれば良いからである。
【００６７】
さらに、アクセス元ＩＤ（識別情報）を上位プロトコル情報に依存せずに取得するため、プロトコル毎に「アクセス元ＩＤを通信内容のどこに記載するか」を設計する必要がない。
【００６８】
さらに、アクセス管理ポリシーをオンメモリでキャッシュするため、高速なアクセス管理処理を実現することができる。
【００６９】
従って、実施形態によれば、アクセス管理機構を処理系やプロトコルから独立したゲートウェイとして構成し、設定されたアクセス管理ポリシーに基づいて一元的なアクセス管理を実現することができるアクセス管理装置及びアクセス管理方法を提供できる。
【００７０】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【図１】
2019059034.tif 000003
【図２】
2019059034.tif 000004
【図３】
2019059034.tif 000005
【図４】
2019059034.tif 000006
【図５】
2019059034.tif 000007
【図６】
2019059034.tif 000008
【図７】
2019059034.tif 000009
【図８】
2019059034.tif 000010
【手続補正書】
【提出日】平成31年1月10日(2019.1.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
アクセス元と、前記アクセス元からのアクセス要求に対する処理を行なう複数の処理系との間に接続され、前記アクセス元からのアクセス要求を受信し、前記複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なうアクセス管理機能部を有するゲートウェイを具備し、
前記アクセス管理ポリシーは、前記アクセス元と、前記アクセス元のアクセス先と、前記アクセス要求に対するアクセス制限内容とが関連付けられている、
アクセス管理装置。
【請求項２】
前記ゲートウェイは、
前記アクセス元のＩＰアドレスに基づいて、前記アクセス元の識別情報を取得し、前記取得したアクセス元の識別情報を前記アクセス管理機能部に送信するアクセス元識別機能部をさらに具備する、請求項１記載のアクセス管理装置。
【請求項３】
前記アクセス管理ポリシーは、前記ゲートウェイのキャッシュメモリ上に記憶される、請求項１記載のアクセス管理装置。
【請求項４】
前記ゲートウェイは、前記アクセス管理機能部によってアクセス要求が認められた場合、前記複数の処理系と前記アクセス元との間のプロトコル変換を行なうプロトコル中継機能部をさらに具備する、請求項１記載のアクセス管理装置。
【請求項５】
前記アクセス制限内容は、
前記アクセス元の前記アクセス先への可能な操作である、請求項１記載のアクセス管理装置。
【請求項６】
前記アクセス制限内容は、
前記アクセス元の前記アクセス先への同時アクセス数である、
請求項１記載のアクセス管理装置。
【請求項７】
前記アクセス制限内容は、
前記アクセス元の優先度である、
請求項１記載のアクセス管理装置。
【請求項８】
アクセス元と、前記アクセス元からのアクセス要求に対する処理を行なう複数の処理系との間に接続され、前記アクセス元からのアクセス要求を受信し、
前記複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なうアクセス管理機能部を有するゲートウェイを具備し、前記アクセス管理ポリシーは、前記アクセス元と、前記アクセス元のアクセス先と、前記アクセス要求に対するアクセス制限内容とが関連付けられている、アクセス管理装置におけるアクセス管理方法において、
前記アクセス管理機能部は、
前記アクセス元からのアクセス要求を受信し、
記憶部に記憶された前記アクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なう、アクセス管理方法。
【請求項９】
前記アクセス元のＩＰアドレスに基づいて、前記アクセス元の識別情報を取得し、前記取得したアクセス元の識別情報を前記アクセス管理機能部に送信する処理を、さらに行う、請求項８記載のアクセス管理方法。
【請求項１０】
前記ゲートウェイのキャッシュメモリ上に前記アクセス管理ポリシーを記憶する処理を、さらに行う、請求項８記載のアクセス管理方法。
【請求項１１】
前記アクセス管理機能部によってアクセス要求が認められた場合、前記複数の処理系と、前記アクセス元との間のプロトコル変換を、さらに行なう、請求項８記載のアクセス管理方法。
【請求項１２】
前記アクセス制限内容は、
前記アクセス元の前記アクセス先への可能な操作である、請求項８記載のアクセス管理方法。
【請求項１３】
前記アクセス制限内容は、
前記アクセス元の前記アクセス先への同時アクセス数である、請求項８記載のアクセス管理方法。
【請求項１４】
前記アクセス制限内容は、
前記アクセス元の優先度である、請求項８記載のアクセス管理方法。
【請求項１５】
アクセス元と、前記アクセス元からのアクセス要求に対する処理を行なう複数の処理系との間に接続されたアクセス管理機能部を有するゲートウェイを具備するアクセス管理装置におけるアクセス管理方法を実行するプログラムにおいて、
前記プログラムは、前記アクセス管理機能部に、
前記アクセス元からのアクセス要求を受信させ、
前記複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なわせ、前記アクセス管理ポリシーは、前記アクセス元と、前記アクセス元のアクセス先と、前記アクセス要求に対するアクセス制限内容とが関連付けられている、
プログラム。
【国際調査報告】
2019059034.tif 000011
2019059034.tif 000012
2019059034.tif 000013