(57)【要約】【課題】ＩＰｓｅｃやセキュリティポリシーの制御を、機器ではなくユーザ等を単位に行えるようにしたネットワーク機器を提供する。【解決手段】暗号化手段を有し、ネットワークに接続されるネットワーク機器であって、暗号化共有鍵を生成するための処理に際し、イニシエータから当該イニシエータのユーザのＩＤを取得し、データベースを参照してアクセス可能であるか否か判断する手段を備える。【選択図】図２
2007251842.tif 000002
【特許請求の範囲】
【請求項１】
暗号化手段を有し、ネットワークに接続されるネットワーク機器であって、
暗号化共有鍵を生成するための処理に際し、イニシエータから当該イニシエータのユーザのＩＤを取得し、データベースを参照してアクセス可能であるか否か判断する手段を備えたことを特徴とするネットワーク機器。
【請求項２】
請求項１に記載のネットワーク機器において、
上記のＩＤを判断するにあたり、当該ＩＤの一部を利用して登録情報との一致を判断することを特徴とするネットワーク機器。
【請求項３】
請求項１または２のいずれか一項に記載のネットワーク機器において、
レスポンダ側にアクセスコントロールのデータベースを保持することを特徴とするネットワーク機器。
【請求項４】
請求項１または２のいずれか一項に記載のネットワーク機器において、
レスポンダ側にアクセスコントロールのデータベースを保持せず、サーバ機器に対して問い合わせを行い、当該サーバ機器でアクセスコントロールの判断を行い、その結果をレスポンダ側で取得することを特徴とするネットワーク機器。
【請求項５】
請求項１乃至４のいずれか一項に記載のネットワーク機器において、
上記のＩＤをセキュリティポリシーと関連付けて設定する手段を備えたことを特徴とするネットワーク機器。
【請求項６】
請求項５に記載のネットワーク機器において、
上記のＩＤとセキュリティポリシーとの関連付けは、ポート識別子を介して行うことを特徴とするネットワーク機器。
【請求項７】
請求項５または６のいずれか一項に記載のネットワーク機器において、
上記のセキュリティポリシーはアクセスグープごとに設定されていることを特徴とするネットワーク機器。
【請求項８】
暗号化手段を有し、ネットワークに接続されるネットワーク機器のアクセス制御方法であって、
暗号化共有鍵を生成するための処理に際し、イニシエータから当該イニシエータのユーザのＩＤを取得し、データベースを参照してアクセス可能であるか否か判断する工程を備えたことを特徴とするネットワーク機器のアクセス制御方法。
【請求項９】
請求項８に記載のネットワーク機器のアクセス制御方法において、
上記のＩＤを判断するにあたり、当該ＩＤの一部を利用して登録情報との一致を判断することを特徴とするネットワーク機器のアクセス制御方法。
【請求項１０】
請求項８または９のいずれか一項に記載のネットワーク機器のアクセス制御方法において、
レスポンダ側にアクセスコントロールのデータベースを保持することを特徴とするネットワーク機器のアクセス制御方法。
【請求項１１】
請求項８または９のいずれか一項に記載のネットワーク機器のアクセス制御方法において、
レスポンダ側にアクセスコントロールのデータベースを保持せず、サーバ機器に対して問い合わせを行い、当該サーバ機器でアクセスコントロールの判断を行い、その結果をレスポンダ側で取得することを特徴とするネットワーク機器のアクセス制御方法。
【請求項１２】
請求項８乃至１１のいずれか一項に記載のネットワーク機器のアクセス制御方法において、
上記のＩＤをセキュリティポリシーと関連付けて設定する工程を備えたことを特徴とするネットワーク機器のアクセス制御方法。
【請求項１３】
請求項１２に記載のネットワーク機器のアクセス制御方法において、
上記のＩＤとセキュリティポリシーとの関連付けは、ポート識別子を介して行うことを特徴とするネットワーク機器のアクセス制御方法。
【請求項１４】
請求項１２または１３のいずれか一項に記載のネットワーク機器のアクセス制御方法において、
上記のセキュリティポリシーはアクセスグープごとに設定されていることを特徴とするネットワーク機器のアクセス制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰｓｅｃ（Security Architecture for Internet Protocol）やセキュリティポリシーの制御を、機器ではなくユーザ等を単位に行えるようにしたネットワーク機器に関する。
【背景技術】
【０００２】
ＩＰｓｅｃにより通信を暗号化することにより、通信経路上の安全を保つことが可能となってきた。
【０００３】
ＩＰｓｅｃの認証とアクセスコントロールについては、ＩＰｓｅｃの暗号化共有鍵を生成するための処理であるＩＫＥ（Internet Key Exchange）によるＰｈａｓｅ１の処理において、規格上はユーザ名やディレクトリサービスの国際標準であるＸ．５００で規定されたものも利用することができる。
【０００４】
しかし、機器に設定して処理されることを前提としているため、データを振り分ける識別子としては、ＩＰ（Internet Protocol）アドレス、ＭＡＣ（Media Access Control）アドレスが前提とされている。
【０００５】
同様に、ＩＰｓｅｃのアクセスデータベースとしてもＩＰアドレスで振り分けることが規格上指示されている。
【０００６】
なお、出願人は出願時点までに本発明に関連する公開された先行技術文献を発見することができなかった。よって、先行技術文献情報を開示していない。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上述したように、従来はＩＰアドレスもしくはＭＡＣアドレスが管理上の識別子として用いられていたため、本人認証として認証されるＩＫＥの部分では、機器が正しいことは確保されているが、それを使うユーザが正しいことは確保できていない。
【０００８】
このため、例えば一人のユーザが複数の機器をもって処理する場合、それらの機器による通信におけるアクセスコントロール、セキュリティポリシーを同一に保つためには、機器ごとに同じ設定をしなければならず、作業が煩雑であるとともに、保守性が悪くなるという問題があった。
【０００９】
また、ＩＰｖ６（Internet Protocol version 6）においてはＩＰアドレスを複数用いた運用がなされるが、ＩＰアドレスごとによるＩＰｓｅｃのＳＡ（Security Association）経路の管理、アクセスコントロールを実施する場合、複数の証明書や、共通鍵を用意しなければならず、煩雑になるという問題があった。
【００１０】
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、ＩＰｓｅｃやセキュリティポリシーの制御を、機器ではなくユーザ等を単位に行えるようにしたネットワーク機器を提供することにある。
【課題を解決するための手段】
【００１１】
上記の課題を解決するため、本発明にあっては、請求項１に記載されるように、暗号化手段を有し、ネットワークに接続されるネットワーク機器であって、暗号化共有鍵を生成するための処理に際し、イニシエータから当該イニシエータのユーザのＩＤを取得し、データベースを参照してアクセス可能であるか否か判断する手段を備えるネットワーク機器を要旨としている。
【００１２】
また、請求項２に記載されるように、請求項１に記載のネットワーク機器において、上記のＩＤを判断するにあたり、当該ＩＤの一部を利用して登録情報との一致を判断するようにすることができる。
【００１３】
また、請求項３に記載されるように、請求項１または２のいずれか一項に記載のネットワーク機器において、レスポンダ側にアクセスコントロールのデータベースを保持するようにすることができる。
【００１４】
また、請求項４に記載されるように、請求項１または２のいずれか一項に記載のネットワーク機器において、レスポンダ側にアクセスコントロールのデータベースを保持せず、サーバ機器に対して問い合わせを行い、当該サーバ機器でアクセスコントロールの判断を行い、その結果をレスポンダ側で取得するようにすることができる。
【００１５】
また、請求項５に記載されるように、請求項１乃至４のいずれか一項に記載のネットワーク機器において、上記のＩＤをセキュリティポリシーと関連付けて設定する手段を備えるようにすることができる。
【００１６】
また、請求項６に記載されるように、請求項５に記載のネットワーク機器において、上記のＩＤとセキュリティポリシーとの関連付けは、ポート識別子を介して行うようにすることができる。
【００１７】
また、請求項７に記載されるように、請求項５または６のいずれか一項に記載のネットワーク機器において、上記のセキュリティポリシーはアクセスグープごとに設定されているものとすることができる。
【００１８】
また、請求項８〜１４に記載されるように、ネットワーク機器のアクセス制御方法として構成することができる。
【発明の効果】
【００１９】
本発明のネットワーク機器にあっては、ＩＰｓｅｃやセキュリティポリシーの制御を、機器ではなくユーザ等を単位に行うことができ、ユーザ毎に個別に通信経路を暗号化し、個人毎の情報のコントロールが可能となる。これにより、複数の機器を利用するユーザであっても、どの機器からのアクセスでも同じアクセスコントロールおよびセキュリティポリシーの適応が可能となる。また、登録されたＩＤ１つで、利用する機器に対して安全な通信経路の利用ができる。
【発明を実施するための最良の形態】
【００２０】
以下、本発明の好適な実施形態につき説明する。
【００２１】
図１は本発明のネットワーク機器を用いたネットワークシステムの一実施形態を示す全体構成図である。
【００２２】
図１において、ネットワーク３上にはネットワーク機器１Ａ、１Ｂと外部サーバ２が接続されている。なお、後述する動作説明との関係から、ネットワーク機器１Ａはイニシエータ、ネットワーク機器１Ｂはレスポンダと示してあるが、逆になる場合もある。また、同一のネットワーク３上に限らず、ルータ等を介して他のセグメントにあるネットワーク機器と通信することも可能である。
【００２３】
図２はレスポンダ側のネットワーク機器１Ｂの内部構成例を示す図である。
【００２４】
図２において、ネットワーク機器１Ｂは、処理において参照もしくは更新する各種のデータベースＤ１〜Ｄ５を備えている。なお、データベースＤ１〜Ｄ５は機器内部に設けてもよいし、ネットワーク上のサーバ等に設けてもよい。
【００２５】
ネットワーク機器１Ｂは、ＩＫＥのＰｈａｓｅ１の処理を行うＰｈａｓｅ１処理部１１と、Ｐｈａｓｅ１処理部１１内にあって、イニシエータから送られたユーザを示すＩＤに基づいてアクセス条件の確認を行うアクセス条件確認部１２とを備えている。
【００２６】
また、ＩＫＥのＰｈａｓｅ１処理の後に、セキュリティポリシー適用のためにユーザのＩＤとポートとの関連付けを行うＩＤ／ポート関連付け設定部１３と、ＩＫＥのＰｈａｓｅ２の処理を行うＰｈａｓｅ２処理部１４と、ＩＫＥのＰｈａｓｅ１、Ｐｈａｓｅ２の処理により設定された情報に基づいてＩＰｓｅｃ通信を行うＩＰｓｅｃ通信処理部１５とを備えている。
【００２７】
図３はＩＤデータベースＤ１の例を示す図であり、レコード番号と、ユーザのＩＤと、公開鍵とを対応付けて保持している。
【００２８】
図４はアクセスデータベースＤ２の例を示す図であり、ユーザのＩＤと、アクセス条件＃１と、アクセス条件＃２とを対応付けて保持している。ここではアクセス条件＃１としてアクセス時間帯を規定し、アクセス条件＃２として機器の状態を規定しているが、別のアクセス条件を規定してもよい。
【００２９】
図５はグループセキュリティポリシーデータベースＤ３の例を示す図であり、ルール番号と、Ｘ．５００等で規定される送信元（グループ）の識別子と、通信の識別ポートと、動作と、フィルタと、セキュリティプロトコル等の設定とを対応付けて保持している。
【００３０】
図６はＩＤ／グループ対応データベースＤ４の例を示す図であり、ユーザのＩＤと、グループとを対応付けて保持している。
【００３１】
図７はＩＰｓｅｃアクセスデータベースＤ５の例を示す図であり、ルール番号と、送信元の識別子と、識別ポートと、動作と、フィルタと、セキュリティプロトコル等の設定とを対応付けて保持している。
【００３２】
図８は上記の実施形態の全体的な処理例を示すフローチャートである。
【００３３】
図８において、処理を開始すると（ステップＳ１０１）、先ずＩＫＥのＰｈａｓｅ１の処理を行う（ステップＳ１０２）。
【００３４】
その後、ユーザのＩＤとポートとの関連付けを行う（ステップＳ１０３）。
【００３５】
その後、ＩＫＥのＰｈａｓｅ２の処理を行う（ステップＳ１０４）。
【００３６】
そして、Ｐｈａｓｅ１、Ｐｈａｓｅ２の処理により設定された情報に基づいてＩＰｓｅｃ通信を行い（ステップＳ１０５）、処理を終了する（ステップＳ１０６）。
【００３７】
図９はデジタル証明の認証Ａｇｇｒｅｓｓｉｖｅ  ＭｏｄｅによるＩＫＥ  Ｐｈａｓｅ１の処理例を示すシーケンス図であり、図１０はＩＫＥ  Ｐｈａｓｅ１におけるレスポンダ側のネットワーク機器１Ｂの処理例を示すフローチャートである。なお、図９において網掛けした部分は暗号化されていることを示している。
【００３８】
図９および図１０において、イニシエータ側のネットワーク機器１Ａから認証のデータとしてイニシエータのユーザを特定するＩＤを含むデータ（ＳＡパラメータの提案）が送信される（ステップＳ１１１）。
【００３９】
レスポンダ側のネットワーク機器１Ｂは処理を開始し（ステップＳ１１２）、そのＩＤによりＩＤデータベースＤ１を検索し（ステップＳ１１３）、ＩＤが存在するかどうか判断する（ステップＳ１１４）。
【００４０】
ＩＤが存在する場合、アクセスデータベースＤ２を検索し（ステップＳ１１５）、ＩＤを比較することによりアクセス条件に当てはまるかどうか判断する（ステップＳ１１６）。図４に示したアクセスデータベースＤ２の例では、例えば、「hogehoge」というＩＤのイニシエータが、ＩＫＥのＩＳＫＭＰ（Internet Security Association Key Management Protocol）のパケットを送ってきた場合、現在時刻が９：００〜１８：００であり、レスポンダがスタンバイの状態であったときのみ、ＩＰｓｅｃによるアクセスを許可する。この条件以外の場合はアクセスを拒否する。
【００４１】
図９および図１０に戻り、アクセス条件に当てはまる場合、アクセス許可のコマンド（ＳＡパラメータの提案）をイニシエータ側のネットワーク機器１Ａに送信する（ステップＳ１１７）。
【００４２】
次いで、イニシエータ側のネットワーク機器１Ａから秘密鍵で署名したイニシエータのＩＤおよび証明書情報を受信する（ステップＳ１１８）。このとき、レスポンダはこのＩＤに対する本人性確認をするために、このＩＤに対するハッシュ値の計算を実施し、この送付されたＩＤとレスポンダ側が保持するＩＤとその公開鍵とで署名が正しいかどうかを確認することにより本人認証を実施し、Ｐｈａｓｅ１の処理を終了する（ステップＳ１２０）。これにより、続くＰｈａｓｅ２以降で実際の暗号化通信を実施できるようにすることが可能となる。予めＩＤに対してアクセスコントロールを設定することにより、以降時間のかかるＩＰｓｅｃのための共通鍵の作成計算を必要としないアクセスコントロールを実施することができる。
【００４３】
また、ＩＤが存在しなかった場合もしくはアクセス条件に当てはまらなかった場合は、アクセス破棄のコマンドを送信し（ステップＳ１１９）、処理を終了する（ステップＳ１２０）。
【００４４】
一方、上記のレスポンダでの処理におけるＩＤデータベースＤ１もしくはアクセスデータベースＤ２の検索においては、ＩＤが完全に一致しない場合であっても次のように処理することができる。すなわち、図３のＩＤデータベースＤ１においては「saru@banana.com」のように名前付きＦＱＤＮ（Fully Qualified Domain Name）で指定されており、図４のアクセスデータベースＤ２では「banana.com」のようにドメイン名のみが指定されている場合がある。この場合、完全一致ではないが、ドメイン名が一致したユーザに対しては図４のアクセスデータベースＤ２に示される内容でアクセスできるようにする。その他、Ｘ．５００で定義されたＤＮ（Distinguished Name）、ＦＱＤＮ等についても同様である。
【００４５】
また、上記のレスポンダでの処理におけるＩＤデータベースＤ１、アクセスデータベースＤ２をレスポンダに保持せずに、図１に示した外部サーバ２に保持させることができる。この場合、イニシエータからＩＫＥのデータ通信があった場合、アクセスされたＩＤを外部サーバ２に対して送付する。外部サーバ２は、ＩＤデータベースＤ１およびアクセスデータベースＤ２を保持してあり、その内容と照らし合わせて、アクセス可能かどうかの結果をレスポンダに返す。レスポンダはその結果によりＩＰｓｅｃの処理を提供する。これにより、レスポンダ側のネットワーク機器１Ｂでは外部サーバ２を指定するだけでレスポンダ側へのアクセスコントロールを実現することができる。
【００４６】
図１１はＩＤ／ポート関連付けの処理例を示すシーケンス図である。Ｐｈａｓｅ１が終了し、イニシエータ、レスポンダのお互いの認証が終了したときに、お互いの認証と同時に、認証されたものからセキュリティポリシーを参照する。例えば、あるＩＰアドレスやＩＰアドレスのサブネットとの通信には、ＴＣＰ（Transmission Control Protocol）のみをＩＰｓｅｃにしたり、ＴＣＰのあるポートのみをＩＰｓｅｃしたりすることでアクセスコントロールを実施することができる。
【００４７】
図１１において、イニシエータ側のネットワーク機器１ＡからＣｏｎｆｉｕｒａｔｉｏｎ  Ｍｅｔｈｏｄによって、Ｐｈａｓｅ１のＩＤとＵＤＰ（User Datagram Protocol）等のポート番号を送信する（ステップＳ１２１）。
【００４８】
レスポンダ側のネットワーク機器１Ｂでは、グループセキュリティポリシーデータベースＤ３（図５）およびＩＤ／グループ対応データベースＤ４（図６）を参照することで、ユーザのＩＤと識別ポートとの対応関係を把握し、ＩＰｓｅｃアクセスデータベースＤ５（図７）を生成する。そして、レスポンダ側のネットワーク機器１Ｂはレスポンスを発し（ステップＳ１２２）、イニシエータ側のネットワーク機器１Ａはそのレスポンスを受け取る。
【００４９】
これにより、ＩＰアドレスやＩＰアドレスのサブネットとは別に、ＩＰｓｅｃによるＳＡを、ＩＤとＵＤＰポートを関連図けることにより、ＩＤによる識別を可能とする。図１２はＵＤＰヘッダを付加したＩＰｓｅｃパケットの例を示す図であり、このパケットをＩＰｓｅｃのＳＡとして処理する。通常ＩＰｓｅｃの識別には、ＩＰアドレスを利用するが、ＩＫＥで認証した識別子に対して、ＩＰｓｅｃ上でもユーザによるアクセスコントロールを実現することができる。また、アクセスコントロールをグループ毎に管理することができる。なお、ＴＣＰにも同様に適用することができる。
【００５０】
図１３はＩＫＥ  Ｐｈａｓｅ２の処理例を示すシーケンス図である。
【００５１】
図１３において、イニシエータ側のネットワーク機器１ＡからＳＡパラメータの提案を行い（ステップＳ１３１）、レスポンダ側のネットワーク機器１Ｂはこれを受け取る。
【００５２】
次いで、レスポンダ側のネットワーク機器１ＢからもＳＡパラメータの提案を行い（ステップＳ１３２）、イニシエータ側のネットワーク機器１Ａはこれを受け取る。
【００５３】
次いで、イニシエータ側のネットワーク機器１ＡからイニシエータのＩＤおよび認証情報を送信し（ステップＳ１３３）、Ｐｈａｓｅ２の処理を終了する。
【００５４】
その後、上述したＩＰｓｅｃアクセスデータベースＤ５（図７）の内容に基づき、ＩＰｓｅｃ通信が行われる。
【００５５】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【図面の簡単な説明】
【００５６】
【図１】本発明のネットワーク機器を用いたネットワークシステムの一実施形態を示す全体構成図である。
【図２】レスポンダ側のネットワーク機器の内部構成例を示す図である。
【図３】ＩＤデータベースの例を示す図である。
【図４】アクセスデータベースの例を示す図である。
【図５】グループセキュリティポリシーデータベースの例を示す図である。
【図６】ＩＤ／グループ対応データベースの例を示す図である。
【図７】ＩＰｓｅｃアクセスデータベースの例を示す図である。
【図８】実施形態の全体的な処理例を示すフローチャートである。
【図９】ＩＫＥ  Ｐｈａｓｅ１の処理例を示すシーケンス図である。
【図１０】ＩＫＥ  Ｐｈａｓｅ１におけるレスポンダ側のネットワーク機器の処理例を示すフローチャートである。
【図１１】ＩＤ／ポート関連付けの処理例を示すシーケンス図である。
【図１２】ＵＤＰヘッダを付加したＩＰｓｅｃパケットの例を示す図である。
【図１３】ＩＫＥ  Ｐｈａｓｅ２の処理例を示すシーケンス図である。
【符号の説明】
【００５７】
１Ａ、１Ｂ    ネットワーク機器
１１          Ｐｈａｓｅ１処理部
１２          アクセス条件確認部
１３          ＩＤ／ポート関連付け設定部
１４          Ｐｈａｓｅ２処理部
１５          ＩＰｓｅｃ通信処理部
Ｄ１          ＩＤデータベース
Ｄ２          アクセスデータベース
Ｄ３          グループセキュリティポリシーデータベース
Ｄ４          ＩＤ／グループ対応データベース
Ｄ５          ＩＰｓｅｃアクセスデータベース
２            外部サーバ
３            ネットワーク
【図１】
2007251842.tif 000003
【図２】
2007251842.tif 000004
【図３】
2007251842.tif 000005
【図４】
2007251842.tif 000006
【図５】
2007251842.tif 000007
【図６】
2007251842.tif 000008
【図７】
2007251842.tif 000009
【図８】
2007251842.tif 000010
【図９】
2007251842.tif 000011
【図１０】
2007251842.tif 000012
【図１１】
2007251842.tif 000013
【図１２】
2007251842.tif 000014
【図１３】
2007251842.tif 000015