JP6868188B2 - 通信制御装置及びプログラム - Google Patents
通信制御装置及びプログラム Download PDFInfo
- Publication number
- JP6868188B2 JP6868188B2 JP2020007356A JP2020007356A JP6868188B2 JP 6868188 B2 JP6868188 B2 JP 6868188B2 JP 2020007356 A JP2020007356 A JP 2020007356A JP 2020007356 A JP2020007356 A JP 2020007356A JP 6868188 B2 JP6868188 B2 JP 6868188B2
- Authority
- JP
- Japan
- Prior art keywords
- communication
- public key
- information processing
- key certificate
- processing device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Description
本発明は、通信制御装置及びプログラムに関する。
ユーザ端末とサーバとの間でのインターネットを介する通信のセキュリティを確保するために、TLS(Transport Layer Security)又はSSL(Secure Socket Layer)のプロトコルが用いられる。これらのプロトコルは、PKI(公開鍵基盤)技術を利用している。ユーザ端末とサーバとが通信を開始する際に、互いの公開鍵証明書(以下単に「証明書」と呼ぶ)を交換し合い、これら証明書を用いてPKIの仕組みを利用することで、その後の通信に用いる暗号鍵の交換を行う。
従来技術として、ユーザ端末のウェブブラウザ等が、サーバからの証明書を検証し、証明書が妥当でないとの検証結果を得た場合に、その旨を画面表示し、通信を続行するかどうかをユーザに問い合わせる技術がある。
また、従来、LAN(ローカルエリアネットワーク)内のユーザ端末からインターネット上のサーバへのTLS/SSL接続が開始された際、インターネットへの出口に設けられたゲートウェイ装置が、サーバの証明書をチェックすることも行われている。
特許文献1に開示されるゲートウェイサーバ装置は、一時的な暗号通信中継許可証およびその対の秘密鍵を生成し、それらを用いてクライアント装置とゲートウェイサーバ装置との間で暗号化通信を行う。そのとき、暗号通信中継許可証、秘密鍵、クライアント装置のIPアドレス、コンテンツサーバ名、通信方法等をデータベースサーバに登録する。そして、コンテンツサーバ装置との間で、暗号化通信を行う。従って、ゲートウェイサーバ装置において、暗号化通信がいったん終端されるので、そこで種々の付加価値処理を行うことができるようになる。
特許文献2には、クライアント端末と情報処理装置との間で通信される通信データを中継する仕組みが開示される。この仕組みは、クライアント端末と通信データの通信で用いられる第1のSSL通信を確立する第1確立部と、情報処理装置と通信データの通信で用いられる第2のSSL通信を確立する第2確立部と、第2確立部で第2のSSL通信を確立する際に情報処理装置から取得される情報処理装置の公開鍵証明書を、第1の確立部により第1のSSL通信を確立するクライアント端末に送信する送信部を備える。
特許文献3には、クライアント端末と情報処理装置との間で通信される通信データを中継する仕組みが開示される。この仕組みは、クライアント端末と情報処理装置との間の通信データを中継するために用いられるSSL通信を情報処理装置と確立する際に情報処理装置から取得される情報処理装置の公開鍵証明書と、中継処理装置が信頼する認証局により発行された公開鍵証明書とを用いて、当該情報処理装置の公開鍵証明書が前記認証局により発行されたものであるか否かを判定し、その判定結果に従って、クライアント端末と情報処理装置との間の通信データの中継を許可するか否かを決定する。
通信先の情報処理装置から通信元に送信された公開鍵証明書が検証の結果妥当でないと分かった場合、その通信を許可しないことがセキュリティ上基本的には妥当である。しかし、検証により公開鍵証明書が妥当でないと判定されたからといって一律に通信を許可しないようにすると、かえって不便な場合がある。例えば、通信先の情報処理装置が、通信元には安全と分かっているが、費用節約等何らかの事情で一般的な検証では妥当でないと判定される公開鍵証明書を用いている場合がその一例である。一般的な検証で妥当と判定される公開鍵証明書は、しかるべき発行者から発行を受けるためかなりの費用がかかる。
本発明は、公開鍵証明書が妥当でない場合に一律に通信を許可しない方式と比べて、通信を許可するか否かをより柔軟に制御できるようにすることを目的とする。
請求項1に係る発明は、第1の情報処理装置から第2の情報処理装置へ送られる公開鍵証明書を取得する取得手段と、前記取得手段が取得した前記公開鍵証明書が妥当でない場合に、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かの制御を行う制御手段と、を含み、前記制御手段は、前記公開鍵証明書が妥当でない場合に、公開鍵証明書が妥当でない場合の処置を示したポリシー情報に従い、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かの制御を行い、前記ポリシー情報は、公開鍵証明書が妥当でないと判定される原因事象毎に前記処置を示すものであり、前記制御手段は、前記公開鍵証明書が妥当でない場合、前記ポリシー情報に示される、妥当でないと判定された原因事象に対応する処置に従い、前記通信を許可するか否かの制御を行う、ことを特徴とする通信制御装置である。
請求項2に係る発明は、検証手段が検証した、前記第1の情報処理装置からの最新の公開鍵証明書を記憶する記憶手段を更に備え、前記公開鍵証明書が妥当でない場合とは、前記取得手段が取得した前記第1の情報処理装置からの前記公開鍵証明書が、前記記憶手段に記憶されているものと異なる場合であり、前記ポリシー情報とは、前記第1の情報処理装置の公開鍵証明書が変更された場合の処置を示したものであることを特徴とする、請求項1に記載の通信制御装置である。
請求項3に係る発明は、コンピュータを、第1の情報処理装置から第2の情報処理装置へ送られる公開鍵証明書を取得する取得手段、前記取得手段が取得した前記公開鍵証明書が妥当でない場合に、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かを制御する制御手段、として機能させるためのプログラムであって、前記制御手段は、前記公開鍵証明書が妥当でない場合に、公開鍵証明書が妥当でない場合の処置を示したポリシー情報に従い、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かの制御を行い、前記ポリシー情報は、公開鍵証明書が妥当でないと判定される原因事象毎に前記処置を示すものであり、前記制御手段は、前記公開鍵証明書が妥当でない場合、前記ポリシー情報に示される、妥当でないと判定された原因事象に対応する処置に従い、前記通信を許可するか否かの制御を行う、ことを特徴とするプログラムである。
請求項1又は3に係る発明によれば、公開鍵証明書が妥当でない場合に一律に通信を許可しない方式と比べて、通信を許可するか否かをより柔軟に制御できる。また、公開鍵証明書が妥当でない場合の処置が一律である場合と比べて、妥当でないことの原因事象に応じてよりきめ細かい制御が可能になる。
請求項2に係る発明によれば、第1の情報処理装置の公開鍵証明書が変更を考慮しない場合と比べて、きめ細かい制御が可能になる。
図1に示すように、本実施形態の制御は、ローカルネットワーク250とインターネット350との間の通信を中継するゲートウェイ装置100で実行される。ローカルネットワーク250は、例えば、LANやイントラネット等である。例えば、ゲートウェイ装置100は、ローカルネットワーク250上のユーザ端末200からの、サーバ300宛のリクエストをインターネット350へと中継する。インターネット350に送出されたそのリクエストは、宛先であるサーバ300に伝達される。またゲートウェイ装置100は、そのリクエストに対するサーバ300からのレスポンスをインターネット350経由で受け取り、ユーザ端末200へと転送する。なお、これに限定されるものではないが、ユーザ端末200は例えばパーソナルコンピュータであり、サーバ300はウェブサーバである。図では、ユーザ端末200及びサーバ300を1つずつしか示さなかったが、ローカルネットワーク250上にはユーザ端末200は複数存在し、それらユーザ端末200がインターネット350上の様々なサーバ300にリクエストを送り、レスポンスを受け取る。
ユーザ端末200とサーバ300との間での通信のセキュリティを確保するために、TLS(Transport Layer Security)又はSSL(Secure Socket Layer)のプロトコルが用いられる。これらのプロトコルは、PKI(公開鍵基盤)技術を利用している。ユーザ端末200とサーバ300とが通信を開始する際、サーバ300の公開鍵証明書(以下単に「証明書」と呼ぶ)をユーザ端末に送信し、この証明書を用いてPKIの仕組みを利用することで、その後の通信に用いる暗号鍵の交換を行う。本実施形態では、ゲートウェイ装置100は、サーバ300からユーザ端末200宛に送られてくるサーバ300の証明書を検証し、検証が失敗した場合には、サーバ300が信頼できないと判断し、基本的にはユーザ端末200・サーバ300間の通信を遮断する。ただし、サーバ300の中には、費用節約等何らかの事情で一般的な証明書検証では検証失敗となる証明書を用いざるを得ないが、ローカルネットワーク250側にはあらかじめ安全であることが分かっているものもある。例えば、ローカルネットワーク250が設けられた組織内の者が、例えば短期的なプロジェクト等のためにインターネット350上に一時的に設けたサイトがその一例である。本実施形態のゲートウェイ装置100は、そのようにあらかじめ安全と分かっているサーバ300については、証明書検証が失敗しても通信を許可する仕組みを有する。
図2に、本実施形態のゲートウェイ装置100の機能的な構成を示す。
妥当性検証部102は、TLS/SSLによる通信の開始時にサーバ300からユーザ端末200に送られてくる証明書の妥当性(有効性ともいう)を検証する。ユーザ端末200があるURL(Uniform Resource Locator)が指し示すサーバ300と通信を開始しようとする際、TLS/SSLの仕組みでは、まずユーザ端末200からサーバ300に対して通信開始通知が送られ、それに対してサーバ300からユーザ端末200に、そのサーバ300の証明書を含む応答が返される。妥当性検証部102はそのサーバ300の証明書の妥当性を検証する。この検証処理は、従来公知のものでよい。
検証結果DB(データベース)104は、妥当性検証部102の検証結果を記録するデータベースである。検証結果DB104には、そのサーバ300のURL(ユーザ端末200が通信開始時に接続先として指定したURL)と、妥当性の検証結果(項目「妥当性」)と、証明書自体のファイルとが、互いに対応付けて格納される。「妥当性」の項目において、「○」印はそのURLからの証明書が「妥当」(「有効」)であることを示し、「×」印はその証明書が「非妥当」(「無効」)であることを示す。
通信可否判断部108は、ユーザ端末200とサーバ300の通信を許可するか否かを判断する。この判断は、妥当性検証部102の検証結果と、ポリシーDB110の情報とに基づいて行われる。
ポリシーDB110には、各サーバ300のURL毎に、妥当性ポリシーの値が登録されている。なお、図では、煩雑さを避けるためにURLを簡略化して表現している。
妥当性ポリシーは、妥当性検証部102での証明書検証が失敗した場合(すなわち検証結果が「非妥当」の場合)に、ユーザ端末200からサーバ300への通信アクセスについての処置(すなわちその通信をどのように取り扱うか)を規定するポリシー(ルール)である。妥当性ポリシーの値には、例えば「通過」、「遮断」、「通知」等がある。「通過」は、その通信を許可することを示し、「遮断」は、その通信を許可しない(したがってその通信を遮断する)ことを示す。「通知」は、その通信を許可するが、その通信の情報(例えば通信が行われた日時、サーバ300のURL、ユーザ端末200の識別情報等)をネットワーク管理者又はログ記録装置等に通知すること、を示す。例えば、ローカルネットワーク250のネットワーク管理者にあらかじめ安全と分かっているURLについては、ポリシーDB110にそのURLと、「通過」又は「通知」の妥当性ポリシー値とを登録しておけばよい。妥当性ポリシーの値は、ネットワーク管理者が設定する。
図示例において、例えばユーザ端末200が「moge.com」というURLにアクセスした場合を考える。この例では、「moge.com」から送られてきた証明書が妥当性検証部102で「非妥当」と判定されても、妥当性ポリシーの値が「通知」なので、通信可否判断部108は、そのアクセスを許可し、そのアクセスについての情報をネットワーク管理者等に通知する。
図3を参照して、この実施形態におけるゲートウェイ装置100の処理手順を説明する。
この手順は、ゲートウェイ装置100が、ローカルネットワーク250内のユーザ端末200がインターネット350上のサーバ300とTLS/SSL通信を開始したことを検知(S10)した場合に開始される。この手順では、妥当性検証部102が、その通信開始に応じてサーバ300からユーザ端末200へと送られる証明書の妥当性を検証する(S12)。この検証の結果が「○」(「妥当」)である場合、妥当性検証部102は、検証結果DB104に、サーバ300のURLに対応付けてその検証結果「○」を記録する(S14)。そして、通信可否判断部108は、妥当性検証部102から検証結果「○」を受け取ると、そのユーザ端末200からサーバ300への通信アクセスを許可する(S16)。
S12での検証結果が「×」(「非妥当」)である場合、妥当性検証部102は、検証結果DB104に、サーバ300のURLに対応付けてその検証結果の値「×」を記録する(S18)。通信可否判断部108は、妥当性検証部102から検証結果「×」を受け取った場合は、ポリシーDB110の妥当性ポリシーに基づいて通信可否の判定を行う(S20)。ここでは、まず通信先のサーバ300のURLに対応する妥当性ポリシーが登録されていない(あるいはそのURLがポリシーDB110にない)場合には、「不許可」(「遮断」)と判定する。また、サーバ300のURLに対応する妥当性ポリシーが登録されている場合には、その妥当性ポリシーの値に従う。すなわち、その妥当性ポリシーが「通過」であれば、ユーザ端末200からサーバ300へのアクセスを許可する(S16)。また、妥当性ポリシーが「通知」であれば、通信可否判断部108は、ユーザ端末200からサーバ300への通信の情報をネットワーク管理者に電子メール等で通知したり、ログデータ等として記録したりした上で(S22)、その通信を許可する(S16)。そして、妥当性ポリシーが「遮断」であれば、ユーザ端末200からサーバ300への通信を遮断する(S24)。この場合、通信要求元のユーザ端末200に対して、セキュリティ上の理由で通信不可であること等を示すエラーメッセージを通知してもよい。
次に、第1の変形例について説明する。
図4は、第1の変形例におけるゲートウェイ装置100の構成を示す。図2に示した実施形態の構成との違いは、変更検出部106を有する点と、ポリシーDB110に変更ポリシーが登録されている点である。
変更検出部106は、今回検証したサーバ300の証明書が、同じサーバ300の前回の検証時の証明書から変更されているか否かを判定する。前回と今回の証明書のデータ同士が一致していれば変更はなく、一致していなければ変更されたことになる。ポリシーDB110に保持される変更ポリシーは、証明書が前回から変更されている場合の、ユーザ端末200とサーバ300との間の通信についての処置を規定する。変更ポリシーの取り得る値は、妥当性ポリシーの場合と同様でよい。
図5を参照して、この変形例の処理手順を説明する。図5において、図3の処理手順内のステップと同様のステップには同一符号を付して説明を省略する。
図5の手順のうち、サーバ300からの証明書の妥当性検証結果が「×」(S12がNGの場合)の処理手順は、上記実施形態の場合と同じである。S12で証明書が妥当と判定された場合、この変形例では、妥当性検証部102がその検証結果を検証結果DB104に登録すると共に(S14)、変更検出部106がそのサーバ300のURLに対応する前回記録した証明書のファイルを検証結果DB104から取得する(S30)。そして、取得した前回の証明書と、今回検証した証明書とを比較することで、証明書が変更されたかどうかを判定する(S32)。
S32の判定結果は3つのケースに分かれる。
まず検証結果DB104に前回の証明書がないケースがある。この場合、ゲートウェイ装置100は、今回の証明書をサーバ300のURLに対応付けて検証結果DB104に保存(S34)した上で、ユーザ端末200とサーバ300との通信を許可する(S16)。
S32の判定結果の第2のケースは「変更なし」である。この場合、今回の証明書と同じものが既に検証結果DB104に保存されているので、ゲートウェイ装置100(通信可否判断部108)は、S34をスキップし、ユーザ端末200とサーバ300との通信を許可する(S16)。
S32の判定結果の第3のケースは「変更あり」である。この場合、変更検出部106は、検証結果DB104内のそのサーバ300のURLに対応する前回の証明書のファイルを削除し、代わりに今回の証明書をそのURLに対応付けて保存する(S36)。そして通信可否判断部108が、ポリシーDB110内の、そのサーバ300のURLに対応する変更ポリシーに従って、その通信についての処置を判定する(S38)。この判定では、サーバ300のURLに対応する変更ポリシーの値が登録されていない(あるいはそのURLがポリシーDB110にない)場合には、通信が「不許可」(「遮断」)と判定する。また、サーバ300のURLに対応する変更ポリシーが登録されている場合には、そのポリシーの値に従う。すなわち、その変更ポリシーが「通過」であれば、ユーザ端末200からサーバ300へのアクセスを許可し(S16)、「通知」であればその通信の情報を管理者等に通知又は記録した上で(S22)、その通信を許可する(S16)。また、変更ポリシーが「遮断」であれば、ユーザ端末200からサーバ300への通信を遮断する(S24)。この場合、通信要求元のユーザ端末200に対して、セキュリティ上の理由で通信不可であること等を示すエラーメッセージを通知してもよい。
変更ポリシーを定めておくことで、例えば証明書が更新された場合にも、ネットワーク管理者の狙いに沿った通信可否の制御が行われる。
次に第2の変形例を説明する。この第2の変形例におけるゲートウェイ装置100の構成は、図2又は図4に示した上記実施形態又は変形例の構成と同様でよい。
上述の実施形態では、妥当性ポリシーは、証明書検証結果が「非妥当」の場合の処置を規定する1つの値だけであった。これに対し、本実施形態では、証明書の検証結果を細分化し、検証結果のバリエーション毎に処置を規定する。
例えば、一口に証明書の検証結果が「非妥当」といっても、その中には、証明書チェインを遡ってもゲートウェイ装置100が信頼するルート証明書に到達しない場合(サーバ300の証明書が自己署名証明書の場合も含む)もあれば、証明書の期限が切れている場合もある。また、通信先のサーバ300のURLとその証明書のCN(Common Name)が不一致の場合、証明書が失効リストに含まれている場合、証明書のデータが壊れている場合等も、それぞれ「非妥当」と判定される原因事象に該当する。この第2の変形例では、「非妥当」をそのような原因事象毎に分類し、原因事象単位で妥当性ポリシーの値を設定する。
図6に、この変形例におけるポリシーDB110のデータ内容の例を示す。図6の例では、「moge.com」に対する妥当性ポリシーは、検証結果が「○」(すなわち「妥当」)の場合は「通過」、「(証明書の)期限切れ」の場合は「通知」、それら2つ以外の場合(すなわち「期限切れ」以外で「非妥当」の場合)は「遮断」と設定されている。
この変形例の処理では、ゲートウェイ装置100は、サーバ300の証明書の検証結果が「非妥当」の場合、その検証結果が「非妥当」を細分化したどのケースであるかを調べ、そのサーバ300のURLに対応する妥当性ポリシーのうち、そのケースに該当する処置を選択する。例えば、サーバ「moge.com」からの証明書が「期限切れ」で「非妥当」と判定された場合、ゲートウェイ装置100(通信可否判断部108)は、図6に例示した妥当性ポリシーから、管理者等に「通知」した上で通信を許可する。
また、検証結果と他の条件の組み合わせで、妥当性ポリシーを規定してもよい。例えば検証結果が「期限切れ」の場合、現在日時がその「期限」からみてあらかじめ定めた長さの期間内であれば、通信を許可(例えば「通過」又は「通知」と判定)し、その期間を過ぎると通信を不許可(「遮断」)とするなどである。
このように、検証結果を詳細にケース分けし、ケースに応じて処置を規定することで、より緻密な制御が可能になる。
次に第3の変形例を説明する。この第3の変形例では、図7に示すように、ポリシーDB110に、「強制設定」の項目を設ける。「強制設定」の項目が取り得る値は、妥当性ポリシーや変更ポリシーの場合と同様でよい。
ユーザ端末200が通信先に指定したURLに対して、ポリシーDB110内の「強制設定」項目に値が設定されている場合、ゲートウェイ装置100は、そのURL(サーバ300)から送られてくる証明書について、妥当性検証や変更の検出は省略し、その項目の値に沿って通信の可否を制御する。
次に第4の変形例について説明する。
上述の実施形態では、ユーザ端末200がサーバ300にTLS/SSLで通信しようとする都度、サーバ300からの証明書の妥当性検証を行った。ローカルネットワーク250上には複数の(場合によっては非常に多くの)ユーザ端末200があるので、同じサーバ300に対して短期間の間に複数の通信が行われることがあり得る。妥当性検証の処理は計算負荷が高いので、短期間の間に何度も同じ証明書を検証するのは、ゲートウェイ装置100の能力等から好ましくない場合がある。そこで、この変形例では、一度検証した証明書については、その検証からしばらくの間は、その検証の結果を再利用することで、再度の検証を省略する。
この変形例のゲートウェイ装置100の構成は、図2や図4に示すものと同様でよい。この変形例では、図8に示すように、検証結果DB104に、証明書の妥当性検証を最後に行った日時(「検証日時」)を記録する。図8の例では、「moge.com」からの証明書を最後に検証したのは2015年8月2日15時30分であり、その際の検証結果は「期限切れ」であり、その証明書のファイルが「ファイル2」という識別名で保存されている。
またこの変形例では、図9に示すように、ポリシーDB110に、「キャッシュ有効期間」を登録可能としている。「キャッシュ有効期間」とは、検証結果DB104に記録された「妥当性」の検証結果(キャッシュされた検証結果値)を有効とみなす期間である。すなわち、この変形例では、検証結果DB104に登録された「検証日時」から「キャッシュ有効期間」の間は、その「検証日時」に行った妥当性検証結果を有効なものとして信頼し、実際の妥当性検証の処理は省略する。「キャッシュ有効期間」の値は、ネットワーク管理者が、当該URLに対応するサーバ300に関する知識に基づき適宜定めればよい。なお、「キャッシュ有効期間」は、図示例のようにURL毎に個別に設定できるようにしてもよいし、URLによらず一律に定めてもよい。
図10にこの変形例の処理手順を例示する。この手順では、TLS/SSL接続の開始を検知すると(S10)、通信可否判断部108は、その通信の接続先のサーバ300のURLに対応する「証明書」と「検証日時」が検証結果DB104にあるかどうかを判定する(S40)。またS40では、そのときサーバ300から送られてきた証明書が、そのURLに対応付けて検証結果DB104に保存されているものと一致するかを判定する。接続先URLに対応する「証明書」と「検証日時」が検証結果DB104内にあり、かつその「証明書」がそのURLから今回送られてきた証明書と一致する場合に、S40の判定結果は「あり」(Yes)となる。一方、それら条件のうち1つでも満たされなければ、S40の判定結果は「なし」(No)となる。
S40の判定結果が「あり」の場合、通信可否判断部108は、ポリシーDB110からそのURLに対応する「キャッシュ有効期間」を求め、現在時刻がその「検証日時」からみて「キャッシュ有効期間」内か否かを判定する(S42)。この判定の結果がYesの場合、通信可否判断部108は、検証結果DB104内のそのURLに対応する検証結果(「妥当性」)が「○」(「妥当」)であるか否かを判定する(S44)。その検証結果が「○」の場合は、通信可否判断部108は、その通信を許可する(S16)。またその検証結果が「○」でない場合は、S20に進み、そのURLに対応する妥当性ポリシーに従って、その通信の許可/遮断等の制御を行う。S20以降の処理は、図3又は図5に示した上記実施形態等の場合と同様である。
このように、この変形例では、接続先のURLから送られてきた証明書の検証が、現在から見て「キャッシュ有効期間」内に既になされていれば、その検証結果を信頼して、今回の検証は省略する。
なお、S40の判定結果が「ない」の場合、すなわち今回送られてきた証明書が過去に検証されていないか、あるいは検証されていたとしても「キャッシュ有効期間」内でない場合には、S12に進み、妥当性検証部102によりその証明書を検証する。そして、その検証の結果とその時の日時を検証結果DB104に記録(又は既にあるそのURLのエントリ内の検証結果及び検証日時を更新)する(S14a又はS18a)。また、このときその証明書をそのURLに対応付けて検証結果DB104に保存する。その後の処理は図3又は図5に示した上記実施形態等の場合と同様である。
以上に例示したゲートウェイ装置100は、例えば、内蔵されるコンピュータにそれら各装置の機能を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、CPU等のマイクロプロセッサ、ランダムアクセスメモリ(RAM)およびリードオンリメモリ(ROM)等のメモリ(一次記憶)、HDD(ハードディスクドライブ)を制御するHDDコントローラ、各種I/O(入出力)インタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばI/Oインタフェース経由で、CDやDVDなどの可搬型ディスク記録媒体に対する読み取り及び/又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び/又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがCDやDVD等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがRAMに読み出されCPU等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。
<補遺>
この明細書には、以下に示す技術的な構成も開示されている。
(構成1)
第1の情報処理装置から第2の情報処理装置へ送られる公開鍵証明書を取得する取得手段と、
前記取得手段が取得した前記公開鍵証明書が妥当でない場合に、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かの制御を行う制御手段と、
を含む通信制御装置。
(構成2)
前記制御手段は、前記公開鍵証明書が妥当でない場合に、公開鍵証明書が妥当でない場合の処置を示したポリシー情報に従い、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かの制御を行うことを特徴とする構成1に記載の通信制御装置。
(構成3)
前記ポリシー情報は、公開鍵証明書が妥当でないと判定される原因事象毎に前記処置を示すものであり、
前記制御手段は、前記公開鍵証明書が妥当でない場合、前記ポリシー情報に示される、妥当でないと判定された原因事象に対応する処置に従い、前記通信を許可するか否かの制御を行う、ことを特徴とする構成2に記載の通信制御装置。
(構成4)
検証手段が検証した、前記第1の情報処理装置からの最新の公開鍵証明書を記憶する記憶手段、を更に含み、
前記制御手段は、前記取得手段が取得した前記第1の情報処理装置からの前記公開鍵証明書が、前記記憶手段に記憶されているものと異なる場合に、前記第1の情報処理装置の公開鍵証明書が変更された場合の処置を示した第2のポリシー情報に従って、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かを制御する、ことを特徴とする、構成2又は3に記載の通信制御装置。
(構成5)
検証手段が検証した、前記第1の情報処理装置からの最新の公開鍵証明書と、その検証の日時と、検証結果とを記憶する記憶手段、を更に含み、
前記制御手段は、前記取得手段が前記第1の情報処理装置から取得した公開鍵証明書について、前記記憶手段に記憶された検証の日時が現在日時からみてあらかじめ定められた有効期間内である場合には、前記取得手段が取得した前記公開鍵証明書の検証を省略し、前記記憶手段に記憶された前記検証結果に従って、前記制御を行う、ことを特徴とする構成1〜3のいずれか1項に記載の通信制御装置。
(構成6)
コンピュータを、
第1の情報処理装置から第2の情報処理装置へ送られる公開鍵証明書を取得する取得手段、
前記取得手段が取得した前記公開鍵証明書が妥当でない場合に、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かを制御する制御手段、
として機能させるためのプログラム。
(各構成の利点)
構成1、2又は6によれば、公開鍵証明書が妥当でない場合に一律に通信を許可しない方式と比べて、通信を許可するか否かをより柔軟に制御できる。
構成3によれば、公開鍵証明書が妥当でない場合の処置が一律である場合と比べて、妥当でないことの原因事象に応じてよりきめ細かい制御が可能になる。
構成4によれば、第1の情報処理装置の公開鍵証明書が変更を考慮しない場合と比べて、きめ細かい制御が可能になる。
構成5によれば、公開鍵証明書を毎回検証する場合と比べて、検証のための処理負荷を軽減することができる。
この明細書には、以下に示す技術的な構成も開示されている。
(構成1)
第1の情報処理装置から第2の情報処理装置へ送られる公開鍵証明書を取得する取得手段と、
前記取得手段が取得した前記公開鍵証明書が妥当でない場合に、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かの制御を行う制御手段と、
を含む通信制御装置。
(構成2)
前記制御手段は、前記公開鍵証明書が妥当でない場合に、公開鍵証明書が妥当でない場合の処置を示したポリシー情報に従い、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かの制御を行うことを特徴とする構成1に記載の通信制御装置。
(構成3)
前記ポリシー情報は、公開鍵証明書が妥当でないと判定される原因事象毎に前記処置を示すものであり、
前記制御手段は、前記公開鍵証明書が妥当でない場合、前記ポリシー情報に示される、妥当でないと判定された原因事象に対応する処置に従い、前記通信を許可するか否かの制御を行う、ことを特徴とする構成2に記載の通信制御装置。
(構成4)
検証手段が検証した、前記第1の情報処理装置からの最新の公開鍵証明書を記憶する記憶手段、を更に含み、
前記制御手段は、前記取得手段が取得した前記第1の情報処理装置からの前記公開鍵証明書が、前記記憶手段に記憶されているものと異なる場合に、前記第1の情報処理装置の公開鍵証明書が変更された場合の処置を示した第2のポリシー情報に従って、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かを制御する、ことを特徴とする、構成2又は3に記載の通信制御装置。
(構成5)
検証手段が検証した、前記第1の情報処理装置からの最新の公開鍵証明書と、その検証の日時と、検証結果とを記憶する記憶手段、を更に含み、
前記制御手段は、前記取得手段が前記第1の情報処理装置から取得した公開鍵証明書について、前記記憶手段に記憶された検証の日時が現在日時からみてあらかじめ定められた有効期間内である場合には、前記取得手段が取得した前記公開鍵証明書の検証を省略し、前記記憶手段に記憶された前記検証結果に従って、前記制御を行う、ことを特徴とする構成1〜3のいずれか1項に記載の通信制御装置。
(構成6)
コンピュータを、
第1の情報処理装置から第2の情報処理装置へ送られる公開鍵証明書を取得する取得手段、
前記取得手段が取得した前記公開鍵証明書が妥当でない場合に、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かを制御する制御手段、
として機能させるためのプログラム。
(各構成の利点)
構成1、2又は6によれば、公開鍵証明書が妥当でない場合に一律に通信を許可しない方式と比べて、通信を許可するか否かをより柔軟に制御できる。
構成3によれば、公開鍵証明書が妥当でない場合の処置が一律である場合と比べて、妥当でないことの原因事象に応じてよりきめ細かい制御が可能になる。
構成4によれば、第1の情報処理装置の公開鍵証明書が変更を考慮しない場合と比べて、きめ細かい制御が可能になる。
構成5によれば、公開鍵証明書を毎回検証する場合と比べて、検証のための処理負荷を軽減することができる。
100 ゲートウェイ装置、102 妥当性検証部、104 検証結果DB、106 変更検出部、108 通信可否判断部、110 ポリシーDB、200 ユーザ端末、250 ローカルネットワーク、300 サーバ、350 インターネット。
Claims (3)
- 第1の情報処理装置から第2の情報処理装置へ送られる公開鍵証明書を取得する取得手段と、
前記取得手段が取得した前記公開鍵証明書が妥当でない場合に、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かの制御を行う制御手段と、
を含み、
前記制御手段は、前記公開鍵証明書が妥当でない場合に、公開鍵証明書が妥当でない場合の処置を示したポリシー情報に従い、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かの制御を行い、
前記ポリシー情報は、公開鍵証明書が妥当でないと判定される原因事象毎に前記処置を示すものであり、
前記制御手段は、前記公開鍵証明書が妥当でない場合、前記ポリシー情報に示される、妥当でないと判定された原因事象に対応する処置に従い、前記通信を許可するか否かの制御を行う、ことを特徴とする通信制御装置。 - 検証手段が検証した、前記第1の情報処理装置からの最新の公開鍵証明書を記憶する記憶手段を更に備え、
前記公開鍵証明書が妥当でない場合とは、前記取得手段が取得した前記第1の情報処理装置からの前記公開鍵証明書が、前記記憶手段に記憶されているものと異なる場合であり、
前記ポリシー情報とは、前記第1の情報処理装置の公開鍵証明書が変更された場合の処置を示したものであることを特徴とする、請求項1に記載の通信制御装置。 - コンピュータを、
第1の情報処理装置から第2の情報処理装置へ送られる公開鍵証明書を取得する取得手段、
前記取得手段が取得した前記公開鍵証明書が妥当でない場合に、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かを制御する制御手段、
として機能させるためのプログラムであって、
前記制御手段は、前記公開鍵証明書が妥当でない場合に、公開鍵証明書が妥当でない場合の処置を示したポリシー情報に従い、前記第1の情報処理装置と前記第2の情報処理装置との通信を許可するか否かの制御を行い、
前記ポリシー情報は、公開鍵証明書が妥当でないと判定される原因事象毎に前記処置を示すものであり、
前記制御手段は、前記公開鍵証明書が妥当でない場合、前記ポリシー情報に示される、妥当でないと判定された原因事象に対応する処置に従い、前記通信を許可するか否かの制御を行う、ことを特徴とするプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020007356A JP6868188B2 (ja) | 2020-01-21 | 2020-01-21 | 通信制御装置及びプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020007356A JP6868188B2 (ja) | 2020-01-21 | 2020-01-21 | 通信制御装置及びプログラム |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015178549A Division JP2017055298A (ja) | 2015-09-10 | 2015-09-10 | 接続制御装置及びプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2020080540A JP2020080540A (ja) | 2020-05-28 |
JP6868188B2 true JP6868188B2 (ja) | 2021-05-12 |
Family
ID=70802517
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2020007356A Active JP6868188B2 (ja) | 2020-01-21 | 2020-01-21 | 通信制御装置及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP6868188B2 (ja) |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012137975A (ja) * | 2010-12-27 | 2012-07-19 | Canon Marketing Japan Inc | 中継処理装置、及びその制御方法、プログラム |
JP5967822B2 (ja) * | 2012-10-12 | 2016-08-10 | ルネサスエレクトロニクス株式会社 | 車載通信システム及び装置 |
-
2020
- 2020-01-21 JP JP2020007356A patent/JP6868188B2/ja active Active
Also Published As
Publication number | Publication date |
---|---|
JP2020080540A (ja) | 2020-05-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110138718B (zh) | 信息处理***及其控制方法 | |
US9215232B2 (en) | Certificate renewal | |
JP6286504B2 (ja) | 多数のネットワークサイトのためのアカウント管理 | |
US8490165B2 (en) | Restoring secure sessions | |
US8572268B2 (en) | Managing secure sessions | |
JP5723300B2 (ja) | サーバシステム、サービス提供サーバおよび制御方法 | |
JP2006221506A (ja) | ユーザパスワード認証システムにおける権限委譲方法 | |
JP7096736B2 (ja) | システム、及びデータ処理方法 | |
JP2009514050A (ja) | クライアント−サーバ環境においてクライアントを認証するためのシステムおよび方法 | |
JP2015511356A5 (ja) | ||
US10873497B2 (en) | Systems and methods for maintaining communication links | |
JP2020177537A (ja) | 認証認可サーバー、クライアント、サービス提供システム、アクセス管理方法とプログラム | |
JP5991817B2 (ja) | ネットワークシステム | |
CN104935562A (zh) | 信息处理装置、信息处理***、以及信息处理方法 | |
JP6868188B2 (ja) | 通信制御装置及びプログラム | |
JP2017055298A (ja) | 接続制御装置及びプログラム | |
CN111866172A (zh) | 会话票证的处理方法、装置及电子设备 | |
CN108737331B (zh) | 跨域通信方法及跨域通信*** | |
JP2007115107A (ja) | 画像形成装置 | |
EP4002756B1 (en) | Systems and methods of managing a certificate associated with a component located at a remote location | |
JP7521598B2 (ja) | 認証代行装置、認証代行方法および認証代行プログラム | |
JP7423328B2 (ja) | 情報処理装置、情報処理方法及びプログラム | |
CN114237673A (zh) | 一种更新客户端证书的方法、装置及*** | |
CN115834182A (zh) | 一种用户身份认证的方法、装置、存储介质及电子设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20200121 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20210309 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20210322 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 6868188 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |