JP2005310125A - セキュリティ情報を表示および管理するための方法およびシステム - Google Patents

Abstract

【課題】 コンピュータ・システムのドメイン用のセキュリティ情報を管理するための方法およびシステムを提供すること。
【解決手段】 セキュリティ・システムは、ユーザやコンピュータ・システムなどの選択されたセキュリティ・オブジェクト用のセキュリティ情報を表示する。このセキュリティ・システムは、先ず、それぞれが選択されたセキュリティ・オブジェクト用のエンティティ、リソース、およびアクセス権のＩＤを有するセキュリティ仕様を含むセキュリティ情報を取り出す。次に、エンティティとリソースのＩＤを、各セキュリティ仕様用のアクセス権と共に表示する。各リソースとそのリソースに対するアクセス権を有するエンティティ用のセキュリティ情報が、リソースごとに、（メイン）セキュリティ・ストア内に記憶されると、セキュリティ・システムは、補助セキュリティ・ストアを使用してセキュリティ情報の取り出しを容易にすることができる。
【選択図】 図４

Description

本明細書で説明する技術は、一般にコンピュータ・システムのドメイン用のセキュリティ情報を管理することに関する。

現行のネットワーク・システムによって、コンピュータ・システムのドメインの間で信頼関係を確立することができる。コンピュータ・システムのドメインは、同じドメイン内に存在するという共通の属性を共有するコンピュータ・システムの集合体である。たとえば、企業の全コンピュータ・システムは企業のドメインを形成することができ、企業の人事部のコンピュータ・システムは企業の人事ドメインを形成することができる。しばしば、あるドメイン内のコンピュータ・システムのユーザは、別のドメインのユーザが自分たちのリソース（たとえば、データ・ファイルおよびアプリケーション・ファイル）にアクセスするのを許可する場合がある。たとえば、自分のコンピュータ・システムが役員ドメインにある企業の社長は、人事ドメインのコンピュータ・システムに記憶されている人事ファイル（すなわち一種のリソース）へのアクセス（権）を有することができる。人事ファイルへのアクセスを許可するために、人事ドメインの管理者は、役員ドメインのユーザとの間で「信頼関係（trust relationship）」を確立することができる。いったん信頼関係が確立されると、企業の社長は、信頼されたドメインのメンバとなり、希望の人事ファイルにアクセスすることができる。人事ドメインの管理者は役員ドメインとの間で人事ドメイン用の「着信の信頼（incoming trust）」を確立したと言うことができ、これは、役員ドメインのユーザが人事ドメインの管理者によって信頼されていることを意味する。役員ドメインの管理者も、役員ドメインと人事ドメインの間で信頼関係を確立することができる。この信頼関係が確立されれば、人事ドメインのユーザは役員ドメインのリソースにアクセスできることになる。この場合、役員ドメインとの間で人事ドメイン用の「発信の信頼（outgoing trust）」が確立され、これによって人事ドメインのユーザは役員ドメインのリソースにアクセスすることができる。人事ドメイン用の「着信信頼」は役員ドメイン用の「発信の信頼」となり、役員ドメイン用の「着信の信頼」は人事ドメイン用の「発信の信頼」となる。

いったんドメインの間で信頼関係が確立されると、着信の信頼を有するドメインのリソースへのアクセスは、アクセス制御リスト（「ＡＣＬ」）または他の何らかの制御メカニズムによって制御することができる。たとえば、人事ドメイン内のマネージャは、社長が自分の人事ファイルに対しては読取り専用アクセスを有し、会社の他の役員の人事ファイルに対しては読み書き両用アクセスを有するように指定することができる。社長が自分の人事ファイルへのアクセスを要求すると、人事ドメインのセキュリティ・メカニズムはその人事ファイルのＡＣＬをチェックし、要求されたアクセスが社長のアクセス権と整合することを確認する。もしも整合しない場合、社長はアクセスを拒否される。

着信信頼関係を有するドメインの管理者およびユーザにとって、信頼されたドメインの全ユーザ用にその全リソースへの適切なアクセス権を確立することは、非常に時間を要することがある。アクセス権の確立を容易にするために、少なくとも１つのネットワーク・セキュリティ・メカニズムが、着信信頼を有するドメインのコンピュータ・システムと、対応する発信信頼を有するドメインのユーザとの間で「認証により許可される（allowed-to-authenticate）」アクセス権を提供する。たとえば、人事ドメインの管理者は、人事ファイルを含む人事ドメインの人事サーバから会社の役員が認証を受けられるように指定することができる。社長が人事ファイルへのアクセスを要求すると、社長のコンピュータ・システムはまず人事サーバから認証を受けようと試みる。人事管理者が、人事サーバから認証を受ける権利を社長に認めた場合、ネットワーク・セキュリティ・メカニズムは社長を認証し、アクセスを要求しているのが本当に社長であることを確認する。認証が完了すると、社長は人事サーバのリソース（たとえば人事ファイル）にそれらのリソースのＡＣＬに従ってアクセスすることができる。人事サーバのどのリソースも、社長にアクセス権を認めるＡＣＬを有していない場合、社長は認証を受けることが可能であるものの、そのリソースのいずれにもアクセスすることはできない。

ネットワーク・セキュリティ・メカニズムによって使用される認証プロセスは、標準的なＫｅｒｅｂｏｓ認証技術とすることができ、社長のコンピュータ・システムのＫｅｒｅｂｏｓクライアントは、人事ドメインのＫｅｒｅｂｏｓサーバにユーザ名およびパスワードを提供する。Ｋｅｒｅｂｏｓサーバはユーザ名およびパスワードを検証して、要求されたコンピュータ・システムへの「認証により許可される」アクセス権をユーザが有しているかを確認し、もしそうであればユーザに「チケット」を提供する。そのユーザが、認証を受けたコンピュータ・システムのリソースにアクセスを試みるたびに、このチケットが使用される。このチケットが有効であれば、そのリソースのＡＣＬに従ってそのリソースへのアクセスが許可される。有効でなければ、アクセスは拒否される。

いくつかのネットワーク・セキュリティ・メカニズムは、ＬＤＡＰディレクトリや「ＭＩＣＲＯＳＯＦＴ ＡＣＴＩＶＥ ＤＩＲＥＣＴＯＲＹ」などのディレクトリ・サーバを使用して中央リポジトリ内のドメイン用に「認証により許可される」情報などのセキュリティ情報を記憶する。ドメインの各コンピュータ・システムは中央リポジトリ内にエントリを有することができ、このエントリは、このドメインへの発信の信頼を有するドメインのどのユーザがそのコンピュータ・システムから認証を受けることができるか、を指定する。たとえば、人事ドメインの人事サーバ用のエントリは、「役員」と呼ばれる役員ドメインの一群のユーザが人事サーバから認証を受けることができるように、指定することができる。あるいは、このエントリは各役員のユーザ名を一覧にすることもできる。ネットワーク・セキュリティ・メカニズムは、このドメインへの発信信頼を有するドメインのユーザがこのドメインのコンピュータ・システムから認証を受けることを要求するたびに、この中央リポジトリにアクセスする。

こうしたセキュリティ情報の中央リポジトリは、各コンピュータ・システム用の情報を記憶するが、発信の信頼を有するドメインの個々のユーザのすべてのアクセス権を迅速に判定できる形で情報を記憶するわけではない。ユーザのアクセス権を判定するには、ユーザがどのコンピュータ・システムに対してアクセス権（たとえば、「認証により許可される」アクセス権）を有しているかを識別するために、セキュリティ情報のストア全体にアクセスする必要がある。ドメインは数十万のコンピュータ・システムを有する場合があり、それぞれが数十万のユーザを有する多くの異なるドメインとの間で着信の信頼関係を有する場合があるため、中央リポジトリのセキュリティ情報はきわめて膨大になる可能性があり、個々のユーザのすべてのアクセス権を識別するには長い時間を要することがある。たとえば、コンピュータ・プログラムが、「認証により許可される」アクセス権を有する各ユーザ用に示されたリスト、すなわちそのユーザが「認証により許可される」アクセス権を有するコンピュータ・システムのリストをコンパイルするのに３日以上かかった例もある。結果として、個々のユーザのアクセス権を識別および制御することは非現実的であるため、ネットワーク・セキュリティ・メカニズムの特定のセキュリティ機能を使用しない管理者もいる。

管理者が個々のユーザ用のセキュリティ情報を参照および制御できる効果的な方法があれば、望ましいであろう。

セキュリティ情報を整備する（maintaining）ためのセキュリティ・システムが提供される。一実施形態では、このセキュリティ・システムはドメイン用のメイン・セキュリティ・ストアを提供し、このメイン・セキュリティ・ストアはそのドメインのリソース用のエントリを含み、このエントリはエンティティおよびそのリソースへのそのエンティティのアクセス権を識別する。またこのセキュリティ・システムは補助セキュリティ・ストアも提供し、この補助セキュリティ・ストアは、リソースへのエンティティのアクセス権を識別するエントリを有する。このセキュリティ・システムは、ユーザ・インターフェースを提供する際に補助セキュリティ・ストアを使用し、管理者はこのユーザ・インターフェースを介してアクセス権を参照および更新することができる。このセキュリティ・システムは、リソースへのエンティティのアクセス権を検証する際にメイン・セキュリティ・ストアを使用する。ユーザがアクセス権の更新を指定すると、セキュリティ・システムはメイン・セキュリティ・ストアおよび補助セキュリティ・ストアの双方を更新する。このように、このセキュリティ・システムによって、管理者は、セキュリティ情報をエンティティごとに効果的に制御することができ補助セキュリティ・ストアに同期化したメイン・セキュリティ・ストアを維持することを可能になる。

コンピュータ・システムのドメイン用のセキュリティ情報を管理するための方法およびシステムが提供される。一実施形態では、セキュリティ・システムは、ユーザやコンピュータ・システムなどの選択されたセキュリティ・オブジェクト用のセキュリティ情報を表示する。このセキュリティ・システムは、はじめにセキュリティ情報を取り出す。このセキュリティ情報は、それぞれが選択されたセキュリティ・オブジェクト用のエンティティ、リソース、およびアクセス権のＩＤを有するセキュリティ仕様を含む。エンティティは、ユーザまたはユーザのグループを含むことができ、リソースは、コンピュータ・システムを含むことができ、アクセス権は、エンティティがリソースから認証を受けることができるかどうかを指定することができる。次いでセキュリティ・システムは、エンティティのＩＤおよびリソースを、各セキュリティ仕様用のアクセス権と共に表示する。各リソースとそのリソースに対するアクセス権を有するエンティティ用のセキュリティ情報が、リソースごとに、セキュリティ・ストア（すなわちメイン・セキュリティ・ストア）内に記憶されると、セキュリティ・システムは、補助セキュリティ・ストアを使用してセキュリティ情報の検索を容易にすることができる。一実施形態では、補助セキュリティ・ストアは、メイン・セキュリティ・ストア内で指定された各セキュリティ仕様のためのエントリを含む。

セキュリティ仕様は、エンティティ、リソース、およびアクセス権の３つから成る組（triplet）を定義し、これは、そのエンティティがそのリソースへの指定されたアクセス権を有するという関係を意味する。エンティティは、アクセス権の「発信元（source）」と言うこともでき、リソースはアクセス権の「宛先（destination）」と言うこともできる。この発信元および宛先という用語は、どんな発信元がどんな宛先に対してどんなアクセス権を有するかを指定するファイアウォール・メカニズムによって使用される用語に似ている。セキュリティ・システムは、セキュリティ情報へのアクセスを管理者に提供する際に補助セキュリティ・ストアを使用することができる。具体的には、管理者がセキュリティ情報を参照したい場合、セキュリティ・システムは、メイン・セキュリティ・ストアではなく、補助セキュリティ・ストアからセキュリティ仕様を取り出す。さらに、管理者がセキュリティ情報を修正したい場合、セキュリティ・システムは、どのセキュリティ情報が修正されるべきかを特定する際に、管理者支援するために、補助セキュリティ・ストアのセキュリティ仕様を用いる。またセキュリティ・システムは、メイン・セキュリティ・ストアおよび補助セキュリティ・ストアの双方を更新して、修正を反映する。このように、管理者はセキュリティ・システムを使用して（セキュリティ・システムは補助セキュリティ・ストアを使用して）、自らのドメイン用のセキュリティ情報を効果的に管理することができ、ネットワーク・セキュリティ・メカニズムは、リソースへのアクセスを要求しているエンティティが、要求されたアクセスを満足するアクセス権を有しているかどうかをチェックする際に、依然としてメイン・セキュリティ・ストアを使用することができる。

一実施形態では、セキュリティ・システムは、メイン・セキュリティ・ストアからのセキュリティ情報からセキュリティ仕様をコンパイルすることによって、当初においては、補助セキュリティ・ストアを取り込むことができる。メイン・セキュリティ・ストアのセキュリティ情報の取り出しおよび処理するには長い時間を要する場合があるが、その取り出しおよび処理は１回行うだけでよい。はじめに補助セキュリティ・ストアが取り込まれた後は、セキュリティ情報が更新されるたびに、セキュリティ・システムはメイン・セキュリティ・ストアおよび補助セキュリティ・ストアの双方を更新する。メイン・セキュリティ・ストアと補助セキュリティ・ストアが整合していることが重要であるため、セキュリティ・システムはメイン・セキュリティ・ストアおよび補助セキュリティ・ストアの双方を更新した後、更新されたセキュリティ情報を両セキュリティ・ストアから取り出して、更新が正しく完了したことを確認することができる。もしも更新が正しく完了していない場合、セキュリティ・システムは管理者に通知することができるので、修正の措置を講じることができる。セキュリティ・システムはセキュリティ情報に対する更新をすべて記録することもできるので、両セキュリティ・ストア用の更新を必要に応じてロール・フォワードまたはロール・バックワードすることができる。一実施形態では、セキュリティ・システムは、セキュリティ・システムによって管理されているアクセス権（たとえば、「認証により許可される」アクセス権）を有効にしたり無効にしたりする特権を有するユーザ（たとえば管理者）だけが、セキュリティ情報の更新をすることが認められる、ことを保証することができる。

一実施形態では、セキュリティ・システムは、親セキュリティ・オブジェクトからアクセス権が継承されることを認める。たとえば、ユーザがコンピュータ・システムのあるドメインから認証を受ける権利を許可されると、そのドメインの各サブ・コンテナはその許可を継承する。さらに、各サブ・コンテナの各コンピュータ・システムもその許可を継承する。しかしセキュリティ・システムは、受け継がれたアクセス権を管理者が指定変更する（override）ことを認める。たとえば管理者は、ユーザがサブ・コンテナのあるコンピュータ・システムに対する、受け継がれた許可を指定変更するアクセス権を持たないように指定することができる。一実施形態では、セキュリティ・システムはアクセス権のネストされた指定変更を認めない。たとえば管理者が、サブ・コンテナ用に受け継がれた許可を指定変更する場合、セキュリティ・システムは、サブ・コンテナのコンピュータ・システムによって受け継がれた指定変更を管理者がさらに指定変更するのを認めない。したがって、管理者はサブ・コンテナが受け継がれたアクセス権を認められないと指定することはできず、サブ・コンテナのコンピュータ・システムは受け継がれたアクセス権を認められる。もしも管理者が、コンピュータ・システムがアクセス権を認められるようにする必要がある場合、そのコンピュータ・システムが、受け継いだ権利を指定変更されたサブ・コンテナ内から外れるように、セキュリティ・オブジェクトの階層構造を編成し直すことができる。あるいは、コンピュータ・システムを別のドメイン内に置き、そこを通じてアクセス権を受け継ぐこともできる。

図１〜３は、一実施形態における「認証により許可される」セキュリティ情報の管理を示す表示ページである。図１は、一実施形態における表示ページであり、セキュリティ仕様が表示されることになる選択されるオブジェクトのエントリを示している。表示ページ１００は、エンティティまたはリソースのＩＤを入力するためのデータ入力フィールド１０１および１０２を含む。このデータ入力フィールドは、セキュリティ・オブジェクトの選択を容易にするためのドロップ・ダウン・リストやブラウジング機能を提供することができる。送信ボタン１０３は、エンティティまたはリソースに対するその「認証により許可される」セキュリティ仕様を識別される確認する場合、管理者によって選択される。たとえば、企業の社長用のセキュリティ情報を参照するには、管理者は社長の氏名Ｊｏｈｎ Ｄｏｅを入力フィールドに入力し、送信ボタンを選択する。あるいは、管理者はリソースの名前をリソース・フィールドに入力し、送信ボタンを選択して、そのリソース用のセキュリティ情報を参照する。送信ボタンが選択されると、識別されたセキュリティ・オブジェクト用のセキュリティ仕様が、図２Ａに示すように表示される。

図２Ａは、一実施形態における表示ページであり、エンティティ用の「認証により許可される」セキュリティ仕様の表示を示している。表示ページ２００は、セキュリティ・オブジェクトＩＤフィールド２０１およびセキュリティ情報エリア２０２を含む。セキュリティ・オブジェクトＩＤフィールドは、図１の表示ページを介してセキュリティ・オブジェクトを識別する。この場合、「Ｊｏｈｎ Ｄｏｅ」という名前のユーザがエンティティであり、そのセキュリティ仕様が表示される。セキュリティ情報エリアは、「Ｊｏｈｎ Ｄｏｅ」が認証を受ける権利を有するリソースのリストを含む。この例では、「Ｊｏｈｎ Ｄｏｅ」は「コンピュータ１」、「コンピュータ５」、「コンピュータ８」、および「コンピュータ１２」から認証を受ける権利を有する。セキュリティ仕様は、セキュリティ・オブジェクトの基礎をなす階層を反映する方法で選択できることを、当業者なら理解するであろう。たとえばエンティティは、さまざまなサブグループによって定義されるユーザのグループとすることができる。セキュリティ・システムは、管理者がグループ用のセキュリティ仕様を参照し、サブグループへ、そして最終的には個々のユーザへドリル・ダウンすることを許可することができる。同様に、リソースはサブ・ドメイン内のドメインとして指定することができ、管理者はドメインまたはサブ・ドメイン内のリソース用のすべてのセキュリティ仕様を参照することを選択することができる。

図２Ｂは、一実施形態における表示ページであり、リソースの「認証により許可される」セキュリティ仕様の表示を示している。表示ページ２５０は、ドメインＩＤエリア２５１およびセキュリティ仕様エリア２５２を含む。管理者がドメインを選択すると、セキュリティ・システムはそのドメイン用のセキュリティ仕様をセキュリティ仕様エリアに表示する。セキュリティ仕様エリアは、リソースの縦列２５３、エンティティの縦列２５４、およびアクセス権の縦列２５５を含む。セキュリティ仕様エリアの各横行は、リソースおよびエンティティならびに対応するアクセス権を同一の横行に表示する。

図３は、一実施形態における「認証により許可される」セキュリティ仕様の作成を示す表示ページである。表示ページ３００は、エンティティＩＤフィールド３０１、リソースＩＤフィールド３０２、アクション指定ラジオ・ボタン３０３、および追加ボタン３０４を含む。エンティティＩＤは、セキュリティ仕様の作成対象となるエンティティを識別する。エンティティＩＤフィールドは、エンティティのドロップ・ダウン・リストを含むことができる。この例では、セキュリティ・オブジェクトはＪｏｈｎ Ｄｏｅというエンティティである。リソースＩＤフィールドは、エンティティがセキュリティ仕様を追加する対象となるリソースを指定するために使用する。リソースＩＤフィールドは、着信の信頼を有するドメインのコンピュータ・システムのドロップ・ダウン・リストを含むことができる。アクション・ラジオ・ボタンは、そのエンティティがそのリソースから認証を受けることができるかどうかを指定する。管理者は、エンティティ、リソース、およびアクションを指定した後に追加ボタンを選択して、セキュリティ仕様を補助セキュリティ・ストアに追加し、それに応じてメイン・セキュリティ・ストアを更新する。

図４は、一実施形態におけるセキュリティ・システムを実装するドメインのコンポーネントを示すブロック図である。このドメインは、通信リンク４０２を介して相互に接続されたコンピュータ・システム４０１、セキュリティ・システム４１０、およびディレクトリ・サーバ４２０を含む。ディレクトリ・サーバは、メイン・セキュリティ・ストア４２１および補助セキュリティ・ストア４２２へのアクセスを提供する。補助セキュリティ・ストアは、メイン・セキュリティ・ストアが配置されているサーバとは別のサーバ上に配置できることを、当業者なら理解するであろう。セキュリティ・システムは、ＵＩコントローラ４１１、補助セキュリティ・ストア初期設定コンポーネント４１２、エンティティ・エントリ検索コンポーネント４１３、リソース・エントリ検索コンポーネント４１４、およびエントリ更新コンポーネント４１５を含み、これらのそれぞれが、セキュリティ・システムがインストールされているコンピュータ・システムを実行することができる。ＵＩコントローラは、たとえば図１〜３によって示されているように、セキュリティ・システム用のユーザ・インターフェースを提供する。ＵＩコントローラは、エンティティ・エントリ検索コンポーネントおよびリソース・エントリ検索コンポーネントを呼び出して、補助セキュリティ・ストアからセキュリティ情報を取り出す。ＵＩコントローラはエントリ更新コンポーネントを呼び出して、メイン・セキュリティ・ストアおよび補助セキュリティ・ストアの双方のセキュリティ情報を更新する。補助セキュリティ・ストア初期設定コンポーネントは、メイン・セキュリティ・ストアのセキュリティ情報に基づいて、はじめに補助セキュリティ・ストアを取り込む。

セキュリティ・システムが実装されているコンピューティング・デバイスは、中央演算処理装置、メモリ、入力装置（たとえば、キーボ−ドおよびポインティング・デバイス）、出力装置（たとえばディスプレイ装置）、ならびにストレージ・デバイス（たとえばディスクドライブ）を含むことができる。メモリおよびストレージ・デバイスは、セキュリティ・システムを実施する命令を含むことができるコンピュータ可読メディアである。さらにデータ構造およびメッセージ構造は、通信リンク上の信号などのデータ伝送メディアを介して記憶したり伝送したりすることができる。インターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、あるいはＰｏｉｎｔ−ｔｏ−Ｐｏｉｎｔダイヤル・アップ接続など、さまざまな通信リンクを使用することができる。

図４は、セキュリティ・システムを実装することができる好ましい動作環境の一例を示している。この動作環境は好ましい動作環境の一例にすぎず、セキュリティ・システムの使用や機能の範囲に関して何らかの限定を意図するものではない。使用に適する可能性のある他のよく知られたコンピューティングシステム、コンピューティング環境、およびコンピューティング構成としては、パーソナル・コンピュータ、サーバ・コンピュータ、ハンドヘルド・デバイスやラップトップ・デバイス、マルチ・プロセッサ・システム、マイクロ・プロセッサ・ベースのシステム、プログラム可能な家庭用電化製品、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータ、これらのシステムやデバイスを任意に含む分散コンピューティング環境などがある。

このセキュリティ・システムについては、１つまたは複数のコンピュータまたは他のデバイスによって実行される、プログラム・モジュールなどのコンピュータ実行可能命令という一般的な文脈において説明することができる。一般にプログラム・モジュールは、特定のタスクを実行したり特定の抽象データ型を実装したりするルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。通常、プログラム・モジュールの機能は、さまざまな実施形態において希望に応じて組み合わせたり分散させたりすることができる。

図５は、一実施形態における補助セキュリティ・ストア初期設定コンポーネントの処理を示す流れ図である。このコンポーネントは、「認証により許可される」情報をメイン・セキュリティ・ストアから取り出し、取り出したセキュリティ情報から導出されたセキュリティ仕様を補助セキュリティ・ストアに取り込む。ブロック５０１〜５０５において、コンポーネントは、メイン・セキュリティ・ストアの各リソースと、その各リソース用に指定された「認証により許可される」情報を有する各エンティティとを選択しながらループする。ブロック５０１では、コンポーネントはメイン・セキュリティ・ストアの次のリソースを選択する。判定ブロック５０２では、メイン・セキュリティ・ストアのすべてのリソースが既に選択されている場合、コンポーネントは終了し、そうでない場合、コンポーネントはブロック５０３で継続する。ブロック５０３では、コンポーネントは、選択されたリソース用の次のエンティティをメイン・セキュリティ・ストアから選択する。判定ブロック５０４では、すべてのエンティティが既に選択されている場合、コンポーネントはブロック５０１にループして次のリソースを選択し、そうでない場合、コンポーネントはブロック５０５で継続する。ブロック５０５では、コンポーネントは、選択されたリソースおよび選択されたエンティティならびに「認証により許可される」アクション（すなわち、拒否または許可）を指定するセキュリティ仕様を補助セキュリティ・ストアに追加する。次いでコンポーネントはブロック５０３にループして、選択されたリソース用の次のエンティティを選択する。

図６は、一実施形態におけるＵＩコントローラの処理を示す流れ図である。ブロック６０１では、ＵＩコントローラは、図１の表示ページなどの表示ページを表示する。判定ブロック６０２では、管理者がエンティティのＩＤを入力してある場合、コンポーネントはブロック６０３で継続し、そうでない場合、コンポーネントはブロック６０４で継続する。ブロック６０３では、ＵＩコントローラは、エンティティ情報表示コンポーネントを呼び出して、識別されたエンティティ用のセキュリティ仕様の表示を制御する。次いでコンポーネントは、表示ページを再表示するために、ブロック６０１にループする。判定ブロック６０４では、管理者がリソースのＩＤを入力してある場合、ＵＩコントローラはブロック６０５で継続し、そうでない場合、ＵＩコントローラは、表示ページを再表示するためにループする。ブロック６０５では、ＵＩコントローラはリソース情報表示コンポーネントを呼び出して、識別されたリソース用のセキュリティ仕様を表示し、次いで、表示ページを再表示するためにブロック６０１にループする。

図７は、一実施形態におけるエンティティ情報表示コンポーネントの処理を示す流れ図である。このコンポーネントは、エンティティのＩＤを渡され、識別されたエンティティ用のセキュリティ仕様の表示を制御する。ブロック７０１では、コンポーネントは、エンティティが所属するグループを識別する。コンポーネントは、そのエンティティのドメインに連絡を取り、そのエンティティの所属するグループを識別するようそのドメインに要求することによって、グループを識別することができる。ドメインはツリーの「メンバ」を横断して、エンティティが過渡的に所属するすべてのグループを識別することができる。ブロック７０２〜７０４において、コンポーネントは、そのグループ用の補助セキュリティ・ストアからエントリを取り出しながらループする。エンティティは、それ自体グループとみなすことができる。ブロック７０２において、コンポーネントは次のグループを選択する。判定ブロック７０３では、既にすべてのグループが選択されている場合、コンポーネントはブロック７０５で継続し、そうでない場合、コンポーネントはブロック７０４で継続する。ブロック７０４では、コンポーネントは、選択されたグループ用のセキュリティ仕様を補助セキュリティ・ストアから取り出し、次いでブロック７０２にループして次のグループを選択する。ブロック７０５では、コンポーネントは、たとえば図２Ａに示すように、取り出されたセキュリティ仕様を表示する。

図８は、一実施形態におけるセキュリティ仕様表示コンポーネントの処理を示す流れ図である。このコンポーネントはドメインのＩＤを渡され、識別されたドメインに関連するセキュリティ仕様を表示する。ブロック８０１では、コンポーネントは、識別されたドメイン用の補助セキュリティ・ストアからセキュリティ仕様を取り出す。ブロック８０２では、コンポーネントは、たとえば図２Ｂに示すように、取り出されたセキュリティ仕様を表示する。そしてコンポーネントは終了する。

図９は、一実施形態におけるセキュリティ仕様更新コンポーネントの処理を示す流れ図である。このコンポーネントは、エンティティ、リソース、およびアクセス権を識別するセキュリティ仕様を渡される。このコンポーネントは、（たとえば図３の表示ページを使用して）管理者がセキュリティ仕様を指定した後に、呼び出される。判定ブロック９０１では、エンティティとリソースのペア用のセキュリティ仕様が既に補助セキュリティ・ストア内にある場合、コンポーネントはブロック９０２で継続し、そうでない場合、コンポーネントはブロック９０４で継続する。図中には示されていないが、セキュリティ仕様を削除するかどうかを示すフラグも渡すことができる。ブロック９０２では、コンポーネントは補助セキュリティ・ストアのセキュリティ仕様を更新して、渡されたセキュリティ仕様の新しいアクセス権を反映する。ブロック９０３では、コンポーネントはメイン・セキュリティ・ストアのセキュリティ情報を更新して、戻る。ブロック９０４では、コンポーネントは、渡されたセキュリティ仕様を補助セキュリティ・ストアに追加する。ブロック９０５では、コンポーネントは、渡されたセキュリティ仕様によって示されるように、メイン・セキュリティ・ストア内のセキュリティ情報を更新して、戻る。

本明細書では、例示の目的でセキュリティ・システムの特定の実施形態について説明したが、本発明の趣旨および範囲から逸脱することなくさまざまな修正を施すことができることを、当業者なら理解するであろう。ドメインはユーザまたはコンピュータ・システムあるいはその両方の点から定義できることを、当業者なら理解するであろう。セキュリティ・システムは、メイン・セキュリティ・ストア内に記憶できるファイアウォールやＩＰセキュリティフィルタルールを管理するように適合できることを、当業者なら理解するであろう。したがって本発明は、添付の特許請求の範囲以外のものによって限定されるものではない。

一実施形態におけるセキュリティ仕様が表示される選択されたオブジェクトのエントリを示す表示ページの図である。 一実施形態におけるエンティティ用の「認証により許可される」セキュリティ仕様の表示を示す表示ページの図である。 一実施形態におけるリソースの「認証により許可される」セキュリティ仕様の表示を示す表示ページの図である。 一実施形態における「認証により許可される」セキュリティ仕様の作成を示す表示ページの図である。 一実施形態におけるセキュリティ・システムを実装するドメインのコンポーネントを示すブロック図である。 一実施形態における補助セキュリティ・ストア初期設定コンポーネントの処理を示す流れ図である。 一実施形態におけるＵＩコントローラの処理を示す流れ図である。 一実施形態におけるエンティティ情報表示コンポーネントの処理を示す流れ図である。 一実施形態におけるセキュリティ仕様表示コンポーネントの処理を示す流れ図である。 一実施形態におけるセキュリティ仕様更新コンポーネントの処理を示す流れ図である。

符号の説明

１００ 表示ページ
１０１ エンティティのＩＤを入力するためのデータ入力フィールド
１０２ リソースのＩＤを入力するためのデータ入力フィールド
２００ 表示ページ
２０１ セキュリティ・オブジェクトＩＤフィールド
２０２ セキュリティ情報エリア
２５０ 表示ページ
２５１ ドメインＩＤエリア
２５２ セキュリティ仕様エリア
２５３ リソースの縦列
２５４ エンティティの縦列
２５５ アクセス権の縦列
３００ 表示ページ
３０１ エンティティＩＤフィールド
３０２ リソースＩＤフィールド
３０３ アクション指定ラジオ・ボタン
３０４ 追加ボタン
４０１ コンピュータ・システム
４０２ 通信リンク
４１０ セキュリティ・システム
４１１ ＵＩコントローラ
４１２ 補助セキュリティ・ストアの初期設定
４１３ エンティティ・エントリの検索
４１４ リソース・エントリの検索
４１５ エントリの更新
４２０ ディレクトリ・サーバ
４２１ メイン・セキュリティ・ストア
４２２ 補助セキュリティ・ストア

Claims (39)

1. 「認証により許可される」情報を表示するためのコンピュータ・システムにおける方法において、
   セキュリティ・オブジェクトの選択を受け取ること、
   前記選択されたセキュリティ・オブジェクト用の「認証により許可される」情報を取り出すことであって、（ａ）エンティティ、（ｂ）リソース、および（ｃ）前記エンティティが前記リソースから認証を受けようと試みる際に、前記リソースから認証を受けようとする前記試みを許可するかまたは拒否するかを示すアクション、を識別する前記情報を取り出すこと、ならびに
   前記選択されたセキュリティ・オブジェクトを指示する情報を、前記取り出された「認証により許可される」情報と共に表示すること
   を備えることを特徴とする方法。
2. エンティティおよびリソースに関連した前記アクションを修正することを含むことを特徴とする請求項１に記載の方法。
3. エンティティがリソースから認証を受けることができるかどうかを指定する、新たな「認証により許可される」情報を作成することを含むことを特徴とする請求項１に記載の方法。
4. 前記選択されたセキュリティ・オブジェクトは、エンティティであることを特徴とする請求項１に記載の方法。
5. 前記選択されたセキュリティ・オブジェクトは、リソースであることを特徴とする請求項１に記載の方法。
6. 前記選択されたセキュリティ・オブジェクトがユーザである場合に、前記ユーザがメンバとなっているすべてのグループを識別すること、および前記識別されたグループ用の「認証により許可される」情報を取り出すことを含むことを特徴とする請求項１に記載の方法。
7. エンティティがリソースから認証を受けようと試みる際に、前記「認証により許可される」情報は、セキュリティ・メカニズムによって使用されるメイン・セキュリティ・ストアとは別の補助セキュリティ・ストアから取り出されることを特徴とする請求項１に記載の方法。
8. 前記エンティティは、発信元として表され、前記リソースは、宛先として表されることを特徴とする請求項１に記載の方法。
9. 前記リソースは、あるドメイン内に存在し、前記エンティティは、別のドメイン内に存在し、前記あるドメインは、前記別のドメインとの間に着信の信頼関係を有することを特徴とする請求項１に記載の方法。
10. セキュリティ情報を整備するためのコンピュータ・システムにおける方法において、
    ドメイン用のメイン・セキュリティ・ストアであって、前記ドメインのリソース用のエントリを含み、リソース用の各エントリはエンティティおよび前記リソースへの各エンティティのアクセス権を識別する、メイン・セキュリティ・ストアを提供すること、
    前記ドメイン用の補助セキュリティ・ストアであって、エンティティ用のエントリを含み、エンティティ用の各エントリはリソースおよび前記リソースへの前記エンティティのアクセス権を識別する、補助セキュリティ・ストアを提供すること、
    ユーザからセキュリティ・オブジェクトの選択を受け取ること、
    前記補助セキュリティ・ストアから前記選択されたセキュリティ・オブジェクトに関連したエントリを取り出すこと、ならびに
    前記取り出されたエントリのエンティティ、リソース、およびアクセス権を表示すること
    を備え、前記提供されたメイン・セキュリティ・ストアは、リソースへのエンティティのアクセス権を検証する際に使用されることを特徴とする方法。
11. リソースへのエンティティのアクセス権を変更することを指示する情報を受け取ること、ならびに前記メイン・セキュリティ・ストアおよび前記補助セキュリティ・ストアの双方のエントリを更新することを含むことを特徴とする請求項１０に記載の方法。
12. はじめに前記メイン・セキュリティ・ストアの前記エントリから前記補助セキュリティ・ストアを作成することを含むことを特徴とする請求項１０に記載の方法。
13. 前記アクセス権は、エンティティは、リソースから認証を受けることができるかどうかということであることを特徴とする請求項１０に記載の方法。
14. 前記メイン・セキュリティ・ストアは、前記ドメインのディレクトリ・サービスを使用して実装されることを特徴とする請求項１０に記載の方法。
15. 前記ディレクトリ・サービスは、「ＡＣＴＩＶＥ ＤＩＲＥＣＴＯＲＹ」であることを特徴とする請求項１４に記載の方法。
16. 前記補助セキュリティ・ストアは、前記ドメインの前記ディレクトリ・サービスを使用して実装されることを特徴とする請求項１４に記載の方法。
17. 前記選択されたセキュリティ・オブジェクトがエンティティである場合に、前記エンティティがメンバとなっているグループを識別すること、および前記識別されたグループに関連したエントリを前記補助セキュリティ・ストアから取り出すことを含むことを特徴とする請求項１０に記載の方法。
18. 前記エンティティは、発信元として表され、前記リソースは、宛先として表されることを特徴とする請求項１０に記載の方法。
19. 前記リソースは、あるドメイン内に存在し、前記エンティティは、別のドメイン内に存在し、前記あるドメインは、前記別のドメインとの間に着信の信頼関係を有することを特徴とする請求項１０に記載の方法。
20. セキュリティ情報を表示するためのコンピュータ・システムにおいて、
    セキュリティ・オブジェクトの選択を受け取るコンポーネントと、
    前記選択されたセキュリティ・オブジェクト用のセキュリティ情報であって、（ａ）発信元、（ｂ）宛先、および（ｃ）前記発信元が前記宛先にアクセスしようと試みる際に、前記宛先へのアクセスを制御するために使用されるアクセス権、を識別するセキュリティ情報を取り出すコンポーネントと、
    前記取り出されたセキュリティ情報の前記発信元、宛先、およびアクセス権を指示する情報を表示するコンポーネントと
    を備えることを特徴とするコンピュータ・システム。
21. 前記セキュリティ情報は、「認証により許可される」情報であることを特徴とする請求項２０に記載のコンピュータ・システム。
22. 発信元および宛先に関連した前記アクセス権を修正するコンポーネントを含むことを特徴とする請求項２０に記載のコンピュータ・システム。
23. 宛先への発信元のアクセス権を指定する新たなセキュリティ情報を作成するコンポーネントを含むことを特徴とする請求項２０に記載のコンピュータ・システム。
24. 前記選択されたセキュリティ・オブジェクトは、発信元であることを特徴とする請求項２０に記載のコンピュータ・システム。
25. 前記選択されたセキュリティ・オブジェクトは、宛先であることを特徴とする請求項２０に記載のコンピュータ・システム。
26. 前記選択されたセキュリティ・オブジェクトがユーザである場合に、前記ユーザがメンバとなっているすべてのグループを識別すること、および前記識別されたグループ用のセキュリティ情報を取り出すことを含むことを特徴とする請求項２０に記載のコンピュータ・システム。
27. 前記セキュリティ情報は、発信元が宛先へのアクセスを試みる際に使用されるメイン・セキュリティ・ストアとは別の補助セキュリティ・ストアから取り出されることを特徴とする請求項２０に記載のコンピュータ・システム。
28. 前記発信元は、エンティティであり、前記宛先は、リソースであることを特徴とする請求項２０に記載のコンピュータ・システム。
29. 前記宛先は、あるドメイン内に存在し、前記発信元は、別のドメイン内に存在し、前記あるドメインは、前記別のドメインとの間に着信の信頼関係を有することを特徴とする請求項２０に記載のコンピュータ・システム。
30. セキュリティ情報を整備するためのコンピュータ・システムにおいて、
    ドメイン用のメイン・セキュリティ・ストアであって、前記ドメインのリソース用のエントリを含み、リソース用の各エントリはエンティティおよび前記リソースへの各エンティティのアクセス権を識別する、メイン・セキュリティ・ストアと、
    前記ドメイン用の補助セキュリティ・ストアであって、それぞれがリソースへのエンティティのアクセス権を識別するセキュリティ仕様を含む、補助セキュリティ・ストアと、
    前記補助セキュリティ・ストアから取り出されたエンティティ、リソース、およびアクセス権を表示するコンポーネントと、
    エンティティがリソースへのアクセスを試みる際に前記メイン・セキュリティ・ストアを使用してアクセス権を検証するコンポーネントと
    を備えることを特徴とするコンピュータ・システム。
31. リソースへのエンティティのアクセス権を変更する指示する情報を受け取るコンポーネントと、前記メイン・セキュリティ・ストアおよび前記補助セキュリティ・ストアの双方を更新するコンポーネントとを含むことを特徴とする請求項３０に記載のコンピュータ・システム。
32. 前記メイン・セキュリティ・ストアから前記補助セキュリティ・ストアを作成するコンポーネントを含むことを特徴とする請求項３０に記載のコンピュータ・システム
33. アクセス権は、エンティティがリソースから認証を受けることができるかどうかということであることを特徴とする請求項３０に記載のコンピュータ・システム。
34. 前記メイン・セキュリティ・ストアは、前記ドメインのディレクトリ・サービスを使用して実装されることを特徴とする請求項３０に記載のコンピュータ・システム。
35. 前記ディレクトリ・サービスは、「ＡＣＴＩＶＥ ＤＩＲＥＣＴＯＲＹ」であることを特徴とする請求項３４に記載のコンピュータ・システム。
36. 前記補助セキュリティ・ストアは、前記ドメインの前記ディレクトリ・サービスを使用して実装されることを特徴とする請求項３４に記載のコンピュータ・システム。
37. 前記エンティティがメンバとなっているグループを識別し、前記識別されたグループに関連したエントリを前記補助セキュリティ・ストアから取り出すコンポーネントを含むことを特徴とする請求項３０に記載のコンピュータ・システム。
38. 前記エンティティは、発信元として表され、前記リソースは、宛先として表されることを特徴とする請求項３０に記載のコンピュータ・システム。
39. 前記リソースは、あるドメイン内に存在し、前記エンティティは、別のドメイン内に存在し、前記あるドメインは、前記別のドメインとの間に着信信頼関係を有することを特徴とする請求項３０に記載のコンピュータ・システム。
    

Images