JP2005085102A - 保証システム - Google Patents

Abstract

【課題】 クライアントＰＣ或いはデバイスにおいて、多重化された認証サーバの信頼性を保証することができるようにする。
【解決手段】 ネットワークに接続されたクライアントＰＣ（１−１、１−３）、認証サーバ１（１−７）、並びにデバイス（１−５）によって構成された保証システムにおいて、認証サーバ１（１−７）のバックアップを目的として、認証サーバ２（１−８）を設けて多重化システムを構成し、クライアントＰＣ、認証サーバ１，２、並びにデバイスの相互間の暗号化通信に公開鍵暗号方式を利用し、認証サーバ１，２の公開鍵を、１人のシステム管理者（１−１０）の公開鍵暗号方式による秘密鍵で電子署名する。
【選択図】 図１

Description

本発明は、複数のクライアントサーバＰＣやデバイスとこれらを使用するユーザの認証を行い、かつ、リソースへのアクセスを制御する認証サーバによって構成される保証システムに関連するものであり、さらに詳しくは、当該認証サーバに障害が発生した場合に、機能をバックアップする二重化（冗長化）システムに関連する。また、さらに詳しくは、当該冗長化システムによって構成される複数の認証サーバに信頼性を与え、かつ、これを確認するシステムに関する。

ネットワークに接続されたクライアントＰＣ及びサーバ、デバイスによって構成される論理領域（ドメイン）において、ユーザがドメイン上の何らかのリソースを利用する場合、当該ユーザの認証とリソースへのアクセス権限の付与が必要である。クライアントサーバシステムにおける認証サーバは、独自あるいは標準化されたプロトコルに基づいて、当該ユーザ認証とアクセス権限の付与を行うよう、その機能を発揮することになる。

また、クライアントＰＣとサーバ間、或いはデバイスとサーバ間といった１対１の通信において、互いのセキュリティを確保しなければならない場合がある。例えば、通信データの機密性、完全性を保証する必要性や、通信相手の成りすましを防止する必要性などが挙げられる。これらの場合において、従来、公開鍵暗号方式を利用した鍵配布方法によれば、通信相手の成りすましを防止し、通信データを暗号化するための暗号鍵を安全に配布することが可能である。

認証サーバは、このような場合において、公開鍵暗号方式を利用した鍵配布サービスをクライアントＰＣ或いはデバイスに提供する機能も併せ持っている。ドメインにおける安全でかつ機密性の高いネットワークセキュリティは、当該認証サーバによって実現される。

ところで、前述したようなセキュリティ機能を提供する認証サーバは、ドメインの中で唯一でなければならない。すなわち、ドメインのユーザ管理や暗号鍵の管理、配布といった機能が、１つの認証サーバによって統一的に実施されることが必要である。これは、認証サーバの成りすまし等、セキュリティ上の問題（セキュリティホール）を回避するためである。

しかし一方で、ドメインを構成する認証サーバが１つしかない場合において、当該認証サーバに何らかの障害が発生すると、ユーザ認証並びにアクセス権限の付与といった機能が一切動作しなくなるといった問題が発生する。このような状態では、利用したいリソース、例えばデバイスやファイルサーバは正常に稼動していても、ユーザはその認証サーバから認証と使用権原が与えられないため、これらのリソースを使うことができなくなる。これは、ドメインに所属する認証サーバが１つしか存在しないからである。

このように、認証サーバは、その機能的な性格からドメインの中で唯一、稼動しなければならないが、一方で、前述のような障害時のシステムダウンといった問題が従来から指摘されている。この問題に対処するため、通常、ドメインを構成するクライアントサーバシステムにおいて、認証サーバの多重化或いは冗長化といった概念が考え出され実用化されている。

具体的には、ドメインにおける認証を制御する認証サーバを複数台用意しておき、全てを動作させておくのである。但し、認証サーバが複数、同時に稼動することは、上述したとおり問題がある。そこで、認証サーバには、有効に稼動する優先順位（プライオリティ）をあらかじめ設定しておき、プライオリティの高い認証サーバから順番に機能するように構成するのである。

すなわち、稼動中の複数台の認証サーバは互いに通信しあいながら、認証サーバが正常に稼動しているかどうかを確認しあう。定期的にこのプロセスを実行し、もしプライマリ認証サーバに障害が発生して稼動していないことがわかったら、セカンダリの認証サーバが自動的にドメインの認証サーバに昇格し、引き続き認証サービスを提供するのである。

多重化機能のある認証サーバは、第１優先の認証サーバに障害が発生して認証機能が停止した場合、第２優先の認証サーバが自動的に作業を引き継いで、認証作業或いはアクセス権限の付与といった作業を行う。さらに、第３優先の認証サーバがある場合、第２優先の認証サーバに引き続き障害が発生したら、自動的に第３優先の認証サーバが機能するような仕組みが備わっている。

このように認証サーバに障害が発生すると、ドメインを構成するリソースが使用できなくなるといった問題は、認証サーバの多重化によって解決可能である。しかし一方で、認証サーバが責任を負っていたセキュリティ機能の信頼性の観点で新たに問題がある。すなわち、認証サーバ自身の成りすましである。

認証サーバを多重化させるシステムでは、通常、管理者がバックアップ用の認証サーバをセットアップして起動させるが、この場合には、バックアップ用に立ち上げる認証サーバの信頼性を保証する仕組みが不十分である。バックアップ用の認証サーバが、本来の正しい管理者の意図しないサーバ（悪意のある認証サーバrogue server）であった場合、第１優先の認証サーバに障害が発生すると、この成りすました認証サーバが有効になってしまう場合が考えられる。

一度、前記rogue serverが稼動してしまうと、正規な手続きに従って登録されたユーザ以外の意図しないユーザが認証されてリソースにアクセスできてしまったり、正規ユーザの認証手続きからパスワードを盗み取ったりといった様々なセキュリティ上の問題が発生してしまう。

このような多くのセキュリティ上の問題の原因となるrogue serverは、バックアップ用の認証サーバとしてドメインに参加できないようにしなければならない。そのための手段として、現在、バックアップ用に認証サーバを設定する時に、管理者のパスワード認証を要求するといった手続きによって回避する方法がある。すなわち、認証サーバを正しくインストールして起動した後、第１優先の認証サーバがドメインに、第２優先の認証サーバを参加させるという作業工程を用意している。認証サーバの参加を行うためには、管理者のパスワード認証が必要であり、管理者パスワードの入力が求められる。

第１優先の認証サーバは、入力されたパスワード認証が正しい場合にのみ、第２優先の認証サーバをバックアップサーバとしてドメインに参加を許可するのである。通常、管理者のパスワードは、管理者のみが知りうる情報であり、原則として一般ユーザに知られることはない。従って、このような作業工程を導入することによって、第１優先の認証サーバは、勝手に第２優先の認証サーバがドメインに参加することを未然に防ぐことができる。ひいては、第１優先の認証サーバは、第２優先の認証サーバを信頼することが可能となるのである。

ところで、上記従来例で述べたごとく、管理者のパスワード認証による方法は、第１優先の認証サーバが第２優先の認証サーバを信頼する方法としては有効である。しかしながら、ドメインに参加しているクライアントＰＣ或いはデバイスからは、第２優先の認証サーバ、すなわちバックアップ用の認証サーバが信頼できるかどうかを判断することは難しい。

一般的に、バックアップ用の認証サーバのアドレスをクライアントＰＣやデバイスに登録する作業は、クライアントＰＣ或いはデバイスの所有者もしくは利用者がこれを行う。通常、クライアントＰＣ或いはデバイス側で、ドメイン管理者が管理者のパスワードを入力して信頼性を確認するような作業工程は用意されていない。このため、クライアントＰＣやデバイスの利用者が、第２優先の認証サーバアドレスを設定する際、利用者はなんらその信頼性について確かめる手段を持たずに、また、確かめることもなく設定することが可能となってしまう。

このことは、ドメインにおける多重化した認証サーバの成りすましを許すことにつながるため、認証サーバの多重化システムにおけるセキュリティホールとみなすことができる。また、従来の管理者パスワード認証方式では認証サーバの成りすましを完全に防止できるとはいえない。なぜなら、成りすました認証サーバをドメインに稼動させておき、ドメインの利用者にこの成りすまし認証サーバのアドレスを提供し、各自のクライアントＰＣやデバイスに設定させることが可能であり、システムの利用者にこの虚偽のアドレスを設定させてしまうことが可能だからである。

利用者が、ひとたびクライアントＰＣやデバイスに成りすました認証サーバのアドレスを設定してしまうと、以降、第１優先の認証サーバが障害でダウンしてしまったとき、先に従来例で述べたような様々なセキュリティ上の問題が露呈することになるのである。

本発明は、このような従来の技術の有する未決の課題に着目してなされたものであって、クライアントＰＣ或いはデバイスにおいて多重化された認証サーバの信頼性を保証する保証システムを提供することを目的としている。

加えて他の目的として、多重化認証サーバの信頼性を保証した上で、当該多重化された認証サーバのアドレス設定をクライアントＰＣ或いはデバイスにおこなうことによって、成りすまし認証サーバの登録を未然に防ぎ、ドメインのセキュリティを完全ならしめるための仕組みを提供する。

上記目的を達成するために本発明の保証システムは、ネットワークに接続されたクライアントＰＣ、認証サーバ、並びにデバイスによって構成され、利用者の識別と認証、並びにリソースへのアクセスと許可とを集中的に管理する前記認証サーバの多重化システムにおける信頼性を保証する保証システムにおいて、前記認証サーバのバックアップを目的として、前記認証サーバの多重化システムを構成し、前記クライアントＰＣ、前記認証サーバ、並びに前記デバイスの相互間の暗号化通信に公開鍵暗号方式を利用し、前記認証サーバの公開鍵を配布するに先立って、全ての前記認証サーバの公開鍵を、１人のシステム管理者の公開鍵暗号方式による秘密鍵で電子署名する。

本発明にかかる認証サーバの多重化システムにおける信頼性を保証するシステムによれば、バックアップ用の認証サーバを設置し、ドメインに参加させるに当たって、システム管理者の秘密鍵をもって暗号化されたユーザ情報をバックアップ認証サーバに送るため、当該ユーザ情報の機密性を確保することができる。また、バックアップ用の認証サーバのドメインへの参加を行うにあたって、システム管理者の信頼を付与することが可能となる。

さらに、クライアントＰＣおよびデバイスに、認証サーバのアドレスを登録するに当たって、１つのシステム管理者の公開鍵をもって、全ての認証サーバの公開鍵の正当性を確認してから行うため、全ての認証サーバの信頼性が一人のシステム管理者によって信頼を付与されたことを前提にすることができるようになる。従って、悪意のある第三者が、機密情報の不正取得を目的として不正な認証サーバをクライントＰＣやデバイスに登録しようとしても、未然にこれを防ぐことができる。

加えて、システム管理者の公開鍵は、一般に公開される性格のものであり、クライアントＰＣおよびデバイス側で署名データの検証を行う際、誰でもシステム管理者の公開鍵を入手し、検証作業を行うことが可能である。つまり、システム管理者が自らクライアントＰＣやデバイスの設置に立ち会って秘密のパスワードを入力するなどといった手間を全く必要とせず、このためシステム管理者のＴＣＯ削減を実現することができる。

一方、クライアントＰＣ、およびデバイスは、認証サーバのアドレス情報を登録するに当たり、認証サーバの正当性が確認できたもののみ登録するという安全機構が働くため、誤って異なった認証サーバのアドレスを登録してしまうといった手続き上の不注意によるミスも未然に防ぐことが可能となる。

以下、本発明の保証システムにおける実施形態について図面を参照しながら説明する。

図１は、本発明にかかる認証サーバの多重化システムにおける信頼性を保証する保証システムの全体構成図である。

図１に示すように、本実施形態における保証システムは、利用者向けにサービスを提供するクライアントＰＣ（１−１、１−３）と、ネットワークデバイス（１−５）と、利用者の識別と認証、アクセス制御などを統括する認証サーバ１（１−７）とを含んで構成されており、また、各々が物理的なネットワーク接続手段によって結合しており、相互に情報通信が可能となっている。

本実施形態における保証システムにおいて、ネットワークデバイス（１−５）とは、ネットワークに接続された印刷機器、あるいはスキャナ、プリンタ、ＦＡＸ機能などを併せ持った複合機を意図する。また、ファイルサーバ（不図示）なども本システムの構成に含まれる場合がある。物理的なネットワーク接続手段としては、イーサネット（Ｒ）による有線、あるいは無線ＬＡＮ規格に準拠した無線による情報通信があり、いずれの場合も本システムのネットワーク手段として予定される。

認証サーバ１（１−７）は、システム利用者の識別と認証、アクセス制御などを統括して制御し、システムのセキュリティを統括するセキュリティの論理領域（ドメイン：１−９）を構成する。ドメイン（１−９）は、他の認証サーバ２（１−８）が統括する別のセキュリティドメインと区別するための論理的な境界をも意味している。従って、物理的には同じネットワーク手段によって結合した複数のクライアントＰＣ、デバイス、並びに認証サーバ群が、論理的には複数のセキュリティドメインに分割されて運用されることもある。

原則として１つのドメインには、１つの認証サーバが優先的な認証サーバ（プライマリ認証サーバ）として存在しており、そのドメインのセキュリティを統括している。従って、複数のドメインがある場合は、それぞれのドメインに１つずつプライマリ認証サーバが設置される。なお、認証サーバの機能として、ドメインをまたがる認証やアクセス制御を実現するために、認証サーバ同士が信頼関係を結ぶための機能が備わっている場合もある。

ところで、ドメインにおけるセキュリティ機能の制御は、１つのプライマリ認証サーバが統括して行っているため、この認証サーバに障害が発生した場合、利用者はそのドメインのリソースを一切使用することができなくなってしまう。このような問題を解決するため、認証サーバを多重化し１台の認証サーバに障害が発生してもバックアップ用の他の認証サーバが以降の処理を引き継ぐ仕組みがある。このような仕組みは、多重化システム、冗長化システム、あるいはバックアップシステムなどと呼ばれ、バックアップ用の他の認証サーバをバックアップ認証サーバ、セカンダリ認証サーバなどと呼ぶ。

本発明にかかる認証サーバの多重化システムにおける信頼性を保証する保証システムは、認証サーバが多重化システムに対応する機能を有している。認証サーバ１（１−７）はプライマリ認証サーバで、障害発生時にバックアップ用の認証サーバである認証サーバ２（１−８）に自動的に切り替わり、認証などの処理を続行させることが可能である。

−プライマリ認証サーバの設置とドメインの構築−
図２は、本発明にかかる保証システムにおいて、プライマリ認証サーバを設置するときに、プライマリ認証サーバに信頼を付与するための工程を示すフローチャートである。

まず、図２の各工程を開始する前に、認証サーバとして機能するための必要なＯＳやアプリケーションソフトウエアを正しく導入しておく。また、ネットワークに接続するための必要な情報の設定・登録も行っておく。その後、図２のステップＳ２−１において、プライマリ認証サーバの設置工程を開始する。

続いて、ステップＳ２−２は、プライマリ認証サーバ自身の鍵ペアを生成する工程である。本発明にかかる保証システムでは、認証サーバ１（１−７）は、公開鍵暗号方式に基づく公開鍵と秘密鍵の組（ペア）を生成する必要がある。これらの暗号鍵は、クライアントＰＣ（１−１、１−３）やネットワークデバイス（１−５）と認証サーバ１（１−７）間で行われる通信の機密保持や成りすまし防止のために用いられる。また、公開鍵暗号方式としては、既知の標準的な暗号アルゴリズムが用いられる。例えば、ＲＳＡ、Ｄｉｆｆｉｅ＆Ｈｅｌｌｍａｎなどが例示できる。

続いて、ステップＳ２−３は、システム管理者（１−１０）の鍵ペアを生成する工程である。システム管理者（１−１０）は、認証サーバ１（１−７）によって構成されるドメイン（１−９）全体の管理者であり、システムのセキュリティに関する責任を担う。ここで、鍵ペアを生成するときの詳細は、認証サーバ１（１−７）の鍵ペアを生成する場合と同様である。

続いて、ステップＳ２−４は、プライマリ認証サーバ１（１−７）の公開鍵を、システム管理者（１−１０）の秘密鍵で電子署名する工程である。電子署名は、プライマリ認証サーバ１（１−７）の公開鍵の改ざんがなされていないことをシステム管理者（１−１０）が保障し、これを第三者に証明するための手立てとして用いられるものである。なお、プライマリ認証サーバ１（１−７）とシステム管理者（１−１０）との公開鍵は、いずれもクライアントＰＣ（１−１、１−３）、並びにネットワークデバイス（１−５）に公開されるものである。

上述した電子署名の方法の一例として、公開鍵データのハッシュ値を計算し、これをシステム管理者（１−１０）の秘密鍵で暗号化する手法が挙げられる。ハッシュ演算は、既知のハッシュアルゴリズムで、あらかじめ本システム導入時に決めておいたものを利用する。

また、署名データの正当性は以下のようにして確認される。

すなわち、あらかじめ電子署名データと公開鍵とを一緒に取得し、署名データをあらかじめ取得してあるシステム管理者（１−１０）の公開鍵で復号する。次に、一緒に取得した公開鍵データを、システム導入時に設定してあるハッシュアルゴリズムにかけて所定のハッシュ値を計算する。ここで、署名データを復号した値と、公開鍵のハッシュとが一致した場合、一緒に取得した公開鍵データは、改ざんされておらず、システム管理者（１−１０）によって署名されたものであることが明確となる。

その後、ステップＳ２−５に進み、プライマリ認証サーバ１（１−７）はシステム管理者（１−１０）による信頼が付与され、設置が完了する。また、この工程を経ることによって、ドメイン（１−９）が構築されたとみなすことができる。

−バックアップ用認証サーバの設置とドメインへの参加−
次に、上記のごとく構成されたドメイン（１−９）に、セカンダリ認証サーバ２（１−８）を設置し、さらに、システム管理者（１−１０）によって信頼を付与するための工程について説明する。

図３は、本発明にかかる保証システムにおいて、セカンダリ認証サーバを設置するときに、セカンダリ認証サーバに信頼を付与するための工程を示すフローチャートである。

まず、システム管理者（１−１０）による信頼の付与を行う前に、認証サーバとして機能するための必要なＯＳやアプリケーションソフトウエアを正しく導入し、さらに、ネットワークに接続するための必要な情報の設定・登録も行っておく作業があることは、プライマリ認証サーバ１（１−７）と同様である。その後、図３のステップＳ３−１において、セカンダリ認証サーバの設置工程を開始する。

続いて、ステップＳ３−２は、セカンダリ認証サーバ２（１−８）の鍵ペアを生成する工程である。鍵ペアを生成するときの詳細は、プライマリ認証サーバ１（１−７）における鍵ペアを生成するステップＳ２−２で述べた工程と同様である。これらの暗号鍵は、クライアントＰＣ（１−１、１−３）やネットワークデバイス（１−５）と認証サーバ２（１−８）間で行われる通信の機密保持や成りすまし防止のために用いられる。また、プライマリ認証サーバ１（１−７）の場合同様、セカンダリ認証サーバ２（１−８）の鍵ペアのうち、公開鍵クライアントＰＣ（１−１、１−３）やネットワークデバイス（１−５）に公開される。

続いて、ステップＳ３−３は、プライマリ認証サーバ１（１−７）から送信されたバックアップ情報を、システム管理者（１−１０）の秘密鍵で復号し、セカンダリ認証サーバ２（１−８）の所定の記憶領域に登録する工程である。ここで、バックアップ情報は、利用者の識別と認証、並びにアクセス制御に必要な各種のユーザ情報を主として含むものであり、ドメイン（１−９）のセキュリティを維持するために重要な情報である。あわせて、セカンダリ認証情報は、できるだけ最新のバックアップ情報を保持し、プライマリ認証サーバ１（１−７）に障害が発生した場合、直ちに利用者の認証などの機能を代行しなければならない。

バックアップ情報は、上記の性格を有するため、セカンダリ認証サーバ２（１−８）の設置時に、プライマリ認証サーバ１（１−７）からセカンダリ認証サーバ２（１−８）へ送信される。また、送信は通常、ネットワークを経由して行われるため、情報の機密性を十分に補償しなければならない。このため、バックアップ情報をシステム管理者（１−１０）の秘密鍵で暗号化したうえで、これをセカンダリ認証サーバ２（１−８）に送信する。

続いて、ステップＳ３−４では、セカンダリ認証サーバ２（１−８）は、バックアップ情報を暗号化された状態で受け取るため、これをシステム管理者（１−１０）の秘密鍵で復号処理し、所定の記憶領域に保持する。通常、システム管理者（１−１０）の秘密鍵は、管理者本人のみ知りうる情報であり、従って、本発明にかかる保証システムでは、セカンダリ認証サーバ２（１−８）の登録のために、システム管理者（１−１０）が常に設置に関わる仕組みになっている。

その後、ステップＳ３−５に進み、認証サーバ２（１−８）はシステム管理者（１−１０）の信頼を付与され、設置が完了する。これにより、認証サーバ２（１−８）はドメイン（１−９）に参加したことになる。

−クライアントＰＣ、もしくはネットワークデバイスにおける認証サーバアドレスの登録−
クライアントＰＣ（１−１、１−３）もしくはネットワークデバイス（１−５）は、利用者の認証を行うためにドメイン（１−９）のセキュリティを管理する認証サーバと通信する必要がる。そのために、クライアントＰＣ（１−１、１−３）およびネットワークデバイス（１−５）は正しく設置された後、認証サーバのネットワーク上のアドレス情報があらかじめ登録されていなければならない。

ここで、ネットワーク上のアドレス情報は、ネットワークにおける通信プロトコルに依存していくつかの形態があるが、例えば、ＴＣＰ／ＩＰによるＩＰアドレス情報がこの場合のアドレス情報に該当する。また、Ｗｉｎｄｏｗｓ（Ｒ）のプロトコルであるＮｅｔＢＥＵＩの場合は、コンピュータ名が該当する。

図４は、クライアントＰＣ（１−１、１−３）、もしくはネットワークデバイス（１−５）における認証サーバアドレスの登録処理について説明するフローチャートである。

クライアントＰＣ（１−１、１−３）およびネットワークデバイス（１−５）は、利用者あるいは専門のスタッフによって正しく設置された後、図４のステップＳ４−１において、認証サーバアドレスの登録工程を開始する。

続いて、ステップＳ４−２は、システム管理者（１−１０）の公開鍵を取得する工程である。公開鍵の入手は、例えば、所定の磁気媒体を利用してオフラインで行っても良いし、あるいは所定の既存のディレクトリサーバや公開鍵配布サーバを利用することも可能である。ここで入手するシステム管理者（１−１０）の公開鍵は、後述する電子署名の正当性の確認において利用される。

続いて、ステップＳ４−３は、プライマリ認証サーバ１（１−７）のアドレスを、クライアントＰＣ（１−１、１−３）あるいはネットワークデバイス（１−５）に登録する工程である。なお、アドレス情報の登録の詳細は、フローチャートを用いて後に説明する。

続いて、ステップＳ４−４は、セカンダリ認証サーバ２（１−８）のアドレスを、クライアントＰＣ（１−１、１−３）あるいはネットワークデバイス（１−５）に登録する工程である。これについても、後述する。

このステップＳ４−４までを実施することで、クライアントＰＣ（１−１、１−３）およびネットワークデバイス（１−５）には、プライマリ認証サーバ１（１−７）と、セカンダリ認証サーバ２（１−８）のそれぞれのアドレス情報が登録されたことになる。これによって、例えば、プライマリ認証サーバ１（１−７）に何らかの障害が発生した場合でも、セカンダリ認証サーバ２（１−８）が機能を受けついで、引き続き処理を実行することができるようになる。これにより、利用者は、仮にプライマリ認証サーバ１（１−７）の障害が発生したとしても、ドメイン（１−９）のリソースを引き続き利用することができるようになるのである。

本実施形態においては、クライアントＰＣ（１−１、１−３）並びにネットワークデバイス（１−５）には、プライマリ認証サーバ１（１−７）とセカンダリ認証サーバ２（１−８）との２つのアドレス情報しか設定しないように説明したが、実際には、この部分を拡張して、３台目、あるいは４台目の認証サーバを登録できるようにして、さらに多重化を進め、リスクを軽減することが可能であることはいうまでもない。

続いて、ステップＳ４−５は、１つ以上の認証サーバを登録することができたか否かを評価する工程である。これは、クライアントＰＣ（１−１、１−３）あるいはネットワークデバイス（１−５）に１つの認証サーバアドレスも登録することができなかった場合を判別するために設けられた工程である。クライアントＰＣ（１−１、１−３）あるいはネットワークデバイス（１−５）にとって、認証サーバアドレスが１つも登録できないことは、どの認証サーバにもアクセスができないことになる。

すなわち、ドメイン（１−９）における認証を全く受けられないことを意味する。これは、クライアントＰＣ（１−１、１−３）あるいはネットワークデバイス（１−５）が、ドメイン（１−９）に参加できなかったことをも意味する。この処理工程を設けることによって、システム管理者（１−１０）の認識していないクライアントＰＣ（１−１、１−３）やネットワークデバイス（１−５）に対するドメイン（１−９）への勝手な参加を未然に防ぐことが可能である。

ステップＳ４−５の評価の結果、１つ以上の認証サーバを登録することができたと評価された場合には、ステップＳ４−６に進む。一方、ステップＳ４−５の評価の結果、１つの認証サーバも登録することができなかったと評価された場合には、ステップＳ４−７に進む。

続いて、ステップＳ４−６は、１つ以上の認証サーバが登録できた場合に処理される工程であり、具体的には、クライアントＰＣ（１−１、１−３）およびネットワークデバイス（１−５）のドメイン（１−９）への参加を完了する工程である。このステップＳ４−６は、正常な処理における最終工程である。

一方、ステップＳ４−７は、何らかの原因で１つの認証サーバも登録できなかった場合に処理される工程であり、具体的には、クライアントＰＣ（１−１、１−３）もしくはネットワークデバイス（１−５）におけるドメイン（１−９）への参加を一切認めずに、その旨を報知するダイアログやログを残して処理を終了する工程である。

その後、ステップＳ４−８に進み、クライアントＰＣ（１−１、１−３）あるいはネットワークデバイス（１−５）におけるドメイン（１−９）への参加工程を終了する。

次に、クライアントＰＣ（１−１、１−３）あるいはネットワークデバイス（１−５）への認証サーバアドレスの登録処理工程について説明する。

図５は、クライアントＰＣ（１−１、１−３）あるいはネットワークデバイス（１−５）への認証サーバアドレスの登録処理におけるフローチャートである。

まず、ステップＳ５−１では、ステップＳ４−３あるいはステップＳ４−４において認証サーバアドレスの登録処理が行われるときに、認証サーバアドレスの登録処理工程を開始する。

続いて、ステップＳ５−２では、クライアントＰＣ（１−１、１−３）もしくはネットワークデバイス（１−５）は、認証サーバの公開鍵と署名データを取得する。この署名データは、認証サーバを設置しシステム管理者（１−１０）によって信頼を付与されたときに作成したデータである（ステップＳ２−４およびステップＳ３−３）。また、公開鍵と署名データの取得は、本実施形態では、認証サーバからネットワークを経て所定のプロトコルによって取得する。しかし、所定の磁気ディスクなどを利用してオフラインで取得することもできる。

続いて、ステップＳ５−３は、システム管理者（１−１０）の公開鍵を使用して、ステップＳ５−２において取得した署名データの検証を行う工程である。署名データの検証は、前述のプライマリ認証サーバ１（１−７）の設置とドメイン（１−９）の構築の中で記述したとおりである。具体的には、署名データをシステム管理者（１−１０）の公開鍵で復号し、一方で、システム設定時に決定したハッシュアルゴリズムに基づいて計算した認証サーバの公開鍵のハッシュ値を計算する。

続いて、ステップＳ５−４は、ステップＳ５−３で検証した署名データが正当であるか否かを判定する。具体的には、システム管理者（１−１０）の公開鍵で復号したデータとハッシュ値とが一致するかどうかを判定する。この判定により、一致する場合には、認証サーバの公開鍵は改ざんされておらず、しかも正当なシステム管理者（１−１０）によって署名されたものであると判断することができる。

ステップＳ５−４の判定の結果、署名データが正当であると判定された場合には、ステップＳ５−５に進む。一方、ステップＳ５０４の判定の結果、署名データが正当でないと判定された場合には、ステップＳ５−６に進む。

続いて、ステップＳ５−５は、公開鍵の署名データが正当である場合に処理される工程であり、当該認証サーバのアドレス情報をクライアントＰＣ（１−１、１−３）もしくはネットワークデバイス（１−５）に保持する工程である。

一方、ステップＳ５−６は、公開鍵の署名データが正当でない場合に処理される工程であり、この署名データに関連付けされた公開鍵を破棄する工程である。

ここで、ステップＳ５−３において、署名データの検証に使用するシステム管理者（１−１０）の公開鍵は、プライマリ認証サーバ１（１−７）のアドレス登録（ステップＳ４−３）の時と、セカンダリ認証サーバ２（１−８）のアドレス登録（ステップＳ４−４）の時とで同一のものを使用する。これによって、１人のシステム管理者（１−１０）によって管理されているドメイン（１−９）におけるセキュリティを、クライアントＰＣ（１−１、１−３）およびネットワークデバイス（１−５）においても補償することが可能となる。

ステップＳ５−３において、同一のシステム管理者（１−１０）の公開鍵が適用されることを強制するために、本発明にかかる保証システムは、ステップＳ４−２において取得したシステム管理者（１−１０）の公開鍵データをクライアントＰＣ（１−１、１−３）もしくはネットワークデバイス（１−５）の所定の記憶領域（１−２、１−４、１−６）に保持しておき、ステップＳ４−３およびステップＳ４−４の処理におけるステップＳ５−３の実行において、ソフトウエアプログラムとして自動的に先の記憶領域からシステム管理者（１−１０）の公開鍵を取得し、ステップＳ５−３の処理が実行されるよう構成されている。

その後、ステップＳ５−７に進み、認証サーバの公開鍵の正当性が判断され、当該認証サーバのアドレス情報が登録、あるいは破棄されて、認証サーバアドレスの登録処理工程を終了する。これ以降、ステップＳ４−５の処理工程に復帰して、前述したとおりの処理が行われる。

−認証サーバの切り替え−
次に、認証サーバ１（１−７）に障害が発生したときに、バックアップ用に用意された認証サーバ２（１−８）に切り替わる処理を説明する。

ドメイン（１−９）に参加しているクライアントＰＣ（１−１）、クライアントＰＣ（１−３）、並びにネットワークデバイス（１−５）は、利用者がリソースにアクセスして利用するために、最初に当該利用者の識別と認証およびアクセス制御情報の受け渡しを行う。このとき、各クライアントＰＣ（１−１、１−３）もしくはネットワークデバイス（１−５）は、登録してある認証サーバのアドレス情報に基づいて、プライマリ認証サーバ１（１−７）からアクセスを試みる。

もし、プライマリ認証サーバ１（１−７）との通信が失敗して、これらの情報取得に失敗した場合には、次に、セカンダリ認証サーバ２（１−８）として登録してあるアドレス情報にアクセスする。ここで、失敗する場合の事例として、所定のプロトコルに従って通信しようとしても、レスポンスがエラーになってしまう場合や、全くレスポンスがなく、通信がタイムアウトになってしまう場合などが挙げられる。

（他の実施形態）
次に、本発明にかかる認証サーバの多重化システムにおける信頼性を保証する保証システムの他の実施形態について説明する。

図６は、本発明にかかる認証サーバの多重化システムの信頼性を保証する他の実施形態における保証システムの全体構成図である。

図６に示す６−１〜６−６は、本発明にかかる保証システムの構成のうち、クライアントＰＣおよびデバイス部分に相当するものであり、先の実施形態で説明した図１の１−１〜１−６の構成に等しい。

図６に示した認証サーバ（６−９）は、利用者の識別と認証、およびアクセス制御情報の管理と付与など集中的に行う。例えば、Ｗｉｎｄｏｗｓ（Ｒ）のＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙなどが該当する。

図６に示した６−７は、プライマリ認証ＧＷ（ゲートウエイ）１である。認証ＧＷは、クライアントＰＣ（６−１、６−３）およびネットワークデバイス（６−５）と認証サーバ（６−９）との間に介在し、利用者の認証処理を代理（プロクシ）する。この構成は、利用者が本発明にかかる保証システムを導入する以前から、既に汎用の認証サーバ（６−９）を利用しているときに、本発明にかかる保証システムを導入するために認証処理を代理する役割をもっている。従って、認証ＧＷ自身が直接、クライアントＰＣ（６−１、６−３）やネットワークデバイス（６−５）に対して認証処理を行うことはない。

ここで、利用者の既存の環境に複数種類の認証サーバが混在している場合には（例えば、Ｗｉｎｄｏｗｓ（Ｒ）とＮｏｔｅｓなど）、認証ＧＷ１（６−７）がこれらの認証サーバに対してそれぞれ認証処理を代理することによって、利用者に共通の認証処理環境（例えば、シングルサインオン機能）を提供することが可能となる。

また、図６に示した６−８は、セカンダリ認証ＧＷ２である。これは、プライマリ認証ＧＷ１（６−７）に障害が発生した場合、その機能を代理する役割を果たすものである。また、６−１０は、上記のクライアントＰＣ（６−１、６−３）、ネットワークデバイス（６−５）、認証サーバ（６−９）によって構成されるセキュリティのドメインを示したものである。このドメイン（６−１０）は、１人のシステム管理者（６−１１）によって統一的に管理される。

本発明にかかる保証システムの他の実施形態は、前述した認証ＧＷ１（６−７）および認証ＧＷ２（６−８）が多重化されており、それぞれが公開鍵暗号方式に基づく鍵ペアを生成する。そして、システム管理者（６−１１）の秘密鍵による電子署名は、当該認証ＧＷの設置時に、それぞれの公開鍵に対して行われる。これによって、認証ＧＷ１（６−７）および認証ＧＷ２（６−８）のドメイン（６−１０）への設置と信頼性の付与がなされる。

一方、クライアントＰＣ（６−１、６−３）およびネットワークデバイス（６−５）における認証ＧＷのアドレス情報の登録に関しては、先に説明した実施形態と同じ工程が適用される。また、各認証ＧＷと利用者環境の既存の認証サーバ（６−９）との通信は、例えば、Ｗｉｎｄｏｗｓ（Ｒ）の場合はＮＴＬＭ認証やＫｅｒｂｅｒｏｓ認証などが適用される。また、認証サーバ（６−９）がＮｏｔｅｓの場合には、ＬＤＡＰ認証が適用されることもある。従って、認証サーバ（６−９）は自身が利用者の認証処理を行わない代わりに、複数の認証プロトコルに適用しており、利用者の環境に混在する複数の認証サーバに対して共通の認証インターフェースを提供することが特徴となっている。

以下、本発明の諸態様を附記としてまとめて記載する。

［附記１］ ネットワークに接続されたクライアントＰＣ、認証サーバ、並びにデバイスによって構成され、利用者の識別と認証、並びにリソースへのアクセスと許可とを集中的に管理する前記認証サーバの多重化システムにおける信頼性を保証する保証システムにおいて、
前記認証サーバのバックアップを目的として、前記認証サーバの多重化システムを構成し、前記クライアントＰＣ、前記認証サーバ、並びに前記デバイスの相互間の暗号化通信に公開鍵暗号方式を利用し、前記認証サーバの公開鍵を配布するに先立って、全ての前記認証サーバの公開鍵を、１人のシステム管理者の公開鍵暗号方式による秘密鍵で電子署名することを特徴とする保証システム。

［附記２］ ネットワークに接続されたクライアントＰＣ、認証サーバ、並びにデバイスによって構成され、利用者の識別と認証、並びにリソースへのアクセスと許可とを集中的に管理する前記認証サーバの多重化システムにおける信頼性を保証する保証システムにおいて、
前記クライアントＰＣ及び前記デバイスは、全ての前記認証サーバの電子署名された公開鍵、並びに前記認証サーバのアドレス情報を登録するに先立って、システム管理者の公開鍵を利用して当該認証サーバの公開鍵の正当性を検証することを特徴とする保証システム。

［附記３］ 前記クライアントＰＣ及び前記デバイスは、前記電子署名の正当性が確認された場合にのみ、最初の認証サーバ（プライマリ認証サーバ）の公開鍵とアドレス情報とを保持することを特徴とする附記２に記載の保証システム。

［附記４］ 前記クライアントＰＣ及び前記デバイスは、バックアップ用に設置した認証サーバ（バックアップ認証サーバ）の公開鍵とアドレス情報とを保持するにあたって、前記電子署名の正当性を最初に確認した時に利用したシステム管理者の公開鍵を用いて当該バックアップ認証サーバの公開鍵の正当性を検証して、当該正当性が確認された場合にのみ、当該バックアップ認証サーバの公開鍵とアドレス情報とを保持することを特徴とする附記２に記載の保証システム。

［附記５］ ネットワークに接続されたクライアントＰＣ、認証サーバ、並びにデバイスによって構成され、利用者の認証及びリソースへのアクセスと許可とを集中的に管理する前記認証サーバの多重化システムの信頼性を保証する保証方法において、
最初の認証サーバ（プライマリ認証サーバ）設置時に当該プライマリ認証サーバの公開鍵暗号方式による鍵ペアを生成する工程と、
システム管理者の鍵ペアを生成する工程と、
前記プライマリ認証サーバ自身の公開鍵を前記システム管理者の秘密鍵で電子署名する工程と、
バックアップ用の認証サーバ（バックアップ認証サーバ）設置時に当該バックアップ認証サーバの公開鍵暗号方式による鍵ペアを生成する工程と、
前記バックアップ認証サーバ自身の公開鍵を前記システム管理者の秘密鍵で電子署名する工程と、
前記プライマリ認証サーバ及び前記バックアップ認証サーバの電子署名に関連付けられた公開鍵を前記クライアントＰＣ及び前記デバイスで受け取って、同一のシステム管理者の公開鍵で電子署名の正当性を検証し、当該検証を行ってから前記認証サーバの公開鍵を前記クライアントＰＣ及び前記デバイス自身の所定の記憶領域に格納する工程とを有することを特徴とする保証方法。

［附記６］ ネットワークに接続されたクライアントＰＣ、認証サーバ、並びにデバイスによって構成され、利用者の認証及びリソースへのアクセスと許可とを集中的に管理する前記認証サーバの多重化システムの信頼性を保証する保証方法において、
前記クライアントＰＣ及び前記デバイスは、前記認証サーバのアドレス情報を自身の所定の記憶領域に格納するときに、システム管理者の公開鍵で電子署名の正当性を検証して、当該正当性が確認できた場合にのみ、当該認証サーバのアドレス情報を格納することを特徴とする保証方法。

本発明にかかる認証サーバの多重化システムにおける信頼性を保証するシステムの全体構成図である。 本発明にかかる保証システムにおいて、プライマリ認証サーバを設置するときに、プライマリ認証サーバに信頼を付与するための工程を示すフローチャートである。 本発明にかかる保証システムにおいて、セカンダリ認証サーバを設置するときに、セカンダリ認証サーバに信頼を付与するための工程を示すフローチャートである。 クライアントＰＣ、もしくはデバイスにおける認証サーバアドレスの登録処理について説明するフローチャートである。 クライアントＰＣあるいはデバイスへの認証サーバアドレスの登録処理について説明するフローチャートである。 本発明にかかる認証サーバの多重化システムの信頼性を保証する他の実施形態における保証システムの全体構成図である。

符号の説明

１−１、１−３ クライアント
１−２、１−４、１−６ 記憶領域
１−５ ネットワークデバイス
１−７ 認証サーバ１
１−８ 認証サーバ２
１−９ ドメイン
１−１０ システム管理者

Claims (1)

1. ネットワークに接続されたクライアントＰＣ、認証サーバ、並びにデバイスによって構成され、利用者の識別と認証、並びにリソースへのアクセスと許可とを集中的に管理する前記認証サーバの多重化システムにおける信頼性を保証する保証システムにおいて、
   前記認証サーバのバックアップを目的として、前記認証サーバの多重化システムを構成し、前記クライアントＰＣ、前記認証サーバ、並びに前記デバイスの相互間の暗号化通信に公開鍵暗号方式を利用し、前記認証サーバの公開鍵を配布するに先立って、全ての前記認証サーバの公開鍵を、１人のシステム管理者の公開鍵暗号方式による秘密鍵で電子署名することを特徴とする保証システム。

Images