JP2006101346A - アクセス制御システム、アクセス制御方法、およびアクセス制御プログラム - Google Patents

Abstract

【課題】 アクセス制御に関する管理の負担を軽減するとともに、適切な管理の実行を容易にする。
【解決手段】 呼設定の許可、不許可を決定してアクセス制御を実行するアクセス制御システムにおいて、呼設定可否情報を蓄積した呼設定可否データベース部を有する呼制御関連サーバと、呼設定の要求元または要求先となる通信端末とを備え、通信端末は、通信端末を利用するユーザが行う登録内容変更操作に応じて、呼設定可否情報を含む所定の登録内容変更要求メッセージを呼制御関連サーバに送信し、呼設定可否データベース部における呼設定可否情報の登録内容を変更させる登録内容変更要求部を有する。
【選択図】 図１

Description

本発明はアクセス制御システム、アクセス制御方法、およびアクセス制御プログラムに関し、例えば、ＶｏＩＰ技術を利用するＩＰ電話機能を搭載したパソコンでセキュリティポリシーを設定する場合などに適用して好適なものである。

従来、セキュリティーポリシーを設定する場合、ＵＲＬ、通信プロトコルの種類、通信相手となるコンピュータのホスト名、アドレス、ポート番号などの項目を、システム管理者が手作業で設定するのが普通である。

一方、企業内ネットワーク（プライベートネットワーク）の外部にあるモバイル端末から、インターネットおよびその他のネットワーク（ＮＳＰネットワーク）を経由して当該企業内ネットワークに接続することを可能にする技術として下記の特許文献１に記載されたものがある。

特許文献１では、ＮＳＰネットワーク内の加入者データ管理部に、企業内ネットワークへの接続を許可された正当なモバイル端末のＩＤなど認証用情報を蓄積しておく。企業内ネットワークにアクセスしようとする場合、モバイル端末はまず最初に、当該ＮＳＰネットワーク内に設けられたＮＡＳ（あるいは、アクセスルータ）にアクセスし、ＮＳＰネットワークとインターネットを経由して、企業内ネットワークのゲートウエイ部に接続要求を送る。具体的には、当該モバイル端末から企業内ネットワークに設けられたＷｅｂサーバなどへ送信される最初のパケットがゲートウエイ部に届いたとき、当該パケットがゲートウエイ部により接続要求として扱われる。

ゲートウエイ部が当該モバイル端末による接続要求の正当性の認証を要求する（接続認証要求を送る）と、前記ＮＳＰネットワーク内に設置されたプラットフォーム部がこの接続認証要求を受け取り、同じＮＳＰネットワーク内に設置されている加入者データ管理部に問い合わせることで、当該認証を行う。

接続要求の正当性が認証されると、前記企業内ネットワークのゲートウエイ部は、前記モバイル端末との接続を確立するので、モバイル端末から前記Ｗｅｂサーバなどにアクセスすることが可能になる。このとき、企業内ネットワークのセキュリティポリシー（セキュリティ方針）に応じて、ゲートウエイ部から前記ＮＡＳやモバイル端末にまで及ぶＶＰＮ（仮想プライベートネットワーク）などを形成することもできる。
特開２００４−７２７６６号公報

ところで、システム管理者が上述したように、ＵＲＬ、通信プロトコルの種類、通信相手となるコンピュータのホスト名、アドレス、ポート番号などの項目を、手作業で設定することによってセキュリティポリシーの設定を行うことは、管理のための負担が大きい。しかも、実際のネットワークで用いられるセキュリティポリシーは、組織が必要とするネットワークの利用法や組織内にあるリソースの量や質、組織の業務内容など各種の複雑な要因に基づいて決まるものであるため、これらの要因に変動があれば、最適なセキュリティーポリシーの設定もそれに合わせて変化させなければならず、管理の負担はさらに増大する。反対に、管理負担を軽減しようとすると、セキュリティーポリシーが最適なものから大きく外れたものとなってしまい、適切な管理を行うことができない。

前記特許文献１では、企業内ネットワークの内部で設定し管理する必要のあるセキュリティポリシーの設定方法に関して、特段、言及されてはいない。

また、特許文献１において、前記加入者データ管理部に蓄積された認証用情報（モバイル端末のＩＤなど）も、広い意味でのセキュリティポリシーに属するものであるとみることもできるが、モバイル端末のＩＤなどを加入者データ管理部に設定するための方法に関して、特許文献１には特段、言及されてはいない。したがって、特許文献１によっても、上述した管理負担を軽減することや、適切な管理を行うことが難しい。

かかる課題を解決するために、第１の本発明では、開始時に呼設定の過程を伴う通信に関し、呼設定のため呼設定の要求元となる通信端末から送信される呼設定メッセージの記述内容を、予め蓄積した呼設定可否情報と照合することによって呼設定の許可、不許可を決定してアクセス制御を実行するアクセス制御システムにおいて、（１）前記呼設定可否情報を蓄積した呼設定可否データベース部を有する呼制御関連サーバと、（２）呼設定の要求元または要求先となる通信端末とを備え、（３）当該通信端末は、当該通信端末を利用するユーザが行う登録内容変更操作に応じて、前記呼設定可否情報を含む所定の登録内容変更要求メッセージを前記呼制御関連サーバに送信し、前記呼設定可否データベース部における当該呼設定可否情報の登録内容を変更させる登録内容変更要求部を有することを特徴とする。

また、第２の本発明では、開始時に呼設定の過程を伴う通信に関し、呼設定のため呼設定の要求元となる通信端末から送信される呼設定メッセージの記述内容を、予め蓄積した呼設定可否情報と照合することによって呼設定の許可、不許可を決定してアクセス制御を実行するアクセス制御方法において、（１）呼制御関連サーバでは、呼設定可否データベース部が前記呼設定可否情報を蓄積し、（２）通信端末が、呼設定の要求元または要求先となり、（３）当該通信端末は、当該通信端末を利用するユーザが行う登録内容変更操作に応じて、前記呼設定可否情報を含む所定の登録内容変更要求メッセージを前記呼制御関連サーバに送信し、前記呼設定可否データベース部における当該呼設定可否情報の登録内容を変更させることを特徴とする。

さらに、第３の本発明では、開始時に呼設定の過程を伴う通信に関し、呼設定のため呼設定の要求元となる通信端末から送信される呼設定メッセージの記述内容を、予め蓄積した呼設定可否情報と照合することによって呼設定の許可、不許可を決定してアクセス制御を実行するアクセス制御プログラムにおいて、コンピュータに、（１）前記呼設定可否情報を蓄積した呼設定可否データベース機能を有する呼制御関連サーバ機能と、（２）呼設定の要求元または要求先となる通信端末機能とを実現させ、（３）当該通信端末機能は、当該通信端末機能を利用するユーザが行う登録内容変更操作に応じて、前記呼設定可否情報を含む所定の登録内容変更要求メッセージを前記呼制御関連サーバ機能に送信し、前記呼設定可否データベース機能における当該呼設定可否情報の登録内容を変更させる登録内容変更要求機能を有することを特徴とする。

本発明によれば、アクセス制御に関する管理の負担を軽減するとともに、適切な管理の実行を容易にすることができる。

（Ａ）実施形態
以下、本発明にかかるアクセス制御システム、アクセス制御方法、およびアクセス制御プログラムを、ＳＩＰ（セッション・イニシエーション・プロトコル）を用いるＶｏＩＰ通信システムに適用した場合を例に、実施形態について説明する。ここでのＳＩＰには、ＶｏＩＰによるリアルタイム通信のためのＲＴＰやＲＴＣＰも含む。

（Ａ−１）第１の実施形態の構成
本実施形態にかかるＶｏＩＰ通信システム１０の全体構成例を図１に示す。

図１において、当該ＶｏＩＰ通信システム１０は、ＬＡＮ（ローカル・エリア・ネットワーク）１１と、インターネット（インターネット網）１２とを備えている。

このうちＬＡＮ１１は、ある企業ＥＲ１のために構築されたネットワークであり、当該ＬＡＮ１１とインターネット１４のあいだにはファイアウオール１４が配置されている。

ＬＡＮ１１の内部は、前記ファイアウオール１４により、企業内ネットワーク１５と、ＤＭＺ（DeMilitarized Zone）１６に分けられている。ＤＭＺ１６はインターネット１２上からアクセス可能の公開サーバなどを設置するためのセグメントで、図示の例では、ＳＩＰバックワードプロキシサーバ（ＳＩＰリバースプロキシサーバ）１７とデータベース１８〜２０が設置されている。一般的にＤＭＺ１６は、ファイアウオール１４によって守られている点でバリアセグメントよりもセキュリティレベルが高いが、インターネット１２上の通信端末（例えば、パソコン１３）からアクセス可能である点で、企業内ネットワーク１５よりもセキュリティレベルは低い。ただし、図１の場合、ユーザＢとユーザＡがＶｏＩＰによる通話を行うためには、ファイアウオール１４経由でパソコン１３からパソコン２１にアクセスできることが必要となる。

ＤＭＺ１６に設置されているＳＩＰバックワードプロキシサーバ１７には、インターネット１２上のパソコン１３のほか、企業内ネットワーク１５に属するパソコン２１，２２も、ファイアウオール１４経由でアクセスできる。ここで、パソコン１３，２１，２２は、ＳＩＰソフトフォンを搭載しているものとする。ＳＩＰソフトフォンは通常のパソコンをＩＰ電話機として利用できるようにするためのアプリケーションプログラムである。この場合、パソコン１３，２１，２２にスピーカやマイクなどのデバイスを装備すれば、ＩＰ電話機として利用することが可能となる。パソコン１３，２１，２２は据え置き型のパソコンであってもよく、移動性を有するノート型パソコンなどであってもよい。パソコン１３はユーザＢによって利用され、パソコン２１はユーザＡによって利用され、パソコン２２はユーザＣによって利用されるものとする。

ＩＰ電話で呼制御のために用いる呼制御プロトコルには様々なものがあり、例えば、ＩＴＵ−Ｔ勧告Ｈ．３２３などを用いることも可能であるが、ＳＩＰソフトフォンは呼制御プロトコルとしてＳＩＰを用いる。

ＳＩＰバックワードプロキシサーバ１７は、いわゆるＳＩＰサーバ（図示せず）側に配置される構成要素で、ユーザがＳＩＰによる呼制御を受けるためには、必ず当該ＳＩＰバックワードプロキシサーバ１７による処理を経なければならない。したがって、ＳＩＰバックワードプロキシサーバ１７によってアクセスを拒否されたユーザは、呼の設定などを行うことができず、ＶｏＩＰ通信を実行することが不可能となる。

前記データベース１８〜２０は、ＳＩＰバックワードプロキシサーバ１７によって利用される情報を登録、蓄積している。データベース１８にはＳＩＰバックワードセキュリティポリシーが登録され、データベース１９にはユーザＣによって登録されたバディリスト（お友達リスト）データが蓄積され、データベース２０にはユーザＡによって登録されたバディリストデータが蓄積されている。必要ならば、これら３つのデータベース１８〜２０は、物理的には、１つの情報処理装置上に実現できることは当然である。

また、ユーザＡによって登録されたバディリストデータ（バディリストテーブルＴＢ２）を図７に示す。このバディリストテーブルＴＢ２は、ユーザＡがＶｏＩＰ通信による通話をすることを希望する正当なユーザのリストを登録したテーブルである。パソコン２１を操作するユーザＡには、パソコン２１上で動作する一種のアドレス帳である所定のアプリケーションプログラム（バディリストプログラム）ＡＰ１が提供する画面として当該バディリストテーブルＴＢ２の内容が閲覧され、認識される。バディリストテーブルＴＢ２には、ユーザＡがプレゼンス情報（例えば、通話中か否かを示す通話状態情報、在席しているか否かを示す在席状態情報、着呼時において通話の用件を示す用件情報など）を取得したいと希望する１または複数のユーザを登録する。

当該アプリケーションＡＰ１は、前記ＳＩＰソフトフォンの一部の機能として実現することもできるし、独立したプログラムとして実現することも可能である。したがって、アプリケーションＡＰ１は、当該バディリストテーブルＴＢ２上の手段（例えば、図示しないデータ項目）またはバディリストテーブルＴＢ２とは別個の手段（図示せず）で、他のユーザ（例えば、Ｂ）のプレゼンス情報をユーザＡに伝える機能を有する。

他のユーザ（例えば、Ｃ）によって登録されたバディリストデータも、このバディリストテーブルＴＢ２と同様な構造を持ち、同様の方法で閲覧される。ただし、通常、ユーザが閲覧できるのは、自身が登録したバディリストデータのみであり、他のユーザが登録したバディリストデータは閲覧できない。

図７において、前記バディリストテーブルＴＢ２は、データ項目として、ＩＤと、登録ユーザ（ＳＩＰ−ＵＲＩ）と、ユーザ名とを備えている。

このうちＩＤは、バディリストテーブルＴＢ２内で各行（各エントリ）を一意に識別するための識別情報である。ここで、行とは、テーブルＴＢ２中のデータ項目を除く横の並びのことである。例えば、「１ sip:userB@… Ｂ」の行Ｌ１は１つの行である。

登録ユーザは、ユーザＡによって登録された各ユーザを示す。登録ユーザの値は、そのユーザ（例えば、ユーザＢ）を識別するためのＳＩＰ−ＵＲＩである。ＳＩＰ−ＵＲＩは、ＳＩＰプロトコルで宛先などを識別するために使用される識別情報である。ここに登録されたＳＩＰ−ＵＲＩに対応するユーザが、ユーザＡがＶｏＩＰ通信による通話を行うことを希望する正当なユーザである。ＳＩＰ−ＵＲＩは、ＯＳＩ参照モデルのアプリケーション層などに対応するＳＩＰメッセージのレベルで使用される識別情報であるため、実装上、アプリケーションレベルで利用しやすい。このＶｏＩＰ通信システム１０内では、すべての正当なユーザが各ユーザに割り当てられたＳＩＰ−ＵＲＩで識別される。

ユーザＡがバディリストテーブルＴＢ２に登録する登録ユーザは、通常、ユーザＡが頻繁に連絡を取る必要のあるユーザや、居場所（例えば、そのユーザの移動先のＩＰ電話機の電話番号やＩＰアドレスなど）を把握しておきたいユーザなどである。

ユーザ名は、各ユーザを識別するためのユーザ名を示す。人間にとって可読で各ユーザ（各社員）を識別できるあらゆる情報をユーザ名として用いることができるが、例えば、そのユーザの氏名をユーザ名としてもよい。

前記ＳＩＰバックワードセキュリティポリシー（セキュリティポリシーテーブルＴＢ１）は例えば図８に示す通りである。前記バディリストテーブル（例えば、ＴＢ２）は、バディリストテーブルを登録するユーザごとに用意されるものであるが、当該セキュリティポリシーテーブルＴＢ１は、全ユーザのために１つだけ用意されるテーブルである。したがって、当該セキュリティポリシーテーブルＴＢ１には、ＶｏＩＰ通信システム１０内の正当な全ユーザ分のセキュリティポリシーが登録される。

本来、セキュリティポリシーは、ネットワーク（ここでは、ＬＡＮ１１）のセキュリティを確保するための多種多様な規則を包含する広い概念であるため、セキュリティポリシーの設定には、例えば、上述したＵＲＬ、通信プロトコルの種類、通信相手となるコンピュータのホスト名、アドレス、ポート番号などの項目の設定が含まれ得るが、図８の例では、呼の設定が可能なユーザの組を示すＳＩＰ−ＵＲＩの組を、１つのセキュリティポリシーとしている。

図７において、当該セキュリティポリシーテーブルＴＢ１は、データ項目として、ＩＤと、バディリスト登録元ユーザと、バディリスト登録ユーザとを備えている。

このうちＩＤは、セキュリティポリシーテーブルＴＢ１内で各行を一意に識別するための識別情報である。

バディリスト登録元ユーザは、データ項目としてのバディリスト登録ユーザを登録したユーザを示す。バディリスト登録元ユーザの値は、ユーザを識別するためのＳＩＰ−ＵＲＩで登録される。

バディリスト登録ユーザは、バディリスト登録元ユーザによって登録されたユーザを示す。バディリスト登録ユーザの値は、ユーザを識別するためのＳＩＰ−ＵＲＩで登録される。

例えば、セキュリティポリシーテーブルＴＢ１の行ＬＮ１では、ＳＩＰ−ＵＲＩとして「ｕｓｅｒＡ＠…」を割り当てられたユーザＡ（バディリスト登録元ユーザの一例）が、ＳＩＰ−ＵＲＩとして「ｕｓｅｒＢ＠…」を割り当てられたユーザＢ（バディリスト登録ユーザの一例）を登録している。この登録に基づいて、ユーザＢのパソコン１３から送信された呼制御メッセージを前記ＳＩＰサーバが処理、中継することが許可されるため、ユーザＢはユーザＡに発呼することが可能になる。

なお、一人のバディリスト登録元ユーザが、複数のバディリスト登録ユーザを当該セキュリティポリシーテーブルＴＢ１に登録できることは当然である。

以下、上記のような構成を有する本実施形態の動作について、図２〜図５の動作シーケンスを用いて説明する。ここでは、ユーザＡとユーザＡが利用するパソコン２１に注目して、本実施形態の動作を説明する。

図２は、前記セキュリティポリシーテーブルＴＢ１に行を追加するための動作シーケンスで、Ｓ１０〜Ｓ１４の各ステップを備えている。

図３は、前記セキュリティポリシーテーブルＴＢ１から行を削除するための動作シーケンスで、Ｓ２０〜Ｓ２２の各ステップを備えている。

図４は、正当なユーザのパソコンに対し、呼制御メッセージの処理、中継を許可する場合の動作シーケンスで、Ｓ３０〜Ｓ３４の各ステップを備えている。

図５は、正当でないユーザのパソコンに対し、呼制御メッセージの処理、中継を拒否する場合の動作シーケンスで、Ｓ４０〜Ｓ４２の各ステップを備えている。

図６は、バディリストテーブルＴＢ２に行を追加するための動作シーケンスで、Ｓ５０〜Ｓ５４の各ステップを備えている。本実施形態では、バディリストテーブルＴＢ２の操作と、セキュリティポリシーテーブルＴＢ１の操作を連携させているため、例えば、バディリストテーブルＴＢ２に行を追加した場合には、セキュリティポリシーテーブルＴＢ１にも行が追加される。したがって、図６中の多くのステップは、図２のステップと重複している。

（Ａ−２）第１の実施形態の動作
図６に示すように、ユーザＡがパソコン２１を用いて自身のバディリストテーブルＴＢ２に新たなユーザ（ここでは、Ｂとする）を登録することを要求するバディリスト登録要求メッセージを送信すると（Ｓ５０）、このバディリスト登録要求メッセージを受け取ったＳＩＰバックワードプロキシサーバ１７では、当該バディリスト登録要求メッセージが到着したことをユーザＢのパソコン１３へ通知する（Ｓ５１）。ここで、バディリストテーブルＴＢ２に登録するということは、上述したようにユーザＢのプレゼンス情報をユーザＡに伝えることを意味するため、ステップＳ５１では、伝えてよいかユーザＢに許可を求めている。

ユーザＢが許可しない場合、前記ステップＳ５０のバディリスト登録要求メッセージには応じられない旨の応答メッセージをユーザＡに返送するものであってよいが、ユーザＢが許可した場合（Ｓ５２）には、図６に示すように、バディリストテーブルＴＢ２にユーザＢに対応する行が追加され（Ｓ５３）、この追加が行われた旨の応答メッセージがＳＩＰバックワードプロキシサーバ１７からユーザＡのパソコン２１へ届けられる（Ｓ５４）。この応答メッセージがパソコン２１に届いたことは、パソコン２１に搭載している前記アプリケーションＡＰ１によってユーザＡに伝えられる。

図７に示した前記行Ｌ１はこのようにして追加されたものである。

なお、ステップＳ５０，Ｓ５１，Ｓ５２，Ｓ５４の処理で行われるメッセージの送受は、各パソコン２１，１３に搭載されている前記アプリケーションＡＰ１の機能によるものである。この点は、図２〜図５でも同じである。

上述したように、バディリストテーブル（ここでは、ＴＢ２）も、セキュリティポリシーテーブルＴＢ１もＳＩＰバックワードプロキシサーバ１７側で管理しているため、当該ＳＩＰバックワードプロキシサーバ１７は、バディリストテーブルＴＢ２に対する操作（例えば、行の追加）に連携してセキュリティポリシーテーブルＴＢ１に対する操作（例えば、行の追加）を自動的に実行することができる。

例えば、図７に示すバディリストテーブルＴＢ２に行Ｌ１が追加されると、それに連携して、セキュリティポリシーテーブルＴＢ１に行ＬＮ１が追加される。この行ＬＮ１の追加を行うステップは、図２上のステップＳ１３である。

図２において、ステップＳ１０は前記ステップＳ５０に対応し、ステップＳ１１は前記ステップＳ５１に対応し、ステップＳ１２は前記ステップＳ５２に対応し、ステップＳ１４は前記ステップＳ５４に対応するので、その詳しい説明は省略する。

ユーザＡの立場からすると、一度、バディリスト登録要求メッセージを送信するだけで、バディリストテーブルＴＢ２に対する行Ｌ１の追加と、セキュリティポリシーテーブルＴＢ１に対する行ＬＮ１の追加を行うことができる。

また、具体的にユーザＡが実行する操作の内容はユーザインタフェースの構成に応じて決まるが、例えば、前記ステップＳ５０のバディリスト登録要求メッセージを送信する場合、自ユーザＡのＳＩＰ−ＵＲＩと登録ユーザＢのＳＩＰ−ＵＲＩがすでにアドレス帳などに記録されているものとすると、画面上で該当する対話部品（例えば、ボタン）に所定の簡単な操作（例えば、右クリックのみ）を行うだけで、パソコン２１から前記ステップＳ１０やＳ５０のバディリスト登録要求メッセージを送信させることができる。

次に、セキュリティポリシーテーブルＴＢ１に行ＬＮ１が追加された状態で、図４に示すように、ユーザＢが利用するパソコン１３からユーザＡとの接続を求める接続要求メッセージが送信されたものとする（Ｓ３０）。この接続要求メッセージには、ユーザＢ自身を指定するＳＩＰ−ＵＲＩ（前記「ｕｓｅｒＢ＠…」）と、ユーザＡを指定するＳＩＰ−ＵＲＩ（前記「ｕｓｅｒＡ＠…」）が含まれているため、ＳＩＰバックワードプロキシサーバ１７は、これらのＳＩＰ−ＵＲＩの組と一致する行が前記セキュリティポリシーテーブルＴＢ１に存在するか否かを検査する。

検査の結果、一致する行が存在しなければ、図５に示すステップＳ４２のように、接続を拒否する旨のメッセージを返送することになるが、セキュリティポリシーテーブルＴＢ１が図８に示す通りの状態であるものとすると、行ＬＮ１が一致するため、接続は許可され、接続要求メッセージはユーザＡが利用しているパソコン２１へ届けられる（Ｓ３３）。ユーザＡから接続を許可する旨の応答があれば（Ｓ３３）、その応答の内容がパソコン１３まで伝えられ（Ｓ３４）、パソコン１３とパソコン２１のあいだに呼を設定してユーザＢとユーザＡがＶｏＩＰによる通話を行うことが可能となる。

なお、ステップＳ３０で送信される接続要求メッセージなどは、呼制御メッセージと別個のメッセージとし、呼制御メッセージより前に送信されるものであってもよいが、呼制御メッセージ自体に、ユーザＢ自身を指定するＳＩＰ−ＵＲＩと、ユーザＡを指定するＳＩＰ−ＵＲＩを収容しておけば、パソコン１３は一度、呼制御メッセージを送信するだけでよいので簡便である。

また、セキュリティポリシーテーブルＴＢ１の各行は、その行に登録されている２つのＳＩＰ−ＵＲＩのユーザ間における双方向の発呼を許可するものであってもよいが、図８の例の場合、一方向の発呼のみを認めている。１つの行で一方向の発呼のみを許可するほうが、よりきめ細かく、セキュリティ管理を行うことができる。

図８の場合、例えば、行ＬＮ１でユーザＢからユーザＡへの発呼を許可し、反対に行ＬＮ３では、ユーザＡからユーザＢへの発呼を許可している。この場合、各ユーザ（バディリスト登録元ユーザ）は自身に電話をかけてきてもよいと判断したユーザをバディリスト登録ユーザとして登録することになる。この場合にはまた、例えば、ロケーションサーバ（図示せず）などが管理する情報をもとにユーザＢ（パソコン１３）がＬＡＮ１１の外部に移動したことを検出できた場合、セキュリティ性を高めるために外部からＬＡＮ１５内への発呼を禁止（内部から外部への発呼は許可）したければ、管理者（あるいは、ユーザＡ）などは、セキュリティポリシーテーブルＴＢ１上で行ＬＮ１だけを削除し、行ＬＮ３は残すようにするとよい。

ユーザＡが例えば行ＬＮ１を削除しようとする場合、図３に示すように、パソコン２１から削除要求メッセージを送信し（Ｓ２０）、この削除要求メッセージを受け取ったＳＩＰバックワードプロキシサーバ１７が、前記セキュリティポリシーテーブルＴＢ１上で該当する行ＬＮ１を特定したうえで、その削除を実行し（Ｓ２１）、削除が完了したことを伝える削除完了通知メッセージをユーザＡに返送することになる（Ｓ２２）。なお、この削除要求メッセージを送信できる者は、管理者のほか、バディリスト登録元ユーザ（ここでは、ユーザＡ）またはバディリスト登録ユーザ（ここでは、ユーザＢ）に制限するとよい。

行ＬＮ１が削除された場合、ユーザＢは図５の未登録ユーザＵＸと同様の取り扱いとなるため、削除後にユーザＢがユーザＡに発呼しようとしても、拒否される。

このように、各ユーザが、自身に関連するセキュリティポリシーを管理することにより、管理者の負担は大幅に軽減できるし、各ユーザの事情（上述した、組織が必要とするネットワークの利用法や組織内にあるリソースの量や質、組織の業務内容など各種の複雑な要因、およびそれら要因の変動などを含む）を最もよく知っているのはユーザ自身であるため、各ユーザにセキュリティポリシーを設定（登録）させることによって最も適切なセキュリティポリシーの設定を行うことができる可能性が高い。

また、ここで行われる呼の管理は、パソコン間の管理ではなくユーザ間の管理なので、各ユーザのプレゼンス情報が適切に管理されていれば、ユーザの移動先の電話機（移動先のパソコン）に発呼することも可能である。例えば、ユーザＡがパソコン２１からパソコン２２へ移動し、パソコン２２を利用するようになっていることがプレゼンス情報として管理されていれば、前記セキュリティポリシーテーブルＴＢ１に基づいて、パソコン２２を利用しているユーザＡにユーザＢから着信させることができる。さらに、このとき、セキュリティポリシーテーブルＴＢ１の登録内容をユーザの移動に合わせて変更する必要はないことも、管理を容易なものとすることに寄与する。

前記ステップＳ４２を含む図５は、バディリストテーブル（例えば、ＴＢ２）およびセキュリティポリシーテーブルＴＢ１に登録されていないユーザから発呼して拒否されるケースを示したものあるが、そのステップＳ４０は前記ステップＳ３０に対応し、ステップＳ４１は前記ステップＳ３１に対応するので、その詳しい説明は省略する。

（Ａ−３）第１の実施形態の効果
本実施形態によれば、管理負担の分散と、その管理を行うのに最も適した各ユーザ自身が管理を行うことにより、全体として管理の負担を軽減し、適切な管理の実行を容易にすることが可能となる。

また、本実施形態では、各ユーザによって登録されたバディリストテーブル（例えば、ＴＢ２）の内容が自動的にセキュリティポリシーテーブル（ＴＢ１）に反映され、不審者からの迷惑電話などを防止することができる点で、セキュリティ性や利便性の向上が可能となる。

（Ｂ）第２の実施形態
以下では、本実施形態が第１の実施形態と相違する点についてのみ説明する。

セキュリティポリシーテーブルＴＢ１の登録内容の変更に直結するバディリストテーブル（例えば、ＴＢ２）の登録内容の変更は、真に、その変更を行う権限を有する正当なユーザ（ＴＢ２の場合には、ユーザＡ）にのみ認めるべきであるが、そのためにはユーザ認証が必要となる。第１の実施形態では用意していなかったが、本実施形態では、このようなユーザ認証を行う手段を用意したことを特徴とする。

（Ｂ−１）第２の実施形態の構成および動作
本実施形態にかかるＶｏＩＰ通信システム３０の全体構成例を図１１に示す。

図１１において、当該ＶｏＩＰ通信システム１０は、ＬＡＮ１１と、インターネット１２と、認証装置３１とを備えている。

このうちＬＡＮ１１の内部には、ファイアウオール１４によって分けられた企業内ネットワーク１５と、ＤＭＺ１６が含まれており、ＤＭＺ１６には、ＳＩＰバックワードプロキシサーバ１７と、データベース１８〜２０が配置され、企業内ネットワーク１５の内部には、パソコン２１，２２が配置されている。

また、インターネット１２上にはパソコン１３が配置されている。

さらに、ＳＩＰバックワードプロキシサーバ１７には、認証装置３１が接続されている。

このうち、図１と同じ符号１１〜２２、ＡＰ１を付与した各構成要素の機能は基本的に第１の実施形態と同じなので、その詳しい説明は省略する。

認証装置３１は、バディリストテーブル（例えば、ＴＢ２）の登録内容を変更しようとしてＳＩＰバックワードプロキシサーバ１７にアクセスしてきたユーザ（例えば、ユーザＡ）が、真に、その変更を行う権限を有する正当なユーザであるかを検証することによってユーザ認証を実行する装置である。

認証装置３１の詳細は具体的なユーザ認証の方法によって異なり、例えば、電子証明書などを用いる場合などには、第３者機関（認証機関）がＬＡＮ１６の外部のインターネット１２上などに設置した認証装置と連携する必要が生じることもあるが、その必要がない場合には、認証装置３１の機能は例えばＤＭＺ１６の内部に配置したものだけで実現することもできる。

本実施形態では、ＳＩＰ−ＵＲＩ自体を用いてユーザ認証を行うので、ＤＭＺ１６の内部に配置したものだけで認証装置３１の機能を実現することが可能である。

ＳＩＰ−ＵＲＩ自体の正誤を確認することだけによってユーザ認証を行うようにしてもよいが、本来、ＳＩＰ−ＵＲＩは電子メールアドレスなどと同様、相互に通信する必要のあるユーザ間では伝え合うもので、秘匿性の高い情報ではない。このため、ユーザ認証の実効性を確保するには、暗号技術を併用すること等が必要となる。このようなケースで利用できる暗号技術には様々なものがあり得るが、一例として、公開鍵系の暗号技術を利用することもできる。

例えば、ユーザＡの公開鍵ＢＫＡと、その公開鍵ＢＫＡに対応する秘密鍵ＲＫＡを用意し、秘密鍵ＲＫＡはユーザＡ側に、公開鍵ＢＫＡは認証装置３１側に保管しておき、ユーザＡがユーザ認証を受けるために自身のＳＩＰ−ＵＲＩを送るときには、当該ＳＩＰ−ＵＲＩの値（例えば、前記「ｕｓｅｒＡ＠…」を示す文字コードなど）と当該秘密鍵ＲＫＡの演算結果を送り、ＳＩＰバックワードプロキシサーバ１７経由でこの演算結果を受信した認証装置３１は、前記公開鍵ＢＫＡで当該演算結果を復号し、復号結果として得られた値が前記「ｕｓｅｒＡ＠…」を示す文字コードに一致するか否かを確認する。一致した場合、ユーザ認証はＯＫとなり、一致しなかった場合には、ＮＧとなる。公開鍵ＢＫＡに対応する秘密鍵ＲＫＡの値を知っているのはユーザＡに限られるから、これによってユーザ認証の実効性を確保できる。

また、ユーザ認証を受けるため、ユーザＡがパソコン２１に対して行うＳＩＰ−ＵＲＩ等の入力操作は、ユーザインタフェースの構成に依存する。例えば、ＳＩＰ−ＵＲＩの値も、秘密鍵ＲＫＡの値もパソコン２１に記憶させておいて必要なときに自動的に再利用させる構成とする場合には、特段、入力操作は必要ない。ただしこの場合、厳密には、ユーザの正当性を認証するユーザ認証ではなく、端末（ここでは、パソコン２１）の正当性を認証する端末認証を行っていることになり、パソコン２１が盗まれた場合などには、正当な権限を持たない第３者にセキュリティポリシーテーブルＴＢ１の登録内容を変更されてしまう可能性がある。これに対し、例えば、その都度、秘密鍵ＲＫＡの値をユーザＡに入力させる場合には、ユーザの正当性を認証するユーザ認証を行っていることになるので、真に正当な権限を持つユーザ（例えば、Ａ）のみがセキュリティポリシーテーブルＴＢ１などの登録内容の変更を行うことができる。

以下でも、ユーザＡに注目して説明を進める。

本実施形態の動作シーケンスを図９，図１０に示す。

図９はユーザＡのユーザ認証の結果がＯＫとなる場合の動作シーケンスで、Ｓ６０〜Ｓ６６の各ステップを備えている。図１０はユーザＡのユーザ認証の結果がＮＧとなる場合の動作シーケンスで、Ｓ７０〜Ｓ７３の各ステップを備えている。

ここでは、ユーザＡがバディリストテーブルＴＢ２上で図７に示す行Ｌ１を追加し、それによってセキュリティポリシーテーブルＴＢ１では、図８に示す行ＬＮ１を追加させようとするケースを想定する。

図９に示すように、ユーザＡがパソコン２１からそのためのバディリスト登録要求メッセージを送信する（Ｓ６０）。このバディリスト登録要求メッセージには、ユーザＡのＳＩＰ−ＵＲＩの値と前記秘密鍵ＲＫＡの演算結果が含まれている。

ＳＩＰバックワードプロキシサーバ１７は、当該バディリスト登録要求メッセージから当該演算結果を抽出して、当該演算結果を含む認証要求メッセージを前記認証装置３１に送信する（Ｓ６１）。この認証要求メッセージには、前記演算結果のほか、この認証要求メッセージがユーザＡに関するものであることを伝える識別情報（例えば、ユーザＡの平文のＳＩＰ−ＵＲＩ）が含まれているものであってよい。

これを受信した認証装置３１は、平文のＳＩＰ−ＵＲＩから、ユーザＡの公開鍵ＢＫＡを特定し、当該公開鍵ＢＫＡで前記演算結果を復号する。そして、復号結果としてユーザＡのＳＩＰ−ＵＲＩが得られたことを確認できれば、ユーザ認証の結果はＯＫとなる。このあと、ユーザ認証の結果がＯＫであることを伝える認証応答メッセージが、認証装置３１からＳＩＰバックワードプロキシサーバ１７へ送信される（Ｓ６２）。なお、平文のＳＩＰ−ＵＲＩをネットワーク上に伝送させることを避けるには、認証装置３１とＳＩＰバックワードプロキシサーバ１７のあいだで定めた鍵で、さらに当該平文のＳＩＰ−ＵＲＩなどを暗号化したうえで伝送するようにするとよい。

前記ステップＳ６２の認証応答メッセージから、ユーザ認証の結果がＯＫであったことを認識したＳＩＰバックワードプロキシサーバ１７が実行するステップＳ６３〜Ｓ６６の動作は、図２と同じである。

すなわち、ステップＳ６３は前記ステップＳ１１に対応し、ステップＳ６４は前記ステップＳ１２に対応し、ステップＳ６５は前記ステップＳ１３に対応し、ステップＳ６６は前記ステップＳ１４に対応するので、その詳しい説明は省略する。

結局、認証装置３１によるユーザ認証の結果がＯＫとなる正当な権限を持つユーザＡのみが、バディリストテーブルＴＢ２の登録内容を変更できることになる。

一方、認証装置３１によるユーザ認証の結果がＮＧである場合、図９に示すように、認証装置３１は、ユーザ認証の結果がＮＧであることを伝える拒否応答メッセージを返送してくるため、これを受信したＳＩＰバックワードプロキシサーバ１７は、要求されたバディリストテーブルＴＢ２の登録内容の変更（例えば、新たな行の追加）を拒否する旨の登録拒否通知メッセージをパソコン２１に送信することになる。

なお、図１０において、ステップＳ７０は前記ステップＳ６０に対応し、ステップＳ７１は前記ステップＳ６１に対応するので、その詳しい説明は省略する。

ただし、ユーザ認証の結果がＮＧとなる以上、図１０の場合、ステップＳ７０で送信されたバディリスト登録要求メッセージに含まれる演算結果は、本来の値とは異なるものとなる。これは、ＳＩＰ−ＵＲＩの値と秘密鍵ＲＫＡの少なくともいずれか一方が誤っているためである。

なお、ここでは、バディリストテーブルＴＢ２に新たな行を追加する場合について説明したが、すでにバディリストテーブルＴＢ２に登録されている行を削除する場合など、バディリストテーブルＴＢ２の登録内容を変更する場合にはいつでも、このようなユーザ認証を行うようにすることが望ましい。

また、バディリスト登録元ユーザ（ここでは、ユーザＡ）だけでなく、バディリスト登録ユーザ（ここでは、ユーザＢ）にも、少なくとも自身が関連する行（ここでは、行ＬＮ１）の削除などは許可する構成を取ってもよいと考えられるが、その場合、その削除を要求してきた者が真にユーザＢであることを確認するためのユーザ認証が必要となる。このユーザ認証も、前記ステップＳ６１とＳ６２のあいだで認証装置３１が実行したものと同様な処理であってよい。

なお、ユーザＢからの要求に基づいてセキュリティポリシーテーブルＴＢ１上から行ＬＮ１が削除された場合、それを反映して、バディリストテーブルＴＢ２上で行Ｌ１が削除されるものであってよい。

（Ｂ−２）第２の実施形態の効果
本実施形態によれば、第１の実施形態の効果と同等な効果を得ることができる。

加えて、本実施形態では、セキュリティポリシーテーブル（ＴＢ１）やバディリストテーブル（例えば、ＴＢ２）の登録内容を変更するときにはユーザ認証を実行し、真に、その変更を行う権限を有する正当なユーザにのみ当該変更を許可するため、セキュリティ性が向上する。

（Ｃ）他の実施形態
上記第１、第２の実施形態にかかわらず、前記ＳＩＰ−ＵＲＩの代わりに、他のアプリケーションレベルの識別情報（例えば、ＵＲＬ、ＵＲＮ、電子メールアドレスなど）を用いることができる可能性がある。

なお、上記第１、第２の実施形態で１つの機能として説明したものを別個の機能に分割して別の情報処理装置に搭載してもよく、上記第１、第２の実施形態で異なる機能として説明したものを同一の情報処理装置に搭載してもよい。例えば、ＳＩＰバックワードプロキシサーバ１７とデータベース１８〜２０を１つの情報処理装置に搭載してもよく、ＳＩＰバックワードプロキシサーバ１７と前記認証装置３１の機能を１つの情報処理装置に搭載してもよい。

また、上記第１、第２の実施形態で述べた機能に関する限り、必ずしもＳＩＰバックワードプロキシサーバ１７とＳＩＰサーバの機能が別個のものである必要はない。例えば、ＳＩＰサーバの機能の一部として、上記第１、第２の実施形態で述べたＳＩＰバックワードプロキシサーバ１７の機能を実現するようにしてもよい。

さらに、上記第１、第２の実施形態では、ＬＡＮ１１は企業ＥＲ１のために構築されたものであったが、ＬＡＮ１１がどのような主体のために構築されたものであってもかまわないことは当然である。例えば、ＬＡＮ１１は学校などのために構築されることもあり得る。

なお、上記第１、第２の実施形態におけるパソコン（例えば、２１）は、その他の通信端末（例えば、ワークステーションなど）に置換可能である。

さらにまた、上記第１、第２の実施形態で用いたネットワークの構成を変更することも可能である。例えば、セキュリティ性を高めるために、データベース１８〜２０は企業内ネットワーク１５に配置し、ＳＩＰバックワードプロキシサーバ１７はファイアウオール１４経由でデータベース１８〜２０にアクセスする構成としてもよい。また、必要に応じて、ＤＭＺ１６を省略し、すべての構成要素（例えば、１７〜２２）を企業内ネットワーク１５の内部に配置するようにしてもよい。さらに、インターネット１２は、その他のネットワーク（例えば、特定の通信事業者が運営するＩＰ網など）に置換することも可能である。

なお、図８，図７に示すテーブルＴＢ１，ＴＢ２は必ずしもこれらの図に示した通りの構成を持つものに限定する必要はない。図示したデータ項目を他のデータ項目と置き換えたり、図示したデータ項目に他のデータ項目を追加した構成のテーブルを用いることも可能である。

例えば、図８では、呼の設定が可能なユーザの組を示すＳＩＰ−ＵＲＩの組を、１つのセキュリティポリシーとしたが、ＳＩＰ−ＵＲＩとともに、またはＳＩＰ−ＵＲＩに替えて、その他の情報（例えば、ＵＲＬ、通信プロトコルの種類、通信相手となるコンピュータのホスト名、アドレス、ポート番号など）をセキュリティポリシーとしてもよい。

また、テーブルＴＢ１，ＴＢ２のデータ項目として、該当するユーザ（登録ユーザ（バディリスト登録ユーザ））に関する前記プレゼンス情報などを設けるようにしてもよい。このようなプレゼンス情報は所定のプレゼンスシステム（図示せず）によって収集されるものである。この場合、各ユーザは例えばあるユーザに発呼しようとするとき等、パソコンの画面上に、そのユーザのプレゼンス情報を表示させることができる
さらに、上記第２の実施形態で使用するユーザ認証の方法としては様々なものを利用することが可能である。例えば、ＳＩＰ−ＵＲＩをユーザＩＤとして用いると、ＳＩＰ−ＵＲＩとパスワードを入力させて一般的なユーザＩＤとパスワードによるユーザ認証を行うこともできる。

なお、上記第１、第２の実施形態で用いた通信プロトコルは必要に応じてその他の通信プロトコルに置き換えてもよい。

例えば、ＩＰプロトコルの代わりに、ＩＰＸプロトコルなどを用いることができる可能性がある。

また、ＳＩＰプロトコルの代わりに、前記ＩＴＵ−Ｔ勧告Ｈ．３２３などの呼制御プロトコルを用いることができる可能性がある。

さらに、前記ＶｏＩＰでは音声データの通信を行うが、音声データとともに、または音声データに替えて、その他のマルチメディアデータ（例えば、動画像データなど）を通信する場合にも、本発明は適用可能である。

また、やり取りされるデータが、音声データや動画像データのように、高度なリアルタイム性を要するものであることは、本発明の構成上、必ずしも必須ではない。

以上の説明でハードウエア的に実現した機能の大部分はソフトウエア的に実現することが可能であり、ソフトウエア的に実現した機能のほとんど全ては、ハードウエア的に実現することが可能である。

第１の実施形態にかかるＶｏＩＰ通信システムの全体構成例を示す概略図である。 第１の実施形態の動作例を示すシーケンス図である。 第１の実施形態の動作例を示すシーケンス図である。 第１の実施形態の動作例を示すシーケンス図である。 第１の実施形態の動作例を示すシーケンス図である。 第１の実施形態の動作例を示すシーケンス図である。 第１および第２の実施形態で使用するバディリストテーブルの構成例を示す概略図である。 第１および第２の実施形態で使用するセキュリティポリシーテーブルの構成例を示す概略図である。 第２の実施形態の動作例を示すシーケンス図である。 第２の実施形態の動作例を示すシーケンス図である。 第２の実施形態にかかるＶｏＩＰ通信システムの全体構成例を示す概略図である。

符号の説明

１０…ＶｏＩＰ通信システム、１１…ＬＡＮ、１２…インターネット網、１３、２１，２２…パソコン、１４…ファイアウオール、１５…企業内ネットワーク、１６…ＤＭＺ、１７…ＳＩＰバックワードプロキシサーバ、１８〜２０…データベース、ＴＢ１…セキュリティポリシーテーブル、ＴＢ２…バディリストテーブル。

Claims (4)

1. 開始時に呼設定の過程を伴う通信に関し、呼設定のため呼設定の要求元となる通信端末から送信される呼設定メッセージの記述内容を、予め蓄積した呼設定可否情報と照合することによって呼設定の許可、不許可を決定してアクセス制御を実行するアクセス制御システムにおいて、
   前記呼設定可否情報を蓄積した呼設定可否データベース部を有する呼制御関連サーバと、
   呼設定の要求元または要求先となる通信端末とを備え、
   当該通信端末は、
   当該通信端末を利用するユーザが行う登録内容変更操作に応じて、前記呼設定可否情報を含む所定の登録内容変更要求メッセージを前記呼制御関連サーバに送信し、前記呼設定可否データベース部における当該呼設定可否情報の登録内容を変更させる登録内容変更要求部を有することを特徴とするアクセス制御システム。
2. 請求項１のアクセス制御システムにおいて、
   前記呼制御関連サーバは、
   アプリケーションレベルで前記通信端末またはユーザを一意に識別するアプリケーションレベル識別情報のうち、自呼制御関連サーバにアクセスする正当な通信端末またはユーザを示すアプリケーションレベル識別情報を蓄積したアプリケーションレベル識別情報データベース部と、
   送信元の通信端末またはユーザを示す前記アプリケーションレベル識別情報を含む登録内容変更要求メッセージが届いた場合、当該登録内容変更要求メッセージ中のアプリケーションレベル識別情報を、前記アプリケーションレベル識別情報データベース部に蓄積されたアプリケーションレベル識別情報と照合して当該登録内容変更要求メッセージの送信元の通信端末またはユーザの正当性を検証する認証実行部とを備えたことを特徴とするアクセス制御システム。
3. 開始時に呼設定の過程を伴う通信に関し、呼設定のため呼設定の要求元となる通信端末から送信される呼設定メッセージの記述内容を、予め蓄積した呼設定可否情報と照合することによって呼設定の許可、不許可を決定してアクセス制御を実行するアクセス制御方法において、
   呼制御関連サーバでは、呼設定可否データベース部が前記呼設定可否情報を蓄積し、
   通信端末が、呼設定の要求元または要求先となり、
   当該通信端末は、
   当該通信端末を利用するユーザが行う登録内容変更操作に応じて、前記呼設定可否情報を含む所定の登録内容変更要求メッセージを前記呼制御関連サーバに送信し、前記呼設定可否データベース部における当該呼設定可否情報の登録内容を変更させることを特徴とするアクセス制御方法。
4. 開始時に呼設定の過程を伴う通信に関し、呼設定のため呼設定の要求元となる通信端末から送信される呼設定メッセージの記述内容を、予め蓄積した呼設定可否情報と照合することによって呼設定の許可、不許可を決定してアクセス制御を実行するアクセス制御プログラムにおいて、コンピュータに、
   前記呼設定可否情報を蓄積した呼設定可否データベース機能を有する呼制御関連サーバ機能と、
   呼設定の要求元または要求先となる通信端末機能とを実現させ、
   当該通信端末機能は、
   当該通信端末機能を利用するユーザが行う登録内容変更操作に応じて、前記呼設定可否情報を含む所定の登録内容変更要求メッセージを前記呼制御関連サーバ機能に送信し、前記呼設定可否データベース機能における当該呼設定可否情報の登録内容を変更させる登録内容変更要求機能を有することを特徴とするアクセス制御プログラム。

Images