特開 2024-134959 データ管理プログラム、データ管理方法及びデータ管理装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024134959

(43)【公開日】2024-10-04

(54)【発明の名称】データ管理プログラム、データ管理方法及びデータ管理装置

(51)【国際特許分類】

   G06F 21/64 20130101AFI20240927BHJP

   G06F 16/16 20190101ALI20240927BHJP

【ＦＩ】

G06F21/64

G06F16/16

【審査請求】未請求

【請求項の数】7

【出願形態】ＯＬ

(21)【出願番号】P 2023045428

(22)【出願日】2023-03-22

【国等の委託研究の成果に係る記載事項】（出願人による申告）令和元年度、国立研究開発法人海上・港湾・航空技術研究所、戦略的イノベ－ション創造プログラム「スマート物流サービス」「物流・商流データ基盤に関する技術（要素基礎技術）」委託研究、産業技術力強化法第１７条の適用を受ける特許出願

(71)【出願人】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】山崎 滉一

(72)【発明者】

【氏名】小林 郁弥

(57)【要約】

【課題】ログ取得用のクエリの応答時間の短縮を実現することを課題とする。
【解決手段】データ管理プログラムは、データ基盤のプラットフォーム上のデータに対するアクセスログを、アクセスログが持つ特徴を数値化した特徴量を用いて特徴ベクトルへ変換し、アクセスログを識別する識別情報と、特徴ベクトルとを紐づけてブロックチェーンネットワーク内のデータストアへ保存する、処理をコンピュータに実行させる。
【選択図】図９

【特許請求の範囲】

【請求項1】

データ基盤のプラットフォーム上のデータに対するアクセスログを、前記アクセスログが持つ特徴を数値化した特徴量を用いて特徴ベクトルへ変換し、
前記アクセスログを識別する識別情報と、前記特徴ベクトルとを紐づけてブロックチェーンネットワーク内のデータストアへ保存する、
処理をコンピュータに実行させることを特徴とするデータ管理プログラム。

【請求項2】

前記特徴ベクトルは、前記アクセスログよりもデータサイズが小さく、
前記変換する処理は、特定の時間帯ごとに前記時間帯で生成された複数のアクセスログを複数の特徴ベクトルへ変換する処理を含み、
前記保存する処理は、前記時間帯を識別する識別情報と、前記複数の特徴ベクトルとを紐づけて保存する処理を含む、
ことを特徴とする請求項１に記載のデータ管理プログラム。

【請求項3】

前記変換する処理は、前記時間帯で生成された複数のアクセスログの中に記述内容が同一である複数のアクセスログが存在する場合、前記複数のアクセスログのうち１つのアクセスログを特徴ベクトルに変換する処理を含み、
前記保存する処理は、前記時間帯を識別する識別情報に紐づけて、前記１つのアクセスログから変換された特徴ベクトルおよび記述内容が同一であるアクセスログの個数の組合せを保存する処理を含む、
ことを特徴とする請求項２に記載のデータ管理プログラム。

【請求項4】

前記識別情報は、前記時間帯に対応するタイムスタンプであることを特徴とする請求項２に記載のデータ管理プログラム。

【請求項5】

前記変換する処理は、前記ブロックチェーンネットワークのＰｅｅｒノードで実行されるチェーンコードが実行するログ解析用の機械学習モデルが入力とする特徴ベクトルの形式と同一の形式で前記アクセスログを前記特徴ベクトルへ変換する処理を含む、
ことを特徴とする請求項１に記載のデータ管理プログラム。

【請求項6】

データ基盤のプラットフォーム上のデータに対するアクセスログを、前記アクセスログが持つ特徴を数値化した特徴量を用いて特徴ベクトルへ変換し、
前記アクセスログを識別する識別情報と、前記特徴ベクトルとを紐づけてブロックチェーンネットワーク内のデータストアへ保存する、
処理をコンピュータが実行することを特徴とするデータ管理方法。

【請求項7】

データ基盤のプラットフォーム上のデータに対するアクセスログを、前記アクセスログが持つ特徴を数値化した特徴量を用いて特徴ベクトルへ変換し、
前記アクセスログを識別する識別情報と、前記特徴ベクトルとを紐づけてブロックチェーンネットワーク内のデータストアへ保存する、
処理を実行する制御部を有するデータ管理装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データ管理プログラム、データ管理方法及びデータ管理装置に関する。

【背景技術】

【0002】

データ基盤には、従来のプラットフォーム以上の安心および安全が求められる。このため、防御中心の対策に留まらず、防御を突破された場合でもデータの真正性（非改ざん性）を担保できる対策をとることが求められている。このような対策の１つとして、不正アクセスを検知するログ解析技術をデータ基盤に取り入れることが挙げられる。

【0003】

しかし現状、防御が突破された場合、ログ解析用のアクセスログやログ解析で異常が検知された異常ログ自体が改ざんされる場合があるので、正常な不正アクセスの検知が困難な側面がある。

【0004】

このような側面から、アクセスログの非改ざん性を担保するために、ブロックチェーン技術を利用して、データ基盤におけるアクセスログをブロックチェーンに記録することが提案されている。

【0005】

このとき、アクセスログの取得にかかる所要時間は短い方が実用的である。このため、ログ解析時には、全てのトランザクションが記録されるブロックチェーンおよび最新のブロックのトランザクションが記録されるデータストアのうち、クエリの応答時間が短いデータストアからアクセスログが取得される。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２０２１－３５０４１号公報

【特許文献2】特開２０２０－１３１７５号公報

【特許文献3】特開２０２０－９８９７２号公報

【発明の概要】

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

【0007】

しかしながら、上記のデータストアからアクセスログを取得する場合であっても、依然として、ログ取得用のクエリの応答時間が短縮するのが困難である側面がある。

【0008】

１つの側面では、本発明は、ログ取得用のクエリの応答時間の短縮を実現できるデータ管理プログラム、データ管理方法及びデータ管理装置を提供することを目的とする。

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

【0009】

１つの側面にかかるデータ管理プログラムは、データ基盤のプラットフォーム上のデータに対するアクセスログを、前記アクセスログが持つ特徴を数値化した特徴量を用いて特徴ベクトルへ変換し、前記アクセスログを識別する識別情報と、前記特徴ベクトルとを紐づけてブロックチェーンネットワーク内のデータストアへ保存する、処理をコンピュータに実行させる。

【発明の効果】

【0010】

一実施形態によれば、ログ取得用のクエリの応答時間の短縮を実現できる。

【図面の簡単な説明】

【0011】

【図1】図１は、従来技術におけるログ取得を示す模式図である。

【図2】図２は、ログ保存量とクエリ性能の関係を示す図である。

【図3】図３は、コンフリクトの一例を示す模式図である。

【図4】図４は、従来技術に係るStateDBの一例を示す図である。

【図5】図５は、本実施例に係るStateDBの一例を示す図である。

【図6】図６は、サーバ装置の機能構成例を示すブロック図である。

【図7】図７は、アクセスログの保存の流れを示す模式図である。

【図8】図８は、ログ書込関数の動作を示す模式図である。

【図9】図９は、特徴ベクトルの変換の一例を示す模式図である。

【図10】図１０は、リアルタイム性とＩ／Ｏ頻度の関係を示す図である。

【図11】図１１は、不正アクセス検知および確認依頼の流れを示す模式図である。

【図12】図１２は、変更履歴照会および通報の流れを示す模式図である。

【図13】図１３は、不正操作無効化およびアカウント初期化の流れを示す模式図である。

【図14】図１４は、保存処理の手順を示すフローチャートである。

【図15】図１５は、生成処理の手順を示すフローチャートである。

【図16】図１６は、変換処理の手順を示すフローチャートである。

【図17】図１７は、ハードウェア構成例を示す図である。

【発明を実施するための形態】

【0012】

以下、添付図面を参照して本願に係るデータ管理プログラム、データ管理方法及びデータ管理装置の実施例について説明する。各実施例には、あくまで１つの例や側面を示すに過ぎず、このような例示により数値や機能の範囲、利用シーンなどは限定されない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

【実施例0013】

まず、従来技術に係るデータ基盤やブロックチェーンについて説明する。図１は、従来技術におけるログ取得を示す模式図である。図１に示すように、データ基盤上で公開された公開データへのアクセスを受け付けると（ステップＳ１）、データ基盤上のデータに対するアクセス制御を行うデータ基盤ＡＰＩ（Application Programming Interface）は、アクセスログを生成する（ステップＳ２）。そして、データ基盤ＡＰＩは、ステップＳ２で生成されたアクセスログをＢＣ（Block Chain）およびStateDBへ記録する（ステップＳ３）。

【0014】

このようなアクセスログの管理の下、ログ解析時には、チェーンコードの解析関数は、ログ取得用のクエリをStateDBに発行することにより、StateDBに保存されたアクセスログを取得する（ステップＳ４）。

【0015】

このように、ログ解析時にＢＣおよびStateDBのうちStateDBからアクセスログが取得されるのは、アクセスログの取得にかかる所要時間は短い方が実用的であるからである。このため、クエリの応答時間が短いStateDBからアクセスログが取得される。

【0016】

しかしながら、StateDBからアクセスログを取得する場合であっても、依然として、ログ取得用のクエリの応答時間が短縮するのが困難である側面がある。

【0017】

なぜなら、ログ解析で一定の精度を得るには、ある程度以上の量のアクセスログが求められる側面から、StateDBのデータサイズ、すなわちアクセスログの保存量を削減するには限界があるからである。

【0018】

StateDBのクエリ性能は、データサイズおよびキーの数に依存する。図２は、ログ保存量とクエリ性能の関係を示す図である。図２には、比較例として、ＢＣの最新値のみをStateDBに保存するパターン１と、StateDBに大量のアクセスログを保存するパターン２とが挙げられている。図２に示すように、パターン１の場合、StateDBに保存されるアクセスログの量が少ないので、高精度のログ解析が困難である一方で、クエリ性能は高まる。また、パターン２の場合、StateDBに大量のアクセスログが保存されるので、高精度のログ解析が実施できる一方で、クエリ性能は低下する。

【0019】

このような側面から、クエリ性能の低下を抑制しつつ、StateDBに保存するデータサイズを増加させるために、１つのキーに複数のアクセスログを関連付けてStateDBに保存する先進技術が考えられる。なお、ここで挙げる先進技術は、公知である特許文献や非特許文献等に記載がある上記の従来技術とは区別される。

【0020】

しかしながら、上記の先進技術では、StateDBの更新時にコンフリクトが発生する場合がある。すなわち、StateDBの各キーは、データベースの各キーに対応するが、ブロックチェーンでは、StateDBを更新するデータがブロック内で時系列順に整理されている。このため、ブロック内に同一のキーに関する更新処理や参照処理などのコマンドが２つ以上含まれる場合、コンフリクトが発生する結果、データの不一致が起こる場合がある。

【0021】

図３は、コンフリクトの一例を示す図である。図３には、あくまで一例として、同一のユニークキーであるキー２に対する処理１のwrite setおよび処理２のwrite setのコンフリクトが発生する例が示されている。図３に示すように、処理１のwrite setおよび処理２のwrite setのコンフリクトが発生すると、先に処理１のwrite setがStateDBに反映されてしまうので、後でStateDBに反映される処理２のwrite setの内容がブロックと一致しないものになってしまう。

【0022】

そこで、本実施例に係るデータ管理機能は、時間帯ごとに当該時間帯で生成されたアクセスログの集合をバッチ化し、バッチ化されたアクセスログの集合を１つのキーに関連付けて記録できる。このようなアクセスログの特徴ベクトルの記録と同時、あるいは並行して、本実施例に係るデータ管理機能は、アクセスログを特徴ベクトルへ変換してオリジナルのアクセスログの代わりに特徴ベクトルをStateDBに記録する。

【0023】

図４は、従来技術に係るStateDBの一例を示す図である。図５は、本実施例に係るStateDBの一例を示す図である。上記の従来技術では、図４に示すように、オリジナルのアクセスログがStateDBに記録される。その一方で、本実施例に係るデータ管理機能によれば、図５に示すように、オリジナルのアクセスログから特徴が抽出された特徴ベクトルがStateDBに記録される。これにより、アクセスログの記述が数値表現へ変換されるので、１つのアクセスログあたりのデータサイズが削減される結果、StateDBのデータサイズを削減できる。したがって、本実施例に係るデータ管理機能によれば、ログ取得用のクエリの応答時間の短縮を実現できる。加えて、ログ解析時にチェーンコードの解析関数が実行する機械学習モデルにアクセスログを入力する際に実行される特徴ベクトルの変換をログ保存時に前処理できるので、ログ解析時の処理負荷を軽減することも可能になる。

【0024】

また、上記の従来技術では、図４に示すように、１つのユニークキーにつき１つのアクセスログがStateDBに記録される。一方、本実施例に係るデータ管理機能によれば、図５に示すように、１時間単位でバッチ化されたアクセスログの集合がStateDBに記録される。このように時間帯ごとにキーを分離することで、コンフリクトの発生というデメリットを回避する一方で、StateDBのキーの数の増加を抑えつつ、StateDBに保存するアクセスログの量を増加させるメリットのみを得ることができる。加えて、StateDBのキーの数の増加が抑えられるので、StateDBからのＩ／Ｏの頻度を削減できる結果、ログ解析の処理速度を高速化できる。

【0025】

次に、本実施例に係るデータ管理機能を提供するサーバ装置１の機能構成例について説明する。図６は、サーバ装置１の機能構成例を示すブロック図である。図６に示すサーバ装置１は、データ基盤を提供するプラットフォームとして機能するとともに、上記のデータ管理機能を提供する。このようなデータ基盤の利用シーンの１つとして、サプライチェーンにおける川上（メーカー）から川下（小売）までの商流および物流の情報を産業界全体で共有する例が挙げられる。

【0026】

図６に示すように、サーバ装置１は、ネットワークＮＷを介して、クライアント端末３および管理者端末５と通信可能に接続され得る。例えば、ネットワークＮＷは、有線または無線を問わず、インターネットやＬＡＮ（Local Area Network）などの任意の種類の通信網であってよい。

【0027】

クライアント端末３および管理者端末５は、端末装置の一例である。例えば、クライアント端末３は、上記のデータ基盤の提供を受けるユーザにより使用され得る。また、管理者端末５は、上記のデータ基盤の管理者などにより使用され得る。これらクライアント端末３および管理者端末５は、パーソナルコンピュータを始め、携帯端末装置やウェアラブル端末などの任意のコンピュータにより実現されてよい。

【0028】

なお、図６には、１つのサーバ装置１につき１つのクライアント端末３および１つの管理者端末５が接続される例を挙げたが、任意の台数のクライアント端末３および任意の台数の管理者端末５が接続されることを妨げない。

【0029】

図６には、サーバ装置１が有するデータ管理機能に関連するブロックが模式化されている。図６に示すように、サーバ装置１は、通信制御部６と、記憶部７と、制御部１０とを有する。なお、図６には、上記のデータ管理機能に関連する機能部が抜粋して示されているに過ぎず、図示以外の機能部がサーバ装置１に備わることとしてもよい。

【0030】

通信制御部６は、クライアント端末３や管理者端末５などの他の装置との間の通信を制御する機能部である。あくまで一例として、通信制御部６は、ネットワークインタフェイスカードにより実現され得る。

【0031】

記憶部７は、各種のデータを記憶する機能部である。あくまで一例として、記憶部７は、サーバ装置１の内部、外部または補助のストレージにより実現される。例えば、記憶部７は、データ基盤上で公開される公開データ８と、StateDBに対応するデータストア９とを記憶する。なお、公開データ８およびデータストア９などの説明は、参照、生成または登録が実行される場面で併せて説明することとする。

【0032】

制御部１０は、サーバ装置１の全体制御を行う機能部である。例えば、制御部１０は、ハードウェアプロセッサにより実現され得る。図６に示すように、制御部１０は、ＭＷ（MiddleWare）実行部１１を有する。なお、制御部１０は、ハードワイヤードロジックなどにより実現されてもよい。

【0033】

ＭＷ実行部１１は、上記のデータ基盤の機能を実現するミドルウェアを実行する処理部である。図６に示すように、ＭＷ実行部１１は、アクセス制御部１３と、ＰＦ（PlatForm）実行部２０と、監視部１５とを有する。

【0034】

アクセス制御部１３は、データ基盤上のデータに対するアクセス制御を行う処理部である。このようなアクセス制御は、一例として、データ基盤ＡＰＩにより実現され得る。

【0035】

ＰＦ実行部２０は、ＢＣネットワークのプラットフォームを実現するソフトウェアを実行する処理部である。このようなソフトウェアが実行されることにより、ＢＣネットワークのプラットフォームが構築される。ＰＦ実行部２０は、図６に示すように、トランザクションとそのデータへのアクセスを管理するスマートコントラクトのロジックが定義されたチェーンコードを実行するチェーンコード実行部３０をさらに有する。

【0036】

監視部１５は、データ基盤上のデータに対する不正アクセスを監視する処理部である。このような不正アクセスの監視は、一例として、監視プログラムを実行することにより実現され得る。

【0037】

図７を用いて、アクセス制御部１３およびＰＦ実行部２０により実現されるアクセスログの保存機能を説明する。図７は、アクセスログの保存の流れを示す模式図である。図７には、データ基盤に構築されたＢＣネットワークに含まれるＰｅｅｒノードと、データ基盤ＡＰＩとが模式化されている。

【0038】

図７に示すように、データ基盤ＡＰＩは、特定の時間帯の間に生成されたＫ個のアクセスログをバッチ化する（ステップＳ１０）。例えば、同図の例で言えば、２０２２年１２月１１日の午前１０時００分００秒から午前１０時５９分５９秒までの１時間の間で生成されたアクセスログが一括でまとめられる。

【0039】

続いて、データ基盤ＡＰＩは、ステップＳ１０でバッチ化されたＫ個のアクセスログを引数とし、チェーンコードのログ書込関数の実行命令をＰｅｅｒ（Endorser）ノードへ送信する（ステップＳ１１）。そして、Ｐｅｅｒ（Endorser）ノードは、チェーンコードのログ書込関数を実行する（ステップＳ１２）。

【0040】

ここで、ログ書込関数は、Ｋ個のアクセスログの各々を特徴ベクトルへ変換してwrite setを生成する（ステップＳ１３）。例えば、ログ書込関数は、ステップＳ１０でバッチ化が実施された時間帯のタイムスタンプから当該時間帯を識別する識別情報を生成し、生成された識別情報と、Ｋ個の特徴ベクトルとを対応付けることにより、write setを生成する。

【0041】

その後、チェーンコードは、ステップＳ１３で生成されたwrite setを処理結果としてＰｅｅｒ（Endorser）ノードへ返却する（ステップＳ１４）。この処理結果を受け付けたＰｅｅｒ（Endorser）ノードは、ステップＳ１３で生成されたwrite setに署名を実行してデータ基盤ＡＰＩへ返却する（ステップＳ１５）。

【0042】

続いて、データ基盤ＡＰＩは、ステップＳ１５でＰｅｅｒ（Endorser）ノードから返却された承認結果、すなわちEndorsementをOrdererノードへ送信する（ステップＳ１６）。すると、Ordererノードは、Endorsementを順序付けしてブロックを生成する（ステップＳ１７）。そして、Ordererノードは、ステップＳ１７で生成されたブロックをＰｅｅｒ（Committer）ノードへ送信する（ステップＳ１８）。

【0043】

その後、Ｐｅｅｒ（Committer）ノードは、ステップＳ１８で送信されたブロックをＢＣに追加する（ステップＳ１９Ａ）。さらに、Ｐｅｅｒ（Committer）ノードは、ステップＳ１８で送信されたwrite setをStateDBに追加する（ステップＳ１９Ｂ）。

【0044】

次に、図７に示すステップＳ１３におけるログ書込関数の動作について説明する。図８は、ログ書込関数の動作を示す模式図である。図８に示すように、特定の時間帯でバッチ化されたＫ個のアクセスログを受け付けると、ログ書込関数は、バッチ化が実施された時間帯のタイムスタンプに対応するキーを採番する（ステップＳ１３２）。

【0045】

このとき、複数のアクセスログの間で記述内容が同一である場合、ログ書込関数は、同一の記述内容である複数のアクセスログを１つに集約する（ステップＳ１３４）。続いて、ログ書込関数は、Ｋ個のアクセスログの各々を特徴ベクトルへ変換する（ステップＳ１３５）。

【0046】

ここで、同一の記述内容である複数のアクセスログについては、複数のアクセスログのうち１つのアクセスログから変換された特徴ベクトルと、同一のアクセスログの個数との組合せにより数値表現される。例えば、図８に示す例で言えば、特徴ベクトル［５，４，７，・・・，５，７］と、同一のアクセスログの個数「３」とを乗算記号「＊」で接続する。

【0047】

その後、ログ書込関数は、ステップＳ１３２で採番されたキーと、ステップＳ１３５で変換された特徴ベクトルの集合とを関連付けることにより、write setを生成する（ステップＳ１３６）。

【0048】

さらに、図８に示すステップＳ１３５における特徴ベクトルの変換をより詳細に説明する。図９は、特徴ベクトルの変換の一例を示す模式図である。図９には、アクセスログから２３個の特徴量を含む特徴ベクトルへ変換される例が示されている。図９に示すように、ログ書込関数は、アクセスログに含まれる「．」の個数「１０」を特徴ベクトルの１つ目の特徴量として抽出する。さらに、ログ書込関数は、アクセスログで「％」が最初に出現する場所「０」を特徴ベクトルの２つ目の特徴量として抽出する。さらに、ログ書込関数は、アクセスログに含まれる「／」の個数「８」を特徴ベクトルの３つ目の特徴量として抽出する。同様にして２３個の特徴量が抽出されることにより、特徴ベクトルが得られる。なお、図９に示す特徴抽出は、あくまで一例に過ぎず、機械学習で実行される任意の特徴抽出が実行されてよい。

【0049】

次に、アクセスログをバッチ化する時間帯のサイズを切り替える場合におけるリアルタイム性およびＩ／Ｏ頻度を説明する。図１０は、リアルタイム性とＩ／Ｏ頻度の関係を示す図である。図１０に示すように、アクセスログをバッチ化する時間帯のサイズが短く設定するにつれてリアルタイム性が高まる一方で、キーの分離性能が低下するので、Ｉ／Ｏ頻度は高くなり、クエリ性能は低下する。一方、アクセスログをバッチ化する時間帯のサイズが長く設定するにつれてリアルタイム性が低下する一方で、キーの分離性能が向上するので、Ｉ／Ｏ頻度は低くなり、クエリ性能は向上する。

【0050】

次に、図１１を用いて、監視部１５により実現される不正アクセス検知機能および確認依頼機能を説明する。図１１は、不正アクセス検知および確認依頼の流れを示す模式図である。図１１に示すように、アカウントＡのユーザを装う第三者がクライアント端末３を介して公開データ８にアクセスすると（ステップＳ２１）、データ基盤ＡＰＩは、アクセスログを生成する（ステップＳ２２）。

【0051】

このように生成されたアクセスログは、図７に示す動作が実行されることにより、他のアクセスログとともにバッチ化された上でＢＣおよびStateDBに追加される（ステップＳ２３）。

【0052】

これらステップＳ２１からステップＳ２３までの動作と独立して、監視プログラムは、一定時間ごとにログ解析のリクエストをチェーンコードの解析関数に送信する（ステップＳ２４）。

【0053】

すると、チェーンコードの解析関数は、ログ取得用のクエリをStateDBに発行することにより、バッチ化されたアクセスログの集合に対応する特徴ベクトルの集合を読み出す（ステップＳ２５）。そして、機械学習モデルにより異常候補ログが検知された場合、チェーンコードの解析関数は、当該異常候補ログを監視プログラムへ応答する（ステップＳ２７）。

【0054】

その上で、チェーンコードの解析関数は、ステップＳ２５で読みだされた特徴ベクトルの集合をログ解析用の機械学習モデルへ入力することにより、ログ解析を実行する（ステップＳ２６）。

【0055】

あくまで一例として、上記のログ解析は、１つ以上の特徴ベクトルを入力として異常なアクセスログの候補である異常候補ログに対応する特徴ベクトルを出力する機械学習モデルにより実現されてよい。例えば、機械学習モデルは、ニューラルネットワークを始め、サポートベクタマシンや勾配ブースティング決定木などの任意の機械学習モデルにより実現されてよい。

【0056】

その後、監視プログラムは、ステップＳ２７で応答された異常候補ログからアクセス元のユーザ、例えばアカウントＡを識別する（ステップＳ２８）。その上で、監視プログラムは、当該異常候補ログに該当するアクセスを行った否かを確認する確認依頼を、ステップＳ２８で識別されたユーザ、すなわちアカウントＡの正規のユーザにより使用されるクライアント端末３に、送信する（ステップＳ２９）。

【0057】

次に、図１２を用いて、データ基盤ＡＰＩにより実現される変更履歴照会機能および通報機能を説明する。図１２は、変更履歴照会および通報の流れを示す模式図である。図１２に示すように、図１１に示すステップＳ２９の確認依頼を受けたユーザ、すなわちアカウントＡの正規のユーザは、クライアント端末３を介してデータ基盤へログインする（ステップＳ３１）。

【0058】

続いて、アカウントＡの正規のユーザは、クライアント端末３を介して異常候補ログに対応する変更履歴をチェーンコードの照会関数へ問い合わせる（ステップＳ３２）。これにより、アカウントＡの正規のユーザは、異常候補ログに対応する変更履歴から不正な操作履歴の有無を確認できる。

【0059】

このとき、不正な操作履歴がある場合、アカウントＡの正規のユーザは、クライアント端末３を介して不正な操作履歴をデータ基盤ＡＰＩの通報機能へ通報する（ステップＳ３３）。このような通報を受け付けた通報機能は、管理者端末５を介して不正な操作履歴をデータ基盤の管理者に通知したり、あるいは、クライアント端末３を介して不正な操作履歴を不正な操作が行われたデータを過去に閲覧したユーザ、例えばアカウントＢのユーザなどに通知したりすることができる。

【0060】

次に、図１３を用いて、データ基盤ＡＰＩにより実現される不正操作無効化機能およびアカウント初期化機能を説明する。図１３は、不正操作無効化およびアカウント初期化の流れを示す模式図である。

【0061】

図１３に示すように、図１２に示すステップＳ３３で通報を受けた管理者は、管理者端末５を介して不正な操作を当該不正な操作が行われる時点よりも前の状態のデータにロールバックする不正操作無効化の実行をチェーンコードの不正操作無効化関数へリクエストする（ステップＳ４１）。

【0062】

その後、管理者は、管理者端末５を介して不正アクセスが検知されたアカウントＡのアカウント情報を初期化する（ステップＳ４２）。

【0063】

次に、アクセスログの保存処理のフローチャートを説明する。図１４は、保存処理の手順を示すフローチャートである。図１４に示すように、データ基盤ＡＰＩは、特定の時間帯の間に生成されたＫ個のアクセスログをバッチ化する（ステップＳ１０）。

【0064】

続いて、データ基盤ＡＰＩは、ステップＳ１０でバッチ化されたＫ個のアクセスログを引数とし、チェーンコードのログ書込関数の実行命令をＰｅｅｒ（Endorser）ノードへ送信する（ステップＳ１１）。そして、Ｐｅｅｒ（Endorser）ノードは、チェーンコードのログ書込関数を実行する（ステップＳ１２）。

【0065】

ここで、ログ書込関数は、Ｋ個のアクセスログの各々を特徴ベクトルへ変換してwrite setを生成する（ステップＳ１３）。その後、チェーンコードは、ステップＳ１３で生成されたwrite setを処理結果としてＰｅｅｒ（Endorser）ノードへ返却する（ステップＳ１４）。この処理結果を受け付けたＰｅｅｒ（Endorser）ノードは、ステップＳ１３で生成されたwrite setに署名を実行してデータ基盤ＡＰＩへ返却する（ステップＳ１５）。

【0066】

続いて、データ基盤ＡＰＩは、ステップＳ１５でＰｅｅｒ（Endorser）ノードから返却された承認結果、すなわちEndorsementをOrdererノードへ送信する（ステップＳ１６）。すると、Ordererノードは、Endorsementを順序付けしてブロックを生成する（ステップＳ１７）。そして、Ordererノードは、ステップＳ１７で生成されたブロックをＰｅｅｒ（Committer）ノードへ送信する（ステップＳ１８）。

【0067】

その後、Ｐｅｅｒ（Committer）ノードは、ステップＳ１８で送信されたブロックをＢＣに追加する（ステップＳ１９Ａ）。さらに、Ｐｅｅｒ（Committer）ノードは、ステップＳ１８で送信されたwrite setをStateDBに追加し（ステップＳ１９Ｂ）、処理を終了する。

【0068】

次に、図１４に示すステップＳ１３で実行されるwrite setの生成処理について説明する。図１５は、生成処理の手順を示すフローチャートである。図１５に示すように、特定の時間帯でバッチ化されたＫ個のアクセスログを受け付けると（ステップＳ１３１）、ログ書込関数は、バッチ化が実施された時間帯のタイムスタンプに対応するキーを採番する（ステップＳ１３２）。

【0069】

このとき、記述内容が同一である複数のアクセスログが存在する場合（ステップＳ１３３Ｙｅｓ）、ログ書込関数は、同一の記述内容である複数のアクセスログを１つに集約する（ステップＳ１３４）。続いて、ログ書込関数は、Ｋ個のアクセスログの各々を特徴ベクトルへ変換する（ステップＳ１３５）。

【0070】

その後、ログ書込関数は、ステップＳ１３２で採番されたキーと、ステップＳ１３５で変換された特徴ベクトルの集合とを関連付けることにより、write setを生成し（ステップＳ１３６）、処理を終了する。

【0071】

最後に、図１５に示すステップＳ１３５で実行される特徴ベクトルの変換処理について説明する。図１６は、変換処理の手順を示すフローチャートである。図１６に示すように、ログ書込関数は、記述内容が異なるアクセスログの数Ｍおよび特徴ベクトルのパラメータ（特徴量）の個数Ｎに対応する回数の分、下記のステップＳ１３５１および下記のステップＳ１３５２の処理を反復するループ処理１およびループ処理２を実行する。

【0072】

すなわち、ログ書込関数は、ｍ個目のアクセスログから特徴ベクトルのｎ番目のパラメータをカウントする（ステップＳ１３５１）。そして、ログ書込関数は、ｍ個目のアクセスログに対応する特徴ベクトルのｎ番目の要素にステップＳ１３５１でカウントされたパラメータの個数を追加する（ステップＳ１３５２）。

【0073】

このようなループ処理１およびループ処理２が反復されることにより、Ｍ個のアクセスログごとにＮ個のパラメータを持つ特徴ベクトルを生成できる。

【0074】

上述してきたように、本実施例に係るデータ管理機能は、データ基盤上のデータに対するアクセスログをＢＣネットワークに記録する際、アクセスログを特徴ベクトルへ変換してオリジナルのアクセスログの代わりに特徴ベクトルをStateDBに記録する。これにより、アクセスログの記述が数値表現へ変換されるので、１つのアクセスログあたりのデータサイズが削減される結果、StateDBのデータサイズを削減できる。したがって、本実施例に係るデータ管理機能によれば、ログ取得用のクエリの応答時間の短縮を実現できる。

【実施例0075】

さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

【0076】

＜システム＞
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、アクセス制御部１３、ＰＦ実行部２０および監視部１５のうちいずれか１つ以上の機能部は、別々の装置で構成されていてもよい。

【0077】

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散および統合して構成することができる。なお、各構成は、物理的な構成であってもよい。

【0078】

さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵ（Central Processing Unit）および当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

【0079】

＜ハードウェア構成＞
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１７を用いて、実施例１及び実施例２と同様の機能を有するデータ管理プログラムを実行するコンピュータの一例について説明する。

【0080】

図１７は、ハードウェア構成例を示す図である。図１７に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０とを有する。これら１１０～１８０の各部はバス１４０を介して接続される。

【0081】

ＨＤＤ１７０には、図１７に示すように、上記の実施例１で示されたＭＷ実行部１１と同様の機能を発揮するデータ管理プログラム１７０ａが記憶される。このデータ管理プログラム１７０ａは、図６に示すＭＷ実行部１１の各構成要素と同様、統合又は分離してもよい。すなわち、ＨＤＤ１７０には、必ずしも上記の実施例１で示した全てのデータが格納されずともよく、処理に用いるデータがＨＤＤ１７０に格納されればよい。

【0082】

このような環境の下、ＣＰＵ１５０は、ＨＤＤ１７０からデータ管理プログラム１７０ａを読み出した上でＲＡＭ１８０へ展開する。この結果、データ管理プログラム１７０ａは、図１７に示すように、データ管理プロセス１８０ａとして機能する。このデータ管理プロセス１８０ａは、ＲＡＭ１８０が有する記憶領域のうちデータ管理プロセス１８０ａに割り当てられた領域にＨＤＤ１７０から読み出した各種データを展開し、展開された各種データを用いて各種の処理を実行する。例えば、データ管理プロセス１８０ａが実行する処理の一例として、図１４～図１６に示す処理などが含まれ得る。なお、ＣＰＵ１５０では、必ずしも上記の実施例１で示した全ての処理部が動作せずともよく、実行対象とする処理に対応する処理部が仮想的に実現されればよい。

【0083】

なお、上記のデータ管理プログラム１７０ａは、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶されておらずともかまわない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ－ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」にデータ管理プログラム１７０ａを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体からデータ管理プログラム１７０ａを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などにデータ管理プログラム１７０ａを記憶させておく。このように記憶されたデータ管理プログラム１７０ａをコンピュータ１００にダウンロードさせた上で実行させるようにしてもよい。

【0084】

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

【0085】

（付記１）データ基盤のプラットフォーム上のデータに対するアクセスログを、前記アクセスログが持つ特徴を数値化した特徴量を用いて特徴ベクトルへ変換し、
前記アクセスログを識別する識別情報と、前記特徴ベクトルとを紐づけてブロックチェーンネットワーク内のデータストアへ保存する、
処理をコンピュータに実行させることを特徴とするデータ管理プログラム。

【0086】

（付記２）前記特徴ベクトルは、前記アクセスログよりもデータサイズが小さく、
前記変換する処理は、特定の時間帯ごとに前記時間帯で生成された複数のアクセスログを複数の特徴ベクトルへ変換する処理を含み、
前記保存する処理は、前記時間帯を識別する識別情報と、前記複数の特徴ベクトルとを紐づけて保存する処理を含む、
ことを特徴とする付記１に記載のデータ管理プログラム。

【0087】

（付記３）前記変換する処理は、前記時間帯で生成された複数のアクセスログの中に記述内容が同一である複数のアクセスログが存在する場合、前記複数のアクセスログのうち１つのアクセスログを特徴ベクトルに変換する処理を含み、
前記保存する処理は、前記時間帯を識別する識別情報に紐づけて、前記１つのアクセスログから変換された特徴ベクトルおよび記述内容が同一であるアクセスログの個数の組合せを保存する処理を含む、
ことを特徴とする付記２に記載のデータ管理プログラム。

【0088】

（付記４）前記識別情報は、前記時間帯に対応するタイムスタンプであることを特徴とする付記２に記載のデータ管理プログラム。

【0089】

（付記５）前記変換する処理は、前記ブロックチェーンネットワークのＰｅｅｒノードで実行されるチェーンコードが実行するログ解析用の機械学習モデルが入力とする特徴ベクトルの形式と同一の形式で前記アクセスログを前記特徴ベクトルへ変換する処理を含む、
ことを特徴とする付記１に記載のデータ管理プログラム。

【0090】

（付記６）データ基盤のプラットフォーム上のデータに対するアクセスログを、前記アクセスログが持つ特徴を数値化した特徴量を用いて特徴ベクトルへ変換し、
前記アクセスログを識別する識別情報と、前記特徴ベクトルとを紐づけてブロックチェーンネットワーク内のデータストアへ保存する、
処理をコンピュータが実行することを特徴とするデータ管理方法。

【0091】

（付記７）前記特徴ベクトルは、前記アクセスログよりもデータサイズが小さく、
前記変換する処理は、特定の時間帯ごとに前記時間帯で生成された複数のアクセスログを複数の特徴ベクトルへ変換する処理を含み、
前記保存する処理は、前記時間帯を識別する識別情報と、前記複数の特徴ベクトルとを紐づけて保存する処理を含む、
ことを特徴とする付記６に記載のデータ管理方法。

【0092】

（付記８）前記変換する処理は、前記時間帯で生成された複数のアクセスログの中に記述内容が同一である複数のアクセスログが存在する場合、前記複数のアクセスログのうち１つのアクセスログを特徴ベクトルに変換する処理を含み、
前記保存する処理は、前記時間帯を識別する識別情報に紐づけて、前記１つのアクセスログから変換された特徴ベクトルおよび記述内容が同一であるアクセスログの個数の組合せを保存する処理を含む、
ことを特徴とする付記７に記載のデータ管理方法。

【0093】

（付記９）前記識別情報は、前記時間帯に対応するタイムスタンプであることを特徴とする付記７に記載のデータ管理方法。

【0094】

（付記１０）前記変換する処理は、前記ブロックチェーンネットワークのＰｅｅｒノードで実行されるチェーンコードが実行するログ解析用の機械学習モデルが入力とする特徴ベクトルの形式と同一の形式で前記アクセスログを前記特徴ベクトルへ変換する処理を含む、
ことを特徴とする付記６に記載のデータ管理方法。

【0095】

（付記１１）データ基盤のプラットフォーム上のデータに対するアクセスログを、前記アクセスログが持つ特徴を数値化した特徴量を用いて特徴ベクトルへ変換し、
前記アクセスログを識別する識別情報と、前記特徴ベクトルとを紐づけてブロックチェーンネットワーク内のデータストアへ保存する、
処理を実行する制御部を有するデータ管理装置。

【0096】

（付記１２）前記特徴ベクトルは、前記アクセスログよりもデータサイズが小さく、
前記変換する処理は、特定の時間帯ごとに前記時間帯で生成された複数のアクセスログを複数の特徴ベクトルへ変換する処理を含み、
前記保存する処理は、前記時間帯を識別する識別情報と、前記複数の特徴ベクトルとを紐づけて保存する処理を含む、
ことを特徴とする付記１１に記載のデータ管理装置。

【0097】

（付記１３）前記変換する処理は、前記時間帯で生成された複数のアクセスログの中に記述内容が同一である複数のアクセスログが存在する場合、前記複数のアクセスログのうち１つのアクセスログを特徴ベクトルに変換する処理を含み、
前記保存する処理は、前記時間帯を識別する識別情報に紐づけて、前記１つのアクセスログから変換された特徴ベクトルおよび記述内容が同一であるアクセスログの個数の組合せを保存する処理を含む、
ことを特徴とする付記１２に記載のデータ管理装置。

【0098】

（付記１４）前記識別情報は、前記時間帯に対応するタイムスタンプであることを特徴とする付記１２に記載のデータ管理装置。

【0099】

（付記１５）前記変換する処理は、前記ブロックチェーンネットワークのＰｅｅｒノードで実行されるチェーンコードが実行するログ解析用の機械学習モデルが入力とする特徴ベクトルの形式と同一の形式で前記アクセスログを前記特徴ベクトルへ変換する処理を含む、
ことを特徴とする付記１１に記載のデータ管理装置。