特許 6084278 情報処理装置、方法およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】6084278

(24)【登録日】2017年2月3日

(45)【発行日】2017年2月22日

(54)【発明の名称】情報処理装置、方法およびプログラム

(51)【国際特許分類】

   H04L 9/32 20060101AFI20170213BHJP

   H04L 12/66 20060101ALI20170213BHJP

   H04L 9/08 20060101ALI20170213BHJP

【ＦＩ】

   H04L9/00 675B

   H04L12/66 B

   H04L9/00 601C

【請求項の数】18

【全頁数】17

(21)【出願番号】特願2015-231697(P2015-231697)

(22)【出願日】2015年11月27日

【審査請求日】2015年12月10日

(73)【特許権者】

【識別番号】000136136

【氏名又は名称】株式会社ＰＦＵ

(74)【代理人】

【識別番号】100113608

【弁理士】

【氏名又は名称】平川 明

(74)【代理人】

【識別番号】100105407

【弁理士】

【氏名又は名称】高田 大輔

(74)【代理人】

【識別番号】100145838

【弁理士】

【氏名又は名称】畑添 隆人

(72)【発明者】

【氏名】小林 峻

(72)【発明者】

【氏名】寺田 成吾

【審査官】 青木 重徳

(56)【参考文献】

【文献】 特開２００６−２７０５０４（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１１／０１５４０１７（ＵＳ，Ａ１）

【文献】 特表２０１２−５３２５１６（ＪＰ，Ａ）

【文献】 特開２０１４−０９９８００（ＪＰ，Ａ）

【文献】 島岡 政基、他，安全な通信を確保するＳＳＬ／ＴＬＳの教科書 インターネットの通信セキュリティを確保するしくみをマスターしよう！，ＳｏｆｔｗａｒｅＤｅｓｉｇｎ，日本，（株）技術評論社，２０１５年 ８月１８日，第２９８号，ｐ．８２−９４

【文献】 梅澤 克之、他，モバイル向け証明書検証システムの開発，情報処理学会論文誌，日本，社団法人情報処理学会，２００７年 ２月１５日，Vol. 48, No. 2，pp. 625-634

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ ９／３２

Ｈ０４Ｌ ９／０８

Ｈ０４Ｌ １２／６６

(57)【特許請求の範囲】

【請求項1】

ネットワークに接続された第一の端末と第二の端末との間の通信に係るデータを、相手側端末へ到達する前に取得する通信取得手段と、
前記通信取得手段によって取得されたデータに係る通信のプロトコルを解析することで、該データに含まれる、秘匿化の対象となるセッションにおける通信相手の電子証明書を含むセッション確立用メッセージを特定する、プロトコル解析手段と、
前記プロトコル解析手段によって特定された前記セッション確立用メッセージから電子証明書を抽出する証明書抽出手段と、
抽出された前記電子証明書及び前記セッションにおける通信相手の正当性を検査する検査手段と、
前記通信取得手段によって取得されたデータのうち、前記セッション確立用メッセージの送受信の前に前記第一の端末と前記第二の端末との間で送受信されるデータから、前記通信相手の識別情報を抽出する識別情報抽出手段と、を備え、
前記検査手段は、前記識別情報抽出手段によって抽出された前記通信相手の識別情報と、前記電子証明書に含まれる対象サーバー情報とを比較することで、前記セッションにおける通信相手の正当性を検査する、
情報処理装置。

【請求項2】

前記識別情報抽出手段は、前記セッション確立用メッセージの前に送受信される名前解決のためのメッセージから、名前解決を要した前記通信相手の識別情報を抽出する、
請求項１に記載の情報処理装置。

【請求項3】

前記識別情報抽出手段は、前記第一の端末と前記第二の端末との間の通信を仲介する仲介サーバーへのセッション確立用メッセージに含まれる、該仲介サーバーを介した通信の宛先を示す情報から、前記通信相手の識別情報を抽出する、
請求項１に記載の情報処理装置。

【請求項4】

ネットワークに接続された第一の端末と第二の端末との間の通信に係るデータを、相手側端末へ到達する前に取得する通信取得手段と、
前記通信取得手段によって取得されたデータに係る通信のプロトコルを解析することで、該データに含まれる、秘匿化の対象となるセッションにおける通信相手の電子証明書を
含むセッション確立用メッセージを特定する、プロトコル解析手段と、
前記プロトコル解析手段によって特定された前記セッション確立用メッセージから電子証明書を抽出する証明書抽出手段と、
抽出された前記電子証明書及び前記セッションにおける通信相手の正当性を検査する検査手段と、
前記セッション確立用メッセージから前記通信相手の識別情報を抽出する識別情報抽出手段と、を備え、
前記検査手段は、前記識別情報抽出手段によって抽出された前記通信相手の識別情報と、前記電子証明書に含まれる対象サーバー情報とを比較することで、前記セッションにおける通信相手の正当性を検査する、
情報処理装置。

【請求項5】

ネットワークに接続された第一の端末と第二の端末との間の通信に係るデータを、相手側端末へ到達する前に取得する通信取得手段と、
前記通信取得手段によって取得されたデータに係る通信のプロトコルを解析することで、該データに含まれる、秘匿化の対象となるセッションにおける通信相手の電子証明書を含むセッション確立用メッセージを特定する、プロトコル解析手段と、
前記プロトコル解析手段によって特定された前記セッション確立用メッセージから電子証明書を抽出する証明書抽出手段と、
抽出された前記電子証明書を検査する検査手段と、を備え、
前記検査手段は、セッション確立用メッセージに含まれる、確立されようとしているセッションにおいて用いられる暗号通信方式と、予め定義された、該情報処理装置が設置された環境において許可される暗号通信方式と、を比較することで、該セッションのセキュリティ強度を更に検査する、
情報処理装置。

【請求項6】

外部サーバーから、前記電子証明書に関する情報を取得する情報取得手段を更に備え、
前記検査手段は、外部サーバーから取得された情報に基づいて、前記電子証明書を検査する、
請求項１から５の何れか一項に記載の情報処理装置。

【請求項7】

前記検査手段は、前記電子証明書に含まれる所定のフィールドの値と、予め定義された、該所定のフィールドの値が取り得る範囲と、を比較することで、前記電子証明書を検査する、
請求項１から６の何れか一項に記載の情報処理装置。

【請求項8】

前記検査手段による検査の結果が所定の基準を満たさない場合に、前記第一の端末、前記第二の端末または該情報処理装置の管理者に対して通知を送信するイベント処理手段を更に備える、
請求項１から７の何れか一項に記載の情報処理装置。

【請求項9】

前記検査手段による検査の結果が所定の基準を満たさない場合に、前記第一の端末と前記第二の端末との間の通信を遮断する通信遮断手段を更に備える、
請求項１から８の何れか一項に記載の情報処理装置。

【請求項10】

前記通信取得手段によって取得された複数のパケットを、該複数のパケットの夫々に付された識別情報に基づいて、前記第一の端末と前記第二の端末との間で送受信される通信の内容を組み立てるフロー管理手段を更に備え、
前記プロトコル解析手段は、前記フロー管理手段によって組み立てられた通信の内容を解析することで、前記セッション確立用メッセージを特定する、
請求項１から９の何れか一項に記載の情報処理装置。

【請求項11】

コンピューターが、
ネットワークに接続された第一の端末と第二の端末との間の通信に係るデータを、相手側端末へ到達する前に取得する通信取得ステップと、
前記通信取得ステップで取得されたデータに係る通信のプロトコルを解析することで、該データに含まれる、秘匿化の対象となるセッションにおける通信相手の電子証明書を含むセッション確立用メッセージを特定する、プロトコル解析ステップと、
前記プロトコル解析ステップで特定された前記セッション確立用メッセージから電子証明書を抽出する証明書抽出ステップと、
抽出された前記電子証明書及び前記セッションにおける通信相手の正当性を検査する検査ステップと、
前記通信取得ステップで取得されたデータのうち、前記セッション確立用メッセージの送受信の前に前記第一の端末と前記第二の端末との間で送受信されるデータから、前記通信相手の識別情報を抽出する識別情報抽出ステップと、を実行し、
前記検査ステップでは、前記識別情報抽出ステップで抽出された前記通信相手の識別情報と、前記電子証明書に含まれる対象サーバー情報とを比較することで、前記セッションにおける通信相手の正当性が検査される、
方法。

【請求項12】

コンピューターが、
ネットワークに接続された第一の端末と第二の端末との間の通信に係るデータを、相手側端末へ到達する前に取得する通信取得ステップと、
前記通信取得ステップで取得されたデータに係る通信のプロトコルを解析することで、該データに含まれる、秘匿化の対象となるセッションにおける通信相手の電子証明書を含むセッション確立用メッセージを特定する、プロトコル解析ステップと、
前記プロトコル解析ステップで特定された前記セッション確立用メッセージから電子証明書を抽出する証明書抽出ステップと、
抽出された前記電子証明書及び前記セッションにおける通信相手の正当性を検査する検査ステップと、
前記セッション確立用メッセージから前記通信相手の識別情報を抽出する識別情報抽出ステップと、を実行し、
前記検査ステップでは、前記識別情報抽出ステップで抽出された前記通信相手の識別情報と、前記電子証明書に含まれる対象サーバー情報とを比較することで、前記セッションにおける通信相手の正当性が検査される、
方法。

【請求項13】

コンピューターが、
ネットワークに接続された第一の端末と第二の端末との間の通信に係るデータを、相手側端末へ到達する前に取得する通信取得ステップと、
前記通信取得ステップで取得されたデータに係る通信のプロトコルを解析することで、該データに含まれる、秘匿化の対象となるセッションにおける通信相手の電子証明書を含むセッション確立用メッセージを特定する、プロトコル解析ステップと、
前記プロトコル解析ステップで特定された前記セッション確立用メッセージから電子証明書を抽出する証明書抽出ステップと、
抽出された前記電子証明書を検査する検査ステップと、を実行し、
前記検査ステップでは、セッション確立用メッセージに含まれる、確立されようとしているセッションにおいて用いられる暗号通信方式と、予め定義された、該情報処理装置が設置された環境において許可される暗号通信方式と、を比較することで、該セッションのセキュリティ強度が更に検査される、
方法。

【請求項14】

外部サーバーから、前記電子証明書に関する情報を取得する情報取得ステップを更に実行し、
前記検査ステップでは、外部サーバーから取得された情報に基づいて、前記電子証明書が検査される、
請求項１１から１３の何れか一項に記載の方法。

【請求項15】

コンピューターに、
ネットワークに接続された第一の端末と第二の端末との間の通信に係るデータを、相手側端末へ到達する前に取得する通信取得ステップと、
前記通信取得ステップで取得されたデータに係る通信のプロトコルを解析することで、該データに含まれる、秘匿化の対象となるセッションにおける通信相手の電子証明書を含むセッション確立用メッセージを特定する、プロトコル解析ステップと、
前記プロトコル解析ステップで特定された前記セッション確立用メッセージから電子証明書を抽出する証明書抽出ステップと、
抽出された前記電子証明書及び前記セッションにおける通信相手の正当性を検査する検査ステップと、
前記通信取得ステップで取得されたデータのうち、前記セッション確立用メッセージの送受信の前に前記第一の端末と前記第二の端末との間で送受信されるデータから、前記通信相手の識別情報を抽出する識別情報抽出ステップと、を実行させ、
前記検査ステップでは、前記識別情報抽出ステップで抽出された前記通信相手の識別情報と、前記電子証明書に含まれる対象サーバー情報とを比較することで、前記セッションにおける通信相手の正当性が検査される、
プログラム。

【請求項16】

コンピューターに、
ネットワークに接続された第一の端末と第二の端末との間の通信に係るデータを、相手側端末へ到達する前に取得する通信取得ステップと、
前記通信取得ステップで取得されたデータに係る通信のプロトコルを解析することで、該データに含まれる、秘匿化の対象となるセッションにおける通信相手の電子証明書を含むセッション確立用メッセージを特定する、プロトコル解析ステップと、
前記プロトコル解析ステップで特定された前記セッション確立用メッセージから電子証明書を抽出する証明書抽出ステップと、
抽出された前記電子証明書及び前記セッションにおける通信相手の正当性を検査する検査ステップと、
前記セッション確立用メッセージから前記通信相手の識別情報を抽出する識別情報抽出ステップと、を実行させ、
前記検査ステップでは、前記識別情報抽出ステップで抽出された前記通信相手の識別情報と、前記電子証明書に含まれる対象サーバー情報とを比較することで、前記セッションにおける通信相手の正当性が検査される、
プログラム。

【請求項17】

コンピューターに、
ネットワークに接続された第一の端末と第二の端末との間の通信に係るデータを、相手側端末へ到達する前に取得する通信取得ステップと、
前記通信取得ステップで取得されたデータに係る通信のプロトコルを解析することで、該データに含まれる、秘匿化の対象となるセッションにおける通信相手の電子証明書を含むセッション確立用メッセージを特定する、プロトコル解析ステップと、
前記プロトコル解析ステップで特定された前記セッション確立用メッセージから電子証
明書を抽出する証明書抽出ステップと、
抽出された前記電子証明書を検査する検査ステップと、を実行させ、
前記検査ステップでは、セッション確立用メッセージに含まれる、確立されようとしているセッションにおいて用いられる暗号通信方式と、予め定義された、該情報処理装置が設置された環境において許可される暗号通信方式と、を比較することで、該セッションのセキュリティ強度が更に検査される、
プログラム。

【請求項18】

外部サーバーから、前記電子証明書に関する情報を取得する情報取得ステップを更に実行させ、
前記検査ステップでは、外部サーバーから取得された情報に基づいて、前記電子証明書が検査される、
請求項１５から１７の何れか一項に記載のプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、電子証明書を検査するための技術に関する。

【背景技術】

【0002】

従来、クライアントからの検査要求を受けて証明書を検証する証明書検証サーバーが提案されている（非特許文献１を参照）。

【0003】

また、既知の不正通信のうちいずれかの不正通信を端末が行った場合に、該不正通信の発生時刻から所定範囲の時間帯において端末が通信に使用した通信先のアクセスＵＲＬを取得して、取得された各通信先のアクセスＵＲＬが、不正通信および他の不正通信において出現する頻度に基づいて、各通信先のアクセスＵＲＬのなかから不正通信と関連する通信先のアクセスＵＲＬを検出する解析装置が提案されている（特許文献１を参照）。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１５−０８２７６９号公報

【非特許文献】

【0005】

【非特許文献1】株式会社日立製作所、「証明書検証サーバ＞製品紹介」ｈｔｔｐ：／／ｗｗｗ．ｈｉｔａｃｈｉ．ｃｏ．ｊｐ／Ｐｒｏｄ／ｃｏｍｐ／ａｐｐ／ｋｅｎｓｈｏ／ｐｒｏｄｕｃｔ．ｈｔｍｌ、平成２７年９月２４日取得

【発明の概要】

【発明が解決しようとする課題】

【0006】

従来、ＳＳＬ／ＴＬＳ等の暗号通信において、通信相手を認証する目的で、電子証明書が利用されている。しかし、電子証明書は、従来、終端するアプリケーションによって検査されているため、アプリケーションの実装に不備があった場合、意図しない通信先と通信してしまう可能性がある。

【0007】

このような問題を受けて、従来、代理サーバーによって検査する方法や、利用するアプリケーションの検査機能を強化する方法等が提案されているが、このような方法を採用する場合には、アプリケーションに対し、代理サーバーを利用するための設定や検査機能強化のための設定等が必要であり、電子証明書の検査漏れが発生する可能性がある。

【0008】

また、マルウェアの中にも、Ｃ＆Ｃサーバーと暗号通信を行うためにＳＳＬ／ＴＬＳ プロトコルを使用するものがあり、このようなマルウェアは、正当な電子証明書を使用しないことも多い。そして、本来電子証明書の検査を行なうべき終端アプリケーションはマルウェアであるため、端末側ではこのような電子証明書を検査することも困難である。

【0009】

本開示は、上記した問題に鑑み、電子証明書の検査漏れを低減させることを課題とする。

【課題を解決するための手段】

【0010】

本開示の一例は、ネットワークに接続された第一の端末と第二の端末との間の通信を、相手側端末へ到達する前に取得する通信取得手段と、前記通信取得手段によって取得された通信のプロトコルを解析することで、該通信に含まれる、秘匿化の対象となるセッションにおける通信相手の電子証明書を含むセッション確立用メッセージを特定する、プロト
コル解析手段と、前記プロトコル解析手段によって特定された前記セッション確立用メッセージから電子証明書を抽出する証明書抽出手段と、抽出された前記電子証明書を検査する検査手段と、を備える情報処理装置である。

【0011】

本開示は、情報処理装置、システム、コンピューターによって実行される方法またはコンピューターに実行させるプログラムとして把握することが可能である。また、本開示は、そのようなプログラムをコンピューターその他の装置、機械等が読み取り可能な記録媒体に記録したものとしても把握できる。ここで、コンピューター等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的または化学的作用によって蓄積し、コンピューター等から読み取ることができる記録媒体をいう。

【発明の効果】

【0012】

本開示によれば、電子証明書の検査漏れを低減させることが可能となる。

【図面の簡単な説明】

【0013】

【図1】実施形態に係るシステムの構成を示す概略図である。

【図2】実施形態に係るネットワーク監視装置のハードウェア構成を示す図である。

【図3】実施形態に係るネットワーク監視装置の機能構成の概略を示す図である。

【図4】実施形態に係るデータ処理の流れを示すフローチャートである。

【図5】実施形態に係る検査処理の流れを示すフローチャートである。

【図6】実施形態に係る、ＳＳＬ／ＴＬＳセッション確立処理およびその前に実行される名前解決処理の流れを示すシーケンス図である。

【図7】実施形態に係るＳＳＬ／ＴＬＳセッション確立処理およびその前に実行されるプロキシサーバーとのセッション確立処理の流れを示すシーケンス図である。

【図8】実施形態に係るシステムの構成のバリエーションを示す概略図である。

【発明を実施するための形態】

【0014】

以下、本開示に係る情報処理装置、方法およびプログラムの実施の形態を、図面に基づいて説明する。但し、以下に説明する実施の形態は、実施形態を例示するものであって、本開示に係る情報処理装置、方法およびプログラムを以下に説明する具体的構成に限定するものではない。実施にあたっては、実施の態様に応じた具体的構成が適宜採用され、また、種々の改良や変形が行われてよい。

【0015】

本実施形態では、本開示に係る情報処理装置、方法およびプログラムを、ネットワークを監視するためのシステムにおいて実施した場合の実施の形態について説明する。但し、本開示に係る情報処理装置、方法およびプログラムは、電子証明書を検査するための技術について広く用いることが可能であり、本開示の適用対象は、本実施形態において示した例に限定されない。

【0016】

＜システムの構成＞
図１は、本実施形態に係るシステム１の構成を示す概略図である。本実施形態に係るシステム１は、複数の情報処理端末９０（以下、「ノード９０」と称する）が接続されるネットワークセグメント２と、ノード９０に係る通信を監視するためのネットワーク監視装置２０と、を備える。また、ネットワークセグメント２内のノード９０は、インターネットや広域ネットワークを介して遠隔地において接続された各種のサーバーと、ルータ１０を介して通信可能である。本実施形態において、ネットワーク監視装置２０は、ネットワークセグメント２のスイッチまたはルータ（図１に示した例では、ルータ１０）と、その上位にある他のスイッチまたはルータと、の間に接続されることで、通過するパケットやフレーム等を取得する。この場合、ネットワーク監視装置２０は、取得したパケットのうち、遮断しなくてもよいパケットについては転送するインラインモードで動作する。

【0017】

図２は、本実施形態に係るネットワーク監視装置２０のハードウェア構成を示す図である。なお、図２においては、ネットワーク監視装置２０以外の構成（ルータ１０、ノード９０等）については、図示を省略している。ネットワーク監視装置２０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記憶装置１４、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）１５等の通信ユニット、等を備えるコンピューターである。

【0018】

図３は、本実施形態に係るネットワーク監視装置２０の機能構成の概略を示す図である。なお、図３においては、ネットワーク監視装置２０以外の構成（ルータ１０およびノード９０等）については、図示を省略している。ネットワーク監視装置２０は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されることで、通信取得部２１、フロー管理部２２、プロトコル解析部２３、証明書抽出部２４、識別情報抽出部２５、検査部２６、情報取得部２７、イベント処理部２８および通信遮断部２９を備える情報処理装置として機能する。なお、本実施形態では、ネットワーク監視装置２０の備える各機能は、汎用プロセッサであるＣＰＵ１１によって実行されるが、これらの機能の一部または全部は、１または複数の専用プロセッサによって実行されてもよい。また、これらの機能の一部または全部は、クラウド技術等を用いて、遠隔値に設置された装置や、分散設置された複数の装置によって実行されてもよい。

【0019】

通信取得部２１は、ネットワークに接続された端末によって送受信される通信のデータを、相手側端末へ到達する前に取得する。なお、本実施形態において、ネットワーク監視装置２０による監視および検知の対象となる「端末」には、ネットワークセグメント２に接続されたノード９０の他、ノード９０とルータ１０を介して通信するその他の端末（他のネットワークに属するノードや外部サーバー等）が含まれる。

【0020】

フロー管理部２２は、通信取得部２１によって取得されたデータが属する通信フロー（以下、単に「フロー」とも称する）を識別し、また、夫々のフローに属するデータが受信される毎に、取得されたデータや解析結果、検査結果に基づいてフローテーブル（図示は省略する）を更新することで、フローを管理する。ここで、フローとは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）のコネクションや、ＳＳＬ／ＴＬＳのセッション等、１まとまりのデータの送受信を識別するための単位である。

【0021】

フローテーブルには、ネットワーク監視装置２０によって取得される通信のフロー毎に、当該フローに係る情報（以下、「フロー関連情報」と称する）が管理されている。本実施形態において、フローはフローＩＤが付されることで識別されており、フロー管理部２２は、フローＩＤをキーとして、フローテーブルから目的のフロー関連情報を索出することが出来る。また、フローは、パケットのヘッダーに含まれるプロトコル番号、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号等を参照することで識別される。このため、新たなフローに係るパケットが受信されると、フロー管理部２２は、フローＩＤを採番し、先述したフローの識別に用いられる情報との対応関係を保持する。

【0022】

更に、フロー管理部２２は、通信取得部２１によって取得された複数のパケットを、当該複数のパケットの夫々が属するフローに基づいて、ノード９０と外部サーバー等との間で送受信される通信の内容を組み立てる。

【0023】

プロトコル解析部２３は、予め設定されたプロトコルの特徴に従って、通信取得部２１によって取得された対象データを解析することで、当該フローに係るプロトコルが何れのプロトコルであるか否かを推定する。また、プロトコル解析部２３は、フロー管理部２２によって組み立てられた通信の内容を参照し、プロトコルを解析することで、当該通信に含まれる、秘匿化の対象となるセッションにおける通信相手の電子証明書を含むセッション確立用メッセージ（本実施形態では、ＳＳＬ／ＴＬＳハンドシェイク）を特定する。

【0024】

証明書抽出部２４は、プロトコル解析部２３によって特定されたセッション確立用メッセージから、電子証明書（サーバー証明書および／または認証局証明書）を抽出する。

【0025】

識別情報抽出部２５は、ノード９０の通信相手であるサーバーの識別情報を抽出する。ここで抽出されるサーバーの識別情報は、例えばＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）やＩＰアドレス等である。また、識別情報抽出部２５は、様々な方法でサーバーの識別情報を抽出してよい。例えば、識別情報抽出部２５は、セッション確立用メッセージ（例えば、ＣｌｉｅｎｔＨｅｌｌｏメッセージのＳＮＩ（Ｓｅｒｖｅｒ Ｎａｍｅ Ｉｎｄｉｃａｔｉｏｎ）フィールド）から通信相手の識別情報を抽出することが出来る。加えて、識別情報抽出部２５は、通信取得部２１によって取得された通信のうち、セッション確立用メッセージの送受信の前にノード９０と外部サーバー等との間で送受信される通信から、通信相手の識別情報を抽出してもよい。ここでいう「セッション確立用メッセージの送受信の前にノード９０と外部サーバー等との間で送受信される通信」とは、例えば名前解決のためのメッセージ送受信や、プロキシサーバーとのセッションを確立するための３ＷＡＹハンドシェイク等である。

【0026】

検査部２６は、電子証明書に含まれる１または複数の所定のフィールドの値と、予め定義された、各フィールドの値が取り得る範囲と、を比較することで、抽出された電子証明書を検査する。また、検査部２６は、外部サーバーから取得された情報に基づいて、電子証明書を検査する。

【0027】

また、検査部２６は、識別情報抽出部２５によって抽出された通信相手の識別情報と、電子証明書（サーバー証明書）に含まれる対象（ｓｕｂｊｅｃｔ）サーバー情報とを比較することで、セッションにおける通信相手の正当性を検査する。

【0028】

更に、検査部２６は、セッション確立用メッセージに含まれる、確立されようとしているセッションにおいて用いられる暗号通信方式（暗号化スイート）と、予め定義された、該情報処理装置が設置された環境において許可される暗号通信方式と、を比較することで、該セッションのセキュリティ強度を更に検査する。

【0029】

情報取得部２７は、外部サーバー（例えば、認証局）から、電子証明書に関する情報を取得する。情報の取得には、ＣＲＬ（Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ：証明書失効リスト）やＯＣＳＰ（Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｔａｔｕｓ Ｐｒｏｔｏｃｏｌ）等を利用することが出来る。

【0030】

イベント処理部２８は、プロトコル解析部２３または検査部２６によってイベントが検知された場合に、当該イベントに係るログ（証跡）を保存または当該イベントの検知をユーザーに通知する。本実施形態において検知されるイベントとしては、例えば、不正な電子証明書の通信や、不正な通信相手、セキュリティポリシーを満たさない通信、プロトコルに沿っていない通信、マルウェアによる通信、等がある。より具体的には、イベント処理部２８は、検査部２６による検査の結果が所定の基準を満たさない場合に、ノード９０、外部サーバー等または該情報処理装置の管理者に対して通知（警告）を送信する。更に、イベント処理部２８は、検査部２６による検査結果をログとして記憶装置１４等に蓄積
する。

【0031】

通信遮断部２９は、検査部２６による検査の結果が所定の基準を満たさない場合、例えば、検査結果が正常でないと判定された場合に、ノード９０と外部サーバー等との間の通信を遮断する。なお、本実施形態では、検査結果が正常でないと判定された場合、当該端末の通信を遮断する対処が採られる例について説明しているが、検査結果が正常でないと判定された場合の対処方法は、通信の遮断に限定されない。ネットワーク監視装置２０は、検査結果が正常でないと判定された場合に、アラート（警告）の通知を行ってもよいし、正常でない通信を行っている端末の治癒（例えば、マルウェアの除去や脆弱性の除去）を行ってもよい。

【0032】

なお、ネットワーク監視装置２０は、例えば、ノード９０に対してＡＲＰ偽装によるパケット送信先の誘導を行う方法や、ルータ１０に指示してノード９０に係る通信を破棄させる方法、またはノード９０が属するＶＬＡＮを変更して隔離する方法、等を用いて、ノード９０による通信を遮断することができる。また、ネットワーク監視装置２０は、ノード９０が受信または送信する通信を直接遮断することもできる。また、ネットワーク監視装置２０は、管理サーバーやノード９０、予め設定された管理者端末等に通知パケットやメール等を送信する方法や、ネットワーク監視装置２０自身に設けられた表示装置（ディスプレイやＬＥＤ等）を介して警告表示する方法等を用いて、アラートを通知することが出来る。

【0033】

＜処理の流れ＞
次に、本実施形態に係るシステム１によって実行される処理の流れを、フローチャートを用いて説明する。なお、以下に説明するフローチャートに示された処理の具体的な内容および処理順序は、本開示を実施するための一例である。具体的な処理内容および処理順序は、本開示の実施の形態に応じて適宜選択されてよい。

【0034】

図４は、本実施形態に係るデータ処理の流れを示すフローチャートである。本実施形態に係るデータ処理は、ネットワーク監視装置２０によって、ネットワーク上を流れるデータが取得される度に実行される。

【0035】

ステップＳ１０１では、データが取得される。通信取得部２１は、ネットワーク上を流れる、ノード９０と外部サーバー等との間の通信に係るデータを取得する。ここで、フロー管理部２２は、対象データを含むパケットのヘッダー等を参照することで、対象データが属するフローを識別し、データが複数のパケットに分割されている場合には、分割された複数のパケットの受信を待つことで、所定の単位のデータを取得する。

【0036】

より具体的には、フロー管理部２２は、通信取得部２１によって新たに通信（入力パケット）が取得されると、入力パケットの整形、分類、および有効な既存フローへの関連付けを行う。また、ネットワーク監視装置２０は、入力パケットを端末単位（送信元／宛先ＩＰアドレス（ＭＡＣアドレス）単位）、トランスポート層およびトランスポート層より上位層のプロトコル（ＴＣＰ、ＵＤＰ、ＩＣＭＰ、ＳＳＬ／ＴＬＳ等）単位に分類、および既存フローとの関連付けを行う。そして、フロー管理部２２は、フローテーブルを参照することで、識別されたフローに係る情報を取得する。その後、処理はステップＳ１０２へ進む。

【0037】

ステップＳ１０２およびステップＳ１０３では、対象データが、ＳＳＬ／ＴＬＳプロトコルのハンドシェイクのためのメッセージであるか否かの解析（パース）が行われる。プロトコル解析部２３は、対象データを参照し、データのパース処理やトランザクションの管理などの解析を行なう。解析は、例えば、予め定義されたプロトコルのデータパターン
との比較等によって行われる。

【0038】

但し、プロトコルの解析に用いられる方法は、本開示における例示に限定されない。例えば、当該プロトコル解析部２３に係るプロトコルのデータパターンとの一致点や不一致点についてポイントを累積し、このポイントと閾値とを比較する方法を用いて、これまでに受信された対象データの当該プロトコルらしさを判定することで、対象データが当該プロトコル解析部２３の担当するプロトコルであるか否かが解析されてもよい。なお、対象データが当該フローに係る２回目以降のデータである場合、即ち、以前に当該フローに係るデータを当該プロトコル解析部２３が解析したことがある場合、解析にあたって、対象データに加えて前回までの解析コンテキストも参照される。

【0039】

プロトコル解析の結果、対象データがＳＳＬ／ＴＬＳのハンドシェイクメッセージでないと判定された場合、処理はステップＳ１０１へ戻る。一方、プロトコル解析の結果、対象データがＳＳＬ／ＴＬＳのハンドシェイクメッセージであると判定された場合、処理はステップＳ１０４へ進む。

【0040】

ステップＳ１０４からステップＳ１０７では、メッセージの種類に応じて、検査に必要な情報が取得される。プロトコル解析部２３は、取得されたＳＳＬ／ＴＬＳのハンドシェイクメッセージが、ハンドシェイクメッセージのうちの何れの種類のメッセージであるかを判定する（ステップＳ１０４）。

【0041】

メッセージの種類がＣｌｉｅｎｔＨｅｌｌｏであった場合、識別情報抽出部２５は、取得されたＣｌｉｅｎｔＨｅｌｌｏメッセージのＳＮＩフィールドから、ノード９０の通信相手であるサーバーの識別情報（具体的には、ＦＱＤＮやＩＰアドレス等）を抽出する（ステップＳ１０５）。但し、ノード９０の通信相手であるサーバーの識別情報は、ノード９０からサーバー宛に送信されたパケットに設定されている宛先ＩＰアドレスから抽出されてもよい。

【0042】

また、メッセージの種類がＳｅｒｖｅｒＨｅｌｌｏであった場合、プロトコル解析部２３は、取得されたＳｅｒｖｅｒＨｅｌｌｏメッセージから、確立されようとしているＳＳＬ／ＴＬＳのセッションにおいて用いられることが提案されている暗号化スイート（暗号通信方法。具体的には、暗号化方式や鍵の強度等）を抽出する（ステップＳ１０６）。

【0043】

また、メッセージの種類がサーバーから送信されたＣｅｒｔｉｆｉｃａｔｅであった場合、証明書抽出部２４は、取得されたＣｅｒｔｉｆｉｃａｔｅメッセージから、ノード９０の通信相手であるサーバーの電子証明書（サーバー証明書）を抽出する（ステップＳ１０７）。

【0044】

ＳＳＬ／ＴＬＳのハンドシェイクメッセージに含まれる各種情報の抽出が行われると、処理はステップＳ１０８へ進む。

【0045】

ステップＳ１０８では、検査に必要な情報の取得処理が完了したか否かが判定される。但し、「取得処理が完了」とは、ステップＳ１０５からステップＳ１０７において取得可能な全ての情報が取得されたことを意味するものではない。例えば、詳細については後述するが、サーバーの識別情報はＣｌｉｅｎｔＨｅｌｌｏメッセージのＳＮＩフィールド以外のパケットからも取得可能であるため、その他のパケットから取得が完了していれば、ステップＳ１０５における取得は不要である。また、何らかの理由（パケットに情報が含まれていない等の理由）でステップＳ１０５からステップＳ１０７において取得すべき情報が取得できなかった場合も、検査を開始するため、取得処理が完了したと判定される。情報の取得処理が完了していない場合、処理はステップＳ１０１へ戻る。一方、情報の取
得処理が完了した場合、処理はステップＳ１０９へ進む。

【0046】

ステップＳ１０９では、検査処理が実行される。本実施形態に係る検査処理では、電子証明書、セッションにおける通信相手の正当性、および秘匿化通信のセキュリティ強度、等が検査される。検査の詳細については、図５を参照して後述する。検査が完了すると、処理はステップＳ１１０へ進む。

【0047】

ステップＳ１１０およびステップＳ１１１では、検査の結果が判定され、検査結果が正常でない場合に、イベント処理が行われる。検査結果が正常でないと判定された場合、イベント処理部２８は、証跡の保存や管理者へ通知などの処理を行なう。また、通信遮断部２９による通信の遮断が行われてもよい。なお、検査結果が正常でないと判定された場合の対処方法は、通信の遮断に限定されない。ネットワーク監視装置２０は、検査結果が正常でないと判定された場合に、アラート（警告）の通知を行ってもよいし、正常ではない通信を行っている端末の治癒（例えば、マルウェアの除去や脆弱性の除去）を行ってもよい。その後、本フローチャートに示された処理は終了する。

【0048】

図５は、本実施形態に係る検査処理の流れを示すフローチャートである。本実施形態に係る検査処理は、図４を参照して説明したデータ処理において、ステップＳ１０９に示された検査処理が呼び出されたことを契機として実行される。即ち、図５に示されたフローチャートは、図４のステップＳ１０９に示された検査処理の詳細を示すものである。

【0049】

ステップＳ２０１では、確立されようとしているセッションにおける通信相手の正当性が検査される。検査部２６は、これまでの処理で得られている、ノード９０の通信相手の識別情報と、サーバー証明書に含まれる対象サーバー情報（具体的には、ｓｕｂｊｅｃｔフィールド、およびｓｕｂｊｅｃｔＡｌｔＮａｍｅフィールドの情報）と、の一致／不一致を検査することによって、確立されようとしているセッションにおける通信相手の正当性を検査する。なお、通信相手の識別情報が得られていない場合、本ステップの処理はスキップされてよい。正当な通信相手ではないと判定された場合、処理はステップＳ２０５へ進む。一方、正当な通信相手であると判定された場合、処理はステップＳ２０２へ進む。

【0050】

ステップＳ２０２では、抽出された電子証明書が正規の証明書であるか否か検査される。検査部２６は、例えば、以下の手順で、ＳＳＬサーバー証明書の正当性を検査する。

【0051】

（１） ＳＳＬ／ＴＬＳ ＨａｎｄｓｈａｋｅプロトコルのＳｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅメッセージを監視する。なお、ＳＳＬセッションの再利用（ＳＳＬセッションキャッシュ）シーケンスでは、Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅメッセージは送信されないため、この項目は検査されない。

【0052】

（２） Ｓｅｒｖｅｒ Ｃｅｒｔｉｆｉｃａｔｅメッセージに含まれるＳＳＬサーバー証明書の内容を検査する。例えば、検査部２６は、以下の条件を満たさない証明書を、不正なＳＳＬサーバー証明書とみなす。
・ｖｅｒｓｉｏｎフィールドの値がｖ３（０ｘ０２）である（ｖ３以外の古い形式は認めない）。
・ｖａｌｉｄｉｔｙフィールドの「ｎｏｔＢｅｆｏｒｅ」と「ｎｏｔＡｆｔｅｒ」の値が妥当（ｎｏｔＢｅｆｏｒｅが現在より過去、ｎｏｔＡｆｔｅｒが現在より未来である）である。
・ｅｘｔｅｎｓｉｏｎｓフィールドの「ｋｅｙＵｓａｇｅ（Ｉｄ：２．５．２９．１５）」や「ｅｘｔＫｅｙＵｓａｇｅ（Ｉｄ：２．５．２９．３７）」拡張フィールドに正当な値が設定されている（例えば、Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅビットや、ｓｅｒｖ
ｅｒＡｕｔｈ（ＫｅｙＰｕｒｐｏｓｅＩｄ：１．３．６．１．５．５．７．３．１）が設定されていることを確認する）。

【0053】

（３） 正当な認証局が発行したＳＳＬサーバー証明書であることを検証する。例えば、以下の何れかの条件を満たす場合は、自己署名ＳＳＬサーバー証明書とみなす。
・ｉｓｓｕｅｒフィールドとｓｕｂｊｅｃｔフィールドの値が一致する。
・信頼出来る認証局によって署名された証明書でない。

【0054】

また、証明書チェーンに認証局証明書が含まれている場合、同様の手法（各フィールドの内容チェック）を用いて、この認証局証明書もチェックされてよい。

【0055】

以上の手順による検査の結果、電子証明書が正規の証明書ではない（不正な証明書である）と判定された場合、処理はステップＳ２０５へ進む。一方、電子証明書が正規の証明書であると判定された場合、処理はステップＳ２０３へ進む。

【0056】

また、ネットワーク監視装置２０は、より詳細な検査を行なう為に、抽出された証明書に示されている認証局の存在を確認したり、証明書の付加情報を自発的に入手して検査したりしてもよい。具体的には、情報取得部２７が、認証局等の外部サーバーから、電子証明書に関する情報を取得する。情報の取得には、ＣＲＬやＯＣＳＰ等を利用することが出来る。そして、検査部２６は、外部のサービス（ＣＲＬやＯＣＳＰレスポンダ等）へ問い合わせて得られた情報を用いて、より正確に証明書の有効性を検査する。検査部２６は、外部から取得された１または複数の情報と、予め定義された、各情報の値が取り得る範囲と、を比較することで、電子証明書を検査する。また、検査部２６は、上位の認証局証明書の鍵を用いて、サーバー証明書の署名を検査するといった、通常の終端アプリケーションが行なう検査を行ってもよい。

【0057】

ステップＳ２０３では、確立されようとしているセッションにおいて用いられる暗号化スイートのセキュリティ強度が検査される。検査部２６は、セッション確立用メッセージから抽出した暗号化スイートの内容と、予め設定された所定の基準とを比較する。暗号化スイートのセキュリティ強度が所定の基準（例えば、管理者によって設定されたセキュリティポリシー）を満たしていないと判定された場合、処理はステップＳ２０５へ進む。一方、暗号化スイートのセキュリティ強度が所定の基準を満たしていると判定された場合、処理はステップＳ２０４へ進む。

【0058】

ステップＳ２０４では、検査結果として、検査結果が正常である旨を示す値が設定される。その後、本フローチャートに示された処理は終了し、図４に示されたデータ処理に戻る。

【0059】

ステップＳ２０５では、検査結果として、検査結果が正常ではない旨を示す値が設定される。その後、本フローチャートに示された処理は終了し、図４に示されたデータ処理に戻る。

【0060】

＜バリエーション１＞
次に、通信相手の情報を取得する方法のバリエーションを説明する。ノード９０において通信を終端するクライアントアプリケーションは、自身が接続したい通信相手の情報を保持しているため、自身が保持している通信相手の情報を用いて通信相手の正当性を検査することが可能であるが、本実施形態に示されたネットワーク監視装置２０は、伝送路上でノード９０の通信相手の正当性を検査するため、ノード９０の通信相手の情報を有していない。このため、ネットワーク監視装置２０は、ノード９０の通信相手の情報を、通信データから取得する必要がある。通信相手の情報は、以下の何れかから取得することが出
来る。
（１）ノード９０が実際に通信するサーバーの宛先ＩＰアドレス
（２）ノード９０が名前解決に用いたＤＮＳクエリおよびリプライに含まれるＦＱＤＮ
（３）ノード９０がＨＴＴＰプロキシに対し、トンネル接続を要求するＣＯＮＮＥＣＴメソッドのＵＲＩ
（４）ノード９０がおこなうＳＳＬ／ＴＬＳハンドシェイクのＣｌｉｅｎｔＨｅｌｌｏメッセージに含まれるＳＮＩフィールド
このうち、（１）および（４）については図４に示されたフローチャートを用いて説明済みであるため、以下に、図６および図７を用いて、（２）および（３）について説明する。

【0061】

図６は、本実施形態に係る、ＳＳＬ／ＴＬＳセッション確立処理およびその前に実行される名前解決処理の流れを示すシーケンス図である。このシーケンス図に示された名前解決処理は、図４および図５を用いて説明したデータ処理および検査処理の前に実行される。通信取得部２１によって取得された通信が、プロトコル解析部２３によって名前解決プロトコルであると判定された場合、識別情報抽出部２５は、名前解決のためのメッセージ（ＤＮＳクエリまたはリプライ）から、名前解決を要した通信相手の識別情報を抽出する。即ち、図６に示された例では、識別情報抽出部２５は、セッション確立用メッセージの前に送受信される通信の内容から、通信相手の識別情報を抽出する。

【0062】

そして、検査部２６は、識別情報抽出部２５によって抽出された識別情報、および名前解決の後にステップＳ１０５で取得される識別情報の、何れか一方又は両方を用いて、通信相手の正当性を検査する（検査の詳細については、ステップＳ２０１を参照）。

【0063】

図７は、本実施形態に係るＳＳＬ／ＴＬＳセッション確立処理およびその前に実行されるプロキシサーバーとのセッション確立処理の流れを示すシーケンス図である。このシーケンス図に示されたプロキシサーバーとのセッション確立処理は、図４および図５を用いて説明したデータ処理および検査処理の前に実行される。通信取得部２１によって取得された通信が、プロトコル解析部２３によってプロキシサーバーとのコネクション確立のための通信であると判定された場合、識別情報抽出部２５は、プロキシサーバーへのセッション確立用メッセージ（ＨＴＴＰ ＣＯＮＮＥＣＴメソッド）に含まれる、該仲介サーバーを介した通信の宛先を示す情報（ＵＲＩ）から、通信相手の識別情報を抽出する。

【0064】

その後、プロキシサーバー（仲介サーバー）は、ノード９０と外部サーバー等との間の通信を仲介する。即ち、図６に示された例では、識別情報抽出部２５は、セッション確立用メッセージの前に送受信される通信の内容から、通信相手の識別情報を抽出する。なお、プロキシサーバーとのセッション確立後、ＳＳＬ／ＴＬＳのセッション確立用メッセージは、プロキシサーバーによるトンネルを介して送受信される。

【0065】

そして、検査部２６は、識別情報抽出部２５によって抽出された識別情報、およびプロキシサーバーとのセッション確立の後にステップＳ１０５で取得される識別情報の、何れか一方又は両方を用いて、通信相手の正当性を検査する（検査の詳細については、ステップＳ２０１を参照）。

【0066】

＜バリエーション２＞
上記実施形態では、ネットワーク監視装置２０が、スイッチまたはルータと、その上位にある他のスイッチまたはルータと、の間に接続されることでノード９０によって送受信されるパケットやフレーム等を取得し、遮断しなくてもよいパケットについては転送するインラインモードで動作する例について説明した（図１を参照）。但し、上記実施形態に示したネットワーク構成は、本開示を実施するための一例であり、実施にあたってはその
他のネットワーク構成が採用されてもよい。

【0067】

例えば、ネットワーク監視装置２０は、スイッチまたはルータ（図１に示した例では、ルータ１０）のモニタリングポート（ミラーポート）に接続されることで、ノード９０によって送受信されるパケットやフレーム等を取得してもよい（図８を参照）。この場合、ネットワーク監視装置２０は、取得したパケットを転送しないパッシブモードで動作する。また、例えば、ネットワーク監視装置２０は、モニタリングポート（ミラーポート）に接続されず、単にネットワークセグメント２に接続されている場合であっても、ネットワークセグメント２を流れるフレームを、自身のＭＡＣアドレス宛でないものも含めて全て取得することで、ノード９０によって送受信されるパケットやフレーム等を取得することが出来る。この場合も、ネットワーク監視装置２０は、パッシブモードで動作する。また、例えば、ネットワーク監視装置２０は、ルータまたはスイッチに内包されてもよい。

【符号の説明】

【0068】

１ システム
２０ ネットワーク監視装置
９０ ノード

【要約】

【課題】電子証明書の検査漏れを低減させることを課題とする。
【解決手段】ネットワーク監視装置に、相手側端末へ到達する前に通信取得する通信取得部と、取得された通信のプロトコルを解析することで、該通信に含まれる、秘匿化の対象となるセッションにおける通信相手の電子証明書を含むセッション確立用メッセージを特定する、プロトコル解析部と、特定されたセッション確立用メッセージから電子証明書を抽出する証明書抽出部と、抽出された電子証明書を検査する検査部と、を備えた。
【選択図】図３

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】