(57)【要約】【課題】  システムに対して導入設置された多重化認証サーバの信頼性を保証する仕組みを提供することを目的とする。【解決手段】  ネットワーク（1-6）に接続されたクライアントＰＣ（1-1,1-2）、サーバ（1-4,1-5）、並びにデバイス（1-3）によって構成され、利用者の識別と認証、並びにリソースへのアクセスと許可が認証サーバ（1-4,1-5）によって集中的に管理され、当該認証サーバの多重化を目的とする複数の認証サーバによる多重化システムであって、複数の認証サーバ（1-4,1-5）は、公開鍵暗号方式に基づく公開鍵と秘密鍵の鍵ペアのうち、自身に関連付けされた秘密鍵を秘密のうちに保持する保持手段と、多重化された認証サーバ間で信頼性を確認するために定期的な通信を行う通信手段とを有し、前記通信手段による通信のために、前記鍵ペアを用いることを特徴とする認証サーバの多重化システム等を提供する。【選択図】  図１
2005165671.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続されたクライアントＰＣ、サーバ、並びにデバイスによって構成され、利用者の識別と認証、並びにリソースへのアクセスと許可が認証サーバによって集中的に管理され、当該認証サーバの多重化を目的とする複数の認証サーバによる多重化システムであって、
前記複数の認証サーバは、公開鍵暗号方式に基づく公開鍵と秘密鍵の鍵ペアのうち、自身に関連付けされた秘密鍵を秘密のうちに保持する保持手段と、
多重化された認証サーバ間で信頼性を確認するために定期的な通信を行う通信手段と
を有し、
前記通信手段による通信のために、前記鍵ペアを用いることを特徴とする認証サーバの多重化システム。
【請求項２】
ネットワークに接続されたクライアントＰＣ、サーバ、並びにデバイスによって構成され、利用者の識別と認証、並びにリソースへのアクセスと許可が認証サーバによって集中的に管理され、当該認証サーバの多重化を目的とする複数の認証サーバによる多重化システムであって、
前記複数の認証サーバは、公開鍵暗号方式に基づく公開鍵と秘密鍵の鍵ペアのうち、自身に関連付けされた秘密鍵を秘密のうちに保持する保持手段と、
多重化された認証サーバ間で定期的なチャレンジ・アンド・レスポンス方式に基づく認証を行う認証手段と
を有し、
前記認証手段による認証のために、前記鍵ペアを用いることを特徴とする認証サーバの多重化システム。
【請求項３】
前記認証サーバは、他の認証サーバとの間で信頼性を確認するために、
乱数を生成し保持する乱数生成保持手段と、
前記公開鍵暗号方式のアルゴリズムに基づく暗号・復号手段と、
所定の電子署名方法に従って電子署名を行い、かつ検証処理を行う電子署名手段と
を更に有することを特徴とする請求項１又は２に記載の認証サーバの多重化システム。
【請求項４】
所定の監査手段を更に有し、
前記電子署名手段によって不正が検出された場合に、当該監査手段によって管理者に報知することを特徴とする請求項３に記載の認証サーバの多重化システム。
【請求項５】
前記通信手段は、多重化された認証サーバ間で相互に信頼性を確認するために、定期的な通信を相互に行うことを特徴とする請求項１に記載の認証サーバの多重化システム。
【請求項６】
前記認証手段は、多重化された認証サーバ間で相互に信頼性を確認するために、定期的なチャレンジ・アンド・レスポンス方式に基づく認証を相互に行うことを特徴とする請求項２に記載の認証サーバの多重化システム。
【請求項７】
ネットワークに接続されたクライアントＰＣ、サーバ、並びにデバイスによって構成され、利用者の識別と認証、並びにリソースへのアクセスと許可が認証サーバによって集中的に管理され、当該認証サーバにおける多重化方法であって、
公開鍵暗号方式に基づく公開鍵と秘密鍵の鍵ペアのうち、自身に関連付けされた秘密鍵を秘密のうちに保持する保持工程と、
多重化された認証サーバ間で信頼性を確認するために定期的な通信を行う通信工程と
を有し、
前記通信工程による通信のために、前記鍵ペアを用いることを特徴とする認証サーバの多重化方法。
【請求項８】
ネットワークに接続されたクライアントＰＣ、サーバ、並びにデバイスによって構成され、利用者の識別と認証、並びにリソースへのアクセスと許可が認証サーバによって集中的に管理され、当該認証サーバにおける多重化方法であって、
公開鍵暗号方式に基づく公開鍵と秘密鍵の鍵ペアのうち、自身に関連付けされた秘密鍵を秘密のうちに保持する保持工程と、
多重化された認証サーバ間で定期的なチャレンジ・アンド・レスポンス方式に基づく認証を行う認証工程と
を有し、
前記認証工程による認証のために、前記鍵ペアを用いることを特徴とする認証サーバの多重化方法。
【請求項９】
多重化された認証サーバ間で信頼性を確認するために、乱数を生成し保持する乱数生成保持工程と、
前記公開鍵暗号方式のアルゴリズムに基づく暗号・復号工程と、
所定の電子署名方法に従って電子署名を行い、かつ検証処理を行う電子署名工程と
を更に有することを特徴とする請求項７又は８に記載の認証サーバの多重化方法。
【請求項１０】
所定の監査工程を更に有し、
前記電子署名工程によって不正が検出された場合に、当該監査工程によって管理者に報知することを特徴とする請求項９に記載の認証サーバの多重化方法。
【請求項１１】
前記通信工程は、多重化された認証サーバ間で相互に信頼性を確認するために、定期的な通信を相互に行うことを特徴とする請求項７に記載の認証サーバの多重化方法。
【請求項１２】
前記認証工程は、多重化された認証サーバ間で相互に信頼性を確認するために、定期的なチャレンジ・アンド・レスポンス方式に基づく認証を相互に行うことを特徴とする請求項８に記載の認証サーバの多重化方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のＰＣやデバイスとこれらを使用するユーザの認証を行い、かつリソースへのアクセスを制御する認証サーバの機能をバックアップする多重化（冗長化）システムに関する。また、当該多重化システムによって構成される複数の認証サーバに信頼性を与え、かつこれを確認する多重化方法に関する。
【背景技術】
【０００２】
ネットワークに接続されたクライアントＰＣ及びサーバ、デバイスによって構成される論理領域（ドメイン）において、ユーザがドメイン上の何らかのリソースを利用する場合、当該ユーザの認証とリソースへのアクセス権限の付与が必要である。クライアントサーバシステムにおける認証サーバは、独自あるいは標準化されたプロトコルに基づいて、利用者の識別と認証、並びにリソースへのアクセス権限の付与などといった機能を提供し、利用者がシステム内のリソースの利用に供する。
【０００３】
システム内のリソースは、特定の第三者にとって資産価値の高い情報も含まれ、クライアントＰＣとサーバ間、或いはデバイスとサーバ間の通信において、互いのセキュリティを確保しなければならない。具体的には通信データの機密性、完全性を保証する必要性や、通信相手の成りすましを防止する必要性などが考えられる。このような場合において、従来、通信データを暗号化してセキュリティを確保する方式が用いられている。例えば、公開鍵暗号方式を利用した鍵配布方法によれば、通信相手の成りすましを防止し、通信データを暗号化するための暗号鍵を安全に配布することが可能である。
【０００４】
認証サーバは、このような場合において公開鍵暗号方式を利用した鍵配布サービスを、クライアントＰＣ或いはデバイスに提供する機能も併せ持っている。ドメインにおける安全でかつ機密性の高いネットワークセキュリティは、高いセキュリティによって守られた認証サーバによって実現される。
【０００５】
ところで、このようにシステムのセキュリティを確保する上で、認証サーバ自身のセキュリティを確保することが重要な要素となる。認証サーバ自身が簡単に改ざんされたり、成りすましされたのでは、システム全体のセキュリティを確保することができないからである。さらに、ドメインの中で稼動する認証サーバは、そのドメインの中で唯一１つでなければならない。ドメインのユーザ管理や暗号鍵の管理、配布といった機能が、１つの認証サーバによって統一的に実施されることが必要だからである。これは、認証サーバの成りすまし等、セキュリティ上の問題（セキュリティホール）を回避するためにも必要である。
【０００６】
しかし、一方でドメインを構成する認証サーバが１つしかない場合において、当該認証サーバに何らかの障害が発生すると、ユーザ認証並びにアクセス権限の付与といった機能が一切動作しなくなるといった問題が発生する。このような状態では、利用したいリソース、例えばデバイスやファイルサーバは正常に稼動していても、ユーザはその認証サーバから認証と使用権原が与えられないため、これらのリソースを使うことができなくなる。ドメインに所属する認証サーバが１つしか存在しないからである。
【０００７】
このように、認証サーバはその機能的な性格からドメインの中で唯一、稼動しなければならないが、一方で、前述のようなケース、すなわち障害時のシステム全体のダウンといった利便性の問題にも対処することが、実際の運用のために必要である。この問題に対処するため、通常、ドメインを構成するクライアントサーバシステムにおいて、認証サーバの多重化或いは冗長化といった考え方があり、実用化されている。
【０００８】
認証サーバの多重化とは、ドメインにおける認証を制御する認証サーバを複数台用意しておき、優先順位を設けた状態で全てを動かしておくシステム形態である。優先順位とは、認証サーバが有効に機能する順位（プライオリティ）をあらかじめ設定しておき、プライオリティの高い認証サーバから順番に機能するように構成するのである。ここで、多重化した認証サーバは、サーバの成りすましや改ざんなど、セキュリティホールの元凶になりやすいという欠点もあり、全ての認証サーバが真正な認証サーバであることが前提となって多重化システムが構成されなければならない。
【０００９】
多重化機能のある認証サーバの動作の概略を説明すると次のようになる。第一優先の認証サーバに何らかの障害が発生して認証機能が停止した場合、第二優先の認証サーバが自動的に作業を引き継いで、認証作業或いはアクセス権限の付与といった作業を行う。さらに、第三優先の認証サーバがある場合、第二優先の認証サーバに引き続き障害が発生したら、自動的に第三優先の認証サーバが機能するような仕組みが備わっている。ここで、認証サーバに障害が発生したときに、プライオリティの低い認証サーバに機能を引き継ぐための手順については、例えば、クライアント側が認証サーバの障害を検知して切り替えるタイプ、あるいは多重化した他の認証サーバが上位優先の認証サーバを監視する方法などがある。
【００１０】
このように認証サーバに障害が発生すると、ドメインを構成するリソースが使用できなくなるといった問題は、認証サーバの多重化によって解決可能である。しかし、一方で、認証サーバが責任を負っていたセキュリティ機能の信頼性の点で新たに問題がある。すなわち、認証サーバ自身の成りすましである。
【００１１】
認証サーバの多重化させるシステムでは、通常、管理者がバックアップ用の認証サーバをセットアップして起動させるが、ここでバックアップ用に立ち上げる認証サーバの信頼性を保証する仕組みが不十分である。バックアップ用の認証サーバが、本来の正しい管理者の意図しないサーバ（悪意のある認証サーバrogue server）であった場合、第一優先の認証サーバに障害が発生すると、この成りすました認証サーバが有効になってしまう場合が考えられる。
【００１２】
一度、前記rogue serverが稼動してしまうと、正規な手続きに従って登録されたユーザ以外の意図しないユーザが認証されてリソースにアクセスできてしまったり、正規ユーザの認証手続きからパスワードを盗み取ったりといった様々なセキュリティ上の問題が発生してしまう。
【００１３】
多くのセキュリティ上の問題の原因となるrogue serverを、バックアップ用の認証サーバとしてドメインに参加できないようにする手段としては、現在、バックアップ用に認証サーバを設定する時に、管理者のパスワード認証を要求するといった手続きによって回避する方法がある。
【００１４】
すなわち、認証サーバを正しくインストールし起動した後、第一優先の認証サーバがドメインに、第二優先の認証サーバを参加させるという作業工程を用意している。認証サーバの参加を行うためには、管理者のパスワード認証が必要であり、管理者パスワードの入力が求められる。第一優先の認証サーバは、入力されたパスワード認証が正しい場合にのみ、第二優先の認証サーバをバックアップサーバとしてドメインに参加を許可するのである。通常、管理者のパスワードは、管理者のみが知りうる情報であり、原則として一般ユーザに知られることはない。従って、このような作業工程を導入することによって、第一優先の認証サーバは、勝手に第二優先の認証サーバがドメインに参加することを未然に防ぐことができる。ひいては、第一優先の認証サーバは、第二優先の認証サーバを信頼することが可能となるのである。
【発明の開示】
【発明が解決しようとする課題】
【００１５】
ところで、上記従来例で述べたごとく、管理者のパスワード認証による方法によれば、認証サーバの設置時に第一優先の認証サーバが第二優先の認証サーバを信頼する方法として有効である。
【００１６】
しかし、この方法では、一旦認証サーバを設置し多重化構成を構築した後、すなわちシステムを運用中にまで及んで、バックアップ用に設置した多重化認証サーバの信頼性を維持し続けることはできない。例えば、バックアップ用の認証サーバが悪意を持った第三者に置き換えられたり、改ざんされたりといったセキュリティ上の問題が考えられ、このような問題に対処するためには、設置時だけでなくシステムの運用中も認証サーバの信頼性の確認が必要である。
【００１７】
従来、以上のような目的で運用中のバックアップ認証サーバの信頼性を自動で確認し保証する仕組みはなかった。また、システム全体を管理し監視するシステム管理者が定期的にバックアップ用認証サーバの構成を確認する方法や、アクセスログや状態を監査するなどの手法を用いることは可能であった。しかし、このような方法はシステム管理者の非常に大きな手間を必要とし、管理コストが高いといった欠点がある。
【００１８】
本発明は、このような従来における認証サーバの運用および管理上未決の課題に着目してなされたものであって、システムに対して導入設置された多重化認証サーバの信頼性を保証する仕組みを提供することを目的としている。加えて他の目的として、多重化認証サーバの信頼性を保証するための処理を完全に自動化し、システム管理者の管理コストをできるだけ削減することを実現するための仕組みを提供する。
【課題を解決するための手段】
【００１９】
上記目的を達成するために本発明は、ネットワークに接続されたクライアントＰＣ、サーバ、並びにデバイスによって構成され、利用者の識別と認証、並びにリソースへのアクセスと許可が認証サーバによって集中的に管理され、当該認証サーバの多重化を目的とする複数の認証サーバによる多重化システムであって、前記複数の認証サーバは、公開鍵暗号方式に基づく公開鍵と秘密鍵の鍵ペアのうち、自身に関連付けされた秘密鍵を秘密のうちに保持する保持手段と、多重化された認証サーバ間で信頼性を確認するために定期的な通信を行う通信手段とを有し、前記通信手段による通信のために、前記鍵ペアを用いることを特徴とする認証サーバの多重化システム等を提供する。
【発明の効果】
【００２０】
本発明によれば、システムを構築した後、すなわちシステムの運用中にまで及んで、バックアップ用に設置した多重化認証サーバの信頼性を維持し続けることができる。従って、例えば、バックアップ用の認証サーバが悪意を持った第三者に置き換えられたり、改ざんされたりといったセキュリティ上の問題に対しても、設置時だけでなくシステムの運用中も認証サーバの信頼性を確認することができ、当該セキュリティ上の問題にも対処することができる。
【００２１】
また、システム全体を管理し監視するシステム管理者が定期的にバックアップ用認証サーバの構成を確認する方法や、アクセスログや状態を監査するなどの手法を用いなくても、自動的かつ継続的に認証サーバの信頼性を保証することができるため、システム管理者の管理コストを大幅に削減することができるようになる。
【発明を実施するための最良の形態】
【００２２】
以下、本発明の実施形態について図面を参照しながら説明する。
【００２３】
（第１の実施形態）
図１は、本発明の第１の実施形態にかかる認証サーバの多重化システムの全体構成図である。
図１において、１−１および１−２は、本多重化システムを構成するクライアントＰＣである。利用者は、当該クライアントＰＣを使って本ネットワークシステムにアクセスし、各種リソースを利用する。利用者は、システムリソースへのアクセスと利用を行うに当たって、先ず、当該クライアントＰＣから利用者認証を行い、利用者ごとに割り当てられたアクセス制御情報の割り当てを受ける。本実施例では、便宜上、２台のクライアントＰＣを記載してあるが、必ずしも２台に限定されるものではない。
【００２４】
図１において、１−３は本システムにネットワークによって接続されたデバイスである。デバイスとして、例えば印刷機器、スキャナ、ＦＡＸ、これらの複合機などが相当する。また、ファイルサーバ（不図示）などもネットワークシステムの１つである。
【００２５】
物理的ネットワーク接続手段としては、イーサネット（Ｒ）による有線、あるいは無線ＬＡＮ規格に準拠した無線による情報通信があり、いずれの場合も本システムのネットワーク手段として予定される。
【００２６】
図１において、１−４は、本発明にかかるシステム全体のユーザ認証やアクセス制御などを統括して行っている認証サーバである。認証サーバは、システム利用者の識別と認証、アクセス制御などを統括して制御し、システムのセキュリティを統括するセキュリティの論理領域（ドメイン、１−６）を構成する。ドメインは、他の認証サーバが統括する別のセキュリティドメインと区別するための論理的な境界をも意味している。従って、物理的には同じネットワーク手段によって結合した複数のクライアントＰＣ、デバイス、並びに認証サーバ群が、論理的には複数のセキュリティドメインに分割されて運用されることもある。
【００２７】
原則として１つのドメインには、１つの認証サーバが優先的な認証サーバ（プライマリ認証サーバ）として存在しており、そのドメインのセキュリティを統括している。従って、複数のドメインがある場合は、それぞれのドメインに１つずつプライマリ認証サーバが設置される。なお、認証サーバの機能として、ドメインをまたがる認証やアクセス制御を実現するために、認証サーバ同士が信頼関係を結ぶための機能が備わっている場合もある。
【００２８】
ところで、ドメインにおけるセキュリティ機能の制御は、１つのプライマリ認証サーバが統括して行っているため、この認証サーバに障害が発生した場合、利用者はそのドメインのリソースを一切使用することができなくなってしまう。このような問題を解決するため、認証サーバを多重化し一台の認証サーバに障害が発生してもバックアップ用の他の認証サーバが以降の処理を引き継ぐ仕組みがある。このような仕組みは、多重化システム、冗長化システム、あるいはバックアップシステムなどと呼ばれ、バックアップ用の他の認証サーバをバックアップ認証サーバ、セカンダリ認証サーバなどと呼ぶ。
【００２９】
本発明にかかる認証サーバの多重化システムは、認証サーバが多重化システムに対応する機能を有している。図１において、認証サーバ１−４は、プライマリ認証サーバに該当する。一方、図１において、１−４および１−５はセカンダリの認証サーバに該当し、プライマリ認証サーバ（１−４）に障害が発生した時、自動的に当該セカンダリ認証サーバに切り替わり、利用者の認証などの処理を引き続き行うようになっている。
【００３０】
ここで、ドメイン１−６は、システム全体を統括して管理運用するシステム管理者（不図示）によって管理されている。認証サーバ１−４および１−５は、共に当該システム管理者によって正しく設置され、このときに信頼を付与されている。
【００３１】
一方、システムの運用が開始されると、本発明にかかる認証サーバの多重化システムは、それぞれの認証サーバ間でチャレンジ・アンド・レスポンス方式に基づく通信を行う。図１において、１−７は本発明にかかる認証サーバ同士がチャレンジ・アンド・レスポンス方式に基づくネットワーク通信を行っている様子を示すものである。この通信は、認証サーバの設置以降、システムの運用が始まった後の定期的かつ自動的に信頼を確保するために行われるものである。以下、図３に示す図を用いて、当該チャレンジ・アンド・レスポンス方式に基づく通信手順と、これに基づく信頼性確保の仕組みについて説明する。
【００３２】
図３は、本発明にかかる認証サーバの多重化システムにおいて、チャレンジ・アンド・レスポンス方式に基づく通信手順を示すラダーチャートである。
図３において、３−１および３−２は、それぞれプライマリ認証サーバおよびセカンダリ認証サーバの各処理工程を示すものである。また、図３において、プライマリ認証サーバ３−１は、図１におけるプライマリ認証サーバ１−４に該当し、セカンダリ認証サーバ３−２は、図１におけるセカンダリ認証サーバ１−５に該当する。
【００３３】
図３において、ステップＳ３−３は、プライマリ認証サーバ（３−１）が乱数を生成し、これをサーバ自身の内部データ記憶領域に保持する工程である。この乱数は所定のデータ長を有しており、通信を行うたびに毎回異なる値が生成される。そして、サーバ自身のデータ記憶領域にこの値が保持される。
【００３４】
図３において、ステップＳ３−４は、セカンダリ認証サーバ（３−２）の公開鍵で前述の乱数値を暗号化する工程である。認証サーバには、その設置時にあらかじめ公開鍵暗号方式に基づく暗号鍵のペア、すなわち公開鍵と秘密鍵が作られていて、公開鍵は既知の鍵配布手段に基づいて他の認証サーバに配布され、保持されている。この工程（ステップＳ３−４）では、セカンダリ認証サーバのみが復号しうるデータとして暗号化するため、先にプライマリ認証サーバ（３−１）で生成し保持しておいた乱数値を、セカンダリ認証サーバ（３−２）の公開鍵で暗号化する。公開鍵暗号化方式としては、既知の暗号アルゴリズムを利用することができる。
【００３５】
暗号化された乱数値は、所定の通信プロトコルに従ってセカンダリ認証サーバに送信される（ステップＳ３−５）。所定の通信プロトコルは、例えば公開された標準プロトコルとして、ＦＴＰ、ＨＴＴＰなどがあるが、独自のプロトコルに従うことも可能である。
【００３６】
セカンダリ認証サーバ（３−２）は、暗号化された乱数値を自身の秘密鍵で復号処理し、プライマリ認証サーバ（３−１）がこの通信に関連付けられた値として生成した乱数値を取得する（ステップＳ３−６）。秘密鍵とは、所定の公開鍵暗号アルゴリズムに基づく暗号鍵のうちの秘密鍵のことをいう。暗号アルゴリズムは、認証サーバの設置時に事前に指定しておいても良いが、本発明にかかる多重化システムにおいては、通信時にハンドシェイク処理時に、どの暗号アルゴリズムを適用するかが指定される。これは、認証サーバの種類によって対応しているアルゴリズムに相違のある場合があるからである。なお、乱数値は通信ごとにプライマリ認証サーバによって生成される。
【００３７】
次に、セカンダリ認証サーバ（３−２）は、取得した乱数値を自身の所有する秘密鍵を利用して電子署名処理を施す（ステップＳ３−７）。電子署名は、送信するデータに改ざんが無いことと、本人性を証明することを目的として行われる。電子署名の方法として、本発明にかかるシステムは、例えば、次に示す手順と工程に従った処理が実行される。すなわち、セカンダリ認証サーバの処理として、乱数値を、署名データを送信する相手先認証サーバの公開鍵で暗号化する。この後、セカンダリ認証サーバは暗号データをプライマリ認証サーバに送信する（ステップＳ３−９）。
【００３８】
暗号データを受け取ったプライマリ認証サーバは、自身の秘密鍵で暗号データを復号する。復号処理の結果、プライマリ認証サーバは乱数値を取得することになる（ステップＳ３−１０）。ここで、プライマリ認証サーバは通信前に生成しておいた乱数値を保持しており、この値と復号の結果取得した乱数値の一致、不一致を比較する。比較の結果、乱数値が一致すれば、セカンダリ認証サーバは自身の秘密鍵でプライマリ認証サーバが先に送信した乱数値の暗号データを復号することができたことになる。
【００３９】
正しく復号するためには、セカンダリ認証サーバは、プライマリ認証サーバが保持している公開鍵に対応する正しい秘密鍵を利用して暗号データを復号しなければならない。このことから、正しく復号できたと判断できる場合には、セカンダリ認証サーバはプライマリ認証サーバが意図する真正な秘密鍵を保有していることになり、よって、プライマリ認証サーバはセカンダリ認証サーバが真正に設置されたサーバであると認識することが可能となる（ステップＳ３−１１）。
【００４０】
このあと、プライマリ認証サーバ（３−１）は、セカンダリ認証サーバ（３−２）が真正に設置されたサーバであると判断すれば、引き続き当該セカンダリ認証サーバ（３−２）を信頼する。しかし、セカンダリ認証サーバ（３−２）が真正に設置されたものではないと判断した場合、その結果を監査し、システム管理者への警告メッセージの発行と、セカンダリ認証サーバのシステムからの切り離しを行う（ステップＳ３−１２）。
【００４１】
ところで、セキュリティに対する攻撃手法として、セカンダリ認証サーバ（３−２）からの通信を第三者が傍受して、データパケットをハッキングし、セカンダリ認証サーバ（３−２）に成りすますことが可能である。いわゆる、リプライ攻撃と呼ばれる手法である。
【００４２】
本発明にかかる認証サーバの多重化システムは、この攻撃に対処するために次のような方法を用意している。すなわち、プライマリ認証サーバ（３−１）とセカンダリ認証サーバ（３−２）の通信ごとに、乱数を確実に変えるため、前回の乱数値を次の通信のための乱数生成・保持工程（ステップＳ３−３）まで記憶しておき、もし、乱数値が偶然一致した場合は当該乱数値を破棄し、再度、生成しなおす工程である。これにより、通信に使われる乱数は通信ごとに確実に変わるため、仮にリプライ攻撃にあった場合にこれを確実に検出することが可能である。
【００４３】
また、別の方法として、次の工程を付加することも可能である。
すなわち、セカンダリ認証サーバ（３−２）が乱数値を電子署名する工程（ステップＳ３−７）とプライマリ認証サーバ（３−２）の公開鍵で署名データを暗号化する工程（ステップＳ３−８）において、セカンダリ認証サーバ（３−２）の時刻を入れ込むのである。時刻は、途中改ざんを防止するために、所定のハッシュアルゴリズムに従ってハッシュを計算し、この値ともとの乱数値、および時刻データを所定のデリミタで結合し、署名データを送信する相手先認証サーバ、すなわちプライマリ認証サーバ（３−１）の公開鍵で暗号化する。
【００４４】
その後、暗号データを受け取ったプライマリ認証サーバ（３−１）は、暗号データの復号工程（ステップＳ３−１０）、並びに署名データの検証工程（ステップＳ３−１１）において時刻データを取り出し、時刻があらかじめ設定してある許容値範囲内にあれば、セカンダリ認証サーバを信頼し、許容値を超えて時刻が経過していた場合はリプライ攻撃にあっていると判断するのである。
【００４５】
以上の一連の処理は、プライマリ認証サーバ（３−１）およびセカンダリ認証サーバ（３−２）の間で行われる１回の通信の流れであるが、本発明にかかる認証サーバの多重化システムは、この一連の通信を定期的に継続して、かつ自動で行うことで、セカンダリ認証サーバの信頼性の確認をサーバ設置以降も行い続ける。これによって、システム運用中のセキュリティの維持を実現する。
【００４６】
一方、本実施例で示したチャレンジ・アンド・レスポンス方式に基づく通信は、プライマリ認証サーバからセカンダリ認証サーバに対して片方向で行う形態を説明した。しかし、認証サーバ同士の信頼性を互いに検証し確実に保障する目的で、双方向でチャレンジ・アンド・レスポンス方式を実施することも可能である。
【００４７】
すなわち、セカンダリ認証サーバ３−２が乱数を生成・保持し、プライマリ認証サーバの公開鍵で暗号化してこれを送信する。プライマリ認証サーバは受け取った暗号データを自身の秘密鍵で復号処理し、電子署名を行ってからセカンダリ認証サーバの公開鍵で暗号化する。セカンダリ認証サーバ３−２は、プライマリ認証サーバ３−１から暗号データを受け取り、自身の秘密鍵で復号し、署名データの検証を行い、検証結果に応じて対処を切り替えるのである。
【００４８】
双方向で通信を行う場合、チャレンジ・アンド・レスポンス方式に基づく通信の方向は、例えば交互に行うなど、いくつかのバリエーションがあり、そのシステムに最適な方法を最初に決めておけばよい。
【００４９】
次に、図２を用いて本実施例にかかる認証サーバの多重化システムの構成手段について説明する。図２は、本発明にかかる認証サーバの多重化システムにおいて、認証サーバが持っている機能構成を模式的に表した図である。
【００５０】
図２において、２−１は認証サーバの機能境界を示している。２−２は、認証サーバ自身の公開鍵暗号方式に基づく鍵ペア生成手段である。これによって生成される公開鍵は、サーバの設置時に他の認証サーバに配布され保持される。一方、秘密鍵は、図２において、２−４で示す秘密鍵保持手段によって機密性を保ったまま認証サーバ内部に保持される。ここで保持する秘密鍵データは、認証サーバ２−１自身のデータであり、認証サーバ自身以外の誰からも参照されないようにしなければならない。従って、通常、秘密鍵が保持されるデータ領域は、システム管理者を含む誰からもアクセスできない領域にセキュアに保持される。
【００５１】
このような形態を実現するために、例えば、秘密鍵を生成したあと、ハード的に秘密鍵データを保持した装置をドングルとして認証サーバにアタッチするなどの手法をとることが可能である。また、設置時のコストを下げるために、生成した秘密鍵を認証サーバのシステム以外にアクセス権限が無いデータ記憶領域に保持するなどの構成をとっても良い。
【００５２】
図２において、２−３は乱数生成・保持手段である。認証サーバ同士の通信で送受信される任意のデータとして、当該乱数生成・保持手段によって生成された乱数が使用される。また、当該乱数は認証サーバの所定の記憶領域に保持され、セカンダリ認証サーバから返信されてきた乱数値がプライマリ認証サーバの送信した乱数値と一致するかどうかを判断するために供される。
【００５３】
図２において、２−７は暗号・復号手段である。本発明にかかる認証サーバの多重化システムは、認証サーバ同士の通信の機密性を確保するために公開鍵暗号方式に基づく暗号・復号処理が実行される。本暗号・復号手段２−７は、この公開鍵暗号の処理の実現に寄与する。
【００５４】
図２において、２−６は電子署名手段である。本実施例にかかる認証サーバの多重化システムは、前述したとおり乱数の電子署名を行う肯定がある。当該電子署名手段２−６は、この場合の電子署名処理を実現する。
【００５５】
図２において、２−５は通信手段である。本発明にかかる認証サーバの多重化システムにおいて、認証サーバ同士が通信するときに、所定のプロトコルに従ったデータ通信機能を本通信手段２−５が提供する。例えば、ＦＴＰ、ＨＴＴＰなどのプロトコルに加え、独自プロトコルをサポートする場合がある。
【００５６】
（第２の実施形態）
図４は、本発明の第２の実施形態にかかる認証サーバの多重化システムの全体構成図である。
図４において、４−１、４−２および４−３は、本発明にかかるシステムの構成のうち、クライアントＰＣおよびデバイス部分に相当するものであり、第１の実施形態で説明した図１の１−１〜１−３に相当する。
【００５７】
図４において、４−８は、本発明にかかるドメイン４−６の認証を統括する認証サーバである。これは利用者の識別と認証、およびアクセス制御情報の管理と付与など集中的に行う。例えば、Ｗｉｎｄｏｗｓ（Ｒ）のＡｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙなどが該当する。
【００５８】
図４において、４−４はプライマリ認証ＧＷ（ゲートウエイ）である。認証ＧＷは、クライアントＰＣおよびデバイスと認証サーバの間に介在し、利用者の認証処理を代理（プロクシ）する。この構成は、利用者が本発明にかかるシステムを導入する以前から、既に汎用の認証サーバ４−８を利用しているときに、本発明にかかるシステムを導入するために認証処理を代理する役割をもっている。従って、認証ＧＷ自身が直接クライアントＰＣやデバイスに対して認証処理を行うことはない。
【００５９】
また、利用者の既存の環境に複数種類の認証サーバが混在している場合、例えば、Ｗｉｎｄｏｗｓ（Ｒ）とＮｏｔｅｓなど、認証ＧＷがこれらの認証サーバに対してそれぞれ認証処理を代理することによって、利用者に共通の認証処理環境（例えば、シングルサインオン機能）を提供することを可能とする。
【００６０】
図４において、４−５はセカンダリ認証ＧＷである。クライアントＰＣおよびデバイスは、直接認証サーバ４−８と通信するのではなく、認証ＧＷ４−４を経由して識別と認証、並びにアクセス権の付与を受ける。従って、認証ＧＷ４−４に障害が発生した場合、クライアントＰＣおよびデバイスは、ドメイン４−６のリソースにアクセスすることができなくなる。セカンダリ認証ＧＷ４−５は、認証ＧＷ４−４に障害が発生した場合、その機能を代理するために設置される。
【００６１】
本実施形態にかかる認証サーバの多重化システムでは、認証ＧＷが多重化されるので、プライマリ認証ＧＷ４−４、およびセカンダリ認証ＧＷ４−５がチャレンジ・アンド・レスポンス方式に従った信頼性の確認を行う。すなわち、プライマリ認証ＧＷ４−４が乱数を生成・保存し、これを認証ＧＷ４−５の公開鍵で暗号化して送信する。
【００６２】
セカンダリ認証ＧＷ４−５は、受け取った暗号データを自身の秘密鍵で復号し、所定の電子署名処理を行った後、引き続き認証ＧＷ４−４の公開鍵で暗号化する。暗号データは再びプライマリ認証ＧＷ４−４に送信される。プライマリ認証ＧＷ４−４は、受け取った暗号データを自身の秘密鍵で復号し、電子署名を検証する。この検証結果に応じて、その後の適正な処理を実施する。
【００６３】
ところで、本発明にかかる第２の実施形態では、プライマリ認証ＧＷ４−４およびプライマリ認証ＧＷ４−５が多重化されており、それぞれが公開鍵暗号方式に基づく鍵ペアを生成している。システム管理者は、認証ＧＷを設置するときに、システム管理者自身の秘密鍵で認証ＧＷの公開鍵に対して電子署名を施す。これによって、認証ＧＷ４−４，４−５のドメイン４−６全体への信頼性の付与が行われる。
【００６４】
認証ＧＷと利用者環境の既存の認証サーバの通信は、例えば、Ｗｉｎｄｏｗｓ（Ｒ）の場合はＮＴＬＭ認証やＫｅｒｂｅｒｏｓ認証などが適用される。また、認証サーバがＮｏｔｅｓの場合は、ＬＤＡＰ認証が適用されることもある。従って、認証サーバは自身が利用者の認証処理を行わない代わりに、複数の認証プロトコルに適用しており、利用者の環境に混在する複数の認証サーバに対して共通の認証インターフェースを提供することが特徴となっている。
【図面の簡単な説明】
【００６５】
【図１】本発明の第１の実施形態にかかる認証サーバの多重化システムの全体構成図である。
【図２】本発明にかかる認証サーバの多重化システムにおいて、認証サーバが持っている機能構成を模式的に表した図である。
【図３】本発明にかかる認証サーバの多重化システムにおいて、チャレンジ・アンド・レスポンス方式に基づく通信手順を示すラダーチャートである。
【図４】本発明の第２の実施形態にかかる認証サーバの多重化システムの全体構成図である。
【符号の説明】
【００６６】
１−１  クライアントＰＣ−Ａ
１−２  クライアントＰＣ−Ｂ
１−３  ネットワークデバイス
１−４  認証サーバ（プライマリ）
１−５  認証サーバ（セカンダリ）
１−６  ドメイン
１−７  チャレンジ・アンド・レスポンス方式に基づくネットワーク通信
【図１】
2005165671.tif 000003
【図２】
2005165671.tif 000004
【図３】
2005165671.tif 000005
【図４】
2005165671.tif 000006