JP5014191B2

JP5014191B2 - 機器及び操作権限判定方法

Info

Publication number: JP5014191B2
Application number: JP2008031817A
Authority: JP
Inventors: 和明木戸口
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2008-02-13
Filing date: 2008-02-13
Publication date: 2012-08-29
Anticipated expiration: 2028-02-13
Also published as: JP2009193225A

Description

本発明は、機器及び操作権限判定方法に関し、特にプログラムの操作権限を判定する機器及び操作権限判定方法に関する。

従来、電子的な資源に対するアクセス制御の手段として、ユーザごとに紐付けられた電子的なチケットを利用する技術がある。認証されたユーザに対して仮想空間内においてチケットを発行し、当該チケットに基づいてユーザによる各機能（アプリケーション）の利用の可否を判断するというものである（例えば、特許文献１）。斯かる技術によれば、複数のアプリケーションの連携によって実現されるサービスを受ける場合であっても、ユーザは、一度認証情報を入力すれば認められている権限の範囲内で当該サービスを利用することができる。すなわち、一度入力された認証情報に基づいて発行されたチケットをアプリケーション間で流通させることにより、各アプリケーションは、ユーザの権限を確認することができるからである。

他方において、近年では、プリンタ、複写機、又は複合機等の画像形成装置においても、その出荷後にサードベンダ等によって開発されたアプリケーションの追加（インストール）が可能とされているものがある。この場合、アプリケーションの開発者に対する信頼度等に応じてアプリケーションごとに権限の制御を行うことがセキュリティ上の観点より好ましい。画像形成装置内には、スキャンされた機密文書の電子データや、ユーザのアドレス帳情報等、各種の機密情報又は個人情報が格納されており、全てのアプリケーションが斯かる情報に無条件にアクセスできるのは情報の漏洩の虞を招くからである。
特開２００５−１１３２２号公報

しかしながら、従来におけるユーザに紐付けられたチケットの仕組みをそのままプログラムに適用した場合、プログラムごとに権限を定義しなければならず、煩雑な作業が必要とされる。また、各プログラムは、その実行時にそれぞれのプログラムに紐付けられているチケットを取得しなければならず、複数のプログラムが連携して動作する通常のシステムにおいてもメモリリソース面、パフォーマンス面において負荷が増加してしまうという問題がある。

本発明は、上記の点に鑑みてなされたものであって、プログラムごとの権限制御を適切に実現することのできる機器及び操作権限判定方法の提供を目的とする。

そこで上記課題を解決するため、本発明は、プログラムを追加可能な機器であって、プログラムごとに当該プログラムを識別するための電子チケットを発行する電子チケット発行手段と、前記電子チケットに基づいて前記プログラムが要求する操作に対する権限の有無を、記憶手段に記録されたポリシー情報に基づいて判定する権限判定手段とを有し、前記ポリシー情報は、プログラムごとに、当該プログラムに対して発行された前記電子チケットを利用可能なプログラムを識別する情報を含み、前記権限判定手段は、前記操作の要求元のプログラムが、前記電子チケットを発行されたプログラムに対する前記ポリシー情報において当該電子チケットを利用可能とされていないときは前記操作の権限は無いと判定することを特徴とする。

このような機器では、プログラムごとの権限制御を適切に実現することができる。

本発明によれば、プログラムごとの権限制御を適切に実現することのできる機器及び操作権限判定方法を提供することができる。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるシステム構成例を示す図である。同図において、一台以上の機器１０とポリシーサーバ２０とは、ＬＡＮ（Local Area Network）又はインターネット等のネットワーク３０（有線又は無線の別は問わない。）を介して接続されている。

機器１０は、コピー機能、印刷機能、スキャナ機能、及びＦＡＸ機能等、複数の画像形成機能を一台の筐体において実現する画像形成装置（複合機）である。但し、本発明の適用対象は、単体の機能を実現する画像形成装置（例えば、複写機、プリンタ、スキャナ、又はＦＡＸ等）であってもよいし、画像形成装置以外の機器であってもよい。少なくとも、プログラムによる処理制御が可能な機器であればよい。

ポリシーサーバ２０は、機器１０において動作する各種ソフトウェア部品（プログラム）について、機器１０の電子的又は物理的な資源に対するアクセス権限（操作権限）に関する定義情報（以下、「ポリシー情報」という。）を管理するコンピュータである。複数の機器１０に対するポリシー情報を一台のポリシーサーバ２０において一元管理することにより、ポリシー情報の保守作業の効率化、各機器１０間におけるアクセス制御の整合性の確保等を適切に図ることができる。

図２は、本発明の実施の形態における機器のハードウェア構成例を示す図である。同図において、機器１０は、それぞれバスBで相互に接続されている、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、補助記憶装置１０４、ＬＡＮコントローラ１０５、ファクシミリ装置１０６、画像読み取り装置１０７、印刷装置１０８、及び操作パネル１０９等より構成される。

ＲＯＭ１０２や補助記憶装置１０４には、各種のプログラムやプログラムによって利用されるデータ等が記録されている。ＲＡＭ１０３は、プログラムをロードするための記憶領域や、ロードされたプログラムのワーク領域等として用いられる。ＣＰＵ１０１は、ＲＡＭ１０３にロードされたプログラムを処理することにより、後述される機能を実現する。

ＬＡＮコントローラ１０５は、ネットワーク３０を介した通信を実現する。ファクシミリ装置１０６は、ファクスの送受信を実現する。画像読み取り装置１０７は、紙文書より画像データを読み取る。印刷装置１０８は、画像読み取り装置１０７によって読み取られた画像データやネットワーク３０を介して受信される画像データ等を印刷用紙に印刷する。操作パネル１０９は、ユーザからの入力の受け付けや、ユーザに対する情報の通知等を行うめのボタン、液晶パネル等を備えたハードウェアである。

図３は、本発明の実施の形態における機器の機能構成例を示す図である。同図において、機器１０は、Ａアプリ１１ａ、Ｂアプリ１１ｂ、及びＣアプリ１１ｃ等、各種のアプアプリケーション（以下、総称する場合、「アプリ１１」という。）と、各アプリ１１より共通に利用される、データ管理部１２、チケット制御部１３、アクセス制御部１４、ポリシー制御部１５、インストール制御部１６、及び履歴情報１７等とを有する。これら各アプリ１１及び各部は、プログラムがＣＰＵ１０１に実行させる処理によりその機能を実現する。

データ管理部１２は、機器１０の各種の設定情報を管理する。設定情報は、例えば、補助記憶装置１０４に記録されている。本実施の形態では、当該設定情報がアプリ１１による操作対象とされる。アプリ１１が、データ管理部１２に管理される設定情報を操作するためには、「チケット」と呼ばれる電子データ（電子チケット）の提示が必要とされる。チケットは、操作要求元を識別すると共に、操作要求元の設定情報に対する操作権限を識別するために用いられる。

チケット制御部１３は、アプリ１１に対してチケットを発行すると共に、チケットの正当性を検証する。アクセス制御部１４は、チケットに基づく操作権限の有無（操作の許否）を判定する。実際には、アクセス制御部１４は、操作の許否判定の実質的な判定をポリシー管理部１５に委譲する。ポリシー管理部１５は、ポリシーサーバ２０に管理されているポリシー情報２１等に基づいて、アクセス制御部１４より委譲された操作の許否判定を実行する。

インストール制御部１６は、アプリ１１のインストール処理を制御する。すなわち、機器１０において、アプリ１１は任意にインストール（追加）可能である。履歴情報１７は、チケットに基づいて行われる操作履歴に関する情報であり、例えば、チケットごとに補助記憶装置１０４に記録される。

なお、ポリシー情報２１は、ポリシーサーバ２０の記憶装置に保存されている。

以下、機器１０の処理手順について説明する。図４は、アプリによる設定情報の操作時の処理手順を説明するためのシーケンス図である。

例えば、操作パネル１０９を介した入力に応じて、設定情報の変更（書き込み）を指示されたＡアプリ１１ａは、チケット制御部１３に対してチケットの発行を要求する（Ｓ１０１）。チケット制御部１３は、Ａアプリ１１ａに対するチケットを生成すると共に当該チケットの生成に関する履歴を履歴情報１７に記録し、生成されたチケットをＡアプリ１１ａに返却する（Ｓ１０２）。

図５は、チケットの構成例を示す図である。同図に示されるように、一つのチケットは、チケットＩＤ５１１、チケット発行先５１２、履歴情報ＩＤ５１３、及び署名情報５１４等を含む。

チケットＩＤ５１１は、チケットの生成時において各チケットに対して一意となるように割り当てられるＩＤである。チケット発行先は、当該チケット５１０の発行を直接受けたアプリ１１の識別名（ここでは、Ａアプリ１１ａのアプリ名）である。履歴情報ＩＤ５１３は、当該チケット５１０に対する履歴情報１７のＩＤ（識別子）である。署名情報５１４は、チケット５１０の改竄を検知するための電子署名であり、例えば、チケットＩＤ５１１、チケット発行元５１２、及び履歴情報ＩＤ５１３を含む情報のハッシュ値である。

また、図６は、一つのチケットに対する履歴情報の構成例を示す図である。同図に示される履歴情報１７ａは、図５に示されるチケット５１０に対応する履歴情報１７の例である。履歴情報１７ａは、履歴情報ＩＤ１７１、対応チケットＩＤ１７２、履歴項目１７３、及び署名情報１７４等を含む。

履歴情報ＩＤ１７１は、チケットごとに生成される各履歴情報１７に一意に割り当てられるＩＤであり、チケット５１０における履歴情報ＩＤ５１３に対応する。対応チケットＩＤ１７２は、当該履歴情報１７が対応するチケットのチケットＩＤである。したがって、チケット５１０と履歴情報１７１とは、履歴情報ＩＤ及びチケットＩＤによって双方向に関連付けられている。履歴項目１７３は、対応するチケットに関する履歴である。例えば、ステップＳ１０２では、１行目（「Ａアプリへ新規発行」）が履歴項目１７３として記録される。署名情報１７４は、履歴情報１７の改竄を検知するための電子署名であり、例えば、履歴情報ＩＤ１７１、対応チケットＩＤ１７２、及び履歴項目１７３を含む情報のハッシュ値である。したがって、署名情報１７４は、履歴項目１７３の更新に応じて更新される。

なお、ステップＳ１０１において、チケットの発行要求と共に、要求元のアプリ名を指定させるようにしてもよい。チケット制御部１３は、指定されたアプリ名に基づいてチケットの発行要求元を識別することができる。また、アプリ名のみならず、当該発行元を証明するための署名情報（例えば、Ａアプリ１１ａの実行コードのハッシュ値等）を指定するようにしてもよい。又は、発行要求元にアプリ名を指定させるのではなく、チケット制御部１３側において、チケットの発行要求の呼び出し元をスタックをトレースすることにより判定してもよい。

続いて、チケット５１０を入手したＡアプリ１１ａは、チケット５１０と自身のアプリ名とを提示してデータ管理部１２に対して設定情報の操作（書き込み、参照等）を要求する（Ｓ１０３）。当該要求に応じ、データ管理部１２は、Ａアプリ１１に対する該操作権限の有無の判定を、提示されたチケット、要求された操作内容、及び要求元のＡアプリ１１ａのアプリ名を指定してアクセス制御部１４に要求する（Ｓ１０４）。

アクセス制御部１４は、操作権限の有無を判定する前に、チケット５１０の改竄チェックをチケット制御部１３に要求する（Ｓ１０５）。チケット制御部１３は、チケット５１０に含まれている署名情報５１４に基づいてチケット５１０の改竄の有無をチェックし（Ｓ１０６）、チェック結果をアクセス制御部１４に返却する（Ｓ１０７）。

チケット５１０が改竄されていない場合、アクセス制御部１４は、チケット５１０、アプリ名、及び操作内容を伴って、チケット５１０に基づく操作権限の有無の判定をポリシー制御部１５に要求する（Ｓ１０８）。ポリシー制御部１５は、ポリシーサーバ２０よりチケット５１０に対応するポリシー情報２１を取得し、操作権限の有無等を判定する（Ｓ１０９）。なお、当該ステップの詳細については後述する。続いて、ポリシー制御部１５は、操作権限の有無の判定結果をアクセス制御部１４に返却する（Ｓ１１０）。アクセス制御部１４は、当該判定結果をデータ管理部１２に返却する（Ｓ１１１）。データ管理部１２は、判定結果において操作権限が有ることが示されている場合には、要求された操作を実行し、その実行結果をＡアプリ１１ａに返却する（Ｓ１１２）。一方、判定結果において操作権限が無いことが示されている場合には、要求された操作は実行せず、エラーをＡアプリ１１ａに返却する（Ｓ１１２）。

続いて、ステップＳ１０９における処理内容の詳細について説明する。図７は、ポリシー制御部による操作権限の判定処理を説明するためのフローチャートである。

まず、チケット５１０における履歴情報ＩＤ１７１に示される値を履歴情報ＩＤ１７１として有する履歴情報１７ａを補助記憶装置１０４より取得する（Ｓ１０９１）。続いて、履歴情報１７ａの署名情報１７４に基づいて履歴情報１７ａの改竄の有無をチェックする（Ｓ１０９２）。履歴情報１７ａが改竄されていることが検知された場合（Ｓ１０９２でＮｏ）、「操作権限無し」と判定する（Ｓ１１０１）。

履歴情報１７ａが改竄されていないことが確認された場合（Ｓ１０９２でＹｅｓ）、チケット５１０におけるチケット発行先５１２に記録されているアプリ名に基づいて適用対象となるポリシー情報２１をポリシーサーバ２０より検索し、取得する（Ｓ１０９３）。

図８は、ポリシー情報の構成例を示す図である。同図に示されるポリシー情報２１ａは、Ａアプリ１１ａに対するポリシー情報２１の例である。同図において、ポリシー情報２１ａは、適用アプリ名２１１、ポリシーＩＤ２１２、流通許可定義２１３、操作許可定義２１４、及び署名情報２１５等を含む。

適用アプリ名２１１は、当該ポリシー情報２１ａが適用されるアプリ１１のアプリ名である。ステップＳ１０９３における検索の際には、適用アプリ名２１１に基づいて適用対象か否かが判定される。ポリシーＩＤ２１２は、各ポリシー情報２１に対して一意に割り当てられるＩＤである。流通許可定義２１３は、チケット５１０について許可される流通経路に関する定義（チケット５１０を利用可能なアプリを識別する情報）である。図中では、「ＧＥＴ：Ａアプリ」という定義と、「ＵＳＥ：Ｂアプリ」という定義とより構成される。これは、Ａアプリ１１ａによって取得されたチケット５１０は、Ｂアプリ１１ｂによって利用可能であることを示す。すなわち、本実施の形態では、各アプリ１１に対して発行されるチケットは、ポリシー情報２１における流通許可定義２１３に定義された範囲内で流通（引き渡す又は引き回す）ことが可能とされている。流通許可定義２１３における定義順（記述順）は、チケット５１０の利用順に関する制限を示す。流通許可定義２１３は、チケット５１０の利用順を示す（規定する）情報でもある。なお、チケット５１０を取得したアプリＡ１１ａは、もちろんチケット５１０を利用可能である。

操作許可定義２１４は、チケット５１０に基づいて許可される操作に関する定義である。図中では、「Ａアプリ Machine Information WRITE」という定義と、「Ｂアプリ Machine Information READ」という定義とより構成される。前者は、Ａアプリ１１ａは自ら取得したチケット５１０に基づいて機器１０の設定情報の書き込みが許可される（書き込み権限が有る）ことを示す。後者は、Ｂアプリ１１ｂは、Ａアプリ１１ａによって取得されたチケット５１０に基づいて機器１０の設定情報の参照が許可されることを示す。署名情報２１５は、ポリシー情報２１ａの改竄を検知するための電子署名であり、例えば、適用アプリ名２１１、ポリシーＩＤ２１２、流通許可定義２１３、及び操作許可定義２１４を含む情報のハッシュ値である。

続いて、取得されたポリシー情報２１ａの流通許可定義２１３と、履歴情報１７ａの履歴項目１７３及び操作要求元のアプリ名とを照合することによりチケット５１０ａの流通経路の適否を判定する（Ｓ１０９４）。具体的には、履歴項目１７３に基づいて、チケット５１０の過去の利用アプリを判定すると共に操作要求元のアプリ名に基づいて現在のチケット５１０の利用アプリを判定する。その判定結果に基づくチケット５１０の利用順が、流通許可定義２１３の定義順に一致する場合は流通経路は適切であると判定し、一致しない場合は、流通経路は不適切（ポリシー違反）であると判定する。

この段階では、履歴項目１７３には１行目のみが記録されており、当該記録に係る行為は、流通許可定義２１３の１行目において許可されているものである。したがって、チケット５１０の流通経路は適切であると判定される。

なお、このステップＳ１０９４におけるチェックを更に厳しくしてもよい。例えば、履歴情報１７ａの記録順をポリシー情報２１の操作許可定義２１４における定義順と比較して、履歴に基づく操作の実行順が、ポリシー情報２１における定義順に一致しない場合は、流通経路はポリシー違反であると判定してもよい。この場合、操作許可定義２１４は、操作の順番をも示す（規定する）情報となる。

チケット５１０の流通経路が適切な場合（Ｓ１０９４でＹｅｓ）、ポリシー情報２１の操作許可定義２１４に基づいて操作権限の有無を判定する（Ｓ１０９５）。ここでは、操作要求元はＡアプリ１１ａであるため、要求操作が設定情報の書き込みであれば「操作権限有り」と判定し（Ｓ１０９６）、履歴情報１７ａの履歴項目１７３に対してＡアプリ１１ａが設定情報の書き込みを行う旨（図６における設定項目１７３の２行目）を記録する（Ｓ１０９７）。続いて、履歴情報１７ａの履歴項目１７３に基づいて、チケット５１０は消尽したか否かを判定する（Ｓ１０９８）。チケット５１０の消尽とは、チケット５１０の操作許可定義２１４において許可されている全ての操作が当該チケット５１０に基づいて行われたことをいう。すなわち、本実施の形態において、チケットは、操作許可定義２１４において許可された一連の操作に対して一回のみの権限を与えるものであり、同一のチケットに基づいて一連の操作を繰り返すことはできない。古いチケットが流通することによるセキュリティの劣化を防止するためのである。

チケット５１０が消尽した場合（Ｓ１０９８でＹｅｓ）、履歴情報１７ａを無効化する（Ｓ１０９９）。無効化とは、履歴情報１７ａが無効であることが識別可能な情報を、履歴情報１７ａ内、又は履歴情報１７ａと関連付けて記録することをいう。無効化された履歴情報１７ａに対応するチケットは、利用不可能な状態となる。なお、チケット５１０自体を無効化してもよい。

チケット５１０が消尽していない場合（Ｓ１０９８でＮｏ）、履歴情報１７ａの無効化は実行されない。ここでは、Ａアプリ１１ａによる書き込みが行われたのみであり、チケット５１０は、まだＢアプリ１１ｂによる参照について利用可能である。したがって、消尽していないとして履歴情報１７ａの無効化は行われない。

一方、操作許可定義２１４に定義されていない操作を要求している場合は（Ｓ１０９５でＮｏ）、「操作権限無し」と判定する（Ｓ１１０１）。

なお、チケット５１０の流通経路がポリシー情報２１ａの流通許可定義２１３に違反していると判定した場合（Ｓ１０９４でＮｏ）、ポリシー違反のチケットの流通（引き回し）を検知したことを履歴情報１７ａの履歴項目１７３に記録し（Ｓ１１００）、「操作権限無し」と判定する（Ｓ１１０１）。なお、この場合、履歴項目１７３には、操作要求元アプリのアプリ名、要求操作内容、及びチケットの発行先のアプリ名等を記録しておくと、後のトレース作業において有効な情報となる。

次に、チケットの流通を伴う処理手順について説明する。図９は、ポリシー違反のチケットの流通が行われた場合の処理手順を説明するためのシーケンス図である。

例えば、Ａアプリ１１ａによって設定情報への書き込みが行われた後、Ａアプリ１１ａによって取得されたチケット５１０がＣアプリ１１ｃに引き渡され（Ｓ２０１）、チケット５１０に基づいてＣアプリ１１ｃが設定情報の参照をデータ管理部１２に要求したとする（Ｓ２０２）。この場合、ステップＳ２０３〜Ｓ２０７において、図４のステップＳ１０４〜Ｓ１０８と同様の処理が実行される。続いて、ステップＳ２０８において、図７において説明した処理が実行される。ここでは、図７のステップＳ１０９４において、チケット５１０の流通経路はポリシー違反であると判定される。すなわち、ポリシー情報２１ａの流通許可定義２１３において、Ｃアプリ１１ｃによるチケット５１０の利用が許可されていないからである。したがって、ステップＳ１１００及びＳ１１０１が実行され、「操作権限無し」と判定される。その結果、Ｃアプリ１１ｃによる設定情報の参照は拒否される（図９のＳ２０９〜Ｓ２１１）。

なお、チケットの流通経路がポリシー違反であることが検知された場合、警告メッセージ等を操作パネル１０９表示して、異常の検知をユーザに通知するようにしてもよい。更に、機器１０の機能全体を停止させてしまってもよい。

図９の処理手順によれば、Ｃアプリ１１ｃが機器１０内に保管されている機密文書などのデータを取り出してネットワーク上に流出させてしまうような悪意あるプログラムであり、斯かるＣアプリ１１ｃがプラグインとして機器１０にインストールされた場合であっても、Ｃアプリ１１ｃが不法にチケットを入手し、情報を読み出そうとしたことを履歴として記録することができる。その結果、Ｃアプリ１１ｃを機器１０より除外する等、適切な措置をとることができる。

次に、図１０は、ポリシーにしたがったチケットの流通が行われた場合の処理手順を説明するためのシーケンス図である。

例えば、Ａアプリ１１ａによって設定情報への書き込みが行われた後、Ａアプリ１１ａによって取得されたチケット５１０がＢアプリ１１ｂに引き渡され（Ｓ３０１）、チケット５１０に基づいてＢアプリ１１ｂが設定情報の参照をデータ管理部１２に要求したとする（Ｓ３０２）。この場合、ステップＳ３０３〜Ｓ３０７において、図４のステップＳ１０４〜Ｓ１０８と同様の処理が実行される。続いて、ステップＳ３０８において、図７において説明した処理が実行される。ここで、履歴情報１７ａによれば（この時点では、２行目までが記録されている。）、過去のチケット５１０の利用者はＡアプリ１１ａのみであり、現在のチケット５１０の利用者はＢアプリ１１ｂである。また、ポリシー情報２１ａの流通許可定義２１３において、Ｂアプリ１１ｂは、Ａアプリ１１ａの次にチケット５１０の利用が許可されている。したがって、チケット５１０の流通経路は適切であると判定される（Ｓ１０９４でＹｅｓ）。また、ポリシー情報２１ａの操作許可定義２１４において、Ｂアプリ１１ｂには、設定情報の参照が許可されている（Ｓ１０９５でＹｅｓ）。よって「操作権限有り」と判定され（Ｓ１０９６）、Ｂアプリ１１ｂによる設定情報の参照の記録が履歴情報１７ａの履歴項目１７３に追加される（図６の履歴項目１７３の３行目参照）（Ｓ１０９７）。なお、Ｂアプリ１１ｂによって設定情報の参照が行われたことにより、チケット５１０は消尽するため（効力が失われるため）（Ｓ１０９８でＹｅｓ）、履歴情報１７ａは無効化される（Ｓ１０９９）。したがって、その後、チケット５１０に基づく操作は拒否される。

続いて、Ｂアプリ１１ｂに対する操作権限が有ることがアクセス制御部１４を介してデータ管理部１２に返却され（Ｓ３０９、Ｓ３１０）、Ｂアプリ１１ｂによる設定情報の参照が行われる（Ｓ３１１）。

なお、上記では、ポリシーサーバ２０においてポリシー情報２１が管理される例について説明したが、ポリシー情報２１は、機器１０の補助記憶装置１０４に記録されていてもよい。例えば、アプリ１１がプラグインとしてインストールされる場合、インストール制御部１６は、ポリシーサーバ２０よりネットワークを介して当該アプリ１１に対するポリシー情報２１を取得し、補助記憶装置１０４に記録する。この際、ポリシーサーバ２０との通信はＳＳＬ（Secure Socket Layer）やＩＰＳＥＣ(Security Architecture for Internet Protocol)等の暗号通信を用いることによりポリシー情報２１をセキュアに転送するようにしてもよい。

斯かる仕組みにより、新たにプラグインされたアプリ１１に対しても、ネットワーク経由で新規に作成したポリシー情報２１を強制的に適用させることが出来る。また、ポリシー情報２１の配布をポリシーサーバ２０に実行させることで、一度に複数台の機器１０へ同時にアプリ１１を追加したい場合も、効率的にポリシー情報２１を配布することが出来る。

また、ポリシー情報２１の入手は、ネットワークを介してではなく、ＳＤカード等、機器１０に接続可能な記録媒体より行ってもよい。これにより、ネットワーク接続機能をもたない機器１０におけるポリシー情報２１に基づくアクセス制御を適切に実現することができる。

更に、ポリシー情報２１は、アプリ１１のパッケージ内に含まれていてもよい。この場合、インストール制御部１６は、アプリ１１のパッケージよりポリシー情報２１を取得し、補助記憶装置１０４に記録する。この場合、別途ポリシー情報２１の導入作業を行う必要をなくすことができる。

上述したように、本実施の形態における機器１０によれば、アプリ１１間においてチケットを流通させることができる。したがって、アプリ１１ごとにチケットを発行する必要はなく、メモリリソース面、パフォーマンス面における負荷の増大を抑制することができる。

また、ポリシー情報２１に基づいて、チケットの流通経路（共通のチケットを利用可能なアプリ１１）を制限することができるため、チケットの流通によるセキュリティの劣化を適切に抑制することができる。

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

本発明の実施の形態におけるシステム構成例を示す図である。本発明の実施の形態における機器のハードウェア構成例を示す図である。本発明の実施の形態における機器の機能構成例を示す図である。アプリによる設定情報の操作時の処理手順を説明するためのシーケンス図である。チケットの構成例を示す図である。一つのチケットに対する履歴情報の構成例を示す図である。ポリシー制御部による操作権限の判定処理を説明するためのフローチャートである。ポリシー情報の構成例を示す図である。ポリシー違反のチケットの流通が行われた場合の処理手順を説明するためのシーケンス図である。ポリシーにしたがったチケットの流通が行われた場合の処理手順を説明するためのシーケンス図である。

符号の説明

１０機器
１１アプリ
１１ａＡアプリ
１１ｂＢアプリ
１１ｃＣアプリ
１２データ管理部
１３チケット制御部
１４アクセス制御部
１５ポリシー制御部
１６インストール制御部
２０ポリシーサーバ
３０ネットワーク
１０１ＣＰＵ
１０２ＲＯＭ
１０３ＲＡＭ
１０４補助記憶装置
１０５ＬＡＮコントローラ
１０６ファクシミリ装置
１０７画像読み取り装置
１０８印刷装置
１０９操作パネル
Ｂバス

Claims

プログラムを追加可能な機器であって、
プログラムごとに当該プログラムを識別するための電子チケットを発行する電子チケット発行手段と、
前記電子チケットに基づいて前記プログラムが要求する操作に対する権限の有無を、記憶手段に記録されたポリシー情報に基づいて判定する権限判定手段とを有し、
前記ポリシー情報は、プログラムごとに、当該プログラムに対して発行された前記電子チケットを利用可能なプログラムを識別する情報を含み、
前記権限判定手段は、前記操作の要求元のプログラムが、前記電子チケットを発行されたプログラムに対する前記ポリシー情報において当該電子チケットを利用可能とされていないときは前記操作の権限は無いと判定することを特徴とする機器。
前記ポリシー情報は、前記電子チケットを利用可能なプログラムのそれぞれの操作の権限の有無を識別する情報を更に含み、
前記権限判定手段は、前記電子チケットを発行されたプログラムに対する前記ポリシー情報において、操作の要求元のプログラムに対して当該操作の権限が認められていないときは当該操作の権限は無いと判定することを特徴とする請求項１記載の機器。
前記権限判定手段によって操作の権限が有ると判定された場合に当該操作に係るプログラムの識別名を、前記電子チケットごとに履歴情報として記憶手段に記録する履歴記録手段を有し、
前記権限判定手段は、前記履歴情報に記録されている前記識別名に係るプログラムの中で、操作の要求に用いられた前記電子チケットに対する前記ポリシー情報において当該電子チケットを利用可能とされていないプログラムが有るときは、前記操作の権限は無いと判定することを特徴とする請求項１又は２記載の機器。
前記ポリシー情報は、前記電子チケットを利用可能なプログラムの利用順を示す情報を含み、
前記権限判定手段は、前記履歴情報に記録された識別名の順番と、前記ポリシー情報における前記利用順を示す情報との比較に基づいて権限の有無を判定することを特徴とする請求項３記載の機器。
前記ポリシー情報は、前記電子チケットを利用可能なプログラムによる操作の順番を示す情報を含み、
前記履歴記録手段は、権限が有ると判定された操作の識別名をプログラムの識別名とともに前記履歴情報に記録し、
前記権限判定手段は、前記履歴情報に記録された操作の識別名の順番と、前記ポリシー情報における前記操作の順番を示す情報との比較に基づいて権限の有無を判定することを特徴とする請求項３又は４記載の機器。
前記権限判定手段は、前記履歴情報に記録された操作の識別名の順番に基づいて、前記ポリシー情報における前記操作の順番を示す情報に係る全ての操作が実行されたか否かを判定し、全ての操作が実行されたときは、操作の要求に用いられた前記電子チケットを利用不可能な状態とすることを特徴とする請求項５記載の機器。
電子チケット発行手段と権限判定手段とを有し、プログラムを追加可能な機器における操作権限判定方法であって、
前記電子チケット発行手段が、プログラムごとに当該プログラムを識別するための電子チケットを発行する電子チケット発行手順と、
前記権限判定手段が、前記電子チケットに基づいて前記プログラムが要求する操作に対する権限の有無を、記憶手段に記録されたポリシー情報に基づいて判定する権限判定手順とを有し、
前記ポリシー情報は、プログラムごとに、当該プログラムに対して発行された前記電子チケットを利用可能なプログラムを識別する情報を含み、
前記権限判定手順において、前記権限判定手段は、前記操作の要求元のプログラムが、前記電子チケットを発行されたプログラムに対する前記ポリシー情報において当該電子チケットを利用可能とされていないときは前記操作の権限は無いと判定することを特徴とする操作権限判定方法。
前記ポリシー情報は、前記電子チケットを利用可能なプログラムのそれぞれの操作の権限の有無を識別する情報を更に含み、
前記権限判定手順において、前記権限判定手段は、前記電子チケットを発行されたプログラムに対する前記ポリシー情報において、操作の要求元のプログラムに対して当該操作の権限が認められていないときは当該操作の権限は無いと判定することを特徴とする請求項７記載の操作権限判定方法。
前記機器は履歴記録手段を有し、
前記履歴記録手段が、前記権限判定手順において操作の権限が有ると判定された場合に当該操作に係るプログラムの識別名を、前記電子チケットごとに履歴情報として記憶手段に記録する履歴記録手順を有し、
前記権限判定手順において、前記権限判定手段は、前記履歴情報に記録されている前記識別名に係るプログラムの中で、操作の要求に用いられた前記電子チケットに対する前記ポリシー情報において当該電子チケットを利用可能とされていないプログラムが有るときは、前記操作の権限は無いと判定することを特徴とする請求項７又は８記載の操作権限判定方法。
前記ポリシー情報は、前記電子チケットを利用可能なプログラムの利用順を示す情報を含み、
前記権限判定手順において、前記権限判定手段は、前記履歴情報に記録された識別名の順番と、前記ポリシー情報における前記利用順を示す情報との比較に基づいて権限の有無を判定することを特徴とする請求項９記載の操作権限判定方法。
前記ポリシー情報は、前記電子チケットを利用可能なプログラムによる操作の順番を示す情報を含み、
前記履歴記録手順において、前記履歴記録手段は、権限が有ると判定された操作の識別名をプログラムの識別名とともに前記履歴情報に記録し、
前記権限判定手順において、前記権限判定手段は、前記履歴情報に記録された操作の識別名の順番と、前記ポリシー情報における前記操作の順番を示す情報との比較に基づいて権限の有無を判定することを特徴とする請求項９又は１０記載の操作権限判定方法。
前記権限判定手順において、前記権限判定手段は、前記履歴情報に記録された操作の識別名の順番に基づいて、前記ポリシー情報における前記操作の順番を示す情報に係る全ての操作が実行されたか否かを判定し、全ての操作が実行されたときは、操作の要求に用いられた前記電子チケットを利用不可能な状態とすることを特徴とする請求項１１記載の操作権限判定方法。