ネットワーク・アクセスを制御するシステムおよび方法
【課題】製品へのネットワーク・アクセスを制御するシステムを提供すること。
【解決手段】システムは、第１の事業体の業務管理下で、製品に接続されるセキュリティ機器と、第２の事業体の業務管理下の、ユーザ端末によりアクセスされる製品接続プラットフォームおよびユーザ端末と、前記第１の事業体と前記第２の事業体の間で予め定められた判定基準に基づいて、前記第１の事業体と前記第２の事業体の間に確立された信頼関係であって、証明書または公的／私的鍵の交換により表される信頼関係とを含む。前記第２の事業体のユーザ端末のユーザによる、前記第１の事業体の前記製品へのアクセスの認証が、前記信頼関係の前記予め定められた判定基準に基づいて、前記第２の事業体の前記製品接続プラットフォームの判断にゆだねられ、認証が得られた場合に、前記ユーザが前記製品へのアクセスを提供される。
【解決手段】システムは、第１の事業体の業務管理下で、製品に接続されるセキュリティ機器と、第２の事業体の業務管理下の、ユーザ端末によりアクセスされる製品接続プラットフォームおよびユーザ端末と、前記第１の事業体と前記第２の事業体の間で予め定められた判定基準に基づいて、前記第１の事業体と前記第２の事業体の間に確立された信頼関係であって、証明書または公的／私的鍵の交換により表される信頼関係とを含む。前記第２の事業体のユーザ端末のユーザによる、前記第１の事業体の前記製品へのアクセスの認証が、前記信頼関係の前記予め定められた判定基準に基づいて、前記第２の事業体の前記製品接続プラットフォームの判断にゆだねられ、認証が得られた場合に、前記ユーザが前記製品へのアクセスを提供される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク・アクセスを制御するシステムおよび方法に関する。
【背景技術】
【０００２】
近年、様々な規模の公的機関や私企業が、遠距離通信システム、情報システムおよび日常のビジネス業務用の作業インフラストラクチャとして機能するその他の製品の大規模アレイを、ますます備えてきている。
【０００３】
しかしながらそれらの製品、システムおよびサービスのプロバイダは、彼らの顧客のシステムおよび装置の試験を行い、アップグレードし、かつ維持するために、アクセスと認証図式の統合に関する課題を抱えてきた。特にこれらのプロバイダおよびサービス会社は、彼らの顧客により用いられる多数のリモート・アクセスの要求と異なるリモート・アクセスおよび権限委任パッケージに応じることは困難であることが判ってきた。さらに、顧客の拡張されたユーザ・ベースにより用いられる、製品やシステムへのリモート・アクセスを必要とする、全ての第三者機関の技術者、ビジネス・パートナーおよびアウト・ソースを管理することは、コストと資源に関わる課題である。
【０００４】
企業の顧客は一般的に、確認し、制御し、ユーザにログするための、彼らのサイトに配置された認証／権限委任／管理（ＡＡＡ）サーバを有する。
ＡＡＡサーバは、
・認証：ユーザの特定および認識の処理、
・権限委任：あるユーザができることの決定、
・管理：あるユーザがしていることおよびしてきたことの記録動作、
を提供する。
【０００５】
図１は、代表的な顧客ネットワーク環境での、従来の認証／権限委任／管理（ＡＡＡ）サーバ５０を示す。図１はまた、顧客ＶＰＮゲートウェイ５１および製品５２、５３（例えば、ＰＢＸ）を示す。
【０００６】
サービス・プロバイダ技術者によるアクセスは、インターネットを経由してアクセス装置４０により実行される。従来、ユーザの認証を要求する顧客は、サービス・プロバイダの技術者に、彼らの仮想プライベート・ネットワーク（ＶＰＮ）クライアント（図示せず）および保証ＩＤのような彼らのハード・トークンの使用を要求する。数人のサービス技術者しか有さないサービス・プロバイダにとって、これは実行可能なオプションである。しかしながら、数百または数千の技術者を有するプロバイダにとっては、これは殆ど不可能である。
【０００７】
・各々のサービス技術者は、全ての顧客のＶＰＮクライアントを彼らのＰＣ上にインストールする必要がある。ＶＰＮクライアントは一般的にＰＣのＴＣＰＩＰスタックを変更するので、サービス・プロバイダのＰＣはもはや適切には機能しない。
【０００８】
・各々のサービス技術者は、全てのサービスを受けている顧客の数百またはできうれば数千のハード・トークンを管理する必要がある。これは、プロバイダと顧客の双方にとって管理不能になる。顧客がこの可能性について尋ねられると、彼らはよりよい解決法が必要であることに同意する。
【０００９】
・認証の前に、サービス・プロバイダが障害チケットまたは作業チケットを公表するように、との要望はない。
【００１０】
ＲＳＡセキュリティ社およびイオンネットワーク社のような、ハードおよびソフトのトークン・ベースのリモート・アクセス制御の解決法を提供する、多数の会社がある。この解決法は、彼ら自身の装置にアクセスする単一の会社に関しては、うまく動作する。外注のまたは第三者の保守の局面においては、これは、顧客のアクセス制御システムに設定され、個々のハードまたはソフトのトークンを割り当てられた、全てが第三者の技術者であることを含む、完全な拡張された技術者の力を必要とする。外部の保守会社にとって、各々の顧客に対する各々の技術者用のハード・トークン装置と連絡を絶やさないとの要望は、コストと保守の重大な問題である。
【００１１】
パーメオ技術社（Ｐｅｒｍｅｏ Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．）のような会社は、認証とリモート・アクセス制御の解決法の装置に、ターンキィ・デスクトップを提案する。この解決法は、彼ら自身の装置をアクセスする単一の会社については、うまく動作する。これは、全てのリモート・ユーザが全く同じソフトウェアのセットを購入して用いることと、顧客のアクセス制御システムに設定された、全てが第三者の技術者であることを含む、完全に拡張された技術者の力を必要とする。全ての顧客が選択したターンキィの解決法に必要とされる、全ての種々の構成およびソフトウェアを個々の技術者に提供することは実現可能でないので、これは第三者管理会社とコストにとっては重荷である。
【００１２】
リバティ・アライアンスおよびセキュリティ・アサーション・マークアップ（ダッシュ抜き）言語（ＳＡＭＬ）機関は、ウェブ・ベースのビジネス作業用の、信用ベースの身元確認および認証交換標準を開発中である。この標準化の努力は、ウェブ・ベースのビジネス取引およびその用途に、完全に焦点を当てている。リモート・メンテナンス監視およびサポートのためのプロトコルおよびそのアクセス要求は、アプリケーションへのウェブ・ベースのアクセスを遙かに超えている。
【００１３】
ソックス（ＳＯＣＫＳ）インターネット・コメント要請（ＲＦＣ１９２８、３０８９、１９２９）は、プロキシ・サービスを用いるネットワーク装置へのアクセスを確立する、プロトコルを提供する。プロキシ・サービスは、プロキシの背後の装置に対し、アクセスと権限委任制御を実施することができる。現在の標準は、クライアントのアプリケーションとプロキシの協定に基づいて、追加の権限委任モデルが設定されることを可能にするために、一般セキュリティ・サービス・アプリケーション・プログラミング・インターフェイス（ＧＳＳＡＰＩ）へのサポートと同様に、ユーザＩＤおよびパスワード・ベースの権限委任制御の使用をカバーする。
【００１４】
これらについてのさらなる情報は、以下に記載されている：
・ネットグリティ役割管理：
ｈｔｔｐ：／／ｗｗｗ．ｎｅｔｅｇｒｉｔｙ．ｃｏｍ／ｎｅｗｓ／ｗｅｂｓｅｍｉｎａｒａｒｃｈｉｖｅ／ｒｏｌｅｓａｒｃｈｉｖｅ．ｈｔｍｌ
・パーメオ社（Ｐｅｒｍｅｏ Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．）外向けアクセス：ｈｔｔｐ：／／ｗｗｗ．ｐｅｒｍｅｏ．ｃｏｍ／ｏｕｔｂｏｕｎｄａｃｃｅｓｓ．ｈｔｍ
・イオン・ネットワーク・セキュア・リモート・アクセス：ｈｔｔｐ：／／ｗｗｗ．ｉｏｎ−ｎｅｔｗｏｒｋｓ．ｃｏｍ／ｐｒｉｉｓｍｓ．ｓｈｔｍｌ
上記の問題が与えられた時に前進するために必要なものは、三つのＡＡＡ機能を分離して、認証はサービス・プロバイダのサイトで、ユーザの身元確認とそれに関連する役割はアクセスが要求された時に顧客のサイトにパスする手段である。認証と管理は、その後顧客のサイトで実行される。
【発明の開示】
【発明が解決しようとする課題】
【００１５】
本発明は、主たる目的として、背景技術のシステムおよびアプローチを改良すること、および背景技術のシステムに関連する欠点を解決することを有する。
【００１６】
ここに提案される解決法は、二つの会社の間の外用の信頼関係に基づく、認証モデルを含むためのＳＯＣＫＳトンネリングの概念を拡張することである。この信頼関係は、証明書を用いて実装される。
【００１７】
ＳＯＣＫＳトンネリングは、ＳＯＣＫＳクライアント・アプリケーションの代わりに、あるＳＯＣＫＳサーバがある装置へのプロキシ接続を確立するために、他のＳＯＣＫＳサーバに接触することである。ＳＯＣＫＳトンネリングに対しては、現在のところインターネット標準は存在しない。
【００１８】
権限委任モデルは、会社Ａがそれ自身の従業員を認証するために会社Ｂを信用するような、二つの会社の間の予め確立された信頼関係に基づいている。会社Ａは、会社Ｂから隔てられたリモート・ユーザを認証することを企図していない。その代わりに会社Ａは、会社Ｂの従業員によりなされた任意のリモート・アクセス要求を権限委任する。この権限委任は、そのリモート・アクセス要求の一部として安全なチャネルを通して送信された、身元情報のセットに基づいている。
【００１９】
作業においては二つの会社は、それらの会社の身元を表す、証明書または公的／私的鍵の組を最初に交換する。証明書は、リモート・アクセス要求がなされた場合に、各々の会社の身元を確立するために用いられる。それはまた、その要求を作成したリモート・ユーザの身元を交換するために、安全な通信機構を確立するためにも用いられる。
【００２０】
本発明の他の目的およびさらなる適用範囲は、以下に与えられる詳細な説明から明らかになるであろう。しかしながら、本発明の望ましい実施形態を示す一方で、詳細な説明および特定の実施例は一例としてのみ与えられるので、この詳細な説明から本発明の精神と範囲内の種々の変形および修正が当業者には自明であることが、理解されなければならない。
【００２１】
本発明は、以下に示される詳細な記述と、一例としてのみ添付された本発明の限定ではない図面により、さらに完全に理解されるであろう。
【課題を解決するための手段】
【００２２】
本発明は、従来のシステムおよびアプローチとは全く異なる、権限委任モデルを提供する。
この権限委任モデルは、会社Ａ（例えば顧客）が会社Ｂ（例えばサービス・プロバイダ）に、会社Ｂのシステムが全ての関係する従業員の身元証明を会社Ａに送った後にのみ、会社Ａの装置の一つにアクセスする権限を会社Ａが委任するようにされた、二つの会社の間の予め確立された信頼関係に基づいている。
【００２３】
顧客Ａは、図２に示される工程を実装することにより、二つの会社の間の信頼関係を最初に確立する。当該二つの会社の間に信頼関係が一度確立されると、会社Ｂによるリモート・アクセスができるようになる。
【発明を実施するための最良の形態】
【００２４】
図３（ａ）に示されるように会社Ａの環境は、ＳＯＣＫＳサーバ５、ポリシー・サーバ６および製品アクセス監査証跡装置７からなる、ローカル・ゲートウェイＳＳＧ１０を含む。製品８（例えばＰＢＸ）は、ローカル・ゲートウェイＳＳＧ１０に接続されている。
【００２５】
会社Ｂのシステムは、ＳＯＣＫＳサーバ４、ＡＡＡシステム２および障害チケット・システム１を備える、製品接続システム３を含む。
作業において二つの会社は、各々の会社の身元を表す、証明書または公的鍵／私的鍵の組を最初に取り交わす。証明書は、到来する要請が信頼されるシステムに由来することを確証するために用いられる。この取り交わしは、図３（ａ）に示される会社ＡとＢの環境について、また図３（ｂ）に示されるメッセージのシーケンスについて図示される。再確認すると、会社Ａは音声ＰＢＸスイッチのような、リモートでサービス可能なある製品のユーザであり、会社Ｂはこのシステムのサービス・プロバイダである。ローカルな認証データ・ベースに対し個々のリモート・ユーザの身元をチェックする代わりに、到来する接続が既知で信頼されるシステムに由来することを確証するために、ローカル・ゲートウェイＳＳＧ１０は会社の証明書または保証書をチェックする。個々のユーザの情報は、ローカル・ゲートウェイＳＳＧ１０により検査できる暗号化されたパケットの一部として送信され、個々のユーザの身元と他の関連する情報はＳＳＧ１０により記録される。
【００２６】
ここで図３（ｂ）を参照すると、会社Ｂの技術者（ユーザ）が会社Ａのネットワーク上の製品８に接続しようと企てる場合、以下の工程が発生する。
工程１：会社Ｂの技術者は、端末４０を経由して障害チケット・システム１にログインする。
工程２：技術者は、会社ＢのＡＡＡサービス２により認証される。
工程３：技術者は、障害チケット・システム１からサービスするチケットを選択する。
工程４：会社Ｂの技術者は、チケット内で参照される製品８への接続を要求する。
工程５：障害チケット・システム１は、製品接続システム３をコールし、接続を要求する。
工程６：製品接続システム３は、その技術者が当該の接続を許可されるべき適宜の権限委任を有するかどうかを決定するために、会社ＢのＡＡＡシステム（２）にコンタクトする。
工程７：権限委任が許可されたと仮定すると、製品接続システム３は会社ＢのＳＯＣＫＳサーバ４にコンタクトし、会社Ａのリモート製品８への接続を要求する。技術者の身元と障害チケット番号が、製品８の特定情報と共にＳＯＣＫＳサーバ４に送信される。
工程８：会社ＢのＳＯＣＫＳサーバ４は、ローカル・ゲートウェイＳＳＧ１０内で稼働中の、会社ＡのＳＯＣＫＳサーバ５との安全な接続を生成し、会社Ｂの保証書、技術者の身元、アクセスされる製品および作業される障害チケットを含む全ての関連する情報を包含する、権限委任要求ドキュメント９を送信する。
工程９：会社ＡのＳＯＣＫＳサーバ５は、会社Ｂの任意の身元を有効にするために供給される保証書を有効にする。
工程１０：会社ＡのＳＯＣＫＳサーバ５は、処理のためにこれまたローカル・ゲートウェイＳＳＧ１０で稼働中の、ポリシー・サーバ６にアクセス要求ドキュメントを送信する。
工程１１：ポリシー・サーバ６は、顧客が定義した任意のアクセス規則を、アクセス要求ドキュメント９の名前（ｎａｍｅ？）で供給される情報に適用する。ポリシー・サーバ６は、特定の顧客の従業員による現場でのリアルタイムの権限委任を必要とする、特定の装置へのアクセスを指定する。ローカル・ゲートウェイＳＳＧ１０は次に、その製品にアクセスするための権限委任を承認するために、これらの特定の顧客の従業員を通知する、顧客のインスタント・メッセージ・サーバ１１にアクセスする。ＳＳＧ１０は、リアルタイムの権限委任のために、顧客の従業員に特定のアクセス属性（故障チケット番号、製品の説明書、会社および従業員がアクセスする製品）を表す。一人またはそれ以上の顧客の従業員は、アクセスを「許可」または「拒否」することができる。顧客の従業員の誰かが、顧客が指定した時間内に「拒否」と言った場合は、アクセスは拒否される。拒否の理由は、顧客のインスタント・メッセージ・クライアントを用いて提供されることができる。顧客の従業員全員が「許可」と言った場合には、アクセスは許可される。所望のアクセス・ポリシーを提供するために、他のセキュリティ・パラメータがプログラムされてもよい。
【００２７】
本発明は以上に記述したような、リアルタイム警報のインスタント・メッセージの型式に限定されない。リアルタイムの権限委任への代替案の解決法は、標準の番号パッドを備えるディスプレイ電話１４を用いて顧客と交信する、ＳＩＰ（セッション起動プロトコル）サーバ１３（図３（ａ）に示される）を用いる。ここでＳＳＧのポリシー・サーバ６は、例えばサービス・プロバイダの技術者名、故障チケット情報および／またはアクセスを要求する装置を表すために、顧客のディスプレイ電話１４をコールし、次にアクセス情報を送る。顧客は、許可のために「１」を、拒否のために「２」を押す。ＳＳＧ１０は管理する装置毎に、顧客がプログラムしたアクセス・ポリシーを記憶している。
【００２８】
供給元のアクセスを許可するために顧客が用いる装置は、電話またはインスタント・メッセージ・サービスに限定されない。電話のような無線装置、パーソナル・デジタル・アシスタンツ、ブラック・ベリー（ｈｔｔｐ：／／ｗｗｗ．ｂｌａｃｋｂｅｒｒｙ．ｃｏｍ）装置、任意のローカルまたはリモート通信クライアントが、本発明に含まれる。
【００２９】
工程１２：ＳＯＣＫＳサーバ５は、ＳＳＧ１０に配置された会社Ａの監査ログ７に、全ての情報を記録する。
工程１３：権限委任が許可されたと仮定すると、ＳＯＣＫＳサーバ５は製品８への接続を公開する。その後制御は、技術者に戻される。ＳＯＣＫＳサーバ５は、ローカル装置にアドレスするために必要な、ネットワーク・アドレス変換を実行する。
【００３０】
認証機能と処理
認証機能は、顧客のサイトとはリモートに配置された、サービス・プロバイダのサービス配送プラットフォームと、顧客の構内またはその近くに配置された、ローカル・ゲートウェイ／セキュリティ機器ＳＳＧの、二つの個別のプラットフォームの相互作用により提供される。ＳＳＧは、サービス・プロバイダではなく、顧客により制御され、監視される。
【００３１】
サービス・プロバイダは、サービス技術者の顧客のサイトへの任意のアクセスが許可される前に、サービス技術者が認証されることを保証しなければならない。この認証処理は、また各々の個々の技術者にサービスする「役割」を割り当てる。ある役割は、顧客の装置またはシステムの特定の一部に、サービスを提供するための個々のサービス技術者の「免許」と考えられることができる。
【００３２】
例えば生成された障害チケットの結果としてアクセスが必要になると、最初にアクセス要求が顧客とは隔たったセキュリティ機器（ＳＳＧ）と交渉される。
アクセス要求は、以下のような属性を含む。
・サービス会社名
・技術者名、役割、アドレス
・技術者の管理者名、アドレスおよび電話番号
・アクセスされる製品
・障害チケット番号
・要求された現場での承認
・それらのネットワークに、サービス・プロバイダへのアクセス許可を与えた現場の担当の、電話番号、インスタント・メッセージ名またはＩＰアドレス
【００３３】
・サービス・プロバイダの社内処理ＩＤ
ＳＳＧは顧客により、特定の役割を有する技術者が彼らの装置およびネットワークにアクセスできるようにされている。サービス技術者によるアクセス要求は、ＳＳＧに安全に送られ、ＳＳＧ内に記憶されたアクセス・ポリシーと比較される。役割が適合すると、ユーザの身元およびアクセス要求内のその他全ての情報がＳＳＧの監査ログに記憶される。アクセス要求はまた、ネットワーク・マネジメント・システム、またはそれらにリアルタイムのアクセス通知を与えるシスログ・サーバに、ＳＳＧにより送信されることができる。以上に記述したように、アクセスはユーザの身元ではなく役割に対して与えられるが、ユーザの身元も説明責任のために同様に記録される。
【００３４】
認証機能および処理はまた、顧客が身元パケット内の他の情報について規則を構築できるようにしてもよい。例えば、特定のサービス技術者（または他のユーザ）が彼らのネットワークにアクセスできないようにする、顧客が「名前による拒否」ができる規則を作ることができる。これは、特定のサービス技術者またはユーザについての、顧客の過去の経験の結果であってもよい。この機能を提供するためには、サービス会社ＢはＳＳＧに全ての彼らの技術者名を送信する必要はない。むしろＳＳＧは、製品へのアクセスの通常処理中に、身元パケットで通過した名前を記憶する。この自動的な名前リストの作成は、除外リストの基礎となる。ＳＳＧ監査ログを裁判解析に用いて、顧客は除外すべき人物を決定する。顧客は次に、その名前を除外リストにコピーする。その人物が次にどんな製品にアクセスしようとしても、ＳＳＧはその人物によるどんな製品へのアクセスも拒否する。ＳＳＧはまた、拒否の理由を記述したＳＯＣＫＳ接続要求内の拒否メッセージを、会社ＢのＳＯＣＫＳサーバに返送する。
【００３５】
このようにして、認証機能は顧客が定義した権限委任チェックを許可する。
さらに認証機能は、「要求された現場での承認」権限委任モデルを可能にすることができる。例えばある顧客は、彼らのサイトに接続するのに先だって、サービス・プロバイダがリアルタイムのアクセス許可を得ることを必要とするかもしれない。このエントリは、顧客のサイトのＳＳＧにパスされる。ＳＳＧセキュリティ・ポリシーは、外部の通知サービス（以前に記述）を経由して、その技術者（名前による）がその製品にアクセスすることを許可するのに先立って、顧客の権限委任を求めるインスタント・メッセージ、ビーパまたはＥメールのようなメッセージを送信する。ＳＳＧは、顧客がそのアクセスを許可するか否か決定することができるように、サポートするアクセス情報を提供する。顧客の代理人がＳＳＧに承認を一度与えると、そのサービス技術者によるアクセスが許可される。ＳＳＧは後刻の顧客の監査のために、全ての許可および拒否されたアクセス要求を記録する。これは、あるベンダによりなされたアクセスが結果として、他の顧客のサーバにサービス停止やセキュリティ攻撃を起こした場合に重要である。この記録は、それを引き起こしたベンダ、技術者またはベンダの自動化ツールを指定することを助ける。
【００３６】
権限委任機能と処理
権限委任は、ユーザのアクセスが割り当てられたリソースにのみであることを保証する処理である。これは、通常、認証段階の後で行われる。
【００３７】
最初に、ＶＰＮクライアントについての簡潔な記述が提供される。ＶＰＮ接続処理では、あるネットワークまたはＩＰアドレスにのみアクセスするように、ＶＰＮクライアントが顧客のＶＰＮサーバによりリモートで作成される。リモートＰＣのＩＰパラメーターが、リモートネットワーク上のリソースにアクセスして使用するために、変更される。全ての実際的な目的のために、リモートＰＣはそのＰＣのローカルＬＡＮ上のリソースにはアクセスできない。そのＰＣは、論理的には顧客のネットワーク上に存在する。
【００３８】
ＬＡＮ接続へのＶＰＮクライアントの代わりにＬＡＮ−ＬＡＮ接続が用いられた場合、二つの異なるＩＰネットワークへの橋渡しのために、ネットワーク・アドレス変換（ＮＡＴ）が必要になるのでこれは重要である。顧客のＡＡＡサーバが許可された本当のＩＰアドレスを含む場合、アクセスがなされる前に、ＳＳＧはＡＡＡサーバからそれらを回収し、次にそれらをサービス・プロバイダの内部アドレスにマップする必要がある。
この処理を簡便化するために、ＳＳＧはネットワーク・アドレス変換（ＮＡＴ）と権限委任および管理機能の双方を実行する。
【００３９】
管理機能および処理
管理は、全ての認証および権限委任工程が完了した後に、ＳＳＧ内で実行される。
その顧客が管理に用いられる外部ＡＡＡサーバ（例えば、ポート１８１３を用いる、リモート認証ダイヤル・イン・ユーザ・サーバ（ＲＡＤＩＵＳ）システム）を有する場合は、ＳＳＧは顧客のサーバにアクセス要求／結果を記録することができる。これは、一つのサーバ内の全てのアクセス要求の監査を可能にする。
【００４０】
自動化リモート・アクセス・システム
以上に記述された処理は、サービス技術者により起動される。代替案としてシステムは、一般的に診断コンピュータにより起動される、自動化リモート・アクセスを提供するために用いられてもよい。
【００４１】
自動化システム・リモート・アクセスの際のメッセージ・フローは、以下の例外を除き、リモート技術者によるアクセスと同様である。会社Ｂの各々の自動化システムはそれ自身の固有の身元を有し、この身元はサービス・プロバイダのシステムにより確証され、次に顧客のシステムに提供される。ＳＳＧに送信された身元は技術者のそれではなく、診断コンピュータのそれなので、これは非常に重要である。障害チケット・システム１にアクセスする代わりに、自動化システム・リモート・アクセス・アプリケーションは、適切なチケット情報を供給する製品接続システム３に直接アクセスする。
【００４２】
ローカル技術者によるアクセス
ローカル技術者によるアクセスの際の、システムの構成要素の間のメッセージ・フローは、図４（ａ）の矢印により示されている。図４（ｂ）は、リモート技術者のアクセスの際の、工程のフロー・チャートを提供する。
【００４３】
会社Ｂの技術者によるローカル・アクセスの事前要件は、その技術者のＰＣがＳＯＣＫＳ化されていなければならないことである。ＳＯＣＫＳソフトウェアは、会社ＡのＳＳＧ１により管理されている製品への全てのトラヒックを、ＳＯＣＫＳサーバ２にリダイレクトするようにされていなければならない。ＳＯＣＫＳ化されたクライアントとＳＯＣＫＳサーバの間のプロトコルは、ＳＳＧへの安全なローカル・アクセスを維持するために、ＳＳＬを用いて暗号化されている
関連する工程は、以下を含んでいる：
工程１：ローカル技術者が、ローカルＳＳＧ１上で稼働中のＳＯＣＫＳサーバ２に接続する。
工程２：ＳＯＣＫＳサーバ２は、顧客のＡＡＡサーバ４に対して技術者の情報を認証する。
工程３：技術者は、ローカル・ネットワーク・アドレスを用いて製品５への接続を生成しようとする。
工程４：ＳＯＣＫＳサーバ２は、製品５にアクセスするための権限委任を求めて顧客のＡＡＡサーバ４をチェックする。
工程５：ＳＯＣＫＳサーバ２は、ＳＳＧ１のローカル監査ログ３内の接続要求を記録する。
工程６：ＳＯＣＫＳサーバ２は、製品５への接続を開放し、会社Ａのローカル技術者に制御を戻す。
【００４４】
以上に記述した本発明は、従来技術の審判アプローチの問題への、安全で統合された解決法を提供する。この解決法の利点は、以下を含む：
サービス・プロバイダが、顧客のアクセス制御システムに全ての第三者の技術者の身元を維持することは、もはや不必要である。
各々の第三者の保守、監視または支援ベンダのそれぞれが、各々の全ての顧客が彼らの装置にアクセスするために要求する、ソフトウェアまたはハード・トークンを有することは不必要である。
【００４５】
安全、監査手続および立法を充足するために必要な情報は、サービス会社とその装置を用いる顧客の双方により安全な方法で維持される。
【００４６】
サービス・プロバイダまたは顧客のどちらかによる甚大な作業を必要とすることなく、非常に個別的なアクセス制御規則の構築が可能となる。交換される身元情報は、リモートの保守、監視または支援の顧客が彼ら自身の装置にアクセスするための個別的で詳細なアクセス制御記録を、サービス・プロバイダに重荷を負わすことなく構築できるようにするのに充分である。
【００４７】
他の固有の利点は、以下を含む：
・権限委任はサービス・プロバイダのサイトではなく、むしろ顧客のサイトで起こる。
・顧客のサイトへのＩＰアクセスを可能にする、障害／作業チケットが最初に生成されなければならない。サービス・プロバイダのサイトに配置されたＳＳＧは、顧客のサイトへの直接のＩＰアクセスを妨げる。要求された情報が提供されない場合、アクセスは拒否される。これは、サービス・プロバイダの身元、サービス・プロバイダの技術者の身元および作業される障害チケットを含む。技術者の会社、技術者の身元（または自動化エキスパート・システムの身元）、役割、チケット番号および／または製品ＩＰアドレスおよび「要求された現場での承認」が、権限委任要求ドキュメントを用いて、現場のゲートウェイＳＳＧに安全に送信される。
・顧客は現場でのアクセス制御を保持し、その制御のためにサービス・プロバイダを信用する必要がない。
・顧客は：
ｉ．アクセスが許可された時間
ｉｉ．彼らの製品にアクセスする、許可された技術者の役割
ｉｉｉ．アクセスが許可された製品
ｉｖ．彼らの製品へのアクセスが許可されなかった人物（おそらく過去の経験から）および
ｖ．「要求された現場での承認」を与えることを許可された人物
など、所望のアクセス制御規則を有するオンサイト・ゲートウェイを予めプログラムする能力を有する。
・この解決法はまた、取引を記録する場所として、顧客のＡＡＡデータ・ベースとの統合を可能にする。認証は、サービス・プロバイダのＡＡＡシステムにより実行される。権限委任は、現場のゲートウェイ（ＳＳＧ）により実行される。管理（記録）は、ＳＳＧまたは顧客のＡＡＡサーバにより、オプションとして実行される。
・顧客の技術者は、ＳＳＧを通してローカルの製品に接続するために、標準ＳＯＣＫＳクライアントを用いることができる。ＳＳＧは、製品にアクセスするための単一のゲートウェイになる。
・この解決法は、顧客が現有するＢ２Ｂ接続を用いることができる。それは、サービス・プロバイダに個別のＶＰＮ／フレーム・リレー接続を必要とさせない。
【００４８】
本発明は以上のように記述されたが、これが多様な方法で変形されることが自明であろう。そのような変形は本発明の精神と範囲から逸脱していると見なしてはならず、当業者に自明な全てのそのような変形が、添付の請求項の範囲内に含まれることが企図されている。
【図面の簡単な説明】
【００４９】
【図１】顧客のネットワーク環境の代表例としての、従来技術の認証／権限委任／管理（ＡＡＡ）サーバを示す図である。
【図２】二つの会社の間の信頼関係の確立に際して起こる、マニュアルの工程のフロー・チャートである。
【図３（ａ）】顧客のネットワーク環境の代表例としての、本発明の認証／権限委任／管理（ＡＡＡ）システムを示す図である。
【図３（ｂ）】本発明の主たる利用に関わる工程を強調した、シーケンス図である。
【図４（ａ）】顧客サイトにいる、サービス技術者用の処理を示す図である。
【図４（ｂ）】本発明の変形に関わる工程を強調した、シーケンス図である。
【技術分野】
【０００１】
本発明は、ネットワーク・アクセスを制御するシステムおよび方法に関する。
【背景技術】
【０００２】
近年、様々な規模の公的機関や私企業が、遠距離通信システム、情報システムおよび日常のビジネス業務用の作業インフラストラクチャとして機能するその他の製品の大規模アレイを、ますます備えてきている。
【０００３】
しかしながらそれらの製品、システムおよびサービスのプロバイダは、彼らの顧客のシステムおよび装置の試験を行い、アップグレードし、かつ維持するために、アクセスと認証図式の統合に関する課題を抱えてきた。特にこれらのプロバイダおよびサービス会社は、彼らの顧客により用いられる多数のリモート・アクセスの要求と異なるリモート・アクセスおよび権限委任パッケージに応じることは困難であることが判ってきた。さらに、顧客の拡張されたユーザ・ベースにより用いられる、製品やシステムへのリモート・アクセスを必要とする、全ての第三者機関の技術者、ビジネス・パートナーおよびアウト・ソースを管理することは、コストと資源に関わる課題である。
【０００４】
企業の顧客は一般的に、確認し、制御し、ユーザにログするための、彼らのサイトに配置された認証／権限委任／管理（ＡＡＡ）サーバを有する。
ＡＡＡサーバは、
・認証：ユーザの特定および認識の処理、
・権限委任：あるユーザができることの決定、
・管理：あるユーザがしていることおよびしてきたことの記録動作、
を提供する。
【０００５】
図１は、代表的な顧客ネットワーク環境での、従来の認証／権限委任／管理（ＡＡＡ）サーバ５０を示す。図１はまた、顧客ＶＰＮゲートウェイ５１および製品５２、５３（例えば、ＰＢＸ）を示す。
【０００６】
サービス・プロバイダ技術者によるアクセスは、インターネットを経由してアクセス装置４０により実行される。従来、ユーザの認証を要求する顧客は、サービス・プロバイダの技術者に、彼らの仮想プライベート・ネットワーク（ＶＰＮ）クライアント（図示せず）および保証ＩＤのような彼らのハード・トークンの使用を要求する。数人のサービス技術者しか有さないサービス・プロバイダにとって、これは実行可能なオプションである。しかしながら、数百または数千の技術者を有するプロバイダにとっては、これは殆ど不可能である。
【０００７】
・各々のサービス技術者は、全ての顧客のＶＰＮクライアントを彼らのＰＣ上にインストールする必要がある。ＶＰＮクライアントは一般的にＰＣのＴＣＰＩＰスタックを変更するので、サービス・プロバイダのＰＣはもはや適切には機能しない。
【０００８】
・各々のサービス技術者は、全てのサービスを受けている顧客の数百またはできうれば数千のハード・トークンを管理する必要がある。これは、プロバイダと顧客の双方にとって管理不能になる。顧客がこの可能性について尋ねられると、彼らはよりよい解決法が必要であることに同意する。
【０００９】
・認証の前に、サービス・プロバイダが障害チケットまたは作業チケットを公表するように、との要望はない。
【００１０】
ＲＳＡセキュリティ社およびイオンネットワーク社のような、ハードおよびソフトのトークン・ベースのリモート・アクセス制御の解決法を提供する、多数の会社がある。この解決法は、彼ら自身の装置にアクセスする単一の会社に関しては、うまく動作する。外注のまたは第三者の保守の局面においては、これは、顧客のアクセス制御システムに設定され、個々のハードまたはソフトのトークンを割り当てられた、全てが第三者の技術者であることを含む、完全な拡張された技術者の力を必要とする。外部の保守会社にとって、各々の顧客に対する各々の技術者用のハード・トークン装置と連絡を絶やさないとの要望は、コストと保守の重大な問題である。
【００１１】
パーメオ技術社（Ｐｅｒｍｅｏ Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．）のような会社は、認証とリモート・アクセス制御の解決法の装置に、ターンキィ・デスクトップを提案する。この解決法は、彼ら自身の装置をアクセスする単一の会社については、うまく動作する。これは、全てのリモート・ユーザが全く同じソフトウェアのセットを購入して用いることと、顧客のアクセス制御システムに設定された、全てが第三者の技術者であることを含む、完全に拡張された技術者の力を必要とする。全ての顧客が選択したターンキィの解決法に必要とされる、全ての種々の構成およびソフトウェアを個々の技術者に提供することは実現可能でないので、これは第三者管理会社とコストにとっては重荷である。
【００１２】
リバティ・アライアンスおよびセキュリティ・アサーション・マークアップ（ダッシュ抜き）言語（ＳＡＭＬ）機関は、ウェブ・ベースのビジネス作業用の、信用ベースの身元確認および認証交換標準を開発中である。この標準化の努力は、ウェブ・ベースのビジネス取引およびその用途に、完全に焦点を当てている。リモート・メンテナンス監視およびサポートのためのプロトコルおよびそのアクセス要求は、アプリケーションへのウェブ・ベースのアクセスを遙かに超えている。
【００１３】
ソックス（ＳＯＣＫＳ）インターネット・コメント要請（ＲＦＣ１９２８、３０８９、１９２９）は、プロキシ・サービスを用いるネットワーク装置へのアクセスを確立する、プロトコルを提供する。プロキシ・サービスは、プロキシの背後の装置に対し、アクセスと権限委任制御を実施することができる。現在の標準は、クライアントのアプリケーションとプロキシの協定に基づいて、追加の権限委任モデルが設定されることを可能にするために、一般セキュリティ・サービス・アプリケーション・プログラミング・インターフェイス（ＧＳＳＡＰＩ）へのサポートと同様に、ユーザＩＤおよびパスワード・ベースの権限委任制御の使用をカバーする。
【００１４】
これらについてのさらなる情報は、以下に記載されている：
・ネットグリティ役割管理：
ｈｔｔｐ：／／ｗｗｗ．ｎｅｔｅｇｒｉｔｙ．ｃｏｍ／ｎｅｗｓ／ｗｅｂｓｅｍｉｎａｒａｒｃｈｉｖｅ／ｒｏｌｅｓａｒｃｈｉｖｅ．ｈｔｍｌ
・パーメオ社（Ｐｅｒｍｅｏ Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．）外向けアクセス：ｈｔｔｐ：／／ｗｗｗ．ｐｅｒｍｅｏ．ｃｏｍ／ｏｕｔｂｏｕｎｄａｃｃｅｓｓ．ｈｔｍ
・イオン・ネットワーク・セキュア・リモート・アクセス：ｈｔｔｐ：／／ｗｗｗ．ｉｏｎ−ｎｅｔｗｏｒｋｓ．ｃｏｍ／ｐｒｉｉｓｍｓ．ｓｈｔｍｌ
上記の問題が与えられた時に前進するために必要なものは、三つのＡＡＡ機能を分離して、認証はサービス・プロバイダのサイトで、ユーザの身元確認とそれに関連する役割はアクセスが要求された時に顧客のサイトにパスする手段である。認証と管理は、その後顧客のサイトで実行される。
【発明の開示】
【発明が解決しようとする課題】
【００１５】
本発明は、主たる目的として、背景技術のシステムおよびアプローチを改良すること、および背景技術のシステムに関連する欠点を解決することを有する。
【００１６】
ここに提案される解決法は、二つの会社の間の外用の信頼関係に基づく、認証モデルを含むためのＳＯＣＫＳトンネリングの概念を拡張することである。この信頼関係は、証明書を用いて実装される。
【００１７】
ＳＯＣＫＳトンネリングは、ＳＯＣＫＳクライアント・アプリケーションの代わりに、あるＳＯＣＫＳサーバがある装置へのプロキシ接続を確立するために、他のＳＯＣＫＳサーバに接触することである。ＳＯＣＫＳトンネリングに対しては、現在のところインターネット標準は存在しない。
【００１８】
権限委任モデルは、会社Ａがそれ自身の従業員を認証するために会社Ｂを信用するような、二つの会社の間の予め確立された信頼関係に基づいている。会社Ａは、会社Ｂから隔てられたリモート・ユーザを認証することを企図していない。その代わりに会社Ａは、会社Ｂの従業員によりなされた任意のリモート・アクセス要求を権限委任する。この権限委任は、そのリモート・アクセス要求の一部として安全なチャネルを通して送信された、身元情報のセットに基づいている。
【００１９】
作業においては二つの会社は、それらの会社の身元を表す、証明書または公的／私的鍵の組を最初に交換する。証明書は、リモート・アクセス要求がなされた場合に、各々の会社の身元を確立するために用いられる。それはまた、その要求を作成したリモート・ユーザの身元を交換するために、安全な通信機構を確立するためにも用いられる。
【００２０】
本発明の他の目的およびさらなる適用範囲は、以下に与えられる詳細な説明から明らかになるであろう。しかしながら、本発明の望ましい実施形態を示す一方で、詳細な説明および特定の実施例は一例としてのみ与えられるので、この詳細な説明から本発明の精神と範囲内の種々の変形および修正が当業者には自明であることが、理解されなければならない。
【００２１】
本発明は、以下に示される詳細な記述と、一例としてのみ添付された本発明の限定ではない図面により、さらに完全に理解されるであろう。
【課題を解決するための手段】
【００２２】
本発明は、従来のシステムおよびアプローチとは全く異なる、権限委任モデルを提供する。
この権限委任モデルは、会社Ａ（例えば顧客）が会社Ｂ（例えばサービス・プロバイダ）に、会社Ｂのシステムが全ての関係する従業員の身元証明を会社Ａに送った後にのみ、会社Ａの装置の一つにアクセスする権限を会社Ａが委任するようにされた、二つの会社の間の予め確立された信頼関係に基づいている。
【００２３】
顧客Ａは、図２に示される工程を実装することにより、二つの会社の間の信頼関係を最初に確立する。当該二つの会社の間に信頼関係が一度確立されると、会社Ｂによるリモート・アクセスができるようになる。
【発明を実施するための最良の形態】
【００２４】
図３（ａ）に示されるように会社Ａの環境は、ＳＯＣＫＳサーバ５、ポリシー・サーバ６および製品アクセス監査証跡装置７からなる、ローカル・ゲートウェイＳＳＧ１０を含む。製品８（例えばＰＢＸ）は、ローカル・ゲートウェイＳＳＧ１０に接続されている。
【００２５】
会社Ｂのシステムは、ＳＯＣＫＳサーバ４、ＡＡＡシステム２および障害チケット・システム１を備える、製品接続システム３を含む。
作業において二つの会社は、各々の会社の身元を表す、証明書または公的鍵／私的鍵の組を最初に取り交わす。証明書は、到来する要請が信頼されるシステムに由来することを確証するために用いられる。この取り交わしは、図３（ａ）に示される会社ＡとＢの環境について、また図３（ｂ）に示されるメッセージのシーケンスについて図示される。再確認すると、会社Ａは音声ＰＢＸスイッチのような、リモートでサービス可能なある製品のユーザであり、会社Ｂはこのシステムのサービス・プロバイダである。ローカルな認証データ・ベースに対し個々のリモート・ユーザの身元をチェックする代わりに、到来する接続が既知で信頼されるシステムに由来することを確証するために、ローカル・ゲートウェイＳＳＧ１０は会社の証明書または保証書をチェックする。個々のユーザの情報は、ローカル・ゲートウェイＳＳＧ１０により検査できる暗号化されたパケットの一部として送信され、個々のユーザの身元と他の関連する情報はＳＳＧ１０により記録される。
【００２６】
ここで図３（ｂ）を参照すると、会社Ｂの技術者（ユーザ）が会社Ａのネットワーク上の製品８に接続しようと企てる場合、以下の工程が発生する。
工程１：会社Ｂの技術者は、端末４０を経由して障害チケット・システム１にログインする。
工程２：技術者は、会社ＢのＡＡＡサービス２により認証される。
工程３：技術者は、障害チケット・システム１からサービスするチケットを選択する。
工程４：会社Ｂの技術者は、チケット内で参照される製品８への接続を要求する。
工程５：障害チケット・システム１は、製品接続システム３をコールし、接続を要求する。
工程６：製品接続システム３は、その技術者が当該の接続を許可されるべき適宜の権限委任を有するかどうかを決定するために、会社ＢのＡＡＡシステム（２）にコンタクトする。
工程７：権限委任が許可されたと仮定すると、製品接続システム３は会社ＢのＳＯＣＫＳサーバ４にコンタクトし、会社Ａのリモート製品８への接続を要求する。技術者の身元と障害チケット番号が、製品８の特定情報と共にＳＯＣＫＳサーバ４に送信される。
工程８：会社ＢのＳＯＣＫＳサーバ４は、ローカル・ゲートウェイＳＳＧ１０内で稼働中の、会社ＡのＳＯＣＫＳサーバ５との安全な接続を生成し、会社Ｂの保証書、技術者の身元、アクセスされる製品および作業される障害チケットを含む全ての関連する情報を包含する、権限委任要求ドキュメント９を送信する。
工程９：会社ＡのＳＯＣＫＳサーバ５は、会社Ｂの任意の身元を有効にするために供給される保証書を有効にする。
工程１０：会社ＡのＳＯＣＫＳサーバ５は、処理のためにこれまたローカル・ゲートウェイＳＳＧ１０で稼働中の、ポリシー・サーバ６にアクセス要求ドキュメントを送信する。
工程１１：ポリシー・サーバ６は、顧客が定義した任意のアクセス規則を、アクセス要求ドキュメント９の名前（ｎａｍｅ？）で供給される情報に適用する。ポリシー・サーバ６は、特定の顧客の従業員による現場でのリアルタイムの権限委任を必要とする、特定の装置へのアクセスを指定する。ローカル・ゲートウェイＳＳＧ１０は次に、その製品にアクセスするための権限委任を承認するために、これらの特定の顧客の従業員を通知する、顧客のインスタント・メッセージ・サーバ１１にアクセスする。ＳＳＧ１０は、リアルタイムの権限委任のために、顧客の従業員に特定のアクセス属性（故障チケット番号、製品の説明書、会社および従業員がアクセスする製品）を表す。一人またはそれ以上の顧客の従業員は、アクセスを「許可」または「拒否」することができる。顧客の従業員の誰かが、顧客が指定した時間内に「拒否」と言った場合は、アクセスは拒否される。拒否の理由は、顧客のインスタント・メッセージ・クライアントを用いて提供されることができる。顧客の従業員全員が「許可」と言った場合には、アクセスは許可される。所望のアクセス・ポリシーを提供するために、他のセキュリティ・パラメータがプログラムされてもよい。
【００２７】
本発明は以上に記述したような、リアルタイム警報のインスタント・メッセージの型式に限定されない。リアルタイムの権限委任への代替案の解決法は、標準の番号パッドを備えるディスプレイ電話１４を用いて顧客と交信する、ＳＩＰ（セッション起動プロトコル）サーバ１３（図３（ａ）に示される）を用いる。ここでＳＳＧのポリシー・サーバ６は、例えばサービス・プロバイダの技術者名、故障チケット情報および／またはアクセスを要求する装置を表すために、顧客のディスプレイ電話１４をコールし、次にアクセス情報を送る。顧客は、許可のために「１」を、拒否のために「２」を押す。ＳＳＧ１０は管理する装置毎に、顧客がプログラムしたアクセス・ポリシーを記憶している。
【００２８】
供給元のアクセスを許可するために顧客が用いる装置は、電話またはインスタント・メッセージ・サービスに限定されない。電話のような無線装置、パーソナル・デジタル・アシスタンツ、ブラック・ベリー（ｈｔｔｐ：／／ｗｗｗ．ｂｌａｃｋｂｅｒｒｙ．ｃｏｍ）装置、任意のローカルまたはリモート通信クライアントが、本発明に含まれる。
【００２９】
工程１２：ＳＯＣＫＳサーバ５は、ＳＳＧ１０に配置された会社Ａの監査ログ７に、全ての情報を記録する。
工程１３：権限委任が許可されたと仮定すると、ＳＯＣＫＳサーバ５は製品８への接続を公開する。その後制御は、技術者に戻される。ＳＯＣＫＳサーバ５は、ローカル装置にアドレスするために必要な、ネットワーク・アドレス変換を実行する。
【００３０】
認証機能と処理
認証機能は、顧客のサイトとはリモートに配置された、サービス・プロバイダのサービス配送プラットフォームと、顧客の構内またはその近くに配置された、ローカル・ゲートウェイ／セキュリティ機器ＳＳＧの、二つの個別のプラットフォームの相互作用により提供される。ＳＳＧは、サービス・プロバイダではなく、顧客により制御され、監視される。
【００３１】
サービス・プロバイダは、サービス技術者の顧客のサイトへの任意のアクセスが許可される前に、サービス技術者が認証されることを保証しなければならない。この認証処理は、また各々の個々の技術者にサービスする「役割」を割り当てる。ある役割は、顧客の装置またはシステムの特定の一部に、サービスを提供するための個々のサービス技術者の「免許」と考えられることができる。
【００３２】
例えば生成された障害チケットの結果としてアクセスが必要になると、最初にアクセス要求が顧客とは隔たったセキュリティ機器（ＳＳＧ）と交渉される。
アクセス要求は、以下のような属性を含む。
・サービス会社名
・技術者名、役割、アドレス
・技術者の管理者名、アドレスおよび電話番号
・アクセスされる製品
・障害チケット番号
・要求された現場での承認
・それらのネットワークに、サービス・プロバイダへのアクセス許可を与えた現場の担当の、電話番号、インスタント・メッセージ名またはＩＰアドレス
【００３３】
・サービス・プロバイダの社内処理ＩＤ
ＳＳＧは顧客により、特定の役割を有する技術者が彼らの装置およびネットワークにアクセスできるようにされている。サービス技術者によるアクセス要求は、ＳＳＧに安全に送られ、ＳＳＧ内に記憶されたアクセス・ポリシーと比較される。役割が適合すると、ユーザの身元およびアクセス要求内のその他全ての情報がＳＳＧの監査ログに記憶される。アクセス要求はまた、ネットワーク・マネジメント・システム、またはそれらにリアルタイムのアクセス通知を与えるシスログ・サーバに、ＳＳＧにより送信されることができる。以上に記述したように、アクセスはユーザの身元ではなく役割に対して与えられるが、ユーザの身元も説明責任のために同様に記録される。
【００３４】
認証機能および処理はまた、顧客が身元パケット内の他の情報について規則を構築できるようにしてもよい。例えば、特定のサービス技術者（または他のユーザ）が彼らのネットワークにアクセスできないようにする、顧客が「名前による拒否」ができる規則を作ることができる。これは、特定のサービス技術者またはユーザについての、顧客の過去の経験の結果であってもよい。この機能を提供するためには、サービス会社ＢはＳＳＧに全ての彼らの技術者名を送信する必要はない。むしろＳＳＧは、製品へのアクセスの通常処理中に、身元パケットで通過した名前を記憶する。この自動的な名前リストの作成は、除外リストの基礎となる。ＳＳＧ監査ログを裁判解析に用いて、顧客は除外すべき人物を決定する。顧客は次に、その名前を除外リストにコピーする。その人物が次にどんな製品にアクセスしようとしても、ＳＳＧはその人物によるどんな製品へのアクセスも拒否する。ＳＳＧはまた、拒否の理由を記述したＳＯＣＫＳ接続要求内の拒否メッセージを、会社ＢのＳＯＣＫＳサーバに返送する。
【００３５】
このようにして、認証機能は顧客が定義した権限委任チェックを許可する。
さらに認証機能は、「要求された現場での承認」権限委任モデルを可能にすることができる。例えばある顧客は、彼らのサイトに接続するのに先だって、サービス・プロバイダがリアルタイムのアクセス許可を得ることを必要とするかもしれない。このエントリは、顧客のサイトのＳＳＧにパスされる。ＳＳＧセキュリティ・ポリシーは、外部の通知サービス（以前に記述）を経由して、その技術者（名前による）がその製品にアクセスすることを許可するのに先立って、顧客の権限委任を求めるインスタント・メッセージ、ビーパまたはＥメールのようなメッセージを送信する。ＳＳＧは、顧客がそのアクセスを許可するか否か決定することができるように、サポートするアクセス情報を提供する。顧客の代理人がＳＳＧに承認を一度与えると、そのサービス技術者によるアクセスが許可される。ＳＳＧは後刻の顧客の監査のために、全ての許可および拒否されたアクセス要求を記録する。これは、あるベンダによりなされたアクセスが結果として、他の顧客のサーバにサービス停止やセキュリティ攻撃を起こした場合に重要である。この記録は、それを引き起こしたベンダ、技術者またはベンダの自動化ツールを指定することを助ける。
【００３６】
権限委任機能と処理
権限委任は、ユーザのアクセスが割り当てられたリソースにのみであることを保証する処理である。これは、通常、認証段階の後で行われる。
【００３７】
最初に、ＶＰＮクライアントについての簡潔な記述が提供される。ＶＰＮ接続処理では、あるネットワークまたはＩＰアドレスにのみアクセスするように、ＶＰＮクライアントが顧客のＶＰＮサーバによりリモートで作成される。リモートＰＣのＩＰパラメーターが、リモートネットワーク上のリソースにアクセスして使用するために、変更される。全ての実際的な目的のために、リモートＰＣはそのＰＣのローカルＬＡＮ上のリソースにはアクセスできない。そのＰＣは、論理的には顧客のネットワーク上に存在する。
【００３８】
ＬＡＮ接続へのＶＰＮクライアントの代わりにＬＡＮ−ＬＡＮ接続が用いられた場合、二つの異なるＩＰネットワークへの橋渡しのために、ネットワーク・アドレス変換（ＮＡＴ）が必要になるのでこれは重要である。顧客のＡＡＡサーバが許可された本当のＩＰアドレスを含む場合、アクセスがなされる前に、ＳＳＧはＡＡＡサーバからそれらを回収し、次にそれらをサービス・プロバイダの内部アドレスにマップする必要がある。
この処理を簡便化するために、ＳＳＧはネットワーク・アドレス変換（ＮＡＴ）と権限委任および管理機能の双方を実行する。
【００３９】
管理機能および処理
管理は、全ての認証および権限委任工程が完了した後に、ＳＳＧ内で実行される。
その顧客が管理に用いられる外部ＡＡＡサーバ（例えば、ポート１８１３を用いる、リモート認証ダイヤル・イン・ユーザ・サーバ（ＲＡＤＩＵＳ）システム）を有する場合は、ＳＳＧは顧客のサーバにアクセス要求／結果を記録することができる。これは、一つのサーバ内の全てのアクセス要求の監査を可能にする。
【００４０】
自動化リモート・アクセス・システム
以上に記述された処理は、サービス技術者により起動される。代替案としてシステムは、一般的に診断コンピュータにより起動される、自動化リモート・アクセスを提供するために用いられてもよい。
【００４１】
自動化システム・リモート・アクセスの際のメッセージ・フローは、以下の例外を除き、リモート技術者によるアクセスと同様である。会社Ｂの各々の自動化システムはそれ自身の固有の身元を有し、この身元はサービス・プロバイダのシステムにより確証され、次に顧客のシステムに提供される。ＳＳＧに送信された身元は技術者のそれではなく、診断コンピュータのそれなので、これは非常に重要である。障害チケット・システム１にアクセスする代わりに、自動化システム・リモート・アクセス・アプリケーションは、適切なチケット情報を供給する製品接続システム３に直接アクセスする。
【００４２】
ローカル技術者によるアクセス
ローカル技術者によるアクセスの際の、システムの構成要素の間のメッセージ・フローは、図４（ａ）の矢印により示されている。図４（ｂ）は、リモート技術者のアクセスの際の、工程のフロー・チャートを提供する。
【００４３】
会社Ｂの技術者によるローカル・アクセスの事前要件は、その技術者のＰＣがＳＯＣＫＳ化されていなければならないことである。ＳＯＣＫＳソフトウェアは、会社ＡのＳＳＧ１により管理されている製品への全てのトラヒックを、ＳＯＣＫＳサーバ２にリダイレクトするようにされていなければならない。ＳＯＣＫＳ化されたクライアントとＳＯＣＫＳサーバの間のプロトコルは、ＳＳＧへの安全なローカル・アクセスを維持するために、ＳＳＬを用いて暗号化されている
関連する工程は、以下を含んでいる：
工程１：ローカル技術者が、ローカルＳＳＧ１上で稼働中のＳＯＣＫＳサーバ２に接続する。
工程２：ＳＯＣＫＳサーバ２は、顧客のＡＡＡサーバ４に対して技術者の情報を認証する。
工程３：技術者は、ローカル・ネットワーク・アドレスを用いて製品５への接続を生成しようとする。
工程４：ＳＯＣＫＳサーバ２は、製品５にアクセスするための権限委任を求めて顧客のＡＡＡサーバ４をチェックする。
工程５：ＳＯＣＫＳサーバ２は、ＳＳＧ１のローカル監査ログ３内の接続要求を記録する。
工程６：ＳＯＣＫＳサーバ２は、製品５への接続を開放し、会社Ａのローカル技術者に制御を戻す。
【００４４】
以上に記述した本発明は、従来技術の審判アプローチの問題への、安全で統合された解決法を提供する。この解決法の利点は、以下を含む：
サービス・プロバイダが、顧客のアクセス制御システムに全ての第三者の技術者の身元を維持することは、もはや不必要である。
各々の第三者の保守、監視または支援ベンダのそれぞれが、各々の全ての顧客が彼らの装置にアクセスするために要求する、ソフトウェアまたはハード・トークンを有することは不必要である。
【００４５】
安全、監査手続および立法を充足するために必要な情報は、サービス会社とその装置を用いる顧客の双方により安全な方法で維持される。
【００４６】
サービス・プロバイダまたは顧客のどちらかによる甚大な作業を必要とすることなく、非常に個別的なアクセス制御規則の構築が可能となる。交換される身元情報は、リモートの保守、監視または支援の顧客が彼ら自身の装置にアクセスするための個別的で詳細なアクセス制御記録を、サービス・プロバイダに重荷を負わすことなく構築できるようにするのに充分である。
【００４７】
他の固有の利点は、以下を含む：
・権限委任はサービス・プロバイダのサイトではなく、むしろ顧客のサイトで起こる。
・顧客のサイトへのＩＰアクセスを可能にする、障害／作業チケットが最初に生成されなければならない。サービス・プロバイダのサイトに配置されたＳＳＧは、顧客のサイトへの直接のＩＰアクセスを妨げる。要求された情報が提供されない場合、アクセスは拒否される。これは、サービス・プロバイダの身元、サービス・プロバイダの技術者の身元および作業される障害チケットを含む。技術者の会社、技術者の身元（または自動化エキスパート・システムの身元）、役割、チケット番号および／または製品ＩＰアドレスおよび「要求された現場での承認」が、権限委任要求ドキュメントを用いて、現場のゲートウェイＳＳＧに安全に送信される。
・顧客は現場でのアクセス制御を保持し、その制御のためにサービス・プロバイダを信用する必要がない。
・顧客は：
ｉ．アクセスが許可された時間
ｉｉ．彼らの製品にアクセスする、許可された技術者の役割
ｉｉｉ．アクセスが許可された製品
ｉｖ．彼らの製品へのアクセスが許可されなかった人物（おそらく過去の経験から）および
ｖ．「要求された現場での承認」を与えることを許可された人物
など、所望のアクセス制御規則を有するオンサイト・ゲートウェイを予めプログラムする能力を有する。
・この解決法はまた、取引を記録する場所として、顧客のＡＡＡデータ・ベースとの統合を可能にする。認証は、サービス・プロバイダのＡＡＡシステムにより実行される。権限委任は、現場のゲートウェイ（ＳＳＧ）により実行される。管理（記録）は、ＳＳＧまたは顧客のＡＡＡサーバにより、オプションとして実行される。
・顧客の技術者は、ＳＳＧを通してローカルの製品に接続するために、標準ＳＯＣＫＳクライアントを用いることができる。ＳＳＧは、製品にアクセスするための単一のゲートウェイになる。
・この解決法は、顧客が現有するＢ２Ｂ接続を用いることができる。それは、サービス・プロバイダに個別のＶＰＮ／フレーム・リレー接続を必要とさせない。
【００４８】
本発明は以上のように記述されたが、これが多様な方法で変形されることが自明であろう。そのような変形は本発明の精神と範囲から逸脱していると見なしてはならず、当業者に自明な全てのそのような変形が、添付の請求項の範囲内に含まれることが企図されている。
【図面の簡単な説明】
【００４９】
【図１】顧客のネットワーク環境の代表例としての、従来技術の認証／権限委任／管理（ＡＡＡ）サーバを示す図である。
【図２】二つの会社の間の信頼関係の確立に際して起こる、マニュアルの工程のフロー・チャートである。
【図３（ａ）】顧客のネットワーク環境の代表例としての、本発明の認証／権限委任／管理（ＡＡＡ）システムを示す図である。
【図３（ｂ）】本発明の主たる利用に関わる工程を強調した、シーケンス図である。
【図４（ａ）】顧客サイトにいる、サービス技術者用の処理を示す図である。
【図４（ｂ）】本発明の変形に関わる工程を強調した、シーケンス図である。
【特許請求の範囲】
【請求項１】
第１の事業体の業務管理下で、製品に接続されるセキュリティ機器と、
第２の事業体の業務管理下の、前記ユーザ端末によりアクセスされる製品接続プラットフォームおよびユーザ端末と、
前記第１の事業体と前記第２の事業体との間で予め定められた判定基準に基づいて、前記第１の事業体と前記第２の事業体との間に確立された信頼関係であって、証明書または公的／私的鍵の交換により表される信頼関係とを含む、ネットワーク・アクセスを制御するシステムであって、
前記第２の事業体のユーザ端末のユーザによる、前記第１の事業体の前記製品へのアクセスの認証が、前記信頼関係の前記予め定められた判定基準に基づいて、前記第２の事業体の前記製品接続プラットフォームの判断にゆだねられ、認証が得られた場合に、前記ユーザが前記製品へのアクセスを提供される、ネットワーク・アクセスを制御するシステム。
【請求項２】
前記セキュリティ機器と前記製品接続プラットフォームとが互いに隔てられ、安全なネットワーク接続により接続可能であり、アクセスが許可された場合、前記ユーザ端末が前記安全な接続により前記製品にアクセスされる、請求項１に記載のネットワーク・アクセスを制御するシステム。
【請求項３】
前記セキュリティ機器が、第１のＳＯＣＫＳサーバと、ポリシー・サーバおよび製品アクセス監査ログとを含む、請求項１に記載のネットワーク・アクセスを制御するシステム。
【請求項４】
前記製品接続システムが第２のＳＯＣＫＳサーバを含む、請求項１に記載のネットワーク・アクセスを制御するシステム。
【請求項５】
認証サーバと障害管理システムとが前記製品接続システムに接続された、請求項１に記載のネットワーク・アクセスを制御するシステム。
【請求項６】
前記製品接続システムが、障害チケット番号、前記製品の認識票および前記ユーザの役割を含む、アクセス要求を発行する、請求項１に記載のネットワーク・アクセスを制御するシステム。
【請求項７】
前記第１の事業体と前記第２の事業体とが同じである、請求項１に記載のネットワーク・アクセスを制御するシステム。
【請求項８】
前記ポリシー・サーバが、前記製品へのアクセスがリアルタイムの権限委任を必要とすることを指定する、請求項３に記載のネットワーク・アクセスを制御するシステム。
【請求項９】
第１の事業体の業務管理下で、製品に接続されるセキュリティ機器と、
第２の事業体の業務管理下の、ユーザ端末と、
前記第１の事業体と前記第２の事業体との間で予め定められた判定基準に基づいて、前記第１の事業体と前記第２の事業体との間に確立された信頼関係であって、証明書または公的／私的鍵の交換により表される信頼関係とを含む、ネットワーク・アクセスを制御するシステムであって、
前記第２の事業体のユーザ端末のユーザによる、前記第１の事業体の前記製品へのアクセスの認証が、前記信頼関係の前記予め定められた判定基準に基づいて、前記第２の事業体の前記ユーザ端末の判断にゆだねられ、認証が得られた場合に、前記ユーザが前記製品へのアクセスを提供される、ネットワーク・アクセスを制御するシステム。
【請求項１０】
前記ユーザ端末が前記セキュリティ機器と交信するためのＳＯＣＫＳソフトウェアを備える、請求項９に記載のネットワーク・アクセスを制御するシステム。
【請求項１１】
前記セキュリティ機器が、第１のＳＯＣＫＳサーバと、ポリシー・サーバおよび製品アクセス監査ログを含む、請求項９に記載のネットワーク・アクセスを制御するシステム。
【請求項１２】
前記ユーザ端末が、障害チケット番号、前記製品の認識票および前記ユーザの役割を含む、アクセス要求を発行する、請求項９に記載のネットワーク・アクセスを制御するシステム。
【請求項１３】
前記ポリシー・サーバが、前記製品へのアクセスがリアルタイムの権限委任を必要とすることを指定する、請求項１１に記載のネットワーク・アクセスを制御するシステム。
【請求項１４】
第１と第２の事業体の間に、証明書または公的／私的鍵の交換により表される信頼関係を確立する工程と、
前記第２の事業体のユーザが前記第１の事業体の製品へのアクセスを要求する工程と、
前記第１の事業体へのアクセスを要求する前記ユーザの認証を前記第２の事業体の判断にゆだねる工程と、
認証が得られた場合に、前記第１の事業体の製品への前記第２の事業体のユーザによるアクセスを提供する工程からなるネットワーク・アクセスを提供する工程とを含む方法であって、
前記アクセスの認証が、前記信頼関係の予め定められた判定基準に基づいて許可される、ネットワーク・アクセスを制御する方法。
【請求項１５】
前記第１の事業体のセキュリティ機器に、アクセス要求を生成して送信する工程をさらに含む、請求項１４に記載のネットワーク・アクセスを制御する方法。
【請求項１６】
ＳＯＣＫＳサーバに安全なネットワーク接続のアクセス要求を送信する工程をさらに含む、請求項１４に記載のネットワーク・アクセスを制御する方法。
【請求項１７】
予め定められた判定基準に基づいて、ローカル・ネットワーク・ゲートウェイでアクセスを認証して管理する工程であって、前記予め定められた判定基準が、ユーザの身元、障害チケット番号およびアクセスされる前記製品の認識票を含むものである工程をさらに含む、請求項１４に記載のネットワーク・アクセスを制御する方法。
【請求項１８】
前記予め定められた判定基準が前記第１の事業体により動的に制御される、請求項１４に記載のネットワーク・アクセスを制御する方法。
【請求項１９】
リアルタイム・ベースで認証を許可する工程をさらに含む、請求項１４に記載のネットワーク・アクセスを制御する方法。
【請求項１】
第１の事業体の業務管理下で、製品に接続されるセキュリティ機器と、
第２の事業体の業務管理下の、前記ユーザ端末によりアクセスされる製品接続プラットフォームおよびユーザ端末と、
前記第１の事業体と前記第２の事業体との間で予め定められた判定基準に基づいて、前記第１の事業体と前記第２の事業体との間に確立された信頼関係であって、証明書または公的／私的鍵の交換により表される信頼関係とを含む、ネットワーク・アクセスを制御するシステムであって、
前記第２の事業体のユーザ端末のユーザによる、前記第１の事業体の前記製品へのアクセスの認証が、前記信頼関係の前記予め定められた判定基準に基づいて、前記第２の事業体の前記製品接続プラットフォームの判断にゆだねられ、認証が得られた場合に、前記ユーザが前記製品へのアクセスを提供される、ネットワーク・アクセスを制御するシステム。
【請求項２】
前記セキュリティ機器と前記製品接続プラットフォームとが互いに隔てられ、安全なネットワーク接続により接続可能であり、アクセスが許可された場合、前記ユーザ端末が前記安全な接続により前記製品にアクセスされる、請求項１に記載のネットワーク・アクセスを制御するシステム。
【請求項３】
前記セキュリティ機器が、第１のＳＯＣＫＳサーバと、ポリシー・サーバおよび製品アクセス監査ログとを含む、請求項１に記載のネットワーク・アクセスを制御するシステム。
【請求項４】
前記製品接続システムが第２のＳＯＣＫＳサーバを含む、請求項１に記載のネットワーク・アクセスを制御するシステム。
【請求項５】
認証サーバと障害管理システムとが前記製品接続システムに接続された、請求項１に記載のネットワーク・アクセスを制御するシステム。
【請求項６】
前記製品接続システムが、障害チケット番号、前記製品の認識票および前記ユーザの役割を含む、アクセス要求を発行する、請求項１に記載のネットワーク・アクセスを制御するシステム。
【請求項７】
前記第１の事業体と前記第２の事業体とが同じである、請求項１に記載のネットワーク・アクセスを制御するシステム。
【請求項８】
前記ポリシー・サーバが、前記製品へのアクセスがリアルタイムの権限委任を必要とすることを指定する、請求項３に記載のネットワーク・アクセスを制御するシステム。
【請求項９】
第１の事業体の業務管理下で、製品に接続されるセキュリティ機器と、
第２の事業体の業務管理下の、ユーザ端末と、
前記第１の事業体と前記第２の事業体との間で予め定められた判定基準に基づいて、前記第１の事業体と前記第２の事業体との間に確立された信頼関係であって、証明書または公的／私的鍵の交換により表される信頼関係とを含む、ネットワーク・アクセスを制御するシステムであって、
前記第２の事業体のユーザ端末のユーザによる、前記第１の事業体の前記製品へのアクセスの認証が、前記信頼関係の前記予め定められた判定基準に基づいて、前記第２の事業体の前記ユーザ端末の判断にゆだねられ、認証が得られた場合に、前記ユーザが前記製品へのアクセスを提供される、ネットワーク・アクセスを制御するシステム。
【請求項１０】
前記ユーザ端末が前記セキュリティ機器と交信するためのＳＯＣＫＳソフトウェアを備える、請求項９に記載のネットワーク・アクセスを制御するシステム。
【請求項１１】
前記セキュリティ機器が、第１のＳＯＣＫＳサーバと、ポリシー・サーバおよび製品アクセス監査ログを含む、請求項９に記載のネットワーク・アクセスを制御するシステム。
【請求項１２】
前記ユーザ端末が、障害チケット番号、前記製品の認識票および前記ユーザの役割を含む、アクセス要求を発行する、請求項９に記載のネットワーク・アクセスを制御するシステム。
【請求項１３】
前記ポリシー・サーバが、前記製品へのアクセスがリアルタイムの権限委任を必要とすることを指定する、請求項１１に記載のネットワーク・アクセスを制御するシステム。
【請求項１４】
第１と第２の事業体の間に、証明書または公的／私的鍵の交換により表される信頼関係を確立する工程と、
前記第２の事業体のユーザが前記第１の事業体の製品へのアクセスを要求する工程と、
前記第１の事業体へのアクセスを要求する前記ユーザの認証を前記第２の事業体の判断にゆだねる工程と、
認証が得られた場合に、前記第１の事業体の製品への前記第２の事業体のユーザによるアクセスを提供する工程からなるネットワーク・アクセスを提供する工程とを含む方法であって、
前記アクセスの認証が、前記信頼関係の予め定められた判定基準に基づいて許可される、ネットワーク・アクセスを制御する方法。
【請求項１５】
前記第１の事業体のセキュリティ機器に、アクセス要求を生成して送信する工程をさらに含む、請求項１４に記載のネットワーク・アクセスを制御する方法。
【請求項１６】
ＳＯＣＫＳサーバに安全なネットワーク接続のアクセス要求を送信する工程をさらに含む、請求項１４に記載のネットワーク・アクセスを制御する方法。
【請求項１７】
予め定められた判定基準に基づいて、ローカル・ネットワーク・ゲートウェイでアクセスを認証して管理する工程であって、前記予め定められた判定基準が、ユーザの身元、障害チケット番号およびアクセスされる前記製品の認識票を含むものである工程をさらに含む、請求項１４に記載のネットワーク・アクセスを制御する方法。
【請求項１８】
前記予め定められた判定基準が前記第１の事業体により動的に制御される、請求項１４に記載のネットワーク・アクセスを制御する方法。
【請求項１９】
リアルタイム・ベースで認証を許可する工程をさらに含む、請求項１４に記載のネットワーク・アクセスを制御する方法。
【図１】
【図２】
【図３（ａ）】
【図３（ｂ）】
【図４（ａ）】
【図４（ｂ）】
【図２】
【図３（ａ）】
【図３（ｂ）】
【図４（ａ）】
【図４（ｂ）】
【公開番号】特開２００６−５３９２３（Ｐ２００６−５３９２３Ａ）
【公開日】平成１８年２月２３日（２００６．２．２３）
【国際特許分類】
【出願番号】特願２００５−２３２７６８（Ｐ２００５−２３２７６８）
【出願日】平成１７年８月１１日（２００５．８．１１）
【出願人】（５００５０００４４）アバイア テクノロジー コーポレーション (53)
【Ｆターム（参考）】
【公開日】平成１８年２月２３日（２００６．２．２３）
【国際特許分類】
【出願日】平成１７年８月１１日（２００５．８．１１）
【出願人】（５００５０００４４）アバイア テクノロジー コーポレーション (53)
【Ｆターム（参考）】
[ Back to top ]