JPWO2019059034A1 - アクセス管理装置及びアクセス管理方法 - Google Patents

Abstract

本発明によれば、複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて一元的なアクセス管理を実現することができるアクセス管理装置を提供する。本発明のアクセス管理装置は、アクセス元（ＡＳ）と複数の処理系（ＰＳ）との間に接続され、アクセス元（ＡＳ）からのアクセス要求を受信し、設定されたアクセス管理ポリシーに基づいて、アクセス要求の制御を行なうアクセス管理機能部（２２）を有するゲートウェイ（１１）とを具備する。

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (15)

1. アクセス元と、前記アクセス元からのアクセス要求に対する処理を行なう複数の処理系との間に接続され、前記アクセス元からのアクセス要求を受信し、前記複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なうアクセス管理機能部を有するゲートウェイを具備するアクセス管理装置。
2. 前記ゲートウェイは、
   前記アクセス元のＩＰアドレスに基づいて、前記アクセス元の識別情報を取得し、前記取得したアクセス元の識別情報を前記アクセス管理機能部に送信するアクセス元識別機能部をさらに具備する、請求項１記載のアクセス管理装置。
3. 前記アクセス管理ポリシーは、前記ゲートウェイのキャッシュメモリ上に記憶される、請求項１記載のアクセス管理装置。
4. 前記ゲートウェイは、前記アクセス管理機能部によってアクセス要求が認められた場合、前記複数の処理系と前記アクセス元との間のプロトコル変換を行なうプロトコル中継機能部をさらに具備する、請求項１記載のアクセス管理装置。
5. 前記アクセス管理ポリシーは、
   前記アクセス元と、前記アクセス元のアクセス先と、前記アクセス元の前記アクセス先への可能な操作とが関連付けられたアクセス制御ポリシーを有する、請求項１記載のアクセス管理装置。
6. 前記アクセス管理ポリシーは、
   前記アクセス元のアクセス先と、前記アクセス元と、前記アクセス元の前記アクセス先への同時アクセス数情報とが関連付けられた同時アクセス数制限ポリシーを有する、請求項１記載のアクセス管理装置。
7. 前記アクセス管理ポリシーは、
   前記アクセス元と、前記アクセス元の前記優先度とが関連付けられた優先制御ポリシーを有する、請求項１記載のアクセス管理装置。
8. アクセス元と、前記アクセス元からのアクセス要求に対する処理を行なう複数の処理系との間に接続され、前記アクセス元からのアクセス要求を受信し、
   前記複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なうアクセス管理機能部を有するゲートウェイを具備するアクセス管理装置におけるアクセス管理方法において、
   前記アクセス管理機能部は、
   前記アクセス元からのアクセス要求を受信し、
   前記記憶部に記憶されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なう、アクセス管理方法。
9. 前記アクセス元のＩＰアドレスに基づいて、前記アクセス元の識別情報を取得し、前記取得したアクセス元の識別情報を前記アクセス管理機能部に送信する処理を、さらに行う、請求項８記載のアクセス管理方法。
10. 前記ゲートウェイのキャッシュメモリ上に前記アクセス管理ポリシーを記憶する処理を、さらに行う、請求項８記載のアクセス管理方法。
11. 前記アクセス管理機能部によってアクセス要求が認められた場合、前記複数の処理系と、前記アクセス元との間のプロトコル変換を、さらに行なう、請求項８記載のアクセス管理方法。
12. 前記アクセス管理ポリシーは、
    前記アクセス元と、前記アクセス元のアクセス先と、前記アクセス元の前記アクセス先への可能な操作とが関連付けられたアクセス制御ポリシーを有する、請求項８記載のアクセス管理方法。
13. 前記アクセス管理ポリシーは、
    前記アクセス元のアクセス先と、前記アクセス元と、前記アクセス元の前記アクセス先への同時アクセス数情報とが関連付けられた同時アクセス数制限ポリシーを有する、請求項８記載のアクセス管理方法。
14. 前記アクセス管理ポリシーは、
    前記アクセス元と、前記アクセス元の前記優先度とが関連付けられた優先制御ポリシーを有する、請求項８記載のアクセス管理方法。
15. アクセス元と、前記アクセス元からのアクセス要求に対する処理を行なう複数の処理系との間に接続されたアクセス管理機能部を有するゲートウェイを具備するアクセス管理装置におけるアクセス管理方法を実行するプログラムにおいて、
    前記プログラムは、前記アクセス機能管理部に、
    前記アクセス元からのアクセス要求を受信させ、
    前記複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なわせる、
    プログラム。

Images