改ざんチェック装置
【課題】随時変更されるアプリケーション実行環境において、原本性を保証されているファイル群とアプリケーション実行環境のファイル群を比較することを可能とし、不正な改ざんを検出する仕組みを提供する。
【解決手段】ファイルデータの原本性を保証するソフトウェア構成管理システムからアプリケーション動作サーバ上にリリースされたファイルデータの改ざんを検出する改ざんチェック装置３０７において、原本取得手段、チェック対象取得手段、さらに１または複数の比較手段が指定されたシナリオを記憶するシナリオ記憶手段と、シナリオ実行手段とを備え、原本取得手段は、前記ソフトウェア構成管理システムから原本性が保証されたファイルデータ３０８を取得し、チェック対象取得手段は、前記アプリケーション動作サーバ上にリリースされたチェック対象となるファイルデータ３０９を取得し、比較手段による比較結果をレポート３１０する手段と、を有する。
【解決手段】ファイルデータの原本性を保証するソフトウェア構成管理システムからアプリケーション動作サーバ上にリリースされたファイルデータの改ざんを検出する改ざんチェック装置３０７において、原本取得手段、チェック対象取得手段、さらに１または複数の比較手段が指定されたシナリオを記憶するシナリオ記憶手段と、シナリオ実行手段とを備え、原本取得手段は、前記ソフトウェア構成管理システムから原本性が保証されたファイルデータ３０８を取得し、チェック対象取得手段は、前記アプリケーション動作サーバ上にリリースされたチェック対象となるファイルデータ３０９を取得し、比較手段による比較結果をレポート３１０する手段と、を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイルの原本管理とアプリケーション実行環境におけるファイルの改ざんをチェックするシステムに関する。
【背景技術】
【０００２】
近年、ソフトウェアの開発においても内部統制の観点から、開発および開発したシステムの改修に対する要求、承認を管理し、さらに実際に変更したソースコードや実行モジュールと結びつけて統合的に監査することの重要性が認識されてきている。特にソフトウェア構成管理（ＳＣＭ）と呼ばれるシステムも多数製品化され、アプリケーションを実行する環境であるサーバにデプロイ（リリースとも言う）し、デプロイに関する監査証跡まで残すことが可能な製品も存在する。
【０００３】
特開２０００−１４８４５３号公報では、ソフトウェアモジュールの更新履歴を格納し、リリース対象のソフトウェアモジュールを特定するデータを入力し、入力された特定用データに対応する更新履歴データを取得し、さらに更新履歴データに、少なくとも日付，ソフトウェアモジュール名称を付加した実行結果データを出力することにより、ソフトウェアモジュールの更新履歴の管理が容易に行えるソフトウェアモジュールのリリース管理システムを実現している。
【０００４】
特許３８０３００２号公報に記載の発明では、ハードディスク上のデータが不正に改ざんされた場合に備え、監視対象とするデータと、当該データを参照するプログラムを登録し、前記データの更新を監視し、監視対象とするデータを予め待避し、前記データの更新を監視して検出し、当該データを参照するプログラムの実行状態を検出し、前記データの更新が検出されたとき、当該データを参照するプログラムの実行状態が停止中であったときは該更新内容を退避し、実行状態が動作中であったときは退避してあった該データを回復する技術を実現している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０００−１４８４５３号公報
【特許文献２】特許３８０３００２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
特許文献１では、アプリケーションのリリースに関して作業を容易かつ確実に行い、更に監査証跡を残すことを実現している。
【０００７】
しかしながら、一度、実行環境にリリースしたファイル群の監視までは行うことはできない。すなわち、不正なルート、例えばアプリケーションが実行されているサーバに不正侵入し、アプリケーションを構成するファイルの改ざんされた場合まで管理する機能は実現していない。
特許文献２では、予め登録したデータの改ざんを検出することを実現している。
【０００８】
しかしながら、前記の監視は、あくまでバックアップしている更新前のデータとの比較によるものに過ぎず、更新前のデータ自体が原本性を有することをソフトウェア構成管理（ＳＣＭ）ツールなどにより保証するものではない。
【０００９】
更に、予め特定されたデータに対しての監視に限定されているため、アプリケーションを構成する実行ファイルや関連ファイルのように、機能追加や障害対応でアプリケーションのファイル構成が変わるたびに監視対象とするファイルを特定し直す必要があった。また監視方法も、予め実装された方法に限定され、監視方法の拡張は困難であった。
【００１０】
本発明は、アプリケーションの実行形式ファイル、設定ファイル、その他のデータの構成が随時変更される状況において、チェック対象とするファイルの構成を特定することなく、原本性を保証されているファイル群とアプリケーション実行環境のファイル群を比較することを可能とするとともに、比較方法の拡張を柔軟に実現することで、不正な改ざんを検出する仕組みを提供することを課題とする。
【課題を解決するための手段】
【００１１】
ファイルデータの原本性を保証するソフトウェア構成管理システムからアプリケーション動作サーバ上にリリースされたファイルデータの改ざんを検出する改ざんチェック装置において、
【００１２】
原本データを取得する原本取得方法と、チェック対象となるリリースデータを取得するチェック対象取得方法と、前記取得した原本データとリリースデータの比較方法とを定義したシナリオを記憶するシナリオ記憶手段と、
前記シナリオ記憶手段に記憶された前記シナリオを読み込んで実行するシナリオ実行手段とを備え、
【００１３】
前記シナリオには、前記原本取得方法として少なくとも原本取得手段が指定され、前記チェック対象取得方法として少なくともチェック対象取得手段が指定され、前記比較方法として少なくとも１または複数の比較手段が指定され、
前記原本取得手段は、前記ソフトウェア構成管理システムから原本性が保証されたファイルデータを取得し、
前記チェック対象取得手段は、前記アプリケーション動作サーバ上にリリースされたチェック対象となるファイルデータを取得し、
前記１または複数の比較手段は、前記原本性が保証されたファイルデータと前記チェック対象となるファイルデータを比較し、
前記１または複数の比較手段による比較結果をレポートするレポート手段と、を有することを特徴とする改ざんチェック装置。
【発明の効果】
【００１４】
サーバ上で動作しているアプリケーションを構成するファイル群に対しログファイルなどアプリケーションが随時変更するファイルを除外した上で、不正な改ざんがあれば、原本性を保証されているファイル群に基づき検出することを可能とする。また、改ざんの検出方法を外部手段により追加し、シナリオファイルで実行定義するため、検出方法を柔軟に拡張できる。
【図面の簡単な説明】
【００１５】
【図１】改ざんチェック装置、ＳＣＭサーバ、ＳＣＭクライアント、アプリケーション動作サーバの各ハード構成の一例を示すブロック図である。
【図２】本発明の実施形態に関わる改ざんチェック装置、ＳＣＭサーバ、ＳＣＭクライアント、アプリケーション動作サーバのシステム構成の一例を示す図である。
【図３】本発明の実施形態に関わる改ざんチェック装置、ＳＣＭサーバ、ＳＣＭクライアント、アプリケーション動作サーバの動作の概略の流れを説明するための図である。
【図４】ソフトウェア構成管理（ＳＣＭ）ツールのクライアント画面の一例を示す図である。
【図５】改ざんチェック装置の機能ブロックの一例を示す図である。
【図６】シナリオファイルの一例を示す図である。
【図７】除外ファイルを指定する設定ファイルの一例を示す図である。
【図８】メモリ上に展開されたシナリオ構造の一例を示す図である。
【図９】改ざんチェック装置の機能ブロックのうち、原本取得手段の一例を示す図である。
【図１０】図９に記載した原本取得手段と協調して動作するＳＣＭサーバ側原本取得手段を構成する機能ブロックの一例を示す図である。
【図１１】改ざんチェック装置の機能ブロックのうち、チェック対象取得手段の一例を示す図である。
【図１２】図１１に記載したチェック対象取得手段と協調して動作するアプリケーション側ファイル取得手段を構成する機能ブロックの一例を示す図である。
【図１３】チェック対象取得手段、比較手段の設定を含むシナリオファイルの一例を示す図である。
【図１４】改ざんチェック装置で実行する最上位の処理のフローチャートである。
【図１５】ＳＣＭサーバから原本ファイル群を取得するプログラムのフローチャートである。
【図１６】アプリケーション動作サーバからアプリケーションファイル群を取得するプログラムのフローチャートである。
【図１７】原本ファイル群とアプリケーションファイル群を比較するプログラムのフローチャートである。
【図１８】１つの原本ファイルと対応する１つのアプリケーションファイルを比較するプログラムのフローチャートである。
【図１９】比較結果を記録したメモリ上の構造体の一例を示す図である。
【図２０】比較結果のレポートの一例を示す図である。
【発明を実施するための形態】
【００１６】
以下、本発明の実施の形態を、図面を参照して詳細に説明する。
【００１７】
図１は、本発明の実施形態に関わる改ざんチェック装置、ＳＣＭサーバ、ＳＣＭクライアント、アプリケーション動作サーバのシステム構成の一例を示す図である。ＳＣＭクライアント１０１、ＳＣＭサーバ１０２、改ざんチェック装置１０３、アプリケーション動作サーバ１０４、１０５は、ネットワーク１０６を介して相互に接続される。
【００１８】
図２は、改ざんチェック装置、ＳＣＭサーバ、ＳＣＭクライアント、アプリケーション動作サーバの各ハード構成の一例を示すブロック図である。ＣＲＴ２０１と、入力デバイス２０２と、ＣＰＵ２０３と、ＲＡＭ２０４と、ＲＯＭ２０５と、外部記憶装置２０６と、ネットワーク・インタフェース２０７とを備える。
【００１９】
ＣＰＵ２０３は、ＲＯＭ２０５に記憶された制御プログラムを読み出して実行すると共に、情報処理装置を制御する。ＲＡＭ２０４は、データ等を一時記憶するためのバッファやワークエリア等として機能し、またＯＳを含む各種プログラムを実行する作業領域として使用される。
【００２０】
外部記憶装置２０６はハードディスクドライブ等の記憶装置であり、ＯＳやファイル管理システムのプログラムを含む各種プログラム及び各種データの短期的、永続的な記憶装置として使用される。
【００２１】
入力デバイス２０２は、キーボード、マウス等に代表されるユーザ入力機器であり、ＣＲＴ２０１は情報処理装置の処理結果等を表示するための機器である。バス２０８は、上述した各部を互いに接続するシステムバスである。
なお、ＳＣＭサーバ１０２、アプリケーション動作サーバ１０４ならびに１０５においては、ＣＲＴ２０１および入力デバイス２０２は、必須なものではない。
図３は、改ざんチェック装置、ＳＣＭサーバ、ＳＣＭクライアント、アプリケーション動作サーバの関連を簡単な動作例を用いて説明する概略図である。
【００２２】
ＳＣＭクライアント３０１は、図1のＳＣＭクライアント１０１に相当し、ＳＣＭサーバ３０３は、図１の１０２、アプリケーション動作サーバ３０５は、図１のアプリケーション動作サーバ１０４および１０５、改ざんチェック装置３０７は図１の改ざんチェック装置１０３に相当する。
【００２３】
ＳＣＭサーバ３０３は、ソフトウェア構成管理システム（Ｓｏｆｔｗａｒｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ：ＳＣＭシステム）と呼ばれるツールであり、開発しているプログラム（ソースコード）を変更する際に変更する旨の申請および承認のワークフロー管理、変更したプログラム（ソースコード）のバージョン管理、前記申請及び承認のワークフローと実際に変更したプログラム（ソースコード）の関連を保持し、プログラムの変更に関する監査履歴（誰が、いつ、どのような理由で、誰の承認を得て変更をしたのか）を残すことができる。ＳＣＭツールは、１つのアプリケーションを構成するために必要なソースコード一式を「プロジェクト」という単位で管理する。例えば、経理システムを構成するソースコード一式を「経理ソースコード」というプロジェクト名で管理することができる。
【００２４】
図４のＧＵＩ４０１は、ソフトウェア構成管理（ＳＣＭ）ツールのクライアント側ＧＵＩの一例である。画面は大きく３つに分かれており、プロジェクト一覧ウィンドウ４０２、プロジェクト原本表示ウィンドウ４０３、作業領域表示ウィンドウ４０４から構成される。
プロジェクト一覧ウィンドウ４０２は、プロジェクトと呼ばれる単位で管理され、図４の例では３つのプロジェクトが管理されている。
【００２５】
例えば１つのアプリケーションを構成する全てのソースコードを格納することができる。プロジェクト名４０５は、例として「Ｋｅｉｒｉ＿Ｓｏｕｒｃｅ＿Ｃｏｄｅ」（４０７）であり、説明（備考）４０６として「経理システムソースコード管理用プロジェクト」というコメントを付与している。いずれも利用者が当該ＧＵＩ４０１を用いて設定することができる。
【００２６】
プロジェクト原本表示ウィンドウ４０３は、ＳＣＭサーバ３０３（図３）上に格納されている原本ファイル群（ここでは経理システムソースコードのファイル群）の最新の状態を表示している。通常の開発におけるフォルダおよびファイルの構成が、ウィンドウ内にツリー構造としてそのまま表示されている。従って複数の開発者が同時に当該プロジェクトの開発を行う場合であっても、（最新状態を表示さえすれば）同じ表示状態になる。
【００２７】
作業領域表示ウィンドウ４０４の表示内容は、プロジェクト原本表示ウィンドウ４０３とほぼ同一だが、ＳＣＭサーバ３０３（図３）の状態を表しているのではなく、作業領域（通常は開発者などが個人使用するＰＣのローカルのフォルダ）の最新状態が表示されている。この例では、ファイル４０９“ｕｒｉａｇｅ．ｊｓｐ”とファイル４１０“ｓｙｏｕｓａｉ．ｊｓｐ”の２ファイルがチェックアウト（ｃｈｅｃｋｏｕｔ）されている。チェックアウトとは、該ローカルＰＣで開発者が前記２ファイルを作業している状態である。他の開発者が使用できないように排他的ロックすることが多いが、開発者あるいはシステム管理者（ＳＣＭサーバ３０３の管理者）が、オプションにより排他的か非排他的か選択することができるＳＣＭツールも存在する。
【００２８】
ファイル４１０“ｓｙｏｕｓａｉ．ｊｓｐ”には“＊”記号が表示されており、チェックアウトした後、ローカルＰＣの作業領域で編集し、ＳＣＭサーバ３０３の原本とは差分が生じていることを表している。差分をＳＣＭサーバ３０３の原本に反映し、変更したものを新たに原本とするためには、開発者はチェックイン（ｃｈｅｃｋｉｎ）という操作をする。
【００２９】
さらに、ＳＣＭツールはプログラム（ソースコード）だけではなく、バイナリデータ（実行ファイルやワープロ文書、データ）、ｈｔｍｌファイル、ｈｔｍｌファイルで表示する画像データなど、アプリケーションを構成するファイル一式を管理することも可能であり、図４の例では、ソースコード側のプロジェクト（ＧＵＩ４０１のプロジェクト一覧ウィンドウ４０２）に対応して３つのプロジェクトが管理されている。ただしこれはあくまで例であり、ソースコードのみ管理する場合、実行ファイルのみを管理する場合などがあってもよい。
【００３０】
例えば、前述の経理システムを構成するソースコード一式をコンパイル、あるいはビルドしてアプリケーションとして動作可能なファイル一式（リリースファイル、リリースデータ）に変換した後、本図ではプロジェクト名４１１「ＫｅｉｒｉＰｒｏｊｅｃｔ」、説明（備考）４１２「経理システムリリース用プロジェクト」というプロジェクト名で管理する。
【００３１】
バイナリデータの原本を更新する場合も、ソースコードの場合と同様に一度チェックアウトし、外部でコンパイラ、ビルド等されたファイで上書きする。図４のファイル４１３“ｔｏｏｌ．ｊａｒ”がローカルＰＣの作業領域上で、“ｔｏｏｌ．ｊａｒ”が変更された状態にあることを示している。このファイルをチェックインすることで、ＳＣＭサーバ３０３上の“ｔｏｏｌ．ｊａｒ”の原本を更新する。
【００３２】
デプロイ（リリース）用に設定されたプロジェクト４１１“ＫｅｉｒｉＰｒｏｊｅｃｔ”では、更新されたファイルがチェックインされると、ＳＣＭサーバ３０３はこのファイルを指定されたアプリケーション動作サーバにデプロイするように機能設定できる製品もある。
【００３３】
説明を図３に戻すと、「デプロイ実施」は、前述のようにアプリケーションの一部ファイルが変更され、デプロイされ、改ざんチェックされる動作の概略図である。
【００３４】
ＳＣＭクライアント３０１には、アプリケーションを構成するファイル一式を管理するワークスペース３０２があり、変更しビルドし直したファイルは開発者によりワークスペースに上書きされる。 開発者が、前記上書きしたファイルを指定して、ＳＣＭサーバ３０３にチェックインすると、登録された原本ファイル群であるリポジトリ３０４は更新される。ここで更新とは、単に既存ファイルの変更だけではなく、存在しないファイルの追加、既存ファイルの削除の処理も含む。
【００３５】
ＳＣＭサーバ３０３は、前記チェックインされたファイルがあると、自動的にあるいはＳＣＭクライアントのユーザ操作によりデプロイを実施する。デプロイは、前記チェックインされたファイルの更新情報をアプリケーション動作サーバ３０５に送信し、アプリケーションファイル３０６を更新する処理である。前述と同様、更新とは、変更、追加、削除を含む。
【００３６】
図３の改ざんチェック装置３０７は、改ざんチェック対象のアプリケーションを構成するファイル（原本ファイル）をＳＣＭサーバ３０３の指定されたプロジェクトのリポジトリ３０４から抽出する。さらに対応するアプリケーションファイル３０６をアプリケーション動作サーバから抽出する。
【００３７】
改ざんチェック装置３０７に抽出された原本ファイル３０８と抽出されたアプリケーションファイルは、同じフォルダ構成（ルートフォルダ配下の階層構造など）からなっている。すなわち、改ざんチェック装置３０７のハードディスク内に指定された異なる２つのフォルダを各々のルートフォルダとし、その配下は同じはずである。この２つのルートフォルダ配下に格納されたファイル群から、改ざんチェック装置３０７は差分を検出する。以上の動作は、シナリオ記憶手段３１０に記憶されているシナリオに基づいて実行される。
【００３８】
図３では、ＳＣＭクライアント３０１、ＳＣＭサーバ３０３、アプリケーション動作サーバ３０５、改ざんチェック装置３０７の全てを異なる装置として記載しているが、これらの全てあるいは一部が同一の装置上に構成されていても良い。
【００３９】
図５は改ざんチェック装置の機能ブロックの一例を示す図である。改ざんチェック装置の機能ブロックは、大きく分けてシナリオ読み込み手段５０１とシナリオ実行手段５０２に分かれている。またシナリオ実行手段５０２は、原本取得手段５０３、チェック対象取得手段５０４、比較手段５０５、レポート手段５０６を制御する。
【００４０】
シナリオ読み込み手段５０１で読み込まれたシナリオファイル５０７は、メモリ上に展開されたシナリオ５１０としてシナリオ実行手段５０２で利用しても良い。図８は、後述のフローチャートを説明する際に使用する図１３のシナリオ１３０１をメモリ上に展開した一例である。
【００４１】
メモリ上の構成全体を管理するシナリオルート８０１を“Ｓｃｅｎａｒｉｏ”で表している。それ以下、シナリオファイル内で表現されるブロック（後述）をブロック８０２とその属性と値のペアを図８のブロック内容８０３として記載している。同様に、ブロック８０４、ブロック内容８０５、ブロック８０６、ブロック内容８０７として展開される。
【００４２】
図５では、シナリオ実行手段は、原本データ（原本ファイルデータ）を取得するためにシナリオ実行手段に組み込まれた原本取得手段５０３あるいは外部コマンドとして呼び出される原本取得手段５１１のいずれかを実行する。また、チェック対象を取得するためにシナリオ実行手段に組み込まれたチェック対象取得手段５０４あるいは外部コマンドとして呼び出されるチェック対象取得手段５１２のいずれかを実行する。さらに、原本とチェック対象を比較するためにシナリオ実行手段に組み込まれた比較手段５０５あるいは外部コマンドとして呼び出される比較手段５１３のいずれかを実行する。比較手段の場合には、シナリオ実行手段に組み込まれたもの、外部コマンドの双方あわせて、１または複数の比較手段を実行するよう、シナリオにて定義することができる。
【００４３】
ここでシナリオファイル５０７について説明する。シナリオファイル５０７は、図６にその一例を示している。図６は、外部ツールを呼び出さないシナリオの例である。
【００４４】
図６のシナリオファイル６０１には、５つのブロック６０２〜６０６が記載されている。また、行頭に「＃」があるコメント行６２１は、コメントとしてシナリオを実行する際には無視する。
【００４５】
ブロックには２種類有り、ブロック６０２はブロック定義行６２２によりコピーブロック、ブロック６０４はブロック定義行６４１によりコンペアブロックとして定義される。
コピーブロックは、ＳＣＭサーバやアプリケーション動作サーバから改ざんチェックをするために必要なファイル群を取得するための定義である。
【００４６】
コピーブロック６０２の定義は、Ｔｙｐｅ属性６２３が“Ｏｒｉｇｉｎａｌ“であり、原本性が保証されているＳＣＭサーバからファイル群を取得するための定義を記載している。詳細にはＳｅｒｖｅｒ属性６２４により”ＳＣＭ“というネットワーク上のサーバにあるＳＣＭサーバから、Ｐｒｏｊｅｃｔ属性６２５により”ＫｅｉｒｉＲｅｌｅａｓｅＰｒｏｊｅｃｔ“という経理アプリケーションが格納されているリポジトリの内容を抽出し、ＷｏｒｋＦｏｌｄｅｒ属性６２６により改ざんチェック装置の”Ｃ：￥Ｃｏｍｐａｒｅ￥Ｏｒｉｇｉｎａｌ￥Ｋｅｉｒｉ“フォルダに前記抽出した原本ファイル５１４（図５）を格納するように指示するシナリオである。
【００４７】
また、ブロック６０３の定義は、６３１よりコピーブロックとして定義されているが、Ｔｙｐｅ属性６３２が“Ｅｘｅｃｕｔｉｏｎ“であり、アプリケーション動作サーバからファイル群を取得するための定義を記載している。詳細にはＳｅｒｖｅｒ属性６３３により”￥￥Ｓｒｖ０１￥ｃ：￥Ｋｅｉｒｉ“というネットワーク上のサーバおよびフォルダから経理アプリケーションファイルを抽出し、ＷｏｒｋＦｏｌｄｅｒ属性６３４により改ざんチェック装置の”Ｃ：￥Ｃｏｍｐａｒｅ￥Ｅｘｅｃ￥Ｋｅｉｒｉ０１“フォルダに前記抽出したアプリケーションファイル５１５（図５）を格納するように指示するシナリオである。さらにＥｘｃｌｕｄｅＦｉｌｅｓ属性６３５により除外ファイルとして”Ｅｘｃｌｕｄｅ．ｄｅｆ”ファイルが指定され、ファイルのフルパスを文字列と見なした場合に、該ファイルに記載された文字列パターンのいずれかを含む場合には、改ざんチェックシステムの処理対象として抽出しない（改ざんチェックをしない）ファイルとなる。図５では除外ファイル５０８、除外ファイル５０９としてシナリオファイル５０７から指定している。図７に除外ファイルの一例を図示する。
【００４８】
図７の除外ファイル７０１には、改行コードで区切られた３つのパターンが定義されている。パターン７０２はフルパス中に“Ｌｏｇｆｏｌｄｅｒ￥＊．ｌｏｇ”というパターンが現れた場合には、そのファイルは前述の通り、改ざんチェックシステムの処理対象として抽出されない。
【００４９】
ここで“＊”は、正規表現のワイルドカードを意味している。例えば“Ｃ：￥Ｋｅｉｒｉ￥ｔｅｍｐ￥Ｌｏｇｆｏｌｄｅｒ￥２０１００８２０．ｌｏｇ”が、そのパターンを満たしている。パターン７０３は“．ｂａｋ”を、パターン７０４は“．ｃｏｎｆ”を同様に定義している。
【００５０】
ここで、パターン定義として正規表現およびワイルドカードを説明したのは、あくまで一例である。最も単純な例としては文字列の部分一致、ファイル名の完全一致、さらに正規表現以外のパターンマッチング手法などを利用しても良い。また、除外ファイルをシナリオファイルの外部定義としたが、これは運用におけるメンテナンス性を考慮したものであり、実際の用途に応じてシナリオファイルの中に記載するようにしても良い。また、単なるパターンマッチングだけではなく、スクリプト言語などによる簡単な判定ツールにより、除外ファイルのフィルタリングを行っても良い。
【００５１】
ここで説明を図５に戻す。図５の比較手段５０５は、図６のコンペアブロック６０４のシナリオを実行する手段である。コピーブロック６０２およびコピーブロック６０３で、改ざんチェック装置に抽出したファイル群、すなわちＷｏｒｋＦｏｌｄｅｒ属性６２６で指定された”Ｃ：￥Ｃｏｍｐａｒｅ￥Ｏｒｉｇｉｎａｌ￥Ｋｅｉｒｉ“とＷｏｒｋＦｏｌｄｅｒ属性６３４で指定された”Ｃ：￥Ｃｏｍｐａｒｅ￥Ｅｘｅｃ￥Ｋｅｉｒｉ０１“の２つのフォルダ配下のファイル群を比較する。比較結果はレポート手段５０６からレポート５１６として出力される。
【００５２】
ブロック６０４は、６４１によりコンペアブロックの定義であるが、記載されているＰｒｏｊｅｃｔ属性６４２とＥｘｅｃＳｅｒｖｅｒ属性６４３は、例えばレポートファイルを生成する際に、原本（ＳＣＭサーバのプロジェクト名：“ＫｅｉｒｉＲｅｌｅａｓｅＰｒｏｊｅｃｔ”）とアプリケーション動作サーバ名（“Ｓｒｖ０１“）およびレポートした日時などを結合してファイル名とし、他のレポートと一意的に区別するために使用する目的で付与した属性である。レポートファイル名を一意的に生成する方法としては、他の属性の値の部分文字列を利用するなど、他の方法も考えられ、前述の方法はあくまで一例に過ぎない。さらにＯｒｉｇｉｎａｌＦｏｌｄｅｒ属性６４４は改ざんチェック時の原本性を保証するファイル群を格納するフォルダのルートを定義する。ＥｘｅｃＦｏｌｄｅｒ属性６４５は改ざんチェックのチェック対象となるアプリケーションファイル群を格納するフォルダのルートを定義する。
【００５３】
以下の例では、外部手段を利用することを前提に説明するが、もちろんこれは実施形態の一例であることは言うまでもない。外部手段を利用することを前提とするため、機能ブロックを図９〜図１２を予め説明する。
【００５４】
図９の原本取得手段９０１は、改ざんチェック装置上の機能ブロックの一部であり、原本抽出手段９０２、原本受信外部手段９０３、原本不要ファイル除外手段９０４から構成されており、原本不要ファイル除外手段９０４は除外ファイル設定９０５を参照して動作する。
【００５５】
原本抽出手段９０２は、ＳＣＭサーバの指定のリポジトリの指定のプロジェクト（例えば“ＫｅｉｒｉＰｒｏｊｅｃｔ”）の原本ファイル１００６を抽出する。ただし、これは構成の一例であり、原本抽出手段９０２は、図１０のＳＣＭサーバ側原本抽出手段１００２に要求を送り、該ＳＣＭサーバ側原本抽出手段１００２が、原本ファイル１００６を抽出するように機能しても良い。例えば原本抽出手段９０２がＳＣＭ製品のクライアント機能として提供されている場合、改ざんチェック装置にも、前者のようにＳＣＭクライアントをインストールしなければならないが、原本抽出手段９０２からＳＣＭサーバ側原本抽出手段１００２を呼出し、ＳＣＭサーバ側原本抽出手段１００２をＳＣＭ製品のクライアント機能により構成すれば、改ざんチェック装置にＳＣＭクライアントをインストールする必要はなくなる。
【００５６】
次に、原本受信外部手段９０３は、原本抽出手段９０２で抽出した原本ファイル１００６（図１０）を、改ざんチェック装置側に転送する際の受信機能を有する。
【００５７】
前述のように、原本抽出手段９０２がＳＣＭサーバ側原本抽出手段１００２に要求せずに、単独で動作する場合には、原本受信外部手段９０３は不要となる。ＳＣＭサーバ側原本抽出手段１００２に要求してＳＣＭサーバ側で原本ファイルを抽出した場合には、原本受信外部手段９０３は、独自に原本ファイル１００６を改ざんチェック装置に転送するか、ＳＣＭサーバ側原本送信手段と協調して原本ファイル１００６の送受信を行うかのいずれかである。
【００５８】
前者の例としては、例えばＳＣＭサーバにおいて抽出された原本を格納しているフォルダがネットワーク上の共有フォルダとして公開されているのであれば、ＯＳ標準のコピーコマンドを使用すればよい。後者の例としては、市販のデータ転送ソフトウェア製品を利用することも可能である。この場合、データの転送効率を良くするため多数のファイルを１つに結合する、転送中に改ざんされないようにするため暗号化する、などの機能が容易に利用できる。
【００５９】
最後に、原本不要ファイル除外手段９０４は、前述の受信したファイルのうち、改ざんチェック対象ではないファイルと改ざんチェック対象のファイルをフィルタリングする手段である。
【００６０】
不要なファイルを削除しても良いし、不要なファイルあるいは必要なファイルのいずれかを他のフォルダに移動しても良い。この場合、除外ファイル設定９０５を参照する。除外ファイルについては、既に図７で説明しているため、ここでは省略する。
【００６１】
原本において、不要なファイルを除外する目的としては、各種あるＳＣＭ製品の中には、原本を抽出し作業フォルダを構成する際に、原本管理用の隠しファイルを多数作成する製品も存在し、その場合には該原本管理用の隠しファイルは改ざんチェック対象から削除したい、などの理由による。もちろん他の目的で使用することも可能である。
【００６２】
あるいは、除外ファイル設定１００５に基づきＳＣＭサーバ側原本不要ファイル除外手段１００３により、原本ファイルを改ざんチェック装置に転送する前に不要なファイルを除外しても良い。この場合、転送するファイル群は、原本ファイルから不要ファイル医を除外したファイル群１００７となる。予め除外するファイルが多ければ、ネットワーク負荷も押さえることが可能となる。
以上、図９と図１０の機能ブロックにより改ざんチェック処理に必要な原本ファイルが改ざんチェック装置上に格納される。
【００６３】
しかし、あくまで本機能ブロックの構成は一例に過ぎない。例えば、前述のコピーコマンドを使用する例において、コピーコマンド自身がファイルのフィルタリング機能を有するものもある。この場合、原本受信外部手段９０３および原本不要ファイル除外手段９０４は単一の実行コマンドとなる。また改ざんチェック装置上にＳＣＭクライントをインストールし、ＳＣＭクライアントが１つのコマンドとして原本取得手段９０１の全ての機能を含んでいる場合もある。この場合はさらにＳＣＭサーバ側においても全ての機能はＳＣＭサーバに組み込まれていてもよい。
【００６４】
このように、図９と図１０は様々な構成が考えられるが、詳細の動作をフローチャート図１４〜図１８を説明する際には、図９と図１０の機能ブロックを例としてそのまま使用する。
次に図１１と図１２を説明する。
【００６５】
図１１のチェック対象種特外部手段１１０１は、改ざんチェック装置上の機能ブロックの一部であり、チェック対象抽出手段１１０２、チェック対象受信外部手段１１０３、チェック対象不要ファイル除外手段１１０４から構成されている。
【００６６】
図１１の各手段は図９の各手段と次のように対応しており、ほぼ同一の機能を有している。すなわち、チェック対象抽出手段１１０２と原本抽出手段９０２、チェック対象受信外部手段１１０３と原本受信外部手段９０３、チェック対象不要ファイル除外手段１１０４と原本不要ファイル除外手段９０４が対応している。
【００６７】
また、図１２のアプリケーション側ファイル抽出手段１２０１はチェック対象種特外部手段１１０１（図１１）と協調して動作するアプリケーション動作サーバ上の機能ブロックであり、アプリケーション側ファイル抽出手段１２０２、アプリケーション側不要ファイル除外手段１２０３、アプリケーション側ファイル送信手段１２０４から構成されている。
【００６８】
図１２の各手段は図１０の各手段と次のように対応しており、ほぼ同一の機能を有している。すなわち、アプリケーション側ファイル抽出手段１２０２とＳＣＭサーバ側原本抽出手段１００２、アプリケーション側不要ファイル除外手段１２０３とＳＣＭサーバ側不要ファイル除外手段１００３、アプリケーション側ファイル送信手段１２０４とＳＣＭサーバ側原本送信手段１００４が対応している。
【００６９】
対応しているとはいえ、図１１と図１２の機能ブロックの関係は、図９と図１０の関係とは異なる点がいくつかある。例えば、図１０はＳＣＭサーバであるため、図９にＳＣＭクライアントを導入して原本ファイルの抽出を実現することができる。一方、図１２のアプリケーション動作サーバでは、アプリケーションファイルを抽出する際に、ほぼそのフォルダ構成を利用すればよいことが多く、必ずしも抽出処理が必要ではない。
【００７０】
一方で、図１２のアプリケーション動作サーバでは、例えばＷｅｂアプリケーションサーバ（ＷＡＳ）がアプリケーションファイルを管理しており、アプリケーションファイルを抽出する前提として、Ｗｅｂアプリケーションサーバを停止させるなどの前処理および抽出後、Ｗｅｂアプリケーションサーバを再起動する処理が必要な場合がある。
【００７１】
図１１と図１２にも図９と図１０に関しての説明を実施した際に述べたのと同様、様々な構成が考えられるが、詳細の動作をフローチャート図１４〜図１８を説明する際には、図１１と図１２の機能ブロックを例としてそのまま使用する。
次に、改ざんチェックシステムの詳細の動作を図１３〜図１８を用いて説明する。
図１４は改ざんチェック装置で実行する最上位の処理のフローチャートである。
【００７２】
ステップＳ１４０１では、シナリオファイルを読み込みメモリ上に展開する。シナリオの例として図１３シナリオ１３０１を展開すると、メモリ上の展開結果の図８のようになる。
【００７３】
ステップ１４０２からステップＳ１４０７では、シナリオに記述されたブロック（１または複数）を先頭から１つずつ順に処理する。 ステップＳ１４０３では、ブロックの１つに着目（取得）する。
ステップＳ１４０４では、着目しているブロックが“Ｃｏｐｙ”ブロックか“Ｃｏｍｐａｒｅ”ブロックかで処理を分岐する。
【００７４】
“Ｃｏｐｙ”ブロック１３１１の場合、ステップＳ１４０５Ｃｏｐｙブロック処理手段に進む。Ｔｙｐｅ属性が“Ｏｒｉｇｉｎａｌ”（例：ブロック１３０２のＴｙｐｅ属性１３１２）であれば図１５（図５の原本取得手段５０３または原本取得手段５１１）が詳細のフローチャートである。Ｔｙｐｅ属性が“Ｅｘｅｃｕｔｉｏｎ”（例：ブロック１３０３のＴｙｐｅ属性１３２２）であれば図１６（チェック対象取得手段５０４あるいはチェック対象取得手段５１２に対応）が詳細のフローチャートである。
【００７５】
“Ｃｏｍｐａｒｅ”ブロックの場合には、ステップＳ１４０６に進む。Ｃｏｍｐａｒｅブロック処理手段（図５の比較手段５０５または比較手段５１３に対応）は、図１７および図１８のフローチャートで説明する。
【００７６】
ステップＳ１４０８では、ステップＳ１４０６における原本ファイルとアプリケーションファイルの比較結果を、出力する（図５のレポート手段５０６に対応）。詳細の説明としては、図１８のフローチャートの処理において図１９の構造を生成する方法について説明する。図２０は、図１９の構造をファイルに出力した形式の一例であり、後述する。
【００７７】
図１５は、ＳＣＭサーバから原本ファイル群を取得するプログラムである。このフローチャートを実行するのは、前述したようにＴｙｐｅ属性１３１２のようにＴｙｐｅ属性の値が“Ｏｒｉｇｉｎａｌ”である場合である。フローチャート１５０１が改ざんチェック装置、フローチャート１５０２がＳＣＭサーバにおけるプログラムの処理であり、協調して動作する。
【００７８】
ステップＳ１５０３原本抽出手段は、Ｓｅｒｖｅｒ属性１３１３の“ＳＣＭ”上、Ｐｒｏｊｅｃｔ属性１３１４の“ＫｅｉｒｉＰｒｏｊｅｃｔ”に格納されている原本ファイルを抽出するようステップＳ１５０７ＳＣＭサーバ側原本抽出手段に要求する（リクエスト１５１１）。ステップＳ１５０７ＳＣＭサーバ側原本抽出手段は要求通り、ＳＣＭサーバに格納されているプロジェクト“ＫｅｉｒｉＰｒｏｊｅｃｔ”から原本ファイルを抽出し、ＷｏｒｋＦｏｌｄｅｒ属性１３１５に指定された改ざんチェック装置側のフォルダ“Ｃ：￥Ｃｏｍｐａｒｅ￥Ｏｒｉｇｉｎａｌ￥Ｋｅｉｒｉ”に格納する。
【００７９】
ＳＣＭサーバ側で不要なファイルを除外するように設定されている場合には、ステップＳ１５０８ＹｅｓによりステップＳ１５０９ＳＣＭサーバ側原本不要ファイル除外手段に進み、改ざんチェックの処理対象として不要なファイルが除外される。実際に、ファイルを削除する、別のフォルダに移動する、あるいはファイル自体は元の位置に存在するが改ざんチェック時に利用しないよう一覧表に残すなど、除外方法は、物理的なもの、論理的（仮想的）なもの限定しない。その後、ステップＳ１５１０ＳＣＭサーバ側原本送信手段に進む。
【００８０】
ＳＣＭサーバ側で不要なファイルを除外するように設定されていない場合には、ステップＳ１５０８ＮｏによりステップＳ１５１０ＳＣＭサーバ側原本送信手段に進む。
【００８１】
ステップＳ１５１０ＳＣＭサーバ側原本送信手段では、ステップＳ１５０７ＳＣＭサーバ側原本抽出手段で抽出したファイルを、ＳＣＭサーバ側から改ざんチェック装置側に送信する。ステップＳ１５０９ＳＣＭサーバ側原本不要ファイル除外手段を実行した場合には不要ファイルを除外した残りのファイルを送信する（送信１５１２）。
送信されたファイルは、改ざんチェック装置側においてステップＳ１５０４原本受信外部手段により受信される。
【００８２】
次に改ざんチェック装置側で不要なファイルを除外するように設定されている場合には、ステップＳ１５０５ＹｅｓによりステップＳ１５０６原本不要ファイル除外手段に進み、改ざんチェックの処理対象として不要なファイルが除外される。実際に、ファイルを削除する、別のフォルダに移動する、あるいはファイル自体は元の位置に存在するが改ざんチェック時に利用しないよう一覧表に残すなど、除外方法は、物理的なもの、論理的（仮想的）なもの限定しないのはステップＳ１５０９ＳＣＭサーバ側原本不要ファイル除外手段と同様である。これにより図１５のフローチャートを完了し、呼出側である図１４のステップＳ１４０５Ｃｏｐｙブロック処理手段の終了時点に戻る。
【００８３】
改ざんチェック装置側で不要なファイルを除外するように設定されていない場合には、図１５のステップＳ１５０５Ｎｏによりフローチャートを完了し、呼出側である図１４のステップＳ１４０５Ｃｏｐｙブロック処理手段の終了時点に戻る。
【００８４】
なお、図１５のフローチャートでは、ステップＳ１５０８とステップＳ１５０５により、原本ファイルから不要ファイルを除外する処理が、ＳＣＭサーバ側か改ざんチェック装置側か判定しているが、このような判定せず一方に固定的に実装する、あるいは両方で（同一、あるいは異なる除外設定で）除外処理をする、などの実装が可能であることは言うまでもない。その他、図１５は様々な実現方法があり、本フローチャートは、原本ファイルをＳＣＭサーバから抽出する実装の一例に過ぎない。
【００８５】
図１６は、アプリケーション動作サーバからアプリケーションファイル群を取得するプログラムである。このフローチャートを実行するのは、前述したようにコピーブロック１３２１のＴｙｐｅ属性１３２２のようにＴｙｐｅ属性の値が“Ｅｘｅｃｕｔｉｏｎ”である場合である。フローチャート１６０１が改ざんチェック装置、フローチャート１６０２がアプリケーション動作サーバにおけるプログラムの処理であり、協調して動作する。
【００８６】
ステップＳ１６０３チェック対象抽出手段は、Ｓｅｒｖｅｒ属性１３２３の値￥￥Ｓｒｖ０１￥ｃ：￥Ｋｅｉｒｉ（サーバ名￥フォルダ名）に格納されているアプリケーションファイルを抽出するようステップＳ１６０７アプリケーション側ファイル抽出手段に要求する（リクエスト１６１１）。ステップＳ１６０７アプリケーション側ファイル抽出手段は要求通り、アプリケーション動作サーバ“￥￥Ｓｒｖ０１”のフォルダ“ｃ：￥Ｋｅｉｒｉ”からアプリケーションファイルを抽出する。
【００８７】
アプリケーション動作サーバ側で不要なファイルを除外するように設定されている場合には、ステップＳ１６０８ＹｅｓによりステップＳ１６０９アプリケーション側不要ファイル除外手段に進み、改ざんチェックの処理対象として不要なファイルが除外される。この際、除外ファイル設定としては、ＥｘｃｌｕｄｅＦｉｌｅｓ属性１３２５で定義された値“Ｅｘｃｌｕｄｅ．ｄｅｆ”を設定ファイル名として利用する。実際に、ファイルを削除する、別のフォルダに移動する、あるいはファイル自体は元の位置に存在するが改ざんチェック時に利用しないよう一覧表に残すなど、除外方法は、物理的なもの、論理的（仮想的）なもの限定しない。その後、ステップＳ１６１０アプリケーション側ファイル送信手段に進む。
【００８８】
アプリケーション動作サーバ側で不要なファイルを除外するように設定されていない場合には、ステップＳ１６０８ＮｏによりステップＳ１６１０アプリケーション側ファイル送信手段に進む。
【００８９】
ステップＳ１６１０アプリケーション側ファイル送信手段では、ステップＳ１６０７アプリケーション側ファイル抽出手段で抽出したファイルを、アプリケーション動作サーバ側から改ざんチェック装置側に送信する。実際の送信方法としては、ｓｅｎｄ属性１３２７に定義された“ｓｅｎｄ．ｅｘｅ”を利用する。ステップＳ１６０９アプリケーション側不要ファイル除外手段を実行した場合には不要ファイルを除外した残りのファイルを送信する（送信１６１２）。
【００９０】
送信されたファイルは、改ざんチェック装置側においてステップＳ１６０４チェック対象受信外部手段により受信される。実際の受信方法としては、ｒｅｃｅｉｖｅ属性１３２６に定義された“ｒｅｃｅｉｖｅ．ｅｘｅ”を利用する。受信されたファイル群は、ＷｏｒｋＦｏｌｄｅｒ属性１３２４に指定された値“Ｃ：￥Ｃｏｍｐａｒｅ￥Ｅｘｅｃ￥Ｋｅｉｒｉ０１”に格納する。
【００９１】
次に改ざんチェック装置側で不要なファイルを除外するように設定されている場合には、ステップＳ１６０５ＹｅｓによりステップＳ１６０６アプリケーション側不要ファイル除外手段に進み、改ざんチェックの処理対象として不要なファイルが除外される。
【００９２】
実際に、ファイルを削除する、別のフォルダに移動する、あるいはファイル自体は元の位置に存在するが改ざんチェック時に利用しないよう一覧表に残すなど、除外方法は、物理的なもの、論理的（仮想的）なもの限定しないのはステップＳ１６０９ＳＣＭサーバ側原本不要ファイル除外手段と同様である。これにより図１６のフローチャートを完了し、呼出側である図１４のステップＳ１４０５Ｃｏｐｙブロック処理手段の終了時点に戻る。
【００９３】
改ざんチェック装置側で不要なファイルを除外するように設定されていない場合には、図１６のステップＳ１６０５Ｙｅｓによりフローチャートを完了し、呼出側である図１４のステップＳ１４０５Ｃｏｐｙブロック処理手段の終了時点に戻る。
【００９４】
なお、図１６のフローチャートでは、ステップＳ１６０８とステップＳ１６０５により、アプリケーションファイルから不要ファイルを除外する処理が、アプリケーション動作サーバ側か改ざんチェック装置側か判定しているが、このような判定せず一方に固定的に実装する、あるいは両方で（同一、あるいは異なる除外設定で）除外処理をする、などの実装が可能であることは言うまでもない。その他、図１６は様々な実現方法があり、本フローチャートは、アプリケーション動作に存在するアプリケーションファイルを抽出する実装の一例に過ぎない。
【００９５】
図１７は、原本ファイル群とアプリケーションファイル群を比較するプログラムのフローチャートである。ステップＳ１７０１では、全ファイルの比較結果を格納するメモリ上の構造のルートを作成する。これは、図１９の比較結果情報１９０１で表される。図１９および図２０については、図１７、図１８と会わせて随時説明する。本フローチャートは例えば、シナリオファイル１３０１（図１３）のコンペアブロック１３０４（ブロック１３３１の値によりコンペアブロックと定義）に従って動作する。
【００９６】
ステップＳ１７０２からステップＳ１７１１は、原本ファイル側を中心として、対応するアプリケーションファイルの存在、内容、属性などをチェックする繰り返し処理である。
【００９７】
ステップＳ１７０３では、チェック対象とする原本ファイルから１つを取り出し着目する。原本ファイルは図１３の例では、１３３４ＯｒｉｇｉｎａｌＦｏｌｄｅｒ属性の値“Ｃ：￥Ｃｏｍｐａｒｅ￥Ｏｒｉｇｉｎａｌ￥Ｋｅｉｒｉ”に格納されている。以下の説明では、例として図２０の対象２００６“ｔｏｏｌ．ｊａｒ”に着目する。ステップＳ１７０４では、ステップＳ１７０３で着目したファイル（原本と比較対象）の比較結果を格納する総合結果１９０３（図１９）を生成する。項目「対象」に着目中の対象“ｔｏｏｌ．ｊａｒ”を格納する。
【００９８】
次にステップＳ１７０５では、着目中の原本ファイルに対応するアプリケーションファイルが存在すれば取得する。本ファイルは図１３の例では、１３３５ＥｘｅｃＦｏｌｄｅｒ属性の値“Ｃ：￥Ｃｏｍｐａｒｅ￥Ｅｘｅｃ￥Ｋｅｉｒｉ０１”に格納されている。
【００９９】
ステップＳ１７０６からステップＳ１７０９は、前述で着目した原本ファイル（例では“ｔｏｏｌ．ｊａｒ”）と対応するアプリケーションファイルを比較する処理であり、ループは、シナリオで指定された比較手段のそれぞれを順に処理するための繰り返し制御である。シナリオファイル１３０１の例では、比較手段として１３３７，１３３８，１３３９の３つが定義されている。
【０１００】
原本ファイルとアプリケーションファイル、シナリオで指定された比較手段が決定し、ステップＳ１７０７（詳細は図１８のフローチャート）にて実際の比較が行われる。比較方法の詳細は図１８で説明するが、比較処理は原本ファイルに対応するアプリケーションファイルが存在しなくても実行可能であるか、あるいは比較できない旨を返す。図１９の例では、“ｔｏｏｌ．ｊａｒ”に対して、まず比較ツール“ｆｃ”が実行され、その結果が図１９の比較結果１９０４となり、ステップＳ１７０８で総合結果１９０３に関連付けられる。同様に、“ｓｉｚｅ”，“ｃｒｅａｔｅ＿ｄａｔｅ”が順に実行され、その結果が比較結果１９０５，比較結果１９０６となり、総合結果１９０３に関連付けられる。ステップＳ１７１０では、３つの比較内容１９０４，１９０５，１９０６が全て“○”（一致している）ため、１９０３の総合結果も“○”（一致している）となる。すなわち“ｔｏｏｌ．ｊａｒ”に対する総合結果は、図１９の総合結果１９０２のようになる。
【０１０１】
同様に，図１９では例として“ｖｉｅｗ．ｊａｒ”に対してステップＳ１７０４からステップＳ１７０９を実行した結果が図１９の総合結果１９０７を得る。総合結果１９０２および総合結果１９０７は，いずれも比較結果情報１９０１に関連付けられる（格納される）。“ｖｉｅｗ．ｊａｒ”は、“ｆｃ”と“ｃｒｅａｔｅ＿ｄａｔｅ”の比較結果が“×”（一致しない）ので、総合結果１９０８も“×”（一致しない）とされている。以上の処理が全ての原本ファイルに対して繰り返される。
【０１０２】
さて、一方、アプリケーションファイル群には含まれるが、原本ファイル群には含まれないファイル，すなわち原本ファイルに非対応のアプリケーションファイルが存在する可能性がある。これらのファイルを処理するのが、ステップＳ１７１２からステップＳ１７２０である。まず、ステップＳ１７１２では、原本ファイルに非対応のアプリケーションファイルを収集する。
【０１０３】
ステップＳ１７１３からステップＳ１７２０のループは、アプリケーションファイル側に着目して比較していること、比較対象である原本ファイルが存在しないことが最初から明確であることを除き、ステップＳ１７０２からステップＳ１７１１のループ処理と同じである。
【０１０４】
ステップＳ１７１４において、非対応アプリケーションファイルの１つに着目する。ステップＳ１７１６において、非対応アプリケーションのみで比較処理（詳細は図１８）を実施し、ステップＳ１７１７では比較内容を総合結果に関連付ける（格納する）。原本ファイルが存在しないため、ステップＳ１７１９での総合結果は、“×”（一致しない）である。最後に前述の総合結果を図１９の１９０１比較情報結果に関連付ける（格納する）。
【０１０５】
全ての非対応のアプリケーションファイルに対してＳ１７１３からＳ１７２０のループで制御された処理を完了したら、図１７の処理、すなわち図１４のステップ１４０６Ｃｏｍｐａｒｅブロック処理手段を完了する。
さて、図１８は１つの比較手段に対して、１つの原本ファイルと対応する１つのアプリケーションファイルを比較するプログラムのフローチャートである。
【０１０６】
本フローチャートは、改ざんチェック装置のシナリオ実行手段５０２（図５）から呼び出される比較手段５０５または比較手段５１３の１つに対応する。シナリオに従い、チェック対象のファイル（原本ファイルとアプリケーションファイル）を比較対象として実行されるが、前述の通り比較対象ファイルの一方が存在しない場合もある。
【０１０７】
図１８のフローチャートは、大きく４つの部分に分かれる。まず、比較処理を行う際に比較対象となる２つのファイルのうち一方でも存在すれば実行可能な比較処理に対するステップである。すなわち、何らかのコマンドで、１つのファイルの属性を抽出することが可能であるが、２つのファイルから値を抽出後、それらの値が一致するかどうかを判定するものである。
【０１０８】
（１）ステップＳ１８０２からステップＳ１８０５は、このうち原本ファイルが存在する場合の処理である。（２）ステップＳ１８０６からステップＳ１８０９は、このうちアプリケーションファイルが存在する場合の処理である。両方存在する場合には（１）と（２）の両方を実行する。一方が存在しない場合でも、結果には空を設定しておくため、後述（３）の比較が可能である。（３）ステップＳ１８１０からステップＳ１８１３は原本ファイルとアプリケーションファイルの情報を比較する処理である。
【０１０９】
（４）ステップＳ１８１４からステップＳ１８１６は原本ファイルとアプリケーションファイルの両方を同時に処理対象とするため、２つのファイルが存在する場合に実行可能な比較手段を前提とした処理である。
【０１１０】
まず、ステップＳ１８０１は、比較のために使用する比較手段が、原本ファイルとアプリケーションファイルの２つが存在する必要があるか判断する。ファイルが２つ存在する必要がなければ、ステップ１８０１はＮｏを返し、上記（１）から（３）の処理を実行する（ステップＳ１８０２に進む）。ファイルが２つ存在する必要があれば、ステップ１８０１はＹｅｓを返し、上記（４）の処理を実行する（ステップＳ１８１４に進む）。
以下、例としてファイル“ｔｏｏｌ．ｊａｒ”に対してコマンド“ｓｉｚｅ”の処理を用いて説明する。
【０１１１】
最初に前記（１）の場合について説明する。ステップＳ１８０２で原本ファイルが存在するかどうか判定する。原本ファイルが存在すればステップＳ１８０３に進み、原本ファイル“ｔｏｏｌ．ｊａｒ”に対して“ｓｉｚｅ”ツールを実行し結果“１２，３４５”を得る。ステップＳ１８０３で得た値を、ステップＳ１８０４にて図１９の比較内容１９０５における“原本”に格納する。ここでは、“１２，３４５”が格納される。原本ファイルが存在しない場合には、ステップＳ１８０５にて、１９０５における“原本”に空白（値が得られなかったというマーク）を格納する。
【０１１２】
次に前記（２）の場合について説明する。ステップＳ１８０６でアプリケーションファイルが存在するかどうか判定する。アプリケーションファイルが存在すればステップＳ１８０７に進み、原本ファイル“ｔｏｏｌ．ｊａｒ”に対して“ｓｉｚｅ”ツールを実行し結果“１２，３４５”を得る。ステップＳ１８０７で得た値を、ステップＳ１８０８にて図１９の比較内容１９０５における“比較対象”に格納する。ここでは、“１２，３４５”が格納される。アプリケーションファイルが存在しない場合には、ステップＳ１８０９にて、１９０５における“比較対象”に空白（値が得られなかったというマーク）を格納する。
【０１１３】
次に前記（３）について説明する。ここでは、前記（１）および（２）で得た２つの値をステップＳ１８１０で比較する。比較において、両者とも“比較対象”が空白（値が得られなかったというマーク）ではない値が入っており、その両者の値が一致する場合のみ、ステップＳ１８１１Ｙｅｓとなり、ステップＳ１８１２に進む。ステップＳ１８１２では、図１９の例では、“比較内容”に“ｓｉｚｅ“を格納し、１９０５において、”原本“と”比較対象“のサイズがいずれも”１２，３４５”であるため、“結果”に“○”（一致する）を格納する。
【０１１４】
一方、原本あるいは比較対象の一方または双方の値が空白（値が得られなかったというマーク）あるいは、両方の値が得られたが一致しない場合（図１９の１９１１の例）では“比較内容”に“ｃｒｅａｔｅ＿ｄａｔｅ”、“結果”に“×”（一致しない）を格納する。
【０１１５】
次に前記（４）について説明する。前述の通りＳ１８０１にて“Ｙｅｓ”となるのは、比較に使用するコマンドが、原本ファイルとアプリケーションファイルの両方を同時に処理対象とするため、２つのファイルが存在する場合に実行可能な比較手段を前提とした処理である（例として２つのファイルの内容が一致することを確認する“ｆｃ”コマンド）。
【０１１６】
まずステップＳ１８１４では、ファイルが２つ存在することを確認する。ファイルが２つ存在した場合には、ステップＳ１８１５にて指定された比較手段を実行する。比較処理結果として“原本”および“比較対象”から、何らかの属性値を抽出するわけではないので、それぞれ“空白”が格納される（これはファイルが２つとも存在する場合でも同じである）。比較内容は例えば“ｆｃ”である（図１９の１９０４）。比較結果が等しければ“○”（一致する）、等しくなければ“×”（一致しない）が結果に格納される。何を持って等しい、等しくないとするかは、各比較手段における定義であり、本発明の改ざんチェック装置では比較手段（図５の５１３）を任意に定義できるため、本結果の定義も柔軟に定義できる。
一方、ファイルが２つ存在しなければステップＳ１８１７にて“結果”は“×”となる（図１９の１９０４）。
【０１１７】
以上により、原本ファイルとアプリケーションファイルに対して、個々の比較手段による比較（図１８）、シナリオに基づいた複数の比較手段による総合結果（図１７）、全ファイルに対する比較（図１４）の説明を完了する。
上記説明の中で、比較結果は図１９の形式でメモリ上に展開したが、この構成があくまで例であることは言うまでもない。
【０１１８】
さらに、これらの結果をファイルにレポート出力した例を図２０に示す。図２０は、１ファイル１行で出力している。また、レポートファイルを出力するにあたり、原本やチェック対象により一意的にレポートファイル名を割り当てる必要がある場合、１３３２Ｐｒｏｊｅｃｔ属性、１３３３ＥｘｅｃＳｅｒｖｅｒ属性の値を利用してファイル名を生成してもよい。またレポートファイルの出力先フォルダとして、１３３７ＲｅｐｏｒｔＦｏｌｄｅｒ属性の値を利用する。
【０１１９】
２００６“ｔｏｏｌ．ｊａｒ”は、２００３“ｆｃ”、２００４“ｓｉｚｅ”、２００５“ｃｒｅａｔｅ＿ｄａｔｅ”の３つの比較手段により、原本ファイル、アプリケーションファイルのいずれの値も一致しているため、総合結果２００１も“○”（一致している）となっている。
【０１２０】
一方、２００７“ｖｉｅｗ．ｊａｒ”は、２００３“ｆｃ”と“ｃｒｅａｔｅ＿ｄａｔｅ”の結果が異なるため、総合結果２００１も“×”（一致していない）となっている。
【０１２１】
さらに、２００８“ｃｏｎｔｒｏｌｅ．ｊａｒ”はアプリケーションファイルが存在していないため、総合結果に“Ｏｎｌｙ＿Ｏｒｇｎ”（原本ファイルしか存在しない）とマークされている。また、２０１２“ｍｏｄｕｌｅ￥ｍｏｄｅｌ．ｊａｒ”は、アプリケーションファイルしか存在していないため、総合結果に“Ｏｎｌｙ＿Ａｐｌ”（アプリケーションファイルしか存在しない）とマークされている。図２０のレポート出力が一例であることは言うまでもない。
以上、改ざんチェック装置における改ざんチェック処理の１つの実施例の説明を完了する。
【０１２２】
なお、以上の実施例では、比較の一方は、ＳＣＭサーバに格納され、原本性が確保された原本ファイルであるという前提で説明した。しかしながら、本発明を利用する環境において、必ずしも原本ファイルが利用できるわけではない。
この様な場合でも、同一のアプリケーションが複数のアプリケーション動作サーバで実行されていれば、相互に比較することができる。
【０１２３】
また、本実施例で使用したシナリオ（図１３の１３０１）は、１つの原本ファイル群、１つのアプリケーションファイル群を取得し、１回の比較を行ったが、図１４のフローチャートからこれらの処理を繰り返し実施できることは言うまでもない。例えば、まず経理システムの原本ファイル群を取得して、サーバ１にリリースされた経理アプリファイル群を取得し、前記原本ファイルと比較し、さらにサーバ２にリリースされた経理アプリファイル群を取得し、別な比較手段で原本ファイルと比較し、引き続き発注システムの原本ファイルからファイル群を取得し、サーバ３およびサーバ４にリリースされている発注システムのファイル群を取得して比較する、ということを繰り返すことが可能である。
【０１２４】
図１３においてブロック１３０２とブロック１３０３のいずれもアプリケーション動作サーバを設定し、比較することで「少なくとも一方だけが改ざんされた」という状況の発生を発見することができる。
【０１２５】
さらに、以上では、２つのファイル群（原本とアプリケーションファイル、２つのアプリケーションファイル）を比較したが、２つ以上のファイル群をいずれか１つを基準に比較することも可能である。この場合、原本ファイルがなくとも全てのアプリケーション動作環境が同一でない限り、何らかの改ざんが成されたとすることで、さらに改ざんチェックの精度を高めることも可能となる。
【０１２６】
また、本発明の目的は、以下の処理を実行することによって達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。
【０１２７】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１２８】
また、プログラムコードを供給するための記憶媒体としては、次のものを用いることができる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等である。または、プログラムコードを、ネットワークを介してダウンロードしてもよい。
【０１２９】
また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１３０】
更に、前述した実施形態の機能が以下の処理によって実現される場合も本発明に含まれる。即ち、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行う場合である。
【０１３１】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した各実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳなどが実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現する場合も含まれる。
【０１３２】
この場合、上記プログラムは、該プログラムを記憶した記憶媒体から直接、またはインターネット、商用ネットワーク、若しくはローカルエリアネットワーク等に接続された不図示の他のコンピュータやデータベースなどからダウンロードすることにより供給される。
【０１３３】
上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、ＯＳ（オペレーティングシステム）に供給されるスクリプトデータ等の形態から成ってもよい。
【符号の説明】
【０１３４】
１０１ ＳＣＭクライアント
１０２ ＳＣＭサーバ
１０３ 改ざんチェック装置
１０４ アプリケーション動作サーバ
１０５ アプリケーション動作サーバ
１０６ ネットワーク
２０１ ＣＲＴ
２０２ 入力デバイス
２０３ ＣＰＵ
２０４ ＲＡＭ
２０５ ＲＯＭ
２０６ 外部記憶装置
２０７ ネットワーク・インタフェース
２０８ バス
３０１ ＳＣＭクライアント
３０２ ワークスペース
３０３ ＳＣＭサーバ
３０４ リポジトリ
３０５ アプリケーション動作サーバ
３０６ アプリケーションフォルダ
３０７ 改ざんチェック装置
３０８ 抽出した原本ファイル
３０９ 抽出したアプリケーションファイル
３１０ レポート
【技術分野】
【０００１】
本発明は、ファイルの原本管理とアプリケーション実行環境におけるファイルの改ざんをチェックするシステムに関する。
【背景技術】
【０００２】
近年、ソフトウェアの開発においても内部統制の観点から、開発および開発したシステムの改修に対する要求、承認を管理し、さらに実際に変更したソースコードや実行モジュールと結びつけて統合的に監査することの重要性が認識されてきている。特にソフトウェア構成管理（ＳＣＭ）と呼ばれるシステムも多数製品化され、アプリケーションを実行する環境であるサーバにデプロイ（リリースとも言う）し、デプロイに関する監査証跡まで残すことが可能な製品も存在する。
【０００３】
特開２０００−１４８４５３号公報では、ソフトウェアモジュールの更新履歴を格納し、リリース対象のソフトウェアモジュールを特定するデータを入力し、入力された特定用データに対応する更新履歴データを取得し、さらに更新履歴データに、少なくとも日付，ソフトウェアモジュール名称を付加した実行結果データを出力することにより、ソフトウェアモジュールの更新履歴の管理が容易に行えるソフトウェアモジュールのリリース管理システムを実現している。
【０００４】
特許３８０３００２号公報に記載の発明では、ハードディスク上のデータが不正に改ざんされた場合に備え、監視対象とするデータと、当該データを参照するプログラムを登録し、前記データの更新を監視し、監視対象とするデータを予め待避し、前記データの更新を監視して検出し、当該データを参照するプログラムの実行状態を検出し、前記データの更新が検出されたとき、当該データを参照するプログラムの実行状態が停止中であったときは該更新内容を退避し、実行状態が動作中であったときは退避してあった該データを回復する技術を実現している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０００−１４８４５３号公報
【特許文献２】特許３８０３００２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
特許文献１では、アプリケーションのリリースに関して作業を容易かつ確実に行い、更に監査証跡を残すことを実現している。
【０００７】
しかしながら、一度、実行環境にリリースしたファイル群の監視までは行うことはできない。すなわち、不正なルート、例えばアプリケーションが実行されているサーバに不正侵入し、アプリケーションを構成するファイルの改ざんされた場合まで管理する機能は実現していない。
特許文献２では、予め登録したデータの改ざんを検出することを実現している。
【０００８】
しかしながら、前記の監視は、あくまでバックアップしている更新前のデータとの比較によるものに過ぎず、更新前のデータ自体が原本性を有することをソフトウェア構成管理（ＳＣＭ）ツールなどにより保証するものではない。
【０００９】
更に、予め特定されたデータに対しての監視に限定されているため、アプリケーションを構成する実行ファイルや関連ファイルのように、機能追加や障害対応でアプリケーションのファイル構成が変わるたびに監視対象とするファイルを特定し直す必要があった。また監視方法も、予め実装された方法に限定され、監視方法の拡張は困難であった。
【００１０】
本発明は、アプリケーションの実行形式ファイル、設定ファイル、その他のデータの構成が随時変更される状況において、チェック対象とするファイルの構成を特定することなく、原本性を保証されているファイル群とアプリケーション実行環境のファイル群を比較することを可能とするとともに、比較方法の拡張を柔軟に実現することで、不正な改ざんを検出する仕組みを提供することを課題とする。
【課題を解決するための手段】
【００１１】
ファイルデータの原本性を保証するソフトウェア構成管理システムからアプリケーション動作サーバ上にリリースされたファイルデータの改ざんを検出する改ざんチェック装置において、
【００１２】
原本データを取得する原本取得方法と、チェック対象となるリリースデータを取得するチェック対象取得方法と、前記取得した原本データとリリースデータの比較方法とを定義したシナリオを記憶するシナリオ記憶手段と、
前記シナリオ記憶手段に記憶された前記シナリオを読み込んで実行するシナリオ実行手段とを備え、
【００１３】
前記シナリオには、前記原本取得方法として少なくとも原本取得手段が指定され、前記チェック対象取得方法として少なくともチェック対象取得手段が指定され、前記比較方法として少なくとも１または複数の比較手段が指定され、
前記原本取得手段は、前記ソフトウェア構成管理システムから原本性が保証されたファイルデータを取得し、
前記チェック対象取得手段は、前記アプリケーション動作サーバ上にリリースされたチェック対象となるファイルデータを取得し、
前記１または複数の比較手段は、前記原本性が保証されたファイルデータと前記チェック対象となるファイルデータを比較し、
前記１または複数の比較手段による比較結果をレポートするレポート手段と、を有することを特徴とする改ざんチェック装置。
【発明の効果】
【００１４】
サーバ上で動作しているアプリケーションを構成するファイル群に対しログファイルなどアプリケーションが随時変更するファイルを除外した上で、不正な改ざんがあれば、原本性を保証されているファイル群に基づき検出することを可能とする。また、改ざんの検出方法を外部手段により追加し、シナリオファイルで実行定義するため、検出方法を柔軟に拡張できる。
【図面の簡単な説明】
【００１５】
【図１】改ざんチェック装置、ＳＣＭサーバ、ＳＣＭクライアント、アプリケーション動作サーバの各ハード構成の一例を示すブロック図である。
【図２】本発明の実施形態に関わる改ざんチェック装置、ＳＣＭサーバ、ＳＣＭクライアント、アプリケーション動作サーバのシステム構成の一例を示す図である。
【図３】本発明の実施形態に関わる改ざんチェック装置、ＳＣＭサーバ、ＳＣＭクライアント、アプリケーション動作サーバの動作の概略の流れを説明するための図である。
【図４】ソフトウェア構成管理（ＳＣＭ）ツールのクライアント画面の一例を示す図である。
【図５】改ざんチェック装置の機能ブロックの一例を示す図である。
【図６】シナリオファイルの一例を示す図である。
【図７】除外ファイルを指定する設定ファイルの一例を示す図である。
【図８】メモリ上に展開されたシナリオ構造の一例を示す図である。
【図９】改ざんチェック装置の機能ブロックのうち、原本取得手段の一例を示す図である。
【図１０】図９に記載した原本取得手段と協調して動作するＳＣＭサーバ側原本取得手段を構成する機能ブロックの一例を示す図である。
【図１１】改ざんチェック装置の機能ブロックのうち、チェック対象取得手段の一例を示す図である。
【図１２】図１１に記載したチェック対象取得手段と協調して動作するアプリケーション側ファイル取得手段を構成する機能ブロックの一例を示す図である。
【図１３】チェック対象取得手段、比較手段の設定を含むシナリオファイルの一例を示す図である。
【図１４】改ざんチェック装置で実行する最上位の処理のフローチャートである。
【図１５】ＳＣＭサーバから原本ファイル群を取得するプログラムのフローチャートである。
【図１６】アプリケーション動作サーバからアプリケーションファイル群を取得するプログラムのフローチャートである。
【図１７】原本ファイル群とアプリケーションファイル群を比較するプログラムのフローチャートである。
【図１８】１つの原本ファイルと対応する１つのアプリケーションファイルを比較するプログラムのフローチャートである。
【図１９】比較結果を記録したメモリ上の構造体の一例を示す図である。
【図２０】比較結果のレポートの一例を示す図である。
【発明を実施するための形態】
【００１６】
以下、本発明の実施の形態を、図面を参照して詳細に説明する。
【００１７】
図１は、本発明の実施形態に関わる改ざんチェック装置、ＳＣＭサーバ、ＳＣＭクライアント、アプリケーション動作サーバのシステム構成の一例を示す図である。ＳＣＭクライアント１０１、ＳＣＭサーバ１０２、改ざんチェック装置１０３、アプリケーション動作サーバ１０４、１０５は、ネットワーク１０６を介して相互に接続される。
【００１８】
図２は、改ざんチェック装置、ＳＣＭサーバ、ＳＣＭクライアント、アプリケーション動作サーバの各ハード構成の一例を示すブロック図である。ＣＲＴ２０１と、入力デバイス２０２と、ＣＰＵ２０３と、ＲＡＭ２０４と、ＲＯＭ２０５と、外部記憶装置２０６と、ネットワーク・インタフェース２０７とを備える。
【００１９】
ＣＰＵ２０３は、ＲＯＭ２０５に記憶された制御プログラムを読み出して実行すると共に、情報処理装置を制御する。ＲＡＭ２０４は、データ等を一時記憶するためのバッファやワークエリア等として機能し、またＯＳを含む各種プログラムを実行する作業領域として使用される。
【００２０】
外部記憶装置２０６はハードディスクドライブ等の記憶装置であり、ＯＳやファイル管理システムのプログラムを含む各種プログラム及び各種データの短期的、永続的な記憶装置として使用される。
【００２１】
入力デバイス２０２は、キーボード、マウス等に代表されるユーザ入力機器であり、ＣＲＴ２０１は情報処理装置の処理結果等を表示するための機器である。バス２０８は、上述した各部を互いに接続するシステムバスである。
なお、ＳＣＭサーバ１０２、アプリケーション動作サーバ１０４ならびに１０５においては、ＣＲＴ２０１および入力デバイス２０２は、必須なものではない。
図３は、改ざんチェック装置、ＳＣＭサーバ、ＳＣＭクライアント、アプリケーション動作サーバの関連を簡単な動作例を用いて説明する概略図である。
【００２２】
ＳＣＭクライアント３０１は、図1のＳＣＭクライアント１０１に相当し、ＳＣＭサーバ３０３は、図１の１０２、アプリケーション動作サーバ３０５は、図１のアプリケーション動作サーバ１０４および１０５、改ざんチェック装置３０７は図１の改ざんチェック装置１０３に相当する。
【００２３】
ＳＣＭサーバ３０３は、ソフトウェア構成管理システム（Ｓｏｆｔｗａｒｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ：ＳＣＭシステム）と呼ばれるツールであり、開発しているプログラム（ソースコード）を変更する際に変更する旨の申請および承認のワークフロー管理、変更したプログラム（ソースコード）のバージョン管理、前記申請及び承認のワークフローと実際に変更したプログラム（ソースコード）の関連を保持し、プログラムの変更に関する監査履歴（誰が、いつ、どのような理由で、誰の承認を得て変更をしたのか）を残すことができる。ＳＣＭツールは、１つのアプリケーションを構成するために必要なソースコード一式を「プロジェクト」という単位で管理する。例えば、経理システムを構成するソースコード一式を「経理ソースコード」というプロジェクト名で管理することができる。
【００２４】
図４のＧＵＩ４０１は、ソフトウェア構成管理（ＳＣＭ）ツールのクライアント側ＧＵＩの一例である。画面は大きく３つに分かれており、プロジェクト一覧ウィンドウ４０２、プロジェクト原本表示ウィンドウ４０３、作業領域表示ウィンドウ４０４から構成される。
プロジェクト一覧ウィンドウ４０２は、プロジェクトと呼ばれる単位で管理され、図４の例では３つのプロジェクトが管理されている。
【００２５】
例えば１つのアプリケーションを構成する全てのソースコードを格納することができる。プロジェクト名４０５は、例として「Ｋｅｉｒｉ＿Ｓｏｕｒｃｅ＿Ｃｏｄｅ」（４０７）であり、説明（備考）４０６として「経理システムソースコード管理用プロジェクト」というコメントを付与している。いずれも利用者が当該ＧＵＩ４０１を用いて設定することができる。
【００２６】
プロジェクト原本表示ウィンドウ４０３は、ＳＣＭサーバ３０３（図３）上に格納されている原本ファイル群（ここでは経理システムソースコードのファイル群）の最新の状態を表示している。通常の開発におけるフォルダおよびファイルの構成が、ウィンドウ内にツリー構造としてそのまま表示されている。従って複数の開発者が同時に当該プロジェクトの開発を行う場合であっても、（最新状態を表示さえすれば）同じ表示状態になる。
【００２７】
作業領域表示ウィンドウ４０４の表示内容は、プロジェクト原本表示ウィンドウ４０３とほぼ同一だが、ＳＣＭサーバ３０３（図３）の状態を表しているのではなく、作業領域（通常は開発者などが個人使用するＰＣのローカルのフォルダ）の最新状態が表示されている。この例では、ファイル４０９“ｕｒｉａｇｅ．ｊｓｐ”とファイル４１０“ｓｙｏｕｓａｉ．ｊｓｐ”の２ファイルがチェックアウト（ｃｈｅｃｋｏｕｔ）されている。チェックアウトとは、該ローカルＰＣで開発者が前記２ファイルを作業している状態である。他の開発者が使用できないように排他的ロックすることが多いが、開発者あるいはシステム管理者（ＳＣＭサーバ３０３の管理者）が、オプションにより排他的か非排他的か選択することができるＳＣＭツールも存在する。
【００２８】
ファイル４１０“ｓｙｏｕｓａｉ．ｊｓｐ”には“＊”記号が表示されており、チェックアウトした後、ローカルＰＣの作業領域で編集し、ＳＣＭサーバ３０３の原本とは差分が生じていることを表している。差分をＳＣＭサーバ３０３の原本に反映し、変更したものを新たに原本とするためには、開発者はチェックイン（ｃｈｅｃｋｉｎ）という操作をする。
【００２９】
さらに、ＳＣＭツールはプログラム（ソースコード）だけではなく、バイナリデータ（実行ファイルやワープロ文書、データ）、ｈｔｍｌファイル、ｈｔｍｌファイルで表示する画像データなど、アプリケーションを構成するファイル一式を管理することも可能であり、図４の例では、ソースコード側のプロジェクト（ＧＵＩ４０１のプロジェクト一覧ウィンドウ４０２）に対応して３つのプロジェクトが管理されている。ただしこれはあくまで例であり、ソースコードのみ管理する場合、実行ファイルのみを管理する場合などがあってもよい。
【００３０】
例えば、前述の経理システムを構成するソースコード一式をコンパイル、あるいはビルドしてアプリケーションとして動作可能なファイル一式（リリースファイル、リリースデータ）に変換した後、本図ではプロジェクト名４１１「ＫｅｉｒｉＰｒｏｊｅｃｔ」、説明（備考）４１２「経理システムリリース用プロジェクト」というプロジェクト名で管理する。
【００３１】
バイナリデータの原本を更新する場合も、ソースコードの場合と同様に一度チェックアウトし、外部でコンパイラ、ビルド等されたファイで上書きする。図４のファイル４１３“ｔｏｏｌ．ｊａｒ”がローカルＰＣの作業領域上で、“ｔｏｏｌ．ｊａｒ”が変更された状態にあることを示している。このファイルをチェックインすることで、ＳＣＭサーバ３０３上の“ｔｏｏｌ．ｊａｒ”の原本を更新する。
【００３２】
デプロイ（リリース）用に設定されたプロジェクト４１１“ＫｅｉｒｉＰｒｏｊｅｃｔ”では、更新されたファイルがチェックインされると、ＳＣＭサーバ３０３はこのファイルを指定されたアプリケーション動作サーバにデプロイするように機能設定できる製品もある。
【００３３】
説明を図３に戻すと、「デプロイ実施」は、前述のようにアプリケーションの一部ファイルが変更され、デプロイされ、改ざんチェックされる動作の概略図である。
【００３４】
ＳＣＭクライアント３０１には、アプリケーションを構成するファイル一式を管理するワークスペース３０２があり、変更しビルドし直したファイルは開発者によりワークスペースに上書きされる。 開発者が、前記上書きしたファイルを指定して、ＳＣＭサーバ３０３にチェックインすると、登録された原本ファイル群であるリポジトリ３０４は更新される。ここで更新とは、単に既存ファイルの変更だけではなく、存在しないファイルの追加、既存ファイルの削除の処理も含む。
【００３５】
ＳＣＭサーバ３０３は、前記チェックインされたファイルがあると、自動的にあるいはＳＣＭクライアントのユーザ操作によりデプロイを実施する。デプロイは、前記チェックインされたファイルの更新情報をアプリケーション動作サーバ３０５に送信し、アプリケーションファイル３０６を更新する処理である。前述と同様、更新とは、変更、追加、削除を含む。
【００３６】
図３の改ざんチェック装置３０７は、改ざんチェック対象のアプリケーションを構成するファイル（原本ファイル）をＳＣＭサーバ３０３の指定されたプロジェクトのリポジトリ３０４から抽出する。さらに対応するアプリケーションファイル３０６をアプリケーション動作サーバから抽出する。
【００３７】
改ざんチェック装置３０７に抽出された原本ファイル３０８と抽出されたアプリケーションファイルは、同じフォルダ構成（ルートフォルダ配下の階層構造など）からなっている。すなわち、改ざんチェック装置３０７のハードディスク内に指定された異なる２つのフォルダを各々のルートフォルダとし、その配下は同じはずである。この２つのルートフォルダ配下に格納されたファイル群から、改ざんチェック装置３０７は差分を検出する。以上の動作は、シナリオ記憶手段３１０に記憶されているシナリオに基づいて実行される。
【００３８】
図３では、ＳＣＭクライアント３０１、ＳＣＭサーバ３０３、アプリケーション動作サーバ３０５、改ざんチェック装置３０７の全てを異なる装置として記載しているが、これらの全てあるいは一部が同一の装置上に構成されていても良い。
【００３９】
図５は改ざんチェック装置の機能ブロックの一例を示す図である。改ざんチェック装置の機能ブロックは、大きく分けてシナリオ読み込み手段５０１とシナリオ実行手段５０２に分かれている。またシナリオ実行手段５０２は、原本取得手段５０３、チェック対象取得手段５０４、比較手段５０５、レポート手段５０６を制御する。
【００４０】
シナリオ読み込み手段５０１で読み込まれたシナリオファイル５０７は、メモリ上に展開されたシナリオ５１０としてシナリオ実行手段５０２で利用しても良い。図８は、後述のフローチャートを説明する際に使用する図１３のシナリオ１３０１をメモリ上に展開した一例である。
【００４１】
メモリ上の構成全体を管理するシナリオルート８０１を“Ｓｃｅｎａｒｉｏ”で表している。それ以下、シナリオファイル内で表現されるブロック（後述）をブロック８０２とその属性と値のペアを図８のブロック内容８０３として記載している。同様に、ブロック８０４、ブロック内容８０５、ブロック８０６、ブロック内容８０７として展開される。
【００４２】
図５では、シナリオ実行手段は、原本データ（原本ファイルデータ）を取得するためにシナリオ実行手段に組み込まれた原本取得手段５０３あるいは外部コマンドとして呼び出される原本取得手段５１１のいずれかを実行する。また、チェック対象を取得するためにシナリオ実行手段に組み込まれたチェック対象取得手段５０４あるいは外部コマンドとして呼び出されるチェック対象取得手段５１２のいずれかを実行する。さらに、原本とチェック対象を比較するためにシナリオ実行手段に組み込まれた比較手段５０５あるいは外部コマンドとして呼び出される比較手段５１３のいずれかを実行する。比較手段の場合には、シナリオ実行手段に組み込まれたもの、外部コマンドの双方あわせて、１または複数の比較手段を実行するよう、シナリオにて定義することができる。
【００４３】
ここでシナリオファイル５０７について説明する。シナリオファイル５０７は、図６にその一例を示している。図６は、外部ツールを呼び出さないシナリオの例である。
【００４４】
図６のシナリオファイル６０１には、５つのブロック６０２〜６０６が記載されている。また、行頭に「＃」があるコメント行６２１は、コメントとしてシナリオを実行する際には無視する。
【００４５】
ブロックには２種類有り、ブロック６０２はブロック定義行６２２によりコピーブロック、ブロック６０４はブロック定義行６４１によりコンペアブロックとして定義される。
コピーブロックは、ＳＣＭサーバやアプリケーション動作サーバから改ざんチェックをするために必要なファイル群を取得するための定義である。
【００４６】
コピーブロック６０２の定義は、Ｔｙｐｅ属性６２３が“Ｏｒｉｇｉｎａｌ“であり、原本性が保証されているＳＣＭサーバからファイル群を取得するための定義を記載している。詳細にはＳｅｒｖｅｒ属性６２４により”ＳＣＭ“というネットワーク上のサーバにあるＳＣＭサーバから、Ｐｒｏｊｅｃｔ属性６２５により”ＫｅｉｒｉＲｅｌｅａｓｅＰｒｏｊｅｃｔ“という経理アプリケーションが格納されているリポジトリの内容を抽出し、ＷｏｒｋＦｏｌｄｅｒ属性６２６により改ざんチェック装置の”Ｃ：￥Ｃｏｍｐａｒｅ￥Ｏｒｉｇｉｎａｌ￥Ｋｅｉｒｉ“フォルダに前記抽出した原本ファイル５１４（図５）を格納するように指示するシナリオである。
【００４７】
また、ブロック６０３の定義は、６３１よりコピーブロックとして定義されているが、Ｔｙｐｅ属性６３２が“Ｅｘｅｃｕｔｉｏｎ“であり、アプリケーション動作サーバからファイル群を取得するための定義を記載している。詳細にはＳｅｒｖｅｒ属性６３３により”￥￥Ｓｒｖ０１￥ｃ：￥Ｋｅｉｒｉ“というネットワーク上のサーバおよびフォルダから経理アプリケーションファイルを抽出し、ＷｏｒｋＦｏｌｄｅｒ属性６３４により改ざんチェック装置の”Ｃ：￥Ｃｏｍｐａｒｅ￥Ｅｘｅｃ￥Ｋｅｉｒｉ０１“フォルダに前記抽出したアプリケーションファイル５１５（図５）を格納するように指示するシナリオである。さらにＥｘｃｌｕｄｅＦｉｌｅｓ属性６３５により除外ファイルとして”Ｅｘｃｌｕｄｅ．ｄｅｆ”ファイルが指定され、ファイルのフルパスを文字列と見なした場合に、該ファイルに記載された文字列パターンのいずれかを含む場合には、改ざんチェックシステムの処理対象として抽出しない（改ざんチェックをしない）ファイルとなる。図５では除外ファイル５０８、除外ファイル５０９としてシナリオファイル５０７から指定している。図７に除外ファイルの一例を図示する。
【００４８】
図７の除外ファイル７０１には、改行コードで区切られた３つのパターンが定義されている。パターン７０２はフルパス中に“Ｌｏｇｆｏｌｄｅｒ￥＊．ｌｏｇ”というパターンが現れた場合には、そのファイルは前述の通り、改ざんチェックシステムの処理対象として抽出されない。
【００４９】
ここで“＊”は、正規表現のワイルドカードを意味している。例えば“Ｃ：￥Ｋｅｉｒｉ￥ｔｅｍｐ￥Ｌｏｇｆｏｌｄｅｒ￥２０１００８２０．ｌｏｇ”が、そのパターンを満たしている。パターン７０３は“．ｂａｋ”を、パターン７０４は“．ｃｏｎｆ”を同様に定義している。
【００５０】
ここで、パターン定義として正規表現およびワイルドカードを説明したのは、あくまで一例である。最も単純な例としては文字列の部分一致、ファイル名の完全一致、さらに正規表現以外のパターンマッチング手法などを利用しても良い。また、除外ファイルをシナリオファイルの外部定義としたが、これは運用におけるメンテナンス性を考慮したものであり、実際の用途に応じてシナリオファイルの中に記載するようにしても良い。また、単なるパターンマッチングだけではなく、スクリプト言語などによる簡単な判定ツールにより、除外ファイルのフィルタリングを行っても良い。
【００５１】
ここで説明を図５に戻す。図５の比較手段５０５は、図６のコンペアブロック６０４のシナリオを実行する手段である。コピーブロック６０２およびコピーブロック６０３で、改ざんチェック装置に抽出したファイル群、すなわちＷｏｒｋＦｏｌｄｅｒ属性６２６で指定された”Ｃ：￥Ｃｏｍｐａｒｅ￥Ｏｒｉｇｉｎａｌ￥Ｋｅｉｒｉ“とＷｏｒｋＦｏｌｄｅｒ属性６３４で指定された”Ｃ：￥Ｃｏｍｐａｒｅ￥Ｅｘｅｃ￥Ｋｅｉｒｉ０１“の２つのフォルダ配下のファイル群を比較する。比較結果はレポート手段５０６からレポート５１６として出力される。
【００５２】
ブロック６０４は、６４１によりコンペアブロックの定義であるが、記載されているＰｒｏｊｅｃｔ属性６４２とＥｘｅｃＳｅｒｖｅｒ属性６４３は、例えばレポートファイルを生成する際に、原本（ＳＣＭサーバのプロジェクト名：“ＫｅｉｒｉＲｅｌｅａｓｅＰｒｏｊｅｃｔ”）とアプリケーション動作サーバ名（“Ｓｒｖ０１“）およびレポートした日時などを結合してファイル名とし、他のレポートと一意的に区別するために使用する目的で付与した属性である。レポートファイル名を一意的に生成する方法としては、他の属性の値の部分文字列を利用するなど、他の方法も考えられ、前述の方法はあくまで一例に過ぎない。さらにＯｒｉｇｉｎａｌＦｏｌｄｅｒ属性６４４は改ざんチェック時の原本性を保証するファイル群を格納するフォルダのルートを定義する。ＥｘｅｃＦｏｌｄｅｒ属性６４５は改ざんチェックのチェック対象となるアプリケーションファイル群を格納するフォルダのルートを定義する。
【００５３】
以下の例では、外部手段を利用することを前提に説明するが、もちろんこれは実施形態の一例であることは言うまでもない。外部手段を利用することを前提とするため、機能ブロックを図９〜図１２を予め説明する。
【００５４】
図９の原本取得手段９０１は、改ざんチェック装置上の機能ブロックの一部であり、原本抽出手段９０２、原本受信外部手段９０３、原本不要ファイル除外手段９０４から構成されており、原本不要ファイル除外手段９０４は除外ファイル設定９０５を参照して動作する。
【００５５】
原本抽出手段９０２は、ＳＣＭサーバの指定のリポジトリの指定のプロジェクト（例えば“ＫｅｉｒｉＰｒｏｊｅｃｔ”）の原本ファイル１００６を抽出する。ただし、これは構成の一例であり、原本抽出手段９０２は、図１０のＳＣＭサーバ側原本抽出手段１００２に要求を送り、該ＳＣＭサーバ側原本抽出手段１００２が、原本ファイル１００６を抽出するように機能しても良い。例えば原本抽出手段９０２がＳＣＭ製品のクライアント機能として提供されている場合、改ざんチェック装置にも、前者のようにＳＣＭクライアントをインストールしなければならないが、原本抽出手段９０２からＳＣＭサーバ側原本抽出手段１００２を呼出し、ＳＣＭサーバ側原本抽出手段１００２をＳＣＭ製品のクライアント機能により構成すれば、改ざんチェック装置にＳＣＭクライアントをインストールする必要はなくなる。
【００５６】
次に、原本受信外部手段９０３は、原本抽出手段９０２で抽出した原本ファイル１００６（図１０）を、改ざんチェック装置側に転送する際の受信機能を有する。
【００５７】
前述のように、原本抽出手段９０２がＳＣＭサーバ側原本抽出手段１００２に要求せずに、単独で動作する場合には、原本受信外部手段９０３は不要となる。ＳＣＭサーバ側原本抽出手段１００２に要求してＳＣＭサーバ側で原本ファイルを抽出した場合には、原本受信外部手段９０３は、独自に原本ファイル１００６を改ざんチェック装置に転送するか、ＳＣＭサーバ側原本送信手段と協調して原本ファイル１００６の送受信を行うかのいずれかである。
【００５８】
前者の例としては、例えばＳＣＭサーバにおいて抽出された原本を格納しているフォルダがネットワーク上の共有フォルダとして公開されているのであれば、ＯＳ標準のコピーコマンドを使用すればよい。後者の例としては、市販のデータ転送ソフトウェア製品を利用することも可能である。この場合、データの転送効率を良くするため多数のファイルを１つに結合する、転送中に改ざんされないようにするため暗号化する、などの機能が容易に利用できる。
【００５９】
最後に、原本不要ファイル除外手段９０４は、前述の受信したファイルのうち、改ざんチェック対象ではないファイルと改ざんチェック対象のファイルをフィルタリングする手段である。
【００６０】
不要なファイルを削除しても良いし、不要なファイルあるいは必要なファイルのいずれかを他のフォルダに移動しても良い。この場合、除外ファイル設定９０５を参照する。除外ファイルについては、既に図７で説明しているため、ここでは省略する。
【００６１】
原本において、不要なファイルを除外する目的としては、各種あるＳＣＭ製品の中には、原本を抽出し作業フォルダを構成する際に、原本管理用の隠しファイルを多数作成する製品も存在し、その場合には該原本管理用の隠しファイルは改ざんチェック対象から削除したい、などの理由による。もちろん他の目的で使用することも可能である。
【００６２】
あるいは、除外ファイル設定１００５に基づきＳＣＭサーバ側原本不要ファイル除外手段１００３により、原本ファイルを改ざんチェック装置に転送する前に不要なファイルを除外しても良い。この場合、転送するファイル群は、原本ファイルから不要ファイル医を除外したファイル群１００７となる。予め除外するファイルが多ければ、ネットワーク負荷も押さえることが可能となる。
以上、図９と図１０の機能ブロックにより改ざんチェック処理に必要な原本ファイルが改ざんチェック装置上に格納される。
【００６３】
しかし、あくまで本機能ブロックの構成は一例に過ぎない。例えば、前述のコピーコマンドを使用する例において、コピーコマンド自身がファイルのフィルタリング機能を有するものもある。この場合、原本受信外部手段９０３および原本不要ファイル除外手段９０４は単一の実行コマンドとなる。また改ざんチェック装置上にＳＣＭクライントをインストールし、ＳＣＭクライアントが１つのコマンドとして原本取得手段９０１の全ての機能を含んでいる場合もある。この場合はさらにＳＣＭサーバ側においても全ての機能はＳＣＭサーバに組み込まれていてもよい。
【００６４】
このように、図９と図１０は様々な構成が考えられるが、詳細の動作をフローチャート図１４〜図１８を説明する際には、図９と図１０の機能ブロックを例としてそのまま使用する。
次に図１１と図１２を説明する。
【００６５】
図１１のチェック対象種特外部手段１１０１は、改ざんチェック装置上の機能ブロックの一部であり、チェック対象抽出手段１１０２、チェック対象受信外部手段１１０３、チェック対象不要ファイル除外手段１１０４から構成されている。
【００６６】
図１１の各手段は図９の各手段と次のように対応しており、ほぼ同一の機能を有している。すなわち、チェック対象抽出手段１１０２と原本抽出手段９０２、チェック対象受信外部手段１１０３と原本受信外部手段９０３、チェック対象不要ファイル除外手段１１０４と原本不要ファイル除外手段９０４が対応している。
【００６７】
また、図１２のアプリケーション側ファイル抽出手段１２０１はチェック対象種特外部手段１１０１（図１１）と協調して動作するアプリケーション動作サーバ上の機能ブロックであり、アプリケーション側ファイル抽出手段１２０２、アプリケーション側不要ファイル除外手段１２０３、アプリケーション側ファイル送信手段１２０４から構成されている。
【００６８】
図１２の各手段は図１０の各手段と次のように対応しており、ほぼ同一の機能を有している。すなわち、アプリケーション側ファイル抽出手段１２０２とＳＣＭサーバ側原本抽出手段１００２、アプリケーション側不要ファイル除外手段１２０３とＳＣＭサーバ側不要ファイル除外手段１００３、アプリケーション側ファイル送信手段１２０４とＳＣＭサーバ側原本送信手段１００４が対応している。
【００６９】
対応しているとはいえ、図１１と図１２の機能ブロックの関係は、図９と図１０の関係とは異なる点がいくつかある。例えば、図１０はＳＣＭサーバであるため、図９にＳＣＭクライアントを導入して原本ファイルの抽出を実現することができる。一方、図１２のアプリケーション動作サーバでは、アプリケーションファイルを抽出する際に、ほぼそのフォルダ構成を利用すればよいことが多く、必ずしも抽出処理が必要ではない。
【００７０】
一方で、図１２のアプリケーション動作サーバでは、例えばＷｅｂアプリケーションサーバ（ＷＡＳ）がアプリケーションファイルを管理しており、アプリケーションファイルを抽出する前提として、Ｗｅｂアプリケーションサーバを停止させるなどの前処理および抽出後、Ｗｅｂアプリケーションサーバを再起動する処理が必要な場合がある。
【００７１】
図１１と図１２にも図９と図１０に関しての説明を実施した際に述べたのと同様、様々な構成が考えられるが、詳細の動作をフローチャート図１４〜図１８を説明する際には、図１１と図１２の機能ブロックを例としてそのまま使用する。
次に、改ざんチェックシステムの詳細の動作を図１３〜図１８を用いて説明する。
図１４は改ざんチェック装置で実行する最上位の処理のフローチャートである。
【００７２】
ステップＳ１４０１では、シナリオファイルを読み込みメモリ上に展開する。シナリオの例として図１３シナリオ１３０１を展開すると、メモリ上の展開結果の図８のようになる。
【００７３】
ステップ１４０２からステップＳ１４０７では、シナリオに記述されたブロック（１または複数）を先頭から１つずつ順に処理する。 ステップＳ１４０３では、ブロックの１つに着目（取得）する。
ステップＳ１４０４では、着目しているブロックが“Ｃｏｐｙ”ブロックか“Ｃｏｍｐａｒｅ”ブロックかで処理を分岐する。
【００７４】
“Ｃｏｐｙ”ブロック１３１１の場合、ステップＳ１４０５Ｃｏｐｙブロック処理手段に進む。Ｔｙｐｅ属性が“Ｏｒｉｇｉｎａｌ”（例：ブロック１３０２のＴｙｐｅ属性１３１２）であれば図１５（図５の原本取得手段５０３または原本取得手段５１１）が詳細のフローチャートである。Ｔｙｐｅ属性が“Ｅｘｅｃｕｔｉｏｎ”（例：ブロック１３０３のＴｙｐｅ属性１３２２）であれば図１６（チェック対象取得手段５０４あるいはチェック対象取得手段５１２に対応）が詳細のフローチャートである。
【００７５】
“Ｃｏｍｐａｒｅ”ブロックの場合には、ステップＳ１４０６に進む。Ｃｏｍｐａｒｅブロック処理手段（図５の比較手段５０５または比較手段５１３に対応）は、図１７および図１８のフローチャートで説明する。
【００７６】
ステップＳ１４０８では、ステップＳ１４０６における原本ファイルとアプリケーションファイルの比較結果を、出力する（図５のレポート手段５０６に対応）。詳細の説明としては、図１８のフローチャートの処理において図１９の構造を生成する方法について説明する。図２０は、図１９の構造をファイルに出力した形式の一例であり、後述する。
【００７７】
図１５は、ＳＣＭサーバから原本ファイル群を取得するプログラムである。このフローチャートを実行するのは、前述したようにＴｙｐｅ属性１３１２のようにＴｙｐｅ属性の値が“Ｏｒｉｇｉｎａｌ”である場合である。フローチャート１５０１が改ざんチェック装置、フローチャート１５０２がＳＣＭサーバにおけるプログラムの処理であり、協調して動作する。
【００７８】
ステップＳ１５０３原本抽出手段は、Ｓｅｒｖｅｒ属性１３１３の“ＳＣＭ”上、Ｐｒｏｊｅｃｔ属性１３１４の“ＫｅｉｒｉＰｒｏｊｅｃｔ”に格納されている原本ファイルを抽出するようステップＳ１５０７ＳＣＭサーバ側原本抽出手段に要求する（リクエスト１５１１）。ステップＳ１５０７ＳＣＭサーバ側原本抽出手段は要求通り、ＳＣＭサーバに格納されているプロジェクト“ＫｅｉｒｉＰｒｏｊｅｃｔ”から原本ファイルを抽出し、ＷｏｒｋＦｏｌｄｅｒ属性１３１５に指定された改ざんチェック装置側のフォルダ“Ｃ：￥Ｃｏｍｐａｒｅ￥Ｏｒｉｇｉｎａｌ￥Ｋｅｉｒｉ”に格納する。
【００７９】
ＳＣＭサーバ側で不要なファイルを除外するように設定されている場合には、ステップＳ１５０８ＹｅｓによりステップＳ１５０９ＳＣＭサーバ側原本不要ファイル除外手段に進み、改ざんチェックの処理対象として不要なファイルが除外される。実際に、ファイルを削除する、別のフォルダに移動する、あるいはファイル自体は元の位置に存在するが改ざんチェック時に利用しないよう一覧表に残すなど、除外方法は、物理的なもの、論理的（仮想的）なもの限定しない。その後、ステップＳ１５１０ＳＣＭサーバ側原本送信手段に進む。
【００８０】
ＳＣＭサーバ側で不要なファイルを除外するように設定されていない場合には、ステップＳ１５０８ＮｏによりステップＳ１５１０ＳＣＭサーバ側原本送信手段に進む。
【００８１】
ステップＳ１５１０ＳＣＭサーバ側原本送信手段では、ステップＳ１５０７ＳＣＭサーバ側原本抽出手段で抽出したファイルを、ＳＣＭサーバ側から改ざんチェック装置側に送信する。ステップＳ１５０９ＳＣＭサーバ側原本不要ファイル除外手段を実行した場合には不要ファイルを除外した残りのファイルを送信する（送信１５１２）。
送信されたファイルは、改ざんチェック装置側においてステップＳ１５０４原本受信外部手段により受信される。
【００８２】
次に改ざんチェック装置側で不要なファイルを除外するように設定されている場合には、ステップＳ１５０５ＹｅｓによりステップＳ１５０６原本不要ファイル除外手段に進み、改ざんチェックの処理対象として不要なファイルが除外される。実際に、ファイルを削除する、別のフォルダに移動する、あるいはファイル自体は元の位置に存在するが改ざんチェック時に利用しないよう一覧表に残すなど、除外方法は、物理的なもの、論理的（仮想的）なもの限定しないのはステップＳ１５０９ＳＣＭサーバ側原本不要ファイル除外手段と同様である。これにより図１５のフローチャートを完了し、呼出側である図１４のステップＳ１４０５Ｃｏｐｙブロック処理手段の終了時点に戻る。
【００８３】
改ざんチェック装置側で不要なファイルを除外するように設定されていない場合には、図１５のステップＳ１５０５Ｎｏによりフローチャートを完了し、呼出側である図１４のステップＳ１４０５Ｃｏｐｙブロック処理手段の終了時点に戻る。
【００８４】
なお、図１５のフローチャートでは、ステップＳ１５０８とステップＳ１５０５により、原本ファイルから不要ファイルを除外する処理が、ＳＣＭサーバ側か改ざんチェック装置側か判定しているが、このような判定せず一方に固定的に実装する、あるいは両方で（同一、あるいは異なる除外設定で）除外処理をする、などの実装が可能であることは言うまでもない。その他、図１５は様々な実現方法があり、本フローチャートは、原本ファイルをＳＣＭサーバから抽出する実装の一例に過ぎない。
【００８５】
図１６は、アプリケーション動作サーバからアプリケーションファイル群を取得するプログラムである。このフローチャートを実行するのは、前述したようにコピーブロック１３２１のＴｙｐｅ属性１３２２のようにＴｙｐｅ属性の値が“Ｅｘｅｃｕｔｉｏｎ”である場合である。フローチャート１６０１が改ざんチェック装置、フローチャート１６０２がアプリケーション動作サーバにおけるプログラムの処理であり、協調して動作する。
【００８６】
ステップＳ１６０３チェック対象抽出手段は、Ｓｅｒｖｅｒ属性１３２３の値￥￥Ｓｒｖ０１￥ｃ：￥Ｋｅｉｒｉ（サーバ名￥フォルダ名）に格納されているアプリケーションファイルを抽出するようステップＳ１６０７アプリケーション側ファイル抽出手段に要求する（リクエスト１６１１）。ステップＳ１６０７アプリケーション側ファイル抽出手段は要求通り、アプリケーション動作サーバ“￥￥Ｓｒｖ０１”のフォルダ“ｃ：￥Ｋｅｉｒｉ”からアプリケーションファイルを抽出する。
【００８７】
アプリケーション動作サーバ側で不要なファイルを除外するように設定されている場合には、ステップＳ１６０８ＹｅｓによりステップＳ１６０９アプリケーション側不要ファイル除外手段に進み、改ざんチェックの処理対象として不要なファイルが除外される。この際、除外ファイル設定としては、ＥｘｃｌｕｄｅＦｉｌｅｓ属性１３２５で定義された値“Ｅｘｃｌｕｄｅ．ｄｅｆ”を設定ファイル名として利用する。実際に、ファイルを削除する、別のフォルダに移動する、あるいはファイル自体は元の位置に存在するが改ざんチェック時に利用しないよう一覧表に残すなど、除外方法は、物理的なもの、論理的（仮想的）なもの限定しない。その後、ステップＳ１６１０アプリケーション側ファイル送信手段に進む。
【００８８】
アプリケーション動作サーバ側で不要なファイルを除外するように設定されていない場合には、ステップＳ１６０８ＮｏによりステップＳ１６１０アプリケーション側ファイル送信手段に進む。
【００８９】
ステップＳ１６１０アプリケーション側ファイル送信手段では、ステップＳ１６０７アプリケーション側ファイル抽出手段で抽出したファイルを、アプリケーション動作サーバ側から改ざんチェック装置側に送信する。実際の送信方法としては、ｓｅｎｄ属性１３２７に定義された“ｓｅｎｄ．ｅｘｅ”を利用する。ステップＳ１６０９アプリケーション側不要ファイル除外手段を実行した場合には不要ファイルを除外した残りのファイルを送信する（送信１６１２）。
【００９０】
送信されたファイルは、改ざんチェック装置側においてステップＳ１６０４チェック対象受信外部手段により受信される。実際の受信方法としては、ｒｅｃｅｉｖｅ属性１３２６に定義された“ｒｅｃｅｉｖｅ．ｅｘｅ”を利用する。受信されたファイル群は、ＷｏｒｋＦｏｌｄｅｒ属性１３２４に指定された値“Ｃ：￥Ｃｏｍｐａｒｅ￥Ｅｘｅｃ￥Ｋｅｉｒｉ０１”に格納する。
【００９１】
次に改ざんチェック装置側で不要なファイルを除外するように設定されている場合には、ステップＳ１６０５ＹｅｓによりステップＳ１６０６アプリケーション側不要ファイル除外手段に進み、改ざんチェックの処理対象として不要なファイルが除外される。
【００９２】
実際に、ファイルを削除する、別のフォルダに移動する、あるいはファイル自体は元の位置に存在するが改ざんチェック時に利用しないよう一覧表に残すなど、除外方法は、物理的なもの、論理的（仮想的）なもの限定しないのはステップＳ１６０９ＳＣＭサーバ側原本不要ファイル除外手段と同様である。これにより図１６のフローチャートを完了し、呼出側である図１４のステップＳ１４０５Ｃｏｐｙブロック処理手段の終了時点に戻る。
【００９３】
改ざんチェック装置側で不要なファイルを除外するように設定されていない場合には、図１６のステップＳ１６０５Ｙｅｓによりフローチャートを完了し、呼出側である図１４のステップＳ１４０５Ｃｏｐｙブロック処理手段の終了時点に戻る。
【００９４】
なお、図１６のフローチャートでは、ステップＳ１６０８とステップＳ１６０５により、アプリケーションファイルから不要ファイルを除外する処理が、アプリケーション動作サーバ側か改ざんチェック装置側か判定しているが、このような判定せず一方に固定的に実装する、あるいは両方で（同一、あるいは異なる除外設定で）除外処理をする、などの実装が可能であることは言うまでもない。その他、図１６は様々な実現方法があり、本フローチャートは、アプリケーション動作に存在するアプリケーションファイルを抽出する実装の一例に過ぎない。
【００９５】
図１７は、原本ファイル群とアプリケーションファイル群を比較するプログラムのフローチャートである。ステップＳ１７０１では、全ファイルの比較結果を格納するメモリ上の構造のルートを作成する。これは、図１９の比較結果情報１９０１で表される。図１９および図２０については、図１７、図１８と会わせて随時説明する。本フローチャートは例えば、シナリオファイル１３０１（図１３）のコンペアブロック１３０４（ブロック１３３１の値によりコンペアブロックと定義）に従って動作する。
【００９６】
ステップＳ１７０２からステップＳ１７１１は、原本ファイル側を中心として、対応するアプリケーションファイルの存在、内容、属性などをチェックする繰り返し処理である。
【００９７】
ステップＳ１７０３では、チェック対象とする原本ファイルから１つを取り出し着目する。原本ファイルは図１３の例では、１３３４ＯｒｉｇｉｎａｌＦｏｌｄｅｒ属性の値“Ｃ：￥Ｃｏｍｐａｒｅ￥Ｏｒｉｇｉｎａｌ￥Ｋｅｉｒｉ”に格納されている。以下の説明では、例として図２０の対象２００６“ｔｏｏｌ．ｊａｒ”に着目する。ステップＳ１７０４では、ステップＳ１７０３で着目したファイル（原本と比較対象）の比較結果を格納する総合結果１９０３（図１９）を生成する。項目「対象」に着目中の対象“ｔｏｏｌ．ｊａｒ”を格納する。
【００９８】
次にステップＳ１７０５では、着目中の原本ファイルに対応するアプリケーションファイルが存在すれば取得する。本ファイルは図１３の例では、１３３５ＥｘｅｃＦｏｌｄｅｒ属性の値“Ｃ：￥Ｃｏｍｐａｒｅ￥Ｅｘｅｃ￥Ｋｅｉｒｉ０１”に格納されている。
【００９９】
ステップＳ１７０６からステップＳ１７０９は、前述で着目した原本ファイル（例では“ｔｏｏｌ．ｊａｒ”）と対応するアプリケーションファイルを比較する処理であり、ループは、シナリオで指定された比較手段のそれぞれを順に処理するための繰り返し制御である。シナリオファイル１３０１の例では、比較手段として１３３７，１３３８，１３３９の３つが定義されている。
【０１００】
原本ファイルとアプリケーションファイル、シナリオで指定された比較手段が決定し、ステップＳ１７０７（詳細は図１８のフローチャート）にて実際の比較が行われる。比較方法の詳細は図１８で説明するが、比較処理は原本ファイルに対応するアプリケーションファイルが存在しなくても実行可能であるか、あるいは比較できない旨を返す。図１９の例では、“ｔｏｏｌ．ｊａｒ”に対して、まず比較ツール“ｆｃ”が実行され、その結果が図１９の比較結果１９０４となり、ステップＳ１７０８で総合結果１９０３に関連付けられる。同様に、“ｓｉｚｅ”，“ｃｒｅａｔｅ＿ｄａｔｅ”が順に実行され、その結果が比較結果１９０５，比較結果１９０６となり、総合結果１９０３に関連付けられる。ステップＳ１７１０では、３つの比較内容１９０４，１９０５，１９０６が全て“○”（一致している）ため、１９０３の総合結果も“○”（一致している）となる。すなわち“ｔｏｏｌ．ｊａｒ”に対する総合結果は、図１９の総合結果１９０２のようになる。
【０１０１】
同様に，図１９では例として“ｖｉｅｗ．ｊａｒ”に対してステップＳ１７０４からステップＳ１７０９を実行した結果が図１９の総合結果１９０７を得る。総合結果１９０２および総合結果１９０７は，いずれも比較結果情報１９０１に関連付けられる（格納される）。“ｖｉｅｗ．ｊａｒ”は、“ｆｃ”と“ｃｒｅａｔｅ＿ｄａｔｅ”の比較結果が“×”（一致しない）ので、総合結果１９０８も“×”（一致しない）とされている。以上の処理が全ての原本ファイルに対して繰り返される。
【０１０２】
さて、一方、アプリケーションファイル群には含まれるが、原本ファイル群には含まれないファイル，すなわち原本ファイルに非対応のアプリケーションファイルが存在する可能性がある。これらのファイルを処理するのが、ステップＳ１７１２からステップＳ１７２０である。まず、ステップＳ１７１２では、原本ファイルに非対応のアプリケーションファイルを収集する。
【０１０３】
ステップＳ１７１３からステップＳ１７２０のループは、アプリケーションファイル側に着目して比較していること、比較対象である原本ファイルが存在しないことが最初から明確であることを除き、ステップＳ１７０２からステップＳ１７１１のループ処理と同じである。
【０１０４】
ステップＳ１７１４において、非対応アプリケーションファイルの１つに着目する。ステップＳ１７１６において、非対応アプリケーションのみで比較処理（詳細は図１８）を実施し、ステップＳ１７１７では比較内容を総合結果に関連付ける（格納する）。原本ファイルが存在しないため、ステップＳ１７１９での総合結果は、“×”（一致しない）である。最後に前述の総合結果を図１９の１９０１比較情報結果に関連付ける（格納する）。
【０１０５】
全ての非対応のアプリケーションファイルに対してＳ１７１３からＳ１７２０のループで制御された処理を完了したら、図１７の処理、すなわち図１４のステップ１４０６Ｃｏｍｐａｒｅブロック処理手段を完了する。
さて、図１８は１つの比較手段に対して、１つの原本ファイルと対応する１つのアプリケーションファイルを比較するプログラムのフローチャートである。
【０１０６】
本フローチャートは、改ざんチェック装置のシナリオ実行手段５０２（図５）から呼び出される比較手段５０５または比較手段５１３の１つに対応する。シナリオに従い、チェック対象のファイル（原本ファイルとアプリケーションファイル）を比較対象として実行されるが、前述の通り比較対象ファイルの一方が存在しない場合もある。
【０１０７】
図１８のフローチャートは、大きく４つの部分に分かれる。まず、比較処理を行う際に比較対象となる２つのファイルのうち一方でも存在すれば実行可能な比較処理に対するステップである。すなわち、何らかのコマンドで、１つのファイルの属性を抽出することが可能であるが、２つのファイルから値を抽出後、それらの値が一致するかどうかを判定するものである。
【０１０８】
（１）ステップＳ１８０２からステップＳ１８０５は、このうち原本ファイルが存在する場合の処理である。（２）ステップＳ１８０６からステップＳ１８０９は、このうちアプリケーションファイルが存在する場合の処理である。両方存在する場合には（１）と（２）の両方を実行する。一方が存在しない場合でも、結果には空を設定しておくため、後述（３）の比較が可能である。（３）ステップＳ１８１０からステップＳ１８１３は原本ファイルとアプリケーションファイルの情報を比較する処理である。
【０１０９】
（４）ステップＳ１８１４からステップＳ１８１６は原本ファイルとアプリケーションファイルの両方を同時に処理対象とするため、２つのファイルが存在する場合に実行可能な比較手段を前提とした処理である。
【０１１０】
まず、ステップＳ１８０１は、比較のために使用する比較手段が、原本ファイルとアプリケーションファイルの２つが存在する必要があるか判断する。ファイルが２つ存在する必要がなければ、ステップ１８０１はＮｏを返し、上記（１）から（３）の処理を実行する（ステップＳ１８０２に進む）。ファイルが２つ存在する必要があれば、ステップ１８０１はＹｅｓを返し、上記（４）の処理を実行する（ステップＳ１８１４に進む）。
以下、例としてファイル“ｔｏｏｌ．ｊａｒ”に対してコマンド“ｓｉｚｅ”の処理を用いて説明する。
【０１１１】
最初に前記（１）の場合について説明する。ステップＳ１８０２で原本ファイルが存在するかどうか判定する。原本ファイルが存在すればステップＳ１８０３に進み、原本ファイル“ｔｏｏｌ．ｊａｒ”に対して“ｓｉｚｅ”ツールを実行し結果“１２，３４５”を得る。ステップＳ１８０３で得た値を、ステップＳ１８０４にて図１９の比較内容１９０５における“原本”に格納する。ここでは、“１２，３４５”が格納される。原本ファイルが存在しない場合には、ステップＳ１８０５にて、１９０５における“原本”に空白（値が得られなかったというマーク）を格納する。
【０１１２】
次に前記（２）の場合について説明する。ステップＳ１８０６でアプリケーションファイルが存在するかどうか判定する。アプリケーションファイルが存在すればステップＳ１８０７に進み、原本ファイル“ｔｏｏｌ．ｊａｒ”に対して“ｓｉｚｅ”ツールを実行し結果“１２，３４５”を得る。ステップＳ１８０７で得た値を、ステップＳ１８０８にて図１９の比較内容１９０５における“比較対象”に格納する。ここでは、“１２，３４５”が格納される。アプリケーションファイルが存在しない場合には、ステップＳ１８０９にて、１９０５における“比較対象”に空白（値が得られなかったというマーク）を格納する。
【０１１３】
次に前記（３）について説明する。ここでは、前記（１）および（２）で得た２つの値をステップＳ１８１０で比較する。比較において、両者とも“比較対象”が空白（値が得られなかったというマーク）ではない値が入っており、その両者の値が一致する場合のみ、ステップＳ１８１１Ｙｅｓとなり、ステップＳ１８１２に進む。ステップＳ１８１２では、図１９の例では、“比較内容”に“ｓｉｚｅ“を格納し、１９０５において、”原本“と”比較対象“のサイズがいずれも”１２，３４５”であるため、“結果”に“○”（一致する）を格納する。
【０１１４】
一方、原本あるいは比較対象の一方または双方の値が空白（値が得られなかったというマーク）あるいは、両方の値が得られたが一致しない場合（図１９の１９１１の例）では“比較内容”に“ｃｒｅａｔｅ＿ｄａｔｅ”、“結果”に“×”（一致しない）を格納する。
【０１１５】
次に前記（４）について説明する。前述の通りＳ１８０１にて“Ｙｅｓ”となるのは、比較に使用するコマンドが、原本ファイルとアプリケーションファイルの両方を同時に処理対象とするため、２つのファイルが存在する場合に実行可能な比較手段を前提とした処理である（例として２つのファイルの内容が一致することを確認する“ｆｃ”コマンド）。
【０１１６】
まずステップＳ１８１４では、ファイルが２つ存在することを確認する。ファイルが２つ存在した場合には、ステップＳ１８１５にて指定された比較手段を実行する。比較処理結果として“原本”および“比較対象”から、何らかの属性値を抽出するわけではないので、それぞれ“空白”が格納される（これはファイルが２つとも存在する場合でも同じである）。比較内容は例えば“ｆｃ”である（図１９の１９０４）。比較結果が等しければ“○”（一致する）、等しくなければ“×”（一致しない）が結果に格納される。何を持って等しい、等しくないとするかは、各比較手段における定義であり、本発明の改ざんチェック装置では比較手段（図５の５１３）を任意に定義できるため、本結果の定義も柔軟に定義できる。
一方、ファイルが２つ存在しなければステップＳ１８１７にて“結果”は“×”となる（図１９の１９０４）。
【０１１７】
以上により、原本ファイルとアプリケーションファイルに対して、個々の比較手段による比較（図１８）、シナリオに基づいた複数の比較手段による総合結果（図１７）、全ファイルに対する比較（図１４）の説明を完了する。
上記説明の中で、比較結果は図１９の形式でメモリ上に展開したが、この構成があくまで例であることは言うまでもない。
【０１１８】
さらに、これらの結果をファイルにレポート出力した例を図２０に示す。図２０は、１ファイル１行で出力している。また、レポートファイルを出力するにあたり、原本やチェック対象により一意的にレポートファイル名を割り当てる必要がある場合、１３３２Ｐｒｏｊｅｃｔ属性、１３３３ＥｘｅｃＳｅｒｖｅｒ属性の値を利用してファイル名を生成してもよい。またレポートファイルの出力先フォルダとして、１３３７ＲｅｐｏｒｔＦｏｌｄｅｒ属性の値を利用する。
【０１１９】
２００６“ｔｏｏｌ．ｊａｒ”は、２００３“ｆｃ”、２００４“ｓｉｚｅ”、２００５“ｃｒｅａｔｅ＿ｄａｔｅ”の３つの比較手段により、原本ファイル、アプリケーションファイルのいずれの値も一致しているため、総合結果２００１も“○”（一致している）となっている。
【０１２０】
一方、２００７“ｖｉｅｗ．ｊａｒ”は、２００３“ｆｃ”と“ｃｒｅａｔｅ＿ｄａｔｅ”の結果が異なるため、総合結果２００１も“×”（一致していない）となっている。
【０１２１】
さらに、２００８“ｃｏｎｔｒｏｌｅ．ｊａｒ”はアプリケーションファイルが存在していないため、総合結果に“Ｏｎｌｙ＿Ｏｒｇｎ”（原本ファイルしか存在しない）とマークされている。また、２０１２“ｍｏｄｕｌｅ￥ｍｏｄｅｌ．ｊａｒ”は、アプリケーションファイルしか存在していないため、総合結果に“Ｏｎｌｙ＿Ａｐｌ”（アプリケーションファイルしか存在しない）とマークされている。図２０のレポート出力が一例であることは言うまでもない。
以上、改ざんチェック装置における改ざんチェック処理の１つの実施例の説明を完了する。
【０１２２】
なお、以上の実施例では、比較の一方は、ＳＣＭサーバに格納され、原本性が確保された原本ファイルであるという前提で説明した。しかしながら、本発明を利用する環境において、必ずしも原本ファイルが利用できるわけではない。
この様な場合でも、同一のアプリケーションが複数のアプリケーション動作サーバで実行されていれば、相互に比較することができる。
【０１２３】
また、本実施例で使用したシナリオ（図１３の１３０１）は、１つの原本ファイル群、１つのアプリケーションファイル群を取得し、１回の比較を行ったが、図１４のフローチャートからこれらの処理を繰り返し実施できることは言うまでもない。例えば、まず経理システムの原本ファイル群を取得して、サーバ１にリリースされた経理アプリファイル群を取得し、前記原本ファイルと比較し、さらにサーバ２にリリースされた経理アプリファイル群を取得し、別な比較手段で原本ファイルと比較し、引き続き発注システムの原本ファイルからファイル群を取得し、サーバ３およびサーバ４にリリースされている発注システムのファイル群を取得して比較する、ということを繰り返すことが可能である。
【０１２４】
図１３においてブロック１３０２とブロック１３０３のいずれもアプリケーション動作サーバを設定し、比較することで「少なくとも一方だけが改ざんされた」という状況の発生を発見することができる。
【０１２５】
さらに、以上では、２つのファイル群（原本とアプリケーションファイル、２つのアプリケーションファイル）を比較したが、２つ以上のファイル群をいずれか１つを基準に比較することも可能である。この場合、原本ファイルがなくとも全てのアプリケーション動作環境が同一でない限り、何らかの改ざんが成されたとすることで、さらに改ざんチェックの精度を高めることも可能となる。
【０１２６】
また、本発明の目的は、以下の処理を実行することによって達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。
【０１２７】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１２８】
また、プログラムコードを供給するための記憶媒体としては、次のものを用いることができる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等である。または、プログラムコードを、ネットワークを介してダウンロードしてもよい。
【０１２９】
また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１３０】
更に、前述した実施形態の機能が以下の処理によって実現される場合も本発明に含まれる。即ち、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行う場合である。
【０１３１】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した各実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳなどが実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現する場合も含まれる。
【０１３２】
この場合、上記プログラムは、該プログラムを記憶した記憶媒体から直接、またはインターネット、商用ネットワーク、若しくはローカルエリアネットワーク等に接続された不図示の他のコンピュータやデータベースなどからダウンロードすることにより供給される。
【０１３３】
上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、ＯＳ（オペレーティングシステム）に供給されるスクリプトデータ等の形態から成ってもよい。
【符号の説明】
【０１３４】
１０１ ＳＣＭクライアント
１０２ ＳＣＭサーバ
１０３ 改ざんチェック装置
１０４ アプリケーション動作サーバ
１０５ アプリケーション動作サーバ
１０６ ネットワーク
２０１ ＣＲＴ
２０２ 入力デバイス
２０３ ＣＰＵ
２０４ ＲＡＭ
２０５ ＲＯＭ
２０６ 外部記憶装置
２０７ ネットワーク・インタフェース
２０８ バス
３０１ ＳＣＭクライアント
３０２ ワークスペース
３０３ ＳＣＭサーバ
３０４ リポジトリ
３０５ アプリケーション動作サーバ
３０６ アプリケーションフォルダ
３０７ 改ざんチェック装置
３０８ 抽出した原本ファイル
３０９ 抽出したアプリケーションファイル
３１０ レポート
【特許請求の範囲】
【請求項１】
ファイルデータの原本性を保証するソフトウェア構成管理システムからアプリケーション動作サーバ上にリリースされたファイルデータの改ざんを検出する改ざんチェック装置において、
原本データを取得する原本取得方法と、チェック対象となるリリースデータを取得するチェック対象取得方法と、前記取得した原本データとリリースデータの比較方法とを定義したシナリオを記憶するシナリオ記憶手段と、
前記シナリオ記憶手段に記憶された前記シナリオを読み込んで実行するシナリオ実行手段とを備え、
前記シナリオには、前記原本取得方法として少なくとも原本取得手段が指定され、前記チェック対象取得方法として少なくともチェック対象取得手段が指定され、前記比較方法として少なくとも１または複数の比較手段が指定され、
前記原本取得手段は、前記ソフトウェア構成管理システムから原本性が保証されたファイルデータを取得し、
前記チェック対象取得手段は、前記アプリケーション動作サーバ上にリリースされたチェック対象となるファイルデータを取得し、
前記１または複数の比較手段は、前記原本性が保証されたファイルデータと前記チェック対象となるファイルデータを比較し、
前記１または複数の比較手段による比較結果をレポートするレポート手段と、を有することを特徴とする改ざんチェック装置。
【請求項２】
前記原本取得手段および前記チェック対象取得手段は、
改ざんチェックの対象として不要なファイルを予め比較対象から除外することが可能であることを特徴とする請求項１に記載の改ざんチェック装置。
【請求項３】
ファイルデータの原本性を保証するソフトウェア構成管理システムからアプリケーション動作サーバ上にリリースされたファイルデータの改ざんを検出する改ざんチェック方法において、
シナリオ記憶手段が、原本データを取得する原本取得方法と、チェック対象となるリリースデータを取得するチェック対象取得方法と、前記取得した原本データとリリースデータの比較方法とを定義したシナリオを記憶するシナリオ記憶工程と、
シナリオ実行手段が、前記シナリオ記憶手段に記憶された前記シナリオを読み込んで実行するシナリオ実行工程とを備え、
前記シナリオには、前記原本取得方法として少なくとも原本取得手段が指定され、前記チェック対象取得方法として少なくともチェック対象取得手段が指定され、前記比較方法として少なくとも１または複数の比較手段が指定され、
原本取得工程は、前記ソフトウェア構成管理システムから原本性が保証されたファイルデータを取得し、
チェック対象取得工程は、前記アプリケーション動作サーバ上にリリースされたチェック対象となるファイルデータを取得し、
前記１または複数の比較工程は、前記原本性が保証されたファイルデータと前記チェック対象となるファイルデータを比較し、
レポート手段が、前記１または複数の比較工程による比較結果をレポートするレポート工程と、を有することを特徴とする改ざんチェック方法。
【請求項４】
請求項３に記載された改ざんチェック方法をコンピュータに実行させるためのプログラム。
【請求項５】
請求項４に記載された改ざんチェック方法をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１】
ファイルデータの原本性を保証するソフトウェア構成管理システムからアプリケーション動作サーバ上にリリースされたファイルデータの改ざんを検出する改ざんチェック装置において、
原本データを取得する原本取得方法と、チェック対象となるリリースデータを取得するチェック対象取得方法と、前記取得した原本データとリリースデータの比較方法とを定義したシナリオを記憶するシナリオ記憶手段と、
前記シナリオ記憶手段に記憶された前記シナリオを読み込んで実行するシナリオ実行手段とを備え、
前記シナリオには、前記原本取得方法として少なくとも原本取得手段が指定され、前記チェック対象取得方法として少なくともチェック対象取得手段が指定され、前記比較方法として少なくとも１または複数の比較手段が指定され、
前記原本取得手段は、前記ソフトウェア構成管理システムから原本性が保証されたファイルデータを取得し、
前記チェック対象取得手段は、前記アプリケーション動作サーバ上にリリースされたチェック対象となるファイルデータを取得し、
前記１または複数の比較手段は、前記原本性が保証されたファイルデータと前記チェック対象となるファイルデータを比較し、
前記１または複数の比較手段による比較結果をレポートするレポート手段と、を有することを特徴とする改ざんチェック装置。
【請求項２】
前記原本取得手段および前記チェック対象取得手段は、
改ざんチェックの対象として不要なファイルを予め比較対象から除外することが可能であることを特徴とする請求項１に記載の改ざんチェック装置。
【請求項３】
ファイルデータの原本性を保証するソフトウェア構成管理システムからアプリケーション動作サーバ上にリリースされたファイルデータの改ざんを検出する改ざんチェック方法において、
シナリオ記憶手段が、原本データを取得する原本取得方法と、チェック対象となるリリースデータを取得するチェック対象取得方法と、前記取得した原本データとリリースデータの比較方法とを定義したシナリオを記憶するシナリオ記憶工程と、
シナリオ実行手段が、前記シナリオ記憶手段に記憶された前記シナリオを読み込んで実行するシナリオ実行工程とを備え、
前記シナリオには、前記原本取得方法として少なくとも原本取得手段が指定され、前記チェック対象取得方法として少なくともチェック対象取得手段が指定され、前記比較方法として少なくとも１または複数の比較手段が指定され、
原本取得工程は、前記ソフトウェア構成管理システムから原本性が保証されたファイルデータを取得し、
チェック対象取得工程は、前記アプリケーション動作サーバ上にリリースされたチェック対象となるファイルデータを取得し、
前記１または複数の比較工程は、前記原本性が保証されたファイルデータと前記チェック対象となるファイルデータを比較し、
レポート手段が、前記１または複数の比較工程による比較結果をレポートするレポート工程と、を有することを特徴とする改ざんチェック方法。
【請求項４】
請求項３に記載された改ざんチェック方法をコンピュータに実行させるためのプログラム。
【請求項５】
請求項４に記載された改ざんチェック方法をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２０１２−５３６３５（Ｐ２０１２−５３６３５Ａ）
【公開日】平成２４年３月１５日（２０１２．３．１５）
【国際特許分類】
【出願番号】特願２０１０−１９５１３１（Ｐ２０１０−１９５１３１）
【出願日】平成２２年８月３１日（２０１０．８．３１）
【出願人】（３０１０１５９５６）キヤノンソフトウェア株式会社 (364)
【Ｆターム（参考）】
【公開日】平成２４年３月１５日（２０１２．３．１５）
【国際特許分類】
【出願日】平成２２年８月３１日（２０１０．８．３１）
【出願人】（３０１０１５９５６）キヤノンソフトウェア株式会社 (364)
【Ｆターム（参考）】
[ Back to top ]