特許 7452366 アクセス制御装置、アクセス制御方法及びアクセス制御プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-03-11

(45)【発行日】2024-03-19

(54)【発明の名称】アクセス制御装置、アクセス制御方法及びアクセス制御プログラム

(51)【国際特許分類】

   G06F 21/60 20130101AFI20240312BHJP

【ＦＩ】

G06F21/60 340

【請求項の数】 7

(21)【出願番号】P 2020169255

(22)【出願日】2020-10-06

(65)【公開番号】P2022061322

(43)【公開日】2022-04-18

【審査請求日】2023-07-07

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】大桃 潤

(72)【発明者】

【氏名】木村 浩希

【審査官】宮司 卓佳

(56)【参考文献】

【文献】特開２００５－１４２８４８（ＪＰ，Ａ）

【文献】特開２００１－５７２７（ＪＰ，Ａ）

【文献】特開２００９－１１６４９６（ＪＰ，Ａ）

【文献】特開２０００－０３５９１２（ＪＰ，Ａ）

【文献】特開２０１１－１２３６１０（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／６０

(57)【特許請求の範囲】

【請求項1】

複数のユーザの属性情報群を記憶するサーバから、アクセス頻度が閾値を超えるグループに属するユーザの属性情報を所定の周期で取得する取得部と、
前記アクセス頻度が前記閾値を超えるグループに属する第１のユーザのユーザ端末からサービスに対するアクセスを受け付けた場合、前記取得部により取得される属性情報のうち前記第１のユーザの属性情報に基づいてアクセス制御を実行し、前記アクセス頻度が前記閾値を超えないグループに属する第２のユーザのユーザ端末から前記サービスに対するアクセスを受け付けた場合、前記サーバに記憶された前記第２のユーザの属性情報に基づいてアクセス制御を実行するアクセス制御部と
を有することを特徴とするアクセス制御装置。

【請求項2】

前記サーバは、ＬＤＡＰに対応するディレクトリサービスを提供するＬＤＡＰサーバであることを特徴とする請求項１に記載のアクセス制御装置。

【請求項3】

前記グループは、前記ＬＤＡＰサーバに記憶されたディレクトリ情報ツリーのルートエントリの直下に位置するエントリに対応する組織であることを特徴とする請求項２に記載のアクセス制御装置。

【請求項4】

前記所定の周期が経過した場合、前記アクセス頻度と比較する閾値を算出する算出部をさらに有することを特徴とする請求項１または請求項２に記載のアクセス制御装置。

【請求項5】

前記算出部は、前記アクセス頻度で前記サーバから属性情報を取得したときの総データサイズが前記取得部により前記グループ内の全ユーザの属性情報が一括で取得されるデータサイズと同等になる閾値を算出することを特徴とする請求項４に記載のアクセス制御装置。

【請求項6】

複数のユーザの属性情報群を記憶するサーバから、アクセス頻度が閾値を超えるグループに属するユーザの属性情報を所定の周期で取得し、
前記アクセス頻度が前記閾値を超えるグループに属する第１のユーザのユーザ端末からサービスに対するアクセスを受け付けた場合、前記取得する処理で取得される属性情報のうち前記第１のユーザの属性情報に基づいてアクセス制御を実行し、前記アクセス頻度が前記閾値を超えないグループに属する第２のユーザのユーザ端末から前記サービスに対するアクセスを受け付けた場合、前記サーバに記憶された前記第２のユーザの属性情報に基づいてアクセス制御を実行する、
処理をコンピュータが実行することを特徴とするアクセス制御方法。

【請求項7】

複数のユーザの属性情報群を記憶するサーバから、アクセス頻度が閾値を超えるグループに属するユーザの属性情報を所定の周期で取得し、
前記アクセス頻度が前記閾値を超えるグループに属する第１のユーザのユーザ端末からサービスに対するアクセスを受け付けた場合、前記取得する処理で取得される属性情報のうち前記第１のユーザの属性情報に基づいてアクセス制御を実行し、前記アクセス頻度が前記閾値を超えないグループに属する第２のユーザのユーザ端末から前記サービスに対するアクセスを受け付けた場合、前記サーバに記憶された前記第２のユーザの属性情報に基づいてアクセス制御を実行する、
処理をコンピュータに実行させることを特徴とするアクセス制御プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、アクセス制御技術に関する。

【背景技術】

【0002】

一度のユーザ認証で複数のサービスへのアクセスを認可する機能、いわゆるＳＳＯ（Single Sign-On）が知られている。例えば、ＳＳＯでは、ＬＤＡＰ（Lightweight Directory Access Protocol）等に対応するディレクトリサービスを提供するＬＤＡＰサーバから取得されるユーザの属性情報を用いて、サービスに対するアクセス可否やアクセスレベルなどの制御が実現される。

【0003】

上記のディレクトリサービスでは、ユーザの職制の変更などに伴ってディレクトリ情報が高頻度で更新され得る。このような更新を反映してアクセス制御を行う側面から、サービスに対するユーザアクセスが行われる度にディレクトリサービスへのアクセスが行われる。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２００５－６２５５６号公報

【文献】特開平８－２８７０９５号公報

【文献】特開２００３－２８１０２１号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、上記のＬＤＡＰサーバでは、ユーザアクセスが行われる度にディレクトリサービスへのアクセスが行われるので、ＬＤＡＰサーバの負荷が増大する側面がある。

【0006】

なお、上記の課題は、ＬＤＡＰサーバ等のディレクトリサービスにより属性情報が提供される場合だけではなく、ユーザの属性情報を提供するサービス全般で同様に生じる課題である。

【0007】

１つの側面では、本発明は、ユーザの属性情報を提供するサーバの負荷を低減できるアクセス制御装置、アクセス制御方法及びアクセス制御プログラムを提供することを目的とする。

【課題を解決するための手段】

【0008】

１つの案では、アクセス制御装置は、複数のユーザの属性情報群を記憶するサーバから、アクセス頻度が閾値を超えるグループに属するユーザの属性情報を所定の周期で取得する取得部と、前記アクセス頻度が前記閾値を超えるグループに属する第１のユーザのユーザ端末からサービスに対するアクセスを受け付けた場合、前記取得部により取得される属性情報のうち前記第１のユーザの属性情報に基づいてアクセス制御を実行し、前記アクセス頻度が前記閾値を超えないグループに属する第２のユーザのユーザ端末から前記サービスに対するアクセスを受け付けた場合、前記サーバに記憶された前記第２のユーザの属性情報に基づいてアクセス制御を実行するアクセス制御部とを有する。

【発明の効果】

【0009】

ユーザの属性情報を提供するサーバの負荷を低減できる。

【図面の簡単な説明】

【0010】

【図1】図１は、実施例１に係るシステム構成例を示す図である。

【図2】図２は、ディレクトリ情報ツリーの一例を示す図である。

【図3】図３は、実施例１に係るサーバ装置の機能的構成の一例を示す図である。

【図4】図４は、取得先情報の遷移例を示す図である。

【図5】図５は、定期取得時の動作例を示す図である。

【図6】図６は、定期取得時の動作例を示す図である。

【図7】図７は、アクセス制御時の動作例を示す図である。

【図8】図８は、アクセス制御時の動作例を示す図である。

【図9】図９は、実施例１に係る定期取得処理の手順を示すシーケンス図である。

【図10】図１０は、実施例１に係る定期取得処理の手順を示すフローチャートである。

【図11】図１１は、実施例１に係るアクセス制御処理の手順を示すシーケンス図である。

【図12】図１２は、実施例１に係るアクセス制御処理の手順を示すフローチャートである。

【図13】図１３は、コンピュータのハードウェア構成例を示す図である。

【発明を実施するための形態】

【0011】

以下に添付図面を参照して本願に係るアクセス制御装置、アクセス制御方法及びアクセス制御プログラムについて説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

【実施例1】

【0012】

［システム構成］
図１は、実施例１に係るシステム構成例を示す図である。図１には、本実施例に係るアクセス制御機能が適用される情報システムの一例として、シングルサインオンサービスを導入する企業情報システム１を例に挙げるが、任意の情報システムであってよい。さらに、図１には、本実施例に係るアクセス制御機能がエージェント方式のシングルサインオンサービスで提供される例を挙げるが、リバースプロキシ方式などの他の方法で提供されることとしてもよい。

【0013】

図１に示すように、企業情報システム１には、サーバ装置１０－１～１０－Ｎと、ユーザ端末２０Ａ～２０Ｍと、管理者端末３０と、ＬＤＡＰサーバ４０とが含まれ得る。以下、サーバ装置１０－１～１０－Ｎの個体の区別が不要である場合に「サーバ装置１０」と記載し、ユーザ端末２０Ａ～２０Ｍの個体の区別が不要である場合に「ユーザ端末２０」と記載する場合がある。

【0014】

サーバ装置１０、ユーザ端末２０、管理者端末３０及びＬＤＡＰサーバ４０は、ネットワークＮＷを介して通信可能に接続される。例えば、ネットワークＮＷは、有線または無線を問わず、インターネット、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網であってよい。

【0015】

サーバ装置１０は、任意のサービス、例えば業務サービスなどのＷｅｂサービスを提供するコンピュータの一例である。このようなサーバ装置１０の例として、Ｗｅｂサーバやアプリケーションサーバ、データベースサーバなどが挙げられる。

【0016】

図１に示すように、サーバ装置１０－１～１０－Ｎは、サービス実行部１３－１～１３－Ｎと、認可ｐｒｏｘｙ実行部１５－１～１５－Ｎとを含み得る。サービス実行部１３－１～１３－Ｎは、Ｗｅｂサービスに対応する処理を実行する。認可ｐｒｏｘｙ実行部１５－１～１５－Ｎは、認可コントローラ５０により設定される認可ポリシーにしたがってＷｅｂサービスに対するユーザアクセスの認可、いわゆるアクセス制御を行う。以下、サービス実行部１３－１～１３－Ｎの個体の区別が不要である場合に「サービス実行部１３」と記載すると共に、認可ｐｒｏｘｙ実行部１５－１～１５－Ｎの個体の区別が不要である場合に「認可ｐｒｏｘｙ実行部１５」と記載する場合がある。

【0017】

あくまで一例として、図１には、１つのサーバ装置１０につき１つのＷｅｂサービスが提供される例を挙げたが、図示の例に限定されない。例えば、サーバ装置１０は、Ｗｅｂサービスの並列化および冗長化を実現する側面から、ＶＭ（Virtual Machine）やコンテナなどのホスト上で同種または異種の複数のＷｅｂサービスに対応する処理を実行する複数のプロセスを動作させることもできる。この場合、サーバ装置１０には、複数のサービス実行部１３と、複数のサービス実行部１３の各々に対応するエージェントとして配置される複数の認可ｐｒｏｘｙ実行部１５とが含まれ得る。

【0018】

ユーザ端末２０は、企業情報システム１のエンドユーザにより使用される端末装置である。例えば、ユーザ端末２０は、サーバ装置１０により提供されるＷｅｂサービスを利用できる環境、例えばＷｅｂクライアントの一例であるブラウザが動作できる環境を有する。以下、ユーザ端末２０からネットワークＮＷ上に存在するリソースへ行われるアクセスのことを「ユーザアクセス」と記載する場合がある。

【0019】

管理者端末３０は、シングルサインオンサービスのユーザの一例に対応する企業情報システム１の管理者により使用される端末装置である。ここで言う「管理者」には、企業情報システム１のシステム管理者やセキュリティ管理者、サーバ装置１０の運営者などといった企業情報システム１の管理者全般が含まれてよい。

【0020】

ＬＤＡＰサーバ４０は、ＬＤＡＰに対応するディレクトリサービスを提供するコンピュータの一例に対応する。例えば、上記のディレクトリサービスには、人や組織などのオブジェクトに関するエントリの集合がツリー構造で表現されたディレクトリ情報ツリーを格納するディレクトリ情報ベースが用いられる。

【0021】

図２は、ディレクトリ情報ツリーの一例を示す図である。図２に示すように、ディレクトリ情報ツリーのオブジェクトには、属性および属性値が含まれる。例えば、ディレクトリ情報ツリーのオブジェクトの登録、更新または削除などの編集は、エンドユーザの職制情報にしたがって管理者端末３０から受け付けることができる。ここで、図２に示す“ｄｃ”はドメイン名を指し、“ｏｕ”は組織を指し、“ｃｎ”は個人を指す。図２に示すディレクトリ情報ツリーの例で言えば、ＦＪという企業には、営業、開発、総務および経理の４つの組織が含まれることをコンピュータが認識できる。このうち、営業には、１ｇおよび２ｇの２つ組織が含まれると共に、Ｘという個人が含まれることをコンピュータが認識できる。さらに、営業の１ｇという組織には、Ａ、ＢおよびＣという３人の個人が含まれることをコンピュータが認識できる。また、開発には、１ｇおよび２ｇの２つ組織が含まれ、さらに、１ｇには、ＤおよびＥという２人の個人が含まれることをコンピュータが認識できる。また、総務には、１ｇおよび２ｇという２つの組織が含まれると共に、経理には、１ｇおよび２ｇの２つの組織が含まれると共にＹという個人がことをコンピュータが認識できる。

【0022】

以上のように、図１では、サーバ装置１０およびＬＤＡＰサーバ４０が企業情報システム１内に設置されるオンプレミス環境を例示したが、これに限定されない。例えば、サーバ装置１０およびＬＤＡＰサーバ４０が有する機能の一部または全部は、クラウド環境でクラウドサービスとして提供されることとしてもよい。

【0023】

さらに、図１に示す認可コントローラ５０を通じて、認可ｐｒｏｘｙの制御機能がクラウドサービスとして提供される。１つの側面として、認可コントローラ５０は、エンドユーザのアクセス権限の設定を受け付けるＧＵＩ（Graphical User Interface）やＣＬＩ（Command Line Interface）などのユーザインタフェイスを管理者端末３０へ提供する。例えば、エンドユーザには、エンドユーザの組織内における仕事や役割を表すロールが設定される。このようなロールごとにサービスやデータなどのリソースに対するアクセス可否やアクセスレベルなどのアクセス権限が割り当てられる。これらロールおよびアクセス権限が対応付けられた認可ポリシー情報が認可ｐｒｏｘｙ実行部１５へ配信される。他の側面として、認可コントローラ５０には、各サーバ装置１０の認可ｐｒｏｘｙ実行部１５からリソースに対するアクセスログを収集することもできる。

【0024】

なお、図１には、認可コントローラ５０により認可ｐｒｏｘｙ実行部１５－１～１５－Ｎが制御される例を挙げるが、図示の例に限定されない。例えば、認可ｐｒｏｘｙ実行部１５－１～１５－Ｎのうち１つまたは所定数の認可ｐｒｏｘｙ実行部１５が他の認可ｐｒｏｘｙ実行部１５の制御機能を有することとしてもよい。この場合、認可コントローラ５０が必ずしも含まれずともよい。

【0025】

［サーバ装置１０の構成］
次に、本実施例に係るサーバ装置１０の機能的構成について説明する。図３は、実施例１に係るサーバ装置１０の機能的構成の一例を示すブロック図である。図３には、サーバ装置１０が有する機能に対応するブロックが模式化されている。図３に示すように、サーバ装置１０は、認証部１１と、サービス実行部１３と、認可ｐｒｏｘｙ実行部１５とを有する。なお、サーバ装置１０は、図３に示す機能部以外にも既知のコンピュータが有する各種の機能部、例えば入出力インタフェイスや通信インタフェイスなどに対応する機能が含まれることを妨げない。

【0026】

認証部１１、サービス実行部１３および認可ｐｒｏｘｙ実行部１５などの機能部は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などのハードウェアプロセッサにより仮想的に実現される。例えば、プロセッサは、図示しないストレージ、例えばＨＤＤ（Hard Disk Drive）、光ディスクやＳＳＤ（Solid State Drive）などから各種のプログラムを読み出す。このようなプログラムには、ＯＳ（Operating System）の他、Ｗｅｂサービスを実現するＷｅｂアプリケーションや上記のアクセス制御機能を実現するアクセス制御プログラムなどが含まれ得る。

【0027】

例えば、プロセッサは、上記のＷｅｂアプリケーションを実行することにより、ＲＡＭ（Random Access Memory）等のメモリ上に認証部１１やサービス実行部１３に対応するプロセスを展開する。このように、上記のＷｅｂアプリケーションが実行される結果、上記のサービス実行部３３がプロセスとして仮想的に実現される。また、プロセッサは、上記のアクセス制御プログラムを実行することにより、ＲＡＭ等のメモリ上に認可ｐｒｏｘｙ実行部１５に対応するプロセスを展開する。このように、上記のアクセス制御プログラムが実行される結果、認可ｐｒｏｘｙ実行部１５がプロセスとして仮想的に実現される。なお、ここでは、プロセッサの一例として、ＣＰＵやＭＰＵを例示したが、汎用型および特化型を問わず、任意のプロセッサにより上記の機能部が実現されることとしてもかまわない。この他、上記の機能部または機能部の一部は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などのハードワイヤードロジックによって実現されることとしてもかまわない。

【0028】

認証部１１は、ユーザ認証を実行する処理部である。一実施形態として、認証部１１は、ユーザ端末２０からサインインのリクエストを受け付けた場合、ユーザ端末２０から受け付けたユーザＩＤおよびパスワードを含む認証リクエストを図示しないＳＳＯサーバへ送信する。この認証リクエストに応答して、ＳＳＯサーバでは、ＬＤＡＰ上のアカウントを用いてユーザ認証が実行される。この結果、認証の成功時には、認証トークン、例えばＬＤＡＰのユーザ名などが発行される。

【0029】

サービス実行部１３は、Ｗｅｂサービスに対応する処理を実行する処理部である。一実施形態として、サービス実行部１３は、ユーザ端末２０から認可ｐｒｏｘｙ実行部１５を介してユーザアクセス、例えばＨＴＴＰ（HyperText Transfer Protocol）リクエストを受け付けると、ＨＴＴＰリクエストで要求された処理を実行する。その後、サービス実行部１３は、ＨＴＴＰレスポンスを認可ｐｒｏｘｙ実行部１５を介してユーザ端末２０へ送信する。

【0030】

認可ｐｒｏｘｙ実行部１５は、認可ｐｒｏｘｙ、すなわち上記のアクセス制御プログラムを実行する処理部である。図３に示すように、認可ｐｒｏｘｙ実行部１５は、算出部１５Ａと、生成部１５Ｂと、取得部１５Ｃと、受付部１５Ｄと、アクセス制御部１５Ｅとを有する。

【0031】

算出部１５Ａは、アクセス頻度を算出する処理部である。一実施形態として、算出部１５Ａは、組織単位の属性情報の定期取得が実行される場合、処理を起動することができる。すなわち、本実施例では、ＬＤＡＰサーバ４０の負荷を低減する側面から、アクセス頻度が閾値以上である組織に属するエンドユーザの属性情報をユーザアクセスが行われる度にＬＤＡＰサーバ４０から取得することが抑制される。その代わりに、本実施例では、所定の周期、例えば数時間につき１回の頻度に抑えて、アクセス頻度が閾値を超える組織に属するエンドユーザの属性情報がＬＤＡＰサーバ４０から取得される。このような定期取得が実行されるタイミングで、算出部１５Ａは、ディレクトリ情報ツリーが分割される分割範囲、例えばルートエントリの直下に位置するエントリに対応する組織ごとに当該組織のアクセス頻度および閾値Ｔｈを算出する。

【0032】

１つの側面として、算出部１５Ａは、アクセスログ１４Ａを参照して、組織のアクセス頻度を算出する。アクセスログ１４Ａは、サービス実行部１３－１～１３－Ｎの各々のサービスに対するアクセスのログである。例えば、アクセスログ１４Ａは、サービス実行部１３－１～１３－Ｎの各々のサービスに対するアクセスが認可ｐｒｏｘｙ実行部１５－１～１５－Ｎから認可コントローラ５０へ収集されたことにより生成される。あくまで一例として、図２に示す例で言えば、ディレクトリ情報ツリーは、ルートエントリの直下に位置する営業、開発、総務および経理の４つの組織へ分割される。この場合、算出部１５Ａは、営業、開発、総務および経理の４つの組織ごとに当該組織がアクセス元であるアクセス数を集計した上で単位時間、例えば１日から１か月程度あたりのアクセス数をアクセス頻度として計算する。このとき、直近のアクセスの状況を重視する側面から、アクセス数を集計する期間をアクセス頻度の算出が行われる時点から所定の期間以内のアクセスに絞り込んでもよいし、アクセス頻度の算出が行われる時点に近づくに連れて大きい重みを付与することもできる。なお、ここでは、定期取得時にアクセス頻度が算出される例を挙げたが、認可ｐｒｏｘｙ実行部１５－１～１５－Ｎでアクセスが検出される度にアクセス数を集計してアクセス頻度を算出することもできる。

【0033】

他の側面として、算出部１５Ａは、アクセス頻度と比較する閾値Ｔｈを算出する。あくまで一例として、算出部１５Ａは、単位時間あたりのアクセスをすべて個別に属性情報を取得したときの総データサイズが定期取得で組織内の全ユーザの属性情報を一括で取得するデータサイズと同等になる値を閾値Ｔｈとして算出する。このような閾値Ｔｈは、一例として、次式で動的に算出できる。

【0034】

閾値Ｔｈ＝（保存済み組織内データサイズ×アクセスカウント単位時間÷ＬＤＡＰからの定期取得間隔）÷（保存済み組織内データサイズ÷組織の所属人数）
＝アクセスカウント単位時間×組織の所属人数÷ＬＤＡＰからの定期取得間隔

【0035】

生成部１５Ｂは、ディレクトリ情報ツリーの分割範囲に対応する組織ごとに当該組織に属するユーザの属性情報の取得先が設定された取得先情報１４Ｂを生成する処理部である。以下、ユーザの属性情報の取得先のことを「ユーザ属性取得先」と略記する場合がある。一実施形態として、生成部１５Ｂは、ディレクトリ情報ツリーのルートエントリの直下に位置するエントリに対応する組織ごとに、当該組織のアクセス頻度が閾値Ｔｈを超えるか否かを判定する。このとき、生成部１５Ｂは、アクセス頻度が閾値Ｔｈを超える組織のユーザ属性取得先を“ｐｒｏｘｙ”に設定する一方で、アクセス頻度が閾値Ｔｈ以下である組織のユーザ属性取得先を“ＬＤＡＰ”に設定する。このようにして組織ごとに当該組織のユーザ属性取得先が設定された取得先情報１４Ｂが生成される。

【0036】

図４は、取得先情報１４Ｂの遷移例を示す図である。図４には、初回の時点Ｔ０、２回目の時点Ｔ１、３回目の時点Ｔ２および４回目の時点Ｔ３の取得先情報１４Ｂ０～１４Ｂ３が示されている。図４に示すように、初回の時点Ｔ０では、アクセス頻度の実測値がない。このため、全ての組織のアクセス頻度の初期値が閾値Ｔｈを超える「高」に設定されるので、全ての組織のユーザ属性取得先は“ｐｒｏｘｙ”に設定される。続いて、２回目の時点Ｔ１では、４つの組織のうち営業、総務および経理の３つの組織のアクセス頻度が閾値Ｔｈ_営業、閾値Ｔｈ_総務および閾値Ｔｈ_経理を超える一方で開発のアクセス頻度が閾値Ｔｈ_開発以下となる。この場合、開発のユーザ属性取得先が“ｐｒｏｘｙ”から“ＬＤＡＰ”へ変更される。その後、３回目の時点Ｔ２では、経理のアクセス頻度が低下し、閾値Ｔｈ_経理以下となる。これに伴って、経理のユーザ属性取得先が“ｐｒｏｘｙ”から“ＬＤＡＰ”へ変更される。続いて、４回目の時点Ｔ３では、経理のアクセス頻度が上昇し、閾値Ｔｈ_経理を超える。これに伴って、経理のユーザ属性取得先が“ＬＤＡＰ”から“ｐｒｏｘｙ”へ変更される。このように、アクセス頻度の推移に追従して組織のユーザ属性取得先を動的に変更できる。

【0037】

取得部１５Ｃは、ＬＤＡＰサーバ４０から組織単位の属性情報を所定の周期で取得する定期取得を実行する処理部である。一実施形態として、取得部１５Ｃは、前回の定期取得が行われてから一定の周期が経過した場合、ディレクトリ情報ツリーの分割範囲に対応する組織ごとに当該組織のユーザ属性取得先を取得先情報１４Ｂから参照する。その上で、取得部１５Ｃは、ユーザ属性取得先が“ｐｒｏｘｙ”である組織ごとに当該組織に属するユーザの属性情報をＬＤＡＰサーバ４０から取得する。

【0038】

図５及び図６は、定期取得時の動作例を示す図である。図５には、図４に示す取得先情報１４Ｂ０を参照して定期取得が行われる例が示される一方で、図６には、図４に示す取得先情報１４Ｂ１を参照して定期取得が行われる例が示されている。

【0039】

図５に示すように、算出部１５Ａは、ディレクトリ情報ツリーの分割範囲に対応する営業、開発、総務および経路の４つの組織ごとにアクセス頻度および閾値Ｔｈを算出する（ステップＳ１１）。続いて、生成部１５Ｂは、ステップＳ１１で算出されたアクセス頻度が閾値Ｔｈを超えるか否かに応じて組織ごとに当該組織のユーザ属性取得先が対応付けられた取得先情報１４Ｂ０を生成する（ステップＳ１２）。続いて、取得部１５Ｃは、取得先情報１４Ｂ０に設定されたユーザ属性取得先を参照する（ステップＳ１３）。ここで、図５に示す取得先情報１４Ｂ０には、営業、開発、総務および経理の全ての組織のユーザ属性取得先に“ｐｒｏｘｙ”が設定されている。このため、取得部１５Ｃは、ルートエントリ直下の全てのｏｕ以下のエントリをＬＤＡＰサーバ４０にリクエストする（ステップＳ１４）。この結果、ディレクトリ情報ベース、すなわちＤＩＢ（Directory Information Base）４１Ａから全組織のユーザの属性情報が取得される（ステップＳ１５）。その後、取得部１５Ｃは、ステップＳ１５で取得された全組織のユーザの属性情報を認可ｐｒｏｘｙ実行部１５が参照可能な記憶領域へ保存する（ステップＳ１６）。以下、認可ｐｒｏｘｙ実行部１５が参照可能な記憶領域のことを「認可ｐｒｏｘｙ記憶領域」と略記する場合がある。これら一連の定期取得により、属性情報１４Ｃ０が得られる。

【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】

［効果の一側面］
上述してきたように、本実施例に係る認可ｐｒｏｘｙ実行部１５は、アクセス頻度が閾値を超える組織のユーザであるか否かに応じてアクセス制御に用いる属性情報の参照先をＬＤＡＰまたは事前キャッシュの何れとするかを切り替える。例えば、アクセス頻度が閾値を超える組織のユーザからのアクセス受付時には、事前キャッシュの属性情報をアクセス制御に用いる一方で、アクセス頻度が閾値以下である組織のユーザからのアクセス受付時には、ＬＤＡＰの属性情報をアクセス制御に用いる。したがって、本実施例に係る認可ｐｒｏｘｙ実行部１５によれば、ＬＤＡＰサーバの負荷の低減を実現できる。

【実施例2】

【0065】

さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

【0066】

［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されておらずともよい。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、認可ｐｒｏｘｙ実行部１５に含まれる機能部の一部をサーバ装置１０の外部装置としてネットワーク経由で接続するようにしてもよい。また、認可ｐｒｏｘｙ実行部１５に含まれる機能部の一部を別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記の認可ｐｒｏｘｙ実行部１５の機能を実現するようにしてもよい。

【0067】

［アクセス制御プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１３を用いて、実施例１及び実施例２と同様の機能を有するアクセス制御プログラムを実行するコンピュータの一例について説明する。

【0068】

図１３は、コンピュータのハードウェア構成例を示す図である。図１３に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０とを有する。これら１１０～１８０の各部はバス１４０を介して接続される。

【0069】

ＨＤＤ１７０には、図１３に示すように、上記の実施例１で示した認可ｐｒｏｘｙ実行部１５と同様の機能を発揮するアクセス制御プログラム１７０ａが記憶される。このアクセス制御プログラム１７０ａは、図３に示した認可ｐｒｏｘｙ実行部１５の各構成要素と同様、統合又は分離してもかまわない。すなわち、ＨＤＤ１７０には、必ずしも上記の実施例１で示した全てのデータが格納されずともよく、処理に用いるデータがＨＤＤ１７０に格納されればよい。

【0070】

このような環境の下、ＣＰＵ１５０は、ＨＤＤ１７０からアクセス制御プログラム１７０ａを読み出した上でＲＡＭ１８０へ展開する。この結果、アクセス制御プログラム１７０ａは、図１３に示すように、アクセス制御プロセス１８０ａとして機能する。このアクセス制御プロセス１８０ａは、ＲＡＭ１８０が有する記憶領域のうちアクセス制御プロセス１８０ａに割り当てられた領域にＨＤＤ１７０から読み出した各種データを展開し、この展開した各種データを用いて各種の処理を実行する。例えば、アクセス制御プロセス１８０ａが実行する処理の一例として、図９～図１２に示す処理などが含まれる。なお、ＣＰＵ１５０では、必ずしも上記の実施例１で示した全ての処理部が動作せずともよく、実行対象とする処理に対応する処理部が仮想的に実現されればよい。

【0071】

なお、上記のアクセス制御プログラム１７０ａは、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶されておらずともかまわない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ－ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」にアクセス制御プログラム１７０ａを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体からアクセス制御プログラム１７０ａを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などにアクセス制御プログラム１７０ａを記憶させておき、コンピュータ１００がこれらからアクセス制御プログラム１７０ａを取得して実行するようにしてもよい。

【0072】

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

【0073】

（付記１）複数のユーザの属性情報群を記憶するサーバから、アクセス頻度が閾値を超えるグループに属するユーザの属性情報を所定の周期で取得する取得部と、
前記アクセス頻度が前記閾値を超えるグループに属する第１のユーザのユーザ端末からサービスに対するアクセスを受け付けた場合、前記取得部により取得される属性情報のうち前記第１のユーザの属性情報に基づいてアクセス制御を実行し、前記アクセス頻度が前記閾値を超えないグループに属する第２のユーザのユーザ端末から前記サービスに対するアクセスを受け付けた場合、前記サーバに記憶された前記第２のユーザの属性情報に基づいてアクセス制御を実行するアクセス制御部と
を有することを特徴とするアクセス制御装置。

【0074】

（付記２）前記サーバは、ＬＤＡＰに対応するディレクトリサービスを提供するＬＤＡＰサーバであることを特徴とする付記１に記載のアクセス制御装置。

【0075】

（付記３）前記グループは、前記ＬＤＡＰサーバに記憶されたディレクトリ情報ツリーのルートエントリの直下に位置するエントリに対応する組織であることを特徴とする付記２に記載のアクセス制御装置。

【0076】

（付記４）前記所定の周期が経過した場合、前記アクセス頻度と比較する閾値を算出する算出部をさらに有することを特徴とする付記１に記載のアクセス制御装置。

【0077】

（付記５）前記算出部は、前記アクセス頻度で前記サーバから属性情報を取得したときの総データサイズが前記取得部により前記グループ内の全ユーザの属性情報が一括で取得されるデータサイズと同等になる閾値を算出することを特徴とする付記４に記載のアクセス制御装置。

【0078】

（付記６）複数のユーザの属性情報群を記憶するサーバから、アクセス頻度が閾値を超えるグループに属するユーザの属性情報を所定の周期で取得し、
前記アクセス頻度が前記閾値を超えるグループに属する第１のユーザのユーザ端末からサービスに対するアクセスを受け付けた場合、前記取得する処理で取得される属性情報のうち前記第１のユーザの属性情報に基づいてアクセス制御を実行し、前記アクセス頻度が前記閾値を超えないグループに属する第２のユーザのユーザ端末から前記サービスに対するアクセスを受け付けた場合、前記サーバに記憶された前記第２のユーザの属性情報に基づいてアクセス制御を実行する、
処理をコンピュータが実行することを特徴とするアクセス制御方法。

【0079】

（付記７）前記サーバは、ＬＤＡＰに対応するディレクトリサービスを提供するＬＤＡＰサーバであることを特徴とする付記６に記載のアクセス制御方法。

【0080】

（付記８）前記グループは、前記ＬＤＡＰサーバに記憶されたディレクトリ情報ツリーのルートエントリの直下に位置するエントリに対応する組織であることを特徴とする付記７に記載のアクセス制御方法。

【0081】

（付記９）前記所定の周期が経過した場合、前記アクセス頻度と比較する閾値を算出する処理をさらに前記コンピュータが実行することを特徴とする付記６に記載のアクセス制御方法。

【0082】

（付記１０）前記算出する処理は、前記アクセス頻度で前記サーバから属性情報を取得したときの総データサイズが前記取得部により前記グループ内の全ユーザの属性情報が一括で取得されるデータサイズと同等になる閾値を算出することを特徴とする付記９に記載ののアクセス制御方法。

【0083】

（付記１１）複数のユーザの属性情報群を記憶するサーバから、アクセス頻度が閾値を超えるグループに属するユーザの属性情報を所定の周期で取得し、
前記アクセス頻度が前記閾値を超えるグループに属する第１のユーザのユーザ端末からサービスに対するアクセスを受け付けた場合、前記取得する処理で取得される属性情報のうち前記第１のユーザの属性情報に基づいてアクセス制御を実行し、前記アクセス頻度が前記閾値を超えないグループに属する第２のユーザのユーザ端末から前記サービスに対するアクセスを受け付けた場合、前記サーバに記憶された前記第２のユーザの属性情報に基づいてアクセス制御を実行する、
処理をコンピュータに実行させることを特徴とするアクセス制御プログラム。

【0084】

（付記１２）前記サーバは、ＬＤＡＰに対応するディレクトリサービスを提供するＬＤＡＰサーバであることを特徴とする付記１１に記載のアクセス制御プログラム。

【0085】

（付記１３）前記グループは、前記ＬＤＡＰサーバに記憶されたディレクトリ情報ツリーのルートエントリの直下に位置するエントリに対応する組織であることを特徴とする付記１２に記載のアクセス制御プログラム。

【0086】

（付記１４）前記所定の周期が経過した場合、前記アクセス頻度と比較する閾値を算出する処理をさらに前記コンピュータに実行させることを特徴とする付記１１に記載のアクセス制御プログラム。

【0087】

（付記１５）前記算出する処理は、前記アクセス頻度で前記サーバから属性情報を取得したときの総データサイズが前記取得部により前記グループ内の全ユーザの属性情報が一括で取得されるデータサイズと同等になる閾値を算出することを特徴とする付記１４に記載のアクセス制御プログラム。

【符号の説明】

【0088】

１ 企業情報システム
１０ サーバ装置
１１ 認証部
１３ サービス実行部
１５ 認可ｐｒｏｘｙ実行部
１５Ａ 算出部
１５Ｂ 生成部
１５Ｃ 取得部
１５Ｄ 受付部
１５Ｅ アクセス制御部
２０ ユーザ端末
３０ 管理者端末
４０ ＬＤＡＰサーバ
５０ 認可コントローラ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】