以下、図面に基づいて本発明の実施の形態を説明する。図1は、本発明の実施の形態における複合機のハードウェア構成例を示す図である。図1において複合機10は、コントローラ201、オペレーションパネル202、ファクシミリコントロールユニット(FCU)203、撮像部204、及び印刷部205等を備える。
コントローラ201は、CPU211、ASIC212、NB221、SB222、MEM−P231、MEM−C232、HDD(ハードディスクドライブ)233、メモリカードスロット234、NIC(ネットワークインタフェースコントローラ)241、USBデバイス242、IEEE1394デバイス243、セントロニクスデバイス244により構成される。
CPU211は、種々の情報処理用のICである。ASIC212は、種々の画像処理用のICである。NB221は、コントローラ201のノースブリッジである。SB222は、コントローラ201のサウスブリッジである。MEM−P231は、複合機10のシステムメモリである。MEM−C232は、複合機10のローカルメモリである。HDD233は、複合機10のストレージである。メモリカードスロット234は、メモリカード235をセットするためのスロットである。NIC241は、MACアドレスによるネットワーク通信用のコントローラである。USBデバイス242は、USB規格の接続端子を提供するためのデバイスである。IEEE1394デバイス243は、IEEE1394規格の接続端子を提供するためのデバイスである。セントロニクスデバイス244は、セントロニクス仕様の接続端子を提供するためのデバイスである。
オペレーションパネル202は、オペレータが複合機10に入力を行うためのハードウェア(操作部)であると共に、オペレータが複合機10から出力を得るためのハードウェア(表示部)である。
図2は、本発明の実施の形態における複合機のソフトウェア構成例を示す図である。図2において、複合機10のソウトウェアは、JSDKアプリ30、JSDKプラットフォーム40、及びネイティブサービスレイヤ50等より構成されている。これらの各ソフトウェアは、それぞれに実装された処理手順をCPU211に実行させることによりその機能を実現する。
ネイティブサービスレイヤ50は、複合機10のハードウェアやソフトウェアに基づく機能を利用させるためのインタフェースを上位モジュールに対して提供し、当該インタフェースの呼び出し(機能の利用要求)に応じて、当該機能を実現するための制御を行う。例えば、ネイティブサービスレイヤ50には、ネットワーク通信の制御に関するインタフェースを提供するモジュール、ファクシミリの制御に関するインタフェースを提供するモジュール、蓄積文書(HDD233に保存されている文書(画像)データ)の配信処理の制御に関するインタフェースを提供するモジュール、撮像部204や印刷部205の制御に関するインタフェースを提供するモジュール。メモリやHDD233等の制御に関するインタフェースを提供するモジュール、オペレーションパネル202の制御に関するインタフェースを提供するモジュール、認証処理や課金処理の制御に関するインタフェースを提供するモジュール、ユーザ情報の管理に関するインタフェースを提供するモジュール等が含まれる。
JSDKプラットフォーム40は、JSDKアプリ30の実行環境を提供するソフトウェアプラットフォームであり、ネイティブサービスレイヤ50に対するJava(登録商標)インタフェースを上位モジュールに対して提供する。JSDKプラットフォーム40は、Java(登録商標)の標準のクラスや、複合機10用に拡張されたクラスに関するクラスライブラリ、及びJava(登録商標)仮想マシン(VM41)等を含む。
VM41は、Java(登録商標)バイトコードを逐次解釈しながらJSDKアプリ30の実行を制御する。当該制御の一部として、VM41は、ポリシー設定ファイル(policy configuration file)70に予め定義されたポリシーに基づいて、JSDKアプリ30による、ファイル、ネットワークソケット、及びプリンタ等のリソースへのアクセスを制限する。すなわち、VM41は、Java(登録商標)標準の仕組みとして、リソースへのアクセスが発生する際に、SecurityManagerクラスのインスタンス(SecurityManagerオブジェクト)に対する通知が行われるように構成されている。SecurityManagerオブジェクトは、その呼び出しに応じてポリシー設定ファイル70に基づいてリソースへのアクセスの可否を判断する。
ところで、JSDKプラットフォーム40は、OSGi(Open Service Gateway initiative)プラットフォームとして実装されている。OSGi(Open Service Gateway initiative)プラットフォームとは、OSGiアライアンスによる標準化技術であり、Java(登録商標)言語に基づいたオープンなソフトウェア部品化技術に基づいて作成されたソフトウェア部品の実行環境を提供するソフトウェアプラットフォームである。OSGiプラットフォーム上において、Java(登録商標)言語のソフトウェアは「バンドル」と呼ばれるソフトウェア部品の形で実装される。一つのバンドルは、一つのJAR(Java ARchive)ファイルによって構成され、それぞれ独立して動的に(装置の再起動を要することなく)インストール可能である。
JSDKアプリ30は、JSDKプラットフォーム40において公開されている専用のSDK(ソフトウェア開発キット)を使用して作成されたアプリケーション(以下「SDKアプリ」という。)である。SDKアプリのうち、特にJava(登録商標)言語を使用して開発されたアプリケーションをJSDKアプリという。
図中では、JSDKアプリ30の例として、SAS(SDK Application Service)マネージャ31、アプリケーションバンドル320、及びサービスバンドル330等が存在する。SASマネージャ310は、他のJSDKアプリ30(アプリケーションバンドル320やサービスバンドル330等)のインストール(追加)、アンインストール(削除)、起動、及び起動解除等の制御を行う。
アプリケーションバンドル320は、オペレーションパネル202に操作画面を表示させ、当該操作画面を介してエンドユーザから直接利用(操作)されるJSDKアプリ30としてのバンドルである。図中では、アプリケーションバンドル320の一例としてスキャンアプリ321が示されている。スキャンアプリ321は、撮像部204による原稿からの画像の読み取りを実現するアプリケーションである。
サービスバンドル330は、アプリケーションバンドル320等に対してサービスを提供するためのJSDKアプリ30としてのバンドルである。すなわち、サービスバンドル330は、アプリケーションバンドル320等からの呼び出しに応じて各サービスバンドル330に応じた処理を実行し、その処理結果をアプリケーションバンドル320等に返却する。図中では、サービスバンドル330の一例として、スキャンサービス331、及びパネルサービス332等が示されている。
スキャンサービス331は、画像の読み取り機能に関するサービスを提供する。パネルサービス332は、オペレーションパネル202の表示制御に関するサービスを提供する。
次に、複合機10における、JSDKアプリ30に関するセキュリティの管理について説明する。上記したように、JSDKアプリ30は、JSDKプラットフォーム40において効果されているSDKを用いて開発されるJava(登録商標)アプリケーションである。したがって、複合機1の出荷後にサードベンダ等によって作成されるアプリケーション等もJSDKアプリ30として複合機1にインストールされうる。
そこで、複合機1では、複合機1のリソースに対するアクセス権限の範囲をレベル分け(グループに分類)し(当該レベルを以下「セキュリティレベル」という。)、JSDKアプリ30ごとに、その信頼度に応じたセキュリティレベルを付与することによりコードベースのアクセス制御を実現している。セキュリティレベルは、各JSDKアプリ30に付された署名(電子署名)によって識別可能とされている。
図3は、本実施の形態におけるJSDKアプリの構成例を示す図である。同図に示されるように、各JSDKアプリ30は、JARファイル31及びアプリケーション管理ファイル51等のファイルを含む。ここで、JARファイル31に付されている(関連付けられている)署名33が、セキュリティレベルを識別するための署名に相当する。署名33は、例えば、JARファイル31のハッシュ値を暗号化したものであり、当該暗号化に用いられた暗号鍵によってセキュリティレベルが識別される。署名33は、セキュリティレベルの識別の他、JSDKアプリ30の改ざんの有無のチェックにも用いられる。なお、本実施の形態において、セキュリティレベルは、レベル1(Lv1)、レベル2(Lv2)、及びレベル3(Lv3)の3段階の値を有することとする。Lv1が最もアクセス権限が大きく、Lv3が最もアクセス権限が小さい。
セキュリティレベルごとのアクセス権限については、Java(登録商標)標準の仕様に基づいてポリシー設定ファイル70において定義されている。
図4は、本実施の形態におけるポリシー設定ファイルの定義例を示す図である。同図においてポリシー設定ファイル70の書式は、Java(登録商標)標準の仕様に従っているため、書式に関する詳細な説明については省略する。
同図では、3つのgrantエントリが示されている。grantエントリ71のsinedByフィールドには、Lv1が指定されている。したがって、grantエントリ71の定義は、セキュリティレベルの値がLv1の署名33が付されたJSDKアプリ30に適用される。同様に、grantエントリ72はLv2の署名33が付されたJSDKアプリ30に、grantエントリ73はLv3の署名33が付されatJSDKアプリ30に適用される。
なお、grantエントリ71において、(a)では、実行時(Lv1のJSDKアプリ30の実行時)には(RuntimePermission)、全てのパッケージ(accessClassInPackage.*)にアクセス可能であることが設定されている。また、(b)では、全てのライブラリへの動的リンクが可能であることが設定されている。また、(c)では、ファイルシステム上の全てのファイルに対して、読み取り(read)及び書き込み(write)が可能であることが設定されている。
このように、ポリシー設定ファイル70内では、セキュリティレベルに対応させてアクセス権限が定義されている。したがって、複合機1では、各JSDKアプリ30に付与された署名33に対応するセキュリティレベルに応じて、当該JSDKアプリ30のアクセス権限が決定される。
ところで、各セキュリティレベル(Lv1、Lv2、Lv3)は、それぞれJava(登録商標)でいうところの保護ドメイン(ProtectionDomain)を形成する。 図5は、保護ドメインを説明するための図である。保護ドメインとは、ある主体(ここでは、JSDKアプリ30又はJSDKアプリ30に含まれるクラスのインスタンス)が現在直接にアクセスできるオブジェクトのセット(すなわち、アクセス権限の集合)であると考えることができる。同図では、a.class及びb.b.lassに対しては、保護ドメインXが適用され、c.class及びd.classに対しては保護ドメインYが適用される例が示されている。すなわち、a.class及びb.classには保護ドメインXに属する同じアクセス権限が与えられる。また、c.class及びd.classには保護ドメインYに属する同じアクセス権限が与えられる。なお、同図において、一つの「アクセス権限」は、ポリシー設定ファイル70における一つのPermissionエントリと考えればよい。また、一つの「保護ドメイン」は、一つのgrantエントリに対応するものと考えればよい。したがって、本実施の形態における複合機10では、Lv1に対応する保護ドメイン、Lv2に対応する保護ドメイン、及びLv3に対応する保護ドメインが形成される。
図3に戻る、アプリケーション管理ファイル51は、当該JSDKアプリ30の構成要素やインストール、起動等に必要な情報、及びその他の管理情報等が定義されているファイルであり、例えば、ファイル名によってJarファイル31に関連付けられている。本実施の形態において、アプリケーション管理ファイル51は、セキュリティパッチ523を含む。セキュリティパッチ523は、ポリシー設定ファイル70内において、静的に設定されているポリシーの定義に対するパッチ(変更情報又は差分情報)である。複合機10は、JSDKアプリ30の実行に際し、当該JSDKアプリ30に関連付けられているセキュリティパッチ523を適用することにより、ポリシー設定ファイル70の定義を動的に変更させる(以下、斯かる機能を「ポリシー動的変更機能」という。)。
図6は、セキュリティパッチの書式の例を示す図である。同図に示されるように、セキュリティパッチ523の書式は、基本的にJava(登録商標)標準のポリシーの書式に従う。但し、本実施の形態では、破線で囲まれた部分が拡張されている。すなわち、grantエントリ及びpermissionエントリに対して、CalledByフィールド及びStateフィールドの付加が可能とされている。
CalledByフィールドでは、当該CalledByフィールドが付与されたエントリ(grantエントリ又はpermissionエントリ)が有効となるタイミングが指定される。当該タイミングは、メソッドの呼び出しによって特定される。CalledByフィールドは、「CalledBy "from_class_name.to_class_name"」の書式で記述される。from_class_nameは、<呼び出し元のクラス名>:<メソッド名>の書式で記述され、to_class_nameは、<呼び出し先のクラス名>:<メソッド名>の書式で記述される。但し、メソッド名及び呼び出し元のクラス名は省略可能である。
「from_class_name.to_class_name」の書式例と、その意味を以下に示す。
(1)"Password:getPassWord"
この場合、PasswordクラスのgetPassWordメソッドが呼び出されたときに当該エントリが有効とされる(ポリシーが変更される)。
(2)"Apli1:dispPassWord.Password:getPassWord"
この場合、Apli1クラスのdispPassWordメソッドからPasswordクラスのgetPassWordメソッドが呼び出されたときに当該エントリが有効とされる。
(3)"Password"
この場合、Passwordクラスの全てのメソッドを実行されたときにポリシー変更を行う。
例えば、図7は、CalledByフィールドの記述例を示す図である。同図において、(A)及び(B)は、実質的に同じことが定義されている。すなわち、CalledByフィールド(図中破線で囲まれた部分)によって、PasswordクラスのgetPassWordが呼び出されたときに、パスワードファイル(Password.txt)の読み込み権限が与えられることが定義されている。但し、(A)では、CalledByフィールドはgrantエントリに付与されているため、当該grantエントリに他のpermissionエントリが含まれている場合は、それらにもCalledByフィールドの効力が及ぶ。
また、Stateフィールドは、当該Stateフィールドが付与されたエントリが有効となる複合機10の状態が指定される。Stateフィールドは、「State "State_name」の書式で記述される。State_nameには、状態を特定する文字列又は数値が記載される。
例えば、状態を識別するためのパラメータが固定的に決められている場合は、以下のように記述することができる。
図8は、Stateフィールドの第一の記述例を示す図である。同図において、(A)及び(B)は、実質的に同じことが定義されている。すなわち、Stateフィールド(図中破線で囲まれた部分)によって、予め決められているパラメータの値が「1」である場合は、パスワードファイル(Password.txt)の読み込み権限が与えられることが定義されている。但し、(A)では、Stateフィールドはgrantエントリに付与されているため、当該grantエントリに他のpermissionエントリが含まれている場合は、それらにもStateフィールドの効力が及ぶ。
また、状態を識別するためのパラメータをStateフィールドの記述において特定したい場合は、以下のように記述してもよい。
図9は、Stateフィールドの第二の記述例を示す図である。同図において、Stateフィールドは、「State Counter.A==0」と記述されている。これは、Countter.Aというパラメータが0である状態を特定している。すなわち、同図の(A)及び(B)では、Countter.Aというパラメータが0である場合は、パスワードファイル(Password.txt)の読み込み権限が与えられることが定義されている。
なお、本実施の形態では、CalledByフィールドとStateフィールドとが同一のエントリに対して定義された場合、二つのフィールドのAND条件によって当該エントリの有効性が判定されることとする。但し、OR条件によって判定するようにしてもよい。
以下、複合機10によって実行される処理手順について説明する。図10は、JSDKアプリ実行時の処理手順を説明するための図である。
ユーザ(例えば、管理者)によって、起動可能なJSDKアプリ30(以下、単に「アプリ」という。)の一覧の表示要求がオペレーションパネル202を介して入力されると(S101)、SASマネージャ310は、複合機10にインストールされ、起動可能な状態にある各アプリに関連付けられているアプリケーション管理ファイル51を読み込み(S102)、その定義情報に基づいてアプリ一覧画面をオペレーションパネル202に表示させる(S103)。
図11は、アプリケーション管理ファイルの定義例を示す図である。図11に示される定義例は、XML(eXtensible Markup Language)形式をベースとしたJNLP(Java Network Launching Protocol(JSR−56仕様))を拡張した形式によって表現されている。
同図において、アプリケーション管理ファイル51の定義情報は、<information>タグで囲まれたinformation要素510、及び<rsource>タグで囲まれたresource要素520等を含む。
information要素510には、主に、アプリ及び当該アプリの作成者を識別するための情報が記述されている。すなわち、title要素511には、アプリのタイトル(アプリ名)が記述されている。vendor要素512、telephone要素513、fax要素514、email要素515には、アプリのベンダの名前(ベンダ名)、電話番号、FAX番号、メールアドレスが記述されている。また、product−id要素516、description要素517、icon要素518には、アプリのプロダクトID、アプリに関する説明文、アプリのアイコンファイル名が記述されている。
一方、resource要素520には、アプリの実行に必要なリソースに関する情報が記述されている。例えば、jar要素のhref属性521の値として、アプリのJARファイルのファイル名(パス名)が記述されている。また、version属性522の値として、アプリのバージョンが記述されている。
更に、security.patch要素の値としてセキュリティパッチ523が記述されている。また、security.patch要素のcomment属性524の値として、セキュリティパッチ523に関するコメントが記述されている。なお、セキュリティパッチ523の定義内容の詳細については後述する。
ステップS103では、上記のようなアプリケーション管理ファイル51のtitle要素511及びicon要素518に基づいて起動可能な各アプリのアプリ名及びアイコンの一覧がアプリ一覧画面に表示される。
続いて、アプリ一覧画面に表示されたアプリの中から起動対象とされるアプリがユーザによって選択されると(S104)、SASマネージャ310は、選択されたアプリ(以下、「カレントアプリ」という。)に関連付けられているアプリケーション管理ファイル51等に基づいてカレントアプリのアプリ設定画面を生成し、オペレーションパネル202に表示させる(S105)。
図12は、アプリ設定画面の表示例を示す図である。同図のアプリ設定画面610において、アプリ名、説明、バージョン、プロダクトID、及び連絡先(電話、Fax、email)の項目については、アプリケーション管理ファイル51に記述されていた情報がそのまま表示される。
セキュリティ項目611及びパフォーマンス項目613には、セキュリティレベル及びセキュリティパッチ523に関係又は影響する情報(すなわち、カレントアプリのアクセス権限に関する情報)が表示される。同図において、セキュリティ項目611には、カレントアプリのセキュリティレベル(レベル3)が表示され、また、パスワードファイルの参照の可否を選択させるチェックボタン612が「パスワードファイルを参照」というメッセージと共に表示されている。すなわち、カレントアプリはパスワードファイルを参照する必要があるところ、その許否はチェックボタン612によってユーザの判断で選択可能とされている。なお、カレントアプリがレベル3であることは、SASマネージャ310がカレントアプリの署名33に基づいて判別する。また、「パスワードファイルを参照」という文字列は、アプリケーション管理ファイル51のcomment属性524に基づいて表示される。また、パスワードファイルは、複合機10のユーザのアカウント情報が記録されたファイルであり、ポリシー設定ファイル70においてはレベル3のアプリには読み込み権限は与えられていないリソースの例示である。
また、パフォーマンス項目613では、ラジオボタン614により、カレントアプリの動作について、セキュリティ優先、最適、及びパフォーマンス優先のいずれかを選択することができる。この選択は、ポリシー設定ファイル70に定義されているポリシーをカレントアプリにどれだけ忠実に遵守させるかの選択に相当する。セキュリティ優先→最適→パフォーマンス優先の順で、ポリシーに対する忠実度は低下する。但し、そのトレードオフとして性能は向上する。
ユーザによってセキュリティ項目611及びパフォーマンス項目613に対する設定が行われ、OKボタン615がクリックされると(S106)、SASマネージャ310は、設定内容を複合機10のメモリ又はHDD233上に保持される所定のパラメータに記録する(S107)。より詳しくは、チェックボタン612に対する設定については、パスワードファイルフラグ変数(passwdFlag)の値とし記録される。例えば、チェックボタン612がチェックされなかった場合(パスワードファイルの参照が許可されない場合)は「0」が、チェックボタン612がチェックされた場合(パスワードファイルの参照が許可される場合)は「1」が、パスワードファイルフラグ変数に記録される。また、ラジオボタン614に対する設定については、パフォーマンスフラグ変数(performanceFlag)の値として記録される。例えば、セキュリティ優先の場合は「1」が、最適の場合は「2」が、パフォーマンス優先の場合は「3」がパフォーマンスフラグ変数に記録される。続いて、SASマネージャ310からの要求に応じ、JSDKプラットフォーム40のVM41は、カレントアプリを起動させる(S108)。
続いて、ステップS108の内容を詳細に説明する。図13は、JSDKアプリの起動処理を説明するための図である。
ステップS1081において、VM41は、カレントアプリのJARファイル31をメモリ上に読み込む。この際、JARファイル31に対する署名33の検証も行われる。すなわち、正当な署名33であること及びJARファイル31が改ざんされていないこと等が検証される。したがって、署名33が無い場合若しくは不正なものである場合、又はJARファイル31が改ざんされていることが検出された場合は、当該JSDKアプリ30の起動は中止される。
続いて、VM41は、ポリシー設定ファイル70よりカレントアプリのセキュリティレベルに対応するポリシー(例えば、Lv3に対応するgrantエントリ)をオブジェクトとしてロードする(S1082)。
図14は、オブジェクトとしてロードされたポリシーの例を示す図である。同図において、ProtectionDomain411は、上記した保護ドメインに対応するProtectionDomainクラスのインスタンスである。ProtectionDomain411は、ポリシー設定ファイル70において、カレントアプリのセキュリティレベルに対応するgrantエントリごとにインスタンス化される。
PermissionCollection412は、その名の通り、Permissionオブジェクトの集合を管理するPermissionCollectionクラスのインスタンスである。Permissionオブジェクトは、ポリシー設定ファイル70におけるpermissionエントリごとに当該エントリによって許可されるアクセス権限に応じた具象クラスに基づいてインスタンス化される。図中では、RuntimePermissionオブジェクト及びFilePermissionオブジェクトが例示されている。
同図に示されるように、ProtectionDomain411とPermissionCollection412との間にはポリシー設定ファイル70における関係に対応した関連が形成される。
続いて、VM41は、カレントアプリのJARファイル33に含まれるクラス定義をメモリ上に展開し(S1083)、当該クラス定義に基づいてカレントアプリをインスタンス化する(S1084)。続いて、VM41は、インスタンス化されたカレントアプリを実行する(S1085)。
続いて、図10及び図13の処理を経て実行されるアプリについて、セキュリティパッチ523が適用されてポリシーが動的に変更される際の処理手順について説明する。
ここで、改めて図11のアプリケーション管理ファイル51に含まれているセキュリティパッチ523を参照する。当該セキュリティパッチ523には、3つのpermissionエントリが含まれている。
permissionエントリ5231の定義は、「permission java.io.FilePermission "Password.txt", "read" ,CalledBy "Password:getPassWord", State passwdFlag==1」というものである。これは、パスワードファイル(Password.txt)の読み込み権限を許可する定義に相当する。但し、CalledByフィールド及びStateフィールドによって当該読み込み権限が許可されるのは、Password:getPassWordメソッドが呼び出されたときであって、かつ、パスワードフラグ(passwdFlag)の値が1である場合(すなわち、アプリ設定画面610のチェックボタン612がチェックされた場合)であるとされている。
permissionエントリ5232の定義は、「permission java.security.AllPermission State performanceFlag==2 , CalledBy "Apli1:init"」というものである。これは、全権限(AllPermission)を許可する定義に相当する。但し、CalledByフィールド及びStateフィールドによって、全権限が許可されるのは、Apli1:initメソッドが呼び出された際であって、かつ、パフォーマンスフラグ(performanceFlag)の値が2である場合(すなわち、アプリ設定画面610のラジオボタン613において「最適」が選択された場合)であるとされている。
permissionエントリ5233の定義は、「permission java.security.AllPermission State performanceFlag==3 , CalledBy " Apli1:dispPassWord"」というものである。これは、全権限(AllPermission)を許可する定義に相当する。但し、CalledByフィールド及びStateフィールドによって全権限が許可されるのは、Apli1:dispPassWordメソッドが呼び出されたときであって、かつ、パフォーマンスフラグ(performanceFlag)の値が2である場合(すなわち、アプリ設定画面610のラジオボタン613において「パフォーマンス優先」が選択された場合)であるとされている。
このように、セキュリティパッチ523には、パスワードフラグ及びパフォーマンスフラグといった、アプリ設定画面610において設定されるパラメータに対応させて定義がなされている。したがって、SASマネージャ310は、アプリ設定画面610の表示内容を、セキュリティパッチ523の記述に基づいて決定するようにしてもよい。
斯かるセキュリティパッチ523によるポリシーの動的な変更は、ProtectionDomain411の状態遷移として把握することができる。図15は、ポリシーの動的な変更をProtectionDomainの状態遷移として示す図である。同図では、アプリ32に対するProtectionDomain411とPermissionCollection412とが示されている。アプリ32は、カレントアプリのインスタンスを示す。
同図において、ProtectionDomain411は、状態PD_Lv3、状態PD_Lv3+、状態PD_Optimaize、及び状態PD_Performanceの4つの状態を有する。
状態PD_Lv3はポリシーがセキュリティパッチ523によって動的に変更される前の状態である。この場合、通常のLv3に対するアクセス権限が与えられる。
状態PD_Lv3+は、Lv3のアクセス権限に加えてパスワードファイル(Password.txt)の読み込み権限が与えられる状態である。この状態への遷移条件は、セキュリティパッチ523(図11)のpermissionエントリ5231に基づいて、Password.getPasswordメソッドが実行中であることである。但し、permissionエントリ5231におけるStateエントリによってパスワードファイルフラグが1であることがガード条件となる。
状態PD_Optimaizeは、全アクセス権限が与えられる状態である。この状態への遷移条件は、permissionエントリ5232に基づいて、パフォーマンスフラグ(peformanceFlag)が「2」に設定されている状態において、Apli1:initメソッドが実行中であることである。
状態PD_Performanceも全アクセス権限が与えられる状態である。この状態への遷移条件は、permissionエントリ5233に基づいて、パフォーマンスフラグ(peformanceFlag)が「3」に設定されている状態において、Apli1:dispPassWordが実行中であることである。
以下、更に具体的に説明する。図16は、ポリシーが動的に変更される際の処理手順を説明するためのシーケンス図である。同図では、アプリ32が、パスワードファイルの参照を要求した場合の処理手順について説明する。
同図において、「apli1:Apli1」は、カレントアプリ32のクラス名(Apli1)及びインスタンの識別名(apli1)を示す。カレントアプリ32は、Lv3の保護ドメインに対するアクセス権限を有する(すなわち、Lv3のセキュリティレベルが与えられている)。また、Password411及びPassWordAccess412は、本実施の形態においてJSDKプラットフォーム40に実装されている、パスワードファイル(Password.txt)にアクセスするためのPasswordクラス、PassWordAccessクラスのインスタンスである。PasswordクラスはLv2の保護ドメインに対するアクセス権限を有する。PassWordAccessクラスはLv1の保護ドメインに対するアクセス権限を有する。また、sm:SecurityManager413は、Java(登録商標)標準のSecurityManagerクラスを本実施の形態のために拡張したクラスのインスタンスである。
なお、図示される通り、ポリシー設定ファイル70の定義において、パスワードファイルに対するアクセス権限としては、Lv1に対しては読み込み及び書き込み権限が、Lv2に対しては読み込み権限が許可されている。一方、Lv3については読み込み及び書き込み権限のいずれも許可されていない。
例えば、カレントアプリ32のdispPassWordメソッドが呼び出されると、
1)当該メソッド内から複合機10内の記憶装置に記録されているパスワード情報を取得するため、カレントアプリ32は、Password421のgetPassWordメソッドを呼び出す(S201)。続いて、Password421のgetPassWordメソッド内において、PasswordAccess422のreadメソッド(パスワードファイルの参照要求)が呼び出される(S202)。PasswordAccess422は、パスワードファイルに対して直接アクセスするクラスであるため、readメソッドの中でsm:SecurityManager413のcheckPermissionメソッドを呼び出すことにより、パスワードファイルに対する読み込み権限の有無を問い合わせる(S203)。
続いて、sm:SeccurityManager413は、カレントアプリ32に対応するProtectionDomain411をカレントアプリ32より取得する(S204)。なお、sm:SeccurityManager413は、スタック情報をトレースすることにより、パスワードファイルにアクセスしようとするカレントアプリ32(のクラス名)を判別することができる。
続いて、sm:SeccurityManager413は、スタック情報をトレースし、ProtectionDomain411に対して、Apli1:dispPasswordメソッドやPassword:getPasswordメソッドが呼び出されたことを通知する(S205)。当該通知に応じて、ProtectionDomain411は、カレントアプリ32のセキュリティパッチ523(図11参照)に基づいて状態の遷移の要否を判定する。
ここで、セキュリティパッチ523のpermissionエントリ5231には、CalledByフィールド(「CalledBy "Password:getPassWord"」)が付与されており、ステップS205における通知は、当該CalledByフィールドの条件に当てはまる。したがって、ProtectionDomain411は、パスワードファイルフラグ(passwdflag)の値が「1」であれば、自らの状態をPD_Lv3から状態PD_Lv3+へ遷移させ、permissionエントリ5231を有効とする。当該状態の遷移は、具体的には、permissionエントリ5231に対応するFilePermissionオブジェクトをPermissionCollection412に追加することが相当する(S206)。
但し、現在は、Apli1:dispPassWordメソッドの実行中でもある。したがって、パフォーマンスフラグ(performanceFlag)の値が「3」である場合は、ProtectionDomain411は、状態PD_Optimaizeへ遷移し、permissionエントリ5233を有効とする。この場合、AllPermissionオブジェクトがPermissionCollection412に追加される。
なお、仮に、現在実行中のメソッド(例えば、ステップS201で呼び出されたメソッド)が「Apli1:init」であり、パフォーマンスフラグ(performanceFlag)の値が「2」である場合、ProtectionDomain411は、状態PD_Optimaizeへ遷移し、permissionエントリ5232を有効とする。この場合、AllPermissionオブジェクトがPermissionCollection412に追加される。
続いて、sm:SeccurityManager413は、ProtectionDomain411よりPermissionCollection412を取得する(S207)。続いて、sm:SeccurityManager413は、PermissionCollection412に対して、パスワードファイルに対する読み込み権限の有無を問い合わせる(S208)。PermissionCollection412は、パスワードファイルに対する読み込み権限に対応するPermissioinオブジェクトが自らに含まれているか否かを確認することにより、当該読み込み権限の有無を判定する。ここでは、ステップS206において当該Permissionオブジェクトが追加されている。したがって、当該読み込み権限は有ることを判定結果として応答する(S209)。
続いて、sm:SeccurityManager413は、ProtectionDomain411に対して「Password:getPassword」から退出することを通知する(S210)。当該通知に応じ、ProtectionDomain411は、自らの状態を元(PD_Lv)に戻す(遷移させる)。厳密には、このタイミングでは、「Password:getPassword」から退出していないが、本実施の形態では、ProtectionDomain411に対するイベントはm:SeccurityManager413が発行することとしているため、このタイミングで退出が通知される。
続いて、sm:SeccurityManager413は、アクセス権限(読み込み権限)が有ることをPasswordAccess422に通知する(S211)。当該通知に応じ、パスワードファイルが読み込まれる。なお、S209においてアクセスが許可されない旨が返却された場合、sm:SeccurityManager413は、例外を発行する。当該例外は、カレントアプリ32に通知される。
なお、上記では、ProtectionDomain411に対するイベントは、sm:SeccurityManager413が発行する例を示しているが、斯かるイベントは、カレントアプリ32によって発行されてもよい。
上述したように、本実施の形態における複合機10によれば、ポリシー設定ファイル70において静的に定義されているポリシーをセキュリティパッチ523に基づいて動的に変化させることができる。したがって、プログラムによるアクセス制御の柔軟性を適切に向上させることができる。
なお、本実施の形態では、CalledByフィールドやStateフィールドによって、当該フィールドが付加されたエントリが有効となる(すなわち、当該エントリに係る権限が与えられる)例について説明した。しかし、CalledByフィールドやStateフィールドによって当該フィールドが付加されたエントリを無効とする(すなわち、当該エントリに係る権限が剥奪される)ようにしてもよい。この場合、特定の場合に限って、当初与えられていた権限よりも狭い権限しか認められないようにすることができる。
ところで、上記において説明したJSDKアプリ30に対するセキュリティ機能又は機構は、JSDKアプリ30の開発から運用までの手順が適切に履行されることにより、より効果的に機能する。そこで、以下において、JSDKアプリ30の開発から運用までの手順(ビジネスモデル)の一例について説明する。
図17は、JSDKアプリの開発から運用までの手順の一例を説明するための図である。
まず、複合機ベンダ(複合機10のメーカ又は複合機10の販売及び保守等を行う業者)によってJSDKプラットフォーム40と基本機能を実現するためのJSDKアプリ30とを含むパッケージ(以下、「JSDKパッケージ」という。)が販売される(S501)。なお、JSDKパッケージに含まれるJSDKアプリ30等には、予め複合機ベンダによって署名33が付される。JSDKパッケージに含まれるJSDKアプリ30は、複合機ベンダ自身によって開発されたものであり、信頼度も高いためLv1又はLv2のセキュリティレベルが付与される。
複合機10のユーザは、JSDKパッケージを購入し(S502)、自らの複合機10に対してJSDKプラットフォーム40等のインストール(S503)を行い、必要に応じてJSDKプラットフォーム40及びJSDKアプリ30等を起動させる(利用する)(S504)。
一方、機能拡張のためのJSDKアプリ30を開発するアプリ開発ベンダは、開発用のプラットフォームとしてJSDKプラットフォーム30を入手(購入)し、当該JSDKプラットフォーム30上において新たなJSDKアプリ30を開発する(S505)。続いて、アプリ開発ベンダは、アプリ開発申請書を作成し(S506)、開発したJSDKアプリ30のJARファイルと共にアプリ開発申請書を複合機ベンダに送付することにより、当該JSDKアプリ30の販売に対する承認の申請を行う(S507)。
図18は、アプリ開発申請書の一例を示す図である。同図において、アプリ開発申請書は、サービスバンドル、セキュリティレベル、セキュリティパッチ、セキュリティパッチ理由、及びパフォーマンス等の項目を有する。
サービスバンドルは、申請対象のJSDKアプリ30(以下、「申請対象アプリ」という。)が利用するサービスバンドル330の名前が記載される。セキュリティレベルには、申請対象アプリに対して要求するセキュリティレベルが記載される。セキュリティパッチには、必要に応じて、図6において説明した書式に従ってセキュリティパッチ524が記載される。セキュリティパッチ理由は、セキュリティパッチ524が必要な理由が記載される。パフォーマンスには、申請対象アプリのパフォーマンスと安全性とのトレードオフを申請する。具体的にはパフォーマンスと安全性との関係を段階分けして、その段階ごとに、セキュリティチェック(アクセス権限のチェック)を無効とするメソッドが記載される。同図では、a)安全優先、b)最適、c)パフォーマンス優先の3段階に分けられて記載されている。
複合機ベンダは、承認の申請を受け付けると(S508)、申請対象アプリの評価(テスト)を行う(S509)。当該評価では、申請対象アプリによるリソースの消費量が制限内であるか、また、セキュリティ違反がないか(セキュリティパッチの妥当性等)等が検証される。評価に合格すると、複合機ベンダは申請アプリについて配布用パッケージを作成する(S510)。配布用パッケージは、申請対象アプリのJARファイルの他にアプリケーション管理ファイル51等も含まれる。また、当該JARファイルには申請されたセキュリティレベルに応じた署名33が付与される。なお、署名33及びアプリケーション管理ファイル51はアプリ開発申請書に基づいて複合機ベンダによって作成される。続いて、複合機ベンダは、配布用パッケージをアプリ開発ベンダに提供する(S511)
アプリ開発ベンダは、配布用パッケージを受理し(S512)、当該配布用パッケージをユーザに販売する(S513)。ユーザは、配布用パッケージを購入すると(S514)、当該配布用パッケージに含まれているJSDKアプリ30を複合機10にインストールし(S515)、起動(S516)、及び操作(S517)を行う。
以上のような手順によれば、アプリ開発ベンダによって開発されるJSDKアプリ30は、複合機ベンダの管理下においてセキュリティレベルが付与され、またセキュリティパッチ524の適用が許可される。したがって、不正なアプリケーションの実行をより効果的に防止することができる。
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。