以下、本発明の実施の形態を、図面を参照して詳細に説明する。
図1は、本発明の実施形態に関わる改ざんチェック装置、SCMサーバ、SCMクライアント、アプリケーション動作サーバのシステム構成の一例を示す図である。SCMクライアント101、SCMサーバ102、改ざんチェック装置103、アプリケーション動作サーバ104、105は、ネットワーク106を介して相互に接続される。
図2は、改ざんチェック装置、SCMサーバ、SCMクライアント、アプリケーション動作サーバの各ハード構成の一例を示すブロック図である。CRT201と、入力デバイス202と、CPU203と、RAM204と、ROM205と、外部記憶装置206と、ネットワーク・インタフェース207とを備える。
CPU203は、ROM205に記憶された制御プログラムを読み出して実行すると共に、情報処理装置を制御する。RAM204は、データ等を一時記憶するためのバッファやワークエリア等として機能し、またOSを含む各種プログラムを実行する作業領域として使用される。
外部記憶装置206はハードディスクドライブ等の記憶装置であり、OSやファイル管理システムのプログラムを含む各種プログラム及び各種データの短期的、永続的な記憶装置として使用される。
入力デバイス202は、キーボード、マウス等に代表されるユーザ入力機器であり、CRT201は情報処理装置の処理結果等を表示するための機器である。バス208は、上述した各部を互いに接続するシステムバスである。
なお、SCMサーバ102、アプリケーション動作サーバ104ならびに105においては、CRT201および入力デバイス202は、必須なものではない。
図3は、改ざんチェック装置、SCMサーバ、SCMクライアント、アプリケーション動作サーバの関連を簡単な動作例を用いて説明する概略図である。
SCMクライアント301は、図1のSCMクライアント101に相当し、SCMサーバ303は、図1の102、アプリケーション動作サーバ305は、図1のアプリケーション動作サーバ104および105、改ざんチェック装置307は図1の改ざんチェック装置103に相当する。
SCMサーバ303は、ソフトウェア構成管理システム(Software Configuration Management System:SCMシステム)と呼ばれるツールであり、開発しているプログラム(ソースコード)を変更する際に変更する旨の申請および承認のワークフロー管理、変更したプログラム(ソースコード)のバージョン管理、前記申請及び承認のワークフローと実際に変更したプログラム(ソースコード)の関連を保持し、プログラムの変更に関する監査履歴(誰が、いつ、どのような理由で、誰の承認を得て変更をしたのか)を残すことができる。SCMツールは、1つのアプリケーションを構成するために必要なソースコード一式を「プロジェクト」という単位で管理する。例えば、経理システムを構成するソースコード一式を「経理ソースコード」というプロジェクト名で管理することができる。
図4のGUI401は、ソフトウェア構成管理(SCM)ツールのクライアント側GUIの一例である。画面は大きく3つに分かれており、プロジェクト一覧ウィンドウ402、プロジェクト原本表示ウィンドウ403、作業領域表示ウィンドウ404から構成される。
プロジェクト一覧ウィンドウ402は、プロジェクトと呼ばれる単位で管理され、図4の例では3つのプロジェクトが管理されている。
例えば1つのアプリケーションを構成する全てのソースコードを格納することができる。プロジェクト名405は、例として「Keiri_Source_Code」(407)であり、説明(備考)406として「経理システムソースコード管理用プロジェクト」というコメントを付与している。いずれも利用者が当該GUI401を用いて設定することができる。
プロジェクト原本表示ウィンドウ403は、SCMサーバ303(図3)上に格納されている原本ファイル群(ここでは経理システムソースコードのファイル群)の最新の状態を表示している。通常の開発におけるフォルダおよびファイルの構成が、ウィンドウ内にツリー構造としてそのまま表示されている。従って複数の開発者が同時に当該プロジェクトの開発を行う場合であっても、(最新状態を表示さえすれば)同じ表示状態になる。
作業領域表示ウィンドウ404の表示内容は、プロジェクト原本表示ウィンドウ403とほぼ同一だが、SCMサーバ303(図3)の状態を表しているのではなく、作業領域(通常は開発者などが個人使用するPCのローカルのフォルダ)の最新状態が表示されている。この例では、ファイル409“uriage.jsp”とファイル410“syousai.jsp”の2ファイルがチェックアウト(checkout)されている。チェックアウトとは、該ローカルPCで開発者が前記2ファイルを作業している状態である。他の開発者が使用できないように排他的ロックすることが多いが、開発者あるいはシステム管理者(SCMサーバ303の管理者)が、オプションにより排他的か非排他的か選択することができるSCMツールも存在する。
ファイル410“syousai.jsp”には“*”記号が表示されており、チェックアウトした後、ローカルPCの作業領域で編集し、SCMサーバ303の原本とは差分が生じていることを表している。差分をSCMサーバ303の原本に反映し、変更したものを新たに原本とするためには、開発者はチェックイン(checkin)という操作をする。
さらに、SCMツールはプログラム(ソースコード)だけではなく、バイナリデータ(実行ファイルやワープロ文書、データ)、htmlファイル、htmlファイルで表示する画像データなど、アプリケーションを構成するファイル一式を管理することも可能であり、図4の例では、ソースコード側のプロジェクト(GUI401のプロジェクト一覧ウィンドウ402)に対応して3つのプロジェクトが管理されている。ただしこれはあくまで例であり、ソースコードのみ管理する場合、実行ファイルのみを管理する場合などがあってもよい。
例えば、前述の経理システムを構成するソースコード一式をコンパイル、あるいはビルドしてアプリケーションとして動作可能なファイル一式(リリースファイル、リリースデータ)に変換した後、本図ではプロジェクト名411「KeiriProject」、説明(備考)412「経理システムリリース用プロジェクト」というプロジェクト名で管理する。
バイナリデータの原本を更新する場合も、ソースコードの場合と同様に一度チェックアウトし、外部でコンパイラ、ビルド等されたファイで上書きする。図4のファイル413“tool.jar”がローカルPCの作業領域上で、“tool.jar”が変更された状態にあることを示している。このファイルをチェックインすることで、SCMサーバ303上の“tool.jar”の原本を更新する。
デプロイ(リリース)用に設定されたプロジェクト411“KeiriProject”では、更新されたファイルがチェックインされると、SCMサーバ303はこのファイルを指定されたアプリケーション動作サーバにデプロイするように機能設定できる製品もある。
説明を図3に戻すと、「デプロイ実施」は、前述のようにアプリケーションの一部ファイルが変更され、デプロイされ、改ざんチェックされる動作の概略図である。
SCMクライアント301には、アプリケーションを構成するファイル一式を管理するワークスペース302があり、変更しビルドし直したファイルは開発者によりワークスペースに上書きされる。 開発者が、前記上書きしたファイルを指定して、SCMサーバ303にチェックインすると、登録された原本ファイル群であるリポジトリ304は更新される。ここで更新とは、単に既存ファイルの変更だけではなく、存在しないファイルの追加、既存ファイルの削除の処理も含む。
SCMサーバ303は、前記チェックインされたファイルがあると、自動的にあるいはSCMクライアントのユーザ操作によりデプロイを実施する。デプロイは、前記チェックインされたファイルの更新情報をアプリケーション動作サーバ305に送信し、アプリケーションファイル306を更新する処理である。前述と同様、更新とは、変更、追加、削除を含む。
図3の改ざんチェック装置307は、改ざんチェック対象のアプリケーションを構成するファイル(原本ファイル)をSCMサーバ303の指定されたプロジェクトのリポジトリ304から抽出する。さらに対応するアプリケーションファイル306をアプリケーション動作サーバから抽出する。
改ざんチェック装置307に抽出された原本ファイル308と抽出されたアプリケーションファイルは、同じフォルダ構成(ルートフォルダ配下の階層構造など)からなっている。すなわち、改ざんチェック装置307のハードディスク内に指定された異なる2つのフォルダを各々のルートフォルダとし、その配下は同じはずである。この2つのルートフォルダ配下に格納されたファイル群から、改ざんチェック装置307は差分を検出する。以上の動作は、シナリオ記憶手段310に記憶されているシナリオに基づいて実行される。
図3では、SCMクライアント301、SCMサーバ303、アプリケーション動作サーバ305、改ざんチェック装置307の全てを異なる装置として記載しているが、これらの全てあるいは一部が同一の装置上に構成されていても良い。
図5は改ざんチェック装置の機能ブロックの一例を示す図である。改ざんチェック装置の機能ブロックは、大きく分けてシナリオ読み込み手段501とシナリオ実行手段502に分かれている。またシナリオ実行手段502は、原本取得手段503、チェック対象取得手段504、比較手段505、レポート手段506を制御する。
シナリオ読み込み手段501で読み込まれたシナリオファイル507は、メモリ上に展開されたシナリオ510としてシナリオ実行手段502で利用しても良い。図8は、後述のフローチャートを説明する際に使用する図13のシナリオ1301をメモリ上に展開した一例である。
メモリ上の構成全体を管理するシナリオルート801を“Scenario”で表している。それ以下、シナリオファイル内で表現されるブロック(後述)をブロック802とその属性と値のペアを図8のブロック内容803として記載している。同様に、ブロック804、ブロック内容805、ブロック806、ブロック内容807として展開される。
図5では、シナリオ実行手段は、原本データ(原本ファイルデータ)を取得するためにシナリオ実行手段に組み込まれた原本取得手段503あるいは外部コマンドとして呼び出される原本取得手段511のいずれかを実行する。また、チェック対象を取得するためにシナリオ実行手段に組み込まれたチェック対象取得手段504あるいは外部コマンドとして呼び出されるチェック対象取得手段512のいずれかを実行する。さらに、原本とチェック対象を比較するためにシナリオ実行手段に組み込まれた比較手段505あるいは外部コマンドとして呼び出される比較手段513のいずれかを実行する。比較手段の場合には、シナリオ実行手段に組み込まれたもの、外部コマンドの双方あわせて、1または複数の比較手段を実行するよう、シナリオにて定義することができる。
ここでシナリオファイル507について説明する。シナリオファイル507は、図6にその一例を示している。図6は、外部ツールを呼び出さないシナリオの例である。
図6のシナリオファイル601には、5つのブロック602〜606が記載されている。また、行頭に「#」があるコメント行621は、コメントとしてシナリオを実行する際には無視する。
ブロックには2種類有り、ブロック602はブロック定義行622によりコピーブロック、ブロック604はブロック定義行641によりコンペアブロックとして定義される。
コピーブロックは、SCMサーバやアプリケーション動作サーバから改ざんチェックをするために必要なファイル群を取得するための定義である。
コピーブロック602の定義は、Type属性623が“Original“であり、原本性が保証されているSCMサーバからファイル群を取得するための定義を記載している。詳細にはServer属性624により”SCM“というネットワーク上のサーバにあるSCMサーバから、Project属性625により”KeiriReleaseProject“という経理アプリケーションが格納されているリポジトリの内容を抽出し、WorkFolder属性626により改ざんチェック装置の”C:¥Compare¥Original¥Keiri“フォルダに前記抽出した原本ファイル514(図5)を格納するように指示するシナリオである。
また、ブロック603の定義は、631よりコピーブロックとして定義されているが、Type属性632が“Execution“であり、アプリケーション動作サーバからファイル群を取得するための定義を記載している。詳細にはServer属性633により”¥¥Srv01¥c:¥Keiri“というネットワーク上のサーバおよびフォルダから経理アプリケーションファイルを抽出し、WorkFolder属性634により改ざんチェック装置の”C:¥Compare¥Exec¥Keiri01“フォルダに前記抽出したアプリケーションファイル515(図5)を格納するように指示するシナリオである。さらにExcludeFiles属性635により除外ファイルとして”Exclude.def”ファイルが指定され、ファイルのフルパスを文字列と見なした場合に、該ファイルに記載された文字列パターンのいずれかを含む場合には、改ざんチェックシステムの処理対象として抽出しない(改ざんチェックをしない)ファイルとなる。図5では除外ファイル508、除外ファイル509としてシナリオファイル507から指定している。図7に除外ファイルの一例を図示する。
図7の除外ファイル701には、改行コードで区切られた3つのパターンが定義されている。パターン702はフルパス中に“Logfolder¥*.log”というパターンが現れた場合には、そのファイルは前述の通り、改ざんチェックシステムの処理対象として抽出されない。
ここで“*”は、正規表現のワイルドカードを意味している。例えば“C:¥Keiri¥temp¥Logfolder¥20100820.log”が、そのパターンを満たしている。パターン703は“.bak”を、パターン704は“.conf”を同様に定義している。
ここで、パターン定義として正規表現およびワイルドカードを説明したのは、あくまで一例である。最も単純な例としては文字列の部分一致、ファイル名の完全一致、さらに正規表現以外のパターンマッチング手法などを利用しても良い。また、除外ファイルをシナリオファイルの外部定義としたが、これは運用におけるメンテナンス性を考慮したものであり、実際の用途に応じてシナリオファイルの中に記載するようにしても良い。また、単なるパターンマッチングだけではなく、スクリプト言語などによる簡単な判定ツールにより、除外ファイルのフィルタリングを行っても良い。
ここで説明を図5に戻す。図5の比較手段505は、図6のコンペアブロック604のシナリオを実行する手段である。コピーブロック602およびコピーブロック603で、改ざんチェック装置に抽出したファイル群、すなわちWorkFolder属性626で指定された”C:¥Compare¥Original¥Keiri“とWorkFolder属性634で指定された”C:¥Compare¥Exec¥Keiri01“の2つのフォルダ配下のファイル群を比較する。比較結果はレポート手段506からレポート516として出力される。
ブロック604は、641によりコンペアブロックの定義であるが、記載されているProject属性642とExecServer属性643は、例えばレポートファイルを生成する際に、原本(SCMサーバのプロジェクト名:“KeiriReleaseProject”)とアプリケーション動作サーバ名(“Srv01“)およびレポートした日時などを結合してファイル名とし、他のレポートと一意的に区別するために使用する目的で付与した属性である。レポートファイル名を一意的に生成する方法としては、他の属性の値の部分文字列を利用するなど、他の方法も考えられ、前述の方法はあくまで一例に過ぎない。さらにOriginalFolder属性644は改ざんチェック時の原本性を保証するファイル群を格納するフォルダのルートを定義する。ExecFolder属性645は改ざんチェックのチェック対象となるアプリケーションファイル群を格納するフォルダのルートを定義する。
以下の例では、外部手段を利用することを前提に説明するが、もちろんこれは実施形態の一例であることは言うまでもない。外部手段を利用することを前提とするため、機能ブロックを図9〜図12を予め説明する。
図9の原本取得手段901は、改ざんチェック装置上の機能ブロックの一部であり、原本抽出手段902、原本受信外部手段903、原本不要ファイル除外手段904から構成されており、原本不要ファイル除外手段904は除外ファイル設定905を参照して動作する。
原本抽出手段902は、SCMサーバの指定のリポジトリの指定のプロジェクト(例えば“KeiriProject”)の原本ファイル1006を抽出する。ただし、これは構成の一例であり、原本抽出手段902は、図10のSCMサーバ側原本抽出手段1002に要求を送り、該SCMサーバ側原本抽出手段1002が、原本ファイル1006を抽出するように機能しても良い。例えば原本抽出手段902がSCM製品のクライアント機能として提供されている場合、改ざんチェック装置にも、前者のようにSCMクライアントをインストールしなければならないが、原本抽出手段902からSCMサーバ側原本抽出手段1002を呼出し、SCMサーバ側原本抽出手段1002をSCM製品のクライアント機能により構成すれば、改ざんチェック装置にSCMクライアントをインストールする必要はなくなる。
次に、原本受信外部手段903は、原本抽出手段902で抽出した原本ファイル1006(図10)を、改ざんチェック装置側に転送する際の受信機能を有する。
前述のように、原本抽出手段902がSCMサーバ側原本抽出手段1002に要求せずに、単独で動作する場合には、原本受信外部手段903は不要となる。SCMサーバ側原本抽出手段1002に要求してSCMサーバ側で原本ファイルを抽出した場合には、原本受信外部手段903は、独自に原本ファイル1006を改ざんチェック装置に転送するか、SCMサーバ側原本送信手段と協調して原本ファイル1006の送受信を行うかのいずれかである。
前者の例としては、例えばSCMサーバにおいて抽出された原本を格納しているフォルダがネットワーク上の共有フォルダとして公開されているのであれば、OS標準のコピーコマンドを使用すればよい。後者の例としては、市販のデータ転送ソフトウェア製品を利用することも可能である。この場合、データの転送効率を良くするため多数のファイルを1つに結合する、転送中に改ざんされないようにするため暗号化する、などの機能が容易に利用できる。
最後に、原本不要ファイル除外手段904は、前述の受信したファイルのうち、改ざんチェック対象ではないファイルと改ざんチェック対象のファイルをフィルタリングする手段である。
不要なファイルを削除しても良いし、不要なファイルあるいは必要なファイルのいずれかを他のフォルダに移動しても良い。この場合、除外ファイル設定905を参照する。除外ファイルについては、既に図7で説明しているため、ここでは省略する。
原本において、不要なファイルを除外する目的としては、各種あるSCM製品の中には、原本を抽出し作業フォルダを構成する際に、原本管理用の隠しファイルを多数作成する製品も存在し、その場合には該原本管理用の隠しファイルは改ざんチェック対象から削除したい、などの理由による。もちろん他の目的で使用することも可能である。
あるいは、除外ファイル設定1005に基づきSCMサーバ側原本不要ファイル除外手段1003により、原本ファイルを改ざんチェック装置に転送する前に不要なファイルを除外しても良い。この場合、転送するファイル群は、原本ファイルから不要ファイル医を除外したファイル群1007となる。予め除外するファイルが多ければ、ネットワーク負荷も押さえることが可能となる。
以上、図9と図10の機能ブロックにより改ざんチェック処理に必要な原本ファイルが改ざんチェック装置上に格納される。
しかし、あくまで本機能ブロックの構成は一例に過ぎない。例えば、前述のコピーコマンドを使用する例において、コピーコマンド自身がファイルのフィルタリング機能を有するものもある。この場合、原本受信外部手段903および原本不要ファイル除外手段904は単一の実行コマンドとなる。また改ざんチェック装置上にSCMクライントをインストールし、SCMクライアントが1つのコマンドとして原本取得手段901の全ての機能を含んでいる場合もある。この場合はさらにSCMサーバ側においても全ての機能はSCMサーバに組み込まれていてもよい。
このように、図9と図10は様々な構成が考えられるが、詳細の動作をフローチャート図14〜図18を説明する際には、図9と図10の機能ブロックを例としてそのまま使用する。
次に図11と図12を説明する。
図11のチェック対象種特外部手段1101は、改ざんチェック装置上の機能ブロックの一部であり、チェック対象抽出手段1102、チェック対象受信外部手段1103、チェック対象不要ファイル除外手段1104から構成されている。
図11の各手段は図9の各手段と次のように対応しており、ほぼ同一の機能を有している。すなわち、チェック対象抽出手段1102と原本抽出手段902、チェック対象受信外部手段1103と原本受信外部手段903、チェック対象不要ファイル除外手段1104と原本不要ファイル除外手段904が対応している。
また、図12のアプリケーション側ファイル抽出手段1201はチェック対象種特外部手段1101(図11)と協調して動作するアプリケーション動作サーバ上の機能ブロックであり、アプリケーション側ファイル抽出手段1202、アプリケーション側不要ファイル除外手段1203、アプリケーション側ファイル送信手段1204から構成されている。
図12の各手段は図10の各手段と次のように対応しており、ほぼ同一の機能を有している。すなわち、アプリケーション側ファイル抽出手段1202とSCMサーバ側原本抽出手段1002、アプリケーション側不要ファイル除外手段1203とSCMサーバ側不要ファイル除外手段1003、アプリケーション側ファイル送信手段1204とSCMサーバ側原本送信手段1004が対応している。
対応しているとはいえ、図11と図12の機能ブロックの関係は、図9と図10の関係とは異なる点がいくつかある。例えば、図10はSCMサーバであるため、図9にSCMクライアントを導入して原本ファイルの抽出を実現することができる。一方、図12のアプリケーション動作サーバでは、アプリケーションファイルを抽出する際に、ほぼそのフォルダ構成を利用すればよいことが多く、必ずしも抽出処理が必要ではない。
一方で、図12のアプリケーション動作サーバでは、例えばWebアプリケーションサーバ(WAS)がアプリケーションファイルを管理しており、アプリケーションファイルを抽出する前提として、Webアプリケーションサーバを停止させるなどの前処理および抽出後、Webアプリケーションサーバを再起動する処理が必要な場合がある。
図11と図12にも図9と図10に関しての説明を実施した際に述べたのと同様、様々な構成が考えられるが、詳細の動作をフローチャート図14〜図18を説明する際には、図11と図12の機能ブロックを例としてそのまま使用する。
次に、改ざんチェックシステムの詳細の動作を図13〜図18を用いて説明する。
図14は改ざんチェック装置で実行する最上位の処理のフローチャートである。
ステップS1401では、シナリオファイルを読み込みメモリ上に展開する。シナリオの例として図13シナリオ1301を展開すると、メモリ上の展開結果の図8のようになる。
ステップ1402からステップS1407では、シナリオに記述されたブロック(1または複数)を先頭から1つずつ順に処理する。 ステップS1403では、ブロックの1つに着目(取得)する。
ステップS1404では、着目しているブロックが“Copy”ブロックか“Compare”ブロックかで処理を分岐する。
“Copy”ブロック1311の場合、ステップS1405Copyブロック処理手段に進む。Type属性が“Original”(例:ブロック1302のType属性1312)であれば図15(図5の原本取得手段503または原本取得手段511)が詳細のフローチャートである。Type属性が“Execution”(例:ブロック1303のType属性1322)であれば図16(チェック対象取得手段504あるいはチェック対象取得手段512に対応)が詳細のフローチャートである。
“Compare”ブロックの場合には、ステップS1406に進む。Compareブロック処理手段(図5の比較手段505または比較手段513に対応)は、図17および図18のフローチャートで説明する。
ステップS1408では、ステップS1406における原本ファイルとアプリケーションファイルの比較結果を、出力する(図5のレポート手段506に対応)。詳細の説明としては、図18のフローチャートの処理において図19の構造を生成する方法について説明する。図20は、図19の構造をファイルに出力した形式の一例であり、後述する。
図15は、SCMサーバから原本ファイル群を取得するプログラムである。このフローチャートを実行するのは、前述したようにType属性1312のようにType属性の値が“Original”である場合である。フローチャート1501が改ざんチェック装置、フローチャート1502がSCMサーバにおけるプログラムの処理であり、協調して動作する。
ステップS1503原本抽出手段は、Server属性1313の“SCM”上、Project属性1314の“KeiriProject”に格納されている原本ファイルを抽出するようステップS1507SCMサーバ側原本抽出手段に要求する(リクエスト1511)。ステップS1507SCMサーバ側原本抽出手段は要求通り、SCMサーバに格納されているプロジェクト“KeiriProject”から原本ファイルを抽出し、WorkFolder属性1315に指定された改ざんチェック装置側のフォルダ“C:¥Compare¥Original¥Keiri”に格納する。
SCMサーバ側で不要なファイルを除外するように設定されている場合には、ステップS1508YesによりステップS1509SCMサーバ側原本不要ファイル除外手段に進み、改ざんチェックの処理対象として不要なファイルが除外される。実際に、ファイルを削除する、別のフォルダに移動する、あるいはファイル自体は元の位置に存在するが改ざんチェック時に利用しないよう一覧表に残すなど、除外方法は、物理的なもの、論理的(仮想的)なもの限定しない。その後、ステップS1510SCMサーバ側原本送信手段に進む。
SCMサーバ側で不要なファイルを除外するように設定されていない場合には、ステップS1508NoによりステップS1510SCMサーバ側原本送信手段に進む。
ステップS1510SCMサーバ側原本送信手段では、ステップS1507SCMサーバ側原本抽出手段で抽出したファイルを、SCMサーバ側から改ざんチェック装置側に送信する。ステップS1509SCMサーバ側原本不要ファイル除外手段を実行した場合には不要ファイルを除外した残りのファイルを送信する(送信1512)。
送信されたファイルは、改ざんチェック装置側においてステップS1504原本受信外部手段により受信される。
次に改ざんチェック装置側で不要なファイルを除外するように設定されている場合には、ステップS1505YesによりステップS1506原本不要ファイル除外手段に進み、改ざんチェックの処理対象として不要なファイルが除外される。実際に、ファイルを削除する、別のフォルダに移動する、あるいはファイル自体は元の位置に存在するが改ざんチェック時に利用しないよう一覧表に残すなど、除外方法は、物理的なもの、論理的(仮想的)なもの限定しないのはステップS1509SCMサーバ側原本不要ファイル除外手段と同様である。これにより図15のフローチャートを完了し、呼出側である図14のステップS1405Copyブロック処理手段の終了時点に戻る。
改ざんチェック装置側で不要なファイルを除外するように設定されていない場合には、図15のステップS1505Noによりフローチャートを完了し、呼出側である図14のステップS1405Copyブロック処理手段の終了時点に戻る。
なお、図15のフローチャートでは、ステップS1508とステップS1505により、原本ファイルから不要ファイルを除外する処理が、SCMサーバ側か改ざんチェック装置側か判定しているが、このような判定せず一方に固定的に実装する、あるいは両方で(同一、あるいは異なる除外設定で)除外処理をする、などの実装が可能であることは言うまでもない。その他、図15は様々な実現方法があり、本フローチャートは、原本ファイルをSCMサーバから抽出する実装の一例に過ぎない。
図16は、アプリケーション動作サーバからアプリケーションファイル群を取得するプログラムである。このフローチャートを実行するのは、前述したようにコピーブロック1321のType属性1322のようにType属性の値が“Execution”である場合である。フローチャート1601が改ざんチェック装置、フローチャート1602がアプリケーション動作サーバにおけるプログラムの処理であり、協調して動作する。
ステップS1603チェック対象抽出手段は、Server属性1323の値¥¥Srv01¥c:¥Keiri(サーバ名¥フォルダ名)に格納されているアプリケーションファイルを抽出するようステップS1607アプリケーション側ファイル抽出手段に要求する(リクエスト1611)。ステップS1607アプリケーション側ファイル抽出手段は要求通り、アプリケーション動作サーバ“¥¥Srv01”のフォルダ“c:¥Keiri”からアプリケーションファイルを抽出する。
アプリケーション動作サーバ側で不要なファイルを除外するように設定されている場合には、ステップS1608YesによりステップS1609アプリケーション側不要ファイル除外手段に進み、改ざんチェックの処理対象として不要なファイルが除外される。この際、除外ファイル設定としては、ExcludeFiles属性1325で定義された値“Exclude.def”を設定ファイル名として利用する。実際に、ファイルを削除する、別のフォルダに移動する、あるいはファイル自体は元の位置に存在するが改ざんチェック時に利用しないよう一覧表に残すなど、除外方法は、物理的なもの、論理的(仮想的)なもの限定しない。その後、ステップS1610アプリケーション側ファイル送信手段に進む。
アプリケーション動作サーバ側で不要なファイルを除外するように設定されていない場合には、ステップS1608NoによりステップS1610アプリケーション側ファイル送信手段に進む。
ステップS1610アプリケーション側ファイル送信手段では、ステップS1607アプリケーション側ファイル抽出手段で抽出したファイルを、アプリケーション動作サーバ側から改ざんチェック装置側に送信する。実際の送信方法としては、send属性1327に定義された“send.exe”を利用する。ステップS1609アプリケーション側不要ファイル除外手段を実行した場合には不要ファイルを除外した残りのファイルを送信する(送信1612)。
送信されたファイルは、改ざんチェック装置側においてステップS1604チェック対象受信外部手段により受信される。実際の受信方法としては、receive属性1326に定義された“receive.exe”を利用する。受信されたファイル群は、WorkFolder属性1324に指定された値“C:¥Compare¥Exec¥Keiri01”に格納する。
次に改ざんチェック装置側で不要なファイルを除外するように設定されている場合には、ステップS1605YesによりステップS1606アプリケーション側不要ファイル除外手段に進み、改ざんチェックの処理対象として不要なファイルが除外される。
実際に、ファイルを削除する、別のフォルダに移動する、あるいはファイル自体は元の位置に存在するが改ざんチェック時に利用しないよう一覧表に残すなど、除外方法は、物理的なもの、論理的(仮想的)なもの限定しないのはステップS1609SCMサーバ側原本不要ファイル除外手段と同様である。これにより図16のフローチャートを完了し、呼出側である図14のステップS1405Copyブロック処理手段の終了時点に戻る。
改ざんチェック装置側で不要なファイルを除外するように設定されていない場合には、図16のステップS1605Yesによりフローチャートを完了し、呼出側である図14のステップS1405Copyブロック処理手段の終了時点に戻る。
なお、図16のフローチャートでは、ステップS1608とステップS1605により、アプリケーションファイルから不要ファイルを除外する処理が、アプリケーション動作サーバ側か改ざんチェック装置側か判定しているが、このような判定せず一方に固定的に実装する、あるいは両方で(同一、あるいは異なる除外設定で)除外処理をする、などの実装が可能であることは言うまでもない。その他、図16は様々な実現方法があり、本フローチャートは、アプリケーション動作に存在するアプリケーションファイルを抽出する実装の一例に過ぎない。
図17は、原本ファイル群とアプリケーションファイル群を比較するプログラムのフローチャートである。ステップS1701では、全ファイルの比較結果を格納するメモリ上の構造のルートを作成する。これは、図19の比較結果情報1901で表される。図19および図20については、図17、図18と会わせて随時説明する。本フローチャートは例えば、シナリオファイル1301(図13)のコンペアブロック1304(ブロック1331の値によりコンペアブロックと定義)に従って動作する。
ステップS1702からステップS1711は、原本ファイル側を中心として、対応するアプリケーションファイルの存在、内容、属性などをチェックする繰り返し処理である。
ステップS1703では、チェック対象とする原本ファイルから1つを取り出し着目する。原本ファイルは図13の例では、1334OriginalFolder属性の値“C:¥Compare¥Original¥Keiri”に格納されている。以下の説明では、例として図20の対象2006“tool.jar”に着目する。ステップS1704では、ステップS1703で着目したファイル(原本と比較対象)の比較結果を格納する総合結果1903(図19)を生成する。項目「対象」に着目中の対象“tool.jar”を格納する。
次にステップS1705では、着目中の原本ファイルに対応するアプリケーションファイルが存在すれば取得する。本ファイルは図13の例では、1335ExecFolder属性の値“C:¥Compare¥Exec¥Keiri01”に格納されている。
ステップS1706からステップS1709は、前述で着目した原本ファイル(例では“tool.jar”)と対応するアプリケーションファイルを比較する処理であり、ループは、シナリオで指定された比較手段のそれぞれを順に処理するための繰り返し制御である。シナリオファイル1301の例では、比較手段として1337,1338,1339の3つが定義されている。
原本ファイルとアプリケーションファイル、シナリオで指定された比較手段が決定し、ステップS1707(詳細は図18のフローチャート)にて実際の比較が行われる。比較方法の詳細は図18で説明するが、比較処理は原本ファイルに対応するアプリケーションファイルが存在しなくても実行可能であるか、あるいは比較できない旨を返す。図19の例では、“tool.jar”に対して、まず比較ツール“fc”が実行され、その結果が図19の比較結果1904となり、ステップS1708で総合結果1903に関連付けられる。同様に、“size”,“create_date”が順に実行され、その結果が比較結果1905,比較結果1906となり、総合結果1903に関連付けられる。ステップS1710では、3つの比較内容1904,1905,1906が全て“○”(一致している)ため、1903の総合結果も“○”(一致している)となる。すなわち“tool.jar”に対する総合結果は、図19の総合結果1902のようになる。
同様に,図19では例として“view.jar”に対してステップS1704からステップS1709を実行した結果が図19の総合結果1907を得る。総合結果1902および総合結果1907は,いずれも比較結果情報1901に関連付けられる(格納される)。“view.jar”は、“fc”と“create_date”の比較結果が“×”(一致しない)ので、総合結果1908も“×”(一致しない)とされている。以上の処理が全ての原本ファイルに対して繰り返される。
さて、一方、アプリケーションファイル群には含まれるが、原本ファイル群には含まれないファイル,すなわち原本ファイルに非対応のアプリケーションファイルが存在する可能性がある。これらのファイルを処理するのが、ステップS1712からステップS1720である。まず、ステップS1712では、原本ファイルに非対応のアプリケーションファイルを収集する。
ステップS1713からステップS1720のループは、アプリケーションファイル側に着目して比較していること、比較対象である原本ファイルが存在しないことが最初から明確であることを除き、ステップS1702からステップS1711のループ処理と同じである。
ステップS1714において、非対応アプリケーションファイルの1つに着目する。ステップS1716において、非対応アプリケーションのみで比較処理(詳細は図18)を実施し、ステップS1717では比較内容を総合結果に関連付ける(格納する)。原本ファイルが存在しないため、ステップS1719での総合結果は、“×”(一致しない)である。最後に前述の総合結果を図19の1901比較情報結果に関連付ける(格納する)。
全ての非対応のアプリケーションファイルに対してS1713からS1720のループで制御された処理を完了したら、図17の処理、すなわち図14のステップ1406Compareブロック処理手段を完了する。
さて、図18は1つの比較手段に対して、1つの原本ファイルと対応する1つのアプリケーションファイルを比較するプログラムのフローチャートである。
本フローチャートは、改ざんチェック装置のシナリオ実行手段502(図5)から呼び出される比較手段505または比較手段513の1つに対応する。シナリオに従い、チェック対象のファイル(原本ファイルとアプリケーションファイル)を比較対象として実行されるが、前述の通り比較対象ファイルの一方が存在しない場合もある。
図18のフローチャートは、大きく4つの部分に分かれる。まず、比較処理を行う際に比較対象となる2つのファイルのうち一方でも存在すれば実行可能な比較処理に対するステップである。すなわち、何らかのコマンドで、1つのファイルの属性を抽出することが可能であるが、2つのファイルから値を抽出後、それらの値が一致するかどうかを判定するものである。
(1)ステップS1802からステップS1805は、このうち原本ファイルが存在する場合の処理である。(2)ステップS1806からステップS1809は、このうちアプリケーションファイルが存在する場合の処理である。両方存在する場合には(1)と(2)の両方を実行する。一方が存在しない場合でも、結果には空を設定しておくため、後述(3)の比較が可能である。(3)ステップS1810からステップS1813は原本ファイルとアプリケーションファイルの情報を比較する処理である。
(4)ステップS1814からステップS1816は原本ファイルとアプリケーションファイルの両方を同時に処理対象とするため、2つのファイルが存在する場合に実行可能な比較手段を前提とした処理である。
まず、ステップS1801は、比較のために使用する比較手段が、原本ファイルとアプリケーションファイルの2つが存在する必要があるか判断する。ファイルが2つ存在する必要がなければ、ステップ1801はNoを返し、上記(1)から(3)の処理を実行する(ステップS1802に進む)。ファイルが2つ存在する必要があれば、ステップ1801はYesを返し、上記(4)の処理を実行する(ステップS1814に進む)。
以下、例としてファイル“tool.jar”に対してコマンド“size”の処理を用いて説明する。
最初に前記(1)の場合について説明する。ステップS1802で原本ファイルが存在するかどうか判定する。原本ファイルが存在すればステップS1803に進み、原本ファイル“tool.jar”に対して“size”ツールを実行し結果“12,345”を得る。ステップS1803で得た値を、ステップS1804にて図19の比較内容1905における“原本”に格納する。ここでは、“12,345”が格納される。原本ファイルが存在しない場合には、ステップS1805にて、1905における“原本”に空白(値が得られなかったというマーク)を格納する。
次に前記(2)の場合について説明する。ステップS1806でアプリケーションファイルが存在するかどうか判定する。アプリケーションファイルが存在すればステップS1807に進み、原本ファイル“tool.jar”に対して“size”ツールを実行し結果“12,345”を得る。ステップS1807で得た値を、ステップS1808にて図19の比較内容1905における“比較対象”に格納する。ここでは、“12,345”が格納される。アプリケーションファイルが存在しない場合には、ステップS1809にて、1905における“比較対象”に空白(値が得られなかったというマーク)を格納する。
次に前記(3)について説明する。ここでは、前記(1)および(2)で得た2つの値をステップS1810で比較する。比較において、両者とも“比較対象”が空白(値が得られなかったというマーク)ではない値が入っており、その両者の値が一致する場合のみ、ステップS1811Yesとなり、ステップS1812に進む。ステップS1812では、図19の例では、“比較内容”に“size“を格納し、1905において、”原本“と”比較対象“のサイズがいずれも”12,345”であるため、“結果”に“○”(一致する)を格納する。
一方、原本あるいは比較対象の一方または双方の値が空白(値が得られなかったというマーク)あるいは、両方の値が得られたが一致しない場合(図19の1911の例)では“比較内容”に“create_date”、“結果”に“×”(一致しない)を格納する。
次に前記(4)について説明する。前述の通りS1801にて“Yes”となるのは、比較に使用するコマンドが、原本ファイルとアプリケーションファイルの両方を同時に処理対象とするため、2つのファイルが存在する場合に実行可能な比較手段を前提とした処理である(例として2つのファイルの内容が一致することを確認する“fc”コマンド)。
まずステップS1814では、ファイルが2つ存在することを確認する。ファイルが2つ存在した場合には、ステップS1815にて指定された比較手段を実行する。比較処理結果として“原本”および“比較対象”から、何らかの属性値を抽出するわけではないので、それぞれ“空白”が格納される(これはファイルが2つとも存在する場合でも同じである)。比較内容は例えば“fc”である(図19の1904)。比較結果が等しければ“○”(一致する)、等しくなければ“×”(一致しない)が結果に格納される。何を持って等しい、等しくないとするかは、各比較手段における定義であり、本発明の改ざんチェック装置では比較手段(図5の513)を任意に定義できるため、本結果の定義も柔軟に定義できる。
一方、ファイルが2つ存在しなければステップS1817にて“結果”は“×”となる(図19の1904)。
以上により、原本ファイルとアプリケーションファイルに対して、個々の比較手段による比較(図18)、シナリオに基づいた複数の比較手段による総合結果(図17)、全ファイルに対する比較(図14)の説明を完了する。
上記説明の中で、比較結果は図19の形式でメモリ上に展開したが、この構成があくまで例であることは言うまでもない。
さらに、これらの結果をファイルにレポート出力した例を図20に示す。図20は、1ファイル1行で出力している。また、レポートファイルを出力するにあたり、原本やチェック対象により一意的にレポートファイル名を割り当てる必要がある場合、1332Project属性、1333ExecServer属性の値を利用してファイル名を生成してもよい。またレポートファイルの出力先フォルダとして、1337ReportFolder属性の値を利用する。
2006“tool.jar”は、2003“fc”、2004“size”、2005“create_date”の3つの比較手段により、原本ファイル、アプリケーションファイルのいずれの値も一致しているため、総合結果2001も“○”(一致している)となっている。
一方、2007“view.jar”は、2003“fc”と“create_date”の結果が異なるため、総合結果2001も“×”(一致していない)となっている。
さらに、2008“controle.jar”はアプリケーションファイルが存在していないため、総合結果に“Only_Orgn”(原本ファイルしか存在しない)とマークされている。また、2012“module¥model.jar”は、アプリケーションファイルしか存在していないため、総合結果に“Only_Apl”(アプリケーションファイルしか存在しない)とマークされている。図20のレポート出力が一例であることは言うまでもない。
以上、改ざんチェック装置における改ざんチェック処理の1つの実施例の説明を完了する。
なお、以上の実施例では、比較の一方は、SCMサーバに格納され、原本性が確保された原本ファイルであるという前提で説明した。しかしながら、本発明を利用する環境において、必ずしも原本ファイルが利用できるわけではない。
この様な場合でも、同一のアプリケーションが複数のアプリケーション動作サーバで実行されていれば、相互に比較することができる。
また、本実施例で使用したシナリオ(図13の1301)は、1つの原本ファイル群、1つのアプリケーションファイル群を取得し、1回の比較を行ったが、図14のフローチャートからこれらの処理を繰り返し実施できることは言うまでもない。例えば、まず経理システムの原本ファイル群を取得して、サーバ1にリリースされた経理アプリファイル群を取得し、前記原本ファイルと比較し、さらにサーバ2にリリースされた経理アプリファイル群を取得し、別な比較手段で原本ファイルと比較し、引き続き発注システムの原本ファイルからファイル群を取得し、サーバ3およびサーバ4にリリースされている発注システムのファイル群を取得して比較する、ということを繰り返すことが可能である。
図13においてブロック1302とブロック1303のいずれもアプリケーション動作サーバを設定し、比較することで「少なくとも一方だけが改ざんされた」という状況の発生を発見することができる。
さらに、以上では、2つのファイル群(原本とアプリケーションファイル、2つのアプリケーションファイル)を比較したが、2つ以上のファイル群をいずれか1つを基準に比較することも可能である。この場合、原本ファイルがなくとも全てのアプリケーション動作環境が同一でない限り、何らかの改ざんが成されたとすることで、さらに改ざんチェックの精度を高めることも可能となる。
また、本発明の目的は、以下の処理を実行することによって達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ(またはCPUやMPU等)が記憶媒体に格納されたプログラムコードを読み出す処理である。
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
また、プログラムコードを供給するための記憶媒体としては、次のものを用いることができる。例えば、フロッピー(登録商標)ディスク、ハードディスク、光磁気ディスク、CD−ROM、CD−R、CD−RW、DVD−ROM、DVD−RAM、DVD−RW、DVD+RW、磁気テープ、不揮発性のメモリカード、ROM等である。または、プログラムコードを、ネットワークを介してダウンロードしてもよい。
また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOS(オペレーティングシステム)等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
更に、前述した実施形態の機能が以下の処理によって実現される場合も本発明に含まれる。即ち、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部または全部を行う場合である。
また、コンピュータが読み出したプログラムコードを実行することにより、前述した各実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているOSなどが実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現する場合も含まれる。
この場合、上記プログラムは、該プログラムを記憶した記憶媒体から直接、またはインターネット、商用ネットワーク、若しくはローカルエリアネットワーク等に接続された不図示の他のコンピュータやデータベースなどからダウンロードすることにより供給される。
上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、OS(オペレーティングシステム)に供給されるスクリプトデータ等の形態から成ってもよい。