(57)【特許請求の範囲】
【請求項１】
コンピュータ内のファイルなどのリソースに対するアプリケーションの入出力を監視する方法であって、
前記コンピュータ内に実装されたＩ／Ｏ監視手段が前記アプリケーションの起動を検出し、同コンピュータ内に実装されたアプリケーション認証手段に対し前記アプリケーションの認証を要求する第１のステップと、
前記アプリケーション認証手段が前記アプリケーションのハッシュ値を算出し、算出したハッシュ値と当該アプリケーション認証手段内の管理者により設定されるハッシュ管理テーブルに予め登録されているハッシュ値と照合し、前記アプリケーションが前記ハッシュ管理テーブルにハッシュ値が登録された正規のアプリケーションであるか否かを認証し、認証結果を前記Ｉ／Ｏ監視手段に通知する第２のステップと、
前記アプリケーションの認証結果の通知を受けた前記Ｉ／Ｏ監視手段が、認証成功の通知であった場合は前記アプリケーションと同一のプロセス空間に前記アプリケーションからのＩ／Ｏ要求を捕捉するためのフィルタ手段を挿入し、認証不成功の通知であった場合は前記アプリケーションを強制終了または管理者に通知する第３のステップと、
前記フィルタ手段が、前記アプリケーションからのＩ／Ｏ要求を捕捉した後、前記アプリケーション認証手段に対してＩ／Ｏ許可要求を発行する第４のステップと、
前記アプリケーション認証手段が、前記Ｉ／Ｏ許可要求に対して前記フィルタ手段が改ざんされていないかどうかを当該フィルタ手段自体のハッシュ値により認証し、さらに前記アプリケーションのハッシュ値を算出し、算出したハッシュ値と当該アプリケーション認証手段内の管理者により設定されるハッシュ管理テーブルに予め登録されているハッシュ値と照合し、前記アプリケーションが前記ハッシュ管理テーブルにハッシュ値が登録された正規のアプリケーションであるか否かを認証し、前記フィルタ手段と前記アプリケーションの両方が認証成功の場合のみ前記Ｉ／Ｏ監視手段に対し前記アプリケーションによるＩ／Ｏ要求の抑止状態の解除を要求し、前記フィルタ手段に捕捉されていたアプリケーションからのリソースに対するＩ／Ｏ要求を許可する第５のステップと
を備えることを特徴とするアプリケーションの監視方法。
【請求項２】
前記第５のステップにおいて、前記Ｉ／Ｏ要求の抑止状態の解除の要求を受けた前記Ｉ／Ｏ監視手段が、前記アプリケーション認証手段自体が改ざんされていないかどうかを当該アプリケーション認証手段自体のハッシュ値により認証し、認証成功の場合のみ前記フィルタ手段に捕捉されていたアプリケーションからのリソースに対するＩ／Ｏ要求を許可するステップを備えることを特徴とする請求項１に記載のアプリケーションの監視方法。
【請求項３】
コンピュータ内に実装されたＩ／Ｏ監視モジュール、アプリケーションモジュール及びフィルタモジュールとから構成され、コンピュータ内のファイルなどのリソースに対するアプリケーションの入出力を監視するためのプログラムであって、
前記Ｉ／Ｏ監視モジュールにより、前記アプリケーションの起動を検出し、同コンピュータ内に実装されたアプリケーション認証モジュールに対し前記アプリケーションの認証を要求する第１のステップと、
前記アプリケーション認証モジュールにより、前記アプリケーションのハッシュ値を算出し、算出したハッシュ値と当該アプリケーション認証モジュール内の管理者により設定されるハッシュ管理テーブルに予め登録されているハッシュ値と照合し、前記アプリケーションが前記ハッシュ管理テーブルにハッシュ値が登録された正規のアプリケーションであるか否かを認証し、認証結果を前記Ｉ／Ｏ監視モジュールに通知する第２のステップと、
前記アプリケーションの認証結果の通知を受けた前記Ｉ／Ｏ監視モジュールにより、認証成功の通知であった場合は前記アプリケーションと同一のプロセス空間に前記アプリケーションからのＩ／Ｏ要求を捕捉するためのフィルタモジュールを挿入し、認証不成功の通知であった場合は前記アプリケーションを強制終了または管理者に通知する第３のステップと、
前記フィルタモジュールにより、前記アプリケーションからのＩ／Ｏ要求を捕捉した後、前記アプリケーション認証モジュールに対してＩ／Ｏ許可要求を発行する第４のステップと、
前記アプリケーション認証モジュールにより、前記Ｉ／Ｏ許可要求に対して前記フィルタモジュールが改ざんされていないかどうかを当該フィルタモジュール自体のハッシュ値により認証し、さらに前記アプリケーションのハッシュ値を算出し、算出したハッシュ値と当該アプリケーション認証モジュール内の管理者により設定されるハッシュ管理テーブルに予め登録されているハッシュ値と照合し、前記アプリケーションが前記ハッシュ管理テーブルにハッシュ値が登録された正規のアプリケーションであるか否かを認証し、前記フィルタモジュールと前記アプリケーションの両方が認証成功の場合にのみ前記Ｉ／Ｏ監視モジュールに対し前記アプリケーションによるＩ／Ｏ要求の抑止状態の解除を要求し、前記フィルタモジュールに捕捉されていたアプリケーションからのリソースに対するＩ／Ｏ要求を許可する第５のステップと
をコンピュータに実行させることを特徴とするアプリケーションの監視プログラム。
【請求項４】
前記第５のステップにおいて、前記Ｉ／Ｏ要求の抑止状態の解除の要求を受けた前記Ｉ／Ｏ監視モジュールが、前記アプリケーション認証モジュール自体が改ざんされていないかどうかを当該アプリケーション認証モジュール自体のハッシュ値により認証し、認証成功の場合のみ前記フィルタモジュールに捕捉されていたアプリケーションからのリソースに対するＩ／Ｏ要求を許可するステップを備えることを特徴とする請求項３に記載のアプリケーションの監視プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータシステムあるいはネットワークコンピュータシステムにおけるファイルなどのリソースからの情報漏洩を防止するために不正なアプリケーションの入出力を監視する方法および該方法を実施するためのプログラムに関するものである。
【０００２】
【従来の技術】
従来、コンピュータのファイルから情報の漏洩を防止する方法としては、ファイル暗号が主流である。ファイル暗号は、特定のファイルを予め暗号化しておき、当該ファイルにアクセスする権限を有するユーザがファイルを参照した場合だけ当該ファイルを復号化する方法により、ユーザごとのファイルアクセスを制御する。
このファイル暗号の実現には、システムに常駐し、常時ファイルＩ／Ｏを監視しておく機能が必要である。前記機能の実現には高い特権レベルで動作するプログラムが必要となるが、これはデバイスドライバとして実現される。
【０００３】
ファイル暗号によるアクセス制御では、システムの低レベルな階層でファイルＩ／Ｏを監視するため、アプリケーションプログラム（以下、単にアプリケーションと略記）によるファイルの利用を全て許可するか、全く利用させないかの２種類の選択肢だけしかユーザに与えることできない。従って、例えば、特定のアプリケーションにおけるプリント機能の実行を禁止するような詳細なアクセス制御を実施するのが大変困難である。
【０００４】
そこで、特願平２００１−０９１３４９号（本願発明と同一出願人）では、ユーザと等価な特権レベルで動作するプログラムを提供する方法を提案している。このプログラムは、ユーザが起動するアプリケーションのプロセス中に挿入されるフィルタモジュールであり、アプリケーションからシステムのＡＰＩの利用を捕捉・制限する機能を持たせることにより、アプリケーションの詳細なアクセス制御を実現するものである。
しかし、この提案におけるフィルタモジュールではユーザが起動するアプリケーションがどういうアプリケーションかを判断できない。例えば、特定のフォルダへのアクセスを許可するアプリケーションは特定のワードプロセッサだけに限定したい場合を想定する。この場合、特定のワードプロセッサを識別する情報としては実行可能ファイルの絶対パスが考えられるが、このパスに別のワードプロセッサの実行可能ファイルを置き換えることも可能である。この場合、ファイルＩ／Ｏを監視しておき、ワードプロセッサの実行可能ファイルを置き換える処理を禁止するように制御することが考えられるが、ディスクを取り外し、別のコンピュータに接続してファイルを置き換えることも可能である。
【０００５】
また、データの改ざんを検出する方法としてハッシュ関数を利用するのが一般的である。ハッシュ関数は任意の長さのメッセージを固定長のハッシュに変換する。この方法を利用する場合、予め正規のメッセージのハッシュ値を取得しておき、これと検査対象となるメッセージのハッシュ値とを比較することでメッセージが改ざんされていないか検証できる。ハッシュ関数を利用するメッセージ認証は主にインターネットでのメールの交換等でメールの受信者がメールの送信者確認や第３者によるメールの改ざんを検証するために利用されている。メール等ではメッセージの受信をトリガーにしてハッシュ値を算出することが容易に行える。
【０００６】
【発明が解決しようとする課題】
前記の通り、アプリケーションの実行コードの中にフィルタモジュールを挿入する方法にあっては、メモリ中にロードされたアプリケーションやフィルタモジュールが改ざんされることにより、情報漏洩防止機能が無効化される問題があり、情報漏洩防止機能をさらに確実なものとするためにはアプリケーションが正規のアプリケーションであるか否かを識別する必要がある。
【０００７】
また、アプリケーションを識別するにしたとしても、アプリケーションの認証のトリガー（認証の契機）を決定するのが大変困難である。理想的には、アプリケーションが１ステップ実行されるたびにアプリケーションの認証を実行する方法が一番確実であるが、実行速度やパフォーマンスが低下するため、認証の頻度を下げなければ実用に耐えられない。特願平２００１−０９１３４９号の例では、アプリケーションはシステムのＡＰＩの利用を制限する必要があるため、フィルタモジュールを中継させてシステムのＡＰＩを呼び出している。ユーザの特権レベルで動作する不正なプログラムが他のプロセスに入出力するためには、システムの提供するＡＰＩを利用する必要がある。すなわち、アプリケーションがシステムのＡＰＩを実行する前には必ずアプリケーションの認証を実施する必要がある。
しかし、全てのシステムのＡＰＩでアプリケーションの認証を実行する方法では、呼び出される回数が非常に多くなるため、アプリケーションの認証処理がシステムの負荷を高めることになる。それを解決するためには、クリティカルな制御が必要なシステムで非同期的に発生するアプリケーション認証を処理することが必要になる。
【０００８】
本発明の目的は、システムのパフォーマンスを落とすことなく、効率的にアプリケーションの認証を実施し、ファイルなどのリソースの情報漏洩防止機能をさらに確実なものにすることができるアプリケーションの監視方法および該方法を実施するためのプログラムを提供することである。
【０００９】
【課題を解決するための手段】
上記目的を達成するために、本発明のアプリケーションの監視方法は、アプリケーションの起動を検出する第１のステップと、起動されたアプリケーションから発行された前記リソースに対する処理要求を一時保留する第２のステップと、起動されたアプリケーションが正規のアプリケーションであるか否かを認証する第２のステップと、起動されたアプリケーションの認証結果が認証成功の場合にのみ、前記一時保留した処理要求による処理を許可する第３のステップとを備えることを特徴とする。
また、前記第２のステップが、メモリ中にロードされたアプリケーションのコード中に当該アプリケーションを任意ステップ数ずつ実行させるためのコードを挿入する第４のステップをさらに備えることを特徴とする。
また、前記第４のステップが、前記任意ステップ数ごとに正規のアプリケーションか否かを認証する処理を実行する第５のステップをさらに備えることを特徴とする。
また、前記第５のステップが、不正なアプリケーションを検出した場合に、不正なアプリケーションの処理を禁止する第６のステップとをさらに備えることを特徴とする。
また、前記第６のステップが、アプリケーションの起動時等に不正なアプリケーションを検出したことを管理者に通知する第７のステップをさらに備えることを特徴とする。
また、前記第６のステップが、アプリケーションの起動時等に不正なアプリケーションを検出した場合に、外部のコンピュータから正規のアプリケーションをダウンロードし、不正なアプリケーションに置き換えて実行させる第８のステップとをさらに備えることを特徴とする。
また、前記第５のステップが、処理要求単位に処理をグループ化し、該当する処理の初期化時および終了時にだけ、または書込み処理時にだけ不正なアプリケーションを認証する処理を実行させる第９のステップとをさらに備えることを特徴とする。
また、前記第５のステップが、処理要求に対する処理の初期化時にファイルのバックアップを行い、当該バックアップファイルへのアクセスをブロックする処理を実行する第１０のステップとをさらに備えることを特徴とする。
また、前記第１のステップが、アプリケーションがロードされるメモリの同一プロセス空間に、当該アプリケーションの処理要求を一時保留するフィルタモジュールを挿入するステップをさらに備えることを特徴とする。
【００１０】
本発明に係るアプリケーション監視用のプログラムは、アプリケーションの起動を検出する第１のステップと、起動されたアプリケーションから発行された前記リソースに対する処理要求を一時保留する第２のステップと、起動されたアプリケーションが正規のアプリケーションであるか否かを認証する第２のステップと、起動されたアプリケーションの認証結果が認証成功の場合にのみ、前記一時保留した処理要求による処理を許可する第３のステップとを含むことを特徴とする。
【００１１】
【発明の実施の形態】
以下、本発明の一実施の形態を、図面を用いて詳細に説明する。
図１は、本発明の一実施の形態を示すシステム構成図である。この実施形態は、特願平２００１−０９１３４９号で提案している方法（機密ファイル持ち出し禁止方法）に本発明を適用したものである。
図１に示すシステムでは、ユーザコンピュータが各種の業務処理等に利用する全ての業務アプリケーション１０１に、フィルタモジュール１０２を当該業務アプリケーション１０１と同一のプロセス空間内に挿入する。フィルタモジュール１０２は、業務アプリケーション１０１がシステム（ＯＳ）の提供するＡＰＩを利用して行うＩ／Ｏ処理を全て捕捉する機能を保持している。本実施形態では、このＩ／Ｏ処理の捕捉機能を利用して、情報漏洩に関連するシステムのＡＰＩの利用をキャンセルすることにより情報漏洩防止を実現する。
【００１２】
また、ユーザコンピュータ上には、アプリケーション認証モジュール１０３がコンピュータ起動時に自動的に稼動する。このアプリケーション認証モジュール１０３は、業務アプリケーション１０１やフィルタモジュール１０２のメモリ中の実行コードイメージが外部の不正なプログラムにより改ざんされるのを防止するため、常時、業務アプリケーション１０１を監視する機能を保持している。
【００１３】
アプリケーション認証モジュール１０３は、内部にハッシュ管理テーブル１０９を保持しており、特定の業務アプリケーションに関するハッシュ値を格納する。
ハッシュ管理テーブル１０９は管理者が自由に設定できるように、ネットワークを介して管理者のコンピュータから自動的に設定をダウンロードすることができるようになっている。また、ユーザがハッシュ管理テーブル１０９に不正にアクセスできないように、メモリ中のハッシュ管理テーブル１０９の領域にはアクセスできないような構成になっている。
【００１４】
また、ユーザコンピュータ上には、Ｉ／Ｏ監視モジュール１０４がコンピュータ起動時に自動的に稼動する。Ｉ／Ｏ監視モジュール１０４は、システムの内部で発生するすべての低レベルなＩ／Ｏを捕捉するモジュールであり、一種のドライバとして動作する。
低レベルなＩ／Ｏには、ハードウェアへのＩ／Ｏを含んでおり、Ｉ／Ｏ監視モジュール１０４で捕捉するＩ／Ｏ要求をキャンセルすることにより、システムのＩ／Ｏをブロックすることと同等の機能が実現される構成になっている。
Ｉ／Ｏ監視モジュール１０４は、内部にプロセス管理テーブル１１０を保持しており、ユーザが利用しているコンピュータ上で稼動する全てのプロセスのファイルＩ／Ｏのパーミッションを管理する。
【００１５】
また、ユーザコンピュータ上には、機密フォルダ１０５、一般フォルダ１０６、ネットワークドライブ１０７、その他の書込み可能なメディア１０８といったＩ／Ｏの対象がディスク内に存在する。これらのドライブへのＩ／Ｏは全てＩ／Ｏ監視モジュール１０４を中継して行われる。
【００１６】
図２は、アプリケーション監視モジュール１０４が業務アプリケーション１０１の改ざんを監視する仕組を示す図である。
ユーザコンピュータ上で稼動する業務アプリケーション１０１は、最初にファイルＩ／Ｏイベントを発行する。この業務アプリケーション１０１と同一のプロセス空間の内部で稼動中のフィルタモジュール１０２は、業務アプリケーション１０１が発行したファイルＩ／Ｏイベントを捕捉し、Ｉ／Ｏ監視モジュール１０４にファイルＩ／Ｏ要求を転送してよいか判断するため、アプリケーション認証モジュール１０３にＩ／Ｏ許可要求を発行する。
【００１７】
アプリケーション認証モジュール１０３は、Ｉ／Ｏ許可要求を受信すると、業務アプリケーション１０１やフィルタモジュール１０２が不正プログラム２０１により、改ざんされていないかチェックし、もし改ざんされている場合にはファイルＩ／Ｏをキャンセルする。ここで、業務アプリケーション１０１やフィルタモジュール１０２が不正プログラム２０１により、改ざんされているかどうかは、後述するように、例えば、業務アプリケーション１０１のハッシュ値あるいはフィルタモジュール１０２を含む業務アプリケーション１０１のハッシュ値が正規の値であるか否かによって判断する。
【００１８】
アプリケーション認証モジュール１０３は、業務アプリケーション１０１が改ざんされていないと判断したならば、Ｉ／Ｏ監視モジュール１０４にＩ／Ｏブロックの解除要求を出し、Ｉ／Ｏの許可を要求する。
Ｉ／Ｏ監視モジュール１０４は、ディスク２０２内に存在する機密フォルダ等へのすべてのＩ／Ｏを捕捉しており、アプリケーション認証モジュール１０３の認証を受けていない業務アプリケーション１０１からのＩ／Ｏに対しては、これを全てブロックする。しかし、認証を受けた業務アプリケーション１０１からのI／Ｏについてはブロックしない。
【００１９】
ここで、不正プログラム２０１がアプリケーション認証モジュール１０３自体を改ざんし、アプリケーションの認証機能自体を無効にすることも考えられる。そこで、本実施形態では、後述するように、Ｉ／Ｏ監視モジュール１０４がアプリケーション認証モジュール１０３を認証するようにしている。この認証処理は、例えば正規のアプリケーション認証モジュール１０３のハッシュ値をＩ／Ｏ監視モジュール１０４内に登録しておき、アプリケーション認証モジュール１０３からＩ／Ｏブロックの解除要求を受けた時、要求元のアプリケーション認証モジュール１０３のハッシュ値を算出し、予め登録していたハッシュ値と比較することにより実現している。
【００２０】
アプリケーション認証モジュール１０３は、Ｉ／Ｏ監視モジュール１０４からＩ／Ｏ許可を受け、Ｉ／Ｏブロックを解除することに成功すると、フィルタモジュール１０２にＩ／Ｏ許可を発行する。フィルタモジュール１０２は、アプリケーション認証モジュール１０３からのＩ／Ｏ許可を受信できた場合にだけ、Ｉ／Ｏ監視モジュール１０４にＩ／Ｏを転送し、ディスクアクセスが可能になる。
ここで、アプリケーション認証モジュール１０３からＩ／Ｏ許可を受信した後に不正プログラム２０１により業務アプリケーション１０１やフィルタモジュール１０２が改ざんされる可能性がある。
しかし、本実施形態では、アプリケーション認証モジュール１０３がメモリ中にロードされた業務アプリケーション１０１中に、ソフトウェアブレイクポイント等の１ステップずつ実行または任意数ステップ数ずつ実行させるコードを挿入することにより、業務アプリケーション１０１やフィルタモジュール１０２が１ステップ実行されるごとに、または任意数ステップ実行されるごとに、業務アプリケーション１０１の認証を実施する構成としている。このため、フィルタモジュール１０２が実際にファイルＩ／Ｏを実行するまでの間は業務アプリケーション１０１の認証を継続して行うことが可能になっている。
これにより、業務アプリケーション１０１やフィルタモジュール１０２が改ざんされ、この改ざんされた業務アプリケーション１０１によって機密フォルダ１０５等の情報が不正に取得されるのを防止することができる。
【００２１】
本実施形態では、実行性能面を考慮して、業務アプリケーション１０１がシステムの提供するＡＰＩを呼び出すのを単位に業務アプリケーション１０１の認証を行う方法を示しているが、この仕組は利用者のセキュリティポリシによって、任意数のステップ実行毎に行うなど、動的に変更することが可能である。
【００２２】
図３はフィルタモジュール１０２やＩ／Ｏ監視モジュール１０４がファイルＩ／Ｏをブロックする仕組を示す図である。
ユーザコンピュータ上で稼動する業務アプリケーション１０１は、ファイルＩ／Ｏイベントを発行する。この業務アプリケーション１０１と同一のプロセス空間の内部で稼動中のフィルタモジュール１０２は、業務アプリケーション１０１が発行したファイルＩ／Ｏイベントを捕捉し、Ｉ／Ｏ監視モジュール１０４にファイルＩ／Ｏ要求を転送してよいか判断するため、アプリケーション認証モジュール１０３にＩ／Ｏ許可要求を発行する。
【００２３】
図２と異なるのは、不正プログラム３０１が業務アプリケーション１０１やフィルタモジュール１０２を改ざんしたり、業務アプリケーション１０１と同一のプロセス空間に不正コード３０２をロードする点である。この場合、アプリケーション認証モジュール１０３は、フィルタモジュール１０２からのＩ／Ｏ許可要求を受信しても、業務アプリケーション１０１やフィルタモジュール１０２が改ざんされていたり、業務アプリケーション１０１と同一のプロセス空間に不正コード３０２が挿入されている場合には、業務アプリケーション１０１の認証が失敗するので、ファイルＩ／Ｏ要求を却下する。
また、不正コード３０２から直接ファイルＩ／Ｏを実行しようとする場合でも、Ｉ／Ｏ監視モジュール１０４は、アプリケーション認証モジュール１０３の認証を受けていないＩ／ＯとしてＩ／Ｏ要求をキャンセルする。これにより、不正な情報取得行為は失敗し、情報漏洩を防止することができる。
【００２４】
図４は、Ｉ／Ｏ監視モジュール１０４が業務アプリケーション１０１のロードを検出し、業務アプリケーション１０１と同一のプロセス空間にフィルタモジュール１０２を挿入する仕組を示す図である。
Ｉ／Ｏ監視モジュール１０４は、システムがプロセスを作成する処理を監視し、業務アプリケーション１０１のプロセス起動時には、業務アプリケーション１０１と同一のプロセス空間にフィルタモジュール１０２を挿入するが、業務アプリケーション１０１のプロセスが起動してフィルタモジュール１０２が挿入されるまでの間に不正プログラム等による業務アプリケーション１０１への不正なアクセスを回避するため、Ｉ／Ｏ監視モジュール１０４はアプリケーション認証モジュール１０３に対して、業務アプリケーション１０１の認証を要求する。
業務アプリケーション１０１の認証が成功し、正規のアプリケーションが起動したことがアプリケーション認証モジュール１０３により保証された場合にだけ、すなわち、アプリケーション認証モジュール１０３から認証成功のメッセージを受信した場合にのみ、Ｉ／Ｏ監視モジュール１０４はフィルタモジュール１０２の挿入を実行する。
【００２５】
Ｉ／Ｏ監視モジュール１０４は、業務アプリケーション１０１の認証が失敗した場合には、業務アプリケーション１０１のプロセスを強制的に終了させることもできるし、管理者に報告することも可能である。図３の場合と同様にセキュリティポリシによりＩ／Ｏ監視モジュール１０４の実現方法は柔軟に変更することができる。
【００２６】
図５は、アプリケーション認証モジュール１０３が業務アプリケーション１０１の正当性をチェックするための１つの手段として、業務アプリケーション１０１の実行コードイメージのハッシュ値を利用する仕組を示す図である。
業務アプリケーション１０１がファイルＩ／Ｏイベントを発行すると（図５の（１））、フィルタモジュール１０２がファイルＩ／Ｏを捕捉する。これは図３と同様である。
図３では、フィルタモジュール１０２がすべてのシステムＡＰＩに対してアプリケーション認証を実行する例を示したが、このような実装はシステムの実行速度に悪影響が生じる可能性がある。
【００２７】
そこで、本実施形態では、すべてのＡＰＩに対してアプリケーション認証を行う方法だけでなく、特定のＡＰＩを利用する場合にだけアプリケーション認証を実行する仕組を示す。
この図５においては、フィルタモジュール１０２が、Createフィルタ５１１、Readフィルタ５１２、Writeフィルタ５１３、Closeフィルタ５１４で構成されている。
Createフィルタ５１１とは、業務アプリケーションが新規にファイルを作成するＡＰＩや既存のファイルを開くＡＰＩを補足する機能を保持している。例えばWindows（マイクロソフト社の登録商標）では、CreateFileやOpenFileといったＡＰＩがこのCreateフィルタ５１１の捕捉対象となる。
Readフィルタ５１２とは、業務アプリケーションが参照中のファイルからデータを読み込むＡＰＩを補足する機能を保持している。例えばWindows（マイクロソフト社の登録商標）では、ReadFileといったＡＰＩがこのReadフィルタ５１２の捕捉対象となる。
Writeフィルタ５１３とは、業務アプリケーションが参照中のファイルにデータを書き込むＡＰＩを補足する機能を保持している。例えばWindows（マイクロソフト社の登録商標）では、WriteFileといったＡＰＩがこのWriteフィルタ５１３の捕捉対象となる。
Closeフィルタ５１４とは、業務アプリケーションが参照中のファイルのハンドルを閉じるＡＰＩを補足する機能を保持している。例えばWindows（マイクロソフト社の登録商標）では、CloseHandleといったＡＰＩがこのCloseフィルタ５１４の捕捉対象となる。
図５の例ではファイルＩ／Ｏの初期化時、つまりファイルやハンドルのCreate系を処理する特定のＡＰＩが呼ばれた場合にだけ、アプリケーション認証モジュール１０３を介してアプリケーション認証を実行する。
【００２８】
Ｉ／Ｏ監視モジュール１０４は、アプリケーション認証モジュール１０３による認証が成功し、Ｉ／Ｏブロックを解除する要求を受信すると、業務アプリケーション１０１の認証モジュール１０３自体の認証とファイルのバックアップを実行する。
【００２９】
ここで、不正プログラムをファイルＩ／Ｏの初期化以降に埋め込むことは可能であり、実際に開かれているファイルに対して不正なデータを書き込むことは可能である。しかし、不正プログラムが別のファイルを開き、現在開いているファイルを不正にコピーしようとする場合、別のファイルを新たに開く必要がある。そして、別のファイルを開く時には再び業務アプリケーション１０１の認証を実行する必要があるため、この時点でアプリケーション認証は失敗し、不正プログラムが挿入されていることを検出できる。
また、既存のファイルを不正に編集した場合でも、フィルタモジュール１０２がファイルやハンドルのClose系のＡＰＩを実行するためにアプリケーション認証モジュール１０３に問い合わせを行うときに業務アプリケーション１０１やフィルタモジュール１０２が改ざんされている事実を検出できる。不正なファイルの編集を発見したときには、管理者に通知したり、バックアップしてあるファイルからファイルの復元を行うことが可能である。また、ファイルＩ／Ｏの初期化以降に挿入された不正プログラムは、Ｉ／Ｏ監視モジュール１０４に直接Ｉ／Ｏを転送することもできる。ただし、Ｉ／Ｏ監視モジュール１０４でＩ／Ｏが許可されているのは、アプリケーション認証モジュール１０３により認証を受けたフォルダに限定される。つまり、Create系のＡＰＩを実行して開かれているファイルだけしかＩ／Ｏを行うことができないため、他のファイルに書き込むことはできない。
【００３０】
ユーザが複数のファイルを開いた後で、不正プログラムを業務アプリケーション１０１やフィルタモジュール１０２に挿入する場合も考えられる。この場合、情報を持ち出したいファイルと持ち出す先のファイルを同時に開いた後で不正プログラムを挿入すれば、不正プログラムは両方のファイルにRead系のＡＰＩやWrite系のＡＰＩを実行できるので、一見情報を漏洩することが可能に見える。しかし、特願平２００１−０９１３４９号で提案しているように、情報を漏洩されたくないファイルは機密フォルダ（１０５）に格納し、一度機密フォルダを開いた業務アプリケーション１０１は機密フォルダ以外にアクセスを許さないという構成にすることにより、不正プログラムは情報を持ち出すことができない。
【００３１】
本実施形態では、１例として、Create系のＡＰＩとClose系のＡＰＩでアプリケーションの認証を行う方法を示したが、Write系のＡＰＩでアプリケーションの認証を行うことも可能である。もっとも確実な方法は、すべてのＡＰＩが実行されるたびに業務アプリケーション１０１の認証を実行することである。
さらに確実な方法は、業務アプリケーション１０１の１ステップ実行ごとに業務アプリケーション１０１の認証を行うことである。ただし、セキュリティポリシとシステムのパフォーマンスに応じて動的に実現方法を変更することが重要であり、本発明はすべての実現方法に対応することができる。
【００３２】
図６は、アプリケーション認証モジュール１０３が管理するハッシュ管理テーブルの構成を示す図である。ここで例示するハッシュ管理テーブル１０９は、Application（６０１）、Hash Value（６０２）、Exe File Path（６０３）の属性を保持している。
アプリケーション認証モジュールはApplication属性６０１を見て該当する業務アプリケーション１０１を区別する。業務アプリケーション１０１のプロセスの起動時には、Exe File Path属性を見て起動パスが正しいものか判断し、Hash Valueを見てアプリケーションの整合性を実行コードイメージレベルでチェックする。
【００３３】
管理者はハッシュ管理テーブル１０９を作成し、ネットワーク等を利用して各ユーザコンピュータに配布することが可能である。このとき、ネットワーク中のデータを改ざんされたり、ユーザコンピュータに配布されたハッシュ管理テーブル１０９は不正なユーザや不正なプログラムにより改ざんされないように、アクセス管理がなされていることを前提とし、ユーザコンピュータが終了した場合には削除される。
【００３４】
図７は、Ｉ／Ｏ監視モジュール１０４が管理するプロセス管理テーブル１１０の構成を示す図である。
ここで例示するプロセス管理テーブル１１０は、Process（７０１）、Permission（７０２）、I/O File Path（７０３）の属性を保持している。
Ｉ／Ｏ監視モジュール１０４は、Process属性を見て該当するアプリケーションを区別する。アプリケーション認証モジュール１０３によって認証を受けた業務アプリケーション１０１は、I/O File Path属性に登録されたファイルにPermission属性が許可（ＴＲＵＥ）の場合にだけ当該アプリケーションのファイルＩ／Ｏが許可される。すなわち、不正プログラムや不正プログラムによって改ざんされた業務アプリケーションは、Permission属性が許可（ＴＲＵＥ）にはならないため、Ｉ／Ｏ監視モジュール１０４でのファイルＩ／Ｏは許可されないことになる。
このプロセス管理テーブル１１０もハッシュ管理テーブル１０９と同様に不正なユーザや不正なプログラムにより改ざんされないように、アクセス管理がなされていることを前提とし、ユーザコンピュータが終了した場合には削除される。
【００３５】
図８は、アプリケーション認証モジュール１０３がフィルタモジュール１０２のＩ／Ｏ許可要求を処理する手順を示すフローチャートである。
アプリケーション認証モジュール１０３は、フィルタモジュール１０２からのＩ／Ｏ許可要求を待っているが（ステップ８０１）、Ｉ／Ｏ許可要求を受信すると（ステップ８０２）、フィルタモジュール１０２が挿入されている業務アプリケーション１０１のハッシュ値を算出する（ステップ８０３）。このとき算出したハッシュ値をハッシュ管理テーブル１０９中のApplication属性が該当するアプリケーションに一致するエントリを検索し、そのHash  Value属性の値と比較する（ステップ８０４）。両者のハッシュ値が等しいことは業務アプリケーション１０１が改ざんされていないことを示しており、この場合はI/Ｏ監視モジュールにI/Oブロック解除要求を発行し（ステップ８０５）、Ｉ／Ｏ監視モジュール１０４がＩ／Ｏ要求をキャンセルしないように依頼を出す。
【００３６】
Ｉ／Ｏ監視モジュール１０４のＩ／Ｏブロックを解除した後、フィルタモジュール１０２にＩ／Ｏが許可されたことを通知する（ステップ８０６）。
このステップ８０６が終了した後、ステップ８０１に戻り、処理を繰り返す。ステップ８０４で両者のハッシュ値が異なる場合は、業務アプリケーション１０１が不正なプログラムにより改ざんされた恐れがあることを示しているため、フィルタモジュール１０２にはＩ／Ｏ要求をＩ／Ｏ監視モジュール１０４に転送しないよう、Ｉ／Ｏ要求却下を通知する（ステップ８０７）。
ステップ８０７が終了した後、ステップ８０１に戻り処理を繰り返す。
なお、本実施形態ではハッシュ値として業務アプリケーション１０１のハッシュ値を適用した例を示したが、フィルタモジュール１０２のハッシュ値も同時に比較することも可能である。ただし、この場合はハッシュ管理テーブル１０９にフィルタモジュール１０２のハッシュ値を格納するエントリを付加することは言うまでもない。
【００３７】
図９は、アプリケーション認証モジュール１０３がＩ／Ｏ監視モジュール１０４からのアプリケーション認証要求を処理する手順を示すフローチャートである。
アプリケーション認証モジュール１０３は、Ｉ／Ｏ監視モジュール１０４からのアプリケーション認証要求を待っているが（ステップ９０１）、業務アプリケーション１０１の認証要求を受信すると（ステップ９０２）、新規に起動した該当する業務アプリケーション１０１のハッシュ値を算出する（ステップ９０３）。このとき算出したハッシュ値をハッシュ管理テーブル１０９中のApplication属性が該当するアプリケーションに一致するエントリを検索し、そのHash  Value属性の値と比較する（ステップ９０４）。両者のハッシュ値が等しいことは業務アプリケーション１０１が改ざんされていないことを示しているため、この場合はI／O監視モジュール１０４に業務アプリケーション１０１の認証が成功したことを通知する（ステップ９０５）。
【００３８】
ステップ９０５が終了した後、ステップ９０１に戻り、処理を繰り返す。
ステップ９０４で両者のハッシュ値が異なる場合は、業務アプリケーション１０１が不正なプログラムにより改ざんされた恐れがあることを示しているため、Ｉ／Ｏ監視モジュール１０４にアプリケーションの認証が失敗したことを通知する（ステップ９０６）。
ステップ９０６が終了した後、ステップ９０１に戻り処理を繰り返す。
【００３９】
図１０は、フィルタモジュール１０２が業務アプリケーション１０１からのＩ／Ｏ要求を処理する手順をフローチャートである。
フィルタモジュール１０２は、自身がフックしている業務アプリケーション１０１からのＩ／Ｏイベントを待っているが（ステップ１００１）、ファイルＩ／Ｏイベントを受信すると（ステップ１００２）、アプリケーション認証モジュール１０３にＩ／Ｏ許可要求発行する（ステップ１００３）。
本実施形態では、業務アプリケーション１０１からのＩ／Ｏイベントとして、業務アプリケーション１０１がシステムの特定のＡＰＩを呼び出すイベントを１例として取り扱っているが、業務アプリケーション１０１から受信するイベントはソフトウェアブレイクポイントによるＥｘｃｅｐｔｉｏｎの場合も同じ方法を適用可能である。
【００４０】
次に、フィルタモジュール１０２は、アプリケーション認証モジュール１０３から返される応答が、Ｉ／Ｏを許可する通知であるかをチェックし（ステップ１００４）、Ｉ／Ｏを許可する通知である場合には該当するファイルＩ／ＯのＡＰＩを業務アプリケーション１０１に代わって実行する（ステップ１００５）。
ステップ１００５が終了した後、ステップ１００１に戻り、処理を繰り返す。ステップ１００４でアプリケーション認証モジュール１０３から返される応答がＩ／Ｏを却下する通知が返された場合には、ファイルＩ／ＯのＡＰＩの呼び出しをフィルタモジュール１０２の中でキャンセルする（ステップ１００６）。
ステップ１００６が終了した後、ステップ１００１に戻り、処理を繰り返す。
【００４１】
図１１は、Ｉ／Ｏ監視モジュール１０４がプロセスの起動を検出する処理を示すフローチャートである。
Ｉ／Ｏ監視モジュール１０４は、システムがプロセスを起動する機能を監視する機能を保持しており、システムからのアプリケーションプロセスの起動イベントを待ち（ステップ１１０１）、アプリケーションプロセスの起動イベントを受信すると（ステップ１１０２）、アプリケーション認証モジュール１０３に業務アプリケーション１０１の認証を依頼する（ステップ１１０３）。
【００４２】
アプリケーション認証モジュール１０３が実行するアプリケーションの認証処理は、業務アプリケーション１０１の実行可能ファイルのハッシュ値を正規のアプリケーションのハッシュ値と比較することによっても実行可能であり、またメモリ中にロードされた業務アプリケーション１０１のコードイメージのハッシュ値を比較することによっても実行可能である。
【００４３】
Ｉ／Ｏ監視モジュール１０４は、アプリケーション認証モジュール１０３に依頼した業務アプリケーション１０１の認証処理が成功したかチェックし（ステップ１１０４）、成功している場合には業務アプリケーション１０１が不正なプログラムにより当該業務アプリケーション１０１の起動時に改ざんされていないと判断し、業務アプリケーション１０１と同一のプロセス空間にフィルタモジュール１０２を挿入する（ステップ１１０５）。
【００４４】
その後、プロセス管理テーブル１１０に新規プロセスのエントリを追加し（ステップ１１０６）、ステップ１１０１に戻り、処理を繰り返す。
ステップ１１０４でアプリケーション認証モジュール１０３に依頼した業務アプリケーション１０１の認証処理が失敗した場合にも、ステップ１１０１に戻り処理を繰り返す。
【００４５】
図１２はＩ／Ｏ監視モジュール１０４がＩ／Ｏのブロックを解除する処理を示すフローチャートである。
Ｉ／Ｏ監視モジュール１０４は、アプリケーション認証モジュール１０３からファイルＩ／Ｏのブロックを解除するように要求されるのを待ち（ステップ１２０１）、Ｉ／Ｏのブロックの解除要求を受信すると（ステップ１２０１）、まずＩ／Ｏブロックを解除するように要求してきたアプリケーション認証モジュール１０３自体が正規のアプリケーション認証モジュールであるかチェックする処理を実行する（ステップ１２０３）。
この認証処理を実行するために、Ｉ／Ｏ監視モジュール１０４は内部にアプリケーション認証モジュールのハッシュ値を格納しており、不正なユーザやプログラムがアクセスできないようになっている。
【００４６】
そして、アプリケーション認証モジュール１０３自体の認証が成功したかチェックし（ステップ１２０４）、成功した場合にはプロセス管理テーブル１１０のI/O File Path属性の値が解除するファイルＩ／Ｏのパスに一致するエントリのPermission属性の値をtrueに変更する（ステップ１２０５）。
このとき、該当するエントリがプロセス管理テーブル１１０内に存在しない場合は、新規にエントリを追加し、Permission属性の値をtrueに設定する。その後、Ｉ／Ｏのブロックを解除したことをアプリケーション認証モジュール１０３に通知し（ステップ１２０６）、ステップ１２０１に戻り、処理を繰り返す。
ステップ１２０４でアプリケーション認証モジュール１０３自体の認証が失敗した場合には、ステップ１２０１に戻り処理を繰り返す。
【００４７】
図１３〜図１６は、Ｉ／Ｏ監視モジュール１０４がＩ／Ｏ要求を処理する手順を示すフローチャートである。
Ｉ／Ｏ監視モジュール１０４はフィルタモジュール１０２からのＩ／Ｏ要求を待ち（ステップ１３０１）、Ｉ／Ｏ要求を受信すると（ステップ１３０２）、該当するＩ／Ｏ要求がCreate系のＡＰＩかチェックする（ステップ１３０３）。Ｉ／Ｏ要求がCreate系のＡＰＩの場合にはプロセス管理テーブル１１０のPermission属性の値をチェックし、アクセスパーミッションが許可（ＴＲＵＥ）されているかチェックする（ステップ１３１１）。
該当するエントリのPermission属性の値がtrueの場合には、要求されているファイルＩ／Ｏに対応するファイルのバックアップファイルを作成し（ステップ１３１２）、ファイルＩ／Ｏを実行する（ステップ１３１３）。
【００４８】
ステップ１３１１で該当するエントリのPermission属性の値がＦＡＬＳＥの場合には、ファイルＩ／Ｏをキャンセルする（ステップ１３１４）。ステップ１３１３またはステップ１３１４終了後、ステップ１３０１に戻り処理を繰り返す。ステップ１３０３でＩ／Ｏ要求がCreate系のＡＰＩでない場合には、該当するＩ／Ｏ要求がClose系のＡＰＩかチェックする（ステップ１３０４）。Ｉ／Ｏ要求がClose系のＡＰＩの場合には、アプリケーション認証モジュール１０３に業務アプリケーション１０１の認証を依頼する（ステップ１３２１）。そして、アプリケーション認証モジュールの認証が成功したかチェックし（ステップ１３２２）、アプリケーション認証モジュール１０３から該当する業務アプリケーション１０１の認証が成功したことを通知された場合には、プロセス管理テーブル１１０のI/O File Path属性の値が解除するファイルＩ／Ｏのパスに一致するエントリのPermission属性の値をＦＡＬＳＥに変更し（ステップ１３２３）、ファイルＩ／Ｏを実行する（ステップ１３２４）。
このとき該当するエントリがプロセス管理テーブル１１０内に存在しない場合は新規にエントリを追加し、Permission属性の値をＦＡＬＳＥに設定する。
【００４９】
ステップ１３２２でアプリケーション認証モジュール１０３から該当する業務アプリケーション１０１の認証は失敗したことを通知されると、当該業務アプリケーション１０１は不正なプログラムにより改ざんされていると判断し、管理者にその旨を通知する等の対応を取る（ステップ１３２５）。ステップ１３２４またはステップ１３２５が終了後、ステップ１３０１に戻り処理を繰り返す。
【００５０】
ステップ１３０４でＩ／Ｏ要求がClose系のＡＰＩでない場合には、該当するファイルＩ／Ｏはプロセス管理テーブル１１０に登録済みでかつ該当するエントリのPermission属性の値がＴＲＵＥかチェックする（ステップ１３３１）。該当するファイルＩ／Ｏはプロセス管理テーブル１１０に登録済みでかつ該当するエントリのPermission属性の値がＴＲＵＥの場合には、ファイルＩ／Ｏを実行し（ステップ１３３２）、それ以外の場合にはファイルＩ／Ｏをキャンセルする（ステップ１３３３）。ステップ１３３２またはステップ１３３３が終了後、ステップ１３０１に戻り処理を繰り返す。
【００５１】
なお、Ｉ／Ｏ単位に処理をグループ化し、Ｉ／Ｏの初期化および終了時にだけ、またはＩ／Ｏの書込み時にだけ不正な業務アプリケーションを識別する処理を実施することにより、非同期的に発生し、回数が不定な業務アプリケーションの認証を実行する場合のシステムのパフォーマンスや実行速度の低下を回避することが可能になる。
【００５２】
以上のように、本実施形態の方法においては、
（１）コンピュータ上のファイルＩ／Ｏを監視し、業務アプリケーションの実行可能ファイルへの変更を監視することで、不正プログラムが業務アプリケーションの実行可能ファイルを直接改ざんするのを禁止することが可能になる。
（２）ロードされた業務アプリケーションのコードイメージの中にソフトウェアブレイクポイントやインターセプトコードを挿入することで、ファイルＩ／Ｏを実行する前に業務アプリケーションの実行を一時的に停止し、業務アプリケーションが不正に改ざんされていないか、当該アプリケーションがＩ／Ｏ要求をシステム（ＯＳ）に要求する直前にチェックし、改ざんされていた場合にはファイルＩ／Ｏをキャンセルし、不正な情報取得行為や変更行為を禁止し、機密ファイル等のリソースを保護することが可能になる。
（３）任意数のステップごとに不正な業務アプリケーションか識別する処理を実行することで、前記と同様に、ファイルＩ／Ｏを実行する前にアプリケーションの実行を一時的に停止し、アプリケーションが不正に改ざんされていないかチェックすることが可能になり、改ざんされていた場合にはファイルＩ／Ｏをキャンセルし、不正な情報取得行為や変更行為を禁止し、機密ファイル等のリソースを保護することが可能になる。
（４）業務アプリケーションの起動時等に不正な業務アプリケーションを検出した場合に、その旨を管理者に通知したり、信頼できる外部のサーバから正規の業務アプリケーションをダウンロードし、不正な業務アプリケーションに置き換えて実行することで、管理者に不正プログラムの存在を警告することが可能になる。また、セキュリティポリシの設定によっては、不正な業務アプリケーションを正規の業務アプリケーションに強制的に置き換えることで、ユーザの作業を継続させることも可能になる。
（５）Ｉ／Ｏ単位に処理をグループ化し、Ｉ／Ｏの初期化・終了時にだけ、またはＩ／Ｏの書込み時にだけ不正な業務アプリケーションを識別する処理を実施することにより、非同期的に発生し、回数が不定な業務アプリケーションの認証を実行する場合のシステムのパフォーマンスや実行速度の低下を回避することが可能になる。
（６）Ｉ／Ｏの初期化時にファイルのバックアップを行い、バックアップファイルへのアクセスをブロックする処理を実施することで、不正なプログラムが直接ファイルにアクセスする行為を禁止し、情報を改ざんしたり漏洩する危険を回避することが可能になる。
（７）情報漏洩防止システム等のセキュリティシステムが稼動するコンピュータ上で、ユーザが実行する業務アプリケーションがセキュリティシステムの機能を無効化するような不正なプログラムではないことを保証し、常に正規のアプリケーションが実行されることを保証することが可能になる。
（８）不正なプログラムが業務アプリケーションを不正に改ざんするような非同期的に発生する不正行為を常時監視するといったクリティカルな認証が必要なシステムで、システムのパフォーマンスやユーザアプリケーションの実行速度を低下させることなく、効率的に認証を行い、認証の安全性も確保することが可能になる。
【００５３】
なお、本発明は上記実施形態に限定されるものではなく、各種のセキュリティシステムを実現するプログラムの安全性を確保する方法に適用することができるものであり、その適用に際しては適用システムに応じて細部を変更して実施することがある。
【００５４】
【発明の効果】
以上説明したように、本発明によれば、システムのパフォーマンスを落とすことなく、効率的にアプリケーションの認証を実施し、ファイルなどのリソースの情報漏洩防止機能をさらに確実なものにすることができる。
【図面の簡単な説明】
【図１】本発明に係わるアプリケーション監視方法を実施売るシステムの実施形態を示す構成図である。
【図２】本発明に係わるアプリケーション監視モジュールがアプリケーションを監視する仕組を示す図である。
【図３】本発明に係わるフィルタモジュールやＩ／Ｏ監視モジュールがファイルＩ／Ｏをブロックする仕組を示す図である。
【図４】本発明に係わるＩ／Ｏ監視モジュールがアプリケーションのロードを検出し、フィルタモジュールを挿入する仕組を示す図である。
【図５】本発明に係わるアプリケーション認証モジュールがアプリケーションのハッシュ値を利用して正当性をチェックする仕組みを示す図である。
【図６】本発明に係わるアプリケーション認証モジュールが管理するハッシュ管理テーブルの構成を示す図である。
【図７】本発明に係わるＩ／Ｏ監視モジュールが管理するプロセス管理テーブルの構成を示す図である。
【図８】本発明に係わるアプリケーション認証モジュールがフィルタモジュールのＩ／Ｏ許可要求を処理する手順を示すフローチャートである。
【図９】本発明に係わるアプリケーション認証モジュールがＩ／Ｏ監視モジュールからのアプリケーション認証要求を処理する手順を示すフローチャートである。
【図１０】本発明に係わるフィルタモジュールがアプリケーションからのＩ／Ｏ要求を処理する手順を示すフローチャートである。
【図１１】本発明に係わるＩ／Ｏ監視モジュールがプロセスの起動を検出する処理を示すフローチャートである。
【図１２】本発明に係わるＩ／Ｏ監視モジュールがＩ／Ｏのブロックを解除する処理を示すフローチャートである。
【図１３】本発明に係わるＩ／Ｏ監視モジュールがＩ／Ｏ要求を処理するフローチャートである。
【図１４】図１３の続きを示すフローチャートである。
【図１５】図１３の続きを示すフローチャートである。
【図１６】図１３の続きを示すフローチャートである。
【符号の説明】
１０１…業務アプリケーション、１０２…フィルタモジュール、１０３…アプリケーション認証モジュール、１０４…Ｉ／Ｏ監視モジュール、１０５…機密フォルダ、１０６…一般フォルダ、１０９…ハッシュ管理テーブル、１１０…プロセス管理テーブル、２０２…ディスク、２０１…不正プログラム、３０２…不正コード。
【図１】
0004023654.tif 000002
【図２】
0004023654.tif 000003
【図３】
0004023654.tif 000004
【図４】
0004023654.tif 000005
【図５】
0004023654.tif 000006
【図６】
0004023654.tif 000007
【図７】
0004023654.tif 000008
【図８】
0004023654.tif 000009
【図９】
0004023654.tif 000010
【図１０】
0004023654.tif 000011
【図１１】
0004023654.tif 000012
【図１２】
0004023654.tif 000013
【図１３】
0004023654.tif 000014
【図１４】
0004023654.tif 000015
【図１５】
0004023654.tif 000016
【図１６】
0004023654.tif 000017