(57)【要約】  本発明は、ネットワークリソースの管理において、そのネットワークリソースに対する操作の可否を、所望の精度でかつより低コストで制御する情報処理システムを提供する。その情報処理システムは、操作主体によって呼び出された、ネットワークリソースを制御するための、ＡＰＩの実行の可否を、その操作主体とその操作主体が操作を許可されたそのネットワークリソースの集合であるテナントとその操作主体による実行が許可されたＡＰＩとの対応に基づいて判定し、その判定の結果に基づいてそのＡＰＩの実行を制御する手段を備える。
2016013200.tif 000002
【特許請求の範囲】
【請求項１】
操作主体によって呼び出された、ネットワークリソースを制御するための、アプリケーションプログラミングインタフェースの実行の可否を、前記操作主体と前記操作主体が操作を許可された前記ネットワークリソースの集合であるテナントとの対応を示す第１のポリシと前記操作主体と前記操作主体による実行が許可されたアプリケーションプログラミングインタフェースとの対応を示す第２のポリシとに基づいて判定し、前記判定された前記実行の可否に基づいて前記アプリケーションプログラミングインタフェースの実行を、前記アプリケーションプログラミングインタフェースを実行する手段へ指示する実行可否判定手段を含む
情報処理システム。
【請求項２】
前記第１のポリシは、前記テナントに属する前記ネットワークリソースのそれぞれの使用量の制限値をさらに含み、
前記実行可否判定手段は、前記テナントに結びつけられた前記ネットワークリソースの使用量の予測値が前記制限値を逸脱する場合、前記アプリケーションプログラミングインタフェースの実行を不可と判定する、
ことを特徴とする請求項１記載の情報処理システム。
【請求項３】
前記制限値は、前記操作主体ごとに設定される
ことを特徴とする請求項２記載の情報処理システム。
【請求項４】
前記第１のポリシ及び前記第２のポリシの少なくともいずれかひとつを記憶するポリシ記憶手段と、
前記ポリシ記憶手段に記憶される前記第１のポリシ及び前記第２のポリシを入力する手段と、をさらに含む
ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
【請求項５】
前記実行可否判定手段が、前記操作主体によって呼び出された、前記ネットワークの前記ネットワークリソースを制御するための、前記アプリケーションプログラミングインタフェースの実行の可否を、不可と判定した場合に、前記判定した結果に係る、前記第１のポリシ及び前記第２のポリシに含まれる情報を出力する手段をさらに含む
ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理システム。
【請求項６】
前記第１のポリシは、前記アプリケーションプログラミングインタフェースを実行する手段であるネットワーク制御装置を前記操作主体とする情報を含み、
前記実行可否判定手段は、さらに前記ネットワーク制御装置による前記アプリケーションプログラミングインタフェースの実行の可否を判定する
ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理システム
【請求項７】
情報処理システムにおいて、操作主体によって呼び出された、ネットワークリソースを制御するための、アプリケーションプログラミングインタフェースの実行の可否を、判定するために使用され、
前記ネットワークに係る、コントローラ、スイッチ、諸元及びケーパビリティのそれぞれにおける、任意の前記ネットワークリソースの集合であるテナントと、前記テナントに含まれる前記ネットワークリソースに対する操作を許可された前記操作主体と、を多対多で関連付け、
前記アプリケーションプログラミングインタフェースと、前記アプリケーションプログラミングインタフェースの実行を許可された前記操作主体と、を多対多で関連付ける
データ構造。
【請求項８】
操作主体によって呼び出された、ネットワークリソースを制御するための、アプリケーションプログラミングインタフェースの実行の可否を、前記操作主体と前記操作主体が操作を許可された前記ネットワークリソースの集合であるテナントとの対応を示す第１のポリシと前記操作主体と前記操作主体による実行が許可されたアプリケーションプログラミングインタフェースとの対応を示す第２のポリシとに基づいて判定し、
前記判定された前記実行の可否に基づいて前記アプリケーションプログラミングインタフェースの実行を、前記アプリケーションプログラミングインタフェースを実行する手段へ指示する
ネットワークリソース管理方法。
【請求項９】
操作主体によって呼び出された、ネットワークリソースを制御するための、アプリケーションプログラミングインタフェースの実行の可否を、前記操作主体と前記操作主体が操作を許可された前記ネットワークリソースの集合であるテナントとの対応を示す第１のポリシと前記操作主体と前記操作主体による実行が許可されたアプリケーションプログラミングインタフェースとの対応を示す第２のポリシとに基づいて判定し、
前記判定された前記実行の可否に基づいて前記アプリケーションプログラミングインタフェースの実行を、前記アプリケーションプログラミングインタフェースを実行する手段へ指示する処理をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な非一時的記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークリソースを操作することの可否を制御する技術に関する。
【背景技術】
【０００２】
近年、Ｓｏｆｔｗａｒｅ  Ｄｅｆｉｎｅｄ  Ｎｅｔｗｏｒｋ（ＳＤＮ）と呼ばれる技術が開発されている。ＳＤＮは、ハードウェア的に構築される固定的なネットワークとは異なり、ネットワークを管理するコントローラのソフトウェア及びそのコンフィギュレーションによって、そのネットワークの構成変更や機能の拡張を可能にする技術の総称である。また、ＳＤＮは、その技術によって構築されたネットワークの総称でもある。【０００３】
ＳＤＮのひとつとして、ＯｐｅｎＦｌｏｗと呼ばれる技術が提案されている。非特許文献１及び２は、ＯｐｅｎＦｌｏｗの特徴及びＯｐｅｎＦｌｏｗスイッチの仕様を開示する。【０００４】
ＯｐｅｎＦｌｏｗの特徴は、コントロールプレーン（ネットワークの経路制御などの機能）とデータプレーン（パケット転送制御の機能）とを分離したことにある。ＯｐｅｎＦｌｏｗは、ＯｐｅｎＦｌｏｗコントローラと複数のＯｐｅｎＦｌｏｗスイッチとから構成される。そのＯｐｅｎＦｌｏｗスイッチは、ＯｐｅｎＦｌｏｗコントローラからの指示に従って、パケットの転送を行う。【０００５】
具体的には、そのＯｐｅｎＦｌｏｗスイッチは、Ｆｌｏｗテーブルと呼ばれる、パケットの転送のルールを内部に保有している。そして、そのＦｌｏｗテーブルには、複数の、Ｆｌｏｗエントリと呼ばれる、パケットの転送ルールが記録されている。１つのそのＦｌｏｗエントリは、マッチフィールドとアクションフィールドとから構成される。そのマッチフィールドは、ＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）アドレスやＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレスなどの条件を指定するフィールドである。また、そのアクションフィールドは、転送や破棄などの動作を指定するフィールドである。【０００６】
そのＯｐｅｎＦｌｏｗスイッチは、パケットを受信した場合に、Ｆｌｏｗテーブルの中からそのパケットにマッチするＦｌｏｗエントリを探索する。それから、そのＯｐｅｎＦｌｏｗスイッチは、そのパケットにマッチするＦｌｏｗエントリを検出した場合、そのＦｌｏｗエントリで指定されるアクションを実行する。【０００７】
そのパケットにマッチするＦｌｏｗエントリを検出できなければ、そのＯｐｅｎＦｌｏｗスイッチは、ＯｐｅｎＦｌｏｗコントローラへ、問い合わせ（Ｐａｃｋｅｔ＿ｉｎメッセージ）を送信する。【０００８】
ＯｐｅｎＦｌｏｗコントローラは、受信したＰａｃｋｅｔ＿ｉｎメッセージに応じて、Ｐａｃｋｅｔ＿ｏｕｔメッセージや、Ｆｌｏｗ＿ｍｏｄメッセージをＯｐｅｎＦｌｏｗスイッチに送信する。ここで、そのＰａｃｋｅｔ＿ｏｕｔメッセージは、パケットの送信（転送）を指示する命令である。また、Ｆｌｏｗ＿ｍｏｄメッセージは、ＯｐｅｎＦｌｏｗスイッチのＦｌｏｗテーブルにＦｌｏｗエントリの追加を指示する命令である。【０００９】
次に、ＯｐｅｎＦｌｏｗスイッチは、ＯｐｅｎＦｌｏｗコントローラから受信したメッセージに従って、そのパケットの転送やＦｌｏｗエントリの追加を行う。【００１０】
上述したＯｐｅｎＦｌｏｗコントローラは、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ）をアプリケーションや管理者など（以後、操作主体とも呼ぶ）向けに提供する。そして、それらの操作主体は、そのＯｐｅｎＦｌｏｗコントローラに、そのＡＰＩ経由で命令を送ることにより、ネットワークリソースを操作する。【００１１】
しかしながら、上記の非特許文献１及び非特許文献２に開示された技術においては、ＯｐｅｎＦｌｏｗのＡＰＩの実行可否の判断を行っていないため、セキュリティのリスクがあるという問題点があった。【００１２】
このような問題点を解決する技術が、非特許文献３及び非特許文献４に記載されている。【００１３】
例えば、既存のコンピュータのオペレーティングシステムは、ファイルなどへのアクセス権限を管理し、各ユーザに許される操作を制限する。こうすることで、そのオペレーティングシステムは、悪意のあるユーザがいた場合でもその影響範囲を限定できる。この概念を、ＯｐｅｎＦｌｏｗコントローラのＡＰＩに適用することにより、ＯｐｅｎＦｌｏｗのセキュリティリスクを低減することが可能である。【００１４】
例えば、非特許文献３は、ＯｐｅｎＦｌｏｗのアプリケーション（操作主体）に対して、利用可能な権限を割り当てて制御する技術を開示する。【００１５】
また非特許文献４は、署名によってＯｐｅｎＦｌｏｗのアプリケーションを認証する技術と、ルールのコンフリクトをアプリケーションの優先度によって解決する技術と、を開示する。【００１６】
特許文献１は、ドメインベースのＡｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｌｉｓｔ（ＡＣＬ）と役割ベースのアクセス制御ポリシであるＲｏｌｅ  Ｂａｓｅｄ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ（ＲＢＡＣ）とを開示する。【００１７】
ＡＣＬ及びＲＢＡＣは、一般的にアクセス制御に使われるポリシである。【００１８】
ＡＣＬは、操作主体（サブジェクト）、操作対象（オブジェクト）及び操作（アクション）ごとに、許可・禁止を指定するルールを有する。【００１９】
ＲＢＡＣは、ＡＣＬにおける上述の問題を、ロール（Ｒｏｌｅ）と呼ばれる概念を用いることで解決する。ロールは、オブジェクトとアクションの組の集合、すなわち、どのリソース（オブジェクト）にどのような操作ができるかという情報の集合である。ＲＢＡＣのポリシは、そのロールがサブジェクトに割り当てられることで、そのサブジェクトの持つ権限を表現するルールを有する。【００２０】
ＡＣＬでは、権限の変更をする場合は、複数のＡＣＬを書き換える必要がある。しかし、ＲＢＡＣでは、権限に変更があった場合に、Ｒｏｌｅの定義のみを変更すれば良いため、ＲＢＡＣの管理負荷は、ＡＣＬのそれに比べて小さい。例えば、特定の事業部の従業員に特定のサーバへのアクセスを許可する場合、ＡＣＬでは、その特定の事業部のすべての従業員のＡＣＬを書き換える必要があるが、ＲＢＡＣでは、その特定の事業部のロールにその特定のサーバのアクセス権を加えるだけでよい。
【先行技術文献】
【特許文献】
【００２１】
【特許文献１】特表２００９−５３９１８３号公報
【非特許文献】
【００２２】
【非特許文献１】Nick McKeown et al.“OpenFlow: Enabling Innovation in Campus Networks” SIGCOMM Computer Communication Review 38、ACM、２００８年、pages 69-74
【非特許文献２】“OpenFlow Switch Specification” Version 1.1.0 Implemented (Wire Protocol 0X02)、［ｏｎｌｉｎｅ］、［平成２４（２０１２）年６月２１日検索］、インターネット〈URL:http://www.openflow.org/documents/openflow-spec-v1.1.0.pdf〉
【非特許文献３】Xitao Wen et al.“Towards a Secure Controller Platform for OpenFlow Applications”HotSDN'13 Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking、ACM、２０１３年8月１６日、pages 171-172
【非特許文献４】Phillip Porras et al. “A Security Enforcement Kernel for OpenFlow Networks”HotSDN '12 Proceedings of the first workshop on Hot topics in software defined networks、ACM、２０１２年8月１３日、Pages 121-126
【発明の概要】
【発明が解決しようとする課題】
【００２３】
ネットワークリソースの管理において、そのネットワークリソースに対する操作の可否を、所望の精度でかつより低コストで制御するという課題がある。【００２４】
非特許文献３及び非特許文献４に開示される技術は、「どのアプリケーション／管理者」による、「どのネットワークリソース」に対する、「どの操作」を、許可するか禁止するかを個別に制御することができない。即ち、非特許文献３及び非特許文献４に開示される技術は、操作主体（アプリケーション／管理者）とネットワークリソースと操作との組み合わせごとに、個々のＡＰＩの実行（ネットワークリソースの制御）の可否を制御することができない。換言すると、非特許文献３及び非特許文献４に開示される技術は、必ずしも、所望の精度でネットワークリソースの制御をできるとは限らないという問題点を有する。【００２５】
その理由は、非特許文献３及び非特許文献４に開示される技術が「どのネットワークリソース」という観点を考慮していないからである。【００２６】
特許文献１に開示されるＡＣＬ及びＲＢＡＣは、例えばＳＤＮのようなダイナミックに構成が変わる環境において、ロールのメンテナンスにコストが掛かるという問題点がある。【００２７】
その理由は、前述したように、ＡＣＬが、サブジェクトとオブジェクトとアクションとの組ごとに、個別に許可・禁止を指定するからである。また、その理由は、ＲＢＡＣが、ロールがオブジェクトとアクションとの組、即ちリソースごとにアクションが記述された情報、の集合だからである。即ち、このようなロールは、コントローラの機能拡張により、新たなアクションの追加やアクションの種類の統廃合などがあった場合、すべてのロールのサブジェクトとアクションとの組がチェックされ、関連するポリシが更新されなければならないからである。【００２８】
本発明の目的は、そのネットワークリソースに対する操作の可否を、所望の精度でかつより低コストで制御するという課題を解決する情報処理システム、ネットワークリソース管理方法及びそのためのプログラム或いはそのプログラムを記録したコンピュータ読み取り可能な非一時的記録媒体を提供することにある。
【課題を解決するための手段】
【００２９】
本発明の一様態における情報処理システムは、操作主体によって呼び出された、ネットワークリソースを制御するための、アプリケーションプログラミングインタフェースの実行の可否を、前記操作主体と前記操作主体が操作を許可された前記ネットワークリソースの集合であるテナントとの対応を示す第１のポリシと前記操作主体と前記操作主体による実行が許可されたアプリケーションプログラミングインタフェースとの対応を示す第２のポリシとに基づいて判定し、前記判定された前記実行の可否に基づいて前記アプリケーションプログラミングインタフェースの実行を、前記アプリケーションプログラミングインタフェースを実行する手段へ指示する実行可否判定手段を含む。【００３０】
本発明の一様態におけるネットワークリソース管理方法は、操作主体によって呼び出された、ネットワークリソースを制御するための、アプリケーションプログラミングインタフェースの実行の可否を、前記操作主体と前記操作主体が操作を許可された前記ネットワークリソースの集合であるテナントとの対応を示す第１のポリシと前記操作主体と前記操作主体による実行が許可されたアプリケーションプログラミングインタフェースとの対応を示す第２のポリシとに基づいて判定し、前記判定された前記実行の可否に基づいて前記アプリケーションプログラミングインタフェースの実行を、前記アプリケーションプログラミングインタフェースを実行する手段へ指示する。【００３１】
本発明の一様態におけるデータ構造は、情報処理システムにおいて、操作主体によって呼び出された、ネットワークリソースを制御するための、アプリケーションプログラミングインタフェースの実行の可否を、判定するために使用され、
前記ネットワークに係る、コントローラ、スイッチ、諸元及びケーパビィティのそれぞれにおける、任意の前記ネットワークリソースの集合であるテナントと、前記テナントに含まれる前記ネットワークリソースに対する操作を許可された前記操作主体と、を多対多で関連付け、
前記アプリケーションプログラミングインタフェースと、前記アプリケーションプログラミングインタフェースの実行を許可された前記操作主体と、を多対多で関連付ける。【００３２】
本発明の一様態におけるコンピュータ読み取り可能な非一時的記録媒体は、操作主体によって呼び出された、ネットワークリソースを制御するための、アプリケーションプログラミングインタフェースの実行の可否を、前記操作主体と前記操作主体が操作を許可された前記ネットワークリソースの集合であるテナントとの対応を示す第１のポリシと前記操作主体と前記操作主体による実行が許可されたアプリケーションプログラミングインタフェースとの対応を示す第２のポリシとに基づいて判定し、前記判定された前記実行の可否に基づいて前記アプリケーションプログラミングインタフェースの実行を、前記アプリケーションプログラミングインタフェースを実行する手段へ指示する処理をコンピュータに実行させるプログラムを記録する。
【発明の効果】
【００３３】
本発明は、ネットワークリソースの制御機能を提供するＡＰＩの実行可否制御を、より低コストで、操作主体とネットワークリソースと操作との組み合わせごとに実現することが可能になる。
【図面の簡単な説明】
【００３４】
【図１】本発明の第１の実施形態に係るネットワークリソース管理システムの構成を示すブロック図である。
【図２】本発明の第１の実施形態におけるネットワークリソース管理システムを含む情報処理システムの構成を示すブロック図である。
【図３】第１の実施形態におけるリソース操作権限ポリシの論理構造の一例を示す図である。
【図４】第１の実施形態におけるリソース操作権限ポリシの一部であるリソーステナントテーブルの一例を示す図である。
【図５】第１の実施形態におけるリソース操作権限ポリシの一部である操作主体テナントテーブルの一例を示す図である。
【図６】第１の実施形態におけるＡＰＩ呼び出し権限ポリシの論理構造の一例を示す図である。
【図７】第１の実施形態におけるＡＰＩ呼び出し権限ポリシを示す操作主体ＡＰＩテーブルの一例を示す図である。
【図８】第１の実施形態におけるＡＰＩ実行可否判定部の内部構成の一例を示す図である。
【図９】第１の実施形態に係るネットワークリソース管理装置を実現するコンピュータのハードウェア構成を示すブロック図である。
【図１０】第１の実施形態における情報処理システムの動作を示すシーケンス図である。
【図１１】第１の実施形態におけるＡＰＩ実行可否判定部の動作を示すフローチャートである。
【図１２】第１の実施形態の変形例に係るネットワークリソース管理システムの構成を示すブロック図である。
【図１３】本発明の第２の実施形態におけるリソース操作権限ポリシの論理構造の一例を示す図である。
【図１４】第２の実施形態におけるリソース操作権限ポリシの一部を示すリソーステナントテーブルの一例を示す図である。
【図１５】本発明の第３の実施形態に掛かる情報処理システムの構成を示すブロック図である。
【発明を実施するための形態】
【００３５】
本発明を実施するための形態について図面を参照して詳細に説明する。尚、各図面及び明細書記載の各実施形態において、同様の構成要素には同様の符号を付与し、適宜説明を省略する。
【００３６】
＜＜＜第１の実施形態＞＞＞
図１は、本発明の第１の実施形態に係るネットワークリソース管理システム（情報処理システムとも呼ばれる）４００の構成を示すブロック図である。
【００３７】
図１に示すように、本実施形態に係るネットワークリソース管理システム４００は、ＡＰＩ実行可否判定部１１０を含む。
【００３８】
尚、図１に示す各構成要素は、ハードウェア単位の回路でも、コンピュータ装置の機能単位に分割された構成要素でもよい。ここでは、図１に示す構成要素は、コンピュータ装置の機能単位に分割された構成要素として説明する。
【００３９】
＝＝＝ＡＰＩ実行可否判定部１１０＝＝＝
ＡＰＩ実行可否判定部１１０は、操作主体（不図示）によって呼び出された、ネットワークリソースを制御するための、ＡＰＩの実行の可否を、リソース制御ポリシ８００に基づいて判定する。次に、ＡＰＩ実行可否判定部１１０は、その判定された実行の可否に基づいて、そのＡＰＩを実行する手段（不図示）により提供されるＡＰＩを呼び出す。尚、リソース制御ポリシ８００の構造は、一般的に、データ構造とも呼ばれる。
【００４０】
ここで、リソース制御ポリシ８００は、第１のポリシと第２のポリシとを含む。第１のポリシは、テナントとの対応を示す。そのテナントは、その操作主体とその操作主体が操作を許可された、そのリソースの集合である。尚、そのテナントは、スライスやコンテナ、ドメインなどとも呼ばれる。第２のポリシは、その操作主体と、その操作主体が実行を許可されたＡＰＩとの対応を示す。
【００４１】
その操作主体は、例えば、管理者やアプリケーションなどの、そのネットワークリソースを操作する主体である。
【００４２】
そのＡＰＩを実行する手段は、例えば、呼び出されたそのＡＰＩに基づいて、そのネットワークリソースを制御する手段である。
【００４３】
図２は、本実施形態に係るネットワークリソース管理システム４０１を含む情報処理システム１０の構成を示すブロック図である。
【００４４】
図２に示すように、情報処理システム１０は、ＳＤＮコントローラ１００とＳＤＮリソース（ネットワークリソースとも呼ばれる）２００とＳＤＮアプリケーション（操作主体とも呼ばれる）２０１とを備える。
【００４５】
＝＝＝ＳＤＮアプリケーション２０１＝＝＝
ＳＤＮアプリケーション２０１は、ＳＤＮコントローラ１００により提供されるＡＰＩを呼び出すことにより、ファイアウォールやロードバランサなどのさまざまなネットワークサービスを提供するアプリケーションである。図２には、１つのＳＤＮアプリケーション２０１を代表的に示すが、ＳＤＮアプリケーション２０１の種類と数とは任意であってよい。
【００４６】
＝＝＝ＳＤＮリソース２００＝＝＝
ＳＤＮリソース２００は、ＳＤＮコントローラ１００から指示を受けて実行される、パケットの転送や書き換えなどに係るネットワークリソースである。例えば、そのネットワークリソースは、ＳＤＮコントローラ１００自身、及びＳＤＮコントローラ１００のＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）や、メモリなどである。そのネットワークリソースは、スイッチや、ルータ、及び、そのスイッチ及びルータのＣＰＵや、ポートなどである。そのネットワークリソースは、帯域やＶＬＡＮ（Ｖｉｒｔｕａｌ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）  ＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）などのネットワーク諸元であってよい。そのネットワークリソースは、テナント内部の通信のアクセスコントロールリスト（ファイアウォールのルール）や、そのテナントでブロードキャストができるかなどの、テナントのケーパビリティであってよい。そのネットワークリソースは、上述の例に限らず、任意のリソースであってよい。図２には、１つのＳＤＮリソース２００を代表的に示すが、ＳＤＮリソース２００の種類と数とは任意であってよい。
【００４７】
＝＝＝ＳＤＮコントローラ１００＝＝＝
ＳＤＮコントローラ１００は、ＳＤＮリソース２００を操作するためのＡＰＩを、ＳＤＮアプリケーション２０１へ提供する。
【００４８】
ＳＤＮコントローラ１００は、ＡＰＩ実行可否判定部１１０と、リソース制御ポリシＤＢ（Ｄａｔａｂａｓｅ）（ポリシ記憶手段とも呼ばれる）１０３と、ＡＰＩ提供部１０４とを備える。ＡＰＩ実行可否判定部１１０とリソース制御ポリシＤＢ１０３とは、合わせてネットワークリソース管理システム４０１とも呼ばれる。
【００４９】
＝＝＝リソース制御ポリシＤＢ１０３＝＝＝
リソース制御ポリシＤＢ１０３は、ＳＤＮリソース２００を操作するＡＰＩの実行可否を制御するための、リソース制御ポリシ８００を記憶する。そのリソース制御ポリシ８００は、第１のポリシであるリソース操作権限ポリシ８１０と第２のポリシであるＡＰＩ呼び出し権限ポリシ８２０とを含む。リソース操作権限ポリシ８１０は、あるＳＤＮアプリケーション２０１が操作可能なＳＤＮリソース２００を規定する。ＡＰＩ呼び出し権限ポリシ８２０は、あるＳＤＮアプリケーション２０１が呼び出し可能（実行可能）なＡＰＩを規定する。
【００５０】
図３は、リソース操作権限ポリシ８１０の論理構造の一例を示す図である。
【００５１】
図３に示すように、リソース操作権限ポリシ８１０は、ＳＤＮリソース２００の集合であるテナントと、操作主体（例えばＳＤＮアプリケーション２０１のようなアプリケーションや管理者など）とが、どのように結びついているかを示す。
【００５２】
図３は、第１テナントが、コントローラリソース、スイッチリソース、ネットワーク諸元及びケーパビリティの４つのリソースグループに結びつくことを示す。
【００５３】
さらに、図３は、コントローラリソースが、ＳＤＮコントローラ１００へのメモリ量及びＣＰＵの割り当て量であることを示す。
【００５４】
また、図３は、スイッチリソースが、スイッチへのＣＰＵの割り当て量、スイッチの物理ポート、ＯｐｅｎＦｌｏｗスイッチのＦｌｏｗＴａｂｌｅの割り当て量や領域などであることを示す。
【００５５】
また、図３は、ネットワーク諸元が、帯域、ＶＬＡＮ  ＩＤ及びＩＰ／ＭＡＣアドレスであることを示す。
【００５６】
また、図３は、ケーパビリティが、テナント内部の通信のＡＣＬ（Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｌｉｓｔ、ファイアウォールのルールを示す）、及びそのテナントでのブロードキャスト可否であることを示す。
【００５７】
また、リソース操作権限ポリシ８１０は、操作主体とテナントとの結びつきを、Ｎ：Ｎ（多対多）の関係で示す。つまり、１つの操作主体が複数のテナントに結びついてよいし、１つのテナントが複数の操作主体と結びついてもよい。
【００５８】
例えば、図３は、「ユーザＡＰＰ（Ａｐｐｌｉｃａｔｉｏｎ）」と、「第１テナント」が結びついていることを示す。これは、「ユーザＡＰＰ」が、「第１テナント」に含まれるＳＤＮリソース２００を操作する権限を有することを示す。同様に、図３は、「特権ＡＰＰ」が、「第１テナント」及び「第２テナント」に含まれるＳＤＮリソース２００を操作する権限を有することを示す。同様に、図３は、「管理者」が、「第２テナント」に含まれるリソースを操作する権限を有することを示す。同様に、図３は、「特権管理者」が、「第１テナント」及び「第２テナント」に含まれるＳＤＮリソース２００を操作する権限を有することを示す。
【００５９】
図４は、本実施形態におけるリソース操作権限ポリシ８１０の一部であるリソーステナントテーブル８１１の一例を示す図である。図４に示すように、リソーステナントテーブル８１１は、ＳＤＮリソース２００を特定するリソース名称とリソースグループを特定するリソースグループ名称とテナントを特定するテナント名称とを含むレコードを含む。即ち、リソーステナントテーブル８１１は、ＳＤＮリソース２００とリソースグループとテナントとの結びつきを示す。
【００６０】
図５は、本実施形態におけるリソース操作権限ポリシ８１０の一部である操作主体テナントテーブル８１２の一例を示す図である。図５に示すように、操作主体テナントテーブル８１２は、操作主体ＩＤとテナント名称とを含むレコードを含む。その操作主体ＩＤは、操作主体を一意に識別するＩＤである。即ち、操作主体テナントテーブル８１２は、操作主体とテナントとの結びつきを示す。
【００６１】
図６は、ＡＰＩ呼び出し権限ポリシ８２０の論理構造の一例を示す図である。
【００６２】
図６に示すように、ＡＰＩ呼び出し権限ポリシ８２０は、操作主体とＡＰＩとの結びつきを示す。換言すると、ＡＰＩ呼び出し権限ポリシ８２０は、各操作主体が実行を許可されているＡＰＩはどのＡＰＩであるかを示す。
【００６３】
また、ＡＰＩ呼び出し権限ポリシ８２０は、操作主体とＡＰＩとの結びつきを、Ｎ：Ｎ（多対多）の関係で示す。つまり、１つの操作主体が複数のＡＰＩに結びついてよいし、１つのＡＰＩが複数の操作主体と結びついてもよい。
【００６４】
例えば、図６は、「ユーザＡＰＰ」が、第１ＡＰＩ及び第２ＡＰＩを呼び出すことができることを示す。また、図６は、「特権ＡＰＰ」が、第１ＡＰＩ、第２ＡＰＩ、第３ＡＰＩ及び第４ＡＰＩを呼び出すことができることを示す。さらに、図６は、「管理者」が、第１ＡＰＩ及び第２ＡＰＩを呼び出すことができることを示す。
【００６５】
図７は、本実施形態におけるＡＰＩ呼び出し権限ポリシ８２０の具体的な記憶形式である操作主体ＡＰＩテーブル８２１の一例を示す図である。図７に示すように、操作主体ＡＰＩテーブル８２１は、操作主体ＩＤとＡＰＩを特定するＡＰＩ名称とを含むレコードを含む。即ち、操作主体ＡＰＩテーブル８２１は、操作主体とＡＰＩとの結びつきを示す。
【００６６】
以上説明したように、本実施形態のリソース制御ポリシ８００は、ネットワークリソース（例えば、ＳＤＮリソース２００）の集合（テナント）と、操作（ＡＰＩ）と、操作主体とを関連付ける。こうすることで、本実施形態は、ポリシの記述やメンテナンスを簡略化している。具体的には、ネットワーク環境において、テナントの定義は主にサービスメニューによって決まるため変化することが少ない。従って、リソース操作権限ポリシ８１０のメンテナンスが必要になることが少ない。また、あるアプリケーションに必要な操作は予め決まっており変化することが少ない。従って、ＡＰＩ呼び出し権限ポリシ８２０のメンテナンスが必要になることが少ない。以上より、リソース制御ポリシ８００のメンテナンスのコストを低減することができる。
【００６７】
また、コントローラの機能拡張により、新たな操作の追加や操作の種類の統廃合があった場合、本実施形態のリソース制御ポリシ８００の構成であれば、図６に示すＡＰＩ呼び出し権限ポリシ８２０のみを更新すればよい。従って、システムの変更に対するポリシの更新のコストを低減することができる。
【００６８】
加えて、リソース制御ポリシ８００は、ＳＤＮコントローラの実装に依存しない。そのため、リソース制御ポリシ８００は、同一の形式で、複数のコントローラに対応できるという効果がある。具体的には、以下のような、ネットワークの一部を切り出したリソースの集合が定義されている。その第１は、ＯｐｅｎＤａｙｌｉｇｈｔ（登録商標）におけるコンテナである。その第２は、Ｐｒｏｇｒａｍｍａｂｌｅ  Ｆｌｏｗコントローラにおけるテナントである。その第３は、オープンソースのＯｐｅｎＦｌｏｗコントローラフレームワークであるＴｒｅｍａの、アプリケーションにおけるスライスである。
【００６９】
リソース制御ポリシ８００は、そのようなリソースの集合と、操作主体（アプリケーションや管理者）とを関連付けるので、どのコントローラにも適用可能である。またこの時、テナント、コンテナ及びスライスなどの定義を、図３に示すリソース操作権限ポリシ８１０によって、柔軟に定義することができる。
【００７０】
＝＝＝ＡＰＩ実行可否判定部１１０＝＝＝
ＡＰＩ実行可否判定部１１０は、図１に示すＡＰＩ実行可否判定部１１０と同じである。
【００７１】
即ち、ＡＰＩ実行可否判定部１１０は、ＳＤＮアプリケーション２０１によって呼び出された、ＳＤＮリソース２００を操作するためのＡＰＩの実行の可否を、リソース制御ポリシ８００（第１のポリシ及び第２のポリシ）に基づいて判定する。次に、ＡＰＩ実行可否判定部１１０は、その判定された実行の可否に基づいて、ＡＰＩ提供部１０４により提供されるＡＰＩを呼び出す。
【００７２】
図８は、ＡＰＩ実行可否判定部１１０の内部構成の一例を示す図である。図８に示すように、ＡＰＩ実行可否判定部１１０は、例えば、ＡＰＩ制御部１１１及び権限管理部１１２を含む。
【００７３】
＝＝＝ＡＰＩ制御部１１１＝＝＝
ＡＰＩ制御部１１１は、ＳＤＮアプリケーション２０１による、ＳＤＮリソース２００を操作するための、ＡＰＩ提供部１０４により提供されるＡＰＩの呼び出しを監視し、そのＡＰＩの実行可否を権限管理部１１２に問い合わせる。また、ＡＰＩ制御部１１１は、権限管理部１１２への問い合わせの結果（権限管理部１１２が判定した実行の可否）に基づいて、そのＡＰＩを呼び出す。
【００７４】
具体的には、ＡＰＩ制御部１１１は、以下のようにして、そのＡＰＩの実行可否を権限管理部１１２に問い合わせる。
【００７５】
第１に、ＡＰＩ制御部１１１は、ＳＤＮアプリケーション２０１からＡＰＩが呼び出された際に、そのＡＰＩを呼び出した操作主体ＩＤを特定する。ここでは、その操作主体ＩＤは、ＳＤＮアプリケーション２０１のアプリケーションＩＤである。
【００７６】
例えば、ＡＰＩ制御部１１１は、そのアプリケーションＩＤを、予め与えられた共有の秘密情報（クレデンシャル）に基づいて、特定する。また、ＡＰＩ制御部１１１は、ＳＤＮアプリケーション２０１の電子署名を確認することにより、そのアプリケーションＩＤを取得してもよい。
【００７７】
第２に、ＡＰＩ制御部１１１は、そのＡＰＩが呼び出された際に、そのＡＰＩに含まれる、その呼び出されたＡＰＩを特定するＡＰＩ名称を取得する。
【００７８】
第３に、ＡＰＩ制御部１１１は、その呼び出されたＡＰＩの引数を確認し、そのＡＰＩが実行されることによって操作されるＳＤＮリソース２００を特定する。
【００７９】
一般的に、ＡＰＩは、複数の引数を取る。従って、ＡＰＩ制御部１１１は、各ＡＰＩのどの引数が、操作しようとしているＳＤＮリソース２００を示すかを判定するためのルールを内部に保持してよい。例えば、関数１（引数１、引数２、引数３）という形式のＡＰＩがある場合、ＡＰＩ制御部１１１は、引数３が操作対象のＳＤＮリソース２００を指定する引数であることを記憶していてよい。そして、ＡＰＩ制御部１１１は、その関数１（ＡＰＩ）が呼び出されたときに、引数３の値に基づいて、そのＡＰＩが操作しようとしているＳＤＮリソース２００を特定する。
【００８０】
第４に、ＡＰＩ制御部１１１は、その操作主体ＩＤ、ＡＰＩ名称及び特定したＳＤＮリソース２００のリソース名称を示して、そのＡＰＩの実行可否を権限管理部１１２に問い合わせる。
【００８１】
＝＝＝権限管理部１１２＝＝＝
権限管理部１１２は、ＡＰＩ制御部１１１の問い合わせを受けて、そのＡＰＩの実行の可否を、リソース制御ポリシＤＢ１０３に記憶されているリソース制御ポリシ８００（第１のポリシ及び第２のポリシ）に基づいて判定する。
【００８２】
具体的には、第１に、権限管理部１１２は、ＡＰＩ制御部１１１から、操作主体ＩＤ、ＡＰＩ名称及びリソース名称を受け取る。
【００８３】
第２に、権限管理部１１２は、その操作主体ＩＤ及びそのＡＰＩ名称の組と、図６に示すＡＰＩ呼び出し権限ポリシ８２０の内容とを比較する。そして、権限管理部１１２は、その比較した結果に基づいて、その操作主体ＩＤで特定される操作主体が、そのＡＰＩ名称で特定されるＡＰＩの実行を許可されているか否かを確認する。
【００８４】
具体的には、権限管理部１１２は、その操作主体とそのＡＰＩとが、ＡＰＩ呼び出し権限ポリシ８２０において結びつけられていれば、その実行を許可されているものと判定する。
【００８５】
第３に、権限管理部１１２は、操作主体ＩＤ及びリソース名称と、図３に示すリソース操作権限ポリシ８１０とを比較する。そして、権限管理部１１２は、その比較した結果に基づいて、その操作主体ＩＤで特定される操作主体が、そのリソース名称で特定されるＳＤＮリソース２００に対する操作を許可されているか否かを確認する。
【００８６】
具体的には、権限管理部１１２は、その操作主体とそのＳＤＮリソース２００とが、リソース操作権限ポリシ８１０において結びつけられていれば、その操作を許可されているものと判定する。
【００８７】
第４に、権限管理部１１２は、そのＡＰＩの実行が許可されており、そのＳＤＮリソース２００に対する操作が許可されていれば、そのＡＰＩの実行が可である旨を、ＡＰＩ制御部１１１に通知する。また、権限管理部１１２は、そのＡＰＩの実行及びそのＳＤＮリソース２００に対する操作の少なくともいずれかが許可されていなければ、そのＡＰＩの実行が不可である旨を、ＡＰＩ制御部１１１に通知する。
【００８８】
＝＝＝ＡＰＩ提供部１０４＝＝＝
ＡＰＩ提供部１０４は、ＳＤＮリソース２００を操作するＡＰＩを、ＳＤＮアプリケーション２０１へ提供する。換言すると、ＡＰＩ提供部１０４は、呼び出されたＡＰＩを実行し、ＳＤＮリソース２００を操作する。
【００８９】
以上が、ネットワークリソース管理システム４００及びネットワークリソース管理システム４０１の機能単位の各構成要素についての説明である。
【００９０】
次に、ネットワークリソース管理システム４００及びネットワークリソース管理システム４０１の、ハードウェア単位の構成要素について説明する。
【００９１】
図９は、本実施形態におけるネットワークリソース管理システム４００及びネットワークリソース管理システム４０１を実現するコンピュータ７００のハードウェア構成を示す図である。
【００９２】
図９に示すように、コンピュータ７００は、ＣＰＵ７０１、記憶部７０２、記憶装置７０３、入力部７０４、出力部７０５及び通信部７０６を含む。さらに、コンピュータ７００は、外部から供給される記録媒体（または記憶媒体）７０７を含む。例えば、記録媒体７０７は、情報を非一時的に記憶する不揮発性記録媒体（非一時的記録媒体）である。また、記録媒体７０７は、情報を信号として保持する、一時的記録媒体であってもよい。
【００９３】
ＣＰＵ７０１は、オペレーティングシステム（不図示）を動作させて、コンピュータ７００の全体の動作を制御する。例えば、ＣＰＵ７０１は、記憶装置７０３に装着された記録媒体７０７から、そのプログラムやデータを読み込み、読み込んだそのプログラムやそのデータを記憶部７０２に書き込む。ここで、そのプログラムは、例えば、後述の図１０のシーケンス図及び図１１に示すフローチャートの動作をコンピュータ７００に実行させるためのプログラムである。
【００９４】
そして、ＣＰＵ７０１は、その読み込んだプログラムに従って、またその読み込んだデータに基づいて、図１及び図２に示すＡＰＩ実行可否判定部１１０として各種の処理を実行する。
【００９５】
尚、ＣＰＵ７０１は、通信網（不図示）に接続される外部コンピュータ（不図示）から、記憶部７０２にそのプログラムやそのデータをダウンロードしてもよい。
【００９６】
記憶部７０２は、そのプログラムやそのデータを記憶する。記憶部７０２は、リソース制御ポリシ８００を記憶してよい。記憶部７０２は、ＡＰＩ実行可否判定部１１０及びリソース制御ポリシＤＢ１０３の一部として含まれてよい。
【００９７】
記憶装置７０３は、例えば、光ディスクや、フレキシブルディスク、磁気光ディスク、外付けハードディスク半導体メモリなどであって、記録媒体７０７を含む。記憶装置７０３（記録媒体７０７）は、そのプログラムをコンピュータ読み取り可能に記憶する。また、記憶装置７０３は、そのデータ（例えば、リソース制御ポリシ８００）を記憶してもよい。記憶装置７０３は、ＡＰＩ実行可否判定部１１０及びリソース制御ポリシＤＢ１０３の一部として含まれてよい。
【００９８】
入力部７０４は、オペレータによる操作の入力や外部からの情報の入力を受け付ける。入力操作に用いられるデバイスは、例えば、マウスや、キーボード、内蔵のキーボタン及びタッチパネルなどである。入力部７０４は、ＡＰＩ実行可否判定部１１０の一部として含まれてよい。
【００９９】
ＡＰＩ実行可否判定部１１０は、入力部７０４によりリソース操作権限ポリシ８１０の入力を受け付け、そのリソース操作権限ポリシ８１０を記憶部７０２及び記憶装置７０３に記録してよい。また、ＡＰＩ実行可否判定部１１０は、入力部７０４によりＡＰＩ呼び出し権限ポリシ８２０の入力を受け付け、それらを記憶部７０２及び記憶装置７０３に記録してよい。
【０１００】
出力部７０５は、例えばディスプレイで実現される。出力部７０５は、例えばＧＵＩ（ＧＲＡＰＨＩＣＡＬ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）によるオペレータへの入力要求や、オペレータに対する出力提示などのために用いられる。出力部７０５は、ＡＰＩ実行可否判定部１１０の一部として含まれてよい。
【０１０１】
ＡＰＩ実行可否判定部１１０は、前述のＡＰＩの実行が不可であると判定した場合に、その判定した結果に係る、リソース操作権限ポリシ８１０及びＡＰＩ呼び出し権限ポリシ８２０に含まれる情報を、出力部７０５を介して出力してよい。
【０１０２】
通信部７０６は、外部システムとのインタフェースを実現する。通信部７０６は、ＡＰＩ実行可否判定部１１０の一部として含まれてよい。その外部システムは、図１の場合は、例えば、リソース操作権限ポリシ８１０やＡＰＩ呼び出し権限ポリシ８２０を記憶する外部の記憶手段や、操作主体が動作するコンピュータ、ネットワークリソース、及びＡＰＩを実行するコンピュータなどであってよい。また、その外部システムは、図２の場合は、例えば、ＳＤＮリソース２００であってよい。この場合、ＳＤＮアプリケーション２０１及びＡＰＩ提供部１０４は、ネットワークリソース管理システム４０１と同じコンピュータ７００上で動作してもよい。
【０１０３】
以上説明したように、図１に示すネットワークリソース管理システム４００及びネットワークリソース管理システム４０１の機能単位のブロックは、図９に示すハードウェア構成のコンピュータ７００によって実現される。但し、コンピュータ７００が備える各部の実現手段は、上記に限定されない。すなわち、コンピュータ７００は、物理的に結合した１つの装置により実現されてもよいし、物理的に分離した２つ以上の装置を有線または無線で接続し、これら複数の装置により実現されてもよい。
【０１０４】
尚、上述のプログラムのコードを記録した記録媒体７０７が、コンピュータ７００に供給される場合、ＣＰＵ７０１は、記録媒体７０７に格納されたそのプログラムのコードを読み出して実行してもよい。或いは、ＣＰＵ７０１は、記録媒体７０７に格納されたそのプログラムのコードを、記憶部７０２、記憶装置７０３またはその両方に格納してもよい。すなわち、本実施形態は、コンピュータ７００（ＣＰＵ７０１）が実行するそのプログラム（ソフトウェア）を、一時的にまたは非一時的に、記憶する記録媒体７０７の実施形態を含む。尚、情報を非一時的に記憶する記憶媒体は、不揮発性記憶媒体とも呼ばれる。
【０１０５】
以上が、本実施形態におけるネットワークリソース管理システム４００及びネットワークリソース管理システム４０１を実現するコンピュータ７００の、ハードウェア単位の各構成要素についての説明である。
【０１０６】
次に本実施形態の動作について、図面を参照して詳細に説明する。
【０１０７】
図１０は、図２に示す情報処理システム１０の動作を示すシーケンス図である。尚、図１０は、図１に示すネットワークリソース管理システム４００及び図２に示すネットワークリソース管理システム４０１の動作を包含する。尚、このシーケンス図による処理は、前述したＣＰＵ７０１によるプログラム制御に基づいて、実行されてよい。また、処理のステップ名については、Ｓ１００のように、記号で記載する。
【０１０８】
ＳＤＮアプリケーション２０１は、ＡＰＩ提供部１０４により提供されるＡＰＩを呼び出す（ステップＳ１００）。例えば、そのＡＰＩの呼び出しは、ＳＤＮコントローラ１００上でローカルに行ってよい。また、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ）を用いて、ネットワーク経由でリモートから呼び出してもよい。
【０１０９】
次に、ＡＰＩ実行可否判定部１１０のＡＰＩ制御部１１１は、ステップＳ１００のそのＡＰＩの呼び出しをフックする（ステップＳ２００）。
【０１１０】
フックの方法は、ＳＤＮアプリケーション２０１とＡＰＩ提供部１０４との間の通信を見張る方法や、ＡＰＩ提供部１０４が実行するＡＰＩを見張るなどの方法があり、特に限定されない。
【０１１１】
次に、ＡＰＩ制御部１１１は、そのフックしたＡＰＩに基づいて、そのＡＰＩを呼び出した操作主体ＩＤと、ＡＰＩ名称と、操作対象のＳＤＮリソース２００のリソース名称とを取得する。続けて、ＡＰＩ制御部１１１は、その操作主体ＩＤとそのＡＰＩ名称とそのリソース名称とを示して、権限管理部１１２にそのＡＰＩの実行可否を問い合わせる（ステップＳ３００）。
【０１１２】
例えば、アプリケーションＡが、「ｓｈｏｗ＿ｓｔａｔ(対象のスイッチ)」という統計情報を表示する関数を呼び出し、スイッチＳの情報を取得する、という場合がある。この場合、アプリケーションのＩＤは、「アプリケーションＡ」、ＡＰＩ名称は、「ｓｈｏｗ＿ｓｔａｔ」、リソース名称は、「スイッチＳ」である。
【０１１３】
次に、権限管理部１１２は、リソース制御ポリシＤＢ１０３に、リソース制御ポリシ８００（リソース操作権限ポリシ８１０とＡＰＩ呼び出し権限ポリシ８２０）を要求する（ステップＳ４００）。
【０１１４】
次に、リソース制御ポリシＤＢ１０３は、リソース制御ポリシ８００（リソース操作権限ポリシ８１０及びＡＰＩ呼び出し権限ポリシ８２０）を送信する（ステップＳ５００）。
【０１１５】
次に、権限管理部１１２は、リソース制御ポリシ８００と、ＡＰＩ制御部１１１から受け取った情報とに基づいて、そのＡＰＩを実行可能であるか実行不可であるか判定し、その判定結果をＡＰＩ制御部１１１へ通知する（ステップＳ６００）。ステップＳ６００の詳細については、後述する。
【０１１６】
次に、ＡＰＩ制御部１１１は、権限管理部１１２から通知された結果が「実行可能」であればＡＰＩ提供部１０４を呼び出す（ステップＳ７００）。
【０１１７】
次に、ＡＰＩ提供部１０４はＡＰＩを実行し、ＳＤＮリソース２００を操作する（ステップＳ８００）。
【０１１８】
ＡＰＩ制御部１１１は、「実行不可」であれば、ＡＰＩ制御部１１１はＳＤＮアプリケーション２０１へエラーを通知する（ステップＳ９００）。
【０１１９】
以上の動作によって、ＳＤＮコントローラ１００は、ＳＤＮアプリケーション２０１が呼び出したＡＰＩの実行の可否を制御する。また、上記では、ＳＤＮアプリケーション２０１がＡＰＩを呼び出す動作を説明したが、管理者がＡＰＩを呼び出すときも、ＳＤＮコントローラ１００は、同じ動作で、ＡＰＩの呼び出しの可否を制御することができる。
【０１２０】
次に、図１１を用いてステップＳ６００を詳細に説明する。図１１は、本実施形態におけるＡＰＩ実行可否判定部１１０の権限管理部１１２の動作を示すフローチャートである。
【０１２１】
ＡＰＩ実行可否判定部１１０の権限管理部１１２は、ＡＰＩ制御部１１１から、操作主体ＩＤとＡＰＩ名称とリソース名称とを受け取る（ステップＳ６０１）。
【０１２２】
次に、権限管理部１１２は、ＳＤＮアプリケーション２０１がＡＰＩの操作の対象としているＳＤＮリソース２００を操作可能であるか否かを判断する（ステップＳ６０２）。
【０１２３】
具体的には、権限管理部１１２は、その操作主体ＩＤに基づいて、図５に示すリソース操作権限ポリシ８１０の操作主体テナントテーブル８１２から、そのＳＤＮアプリケーション２０１を検索する。そして、権限管理部１１２は、そのＳＤＮアプリケーション２０１と結びついているテナントを特定する。そのテナントは、１つ若しくは複数である。次に、権限管理部１１２は、そのリソース名称に基づいて、図４で示されるリソース操作権限ポリシ８１０のリソーステナントテーブル８１１を検索する。そして、権限管理部１１２は、そのＡＰＩの操作の対象となっているＳＤＮリソース２００が、ＳＤＮアプリケーション２０１が結びついているテナントに、関連付けられているか否かを確認する。権限管理部１１２は、そのテナントにそのＳＤＮリソース２００が関連付けられていれば、操作可能と判断し、そのテナントにそのＳＤＮリソース２００が関連付けられていなければ、操作不可と判断する。
【０１２４】
次に、権限管理部１１２は、その操作主体ＩＤで特定される操作主体が、そのＡＰＩを呼び出す権限があるか否かを判断する（ステップＳ６０３）。
【０１２５】
具体的には、権限管理部１１２は、その操作主体ＩＤとそのＡＰＩ名称とに基づいて、図６に示すＡＰＩ呼び出し権限ポリシ８２０を確認し、その操作主体ＩＤとそのＡＰＩ名称が関連付けられているか否か、を確認する。即ち、権限管理部１１２は、その操作主体がそのＡＰＩを実行する権限があるかないかを確認する。
【０１２６】
次に、権限管理部１１２は、ステップＳ６０２でＳＤＮリソース２００の操作が可能、かつ、ステップＳ６０３でＡＰＩを呼び出す権限があると判断されているかを確認する（ステップＳ６０４）。
【０１２７】
ステップＳ６０４の条件を満たす場合（ステップＳ６０４でＹＥＳ）、権限管理部１１２は、そのＡＰＩの実行を許可してよいと判断し、「実行可」をＡＰＩ制御部１１１へ通知する（ステップＳ６０５）。
【０１２８】
ステップＳ６０４の条件を満たさない場合（ステップＳ６０４でＮＯ）、権限管理部１１２は、そのＡＰＩの「実行不可」をＡＰＩ制御部１１１へ通知する（ステップＳ６０６）。
【０１２９】
上述した本実施形態における第１の効果は、ネットワークリソースの制御機能を提供するＡＰＩの実行可否制御を、より低コストで、操作主体とネットワークリソースと操作との組み合わせごとに実現することが可能になる点である。
【０１３０】
その理由は、ＡＰＩ実行可否判定部１１０が、リソース制御ポリシ８００に基づいて、操作主体によって呼び出されたＡＰＩの実行可否を判定し、その判定した結果に基づいて、そのＡＰＩの実行をそのＡＰＩを実行する手段へ指示するからである。
【０１３１】
上述した本実施形態における第２の効果は、ＩＰアドレスやＭＡＣアドレス、ネットワークの帯域及びＯｐｅｎＦｌｏｗスイッチのフローテーブルなどのさまざまなネットワークリソースの制御を、統一的に制御することが可能になる点である。
【０１３２】
その理由は、さまざまな種類のネットワークリソースの集合がリソース操作権限ポリシ８１０に柔軟に定義され、そのようなリソースの集合と、操作主体と、操作とがリソース制御ポリシ８００により関連付けられるからである。
【０１３３】
上述した本実施形態における第３の効果は、さまざまな実装のＳＤＮにおいるネットワークリソースの制御機能を提供するＡＰＩの実行可否制御を、より低コストに、所望の精度で実現することが可能になる点である。
【０１３４】
その理由は、さまざまな実装ＳＤＮにおけるリソースの集合がリソース操作権限ポリシ８１０に柔軟に定義され、そのようなリソースの集合と、操作主体と、操作とがリソース制御ポリシ８００により関連付けられるからである。
【０１３５】
＜＜＜第１の実施形態の変形例＞＞＞
図１２は、第１の実施形態の変形例であるネットワークリソース管理システム４０２を示す図である。図１２に示すように、ネットワークリソース管理システム４０２は、図１及び図２に示すＡＰＩ実行可否判定部１１０と、図２に示すリソース制御ポリシＤＢ１０３と、を含む。ＡＰＩ実行可否判定部１１０と、リソース制御ポリシＤＢ１０３とは、ネットワーク９００を介して接続されている。尚、ＡＰＩ実行可否判定部１１０と、リソース制御ポリシＤＢ１０３とは、１台の図９に示すようなコンピュータ７００であってよいし、ネットワークを介することなく直接接続されてもよい。
【０１３６】
＝＝＝リソース制御ポリシＤＢ１０３＝＝＝
リソース制御ポリシＤＢ１０３は、図２に示すリソース制御ポリシＤＢ１０３と同等である。
【０１３７】
本変形例において、ＡＰＩ実行可否判定部１１０は、リソース制御ポリシＤＢ１０３から、ネットワーク９００を介して、リソース制御ポリシ８００を取得する。
【０１３８】
上述した本実施形態における変形例の効果は、ネットワークリソースの操作の可否を制御するネットワークリソース管理システム４０２の構築を柔軟に実現することが可能になる点である。
【０１３９】
その理由は、ＡＰＩ実行可否判定部１１０と、リソース制御ポリシＤＢ１０３とを、ネットワーク９００を介して接続するからである。
【０１４０】
＜＜＜第２の実施形態＞＞＞
次に、本発明の第２の実施形態について図面を参照して詳細に説明する。以下、本実施形態の説明が不明確にならない範囲で、前述の説明と重複する内容については説明を省略する。
【０１４１】
第２の実施形態は、リソース制御ポリシ８００がリソース操作権限ポリシ８１０に替えて、図１３に示すようなリソース操作権限ポリシ８３０を含む点が第１の実施形態と異なる。また、第２の実施形態は、ＡＰＩ実行可否判定部１１０が使用を許されるネットワークリソースの範囲を示す情報（以後、制限値と呼ぶ）にさらに基づいて、ＡＰＩの実行の可否を判断する点が、第１の実施形態と異なる。
【０１４２】
図１３は、本実施形態におけるリソース操作権限ポリシ８３０の構造を示す図である。図３に示すリソース操作権限ポリシ８１０は、操作主体が操作することを許可されたネットワークリソースを示す。一方、図１３に示すように、リソース操作権限ポリシ８３０は、操作主体が操作することを許可されたネットワークリソースのそれぞれの制限値をさらに示す。
【０１４３】
図１４は、本実施形態におけるリソース操作権限ポリシ８３０の具体的な記憶形式であるリソーステナントテーブル８３１の一例を示す図である。図１４に示すように、リソーステナントテーブル８３１は、ＳＤＮリソース２００を特定するリソース名称及び制限値と、リソースグループを特定するリソースグループ名称と、テナントを特定するテナント名称と、を含むレコードを含む。即ち、リソーステナントテーブル８３１は、ＳＤＮリソース２００及びその制限値と、リソースグループと、テナントと、の結びつきを示す。
【０１４４】
本実施形態のＡＰＩ実行可否判定部１１０は、あるＡＰＩを実行した場合にあるテナントに結びつけられたネットワークリソースの使用量が、リソース操作権限ポリシ８３０で指定された制限値を逸脱する場合、そのＡＰＩの実行を不可と判定する。
【０１４５】
具体的には、第１に、ＡＰＩ実行可否判定部１１０は、テナントに結びつけられたＳＤＮリソース２００のそれぞれの、現在の使用量を、例えば図９に示す記憶部７０２に保持する。
【０１４６】
第２に、ＡＰＩ実行可否判定部１１０は、ＡＰＩの実行可否を判定する場合に、そのＡＰＩが実行された場合の、ＳＤＮリソース２００のそれぞれの使用量の予測値を算出する。
【０１４７】
第３に、ＡＰＩ実行可否判定部１１０は、その予測値がその制限値以下の場合、そのＡＰＩの実行を可と判定し、その予測値がその制限値を逸脱する場合、そのＡＰＩの実行を不可と判定する。
【０１４８】
例えば、あるスイッチリソースのＦｌｏｗエントリの最大使用量が５０００エントリであるときに、ある操作主体がＦｌｏｗエントリを追加するＡＰＩを呼び出したとする。この場合、ＡＰＩ実行可否判定部１１０は、そのＡＰＩの実行によってその操作主体が属するテナントが使用しているフローエントリが５０００エントリを超えるか否かを判定し、超える場合はそのＡＰＩを実行不可であると判断する。
【０１４９】
同様に、ＡＰＩ実行可否判定部１１０は、コントローラリソースのＣＰＵやメモリの使用量、ネットワークの帯域など、制限値が示された任意のネットワークリソースについても、使用量に基づいてＡＰＩの実行の可否を判断してよい。
【０１５０】
以上の構成により、あるテナントが高負荷になっても、そのテナントが利用できるネットワークリソースの最大量が決まっているため、他のテナントへのパフォーマンスの影響を軽減することができる。
【０１５１】
ある操作主体が複数のテナントに属している場合、例えば、図１３に示す特権ＡＰＰは、その操作主体から一意にテナントを特定することができない。この場合は、ＳＤＮアプリケーション２０１は、ＡＰＩの呼び出し時に、ＡＰＩ実行可否判定部１１０へテナントを識別するための情報を送信してよい。そして、ＡＰＩ実行可否判定部１１０はそのテナントを識別するための情報にさらに基づいて、ＡＰＩの実行の可否を判断してよい。
【０１５２】
尚、リソース操作権限ポリシ８３０は、操作主体ごとに設定された制限値を含んでもよい。例えば、特権ＡＰＰや特権管理者の制限値は、ユーザＡＰＰや管理者の制限値より、広い範囲を示すものであってよい。
【０１５３】
上述した本実施形態における第１の効果は、第１の実施形態の効果に加えて、特定のテナントの負荷状態が他のテントのパフォーマンスに影響することを防止することが可能になる点である。
【０１５４】
その理由は、リソース操作権限ポリシ８３０が制限値を含み、ＡＰＩ実行可否判定部１１０がさらにその制限値に基づいて、ＡＰＩの実行の可否を判断するからである。
【０１５５】
上述した本実施形態における第２の効果は、ＡＰＩの実行の可否の判断において、テナントごとに優先度を付与することが可能になる点である。
【０１５６】
その理由は、リソース操作権限ポリシ８３０がテナントごとの制限値を含み、ＡＰＩ実行可否判定部１１０がそのテナントごとの制限値に基づいて、ＡＰＩの実行の可否を判断するからである。
【０１５７】
＜＜＜第３の実施形態＞＞＞
次に、本発明の第３の実施形態について図面を参照して詳細に説明する。以下、本実施形態の説明が不明確にならない範囲で、前述の説明と重複する内容については説明を省略する。
【０１５８】
図１５は、本発明の第３の実施形態における情報処理システム３０の構成を示すブロック図である。
【０１５９】
図１５に示すように、本実施形態における情報処理システム３０は、第１の実施形態の情報処理システム１０と比べて、ＳＤＮアプリケーション２０１に替えてＳＤＮコントローラ３００が接続されている点が異なる。
【０１６０】
ＳＤＮコントローラ３００は、例えば、ＳＤＮコントローラ１００と同等の機能を有する。
【０１６１】
図２に示す第１の実施形態の情報処理システム１０において、ＡＰＩ実行可否判定部１１０が、ＳＤＮアプリケーション２０１からのＡＰＩ呼び出しを監視し、そのＡＰＩの実行可否を制御することを説明した。さらに、図１５に示すように、ＡＰＩ実行可否判定部１１０は、他のＳＤＮコントローラ３００からのＡＰＩ呼び出しを監視してもよい。
【０１６２】
尚、ＳＤＮコントローラ１００は、任意の数の、ＳＤＮアプリケーション２０１及びやＳＤＮコントローラ３００からの、ＡＰＩ呼び出しを監視してよい。
【０１６３】
この場合、リソース制御ポリシ８００は、ＳＤＮコントローラ３００を１つの操作主体とするポリシを含む。
【０１６４】
上述した本実施形態における第１の効果は、第１の実施形態の効果に加えて、ＳＤＮコントローラ連携の時に、ＡＰＩの実行可否を制御することが可能になる点である。具体的には、連携している他のＳＤＮコントローラ３００にバグがあったり、乗っ取られていたりした場合でも、そのＳＤＮコントローラ３００における異常の影響が、ＳＤＮコントローラ１００が制御するＳＤＮリソース２００にまで広がることを防止できる。
【０１６５】
その理由は、ＡＰＩ実行可否判定部１１０が、ＳＤＮコントローラ３００を１つの操作主体として含むリソース制御ポリシ８００に基づいて、ＡＰＩの実行可否を制御するからである。
【０１６６】
以上の各実施形態で説明した各構成要素は、必ずしも個々に独立した存在である必要はない。例えば、複数個の任意のその構成要素が１個のモジュールとして実現されてよい。また、その構成要素の内の任意のひとつが複数のモジュールで実現されてもよい。また、その構成要素の内の任意のひとつがその構成要素の内の任意の他のひとつであってよい。また、その構成要素の内の任意のひとつの一部と、その構成要素の内の任意の他のひとつの一部とが重複してもよい。
【０１６７】
以上説明した各実施形態における各構成要素及び各構成要素を実現するモジュールは、必要に応じ、可能であれば、ハードウェア的に実現されてよい。また、各構成要素及び各構成要素を実現するモジュールは、コンピュータ及びプログラムで実現されてよい。また、各構成要素及び各構成要素を実現するモジュールは、ハードウェア的なモジュールとコンピュータ及びプログラムとの混在により実現されてもよい。
【０１６８】
そのプログラムは、例えば、磁気ディスクや半導体メモリなど、コンピュータが読み取り可能な非一時的記録媒体に記録され、コンピュータに提供される。そして、そのプログラムは、コンピュータの立ち上げ時などに、非一時的記録媒体からコンピュータに読み取られる。この読み取られたプログラムは、そのコンピュータの動作を制御することにより、そのコンピュータを前述した各実施形態における構成要素として機能させる。
【０１６９】
また、以上説明した各実施形態では、複数の動作をフローチャートの形式で順番に記載してあるが、その記載の順番は複数の動作を実行する順番を限定するものではない。このため、各実施形態を実施するときには、その複数の動作の順番は内容的に支障のない範囲で変更することができる。
【０１７０】
さらに、以上説明した各実施形態では、複数の動作は個々に相違するタイミングで実行されることに限定されない。例えば、ある動作の実行中に他の動作が発生してよい。また、ある動作と他の動作との実行タイミングが部分的に乃至全部において重複してもよい。
【０１７１】
さらに、以上説明した各実施形態では、ある動作が他の動作の契機になるように記載しているが、その記載はある動作と他の動作との関係を限定するものではない。このため、各実施形態を実施するときには、その複数の動作の関係は内容的に支障のない範囲で変更することができる。また各構成要素の各動作の具体的な記載は、各構成要素の各動作を限定するものではない。このため、各構成要素の具体的な各動作は、各実施形態を実施する上で機能的、性能的、その他の特性に対して支障を来さない範囲内で変更されてよい。
【０１７２】
以上、各実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得るさまざまな変更をすることができる。
【０１７３】
この出願は、２０１４年７月２２日に出願された日本出願特願２０１４−１４８６６７を基礎とする優先権を主張し、その開示のすべてをここに取り込む。
【符号の説明】
【０１７４】
１０    情報処理システム
３０    情報処理システム
１００    ＳＤＮコントローラ
１０３    リソース制御ポリシＤＢ
１０４    ＡＰＩ提供部
１１０    ＡＰＩ実行可否判定部
１１１    ＡＰＩ制御部
１１２    権限管理部
２００    ＳＤＮリソース
２０１    ＳＤＮアプリケーション
３００    ＳＤＮコントローラ
４００    ネットワークリソース管理システム
４０１    ネットワークリソース管理システム
４０２    ネットワークリソース管理システム
７００    コンピュータ
７０１    ＣＰＵ
７０２    記憶部
７０３    記憶装置
７０４    入力部
７０５    出力部
７０６    通信部
７０７    記録媒体
８００    リソース制御ポリシ
８１０    リソース操作権限ポリシ
８１１    リソーステナントテーブル
８１２    操作主体テナントテーブル
８２０    ＡＰＩ呼び出し権限ポリシ
８２１    操作主体ＡＰＩテーブル
８３０    リソース操作権限ポリシ
８３１    リソーステナントテーブル
９００    ネットワーク
【図１】
2016013200.tif 000003
【図２】
2016013200.tif 000004
【図３】
2016013200.tif 000005
【図４】
2016013200.tif 000006
【図５】
2016013200.tif 000007
【図６】
2016013200.tif 000008
【図７】
2016013200.tif 000009
【図８】
2016013200.tif 000010
【図９】
2016013200.tif 000011
【図１０】
2016013200.tif 000012
【図１１】
2016013200.tif 000013
【図１２】
2016013200.tif 000014
【図１３】
2016013200.tif 000015
【図１４】
2016013200.tif 000016
【図１５】
2016013200.tif 000017
【国際調査報告】
2016013200.tif 000018
2016013200.tif 000019
2016013200.tif 000020
2016013200.tif 000021