技術 アクセス管理装置及びアクセス管理方法

0001

本発明は、アクセス管理装置及びアクセス管理方法に関する。

0002

ＩｏＴ（Internet of Things）サービスを容易に構築可能とする基盤（ＩｏＴ基盤）が注目を集めている。ＩｏＴ基盤においては、多様なサービスを実現するため、異種の処理系（データ管理、データ配信等）を備え、また、これら処理系に適した異種のプロトコル（Hypertext Transfer Protocol（ＨＴＴＰ）、Message Queueing Telemetry Transport（ＭＱＴＴ）等）に対応することが想定されている。

0003

従って、これら処理系に入出力されるデータを管理するニーズが存在する。ここで、「管理」とは、アクセス制御、同時アクセス制限、優先制御などを含む。また、処理系に入出力されるデータには、機微なデータが含まれ得る。機微なデータとしては、例えば、製造業における生産工程に関するデータ、個人のバイタルデータなどである。

0004

従来、ＩｏＴ基盤では、各処理系がそれぞれ、アプリケーションプログラム（以下、「アプリ」という。）やデバイスに対応するインターフェイスを備えている。このため、これらインターフェイス毎に、個別にアクセス管理機構を実装する（＝個別対応）ことで、アクセス管理を実現することが可能である。図７は、従来のＩｏＴ基盤Ｓのアクセス管理装置の概要を示す図である。同図に示すように、アクセス元ＡＳ−１〜ＡＳ−Ｎに対応するＩｏＴ基盤Ｓの各処理系ＰＳ−１〜ＰＳ−Ｎは、アクセス管理機構を有している。

0005

図５は、アクセス元であるアプリＡＰ−１〜ＡＰ−３及びデバイスＤＢ−１〜ＤＢ−５と各処理系ＰＳ−１〜ＰＳ−４との関係を示す図である。

0006

同図において、アクセス元であるアプリＡＰ−１〜ＡＰ−３及びデバイスＤＢ−１〜ＤＢ−５は、ＩｏＴ基盤Ｓのデータ処理系ＰＳ−１〜ＰＳ−４にアクセス可能である。各データ処理系ＰＳ−１〜ＰＳ−４は、アクセス元であるアプリＡＰ−１〜ＡＰ−３及びデバイスＤＢ−１〜ＤＢ−５に対応するインターフェイスを備えており、各インターフェイス毎にアクセス管理機構を実装している。

0007

ここで、データ処理系ＰＳ−１はデータ管理に関する処理、データ処理系ＰＳ−２はデータ配信に関する処理、データ処理系ＰＳ−３はデータ分析に関する処理、データ処理系ＰＳ−４はデバイス制御に関する処理を行なう。また、デバイスＤＢ−１は車、デバイスＤＢ−２、デバイスＤＢ−３はスマートフォン、デバイスＤＢ−４はオシロスコープ、デバイスＤＢ−５はアクチュエータを示す。

0008

プロトコルと処理系の組み合わせ毎にアクセス管理機構を用意するものとして、例えば、非特許文献１には、ＲＥＳＴＡＰＩに関する市中のアクセス制御技術が開示されており、非特許文献２には、ＭＱＴＴブローカに関する市中のアクセス制御技術が開示されている。

0009

"Ｗｈａｔ ｉｓ Ｋｏｎｇ" 、［ｏｎｌｉｎｅ］、Ｋｏｎｇ−Ｏｐｅｎ−ｓｏｕｒｃｅＡＰＩ Ｍｎａｇｅｍｅｎｔ ａｎｄ Ｍｉｃｒｏｓｅｒｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ、［平成２９年５月１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐｓ：／／ｇｅｔｋｏｎｇ．ｏｒｇ／ａｂｏｕｔ／＞
”ｍｏｓｑｕｉｔｔｏ．ｃｏｎｆ−ｔｈｅ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｆｉｌｅ ｆｏｒ ｍｏｓｑｕｉｔｔｏ”、［平成２９年５月１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｍｏｓｑｕｉｔｔｏ．ｏｒｇ／ｍａｎ／ｍｏｓｑｕｉｔｔｏ−ｃｏｎｆ−５．ｈｔｍｌ＞

0010

しかしながら、従来のアクセス管理機構では、アクセス管理機構毎に設定管理が必要となり、運用コストが大きくなってしまうという問題がある。また、アプリ側でアクセス管理機構毎の対応が必要となり、アプリ開発の負担が大きい。さらに、アクセス管理機構間の管理ポリシー（アクセス制御ルール等）の不整合などのリスクも増大する。

0011

さらに、上述のように、アクセス管理機構は、機微なデータを取り扱うため、アプリやデバイスから各処理系へのアクセスに対し、ＩｏＴ基盤を導入するユーザ（例えば、製造業では、工場管理者）のセキュリティポリシーに基づいて、アクセスの可否等を制御する必要がある。

0012

本発明は、上記実情に鑑みてなされたものであり、アクセス管理機構を処理系やプロトコルから独立したゲートウェイとして構成できるようにし、設定されたアクセス管理ポリシーに基づいて一元的なアクセス管理を実現することができるアクセス管理装置及びアクセス管理方法を提供することを目的とする。

0013

本発明の第１態様は、アクセス管理装置が、アクセス元と、前記アクセス元からのアクセス要求に対する処理を行なう複数の処理系との間に接続され、前記アクセス元からのアクセス要求を受信し、前記複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なうアクセス管理機能部を有するゲートウェイを具備するようにしたものである。

0014

本発明の第２態様は、前記ゲートウェイが、前記アクセス元のＩＰアドレスに基づいて、前記アクセス元の識別情報を取得し、前記取得したアクセス元の識別情報を前記アクセス管理機能部に送信するアクセス元識別機能部をさらに具備するようにしたものである。

0015

本発明の第３態様は、前記アクセス管理ポリシーを、前記ゲートウェイのキャッシュメモリ上に記憶するようにしたものである。

0016

本発明の第４態様は、前記ゲートウェイは、前記アクセス管理機能部によってアクセス要求が認められた場合、前記複数の処理系と前記アクセス元との間のプロトコル変換を行なうプロトコル中継機能部をさらに具備するようにしたものである。

0017

この発明の第１の態様によれば、複数の処理系に対して、ゲートウェイによりアクセス管理を一元的に管理することにより、運用コストを低減することができるとともに、アクセス管理ポリシーの不整合リスクを防ぐことができる。

0018

この発明の第２の態様によれば、低レイヤプロトコル情報（ＩＰアドレス）を用いてアクセス元ＩＤを取得することで、上位レイヤプロトコルに依存しないアクセス元識別情報を実現することができる。

0019

この発明の第３の態様によれば、アクセス管理ポリシーをオンメモリでキャッシュするため、高速なアクセス管理処理を実現することができる。

0020

この発明の第４の態様によれば、プロトコル中継機能部は、アクセス管理機能部とは別に設けられているので、アクセス管理のみを一元的に管理することができる。

0021

本発明の各態様によれば、アクセス管理機構を処理系やプロトコルから独立したゲートウェイとして構成することができ、設定されたアクセス管理ポリシーに基づいて一元的なアクセス管理を実現することができるアクセス管理装置及びアクセス管理方法を提供できる。

0022

本発明の実施形態のＩｏＴ基盤Ｓの構成を説明するための図である。
アクセス管理ポリシーＤＢ３１に格納されるアクセス管理ポリシーの一例を示す図である。
実施形態に係るＩｏＴ基盤Ｓのアクセス管理の第１動作について説明するためのタイミングチャートである。
実施形態に係るＩｏＴ基盤Ｓのアクセス管理の第２動作について説明するためのタイミングチャートである。
アクセス元であるアプリＡＰ−１〜ＡＰ−３及びデバイスＤＢ−１〜ＤＢ−５と各処理系ＰＳ−１〜ＰＳ−４との関係を示す図である。
実施形態に係るＩｏＴ基盤Ｓのアクセス管理装置の概要を示す図である。
従来のＩｏＴ基盤Ｓのアクセス管理装置の概要を示す図である。
従来の個別対応のアクセス管理と、本発明の一元管理のアクセス管理との効果を説明するための図である。

0023

以下、図面を参照して、本発明の実施形態について説明する。なお、実施形態において、構成要素を区別して説明する必要がない場合には、ハイフンを省略して説明する。例えば、アクセス元ＡＳ−１、ＡＳ−２、…、ＡＳ−ｎを区別して説明する必要がない場合には、ハイフンを省略して「ＡＳ」として説明する。他の構成要素についても同様に説明する。

0024

図１は、本発明の実施形態のＩｏＴ基盤Ｓの構成を説明するための図である。同図に示すように、ＩｏＴ基盤Ｓは、複数の処理系ＰＳ−１〜ＰＳ−Ｎ、複数の処理系ＰＳ−１〜ＰＳ−Ｎに対応して設けられたプロトコルインターフェイスＩＦ−１〜ＩＦ−Ｎ、アクセス管理ゲートウェイ１１、アクセス管理ポリシーＤＢ３１を有する。

0025

アクセス管理ゲートウェイ１１は、アプリやデバイスなどの複数のアクセス元ＡＳ−１〜ＡＳ−Ｎと、複数の処理系ＰＳ−１〜ＰＳ−Ｎとの間に配置され、プロトコル中継機能部２１、アクセス管理機能部２２、キャッシュ部２３及びアクセス元識別機能部２４を有する。

0026

プロトコル中継機能部２１は、処理系ＰＳ−１〜ＰＳ−Ｎと、プロトコルの組み合わせ毎に存在する。アプリやデバイスからのアクセスを処理系ＰＳ−１〜ＰＳ−Ｎに中継する。

0027

アクセス管理機能部２２は、アクセス管理機能毎に存在する。アクセス管理機能部２２は、プロトコル中継機能部２１に対し、中継時に挿入するアクセス管理処理を提供する機能である。例えば、アクセス制御の場合、プロトコル中継機能部２１はアクセスの中継可否をアクセス管理機能部２２に問い合わせてから中継を行なう。

0028

キャッシュ部２３は、アクセス管理ポリシーＤＢ３１の情報をメモリ上にキャッシュする機能である。

0029

アクセス元識別機能部２４は、低レイヤプロトコル情報（ＩＰアドレス、ＭＡＣアドレス等）を用いて、アクセス元ＡＳ−１〜ＡＳ−Ｎの識別子（アプリＩＤ、デバイスＩＤ）を取得する機能である。

0030

アクセス管理ポリシーＤＢ３１は、アクセス制御のルールなどのアクセス管理ポリシーを格納するデータベースである。アクセス管理ポリシーは、システム運用者のコンピュータ４１から設定される。

0031

図２は、アクセス管理ポリシーＤＢ３１に格納されるアクセス管理ポリシーの一例を示す図である。

0032

同図に示すように、「アクセス制御のポリシー」としては、アクセス元、アクセス先及び可能な操作の種類が関連付けて記憶されている。例えば、アクセス元がアプリＡＰ−１、アクセス先が処理系ＰＳ−１のデータＸである場合、可能な操作は参照、更新の操作のみが許可される。また、アクセス元がアプリＡＰ−１、アクセス先が処理系ＰＳ−１のデータＹである場合、可能な操作は参照の操作のみが許可される。アクセス元がアプリＡＰ−１、アクセス先が処理系ＰＳ−２のデータＺである場合、可能な操作は参照、更新、削除の操作が許可される。

0033

「同時アクセス数制限のポリシー」としては、アクセス先、アクセス元及び同時アクセス数上限が関連付けて記憶されている。例えば、アクセス先が処理系ＰＳ−１、アクセス元がアプリＡＰ−１、アプリＡＰ−２である場合、同時アクセス上限は５リクエスト／秒である。アクセス先が処理系ＰＳ−１、アクセス元がデバイスＤＢ−３である場合、同時アクセス上限は１０リクエスト／秒である。アクセス先が処理系ＰＳ−１、アクセス元がアプリＡＰ−４、ＡＰ−５である場合、同時アクセス上限は１５リクエスト／秒である。

0034

「優先制御のポリシー」としては、アクセス元及び優先度が関連付けて記憶されている。例えば、アクセス元がアプリＡＰ−１の場合、優先度は「高」であり、アクセス元がアプリＡＰ−２の場合、優先度は「中」である。

0035

次に、実施形態に係るＩｏＴ基盤Ｓのアクセス管理の第１動作について、図３のタイミングチャートを参照して説明する。なお、アクセス管理の動作の説明に際し、以下の環境を想定する。

0036

・アプリＡＰやデバイスＤＢとアクセス管理ゲートウェイ１１がそれぞれＤｏｃｋｅｒコンテナであり、同一のＤｏｃｋｅｒ定義ネットワーク上に配置されている。

0037

・ 各アプリやデバイスを一意に表わすＩＤが、各アプリやデバイスのコンテナ名として設定されている。

0038

・ この時、アクセス管理ゲートウェイ１１は、アプリＡＰやデバイスＤＢからのアクセスを受信時、それらアクセス元のＩＰアドレスをＤＮＳ逆引きすることでコンテナ名（＝アクセス元ＩＤ）を取得することが可能である。

0039

このような想定のもと、あるアプリＡＰがＲＥＳＴＡＰＩサーバに対してアクセスする際の、アクセス制御のシーケンスを説明する。なお、図３においては、アプリＡＰからＡＰＩリクエストをする場合について示しているが、デバイスＤＢの場合であっても、同様のシーケンスとなる。

0040

まず、システム管理者のコンピュータ４１からアクセス管理ポリシーＤＢ３１に、図２に示したアクセス管理ポリシーが投入される（Ｔ１）。なお、アクセス管理ポリシーには、図２に示したアクセス制御ポリシー、同時アクセス数制限のポリシー、優先制御のポリシーなどが含まれる。アクセス管理ポリシーは、アクセス管理ポリシーＤＢ３１に記憶される。

0041

アクセス管理ポリシーＤＢ３１に記憶されたアクセス管理ポリシーは、キャッシュ部２３に読み込まれ（Ｔ２）、読み込まれたアクセス管理ポリシーはキャッシュ部２３のメモリに記憶される（Ｔ３）。

0042

次に、アプリＡＰから処理系ＰＳへのＡＰＩリクエストがプロトコル中継機能部２１に送信される（Ｔ１１）。このＡＰＩリクエストは、例えば、ＨＴＴＰのＰＯＳＴメソッドによるデータ送信である。

0043

プロトコル中継機能部２１は、ＡＰＩリクエストを受け付けると、アプリＡＰのアクセス権の問い合わせをアクセス管理機能部２２に問い合わせる（Ｔ１２）。このアクセス権の問い合わせの際には、アクセス元のＩＰアドレスと、アクセス先のＵＲＬとを伝える。

0044

アクセス管理機能部２２は、プロトコル中継機能部２１からアクセス権の問い合わせを受信すると、アクセス元ＩＤ取得要求をアクセス元識別機能部２４に出力する（Ｔ１３）。

0045

アクセス元識別機能部２４は、アクセス元のＩＰアドレスを使用して、ＤＮＳサーバ５１にホスト名の問い合わせを行ない（Ｔ１４）、ホスト名をＤＮＳサーバ５１から取得し（Ｔ１５）、ホスト名からアクセス元ＩＤを取得する（Ｔ１６）。

0046

このようなＤＮＳサーバ５１によるアクセス元の特定は、ＩＰアドレスとアクセス元ＩＤとが１対１の関係であるような環境でのみ実施可能である。実施形態では、アプリＡＰとアクセス管理ゲートウェイ１１とが同一のＤｏｃｋｅｒ定義ネットワークに属するコンテナである、という前提であるため、このようなアクセス元の特定が可能となる。

0047

次に、アクセス元識別機能部２４は、取得したアクセス元ＩＤをアクセス管理機能部２２に送信する（Ｔ１７）。アクセス管理機能部２２は、アクセス元識別機能部２４から取得したアクセス元ＩＤに基づいて、当該アクセス元ＩＤのアクセス管理ポリシーの取得要求をキャッシュ部２３に送信する（Ｔ１８）。

0048

キャッシュ部２３は、アクセス管理ポリシーＤＢ３１から読み込まれたアクセス管理ポリシーのうち、当該アクセス元ＩＤのアクセス管理ポリシーをアクセス管理機能部２２に送信する（Ｔ１９）。

0049

アクセス管理機能部２２は、受信した当該アクセス元ＩＤのアクセス管理ポリシーに基づいて、アクセス権限のチェックを行なう（Ｔ２０）。そして、アクセス権限の有無をプロトコル中継機能部２１に送信する（Ｔ２１）。

0050

アクセス権限がある場合、プロトコル中継機能部２１はＡＰＩリクエストを送信先の処理系ＰＳに転送し（Ｔ３１）、ＡＰＩリクエストに対するＡＰＩレスポンスを受信する（Ｔ３２）。そして、プロトコル中継機能部２１は受信したＡＰＩレスポンスをアクセス元のアプリＡＰに転送する（Ｔ３３）。アクセス権限がない場合、プロトコル中継機能部２１はアクセス不可であることをアクセス元のアプリＡＰに転送する（Ｔ４１）。

0051

次に、実施形態に係るＩｏＴ基盤Ｓのアクセス管理の第２動作について、図４のタイミングチャートを参照して説明する。第２動作は、第１動作と異なり、低レイヤプロトコル情報を用いてアクセス元ＩＤを取得しない場合のアクセス管理の動作を示すものである。

0052

まず、システム管理者のコンピュータ４１からアクセス管理ポリシーＤＢ３１に、図２に示したアクセス管理ポリシーが投入される（Ｔ１）。なお、アクセス管理ポリシーには、図２に示したアクセス制御ポリシー、同時アクセス数制限のポリシー、優先制御のポリシーなどが含まれる。アクセス管理ポリシーは、アクセス管理ポリシーＤＢ３１に記憶される。

0053

アクセス管理ポリシーＤＢ３１に記憶されたアクセス管理ポリシーは、キャッシュ部２３に読み込まれ（Ｔ２）、読み込まれたアクセス管理ポリシーはキャッシュ部２３のメモリに記憶される（Ｔ３）。

0054

次に、アプリＡＰから処理系ＰＳへのＡＰＩリクエストがプロトコル中継機能部２１に送信される（Ｔ５１）。このＡＰＩリクエストは、例えば、ＨＴＴＰのＰＯＳＴメソッドによるデータ送信である。

0055

プロトコル中継機能部２１は、ＡＰＩリクエストを受け付けると、アプリＡＰのアクセス権の問い合わせをアクセス管理機能部２２に問い合わせる（Ｔ５２）。このアクセス権の問い合わせの際には、アクセス元のＩＰアドレスと、アクセス先のＵＲＬとを伝える。

0056

アクセス管理機能部２２は、プロトコル中継機能部２１からアクセス権の問い合わせを受信すると、アクセス元ＩＤの抽出を行なう（Ｓ５３）。この抽出は、例えば、ＨＴＴＰのヘッダにアクセス元ＩＤを記載しておき、アクセス管理機能部２２がそれを取得する。このように、低レイヤプロトコル情報を用いてアクセス元ＩＤを取得しない場合、プロトコル毎に、アクセス元ＩＤを通信内容のどこに記載するかを設計する必要がある。

0057

アクセス管理機能部２２は、抽出したアクセス元ＩＤに基づいて、当該アクセス元ＩＤのアクセス管理ポリシーの取得要求をキャッシュ部２３に送信する（Ｔ５４）。

0058

キャッシュ部２３は、アクセス管理ポリシーＤＢ３１から読み込まれたアクセス管理ポリシーのうち、当該アクセス元ＩＤのアクセス管理ポリシーをアクセス管理機能部２２に送信する（Ｔ５５）。

0059

アクセス管理機能部２２は、受信した当該アクセス元ＩＤのアクセス管理ポリシーに基づいて、アクセス権限のチェックを行なう（Ｔ５６）。そして、アクセス権限の有無をプロトコル中継機能部２１に送信する（Ｔ５７）。

0060

アクセス権限がある場合、プロトコル中継機能部２１はＡＰＩリクエストを送信先の処理系ＰＳに転送し（Ｔ３１）、ＡＰＩリクエストに対するＡＰＩレスポンスを受信する（Ｔ３２）。そして、プロトコル中継機能部２１は受信したＡＰＩレスポンスをアクセス元のアプリＡＰに転送する（Ｔ３３）。アクセス権限がない場合、プロトコル中継機能部２１はアクセス不可であることをアクセス元のアプリＡＰに転送する（Ｔ４１）。

0061

従って、実施形態に係るＩｏＴ基盤Ｓのアクセス管理装置によれば、図６に示すように各種機能へのアクセスを一元的に中継するゲートウェイ１１を配し、アクセス管理を行なうので、図７に示すように従来の機能毎に個別にアクセス管理を行なう場合と比較して、省リソース、低運用コストでアクセス管理を実現することができる。

0062

図８は、従来の個別対応のアクセス管理と、本発明の一元管理のアクセス管理との効果を説明するための図である。

0063

同図に示すように、実施形態によれば、個別対応のアクセス管理に比して、アクセス管理の運用コストを低減することができる。ポリシーを個別のアクセス管理機構に投入する必要がなく、一元的に追加、更新、削除等をすることができるからである。従って、ポリシーの不整合リスクは、実施形態のアクセス管理では存在しない。

0064

また、メモリなどの消費リソースを低減することができる。複数の処理系ＰＳやプロトコルに対し、アクセス管理に用いるリソースを共通化するためである。

0065

さらに、アプリＡＰやデバイスＤＢの開発負担を軽減することができる。統一的な方式でアクセス管理が行なわれるため、アプリＡＰやデバイスＤＢの開発者の学習コストが低減されるからである。

0066

さらに、処理系ＰＳやプロトコルの追加が容易になる。個別のアクセス管理機構を用意する必要がなく、アクセス管理機能部２２は共通化されているため、プロトコル中継機能部２１だけ用意すれば良いからである。

0067

さらに、アクセス元ＩＤ（識別情報）を上位プロトコル情報に依存せずに取得するため、プロトコル毎に「アクセス元ＩＤを通信内容のどこに記載するか」を設計する必要がない。

0068

さらに、アクセス管理ポリシーをオンメモリでキャッシュするため、高速なアクセス管理処理を実現することができる。

0069

従って、実施形態によれば、アクセス管理機構を処理系やプロトコルから独立したゲートウェイとして構成し、設定されたアクセス管理ポリシーに基づいて一元的なアクセス管理を実現することができるアクセス管理装置及びアクセス管理方法を提供できる。

0070

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれる。