JP2005301602A - 情報処理装置、操作許否判定方法、操作許可情報生成方法、操作許否判定プログラム、操作許可情報生成プログラム及び記録媒体 - Google Patents

Abstract

【課題】 柔軟なアクセス制御を実現することのできる情報処理装置、操作許否判定方法、操作許可情報生成方法、操作許否判定プログラム、操作許可情報生成プログラム及び記録媒体の提供を目的とする。
【解決手段】 操作の対象となる資源の分類と前記資源を操作する主体の分類との組み合わせに応じて前記操作の種別ごとに前記操作の許否判定に関する規則が定義された定義情報と、特定の資源について特定の主体に対して許可された前記操作の種別が定義された操作許可情報とに基づいて、前記主体の前記文書に対する前記操作についての許否判定を実行する許否判定手段を有することを特徴とすることにより上記課題を解決する。
【選択図】 図３

Description

本発明は、情報処理装置、操作許否判定方法、操作許可情報生成方法、操作許否判定プログラム、操作許可情報生成プログラム及び記録媒体に関し、特に資源に対するアクセス制御を行うための情報処理装置、操作許否判定方法、操作許可情報生成方法、操作許否判定プログラム、操作許可情報生成プログラム及び記録媒体に関する。

文書管理システムにおける文書に対するアクセス制御を行なうための手段として、文書ごと、又は複数の文書の集合により構成されるグループごとにＡＣＬ（Access Control List）と呼ばれる操作可否リストによって、どのユーザにどのような操作を許可するかといったセキュリティルールを管理することが行われている。しかし、かかるＡＣＬは、各システムの内部において（例えば、文書管理データベースにおける管理情報として）管理されるものであるため、複数のシステムにまたがって統一された方針に基づくルールを適用するのが困難であった。

他方において、一つのシステム内だけでなく、より広範囲に渡って文書等の資源に対するアクセス制御の一貫性を保つため、複数のシステムにおけるアクセス制御に関する情報（以下、「アクセス制御情報」という。）を一つのセキュリティサーバに集約し、資源を利用する各アプリケーションはセキュリティサーバにおける統一的なアクセス制御方針（セキュリティポリシー）に基づいて各種操作の可否を判定するといった方式も検討されている。但し、制御の対象となる操作はアプリケーションによって異なるため、複数のシステムにおけるアクセス制御情報をただ単に集約するだけでは管理情報が煩雑になってしまう。したがって、セキュリティサーバにおいては、より抽象度の高いセキュリティポリシーを定義しておき、個々の具体的な判定の際には、抽象的な操作ごとに定義されたポリシー記述のうち、アプリケーションごとに最も適切なポリシー記述を適用してアクセス制御が行われている（例えば、「印刷出力」処理も「ローカルＰＣへのダウンロード」処理も「文書出力ルール」ポリシーに基づいて実行の可否を判断する等）。
特開２００３−１７０７１５号公報

しかしながら、セキュリティポリシーは、複数のシステムに対する統一的、かつ抽象的なルールという性格上、従来のＡＣＬ以上にその定義内容は固定的なものとなる傾向がある。したがって、セキュリティポリシーよると、日常業務において多々発生する例外的な事態（例えば、一時的に特定の派遣社員に特定の文書の利用を許可したい場合等）に対する柔軟性が損なわれるという問題がある。

なお、特許文献１においては、セキュリティポリシーに付加的なルールを追加することにより当該セキュリティポリシーを拡張する発明が記載されているが、複数のシステムに対する統一的なルールを直接変更することなく、その定義内容を拡張することができればより安全性が高まり便宜である。

本発明は、上記の点に鑑みてなされたものであって、柔軟なアクセス制御を実現することのできる情報処理装置、操作許否判定方法、操作許可情報生成方法、操作許否判定プログラム、操作許可情報生成プログラム及び記録媒体の提供を目的とする。
の提供を目的とする。

そこで上記課題を解決するため、本発明は、請求項１に記載されるように、操作の対象となる資源の分類と前記資源を操作する主体の分類との組み合わせに応じて前記操作の種別ごとに前記操作の許否判定に関する規則が定義された定義情報と、特定の資源について特定の主体に対して許可された前記操作の種別が定義された操作許可情報とに基づいて、前記主体の前記文書に対する前記操作についての許否判定を実行する許否判定手段を有することを特徴とする。

このような情報処理装置では、包括的に定義された前期定義情報と特定の対象に対して定義された前記操作許可情報とに基づいて操作の許否判定を行うため、前記定義情報のみに基づいて許否判定を行う場合に比べて、より柔軟なアクセス制御を行うことができる。

また、上記課題を解決するため、本発明は、請求項８に記載されるように、特定の資源について特定の主体に対して許可された操作の種別が定義された操作許可情報を生成する操作許可情報生成手段を有する情報処理装置であって、操作の対象となる資源の分類と前記資源を操作する主体の分類との組み合わせに応じて前記操作の種別ごとに前記操作の許否判定に関する規則が定義された定義情報において当該操作許可情報が対象とする前記特定の主体、前記特定の資源及び前記操作の種別を対象とし得る前記規則について、前記操作許可情報の適用が禁止されている場合は、当該操作許可情報を生成しないことを特徴とする。

このような情報処理装置では、前記操作許可情報を生成する段階で前記定義情報との関係を調整することができるためその一部又は全部について無効な操作許可情報が生成されるのを防止することができる。

また、上記課題を解決するため、本発明は、上記情報処理装置における操作許否判定方法、操作許可情報生成方法、前記操作許否判定方法を前記情報処理装置に実行させるための操作許否判定プログラム、前記操作許可情報生成方法を前記情報処理装置に実行させるための操作許可情報生成プログラム、又は前記操作許否判定プログラム若しくは前記操作許可情報生成プログラムを記録した記録媒体としてもよい。

本発明によれば、柔軟なアクセス制御を実現することのできる情報処理装置、操作許否判定方法、操作許可情報生成方法、操作許否判定プログラム、操作許可情報生成プログラム及び記録媒体を提供することができる。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における文書管理システムの構成例を示す図である。図１に示されるように、本実施の形態における文書管理システム１は、セキュリティ管理サーバ１０、文書管理サーバ２０、認証サーバ３０、クライアント装置４０、印刷サーバ５１、変換サーバ５２及び配信サーバ５３等が、インターネットやＬＡＮ（Local Area Network）等のネットワーク６０を介して接続されることにより構成されている。

セキュリティ管理サーバ１０は、文書に対するセキュリティ上の各種情報（以下、「セキュリティ情報」という。）の管理機能と共に、当該セキュリティ情報に基づいてユーザの文書に対する各種操作（閲覧、印刷、編集、削除等）についての許否判定を行うための操作許否判定機能をＷｅｂサービスとして提供するセキュリティサービス１１が実装されたコンピュータである。文書管理システム１において文書を取り扱う各種サーバ（文書管理サーバ１０、印刷サーバ５１、変換サーバ５２、及び配信サーバ５３）は、セキュリティサービス１１に対して問い合わせを行うことにより、各ユーザの文書に対する操作権限の有無等を判断する。

文書管理サーバ２０は、文書の管理（文書の保存、保存されている文書に対する検索、更新及び削除等の手段の提供等）をＷｅｂサービスとして提供する文書管理サービス２１が実装されたコンピュータである。認証サーバ３０は、文書管理システム１のユーザの認証を行うための認証機能をＷｅｂサービスとして提供する認証サービス３１が実装されたコンピュータである。認証サービス３１は、認証要求に応じてユーザの認証を行い、ユーザが認証された場合は、当該ユーザが認証された旨を証明する電子的な証明書（以下、「チケット」という。）を発行する。

印刷サーバ５１、変換サーバ５２及び配信サーバ５３は、文書管理サーバ２０に管理されている文書を扱う各種サーバの例示である。印刷サーバ５１は、文書をプリンタに印刷させるための機能が実装されたコンピュータである。変換サーバ５２は、文書を所定のデータ形式に変換するための機能が実装されたコンピュータである。配信サーバ５３は、文書を所定の宛先に配信するための機能が実装されたコンピュータである。

クライアント装置４０は、上述した各種サーバの機能を利用するアプリケーションが実装されたコンピュータである。但し、クライアント装置４０は、ユーザが直接利用する端末であるとは限らない。例えば、クライアント装置４０は、Ｗｅｂサーバであってもよく、その場合、クライアント装置４０に実装されたアプリケーションは、Ｗｅｂアプリケーションに相当する。

次に、セキュリティ管理サーバ１０の詳細について説明する。図２は、本発明の実施の形態におけるセキュリティ管理サーバのハードウェア構成例を示す図である。図２のセキュリティ管理サーバ１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、演算処理装置１０４と、インタフェース装置１０５とを有するように構成される。

セキュリティ管理サーバ１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。演算処理装置１０４は、メモリ装置１０３に格納されたプログラムに従ってセキュリティ管理サーバ１０に係る機能を実行する。インタフェース装置１０５は例えばモデム、ルータ等で構成され、図１のネットワーク６０に接続するために用いられる。

図３は、本発明の実施の形態におけるセキュリティ管理サーバ機能構成例を示す図である。図３に示されるように、セキュリティ管理サーバ１０におけるセキュリティサービス１１は、セキュリティサービス層１１１、操作許否判定部１１２、ポリシー管理部１１３、ポリシー１１４、許可証発行部１１５、許可証管理部１１６、及び許可証管理テーブル１１７等より構成される。

セキュリティサービス層１１１は、セキュリティサービスの機能をネットワーク上に公開するための層である。すなわち、セキュリティサービス層１１１は、クライアント装置４０におけるアプリケーション４１から送信されるＳＯＡＰメッセージを解析することにより、アプリケーション４１からの要求を判断し、その判断結果に基づいてアプリケーション４１から要求された機能を実行するために操作許否判定部１１２又は許可証発行部１１５を呼び出す。セキュリティサービス層１１１は、また、呼び出した操作許否判定部１１２又は許可証発行部１１５から返却される処理結果をＳＯＡＰメッセージとしてアプリケーション４１に対して返信する。

操作許否判定部１１２は、アプリケーション４１からの要求に応じて、ポリシー１１４や許可証管理テーブル１１７等に管理されているセキュリティ情報に基づいて、アプリケーション４１のユーザの任意の文書に対する各種操作についての許否判定を行うための機能が実装されたモジュールである。ポリシー管理部１１３は、ポリシー１１４にアクセスするためのインタフェースを上位モジュール（ここでは、操作許否判定部１１２及び許可証発行部１１５）に対して提供するためのモジュールである。

ポリシー１１４は、セキュリティ情報の一部を構成する情報として、文書を操作する主体（ユーザ）を所定の基準に基づいて分類し、また、操作対象となる資源（文書）を所定の基準に基づいて分類した場合において、主体の分類と資源の分類との組み合わせに応じて、各種操作に関しての許否判定を行うためのセキュリティルール（規則）が定義されたファイルである。

図４は、ポリシーの定義内容の概念的に示す図である。図４の表１１４０においては、ユーザをロール、文書との関係によって分類し、文書を状態、機密レベルによって分類した場合において、ユーザの分類と文書の分類との組み合わせごとに各種操作についての許否判定のためのセキュリティルールが示されている。

ロールとは、企業等のユーザが属する組織におけるユーザの役割（一般社員、管理職、派遣社員等）によってユーザを分類するためのパラメータであり、表１１４０においては、列１１４１によってロールが特定される。文書との関係とは、ユーザが文書の関係者であるか否かによってユーザを分類するためのパラメータである。本実施の形態において、ユーザが属する部署と文書の管理部署とが同一の場合は、当該ユーザは当該文書の関係者であるとされ、異なる場合は当該ユーザは当該文書の関係者以外であるとされる。表１１４０においては、列１１４２によって文書との関係が特定される。

状態とは、文書のライフサイクルにおける状態によって文書を分類するためのパラメータであり、例えば、作成中、完成、廃棄等の状態がある。表１１４０においては、列１１４３によって文書の状態が特定される。機密レベルとは、文書の機密度によって文書を分類するためのパラメータであり、例えば、極秘、秘、社外秘等の機密レベルがある。表１１４０においては、列１１４４、列１１４５、列１１４６にそれぞれ、極秘、秘、社外秘の文書に対するセキュリティルールが割り当てられている。

図中において、破線で囲まれたそれぞれの領域が、上記のパラメータの組み合わせごとに形成される単位を示している。当該単位ごとに、各種操作についての許否がその操作名の横に○（許可）又は×（不許可）で定義されており、更に、操作名の下の行には、当該操作を行う際に課される責務の内容が定義されている。したがって、表１１４０より、例えば、文書１が秘文書であり、かつ、完成文書である場合において、ユーザＡが一般社員であり、文書１の関係者である場合は、ユーザＡは、文書１の閲覧は可能であるが、その際には、ログを記録しなければならない旨が分かる。

なお、文書を更に、他のパラメータ、例えば、文書カテゴリ（仕様書、議事録、報告書等）によって分類した場合は、表１１４０に示される内容が文書カテゴリごとに定義され得る。また、ユーザや文書を分類するための基準は単なるパラメータであるため、組織の事情やシステムに応じて様々なものを用いることが可能であり、どのような基準によって分類するかは運用に合わせて適宜選択すればよい。

図３に戻る。許可証発行部１１５は、アプリケーション４１からの要求に応じて、新たな許可証を発行するための機能が実装されたモジュールである。許可証の発行とは、新たな許可証を許可証管理テーブル１１７に登録することをいう。また、許可証とは、特定の文書について特定のユーザに対して特定の操作を許可するためのセキュリティ情報であるが、詳細については後述する。許可証管理部１１６は、許可証管理テーブル１１７にアクセスするためのインタフェースを上位モジュール（ここでは、操作許否判定部１１２及び許可証発行部１１５）に対して提供するためのモジュールである。

許可証管理テーブル１１７は、許可証を管理するためのテーブルである。図５は、許可証管理テーブルの構成例を示す図である。許可証管理テーブル１１７における一レコード（行）が、一つの許可証に相当する。許可証は，ユーザ指定、文書指定、操作種別、責務、コメント等の項目から構成される。ユーザ指定は、許可証の適用対象となるユーザを指定するための項目であり、例えば、ユーザＩＤによって一ユーザを指定したり、あるいは、所属部署やロール等の指定することで当該所属部署やロールに分類される複数のユーザを指定したりすることができる。

文書指定は、許可証の適用対象となる文書を指定するための項目であり、例えば、文書ＩＤによって一文書を指定したり、あるいは、管理部署や文書カテゴリを指定することで当該管理部署や当該文書カテゴリに分類される複数の文書を指定したりすることができる。操作種別は、許可証によって許可される操作の種別を指定するための項目である。責務は、許可証によって許可される操作の際に課される責務の内容が定義された項目である。コメントは、例えば、許可証が発行された理由等を記録するための項目である。したがって、例えば、許可証管理テーブル１１７における一行目の許可証は、文書ＩＤが「０００００ＡＢＣ」の文書について、ユーザＩＤが「０７０Ｂ２ＡＥＣ」のユーザに対して印刷を許可するための許可証であるといえる。但し、当該許可証によれば、当該ユーザは、印刷の際にログを記録しなければならず、２００４／１０／１０までの一回のみ印刷が許可されることが分かる。

このように、ポリシー１１４における定義（セキュリティルール）は、文書に対する操作権限について包括的かつ抽象的なものであるのに対し、許可証における定義は、部分的かつ具体的なものであるといえる。以下においては、性質の異なる二種類のセキュリティ情報を用いて柔軟性のあるセキュリティシステムを構築する例について説明する。

まず、第一の実施の形態として、ポリシー１１４に対して許可証を優先させて許否判定を行う例について説明する。図６は、第一の実施の形態におけるポリシーと許可証との関係を示す図である。図６においては、機密レベルや文書カテゴリ等によって分類される文書に対するポリシー定義と、許可証の定義が干渉した場合は、許可証の定義を優先させる旨が示されている。

図７、図８及び図９は、第一の実施の形態におけるポリシーの定義例を示す図である。図７等におけるポリシー１１４ａは、ＸＡＣＭＬ（eXtensible Access Control Markup Language）の仕様に基づいて定義されている。なお、図７、図８、及び図９は、一つのファイル内においてなされている定義を、便宜上分割して表示したものである。ポリシー１１４ａにおいては、一つのセキュリティルールに対応する定義は、＜Ｒｕｌｅ＞タグで囲まれたＲｕｌｅ定義が該当する。図中においては、Ｒｕｌｅ定義ｒ１（図７）、Ｒｕｌｅ定義ｒ２、Ｒｕｌｅ定義ｒ３（図８）、Ｒｕｌｅ定義ｒ４（図９）等がＲｕｌｅ定義として表示されている。各Ｒｕｌｅ定義は、＜Ｔａｒｇｅｔ＞タグで囲まれたＴａｒｇｅｔ定義を要素として含む。例えば、Ｒｕｌｅ定義ｒ１には、Ｔａｒｇｅｔ定義ｔ１が含まれている。

Ｔａｒｇｅｔ定義は、当該セキュリティルールを適用する対象（主体、資源、操作）を特定するための定義であり、＜Ｓｕｂｊｅｃｔ（ｓ）＞タグで囲まれたＳｕｂｊｅｃｔ定義、＜Ｒｅｓｏｕｒｃｅ（ｓ）＞タグで囲まれたＲｅｓｏｕｒｃｅ定義、＜Ａｃｔｉｏｎ（ｓ）＞タグで囲まれたＡｃｔｉｏｎ定義等を含む。Ｓｕｂｊｅｃｔ定義は、セキュリティルールを適用する主体の分類を特定するための定義である。Ｒｅｓｏｕｒｃｅ定義は、セキュリティルールを適用する資源の分類を特定するための定義である。Ａｃｔｉｏｎ定義は、セキュリティルールを適用する操作の種別を特定するための定義である。例えば、Ｔａｒｇｅｔ定義ｔ１より、Ｒｕｌｅ定義ｒ１は、関係者（主体）による秘文書（資源）の閲覧（操作）の許否を判定する際に適用されるセキュリティルールであることが特定される。

セキュリティルールを適用した場合の許否判定の結果は、当該Ｒｕｌｅ定義のＥｆｆｅｃｔ属性の値によって特定される。すなわち、Ｅｆｆｅｃｔ属性の値が「Ｐｅｒｍｉｔ」であれば、判定結果は「許可」となり、「Ｄｅｎｙ」であれば判定結果は「不許可」となる。例えば、Ｒｕｌｅ定義ｒ１のＥｆｆｅｃｔ属性ｅ１の値は、「Ｐｅｒｍｉｔ」であることから、Ｒｕｌｅ定義ｒ１が適用される場合の判定結果は「許可」であることが分かる。以上より、Ｒｕｌｅ定義ｒ１には、「関係者による秘文書の閲覧は許可する。」旨が定義されていることとなる。

一つ以上のＲｕｌｅ定義は、＜Ｐｏｌｉｃｙ＞タグで囲まれたＰｏｌｉｃｙ定義によってまとめることができる。図中には、Ｐｏｌｉｃｙ定義ｐ１（図７）、Ｐｏｌｉｃｙ定義ｐ２、Ｐｏｌｉｃｙ定義ｐ３（図８）、及びＰｏｌｉｃｙ定義ｐ４（図９）等がＰｏｌｉｃｙ定義として表示されている。一つのＰｏｌｉｃｙ定義には、＜Ｏｂｌｉｇａｔｉｏｎ（ｓ）＞タグで囲まれたＯｂｌｉｇａｔｉｏｎ定義、及び＜Ｄｅｓｃｒｉｐｔｉｏｎ＞タグで囲まれたＤｅｓｃｒｉｐｔｉｏｎ定義等を含み得る。例えば、Ｐｏｌｉｃｙ定義ｐ１には、Ｏｂｌｉｇａｔｉｏｎ定義ｏ１とＤｅｓｃｒｉｐｔｉｏｎ定義ｄ１とが含まれている。

Ｏｂｌｉｇａｔｉｏｎ定義は、資源に対する操作を許可する場合に強制する責務を規定するための定義であり、当該Ｏｂｌｉｇａｔｉｏｎ定義を含むＰｏｌｉｃｙ定義に属する全てのＲｕｌｅ定義に対して共通的に適用される。但し、本実施の形態においては、Ｐｏｌｉｃｙ定義とＲｕｌｅ定義とは一対一に対応している。これは、ＸＡＣＭＬの仕様上、Ｏｂｌｉｇａｔｉｏｎ定義はＰｏｌｉｃｙ定義ごとに定義されるものであるところ、本実施の形態においては、Ｒｕｌｅ定義ごとにＯｂｌｉｇａｔｉｏｎ定義を対応させたいからである。Ｏｂｌｉｇａｔｉｏｎ定義ｏ１には、「ログ記録」が責務として規定されている。したがって、Ｐｏｌｉｃｙ定義ｐ１には、「関係者による秘文書の閲覧は許可する。但し、閲覧の際には、ログを記録しなければならない。」旨が定義されていることとなる。

Ｄｅｓｃｒｉｐｔｉｏｎ定義は、当該Ｄｅｓｃｒｉｐｔｉｏｎ定義が属するＰｏｌｉｃｙ定義におけるＲｕｌｅ定義の定義内容を説明した説明文が定義されたものである。

Ｐｏｌｉｃｙ定義には、更に、ＰｏｌｉｃｙＩＤ属性が定義されている。ＰｏｌｉｃｙＩＤ属性は、各Ｐｏｌｉｃｙ定義を一意に識別するためのＩＤである。例えば、Ｐｏｌｉｃｙ定義ｐ１のＰｏｌｉｃｙＩＤ属性ｉ１の値は「Ｐｏｌｉｃｙ１」として定義されている。

図１０は、第一の実施の形態におけるポリシーの定義内容を概念的に示す図である。すなわち、図１０の表１１４０ａは、図７等に示したポリシー１１４ａにおける記述から導出される定義内容を表形式にまとめて表示したものである。図１０に示されるように、ポリシー１１４ａにおける記述によって、主体の分類（文書の関係者又は関係者以外）と文書の分類（極秘、秘、社外秘）との組み合わせに応じて、操作の種別（閲覧、印刷）ごとについての許否（○又は×）、責務、定義内容説明文が定義されたこととなる。なお、図１０においては、図１０において示したユーザのロール、文書の状態及び文書カテゴリ等の分類は除かれているが、これは説明を容易にするための便宜的なものである。

以下、図３のセキュリティ管理サーバ１０の処理手順について説明する。図１１は、第一の実施の形態におけるセキュリティ管理サーバによる操作許否判定処理を説明するためのフローチャートである。

ステップＳ１１０において、アプリケーション４１からの許否判定の要求に基づいて操作許否判定部１１２が呼び出されると、操作許否判定部１１２は、アプリケーション４１からの要求において許否判定の対象として指定されているユーザ（カレントユーザ）及び文書（カレント文書）等の分類を特定する。なお、アプリケーション４１からの許否判定の要求においては、ユーザ及び文書の他に、許否判定の対象とする操作の種別（カレント操作）が指定されている。ステップＳ１１０に続いてステップＳ１２０に進み、操作許否判定部１１２は、カレントユーザ、カレント文書及びカレント操作の組み合わせに対応する許可証（以下、「適用許可証」という。）を、許可証管理部１１６を介して許可証管理テーブル１１７より取得し、適用許可証を適用して許否判定を実行する。

許可証管理テーブル１１７に適用許可証が存在した場合（ステップＳ１３０でＹＥＳ）は、操作許否判定部１１２は、ステップＳ１２０における判定結果をセキュリティサービス層１１１を介してアプリケーション４１に送信し処理を終了する。一方、許可証管理テーブル１１７に適用許可証が無かった場合は、ポリシー１１４ａに基づいて許否判定を実行し、その判定結果をアプリケーション４１に送信する（Ｓ１４０）。

続いて、ステップＳ１１０における判定対象の分類処理について更に詳しく説明する。図１２は、操作許否判定部による判定対象の分類処理を説明するためのフローチャートである。

ステップＳ１１１において、アプリケーション４１より許否判定要求を受け付ける。当該許否判定要求には、文書ＩＤ、チケット、及び操作種別等が引数として指定されている。文書ＩＤは、カレント文書を特定するための情報である。チケットは、アプリケーション４１が、ユーザの認証を受けた際に認証サービス３１より発行されたチケットであり、カレントユーザを特定するための情報である。操作種別は、カレント操作（閲覧、印刷、編集又は削除）を特定するための情報である。

ステップＳ１１１に続いてステップＳ１１２に進み、認証サービス３１にチケットを提示（送信）することにより、カレントユーザの属性情報（以下、「ユーザプロファイル」という。）を取得し、ユーザプロファイルよりカレントユーザのユーザＩＤ、所属部署、ロール等を特定する（Ｓ１１３）ステップＳ１１３に続いてステップＳ１１４に進み、文書ＩＤに基づいてカレント文書の機密レベル、作成者、管理部署、及び文書カテゴリ等の属性情報を取得する。この属性情報は、文書管理サービス２１より取得してもよいし、セキュリティサービス１１内において、文書の分類に関連する属性情報のみを抽出して予め管理しておき、そこから取得するようにしてもよい。

ステップＳ１１４に続いてステップＳ１１５に進み、カレントユーザの所属文書とカレント文書の管理部署とを比較することにより、カレントユーザがカレント文書の関係者であるか否か（以下、「関係者フラグ」という。）を特定する。また、例えば、ポリシー１１４において、ユーザが文書の作成者であるか否かによってユーザを分類している場合は、カレントユーザのユーザ名とカレント文書の作成者とを比較することによりカレントユーザがカレント文書の作成者であるか否か（以下、「作成者フラグ」という。）を特定する。

ステップＳ１１５に続いてステップＳ１１６に進み、上記において特定されたカレントユーザの所属部署、関係者フラグ及び作成者フラグ（以下、「ユーザ分類情報」という。）と、カレント文書の文書ＩＤ，文書カテゴリ、機密レベル及び管理部署等（以下、「文書分類情報」という。）と、カレント操作の種別とを判定対象情報として出力する。

続いて、ステップＳ１２０（図１１）における許可証に基づく操作許否判定処理について説明する。図１３は、操作許否判定部による許可証に基づく操作許否判定処理を説明するためのフローチャートである。

ステップＳ１２１において、操作対象情報を入力情報として受け付ける。ステップＳ１２１に続いてステップＳ１２２以降は、許可証管理テーブル１１７において管理されている許可証ごとのループ処理である（Ｓ１２２）。まず、許可証管理テーブル１１７より、許可証を一つ取り出し（カレント許可証）（Ｓ１２３）、カレント許可証におけるユーザ指定、文書指定、及び操作種別と操作対象情報とを照合することにより、カレント許可証がカレントユーザ、カレント文書及びカレント操作を対象としたもの（適用許可証）であるかを調べる（Ｓ１２４）。カレント許可証が適用許可証であった場合は（Ｓ１２５でＹＥＳ）、カレント操作を許可する旨と共に、カレント許可証に定義されている責務の内容等を判定結果として出力する（Ｓ１２６）。

一方、カレント許可証が適用許可証でなかった場合は、次の許可証を処理対象とすべくステップＳ１２２に戻る。許可証管理テーブル１１７におけるいずれの許可証も適用許可証でなかった場合（ステップＳ１２２でＮＯ）は、適用許可証は存在しない旨を判定結果として出力する。

続いて、ステップＳ１４０（図１１）におけるポリシー１１４ａに基づく操作許否判定処理について説明する。図１４は、操作許否判定部によるポリシーに基づく操作許否判定処理を説明するためのフローチャートである。

ステップＳ１４１において、操作対象情報を入力情報として受け付ける。ステップＳ１４１に続いてステップＳ１４２以降は、ポリシー１１４ａ内におけるＰｏｌｉｃｙ定義ごとのループ処理となる（Ｓ１４２）。まず、ポリシー１１４ａにおいて定義されている順番に沿って一つのＰｏｌｉｃｙ定義を処理対象とする（Ｓ１４３）。したがって、最初は、Ｐｏｌｉｃｙ定義ｐ１が処理対象のＰｏｌｉｃｙ定義（以下「カレントＰｏｌｉｃｙ定義」という。）となる。ステップＳ１４３に続いてステップＳ１４４に進み、カレントＰｏｌｉｃｙ定義に属するＲｕｌｅ定義（カレントＲｕｌｅ定義）が、カレントユーザ、カレント文書及びカレント操作の組み合わせに対して適用されるべきＲｕｌｅ定義（適用Ｒｕｌｅ定義）であるか否かを判定する。すなわち、カレントＲｕｌｅ定義（例えば、Ｒｕｌｅ定義ｒ１）に属するＴａｒｇｅｔ定義（例えば、Ｔａｒｇｅｔ定義ｔ１。以下、「カレントＴａｒｇｅｔ定義」という。）内のＳｕｂｊｅｃｔ定義の値がカレントユーザの属する分類を示し、Ｒｅｓｏｕｒｃｅ定義の値がカレント文書の属する分類を示し、更に、Ａｃｔｉｏｎ定義の値がカレント操作と一致する場合は、カレントＲｕｌｅ定義は適用Ｒｕｌｅ定義であると判定される。一方、少なくともいずれか一つが該当しない場合は、カレントＲｕｌｅ定義は適用Ｒｕｌｅ定義ではないと判定され、次のＰｏｌｉｃｙ定義を処理対象とすべくステップＳ１４２に戻る。

カレントＲｕｌｅ定義が適用Ｒｕｌｅ定義であると判定された場合はステップＳ１４５に進み、カレントＲｕｌｅ定義のＥｆｆｅｃｔ属性に基づいて許否判定を実行すると共に、カレントＰｏｌｉｃｙ定義に属するＯｂｌｉｇａｔｉｏｎ定義、Ｄｅｓｃｒｉｐｔｉｏｎ定義より責務の内容及び定義内容説明文等を抽出し、許否判定の判定結果と共に処理結果として出力する。

ポリシー１１４ａ内において、適用Ｒｕｌｅ定義が見つからなかった場合（Ｓ１４２でＮＯ）は、判定結果は不定として出力する。なお、判定結果が不定の場合に実際にカレント操作を許可するか否かは、アプリケーション４１の事情に基づいて判断するようにすればよい。

上述したように、第一の実施の形態におけるセキュリティ管理サーバ１０によれば、許可証による定義をポリシー１１４における定義に対して優先的に適用させることにより、ポリシー１１４において許可されている権限に対して追加的な権限を付与する情報として許可証を機能させることができる。したがって、複数のシステムにまたがった統一的なセキュリティルールが定義されているという性格上、その内容を安易に変更できないポリシー１１４に基づいてアクセス制御を行う場合であっても、例えば、派遣社員に一時的な権限を付与したい場合等、例外的な場面に応じた柔軟なアクセス制御を実現することができる。

ところで、第一の実施の形態においては、ポリシー１１４と許可証との関係は、常に許可証が優先されるといった固定的なものである。しかしながら、ポリシー１１４における定義が、容易に発行可能な許可証によって安易に上書きされるのは望ましく無い場合もある。そこで、第二の実施の形態として、ポリシー１１４における定義と許可証との関係、すなわち両者間の優先度を任意に指定可能とした例について説明する。図１５は、第二の実施の形態におけるポリシーと許可証との関係を示す図である。図１５においては、例えば、秘文書や社外秘文書については許可証の定義を優先させ、極秘文書についてはポリシー１１４の定義を優先させるといったように、ユーザや文書等の分類に応じてポリシー１１４と許可証との関係が変化する旨が示されている。

図１６、図１７及び図１８は、第二の実施の形態におけるポリシーの定義例を示す図である。図１６等におけるポリシー１１４ｂの定義内容は、第一の実施の形態におけるポリシー１１４ａ（図７等）におけるものとほぼ同様である。但し、図１６等においては、各Ｒｕｌｅ定義にｓｕｐｅｒｉｏｒ属性が追加されている点が異なる。すなわち、Ｒｕｌｅ定義ｒ１、ｒ２、ｒ３、ｒ４には、それぞれ、ｓｕｐｅｒｉｏｒ属性ｓｐ１、ｓｐ２、ｓｐ３、ｓｐ４が追加されている。ｓｕｐｅｒｉｏｒ属性は、当該Ｒｕｌｅ定義におけるセキュリティルールについて許可証との干渉が発生した場合、すなわち、当該Ｒｕｌｅ定義の対象（主体、資源、操作）が許可証の対象（ユーザ指定、文書指定、操作種別）と重複した場合に、許可証を優先させるか否かを指定するための属性であり、その値が「ＴＲＵＥ」の場合は許可証を優先させる旨を示し、「ＦＡＬＳＥ」の場合は当該Ｒｕｌｅ定義を優先させる旨を示す。したがって、ポリシー１１４ｂにおいては、Ｒｕｌｅ定義ｒ２については許可証を優先させる旨が定義されていることとなる。

以下、第二の実施の形態におけるセキュリティ管理サーバ１０の処理手順について説明する。図１９は、第二の実施の形態におけるセキュリティ管理サーバによる操作許否判定処理を説明するためのフローチャートである。

ステップＳ２１０において、アプリケーション４１からの許否判定の要求に基づいて、操作許否判定部１１２は、許否判定の対象として指定されているユーザ（カレントユーザ）及び文書（カレント文書）等の分類を特定する。この処理の詳細は図１２において説明した通りである。ステップＳ２２０に続いてステップＳ２３０に進み、操作許否判定部１１２は、ポリシー１１４ｂに基づいて操作許否判定を実行すると共に、当該操作許否判定における適用Ｒｕｌｅ定義が許可証を優先させるものであるか否かを判定する。

適用Ｒｕｌｅ定義が許可証を優先させるものである場合（Ｓ２２０でＹＥＳ）は、ステップＳ２４０に進み、操作許否判定部１１２は、許可証に基づいて操作許否判定を実行する。この処理の詳細は、図１３において説明した通りである。許可証管理テーブル１１７に適用許可証が存在した場合（ステップＳ２５０でＹＥＳ）は、操作許否判定部１１２は、ステップＳ２４０における許可証に基づく判定結果をセキュリティサービス層１１１を介してアプリケーション４１に送信し処理を終了する。一方、許可証管理テーブル１１７に適用許可証が無かった場合（ステップＳ２５０でＮＯ）、又は、適用Ｒｕｌｅ定義が許可証を優先させないものである場合（ステップＳ２３０でＮｏ）は、ステップＳ２２０におけるポリシー１１４ｂに基づく判定結果をプリケーション４１に送信する（Ｓ２７０）。

続いて、ステップＳ２２０におけるポリシー１１４ｂに基づく操作許否判定及び許可証との優先判定処理の詳細について説明する。図２０は、操作許否判定部によるポリシーに基づく操作許否判定処理及び許可証との優先判定処理を説明するためのフローチャートである。

図２０において、ステップＳ２２１〜Ｓ２２５までの処理は、図１４において説明したステップＳ１４１〜Ｓ１４５までの処理と同様である。すなわち、ポリシー１１４ｂにおけるＲｕｌｅ定義の中から適用Ｒｕｌｅ定義を特定し、当該適用Ｒｕｌｅ定義に基づいて許否判定を実行する。

ステップＳ２２５に続いてステップＳ２２６に進み、適用Ｒｕｌｅ定義のｓｕｐｅｒｉｏｒ属性に基づいて許可証との優先判定を実行する。すなわち、適用Ｒｕｌｅ定義のｓｕｐｅｒｉｏｒ属性の値がＴＲＵＥであれば、許可証を優先させる旨を判定し、ＦＡＬＳＥであれば、許可証は優先させない旨を判定する。その後、操作許否判定の結果と許可証との優先判定の結果とを出力する。

上述したように、第二の実施の形態におけるセキュリティ管理サーバ１０によれば、ポリシー１１４におけるＲｕｌｅ定義ごと、すなわち、ユーザ、文書及び操作種別の組み合わせごとに許可証を優先させるか否かについて制御することができる。したがって、より柔軟なアクセス制御が可能になると共に、許可証が安易に発行されることによるセキュリティレベルの劣化を防止することができる。

ところで、第二の実施の形態においては、発行された許可証が必ずしも優先されないため、その一部又は全部について無効な許可証が発行されることもあり得る。すなわち、許可証を発行されたとしても、当該許可証が対象とする操作が実際に許可されるとは限らない。そこで、かかる状況の発生を防止すべく、第三の実施の形態として、許可証を発行する段階においてポリシー１１４と許可証との関係を調整する例について説明する。図２１は、第三の実施の形態におけるポリシーと許可証との関係を示す図である。図２１においては、秘文書や社外秘文書を対象とする許可証の発行は可能であるが、極秘文書については、許可証の発行が禁止されている旨を示している。したがって、秘文書及び社外秘文書を対象とする許可証が発行され、その場合には許可証が優先適用されている。

図２２、図２３及び図２４は、第三の実施の形態におけるポリシーの定義例を示す図である。図２２等におけるポリシー１１４ｃの定義内容は、第二の実施の形態におけるポリ四１１４ｂ（図１６等）におけるものとほぼ同様である。但し、図２２等においては、各Ｒｕｌｅ定義にｓｕｐｅｒｉｏｒ属性の代わりにｏｖｅｒｗｒｉｔａｂｌｅ属性が定義されている点が異なる。すなわち、Ｒｕｌｅ定義ｒ１、ｒ２、ｒ３、ｒ４には、それぞれ、ｏｖｅｒｗｒｉｔａｂｌｅ属性ｗ１、ｗ２、ｗ３、ｗ４が定義されている。ｏｖｅｒｗｒｉｔａｂｌｅ属性は、当該Ｒｕｌｅ定義に対する許可証による上書きの許否を指定するための属性であり、その値が「Ｐｅｒｍｉｔ」の場合は許可証による上書きを許可する旨を、「Ｄｅｎｙ」の場合は許可証による上書きを禁止する旨を示す。したがって、ポリシー１１４ｃにおいては、Ｒｕｌｅ定義ｒ２については許可証による上書きは禁止されている旨が定義されていることとなる。

以下、第三の実施の形態におけるセキュリティ管理サーバ１０の処理手順について説明する。図２５は、第三の実施の形態におけるセキュリティ管理サーバによる許可証発行処理を説明するためのフローチャートである。

ステップＳ３１０において、アプリケーション４１からの許可証の発行要求に基づいて許可証発行部１１５が呼び出されると、許可証発行部１１５は、アプリケーション４１からの要求されている許可証の発行の可否を、当該許可証と干渉するＲｕｌｅ定義に基づいて判定する。許可証の発行が可能である場合（ステップＳ３２０でＹＥＳ）、許可証発行部１１５は、アプリケーション４１より指定された、ユーザ、文書、及び操作種別等を対象とする許可証を許可証管理部１１６を介して許可証管理テーブル１１７に登録する（Ｓ３３０）。一方、許可証の発行が不可能であると判定した場合（ステップＳ３２０でＮＯ）は、許可証発行部１１５は、許可証は発行せずに処理を終了する。

続いて、ステップＳ３１０における許可証発行の可否判定処理について更に詳しく説明する。図２６は、許可証発行部による許可証発行の可否判定処理を説明するためのフローチャートである。

ステップＳ３１１において、アプリケーション４１からの許可証発行要求を受け付ける。許可証発行要求には、許可証を構成する各項目に対応する値（ユーザ指定、文書指定、操作種別、責務、及びコメント等）が引数として指定されている。ステップＳ３１１に続いてＳ３１２以降は、ポリシー１１４ｃ内におけるＲｕｌｅ定義ごとのループ処理となる（Ｓ３１２）。まず、ポリシー１１４ｃにおいて定義されている順番に沿って一つのＲｕｌｅ定義を処理対象とする（Ｓ３１３）。したがって、最初は、Ｒｕｌｅ定義ｐ１が処理対象のＲｕｌｅ定義（カレントＲｕｌｅ定義）となる。

ステップＳ３１３に続いてステップＳ３１４に進み、カレントＲｕｌｅ定義が、発行が要求されている許可証（以下、「要求許可証」という。）がカレントＲｕｌｅ定義と干渉するか否かを判定する。すなわち、要求許可証のユーザ指定、文書指定、操作種別が、カレントＲｕｌｅ定義に属するＴａｒｇｅｔ定義におけるＳｕｂｊｅｃｔ定義、Ｒｅｓｏｕｒｃｅ定義、Ａｃｔｉｏｎ定義のそれぞれに該当する値である場合は、両者は同一対象に対する定義であるため、要求許可証とカレントＲｕｌｅ定義とは干渉すると判定される。それ以外の場合は、両者は異なる対象に対する定義であるため、要求許可証とカレントＲｕｌｅ定義とは干渉しないと判定される。

要求許可証とカレントＲｕｌｅ定義とが干渉すると判定された場合は、ステップＳ３１５に進み、カレントＲｕｌｅ定義のｏｖｅｒｗｒｉｔａｂａｌｅ属性に基づいて、カレントＲｕｌｅ定義は、許可証による上書きが可能であるか否かを判定する。許可証による上書きが許可されていない場合は、要求許可証の発行は不可能であると判定し（Ｓ３１６）、処理を終了する。一方、カレントＲｕｌｅ定義において許可証による上書きが許可されている場合（Ｓ３１５でＹＥＳ）、又は、そもそも要求許可証とカレントＲｕｌｅ定義とが干渉しない場合（Ｓ３１４でＮＯ）は、次のＲｕｌｅ定義を処理対象とすべくステップＳ３１２に戻る。全てのＲｕｌｅ定義について要求許可証との干渉が発生しないことが確認された場合（Ｓ３１２でＹＥＳ）は、要求許可証の発行は可能であると判定し（Ｓ３１７）、処理を終了する。

すなわち、図２６の処理は、対象（ユーザ、文書、操作）とする範囲が複数のＲｕｌｅ定義にまたがった許可証の発行が要求される場合を考慮して、当該範囲の全てにおいてＲｕｌｅ定義と干渉しないか、又は干渉する場合であっても当該干渉範囲において許可証による上書きが許可されている場合に許可証の発行は可能であるとし、少なくとも許可証の一部が、上書きが禁止されているＲｕｌｅ定義と干渉する場合は、許可証の発行は不可能と判断するものである。

なお、このように発行された許可証については、操作許否判定の際には、第一の実施の形態において説明した処理と同様に、ポリシー１１４ｃに優先させて適用させればよい。

上述したように、第三の実施の形態におけるセキュリティ管理サーバ１０によれば、許可証の発行の段階においてポリシー１１４と許可証との関係が調整されるため、発行された許可証は、その全範囲において有効であることが保証される。したがって、許可証に対する信頼を高めることができる。

以上、本発明の好ましい実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

本発明の実施の形態における文書管理システムの構成例を示す図である。 本発明の実施の形態におけるセキュリティ管理サーバのハードウェア構成例を示す図である。 本発明の実施の形態におけるセキュリティ管理サーバ機能構成例を示す図である。 ポリシーの定義内容の概念的に示す図である。 許可証管理テーブルの構成例を示す図である。 第一の実施の形態におけるポリシーと許可証との関係を示す図である。 第一の実施の形態におけるポリシーの定義例を示す図である。 第一の実施の形態におけるポリシーの定義例を示す図である。 第一の実施の形態におけるポリシーの定義例を示す図である。 第一の実施の形態におけるポリシーの定義内容を概念的に示す図である。 第一の実施の形態におけるセキュリティ管理サーバによる操作許否判定処理を説明するためのフローチャートである。 操作許否判定部による判定対象の分類処理を説明するためのフローチャートである。 操作許否判定部による許可証に基づく操作許否判定処理を説明するためのフローチャートである。 操作許否判定部によるポリシーに基づく操作許否判定処理を説明するためのフローチャートである。 第二の実施の形態におけるポリシーと許可証との関係を示す図である。 第二の実施の形態におけるポリシーの定義例を示す図である。 第二の実施の形態におけるポリシーの定義例を示す図である。 第二の実施の形態におけるポリシーの定義例を示す図である。 第二の実施の形態におけるセキュリティ管理サーバによる操作許否判定処理を説明するためのフローチャートである。 操作許否判定部によるポリシーに基づく操作許否判定処理及び許可証との優先判定処理を説明するためのフローチャートである。 第三の実施の形態におけるポリシーと許可証との関係を示す図である。 第三の実施の形態におけるポリシーの定義例を示す図である。 第三の実施の形態におけるポリシーの定義例を示す図である。 第三の実施の形態におけるポリシーの定義例を示す図である。 第三の実施の形態におけるセキュリティ管理サーバによる許可証発行処理を説明するためのフローチャートである。 許可証発行部による許可証発行の可否判定処理を説明するためのフローチャートである。

符号の説明

１ 文書管理システム
１０ セキュリティ管理サーバ
１１ セキュリティサービス
２０ 文書管理サーバ
２１ 文書管理サービス
３０ 認証サーバ
３１ 認証サービス
４０ クライアント装置
４１ アプリケーション
５１ 印刷サーバ
５２ 変換サーバ
５３ 配信サーバ
６０ ネットワーク
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ 演算処理装置
１０５ インタフェース装置
１１１ セキュリティサービス層
１１２ 操作許否判定部
１１３ ポリシー管理部
１１４ ポリシー
１１５ 許可証発行部
１１６ 許可証管理部
１１７ 許可証管理テーブル
Ｂ バス

Claims (22)

1. 操作の対象となる資源の分類と前記資源を操作する主体の分類との組み合わせに応じて前記操作の種別ごとに前記操作の許否判定に関する規則が定義された定義情報と、特定の資源について特定の主体に対して許可された前記操作の種別が定義された操作許可情報とに基づいて、前記主体の前記文書に対する前記操作についての許否判定を実行する許否判定手段を有することを特徴とする情報処理装置。
2. 前記許否判定手段は、前記定義情報に対して前記操作許可情報を優先させて適用することにより前記許否判定を実行することを特徴とする請求項１記載の情報処理装置。
3. 前記許否判定手段は、前記許否判定に係る前記主体、前記資源及び前記操作の種別を対象とする前記操作許可情報が存在する場合は、該操作許可情報を適用して前記許否判定を実行することにより該操作を許可する旨を判定することを特徴とする請求項２記載の情報処理装置。
4. 前記許否判定手段は、前記許否判定に係る前記主体、前記資源及び前記操作の種別を対象とする前記操作許可情報が存在しない場合は、該主体、該資源及び該操作の種別を対象とする前記規則を適用して前記許否判定を実行することを特徴とする請求項２又は３記載の情報処理装置。
5. それぞれの前記規則には、当該規則と前記操作許可情報との関係を示す関係識別情報が定義されており、
   前記許否判定手段は、前記許否判定に係る前記主体、前記資源及び前記操作の種別を対象とする前記規則に定義された前記関係識別情報に基づいて、前記操作許可情報を前記定義情報に対して優先させるかを判定することを特徴とする請求項２記載の情報処理装置。
6. 前記許否判定手段は、前記操作許可情報を優先させる旨を判定した場合であって、かつ、前記許否判定に係る前記主体、前記資源及び前記操作の種別を対象とする前記操作許可情報が存在する場合は、該操作許可情報を適用して前記許否判定を実行することにより該操作を許可する旨を判定することを特徴とする請求項５記載の情報処理装置。
7. 前記許否判定手段は、前記操作許可情報を優先させない旨を判定した場合は、前記許否判定に係る前記主体、前記資源及び前記操作の種別を対象とする前記規則を適用して前記許否判定を実行することを特徴とする請求項５又は６記載の情報処理装置。
8. 特定の資源について特定の主体に対して許可された操作の種別が定義された操作許可情報を生成する操作許可情報生成手段を有する情報処理装置であって、
   操作の対象となる資源の分類と前記資源を操作する主体の分類との組み合わせに応じて前記操作の種別ごとに前記操作の許否判定に関する規則が定義された定義情報において当該操作許可情報が対象とする前記特定の主体、前記特定の資源及び前記操作の種別を対象とし得る前記規則について、前記操作許可情報の適用が禁止されている場合は、当該操作許可情報を生成しないことを特徴とする情報処理装置。
9. 前記規則には、当該規則に対する前記操作許可情報の適用の許否を示す適用許否情報が定義されており、
   前記操作許可情報生成手段は、前記適用許否情報に基づいて、前記操作許可情報の適用の禁止を判定することを特徴とする請求項８記載の情報処理装置。
10. 前記操作許可情報生成手段は、生成に係る前記操作許可情報が対象とする記主体、前記資源及び前記操作の種別を対象とし得る前記規則が複数存在する場合は、その一部について前記操作許可情報の適用が禁止されていれば前記操作許可情報を生成しないことを特徴とする請求項８又は９記載の情報処理装置。
11. 前記定義情報を管理する定義情報管理手段を更に有することを特徴とする請求項１乃至１０いずれか一項記載の情報処理装置。
12. 前記操作許可情報を管理する操作許可情報管理手段を更に有することを特徴とする請求項１乃至１１いずれか一項記載の情報処理装置。
13. 前記定義情報は、ＸＡＣＭＬに基づいて定義されていることを特徴とする請求項１乃至１２いずれか一項記載の情報処理装置。
14. コンピュータを用いて、資源に対する操作についての許否判定を行う操作許否判定方法であって、
    それぞれに特定の資源について特定の主体に対して許可された前記操作の種別が定義された操作許可情報の中から前記許否判定に係る主体、資源及び操作の種別を対象とする前記操作許可情報を検索する操作許可情報検索手順と、
    前記操作許可情報検索手順において検索された前記操作許可情報を適用して前記許否判定を実行する第一の許否判定手順と、
    前記操作許可情報検索手順において、前記許否判定に係る主体、資源及び操作の種別を対象とする前記操作許可情報が検索されなかった場合に、資源の分類と前記資源を操作する主体の分類との組み合わせに応じて前記操作の種別ごとに前記操作の許否判定に関する規則が定義された定義情報に基づいて前記許否判定を行う第二の許否判定手順とを有することを特徴とする操作許否判定方法。
15. コンピュータを用いて、資源に対する操作についての許否判定を行う操作許否判定方法であって、
    前記資源の分類と前記資源を操作する主体の分類との組み合わせに応じて前記操作の種別ごとに前記操作の許否判定に関する規則が定義された定義情報に基づいて前記許否判定を行う第一の許否判定手順と、
    特定の資源について特定の主体に対して許可された前記操作の種別が定義された操作許可情報に基づいて前記許否判定を実行する第二の許否判定手順と、
    それぞれの前記規則に定義されている、当該規則と前記操作許可情報との関係を示す関係識別情報に基づいて、前記第一の許否判定手順及び前記第二の許否判定手順のいずれを採用するかを判定する採用判定手順とを有することを特徴とする操作許否判定方法。
16. コンピュータを用いて、特定の資源について特定の主体に対して許可された操作の種別が定義された操作許可情報を生成する操作許可情報生成方法であって、
    操作の対象となる資源の分類と前記資源を操作する主体の分類との組み合わせに応じて前記操作の種別ごとに前記操作の許否判定に関する規則が定義された定義情報の中から前記操作許可情報が対象とする前記特定の主体、前記特定の資源及び前記操作の種別を対象とし得る前記規則を検索する規則検索手順と、
    前記規則検索手順において検索された前記規則に定義された、当該規則に対する前記操作許可情報の適用の許否を示す適用許否情報に基づいて、前記操作許可情報の生成の可否を判断する生成可否判断手順とを有することを特徴とする操作許可情報生成方法。
17. コンピュータに、
    それぞれに特定の資源について特定の主体に対して許可された前記操作の種別が定義された操作許可情報の中から前記許否判定に係る主体、資源及び操作の種別を対象とする前記操作許可情報を検索する操作許可情報検索手順と、
    前記操作許可情報検索手順において検索された前記操作許可情報を適用して前記許否判定を実行する第一の許否判定手順と、
    前記操作許可情報検索手順において、前記許否判定に係る主体、資源及び操作の種別を対象とする前記操作許可情報が検索されなかった場合に、資源の分類と前記資源を操作する主体の分類との組み合わせに応じて前記操作の種別ごとに前記操作の許否判定に関する規則が定義された定義情報に基づいて前記許否判定を行う第二の許否判定手順とを実行させるための操作許否判定プログラム。
18. 請求項１７記載の操作許否判定プログラムを記録したコンピュータ読み込み可能な記録媒体。
19. コンピュータに、
    資源の分類と前記資源を操作する主体の分類との組み合わせに応じて前記操作の種別ごとに前記操作の許否判定に関する規則が定義された定義情報に基づいて前記許否判定を行う第一の許否判定手順と、
    特定の資源について特定の主体に対して許可された前記操作の種別が定義された操作許可情報に基づいて前記許否判定を実行する第二の許否判定手順と、
    それぞれの前記規則に定義されている、当該規則と前記操作許可情報との関係を示す関係識別情報に基づいて、前記第一の許否判定手順及び前記第二の許否判定手順のいずれを採用するかを判定する採用判定手順とを実行させるための操作許否判定プログラム。
20. 請求項１９記載の操作許否判定プログラムを記録したコンピュータ読み込み可能な記録媒体。
21. 特定の資源について特定の主体に対して許可された操作の種別が定義された操作許可情報を生成するコンピュータに、
    操作の対象となる資源の分類と前記資源を操作する主体の分類との組み合わせに応じて前記操作の種別ごとに前記操作の許否判定に関する規則が定義された定義情報の中から前記操作許可情報が対象とする前記特定の主体、前記特定の資源及び前記操作の種別を対象とし得る前記規則を検索する規則検索手順と、
    前記規則検索手順において検索された前記規則に定義された、当該規則に対する前記操作許可情報の適用の許否を示す適用許否情報に基づいて、前記操作許可情報の生成の可否を判断する生成可否判断手順とを実行させるための操作許可情報生成プログラム。
22. 請求項２１記載の操作許否判定プログラムを記録したコンピュータ読み込み可能な記録媒体。

Images