通信内容監査支援システム
【課題】任意の暗号通信の通信内容を、任意の時点で監査することができる通信内容監査支援システムを提供する。
【解決手段】本発明の通信内容監査支援システムは、暗号通信に用いられる鍵情報3000が生成される都度、当該鍵情報3000を鍵IDに対応付けて鍵管理DB201に保存し、当該鍵情報3000を用いる暗号通信を行うユーザ端末300およびサービス提供サーバ350のIPアドレスを、当該鍵IDに対応付けて通信状態管理DB101に保存し、暗号通信で送信される暗号パケットを、当該暗号パケットの送信元のIPアドレスおよび宛先のIPアドレスに対応付けてパケットDB501に保存する。
【解決手段】本発明の通信内容監査支援システムは、暗号通信に用いられる鍵情報3000が生成される都度、当該鍵情報3000を鍵IDに対応付けて鍵管理DB201に保存し、当該鍵情報3000を用いる暗号通信を行うユーザ端末300およびサービス提供サーバ350のIPアドレスを、当該鍵IDに対応付けて通信状態管理DB101に保存し、暗号通信で送信される暗号パケットを、当該暗号パケットの送信元のIPアドレスおよび宛先のIPアドレスに対応付けてパケットDB501に保存する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、暗号化された通信内容を復号して監査するための技術に関する。
【背景技術】
【0002】
外部の監査機関等が、ネットワーク上で送信されている通信データを収集し、収集した通信データを解析することにより、事件の捜査等の目的で通信内容を監査する場合がある。しかし、通信内容が暗号化されている場合、暗号化された通信データを収集しても、監査機関は、通信内容を把握することができない。
【0003】
これを回避するために、ユーザが暗号通信を行う場合に、当該暗号通信に用いられる鍵を第三者機関に預け、監査機関による通信内容の監査の必要性が生じた場合に、当該監査機関が、監査対象の暗号通信に用いられる鍵を当該第三者機関から取得して、対応する暗号通信の内容を監査するキーエスクローと呼ばれる技術がある(例えば、特許文献1参照)。
【0004】
【特許文献1】米国特許第5535276号明細書
【発明の開示】
【発明が解決しようとする課題】
【0005】
上記の特許文献1に開示されている技術は、監査機関による通信内容の監査の必要性が生じた場合に、当該監査機関が、当該第三者機関から鍵を取得して、対応するユーザの通信内容を監査するため、鍵を取得した後も継続している暗号通信については、通信内容の監査を行うことができるものの、鍵を取得する前に行われていた暗号通信については、通信内容の監査を行うことができない。
【0006】
監査の有無によらず、全ての暗号通信を収集して保存しておくことも考えられるが、暗号通信に用いられる鍵は、生成されてからの時間の経過に応じて暗号強度が低下するため、所定のタイミングで更新される場合が多い。そのため、監査機関による通信内容の監査の必要性が生じた時点の鍵を取得しても、その鍵とは異なる鍵を用いて行われた過去の暗号通信の内容を監査することはできない。
【0007】
本発明は上記事情を鑑みてなされたものであり、本発明の目的は、任意の暗号通信の通信内容を、任意の時点で監査できるようにすることにある。
【課題を解決するための手段】
【0008】
上記課題を解決するために、本発明の通信内容監査支援システムは、暗号通信に用いられる鍵情報が生成される都度、当該鍵情報を鍵IDに対応付けて保存し、当該鍵情報を用いる暗号通信を行う通信装置のIPアドレスを、当該鍵IDに対応付けて保存し、暗号通信で送信される暗号パケットを、当該暗号パケットの送信元のIPアドレスおよび宛先のIPアドレスに対応付けて保存する。
【0009】
例えば、本発明の第1の態様は、複数の通信装置間で行われる暗号通信の監査に必要な情報を提供する通信内容監査支援システムであって、暗号通信に用いられる鍵情報が生成される都度、生成された鍵情報を、当該鍵情報を識別する鍵IDに対応付けて鍵管理DB(データベース)に格納する鍵管理手段と、暗号通信が確立する都度、当該暗号通信を行う複数の通信装置のそれぞれのIPアドレスを、当該暗号通信に用いられる鍵情報の鍵IDに対応付けて通信状態管理DBに格納する通信管理手段と、暗号通信において送信された暗号パケットの複製を取得し、取得した暗号パケットの複製を、当該暗号パケットの送信元のIPアドレスおよび宛先のIPアドレスに対応付けてパケットDBに格納するパケット取得手段と、ユーザからの検索指示に基づいて通信状態管理DBを参照し、当該検索指示で特定される暗号通信を行っていた通信装置のIPアドレスに対応する鍵IDを特定し、特定した鍵IDに対応する鍵情報を鍵管理DBから抽出すると共に、当該検索指示で特定される暗号パケットの複製をパケットDBから抽出し、抽出した鍵情報および暗号パケットの複製を出力する通信情報出力手段とを備えることを特徴とする通信内容監査支援システムを提供する。
【0010】
例えば、本発明の第2の態様は、複数の通信装置間で行われる暗号通信の監査に必要な情報を提供する通信内容監査支援システムであって、暗号通信に用いられる鍵情報が生成される都度、生成された鍵情報を、当該鍵情報を識別する鍵IDに対応付けて鍵管理DB(データベース)に格納する鍵管理手段と、暗号通信が確立した場合に、当該暗号通信を行う複数の通信装置のそれぞれに固有の情報である固有情報、当該複数の通信装置のそれぞれのIPアドレス、および、当該暗号通信の開始時刻を、当該暗号通信に用いられる鍵情報の鍵IDに対応付けて通信状態管理DBに格納し、当該暗号通信が終了した場合に、当該鍵情報を用いた暗号通信の終了時刻を当該鍵情報の鍵IDに対応付けて通信状態管理DBに格納する通信管理手段と、暗号通信において送信された暗号パケットの複製を取得し、取得した暗号パケットの複製を、当該暗号パケットの送信元のIPアドレスおよび宛先のIPアドレス、ならびに、当該暗号パケットの複製の取得時刻に対応付けてパケットDBに格納するパケット取得手段と、ユーザからの検索指示に基づいて通信状態管理DBを参照し、当該検索指示で特定される暗号通信を行っていた通信装置の固有情報、IPアドレス、暗号通信の開始時刻、および終了時刻に対応する鍵IDを特定し、特定した鍵IDに対応する鍵情報を鍵管理DBから抽出すると共に、当該検索指示で特定される暗号パケットの複製をパケットDBから抽出し、抽出した鍵情報および暗号パケットの複製を出力する通信情報出力手段とを備えることを特徴とする通信内容監査支援システムを提供する。
【発明の効果】
【0011】
本発明の通信内容監査支援システムによれば、任意の暗号通信の通信内容を、任意の時点で監査することができる。
【発明を実施するための最良の形態】
【0012】
以下、本発明の実施の形態を、図面を用いて詳細に説明する。
<実施例1>
本実施例1では、SIP(Session Initiation Protocol)を用いた通信システムに対して、本発明を適用した例について説明する。SIPはIETFのRFC3261に定義された、通信セッションの管理や制御を行う通信プロトコルである。なお、本発明の通信内容監査支援システムは、SIPに限らず、複数の通信装置間の通信を第三者の装置が確立させるような通信システムに対しても適用することができる。
【0013】
図1は、実施例1の通信内容監査支援システムのシステム構成図である。同図において、通信内容監査支援システムは、セッション管理装置100、鍵管理装置200、ユーザ端末300、サービス提供サーバ350、モニタリング機能付ルーティング装置400、パケットモニタ装置500、および監査装置600を備える。
【0014】
サービス提供サーバ350およびパケットモニタ装置500は、モニタリング機能付ルーティング装置400に接続される。モニタリング機能付ルーティング装置400は、インターネット等のネットワーク0に接続され、当該ネットワーク0を介して、セッション管理装置100、鍵管理装置200、ユーザ端末300、および監査装置600と通信する。
【0015】
なお、本実施例1において、ユーザ端末300やサービス提供サーバ350は、SIP-URI(Uniform Resource Identifier)と呼ばれる識別子によって一意に識別される。ユーザ端末300のSIP-URIは、ユーザ端末300の名前とセッション管理装置100の名前とを"@"で連結し、この文字列の先頭に"sip:"を付加した文字列で表現される。同様に、サービス提供サーバ350のSIP-URIは、サービス提供サーバ350の名前とセッション管理装置100の名前とを"@"で連結し、この文字列の先頭に"sip:"を付加した文字列で表現される。
【0016】
図1に示す例では、ユーザ端末300の名前が"user"であり、セッション管理装置100の名前が"domain.hitachi.co.jp"である場合、ユーザ端末300のSIP-URIは"sip:user @ domain.hitachi.co.jp "となる。同様に、サービス提供サーバ350の名前が"service"である場合、サービス提供サーバ350のSIP-URIは"sip:service@ domain.hitachi.co.jp "となる。しかしながら、SIP-URIの命名規則はこれに限定されない。例えば、ユーザ端末の名前ではなく、ユーザ端末を使用しているユーザの識別情報(ユーザ名)等を使用してもよい。
【0017】
また、本実施例1において、ユーザ端末300またはサービス提供サーバ350が自身のIPアドレスとSIP-URIをセッション管理装置100に対応付けてレジストラDBに保存させる処理を、ユーザ端末300またはサービス提供サーバ350がセッション管理装置100にログインすると定義する。
【0018】
次に、本実施例1における通信内容監査支援システムの各構成要素が備える機能について説明する。
【0019】
セッション管理装置100は、ユーザ端末300とサービス提供サーバ350との間の暗号通信を制御および管理する装置であり、通信状態管理DB(データベース)101、通信管理機能103、鍵取得機能104、メッセージ送受信機能105、およびセッション情報通知機能106を有する。鍵管理装置200は、鍵管理DB201、鍵管理機能202、および鍵送受信機能203を有する。パケットモニタ装置500は、パケットDB501、パケット受信機能502、パケット管理機能503、およびパケット送信機能504を備える。
【0020】
通信状態管理DB101は、セッション情報を登録するデータベースである。通信管理機能103は、ユーザ端末300とサービス提供サーバ350との間の暗号通信のセッション情報を通信状態管理DB101に登録したり、当該セッション情報を通信状態管理DB101から検索して取得したりする。鍵取得機能104は、ユーザ端末300とサービス提供サーバ350との間の暗号通信に使用される鍵情報を鍵管理装置200から取得したり、取得した鍵情報をメッセージ送受信機能105によって送信されるメッセージに記載したりする。メッセージ送受信機能105は、ユーザ端末300とサービス提供サーバ350との間でSIPメッセージを送信または受信する。セッション情報通知機能106は、セッション情報を監査装置600へ送信する。
【0021】
なお、本実施例1の鍵情報には、暗号通信に使用する鍵および当該鍵を一意に識別するための鍵ID、有効期間、および当該鍵を用いる暗号アルゴリズム名が含まれる。また、本実施例1のセッション情報には、暗号通信を一意に識別するためのセッションID、暗号通信に使用する鍵ID、暗号通信を行う通信装置の名前およびIPアドレス、ならびに、鍵の使用開始時刻および終了時刻が含まれる。また、本実施例において、セッションIDには、SIPメッセージに記載されたCall-IDフィールド内の文字列の"@"以前(左側)の部分が用いられる。
【0022】
鍵管理装置200は、ユーザ端末300とサービス提供サーバ350との間の暗号通信に使用する鍵の生成および管理を行う装置であり、鍵管理DB201、鍵管理機能202、および鍵送受信機能203を備える。
【0023】
鍵管理DB201は、鍵情報を登録するデータベースである。鍵管理機能202は、鍵情報を生成し、生成した鍵情報を鍵管理DB201に登録したり、鍵管理DB201内の鍵情報を検索して取得したりする。鍵送受信機能203は、鍵の取得要求または生成要求を受信し、鍵情報を要求元に送る。
【0024】
ユーザ端末300は、サービス提供サーバ350と暗号通信を行う装置であり、サービス提供サーバ350は、ユーザ端末300と暗号通信を行う装置である。ユーザ端末300およびサービス提供サーバ350は、鍵取得機能301、SIPクライアント機能302、暗号通信機能303、および状態管理機能304を備える。
【0025】
鍵取得機能301は、セッション管理装置100より受信したSIPメッセージから暗号通信に使用する鍵情報を取得し、取得した鍵情報の有効期限を監視したり、暗号通信終了後に、使用した鍵情報を削除したりする。SIPクライアント機能302は、セッション管理装置100を介して他のユーザ端末300もしくはサービス提供サーバ350と暗号通信を確立するためのSIP通信を行う。
【0026】
暗号通信機能303は、通信を確立している通信相手から暗号パケットを受信し、受信した暗号パケットの復号を行ったり、パケットを暗号化して通信を確立している通信相手へ送信したりする。状態管理機能304は、SIPクライアント機能302が管理する、自装置と通信相手の装置の内部状態を管理する。
【0027】
なお、本実施例では、ユーザ端末300内の状態管理機能304は、内部状態をユーザ端末300に接続されている画面に表示し、サービス提供サーバ350内の状態管理機能304は、内部状態をイベントログとして出力する。
【0028】
モニタリング機能付ルーティング装置400は、ユーザ端末300とサービス提供サーバ350との間で送信または受信された暗号パケットを受信し、受信した暗号パケットを複製し、受信した暗号パケットを本来の宛先へ送信すると共に、複製した暗号パケットをパケットモニタ装置500へ送信するパケット制御機能401を備える。
【0029】
パケットモニタ装置500は、パケットDB501、パケット受信機能502、パケット管理機能503、およびパケット送信機能504を備える。パケットDB501は、モニタリング機能付ルーティング装置400から受信した暗号パケットを、当該暗号パケットの送信元および宛先に対応付けて格納するデータベースである。パケット受信機能502は、モニタリング機能付ルーティング装置400から暗号パケットを受信する。
【0030】
パケット管理機能503は、パケット受信機能502が受信した暗号パケットをパケットDB501に格納したり、監査装置600から要求された暗号パケットをパケットDB501から検索して取得したりする。パケット送信機能504は、パケット管理機能503によってパケットDB501から取得された暗号パケットを監査装置600へ送る。
【0031】
監査装置600は、ユーザ端末300とサービス提供サーバ350との間の暗号通信で送信または受信された通信内容を監査する装置であり、鍵取得機能601、セッション情報取得機能602、パケット取得・復号機能603、および監査アプリケーション604を備える。
【0032】
鍵取得機能601は、ユーザ端末300とサービス提供サーバ350との間の暗号通信で使用された鍵を鍵管理装置200から取得する。セッション情報取得機能602は、セッション情報の一覧をセッション管理装置100から取得する。パケット取得・復号機能603は、暗号パケットをパケットモニタ装置500から取得し、鍵管理装置200から取得した鍵を用いて当該暗号パケットを復号する。監査アプリケーション604は、復号されたパケットを用いてユーザ端末300とサービス提供サーバ350との間の暗号通信の内容を監査する。
【0033】
なお、本実施例1が適用された通信内容監査支援システムは、ユーザ端末300とサービス提供サーバ350との間で通信を行うクライアント/サーバ通信の監査だけでなく、サービス提供サーバ350同士が通信を行う場合の監査にも適用可能である。更には、本実施例1ではサービス提供サーバ350をモニタリング機能付ルーティング装置400に接続する構成にしているが、本発明はこれに限られない。
【0034】
例えば、ユーザ端末300をモニタリング機能付ルーティング装置400に接続するように構成してもよい。その場合、図1のシステム構成においてサービス提供サーバ350をユーザ端末300に置き換えることにより、ネットワーク0に直接接続されているユーザ端末300やサービス提供サーバ350と暗号通信を行う場合にも通信内容監査支援システムを適用することができる。そして、モニタリング機能付ルーティング装置400に接続されているユーザ端末300に着目して暗号通信の通信内容の監査が行われる。
【0035】
その他、ネットワーク0は、企業内LANのようなプライベートネットワークに限らず、インターネットのようなオープンネットワークでも良い。更に、モニタリング機能付ルーティング装置400は、スイッチング機能を持たないリピータハブ、ミラーリングポート機能を有するスイッチングハブ、ルータ、ファイアウォール、プロキシサーバに代表される、通信を中継する機能を持った装置であれば、いずれでも良い。例えば、ファイアウォールをモニタリング機能付ルーティング装置400とする場合には、ファイアウォールを介して行われる組織内部と組織外部の間の通信を監査することができるようになる。
【0036】
また、通信状態管理DB101は、本実施例1のようにセッション管理装置100内に含まれる装置として構成されることが可能であるが、セッション管理装置100とは別の装置内に設け、当該装置とセッション管理装置100とをネットワークで接続するようにしてもよい。同様に、鍵管理DB201は、鍵管理装置200とは別の装置内に設けられてもよい。さらに、パケットDB501は、パケットモニタ装置500とは別の装置内に設けられてもよい。
【0037】
また、本実施例1において、セッション管理装置100、鍵管理装置200、パケットモニタ装置500、および監査装置600は、図1のように異なる装置によって実現されているが、本実施例はこれに限られない。鍵管理装置200とセッション管理装置100とを一つの装置として構成したり、監査装置600とセッション管理装置100とを一つの装置として構成したり、パケットモニタ装置500と監査装置600とを一つの装置として構成したりしてもよい。
【0038】
図2は、セッション管理装置100、鍵管理装置200、ユーザ端末300、サービス提供サーバ350、パケットモニタ装置500、または監査装置600の機能を実現する情報処理装置の構成を例示する。
【0039】
情報処理装置は、CPU(Central Processing Unit)11、メモリ12、通信処理装置13、入力装置14、出力装置15、読取装置16、および外部記憶装置17を備える。これらは、バス10を介して互いに接続されている。
【0040】
通信処理装置13は、インターネットやLANを介して他の通信装置と通信を行う。入力装置14は、例えばキーボードやマウス等である。出力装置15は、例えばモニタやプリンタ等である。読取装置16は、ICカードやUSBメモリ等の可搬性を有する記録媒体18内のデータを読み込む。外部記憶装置17は、例えばハードディスク等である。
【0041】
本実施例1における、セッション管理装置100、鍵管理装置200、ユーザ端末300、サービス提供サーバ350、パケットモニタ装置500、または監査装置600内の各機能は、これらの機能を実現するプログラムがメモリ12上にロードされ、CPU11によって実行されることにより具現化される。
【0042】
これらのプログラムは、予め上記情報処理装置の外部記憶装置17内に格納されていてもよいし、必要なときに、読取装置16または通信処理装置13によって、当該情報処理装置が利用可能な媒体を介して、他の装置から取得されて外部記憶装置17内に格納されてもよい。媒体とは、例えば、読取装置16に着脱可能な記録媒体18、または通信処理装置13に接続可能なネットワーク0または当該ネットワーク0を伝搬する搬送波やディジタル信号を指す。
【0043】
そして、プログラムは一旦外部記憶装置17内に格納された後、そこからメモリ12上にロードされてCPU11によって実行されてもよいし、あるいは外部記憶装置17内に格納されることなく、直接メモリ12上にロードされて、CPU11によって実行されてもよい。また、通信状態管理DB101、鍵管理DB201、またはパケットDB501は、メモリ12が外部記憶装置17を利用することにより実現される。
【0044】
次に、本実施例1において、SIPを用いた通信内容監査支援システムの動作について説明する。なお、ユーザ端末300およびサービス提供サーバ350がセッション管理装置100にログインする動作は、通常のSIPを用いたシステムの動作(例えばレジストレーション)と同じであるため、説明を省略している。
【0045】
ユーザ端末300およびサービス提供サーバ350がセッション管理装置100にログインすることにより、セッション管理装置100は、ユーザ端末300とサービス提供サーバ350のSIP-URIとIPアドレスとを対応付けてメモリ12に保存する。また、セッション管理装置100へのログインにより、ユーザ端末300とサービス提供サーバ350との間で暗号通信の確立が可能となり、同時に鍵管理装置200がユーザ端末300とサービス提供サーバ350との間の暗号通信に使用する鍵を管理することが可能となる。そして、監査装置600が暗号パケットおよび暗号通信に使用する鍵を取得して、パケットを復号することでユーザ端末300とサービス提供サーバ350との間の暗号通信の通信内容を監査できるようになる。
【0046】
まず、ユーザ端末300がセッション管理装置100を介して、サービス提供サーバ350と暗号通信に使用する鍵を共有し、暗号通信を開始する一連の動作シーケンスを図3から図5を用いて説明する。
【0047】
ユーザ端末300の利用者は、状態管理機能304のGUI画面を見てユーザ端末300の内部状態がログイン済状態であることを確認すると、サービス提供サーバ350との間の暗号通信処理の開始をユーザ端末300へ指示する。そして、ユーザ端末300のSIPクライアント機能302は、サービス提供サーバ350への通信開始要求2000を作成してセッション管理装置100へ送信する(ステップS101)。本実施例1において、SIPクライアント機能302は、例えば図10(a)に示すように、SIPで定義されているINVITEのリクエストメッセージを通信開始要求2000として生成する。
【0048】
セッション管理装置100のメッセージ送受信機能105は、ユーザ端末300から鍵管理装置200を受信すると(ステップS102)、鍵取得機能104は、通信開始要求2000のFromフィールドに記載されているユーザ端末300のSIP-URI、および、Toフィールドに記載されているサービス提供サーバ350のSIP-URIを記載した鍵生成要求2200を作成し、生成した鍵生成要求2200を鍵管理装置200へ送信する(ステップS103)。
【0049】
本実施例1では、鍵生成要求2200は、例えば図12(a)XMLメッセージのgenKeyRequestタグとして記述される。図12(a)は、セッション管理装置100が鍵管理装置200へ送信する鍵生成要求2200のうち、本実施例の説明に必要な部分のみを示している。送信元であるユーザ端末300のSIP-URIがfromタグに記載され、宛先であるサービス提供サーバ350のSIP-URIがtoタグに記載される。
【0050】
鍵管理装置200の鍵送受信機能203は、セッション管理装置100から鍵生成要求2200を受信すると(ステップS104)、鍵管理機能202は、鍵情報3000を生成し(ステップS105)、そのうち鍵ID、鍵、使用する暗号アルゴリズム名を鍵管理DB201に登録する(ステップS106)。
【0051】
本実施例1では、例えば図13に示すように、鍵管理DB201は、鍵ID、暗号アルゴリズム、および鍵を有する各レコードを格納する。鍵管理DB201には、監査装置600が鍵を取得するために最低限必要な情報が格納される。なお、鍵管理DB201内の暗号アルゴリズムの欄には、鍵のビット数や暗号アルゴリズムのバージョン等も格納される。
【0052】
まず、図13(a)は、ステップS106を実行する前において、鍵IDが「12345678」であり、暗号アルゴリズムがAES-256bitである鍵が登録されている様子を示している。図13(b)は、ステップS106が実行されることにより、鍵IDが「12345679」であり、暗号アルゴリズムがAES-256bitである鍵が作成され、鍵管理DB201に追加登録された様子を示している。
【0053】
図3に戻って説明を続ける。鍵送受信機能203は、鍵生成応答2300を作成し、ステップS105で生成された鍵情報3000を添付してセッション管理装置100へ送信する(ステップS107)。
【0054】
本実施例1では、鍵生成応答2300は、例えば図12(b)に示すように、XMLメッセージのgenKeyResponseタグとして記述される。図12(b)は、鍵管理装置200がセッション管理装置100へ送信する鍵生成応答2300のうち、本実施例の説明に必要な部分のみを示している。statusタグ要素には、ユーザ端末300とサービス提供サーバ350との間の暗号通信に使用する鍵ID、鍵、および使用する暗号アルゴリズム名を、鍵管理装置200が鍵管理DB201に登録した結果が記載される。
【0055】
登録成功の場合、鍵生成応答2300のstatusタグ要素には"OK"と記載され、登録失敗の場合には"NG"と記載される。また、鍵生成要求の送信元であるユーザ端末300のSIP-URIがfromタグ要素に記載され、宛先であるサービス提供サーバ350のSIP-URIがtoタグ要素に記載される。更に、生成された鍵情報3000がXML形式で記載される。
【0056】
鍵情報3000は、XML形式を用いてsessionKeyInfoタグで表現される。鍵情報3000には、例えば図12(c)に示すように、ユーザ端末300とサービス提供サーバ350との間の暗号通信に使用される鍵IDが記載されるkeyIDタグ、データの暗号化に使用されるアルゴリズム名が記載されるencタグ、鍵の有効期間が記載されるlifetimeタグ、および、鍵が記載されるkeyタグが記載される。なお、本実施例1において、lifetimeタグに記載される数値は秒を単位の時間を示す。
【0057】
セッション管理装置100の鍵取得機能104は、ステップS107において鍵管理装置200から送信された鍵生成応答2300を受信すると(図3のステップS108)、通信開始要求2000のCall-IDフィールドに記載されているセッションIDに対応付けて鍵情報3000をメモリ12に保存し、当該鍵情報3000を、図10(a)に示す通信開始要求2000のBODY部に記載する(ステップS109)。そして、メッセージ送受信機能105は、通信開始要求2000をサービス提供サーバ350へ送信する(ステップS110)。
【0058】
なお、ステップS110以降において送信または受信される通信開始要求2000は、図10(a)に示す通信開始要求2000のBODY部にXML形式で記述された鍵情報3000が記載されたものである。
【0059】
サービス提供サーバ350のSIPクライアント機能302は、セッション管理装置100から通信開始要求2000を受信すると(ステップS111)、受信した通信開始要求2000の内容を調べ、ユーザ端末300との通信可否を判定する(ステップS112)。ユーザ端末300との間の暗号通信を拒否する場合、サービス提供サーバ350のSIPクライアント機能302は、通信を拒否する旨を示すメッセージを含む通信開始応答2100を作成してセッション管理装置100へ返信する(ステップS115)。そして、状態管理機能304は、ユーザ端末300からの通信を拒否した旨をイベントログに出力する。サービス提供サーバ350の管理者は、イベントログを確認することで、ユーザ端末300との間の暗号通信を拒否したことを認識することができる。
【0060】
なお、本実施例1において、上記通信を拒否する旨を示すメッセージには、SIPで定義されているINVITEレスポンスの401 Unauthorizedメッセージが用いられる。
【0061】
一方、ステップS112において、ユーザ端末300との間の暗号通信を許可する場合、サービス提供サーバ350の鍵取得機能301は、通信開始要求2000のBODY部に記載されている鍵情報3000を取得し(ステップS113)、通信開始要求2000のCall-IDフィールドに記載されているセッションIDと対応付けてメモリ12に保存する。
【0062】
そして、SIPクライアント機能302は、通信を許可する旨を示すメッセージを含む通信開始応答2100を作成してセッション管理装置100へ返信する(ステップS114)。そして、状態管理機能304は、内部状態を暗号通信状態へ遷移させると共に、ユーザ端末300との間の暗号通信を開始した旨をイベントログに出力する。サービス提供サーバ350の管理者は、イベントログを確認することで、ユーザ端末300との間の暗号通信開始処理が正常に行われたことを認識することができる。
【0063】
なお、本実施例1では、上記通信を許可する旨を示すメッセージを含む通信開始応答2100には、例えば図10(b)に示すように、SIPで定義されているINVITEレスポンスの200 OKメッセージが用いられる。
【0064】
ステップS114またはステップS115の後に、セッション管理装置100のメッセージ送受信機能105は、サービス提供サーバ350から通信開始応答2100を受信し(ステップS116)、通信開始応答2100の内容を調べ、ユーザ端末300のサービス提供サーバ350に対する通信開始要求2000が許可されたか否かを判定する(ステップS117)。
【0065】
通信開始応答2100が通信を拒否する旨を示すメッセージを含む場合、セッション管理装置100の鍵取得機能104は、メモリ12に保存されている鍵情報3000から鍵IDを取出して、鍵削除要求2600を作成し、作成した鍵削除要求2600を鍵管理装置200へ送信する(ステップS122)。
【0066】
本実施例1では、鍵削除要求2600は、例えば図12(d)に示すように、XMLメッセージのdelKeyRequestタグとして記述される。図12(d)は、セッション管理装置100が鍵管理装置200へ送信する鍵削除要求2600のうち、本実施例の説明に必要な部分のみを示している。鍵削除要求2600には、sessionIDタグおよびkeyIDタグが記載される。sessionIDタグ内には、通信開始応答2100に記載されたCall-IDフィールド内の文字列の"@"以前(左側)の部分が記載される。また、keyIDタグ内には、鍵情報3000のkeyIDタグ内の情報がそのまま記載される。
【0067】
鍵管理装置200の鍵送受信機能203が、セッション管理装置100から鍵削除要求2600を受信すると(ステップS123)、鍵管理機能202は、鍵削除要求2600のkeyIDタグに記載されている鍵IDを鍵管理DB201から削除することにより、鍵IDを失効する(ステップS124)。その後、鍵送受信機能203は、鍵削除応答2700を作成してセッション管理装置100へ送信する(ステップS125)。
【0068】
これにより、鍵管理DB201内に格納されている情報は、例えば図13(b)から(c)のように更新される。なお、ステップS124において、鍵管理機能202は、鍵IDに加えて、対応する暗号アルゴリズムおよび鍵を鍵管理DB201から削除するようにしてもよい。
【0069】
なお、本実施例1において、鍵削除応答2700は、XMLメッセージのdelKeyResponseタグとして記述される。図12(e)は、鍵管理装置200がセッション管理装置100へ送信する鍵削除応答2700のうち、本実施例の説明に必要な部分のみが示されている。鍵削除応答2700には、sessionIDタグおよびstatusタグが記載される。鍵管理機能202によって鍵管理DB201から鍵ID、鍵、暗号アルゴリズム名を削除された結果が、statusタグに記載される。削除成功の場合にはstatusタグに"OK"と記載され、削除失敗の場合には"NG"と記載される。
【0070】
セッション管理装置100の鍵取得機能104は、鍵管理装置200から送信された鍵削除応答2700を受信すると(ステップS126)、メモリ12に保存していたセッションIDと鍵情報を削除し、メッセージ送受信機能105は、通信開始応答2100を作成してユーザ端末300へ送信する(ステップS127)。
【0071】
一方、図4のステップS117の後、通信開始応答2100が通信を許可する旨のメッセージを含む場合、セッション管理装置100の通信管理機能103は、通信開始応答2100のCall-IDフィールドに記載されているセッションIDをキーに、通信状態管理DB101のセッションIDレコードを検索する(ステップS118)。なお、本実例1において、通信管理機能103は、暗号通信の相手の通信装置から暗号通信を許可する旨のメッセージを受信した場合に、暗号通信が確立したものと判定する。
【0072】
本実施例1において、通信状態管理DB101は、例えば図11に示すように、鍵ID、通信の開始を要求した通信装置を示す通信装置1、通信装置1の通信相手である通信装置2、通信の開始時刻、通信の終了時刻、および暗号アルゴリズムを、セッションIDに対応付けて格納する。本実施例1において、図3のステップS118を実行する前の時点では、通信状態管理DB101内には、例えば図11の(a)に示すような情報が格納されているものと仮定する。
【0073】
通信状態管理DB101を参照することにより、例えば通信の管理者はどのような通信が行われているかを把握したり、また、決められた暗号アルゴリズムを使用して暗号通信を行っているかといった通信ポリシを一元的にチェックしたりすることができる。また、本実施例1において、通信状態管理DB101には、暗号通信を行う通信装置のIPアドレスだけでなく、暗号通信が行われた時間帯が鍵IDに対応付けられているので、IPアドレスの割り当てがDHCP(Dynamic Host Configuration Protocol)等により動的に変更される場合であっても、特定の時間帯におけるIPアドレスによって、通信装置を一意に特定することができる。
【0074】
ステップS116において受信した通信開始応答2100のCall-IDフィールドに記載されているセッションID(本実施例1では「f4yh79bn6o」)が通信状態管理DB101のセッションIDレコードに記載されていないので、通信管理機能103は、ユーザ端末300とサービス提供サーバ350との間の暗号通信が新規の通信であると判断する(ステップS119)。
【0075】
そして、通信管理機能103は、セッションIDを通信状態管理DB101のセッションIDレコードに書き込み、メモリ12に保存されている鍵情報3000のkeyIDタグに記載された鍵IDを鍵IDレコードに書き込み、通信開始応答2100のFromフィールドに記載されたユーザ端末300の名前をメモリ12に保存しているユーザ端末300のSIP-URIと対応付けて通信装置1レコードに書き込み、通信開始応答2100のToフィールドに記載されたサービス提供サーバ350の名前をメモリ12に保存しているサービス提供サーバ350のSIP-URIと対応付けて通信装置2レコードに書き込み、現在の時刻を開始時刻レコードに書き込み、鍵情報3000のencタグに記載された暗号アルゴリズム名を暗号アルゴリズムレコードに書き込む(ステップS121)。これにより、通信状態管理DB101に格納されている情報は、例えば図11(b)に示すようになる。
【0076】
その後、鍵取得機能104は、メモリ12に保存されている鍵情報3000を取り出し、図10(b)に示す通信開始応答2100のBODY部に記載すると、メモリ12に保存していたセッションIDと鍵情報3000を削除する。そして、メッセージ送受信機能105は、入力装置14によって作成された通信開始応答2100をユーザ端末300へ送信する(ステップS127)。
【0077】
ユーザ端末300のSIPクライアント機能302は、セッション管理装置100から通信開始応答2100を受信すると(ステップS128)、受信した通信開始応答2100の内容を確認する(ステップS129)。通信開始応答2100が通信を拒否する旨を示すメッセージを含む場合、ユーザ端末300の状態管理機能304は、GUI画面にサービス提供サーバ350への通信が拒否された旨を表示する。ユーザ端末300の利用者は、GUI画面を確認することで、サービス提供サーバ350との間の暗号通信が拒否されたことを認識することができる。
【0078】
通信開始応答2100が通信を許可する旨を示すメッセージを含む場合、ユーザ端末300の鍵取得機能301は、通信開始応答2100のBODY部に記載されている鍵情報3000を取得し(ステップS130)、通信開始応答2100のCall-IDフィールドに記載されたセッションIDと対応付けてメモリ12に保存する。そして、状態管理機能304は、内部状態を暗号通信状態へと遷移させると共に、GUI画面にサービス提供サーバ350との間の暗号通信が開始された旨を表示する。ユーザ端末300の利用者は、GUI画面を確認することで、サービス提供サーバ350との間の暗号通信開始処理が正常に行われたことを認識することができる。
【0079】
そして、ユーザ端末300とサービス提供サーバ350とは、セッション管理装置100を介することなく、取得した鍵情報3000を用いて、暗号通信を開始する。
【0080】
以上が本実施例1において、ユーザ端末300がセッション管理装置100を介して、サービス提供サーバ350と暗号通信に使用する鍵情報3000を共有し、暗号通信を開始する動作シーケンスである。
【0081】
また、ユーザ端末300とサービス提供サーバ350との間で共有された鍵の有効期限が切れ、その契機で鍵更新を行う一連の動作については、図4のステップS118の後の動作以外は、暗号通信開始の動作シーケンスと同一である。ただし、鍵更新のシーケンスでは、サービス提供サーバ350は、常に暗号通信を許可する。すなわち、通信開始応答2100には通信を許可する旨を示すメッセージが含まれるため、セッション管理装置100の通信管理機能103は、ステップS117の後に、ステップS118を実行する。
【0082】
そして、通信管理機能103は、ステップS118において、通信開始応答2100のCall-IDフィールドに対応するセッションIDが記載され、かつ、終了時刻レコードに何も記載されていない行を通信状態管理DB101から検索する。ステップS118を実行する前の時点では、通信状態管理DB101に格納されている情報は、例えば図11(b)のようになっているので、通信管理機能103は、2行目のセッションIDレコードに検索しているセッションIDが記載され、終了時刻レコードに何も記載されていない行が存在することを検知する(ステップS119)。
【0083】
そして、通信管理機能103は、通信状態管理DB101の2行目の終了時刻レコードに現在の時刻を入力し(ステップS120)、空白行になっている3行目にセッションID、更新した鍵ID、ユーザ端末300の名前、サービス提供サーバ350の名前、開始時刻(現在の時刻)、および暗号アルゴリズムの各情報を書き込む(ステップS121)。これにより、通信状態管理DB101に格納されている情報は、例えば図11(c)のようになる。
【0084】
その後、ステップS127以降の処理が実行され、ユーザ端末300およびサービス提供サーバ350は、セッション管理装置100を介することなく、取得した鍵情報3000を用いて暗号通信を継続する。
【0085】
以上が本実施例1において、ユーザ端末300とサービス提供サーバ350との間で共有された鍵の有効期限が切れ、その契機で鍵更新を行う場合の動作シーケンスである。なお、このシーケンスについては、サービス提供サーバ350からユーザ端末300に対する通信開始要求2000をセッション管理装置100へ送信することも可能である。この場合、図3においてユーザ端末300とサービス提供サーバ350の立場が入れ替わるだけで、それ以外にシーケンスの変更はない。また、鍵の有効期限が切れたことを契機とするのではなく、鍵の有効期限が近づいたことを契機としてもよい。
【0086】
次に、ユーザ端末300が、セッション管理装置100を介して、サービス提供サーバ350との間の暗号通信を終了する一連の動作シーケンスを、図6を用いて説明する。
【0087】
ユーザ端末300の利用者は、状態管理機能304のGUI画面を参照して、ユーザ端末300の内部状態が暗号通信状態であることを確認し、暗号通信を終了する場合には、サービス提供サーバ350との間の暗号通信処理の終了をユーザ端末300へ指示する。ユーザ端末300のSIPクライアント機能302は、サービス提供サーバ350への通信終了要求2400を作成し、セッション管理装置100へ送信する(ステップS131)。本実施例1では、通信終了要求2400には、例えば図10(c)に示すように、SIPで定義されているBYEリクエストメッセージが利用される。
【0088】
セッション管理装置100のメッセージ送受信機能105は、ユーザ端末300から通信終了要求2400を受信すると(ステップS132)、サービス提供サーバ350に通信終了要求2400を送信する(ステップS133)。サービス提供サーバ350のSIPクライアント機能302は、セッション管理装置100から通信終了要求2400を受信し(ステップS134)、鍵取得機能301は、通信終了要求2400のCall-IDフィールドに記載されているセッションIDおよび鍵情報3000をメモリ12から削除する(ステップS135)。
【0089】
そして、SIPクライアント機能302は、通信終了応答2500を作成して、セッション管理装置100へ返信する(ステップS136)。そして、状態管理機能304は、内部状態を通信開始前状態へ遷移させると共に、ユーザ端末300との間の暗号通信に使用した鍵情報3000を削除した旨、および、暗号通信を終了した旨をイベントログへ出力する。サービス提供サーバ350の管理者は、イベントログを確認することで、ユーザ端末300との間の暗号通信終了処理が正常に行われたことを認識する。
【0090】
なお、本実施例1において、通信終了応答2500には、例えば図10(d)に示すように、SIPで定義されているBYEレスポンスメッセージが利用される。
【0091】
セッション管理装置100のメッセージ送受信機能105がサービス提供サーバ350から通信終了応答2500を受信すると(図6のステップS137)、通信管理機能103は、通信終了応答2500のCall-IDフィールドに記載されているセッションIDが記載され、かつ、終了時刻が記載されていない行を、通信状態管理DB101から検索する。この時点では、通信状態管理DB101に格納されている情報は、例えば図11(c)のようになっているので、通信管理機能103は、図11(c)の3行目を検索対象の行として検出する。
【0092】
そして、通信管理機能103は、ユーザ端末300とサービス提供サーバ350との間の暗号通信が終了したと判断し、通信状態管理DB101の3行目の終了時刻レコードに現在の時刻を入力する(ステップS138)。これにより、通信状態管理DB101に格納されている情報は、例えば図11(d)のようになる。その後、メッセージ送受信機能105は、通信終了応答2500をユーザ端末300へ送信する(ステップS139)。
【0093】
ユーザ端末300のSIPクライアント機能302は、セッション管理装置100から通信終了応答2500を受信し(ステップS140)、鍵取得機能301は、通信終了要求2400のCall-IDフィールドに記載したセッションIDおよび鍵情報3000をメモリ12から削除する(ステップS141)。そして、状態管理機能304は、内部状態を通信開始前状態へ遷移させると共に、GUI画面にサービス提供サーバ350との間の暗号通信に使用した鍵情報3000を削除した旨、および、暗号通信を終了した旨を表示する。ユーザ端末300の利用者は、GUI画面を確認することで、サービス提供サーバ350との間の暗号通信終了処理が正常に行われたことを認識することができる。
【0094】
以上が、ユーザ端末300がセッション管理装置100を介して、サービス提供サーバ350との間の暗号通信を終了する場合の動作シーケンスである。なお、このシーケンスについては、サービス提供サーバ350からセッション管理装置100を介してユーザ端末300へ通信終了要求2400を送信することも可能である。この場合、図6において、ユーザ端末300とサービス提供サーバ350の立場が入れ替わるだけで、それ以外にシーケンスの変更はない。また、鍵の有効期限が近づいたことを契機として鍵の更新を行う場合には、鍵の有効期限が切れたことを契機として一連の動作を実行してもよい。
【0095】
次に、暗号通信開始後、ユーザ端末300とサービス提供サーバ350との間で暗号パケットを送信または受信する場合の一連の動作シーケンスを、図7を用いて説明する。なお、図7では、暗号パケットがユーザ端末300からサービス提供サーバ350へ送信される例のみ説明する。
【0096】
内部状態が暗号通信状態であるユーザ端末300は、サービス提供サーバ350へ暗号パケットを送信する(ステップS142)。モニタリング機能付ルーティング装置400のパケット制御機能401は、ユーザ端末300から送信された暗号パケットを受信し(ステップS143)、受信した暗号パケットを複製して(ステップS144)、サービス提供サーバ350とパケットモニタ装置500にそれぞれ送信する(ステップS145およびS147)。
【0097】
サービス提供サーバ350は、ステップS145において、モニタリング機能付ルーティング装置400から送信された暗号パケットを受信し(ステップS146)、メモリ12に保存していた鍵情報3000を用いて暗号パケットを復号する。
【0098】
パケットモニタ装置500は、ステップS147においてモニタリング機能付ルーティング装置400から送信された暗号パケットを受信し(ステップS148)、図15(e)に示す暗号パケットのヘッダ領域に格納された情報を調べる。そして、パケットモニタ装置500は、送信元のIPアドレスと宛先のIPアドレスを確認し、パケットDB501のパケット格納場所レコードに記載された場所へ保存する(ステップS149)。
【0099】
本実施例1では、パケットDB501は、暗号通信を行う送信元の通信装置のIPアドレスおよび宛先の通信装置のIPアドレスの組み合わせ毎に、当該組み合わせの通信装置同士において送信された暗号パケットの格納場所を示すテーブルを持っており、パケット管理機能503は、受信した暗号パケットのヘッダ情報に基づいて当該テーブルを参照し、当該暗号パケットを、格納すべき格納場所へ格納する。
【0100】
例えば、ユーザ端末300からサービス提供サーバ350へ送信された暗号パケットのヘッダ領域に、送信元の通信装置(ユーザ端末300)のIPアドレスとして192.168.10.1が格納され、宛先の通信装置(サービス提供サーバ350)のIPアドレスとして192.168.20.1が格納されている場合、図15(a)に示す例では、パケット管理機能503は、当該暗号パケットを、/var/audit/packet/0000120060401/で識別されるディレクトリに保存する。
【0101】
パケット管理機能503は、例えば、送信元の通信装置のIPアドレスと宛先の通信装置のIPアドレスの組み合わせを識別する文字列(例えば5桁の番号)と日付を示す文字列とを組み合わせた識別情報で識別されるディレクトリを生成し、送信元と宛先のIPアドレスの組み合わせが同一の暗号パケットが同一の日に送信された場合には、当該暗号パケットを同一のディレクトリに格納する。
【0102】
以上が、ユーザ端末300とサービス提供サーバ350との間で暗号パケットが送信または受信される場合の動作シーケンスである。なお、このシーケンスについては、サービス提供サーバ350がユーザ端末300に対して暗号パケットを送信することも可能である。この場合、図7においてユーザ端末300とサービス提供サーバ350の立場が入れ替わるだけで、それ以外にシーケンスの変更はない。また、S149において、パケットモニタ装置500は、サービス提供サーバ350がユーザ端末300へ送信した暗号パケットを受信すると、これをパケットDB501の/var/audit/packet/0000220060401/で識別されるディレクトリに保存する。
【0103】
次に、暗号通信終了後に監査装置600がパケットDB501に保存されている暗号パケットを取得し、復号を行うことによりパケットの内容を監査する一連の動作シーケンスについて、図8および図9を用いて説明する。
【0104】
監査装置600を利用する監査者は、監査したい通信のセッション情報をセッション管理装置100から取得するため、監査装置600の監査アプリケーション604が表示しているセッション情報検索画面3400(図16(a)参照)へ検索キーを入力する。監査アプリケーション604は、入力された検索キーを読み込む(S150)。
【0105】
本実施例1において、監査者は、セッション情報検索画面3400に入力する検索キーとして、暗号通信を行う送信元の通信装置の名前、宛先の通信装置の名前、および暗号パケットの送信時刻の範囲を入力し、暗号通信に用いられている暗号アルゴリズム名を指定するものとする。図16(a)に示す例では、"user"という名前の通信装置が、"service"という名前の通信装置に対して、2006年4月1日の11:00以降に送信された暗号パケットが指定されている。
【0106】
なお、通信装置の名前および通信時刻の範囲を指定する各項目は空白でも構わない。その場合、検索キーが入力されなかった項目については条件指定が無かったものと判定される。また、全ての検索キーが空白の場合、監査アプリケーション604は、過去に行われた全ての通信を監査対象としてセッション情報を検索する。
【0107】
監査装置600のセッション情報取得機能602は、セッション情報検索画面3400に入力された検索キーをメモリ12に保存する。そして、セッション情報取得機能602は、セッション情報一覧取得要求2800を作成してセッション管理装置100へ送信する(ステップS151)。
【0108】
本実施例1において、セッション情報一覧取得要求2800は、XMLメッセージのgetSessionInfoRequestタグとして記述される。図14(a)は、監査装置600からセッション管理装置100へ送信されるセッション情報一覧取得要求2800のうち、本実施例の説明に必要な部分のみを示している。セッション情報検索画面3400には、検索キーとして入力された情報が記載される。セッション情報検索画面3400の「送信元の通信装置の名前」および「宛先の通信装置の名前」の項目に入力された検索キーは、それぞれfromタグおよびtoタグに記載される。
【0109】
また、「通信時刻の範囲」の項目に入力された検索キーは、startタグとendタグに記載される。また、指定された暗号アルゴリズム名は、encタグに記載される。なお、セッション情報検索画面3400に検索キーが入力されていない項目については、対応するセッション情報一覧取得要求2800のタグに"null"が記載される。
【0110】
セッション管理装置100のセッション情報通知機能106は、監査装置600からセッション情報一覧取得要求2800を受信すると(ステップS152)、通信管理機能103は、セッション情報一覧取得要求2800のfromタグに記載されたユーザ端末300の名前、toタグに記載されたサービス提供サーバ350の名前、startタグに記載された時刻、endタグに記載された時刻、およびencタグに記載された暗号アルゴリズム名を基にして、監査対象の通信のセッション情報について通信状態管理DB101を検索する(ステップS153)。
【0111】
この時点では、通信状態管理DB101に格納されている情報は、例えば図11(d)のようになっているので、通信管理機能103は、図11(d)に示した例において、2行目と3行目に記載された各レコードの情報を取得する。そして、セッション情報通知機能106は、通信管理機能103が取得した各情報からセッション情報3100を作成する。本実施例において、セッション情報通知機能106は、鍵IDが「12345679」であるセッション情報3100と、鍵IDが「12345680」であるセッション情報3100とを記載したセッション情報一覧取得応答2900を作成し、監査装置600へ送信する(ステップS154)。
【0112】
本実施例1において、セッション情報一覧取得応答2900は、例えば、XMLメッセージのgetSessionInfoResponseタグとして記述される。図14(b)は、セッション管理装置100から監査装置600へ送信されるセッション情報一覧取得応答2900のうち、本実施例の説明に必要な部分のみを示している。セッション管理装置100によるセッション情報の検索結果がstatusタグに記載される。
【0113】
セッション情報通知機能106は、検索の結果、セッション情報一覧取得要求2800の条件に合致した通信のセッション情報が見つかった場合には、statusタグに"OK"と記載し、見つからなかった場合には"NG"と記載する。また、作成したセッション情報3100は例えばXML形式で記載される。なお、1つのセッションにおいて複数の鍵が用いられている場合には、セッション情報一覧取得応答2900には、複数のセッション情報3100が記載されてもよい。
【0114】
セッション情報3100は、例えばXML形式のsessionInfoタグとして表現される。セッション情報3100には、例えば図14(c)に示すように、通信状態管理DB101から取得されたセッションIDが記載されるsessionIDタグ、鍵IDが記載されるkeyIDタグ、セッション管理装置100のメモリ12に保存されている送信元の通信装置の名前が記載されるterm1タグ、当該通信装置のIPアドレスが記載されるaddr1タグ、当該通信装置の通信相手の名前が記載されるterm2タグ、当該通信相手のIPアドレスが記載されるaddr2タグ、通信開始時刻が記載されるstartタグ、通信終了時刻が記載されるendタグ、および、使用される暗号アルゴリズム名が記載されるencタグが記載される。
【0115】
監査装置600のセッション情報取得機能602は、セッション管理装置100からセッション情報一覧取得応答2900を受信すると(ステップS155)、監査アプリケーション604は、内部状態を監査前状態へ遷移させる。そして、セッション情報一覧取得応答2900のstatusタグに"NG"が記載されている場合、監査アプリケーション604は、監査対象の通信のセッション情報の再検索を促し、セッション情報検索画面3400を再表示する。監査者は、セッション情報検索画面3400に検索キーを再入力し、監査アプリケーション604は、再びステップS150を実行する。
【0116】
セッション情報一覧取得応答2900のstatusタグに"OK"が記載されている場合、監査アプリケーション604は、取得したセッション情報3100と監査装置600のメモリ12に保存されていた検索キーとを照合した結果を、セッション情報検索結果画面3500に表示する。
【0117】
本実施例1において、監査アプリケーション604は、例えば図16(b)に示すようなセッション情報検索結果画面3500を表示する。セッション情報検索結果画面3500には、セッション情報3100のsessionIDタグに記載されたセッションID、term1タグに記載された送信元の通信装置の名前、addr1タグに記載された送信元の通信装置のIPアドレス、term2タグに記載された宛先の通信装置の名前、addr2タグに記載された宛先の通信装置のIPアドレス、startタグに記載された通信開始時刻、endタグに記載された通信終了時刻、およびencタグに記載された暗号アルゴリズム名が、新たに付与された監査IDと共に表示される。
【0118】
なお、セッション情報検索結果画面3500を表示する際に、監査アプリケーション604は、検索キーの送信元の通信装置の名前がterm1タグに記載されている名前と一致する場合に、セッション情報検索結果画面3500の送信元の通信装置の名前の項目に、term1タグおよびaddr1タグに記載された情報を記載する。同様に、検索キーの宛先の通信装置の名前がterm2タグに記載されている名前と一致する場合に、監査アプリケーション604は、セッション情報検索結果画面3500の宛先の通信装置の名前の欄にterm2タグおよびaddr2タグに記載された情報を記載する。
【0119】
また、セッション情報一覧取得応答2900から取得した複数のセッション情報3100のうち、sessionIDタグに同じセッションIDが記載されているセッション情報3100が二つ以上存在する場合、監査アプリケーション604は、まとめて一つの通信セッションとしてセッション情報検索結果画面3500に表示する。
【0120】
監査者は、セッション情報検索結果画面3500を参照して、監査対象の暗号通信のセッション情報を確認する。そして、監査者は、監査対象の通信の条件を指定し直したい場合、セッション情報検索結果画面3500に表示されている再検索ボタンを押す。再検索ボタンが押されると、監査アプリケーション604は、セッション情報検索画面3400を再度表示し、監査者から入力された検索キーに基づいて、再びステップS150を実行する。このように、セッション情報検索結果画面3500を参照することにより、監査者は、より効率よく監査処理を進めることができる。
【0121】
一方、監査者は、検索されたセッション情報に対応する通信内容の監査を実施する場合、セッション情報検索結果画面3500に表示された通信のセッション情報一覧から、監査対象の通信を選択し、監査開始ボタンを押す。監査対象ボタンが押されると、監査アプリケーション604は、選択された監査対象の通信情報を監査装置600のメモリ12に保存すると共に、鍵取得機能601が鍵取得要求3200を作成して鍵管理装置200へ送信する(ステップS156)。
【0122】
本実施例1において、鍵取得要求3200は、例えば図14(d)に示すように、XMLメッセージのgetKeyRequestタグとして記述される。図14(d)は、監査装置600から鍵管理装置200へ送信されるセッション情報3100のうち、本実施例の説明に必要な部分のみを示している。監査対象の通信の鍵IDがkeyIDタグに記載される。なお、1つの鍵取得要求3200には、複数のkeyIDタグが記載されてもよい。
【0123】
鍵管理装置200の鍵送受信機能203は、監査装置600から鍵取得要求3200を受信すると(ステップS157)、鍵管理機能202は、鍵取得要求3200のkeyIDタグに記載されている鍵IDをキーに鍵管理DB201を検索する(ステップS158)。この時点では、鍵管理DB201に格納されている情報は、例えば図13(d)に示すようになっているものと仮定する。
【0124】
鍵管理機能202は、鍵取得要求3200のkeyIDタグに記載されている鍵IDが、鍵管理DB201内の2行目と3行目に登録されていることを検出する。そして、鍵管理機能202は、2行目に記載された鍵と3行目に記載された鍵を取得し(ステップS159)、鍵送受信機能203は、取得された鍵を用いて鍵取得応答3300を作成し、監査装置600へ送信する(ステップS160)。
【0125】
本実施例1では、鍵取得応答3300は、例えば図14(e)に示すように、XMLメッセージのgetKeyResponseタグとして記述される。図14(e)は、鍵管理装置200から監査装置600へ送信される鍵取得応答3300のうち、本実施例の説明に必要な部分のみを示している。鍵送受信機能203は、鍵管理DB201から監査対象の通信の鍵IDおよび鍵を取得した結果をstatusタグに記載する。登録成功の場合にはstatusタグに"OK"が記載され、登録失敗の場合には"NG"が記載される。また、監査対象の通信の鍵IDがkeyIDタグに記載され、鍵がkeyタグに記載される。なお、keyIDタグおよびkeyタグは監査対象の通信の数だけ複数記載されていてもよい。
【0126】
監査装置600の鍵取得機能601は、鍵管理装置200から鍵取得応答3300を受信すると(ステップS161)、鍵取得応答3300のkeyIDタグに記載されている鍵IDおよびkeyタグに記載されている鍵を取得し(ステップS162)、監査装置600のメモリ12に保存する。そして、パケット取得・復号機能603は、パケット取得要求3600を作成し、パケットモニタ装置500へ送信する(ステップS163)。
【0127】
本実施例1では、パケット取得要求3600は、例えば図15(b)に示すように、XMLメッセージのgetPacketRequestタグとして記述される。図15(b)は、監査装置600からパケットモニタ装置500へ送信されるパケット取得要求3600のうち、本実施例の説明に必要な部分のみを示している。監査装置600のメモリ12に保存された監査対象の通信情報のうち、送信元の通信装置のIPアドレスがfromタグに記載され、宛先の通信装置のIPアドレスがtoタグに記載され、開始時刻がstartタグに記載され、終了時刻がendタグに記載される。なお、これらのフィールドは、監査対象の通信のセッションID毎に複数記載されてもよい。
【0128】
パケットモニタ装置500のパケット送信機能504が監査装置600からパケット取得要求3600を受信すると(S164)、パケット管理機能503は、パケット取得要求3600のaddr1タグに記載されているユーザ端末300のIPアドレス、addr2タグに記載されているサービス提供サーバ350のIPアドレス、startタグに記載されている暗号通信の開始時刻、およびendタグに記載されている暗号通信の終了時刻をキーとして、パケットDB501を検索する。この時点では、パケットDB501に格納されている情報は、例えば図15(a)のようになっていると仮定する。
【0129】
パケット管理機能503は、パケット取得要求3600のaddr1タグに記載されているユーザ端末300のIPアドレスおよびaddr2タグに記載されているサービス提供サーバ350のIPアドレスが、1行目に記載されていることを検出する。そして、startタグに記載されている開始時刻からendタグに記載されている終了時刻までの範囲の日付が、パケット格納場所の名称の下8桁と一致することを確認する。すなわち、図15(b)において、パケット取得対象の暗号通信が行われた日付は「2006年4月1日」であり、図15(a)の1行目に記載されたパケット格納場所の下8桁が「20060401」となっていることを確認する。その後、パケット管理機能503は、1行目のパケット格納場所レコードに示されている格納場所へアクセスし、ユーザ端末300からサービス提供サーバ350へ送信された暗号パケットを取得する(ステップS165)。
【0130】
そして、パケット送信機能504は、パケット取得応答3700を作成し、監査装置600へ送信する(ステップS166)。監査装置600のパケット取得・復号機能603がパケットモニタ装置500からパケット取得応答3700を受信すると(ステップS167)、監査アプリケーション604は、パケットモニタ装置500が暗号パケットを取得済である旨を画面に表示する。そして、監査者は、監査アプリケーション604が表示した画面を見て、暗号パケットを取得済である旨を確認する。
【0131】
本実施例1では、パケット取得応答3700は、例えば図15(c)に示すように、XMLメッセージのgetPacket Responseタグとして記述される。図15(c)は、パケットモニタ装置500から監査装置600へ送信されるパケット取得応答3700のうち、本実施例の説明に必要な部分のみを示している。パケットDB501から暗号パケットが取得された結果がstatusタグに記載される。取得成功の場合にはstatusタグに"OK"が記載され、取得失敗の場合には"NG"が記載される。
【0132】
その後、パケットモニタ装置500のパケット送信機能504は、ユーザ端末300からサービス提供サーバ350へ送信された暗号パケットを監査装置600へ送信する(ステップS168)。そして、監査装置600のパケット取得・復号機能603は、パケットモニタ装置500から暗号パケットを受信し(ステップS169)、監査装置600内の外部記憶装置17に保存する。
【0133】
パケットモニタ装置500のパケット送信機能504は、暗号パケットを全て監査装置600に送信した場合、パケット送信終了通知3800を作成して監査装置600へ送信する(ステップS170)。本実施例1において、パケット送信終了通知3800は、例えば図15(d)に示すように、XMLメッセージのendSendingPacketInfoタグとして記述される。
【0134】
監査装置600のパケット取得・復号機能603がパケットモニタ装置500からパケット送信終了通知3800を受信すると(ステップS171)、監査アプリケーション604は、内部状態を監査処理実施状態に遷移させる。そして、パケット取得・復号機能603は、監査装置600のメモリ12から鍵と監査対象の通信情報を取り出し、監査装置600の外部記憶装置17に保存されている暗号パケットを復号する。監査者は、復号されたパケットを基に、ユーザ端末300とサービス提供サーバ350との通信の通信内容を監査する。
【0135】
監査終了後、監査者は、監査アプリケーション604に監査終了の指示を行うと、監査アプリケーション604は、監査装置600のメモリ12に保存されている鍵IDおよび鍵、ならびに監査装置600の外部記憶装置17に保存されている暗号パケットを削除する。そして、監査アプリケーション604は、監査処理を終了し(S172)、内部状態を待ち状態に遷移させると、監査処理が終了したことを表示する。監査者は、監査アプリケーション604が表示した内容を確認することで、監査処理が終了したことを認識する。
【0136】
以上が、暗号通信終了後に監査装置600がパケットDB501に保存されている暗号パケットを取得し、取得した暗号パケットを復号してパケットの内容を監査する場合の動作シーケンスである。なお、通信内容を監査する場合、監査アプリケーション604は、復号した一連のパケットを解析して、通信に用いられたアプリケーションプロトコルの種類(HTTP等)、および、ユーザ端末300がアクセスしたサービス提供サーバ350のリソース名(URL等)といった、通信のサマリを表示するようにしてもよい。
【0137】
なお、本実施例1における監査の実施形態としては、暗号通信終了した後に当該暗号通信の内容を監査するだけでなく、リアルタイムで行われている暗号通信の内容を監査することも可能である。この場合、図8のステップS150からステップS155までの処理を行った後、監査装置600の監査アプリケーション604が表示するセッション情報検索結果画面3500には、現在行われている暗号通信のセッション情報が含まれることになる。そして、監査者が現在行われている暗号通信を選択すると、ステップS156からステップS171までの処理を行った後、監査装置600の監査アプリケーション604は、リアルタイム監査の処理を行い、ステップS172で監査処理を終了する。
【0138】
また、本実施例1では、鍵管理装置200でなく、ユーザ端末300またはサービス提供サーバ350等の暗号通信を行う通信装置が鍵情報を生成することも可能である。この場合、ユーザ端末300およびサービス提供サーバ350には、鍵生成機能が新たに設けられる。この場合の暗号通信開始時および鍵更新時の動作シーケンスは次のようになる。
【0139】
まず、ユーザ端末300の鍵生成機能は、ステップS101において、サービス提供サーバ350へ送信するパケットを暗号化するための鍵、当該鍵の有効期間、および暗号アルゴリズム名を含む鍵情報3000を生成してユーザ端末300のメモリ12に保存すると共に、通信開始要求2000のBODY部に生成した鍵情報3000を記載する。そして、SIPクライアント機能302は、通信開始要求2000をセッション管理装置100へ送信する。
【0140】
セッション管理装置100のメッセージ送受信機能105がステップS102でユーザ端末300から通信開始要求2000を受信すると、鍵取得機能104は、通信開始要求2000のBODY部に記載されている鍵情報3000をセッション管理装置100のメモリ12に保存する。そして、メッセージ送受信機能105は、ステップS110を実行する。すなわち、メッセージ送受信機能105は、通信開始要求2000をサービス提供サーバ350へ送信する。
【0141】
次に、サービス提供サーバ350は、ステップS111からステップS115を実行する。なお、ステップS113において、サービス提供サーバ350の鍵取得機能301は、通信開始要求2000のBODY部に記載されている鍵情報3000を取得し、取得した鍵情報3000を、当該2000のCall-IDフィールドに記載されているセッションIDに対応付けてサービス提供サーバ350のメモリ12に保存する。ここで保存された鍵は、ユーザ端末300から送信された暗号パケットを復号する際に使用され、ユーザ端末300へ送信されるパケットの暗号化には使用されない。
【0142】
また、ステップS114において、鍵取得機能301は、ユーザ端末300へ送信するパケットを暗号化するための鍵、鍵の有効期間、および暗号アルゴリズム名を含む鍵情報3000を通信開始応答2100のBODY部に記載する。そして、SIPクライアント機能302は、当該通信開始応答2100をセッション管理装置100へ送信する。
【0143】
セッション管理装置100のメッセージ送受信機能105は、ステップS116でサービス提供サーバ350から通信開始応答2100を受信すると、ステップS117を実行する。通信開始応答2100が通信を拒否する旨を示すメッセージを含む場合、メッセージ送受信機能105は、ステップS122以降の処理を実行する。通信開始応答2100が通信を許可する旨を示すメッセージを含む場合、メッセージ送受信機能105は、通信開始応答2100内の鍵情報3000をセッション管理装置100のメモリ12に保存する。そして、鍵取得機能104は、ステップS103を実行する。すなわち、鍵取得機能104は、鍵生成要求2200を生成して鍵管理装置200へ送信する。なお、この場合、鍵生成要求2200には、ユーザ端末300から送信された鍵情報3000とサービス提供サーバ350から送信された鍵情報3000とが記載される。
【0144】
そして、鍵管理装置200は、ステップS104からステップS107を実行する。なお、ステップS105において、鍵管理機能202は、鍵生成要求2200に記載されている、ユーザ端末300から送信された鍵情報3000に対応する鍵ID、および、サービス提供サーバ350から送信された鍵情報3000に対応する鍵IDを、それぞれ生成する。そして、ステップS106において、鍵管理機能202は、鍵管理DB201に、鍵ID毎に鍵情報3000内の暗号アルゴリズムおよび鍵を登録する。
【0145】
そして、セッション管理装置100の鍵取得機能104は、ステップS108において鍵管理装置200から鍵生成応答2300を受信すると、ステップS118からステップS121を実行する。そして、鍵取得機能104は、通信開始応答2100のBODY部に、サービス提供サーバ350から送信された鍵情報3000を記載して、ステップS127を実行する。
【0146】
そして、ユーザ端末300は、ステップS128からステップS130を実行する。なお、ステップS130において、ユーザ端末300の鍵取得機能301は、通信開始応答2100のBODY部に記載されている鍵情報3000を取得し、通信開始応答2100のCall-IDフィールドに記載されているセッションIDと対応付けてユーザ端末300のメモリ12に保存する。ここで、保存された鍵情報3000内の鍵は、サービス提供サーバ350から送信された暗号パケットを復号する際に使用され、サービス提供サーバ350へ送信されるパケットの暗号化には使用されない。
【0147】
また、暗号通信終了のシーケンスについては、ステップS135およびステップS140において、ユーザ端末300およびサービス提供サーバ350の鍵取得機能301がそれぞれメモリ12に保存していたセッションIDおよび鍵情報3000を削除する。
【0148】
なお、ユーザ端末300またはサービス提供サーバ350が暗号通信に使用される鍵を生成する場合、上記では受信用の鍵と送信用の鍵を別にしたが、送信用の鍵と受信用の鍵を同じにしてもよい。その場合、サービス提供サーバ350が鍵情報3000を作成してユーザ端末300へ送信する処理および鍵管理装置200がサービス提供サーバ350によって作成された鍵情報3000を鍵管理DB201に登録する処理は不要である。
<実施例2>
本実施例2では、監査装置600によって指定された暗号通信のみが監査対象とされ、パケットモニタ装置500は、対象となる暗号通信において送信される暗号パケットのみ取得する。これにより、パケットモニタ装置500は、保存すべき暗号パケットのデータ量を少なくすることができる。
【0149】
図17は、本実施例2の通信内容監査支援システムのシステム構成図である。本実施例2では、実施例1の場合と異なり、セッション管理装置100、パケットモニタ装置500、および監査装置600内に、新たな機能が追加されている。
【0150】
セッション管理装置100は、監査装置600から指定された監査条件を登録する監査条件テーブル102と、監査条件テーブル102に登録された監査条件を基に通信内容の監査に関する制御を行うバス107とを新たに備える。また、セッション情報通知機能106は、実施例1で説明した機能に加え、監査対象となる暗号通信が開始した場合に当該暗号通信のセッション情報を監査装置600に通知する機能を有する。
【0151】
パケットモニタ装置500は、監査装置600から指定された暗号通信において送信される暗号パケットのみ取得し、それ以外の暗号パケットを破棄するパケット収集制御機能505を新たに備える。
【0152】
監査装置600は、セッション管理装置100に監査対象の暗号通信の条件を指示する監査条件指示機能605と、セッション管理装置100から暗号通信開始の通知を受けた場合に、当該暗号通信において送信される暗号パケットの収集をパケットモニタ装置500に指示するパケット収集指示機能606とを新たに備える。なお、監査アプリケーション604は、実施例1において説明した機能に加え、監査対象となる暗号通信の条件を設定したり、指定した監査条件と合致する暗号通信の通信内容を通信開始時からリアルタイム監査したりする機能を有する。
【0153】
次に、ユーザ端末300がセッション管理装置100を介して、サービス提供サーバ350と暗号通信に使用する鍵を共有し、暗号通信を開始する場合の一連の動作シーケンスについて、図3、図4、図18、および図19を用いて説明する。なお、本実施例2では、実施例1の場合とは異なり、監査装置600が事前にセッション管理装置100に対して、監査対象となる暗号通信の条件を指定する。また、セッション管理装置100は、ユーザ端末300から通信開始要求を受信すると、これから開始される暗号通信が事前に監査装置600から指定された条件と合致するか否かを調べ、合致する場合、監査装置600に暗号通信の開始を通知し、監査装置600は、パケットモニタ装置500にパケット収集を指示する。
【0154】
まず、監査装置600を利用する監査者は、監査アプリケーション604が表示している監査条件入力画面3900(図22(a)参照)に、監査対象の暗号通信に関する条件を入力する。監査アプリケーション604は、入力された監査条件を読み込む(ステップS201)。
【0155】
本実施例2において、監査条件入力画面3900に入力される監査条件には、監査のタイミング、監査対象の暗号通信を行う送信元の通信装置の名前、宛先の通信装置の名前、暗号パケットの送信時刻の範囲、および暗号通信に使用される暗号アルゴリズム名が含まれる。図22(a)に示す監査条件入力画面3900の例では、名前が"user"である通信装置から、名前が"service"である通信装置へ送信された暗号パケットであり、かつ、通信に使用される暗号アルゴリズム名が"AES-256bit"である暗号パケットが監査対象の暗号パケットとして指定された様子が示されている。なお、通信装置の名前または監査対象時間帯を指定する各項目は空白でも構わない。検索キーが入力されなかった項目については、監査アプリケーション604は、条件指定が無かったものとして取り扱う。
【0156】
監査装置600の監査条件指示機能605は、監査条件入力画面3900に入力された監査条件を基に監査条件登録要求4000を作成してセッション管理装置100へ送信する(ステップS202)。
【0157】
本実施例2において、監査条件登録要求4000は、例えば図22(b)に示すように、XMLメッセージのregAuditCondRequestタグとして記述される。図22(b)は、監査装置600からセッション管理装置100へ送信される監査条件登録要求4000のうち、本実施例の説明に必要な部分のみを示している。監査条件入力画面3900には、監査条件として入力された情報が記載される。監査条件入力画面3900の「監査のタイミング」の項目で選択された条件がmodeタグに記載され、「送信元の通信装置の名前」および「宛先の通信装置の名前」の項目に入力された条件が、それぞれfromタグおよびtoタグに記載される。
【0158】
また、「監査対象時間帯」の項目に入力された条件が、startタグとendタグに記載され、「暗号アルゴリズム」の項目で選択された条件が、encタグに記載される。なお、監査条件入力画面3900に監査条件が入力されていない項目については、対応する監査条件登録要求4000内のタグに"null"が記載される。また、監査条件入力画面3900の「監査のタイミング」の項目で「後で」が選択された場合、対応するmodeタグには"afterward"が記載され、「リアルタイム」が選択された場合、対応するmodeタグには"realtime"が記載される。
【0159】
セッション管理装置100のバス107は、監査装置600から監査条件登録要求4000を受信すると(ステップS203)、監査条件登録要求4000の情報を監査条件テーブル102に登録し(ステップS204)、監査条件登録応答4100を作成して監査装置600へ送信する(ステップS205)。
【0160】
本実施例2において、監査条件登録応答4100は、例えば図22(c)に示すように、XMLメッセージのregAuditCond Responseタグとして記述される。図22(c)は、セッション管理装置100から監査装置600へ送信される監査条件登録応答4100のうち、本実施例の説明に必要な部分のみを示している。監査条件登録要求4000に記載された監査条件がセッション管理装置100によって監査条件テーブル102に登録された結果がstatusタグに記載される。監査条件が監査条件テーブル102に正常に登録された場合、statusタグには"OK"が記載され、正常に登録されなかった場合には"NG"が記載される。
【0161】
また、セッション管理装置100の監査条件テーブル102には、例えば図23(a)に示すように、監査のタイミング、暗号パケットの送信元の通信装置の名前、暗号パケットの宛先の通信装置の名前、暗号通信が行われる時刻の範囲、および暗号通信に使用される暗号アルゴリズム名が格納される。図23(a)に示す例では、ステップS204が実行されることにより、2行目の監査条件が追加された後の状態が示されている。
【0162】
以上の一連の処理が行われた後、図3を用いて説明したステップS102において、セッション管理装置100のメッセージ送受信機能105がユーザ端末300から通信開始要求2000を受信することにより、図3または図4において説明したステップS103からステップS121までの処理が順次行われる。すなわち、セッション管理装置100は、鍵管理装置200によって生成された鍵情報3000を取得し、これをサービス提供サーバ350へ送信する。そして、セッション管理装置100は、サービス提供サーバ350から通通信開始応答2100を受信すると、通信状態管理DB101を更新する。なお、更新後の通信状態管理DB101内の情報は、例えば図11(b)に示した内容であると仮定する。
【0163】
以上の処理が行われた後、セッション管理装置100のバス107は、ステップS121において通信状態管理DB101に登録されたセッション情報が監査条件テーブル102に登録された条件と一致するか否かを判定することにより、これから開始される暗号通信が監査対象であるかを判定する(ステップS207)。判定の結果、これから開始される暗号通信が監査対象でない場合、通信内容監査支援システムはステップS127以降の処理を実行する。
【0164】
一方、これから開始される暗号通信が監査対象であり、監査条件テーブル102の内容が図23(a)に示すような状態である場合、セッション管理装置100のセッション情報通知機能106は、監査条件テーブル102の2行目の条件と、図11(b)に示す通信状態管理DB101の2行目に登録されている情報とを基に、監査要件定義5000を作成する。
【0165】
本実施例2において、監査要件定義5000は、例えば図22(h)に示すように、XML形式のdefAuditReqタグとして記述される。図22(h)に示す例において、監査要件定義5000には、監査のタイミングが記載されるmodeタグ、セッションIDが記載されるsessionIDタグ、送信元の通信装置のIPアドレスが記載されるfromタグ、および宛先の通信装置のIPアドレスが記載されるtoタグが記載される。
【0166】
次に、セッション情報通知機能106は、監査要件定義5000が記載された暗号通信開始通知4200を作成する(ステップS208)。そして、バス107は、監査要件定義5000のmodeタグを参照して、これから監査を実施するか否かを判定する(ステップS209)。
【0167】
監査要件定義5000のmodeタグに"afterward"と記載されている場合、セッション管理装置100のセッション情報通知機能106は、暗号通信開始通知4200を監査装置600へ送信する(ステップS211)。一方、監査要件定義5000のmodeタグに"realtime"と記載されている場合、セッション情報通知機能106は、、セッション管理装置100のメモリ12に保存されている鍵情報3000を暗号通信開始通知4200に記載して(ステップS210)、ステップS211に示した処理を実行する。
【0168】
本実施例2において、暗号通信開始通知4200は、例えば図22(d)に示すように、XMLメッセージのstartCommunicationInfoタグとして記述される。図22(d)は、セッション管理装置100から監査装置600へ送信される暗号通信開始通知4200のうち、本実施例の説明に必要な部分のみを示している。暗号通信開始通知4200には、図22(h)に示した監査要件定義5000が記載される。暗号通信がリアルタイムに監査される場合には、更に、図12(c)で説明した鍵情報3000が記載される。
【0169】
監査装置600のセッション情報取得機能602は、セッション管理装置100から暗号通信開始通知4200を受信すると(ステップS212)、暗号通信開始通知4200に記載されている監査要件定義5000を監査装置600のメモリ12に保存し、監査要件定義5000のmodeタグを参照して、これから監査を実施するか否かを判定する(ステップS213)。
【0170】
modeタグに"afterward"と記載されている場合、監査装置600のパケット収集指示機能606は、パケット収集開始要求4600を作成してパケットモニタ装置500へ送信する(ステップS215)。一方、modeタグに"realtime"と記載されている場合、監査装置600のセッション情報取得機能602は、暗号通信開始通知4200に記載されている鍵情報3000を監査要件定義5000と対応づけて監査装置600のメモリ12に保存する(ステップS214)。そして、監査アプリケーション604は、内部状態をリアルタイム監査状態に遷移させ、ステップS215に示した処理を実行する。
【0171】
本実施例2において、パケット収集開始要求4600は、例えば図23(c)に示すように、XMLメッセージのstartGathering PacketRequestタグとして記述される。図23(c)は、監査装置600からパケットモニタ装置500へ送信されるパケット収集開始要求4600のうち、本実施例の説明に必要な部分のみを示している。監査要件定義5000のmodeタグ、sessionIDタグ、fromタグ、およびtoタグ内の情報がそのままパケット収集開始要求4600のmodeタグ、sessionIDタグ、fromタグ、およびtoタグにそれぞれ記載される。
【0172】
パケットモニタ装置500のパケット収集制御機能505は、監査装置600からパケット収集開始要求4600を受信すると(ステップS216)、パケット収集開始要求4600の情報をパケットDB501の空白行に記載する。また、パケット管理機能503は、暗号パケットの格納領域を作成し、格納場所をパケットDB501のパケット格納場所レコードに記載する。そして、パケット管理機能503は、パケットDB501の状態レコードに「パケット収集中」と記載する。そして、パケット収集制御機能505は、パケット収集開始応答4700を作成して監査装置600へ送信し(ステップS217)、内部状態をパケット受信待ち状態に遷移させる。
【0173】
本実施例2において、パケット収集開始応答4700は、例えば図23(d)に示すように、XMLメッセージのstartGathering PacketResponseタグとして記述される。図23(d)は、パケットモニタ装置500から監査装置600へ送信されるパケット収集開始応答4700のうち、本実施例の説明に必要な部分のみを示している。パケットの収集対象である暗号通信の情報がパケットDB501に登録された結果が、statusタグに記載される。登録成功の場合はstatusタグに"OK"が記載され、失敗の場合には"NG"が記載される。また、パケット収集開始応答4700には、パケット収集開始要求4600のsessionIDタグが記載される。
【0174】
なお、本実施例2において、パケットDB501は、例えば図23(b)に示すようなデータ構造を有しており、図15(a)で説明した実施例1のパケットDB501と比較して、「セッションID」、「監査のタイミング」、および「状態」のレコードが新たに追加されている。これにより、パケットモニタ装置500が取得した暗号パケットをセッションID毎に管理することができ、監査時に監査装置600から要求のあったセッションIDに対応する暗号パケットを確実に取得することができる。
【0175】
また、「監査のタイミング」レコードを参照することにより、パケット収集制御機能505は、リアルタイム監査時に、受信した暗号パケットを直ちに監査装置600へ送信することができる。また、状態レコードを確認することで、パケットモニタ装置500のパケット管理機能503は、受信したパケットをセッションID毎に分けて保存することができる。
【0176】
監査装置600のパケット収集指示機能606がパケットモニタ装置500からパケット収集開始応答4700を受信すると(ステップS218)、セッション情報取得機能602は、暗号通信開始確認応答4300を作成してセッション管理装置100へ送信する(ステップS219)。本実施例2において、暗号通信開始確認応答4300は、例えば図22(e)に示すように、XMLメッセージのackStartCommunicationInfoタグとして記述される。また、ackStartCommunicationInfoタグ内には、監査要件定義5000のsessionIDタグが記載される。
【0177】
セッション管理装置100のセッション情報通知機能106は、監査装置600から暗号通信開始確認応答4300を受信すると(ステップS220)、鍵取得機能104は、セッション管理装置100のメモリ12に保存されている鍵情報3000を、図10(b)において説明したに通信開始応答2100のBODY部に記載する。そして、メッセージ送受信機能105は、通信開始応答2100をユーザ端末300へ送信し、実施例1で説明したステップS127以降の処理を実行する。
【0178】
以上が、本実施例2において、ユーザ端末300がセッション管理装置100を介して、サービス提供サーバ350と暗号通信に使用される鍵を共有し、暗号通信を開始する場合の動作シーケンスである。
【0179】
また、ユーザ端末300とサービス提供サーバ350との間で共有された鍵の有効期限が切れ、その契機で鍵更新を行う場合の一連の動作において、図18のステップS202からステップS212までは暗号通信開始の動作シーケンスと同一である。なお、ステップS212において、監査装置600がセッション管理装置100から暗号通信開始通知4200を受信した場合、監査装置600の内部状態は待ち状態またはリアルタイム監査状態のいずれかである。また、このとき、通信状態管理DB101内のデータは、図11(c)のようになっているものと仮定する。
【0180】
ステップS212において、監査装置600のセッション情報取得機能602がセッション管理装置100から暗号通信開始通知4200を受信すると、監査装置600のメモリ12内に対応する監査要件定義5000が保存されているか否かを判定する。メモリ12内に対応する監査要件定義5000が保存されている場合、セッション情報取得機能602は、暗号通信開始通知4200に記載されている監査要件定義5000のsessionIDタグと、監査装置600のメモリ12に保存されている監査要件定義5000のsessionIDタグとを比較し、セッションIDが一致すれば一連の処理が鍵更新を契機としたものであると判断する。
【0181】
そして、ステップS213において、監査要件定義5000のmodeタグに"afterward"と記載されている場合、ステップS219が実行される。一方、監査要件定義5000のmodeタグに"realtime"と記載されている場合、ステップS214が実行された後に、ステップS219が実行される。
【0182】
以上が、本実施例2において、ユーザ端末300とサービス提供サーバ350との間で共有した鍵の有効期限が切れ、その契機で鍵更新を行う場合の動作シーケンスである。なお、このシーケンスについては、サービス提供サーバ350がセッション管理装置100を介してユーザ端末300へ通信開始要求2000を送信することも可能である。また、鍵の有効期限が切れたことを契機とするのではなく、鍵の有効期限が近づいたことを契機として一連の動作が実行されてもよい。
【0183】
次に、ユーザ端末300がセッション管理装置100を介して、サービス提供サーバ350との間の暗号通信を終了する場合の一連の動作シーケンスを、図20を用いて説明する。
【0184】
ステップS132において、セッション管理装置100のメッセージ送受信機能105がユーザ端末300から通信終了要求2400を受信すると、実施例1において図6を用いて説明したステップS133からステップS138までの処理が順次行われる。すなわち、セッション管理装置100は、通信終了要求2400をサービス提供サーバ350へ送信し、サービス提供サーバ350から通信終了応答2500を受信すると、通信状態管理DB101内の情報を更新する。
【0185】
以上の処理が行われた後、セッション管理装置100のバス107は、ステップS121において、通信状態管理DB101に登録されている情報が監査条件テーブル102に登録されている条件に一致するか否かを判定することにより、終了対象の暗号通信が監査対象であるか否かを判定する(ステップS221)。
【0186】
終了対象の暗号通信が監査対象でなかった場合(S221:No)、通信内容監査支援システムはステップS139以降の処理を実行する。一方、終了対象の暗号通信が監査対象であった場合(S221:Yes)、セッション管理装置100のセッション情報通知機能106は、暗号通信終了通知4400を作成して監査装置600へ送信する(ステップs222)。
【0187】
本実施例2において、暗号通信終了通知4400は、例えば図22(f)に示すように、XMLメッセージのendCommunication Infoタグとして記述される。図22(f)は、セッション管理装置100から監査装置600へ送信される暗号通信終了通知4400のうち、本実施例の説明に必要な部分のみを示している。通信終了要求2400のCall-IDフィールドに記載されているセッションIDが、暗号通信終了通知4400のsessionIDタグに記載される。
【0188】
監査装置600のセッション情報取得機能602は、セッション管理装置100から暗号通信終了通知4400を受信すると(ステップS223)、パケット収集終了要求4800を作成してパケットモニタ装置500へ送信する(ステップS224)。
【0189】
本実施例2において、パケット収集終了要求4800は、例えば図23(e)に示すように、XMLメッセージのendGatheringPacketRequestタグとして記述される。図23(e)は、監査装置600からパケットモニタ装置500へ送信されるパケット収集終了要求4800のうち、本実施例の説明に必要な部分のみを示している。パケット収集終了要求4800のsessionIDタグには、暗号通信終了通知4400のsessionIDタグの情報がそのまま記載される。
【0190】
パケットモニタ装置500のパケット収集制御機能505は、監査装置600からパケット収集終了要求4800を受信すると(ステップS225)、パケットの収集を終了する。具体的には、パケットDB501内のデータが図23(b)に示すような状態にある場合に、パケット収集制御機能505は、パケット収集終了要求4800に記載されているセッションIDに対応するレコードの状態を示す情報を、「パケット収集中」から「パケット収集済」に書き換える。そして、パケット収集制御機能505は、パケット収集終了応答4900を作成して監査装置600へ送信し(ステップS226)、内部状態を待ち状態に遷移させる。
【0191】
本実施例2において、パケット収集終了応答4900は、例えば図23(f)に示すように、XMLメッセージのendGatheringPacketResponseタグとして記述される。図23(f)は、パケットモニタ装置500から監査装置600へ送信されるパケット収集終了応答4900のうち、本実施例の説明に必要な部分のみを示している。パケット収集制御機能505によってパケット収集の終了処理が行われた結果がstatusタグに記載される。終了成功の場合はstatusタグに"OK"が記載され、失敗の場合には"NG"が記載される。また、パケット収集終了応答4900には、パケット収集終了要求4800のsessionIDタグが記載される。
【0192】
監査装置600のパケット収集指示機能606がパケットモニタ装置500からパケット収集終了応答4900を受信すると(ステップS227)、セッション情報取得機能602は、終了対象の暗号通信がリアルタイム監査を実施していたか否かを判定する(ステップS228)。ステップS212の後にセッション情報3100と共に監査装置600のメモリ12に保存された監査のタイミングを示す情報が"afterward"である場合、セッション情報取得機能602は、リアルタイム監査を実施していなかったと判定し、暗号通信終了確認応答4500を作成してセッション管理装置100へ送信する(ステップS230)。
【0193】
一方、監査のタイミングを示す情報が"realtime"である場合、セッション情報取得機能602は、リアルタイム監査を実施していたと判定し、監査装置600のメモリ12に保存している鍵情報3000を削除し(ステップS229)、内部状態を待ち状態へ遷移させた後、ステップS230に示した処理を実行する。本実施例2において、暗号通信終了確認応答4500は、例えば図22(g)に示すように、XMLメッセージのackEndCommunicationInfoタグとして記述される。また、ackEndCommunicationInfoタグの中には、暗号通信終了通知4400のsessionIDタグが記載される。
【0194】
セッション管理装置100のセッション情報通知機能106は、監査装置600から暗号通信終了確認応答4500を受信すると(ステップS231)、メッセージ送受信機能105は、通信終了応答2500を作成してユーザ端末300へ送信し、実施例1において説明したステップS139以降の処理を実行する。
【0195】
以上が、本実施例2において、ユーザ端末300がセッション管理装置100を介して、サービス提供サーバ350との間の暗号通信を終了する場合の動作シーケンスである。なお、このシーケンスについては実施例1と同様、サービス提供サーバ350からセッション管理装置100を介してユーザ端末300に通信終了要求2400を送信することにより暗号通信を終了することも可能である。
【0196】
次に、ユーザ端末300とサービス提供サーバ350との間で暗号パケットを送信または受信する場合の一連の動作シーケンスを、図21を用いて説明する。なお、図21に示す例では、暗号パケットがユーザ端末300からサービス提供サーバ350へ送信される場合を例に説明されている。また、ユーザ端末300とサービス提供サーバ350との間の暗号通信において、送信または受信される暗号パケットは、必ずモニタリング機能付ルーティング装置400を経由する。
【0197】
ステップS148において、パケットモニタ装置500のパケット受信機能502がモニタリング機能付ルーティング装置400から暗号パケットを受信すると、パケット収集制御機能505は、受信した暗号パケットが監査対象であるか否かを判定する(ステップS232)。
【0198】
受信した暗号パケットのヘッダに記載されている送信元のIPアドレスおよび宛先のIPアドレスの組が、パケットDB501のどの行にも記載されていない場合、または、当該組が記載されているものの、「状態」の欄に「パケット収集済」が記載されている場合、パケット収集制御機能505は、暗号パケットが監査対象ではないと判定し(S232:No)、受信した暗号パケットを破棄する(ステップS233)。
【0199】
一方、パケット収集制御機能505は、暗号パケットが監査対象であると判定した場合(S232:Yes)、パケット収集制御機能505は、パケットDB501の「監査のタイミング」の欄を参照して、受信した暗号パケットに対して実施する監査がリアルタイム監査であるか否かを判定する(ステップS234)。
【0200】
「監査のタイミング」の欄に「後で」と記載されている場合(S234:No)、パケット管理機能503は、受信した暗号パケットをパケットDB501に保存する(S149)。一方、「監査のタイミング」の欄に「リアルタイム」と記載されている場合(S234:Yes)、パケット収集制御機能505は、受信した暗号パケットを複製し(ステップS235)、複製した暗号パケットを監査装置600へ送信し(ステップS236)、ステップS149に示した処理を実行する。
【0201】
監査装置600のパケット取得・復号機能603は、パケットモニタ装置500から暗号パケットを受信すると(ステップS237)、暗号パケットのヘッダ領域(図15(e)参照)に記載されている送信元装置のIPアドレスおよび宛先装置のIPアドレスを参照し、当該IPアドレスの組と一致する監査要件定義5000および鍵情報3000を監査装置600のメモリ12から取り出す。そして、パケット取得・復号機能603は、取り出した鍵情報3000を用いて暗号パケットを復号し(ステップS238)、監査者は復号されたパケットを基に、ユーザ端末300とサービス提供サーバ350との通信の通信内容を監査する。
【0202】
以上が、本実施例2において、暗号通信開始後に、ユーザ端末300とサービス提供サーバ350との間で暗号パケットを送信または受信する場合の動作シーケンスである。なお、このシーケンスについては実施例1と同様、サービス提供サーバ350がユーザ端末300に対して暗号パケットを送信することも可能である。
【0203】
なお、上記した実施例1および実施例2において、ユーザ端末300とセッション管理装置100との間の通信、および、サービス提供サーバ350とセッション管理装置100との間の通信に関しては、ユーザ端末300およびサービス提供サーバ350の公開鍵あるいは当該公開鍵が記載された公開鍵証明書をセッション管理装置100内に保存し、セッション管理装置100の公開鍵あるいは当該公開鍵が記載された公開鍵証明書をユーザ端末300およびサービス提供サーバ350内に保存し、これらの公開鍵を用いて、各SIPメッセージを通信相手の公開鍵で暗号化して送信したり、各SIPメッセージの受信後に自装置の秘密鍵で復号したりしてもよい。これにより、鍵情報3000の漏洩の危険性を減少させることができる。
【0204】
また、通信内容監査支援システムに、複数の装置を設け、それぞれの装置に、通信状態管理DB101、鍵管理DB201、およびパケットDB501をそれぞれ分割してそれぞれ格納することにより、セッション情報に関するデータ、鍵、鍵ID、および暗号アルゴリズム名に関するデータ、ならびに、暗号パケットを分散管理するようにしてもよい。これにより、1台のデータベースが故障することにより全てのデータが消失してしなうような危険性を回避することができる。
【0205】
また、複数の装置のそれぞれに鍵管理DB201内のデータを分割して格納する場合、鍵を秘密分散により複数の情報に分割するようにしてもよい。これにより、鍵の漏洩の危険性をさらに減少させることができる。
【0206】
また、本実施例2の通信内容監査支援システムは、複数のパケットモニタ装置500およびモニタリング機能付ルーティング装置400を有していてもよい。この場合、監査装置600内には、それぞれのモニタリング機能付ルーティング装置400に接続されているパケットモニタ装置500のアドレスを示す情報が記載されたテーブルが格納される。パケットモニタ装置500のアドレスを示す情報としては、例えばサブネットマスクおよびIPアドレス等である。監査装置600は、当該テーブルを参照して、該当する全てのパケットモニタ装置500に指示を出す。
【0207】
具体的には、図19のステップS215において、監査装置600のパケット収集指示機能606は、パケットモニタ装置500のアドレスを示す情報が記載されたテーブルを参照して、どのパケットモニタ装置500へパケット収集を指示するかを判定する。判定の際、パケット収集指示機能606は、監査装置600のメモリ12に保存されている監査要件定義5000に記載されている送信元のIPアドレスおよび宛先のIPアドレスを基に、どちらかの通信装置と同じネットワークに存在するパケットモニタ装置500を調べる。
【0208】
例えば、図22(h)に示しているように、暗号通信を行うユーザ端末300のIPアドレスとサービス提供サーバ350のIPアドレスとがそれぞれ192.168.10.1と192.168.20.1であるので、例えばIPアドレスが192.168.20.10であり、サブネットマスクが255.255.255.0であるパケットモニタ装置500は、サービス提供サーバ350と同じネットワークに属する。このような判定方法により、監査装置600は、IPアドレスが192.168.20.10であり、サブネットマスクが255.255.255.0であるパケットモニタ装置500へパケット収集開始要求4600を送信する。
【0209】
また、実施例2では、実施例1と同様に、鍵管理装置200でなく、ユーザ端末300およびサービス提供サーバ350が鍵情報を生成するようにしてもよい。この場合の動作シーケンスは、鍵管理装置200が生成した鍵情報3000の代わりに、ユーザ端末300が生成した鍵情報3000と鍵IDの組、および、サービス提供サーバ350が生成した鍵情報3000と鍵IDの組が用いられる。それ以外は実施例1で補足説明した動作シーケンスと同一である。
【0210】
上記において、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【図面の簡単な説明】
【0211】
【図1】実施例1の通信内容監査支援システムが備える各装置の機能構成を例示する図。
【図2】セッション管理装置100、鍵管理装置200、ユーザ端末300、サービス提供サーバ350、パケットモニタ装置500、または監査装置600の機能を実現する情報処理装置の構成を例示する図。
【図3】実施例1の通信内容監査支援システムにおける暗号通信開始・鍵更新処理の動作を例示するシーケンス図。
【図4】実施例1の通信内容監査支援システムにおける暗号通信開始・鍵更新処理の動作を例示するシーケンス図。
【図5】実施例1の通信内容監査支援システムにおける暗号通信開始・鍵更新処理の動作を例示するシーケンス図。
【図6】実施例1の通信内容監査支援システムにおける暗号通信終了の動作を例示するシーケンス図。
【図7】実施例1の通信内容監査支援システムにおける暗号パケットモニタリングの動作を例示するシーケンス図。
【図8】実施例1の通信内容監査支援システムにおける暗号通信の監査処理を例示するシーケンス図。
【図9】実施例1の通信内容監査支援システムにおける暗号通信の監査処理を例示するシーケンス図。
【図10】通信開始要求2000、通信開始応答2100、通信終了要求2400、および通信終了応答2500のデータ構造を例示する図。
【図11】通信状態管理DB101に格納されるデータの構造を例示する図。
【図12】鍵生成要求2200、鍵生成応答2300、鍵情報3000、鍵削除要求2600、および鍵削除応答2700のデータ構造を例示する図。
【図13】鍵管理DB201に格納されるデータの構造を例示する図。
【図14】セッション情報一覧取得要求2800、セッション情報一覧取得応答2900、セッション情報3100、鍵取得要求3200、および鍵取得応答3300のデータ構造を例示する図。
【図15】実施例1においてパケットDB501に格納されるデータ、パケット取得要求3600、パケット取得応答3700、パケット送信終了通知3800、および暗号パケットのデータ構造を例示する図。
【図16】監査アプリケーション604が表示するセッション情報検索画面3400およびセッション情報検索結果画面3500を例示する図。
【図17】実施例2の通信内容監査支援システムが備える各装置の機能構成を例示する図。
【図18】実施例2の通信内容監査支援システムにおける暗号通信開始の動作を例示するシーケンス図。
【図19】実施例2の通信内容監査支援システムにおける暗号通信開始の動作を例示するシーケンス図。
【図20】実施例2の通信内容監査支援システムにおける暗号通信終了の動作を例示するシーケンス図。
【図21】実施例2の通信内容監査支援システムにおける暗号パケットのモニタリングおよびリアルタイム監査の処理を例示するシーケンス図。
【図22】監査アプリケーション604が表示する監査条件入力画面3900の構成、ならびに、監査条件登録要求4000、監査条件登録応答4100、暗号通信開始通知4200、暗号通信開始確認応答4300、暗号通信終了通知4400、4500、および監査要件定義5000のデータ構造を例示する図。
【図23】監査条件テーブル102に格納されるデータ、実施例2においてパケットDB501に格納されるデータ、パケット収集開始要求4600、パケット収集開始応答4700、パケット収集終了要求4800、およびパケット収集終了応答4900のデータ構造を例示する図。
【符号の説明】
【0212】
0・・・ネットワーク、100・・・セッション管理装置、200・・・鍵管理装置、300・・・ユーザ端末、350・・・サービス提供サーバ、400・・・モニタリング機能付ルーティング装置、500・・・パケットモニタ装置、600・・・監査装置、2000・・・通信開始要求、2100・・・通信開始応答、2200・・・鍵生成要求、2300・・・鍵生成応答、2400・・・通信終了要求、2500・・・通信終了応答、2600・・・鍵削除要求、2700・・・鍵削除応答、2800・・・セッション情報一覧取得要求、2900・・・セッション情報一覧取得応答、3000・・・鍵情報、3100・・・セッション情報、3200・・・鍵取得要求、3300・・・鍵取得応答、3400・・・セッション情報検索画面、3500・・・セッション情報検索結果画面、3600・・・パケット取得要求、3700・・・パケット取得応答、3800・・・パケット送信終了通知、3900・・・監査条件入力画面、4000・・・監査条件登録要求、4100・・・監査条件登録応答、4200・・・暗号通信開始通知、4300・・・暗号通信開始確認応答、4400・・・暗号通信終了通知、4500・・・暗号通信終了確認応答、4600・・・パケット収集開始要求、4700・・・パケット収集開始応答、4800・・・パケット収集終了要求、4900・・・パケット収集終了応答、5000・・・監査要件定義
【技術分野】
【0001】
本発明は、暗号化された通信内容を復号して監査するための技術に関する。
【背景技術】
【0002】
外部の監査機関等が、ネットワーク上で送信されている通信データを収集し、収集した通信データを解析することにより、事件の捜査等の目的で通信内容を監査する場合がある。しかし、通信内容が暗号化されている場合、暗号化された通信データを収集しても、監査機関は、通信内容を把握することができない。
【0003】
これを回避するために、ユーザが暗号通信を行う場合に、当該暗号通信に用いられる鍵を第三者機関に預け、監査機関による通信内容の監査の必要性が生じた場合に、当該監査機関が、監査対象の暗号通信に用いられる鍵を当該第三者機関から取得して、対応する暗号通信の内容を監査するキーエスクローと呼ばれる技術がある(例えば、特許文献1参照)。
【0004】
【特許文献1】米国特許第5535276号明細書
【発明の開示】
【発明が解決しようとする課題】
【0005】
上記の特許文献1に開示されている技術は、監査機関による通信内容の監査の必要性が生じた場合に、当該監査機関が、当該第三者機関から鍵を取得して、対応するユーザの通信内容を監査するため、鍵を取得した後も継続している暗号通信については、通信内容の監査を行うことができるものの、鍵を取得する前に行われていた暗号通信については、通信内容の監査を行うことができない。
【0006】
監査の有無によらず、全ての暗号通信を収集して保存しておくことも考えられるが、暗号通信に用いられる鍵は、生成されてからの時間の経過に応じて暗号強度が低下するため、所定のタイミングで更新される場合が多い。そのため、監査機関による通信内容の監査の必要性が生じた時点の鍵を取得しても、その鍵とは異なる鍵を用いて行われた過去の暗号通信の内容を監査することはできない。
【0007】
本発明は上記事情を鑑みてなされたものであり、本発明の目的は、任意の暗号通信の通信内容を、任意の時点で監査できるようにすることにある。
【課題を解決するための手段】
【0008】
上記課題を解決するために、本発明の通信内容監査支援システムは、暗号通信に用いられる鍵情報が生成される都度、当該鍵情報を鍵IDに対応付けて保存し、当該鍵情報を用いる暗号通信を行う通信装置のIPアドレスを、当該鍵IDに対応付けて保存し、暗号通信で送信される暗号パケットを、当該暗号パケットの送信元のIPアドレスおよび宛先のIPアドレスに対応付けて保存する。
【0009】
例えば、本発明の第1の態様は、複数の通信装置間で行われる暗号通信の監査に必要な情報を提供する通信内容監査支援システムであって、暗号通信に用いられる鍵情報が生成される都度、生成された鍵情報を、当該鍵情報を識別する鍵IDに対応付けて鍵管理DB(データベース)に格納する鍵管理手段と、暗号通信が確立する都度、当該暗号通信を行う複数の通信装置のそれぞれのIPアドレスを、当該暗号通信に用いられる鍵情報の鍵IDに対応付けて通信状態管理DBに格納する通信管理手段と、暗号通信において送信された暗号パケットの複製を取得し、取得した暗号パケットの複製を、当該暗号パケットの送信元のIPアドレスおよび宛先のIPアドレスに対応付けてパケットDBに格納するパケット取得手段と、ユーザからの検索指示に基づいて通信状態管理DBを参照し、当該検索指示で特定される暗号通信を行っていた通信装置のIPアドレスに対応する鍵IDを特定し、特定した鍵IDに対応する鍵情報を鍵管理DBから抽出すると共に、当該検索指示で特定される暗号パケットの複製をパケットDBから抽出し、抽出した鍵情報および暗号パケットの複製を出力する通信情報出力手段とを備えることを特徴とする通信内容監査支援システムを提供する。
【0010】
例えば、本発明の第2の態様は、複数の通信装置間で行われる暗号通信の監査に必要な情報を提供する通信内容監査支援システムであって、暗号通信に用いられる鍵情報が生成される都度、生成された鍵情報を、当該鍵情報を識別する鍵IDに対応付けて鍵管理DB(データベース)に格納する鍵管理手段と、暗号通信が確立した場合に、当該暗号通信を行う複数の通信装置のそれぞれに固有の情報である固有情報、当該複数の通信装置のそれぞれのIPアドレス、および、当該暗号通信の開始時刻を、当該暗号通信に用いられる鍵情報の鍵IDに対応付けて通信状態管理DBに格納し、当該暗号通信が終了した場合に、当該鍵情報を用いた暗号通信の終了時刻を当該鍵情報の鍵IDに対応付けて通信状態管理DBに格納する通信管理手段と、暗号通信において送信された暗号パケットの複製を取得し、取得した暗号パケットの複製を、当該暗号パケットの送信元のIPアドレスおよび宛先のIPアドレス、ならびに、当該暗号パケットの複製の取得時刻に対応付けてパケットDBに格納するパケット取得手段と、ユーザからの検索指示に基づいて通信状態管理DBを参照し、当該検索指示で特定される暗号通信を行っていた通信装置の固有情報、IPアドレス、暗号通信の開始時刻、および終了時刻に対応する鍵IDを特定し、特定した鍵IDに対応する鍵情報を鍵管理DBから抽出すると共に、当該検索指示で特定される暗号パケットの複製をパケットDBから抽出し、抽出した鍵情報および暗号パケットの複製を出力する通信情報出力手段とを備えることを特徴とする通信内容監査支援システムを提供する。
【発明の効果】
【0011】
本発明の通信内容監査支援システムによれば、任意の暗号通信の通信内容を、任意の時点で監査することができる。
【発明を実施するための最良の形態】
【0012】
以下、本発明の実施の形態を、図面を用いて詳細に説明する。
<実施例1>
本実施例1では、SIP(Session Initiation Protocol)を用いた通信システムに対して、本発明を適用した例について説明する。SIPはIETFのRFC3261に定義された、通信セッションの管理や制御を行う通信プロトコルである。なお、本発明の通信内容監査支援システムは、SIPに限らず、複数の通信装置間の通信を第三者の装置が確立させるような通信システムに対しても適用することができる。
【0013】
図1は、実施例1の通信内容監査支援システムのシステム構成図である。同図において、通信内容監査支援システムは、セッション管理装置100、鍵管理装置200、ユーザ端末300、サービス提供サーバ350、モニタリング機能付ルーティング装置400、パケットモニタ装置500、および監査装置600を備える。
【0014】
サービス提供サーバ350およびパケットモニタ装置500は、モニタリング機能付ルーティング装置400に接続される。モニタリング機能付ルーティング装置400は、インターネット等のネットワーク0に接続され、当該ネットワーク0を介して、セッション管理装置100、鍵管理装置200、ユーザ端末300、および監査装置600と通信する。
【0015】
なお、本実施例1において、ユーザ端末300やサービス提供サーバ350は、SIP-URI(Uniform Resource Identifier)と呼ばれる識別子によって一意に識別される。ユーザ端末300のSIP-URIは、ユーザ端末300の名前とセッション管理装置100の名前とを"@"で連結し、この文字列の先頭に"sip:"を付加した文字列で表現される。同様に、サービス提供サーバ350のSIP-URIは、サービス提供サーバ350の名前とセッション管理装置100の名前とを"@"で連結し、この文字列の先頭に"sip:"を付加した文字列で表現される。
【0016】
図1に示す例では、ユーザ端末300の名前が"user"であり、セッション管理装置100の名前が"domain.hitachi.co.jp"である場合、ユーザ端末300のSIP-URIは"sip:user @ domain.hitachi.co.jp "となる。同様に、サービス提供サーバ350の名前が"service"である場合、サービス提供サーバ350のSIP-URIは"sip:service@ domain.hitachi.co.jp "となる。しかしながら、SIP-URIの命名規則はこれに限定されない。例えば、ユーザ端末の名前ではなく、ユーザ端末を使用しているユーザの識別情報(ユーザ名)等を使用してもよい。
【0017】
また、本実施例1において、ユーザ端末300またはサービス提供サーバ350が自身のIPアドレスとSIP-URIをセッション管理装置100に対応付けてレジストラDBに保存させる処理を、ユーザ端末300またはサービス提供サーバ350がセッション管理装置100にログインすると定義する。
【0018】
次に、本実施例1における通信内容監査支援システムの各構成要素が備える機能について説明する。
【0019】
セッション管理装置100は、ユーザ端末300とサービス提供サーバ350との間の暗号通信を制御および管理する装置であり、通信状態管理DB(データベース)101、通信管理機能103、鍵取得機能104、メッセージ送受信機能105、およびセッション情報通知機能106を有する。鍵管理装置200は、鍵管理DB201、鍵管理機能202、および鍵送受信機能203を有する。パケットモニタ装置500は、パケットDB501、パケット受信機能502、パケット管理機能503、およびパケット送信機能504を備える。
【0020】
通信状態管理DB101は、セッション情報を登録するデータベースである。通信管理機能103は、ユーザ端末300とサービス提供サーバ350との間の暗号通信のセッション情報を通信状態管理DB101に登録したり、当該セッション情報を通信状態管理DB101から検索して取得したりする。鍵取得機能104は、ユーザ端末300とサービス提供サーバ350との間の暗号通信に使用される鍵情報を鍵管理装置200から取得したり、取得した鍵情報をメッセージ送受信機能105によって送信されるメッセージに記載したりする。メッセージ送受信機能105は、ユーザ端末300とサービス提供サーバ350との間でSIPメッセージを送信または受信する。セッション情報通知機能106は、セッション情報を監査装置600へ送信する。
【0021】
なお、本実施例1の鍵情報には、暗号通信に使用する鍵および当該鍵を一意に識別するための鍵ID、有効期間、および当該鍵を用いる暗号アルゴリズム名が含まれる。また、本実施例1のセッション情報には、暗号通信を一意に識別するためのセッションID、暗号通信に使用する鍵ID、暗号通信を行う通信装置の名前およびIPアドレス、ならびに、鍵の使用開始時刻および終了時刻が含まれる。また、本実施例において、セッションIDには、SIPメッセージに記載されたCall-IDフィールド内の文字列の"@"以前(左側)の部分が用いられる。
【0022】
鍵管理装置200は、ユーザ端末300とサービス提供サーバ350との間の暗号通信に使用する鍵の生成および管理を行う装置であり、鍵管理DB201、鍵管理機能202、および鍵送受信機能203を備える。
【0023】
鍵管理DB201は、鍵情報を登録するデータベースである。鍵管理機能202は、鍵情報を生成し、生成した鍵情報を鍵管理DB201に登録したり、鍵管理DB201内の鍵情報を検索して取得したりする。鍵送受信機能203は、鍵の取得要求または生成要求を受信し、鍵情報を要求元に送る。
【0024】
ユーザ端末300は、サービス提供サーバ350と暗号通信を行う装置であり、サービス提供サーバ350は、ユーザ端末300と暗号通信を行う装置である。ユーザ端末300およびサービス提供サーバ350は、鍵取得機能301、SIPクライアント機能302、暗号通信機能303、および状態管理機能304を備える。
【0025】
鍵取得機能301は、セッション管理装置100より受信したSIPメッセージから暗号通信に使用する鍵情報を取得し、取得した鍵情報の有効期限を監視したり、暗号通信終了後に、使用した鍵情報を削除したりする。SIPクライアント機能302は、セッション管理装置100を介して他のユーザ端末300もしくはサービス提供サーバ350と暗号通信を確立するためのSIP通信を行う。
【0026】
暗号通信機能303は、通信を確立している通信相手から暗号パケットを受信し、受信した暗号パケットの復号を行ったり、パケットを暗号化して通信を確立している通信相手へ送信したりする。状態管理機能304は、SIPクライアント機能302が管理する、自装置と通信相手の装置の内部状態を管理する。
【0027】
なお、本実施例では、ユーザ端末300内の状態管理機能304は、内部状態をユーザ端末300に接続されている画面に表示し、サービス提供サーバ350内の状態管理機能304は、内部状態をイベントログとして出力する。
【0028】
モニタリング機能付ルーティング装置400は、ユーザ端末300とサービス提供サーバ350との間で送信または受信された暗号パケットを受信し、受信した暗号パケットを複製し、受信した暗号パケットを本来の宛先へ送信すると共に、複製した暗号パケットをパケットモニタ装置500へ送信するパケット制御機能401を備える。
【0029】
パケットモニタ装置500は、パケットDB501、パケット受信機能502、パケット管理機能503、およびパケット送信機能504を備える。パケットDB501は、モニタリング機能付ルーティング装置400から受信した暗号パケットを、当該暗号パケットの送信元および宛先に対応付けて格納するデータベースである。パケット受信機能502は、モニタリング機能付ルーティング装置400から暗号パケットを受信する。
【0030】
パケット管理機能503は、パケット受信機能502が受信した暗号パケットをパケットDB501に格納したり、監査装置600から要求された暗号パケットをパケットDB501から検索して取得したりする。パケット送信機能504は、パケット管理機能503によってパケットDB501から取得された暗号パケットを監査装置600へ送る。
【0031】
監査装置600は、ユーザ端末300とサービス提供サーバ350との間の暗号通信で送信または受信された通信内容を監査する装置であり、鍵取得機能601、セッション情報取得機能602、パケット取得・復号機能603、および監査アプリケーション604を備える。
【0032】
鍵取得機能601は、ユーザ端末300とサービス提供サーバ350との間の暗号通信で使用された鍵を鍵管理装置200から取得する。セッション情報取得機能602は、セッション情報の一覧をセッション管理装置100から取得する。パケット取得・復号機能603は、暗号パケットをパケットモニタ装置500から取得し、鍵管理装置200から取得した鍵を用いて当該暗号パケットを復号する。監査アプリケーション604は、復号されたパケットを用いてユーザ端末300とサービス提供サーバ350との間の暗号通信の内容を監査する。
【0033】
なお、本実施例1が適用された通信内容監査支援システムは、ユーザ端末300とサービス提供サーバ350との間で通信を行うクライアント/サーバ通信の監査だけでなく、サービス提供サーバ350同士が通信を行う場合の監査にも適用可能である。更には、本実施例1ではサービス提供サーバ350をモニタリング機能付ルーティング装置400に接続する構成にしているが、本発明はこれに限られない。
【0034】
例えば、ユーザ端末300をモニタリング機能付ルーティング装置400に接続するように構成してもよい。その場合、図1のシステム構成においてサービス提供サーバ350をユーザ端末300に置き換えることにより、ネットワーク0に直接接続されているユーザ端末300やサービス提供サーバ350と暗号通信を行う場合にも通信内容監査支援システムを適用することができる。そして、モニタリング機能付ルーティング装置400に接続されているユーザ端末300に着目して暗号通信の通信内容の監査が行われる。
【0035】
その他、ネットワーク0は、企業内LANのようなプライベートネットワークに限らず、インターネットのようなオープンネットワークでも良い。更に、モニタリング機能付ルーティング装置400は、スイッチング機能を持たないリピータハブ、ミラーリングポート機能を有するスイッチングハブ、ルータ、ファイアウォール、プロキシサーバに代表される、通信を中継する機能を持った装置であれば、いずれでも良い。例えば、ファイアウォールをモニタリング機能付ルーティング装置400とする場合には、ファイアウォールを介して行われる組織内部と組織外部の間の通信を監査することができるようになる。
【0036】
また、通信状態管理DB101は、本実施例1のようにセッション管理装置100内に含まれる装置として構成されることが可能であるが、セッション管理装置100とは別の装置内に設け、当該装置とセッション管理装置100とをネットワークで接続するようにしてもよい。同様に、鍵管理DB201は、鍵管理装置200とは別の装置内に設けられてもよい。さらに、パケットDB501は、パケットモニタ装置500とは別の装置内に設けられてもよい。
【0037】
また、本実施例1において、セッション管理装置100、鍵管理装置200、パケットモニタ装置500、および監査装置600は、図1のように異なる装置によって実現されているが、本実施例はこれに限られない。鍵管理装置200とセッション管理装置100とを一つの装置として構成したり、監査装置600とセッション管理装置100とを一つの装置として構成したり、パケットモニタ装置500と監査装置600とを一つの装置として構成したりしてもよい。
【0038】
図2は、セッション管理装置100、鍵管理装置200、ユーザ端末300、サービス提供サーバ350、パケットモニタ装置500、または監査装置600の機能を実現する情報処理装置の構成を例示する。
【0039】
情報処理装置は、CPU(Central Processing Unit)11、メモリ12、通信処理装置13、入力装置14、出力装置15、読取装置16、および外部記憶装置17を備える。これらは、バス10を介して互いに接続されている。
【0040】
通信処理装置13は、インターネットやLANを介して他の通信装置と通信を行う。入力装置14は、例えばキーボードやマウス等である。出力装置15は、例えばモニタやプリンタ等である。読取装置16は、ICカードやUSBメモリ等の可搬性を有する記録媒体18内のデータを読み込む。外部記憶装置17は、例えばハードディスク等である。
【0041】
本実施例1における、セッション管理装置100、鍵管理装置200、ユーザ端末300、サービス提供サーバ350、パケットモニタ装置500、または監査装置600内の各機能は、これらの機能を実現するプログラムがメモリ12上にロードされ、CPU11によって実行されることにより具現化される。
【0042】
これらのプログラムは、予め上記情報処理装置の外部記憶装置17内に格納されていてもよいし、必要なときに、読取装置16または通信処理装置13によって、当該情報処理装置が利用可能な媒体を介して、他の装置から取得されて外部記憶装置17内に格納されてもよい。媒体とは、例えば、読取装置16に着脱可能な記録媒体18、または通信処理装置13に接続可能なネットワーク0または当該ネットワーク0を伝搬する搬送波やディジタル信号を指す。
【0043】
そして、プログラムは一旦外部記憶装置17内に格納された後、そこからメモリ12上にロードされてCPU11によって実行されてもよいし、あるいは外部記憶装置17内に格納されることなく、直接メモリ12上にロードされて、CPU11によって実行されてもよい。また、通信状態管理DB101、鍵管理DB201、またはパケットDB501は、メモリ12が外部記憶装置17を利用することにより実現される。
【0044】
次に、本実施例1において、SIPを用いた通信内容監査支援システムの動作について説明する。なお、ユーザ端末300およびサービス提供サーバ350がセッション管理装置100にログインする動作は、通常のSIPを用いたシステムの動作(例えばレジストレーション)と同じであるため、説明を省略している。
【0045】
ユーザ端末300およびサービス提供サーバ350がセッション管理装置100にログインすることにより、セッション管理装置100は、ユーザ端末300とサービス提供サーバ350のSIP-URIとIPアドレスとを対応付けてメモリ12に保存する。また、セッション管理装置100へのログインにより、ユーザ端末300とサービス提供サーバ350との間で暗号通信の確立が可能となり、同時に鍵管理装置200がユーザ端末300とサービス提供サーバ350との間の暗号通信に使用する鍵を管理することが可能となる。そして、監査装置600が暗号パケットおよび暗号通信に使用する鍵を取得して、パケットを復号することでユーザ端末300とサービス提供サーバ350との間の暗号通信の通信内容を監査できるようになる。
【0046】
まず、ユーザ端末300がセッション管理装置100を介して、サービス提供サーバ350と暗号通信に使用する鍵を共有し、暗号通信を開始する一連の動作シーケンスを図3から図5を用いて説明する。
【0047】
ユーザ端末300の利用者は、状態管理機能304のGUI画面を見てユーザ端末300の内部状態がログイン済状態であることを確認すると、サービス提供サーバ350との間の暗号通信処理の開始をユーザ端末300へ指示する。そして、ユーザ端末300のSIPクライアント機能302は、サービス提供サーバ350への通信開始要求2000を作成してセッション管理装置100へ送信する(ステップS101)。本実施例1において、SIPクライアント機能302は、例えば図10(a)に示すように、SIPで定義されているINVITEのリクエストメッセージを通信開始要求2000として生成する。
【0048】
セッション管理装置100のメッセージ送受信機能105は、ユーザ端末300から鍵管理装置200を受信すると(ステップS102)、鍵取得機能104は、通信開始要求2000のFromフィールドに記載されているユーザ端末300のSIP-URI、および、Toフィールドに記載されているサービス提供サーバ350のSIP-URIを記載した鍵生成要求2200を作成し、生成した鍵生成要求2200を鍵管理装置200へ送信する(ステップS103)。
【0049】
本実施例1では、鍵生成要求2200は、例えば図12(a)XMLメッセージのgenKeyRequestタグとして記述される。図12(a)は、セッション管理装置100が鍵管理装置200へ送信する鍵生成要求2200のうち、本実施例の説明に必要な部分のみを示している。送信元であるユーザ端末300のSIP-URIがfromタグに記載され、宛先であるサービス提供サーバ350のSIP-URIがtoタグに記載される。
【0050】
鍵管理装置200の鍵送受信機能203は、セッション管理装置100から鍵生成要求2200を受信すると(ステップS104)、鍵管理機能202は、鍵情報3000を生成し(ステップS105)、そのうち鍵ID、鍵、使用する暗号アルゴリズム名を鍵管理DB201に登録する(ステップS106)。
【0051】
本実施例1では、例えば図13に示すように、鍵管理DB201は、鍵ID、暗号アルゴリズム、および鍵を有する各レコードを格納する。鍵管理DB201には、監査装置600が鍵を取得するために最低限必要な情報が格納される。なお、鍵管理DB201内の暗号アルゴリズムの欄には、鍵のビット数や暗号アルゴリズムのバージョン等も格納される。
【0052】
まず、図13(a)は、ステップS106を実行する前において、鍵IDが「12345678」であり、暗号アルゴリズムがAES-256bitである鍵が登録されている様子を示している。図13(b)は、ステップS106が実行されることにより、鍵IDが「12345679」であり、暗号アルゴリズムがAES-256bitである鍵が作成され、鍵管理DB201に追加登録された様子を示している。
【0053】
図3に戻って説明を続ける。鍵送受信機能203は、鍵生成応答2300を作成し、ステップS105で生成された鍵情報3000を添付してセッション管理装置100へ送信する(ステップS107)。
【0054】
本実施例1では、鍵生成応答2300は、例えば図12(b)に示すように、XMLメッセージのgenKeyResponseタグとして記述される。図12(b)は、鍵管理装置200がセッション管理装置100へ送信する鍵生成応答2300のうち、本実施例の説明に必要な部分のみを示している。statusタグ要素には、ユーザ端末300とサービス提供サーバ350との間の暗号通信に使用する鍵ID、鍵、および使用する暗号アルゴリズム名を、鍵管理装置200が鍵管理DB201に登録した結果が記載される。
【0055】
登録成功の場合、鍵生成応答2300のstatusタグ要素には"OK"と記載され、登録失敗の場合には"NG"と記載される。また、鍵生成要求の送信元であるユーザ端末300のSIP-URIがfromタグ要素に記載され、宛先であるサービス提供サーバ350のSIP-URIがtoタグ要素に記載される。更に、生成された鍵情報3000がXML形式で記載される。
【0056】
鍵情報3000は、XML形式を用いてsessionKeyInfoタグで表現される。鍵情報3000には、例えば図12(c)に示すように、ユーザ端末300とサービス提供サーバ350との間の暗号通信に使用される鍵IDが記載されるkeyIDタグ、データの暗号化に使用されるアルゴリズム名が記載されるencタグ、鍵の有効期間が記載されるlifetimeタグ、および、鍵が記載されるkeyタグが記載される。なお、本実施例1において、lifetimeタグに記載される数値は秒を単位の時間を示す。
【0057】
セッション管理装置100の鍵取得機能104は、ステップS107において鍵管理装置200から送信された鍵生成応答2300を受信すると(図3のステップS108)、通信開始要求2000のCall-IDフィールドに記載されているセッションIDに対応付けて鍵情報3000をメモリ12に保存し、当該鍵情報3000を、図10(a)に示す通信開始要求2000のBODY部に記載する(ステップS109)。そして、メッセージ送受信機能105は、通信開始要求2000をサービス提供サーバ350へ送信する(ステップS110)。
【0058】
なお、ステップS110以降において送信または受信される通信開始要求2000は、図10(a)に示す通信開始要求2000のBODY部にXML形式で記述された鍵情報3000が記載されたものである。
【0059】
サービス提供サーバ350のSIPクライアント機能302は、セッション管理装置100から通信開始要求2000を受信すると(ステップS111)、受信した通信開始要求2000の内容を調べ、ユーザ端末300との通信可否を判定する(ステップS112)。ユーザ端末300との間の暗号通信を拒否する場合、サービス提供サーバ350のSIPクライアント機能302は、通信を拒否する旨を示すメッセージを含む通信開始応答2100を作成してセッション管理装置100へ返信する(ステップS115)。そして、状態管理機能304は、ユーザ端末300からの通信を拒否した旨をイベントログに出力する。サービス提供サーバ350の管理者は、イベントログを確認することで、ユーザ端末300との間の暗号通信を拒否したことを認識することができる。
【0060】
なお、本実施例1において、上記通信を拒否する旨を示すメッセージには、SIPで定義されているINVITEレスポンスの401 Unauthorizedメッセージが用いられる。
【0061】
一方、ステップS112において、ユーザ端末300との間の暗号通信を許可する場合、サービス提供サーバ350の鍵取得機能301は、通信開始要求2000のBODY部に記載されている鍵情報3000を取得し(ステップS113)、通信開始要求2000のCall-IDフィールドに記載されているセッションIDと対応付けてメモリ12に保存する。
【0062】
そして、SIPクライアント機能302は、通信を許可する旨を示すメッセージを含む通信開始応答2100を作成してセッション管理装置100へ返信する(ステップS114)。そして、状態管理機能304は、内部状態を暗号通信状態へ遷移させると共に、ユーザ端末300との間の暗号通信を開始した旨をイベントログに出力する。サービス提供サーバ350の管理者は、イベントログを確認することで、ユーザ端末300との間の暗号通信開始処理が正常に行われたことを認識することができる。
【0063】
なお、本実施例1では、上記通信を許可する旨を示すメッセージを含む通信開始応答2100には、例えば図10(b)に示すように、SIPで定義されているINVITEレスポンスの200 OKメッセージが用いられる。
【0064】
ステップS114またはステップS115の後に、セッション管理装置100のメッセージ送受信機能105は、サービス提供サーバ350から通信開始応答2100を受信し(ステップS116)、通信開始応答2100の内容を調べ、ユーザ端末300のサービス提供サーバ350に対する通信開始要求2000が許可されたか否かを判定する(ステップS117)。
【0065】
通信開始応答2100が通信を拒否する旨を示すメッセージを含む場合、セッション管理装置100の鍵取得機能104は、メモリ12に保存されている鍵情報3000から鍵IDを取出して、鍵削除要求2600を作成し、作成した鍵削除要求2600を鍵管理装置200へ送信する(ステップS122)。
【0066】
本実施例1では、鍵削除要求2600は、例えば図12(d)に示すように、XMLメッセージのdelKeyRequestタグとして記述される。図12(d)は、セッション管理装置100が鍵管理装置200へ送信する鍵削除要求2600のうち、本実施例の説明に必要な部分のみを示している。鍵削除要求2600には、sessionIDタグおよびkeyIDタグが記載される。sessionIDタグ内には、通信開始応答2100に記載されたCall-IDフィールド内の文字列の"@"以前(左側)の部分が記載される。また、keyIDタグ内には、鍵情報3000のkeyIDタグ内の情報がそのまま記載される。
【0067】
鍵管理装置200の鍵送受信機能203が、セッション管理装置100から鍵削除要求2600を受信すると(ステップS123)、鍵管理機能202は、鍵削除要求2600のkeyIDタグに記載されている鍵IDを鍵管理DB201から削除することにより、鍵IDを失効する(ステップS124)。その後、鍵送受信機能203は、鍵削除応答2700を作成してセッション管理装置100へ送信する(ステップS125)。
【0068】
これにより、鍵管理DB201内に格納されている情報は、例えば図13(b)から(c)のように更新される。なお、ステップS124において、鍵管理機能202は、鍵IDに加えて、対応する暗号アルゴリズムおよび鍵を鍵管理DB201から削除するようにしてもよい。
【0069】
なお、本実施例1において、鍵削除応答2700は、XMLメッセージのdelKeyResponseタグとして記述される。図12(e)は、鍵管理装置200がセッション管理装置100へ送信する鍵削除応答2700のうち、本実施例の説明に必要な部分のみが示されている。鍵削除応答2700には、sessionIDタグおよびstatusタグが記載される。鍵管理機能202によって鍵管理DB201から鍵ID、鍵、暗号アルゴリズム名を削除された結果が、statusタグに記載される。削除成功の場合にはstatusタグに"OK"と記載され、削除失敗の場合には"NG"と記載される。
【0070】
セッション管理装置100の鍵取得機能104は、鍵管理装置200から送信された鍵削除応答2700を受信すると(ステップS126)、メモリ12に保存していたセッションIDと鍵情報を削除し、メッセージ送受信機能105は、通信開始応答2100を作成してユーザ端末300へ送信する(ステップS127)。
【0071】
一方、図4のステップS117の後、通信開始応答2100が通信を許可する旨のメッセージを含む場合、セッション管理装置100の通信管理機能103は、通信開始応答2100のCall-IDフィールドに記載されているセッションIDをキーに、通信状態管理DB101のセッションIDレコードを検索する(ステップS118)。なお、本実例1において、通信管理機能103は、暗号通信の相手の通信装置から暗号通信を許可する旨のメッセージを受信した場合に、暗号通信が確立したものと判定する。
【0072】
本実施例1において、通信状態管理DB101は、例えば図11に示すように、鍵ID、通信の開始を要求した通信装置を示す通信装置1、通信装置1の通信相手である通信装置2、通信の開始時刻、通信の終了時刻、および暗号アルゴリズムを、セッションIDに対応付けて格納する。本実施例1において、図3のステップS118を実行する前の時点では、通信状態管理DB101内には、例えば図11の(a)に示すような情報が格納されているものと仮定する。
【0073】
通信状態管理DB101を参照することにより、例えば通信の管理者はどのような通信が行われているかを把握したり、また、決められた暗号アルゴリズムを使用して暗号通信を行っているかといった通信ポリシを一元的にチェックしたりすることができる。また、本実施例1において、通信状態管理DB101には、暗号通信を行う通信装置のIPアドレスだけでなく、暗号通信が行われた時間帯が鍵IDに対応付けられているので、IPアドレスの割り当てがDHCP(Dynamic Host Configuration Protocol)等により動的に変更される場合であっても、特定の時間帯におけるIPアドレスによって、通信装置を一意に特定することができる。
【0074】
ステップS116において受信した通信開始応答2100のCall-IDフィールドに記載されているセッションID(本実施例1では「f4yh79bn6o」)が通信状態管理DB101のセッションIDレコードに記載されていないので、通信管理機能103は、ユーザ端末300とサービス提供サーバ350との間の暗号通信が新規の通信であると判断する(ステップS119)。
【0075】
そして、通信管理機能103は、セッションIDを通信状態管理DB101のセッションIDレコードに書き込み、メモリ12に保存されている鍵情報3000のkeyIDタグに記載された鍵IDを鍵IDレコードに書き込み、通信開始応答2100のFromフィールドに記載されたユーザ端末300の名前をメモリ12に保存しているユーザ端末300のSIP-URIと対応付けて通信装置1レコードに書き込み、通信開始応答2100のToフィールドに記載されたサービス提供サーバ350の名前をメモリ12に保存しているサービス提供サーバ350のSIP-URIと対応付けて通信装置2レコードに書き込み、現在の時刻を開始時刻レコードに書き込み、鍵情報3000のencタグに記載された暗号アルゴリズム名を暗号アルゴリズムレコードに書き込む(ステップS121)。これにより、通信状態管理DB101に格納されている情報は、例えば図11(b)に示すようになる。
【0076】
その後、鍵取得機能104は、メモリ12に保存されている鍵情報3000を取り出し、図10(b)に示す通信開始応答2100のBODY部に記載すると、メモリ12に保存していたセッションIDと鍵情報3000を削除する。そして、メッセージ送受信機能105は、入力装置14によって作成された通信開始応答2100をユーザ端末300へ送信する(ステップS127)。
【0077】
ユーザ端末300のSIPクライアント機能302は、セッション管理装置100から通信開始応答2100を受信すると(ステップS128)、受信した通信開始応答2100の内容を確認する(ステップS129)。通信開始応答2100が通信を拒否する旨を示すメッセージを含む場合、ユーザ端末300の状態管理機能304は、GUI画面にサービス提供サーバ350への通信が拒否された旨を表示する。ユーザ端末300の利用者は、GUI画面を確認することで、サービス提供サーバ350との間の暗号通信が拒否されたことを認識することができる。
【0078】
通信開始応答2100が通信を許可する旨を示すメッセージを含む場合、ユーザ端末300の鍵取得機能301は、通信開始応答2100のBODY部に記載されている鍵情報3000を取得し(ステップS130)、通信開始応答2100のCall-IDフィールドに記載されたセッションIDと対応付けてメモリ12に保存する。そして、状態管理機能304は、内部状態を暗号通信状態へと遷移させると共に、GUI画面にサービス提供サーバ350との間の暗号通信が開始された旨を表示する。ユーザ端末300の利用者は、GUI画面を確認することで、サービス提供サーバ350との間の暗号通信開始処理が正常に行われたことを認識することができる。
【0079】
そして、ユーザ端末300とサービス提供サーバ350とは、セッション管理装置100を介することなく、取得した鍵情報3000を用いて、暗号通信を開始する。
【0080】
以上が本実施例1において、ユーザ端末300がセッション管理装置100を介して、サービス提供サーバ350と暗号通信に使用する鍵情報3000を共有し、暗号通信を開始する動作シーケンスである。
【0081】
また、ユーザ端末300とサービス提供サーバ350との間で共有された鍵の有効期限が切れ、その契機で鍵更新を行う一連の動作については、図4のステップS118の後の動作以外は、暗号通信開始の動作シーケンスと同一である。ただし、鍵更新のシーケンスでは、サービス提供サーバ350は、常に暗号通信を許可する。すなわち、通信開始応答2100には通信を許可する旨を示すメッセージが含まれるため、セッション管理装置100の通信管理機能103は、ステップS117の後に、ステップS118を実行する。
【0082】
そして、通信管理機能103は、ステップS118において、通信開始応答2100のCall-IDフィールドに対応するセッションIDが記載され、かつ、終了時刻レコードに何も記載されていない行を通信状態管理DB101から検索する。ステップS118を実行する前の時点では、通信状態管理DB101に格納されている情報は、例えば図11(b)のようになっているので、通信管理機能103は、2行目のセッションIDレコードに検索しているセッションIDが記載され、終了時刻レコードに何も記載されていない行が存在することを検知する(ステップS119)。
【0083】
そして、通信管理機能103は、通信状態管理DB101の2行目の終了時刻レコードに現在の時刻を入力し(ステップS120)、空白行になっている3行目にセッションID、更新した鍵ID、ユーザ端末300の名前、サービス提供サーバ350の名前、開始時刻(現在の時刻)、および暗号アルゴリズムの各情報を書き込む(ステップS121)。これにより、通信状態管理DB101に格納されている情報は、例えば図11(c)のようになる。
【0084】
その後、ステップS127以降の処理が実行され、ユーザ端末300およびサービス提供サーバ350は、セッション管理装置100を介することなく、取得した鍵情報3000を用いて暗号通信を継続する。
【0085】
以上が本実施例1において、ユーザ端末300とサービス提供サーバ350との間で共有された鍵の有効期限が切れ、その契機で鍵更新を行う場合の動作シーケンスである。なお、このシーケンスについては、サービス提供サーバ350からユーザ端末300に対する通信開始要求2000をセッション管理装置100へ送信することも可能である。この場合、図3においてユーザ端末300とサービス提供サーバ350の立場が入れ替わるだけで、それ以外にシーケンスの変更はない。また、鍵の有効期限が切れたことを契機とするのではなく、鍵の有効期限が近づいたことを契機としてもよい。
【0086】
次に、ユーザ端末300が、セッション管理装置100を介して、サービス提供サーバ350との間の暗号通信を終了する一連の動作シーケンスを、図6を用いて説明する。
【0087】
ユーザ端末300の利用者は、状態管理機能304のGUI画面を参照して、ユーザ端末300の内部状態が暗号通信状態であることを確認し、暗号通信を終了する場合には、サービス提供サーバ350との間の暗号通信処理の終了をユーザ端末300へ指示する。ユーザ端末300のSIPクライアント機能302は、サービス提供サーバ350への通信終了要求2400を作成し、セッション管理装置100へ送信する(ステップS131)。本実施例1では、通信終了要求2400には、例えば図10(c)に示すように、SIPで定義されているBYEリクエストメッセージが利用される。
【0088】
セッション管理装置100のメッセージ送受信機能105は、ユーザ端末300から通信終了要求2400を受信すると(ステップS132)、サービス提供サーバ350に通信終了要求2400を送信する(ステップS133)。サービス提供サーバ350のSIPクライアント機能302は、セッション管理装置100から通信終了要求2400を受信し(ステップS134)、鍵取得機能301は、通信終了要求2400のCall-IDフィールドに記載されているセッションIDおよび鍵情報3000をメモリ12から削除する(ステップS135)。
【0089】
そして、SIPクライアント機能302は、通信終了応答2500を作成して、セッション管理装置100へ返信する(ステップS136)。そして、状態管理機能304は、内部状態を通信開始前状態へ遷移させると共に、ユーザ端末300との間の暗号通信に使用した鍵情報3000を削除した旨、および、暗号通信を終了した旨をイベントログへ出力する。サービス提供サーバ350の管理者は、イベントログを確認することで、ユーザ端末300との間の暗号通信終了処理が正常に行われたことを認識する。
【0090】
なお、本実施例1において、通信終了応答2500には、例えば図10(d)に示すように、SIPで定義されているBYEレスポンスメッセージが利用される。
【0091】
セッション管理装置100のメッセージ送受信機能105がサービス提供サーバ350から通信終了応答2500を受信すると(図6のステップS137)、通信管理機能103は、通信終了応答2500のCall-IDフィールドに記載されているセッションIDが記載され、かつ、終了時刻が記載されていない行を、通信状態管理DB101から検索する。この時点では、通信状態管理DB101に格納されている情報は、例えば図11(c)のようになっているので、通信管理機能103は、図11(c)の3行目を検索対象の行として検出する。
【0092】
そして、通信管理機能103は、ユーザ端末300とサービス提供サーバ350との間の暗号通信が終了したと判断し、通信状態管理DB101の3行目の終了時刻レコードに現在の時刻を入力する(ステップS138)。これにより、通信状態管理DB101に格納されている情報は、例えば図11(d)のようになる。その後、メッセージ送受信機能105は、通信終了応答2500をユーザ端末300へ送信する(ステップS139)。
【0093】
ユーザ端末300のSIPクライアント機能302は、セッション管理装置100から通信終了応答2500を受信し(ステップS140)、鍵取得機能301は、通信終了要求2400のCall-IDフィールドに記載したセッションIDおよび鍵情報3000をメモリ12から削除する(ステップS141)。そして、状態管理機能304は、内部状態を通信開始前状態へ遷移させると共に、GUI画面にサービス提供サーバ350との間の暗号通信に使用した鍵情報3000を削除した旨、および、暗号通信を終了した旨を表示する。ユーザ端末300の利用者は、GUI画面を確認することで、サービス提供サーバ350との間の暗号通信終了処理が正常に行われたことを認識することができる。
【0094】
以上が、ユーザ端末300がセッション管理装置100を介して、サービス提供サーバ350との間の暗号通信を終了する場合の動作シーケンスである。なお、このシーケンスについては、サービス提供サーバ350からセッション管理装置100を介してユーザ端末300へ通信終了要求2400を送信することも可能である。この場合、図6において、ユーザ端末300とサービス提供サーバ350の立場が入れ替わるだけで、それ以外にシーケンスの変更はない。また、鍵の有効期限が近づいたことを契機として鍵の更新を行う場合には、鍵の有効期限が切れたことを契機として一連の動作を実行してもよい。
【0095】
次に、暗号通信開始後、ユーザ端末300とサービス提供サーバ350との間で暗号パケットを送信または受信する場合の一連の動作シーケンスを、図7を用いて説明する。なお、図7では、暗号パケットがユーザ端末300からサービス提供サーバ350へ送信される例のみ説明する。
【0096】
内部状態が暗号通信状態であるユーザ端末300は、サービス提供サーバ350へ暗号パケットを送信する(ステップS142)。モニタリング機能付ルーティング装置400のパケット制御機能401は、ユーザ端末300から送信された暗号パケットを受信し(ステップS143)、受信した暗号パケットを複製して(ステップS144)、サービス提供サーバ350とパケットモニタ装置500にそれぞれ送信する(ステップS145およびS147)。
【0097】
サービス提供サーバ350は、ステップS145において、モニタリング機能付ルーティング装置400から送信された暗号パケットを受信し(ステップS146)、メモリ12に保存していた鍵情報3000を用いて暗号パケットを復号する。
【0098】
パケットモニタ装置500は、ステップS147においてモニタリング機能付ルーティング装置400から送信された暗号パケットを受信し(ステップS148)、図15(e)に示す暗号パケットのヘッダ領域に格納された情報を調べる。そして、パケットモニタ装置500は、送信元のIPアドレスと宛先のIPアドレスを確認し、パケットDB501のパケット格納場所レコードに記載された場所へ保存する(ステップS149)。
【0099】
本実施例1では、パケットDB501は、暗号通信を行う送信元の通信装置のIPアドレスおよび宛先の通信装置のIPアドレスの組み合わせ毎に、当該組み合わせの通信装置同士において送信された暗号パケットの格納場所を示すテーブルを持っており、パケット管理機能503は、受信した暗号パケットのヘッダ情報に基づいて当該テーブルを参照し、当該暗号パケットを、格納すべき格納場所へ格納する。
【0100】
例えば、ユーザ端末300からサービス提供サーバ350へ送信された暗号パケットのヘッダ領域に、送信元の通信装置(ユーザ端末300)のIPアドレスとして192.168.10.1が格納され、宛先の通信装置(サービス提供サーバ350)のIPアドレスとして192.168.20.1が格納されている場合、図15(a)に示す例では、パケット管理機能503は、当該暗号パケットを、/var/audit/packet/0000120060401/で識別されるディレクトリに保存する。
【0101】
パケット管理機能503は、例えば、送信元の通信装置のIPアドレスと宛先の通信装置のIPアドレスの組み合わせを識別する文字列(例えば5桁の番号)と日付を示す文字列とを組み合わせた識別情報で識別されるディレクトリを生成し、送信元と宛先のIPアドレスの組み合わせが同一の暗号パケットが同一の日に送信された場合には、当該暗号パケットを同一のディレクトリに格納する。
【0102】
以上が、ユーザ端末300とサービス提供サーバ350との間で暗号パケットが送信または受信される場合の動作シーケンスである。なお、このシーケンスについては、サービス提供サーバ350がユーザ端末300に対して暗号パケットを送信することも可能である。この場合、図7においてユーザ端末300とサービス提供サーバ350の立場が入れ替わるだけで、それ以外にシーケンスの変更はない。また、S149において、パケットモニタ装置500は、サービス提供サーバ350がユーザ端末300へ送信した暗号パケットを受信すると、これをパケットDB501の/var/audit/packet/0000220060401/で識別されるディレクトリに保存する。
【0103】
次に、暗号通信終了後に監査装置600がパケットDB501に保存されている暗号パケットを取得し、復号を行うことによりパケットの内容を監査する一連の動作シーケンスについて、図8および図9を用いて説明する。
【0104】
監査装置600を利用する監査者は、監査したい通信のセッション情報をセッション管理装置100から取得するため、監査装置600の監査アプリケーション604が表示しているセッション情報検索画面3400(図16(a)参照)へ検索キーを入力する。監査アプリケーション604は、入力された検索キーを読み込む(S150)。
【0105】
本実施例1において、監査者は、セッション情報検索画面3400に入力する検索キーとして、暗号通信を行う送信元の通信装置の名前、宛先の通信装置の名前、および暗号パケットの送信時刻の範囲を入力し、暗号通信に用いられている暗号アルゴリズム名を指定するものとする。図16(a)に示す例では、"user"という名前の通信装置が、"service"という名前の通信装置に対して、2006年4月1日の11:00以降に送信された暗号パケットが指定されている。
【0106】
なお、通信装置の名前および通信時刻の範囲を指定する各項目は空白でも構わない。その場合、検索キーが入力されなかった項目については条件指定が無かったものと判定される。また、全ての検索キーが空白の場合、監査アプリケーション604は、過去に行われた全ての通信を監査対象としてセッション情報を検索する。
【0107】
監査装置600のセッション情報取得機能602は、セッション情報検索画面3400に入力された検索キーをメモリ12に保存する。そして、セッション情報取得機能602は、セッション情報一覧取得要求2800を作成してセッション管理装置100へ送信する(ステップS151)。
【0108】
本実施例1において、セッション情報一覧取得要求2800は、XMLメッセージのgetSessionInfoRequestタグとして記述される。図14(a)は、監査装置600からセッション管理装置100へ送信されるセッション情報一覧取得要求2800のうち、本実施例の説明に必要な部分のみを示している。セッション情報検索画面3400には、検索キーとして入力された情報が記載される。セッション情報検索画面3400の「送信元の通信装置の名前」および「宛先の通信装置の名前」の項目に入力された検索キーは、それぞれfromタグおよびtoタグに記載される。
【0109】
また、「通信時刻の範囲」の項目に入力された検索キーは、startタグとendタグに記載される。また、指定された暗号アルゴリズム名は、encタグに記載される。なお、セッション情報検索画面3400に検索キーが入力されていない項目については、対応するセッション情報一覧取得要求2800のタグに"null"が記載される。
【0110】
セッション管理装置100のセッション情報通知機能106は、監査装置600からセッション情報一覧取得要求2800を受信すると(ステップS152)、通信管理機能103は、セッション情報一覧取得要求2800のfromタグに記載されたユーザ端末300の名前、toタグに記載されたサービス提供サーバ350の名前、startタグに記載された時刻、endタグに記載された時刻、およびencタグに記載された暗号アルゴリズム名を基にして、監査対象の通信のセッション情報について通信状態管理DB101を検索する(ステップS153)。
【0111】
この時点では、通信状態管理DB101に格納されている情報は、例えば図11(d)のようになっているので、通信管理機能103は、図11(d)に示した例において、2行目と3行目に記載された各レコードの情報を取得する。そして、セッション情報通知機能106は、通信管理機能103が取得した各情報からセッション情報3100を作成する。本実施例において、セッション情報通知機能106は、鍵IDが「12345679」であるセッション情報3100と、鍵IDが「12345680」であるセッション情報3100とを記載したセッション情報一覧取得応答2900を作成し、監査装置600へ送信する(ステップS154)。
【0112】
本実施例1において、セッション情報一覧取得応答2900は、例えば、XMLメッセージのgetSessionInfoResponseタグとして記述される。図14(b)は、セッション管理装置100から監査装置600へ送信されるセッション情報一覧取得応答2900のうち、本実施例の説明に必要な部分のみを示している。セッション管理装置100によるセッション情報の検索結果がstatusタグに記載される。
【0113】
セッション情報通知機能106は、検索の結果、セッション情報一覧取得要求2800の条件に合致した通信のセッション情報が見つかった場合には、statusタグに"OK"と記載し、見つからなかった場合には"NG"と記載する。また、作成したセッション情報3100は例えばXML形式で記載される。なお、1つのセッションにおいて複数の鍵が用いられている場合には、セッション情報一覧取得応答2900には、複数のセッション情報3100が記載されてもよい。
【0114】
セッション情報3100は、例えばXML形式のsessionInfoタグとして表現される。セッション情報3100には、例えば図14(c)に示すように、通信状態管理DB101から取得されたセッションIDが記載されるsessionIDタグ、鍵IDが記載されるkeyIDタグ、セッション管理装置100のメモリ12に保存されている送信元の通信装置の名前が記載されるterm1タグ、当該通信装置のIPアドレスが記載されるaddr1タグ、当該通信装置の通信相手の名前が記載されるterm2タグ、当該通信相手のIPアドレスが記載されるaddr2タグ、通信開始時刻が記載されるstartタグ、通信終了時刻が記載されるendタグ、および、使用される暗号アルゴリズム名が記載されるencタグが記載される。
【0115】
監査装置600のセッション情報取得機能602は、セッション管理装置100からセッション情報一覧取得応答2900を受信すると(ステップS155)、監査アプリケーション604は、内部状態を監査前状態へ遷移させる。そして、セッション情報一覧取得応答2900のstatusタグに"NG"が記載されている場合、監査アプリケーション604は、監査対象の通信のセッション情報の再検索を促し、セッション情報検索画面3400を再表示する。監査者は、セッション情報検索画面3400に検索キーを再入力し、監査アプリケーション604は、再びステップS150を実行する。
【0116】
セッション情報一覧取得応答2900のstatusタグに"OK"が記載されている場合、監査アプリケーション604は、取得したセッション情報3100と監査装置600のメモリ12に保存されていた検索キーとを照合した結果を、セッション情報検索結果画面3500に表示する。
【0117】
本実施例1において、監査アプリケーション604は、例えば図16(b)に示すようなセッション情報検索結果画面3500を表示する。セッション情報検索結果画面3500には、セッション情報3100のsessionIDタグに記載されたセッションID、term1タグに記載された送信元の通信装置の名前、addr1タグに記載された送信元の通信装置のIPアドレス、term2タグに記載された宛先の通信装置の名前、addr2タグに記載された宛先の通信装置のIPアドレス、startタグに記載された通信開始時刻、endタグに記載された通信終了時刻、およびencタグに記載された暗号アルゴリズム名が、新たに付与された監査IDと共に表示される。
【0118】
なお、セッション情報検索結果画面3500を表示する際に、監査アプリケーション604は、検索キーの送信元の通信装置の名前がterm1タグに記載されている名前と一致する場合に、セッション情報検索結果画面3500の送信元の通信装置の名前の項目に、term1タグおよびaddr1タグに記載された情報を記載する。同様に、検索キーの宛先の通信装置の名前がterm2タグに記載されている名前と一致する場合に、監査アプリケーション604は、セッション情報検索結果画面3500の宛先の通信装置の名前の欄にterm2タグおよびaddr2タグに記載された情報を記載する。
【0119】
また、セッション情報一覧取得応答2900から取得した複数のセッション情報3100のうち、sessionIDタグに同じセッションIDが記載されているセッション情報3100が二つ以上存在する場合、監査アプリケーション604は、まとめて一つの通信セッションとしてセッション情報検索結果画面3500に表示する。
【0120】
監査者は、セッション情報検索結果画面3500を参照して、監査対象の暗号通信のセッション情報を確認する。そして、監査者は、監査対象の通信の条件を指定し直したい場合、セッション情報検索結果画面3500に表示されている再検索ボタンを押す。再検索ボタンが押されると、監査アプリケーション604は、セッション情報検索画面3400を再度表示し、監査者から入力された検索キーに基づいて、再びステップS150を実行する。このように、セッション情報検索結果画面3500を参照することにより、監査者は、より効率よく監査処理を進めることができる。
【0121】
一方、監査者は、検索されたセッション情報に対応する通信内容の監査を実施する場合、セッション情報検索結果画面3500に表示された通信のセッション情報一覧から、監査対象の通信を選択し、監査開始ボタンを押す。監査対象ボタンが押されると、監査アプリケーション604は、選択された監査対象の通信情報を監査装置600のメモリ12に保存すると共に、鍵取得機能601が鍵取得要求3200を作成して鍵管理装置200へ送信する(ステップS156)。
【0122】
本実施例1において、鍵取得要求3200は、例えば図14(d)に示すように、XMLメッセージのgetKeyRequestタグとして記述される。図14(d)は、監査装置600から鍵管理装置200へ送信されるセッション情報3100のうち、本実施例の説明に必要な部分のみを示している。監査対象の通信の鍵IDがkeyIDタグに記載される。なお、1つの鍵取得要求3200には、複数のkeyIDタグが記載されてもよい。
【0123】
鍵管理装置200の鍵送受信機能203は、監査装置600から鍵取得要求3200を受信すると(ステップS157)、鍵管理機能202は、鍵取得要求3200のkeyIDタグに記載されている鍵IDをキーに鍵管理DB201を検索する(ステップS158)。この時点では、鍵管理DB201に格納されている情報は、例えば図13(d)に示すようになっているものと仮定する。
【0124】
鍵管理機能202は、鍵取得要求3200のkeyIDタグに記載されている鍵IDが、鍵管理DB201内の2行目と3行目に登録されていることを検出する。そして、鍵管理機能202は、2行目に記載された鍵と3行目に記載された鍵を取得し(ステップS159)、鍵送受信機能203は、取得された鍵を用いて鍵取得応答3300を作成し、監査装置600へ送信する(ステップS160)。
【0125】
本実施例1では、鍵取得応答3300は、例えば図14(e)に示すように、XMLメッセージのgetKeyResponseタグとして記述される。図14(e)は、鍵管理装置200から監査装置600へ送信される鍵取得応答3300のうち、本実施例の説明に必要な部分のみを示している。鍵送受信機能203は、鍵管理DB201から監査対象の通信の鍵IDおよび鍵を取得した結果をstatusタグに記載する。登録成功の場合にはstatusタグに"OK"が記載され、登録失敗の場合には"NG"が記載される。また、監査対象の通信の鍵IDがkeyIDタグに記載され、鍵がkeyタグに記載される。なお、keyIDタグおよびkeyタグは監査対象の通信の数だけ複数記載されていてもよい。
【0126】
監査装置600の鍵取得機能601は、鍵管理装置200から鍵取得応答3300を受信すると(ステップS161)、鍵取得応答3300のkeyIDタグに記載されている鍵IDおよびkeyタグに記載されている鍵を取得し(ステップS162)、監査装置600のメモリ12に保存する。そして、パケット取得・復号機能603は、パケット取得要求3600を作成し、パケットモニタ装置500へ送信する(ステップS163)。
【0127】
本実施例1では、パケット取得要求3600は、例えば図15(b)に示すように、XMLメッセージのgetPacketRequestタグとして記述される。図15(b)は、監査装置600からパケットモニタ装置500へ送信されるパケット取得要求3600のうち、本実施例の説明に必要な部分のみを示している。監査装置600のメモリ12に保存された監査対象の通信情報のうち、送信元の通信装置のIPアドレスがfromタグに記載され、宛先の通信装置のIPアドレスがtoタグに記載され、開始時刻がstartタグに記載され、終了時刻がendタグに記載される。なお、これらのフィールドは、監査対象の通信のセッションID毎に複数記載されてもよい。
【0128】
パケットモニタ装置500のパケット送信機能504が監査装置600からパケット取得要求3600を受信すると(S164)、パケット管理機能503は、パケット取得要求3600のaddr1タグに記載されているユーザ端末300のIPアドレス、addr2タグに記載されているサービス提供サーバ350のIPアドレス、startタグに記載されている暗号通信の開始時刻、およびendタグに記載されている暗号通信の終了時刻をキーとして、パケットDB501を検索する。この時点では、パケットDB501に格納されている情報は、例えば図15(a)のようになっていると仮定する。
【0129】
パケット管理機能503は、パケット取得要求3600のaddr1タグに記載されているユーザ端末300のIPアドレスおよびaddr2タグに記載されているサービス提供サーバ350のIPアドレスが、1行目に記載されていることを検出する。そして、startタグに記載されている開始時刻からendタグに記載されている終了時刻までの範囲の日付が、パケット格納場所の名称の下8桁と一致することを確認する。すなわち、図15(b)において、パケット取得対象の暗号通信が行われた日付は「2006年4月1日」であり、図15(a)の1行目に記載されたパケット格納場所の下8桁が「20060401」となっていることを確認する。その後、パケット管理機能503は、1行目のパケット格納場所レコードに示されている格納場所へアクセスし、ユーザ端末300からサービス提供サーバ350へ送信された暗号パケットを取得する(ステップS165)。
【0130】
そして、パケット送信機能504は、パケット取得応答3700を作成し、監査装置600へ送信する(ステップS166)。監査装置600のパケット取得・復号機能603がパケットモニタ装置500からパケット取得応答3700を受信すると(ステップS167)、監査アプリケーション604は、パケットモニタ装置500が暗号パケットを取得済である旨を画面に表示する。そして、監査者は、監査アプリケーション604が表示した画面を見て、暗号パケットを取得済である旨を確認する。
【0131】
本実施例1では、パケット取得応答3700は、例えば図15(c)に示すように、XMLメッセージのgetPacket Responseタグとして記述される。図15(c)は、パケットモニタ装置500から監査装置600へ送信されるパケット取得応答3700のうち、本実施例の説明に必要な部分のみを示している。パケットDB501から暗号パケットが取得された結果がstatusタグに記載される。取得成功の場合にはstatusタグに"OK"が記載され、取得失敗の場合には"NG"が記載される。
【0132】
その後、パケットモニタ装置500のパケット送信機能504は、ユーザ端末300からサービス提供サーバ350へ送信された暗号パケットを監査装置600へ送信する(ステップS168)。そして、監査装置600のパケット取得・復号機能603は、パケットモニタ装置500から暗号パケットを受信し(ステップS169)、監査装置600内の外部記憶装置17に保存する。
【0133】
パケットモニタ装置500のパケット送信機能504は、暗号パケットを全て監査装置600に送信した場合、パケット送信終了通知3800を作成して監査装置600へ送信する(ステップS170)。本実施例1において、パケット送信終了通知3800は、例えば図15(d)に示すように、XMLメッセージのendSendingPacketInfoタグとして記述される。
【0134】
監査装置600のパケット取得・復号機能603がパケットモニタ装置500からパケット送信終了通知3800を受信すると(ステップS171)、監査アプリケーション604は、内部状態を監査処理実施状態に遷移させる。そして、パケット取得・復号機能603は、監査装置600のメモリ12から鍵と監査対象の通信情報を取り出し、監査装置600の外部記憶装置17に保存されている暗号パケットを復号する。監査者は、復号されたパケットを基に、ユーザ端末300とサービス提供サーバ350との通信の通信内容を監査する。
【0135】
監査終了後、監査者は、監査アプリケーション604に監査終了の指示を行うと、監査アプリケーション604は、監査装置600のメモリ12に保存されている鍵IDおよび鍵、ならびに監査装置600の外部記憶装置17に保存されている暗号パケットを削除する。そして、監査アプリケーション604は、監査処理を終了し(S172)、内部状態を待ち状態に遷移させると、監査処理が終了したことを表示する。監査者は、監査アプリケーション604が表示した内容を確認することで、監査処理が終了したことを認識する。
【0136】
以上が、暗号通信終了後に監査装置600がパケットDB501に保存されている暗号パケットを取得し、取得した暗号パケットを復号してパケットの内容を監査する場合の動作シーケンスである。なお、通信内容を監査する場合、監査アプリケーション604は、復号した一連のパケットを解析して、通信に用いられたアプリケーションプロトコルの種類(HTTP等)、および、ユーザ端末300がアクセスしたサービス提供サーバ350のリソース名(URL等)といった、通信のサマリを表示するようにしてもよい。
【0137】
なお、本実施例1における監査の実施形態としては、暗号通信終了した後に当該暗号通信の内容を監査するだけでなく、リアルタイムで行われている暗号通信の内容を監査することも可能である。この場合、図8のステップS150からステップS155までの処理を行った後、監査装置600の監査アプリケーション604が表示するセッション情報検索結果画面3500には、現在行われている暗号通信のセッション情報が含まれることになる。そして、監査者が現在行われている暗号通信を選択すると、ステップS156からステップS171までの処理を行った後、監査装置600の監査アプリケーション604は、リアルタイム監査の処理を行い、ステップS172で監査処理を終了する。
【0138】
また、本実施例1では、鍵管理装置200でなく、ユーザ端末300またはサービス提供サーバ350等の暗号通信を行う通信装置が鍵情報を生成することも可能である。この場合、ユーザ端末300およびサービス提供サーバ350には、鍵生成機能が新たに設けられる。この場合の暗号通信開始時および鍵更新時の動作シーケンスは次のようになる。
【0139】
まず、ユーザ端末300の鍵生成機能は、ステップS101において、サービス提供サーバ350へ送信するパケットを暗号化するための鍵、当該鍵の有効期間、および暗号アルゴリズム名を含む鍵情報3000を生成してユーザ端末300のメモリ12に保存すると共に、通信開始要求2000のBODY部に生成した鍵情報3000を記載する。そして、SIPクライアント機能302は、通信開始要求2000をセッション管理装置100へ送信する。
【0140】
セッション管理装置100のメッセージ送受信機能105がステップS102でユーザ端末300から通信開始要求2000を受信すると、鍵取得機能104は、通信開始要求2000のBODY部に記載されている鍵情報3000をセッション管理装置100のメモリ12に保存する。そして、メッセージ送受信機能105は、ステップS110を実行する。すなわち、メッセージ送受信機能105は、通信開始要求2000をサービス提供サーバ350へ送信する。
【0141】
次に、サービス提供サーバ350は、ステップS111からステップS115を実行する。なお、ステップS113において、サービス提供サーバ350の鍵取得機能301は、通信開始要求2000のBODY部に記載されている鍵情報3000を取得し、取得した鍵情報3000を、当該2000のCall-IDフィールドに記載されているセッションIDに対応付けてサービス提供サーバ350のメモリ12に保存する。ここで保存された鍵は、ユーザ端末300から送信された暗号パケットを復号する際に使用され、ユーザ端末300へ送信されるパケットの暗号化には使用されない。
【0142】
また、ステップS114において、鍵取得機能301は、ユーザ端末300へ送信するパケットを暗号化するための鍵、鍵の有効期間、および暗号アルゴリズム名を含む鍵情報3000を通信開始応答2100のBODY部に記載する。そして、SIPクライアント機能302は、当該通信開始応答2100をセッション管理装置100へ送信する。
【0143】
セッション管理装置100のメッセージ送受信機能105は、ステップS116でサービス提供サーバ350から通信開始応答2100を受信すると、ステップS117を実行する。通信開始応答2100が通信を拒否する旨を示すメッセージを含む場合、メッセージ送受信機能105は、ステップS122以降の処理を実行する。通信開始応答2100が通信を許可する旨を示すメッセージを含む場合、メッセージ送受信機能105は、通信開始応答2100内の鍵情報3000をセッション管理装置100のメモリ12に保存する。そして、鍵取得機能104は、ステップS103を実行する。すなわち、鍵取得機能104は、鍵生成要求2200を生成して鍵管理装置200へ送信する。なお、この場合、鍵生成要求2200には、ユーザ端末300から送信された鍵情報3000とサービス提供サーバ350から送信された鍵情報3000とが記載される。
【0144】
そして、鍵管理装置200は、ステップS104からステップS107を実行する。なお、ステップS105において、鍵管理機能202は、鍵生成要求2200に記載されている、ユーザ端末300から送信された鍵情報3000に対応する鍵ID、および、サービス提供サーバ350から送信された鍵情報3000に対応する鍵IDを、それぞれ生成する。そして、ステップS106において、鍵管理機能202は、鍵管理DB201に、鍵ID毎に鍵情報3000内の暗号アルゴリズムおよび鍵を登録する。
【0145】
そして、セッション管理装置100の鍵取得機能104は、ステップS108において鍵管理装置200から鍵生成応答2300を受信すると、ステップS118からステップS121を実行する。そして、鍵取得機能104は、通信開始応答2100のBODY部に、サービス提供サーバ350から送信された鍵情報3000を記載して、ステップS127を実行する。
【0146】
そして、ユーザ端末300は、ステップS128からステップS130を実行する。なお、ステップS130において、ユーザ端末300の鍵取得機能301は、通信開始応答2100のBODY部に記載されている鍵情報3000を取得し、通信開始応答2100のCall-IDフィールドに記載されているセッションIDと対応付けてユーザ端末300のメモリ12に保存する。ここで、保存された鍵情報3000内の鍵は、サービス提供サーバ350から送信された暗号パケットを復号する際に使用され、サービス提供サーバ350へ送信されるパケットの暗号化には使用されない。
【0147】
また、暗号通信終了のシーケンスについては、ステップS135およびステップS140において、ユーザ端末300およびサービス提供サーバ350の鍵取得機能301がそれぞれメモリ12に保存していたセッションIDおよび鍵情報3000を削除する。
【0148】
なお、ユーザ端末300またはサービス提供サーバ350が暗号通信に使用される鍵を生成する場合、上記では受信用の鍵と送信用の鍵を別にしたが、送信用の鍵と受信用の鍵を同じにしてもよい。その場合、サービス提供サーバ350が鍵情報3000を作成してユーザ端末300へ送信する処理および鍵管理装置200がサービス提供サーバ350によって作成された鍵情報3000を鍵管理DB201に登録する処理は不要である。
<実施例2>
本実施例2では、監査装置600によって指定された暗号通信のみが監査対象とされ、パケットモニタ装置500は、対象となる暗号通信において送信される暗号パケットのみ取得する。これにより、パケットモニタ装置500は、保存すべき暗号パケットのデータ量を少なくすることができる。
【0149】
図17は、本実施例2の通信内容監査支援システムのシステム構成図である。本実施例2では、実施例1の場合と異なり、セッション管理装置100、パケットモニタ装置500、および監査装置600内に、新たな機能が追加されている。
【0150】
セッション管理装置100は、監査装置600から指定された監査条件を登録する監査条件テーブル102と、監査条件テーブル102に登録された監査条件を基に通信内容の監査に関する制御を行うバス107とを新たに備える。また、セッション情報通知機能106は、実施例1で説明した機能に加え、監査対象となる暗号通信が開始した場合に当該暗号通信のセッション情報を監査装置600に通知する機能を有する。
【0151】
パケットモニタ装置500は、監査装置600から指定された暗号通信において送信される暗号パケットのみ取得し、それ以外の暗号パケットを破棄するパケット収集制御機能505を新たに備える。
【0152】
監査装置600は、セッション管理装置100に監査対象の暗号通信の条件を指示する監査条件指示機能605と、セッション管理装置100から暗号通信開始の通知を受けた場合に、当該暗号通信において送信される暗号パケットの収集をパケットモニタ装置500に指示するパケット収集指示機能606とを新たに備える。なお、監査アプリケーション604は、実施例1において説明した機能に加え、監査対象となる暗号通信の条件を設定したり、指定した監査条件と合致する暗号通信の通信内容を通信開始時からリアルタイム監査したりする機能を有する。
【0153】
次に、ユーザ端末300がセッション管理装置100を介して、サービス提供サーバ350と暗号通信に使用する鍵を共有し、暗号通信を開始する場合の一連の動作シーケンスについて、図3、図4、図18、および図19を用いて説明する。なお、本実施例2では、実施例1の場合とは異なり、監査装置600が事前にセッション管理装置100に対して、監査対象となる暗号通信の条件を指定する。また、セッション管理装置100は、ユーザ端末300から通信開始要求を受信すると、これから開始される暗号通信が事前に監査装置600から指定された条件と合致するか否かを調べ、合致する場合、監査装置600に暗号通信の開始を通知し、監査装置600は、パケットモニタ装置500にパケット収集を指示する。
【0154】
まず、監査装置600を利用する監査者は、監査アプリケーション604が表示している監査条件入力画面3900(図22(a)参照)に、監査対象の暗号通信に関する条件を入力する。監査アプリケーション604は、入力された監査条件を読み込む(ステップS201)。
【0155】
本実施例2において、監査条件入力画面3900に入力される監査条件には、監査のタイミング、監査対象の暗号通信を行う送信元の通信装置の名前、宛先の通信装置の名前、暗号パケットの送信時刻の範囲、および暗号通信に使用される暗号アルゴリズム名が含まれる。図22(a)に示す監査条件入力画面3900の例では、名前が"user"である通信装置から、名前が"service"である通信装置へ送信された暗号パケットであり、かつ、通信に使用される暗号アルゴリズム名が"AES-256bit"である暗号パケットが監査対象の暗号パケットとして指定された様子が示されている。なお、通信装置の名前または監査対象時間帯を指定する各項目は空白でも構わない。検索キーが入力されなかった項目については、監査アプリケーション604は、条件指定が無かったものとして取り扱う。
【0156】
監査装置600の監査条件指示機能605は、監査条件入力画面3900に入力された監査条件を基に監査条件登録要求4000を作成してセッション管理装置100へ送信する(ステップS202)。
【0157】
本実施例2において、監査条件登録要求4000は、例えば図22(b)に示すように、XMLメッセージのregAuditCondRequestタグとして記述される。図22(b)は、監査装置600からセッション管理装置100へ送信される監査条件登録要求4000のうち、本実施例の説明に必要な部分のみを示している。監査条件入力画面3900には、監査条件として入力された情報が記載される。監査条件入力画面3900の「監査のタイミング」の項目で選択された条件がmodeタグに記載され、「送信元の通信装置の名前」および「宛先の通信装置の名前」の項目に入力された条件が、それぞれfromタグおよびtoタグに記載される。
【0158】
また、「監査対象時間帯」の項目に入力された条件が、startタグとendタグに記載され、「暗号アルゴリズム」の項目で選択された条件が、encタグに記載される。なお、監査条件入力画面3900に監査条件が入力されていない項目については、対応する監査条件登録要求4000内のタグに"null"が記載される。また、監査条件入力画面3900の「監査のタイミング」の項目で「後で」が選択された場合、対応するmodeタグには"afterward"が記載され、「リアルタイム」が選択された場合、対応するmodeタグには"realtime"が記載される。
【0159】
セッション管理装置100のバス107は、監査装置600から監査条件登録要求4000を受信すると(ステップS203)、監査条件登録要求4000の情報を監査条件テーブル102に登録し(ステップS204)、監査条件登録応答4100を作成して監査装置600へ送信する(ステップS205)。
【0160】
本実施例2において、監査条件登録応答4100は、例えば図22(c)に示すように、XMLメッセージのregAuditCond Responseタグとして記述される。図22(c)は、セッション管理装置100から監査装置600へ送信される監査条件登録応答4100のうち、本実施例の説明に必要な部分のみを示している。監査条件登録要求4000に記載された監査条件がセッション管理装置100によって監査条件テーブル102に登録された結果がstatusタグに記載される。監査条件が監査条件テーブル102に正常に登録された場合、statusタグには"OK"が記載され、正常に登録されなかった場合には"NG"が記載される。
【0161】
また、セッション管理装置100の監査条件テーブル102には、例えば図23(a)に示すように、監査のタイミング、暗号パケットの送信元の通信装置の名前、暗号パケットの宛先の通信装置の名前、暗号通信が行われる時刻の範囲、および暗号通信に使用される暗号アルゴリズム名が格納される。図23(a)に示す例では、ステップS204が実行されることにより、2行目の監査条件が追加された後の状態が示されている。
【0162】
以上の一連の処理が行われた後、図3を用いて説明したステップS102において、セッション管理装置100のメッセージ送受信機能105がユーザ端末300から通信開始要求2000を受信することにより、図3または図4において説明したステップS103からステップS121までの処理が順次行われる。すなわち、セッション管理装置100は、鍵管理装置200によって生成された鍵情報3000を取得し、これをサービス提供サーバ350へ送信する。そして、セッション管理装置100は、サービス提供サーバ350から通通信開始応答2100を受信すると、通信状態管理DB101を更新する。なお、更新後の通信状態管理DB101内の情報は、例えば図11(b)に示した内容であると仮定する。
【0163】
以上の処理が行われた後、セッション管理装置100のバス107は、ステップS121において通信状態管理DB101に登録されたセッション情報が監査条件テーブル102に登録された条件と一致するか否かを判定することにより、これから開始される暗号通信が監査対象であるかを判定する(ステップS207)。判定の結果、これから開始される暗号通信が監査対象でない場合、通信内容監査支援システムはステップS127以降の処理を実行する。
【0164】
一方、これから開始される暗号通信が監査対象であり、監査条件テーブル102の内容が図23(a)に示すような状態である場合、セッション管理装置100のセッション情報通知機能106は、監査条件テーブル102の2行目の条件と、図11(b)に示す通信状態管理DB101の2行目に登録されている情報とを基に、監査要件定義5000を作成する。
【0165】
本実施例2において、監査要件定義5000は、例えば図22(h)に示すように、XML形式のdefAuditReqタグとして記述される。図22(h)に示す例において、監査要件定義5000には、監査のタイミングが記載されるmodeタグ、セッションIDが記載されるsessionIDタグ、送信元の通信装置のIPアドレスが記載されるfromタグ、および宛先の通信装置のIPアドレスが記載されるtoタグが記載される。
【0166】
次に、セッション情報通知機能106は、監査要件定義5000が記載された暗号通信開始通知4200を作成する(ステップS208)。そして、バス107は、監査要件定義5000のmodeタグを参照して、これから監査を実施するか否かを判定する(ステップS209)。
【0167】
監査要件定義5000のmodeタグに"afterward"と記載されている場合、セッション管理装置100のセッション情報通知機能106は、暗号通信開始通知4200を監査装置600へ送信する(ステップS211)。一方、監査要件定義5000のmodeタグに"realtime"と記載されている場合、セッション情報通知機能106は、、セッション管理装置100のメモリ12に保存されている鍵情報3000を暗号通信開始通知4200に記載して(ステップS210)、ステップS211に示した処理を実行する。
【0168】
本実施例2において、暗号通信開始通知4200は、例えば図22(d)に示すように、XMLメッセージのstartCommunicationInfoタグとして記述される。図22(d)は、セッション管理装置100から監査装置600へ送信される暗号通信開始通知4200のうち、本実施例の説明に必要な部分のみを示している。暗号通信開始通知4200には、図22(h)に示した監査要件定義5000が記載される。暗号通信がリアルタイムに監査される場合には、更に、図12(c)で説明した鍵情報3000が記載される。
【0169】
監査装置600のセッション情報取得機能602は、セッション管理装置100から暗号通信開始通知4200を受信すると(ステップS212)、暗号通信開始通知4200に記載されている監査要件定義5000を監査装置600のメモリ12に保存し、監査要件定義5000のmodeタグを参照して、これから監査を実施するか否かを判定する(ステップS213)。
【0170】
modeタグに"afterward"と記載されている場合、監査装置600のパケット収集指示機能606は、パケット収集開始要求4600を作成してパケットモニタ装置500へ送信する(ステップS215)。一方、modeタグに"realtime"と記載されている場合、監査装置600のセッション情報取得機能602は、暗号通信開始通知4200に記載されている鍵情報3000を監査要件定義5000と対応づけて監査装置600のメモリ12に保存する(ステップS214)。そして、監査アプリケーション604は、内部状態をリアルタイム監査状態に遷移させ、ステップS215に示した処理を実行する。
【0171】
本実施例2において、パケット収集開始要求4600は、例えば図23(c)に示すように、XMLメッセージのstartGathering PacketRequestタグとして記述される。図23(c)は、監査装置600からパケットモニタ装置500へ送信されるパケット収集開始要求4600のうち、本実施例の説明に必要な部分のみを示している。監査要件定義5000のmodeタグ、sessionIDタグ、fromタグ、およびtoタグ内の情報がそのままパケット収集開始要求4600のmodeタグ、sessionIDタグ、fromタグ、およびtoタグにそれぞれ記載される。
【0172】
パケットモニタ装置500のパケット収集制御機能505は、監査装置600からパケット収集開始要求4600を受信すると(ステップS216)、パケット収集開始要求4600の情報をパケットDB501の空白行に記載する。また、パケット管理機能503は、暗号パケットの格納領域を作成し、格納場所をパケットDB501のパケット格納場所レコードに記載する。そして、パケット管理機能503は、パケットDB501の状態レコードに「パケット収集中」と記載する。そして、パケット収集制御機能505は、パケット収集開始応答4700を作成して監査装置600へ送信し(ステップS217)、内部状態をパケット受信待ち状態に遷移させる。
【0173】
本実施例2において、パケット収集開始応答4700は、例えば図23(d)に示すように、XMLメッセージのstartGathering PacketResponseタグとして記述される。図23(d)は、パケットモニタ装置500から監査装置600へ送信されるパケット収集開始応答4700のうち、本実施例の説明に必要な部分のみを示している。パケットの収集対象である暗号通信の情報がパケットDB501に登録された結果が、statusタグに記載される。登録成功の場合はstatusタグに"OK"が記載され、失敗の場合には"NG"が記載される。また、パケット収集開始応答4700には、パケット収集開始要求4600のsessionIDタグが記載される。
【0174】
なお、本実施例2において、パケットDB501は、例えば図23(b)に示すようなデータ構造を有しており、図15(a)で説明した実施例1のパケットDB501と比較して、「セッションID」、「監査のタイミング」、および「状態」のレコードが新たに追加されている。これにより、パケットモニタ装置500が取得した暗号パケットをセッションID毎に管理することができ、監査時に監査装置600から要求のあったセッションIDに対応する暗号パケットを確実に取得することができる。
【0175】
また、「監査のタイミング」レコードを参照することにより、パケット収集制御機能505は、リアルタイム監査時に、受信した暗号パケットを直ちに監査装置600へ送信することができる。また、状態レコードを確認することで、パケットモニタ装置500のパケット管理機能503は、受信したパケットをセッションID毎に分けて保存することができる。
【0176】
監査装置600のパケット収集指示機能606がパケットモニタ装置500からパケット収集開始応答4700を受信すると(ステップS218)、セッション情報取得機能602は、暗号通信開始確認応答4300を作成してセッション管理装置100へ送信する(ステップS219)。本実施例2において、暗号通信開始確認応答4300は、例えば図22(e)に示すように、XMLメッセージのackStartCommunicationInfoタグとして記述される。また、ackStartCommunicationInfoタグ内には、監査要件定義5000のsessionIDタグが記載される。
【0177】
セッション管理装置100のセッション情報通知機能106は、監査装置600から暗号通信開始確認応答4300を受信すると(ステップS220)、鍵取得機能104は、セッション管理装置100のメモリ12に保存されている鍵情報3000を、図10(b)において説明したに通信開始応答2100のBODY部に記載する。そして、メッセージ送受信機能105は、通信開始応答2100をユーザ端末300へ送信し、実施例1で説明したステップS127以降の処理を実行する。
【0178】
以上が、本実施例2において、ユーザ端末300がセッション管理装置100を介して、サービス提供サーバ350と暗号通信に使用される鍵を共有し、暗号通信を開始する場合の動作シーケンスである。
【0179】
また、ユーザ端末300とサービス提供サーバ350との間で共有された鍵の有効期限が切れ、その契機で鍵更新を行う場合の一連の動作において、図18のステップS202からステップS212までは暗号通信開始の動作シーケンスと同一である。なお、ステップS212において、監査装置600がセッション管理装置100から暗号通信開始通知4200を受信した場合、監査装置600の内部状態は待ち状態またはリアルタイム監査状態のいずれかである。また、このとき、通信状態管理DB101内のデータは、図11(c)のようになっているものと仮定する。
【0180】
ステップS212において、監査装置600のセッション情報取得機能602がセッション管理装置100から暗号通信開始通知4200を受信すると、監査装置600のメモリ12内に対応する監査要件定義5000が保存されているか否かを判定する。メモリ12内に対応する監査要件定義5000が保存されている場合、セッション情報取得機能602は、暗号通信開始通知4200に記載されている監査要件定義5000のsessionIDタグと、監査装置600のメモリ12に保存されている監査要件定義5000のsessionIDタグとを比較し、セッションIDが一致すれば一連の処理が鍵更新を契機としたものであると判断する。
【0181】
そして、ステップS213において、監査要件定義5000のmodeタグに"afterward"と記載されている場合、ステップS219が実行される。一方、監査要件定義5000のmodeタグに"realtime"と記載されている場合、ステップS214が実行された後に、ステップS219が実行される。
【0182】
以上が、本実施例2において、ユーザ端末300とサービス提供サーバ350との間で共有した鍵の有効期限が切れ、その契機で鍵更新を行う場合の動作シーケンスである。なお、このシーケンスについては、サービス提供サーバ350がセッション管理装置100を介してユーザ端末300へ通信開始要求2000を送信することも可能である。また、鍵の有効期限が切れたことを契機とするのではなく、鍵の有効期限が近づいたことを契機として一連の動作が実行されてもよい。
【0183】
次に、ユーザ端末300がセッション管理装置100を介して、サービス提供サーバ350との間の暗号通信を終了する場合の一連の動作シーケンスを、図20を用いて説明する。
【0184】
ステップS132において、セッション管理装置100のメッセージ送受信機能105がユーザ端末300から通信終了要求2400を受信すると、実施例1において図6を用いて説明したステップS133からステップS138までの処理が順次行われる。すなわち、セッション管理装置100は、通信終了要求2400をサービス提供サーバ350へ送信し、サービス提供サーバ350から通信終了応答2500を受信すると、通信状態管理DB101内の情報を更新する。
【0185】
以上の処理が行われた後、セッション管理装置100のバス107は、ステップS121において、通信状態管理DB101に登録されている情報が監査条件テーブル102に登録されている条件に一致するか否かを判定することにより、終了対象の暗号通信が監査対象であるか否かを判定する(ステップS221)。
【0186】
終了対象の暗号通信が監査対象でなかった場合(S221:No)、通信内容監査支援システムはステップS139以降の処理を実行する。一方、終了対象の暗号通信が監査対象であった場合(S221:Yes)、セッション管理装置100のセッション情報通知機能106は、暗号通信終了通知4400を作成して監査装置600へ送信する(ステップs222)。
【0187】
本実施例2において、暗号通信終了通知4400は、例えば図22(f)に示すように、XMLメッセージのendCommunication Infoタグとして記述される。図22(f)は、セッション管理装置100から監査装置600へ送信される暗号通信終了通知4400のうち、本実施例の説明に必要な部分のみを示している。通信終了要求2400のCall-IDフィールドに記載されているセッションIDが、暗号通信終了通知4400のsessionIDタグに記載される。
【0188】
監査装置600のセッション情報取得機能602は、セッション管理装置100から暗号通信終了通知4400を受信すると(ステップS223)、パケット収集終了要求4800を作成してパケットモニタ装置500へ送信する(ステップS224)。
【0189】
本実施例2において、パケット収集終了要求4800は、例えば図23(e)に示すように、XMLメッセージのendGatheringPacketRequestタグとして記述される。図23(e)は、監査装置600からパケットモニタ装置500へ送信されるパケット収集終了要求4800のうち、本実施例の説明に必要な部分のみを示している。パケット収集終了要求4800のsessionIDタグには、暗号通信終了通知4400のsessionIDタグの情報がそのまま記載される。
【0190】
パケットモニタ装置500のパケット収集制御機能505は、監査装置600からパケット収集終了要求4800を受信すると(ステップS225)、パケットの収集を終了する。具体的には、パケットDB501内のデータが図23(b)に示すような状態にある場合に、パケット収集制御機能505は、パケット収集終了要求4800に記載されているセッションIDに対応するレコードの状態を示す情報を、「パケット収集中」から「パケット収集済」に書き換える。そして、パケット収集制御機能505は、パケット収集終了応答4900を作成して監査装置600へ送信し(ステップS226)、内部状態を待ち状態に遷移させる。
【0191】
本実施例2において、パケット収集終了応答4900は、例えば図23(f)に示すように、XMLメッセージのendGatheringPacketResponseタグとして記述される。図23(f)は、パケットモニタ装置500から監査装置600へ送信されるパケット収集終了応答4900のうち、本実施例の説明に必要な部分のみを示している。パケット収集制御機能505によってパケット収集の終了処理が行われた結果がstatusタグに記載される。終了成功の場合はstatusタグに"OK"が記載され、失敗の場合には"NG"が記載される。また、パケット収集終了応答4900には、パケット収集終了要求4800のsessionIDタグが記載される。
【0192】
監査装置600のパケット収集指示機能606がパケットモニタ装置500からパケット収集終了応答4900を受信すると(ステップS227)、セッション情報取得機能602は、終了対象の暗号通信がリアルタイム監査を実施していたか否かを判定する(ステップS228)。ステップS212の後にセッション情報3100と共に監査装置600のメモリ12に保存された監査のタイミングを示す情報が"afterward"である場合、セッション情報取得機能602は、リアルタイム監査を実施していなかったと判定し、暗号通信終了確認応答4500を作成してセッション管理装置100へ送信する(ステップS230)。
【0193】
一方、監査のタイミングを示す情報が"realtime"である場合、セッション情報取得機能602は、リアルタイム監査を実施していたと判定し、監査装置600のメモリ12に保存している鍵情報3000を削除し(ステップS229)、内部状態を待ち状態へ遷移させた後、ステップS230に示した処理を実行する。本実施例2において、暗号通信終了確認応答4500は、例えば図22(g)に示すように、XMLメッセージのackEndCommunicationInfoタグとして記述される。また、ackEndCommunicationInfoタグの中には、暗号通信終了通知4400のsessionIDタグが記載される。
【0194】
セッション管理装置100のセッション情報通知機能106は、監査装置600から暗号通信終了確認応答4500を受信すると(ステップS231)、メッセージ送受信機能105は、通信終了応答2500を作成してユーザ端末300へ送信し、実施例1において説明したステップS139以降の処理を実行する。
【0195】
以上が、本実施例2において、ユーザ端末300がセッション管理装置100を介して、サービス提供サーバ350との間の暗号通信を終了する場合の動作シーケンスである。なお、このシーケンスについては実施例1と同様、サービス提供サーバ350からセッション管理装置100を介してユーザ端末300に通信終了要求2400を送信することにより暗号通信を終了することも可能である。
【0196】
次に、ユーザ端末300とサービス提供サーバ350との間で暗号パケットを送信または受信する場合の一連の動作シーケンスを、図21を用いて説明する。なお、図21に示す例では、暗号パケットがユーザ端末300からサービス提供サーバ350へ送信される場合を例に説明されている。また、ユーザ端末300とサービス提供サーバ350との間の暗号通信において、送信または受信される暗号パケットは、必ずモニタリング機能付ルーティング装置400を経由する。
【0197】
ステップS148において、パケットモニタ装置500のパケット受信機能502がモニタリング機能付ルーティング装置400から暗号パケットを受信すると、パケット収集制御機能505は、受信した暗号パケットが監査対象であるか否かを判定する(ステップS232)。
【0198】
受信した暗号パケットのヘッダに記載されている送信元のIPアドレスおよび宛先のIPアドレスの組が、パケットDB501のどの行にも記載されていない場合、または、当該組が記載されているものの、「状態」の欄に「パケット収集済」が記載されている場合、パケット収集制御機能505は、暗号パケットが監査対象ではないと判定し(S232:No)、受信した暗号パケットを破棄する(ステップS233)。
【0199】
一方、パケット収集制御機能505は、暗号パケットが監査対象であると判定した場合(S232:Yes)、パケット収集制御機能505は、パケットDB501の「監査のタイミング」の欄を参照して、受信した暗号パケットに対して実施する監査がリアルタイム監査であるか否かを判定する(ステップS234)。
【0200】
「監査のタイミング」の欄に「後で」と記載されている場合(S234:No)、パケット管理機能503は、受信した暗号パケットをパケットDB501に保存する(S149)。一方、「監査のタイミング」の欄に「リアルタイム」と記載されている場合(S234:Yes)、パケット収集制御機能505は、受信した暗号パケットを複製し(ステップS235)、複製した暗号パケットを監査装置600へ送信し(ステップS236)、ステップS149に示した処理を実行する。
【0201】
監査装置600のパケット取得・復号機能603は、パケットモニタ装置500から暗号パケットを受信すると(ステップS237)、暗号パケットのヘッダ領域(図15(e)参照)に記載されている送信元装置のIPアドレスおよび宛先装置のIPアドレスを参照し、当該IPアドレスの組と一致する監査要件定義5000および鍵情報3000を監査装置600のメモリ12から取り出す。そして、パケット取得・復号機能603は、取り出した鍵情報3000を用いて暗号パケットを復号し(ステップS238)、監査者は復号されたパケットを基に、ユーザ端末300とサービス提供サーバ350との通信の通信内容を監査する。
【0202】
以上が、本実施例2において、暗号通信開始後に、ユーザ端末300とサービス提供サーバ350との間で暗号パケットを送信または受信する場合の動作シーケンスである。なお、このシーケンスについては実施例1と同様、サービス提供サーバ350がユーザ端末300に対して暗号パケットを送信することも可能である。
【0203】
なお、上記した実施例1および実施例2において、ユーザ端末300とセッション管理装置100との間の通信、および、サービス提供サーバ350とセッション管理装置100との間の通信に関しては、ユーザ端末300およびサービス提供サーバ350の公開鍵あるいは当該公開鍵が記載された公開鍵証明書をセッション管理装置100内に保存し、セッション管理装置100の公開鍵あるいは当該公開鍵が記載された公開鍵証明書をユーザ端末300およびサービス提供サーバ350内に保存し、これらの公開鍵を用いて、各SIPメッセージを通信相手の公開鍵で暗号化して送信したり、各SIPメッセージの受信後に自装置の秘密鍵で復号したりしてもよい。これにより、鍵情報3000の漏洩の危険性を減少させることができる。
【0204】
また、通信内容監査支援システムに、複数の装置を設け、それぞれの装置に、通信状態管理DB101、鍵管理DB201、およびパケットDB501をそれぞれ分割してそれぞれ格納することにより、セッション情報に関するデータ、鍵、鍵ID、および暗号アルゴリズム名に関するデータ、ならびに、暗号パケットを分散管理するようにしてもよい。これにより、1台のデータベースが故障することにより全てのデータが消失してしなうような危険性を回避することができる。
【0205】
また、複数の装置のそれぞれに鍵管理DB201内のデータを分割して格納する場合、鍵を秘密分散により複数の情報に分割するようにしてもよい。これにより、鍵の漏洩の危険性をさらに減少させることができる。
【0206】
また、本実施例2の通信内容監査支援システムは、複数のパケットモニタ装置500およびモニタリング機能付ルーティング装置400を有していてもよい。この場合、監査装置600内には、それぞれのモニタリング機能付ルーティング装置400に接続されているパケットモニタ装置500のアドレスを示す情報が記載されたテーブルが格納される。パケットモニタ装置500のアドレスを示す情報としては、例えばサブネットマスクおよびIPアドレス等である。監査装置600は、当該テーブルを参照して、該当する全てのパケットモニタ装置500に指示を出す。
【0207】
具体的には、図19のステップS215において、監査装置600のパケット収集指示機能606は、パケットモニタ装置500のアドレスを示す情報が記載されたテーブルを参照して、どのパケットモニタ装置500へパケット収集を指示するかを判定する。判定の際、パケット収集指示機能606は、監査装置600のメモリ12に保存されている監査要件定義5000に記載されている送信元のIPアドレスおよび宛先のIPアドレスを基に、どちらかの通信装置と同じネットワークに存在するパケットモニタ装置500を調べる。
【0208】
例えば、図22(h)に示しているように、暗号通信を行うユーザ端末300のIPアドレスとサービス提供サーバ350のIPアドレスとがそれぞれ192.168.10.1と192.168.20.1であるので、例えばIPアドレスが192.168.20.10であり、サブネットマスクが255.255.255.0であるパケットモニタ装置500は、サービス提供サーバ350と同じネットワークに属する。このような判定方法により、監査装置600は、IPアドレスが192.168.20.10であり、サブネットマスクが255.255.255.0であるパケットモニタ装置500へパケット収集開始要求4600を送信する。
【0209】
また、実施例2では、実施例1と同様に、鍵管理装置200でなく、ユーザ端末300およびサービス提供サーバ350が鍵情報を生成するようにしてもよい。この場合の動作シーケンスは、鍵管理装置200が生成した鍵情報3000の代わりに、ユーザ端末300が生成した鍵情報3000と鍵IDの組、および、サービス提供サーバ350が生成した鍵情報3000と鍵IDの組が用いられる。それ以外は実施例1で補足説明した動作シーケンスと同一である。
【0210】
上記において、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【図面の簡単な説明】
【0211】
【図1】実施例1の通信内容監査支援システムが備える各装置の機能構成を例示する図。
【図2】セッション管理装置100、鍵管理装置200、ユーザ端末300、サービス提供サーバ350、パケットモニタ装置500、または監査装置600の機能を実現する情報処理装置の構成を例示する図。
【図3】実施例1の通信内容監査支援システムにおける暗号通信開始・鍵更新処理の動作を例示するシーケンス図。
【図4】実施例1の通信内容監査支援システムにおける暗号通信開始・鍵更新処理の動作を例示するシーケンス図。
【図5】実施例1の通信内容監査支援システムにおける暗号通信開始・鍵更新処理の動作を例示するシーケンス図。
【図6】実施例1の通信内容監査支援システムにおける暗号通信終了の動作を例示するシーケンス図。
【図7】実施例1の通信内容監査支援システムにおける暗号パケットモニタリングの動作を例示するシーケンス図。
【図8】実施例1の通信内容監査支援システムにおける暗号通信の監査処理を例示するシーケンス図。
【図9】実施例1の通信内容監査支援システムにおける暗号通信の監査処理を例示するシーケンス図。
【図10】通信開始要求2000、通信開始応答2100、通信終了要求2400、および通信終了応答2500のデータ構造を例示する図。
【図11】通信状態管理DB101に格納されるデータの構造を例示する図。
【図12】鍵生成要求2200、鍵生成応答2300、鍵情報3000、鍵削除要求2600、および鍵削除応答2700のデータ構造を例示する図。
【図13】鍵管理DB201に格納されるデータの構造を例示する図。
【図14】セッション情報一覧取得要求2800、セッション情報一覧取得応答2900、セッション情報3100、鍵取得要求3200、および鍵取得応答3300のデータ構造を例示する図。
【図15】実施例1においてパケットDB501に格納されるデータ、パケット取得要求3600、パケット取得応答3700、パケット送信終了通知3800、および暗号パケットのデータ構造を例示する図。
【図16】監査アプリケーション604が表示するセッション情報検索画面3400およびセッション情報検索結果画面3500を例示する図。
【図17】実施例2の通信内容監査支援システムが備える各装置の機能構成を例示する図。
【図18】実施例2の通信内容監査支援システムにおける暗号通信開始の動作を例示するシーケンス図。
【図19】実施例2の通信内容監査支援システムにおける暗号通信開始の動作を例示するシーケンス図。
【図20】実施例2の通信内容監査支援システムにおける暗号通信終了の動作を例示するシーケンス図。
【図21】実施例2の通信内容監査支援システムにおける暗号パケットのモニタリングおよびリアルタイム監査の処理を例示するシーケンス図。
【図22】監査アプリケーション604が表示する監査条件入力画面3900の構成、ならびに、監査条件登録要求4000、監査条件登録応答4100、暗号通信開始通知4200、暗号通信開始確認応答4300、暗号通信終了通知4400、4500、および監査要件定義5000のデータ構造を例示する図。
【図23】監査条件テーブル102に格納されるデータ、実施例2においてパケットDB501に格納されるデータ、パケット収集開始要求4600、パケット収集開始応答4700、パケット収集終了要求4800、およびパケット収集終了応答4900のデータ構造を例示する図。
【符号の説明】
【0212】
0・・・ネットワーク、100・・・セッション管理装置、200・・・鍵管理装置、300・・・ユーザ端末、350・・・サービス提供サーバ、400・・・モニタリング機能付ルーティング装置、500・・・パケットモニタ装置、600・・・監査装置、2000・・・通信開始要求、2100・・・通信開始応答、2200・・・鍵生成要求、2300・・・鍵生成応答、2400・・・通信終了要求、2500・・・通信終了応答、2600・・・鍵削除要求、2700・・・鍵削除応答、2800・・・セッション情報一覧取得要求、2900・・・セッション情報一覧取得応答、3000・・・鍵情報、3100・・・セッション情報、3200・・・鍵取得要求、3300・・・鍵取得応答、3400・・・セッション情報検索画面、3500・・・セッション情報検索結果画面、3600・・・パケット取得要求、3700・・・パケット取得応答、3800・・・パケット送信終了通知、3900・・・監査条件入力画面、4000・・・監査条件登録要求、4100・・・監査条件登録応答、4200・・・暗号通信開始通知、4300・・・暗号通信開始確認応答、4400・・・暗号通信終了通知、4500・・・暗号通信終了確認応答、4600・・・パケット収集開始要求、4700・・・パケット収集開始応答、4800・・・パケット収集終了要求、4900・・・パケット収集終了応答、5000・・・監査要件定義
【特許請求の範囲】
【請求項1】
複数の通信装置間で行われる暗号通信の監査に必要な情報を提供する通信内容監査支援システムであって、
暗号通信に用いられる鍵情報が生成される都度、生成された鍵情報を、当該鍵情報を識別する鍵IDに対応付けて鍵管理DB(データベース)に格納する鍵管理手段と、
暗号通信が確立する都度、当該暗号通信を行う複数の通信装置のそれぞれのIPアドレスを、当該暗号通信に用いられる鍵情報の鍵IDに対応付けて通信状態管理DBに格納する通信管理手段と、
暗号通信において送信された暗号パケットの複製を取得し、取得した暗号パケットの複製を、当該暗号パケットの送信元のIPアドレスおよび宛先のIPアドレスに対応付けてパケットDBに格納するパケット取得手段と、
ユーザからの検索指示に基づいて前記通信状態管理DBを参照し、当該検索指示で特定される暗号通信を行っていた通信装置のIPアドレスに対応する鍵IDを特定し、特定した鍵IDに対応する鍵情報を前記鍵管理DBから抽出すると共に、当該検索指示で特定される暗号パケットの複製を前記パケットDBから抽出し、抽出した鍵情報および暗号パケットの複製を出力する通信情報出力手段と
を備えることを特徴とする通信内容監査支援システム。
【請求項2】
請求項1に記載の通信内容監査支援システムであって、
前記通信管理手段は、
暗号通信が行われていた時間帯を示す情報を、当該暗号通信に用いられる鍵情報の鍵IDに対応付けて通信状態管理DBにさらに格納し、
前記格納するパケット取得手段は、
暗号パケットの複製を取得した時刻を、当該暗号パケットの送信元のIPアドレスおよび宛先のIPアドレスに対応付けてパケットDBにさらに格納し、
前記検索指示には、暗号パケットの送信元のIPアドレスもしくは宛先のIPアドレス、暗号パケットの複製の取得時間帯、または、それらの組み合わせが含まれることを特徴とする通信内容監査支援システム。
【請求項3】
請求項1または2に記載の通信内容監査支援システムであって、
監査対象の暗号通信を特定するために予め設定された監査条件を格納する監査条件格納手段をさらに備え、
前記パケット取得手段は、
取得した暗号パケットの複製が、前記監査条件に該当する場合に、当該暗号パケットの複製を前記パケットDBに格納し、
取得した暗号パケットの複製が、前記監査条件に該当しない場合に、当該暗号パケットを破棄することを特徴とする通信内容監査支援システム。
【請求項4】
請求項3に記載の通信内容監査支援システムであって、
前記監査条件に監査を即座に実行する旨が含まれており、かつ、当該監査条件に該当する暗号通信が確立した場合に、当該暗号通信に用いられる鍵情報を前記鍵管理DBから取得して前記通信情報出力手段へ送信する鍵情報通知手段をさらに備え、
前記パケット取得手段は、
前記監査条件に監査を即座に実行する旨が含まれている場合に、当該監査条件に該当する暗号パケットの複製を前記通信情報出力手段へさらに送信し、
前記通信情報出力手段は、
前記鍵情報通知手段から通知された鍵情報および前記パケット取得手段から受信した暗号パケットの複製を出力することを特徴とする通信内容監査支援システム。
【請求項5】
請求項3または4に記載の通信内容監査支援システムであって、
前記監査条件には、暗号パケットの送信元のIPアドレス、暗号パケットの宛先のIPアドレス、暗号パケットの複製の取得時間帯、または、これらの組み合わせが含まれることを特徴とする通信内容監査支援システム。
【請求項6】
複数の通信装置間で行われる暗号通信の監査に必要な情報を提供する通信内容監査支援システムであって、
暗号通信に用いられる鍵情報が生成される都度、生成された鍵情報を、当該鍵情報を識別する鍵IDに対応付けて鍵管理DB(データベース)に格納する鍵管理手段と、
暗号通信が確立した場合に、当該暗号通信を行う複数の通信装置のそれぞれに固有の情報である固有情報、当該複数の通信装置のそれぞれのIPアドレス、および、当該暗号通信の開始時刻を、当該暗号通信に用いられる鍵情報の鍵IDに対応付けて通信状態管理DBに格納し、
当該暗号通信が終了した場合に、当該鍵情報を用いた暗号通信の終了時刻を当該鍵情報の鍵IDに対応付けて前記通信状態管理DBに格納する通信管理手段と、
暗号通信において送信された暗号パケットの複製を取得し、取得した暗号パケットの複製を、当該暗号パケットの送信元のIPアドレスおよび宛先のIPアドレス、ならびに、当該暗号パケットの複製の取得時刻に対応付けてパケットDBに格納するパケット取得手段と、
ユーザからの検索指示に基づいて前記通信状態管理DBを参照し、当該検索指示で特定される暗号通信を行っていた通信装置の固有情報、IPアドレス、暗号通信の開始時刻、および終了時刻に対応する鍵IDを特定し、特定した鍵IDに対応する鍵情報を前記鍵管理DBから抽出すると共に、当該検索指示で特定される暗号パケットの複製を前記パケットDBから抽出し、抽出した鍵情報および暗号パケットの複製を出力する通信情報出力手段と
を備えることを特徴とする通信内容監査支援システム。
【請求項7】
請求項6に記載の通信内容監査支援システムであって、
前記検索指示には、暗号パケットの送信元もしくは宛先の固有情報もしくはIPアドレス、暗号パケットの複製の取得時間帯、または、それらの組み合わせが含まれることを特徴とする通信内容監査支援システム。
【請求項8】
請求項6または7に記載の通信内容監査支援システムであって、
監査対象の暗号通信を特定するために予め設定された監査条件を格納する監査条件格納手段をさらに備え、
前記パケット取得手段は、
取得した暗号パケットの複製が、前記監査条件に該当する場合に、当該暗号パケットの複製を前記パケットDBに格納し、
取得した暗号パケットの複製が、前記監査条件に該当しない場合に、当該暗号パケットを破棄することを特徴とする通信内容監査支援システム。
【請求項9】
請求項8に記載の通信内容監査支援システムであって、
前記監査条件に監査を即座に実行する旨が含まれており、かつ、当該監査条件に該当する暗号通信が確立した場合に、当該暗号通信に用いられる鍵情報を前記鍵管理DBから取得して前記通信情報出力手段へ送信する鍵情報通知手段をさらに備え、
前記パケット取得手段は、
前記監査条件に監査を即座に実行する旨が含まれている場合に、当該監査条件に該当する暗号パケットの複製を前記通信情報出力手段へさらに送信し、
前記通信情報出力手段は、
前記鍵情報通知手段から通知された鍵情報および前記パケット取得手段から受信した暗号パケットの複製を出力することを特徴とする通信内容監査支援システム。
【請求項10】
請求項3または4に記載の通信内容監査支援システムであって、
前記監査条件には、暗号パケットの送信元もしくは宛先の固有情報もしくはIPアドレス、暗号パケットの複製の取得時間帯、または、それらの組み合わせが含まれることを特徴とする通信内容監査支援システム。
【請求項1】
複数の通信装置間で行われる暗号通信の監査に必要な情報を提供する通信内容監査支援システムであって、
暗号通信に用いられる鍵情報が生成される都度、生成された鍵情報を、当該鍵情報を識別する鍵IDに対応付けて鍵管理DB(データベース)に格納する鍵管理手段と、
暗号通信が確立する都度、当該暗号通信を行う複数の通信装置のそれぞれのIPアドレスを、当該暗号通信に用いられる鍵情報の鍵IDに対応付けて通信状態管理DBに格納する通信管理手段と、
暗号通信において送信された暗号パケットの複製を取得し、取得した暗号パケットの複製を、当該暗号パケットの送信元のIPアドレスおよび宛先のIPアドレスに対応付けてパケットDBに格納するパケット取得手段と、
ユーザからの検索指示に基づいて前記通信状態管理DBを参照し、当該検索指示で特定される暗号通信を行っていた通信装置のIPアドレスに対応する鍵IDを特定し、特定した鍵IDに対応する鍵情報を前記鍵管理DBから抽出すると共に、当該検索指示で特定される暗号パケットの複製を前記パケットDBから抽出し、抽出した鍵情報および暗号パケットの複製を出力する通信情報出力手段と
を備えることを特徴とする通信内容監査支援システム。
【請求項2】
請求項1に記載の通信内容監査支援システムであって、
前記通信管理手段は、
暗号通信が行われていた時間帯を示す情報を、当該暗号通信に用いられる鍵情報の鍵IDに対応付けて通信状態管理DBにさらに格納し、
前記格納するパケット取得手段は、
暗号パケットの複製を取得した時刻を、当該暗号パケットの送信元のIPアドレスおよび宛先のIPアドレスに対応付けてパケットDBにさらに格納し、
前記検索指示には、暗号パケットの送信元のIPアドレスもしくは宛先のIPアドレス、暗号パケットの複製の取得時間帯、または、それらの組み合わせが含まれることを特徴とする通信内容監査支援システム。
【請求項3】
請求項1または2に記載の通信内容監査支援システムであって、
監査対象の暗号通信を特定するために予め設定された監査条件を格納する監査条件格納手段をさらに備え、
前記パケット取得手段は、
取得した暗号パケットの複製が、前記監査条件に該当する場合に、当該暗号パケットの複製を前記パケットDBに格納し、
取得した暗号パケットの複製が、前記監査条件に該当しない場合に、当該暗号パケットを破棄することを特徴とする通信内容監査支援システム。
【請求項4】
請求項3に記載の通信内容監査支援システムであって、
前記監査条件に監査を即座に実行する旨が含まれており、かつ、当該監査条件に該当する暗号通信が確立した場合に、当該暗号通信に用いられる鍵情報を前記鍵管理DBから取得して前記通信情報出力手段へ送信する鍵情報通知手段をさらに備え、
前記パケット取得手段は、
前記監査条件に監査を即座に実行する旨が含まれている場合に、当該監査条件に該当する暗号パケットの複製を前記通信情報出力手段へさらに送信し、
前記通信情報出力手段は、
前記鍵情報通知手段から通知された鍵情報および前記パケット取得手段から受信した暗号パケットの複製を出力することを特徴とする通信内容監査支援システム。
【請求項5】
請求項3または4に記載の通信内容監査支援システムであって、
前記監査条件には、暗号パケットの送信元のIPアドレス、暗号パケットの宛先のIPアドレス、暗号パケットの複製の取得時間帯、または、これらの組み合わせが含まれることを特徴とする通信内容監査支援システム。
【請求項6】
複数の通信装置間で行われる暗号通信の監査に必要な情報を提供する通信内容監査支援システムであって、
暗号通信に用いられる鍵情報が生成される都度、生成された鍵情報を、当該鍵情報を識別する鍵IDに対応付けて鍵管理DB(データベース)に格納する鍵管理手段と、
暗号通信が確立した場合に、当該暗号通信を行う複数の通信装置のそれぞれに固有の情報である固有情報、当該複数の通信装置のそれぞれのIPアドレス、および、当該暗号通信の開始時刻を、当該暗号通信に用いられる鍵情報の鍵IDに対応付けて通信状態管理DBに格納し、
当該暗号通信が終了した場合に、当該鍵情報を用いた暗号通信の終了時刻を当該鍵情報の鍵IDに対応付けて前記通信状態管理DBに格納する通信管理手段と、
暗号通信において送信された暗号パケットの複製を取得し、取得した暗号パケットの複製を、当該暗号パケットの送信元のIPアドレスおよび宛先のIPアドレス、ならびに、当該暗号パケットの複製の取得時刻に対応付けてパケットDBに格納するパケット取得手段と、
ユーザからの検索指示に基づいて前記通信状態管理DBを参照し、当該検索指示で特定される暗号通信を行っていた通信装置の固有情報、IPアドレス、暗号通信の開始時刻、および終了時刻に対応する鍵IDを特定し、特定した鍵IDに対応する鍵情報を前記鍵管理DBから抽出すると共に、当該検索指示で特定される暗号パケットの複製を前記パケットDBから抽出し、抽出した鍵情報および暗号パケットの複製を出力する通信情報出力手段と
を備えることを特徴とする通信内容監査支援システム。
【請求項7】
請求項6に記載の通信内容監査支援システムであって、
前記検索指示には、暗号パケットの送信元もしくは宛先の固有情報もしくはIPアドレス、暗号パケットの複製の取得時間帯、または、それらの組み合わせが含まれることを特徴とする通信内容監査支援システム。
【請求項8】
請求項6または7に記載の通信内容監査支援システムであって、
監査対象の暗号通信を特定するために予め設定された監査条件を格納する監査条件格納手段をさらに備え、
前記パケット取得手段は、
取得した暗号パケットの複製が、前記監査条件に該当する場合に、当該暗号パケットの複製を前記パケットDBに格納し、
取得した暗号パケットの複製が、前記監査条件に該当しない場合に、当該暗号パケットを破棄することを特徴とする通信内容監査支援システム。
【請求項9】
請求項8に記載の通信内容監査支援システムであって、
前記監査条件に監査を即座に実行する旨が含まれており、かつ、当該監査条件に該当する暗号通信が確立した場合に、当該暗号通信に用いられる鍵情報を前記鍵管理DBから取得して前記通信情報出力手段へ送信する鍵情報通知手段をさらに備え、
前記パケット取得手段は、
前記監査条件に監査を即座に実行する旨が含まれている場合に、当該監査条件に該当する暗号パケットの複製を前記通信情報出力手段へさらに送信し、
前記通信情報出力手段は、
前記鍵情報通知手段から通知された鍵情報および前記パケット取得手段から受信した暗号パケットの複製を出力することを特徴とする通信内容監査支援システム。
【請求項10】
請求項3または4に記載の通信内容監査支援システムであって、
前記監査条件には、暗号パケットの送信元もしくは宛先の固有情報もしくはIPアドレス、暗号パケットの複製の取得時間帯、または、それらの組み合わせが含まれることを特徴とする通信内容監査支援システム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【公開番号】特開2008−219454(P2008−219454A)
【公開日】平成20年9月18日(2008.9.18)
【国際特許分類】
【出願番号】特願2007−53708(P2007−53708)
【出願日】平成19年3月5日(2007.3.5)
【国等の委託研究の成果に係る記載事項】(出願人による申告)国等の委託研究の成果に係る特許出願(平成18年度総務省「認証機能を具備するサービスプラットフォーム技術」委託研究、産業活力再生特別措置法第30条の適用を受けるもの)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】
【公開日】平成20年9月18日(2008.9.18)
【国際特許分類】
【出願日】平成19年3月5日(2007.3.5)
【国等の委託研究の成果に係る記載事項】(出願人による申告)国等の委託研究の成果に係る特許出願(平成18年度総務省「認証機能を具備するサービスプラットフォーム技術」委託研究、産業活力再生特別措置法第30条の適用を受けるもの)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】
[ Back to top ]