JP7327100B2 - データ管理システム、データ管理装置及びデータ管理プログラム - Google Patents

Description

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

特許文献１には、印刷データのページ画像のハッシュ値を算出し、算出されたハッシュ値と、記憶部に格納されている正常のハッシュ値を比較することで、ページ画像が正常であるか否かを判断する画像処理装置が開示されている。

特許文献２には、処理内容と依頼先のセキュリティ状態とに応じて、データファイルに含まれる１つ以上の付加情報を削除した上で、当該データファイルの処理を依頼する画像処理装置が開示されている。

特開２０１４－０３７０６８号公報 特開２０１４－１０２７９１号公報

しかしながら、記憶装置に記憶されているハッシュ値を読み出して比較値として用いる際、改ざんや破損などが起こって当該ハッシュ値の不変性が損なわれていた場合、両方のハッシュ値が一致しないことを理由に、管理対象のデータ自体の不変性が損なわれたものと誤って判定される可能性がある。

本発明の目的は、記憶装置に記憶されているハッシュ値を読み出して比較値として用いる際、当該ハッシュ値の不変性が損なわれていた場合に、管理対象のデータの不変性に関する誤判定を抑制することである。

請求項１に記載の発明は、プロセッサを有する管理装置と、複数の記憶装置と、を備え、前記プロセッサは、予め定められた演算規則に従って管理対象のデータに対応するハッシュ値を生成し、前記複数の記憶装置は、前記プロセッサが第１時点にて生成したハッシュ値である第１ハッシュ値をそれぞれ記憶し、前記プロセッサは、前記複数の記憶装置から読み出された前記複数の第１ハッシュ値と、前記第１時点よりも後の第２時点にて前記演算規則に従って再度生成したハッシュ値である第２ハッシュ値とからなる集合の間で相互に比較することで、前記複数の第１ハッシュ値又は前記データに関する不変性の判定を行うデータ管理システムである。

請求項２に記載の発明は、前記複数の記憶装置のうちの少なくとも１つは、他の記憶装置とは異なるネットワーク内に設けられる、請求項１に記載のデータ管理システムである。
請求項３に記載の発明は、前記複数の記憶装置のうちの少なくとも１つは、前記データが記憶されている装置とは異なるネットワーク内に設けられる、請求項１に記載のデータ管理システムである。
請求項４に記載の発明は、前記管理装置は、前記データが記憶されている装置と同一であり又は該装置と同一のネットワーク内に設けられる、請求項１に記載のデータ管理システムである。
請求項５に記載の発明は、前記不変性の判定は、前記データへのアクセスの要求を前記管理装置とは別の端末装置から受け付けたことを契機として行われる、請求項１に記載のデータ管理システムである。
請求項６に記載の発明は、前記不変性が損なわれていると判定された第１ハッシュ値又は前記データを記憶する装置に関する装置情報を表示する表示装置をさらに備える、請求項１に記載のデータ管理システムである。

請求項７に記載の発明は、前記不変性の判定は、前記複数の第１ハッシュ値が互いに一致する場合、すべての第１ハッシュ値の不変性が保たれていると判定することを含む、請求項１に記載のデータ管理システムである。
請求項８に記載の発明は、前記不変性の判定は、前記複数の第１ハッシュ値のうち１つでも一致しない場合、一致する個数が最も多い第１ハッシュの不変性が保たれていると判定することを含む、請求項１に記載のデータ管理システムである。
請求項９に記載の発明は、前記不変性の判定は、前記複数の第１ハッシュ値のうちの一部が前記第２ハッシュ値に一致しない場合、当該一部の第１ハッシュ値の不変性が損なわれていると判定することを含む、請求項１に記載のデータ管理システムである。
請求項１０に記載の発明は、前記不変性の判定は、前記第２ハッシュ値が、不変性が保たれていると判定された第１ハッシュ値に一致しない場合、前記データの不変性が損なわれていると判定することを含む、請求項１に記載のデータ管理システムである。

請求項１１に記載の発明は、プロセッサを有し、前記プロセッサは、予め定められた演算規則に従って管理対象のデータに対応するハッシュ値を生成し、第１時点にて生成したハッシュ値であって複数の記憶装置にそれぞれ記憶されていた複数の第１ハッシュ値と、前記第１時点よりも後の第２時点にて前記演算規則に従って再度生成したハッシュ値である第２ハッシュ値とからなる集合の間で相互に比較することで、前記複数の第１ハッシュ値又は前記データに関する不変性の判定を行うデータ管理装置である。
請求項１２に記載の発明は、プロセッサに、予め定められた演算規則に従って管理対象のデータに対応するハッシュ値を生成させ、第１時点にて生成したハッシュ値であって複数の記憶装置にそれぞれ記憶されていた複数の第１ハッシュ値と、前記第１時点よりも後の第２時点にて前記演算規則に従って再度生成したハッシュ値である第２ハッシュ値とからなる集合の間で相互に比較することで、前記複数の第１ハッシュ値又は前記データに関する不変性の判定を行わせるデータ管理プログラムである。

請求項１，１１，１２に記載の発明によれば、記憶装置に記憶されているハッシュ値を読み出して比較値として用いる際、当該ハッシュ値の不変性が損なわれていた場合に、管理対象のデータの不変性に関する誤判定を抑制される。
請求項２に記載の発明によれば、複数の第１ハッシュ値がすべて単一のネットワーク内で記憶されている場合と比べて、不変性の判定に対する信頼性がより高まる。
請求項３に記載の発明によれば、複数の第１ハッシュ値及び管理対象のデータがすべて単一のネットワーク内で記憶されている場合と比べて、不変性の判定に対する信頼性がより高まる。
請求項４に記載の発明によれば、管理対象のデータが記憶されている装置とは別のネットワーク内に管理装置が設けられる場合と比べて、管理装置がデータを取得する際に当該データの不変性が損なわれる可能性が低くなる。
請求項５に記載の発明によれば、不変性の判定を定期的に行う場合と比べて、より適したタイミングで判定がなされる。
請求項６に記載の発明によれば、不変性の判定結果を単に表示させる場合と比べて、不変性が損なわれた原因を特定するためのより有用な情報がユーザに提示される。
請求項７，８，９に記載の発明によれば、複数の第１ハッシュ値のうち一部又は全部の不変性が適切に判定される。
請求項１０に記載の発明によれば、第１，第２ハッシュ値の生成源であるデータの不変性が適切に判定される。

本発明の一実施形態におけるデータ管理システムの全体構成図である。 図１に示すオンプレミス側サーバのブロック図である。 図１に示すクラウド側サーバのブロック図である。 図２，図３の文書情報ＤＢに含まれる文書管理テーブルが有するデータ構造の一例を示す図である。 図３の資源情報ＤＢに含まれる資源管理テーブルが有するデータ構造の一例を示す図である。 データの同期更新時におけるデータ管理システムの動作を示すフローチャートである。 クラウド側データの提供時におけるデータ管理システムの動作を示すフローチャートである。 オンプレミス側データの提供時におけるデータ管理システムの動作を示すフローチャートである。 ハッシュ値又はデータの不変性が損なわれた場合におけるデータ管理システムの動作を示すフローチャートである。 図２の不変性判定部により用いられる判定規則の一例を示す図である。 ４つの第１ハッシュ値を用いた判定方法を行うための構成を示す模式図である。 クライアント端末による画面の表示例を示す図である。

本発明におけるデータ管理システムについて、データ管理装置及びデータ管理プログラムとの関係において好適な実施形態を挙げ、添付の図面を参照しながら説明する。

［データ管理システム１０の構成］
図１は、本発明の一実施形態におけるデータ管理システム１０の全体構成図である。このデータ管理システム１０は、オンプレミス環境１２及びクラウド環境１４にわたって文書データＤｏｃの管理を行う、いわゆる「ハイブリッド型」の文書管理サービスを提供可能に構成される。この実施形態では、管理対象のデータが電子文書である場合を例に挙げているが、この管理サービスは、電子文書の他にも、動画像データ、静止画像データ、音声データなどの様々な形式のデータに適用され得る。

このデータ管理システム１０は、オンプレミス環境１２内に設けられるオンプレミス側サーバ１６と、クラウド環境１４内に設けられるクラウド側サーバ１８と、少なくとも１つのクライアント端末２０と、を含んで構成される。

オンプレミス側サーバ１６は、オンプレミス環境１２内での文書データＤｏｃに関する統括的な制御を行うコンピュータである。ここで、オンプレミス側サーバ１６を単体のコンピュータとして図示しているが、これに代わって、オンプレミス側サーバ１６は、分散システムを構築するコンピュータ群であってもよい。

クラウド側サーバ１８は、クラウド環境１４内での文書データＤｏｃに関する統括的な制御を行うコンピュータである。ここで、クラウド側サーバ１８を単体のコンピュータとして図示しているが、これに代わって、クラウド側サーバ１８は、分散システムを構築するコンピュータ群であってもよい。

クライアント端末２０は、外部装置との間で双方向に通信可能なコンピュータであり、例えば、タブレット、スマートフォン、パーソナルコンピュータ、ウェアラブルデバイスなどから構成される。クライアント端末２０は、入力部２２と、出力部２４と、を含んで構成される。入力部２２は、マウス、キーボード、タッチセンサ又はマイクロフォンを含む入力デバイスからなる。出力部２４は、ディスプレイ、スピーカを含む出力デバイスからなる。クライアント端末２０は、入力部２２による入力機能と出力部２４による出力機能を組み合わせることで、ユーザインターフェース２６を実現する。

ところで、オンプレミス環境１２は、外部のネットワークＮＷから自由にアクセスできないように制限が設けられているネットワーク環境である。一方、クラウド環境１４は、不特定のユーザがアクセス可能なネットワーク環境である。例えば、オンプレミス環境１２の外側にあるクライアント端末２０は、クラウド側サーバ１８を窓口として、オンプレミス側サーバ１６が管理する文書データＤｏｃを取得することができる。

図２は、図１に示すオンプレミス側サーバ１６のブロック図である。このオンプレミス側サーバ１６は、通信部３０と、制御部３２と、記憶部３４と、を含んで構成される。

通信部３０は、外部装置に対して電気信号を送受信するための通信インターフェースである。これにより、オンプレミス側サーバ１６は、ネットワークＮＷを経由して、クラウド側サーバ１８との間で様々なデータのやり取りが可能である。

制御部３２は、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）を含むプロセッサによって構成される。制御部３２は、記憶部３４に格納された文書管理プログラムを読み出して実行することで、文書管理部３６、ハッシュ値生成部３８及び不変性判定部４０として機能する。

記憶部３４は、非一過性であり、かつ、コンピュータ読み取り可能な記憶媒体で構成されている。ここで、コンピュータ読み取り可能な記憶媒体は、ハードディスクドライブ（ＨＤＤ：Hard Disk Drive）、ソリッドステートドライブ（ＳＳＤ：Solid State Drive）を含む記憶装置、あるいは、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ、フラッシュメモリ等の可搬媒体である。本図の例では、記憶部３４には、文書データ群４２が記憶されるとともに、文書の情報に関するデータベース（以下、「文書情報ＤＢ４４」という）が構築されている。

図３は、図１に示すクラウド側サーバ１８のブロック図である。このクラウド側サーバ１８は、通信部５０と、制御部５２と、記憶部５４と、を含んで構成される。

通信部５０は、図２の通信部３０と同様の構成を有する通信インターフェースである。これにより、クラウド側サーバ１８は、ネットワークＮＷを経由して、オンプレミス側サーバ１６又はクライアント端末２０との間で様々なデータのやり取りが可能である。

制御部５２は、図２の制御部３２と同様に、ＣＰＵ、ＧＰＵを含むプロセッサによって構成される。制御部５２は、記憶部５４に格納された文書管理プログラムを読み出して実行することで、文書管理部５６及びアクセス管理部５８として機能する。

記憶部５４は、非一過性であり、かつ、コンピュータ読み取り可能な記憶媒体で構成されている。本図の例では、記憶部５４には、文書データ群６２が記憶されるとともに、文書の情報に関するデータベース（以下、「文書情報ＤＢ６４」という）、資源の情報に関するデータベース（以下、「資源情報ＤＢ６６」という）が構築されている。

図４は、図２，図３の文書情報ＤＢ４４，６４に含まれる文書管理テーブル４５，６５が有するデータ構造の一例を示す図である。より詳しくは、図４（ａ）は図２の文書情報ＤＢ４４に含まれる文書管理テーブル４５を示すとともに、図４（ｂ）は図３の文書情報ＤＢ６４に含まれる文書管理テーブル６５を示している。

この文書管理テーブル４５，６５はいずれも、文書データＤｏｃの識別情報である「文書ＩＤ」と、文書データＤｏｃの登録時点を示す「登録日時」と、文書データＤｏｃの名称を示す「ファイル名」、文書データＤｏｃへのアクセスが許可されたユーザ名を示す「許可ユーザ」と、文書データＤｏｃの格納場所を示す「格納先」と、オンプレミス側サーバ１６がクラウド側サーバ１８にアクセスするためのネットワーク情報を示す「アクセス情報」と、文書データＤｏｃから生成された「ハッシュ値」の間の対応関係を示す情報である。

なお、「格納先」は、具体的には、[１]オンプレミス側サーバ１６のみに格納される状態を示す「オンプレミス」、[２]クラウド側サーバ１８のみに格納される状態を示す「クラウド」、[３]オンプレミス側サーバ１６及びクラウド側サーバ１８の両方に格納される状態を示す「両方」のうちのいずれかが選択される。

図５は、図３の資源情報ＤＢ６６に含まれる資源管理テーブル６７が有するデータ構造の一例を示す図である。資源管理テーブル６７は、ユーザの識別情報である「ユーザＩＤ」と、ユーザの名前を示す「ユーザ名」と、文書データＤｏｃの送信先を示す「メールアドレス」と、ユーザを認証するための「パスワード」と、ユーザの所属を示す「所属グループ」と、ユーザの登録時点を示す「登録日時」の間の対応関係を示す情報である。

［データ管理システム１０の動作］
この実施形態におけるデータ管理システム１０は、以上のように構成される。続いて、データ管理システム１０の各種動作について、図６～図９のフローチャートを主に参照しながら説明する。

＜第１動作：データの同期更新＞
まず、データ管理システム１０の第１動作である「データの同期更新」について、図６のフローチャートを参照しながら説明する。この同期更新は、［１］オンプレミス環境１２内のデータ更新分をクラウド環境１４内に反映させる更新処理、［２］クラウド環境１４内のデータの更新分をオンプレミス環境１２内に反映させる更新処理、を同時に行うことで達成される。ここでは、前者の更新処理についてのみ説明する。図６のステップＳ１～Ｓ６はオンプレミス側サーバ１６により、ステップＳ７はクラウド側サーバ１８によりそれぞれ実行される。

図６のステップＳ１において、オンプレミス側サーバ１６の制御部３２（より詳しくは、文書管理部３６）は、文書データ群４２の更新状態を確認する。具体的には、文書管理部３６は、前回の更新時点における文書管理テーブル４５と、今回の更新時点における文書管理テーブル４５とを比較することで、文書データ群４２の更新の有無及び内容を確認する。

ステップＳ２において、文書管理部３６は、ステップＳ１での確認結果を参照し、特定の文書データＤｏｃに関する更新（具体的には、追加又は変更）があったか否かを確認する。特定の文書データＤｏｃの一例として、オンプレミス環境１２を利用する組織又はその構成員にとって機密性が高い情報を含むデータが挙げられる。特定の文書データＤｏｃの更新がなかった場合（ステップＳ２：ＮＯ）、ステップＳ３～Ｓ５の実行を省略し、後述するステップＳ６に進む。一方、特定の文書データＤｏｃの更新があった場合（ステップＳ２：ＹＥＳ）、次のステップＳ３に進む。

ステップＳ３において、制御部３２（より詳しくは、ハッシュ値生成部３８）は、特定の文書データＤｏｃに特有の属性情報を少なくとも１つ抽出し、この属性情報を引数とする関数を用いて特殊データを生成する。この属性情報は、文書の実データとは異なる付帯的な情報であり、例えば、ファイル名、拡張子、更新時点、作成者を含む様々な情報であってもよい。なお、この特殊データは、改ざんを防止する観点から、ハッシュ値が生成された後に削除されることが望ましい。

ステップＳ４において、ハッシュ値生成部３８は、予め定められた演算規則に従って、上記した実データ及び特殊データの組み合わせから文書データＤｏｃに対応するハッシュ値を生成する。この演算規則は、ＭＤ５、ＳＨＡ－１、ＳＨＡ－２５６を含む様々なハッシュ関数に基づく規則であってもよい。以下、データの同期更新を契機として、第１時点に生成されたハッシュ値のことを「第１ハッシュ値」という。

ステップＳ５において、ハッシュ値生成部３８は、ステップＳ４で生成された第１ハッシュ値を、オンプレミス側サーバ１６の記憶部３４に記憶させる。具体的には、図４（ａ）の文書管理テーブル４５において該当する「文書ＩＤ」に対応する「ハッシュ値」が格納される。

ステップＳ６において、オンプレミス側サーバ１６の制御部３２は、クラウド側サーバ１８に対してデータの同期更新を要求する。具体的には、オンプレミス側サーバ１６は、更新対象である文書データＤｏｃ及び文書管理テーブル４５を含むデータをクラウド側サーバ１８に向けて送信する。なお、ステップＳ３～Ｓ５の実行があった場合、文書管理テーブル４５に含まれる第１ハッシュ値も併せて送信される。

ステップＳ７において、クラウド側サーバ１８の制御部５２（より詳しくは、文書管理部５６）は、ステップＳ６でなされた同期更新の要求に応じて、各種データベースを更新する。具体的には、文書管理部５６は、オンプレミス側サーバ１６から受信した文書データＤｏｃを用いて文書データ群６２を更新するとともに、オンプレミス側サーバ１６から受信した文書管理テーブル４５を用いて文書情報ＤＢ６４の更新を行う。ここで、文書管理テーブル４５に第１ハッシュ値が新たに追記されている場合、第１ハッシュ値は、文書管理テーブル６５の更新を通じて記憶部３４に記憶される点に留意する。このようにして、データ管理システム１０の第１動作が終了する。

＜第２動作：クラウド側データの提供＞
続いて、データ管理システム１０の第２動作である「クラウド側データの提供」について、図７のフローチャートを参照しながら説明する。図７のステップＳ１１～Ｓ１５はいずれもクラウド側サーバ１８により実行される。

図７のステップＳ１１において、クラウド側サーバ１８の制御部５２（より詳しくは、アクセス管理部５８）は、文書データＤｏｃへのアクセスを要求するための要求信号を、クライアント端末２０から受け付けたか否かを確認する。ここで、「アクセス」とは、ユーザが文書データＤｏｃを利用することができる状態を意味し、例えば、クライアント端末２０が文書データＤｏｃを取得することであってもよいし、クライアント端末２０と文書データＤｏｃを保持する装置との間の接続が許可されることであってもよい。

この確認に先立ち、ユーザは、クライアント端末２０のユーザインターフェース２６を介して、要求対象である文書データＤｏｃの指定やユーザの認証を含む要求操作を行う。そうすると、クライアント端末２０は、ユーザ名、ファイル名、メールアドレス、パスワードなどのアクセス要求情報を含む要求信号を生成し、この要求信号をクラウド側サーバ１８に向けて送信する。

クラウド側サーバ１８がクライアント端末２０からの要求信号をまだ受け付けていない場合（ステップＳ１１：ＮＯ）、この要求信号を受け付けるまでステップＳ１１に留まる。一方、クラウド側サーバ１８がこの要求信号を受け付けた場合（ステップＳ１１：ＹＥＳ）、次のステップＳ１２に進む。

ステップＳ１２において、アクセス管理部５８は、ステップＳ１１で受け付けた要求信号から特定されるアクセス要求情報を用いて、クライアント端末２０に対して要求操作を行ったユーザがアクセス権限を有するか否かを判定する。具体的には、アクセス管理部５８は、ファイル名を照合して文書情報ＤＢ６４から文書管理テーブル６５を読み出すとともに、許可ユーザ（つまり、ユーザ名）を照合して資源情報ＤＢ６６から資源管理テーブル６７を読み出す。そして、アクセス管理部５８は、メールアドレスの入力値及び設定値が一致し、かつパスワードの入力値及び設定値が一致した場合、ユーザのアクセス権限があると判定する。

ステップＳ１３において、アクセス管理部５８は、文書データＤｏｃへのアクセスを許可するか否かを決定する。このアクセスを許可しない場合（ステップＳ１３：ＮＯ）、ステップＳ１４，Ｓ１５の実行を省略し、図７のフローチャートを終了する。一方、このアクセスを許可する場合（ステップＳ１３：ＹＥＳ）、次のステップＳ１４に進む。

ステップＳ１４において、クラウド側サーバ１８の制御部５２（より詳しくは、文書管理部５６）は、要求対象の文書データＤｏｃがクラウド環境１４内にあるか否かを確認する。具体的には、文書管理部５６は、文書管理テーブル６５内の該当する保存先が「オンプレミス」であればクラウド環境１４内にないと判定し（ステップＳ１４：ＮＯ）、後述する図８のステップＳ２２に進む。一方、文書管理部５６は、該当する保存先が「クラウド」又は「両方」のいずれかであればクラウド環境１４内にあると判定し（ステップＳ１４：ＹＥＳ）、次のステップＳ１５に進む。

ステップＳ１５において、文書管理部５６は、要求対象の文書データＤｏｃを文書データ群６２から読み出した後、クライアント端末２０を送信先に指定して当該文書データＤｏｃを送信する制御を行う。そうすると、クライアント端末２０は、ネットワークＮＷを介して、クラウド側サーバ１８からの文書データＤｏｃを受信する。

このようにして、データ管理システム１０の第２動作が終了し、クラウド環境１４内の文書データＤｏｃがユーザに提供される。一方、所望の文書データＤｏｃがオンプレミス環境１２内にある場合、クラウド側サーバ１８は、クライアント端末２０に提供する文書データＤｏｃをオンプレミス側サーバ１６から事前に取得しなければならない。

＜第３動作：オンプレミス側データの提供＞
続いて、データ管理システムの第３動作である「オンプレミス側データの提供」について、図８，図９のフローチャートを参照しながら説明する。図８のステップＳ２１，Ｓ２７はクラウド側サーバ１８により、ステップＳ２２～Ｓ２６はオンプレミス側サーバ１６によりそれぞれ実行される。

図８のステップＳ２１において、クラウド側サーバ１８は、オンプレミス側サーバ１６に対して文書データＤｏｃの送信を要求する。具体的には、クラウド側サーバ１８は、文書管理テーブル４５内にある文書データＤｏｃの管理情報を含む要求信号を、オンプレミス側サーバ１６に向けて送信する。この管理情報には、文書ＩＤ、ユーザＩＤ及びハッシュ値の他に、上記した特殊データを生成するための各種情報が含まれる。

ステップＳ２２において、オンプレミス側サーバ１６の制御部３２（より詳しくは、ハッシュ値生成部３８）は、ステップＳ２１で送信された要求信号を受信した後、取得した管理情報に含まれる文書ＩＤから要求対象の文書データＤｏｃを特定し、図６のステップＳ３の場合と同一の関数を用いて特殊データを生成する。

ステップＳ２３において、ハッシュ値生成部３８は、図６のステップ４の場合と同一の演算規則に従って、実データ及び特殊データの組み合わせから文書データＤｏｃに対応するハッシュ値を生成する。以下、文書データＤｏｃの要求を契機として、第２時点に生成されたハッシュ値のことを「第２ハッシュ値」という。この第２時点は、文書データＤｏｃの同期更新時である第１時点よりも後の時点に相当する。

ステップＳ２４において、制御部３２（より詳しくは、不変性判定部４０）は、要求対象の文書データＤｏｃを用いて過去に生成された複数の第１ハッシュ値を取得する。具体的には、不変性判定部４０は、オンプレミス側サーバ１６の文書管理テーブル４５に含まれる第１ハッシュ値を取得するとともに、クラウド側サーバ１８からの管理情報に含まれる第１ハッシュ値を取得する。これにより、２つの記憶部３４，５４により記憶されていた２つの第１ハッシュ値が取得される。

ステップＳ２５において、不変性判定部４０は、ステップＳ２３，Ｓ２４で得られた３つのハッシュ値がすべて一致するか否かを判定する。３つのハッシュ値のうち１つでも一致しない場合（ステップＳ２５：ＮＯ）、後述する図９のステップＳ３１に進む。一方、３つのハッシュ値がすべて一致する場合（ステップＳ２５：ＹＥＳ）、次のステップＳ２６に進む。

ステップＳ２６において、文書管理部３６は、要求対象の文書データＤｏｃを文書データ群４２から読み出した後、クラウド側サーバ１８を送信先に指定して当該文書データＤｏｃを送信する制御を行う。そうすると、クラウド側サーバ１８は、ネットワークＮＷを介して、オンプレミス側サーバ１６からの文書データＤｏｃを受信する。

ステップＳ２７において、クラウド側サーバ１８の制御部５２（より詳しくは、文書管理部５６）は、要求対象の文書データＤｏｃを受信した後、クライアント端末２０を送信先に指定して当該文書データＤｏｃを送信する制御を行う。そうすると、クライアント端末２０は、ネットワークＮＷを介して、クラウド側サーバ１８からの文書データＤｏｃを受信する。

このようにして、オンプレミス環境１２内の文書データＤｏｃは、不変性が保たれていることが確認された上で、ユーザに提供される。この「不変性が保たれている」とは、時間の経過にわたって文書データＤｏｃの同一性が維持されることを意味し、改ざんや破損がない状態をいう。一方、３つのハッシュ値のうち１つでも一致していない場合、データ管理システム１０は、図９のフローチャートに従って動作する。図９のステップＳ３１～Ｓ３３はオンプレミス側サーバ１６により、ステップＳ３４はクラウド側サーバ１８により、ステップＳ３５はクライアント端末２０によりそれぞれ実行される。

図９のステップＳ３１において、オンプレミス側サーバ１６の制御部３２（より詳しくは、不変性判定部４０）は、３つのハッシュ値からなる集合の間で相互に比較することで、ハッシュ値の不一致を示す分類パターン（以下、「不一致パターン」という）を特定する。比較対象であるハッシュ値が３つである場合、この不一致性パターンは、１つのみが一致しないパターン、又は３つとも一致しないパターンのいずれかである。

ステップＳ３２において、不変性判定部４０は、ステップＳ３１で特定された不一致パターンから、データの不変性が損なわれた原因を判定する。ここで、「データの不変性を損なう」には、［１］データが改ざんされること、及び［２］データが破損すること、の両方の現象が含まれる。この原因は、図１０に示す判定規則に従って判定される。

図１０に示す判定規則は、ハッシュ値の組み合わせに対する判定結果をそれぞれ記述している。本図では、オンプレミス側の第１ハッシュ値を「ＨＯ１」、クラウド側の第１ハッシュ値を「ＨＣ１」、再生成された第２ハッシュ値を「ＨＯ２」とそれぞれ表記している。また、「一致」とは、ハッシュ値が一致した個数が最も多いグループ（以下、「最多数グループ」という）に属することを意味する。逆に「不一致」とは、上記した最多数グループに属さないことを意味する。

ここでは、［１］ハッシュ値ＨＯ１，ＨＣ１，ＨＯ２がすべて一致する場合、正常であると判定される。［２］ハッシュ値ＨＯ１のみが一致しない場合、オンプレミス側にてハッシュ値ＨＯ１の改ざん又は破損があったと判定される。［３］ハッシュ値ＨＣ１のみが一致しない場合、クラウド側にてハッシュ値ＨＣ１の改ざん又は破損があったと判定される。［４］ハッシュ値ＨＯ２のみが一致しない場合、オンプレミス側にて文書データＤｏｃの改ざん又は破損があったと判定される。［５］ハッシュ値ＨＯ１，ＨＣ１，ＨＯ２が相互に一致しない場合、原因不明の異常であると判定される。ここでは、２つの第１ハッシュ値を用いて判定が行われるが、３つ、４つあるいは５つ以上の第１ハッシュ値を用いて判定が行われてもよい。

図１１は、４つの第１ハッシュ値を用いた判定方法を行うための構成を示す模式図である。本図における「Ｈ１」は第１ハッシュ値を、「Ｈ２」は第２ハッシュ値をそれぞれ示している。ここでは、第１ハッシュ値は、オンプレミス側サーバ１６の記憶部３４と、クラウド側サーバ１８の記憶部５４の他にも、これとは別の記憶部７０，７２にそれぞれ記憶されている。記憶部７０，７２は、データの保存を目的とするストレージ装置であってもよいし、コンピュータに内蔵するメモリであってもよい。また、記憶部７０，７２は、オンプレミス環境１２内又はクラウド環境１４内に設けられてもよいし、これとは別のネットワーク環境内に設けられてもよい。

例えば、複数の第１ハッシュ値がすべて単一のネットワーク内で記憶されている場合、当該ネットワーク内で障害などが発生した場合、不変性の判定が実行できない可能性がある。そこで、この判定に対する信頼性をより高めるべく、複数の記憶部３４，５４，７０，７２のうちの少なくとも１つは、他の記憶装置とは異なるネットワーク内に設けられてもよい。

同様に、複数の第１ハッシュ値と文書データＤｏｃの両方が単一のネットワーク内で記憶されている場合、当該ネットワーク内で障害などが発生した場合、不変性の判定が実行できない可能性がある。そこで、この判定に対する信頼性をより高めるべく、複数の記憶部３４，５４，７０，７２のうちの少なくとも１つは、文書データＤｏｃが記憶されている装置（つまり、オンプレミス側サーバ１６）とは異なるネットワーク内に設けられてもよい。

また、文書データＤｏｃを記憶する装置と不変性を判定する装置とが別々のネットワーク内に設けられている場合、この判定を行う際に複数のネットワークにわたって文書データＤｏｃがやり取りされるので、その分だけ改ざんや破損などが発生する可能性が高くなる。そこで、制御部３２が文書データＤｏｃを取得する際に文書データＤｏｃの不変性が損なわれることを抑制するため、オンプレミス側サーバ１６は、文書データＤｏｃが記憶されている装置と同一であってもよいし、あるいは該装置と同一のネットワーク内に設けられてもよい。

また、制御部３２が不変性の判定を定期的に行う場合、クライアント端末２０が文書データＤｏｃへのアクセスを要求するタイミングによっては、直近の判定時点から時間が空いてしまうため、その空いた期間内に文書データＤｏｃの改ざんや破損などが発生することがあり得る。そこで、文書データＤｏｃを要求するユーザにとってより適したタイミングで判定するため、制御部３２は、文書データＤｏｃへのアクセスの要求をオンプレミス側サーバ１６とは別のクライアント端末２０から受け付けたことを契機として判定を行ってもよい。

複数の第１ハッシュ値を用いて判定を行う場合、［１］制御部３２（より詳しくは、不変性判定部４０）は、複数の第１ハッシュ値が互いに一致する場合、すべての第１ハッシュ値の不変性が保たれていると判定してもよい。また、［２］制御部３２は、複数の第１ハッシュ値のうち１つでも一致しない場合、最多数グループに属する第１ハッシュの不変性が保たれていると判定してもよい。また、［３］制御部３２は、複数の第１ハッシュ値のうちの一部が第２ハッシュ値に一致しない場合、当該一部の第１ハッシュ値の不変性が損なわれていると判定してもよい。また、［４］制御部３２は、第２ハッシュ値が、不変性が保たれていると判定された第１ハッシュ値に一致しない場合、文書データＤｏｃの不変性が損なわれていると判定してもよい。このようにして、第１，第２ハッシュ値、又は文書データＤｏｃの不変性が損なわれた原因が切り分けられる（ステップＳ３２）。

図９のステップＳ３３において、オンプレミス側サーバ１６の制御部３２（より詳しくは、文書管理部３６）は、要求対象の文書データＤｏｃの送信ができない旨を通知する制御を行う。そうすると、クラウド側サーバ１８は、ネットワークＮＷを介して、オンプレミス側サーバ１６からの通知信号を受信する。

ステップＳ３４において、クラウド側サーバ１８の制御部５２（より詳しくは、文書管理部５６）は、要求対象の文書データＤｏｃの送信ができない旨を通知する制御を行う。そうすると、クライアント端末２０は、ネットワークＮＷを介して、クラウド側サーバ１８からの通知信号を受信する。

ステップＳ３５において、クライアント端末２０の出力部２４は、文書データＤｏｃの送信ができない旨をユーザに向けて出力する。ここでは、その原因を特定するためのより有用な情報をユーザに提示すべく、出力部２４は、不変性が損なわれていると判定された第１ハッシュ値又は文書データＤｏｃを記憶する装置に関する情報を確認画面８０上に表示する。

図１２は、確認画面８０上の表示の一例を示す図である。より詳しくは、図１２（ａ）はクライアント端末２０が文書データＤｏｃを取得できた場合を示すとともに、図１２（ｂ）はクライアント端末２０が文書データＤｏｃを取得できなかった場合を示している。この確認画面８０内には、確認結果、理由、及び対象機器を示す第１欄８２と、３つのハッシュ値を示す第２欄８４と、が設けられている。

第１欄８２内の「確認結果」には、図８のステップＳ２５での判定結果が表示される。具体的には、３つのハッシュ値がすべて一致している場合には「問題無し」と表示される一方、３つのハッシュ値のうち１つでも一致していない場合には「問題有り」と表示される。第１欄８２内の「理由」には、図９のステップＳ３２での判定結果、つまり図１０に示す「原因」が表示される。第１欄８２の「対象機器」には、不変性が損なわれていると判定された第１ハッシュ値又は文書データＤｏｃを記憶する装置に関する装置情報（例えば、装置の名前・ＩＤ・管理者など）が表示される。

ユーザは、確認画面８０上の第２欄８４を視認することで、データの改ざん・破損の事実を一目で把握することができる。また、第１欄８２を視認したユーザに、データの改ざん・破損に対処するための行動を促すことができる。このようにして、データ管理システム１０の第３動作が終了する。

以上のように、このデータ管理システム１０、データ管理装置及びデータ管理プログラムによれば、［１］オンプレミス側サーバ１６の制御部３２が、予め定められた演算規則に従って管理対象の文書データＤｏｃに対応するハッシュ値を生成し（ステップＳ４，Ｓ２３）、［２］複数の記憶部３４，５４，７０，７２が、第１時点にて制御部３２が生成した第１ハッシュ値をそれぞれ記憶し（ステップＳ５，Ｓ７）、［３］制御部３２が、複数の記憶部３４，５４，７０，７２から読み出された複数の第１ハッシュ値と、第１時点よりも後の第２時点にて演算規則に従って再度生成した第２ハッシュ値とからなる集合の間で相互に比較することで、複数の第１ハッシュ値又は文書データＤｏｃに関する不変性の判定を行う（ステップＳ２５，Ｓ３１，Ｓ３２）。

このように、複数の第１ハッシュ値同士を相互に比較することで異なる記憶部３４，５４，７０，７２におけるハッシュ値の一貫性を評価することが可能となり、第１ハッシュ値と第２ハッシュ値を相互に比較することで異なる生成時点におけるハッシュ値の一貫性を評価することが可能となる。つまり、複数の第１ハッシュ値と第２ハッシュ値の間のクロスチェックを通じて、文書データＤｏｃに関する判定結果とは切り離された状態で、各々の第１ハッシュ値に関する不変性を判定することができる。これにより、記憶装置に記憶されているハッシュ値を読み出して比較値として用いる際、当該ハッシュ値の不変性が損なわれていた場合に、文書データＤｏｃの不変性に関する誤判定が抑制される。

［変形例］
なお、本発明は、上記した実施形態に限定されるものではなく、この発明の主旨を逸脱しない範囲で自由に変更できることは勿論である。あるいは、技術的に矛盾が生じない範囲で各々の構成を任意に組み合わせてもよい。

上記した実施形態における「プロセッサ」は、広義のプロセッサを意味し、汎用的なプロセッサ（ＣＰＵ又はＭＰＵ）のみならず、専用的なプロセッサ（ＧＰＵ；Graphics Processing Unit、ＡＳＩＣ：Application Specific Integrated Circuit、ＦＰＧＡ：Field Programmable Gate Array、ＰＬＤ：Programmable Logic Device）を含み得る。

上記した実施形態におけるプロセッサの動作は、１つのプロセッサにより行われてもよいし、物理的に離れた位置に設けられた複数のプロセッサが協働して行われてもよい。また、プロセッサの各動作の順序は、図６～図９に示すフローチャートの順序のみに限定されるものではなく、必要に応じて適宜変更され得る。

１０ データ管理システム、１２ オンプレミス環境、１４ クラウド環境、１６ オンプレミス側サーバ、１８ クラウド側サーバ（データ管理装置）、２０ クライアント端末、２４ 出力部（表示装置）、３２ 制御部（プロセッサ）、３４，５４，７０，７２ 記憶部（記憶装置）、８０ 確認画面、Ｄｏｃ 文書データ（データ）、ＮＷ ネットワーク。

Claims (12)

1. プロセッサを有する管理装置と、複数の記憶装置と、を備え、
   前記プロセッサは、予め定められた演算規則に従って管理対象のデータに対応するハッシュ値を生成し、
   前記複数の記憶装置は、前記プロセッサが第１時点にて生成したハッシュ値である第１ハッシュ値をそれぞれ記憶し、
   前記プロセッサは、前記複数の記憶装置から読み出された前記複数の第１ハッシュ値と、前記第１時点よりも後の第２時点にて前記演算規則に従って再度生成したハッシュ値である第２ハッシュ値とからなる集合の間で相互に比較することで、前記複数の第１ハッシュ値又は前記データに関する不変性の判定を行う
   ことを特徴とするデータ管理システム。
2. 前記複数の記憶装置のうちの少なくとも１つは、他の記憶装置とは異なるネットワーク内に設けられることを特徴とする請求項１に記載のデータ管理システム。
3. 前記複数の記憶装置のうちの少なくとも１つは、前記データが記憶されている装置とは異なるネットワーク内に設けられることを特徴とする請求項１に記載のデータ管理システム。
4. 前記管理装置は、前記データが記憶されている装置と同一であり又は該装置と同一のネットワーク内に設けられることを特徴とする請求項１に記載のデータ管理システム。
5. 前記不変性の判定は、前記データへのアクセスの要求を前記管理装置とは別の端末装置から受け付けたことを契機として行われることを特徴とする請求項１に記載のデータ管理システム。
6. 前記不変性が損なわれていると判定された第１ハッシュ値又は前記データを記憶する装置に関する情報を表示する表示装置をさらに備えることを特徴とする請求項１に記載のデータ管理システム。
7. 前記不変性の判定は、前記複数の第１ハッシュ値が互いに一致する場合、すべての第１ハッシュ値の不変性が保たれていると判定することを含むことを特徴とする請求項１に記載のデータ管理システム。
8. 前記不変性の判定は、前記複数の第１ハッシュ値のうち１つでも一致しない場合、一致する個数が最も多い第１ハッシュの不変性が保たれていると判定することを含むことを特徴とする請求項１に記載のデータ管理システム。
9. 前記不変性の判定は、前記複数の第１ハッシュ値のうちの一部が前記第２ハッシュ値に一致しない場合、当該一部の第１ハッシュ値の不変性が損なわれていると判定することを含むことを特徴とする請求項１に記載のデータ管理システム。
10. 前記不変性の判定は、前記第２ハッシュ値が、不変性が保たれていると判定された第１ハッシュ値に一致しない場合、前記データの不変性が損なわれていると判定することを含むことを特徴とする請求項１に記載のデータ管理システム。
11. プロセッサを有し、前記プロセッサは、
    予め定められた演算規則に従って管理対象のデータに対応するハッシュ値を生成し、
    第１時点にて生成したハッシュ値であって複数の記憶装置にそれぞれ記憶されていた複数の第１ハッシュ値と、前記第１時点よりも後の第２時点にて前記演算規則に従って再度生成したハッシュ値である第２ハッシュ値とからなる集合の間で相互に比較することで、前記複数の第１ハッシュ値又は前記データに関する不変性の判定を行う
    ことを特徴とするデータ管理装置。
12. プロセッサに、
    予め定められた演算規則に従って管理対象のデータに対応するハッシュ値を生成させ、
    第１時点にて生成したハッシュ値であって複数の記憶装置にそれぞれ記憶されていた複数の第１ハッシュ値と、前記第１時点よりも後の第２時点にて前記演算規則に従って再度生成したハッシュ値である第２ハッシュ値とからなる集合の間で相互に比較することで、前記複数の第１ハッシュ値又は前記データに関する不変性の判定を行わせる
    ことを特徴とするデータ管理プログラム。

Images