JP2009181427A - アクセス管理システム及びアクセス管理方法 - Google Patents

Abstract

【課題】多種のアクセス制限を柔軟に組み合わせる。
【解決手段】
ユーザーからの情報資源に対するアクセス要求を取得するアクセス要求取得部１１と、アクセス権限の有無を判定する複数の判定基準の各々に対応する複数の判定プログラムを格納する判定プログラム格納部１４と、判定基準との比較対象となるユーザー情報を定義するユーザー情報定義テーブル１２３と、アクセス要求に対して実行される判定プログラムおよび実行順序を定義する実行順序定義テーブル１２１と、アクセス要求に基づいてユーザー情報定義テーブル１２３からユーザー情報、実行順序定義テーブル１２１から実行される判定プログラムおよび実行順序を取得すると共に判定プログラムを順次実行し、各々の判定結果の論理和および論理積の組合せによってユーザーのアクセス権限の有無を判定するアクセス権限判定部１３を有するアクセス管理システム。
【選択図】図１

Description

本発明は、ユーザーの情報資源に対するアクセス権限の有無を判定するアクセス管理システムおよびアクセス管理方法に関する。

一般に、重要な情報資源（リソース）に対してアクセス要求がなされた場合には、アクセス要求を行ったユーザーの登録情報に基づいてアクセス権限の有無が判定される。例えば、情報資源が人事に関する情報の場合には、人事部に所属する社員はアクセス権限を有するが、営業部の社員はアクセス権限が無いと判定する。このような判定処理は、情報資源へのアクセス許諾を受ける者とアクセス権の内容を対応付けしたアクセス制御リストを参照することで行われ、このアクセス制御リストはデータベースに予め登録されている（例えば特許文献１参照）。
特開２００１−１９５２９４号公報

しかしながら、上記の技術においては、複数のアクセス制限を組み合わせる際の手法が統一されず、各アクセス制限の導入方法が異なっていた。例えば、各アクセス制限に対応する判定プログラムを順次実行する場合には、主処理のプログラムの中で判定プログラムの実行順序や実行条件などが定義されていた。このため、判定プログラムの実行順序や実行条件などを変更するためには各プログラムのソースコードの大幅な修正を要するという問題があった。

また、機能毎に異なるアクセス制限を論理積（AND条件）および論理和（OR条件）を組み合わせて行うことが難しく、セキュリティの強度を柔軟に変更することが困難であった。

そこで、本発明は、従来技術の問題に鑑み、機能毎に多種のアクセス制限を柔軟に組み合わせることが可能なアクセス管理システムおよびアクセス管理方法を提供することを目的とする。

本発明に係るアクセス管理システムは、情報資源を格納する情報資源格納部と、ユーザーからの情報資源に対するアクセス要求を取得するアクセス要求取得部と、ユーザーの情報資源に対するアクセス権限の有無を判定する複数の判定基準の各々に対応する複数の判定プログラムを格納する判定プログラム格納部と、判定基準との比較対象となるユーザー情報を定義するユーザー情報定義テーブルと、アクセス要求に対して実行される判定プログラムおよび実行順序を定義する実行順序定義テーブルと、アクセス要求に基づいてユーザー情報定義テーブルからユーザー情報、実行順序定義テーブルから実行される判定プログラムおよび実行順序を取得し、これらの取得された情報に基づいて判定プログラムを順次実行し、それぞれの判定結果の論理和および論理積の組合せによってユーザーのアクセス権限の有無を判定するアクセス権限判定部と、を有することを特徴とする。

本発明に係るアクセス管理方法は、コンピューター内の情報資源に対するユーザーからのアクセス要求を取得するアクセス要求取得ステップと、ユーザーの情報資源に対するアクセス権限の有無を判定する複数の判定基準の各々に対応する複数の判定プログラムを格納する判定プログラム格納ステップと、判定基準との比較対象となるユーザー情報を定義するユーザー情報定義ステップと、アクセス要求に対して実行される判定プログラムおよび実行順序を定義する実行順序定義ステップと、アクセス要求に基づいてユーザー情報定義ステップで定義されたユーザー情報、実行順序定義ステップで定義された実行される判定プログラムおよび実行順序を取得し、これらの取得された情報に基づいて判定プログラムを順次実行し、それぞれの判定結果の論理和および論理積の組合せによってユーザーのアクセス権限の有無を判定するアクセス権限判定ステップと、を有することを特徴とする。

本発明によれば、機能毎に多種のアクセス制限を組み合わせることが可能なアクセス管理システムおよびアクセス管理方法が提供される。

以下、本発明の実施形態について図面を用いて説明する。図１は、本発明の一実施形態に係るアクセス管理システムの全体構成例を示す図である。同図に示されるように、本実施形態に係るアクセス管理システムは、アクセス管理サーバ１とクライアント端末２から構成されており、アクセス管理サーバ１に複数台のクライアント端末２がネットワーク３を介して接続されている。

アクセス管理サーバ１は、アクセス要求取得部１１、データベース部１２、アクセス権限判定部１３、判定プログラム格納部１４、実行処理部１５、および情報資源格納部１６を有するコンピュータである。

アクセス要求取得部１１は、ネットワーク３を介してクライアント端末２から情報資源に対するアクセス要求を取得する装置である。

データベース部１２は、アクセス権限に関する各種の情報を格納するデータベースである。図２は、データベース部１２の構成例を示すブロック図である。同図に示されるように、データベース部１２は、実行順序定義テーブル１２１、判定プログラム定義テーブル１２２、ユーザー情報定義テーブル１２３、およびモジュール定義テーブル１２４を含んでいる。

図３は、実行順序定義テーブル１２１の具体例を示す図である。同図に示されるように、実行順序定義テーブル１２１は、初期実行フラグ、機能ＩＤ、機能名称、判定プログラムＩＤ、許可時および拒否時の次判定プログラムＩＤなどをデータ項目に含んでいる。ここでは、設計に関する機能ＩＤが“Ｆｕ−００１”であり、これに対して実施される判定プログラムが“Ｊｕ−００１”、“Ｊｕ−００２”、および“Ｊｕ−００３”であることが定義されている。また、初期実行フラグが“１”のプログラムが最初に実行される判定プログラムであり、判定処理の結果が許可または拒否の場合に実施されるプログラムを次判定プログラムＩＤで各々定義している。例えば、判定プログラム“Ｊｕ−００１”の判定結果が拒否の場合には、次に実行する判定プログラムは“Ｊｕ−００２”であることが示されている。尚、“―”は最終判定であることを示しており、判定プログラム“Ｊｕ−００１”の判定結果が許可の場合には、他の判定プログラムは実行しない。

図４は、判定プログラム定義テーブル１２２の具体例を示す図である。同図に示されるように、判定プログラム定義テーブル１２２は、機能ＩＤ、判定プログラムＩＤ、およびアクセス許可条件（判定基準）などをデータ項目に含んでいる。ここでは、機能ＩＤに関連付けされた判定プログラムのそれぞれに対してアクセス許可条件が定義されている。例えば、機能ＩＤが“Ｆｕ−００１”の場合に実行される判定プログラムには“Ｊｕ−００１”が含まれているが、判定プログラム“Ｊｕ−００１”の中でのアクセス許可条件は「ユーザーの役職が係長以上であること」と定義されている。しかし、機能ＩＤが“Ｆｕ−００２”の場合には、同一の判定プログラム“Ｊｕ−００１”を実行するが、アクセス許可条件は「ユーザーの役職が副部長以上であること」と定義されている。このように定義するため、共通する判定プログラムを用いつつ、機能に応じて異なる判定基準を設定することが可能となる。

図５は、ユーザー情報定義テーブル１２３の具体例を示す図である。同図に示されるように、ユーザー情報定義テーブル１２３は、識別区分、ユーザーＩＤ、役職、社員区分、および役割などをデータ項目に含んでいる。ここではユーザーＩＤが“ＵＳＥＲ＿Ａ”のユーザー情報は“役職が部長、社員区分が正社員、役割が設計”と設定されている。尚、識別区分はアクセス制限の設定単位を示し、識別区分“Ｇ”はグループ単位で設定することを示している。

図６は、モジュール定義テーブル１２４の具体例を示す図である。同図に示されるように、モジュール定義テーブル１２４は、判定プログラムＩＤ、モジュールＩＤ、モジュール名称、および格納場所をデータ項目に含んでおり、後述する判定プログラム格納部１４との関連付けがなされている。

アクセス権限判定部１３は、ユーザー情報定義テーブル１２３および判定プログラム定義テーブル１２２を参照してユーザー情報およびアクセス要求に係る判定プログラムの情報をそれぞれ取得し、実行順序定義テーブル１２１およびモジュール定義テーブル１２４を参照して各判定プログラムを判定プログラム格納部１４から読込み、判定処理を順次実行することで、論理和（ＯＲ条件）および論理積（ＡＮＤ条件）の組合せによってユーザーがアクセス権限を有するか否かを判定するプログラムである。

図７は、アクセス管理システムにおけるアクセス権限を説明する図である。ここでは、‘＋’は論理和（ＯＲ条件）、‘＆’は論理積（ＡＮＤ条件）を示しており、設計機能に関しては“役職者、正社員、設計者のいずれかに該当すること”、原価管理機能に関しては“役職者または正社員の設計者であること”、部門負荷管理機能に関しては“役職者であること”を満たすユーザーがアクセスできることを論理式で示している。これらのアクセス権限を予め定義し、上述したようにデータベース部１２内の各テーブルを定義することでアクセス権限判定部１３における判定が可能となる。

判定プログラム格納部１４は、複数の機能に対して共通に設けられた汎用性のあるプログラムであって、情報資源に対するアクセス権限の有無を機能単位で判定する各種の判定プログラムを格納する記憶装置である。判定プログラムの具体例としては、役職判定プログラム、社員区分判定プログラム、役割判定プログラムなどが挙げられる。尚、判定プログラムは、それぞれモジュール化されているので、追加や修正が容易となっている。

実行処理部１５は、アクセス権限判定部１３における判定結果に基づいて情報資源格納部１６に格納された情報資源にアクセスするプログラムである。

情報資源格納部１６は、情報資源を機能単位で分類して格納する記憶装置である。情報資源としては、アクセス管理サーバ１において提供される各種の機能のそれぞれに対応する各種のプログラム（アプリケーションプログラムなど）や文字、音声、映像などの電子データなどが該当する。尚、本実施形態においては、情報資源へのアクセス要求とユーザーの機能選択を同義として説明する。

クライアント端末２は、ユーザーがアクセス管理サーバ１に対してアクセス要求を行う際に用いるコンピュータである。本実施形態においては、ユーザーＩＤによって識別されているユーザーが、クライアント端末２上に表示されるメニュー選択画面において機能選択（情報資源へのアクセス要求）を行った場合について説明する。図８は、メニュー選択画面の具体例を示す図である。ここでは、ユーザーＩＤが“ＵＳＥＲ＿Ａ”のユーザーが設計機能に対してアクセス要求を行った場合が示されている。

図９は、アクセス権限判定部１３における判定処理の具体例を示すフローチャートである。

Ｓ９０１において、アクセス要求取得部１１は、ネットワーク３を介してクライアント端末２から入力されたアクセス要求を取得し、このアクセス要求に係る機能ＩＤをアクセス権限判定部１３に出力する。

Ｓ９０２において、アクセス権限判定部１３は、アクセス要求取得部１１で取得された機能ＩＤをキーとして実行順序定義テーブル１２１を参照し、実行対象となる判定プログラムの有無を判定する。ここで、実行対象となる判定プログラムが有る場合には、Ｓ９０３へ進む。これに対し、実行対象となる判定プログラムが無い場合には、Ｓ９１０へ進む。

Ｓ９０３において、アクセス権限判定部１３は、アクセス要求の機能に対応する判定プログラムのリスト、各判定プログラムの実行順序、および各判定プログラムの実行条件を関連付けした判定モデルを作成する。図１０は、アクセス権限判定部１３におけるアクセス権限の判定モデルを具体的に説明する図である。ここでは、実行順序定義テーブル１２１において初期実行フラグが“１”に設定された判定プログラムが最初に実行されることが示されている。また、判定処理の結果に応じて次に実行する判定プログラムを矢印で結ぶことで各判定プログラムの実行順序と実行条件が定義されている。図１０（ａ）は、ユーザーが設計機能へアクセス要求を行った場合、図１０（ｂ）は原価管理機能へアクセス要求を行った場合、図１０（ｃ）は部門別負荷管理機能へアクセス要求を行った場合を示している。

Ｓ９０４においては、判定プログラム定義テーブル１２２を参照し、判定モデルを構成する各判定プログラムで用いられるアクセス許可条件（判定基準）を取得する。例えば、設計機能にアクセス要求を行った際の役職判定では、アクセス許可条件は“ユーザーの役職が係長以上”であることが分かる。

Ｓ９０５において、アクセス権限判定部１３は、ユーザー情報定義テーブル１２３を参照し、アクセス要求を行ったユーザーのユーザー情報を取得する。例えば、ユーザーＩＤが“ＵＳＥＲ−Ａ”の場合には、ユーザー情報定義テーブル１２３から役職が“部長”、社員区分が“正社員”、役割が“設計”というユーザー情報が取得される。

Ｓ９０６において、アクセス権限判定部１３は、判定モデルに基づいて１番目の判定プログラムを判定プログラム格納部１４から読込み、判定処理を実行する。

Ｓ９０７において、アクセス権限判定部１３は、実行された判定プログラムの判定結果が最終判定に該当するか否かを判定する。すなわち、既に実行した判定プログラムの判定結果に基づいて判定モデルを参照し、次に実行する判定プログラムの有無を判定する。上述した図１０（ａ）の場合には、役職判定の判定結果が許可ならば、最終判定となるが、判定結果が拒否ならば、次に実行する判定プログラムは“Ｊｕ−００２（社員区分判定）”となる。

ここで、判定結果が最終判定であると判定された場合にはＳ９０９へ進む。これに対し、最終判定ではないと判定された場合には、Ｓ９０８へ進む。

Ｓ９０８において、アクセス権限判定部１３は、判定モデルを参照して次の判定プログラムを判定プログラム格納部１４から読込み、判定処理を実行した後に、Ｓ９０７へ戻る。尚、Ｓ９０７〜Ｓ９０８の処理は、最終判定が行われるまで繰り返される。

Ｓ９０９において、アクセス権限判定部１３は、単数若しくは複数の判定プログラムの判定結果の論理積および論理和の組合せに基づく最終判定結果を出力し、処理を終了する。尚、最終判定が“アクセス権限無し”の場合には、アクセス権限判定部１３は、システムメッセージ表示画面を出力する。図１１は、システムメッセージ表示画面の具体例を示す図である。

図１２は、アクセス権限判定部１３におけるアクセス権限の判定処理を具体的に説明する図である。図１２（ａ）は、ユーザーＩＤが“ＵＳＥＲ＿Ａ”のユーザーが設計機能へのアクセス要求を行った場合には、ユーザー情報定義テーブル１２３からユーザーの役職が部長であることが分かるので、判定プログラム“Ｊｕ−００１（役職判定）”の判定結果が許可となり、“アクセス権限有り”の最終判定がなされることが示されている。一方、図１２（ｂ）は、ユーザーＩＤが“ＵＳＥＲ＿Ｆ”のユーザーが設計機能へのアクセス要求を行った場合には、役職判定および社員区分判定が順番に実行されたが、いずれの判定結果も拒否であるので役割判定が行われるが拒否となり、“アクセス権限無し”の最終判定がなされることが示されている。

また、Ｓ９１０において、アクセス権限判定部１３は、最終判定結果をアクセス許可として処理を終了する。

このように、データベース部１２の各テーブルに定義された情報に基づいて判定プログラムを順次実行することで、アクセス権限の有無を論理和（ＯＲ条件）および論理積（ＡＮＤ条件）の組合せによって判定することが可能となる。図１３は、アクセス権限判定部１３における判定結果を示す図である。

また、各判定プログラムはモジュール化されているので、アクセス権限の変更や追加が容易であり、セキュリティ強度を柔軟に変更できる。例えば、設計機能に対するアクセス権限の判定プログラムを新規に追加する場合には、各テーブルに必要な情報を追加・修正することによりアクセス権限を柔軟に変更可能となる。

尚、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。

また、上記実施形態におけるアクセス管理システムはクライアント・サーバ方式であったが、単体の装置におけるアクセス管理の場合も同様に行うことができる。

更に、各種のテーブルの定義方法も任意に変更可能である。例えば、ユーザー情報定義テーブル１２３において関連する判定プログラムとその判定プログラムで用いるユーザー情報（権限）を定義してもよい。図１４は、ユーザー情報定義テーブル１２３の具体例を示す図である。ここでは、ユーザーＩＤが“ＵＳＥＲ＿Ａ”のユーザーのアクセス権限の有無に関して実行される判定プログラムが“Ｊｕ−００１”、“Ｊｕ−００２”、および“Ｊｕ−００３”であることに加え、各判定プログラムで用いられるユーザー情報がそれぞれ定義されている。このように、各テーブルを既存のテーブルの構成などに対応して変更することでアクセス管理システムを容易に導入することができる。

本発明の一実施形態に係るアクセス管理システムの全体構成例を示すブロック図。 本発明の一実施形態に係るデータベース部１２の構成例を示すブロック図。 本発明の一実施形態に係る実行順序定義テーブル１２１の具体例を示す図。 本発明の一実施形態に係る判定プログラム定義テーブル１２２の具体例を示す図。 本発明の一実施形態に係るユーザー情報定義テーブル１２３の具体例を示す図。 本発明の一実施形態に係るモジュール定義テーブル１２４の具体例を示す図。 本発明の一実施形態に係るアクセス管理システムにおけるアクセス権限を説明する図。 本発明の一実施形態に係るクライアント端末２に表示されるメニュー選択画面の具体例を示す図。 本発明の一実施形態に係るアクセス権限判定部１３における判定処理の具体例を示すフローチャート。 本発明の一実施形態に係るアクセス権限判定部１３におけるアクセス権限の判定モデルを具体的に説明する図。 本発明の一実施形態に係るシステムメッセージ表示画面の具体例を示す図。 本発明の一実施形態に係るアクセス権限の判定処理を具体的に説明する図。 本発明の一実施形態に係るアクセス権限判定処理の判定結果を示す図。 本発明の他の実施形態に係るユーザー情報定義テーブル１２３の具体例を示す図。

符号の説明

１…アクセス管理サーバ、
２…クライアント端末、
３…ネットワーク、
１１…アクセス要求取得部、
１２…データベース部、
１３…アクセス権限判定部、
１４…判定プログラム格納部、
１５…実行処理部、
１６…情報資源格納部、
１２１…実行順序定義テーブル、
１２２…判定プログラム定義テーブル、
１２３…ユーザー情報定義テーブル、
１２４…モジュール定義テーブル。

Claims (5)

1. 情報資源を格納する情報資源格納部と、
   ユーザーからの前記情報資源に対するアクセス要求を取得するアクセス要求取得部と、
   前記ユーザーの前記情報資源に対するアクセス権限の有無を判定する複数の判定基準の各々に対応する複数の判定プログラムを格納する判定プログラム格納部と、
   前記判定基準との比較対象となる前記ユーザー情報を定義するユーザー情報定義テーブルと、
   前記アクセス要求に対して実行される前記判定プログラムおよび実行順序を定義する実行順序定義テーブルと、
   前記アクセス要求に基づいて前記ユーザー情報定義テーブルから前記ユーザー情報、前記実行順序定義テーブルから前記実行される前記判定プログラムおよび前記実行順序を取得し、これらの取得された情報に基づいて前記判定プログラムを順次実行し、それぞれの判定結果の論理和および論理積の組合せによって前記ユーザーの前記アクセス権限の有無を判定するアクセス権限判定部と、
   を有することを特徴とするアクセス管理システム。
2. 前記判定基準をコンピューター上で提供される機能単位で定義した判定プログラム定義テーブルを更に備え、
   前記アクセス権限判定部は、前記判定基準に基づいて前記判定プログラムをそれぞれ実行することを特徴とする請求項１記載のアクセス管理システム。
3. 前記判定プログラムは、少なくとも役職判定、社員区分判定、および役割判定に対応して個別に備えられていることを特徴とする請求項１または請求項２記載のアクセス管理システム。
4. コンピューター内の情報資源に対するユーザーからのアクセス要求を取得するアクセス要求取得ステップと、
   前記ユーザーの前記情報資源に対するアクセス権限の有無を判定する複数の判定基準の各々に対応する複数の判定プログラムを格納する判定プログラム格納ステップと、
   前記判定基準との比較対象となる前記ユーザー情報を定義するユーザー情報定義ステップと、
   前記アクセス要求に対して実行される前記判定プログラムおよび実行順序を定義する実行順序定義ステップと、
   前記アクセス要求に基づいて前記ユーザー情報定義ステップで定義された前記ユーザー情報、前記実行順序定義ステップで定義された前記実行される前記判定プログラムおよび前記実行順序を取得し、これらの取得された情報に基づいて前記判定プログラムを順次実行し、それぞれの判定結果の論理和および論理積の組合せによって前記ユーザーの前記アクセス権限の有無を判定するアクセス権限判定ステップと、
   を有することを特徴とするアクセス管理方法。
5. 前記判定基準を前記コンピューター上で提供される機能単位で定義する判定プログラム定義ステップを更に備え、
   前記アクセス権限判定ステップにおいて、前記判定基準に基づいて前記判定プログラムをそれぞれ実行することを特徴とする請求項４記載のアクセス管理方法。

Images