JP2000010930A - ネットワークシステムでのアクセス制御方法 - Google Patents

Abstract

(57)【要約】 【課題】業務サーバ，ＤＢサーバ，グループウェアサー
バ等が従来のＡＣＬで行っていたアクセス制御処理を、
アクセス制御サーバで集中的に一元管理する。またアク
セスチケットを利用して、ネットワークシステム利用の
一時的制約やユーザのアクセス状況を把握して、より柔
軟なネットワーク運用を行う。 【解決手段】ユーザの認証後あるいはクライアント８，
２０からアクセス制御サーバ５０に対してユーザの業務
要求が転送された時に、アクセス制御サーバ５０が統合
認証サーバ２によるユーザの証明証の確認結果からユー
ザの業務サーバ６へのアクセス権限のチェックを行い、
正当であれば業務サーバ６へのユーザの業務要求を許可
する。その場合、通信内容を第三者には見せないことを
保証する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、認証サーバ、アク
セス制御サーバ、およびクライアントに対して、証明証
を利用して広域ネットワークシステムでユーザ認証およ
びアクセス制御を行うネットワークシステムでのアクセ
ス制御方法に関する。

【０００２】

【従来の技術】インターネットの普及に伴いセキュリテ
ィをめぐる市場動向はめざましく変化してきた。特に、
インターネットとイントラネットを統合する認証サーバ
は重要であり、広域ネットワークシステムでユーザを一
元管理し、さらに集中的にアクセス制御を行う機能が求
められている。ユーザ認証及びアクセス制御に証明証を
利用する方法は、今後の広域ネットワークシステムでは
一般的になると思われる。しかし、現実のネットワーク
システムを考えると、最初から一元的なユーザ管理を行
うことは困難であり、従来のユーザのネットワークシス
テムや業務形態に応じて、各業務サーバが個別にユーザ
のアクセス制御を行うことになると考えられる。この様
なシステムの問題点としては、例えば企業内の人事移動
に伴う職制変更等の時などに、複数の業務システムのデ
ータベースのユーザ情報（例えば、認証情報やアクセス
制御情報）を変更しなければならない点である。

【０００３】本出願人は、本願より先に２つの提案（特
願平９−７６９５４号（先願Ａ）、および特願平９−１
７３５３２号（先願Ｂ）の各明細書および図面参照）を
行っているが、先願Ａでは、統合認証サーバで証明証に
よりユーザを認証することにより、従来のパスワードに
よる認証処理とのシングルサインオンを実現している。
また、クライアントと統合認証サーバの双方でユーザに
関するアクセス履歴を取得し、両者を比較することによ
りユーザの不正なアクセス状況をチェックしている。一
方、先願Ｂでは、このセキュリティ管理モデルを拡張
し、ユーザが複数の証明書により取り引きを行う場合に
証明書の管理を容易化している。具体的には、統合認証
サーバで１枚の統合証明書によりユーザを認証し、クラ
イアントから業務APあるいは通信相手への通信要求に応
じて、取り引きに必要な証明書を通信の当事者に送信す
るようにしている。先願Ｂの方式は、統合認証サーバで
統合証明書の確認を集中的に行うシステム形態を想定し
ており、この場合には前記通信要求に関するユーザのア
クセス権限の確認を統合証明書の認証処理の延長で行う
ことができる。なお、本願では、先願Ａに合わせて認証
サーバが発行する証明を証明証と記載する。

【０００４】

【発明が解決しようとする課題】前述のように、統合認
証サーバで統合証明証の確認を集中的に行うシステム形
態のアクセス制御方式については、先願Ｂに開示されて
いる。しかしながら、認証処理のために統合認証サーバ
を設けず、通信の当事者間で、例えばセキュア通信ライ
ブラリを実装することにより認証プロトコルに基づいて
相互認証するシステム形態を考えると、アクセス制御を
集中的に管理するアクセス制御サーバを設けたセキュリ
ティ管理の方が適していると考える。

【０００５】そこで、本発明の目的は、このような従来
の課題を解決し、前記セキュア通信ライブラリと連携し
てアクセス制御を実現することにより、企業内のネット
ワークシステムを１箇所から集中管理することが可能な
ネットワークシステムでのアクセス制御方法を提供する
ことにある。また、本発明の他の目的は、アクセス制御
ライブラリを通信の当事者に実装したシステム形態を考
慮し、その場合に必要となる前記アクセス制御サーバと
の間のアクセス権限情報を送受信することができる機能
を有するネットワークシステムでのアクセス制御方法を
提供することにある。

【０００６】

【課題を解決するための手段】上記目的を達成するた
め、本発明によるネットワークシステムでのアクセス制
御方法では、ユーザを認証した後に、あるいは該ユー
ザが共有するクライアントからアクセス制御サーバに対
してユーザの業務要求が転送された時に、アクセス制御
サーバが該ユーザの証明証の確認結果からユーザの該業
務サーバへのアクセス権限のチェックを行い、正当であ
れば業務サーバへのユーザの業務要求を許可することを
特徴とする。また、本発明のアクセス制御方法では、
クライアントにアクセス制御ライブラリを設ける場合に
は、アクセス制御サーバＩＤ，ユーザＩＤ，アクセス制
御リスト、制約条件、署名情報等から構成されるアクセ
スチケット情報を利用して、ユーザのアクセス権限をチ
ェックするために、次の処理を行うことも特徴とする。 (1)アクセス制御ライブラリで、前記アクセスチケット
を用いて該ユーザの業務サーバへのアクセス権限チェッ
クするステップと、該業務サーバへのアクセス要求が適
切であった場合には該業務サーバに該ユーザの業務要求
と前記アクセスチケットを転送するステップと、(2)業
務サーバで、該ユーザによるデータへのアクセス権限の
チェック結果を含むアクセス履歴情報を作成するステッ
プと、該ユーザによるアクセスの終了時に業務結果と前
記アクセス履歴情報を付加したアクセスチケットを該ア
クセス制御ライブラリに送信するステップと、(3)該ア
クセス制御ライブラリで、前記アクセスチケットの内容
を確認して該ユーザのアクセス状況をチェックするステ
ップと、該アクセス状況に問題があった場合にはセキュ
リティ侵害情報を作成するステップと、前記セキュリテ
ィ侵害を付加したアクセスチケットを該アクセス制御サ
ーバに送信するステップとを有することである。

【０００７】さらに、本発明のアクセス制御方法では、
アクセス制御サーバ、クライアントのアクセス制御ラ
イブラリ及び業務サーバとの間で送受信されるアクセス
チケットの情報については、通信の当事者以外には見せ
ないことを保証することも特徴とする。本発明では、証
明証を基にユーザのアクセス制御情報を参照することに
より、全てのサーバへのアクセス制御を行う方式を提案
する。すなわち、証明証を利用して広域ネットワークシ
ステムでユーザ認証及びアクセス制御を行う認証サーバ
とアクセス制御サーバに関わるものであり、先願Ａで提
案した統合認証サーバとの連携を実現するアクセス制御
方法を対象としている。これにより、業務サーバやデー
タベース（ＤＢ）サーバ、グループウェアサーバ等が、
従来ではＡＣＬ（アクセス制御リスト）で行っていたア
クセス制御処理を、アクセス制御サーバで集中的に一元
管理することができ、またアクセスチケットを利用する
ことにより、ネットワークシステム利用の一時的制約や
ユーザのアクセス状況を把握することができ、柔軟なネ
ットワークの運用が可能になる。

【０００８】

【発明の実施の形態】以下、本発明の実施例を、図面に
より詳細に説明する。図１は、本発明が適用されるネッ
トワークシステムの構成図である。インターネットのよ
うな広域ネットワーク１０には、企業ネットワークシス
テム１と他企業ネットワークシステム９が接続される。
企業ネットワークシステム１には、複数のクライアント
８（ここでは、１個のみ示されている）の他に、統合認
証サーバ２，セキュリティ情報を管理するサーバ３、ア
クセス制御サーバ５０、業務サーバ６、ＤＢサーバ５、グ
ループウェアサーバ４，鍵管理サーバ１７，および証明
証発行サーバ１８等の各サーバが接続される。ここで、
ＤＢサーバ５および業務サーバ６は、クライアント８か
らアクセスされ、かつ業務処理のために利用されるサー
バである。また、グループウェアサーバ４は、クライア
ント８へ最初の業務メニュー画面を送ったり、クライア
ント８の電子メールの送受信管理をしたり、ユーザのス
ケジュールを管理したりするサーバである。一方、他企
業ネットワークシステム９には、クライアント２０が接
続されており、クライアント８のユーザとクライアント
２０は、電子取り引き等の特定の業務を証明証を用いて
行うものとする。なお、クライアントシステム８には、
アクセス制御ライブラリ５１とセキュア通信ライブラリ
５２が備えられ、これを黒枠で示しており、ネットワー
クシステム１，９に接続されているクライアントシステ
ム２０と各サーバ４，５，６，５０にも同じライブラリ
が備えられていることを黒枠で示している。

【０００９】セキュリティ情報を管理するサーバ３は、
ＤＢサーバ５および業務サーバ６または他企業ネットワ
ークシステム９へのアクセスを制御する情報と、業務に
応じた証明証の情報を含むユーザの認証情報からなるセ
キュリティ情報とを、一元的に管理するサーバである。
公開鍵等もこのサーバ３で扱われる。また、統合認証サ
ーバ２は、クライアント８から送られる証明証を確認
し、サーバ３からセキュリティ情報を取得してユーザが
企業ネットワークシステム１にログインする資格を持つ
か否かを調べる。このユーザの識別と認証処理が終了す
ると、ユーザのＤＢサーバ５および業務サーバ６または
他企業ネットワークシステム９へのアクセス権限をチェ
ックする必要があるため、該ユーザのＡＣＬ（アクセス
制御リスト）をサーバ３に要求する。該ＡＣＬの要求処
理は、統合認証サーバ２がユーザの認証処理の延長で行
うことにより、サーバ３から取得したセキュリティ情報
の中からＡＣＬだけをアクセス制御サーバ５０に渡すよ
うに実装することも可能であり、また、アクセス制御サ
ーバ５０が直接前記サーバ３からＡＣＬを取得するよう
に実装することも可能である。また、ＡＣＬを取得する
タイミングとしては、ユーザの認証処理の後でも、ユー
ザからの業務要求を受けた時でもよい。

【００１０】図２は、本発明におけるＡＣＬを取得する
手順および業務要求に対して許可／拒絶を受ける手順を
示すシーケンスチャートである。図２（ａ）のシーケン
スチャートでは、セキュア通信ライブラリ５２がユーザ
を認証した後に、アクセス制御サーバ５０にユーザのア
クセス無限の確認要求を行い、アクセス制御サーバ５０
がサーバ３にＡＣＬを要求する処理例を示している。ま
た、図２（ｂ）のシーケンスチャートでは、クライアン
ト８のユーザの業務要求がアクセス制御サーバ５０に転
送された時に、同時にユーザのアクセス権限の確認要求
が行われ、アクセス制御サーバ５０で該ユーザの証明証
の確認結果からユーザの該業務サーバへのアクセス権限
のチェックを行っている。いずれにしても、アクセス制
御サーバ５０は、サーバ３から取得したＡＣＬ情報を用
いて、ユーザがＤＢサーバ５および業務サーバ６または
他企業ネットワークシステム９にアクセスする権限を持
つかどうかを確認するサーバである。また、鍵管理サー
バ１７は、企業ネットワークシステム１内での暗号化通
信で使用する通信当事者の鍵(秘密鍵と公開鍵の対)を生
成するサーバである。広域ネットワーク１０には、外部
証明書発行サーバ７が接続されている。この外部証明書
発行サーバ７は、所定の手順に従って外部証明書を発行
するサーバである。例えば、クライアントシステム８と
クライアントシステム２０が広域ネットワーク１０を介
して取引を行う場合には、証明証発行サーバ１８あるい
は外部証明証発行サーバ７のいずれかに証明証あるいは
外部証明証の発行を申請すればよい。

【００１１】なお、ディレクトリサーバ（図示省略：各
アプリケーションの存在場所を管理するサーバ）と呼ば
れるサーバを配置して、ここにサーバ３の情報を有して
いても良い。この場合、クライアント８および各種サー
バは、パソコン、ワークステーションを含む情報処理装
置である。さらに、クライアント８および各種サーバに
よって各々読み取り可能な記憶媒体上に実体化されたコ
ンピュータプログラムを実行して、以下に記述するクラ
イアント８および各種サーバの処理を行うことができ
る。例えば、アクセス制御ライブラリ５１は、クライア
ント８上のコンピュータプログラムであり、アクセス制
御サーバ５０や業務サーバ６などと通信することによ
り、ユーザのアクセス状況を監視する。また、セキュア
通信ライブラリ５２は、クライアント８上や各種サーバ
上のコンピュータプログラムであり、ネットワークシス
テム内の通信をセキュアに保護するために、通信当事者
の相互認証、通信データの暗号化と内容の保証を行う。
クライアント８または他企業ネットワークシステム９に
接続されるクライアント２０から証明証の情報を入力し
て、例えばＤＢサーバ５にログインすると、統合認証サ
ーバ２が証明証の確認を行うが、この証明証を用いた具
体的な認証処理シーケンスやシングルサインオンの実現
方法については、前述の先願発明Ａを参照すれば明らか
となる。

【００１２】図２（ａ）には、ユーザがクライアント８
からログイン後にセキュア通信ライブラリ５２、アクセ
ス制御ライブラリ５１、アクセス制御サーバ５０および
サーバ３間でやり取りする処理シーケンスが示されてい
る。ユーザ１１は、クライアント８の表示するユーザ認
証画面（１１ａ）にＩＣカード内の証明証３０の情報を
入力することにより（１１ｂ）、企業ネットワークシス
テム１にログインする。ユーザの認証処理については、
通信する双方のセキュア通信ライブラリ５２がＩＣカー
ド内のユーザ１１の証明証３０の情報を確認し、乱数情
報を送受信するチャレンジレスポンスシーケンスにより
相互を認証しあい、そのセションで利用する暗号鍵をネ
ゴシェーションする処理を行うが、本発明では詳細の説
明は省略する。具体的な認証シーケンスについては、先
願発明Ｂを参照することで明らかとなる。証明証３０の
情報を利用してセキュア通信ライブラリ５２の処理によ
りユーザ１１の正当性が認められた後は、クライアント
８上のアクセス制御ライブラリ５１が証明証３０の情報
を用いて、ユーザ１１のアクセス権限を確認する。図２
（ａ）に示すように、アクセス制御ライブラリ５２は、
アクセス制御サーバ５０に対して証明証３０の情報を送
信する（１１ｃ）。これにより、アクセス制御サーバ５
０は、証明証３０の情報を基にサーバ３に格納されてい
るユーザ１１のアクセス制御リスト(ＡＣＬ)７０を入手
要求する（１１ｄ，１１ｅ）。

【００１３】例えば、サーバ３がＬＤＡＰ(Lightweight
Data Access Protocol)に基づくディレクトリサーバで
ある場合には、アクセス制御サーバ５０はＬＤＡＰのプ
ロトコルに基づきサーバ３に情報の問合せを行う。ＬＤ
ＡＰのプロトコル処理の一例については、先願発明Ａを
参照すれば明らかとなる。そして、ＡＣＬ７０の内容を
確認することにより、アクセス制御サーバ５０は、ユー
ザ１１の企業ネットワークシステム１へのアクセス権限
が確認できる。具体的には、アクセス制御サーバ５０か
ら送信されてきたＡＣＬ７０の情報をもとに、クライア
ント８側のアクセス制御ライブラリ５１がユーザ１１向
けの初期選択画面を表示し（１１ｇ）、以降、ユーザ１
１への業務処理サービスを行う（１１ｈ）。なお、アク
セス制御サーバ５０とアクセス制御ライブラリ５１との
間の通信はセキュア通信ライブラリ５２の機能により保
護されているため、相互で正しく認証され、情報が盗ま
れたり改ざんされたりする心配はない。該セキュア通信
ライブラリ５２の処理内容については、先願発明Ａを参
照されたい。

【００１４】一方、図２（ｂ）では、クライアント８の
ユーザの業務要求がアクセス制御サーバ５０に転送され
た時に、アクセス制御サーバ５０で該ユーザの証明証の
確認結果からユーザの該業務サーバへのアクセス権限の
チェックを行っている。例えば、ＥＣ向けアプリケーシ
ョンのように、商品の購入時に初めて認証処理を行う時
等に相当する。クライアント８から業務要求を受けた時
に（１０ａ）、セキュア通信ライブラリ５２はユーザ認
証画面を表示し（１０ｂ）、ユーザはユーザ認証画面に
ＩＣカード内の証明証３０の情報を入力する（１０
ｃ）。証明証３０の情報を利用してセキュア通信ライブ
ラリ５２の処理によりユーザ１１の正当性が認められた
後は、クライアント８上のアクセス制御ライブラリ５１
が証明証３０の情報を用いて、ユーザ１１のアクセス権
限を確認する。図２（ｂ）に示すように、アクセス制御
ライブラリ５２は、アクセス制御サーバ５０に対して証
明証３０の情報を送信する（１０ｄ）。その結果、アク
セス制御サーバ５０は証明証３０の情報を基に、サーバ
３に格納されているユーザ１１のアクセス制御リスト
（ＡＣＬ）７０を入手要求する（１０ｅ）。そして、Ａ
ＣＬ７０の内容を確認することにより（ＡＣＬ７０
ｅ）、アクセス制御サーバ５０は、ユーザ１１の企業ネ
ットワークシステム１へのアクセス権限が確認できる。
具体的には、アクセス制御サーバ５０から送信されてき
たＡＣＬ７０の情報（ＡＣＬ７０ｆ）を基に、クライア
ント８側のアクセス制御ライブラリ５１がユーザ１１の
業務要求の許可あるいは拒絶を応答する（１０ｇ）。

【００１５】図３は、本発明に用いられるＡＣＬ形式の
情報例を示す図である。ＡＣＬには種々の形式が考えら
れるが、ユーザ情報の更新時に修正作業を最小限にする
ために、図３（ａ）に示すようにユーザ情報７１とユー
ザ権限情報７２、およびアクセス関連情報７３をツリー
構造の別データとして管理している。ユーザ情報７１に
は、図３（ｂ）に示すように企業内ネットワーク１内で
当ユーザを一意的に識別するために付与されているユー
ザ識別名称と証明証の情報の対応が管理されている。こ
のユーザ識別名称については、企業システムの名称ポリ
シーの規定に従う。また、図３（ｃ）に示すようにユー
ザに関するその他の情報(例えば住所、家族構成や入社
年度等の情報)も必要に応じて参照できるようになって
いる。ユーザ権限情報７２には、図３（ｄ）に示すよう
にユーザとユーザの権限の対応が管理されている。例え
ばユーザをＡ０，Ａ１，Ａ２，Ａ３という権限クラスで
分類してアクセスさせるようなシステムの場合は、事例
１に示すようにユーザごとに権限クラスを指定してお
く。また、このようなクラスの代りに、事例２（図３
（ｅ））に示すように所属や職位からなる職制情報を利
用してもよい。

【００１６】これらの権限クラスや職制情報に対応させ
て、どのような権限を許可するかを規定しておくのが、
図３（ｆ）に示すようなアクセス関連情報７３である。
アクセス関連情報７３には、企業ネットワークシステム
１内の全リソースに関するアクセス権限情報が定義され
ているので、例えば、図３（ｆ）に示すように、クラス
Ａ１のユーザ１１についての企業ネットワークシステム
１内のアクセス権限が、ＤＢサーバ５のファイル５０１
に対する参照と更新、ファイル５０２に対する参照が許
可され、業務サーバ６のＡＰ６０１の起動が許可されて
いることがわかる。また、接続形態の条件として、企業
ネットワーク内からのアクセスだけが許可されており、
リモートアクセスによる接続は許可されていないことが
わかる。このようにして、全てのユーザに対するアクセ
ス制御情報を一元管理するが、よりきめ細かなアクセス
制御、例えばファイル５０３のレコード５０３１（いず
れも図示省略）をユーザ１１だけに見せるというアクセ
スを制御したい場合には、ＤＢサーバ５内のアクセス制
御機能を利用することも可能である。職制変更時のユー
ザ情報変更作業を考えると、例えば、ユーザ１１の担当
業務が変更になった場合には、図３（ｅ）に示すユーザ
権限情報７２を変更すればよく、ユーザ１１のアカウン
トが削除される場合には、図３（ｂ）〜（ｅ）に示すユ
ーザ情報７１とユーザ権限情報７２からユーザ１１の項
目を削除すればよい。従来方式において、業務サーバ毎
にユーザのＡＣＬを管理していたシステム形態では、ユ
ーザ情報の修正が業務サーバ毎に必要であったことを考
えると、本発明では、ユーザ情報を一個所で変更できる
点に利点がある。

【００１７】図４は、本発明におけるアクセスチケット
を用いた制御手順を示すシーケンスチャートである。ア
クセス制御サーバ５０がアクセスチケット７５を用い
て、さらにきめ細かな運用を考慮したアクセス制御を行
う事例について説明する。図４に示すように、セキュア
通信ライブラリ５２はユーザ認証画面を表示し（１４
ａ）、ユーザはユーザ認証画面にＩＣカード内の証明証
３１の情報を入力する（１４ｂ）。証明証３１の情報を
利用してセキュア通信ライブラリ５２の処理によりユー
ザ１４の正当性が認められた後は、クライアント２０上
のアクセス制御ライブラリ５１が証明証３１の情報を用
いて、ユーザ１４のアクセス権限を確認する。次に、ア
クセス制御サーバ５０に対してユーザ１４のアクセス権
限の確認要求を行うと（１４ｃ）、アクセス制御サーバ
５０は業務サーバ６にＡＣＬを要求する（１４ｄ）。こ
のように、ユーザ１４がクライアント２０からネットワ
ークシステム１にログインする場合、アクセスチケット
７５ａの中に９時から１７時までという一時的な運用の
制約条件７６をつけることが可能である。この場合、ア
クセス制御サーバ５０は、クライアント２０側のアクセ
ス制御ライブラリ５１に、アクセス制御サーバＩＤ，ユ
ーザ１４のユーザ識別名、ユーザ１４のＡＣＬ,制約条
件７６、およびアクセス制御サーバ５０の署名情報から
構成されるアクセスチケット７５ａを作成し、アクセス
制御ライブラリ５１に送信する（７５ａ）。アクセス制
御サーバ５０とアクセス制御ライブラリ５１との間の通
信はセキュア通信ライブラリ５２の機能により保護され
ているため、相互で正しく認証され、情報が盗まれたり
改ざんされる心配はない。また、セキュア通信ライブラ
リ５１は、アクセスチケット７５ａの内容が確かにアク
セス制御サーバ５０によって作成されたものであること
を保証するために、署名情報を付加している。

【００１８】次に、図４において、アクセス制御ライブ
ラリ５１がアクセスチケット７５ａを受け取ると、クラ
イアント２０上のグループウェアアプリケーションはユ
ーザ１４に対して初期選択画面を表示する（１４ｅ）。
この初期選択画面は、ユーザ１４のＡＣＬに基づき作成
されるもので、ユーザ１４に権限に許されている業務だ
けが表示される。また、ユーザ１４が表示された以外の
業務のアプリケーションを起動するとユーザ１４に対し
て警告を発し、アクセス履歴情報報１２が取得される。
ユーザ１４が前記初期選択画面の中の業務の中から業務
サーバ６のＡＰ６０（図示省略）を起動した場合（１４
ｆ）、ユーザ１４によるＡＰ６０１（図示省略）の業務
要求は、アクセス制御ライブラリ５１から業務サーバ６
に転送されるが（７５ｄ）、その時に前記アクセスチケ
ット７５ａも添付される。業務サーバ６は、このアクセ
スチケット７５ａの内容を確認することにより、以降の
業務処理ＡＰ６０１を実行する。具体的には、ＡＣＬと
制約条件７６を考慮した処理を行うので、図４に示すＡ
ＣＬに許可された以外のＡＰ６０１の修正や業務ＡＰ６
０２の起動等は許さず、時刻が１７時を過ぎたならばユ
ーザ１４に対する処理を打ち切る。そして、業務サーバ
６は、ユーザ１４のアクセス状況についてはアクセス履
歴情報１２に記録しておく。

【００１９】業務が終了すると、業務サーバ６は、業務
サーバＩＤ，ユーザ１４のユーザ識別名、ユーザ１４に
よるアクセス履歴情報１２、および業務サーバ６の署名
情報から構成されるアクセスチケット７５ｂを作成し、
アクセス制御ライブラリ５１に送信する（７５ｂ）。な
お、業務サーバ６とアクセス制御ライブラリ５１との間
の通信はセキュア通信ライブラリ５２の機能により保護
されているため、相互で正しく認証され、情報が盗まれ
たり改ざんされたりする心配はない。アクセス制御ライ
ブラリ５１は、ユーザ１４に業務結果を出力するととも
に（１４ｇ）、業務サーバ６から受信したアクセスチケ
ット７５ｂのアクセス履歴情報１２を確認し、ユーザ１
４のアクセスに問題があるかどうかをチェックし、セキ
ュリティ上の問題を発見した場合には、セキュリティ侵
害情報１３とアクセス制御ライブラリ51の署名情報を作
成してアクセスチケット７５ｃに付加して送信すること
により（７５ｃ）、アクセス制御サーバ５０に報告す
る。また、図４の例では、制約条件７６をアクセス制御
サーバ５０が付加したが、例えば、ユーザのＩＣカード
の中にオペレーション情報を格納しておき、その情報を
図４のアクセス制御ライブラリ５１によるユーザ１４の
アクセス権限の確認要求の時にアクセス制御サーバ５０
に送るような実装も可能である。

【００２０】

【発明の効果】以上述べたように、本発明によれば、業
務サーバ、ＤＢサーバ、あるいはグループウェアサーバ
等が従来のＡＣＬで行っていたアクセス制御処理を、ア
クセス制御サーバにより一元管理できるので、企業内ネ
ットワークシステムを一個所から集中管理することが可
能である。また、アクセスチケットを利用することによ
り、ネットワークシステム利用の一時的制約やユーザの
アクセス状況を把握できるので、より柔軟なネットワー
ク運用が可能となる。さらに、前記アクセスチケットの
情報は、クライアント、業務サーバ、アクセス制御サー
バの間でセキュアに送受信されるため、悪意のある第三
者が盗聴して悪用することは不可能となる。

【図面の簡単な説明】

【図１】本発明が適用されるネットワークシステムの構
成図である。

【図２】本発明におけるＡＣＬ問い合わせ手順および業
務要求手順の各シーケンスチャートである。

【図３】本発明で用いられるＡＣＬ形式の情報例を示す
図である。

【図４】本発明におけるアクセスチケットを用いた制御
手順のシーケンスチャートである。

【符号の説明】

１…企業ネットワークシステム、２…統合認証サーバ、
３…セキュリティ情報を管理するサーバ、４…グループ
ウェアサーバ、５…ＤＢサーバ、６…業務サーバ、７…
外部証明証発行サーバ、８，２０…クライアントシステ
ム、９…他企業のネットワークシステム、１０…広域ネ
ットワークシステム、１１，１４…ユーザ、１２…アク
セス履歴情報、１３…セキュリティ侵害情報、１７…鍵
管理サーバ、１８…証明証発行サーバ、３０，３１…証
明証、７０…ＡＣＬ（アクセス制御リスト）、７５…ア
クセスチケット、７６…制約条件、５１…アクセス制御
ライブラリ、５２…セキュア通信ライブラリ、７１…ユ
ーザ情報、７２…ユーザ権限情報、７３…アクセス関連
情報、５０…アクセス制御サーバ、Ａ０〜Ａ３…権限ク
ラス。

Claims (3)

【特許請求の範囲】
1. 【請求項１】 ユーザが共有するクライアント端末,該
   クライアントからアクセスされ、業務処理のために利用
   される業務サーバ、および該ユーザが各サーバにアクセ
   スする権限を有するか否かを確認するアクセス制御サー
   バが、相互に通信可能なネットワークシステムでのアク
   セス制御方法において、 ユーザを認証した後、あるいは該ユーザが共有するクラ
   イアント端末から該アクセス制御サーバに対して該ユー
   ザの業務要求が転送された時に、 該アクセス制御サーバが、該ユーザの証明証の確認結果
   から該ユーザの業務サーバへのアクセス権限をチェック
   するステップと、 該アクセス制御サーバは、該アクセス権限が正当であれ
   ば該業務サーバへのユーザの業務要求を許可するステッ
   プとを有することを特徴とするネットワークでのアクセ
   ス制御方法。
2. 【請求項２】 ユーザが共有するクライアント端末にア
   クセス制御ライブラリを設け、ユーザが各サーバにアク
   セスする権限を有するか否かを確認するアクセス制御サ
   ーバのＩＤ，該ユーザのＩＤ，アクセス制御リスト、運
   用の制約条件、該アクセス制御サーバの署名情報等から
   構成されるアクセスチケット情報を利用して、ユーザの
   アクセス権限のチェックを行うネットワークシステムで
   のアクセス制御方法において、 該アクセス制御サーバで、前記アクセスチケット情報を
   作成し、該アクセスチケット情報を該アクセス制御ライ
   ブラリに送信するステップと、 該アクセス制御ライブラリで、該アクセスチケット情報
   を用いて該ユーザの業務サーバへのアクセス権限チェッ
   クを行い、該業務サーバへのアクセス要求が適切であっ
   た場合には、該業務サーバに該ユーザの業務要求と該ア
   クセスチケット情報を転送するステップと、 該業務サーバで、該ユーザによるデータへのアクセス権
   限のチェック結果を含むアクセス履歴情報を作成し、該
   ユーザによるアクセスの終了時に、業務結果と前記アク
   セス履歴情報を付加したアクセスチケット情報を該アク
   セス制御ライブラリに送信するステップと、 該アクセス制御ライブラリで、該アクセスチケット情報
   の内容を確認し、該ユーザのアクセス状況をチェック
   し、該アクセス状況に問題があった場合には、セキュリ
   ティ侵害情報を作成して、該セキュリティ侵害情報を付
   加したアクセスチケット情報を該アクセス制御サーバに
   送信するステップとを有することを特徴とするネットワ
   ークシステムでのアクセス制御方法。
3. 【請求項３】 請求項１または２に記載のネットワーク
   システムでのアクセス制御方法において、 前記アクセス制御サーバ、クライアント端末のアクセス
   制御ライブラリ、及び業務サーバとの間でアクセスチケ
   ット情報を送受信する際に、通信の当事者以外には該ア
   クセスチケット情報の内容を見せないよう保証すること
   を特徴とするネットワークシステムでのアクセス制御方
   法。