JP2008287579A - 情報処理装置及び情報処理方法及びプログラム - Google Patents

Abstract

【課題】複数権利者の情報リソースが一つのシステムに含まれている場合に、権利者ごとの情報リソースのアクセス制御を行う。
【解決手段】開発・設定端末（１）において、記憶部（１０２）は、権利者ごとに、情報リソースにアクセス可能なユーザを認証するためのユーザＤＢと、情報リソースにアクセス可能なユーザのアクセス権限を判定するためのアクセス権ＤＢを記憶し、また、ユーザＤＢとアクセス権ＤＢの利用禁止状態を解除するための領域管理者認証情報を記憶しており、領域制御部（１０１）は、ユーザＤＢ及びアクセス権ＤＢの利用禁止状態を保持するとともに、領域管理者認証情報に合致する情報が入力された場合に、ユーザＤＢ及びアクセス権ＤＢの利用禁止状態を解除してユーザＤＢ及びアクセス権ＤＢを利用可能にし、これにより、権利者ごとに情報リソースに対する適切なアクセス制御が可能となる。
【選択図】図１

Description

本発明は、ユーザ認証技術、アクセス権限管理技術に関し、例えば、ＰＬＣ （Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｃｏｎｔｒｏｌｌｅｒ：プログラマブル・ロジック・コントローラ）を用いた産業用システムにおけるユーザ認証技術、アクセス権限管理技術に関する。

ＰＬＣは、産業分野等で用いられている制御装置である。
センサやスイッチといった入力装置から信号の入力を得て、演算を行い、モータやアクチュエータといった出力装置へ信号を出力するといった機能を持っている。
ＰＬＣは、入力装置や出力装置といった被制御装置と、ネットワークまたはワイヤで接続される。
ＰＬＣは、被制御装置に対する制御動作を、内部に備えたプログラムと各種パラメータに基づいて行う。
通常、ＰＬＣが備えるプログラムと各種パラメータの作成は、パソコン等の開発・設定端末で行う。
作成されたプログラムと各種パラメータは、ＵＳＢやシリアル接続、あるいはネットワーク接続を介して、パソコンからＰＬＣへロードされる。

ＰＬＣを用いた産業用システムでは、ＰＬＣの動作に必要となるプログラムと各種パラメータが、重要な保護資産となるが、これらは、一人の権利者によって所有されるものではない。
例えば、プログラムの場合、サードベンダーが開発したライブラリを用いて装置メーカーが製造装置を開発し、エンドユーザは、納入された製造装置に、製造する製品用のプログラムを追加する、といったケースがある。
このケースでは、ライブラリの権利者はサードベンダーであり、ベースとなる製造装置のプログラムの権利者は装置メーカー、最終的な製造システム用に追加したプログラムの権利者はエンドユーザになる。
このように、複数の権利者の保護資産が一つのシステムに含まれている。

通常の情報システムでは、システム内の全てのリソースにアクセスできるシステム管理者が存在する。
しかし、前述のように複数権利者の保護資産が一つのシステムに含まれているケースでは、絶対的な権限を持つシステム管理者が存在すると、各権利者固有の保護資産にアクセスできることになってしまい、適切なアクセス制御を行うことができない。
また、ＰＬＣでは、いわゆるラダープログラムが用いられることが多いが、このラダープログラムは通常のプログラムと異なり、適切なアクセス制御を行わない限り、権利者以外の者も容易に内容を解釈することができるという性質を持つ。

独立した権限とポリシーを持つ複数の管理者がいる場合のファイル保護システム実現方法として、例えば特許文献１がある。特許文献１では、オペレーティングシステムに独自の拡張保護手段を追加している。
特開２００４−１２６６３４号公報（図１）

従来技術には、次のような課題がある。
拡張アクセス制御ツールや拡張ファイル保護手段のインストールや、拡張アクセス制御ツールでの管理者の設定などに、オペレーションシステムにおける全権限を持つシステム管理者の存在を暗黙的に仮定している。
そのため、文献中に記載の仕組みを導入してもなお、ある管理者が管理するリソースに対して、システム管理者がアクセスする手段が存在してしまう。

本発明は、以上のような課題を解決することを主な目的の一つとし、複数の管理者を設け、管理者が管理する領域を分けることによって、独立したユーザ認証体系およびアクセス制御体系を実現することを主な目的の一つとする。

本発明に係る情報処理装置は、
情報リソースにアクセス可能なユーザを認証するためのユーザ認証情報と、利用禁止状態にあるユーザ認証情報の利用禁止状態を解除してユーザ認証情報を利用可能にするための禁止解除認証情報とを対応付けて記憶する記憶部と、
前記ユーザ認証情報の利用禁止状態を保持するとともに、前記禁止解除認証情報に合致する情報が入力された場合に、前記ユーザ認証情報の利用禁止状態を解除してユーザ認証情報を利用可能にする認証制御部とを有することを特徴とする。

本発明によれば、ユーザ認証情報及びアクセス権限情報の利用禁止状態を保持するとともに、利用禁止状態を解除するための禁止解除認証情報に合致する情報が入力された場合に、ユーザ認証情報及びアクセス権限情報の利用禁止状態を解除してユーザ認証情報及びアクセス権限情報を利用可能にするため、権利者以外には、ユーザ認証情報及びアクセス権限情報の利用禁止状態を解除することができず、複数権利者の情報リソースが一つのシステムに含まれている場合にも、権利者ごとに、情報リソースに対する適切なアクセス制御が可能となる。

実施の形態１．
図１は、本発明の実施の形態１における開発・設定端末（１）の構成を示すものである。
開発・設定端末（１）は、領域制御部（１０１）、記憶部（１０２）、メモリ（１０３）、入出力部（１０４）から構成される。
記憶部（１０２）には、領域ＤＢ（１０５）が含まれる。
開発・設定端末（１）は、情報処理装置の例である。また、領域制御部（１０１）は、認証制御部の例である。

前述したように、ＰＬＣを用いた産業用システムでは、ＰＬＣの動作に必要となるプログラムと各種パラメータが重要な保護資産となるが、例えば、ライブラリの権利者はサードベンダーであり、ベースとなる製造装置のプログラムの権利者は装置メーカー、最終的な製造システム用に追加したプログラムの権利者はエンドユーザになるというように、複数のプログラム権利者の保護資産が一つのシステムに含まれている。
このような複数のプログラム権利者（サードベンダー、装置メーカー、エンドユーザ等）は、各々のプログラム資産に対するユーザ認証、アクセス権限管理を行うために、図１に示す開発・設定端末（１）を用いて、各々のプログラム資産にアクセス可能なユーザ、当該ユーザのアクセス権限を設定する。
プログラム権利者（サードベンダー、装置メーカー、エンドユーザ等）は、それぞれ、図１に示す開発・設定端末（１）を保持しているが、各プログラム権利者が利用する開発・設定端末（１）は共通して図１に示す機能を有する。
なお、ＰＬＣの動作に必要となるプログラム、各種パラメータを情報リソースともいう。また、情報リソースは、単にリソースともいう。

図２は、領域ＤＢ（１０５）の一例を示している。
領域ＤＢ（１０５）には、領域情報（２０１ａ、２０１ｂ）が複数含まれる。
図中では、領域Ａと領域Ｂ用の二つの領域情報が含まれる場合を示している。
領域Ａ用の領域情報（２０１ａ）には、領域管理者認証情報（２０２）、ユーザＤＢ（２０３）、アクセス権ＤＢ（２０４）が含まれる。
図中には示していないが、他の領域用の領域情報にも同様に、領域管理者認証情報、ユーザＤＢ、アクセス権ＤＢが含まれる。

ユーザＤＢ（２０３）には、情報リソースにアクセス可能なユーザを認証するためのユーザ認証情報が格納されている。
また、アクセス権ＤＢ（２０４）には、情報リソースにアクセス可能なユーザのアクセス権限を判定するためのアクセス権限情報が格納されている。
領域管理者認証情報（２０２）は、利用禁止状態にあるユーザ認証情報及びアクセス権限情報の利用禁止状態を解除してユーザ認証情報及びアクセス権限情報を利用可能にするための禁止解除認証情報である。なお、ユーザ認証情報及びアクセス権限情報が利用禁止状態にあるとは、ユーザ認証情報及びアクセス権限情報に対するアクセスができず、ユーザ認証情報及びアクセス権限情報が参照できない状態であることをいう。なお、利用禁止状態は、以降、ロック状態ともいう。
このように、領域ＤＢ（１０５）では、ユーザＤＢ（ユーザ認証情報）及びアクセス権ＤＢ（アクセス権限情報）と、領域管理者認証情報（禁止解除認証情報）を対応付けて記憶している。

ここで、領域とは、同じユーザＤＢとアクセス権ＤＢによってユーザ認証とアクセス権管理が行われる情報リソースの集合である。
領域の設定方法の一つは、プログラム権利者ごとに領域を区切るという方法である。
例えば、領域Ａには、開発・設定端末（１）上のファイルＡ、ＰＬＣ上のプログラムＡとパラメータＡが含まれており、装置メーカーのユーザがアクセスできる、領域Ｂには、開発・設定端末（１）上のファイルＢ、ＰＬＣ上のパラメータＢが含まれており、エンドユーザがアクセスできる、といったように使用する。
つまり、領域とは、プログラム権利者が情報リソースを管理する際の管理単位であり、同じ領域が適用される情報リソースに対しては同じユーザＤＢ、アクセス権ＤＢ、領域管理者認証情報が用いられる。

また、プログラム権利者は、領域を作成して、そのプログラム権利者のユーザ（開発者、保守担当者等）についてのユーザＤＢ、アクセス権ＤＢを生成することができる他、領域を作成して、他のプログラム権利者に他のプログラム権利者のユーザに関するユーザＤＢ、アクセス権ＤＢの生成を許可することもできる。
例えば、プログラム権利者である装置メーカーは、自身が権利を有する情報リソースについて、装置メーカーのユーザ（開発者、保守担当者等）についてのユーザＤＢ、アクセス権ＤＢを生成することができる他、領域を作成して、他のプログラム権利者であるエンドユーザにエンドユーザのユーザに関するユーザＤＢ、アクセス権ＤＢの生成を許可することもできる。

領域制御部（１０１）（認証制御部）は、記憶部（１０２）の領域ＤＢ（１０５）内のユーザＤＢ（２０３）（ユーザ認証情報）及びアクセス権ＤＢ（２０４）（アクセス権限情報）の利用禁止状態を保持するとともに、領域管理者認証情報（２０２）（禁止解除認証情報）に合致する情報が入力された場合に、ユーザＤＢ（２０３）及びアクセス権ＤＢ（２０４）の利用禁止状態を解除してユーザＤＢ（２０３）及びアクセス権ＤＢ（２０４）を利用可能にする。
また、領域制御部（１０１）は、プログラム権利者の指示に基づき、特定の情報リソースに対するユーザＤＢ（２０３）及びアクセス権ＤＢ（２０４）を生成するとともに、生成したユーザＤＢ（２０３）及びアクセス権ＤＢ（２０４）の利用禁止状態を解除して利用可能にするための領域管理者認証情報（２０２）を生成し、記憶部（１０２）に、領域情報（２０１）として、領域管理者認証情報（２０２）、ユーザＤＢ（２０３）及びアクセス権ＤＢ（２０４）を記憶させる。

図３は、ユーザＤＢ（２０３）の一例（ユーザ認証情報）を示している。
ユーザＤＢ（２０３）には、ユーザＩＤとパスワードハッシュの組が保持されている。
ユーザＤＢ（２０３）は、一般的なユーザＩＤ−パスワードの管理テーブルであり、パスワードハッシュは、パスワードでも、パスワードハッシュにソルトと呼ばれる乱数であっても良い。
ユーザをグループ分けして、グループＩＤを付与しても良い。
ユーザＩＤは、開発・設定端末（１）内で一意である必要があるが、付与方法にはいくつかの方法がある。
一つの例は、開発・設定端末（１）内で一意となるように付与する方法である。
二つの目の例は、各領域を一意に識別できる領域ＩＤを設け、領域内で一意となるように付与したユーザＩＤと組み合わせる方法である。この場合、領域ＩＤは暗黙的なものであり、ユーザが直接意識する必要はない。

図４は、アクセス権ＤＢ（２０４）の一例（アクセス権限情報）を示している。
アクセス権ＤＢ（２０４）には、アクセス制御対象の名称と、そのアクセス権限の組が保持されている。
読出し、書込みは、アクセス権限の一例である。アクセス権限の付与は、ユーザ単位、ユーザに付与したグループ単位、ユーザ単位とグループ単位の組合せを単位とする場合などがある。
図４では、ユーザ単位にアクセス権限が付与されており、名称がｆｉｌｅ１である対象は、Ｕｓｅｒ１は読出し（ｒ）と書込み（ｗ）、Ｕｓｅｒ２は読出し（ｒ）、Ｕｓｅｒ３は読出し（ｒ）と書込み（ｗ）のアクセス権限を持っていることを表している。
アクセス権ＤＢ（２０４）は、ユーザＩＤと対象の名称が与えられた時、そのユーザがどんなアクセス権限を持っているかを検索できれば、図４に示した以外の形態であってもかまわない。

本実施の形態では、あるプログラム権利者（プログラム権利者Ｘとする）において情報リソース（プログラム、パラメータ）が生成される場合に、生成された情報リソース、つまり、プログラム権利者Ｘが権利を有する情報リソースに対するユーザＤＢ（２０３）、アクセス権ＤＢ（２０４）及び領域管理者認証情報（２０２）を、プログラム権利者Ｘにおいて情報リソースを管理する領域管理者（情報リソース管理者）が、プログラム権利者Ｘの開発・設定端末（１）の領域制御部（１０１）を用いて生成し、領域情報（２０１）とする。なお、領域管理者は、例えば、システム管理者等である。
プログラム権利者Ｘは、生成した情報リソースを他者に移転する際には、領域情報（２０１）も併せて移転する。
領域情報（２０１）のユーザＤＢ（２０３）及びアクセス権ＤＢ（２０４）は、領域制御部（１０１）の制御により通常はロック状態になっており、領域管理者認証情報（２０２）に一致する情報が入力された場合のみ、ロック状態が解除されて、ユーザＤＢ（２０３）及びアクセス権ＤＢ（２０４）が利用可能となる。
開発・設定端末（１）には、ユーザＤＢ（２０３）を参照してユーザ認証を行うユーザ認証部（不図示）とアクセス権ＤＢ（２０４）を参照してユーザのアクセス権の確認・制限を行うアクセス権制御部（不図示）とが含まれており、ユーザＤＢ（２０３）及びアクセス権ＤＢ（２０４）のロック状態が解除されてユーザＤＢ（２０３）及びアクセス権ＤＢ（２０４）が利用可能となっていないと、ユーザ認証部によるユーザ認証、アクセス権ＤＢによるアクセス権の確認ができず、このため、情報リソースにはアクセスすることができない。
領域管理者認証情報（２０２）は、情報リソースに対する権利を有するプログラム権利者Ｘの領域管理者が設定する情報である。
領域管理者認証情報（２０２）は、基本的に、当該領域管理者以外は知りえない情報である。このため、他のプログラム権利者Ｙは、当該領域管理者が設定した領域ＤＢ（１０５）のユーザＤＢ（２０３）及びアクセス権ＤＢ（２０４）のロック状態を解除することができず、この結果、他のプログラム権利者Ｙは、プログラム権利者Ｘが権利を有する情報リソースにアクセスすることができない。
なお、本実施の形態では、プログラム権利者Ｘの領域管理者が、プログラム権利者Ｘに属するユーザ（開発者、保守担当者等）についてのユーザＤＢ及びアクセス権ＤＢを生成する例を説明する。
後述する実施の形態２では、プログラム権利者Ｘ以外のプログラム権利者に属するユーザにも共通するユーザＤＢ及びアクセス権ＤＢ（共通ユーザＤＢ及び共通アクセス権ＤＢ）を生成する例を説明する。

図５は、新規に領域を作成する際の領域制御部（１０１）の動作を示している。
開発・設定端末（１）は、入出力部（１０４）で、領域管理者から、領域作成要求を受け付けると（Ｓ５０１）、既に領域ＤＢ（１０５）に領域情報が含まれているかを判定する（Ｓ５０２）。
含まれている場合（Ｓ５０２でＹＥＳ）には、入出力部（１０４）で認証情報の受付を行い（Ｓ５０３）、領域制御部（１０１）が認証処理を行う（Ｓ５０４）。
認証情報の一例は、ユーザＩＤとパスワードといった情報であるが、ユーザ（領域管理者）を一意に特定できれば他の情報でもかまわない。
以降の図で現れる認証情報受付における認証情報も、同様である。
認証処理では、入出力部で入力された認証情報が、領域ＤＢ（１０５）に含まれるいずれかの領域情報の領域管理者認証情報と一致するかどうかの確認を行う。
認証処理（Ｓ５０４）により、認証が承認されたかどうかの判定を行い（Ｓ５０５）、否認された場合は終了する。
承認された場合には、領域ＤＢに、新たな領域用の領域情報を作成する（Ｓ５０６）。
Ｓ５０２で、領域情報が含まれていない場合には、直ちにＳ５０６へ動作が移る。

続いて、領域制御部（１０１）は、Ｓ５０６で作成した領域用のユーザＤＢとアクセス権ＤＢの作成を行う（Ｓ５０７）。
ここでは、図２と図３でそれぞれ示したユーザＤＢ（２０３）とアクセス権ＤＢ（２０４）の中身を一時に作成するというよりは、中身を保持するためのＤＢの準備が主である。
ユーザＤＢやアクセス権ＤＢの中身であるユーザデータやアクセス権データは、領域のシステム管理者によって行われるユーザ追加やアクセス権の設定によって生成される。但し、この段階で、ユーザＤＢ（２０３）にユーザデータを登録し、アクセス権ＤＢ（２０４）にアクセス権データを登録してもよい。
Ｓ５０７に続いて、入出力部（１０４）で新たに確保した領域用の認証情報を受け付け、領域情報内の領域管理者認証情報として記録する（Ｓ５０８）。
受け付けた領域管理者認証情報あるいは、領域管理者認証情報を元に生成した鍵情報を用いて、作成した領域情報の暗号化を行い（Ｓ５０９）、ロック状態への切り替えを行う（Ｓ５１０）。
ロック状態は、領域管理者の認証情報の受付けや、領域作成要求の受付け等を行うための状態であり、開発・設定端末（１）内のリソースを利用できない状態である。

ここで、領域情報が既にある場合は、認証情報を入力、認証後、領域を作成できる（Ｓ５０２→Ｓ５０３→Ｓ５０４→Ｓ５０５→Ｓ５０６）が、この手順について具体的に説明する。
以下では、装置メーカーが新規に領域を作成し、エンドユーザが、装置メーカーが作成した領域にエンドユーザ用の領域を追加する場合について説明する。
先ず、領域が存在しない状態で、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、新規に領域を作成する（Ｓ５０２→Ｓ５０６）。
次に、領域作成後（Ｓ５０６〜Ｓ５０７）、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、装置メーカー用の領域管理者認証情報を登録する（Ｓ５０８〜Ｓ５０９）。
そして、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、領域情報をロック状態へ切り替える（Ｓ５１０）。
次に、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、エンドユーザ用の領域作成のため、装置メーカーの認証情報で認証を行う（Ｓ５０１〜Ｓ５０５）。
また、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、エンドユーザ用の仮の領域管理者認証情報を登録する（Ｓ５０８〜Ｓ５０９）。
そして、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、領域情報をロック状態へ切り替える（Ｓ５１０）。
この状態で、装置メーカーはエンドユーザへ情報リソース及び領域情報を渡す。
エンドユーザは、装置メーカーから伝えられた仮の領域管理者認証情報を基に、エンドユーザの開発・設定端末（１）にて、領域を使用し、エンドユーザのユーザ（開発者、保守担当者等）についてのユーザＤＢ（２０３）及びアクセス権ＤＢ（２０４）を生成する（Ｓ５０１〜Ｓ５０７）。
また、エンドユーザは、エンドユーザの開発・設定端末（１）にて、仮の領域管理者認証情報を、エンドユーザの領域管理者認証情報へ変更する（Ｓ５０８〜Ｓ５０９）。
このように、受け渡し時には仮の領域管理者認証情報を設定して、ロック状態へしておくことによって、部外者が勝手に領域を追加することを防止することができる。

本実施の形態では、このように、開発・設定端末（１）の領域制御部（１０１）は、他の開発・設定端末（１）を利用する領域管理者（上記の例では、エンドユーザの領域管理者）に特定の情報リソースに対するユーザＤＢ（ユーザ認証情報）及びアクセス権ＤＢ（アクセス権限情報）の生成が許可されていることを他の開発・設定端末（１）（上記の例では、エンドユーザの開発・設定端末）において認証するための認証情報（仮の領域管理者認証情報）を生成する。

また、逆に、開発・設定端末（１）の記憶部（１０２）は、他の開発・設定端末（１）（上記の例では、装置メーカーの開発・設定端末）により生成された認証情報であって、他の開発・設定端末（１）を利用する領域管理者（上記の例では、装置メーカーの領域管理者）に管理権限がある他管理権限情報リソースに対するユーザＤＢ（ユーザ認証情報）及びアクセス権ＤＢ（アクセス権限情報）の生成が当該開発・設定端末（１）を利用する領域管理者（上記の例では、エンドユーザの領域管理者）に許可されていることを認証するための認証情報（仮の領域管理者認証情報）を記憶している。この仮の領域管理者認証情報は、生成許可認証情報の例となる。
そして、領域制御部（１０１）は、仮の領域管理者認証情報に合致する情報が入力された場合に、特定の情報リソースに対するユーザＤＢ及びアクセス権ＤＢを生成するとともに、生成したユーザＤＢ（ユーザ認証情報）及びアクセス権ＤＢ（アクセス権限情報）を利用可能にするための領域管理者認証情報（禁止解除認証情報）を生成する。

図６は、ロック状態から特定の領域へ遷移する際の領域制御部（１０１）の動作を示している。
ここでの領域とは、ある領域情報に含まれるユーザＤＢとアクセス権ＤＢに基づいて、ユーザ認証およびリソースのアクセス制御を行う状態のことをいう。
例えば、産業用システムの権利者の一人である装置メーカーが定めたユーザ体系やアクセス権に基づいて、リソースへのアクセス制御が行われている状態を指す。
開発・設定端末（１）は、入出力部（１０４）で、領域管理者から認証情報を受け付け（Ｓ６０１）、領域制御部（１０１）が認証処理を行う（Ｓ６０２）。
Ｓ６０１はＳ５０３と、Ｓ６０２はＳ５０４とそれぞれ同様である。
認証処理（Ｓ６０２）では、入出力部（１０４）で入力された認証情報が、領域ＤＢ（１０５）に含まれるいずれかの領域情報の領域管理者認証情報と一致するかどうかの確認を行う。
認証処理（Ｓ６０２）により、認証が承認されたかどうかの判定を行い（Ｓ６０３）、否認された場合（Ｓ６０３でＮＯ）は終了する。
承認された場合（Ｓ６０３でＹＥＳ）には、領域制御部（１０１）は、認証情報あるいは認証情報を元に生成した鍵情報を用いて、承認された領域情報を復号化する（Ｓ６０４）。
領域制御部（１０１）は、復号された領域情報に含まれるユーザＤＢ（２０３）とアクセス権ＤＢ（２０４）を取り出して、メモリ（１０３）あるいは記憶部（１０２）に展開し、ユーザ認証やアクセス権制御に利用できる状態にする（Ｓ６０５）。

図７は、特定の領域からロック状態へ遷移する際の領域制御部（１０１）の動作を示している。
開発・設定端末（１）は、入出力部（１０４）で、領域管理者から領域閉鎖要求を受け付ける（Ｓ７０１）。
領域制御部（１０１）は、メモリ（１０３）あるいは記憶部（１０２）に展開し、ユーザ認証やアクセス権制御に利用できる状態にあるユーザＤＢとアクセス権ＤＢを領域情報へ保存する（Ｓ７０２）。
また、領域制御部（１０１）は、領域情報の領域管理者認証情報（２０２）あるいは、領域管理者認証情報を元に生成した鍵情報を用いて、作成した領域情報の暗号化を行い（Ｓ７０３）、ロック状態への切り替えを行う（Ｓ７０４）。
図には示していないが、領域閉鎖要求受付けの前あるいは後に、確認及び領域管理者のみが領域閉鎖を行えるようにするために、領域管理者認証情報の受付けと認証処理を行っても良い。

図８は、特定の領域情報を削除する際の領域制御部（１０１）の動作を示している。
開発・設定端末（１）は、入出力部（１０４）で、領域管理者から領域削除要求を受け付けると（Ｓ８０１）、続いて認証情報を受付け（Ｓ８０２）、その後、認証処理を行う（Ｓ８０３）。
Ｓ８０２とＳ８０３は、それぞれＳ５０３とＳ５０４と同様である。
認証処理によって否認と判定されると（Ｓ８０４）、そのまま終了する。
承認と判定されると、承認された領域の領域情報を領域ＤＢ（１０５）から削除する（Ｓ８０５）。最後に、ロック状態へ切り替えを行う（Ｓ８０６）。

以上、本実施の形態では、次の特徴を備えたユーザ認証・アクセス権限管理方式について説明した。
（１）複数の管理者を設け、各管理者は、それぞれ管理対象となるリソース（ファイルなど）を持っている。
（２）各管理者は、それぞれが独自にユーザ認証管理と、所有するリソースへのアクセス権管理を行う。これらの情報は、リソースの利用停止状態時には、管理者の認証情報を用いて暗号化される。

実施の形態２．
本実施の形態に係る開発・設定端末（１）の構成は、図１に示したものと同様であり、開発・設定端末（１）は、領域制御部（１０１）、記憶部（１０２）、メモリ（１０３）、入出力部（１０４）から構成される。記憶部（１０２）には、領域ＤＢ（１０５）が含まれる。

図９は、実施の形態２における領域ＤＢ（１０５）の一例を示している。
領域ＤＢ（１０５）には、複数の領域情報（２０１ａ、２０１ｂ）と共通領域情報（３０１）が含まれる。
図中では、領域Ａと領域Ｂ用の二つの領域情報が含まれる場合を示している。図中には示していないが、領域情報（２０１ａ、２０１ｂ）は、図２の場合と同様に、領域管理者認証情報（２０２）、ユーザＤＢ（２０３）、アクセス権ＤＢ（２０４）が含まれる。
共通領域情報（３０１）には、領域管理者認証情報（３０２）、共通ユーザＤＢ（３０３）、共通アクセス権ＤＢ（３０４）が含まれる。
ユーザＤＢ（２０３）とアクセス権ＤＢ（２０４）は、それぞれ実施の形態１の場合の図２と図３と同様である。

図１０は、共通ユーザＤＢ（３０３）の一例を示している。
共通ユーザＤＢ（３０３）には、ユーザＩＤとパスワードハッシュ、そのユーザＩＤの所有者の組が保持されている。
共通ユーザＤＢ（３０３）のうちユーザＩＤとパスワードハッシュは、一般的なユーザＩＤ−パスワードの管理テーブルであり、パスワードハッシュは、パスワードでも、パスワードハッシュにソルトと呼ばれる乱数であっても良い。
ユーザをグループ分けして、グループＩＤを付与しても良い。
ユーザＩＤおよびパスワードハッシュと、その所有者との関係を示す方法は、図１０に示したようにテーブル中の各エントリーに所有者を記す方法や、ユーザＩＤ−パスワード管理テーブルの各エントリーの所有者を記した所有者テーブルを別に設けるといった方法がある。
ユーザＩＤ、パスワードハッシュ、所有者が関連付けられていれば、他の方法でも良い。
ここでいう所有者は、領域を意味する。
ユーザＩＤの付与方法にはいくつかの方法があり、一つの例は、開発・設定端末１内で一意となるように付与する方法である。
二つの目の例は、共通領域を一意に識別できる領域ＩＤを設け、共通領域内で一意となるように付与したユーザＩＤと組み合わせる方法である。
ユーザＩＤは、開発・設定端末（１）内で一意である必要がある。
共通ユーザＤＢ（３０３）は、パスワードハッシュを含めてユーザ認証に用いるほか、図１０のＵｓｅｒｓ３のように、パスワードハッシュを含めないことも可能とする。含めない場合には、領域情報（２０１ａ、２０１ｂ）のユーザＤＢ（２０３）に登録されているユーザと関連付けを行い、ユーザＤＢ（２０３）の情報を用いて認証を行う。

図１１は、共通アクセス権ＤＢ（３０４）の一例を示している。
共通アクセス権ＤＢ（３０４）には、アクセス制御対象の名称とアクセス権限、対象の所有者の組が保持されている。
アクセス制御対象の名称およびアクセス権限と、その所有者との関係を示す方法は、図１１に示したようにテーブル中の各エントリーに所有者を記す方法や、アクセス制御対象の名称およびアクセス権限の関係を示すテーブルに加え、各所有者が保持するアクセス制御対象を示したテーブルを別に設けるといった方法もある。
アクセス制御対象の名称およびアクセス権限と、その所有者が関連付けられていれば、他の方法でも良い。
読出し、書込みは、アクセス権限の一例である。アクセス権限の付与は、ユーザ単位、ユーザに付与したグループ単位、ユーザ単位とグループ単位の組合せを単位とする場合、領域単位などがある。
図１１では、名称がｆｉｌｅ１である対象は、Ｕｓｅｒ２は読出し（ｒ）と書込み（ｗ）、Ｕｓｅｒｓ３は読出し（ｒ）のアクセス権限を持っていることを表している。
共通アクセス権ＤＢ（３０４）は、ユーザＩＤと対象の名称が与えられた時、そのユーザがどんなアクセス権限を持っているかを検索できれば、図１１に示した以外の形態であってもかまわない。
また、領域を示すには、開発・設定端末（１）内で一意である領域ＩＤを各領域に付与し、それに基づくといった方法をとる。

実施の形態１では、ある領域ユーザは、別の領域のリソース（例えばパラメータ）にアクセスすることはできない。
実施の形態２では、別の領域からアクセスできるような設定をあらかじめリソースに対して行っておくことで、ある領域のユーザが、別の領域のリソースに対してもアクセスできる仕組みを導入している。
例えば、ＲｅｇｉｏｎＡの領域管理者は、ＲｅｇｉｏｎＡのリソースであるｆｉｌｅ１を、他の領域からアクセスできるようにすることができる。この時、ＲｅｇｉｏｎＡの領域管理者は、他の領域のどのユーザに対し、どんなアクセス権限を与えるのかを指定することができる。
図１１では、ＲｅｇｉｏｎＡの領域管理者が、ＲｅｇｉｏｎＡのリソースであるｆｉｌｅ１に対して、ＲｅｇｉｏｎＢのＵｓｅｒ２に対して読出し（ｒ）と書込み（ｗ）、ＲｅｇｉｏｎＢのＵｓｅｒｓ３には読出し（ｒ）が与えられていることを示している。
図１０のＵｓｅｒ１とＵｓｅｒ２は、他の領域とは独立して設定されたユーザになる。
Ｕｓｅｒｓ３は、各領域のユーザＤＢで登録されたユーザと関連付けて用いる。
ＲｅｇｉｏｎＢのＵｓｅｒＢがＵｓｅｒｓ３と関連付けられているとすると（Ｕｓｅｒｓ３とＲｅｇｉｏｎＢの関連付けは、ここでは記載していない。また、関連付けの方法は問わない）、図１１の場合、ＵｓｅｒＢはＲｅｇｉｏｎＡのｆｉｌｅ１及びｆｉｌｅ２に対して読出し（ｒ）権限が与えられていることになる。

このように、本実施の形態では、領域制御部（１０１）は、開発・設定端末（１）を利用する領域管理者（情報リソース管理者）に管理権限がある情報リソースであって当該領域管理者の管理下にないユーザもアクセス可能な共通情報リソースに対するユーザ認証情報及びアクセス権限情報を共通ユーザＤＢ（３０３）（共通ユーザ認証情報）及び共通アクセス権ＤＢ（３０４）（共通アクセス権限情報）として生成するとともに、生成した共通ユーザＤＢ（３０３）及び共通アクセス権ＤＢ（３０４）の利用禁止状態を解除して利用可能にするための領域管理者認証情報（３０２）（禁止解除認証情報）を生成し、記憶部（１０２）は、領域制御部（１０１）により生成された共通ユーザＤＢ（３０３）と、共通アクセス権ＤＢ（３０４）と、領域管理者認証情報（３０２）とを対応付けて記憶する。

また、逆に、開発・設定端末（１）の記憶部（１０２）は、特定のプログラム権利者の領域管理者（情報リソース管理者）に管理権限がある情報リソースであって特定のプログラム権利者の領域管理者の管理下にないユーザもアクセス可能な共通情報リソースに対して生成されたユーザ認証情報及びアクセス権限情報を共通ユーザＤＢ（３０３）（共通ユーザ認証情報）及び共通アクセス権ＤＢ（３０４）（共通アクセス権限情報）として記憶するとともに、共通ユーザＤＢ（３０３）及び共通アクセス権ＤＢ（３０４）の利用禁止状態を解除して利用可能にするための領域管理者認証情報（３０２）（禁止解除認証情報）を、共通ユーザＤＢ（３０３）及び共通アクセス権ＤＢ（３０４）に対応付けて記憶する。
また、領域制御部（１０１）（認証制御部）は、共通ユーザＤＢ（３０３）及び共通アクセス権ＤＢ（３０４）の利用禁止状態を保持するとともに、領域管理者認証情報（３０２）に合致する情報が入力された場合に、共通ユーザＤＢ（３０３）及び共通アクセス権ＤＢ（３０４）の利用禁止状態を解除して共通ユーザＤＢ（３０３）及び共通アクセス権ＤＢ（３０４）を利用可能にする。

図１２は、新規に領域を作成する際の領域制御部（１０１）の動作を示している。
開発・設定端末（１）は、入出力部（１０４）で、領域管理者から、領域作成要求を受け付けると（Ｓ１２０１）、既に領域ＤＢ（１０５）に領域情報が含まれているかを判定する（Ｓ１２０２）。
含まれている場合には、入出力部（１０４）で認証情報の受付を行い（Ｓ１２０３）、領域制御部（１０１）が認証処理を行う（Ｓ１２０４）。
認証情報の一例は、ユーザＩＤとパスワードといった情報であるが、ユーザを一意に特定できれば他の情報でもかまわない。
認証処理では、入出力部で入力された認証情報が、領域ＤＢ（１０５）に含まれるいずれかの領域情報の領域管理者認証情報と一致するかどうかの確認を行う。
認証処理（Ｓ１２０４）により、認証が承認されたかどうかの判定を行い（Ｓ１２０５）、否認された場合は終了する。
承認された場合には、領域ＤＢに、新たな領域用の領域情報を作成する（Ｓ１２０６）。
Ｓ１２０２で、領域情報が含まれていない場合には、直ちにＳ１２０６へ動作が移る。

続いて、領域制御部（１０１）は、Ｓ１２０６で作成した領域用のユーザＤＢとアクセス権ＤＢの作成を行う（Ｓ１２０７）。
ここでは、図２と図３でそれぞれ示したユーザＤＢ（２０３）とアクセス権ＤＢ（２０４）の中身を一時に作成するというよりは、中身を保持するためのＤＢの準備が主である。
ユーザＤＢやアクセス権ＤＢの中身であるユーザデータやアクセス権データは、領域のシステム管理者によって行われるユーザ追加やアクセス権の設定によって生成される。但し、この段階で、ユーザＤＢ（２０３）にユーザデータを登録し、アクセス権ＤＢ（２０４）にアクセス権データを登録してもよい。
Ｓ１２０７に続いて、入出力部（１０４）で、新たに確保した領域用の認証情報を受け付け、領域情報内の領域管理者認証情報として記録する（Ｓ１２０８）。
受け付けた領域管理者認証情報あるいは、領域管理者認証情報を基に生成した鍵情報を用いて、作成した領域情報の暗号化を行う（Ｓ１２０９）。

次に、領域制御部（１０１）は、既に共通領域情報（３０１）が存在しているかどうかを判定し（Ｓ１２１０）、存在していない場合には、共通領域情報を作成し（Ｓ１２１１）、共通領域用の共通ユーザＤＢ（３０３）と共通アクセス権ＤＢ（３０４）を作成する（Ｓ１２１２）。
ここでは、図１０と図１１でそれぞれ示した共通ユーザＤＢ（３０３）と共通アクセス権ＤＢ（３０４）の中身を一時に作成するというよりは、中身を保持するためのＤＢの準備が主である。
共通ユーザＤＢ（３０３）や共通アクセス権ＤＢ（３０４）の中身であるユーザデータやアクセス権データは、リソースの所有者となる領域管理者によって行われるユーザ追加やアクセス権の設定によって生成される。但し、この段階で、共通ユーザＤＢ（３０３）にユーザデータを登録し、共通アクセス権ＤＢ（３０４）にアクセス権データを登録してもよい。
次に、領域制御部（１０１）は、Ｓ１２０８で受け付けた領域用の認証情報を、共通領域情報の領域管理者認証情報へ登録する（Ｓ１２１３）。
Ｓ１２１０で、共通領域情報が存在する場合には、領域制御部（１０１）は、共通領域情報の復号化を行った後（Ｓ１２１６）、Ｓ１２１３の処理を行う。
共通領域情報の領域管理者認証情報には、複数の領域の領域管理者認証情報が含まれる場合がある。
続いて、領域制御部（１０１）は、共通領域情報の暗号化を行う（Ｓ１２１４）。
暗号化した共通領域情報は、複数の領域管理者が、個別に復号できる必要がある。
そのための方法の一つは、暗号化時に任意の鍵を生成し、生成した鍵で共通領域情報を暗号化し、共通領域情報の暗号化に用いた鍵を、各領域管理者認証情報あるいは各領域管理者認証情報を基に生成した鍵情報を用いて、暗号化して、暗号化した共通領域情報と共に保存するといった方法がある。
Ｓ１２１４に続いて、領域制御部（１０１）は、ロック状態への切り替えを行う（Ｓ１２１５）。
ロック状態は、領域管理者の認証情報の受付けや、領域作成要求の受付け等を行うための状態であり、開発・設定端末（１）内のリソースを利用できない状態である。

ここで、領域情報が既にある場合は、認証情報を入力、認証後、領域を作成できる（Ｓ１２０２→Ｓ１２０３→Ｓ１２０４→Ｓ１２０５→Ｓ１２０６）が、この手順について具体的に説明する。
以下では、装置メーカーが新規に領域を作成し、エンドユーザが、装置メーカーが作成した領域にエンドユーザ用の領域を追加する場合について説明する。
先ず、領域が存在しない状態で、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、装置メーカーが新規に領域を作成する（Ｓ１２０２→Ｓ１２０６）。
領域作成後（Ｓ１２０６〜Ｓ１２０７）、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、装置メーカー用の領域管理者認証情報を登録する（Ｓ１２０８〜Ｓ１２０９）。
共通領域作成後（Ｓ１２１０〜Ｓ１２１２）、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、Ｓ１２０８で受付けた認証情報を、共通領域情報管理用の領域管理者認証情報として登録する（Ｓ１２１３）。
次に、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、Ｓ１２１３の認証情報で、共通領域情報を暗号化する（Ｓ１２１４）。
そして、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、共通領域情報をロック状態へ切り替える（Ｓ１２１５）。
また、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、エンドユーザ用の領域作成のため、装置メーカーの領域管理者認証情報で認証を行う（Ｓ１２０１〜Ｓ１２０５）。
そして、領域作成後（Ｓ１２０６〜Ｓ１２０７）、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、エンドユーザ用の仮の領域管理者認証情報を登録する（Ｓ１２０８〜Ｓ１２０９）。
また、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、Ｓ１２０４の装置メーカーの認証情報で、共通領域情報を復号化後（Ｓ１２１６）、Ｓ１２０８で受付けたエンドユーザ用の仮の領域管理者認証情報を、共通領域情報管理用の認証情報として登録する（Ｓ１２１３）。
そして、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、共通領域情報を暗号化する（Ｓ１２１４）。
最後に、装置メーカーが、装置メーカーにおける開発・設定端末（１）にて、共通領域情報をロック状態へ切り替える（Ｓ１２１５）。
この状態で、装置メーカーはエンドユーザへ情報リソース及び共通領域情報を渡す。
エンドユーザは、装置メーカーから伝えられた仮の領域管理者認証情報を基に、エンドユーザの開発・設定端末（１）にて、領域を使用し、エンドユーザのユーザ（開発者、保守担当者等）についての共通ユーザＤＢ（３０３）及び共通アクセス権ＤＢ（３０４）を生成する（Ｓ１２０１〜Ｓ１２０７）。具体的には、装置メーカーにより生成されている共通ユーザＤＢ（３０３）及び共通アクセス権ＤＢ（３０４）にエンドユーザのユーザデータ、アクセス権データを追加する。
また、エンドユーザは、エンドユーザの開発・設定端末（１）にて、仮の領域管理者認証情報を、エンドユーザの領域管理者認証情報へ変更する（Ｓ１２０８〜Ｓ１２０９）。
これにより、エンドユーザは、共通領域情報の共通ユーザＤＢにエンドユーザのユーザ（開発者、保守担当者等）を設定することができ、また、共通領域情報のアクセス権ＤＢにエンドユーザのユーザについてのアクセス権を設定することができる。

ここで、前述のように、暗号化した共通領域情報は、複数の領域管理者が、個別に復号できる必要がある。
そのための方法の一つは、暗号化時に任意の鍵を生成し、生成した鍵で共通領域情報を暗号化し、共通領域情報の暗号化に用いた鍵を、各領域管理者認証情報あるいは各領域管理者認証情報を基に生成した鍵情報を用いて、暗号化して、暗号化した共通領域情報と共に保存するといった方法がある。Ｓ１２１４では、このような方法を用いる。
例えば、共通領域情報暗号化用の乱数を生成し、それを鍵にして共通領域情報を暗号化する。続いて、その鍵を、装置メーカーの領域管理者認証情報で暗号化する。さらに共通領域情報の暗号化に用いた鍵を、エンドユーザの仮の領域管理者認証情報で暗号化する。共通領域情報が暗号化された状態の実現方法の一つは、（１）乱数を鍵として暗号化した共通領域情報、（２）装置メーカーの管理者認証情報で暗号化した（１）の鍵、（３）エンドユーザの管理者認証情報で暗号化した（１）の鍵、の３つで構成されることになる。

図１３は、ロック状態から特定の領域へ遷移する際の領域制御部（１０１）の動作を示している。
開発・設定端末（１）は、入出力部（１０４）で、領域管理者から認証情報を受け付け（Ｓ１３０１）、認証処理を行う（Ｓ１３０２）。
Ｓ１３０１はＳ１２０３と、Ｓ１３０２はＳ１２０４とそれぞれ同様である。
認証処理（Ｓ１３０２）では、入出力部で入力された認証情報が、領域ＤＢ（１０５）に含まれるいずれかの領域情報の領域管理者認証情報と一致するかどうかの確認を行う。
認証処理（Ｓ１３０２）により、認証が承認されたかどうかの判定を行い（Ｓ１３０３）、否認された場合は終了する。
承認された場合には、認証情報あるいは認証情報を元に生成した鍵情報を用いて、承認された領域情報を復号する（Ｓ１３０４）。
復号された領域情報に含まれるユーザＤＢとアクセス権ＤＢを取り出して、メモリ（１０３）あるいは記憶部（１０２）に展開し、ユーザ認証やアクセス権制御に利用できる状態にする（Ｓ１３０５）。
続いて、領域制御部（１０１）は、共通領域が存在するかどうかを判定する（Ｓ１３０６）。
判定は、共通領域情報が存在するか否かで行い、存在しない場合には終了する。
存在する場合には、共通領域情報を復号する（Ｓ１３０７）。
Ｓ１２１４で説明した方法をとる場合、まず認証情報あるいは認証情報を元に生成した鍵情報を用いて、共通領域情報を暗号化した鍵を復号し、その後に、復号した鍵を用いて共通領域情報を復号する。
復号された共通領域情報に含まれるユーザＤＢとアクセス権ＤＢを取り出して、メモリ（１０３）あるいは記憶部（１０２）に展開し、ユーザ認証やアクセス権制御に利用できる状態にする（Ｓ１３０８）。

図１４は、特定の領域からロック状態へ遷移する際の領域制御部（１０１）の動作を示している。
開発・設定端末（１）は、入出力部（１０４）で、領域管理者から領域閉鎖要求を受け付ける（Ｓ１４０１）。
メモリ（１０３）あるいは記憶部（１０２）に展開され、ユーザ認証やアクセス権制御に利用できる状態にあるユーザＤＢとアクセス権ＤＢを領域情報へ保存する（Ｓ１４０２）。
領域情報の領域管理者認証情報（２０２）あるいは、領域管理者認証情報を元に生成した鍵情報を用いて、作成した領域情報の暗号化を行い（Ｓ１４０３）、共通領域が存在するかどうかを判定する（Ｓ１４０４）。
判定は、共通領域情報が存在するか否かで行い、存在しない場合には終了する。存在する場合には、メモリ（１０３）あるいは記憶部（１０２）に展開され、共通ユーザ認証やアクセス権制御に利用できる状態にある共通ユーザＤＢと共通アクセス権ＤＢを共通領域情報へ保存し（Ｓ１４０５）、共通領域情報を暗号化する（Ｓ１４０６）。
共通領域情報の暗号化は、Ｓ１２１４と同様に行う。
最後にロック状態への切り替えを行う（Ｓ１４０７）。
図には示していないが、領域閉鎖要求受付けの前あるいは後に、確認及び領域管理者のみが領域閉鎖を行えるようにするために、領域管理者認証情報の受付けと認証処理を行っても良い。

図１５は、特定の領域情報を削除する際の領域制御部（１０１）の動作を示している。
開発・設定端末（１）は、入出力部（１０４）で、領域管理者から領域削除要求を受け付けると（Ｓ１５０１）、続いて認証情報を受付け（Ｓ１５０２）、その後、認証処理を行う（Ｓ１５０３）。
Ｓ１５０２とＳ１５０３は、それぞれＳ１２０３とＳ１２０４と同様である。
認証処理によって否認と判定されると（Ｓ１５０４）、そのまま終了する。
承認と判定されると、承認された領域の領域情報を領域ＤＢ（１０５）から削除する（Ｓ１５０５）。
他の領域があるかどうかを領域情報の有無で判定し（Ｓ１５０６）、存在しない場合には、共通領域情報を削除し（Ｓ１５０７）、ロック状態へ切り替えを行う（Ｓ１５０８）。
存在する場合には、メモリ（１０３）あるいは記憶部（１０２）に展開されている共通アクセス権ＤＢから、削除する領域が所有している共通ユーザのアクセス権を削除し（Ｓ１５０９）、同じくメモリ（１０３）あるいは記憶部（１０２）に展開されている共通ユーザＤＢから、削除する領域が所有している共通ユーザを削除する（Ｓ１５１０）。
メモリ（１０３）あるいは記憶部（１０２）に展開され、ユーザ認証やアクセス権制御に利用できる状態にある共通ユーザＤＢと共通アクセス権ＤＢを共通領域情報へ保存した後（Ｓ１５１１）、共通領域情報を暗号化する（Ｓ１５１２）。
最後に、ロック状態へ切り替える（Ｓ１５０８）。

以上、本実施の形態では、共通して利用するリソースは、一人の管理者が所有者となり、リソースの管理を行う。所有者は、共通して利用するリソースに対して、他の管理者が管理するユーザに対するアクセス権も付与できるようにするユーザ認証・アクセス権限管理方式について説明した。

最後に実施の形態１、２に示した開発・設定端末（１）のハードウェア構成例について説明する。
図１６は、実施の形態１、２に示す開発・設定端末（１）のハードウェア資源の一例を示す図である。なお、図１６の構成は、あくまでも開発・設定端末（１）のハードウェア構成の一例を示すものであり、開発・設定端末（１）のハードウェア構成は図１６に記載の構成に限らず、他の構成であってもよい。

図１６において、開発・設定端末（１）は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部の一例である。
通信ボード９１５、キーボード９０２、スキャナ装置９０７、ＦＤＤ９０４などは、入力部、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力部、出力装置の一例である。

通信ボード９１５は、例えば、通信ボード９１５は、ＬＡＮ（ローカルエリアネットワーク）、インターネット、ＷＡＮ（ワイドエリアネットワーク）などに接続されていても構わない。
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。

上記プログラム群９２３には、例えば、実施の形態１、２の説明において「領域制御部」として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
ファイル群９２４には、実施の形態１、２の説明において、「〜の判断」、「〜の計算」、「〜の比較」、「〜の作成」、「〜の更新」、「〜の設定」、「〜の登録」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリになどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１、２で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。

また、実施の形態１、２の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」、であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、実施の形態１、２の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１、２の「〜部」の手順や方法をコンピュータに実行させるものである。

このように、実施の形態１、２に示す開発・設定端末（１）は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータであり、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。

実施の形態１に係る開発・設定端末の構成例を示す図。 実施の形態１に係る領域ＤＢの例を示す図。 実施の形態１に係るユーザＤＢの例を示す図。 実施の形態１に係るアクセス権ＤＢの例を示す図。 実施の形態１に係る新規に領域を作成する際の動作例を示すフローチャート図。 実施の形態１に係るロック状態から特定の領域へ遷移する際の動作例を示すフローチャート図。 実施の形態１に係る特定の領域からロック状態へ遷移する際の動作例を示すフローチャート図。 実施の形態１に係る特定の領域情報を削除する際の動作例を示すフローチャート図。 実施の形態２に係る領域ＤＢの例を示す図。 実施の形態２に係る共通ユーザＤＢの例を示す図。 実施の形態２に係る共通アクセス権ＤＢの例を示す図。 実施の形態２に係る新規に領域を作成する際の動作例を示すフローチャート図。 実施の形態２に係るロック状態から特定の領域へ遷移する際の動作例を示すフローチャート図。 実施の形態２に係る特定の領域からロック状態へ遷移する際の動作例を示すフローチャート図。 実施の形態２に係る特定の領域情報を削除する際の動作例を示すフローチャート図。 実施の形態１、２に係る開発・設定端末のハードウェア構成例を示す図。

符号の説明

１ 開発・設定端末、１０１ 領域制御部、１０２ 記憶部、１０３ メモリ、１０４ 入出力部、１０５ 領域ＤＢ、２０１ 領域情報、２０２ 領域管理者認証情報、２０３ ユーザＤＢ、２０４ アクセス権ＤＢ、３０１ 共通領域情報、３０２ 領域管理者認証情報、３０３ 共通ユーザＤＢ、３０４ 共通アクセス権ＤＢ。

Claims (12)

1. 情報リソースにアクセス可能なユーザを認証するためのユーザ認証情報と、利用禁止状態にあるユーザ認証情報の利用禁止状態を解除してユーザ認証情報を利用可能にするための禁止解除認証情報とを対応付けて記憶する記憶部と、
   前記ユーザ認証情報の利用禁止状態を保持するとともに、前記禁止解除認証情報に合致する情報が入力された場合に、前記ユーザ認証情報の利用禁止状態を解除してユーザ認証情報を利用可能にする認証制御部とを有することを特徴とする情報処理装置。
2. 前記記憶部は、
   情報リソースにアクセス可能なユーザを認証するためのユーザ認証情報と、前記情報リソースにアクセス可能なユーザのアクセス権限を判定するためのアクセス権限情報と、利用禁止状態にあるユーザ認証情報及びアクセス権限情報の利用禁止状態を解除してユーザ認証情報及びアクセス権限情報を利用可能にするための禁止解除認証情報とを対応付けて記憶し、
   前記認証制御部は、
   ユーザ認証情報及びアクセス権限情報の利用禁止状態を保持するとともに、禁止解除認証情報に合致する情報が入力された場合に、ユーザ認証情報及びアクセス権限情報の利用禁止状態を解除してユーザ認証情報及びアクセス権限情報を利用可能にすることを特徴とする請求項１に記載の情報処理装置。
3. 前記認証制御部は、
   特定の情報リソースに対するユーザ認証情報及びアクセス権限情報を生成するとともに、生成したユーザ認証情報及びアクセス権限情報の利用禁止状態を解除して利用可能にするための禁止解除認証情報を生成し、
   前記記憶部は、
   前記認証制御部により生成されたユーザ認証情報と、アクセス権限情報と、禁止解除認証情報とを対応付けて記憶することを特徴とする請求項２に記載の情報処理装置。
4. 前記認証制御部は、
   他の情報処理装置を利用する情報リソース管理者に特定の情報リソースに対するユーザ認証情報及びアクセス権限情報の生成が許可されていることを前記他の情報処理装置において認証するための認証情報を生成することを特徴とする請求項２又は３に記載の情報処理装置。
5. 前記記憶部は、
   他の情報処理装置により生成された認証情報であって、前記他の情報処理装置を利用する情報リソース管理者に管理権限がある他管理権限情報リソースに対するユーザ認証情報及びアクセス権限情報の生成が前記情報処理装置を利用する情報リソース管理者に許可されていることを認証するための認証情報を生成許可認証情報として記憶し、
   前記認証制御部は、
   生成許可認証情報に合致する情報が入力された場合に、前記特定の情報リソースに対するユーザ認証情報及びアクセス権限情報を生成するとともに、生成したユーザ認証情報及びアクセス権限情報を利用可能にするための禁止解除認証情報を生成することを特徴とする請求項２〜４のいずれかに記載の情報処理装置。
6. 前記記憶部は、
   禁止解除認証情報と、前記禁止解除認証情報を用いて暗号化された暗号化ユーザ認証情報と、前記禁止解除認証情報を用いて暗号化された暗号化アクセス権限情報とを対応付けて記憶し、
   前記認証制御部は、
   暗号化ユーザ認証情報及び暗号化アクセス権限情報の利用禁止状態を保持するとともに、前記禁止解除認証情報に合致する情報が入力された場合に、暗号化ユーザ認証情報及び暗号化アクセス権限情報を前記禁止解除認証情報を用いて復号化してユーザ認証情報及びアクセス権限情報を利用可能にすることを特徴とする請求項２〜５のいずれかに記載の情報処理装置。
7. 前記記憶部は、
   複数の情報リソースに対して生成された複数のユーザ認証情報とアクセス権限情報と禁止解除認証情報との組を記憶し、
   前記認証制御部は、
   各組のユーザ認証情報及びアクセス権限情報を利用禁止状態に保持するとともに、いずれかの禁止解除認証情報に合致する情報が入力された場合に、当該禁止解除認証情報に対応付けられているユーザ認証情報及びアクセス権限情報の利用禁止状態のみを解除することを特徴とする請求項２〜６のいずれかに記載の情報処理装置。
8. 前記記憶部は、
   他の情報処理装置を利用する情報リソース管理者に管理権限がある複数の他管理権限情報リソースに対して生成された複数のユーザ認証情報とアクセス権限情報と禁止解除認証情報との組を記憶することを特徴とする請求項７に記載の情報処理装置。
9. 前記記憶部は、
   特定の情報リソース管理者に管理権限がある情報リソースであって前記特定の情報リソース管理者の管理下にないユーザもアクセス可能な共通情報リソースに対して生成されたユーザ認証情報及びアクセス権限情報を共通ユーザ認証情報及び共通アクセス権限情報として記憶するとともに、前記共通ユーザ認証情報及び前記共通アクセス権限情報の利用禁止状態を解除して利用可能にするための禁止解除認証情報を、前記共通ユーザ認証情報及び前記共通アクセス権限情報に対応付けて記憶し、
   前記認証制御部は、
   前記共通ユーザ認証情報及び前記共通アクセス権限情報の利用禁止状態を保持するとともに、禁止解除認証情報に合致する情報が入力された場合に、前記共通ユーザ認証情報及び前記共通アクセス権限情報の利用禁止状態を解除して前記共通ユーザ認証情報及び前記共通アクセス権限情報を利用可能にすることを特徴とする請求項２〜８のいずれかに記載の情報処理装置。
10. 前記認証制御部は、
    前記情報処理装置を利用する情報リソース管理者に管理権限がある情報リソースであって前記情報リソース管理者の管理下にないユーザもアクセス可能な共通情報リソースに対するユーザ認証情報及びアクセス権限情報を共通ユーザ認証情報及び共通アクセス権限情報として生成するとともに、生成した共通ユーザ認証情報及び共通アクセス権限情報の利用禁止状態を解除して利用可能にするための禁止解除認証情報を生成し、
    前記記憶部は、
    前記認証制御部により生成された共通ユーザ認証情報と、共通アクセス権限情報と、禁止解除認証情報とを対応付けて記憶することを特徴とする請求項２〜９のいずれかに記載の情報処理装置。
11. 情報リソースにアクセス可能なユーザを認証するためのユーザ認証情報と、利用禁止状態にあるユーザ認証情報の利用禁止状態を解除してユーザ認証情報を利用可能にするための禁止解除認証情報とを対応付けて記憶するコンピュータが、
    前記ユーザ認証情報の利用禁止状態を保持するとともに、前記禁止解除認証情報に合致する情報が入力された場合に、前記ユーザ認証情報の利用禁止状態を解除してユーザ認証情報を利用可能にすることを特徴とする情報処理方法。
12. 情報リソースにアクセス可能なユーザを認証するためのユーザ認証情報と、利用禁止状態にあるユーザ認証情報の利用禁止状態を解除してユーザ認証情報を利用可能にするための禁止解除認証情報とを対応付けて記憶するコンピュータに、
    前記ユーザ認証情報の利用禁止状態を保持するとともに、前記禁止解除認証情報に合致する情報が入力された場合に、前記ユーザ認証情報の利用禁止状態を解除してユーザ認証情報を利用可能にする処理を実行させることを特徴とするプログラム。

Images