JP6868188B2 - 通信制御装置及びプログラム - Google Patents

Description

本発明は、通信制御装置及びプログラムに関する。

ユーザ端末とサーバとの間でのインターネットを介する通信のセキュリティを確保するために、ＴＬＳ（Transport Layer Security）又はＳＳＬ（Secure Socket Layer）のプロトコルが用いられる。これらのプロトコルは、ＰＫＩ（公開鍵基盤）技術を利用している。ユーザ端末とサーバとが通信を開始する際に、互いの公開鍵証明書（以下単に「証明書」と呼ぶ）を交換し合い、これら証明書を用いてＰＫＩの仕組みを利用することで、その後の通信に用いる暗号鍵の交換を行う。

従来技術として、ユーザ端末のウェブブラウザ等が、サーバからの証明書を検証し、証明書が妥当でないとの検証結果を得た場合に、その旨を画面表示し、通信を続行するかどうかをユーザに問い合わせる技術がある。

また、従来、ＬＡＮ（ローカルエリアネットワーク）内のユーザ端末からインターネット上のサーバへのＴＬＳ／ＳＳＬ接続が開始された際、インターネットへの出口に設けられたゲートウェイ装置が、サーバの証明書をチェックすることも行われている。

特許文献１に開示されるゲートウェイサーバ装置は、一時的な暗号通信中継許可証およびその対の秘密鍵を生成し、それらを用いてクライアント装置とゲートウェイサーバ装置との間で暗号化通信を行う。そのとき、暗号通信中継許可証、秘密鍵、クライアント装置のＩＰアドレス、コンテンツサーバ名、通信方法等をデータベースサーバに登録する。そして、コンテンツサーバ装置との間で、暗号化通信を行う。従って、ゲートウェイサーバ装置において、暗号化通信がいったん終端されるので、そこで種々の付加価値処理を行うことができるようになる。

特許文献２には、クライアント端末と情報処理装置との間で通信される通信データを中継する仕組みが開示される。この仕組みは、クライアント端末と通信データの通信で用いられる第１のＳＳＬ通信を確立する第１確立部と、情報処理装置と通信データの通信で用いられる第２のＳＳＬ通信を確立する第２確立部と、第２確立部で第２のＳＳＬ通信を確立する際に情報処理装置から取得される情報処理装置の公開鍵証明書を、第１の確立部により第１のＳＳＬ通信を確立するクライアント端末に送信する送信部を備える。

特許文献３には、クライアント端末と情報処理装置との間で通信される通信データを中継する仕組みが開示される。この仕組みは、クライアント端末と情報処理装置との間の通信データを中継するために用いられるＳＳＬ通信を情報処理装置と確立する際に情報処理装置から取得される情報処理装置の公開鍵証明書と、中継処理装置が信頼する認証局により発行された公開鍵証明書とを用いて、当該情報処理装置の公開鍵証明書が前記認証局により発行されたものであるか否かを判定し、その判定結果に従って、クライアント端末と情報処理装置との間の通信データの中継を許可するか否かを決定する。

特開２００６−１６５６７８号公報 特開２０１１−１５１７８５号公報 特開２０１２−１３７９７５号公報

通信先の情報処理装置から通信元に送信された公開鍵証明書が検証の結果妥当でないと分かった場合、その通信を許可しないことがセキュリティ上基本的には妥当である。しかし、検証により公開鍵証明書が妥当でないと判定されたからといって一律に通信を許可しないようにすると、かえって不便な場合がある。例えば、通信先の情報処理装置が、通信元には安全と分かっているが、費用節約等何らかの事情で一般的な検証では妥当でないと判定される公開鍵証明書を用いている場合がその一例である。一般的な検証で妥当と判定される公開鍵証明書は、しかるべき発行者から発行を受けるためかなりの費用がかかる。

本発明は、公開鍵証明書が妥当でない場合に一律に通信を許可しない方式と比べて、通信を許可するか否かをより柔軟に制御できるようにすることを目的とする。

請求項１に係る発明は、第１の情報処理装置から第２の情報処理装置へ送られる公開鍵証明書を取得する取得手段と、前記取得手段が取得した前記公開鍵証明書が妥当でない場合に、前記第１の情報処理装置と前記第２の情報処理装置との通信を許可するか否かの制御を行う制御手段と、を含み、前記制御手段は、前記公開鍵証明書が妥当でない場合に、公開鍵証明書が妥当でない場合の処置を示したポリシー情報に従い、前記第１の情報処理装置と前記第２の情報処理装置との通信を許可するか否かの制御を行い、前記ポリシー情報は、公開鍵証明書が妥当でないと判定される原因事象毎に前記処置を示すものであり、前記制御手段は、前記公開鍵証明書が妥当でない場合、前記ポリシー情報に示される、妥当でないと判定された原因事象に対応する処置に従い、前記通信を許可するか否かの制御を行う、ことを特徴とする通信制御装置である。

請求項２に係る発明は、検証手段が検証した、前記第１の情報処理装置からの最新の公開鍵証明書を記憶する記憶手段を更に備え、前記公開鍵証明書が妥当でない場合とは、前記取得手段が取得した前記第１の情報処理装置からの前記公開鍵証明書が、前記記憶手段に記憶されているものと異なる場合であり、前記ポリシー情報とは、前記第１の情報処理装置の公開鍵証明書が変更された場合の処置を示したものであることを特徴とする、請求項１に記載の通信制御装置である。

請求項３に係る発明は、コンピュータを、第１の情報処理装置から第２の情報処理装置へ送られる公開鍵証明書を取得する取得手段、前記取得手段が取得した前記公開鍵証明書が妥当でない場合に、前記第１の情報処理装置と前記第２の情報処理装置との通信を許可するか否かを制御する制御手段、として機能させるためのプログラムであって、前記制御手段は、前記公開鍵証明書が妥当でない場合に、公開鍵証明書が妥当でない場合の処置を示したポリシー情報に従い、前記第１の情報処理装置と前記第２の情報処理装置との通信を許可するか否かの制御を行い、前記ポリシー情報は、公開鍵証明書が妥当でないと判定される原因事象毎に前記処置を示すものであり、前記制御手段は、前記公開鍵証明書が妥当でない場合、前記ポリシー情報に示される、妥当でないと判定された原因事象に対応する処置に従い、前記通信を許可するか否かの制御を行う、ことを特徴とするプログラムである。

請求項１又は３に係る発明によれば、公開鍵証明書が妥当でない場合に一律に通信を許可しない方式と比べて、通信を許可するか否かをより柔軟に制御できる。また、公開鍵証明書が妥当でない場合の処置が一律である場合と比べて、妥当でないことの原因事象に応じてよりきめ細かい制御が可能になる。

請求項２に係る発明によれば、第１の情報処理装置の公開鍵証明書が変更を考慮しない場合と比べて、きめ細かい制御が可能になる。

実施形態のシステム構成の例を示す図である。 実施形態のゲートウェイ装置の機能構成の例を示す図である。 実施形態のゲートウェイ装置の処理手順の例を示す図である。 第１の変形例のゲートウェイ装置の機能構成の例を示す図である。 第１の変形例のゲートウェイ装置の処理手順の例を示す図である。 第２の変形例におけるポリシーＤＢ（データベース）のデータ内容の例を示す図である。 第３の変形例におけるポリシーＤＢのデータ内容の例を示す図である。 第４の変形例における検索結果ＤＢのデータ内容の例を示す図である。 第４の変形例におけるポリシーＤＢのデータ内容の例を示す図である。 第４の変形例のゲートウェイ装置の処理手順の例を示す図である。

図１に示すように、本実施形態の制御は、ローカルネットワーク２５０とインターネット３５０との間の通信を中継するゲートウェイ装置１００で実行される。ローカルネットワーク２５０は、例えば、ＬＡＮやイントラネット等である。例えば、ゲートウェイ装置１００は、ローカルネットワーク２５０上のユーザ端末２００からの、サーバ３００宛のリクエストをインターネット３５０へと中継する。インターネット３５０に送出されたそのリクエストは、宛先であるサーバ３００に伝達される。またゲートウェイ装置１００は、そのリクエストに対するサーバ３００からのレスポンスをインターネット３５０経由で受け取り、ユーザ端末２００へと転送する。なお、これに限定されるものではないが、ユーザ端末２００は例えばパーソナルコンピュータであり、サーバ３００はウェブサーバである。図では、ユーザ端末２００及びサーバ３００を１つずつしか示さなかったが、ローカルネットワーク２５０上にはユーザ端末２００は複数存在し、それらユーザ端末２００がインターネット３５０上の様々なサーバ３００にリクエストを送り、レスポンスを受け取る。

ユーザ端末２００とサーバ３００との間での通信のセキュリティを確保するために、ＴＬＳ（Transport Layer Security）又はＳＳＬ（Secure Socket Layer）のプロトコルが用いられる。これらのプロトコルは、ＰＫＩ（公開鍵基盤）技術を利用している。ユーザ端末２００とサーバ３００とが通信を開始する際、サーバ３００の公開鍵証明書（以下単に「証明書」と呼ぶ）をユーザ端末に送信し、この証明書を用いてＰＫＩの仕組みを利用することで、その後の通信に用いる暗号鍵の交換を行う。本実施形態では、ゲートウェイ装置１００は、サーバ３００からユーザ端末２００宛に送られてくるサーバ３００の証明書を検証し、検証が失敗した場合には、サーバ３００が信頼できないと判断し、基本的にはユーザ端末２００・サーバ３００間の通信を遮断する。ただし、サーバ３００の中には、費用節約等何らかの事情で一般的な証明書検証では検証失敗となる証明書を用いざるを得ないが、ローカルネットワーク２５０側にはあらかじめ安全であることが分かっているものもある。例えば、ローカルネットワーク２５０が設けられた組織内の者が、例えば短期的なプロジェクト等のためにインターネット３５０上に一時的に設けたサイトがその一例である。本実施形態のゲートウェイ装置１００は、そのようにあらかじめ安全と分かっているサーバ３００については、証明書検証が失敗しても通信を許可する仕組みを有する。

図２に、本実施形態のゲートウェイ装置１００の機能的な構成を示す。

妥当性検証部１０２は、ＴＬＳ／ＳＳＬによる通信の開始時にサーバ３００からユーザ端末２００に送られてくる証明書の妥当性（有効性ともいう）を検証する。ユーザ端末２００があるＵＲＬ（Uniform Resource Locator）が指し示すサーバ３００と通信を開始しようとする際、ＴＬＳ／ＳＳＬの仕組みでは、まずユーザ端末２００からサーバ３００に対して通信開始通知が送られ、それに対してサーバ３００からユーザ端末２００に、そのサーバ３００の証明書を含む応答が返される。妥当性検証部１０２はそのサーバ３００の証明書の妥当性を検証する。この検証処理は、従来公知のものでよい。

検証結果ＤＢ（データベース）１０４は、妥当性検証部１０２の検証結果を記録するデータベースである。検証結果ＤＢ１０４には、そのサーバ３００のＵＲＬ（ユーザ端末２００が通信開始時に接続先として指定したＵＲＬ）と、妥当性の検証結果（項目「妥当性」）と、証明書自体のファイルとが、互いに対応付けて格納される。「妥当性」の項目において、「○」印はそのＵＲＬからの証明書が「妥当」（「有効」）であることを示し、「×」印はその証明書が「非妥当」（「無効」）であることを示す。

通信可否判断部１０８は、ユーザ端末２００とサーバ３００の通信を許可するか否かを判断する。この判断は、妥当性検証部１０２の検証結果と、ポリシーＤＢ１１０の情報とに基づいて行われる。

ポリシーＤＢ１１０には、各サーバ３００のＵＲＬ毎に、妥当性ポリシーの値が登録されている。なお、図では、煩雑さを避けるためにＵＲＬを簡略化して表現している。

妥当性ポリシーは、妥当性検証部１０２での証明書検証が失敗した場合（すなわち検証結果が「非妥当」の場合）に、ユーザ端末２００からサーバ３００への通信アクセスについての処置（すなわちその通信をどのように取り扱うか）を規定するポリシー（ルール）である。妥当性ポリシーの値には、例えば「通過」、「遮断」、「通知」等がある。「通過」は、その通信を許可することを示し、「遮断」は、その通信を許可しない（したがってその通信を遮断する）ことを示す。「通知」は、その通信を許可するが、その通信の情報（例えば通信が行われた日時、サーバ３００のＵＲＬ、ユーザ端末２００の識別情報等）をネットワーク管理者又はログ記録装置等に通知すること、を示す。例えば、ローカルネットワーク２５０のネットワーク管理者にあらかじめ安全と分かっているＵＲＬについては、ポリシーＤＢ１１０にそのＵＲＬと、「通過」又は「通知」の妥当性ポリシー値とを登録しておけばよい。妥当性ポリシーの値は、ネットワーク管理者が設定する。

図示例において、例えばユーザ端末２００が「moge.com」というＵＲＬにアクセスした場合を考える。この例では、「moge.com」から送られてきた証明書が妥当性検証部１０２で「非妥当」と判定されても、妥当性ポリシーの値が「通知」なので、通信可否判断部１０８は、そのアクセスを許可し、そのアクセスについての情報をネットワーク管理者等に通知する。

図３を参照して、この実施形態におけるゲートウェイ装置１００の処理手順を説明する。

この手順は、ゲートウェイ装置１００が、ローカルネットワーク２５０内のユーザ端末２００がインターネット３５０上のサーバ３００とＴＬＳ／ＳＳＬ通信を開始したことを検知（Ｓ１０）した場合に開始される。この手順では、妥当性検証部１０２が、その通信開始に応じてサーバ３００からユーザ端末２００へと送られる証明書の妥当性を検証する（Ｓ１２）。この検証の結果が「○」（「妥当」）である場合、妥当性検証部１０２は、検証結果ＤＢ１０４に、サーバ３００のＵＲＬに対応付けてその検証結果「○」を記録する（Ｓ１４）。そして、通信可否判断部１０８は、妥当性検証部１０２から検証結果「○」を受け取ると、そのユーザ端末２００からサーバ３００への通信アクセスを許可する（Ｓ１６）。

Ｓ１２での検証結果が「×」（「非妥当」）である場合、妥当性検証部１０２は、検証結果ＤＢ１０４に、サーバ３００のＵＲＬに対応付けてその検証結果の値「×」を記録する（Ｓ１８）。通信可否判断部１０８は、妥当性検証部１０２から検証結果「×」を受け取った場合は、ポリシーＤＢ１１０の妥当性ポリシーに基づいて通信可否の判定を行う（Ｓ２０）。ここでは、まず通信先のサーバ３００のＵＲＬに対応する妥当性ポリシーが登録されていない（あるいはそのＵＲＬがポリシーＤＢ１１０にない）場合には、「不許可」（「遮断」）と判定する。また、サーバ３００のＵＲＬに対応する妥当性ポリシーが登録されている場合には、その妥当性ポリシーの値に従う。すなわち、その妥当性ポリシーが「通過」であれば、ユーザ端末２００からサーバ３００へのアクセスを許可する（Ｓ１６）。また、妥当性ポリシーが「通知」であれば、通信可否判断部１０８は、ユーザ端末２００からサーバ３００への通信の情報をネットワーク管理者に電子メール等で通知したり、ログデータ等として記録したりした上で（Ｓ２２）、その通信を許可する（Ｓ１６）。そして、妥当性ポリシーが「遮断」であれば、ユーザ端末２００からサーバ３００への通信を遮断する（Ｓ２４）。この場合、通信要求元のユーザ端末２００に対して、セキュリティ上の理由で通信不可であること等を示すエラーメッセージを通知してもよい。

次に、第１の変形例について説明する。

図４は、第１の変形例におけるゲートウェイ装置１００の構成を示す。図２に示した実施形態の構成との違いは、変更検出部１０６を有する点と、ポリシーＤＢ１１０に変更ポリシーが登録されている点である。

変更検出部１０６は、今回検証したサーバ３００の証明書が、同じサーバ３００の前回の検証時の証明書から変更されているか否かを判定する。前回と今回の証明書のデータ同士が一致していれば変更はなく、一致していなければ変更されたことになる。ポリシーＤＢ１１０に保持される変更ポリシーは、証明書が前回から変更されている場合の、ユーザ端末２００とサーバ３００との間の通信についての処置を規定する。変更ポリシーの取り得る値は、妥当性ポリシーの場合と同様でよい。

図５を参照して、この変形例の処理手順を説明する。図５において、図３の処理手順内のステップと同様のステップには同一符号を付して説明を省略する。

図５の手順のうち、サーバ３００からの証明書の妥当性検証結果が「×」（Ｓ１２がＮＧの場合）の処理手順は、上記実施形態の場合と同じである。Ｓ１２で証明書が妥当と判定された場合、この変形例では、妥当性検証部１０２がその検証結果を検証結果ＤＢ１０４に登録すると共に（Ｓ１４）、変更検出部１０６がそのサーバ３００のＵＲＬに対応する前回記録した証明書のファイルを検証結果ＤＢ１０４から取得する（Ｓ３０）。そして、取得した前回の証明書と、今回検証した証明書とを比較することで、証明書が変更されたかどうかを判定する（Ｓ３２）。

Ｓ３２の判定結果は３つのケースに分かれる。

まず検証結果ＤＢ１０４に前回の証明書がないケースがある。この場合、ゲートウェイ装置１００は、今回の証明書をサーバ３００のＵＲＬに対応付けて検証結果ＤＢ１０４に保存（Ｓ３４）した上で、ユーザ端末２００とサーバ３００との通信を許可する（Ｓ１６）。

Ｓ３２の判定結果の第２のケースは「変更なし」である。この場合、今回の証明書と同じものが既に検証結果ＤＢ１０４に保存されているので、ゲートウェイ装置１００（通信可否判断部１０８）は、Ｓ３４をスキップし、ユーザ端末２００とサーバ３００との通信を許可する（Ｓ１６）。

Ｓ３２の判定結果の第３のケースは「変更あり」である。この場合、変更検出部１０６は、検証結果ＤＢ１０４内のそのサーバ３００のＵＲＬに対応する前回の証明書のファイルを削除し、代わりに今回の証明書をそのＵＲＬに対応付けて保存する（Ｓ３６）。そして通信可否判断部１０８が、ポリシーＤＢ１１０内の、そのサーバ３００のＵＲＬに対応する変更ポリシーに従って、その通信についての処置を判定する（Ｓ３８）。この判定では、サーバ３００のＵＲＬに対応する変更ポリシーの値が登録されていない（あるいはそのＵＲＬがポリシーＤＢ１１０にない）場合には、通信が「不許可」（「遮断」）と判定する。また、サーバ３００のＵＲＬに対応する変更ポリシーが登録されている場合には、そのポリシーの値に従う。すなわち、その変更ポリシーが「通過」であれば、ユーザ端末２００からサーバ３００へのアクセスを許可し（Ｓ１６）、「通知」であればその通信の情報を管理者等に通知又は記録した上で（Ｓ２２）、その通信を許可する（Ｓ１６）。また、変更ポリシーが「遮断」であれば、ユーザ端末２００からサーバ３００への通信を遮断する（Ｓ２４）。この場合、通信要求元のユーザ端末２００に対して、セキュリティ上の理由で通信不可であること等を示すエラーメッセージを通知してもよい。

変更ポリシーを定めておくことで、例えば証明書が更新された場合にも、ネットワーク管理者の狙いに沿った通信可否の制御が行われる。

次に第２の変形例を説明する。この第２の変形例におけるゲートウェイ装置１００の構成は、図２又は図４に示した上記実施形態又は変形例の構成と同様でよい。

上述の実施形態では、妥当性ポリシーは、証明書検証結果が「非妥当」の場合の処置を規定する１つの値だけであった。これに対し、本実施形態では、証明書の検証結果を細分化し、検証結果のバリエーション毎に処置を規定する。

例えば、一口に証明書の検証結果が「非妥当」といっても、その中には、証明書チェインを遡ってもゲートウェイ装置１００が信頼するルート証明書に到達しない場合（サーバ３００の証明書が自己署名証明書の場合も含む）もあれば、証明書の期限が切れている場合もある。また、通信先のサーバ３００のＵＲＬとその証明書のＣＮ（Common Name）が不一致の場合、証明書が失効リストに含まれている場合、証明書のデータが壊れている場合等も、それぞれ「非妥当」と判定される原因事象に該当する。この第２の変形例では、「非妥当」をそのような原因事象毎に分類し、原因事象単位で妥当性ポリシーの値を設定する。

図６に、この変形例におけるポリシーＤＢ１１０のデータ内容の例を示す。図６の例では、「moge.com」に対する妥当性ポリシーは、検証結果が「○」（すなわち「妥当」）の場合は「通過」、「（証明書の）期限切れ」の場合は「通知」、それら２つ以外の場合（すなわち「期限切れ」以外で「非妥当」の場合）は「遮断」と設定されている。

この変形例の処理では、ゲートウェイ装置１００は、サーバ３００の証明書の検証結果が「非妥当」の場合、その検証結果が「非妥当」を細分化したどのケースであるかを調べ、そのサーバ３００のＵＲＬに対応する妥当性ポリシーのうち、そのケースに該当する処置を選択する。例えば、サーバ「moge.com」からの証明書が「期限切れ」で「非妥当」と判定された場合、ゲートウェイ装置１００（通信可否判断部１０８）は、図６に例示した妥当性ポリシーから、管理者等に「通知」した上で通信を許可する。

また、検証結果と他の条件の組み合わせで、妥当性ポリシーを規定してもよい。例えば検証結果が「期限切れ」の場合、現在日時がその「期限」からみてあらかじめ定めた長さの期間内であれば、通信を許可（例えば「通過」又は「通知」と判定）し、その期間を過ぎると通信を不許可（「遮断」）とするなどである。

このように、検証結果を詳細にケース分けし、ケースに応じて処置を規定することで、より緻密な制御が可能になる。

次に第３の変形例を説明する。この第３の変形例では、図７に示すように、ポリシーＤＢ１１０に、「強制設定」の項目を設ける。「強制設定」の項目が取り得る値は、妥当性ポリシーや変更ポリシーの場合と同様でよい。

ユーザ端末２００が通信先に指定したＵＲＬに対して、ポリシーＤＢ１１０内の「強制設定」項目に値が設定されている場合、ゲートウェイ装置１００は、そのＵＲＬ（サーバ３００）から送られてくる証明書について、妥当性検証や変更の検出は省略し、その項目の値に沿って通信の可否を制御する。

次に第４の変形例について説明する。

上述の実施形態では、ユーザ端末２００がサーバ３００にＴＬＳ／ＳＳＬで通信しようとする都度、サーバ３００からの証明書の妥当性検証を行った。ローカルネットワーク２５０上には複数の（場合によっては非常に多くの）ユーザ端末２００があるので、同じサーバ３００に対して短期間の間に複数の通信が行われることがあり得る。妥当性検証の処理は計算負荷が高いので、短期間の間に何度も同じ証明書を検証するのは、ゲートウェイ装置１００の能力等から好ましくない場合がある。そこで、この変形例では、一度検証した証明書については、その検証からしばらくの間は、その検証の結果を再利用することで、再度の検証を省略する。

この変形例のゲートウェイ装置１００の構成は、図２や図４に示すものと同様でよい。この変形例では、図８に示すように、検証結果ＤＢ１０４に、証明書の妥当性検証を最後に行った日時（「検証日時」）を記録する。図８の例では、「moge.com」からの証明書を最後に検証したのは２０１５年８月２日１５時３０分であり、その際の検証結果は「期限切れ」であり、その証明書のファイルが「ファイル２」という識別名で保存されている。

またこの変形例では、図９に示すように、ポリシーＤＢ１１０に、「キャッシュ有効期間」を登録可能としている。「キャッシュ有効期間」とは、検証結果ＤＢ１０４に記録された「妥当性」の検証結果（キャッシュされた検証結果値）を有効とみなす期間である。すなわち、この変形例では、検証結果ＤＢ１０４に登録された「検証日時」から「キャッシュ有効期間」の間は、その「検証日時」に行った妥当性検証結果を有効なものとして信頼し、実際の妥当性検証の処理は省略する。「キャッシュ有効期間」の値は、ネットワーク管理者が、当該ＵＲＬに対応するサーバ３００に関する知識に基づき適宜定めればよい。なお、「キャッシュ有効期間」は、図示例のようにＵＲＬ毎に個別に設定できるようにしてもよいし、ＵＲＬによらず一律に定めてもよい。

図１０にこの変形例の処理手順を例示する。この手順では、ＴＬＳ／ＳＳＬ接続の開始を検知すると（Ｓ１０）、通信可否判断部１０８は、その通信の接続先のサーバ３００のＵＲＬに対応する「証明書」と「検証日時」が検証結果ＤＢ１０４にあるかどうかを判定する（Ｓ４０）。またＳ４０では、そのときサーバ３００から送られてきた証明書が、そのＵＲＬに対応付けて検証結果ＤＢ１０４に保存されているものと一致するかを判定する。接続先ＵＲＬに対応する「証明書」と「検証日時」が検証結果ＤＢ１０４内にあり、かつその「証明書」がそのＵＲＬから今回送られてきた証明書と一致する場合に、Ｓ４０の判定結果は「あり」（Ｙｅｓ）となる。一方、それら条件のうち１つでも満たされなければ、Ｓ４０の判定結果は「なし」（Ｎｏ）となる。

Ｓ４０の判定結果が「あり」の場合、通信可否判断部１０８は、ポリシーＤＢ１１０からそのＵＲＬに対応する「キャッシュ有効期間」を求め、現在時刻がその「検証日時」からみて「キャッシュ有効期間」内か否かを判定する（Ｓ４２）。この判定の結果がＹｅｓの場合、通信可否判断部１０８は、検証結果ＤＢ１０４内のそのＵＲＬに対応する検証結果（「妥当性」）が「○」（「妥当」）であるか否かを判定する（Ｓ４４）。その検証結果が「○」の場合は、通信可否判断部１０８は、その通信を許可する（Ｓ１６）。またその検証結果が「○」でない場合は、Ｓ２０に進み、そのＵＲＬに対応する妥当性ポリシーに従って、その通信の許可／遮断等の制御を行う。Ｓ２０以降の処理は、図３又は図５に示した上記実施形態等の場合と同様である。

このように、この変形例では、接続先のＵＲＬから送られてきた証明書の検証が、現在から見て「キャッシュ有効期間」内に既になされていれば、その検証結果を信頼して、今回の検証は省略する。

なお、Ｓ４０の判定結果が「ない」の場合、すなわち今回送られてきた証明書が過去に検証されていないか、あるいは検証されていたとしても「キャッシュ有効期間」内でない場合には、Ｓ１２に進み、妥当性検証部１０２によりその証明書を検証する。そして、その検証の結果とその時の日時を検証結果ＤＢ１０４に記録（又は既にあるそのＵＲＬのエントリ内の検証結果及び検証日時を更新）する（Ｓ１４ａ又はＳ１８ａ）。また、このときその証明書をそのＵＲＬに対応付けて検証結果ＤＢ１０４に保存する。その後の処理は図３又は図５に示した上記実施形態等の場合と同様である。

以上に例示したゲートウェイ装置１００は、例えば、内蔵されるコンピュータにそれら各装置の機能を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）を制御するＨＤＤコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。

＜補遺＞
この明細書には、以下に示す技術的な構成も開示されている。
（構成１）
第１の情報処理装置から第２の情報処理装置へ送られる公開鍵証明書を取得する取得手段と、
前記取得手段が取得した前記公開鍵証明書が妥当でない場合に、前記第１の情報処理装置と前記第２の情報処理装置との通信を許可するか否かの制御を行う制御手段と、
を含む通信制御装置。
（構成２）
前記制御手段は、前記公開鍵証明書が妥当でない場合に、公開鍵証明書が妥当でない場合の処置を示したポリシー情報に従い、前記第１の情報処理装置と前記第２の情報処理装置との通信を許可するか否かの制御を行うことを特徴とする構成１に記載の通信制御装置。
（構成３）
前記ポリシー情報は、公開鍵証明書が妥当でないと判定される原因事象毎に前記処置を示すものであり、
前記制御手段は、前記公開鍵証明書が妥当でない場合、前記ポリシー情報に示される、妥当でないと判定された原因事象に対応する処置に従い、前記通信を許可するか否かの制御を行う、ことを特徴とする構成２に記載の通信制御装置。
（構成４）
検証手段が検証した、前記第１の情報処理装置からの最新の公開鍵証明書を記憶する記憶手段、を更に含み、
前記制御手段は、前記取得手段が取得した前記第１の情報処理装置からの前記公開鍵証明書が、前記記憶手段に記憶されているものと異なる場合に、前記第１の情報処理装置の公開鍵証明書が変更された場合の処置を示した第２のポリシー情報に従って、前記第１の情報処理装置と前記第２の情報処理装置との通信を許可するか否かを制御する、ことを特徴とする、構成２又は３に記載の通信制御装置。
（構成５）
検証手段が検証した、前記第１の情報処理装置からの最新の公開鍵証明書と、その検証の日時と、検証結果とを記憶する記憶手段、を更に含み、
前記制御手段は、前記取得手段が前記第１の情報処理装置から取得した公開鍵証明書について、前記記憶手段に記憶された検証の日時が現在日時からみてあらかじめ定められた有効期間内である場合には、前記取得手段が取得した前記公開鍵証明書の検証を省略し、前記記憶手段に記憶された前記検証結果に従って、前記制御を行う、ことを特徴とする構成１〜３のいずれか１項に記載の通信制御装置。
（構成６）
コンピュータを、
第１の情報処理装置から第２の情報処理装置へ送られる公開鍵証明書を取得する取得手段、
前記取得手段が取得した前記公開鍵証明書が妥当でない場合に、前記第１の情報処理装置と前記第２の情報処理装置との通信を許可するか否かを制御する制御手段、
として機能させるためのプログラム。
（各構成の利点）
構成１、２又は６によれば、公開鍵証明書が妥当でない場合に一律に通信を許可しない方式と比べて、通信を許可するか否かをより柔軟に制御できる。
構成３によれば、公開鍵証明書が妥当でない場合の処置が一律である場合と比べて、妥当でないことの原因事象に応じてよりきめ細かい制御が可能になる。
構成４によれば、第１の情報処理装置の公開鍵証明書が変更を考慮しない場合と比べて、きめ細かい制御が可能になる。
構成５によれば、公開鍵証明書を毎回検証する場合と比べて、検証のための処理負荷を軽減することができる。

１００ ゲートウェイ装置、１０２ 妥当性検証部、１０４ 検証結果ＤＢ、１０６ 変更検出部、１０８ 通信可否判断部、１１０ ポリシーＤＢ、２００ ユーザ端末、２５０ ローカルネットワーク、３００ サーバ、３５０ インターネット。

Claims (3)

1. 第１の情報処理装置から第２の情報処理装置へ送られる公開鍵証明書を取得する取得手段と、
   前記取得手段が取得した前記公開鍵証明書が妥当でない場合に、前記第１の情報処理装置と前記第２の情報処理装置との通信を許可するか否かの制御を行う制御手段と、
   を含み、
   前記制御手段は、前記公開鍵証明書が妥当でない場合に、公開鍵証明書が妥当でない場合の処置を示したポリシー情報に従い、前記第１の情報処理装置と前記第２の情報処理装置との通信を許可するか否かの制御を行い、
   前記ポリシー情報は、公開鍵証明書が妥当でないと判定される原因事象毎に前記処置を示すものであり、
   前記制御手段は、前記公開鍵証明書が妥当でない場合、前記ポリシー情報に示される、妥当でないと判定された原因事象に対応する処置に従い、前記通信を許可するか否かの制御を行う、ことを特徴とする通信制御装置。
2. 検証手段が検証した、前記第１の情報処理装置からの最新の公開鍵証明書を記憶する記憶手段を更に備え、
   前記公開鍵証明書が妥当でない場合とは、前記取得手段が取得した前記第１の情報処理装置からの前記公開鍵証明書が、前記記憶手段に記憶されているものと異なる場合であり、
   前記ポリシー情報とは、前記第１の情報処理装置の公開鍵証明書が変更された場合の処置を示したものであることを特徴とする、請求項１に記載の通信制御装置。
3. コンピュータを、
   第１の情報処理装置から第２の情報処理装置へ送られる公開鍵証明書を取得する取得手段、
   前記取得手段が取得した前記公開鍵証明書が妥当でない場合に、前記第１の情報処理装置と前記第２の情報処理装置との通信を許可するか否かを制御する制御手段、
   として機能させるためのプログラムであって、
   前記制御手段は、前記公開鍵証明書が妥当でない場合に、公開鍵証明書が妥当でない場合の処置を示したポリシー情報に従い、前記第１の情報処理装置と前記第２の情報処理装置との通信を許可するか否かの制御を行い、
   前記ポリシー情報は、公開鍵証明書が妥当でないと判定される原因事象毎に前記処置を示すものであり、
   前記制御手段は、前記公開鍵証明書が妥当でない場合、前記ポリシー情報に示される、妥当でないと判定された原因事象に対応する処置に従い、前記通信を許可するか否かの制御を行う、ことを特徴とするプログラム。

Images