JP4676779B2 - 情報処理装置、資源管理装置、属性変更許否判定方法、属性変更許否判定プログラム及び記録媒体 - Google Patents

Description

本発明は、情報処理装置、資源管理装置、属性変更許否判定方法、属性変更許否判定プログラム及び記録媒体に関し、特に電子的な資源の属性の値の変更の許否を制御するための情報処理装置、資源管理装置、属性変更許否判定方法、属性変更許否判定プログラム及び記録媒体に関する。

文書管理システムにおける文書に対するアクセス制御を行なうための手段として、文書ごと、又は複数の文書の集合により構成されるグループごとにＡＣＬ（Access Control List）と呼ばれる操作可否リストを設けることにより、どのユーザにどのような操作を許可するかといったセキュリティルールを管理することが行われている。

ＡＣＬに基づくアクセス制御では、当該文書に対するＡＣＬを編集することにより、任意の文書に対するセキュリティルールを変更することができる。したがって、ＡＣＬに対する編集権限を設けることで、セキュリティルールの不正な変更を防止することができた。但しこの場合、「ＡＣＬを全く変更できない人」と「ＡＣＬを自由に変更できる人」の二種類にしか分類できなかった。

他方において、一つのシステム内だけでなく、より広範囲に渡って文書等の資源に対するアクセス制御の一貫性を保つため、複数のシステムにおけるアクセス制御に関する情報（以下、「アクセス制御情報」という。）を一つのセキュリティサーバに集約し、資源を利用する各アプリケーションはセキュリティサーバにおける統一的なアクセス制御方針（セキュリティポリシー）に基づいて資源に対する各種操作の可否を判定するといった方式も検討されている。

この場合、制御の対象となる操作はアプリケーションによって異なるため、複数のシステムにおけるアクセス制御情報をただ単に集約するだけでは管理情報が煩雑になってしまう。したがって、セキュリティサーバにおいては、より抽象度の高いセキュリティポリシーを定義しておき、個々の具体的な判定の際は、抽象的な操作ごとに定義されたポリシー記述のうち、アプリケーションごとに最も適切なポリシー記述を参照してアクセス制御を行なうこととなる（例えば、「印刷出力」処理も「ローカルＰＣへのダウンロード」処理も「文書出力ルール」ポリシーに基づいて実行の可否を判断する等。）（例えば、特許文献１）。
特開２００３−１５０７５１号公報

しかしながら、セキュリティポリシーは、資源の属性に基づいて資源を分類し、それぞれの分類ごとにセキュリティルールを定義するのが一般であるため、当該分類の基準となる属性（以下、「セキュリティ属性」という。）の属性値の変更は、当該資源に対するセキュリティルールの変更といった効果をもたらす。そうすると、従来のアクセス制御のままでは、例え、ＡＣＬに対する編集権限を有していないユーザであっても、資源の属性の属性値が許可されているユーザであれば、当該資源のセキュリティルールを変更できてしまうという問題がある。

本発明は、上記の点に鑑みてなされたものであって、アクセス対象となる資源の属性の値の変更を適切に制御することのできる情報処理装置、資源管理装置、属性変更許否判定方法、属性変更許否判定プログラム及び記録媒体の提供を目的とする。

そこで上記課題を解決するため、本発明は、請求項１に記載されるように、アクセス対象となる資源の属性の値の変更許否判定を行う判定手段を有する情報処理装置であって、前記判定手段は、前記アクセス対象となる資源の属性の値について変更前の値と変更後の値との組み合わせに応じた前記属性の値の変更についての許否判定に関する規則が定義された定義情報に基づいて、前記アクセス対象となる資源の属性の値の変更についての許否判定を行うことを特徴とする。

このような情報処理装置では、アクセス対象となる資源の属性の値の変更について、変更前の値と変更後の値の組み合わせに応じた許否判定を行うことができる。

また、上記課題を解決するため、本発明は、請求項１６に記載されるように、アクセス対象となる資源を管理する資源管理装置であって、請求項１５記載の情報処理装置に、前記アクセス対象となる資源の前記属性の変更についての許否判定を要求し、該要求に応じて前記情報処理装置より返信された判定結果に基づいて、前記アクセス対象となる資源の前記属性の変更の可否を判断することを特徴とする。

このような資源管理装置では、請求項１５記載の情報処理装置による判定結果に基づいて、管理している資源の属性の値の変更の可否を判断することができる。

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

本発明によれば、アクセス対象となる資源の属性の値の変更を適切に制御することのできる情報処理装置、資源管理装置、属性変更許否判定方法、属性変更許否判定プログラム及び記録媒体を提供することができる。

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

セキュリティサーバ１０には、セキュリティサービス１１及び文書プロファイルサービス１２等が実装されている。セキュリティサービス１１は、文書ポリシー１１１及び属性変更ポリシー１１２等の管理機能と共に、文書ポリシー１１１等に基づいて、文書管理サーバ２０において管理されている文書に対する各種操作の可否を判定する機能をＷｅｂサービスとして提供するソフトウェアであり、文書ポリシー１１１、属性変更ポリシー１１２及び属性変更判定部１１３等から構成されている。

文書ポリシー１１１は、文書に対する各種の操作（参照、印刷等）に関するセキュリティ上の規則（セキュリティルール）が定義されたファイルである。文書ポリシー１１１においては、文書属性のうちの一部の属性の値に基づいて文書が分類され、その分類に応じてセキュリティルールが定義されている。なお、文書属性のうち、セキュリティルールの定義において文書を分類するための基準となる属性を以下「セキュリティ属性」という。セキュリティ属性は、一つに限られず、複数の属性が同時にセキュリティ属性になり得る。

属性変更ポリシー１１２は、セキュリティ属性の値の変更に対するセキュリティルールが定義されたファイルである。属性変更判定部１１３は、属性変更ポリシー１１２に基づいて、任意のセキュリティ属性の値の変更の許否を判定するためにモジュールである。なお、文書ポリシー１１１及び属性変更ポリシー１１２の詳細については、後述する。

文書プロファイルサービス１２は、文書プロファイル１２１の管理機能をＷｅｂサービスとして提供するソフトウェアであり、文書プロファイル１２１及び属性対応表１２２等を有している。図２は、文書プロファイルの構成例を示す図である。図２に示されるように、文書プロファイル１２１は、文書管理サービス２１の文書ＤＢ２１１に管理されている文書の属性のうち、セキュリティ属性のみを管理するためのテーブルである。図２においては、機密レベル、文書カテゴリ、文書状態、作成者ＩＤ、及び文書管理部署等がセキュリティ属性として文書プロファイル１２１に抽出された例を示している。したがって、各文書のセキュリティ属性については、文書ＤＢ２１１と文書プロファイル１２１とにおいて二重に管理されることとなる。文書プロファイルサービス１２は、また、属性対応表１２２に基づいて、文書管理サービス２１とセキュリティサービス１１との仲介役としての機能も提供する。なお、属性対応表１２２の詳細については後述する。

文書管理サーバ２０（図１）には、文書管理サービス２１が実装されている。文書管理サービス２１は、文書ＤＢ２１１に管理されている文書（文書ファイル及び属性情報等）の管理機能をＷｅｂサービスとして提供するソフトウェアである。本実施の形態では、文書ＤＢ２１１に管理されている文書が、アクセス対象となる資源の一例とされる。

認証サーバ３０には、認証サービス３１が実装されている。認証サービス３１は、文書管理システム１のユーザの認証を行うための機能をＷｅｂサービスとして提供するソフトウェアである。認証モジュール３１は、認証要求に応じてユーザの認証を行い、ユーザが認証された場合は、当該ユーザが認証された旨を証明する電子的な証明書（以下、「チケット」という。）を発行する。

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

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

セキュリティサーバ１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。演算処理装置１０４は、メモリ装置１０３に格納されたプログラムに従ってセキュリティサーバ１０に係る機能を実行する。インタフェース装置１０５は例えばモデム、ルータ等で構成され、ネットワークに接続するために用いられる。

次に、図１において簡単に説明した文書ポリシー１１１及び属性変更ポリシー１１２について、更に詳しく説明する。図４は、文書ポリシーの定義例を概念的に示す図である。図４の表１１１ａは、文書を操作する主体（ユーザ）をその役割によって分類し、また、文書を二つのセキュリティ属性の組み合わせ（文書状態、機密レベル）によって分類した場合において、それらの組み合わせに応じて各種操作についての許否が定義された例を示している。

主体は、例えば、「作成者」、「関係者」、「責任者」、「管理者」及び「関係者以外」に分類される。「作成者」は、文書を作成したユーザであり、文書ごとに設定される。「関係者」は、文書の操作について正当な権利を持つユーザであり、文書ごとに定義された関係者のリストによって管理される。「責任者」は、文書状態や、文書の機密レベルの管理について責任を持つユーザであり、例えば、文書の承認、機密レベルの決定及び破棄の決定等を行う。「管理者」は、文書総体の管理や、文書管理システム１の運用を行うユーザである。「関係者以外」は、前記のいずれにも該当しないが、文書管理システム１のユーザとなり得るユーザである。表１１１ａにおいては、列１１１ａ−１の値によって主体の役割が特定される。なお、図中においては便宜上、作成者に対する定義のみが表示されているが、他の役割についても同様の定義がなされる。

文書状態は、文書のライフサイクルにおける状態であり、例えば、「作成中」、「完成」及び「破棄」等がある。「作成中」は、未完成又は未承認の状態を示す。作成中の文書に対しては、作成者に主な権限が与えられる。「完成」は、正式文書とされた状態、例えば、責任者によって承認された状態を示す。完成文書に対しては、管理者に主な権限が与えられ、関係者には閲覧や更新等の権限が与えられる。「破棄」は、期限切れなどで無効となった状態を示す。表１１１ａにおいては、列１１１ａ−２の値によって文書状態が特定される。

機密レベルには、極秘、秘及び社外秘等がある。なお、作成中の文書については、機密レベルは未確定とされる。表１１１ａにおいては、列１１１ａ−４〜列１１１ａ−７に機密レベルごとに、各操作の可否が○（可）又は×（不可）によって示されている。なお、○又は×の下の段に記載されているのは、当該操作を行うにあたっての責務を示す。

操作については、参照、印刷、更新、削除及び属性変更等がある。表１１１ａにおいては、列１１１ａ−３の値によって操作が特定される。

上記より、例えば、作成者は、作成中であり、かつ、機密レベルが未確定の文書については、参照、印刷、更新、削除及び属性変更は可能であるが、文書が完成し、機密レベルが設定された場合は、極秘文書についてはいずれの操作も許可されず、秘文書については、参照のみ、社外秘文書については、参照及び印刷のみが許可されていることが分かる。但し、秘文書及び社外秘文書を参照する際には、操作ログの記録が必要であり、社外秘文書を印刷するにあたっては、機密印刷等を行う必要がある旨が責務として示されている。なお、図４においては、概念的に表形式によって表示されているが、実装においては、例えば、ＸＡＣＭＬ（eXtensible Access Control Markup Language）によって定義してもよい。

表１１１ａからも明らかなように、文書状態及び機密属性といったセキュリティ属性の値の変更は、当該文書に対して適用されるセキュリティルールの変更をもたらす。すなわち、作成中の文書を完成文書としたり、秘文書であったものを極秘文書としたりすることにより、許可される操作が変化する。また、どのセキュリティ属性の値をどのように変更するかによって、セキュリティルールの適用に与える影響は異なる。したがって、セキュリティ属性については、セキュリティ属性ごとに値の変更の許否を制御できることが望ましい。本実施の形態においては、図５のような制御を行いたい場合を想定する。

図５は、セキュリティ属性の値の変更について本発明の実施の形態において適用されるセキュリティルールを説明するための図である。図５において、矢印１１１ｂ−１は、管理者に許可される操作を示す。矢印１１１ｂ−１より、管理者は、極秘文書、秘文書、社外秘文書のそれぞれについて、完成文書を破棄文書にすること、及び破棄文書を完成文書にすることが許可されていることが分かる。但し、機密レベルの変更は許可されていない。

矢印１１１ｂ−２から矢印１１１ｂ−４は、責任者に許可される操作を示す。矢印１１１ｂ−２より、責任者は、作成中の文書を極秘文書、秘文書又は社外秘文書として完成させることが許可されていることが分かる。なお、「完成させる」ことの具体的な意義は、アプリケーションごとに定義され得るが、例えば、文書管理システム１においては、文書の承認行為が想定される。また、矢印１１１ｂ−３より、管理者と同様の操作が許可されていることが分かる。更に、矢印１１１ｂ−４より、責任者は、機密レベルの変更が許可されていることが分かる。

矢印１１１ｂ−５は、作成者に許可されている操作を示す。矢印１１１ｂ−５より、作成者は、作成中の文書を社外秘文書として完成させることのみが許可されていることが分かる。

なお、関係者及び関係者以外については、矢印は示されていない。したがって、関係者及び関係者以外は、セキュリティ属性の値の変更については、いずれの操作も許可されていないことが分かる。

図５において概念的に説明した、セキュリティ属性の値の変更についてのセキュリティルールが実際に定義されているのが属性変更ポリシー１１２であるが、その定義内容は、例えば、図６のようになる。

図６は、属性変更ポリシーの第一の定義例を示す図である。図６においては、ＸＡＣＭＬの仕様を参考に定義した例を示している。図６の属性変更ポリシー１１２ａにおいて、＜Ｒｕｌｅ＞タグで囲まれたＲｕｌｅ定義（Ｒｕｌｅ定義１１２ａ−１、Ｒｕｌｅ定義１１２ａ−２）ごとに、セキュリティ属性の値の変更についてのセキュリティルールが定義されている。それぞれの＜Ｒｕｌｅ＞タグには、Ｅｆｆｅｃｔ属性が付加されており、その値（Ｐｅｒｍｉｔ又はＤｅｎｙ）は、当該セキュリティルールがセキュリティ属性の値の変更の許否判定における適用対象として判断された場合の判定結果（許可又は不許可）を示す。

各Ｒｕｌｅ定義には、＜Ｔａｒｇｅｔ＞タグで囲まれたＴａｒｇｅｔ定義と＜Ｃｏｎｄｉｔｉｏｎ＞タグで囲まれたＣｏｎｄｉｔｉｏｎ定義とが含まれている。

Ｔａｒｇｅｔ定義は、当該セキュリティルールを適用する対象（主体、資源、動作）を特定するための定義であり、Ｓｕｂｊｅｃｔ（ｓ）定義、Ｒｅｓｏｕｒｃｅ（ｓ）定義及びＡｃｔｉｏｎ（ｓ）定義等によって、主体、資源、動作が特定される。なお、本実施の形態において、資源に相当するのは文書であり、動作に相当するのは属性変更の操作である。また、主体は、役割によって特定され、文書は、セキュリティ属性（文書状態、機密レベル）の値によって特定される。

Ｃｏｎｄｉｔｉｏｎ定義は、当該セキュリティルールの適用を判定するための条件式が定義されたものである。

以上に基づいて、属性変更ポリシー１１２ａの定義内容について具体的に説明する。Ｒｕｌｅ定義１１２ａ−１には、Ｔａｒｇｅｔ定義１１２ａ−１１と、Ｃｏｎｄｉｔｉｏｎ定義１１２ａ−１２とが含まれている。Ｔａｒｇｅｔ定義１１２ａ−１１より、当該セキュリティルールが適用される主体、文書、操作は、それぞれ管理者、ＡＮＹ（あらゆる文書状態及びあらゆる機密レベルの文書）、属性値の変更であることが分かる。なお、図６のＴａｒｇｅｔ定義においては、文書については、許否判定の対象とされた変更が行われた後（変更後）の属性値によって特定される。

また、Ｃｏｎｄｉｔｏｎ定義１１２ａ−１２より、変更前の機密レベルと変更後の機密レベルとが同一であることが、当該セキュリティルールが適用されるための条件であることが分かる。「同一である場合」という条件は、条件を判定するためのパラメータが＜ｅｑｕａｌ＞タグによって囲まれていることによって導き出される。更に、Ｒｕｌｅ定義１１２ａ−１のＥｆｆｅｃｔ属性１１２ａ−１３の値が「Ｐｅｒｍｉｔ」であることから、当該セキュリティルールが適用される場合の判定結果は「許可」であることが分かる。

したがって、Ｒｕｌｅ定義１１２ａ−１より、「変更前の機密レベルと変更後の機密レベルとが同一であれば、管理者は、セキュリティ属性の値を任意（ＡＮＹ）の値に変更することができる。」ということが導き出される。これは、すなわち、図５における矢印１１１ｂ−１に該当する。

一方、Ｒｕｌｅ定義１１２ａ−２には、Ｔａｒｇｅｔ定義１１２ａ−２１と、Ｃｏｎｄｉｔｉｏｎ定義１１２ａ−２２とが含まれている。Ｔａｒｇｅｔ定義１１２ａ−２１より、当該セキュリティルールが適用される主体、文書、操作は、それぞれ作成者、（変更後の機密レベルが）社外秘文書、属性値の変更であることが分かる。また、Ｃｏｎｄｉｔｏｎ定義１１２ａ−２２より、変更前の機密レベル未確定であることが、当該セキュリティルールが適用されるための条件であることが分かる。更に、Ｒｕｌｅ定義１１２ａ−２のＥｆｆｅｃｔ属性１１２ａ−２３の値が「Ｐｅｒｍｉｔ」であることから、当該セキュリティルールが適用される場合の判定結果は「許可」であることが分かる。

したがって、Ｒｕｌｅ定義１１２ａ−２より、「作成者は、機密レベルが未確定の文書を社外秘文書とすることができる。」ということが導き出される。これは、すなわち、図５における矢印１１１ｂ−５に該当する。

なお、その他、責任者等についての定義も同様になし得るが、図６においては便宜上省略している。

図７は、図６における定義内容を概念的に示す図である。図６については、セキュリティ属性について、当該値に変更することが許可されるケースに「○」が示されている。例えば、管理者については、極秘文書、秘文書、社外秘文書のいずれについても、完成文書とすることができし、破棄文書とすることもできる旨が示されている。ただし、それぞれのケースには、「文書状態の変更に限る」といった条件が付加されている。これは、すなわち、機密レベルの変更はできない旨を示しており、図６における「変更前の機密レベルと変更後の機密レベルとが同一であれば」という条件に相当する。

なお、属性変更ポリシー１１１の定義については、図８のようにしてもよい。図８は、属性変更ポリシーの第二の定義例を示す図である。図８の属性変更ポリシー１１２ｂは、Ｔａｒｇｅｔ定義及びＣｏｎｄｉｔｉｏｎ定義等を含む一つ以上のＲｕｌｅ定義によって構成されている点においては、属性変更ポリシー１１２ａ（図６）同様の構造をしているが、記述の仕方が異なっている。但し、Ｒｕｌｅ定義１１２ｂ−１において定義されている内容は、図６におけるＲｕｌｅ定義１１２ａ−２におけるものと同じである。

すなわち、図８においては、Ｔａｒｇｅｔ要素１１２ｂ−１１における文書の特定は、変更前のセキュリティ属性の値によって行われる。また、Ｃｏｎｄｉｔｏｎ定義１１２ｂ−１２には、「変更前の機密レベルが未確定であり、かつ、変更後の機密レベルが社外であること」が条件とされている。ここで「かつ」という条件は、＜ｅｑｕａｌ＞タグで囲まれた各条件式が＜ａｎｄ＞タグ１１２ｂ−１２１によって囲まれていることから導き出される。したがって、Ｒｕｌｅ定義１１２ｂ−１においては、「作成者は、変更前の機密レベルが未確定の文書を社外秘とすることができる。」ということが定義されている。これは、すなわち、Ｒｕｌｅ定義１１２ａ−２と同様、図５における矢印１１１ｂ−５に該当する。

このように、属性変更ポリシー１１１の具体的な記述の仕方は様々なものが考えられるが、具体的な表現形式は異なっていても、セキュリティ属性の値の変更について変更前の値と変更後の値との組み合わせに応じて、かつ、主体の役割に応じてセキュリティルールが定義されているという内容についてはいずれにおいても同様である。

以下、任意の文書に対して、任意のセキュリティ属性の変更が要求された場合の文書管理システム１における処理手順について説明する。図９は、セキュリティ属性の変更が要求された場合の処理概要を説明するためのシーケンス図である。

ステップＳ１０１からステップＳ１０８までは、文書のセキュリティ属性の変更にあたり、前提となる処理（セッションの開設、文書の検索等）である。すなわち、ユーザによるログイン指示に基づいて、クライアントアプリ４１は、ユーザ名及びパスワードを引数として認証サービス３１に対してユーザの認証を要求する（Ｓ１０１）。認証サービス３１は、ユーザを認証し、ユーザが認証された場合はその旨を証明するチケットを生成する。チケットには、例えば、当該チケットを識別するチケットＩＤ、当該チケットが有効なサービスを示す有効範囲、当該チケットによってサービスを利用できる有効期限、ユーザＩＤ、及び改竄チェック用のコード等が記録される。チケットは、その内容を認証サービス３１のみが参照可能なように暗号化され、クライアントアプリ４１に送信される（Ｓ１０２）。

クライアントアプリ４１は、チケットを引数としてセッションの開設要求を文書管理サービス２１に送信する（Ｓ１０３）。文書管理サービス２１は、受信したチケットの正当性の検証を認証サービス３１に要求し（Ｓ１０４）、正当である旨の検証結果が返信されると（Ｓ１０５）、セッションＩＤをクライアントアプリ４１に対して返信する（Ｓ１０６）。なお、文書管理サービス２１は、ユーザのチケットをセッションＩＤと関連付けて保存しておく。

セッションの開設後、ユーザが、文書の検索を要求すると、クライアントアプリ４１は、セッションＩＤ及び検索条件等を引数として文書の検索要求を文書管理サービス２１に送信する（Ｓ１０７）。文書管理サービス２１は、検索条件に基づいて文書を検索し、その検索結果をクライアントアプリ４１に送信する（Ｓ１０８）。

この時点で、ユーザには、検索された文書の一覧が表示された文書一覧画面が提供される。そこで、ユーザが任意の文書を選択し、選択した文書（以下、「カレント文書」という。）のセキュリティ属性の変更を要する操作（例えば、文書の承認等）を行ったとする。なお、変更対象とされたセキュリティ属性を以下、「対象属性」という。

ユーザによるかかる操作に基づいて、クライアントアプリ４１は、セッションＩＤ、カレント文書の文書ＩＤ、対象属性の属性ＩＤ及び対象属性の変更後の値等を引数として、対象属性の変更要求を文書管理サービス２１に対して送信する（Ｓ１０９）。ステップＳ１０９に続いてステップＳ１１０に進み、文書管理サービス２１は、セッションＩＤに基づいて、カレントユーザに対するチケットを特定し、当該チケット、文書ＩＤ、対象属性の属性ＩＤ及変更後の属性値等を引数として、文書プロファイルサービス１２に対して、対象属性の値の変更の許否を問い合わせる。ステップＳ１１０に続いてステップＳ１１１に進み、文書プロファイルサービス１２は、カレント文書の全てのセキュリティ属性の現在（変更前）の値（以下「セキュリティ属性リスト」という。）を文書プロファイル１２１より取得し、取得したセキュリティ属性リストと、チケット、対象属性の属性ＩＤ及び変更後の属性値等を引数として、セキュリティサービス１１に対して、対象属性の値の変更の許否を問い合わせる。

ステップＳ１１１に続いてステップＳ１１２に進み、セキュリティサービス１１が、認証サービス３１に対してチケットの正当性の検証を要求すると、認証サービス３１は、チケットの正当性を検証すると共に、ユーザディレクトリ３１１よりカレントユーザのユーザ情報（ユーザＩＤ、グループＩＤ、所属部署等）を検索し、当該ユーザ情報をセキュリティサービス１１に対して返信する（Ｓ１１３）。ステップＳ１１３に続いてステップＳ１１４に進み、セキュリティサービス１１が、属性変更判定部１１３を呼び出すと、属性変更判定部１１３は、セキュリティ属性リスト、対象属性の属性ＩＤ、及び変更後の属性値等と、属性変更ポリシー１１２とに基づいて属性値の変更の許否を判定し、その判定結果をセキュリティサービス１１に対して出力する（Ｓ１１５）。セキュリティサービス１１は、受け取った判定結果を認証サービス３１に対して出力する（Ｓ１１６）。

判定結果において、属性値の変更は不許可である旨が示されている場合は、文書プロファイルサービス１２は、属性値の変更ができない旨のエラー通知を文書管理サービス２１に対して送信する（Ｓ１１７）。エラー通知の受信に基づいて、文書管理サービス２１は、クライアントアプリ４１に対してエラー通知を送信する（Ｓ１１８）。

一方、判定結果において、属性値の変更を許可する旨が示されている場合は、ステップＳ１１６に続いてステップＳ１１９に進み、文書プロファイルサービス１２は、文書プロファイル１２１におけるカレント文書の対象属性の値を変更後の値に更新する。続いて、文書プロファイルサービス１２は、属性の値の変更を許可する旨の判定結果を文書管理サービス２１に対して送信する（Ｓ１２０）。ステップＳ１２０に続いてステップＳ１２１に進み、文書管理サービス２１は、文書ＤＢ２１１におけるカレント文書の対象属性の値を変更後の値に更新し、属性の値の変更処理が完了した旨をクライアントアプリ４１に対して送信する（Ｓ１２２）。

以上によって、カレント文書のセキュリティ属性の値が変更されたため、以降、カレント文書に対する任意の操作（参照、印刷、更新、削除及び属性変更等）が、クライアントアプリ４１から要求された場合のアクセス制御に関しては、変更後のセキュリティ属性の値に基づいて文書ポリシー１１１を適用することにより判断されることとなる。

次に、図９において、文書プロファイルサービス１２が、文書管理サービス２１より対象属性の値の変更の許否について問い合わせを受けた際に実行される処理（Ｓ１１０〜Ｓ１２０）の詳細について説明する。図１０は、文書プロファイルサービスにおけるセキュリティ属性の値の変更処理を説明するためのフローチャートである。

ステップＳ２０１において、対象属性の値の変更の許否についての問い合わせを文書管理サービス２１より受信する。上述したように、当該問い合わせには、チケット、文書ＩＤ、対象属性の属性ＩＤ及変更後の値等が引数として含まれている。ステップＳ２０１に続いてステップＳ２０２に進み、属性ＩＤ及び変更後の値を、属性対応表１２２に基づいて、セキュリティサービス１１が解釈可能な値に変換する。

図１１は、属性対応表の構成例を示す図である。図１１に示されるように、属性対応表１２２は、属性ＩＤ、セキュリティ属性ＩＤ、及び値の対応情報等の項目から構成されている。属性ＩＤは、文書ＤＢ２１１において、各属性を識別するためにそれぞれの属性に一意に割り当てられたＩＤである。したがって、文書管理サービス２１やクライアントアプリ４１においては、各属性は、属性ＩＤによって識別される。セキュリティ属性ＩＤは、文書プロファイル１２１、文書ポリシー１１１又は属性変更ポリシー１１２において各属性を一意に識別するためのＩＤである。したがって、文書プロファイルサービス１２やセキュリティサービス１１においては、各属性は、セキュリティ属性ＩＤによって識別される。値の対応情報は、文書ＤＢ２１１における値と、文書プロファイル１２１、文書ポリシー１１１及び属性変更ポリシー１１２における値とのマッピング情報である。すなわち、一行目のレコードにおいては、「直接対応」となっているが、これは、当該属性ついては、文書ＤＢ２１１における値と文書プロファイル１２１等における値とが同一であることが示されている。また、二行目のレコードにおいては、当該属性については、文書ＤＢ２１１における「１」、「２」、「３」、「４」という値は、文書プロファイル１２１等における「極秘」、「秘」、「社外秘」、「一般」という値に対応することが示されている。三行目のレコードも同様にマッピング情報が示されている。

このように、文書管理サービス２１とセキュリティサービス１１との間で、属性の値が一致しないのは、セキュリティサービス１１は、文書管理サービス２１のみならず、図１においては図示されていないその他の各種サービスからも利用されるため、より抽象度の高い概念で属性情報を管理する必要があるからである。

したがって、例えば、文書管理サービスからの問い合わせにおいて、属性ＩＤが「１４６Ｄ４４ＤＦ」として指定されている場合は、当該属性ＩＤは、セキュリティ属性ＩＤとしての「機密レベル」に変換され、変更後の属性の値が「１」として指定されている場合は、当該値は、「極秘」に変換される。なお、変換後の属性値を以下「セキュリティ属性値」という。

ステップＳ２０２に続いてステップＳ２０３に進み、文書プロファイル１２１（図２）より、カレント文書の変更前のセキュリティ属性の値をセキュリティ属性リストとして取得する。例えば、カレント文書の「機密レベル」、「文書カテゴリ」、「文書状態」、「作成者ＩＤ」、「文書管理部署」等が取得される。ステップＳ２０３に続いてステップＳ２０４に進み、チケット、セキュリティ属性リスト、対象属性のセキュリティ属性ＩＤ及び変更後のセキュリティ属性値等を引数として、セキュリティサービス１１に対して、対象属性の値の変更の許否を問い合わせる。

ステップＳ２０４に続いてステップＳ２０５に進み、ステップＳ２０３における問い合わせに対するセキュリティサービス１１からの対象属性の値の変更の許否についての判定結果を取得すると、当該判定結果に基づいて値の変更の可否を判断する。変更が可能であると判断した場合は、文書プロファイル１２１におけるカレント文書の対象属性の値を変更後のセキュリティ属性値に更新する。対象属性の値を更新すると、文書プロファイルサービス１２は、属性の値の変更を許可する旨の判定結果を文書管理サービス２１に対して送信する。一方、変更が不可能であると判断した場合は、属性の値の変更は不許可である旨のエラー通知を文書管理サービス２１に対して送信する。

次に、セキュリティサービス１１が、文書プロファイルサービス１２より対象属性の値の変更の許否について問い合わせを受けた際に実行される処理（図９：Ｓ１１１〜Ｓ１１６）の詳細について説明する。図１２は、セキュリティサービスにおけるセキュリティ属性の値の変更の許否についての判定処理を説明するためのフローチャートである。

ステップＳ３０１において、対象属性の値の変更の許否についての問い合わせを文書管理サービス２１より受け付ける。当該問い合わせには、チケット、セキュリティ属性リスト、対象属性のセキュリティ属性ＩＤ及び変更後のセキュリティ属性値等が引数として含まれている。ステップＳ３０１に続いてステップＳ３０２に進み、チケットの正当性の検証を認証サービス３１に要求することにより、カレントユーザのユーザ情報（ユーザＩＤ、グループＩＤ、所属部署等）を認証サービス３１より取得する。ステップＳ３０２に続いてステップＳ３０３に進み、ユーザ情報及びセキュリティ属性リスト等に基づいてカレントユーザの役割を特定する。例えば、カレンユーザのユーザＩＤとカレント文書の属性リストに含まれている作成者ＩＤとが一致する場合は、カレントユーザは、カレント文書の「作成者」であることが特定される。また、カレントユーザの所属部署とカレント文書のセキュリティ属性リストに含まれている文書管理部署とが一致する場合は、カレントユーザは、カレント文書の「関係者」であることが特定される。更に、管理者又は責任者を特定するための情報を管理しているサーバ等に問い合わせることにより、カレントユーザが、管理者又は責任者であるかが特定される。

ステップＳ３０３に続いてステップＳ３０４からＳ３０７までは、属性変更ポリシー１１２（図６参照）の中から、適用対象となるルール定義（図６参照）が検索されるまで繰り返す。すなわち、属性変更判定部１１３は、属性ポリシー１１２からルール定義を一つ読み込み（Ｓ３０５）、読み込んだＲｕｌｅ定義（以下「カレントＲｕｌｅ定義」という。）内のＳｕｂｊｅｃｔ定義及びＲｅｓｏｕｒｃｅ定義に基づいて、カレントＲｕｌｅ定義が、カレントユーザ及びカレト文書に対する定義であるか否かを判断する（Ｓ３０６）。

カレントユーザ及びカレント文書に対する定義であった場合は、属性変更判定部１１３は、カレントＲｕｌｅ定義内のＡｃｔｉｏｎ定義に基づいて、カレントＲｕｌｅ定義が、属性変更に対する定義であるか否かを判断する。（Ｓ３０７）。属性変更に対する定義であった場合は、属性変更判定部１１３は、カレントＲｕｌｅ定義内のＣｏｎｄｉｔｉｏｎ定義を取得し（Ｓ３０８）、要求されている変更が、Ｃｏｎｄｉｔｏｎ定義における条件式を満たしているか否かを判断する（Ｓ３０９）。条件式が満たされている場合は、カレントＲｕｌｅ定義が適用されるべきセキュリティルールである。したがって、属性変更判定部１１３は、カレントＲｕｌｅ定義を適用対象として選択し、カレントＲｕｌｅ定義のＥｆｆｅｃｔ属性の値に従って属性値の変更の許否を判定する（Ｓ３１０）。すなわち、Ｅｆｆｅｃｔ属性の値が「Ｐｅｒｍｉｔ」である場合は、属性値の変更は許可であると判定し、「Ｄｅｎｙ」である場合は、属性値の変更は不許可であると判定する。

なお、カレントＲｕｌｅ定義が、カレントユーザ及びカレント文書に対する定義でなかった場合（Ｓ３０６でＮｏ）、属性変更に対する定義でなかった場合（Ｓ３０７でＮｏ）、又はＣｏｎｄｉｔｉｏｎ定義における条件式に合致しなかった場合（Ｓ３０９でＮｏ）は、属性変更判定部１１３は、次のルール定義をカレント定義とすべくＳ３０４以降の処理を実行する。また、属性変更ポリシー１１２におけるいずれのルール定義も適用対象とならなかった場合（Ｓ３０４でＹｅｓ）は、属性変更判定部１１３は、判定結果は「不定」とする。なお、「不定」という判定結果を許可又は不許可のいずれに解釈するかは、システムの運用に合わせて決定すればよい。例えば、本実施の形態における文書管理システム１においては、文書プロファイルサービス１２においては、「不定」という判定結果を「不許可」に置き換えるという解釈を行い、そのように解釈された判定結果が文書管理サービス２１に通知されるようにしてもよい。

上述したように、本実施の形態におけるセキュリティサーバ１０によれば、セキュリティ上重要な位置づけにあるセキュリティ属性の値の変更について、きめ細かい制御を行うことができる。すなわち、各セキュリティ属性について異なるセキュリティルールを定義することができると共に、変更前の値と変更後との値との組み合わせや、主体との組み合わせ、更に、条件式との組み合わせに応じて、セキュリティルールを定義することができる。したがって、セキュリティ属性の値が不正に変更されてしまうことを防止することができ、従来型のＡＣＬではなく、より抽象度の高いセキュリティポリシーによってアクセス制御を行う場合であっても、資源に適用されるセキュリティルールの変更に対するセキュリティを確保することができる。

また、本実施の形態におけるセキュリティサーバ１０によれば、資源に対する各種操作に関するセキュリティルール（文書ポリシー１１１）と同じ仕組み（ＸＡＣＭＬ等）に基づいてセキュリティ属性の変更についてのセキュリティールール（属性変更ポリシー１１２）を定義することができるため、それぞれのセキュリティルールの定義内容の解釈に関する実装等において共通化を図ることができ、効率的な実装を行うことができる。

ところで、近年においては、ある特定の機能に特化した組み込み機器においてもＣＰＵが搭載され、コンピュータと同様にソフトウェアによって機能を実現するものが提供されている。例えば、融合機、又は複合機と呼ばれる、プリンタ、コピー、又はファクシミリ等の複数のアプリケーションを有する画像形成装置もかかる機器に該当する。そして、このような機器にもセキュリティ機能が必要とされる場合がある。

したがって、このような機器に対して本発明を適用してもよい。図１３は、本実施の形態における各種サービスを実装した機器の構成例を示す図である。図１３中、図１と同一部分には同一符号を付し、その説明は省略する。

図１３において、機器４００は操作パネル４０１、スキャン部４０２及びプリンタ部４０３等を備え、また、セキュリティサービス１１、文書プロファイルサービス１２、文書管理サービス２１、及び認証サービス３１等を有している。すなわち、機器４００は、図１の文書管理システム１において、セキュリティサーバ１０、文書管理サーバ２０、及び認証サーバ３０に分散されていた機能が一つの筐体内に実装されている装置に相当する。

機器４００は、スキャン部４０２で読み取られた文書を文書管理サービス２１において管理し、また、文書管理サービス２１において管理されている文書をプリンタ部４０３より印刷することができる。

機器４００がこのような構成を有することで、例えば、操作パネル４０１やネットワークを介して接続する非図示のクライアントアプリ４１等からの文書のセキュリティ属性の変更操作を適切に制御することができる。

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

本発明の実施の形態における文書管理システムの構成例を示す図である。 文書プロファイルの構成例を示す図である。 本発明の実施の形態におけるセキュリティサーバのハードウェア構成例を示す図である。 文書ポリシーの定義例を概念的に示す図である。 セキュリティ属性の値の変更について本発明の実施の形態において適用されるセキュリティルールを説明するための図である。 属性変更ポリシーの第一の定義例を示す図である。 図６における定義内容を概念的に示す図である。 属性変更ポリシーの第二の定義例を示す図である。 セキュリティ属性の変更が要求された場合の処理概要を説明するためのシーケンス図である。 文書プロファイルサービスにおけるセキュリティ属性の値の変更処理を説明するためのフローチャートである。 属性対応表の構成例を示す図である。 セキュリティサービスにおけるセキュリティ属性の値の変更の許否についての判定処理を説明するためのフローチャートである。 本実施の形態における各種サービスを実装した機器の構成例を示す図である。

符号の説明

１ 文書管理システム
１０ セキュリティサーバ
１１ セキュリティサービス
１２ 文書プロファイルサービス
２０ 文書管理サーバ
２１ 文書管理サービス
３０ 認証サーバ
３１ 認証サービス３１
４０ クライアント装置
４１ クライアントアプリ
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ 演算処理装置
１０５ インタフェース装置
１１１ 文書ポリシー
１１２ 属性変更ポリシー
１１３ 属性変更判定部
２１１ 文書ＤＢ
３１１ ユーザディレクトリ
４００ 機器
４０１ 操作パネル
４０２ スキャン部
４０３ プリンタ部
Ｂ バス

Claims (19)

1. 主体の属性情報と、資源の属性情報と、前記資源の属性情報を構成する一部の属性項目に関する変更前及び変更後の少なくともいずれか一方の値に対する条件との組み合わせに応じて、当該資源の属性情報の変更の許否を示す一以上の規則情報を記憶した規則情報記憶手段と、
   特定の主体、特定の資源、該特定の資源の属性情報の変更内容が指定された当該変更の許否の問い合わせに応じ、前記資源ごとに前記資源の属性情報を記憶する資源属性情報記憶手段より前記特定の資源の属性情報を取得し、前記主体ごとに前記主体の属性情報を記憶する主体属性情報記憶手段より前記特定の主体の属性情報を取得し、前記特定の主体の属性情報及び前記特定の資源の属性情報に、前記主体の属性情報及び前記資源の属性情報が合致する前記規則情報を前記規則情報記憶手段より検索し、前記変更内容が、検索された前記規則情報の前記条件を満たす場合に、当該規則情報に基づいて前記変更の許否を判定する判定手段とを有する情報処理装置。
2. 前記資源の属性情報は、前記資源に対する所定の操作の可否判断に用いられる属性情報であることを特徴とする請求項１記載の情報処理装置。
3. 前記規則情報には、当該規則情報が前記許否の判定に適用された場合の判定結果を示す許否識別情報が定義されており、
   前記判定手段は、前記許否の判定に適用される前記規則情報に定義されている前記許否識別情報に基づいて前記許否の判定を行うことを特徴とする請求項１又は２記載の情報処理装置。
4. 前記資源の前記属性情報は、前記資源の機密度を含むことを特徴とする請求項１乃至３いずれか一項記載の情報処理装置。
5. 前記資源の前記属性情報は、前記資源のライフサイクルにおける状態を含むことを特徴とする請求項１乃至４いずれか一項記載の情報処理装置。
6. 前記主体の属性情報は、前記資源に関する役割を含むことを特徴とする請求項１乃至５いずれか一項記載の情報処理装置。
7. 前記規則情報は、ＸＡＣＭＬに基づいて記述されていることを特徴とする請求項１乃至６いずれか一項記載の情報処理装置。
8. 前記問い合わせに指定された前記変更内容に含まれる前記属性項目の値を、前記問い合わせ元において用いられている値と前記規則情報において用いられている値との対応情報を記憶した対応情報記憶手段を用いて、前記規則情報において用いられている値に変換する変換手段を有し、
   前記判定手段は、前記変換手段によって変換された値に係る前記変更内容が、前記検索された前記規則情報の前記条件を満たす場合に、当該規則情報に基づいて前記変更の許否を判定する請求項１乃至７いずれか一項記載の情報処理装置。
9. 資源を管理する資源管理装置であって、
   前記資源に対するアクセス要求に応じ、請求項１乃至８いずれか一項記載の情報処理装置に、前記アクセス対象となる資源の前記属性情報の変更の許否を問い合わせ、該問い合わせに応じて前記情報処理装置より返信された判定結果に基づいて、前記アクセス対象となる資源の前記属性情報の変更の可否を判断することを特徴とする資源管理装置。
10. コンピュータが、
    主体の属性情報と、資源の属性情報と、前記資源の属性情報を構成する一部の属性項目に関する変更前及び変更後の少なくともいずれか一方の値に対する条件との組み合わせに応じて、当該資源の属性情報の変更の許否を示す一以上の規則情報を記憶した規則情報記憶手段を用いて、
    特定の主体、特定の資源、該特定の資源の属性情報の変更内容が指定された当該変更の許否の問い合わせに応じ、前記資源ごとに前記資源の属性情報を記憶する資源属性情報記憶手段より前記特定の資源の属性情報を取得し、前記主体ごとに前記主体の属性情報を記憶する主体属性情報記憶手段より前記特定の主体の属性情報を取得し、前記特定の主体の属性情報及び前記特定の資源の属性情報に、前記主体の属性情報及び前記資源の属性情報が合致する前記規則情報を前記規則情報記憶手段より検索し、前記変更内容が、検索された前記規則情報の前記条件を満たす場合に、当該規則情報に基づいて前記変更の許否を判定する判定手順を実行することを特徴とする属性変更許否判定方法。
11. 前記資源の属性情報は、前記資源に対する所定の操作の可否判断に用いられる属性情報であることを特徴とする請求項１０記載の属性変更許否判定方法。
12. 前記規則情報には、当該規則情報が前記許否の判定に適用された場合の判定結果を示す許否識別情報が定義されており、
    前記判定手順は、前記許否の判定に適用される前記規則情報に定義されている前記許否識別情報に基づいて前記許否の判定を行うことを特徴とする請求項１０又は１１記載の属性変更許否判定方法。
13. 前記資源の前記属性情報は、前記資源の機密度を含むことを特徴とする請求項１０乃至１２いずれか一項記載の属性変更許否判定方法。
14. 前記資源の前記属性情報は、前記資源のライフサイクルにおける状態を含むことを特徴とする請求項１０乃至１３いずれか一項記載の属性変更許否判定方法。
15. 前記主体の属性情報は、前記資源に関する役割を含むことを特徴とする請求項１０乃至１４いずれか一項記載の属性変更許否判定方法。
16. 前記規則情報は、ＸＡＣＭＬに基づいて記述されていることを特徴とする請求項１０乃至１５いずれか一項記載の属性変更許否判定方法。
17. 前記問い合わせに指定された前記変更内容に含まれる前記属性項目の値を、前記問い合わせ元において用いられている値と前記規則情報において用いられている値との対応情報を記憶した対応情報記憶手段を用いて、前記規則情報において用いられている値に変換する変換手順を前記コンピュータが実行し、
    前記判定手順は、前記変換手順において変換された値に係る前記変更内容が、前記検索された前記規則情報の前記条件を満たす場合に、当該規則情報に基づいて前記変更の許否を判定する請求項１０乃至１６いずれか一項記載の属性変更許否判定方法。
18. コンピュータに、
    主体の属性情報と、資源の属性情報と、前記資源の属性情報を構成する一部の属性項目に関する変更前及び変更後の少なくともいずれか一方の値に対する条件との組み合わせに応じて、当該資源の属性情報の変更の許否を示す一以上の規則情報を記憶した規則情報記憶手段を用いて、
    特定の主体、特定の資源、該特定の資源の属性情報の変更内容が指定された当該変更の許否の問い合わせに応じ、前記資源ごとに前記資源の属性情報を記憶する資源属性情報記憶手段より前記特定の資源の属性情報を取得し、前記主体ごとに前記主体の属性情報を記憶する主体属性情報記憶手段より前記特定の主体の属性情報を取得し、前記特定の主体の属性情報及び前記特定の資源の属性情報に、前記主体の属性情報及び前記資源の属性情報が合致する前記規則情報を前記規則情報記憶手段より検索し、前記変更内容が、検索された前記規則情報の前記条件を満たす場合に、当該規則情報に基づいて前記変更の許否を判定する判定手順を実行させる属性変更許否判定プログラム。
19. 請求項１８記載の属性変更許否判定プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images