JP4358795B2 - Ｔｌｓセッション情報の引継ぎ方法及びコンピュータシステム - Google Patents

Description

本発明は、ネットワークを介したサーバ間の安全な情報の引継ぎ技術に関し、さらに詳しくは、ＴＬＳプロトコルのセッション情報をセキュアＯＳが稼動する一つのサーバから別のサーバへ安全に引継ぐ技術に関する。

家庭や企業での急激なインターネットの普及、ブロードバンド化の進展に伴い、電子商取引等が急激に増加している。それに伴い、暗号化技術等のコンピュータシステムにおけるセキュリティ技術の重要性も飛躍的に高まっており、実際のＷｅｂサーバによる電子商取引サイトでは、ＴＬＳ（Transfer Layer Security）プロトコルと呼ばれる通信路の暗号化技術がよく使われている。

ＴＬＳプロトコルは、ＯＳＩ（Open System Interconnection）参照モデルの第５層（セッションレイヤ）に相当するプロトコルであり、ネットワークを介して接続された二つのコンピュータ間のアプリケーションデータの通信を保護するものであり、ＴＬＳプロトコルに従うことにより、主に通信データの暗号化と通信相手の認証ができる。例えば、非特許文献１に詳述されているように、下位層のＴＣＰにより設定された通信路上でレコードデータを送受信して、通信相手の認証、アプリケーションデータの暗号化に必要な鍵生成に利用する乱数データの交換、アプリケーションデータの圧縮、暗号及び改ざん検出等を行うことができる。以下に、その処理手順について概要を説明する。

（１）クライアントとサーバとの間でＴＣＰによるコネクションを確立する。
（２）クライアントとサーバは、ＴＬＳプロトコルに従い、認証、鍵情報の交換を行うハンドシェイク処理を行う。ハンドシェイク処理の第１段として、クライアントがサーバにClientHelloメッセージを送る。ClientHelloメッセージには、鍵生成に利用する乱数データ、クライアントがサポートしている暗号アルゴリズムや圧縮アルゴリズムの識別子が含まれる。なお、ClientHelloメッセージを含め、続くハンドシェイク処理は、レコードデータの一部に含まれてやり取りされる。
（３）ハンドシェイク処理の第２段として、サーバは、ClinetHelloメッセージを受信した後、ServerHello、ServerHelloDoneなどのメッセージを生成して、クライアントに送信する。ServerHelloメッセージには、セッションＩＤ（以下、「ＳＩＤ」という。）が含まれる。ＳＩＤについては後述する。

（４）ハンドシェイク処理の第３段として、クライアントがServerHelloなどのメッセージを受信した後、ClientKeyExchange、ChangeCipherSpec及びFinishedなどのメッセージを生成して、サーバに送信する。ClientKeyExchangeメッセージには暗号鍵生成に使用する乱数データが暗号化されて含まれており、本データとClientHello及びServerHelloメッセージに含まれる乱数データとを合わせてアプリケーションデータの暗号化や改ざん検知に必要な暗号鍵を生成する。これらのデータはＳＩＤと関連付けられており、ＴＣＰによるコネクションを切断後に再度通信を行う場合に再利用される。詳細は後述する。ChangeCipherSpecは以後の通信が圧縮、暗号化されることを示す。Finishedメッセージはクライアント側のハンドシェイク処理が終わったことをサーバに通知する。

（５）ハンドシェイク処理の第４段として、サーバがClientKeyExchangeなどのメッセージを受信し、ClientKeyExchangeに含まれる暗号化乱数データを復号、暗号鍵の生成する。さらに、ChangeCipherSpec及びFinishedメッセージを生成して、クライアントに送信する。
（６）以後、クライアントとサーバは、乱数データから生成した暗号鍵を利用して、通信データを暗号化したり、改ざん検知のためのデータを付加して相手に送信する。受信側は復号、改ざんがないか確認して、アプリケーションデータを取得し、本来のアプリケーションの処理を行う。なお、アプリケーションデータの圧縮を行う場合には、暗号の前に行う。これらの処理はレコード単位で行われる。

上記（１）〜（６）の手順は、初めてクライアントとサーバが通信を行う場合の完全ハンドシェイク処理の手順であり、クライアントとサーバに比較的負荷のかかる処理である。特に、ClientKeyExchangeメッセージに含まれる乱数データの暗号化や復号化による負荷が大きい。これは公開鍵暗号を利用するためである。

このため、２回目以降の通信におけるハンドシェイク処理では、ClientKeyExchangeメッセージのやり取りを省略し、初回の完全なハンドシェイク処理時に交換した乱数データを再利用して、負荷を減らす簡略ハンドシェイク処理が定義されている。以下に、簡略ハンドシェイクによる通信の手順について説明する。

（１）クライアントは、ClientHelloメッセージをサーバに送る。このメッセージには、初回の完全ハンドシェイク処理時に生成したＴＬＳセッションを識別するＳＩＤが含まれている。
（２）サーバは、ClientHelloメッセージを受信した後、ＳＩＤに対応する初回の通信時に交換した乱数データをキャッシュメモリーより取得し、２回目以降の通信における暗号化や改ざん検知に利用する。このＳＩＤを含むServerHello、ChangeCipherSpec及びFinishedメッセージを生成し、クライアントに送信する。
（３）クライアントは、ChangeCipherSpec及びFinishedメッセージを受信する。さらにChangeCipherSpec及びFinishedメッセージを生成し、サーバに送信する。以後の通信は、ＳＩＤに対応した乱数データから鍵を生成、利用して、暗号化する。

以上がＴＬＳプロトコルの概要である。なお、クライアントとサーバで合意した暗号アルゴリズム、圧縮アルゴリズム及び暗号鍵生成に利用する乱数データを含めて、「ＴＬＳセッション情報」という。クライアントとサーバはＳＩＤを用いてＴＬＳセッション情報を識別することができ、簡略ハンドシェイク処理行うことにより、効率的にＴＬＳプロトコルを利用できる。

一方、従来まで軍事技術に属していたセキュリティを強化したオペレーティングシステム（以下、「セキュアＯＳ」という。）が一般に入手可能になった。セキュアＯＳの強制的アクセス制御を利用することにより、Ｗｅｂサーバ等のサーバに脆弱性があり、この脆弱性が攻撃されても、攻撃の被害を当該サーバのみに限定することができる。例えば、「サーバが停止する」、「サーバがアクセス可能なファイルが改ざんされたり外部に漏洩する」等の被害は発生するが、同一コンピュータシステム内の他のサーバが停止したり、被害を受けたサーバがアクセスしないファイルの破壊や漏洩を防ぐことができる。即ち、被害の範囲が、サーバのプロセスが属するドメイン及び役割にＯＳによって許可されたリソースやプロセスのアクセス範囲内に限定される。ここで、ドメイン及び役割とは、プロセスに割当てられたセキュリティ属性であって、セキュアＯＳは、本プロセスのセキュリティ属性とアクセスの対象であるリソースに割当てたセキュリティ属性とを比較して、アクセスを許可するか禁止するかを決定する。
このようなドメイン及び役割によって、たとえアプリケーションに脆弱性があっても被害範囲が限定できるセキュアＯＳの特徴を利用したセキュリティ技術が開発されている。

例えば、非特許文献２では、セキュアＯＳを用いて、Ｗｅｂサーバ等の利用者に与えられている権限（ドメイン）と、その権限で利用可能なリソースの種類（タイプ）を制限することで、利用者が自由に様々なＯＳ上のリソースにアクセスしようとしてもできないように、権限の細分化と最小化を実践する技術が開示されている。なお、ＴＬＳのセッション情報等、通信路の安全性に関る情報の送信・受信については、記載されていない。
また、特許文献１では、異なるコンピュータシステム間で通信路の安全性や役割などの情報を引継ぎ、共有し、移譲するときの方法として、鍵、役割、期間等の情報を含む委任トークンを、暗号技術を用いて安全に交換する技術が開示されている。

特開２００４−１６６２３８号公報 T.Dierk、 C.Allen、「The TLS Protocol ver.1」、InternetRFC2246、Jan.1999 独立行政法人情報処理推進機構セキュリティセンタ著、「強制的アクセス制御に基づく Ｗｅｂ サーバーに関する調査・設計の機能仕様書」、２００５年４月２６日

しかしながら、非特許文献２に記載の技術では、アクセスがある度にＷｅｂサーバを起動しているので、Ｗｅｂサーバへの負荷が大き過ぎるという問題があった。実際、ｔｅｌｎｅｔのような仮想端末のサーバやｆｔｐのようなファイル転送のサーバは比較的に単純で軽量なサーバであるため、アクセスがある度にサーバを起動してもよいが、Ｗｅｂサーバは複雑で大規模であるため、起動するサーバは一つだけであり、この一つのサーバが複数のクライアントによる大量のアクセスを処理している。また、アプリケーションの性質上、Ｗｅｂサーバへのアクセス頻度は非常に高いので、アクセスのたびに、暗号処理のためのサーバを起動するのは非現実的である。
また、特許文献１に記載の技術では、役割等の委任に必要な情報をサーバ間で、トークンにより安全に転送するために暗号技術を用いて保護しているが、送信側と受信側のサーバでそれぞれに暗号処理が必要になるため、サーバの負荷が増大するという問題があった。

上記問題点に鑑み、本発明は、クライアントとネットワークを介して接続されるコンピュータシステムに使用される効率的で、安全なＴＬＳセッション情報の引継ぎ方法を提供することを課題とする。また、本発明は、ＴＬＳセッション情報の引継ぎ方法を用いて、大幅に稼動効率が向上するコンピュータシステムを提供することを課題とする。

上記課題を解決するために、本発明は、以下の特徴を有する。
本発明によるＴＬＳセッション情報の引継ぎ方法は、セキュアＯＳが稼働し、クライアントからの要求を受付ける中継サーバと、ドメイン及び役割が割当てられアプリケーション処理を行う役割サーバと、前記クライアントのユーザとその役割の関連を保持する第１のデータベースと、ＴＬＳプロトコルのセッションＩＤと前記ドメイン及び役割の関連を保持する第２のデータベースと、前記役割サーバごとに用意されたＴＬＳプロトコルのセッション情報を保持する第３のデータベースとを備え、前記中継サーバが、前記第１のデータベースに対しては読取る権限のみを有し、前記第３のデータベースに対しては書込む権限のみを有するコンピュータシステムにより実行されるＴＬＳセッション情報の引継ぎ方法であって、前記中継サーバが、ＴＬＳプロトコルの処理に関しては、ハンドシェイク処理のみを行い、ハンドシェイク処理時に認証したユーザと、前記第１のデータベースから得た役割及びＴＬＳプロトコルのセッションＩＤとを前記第２のデータベースに書込み、ＴＬＳセッション情報をハンドシェイク処理後に前記第３のデータベースに書込んだ後に破棄し、暗号化されたアプリケーションデータを前記役割サーバに中継するステップと、さらに、ＴＬＳプロトコルによるセッションを再開するときは、セッション開始時にクライアントから受信したメッセージに含まれるセッションＩＤをキーにして、前記第２のデータベースから対応する役割サーバを決定し、該役割サーバに前記メッセージを含めて中継するステップと、前記役割サーバが、前記第３のデータベース書込まれた前記ＴＬＳセッション情報を利用してＴＬＳプロトコルによるハンドシェイク処理を行うステップとを有することを特徴とする。

また、本発明によるＴＬＳセッション情報の引継ぎ方法は、前記中継サーバと、前記役割サーバとを、個々にセキュアＯＳが稼動する異なるコンピュータに配置し、前記役割サーバが配置されたコンピュータには、第３のデータベースへ書込む権限のみを有するデータベース追加サーバを配置し、前記中継サーバが、ＴＬＳセッション情報を、データベース追加サーバを介してハンドシェイク処理後に第３のデータベースに書きこんだ後に破棄するステップを有することを特徴とする。

本発明のコンピュータシステムは、セキュアＯＳが稼働し、クライアントからの要求を受付ける中継サーバとドメイン及び役割が割当てられアプリケーション処理を行う役割サーバと前記クライアントのユーザとその役割の関連を保持する第１のデータベースとＴＬＳプロトコルのセッションＩＤと前記ドメイン及び役割の関連を保持する第２のデータベースと前記役割サーバごとに用意されたＴＬＳプロトコルのセッション情報を保持する第３のデータベースとを備え、前記中継サーバが、前記第１のデータベースに対しては読取る権限のみを有し、前記第３のデータベースに対しては書込む権限のみを有するコンピュータシステムであって、前記中継サーバは、ＴＬＳプロトコルの処理に関しては、ハンドシェイク処理のみを行い、ハンドシェイク処理時に認証したユーザと、前記第１のデータベースから得た役割及びＴＬＳプロトコルのセッションＩＤとを前記第２のデータベースに書込み、ＴＬＳセッション情報をハンドシェイク処理後に前記第３のデータベースに書き込んだ後に破棄し、暗号化されたアプリケーションデータを前記役割サーバに中継し、さらに、ＴＬＳプロトコルによるセッションを再開するときは、セッション開始時にクライアントから受信したメッセージに含まれるセッションＩＤをキーにして、前記第２のデータベースから対応する役割サーバを決定し、該役割サーバに前記メッセージを含めて中継し、前記役割サーバは、前記第３のデータベースに書込まれた前記ＴＬＳセッション情報を利用してＴＬＳプロトコルによるハンドシェイク処理を行うことを特徴とする。

また、本発明のコンピュータシステムは、前記中継サーバと、前記役割サーバとを、個々にセキュアＯＳが稼動する異なるコンピュータに配置し、前記役割サーバが配置されたコンピュータには、第３のデータベースへ書込む権限のみを有するデータベース追加サーバを配置し、前記中継サーバは、ＴＬＳセッション情報を、データベース追加サーバを介してハンドシェイク処理後に第３のデータベースに書きこんだ後に破棄することを特徴とする。

本発明により、中継サーバの完全ハンドシェイク処理で得られたＴＬＳセッション情報を、役割サーバが、アクセスが制限された第３のデータベースにより取得して簡略ハンドシェイク処理を行うことにより、効率的で安全なＴＬＳセッション情報の引継ぎ方法を提供することができる。
また、本発明により、上記方法を用いて、大幅に稼動効率が向上するコンピュータシステムを提供することができる。

以下に、本発明を実施するための最良の形態を図面に基づいて説明する。

（実施の形態１）
図１は、実施の形態１のコンピュータシステムの構成を示す図である。図１に示すように、コンピュータ１００は、中継サーバ１１０、ユーザと役割関連登録ツール１２０、役割１サーバ１３０、役割２サーバ１４０、ＳＩＤと役割関連データベース１５０、ユーザと役割関連データベース１６０及びＴＬＳセッション情報データベース１７０、１８０により構成され、セキュアＯＳが稼働している。さらに、コンピュータ１００には、外部よりクライアントのコンピュータ（以下、「クライアント」という。）２００がネットワークを介して接続されている。以下に、個々の働きについて説明する。

中継サーバ１１０は、クライアント２００がコンピュータ１００にアクセスする最初のサーバである。中継サーバ１１０は、クライアント２００が初めて接続してきたときは、ＴＬＳプロトコルに従うハンドシェイク処理を行い、クライアント２００より取得したＴＬＳセッション情報を役割サーバ１３０、１４０内のＴＬＳセッション情報データベース１７０、１８０に登録する。ここで、セキュアＯＳの機能を用いることにより、中継サーバ１１０は、ＴＬＳセッション情報データベース１７０、１８０に登録、追記等の書込み（w;write）はできるが、読取る（r;read）ことはできないように制限されている。中継サーバ１１０は、ＴＬＳセッション情報データベース１７０、１８０に書込んだ後はＴＬＳセッション情報を破棄する。このようにすることで、中継サーバ１１０に脆弱性があり、外部からの不正アクセスを許可した場合でも、不正侵入者は過去のＴＬＳセッション情報を読み取ることはできない。ハンドシェイク処理後は、暗号化されたままの通信データを役割サーバ１３０、１４０にそのまま中継する。詳細は後述する。

ユーザと役割関連登録ツール１２０は、クライアント２００のユーザとその役割との関係をユーザと役割関連データベース１６０に登録するためのツールである。ユーザと役割関連登録ツール１２０は、ユーザと役割関連データベース１６０への書込み及び読込みの権限を有するが、セキュアＯＳの機能を用いることにより、他のリソース、例えば、ＳＩＤと役割関連データベース１５０やＴＬＳセッション情報データベース１７０、１８０などへのアクセスは禁止されている。

役割サーバ１３０、１４０は、それぞれある役割を持ったアプリケーションサーバであり、本来のアプリケーション処理を行う。役割サーバ１３０、１４０にドメインや役割を割当てることにより、役割サーバ１３０、１４０が不正アクセスされても、アクセス可能なリソースの範囲を限定できる。役割サーバ１３０、１４０は、中継サーバ１１０が行った完全ハンドシェイク処理により取得したＴＬＳセッション情報を用いて簡略ハンドシェイク処理を行う。

ＳＩＤと役割関連データベース１５０は、本発明の第２のデータベースに相当し、中継サーバ１１０のみが読込み及び書込み可能なように、セキュアＯＳの機能により保護されている。
ユーザと役割関連データベース１６０は、本発明の第１のデータベースに相当し、ユーザと役割関連登録ツール１２０は読込み及び書込みが可能であり、中継サーバ１１０は読込みのみ可能となっている。従って、中継サーバ１１０に不正アクセスがあっても、ユーザと役割関連データベース１６０を改ざんすることはできない。

ＴＬＳセッション情報データベース１７０、１８０は、本発明の第３のデータベースに相当し、役割サーバ１３０、１４０にそれぞれ対応して配置されており、対応する役割サーバだけが対応するＴＬＳセッション情報データベースへアクセスできるように、セキュアＯＳの機能を用いて制限されている。即ち、ＴＬＳセッション情報データベース１（１７０）は役割１サーバ１３０からのアクセスのみ許可され、ＴＬＳセッション情報データベース２（１８０）は役割２サーバ１４０からのアクセスのみ許可されるように、セキュアＯＳの機能を用いて制限されている。また、上述したように、中継サーバ１１０からは登録・追記等の書込みのみが可能で読込みはできない。

クライアント２００は、本発明のコンピュータシステム上にあるサーバ１１０、１３０、１４０にアクセスし、アプリケーション処理を要求するコンピュータである。クライアント２００は、役割サーバ１３０、１４０には中継サーバ１１０を介してアクセスする。

図２は、本発明の中継サーバの内部構造を示す図である。
ＴＣＰコネクション処理部１１１は、クライアント２００からのＴＣＰによるコネクションを受け付けたり、データの送受信を行う。一方、ハンドシェイク処理後のクライアント２００と役割サーバ１３０、１４０との通信データの中継も行う他、ハンドシェイク処理部１１３と役割サーバ１３０、１４０とのハンドシェイクメッセージの通信も行う。
レコード処理部１１２は、ＴＣＰコネクション処理部１１１を介して受信したクライアント２００からの受信データを処理する。処理の内容には、受信データをレコードデータ単位に区切ったり、レコードの内容によりその内容をハンドシェイク処理部１１３に渡す。逆に、ハンドシェイク処理部１１３からメッセージを受取り、ＴＣＰコネクション処理部１１１を介してクライアント２００や役割サーバ１３０、１４０に送信する。
ハンドシェイク処理部１１３は、上述したようなクライアント２００との完全ハンドシェイクの他、クライアント２００や役割サーバ１３０、１４０との簡略ハンドシェイク処理の一部を行う。

図３は、本発明の役割サーバの内部構造を示す図である。ここでは、役割１サーバ１３０の内部構造示すが、役割２サーバ１４０の内部構造も同様である。
ＴＣＰコネクション処理部１３１は、中継サーバ１１０からのコネクションを受付けたり、受信データをレコード処理部１３２に渡したり、逆に、レコード処理部１３２から受け取ったデータを中継サーバ１１０に送信する。

レコード処理部１３２は、ＴＣＰコネクション処理部１３１を介して受信した中継サーバ１１０からの受信データを処理する。処理の内容には、受信データをレコード単位に区切ったり、レコードの内容によりその内容をハンドシェイク処理部１３３やサーバデータ処理部１３４に渡したり、圧縮データの場合には伸張、暗号化データの場合には復号などを行う。逆に、ハンドシェイク処理部１３３からメッセージ、サーバデータ処理部１３４からアプリケーションデータを受取り、圧縮や暗号化して、ＴＣＰコネクション処理部１３１を介して中継サーバ１１０に送信する。
ハンドシェイク処理部１３３は、中継サーバ１１０を介したクライアント２００との簡略ハンドシェイクを行う。

サーバデータ処理部１３４は、本来のアプリケーション処理を行う。サーバデータ処理部１３４で行う処理は、役割サーバ１３０に与えられたリソースアクセスの範囲内にセキュアＯＳの機能により制限されている。従って、役割サーバ１３０が不正アクセスに遭っても、その被害範囲は限定される。

図４は、本発明のＳＩＤと役割関連データベースの構造を示す図である。各行は、それぞれデータベース内の１つのレコードを示し、ＳＩＤフィールド１５１と役割フィールド１５２からなる。ＳＩＤフィールド１５１の値は、１６バイトからなり、１６進数で表現して例示したものである。本データベースのレコードは、中継サーバ１１０が完全ハンドシェイク処理を行ったときに作成される。クライアントが、再度サーバにアクセスしたときに行う簡略ハンドシェイク処理時に参照され、ＳＩＤフィールドの値により、どの役割サーバ１３０、１４０に通信を中継するかを決定するのに利用される。

図５は、本発明のユーザと役割関連データベース１６０の構造を示す図である。各行は、それぞれデータベース内の一レコードを示し、ユーザのフィールド１６１と役割のフィールド１６２とからなる。クライアント２００がサーバ１１０に初めてアクセスしたときの完全ハンドシェイク処理を行うときに参照される。即ち、ハンドシェイク処理を通じて認証されたクライアントユーザからその役割を決定し、どの役割サーバ１３０、１４０に通信を中継するのかを決定するのに利用される。

図６は、本発明のＴＬＳセッション情報データベース１の構造を示す図である。
インデックス１７１、１７３は、ＳＩＤをそのまま利用する。インデックス１７１は、図４に示す役割１あたる第４行にあるＳＩＤ１５１に、インデックス１７３は、同様に役割１にあたる第３行にあるＳＩＤ１５１に対応する。データ１７２、１７４は、インデックス１７１、１７３に対応するデータそのものであり、ＳＩＤに対応するセッションに利用される暗号アルゴリズムや鍵長、鍵生成に利用する乱数データを含んでいる。

図７は、本発明の中継サーバによる処理内容を示すフローチャートである。以下、フローチャートに従って、説明する。
まず、中継サーバ１１０内のＴＣＰコネクッション処理部１１１が、クライアントからの接続要求を受け付け、受信データをレコード処理部１１２に渡す（ステップ７０１）。以後のクライアントとの送受信は、ＴＣＰコネクション処理部１１１を介して行われる。
次に、レコード処理部１１２は、受信データを解析し、上位データを取り出し、ハンドシェイクのメッセージであることを確認し、ハンドシェイク処理部１１３に渡す（ステップ７０２）。ここでは、受信データはＴＬＳ Record Protocol（非特許文献１参照）の形式をしており、本処理部１１２はＴＬＳプロトコルの処理を行い、上位のアラート、ハンドシェイク、アプリケーションのデータを取出す。この処理は本発明の範囲外なので、ここでは詳細は記載しない。

次に、ハンドシェイク処理部１１３がハンドシェイク処理を行う（ステップ７０３）。処理の内容は、図８を用いて後述する。
次に、ハンドシェイク処理後、ＴＣＰコネクション処理部１１１がクライアント２００と役割サーバ１３０、１４０との通信を中継する（ステップ７０４）。ハンドシェイク処理後は、中継サーバ１１０は本中継処理のみを行う。

図８は、本発明のハンドシェイク処理部が行う処理の詳細を示すフローチャートである。図７に示すステップ７０３のハンドシェイク処理の詳細である。
まず、中継サーバ１１０内のハンドシェイク処理部１１３は、レコード処理部１１２から受け取ったハンドシェイクのメッセージがClientHelloメッセージであることを確認し、さらに、クライアント２００からの初めてのＴＬＳセッションか、過去のセッションの再開かを判断する（ステップ８０１）。判断は、メッセージの中のＳＩＤフィールドにより決定する。即ち、ＳＩＤフィールドが空白なら初めてのセッションであり、ＳＩＤが入っていれば再開を示す。
次に、初めてのセッションなら完全ハンドシェイク処理を行い、過去のセッションの再開なら簡略ハンドシェイク処理を行う（ステップ８０２）。

図９は、図８のステップ８０２に記載の完全ハンドシェイク処理の詳細を示すフローチャートである。
ハンドシェイク処理部１１３は、ServerHello他のハンドシェイクメッセージを生成し、レコード処理部１１２やＴＣＰコネクション処理部１１１を介して、クライアント２００に送信する（ステップ９０１）。
次に、ハンドシェイク処理部１１３は、クライアント２００が送信し、ＴＣＰコネクション処理部１１１及びレコード処理部１１２を介して受信したCertificate等のメッセージを受取り、処理する（ステップ９０２）。この処理により、通信相手のクライアント２００を認証して、クライアントユーザが判明する。
次に、Finished等のハンドシェイクメッセージを生成し、クライアント２００に送信する（ステップ９０３）。
なお、上述のメッセージの生成・処理方法は、標準規格であるＴＬＳプロトコル（非特許文献１参照）に従うものであり、詳細は記載しない。

次に、ハンドシェイク処理部１１３は、ステップ９０２にて認証したクライアントユーザに対する役割を、ユーザと役割関連データベース１６０を検索することにより、いずれの役割サーバ１３０、１４０が中継先かを決定する。役割の検索は、図５に示すように、認証したユーザに当たるユーザのフィールド１６１を有するレコードを探し、そのレコードの役割フィールド１６２の値を認識することにより行う（ステップ９０４）。
次に、ハンドシェイク処理部１１３は、ＳＩＤと、ステップ９０４にて取得したクライアントユーザの役割とをＳＩＤと役割関連データベース１５０に登録する（ステップ９０５）。ＳＩＤは、ステップ９０１において生成したServerHelloメッセージに含まれるＳＩＤを利用する。登録には、ＳＩＤフィールド１５１にＳＩＤを、役割フィールド１５２には役割をもつレコードを１つ生成し、ＳＩＤと役割関連データベース１５０に追加する。

次に、ハンドシェイク処理部１１３は、ステップ９０４において決定した中継先の役割サーバ１３０又は１４０のＴＬＳセッション情報データベース１７０又は１８０に、ステップ９０１及び９０２における処理で取得したセッション情報１７２、１７４を追加する（ステップ９０６）。セッション情報１７２、１７４の生成方法はＴＬＳプロトコルに従い、その内容は、図６に示すように、通信相手種別、バルクデータ暗号アルゴリズム、暗号タイプ、鍵生成に利用する乱数データなどがある。
以後は、ステップ９０４で決定した役割サーバ１３０又は１４０と中継サーバ１１０との間で簡略ハンドシェイク処理が行われる。

ハンドシェイク処理部１１３は、上記ＳＩＤを含むClientHelloメッセージを生成し、役割サーバ１３０又は１４０に送信する。本メッセージを送信するには、クライアント２００に送信する場合と同様に、レコード処理部１１２及びＴＣＰコネクション処理部を介して送信する（ステップ９０７）。なお、ここで中継サーバ１１０と役割サーバ１３０又は１４０との間にＴＣＰによるＴＣＰ接続を確立させる必要があるため、その接続処理はＴＣＰコネクション処理部１１１が行う。

次に、ハンドシェイク処理部１１３は、役割サーバ１３０又は１４０からServerHelloメッセージ等を受信する（ステップ９０８）。役割サーバ１３０、１４０のＴＬＳセッション情報データベース１７０、１８０には上記ＳＩＤのＴＬＳセッション情報が含まれており、役割サーバ１３０、１４０は簡略ハンドシェイクを行う。
次に、ハンドシェイク処理部１１３は、ChangeCipherSpecとFinishedメッセージを生成し、役割サーバ１３０又は１４０に送信する（ステップ９０９）。
以上の処理を通して、クライアント２００と役割サーバ１３０、１４０はＴＬＳセッション情報を共有して、ＴＬＳ通信を行うことができるようになる。

次に、ハンドシェイク処理部１１３は、セッション情報を破棄する（ステップ９１０）。これは、ＴＬＳセッション情報を記憶していたメモリ部を消去するだけでなく、ヌル文字や乱数で上書きすることにより消去することを含む。このような処理をすることにより、万一、中継サーバ１１０に不正アクセスがあっても、セッション情報を盗まれることはない。

次に、過去のセッションを再開するときに行う簡略ハンドシェイク処理を説明する。図１０は、図８のステップ８０２に記載の簡略ハンドシェイク処理の詳細を示すフローチャートである。
ハンドシェイク処理部１１３は、ClientHelloメッセージに含まれるＳＩＤをキーにＳＩＤと役割関連データベース１５０を検索し、対応する役割サーバ１３０又は１４０を決定する。図４に示すＳＩＤフィールド１５１のＳＩＤに対応する役割フィールド１５２の値により役割サーバが決定される（ステップ１００１）。

次に、先のClientHelloメッセージを役割サーバ１３０又は１４０のいずれかに送信する。本メッセージの送信は、クライアント２００に送信する場合と同様に、レコード処理部１１２及びやＴＣＰコネクション処理部１１１を通じて送信する（ステップ１００２）。ここで、簡略ハンドシェイク処理を完了するには、ClientHelloの他にServerHello、ChangeCipherSpec、Finishedなどのメッセージ交換が必要であるが、これらのメッセージ交換は、クライアント２００と役割サーバ１３０又は１４０のいずれかが行い、中継サーバ１１０はメッセージを中継するのみである。この簡略ハンドシェイク処理のステップ１００２は、図７のステップ７０４に示すＴＣＰコネクション処理部１１１が行うの中継処理に相当する。

図１１は、本発明の役割サーバの処理の詳細を示すフローチャートである。ここでは、役割サーバ１３０の処理の説明をするが、役割サーバ１４０の処理も同様である。
役割サーバ１３０内のＴＣＰコネクション処理部１３１は、中継サーバ１１０からの接続要求を受付け、受信データをレコード処理部１３２に渡す（ステップ１１０１）。本接続要求は、図９のステップ９０７及び図１０のステップ１００２において中継サーバ１１０がClientHelloメッセージを送信するときに発生する接続要求に相当する。中継サーバ１１０と役割サーバ１３０との送受信は、このＴＣＰコネクション処理部１３１を介して行われる。

次に、レコード処理部１３２が受信データを解析、上位データを取出し、ハンドシェイクのメッセージであることを確認、ハンドシェイク処理部１３３に渡す（ステップ１１０２）。受信データはＴＬＳ Record Protocolの形式（非特許文献１参照）に従っている。レコード処理部１３２は本プロトコルの処理を行い、上位のアラート、ハンドシェイク、アプリケーションのデータを取出す。

次に、ハンドシェイク処理部１３３がハンドシェイク処理を行う。クライアント２００から受信した初めてのセッションの場合は、図９に示すステップ９０７ないし９０９で示した簡略ハンドシェイク処理に対する役割サーバ１３０のClientHelloメッセージの受信、ServerHello等のメッセージの生成及び送信、ChangeCipherSpec、Finishedメッセージの送信などの処理を行う。セッションの再開の場合は、役割サーバ１３０が生成したClientHelloメッセージの受信、ServerHello等のメッセージの生成及び中継サーバ１１０を介したクライアント２００への送信、クライアント２００が生成し、中継サーバ１１０が中継したChangeCipherSpec、Finishedメッセージの受信等の処理を行う（ステップ１１０３）。

ここでは、クライアント２００からの接続が初めてか、再開かで区別して説明したが、簡略ハンドシェイク処理としては同じであり、本ハンドシェイク処理部１３３は区別せず処理する。完全ハンドシェイクの処理は中継サーバ１１０が行っており、その結果得られたＴＬＳセッション情報は、ＴＬＳセッション情報データベース１７０に含まれており、本データベースにあるセッション情報を利用して、簡略ハンドシェイク処理を行う。従って、２回目以降のクライアントからのアクセスでは、再度、ＴＬＳセッション情報を生成する必要がなく、この生成処理を省略することができ、役割サーバは、本セッション情報を再利用することが可能になり、コンピュータシステム全体の負荷を軽減することが可能になる。

次に、レコード処理部１３２が受信データを解析し、上位データを取出し、アプリケーションデータであることを確認してサーバデータ処理部１３４に渡す。レコード処理部１３２はＴＬＳセッション情報データベース１７０にあるセッション情報を用いて、受信データの復号や改ざんを検知し、送信データの暗号化や改ざん検知データの付与を行う（１１０４）。
以上により、本実施の形態１では、中継サーバと役割サーバとでＴＬＳセッション情報を共有することで負荷の軽減を実現し、稼動効率を飛躍的に向上させることができる。

（実施の形態２）
実施の形態１では一つのコンピュータ上に中継サーバや役割サーバを配置しており、中継サーバ１１０から役割サーバ１３０、１４０に付属するＴＬＳセッション情報データベース１７０、１８０へのアクセスが、実施の形態１と同様に制限できれば、各々のサーバを別々のコンピュータ上に配置しても、同等の安全性が確保できる。以下、その実施形態について説明する。
図１２は、実施の形態２のコンピュータシステムの構成を示す図である。
図１２に示すように、コンピュータシステムは、複数のコンピュータ１００、３００、４００から構成され、それぞれセキュアＯＳが稼動している。

図１に示す実施の形態１との違いについて説明する。実施の形態１では、中継サーバ１１０と役割サーバ１３０、１４０は、セキュアＯＳが稼動している一つのコンピュータ１００上に稼動していたのに対して、実施の形態２では、各々のサーバがそれぞれ別のコンピュータ上に稼動しており、中継サーバ１１０はコンピュータ１００上で、役割１サーバ１３０はコンピュータ３００上で、役割２サーバ１４０はコンピュータ４００上で稼動している点で異なる。また、不正アクセスの起点となる外部のネットワークからは中継サーバ１１０が稼動するコンピュータ１００のみにアクセスでき、役割サーバ１３０、１４０が稼動するコンピュータ３００、４００にはアクセスできないように制限されている。これはファイアウォールのような公知技術で実現できる。

実施の形態１では、中継サーバ１１０がクライアント２００とＴＬＳハンドシェイク処理を行い、得られたＴＬＳセッション情報を役割サーバ１３０、１４０のＴＬＳセッション情報データベース１７０、１８０に書きこみをしていたのに対して、本実施の形態２では、コンピュータ３００、４００上のデータベースサーバ３１０、４１０を介して書きこみをする。

実施の形態１では、コンピュータ１００上で稼動しているセキュアＯＳの機能を用いて、中継サーバ１１０はＴＬＳセッション情報データベース１７０、１８０には書込みができても、読取ることはできないように制限していたのに対して、本実施の形態２では、コンピュータ３００、４００上で稼動するセキュアＯＳの機能を用いて、データベースサーバ３１０、４１０はＴＬＳセッション情報データベース１７０、１８０に書込み（w;write）はできても、読取る（r;read）ことはできないように制限する。このように、データベースサーバ３１０、４１０を設けてＴＬＳセッション情報データベース１７０、１８０へのアクセスを制限することで、実施の形態１と同様に中継サーバ１１０が不正アクセスを受け、さらにデータベースサーバ３１０、４１０が不正アクセスを受けても、ＴＬＳセッション情報を読取られることはなく、実施の形態１と同等のセキュリティを保つことができる。さらにセキュリティレベルを上げるために、中継サーバ１１０からデータベースサーバ３１０、４１０への通信を、中継サーバからデータベースサーバ３１０、４１０への一方向だけにアプリケーションデータを送るようにセキュアＯＳの機能を用いて制限するようにしてもよい。
また、実施の形態１と同様に、情報を共有することにより、処理の一部を省略し、サーバにかかる負荷を軽減しているため、高速なＴＬＳプロトコルの処理も実現することができる。

実施の形態１のコンピュータシステムの構成を示す図である。 本発明の中継サーバの内部構造を示す図である。 本発明の役割サーバの内部構造を示す図である。 本発明のＳＩＤと役割関連データベースの構造を示す図である。 本発明のユーザと役割関連データベースの構造を示す図である。 本発明のＴＬＳセッション情報データベース１の構造を示す図である。 本発明の中継サーバによる処理内容を示すフローチャートである。 本発明のハンドシェイク処理部が行う処理の詳細を示すフローチャートである。 図８のステップ８０２に記載の完全ハンドシェイク処理の詳細を示すフローチャートである。 図８のステップ８０２に記載の簡略ハンドシェイク処理の詳細を示すフローチャートである。 本発明の役割サーバの処理の詳細を示すフローチャートである。 実施の形態２のコンピュータシステムの構成を示す図である。

符号の説明

１００ コンピュータ
１１０ 中継サーバ
１１１ ＴＣＰコネクション処理部
１１２ レコード処理部
１１３ ハンドシェイク処理部
１２０ ユーザと役割関連登録ツール
１３０ 役割１サーバ
１３１ ＴＣＰコネクション処理部
１３２ レコード処理部
１３３ ハンドシェイク処理部
１４０ 役割２サーバ
１５０ ＳＩＤと役割関連データベース
１５１ ＳＩＤフィールド
１５２ 役割フィールド
１６０ ユーザと役割関連データベース
１６１ ユーザフィールド
１６２ 役割フィールド
１７０ ＴＬＳセッション情報データベース１
１８０ ＴＬＳセッション情報データベース２
３００、４００ コンピュータ
３１０ データベースサーバ１
４１０ データベースサーバ２

Claims (4)

1. セキュアＯＳが稼働し、
   クライアントからの要求を受付ける中継サーバと
   ドメイン及び役割が割当てられアプリケーション処理を行う役割サーバと
   前記クライアントのユーザとその役割の関連を保持する第１のデータベースと
   ＴＬＳプロトコルのセッションＩＤと前記ドメイン及び役割の関連を保持する第２のデータベースと
   前記役割サーバごとに用意されたＴＬＳプロトコルのセッション情報を保持する第３のデータベースとを備え、
   前記中継サーバが、前記第１のデータベースに対しては読込む権限のみを有し、前記第３のデータベースに対しては書込む権限のみを有するコンピュータシステムにより実行されるＴＬＳセッション情報の引継ぎ方法であって、
   前記中継サーバが、
   ＴＬＳプロトコルの処理に関しては、ハンドシェイク処理のみを行い、ハンドシェイク処理時に認証したユーザと、前記第１のデータベースから得た役割及びＴＬＳプロトコルのセッションＩＤとを前記第２のデータベースに書込み、ＴＬＳセッション情報をハンドシェイク処理後に前記第３のデータベースに書込んだ後に破棄し、暗号化されたアプリケーションデータを前記役割サーバに中継するステップと、
   さらに、ＴＬＳプロトコルによるセッションを再開するときは、セッション開始時にクライアントから受信したメッセージに含まれるセッションＩＤをキーにして、前記第２のデータベースから対応する役割サーバを決定し、該役割サーバに前記メッセージを含めて中継するステップと、
   前記役割サーバが、
   前記第３のデータベースに書込まれた前記ＴＬＳセッション情報を利用してＴＬＳプロトコルによるハンドシェイク処理を行うステップとを有する
   ことを特徴とするＴＬＳセッション情報の引継ぎ方法。
2. 前記中継サーバと、前記役割サーバとを、個々にセキュアＯＳが稼動する異なるコンピュータに配置し、
   前記役割サーバが配置されたコンピュータには、第３のデータベースへ書込む権限のみを有するデータベース追加サーバを配置し、
   前記中継サーバが、ＴＬＳセッション情報を、データベース追加サーバを介してハンドシェイク処理後に第３のデータベースに書込んだ後に破棄するステップを有する
   ことを特徴とする請求項１に記載のＴＬＳセッション情報の引継ぎ方法。
3. セキュアＯＳが稼働し、
   クライアントからの要求を受付ける中継サーバと
   ドメイン及び役割が割当てられアプリケーション処理を行う役割サーバと
   前記クライアントのユーザとその役割の関連を保持する第１のデータベースと
   ＴＬＳプロトコルのセッションＩＤと前記ドメイン及び役割の関連を保持する第２のデータベースと
   前記役割サーバごとに用意されたＴＬＳプロトコルのセッション情報を保持する第３のデータベースとを備え、
   前記中継サーバが、前記第１のデータベースに対しては読込む権限のみを有し、前記第３のデータベースに対しては書込む権限のみを有するコンピュータシステムであって、
   前記中継サーバは、
   ＴＬＳプロトコルの処理に関しては、ハンドシェイク処理のみを行い、ハンドシェイク処理時に認証したユーザと、前記第１のデータベースから取得した役割及びＴＬＳプロトコルのセッションＩＤとを前記第２のデータベースに書込み、ＴＬＳセッション情報をハンドシェイク処理後に前記第３のデータベースに書込んだ後に破棄し、暗号化されたアプリケーションデータを前記役割サーバに中継し、
   さらに、ＴＬＳプロトコルによるセッションを再開するときは、セッション開始時にクライアントから受信したメッセージに含まれるセッションＩＤをキーにして、前記第２のデータベースから対応する役割サーバを決定し、該役割サーバに前記メッセージを含めて中継し、
   前記役割サーバは、
   前記第３のデータベースに書込まれた前記ＴＬＳセッション情報を利用してＴＬＳプロトコルによるハンドシェイク処理を行う
   ことを特徴とするコンピュータシステム。
4. 前記中継サーバと、前記役割サーバとを、個々にセキュアＯＳが稼動する異なるコンピュータに配置し、
   前記役割サーバが配置されたコンピュータには、第３のデータベースへ書込む権限のみを有するデータベース追加サーバを配置し、
   前記中継サーバは、ＴＬＳセッション情報を、データベース追加サーバを介してハンドシェイク処理後に第３のデータベースに書込んだ後に破棄する
   ことを特徴とする請求項３に記載のコンピュータシステム。

Images