図面 (/)

技術 データ構造、生成装置、生成方法およびプログラム

出願人 エヌ・ティ・ティ・コムウェア株式会社
発明者 赤井和幸福田富美男荒川豊古川嘉識
出願日 2013年11月20日 (7年1ヶ月経過) 出願番号 2013-240350
公開日 2015年5月28日 (5年7ヶ月経過) 公開番号 2015-099572
状態 未査定
技術分野 記憶装置の機密保護
主要キーワード センシングポイント 記載順序 項目列 所属関係 アクセス可否情報 電力計測器 データ蓄積機 アクセス制御規則
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2015年5月28日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (6)

課題

アクセス制御規則記述量を削減することができるデータ構造生成装置生成方法およびプログラムを提供すること。

解決手段

前記コンポーネントが管理するデータであるポイントポイント情報記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダー識別情報を記述する領域と、前記イニシエータがレジストリへのアクセス許可するか否かを表すアクセス可否情報を記述する領域と、を含むデータ構造。

概要

背景

電力見える化、省エネ制御や生活利便性向上などを実現するために、各種センサまたはアクチュエータなどのデバイスデータ蓄積機能を有するストレージアプリケーション、システムマネージャ機能を有する装置などが相互に連携するシステムとそれを実現するための仕組みが普及しつつある。特に大規模なシステムでは、大量のデバイスが存在し、それらのデバイスから取得されストレージに蓄積される大量のデータが扱われる。このため、システムは、多種の機器接続可能な柔軟性と、機器の構成管理と、が可能であることが重要となる。

これを実現するための仕組みの一つとして、デバイス、ストレージ、アプリケーションなどが相互に連携するための標準化プロトコルとしてIEEE1888が規定されている。IEEE1888では、デバイス、ストレージ、アプリケーションなどのそれぞれを「コンポーネント」として扱う。

このようなシステムでは、デバイスに対するアクセスを制御することによって第三者からのアクセスを制限するだけではシステム全体のセキュリティを確保することは困難である。例えば、あるアプリケーションに対しては、センサデータを渡さないようにセンサ側で設定した場合でも、そのデータを別のストレージで蓄積し、そのストレージがアプリケーションのアクセス制御を行わなければ、結果としてアプリケーションにセンサデータが取得されることになる。また、複数のセンサで取得されたデータが同一のストレージに蓄積されるなどの事例も発生するため、ストレージは、データごとにアクセス制御する必要がある。

このように、デバイスとデータとの所属関係が複雑化するシステム内で、適切なセキュリティを実現する仕組みとしてIEEE1888の拡張仕様であるIEEE1888.3が定義されている。IEEE1888では、当該デバイスから取得されるデータの単位を「ポイント」として扱う(例えば、非特許文献1参照)。IEEE1888.3では、ポイント、手順、メソッドベルでのアクセス制御ルール記述とその運用が定義されており、これらの機能は、アクセス制御装置ACM:Access Control Manager)で実現すると規定されている。また、IEEE1888.1では、アクセス制御装置に対してアクセス制御規則(ACL:Access Control List)を管理して配布するリソースアクセス制御装置(RAM:Resources Access Manager)について規定されている。また、IEEE1888.1では、アクセス制御規則を配布する方法、またはアクセス制御規則を取得する方法について、コンポーネント通信を用いることが規定されている。

概要

アクセス制御規則の記述量を削減することができるデータ構造生成装置生成方法およびプログラムを提供すること。前記コンポーネントが管理するデータであるポイントのポイント情報を記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダー識別情報を記述する領域と、前記イニシエータがレジストリへのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、を含むデータ構造。

目的

本発明は、上記問題に鑑みてなされたものであり、アクセス制御規則の記述量を削減することができるデータ構造、及び生成装置を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

通信ステム構成機器であるコンポーネントから取得されるデータであるポイントポイント情報記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダー識別情報を記述する領域と、前記イニシエータがリソース情報管理装置へのアクセス許可するか否かを表すアクセス可否情報を記述する領域と、を含むことを特徴とするデータ構造

請求項2

通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、を含むデータ構造のアクセス制御規則を生成する生成装置

請求項3

通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、を含むデータ構造のアクセス制御規則を生成する生成方法

請求項4

コンピュータに、通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、を含むデータ構造のアクセス制御規則を生成させるためのプログラム

技術分野

0001

本発明は、データ構造生成装置生成方法およびプログラムに関する。

背景技術

0002

電力見える化、省エネ制御や生活利便性向上などを実現するために、各種センサまたはアクチュエータなどのデバイスデータ蓄積機能を有するストレージアプリケーション、システムマネージャ機能を有する装置などが相互に連携するシステムとそれを実現するための仕組みが普及しつつある。特に大規模なシステムでは、大量のデバイスが存在し、それらのデバイスから取得されストレージに蓄積される大量のデータが扱われる。このため、システムは、多種の機器接続可能な柔軟性と、機器の構成管理と、が可能であることが重要となる。

0003

これを実現するための仕組みの一つとして、デバイス、ストレージ、アプリケーションなどが相互に連携するための標準化プロトコルとしてIEEE1888が規定されている。IEEE1888では、デバイス、ストレージ、アプリケーションなどのそれぞれを「コンポーネント」として扱う。

0004

このようなシステムでは、デバイスに対するアクセスを制御することによって第三者からのアクセスを制限するだけではシステム全体のセキュリティを確保することは困難である。例えば、あるアプリケーションに対しては、センサデータを渡さないようにセンサ側で設定した場合でも、そのデータを別のストレージで蓄積し、そのストレージがアプリケーションのアクセス制御を行わなければ、結果としてアプリケーションにセンサデータが取得されることになる。また、複数のセンサで取得されたデータが同一のストレージに蓄積されるなどの事例も発生するため、ストレージは、データごとにアクセス制御する必要がある。

0005

このように、デバイスとデータとの所属関係が複雑化するシステム内で、適切なセキュリティを実現する仕組みとしてIEEE1888の拡張仕様であるIEEE1888.3が定義されている。IEEE1888では、当該デバイスから取得されるデータの単位を「ポイント」として扱う(例えば、非特許文献1参照)。IEEE1888.3では、ポイント、手順、メソッドベルでのアクセス制御ルール記述とその運用が定義されており、これらの機能は、アクセス制御装置ACM:Access Control Manager)で実現すると規定されている。また、IEEE1888.1では、アクセス制御装置に対してアクセス制御規則(ACL:Access Control List)を管理して配布するリソースアクセス制御装置(RAM:Resources Access Manager)について規定されている。また、IEEE1888.1では、アクセス制御規則を配布する方法、またはアクセス制御規則を取得する方法について、コンポーネント通信を用いることが規定されている。

先行技術

0006

スマートコミュニティ支え基盤技術—大量センシングポイント・コンポーネントの管理、アドレス解決技術IEEE1888レジストリ概要」、NTT技術ジャーナル、2012年11月、pp.38−41

発明が解決しようとする課題

0007

しかしながら、IEEE1888.1で規定されているコンポーネントがリソースアクセス制御装置に対してアクセス制御規則を取得する方法では、コンポーネント通信で用いられるマークアップ言語(XML:Extensible Markup Language)上で表現できるように記述され、例えば、識別情報(id:Identifer)の属性に必要な情報をすべて記述するため、アクセス制御規則の記述量が多くなるという問題があった。

0008

そこで本発明は、上記問題に鑑みてなされたものであり、アクセス制御規則の記述量を削減することができるデータ構造、及び生成装置を提供することを課題とする。

課題を解決するための手段

0009

(1)本発明の一態様は、通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、を含むことを特徴とするデータ構造である。

0010

(2)また、本発明の一態様は、通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、を含むデータ構造のアクセス制御規則を生成する生成装置である。

0011

(3)また、本発明の一態様は、通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、を含むデータ構造のアクセス制御規則を生成する生成方法である。

0012

(4)また、本発明の一態様は、コンピュータに、通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、を含むデータ構造のアクセス制御規則を生成させるためのプログラムである。

発明の効果

0013

本発明のデータ構造、生成装置、生成方法およびプログラムによれば、アクセス制御規則の記述量を削減することができる。

図面の簡単な説明

0014

本発明の実施形態に係る通信システムの構成の一例を示す概略図である。
本発明の実施形態に係るアクセス制御規則を表すデータの一例を示す概略図である。
本発明の実施形態に係る通信システムの一例を示す概略ブロック図である。
本発明の実施形態に係る通信システムの処理の一例を示すシーケンス図である。
本発明の実施形態に係るリソースアクセス制御装置のハードウェア構成の一例を示すハードウェア構成図である。

実施例

0015

(実施形態)
以下、本発明の実施形態について、図面を参照して詳細に説明する。

0016

図1は、本発明の実施形態に係る通信システム1の構成の一例を示す概略図である。
通信システム1は、ゲートウェイ(GW:GateWay)11〜12と、ストレージ21〜22と、アプリケーション31〜32と、レジストリ(リソース情報管理装置)40と、リソースアクセス制御装置(RAM:Resource Access Manager)50と、センサ111およびセンサ121〜122と、アクチュエータ112と、ACM(アクセス制御装置)60およびアクセス制御装置70と、を備える。GW11には、センサ111と、アクチュエータ112と、ACM60と、が接続されている。GW12には、センサ121およびセンサ122が接続されている。センサ111、121、122およびアクチュエータ112を総称して、デバイス機器と称する。デバイス機器、ストレージ21〜22、およびアプリケーション31〜32は、それぞれコンポーネントの一例である。また、各GW11〜12で管理される各デバイス機器から取得されるデータの単位をポイントと称する。

0017

各デバイス機器は、購入移設メンテナンスの管理の単位となる機器製品であり、例えば電力センサ温度センサなどのセンサやスマートタップスマートメータ空調機器などの電源温度制御などが可能なアクチュエータなどであり、一つまたは複数のセンサ、スイッチなどを搭載する。各デバイス機器は、例えば、各GW11〜12に接続されている。例えば、デバイス機器が電力計測器である場合、デバイス機器は、電力値などのセンサデータを管理される各GW11〜12に送信する。また、例えば、各デバイス機器は、各GW11〜12によるスイッチ制御に従って、搭載するスイッチのオンオフ切り替える。

0018

各GW11〜12は、配下に1または複数のデバイス機器を収容し、ネットワークを介して他のコンポーネント(例えば、他のGW、ストレージ21〜22、アプリケーション31〜32)やレジストリ40と通信する。また、各GW11〜12は、配下に管理するデバイス機器の情報を管理、記憶する。
また、各GW11〜12は、レジストリ40に対してコンポーネントの情報の登録、ポイントの情報の登録や、通信対象のコンポーネント、通信対象のポイントなどの検索を行う。また、各GW11〜12が何らかの要求に対して応答するレスポンダー(Responder)となる場合には、アクセス制御規則(ACL:Access Control List)をレジストリ40(またはリソースアクセス制御装置50)から取得し、さらに通信対象のコンポーネントのコンポーネント情報、通信対象のポイントのポイント情報を取得する。

0019

各ストレージ21〜22は、各GW11〜12の配下に接続され、かつ各GW11〜12によって各デバイス機器から取得されたデータや、各アプリケーション31〜32によって生成または加工されたデータを記憶する。各ストレージ21〜22は、他のコンポーネントに対してデータを提供したり、他のコンポーネントからデータを取得したりする。各ストレージ21〜22は、レジストリ40とも通信を行い、レジストリ40に対して通信対象のコンポーネントや通信対象のポイントを検索する。また、各ストレージ21〜22は、アクセス制御規則をレジストリ40(またはリソースアクセス制御装置50)から取得する。

0020

各アプリケーション31〜32は、例えば、各GW11〜12や各ストレージ21〜22からデータを取得し、取得したデータを表示する。また、各アプリケーション31〜32は、例えば、取得したデータを加工して他のコンポーネントに提供する。また、各アプリケーション31〜32は、例えば、各GW11〜12の配下のデバイス機器に対して制御の命令を行う。また、各アプリケーション31〜32は、レジストリ40と通信を行い、レジストリ40に対して通信対象のコンポーネントや通信対象のポイントを検索する。また、各アプリケーション31〜32は、アクセス制御規則をレジストリ40(またはリソースアクセス制御装置50)から取得する。

0021

レジストリ40は、各種コンポーネントのコンポーネント情報と各種ポイントのポイント情報とを一元管理して提供することが可能なディクショナリ機能として機能する機構である。例えば、レジストリ40は、リソース情報(例えば、各種コンポーネントの情報と各種ポイントの情報と)を一元管理する。ここで、リソース情報は、通信システム1を構成し、稼動させるためのハードウェアに関する情報や、ソフトウェアに関する情報である。レジストリ40は、記憶している各種コンポーネントの情報と各種ポイントの情報とをリソースアクセス制御装置50に送信する。レジストリ40は、コンポーネント情報だけでなく、コンポーネントの配下で管理されているポイント情報も管理する。コンポーネント情報は、例えばコンポーネントのそのものの情報と当該コンポーネントが管理するポイント情報である。ポイント情報は、ポイントそのものの属性情報(場所、センサの種別など)である。

0022

具体的には、例えばレジストリ40は、コンポーネントを識別するコンポーネント識別情報と該コンポーネントに属するポイントを識別するポイント識別情報との対応関係が記憶されている記憶部を備える。これにより、コンポーネントとポイントの所属関係を管理することができる。レジストリ40で管理されている情報は、各種コンポーネントから専用のインターフェースを用いて登録、更新および削除などが可能である。

0023

リソースアクセス制御装置(RAM:Resource Access Manager)50は、アクセス制御規則を管理して配布する機構である。具体的には、リソースアクセス制御装置50は、アクセス制御規則を生成して、生成したアクセス制御規則を管理・記憶し、管理・記憶するアクセス制御規則を配布する。なお、リソースアクセス制御装置50は、生成したアクセス制御規則をレジストリ40に記憶させてもよい。なお、リソースアクセス制御装置50は、セキュリティのポリシー情報事前に記憶し、システムの構成が変更された場合やポリシー情報が変更された場合に、随時、当該リソースアクセス制御装置50を起動することでACLを更新してもよい。

0024

各ACM(アクセス制御装置)60、70は、アクセス制御を行う。具体的には、例えば、各ACM60、70はコンポーネントレベルの認証(IEEE1888.3の規定の中ではAM(Access Manager)とも呼ばれる)と、コンポーネントレベルのアクセス制御と、ポイントのアクセス制御と、手順レベルやメソッドレベルのアクセス制御などを実行する。各ACM60、70は、主としてレスポンダーとなるコンポーネント(コンポーネントレベルの認証の場合にはレスポンダー、イニシエータの両方)や、レジストリ40が使用する。各ACM60、70の運用形態は、2つ存在し、コンポーネントやレジストリ40などがそれぞれ各ACM60、70を実装して運用する運用形態と、通信システム1内に各ACM60、70が存在し、当該各ACM60、70に各コンポーネントやレジストリ40が問い合わせを行うことで運用する運用形態と、がある。

0025

本実施形態では、コンポーネントやレジストリ40などがそれぞれ、各ACM60、70を実装する場合には、コンポーネントの各ACM60、70が用いるアクセス制御規則をリソースアクセス制御装置50から取得する。一方、通信システム1内に各ACM60、70が存在し、当該各ACM60、70に各コンポーネントやレジストリ40が問い合わせを行うことで運用する場合には、コンポーネントがリソースアクセス制御装置50に特定のアクセス制御規則を問い合わせるため、リソースアクセス制御装置50がACMのように振る舞ってもよい。

0026

次いで、本実施形態に係るアクセス制御規則に含まれるアクセス制御ルールの記述形式の一例について説明する。当該記述形式は、レジストリ40が管理しているポイント情報の登録および検索を行うマークアップ言語(XML:Extensible Markup Language)に従う。
例えば、アクセス制御ルールの記述が以下に示す場合について説明する。
<point id =“http://{meta}/{responder}/{initiator}/{method}/{point}” point =“{point}” responder =“{responder}” Initiator= “{Initiator}” policy =“{policy}” method =“{method}” />

0027

まず、アクセス制御ルールの記述のうち領域{meta}について説明する。
この領域は、コンポーネントが管理するデータであるポイントのポイント情報を記述する領域である。当該領域は、point情報がアクセス制御規則の記述形式であることを表す。特に、レジストリ40においてポイント情報とアクセス制御規則の情報とをまとめて管理している場合、当該領域{meta}において、レジストリ40および通信するコンポーネントがその情報がポイント情報かアクセス制御規則の情報かを区別することができることが望ましい。これを簡易に実現するには、アクセス制御規則の情報であることを表すような記述をid内に記述すればよい。なお、レジストリ40とリソースアクセス制御装置50が独立して運用される場合などではこの記述を用いなくてもよい。

0028

次いで、アクセス制御ルールの記述のうち領域{responder}について説明する。当該領域は、レスポンダーの識別情報を記述する領域である。レスポンダーの識別情報とは、例えば、レスポンダーのコンポーネントURI(Uniform Resource Identifer)またはレスポンダーの識別情報(IEEE1888.3のコンポーネント識別で用いられる証明書内のSAN(Subject Alternative Name)など)である。

0029

次いで、アクセス制御ルールの記述のうち領域{initiator}について説明する。当該領域は、イニシエータの識別情報を記述する領域である。イニシエータについては、コンポーネントURIを持たない場合も多い。このため、イニシエータの識別情報SANを用いることが好ましい。

0030

次いで、アクセス制御ルールの記述のうち領域{point}について説明する。当該領域{point}は、コンポーネントが管理するポイントのID(識別情報:Identifer)(ポイントレベルでのアクセスコントロール時のアクセスコントロールの対象となるポイント)記述する領域である。また、すべてのポイントに共通のアクセス制御規則を設定する場合には、当該領域にワイルドカード「*」といった記述を用いてもよい。

0031

次いで、アクセス制御ルールの記述のうち領域{policy}について説明する。当該領域は、アクセス可否を表すアクセス可否情報を記述する領域である。具体的には、当該領域には、OK、NG、またはallow、denyなどが記述される。例えば、OK、allowは、アクセスを許可することを表し、NG、denyは、アクセスを許可しないことを表す。なお、アクセス制御規則において、アクセスを許可することを表すアクセス可の情報しか扱わない、またはアクセスを許可しないことを表すアクセス否の情報しか扱わないといった運用をする場合には、この記述はなくてもよい。

0032

次いで、アクセス制御ルールの記述のうち領域{method}について説明する。当該領域は、手順またはメソッドレベルでのアクセス制御を実現する場合に用いる領域である。具体的には、手順はFETCH、WRITE、TRAPなどであり、メソッドレベルでのアクセス制御は、query、dataなどである。なお、手順またはメソッドレベルでのアクセス制御を行わない場合、当該領域は不要である。

0033

次に、アクセス制御ルールの記述におけるXML形式の記述について説明する。
id属性の記述形式については、以下に示す形式が必須ではなく、一例として説明する。例えば、アクセス制御ルールの記述が上述のように「point id =“http://{meta}/{responder}/{Initiator}/{method}/{point}”」である場合、当該記述が「point id =“http://{meta}/{Initiator}/{method}/{point}/{responder}”」のように、記載順序が変わってもよい。id属性の記述形式で必須の条件は、以下の通りである。
(1)異なるアクセス制御規則(例えば、あるレスポンダーの特定のポイントに対するアクセス制御規則についてイニシエータがAのものとBのものとが存在するときなど)は異なるidになること。
(2)同じアクセス制御規則(例えばポイントレベルまでのアクセス制御規則を記述しているのであれば、あるレスポンダーの特定のポイントに対して特定のイニシエータからのアクセスに関するアクセス制御規則)は同じidになること。

0034

上記2つのid属性の記述形式で必須の条件は、レジストリ40のポイント情報がidを主キーとしているためである。そのためこれらの条件を満たすことで、以下のことが可能となる。
(1)管理したいアクセス制御規則を漏れなくレジストリで管理すること(異なるアクセス制御規則を上書きしない)。
(2)アクセス制御規則が更新される場合などに、適切にアクセス制御規則を更新すること(アクセス制御規則が変更された場合に、そのアクセス制御規則を上書きできる)。

0035

また、アクセス制御ルールの記述におけるXML形式の記述について、システム内で必要とするアクセス制御規則の粒度に従って、アクセス制御規則の記述形式は書き換えてよい。例えば、メソッド単位のアクセス制御を行わない場合には、method属性およびidの{method}部分は省略してもよい。逆に、時間ごとのアクセス制御まで必要とする場合は、随時、属性に「time=“{time}”」のような属性を追記し、idもそれにあわせて、例えば、「id=“http://{meta}/{Initiator}/{method}/{point}/{responder}/{time}”」といった属性を追加してもよい。

0036

また、アクセス制御ルールの記述におけるXML形式の記述について、アクセス制御規則で記述される属性は、アクセス制御規則ではないポイント情報と異なる名前名前空間)であることが望ましい。例えば、システム構築段階で単なる(アクセス制御規則ではない)ポイント情報でも「Initiator」属性を登録または検索する可能性がある場合は、アクセス制御規則では異なる属性名もしくは名前空間を使用する。これは、ポイントの検索時(アクセス制御規則の検索時)にアクセス制御規則の情報(ポイント情報)が応答されないようにするためである。

0037

また、レジストリ40がポイント情報の削除機能を持っていない場合も想定される。この場合には、アクセス制御規則が不要になった場合でも、一旦登録されたアクセス制御規則をレジストリ40から削除することが困難になる。このような場合は、以下のようなデータモデルを用いることで対応することが可能である。
<point id =“http://{meta}/{responder}/{Initiator}/{method}/{point}” point =“{point}” responder =“{responder}” Initiator =“{Initiator}” policy =“{policy}” method =“{method}” valid=“{valid}”/>
ここで、validには、“true”または“false”が記述される。

0038

この記述例を用いて運用する場合、アクセス制御規則が不要になった場合には、valid=“false”と記述して登録する(有効であれば“true”と記述する)。この場合、アクセス制御規則を取得するコンポーネントは、ポイント検索の条件に「valid=“true”」と記述することで、必要のないアクセス制御規則を除外して取得することができる。
このように、アクセス制御規則を記述することで、ルールが更新されて、特定のアクセス制御規則が存在しなくなった場合でもそれを識別することが可能である。また、レジストリ40側もその情報に基づいて、ポイント情報を削除することも可能になる。

0039

具体例として、図2、3に示す通信システムとその運用ルールが定義されている場合におけるアクセス制御規則の記述の一例を以下に示す。
図2は、本実施形態に係る通信システムの一例を示す概略図である。また、図3は、図2に示す通信システムの運用ルールの定義の一例を示す概略図である。
図2に図示する例では、テーブルT1は、レスポンダー(responder)、イニシエータ(initiator)、ポリシー(Policy)、ポイント(point)の各項目列を有する。
テーブルT1では、レスポンダーと、それに対応する各イニシエータと、アクセス可否情報とポイント情報とが対応付けられている。
図3に図示する例では、リソースアクセス制御装置50は、レジストリ40と、アプリケーション31、32と、GW11と、ストレージ21と、通信する。GW11は、配下に第1ポイントと第2ポイントとが接続され、これらのポイントと通信する。ストレージ21は、第1ポイントと第3ポイントとが接続され、これらのポイントと通信する一例である。

0040

<point id =“http://.ACL/Storage/APP1/A” point=“A” responder =“Storage” Initiator =“APP1” policy =“OK” valid =“true”/>
<point id =“http://.ACL/Storage/APP1/C” point =“C” responder =“Storage” Initiator =“APP1” policy =“OK” valid =“true”/>
<point id =“http://.ACL/Storage/APP2/A” point =“A” responder =“Storage” Initiator =“APP2” policy =“OK” valid =“true” />
<point id =“http://.ACL/Storage/APP2/C” point =“C” responder =“Storage” Initiator =“APP2” policy =“NG” valid =“true” />
<point id =“http://.ACL/GW/APP1/A” point =“A” responder =“GW” Initiator =“APP1” policy =“OK” valid =“true”/>
<point id =“http://.ACL/GW/APP1/B” point =“B” responder =“GW” initiator =“APP1” policy =“NG” valid =“true”/>
<point id =“http://.ACL/GW/APP2/A” point =“A” responder =“GW” Initiator =“APP2” policy =“OK” valid =“true”/>
<point id =“http://.ACL/GW/APP2/B” point =“B” responder =“GW” Initiator =“APP2” policy =“NG” valid =“true”/>

0041

上記アクセス制御規則をレジストリ40に登録する場合は、IEEE1888で標準化されているレジストリ40のインターフェースを用いることが可能である。以下、レジストレーション手順(REGISTRATION手順)を用いてレジストリ40に登録する場合に、送信すべき電文の一例を示す。なお、ここでは名前空間(namespace)の記述などは省略する。

0042

<transport>
<body>
<point id =“http://.ACL/Storage/APP1/A” point =“A” responder =“Storage” Initiator =“APP1” policy =“OK” valid =“true” />
<point id =“http://.ACL/Storage/APP1/C” point =“C” responder =“Storage” Initiator =“APP1” policy =“OK” valid =“true” />
<point id =“http://.ACL/Storage/APP2/A” point =“A” responder =“Storage” Initiator =“APP2” policy =“OK” valid =“true” />
<point id =“http://.ACL/Storage/APP2/C” point =“C” responder =“Storage” Initiator =“APP2” policy =“NG” valid =“true” />
<point id =“http://.ACL/GW/APP1/A” point =“A” responder =“GW” Initiator =“APP1” policy =“OK” valid =“true>
<point id =“http://.ACL/GW/APP1/B” point =“B” responder =“GW” Initiator =“APP1” policy =“NG” valid =“true”>
<point id =“http://.ACL/GW/APP2/A” point =“A” responder =“GW” Initiator =“APP2” policy =“OK” valid =“true”>
<point id =“http://.ACL/GW/APP2/B” point =“B” responder =“GW” Initiator =“APP2” policy =“NG” valid =“true”>
</body>
</transport>

0043

上記電文は、さらに、記述のグループ化により、電文量(アクセス制御規則の管理量)を削減することが可能である。ここでは、イニシエータのグループ化の記述と、複数のアクセス制御規則をまとめた記述について述べる。グループについては前述したアクセス制御規則の情報を補足するものとして活用する。
これらの記述についても、特定の記述形式としての制限はないが、別のグループ情報やアクセス制御規則、ポイント情報、id属性が重複しないようにする。
まず、グループ化の表記方法としてイニシエータのグループ化記述の一例を説明する。これは、大量のイニシエータが存在し、かつそれらが共通のアクセスポリシーを持つ場合などに有効である。

0044

イニシエータのグループを記述するには以下のような情報をpoint 情報として登録する。
(1)
記述例
<point id =“http://.ACL/group/{group}” group =“{group}” Initiator =“{Initiator}”>
具体例
<point id =“http://.ACL/group/initiatorA” group =“GroupA” Initiator =“initiatorA”>
<point id =“http://.ACL/group/initiatorB” group =“GroupA” Initiator =“initiatorB”>

0045

(2)
記述例
<point id =“http://.ACL/group/{group}” initiatornum=“{num}” intiator{n}=“{Initiator}”(n個分記述)>
具体例
<point id =“http://.ACL/group/groupA” initiatornum =“2” intiator0 =“initiatorA” intiator1 =“initiatorB”>

0046

これらの記述は、(1)、(2)のどちらでも「initiatorA」 と「initiatorB」とを同じグループとして表現している。このとき、アクセス制御規則の記述は、以下のようになる。
<point id =“http://.ACL/GW/groupA/B” point =“B” responder =“GW” Initiator =“groupA” policy =“NG” valid =“true”>

0047

これらの情報は、(1)、(2)のどちらでもレジストリ40のポイント情報として管理される。レスポンダーは、必要に応じてその情報を検索する。
この情報は、リソースアクセス制御装置50から登録される。この場合、レスポンダーは、アクセス制御規則だけでなく、グループの情報もレジストリ40(またはリソースアクセス制御装置50)に対して問い合わせる必要がある。
次に複数のアクセス制御規則をまとめて記述し、情報量を削減する場合の記述について説明する。具体例として、複数のポイントをまとめてアクセス制御規則として記述する一例について説明する。

0048

<point id =“http://.ACL/responderA/initiatorA/PointA/pointB” Initiator =“initiatorA” responder =“responderA” method =“FETCH” policy =“OK” pointnum=“2” point0 =“pointA” point1 =“pointB”>

0049

この記述では、「pointA」と「pointB」についてFETCHメソッドで、「initiatorA」からのアクセスに対し「responderA」がOKであることを表している。

0050

また、同様に複数のメソッドをまとめて表記することなども可能である。
<point id =“http://.ACL/Storage/APP2/C” point =“C” responder =“Storage” Initiator =“APP2” policy =“NG” method =“FETCH|WRITE”>
これらのXML記述の効率化については、システム内で記述ルール統一することで実現することが可能である。

0051

図4は、本発明の実施形態に係る通信システムにおけるシーケンス図である。
テップST100において、レスポンダーは自装置を起動させる。
ステップST101において、レスポンダーは、自身のコンポーネント情報やポイント情報をレジストリ40に登録する。
ステップST102において、レジストリ40は、リソースアクセス制御装置50にレスポンダーのコンポーネント情報やポイント情報の登録が完了したことを表す登録通知を送信する。リソースアクセス制御装置50は、登録通知を受信すると、登録されたコンポーネント情報やポイント情報に基づいて、レスポンダーのアクセス制御規則を生成する。または、リソースアクセス制御装置50は、予めレスポンダーに対するアクセス制御規則を生成しておく。

0052

ステップST103において、リソースアクセス制御装置50は、生成したアクセス制御規則を、REGISTRATION手順を用いてレジストリ40に登録する。なお、リソースアクセス制御装置50とレジストリ40とが同一の装置である場合には、直接追加すればよい。
ステップST103aにおいて、イニシエータは自装置を起動させる。
ステップST104において、イニシエータは、通信相手であるレスポンダーを見つけるために、LOOKUP手順を用いてレジストリ40を検索する。
ステップST105において、レジストリ40は、応答としてコンポーネント情報やポイント情報をイニシエータに送信する。このとき、レジストリ40の情報自体にもアクセス制御規則が設定されている場合は、通信先として許可された装置にのみ応答を送信する。この場合に、イニシエータのアクセス制御が実施されることになる。

0053

ステップST106において、イニシエータは、FETCH/WRITE/TRAP手順によるデータや制御結果を取得するための問合せ(要求)をレスポンダーに対して行う。
ステップST107において、レスポンダーは、LOOKUP手順を用いてアクセスしてきたイニシエータがアクセス可能か否かを表すアクセス制御規則をレジストリ40に対して問い合わせる。

0054

具体的には、以下のようなLOOKUP手順を用いてアクセス制御規則を問い合わせる。
(1)全てのアクセス制御規則を取得する場合(自身を「responderA」とする)
<transport>
<header>
<lookup type=“point” id=“...”>
<point responder=“responderA”/>
</lookup>
</header>
</transport>
(2)特定のアクセス制御規則を取得する場合(イニシエータが「initiatorA」であり、pointXにアクセスしてきた場合)
<transport>
<header>
<point responder =“responderA” Initiator =“Initiator
<point responder =“responderA” Initiator =“Initiatora” point =“pointX” />
</lookup>
</header>
</transport>

0055

ステップST108において、レジストリ40は、応答としてアクセス可否情報を含むアクセス制御規則をレスポンダーに送信する。
ステップST109において、レスポンダーは、レジストリ40から受信したアクセス制御規則を参照し、ステップST106において問い合わせを受信したFETCH/WRITE/TRAP手順によるデータや制御結果を取得するための問合せ(要求)を送信したイニシエータがデータや制御結果に対するアクセスが許可されている場合、応答として当該問い合わせ(要求)に基づくデータや制御結果を当該イニシエータに送信する。
このように、リソースアクセス制御装置50は、アクセス制御規則を記述して、記述したアクセス制御規則をレジストリ40に記憶させる。なお、リソースアクセス制御装置50は、レジストリ40の機能を備え、リソースアクセス制御装置50とレジストリ40との機能を備えるようにしてもよい。

0056

図5は、本発明の実施形態に係るリソースアクセス制御装置50のハードウェア構成の一例を示すハードウェア構成図である。
リソースアクセス制御装置50は、CPU501と、記憶媒体502と、ドライブ部503と、入力部504と、出力部505と、ROM506(Read Only Memory:ロム)と、RAM507(Random Acccess Memory:ラム)と、補助記憶部508と、通信部509と、を備える。
CPU501と、ドライブ部503と、入力部504と、出力部505と、ROM506と、RAM507と、補助記憶部508と、通信部509とは、バスB(母線)を介して相互に接続される。

0057

CPU501は、補助記憶部508が記憶するプログラム、ROM506およびRAM507が記憶する各種データを読み出して実行し、リソースアクセス制御装置50を制御する。また、CPU501は、ドライブ部503を介して記憶媒体502が記憶する各種データを読み出して実行し、リソースアクセス制御装置50を制御する。記憶媒体502は、光磁気ディスクフレキシブルディスクフラッシュメモリなどの可搬記憶媒体であり、各種データを記憶する。ドライブ部503は、光ディスクドライブフレキシブルディスクドライブなどの記憶媒体502の読み出し装置である。入力部504は、マウスキーボードタッチパネルなどの入力装置である。出力部505は、表示部、スピーカなどの出力装置である。ROM506、RAM507は、各種データを一時的に記憶する。補助記憶部508は、ハードディスクドライブ、フラッシュメモリなどであり、上述したリソースアクセス制御装置50の各機能部を動作させるためのプログラム、各種データを記憶する。通信部509は、通信インターフェースを有し、有線または無線によりネットワークNWに接続される。

0058

このように、本実施形態によれば、データ構造は、通信システムの構成機器であるコンポーネントから取得されるデータであるポイントのポイント情報を記述する領域と、前記ポイントのポイント識別情報を記述する領域と、要求を送信するイニシエータのイニシエータ識別情報を記述する領域と、前記要求に対する応答をする側の装置であるレスポンダーの識別情報を記述する領域と、前記イニシエータがリソース情報管理装置へのアクセスを許可するか否かを表すアクセス可否情報を記述する領域と、を含む。

0059

これにより、アクセス制御規則の記述量を削減することができ、当該記述を通信する通信量を削減することができる。また、1度の問合せで必要なアクセス制御規則を取得することができる。
さらに、本実施形態では、IEEE1888で規定されているレジストリとそのインターフェースを用いてアクセス制御規則を管理するため、IEEE1888で規定されているレジストリが持つインターフェースと動作の振る舞いをそのまま活用することができる。また、アクセス制御規則を取得するレスポンダー(アクセスされる側のコンポーネント)も新たなインターフェースを設計する必要がなく、必要なアクセス制御規則を指定して取得する場合でも、レジストリが持っている検索機能をそのまま活用することができる。

0060

また、レスポンダーがアクセス制御規則を検索する際は、取得したいアクセス制御規則を「指定したポイント」や「指定したイニシエータ(アクセスする側のコンポーネント)」などの組み合わせで検索することが可能であるため、既存の方式(存在するイニシエータの数やポイントの数などを事前に問い合わせる必要があるため、結果として複数回の問い合わせが必要となる)と比べて、1回の問い合わせでアクセス制御規則を取得することができるため、問い合わせ途中に発生した更新によって整合性が保てなくなるといった事例も発生しない。また、本実施形態では、記述されるアクセス制御規則の電文形式は存在するイニシエータの数やポイントの数などといった情報をアクセス制御規則の中に記述する必要がなくなるため、アクセス制御規則の電文量自体を削減することができる。

0061

なお、本発明の各実施形態のリソースアクセス制御装置50の各処理を実行するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、当該記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、リソースアクセス制御装置50に係る上述した種々の処理を行ってもよい。

0062

なお、ここでいう「コンピュータシステム」とは、OSや周辺機器等のハードウェアを含むものであってもよい。また、「コンピュータシステム」は、WWWシステムを利用している場合であれば、ホームページ提供環境(あるいは表示環境)も含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、フラッシュメモリ等の書き込み可能不揮発性メモリCD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。

0063

さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバクライアントとなるコンピュータシステム内部の揮発性メモリ(例えばDRAM(Dynamic Random Access Memory))のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク(通信網)や電話回線等の通信回線(通信線)のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル差分プログラム)であっても良い。

0064

以上、本発明の実施形態について図面を参照して詳述したが、具体的な構成はこの実施形態に限られるものではない。各実施形態における各構成およびそれらの組み合わせ等は一例であり、本発明の趣旨から逸脱しない範囲内で、構成の付加、省略、置換、およびその他の変更が可能である。また、本発明は実施形態によって限定されることはなく、特許請求の範囲によってのみ限定される。

0065

1・・・通信システム、11、12・・・ゲートウェイ(GW)、21、22・・・ストレージ、31、32・・・アプリケーション、40・・・レジストリ(リソース情報管理装置)、50・・・リソースアクセス制御装置(RAM)、501・・・CPU、502・・・記憶媒体、503・・・ドライブ部、504・・・入力部、505・・・出力部、506・・・ROM、507・・・RAM、508・・・補助記憶部、509・・・通信部、60、70・・・ACM(アクセス制御装置)、111、121、122・・・センサ、112・・・アクチュエータ

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 株式会社メガチップスの「 情報処理装置及び被判定装置の真贋判定方法」が 公開されました。( 2020/10/29)

    【課題】被判定装置の動作環境要素が変動した場合であっても、被判定装置の真贋判定を高精度に実行することが可能な、情報処理装置、プログラム及び被判定装置の真贋判定方法を提供する。【解決手段】メモリシステム... 詳細

  • 株式会社カシカの「 情報処理装置、システム及びプログラム」が 公開されました。( 2020/10/29)

    【課題】コンテンツを容易に悪用することを防止することのできる情報処理装置、システム及びプログラムを提供すること。【解決手段】本発明によれば、受付部と提供部とを備え、前記受付部は、通信可能な端末からの取... 詳細

  • 徳山真旭の「 情報処理システム、情報処理方法、及びプログラム」が 公開されました。( 2020/10/29)

    【課題】簡便にアプリケーションソフトウエアのライセンスを使い回すことができる情報処理システム、情報処理方法、及びプログラムを提供する。【解決手段】情報処理システム100は、アプリケーションソフトウエア... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ