JP2007328770A - 情報処理装置、アクセス制御方法、アクセス制御プログラム、記録媒体、及び画像形成装置 - Google Patents

Abstract

【課題】セキュリティ情報の定義されたファイルを適切に保護することのできる情報処理装置、アクセス制御方法、アクセス制御プログラム、記録媒体、及び画像形成装置の提供を目的とする。
【解決手段】アプリケーションを追加可能であり、前記アプリケーションによる各リソースに対するアクセス権限が定義されたアクセス制御情報に基づいて前記リソースへのアクセスの許否を判定するアクセス制御手段を備えた情報処理装置であって、
前記アクセス制御手段は、前記アクセス制御情報に対するアクセスの発生に応じ、当該アクセスに関する情報をログファイルに保存することにより上記課題を解決する。
【選択図】図５

Description

本発明は、情報処理装置、アクセス制御方法、アクセス制御プログラム及び記録媒体に関し、特に所定のアプリケーションを実行するためのプラットフォームを備えた情報処理装置、アクセス制御方法、アクセス制御プログラム及び記録媒体に関する。

近年におけるプリンタ、コピー機、スキャナ、ファクシミリ、又はこれらの機能を一台の筐体で実現する複合機等の画像形成装置では、メモリ等の制限は厳しいものの、汎用的なコンピュータと同様にＣＰＵを備え、各機能はアプリケーションの制御によって実現されるようになっている。

このような画像形成装置の中には、Ｊａｖａ（登録商標）アプリケーションを実装及び実行するためのプラットフォームを備え、その出荷後にユーザの利用環境に適したアプリケーションを追加することにより、カスタマイズが可能とされているものもある（例えば、特許文献１）。

ところで、かかるアプリケーションのソースコードは、サードベンダやユーザ自身等、不特定の者によって作成される。したがって、作成者の故意又は不注意等によって画像形成装置内のリソースに不正にアクセスするアプリケーションが実行されてしまう恐れがある。

一方、Ｊａｖａ（登録商標）の実行環境には、アプリケーション毎（クラス毎）に、各リソースに対するアクセス制御を行うための機能が実装されている。各アプリケーションのアクセス制御情報（ポリシー）は、ポリシー設定ファイルといわれるファイル内に定義され、アプリケーションがポリシーに違反する動作を行おうとした場合、例外が発生する仕組みとなっている。かかる仕組みによって各リソースへのセキュリティは確保され得る。しかし、一つのアプリケーションの不正なアクセスによってポリシー設定ファイルが改ざんされてしまっては、それ以降セキュリティの確保が図れず、画像形成装置の信頼性が保証されなくなってしまう。したがって、ポリシー設定ファイル内の定義において、ポリシー設定ファイル自身へのアクセスを禁止しまうことが考えられる。

但し、ポリシー設定ファイルの編集が全く禁止されてしまうと不便である。そこで、ポリシー設定ファイルを編集するためのアプリケーション等、特定のアプリケーションについては、ポリシー設定ファイルへのアクセスを許可し、当該特定のアプリケーションの実行権限を特権ユーザのみに許可するといったことが考えられる。
特開２００５−２６９６１９号公報

しかしながら、権限のないユーザによる特権ユーザへのなりすましの防止は完全には保証されない。また、ポリシー設定ファイルは、テキストファイルであるため、テキストエディタ等によって編集される場合は、Ｊａｖａ（登録商標）のセキュリティ機能によって制限されることなく、容易に変更されてしまうという問題がある。

本発明は、上記の点に鑑みてなされたものであって、セキュリティ情報の定義されたファイルを適切に保護することのできる情報処理装置、アクセス制御方法、アクセス制御プログラム、記録媒体、及び画像形成装置の提供を目的とする。

そこで上記課題を解決するため、本発明は、アプリケーションを追加可能であり、前記アプリケーションによる各リソースに対するアクセス権限が定義されたアクセス制御情報に基づいて前記リソースへのアクセスの許否を判定するアクセス制御手段を備えた情報処理装置であって、前記アクセス制御手段は、前記アクセス制御情報に対するアクセスの発生に応じ、当該アクセスに関する情報をログファイルに保存することを特徴とする。

このような情報処理装置では、セキュリティ情報の定義されたファイルを適切に保護することができる。

本発明によれば、セキュリティ情報の定義されたファイルを適切に保護することのできる情報処理装置、アクセス制御方法、アクセス制御プログラム、記録媒体、及び画像形成装置を提供することができる。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施例に該当する融合機１０１を表す。図１の融合機１０１は、情報処理装置の一例としての画像形成装置であり、種々のハードウェア１１１と、種々のソフトウェア１１２とより構成される。

融合機１０１のハードウェア１１１としては、撮像部１２１と、印刷部１２２と、その他のハードウェア１２３が存在する。撮像部１２１は、読取原稿から画像（画像データ）を読み取るためのハードウェアである。印刷部１２２は、画像（画像データ）を印刷用紙に印刷するためのハードウェアである。

融合機１０１のソフトウェア１１２としては、種々のアプリケーション１３１と、種々のプラットフォーム１３２等が存在する。

アプリケーション１３１としては、標準アプリ１４１、ＳＤＫアプリケーションサービス（ＳＡＳ）１４２、ＣＳＤＫアプリ１４５、ＪＳＫＤアプリ１４６、及びＪＳＤＫプラットフォーム１４７等が存在する。

標準アプリ１４１は、融合機１０１に標準的に（出荷時に予め）実装されている各種アプリケーションの集合であり、例えば、コピー機能、プリンタ機能、スキャナ機能、及びファクシミリ機能等、融合機１０１の基本的な機能を実現するためのアプリケーションによって構成される。

ＣＳＤＫアプリ１４５、及びＪＳＫＤアプリ１４６は、専用のＳＤＫ（ソフトウェア開発キット）を使用して開発されたアプリケーションである。すなわち、融合機１０１には、その出荷後に専用のＳＤＫを使用して新たにアプリケーションを追加することができる。ＳＤＫを使用して開発されたアプリケーション１３１を本実施の形態ではＳＤＫアプリという。専用のＳＤＫとしては、Ｃ言語でアプリケーション１３１を開発するための「ＣＳＤＫ」や、Ｊａｖａ（登録商標）言語でアプリケーション１３１を開発するための「ＪＳＤＫ」が提供される。ＣＳＤＫを使用して開発したアプリケーション１３１を「ＣＳＤＫアプリ」（ＣＳＤＫアプリ１４５）という。また、ＪＳＤＫを使用して開発したアプリケーション１３１を「ＪＳＤＫアプリ」（ＪＳＫＤアプリ１４６）という。

ＪＳＤＫプラットフォーム１４７は、Ｊａｖａ（登録商標）言語で記述されたＪＳＤＫアプリ１４６に対して動作環境を提供するソフトウェアであり、例えば、Ｊａｖａ（登録商標）仮想マシンや、Ｊａｖａ（登録商標）ＭＥ（Micro Edition）において標準で提供されているクラス群の他、融合機１０１用に拡張されたクラス群（以下「拡張クラス」という。）等を含む。図中に示されている、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１、ＳｅｃｕｒｉｔｙＬｏｇクラス１４７２、及びＪＳＤＫＣｏｍｍｏｎクラス１４７３等は、拡張クラスに相当する。これらのクラスの詳細については後述する。なお、本実施の形態では、便宜上「クラス」というときに文脈に応じてそのインスタンス、すなわち、オブジェクトを意味する場合がある。

ＳＡＳ１４２は、ＳＤＫアプリの起動制御，起動解除制御，インストール制御，アンインストール制御，アップデート制御等を行うソフトウェアである。すなわち、従来、Ｗｉｎｄｏｗｓ（登録商標）アプリケーション等においては、インストーラは、各アプリケーションに付随したものであった。しかし、融合機１０１では、各アプリケーションのインストール及びアンインストール等は、ＳＡＳ１４２によって統合的に行われる。アプリケーションのインストール及びアンインストール等がＳＡＳ１４２によって統合されていることにより、ユーザは、アプリケーションごとに異なるインストール作業を要求されることはなく、インストール作業に対する作業負担が軽減される。

プラットフォーム１３２としては、コントロールサービス１５１及びＯＳ１３６等が存在する。

コントロールサービス１５１は、各種のハードウェアリソース等を制御するためのサービスを上位アプリケーション等に対して提供するソフトウェアモジュール群であり、例えば、ネットワーク通信に関するサービスを提供するためのプロセスとして起動されるネットワークコントロールサービス（ＮＣＳ）１６１等を含む。

ＯＳ１３６は、ＵＮＩＸ（登録商標）等のいわゆるＯＳであり、上記各種ソフトウェアをプロセス単位で並列的に起動する。

アプリケーション１３１とプラットフォーム１３２との間には、両者の仲介を行うソフトウェア１１２として、仮想アプリケーションサービス（ＶＡＳ）１３５が存在する。ＶＡＳ１３５は、アプリケーション１３１をクライアントとするサーバプロセスとして動作すると共に、プラットフォーム１３２をサーバとするクライアントプロセスとして動作する。ＶＡＳ１３５は、アプリケーション１３１から見てプラットフォーム１３２を隠蔽するラッピング機能を備え、プラットフォーム１３２のバージョンアップによるバージョン差を吸収する役割等を担う。

図２は、図１の融合機１０１に係るハードウェア構成図である。融合機１０１のハードウェア１１１としては、コントローラ２０１と、オペレーションパネル２０２と、ファクシミリコントロールユニット（ＦＣＵ）２０３と、撮像部１２１と、印刷部１２２が存在する。

コントローラ２０１は、ＣＰＵ２１１、ＡＳＩＣ２１２、ＮＢ２２１、ＳＢ２２２、ＭＥＭ−Ｐ２３１、ＭＥＭ−Ｃ２３２、ＨＤＤ（ハードディスクドライブ）２３３、メモリカードスロット２３４、ＮＩＣ（ネットワークインタフェースコントローラ）２４１、ＵＳＢデバイス２４２、ＩＥＥＥ１３９４デバイス２４３、セントロニクスデバイス２４４により構成される。

ＣＰＵ２１１は、種々の情報処理用のＩＣである。ＡＳＩＣ２１２は、種々の画像処理用のＩＣである。ＮＢ２２１は、コントローラ２０１のノースブリッジである。ＳＢ２２２は、コントローラ２０１のサウスブリッジである。ＭＥＭ−Ｐ２３１は、融合機１０１のシステムメモリである。ＭＥＭ−Ｃ２３２は、融合機１０１のローカルメモリである。ＨＤＤ２３３は、融合機１０１のストレージである。メモリカードスロット２３４は、ＳＤメモリカード等のメモリカード２３５をセットするためのスロットである。ＮＩＣ２４１は、ＭＡＣアドレスによるネットワーク通信用のコントローラである。ＵＳＢデバイス２４２は、ＵＳＢ規格の接続端子を提供するためのデバイスである。ＩＥＥＥ１３９４デバイス２４３は、ＩＥＥＥ１３９４規格の接続端子を提供するためのデバイスである。セントロニクスデバイス２４４は、セントロニクス仕様の接続端子を提供するためのデバイスである。

オペレーションパネル２０２は、オペレータが融合機１０１に入力を行うためのハードウェア（操作部）であると共に、オペレータが融合機１０１から出力を得るためのハードウェア（表示部）である。

なお、図１に示されるアプリケーション１３１は、ＨＤＤ２３３やメモリカード２３５に蓄積されており、これらの記録媒体よりロードされて、ＣＰＵ２１１によって実行される。

次に、拡張クラスについて説明する。図３は、標準クラスと拡張クラスとの関係を示すクラス図である。図中において、四角の枠内に含まれているクラスは、Ｊａｖａ（登録商標）の標準クラスである。

図３に示されるように、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１は、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス５０１のサブクラスである。ＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス５０１は、通常ＯＳの機能とされている、ファイル、ネットワークソケット、及びプリンタ等のリソースへのアクセスを仲介する責任を持つクラスである。ＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス５０１は、Ｊａｖａ（登録商標）アプリケーション（以下、単に「アプリ」という。）が使用するクラス（リソース）に対して持っている信頼の度合いに応じて、当該アプリによる各クラスへのアクセスを制限する。各アプリがいずれのリソースに対してアクセス権限を有するかについてはポリシー設定ファイルに定義されている。したがって、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス５０１は、ポリシー設定ファイルの定義内容にしたがって、各アプリのアクセス権限を判断する。なお、本実施の形態において「リソース」とは、各リソース（ハードウェア、ソフトウェア等）の実体のみならず、各リソースを抽象化した情報（クラス、オブジェクト）をも含む。

ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１は、上記のようなＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス５０１の性質を継承しつつ、独自の拡張がなされている。これによって、融合機１０１におけるセキュリティの強化が図られている。例えば、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス５０１は、アクセス権限のチェックが行われるたびに（すなわち、ｃｈｅｃｋＸＸＸ（）メソッドが呼び出される度に、その履歴（アクセスログ）をログファイルに出力する。なお、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１は、ポリシー設定ファイルにおいてアクセスが制限されているため、当該制限が解除されていない通常のアプリからはアクセスすることはできない。

ＳｅｃｕｒｉｔｙＬｏｇクラス１４７２は、ログファイルを管理するためのクラスである。

ところで、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１が、ＪＳＤＫプラットフォーム１４７において有効とされるには、Ｊａｖａ（登録商標）のＳｙｓｔｅｍクラスにＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクトが登録される必要がある。この登録は、ＪＳＤＫＣｏｍｍｏｎクラス１４７３によって行われる。図４は、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクトの登録シーケンスを説明するための図である。

図４に示されるように、ＪＳＤＫＣｏｍｍｏｎクラス１４７３は、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１のインスタンス（ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクト）を生成し（Ｓ１１）、当該ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクトをＪａｖａ（登録商標）標準のＳｙｓｔｅｍクラス５０３に登録する。具体的には、Ｓｙｓｔｅｍクラス５０３への登録は、ｓｅｔＳｅｃｕｒｉｔｙＭａｎａｇｅｒメソッドを呼び出すことにより行われる。なお、ＪＳＤＫＣｏｍｍｏｎクラス１４７３は、ＪＳＤＫプラットフォーム１４７が起動されるときに動作するクラスである。したがって、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎｇｅｒクラス１４７１は、ＪＳＤＫプラットフォーム１４７の起動に応じて有効となる。すなわち、ＪＳＤＫプラットフォーム１４７の起動後は、ポリシー設定ファイルに基づいて、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１によって各リソースへのアクセスが制限される。

例えば、或るアプリがファイルアクセス（書き込み又は読み込み等）を行おうとした場合、各クラス間では、次のようなメッセージがやりとりされる。図５は、ファイルアクセスが発生した際のクラス間のメッセージのやりとりを示す図である。図中において、アプリ１４６１は、ＪＳＤＫアプリ１４６として実装されている一つのアプリケーションを示す。

ファイルアクセスを行うためのＪａｖａ（登録商標）標準クラスとして、ＦｉｌｅＩｎｐｕｔＳｔｒｅａｍクラスやＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍクラスが提供されている。ＦｉｌｅＩｎｐｕｔＳｔｒｅａｍクラスは、ファイルの読み込みに用いられるクラスであり、ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍクラスは、ファイルの書き込みに用いられるクラスである。融合機１０１のＪＳＤＫプラットフォーム１４７にも、これらのクラスは含まれている。

したがって、アプリ１４６１は、例えば所定のファイル（「ファイルＡ」という。）への書き込みを行う場合、ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍクラス５０４の所定のメソッドを呼び出す（Ｓ２１）。ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍクラス５０４は、ファイルＡへの書き込みを実行する前に、ファイルＡに対するアプリ１４６１による書き込み権限のチェックをＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１に要求する（Ｓ２２）。ステップＳ２２に相当するメッセージは、Ｊａｖａ（登録商標）の標準として組み込まれているものである。なお、ステップＳ２２でＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１が呼び出されるのは、図４において説明したように、予め、Ｓｙｓｔｅｍクラス５０３にＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１が登録されているからである。

ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１は、アクセス権限のチェックが要求されるとＳｅｃｕｒｉｔｙＬｏｇクラス１４７２に対して、アプリ１４６１によってファイルＡに対する書き込みが試みられている旨のアクセスログを出力するよう要求する（Ｓ２３）。当該要求に応じ、ＳｅｃｕｒｉｔｙＬｏｇクラス１４７２は、アクセスログをログファイルに出力する。この処理の詳細については後述する。

なお、本実施の形態では、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１が、アクセスログのログファイルへの出力処理をＳｅｃｕｒｉｔｙＬｏｇクラス１４７２に委譲する例が示されているが、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１がアクセスログの出力処理を直接的に、実行してもよい。前者の場合、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１とＳｅｃｕｒｉｔｙＬｏｇクラス１４７２とによってアクセス制御手段が構成され、後者の場合、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１クラス単独によってアクセス制御手段が構成される。

続いて、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１は、ポリシー設定ファイルに基づく当該アクセス権限のチェックを継承元のクラスであるＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス５０１に要求する（Ｓ２４）。ＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス５０１は、当該アクセス権限のチェックをＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒクラス５０２に委譲する（Ｓ２５）。

続いて、ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒ５０２によってポリシー設定ファイルに基づいて当該アクセス権限のチェックが行われる。アプリ１４６１に当該アクセス権限が許可されていない場合、例外（ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ）が発行される。したがって、この場合アプリ１４６１は、ファイルＡに書き込みを行うことはできない。なお、ステップＳ２５に相当するメッセージ及び例外の発行は、Ｊａｖａ（登録商標）の標準として組み込まれている仕組みである。

ところで、ステップＳ２３のアクセスログの出力要求に応じて、ＳｅｃｕｒｉｔｙＬｏｇクラス１４７２は次のような処理を行う。図６は、ＳｅｃｕｒｉｔｙＬｏｇクラスによるアクセスログの出力処理を説明するための図である。

ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１よりアクセスログの出力要求を受けると、ＳｅｃｕｒｉｔｙＬｏｇクラス１４７２は、ログファイル６０１にアクセスログを出力すると共に、ログファイル６０１を暗号化する。暗号化により、不特定の者によるアクセスログの参照が防止される。アクセスログとしては、例えば、機体番号（融合機１０１に固有の番号）、アクセス日時、アクセスの種類、アクセスしたアプリのプロダクトＩＤ（アプリに固有のＩＤ）、アクセス結果（成功又は失敗等）等が記録される。

続いて、ＳｅｃｕｒｉｔｙＬｏｇクラス１４７２は、所定のハッシュアルゴリズムによりログファイル６０１（暗号化の前後のいずれでもよい）のハッシュ値６０２を生成し、当該ハッシュ値６０２をログファイル６０１と関連付けて保存する。すなわち、ログファイル６０１が更新される度にハッシュ値６０２も更新される。これによって、ログファイル６０１の改ざんを検知することができる。

なお、ログファイル６０１及びハッシュ値６０２等は、ＨＤＤ２３３又はメモリカード２３５等に保存される。また、ログファイル６０１に対するアクセス権限は、例えば、ポリシー設定ファイルにおいて、ＳｅｃｕｒｉｔｙＬｏｇクラス１４７２以外には許可しないようにしておくとよい。

例えば、アクセスログの書き込み先（ＨＤＤ２３３又はメモリカード２３５等）に空き容量が無い場合、ＳｅｃｕｒｉｔｙＬｏｇクラス１４７２は、次のような処理を実行する。図７は、アクセスログの書き込み容量が無い場合の処理を説明するための図である。

ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１よりアクセスログの出力要求を受けると（Ｓ２３）、ＳｅｃｕｒｉｔｙＬｏｇクラス１４７２は、書き込み先の空き容量を確認する（Ｓ４１）。空き容量が無い場合、ＳｅｃｒｉｔｙＬｏｇクラス１４７２は、ＯｐｅＰａｎｅＳｅｒｖｉｃｅクラス１４７４に対し、オペレーションパネル２０２への警告の表示を要求したり（Ｓ４２）、ＮｅｔｗｏｒｋＳｅｒｖｉｃｅクラス１４７５に対し、管理者への警告メールの送信を要求したりする（Ｓ４３）。オペレーションパネル２０２に警告メッセージが表示させたり、警告メールを送信したりすることにより、空き容量が無いことを管理者等に認識させることができ、ログファイル６０１に基づくセキュリティ機能が損なわれるのを防止することができる。

なお、ＯｐｅＰａｎｅＳｅｒｖｉｃｅクラス１４７４及びＮｅｔｗｏｒｋＳｅｒｖｉｃｅクラス１４７５は、融合機１０１の機能に対するＡＰＩ（Application Program Interface）を提供するためのクラスであり、ＪＳＤＫプラットフォーム１４７に含まれている。前者は、オペレーションパネル２０２に対する表示制御に関するＡＰＩを提供し、後者は、ネットワーク通信に関するＡＰＩを提供する。

次に、ポリシー設定ファイルの編集処理について説明する。ポリシー設定ファイルは、各アプリケーション（クラス）について、リソースに対するアクセス制御情報が定義されたものであるため、安易に編集されることは好ましくない。そこで、上記において説明した各クラスによって、ポリシー設定ファイルに対するセキュリティがどのように確保されるのかを説明する。

図８は、ポリシー設定ファイルの編集処理を説明するためのシーケンス図である。図８において、ポリシー編集アプリ１４６２は、ポリシー設定ファイルの編集機能を提供するＪＳＤＫアプリ１４６であり、例えば、管理者等の特権ユーザのみに使用権限が認められている。当該使用権限はポリシー設定ファイルとは別に、例えば、ユーザごとのアクセス制御情報（アクセスロール情報）において認められている。したがって、管理者として認証されたユーザ（例えば、管理者のパスワードを正しく入力したユーザ）は、ポリシー編集アプリ１４６２の使用が認められる。

また、ポリシー設定ファイルにおいて、ポリシー編集アプリ１４６２には当該ポリシー設定ファイルに対するアクセス権限（読み込み及び書き込み等）が許可されている。

オペレーションパネル２０２や、融合機１０１とネットワークを介して接続するクライアントＰＣ等にポリシー編集アプリ１４６２が表示させる画面を介して、管理者として認証されたユーザがポリシーの変更を指示すると、ポリシー編集アプリ１４６２は、変更内容の書き込みを、ポリシー設定ファイルに対応するＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍオブジェクト５０４Ａに要求する（Ｓ１０１）。すなわち、ポリシー設定ファイルも、他のファイルと同様、ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍクラス５０４等を介してアクセスされる。

図５において説明したように、ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍオブジェクト５０４Ａは、書き込み要求に応じ、ポリシー編集アプリ１４６２によるポリシー設定ファイルへの書き込み権限のチェックをＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクト１４７１Ａに要求する（Ｓ１０１）。ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクト１４７１Ａは、まず、ＳｅｃｕｒｉｔｙＬｏｇオブジェクト１４７２Ａに対し、ポリシー編集アプリ１４６２によってポリシー設定ファイルに対する書き込みが試みられている旨のアクセスログを出力するよう要求する（Ｓ１０３）。当該要求に応じ、ＳｅｃｕｒｉｔｙＬｏｇオブジェクト１４７２Ａは、アクセスログをログファイル６０１に出力する（Ｓ１０４）。この際、図６において説明したように、更新されたログファイル６０１は暗号化され、また、更新されたログファイル６０１のハッシュ値が保存される。

続いて、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクト１４７１Ａは、ポリシー設定ファイルに基づいて、当該書き込み権限の有無を判定する（Ｓ１０５）。なお、図５において説明したように、当該判定は、厳密にはＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒクラス５０２に委譲されるが、ここでは便宜上省略する。続いて、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクト１４７１Ａは、判定結果をアクセスログとして出力するようＳｅｃｕｒｉｔｙＬｏｇオブジェクト１４７２Ａに要求する（Ｓ１０６）。ＳｅｃｕｒｉｔｙＬｏｇオブジェクト１４７２Ａは、図６において説明したように、当該アクセスログを出力する（Ｓ１０７）。

続いて、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクト１４７１Ａは、判定結果をＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍ５０４Ａに返却する（Ｓ１０９）。上述したように、ポリシー編集アプリ１４６２には、ポリシー設定ファイルに対するアクセス権限が許可されているため、ステップＳ１０９ではその旨が返却される。なお、仮に、ポリシー編集アプリ１４６２以外のアプリが、ポリシー設定ファイルにアクセスしようとした場合、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクト１４７１Ａは、例外（ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ）を発行する（Ｓ１０８）。したがって、ポリシー編集アプリ１４６２以外のアプリは、ポリシー設定ファイルにアクセスすることはできない。

続いて、ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍ５０４Ａは、ポリシー編集アプリ１４６２から要求された変更内容をポリシー設定ファイルに書き込み（Ｓ１１０）、要求された処理が正常に行われたことを返却する（Ｓ１１１）。

続いて、ポリシー編集アプリ１４６２は、ポリシー設定ファイルに対してアクセスしたことをＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクト１４７１Ａに通知する（Ｓ１１２）。この通知は、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクト１４７１Ａにおいて拡張されたメソッドを介して行われる。

ポリシー編集アプリ１４６２からの通知を受けて、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクト１４７１Ａは、変更されたポリシー設定ファイルのハッシュ値を生成し、当該ハッシュ値をポリシー設定ファイルに関連付けて保存する（Ｓ１１３）。これによって、テキストエディタ等による改ざんの検知が可能となる。すなわち、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクト１４７１Ａを介さないでポリシー設定ファイルが変更された場合、変更後のポリシー設定ファイルのハッシュ値は、既に保存されているハッシュ値と一致しないからである。

上述したように、本実施の形態における融合機１０１によれば、ポリシー編集アプリ１４６２以外のアプリ等によるポリシー設定ファイルを適切に保護することができる。すなわち、ポリシー編集アプリ１４６２以外のアプリによるアクセスは、ポリシー設定ファイルにおいて制限され、例外が発行される。また、テキストエディタ等による変更は、ポリシー設定ファイルのハッシュ値によってその変更を検知することができる。

また、ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス１４７１は、各リソースに対するアクセスが発生する度にアクセスログを出力する。したがって、特権ユーザへのなりすましによるポリシー編集アプリ１４６２の使用について、アクセスログによって検知及び追跡することが可能である。また、アクセスログが採取されていることを周知させることにより、心理的になりすましを抑制させることができる。更に、アクセスログは、暗号化され、また、ハッシュ値が生成されるため、改ざんを防止し、また検知することができる。

特に、融合機１０１のような画像形成装置は、一台の装置が複数のユーザにより共用されるため、通常一人に一台割り当てられるＰＣ（Personal Computer）等の情報処理装置に比べて、上記のようなセキュリティの確保はより重要なものとなる。

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

本発明の実施例に該当する融合機を表す。 図１の融合機に係るハードウェア構成図である。 標準クラスと拡張クラスとの関係を示すクラス図である。 ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクトの登録シーケンスを説明するための図である。 ファイルアクセスが発生した際のクラス間のメッセージのやりとりを示す図である。 ＳｅｃｕｒｉｔｙＬｏｇクラスによるアクセスログの出力処理を説明するための図である。 アクセスログの書き込み容量が無い場合の処理を説明するための図である。 ポリシー設定ファイルの編集処理を説明するためのシーケンス図である。

符号の説明

１０１ 融合機
１１１ ハードウェア
１１２ ソフトウェア
１２１ 撮像部
１２２ 印刷部
１２３ その他のハードウェア
１３１ アプリケーション
１３２ プラットフォーム
１３５ 仮想アプリケーションサービス（ＶＡＳ）
１３６ ＯＳ
１４１ 標準アプリ
１４２ ＳＤＫアプリケーションサービス（ＳＡＳ）
１４５ ＣＳＤＫアプリ
１４６ ＪＳＤＫアプリ
１４７ ＪＳＤＫプラットフォーム
１５１ コントロールサービス
１６１ ネットワークコントロールサービス
２０１ コントローラ
２０２ オペレーションパネル
２０３ ファクシミリコントロールユニット
２１１ ＣＰＵ
２１２ ＡＳＩＣ
２２１ ＮＢ
２２２ ＳＢ
２３１ ＭＥＭ−Ｐ
２３２ ＭＥＭ−Ｃ
２３３ ＨＤＤ
２３４ メモリカードスロット
２３５ メモリカード
２４１ ＮＩＣ
２４２ ＵＳＢデバイス
２４３ ＩＥＥＥ１３９４デバイス
２４４ セントロニクスデバイス
５０１ ＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス
５０２ ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒ
５０３ Ｓｙｓｔｅｍクラス
５０４ ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍクラス
１４７１ ＪＳＤＫＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラス
１４７２ ＳｅｃｕｒｉｔｙＬｏｇクラス
１４７３ ＪＳＤＫＣｏｍｍｏｎクラス

Claims (13)

1. アプリケーションを追加可能であり、前記アプリケーションによる各リソースに対するアクセス権限が定義されたアクセス制御情報に基づいて前記リソースへのアクセスの許否を判定するアクセス制御手段を備えた情報処理装置であって、
   前記アクセス制御手段は、前記アクセス制御情報に対するアクセスの発生に応じ、当該アクセスに関する情報をログファイルに保存することを特徴とする情報処理装置。
2. 前記アクセス制御手段は、前記ログファイルに保存されている情報のハッシュ値を保存することを特徴とする請求項１記載の情報処理装置。
3. 前記アクセス制御手段は、前記ログファイルを暗号化することを特徴とする請求項１又は２記載の情報処理装置。
4. 前記アクセス制御手段は、前記アプリケーションによる前記アクセス制御情報の変更に応じ、変更された前記アクセス制御情報のハッシュ値を保存することを特徴とする請求項１乃至３いずれか一項記載の情報処理装置。
5. 前記各リソースは、前記アプリケーションからアクセスされたときに前記アクセス制御手段に当該アプリケーションによる当該リソースに対するアクセス権限を問い合わせ、
   前記アクセス制御手段は、前記リソースからの問い合わせに応じ、当該アクセスに関する情報をログファイルに保存し、当該アクセスの許否を前記アクセス制御情報に基づいて判定することを特徴とする請求項１乃至４いずれか一項記載の情報処理装置。
6. アプリケーションを追加可能であり、前記アプリケーションによる各リソースに対するアクセス権限が定義されたアクセス制御情報に基づいて前記リソースへのアクセスの許否を判定するアクセス手順を実行する情報処理装置によるアクセス制御方法であって、
   前記アクセス制御手段は、前記アクセス制御情報に対するアクセスの発生に応じ、当該アクセスに関する情報をログファイルに保存することを特徴とするアクセス制御方法。
7. 前記アクセス制御手順は、前記ログファイルに保存されている情報のハッシュ値を保存することを特徴とする請求項６記載のアクセス制御方法。
8. 前記アクセス制御手順は、前記ログファイルを暗号化することを特徴とする請求項６又は７記載のアクセス制御方法。
9. 前記アクセス制御手順は、前記アプリケーションによる前記アクセス制御情報の変更に応じ、変更された前記アクセス制御情報のハッシュ値を保存することを特徴とする請求項６乃至８いずれか一項記載のアクセス制御方法。
10. 前記各リソースは、前記アプリケーションからアクセスされたときに前記アクセス制御手順に当該アプリケーションによる当該リソースに対するアクセス権限を問い合わせ、
    前記アクセス制御手順は、前記リソースからの問い合わせに応じ、当該アクセスに関する情報をログファイルに保存し、当該アクセスの許否を前記アクセス制御情報に基づいて判定することを特徴とする請求項６乃至９いずれか一項記載のアクセス制御方法。
11. 請求項６乃至１０いずれか一項記載のアクセス制御方法をコンピュータに実行させるためのアクセス制御プログラム。
12. 請求項１１記載のアクセス制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
13. アプリケーションを追加可能であり、前記アプリケーションによる各リソースに対するアクセス権限が定義されたアクセス制御情報に基づいて前記リソースへのアクセスの許否を判定するアクセス制御手段を備えた画像形成装置であって、
    前記アクセス制御手段は、前記アクセス制御情報に対するアクセスの発生に応じ、当該アクセスに関する情報をログファイルに保存することを特徴とする画像形成装置。

Images