JP2008219454A - 通信内容監査支援システム - Google Patents

通信内容監査支援システム Download PDF

Info

Publication number
JP2008219454A
JP2008219454A JP2007053708A JP2007053708A JP2008219454A JP 2008219454 A JP2008219454 A JP 2008219454A JP 2007053708 A JP2007053708 A JP 2007053708A JP 2007053708 A JP2007053708 A JP 2007053708A JP 2008219454 A JP2008219454 A JP 2008219454A
Authority
JP
Japan
Prior art keywords
communication
key
packet
encrypted
audit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2007053708A
Other languages
English (en)
Inventor
Akishi Yato
晃史 矢戸
Tadashi Kaji
忠司 鍛
Takahiro Fujishiro
孝宏 藤城
Yoko Hashimoto
洋子 橋本
Kazuyoshi Hoshino
和義 星野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2007053708A priority Critical patent/JP2008219454A/ja
Priority to CN2007101694895A priority patent/CN101262331B/zh
Priority to US11/984,676 priority patent/US20080219445A1/en
Publication of JP2008219454A publication Critical patent/JP2008219454A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic

Abstract

【課題】任意の暗号通信の通信内容を、任意の時点で監査することができる通信内容監査支援システムを提供する。
【解決手段】本発明の通信内容監査支援システムは、暗号通信に用いられる鍵情報３０００が生成される都度、当該鍵情報３０００を鍵ＩＤに対応付けて鍵管理DB２０１に保存し、当該鍵情報３０００を用いる暗号通信を行うユーザ端末３００およびサービス提供サーバ３５０のＩＰアドレスを、当該鍵ＩＤに対応付けて通信状態管理DB１０１に保存し、暗号通信で送信される暗号パケットを、当該暗号パケットの送信元のＩＰアドレスおよび宛先のＩＰアドレスに対応付けてパケットDB５０１に保存する。
【選択図】図１

Description

本発明は、暗号化された通信内容を復号して監査するための技術に関する。
外部の監査機関等が、ネットワーク上で送信されている通信データを収集し、収集した通信データを解析することにより、事件の捜査等の目的で通信内容を監査する場合がある。しかし、通信内容が暗号化されている場合、暗号化された通信データを収集しても、監査機関は、通信内容を把握することができない。
これを回避するために、ユーザが暗号通信を行う場合に、当該暗号通信に用いられる鍵を第三者機関に預け、監査機関による通信内容の監査の必要性が生じた場合に、当該監査機関が、監査対象の暗号通信に用いられる鍵を当該第三者機関から取得して、対応する暗号通信の内容を監査するキーエスクローと呼ばれる技術がある（例えば、特許文献１参照）。
米国特許第５５３５２７６号明細書
上記の特許文献１に開示されている技術は、監査機関による通信内容の監査の必要性が生じた場合に、当該監査機関が、当該第三者機関から鍵を取得して、対応するユーザの通信内容を監査するため、鍵を取得した後も継続している暗号通信については、通信内容の監査を行うことができるものの、鍵を取得する前に行われていた暗号通信については、通信内容の監査を行うことができない。
監査の有無によらず、全ての暗号通信を収集して保存しておくことも考えられるが、暗号通信に用いられる鍵は、生成されてからの時間の経過に応じて暗号強度が低下するため、所定のタイミングで更新される場合が多い。そのため、監査機関による通信内容の監査の必要性が生じた時点の鍵を取得しても、その鍵とは異なる鍵を用いて行われた過去の暗号通信の内容を監査することはできない。
本発明は上記事情を鑑みてなされたものであり、本発明の目的は、任意の暗号通信の通信内容を、任意の時点で監査できるようにすることにある。
上記課題を解決するために、本発明の通信内容監査支援システムは、暗号通信に用いられる鍵情報が生成される都度、当該鍵情報を鍵ＩＤに対応付けて保存し、当該鍵情報を用いる暗号通信を行う通信装置のＩＰアドレスを、当該鍵ＩＤに対応付けて保存し、暗号通信で送信される暗号パケットを、当該暗号パケットの送信元のＩＰアドレスおよび宛先のＩＰアドレスに対応付けて保存する。
例えば、本発明の第１の態様は、複数の通信装置間で行われる暗号通信の監査に必要な情報を提供する通信内容監査支援システムであって、暗号通信に用いられる鍵情報が生成される都度、生成された鍵情報を、当該鍵情報を識別する鍵ＩＤに対応付けて鍵管理ＤＢ（データベース）に格納する鍵管理手段と、暗号通信が確立する都度、当該暗号通信を行う複数の通信装置のそれぞれのＩＰアドレスを、当該暗号通信に用いられる鍵情報の鍵ＩＤに対応付けて通信状態管理ＤＢに格納する通信管理手段と、暗号通信において送信された暗号パケットの複製を取得し、取得した暗号パケットの複製を、当該暗号パケットの送信元のＩＰアドレスおよび宛先のＩＰアドレスに対応付けてパケットＤＢに格納するパケット取得手段と、ユーザからの検索指示に基づいて通信状態管理ＤＢを参照し、当該検索指示で特定される暗号通信を行っていた通信装置のＩＰアドレスに対応する鍵ＩＤを特定し、特定した鍵ＩＤに対応する鍵情報を鍵管理ＤＢから抽出すると共に、当該検索指示で特定される暗号パケットの複製をパケットＤＢから抽出し、抽出した鍵情報および暗号パケットの複製を出力する通信情報出力手段とを備えることを特徴とする通信内容監査支援システムを提供する。
例えば、本発明の第２の態様は、複数の通信装置間で行われる暗号通信の監査に必要な情報を提供する通信内容監査支援システムであって、暗号通信に用いられる鍵情報が生成される都度、生成された鍵情報を、当該鍵情報を識別する鍵ＩＤに対応付けて鍵管理ＤＢ（データベース）に格納する鍵管理手段と、暗号通信が確立した場合に、当該暗号通信を行う複数の通信装置のそれぞれに固有の情報である固有情報、当該複数の通信装置のそれぞれのＩＰアドレス、および、当該暗号通信の開始時刻を、当該暗号通信に用いられる鍵情報の鍵ＩＤに対応付けて通信状態管理ＤＢに格納し、当該暗号通信が終了した場合に、当該鍵情報を用いた暗号通信の終了時刻を当該鍵情報の鍵ＩＤに対応付けて通信状態管理ＤＢに格納する通信管理手段と、暗号通信において送信された暗号パケットの複製を取得し、取得した暗号パケットの複製を、当該暗号パケットの送信元のＩＰアドレスおよび宛先のＩＰアドレス、ならびに、当該暗号パケットの複製の取得時刻に対応付けてパケットＤＢに格納するパケット取得手段と、ユーザからの検索指示に基づいて通信状態管理ＤＢを参照し、当該検索指示で特定される暗号通信を行っていた通信装置の固有情報、ＩＰアドレス、暗号通信の開始時刻、および終了時刻に対応する鍵ＩＤを特定し、特定した鍵ＩＤに対応する鍵情報を鍵管理ＤＢから抽出すると共に、当該検索指示で特定される暗号パケットの複製をパケットＤＢから抽出し、抽出した鍵情報および暗号パケットの複製を出力する通信情報出力手段とを備えることを特徴とする通信内容監査支援システムを提供する。
本発明の通信内容監査支援システムによれば、任意の暗号通信の通信内容を、任意の時点で監査することができる。
以下、本発明の実施の形態を、図面を用いて詳細に説明する。
＜実施例１＞
本実施例１では、SIP（Session Initiation Protocol）を用いた通信システムに対して、本発明を適用した例について説明する。SIPはＩＥＴＦのＲＦＣ３２６１に定義された、通信セッションの管理や制御を行う通信プロトコルである。なお、本発明の通信内容監査支援システムは、ＳＩＰに限らず、複数の通信装置間の通信を第三者の装置が確立させるような通信システムに対しても適用することができる。
図１は、実施例１の通信内容監査支援システムのシステム構成図である。同図において、通信内容監査支援システムは、セッション管理装置１００、鍵管理装置２００、ユーザ端末３００、サービス提供サーバ３５０、モニタリング機能付ルーティング装置４００、パケットモニタ装置５００、および監査装置６００を備える。
サービス提供サーバ３５０およびパケットモニタ装置５００は、モニタリング機能付ルーティング装置４００に接続される。モニタリング機能付ルーティング装置４００は、インターネット等のネットワーク０に接続され、当該ネットワーク０を介して、セッション管理装置１００、鍵管理装置２００、ユーザ端末３００、および監査装置６００と通信する。
なお、本実施例１において、ユーザ端末３００やサービス提供サーバ３５０は、SIP-URI（Uniform Resource Identifier）と呼ばれる識別子によって一意に識別される。ユーザ端末３００のSIP-URIは、ユーザ端末３００の名前とセッション管理装置１００の名前とを"@"で連結し、この文字列の先頭に"sip:"を付加した文字列で表現される。同様に、サービス提供サーバ３５０のSIP-URIは、サービス提供サーバ３５０の名前とセッション管理装置１００の名前とを"@"で連結し、この文字列の先頭に"sip:"を付加した文字列で表現される。
図１に示す例では、ユーザ端末３００の名前が"user"であり、セッション管理装置１００の名前が"domain.hitachi.co.jp"である場合、ユーザ端末３００のSIP-URIは"sip:user @ domain.hitachi.co.jp "となる。同様に、サービス提供サーバ３５０の名前が"service"である場合、サービス提供サーバ３５０のSIP-URIは"sip:service@ domain.hitachi.co.jp "となる。しかしながら、SIP-URIの命名規則はこれに限定されない。例えば、ユーザ端末の名前ではなく、ユーザ端末を使用しているユーザの識別情報（ユーザ名）等を使用してもよい。
また、本実施例１において、ユーザ端末３００またはサービス提供サーバ３５０が自身のIPアドレスとSIP-URIをセッション管理装置１００に対応付けてレジストラＤＢに保存させる処理を、ユーザ端末３００またはサービス提供サーバ３５０がセッション管理装置１００にログインすると定義する。
次に、本実施例1における通信内容監査支援システムの各構成要素が備える機能について説明する。
セッション管理装置１００は、ユーザ端末３００とサービス提供サーバ３５０との間の暗号通信を制御および管理する装置であり、通信状態管理DB（データベース）１０１、通信管理機能１０３、鍵取得機能１０４、メッセージ送受信機能１０５、およびセッション情報通知機能１０６を有する。鍵管理装置２００は、鍵管理DB２０１、鍵管理機能２０２、および鍵送受信機能２０３を有する。パケットモニタ装置５００は、パケットDB５０１、パケット受信機能５０２、パケット管理機能５０３、およびパケット送信機能５０４を備える。
通信状態管理DB１０１は、セッション情報を登録するデータベースである。通信管理機能１０３は、ユーザ端末３００とサービス提供サーバ３５０との間の暗号通信のセッション情報を通信状態管理DB１０１に登録したり、当該セッション情報を通信状態管理DB１０１から検索して取得したりする。鍵取得機能１０４は、ユーザ端末３００とサービス提供サーバ３５０との間の暗号通信に使用される鍵情報を鍵管理装置２００から取得したり、取得した鍵情報をメッセージ送受信機能１０５によって送信されるメッセージに記載したりする。メッセージ送受信機能１０５は、ユーザ端末３００とサービス提供サーバ３５０との間でSIPメッセージを送信または受信する。セッション情報通知機能１０６は、セッション情報を監査装置６００へ送信する。
なお、本実施例１の鍵情報には、暗号通信に使用する鍵および当該鍵を一意に識別するための鍵ID、有効期間、および当該鍵を用いる暗号アルゴリズム名が含まれる。また、本実施例１のセッション情報には、暗号通信を一意に識別するためのセッションID、暗号通信に使用する鍵ID、暗号通信を行う通信装置の名前およびIPアドレス、ならびに、鍵の使用開始時刻および終了時刻が含まれる。また、本実施例において、セッションIDには、SIPメッセージに記載されたCall-IDフィールド内の文字列の"@"以前（左側）の部分が用いられる。
鍵管理装置２００は、ユーザ端末３００とサービス提供サーバ３５０との間の暗号通信に使用する鍵の生成および管理を行う装置であり、鍵管理DB２０１、鍵管理機能２０２、および鍵送受信機能２０３を備える。
鍵管理DB２０１は、鍵情報を登録するデータベースである。鍵管理機能２０２は、鍵情報を生成し、生成した鍵情報を鍵管理DB２０１に登録したり、鍵管理DB２０１内の鍵情報を検索して取得したりする。鍵送受信機能２０３は、鍵の取得要求または生成要求を受信し、鍵情報を要求元に送る。
ユーザ端末３００は、サービス提供サーバ３５０と暗号通信を行う装置であり、サービス提供サーバ３５０は、ユーザ端末３００と暗号通信を行う装置である。ユーザ端末３００およびサービス提供サーバ３５０は、鍵取得機能３０１、SIPクライアント機能３０２、暗号通信機能３０３、および状態管理機能３０４を備える。
鍵取得機能３０１は、セッション管理装置１００より受信したSIPメッセージから暗号通信に使用する鍵情報を取得し、取得した鍵情報の有効期限を監視したり、暗号通信終了後に、使用した鍵情報を削除したりする。SIPクライアント機能３０２は、セッション管理装置１００を介して他のユーザ端末３００もしくはサービス提供サーバ３５０と暗号通信を確立するためのSIP通信を行う。
暗号通信機能３０３は、通信を確立している通信相手から暗号パケットを受信し、受信した暗号パケットの復号を行ったり、パケットを暗号化して通信を確立している通信相手へ送信したりする。状態管理機能３０４は、SIPクライアント機能３０２が管理する、自装置と通信相手の装置の内部状態を管理する。
なお、本実施例では、ユーザ端末３００内の状態管理機能３０４は、内部状態をユーザ端末３００に接続されている画面に表示し、サービス提供サーバ３５０内の状態管理機能３０４は、内部状態をイベントログとして出力する。
モニタリング機能付ルーティング装置４００は、ユーザ端末３００とサービス提供サーバ３５０との間で送信または受信された暗号パケットを受信し、受信した暗号パケットを複製し、受信した暗号パケットを本来の宛先へ送信すると共に、複製した暗号パケットをパケットモニタ装置５００へ送信するパケット制御機能４０１を備える。
パケットモニタ装置５００は、パケットDB５０１、パケット受信機能５０２、パケット管理機能５０３、およびパケット送信機能５０４を備える。パケットDB５０１は、モニタリング機能付ルーティング装置４００から受信した暗号パケットを、当該暗号パケットの送信元および宛先に対応付けて格納するデータベースである。パケット受信機能５０２は、モニタリング機能付ルーティング装置４００から暗号パケットを受信する。
パケット管理機能５０３は、パケット受信機能５０２が受信した暗号パケットをパケットDB５０１に格納したり、監査装置６００から要求された暗号パケットをパケットDB５０１から検索して取得したりする。パケット送信機能５０４は、パケット管理機能５０３によってパケットDB５０１から取得された暗号パケットを監査装置６００へ送る。
監査装置６００は、ユーザ端末３００とサービス提供サーバ３５０との間の暗号通信で送信または受信された通信内容を監査する装置であり、鍵取得機能６０１、セッション情報取得機能６０２、パケット取得・復号機能６０３、および監査アプリケーション６０４を備える。
鍵取得機能６０１は、ユーザ端末３００とサービス提供サーバ３５０との間の暗号通信で使用された鍵を鍵管理装置２００から取得する。セッション情報取得機能６０２は、セッション情報の一覧をセッション管理装置１００から取得する。パケット取得・復号機能６０３は、暗号パケットをパケットモニタ装置５００から取得し、鍵管理装置２００から取得した鍵を用いて当該暗号パケットを復号する。監査アプリケーション６０４は、復号されたパケットを用いてユーザ端末３００とサービス提供サーバ３５０との間の暗号通信の内容を監査する。
なお、本実施例１が適用された通信内容監査支援システムは、ユーザ端末３００とサービス提供サーバ３５０との間で通信を行うクライアント/サーバ通信の監査だけでなく、サービス提供サーバ３５０同士が通信を行う場合の監査にも適用可能である。更には、本実施例１ではサービス提供サーバ３５０をモニタリング機能付ルーティング装置４００に接続する構成にしているが、本発明はこれに限られない。
例えば、ユーザ端末３００をモニタリング機能付ルーティング装置４００に接続するように構成してもよい。その場合、図１のシステム構成においてサービス提供サーバ３５０をユーザ端末３００に置き換えることにより、ネットワーク０に直接接続されているユーザ端末３００やサービス提供サーバ３５０と暗号通信を行う場合にも通信内容監査支援システムを適用することができる。そして、モニタリング機能付ルーティング装置４００に接続されているユーザ端末３００に着目して暗号通信の通信内容の監査が行われる。
その他、ネットワーク０は、企業内LANのようなプライベートネットワークに限らず、インターネットのようなオープンネットワークでも良い。更に、モニタリング機能付ルーティング装置４００は、スイッチング機能を持たないリピータハブ、ミラーリングポート機能を有するスイッチングハブ、ルータ、ファイアウォール、プロキシサーバに代表される、通信を中継する機能を持った装置であれば、いずれでも良い。例えば、ファイアウォールをモニタリング機能付ルーティング装置４００とする場合には、ファイアウォールを介して行われる組織内部と組織外部の間の通信を監査することができるようになる。
また、通信状態管理DB１０１は、本実施例１のようにセッション管理装置１００内に含まれる装置として構成されることが可能であるが、セッション管理装置１００とは別の装置内に設け、当該装置とセッション管理装置１００とをネットワークで接続するようにしてもよい。同様に、鍵管理DB２０１は、鍵管理装置２００とは別の装置内に設けられてもよい。さらに、パケットDB５０１は、パケットモニタ装置５００とは別の装置内に設けられてもよい。
また、本実施例１において、セッション管理装置１００、鍵管理装置２００、パケットモニタ装置５００、および監査装置６００は、図１のように異なる装置によって実現されているが、本実施例はこれに限られない。鍵管理装置２００とセッション管理装置１００とを一つの装置として構成したり、監査装置６００とセッション管理装置１００とを一つの装置として構成したり、パケットモニタ装置５００と監査装置６００とを一つの装置として構成したりしてもよい。
図２は、セッション管理装置１００、鍵管理装置２００、ユーザ端末３００、サービス提供サーバ３５０、パケットモニタ装置５００、または監査装置６００の機能を実現する情報処理装置の構成を例示する。
情報処理装置は、CPU（Central Processing Unit）１１、メモリ１２、通信処理装置１３、入力装置１４、出力装置１５、読取装置１６、および外部記憶装置１７を備える。これらは、バス１０を介して互いに接続されている。
通信処理装置１３は、インターネットやLANを介して他の通信装置と通信を行う。入力装置１４は、例えばキーボードやマウス等である。出力装置１５は、例えばモニタやプリンタ等である。読取装置１６は、ICカードやUSBメモリ等の可搬性を有する記録媒体１８内のデータを読み込む。外部記憶装置１７は、例えばハードディスク等である。
本実施例１における、セッション管理装置１００、鍵管理装置２００、ユーザ端末３００、サービス提供サーバ３５０、パケットモニタ装置５００、または監査装置６００内の各機能は、これらの機能を実現するプログラムがメモリ１２上にロードされ、CPU１１によって実行されることにより具現化される。
これらのプログラムは、予め上記情報処理装置の外部記憶装置１７内に格納されていてもよいし、必要なときに、読取装置１６または通信処理装置１３によって、当該情報処理装置が利用可能な媒体を介して、他の装置から取得されて外部記憶装置１７内に格納されてもよい。媒体とは、例えば、読取装置１６に着脱可能な記録媒体１８、または通信処理装置１３に接続可能なネットワーク０または当該ネットワーク０を伝搬する搬送波やディジタル信号を指す。
そして、プログラムは一旦外部記憶装置１７内に格納された後、そこからメモリ１２上にロードされてCPU１１によって実行されてもよいし、あるいは外部記憶装置１７内に格納されることなく、直接メモリ１２上にロードされて、CPU１１によって実行されてもよい。また、通信状態管理DB１０１、鍵管理DB２０１、またはパケットDB５０１は、メモリ１２が外部記憶装置１７を利用することにより実現される。
次に、本実施例１において、SIPを用いた通信内容監査支援システムの動作について説明する。なお、ユーザ端末３００およびサービス提供サーバ３５０がセッション管理装置１００にログインする動作は、通常のSIPを用いたシステムの動作（例えばレジストレーション）と同じであるため、説明を省略している。
ユーザ端末３００およびサービス提供サーバ３５０がセッション管理装置１００にログインすることにより、セッション管理装置１００は、ユーザ端末３００とサービス提供サーバ３５０のSIP-URIとIPアドレスとを対応付けてメモリ12に保存する。また、セッション管理装置１００へのログインにより、ユーザ端末３００とサービス提供サーバ３５０との間で暗号通信の確立が可能となり、同時に鍵管理装置２００がユーザ端末３００とサービス提供サーバ３５０との間の暗号通信に使用する鍵を管理することが可能となる。そして、監査装置６００が暗号パケットおよび暗号通信に使用する鍵を取得して、パケットを復号することでユーザ端末３００とサービス提供サーバ３５０との間の暗号通信の通信内容を監査できるようになる。
まず、ユーザ端末３００がセッション管理装置１００を介して、サービス提供サーバ３５０と暗号通信に使用する鍵を共有し、暗号通信を開始する一連の動作シーケンスを図３から図５を用いて説明する。
ユーザ端末３００の利用者は、状態管理機能３０４のGUI画面を見てユーザ端末３００の内部状態がログイン済状態であることを確認すると、サービス提供サーバ３５０との間の暗号通信処理の開始をユーザ端末３００へ指示する。そして、ユーザ端末３００のSIPクライアント機能３０２は、サービス提供サーバ３５０への通信開始要求２０００を作成してセッション管理装置１００へ送信する(ステップＳ１０１)。本実施例１において、SIPクライアント機能３０２は、例えば図１０（ａ）に示すように、SIPで定義されているINVITEのリクエストメッセージを通信開始要求２０００として生成する。
セッション管理装置１００のメッセージ送受信機能１０５は、ユーザ端末３００から鍵管理装置２００を受信すると(ステップＳ１０２)、鍵取得機能１０４は、通信開始要求２０００のFromフィールドに記載されているユーザ端末３００のSIP-URI、および、Toフィールドに記載されているサービス提供サーバ３５０のSIP-URIを記載した鍵生成要求２２００を作成し、生成した鍵生成要求２２００を鍵管理装置２００へ送信する（ステップＳ１０３）。
本実施例１では、鍵生成要求２２００は、例えば図１２（ａ）XMLメッセージのgenKeyRequestタグとして記述される。図１２(a)は、セッション管理装置１００が鍵管理装置２００へ送信する鍵生成要求２２００のうち、本実施例の説明に必要な部分のみを示している。送信元であるユーザ端末３００のSIP-URIがfromタグに記載され、宛先であるサービス提供サーバ３５０のSIP-URIがtoタグに記載される。
鍵管理装置２００の鍵送受信機能２０３は、セッション管理装置１００から鍵生成要求２２００を受信すると(ステップＳ１０４)、鍵管理機能２０２は、鍵情報３０００を生成し（ステップＳ１０５）、そのうち鍵ID、鍵、使用する暗号アルゴリズム名を鍵管理DB２０１に登録する（ステップＳ１０６）。
本実施例１では、例えば図１３に示すように、鍵管理DB２０１は、鍵ID、暗号アルゴリズム、および鍵を有する各レコードを格納する。鍵管理DB２０１には、監査装置６００が鍵を取得するために最低限必要な情報が格納される。なお、鍵管理DB２０１内の暗号アルゴリズムの欄には、鍵のビット数や暗号アルゴリズムのバージョン等も格納される。
まず、図１３(a)は、ステップＳ１０６を実行する前において、鍵IDが「12345678」であり、暗号アルゴリズムがAES-256bitである鍵が登録されている様子を示している。図１３(b)は、ステップＳ１０６が実行されることにより、鍵IDが「12345679」であり、暗号アルゴリズムがAES-256bitである鍵が作成され、鍵管理DB２０１に追加登録された様子を示している。
図３に戻って説明を続ける。鍵送受信機能２０３は、鍵生成応答２３００を作成し、ステップＳ１０５で生成された鍵情報３０００を添付してセッション管理装置１００へ送信する（ステップＳ１０７）。
本実施例１では、鍵生成応答２３００は、例えば図１２(b)に示すように、XMLメッセージのgenKeyResponseタグとして記述される。図１２(b)は、鍵管理装置２００がセッション管理装置１００へ送信する鍵生成応答２３００のうち、本実施例の説明に必要な部分のみを示している。statusタグ要素には、ユーザ端末３００とサービス提供サーバ３５０との間の暗号通信に使用する鍵ID、鍵、および使用する暗号アルゴリズム名を、鍵管理装置２００が鍵管理DB２０１に登録した結果が記載される。
登録成功の場合、鍵生成応答２３００のstatusタグ要素には"OK"と記載され、登録失敗の場合には"NG"と記載される。また、鍵生成要求の送信元であるユーザ端末３００のSIP-URIがfromタグ要素に記載され、宛先であるサービス提供サーバ３５０のSIP-URIがtoタグ要素に記載される。更に、生成された鍵情報３０００がXML形式で記載される。
鍵情報３０００は、XML形式を用いてsessionKeyInfoタグで表現される。鍵情報３０００には、例えば図１２(c)に示すように、ユーザ端末３００とサービス提供サーバ３５０との間の暗号通信に使用される鍵IDが記載されるkeyIDタグ、データの暗号化に使用されるアルゴリズム名が記載されるencタグ、鍵の有効期間が記載されるlifetimeタグ、および、鍵が記載されるkeyタグが記載される。なお、本実施例１において、lifetimeタグに記載される数値は秒を単位の時間を示す。
セッション管理装置１００の鍵取得機能１０４は、ステップＳ１０７において鍵管理装置２００から送信された鍵生成応答２３００を受信すると（図３のステップＳ１０８）、通信開始要求２０００のCall-IDフィールドに記載されているセッションIDに対応付けて鍵情報３０００をメモリ１２に保存し、当該鍵情報３０００を、図１０(a)に示す通信開始要求２０００のBODY部に記載する（ステップＳ１０９）。そして、メッセージ送受信機能１０５は、通信開始要求２０００をサービス提供サーバ３５０へ送信する（ステップＳ１１０）。
なお、ステップＳ１１０以降において送信または受信される通信開始要求２０００は、図１０(a)に示す通信開始要求２０００のBODY部にXML形式で記述された鍵情報３０００が記載されたものである。
サービス提供サーバ３５０のSIPクライアント機能３０２は、セッション管理装置１００から通信開始要求２０００を受信すると（ステップＳ１１１）、受信した通信開始要求２０００の内容を調べ、ユーザ端末３００との通信可否を判定する（ステップＳ１１２）。ユーザ端末３００との間の暗号通信を拒否する場合、サービス提供サーバ３５０のSIPクライアント機能３０２は、通信を拒否する旨を示すメッセージを含む通信開始応答２１００を作成してセッション管理装置１００へ返信する（ステップＳ１１５）。そして、状態管理機能３０４は、ユーザ端末３００からの通信を拒否した旨をイベントログに出力する。サービス提供サーバ３５０の管理者は、イベントログを確認することで、ユーザ端末３００との間の暗号通信を拒否したことを認識することができる。
なお、本実施例１において、上記通信を拒否する旨を示すメッセージには、SIPで定義されているINVITEレスポンスの401 Unauthorizedメッセージが用いられる。
一方、ステップＳ１１２において、ユーザ端末３００との間の暗号通信を許可する場合、サービス提供サーバ３５０の鍵取得機能３０１は、通信開始要求２０００のBODY部に記載されている鍵情報３０００を取得し（ステップＳ１１３）、通信開始要求２０００のCall-IDフィールドに記載されているセッションIDと対応付けてメモリ１２に保存する。
そして、SIPクライアント機能３０２は、通信を許可する旨を示すメッセージを含む通信開始応答２１００を作成してセッション管理装置１００へ返信する（ステップＳ１１４）。そして、状態管理機能３０４は、内部状態を暗号通信状態へ遷移させると共に、ユーザ端末３００との間の暗号通信を開始した旨をイベントログに出力する。サービス提供サーバ３５０の管理者は、イベントログを確認することで、ユーザ端末３００との間の暗号通信開始処理が正常に行われたことを認識することができる。
なお、本実施例１では、上記通信を許可する旨を示すメッセージを含む通信開始応答２１００には、例えば図１０(b)に示すように、SIPで定義されているINVITEレスポンスの200 OKメッセージが用いられる。
ステップＳ１１４またはステップＳ１１５の後に、セッション管理装置１００のメッセージ送受信機能１０５は、サービス提供サーバ３５０から通信開始応答２１００を受信し（ステップＳ１１６）、通信開始応答２１００の内容を調べ、ユーザ端末３００のサービス提供サーバ３５０に対する通信開始要求２０００が許可されたか否かを判定する（ステップＳ１１７）。
通信開始応答２１００が通信を拒否する旨を示すメッセージを含む場合、セッション管理装置１００の鍵取得機能１０４は、メモリ１２に保存されている鍵情報３０００から鍵IDを取出して、鍵削除要求２６００を作成し、作成した鍵削除要求２６００を鍵管理装置２００へ送信する（ステップＳ１２２）。
本実施例１では、鍵削除要求２６００は、例えば図１２(d)に示すように、XMLメッセージのdelKeyRequestタグとして記述される。図１２(d)は、セッション管理装置１００が鍵管理装置２００へ送信する鍵削除要求２６００のうち、本実施例の説明に必要な部分のみを示している。鍵削除要求２６００には、sessionIDタグおよびkeyIDタグが記載される。sessionIDタグ内には、通信開始応答２１００に記載されたCall-IDフィールド内の文字列の"@"以前（左側）の部分が記載される。また、keyIDタグ内には、鍵情報３０００のkeyIDタグ内の情報がそのまま記載される。
鍵管理装置２００の鍵送受信機能２０３が、セッション管理装置１００から鍵削除要求２６００を受信すると（ステップＳ１２３）、鍵管理機能２０２は、鍵削除要求２６００のkeyIDタグに記載されている鍵IDを鍵管理DB２０１から削除することにより、鍵IDを失効する（ステップＳ１２４）。その後、鍵送受信機能２０３は、鍵削除応答２７００を作成してセッション管理装置１００へ送信する（ステップＳ１２５）。
これにより、鍵管理DB２０１内に格納されている情報は、例えば図１３(b)から(c)のように更新される。なお、ステップＳ１２４において、鍵管理機能２０２は、鍵IDに加えて、対応する暗号アルゴリズムおよび鍵を鍵管理DB２０１から削除するようにしてもよい。
なお、本実施例１において、鍵削除応答２７００は、XMLメッセージのdelKeyResponseタグとして記述される。図１２(e)は、鍵管理装置２００がセッション管理装置１００へ送信する鍵削除応答２７００のうち、本実施例の説明に必要な部分のみが示されている。鍵削除応答２７００には、sessionIDタグおよびstatusタグが記載される。鍵管理機能２０２によって鍵管理DB２０１から鍵ID、鍵、暗号アルゴリズム名を削除された結果が、statusタグに記載される。削除成功の場合にはstatusタグに"OK"と記載され、削除失敗の場合には"NG"と記載される。
セッション管理装置１００の鍵取得機能１０４は、鍵管理装置２００から送信された鍵削除応答２７００を受信すると（ステップＳ１２６）、メモリ１２に保存していたセッションIDと鍵情報を削除し、メッセージ送受信機能１０５は、通信開始応答２１００を作成してユーザ端末３００へ送信する（ステップＳ１２７）。
一方、図４のステップＳ１１７の後、通信開始応答２１００が通信を許可する旨のメッセージを含む場合、セッション管理装置１００の通信管理機能１０３は、通信開始応答２１００のCall-IDフィールドに記載されているセッションIDをキーに、通信状態管理DB１０１のセッションIDレコードを検索する（ステップＳ１１８）。なお、本実例１において、通信管理機能１０３は、暗号通信の相手の通信装置から暗号通信を許可する旨のメッセージを受信した場合に、暗号通信が確立したものと判定する。
本実施例１において、通信状態管理DB１０１は、例えば図１１に示すように、鍵ID、通信の開始を要求した通信装置を示す通信装置１、通信装置１の通信相手である通信装置２、通信の開始時刻、通信の終了時刻、および暗号アルゴリズムを、セッションIDに対応付けて格納する。本実施例１において、図３のステップＳ１１８を実行する前の時点では、通信状態管理DB１０１内には、例えば図１１の(a)に示すような情報が格納されているものと仮定する。
通信状態管理DB１０１を参照することにより、例えば通信の管理者はどのような通信が行われているかを把握したり、また、決められた暗号アルゴリズムを使用して暗号通信を行っているかといった通信ポリシを一元的にチェックしたりすることができる。また、本実施例１において、通信状態管理DB１０１には、暗号通信を行う通信装置のIPアドレスだけでなく、暗号通信が行われた時間帯が鍵ＩＤに対応付けられているので、IPアドレスの割り当てがDHCP（Dynamic Host Configuration Protocol）等により動的に変更される場合であっても、特定の時間帯におけるIPアドレスによって、通信装置を一意に特定することができる。
ステップＳ１１６において受信した通信開始応答２１００のCall-IDフィールドに記載されているセッションID（本実施例１では「f4yh79bn6o」）が通信状態管理DB１０１のセッションIDレコードに記載されていないので、通信管理機能１０３は、ユーザ端末３００とサービス提供サーバ３５０との間の暗号通信が新規の通信であると判断する（ステップＳ１１９）。
そして、通信管理機能１０３は、セッションIDを通信状態管理DB１０１のセッションIDレコードに書き込み、メモリ１２に保存されている鍵情報３０００のkeyIDタグに記載された鍵IDを鍵IDレコードに書き込み、通信開始応答２１００のFromフィールドに記載されたユーザ端末３００の名前をメモリ１２に保存しているユーザ端末３００のSIP-URIと対応付けて通信装置１レコードに書き込み、通信開始応答２１００のToフィールドに記載されたサービス提供サーバ３５０の名前をメモリ１２に保存しているサービス提供サーバ３５０のSIP-URIと対応付けて通信装置２レコードに書き込み、現在の時刻を開始時刻レコードに書き込み、鍵情報３０００のencタグに記載された暗号アルゴリズム名を暗号アルゴリズムレコードに書き込む（ステップＳ１２１）。これにより、通信状態管理DB１０１に格納されている情報は、例えば図１１(b)に示すようになる。
その後、鍵取得機能１０４は、メモリ１２に保存されている鍵情報３０００を取り出し、図１０(b)に示す通信開始応答２１００のBODY部に記載すると、メモリ１２に保存していたセッションIDと鍵情報３０００を削除する。そして、メッセージ送受信機能１０５は、入力装置１４によって作成された通信開始応答２１００をユーザ端末３００へ送信する（ステップＳ１２７）。
ユーザ端末３００のSIPクライアント機能３０２は、セッション管理装置１００から通信開始応答２１００を受信すると（ステップＳ１２８）、受信した通信開始応答２１００の内容を確認する（ステップＳ１２９）。通信開始応答２１００が通信を拒否する旨を示すメッセージを含む場合、ユーザ端末３００の状態管理機能３０４は、GUI画面にサービス提供サーバ３５０への通信が拒否された旨を表示する。ユーザ端末３００の利用者は、GUI画面を確認することで、サービス提供サーバ３５０との間の暗号通信が拒否されたことを認識することができる。
通信開始応答２１００が通信を許可する旨を示すメッセージを含む場合、ユーザ端末３００の鍵取得機能３０１は、通信開始応答２１００のBODY部に記載されている鍵情報３０００を取得し（ステップＳ１３０）、通信開始応答２１００のCall-IDフィールドに記載されたセッションIDと対応付けてメモリ１２に保存する。そして、状態管理機能３０４は、内部状態を暗号通信状態へと遷移させると共に、GUI画面にサービス提供サーバ３５０との間の暗号通信が開始された旨を表示する。ユーザ端末３００の利用者は、GUI画面を確認することで、サービス提供サーバ３５０との間の暗号通信開始処理が正常に行われたことを認識することができる。
そして、ユーザ端末３００とサービス提供サーバ３５０とは、セッション管理装置１００を介することなく、取得した鍵情報３０００を用いて、暗号通信を開始する。
以上が本実施例１において、ユーザ端末３００がセッション管理装置１００を介して、サービス提供サーバ３５０と暗号通信に使用する鍵情報３０００を共有し、暗号通信を開始する動作シーケンスである。
また、ユーザ端末３００とサービス提供サーバ３５０との間で共有された鍵の有効期限が切れ、その契機で鍵更新を行う一連の動作については、図４のステップＳ１１８の後の動作以外は、暗号通信開始の動作シーケンスと同一である。ただし、鍵更新のシーケンスでは、サービス提供サーバ３５０は、常に暗号通信を許可する。すなわち、通信開始応答２１００には通信を許可する旨を示すメッセージが含まれるため、セッション管理装置１００の通信管理機能１０３は、ステップＳ１１７の後に、ステップＳ１１８を実行する。
そして、通信管理機能１０３は、ステップＳ１１８において、通信開始応答２１００のCall-IDフィールドに対応するセッションIDが記載され、かつ、終了時刻レコードに何も記載されていない行を通信状態管理DB１０１から検索する。ステップＳ１１８を実行する前の時点では、通信状態管理DB１０１に格納されている情報は、例えば図１１(b)のようになっているので、通信管理機能１０３は、２行目のセッションIDレコードに検索しているセッションIDが記載され、終了時刻レコードに何も記載されていない行が存在することを検知する（ステップＳ１１９）。
そして、通信管理機能１０３は、通信状態管理DB１０１の２行目の終了時刻レコードに現在の時刻を入力し（ステップＳ１２０）、空白行になっている３行目にセッションID、更新した鍵ID、ユーザ端末３００の名前、サービス提供サーバ３５０の名前、開始時刻（現在の時刻）、および暗号アルゴリズムの各情報を書き込む（ステップＳ１２１）。これにより、通信状態管理DB１０１に格納されている情報は、例えば図１１(c)のようになる。
その後、ステップＳ１２７以降の処理が実行され、ユーザ端末３００およびサービス提供サーバ３５０は、セッション管理装置１００を介することなく、取得した鍵情報３０００を用いて暗号通信を継続する。
以上が本実施例１において、ユーザ端末３００とサービス提供サーバ３５０との間で共有された鍵の有効期限が切れ、その契機で鍵更新を行う場合の動作シーケンスである。なお、このシーケンスについては、サービス提供サーバ３５０からユーザ端末３００に対する通信開始要求２０００をセッション管理装置１００へ送信することも可能である。この場合、図３においてユーザ端末３００とサービス提供サーバ３５０の立場が入れ替わるだけで、それ以外にシーケンスの変更はない。また、鍵の有効期限が切れたことを契機とするのではなく、鍵の有効期限が近づいたことを契機としてもよい。
次に、ユーザ端末３００が、セッション管理装置１００を介して、サービス提供サーバ３５０との間の暗号通信を終了する一連の動作シーケンスを、図６を用いて説明する。
ユーザ端末３００の利用者は、状態管理機能３０４のGUI画面を参照して、ユーザ端末３００の内部状態が暗号通信状態であることを確認し、暗号通信を終了する場合には、サービス提供サーバ３５０との間の暗号通信処理の終了をユーザ端末３００へ指示する。ユーザ端末３００のSIPクライアント機能３０２は、サービス提供サーバ３５０への通信終了要求２４００を作成し、セッション管理装置１００へ送信する(ステップＳ１３１)。本実施例１では、通信終了要求２４００には、例えば図１０(c)に示すように、SIPで定義されているBYEリクエストメッセージが利用される。
セッション管理装置１００のメッセージ送受信機能１０５は、ユーザ端末３００から通信終了要求２４００を受信すると（ステップＳ１３２）、サービス提供サーバ３５０に通信終了要求２４００を送信する（ステップＳ１３３）。サービス提供サーバ３５０のSIPクライアント機能３０２は、セッション管理装置１００から通信終了要求２４００を受信し（ステップＳ１３４）、鍵取得機能３０１は、通信終了要求２４００のCall-IDフィールドに記載されているセッションIDおよび鍵情報３０００をメモリ１２から削除する（ステップＳ１３５）。
そして、SIPクライアント機能３０２は、通信終了応答２５００を作成して、セッション管理装置１００へ返信する（ステップＳ１３６）。そして、状態管理機能３０４は、内部状態を通信開始前状態へ遷移させると共に、ユーザ端末３００との間の暗号通信に使用した鍵情報３０００を削除した旨、および、暗号通信を終了した旨をイベントログへ出力する。サービス提供サーバ３５０の管理者は、イベントログを確認することで、ユーザ端末３００との間の暗号通信終了処理が正常に行われたことを認識する。
なお、本実施例１において、通信終了応答２５００には、例えば図１０(d)に示すように、SIPで定義されているBYEレスポンスメッセージが利用される。
セッション管理装置１００のメッセージ送受信機能１０５がサービス提供サーバ３５０から通信終了応答２５００を受信すると（図６のステップＳ１３７）、通信管理機能１０３は、通信終了応答２５００のCall-IDフィールドに記載されているセッションIDが記載され、かつ、終了時刻が記載されていない行を、通信状態管理DB１０１から検索する。この時点では、通信状態管理DB１０１に格納されている情報は、例えば図１１(c)のようになっているので、通信管理機能１０３は、図１１(c)の３行目を検索対象の行として検出する。
そして、通信管理機能１０３は、ユーザ端末３００とサービス提供サーバ３５０との間の暗号通信が終了したと判断し、通信状態管理DB１０１の３行目の終了時刻レコードに現在の時刻を入力する（ステップＳ１３８）。これにより、通信状態管理DB１０１に格納されている情報は、例えば図１１(d)のようになる。その後、メッセージ送受信機能１０５は、通信終了応答２５００をユーザ端末３００へ送信する（ステップＳ１３９）。
ユーザ端末３００のSIPクライアント機能３０２は、セッション管理装置１００から通信終了応答２５００を受信し（ステップＳ１４０）、鍵取得機能３０１は、通信終了要求２４００のCall-IDフィールドに記載したセッションIDおよび鍵情報３０００をメモリ１２から削除する（ステップＳ１４１）。そして、状態管理機能３０４は、内部状態を通信開始前状態へ遷移させると共に、GUI画面にサービス提供サーバ３５０との間の暗号通信に使用した鍵情報３０００を削除した旨、および、暗号通信を終了した旨を表示する。ユーザ端末３００の利用者は、GUI画面を確認することで、サービス提供サーバ３５０との間の暗号通信終了処理が正常に行われたことを認識することができる。
以上が、ユーザ端末３００がセッション管理装置１００を介して、サービス提供サーバ３５０との間の暗号通信を終了する場合の動作シーケンスである。なお、このシーケンスについては、サービス提供サーバ３５０からセッション管理装置１００を介してユーザ端末３００へ通信終了要求２４００を送信することも可能である。この場合、図６において、ユーザ端末３００とサービス提供サーバ３５０の立場が入れ替わるだけで、それ以外にシーケンスの変更はない。また、鍵の有効期限が近づいたことを契機として鍵の更新を行う場合には、鍵の有効期限が切れたことを契機として一連の動作を実行してもよい。
次に、暗号通信開始後、ユーザ端末３００とサービス提供サーバ３５０との間で暗号パケットを送信または受信する場合の一連の動作シーケンスを、図７を用いて説明する。なお、図７では、暗号パケットがユーザ端末３００からサービス提供サーバ３５０へ送信される例のみ説明する。
内部状態が暗号通信状態であるユーザ端末３００は、サービス提供サーバ３５０へ暗号パケットを送信する（ステップＳ１４２）。モニタリング機能付ルーティング装置４００のパケット制御機能４０１は、ユーザ端末３００から送信された暗号パケットを受信し（ステップＳ１４３）、受信した暗号パケットを複製して（ステップＳ１４４）、サービス提供サーバ３５０とパケットモニタ装置５００にそれぞれ送信する（ステップＳ１４５およびＳ１４７)。
サービス提供サーバ３５０は、ステップＳ１４５において、モニタリング機能付ルーティング装置４００から送信された暗号パケットを受信し（ステップＳ１４６）、メモリ１２に保存していた鍵情報３０００を用いて暗号パケットを復号する。
パケットモニタ装置５００は、ステップＳ１４７においてモニタリング機能付ルーティング装置400から送信された暗号パケットを受信し（ステップＳ１４８）、図１５(e)に示す暗号パケットのヘッダ領域に格納された情報を調べる。そして、パケットモニタ装置５００は、送信元のIPアドレスと宛先のIPアドレスを確認し、パケットDB５０１のパケット格納場所レコードに記載された場所へ保存する（ステップＳ１４９）。
本実施例１では、パケットDB５０１は、暗号通信を行う送信元の通信装置のIPアドレスおよび宛先の通信装置のIPアドレスの組み合わせ毎に、当該組み合わせの通信装置同士において送信された暗号パケットの格納場所を示すテーブルを持っており、パケット管理機能５０３は、受信した暗号パケットのヘッダ情報に基づいて当該テーブルを参照し、当該暗号パケットを、格納すべき格納場所へ格納する。
例えば、ユーザ端末３００からサービス提供サーバ３５０へ送信された暗号パケットのヘッダ領域に、送信元の通信装置（ユーザ端末３００）のIPアドレスとして192.168.10.1が格納され、宛先の通信装置（サービス提供サーバ３５０）のIPアドレスとして192.168.20.1が格納されている場合、図１５(a)に示す例では、パケット管理機能５０３は、当該暗号パケットを、/var/audit/packet/0000120060401/で識別されるディレクトリに保存する。
パケット管理機能５０３は、例えば、送信元の通信装置のIPアドレスと宛先の通信装置のIPアドレスの組み合わせを識別する文字列（例えば5桁の番号）と日付を示す文字列とを組み合わせた識別情報で識別されるディレクトリを生成し、送信元と宛先のIPアドレスの組み合わせが同一の暗号パケットが同一の日に送信された場合には、当該暗号パケットを同一のディレクトリに格納する。
以上が、ユーザ端末３００とサービス提供サーバ３５０との間で暗号パケットが送信または受信される場合の動作シーケンスである。なお、このシーケンスについては、サービス提供サーバ３５０がユーザ端末３００に対して暗号パケットを送信することも可能である。この場合、図７においてユーザ端末３００とサービス提供サーバ３５０の立場が入れ替わるだけで、それ以外にシーケンスの変更はない。また、Ｓ１４９において、パケットモニタ装置５００は、サービス提供サーバ３５０がユーザ端末３００へ送信した暗号パケットを受信すると、これをパケットDB501の/var/audit/packet/0000220060401/で識別されるディレクトリに保存する。
次に、暗号通信終了後に監査装置６００がパケットDB５０１に保存されている暗号パケットを取得し、復号を行うことによりパケットの内容を監査する一連の動作シーケンスについて、図８および図９を用いて説明する。
監査装置６００を利用する監査者は、監査したい通信のセッション情報をセッション管理装置１００から取得するため、監査装置６００の監査アプリケーション６０４が表示しているセッション情報検索画面３４００（図１６(a)参照）へ検索キーを入力する。監査アプリケーション６０４は、入力された検索キーを読み込む（Ｓ１５０）。
本実施例１において、監査者は、セッション情報検索画面３４００に入力する検索キーとして、暗号通信を行う送信元の通信装置の名前、宛先の通信装置の名前、および暗号パケットの送信時刻の範囲を入力し、暗号通信に用いられている暗号アルゴリズム名を指定するものとする。図１６(a)に示す例では、"user"という名前の通信装置が、"service"という名前の通信装置に対して、2006年4月1日の11:00以降に送信された暗号パケットが指定されている。
なお、通信装置の名前および通信時刻の範囲を指定する各項目は空白でも構わない。その場合、検索キーが入力されなかった項目については条件指定が無かったものと判定される。また、全ての検索キーが空白の場合、監査アプリケーション６０４は、過去に行われた全ての通信を監査対象としてセッション情報を検索する。
監査装置６００のセッション情報取得機能６０２は、セッション情報検索画面３４００に入力された検索キーをメモリ１２に保存する。そして、セッション情報取得機能６０２は、セッション情報一覧取得要求２８００を作成してセッション管理装置１００へ送信する（ステップＳ１５１）。
本実施例１において、セッション情報一覧取得要求２８００は、XMLメッセージのgetSessionInfoRequestタグとして記述される。図１４(a)は、監査装置６００からセッション管理装置１００へ送信されるセッション情報一覧取得要求２８００のうち、本実施例の説明に必要な部分のみを示している。セッション情報検索画面３４００には、検索キーとして入力された情報が記載される。セッション情報検索画面３４００の「送信元の通信装置の名前」および「宛先の通信装置の名前」の項目に入力された検索キーは、それぞれfromタグおよびtoタグに記載される。
また、「通信時刻の範囲」の項目に入力された検索キーは、startタグとendタグに記載される。また、指定された暗号アルゴリズム名は、encタグに記載される。なお、セッション情報検索画面３４００に検索キーが入力されていない項目については、対応するセッション情報一覧取得要求２８００のタグに"null"が記載される。
セッション管理装置１００のセッション情報通知機能１０６は、監査装置６００からセッション情報一覧取得要求２８００を受信すると（ステップＳ１５２）、通信管理機能１０３は、セッション情報一覧取得要求２８００のfromタグに記載されたユーザ端末３００の名前、toタグに記載されたサービス提供サーバ３５０の名前、startタグに記載された時刻、endタグに記載された時刻、およびencタグに記載された暗号アルゴリズム名を基にして、監査対象の通信のセッション情報について通信状態管理DB１０１を検索する（ステップＳ１５３）。
この時点では、通信状態管理DB１０１に格納されている情報は、例えば図１１(d)のようになっているので、通信管理機能１０３は、図１１(d)に示した例において、２行目と３行目に記載された各レコードの情報を取得する。そして、セッション情報通知機能１０６は、通信管理機能１０３が取得した各情報からセッション情報３１００を作成する。本実施例において、セッション情報通知機能１０６は、鍵IDが「12345679」であるセッション情報３１００と、鍵IDが「12345680」であるセッション情報３１００とを記載したセッション情報一覧取得応答２９００を作成し、監査装置６００へ送信する（ステップＳ１５４）。
本実施例１において、セッション情報一覧取得応答２９００は、例えば、XMLメッセージのgetSessionInfoResponseタグとして記述される。図１４(b)は、セッション管理装置１００から監査装置６００へ送信されるセッション情報一覧取得応答２９００のうち、本実施例の説明に必要な部分のみを示している。セッション管理装置１００によるセッション情報の検索結果がstatusタグに記載される。
セッション情報通知機能１０６は、検索の結果、セッション情報一覧取得要求２８００の条件に合致した通信のセッション情報が見つかった場合には、statusタグに"OK"と記載し、見つからなかった場合には"NG"と記載する。また、作成したセッション情報３１００は例えばXML形式で記載される。なお、１つのセッションにおいて複数の鍵が用いられている場合には、セッション情報一覧取得応答２９００には、複数のセッション情報３１００が記載されてもよい。
セッション情報３１００は、例えばXML形式のsessionInfoタグとして表現される。セッション情報３１００には、例えば図１４(c)に示すように、通信状態管理DB１０１から取得されたセッションIDが記載されるsessionIDタグ、鍵IDが記載されるkeyIDタグ、セッション管理装置１００のメモリ１２に保存されている送信元の通信装置の名前が記載されるterm1タグ、当該通信装置のIPアドレスが記載されるaddr1タグ、当該通信装置の通信相手の名前が記載されるterm2タグ、当該通信相手のIPアドレスが記載されるaddr2タグ、通信開始時刻が記載されるstartタグ、通信終了時刻が記載されるendタグ、および、使用される暗号アルゴリズム名が記載されるencタグが記載される。
監査装置６００のセッション情報取得機能６０２は、セッション管理装置１００からセッション情報一覧取得応答２９００を受信すると（ステップＳ１５５）、監査アプリケーション６０４は、内部状態を監査前状態へ遷移させる。そして、セッション情報一覧取得応答２９００のstatusタグに"NG"が記載されている場合、監査アプリケーション６０４は、監査対象の通信のセッション情報の再検索を促し、セッション情報検索画面３４００を再表示する。監査者は、セッション情報検索画面３４００に検索キーを再入力し、監査アプリケーション６０４は、再びステップＳ１５０を実行する。
セッション情報一覧取得応答２９００のstatusタグに"OK"が記載されている場合、監査アプリケーション６０４は、取得したセッション情報３１００と監査装置６００のメモリ１２に保存されていた検索キーとを照合した結果を、セッション情報検索結果画面３５００に表示する。
本実施例１において、監査アプリケーション６０４は、例えば図１６(b)に示すようなセッション情報検索結果画面３５００を表示する。セッション情報検索結果画面３５００には、セッション情報３１００のsessionIDタグに記載されたセッションID、term1タグに記載された送信元の通信装置の名前、addr1タグに記載された送信元の通信装置のIPアドレス、term2タグに記載された宛先の通信装置の名前、addr2タグに記載された宛先の通信装置のIPアドレス、startタグに記載された通信開始時刻、endタグに記載された通信終了時刻、およびencタグに記載された暗号アルゴリズム名が、新たに付与された監査IDと共に表示される。
なお、セッション情報検索結果画面３５００を表示する際に、監査アプリケーション６０４は、検索キーの送信元の通信装置の名前がterm1タグに記載されている名前と一致する場合に、セッション情報検索結果画面３５００の送信元の通信装置の名前の項目に、term1タグおよびaddr1タグに記載された情報を記載する。同様に、検索キーの宛先の通信装置の名前がterm2タグに記載されている名前と一致する場合に、監査アプリケーション６０４は、セッション情報検索結果画面３５００の宛先の通信装置の名前の欄にterm2タグおよびaddr2タグに記載された情報を記載する。
また、セッション情報一覧取得応答２９００から取得した複数のセッション情報３１００のうち、sessionIDタグに同じセッションIDが記載されているセッション情報３１００が二つ以上存在する場合、監査アプリケーション６０４は、まとめて一つの通信セッションとしてセッション情報検索結果画面３５００に表示する。
監査者は、セッション情報検索結果画面３５００を参照して、監査対象の暗号通信のセッション情報を確認する。そして、監査者は、監査対象の通信の条件を指定し直したい場合、セッション情報検索結果画面３５００に表示されている再検索ボタンを押す。再検索ボタンが押されると、監査アプリケーション６０４は、セッション情報検索画面３４００を再度表示し、監査者から入力された検索キーに基づいて、再びステップＳ１５０を実行する。このように、セッション情報検索結果画面３５００を参照することにより、監査者は、より効率よく監査処理を進めることができる。
一方、監査者は、検索されたセッション情報に対応する通信内容の監査を実施する場合、セッション情報検索結果画面３５００に表示された通信のセッション情報一覧から、監査対象の通信を選択し、監査開始ボタンを押す。監査対象ボタンが押されると、監査アプリケーション６０４は、選択された監査対象の通信情報を監査装置６００のメモリ１２に保存すると共に、鍵取得機能６０１が鍵取得要求３２００を作成して鍵管理装置２００へ送信する（ステップＳ１５６）。
本実施例１において、鍵取得要求３２００は、例えば図１４(d)に示すように、XMLメッセージのgetKeyRequestタグとして記述される。図１４(d)は、監査装置６００から鍵管理装置２００へ送信されるセッション情報３１００のうち、本実施例の説明に必要な部分のみを示している。監査対象の通信の鍵IDがkeyIDタグに記載される。なお、１つの鍵取得要求３２００には、複数のkeyIDタグが記載されてもよい。
鍵管理装置２００の鍵送受信機能２０３は、監査装置６００から鍵取得要求３２００を受信すると（ステップＳ１５７）、鍵管理機能２０２は、鍵取得要求３２００のkeyIDタグに記載されている鍵IDをキーに鍵管理DB２０１を検索する（ステップＳ１５８）。この時点では、鍵管理DB２０１に格納されている情報は、例えば図１３(d)に示すようになっているものと仮定する。
鍵管理機能２０２は、鍵取得要求３２００のkeyIDタグに記載されている鍵IDが、鍵管理DB２０１内の２行目と３行目に登録されていることを検出する。そして、鍵管理機能２０２は、２行目に記載された鍵と３行目に記載された鍵を取得し（ステップＳ１５９）、鍵送受信機能２０３は、取得された鍵を用いて鍵取得応答３３００を作成し、監査装置６００へ送信する（ステップＳ１６０）。
本実施例１では、鍵取得応答３３００は、例えば図１４(e)に示すように、XMLメッセージのgetKeyResponseタグとして記述される。図１４(e)は、鍵管理装置２００から監査装置６００へ送信される鍵取得応答３３００のうち、本実施例の説明に必要な部分のみを示している。鍵送受信機能２０３は、鍵管理DB２０１から監査対象の通信の鍵IDおよび鍵を取得した結果をstatusタグに記載する。登録成功の場合にはstatusタグに"OK"が記載され、登録失敗の場合には"NG"が記載される。また、監査対象の通信の鍵IDがkeyIDタグに記載され、鍵がkeyタグに記載される。なお、keyIDタグおよびkeyタグは監査対象の通信の数だけ複数記載されていてもよい。
監査装置６００の鍵取得機能６０１は、鍵管理装置２００から鍵取得応答３３００を受信すると（ステップＳ１６１）、鍵取得応答３３００のkeyIDタグに記載されている鍵IDおよびkeyタグに記載されている鍵を取得し（ステップＳ１６２）、監査装置６００のメモリ１２に保存する。そして、パケット取得・復号機能６０３は、パケット取得要求３６００を作成し、パケットモニタ装置５００へ送信する（ステップＳ１６３）。
本実施例１では、パケット取得要求３６００は、例えば図１５(b)に示すように、XMLメッセージのgetPacketRequestタグとして記述される。図１５(b)は、監査装置６００からパケットモニタ装置５００へ送信されるパケット取得要求３６００のうち、本実施例の説明に必要な部分のみを示している。監査装置６００のメモリ１２に保存された監査対象の通信情報のうち、送信元の通信装置のIPアドレスがfromタグに記載され、宛先の通信装置のIPアドレスがtoタグに記載され、開始時刻がstartタグに記載され、終了時刻がendタグに記載される。なお、これらのフィールドは、監査対象の通信のセッションID毎に複数記載されてもよい。
パケットモニタ装置５００のパケット送信機能５０４が監査装置６００からパケット取得要求３６００を受信すると（Ｓ１６４）、パケット管理機能５０３は、パケット取得要求３６００のaddr1タグに記載されているユーザ端末３００のIPアドレス、addr2タグに記載されているサービス提供サーバ３５０のIPアドレス、startタグに記載されている暗号通信の開始時刻、およびendタグに記載されている暗号通信の終了時刻をキーとして、パケットDB５０１を検索する。この時点では、パケットDB５０１に格納されている情報は、例えば図１５(a)のようになっていると仮定する。
パケット管理機能５０３は、パケット取得要求３６００のaddr1タグに記載されているユーザ端末３００のIPアドレスおよびaddr2タグに記載されているサービス提供サーバ３５０のIPアドレスが、１行目に記載されていることを検出する。そして、startタグに記載されている開始時刻からendタグに記載されている終了時刻までの範囲の日付が、パケット格納場所の名称の下８桁と一致することを確認する。すなわち、図１５(b)において、パケット取得対象の暗号通信が行われた日付は「2006年4月1日」であり、図１５(a)の１行目に記載されたパケット格納場所の下８桁が「20060401」となっていることを確認する。その後、パケット管理機能５０３は、１行目のパケット格納場所レコードに示されている格納場所へアクセスし、ユーザ端末３００からサービス提供サーバ３５０へ送信された暗号パケットを取得する（ステップＳ１６５）。
そして、パケット送信機能５０４は、パケット取得応答３７００を作成し、監査装置６００へ送信する（ステップＳ１６６）。監査装置６００のパケット取得・復号機能６０３がパケットモニタ装置５００からパケット取得応答３７００を受信すると（ステップＳ１６７）、監査アプリケーション６０４は、パケットモニタ装置５００が暗号パケットを取得済である旨を画面に表示する。そして、監査者は、監査アプリケーション６０４が表示した画面を見て、暗号パケットを取得済である旨を確認する。
本実施例１では、パケット取得応答３７００は、例えば図１５(c)に示すように、XMLメッセージのgetPacket Responseタグとして記述される。図１５(c)は、パケットモニタ装置５００から監査装置６００へ送信されるパケット取得応答３７００のうち、本実施例の説明に必要な部分のみを示している。パケットDB５０１から暗号パケットが取得された結果がstatusタグに記載される。取得成功の場合にはstatusタグに"OK"が記載され、取得失敗の場合には"NG"が記載される。
その後、パケットモニタ装置５００のパケット送信機能５０４は、ユーザ端末３００からサービス提供サーバ３５０へ送信された暗号パケットを監査装置６００へ送信する（ステップＳ１６８）。そして、監査装置６００のパケット取得・復号機能６０３は、パケットモニタ装置５００から暗号パケットを受信し（ステップＳ１６９）、監査装置６００内の外部記憶装置１７に保存する。
パケットモニタ装置５００のパケット送信機能５０４は、暗号パケットを全て監査装置６００に送信した場合、パケット送信終了通知３８００を作成して監査装置６００へ送信する（ステップＳ１７０）。本実施例１において、パケット送信終了通知３８００は、例えば図１５(d)に示すように、XMLメッセージのendSendingPacketInfoタグとして記述される。
監査装置６００のパケット取得・復号機能６０３がパケットモニタ装置５００からパケット送信終了通知３８００を受信すると（ステップＳ１７１）、監査アプリケーション６０４は、内部状態を監査処理実施状態に遷移させる。そして、パケット取得・復号機能６０３は、監査装置６００のメモリ１２から鍵と監査対象の通信情報を取り出し、監査装置６００の外部記憶装置１７に保存されている暗号パケットを復号する。監査者は、復号されたパケットを基に、ユーザ端末３００とサービス提供サーバ３５０との通信の通信内容を監査する。
監査終了後、監査者は、監査アプリケーション６０４に監査終了の指示を行うと、監査アプリケーション６０４は、監査装置６００のメモリ１２に保存されている鍵IDおよび鍵、ならびに監査装置６００の外部記憶装置１７に保存されている暗号パケットを削除する。そして、監査アプリケーション６０４は、監査処理を終了し（Ｓ１７２）、内部状態を待ち状態に遷移させると、監査処理が終了したことを表示する。監査者は、監査アプリケーション６０４が表示した内容を確認することで、監査処理が終了したことを認識する。
以上が、暗号通信終了後に監査装置６００がパケットDB５０１に保存されている暗号パケットを取得し、取得した暗号パケットを復号してパケットの内容を監査する場合の動作シーケンスである。なお、通信内容を監査する場合、監査アプリケーション６０４は、復号した一連のパケットを解析して、通信に用いられたアプリケーションプロトコルの種類（HTTP等）、および、ユーザ端末３００がアクセスしたサービス提供サーバ３５０のリソース名（URL等）といった、通信のサマリを表示するようにしてもよい。
なお、本実施例１における監査の実施形態としては、暗号通信終了した後に当該暗号通信の内容を監査するだけでなく、リアルタイムで行われている暗号通信の内容を監査することも可能である。この場合、図８のステップＳ１５０からステップＳ１５５までの処理を行った後、監査装置６００の監査アプリケーション６０４が表示するセッション情報検索結果画面３５００には、現在行われている暗号通信のセッション情報が含まれることになる。そして、監査者が現在行われている暗号通信を選択すると、ステップＳ１５６からステップＳ１７１までの処理を行った後、監査装置６００の監査アプリケーション６０４は、リアルタイム監査の処理を行い、ステップＳ１７２で監査処理を終了する。
また、本実施例１では、鍵管理装置２００でなく、ユーザ端末３００またはサービス提供サーバ３５０等の暗号通信を行う通信装置が鍵情報を生成することも可能である。この場合、ユーザ端末３００およびサービス提供サーバ３５０には、鍵生成機能が新たに設けられる。この場合の暗号通信開始時および鍵更新時の動作シーケンスは次のようになる。
まず、ユーザ端末３００の鍵生成機能は、ステップＳ１０１において、サービス提供サーバ３５０へ送信するパケットを暗号化するための鍵、当該鍵の有効期間、および暗号アルゴリズム名を含む鍵情報３０００を生成してユーザ端末３００のメモリ１２に保存すると共に、通信開始要求２０００のBODY部に生成した鍵情報３０００を記載する。そして、SIPクライアント機能３０２は、通信開始要求２０００をセッション管理装置１００へ送信する。
セッション管理装置１００のメッセージ送受信機能１０５がステップＳ１０２でユーザ端末３００から通信開始要求２０００を受信すると、鍵取得機能１０４は、通信開始要求２０００のBODY部に記載されている鍵情報３０００をセッション管理装置１００のメモリ１２に保存する。そして、メッセージ送受信機能１０５は、ステップＳ１１０を実行する。すなわち、メッセージ送受信機能１０５は、通信開始要求２０００をサービス提供サーバ３５０へ送信する。
次に、サービス提供サーバ３５０は、ステップＳ１１１からステップＳ１１５を実行する。なお、ステップＳ１１３において、サービス提供サーバ３５０の鍵取得機能３０１は、通信開始要求２０００のBODY部に記載されている鍵情報３０００を取得し、取得した鍵情報３０００を、当該２０００のCall-IDフィールドに記載されているセッションIDに対応付けてサービス提供サーバ３５０のメモリ１２に保存する。ここで保存された鍵は、ユーザ端末３００から送信された暗号パケットを復号する際に使用され、ユーザ端末３００へ送信されるパケットの暗号化には使用されない。
また、ステップＳ１１４において、鍵取得機能３０１は、ユーザ端末３００へ送信するパケットを暗号化するための鍵、鍵の有効期間、および暗号アルゴリズム名を含む鍵情報３０００を通信開始応答２１００のBODY部に記載する。そして、SIPクライアント機能３０２は、当該通信開始応答２１００をセッション管理装置１００へ送信する。
セッション管理装置１００のメッセージ送受信機能１０５は、ステップＳ１１６でサービス提供サーバ３５０から通信開始応答２１００を受信すると、ステップＳ１１７を実行する。通信開始応答２１００が通信を拒否する旨を示すメッセージを含む場合、メッセージ送受信機能１０５は、ステップＳ１２２以降の処理を実行する。通信開始応答２１００が通信を許可する旨を示すメッセージを含む場合、メッセージ送受信機能１０５は、通信開始応答２１００内の鍵情報３０００をセッション管理装置１００のメモリ１２に保存する。そして、鍵取得機能１０４は、ステップＳ１０３を実行する。すなわち、鍵取得機能１０４は、鍵生成要求２２００を生成して鍵管理装置２００へ送信する。なお、この場合、鍵生成要求２２００には、ユーザ端末３００から送信された鍵情報３０００とサービス提供サーバ３５０から送信された鍵情報３０００とが記載される。
そして、鍵管理装置２００は、ステップＳ１０４からステップＳ１０７を実行する。なお、ステップＳ１０５において、鍵管理機能２０２は、鍵生成要求２２００に記載されている、ユーザ端末３００から送信された鍵情報３０００に対応する鍵ID、および、サービス提供サーバ３５０から送信された鍵情報３０００に対応する鍵IDを、それぞれ生成する。そして、ステップＳ１０６において、鍵管理機能２０２は、鍵管理DB２０１に、鍵ID毎に鍵情報３０００内の暗号アルゴリズムおよび鍵を登録する。
そして、セッション管理装置１００の鍵取得機能１０４は、ステップＳ１０８において鍵管理装置２００から鍵生成応答２３００を受信すると、ステップＳ１１８からステップＳ１２１を実行する。そして、鍵取得機能１０４は、通信開始応答２１００のBODY部に、サービス提供サーバ３５０から送信された鍵情報３０００を記載して、ステップＳ１２７を実行する。
そして、ユーザ端末３００は、ステップＳ１２８からステップＳ１３０を実行する。なお、ステップＳ１３０において、ユーザ端末３００の鍵取得機能３０１は、通信開始応答２１００のBODY部に記載されている鍵情報３０００を取得し、通信開始応答２１００のCall-IDフィールドに記載されているセッションIDと対応付けてユーザ端末３００のメモリ１２に保存する。ここで、保存された鍵情報３０００内の鍵は、サービス提供サーバ３５０から送信された暗号パケットを復号する際に使用され、サービス提供サーバ３５０へ送信されるパケットの暗号化には使用されない。
また、暗号通信終了のシーケンスについては、ステップＳ１３５およびステップＳ１４０において、ユーザ端末３００およびサービス提供サーバ３５０の鍵取得機能３０１がそれぞれメモリ１２に保存していたセッションIDおよび鍵情報３０００を削除する。
なお、ユーザ端末３００またはサービス提供サーバ３５０が暗号通信に使用される鍵を生成する場合、上記では受信用の鍵と送信用の鍵を別にしたが、送信用の鍵と受信用の鍵を同じにしてもよい。その場合、サービス提供サーバ３５０が鍵情報３０００を作成してユーザ端末３００へ送信する処理および鍵管理装置２００がサービス提供サーバ３５０によって作成された鍵情報３０００を鍵管理DB２０１に登録する処理は不要である。
＜実施例２＞
本実施例２では、監査装置６００によって指定された暗号通信のみが監査対象とされ、パケットモニタ装置５００は、対象となる暗号通信において送信される暗号パケットのみ取得する。これにより、パケットモニタ装置５００は、保存すべき暗号パケットのデータ量を少なくすることができる。
図１７は、本実施例２の通信内容監査支援システムのシステム構成図である。本実施例２では、実施例１の場合と異なり、セッション管理装置１００、パケットモニタ装置５００、および監査装置６００内に、新たな機能が追加されている。
セッション管理装置１００は、監査装置６００から指定された監査条件を登録する監査条件テーブル１０２と、監査条件テーブル１０２に登録された監査条件を基に通信内容の監査に関する制御を行うバス１０７とを新たに備える。また、セッション情報通知機能１０６は、実施例１で説明した機能に加え、監査対象となる暗号通信が開始した場合に当該暗号通信のセッション情報を監査装置６００に通知する機能を有する。
パケットモニタ装置５００は、監査装置６００から指定された暗号通信において送信される暗号パケットのみ取得し、それ以外の暗号パケットを破棄するパケット収集制御機能５０５を新たに備える。
監査装置６００は、セッション管理装置１００に監査対象の暗号通信の条件を指示する監査条件指示機能６０５と、セッション管理装置１００から暗号通信開始の通知を受けた場合に、当該暗号通信において送信される暗号パケットの収集をパケットモニタ装置５００に指示するパケット収集指示機能６０６とを新たに備える。なお、監査アプリケーション６０４は、実施例１において説明した機能に加え、監査対象となる暗号通信の条件を設定したり、指定した監査条件と合致する暗号通信の通信内容を通信開始時からリアルタイム監査したりする機能を有する。
次に、ユーザ端末３００がセッション管理装置１００を介して、サービス提供サーバ３５０と暗号通信に使用する鍵を共有し、暗号通信を開始する場合の一連の動作シーケンスについて、図３、図４、図１８、および図１９を用いて説明する。なお、本実施例２では、実施例１の場合とは異なり、監査装置６００が事前にセッション管理装置１００に対して、監査対象となる暗号通信の条件を指定する。また、セッション管理装置１００は、ユーザ端末３００から通信開始要求を受信すると、これから開始される暗号通信が事前に監査装置６００から指定された条件と合致するか否かを調べ、合致する場合、監査装置６００に暗号通信の開始を通知し、監査装置６００は、パケットモニタ装置５００にパケット収集を指示する。
まず、監査装置６００を利用する監査者は、監査アプリケーション６０４が表示している監査条件入力画面３９００（図２２(a)参照）に、監査対象の暗号通信に関する条件を入力する。監査アプリケーション６０４は、入力された監査条件を読み込む（ステップＳ２０１）。
本実施例２において、監査条件入力画面３９００に入力される監査条件には、監査のタイミング、監査対象の暗号通信を行う送信元の通信装置の名前、宛先の通信装置の名前、暗号パケットの送信時刻の範囲、および暗号通信に使用される暗号アルゴリズム名が含まれる。図２２(a)に示す監査条件入力画面３９００の例では、名前が"user"である通信装置から、名前が"service"である通信装置へ送信された暗号パケットであり、かつ、通信に使用される暗号アルゴリズム名が"AES-256bit"である暗号パケットが監査対象の暗号パケットとして指定された様子が示されている。なお、通信装置の名前または監査対象時間帯を指定する各項目は空白でも構わない。検索キーが入力されなかった項目については、監査アプリケーション６０４は、条件指定が無かったものとして取り扱う。
監査装置６００の監査条件指示機能６０５は、監査条件入力画面３９００に入力された監査条件を基に監査条件登録要求４０００を作成してセッション管理装置１００へ送信する（ステップＳ２０２）。
本実施例２において、監査条件登録要求４０００は、例えば図２２(b)に示すように、XMLメッセージのregAuditCondRequestタグとして記述される。図２２(b)は、監査装置６００からセッション管理装置１００へ送信される監査条件登録要求４０００のうち、本実施例の説明に必要な部分のみを示している。監査条件入力画面３９００には、監査条件として入力された情報が記載される。監査条件入力画面３９００の「監査のタイミング」の項目で選択された条件がmodeタグに記載され、「送信元の通信装置の名前」および「宛先の通信装置の名前」の項目に入力された条件が、それぞれfromタグおよびtoタグに記載される。
また、「監査対象時間帯」の項目に入力された条件が、startタグとendタグに記載され、「暗号アルゴリズム」の項目で選択された条件が、encタグに記載される。なお、監査条件入力画面３９００に監査条件が入力されていない項目については、対応する監査条件登録要求４０００内のタグに"null"が記載される。また、監査条件入力画面３９００の「監査のタイミング」の項目で「後で」が選択された場合、対応するmodeタグには"afterward"が記載され、「リアルタイム」が選択された場合、対応するmodeタグには"realtime"が記載される。
セッション管理装置１００のバス１０７は、監査装置６００から監査条件登録要求４０００を受信すると（ステップＳ２０３）、監査条件登録要求４０００の情報を監査条件テーブル１０２に登録し（ステップＳ２０４）、監査条件登録応答４１００を作成して監査装置６００へ送信する（ステップＳ２０５）。
本実施例２において、監査条件登録応答４１００は、例えば図２２(c)に示すように、XMLメッセージのregAuditCond Responseタグとして記述される。図２２(c)は、セッション管理装置１００から監査装置６００へ送信される監査条件登録応答４１００のうち、本実施例の説明に必要な部分のみを示している。監査条件登録要求４０００に記載された監査条件がセッション管理装置１００によって監査条件テーブル１０２に登録された結果がstatusタグに記載される。監査条件が監査条件テーブル１０２に正常に登録された場合、statusタグには"OK"が記載され、正常に登録されなかった場合には"NG"が記載される。
また、セッション管理装置１００の監査条件テーブル１０２には、例えば図２３(a)に示すように、監査のタイミング、暗号パケットの送信元の通信装置の名前、暗号パケットの宛先の通信装置の名前、暗号通信が行われる時刻の範囲、および暗号通信に使用される暗号アルゴリズム名が格納される。図２３(a)に示す例では、ステップＳ２０４が実行されることにより、２行目の監査条件が追加された後の状態が示されている。
以上の一連の処理が行われた後、図３を用いて説明したステップＳ１０２において、セッション管理装置１００のメッセージ送受信機能１０５がユーザ端末３００から通信開始要求２０００を受信することにより、図３または図４において説明したステップＳ１０３からステップＳ１２１までの処理が順次行われる。すなわち、セッション管理装置１００は、鍵管理装置２００によって生成された鍵情報３０００を取得し、これをサービス提供サーバ３５０へ送信する。そして、セッション管理装置１００は、サービス提供サーバ３５０から通通信開始応答２１００を受信すると、通信状態管理DB１０１を更新する。なお、更新後の通信状態管理DB１０１内の情報は、例えば図１１(b)に示した内容であると仮定する。
以上の処理が行われた後、セッション管理装置１００のバス１０７は、ステップＳ１２１において通信状態管理DB１０１に登録されたセッション情報が監査条件テーブル１０２に登録された条件と一致するか否かを判定することにより、これから開始される暗号通信が監査対象であるかを判定する（ステップＳ２０７）。判定の結果、これから開始される暗号通信が監査対象でない場合、通信内容監査支援システムはステップＳ１２７以降の処理を実行する。
一方、これから開始される暗号通信が監査対象であり、監査条件テーブル１０２の内容が図２３(a)に示すような状態である場合、セッション管理装置１００のセッション情報通知機能１０６は、監査条件テーブル１０２の２行目の条件と、図１１(b)に示す通信状態管理DB１０１の２行目に登録されている情報とを基に、監査要件定義５０００を作成する。
本実施例２において、監査要件定義５０００は、例えば図２２(h)に示すように、XML形式のdefAuditReqタグとして記述される。図２２(h)に示す例において、監査要件定義５０００には、監査のタイミングが記載されるmodeタグ、セッションIDが記載されるsessionIDタグ、送信元の通信装置のIPアドレスが記載されるfromタグ、および宛先の通信装置のIPアドレスが記載されるtoタグが記載される。
次に、セッション情報通知機能１０６は、監査要件定義５０００が記載された暗号通信開始通知４２００を作成する（ステップＳ２０８）。そして、バス１０７は、監査要件定義５０００のmodeタグを参照して、これから監査を実施するか否かを判定する（ステップＳ２０９）。
監査要件定義５０００のmodeタグに"afterward"と記載されている場合、セッション管理装置１００のセッション情報通知機能１０６は、暗号通信開始通知４２００を監査装置６００へ送信する（ステップＳ２１１）。一方、監査要件定義５０００のmodeタグに"realtime"と記載されている場合、セッション情報通知機能１０６は、、セッション管理装置１００のメモリ１２に保存されている鍵情報３０００を暗号通信開始通知４２００に記載して（ステップＳ２１０）、ステップＳ２１１に示した処理を実行する。
本実施例２において、暗号通信開始通知４２００は、例えば図２２(d)に示すように、XMLメッセージのstartCommunicationInfoタグとして記述される。図２２(d)は、セッション管理装置１００から監査装置６００へ送信される暗号通信開始通知４２００のうち、本実施例の説明に必要な部分のみを示している。暗号通信開始通知４２００には、図２２(h)に示した監査要件定義５０００が記載される。暗号通信がリアルタイムに監査される場合には、更に、図１２(c)で説明した鍵情報３０００が記載される。
監査装置６００のセッション情報取得機能６０２は、セッション管理装置１００から暗号通信開始通知４２００を受信すると（ステップＳ２１２）、暗号通信開始通知４２００に記載されている監査要件定義５０００を監査装置６００のメモリ１２に保存し、監査要件定義５０００のmodeタグを参照して、これから監査を実施するか否かを判定する（ステップＳ２１３）。
modeタグに"afterward"と記載されている場合、監査装置６００のパケット収集指示機能６０６は、パケット収集開始要求４６００を作成してパケットモニタ装置５００へ送信する（ステップＳ２１５）。一方、modeタグに"realtime"と記載されている場合、監査装置６００のセッション情報取得機能６０２は、暗号通信開始通知４２００に記載されている鍵情報３０００を監査要件定義５０００と対応づけて監査装置６００のメモリ１２に保存する（ステップＳ２１４）。そして、監査アプリケーション６０４は、内部状態をリアルタイム監査状態に遷移させ、ステップＳ２１５に示した処理を実行する。
本実施例２において、パケット収集開始要求４６００は、例えば図２３(c)に示すように、XMLメッセージのstartGathering PacketRequestタグとして記述される。図２３(c)は、監査装置６００からパケットモニタ装置５００へ送信されるパケット収集開始要求４６００のうち、本実施例の説明に必要な部分のみを示している。監査要件定義５０００のmodeタグ、sessionIDタグ、fromタグ、およびtoタグ内の情報がそのままパケット収集開始要求４６００のmodeタグ、sessionIDタグ、fromタグ、およびtoタグにそれぞれ記載される。
パケットモニタ装置５００のパケット収集制御機能５０５は、監査装置６００からパケット収集開始要求４６００を受信すると（ステップＳ２１６）、パケット収集開始要求４６００の情報をパケットDB５０１の空白行に記載する。また、パケット管理機能５０３は、暗号パケットの格納領域を作成し、格納場所をパケットDB５０１のパケット格納場所レコードに記載する。そして、パケット管理機能５０３は、パケットDB５０１の状態レコードに「パケット収集中」と記載する。そして、パケット収集制御機能５０５は、パケット収集開始応答４７００を作成して監査装置６００へ送信し（ステップＳ２１７）、内部状態をパケット受信待ち状態に遷移させる。
本実施例２において、パケット収集開始応答４７００は、例えば図２３(d)に示すように、XMLメッセージのstartGathering PacketResponseタグとして記述される。図２３(d)は、パケットモニタ装置５００から監査装置６００へ送信されるパケット収集開始応答４７００のうち、本実施例の説明に必要な部分のみを示している。パケットの収集対象である暗号通信の情報がパケットDB５０１に登録された結果が、statusタグに記載される。登録成功の場合はstatusタグに"OK"が記載され、失敗の場合には"NG"が記載される。また、パケット収集開始応答４７００には、パケット収集開始要求４６００のsessionIDタグが記載される。
なお、本実施例２において、パケットDB５０１は、例えば図２３(b)に示すようなデータ構造を有しており、図１５(a)で説明した実施例１のパケットDB５０１と比較して、「セッションID」、「監査のタイミング」、および「状態」のレコードが新たに追加されている。これにより、パケットモニタ装置５００が取得した暗号パケットをセッションID毎に管理することができ、監査時に監査装置６００から要求のあったセッションIDに対応する暗号パケットを確実に取得することができる。
また、「監査のタイミング」レコードを参照することにより、パケット収集制御機能５０５は、リアルタイム監査時に、受信した暗号パケットを直ちに監査装置６００へ送信することができる。また、状態レコードを確認することで、パケットモニタ装置５００のパケット管理機能５０３は、受信したパケットをセッションID毎に分けて保存することができる。
監査装置６００のパケット収集指示機能６０６がパケットモニタ装置５００からパケット収集開始応答４７００を受信すると（ステップＳ２１８）、セッション情報取得機能６０２は、暗号通信開始確認応答４３００を作成してセッション管理装置１００へ送信する（ステップＳ２１９）。本実施例２において、暗号通信開始確認応答４３００は、例えば図２２(e)に示すように、XMLメッセージのackStartCommunicationInfoタグとして記述される。また、ackStartCommunicationInfoタグ内には、監査要件定義５０００のsessionIDタグが記載される。
セッション管理装置１００のセッション情報通知機能１０６は、監査装置６００から暗号通信開始確認応答４３００を受信すると（ステップＳ２２０）、鍵取得機能１０４は、セッション管理装置１００のメモリ１２に保存されている鍵情報３０００を、図１０(b)において説明したに通信開始応答２１００のBODY部に記載する。そして、メッセージ送受信機能１０５は、通信開始応答２１００をユーザ端末３００へ送信し、実施例１で説明したステップＳ１２７以降の処理を実行する。
以上が、本実施例２において、ユーザ端末３００がセッション管理装置１００を介して、サービス提供サーバ３５０と暗号通信に使用される鍵を共有し、暗号通信を開始する場合の動作シーケンスである。
また、ユーザ端末３００とサービス提供サーバ３５０との間で共有された鍵の有効期限が切れ、その契機で鍵更新を行う場合の一連の動作において、図１８のステップＳ２０２からステップＳ２１２までは暗号通信開始の動作シーケンスと同一である。なお、ステップＳ２１２において、監査装置６００がセッション管理装置１００から暗号通信開始通知４２００を受信した場合、監査装置６００の内部状態は待ち状態またはリアルタイム監査状態のいずれかである。また、このとき、通信状態管理DB１０１内のデータは、図１１(c)のようになっているものと仮定する。
ステップＳ２１２において、監査装置６００のセッション情報取得機能６０２がセッション管理装置１００から暗号通信開始通知４２００を受信すると、監査装置６００のメモリ１２内に対応する監査要件定義５０００が保存されているか否かを判定する。メモリ１２内に対応する監査要件定義５０００が保存されている場合、セッション情報取得機能６０２は、暗号通信開始通知４２００に記載されている監査要件定義５０００のsessionIDタグと、監査装置６００のメモリ１２に保存されている監査要件定義５０００のsessionIDタグとを比較し、セッションIDが一致すれば一連の処理が鍵更新を契機としたものであると判断する。
そして、ステップＳ２１３において、監査要件定義５０００のmodeタグに"afterward"と記載されている場合、ステップＳ２１９が実行される。一方、監査要件定義５０００のmodeタグに"realtime"と記載されている場合、ステップＳ２１４が実行された後に、ステップＳ２１９が実行される。
以上が、本実施例２において、ユーザ端末３００とサービス提供サーバ３５０との間で共有した鍵の有効期限が切れ、その契機で鍵更新を行う場合の動作シーケンスである。なお、このシーケンスについては、サービス提供サーバ３５０がセッション管理装置１００を介してユーザ端末３００へ通信開始要求２０００を送信することも可能である。また、鍵の有効期限が切れたことを契機とするのではなく、鍵の有効期限が近づいたことを契機として一連の動作が実行されてもよい。
次に、ユーザ端末３００がセッション管理装置１００を介して、サービス提供サーバ３５０との間の暗号通信を終了する場合の一連の動作シーケンスを、図２０を用いて説明する。
ステップＳ１３２において、セッション管理装置１００のメッセージ送受信機能１０５がユーザ端末３００から通信終了要求２４００を受信すると、実施例１において図６を用いて説明したステップＳ１３３からステップＳ１３８までの処理が順次行われる。すなわち、セッション管理装置１００は、通信終了要求２４００をサービス提供サーバ３５０へ送信し、サービス提供サーバ３５０から通信終了応答２５００を受信すると、通信状態管理DB１０１内の情報を更新する。
以上の処理が行われた後、セッション管理装置１００のバス１０７は、ステップＳ１２１において、通信状態管理DB１０１に登録されている情報が監査条件テーブル１０２に登録されている条件に一致するか否かを判定することにより、終了対象の暗号通信が監査対象であるか否かを判定する（ステップＳ２２１）。
終了対象の暗号通信が監査対象でなかった場合（Ｓ２２１：Ｎｏ）、通信内容監査支援システムはステップＳ１３９以降の処理を実行する。一方、終了対象の暗号通信が監査対象であった場合（Ｓ２２１：Ｙｅｓ）、セッション管理装置１００のセッション情報通知機能１０６は、暗号通信終了通知４４００を作成して監査装置６００へ送信する（ステップｓ２２２）。
本実施例２において、暗号通信終了通知４４００は、例えば図２２(f)に示すように、XMLメッセージのendCommunication Infoタグとして記述される。図２２(f)は、セッション管理装置１００から監査装置６００へ送信される暗号通信終了通知４４００のうち、本実施例の説明に必要な部分のみを示している。通信終了要求２４００のCall-IDフィールドに記載されているセッションIDが、暗号通信終了通知４４００のsessionIDタグに記載される。
監査装置６００のセッション情報取得機能６０２は、セッション管理装置１００から暗号通信終了通知４４００を受信すると（ステップＳ２２３）、パケット収集終了要求４８００を作成してパケットモニタ装置５００へ送信する（ステップＳ２２４）。
本実施例２において、パケット収集終了要求４８００は、例えば図２３(e)に示すように、XMLメッセージのendGatheringPacketRequestタグとして記述される。図２３(e)は、監査装置６００からパケットモニタ装置５００へ送信されるパケット収集終了要求４８００のうち、本実施例の説明に必要な部分のみを示している。パケット収集終了要求４８００のsessionIDタグには、暗号通信終了通知４４００のsessionIDタグの情報がそのまま記載される。
パケットモニタ装置５００のパケット収集制御機能５０５は、監査装置６００からパケット収集終了要求４８００を受信すると（ステップＳ２２５）、パケットの収集を終了する。具体的には、パケットDB５０１内のデータが図２３(b)に示すような状態にある場合に、パケット収集制御機能５０５は、パケット収集終了要求４８００に記載されているセッションＩＤに対応するレコードの状態を示す情報を、「パケット収集中」から「パケット収集済」に書き換える。そして、パケット収集制御機能５０５は、パケット収集終了応答４９００を作成して監査装置６００へ送信し（ステップＳ２２６）、内部状態を待ち状態に遷移させる。
本実施例２において、パケット収集終了応答４９００は、例えば図２３(f)に示すように、XMLメッセージのendGatheringPacketResponseタグとして記述される。図２３(f)は、パケットモニタ装置５００から監査装置６００へ送信されるパケット収集終了応答４９００のうち、本実施例の説明に必要な部分のみを示している。パケット収集制御機能５０５によってパケット収集の終了処理が行われた結果がstatusタグに記載される。終了成功の場合はstatusタグに"OK"が記載され、失敗の場合には"NG"が記載される。また、パケット収集終了応答４９００には、パケット収集終了要求４８００のsessionIDタグが記載される。
監査装置６００のパケット収集指示機能６０６がパケットモニタ装置５００からパケット収集終了応答４９００を受信すると（ステップＳ２２７）、セッション情報取得機能６０２は、終了対象の暗号通信がリアルタイム監査を実施していたか否かを判定する（ステップＳ２２８）。ステップＳ２１２の後にセッション情報３１００と共に監査装置６００のメモリ１２に保存された監査のタイミングを示す情報が"afterward"である場合、セッション情報取得機能６０２は、リアルタイム監査を実施していなかったと判定し、暗号通信終了確認応答４５００を作成してセッション管理装置１００へ送信する（ステップＳ２３０）。
一方、監査のタイミングを示す情報が"realtime"である場合、セッション情報取得機能６０２は、リアルタイム監査を実施していたと判定し、監査装置６００のメモリ１２に保存している鍵情報３０００を削除し（ステップＳ２２９）、内部状態を待ち状態へ遷移させた後、ステップＳ２３０に示した処理を実行する。本実施例２において、暗号通信終了確認応答４５００は、例えば図２２(g)に示すように、XMLメッセージのackEndCommunicationInfoタグとして記述される。また、ackEndCommunicationInfoタグの中には、暗号通信終了通知４４００のsessionIDタグが記載される。
セッション管理装置１００のセッション情報通知機能１０６は、監査装置６００から暗号通信終了確認応答４５００を受信すると（ステップＳ２３１）、メッセージ送受信機能１０５は、通信終了応答２５００を作成してユーザ端末３００へ送信し、実施例１において説明したステップＳ１３９以降の処理を実行する。
以上が、本実施例２において、ユーザ端末３００がセッション管理装置１００を介して、サービス提供サーバ３５０との間の暗号通信を終了する場合の動作シーケンスである。なお、このシーケンスについては実施例１と同様、サービス提供サーバ３５０からセッション管理装置１００を介してユーザ端末３００に通信終了要求２４００を送信することにより暗号通信を終了することも可能である。
次に、ユーザ端末３００とサービス提供サーバ３５０との間で暗号パケットを送信または受信する場合の一連の動作シーケンスを、図２１を用いて説明する。なお、図２１に示す例では、暗号パケットがユーザ端末３００からサービス提供サーバ３５０へ送信される場合を例に説明されている。また、ユーザ端末３００とサービス提供サーバ３５０との間の暗号通信において、送信または受信される暗号パケットは、必ずモニタリング機能付ルーティング装置４００を経由する。
ステップＳ１４８において、パケットモニタ装置５００のパケット受信機能５０２がモニタリング機能付ルーティング装置４００から暗号パケットを受信すると、パケット収集制御機能５０５は、受信した暗号パケットが監査対象であるか否かを判定する（ステップＳ２３２）。
受信した暗号パケットのヘッダに記載されている送信元のIPアドレスおよび宛先のIPアドレスの組が、パケットDB５０１のどの行にも記載されていない場合、または、当該組が記載されているものの、「状態」の欄に「パケット収集済」が記載されている場合、パケット収集制御機能５０５は、暗号パケットが監査対象ではないと判定し（Ｓ２３２：Ｎｏ）、受信した暗号パケットを破棄する（ステップＳ２３３）。
一方、パケット収集制御機能５０５は、暗号パケットが監査対象であると判定した場合（Ｓ２３２：Ｙｅｓ）、パケット収集制御機能５０５は、パケットDB５０１の「監査のタイミング」の欄を参照して、受信した暗号パケットに対して実施する監査がリアルタイム監査であるか否かを判定する（ステップＳ２３４）。
「監査のタイミング」の欄に「後で」と記載されている場合（Ｓ２３４：Ｎｏ）、パケット管理機能５０３は、受信した暗号パケットをパケットDB５０１に保存する（Ｓ１４９）。一方、「監査のタイミング」の欄に「リアルタイム」と記載されている場合（Ｓ２３４：Ｙｅｓ）、パケット収集制御機能５０５は、受信した暗号パケットを複製し（ステップＳ２３５）、複製した暗号パケットを監査装置６００へ送信し（ステップＳ２３６）、ステップＳ１４９に示した処理を実行する。
監査装置６００のパケット取得・復号機能６０３は、パケットモニタ装置５００から暗号パケットを受信すると（ステップＳ２３７）、暗号パケットのヘッダ領域（図１５(e)参照）に記載されている送信元装置のIPアドレスおよび宛先装置のIPアドレスを参照し、当該IPアドレスの組と一致する監査要件定義５０００および鍵情報３０００を監査装置６００のメモリ１２から取り出す。そして、パケット取得・復号機能６０３は、取り出した鍵情報３０００を用いて暗号パケットを復号し（ステップＳ２３８）、監査者は復号されたパケットを基に、ユーザ端末３００とサービス提供サーバ３５０との通信の通信内容を監査する。
以上が、本実施例２において、暗号通信開始後に、ユーザ端末３００とサービス提供サーバ３５０との間で暗号パケットを送信または受信する場合の動作シーケンスである。なお、このシーケンスについては実施例１と同様、サービス提供サーバ３５０がユーザ端末３００に対して暗号パケットを送信することも可能である。
なお、上記した実施例１および実施例２において、ユーザ端末３００とセッション管理装置１００との間の通信、および、サービス提供サーバ３５０とセッション管理装置１００との間の通信に関しては、ユーザ端末３００およびサービス提供サーバ３５０の公開鍵あるいは当該公開鍵が記載された公開鍵証明書をセッション管理装置１００内に保存し、セッション管理装置１００の公開鍵あるいは当該公開鍵が記載された公開鍵証明書をユーザ端末３００およびサービス提供サーバ３５０内に保存し、これらの公開鍵を用いて、各SIPメッセージを通信相手の公開鍵で暗号化して送信したり、各SIPメッセージの受信後に自装置の秘密鍵で復号したりしてもよい。これにより、鍵情報３０００の漏洩の危険性を減少させることができる。
また、通信内容監査支援システムに、複数の装置を設け、それぞれの装置に、通信状態管理DB１０１、鍵管理DB２０１、およびパケットDB５０１をそれぞれ分割してそれぞれ格納することにより、セッション情報に関するデータ、鍵、鍵ID、および暗号アルゴリズム名に関するデータ、ならびに、暗号パケットを分散管理するようにしてもよい。これにより、１台のデータベースが故障することにより全てのデータが消失してしなうような危険性を回避することができる。
また、複数の装置のそれぞれに鍵管理DB２０１内のデータを分割して格納する場合、鍵を秘密分散により複数の情報に分割するようにしてもよい。これにより、鍵の漏洩の危険性をさらに減少させることができる。
また、本実施例２の通信内容監査支援システムは、複数のパケットモニタ装置５００およびモニタリング機能付ルーティング装置４００を有していてもよい。この場合、監査装置６００内には、それぞれのモニタリング機能付ルーティング装置４００に接続されているパケットモニタ装置５００のアドレスを示す情報が記載されたテーブルが格納される。パケットモニタ装置５００のアドレスを示す情報としては、例えばサブネットマスクおよびIPアドレス等である。監査装置６００は、当該テーブルを参照して、該当する全てのパケットモニタ装置５００に指示を出す。
具体的には、図１９のステップＳ２１５において、監査装置６００のパケット収集指示機能６０６は、パケットモニタ装置５００のアドレスを示す情報が記載されたテーブルを参照して、どのパケットモニタ装置５００へパケット収集を指示するかを判定する。判定の際、パケット収集指示機能６０６は、監査装置６００のメモリ１２に保存されている監査要件定義５０００に記載されている送信元のIPアドレスおよび宛先のIPアドレスを基に、どちらかの通信装置と同じネットワークに存在するパケットモニタ装置５００を調べる。
例えば、図２２(h)に示しているように、暗号通信を行うユーザ端末３００のIPアドレスとサービス提供サーバ３５０のIPアドレスとがそれぞれ192.168.10.1と192.168.20.1であるので、例えばIPアドレスが192.168.20.10であり、サブネットマスクが255.255.255.0であるパケットモニタ装置５００は、サービス提供サーバ３５０と同じネットワークに属する。このような判定方法により、監査装置６００は、IPアドレスが192.168.20.10であり、サブネットマスクが255.255.255.0であるパケットモニタ装置５００へパケット収集開始要求４６００を送信する。
また、実施例２では、実施例１と同様に、鍵管理装置２００でなく、ユーザ端末３００およびサービス提供サーバ３５０が鍵情報を生成するようにしてもよい。この場合の動作シーケンスは、鍵管理装置２００が生成した鍵情報３０００の代わりに、ユーザ端末３００が生成した鍵情報３０００と鍵IDの組、および、サービス提供サーバ３５０が生成した鍵情報３０００と鍵IDの組が用いられる。それ以外は実施例１で補足説明した動作シーケンスと同一である。
上記において、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
実施例１の通信内容監査支援システムが備える各装置の機能構成を例示する図。 セッション管理装置１００、鍵管理装置２００、ユーザ端末３００、サービス提供サーバ３５０、パケットモニタ装置５００、または監査装置６００の機能を実現する情報処理装置の構成を例示する図。 実施例１の通信内容監査支援システムにおける暗号通信開始・鍵更新処理の動作を例示するシーケンス図。 実施例１の通信内容監査支援システムにおける暗号通信開始・鍵更新処理の動作を例示するシーケンス図。 実施例１の通信内容監査支援システムにおける暗号通信開始・鍵更新処理の動作を例示するシーケンス図。 実施例１の通信内容監査支援システムにおける暗号通信終了の動作を例示するシーケンス図。 実施例１の通信内容監査支援システムにおける暗号パケットモニタリングの動作を例示するシーケンス図。 実施例１の通信内容監査支援システムにおける暗号通信の監査処理を例示するシーケンス図。 実施例１の通信内容監査支援システムにおける暗号通信の監査処理を例示するシーケンス図。 通信開始要求２０００、通信開始応答２１００、通信終了要求２４００、および通信終了応答２５００のデータ構造を例示する図。 通信状態管理ＤＢ１０１に格納されるデータの構造を例示する図。 鍵生成要求２２００、鍵生成応答２３００、鍵情報３０００、鍵削除要求２６００、および鍵削除応答２７００のデータ構造を例示する図。 鍵管理ＤＢ２０１に格納されるデータの構造を例示する図。 セッション情報一覧取得要求２８００、セッション情報一覧取得応答２９００、セッション情報３１００、鍵取得要求３２００、および鍵取得応答３３００のデータ構造を例示する図。 実施例１においてパケットＤＢ５０１に格納されるデータ、パケット取得要求３６００、パケット取得応答３７００、パケット送信終了通知３８００、および暗号パケットのデータ構造を例示する図。 監査アプリケーション６０４が表示するセッション情報検索画面３４００およびセッション情報検索結果画面３５００を例示する図。 実施例２の通信内容監査支援システムが備える各装置の機能構成を例示する図。 実施例２の通信内容監査支援システムにおける暗号通信開始の動作を例示するシーケンス図。 実施例２の通信内容監査支援システムにおける暗号通信開始の動作を例示するシーケンス図。 実施例２の通信内容監査支援システムにおける暗号通信終了の動作を例示するシーケンス図。 実施例２の通信内容監査支援システムにおける暗号パケットのモニタリングおよびリアルタイム監査の処理を例示するシーケンス図。 監査アプリケーション６０４が表示する監査条件入力画面３９００の構成、ならびに、監査条件登録要求４０００、監査条件登録応答４１００、暗号通信開始通知４２００、暗号通信開始確認応答４３００、暗号通信終了通知４４００、４５００、および監査要件定義５０００のデータ構造を例示する図。 監査条件テーブル１０２に格納されるデータ、実施例２においてパケットＤＢ５０１に格納されるデータ、パケット収集開始要求４６００、パケット収集開始応答４７００、パケット収集終了要求４８００、およびパケット収集終了応答４９００のデータ構造を例示する図。
符号の説明
０・・・ネットワーク、１００・・・セッション管理装置、２００・・・鍵管理装置、３００・・・ユーザ端末、３５０・・・サービス提供サーバ、４００・・・モニタリング機能付ルーティング装置、５００・・・パケットモニタ装置、６００・・・監査装置、２０００・・・通信開始要求、２１００・・・通信開始応答、２２００・・・鍵生成要求、２３００・・・鍵生成応答、２４００・・・通信終了要求、２５００・・・通信終了応答、２６００・・・鍵削除要求、２７００・・・鍵削除応答、２８００・・・セッション情報一覧取得要求、２９００・・・セッション情報一覧取得応答、３０００・・・鍵情報、３１００・・・セッション情報、３２００・・・鍵取得要求、３３００・・・鍵取得応答、３４００・・・セッション情報検索画面、３５００・・・セッション情報検索結果画面、３６００・・・パケット取得要求、３７００・・・パケット取得応答、３８００・・・パケット送信終了通知、３９００・・・監査条件入力画面、４０００・・・監査条件登録要求、４１００・・・監査条件登録応答、４２００・・・暗号通信開始通知、４３００・・・暗号通信開始確認応答、４４００・・・暗号通信終了通知、４５００・・・暗号通信終了確認応答、４６００・・・パケット収集開始要求、４７００・・・パケット収集開始応答、４８００・・・パケット収集終了要求、４９００・・・パケット収集終了応答、５０００・・・監査要件定義

Claims (10)

  1. 複数の通信装置間で行われる暗号通信の監査に必要な情報を提供する通信内容監査支援システムであって、
    暗号通信に用いられる鍵情報が生成される都度、生成された鍵情報を、当該鍵情報を識別する鍵ＩＤに対応付けて鍵管理ＤＢ（データベース）に格納する鍵管理手段と、
    暗号通信が確立する都度、当該暗号通信を行う複数の通信装置のそれぞれのＩＰアドレスを、当該暗号通信に用いられる鍵情報の鍵ＩＤに対応付けて通信状態管理ＤＢに格納する通信管理手段と、
    暗号通信において送信された暗号パケットの複製を取得し、取得した暗号パケットの複製を、当該暗号パケットの送信元のＩＰアドレスおよび宛先のＩＰアドレスに対応付けてパケットＤＢに格納するパケット取得手段と、
    ユーザからの検索指示に基づいて前記通信状態管理ＤＢを参照し、当該検索指示で特定される暗号通信を行っていた通信装置のＩＰアドレスに対応する鍵ＩＤを特定し、特定した鍵ＩＤに対応する鍵情報を前記鍵管理ＤＢから抽出すると共に、当該検索指示で特定される暗号パケットの複製を前記パケットＤＢから抽出し、抽出した鍵情報および暗号パケットの複製を出力する通信情報出力手段と
    を備えることを特徴とする通信内容監査支援システム。
  2. 請求項１に記載の通信内容監査支援システムであって、
    前記通信管理手段は、
    暗号通信が行われていた時間帯を示す情報を、当該暗号通信に用いられる鍵情報の鍵ＩＤに対応付けて通信状態管理ＤＢにさらに格納し、
    前記格納するパケット取得手段は、
    暗号パケットの複製を取得した時刻を、当該暗号パケットの送信元のＩＰアドレスおよび宛先のＩＰアドレスに対応付けてパケットＤＢにさらに格納し、
    前記検索指示には、暗号パケットの送信元のＩＰアドレスもしくは宛先のＩＰアドレス、暗号パケットの複製の取得時間帯、または、それらの組み合わせが含まれることを特徴とする通信内容監査支援システム。
  3. 請求項１または２に記載の通信内容監査支援システムであって、
    監査対象の暗号通信を特定するために予め設定された監査条件を格納する監査条件格納手段をさらに備え、
    前記パケット取得手段は、
    取得した暗号パケットの複製が、前記監査条件に該当する場合に、当該暗号パケットの複製を前記パケットＤＢに格納し、
    取得した暗号パケットの複製が、前記監査条件に該当しない場合に、当該暗号パケットを破棄することを特徴とする通信内容監査支援システム。
  4. 請求項３に記載の通信内容監査支援システムであって、
    前記監査条件に監査を即座に実行する旨が含まれており、かつ、当該監査条件に該当する暗号通信が確立した場合に、当該暗号通信に用いられる鍵情報を前記鍵管理ＤＢから取得して前記通信情報出力手段へ送信する鍵情報通知手段をさらに備え、
    前記パケット取得手段は、
    前記監査条件に監査を即座に実行する旨が含まれている場合に、当該監査条件に該当する暗号パケットの複製を前記通信情報出力手段へさらに送信し、
    前記通信情報出力手段は、
    前記鍵情報通知手段から通知された鍵情報および前記パケット取得手段から受信した暗号パケットの複製を出力することを特徴とする通信内容監査支援システム。
  5. 請求項３または４に記載の通信内容監査支援システムであって、
    前記監査条件には、暗号パケットの送信元のＩＰアドレス、暗号パケットの宛先のＩＰアドレス、暗号パケットの複製の取得時間帯、または、これらの組み合わせが含まれることを特徴とする通信内容監査支援システム。
  6. 複数の通信装置間で行われる暗号通信の監査に必要な情報を提供する通信内容監査支援システムであって、
    暗号通信に用いられる鍵情報が生成される都度、生成された鍵情報を、当該鍵情報を識別する鍵ＩＤに対応付けて鍵管理ＤＢ（データベース）に格納する鍵管理手段と、
    暗号通信が確立した場合に、当該暗号通信を行う複数の通信装置のそれぞれに固有の情報である固有情報、当該複数の通信装置のそれぞれのＩＰアドレス、および、当該暗号通信の開始時刻を、当該暗号通信に用いられる鍵情報の鍵ＩＤに対応付けて通信状態管理ＤＢに格納し、
    当該暗号通信が終了した場合に、当該鍵情報を用いた暗号通信の終了時刻を当該鍵情報の鍵ＩＤに対応付けて前記通信状態管理ＤＢに格納する通信管理手段と、
    暗号通信において送信された暗号パケットの複製を取得し、取得した暗号パケットの複製を、当該暗号パケットの送信元のＩＰアドレスおよび宛先のＩＰアドレス、ならびに、当該暗号パケットの複製の取得時刻に対応付けてパケットＤＢに格納するパケット取得手段と、
    ユーザからの検索指示に基づいて前記通信状態管理ＤＢを参照し、当該検索指示で特定される暗号通信を行っていた通信装置の固有情報、ＩＰアドレス、暗号通信の開始時刻、および終了時刻に対応する鍵ＩＤを特定し、特定した鍵ＩＤに対応する鍵情報を前記鍵管理ＤＢから抽出すると共に、当該検索指示で特定される暗号パケットの複製を前記パケットＤＢから抽出し、抽出した鍵情報および暗号パケットの複製を出力する通信情報出力手段と
    を備えることを特徴とする通信内容監査支援システム。
  7. 請求項６に記載の通信内容監査支援システムであって、
    前記検索指示には、暗号パケットの送信元もしくは宛先の固有情報もしくはＩＰアドレス、暗号パケットの複製の取得時間帯、または、それらの組み合わせが含まれることを特徴とする通信内容監査支援システム。
  8. 請求項６または７に記載の通信内容監査支援システムであって、
    監査対象の暗号通信を特定するために予め設定された監査条件を格納する監査条件格納手段をさらに備え、
    前記パケット取得手段は、
    取得した暗号パケットの複製が、前記監査条件に該当する場合に、当該暗号パケットの複製を前記パケットＤＢに格納し、
    取得した暗号パケットの複製が、前記監査条件に該当しない場合に、当該暗号パケットを破棄することを特徴とする通信内容監査支援システム。
  9. 請求項８に記載の通信内容監査支援システムであって、
    前記監査条件に監査を即座に実行する旨が含まれており、かつ、当該監査条件に該当する暗号通信が確立した場合に、当該暗号通信に用いられる鍵情報を前記鍵管理ＤＢから取得して前記通信情報出力手段へ送信する鍵情報通知手段をさらに備え、
    前記パケット取得手段は、
    前記監査条件に監査を即座に実行する旨が含まれている場合に、当該監査条件に該当する暗号パケットの複製を前記通信情報出力手段へさらに送信し、
    前記通信情報出力手段は、
    前記鍵情報通知手段から通知された鍵情報および前記パケット取得手段から受信した暗号パケットの複製を出力することを特徴とする通信内容監査支援システム。
  10. 請求項３または４に記載の通信内容監査支援システムであって、
    前記監査条件には、暗号パケットの送信元もしくは宛先の固有情報もしくはＩＰアドレス、暗号パケットの複製の取得時間帯、または、それらの組み合わせが含まれることを特徴とする通信内容監査支援システム。
JP2007053708A 2007-03-05 2007-03-05 通信内容監査支援システム Pending JP2008219454A (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2007053708A JP2008219454A (ja) 2007-03-05 2007-03-05 通信内容監査支援システム
CN2007101694895A CN101262331B (zh) 2007-03-05 2007-11-16 通信内容检查支援系统
US11/984,676 US20080219445A1 (en) 2007-03-05 2007-11-20 Communications audit support system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007053708A JP2008219454A (ja) 2007-03-05 2007-03-05 通信内容監査支援システム

Publications (1)

Publication Number Publication Date
JP2008219454A true JP2008219454A (ja) 2008-09-18

Family

ID=39741628

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007053708A Pending JP2008219454A (ja) 2007-03-05 2007-03-05 通信内容監査支援システム

Country Status (3)

Country Link
US (1) US20080219445A1 (ja)
JP (1) JP2008219454A (ja)
CN (1) CN101262331B (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010157998A (ja) * 2008-12-03 2010-07-15 Intel Corp トラフィック可視性を備えたエンドツーエンド・ネットワークのセキュリティのための効率的な鍵の導出
JP2011030083A (ja) * 2009-07-28 2011-02-10 Nippon Telegr & Teleph Corp <Ntt> Ｉｐパケット解析装置
WO2014010183A1 (ja) * 2012-07-13 2014-01-16 パナソニック株式会社 ゲートウェイ装置、ネットワークシステム及び通信方法
US9176838B2 (en) 2012-10-19 2015-11-03 Intel Corporation Encrypted data inspection in a network environment
JP2017531967A (ja) * 2014-10-21 2017-10-26 ゼットティーイー コーポレーションＺｔｅ Ｃｏｒｐｏｒａｔｉｏｎ 情報暗号化・復号化、暗号化キー管理の方法、端末及びネットワークサーバー

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004341768A (ja) * 2003-05-15 2004-12-02 Fujitsu Ltd 磁気ディスク装置、暗号処理方法及びプログラム
US10354255B2 (en) * 2008-01-09 2019-07-16 Microsoft Technology Licensing, Llc Client access license tracking mechanism
JP5169362B2 (ja) * 2008-03-24 2013-03-27 富士通株式会社 セッション情報複製方法、前記方法を実行する呼制御サーバ及び前記方法のプログラム
JP5072715B2 (ja) * 2008-05-28 2012-11-14 株式会社リコー 履歴情報記録装置、履歴情報記録方法、プログラム、及び履歴情報記録システム
US8214442B2 (en) * 2008-08-05 2012-07-03 International Business Machines Corporation Facilitating an extended IM session in a secure way
US20110028209A1 (en) * 2009-07-30 2011-02-03 Microsoft Corporation Controlling content access
EP2542978A4 (en) * 2010-03-04 2015-08-05 METHOD AND DEVICE FOR INTEGRATING APPLICATIONS AND CORRESPONDING COMMUNICATION PROCEDURES
US8577974B2 (en) * 2010-07-07 2013-11-05 Oracle International Corporation Conference server simplifying management of subsequent meetings for participants of a meeting in progress
US8526606B2 (en) * 2010-12-20 2013-09-03 GM Global Technology Operations LLC On-demand secure key generation in a vehicle-to-vehicle communication network
US9577824B2 (en) * 2011-09-23 2017-02-21 CSC Holdings, LLC Delivering a content item from a server to a device
FR2990817B1 (fr) * 2012-05-15 2014-06-06 Cassidian Sas Procede de distribution d’une clef numerique de chiffrement vers des terminaux de telecommunication
US9043593B2 (en) * 2013-03-11 2015-05-26 International Business Machines Corporation Session attribute propagation through secure database server tiers
CN103634789A (zh) * 2013-12-17 2014-03-12 北京网秦天下科技有限公司 移动终端和方法
US10523619B2 (en) * 2013-12-20 2019-12-31 Rovio Entertainment Ltd. Stateless message routing
US9189641B2 (en) * 2014-02-06 2015-11-17 Google Inc. Methods and systems for deleting requested information
CN104009837B (zh) * 2014-04-28 2017-12-12 小米科技有限责任公司 密钥更新方法、装置及终端
US10673629B2 (en) * 2015-04-30 2020-06-02 Nippon Telegraph And Telephone Corporation Data transmission and reception method and system
KR102507113B1 (ko) * 2015-07-06 2023-03-07 삼성전자주식회사 암호화된 통신 세션의 모니터링 방법, 장치 및 시스템
US10855465B2 (en) * 2016-11-10 2020-12-01 Ernest Brickell Audited use of a cryptographic key
US11398906B2 (en) * 2016-11-10 2022-07-26 Brickell Cryptology Llc Confirming receipt of audit records for audited use of a cryptographic key
US11405201B2 (en) * 2016-11-10 2022-08-02 Brickell Cryptology Llc Secure transfer of protected application storage keys with change of trusted computing base
CN108270566A (zh) * 2016-12-30 2018-07-10 航天信息股份有限公司 一种用于时间戳服务器的数据库表构建方法
US10652245B2 (en) 2017-05-04 2020-05-12 Ernest Brickell External accessibility for network devices
US10979404B2 (en) * 2018-03-29 2021-04-13 Paypal, Inc. Systems and methods for inspecting communication within an encrypted session
CN110535748B (zh) * 2019-09-09 2021-03-26 北京科东电力控制系统有限责任公司 一种vpn隧道模式优化方法及系统
CN113420007B (zh) * 2021-03-31 2023-09-26 阿里巴巴新加坡控股有限公司 数据库访问的审计处理方法、装置及电子设备
CN114338141A (zh) * 2021-12-27 2022-04-12 中国电信股份有限公司 通信密钥处理方法、装置、非易失性存储介质及处理器

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5535276A (en) * 1994-11-09 1996-07-09 Bell Atlantic Network Services, Inc. Yaksha, an improved system and method for securing communications using split private key asymmetric cryptography
US5557346A (en) * 1994-08-11 1996-09-17 Trusted Information Systems, Inc. System and method for key escrow encryption
US5960086A (en) * 1995-11-02 1999-09-28 Tri-Strata Security, Inc. Unified end-to-end security methods and systems for operating on insecure networks
US5956404A (en) * 1996-09-30 1999-09-21 Schneier; Bruce Digital signature with auditing bits
US6483920B2 (en) * 1996-12-04 2002-11-19 Bull, S.A. Key recovery process used for strong encryption of messages
US5903652A (en) * 1996-11-25 1999-05-11 Microsoft Corporation System and apparatus for monitoring secure information in a computer network
US6286098B1 (en) * 1998-08-28 2001-09-04 Sap Aktiengesellschaft System and method for encrypting audit information in network applications
JP3755394B2 (ja) * 2000-09-29 2006-03-15 日本電気株式会社 電子商取引監査システム、電子商取引監査方法及び電子商取引監査プログラムを記録した記録媒体
US6826600B1 (en) * 2000-11-02 2004-11-30 Cisco Technology, Inc. Methods and apparatus for managing objects in a client-server computing system environment
CA2327196C (en) * 2000-11-30 2005-01-18 Ibm Canada Limited-Ibm Canada Limitee System and method for detecting dirty data fields
JP3917507B2 (ja) * 2002-01-28 2007-05-23 株式会社東芝 コンテンツ提供側システム、ユーザ側システム、追跡システム、コンテンツ提供方法、暗号化コンテンツ復号方法、不正ユーザ特定方法、暗号化装置、復号装置及びプログラム
US7930757B2 (en) * 2003-10-31 2011-04-19 Adobe Systems Incorporated Offline access in a document control system
US7373509B2 (en) * 2003-12-31 2008-05-13 Intel Corporation Multi-authentication for a computing device connecting to a network
JP3761557B2 (ja) * 2004-04-08 2006-03-29 株式会社日立製作所 暗号化通信のための鍵配付方法及びシステム
CN1860725A (zh) * 2004-07-20 2006-11-08 株式会社理光 检查装置、通信系统、检查方法、计算机可执行程序产品和计算机可读记录介质
JP2006279636A (ja) * 2005-03-30 2006-10-12 Hitachi Ltd クライアント間通信ログの整合性保証管理システム
AU2006278422B2 (en) * 2005-08-03 2011-10-06 Intercomputer Corporation System and method for user identification and authentication

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010157998A (ja) * 2008-12-03 2010-07-15 Intel Corp トラフィック可視性を備えたエンドツーエンド・ネットワークのセキュリティのための効率的な鍵の導出
US8467527B2 (en) 2008-12-03 2013-06-18 Intel Corporation Efficient key derivation for end-to-end network security with traffic visibility
US8903084B2 (en) 2008-12-03 2014-12-02 Intel Corporation Efficient key derivation for end-to-end network security with traffic visibility
JP2011030083A (ja) * 2009-07-28 2011-02-10 Nippon Telegr & Teleph Corp <Ntt> Ｉｐパケット解析装置
WO2014010183A1 (ja) * 2012-07-13 2014-01-16 パナソニック株式会社 ゲートウェイ装置、ネットワークシステム及び通信方法
JP2014022808A (ja) * 2012-07-13 2014-02-03 Panasonic Corp ゲートウェイ装置、ネットワークシステム及び通信方法
US9176838B2 (en) 2012-10-19 2015-11-03 Intel Corporation Encrypted data inspection in a network environment
US9893897B2 (en) 2012-10-19 2018-02-13 Intel Corporation Encrypted data inspection in a network environment
JP2017531967A (ja) * 2014-10-21 2017-10-26 ゼットティーイー コーポレーションＺｔｅ Ｃｏｒｐｏｒａｔｉｏｎ 情報暗号化・復号化、暗号化キー管理の方法、端末及びネットワークサーバー

Also Published As

Publication number Publication date
CN101262331B (zh) 2011-06-08
US20080219445A1 (en) 2008-09-11
CN101262331A (zh) 2008-09-10

Similar Documents

Publication Publication Date Title
JP2008219454A (ja) 通信内容監査支援システム
US8218769B2 (en) Encrypted communication system, communication status management server, encrypted communication method, and communication status management method
US8769291B2 (en) Certificate generation for a network appliance
KR101038124B1 (ko) 데이터 전송 제어 방법, 콘텐트 전송 제어 방법, 콘텐트처리 정보 획득 방법 및 콘텐트 전송 시스템
JP4561671B2 (ja) データ通信方法およびシステム
US8548916B2 (en) Managing passwords used when detecting information on configuration items disposed on a network
US20080256224A1 (en) Data communication system and session management server
JP2009534938A (ja) ピアツーピアバディ要求及び応答
US8656490B1 (en) Safe and secure access to dynamic domain name systems
WO2016061819A1 (zh) 一种访问资源的方法及装置
WO2007110598A1 (en) Electronic data communication system
US10193907B2 (en) Intrusion detection to prevent impersonation attacks in computer networks
JP2005072636A (ja) 通信システム、同通信システムにおけるセキュリティポリシーの配布方法、サーバ装置、ならびにセキュリティポリシーの配布プログラム
JP4830503B2 (ja) 個人情報を保護した通信セッション確立仲介システムおよび方法
CN110213232B (zh) 一种指纹特征和密钥双重验证方法和装置
US20190306110A1 (en) Experience differentiation
US20160105407A1 (en) Information processing apparatus, terminal, information processing system, and information processing method
JP2006019824A (ja) セキュア通信システム、管理装置および通信端末
US20200358751A1 (en) Creating a credential dynamically for a key management protocol
JP4704251B2 (ja) ネットワーク機器
JP4994683B2 (ja) ネットワーク機器
Nainar et al. Capturing Secured Application Traffic for Analysis
US20060235830A1 (en) Web content administration information discovery
JP2006319909A (ja) データ通信の方法、ピアツーピア型のネットワーク、および情報処理装置
JP2006202121A (ja) 耐障害性サービス提供システム、サーバ装置およびクライアント装置