図面 (/)

技術 アクセス管理装置及びアクセス管理方法

出願人 日本電信電話株式会社
発明者 馬越健治坂野遼平
出願日 2018年9月11日 (2年8ヶ月経過) 出願番号 2019-543565
公開日 2020年3月26日 (1年1ヶ月経過) 公開番号 WO2019-059034
状態 特許登録済
技術分野 広域データ交換 計算機・データ通信
主要キーワード 工場管理者 インターフェイス毎 APIサーバ 消費リソース 同時アクセス数 中継可否 バイタルデータ アクセス管理装置
関連する未来課題
重要な関連分野

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

図面 (9)

課題・解決手段

本発明によれば、複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて一元的なアクセス管理を実現することができるアクセス管理装置を提供する。 本発明のアクセス管理装置は、アクセス元(AS)と複数の処理系(PS)との間に接続され、アクセス元(AS)からのアクセス要求を受信し、設定されたアクセス管理ポリシーに基づいて、アクセス要求の制御を行なうアクセス管理機能部(22)を有するゲートウェイ(11)とを具備する。

概要

背景

IoT(Internet of Things)サービスを容易に構築可能とする基盤(IoT基盤)が注目を集めている。IoT基盤においては、多様なサービスを実現するため、異種の処理系(データ管理データ配信等)を備え、また、これら処理系に適した異種のプロトコル(Hypertext Transfer Protocol(HTTP)、Message Queueing Telemetry Transport(MQTT)等)に対応することが想定されている。

従って、これら処理系に入出力されるデータを管理するニーズが存在する。ここで、「管理」とは、アクセス制御同時アクセス制限、優先制御などを含む。また、処理系に入出力されるデータには、機微なデータが含まれ得る。機微なデータとしては、例えば、製造業における生産工程に関するデータ、個人バイタルデータなどである。

従来、IoT基盤では、各処理系がそれぞれ、アプリケーションプログラム(以下、「アプリ」という。)やデバイスに対応するインターフェイスを備えている。このため、これらインターフェイス毎に、個別にアクセス管理機構実装する(=個別対応)ことで、アクセス管理を実現することが可能である。図7は、従来のIoT基盤Sのアクセス管理装置概要を示す図である。同図に示すように、アクセス元AS−1〜AS−Nに対応するIoT基盤Sの各処理系PS−1〜PS−Nは、アクセス管理機構を有している。

図5は、アクセス元であるアプリAP−1〜AP−3及びデバイスDB−1〜DB−5と各処理系PS−1〜PS−4との関係を示す図である。

同図において、アクセス元であるアプリAP−1〜AP−3及びデバイスDB−1〜DB−5は、IoT基盤Sのデータ処理系PS−1〜PS−4にアクセス可能である。各データ処理系PS−1〜PS−4は、アクセス元であるアプリAP−1〜AP−3及びデバイスDB−1〜DB−5に対応するインターフェイスを備えており、各インターフェイス毎にアクセス管理機構を実装している。

ここで、データ処理系PS−1はデータ管理に関する処理、データ処理系PS−2はデータ配信に関する処理、データ処理系PS−3はデータ分析に関する処理、データ処理系PS−4はデバイス制御に関する処理を行なう。また、デバイスDB−1は車、デバイスDB−2、デバイスDB−3はスマートフォン、デバイスDB−4はオシロスコープ、デバイスDB−5はアクチュエータを示す。

プロトコルと処理系の組み合わせ毎にアクセス管理機構を用意するものとして、例えば、非特許文献1には、RESTAPIに関する市中のアクセス制御技術が開示されており、非特許文献2には、MQTTブローカに関する市中のアクセス制御技術が開示されている。

概要

本発明によれば、複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて一元的なアクセス管理を実現することができるアクセス管理装置を提供する。 本発明のアクセス管理装置は、アクセス元(AS)と複数の処理系(PS)との間に接続され、アクセス元(AS)からのアクセス要求を受信し、設定されたアクセス管理ポリシーに基づいて、アクセス要求の制御を行なうアクセス管理機能部(22)を有するゲートウェイ(11)とを具備する。

目的

本発明は、上記実情に鑑みてなされたものであり、アクセス管理機構を処理系やプロトコルから独立したゲートウェイとして構成できるようにし、設定されたアクセス管理ポリシーに基づいて一元的なアクセス管理を実現することができるアクセス管理装置及びアクセス管理方法を提供する

効果

実績

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

この技術が所属する分野

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

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

請求項1

アクセス元と、前記アクセス元からのアクセス要求に対する処理を行なう複数の処理系との間に接続され、前記アクセス元からのアクセス要求を受信し、前記複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なうアクセス管理機能部を有するゲートウェイ具備するアクセス管理装置

請求項2

前記ゲートウェイは、前記アクセス元のIPアドレスに基づいて、前記アクセス元の識別情報を取得し、前記取得したアクセス元の識別情報を前記アクセス管理機能部に送信するアクセス元識別機能部をさらに具備する、請求項1記載のアクセス管理装置。

請求項3

前記アクセス管理ポリシーは、前記ゲートウェイのキャッシュメモリ上に記憶される、請求項1記載のアクセス管理装置。

請求項4

前記ゲートウェイは、前記アクセス管理機能部によってアクセス要求が認められた場合、前記複数の処理系と前記アクセス元との間のプロトコル変換を行なうプロトコル中継機能部をさらに具備する、請求項1記載のアクセス管理装置。

請求項5

前記アクセス管理ポリシーは、前記アクセス元と、前記アクセス元のアクセス先と、前記アクセス元の前記アクセス先への可能な操作とが関連付けられたアクセス制御ポリシーを有する、請求項1記載のアクセス管理装置。

請求項6

前記アクセス管理ポリシーは、前記アクセス元のアクセス先と、前記アクセス元と、前記アクセス元の前記アクセス先への同時アクセス数情報とが関連付けられた同時アクセス数制限ポリシーを有する、請求項1記載のアクセス管理装置。

請求項7

前記アクセス管理ポリシーは、前記アクセス元と、前記アクセス元の前記優先度とが関連付けられた優先制御ポリシーを有する、請求項1記載のアクセス管理装置。

請求項8

アクセス元と、前記アクセス元からのアクセス要求に対する処理を行なう複数の処理系との間に接続され、前記アクセス元からのアクセス要求を受信し、前記複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なうアクセス管理機能部を有するゲートウェイを具備するアクセス管理装置におけるアクセス管理方法において、前記アクセス管理機能部は、前記アクセス元からのアクセス要求を受信し、前記記憶部に記憶されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なう、アクセス管理方法。

請求項9

前記アクセス元のIPアドレスに基づいて、前記アクセス元の識別情報を取得し、前記取得したアクセス元の識別情報を前記アクセス管理機能部に送信する処理を、さらに行う、請求項8記載のアクセス管理方法。

請求項10

前記ゲートウェイのキャッシュメモリ上に前記アクセス管理ポリシーを記憶する処理を、さらに行う、請求項8記載のアクセス管理方法。

請求項11

前記アクセス管理機能部によってアクセス要求が認められた場合、前記複数の処理系と、前記アクセス元との間のプロトコル変換を、さらに行なう、請求項8記載のアクセス管理方法。

請求項12

前記アクセス管理ポリシーは、前記アクセス元と、前記アクセス元のアクセス先と、前記アクセス元の前記アクセス先への可能な操作とが関連付けられたアクセス制御ポリシーを有する、請求項8記載のアクセス管理方法。

請求項13

前記アクセス管理ポリシーは、前記アクセス元のアクセス先と、前記アクセス元と、前記アクセス元の前記アクセス先への同時アクセス数情報とが関連付けられた同時アクセス数制限ポリシーを有する、請求項8記載のアクセス管理方法。

請求項14

前記アクセス管理ポリシーは、前記アクセス元と、前記アクセス元の前記優先度とが関連付けられた優先制御ポリシーを有する、請求項8記載のアクセス管理方法。

請求項15

アクセス元と、前記アクセス元からのアクセス要求に対する処理を行なう複数の処理系との間に接続されたアクセス管理機能部を有するゲートウェイを具備するアクセス管理装置におけるアクセス管理方法を実行するプログラムにおいて、前記プログラムは、前記アクセス機能管理部に、前記アクセス元からのアクセス要求を受信させ、前記複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なわせる、プログラム。

技術分野

0001

本発明は、アクセス管理装置及びアクセス管理方法に関する。

背景技術

0002

IoT(Internet of Things)サービスを容易に構築可能とする基盤(IoT基盤)が注目を集めている。IoT基盤においては、多様なサービスを実現するため、異種の処理系(データ管理データ配信等)を備え、また、これら処理系に適した異種のプロトコル(Hypertext Transfer Protocol(HTTP)、Message Queueing Telemetry Transport(MQTT)等)に対応することが想定されている。

0003

従って、これら処理系に入出力されるデータを管理するニーズが存在する。ここで、「管理」とは、アクセス制御同時アクセス制限、優先制御などを含む。また、処理系に入出力されるデータには、機微なデータが含まれ得る。機微なデータとしては、例えば、製造業における生産工程に関するデータ、個人バイタルデータなどである。

0004

従来、IoT基盤では、各処理系がそれぞれ、アプリケーションプログラム(以下、「アプリ」という。)やデバイスに対応するインターフェイスを備えている。このため、これらインターフェイス毎に、個別にアクセス管理機構実装する(=個別対応)ことで、アクセス管理を実現することが可能である。図7は、従来のIoT基盤Sのアクセス管理装置の概要を示す図である。同図に示すように、アクセス元AS−1〜AS−Nに対応するIoT基盤Sの各処理系PS−1〜PS−Nは、アクセス管理機構を有している。

0005

図5は、アクセス元であるアプリAP−1〜AP−3及びデバイスDB−1〜DB−5と各処理系PS−1〜PS−4との関係を示す図である。

0006

同図において、アクセス元であるアプリAP−1〜AP−3及びデバイスDB−1〜DB−5は、IoT基盤Sのデータ処理系PS−1〜PS−4にアクセス可能である。各データ処理系PS−1〜PS−4は、アクセス元であるアプリAP−1〜AP−3及びデバイスDB−1〜DB−5に対応するインターフェイスを備えており、各インターフェイス毎にアクセス管理機構を実装している。

0007

ここで、データ処理系PS−1はデータ管理に関する処理、データ処理系PS−2はデータ配信に関する処理、データ処理系PS−3はデータ分析に関する処理、データ処理系PS−4はデバイス制御に関する処理を行なう。また、デバイスDB−1は車、デバイスDB−2、デバイスDB−3はスマートフォン、デバイスDB−4はオシロスコープ、デバイスDB−5はアクチュエータを示す。

0008

プロトコルと処理系の組み合わせ毎にアクセス管理機構を用意するものとして、例えば、非特許文献1には、RESTAPIに関する市中のアクセス制御技術が開示されており、非特許文献2には、MQTTブローカに関する市中のアクセス制御技術が開示されている。

先行技術

0009

"What is Kong" 、[online]、Kong−Open−sourceAPI Mnagement and Microservice Management、[平成29年5月1日検索]、インターネット<URL:https://getkong.org/about/>
”mosquitto.conf−the configuration file for mosquitto”、[平成29年5月1日検索]、インターネット<URL:http://mosquitto.org/man/mosquitto−conf−5.html>

0010

しかしながら、従来のアクセス管理機構では、アクセス管理機構毎に設定管理が必要となり、運用コストが大きくなってしまうという問題がある。また、アプリ側でアクセス管理機構毎の対応が必要となり、アプリ開発の負担が大きい。さらに、アクセス管理機構間の管理ポリシーアクセス制御ルール等)の不整合などのリスクも増大する。

0011

さらに、上述のように、アクセス管理機構は、機微なデータを取り扱うため、アプリやデバイスから各処理系へのアクセスに対し、IoT基盤を導入するユーザ(例えば、製造業では、工場管理者)のセキュリティポリシーに基づいて、アクセスの可否等を制御する必要がある。

0012

本発明は、上記実情に鑑みてなされたものであり、アクセス管理機構を処理系やプロトコルから独立したゲートウェイとして構成できるようにし、設定されたアクセス管理ポリシーに基づいて一元的なアクセス管理を実現することができるアクセス管理装置及びアクセス管理方法を提供することを目的とする。

0013

本発明の第1態様は、アクセス管理装置が、アクセス元と、前記アクセス元からのアクセス要求に対する処理を行なう複数の処理系との間に接続され、前記アクセス元からのアクセス要求を受信し、前記複数の処理系のプロトコルに依存せずに設定されたアクセス管理ポリシーに基づいて、前記アクセス要求の制御を行なうアクセス管理機能部を有するゲートウェイを具備するようにしたものである。

0014

本発明の第2態様は、前記ゲートウェイが、前記アクセス元のIPアドレスに基づいて、前記アクセス元の識別情報を取得し、前記取得したアクセス元の識別情報を前記アクセス管理機能部に送信するアクセス元識別機能部をさらに具備するようにしたものである。

0015

本発明の第3態様は、前記アクセス管理ポリシーを、前記ゲートウェイのキャッシュメモリ上に記憶するようにしたものである。

0016

本発明の第4態様は、前記ゲートウェイは、前記アクセス管理機能部によってアクセス要求が認められた場合、前記複数の処理系と前記アクセス元との間のプロトコル変換を行なうプロトコル中継機能部をさらに具備するようにしたものである。

0017

この発明の第1の態様によれば、複数の処理系に対して、ゲートウェイによりアクセス管理を一元的に管理することにより、運用コストを低減することができるとともに、アクセス管理ポリシーの不整合リスクを防ぐことができる。

0018

この発明の第2の態様によれば、低レイヤプロトコル情報(IPアドレス)を用いてアクセス元IDを取得することで、上位レイヤプロトコルに依存しないアクセス元識別情報を実現することができる。

0019

この発明の第3の態様によれば、アクセス管理ポリシーをオンメモリキャッシュするため、高速なアクセス管理処理を実現することができる。

0020

この発明の第4の態様によれば、プロトコル中継機能部は、アクセス管理機能部とは別に設けられているので、アクセス管理のみを一元的に管理することができる。

0021

本発明の各態様によれば、アクセス管理機構を処理系やプロトコルから独立したゲートウェイとして構成することができ、設定されたアクセス管理ポリシーに基づいて一元的なアクセス管理を実現することができるアクセス管理装置及びアクセス管理方法を提供できる。

図面の簡単な説明

0022

本発明の実施形態のIoT基盤Sの構成を説明するための図である。
アクセス管理ポリシーDB31に格納されるアクセス管理ポリシーの一例を示す図である。
実施形態に係るIoT基盤Sのアクセス管理の第1動作について説明するためのタイミングチャートである。
実施形態に係るIoT基盤Sのアクセス管理の第2動作について説明するためのタイミングチャートである。
アクセス元であるアプリAP−1〜AP−3及びデバイスDB−1〜DB−5と各処理系PS−1〜PS−4との関係を示す図である。
実施形態に係るIoT基盤Sのアクセス管理装置の概要を示す図である。
従来のIoT基盤Sのアクセス管理装置の概要を示す図である。
従来の個別対応のアクセス管理と、本発明の一元管理のアクセス管理との効果を説明するための図である。

実施例

0023

以下、図面を参照して、本発明の実施形態について説明する。なお、実施形態において、構成要素を区別して説明する必要がない場合には、ハイフンを省略して説明する。例えば、アクセス元AS−1、AS−2、…、AS−nを区別して説明する必要がない場合には、ハイフンを省略して「AS」として説明する。他の構成要素についても同様に説明する。

0024

図1は、本発明の実施形態のIoT基盤Sの構成を説明するための図である。同図に示すように、IoT基盤Sは、複数の処理系PS−1〜PS−N、複数の処理系PS−1〜PS−Nに対応して設けられたプロトコルインターフェイスIF−1〜IF−N、アクセス管理ゲートウェイ11、アクセス管理ポリシーDB31を有する。

0025

アクセス管理ゲートウェイ11は、アプリやデバイスなどの複数のアクセス元AS−1〜AS−Nと、複数の処理系PS−1〜PS−Nとの間に配置され、プロトコル中継機能部21、アクセス管理機能部22、キャッシュ部23及びアクセス元識別機能部24を有する。

0026

プロトコル中継機能部21は、処理系PS−1〜PS−Nと、プロトコルの組み合わせ毎に存在する。アプリやデバイスからのアクセスを処理系PS−1〜PS−Nに中継する。

0027

アクセス管理機能部22は、アクセス管理機能毎に存在する。アクセス管理機能部22は、プロトコル中継機能部21に対し、中継時に挿入するアクセス管理処理を提供する機能である。例えば、アクセス制御の場合、プロトコル中継機能部21はアクセスの中継可否をアクセス管理機能部22に問い合わせてから中継を行なう。

0028

キャッシュ部23は、アクセス管理ポリシーDB31の情報をメモリ上にキャッシュする機能である。

0029

アクセス元識別機能部24は、低レイヤプロトコル情報(IPアドレス、MACアドレス等)を用いて、アクセス元AS−1〜AS−Nの識別子(アプリID、デバイスID)を取得する機能である。

0030

アクセス管理ポリシーDB31は、アクセス制御のルールなどのアクセス管理ポリシーを格納するデータベースである。アクセス管理ポリシーは、システム運用者コンピュータ41から設定される。

0031

図2は、アクセス管理ポリシーDB31に格納されるアクセス管理ポリシーの一例を示す図である。

0032

同図に示すように、「アクセス制御のポリシー」としては、アクセス元、アクセス先及び可能な操作の種類が関連付けて記憶されている。例えば、アクセス元がアプリAP−1、アクセス先が処理系PS−1のデータXである場合、可能な操作は参照、更新の操作のみが許可される。また、アクセス元がアプリAP−1、アクセス先が処理系PS−1のデータYである場合、可能な操作は参照の操作のみが許可される。アクセス元がアプリAP−1、アクセス先が処理系PS−2のデータZである場合、可能な操作は参照、更新、削除の操作が許可される。

0033

同時アクセス数制限のポリシー」としては、アクセス先、アクセス元及び同時アクセス数上限が関連付けて記憶されている。例えば、アクセス先が処理系PS−1、アクセス元がアプリAP−1、アプリAP−2である場合、同時アクセス上限は5リクエスト/秒である。アクセス先が処理系PS−1、アクセス元がデバイスDB−3である場合、同時アクセス上限は10リクエスト/秒である。アクセス先が処理系PS−1、アクセス元がアプリAP−4、AP−5である場合、同時アクセス上限は15リクエスト/秒である。

0034

「優先制御のポリシー」としては、アクセス元及び優先度が関連付けて記憶されている。例えば、アクセス元がアプリAP−1の場合、優先度は「高」であり、アクセス元がアプリAP−2の場合、優先度は「中」である。

0035

次に、実施形態に係るIoT基盤Sのアクセス管理の第1動作について、図3のタイミングチャートを参照して説明する。なお、アクセス管理の動作の説明に際し、以下の環境を想定する。

0036

・アプリAPやデバイスDBとアクセス管理ゲートウェイ11がそれぞれDockerコンテナであり、同一のDocker定義ネットワーク上に配置されている。

0037

・ 各アプリやデバイスを一意に表わすIDが、各アプリやデバイスのコンテナ名として設定されている。

0038

・ この時、アクセス管理ゲートウェイ11は、アプリAPやデバイスDBからのアクセスを受信時、それらアクセス元のIPアドレスをDNS逆引きすることでコンテナ名(=アクセス元ID)を取得することが可能である。

0039

このような想定のもと、あるアプリAPがRESTAPIサーバに対してアクセスする際の、アクセス制御のシーケンスを説明する。なお、図3においては、アプリAPからAPIリクエストをする場合について示しているが、デバイスDBの場合であっても、同様のシーケンスとなる。

0040

まず、システム管理者のコンピュータ41からアクセス管理ポリシーDB31に、図2に示したアクセス管理ポリシーが投入される(T1)。なお、アクセス管理ポリシーには、図2に示したアクセス制御ポリシー、同時アクセス数制限のポリシー、優先制御のポリシーなどが含まれる。アクセス管理ポリシーは、アクセス管理ポリシーDB31に記憶される。

0041

アクセス管理ポリシーDB31に記憶されたアクセス管理ポリシーは、キャッシュ部23に読み込まれ(T2)、読み込まれたアクセス管理ポリシーはキャッシュ部23のメモリに記憶される(T3)。

0042

次に、アプリAPから処理系PSへのAPIリクエストがプロトコル中継機能部21に送信される(T11)。このAPIリクエストは、例えば、HTTPのPOSTメソッドによるデータ送信である。

0043

プロトコル中継機能部21は、APIリクエストを受け付けると、アプリAPのアクセス権の問い合わせをアクセス管理機能部22に問い合わせる(T12)。このアクセス権の問い合わせの際には、アクセス元のIPアドレスと、アクセス先のURLとを伝える。

0044

アクセス管理機能部22は、プロトコル中継機能部21からアクセス権の問い合わせを受信すると、アクセス元ID取得要求をアクセス元識別機能部24に出力する(T13)。

0045

アクセス元識別機能部24は、アクセス元のIPアドレスを使用して、DNSサーバ51にホスト名の問い合わせを行ない(T14)、ホスト名をDNSサーバ51から取得し(T15)、ホスト名からアクセス元IDを取得する(T16)。

0046

このようなDNSサーバ51によるアクセス元の特定は、IPアドレスとアクセス元IDとが1対1の関係であるような環境でのみ実施可能である。実施形態では、アプリAPとアクセス管理ゲートウェイ11とが同一のDocker定義ネットワークに属するコンテナである、という前提であるため、このようなアクセス元の特定が可能となる。

0047

次に、アクセス元識別機能部24は、取得したアクセス元IDをアクセス管理機能部22に送信する(T17)。アクセス管理機能部22は、アクセス元識別機能部24から取得したアクセス元IDに基づいて、当該アクセス元IDのアクセス管理ポリシーの取得要求をキャッシュ部23に送信する(T18)。

0048

キャッシュ部23は、アクセス管理ポリシーDB31から読み込まれたアクセス管理ポリシーのうち、当該アクセス元IDのアクセス管理ポリシーをアクセス管理機能部22に送信する(T19)。

0049

アクセス管理機能部22は、受信した当該アクセス元IDのアクセス管理ポリシーに基づいて、アクセス権限チェックを行なう(T20)。そして、アクセス権限の有無をプロトコル中継機能部21に送信する(T21)。

0050

アクセス権限がある場合、プロトコル中継機能部21はAPIリクエストを送信先の処理系PSに転送し(T31)、APIリクエストに対するAPIレスポンスを受信する(T32)。そして、プロトコル中継機能部21は受信したAPIレスポンスをアクセス元のアプリAPに転送する(T33)。アクセス権限がない場合、プロトコル中継機能部21はアクセス不可であることをアクセス元のアプリAPに転送する(T41)。

0051

次に、実施形態に係るIoT基盤Sのアクセス管理の第2動作について、図4のタイミングチャートを参照して説明する。第2動作は、第1動作と異なり、低レイヤプロトコル情報を用いてアクセス元IDを取得しない場合のアクセス管理の動作を示すものである。

0052

まず、システム管理者のコンピュータ41からアクセス管理ポリシーDB31に、図2に示したアクセス管理ポリシーが投入される(T1)。なお、アクセス管理ポリシーには、図2に示したアクセス制御ポリシー、同時アクセス数制限のポリシー、優先制御のポリシーなどが含まれる。アクセス管理ポリシーは、アクセス管理ポリシーDB31に記憶される。

0053

アクセス管理ポリシーDB31に記憶されたアクセス管理ポリシーは、キャッシュ部23に読み込まれ(T2)、読み込まれたアクセス管理ポリシーはキャッシュ部23のメモリに記憶される(T3)。

0054

次に、アプリAPから処理系PSへのAPIリクエストがプロトコル中継機能部21に送信される(T51)。このAPIリクエストは、例えば、HTTPのPOSTメソッドによるデータ送信である。

0055

プロトコル中継機能部21は、APIリクエストを受け付けると、アプリAPのアクセス権の問い合わせをアクセス管理機能部22に問い合わせる(T52)。このアクセス権の問い合わせの際には、アクセス元のIPアドレスと、アクセス先のURLとを伝える。

0056

アクセス管理機能部22は、プロトコル中継機能部21からアクセス権の問い合わせを受信すると、アクセス元IDの抽出を行なう(S53)。この抽出は、例えば、HTTPのヘッダにアクセス元IDを記載しておき、アクセス管理機能部22がそれを取得する。このように、低レイヤプロトコル情報を用いてアクセス元IDを取得しない場合、プロトコル毎に、アクセス元IDを通信内容のどこに記載するかを設計する必要がある。

0057

アクセス管理機能部22は、抽出したアクセス元IDに基づいて、当該アクセス元IDのアクセス管理ポリシーの取得要求をキャッシュ部23に送信する(T54)。

0058

キャッシュ部23は、アクセス管理ポリシーDB31から読み込まれたアクセス管理ポリシーのうち、当該アクセス元IDのアクセス管理ポリシーをアクセス管理機能部22に送信する(T55)。

0059

アクセス管理機能部22は、受信した当該アクセス元IDのアクセス管理ポリシーに基づいて、アクセス権限のチェックを行なう(T56)。そして、アクセス権限の有無をプロトコル中継機能部21に送信する(T57)。

0060

アクセス権限がある場合、プロトコル中継機能部21はAPIリクエストを送信先の処理系PSに転送し(T31)、APIリクエストに対するAPIレスポンスを受信する(T32)。そして、プロトコル中継機能部21は受信したAPIレスポンスをアクセス元のアプリAPに転送する(T33)。アクセス権限がない場合、プロトコル中継機能部21はアクセス不可であることをアクセス元のアプリAPに転送する(T41)。

0061

従って、実施形態に係るIoT基盤Sのアクセス管理装置によれば、図6に示すように各種機能へのアクセスを一元的に中継するゲートウェイ11を配し、アクセス管理を行なうので、図7に示すように従来の機能毎に個別にアクセス管理を行なう場合と比較して、省リソース、低運用コストでアクセス管理を実現することができる。

0062

図8は、従来の個別対応のアクセス管理と、本発明の一元管理のアクセス管理との効果を説明するための図である。

0063

同図に示すように、実施形態によれば、個別対応のアクセス管理に比して、アクセス管理の運用コストを低減することができる。ポリシーを個別のアクセス管理機構に投入する必要がなく、一元的に追加、更新、削除等をすることができるからである。従って、ポリシーの不整合リスクは、実施形態のアクセス管理では存在しない。

0064

また、メモリなどの消費リソースを低減することができる。複数の処理系PSやプロトコルに対し、アクセス管理に用いるリソースを共通化するためである。

0065

さらに、アプリAPやデバイスDBの開発負担を軽減することができる。統一的な方式でアクセス管理が行なわれるため、アプリAPやデバイスDBの開発者の学習コストが低減されるからである。

0066

さらに、処理系PSやプロトコルの追加が容易になる。個別のアクセス管理機構を用意する必要がなく、アクセス管理機能部22は共通化されているため、プロトコル中継機能部21だけ用意すれば良いからである。

0067

さらに、アクセス元ID(識別情報)を上位プロトコル情報に依存せずに取得するため、プロトコル毎に「アクセス元IDを通信内容のどこに記載するか」を設計する必要がない。

0068

さらに、アクセス管理ポリシーをオンメモリでキャッシュするため、高速なアクセス管理処理を実現することができる。

0069

従って、実施形態によれば、アクセス管理機構を処理系やプロトコルから独立したゲートウェイとして構成し、設定されたアクセス管理ポリシーに基づいて一元的なアクセス管理を実現することができるアクセス管理装置及びアクセス管理方法を提供できる。

0070

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

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

関連する公募課題

ページトップへ

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

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

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

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

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

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

  • 日本電気株式会社の「 制御装置、車両内通信システム、監視方法及びプログラム」が 公開されました。( 2021/03/18)

    【課題・解決手段】検査用フレーム等の送信を行うことなく、車両の各部や通信経路の異常を検出する。制御装置は、制御エントリを参照して、車両に搭載されたECUに入出力されるパケットを中継する複数のスイッチに... 詳細

  • シャープ株式会社の「 電気機器および機器制御システム」が 公開されました。( 2021/03/18)

    【課題】実際のユーザ状況に適した動作を実行可能な電気機器および機器制御システムを提供する。【解決手段】電気機器は、複数の動作態様を実行可能な動作部と、前記複数の動作態様のうち、前記電気機器で取得された... 詳細

  • シャープ株式会社の「 冷蔵庫システム」が 公開されました。( 2021/03/18)

    【課題】ユーザの行動に応じて、ユーザに所定の情報を送信することができる冷蔵庫システムを提供するする。【解決手段】冷蔵庫システムは、冷蔵庫と、ユーザ端末の使用状況から判定されたユーザの行動に応じて、前記... 詳細

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

関連性が強い人物一覧

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

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

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

関連する公募課題一覧

astavision 新着記事

サイト情報について

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

主たる情報の出典

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